[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 #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
Re: [fltk.bugs] [LOW] STR #2947: Drawing Things in FLTK / minor fixes
On 04/09/13 02:19, 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 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2772: Remove possibly dead code in fl_draw.cxx::fl_measure()
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2772 Version: 1.3-current Fix Version: 1.3-current (r9869) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2772 Version: 1.3-current Fix Version: 1.3-current (r9869) ___ 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 OK; fixes applied to fltk 1.3.x svn current for these: Item #1: fixed in r9865 -- Apple specific overlay emulation issue with swapbuffer + gl rasterpos Item #2: fixed in r9866 -- Apple specific nested gl window issue Haven't gotten to investigating Item #3 yet. 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
Re: [fltk.bugs] [MOD] STR #2939: Fl_Tabs not honoring when(FL_WHEN_NOT_CHANGED)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2939 Version: 1.3.2 Fix Version: 1.3-current (r9867) Fixed in Subversion repository. Leaving this open to allow for comments before closing. Link: http://www.fltk.org/str.php?L2939 Version: 1.3.2 Fix Version: 1.3-current (r9867) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2939: Fl_Tabs not honoring when(FL_WHEN_NOT_CHANGED)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2
Attaching a v7 patch; simplified the docs a bit.
Also added an Fl_Tabs code example while I was at it
(which should be committed separately)
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2Index: FL/Fl_Tabs.H
===
--- FL/Fl_Tabs.H(revision 9853)
+++ FL/Fl_Tabs.H(working copy)
@@ -49,6 +49,52 @@
gap is larger. It is easiest to lay this out in fluid, using the
fluid browser to select each child group and resize them until
the tabs look the way you want them to.
+
+ Typical use:
+ \code
+ Fl_Tabs *tabs = new Fl_Tabs(10,10,300,200);
+ {
+ Fl_Group *tab1 = new Fl_Group(20,30,280,170,Tab1);
+ {
+ ..widgets that go in tab#1..
+ }
+ tab1-end();
+ Fl_Group *tab2 = new Fl_Group(20,30,280,170,Tab2);
+ {
+ ..widgets that go in tab#2..
+ }
+ tab2-end();
+ }
+ tabs-end();
+ \endcode
+
+ In the above, tab1's tab can be made red by using
tab1-selection_color(FL_RED);
+ and tab1's text can be made bold by tab1-labelfont(FL_HELVETICA_BOLD),
+ and can be made 'engraved' by tab1-labeltype(FL_ENGRAVED_LABEL);
+
+ As of FLTK 1.3.3, Fl_Tabs() supports the following flags for when():
+
+ \code
+FL_WHEN_NEVER -- callback never invoked (all flags off)
+FL_WHEN_CHANGED -- if flag set, invokes callback when a tab has been
changed (on click or keyboard navigation)
+FL_WHEN_NOT_CHANGED -- if flag set, invokes callback when the tabs remain
unchanged (on click or keyboard navigation)
+FL_WHEN_RELEASE -- if flag set, invokes callback on RELEASE of mouse
button or keyboard navigation
+
+ Notes:
+
+(a) The above flags can be logically OR-ed (|) or added (+) to combine
behaviors.
+(b) The default value for when() is FL_WHEN_RELEASE (inherited from
Fl_Widget).
+(c) If FL_WHEN_RELEASE is the /only/ flag specified,
+the behavior will be as if (FL_WHEN_RELEASE|FL_WHEN_CHANGED) was
specified.
+(d) The value of changed() will be valid during the callback.
+(e) If both FL_WHEN_CHANGED and FL_WHEN_NOT_CHANGED are specified,
+the callback is invoked whether the tab has been changed or not.
+ The changed() method can be used to determine the cause.
+(f) FL_WHEN_NOT_CHANGED can happen if someone clicks on an already
selected tab,
+or if a keyboard navigation attempt results in no change to the tabs,
+ such as using the arrow keys while at the left or right end of the tabs.
+ \endcode
+
*/
class FL_EXPORT Fl_Tabs : public Fl_Group {
Fl_Widget *value_;
Index: src/Fl_Tabs.cxx
===
--- src/Fl_Tabs.cxx (revision 9855)
+++ src/Fl_Tabs.cxx (working copy)
@@ -170,25 +170,62 @@
}}
/* FALLTHROUGH */
case FL_DRAG:
- case FL_RELEASE:
-o = which(Fl::event_x(), Fl::event_y());
+ case FL_RELEASE: {
+// PUSH, DRAG, RELEASE..
+int do_cb=0;
+if ((o = which(Fl::event_x(), Fl::event_y( { // get tab group for
tab user is over
+ if (o != value()) set_changed(); // if over tab, handle change
+ else clear_changed();
+}
if (event == FL_RELEASE) {
- push(0);
- if (o Fl::visible_focus() Fl::focus()!=this) {
-Fl::focus(this);
-redraw_tabs();
+ push(0); // no longer 'pushed'
+ // Over a tab?
+ if (o) {
+ // Handle taking keyboard focus w/visible focus indication
+ if (Fl::visible_focus() Fl::focus()!=this) {
+ Fl::focus(this);
+ redraw_tabs();
+ }
+ if (value(o)) { // commit to value, see if it
changed..
+ set_changed();// it changed
+ do_cb =
+ ( (when() FL_WHEN_RELEASE) // wants cb on RELEASE
and..
+ (when() FL_WHEN_CHANGED)// when changed?
+ ) || ( // ..or..
+ (when() == FL_WHEN_RELEASE) // *only* WHEN_RELEASE
specified? (default behavior)
+ ) ? 1 : 0;
+ } else {
+ clear_changed(); // no change
+ do_cb = (when() FL_WHEN_RELEASE // wants cb when RELEASE and..
+ when() FL_WHEN_NOT_CHANGED)?1:0; // ..when no change
occurred?
+ }
}
- if (o value(o)) {
-Fl_Widget_Tracker wp(o);
-set_changed();
- do_callback();
- if (wp.deleted()) return 1;
- }
Fl_Tooltip::current(o);
} else {
- push(o);
+ // PUSH or DRAG?
+ //Be careful; a user can PUSH on a tab, but can abort the change
+ //if they
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 And again oops; last message that says Regarding #2 should read Regarding #1. Pff, even had my coffee already. BTW, I'm being overly verbose here to cover my ass, as FLTK opengl internals is not my specialty, esp. the overlay plane stuff.. but I did do quite a bit of gl/opengl back in the day.. 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
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 Active]
Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2
To fix #2, I'm thinking the attached patch, rasterpos_bugfix.patch,
might be a good way to implement the fix with code reuse in mind.
This adds a find_offset() method to Fl_Widget.. essentially the same code
you provided from Fl_mac.cxx, but made into a method so that
both Fl_mac.cxx + Fl_Gl_Window.cxx can use it.
Funny thing though, I *think* Fl_mac.cxx is completely unused code,
a left over from the de-carbonization of FLTK. (verifying this with
the other devs) In which case the code reuse issue might be moot.
Still, it's probably useful to have this as a method; awaiting info
from the other devs.
Anyway, leaving this alternate patch suggestion to fix just #2 here,
in case I get pulled off on other stuff and forget where I left off.
Link: http://www.fltk.org/str.php?L2944
Version: 1.3.2Index: src/Fl_Gl_Window.cxx
===
--- src/Fl_Gl_Window.cxx(revision 9861)
+++ src/Fl_Gl_Window.cxx(working copy)
@@ -183,8 +183,10 @@
GLint xywh[4];
if (window()) {
-xywh[0] = x();
-xywh[1] = window()-h() - y() - h();
+int xoff,yoff;
+const Fl_Window *win = find_offset(xoff, yoff);// STR #2944
+xywh[0] = xoff;
+xywh[1] = win-h() - yoff - h();
} else {
xywh[0] = 0;
xywh[1] = 0;
Index: src/Fl_Window.cxx
===
--- src/Fl_Window.cxx (revision 9861)
+++ src/Fl_Window.cxx (working copy)
@@ -278,6 +278,21 @@
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::find_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$.
Index: FL/Fl_Window.H
===
--- FL/Fl_Window.H (revision 9861)
+++ FL/Fl_Window.H (working copy)
@@ -120,6 +120,7 @@
\see force_position(int)
*/
int force_position() const { return ((flags() FORCE_POSITION)?1:0); }
+ Fl_Window* find_offset(int xoff, int yoff) const;
public:
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2939: Fl_Tabs not honoring when(FL_WHEN_NOT_CHANGED)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2
Suggesting the attached Fl_Tabs-add-when-v6.patch
which modifies Fl_Tabs to handle when().
Includes doxygen docs that describe the various combos of when() flags
supported.
Putting this here so I can remember where I left off if I get pulled
into other activities for a time. Want to do a little more testing of
this before commit.
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2Index: FL/Fl_Tabs.H
===
--- FL/Fl_Tabs.H(revision 9857)
+++ FL/Fl_Tabs.H(working copy)
@@ -49,6 +49,41 @@
gap is larger. It is easiest to lay this out in fluid, using the
fluid browser to select each child group and resize them until
the tabs look the way you want them to.
+
+ As of FLTK 1.3.3, Fl_Tabs() honors the value of when() based on the following
+ table. The default value for when() is FL_WHEN_RELEASE (inherited from
Fl_Widget):
+
+ \code
+when() Flags | Mouse Behavior | Keyboard
Behavior
+--|-|--
+NEVER | change: no callback | change: no
callback
+ | no change: no callback | no change:
no callback
+--|-|--
+ CHANGED| change: callback on PUSH, changed()=true| change:
callback on PUSH, changed()=true
+ | no change: no callback | no change:
no callback
+--|-|--
+ NOT_CHANGED | change: no callback | change: no
callback
+ | no change: callback on PUSH, changed()=false| no change:
callback on PUSH, changed()=false
+--|-|--
+ CHANGED + | change: callback on PUSH, changed()=true| change:
callback on PUSH, changed()=true
+ NOT_CHANGED | no change: callback on PUSH, changed()=false| no change:
callback on PUSH, changed()=false
+--|-|--
+ RELEASE| change: callback on RELEASE, changed()=true | change:
callback on RELEASE, changed()=true
+ | no change: no callback | no change:
no callback
+--|-|--
+ RELEASE + | change: callback on RELEASE, changed()=true | change:
callback on RELEASE, changed()=true
+ CHANGED| no change: no callback | no change:
no callback
+--|-|--
+ RELEASE + | change: no callback | change: no
callback
+ NOT_CHANGED | no change: callback on RELEASE, changed()=false | no change:
callback on RELEASE, changed()=false
+--|-|--
+ RELEASE + | change: callback on RELEASE, changed()=true | change:
callback on RELEASE, changed()=true
+ CHANGED + | no change: callback on RELEASE, changed()=false | no change:
callback on RELEASE, changed()=false
+ NOT_CHANGED | |
++--
+
+ \endcode
+
*/
class FL_EXPORT Fl_Tabs : public Fl_Group {
Fl_Widget *value_;
Index: src/Fl_Tabs.cxx
===
--- src/Fl_Tabs.cxx (revision 9857)
+++ src/Fl_Tabs.cxx (working copy)
@@ -170,25 +170,62 @@
}}
/* FALLTHROUGH */
case FL_DRAG:
- case FL_RELEASE:
-o = which(Fl::event_x(), Fl::event_y());
+ case FL_RELEASE: {
+// PUSH, DRAG, RELEASE..
+int do_cb=0;
+if ((o = which(Fl::event_x(), Fl::event_y( { // get tab group for
tab user is over
+ if (o != value()) set_changed(); // if over tab, handle
change
+ else clear_changed();
+}
if (event == FL_RELEASE) {
- push(0);
- if (o Fl::visible_focus() Fl::focus()!=this) {
-Fl::focus(this);
-redraw_tabs();
+ push(0); // no longer 'pushed'
+ // Over a tab?
+ if (o) {
+ // Handle taking keyboard focus w/visible focus indication
+ if (Fl::visible_focus() Fl::focus()!=this) {
+ Fl::focus(this);
+ redraw_tabs();
+ }
+ if (value(o)) {
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 New] Link: http://www.fltk.org/str.php?L2944 Version: 1.3.2 Thanks for the patches! Can you supply a small compilable app that demonstrates the problem for (1) and (2)? Along the lines of e.g. http://seriss.com/people/erco/fltk/#OpenGlSimple Would like to verify the behavior described. 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
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 Active] Link: http://www.fltk.org/str.php?L2944 Version: 1.3.2 Assigning this STR to myself. Confirmed #2: Attaching rasterpos-fix-before-and-after-screenshot.jpg showing the problem/solution, and agree with the suggested fix to Fl_Gl_Window::make_current(). Since finding the window offset is now needed in at least two places in the code, will probably add a method to the Fl_Window base class that returns x/y offsets, and use that to implement the fix. Link: http://www.fltk.org/str.php?L2944 Version: 1.3.2attachment: rasterpos-fix-before-and-after-screenshot.jpg___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2634: fl_help_view bug fixes and new features
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2634 Version: 1.4-feature Getting around to revisiting this. Unfortunately the changes suggested so far aren't in patch format, so it's hard to determine what changed to merge into current code. I'll see if I can recreate a diff from the latest code attached here, and attach that to this STR so we can see what can be merged into current. Link: http://www.fltk.org/str.php?L2634 Version: 1.4-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2634: fl_help_view bug fixes and new features
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2634 Version: 1.4-feature I'm also attaching a zip that contains Domingo's changes from a posting he made to fltk.dev on 03/08/2010 with the same files broken out: orig -- fltk's original src (based on svn id's from Domingo's files) new -- Domingo's files patch -- patch versions of the changes (diff -Naurw) So between these two zips, we can probably pull what we need to make a merge that includes the best of both. Link: http://www.fltk.org/str.php?L2634 Version: 1.4-feature Attachment: http://www.fltk.org/strfiles/2634/mingodad--03-08-2010-Fl_Help_View-orig-vs-new-as-patches.zip ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Mac OS X Fl_Gl_Window bugs
On 04/03/13 18:34, Lynn Quam wrote: Since I have not previously reported FLTK bug fixes, I would like to know the procedure that I should use. Hi Lynn, Go to the main fltk.org page and click on 'Bugs Features', and then click Submit Bug or Feature Request, and follow the instructions from there. When you create a trouble report, you'll be able to enter text and attach things like patches, screenshots, etc. If you have a fix, best to supply it as a patch, either with 'diff -Naur', or 'svn diff' ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Cursor limitation
On 04/01/13 18:47, Bruce wrote: Trying to build subset of Fldigi for 80m PSK31 USB and the cursor on the waterfall stalls at 2984. I see the PSK31 frequency range as being 1.6 to 3.580 Something that I am misunderstanding or is there a fix for this? Hi Bruce, If you're trying to post a bug about the Fldigi software, you're posting in the wrong place. fltk (where you're posting now) is a graphics toolkit library that the Fldigi software probably uses to draw its graphics, but we don't manage the actual Fldigi software here. You'll want to report bugs in the Fldigi software with the folks that maintain it. I googled around for Fldigi, and although I couldn't really find a clear bug report procedure, according to the README file that comes with its source from this page: http://www.w1hkj.com/download.html ..the following describes how to get support for Fldigi: ** For support, news and updates, join one or more of the following mailing lists and Yahoo groups. Stable releases are announced to all lists and groups; test (alpha) releases are announced to fldigi-alpha and fldigi-announce. * linuxham group General discussion on fldigi, related software and other ham radio topics http://groups.yahoo.com/group/linuxham/join * win-fldigi group For Windows users of fldigi http://groups.yahoo.com/group/win-fldigi/ * NBEMSham group Special focus on NBEMS operation http://groups.yahoo.com/group/NBEMSham/ * fldigi-alpha list Discussion of fldigi testing and related subjects http://lists.berlios.de/mailman/listinfo/fldigi-alpha * fldigi-devel list Fldigi development topics http://lists.berlios.de/mailman/listinfo/fldigi-devel * fldigi-announce list Fldigi announcements http://lists.berlios.de/mailman/listinfo/fldigi-announce ** ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2939: Fl_Tabs not honoring when(FL_WHEN_NOT_CHANGED)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2
Attaching a test program, when.cxx, to test the when() behavior
of tabs vs. radio buttons vs. hold + multi browser.
Also, used this program to generate this table of when() behavior
which will be useful for perhaps fixing not only Fl_Tabs, but bugs
in existing widgets:
http://seriss.com/people/erco/fltk/when-behavior-03-26-2013.html
This test should probably be integrated into the unittests
to check the when() behavior of all widgets. (Instead of using
the tty, the unittest could probably pop open an Fl_Text_Display
widget on first callback, and scroll realtime callback msgs in that)
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.2#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Tabs.H
#include FL/Fl_Group.H
#include FL/Fl_Button.H
#include FL/Fl_Radio_Button.H
#include FL/Fl_Choice.H
#include FL/Fl_Box.H
#include FL/Fl_Browser.H
Fl_Tabs *G_tabs = 0;
Fl_Radio_Button *G_radio1 = 0;
Fl_Radio_Button *G_radio2 = 0;
Fl_Radio_Button *G_radio3 = 0;
Fl_Choice *G_choice = 0;
Fl_Browser *G_brow_hold = 0;
Fl_Browser *G_brow_mult = 0;
void Widget_CB(Fl_Widget*w,void*v) {
const char *msg = (const char*)v;
if (strcmp(msg,MULTI BROWSER)==0|| strcmp(msg,HOLD BROWSER)==0) {
Fl_Browser *b = (Fl_Browser*)w;
printf(%s Callback, changed()=%d value()=%d text()='%s'\n, msg,
w-changed(),b-value(),b-text(b-value()));
} else {
printf(%s Callback, changed()=%d\n, msg, w-changed());
}
}
void When_CB(Fl_Widget*w,void*) {
int when = 0;
const char *s = G_choice-text();
if ( strcmp(s,NEVER )==0) when = FL_WHEN_NEVER;
if ( strcmp(s,CHANGED)==0) when = FL_WHEN_CHANGED;
if ( strcmp(s,NOT_CHANGED)==0) when = FL_WHEN_NOT_CHANGED;
if ( strcmp(s,RELEASE)==0) when = FL_WHEN_RELEASE;
if ( strcmp(s,CHANGED+NOT_CHANGED)==0) when =
FL_WHEN_CHANGED|FL_WHEN_NOT_CHANGED;
if ( strcmp(s,RELEASE+CHANGED)==0) when =
FL_WHEN_RELEASE|FL_WHEN_CHANGED;
if ( strcmp(s,RELEASE+NOT_CHANGED)==0) when =
FL_WHEN_RELEASE|FL_WHEN_NOT_CHANGED;
if ( strcmp(s,RELEASE+CHANGED+NOT_CHANGED)==0) when =
FL_WHEN_RELEASE|FL_WHEN_CHANGED|FL_WHEN_NOT_CHANGED;
// Apply new when value to radio button and tabs widget..
G_radio1-when(when);
G_radio2-when(when);
G_radio3-when(when);
G_tabs-when(when);
G_brow_hold-when(when);
G_brow_mult-when(when);
printf(\n*** WHEN IS NOW %d (%s)\n, when, s);
}
int main(int argc, char *argv[]) {
Fl_Window *win = new Fl_Window(720,240,Tabs Example);
{
G_tabs = new Fl_Tabs(10,10,500-20-110,200-20);
{
// Aaa tab
Fl_Group *aaa = new Fl_Group(10,35,500-20-110,200-45,Aaa);
{
new Fl_Box(50,40,aaa-w()-100,20,These buttons do nothing);
Fl_Button *b1 = new Fl_Button(50, 60,90,25,Button A1);
b1-color(88+1);
Fl_Button *b2 = new Fl_Button(50, 90,90,25,Button A2);
b2-color(88+2);
Fl_Button *b3 = new Fl_Button(50,120,90,25,Button A3);
b3-color(88+3);
}
aaa-end();
// Bbb tab
Fl_Group *bbb = new Fl_Group(10,35,500-10,200-35,Bbb);
{
new Fl_Box(50,40,aaa-w()-100,20,These buttons do nothing);
Fl_Button *b1 = new Fl_Button( 50,60,90,25,Button B1);
b1-color(88+1);
Fl_Button *b2 = new Fl_Button(150,60,90,25,Button B2);
b2-color(88+3);
Fl_Button *b3 = new Fl_Button(250,60,90,25,Button B3);
b3-color(88+5);
Fl_Button *b4 = new Fl_Button( 50,90,90,25,Button B4);
b4-color(88+2);
Fl_Button *b5 = new Fl_Button(150,90,90,25,Button B5);
b5-color(88+4);
Fl_Button *b6 = new Fl_Button(250,90,90,25,Button B6);
b6-color(88+6);
}
bbb-end();
}
G_tabs-end();
G_tabs-callback(Widget_CB, (void*)TABS);
G_choice = new Fl_Choice(500-100-10,30,100,25,when());
G_choice-align(FL_ALIGN_TOP);
G_choice-add(NEVER);
G_choice-add(CHANGED);
G_choice-add(NOT_CHANGED);
G_choice-add(RELEASE);
G_choice-add(CHANGED+NOT_CHANGED);
G_choice-add(RELEASE+CHANGED);
G_choice-add(RELEASE+NOT_CHANGED);
G_choice-add(RELEASE+CHANGED+NOT_CHANGED);
G_choice-callback(When_CB);
G_choice-textsize(9);
Fl_Group *rg = new Fl_Group(G_choice-x(), G_choice-y()+35, 100,100);
rg-color(50);
rg-begin();
G_radio1 = new Fl_Radio_Button(rg-x(),rg-y()+00,rg-w(),25,Radio
1);
G_radio1-callback(Widget_CB,(void*)RADIO1);
G_radio2 = new Fl_Radio_Button(rg-x(),rg-y()+30,rg-w(),25,Radio
2);
G_radio2-callback(Widget_CB,(void*)RADIO2);
G_radio3 = new
Re: [fltk.bugs] [MOD] STR #2939: Fl_Tabs not honoring when(FL_WHEN_NOT_CHANGED)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2939 Version: 1.3.2 Meh, forgot to rename the test program; uploaded as tabs.cxx instead of when.cxx. Link: http://www.fltk.org/str.php?L2939 Version: 1.3.2 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2939: Fl_Tabs not honoroing when(FL_WHEN_NOT_CHANGED)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.3
testalucida posted on fltk.general today:
using Fl_Tabs, wanting to make a single tab group,
and wants to receive callbacks whenever the one tab is clicked.
I was going to offer setting when(FL_WHEN_NOT_CHANGED)
should do this, but does not.
Suggesting a patch here to fix.
Link: http://www.fltk.org/str.php?L2939
Version: 1.3.3Index: Fl_Tabs.cxx
===
--- Fl_Tabs.cxx (revision 9847)
+++ Fl_Tabs.cxx (working copy)
@@ -173,11 +173,14 @@
Fl::focus(this);
redraw_tabs();
}
- if (o value(o)) {
-Fl_Widget_Tracker wp(o);
-set_changed();
- do_callback();
- if (wp.deleted()) return 1;
+ if (o) {
+int change = value(o);
+if (change || (when() FL_WHEN_NOT_CHANGED)) {
+ Fl_Widget_Tracker wp(o);
+ if (change) set_changed();
+ do_callback();
+ if (wp.deleted()) return 1;
+ }
}
Fl_Tooltip::current(o);
} else {
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2939: Fl_Tabs not honoroing when(FL_WHEN_NOT_CHANGED)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2939 Version: 1.3.3 Also attaching a patch suggestion for Fl_Widget's when() docs to elaborate on the use of FL_WHEN_NOT_CHANGED. Link: http://www.fltk.org/str.php?L2939 Version: 1.3.3Index: Fl_Widget.H === --- Fl_Widget.H (revision 9844) +++ Fl_Widget.H (working copy) @@ -615,6 +615,11 @@ \li 0: The callback is not done, but changed() is turned on. \li FL_WHEN_CHANGED: The callback is done each time the text is changed by the user. + \li FL_WHEN_NOT_CHANGED: Do the callback whenever user interacts + with the widget. Some widgets normally won't do a callback +if there's no change (ie. clicking a tab that's already open +or a radio button already selected). Setting this flag causes +the callback to be done regardless if there's a change. \li FL_WHEN_RELEASE: The callback will be done when this widget loses the focus, including when the window is unmapped. This is a useful value for text fields in a panel where doing the callback on every ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [LOW] STR #2940: Docs for label() '@' symbols need some improvement
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2940 Version: 1.3.3 There are some behaviors of @ symbols that aren't documented but should be in this section: http://fltk.org/doc-1.3/common.html I posted a bit about this in fltk.development on 03/23/13 in the thread FLTK '#' symbols question. Would like to suggest adding to the docs something along the lines of: --- '@' symbols in labels can appear only *at the very beginning* or *very end* of a string, or can be at both ends at once. They cannot appear in the middle of a string, which yields undefined behavior. In the presence of multiline strings, symbols will scale up to match the height of all the lines. Examples: [symbol-examples.png goes here] --- Link: http://www.fltk.org/str.php?L2940 Version: 1.3.3attachment: symbol-examples.png___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2939: Fl_Tabs not honoring when(FL_WHEN_NOT_CHANGED)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2939 Version: 1.3.2 Taking ownership, fixed subject typo. Put an RFC on fltk.development to see if implementing all the when() behavior of radio buttons makes sense here. Link: http://www.fltk.org/str.php?L2939 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 #2772: Remove possibly dead code in fl_draw.cxx::fl_measure()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2772
Version: 1.3-current
Attaching a patch to simplify fl_measure()'s handling of symbols.
Result should give same results as old code, but should probably
check odd combos of @ symbols.
Suggest making unittest specifically check @ symbol measurements
for all odd conditions, including @@, abutting @@'s, etc.
Will leave patch here for a while to sleep on it and for comments,
and commit on a later date.
Link: http://www.fltk.org/str.php?L2772
Version: 1.3-currentIndex: fl_draw.cxx
===
--- fl_draw.cxx (revision 9847)
+++ fl_draw.cxx (working copy)
@@ -413,29 +413,20 @@
int lines;
double width=0;
int W = 0;
- char symbol[2][255], *symptr;
int symwidth[2], symtotal;
- // count how many lines and put the last one into the buffer:
- symbol[0][0] = '\0';
- symwidth[0] = 0;
+ symwidth[0] = 0; // size of symbol at beginning of string (if any)
+ symwidth[1] = 0; // size of symbol at end of string (if any)
- symbol[1][0] = '\0';
- symwidth[1] = 0;
-
if (draw_symbols) {
-if (str str[0] == '@' str[1] str[1] != '@') {
- // Start with a symbol...
- for (symptr = symbol[0];
- *str !isspace(*str) symptr (symbol[0] + sizeof(symbol[0]) -
1);
- *symptr++ = *str++);
- *symptr = '\0';
- if (isspace(*str)) str++;
+// Symbol at beginning of string?
+if (str[0] == '@' str[1] != '@') {
+ while ( *str !isspace(*str) ) { ++str; } // skip over symbol
+ if (isspace(*str)) ++str;
symwidth[0] = h;
}
-
-if (str (p = strrchr(str, '@')) != NULL p (str + 1) p[-1]!='@')
{
- strlcpy(symbol[1], p, sizeof(symbol[1]));
+// Symbol at end of string?
+if ( (p=strchr(str,'@'))!=NULL p[1] != '@') {
symwidth[1] = h;
}
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2862: Fl_Table keyboard nav issue: can't use tab to navigate off the widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2862 Version: 1.3-current Fix Version: 1.3-current Fixed in Subversion repository. Fixed (a) and (b) in r9843. Partial changes for (c): examples/table-spreadsheet.cxx Regarding (a): by default FLTK uses Tab to navigate widgets. However, one can enable the new Fl_Table::tab_cell_nav() flag to allow Tab to navigate table cells. Regarding (c): the examples/table-spreadsheet.cxx example was modified to make use of this new feature, and the example works better/more predictably. More to come as other table examples are modified. The new Fl_Table::tab_cell_nav() method breaks ABI, so to to access it in FLTK 1.3.x, YOU MUST UNCOMMENT the FLTK_ABI_VERSION macro at the top of the FL/Enumerations.H file before rebuilding FLTK. Link: http://www.fltk.org/str.php?L2862 Version: 1.3-current Fix 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 #2862: Fl_Table keyboard nav issue: can't use tab to navigate off the widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2862 Version: 1.3-current Fix Version: 1.3-current Looks like Fl_Table_Row needs some fixes as well to support keyboard navigation. So still todo: e) Fl_Table_Row should heed new tab_cell_nav() f) Fl_Table_Row needs a row focus box, similar to Fl_Browser, so user can toggle-select rows in MULTI select mode g) Fl_Table_Row needs to support things like SHIFT-Home, etc to extend selections, and other key combos to toggle selection, etc. Link: http://www.fltk.org/str.php?L2862 Version: 1.3-current Fix 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 #2862: Fl_Table keyboard nav issue: can't use tab to navigate off the widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2862 Version: 1.3-current Fix Version: 1.3-current Made small change in r9844 so that Tab can navigate to/from the input field in foo_v2.cxx attached in this STR when the ABI feature is /disabled/. (It worked OK when ABI feature was enabled) This also fixes the test/table app, which previously had trouble with tab navigation. With r9844, status of issues is: (a) Done (b) Done (c) Tested: -- OK -- test/table -- OK: tab navigates to/from inputs examples/table-as-container -- OK: tab navigates table widgets -- FAILED -- examples/table-sort -- FAIL: because Fl_Table_Row (WIP) examples/table-with-keynav -- FAIL: can't nav to checkbox+Output -- NOT APPLICABLE -- examples/table-spreadsheet -- N/A: no other widgets to tab to examples/table-simple -- N/A: read only, examples/table-spreadsheet-with-keynav -- will be obsolete (d) TODO (e) TODO (f) TODO (g) TODO Link: http://www.fltk.org/str.php?L2862 Version: 1.3-current Fix 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 #2862: Fl_Table keyboard nav issue: can't use tab to navigate off the widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2862 Version: 1.3-current Fix Version: 1.3-current Adding another item to the issues list: (h) Both Fl_Table and Fl_Table_Row will need to heed Fl_Widget::visible_focus() (when focus box is added) Link: http://www.fltk.org/str.php?L2862 Version: 1.3-current Fix Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2897: function Fl_Menu_Item::size() works wrong when Fl_Menu_Item does not meet specification
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2897 Version: 1.1.10 Fix Version: None We are unable to resolve this problem with the information provided. If you discover new information, please file a new STR referencing this one. Closing this due to no response from OP after 1 year. Link: http://www.fltk.org/str.php?L2897 Version: 1.1.10 Fix Version: None ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2772: Remove possibly dead code in fl_draw.cxx::fl_measure()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2772 Version: 1.3-current Taking ownership of this.. Link: http://www.fltk.org/str.php?L2772 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 #2932: 1.3.2 tarball not packaged properly
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. We can probably also automate the release number process, or at very least centralize things so that all version #s come from one location. 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. 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. ___ 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 I applied Albrecht's patch to a fresh copy of fltk r9827, and FLTK built on IRIX 6.5 OK, so looks good to me. (IRIX has its own implementation of scandir(), and HAVE_SCANDIR was set to 1 in config.h) There were a bazillion remarks from the compiler while building FLTK (nothing new; it /always/ moans about unused variables and unreached code), but nothing related to the patch. And nothing stopped the compiler. Just to be sure I didn't miss anything in the voluminous remarks warnings, I tried rebuilding just filename_list.o and scandir.o by themselves, and there were no remarks or warnings at all. So you can add IRIX 6.5 to your list. 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] Does this support UNICODE
On 02/15/13 10:02, parul jain wrote: // // $Id: Fl_Widget.H,v 1.6.2.4.2.19 2002/10/04 15:59:28 easysw Exp $ // // Widget header file for the Fast Light Tool Kit (FLTK). // // Copyright 1998-2002 by Bill Spitzak and others. // // This library is free software; you can redistribute it and/or // modify it under the terms of the GNU Library General Public // License as published by the Free Software Foundation; either // version 2 of the License, or (at your option) any later version. // I am trying to use this software for Russian language for one of my tool. My GUI is based on FLTK. Could you please let me know if I can use this software to develope my tool for Russian language? Please find the details in the comments above. For general questions, in the future please post to fltk.general. Yes, FLTK 1.3.x supports utf8, so it should support any language including russian. Here's a demo of using FLTK in Japanese: http://seriss.com/people/erco/fltk/#UTF8-Japanese As long as your text is encoded in UTF8, it should work fine. PS. Hope you weren't affected by the meteor/asteroid today..yeow! https://www.youtube.com/watch?v=90Omh7_I8vI ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2930: drag and drop from Mozilla Gecko apps broken
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2930 Version: 1.3.2 @Albrecht: yes, I'm not sure either. I dug around a bit; charset names may be case sensitive, but apparently in MIME contexts they're not: http://tools.ietf.org/html/rfc2046#section-4.1.2 A critical parameter that may be specified in the Content-Type field for text/plain data is the character set. This is specified with a charset parameter, as in: Content-type: text/plain; charset=iso-8859-1 Unlike some other parameter values, the values of the charset parameter are *NOT case sensitive.* So I suppose that means we could receive UTF-8, Utf-8, utf-8, etc. I'm unsure though if this is a MIME context with X atom names. Perhaps we should be doing strcasecmp() on the message strings we receive in D+D to check the text/plain;charset=.. string and derive the X atom number that way.. not sure. Anyway, think I'll check this in and close, but leave a comment next to the atom test wondering aloud if this should be done differently. Link: http://www.fltk.org/str.php?L2930 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 #2930: drag and drop from Mozilla Gecko apps broken
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2930 Version: 1.3.2 Fix Version: 1.3.3 (r9824) Fixed in Subversion repository. Closed with resolution. Link: http://www.fltk.org/str.php?L2930 Version: 1.3.2 Fix Version: 1.3.3 (r9824) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2895: Fl_Tree: SINGLE mode selection issues
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2895
Version: 1.3-current
Attaching patch for research..
Link: http://www.fltk.org/str.php?L2895
Version: 1.3-currentIndex: FL/Fl_Tree.H
===
--- FL/Fl_Tree.H(revision 9823)
+++ FL/Fl_Tree.H(working copy)
@@ -330,6 +330,7 @@
void item_clicked(Fl_Tree_Item* val);
void do_callback_for_item(Fl_Tree_Item* item, Fl_Tree_Reason reason);
Fl_Tree_Item *next_visible_item(Fl_Tree_Item *start, int dir);
+ Fl_Tree_Item *next_active_item(Fl_Tree_Item *item, int dir);
void extend_selection(Fl_Tree_Item *from, Fl_Tree_Item *to);
int draw_tree();
@@ -367,10 +368,12 @@
Fl_Tree_Item *item_clicked();
Fl_Tree_Item *first();
Fl_Tree_Item *first_visible();
+ Fl_Tree_Item *first_active();
Fl_Tree_Item *next(Fl_Tree_Item *item=0);
Fl_Tree_Item *prev(Fl_Tree_Item *item=0);
Fl_Tree_Item *last();
Fl_Tree_Item *last_visible();
+ Fl_Tree_Item *last_active();
Fl_Tree_Item *first_selected_item();
Fl_Tree_Item *next_selected_item(Fl_Tree_Item *item=0);
Index: src/Fl_Tree.cxx
===
--- src/Fl_Tree.cxx (revision 9823)
+++ src/Fl_Tree.cxx (working copy)
@@ -168,18 +168,18 @@
switch (Fl::event_key()) { // determine if
focus was navigated..
case FL_Tab: {// received
focus via TAB?
int updown = is_shift ? FL_Up : FL_Down;// SHIFT-TAB
similar to Up, TAB similar to Down
- set_item_focus(next_visible_item(0, updown));
+ set_item_focus(next_active_item(0, updown));
break;
}
case FL_Left: // received focus via LEFT or UP?
case FL_Up: { // XK_ISO_Left_Tab
- set_item_focus(next_visible_item(0, FL_Up));
+ set_item_focus(next_active_item(0, FL_Up));
break;
}
case FL_Right:// received focus via RIGHT or DOWN?
case FL_Down:
default: {
- set_item_focus(next_visible_item(0, FL_Down));
+ set_item_focus(next_active_item(0, FL_Down));
break;
}
}
@@ -255,7 +255,7 @@
}
case FL_Up: // UP: next item up, or extend selection up
case FL_Down: { // DOWN: next item down, or extend selection
down
- set_item_focus(next_visible_item(_item_focus, ekey)); // next
item up|dn
+ set_item_focus(next_active_item(_item_focus, ekey)); // next
item up|dn
if ( _item_focus ) { // item
in focus?
// Autoscroll
int itemtop = _item_focus-y();
@@ -324,9 +324,10 @@
}
break;
}
+ ret |= 1;// handled
+ if ( ! item-is_active() ) break;// item not
active? no changes
set_item_focus(item);// becomes new focus
widget
redraw();
- ret |= 1;// handled
if ( Fl::event_button() == FL_LEFT_MOUSE ) {
if ( item-event_on_collapse_icon(_prefs) ) { // collapse icon
clicked?
open_toggle(item);
@@ -337,7 +338,11 @@
case FL_TREE_SELECT_NONE:
break;
case FL_TREE_SELECT_SINGLE:
- select_only(item, when());
+ if ( is_ctrl ) { // CTRL+LEFT-CLICK?
+ select_toggle(item, when());// toggle
+ } else { // LEFT-CLICK?
+ select_only(item, when()); // select only this item
+ }
_lastselect = item;
break;
case FL_TREE_SELECT_MULTI: {
@@ -375,9 +380,10 @@
if ( Fl::event_button() != FL_LEFT_MOUSE ) break;
Fl_Tree_Item *item = _root-find_clicked(_prefs);
if ( ! item ) break;
+ ret |= 1;
+ if ( ! item-is_active() ) break;// no change if
deactivated
set_item_focus(item);// becomes new focus widget
redraw();
- ret |= 1;
// Item's label clicked?
if ( item-event_on_label(_prefs)
(!item-widget() || !Fl::event_inside(item-widget()))
@@ -752,8 +758,8 @@
return(_callback_item);
}
-/// Returns next visible item above (dir==Fl_Up) or below (dir==Fl_Down) the
specified \p item.
-/// If \p item is 0, returns first() if \p dir is Fl_Up, or last() if \p dir
is FL_Down.
+/// Returns next visible item above (dir==FL_Up) or below (dir==FL_Down) the
specified \p item.
+/// If \p item is 0, returns first() if \p dir is FL_Up, or last() if \p dir
is FL_Down.
///
/// \param[in] item The item
Re: [fltk.bugs] [MOD] STR #2930: drag and drop from Mozilla Gecko apps broken
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2930
Version: 1.3.2
Confirming patch works: I can now d+d text selections from Firefox.
Also confirming patch code is basically the same as code we already use
higher up in Fl_x.cxx.
Verified the printf() debug message triggers during d+d of text.
I'm posting a new version of your patch that differs only in white space
indenting to be consistent with fltk's CMP, added some comments for
clarification, and simplified the printf().
One weird thing though. I tried dragging japanese utf8 text from firefox
- FLTK app and it didn't work. Adding some debug msgs showed the text
coming in from Firefox as:
text/plain;charset=utf-8 (Atom#336)
..but FLTK was checking against:
text/plain;charset=UTF-8 (Atom#278)
..and failing the test. (Note the subtle case difference for utf-8 vs
UTF-8, result in different atom #s for the same utf8 data, causing FLTK
to miss a chance at getting the incoming string as utf8)
This causes FLTK to wait until the text comes in as text/plain, which
drops the utf8 so that only ascii comes through.
I'm not sure why there's both an upper AND lowercase version of the utf8
atom. I did verify that if I added this line to the patch:
if ( t == 336 ) { type = 336; break; } // HACK: HANDLE FIREFOX ATOM
..then the text drag in Japanese works fine.
Not sure if we have it wrong in our code; perhaps this line:
fl_Xatextplainutf = XInternAtom(d, text/plain;charset=UTF-8,0);
..should really be lowercase utf, ie:
fl_Xatextplainutf = XInternAtom(d, text/plain;charset=utf-8,0);
Anyone know?
Link: http://www.fltk.org/str.php?L2930
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 #2930: drag and drop from Mozilla Gecko apps broken
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2930 Version: 1.3.2 Posting a revised patch (patch-with-utf8.diff) that includes the upper AND lowercase version of the charset=utf-8 atom, which seems to make the Japanese d+d work, while not affecting our uppercase version of utf8. Made appropriate changes throughout the module.. was wondering if someone more familiar with this subject than I can weigh in (including the OP). This new patch includes OP's patch with small whitespace mods/comments. Link: http://www.fltk.org/str.php?L2930 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 #2930: drag and drop from Mozilla Gecko apps broken
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2930
Version: 1.3.2
Attached file patch-with-utf8.diff...
Link: http://www.fltk.org/str.php?L2930
Version: 1.3.2Index: src/Fl_x.cxx
===
--- src/Fl_x.cxx(revision 9739)
+++ src/Fl_x.cxx(working copy)
@@ -319,6 +319,7 @@
//Atom fl_XdndProxy;
Atom fl_XdndURIList;
Atom fl_Xatextplainutf;
+Atom fl_Xatextplainutf2;
Atom fl_Xatextplain;
static Atom fl_XaText;
Atom fl_XaCompoundText;
@@ -621,6 +622,7 @@
fl_XdndEnter = XInternAtom(d, XdndEnter, 0);
fl_XdndURIList= XInternAtom(d, text/uri-list, 0);
fl_Xatextplainutf = XInternAtom(d, text/plain;charset=UTF-8,0);
+ fl_Xatextplainutf2= XInternAtom(d, text/plain;charset=utf-8,0);
fl_Xatextplain= XInternAtom(d, text/plain, 0);
fl_XaText = XInternAtom(d, TEXT,0);
fl_XaCompoundText = XInternAtom(d, COMPOUND_TEXT, 0);
@@ -1023,13 +1025,17 @@
Atom type = XA_STRING;
for (unsigned i = 0; icount; i++) {
Atom t = ((Atom*)portion)[i];
- if (t == fl_Xatextplainutf ||
- t == fl_Xatextplain ||
- t == fl_XaUtf8String) {type = t; break;}
- // rest are only used if no utf-8 available:
- if (t == fl_XaText ||
- t == fl_XaTextUriList ||
- t == fl_XaCompoundText) type = t;
+ if (t == fl_Xatextplainutf ||
+ t == fl_Xatextplainutf2 ||
+ t == fl_Xatextplain ||
+ t == fl_XaUtf8String) {
+ type = t;
+ break;
+ }
+ // rest are only used if no utf-8 available:
+ if (t == fl_XaText ||
+ t == fl_XaTextUriList ||
+ t == fl_XaCompoundText) type = t;
}
XFree(portion);
Atom property = xevent.xselection.property;
@@ -1096,7 +1102,8 @@
e.target == fl_XaCompoundText ||
e.target == fl_XaText ||
e.target == fl_Xatextplain ||
-e.target == fl_Xatextplainutf) {
+e.target == fl_Xatextplainutf ||
+e.target == fl_Xatextplainutf2) {
// clobber the target type, this seems to make some applications
// behave that insist on asking for XA_TEXT instead of UTF8_STRING
// Does not change XA_STRING as that breaks xclipboard.
@@ -1186,24 +1193,25 @@
}
// Loop through the source types and pick the first text type...
- int i;
-
- for (i = 0; fl_dnd_source_types[i]; i ++)
- {
-//printf(fl_dnd_source_types[%d] = %ld (%s)\n, i,
-// fl_dnd_source_types[i],
-// XGetAtomName(fl_display, fl_dnd_source_types[i]));
-
-if (!strncmp(XGetAtomName(fl_display, fl_dnd_source_types[i]),
- text/, 5))
- break;
+ unsigned i;
+ Atom type = ((Atom*)fl_dnd_source_types)[0];
+ for (i = 0; fl_dnd_source_types[i]; i ++) {
+Atom t = ((Atom*)fl_dnd_source_types)[i];
+
//printf(fl_dnd_source_types[%d]=%ld(%s)\n,i,t,XGetAtomName(fl_display,t));
+if (t == fl_Xatextplainutf || // text/plain;charset=UTF-8
+ t == fl_Xatextplainutf2 || // text/plain;charset=utf-8
+t == fl_Xatextplain || // text/plain
+t == fl_XaUtf8String) {// UTF8_STRING
+ type = t;
+ break;
+ }
+// rest are only used if no utf-8 available:
+if (t == fl_XaText || // TEXT
+t == fl_XaTextUriList || // text/uri-list
+t == fl_XaCompoundText) type = t; // COMPOUND_TEXT
}
+ fl_dnd_type = type;
- if (fl_dnd_source_types[i])
-fl_dnd_type = fl_dnd_source_types[i];
- else
-fl_dnd_type = fl_dnd_source_types[0];
-
event = FL_DND_ENTER;
Fl::e_text = unknown;
Fl::e_length = unknown_len;
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2930: drag and drop from Mozilla Gecko apps broken
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2930 Version: 1.3.2 I can replicate with both Firefox and Thunderbird on Centos 5.6; 1) Run the fltk 'editor' 2) Highlight some text from a Firefox webpage or thunderbird email (can be plain text) 3) Try to drag the selected text to the FLTK editor I get the '' when dragging selected text in html pages or emails, and if I try to select text from Firefox text input fields (eg. the url) I get the first letter of the text only. Copy+paste work normally, but the drag/drop of a selection does not. Link: http://www.fltk.org/str.php?L2930 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 #2930: drag and drop from Mozilla Gecko apps broken
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2930 Version: 1.3.2 Link: http://www.fltk.org/str.php?L2930 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 #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 Seems introduced between r9850 and r9809 (current); I couldn't replicate with r9850, but doing an update to svn current showed the problem. 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.bugs] [MOD] STR #2920: Fl_JPEG_Image.cxx bug in fltk-1.3.x for jpeg-9
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2920 Version: 1.3-current There's been a change in jpeg 9 FLTK currently releases with jpeg 8c (according to the change log), so I take it you're linking against an external jpeg 9, right? Change should be OK as long as it doesn't break building with FLTK's built-in jpeg 8c. And according to fltk's jpeg/jpeglib.h, it seems like your change is desirable: EXTERN(int) jpeg_read_header JPP((j_decompress_ptr cinfo, boolean require_image)); ..the second arg is a boolean in 8c, so this change is probably recommended. Awaiting a second opinion.. Link: http://www.fltk.org/str.php?L2920 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] jpeg and shared image library
On 01/07/13 16:00, George wrote: Hy I'm trying to compila a code with fltk and i get the following errors: 1main1.obj : error LNK2019: unresolved external symbol public: __thiscall Fl_JPEG_Image::Fl_JPEG_Image(char const *) (??0Fl_JPEG_Image@@QAE@PBD@Z) referenced in function _main 1main1.obj : error LNK2019: unresolved external symbol void __cdecl fl_register_images(void) (?fl_register_images@@YAXXZ) referenced in function _main 1C:\Users\Geo\Desktop\proiect-test-fltk\ProiectOOP\ProiectOOP\Debug\ProiectOOP.exe : fatal error LNK1120: 2 unresolved externals If i create a simple window or a menu item it works just fine but in this case it seems it can't find the lib with the code and i don't know which they are and how to add them. need help pls Please ask such questions on fltk.general, not fltk.bugs. fltk.bugs is only for discussions about bugs that have already been opened with the fltk bug system. I've made a copy of this thread with the same subject and my answer to the question on fltk.general, so please follow up there. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2897: function Fl_Menu_Item::size() works wrong when Fl_Menu_Item does not meet specification
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2897
Version: 1.1.10
I believe this is a bug in your code.
You forgot the extra {0} to close the submenu in the menuitems array.
When you declare an FL_SUBMENU (even if you don't put anything in it),
you have to end it with a {0}. Then you need /another/ {0} to end the
menuitems array itself.
So to fix your program, just add this line (--):
Fl_Menu_Item menuitems[] = {
{ File, 0, 0, 0, FL_SUBMENU },
{0}, // -- ADD THIS LINE (closes the FL_SUBMENU)
{0}// closes the menuitems array
};
Leaving this open for you to confirm this solves your problem,
and will close as 'not a bug' in fltk.
Link: http://www.fltk.org/str.php?L2897
Version: 1.1.10
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2886: Fl_Tile and scrollbars
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2886 Version: 1.3-current Fix Version: 1.3-current (r9720) Yep, I can replicate. It must be taking sneaky path out of the enclosed push/pop's. [..checks..] Yep, looks like there's some 'goto's inside the enclosing push/pop's causing this; need to pop the stack before doing the goto's. I believe r9737 should solve this; leaving open for your confirm. Link: http://www.fltk.org/str.php?L2886 Version: 1.3-current Fix Version: 1.3-current (r9720) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2886: Fl_Tile and scrollbars [issue with Fl_Browser]
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2886 Version: 1.3-current Fix Version: 1.3-current (r9737) Fixed in Subversion repository. Great, thanks manolo for catching this. Geuzaine; I suggest taking note of this, and apply the fix in r9737; without that fix, Fl_Browser can make the clipping stack to grow. Link: http://www.fltk.org/str.php?L2886 Version: 1.3-current Fix Version: 1.3-current (r9737) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2895: Fl_Tree: SINGLE mode selection issues
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2895 Version: 1.3-current On behalf of corvid, paraphrasing: In Fl_Tree, space and left click behave differently in single selection mode. Modifiers such as Ctrl mixed with these are also inconsistent. Also, when items are deactivated, there's differences in behavior. Link: http://www.fltk.org/str.php?L2895 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 #2889: Fl_Table redraw works incorrectly after row increment !
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2889
Version: 1.3.1
Fix Version: 1.3-current (r9731)
Fixed in Subversion repository.
OK, see r9731 with that mod to Fl_Table.H:
- virtual void clear() { rows(0); cols(0); }
+ virtual void clear() { rows(0); cols(0); table-clear(); }
I agree that Fl_Table::clear() should clear the internal Fl_Scroll
as well, since add()/insert()/begin()/end() all affect it as well.
Docs modified as well.
Link: http://www.fltk.org/str.php?L2889
Version: 1.3.1
Fix Version: 1.3-current (r9731)
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2889: Fl_Table redraw works incorrectly after row increment !
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2889
Version: 1.3.1
Fixed in Subversion repository.
The way the example was designed, SetSize() was intended to be called only
once, but it would definitely increase usability if it called clear() so
that it can be called more than once, so I've added it to svn r9728.
So not a bug, but adding the clear() would improve the code for other
purposes.
But in actual practice if I were doing what you're doing (adding a new
row), I'd create a new method called AddRow() and move the relevant code
from SetSize() to that method, and then have SetSize() call AddRow() in
the row loop to add the new rows.
This way you can add new rows without recreating all the widgets. So for
instance, rewriting the two methods this way would be better for your use
case (I didn't heavily test the following, but it seems to work; it should
guide you in the right direction anyway)
--
void AddRow() {
int r = rows();
begin();// start adding widgets to group
for ( int c = 0; ccols(); c++ ) {
int X,Y,W,H;
find_cell(CONTEXT_TABLE, r, c, X, Y, W, H);
char s[40];
if ( c 1 ) {
// Create the input widgets
sprintf(s, %d.%d, r, c);
Fl_Input *in = new Fl_Input(X,Y,W,H);
in-value(s);
} else {
// Create the light buttons
sprintf(s, %d/%d , r, c);
Fl_Light_Button *butt = new Fl_Light_Button(X,Y,W,H,strdup(s));
butt-align(FL_ALIGN_CENTER|FL_ALIGN_INSIDE);
butt-callback(button_cb, (void*)this);
butt-value( ((r+c*2) 4 ) ? 1 : 0);
}
}
end();
rows(rows()+1);
}
void SetSize(int newrows, int newcols) {
clear();// clear child widgets (if any)
rows(0);
cols(newcols);
for ( int r = 0; rnewrows; r++ ) {
AddRow();
}
}
--
Then in your button callback, just call G_Table-AddRow().
In the interest of keeping the example simple though, I'd rather not
change the example beyond adding the clear() you mentioned; while the
above increases usability for purposes beyond the example, it makes the
code harder to comprehend I think, as it is solving problems not shown by
the example.
Leaving this open to see your reply, and will then close.
Link: http://www.fltk.org/str.php?L2889
Version: 1.3.1
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2886: Fl_Tile and scrollbars
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2886 Version: 1.3-current The problem is here: window.box(FL_NO_BOX); Get rid of that line; a parent window must draw 'something' for itself or 'screen garbage' will be left behind. Link: http://www.fltk.org/str.php?L2886 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 #2886: Fl_Tile and scrollbars
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2886 Version: 1.3-current Oops: spoke too soon.. On my system (linux/centos 5.6) when I ran the attached test program resizing made a lot of stuff blink on and off, and much screen garbage was left behind, so I thought that was the main problem. I do advise you keep that line commented out, but I now see the scrollbar tab issue; the lower browser's thumb tab still draws when I make the window small enough that the bottom browser disappears during resize.. I think the issue there is the scrollbar is not getting included in the browser widget's clip region. I'll take a look, as I'm somewhat familiar with Fl_Browser's code; assigning to myself. Link: http://www.fltk.org/str.php?L2886 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 #2886: Fl_Tile and scrollbars
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2886
Version: 1.3-current
Can you try the attached patch-v1.diff and let me know if that solves it?
Link: http://www.fltk.org/str.php?L2886
Version: 1.3-currentIndex: src/Fl_Browser_.cxx
===
--- src/Fl_Browser_.cxx (revision 9719)
+++ src/Fl_Browser_.cxx (working copy)
@@ -423,6 +423,7 @@
fl_pop_clip();
}
fl_pop_clip();
+ fl_push_clip(x(),y(),w(),h());
redraw1 = redraw2 = 0;
if (!dont_repeat) {
@@ -474,6 +475,7 @@
}
real_hposition_ = hposition_;
+ fl_pop_clip();
}
// Quick way to delete and reset everything:
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] A little mistake in fltk-1.3.x-r9705
On 11/01/12 05:47, ChinaJin wrote: Firstly, thanks for sharing this great tool. What I want to mention is not a bug in the programme. You said in the README.MSWindows.txt that we should add a file called fluid.exe, but actually the file in the file of fluid is named fluidd.exe. I know you maybe want to tell people add the fluid.exe to the /VC/bin,but add an extra d in the file name by mistake.And I just want to remind you this little mistake and ask whether is also OK and can be recognized and don't cause any mistakes if we still add this fluidd.exe. We should probably mention 'fluid.exe' for release builds, and 'fluidd.exe' for debug builds. The issue with naming depends on if you built FLTK in Debug or Release mode. IIRC a 'Debug' build causes libs + executables to have the extra 'd' appended (fluidd.exe), and a 'Release' build causes libs + executables to NOT have extra 'd' (fluid.exe). I've often been surprised why the FLTK project files all open by default with 'Debug' build mode enabled, instead of Release. I *think* I remember Matt (or someone) saying it's this way because the VS default is based on the alphabetical order of the release name, and since Debug sorts above Release alphabetically.. it is the default. (It seems hard to believe VS doesn't save the build mode when saved, but I try to avoid the IDE as much as possible, preferring to build via the command line with my own Makefiles..) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2873: Fl_JPEG_Image: when file not found, d() returns 3 instead of 0
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2873
Version: 1.3-current
OK: assigning this to myself and will solve in docs.
A small bit of example code should remove any ambiguity:
if ( img-w() = 0 ||
img-h() = 0 ||
img-d() = 0 ) { ..an error occurred.. }
I think I'll avoid the specifics of error handling (eg. using
strerror()/perror() to access file system errors) because the
failure might be caused by a non-operating system issue (e.g.
bad values in the image header) where any value of errno
would be misleading.
Link: http://www.fltk.org/str.php?L2873
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 #2873: Fl_JPEG_Image: when file not found, d() returns 3 instead of 0
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2873 Version: 1.3-current It looks like /only/ Fl_JPEG_Image documents this behavior; the others (Fl_BMP_Image, Fl_Shared_Image, etc) don't. I'm going to try to check their behaviors empirically to see if they behave similarly and document it, so that if they /don't/ behave that way, it'll be listed as a bug. I'm assuming it's correct to have the docs assume all the Fl_XXX_Image classes should handle errors the same way; if all of x/y/d are = 0 then an error occurred. Link: http://www.fltk.org/str.php?L2873 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2730: valgrind, out of bounds access, Fl_Text_Display wrapping
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2730 Version: 1.3-current Is there any replication info that can be supplied? Optimally, a compilable foo.cxx that demonstrates the problem and some instructions on how to cause the issue (eg. compile+run foo.cxx, and then resize the window slowly to cause the buffer overrun in valgrind) Link: http://www.fltk.org/str.php?L2730 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2873: Fl_JPEG_Image: when file not found, d() returns 3 instead of 0
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2873
Version: 1.3-current
The docs for the Fl_JPEG_Image ctor says:
There is no error function in this class.
If the image has loaded correctly,
w(), h(), and d() should return values greater zero. --
However, I just did a test using the attached (foo.cxx);
if the jpg file doesn't exist, d() should return zero but it does not.
(in my test, it returns 3)
Logging this as a bug, since it disagrees with the docs.
FWIW, testing w() h() for zero works.
Suggest that if the file can't be opened, the code explicitly
sets w()/h()/d() to zero to comply with the docs, and not rely
on the subclass ctors to zero these out.
Also suggest testing other image types (PNG, BMP, etc)
Link: http://www.fltk.org/str.php?L2873
Version: 1.3-current#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Shared_Image.H
#include FL/Fl_JPEG_Image.H
#include FL/Fl_Box.H
#include FL/fl_ask.H // fl_alert()
#include errno.h // strerror()
int main() {
fl_register_images(); // initialize image lib
Fl_Window win(720,486); // make a window
Fl_Boxbox(10,10,720-20,486-20); // widget that will contain
image
const char *filename = /var/tmp/foo.jpg; // load jpeg image into ram
Fl_JPEG_Image jpg(filename);// load jpeg image into ram
if ( jpg.d() == 0 ) // should be zero if file
doesn't exist
{ fl_alert(%s: %s, filename, strerror(errno)); }
box.image(jpg); // attach jpg image to box
win.show();
return(Fl::run());
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2865: Missing X11 headers from SRC zip (Visual Studio 2010 builds)
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2865 Version: 1.3.0 Fix Version: None I think OP says in the summary he's using Visual Studio, which should reach the #include's for X11 anyway. Either way, this is not a bug. OP is best advised to ask such questions on fltk.general before reporting as bugs. Link: http://www.fltk.org/str.php?L2865 Version: 1.3.0 Fix Version: None ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2865: Missing X11 headers from SRC zip (Visual Studio 2010 builds)
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2865 Version: 1.3.0 Fix Version: None Correction: which should *NEVER* reach the #includes for X11 anyway Link: http://www.fltk.org/str.php?L2865 Version: 1.3.0 Fix Version: None ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Can size_range() enforce square resizable windows?
On 07/27/12 20:00, Todd wrote: Q2. How does this program behave on Linux? Is Ian's hack-around not needed - i.e., size_range() suffices? Or if used, does it work (like on Mac) or not work (like Windows)? Just win.size_range() seems to work fine on my linux machine to keep the window square at all times during resizing. On the mac, though, it doesn't work. And if I use a resize() override on the window to try to force it, the window is still unconstrained during resize if I just trivially try to constrain the W/H values.. ie. my constraints are ignored.. sort of. The window becomes two windows; an outer window that is unconstrained (with the usual thumbtab at the bottom right) and an 'inner window' that is more like a group; that inner window/group IS constrained, and it too has a little thumbtab in the corner. What's odd is that you can end up with two thumb tabs in your app this way..! E.g., can FLTK be amended so size_range() suffices on all platforms? The window managers have been changing quite a bit over the years.. It should probably be checked to see if constraint is possible during resizing. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2863: 1.3.x docs for Fl_Window::size_range() don't document args correctly
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2863 Version: 1.3-current Fix Version: 1.3-current (r9644) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2863 Version: 1.3-current Fix Version: 1.3-current (r9644) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] cpam instalation is broken
On 07/21/12 19:27, msangel wrote: I am new in perl and in programing at all. I download manually a newer version of library and dont know how to build it. I'm not familiar with cpanm or dmake commands or the CPAN module Alien, but it sounds like it requires the FLTK 1.3.x library to build from source properly. Normally I'd suggest going to the CPAN Alien maintainer and ask about the issue. I'm pretty sure FLTK doesn't keep SVN snapshots around forever, though it does keep /releases/ around for a long time. This CPAN installer config seems to want an old SVN snapshot that it probably shouldn't. (I don't suppose there's a binary install of this Alien library for your plaform? If so, you can probably just install that, avoiding having to 'build' anything) You don't mention a platform, so if you want to build from source, I'll assume you have linux with a developers environment installed (eg. g++, X windows libs, etc), though these same steps might work on other environments too. So I would suggest: 1) Download this: http://fltk.org/software.php?VERSION=1.3.0FILE=fltk/snapshots/fltk-1.3.x-r9635.tar.bz2 and save it as e.g. /var/tmp/fltk-1.3.x-r9635.tar.bz2 2) Login as root, and run this command to make an empty temp directory: mkdir /var/tmp/test 3) cd into that directory and extract the tar file, eg: cd /var/tmp/test tar xvjf /var/tmp/fltk-1.3.x-r9635.tar.bz2 4) cd into the resulting new directory, and run 'make install', eg: cd /var/tmp/test/fltk-1.3.x-r9635 make install If you get errors, post your platform and the error messages from the above on fltk.general (instead of fltk.bugs) 5) Assuming step #4 works, then try downloading the Alien CPAN module, and follow its instructions for building. It should be able to find the FLTK library you just built and installed, and that should get you further along towards installing the module. Either way, if you need to follow up, please use fltk.general, as it's the right place for this I think. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2862: Fl_Table keyboard nav issue: can't use tab to navigate off the widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2862 Version: 1.3-current As per a thread started on fltk.general (**), investigating why tab doesn't navigate focus off Fl_Table. Attaching code showing the issue, a modified version of the simple-table.cxx example with just an Fl_Input field added. When run: 1) one can't use Tab to navigate to the input field 2) if focus is moved to the input field with the mouse, hitting tab moves focus to the table, but can't again be moved off using tab. So: a) Fl_Table should handle tab navigation b) Fl_Table should honor the new Fl::option(OPTION_ARROW_FOCUS) flag for arrow key focus navigation as well c) the table example programs that depend on arrow keys for internal navigation may need modification to take this flag into account, since arrow keys are used to navigate the cells in the table in some cases. d) Fl_Table should be modified to show focus (eg. focus box), as I don't think it currently does. **jseb opened a thread on fltk.general on 7/7/2012 asking about an issue with keyboard navigation and Fl_Table (Subject: keeping keyboard events in a widget) Link: http://www.fltk.org/str.php?L2862 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 #2862: Fl_Table keyboard nav issue: can't use tab to navigate off the widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2862
Version: 1.3-current
Attached file foo.cxx...
Link: http://www.fltk.org/str.php?L2862
Version: 1.3-current//
// $Id: table-simple.cxx 9086 2011-09-29 21:10:59Z greg.ercolano $
//
//Simple example of using Fl_Table - Greg Ercolano 11/29/2010
//
//Demonstrates the simplest use of Fl_Table possible.
//Display a 10x10 array of integers with row/col headers.
//No interaction; simple display of data only.
//See other examples for more complex interactions with the table.
//
// Copyright 2010 Greg Ercolano.
// Copyright 1998-2010 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
// file is missing or damaged, see the license at:
//
// http://www.fltk.org/COPYING.php
//
// Please report all bugs and problems on the following page:
//
// http://www.fltk.org/str.php
//
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Table.H
#include FL/Fl_Input.H
#include FL/fl_draw.H
#define MAX_ROWS 30
#define MAX_COLS 26 // A-Z
// Derive a class from Fl_Table
class MyTable : public Fl_Table {
int data[MAX_ROWS][MAX_COLS]; // data array for cells
// Draw the row/col headings
//Make this a dark thin upbox with the text inside.
//
void DrawHeader(const char *s, int X, int Y, int W, int H) {
fl_push_clip(X,Y,W,H);
fl_draw_box(FL_THIN_UP_BOX, X,Y,W,H, row_header_color());
fl_color(FL_BLACK);
fl_draw(s, X,Y,W,H, FL_ALIGN_CENTER);
fl_pop_clip();
}
// Draw the cell data
//Dark gray text on white background with subtle border
//
void DrawData(const char *s, int X, int Y, int W, int H) {
fl_push_clip(X,Y,W,H);
// Draw cell bg
fl_color(FL_WHITE); fl_rectf(X,Y,W,H);
// Draw cell data
fl_color(FL_GRAY0); fl_draw(s, X,Y,W,H, FL_ALIGN_CENTER);
// Draw box border
fl_color(color()); fl_rect(X,Y,W,H);
fl_pop_clip();
}
// Handle drawing table's cells
// Fl_Table calls this function to draw each visible cell in the table.
// It's up to us to use FLTK's drawing functions to draw the cells the
way we want.
//
void draw_cell(TableContext context, int ROW=0, int COL=0, int X=0, int Y=0,
int W=0, int H=0) {
static char s[40];
switch ( context ) {
case CONTEXT_STARTPAGE: // before page is drawn..
fl_font(FL_HELVETICA, 16); // set the font for our drawing
operations
return;
case CONTEXT_COL_HEADER: // Draw column headers
sprintf(s,%c,'A'+COL);// A, B, C, etc.
DrawHeader(s,X,Y,W,H);
return;
case CONTEXT_ROW_HEADER: // Draw row headers
sprintf(s,%03d:,ROW); // 001:, 002:, etc
DrawHeader(s,X,Y,W,H);
return;
case CONTEXT_CELL:// Draw data in cells
sprintf(s,%d,data[ROW][COL]);
DrawData(s,X,Y,W,H);
return;
default:
return;
}
}
public:
// Constructor
// Make our data array, and initialize the table options.
//
MyTable(int X, int Y, int W, int H, const char *L=0) : Fl_Table(X,Y,W,H,L) {
// Fill data array
for ( int r=0; rMAX_ROWS; r++ )
for ( int c=0; cMAX_COLS; c++ )
data[r][c] = 1000+(r*1000)+c;
// Rows
rows(MAX_ROWS); // how many rows
row_header(1); // enable row headers (along left)
row_height_all(20); // default height of rows
row_resize(0); // disable row resizing
// Cols
cols(MAX_COLS); // how many columns
col_header(1); // enable column headers (along top)
col_width_all(80); // default width of columns
col_resize(1); // enable column resizing
end(); // end the Fl_Table group
}
~MyTable() { }
};
int main(int argc, char **argv) {
Fl_Double_Window win(900, 400, Simple Table);
MyTable table(10,10,880,350);
Fl_Input in(100,360,100,25,Input);
win.end();
win.resizable(table);
win.show(argc,argv);
return(Fl::run());
}
//
// End of $Id: table-simple.cxx 9086 2011-09-29 21:10:59Z greg.ercolano $.
//
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2862: Fl_Table keyboard nav issue: can't use tab to navigate off the widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2862
Version: 1.3-current
Attached file foo_v2.cxx...
Link: http://www.fltk.org/str.php?L2862
Version: 1.3-current//
// $Id: table-simple.cxx 9086 2011-09-29 21:10:59Z greg.ercolano $
//
//Simple example of using Fl_Table - Greg Ercolano 11/29/2010
//
//Demonstrates the simplest use of Fl_Table possible.
//Display a 10x10 array of integers with row/col headers.
//No interaction; simple display of data only.
//See other examples for more complex interactions with the table.
//
// Copyright 2010 Greg Ercolano.
// Copyright 1998-2010 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
// file is missing or damaged, see the license at:
//
// http://www.fltk.org/COPYING.php
//
// Please report all bugs and problems on the following page:
//
// http://www.fltk.org/str.php
//
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Table.H
#include FL/Fl_Input.H
#include FL/fl_draw.H
#define MAX_ROWS 30
#define MAX_COLS 26 // A-Z
// Derive a class from Fl_Table
class MyTable : public Fl_Table {
int data[MAX_ROWS][MAX_COLS]; // data array for cells
// Draw the row/col headings
//Make this a dark thin upbox with the text inside.
//
void DrawHeader(const char *s, int X, int Y, int W, int H) {
fl_push_clip(X,Y,W,H);
fl_draw_box(FL_THIN_UP_BOX, X,Y,W,H, row_header_color());
fl_color(FL_BLACK);
fl_draw(s, X,Y,W,H, FL_ALIGN_CENTER);
fl_pop_clip();
}
// Draw the cell data
//Dark gray text on white background with subtle border
//
void DrawData(const char *s, int X, int Y, int W, int H, int ROW, int COL) {
fl_push_clip(X,Y,W,H);
// Draw cell bg
fl_color( is_selected(ROW,COL) ? FL_YELLOW : FL_WHITE);
fl_rectf(X,Y,W,H);
// Draw cell data
fl_color(FL_GRAY0); fl_draw(s, X,Y,W,H, FL_ALIGN_CENTER);
// Draw box border
fl_color(color()); fl_rect(X,Y,W,H);
fl_pop_clip();
}
// Handle drawing table's cells
// Fl_Table calls this function to draw each visible cell in the table.
// It's up to us to use FLTK's drawing functions to draw the cells the
way we want.
//
void draw_cell(TableContext context, int ROW=0, int COL=0, int X=0, int Y=0,
int W=0, int H=0) {
static char s[40];
switch ( context ) {
case CONTEXT_STARTPAGE: // before page is drawn..
fl_font(FL_HELVETICA, 16); // set the font for our drawing
operations
return;
case CONTEXT_COL_HEADER: // Draw column headers
sprintf(s,%c,'A'+COL);// A, B, C, etc.
DrawHeader(s,X,Y,W,H);
return;
case CONTEXT_ROW_HEADER: // Draw row headers
sprintf(s,%03d:,ROW); // 001:, 002:, etc
DrawHeader(s,X,Y,W,H);
return;
case CONTEXT_CELL:// Draw data in cells
sprintf(s,%d,data[ROW][COL]);
DrawData(s,X,Y,W,H,ROW,COL);
return;
default:
return;
}
}
public:
// Constructor
// Make our data array, and initialize the table options.
//
MyTable(int X, int Y, int W, int H, const char *L=0) : Fl_Table(X,Y,W,H,L) {
// Fill data array
for ( int r=0; rMAX_ROWS; r++ )
for ( int c=0; cMAX_COLS; c++ )
data[r][c] = 1000+(r*1000)+c;
// Rows
rows(MAX_ROWS); // how many rows
row_header(1); // enable row headers (along left)
row_height_all(20); // default height of rows
row_resize(0); // disable row resizing
// Cols
cols(MAX_COLS); // how many columns
col_header(1); // enable column headers (along top)
col_width_all(80); // default width of columns
col_resize(1); // enable column resizing
end(); // end the Fl_Table group
}
~MyTable() { }
};
int main(int argc, char **argv) {
Fl_Double_Window win(900, 400, Simple Table);
MyTable table(10,10,880,350);
table.end();
Fl_Input in(100,360,100,25,Input);
win.end();
win.resizable(table);
win.show(argc,argv);
return(Fl::run());
}
//
// End of $Id: table-simple.cxx 9086 2011-09-29 21:10:59Z greg.ercolano $.
//
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2862: Fl_Table keyboard nav issue: can't use tab to navigate off the widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2862 Version: 1.3-current Added a v2 of the test program to this STR to fix a few things in the trivial first version: 1) Needed to end() the table to prevent the input field from becoming a child of the table. 2) Added code to show the selection state of the cells, as this is relevant; apparently the table is using tab navigation for its cells; hitting tab shows it walks the cells from left-to-right, and when it hits the end, focus moves on to the input field. Probably like the Fl_Input_ widget, Fl_Table needs something like the tab_nav() method which controls how the table responds to tab navigation specifically. Also, an odd behavior was noticed in v2; assuming the table were had a tab_nav() method and it were disabled (so that tab navigation doesn't move to other widgets, causing the table to use it for itself): Tab navigates cells forward (OK) Shift-Tab navigates cells in reverse (OK) but also does a multi-cell selection (BAD) IMHO, the behavior should work this way: tab_nav() enabled: tab + shift-tab navigate widgets, table does not use tab for its own cell navigation. Only arrow key navigation can be used to navigate cells (dependent on the OPTION_ARROW_FOCUS setting), and SHIFT can be used for multicell selection. tab_nav() disabled: tab + shift-tab navigate /cells/ forward or reverse. (No multi-select behavior for Tab) Arrows should also work, and Shift-Arrows should do multiselect, dependent on OPTION_ARROW_FOCUS. Perhaps too, there should be an Fl_Table method (if there isn't one now) to control whether multicell selection should be allowed or not. I imagine there might be cases where an app doesn't want multi-cell selection, or might not want interactive cell selection at all via mouse or keyboard. (eg. a 'read only' interface, where only the program can select cells) Link: http://www.fltk.org/str.php?L2862 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 #2862: Fl_Table keyboard nav issue: can't use tab to navigate off the widget
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2862 Version: 1.3-current Also, an odd behavior was noticed in v2; assuming the table were had a tab_nav() method and it were disabled (so that tab navigation doesn't move to other widgets, causing the table to use it for itself): Good grief, grammar. Too bad we can't edit bugs. That should have been: Also, an odd behavior was noticed in v2; assuming the table had a tab_nav() method, and the flag was disabled so that tab navigation doesn't move to other widgets and the table can use Tab for itself: Link: http://www.fltk.org/str.php?L2862 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 #2849: X11 drag-n-drop of non-ascii pathname to FLTK widget fails
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2849 Version: 1.3-current +1 to hide platform differences as well, but wondering if we shouldn't provide an option to turn this off if for some reason the app wants the original data. For instance, say a user is pasting the following string from one editor to another: file:///some/path.txt, and today the humidity was %20. ..would the patch convert the %20 to a space? Or if they pasted an escaped URI, would they be surprised to find the URI unescaped after the paste operation? Also: would suggest adding error checking to the sscanf(); patch; if the sscanf() != 1, might be a good reason to abort the unescape operation entirely. If a URI is 'escaped' (or hex encoded), then it probably makes sense to stop parsing as soon as you hit a character that would normally be escaped (like a space), to avoid unescaping beyond the URI itself. Link: http://www.fltk.org/str.php?L2849 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 #2848: DataReadyThread leak OSX (bug in our Cocoa threading code)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2848 Version: 1.3-current Hi Peeter, Great that you're checking in; sounds great. I'm quite sure based on the leak report you showed that is was caused by the use of FLTK's add_fd() call; the references to the FLTK method DataReady() in your report makes that clear. Just so you know what's going on under the hood: Under OSX only: when you use add_fd(), FLTK internally starts a child thread to monitor the fd with select(). and that thread sends events to the main thread to wake it up, so that your callback can be invoked. This was done because the Apple event manager didn't support a way to come out of its event loop on file descriptor activity. So if you see DataReady in leak or crash reports on OSX, the cause will be related to FLTK's add_fd() call. Link: http://www.fltk.org/str.php?L2848 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 #2848: DataReadyThread leak OSX (bug in our Cocoa threading code)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2848 Version: 1.3-current Great! Thanks for the quick fix.. glad it's a small change. I don't think the OP responded to the fltk.general posting, so I'll try sending him a private email referencing this STR to see if he can follow up here. Link: http://www.fltk.org/str.php?L2848 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2848: DataReadyThread leak OSX (bug in our Cocoa threading code)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2848 Version: 1.3-current I'm making this STR on behalf of Peeter Vois' post on fltk.general on May 8 2012, Subject: DataReadyThread leak hunting .. He apparently was using Fl::add_fd() on OSX, and was getting a leak in Fl_Cocoa.mm's DataReady::DataReadyThread(). The leak: ==297== 222,260 bytes in 11,113 blocks are definitely lost in loss record 4,244 of 4,245 ==297==at 0x13CF47: calloc (vg_replace_malloc.c:569) ==297==by 0x5CFC7E: _class_createInstanceFromZone (in /usr/lib/libobjc.A.dylib) ==297==by 0x5CFCC4: _class_createInstance (in /usr/lib/libobjc.A.dylib) ==297==by 0x5C62C7: _objc_rootAllocWithZone (in /usr/lib/libobjc.A.dylib) ==297==by 0x25AD70: +[NSObject allocWithZone:] (in /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation) ==297==by 0x6BE88D: +[NSAutoreleasePool allocWithZone:] (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation) ==297==by 0x5C61BB: _objc_rootAlloc (in /usr/lib/libobjc.A.dylib) ==297==by 0x73361: DataReady::DataReadyThread(void*) (in X) ==297==by 0x1BB3ED8: _pthread_start (in /usr/lib/system/libsystem_c.dylib) ==297==by 0x1BB76DD: thread_start (in /usr/lib/system/libsystem_c.dylib) ==297== ==297== LEAK SUMMARY: ==297==definitely lost: 235,225 bytes in 11,357 blocks ==297==indirectly lost: 6,440 bytes in 17 blocks ==297== possibly lost: 3,883 bytes in 39 blocks ==297==still reachable: 1,403,803 bytes in 10,153 blocks ==297== suppressed: 0 bytes in 0 blocks ==297== Reachable blocks (those to which a pointer was found) are not shown. ==297== To see them, rerun with: --leak-check=full --show-reachable=yes ==297== ==297== For counts of detected and suppressed errors, rerun with: -v ==297== Use --track-origins=yes to see where uninitialised values come from ==297== ERROR SUMMARY: 28937 errors from 55 contexts (suppressed: 722 from 39) Link: http://www.fltk.org/str.php?L2848 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 #2848: DataReadyThread leak OSX (bug in our Cocoa threading code)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2848 Version: 1.3-current I looked into this, and I think the solution we should use is to probably switch our code from using pthreads to using NSThread, for the reasons stated below.. Peeter: can you make an STR for this so we can track it? I think I can confirm it's something we need to fix in Fl_cocoa.mm. This way you'll be notified of fixes as they happen. In the mean time, a little investigation: Peeter, I'm guessing your app uses the fltk method add_fd(), as this triggers FLTK to internally use the DataReady class, which starts a child thread running the DataReadyThread() method to: a) monitor the fd with select(2) b) send the custom event when data is ready to wake up FLTK to run the add_fd() callback. I wrote that code a long time ago (2004), and some years later Manolo ported it to cocoa/objective C, so probably the two of us needs to look at it. Afraid I don't know objective C myself, but given your stack dump, looks like it's something to do with one of the objective C memory allocation calls, probably NSAutoReleasePool. Could be some issue with that call not being thread safe or something is missing in the use of it. Manolo: perhaps you can weigh in on this? The code for the method DataReady::DataReadyThread() (in Fl_cocoa.mm) runs entirely in the context of a child thread. So anything we do in that method has to be thread safe. I looked at the docs for 'NSAutoReleasePool' and it has a section on Threads which has a special note about POSIX threads (which we use): Note: If you are creating secondary threads using the POSIX thread APIs instead of NSThread objects, you cannot use Cocoa, including NSAutoreleasePool, unless Cocoa is in multithreading mode. Cocoa enters multithreading mode only after detaching its first NSThread object. To use Cocoa on secondary POSIX threads, your application must first detach at least one NSThread object, which can immediately exit. You can test whether Cocoa is in multithreading mode with the NSThread class method isMultiThreaded. I'm guessing we need to take this advice, either: 1) Use NSThread instead of pthreads() - OR - 2) Do what the above docs advise, and just start a quick NSThread() during the first use of Add_FD() so that our use of posix threads will work properly, given the above warning. I'm pretty sure that's the issue. Peeter: as a quick workaround, can I advise that at the top of your main() function, before doing anything else, create a simple thread using NSThread() that does nothing (simply returns). I think by doing this, it will do as the above recommends, triggering whatever internal bookkeeping OSX wants to prevent the leak. Doing this should be safe to do, even when we eventually fix the problem. Please open the STR with just your initial post, and I'll follow up with the above details, and me and Manolo will chime in when we have a fix to the code. I want you to open the STR so that you'll receive emails as the fixes progress. Link: http://www.fltk.org/str.php?L2848 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2847: Undefined referance
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2847 Version: 1.1.10 Fix Version: None General support is not available via the STR form. Please post to the FLTK forums and/or mailing lists for general support. Link: http://www.fltk.org/str.php?L2847 Version: 1.1.10 Fix Version: None ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2844: Fl_Text_Display: needs keyboard nav for caret motion and keyboard selection
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2844 Version: 1.3-current Oops, accidentally posted the code with the (A) line already commented out, so when built by default the caret shows OK; you'll have to remove the comment to make the caret disappear. Link: http://www.fltk.org/str.php?L2844 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2844: Fl_Text_Display: needs keyboard nav for caret motion and keyboard selection
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2844 Version: 1.3-current Fl_Text_Display seems to have the features Fl_Multiline_Output does in that one can enable a 'caret' cursor that could be used for keynav selection, but the caret doesn't respond to keyboard motion (up/down/left/right or 'shift selection'). Also, there seems to be inconsistencies in how the caret is displayed once it's enabled. If the widget opens without focus, the caret can not be made to appear via keyboard nav (ie. using the tab key to shift focus). Probably the caret should appear when the widget has focus, and disappear when not in focus (if it's enabled). Link: http://www.fltk.org/str.php?L2844 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 #2828: Fl_Tree RFE's
On 05/08/12 20:25, Fabien Costantini wrote: On 05/08/12 19:47, Fabien Costantini wrote: Now, at initialization the item label color is an 'undefined' value (let say 0x ?). Note that value would be stored in the prefs as well if user did not specify a custom color. Ah, OK, I was going to use a bitflag to keep track of this, and a special 'reset' method to control the flag, but overloading the color ff/ff/ff/ff is better. OK, try r9478. It defaults the item_labelbgcolor() to 0x. The interpretation of this is entirely in the draw() code; the set/get methods are consistent in how that value is returned. This way the user can test for that value to see if 'transparent mode' is enabled. Also, if the user changes it to a 'normal' color, they can set it back again to 'transparent' mode. The docs cover this behavior, and it should be backwards compatible in that the tree's behavior should be consistent with previous versions. I've enhanced the test/tree application to test for this; click on the Test Suggestions button at the lower right to see how to test this new color behavior (under the 'Color' section). ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2828: Fl_Tree RFE's
On 05/08/12 19:47, Fabien Costantini wrote: Now, at initialization the item label color is an 'undefined' value (let say 0x ?). Note that value would be stored in the prefs as well if user did not specify a custom color. Ah, OK, I was going to use a bitflag to keep track of this, and a special 'reset' method to control the flag, but overloading the color ff/ff/ff/ff is better. It's interesting: I had thought all bits were used in Fl_Color, and they sort of are, but indeed there are many patterns of bits that are simply 'undefined', ff/ff/ff/ff being one of them. (ie RGB bits AND colormap bits all enabled). So I could document that the special color ff/ff/ff/ff is 'see through', so that if the item's bg color is set to that, the item's background won't be drawn at all, causing the underlying color() of the widget to show through. And this would be backwards compatible with existing code, because that bit pattern is normally 'not allowed'. Sounds good, I'll go with that. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Unable to compile FLTK
On 05/02/12 07:14, Matthias Melcher wrote: On 02.05.2012, at 15:26, Alexander Dimitrov wrote: When trying to Build the Demo I got the fatal error: fltk-1.3.0-source\fltk-1.3.0\FL/Fl_Cairo.H(44) : fatal error C1083: Cannot open include file: 'cairo-win32.h': No such file or directory. Please set the build style to Debug or Release. It is currently set to Cairo Debug or Cairo Release thanks to VisualC sorting styles alphabetically instead of using the one that was built last. Oh, that's why that happens? For that reason, would it help if we renamed our styles to (A) Release, (B) Debug, (C) Cairo..? ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2828: Fl_Tree RFE's
On 04/27/12 17:07, Fabien Costantini wrote: Link: http://www.fltk.org/str.php?L2828 Version: 1.3-current something really [nice] to do to do would be to sync the item default bkgnd color to the box color instead of white, thus not making the assumption that the default bckgnd is white... More precisely what could be done is make sure that first item creation use a lazy/late binding scheme that would ensure that an item (i.e. the root) would be created only after the default color has been set ? OK, I'm about to commit this as an ABI feature. The way it works, when draw()ing the items: o Use the item's labelbgcolor() IF IT HAS BEEN SET. Otherwise.. o Use the tree's item_labelbgcolor() IF IT HAS BEEN SET. Otherwise.. o Use the tree's Fl_Tree::color() A similar technique is used for the foreground colors. Changing the global colors will affect how the whole tree is drawn (unless the higher level colors are masking it). This behavior is implemented with bitflags at each level, similar to how an alpha channel behaves. The management of the bitflags is transparent to the app; it's all handled internally. Once a color has been set, it 'masks' the use of the more global colors. The default behavior can be restored by calling methods with the reset_ prefix, ie. reset_item_labelbgcolor() will restore default behavior if the app had set a color with item_labelbgcolor(). ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2832: Fl_Tree does not draw child widget labels anymore
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2832 Version: 1.3-current Fix Version: 1.3-current (r9413) Will do. I'm working on a large commit now to do Fabien's request for 'lazy' color control, and among various tweaks to the test/tree program for that, I'll include an Fl_Input widget with a right-aligned label so that this continues to be supported. Closing this STR; thanks for the report! Link: http://www.fltk.org/str.php?L2832 Version: 1.3-current Fix Version: 1.3-current (r9413) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2831: redraw problem with Fl_Pixmap on X11
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2831 Version: 1.3-current Replicated on another machine running fedora3/32bit. (Above was centos5/64bit) So seems like any linux box, 32bit or 64bit should show the issue. Link: http://www.fltk.org/str.php?L2831 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 #2831: redraw problem with Fl_Pixmap on X11
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2831 Version: 1.3-current PS. I don't know anything about how clipping is implemented, which I think might be the problem, so I don't plan on assigning this to myself.. just reporting the issue. My guess is it might have to do with the new Graphics Driver stuff.. not sure. Link: http://www.fltk.org/str.php?L2831 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2832: Fl_Tree does not draw child widget labels anymore
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2832
Version: 1.3-current
Attached file tree-and-inputs-with-labels.cxx...
Link: http://www.fltk.org/str.php?L2832
Version: 1.3-current#include stdio.h
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Tree.H
#include FL/Fl_Input.H
int main(int argc, char *argv[]) {
Fl_Double_Window *win = new Fl_Double_Window(450, 400, Tree As FLTK Widget
Container);
win-begin();
{
Fl_Tree *tree = new Fl_Tree(10, 10, win-w()-20, win-h()-20);
tree-root()-label(Test Nodes);
// Add some regular text nodes
tree-add(Foo/Bar/001);
tree-add(Foo/Bar/002);
tree-add(Foo/Bla/Aaa);
tree-add(Foo/Bla/Bbb);
// Add items to the 'Data' node
for ( int t=0; t1000; t++ ) {
// Add item to tree
static char s[80];
sprintf(s, FLTK Widgets/%d, t);
Fl_Tree_Item *item = tree-add(s);
tree-begin();
{
sprintf(s, Test %04d, t);
Fl_Input *in = new Fl_Input(0,0,140,25);
in-align(FL_ALIGN_RIGHT);
in-copy_label(s);
item-widget(in);
}
tree-end();
}
}
win-end();
win-resizable(win);
win-show(argc, argv);
return(Fl::run());
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2832: Fl_Tree does not draw child widget labels anymore
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2832 Version: 1.3-current Fix Version: 1.3-current (r9411) Fixed in Subversion repository. Try svn r9411; that should restore it. Leaving this open until you can confirm. Link: http://www.fltk.org/str.php?L2832 Version: 1.3-current Fix Version: 1.3-current (r9411) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2832: Fl_Tree does not draw child widget labels anymore
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2832 Version: 1.3-current Fix Version: 1.3-current (r9413) Actually, would like to recommend svn r9413 instead, which fixes a focus/redraw problem when specifically Fl_Input widgets are used as immediate children. Link: http://www.fltk.org/str.php?L2832 Version: 1.3-current Fix Version: 1.3-current (r9413) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2831: redraw problem with Fl_Pixmap on X11
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2831
Version: 1.3-current
Attached file foo.cxx...
Link: http://www.fltk.org/str.php?L2831
Version: 1.3-current#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Button.H
#include FL/Fl_Pixmap.H
/* XPM */
static const char * gradient_xpm[] = {
30 20 3 1,
a c #ff,
b c #dd,
c c #88,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
aabbcc,
};
int main(int argc, char **argv) {
Fl_Pixmap gradient(gradient_xpm);
Fl_Window *win = new Fl_Window(160, 75, test);
Fl_Button *but1 = new Fl_Button(0,0,160,75,);
but1-image(gradient);
but1-align(FL_ALIGN_IMAGE_BACKDROP|but1-align());
win-end();
win-show(argc,argv);
return(Fl::run());
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2831: redraw problem with Fl_Pixmap on X11
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2831 Version: 1.3-current Attached file foo.png... Link: http://www.fltk.org/str.php?L2831 Version: 1.3-currentattachment: foo.png___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2831: redraw problem with Fl_Pixmap on X11
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2831 Version: 1.3-current I'm not sure, but digging down, it seems like it might be a problem with the clipping region stuff. It seems like Fl_Graphics_Driver::clip_box() is coming back with strange responses to the returned XYWH values that causes tiny slivers of the image to be drawn. Hope it's not just my machine needing a reboot :/ Link: http://www.fltk.org/str.php?L2831 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 #2828: Fl_Tree RFE's
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2828 Version: 1.3-current @Fabien: Yes, indeed, there was an intention to do this when I designed the API. The intention was to have it similar to the way the global scrollbar size stuff works, where one control the scrollbar size globally in an application, but also give individual control when needed that overrides the global behavior. Fl_Tree::item_labelfgcolor() and Fl_Tree::item_labelbgcolor() are supposed to allow you to change the entire tree's fg/bg color even /after/ the tree has been built. The only time an item's own color would be used is if it were first SET by the app. So I imagined I could use a bitflag to indicate whether a color had been set or not. Apparently didn't get around to doing that. So I think I can add bitflags for this.. I imagine it can work this way: o If the app doesn't try to set Fl_Tree::item_labelfgcolor()/bg and doesn't try to set a specific item's fg/bg color, the widget's own color() and labelcolor() will be used for all the items. Changing the color()/labelcolor() will affect the items globally, even /after/ the tree is built. o However, if the app sets the Fl_Tree::item_labelfgcolor()/bg, then this globally overrides the use of the widget's color() and labelcolor(). This way, the app can still globally control the tree's item colors even after the tree is built, while still allowing the widget color() and labelcolor() to be different. o Finally, if one sets a particular item's color, this will cause that item to be drawn in that color, overriding the above. Link: http://www.fltk.org/str.php?L2828 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 #2796: Fl_Tree: scrollbar position not recomputed when items are collapsed
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2796 Version: 1.3-current Fix Version: 1.3-current (r9400) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2796 Version: 1.3-current Fix Version: 1.3-current (r9400) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2709: fl_round_box may corrupt line style settings in Win32 systems - was: Windows7/x64 drawing problems in buttons.exe demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) Confirmed w/VS2010 on Win7/x64 -- thanks! Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Fix Version: 1.3.1 (r9211) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2799: Menus can suddenly disappear
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2799 Version: 1.3.0 OK - I defer to the OP to weigh in, as I don't have a problem with the behavior myself.. my mouse doesn't move between push/release. As a last gasp on the subject, I can only recommend to the OP, he might be able to solve this if he changes the '3' in this line (mentioned above): // turn off is_click if enough time or mouse movement has passed: if (abs(Fl::e_x_root-px)+abs(Fl::e_y_root-py) 3 || ..to something larger like 6. This will allow more mouse travel between push/release as not being mistaken as movement. Link: http://www.fltk.org/str.php?L2799 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2796: Fl_Tree: scrollbar position not recomputed when items are collapsed
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2796 Version: 1.3-current I don't think the demo 'tree' has collapse all / open all buttons, but it probably should. I'm about to make a large commit to Fl_Tree, so I'll add buttons for 'open all' and 'collapse all' so this can be exercised. I'll also see if I can fix this while I'm at it, as I've added a 'marginbottom()' method that lets one control how far beyond the bottom of the tree a person can scroll. I'll see if I can use that as a 'minimum position'. To replicate what I think the OP was getting at: 1) Run test/tree 2) Open the 500 items node 3) Select the '%00 items' node 4) Scroll to the bottom 5) Hit 'Remove Selected' (removes '500 items' node and its children) You now find yourself scrolled to a position far beyond the bottom of the tree, and have to scroll all the way through 'nothingness' to find the bottom of the tree. Arguably the tree should prevent one from being able to be scrolled 'beyond the bottom' of the tree. I've seen this issue with other FLTK widgets as well; Fl_Browser has always had it I think, and I think others (Fl_Scroll?) Link: http://www.fltk.org/str.php?L2796 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 #2799: Menus can suddenly disappear
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2799 Version: 1.3.0 Answering on behalf of the OP, I think there is a valid issue to be solved. Our behavior is different than just about everything else, and it's a subtle thing.. probably something someone with a sensitive mouse would notice, such as a mouse that moves when the button is pushed (e.g. IBM thinkpads with those mouse 'pointer sticks' in the middle of the keyboard) Find an app with a File menu, and do these specific steps: 1) Click on the 'F' in a File menu 2) Drag a few *pixels* (from the 'F' to the 'i' in File) without moving off the menu 3) Release In FLTK apps, the menu disappears, in all other apps, it stays open. This, due to a 1pixel movement between click/release. If a user likes click-release stay-open menus, they'll probably have a hard time getting them with something like a track-point mouse, or a mouse that moves easily during a press/release stroke. Link: http://www.fltk.org/str.php?L2799 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2799: Menus can suddenly disappear
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2799 Version: 1.3.0 Or well, I should qualify that: On linux + windows the menus aren't 1pixel sensitive. On the mac, though, it seems they are just like FLTK; a micro-movement during click-release cancels the stay-open menus. Link: http://www.fltk.org/str.php?L2799 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2799: Menus can suddenly disappear
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2799 Version: 1.3.0 But isn't it a bug on linux + windows? Link: http://www.fltk.org/str.php?L2799 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2795: Fl_Tree: needs to be optimized to handle very large contents (10000)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2795 Version: 1.3-current Fix Version: 1.4-feature (r9232) @Domingo: OK, r9355 should take care of not drawing items outside the Fl_Tree viewport when the items are FLTK widgets. I've included a new example as well, to both demonstrate how to make items that are FLTK widgets, and exercise the widget with a very large tree: example/tree-as-container.cxx This example creates 50,000 items, each item containing 5 Fl_Input widgets contained in an Fl_Group. So 50k x (5+1) = 300k widgets. I purposefully chose a large enough number that I could /see/ slight slowness on my dev box (1.8GHz dual intel running centos 5.6) so that any inefficiencies would be obvious. I didn't have time test on windows, but runs well on linux + mac. Or at least, as well as FLTK can handle 300k widgets. Link: http://www.fltk.org/str.php?L2795 Version: 1.3-current Fix Version: 1.4-feature (r9232) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2795: Fl_Tree: needs to be optimized tohandleverylarge contents (10000)
On 04/17/12 06:49, Fabien Costantini wrote: That said, flu combo tree rely on the full tree which permits path navigations, not sure the Fl_Tree permits that ? (i.e. /foo/bar would reference a root foo with a child bar) Yes -- Fl_Tree supports paths (see examples which all use them): add(path) lets you add items with pathnames, auto-creating any parents in the path that don't exist (similar to 'mkdir -p') find_item(path) returns the item* for given path item_pathname(item) returns the path for the given item ..and many other Fl_Tree methods support paths as well, offering both item and paths as arguments (eg. is_selected(), is_open(), etc) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2795: Fl_Tree: needs to be optimized tohandleverylarge contents (10000)
On 04/16/12 18:45, Fabien Costantini wrote:
From the top of mind (I might miss some other flu goodies):
- Show leaves + Show branches - selectable independently
- Sorted, Front, Back, reverse insert api
- Shaded entries
- Multiple selection drag ignore
- {Vertical|Widget} Gap (Fl_Tree has horizontal and top bottom)
- Animate: no really useful but so nice :)
I've opened a new STR for these as RFE's for Fl_Tree:
STR#2828:
http://fltk.org/str.php?L2828
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2795: Fl_Tree: needs to be optimized tohandleverylarge contents (10000)
On 04/17/12 06:49, Fabien Costantini wrote:
Also, on the previous related Fl_Tree design discussion(selection list
as opposed to traverse tree like selection approach) , I wouldn't buy the
performance point on redraw() as you still know what to be redrawn from
the externalized selection list and can rebuild your needed redraw
context in similar ways though it now introduces ptr indirection.
I'd like to understand what you mean, but I don't.. can you
elaborate? I'm probably missing something..
The way I see it, if the selection list is managed as an array
of item ptrs (instead of as a per-item bit flag), then when
Fl_Tree runs its draw() loop, wouldn't it have to do a lookup
on this array each time it has to check if an item is selected
(in order to draw it properly)?
Effectively, the pseudocode:
for (item=first_visible_item; itemlast_visible_item; item++ ) {
if ( is_item_selected(item) )
draw_selected()
else
draw_unselected()
bool is_item_selected(item) {
for (i2=0; i2total_selected_items(); i2++) //
argh: lookup loop
if ( item == selected_array[i2] ) return(true);
return(false)
}
..the problem here being here 'is_item_selected()' becomes
a lookup on a potentially large array, instead of a bit flag test.
If someone did a ^A (select all) on 80k widgets,
the selected_array[] would become 80k large, and so that
array would need to be walked to draw each item.
And whenever the selection is modified (eg. with a Ctrl-Drag
or Shift-Drag), again the array needs to be walked on each
update.
This, as opposed to walking the array once whenever someone
wants to get the selection as an array (ie. a convenience
function). Isn't it better to do that, to prevent constant
array lookups?
I think a bitflag is the better approach, and just compute
the selection list when it's requested (as a single pass at
the array)
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
