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 -- Mailing list: https://launchpad.net/~torios Post to : torios@lists.launchpad.net Unsubscribe : https://launchpad.net/~torios More help : https://help.launchpad.net/ListHelp
