torios team mailing list archive
Mailing list archive
Re: Too early for ToriOS to change its path
On 08/12/2018 06:16 PM, ml@xxxxxxxxxxxx wrote:
> On Tue, August 7, 2018 6:25 am, Israel wrote:
>> yeah I looked at his editor, and it is the tutorial from FLTK just
>> modified slightly. But as it is it wouldn't compile. I guess I could do
>> the same, and make a text editor using the code form the Tutorial as well.
> Don't know if that's what I tried, but whatever I ran did build from
> source. Looked like a basic editor. There were a few at that site.
> I keep wanting to use the scintilla widget from SciTE to create a text
> editor. There's an editor for Fox Toolkit that uses it. There's even an
> ncurses editor that uses it. Someone tried to connect Scintilla with FLTK
> but it wasn't a portable implementation (think it was Windows only).
I actually decided to just make a text editor, the way I wanted it to work.
So far I have a working editor that has a tabbed interface (important
for small screens, I think) but have not fully implemented the Syntax
I had to reimplement the Fl_Text_Editor widget to be able to allow
syntax highlighting... I hope to finish it soon.
It is already much nicer than Xedit (the X11 text editor), so this is a
feature I can return to later once the rest of the programs have been
>> I have thought about making a default theme for FLTK, but my main
>> concern is to make things really consistent.
> Think that would be great. The FLTK developers seem interested in adding
> new themes and finding ways to make it easier to get the new themes added
> to the code.
I have not looked into how to theme FLTK yet, but I suppose I should :D
>> JWM is not completely capable of doing this.
> Just recently saw an old post on the Puppy forum about someone adding some
> features to JWM and looking into adding support for SVG icons using
> nanosvg. Don't know how far they got on the project though.
technosaurus (a Puppy Linux guy) is probably who brought that up. He
made a version of JWM that uses nanosvg for svg support, though JWM does
have SVG support already... I do like how small nanosvg is.
>> There is only a GuI for the xpdf I am familiar with. Is xpdf the name
>> of a library as well? because there is an xpdf (X11-pdf) that uses the
>> Xlibs to draw the window, etc..
> Looked up xpdf on the Debian site and it seemed to indicate this was the
> xpdf client front end and it was now using the poppler library (fork of
> xpdf) instead of xpdf itself as the backend.
Ahh... that makes sense
> I would recommend looking into using mupdf.
I found this, and think you might be interested in it.
It allows mupdf/poppler support, and does the basics for an image viewer.
> It includes lightweight X11
> and OpenGL/GLFW front ends. There are other viewers like zathura that
> offer alternative backends (poppler or mupdf libraries). Mupdf does not
> have as many features as poppler or xpdf. So, if you need more than a
> basic PDF viewer, stick with poppler. However, mupdf renders faster and
> is more responsive (especially on older systems). So, if a basic PDF
> viewer (and ebook reader and cbz viewer and picture viewer) is enough,
> mupdf is a good alternative. xpdf and poppler are written in C++ while
> mupdf is written in C and designed for efficiency. There are some web
> sites with rendering statistics that compare performance between poppler
> and mupdf. They all show mupdf as performing better.
> Best wishes.
I appreciate all your input on this subject, I know small, efficient
programs are a passion of yours.
I recently cam across a way to use fl_read_image(...) to create a
screenshot. I found:
When looking to see if there was a way to use FLTK to grab the entire
screen (for this purpose), and have built a small screenshot tool (26.3
KiB). The only output is PNG, which seemed reasonable, since FLTK also
uses libpng. The program is simple, and eventually I would like to add
single window screenshots, or perhaps, resizeable, but I would like to
finish with all the little programs before extending them more fully.