Frans Pop wrote:
On Friday 11 November 2005 13:54, Attilio Fiandrotti wrote:The arches which would need the fix should be: mips, armeb, powerpc, m68k, sparccool! so what should we do? move all PNGs from gtk-rootskel to the architecture specific cdebconf-gtk-udeb after having corrected endianess ?No. rootskel-gtk is architecture specific too.Anyway, I don't really like this option. I'd prefer the solution offered by Davide to fix it in the frontend.
Has somone ever tried to compile GTKDFB 2.8.3 on a PPC? this would let us know if this coluors-related bug shows up only in GTKDFB 2.0.9 or also in GTKDFB 2.8.3. In the first case a patch is needed until we switch to GTKDFB 2.8.3, in the second case also a bugreport should be filed to mike emmel so that this can be fixed later. Anyway i'll try to build a test GTK app that loads a PNG, does colour swap-magic, and then displays it to see if that's enough. By the way, if we use a 256 colours PNG (so that each pixel's colour gets stored into a single byte) shouldn't we get rid of this L/MSB bug?
ciao Attilio