torios team mailing list archive

[Israel <israeldahl@xxxxxxxxx>]

On 3/22/19 11:15 AM, ml@xxxxxxxxxxxx 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