Re: [fltk.general] Manage focus with Suggestions popup/win/menu
On 2013.01.15, Albrecht wrote: (1) saves the current group, which would otherwise become the window's parent group. (2) resets the current group before window creation (3) reverts (2). Sorry, I don't have the time to do my own tests, so please try this and tell us, if it changes the behavior. Note that simply setting browser_-parent(NULL); is a *really BAD* idea, since this MUST NOT BE USED in user code (see the docs). Unfortunately this method exists, although it really should not exist at all, but it's used for some special internal hacks. Thanks for pointing out to not use parent(Fl_Group *) directly. I haven't done that anywhere else, but at least now I know not to (!). I hacked out a solution to the z problem (remove the popup window from its parent/group, then add it to top window; this puts it last/top in sort order), but I was getting a bit frustrated with the idea altogether and digressed to some other work. I'll return to this one and try out the above. Thanks again for the continued feedback - I'll post whatever works in the end! DLT ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Fl_x.cxx: free unused XFontStringList?
Can we patch to free these two char ** malloc'd by Xlib? About a year or so
ago, Ian (?) had suggested I just not worry too much about any unfree'd buffers
in this particular area.
This is not a serious problem, but now I'm back to using Valgrind to track some
of my own code. Patching would just mean I don't need to remember to ignore the
'safe' lost from amongst my own malignant ones ...
Denton
--- Fl_x.cxx2013-01-21 17:08:22.847562985 +1100
+++ Fl_x.cxx-patched2013-01-21 17:22:21.496352965 +1100
@@ -396,6 +396,7 @@
if (must_free_fnt) free(fnt);
}
#endif
+ XFreeStringList(missing_list); // this list is ignored
preedit_attr = XVaCreateNestedList(0,
XNSpotLocation, spot,
XNFontSet, fs, NULL);
@@ -508,6 +509,8 @@
missing_count, def_string);
#endif
}
+ XFreeStringList(missing_list); // this list is ignored
+
if (fl_xim_ic != ic) {
ic = fl_xim_ic;
change = 1;
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Manage focus with Suggestions popup/win/menu
Hi, all -
I am trying to create a little widget/group made of an Fl_Input (or text
editor) and a drop-down-menu-like suggestions box. The end goal is to make
something similar to an AJAX-y suggestions box found on google, or the firefox
sites suggestions, etc.
It's easy for me to create/fill/show a popup made of an Fl_Select_Browser
inside an Fl_Menu_Window. If I use an Fl_Menu_Window, though, show() steals
focus and the mouse cursor from my Fl_Input widget. I can't send back focus
because the menu is a new window ... or at least I haven't figured out how to
send it back ... ?
In short, I have something like the pseudo-code below. I'm happy to post my
full test/draft if that helps.
Maybe someone else has been through this before?
Denton
// a 'drop down or popup' box with suggested text completions
class SuggestionsBox : public Fl_Menu_Window {
Fl_Select_Browser *browser_; // ideally ...
int handle(int event) {
}
class SuggestionsInput : public Fl_Input {
..
Fl_Input *input_;
... etc etc ...
browser_cb_() {
// when user clicks a browser item, add to input_
// then, hide browser_
}
int handle(int event) {
// on keypress, take input_-value() as prefix.
// search db/tree of terms, put those into browser_.
// show browser_.
}
public:
InputWithSuggestionsBox(..) {
// always display input_
Fl_Group::end();
win_ = new Fl_Menu_Window(...)
browser_ = new Fl_Select_Browser(...)
browser_-callback(browser_cb_, this)
win_-end();
... etc
}
// etc etc
};
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
Sorry - I was a bit trigger-happy with the send button. Pseudo-code
updated/finished:
In short, I have something like the pseudo-code below. I'm happy to post my
full test/draft if that helps.
Maybe someone else has been through this before?
Denton
// a 'drop down or popup' box with suggested text completions
class SuggestionsBox : public Fl_Menu_Window {
Fl_Select_Browser *browser_; // ideally ...
public:
SuggestionsBox(...) : Fl_Menu_Window( ... ){
create browser_;
end();
}
...
etc.
}
// input box that displays suggested completions as dropdown/popup
class SuggestionsInput : public Fl_Input {
...
Fl_Input *input_;
SuggestionsBox *browser_;
... etc etc ...
browser_cb_() {
// when user clicks a browser item, add to input_
// then, hide browser_
}
int handle(int event) {
// on keypress, take input_-value() as prefix. Use client fxn
// to search db/tree of terms, send those to browser_.
// show browser_ just below this input, but keep
// focus in the text input.
}
public:
InputWithSuggestionsBox(..) {
// always display input_
Fl_Group::end();
browser_ = new SuggestionsBox(...);
browser_-callback(browser_cb_, this);
... etc
}
// etc etc
};
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
Sorry - I was a bit trigger-happy with the send button. Pseudo-code
updated/finished:
In short, I have something like the pseudo-code below. I'm happy to post my
full test/draft if that helps.
Maybe someone else has been through this before?
Denton
// a 'drop down or popup' box with suggested text completions
class SuggestionsBox : public Fl_Menu_Window {
Fl_Select_Browser *browser_; // ideally ...
public:
SuggestionsBox(...) : Fl_Menu_Window( ... ){
create browser_;
end();
}
...
etc.
}
// input box that displays suggested completions as dropdown/popup
class SuggestionsInput : public Fl_Input {
...
Fl_Input *input_;
SuggestionsBox *browser_;
... etc etc ...
browser_cb_() {
// when user clicks a browser item, add to input_
// then, hide browser_
}
int handle(int event) {
// on keypress, take input_-value() as prefix. Use client fxn
// to search db/tree of terms, send those to browser_.
// show browser_ just below this input, but keep
// focus in the text input.
}
public:
InputWithSuggestionsBox(..) {
// always display input_
Fl_Group::end();
browser_ = new SuggestionsBox(...);
browser_-callback(browser_cb_, this);
... etc
}
// etc etc
};
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
Using Fl_Window (Fl_Double_Window) + set_non_modal() is definitely easier, and
does not hog input. Thanks for mentioning that, Ian.
New problem, though. Test code is below.
Regardless of what group/win type I use, mouse input will pass through the
popup to the window/widgets below. This acts like an insertion-order thing. So,
widget is drawn z-top, but it is z-below for input. I can fix the input order
by making sure the other widget additions occur before the suggestion box.
In my project, though, I can't control/guarantee the insertion order of the
widget into the parent group ... so I'm a bit stumped.
Ideas? I'll keep reading docs/threads ...
Denton
---
/** \file main.cpp
creating a suggestions drop-down box
CHANGES
- dentonlt, jan 2013: original version
*/
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Group.H
#include FL/Fl_Input.H
#include FL/Fl_Button.H
#include FL/Fl_Select_Browser.H
#include FL/names.h
class SuggestionBox : public Fl_Window {
Fl_Widget *anchor_;
Fl_Select_Browser *browser_;
static void static_browser_cb_(Fl_Widget *src, void *dat) {
if(!src || !dat) printf(SuggestionBox::browser_cb_ rec'd NULL arg.\n);
else ((SuggestionBox *)dat)-browser_cb_(src, dat);
}
void browser_cb_(Fl_Widget *src, void *dat) {
// hack!
printf(SuggestionBox::browser_cb_ runs\n); fflush(stdout);
set_changed();
hide();
}
int handle(int event) {
//printf(SuggestionBox::handle() ran with event %s\n,
fl_eventnames[event]);
int ret = Fl_Window::handle(event);
if(changed()) {
clear_changed();
if(callback()) do_callback();
}
return ret;
}
public:
SuggestionBox(int X, int Y, int W, int H, const char *n = NULL) :
Fl_Window(X, Y, W, H, n) {
anchor_ = NULL;
browser_ = new Fl_Select_Browser(0, 0, W, H);
browser_-callback(static_browser_cb_, this);
// mock 'selection' data
browser_-add(red);
browser_-add(read);
browser_-add(reed);
browser_-add(regurgitate);
Fl_Window::end();
//clear_border();
//set_non_modal(); // stay on top, do not capture events
}
Fl_Select_Browser *browser() { return browser_; }
void anchor(Fl_Widget *a) { anchor_ = a; }
};
class SuggestionInput : public Fl_Input {
SuggestionBox *browser_;
static void static_browser_cb_(Fl_Widget *src, void *dat) {
if(!src || !dat) printf(SuggestionInput::browser_cb_ rec'd NULL arg.\n);
else ((SuggestionInput *)dat)-browser_cb_(src, dat);
}
void browser_cb_(Fl_Widget *src, void *dat) {
// hack!
printf(SuggestionInput::browser_cb_ runs\n); fflush(stdout);
value(browser_-browser()-text(browser_-browser()-value()));
browser_-hide();
}
void post_suggestions_() {
printf(SuggestionInput::post_suggestions_() runs\n); fflush(stdout);
if(browser_-parent()) browser_-position(x(), y() + h());
//else browser_-position(Fl::first_window()-x() + x(),
Fl::first_window()-y() + y() + h());
browser_-show();
browser_-redraw();
}
int handle(int event) {
int ret = Fl_Input::handle(event);
if(changed()) {
clear_changed();
if(value()) post_suggestions_();
if(callback()) do_callback();
}
return ret;
}
public:
SuggestionInput(int X, int Y, int W, int H, const char *n = NULL) :
Fl_Input(X, Y, W, H, n) {
browser_ = new SuggestionBox(0, 0, W, 80);
browser_-callback(static_browser_cb_, this);
browser_-hide();
browser_-anchor(this);
// try both with without ...
//if(browser_-parent()) browser_-parent(NULL);
}
~SuggestionInput() {
printf(SuggestionInput::dtor runs\n); fflush(stdout);
delete browser_;
}
};
void button_cb_(Fl_Widget *, void *) {
printf(button_cb_ ran.\n); fflush(stdout);
}
int main (int argc, char ** argv)
{
Fl_Window *window;
Fl_Input *input;
Fl_Button *button;
window = new Fl_Window (600, 300);
// if I create 'button' here, then it is 'under' the popup.
input = new SuggestionInput(10, 10, 200, 35);
// creating button here hides input from previously inserted widgets
button = new Fl_Button(10, 45, 200, 35, nothing); // this masks input
into the popup ...
button-callback(button_cb_, NULL);
window-resizable(NULL);
window-end ();
window-show (argc, argv);
return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
No, sorry for being unclear. It's solely to detect that the current focus_tracker_ variable value is invalid. This would enable you to see when the current focus widget (inside your group) loses focus and gets it again. Otherwise you wouldn't scroll the widget back into the visible area in that case. However, you would only need to do that, if the user scrolled the focus widget out with the scrollbars or something like that... Ah, of course! That makes very good sense, actually. Another case might be a window resize, if events go through the queue for that. Agreed that I certainly need to track that, and setting focus_tracker_ to 0 would be a simple enough way. DLT ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
Albrecht wrote:
What about adding here:
if (!contains(f_new)) focus_tracker_ = 0; // focus in another group
if(f_new (f_new != focus_tracker_) contains(f_new)) {
focus_tracker_ = f_new; // focus_tracker_ = NULL in ctor
scroll_to(scroll_to_focus_x_(), scroll_to_focus_y_());
redraw();
}
return ret;
}
I guess that's because of cycles, yes?
So, if you want to save some (or more) CPU cycles, I'd recommend
checking what is really needed, and then filter events and/or do
some basic, but simple checks first.
I guess you're thinking it would be cheaper to break up the logical AND
comparisons? I hadn't considered that.
I figured contains() was the most expensive/unpredictable step, so I put
contains() last. If (f_new != focus_tracker_) fails, then the would fail and
contains() wouldn't run. If contains() is not the most expensive part, then I'm
up the wrong tree.
For my own applications, I also don't specifically need to know whether focus
is outside the group ... finding it is just a byproduct. If your own
application needs the flag, though, how about:
if (f_new (f_new != focus_tracker_) {
if(contains(focus_tracker_) {
... do the scroll, etc ...
}
else focus_tracker_ = 0;
}
This would avoid running contains() when focus doesn't change, but it ensures a
flag is 0 when focus is outside the group. I think the down side is that
contains() would -always- run when focus is outside the group, even when focus
does not change. I don't need that, but maybe you do!
DLT
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] RFC: Tracking the focus widget - would this be useful ?
All, I'd like to know if there are more FLTK users who have the need to track the widget that currently has the focus. If this was a common problem, we could probably add something to FLTK to make this easier. It's not easy with current FLTK methods, as can be seen in the current discussion with the title scroll to focus in Fl_Scroll in fltk.general. I, for one, agree. Having a focus callback would be handy. Currently, I template/subclass every widget that I need to have this sort of ability. If others are interested, and the weight of the additional code is trivial, I think it's worth it. Denton ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
Albrecht wrote:
Oh, yes, that's certainly true. If navigation happens to
succeed in a subgroup, then this subgroup does it all. No
parent group will notice. You could maybe derive an own
Fl_Group class to do this in conjunction with its parent
YourScroll class, but this could be a never ending story,
unless you know exactly what groups and widgets you need
in your special case.
Perhaps this is solve-able after all. New handle() below. I like this version a
bit better, if only because it meets your original suggestion for a simple
solution.
int handle(int event) {
int ret = Fl_Scroll::handle(event);
Fl_Widget* f_new = Fl::focus();
if(f_new (f_new != focus_tracker_) contains(f_new)) {
focus_tracker_ = f_new; // focus_tracker_ = NULL in ctor
scroll_to(scroll_to_focus_x_(), scroll_to_focus_y_());
redraw();
}
return ret;
}
I've deleted test_focus_() and scroll_to_focus_() functions as unused kruft.
All the rest remains untouched.
New handle() just checks if focus (1) has moved and (2) is somewhere in the
scroll group. I've done the membership test with contains(), which seems to
return true even if the focus widget is nested. So far, at least.
I found the problem you mentioned re catching key combinations/order,
especially w/ Shift+Tab, etc. If the above works, I can avoid the key problem
altogether by ignoring the event code. Otherwise it may be a bottomless pit of
testing the possible/accepted keycodes for changing focus. I -think- that the
test above will catch any method of changing to the focus widget. I also
-think- it's safe ... but I'll have to test some more.
The main oddity is that I've ditched testing whether the base handle() returned
1. If I rely on that, I can't see nested widgets. Ignoring the value seems
alright, but maybe this does something bad that I haven't caught yet.
Since the placement code seems to be working [knock on wood], I've cut the
color changes / debug. Thanks for identifying how the color change happened to
the input field - I hadn't figured that one out.
I'll post a new test unit when I've got it.
Denton
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
Albrecht wrote: It's not perfect, and maybe some of the changes would turn out to be useless... just take it as a base for more own experiments. Thanks for all this, Albrecht. I'll certainly use those immediately. I appreciate it, as this is part of a current project. I'll keep testing re the style/redraw problem. I'm not sure what I'm doing wrong there - the box style changes just didn't appear on screen ... which was odd. I'll check out your patch to see how you've done it. As well, I caught a more glaring problem: if Fl::focus() is in a group inside of the Fl_Scroll, then it seems the Fl_Scroll::handle() method is not ever run ... so the focus tracking code can't run. I'll write a general test to make sure it's not my own Fl_Group subclass that's hogging the event chain, though. Cheers - Denton ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
On 02.01.2013 13:14, Albrecht Schlosser wrote:
..
Fl_Widget *fw = Fl::focus(); // save focus widget
int ret = Fl_Scroll::handle(event);
if (ret fw != Fl::focus) { // event used and focus changed
..
Albrecht
Thanks for all this, Albrecht. I started mucking with an Fl_Scroll subclass
custom handle(), and decided to track the focus widget in the same way as you.
I hadn't though to cut the test down to that one if statement - big help.
Now working on determining dx/dy. I'll post my subclass when I'm all done.
Cheers -
Denton
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] scroll to focus in Fl_Scroll
Ian wrote:
Ah, but there's a thought... If Denton has already modified his widgets =
to handle the focus differently, then they may perhaps be eating the =
nav events, thus preventing them from propagating to the container =
scroll widget at all?
I may have done that, yes. Have to go back and check now!
For both of you (Ian, Albrecht), here is my solution. It includes a test
sequence that produces some random buttons, and lets the client dynamically
change the size of the scrollbar. I wanted to allow a dynamic box style change
for the scroll group, but it didn't work for some reason ... it just wouldn't
redraw in the new style (???). I'm on 1.3.0 - I think I should just update to
the newest release.
Thanks in advance for any advice - this will certainly be helpful in my current
project.
Denton
---
/** \file Track_Focus_Scroll-Main.cpp
Testing/Draft: Track_Focus_Scroll
CHANGES
- dentonlt, january 2013: original version
- kudos to Albrecht Schlosser and Ian MacArthur for their assistance;
see the fltk newsgroup for replies to:
http://fltk.org/newsgroups.php?gfltk.general+v:35850
*/
// stdlib
#include cstdio
// FLTK lib
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Scroll.H
#include FL/Fl_Button.H
#include FL/Fl_Int_Input.H
class Track_Focus_Scroll;
Fl_Window *win_;
Fl_Int_Input *f; // fudge input
Fl_Int_Input * s; // scrollbar width input
Track_Focus_Scroll *scroll_;
/** @class Track_Focus_Scroll
\brief Fl_Scroll that auto-scrolls to widget in focus
This subclass of Fl_Scroll provides a handle() function that puts
the Fl::focus() widget in view whenever the focus changes. handle()
checks for a focus change after either FL_KEYBOARD or FL_PUSH.
\see handle()
\see scroll_to_focus()
*/
class Track_Focus_Scroll : public Fl_Scroll {
Fl_Widget *focus_tracker_; /// for tracking the Fl::focus() widget
/** if Fl_Scroll:handle() manages event Fl::focus() changes, call
adjust_scroll_() to manage scroll bars */
int handle(int event) {
int ret = Fl_Scroll::handle(event);
if((event == FL_KEYBOARD) || (event == FL_PUSH)) {
if(ret scroll_to_focus_()) redraw();
}
return ret;
}
/** This is a support function for scroll_to_focus_(). You should not have to
call this function directly.
\see scroll_to_focus_()
test Fl::focus() to see (1) if focus has changed since last call
and (2) if focus is inside Fl_Scroll. If both true, return 1. Else return 0.
*/
int test_focus_() {
// if widget is not a widget inside of the scroll group, end.
if(focus_tracker_ == Fl::focus()) return 0;
// record new focus ...
if(focus_tracker_) focus_tracker_-color(FL_BLUE);
focus_tracker_ = Fl::focus();
focus_tracker_-color(FL_RED);
if((!focus_tracker_-inside(this)) ||
(focus_tracker_ == scrollbar) || (focus_tracker_ == hscrollbar) ||
focus_tracker_-inside(scrollbar) ||
focus_tracker_-inside(hscrollbar))
return 0;
return 1; // scroll to it!
}
/** This is a support function for scroll_to_focus_(). You should not have to
call this function directly.
\see scroll_to_focus_()
test focus_tracker_'s x dimensions. If all/part of widget is outside view
area,
calculate a new scroll xposition that will put focus_tracker_ in the view
area.
Return that new scoll xposition. */
int scroll_to_focus_x_() {
int xpos = xposition();
if(!focus_tracker_) return xpos; // avoid glorious segfault ...
int sx, sy, sw, sh;
bbox(sx, sy, sw, sh); // visible scroll area dimensions ...
int style_fudge_ = x() - sx; // to remove the few pixels taken up by the
style border
int wx = focus_tracker_-x();
int ww = focus_tracker_-w();
int minw = (ww sw) ? ww : sw; // get smaller of widget width or scroll
view width
//otherwise, we scroll until as much as possible of the focus_tracker_
widget is in view.
if(wx sx + sw - ww) // scroll right
return xpos + wx - sw + minw - x() + style_fudge_; // move ahead by (dist
b/t window edge widget) + minw + fudge
if(wx sx) // scroll left; this should always scroll until the widget's
left side is against the scroll field left side.
return xpos + wx - x() + style_fudge_; // move back by (dist b/t window
edge and widget) + fudge
return xpos;
}
/** This is a support function for scroll_to_focus_(). You should not have to
call this function directly.
\see scroll_to_focus_()
test focus_tracker_'s y dimensions. If all/part of widget is outside view
area,
calculate a new scroll yposition that will put focus_tracker_ in the view
area.
Return that new scoll yposition. */
int scroll_to_focus_y_() {
int ypos = yposition(); // get current scroll position
if(!focus_tracker_) return ypos; // avoid glorious segfault ...
int sx, sy, sw, sh;
bbox(sx, sy, sw, sh); // get dimensions ...
int style_fudge_ = y() - sy;
Re: [fltk.general] scroll to focus in Fl_Scroll
Thanks for that, Ian. My thinking is that this *should* work and would mean that only one special derived widget is needed, rather than having to make every contained widget be a special widget. Yep, I agree. I've just made a template to add the handlers to any old widget, but it seems like a kludge. From what I can tell, an Fl_Group does not parse events if they are already within the group. If I tab from one widget to another, within the group, the event never goes through Fl_Scroll:handle(). So the group never knows to check whether focus has changed hands/positions. At least I don't -think- it does ... I'll test some more. Denton ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] scroll to focus in Fl_Scroll
Hi, All - Perhaps this has been asked before, but I couldn't find it in the forums. A RTM link would be great ... ! I have an Fl_Scroll with many widgets (buttons, text displays, etc). If I tab through those widgets, I will eventually change focus to a widget that is in the scroll group but outside the visible scroll position. Is there a existing method the Fl_Scroll to notice when the focus widget is not visible, and then to scroll itself to put that widget in view? From what I can tell, this is not a trivial task. I previously used a custom handle() in each child to tell Fl_Scroll when FL_FOCUS changes, then Fl_Scroll::scroll_to(x,y) to put the widget in view ... but perhaps this is not the best method? Thanks for the advice. And Happy New Year!! Denton ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Fl_Text_Editor - key handling
Fl_Text_Editor normally accepts the tab key. I think there's a way to allow tab navigation (not ctrl-tab; I'd really like just tab to navigate) but I can't find that in the docs. Eventually, I'll also like to modify how the editor handles the return/enter key. For these problems, I need to use the key binding functions, yes? Also, any advice? Many thanks - Denton ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Function not implemented
undefined reference to `Fl_PNG_Image::Fl_PNG_Image(char const*, unsigned char const*, int)' I checked the Fl_PNG_Image source file and it's not there. I'd be very surprised if it were elsewhere in the code. In r8507, I have that at line 105 in Fl_PNG_Image.cxx. Perhaps a linker error - is libfltk_images.a in your link list? I haven't played with the imaging code at all, but I think it has to be linked before libfltk.a. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Multiline Input - wrap? [patch draft]
Ok - word wrap works, just not in the way I expected.
If there are spaces in a line, then word wrap will break the line at a space
(insert a newline at a space). If there are no spaces in a line, however,
word wrap will not insert a newline, even if the text length is longer than
the visible area of the widget. If there are no spaces int the first line,
then, it looks like wrapping is disabled.
It's not exactly a bug, but is this the way word wrapping is expected to work?
Perhaps this has already been discussed, and I need to derive my own class?
DLT
I've started a change/patch to r8507 as below, but it is incomplete (it breaks
the scroll in drawtext or somewhere else). The goal is to wrap long lines of
unbroken (un-spaced) text in an Fl_Multiline_Input widget.
I'll appreciate knowing if someone else has already been down this road.
DLT
--- ./Fl_Input_.cxx 2011-04-10 21:07:47.583326523 +1100
+++ ./Fl_Input_.cxx-changes 2011-04-10 21:46:39.475609700 +1100
@@ -81,7 +81,8 @@
}
} else while (oe) {
-if (wrap() (p = value_+size_ || isspace(*p 255))) {
+if (wrap()) {
+ if (p = value_+size_ || isspace(*p 255)) {
word_wrap = w() - Fl::box_dw(box()) - 2;
width_to_lastspace += (int)fl_width(lastspace_out, o-lastspace_out);
if (p lastspace+1) {
@@ -92,7 +93,11 @@
}
lastspace = p;
lastspace_out = o;
+} else if ((int)fl_width(buf, o-buf) w() - Fl::box_dw(box()) - 2) {
+ p--; o--; *o = 0;
+ return p;
}
+} //end if wrap
if (p = value_+size_) break;
int c = *p++ 255;
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Multiline Input - wrap?
I am having trouble wrapping in a multiline input. The stock test/input program
does not wrap, and my test doesn't either (below).
I need to create a multiline input, set its type() to FL_MULTILINE_INPUT and
wrap(1), right?
I'm wondering if there is something not working in Fl_Input_::expand(). I'll
keep studying that.
I've tried both r8441 and r8570, and I'm on Linux/Tinycore. My compile options
disable GL, Cairo, and xft, but I don't believe those should be an issue ... ?
I'm stumped. Many thanks for the guidance.
DLT
---
int main (int argc, char ** argv)
{
Fl_Window *window;
Fl_Multiline_Input *multi_;
window = new Fl_Window (600, 400);
multi_ = new Fl_Multiline_Input(10, 10, 100, 100, stock);
multi_-align(FL_ALIGN_TOP_LEFT);
//also fails w/ FL_MULTILINE_INPUT_WRAP ... :\
multi_-type(FL_MULTILINE_INPUT);
multi_-wrap(1);
window-end ();
window-show (argc, argv);
return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Multiline Input - wrap?
Hello, Albrecht -
Sorry: 1.3, r8570; and yep - just includes as you listed.
Thanks for the confirmation. I must be doing something in my library build that
breaks this, then. I've tried re-enabling xft, but no good.
FYI, I am using:
GCC 4.4.3
Autoconf 2.65
Xorg 7.5 (1.7.7)
I'll keep mucking about, reading manuals. Suggestions still welcome.
DLT
On 08.04.2011 15:38, Denton Thomas wrote:
I am having trouble wrapping in a multiline input. The stock test/input
program does not wrap,
it does for me
and my test doesn't either (below).
It does for me, too.
I need to create a multiline input,
yes
set its type() to FL_MULTILINE_INPUT
no, this is implied (but doesn't matter)
and wrap(1), right?
yes
I'm stumped. Many thanks for the guidance.
Hmm, since it works (wraps words) for me, what do you
expect?
And which FLTK version are we talking about? You mention
r8441 and r8570 - is this FLTK 1.3 ?
BTW.: Your test program is fine, but it would have been even
better, if you had posted it with the #include statements.
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Multiline_Input.H
int main (int argc, char ** argv)
{
Fl_Window *window;
Fl_Multiline_Input *multi_;
window = new Fl_Window (600, 400);
multi_ = new Fl_Multiline_Input(10, 10, 100, 100, stock);
multi_-align(FL_ALIGN_TOP_LEFT);
//also fails w/ FL_MULTILINE_INPUT_WRAP ... :\
multi_-type(FL_MULTILINE_INPUT);
The above statement is redundant.
multi_-wrap(1);
window-end ();
window-show (argc, argv);
return(Fl::run());
}
Albrecht
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Multiline Input - wrap?
On 08.04.2011 16:34, Denton Thomas wrote: Sorry: 1.3, r8570; and yep - just includes as you listed. Thanks for the confirmation. I must be doing something in my library build that breaks this, then. I've tried re-enabling xft, but no good. FYI, I am using: GCC 4.4.3 Autoconf 2.65 Xorg 7.5 (1.7.7) I'll keep mucking about, reading manuals. Suggestions still welcome. Look at test/input.cxx, build it using the FLTK standard autoconf, configure, make sequence from scratch (make distclean, or download a new dist), then run it. It *should* wrap. If it doesn't, then you must have done something wrong. XFT should not matter, IMHO (my build is with XFT, though, and it works for me on Windows as well). Albrecht Thanks, Albrecht. I've just tried clean/bare autoconf/configure/make with no flags, then again using 'standard' Tinycore compile flags: export CFLAGS=-march=i486 -mtune=i686 -Os -pipe -fno-exceptions -frtti export CXXFLAGS=-march=i486 -mtune=i686 -Os -pipe -fno-exceptions -frtti Neither fixed the wrap error. I must have an old dependency that is breaking FLTK or something. I'd expect more than word wrap to break, but ... it can't be the FLTK library if yours works. I'll try other ideas in the morning. Thanks again - DLT ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Multiline Input - wrap?
On 08.04.2011 16:34, Denton Thomas wrote: Sorry: 1.3, r8570; and yep - just includes as you listed. Thanks for the confirmation. I must be doing something in my library build that breaks this, then. I've tried re-enabling xft, but no good. FYI, I am using: GCC 4.4.3 Autoconf 2.65 Xorg 7.5 (1.7.7) I'll keep mucking about, reading manuals. Suggestions still welcome. Look at test/input.cxx, build it using the FLTK standard autoconf, configure, make sequence from scratch (make distclean, or download a new dist), then run it. It *should* wrap. If it doesn't, then you must have done something wrong. XFT should not matter, IMHO (my build is with XFT, though, and it works for me on Windows as well). Albrecht Thanks, Albrecht. I've just tried clean/bare autoconf/configure/make with no flags, then again using 'standard' Tinycore compile flags: export CFLAGS=-march=i486 -mtune=i686 -Os -pipe -fno-exceptions -frtti export CXXFLAGS=-march=i486 -mtune=i686 -Os -pipe -fno-exceptions -frtti Neither fixed the wrap error. I must have an old dependency that is breaking FLTK or something. I'd expect more than word wrap to break, but ... it can't be the FLTK library if yours works. I'll try other ideas in the morning. Thanks again - DLT Ok - word wrap works, just not in the way I expected. If there are spaces in a line, then word wrap will break the line at a space (insert a newline at a space). If there are no spaces in a line, however, word wrap will not insert a newline, even if the text length is longer than the visible area of the widget. If there are no spaces int the first line, then, it looks like wrapping is disabled. It's not exactly a bug, but is this the way word wrapping is expected to work? Perhaps this has already been discussed, and I need to derive my own class? DLT ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_x.cxx: fl_init_xim() missing XFree call, patch
On 15/01/11 09:50, Denton Thomas wrote: I should have suggested removing a couple lines, however - XFree() must happen at the end of fl_init_xim() whether or not the if condition fails at 564, so the new/final XFree() call is basically replacing line 567. I suggest we cut the XFree() at 567 and keep the new check/free at the end. Ok, made that simplification... Try r8279... Will do. I can't get the weekly (8276) for a test right now, though - looks like the domain is in transition ... and caught due to MLK day. I assume no one else can get a download right now, either? DLT ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_x.cxx: fl_init_xim() missing XFree call, patch
On 17.01.2011 11:42, Denton Thomas wrote: Will do. I can't get the weekly (8276) for a test right now, though - looks like the domain is in transition ... and caught due to MLK day. It's working (again) for me. There were DNS problems last Saturday, but they are fixed at least since Sunday morning/midnight (UTC). Maybe your provider still needs a DNS refresh... Alternatively you can temporarily fix it by putting the following IP addresses into your local host table (but don't forget to remove them later): 208.96.52.100 news.easysw.com 208.96.52.101 svn.easysw.com 208.96.52.102 www.fltk.org HTH Albrecht Hello Albrecht/Ian - Working now. Sounds like you were both right: likely needed time to propagate, and I should get a SVN checkout in any case. DLT ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_x.cxx: fl_init_xim() missing XFree call, patch
On 14/01/11 13:22, Denton Thomas wrote:
Agreed, setting to NULL at declaration is pointless! Line 546 is
fine.
Also agreed that it is smart to check xim_styles before use, and to
set it to NULL after. The xlib doc does not specify whether XFree
will or won't set incoming values to NULL. Probably safer.
Denton, I have pushed a variant of your patch into svn at r8278.
Please check it and let us know how it looks.
Ditto for anyone else who's listening of course!
Cheers,
--
Ian
Thanks for adding the conditions/checks at each return statment, Ian.
I should have suggested removing a couple lines, however -
XFree() must happen at the end of fl_init_xim() whether or not the if
condition fails at 564, so the new/final XFree() call is basically replacing
line 567. I suggest we cut the XFree() at 567 and keep the new check/free at
the end.
New r8278 below.
Cheers -
DLT
===
--- branches/branch-1.3/src/Fl_x.cxx 2011-01-14 11:48:18 UTC (rev 8277)
+++ branches/branch-1.3/src/Fl_x.cxx 2011-01-14 22:06:41 UTC (rev 8278)
@@ -550,6 +550,8 @@
xim_styles, NULL, NULL);
} else {
Fl::warning(XOpenIM() failed\n);
+// if xim_styles is allocated, free it now
+if(xim_styles) XFree(xim_styles);
return;
}
@@ -559,14 +561,17 @@
Fl::warning(No XIM style found\n);
XCloseIM(fl_xim_im);
fl_xim_im = NULL;
+ // if xim_styles is allocated, free it now
+ if(xim_styles) XFree(xim_styles);
return;
}
if (!fl_xim_ic) {
Fl::warning(XCreateIC() failed\n);
XCloseIM(fl_xim_im);
-XFree(xim_styles);
fl_xim_im = NULL;
}
+ // if xim_styles is still allocated, free it now
+ if(xim_styles) XFree(xim_styles);
}
void fl_open_display() {
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] Fl_x.cxx - local malloc is not free'd, patch
Sorry - Neglected to mention: FLTK 1.3.0rc3-8207 (current) gcc 4.4.3 Linux (tinycore 3.4.1) Valgrind-ing, I believe I found the source of a leak in Fl_x.cxx. fl_get_font_xfld() malloc's and returns a char * to fl_new_ic(), but the latter does not free this space. From what I can tell, fl_new_ic() needs to do that. This seems to solve the problem: 365c365 char *fnt; --- char *fnt = NULL; 446a447 if (fnt must_free_fnt) free(fnt); The patch makes reflects how fl_set_spot() handles the same situation (line 513). DLT ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.general] Fl_x.cxx: fl_init_xim() missing XFree call, patch
Using: fltk-1.3.x-r8276 / Linux 2.6.33.3 (tinycore) on i686 / gcc 4.4.3
Found via Valgrind and a one-button hello program. In Fl_x.cxx, fl_init_xim()
allocates an XIM object using a call to libx11. fl_init_xim() only deallocates
that object in some cases, rather than in all. It looks like the object is not
needed after fl_ini_xim(), so it should be deallocated locally.
Patch:
540c541
XIMStyles *xim_styles;
---
XIMStyles *xim_styles = NULL;
569a571,575
if (xim_styles) {
XFree(xim_styles);
}
Cheers,
DLT
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] fl_font_x.cxx: missing XFreeFontNames call, patch
fltk-1.3.x-r8276 / Linux 2.6.33.3 (tinycore) on i686 / gcc 4.4.3
find_best_font() keeps a static pointer to the list of font names provided by
libx11. find_best_font() frees and then re-queries that list from libx11 every
time find_best_font() is run. At program termination, that list cannot be freed.
I don't have an elegant solution, but I suggest an improvement that auto-frees.
Rather than keeping a static pointer, I find_best_font() keeps a static, fixed
length array.
Patch:
125c125,126
static char **list = NULL;
---
char **list = NULL;
static char retval[128]; //for storing/returning our font name string
127c128
if (list) XFreeFontNames(list);
---
// if (list) XFreeFontNames(list);
129c130,133
if (!list) return fixed;
---
if (!list) {
strcpy(retval, fixed);
return fixed;
}
190c194,196
return name;
---
strcpy(retval, name);
XFreeFontNames(list);
return (const char *)retval[0];
With that (and a couple other recent patches), Valgrind tells me my simple
helloworld program runs without any leaks.
DLT
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_x.cxx: fl_init_xim() missing XFree call, patch
Found via Valgrind and a one-button hello program. In=20
Fl_x.cxx, fl_init_xim() allocates an XIM object using a call=20
to libx11. fl_init_xim() only deallocates that object in some=20
cases, rather than in all. It looks like the object is not=20
needed after fl_ini_xim(), so it should be deallocated locally.
=20
Patch:
=20
540c541
XIMStyles *xim_styles;
---
XIMStyles *xim_styles =3D NULL;
569a571,575
if (xim_styles) {
XFree(xim_styles);
}
Thanks, that looks like a good catch, though I have some questions;
Initialising xim_styles to NULL is actually done in the body code at
present, so doing it at declaration is probably not adding much.
Does Xfree set things it releases to NULL? I don't remember for sure but
I think not, in which case we'd maybe need to explicitly set xim_styles
=3D NULL; after the Xfree at line 567, I suppose, (and maybe in other
places?) to be sure of avoiding a possible double-free from the proposed
patch?
Do we need to test-and-free-if-set xim_styles at around line 562 as
well?
Also (Denton) I think Unified diffs are generally preferred for patches,
so if you find any more can you post the patches in the unified style
please? Thanks again.
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS=
14 3EL
A company registered in England Wales. Company no. 02426132
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
Hello, Ian - just rec'd this message and next. I'll opt for unified diffs in
the future.
Agreed, setting to NULL at declaration is pointless! Line 546 is fine.
Also agreed that it is smart to check xim_styles before use, and to set it to
NULL after. The xlib doc does not specify whether XFree will or won't set
incoming values to NULL. Probably safer.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_font_x.cxx: missing XFreeFontNames call, patch
Hmm, you have turned off XFT in your build, then? You get much nicer looking text display if you leave XFT enabled in 1.3... find_best_font() keeps a static pointer to the list of font=20 names provided by libx11. find_best_font() frees and then=20 re-queries that list from libx11 every time find_best_font()=20 is run. At program termination, that list cannot be freed. Why is that a Bad Thing? The system will auto-release allocated memory on application exit (and probably more efficiently than we could do it manually), and IIRC XListFonts() doesn't hold onto any other resources, so there's nothing to leak here. What am I missing? Is there something specific about this I'm not seeing? As it stands, I think the existing code is good. Certainly better than a fixed size array, I'd hazard.. Opinions? Also, again, with a unified diff, please? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS= 14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. Yep, I go to/from the XFT. Sometimes the hard lines are refreshing to look at, but XFT is much better for production. Re the would-be-patch, thanks for the details. I am agreed that there is not a lot of justification to make a fix. In retrospect, I am not always clear on when it's safe to let allocations free themselves. Something for me to read up on. I have stumbled onto these as I am beginning to separate my [long] list of [malignant] problems from the harmless library things. So far so good - getting things done. Cheers from Melbourne - Denton ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
