On 26.03.2012 17:28, MacArthur, Ian (SELEX GALILEO, UK) wrote:
>
>> I also believe that we already had a similar problem. This one can
>> be fixed easily with "friend class Fl_X;" in Fl_Widget.H, like this
>> patch:
>>
>> Index: FL/Fl_Widget.H
>> ===================================================================
>> --- FL/Fl_Widget.H (revision 9300)
>> +++ FL/Fl_Widget.H (working copy)
>> @@ -99,6 +99,7 @@
>> */
>> class FL_EXPORT Fl_Widget {
>> friend class Fl_Group;
>> + friend class Fl_X;
>>
>> Fl_Group* parent_;
>> Fl_Callback* callback_;
>>
>>
>> ... instead of making the enum public. I'm not sure which one is
>> better though, but I'd tend to use the friend statement in this
>> case. Anybody?
>
> Yes - I like the look of that better, and it should have the desired effect.
Indeed, it does.
>> First, I'm not sure at all that adding static class members keep
>> the ABI intact, as Manolo states in the comments to the offending
>> code. This should probably be in fltk.development, but anyway...
>> Manolo, did you really intend to add static class members as opposed
>> to static external variables in the ABI compatible case? ...
>
> Oh, that's a point. That hadn't occurred to me but yes, that will add static
> class members in the "backwards compatible" case. I wonder if that's really
> what we'd want? Would that mean that all wondows get "the same" x,y,w,h
> values then...? Hmm...
Well, the no_fullscreen_* members are there to save the window
position and size before making it fullscreen (AFAICT). In the
intended (ABI breaking) case, this is saved per window, but in
the compatible case, this is saved in static members. Since in
most cases there will (should ?) be only one fullscreen window
at a time, this will be almost as intended. Probably...
But the more important point is whether we can add static member
variables to a class w/o breaking the ABI. I just took a look at
[1], and it seems this is okay. So, using the patch as provided
for this part would probably solve the issue, although I still
don't know whether this is a VC++ compiler bug or whatever.
Albrecht
[1] <http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++>
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
