Re: PNG support

Darren Vincent Hart wrote:
> On Tue, 2003-07-22 at 09:09, Marc Strämke wrote:
> 
>>Hi ppl :)
>>The image class now uses offscreen surfaces and libpng for loading, test 
>>  it and break it please :) (supports rgb and rgba PNGs)
>>
> 
> 
> image class code review follows...
> 
> - nice impl Marc.  thanks for adding libpng.
> 
> - /me notes carter's aversion to whitespace (a=b instead of a = b, a,b,c
> instead of a, b, c - coding_style standards).  Perhaps we should relax
> them or modify them, but I think we would like the library code to be
> uniform.  Does anyone else care, or am I just being anal?
Sorry, will change that we should follow the whitespace convetion ( i 
dont do it in my code, but the convention should really be followed ;) )
> 
> - lets find a way to let CVS update the LAST UPDATE field, it's too easy
> to forget to do.
Yep, will check that
> 
> - A question on style: do we want to use the stk:: prefix in the
> headers? I vote "nay" since we are already inside the namepsace stk { 
> ... } block.
Ok, i agree, we shouldnt use the namespace prefix inside the namespace!
> 
> - since application is a singleton, you can avoid passing the
> onscreen_surface by referencing application::get()->surface() when it's
> needed.  But that would limit us to drawing to the main surface... which
> might not be what we want (but atm is the only option).
Hmmm, basicly you're right, drawing to another surface is pretty much 
useless, and i only need the onscreen surface for construction of the 
offscreen surface (surface::create_surface Factory function), not for 
the drawing itself, so the only constraint is that i have a pointer to 
one surface of the right type(backend)
> 
> - the change severly broke the build.  surface_fbdev, and several
> test_apps don't build, and test_app segfaults.  we should be careful to
> update ALL the tests and to implement at least error logging
> implementations of new purely virtual methods added to the abstract base
> classes before we commit changes.
If the function is purely virtual and the derived class doesnt implement 
it you get a compile time error, the build has to be broken by something 
else (checking atm)
> 
> 
> Darren
> 
> 
>>
>>_______________________________________________
>>Libstk mailing list
>>Libstk@Óq«LD—"
>>http://www.dvhart.com/cgi-bin/mailman/listinfo/libst
> 
> k