Re: [fltk.development] fltk and high res retina display?
Indeed, that did the trick! Thanks so much! I updated my make_bundle script, presumably fltk could do the same with the official one, provided there are no side-effects on non-retina systems. I think Manolo has already tweaked the plist files in the fltk-1.3 svn... Selex ES Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ 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) Thanks Greg for implementing exactly what I was getting at. I still have a few remarks about the current implementation of: Fl_Window* Fl_Widget::top_window_offset(int, int) - The doc should say 'current widget' instead of 'current window' because a widget is now current. - I feel the widget-to-window cast const Fl_Window *win = (const Fl_Window *)this; is frightening, because widgets are not windows, in general. It works here because only member functions from the parent Fl_Widget class are employed. Rewriting it Fl_Widget *win = (Fl_Widget*)this; does just the same, removing the fear. - This implementation applied to a window-less widget returns this widget cast as a window, a potentially dangerous thing. My suggestion would be to use (again) our friend Fl_Widget::as_window(). The attached window.patch gathers all of this. 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 #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)
Attached file window.patch...
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Fix Version: 1.3-current (r9871)Index: src/Fl_Window.cxx
===
--- src/Fl_Window.cxx (revision 9873)
+++ src/Fl_Window.cxx (working copy)
@@ -107,19 +107,19 @@
}
/**
- Finds the x/y offset of the current window relative to the top-level window.
+ Finds the x/y offset of the current widget relative to the top-level window.
\param[out] xoff,yoff Returns the x/y offset
- \returns the top-level window
+ \returns the top-level window (or NULL for a widget that's not in any window)
*/
Fl_Window* Fl_Widget::top_window_offset(int xoff, int yoff) const {
xoff = yoff = 0;
- const Fl_Window *win = (const Fl_Window*)this;
+ Fl_Widget *win = (Fl_Widget*)this;
while (win win-window()) {
xoff += win-x(); // accumulate offsets
yoff += win-y();
win = win-window(); // walk up window hierarchy
}
- return (Fl_Window*)win;
+ return win-as_window();
}
/** Gets the x position of the window on the screen */
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2949: align options for tabs
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2949 Version: 1.3-feature It appears that there is no way to set the alignment attribute for the tabs of a Fl_Tabs widget. It seems to be hardcoded to FL_ALIGN_CENTER. This is a problem when trying to display an icon along with some text for which the FL_ALIGN_IMAGE_NEXT_TO_TEXT would be better. I would really appreciate it if an option was added that allows users to set the alignment attribute for tabs. Thanks! Steve Link: http://www.fltk.org/str.php?L2949 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[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
Currently clicking on ANY menu item causes the whole menu to close - which
is sometimes annoying, even if the item is:
1) A submenu. Usually submenu is just an entry point and mouse hovering
opens the submenu automatically, an accidental clicking on this entry
point should not
close the whole menu. Not closing the menu would also indicate that no
action was performed and choosing particular submenu-item is required to
invoke an action
2) A checkbox or radio box. If menu item group is set of check-boxes and
user wants to change a few settings at the same time, he/she needs to
reopen the menu for each single item change. Sometimes user re-opens the
menu even for single checkbox just to visually confirm that the state was
changed. In such a case they expect that menu closes only if you either
hit Esc or click menu-opening widget (menu-bar or menu-button)
Following is an implementation (just included in this message for
simplicity) to give the developper fine control. It is very conservative
(does not change current behaviour) but adds the programmer possibility to
control when the items close the menus.
The API consists of two additional functions, they are implementad as
static of Fl_Menu_Item namespace:
class Fl_Menu_Item {
...
public:
static void no_close_flags(int f){no_close_flags_ = f;}
static int no_close_flags(){return no_close_flags_;}
private:
static int no_close_flags_;
};
The user can globally change how when the items do not close the menus -
ie at the beginning of the program:
Fl_Menu_Item::no_close_flags(FL_MENU_TOGGLE|FL_MENU_RADIO|FL_SUBMENU|FL_SUBMENU_POINTER);
User can also control the items individually like:
#define FL_MENU_NO_CLOSE 0x200
Fl_Menu_Item::no_close_flags(FL_MENU_NO_CLOSE);
and then OR this custom flag to the other flags of particular menu items.
Implementation:
1) In file Fl_Menu_Item.H define the functions as rescribed above
2) In file Fl_Menu.cxx change code in function
menuwindow::early_hide_handle(int e), line approx. 783:
#if 1 // uncommenting - makes defined items leave the menu up
const Fl_Menu_Item* m = pp.current_item;
if (m button (m-flags Fl_Menu_Item::no_close_flags())) {
((Fl_Menu_*)button)-picked(m);
pp.p[pp.menu_number]-redraw();
} else
#endif
3) In file Fl_Menu_.cxx implement
int Fl_Menu_Item::no_close_flags_ = 0;
and change code in function Fl_Menu_::picked() from line approx 271:
if (value_ value_-callback_)
value_-do_callback((Fl_Widget*)this);
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();
}
The code was tested and everything works as expected.
Roman
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_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) @manolo: Great -- agree with all, except perhaps loosing const here: - const Fl_Window *win = (const Fl_Window*)this; + Fl_Widget *win = (Fl_Widget*)this; I think we can maintain const protection on the variable this way: const Fl_Widget *win = this; : return ((Fl_Widget*)win)-as_window(); ..this ensures const protection for all uses of win within the code, and we only turn it off when we need to (eg. the non-const as_window() call) Also, I should probably change all instances of 'win' - 'w' in the code, since it's really working with widgets now. Thanks for the peer review -- will hold on comments regarding const above, as am curious if there's a reason not to. 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
We can probably avoid breaking ABI if we implement this new bitflag
as part of the existing flags, eg:
enum { // values for flags:
:
FL_MENU_NOCLOSE = 0x200 // Don't close menu if submenu|checkbox
clicked
};
Unless I'm missing something, is there a reason to avoid this?
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 Oh, I see, you are suggesting this, /and/ a global flag to affect the entire menu, yes. I guess we can't avoid breaking ABI for the global flag, which is probably best implemented in Fl_Menu_ by adding an int to the class, protected by our new ABI macro so it can be used during patch releases) 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 I have put the functions in Fl_Menu_Item namespace only because maming them that way seems to make sense. As far as I know, static functions (and static class variables) do not break ABI: they are not really class members, just additional ordinary functions and global variables with fancy naming sugar (functions with class namespace scope). For that matter even addition of a non-virtual class function should not break ABI either - any compiler guru can confirm this or am I wrong? Anyway, the function is to set a mask which menu-item flags should indicate not to close the menu. In that way an existing application could take advantage of new behaviour automatically (especially those pesky submenu items) just by adding simple Fl_Menu_Item::no_close_flags(FL_MENU_TOGGLE|FL_MENU_RADIO|FL_SUBMENU|FL_SUBMENU_POINTER); or whatever flags you want at the beginning of the program. But if the user wants old behaviour and set only a few items explicitly, he can always define his own flag and set Fl_Menu_Item::no_close_flags(...) mask to this custom flag only. R. 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
