[interfacekit] Re: Provisional BBitmap, libstorage.so Integration

["Erik Jaesler" <erik@xxxxxxxxxxxxxx>]

>Speaking of which, has anyone perused the bug database for app kit and 
>interface related issues?  Perhaps an understanding of what issues 
>there are with a class before we get too deep into implementing it 
>would be helpful.

It's a great idea and I, along with several other people, have a copy of 
the bug database.  Unfortunately, it's just a bunch of HTML pages, and 
currently no one has a reasonable web-driven engine (or any engine, for 
that matter) for searching and displaying it.  If I had more time, I 
might consider writing either an engine or something to load it into our 
sourceforge bugbase.  Maybe I should bug (no pun intended) Kurtis about 
it ...

e

>>Hi folks,
>>
>>I finished my implementation of a provisional BBitmap and incorporated 

>>libstorage.so into libopenbeos.so. So far everything still seems to 
>>work (or in some cases still doesn't ;-).
>>
>>Regarding BBitmap, I realized, that BBitmap::SetBits() does not only 
>>have a weird specification, but the R5 implementation is also pretty 
>>much broken. For those who aren't familar with it: SetBits() imports 
>>data from a supplied buffer into the bitmap's data, doing color space 
>>conversion, if necessary. Unfortunately the guy spec'ing this methods 
>>must have considered it to be a good idea, that when specifying 
>B_RGB32 
>>as the color space for the supplied data, actually B_RGB24_BIG 
>>formatted data without row padding are expected. Whereas for other 
>>color spaces the respectively formatted (+padded) data are required. 
>>Even more unfortunate is the fact, that the function doesn't implement 

>>this behavior very closely, e.g. if B_CMAP8 is given, padding must be 
>>omitted, but only if the bitmap itself doesn't use B_CMAP8, otherwise 
>>it is needed. Support for B_GRAY1 seems to be completely broken.
>>
>>To deal with these problems I implemented two new, more powerful 
>>methods, namely BBitmap::ImportBits(), which work as expected, and 
>>mapped SetBits() to them, mimicing the original behavior as closely as 

>>reasonable. I would tend to declare SetBits() deprecated, as it is 
>>quite some source of confusion. E.g. the original implementors of 
>>BNodeInfo and BAppFileInfo didn't seem to know, that SetBits() behaves 

>>as it does, for they use it to convert bitmaps from and to B_CMAP8 
>(for 
>>icons), which doesn't work, for the reasons mentioned above. BTW, I 
>was 
>>ignorant myself and used SetBits() when implementing these classes, 
>but 
>>I will fix that tomorrow. I guess the icon methods of BMimeType need 
>to 
>>be reviewed as well.
>>
>>Well, it looks like we're drawing near milestone 2. Only some bits of 
>>BMimeType functionality are missing and the BRoster::FindApp() 
>>methods...
>>
>>CU, Ingo
>>
>>
>>
>--
>Jeremy Rand
>jrand@xxxxxxxx

Necessity is the plea for every infringement of human freedom. It is the 
argument of tyrants; it is the creed of slaves.
        -William Pitt, British prime-minister (1759-1806)

Other related posts:

[interfacekit] Provisional BBitmap, libstorage.so Integration

[interfacekit] Re: Provisional BBitmap, libstorage.so Integration

[interfacekit] Re: Provisional BBitmap, libstorage.so Integration