Re: [fltk.bugs] [LOW] STR #2947: Drawing Things in FLTK / minor fixes
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. I frequently am. But even if I did recover/reset the subversion access password, that still wouldn't free up any time to work on FLTK [or Lunar Linux] and first I would need that time to resurrect a dead computer... :-( D ___ 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 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 Ok, I'll try your suggestions and in case of problems I'll ask on the mailing list. Thanks for the fast answer and sorry for posting this as a bug. 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
[fltk.bugs] svn access / fltk.org changeover?
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. 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'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? ___ 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.bugs] [HIGH] STR #2944: Mac OS X Fl_Gl_Window bugs - all FLTK versions
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2944 Version: 1.3.2 As a side note, in r9870, the new method suggest here to find the top-level window's offset relative to the current widget has been renamed to: top_window_offset(xoff,yoff) Link: http://www.fltk.org/str.php?L2944 Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.commit] [Library] r9870 - in branches/branch-1.3: FL src
Author: greg.ercolano
Date: 2013-04-10 13:13:12 -0700 (Wed, 10 Apr 2013)
New Revision: 9870
Log:
While suggesting a new top_window() method for STR#2948,
it's realized that for consistency, the recently added window_offset() method
(a few days ago) should be renamed to top_window_offset().
Modified:
branches/branch-1.3/FL/Fl_Window.H
branches/branch-1.3/src/Fl_Gl_Window.cxx
branches/branch-1.3/src/Fl_Window.cxx
Modified: branches/branch-1.3/FL/Fl_Window.H
===
--- branches/branch-1.3/FL/Fl_Window.H 2013-04-09 20:11:28 UTC (rev 9869)
+++ branches/branch-1.3/FL/Fl_Window.H 2013-04-10 20:13:12 UTC (rev 9870)
@@ -120,7 +120,7 @@
\see force_position(int)
*/
int force_position() const { return ((flags() FORCE_POSITION)?1:0); }
- Fl_Window* window_offset(int xoff, int yoff) const;
+ Fl_Window* top_window_offset(int xoff, int yoff) const;
public:
Modified: branches/branch-1.3/src/Fl_Gl_Window.cxx
===
--- branches/branch-1.3/src/Fl_Gl_Window.cxx2013-04-09 20:11:28 UTC (rev
9869)
+++ branches/branch-1.3/src/Fl_Gl_Window.cxx2013-04-10 20:13:12 UTC (rev
9870)
@@ -184,7 +184,7 @@
if (window()) {
int xoff,yoff;
-const Fl_Window *win = window_offset(xoff, yoff); // STR #2944 [2]
+const Fl_Window *win = top_window_offset(xoff, yoff); // STR #2944 [2]
xywh[0] = xoff;
xywh[1] = win-h() - yoff - h();
} else {
Modified: branches/branch-1.3/src/Fl_Window.cxx
===
--- branches/branch-1.3/src/Fl_Window.cxx 2013-04-09 20:11:28 UTC (rev
9869)
+++ branches/branch-1.3/src/Fl_Window.cxx 2013-04-10 20:13:12 UTC (rev
9870)
@@ -283,7 +283,7 @@
\param[out] xoff,yoff Returns the x/y offset
\returns the top-level window
*/
-Fl_Window* Fl_Window::window_offset(int xoff, int yoff) const {
+Fl_Window* Fl_Window::top_window_offset(int xoff, int yoff) const {
xoff = yoff = 0;
const Fl_Window *win = (const Fl_Window*)this;
while (win win-window()) {
___
fltk-commit mailing list
fltk-commit@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-commit
[fltk.commit] [Library] r9871 - in branches/branch-1.3: FL src
Author: greg.ercolano
Date: 2013-04-10 13:51:24 -0700 (Wed, 10 Apr 2013)
New Revision: 9871
Log:
Solve STR#2948: Add new method Fl_Widget::top_window() to return the widget's
top-level window.
Docs for existing Fl_Widget::window() revised to clarify the difference between
these two methods.
Docs for window() also moved from .H - .cxx as per CMP (docs should be where
code implementation is).
Modified:
branches/branch-1.3/FL/Fl_Widget.H
branches/branch-1.3/src/Fl_Window.cxx
Modified: branches/branch-1.3/FL/Fl_Widget.H
===
--- branches/branch-1.3/FL/Fl_Widget.H 2013-04-10 20:13:12 UTC (rev 9870)
+++ branches/branch-1.3/FL/Fl_Widget.H 2013-04-10 20:51:24 UTC (rev 9871)
@@ -919,12 +919,8 @@
*/
void measure_label(int ww, int hh) const {label_.measure(ww, hh);}
- /** Returns a pointer to the primary Fl_Window widget.
- \retval NULL if no window is associated with this widget.
- \note for an Fl_Window widget, this returns its Iparent/I window
-(if any), not Ithis/I window.
- */
Fl_Window* window() const ;
+ Fl_Window* top_window() const;
/** Returns an Fl_Group pointer if this widget is an Fl_Group.
Modified: branches/branch-1.3/src/Fl_Window.cxx
===
--- branches/branch-1.3/src/Fl_Window.cxx 2013-04-10 20:13:12 UTC (rev
9870)
+++ branches/branch-1.3/src/Fl_Window.cxx 2013-04-10 20:51:24 UTC (rev
9871)
@@ -80,11 +80,32 @@
clear_visible();
}
+/** Returns a pointer to the nearest parent window up the widget hierarchy.
+This will return sub-windows if there are any, or the parent window if
there's no sub-windows.
+If this widget IS the top-level window, NULL is returned.
+\retval NULL if no window is associated with this widget.
+\note for an Fl_Window widget, this returns its Iparent/I window
+ (if any), not Ithis/I window.
+\see top_window()
+*/
Fl_Window *Fl_Widget::window() const {
for (Fl_Widget *o = parent(); o; o = o-parent())
if (o-type() = FL_WINDOW) return (Fl_Window*)o;
return 0;
}
+
+/** Returns a pointer to the top-level window for the widget.
+In other words, the 'window manager window' that contains this widget.
+This method differs from window() in that it won't return sub-windows (if
there are any).
+\returns the top-level window, or NULL if no top-level window is
associated with this widget.
+\see window()
+*/
+Fl_Window *Fl_Widget::top_window() const {
+ const Fl_Widget *w = this;
+ while (w-parent()) { w = w-parent(); } // walk up the widget
hierarchy to top-level item
+ return const_castFl_Widget*(w)-as_window(); // return if window, or
NULL if not
+}
+
/** Gets the x position of the window on the screen */
int Fl_Window::x_root() const {
Fl_Window *p = window();
___
fltk-commit mailing list
fltk-commit@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-commit
[fltk.commit] [Library] r9872 - in branches/branch-1.3: FL src
Author: greg.ercolano
Date: 2013-04-10 14:16:16 -0700 (Wed, 10 Apr 2013)
New Revision: 9872
Log:
As per notes from STR#2948:
Moved top_window_offset() to being a member of Fl_Widget (was Fl_Window)
and moved its code near implementations of top_window() and window().
Modified:
branches/branch-1.3/FL/Fl_Widget.H
branches/branch-1.3/FL/Fl_Window.H
branches/branch-1.3/src/Fl_Window.cxx
Modified: branches/branch-1.3/FL/Fl_Widget.H
===
--- branches/branch-1.3/FL/Fl_Widget.H 2013-04-10 20:51:24 UTC (rev 9871)
+++ branches/branch-1.3/FL/Fl_Widget.H 2013-04-10 21:16:16 UTC (rev 9872)
@@ -921,6 +921,7 @@
Fl_Window* window() const ;
Fl_Window* top_window() const;
+ Fl_Window* top_window_offset(int xoff, int yoff) const;
/** Returns an Fl_Group pointer if this widget is an Fl_Group.
Modified: branches/branch-1.3/FL/Fl_Window.H
===
--- branches/branch-1.3/FL/Fl_Window.H 2013-04-10 20:51:24 UTC (rev 9871)
+++ branches/branch-1.3/FL/Fl_Window.H 2013-04-10 21:16:16 UTC (rev 9872)
@@ -120,7 +120,6 @@
\see force_position(int)
*/
int force_position() const { return ((flags() FORCE_POSITION)?1:0); }
- Fl_Window* top_window_offset(int xoff, int yoff) const;
public:
Modified: branches/branch-1.3/src/Fl_Window.cxx
===
--- branches/branch-1.3/src/Fl_Window.cxx 2013-04-10 20:51:24 UTC (rev
9871)
+++ branches/branch-1.3/src/Fl_Window.cxx 2013-04-10 21:16:16 UTC (rev
9872)
@@ -106,6 +106,22 @@
return const_castFl_Widget*(w)-as_window(); // return if window, or
NULL if not
}
+/**
+ Finds the x/y offset of the current window relative to the top-level window.
+ \param[out] xoff,yoff Returns the x/y offset
+ \returns the top-level window
+*/
+Fl_Window* Fl_Widget::top_window_offset(int xoff, int yoff) const {
+ xoff = yoff = 0;
+ const Fl_Window *win = (const Fl_Window*)this;
+ while (win win-window()) {
+xoff += win-x(); // accumulate offsets
+yoff += win-y();
+win = win-window(); // walk up window hierarchy
+ }
+ return (Fl_Window*)win;
+}
+
/** Gets the x position of the window on the screen */
int Fl_Window::x_root() const {
Fl_Window *p = window();
@@ -299,22 +315,6 @@
icon_ = ic;
}
-/**
- Finds the x/y offset of the current window relative to the top-level window.
- \param[out] xoff,yoff Returns the x/y offset
- \returns the top-level window
-*/
-Fl_Window* Fl_Window::top_window_offset(int xoff, int yoff) const {
- xoff = yoff = 0;
- const Fl_Window *win = (const Fl_Window*)this;
- while (win win-window()) {
-xoff += win-x(); // accumulate offsets
-yoff += win-y();
-win = win-window(); // walk up window hierarchy
- }
- return (Fl_Window*)win;
-}
-
//
// End of $Id$.
//
___
fltk-commit mailing list
fltk-commit@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-commit
[fltk.commit] [Library] r9873 - branches/branch-1.3
Author: greg.ercolano Date: 2013-04-10 14:19:10 -0700 (Wed, 10 Apr 2013) New Revision: 9873 Log: Mods to CHANGES file for recent additions/fixes Modified: branches/branch-1.3/CHANGES Modified: branches/branch-1.3/CHANGES === --- branches/branch-1.3/CHANGES 2013-04-10 21:16:16 UTC (rev 9872) +++ branches/branch-1.3/CHANGES 2013-04-10 21:19:10 UTC (rev 9873) @@ -2,12 +2,15 @@ - Fixed access of protected member (STR #2903) - Implemented support for the Mac OS text input system that deals with character composition - and input of languages with large character sets (e.g., Chinese and Japanese). This - implementation has been reported to work well for Chinese. Superficial testing suggests - it's also operational for Japanese. In-depth testing remains needed though. + and input of languages with large character sets (e.g., Chinese and Japanese). This + implementation has been reported to work well for Chinese. Superficial testing suggests + it's also operational for Japanese. In-depth testing remains needed though. - Mac OS version of Fl_Native_File_Chooser: when using filters in a save file dialog, - the output file extension gets changed when the user modifies the output file type. + the output file extension gets changed when the user modifies the output file type. - Removed the now unused src/Fl_mac.cxx + - Fixed various Mac specific opengl issues (STR #2944) +- Added new method Fl_Widget::top_window() (STR #2948) +- Added new method Fl_Widget::top_window_offset() (part of STR #2944) CHANGES IN FLTK 1.3.2 @@ -19,10 +22,10 @@ - Prevents scrollbars from drawing when widget is sized too small to be visible (STR #2886). - Documented how to make a Mac OS X FLTK application launchable by dropping files on its icon. - Fixed a Mac-specific issue appeared with OS 10.8 (Mountain Lion): long delay before - opening when the application is started by dragging a file on the application icon. + opening when the application is started by dragging a file on the application icon. - Fixed use of PNG image from in-memory data (STR #2884). - Added static Fl_RGB_Image::max_size(size_t) to limit the maximum memory size allowed to - RGB images (STR #2881). + RGB images (STR #2881). CHANGES IN FLTK 1.3.1 ___ fltk-commit mailing list fltk-commit@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-commit
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 - The last statement of the Fl_Widget::top_window() function may be written more simply: return w-as_window(); - I'm unsure this function would be useful. Can the knowledge of the top enclosing window of an object be useful without knowledge of the object coordinates relatively to this window? May be what is needed would be along this line: Fl_Window* Fl_Widget::top_window_offset(int xoff, int yoff) 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 Can the knowledge of the top enclosing window of an object be useful without knowledge of the object coordinates relatively to this window? Simple case would be a widget (say a button) that wants to hide the window its in. If the button is in a subwindow, window() wouldn't work, bot top_window() would. May be what is needed would be along this line: Fl_Window* Fl_Widget::top_window_offset(int xoff, int yoff) Actually just added such a thing in r9866 a few days ago to solve STR#2944, but called it window_offset(). Perhaps I should add top_ to it though.. its not too late. 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 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 as_window() Yes, that looks good.. I'll do some tests; want to make sure it inherits through all the window options we have (Fl_Gl_Window, etc) window_offset() vs. top_window_offset(): I strongly vote for the latter and consistent naming Agreed. Will make changes and implement. We should remove this old and error-prone w-type() = FL_WINDOW from the entire lib in favor of as_window(). OK, I'll try to handle that too, but as a separate commit. 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 Oh, BTW, I think I missed what Manolo might have been getting at wrt the 'top_window_offset()' method. So where we're at now, just to disambiguate: o There's currently a method Fl_Window::top_window_offset() (just renamed it from window_offset() in r9870) o We're proposing in this STR a new Fl_Widget::top_window(). I can see where the existing top_window_offset() should really be a method of Fl_Widget, not just Fl_Window.. so that even non-windows can find their offset relative to the top window to be more useful. So will look into changing that as well. 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 OK: r9871: top_window(): implemented (using as_window()) r9872: top_window_offset() now a member of Fl_Widget (was Fl_Window) and moved it near top_window() and window(). 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) ..and finally: r9873: CHANGES file updated. Comments before close? 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) 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.development] fltk and high res retina display?
On Fri, Apr 5, 2013 at 2:21 AM, Christophe Geuzaine cgeuza...@ulg.ac.be wrote: Adding keyNSHighResolutionCapable/keytrue/ 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. in the app's Info.plist makes standard FLTK widgets/fonts draw fairly well (there are some small artifacts and off-by-one line drawings here and there, but nothing major). OpenGL windows are still drawn at half-resolution, though... Yeah, I remember the Apple docs said that opengl, being pixel based, isn't quite so simple to convert to retina. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Caps Lock detection
Try the xkbvled(1) application. Do you find it too doesn't properly represent the shift lock LED? It also fails. I've tried this now with F17 and Ubuntu-12.10, hosted on Win7 and OSX 10.6.8, though in VirtualBox VM's in each case. I don't have ready access to another brand of VM to try at present. If anything, the Win7 hosted version might have been slightly better, but none worked right. Well, in passing, I poked at the VM's a bit more, though nothing useful arises... In summary, it looks as if the Caps Lock key is subject to special handling, probably both in X11 itself *and* by the VM. For comparison, the Num Lock key appears to map straight through to xkbvleds (and my own test code) entirely unmolested and can be read reliably within the VM. But the Caps Lock shows some unusual features. - With the VBox VM hosted on Win7: I can read the keyboard in real time with XQueryKeymap and see the Caps Lock key being pressed and released. I take this to mean that the VM is passing the key stokes through pretty much unmolested on Win7. However, the state reported for Caps Lock (either by X11 or by fltk) does not reliably reflect the true state until after the *next* key is pressed (sometimes it is OK, but not often enough to be considered reliable!) This, I *assume* is special handling within X11 in some way. Num Lock is always fine, AFAICT. - With the VBox VM hosted on OSX: When I read the keyboard in real time with XQueryKeymap I *never* see the Caps Lock key being pressed and released. It just never seems to get flagged, ever. I take this to mean that the VM is NOT passing the Caps Lock key stokes through at all. I think the Caps Lock state is somehow only coming through to the VM on the next key stroke. As a result, the state reported for Caps Lock (either by X11 or by fltk) does not reliably reflect the true state until the *next* key is pressed. So in this case, it would appear there is special handling of the Caps Lock key by *both* the VM and by X11. Num Lock is always fine, AFAICT. The end. 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On Wed, 10 Apr 2013 08:48:35 -0700, Greg Ercolano e...@seriss.com wrote: It's also rare apps try to do anything with the capslock state. I don't agree. Most login screens warn immediately if capslock is on because their password fields don't echo input. Howard Rubin ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On Wed, 10 Apr 2013 10:05:04 -0700, Greg Ercolano e...@seriss.com wrote: On 04/10/13 09:25, Howard Rubin wrote: On Wed, 10 Apr 2013 08:48:35 -0700, Greg Ercolano e...@seriss.com wrote: It's also rare apps try to do anything with the capslock state. I don't agree. Most login screens warn immediately if capslock is on because their password fields don't echo input. Right, though login screens have quite a few oddities about them that are unlike regular GUIs.. inability to be 'stowed', fullscreen with no docks/taskbars, running without a window manager (to prevent window manager hotkey backdoors). I imagine there's a bit of Xlib coding needed on top of fltk to pull off a secure login screen, flwm being one example. 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. Out of curiosity I did a bit of googling and found this. http://www.jveweb.net/en/archives/2010/11/making-better-use-of-the-caps-lock-key-in-linux.html It would seem that trying to trap cap locks could be fruitless because of key re mapping. Cheers Richard ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
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.general] Caps Lock detection
On 10 Apr 2013, at 17:25, Howard Rubin wrote: I don't agree. Most login screens warn immediately if capslock is on because their password fields don't echo input. Though it does appear that, at least if there is any prospect that your users will be running Linux in a VBox VM, that we may have to embrace the possibility that the very best we can do is detect the Caps Lock state when the user starts typing - reliably detecting Caps Lock otherwise seems... fraught... ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.opengl] Fl_Gl_Window flashes on context creation (Windows7)
I use a Dell precision What does this means in terms of the graphics card? Those specifics are probably useful to help replicate. I don't have any dell equipment here (though one of the other devs might), but depending on the graphics, that might help zero it in. That means a NVIDIA Quadro FX 880M graphics card I am wondering about the drivers also, but I cannot say for sure. I did upgrade my drivers before posting just to make sure, but still it is strange that I cannot see this behaviour on any other opengl program. I did download and compile freeglut, their demos run smooth without any problems. I see. Well, you could open an STR with all the details we've found to date. It's going to be a problem though if the devs can't replicate. If you're able to identify the issue, supply a patch, or at least let us know what changes the problem if you try messing around with the FLTK innards. You may find something in the FLTK opengl win32 initialization code that needs adjusting. I also suspect that there might be problems replicating this bug, so I will try to do some digging of my own. Since I have built the FLTK library on my own, I might tinker a bit with the source and might run a strace (or windows equiv.) on the glut demos and the fltk demos to see if there might be a difference. You might try tweaking the freeglut examples to enable features FLTK is enabling (double buffer mode, etc) to see if you can perhaps replicate the problem outside FLTK, to see if it's a particular opengl feature causing the problem. This will be the first Ill be checking. I'll get back when I have some results. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
Re: [fltk.opengl] Fl_Gl_Window flashes on context creation (Windows7)
On 04/09/13 23:24, Ivan Nedrehagen wrote: I also suspect that there might be problems replicating this bug, so I will try to do some digging of my own. Since I have built the FLTK library on my own, I might tinker a bit with the source and might run a strace (or windows equiv.) on the glut demos and the fltk demos to see if there might be a difference. Yes, strace might be good, and also I think there's a way to view the X11 messages going back and forth.. It might be as easy as setting an environment variable, or attaching a program to the process or some such.. can't remember. Sometimes just running the app through a remote xsession would let you sniff the X11 network messages (ethereal, or wireshark, or whatever its called these days which sniffs network packets and deconstructs them at the protocol level into meaningful messages. Used this once to solve an STR a few years ago where our code was creating zero sized windows IIRC) ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
