[fltk.development] [RFE] STR #2953: Add append() method to Fl_Multiline_Output and friends

[Greg Ercolano]

DO NOT REPLY TO THIS MESSAGE.  INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.

[STR New]

Link: http://www.fltk.org/str.php?L2953
Version: 1.3-feature


Seems odd that Fl_Multiline_Output and Fl_Multiline_Input
don't have an append() method.

insert(string) is not quite the same, such as if the user has
moved the cursor, but the app wants to append().

Adding this method to Fl_Input_ would effectively add it to the
above two classes, where its absence is felt the most.

I think this method could simply be:

void append(const char s) {
position(size_); // position cursor at end of text
insert(s);   // insert text at end
}


Link: http://www.fltk.org/str.php?L2953
Version: 1.3-feature

___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev

Re: [fltk.development] Article/video on Widget design : How to use type() ?

[Duncan Gibson]

In Fl_Slider.H there are definitions that are used for subclasses:

pre
// values for type(), lowest bit indicate horizontal:
#define FL_VERT_SLIDER  0
#define FL_HOR_SLIDER   1
#define FL_VERT_FILL_SLIDER 2
#define FL_HOR_FILL_SLIDER  3
#define FL_VERT_NICE_SLIDER 4
#define FL_HOR_NICE_SLIDER  5
/pre

although the class documentation doesn't mention the first two, it
uses the values defined in Fl_Valuator.H instead:

pre
// shared type() values for classes that work in both directions:
#define FL_VERTICAL   0 /// The valuator can work vertically
#define FL_HORIZONTAL 1 /// The valuator can work horizontally
/pre

and indeed Fl_Slider makes use of Fl_Valuator::horizontal() which tests
type() against FL_HORIZONTAL.

In Adding and Extending Widgets it says that type() is an arbitrary
8-bit identifier and you can use it for any purpose you want.

It seems to me that if I subclass some existing widgets, such as
Fl_Slider, then I am not completely free to overwrite type() with
my own arbitrary values.

Therefore, are there general guidelines on type(), or do they only
apply on widget-by-widget basis?

D.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev

Re: [fltk.development] Article/video on Widget design : How to use type() ?

[Duncan Gibson]

Me:
 In Adding and Extending Widgets it says that type() is an
 arbitrary 8-bit identifier and you can use it for any purpose
 you want.

 It seems to me that if I subclass some existing widgets, such
 as Fl_Slider, then I am not completely free to overwrite type()
 with my own arbitrary values.

Greg:
   In this case, FL_WINDOW is defined as 0xf0, and the comment
   from FL/Fl_Window.H says:

   .../FL/Fl_Window.H:#define FL_WINDOW 0xF0  \
/// window type id all subclasses have type() = this

   So it sounds like you can do whatever you want.. but only
   with the low order 4 bits if type().

   And that's if you derive from Fl_Widget.

   type() is actually one of those things I try not to mess with
   in favor of using my own type() in my derived classes because
   of the above.
 ...
   I usually try to make my own 'flags' variable in my class,
   and make methods that manipulate it, rather than overload type().

I saw the other comment in the docs about type() that it was a
hold over from the Forms implementation. I was struggling to relate
different uses of type() in different parts of the library to one
consistent whole but it never occurred to me that I might not need
to use type at all.

 Therefore, are there general guidelines on type(), or do they only
 apply on widget-by-widget basis?

   I have a feeling the design is read the source luke;
   look at how the widget you derive from is implemented,
   (i.e. how it makes use of type()) and then design your work
   as an extension of that implementation.

My problem is that in trying to remain Fast and Light, a lot of the
tool kit has avoided using specific enums or class implementations,
and as a result there are a lot of uchar and int fields for types,
which are initialized to 0 and all sorts of overlapping #defines
are called into play in different parts of the library.

I suppose that if you are creating a new hierarchy of widgets then
you are free to implement RTTI within those widgets in any way you
want, as long as you respect the existing use of type().

So would current developer advice be to implement local RTTI ?

Or should we be looking at more modern template or prototype
classes where implementation is passed in? [I'm not sure if I'm
using the GoF Design Pattern nomenclature correcty here].

Cheers
D.





___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev