On 3/22/19 11:15 AM, m...@distasis.com wrote: > On Sat, March 16, 2019 6:37 am, Israel wrote: >> I am always looking for light weight alternatives to GIMP (I like GIMP, >> but it is really heavy for what I usually use it for). > Me too. I know, that is why I am always interested when you bring up a new one (well really any new fast light program) > >> Did you modify anything? I know you like to modify makefiles (and >> sometimes source) to suit your needs and also to improve cross platform >> capabilities. > It built fine pretty much as is. The only thing I needed to change was > the include location for SDL. It pointed to "SDL/SDL.h" and I switched it > to "SDL.h". Otherwise, it couldn't find my SDL include files on my > system. I'm hoping to add SDL2 support at some point, but haven't had > time to look into it. I also like grafx2 and graphicsmagick for graphics > editing.
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 do wish there was a clear streamlined way to get new software easily into Debian. > I.mage is really interesting, but it's not easy to build. I am not familiar with I.mage perhaps I just can't remember which one it is... > The developer > probably designed it on Windows since it works better (and looks better) > on that system. It uses GTK as a backend on Linux machines. The > developer recently added some partial support for a SDL backend. So, I > may look into trying to get that working at some point. > > The calendar program you mentioned in another post sounds really > interesting. Look forward to checking it out. I've used fltdj if I need > a lightweight PIM. It is not really a PIM. Basically all it is is a calendar widget for FLTK with a pretty decent api for modifying things. You simply get a date printed back on stdout once you choose OK, in this program. It is pretty much the same as most DE calendars. I have thought about adding in support for marking days, holidays, etc... and changing the color of that day, or adding an image etc... But currently it is just a calendar widget inside a window (you can configure the colors, though...) just to pop up to see the date (and look up future/past dates). > I've been trying to use picogl (a TinyGL fork) on systems that don't > handle OpenGL well or don't support it. I've been adding missing OpenGL > features to picogl as I run across things I need from programs I'm porting > with it. I just added support for the glTexSubImage2D command. However, > I found a bug with textures. When I specify texture coordinates, it is > sometimes rendering a little more of the texture than it should. That's > probably in the original rendering code, so I don't think it's going to be > any fun to track down that bug and fix it. Seems to be working pretty > well as an OpenGL substitute otherwise. picogl has nano-x and vesafb > backend options (as well as SDL), so you don't even need X to use it. How much does it reduce the size of the programs? How much complexity does it add? Are you simply adding in new conditions/functions or are you reworking the code to only use it? Do you use defines, for the compiler or is it a runtime thing? > > Sincerely, > Laura > http://www.distasis.com/cpp > -- Regards -- Mailing list: https://launchpad.net/~torios Post to : torios@lists.launchpad.net Unsubscribe : https://launchpad.net/~torios More help : https://help.launchpad.net/ListHelp
