torios team mailing list archive

[ml@xxxxxxxxxxxx]

On Sun, March 24, 2019 6:03 am, Israel wrote:
> Rendera is one that I you sent me that I really like, as well.  I think
> with a few tweaks it would be even more solid.

I like it too.  Sometimes use it to get the RGB color number from a
picture of a screenshot using the eye dropper.  Didn't have much luck when
I tried to edit a large graphic though.

>
> I do wish there was a clear streamlined way to get new software easily
> into Debian.

Speaking of getting software into Debian, would appreciate any tips you or
other list members may have on generating deb packages.  So far, I've been
using a different package manager for development, generating tarballs and
using alien to convert to a deb file.  Did that for Tuxmath (which I'm
also having issues getting back into Debian).  Debian had (and may still
have) a version of TiMidity++ that's so old it's practically useless on my
system.  Didn't contain any of the updates for displaying Karaoke midi
lyrics (or other fixes).  It think it's easier for Debian based
distributions to have their own archive with their own added packages than
try to get them back into mainstream Debian.  I know some of the Debian
developers have complained they'd prefer the Ubuntu modifications and
other software forks be reintegrated into their system.  However, I don't
see an easy way for most developers to do that.

Have you checked out some of the Antix Linux modifications to Debian? 
They're running without systemd and have some features and utilities that
are very nice for older computers.  They use Debian repos but also have
their own.

> It is not really a PIM.  Basically all it is is a calendar widget for
> FLTK with a pretty decent api for modifying things.

I figured it was basically a simple calendar.  It's really nice to have
one that you can be add to a menu or toolbar for a quick look at the month
and then possibly add the alternative of bringing up a PIM like fltdj for
other functionality.

> I have thought about adding in support for marking days, holidays,
> etc... and changing the color of that day, or adding an image etc...

I think just having something you can click on from a toolbar to see
today's date and when dates are in the month (such as what day of the
week) is enough for a basic calendar program.  Having the time displayed
could be useful too though.

Don't know if you've experimented with pcal (which last I checked had a
Debian package).  It has some nice PIM-like functionality for a command
line program.  I think having a basic calendar program with the option of
bringing up a user's favorite PIM or other scheduling program of choice is
all I'd want on a lightweight operating system.

>
> How much does it reduce the size of the programs?

Is that for picoGL in place of OpenGL or for nano-X instead of X Windows?

You can check out nanolinux if you want to see a version of Linux that
works with FLTK and without X Windows.  It uses nano-x exclusively.  It is
more lightweight than X Windows.  However, I don't know if it's any more
responsive on older systems than X Windows.  If anyone's interested, you
can compare NanoLinux to TinyCore Linux which it used as a base system to
compare response times.

As to using picoGL instead of OpenGL, I don't do that because one is
smaller.  I do that because OpenGL/Mesa often uses GPU/hardware
acceleration which typically doesn't work well on older machines.  Some of
the handheld devices can't run OpenGL/Mesa; it's too slow.  However, they
can run applications using TinyGL or PicoGL.  The opposite is true on some
of the newer phones.  It depends on whether CPU processing or hardware/GPU
is faster on the system.

> How much complexity does it add? Are you simply adding in new
> conditions/functions or are you reworking the code to only use it?

For nano-x, the nx11 library provides some of the basic functionality that
the X11 libraries have.  It's enough to recompile FLTK using nano-x
instead of the X11 libraries.

For PicoGL, I have some #ifdefs in Emilia Pinball to use it, but mainly
because Emilia Pinball is using some of the SDL OpenGL functions and I'm
using PicoGL with an SDL backend not the other way around.  I've seen a
few operating systems that weren't Linux based used TinyGL as a backend
for SDL.  I'm currently experimenting with trying to get some OpenGL
sample programs working with PicoGL.  You typically need a library to hide
the system specific parts of a program (non-graphics rendering parts such
as creating windows, keyboard input, mouse handling, etc.).  Libraries
like freeglut and glfw handle this.  However, they don't currently offer
the option to choose TinyGL or PicoGL as an OpenGL implementation.  For
what I'm currently testing, I've written a library that handles bringing
up a window and checking keystrokes/mouse clicks.  It currently uses a few
defines and compilation changes if I target a different platform or a
different version of OpenGL, Mesa, PicoGL, etc.  For the OpenGL specific
code, it's just a change in include file path and which libraries to use
when I switch between OpenGL and PicoGL.  TinyGL provides a subset of the
OpenGL commands/API.

As mentioned, the handheld devices use TinyGL and so do some alternative
operating systems like the Free Amiga clones.  There are a few games
written for TinyGL.  One that I saw mentioned was Elite, but I'm not sure
about the licensing status for it.  I also just ran across this one:
https://github.com/bomblik/BlockOut_II_PSVITA  I also ran across the
glshim project ( https://github.com/lunixbochs/glshim ) which uses a
TinyGL fork or a OpenGLES implementation and tries to provide missing
OpenGL desktop functionality in order to port earlier OpenGL based games. 
To make things more complicated when building OpenGL applications, newer
versions of OpenGL and OpenGLES which attempt to take advantage of GPUs
and hardware are not very backward compatible with the older versions
using a fixed pipeline.  There's a mupdf backend that's written using
OpenGL, but not sure if it would port to PicoGL or there's still some
basic functionality missing.  Last time I tried, I still needed to add
glTexSubImage2D support.  Haven't tried since.  Still looking for
interesting OpenGL based applications.  Some of the applications that use
https://sourceforge.net/projects/otk/ looked like they might be useful,
but haven't had time to experiment with them yet.

Sincerely,
Laura