I am going to take liberty here
> 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?
what is a diff? is it the output from diff original new?
>
> > 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?
firstly user defined
Fl_Text_Display::Style_Table_Entry stable[] = {
{ FL_RED, FL_COURIER, 18 }, // A - Red
}; // i assume the compiler puts nulls into each attr because each struct is
only partially defined.
A Style_Table_Entry uses OVERRIDES.
bg_color must exist (somewhere) in each Style_Table_Entry
Fl_Text_display needs to know WHETHER bg colours (in Style_Table_Entry) are
being used
otherwise OLD CODE will pick up non defined info causing random behavoir.
hence bool mDoing_Background_In_StyleTable(or like) must(ought to) be in
Fl_Text_Display.
>
> > 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?
>
You could be right. I think my point was if attr was changed into Fl_Color bg
you still need 2 attr bits for underline and strike-thru.
UNLESS you cram all Fl_Color info + isRgb/ii + 2 bits (underline + strike-thru)
somehow and unscramble them into various bools and Fl_color.This would be messy.
> > 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)).
Ah ha !!
>
> > 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.
Sorry , I thought ii was some special code
>
> 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
>
> ??
bit information about underline/strike-thru pertains to TEXT STYLE not color
>
> > Of course changing Fl_Color will cancerise the rest of the system so
> > perhaps not.
>
> No way, as far as I can tell...
I meant cancerise = LOTS of changes
>
> > 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.
Is {underline,strike-thru) a complete set as Matthias has implied.
> >
> > 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.
>
Having seen it I would guess NOT. What is ABI?
> > 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...
Ok its time for my personal opinion.
We are all trying inventive solutions because of space... this is NOT the way
to go
#define STYLE_ATTR_NONE 0
#define STYLE_ATTR_UNDERLINED 1 // bit 1
#define STYLE_ATTR_STRIKE_THROUGH 2 // bit 2 // someone tell me if these 2
are independent
struct Style_Table_Entry {
Fl_Color color;
Fl_Font font;
Fl_Fontsize size;
Fl_Color bg_color; // although matthias' idea was good this way u can
have a rgb Background
unsigned attr; // still 30 bits over for future
};
Fl_Text_Display::highlightDataBG(same parms as highlightData etc);
(member) bool mUseStyleBg = false but true if highlightDataBG called
Fl_Text_Display::Fl_Text_Display(int X, int Y, int W, int H,Fl_Color
background, Fl_Color selection, const char* l = 0);
now existing old code won't use the bg_color or attr.
Having seen Fl_Text_Display.cxx I would assert that this will not break it
Of course I still have to do the underline and strike-through
but i think there was a Fl_Browser somewhere...
Please explain STR and diff and confirm task.
_______________________________________________
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
