On 27.04.2012 17:37, David Currie wrote:
> Moving Forward... Yes I have added background colours to Fl_Text_Display.
Could you let us see a diff file?
> BUT Warning there are issues : Theory Talk imminent
>
> struct Style_Table_Entry {
> Fl_Color color;
> Fl_Font font;
> Fl_Fontsize size;
> unsigned attr; // attr is so far unused so i used it for Fl_Color bg
> };
>
> After fixing appropriate code, in my (user) structs I put actual colours
> into the attr field,and of course a result. This will cause issues with
> previous
> people's code. These issues of course this can be circumvented by methods
> BUT... Whatever way is chosen
> sizeof(Fl_Text_display) will have to change AND
why would sizeof(Fl_Text_display) change?
> sizeof(Style_Table_Entry) will ALSO have to change even if attr is to NOT
> preserved
why? sizeof(Style_Table_Entry) would be the same if attr were
/replaced with/ (or used as) the background color, wouldn't it?
> How to do the fixes without impacting existing code...
Yup, that's the question...
> Which leads me to...
> Exactly what is an Fl_Color?
> As I understand its either rrggbbii or 000000nn where nn is internally
> defined.
In fact it's either rrggbb00 or 000000ii, where rr, gg, bb, and ii can
all have values from 0 to 255 (unsigned), ie. hex 00 to ff. Of course,
00000000 is black in both "encodings" ((ii=0) = black = (rr=gg=bb=0)).
> Now, in some postings i noticed some would like underline,bold,italic,etc(??).
> FLTK can be made to do bg , but is underline,bold,italic,etc also a
> requirement?
> If so where will the instruction be put?
>
> It occurs to me a different way to do Fl_Color is iirrggbb or ii0000nn
> where one of the bits of ii declares whether the other 24 is rgb or not.
> This way (underline,bold,italic,etc) can be various bits of ii
That would be one possible way to do it ...
> But I don't know which bits of ii are currently unused.
Unfortunately there are no "free" bits in the current Fl_Color scheme,
so this change would definitely break existing code. LOTS of existing
code, especially where rrggbb00 is used in user code. :-(
> maybe Fl_Text_Color : Fl_Color? mm... really all this is a STYLE
??
> Of course changing Fl_Color will cancerise the rest of the system so perhaps
> not.
No way, as far as I can tell...
> Now I personally only need bg Colors not (underline,bold,italic,etc) so i'm
> allright jack.
> But it seems to me this should be complete.
>
> I have further discussion on this and many other matters. My personal opinion
> will be given after I am given instruction on how to proceed.
I can imagine that extending the Style_Table_Entry struct would be the
(probably only) way to go. Existing code could probably be re-compiled
w/o problems. If you take a look at test/editor.cxx: the existing attr
member is ignored completely, and I assume that another member in this
struct wouldn't do any harm.
The problem is with ABI compatibility, so this extension would have to
be guarded with our (new) ABI compatibility preprocessor macro, so that
existing code wouldn't be affected. Whether this would be feasible I
don't know yet. That depends on how much code in Fl_Text_Display would
be affected.
> Who decides which way to jump.
I suggest to open an STR (as proposed earlier), and post your code
changes as diff (patch) files to the STR. You should add another member
to the style struct (IMO) and see what happens. Guarding your changes
with
#if FLTK_ABI_VERSION >= 10302
new or changed code;
#else // if necessary
old code; // if necessary
#endif
would be the way to go for this ABI-breaking new feature.
Albrecht
P.S. ... and I just saw Matthias' proposal to split the attr member in
four bytes, which looks promising and wouldn't break the ABI if done
correctly (might depend on the compiler, however, I don't know). Maybe
we'd need a union or something...
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
