Re: [fltk.development] Article/video on Widget design : How to use type() ?
On 18.04.2013 15:09, Duncan Gibson wrote: 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. So far this is all okay and somewhat plausible, since all Fl_*Slider widgets inherit FL_Valuator. It would probably be more consistent to define ... #define FL_VERT_SLIDER FL_VERTICAL // must be 0 #define FL_HOR_SLIDER FL_HORIZONTAL // must be 1 or something like that. At least this correlation should be mentioned in the docs... 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. ... except as noted elsewhere (see Greg's posting about FL_WINDOW and such). 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. Yep, within one widget hierarchy (e.g. all widgets derived from Fl_Valuator) all widgets need to respect the type() values of all other widgets in the same hierarchy. That's *really* a bad thing IMO: in fact it means all other widgets in this (part of the) widget hierarchy *now and in the future*. So you are not free to derive your own widgets and assign different type() values if you don't know what values will be assigned in other sibling widgets, maybe later. And who can look into the future? Therefore, are there general guidelines on type(), or do they only apply on widget-by-widget basis? I don't think that there are any general guidelines. However, as things are, it would be consistent to use type() values from scratch in own widget hierarchies, if you need a type for discrimination of different widgets in your own hierarchy. However, if you derive from Fl_Valuator, then you're bound to its set of type() values. Seeing the problems as described, it could be useful not to derive from Fl_Valuator. However that's something I wouldn't want to decide based on the type() values used, but more on functionality. That said, what did the author of the FLU sliders (as mentioned by Ian in a later posting) do? Did he add other type values? What if someone uses FLU in his application, and we add conflicting type values for our new slider widgets in the same (Fl_Valuator-derived) widget hierarchy ??? One more note: it seems useful to (re)use FL_VERTICAL and FL_HORIZONTAL for your slider class(es). However, they are defined in Fl_Valuator.H, although they are not defined inside the class (name space). So we could maybe move them 'up' to Fl_Widget as a more general class, but then there might be other conflicts (with type values 0 and 1 in other classes that don't *mean* FL_VERTICAL and FL_HORIZONTAL, resp.). Otherwise, if you wouldn't derive from Fl_Valuator, FL_VERTICAL and FL_HORIZONTAL should not be used - I wouldn't like the idea to have to include Fl_Valuator.H if I don't use any of its (derived) classes. Difficult to say what's best ... Albrecht ___ 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() ?
On 18.04.2013 18:52, Greg Ercolano wrote:
I usually try to avoid type(), because while looking at
FLTK's own code, I've seen coding techniques that disagree
with the above, namely:
Fl.cxx:if (w-type()=FL_WINDOW) {dx -= w-x(); dy -= w-y();}
Fl.cxx: if (p-type() = FL_WINDOW) break; // don't do the unmap
Fl.cxx: if (type() FL_WINDOW) {
Fl.cxx: while (wi-type() FL_WINDOW) {
Fl_Group.cxx: if (o-type() FL_WINDOW) return o-handle(event);
Fl_Group.cxx:if (type() FL_WINDOW) {p[0] = x(); p[2] = y();} else {p[0]
= p[2] = 0;}
Fl_Group.cxx:if (type() FL_WINDOW) {
Fl_Group.cxx:if (type() = FL_WINDOW) dx = dy = 0;
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().
That's not entirely correct, for some interpretation of correct.
0xF0 means decimal 240, so there's a bunch of 240 values (0-239)
you can use, whereas only with the low order 4 bits seems to assume
only 15 distinct values. However, it is correct that you can only use
4 bits if you want to base your type() distinction on something like
a bit mask - then you can only use 4 bits.
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.
Do you mean type() literally, or does it stand for a differently named,
but similar method? I would not recommend to overload type() in a way
that it uses another member variable in a derived class. Although it
is possible, it could lead to some confusion. And since the FLTK core
makes use of type() for some decisions, it must be clear that FLTK
always uses Fl_Widget::type(), whereas your class would always have
to make sure that it uses YourClass::type(), i.e. you can't use a
(Fl_Widget *) pointer and use type() with this (because it's not
virtual, but this is so by design).
And when you derive from a base class that has decided to make
use of type() a certain way, you're kinda bound to the parameters
of its use in your derived class.
True.
I usually try to make my own 'flags' variable in my class,
and make methods that manipulate it, rather than overload type().
Ah, okay, I should have read this before I wrote my comments above. ;-)
I guess you could override type() with your own, and manage a
uchar type_ in your derived class so that the user can use type()
on your class without affecting the base class.
See above, I wouldn't do this.
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.
As much as object oriented programming tries to make a black box
so that one shouldn't have to be concerned with implementation
internals, when deriving classes you kinda have to.
Yep, unless all is documented so well that you don't need to. You
can't access the source code for libraries you don't get as sources,
for instance. And who would try to read the sources of system libs,
or X11, for instance.
In fltk it's often important for instance how base classes
implement handle(), as often your derived class has to take
the base class's implementation of handle() into account
to keep the code details in sync.
I try to compare the code implementation with the docs
to see what the general philosophy is, and then try to design
along a line between the two. I try to get as intimate as
possible with the implementation of the base class, so the
derived widget becomes an extension not only in function
but implementation as well.
Theoretically you shouldn't even *try* to know how it is implemented,
because one OOP principle is that implementation can change, as long
as the interface is kept stable, but in practice ... (you said it).
Albrecht
___
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() ?
On 18.04.2013 23:44, Duncan Gibson wrote: I saw the other comment in the docs about type() that it was a hold over from the Forms implementation. Please ignore Forms compatibility. We're going to remove this, and AFAICT Matt has removed everything Forms related in FLTK 3.0. I was struggling to relate different uses of type() in different parts of the library to one consistent whole There is no consistent whole, it's always only used consistently in one (part of the) widget hierarchy, as written elsewhere. but it never occurred to me that I might not need to use type at all. I believe that you don't need such things like type() in a widget hierarchy if you design everything correctly (in the OOP sense), maybe with virtual methods and such. However, in (FLTK) practice we can see that the base class often has a draw() method that must know which derived classes may exist, and for which one of these it is called in /this/ instance of an object. This can lead to such problems as we can see in this thread. 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(). True. So would current developer advice be to implement local RTTI ? I don't know. 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]. Do it as fits best, I guess. A moderate use of type() within a new class hierarchy may be okay, but adding classes to the Fl_Valuator hierarchy (with pseudo RTTI via type()) might result in problems. Maybe. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] [FLTK 1.3] Filesystem list inFl_File_Browser(STR#2935)
On 16.04.2013 11:01, MacArthur, Ian (Selex ES, UK) wrote: Michael Baeuerle wrote: I will add the test information to the STR and update the patch. Done. All - I'm looking at this patch #2935 and it looks OK, and Michael reports that it works well on the problem targets. I find it does not break my linux builds. I propose to apply this patch sometime soon'ish - hope to get to it during the course of today. Anyone have any objections? Not from me, please go ahead. Thanks. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selecting low and high values within min/max range
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature Well, Greg said it all.. ;-) That said, here's one addition from me. It'd be good to have the widget look like the other FLTK slider widgets for integration with other sliders. However, I'd also like it to have its own fancy look. Maybe both (selectable) would be good to have. (The ultimate option would be to provide a hook to enable own draw() functions, but that's probably too much effort.) So I think that making this DoubleSlider widget being able to use only one slider would be simple and offer an opportunity to use it (and its maybe different look) as a normal lider widget as well, depending on an option or flag - need not be its own class name. Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) +1 for renaming to w instead of win (or maybe widget to avoid name clashes with w(), but that's not important here, IMO) +0 for maintaining constness (yes, I mean + zero). constness doesn't gain much here, and since compilers become pickier more and more, there is the danger of getting a warning when it's cast away for as_window(), as Ian wrote elsewhere. If not now, then maybe later. We're only calling const methods anyway, as x(), y(), window(), and this code is not subject to be changed in the future. Using const here would IMHO only protect ourselves from adding code that would modify the widget in question, and as said before, we won't add more code. Just my 2 (â¬)ct. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature Roman, this looks like a good idea, I recommend adding it, however with two caveats. I'll post them in followup messages. WRT ABI issues: adding flags and static methods doesn't break the ABI, so we should be safe here. Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature #2: I believe that the following part of this proposal should not be added as given: change code in function Fl_Menu_::picked() from line approx 271: ... else if(!(value_-flags Fl_Menu_Item::no_close_flags() (FL_SUBMENU | FL_SUBMENU_POINTER))) // do not execute parent's widget (common) callback if there is no direct menuitem callback assigned // and menu is not closed and isem is just a submenu (no valid item picked) do_callback(); } It think that not calling a callback for submenus is unrelated to the option not to close the menu when the item is clicked on. What if someone wants a callback when a submenu is clicked on, but doesn't want the menu to be closed? Setting the FL_MENU_NOCLOSE flag would prevent the callback from being called in this situation, if I understand correctly what is going on here. I don't really know why one would want a callback to be called when a submenu gets selected, but I can imagine that you could change the submenu before it is popped up (or popup()ed? ;-)). Also, I believe the code could be changed to be more clear, but maybe you did it as proposed because you had compatibility in mind. Wouldn't something like this be better? if ( !((value_-flags Fl_Menu_Item::no_close_flags()) (FL_SUBMENU | FL_SUBMENU_POINTER)) ) Well, I really don't grok it entirely now, but I hope you got my idea. This should be discussed further, and maybe a test programm would be fine. Roman, could you post one and describe a procedure to test what you want to achieve, so that we can see the effect when implementing it? Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
Hi Roman,
1) I didn't write that I didn't want that global flag, and I understood
what you wanted to achieve with it. That's all okay so far.
2) It was not the point that adding a new flag is unnecessary as it can
be done by the user. My point is: we should *avoid* to make the user set
any flags in the menu items except those that are defined in the library.
One argument is to be free to define other bits for new use cases within
the library w/o risking damage if a user defined exactly this bit for his
purposes (as it would be possible with your primary proposal). Therefore I
am for adding this extra bit to the enumeration within the library. Only
that was the reason to do it like Greg proposed, everything else just like
your proposal would be okay with me.
3) Yes, you're right, my code was bad - I was in a hurry. But I still
believe that the callback issue is another issue unrelated to the no_close
flag, so this shouldn't be mixed. However, I don't have the time to think
further about it now, so I'll post later regarding this.
4) to your new code proposals: okay with one exception: if we use the
FL_MENU_NOCLOSE flag, then it would be handy to change this one:
void Fl_Meu_Item::no_close_flags(int m){menu_no_close_flags_ =
m|FL_MENU_NOCLOSE;}
so that FL_MENU_NOCLOSE will always be set in the flags for testing.
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widgetthat returns its top-level window
On 12.04.2013 18:57, Greg Ercolano wrote: Albrecht We're only calling const methods anyway, as x(), y(), window(), Albrecht and this code is not subject to be changed in the future. Yes, though for some reason as_window() is not const, (it probably should be), which is why that cheat is necessary at the end there. Maybe using const_castFl_Widget*(w)-as_window() is better, which is what I decided to go with in top_window_offset().. will check. Using const_cast is only another way to write it, but means the same essentially, doesn't it? However, if some compilers wouldn't flag a warning for const_cast but would for the old-style cast, then we could maybe use it, but according to the CMP this shouldn't be used for fltk 1.1 code, however it should be used for 2.0 code. 1.3 code is not (yet) specified, so we'd have to make a decision about this first. Concerning as_window(): ISTR that the first proposal was const, but for some reason someone removed the const, but I'm not sure about it. Note in manolo's implementation, const is cast away at the top at the declaration of the variable, but I just switched it to const and cast const away only at the place where it was needed, at the as_window() call. So this does two things: 1) Keeps the variable const so one can't later add code like w-label(yoo hoo); without getting an error.. hey, it could be more subtle ;) Yep, that's what I wrote with other words, isn't it? You cited it above. I don't think that such a tiny method will ever be changed. However, I'm not against your proposal, please go ahead... 2) Highlights exactly where the cheat is needed (at as_window()) so if as_window() ever changes in the future to be const, it's easier to find and remove the const cast-away. Fair point. Is there a reason as_window() and friends (other virtual implementations) are not const methods? Fl_Window::window() is. You mean: Fl_Window* Fl_Widget::window() const is, right? Other than what ISTR (see above), I don't know. Probably Fl_Window* Fl_Widget::window() could be const as well, but can we change it w/o breaking the ABI? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fl_Widget::as_window() and friends const ? [was: STR #2948: Add a method to Fl_Widget that returns its top-level window]
On 12.04.2013 19:44, Albrecht Schlosser wrote:
On 12.04.2013 18:57, Greg Ercolano wrote:
Is there a reason as_window() and friends (other virtual
implementations) are not const methods? Fl_Window::window() is.
You mean: Fl_Window* Fl_Widget::window() const is, right?
Other than what ISTR (see above), I don't know. Probably
Fl_Window* Fl_Widget::window() could be const as well, but
can we change it w/o breaking the ABI?
Hmm, I'm not a const and ABI specialist, I mean I don't know
all the implications that would arise if we changed this method.
That said, what about one additional method for each of these
that is const and returns a const pointer, like this patch:
Index: Fl_Widget.H
===
--- Fl_Widget.H (revision 9869)
+++ Fl_Widget.H (working copy)
@@ -964,6 +964,7 @@
\see Fl_Widget::as_group(), Fl_Widget::as_gl_window()
*/
virtual Fl_Window* as_window() {return 0;}
+ virtual const Fl_Window* as_window() const {return 0;}
/** Returns an Fl_Gl_Window pointer if this widget is an Fl_Gl_Window.
Index: Fl_Window.H
===
--- Fl_Window.H (revision 9869)
+++ Fl_Window.H (working copy)
@@ -459,6 +459,7 @@
// Note: Doxygen docs in Fl_Widget.H to avoid redundancy.
virtual Fl_Window* as_window() { return this; }
+ virtual const Fl_Window* as_window() const { return
const_castFl_Window*(this); }
/**
Changes the cursor for this window. This always calls the system, if
--- end of patch ---
This compiles well, but doesn't address all the siblings like as_group()
etc.
Note that I used const_cast that needs to be discussed as well.
Opinions anybody? Would this solve the problem? Would it break the ABI?
Other variants needed?
Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] FLTK-1.3 group button menus inwrong placewherearranged
On 12.04.2013 10:46, MacArthur, Ian (Selex ES, UK) wrote: 2. This program still uses Fl_Pack. I had originally tried Fl_Pack to see what it would do. When changed over to Fl_Group, buttons lower in the window don't respond properly. It seems like the clicked button and above are the only responding buttons. I quit playing with Fl_Group since I couldn't remedy the unpredictable buttons. Sounds like you have put the buttons outside the bounding box of the group, so they don't get any key clicks. You need to ensure the parent group is sized to properly contain its children, or Bad Things can happen. That's exactly what I had thought when reading this. To Marty: please try again with Fl_Group, because Fl_Pack won't do what you want, unless you use Fl::add_timeout() for the popup. Besides looking at the correct bounding box issue, you must only calculate the new button coordinates after changing children inside the group. Only if you want predictable resizing behavior, then you must also call init_sizes() after rearranging children. That should really be easy to implement... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [HIGH] STR #2946: PNG not loaded
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 So your app is compiled and linked with different png libraries. The FLTK libpng is 1.5.10, so I assume that your installed library is 1.6.1. There are two choices: (1) Let FLTK find the installed lib by configuring w/o --enable-localpng, but this might not work, because the internal code may not be compatible with the newer installed library. If it works, however, I'd recommend this one. (2) Use the FLTK PNG *header* files when *compiling* your app. You may have to tweak some include statements, however, and I can't tell you how, since this may be something in your app. Or something like this. BTW: this is not a FLTK bug, but more a user question about linking with the correct libs. Please ask further questions in fltk.general. This STR will be closed soon... Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2946: PNG not loaded
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 No problem, sometimes you don't know, but generally it's better to ask in fltk.general first. Closing this now. Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2946: PNG not loaded
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 Fix Version: 1.3.2 Link: http://www.fltk.org/str.php?L2946 Version: 1.3.2 Fix Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] svn access / fltk.org changeover?
On 10.04.2013 18:51, Greg Ercolano wrote: On 04/10/13 00:01, Duncan Gibson wrote: and I no longer remember my subversion access password] FWIW, I believe there's a process for resetting your password at the right hand side of the login page: http://fltk.org/login.php Thanks for the pointer, Greg That's how I revitalized access from this, my work, address. However, I don't remember my subversion access password [from home] being the same as my mailing list / login account, but I could be wrong. Ah, could be. AFAIK, I don't think regular devs can manage svn user access, or if there is a way I don't know it. Mike (and probably only Mike) can set developer status, and if you have dev. status, you also have write access to svn - if not automatically, then at least because Mike does it so. AFAIK. I do know back in Dec 2011 Mike announced the fltk.org site was being planned to move off easysw.com, and I think it was supposed to move to a site Torsten Giebl found called filemedia. Not sure that transfer happened, as IIRC filemedia required their logo be on our website's main page, e.g. http://www.syntheticsw.com/~wizard/tmp/fltkorg_top_banner.png ..and I don't see that mod currently. Unless I missed it, I don't think there was an announcement as to the changeover. I don't think that anything happened so far... I'm actually not sure now if Mike is still managing fltk.org on a new site pointed at by Torsten, or if Torsten is now managing things. Kinda curious who the main contact and emergency contact (hit by a bus scenario) is for fltk.org.. anyone know? Most of the data could probably be recovered with the nightly backups that the dev's can access and save somewhere - as long as the site still works, at least. But I don't know either, whether anyone else has direct access to the server. whois fltk.org now claims that Mike is the tech and admin person, and Carl Thompson is the registrant. I just checked: this was the same as of Dec. 2011. Expiration date is now Feb. 2014. Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Patch looks good, except what Manolo wrote already. We should remove this old and error-prone w-type() = FL_WINDOW from the entire lib in favor of as_window(). WRT window_offset() vs. top_window_offset(): I strongly vote for the latter and consistent naming, i.e. top_window() and top_window_offset(). +1 for the patch with mods as written. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) Comments? Yes: Great, thanks. BTW: good catch that top_window_offset() should be a Fl_Widget method. I didn't realize that it was Fl_Window:: before. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Caps Lock detection
On 10.04.2013 19:05, Greg Ercolano wrote: If you wrote the code in pure Xlib, you'd still encounter this problem, the workaround apparently being to access the LEDs directly I think. Anyway, not sure if hacking X11's event structure in the case of capslock is a good idea or not -- seems like an X11 bug to me, and not sure if it's appropriate for FLTK to try to cover that up with a hack. Would like to hear what other devs say. There's a (big?) warning that using another Xlib call to get the key state has at least two drawbacks: (1) Speed. It's slow because it needs another client/server roundtrip. (2) AFAIK all you can get is the CURRENT keyboard state. This can differ from the state as seen (or should be seen) when processing events, since this is an asynchronous call. I.e. event handling can be three key presses and two releases behind, and calling for the current state would give you no better values. Note that speed may not be so problematic, if you're working with X on a local machine, but X is designed to be a remote protocol over tcp/ip. This is all off the top of my head, and ISTR that I read such a warning in the FLTK code somewhere, but I don't have personal experience with native X11/Xlib calls. The same problem arises with Windows, BTW, although tests showed in this case that it seemed to work. So, if there is not an OBVIOUS bug in the FLTK code WRT direct event handling, I'd recommend leaving it as-is. We should not try to fix one bug and get another unpredictable behavior. The intended behavior (warning about CapsLock in password entry fields) can be achieved even when the warning is issued when a real key press arrives, so it's usually not too late - and this works reliably, as my tests and Ian's tests seem to show. -- Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2942: Buttons keep the same color when clicked
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2942 Version: 1.3-feature Fix Version: 1.3-current No, sorry. We won't set anything (e.g. selection_color) w/o the user explicitly requesting it. This would also break apps that have the colors set as-is. The usual default is to use the selection_color(), and this is taken from a system color. As I wrote before, the setting you proposed would also be sub-optimal for other FLTK schemes. I'm closing this STR now. Link: http://www.fltk.org/str.php?L2942 Version: 1.3-feature Fix Version: 1.3-current ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: method to find top level window?
On 06.04.2013 07:55, Greg Ercolano wrote:
Is there a method that returns the top-level window manager window
for the current widget?
window() is not it; this just returns the parent window
which won't be the top-level window when there are
windows within windows, eg:
Fl_Window *top = new Fl_Window(..);
top-begin();
Fl_Window *sub = new Fl_Window(..);
sub-begin();
:
It seems unlikely we don't have such a thing, but I think
supporting nested windows is something recent, and I see
places in our code that do inline loops instead of calling a method.
If there isn't such a method, would like to suggest we add one,
the code being something like:
---
Fl_Window *Fl_Widget::toplevel_window() const {
Fl_Window *top = window();
while (top top-window()) top = top-window();
return top;
}
---
Comments?
ISTR that we discussed adding such a method a while ago, and that
it probably wasn't done for some reasons. However, thinking about
it, I don't know what this might have been. Too simple ? What, if
the top-level window still has a (non-window) parent widget? Does
it matter ? I don't know.
Anyway, since it's not much code, could we probably add it to the
header file as an inline method ? I think so. If there were a vote
request, my vote would be +1, unless there are reasons not to do
it that I don't know of (yet). Other opinions, votes?
BTW: toplevel_window() doesn't look bad, but what about top_window().
Less typing ;-)
Albrecht
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] FLTK-1.3 group button menus in wrong place whe rearranged
On 08.04.2013 01:27, marty moore wrote:
What happens:
1. When the first button is clicked, and the delete option is selected, the
other buttons disappear, but the menu is where the clicked button used to be,
not where the button is actually located.
2. If the add option is selected from the popped up menu, the menu is
located on top of the new button.
3. Continue selecting add, and the all of the menus appear over the first
added button.
4. If escape is pressed, or the button is clicked again to cancel the menu,
the buttons and menus seem to act properly again.
So it appears that when a previous button in the group is removed, the
button's menu position doesn't get updated.
Is there any way to update the menu position, other than manually with
popup(x,y) or pulldown(x,y,w,h)
Your problem lies buried in Fl_Pack. This is not designed to be
updated dynamically the way you try to do it, or at least this
doesn't work as expected. The reason why this is so is because
Fl_Pack rearranges its children only when it is draw(), but this
doesn't happen when you might expect it to do.
In your code, this part is called in a callback:
else if ( op == DEL )
{
cout onMenu 2: deleting endl;
int i = G1-find(w);
clearTo(i);
WIN-redraw();
Here you ask the window to be drawn, but this doesn't happen
until the event loop is reached again, either by returning
from the callback or ... (see below).
cout onMenu 3: poping menu endl;
sb = (Sbut*)G1-child(0);
sb-popup();
Here the menu pops up, but Fl_Pack still knows of the old
button position(s), hence the unexpected position. But this
popup() call also includes running the event loop again, until
the menu will be closed. Now you will see the new button
position(s), but the menu stays at the old position.
There are two ways to overcome this:
(1) I recommend not to use Fl_Pack, but instead calculate the
new button positions yourself (use a class derived from Fl_Group),
and everything ought to work as expected if you calculate the
positions before calling popup(). Note that calling init_sizes()
has nothing to do with Fl_Pack's and/or Fl_Groups position
calculations, unless you resize() the group or window. Hence it
would be useful to call init_sizes() after re-positioning the
buttons in the group.
(2) I don't recommend this one, but it should give you a clue
whether I'm right with my assumption. ;-) Instead of calling
popup() in the callback, as you did above, start a timer with
a short time, say 0.3 seconds, and popup() the menu in this
timer callback. If you did this, then the window's draw() would
happen before the timer callback runs, and therefore Fl_Pack's
draw() method would have adjusted the positions already. Although
this might look as the easier part, I don't consider this good
style, and if you extend your program later, Fl_Pack will maybe
not be the widget/group you want to use because of its restricted
features.
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK-1.3 group button menus in wrong place whe rearranged
On 08.04.2013 11:58, Albrecht Schlosser wrote: There are two ways to overcome this: .. at least .. (1) I recommend not to use Fl_Pack, ... (2) I don't recommend this one, but it should give you a clue ... (3) You might also recalculate the button positions in your callbacks/functions to modify the group, i.e. clearto() and/or onMenu(), but you would have to do it in the same way as Fl_Pack would do it later in its draw() method. This way, you'd have the popup() work depending on the new positions, as you expect. The point why I don't recommend this either is because you'd have to *know* how Fl_Pack calculates the positions. However, this is not trivial, but could work with your simple buttons. But if you do this anyway, why not create an own group class? You could also overwrite the resize() method and rearrange your buttons while the window/group is being resized. Then you would be able to call resize() after you rearranged the group's buttons, and that's it. I like this more than recalculating positions in draw(), because (a) it's less overhead, and (b) you avoid the problems you see in your program. So I still recommend (1). Here's a small amendment to my previous posting. I wrote: Here the menu pops up, but Fl_Pack still knows of the old button position(s), hence the unexpected position. In fact, Fl_Pack is not involved here. It's the button widget that still knows its old position, because Fl_Pack didn't rearrange the children yet. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK-1.3 group button menus in wrong placewhe rearranged
Ian, I agree with you 100%, but want to add one comment. On 08.04.2013 12:28, MacArthur, Ian (Selex ES, UK) wrote: Albrecht also suggests a workaround based on timers. I think this might work out pretty well, though I'd consider having my own derived Fl_Pack (or similar container widget) that, in its derived draw() method, sets a flag to tell whether the draw has actually been enacted (and hence the sizes properly recalculated) and have that flag cleared down by the callback that triggers the timer. The timer can then poll until it sees that the widget has been drawn (the flag is re-set) and thence that the sizes ought to be correct, for popping up the menus now... Well, something like that... Yep, this was suggested as a workaround only, either to see how it can be done (just for learning), or if one really wants to use Fl_Pack. Deriving from Fl_Pack (as I assume you meant above) for another container widget and do the polling makes things even worse, but I assume that you only wrote it for the same reasons as I did. My personal opinion is that users should NOT try to resize widgets in their draw methods, since this will lead to problems earlier or later. The problems with Fl_Pack result just from the fact that it tries to allow its children to resize in their respective draw() methods, and hence it *must* recalculate positions after calling the children's draw() methods - thus the only way to do it is in its own draw() method. My suggestion in my other posting about resizing/rearranging children in resize() seems to be much better for user code, and I'm using it in my apps successfully. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] incorrect button label text in Fl_Pack
On 03.04.2013 08:59, Edzard Egberts wrote:
3. When the add menu item is clicked, a new button appears, but has
garbage text.
Garbage text sounds like a well known problem:
void set( string str ) { label(str.c_str()); }
label() doesn't copy the string (but there is a copy_label()), but just
saves the given const char*. But your string is local, so the content
vanishs fast.
True.
There are several solutions, most easy seems to be:
void set( string str)
{
delete[] label();
Please *DON'T* do this (above). The widget knows better if it
had copied a label before (with copy_label()) or not (either the
NULL pointer or a pointer assigned with label()). And, you don't
know how the copied string was allocated (in fact it's done with
strdup(), so delete[] is wrong), and the following copy_label()
call would again call free() since you can't reset the internal
pointer and flag.
copy_label(str.c_str());
This is just enough! Let the widget do the rest!
So there is no need to use an own method, unless you want to use
the string type and not use copy_label(str.c_str()) in the program
code directly.
--
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 05.04.2013 22:02, Howard Rubin wrote:
Thanks for the quick reply. Here's what I have now. It's reporting the
opposite of of the Caps Lock state. In other words, (Fl::event_state()
FL_CAPS_LOCK) is zero when Caps Lock is on, and nonzero when it's off.
Is that what you meant in your last message?
I'm less than enthusiastic about displaying the 'Caps Lock is on'
message when the test in the code says it's off.
Is there really no alternative?
Well, there should be a better way, but it looks like you found a bug
or at least some inconsistency. I'll post two different modified test
programs (derived from yours) that do unfortunately show inconsistent
behavior on Windows and Linux on my test systems, i.e. Windows 7 and
Linux Ubuntu 12.04 an a Virtualbox VM. Maybe someone can test it on
a real Linux box and on Mac OS X ?
Howard, what's your environment ?
Here's #1 that shows more events and gives a clue how to handle the
key, and it works well on Windows, but doesn't on my Linux VM:
$ cat capslock.cxx
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Button.H
#include FL/Fl_Secret_Input.H
#include FL/names.h
#include iostream
class myWindow : public Fl_Window {
public:
myWindow(int x, int y, const char* l) : Fl_Window(x, y, l) { }
virtual int handle(int event) {
if (event == FL_FOCUS) {
std::cout event = fl_eventnames[event] ... ;
if (Fl::event_state() FL_CAPS_LOCK)
std::cout WARNING: CAPS LOCK is set;
std::cout std::endl;
return 1;
}
if ((event == FL_SHORTCUT || event == FL_KEYDOWN || event ==
FL_KEYUP)
Fl::event_key() == FL_Caps_Lock) {
std::cout event = fl_eventnames[event] ... ;
static int n = 0;
if (Fl::event_state() FL_CAPS_LOCK) {
std::cout caps lock ++n std::endl;
} else {
std::cout caps unlock ++n std::endl
std::endl;
}
return 1;
} else
return Fl_Window::handle(event);
}
};
int main(int argc, char* argv[]) {
myWindow* win = new myWindow(300, 200, );
new Fl_Secret_Input(20, 20, 100, 20, );
new Fl_Button(20, 120, 100, 20, Test);
win-end();
win-show();
return Fl::run();
}
// end of file
Compilation and output on Windows:
$ fltk-config --compile capslock.cxx ./capslock.exe
g++ -I/fltk/svn/fltk-1.3 -I/fltk/svn/fltk-1.3/png
-I/fltk/svn/fltk-1.3/zlib -I/fltk/svn/fltk-1.3/jpeg -mwindows -DWIN32
-DUSE_OPENGL32 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -o 'capslock'
'capslock.cxx' -mwindows -static-libgcc -static-libstdc++
/fltk/svn/fltk-1.3/lib/libfltk.a -lole32 -luuid -lcomctl32
event = FL_FOCUS ...
event = FL_KEYDOWN ... caps lock 1
event = FL_KEYUP ... caps lock 2
event = FL_KEYDOWN ... caps lock 3
event = FL_KEYUP ... caps unlock 4
event = FL_KEYDOWN ... caps lock 5
event = FL_KEYUP ... caps lock 6
event = FL_KEYDOWN ... caps lock 7
event = FL_KEYUP ... caps unlock 8
event = FL_KEYDOWN ... caps lock 9
event = FL_KEYUP ... caps lock 10
event = FL_KEYDOWN ... caps lock 11
event = FL_KEYUP ... caps unlock 12
You can see (or guess) that the CAPS LOCK state is updated *before*
the handle message is called on FL_KEYDOWN events, if CAPS LOCK is
being turned ON, but *after* the FL_KEYDOWN event, if it is turned
OFF. That's why the program shows the caps unlock message only on
FL_KEYDOWN events.
Obviously it's a little difficult to get the state of these toggle
keys in a platform independent way, and hence this doesn't seem to
work well on my Linux VM:
$ fltk-config --compile capslock.cxx ./capslock
g++ -I/home/albrecht/svn/fltk-1.3 -I/home/albrecht/svn/fltk-1.3/png
-I/home/albrecht/svn/fltk-1.3/zlib -I/home/albrecht/svn/fltk-1.3/jpeg
-I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -o 'capslock'
'capslock.cxx' -static-libgcc -static-libstdc++
/home/albrecht/svn/fltk-1.3/lib/libfltk.a -lXext -lfontconfig -lXinerama
-lpthread -ldl -lm -lX11
event = FL_FOCUS ...
event = FL_KEYDOWN ... caps unlock 1
event = FL_KEYDOWN ... caps lock 2
event = FL_KEYUP ... caps lock 3
event = FL_KEYDOWN ... caps unlock 4
event = FL_KEYDOWN ... caps lock 5
event = FL_KEYDOWN ... caps lock 6
event = FL_KEYUP ... caps lock 7
event = FL_KEYDOWN ... caps lock 8
event = FL_KEYUP ... caps lock 9
event = FL_KEYDOWN ... caps unlock 10
event = FL_KEYUP ... caps lock 11
event = FL_KEYDOWN ... caps lock 12
event = FL_KEYUP ... caps lock 13
event = FL_KEYDOWN ... caps unlock 14
event = FL_KEYDOWN ... caps lock 15
event = FL_KEYUP ... caps lock 16
event = FL_KEYDOWN ... caps unlock 17
event = FL_KEYDOWN ... caps lock 18
event = FL_KEYDOWN ... caps lock 19
event = FL_KEYUP ... caps lock 20
event = FL_KEYDOWN ... caps lock 21
event = FL_KEYUP ... caps lock 22
event = FL_KEYDOWN ... caps unlock 23
event = FL_KEYUP ... caps lock 24
Re: [fltk.general] Caps Lock detection
Correction: On 06.04.2013 02:10, Albrecht Schlosser wrote: [... about compiling and running program #1] ... event = FL_KEYDOWN ... caps lock 9 event = FL_KEYUP ... caps lock 10 event = FL_KEYDOWN ... caps lock 11 event = FL_KEYUP ... caps unlock 12 You can see (or guess) that the CAPS LOCK state is updated *before* the handle message is called on FL_KEYDOWN events, if CAPS LOCK is being turned ON, but *after* the FL_KEYDOWN event, if it is turned OFF. That's why the program shows the caps unlock message only on FL_KEYDOWN events. The last line should read: FL_KEYUP events., of course. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.opengl] event_x() To Get FL_Gl_Window Coordinates
On 03.04.2013 22:54, Mike Werner wrote: I want to be able to left click in an OpenGL window and have the mouse coordinates in that window returned (i.e. relative to the upper left corner of the window). Seems like I should be able to do this using Fl::event_x. However it's turning out to be difficult. First of all the only way I can get event_x to return anything is to put it in the draw function of my Fl_Gl_Window with the syntax Fl::event_x(). But this doesn't return anything when I click in the OpenGL window. It ONLY returns coordinates when I click on a button outside the OGL window. And the X value returned is relative to main FLTK window. Not what I need. First of all: Fl::event_x() is only valid in the event handling code or in a callback called from this code. Putting Fl::event_x() in a draw() method can only give you _undefined_ values, i.e. it _can_ sometimes be what you expect. This is because Fl::event_x() uses a static variable that is updated only on some events like mouse clicks, but also on FL_MOVE and maybe others. I saw your follow-up: using a button underneath the OGL window might do what you need, since you get the button callback when the click event is handled. There is no way other than to do the coordinate translation yourself, since the OGL window has its own coordinate system, but the button coordinates are relative to the button's window(). Was hoping to be able to put event_x() in the draw function never put it in the draw() method, see above. or in the callback to Fl_Gl_Window and get OGL window relative coordinates. The only idea I have now is to put a large button underneath the OGL window. When I click inside the OGL window, this button will be activated and I'll get an x cord. relative to the main FLTK window and have to subtract off the upper left corner coordinates of the OGL window. Anyone have a more elegant solution? I'd try to put an invisible box or button in the OGL window that serves the same purpose as your button in the main window. The invisible box could be an own derived class, so that you can use the handle() method, but a simple callback would also do the job. However, event handling in GL Windows might differ from normal windows, so I don't know if this would work. Albrecht ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.development] [RFE] STR #2942: Buttons keep the same color when clicked
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2942
Version: 1.3-feature
Fix Version: 1.3-current
Edmanuel, I recommend not to use this down_button_color...patch, because
this would *remove* the user's ability to set the selection color.
Please see attached patch gleam_button_selection_color.diff how to set the
selection color in the unittest_scheme.cxx file. If you want to use
fl_darker() or another color you can do it this way as well.
I'll close this STR within the next few days, as agreed by the OP, but
leave it open now for feedback.
Link: http://www.fltk.org/str.php?L2942
Version: 1.3-feature
Fix Version: 1.3-currentIndex: test/unittest_schemes.cxx
===
--- test/unittest_schemes.cxx (Revision 9855)
+++ test/unittest_schemes.cxx (Arbeitskopie)
@@ -62,14 +62,14 @@
schemechoice-add(none);
schemechoice-add(plastic);
schemechoice-add(gtk+);
-//schemechoice-add(gleam);
+schemechoice-add(gleam);
schemechoice-value(0);
schemechoice-labelfont(FL_HELVETICA_BOLD);
const char *name = Fl::scheme();
if ( name ) {
if ( strcmp(name, plastic) == 0) { schemechoice-value(1); }
else if ( strcmp(name, gtk+)== 0) { schemechoice-value(2); }
- //else if ( strcmp(name, gleam) == 0) { schemechoice-value(3); }
+ else if ( strcmp(name, gleam) == 0) { schemechoice-value(3); }
}
schemechoice-callback(SchemeChoice_CB, (void*)this);
@@ -80,21 +80,25 @@
{ Fl_Button* o = new Fl_Button(10, 9, 90, 25, button);
o-box(FL_UP_BOX);
o-color((Fl_Color)101);
+ o-selection_color(o-color());
o-labelfont(5);
} // Fl_Button* o
{ Fl_Button* o = new Fl_Button(10, 36, 90, 25, button);
o-box(FL_UP_BOX);
o-color((Fl_Color)179);
+ // o-selection_color(o-color());
o-labelfont(4);
o-labelcolor(FL_BACKGROUND2_COLOR);
} // Fl_Button* o
{ Fl_Button* o = new Fl_Button(10, 63, 90, 25, button);
o-box(FL_UP_BOX);
o-color((Fl_Color)91);
+ o-selection_color(o-color());
} // Fl_Button* o
{ Fl_Button* o = new Fl_Button(10, 90, 90, 25, button);
o-box(FL_UP_BOX);
o-color(FL_INACTIVE_COLOR);
+ o-selection_color(o-color());
o-labelcolor(FL_BACKGROUND2_COLOR);
} // Fl_Button* o
{ Fl_Tabs* o = new Fl_Tabs(10, 120, 320, 215);
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2942: Buttons keep the same color when clicked
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2942 Version: 1.3-feature Fix Version: 1.3-current FTR: the changes in test/unittest_schemes.cxx change the selection_color() for 3 of 4 buttons to show the effect more clearly. The blue (2nd) button is unaffected by this patch. The functionality is the same for all schemes, so this is all okay. Note: for some schemes (including gtk+) it would maybe be better not to use the same color for selection_color(), because the border changes don't make a big difference in the overall appearance, hence using fl_darker() might be useful. However, you can see the effect... Link: http://www.fltk.org/str.php?L2942 Version: 1.3-feature Fix Version: 1.3-current ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2942: Buttons keep the same color when clicked
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2942 Version: 1.3-feature Yes, indeed, I hadn't looked at the code and thus missed that selection_color() bit. Edmanuel, I apologize for the confusion... So, if it's in the user's control (via selection_color()) then we should NOT use this patch. Any objections to closing *this* STR ? Link: http://www.fltk.org/str.php?L2942 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] R: Re: Smooth blinking
On 19.03.2013 16:31, memoryl...@tin.it wrote: The problem was that, under particular conditions (many redraw of images), my blinking could become irregular, as timers, if I understand well, are all at the same priority level. Hint Fl::repeat_timeout() is designed to compensate for small timer delays, so that the next timer interval will be shorted if the actual timer callback is serviced later than it should. However, this does obviously work only if the overall CPU usage is small enough so that there is room to *wait* for the next timer. If the CPU is utilized so heavily that there is no time left, then ... Also note that this timer delay compensation works well (i.e. as designed) on Linux, but probably not on Windows :-( I did some tests a while back, but lost track of it. I can't say anything about Mac OS WRT this. The technique you and Greg told me is clear ; will clean up something in my (growing!) app and try to avoid unnecessary redraws. That's always a good idea. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Alpha blending with Fl_PNG_Image
Am 17.03.2013 22:17, Chris Russ wrote: Upon further investigation, the documentation says that the only way to get transparency (and 100% transparency at that) is with an Fl_Pixmap (say, a GIF file), and that is definitely NOT RGB. Even so, would that work where this fails, albeit without the kinds of shadows I'm trying to cast in the PNGs? That's not up-to-date anymore, could you give a pointer where you read it exactly? This documentation should better be updated, but as I wrote before, the current state of image drawing was not intended and should be more consistent across platforms. However, it's not as easy to do it as it might seem, and somebody has to do it. Patches always welcome... Here's the link to the documentation that says it: http://fltk.org/doc-1.3/drawing.html Search on the page for the word transparency... Thanks for the link. I'll try to improve this later. The documentation also strongly discourages people from using the -draw() method of widgets. Yes, and it is important not to call draw() from any callback, be it a widget's callback or a timer update or any other. However, if you are already within a draw() method of one widget, then it is allowed and useful to use other widgets' draw() methods, e.g. for a group or a complicated widget layout (draw the background image, then a graph, then another Fl_Box with a bargraph on top of it, similar to your case). My problem is solved, thank you. But the docs are, shall we say, confusing. Yep, you're right. The entire chapter needs some improvements and probably some examples. I'll see what I can do when I can find the time. Thanks for the heads-up. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Correct way to fire graphics updates from abackground thread
On 18.03.2013 10:51, memoryl...@tin.it wrote:
Hi all,
just to have confirmation of what I am doing.
My app is multithreaded ; the main() loop and some other working threads,
receiving / sending data and doing calculations.
The question: what is the correct way to fire a graphics update from a thread
?
My work (omitted all sanity checks):
- main:
.
static int fd_refresh[2];
.
pipe(fd_refresh);
SetNonblocking(fd_refresh[0]);
SetNonblocking(fd_refresh[1]);
Fl::add_fd(fd_refresh[0], Do_refresh_callback, NULL);
.
#define CMD_REFRESH 0
.
static void Do_refresh_callback(int fd, void *data)
{
unsigned int val;
while(read(fd, amp;val, sizeof(val)) 0)
{
switch(val)
{
case CMD_REFRESH:
// HERE I can draw to screen !
nitpick on
To be precise: no, you can't!
/nitpick
You can do widget updates and call redraw(), but you must not
call draw() methods directly from a callback. See also below.
break;
.
}
}
.
}
- A thread receives data and wants to update a drawing. It cannot do it
directly,
so it writes to fd_refresh[1] an integer which values represent what I want
to do
(full redraw(), partial updates, etc.) .
Fltk then will call Do_refresh_callback and there I will be safe drawing
anything.
Is this sequence correct ?
Now it's working without (apparent) problems.
AFAICT this is okay, so long as you don't call draw() directly,
as I wrote above.
However, using Fl::add_fd() with a pipe is not portable. IIRC you're
using an embedded Linux platform, so this may not be a problem for you.
But there are maybe more simple and portable ways using Fl::lock() and
Fl::awake() to send messages from a thread to the FLTK main loop to do
what you need. You can read more about this in the chapter Advanced
FLTK in the docs.
http://www.fltk.org/doc-1.3/advanced.html
Others will probably chime in and tell you more about programming with
threads and FLTK.
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Alpha blending with Fl_PNG_Image
On 16.03.2013 03:21, Chris Russ wrote: I've been working on a widget that can show images zoomed in and out at arbitrary percentages, and that part works. Now, in the middle of my ::draw() function I want to overlay some RGBA PNG images -- these have transparency where I'd like the underlying image to show up. I can make the images show up in the right places, but the alpha channel is being completely ignored in this little snippet: void *baseaddr = (void *)(head-image_-data()[0]); int imagew = head-image_-w(); int imageh = head-image_-h(); int imaged = head-image_-d(); fl_draw_image((const uchar *)baseaddr, x, y, imagew, imageh, imaged); head-image_ in this case was an Fl_PNG_Image that should have 4 channels. It has been cast into an Fl_RGB_Image, which should be a compatible type. But alpha blending isn't happening. I'm getting white where there should be transparency to the pixels previously drawn in the buffer. Instead, I should be getting a blend using the variable opacity in the A channel. As Ian and Greg pointed out already, alpha blending works with FLTK 1.3 (and even with 1.1), but there are some restrictions. Unfortunately you chose to use fl_draw_image(), but this function does support alpha blending only on Mac OS X with FLTK 1.3 (this is not intended, but currently that's how it is :-( ). In FLTK 1.1 and 1.3 you can use the image drawing methods instead, and *these functions* support alpha blending. So you can use the png image directly, as Greg did in his example (see his posting). You can also take a look at the source file test/unittest_images.cxx to see how it is done there. Note that this is a *unittest* code and not an example for good FLTK programming. However, the comments show what I stated above, and the code shows how you can use arbitrary image data, convert it to a RGB image, and use the image drawing method to draw it (selected by preprocessor macro IMG) vs. using fl_draw_image(), which would work only on OS X). As I said before, that's not the recommended way for your problem, since you could use the image drawing method with the png image. Upon further investigation, the documentation says that the only way to get transparency (and 100% transparency at that) is with an Fl_Pixmap (say, a GIF file), and that is definitely NOT RGB. Even so, would that work where this fails, albeit without the kinds of shadows I'm trying to cast in the PNGs? That's not up-to-date anymore, could you give a pointer where you read it exactly? This documentation should better be updated, but as I wrote before, the current state of image drawing was not intended and should be more consistent across platforms. However, it's not as easy to do it as it might seem, and somebody has to do it. Patches always welcome... The documentation also points out a function called fl_read_image() where I could copy out the area underneath where the PNG is destined to be drawn. Therefore I could do the alpha blend myself and then do a regular fl_draw_image() to put the blended image in place. Is this the only way it will work? No, see above. This is something you could do if the background changed outside of your control, but I wouldn't do it in your case. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] R: Bargraph object with Fl_Group
On 16.03.2013 09:24, Ian MacArthur wrote:
On 16 Mar 2013, at 06:28, memoryl...@tin.it wrote:
Now a plant is smaller and has only two stations: the remote machine will
put some visible booleans to zero... and the graphics app
will show only the installed stations.
So one can think: I create a group with image, bargraph, boxes and it's done.
I can't do this, because my app has to be general: it's the plant installer
who knows how the plant is made.
He will create the configuration file for my app (we created a Windows
software for this), specifying where (x, y) and how big the objects are.
I *think* what I'd do is create a group (probably with a FLAT_BOX type) that
contained just the required widgets - I'd populate this at runtime with
widgets as required based on reading the config file.
And so would I. The visibility property could make an entire group
visible (show()) or invisible (hide()).
The redraw would then be sent to the group, hopefully that would work...!
I assume it would - however, the group would need a solid background,
e.g. one of the BOX types, probably FL_FLAT_BOX.
With judicious use of groups, you can possibly arrange for some of the
widgets to be in another group to reduce the redrawing somewhat...
Just as I wrote above? One group for _one_ image, bargraph, and whatever
else is needed for one station.
...
Coming back to the problem: instead of redrawing all the bargraph parent,
IMHO the key point could be the ability to invalidate only one small
portion of the parent,
the rectangular portion under the bargraph.
Bargraph::RedrawObject()
{
parent()-invalidateRect(xBar, yBar, wBar, hBar);
redraw();
}
First instruction tells the parent to redraw only the part under the
bargraph, and the second redraws the bargraph.
Obviously this is general: all objects needing some sort of transparency
should behave this way.
You can manage this by controlling the damage regions for your widgets - but
you still need to do the redrawing of the damaged regions yourself, the
toolkit will not do it for you...
This ought to be doable with damage(), but could indeed be a little
tricky to do it right. redraw() implicitly sets FL_DAMAGE_ALL in any
widget, but here you'd have to set FL_DAMAGE_CHILD for the parent
group and redraw() for the widget to be drawn or something like this
http://www.fltk.org/doc-1.3/classFl__Widget.html#ac92191cba5d17ae34bfc346d2126c9f2
to damage a particular region (like invalidateRect would do).
So, it CAN be done, but ...
If the update rate is low, it is probably not worth the extra effort - just
redrawing the lot will be simpler!
Agreed 100% ! Don't optimize prematurely. It's much easier and saves
a lot of trouble and testing to (re)draw entire groups, unless you
(the OP) really need(s) it.
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Linker problem with Fl_Output
On 13.03.2013 10:32, Mirko D. Comparetti wrote:
...
If I issue an fltk-config --compile main.cpp everything works and I get the
working executable file.
If I create this cmake file:
- - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - -
#CMakeList.txt
cmake_minimum_required(VERSION 2.8)
project(test)
find_package(FLTK REQUIRED NO_MODULE)
find_package(OpenGL REQUIRED)
set(test_SRCS
main.cpp
)
set(test_HDRS
)
add_executable(test ${APPLICATION_EXECUTABLE_SYSTEM} ${test_SRCS}
${test_HDRS})
target_link_libraries(test ${FLTK_LIBRARIES})
target_link_libraries(test ${OPENGL_LIBRARIES})
- - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - -
I can cmake it using the GUI and create the makefile without any problem, but
when I issue the make command, this is the output error from the linker (and
not from the compiler):
- - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - -
Linking CXX executable test
CMakeFiles/test.dir/main.cpp.o: In function `main':
main.cpp:(.text+0x5f): undefined reference to `Fl_Output::Fl_Output(int, int,
int, int, char const*)'
collect2: ld returned 1 exit status
make[2]: *** [test] Error 1
make[1]: *** [CMakeFiles/test.dir/all] Error 2
make: *** [all] Error 2
- - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - - 8 - - - -
Do you know how to solve it? I think I'm missing some dependencies, but I
don't know which ones.
Please read the file README.CMake.txt, particularly the part about
using FLTK with CMake. If you know how to work with CMake, you should
understand what you need, but I can't say what it is. I can only guess
that $(FLTK_LINKLIBRARIES) is not correct, since in the example given
in this file you can read:
target_link_libraries(hello fltk)
and later, why the name fltk is chosen and more...
If this doesn't help, please try to post the linker command and
information about your OS (and version), FLTK version, and build
system (e.g. MinGW on Windows?).
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Linker problem with Fl_Output
On 13.03.2013 11:59, Mirko D. Comparetti wrote: The strange thing is that if I change Output in Input (...), it works perfectly. Okay, now we're coming closer, and now we REALLY need your build environment and your FLTK version! Let me guess: (1) you're linking against the shared libs of FLTK ? (2) you're probably using a FLTK version older than 1.3.2 ? Note that FLTK 2.x is OLDER than any 1.3.x version, and that you should definitely NOT use 2.0 or 3.0 (dev./pre-alpha version). Please try to link statically and tell us the FLTK version. If it's not 1.3.2 or later (svn), there may be missing c'tors in the shared libs that have already been fixed. If it's 1.3.2 or a later svn version, then you found another missing c'tor, and we should fix this. TIA for feedback ... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2672: Updated Gleam patch against FLTK1.3.x-r8816
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2672 Version: 1.4-feature Thanks for fixing the bug so quickly, I can confirm that it works now. WRT front light 3d effect being more modern: I'm not a 3d expert, and I don't know much about what is modern in GUI design. My PERSONAL opinion is that I don't like this because I don't get a correct 3d impression. However, as I said before, if this is intendend, and if others want this scheme to be included, then I won't object. Maybe it needs some more fine tuning, but we should first think about including it in the FLTK core before there is too much work done... Thanks for your efforts, Edmanuel. Looking forward to seeing the left-right gradients, too. I can see the difference in white box backgrounds in your new patch (4.3d), and I believe it's better now, but IMHO it could still be a little brighter... I can also confirm that colored buttons become black..gray..white (or get the default system color?) when pressed in other schemes (gtk+, none, plastic), but I wonder why this is so and whether it could be changed (a) generally, or (b) for the gleam scheme? Link: http://www.fltk.org/str.php?L2672 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Displaying non-english sumbols in OS Windows
On 10.03.2013 15:15, Anton Petrov wrote: The problem is that in the windows operating system cyrillic text is incorrectly displaying. How it could be fixed? We need to know which FLTK version you're using. To be able to render cyrillic *and* other text in *one* application you must use FLTK 1.3, and you must probably install the correct fonts, but then it just ought to work. If you're still using FLTK 1.1, please upgrade to FLTK 1.3.2. This is straight-forward, and you will not have to change code, but take care: FLTK 1.3 uses UTF-8 for text encoding, and if you're now using some Windows codepage for your text, then you may need to convert your stored text / data to UTF-8 before you can use it properly. -- Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [MOD] STR #2934: probably user-error, but .c files in src/fltk3png cannot find pngpriv.h
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2934 Version: 3.0-feature Thanks for the report, your testing, and for your confirmation. As said before, FLTK 3 is still under development, and the developers usually don't install the compiled version. The problem with png seems to be caused by not finding the correct libs/paths during configure. The default for the png library should be to use the system libs if available, but use the built-in version, if the system libs are not available. However, you'd need to install appropriate dev packages, if you want to use the system libs. But something appears not to work as intended. We'll take a look at this later, hence I'm leaving this STR open as a reminder, but won't fix anything now. Link: http://www.fltk.org/str.php?L2934 Version: 3.0-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2933: fltk-1.3.x-r9831 and Cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2933
Version: 1.3-current
Fix Version: 1.3.2
Okay, then your problem is solved ?
I still believe that it was only a problem of relics of previous builds in
the same source tree. You should really clean your sources and run
autoconf/configure from scratch, if you want to change the configuration.
Here is what I did with your configure commands as posted in Cygwin.tbz:
$ make distclean
=== cleaning jpeg ===
=== cleaning png ===
=== cleaning src ===
=== cleaning fluid ===
=== cleaning test ===
=== cleaning documentation ===
$ autoconf -f
$ cat str/Cygwin/error/Configure.fltk13
#! /bin/bash
# do_configure:
./configure \
--enable-cygwin \
--prefix=/usr/local/fltk13 \
--enable-shared \
--disable-x11 \
--enable-threads \
--enable-largefile \
--disable-localjpeg \
--disable-localpng \
--disable-localzlib
$ str/Cygwin/error/Configure.fltk13
checking for gcc... gcc
...
Configuration Summary
-
Directories: prefix=/usr/local/fltk13
bindir=${exec_prefix}/bin
datadir=${datarootdir}
datarootdir=${prefix}/share
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib
mandir=${datarootdir}/man
Graphics: GDI
Image Libraries: JPEG=Builtin
PNG=Builtin
ZLIB=System
Large Files: YES
OpenGL: YES
Threads: YES
configure: creating ./config.status
config.status: creating makeinclude
config.status: creating fltk.list
config.status: creating fltk-config
config.status: creating fltk.spec
config.status: creating FL/Makefile
config.status: creating config.h
$ make
=== making jpeg ===
...
Note that JPEG and PNG fell back to using the builtin versions, since I
don't have the JPEG and PNG libs and/or headers installed.
This ran to completion w/o warnings or errors. You can view the full log
in the attached file:
http://www.fltk.org/strfiles/2933/str-2933_cygwin_log.txt
I'd appreciate if you could confirm that it works for you as well with the
given commands.
I consider this STR resolved now, but waiting for feedback...
Link: http://www.fltk.org/str.php?L2933
Version: 1.3-current
Fix Version: 1.3.2
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [RFE] STR #2672: Updated Gleam patch against FLTK1.3.x-r8816
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2672 Version: 1.4-feature BUG REPORT -- System: Linux Ubuntu 12.04 FLTK 1.3.2 svn -r 9834 with patch http://www.fltk.org/strfiles/2672/fltk-1.3.2-gleam-4.3c.patch (uncommented gleam entries in test/unittest_gleam.fl/.cxx, but this probably doesn't matter, but makes testing easier). Warning: testing this hogs the cpu, and the app becomes unresponsive - I could not even close the app with the window's close button. CTRL-C from the console that started the app can stop it though. Test: run test/unittests -s gleam, then go to the scroll size test and try to move the top right A: Scroll Size scrollbar. The app hangs. Stop it. Start again, w/o -s gleam, go to the same test, move that scrollbar to a value like 10 (that works), select schemes test, select the gleam scheme, select scrollbar size test again, click on the slider in the same scroll bar, and move it step by step with the left arrow key down until the app hangs. This happens when you try to go from 2 to 1, at least for me. Assumption: box drawing goes into an endless loop when the box width is too small. Link: http://www.fltk.org/str.php?L2672 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2672: Updated Gleam patch against FLTK1.3.x-r8816
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2672 Version: 1.4-feature Other than the mentioned bug, I like this gleam patch, but would like to ask for your opinions. Although it looks good, I can't seem to interpret the boxes well as up and/or down boxes. ISTR that I once learned that we (our brain) usually interpret(s) flat drawings as 3-dimensional according to some light effects, so that our impression of up and down is best, if the light seems to come from top left. This is used in the standard box types, and it seems to be utilized in widgets of other apps (e.g. firefox). The clue is that... - for an UP box, the top and left side are brighter, the bottom and right side are darker - for a DOWN box, this is just the opposite. In the gleam patch, there is only the top-down gradient (not left-right), but this would be okay, IMHO. However, could we (Edmanuel ?) try to change the patch so that it is like described above ? I'd like to see that as an example, to be able to decide if this is better. OTOH, if this is not intended, then I'm also okay with the patch as-is. Just wanted to ask for a possible improvement or other opinions. Link: http://www.fltk.org/str.php?L2672 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2672: Updated Gleam patch against FLTK1.3.x-r8816
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2672 Version: 1.4-feature Well, here are more test results. In the test/unittests schemes test (BTW: big thanks to Edmanuel for the code and Greg for inclusion - this is a nice new test) I see: (1) The white selection box(es) seem too dark at the top and at the bottom. Wouldn't it be better to make them only some kinda gray, but not black at the border? In general: should the darkest color be something like fl_darker(original_color, FL_BLACK, some-value) instead of FL_BLACK? Note that I wrote this w/o looking at the code, I may be wrong, but this is what it looks like. (2) The colored buttons become black'n'white (gray) when clicked, i.e. they lose ther colors. Wouldn't it be better if they only changed their up-down-box, but not the color? Again, this is what I see, not something I read in the code. Link: http://www.fltk.org/str.php?L2672 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Vote request: addition of two new schemesgrad and gleam
On 08.03.2013 22:13, Ian MacArthur wrote: On 8 Mar 2013, at 17:31, Greg Ercolano wrote: A request to vote on the addition of the gleam and grad patches to FLTK. There's two STRs for this: http://www.fltk.org/str.php?L2672 http://www.fltk.org/str.php?L2675 Would like to combine and apply. Code seems OK, looking for consensus and comments on patches. I've not looked at the patches in detail recently - looked at the gleam patch a while back, but Edmanuel has been working on it more since then... If it looks OK to others, then I'd be +1 on adding it, as more schemes would probably be a popular option! Same here, +1 on adding both new schemes, if they are okay for inclusion. I posted a bug report and a few comments to STR #2672. I did NOT test the grad patch yet (STR #2675). My only comment is I'd like to modify the unittests program to have a test for all our scheme options (plastic, gtk+, etc) so it can be used to look for artifacts. Basically taking STR#2672's test/gleam application and moving it into unittests as one of the test screens (with some mods). This sounds like a good idea in any case: this is what the unittests framework was meant for really, I think! (I mean, adding on all sorts of useful testing features without having to ad new test programs directly.) +1 (and since this is done already, thanks for doing it, Greg) Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [MOD] STR #2933: fltk-1.3.x-r9831 and Cygwin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2933 Version: 1.3-current This could be an autoconf/configure problem, or maybe your Cygwin version is not up-to-date. There has been an update for binutils lately, for instance. Basically, I have the same Cygwin version, and I made sure that mine is up-to-date: uname -a CYGWIN_NT-6.1-WOW64 as-w7 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin I tried different ./configure command lines, and all variants worked for me (after running commands like the following). Please try this: make distclean rm -rf autom4te.cache/ autoconf -f ./configure --enable-cygwin --enable-shared --disable-x11 The last line (./configure...) seems to be what you did, but I can only guess. If this doesn't work for you, please post your configure line and results, and show your error messages with a little more context (at least the last few successful compile commands before the error). BTW: your output looks strange, since you seem to compile for cygwin, but you also seem to have disabled X11 (because I see cygfltknox-1.3.dll in your error message) - however, this ought to work as well, and the command line given above works for me. Link: http://www.fltk.org/str.php?L2933 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.general] Which Fl_Menu_Bar submenu is current?
On 02.03.2013 00:50, Howard Rubin wrote: How can I find out which dropdown menu of an Fl_Menu_Bar is currently dropped down (if any)? I need to know this in an add_timeout()/repeat_timeout() timer. I don't know if there is a way to do it, and I'm afraid there is no official/documented way to do this. Also, please take care not to open or modify windows while a menu is open. This can yield unwanted effects, since the open menu window does a grab(), so that mouse events can be captured. This can result in the program appearing to hang. Although this has been fixed at least partially, there can still be some bad effects. See http://www.fltk.org/str.php?L1986 That said, I'd try if mvalue() is of some help for you. It returns the last menu item that was picked(), and I assume this is or can be the (parent ?) item that has been clicked to open the currently open menu item/window. However, I'm not at all sure about this, and you'd have to check if this is also usable if only the top level menu item has been opened, and also if this is really reset when the menu is dismissed - I don't know, but this is the best help I can give. Another way could be to use a callback that will be called when a menu is selected, but again I'm not sure if this will help. You'd probably have to track the open menu(s) yourself, and I also don't know if you'd get a callback when the menu gets closed. HTH Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] RFC: decision on license to useforfltk/examplessource code
On 01.03.2013 04:16, Michael Sweet wrote: On 2013-02-28, at 8:24 PM, Albrecht Schlosser ... wrote: IIRC I haven't seen a real freeware (public domain) proposal. Wouldn't this be appropriate for the example code? Unfortunately, public domain isn't a universally-recognized status for copyrightable works. What you ultimately have to do is say I hold the copyright on this code and I say you can do whatever you want with it. Thanks for clarification. I'll take a look at the other licenses during the weekend, if I can find the time... Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK version number update and releaseprocess [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packagedproperly]
On 01.03.2013 11:55, Peter Åstrand wrote: Suggestion: After the release is done, append post to the version number. The version number must be numeric, three parts only, see: http://www.fltk.org/doc-1.3/enumerations.html The FLTK version number is stored in a number of compile-time constants: FL_MAJOR_VERSION - The major release number, currently 1. FL_MINOR_VERSION - The minor release number, currently 3. FL_PATCH_VERSION - The patch release number, currently 2. FL_VERSION - A combined floating-point version number for the major, minor, and patch release numbers, currently 1.0302. We can't change this, but *maybe* we could _add_ some string to be used in another variable/macro for those who want to get that additional info. FL_VERSION_SUFFIX or something like that, maybe. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packaged properly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2932 Version: 1.3.2 Fix Version: 1.3.2 (r9829) Fixed in Subversion repository. Thanks for the heads-up, this is now fixed in the svn repo (r 9829). We'll need to take care of this for the next release. Unfortunately there are several places with version numbers that need to be adjusted manually for each release. :-( Some of them had already been fixed before, the remaining fixes were in src/Makefile for some library version numbers. We can't fix the released tarball, but this fix will be in the next weekly snapshot, which is due in about 9-10 hours from now, probably at 8 am UTC (1 am somewhere in the US). This is not exactly the released 1.3.2 version, but you can download it to get the correct version numbers. Link: http://www.fltk.org/str.php?L2932 Version: 1.3.2 Fix Version: 1.3.2 (r9829) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packaged properly
On 01.03.2013 01:04, Greg Ercolano wrote: On 02/28/13 15:24, Albrecht Schlosser wrote: We'll need to take care of this for the next release. Unfortunately there are several places with version numbers that need to be adjusted manually for each release. :-( We probably should have a checklist as part of the CMP, or similar document to describe the release process, so that we don't miss anything obvious. Greg, I started working on this. Please see for my posting in fltk.development, coming up soon... Albrecht ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.development] FLTK version number update and release process [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packaged properly]
On 01.03.2013 01:04, Greg Ercolano wrote: On 02/28/13 15:24, Albrecht Schlosser wrote: We'll need to take care of this for the next release. Unfortunately there are several places with version numbers that need to be adjusted manually for each release. :-( We probably should have a checklist as part of the CMP, or similar document to describe the release process, so that we don't miss anything obvious. I've started developing such a checklist. It's only a raw list for now, but I've managed to describe a few search commands (grep... | cut... | sort...) and so on to FIND the version numbers in the source files. (And, BTW, I still found a few old version numbers, see svn r We can probably also automate the release number process, or at very least centralize things so that all version #s come from one location. That would be the next step. Any help appreciated... I've had to do this with my own software, and found over the years I use two approaches: 1) For large commercial software, I have a VERSION file in the main directory with a single line in it: VERSION=#.# This can be include'ed from Makefiles to define macros used on everything from compile lines to Makefile construction to documentation builds and tar filenames. I believe that such a solution would fit best for FLTK, if we could manage to use this version number everywhere. I've made a similar approach in a small commercial project as well. 2) For small open source projects, my small 'release' script usually grabs the first version number it finds in the CHANGES log. This ensures I keep CHANGES up to date, and the version number doesn't have to be separately named. Makefiles get this number by running a small script to get the version# from CHANGES and turns it into a macro value. The release script makes sure this value gets hardwired into files that need it hardwired for release. Another good idea. We need to see what fits best. Another important thing that we should have is a description of the release process, so that other developers (than Matt) can do a release w/o hassle. Yeah, I know that Manolo did the last release, and this is good, but I assume it was a lot of (unnecessary) work to find out how to do it. This should be made easier, and then we could probably do a release more often... Oh, and another question: WHEN do we upgrade the version number(s)? (a) immediately after one release, for the next release, or (b) short before the next release ? (a) has the advantage that there can't be FLTK software with the same version number as the last released one, but that is different. This includes the weekly snapshots! (b) has the advantage that we'd better know WHICH would be the next release/version number, e.g. is it 1.3.3, or will it be 1.4.0 ? (c) would be to do both, so that all releases will have even patch versions (1.3.0, 1.3.2, ...), but intermediate development versions (only from svn or weekly snapshots) will have odd patch versions, i.e. 1.3.1, 1.3.3, ... Thoughts ? Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk with VC6 development isn'it possible?
On 24.02.2013 10:07, Ali wrote: This is my first post on Fltk org, Greetings, new users are always welcome. Fltk I find it very interresting but I hope I will implement it on my VC6 environnement. Well, this is possible, but we don't recommend it. If you have a working VC6 solution, then you *can* do it. A better (recommended from FLTK dev's) alternative for Windows is MinGW, but YMMV. So I downloaded fltk-1.1.4 packages with lib and includes Ooh, that's really, really outdated. Don't use it! Please use a FLTK 1.3.x release (current is 1.3.2). It's really easy to build it from source. You can even do it with your ancient VC6 environment. In FLTK 1.3, there is IDE/VisualC6/*, and this should pretty much work for you. If you really want to use 1.1, then look for a source distribution at the FLTK web site for FLTK 1.1.10: http://www.fltk.org/software.php I put in my VC6: -Project - settings - Link: fltk.lib wsock32.lib comctl32.lib fltkimages.lib -Project - settings - Link: fltk.lib wsock32.lib comctl32.lib fltkimages.lib -Tools - Option - Directories Includes: C:\Program Files\fltk-1.1.4 -Tools - Option - Directories Library files: C:\Program Files\fltk-1.1.4\lib Well, usually order matters (I don't know for sure for Windows/VC). If it does, you should fltkimages.lib and fltk.lib first (in this order), then all the Windows libs. So I tested with this sample code: [simple hello world code removed] So the results is linking problem: Linking... fltk.lib(Fl_Pixmap.obj) : error LNK2001: unresolved external symbol __ftol2 fltk.lib(Fl_Image.obj) : error LNK2001: unresolved external symbol __ftol2 fltk.lib(fl_arci.obj) : error LNK2001: unresolved external symbol __ftol2 fltk.lib(fl_vertex.obj) : error LNK2001: unresolved external symbol __ftol2 fltk.lib(Fl_x.obj) : error LNK2001: unresolved external symbol __ftol2 fltk.lib(fl_color.obj) : error LNK2001: unresolved external symbol __ftol2 fltk.lib(Fl_get_system_colors.obj) : error LNK2001: unresolved external symbol __ftol2 fltk.lib(fl_draw.obj) : error LNK2001: unresolved external symbol __ftol2 Release/prj_win32cons_fltk.exe : fatal error LNK1120: 1 unresolved externals Error executing link.exe. prj_win32cons_fltk.exe - 9 error(s), 0 warning(s) I have no idea why __ftol2 is undefined. This is probably resulting from the package you're using. We strongly recommend compiling FLTK from the original source download package. FWIW: google finds some answers if you enter __ftol2. Among others someone mentioned that ftol2 is a new function in VC7 (sic !). You may not want to use a (pre-compiled) package from VC7 with your VC6 environment. I know that there is a VC6 ide directories on some packages of Fltk but I must compil fltk.dsw projects and there are severals errors If you're using FLTK 1.3, then it ought to work. If not, please ask here with specific error messages. So I think there is a way without using an existing dsw project, Could you help me to link correctly my little Fltk program with VC++6 ? Please take a look at these FLTK 1.3 files: ...fltk_root/README.MSWindows.txt and ...fltk_root/IDE/README.IDE and if this doesn't help, feel free to ask again. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk with VC6 development isn'it possible?
On 24.02.2013 10:07, Ali wrote: This is my first post on Fltk org, Oh, I forgot to mention: fltk.development is the wrong forum/group for your question, please ask in fltk.general. fltk.development is for development of the FLTK lib and not for user questions. Thank you. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] C API experiment
On 22.02.2013 15:46, Patrick wrote: I have realized that pretty much everything I like about Ada is available from Cobol too and I have recently switched my focus. Open Cobol compiles to intermediate C. I was trying to figure out how to call back into C++ from C but then I finally realized I could just run the C code through a C++ compiler and have code at the same level as C++ and now I don't think I need to figure out a way to call up into C++. And why would you want to do that? What is it that you can do with Cobol that is so important? Maybe it's worth looking at it from the other way aroung: write your GUI (and main program) in C++ and call Cobol-written code for doing whatever work your program has to do? Having said that, I think that a C binding would really help the project and I would like to help, please let me know if I can. I'm not keen on adding a C binding to the FLTK project. There may be reasons why someone might want to have one, but you'd lose all object-oriented features of C++, namely function overloading (even for normal functions) and - IMO *much more important* - inheritance from predefined FLTK objects (widgets) for your own program. My FLTK programs have lots of derived classes, and I don't see a way to do this with a C binding. That said, if someone would write a library addition (the C binding or whatever), and if this would require a few changes, additions or new functions in the FLTK core, I probably wouldn't oppose, as long as this wouldn't break anything and patches would be supplied. But I'm only one developer, and we'd have to agree about this. And, to be clear: I don't think that it is useful to have and support this C binding in the fltk core, since we'd have to update it whenever we add or change functions/widgets within the library. This is a similar problem as our different build systems (make, IDE's, Cmake, etc.). Too much work for our small team, and if we don't use it ourselves, then this would easily get out of sync. Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] change labelfont and labelize in fltk 1.3.2
On 22.02.2013 03:09, edgar wrote: On 21 Feb 2013, at 20:33, edgar wrote: Hi Ian - that fixed it! Thanks!!! I've been able to compile numerous tests and play around with the font size and style. Here is a different issue: the fltk-config --complile is not finding FL_Box. I typed fltk-config --complile hello.cxx and get an error message /hello.cxx:7: undefined reference to 'FL_Box::Fl_Box(int, int, int, int, char const*)' It is finding FL_Window but not FL_Box ... But it will compile programs that do not require FL_Box. I am assuming it is located in libfltk.a which is in usr/lib/x86_64- linux-gnu - Is that correct? No, according to your previous posting this is not correct! There you wrote: Here is what I did: tar -xvzf fltk-1.3.2-source.tar.gz cd fltk-1.3.2 ./configure make #make install I presume you meant that you did not run make install. That's fine and is the recommended way for development (recommended by the fltk developer team). However, if ther is some older version in the system library/include area (path), then you may get conflicts, if you don't take care. Any suggestions? Use the /full/path/to/fltk-config (not only fltk-config, as you wrote above) to compile your test program. This should pull in all required files from the fltk library you just compiled (if it is in /full/path/to/...). However, there's still one small possibility that you might get the wrong lib when _running_ your app (this is not the case if you get linker errors as you wrote). To be absolutely sure you should maybe run configure with --disable-shared so that the shared libs are not built, but this is the default anyway. If you are trying to build fltk from source, as you described, then you should consider uninstalling the system fltk package and all fltk versions you may have installed previously, unless you need fltk for another system-supplied package. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] change labelfont and labelize in fltk 1.3.2
On 22.02.2013 10:44, MacArthur, Ian (Selex ES, UK) wrote: Thanks for responding, Greg. I made an error writing the report from the compiler. The code is a copy from the hello.cxx on the fltk.org site. The compiler statement actually reads : /hello.cxx:7: undefined reference to 'Fl_Box::Fl_Box(int, int, int, int, char const*)' Assuming your code is short, post it here. I'm guessing you have forgotten to include the FL/Fl_Box.H header files... Hmm, the error message is a linker error, so the compiling stage should have passed successfully. Maybe a library version mix, as I wrote in my other post? Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.opengl] How to enable Drag n Drop on OpenGL window ?
On 18.02.2013 12:17, Furqan wrote: ... File only accepted when drop over the Fl_Double_Window. Here is my code.. MainWindow-begin(); // Fl_Double_Window DnDReceiver b(0,0,WINDOW_SIZE_W, WINDOW_SIZE_H); // Drag n Drop Box glutInitDisplayMode (GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH | GLUT_ACCUM | GLUT_ALPHA | GLUT_STENCIL | GLUT_MULTISAMPLE); GLUT_MAIN_WINDOW = glutCreateWindow(RACS_VERSION); MainWindow-end(); MainWindow-show(argc, argv); I tried to put DnDReceiver box before, after, middle, everywhere, inside of begin and end of Fl_Double_Window but no success. Please guide me Where to put DnDReceiver box in the code. To receive events first, you must put the invisible receiver box last, but within begin()/end() of the main window. You can imagine that this box is the top-most widget in the widget layer(s) of your window, so it gets the events first. If it returns zero on an event, then the event falls through to the lower layers. BTW: in contrast, drawing is done first to last widget within each group/window, which is essentially the same principle: bottom layer drawn first, top layer drawn last. Albrecht ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.bugs] [MOD] STR #2931: Re-implement fl_scandir for *nix systems that do not provide a native version
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current Regarding ABI issues WRT (C++) fl_filename_list(), Michael wrote: I have tried to statically link code that use the new 'filename.H' against an older library and this fails because the parameter types of the C++ function do not exactly match. This is not the really the ABI problem we're talking about. If you compile with a new library (i.e. its header files), then this is NOT supposed to link and work correctly with an older library. The important part is the other way around: if you have an old program, linked dynamically against an older library (Windows DLL, U*X shared object), THEN it must still work with a newer shared library. This means that all previously existing functions/methods must still exist in the new library and be compatible. Michael continued: ... is it possible to overload the function declaration without breaking other things? I know that we have such overloaded functions/methods with different const-ness in some parameters. So, in theory, it should work if we kept the old non-const (C++) function name(s) and add another const-correct version, maybe as a pure C function (wasn't this another change you, Michael, did?). This could probably work, but I'm not absolutely sure. In this case the old function can simply call the new function, if this is possible (maybe by casting the arguments). Hint: a *test* could be to compile and _link_ a program dynamically with an old shared library and _run_ it (maybe on another system) with the new shared library. That's what typically happens if you have built your program on a Linux system with fltk 1.3.0, then you upgrade the system, and this installs fltk 1.3.3 (the next version, maybe with this patch). Link: http://www.fltk.org/str.php?L2931 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2931: Re-implement fl_scandir for *nix systems that do not provide a native version
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2931
Version: 1.3-current
Added a patch file to replace the full source files in the uploaded tar
file. The patch is against current svn (r 9827). Although bigger than the
compressed tar file, I prefer the patch format.
The patch contains a few small changes WRT the tar file:
- copyright year adjusted (e.g. 1998-2010, 2013 - 1998-2013
- fixed one typo
Still testing, but patch looks good AFAICT. I'll post my test results with
Cygwin and other available systems later, but this can take some days due
to restricted test time. :-(
Link: http://www.fltk.org/str.php?L2931
Version: 1.3-currentIndex: FL/filename.H
===
--- FL/filename.H (revision 9827)
+++ FL/filename.H (working copy)
@@ -3,7 +3,7 @@
*
* Filename header file for the Fast Light Tool Kit (FLTK).
*
- * Copyright 1998-2010 by Bill Spitzak and others.
+ * Copyright 1998-2013 by Bill Spitzak and others.
*
* This library is free software. Distribution and use rights are outlined in
* the file COPYING which should have been included with this file. If this
@@ -107,13 +107,15 @@
# endif /* __cplusplus */
# if !defined(FL_DOXYGEN)
-FL_EXPORT int fl_alphasort(struct dirent **, struct dirent **);
-FL_EXPORT int fl_casealphasort(struct dirent **, struct dirent **);
-FL_EXPORT int fl_casenumericsort(struct dirent **, struct dirent **);
-FL_EXPORT int fl_numericsort(struct dirent **, struct dirent **);
+/* Parameters changed to 'const struct dirent**' */
+FL_EXPORT int fl_alphasort(const struct dirent **, const struct dirent **);
+FL_EXPORT int fl_casealphasort(const struct dirent **, const struct dirent **);
+FL_EXPORT int fl_casenumericsort(const struct dirent **, const struct dirent
**);
+FL_EXPORT int fl_numericsort(const struct dirent **, const struct dirent **);
# endif
- typedef int (Fl_File_Sort_F)(struct dirent **, struct dirent **); /** File
sorting function. \see fl_filename_list() */
+ /* Changed to match POSIX.1-2008 compliant sort function like 'alphasort()'
*/
+ typedef int (Fl_File_Sort_F)(const struct dirent **, const struct dirent
**); /** File sorting function. \see fl_filename_list() */
# if defined(__cplusplus)
}
Index: src/filename_list.cxx
===
--- src/filename_list.cxx (revision 9827)
+++ src/filename_list.cxx (working copy)
@@ -3,7 +3,7 @@
//
// Filename list routines for the Fast Light Tool Kit (FLTK).
//
-// Copyright 1998-2010 by Bill Spitzak and others.
+// Copyright 1998-2013 by Bill Spitzak and others.
//
// This library is free software. Distribution and use rights are outlined in
// the file COPYING which should have been included with this file. If this
@@ -28,17 +28,18 @@
extern C {
#ifndef HAVE_SCANDIR
- int fl_scandir (const char *dir, dirent ***namelist,
- int (*select)(dirent *),
- int (*compar)(dirent **, dirent **));
+ /* POSIX.1-2008 compliant prototype for own implementation of 'scandir()' */
+ int fl_scandir(const char *dir, struct dirent ***namelist,
+ int (*select)(const struct dirent *),
+ int (*compar)(const struct dirent **, const struct dirent
**));
#endif
}
-int fl_alphasort(struct dirent **a, struct dirent **b) {
+int fl_alphasort(const struct dirent **a, const struct dirent **b) {
return strcmp((*a)-d_name, (*b)-d_name);
}
-int fl_casealphasort(struct dirent **a, struct dirent **b) {
+int fl_casealphasort(const struct dirent **a, const struct dirent **b) {
return strcasecmp((*a)-d_name, (*b)-d_name);
}
@@ -72,8 +73,7 @@
according to their ASCII ordering - uppercase before lowercase.
\return the number of entries if no error, a negative value otherwise.
*/
-int fl_filename_list(const char *d, dirent ***list,
- Fl_File_Sort_F *sort) {
+int fl_filename_list(const char *d, dirent ***list, Fl_File_Sort_F *sort) {
#if defined(WIN32) !defined(__CYGWIN__) !defined(HAVE_SCANDIR)
// For Windows we have a special scandir implementation that uses
// the Win32 wide functions for lookup, avoiding the code page mess
@@ -94,32 +94,29 @@
fl_utf8to_mb(d, dirlen, dirloc, dirlen + 1);
#endif
+ // We should not write 'dirent' here if we mean 'struct dirent' because the
+ // implicit 'struct' is only allowed with C++ and 'scandir()' is a C function
#ifndef HAVE_SCANDIR
- // This version is when we define our own scandir
+ // The system don't provide a usable implementation
+ // This is e.g. the case on SunOS 5.9 and older versions
int n = fl_scandir(dirloc, list, 0, sort);
-#elif defined(HAVE_SCANDIR_POSIX) !defined(__APPLE__)
- // POSIX (2008) defines the comparison function like this:
- int n = scandir(dirloc, list, 0, (int(*)(const dirent **, const dirent
Re: [fltk.general] OT: Making application run once
On 17.02.2013 16:57, Ian MacArthur wrote: I used named pipes to do this, since they work ok on WIN32 as well as *nix OSX. My app tests for the presence of the named pipe on launch; if not found it launches a full instance creates the pipe... If found, a little helper function just writes the new file instance onto the pipe then terminates. The main app monitors the incoming pipe for actions, albeit as a low priority background thread. Seems to work ok, but was a bit of messing about with platform specific code to get the pipes to work transparently across platforms. There's probably a better way though! Maybe not better, but for some reasons easier to implement, at least for me: I used a local TCP socket and Fl::add_fd() for this. PRO: platform independent implementation, and Fl::add_fd() works even on Windows, where Fl::add_fd() is restricted to sockets. This was the main argument to do it this way. Also, no threads required. CON: you need a fixed local socket number for it to work. A named pipe would be more flexible (arbitrary NAME vs. socket NUMBER). The app first tries to connect to the socket, and if it exists, sends a message and exits. If it doesn't exist, then this is the first instance of the app. It creates a local server socket and registers it with Fl::add_fd() to watch it. Whenever a new app is started, a callback is triggered in the first instance, since the other instance writes to the socket. The first instance then reads the message from the socket... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
On 18.02.2013 11:12, MacArthur, Ian (Selex ES, UK) wrote: There's probably a better way though! Maybe not better, but for some reasons easier to implement, at least for me: I used a local TCP socket and Fl::add_fd() for this. PRO: platform independent implementation, and Fl::add_fd() works even on Windows, where Fl::add_fd() is restricted to sockets. This was the main argument to do it this way. Also, no threads required. Yes: though my code was threaded anyway, so there wasn't a big cost for me in going this way. I knew that, and that's why I wrote at least for me ;-) It would have been nice if Fl::add_fd() worked on pipes on WIN32 though... Yep, and files as well. CON: you need a fixed local socket number for it to work. A named pipe would be more flexible (arbitrary NAME vs. socket NUMBER). Not quite an arbitrary name though - I had to figure out a recipe whereby the new process would figure out the same name as any prior process, so that it could look for the name at runtime... My emphasis was on NAME vs. NUMBER, and what you can select the name|number from. This way, I still consider the selection of a name for a pipe arbitrary, since the name space is much bigger than a number range from 1024 to 65535 for non-priviledged TCP sockets. Of course, all processes must agree about the same name if they want to communicate... I made something up based on user name, the dir in which the executable resided, and, erm, some other stuff... That seems to work, and means that if two users are on the same machine they get one instance each, rather than just one instance between them. Which was what I wanted. Yes, I didn't consider different users on the same system (client PC), since Windows was the main target, and single user Linux workstations were a secondary target. However, if I'd get the task to make it work for different users on the same system, maybe Linux workstations/servers with remote (X) access, then I'd probably utilize Fl_Preferences for saving the socket number (or pipe name, or ...), since Fl_Preferences is user specific. You must still take care that it is unique, and _your_ app probably predates the addition of Fl_Preferences to FLTK, but you know what I mean. For some sort of server process, maybe one instance for all users would be more appropriate, though? Sure, however in my constellation it's a GUI (FLTK) program, and so one instance per user would be the way to go, too, if there could be more than one user on a client PC. It would even be more complicated, if more than one _person_ could access the same system with the same _user_ name from different remote workstations. Not really something you'd want, but in real life ... :-( The app first tries to connect to the socket, and if it exists, sends a message and exits. If it doesn't exist, then this is the first instance of the app. It creates a local server socket and registers it with Fl::add_fd() to watch it. Whenever a new app is started, a callback is triggered in the first instance, since the other instance writes to the socket. The first instance then reads the message from the socket... Yup - sounds familiar... Only I didn't have the convenience of a working Fl::add_fd() method to help out, so I have a helper thread that just blocks on the pipe, and only ever runs if there is something there to read. Same principle, of course... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Ubuntu vs Fedora performance GMorgan0.58
On 14.02.2013 18:22, Robert Vogel wrote: On 12 Feb 2013, at 21:15, Robert Vogel wrote: Originally the UI was generated using Fluid, but lately I have been hand-coding it. Just to be sure there is no misunderstanding the formerly generated code is now an element called NotGenerated.cxx. It contains a small routine, LightIt, which colors the bars when sequencing and scrolls. The last line of LightIt is a redraw statement. If I comment it our in Fedora, timing recovers. =20 I use the same 64 bit machine for both U12.4 and F17. So, here's the question: What's the difference between Ubuntu and Fedora that could cause this ? [Ian's comments about graphics drivers removed] Thank you for your note. I think you are correct...I DO have an Nvidia card. But, since it was not too straightforward to install the drivers, I didn't prove it. Okay, now that's a point. But you should check if you NEED that redraw() call if you can comment it out and the software still works as expected (does it?). Calling redraw() when not needed or for groups/windows if a partial update of a smaller widget might suffice means wasting resources that aren't needed. If today's fast graphic cards still can do it (with appropriate drivers), there is still the question: why waste resources, and when will you reach a point where you will see the effect (slowness) ? I'd take this experience with the slow drivers to test and see what is really needed... Cheers, Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FL_LEAVE in Fl_Menu_Bar
On 11.02.2013 11:11, MacArthur, Ian (Selex ES, UK) wrote: It seems that pulldown() doesn't return until I press Esc, and handle(FL_LEAVE) doesn't get called until then. Yup - this seems to be a weakness here; we have the pulldown method which allows us to programmatically show the menu, but I can't see an equivalent method to ask the menu to close again, programmatically... I tried a few tests around your code, and what I wanted was a method I could call to ask the menu to close again (pushup ?) in response to some event, e.g. a leave or similar... but... Anyone? Not much help from me, but pulldown() as well as popup() are synchronous methods. From the docs of popup(): The menu stays up until the user picks an item or dismisses it. Hence, there is no way that these methods do anything like that requested, AFAICT. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [HIGH] STR #2928: Shortcuts not precessed correctly on MacOS
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2928 Version: 1.3-current That's difficult to say... This is another kind of interference of making FLTK fully cross-platform and adhering to platform-specific standards. In my world ALT-letter doesn't produce text, and I can assume that our users are long accustomed to using these key combinations as shortcuts, as well as others may have used them (e.g. the OP). Currently we're not using MacOS, but this is planned for the future. So, I'd *like* to have ALT-letter as shortcuts on all platforms, but ... Just my 2 ct. Link: http://www.fltk.org/str.php?L2928 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
[sorry, if this is a double post - I clicked the wrong send button]
On 13.01.2013 19:22, Ian MacArthur wrote:
On 12 Jan 2013, at 03:17, Denton Thomas wrote:
Using Fl_Window (Fl_Double_Window) + set_non_modal() is definitely easier,
and does not hog input. Thanks for mentioning that, Ian.
New problem, though. Test code is below.
Regardless of what group/win type I use, mouse input will pass through the
popup to the window/widgets below. This acts like an insertion-order thing.
So, widget is drawn z-top, but it is z-below for input. I can fix the
input order by making sure the other widget additions occur before the
suggestion box.
In my project, though, I can't control/guarantee the insertion order of the
widget into the parent group ... so I'm a bit stumped.
Ideas? I'll keep reading docs/threads ...
(Without studying the sample code in all that much detail..) my initial
reaction is that the creation of the Fl_Window based SuggestionBox widget as
a member of your SuggestionInput widget, is causing it to be created as a
sub-window of the main window, rather than a window in its own right and
this is messing with the behaviour of the other widgets.
If you can put the SuggestionBox browser in a pop-up window, rather than
putting the pop-up windows inside the SuggestionBox, things might be simpler
and make it easier to control the ordering of windows / events / etc...?
Yes, I agree that the code seems to arrange the suggestion window as
a subwindow, since there is a parent group existing *at the time of
window creation*. Maybe there are also platform-dependent differences
concerning the arrangement of windows at the time of the window's first
show(), but anyway - keeping it clean is the best.
@Denton:
It can be done easily in the current SuggestionInput constructor, if
you don't want to change much code, like this (see comments below):
public:
SuggestionInput(int X, int Y, int W, int H, const char *n = NULL) :
Fl_Input(X, Y, W, H, n) {
Fl_Group *current_group = Fl_Group::current();// add (1)
Fl_Group::current(0);// add (2)
browser_ = new SuggestionBox(0, 0, W, 80);
Fl_Group::current(current_group);// add (3)
browser_-callback(static_browser_cb_, this);
browser_-hide();
browser_-anchor(this);
// try both with without ...
//if(browser_-parent()) browser_-parent(NULL);
}
(1) saves the current group, which would otherwise become the window's
parent group.
(2) resets the current group before window creation
(3) reverts (2).
Sorry, I don't have the time to do my own tests, so please try this
and tell us, if it changes the behavior.
Note that simply setting browser_-parent(NULL); is a *really BAD*
idea, since this MUST NOT BE USED in user code (see the docs).
Unfortunately this method exists, although it really should not exist
at all, but it's used for some special internal hacks.
http://www.fltk.org/doc-1.3/classFl__Widget.html#a6b57ff665a0e988064cb42d742668566
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
On 11.01.2013 14:27, Denton Thomas wrote: I am trying to create a little widget/group made of an Fl_Input (or text editor) and a drop-down-menu-like suggestions box. The end goal is to make something similar to an AJAX-y suggestions box found on google, or the firefox sites suggestions, etc. It's easy for me to create/fill/show a popup made of an Fl_Select_Browser inside an Fl_Menu_Window. If I use an Fl_Menu_Window, though, show() steals focus and the mouse cursor from my Fl_Input widget. I can't send back focus because the menu is a new window ... or at least I haven't figured out how to send it back ... ? As Ian wrote, I'm also not sure if Fl_Menu_Window is the best solution, but maybe this doesn't matter. I solved a similar, but different issue, and the best I can do is to describe what I've done to solve it. My problem was similar to FLTK's Fl_Choice widget. I have an input widget and another box (the usual one with the small triangle used to open that suggestion window). The user must click on the triangle box to open the suggestion window. My window is derived from Fl_Double_Window, but I also use set_override() to make it borderless, like Fl_Menu_Window. That's why I think that the window type wouldn't matter. Additionally I use Fl::grab() to make the suggestion/menu window take all events when it is opened. That's like a menu window, and steals focus from the input widget as you describe with your solution. But then, well, why would you need to give the focus back to the input widget? You don't need to do that if your handle() method of the window or its embedded browser widget has the focus (see Fl::grab()) and handles the input. It's some work, but you can do everything you like ... Add one character at a time to your input widget and update the browser widget whenever a key is pressed (FL_KEYBOARD event), put the selected value into the input widget's value() whenever a browser item is selected, and so on. The only problem I see with this approach is that the input widget indeed doesn't have the focus, and thus doesn't give much visible feedback like a cursor to show the current point of input. You may want to derive your own input class as well and make your own draw() method to show a cursor if you go that route. Maybe... Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 05.01.2013 23:01, Denton Thomas wrote:
Albrecht wrote:
What about adding here:
if (!contains(f_new)) focus_tracker_ = 0; // focus in another
group
if(f_new (f_new != focus_tracker_) contains(f_new)) {
focus_tracker_ = f_new; // focus_tracker_ = NULL in ctor
scroll_to(scroll_to_focus_x_(), scroll_to_focus_y_());
redraw();
}
return ret;
}
I guess that's because of cycles, yes?
No, sorry for being unclear. It's solely to detect that the current
focus_tracker_ variable value is invalid. This would enable you to
see when the current focus widget (inside your group) loses focus
and gets it again. Otherwise you wouldn't scroll the widget back
into the visible area in that case. However, you would only need to
do that, if the user scrolled the focus widget out with the scrollbars
or something like that...
So, if you want to save some (or more) CPU cycles, I'd recommend
checking what is really needed, and then filter events and/or do
some basic, but simple checks first.
I guess you're thinking it would be cheaper to break up the logical
AND comparisons? I hadn't considered that.
No, sorry again. I thought of events that are delivered to the scroll
widget, but ignored. There can be really *lots* of such events. There
is maybe the most important FL_MOVE, but there are also all events that
other widgets may ignore, like FL_ENTER, FL_LEAVE, drag'n'drop, etc..
The most important events after FL_MOVE would probably be FL_KEYUP and
FL_SHORTCUT. FL_KEYUP is ignored by almost all FLTK widgets, but FLTK
tries really hard to deliver all events ... (cited off the top of my
head from the docs elsewhere), so you can be sure that your scroll
widget WILL receive lost of FL_KEYUP events. FL_SHORTCUT will be sent
to (maybe) all widgets if the current focus widget and all parent
widgets ignore an FL_KEYBOARD event. You could say that all key events
are not really a problem, since most users won't type more than about
10 keys per sec., but you can probably see real CPU usage if you move
the mouse pointer fast over your scroll area. Maybe still not very
important, but you can get the idea...
I figured contains() was the most expensive/unpredictable step, so I
put contains() last.
That seems all okay. contains() moves up the parent() chain of the
widget you requested (i.e. parent(w) if you called contains(w)) until
either it finds the group (in this case the scroll widget) or it finds
the top widget (no parent). This can be a few pointer dereferences,
depending on your overall widget tree depth. Not something I'd be
much concerned about.
For my own applications, I also don't specifically need to know
whether focus is outside the group ... finding it is just a byproduct.
If your own application needs the flag, though, how about:
if (f_new (f_new != focus_tracker_) {
if(contains(focus_tracker_) {
... do the scroll, etc ...
}
else focus_tracker_ = 0;
}
This would avoid running contains() when focus doesn't change, but it
ensures a flag is 0 when focus is outside the group. I think the down
side is that contains() would -always- run when focus is outside the
group, even when focus does not change. I don't need that, but maybe you do!
Something like that, yes. Again, my intention was to detect
focus loss, so that you can act on the focus coming back.
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] RFC: Tracking the focus widget - would this be useful ?
On 06.01.2013 09:01, Greg Ercolano wrote:
On 01/04/13 05:22, Albrecht Schlosser wrote:
I'd like to know if there are more FLTK users who have the need
to track the widget that currently has the focus.
I wouldn't be against it.. sounds reasonable.
I could imagine something like a callback that could be called
whenever the current focus widget (Fl::focus()) changes. This
could be something like:
Fl::register_focus[_tracking] (my_widget,callback,arg)
Seems like:
Fl::add_focus_callback(cb, data);
Fl::remove_focus_callback(cb,data);
..would make sense.
void callback (Fl_Widget *w, long or void * arg, Fl_Widget *focus)
The last argument is just to avoid calling Fl::focus() each time
the callback is called, but could also be removed.
I'd prefer the user's callback code do the Fl::focus() call
(if it needs it) rather than a third arg so as to be consistent
with Fl_Callback and it's always easier to remember shorter arg lists.
Agreed, 100%. All good points.
Plus whatever few cycles are saved by preventing the user from calling
Fl::focus() are probably undone by the stack manipulations of handling
a third arg in the callback..
Yep, you're right, thanks. Calling Fl::focus() is a simple pointer
assignment, usually handled inline:
From FL/Fl.H:
static Fl_Widget* focus() {return focus_;}
Note also that I currently believe that the first argument I had in my
register... method should be dropped, because it's useless or redundant.
If someone would want to save the widget that is interested in the focus
change somewhere, s/he could use the data arg for this or save it
elsewhere.
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 04.01.2013 03:12, Denton Thomas wrote: Albrecht wrote: It's not perfect, and maybe some of the changes would turn out to be useless... just take it as a base for more own experiments. Thanks for all this, Albrecht. I'll certainly use those immediately. I appreciate it, as this is part of a current project. I'll keep testing re the style/redraw problem. I'm not sure what I'm doing wrong there - the box style changes just didn't appear on screen ... which was odd. I'll check out your patch to see how you've done it. You'll see that I did it by explicitly calling redraw() on the scroll widget (see the notes and the callback). You may need to call the parent's redraw method as well, if you have a frame box time somewhere, so that the redraw doesn't draw the background. As well, I caught a more glaring problem: if Fl::focus() is in a group inside of the Fl_Scroll, then it seems the Fl_Scroll::handle() method is not ever run ... so the focus tracking code can't run. I'll write a general test to make sure it's not my own Fl_Group subclass that's hogging the event chain, though. Oh, yes, that's certainly true. If navigation happens to succeed in a subgroup, then this subgroup does it all. No parent group will notice. You could maybe derive an own Fl_Group class to do this in conjunction with its parent YourScroll class, but this could be a never ending story, unless you know exactly what groups and widgets you need in your special case. In my case I'm using only simple widgets within the scroll and I handle it all in the child widgets, but this is a special case, since all /my/ child widgets are own classes anyway (and inherit from another common class as well - which is not generally recommended to do, but I did ...). Another issue I observed in your test case that I couldn't fix in my tests is this: click on the input field, then use SHIFT/TAB to go backwards into your group. This is not handled by the scroll widget. Go one more back with SHIFT/TAB, then forwards with TAB, and you'll see. Try also to move the scrollbar to scroll the last widget out of the visible area while the focus is on it or on the input widget, then use TAB and/or SHIFT/TAB. That's what I meant when I wrote that there's a problem when the focus leaves the scroll widget and comes back to it. Another small point: you tested that the same widget doesn't scroll if it gets the focus again, e.g. by mouse clicking. So, if you move the scroll area while one widget has the focus to move it partly out of the scroll area, then click on it again, it will stay where it is and doesn't scroll to be fully visible. This could be called a feature though... One last point: in your original test program I could sometimes make the input widget to get a red background. I hope this is fixed with my 2nd patch, but you should check this, if you intend to do something with the previous focus widget to make sure you don't modify a widget outside your scroll group. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 04.01.2013 10:05, Albrecht Schlosser wrote: the scroll widget (see the notes and the callback). You may need to call the parent's redraw method as well, if you have a frame box time somewhere, so that the redraw doesn't draw ... frame box TYPE ... (fingers faster than mind ;-) ) Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 04.01.2013 12:36, Denton Thomas wrote:
Albrecht wrote:
Oh, yes, that's certainly true. If navigation happens to
succeed in a subgroup, then this subgroup does it all. No
parent group will notice. You could maybe derive an own
Fl_Group class to do this in conjunction with its parent
YourScroll class, but this could be a never ending story,
unless you know exactly what groups and widgets you need
in your special case.
Perhaps this is solve-able after all. New handle() below. I like this version
a bit better, if only because it meets your original suggestion for a simple
solution.
Yup, simplicity rocks ;-)
int handle(int event) {
int ret = Fl_Scroll::handle(event);
Fl_Widget* f_new = Fl::focus();
What about adding here:
if (!contains(f_new)) focus_tracker_ = 0; // focus in another group
if(f_new (f_new != focus_tracker_) contains(f_new)) {
focus_tracker_ = f_new; // focus_tracker_ = NULL in ctor
scroll_to(scroll_to_focus_x_(), scroll_to_focus_y_());
redraw();
}
return ret;
}
I've deleted test_focus_() and scroll_to_focus_() functions as unused kruft.
All the rest remains untouched.
New handle() just checks if focus (1) has moved and (2) is somewhere in the
scroll group. I've done the membership test with contains(), which seems to
return true even if the focus widget is nested. So far, at least.
That's how contains() is defined, it *should* (and will) find nested
widgets - and the container widget itself as well.
I found the problem you mentioned re catching key combinations/order,
especially w/ Shift+Tab, etc.
This was only a test case and had nothing to do with the keys
pressed per se. I only used it as a means to leave the scroll
group and return easily.
If the above works, I can avoid the key problem altogether by ignoring the
event code. Otherwise it may be a bottomless pit of testing the
possible/accepted keycodes for changing focus. I -think- that the test above
will catch any method of changing to the focus widget. I also -think- it's
safe ... but I'll have to test some more.
There's nothing that could be wrong with it, IMHO. Just comparing
previous focus (or maybe an ancient predecessor if you left the
groupt meanwhile) with current focus can't be wrong.
The main oddity is that I've ditched testing whether the base handle()
returned 1. If I rely on that, I can't see nested widgets. Ignoring the value
seems alright, but maybe this does something bad that I haven't caught yet.
This was probably the reason why leaving the group couldn't be
handled, since this would return 0 from Fl_Scroll's handle() -
which means that the parent group should handle it. However,
then the focus change would also happen after returning from
handle, so this would probably not work either. :-(
One drawback of not testing any event type and/or the return
value would be more CPU time to do your checks all the time,
even if there is an FL_MOVE event. However, maybe *this* is what
triggers your focus checks eventually and makes it all work now.
So, if you want to save some (or more) CPU cycles, I'd recommend
checking what is really needed, and then filter events and/or do
some basic, but simple checks first.
Note that there is FL/names.h with the fl_eventnames[] array that
makes it simple to debug events with something like
printf(event = %3d: %s\n,event,fl_eventnames[event]);
In my tests I usually omit repeating FL_MOVE events, since they
can be annoying. YMMV
Since the placement code seems to be working [knock on wood], I've cut the
color changes / debug. Thanks for identifying how the color change happened
to the input field - I hadn't figured that one out.
You're welcome.
I'll post a new test unit when I've got it.
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] RFC: Tracking the focus widget - would this be useful ?
All, I'd like to know if there are more FLTK users who have the need to track the widget that currently has the focus. If this was a common problem, we could probably add something to FLTK to make this easier. It's not easy with current FLTK methods, as can be seen in the current discussion with the title scroll to focus in Fl_Scroll in fltk.general. http://www.fltk.org/newsgroups.php?gfltk.general+Q%22scroll+to+focus+in+Fl_Scroll%22 I could imagine something like a callback that could be called whenever the current focus widget (Fl::focus()) changes. This could be something like: Fl::register_focus[_tracking] (my_widget,callback,arg) to register interest in focus changes. In this case, each focus change would call the callback function like this: void callback (Fl_Widget *w, long or void * arg, Fl_Widget *focus) The last argument is just to avoid calling Fl::focus() each time the callback is called, but could also be removed. The first argument would be the widget (my_widget) the callback was registered for (this could also be NULL, if my_widget was NULL in the call to register_focus[...]. ... or something like that ... Any ideas, comments, wishes ? Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 04.01.2013 12:36, Denton Thomas wrote: New handle() below. I like this version a bit better, if only because it meets your original suggestion for a simple solution. Please see also my RFC in fltk.general: http://www.fltk.org/newsgroups.php?gfltk.general+v:35878 Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 03.01.2013 05:47, Denton Thomas wrote:
For both of you (Ian, Albrecht), here is my solution. It includes a test
sequence that produces some random buttons, and lets the client dynamically
change the size of the scrollbar. I wanted to allow a dynamic box style
change for the scroll group, but it didn't work for some reason ... it just
wouldn't redraw in the new style (???). I'm on 1.3.0 - I think I should just
update to the newest release.
Thanks in advance for any advice - this will certainly be helpful in my
current project.
I tried your test case, and it seemed to work mostly.
Concerning the scrollbar size changes, here's a diff that makes
it work. I put the scroll_ widget in the user_data argument to
access it in the callback and set the scrollbar size. Note that
you changed the global scrollbar size variable, whereas my patch
changes only that of this particular scroll widget.
diff --git a/Track_Focus_Scroll-Main.cpp b/Track_Focus_Scroll-Main.cpp
index cb89b47..0360aef 100644
--- a/Track_Focus_Scroll-Main.cpp
+++ b/Track_Focus_Scroll-Main.cpp
@@ -186,8 +186,9 @@ void set_scrollbar_size_cb_(Fl_Widget *src, void *dat) {
int x = atoi(((Fl_Int_Input *)src)-value());
- Fl::scrollbar_size(x);
- printf(Set scrollbar size to %d\n, x);
+ Fl_Scroll *scroll = (Fl_Scroll *)dat;
+ scroll-scrollbar_size(x); scroll-redraw();
+ printf(Set scrollbar size to %d\n, x); fflush(stdout);
}
void setup() {
@@ -238,7 +239,7 @@ void setup() {
s = new Fl_Int_Input(scroll_-x() + scroll_-w() + 10, scroll_-y(),
50, 35, scrollbar size);
s-labelsize(9);
s-align(FL_ALIGN_TOP);
-s-callback(set_scrollbar_size_cb_, NULL);
+s-callback(set_scrollbar_size_cb_, scroll_);
win_-resizable(scroll_);
win_-end();
I don't really understand what you mean with I wanted to allow a
dynamic box style change for the scroll group, but it didn't work for
some reason ... it just wouldn't redraw in the new style (???).
I assume that the problem was triggering the redraw(), and the solution
is in my patch. Or was this something else?
I also experimented a little more to remove some artifacts when
the focus leaves the scroll widget and/or comes back to it. My
time doesn't allow more comments now, I'm just posting another
diff that should be applied after the first one. Just try to
understand what it does, and experiment with the diff's in it.
It's not perfect, and maybe some of the changes would turn out
to be useless... just take it as a base for more own experiments.
diff --git a/Track_Focus_Scroll-Main.cpp b/Track_Focus_Scroll-Main.cpp
index 0360aef..f042f66 100644
--- a/Track_Focus_Scroll-Main.cpp
+++ b/Track_Focus_Scroll-Main.cpp
@@ -45,12 +45,14 @@ class Track_Focus_Scroll : public Fl_Scroll {
/** if Fl_Scroll:handle() manages event Fl::focus() changes, call
adjust_scroll_() to manage scroll bars */
int handle(int event) {
+if(!contains(Fl::focus())) focus_tracker_ = 0;
+// if(event == FL_UNFOCUS) focus_tracker_ = 0;
int ret = Fl_Scroll::handle(event);
+if(!contains(Fl::focus())) focus_tracker_ = 0;
-if((event == FL_KEYBOARD) || (event == FL_PUSH)) {
+if((event == FL_KEYBOARD) || (event == FL_SHORTCUT) || (event ==
FL_PUSH)) {
if(ret scroll_to_focus_()) redraw();
}
-
return ret;
}
@@ -65,17 +67,20 @@ class Track_Focus_Scroll : public Fl_Scroll {
*/
int test_focus_() {
// if widget is not a widget inside of the scroll group, end.
-if(focus_tracker_ == Fl::focus()) return 0;
+if(focus_tracker_ (focus_tracker_ == Fl::focus())) return 0;
// record new focus ...
if(focus_tracker_) focus_tracker_-color(FL_BLUE);
focus_tracker_ = Fl::focus();
-focus_tracker_-color(FL_RED);
if((!focus_tracker_-inside(this)) ||
(focus_tracker_ == scrollbar) || (focus_tracker_ ==
hscrollbar) ||
- focus_tracker_-inside(scrollbar) ||
focus_tracker_-inside(hscrollbar))
+ focus_tracker_-inside(scrollbar) ||
focus_tracker_-inside(hscrollbar)) {
+ focus_tracker_ = 0;
return 0;
+}
+
+focus_tracker_-color(FL_RED);
return 1; // scroll to it!
Hth
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 01.01.2013 23:39, Ian MacArthur wrote:
On 1 Jan 2013, at 21:44, Denton Thomas wrote:
My thinking is that this *should* work and would mean that only one
special derived widget is needed, rather than having to make every
contained widget be a special widget.
Yep, I agree. I've just made a template to add the handlers to any old
widget, but it seems like a kludge.
From what I can tell, an Fl_Group does not parse events if they are
already within the group. If I tab from one widget to another, within the
group, the event never goes through Fl_Scroll:handle(). So the group never
knows to check whether focus has changed hands/positions.
At least I don't -think- it does ... I'll test some more.
Ah... that was what I was worried about, perhaps...
(Paraphrasing somewhat...) Normally, events in fltk get propagated from the
container widget (e.g. group or scroll) down to its children, until one of
them takes it.
Correct.
But I suspect that keyboard events get routed *first* to the widget with
focus, and only if it doesn't want them, do they get passed to the container
widget to be distributed.
Yep, correct as well.
And so I guess it is possible that keyboard nav events would go to the focus
widget
True so far...
without necessarily passing through the parent container at all. And thereby
rendering my cunning scheme useless.
Yep, that's also correct, but fortunately normal FLTK widgets don't
*use* the navigation keys. Hence, navigation key events usually return
zero from the widget's handle() method, and the group gets it.
Oh well. If you look into this further, be handy to know for sure if this is
the way things are!
Eventually, when the group gets the key event, there is this code
in Fl_Group::handle():
case FL_KEYBOARD:
return navigation(navkey());
and this method at line #315 in current svn (r 9783):
// try to move the focus in response to a keystroke:
int Fl_Group::navigation(int key) {
...
}
So the approach to subclass Fl_Scroll should work as suggested.
It could maybe need just a little code in handle(), something
like this might suffice:
MyScroll::handle(int event) {
Fl_Widget *fw = Fl::focus(); // save focus widget
int ret = Fl_Scroll::handle(event);
if (ret fw != Fl::focus) { // event used and focus changed
// check focus widget and scroll ...
// your design decision here how to manage scrolling
// returns wx and wx to scroll to
scroll_to(wx,wy);
}
return ret; // return Fl_Scroll/Fl_Group's return value
}
So far this simple code. Maybe you'd want to also check for
FL_KEYBOARD and/or FL_SHORTCUT events, but that's probably not
necessary.
That said, I have done it in my own code also in all the child
widget classes, but I had shared code in my child classes anyway,
so this was the easiest approach for me at that time.
I'll check if I can use this simple code in my own app as well,
but this will not be done soon. So don't hold your breath for
any more info from me concerning this approach.
To the OP: I'd be interested in your feedback, if it works this
way for you, and in any corrections you need to make.
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 02.01.2013 13:14, Albrecht Schlosser wrote:
So the approach to subclass Fl_Scroll should work as suggested.
It could maybe need just a little code in handle(), something
like this might suffice:
MyScroll::handle(int event) {
Fl_Widget *fw = Fl::focus(); // save focus widget
int ret = Fl_Scroll::handle(event);
if (ret fw != Fl::focus) { // event used and focus changed
should read: if (ret fw != Fl::focus()) { ...
// check focus widget and scroll ...
// your design decision here how to manage scrolling
// returns wx and wx to scroll to
should read: // returns wx and wy to scroll to
scroll_to(wx,wy);
}
return ret; // return Fl_Scroll/Fl_Group's return value
}
And note that this is untested code.
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Time out Reentrance on Windows
On 02.01.2013 12:12, claude roux wrote:
[please see also Ian's post about Fl::repeat_timeout() and others]
The way I use FLTK encompasses some level of re-entrance. However, I
discovered a little problem in the way add_timeout is used on Windows. If I
initialize a first timeout, it works like a charm... If I try to relaunch a
new timeout within the same application, then it does not work anymore.
I have investigated a little bit, and I have discovered that in order to
re-use a timer in the same application, I needed to reset the value of
s_TimerWnd to 0 in fl_win32.cxx.
For the moment, I have implemented a small function, which does that (the
variable is static)
void FlResetTimer() {
if (s_TimerWnd)
s_TimerWnd=0;
}
I suppose there is a better way to have this variable reset in a different
place, but for the moment, it seems to suffice.
Setting s_TimerWnd to 0 means asking for Windows resource leaks,
since the next add_timeout() call would create a new (hidden)
window w/o destroying the former. Bad idea...
What kind of reentrance do you mean? Are there different timers
overlapping each other, or is this one time that needs to be
adjusted somehow? With different I mean logically different
cases - if it is so, then the callback argument to add_timeout
*should* be different, since this is the timer's *id* in the
timer queue.
If you have logically the *same* timer function occurring
overlapped in a reentrant way (i.e. with the same callback
argument), then it will probably get more complicated. If
you want all timers to trigger independently, then I assume
that you'd have to manage timer events by yourself somehow.
That said, if you still believe that the Windows timeout
mechanism has a bug (after considering your use case and
maybe using remove_timeout, repeat_timeout etc.), then please
try to post a simple(?), self-contained demo source file so
that we can try it and test.
Important question: you wrote in the way add_timeout is used
on Windows. Does this mean that it works for you on other
platforms as expected, or did you only test on Windows?
BTW: Once I tested Fl::repeat_timeout() and it seemed that
the Windows version doesn't work as specified (and as the
linux version DOES), because timers aren't scheduled correctly
in the intervals given (elapsed time differences are not
calculated correctly, or something like this). So, there
*may* be issues with the Windows timer code...
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 02.01.2013 14:12, Denton Thomas wrote:
On 02.01.2013 13:14, Albrecht Schlosser wrote:
..
Fl_Widget *fw = Fl::focus(); // save focus widget
int ret = Fl_Scroll::handle(event);
if (ret fw != Fl::focus) { // event used and focus changed
..
Albrecht
Thanks for all this, Albrecht. I started mucking with an Fl_Scroll subclass
custom handle(), and decided to track the focus widget in the same way as
you. I hadn't though to cut the test down to that one if statement - big help.
You're welcome, I'm glad if I could help.
Here's something I forgot: you should also check if the
focus widget after Fl_Scoll::handle() is
(a) a child of your scroll widget, and
(b) NOT one of the scrollbars.
There are public members scrollbar and hscrollbar in Fl_Scroll.
Do NOT assume that the scrollbars are the last members of Fl_Scroll,
since this can change...
Now working on determining dx/dy. I'll post my subclass when I'm all done.
Looking forward to your post...
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Amalgamation
On 31.12.2012 13:48, Matthias Melcher wrote: But back to amalgamation/modularization: technically, there is no difference between g++ myApp.cpp fltk/Window.cxx fltk/Widget.cxx fltk/run.cxx -o myApp and g++ -c fltk/Window.cxx g++ -c fltk/Widget.cxx g++ -c fltk/run.cxx ar WIndow.o Widget.o run.o -o fltk.lib g++ myApp.cpp -l fltk -o myApp Well, in my experience there *are* big differences between these two ways. See comments below. And while the second version seems more involved, it is actually much faster because it only needs to run those lines that are associated with files that actually changed. Here you assume that you also have a make system that decides what to compile from (a) changes in source files and (b) dependencies. This is not the case in the simple compile-and-build case, especially if we compare with the all-in-one-file amalgamation. Setting the linker correctly will remove all unused code from the final executable, so there is no harm in adding more files. Again an assumption that doesn't hold generally. If we are talking about default linker behavior, then the second method would select only used files, whereas the former would include all object files (at least from my knowledge and experience). Setting the linker correctly... would IMHO be very much platform- dependent and can not be assumed to be even possible in all cases, at least NOT for the first case. FLTK does require a pre-compile configuration pahse though, simply because it supports so many configurations, especially for X11. The advantage is that FLTK will run on even the smallest embedded Linux device, to a certain degree even without X11. There is simply n way to do that at compile time only. I agree, but what does the pre-compile phase do? It writes a config file with some #define's (and/or omits others). Nothing of this would preclude an amalgamation. But then again it's not THAT simple to use just one file for all configurations. That's the point. To me, it's fine if users want to compile fltk cxx files instead of using the library. We could provide a default configuration that just works for current machines, but for older systems, we still need autoconf. Yup, so we'd need n (how many?) pre-configured and platform dependent header files (config_windows.h, config_mingw.h, config_X11.h, ... ?) and maybe only one amalgamation file that includes all sources. Maybe... Again, I don't think that we should discuss changing the main FLTK development way. It's good as it is, but an amalgamation could make sense as an additional way for (a) beginners and (b) people who like that amalgamation idea for whatever reasons. -- Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Amalgamation
On 30.12.2012 11:23, Ian MacArthur wrote: On 29 Dec 2012, at 16:28, Matthias Melcher wrote: So it seems they went from amalgamation to modularization in which the source files are included into the main build. Modularization I can see the point of: I've used that myself, where we switched from compiling a lib to selecting *just the needed sources* directly into the build. However, AFAIK, an amalgamation of fltk would have two big disadvantages for me: ... For my part, I still think our static lib approach is the best fit for almost all use cases, and am not all that keen to change to somethng less time proven... Having read all the discussions and seen this post, I think that this pro-and-con discussion doesn't bring us much further. Instead, we should think about whether we (the dev's, and I'm one of them, as most of you know) can achieve something to help those who would like to have an amalgamation of FLTK. I also think that it has become clear already that the FLTK dev's don't want this as the primary source of FLTK, which would, as has already been written, be a nightmare for the developers (aspect of maintainability). Also, the bigger size of the compiled code WOULD matter for those addressing embedded systems, which is one of FLTK's design goals and should not be forgotten. Conclusion: we can only create an amalgamation in a pre-distribution process that could be (a) included in the normal source tarballs (b) made available as a separate download file. If at all, I'd prefer the latter, since this is nothing we should include in all the tarballs for all users, because I think that the majority would use the normal sources. Others may think differently about that last point, but IMHO it's useless to discuss this *now*. So, IMO the question is: can we provide a (select one or more of:) script, makefile, or whatever to copy the source files in one source file (and one header file?) that could be distributed as the amalgamation, or would this be too much effort? Would we have to change the/many source files to achieve this? What else? Platform dependent amalgamation files, maybe? ... If this was easy to do, then why shouldn't we do it? However, if we'd need to change source files to make it work or add more and more #if ... #endif, then I'd clearly say no, since the devs seem to agree that it's not a useful thing (from our own view). But if other users like it or if it is an argument to try to use FLTK in a simple way for beginners? Maybe it could be worth the effort. Albrecht P.S. Happy new year to all ! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [MOD] STR #2911: Library can't be compiled under clang 3.1
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.3 (r9750) Thanks for confirmation. I'm leaving this STR open as a reference so others can find it. At least for now... Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.3 (r9750) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2911: Library can't be compiled under clang 3.1
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.2 Thanks for the report, but this is already fixed in the Subversion repository. Could you please try a subversion download, or the patch posted in STR #2903 [1], or a newer snapshot [2]? [1] http://www.fltk.org/str.php?L2903 http://www.fltk.org/strfiles/2903/str_2903.patch [2] http://www.fltk.org/articles.php?L1270 or later ... Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2911: Library can't be compiled under clang 3.1
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.3 (r9750) Correction: Fix Version will be 1.3.3 (was 1.3.2). Link: http://www.fltk.org/str.php?L2911 Version: 1.3.2 Fix Version: 1.3.3 (r9750) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2705: FL_EXPORT that should not exist: See STR #2632 for FL_Button subclasses
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2705 Version: 1.3-current Fix Version: 1.3.2 This STR has not been updated by the submitter for two or more weeks and has been closed as required by the FLTK Configuration Management Plan. If the issue still requires resolution, please re-submit a new STR. Link: http://www.fltk.org/str.php?L2705 Version: 1.3-current Fix Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1679: Borderless windows on WIN32 do not appear on the taskbar
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1679 Version: 1.4-feature FWIW, meanwhile (in FLTK 1.3 and later) we have: int Fl_Window::menu_window() that can be used to test whether a window is a menu (window). This would simplify the proposed patch and get rid of having to set a specific window class for menus - although that could be useful as well, maybe... Link: http://www.fltk.org/str.php?L1679 Version: 1.4-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [RFE] STR #2879: Better RTTI support
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2879 Version: 1.3-feature Fix Version: 1.3-current This STR has not been updated by the submitter for two or more weeks and has been closed as required by the FLTK Configuration Management Plan. If the issue still requires resolution, please re-submit a new STR. Link: http://www.fltk.org/str.php?L2879 Version: 1.3-feature Fix Version: 1.3-current ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Amalgamation
On 26.12.2012 18:12, Ian MacArthur wrote: On 26 Dec 2012 15:35, superbem super...@gmail.com wrote: I was seeking for a FLTK Amalgamation with no luck. An Amalgamation of FLTK will be very straightforward. Please consider. (reply) Um, I don't understand what's being asked here. Anybody? The OP is probably asking for FLTK as a single source file to be compiled and linked in an application, like sqlite3: http://www.sqlite.org/amalgamation.html One of the arguments for this amalgamation of sqlite3 is speed because of some more optimizations if everything is compiled in one file. Maybe this would be interesting for a database like sqlite3, but I don't think that FLTK would benefit much. That said, one of FLTK's main points is that it's small (light) and fast. The downside of the amalgamation would be to compile and link ALL FLTK code into the application, and the compiled code would maybe also be larger (because of more inlining, see also the link above). Well, I don't think that we (the devs) would (should) support this, but if someone would do it for himself (for some reasons I don't) know), why not? To the OP: why do you want to have this, what do you want to achieve with it? - or am I wrong with my assumption ? -- Albrecht ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] How to open a folder from a hard-drive partition ?
On 20.12.2012 19:34, Greg Ercolano wrote: Albrecht writes: fl_open_uri(file:///c:/samples) should work. Note the triple '/'.. Hmm, is the third slash needed? I don't know if it works with two slashes by chance, but ... Probably both work, but I think two slashes followed by the path is correct. http://en.wikipedia.org/wiki/File_URI_scheme Yep, it's file://host/path..., and if there is no host given, then it's the local host - as far as I understand it. Should be easy to test, but what is the most portable way? .. and citing Wikipedia from your link above: Note that when omitting host you do not omit the slash (file:///foo.txt is okay, while file://foo.txt is not, although some interpreters manage to handle the latter). -- Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Problem creating a second modal dialog
On 18.12.2012 23:48, Ian MacArthur wrote: On 18 Dec 2012, at 18:18, Chris Shearer-Cooper wrote: We are using fltk 1.3.0rc2; I'm displaying a modal dialog by calling set_override() and set_modal(), ... ... So, try just the set_modal() and see how that goes. Any suggestions how I can force fltk to display the second modal dialog on top of the first? You don't say what platform you are on, but on X11 or WIN32 that ought to pretty much just work - though it might be a good idea to call show() on your prior modal window, just before you set the new one modal and show it, as in some cases I have found (probably superstition) that doing so helps ensure the transient property gets the right parent and so forth... I believe that this is a good way to force the correct window hierarchy in terms of transient property and so on. Once I was trying to fix a problem [1] with modal and menu windows (and it worked partially in my tests) by setting additional window attributes (e.g. menu_window()) so that we could find the correct (or: at least a better fitting) parent window in the window list, but this was never completed... :-( Anyway, calling show() on the first modal window before calling show() for the new window will put the first modal window on top of FLTK's internal window list and make it more likely to be selected as the parent window of the new one. On OSX, I have found that having multiple modal windows can be a bit fragile, OSX does not really have the concept of modal windows, and the way we enforce it used to be a bit flaky at times; though that said it seems a lot better these days, so your ought to be fine! I can't comment on OSX. Albrecht [1] If you tried to open a modal window while a menu was open, then the menu window would become the (a) Windows: parent window or (b) Linux/Unix/X11: get the transient attribute/relationship of the modal window. Then, when you closed the menu window, the modal window would be closed too. This is probably still the case, and IIRC there's a STR for this, but I don't know which one right now. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature FWIW: doing this as Ian suggested means that the gtk development files (headers etc.) must be present on the /developer's/ machine. So we'd have to add a configure check and #if.../#endif around the corresponding gtk wrapper code. But that would be doable as well. Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [MOD] STR #2903: Fl_X accesses protected member of Fl_Widget
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2903 Version: 1.3.2 Fix Version: 1.3.3 (r9750) Fixed in 3.0 as well (svn r 9751). Link: http://www.fltk.org/str.php?L2903 Version: 1.3.2 Fix Version: 1.3.3 (r9750) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2903: Fl_X accesses protected member of Fl_Widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2903
Version: 1.3.2
Hmm, you marked Scope 2 (Specific to an operating system), but didn't tell
us which one...
Anyway, according to the line numbers, this must be U*X, Linux, OS X ?
Thanks for the patch, but that's probably not what we want. The proper way
should be to use fullscreen_active() instead of using the flag directly.
Could you please try the attached patch instead ? (And please don't forget
to revert your changes). Does this work with clang?
Link: http://www.fltk.org/str.php?L2903
Version: 1.3.2Index: src/Fl_x.cxx
===
--- src/Fl_x.cxx(revision 9749)
+++ src/Fl_x.cxx(working copy)
@@ -1873,7 +1873,7 @@
// since we do not want save_under, do not want to turn off the
// border, and cannot grab without an existing window. Besides,
// there is no clear_override().
- if (win-flags() Fl_Widget::FULLSCREEN !Fl_X::ewmh_supported()) {
+ if (win-fullscreen_active() !Fl_X::ewmh_supported()) {
attr.override_redirect = 1;
mask |= CWOverrideRedirect;
Fl::screen_xywh(X, Y, W, H, X, Y, W, H);
@@ -1940,7 +1940,7 @@
}
// If asked for, create fullscreen
-if (win-flags() Fl_Widget::FULLSCREEN Fl_X::ewmh_supported()) {
+if (win-fullscreen_active() Fl_X::ewmh_supported()) {
XChangeProperty (fl_display, xp-xid, fl_NET_WM_STATE, XA_ATOM, 32,
PropModeAppend, (unsigned char*)
fl_NET_WM_STATE_FULLSCREEN, 1);
}
@@ -1984,7 +1984,7 @@
}
// non-EWMH fullscreen case, need grab
- if (win-flags() Fl_Widget::FULLSCREEN !Fl_X::ewmh_supported()) {
+ if (win-fullscreen_active() !Fl_X::ewmh_supported()) {
XGrabKeyboard(fl_display, xp-xid, 1, GrabModeAsync, GrabModeAsync,
fl_event_time);
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2903: Fl_X accesses protected member of Fl_Widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2903 Version: 1.3.2 Fix Version: 1.3.3 (r9750) Fixed in Subversion repository. Thanks for quick confirmation, this is now in svn r 9750. Link: http://www.fltk.org/str.php?L2903 Version: 1.3.2 Fix Version: 1.3.3 (r9750) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2900: ScrollGroup bug in fltk-3.0
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2900 Version: 3.0 See also original posting in fltk.bugs: http://www.fltk.org/newsgroups.php?gfltk.bugs+v:11981 with test code and diff and maybe follow-up's here: http://www.fltk.org/newsgroups.php?gfltk.bugs+Q%22ScrollGroup+bug+in+fltk-3.0%22 Link: http://www.fltk.org/str.php?L2900 Version: 3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [RFE] STR #2745: fltk-3 window origin
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2745 Version: 3.0-feature changed from 2.0-feature to 3.0-feature Link: http://www.fltk.org/str.php?L2745 Version: 3.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Keyboard Extension with function keys
On 08.12.2012 00:36, D E Maynard wrote: You could try storm700/900 series keypads. These have removable key legend tiles so you could substitute you own tactile ones. They are waterproof as well. http://www.storm-interface.com/products_description.asp?id=8 Hope this helps. Thanks, I appreciate all hints and links. Link saved. Albrecht ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [LOW] STR #2901: Fl_Browser format codes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current @1: 'N' format code undocumented: should be added to docs. @2: literal '@': Hmm, I don't know what it's exactly intended to do, but the while loop started some lines above has *str != format_char(), so this is in fact format_char() != '@' followed by '@' ? Just wanted to add my *observation*, w/o further analysis. What is it intended to do there, and is that documented correctly? Or am I missing something? Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2901: Fl_Browser format codes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current The documentation is ... ambiguous at best: http://www.fltk.org/doc-1.3/classFl__Browser.html#a6b4d3525d8d9fccfc748d824b39f250b '@@' Print rest of line starting with '@' Obviously the first '@' is meant to represent the current format_char(), but the second '@'? Literal '@' or also format_char()? I tend to read it as the latter, but ... (a) then the code posted above in the while loop doesn't make sense (b) how to represent a single @ sign and continue parsing format_char()? Is this not possible? At least I can't find it unambiguously in the docs. Or does Print rest of line mean Print with parsing '@' signs (format_char()'s) ??? Still confused ... It's not clear to me whether the code is correct at all, whatever is documented or not. Does anybody know what is really meant in the docs? Link: http://www.fltk.org/str.php?L2901 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
