[fltk.development] [RFE] STR #1750: FLUID should not generate casts
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1750 Version: 2.0-feature The code generated by FLUID contains old-style "C" casts. For instance, adding "my_func" with "my_arg" as its second argument generates o->callback((Fl_Callback*)my_func, (void*)my_arg); Now, if my_func has the wrong signature, or if my_arg isn't a pointer, or whatever, the casts allow the code to compile anyway, and the error isn't detected until the application crashes. This adds no value, in fact quite the opposite. PS. This applies to 1.1.x as well as 2.0; the software prevents entering a feature request for 1.1.x Link: http://www.fltk.org/str.php?L1750 Version: 2.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #1750: FLUID should not generate casts
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1750 Version: 2.0-feature The first argument to Fl_Widget::callback is declared to be void(*f)(Fl_Widget*, void*). If I insist on supplying it with void(*g)(Wombat*, Voodoo*), I should bear the responsibility of doing the cast myself. Which I could do, by telling FLUID that the callback function is (Fl_Callback*)(g). I'm not convinced that having the cast generated automatically is useful. Reasonable people may disagree. Link: http://www.fltk.org/str.php?L1750 Version: 2.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #1787: Widget::size() and Widget::position() should honor name lookup
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L1787
Version: 2.0-feature
In fltk 1.1, the non-virtual Fl_Widget::size(w, h) is coded
as { resize(x(), y(), w, h); } Similarly for position().
This constitutes a bit of a trap for the unwary:
class Thing : public Fl_Something
{
void resize(int x, int y, int w, int h) { ... }
void f(int a, int b) {
Fl_Widget::size(a, b); // calls Thing::resize(),
// not Fl_Widget::resize()
}
};
I think it would be preferable to code Fl_Widget::size(w, h)
as Fl_Widget::resize(x(), y(), w, h)
Link: http://www.fltk.org/str.php?L1787
Version: 2.0-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #1774: please makeWidget::do_callback() virtual
> Link: http://www.fltk.org/str.php?L1774 > Version: 2.0-feature > > > I think if you set the callback in the constructor you would achieve > exactly the same functionality? Not really. The OP's idea ties the callback behavior to the dynamic type of the class. Setting the callback in the ctor just sets a default (it can still be reset afterward). I don't think I particularly care for the idea, but it's not the same. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #1774: please makeWidget::do_callback() virtual
> I think if you set the callback in the constructor you would achieve > exactly the same functionality? > Come to think of it, the proposal is rather more powerful. One could use a callback function with a different signature from fltk's, for instance, or call more than one function, or whatever .. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #1820: main: const arguments support?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1820 Version: 2.0-feature For the record, the standard overloaded signature of main() in C++ is int main() int main(int argc, char* argv[]), so, yes, it would be nice for Fl_Window::show() to accept those signatures. Accepting the extra const's would be fine, but it would be disadvantageous for fltk to insist on them. Link: http://www.fltk.org/str.php?L1820 Version: 2.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #1774: please makeWidget::do_callback() virtual
>
> [STR Closed w/o Resolution]
>
> Link: http://www.fltk.org/str.php?L1774
> Version: 2.0-feature
> Fix Version: 2.0-current (r5971)
>
>
> I agree with Bill - I am closing this STR. No offense, but if there are
> some "hard" reasons (I would appreciate if you back it up with some
> arguments) other than "it would be cool" to do what this STR says, please
> post them here and I will gladly reopen it, and discuss it further. --
> Dejan
Here's one reason. There seems to be a lot of interest in
member functions as callbacks. For instance,
http://www.fltk.org/articles.php?L745+I0+T+M10+P1+Qcallback
and
http://www.fltk.org/articles.php?L753+I0+T+M10+P1+Qcallback
The proposal would make it trivial in many cases
class myButton : public Fl_Button {
public:
void do_callback() { member_function(); }
};
I'm not entirely convinced that I'm in favor of the proposal,
but I'm pretty sure it's worthy of a closer look.
- Stan
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk1 and fltk2 merge
[...] > .. (which is why most C++ books > recommend against "using" in application code...) Can you cite some examples? Personally I know of no authors who recommend against "using" in application code, but then again I haven't read a C++ book for a number of years. Perhaps you're thinking of the recommondation to avoid "using" in header files? Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk1 and fltk2 merge
> [EMAIL PROTECTED] wrote: > > [...] > >> .. (which is why most C++ books > >> recommend against "using" in application code...) > > > > Can you cite some examples? Personally I know of no authors > > who recommend against "using" in application code, but then > > again I haven't read a C++ book for a number of years. > > I'd have to go digging (I also haven't read a C++ book in a while) .. I'm totally agnostic about what fltk does with namespaces. However, having kept pretty close tabs on the C++ literature for a long time, I was surprised to read your assertion about "most C++ books..," since, as I said, I know of none, and I'd be interested to learn if current thinking on the subject has changed. For the moment, I'm just going to assume that you're mistaken. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] enums vs. typedef/int
> Greg Ercolano wrote: > >>> Assuming that is a call, what is wrong with var args? > >> > > >>> myWidget->align( FL_ALIGN_LEFT, FL_ALIGN_INSIDE ) > >> [..] > varargs/stdargs never did supply the ability to count the variable > arguments. > [..] It might be possible to achieve the same effect by overloading the comma operator for some Align class, but it would hardly be worth the effort. However, the OP seems to be making the good point that this isn't completely about "enum vs typedef" per se. He's saying, I think, that making users construct bitmasks is a questionable api design, as it exposes too much of the implementation. To see that, just imagine that there were, say, only 2 kinds of alignment, the mutually exclusive Left and Right. Then an enum would be a perfect choice, and we wouldn't be having this discussion, right? A solution that hasn't been proposed yet would be to keep the bitmask implementation private, and provide a public functional interface. align_left() to set the "left" bit, clear the "right" and "center" bits, and leave the others alone. align_inside(), align_outside(), align_wrap(), and so on. Having said all that, I really think it's no big deal either way. Bitmasks are a pretty familiar concept to all but the least experienced programmers; the results of getting it wrong are immediately obvious and easy to fix; few if any problems have been reported in this area. I imagine that there are plenty of other areas far more deserving of development effort. Regards, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2
> I'll throw in my $.02 here > Me too. [..] > The vast majority of widget labels & tooltips are compile time constants Other than your own apps, do you have any evidence whatsoever to support this statement? > anyways, why add the extra overhead that's not needed? > And it integrates wonderfully well with internationalization libraries like > gettext, cstrings, intlize, etc. > Indeed. And how do you internationalize your compile-time constants? Sorry for being grouchy. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2
[..]
>
> My proposal would be (and it solves the problem above as well) to stop
> continue what was internally done already and pull all label code out
> of the widget and simply allow any kind of widget as a "label-child"
> of a widget. The advantages should be obvious: create html based
> complex labels, simple one-text-liners, or image labels. Even the
> existing interface can reain the same.
>
[..]
> Like it?
>
> Matthias
Great idea. Expanding on it a bit, it should make it fairly
easy to allow widgets to have more than 1 label (why not?). Alignment
would become a property of the label rather than the widget, which
seems like a logical place for it anyway, at least to me.
Having done this, I think there wouldn't be any remaining meaningful
distinction between Widget and Group, and the latter could
be eliminated altogether. That would be a Good Thing (tm), imo.
>
>
> Example
>
> > w = new Fl_Value(10, 10, 200, 200, "Hello");
>
> would internally call this:
>
> > w = new Fl_Value(10, 10, 200, 200);
> > w->label(new Fl_Label("Hello"));
>
I think this example argues in favor of the use of a string class.
Otherwise, it might become difficult for users to keep track of
who owns the memory containing the text when it isn't a literal.
Best,
Stan
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2 (alsoconcerning FLTK1)
> > On 25.08.2008, at 14:49, [EMAIL PROTECTED] wrote: > > > > Having done this, I think there wouldn't be any remaining meaningful > > distinction between Widget and Group, and the latter could > > be eliminated altogether. That would be a Good Thing (tm), imo. > > > I have thought about that quite a bit and I am not sure we hould do > that. The functionality is quite different. A group *contains* a bunch > of other widgets. The label however is strictly connected to a single > widget and positioned in relation to the widget, possibly outside of > the widget bounds. > > This is not to say that a widget should not be a group. This can be > useful when deriving new combined widget types. It appears to me > however that the label should be seperate. > Well, knowing next to nothing about the implementation details I'm sort of talking through my hat -- still, as a layman, it's hard to see the problem. A widget/group would contain zero or more other widgets, some of which might be labels. A label's position would be a function of its alignment and its parent's geometry. Of course, that's a view from 3,000 meters up. I'm sure there are issues that I'm not familiar with. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2
[..] > font etc. yes, but I am not sure about alignment - as it is property > relative to something above it, ... True enough, but is not the same thing true of any widget? The widget's position is relative to something (window or screen) above it. > ... so it should be rather property of the > widget. This would also allow assignment of the same label (which looks > the same within its bounding box) to different widget. Agreed, under my scheme it would not be possible for multiple widgets to share a label with different alignments; the label would have to be copied in that case. Is this a common use case, do you think? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2
[..] > Also strictly speaking we would need to distinguish between two alignments: > 1. row indentation (right, left, centre) > 2. position of the label relative to the widget > > The first one is a sole property of the label and if the second (which > is rather what we have in mind here) would be property of widget then > you can share labels between widgets even if they would have different > position relative to them. Think like images - the same image can be > shared by many widgets. > Yes. So perhaps it would be a good idea to separate them? The first group (I think there are more values, btw), would a property of the label, the second maybe handle with a functional interface in the widget like maybe label_left(label), label_right(label) and so on. I'm just sort of thinking out loud here... I do know that on more than one occasion I've wished it were possible to have more than one label on a widget. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Re : Design and future - FLTK2
> [EMAIL PROTECTED] wrote: > > I'm just sort of thinking out loud here... I do know that > > on more than one occasion I've wished it were possible to have > > more than one label on a widget. > > Hmm, but wouldn't it be better in such a case to create > a custom widget, or just an Fl_Group with two Fl_Widgets > in it? > > Then you have more flexible control over label placement, > as opposed to having a larger, more complex Fl_Widget > which would affect everyone's apps.. That's what I ended up doing, and it turned out to be non-trivial to make the result look like the rest of the labels on the screen... I don't remember why, maybe resizing behavior? In any case, I don't see why it's "better" in any way to have to do that. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Comments about the branch1.3-composite
[..] > > That said, I don't know how much existing code exists that tries to > directly manipulate the child() array of a Fl_Scroll widget. I'm sure there's some code (mine) that depends on there being children() - 2 "real" children. I'd be more than happy to get rid of it; hopefully other users feel the same way. Cheers, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: STR #1306: automated safe widget deletion inside the library
> Question to developers: [...] > > > > Fl_Smart_Pointer (maybe even making it public?!) > > I wasn't sure about a good name (my first idea was Fl_Widget_Watch), and I am > open for suggestions. If it's going to be public, I'd suggest avoiding "Smart Pointer," because that phrase historically suggests something a bit different, namely smart_pointer p = new Thing; // this will be deleted automatically Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] callback mechanism
> All I was actually saying is that the Widget::callback API is not type safe > and could one come up with a better API. I think if one rules out using > templates then the answer is no. This is fine, as I said, it's not bad. > > Mike. > An extremely simple way to accomplish this goal is to make Fl_Widget::do_callback() a virtual method. Derived classes could then implement their own (presumably) type safe callbacks, or use functors, or do anything else. The down side is that one would have to subclass in order to obtain type safety in callbacks; that wouldn't be an issue for me, since I use un-subclassed Widgets approximately never, but it may well be one for others. I should note that I'm a big fan of templates, and agree that use of a standard conforming compiler is a reasonable requirement. I just don't think that sort of solution is necessary in this case. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: new convenience function for finding the inner box of a widget
> Would it make sense to make a new method that does the following
> common coding pattern to find the inside area of a widget:
>
> int X = yourwidget->x() + Fl::box_dx(yourwidget->box());
> int Y = yourwidget->y() + Fl::box_dy(yourwidget->box());
> int W = yourwidget->w() - Fl::box_dw(yourwidget->box());
> int H = yourwidget->h() - Fl::box_dh(yourwidget->box());
>
> This seems to be a common coding pattern that could maybe be made
> into something much simpler, like:
>
> int X,Y,W,H;
> Fl::inner_box(yourwidget,X,Y,W,H);
>
Personally, I'd prefer separate methods (in Fl_Widget)
int inner_x() { return x() + Fl::box_dx(box()); }
... etc
Probably just a matter of taste.
Best,
Stan
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Global scrollbar size..
>From an OO perspective, wouldn't it be sensible to have Fl_Scrollbar::size(), rather than Fl::scrollbar_size()? Sorry to arrive on the scene so late. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Input - why is draw() now protected?
[..] > This is documented here: > (quoting from the docs) If you ever need to call another widget's draw method from within your own draw method, e.g. for an embedded scrollbar, you must downcast the embedded widget's pointer to Fl_Widget* and call the virtual draw() method. Fl_Widget *s = &scroll; // scroll is an embedded Fl_Scrollbar s->draw(); // calls Fl_Scrollbar::draw() (end of quote) Just a minor nit. I believe the term "downcast" means something like "use of a cast operator to convert from a base class to a derived class pointer or reference." I don't think the example shows a cast, and if it did it would be an upcast. I'd suggest "... you must assign the embedded widget's pointer ..." Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Input - why is draw() now protected?
[..] > > The intention of this example was to > (a) show the (implicit, type-safe, up-) cast to Fl_Widget > (b) do it without an explicit cast operator to show type safety > > Maybe we should have two examples. > > Other suggestions ? > Apparently the terminology is more ambiguous than I'd imagined. In any case, the example is perfect, so perhaps the idea is to avoid verbiage that might be confusing. How about something like this? If you ever need to call another widget's draw method from within your own draw method, e.g. for an embedded scrollbar, you can do it like this: Fl_Widget *s = &scroll; // scroll is an embedded Fl_Scrollbar s->draw(); // calls Fl_Scrollbar::draw() Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
[..] - note that many of the "C++ features" people ask for > - e.g. std::string, STL, etc... - are not part of the language > definition per se, they are part of the surrounding infrastructure > around the language core Ian, I don't want to be adversarial, nor do I want to engage in a debate about whether or not fltk should use these features. Still, just for a little truth in advertising, please note that the above has not been true for at least 7 years. The first C++ standard, published in 1998, included just about everything people ask for (certainly strings and stl); the 2003 revision added, IIRC, namespaces and a few odds and ends. Use it or don't, but thinking that std::string isn't part of the C++ language is akin to thinking that strcmp() isn't part of the C language. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
[..] > (2) all sorts of Fl_Group's child modification methods (add, remove, > insert, clear, etc.) should be virtual... > > Albrecht As a user, I've often wished that (nearly) the entire Fl_Widget interface was virtual. That's because when I feel that I have to design some sort of custom widget the result usually ends up being derived from Fl_Group. That in turn means that in order to manipulate my widget in even the simplest of ways (change its color, for instance), the caller must know its type, which is quite inconvenient. Just food for thought, I hope. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
[..] > I can understand your problem, but not exactly the example. > It is obvious that virtual methods would help, but in your > _example_ Fl_Widget::color() would be okay, wouldn't it? > > Unless you overloaded the color() method in your derived widget. > Is this what you meant, or am I missing something? > Yes, that's exactly what I meant (sorry, I should have been more clear). When I've derived something from Fl_Group, changing its color is likely to mean changing the color of 1 or more of its components. It's easy to implement that, but, as I said, the caller can't get at it through Fl_Widget::color(). Thanks for listening :) Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Will FLTK use more C++ features?
[..] The only reason why I > didn't add the modified Fl_Scroll widget at that time was compatibility: > this would have broken code that assumes that there are two extra > children in the group. > > Albrecht You might want to poll users on this. The way things stand, any user code that has to peek at the children of Fl_Scroll ends up being a mess, imo. Personally, I'd be quite willing to clean up my own stuff. My vote would be to go ahead and fix it: don't worry about backward compatibility. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Help_View code cleanup and optimizations, attached > 100KB
[..] > I looked at the ANSI C++ spec (ISO 14882), but could not find a clear > definition on this. FWIW, I'm pretty sure there won't be anything in the standard about this. Since the size of a literal string is known at compile time, there's no reason for a compiler to allocate the string simply to satisfy the sizeof operator. That said, there's nothing to prevent a compiler from putting the string "abracadabra" or anything else it pleases into a binary. But why would it do so? It's just a quality of implementation (non-) issue. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] changing long to intptr_t
> [..] On any other platform, > sizeof(long) == sizeof(void*) > When I worked on the AS/400, sizeof(void*) was 256. I don't recall if longs were 4 or 8 bytes long. I have no idea if that factoid is relevant to the discussion at hand, but to assume that sizeof(long) == sizeof(void*) is surely incorrect. windows + *nix != everything :) Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-1.1.10: fl_draw(const char* s, int x, int y)
[..] >One could argue fl_draw() should call fl_font() if no font was set, >to avoid problems. Probably should be discussed, though I think this >has come up before.. can't recall the reason it wasn't changed. Or argue instead that the font should be a parameter for fl_draw(). Just my $.02. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Input_::position(int, int) vs Fl_Widget::position(int, int)
[..] > I would like to change the API for Fl_Input. I have not found a good = > name yet. Any suggestions welcome. We did the exact same thing for = > Fl_Scroll which also overrode position(int, int) > cursor_position() ? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Input_::position(int, int) vs Fl_Widget::position(int, int)
[..] > > That said, I agree that we should change the API, but I would like > to keep the old function as a compatibility wrapper for a while, > as Greg also suggested. > > IMHO we should add a new method, document that the old method > is deprecated, and remove it in the following release after 1.3.x, > i.e. 1.4 or 3.0. > [..] > More comments/proposals? > > Albrecht Regarding the question of providing a migration path, IMO it's oftentimes easier to keep a deprecated class around for awhile, as opposed to some methods. Here that means renaming the existing Fl_Input to Fl_Input_Deprecated (or something) while making the proposed changes to Fl_Input. I think that makes it easier for affected developers to migrate, because the change is more centralized. I haven't got any hard evidence to support this claim of course, it's just sort of a gut feeling. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Input_::position(int, int) vs Fl_Widget::position(int, int)
> > > Regarding the question of providing a migration path, IMO it's > > oftentimes easier to keep a deprecated class around for awhile, > > as opposed to some methods. Here that means renaming the > > existing Fl_Input to Fl_Input_Deprecated (or something) while > > making the proposed changes to Fl_Input. I think that makes > > it easier for affected developers to migrate, because the > > change is more centralized. I haven't got any hard evidence > > to support this claim of course, it's just sort of a gut feeling. > > -1 on this proposal. Everyone's code would break, and they would > be forced to either rename all use of Fl_Input to Fl_Input_Deprecated, > or update the method calls to the new interface. > > D. One way or another, at some point following the API change, code that uses Fl_Input(int, int) to set the text insertion position is going to be broken -- it will have to be updated to use the new interface. (Code that doesn't do so is unaffected). The question in my mind is how best to help affected users get from point A to point B. To that end, I feel like it would be nice to be able to say something like "if your code breaks, you can just replace this class with that one until you get a chance to hunt around for the method calls that you have to change." Just one man's opinion :) Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Makefile and .phony
> I used .phony in documentation/Makefile to force generation > of the doc files manually independent of (not defined) > dependencies. > > I couldn't find another example in our Makefiles and wonder > whether this is standard or a GNU make extension. I could > not find it on the web. Does anybody know? > > If it's not standard, how can we achieve the same with standard > make? > > Albrecht Albrecht, is this what you're looking for? http://www.gnu.org/software/automake/manual/make/Phony-Targets.html I'm pretty sure this feature is specific to GNU, though I believe some other make's have something called ".force" which is the same thing IIRC. (Is there a "standard" make? I think not). In any case, using it should be pretty harmless. It will work as intended if the feature is supported; if not, it will do the right thing unless the user has a file called ".phony" lying around. Happy New Year, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Makefile and .phony
> You can probably get what you want by having a dependency on a > file that never exists: > > always: noSuchFile > build always > > noSuchFile: > : > > # remember that ':' is a dummy command on Unix > Right. That works until some wiseguy creates a file called "noSuchFile" to trip you up. Tricks abound of course. Here's one I find particularly amusing: # We can assume we know the name of our own makefile FORCE=./makefile/nothing always: $(FORCE) build always $(FORCE): I guess that part of the motivation for the .phony (or .force) target is to solve this problem. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Makefile and .phony
[..] > > In any case, using it should be pretty harmless. It will work > > as intended if the feature is supported; if not, it will do the > > right thing unless the user has a file called ".phony" lying > > around. > > Hmm, sounds good. However it's not the file ".phony", but the real > target (in this case "html" and "pdf"). And "html" is also the > directory that is created by doxygen. :-( This works only with > ..phony and if .phony does what it's supposed to. > > Albrecht Yes, reading more carefully I see I may have misled you. If you only use the .PHONY label there may be problems with non-GNU make. Try this though: foo: .PHONY build foo .PHONY: I'm pretty sure that leads GNU make to build foo no matter what, and make's that don't support the .PHONY label to do so unless there's a file called ".PHONY" present. Sorry for the confusion, and HTH, stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk 2.x
> I still keep seeing new folks jumping on fltk2.. > is it perhaps not clear enough on the website that it's still in dev, > not even in alpha, and should only be used by.. other devs? Well, to find that out, you have to go to "Documentation," and from there to "FAQ (HTML)." That might be less than obvious to new visitors, especially considering that there's a top-level "Articles and FAQ's" link, which contains nothing very interesting in this context. So I guess I'd agree that it's not clear on the website. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk 2.x
> > Well, to find that out, you have to go to "Documentation," > > and from there to "FAQ (HTML)." That might be less than > > obvious to new visitors, especially considering that there's > > a top-level "Articles and FAQ's" link, which contains nothing > > very interesting in this context. So I guess I'd agree that > > it's not clear on the website. > > Huh? What about > > Article #825: What are the versions of FLTK? > http://www.fltk.org/articles.php?L825+I0+T+P1+Q > > which is bumped on a regular basis to keep it in the top 10 and > on the first screen of Articles and FAQs. .. Yup, you're right. But what my eyes saw when I went to that screen was a page full of "Weekly Snapshots." The fact that the third article down was different from the rest didn't get processed by my brain. Whether or not my perception is typical I have no idea. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] API naming: future/past tense, etc
> I was noticing while creating the Fl_Tree API I had some second thoughts > about function naming. > > Things like: open() / close() / select() / deselect() all seem obvious enough, > but when testing to see if something is selected, seemed one could go > either present or past tense: > > is_open() vs. is_opened() > is_close() vs. is_closed() > is_select() vs. is_selected() > [..] In the examples, "opened" isn't just the past tense of the verb "open," it's also an adjectival form of that verb. "Open" is itself an adjective as well as a verb, and the meanings of "open" and "opened" (as adjectives) are roughly the same, so either is_open or is_opened expresses the desired concept. "Close" is also an adjective as well as a verb, but its meanings include "nearby" and "lacking air," not the opposite of "open," so is_close sounds weird in context. Similarly with "select." Unless is_select means "it's something really special," like a nice cut of meat, it sounds odd. It doesn't convey the meaning that the thing is, er, selected. In my view, a helpful way to think about this is to drop the idea of tense and concentrate on making sure that the word on the right of the is_ has the intended meaning when used as an adjective. Best, Stan ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Flth3 build error on win32/msys/mingw
[..] > > There are two, being: > > > > A) FLTK3_EXPORT void alert(const char *,...) __fl_attr((__format__ > > (__printf__, 1, 2))); > > B) FLTK3_EXPORT void alert(va_list, const char *); > > const issues aside, (A) says there's an fl_alert() that takes a char* argument and some other arguments, while (B) says there's one that takes some arguments and a char*. Isn't that bound to be ambiguous in some cases? For instance, imagine char* a, b, c; fl_alert(a, b, c) No matter whether the declarations of (A) and (B) include const, won't there always be some combination of const/non-const a,b,c that makes the fl_alert call ambiguous? Or have I missed something? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
