← Back to team overview

torios team mailing list archive

Re: Too early for ToriOS to change its path


On Mon, August 13, 2018 6:47 am, Israel wrote:
> 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
> highlighting. 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 reworked.

I think the developer of EDE came to a similar conclusion.  Don't know how
useful his work would be for ToriOS because EDE requires a helper library
along with FLTK.  Would make more sense to use on a system where EDE was
the desktop of choice instead of using JWM as file manager of choice. 
Personally, I like sticking with JWM over a desktop though.

It sounds like you're doing well with this.  If there's any way you can
integrate the scintilla widget in the background, that could handle syntax
highlighting.  It has a nice parser to highlight various programming
languages and is highly customizable.

> I found this, and think you might be interested in it.
> https://github.com/beranat/flviewer
> It allows mupdf/poppler support, and does the basics for an image viewer.

I've tried it out before.  Seemed very nice.

I tried making some changes to mupdf to add cbr format using sumatrapdf's
unrar library.  After checking what it would take to integrate with mupdf,
I realized I could write a stand-alone cbr/cbz viewer using unrar that
could do whatever I need.  mupdf is Affero GPL and unrar is only LGPL. 
So, if I write my own viewer, it doesn't need to have a GPL or Affero GPL
license.  I can also write it to follow Unix philosophy of doing one thing
well.  Instead of supporting PDF, XPS, epub, HTML, etc., I can just
concentrate on cbr and cbz formats.

I still like mupdf for a lightweight PDF viewer.  I also thought this was
an interesting alternative for a PDF viewer:
It has an Apache license which is much more lenient than the GNU Affero
license of mupdf and the GNU license of poppler.  Since it's written in
JavaScript, it's probably slower.  I did see an interesting argument that
the speed for JavaScript might be good on some systems if they make
efficient use of canvas (and opengl behind it) for rendering.  Wonder how
hard it would be to try to port some of the JavaScript to C.

> I recently cam across a way to use fl_read_image(...) to create a
> screenshot.  I found:
> https://stackoverflow.com/questions/46596654/fltk-desktop-screenshot-issu
> e

Will check it out.  I've seen a few interesting screen shot programs. 
Haven't had time to look through the code yet.  When I have more time,
it'll be interesting going through them and trying to figure out which I
like best or incorporating them with other tools.

Always enjoy discussing lightweight alternatives with other FLOSS advocates.

Best wishes.