← Back to team overview

torios team 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.
> Laura

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.


Follow ups