Re: [fltk.general] Fl_tile: don't shrink, just shift
On 04/21/13 10:50, Greg Ercolano wrote:
I made one of these once; in my case I didn't use a tile,
just used a regular Fl_Group in which the widgets were positioned,
and put a thin widget between each that acted as a 'resizer' which:
1) enlarged/shrunk the widget above it
2) enlarged/shrunk the parent group
3) moved all the children below it up/down
+---Fl_tile---+
| +-+ |
| | | |
| | widget 0| |
| | | |
| +-+ |
| | resizer | |
| +-+ |
| | | |
| | widget 1| |
| | | |
| +-+ |
| | resizer | |
| +-+ |
| | | |
| | widget 2| |
| | | |
| +-+ |
+-+
Here's an example implementation of the above based on an older work.
This assumes the parent is an *Fl_Scroll*.
This is so that widgets off-screen can be reached with a scroll bar.
The ResizerButton class is what you would use in your app.
The main() below it shows how to use it.
The example code creates 10 Fl_Box widgets with a resizer below each.
You can drag the resizers around to change the size of the widget above;
the other widgets below will be moved around inside the scroller to
accommodate.
Scrollbars will appear for widgets that are off-screen.
--- snip
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Scroll.H
#include FL/Fl_Box.H
#include FL/Fl_Button.H
#include FL/fl_draw.h
#include stdio.h
//
// Demonstrate a resizer class for widgets in an Fl_Scroll
// erco 1.0 ??/??/04 - original test program
// erco 1.1 04/21/13 - modernized
//
// CLASS FOR HANDLING A 'RESIZER' BETWEEN WIDGETS IN AN Fl_Scroll
//
// Shows a resize cursor when hovered over
// Assumes: * Parent is an Fl_Scroll
// * All children of Fl_Scroll are vertically arranged
// * The widget above us has a bottom edge touching our top edge
// ie. (w-y()+w-h() == this-y())
//
//When this widget is dragged:
// * The widget above us (with a common edge) will be /resized/
vertically
// * All children below us will be /moved/ vertically
//
class ResizerButton : public Fl_Button {
int orig_h;
int last_y;
int min_h; // min
height for widget above us
void HandleDrag(int diff) {
Fl_Scroll *grp = (Fl_Scroll*)parent();
int top = y();
int bot = y()+h();
// First pass: find widget directly above us with common edge
//Possibly clamp 'diff' if widget would get too small..
//
for ( int t=0; tgrp-children(); t++ ) {
Fl_Widget *w = grp-child(t);
if ( (w-y()+w-h()) == top ) { //
found widget directly above?
if ( (w-h()+diff) min_h ) diff = w-h() - min_h; // clamp
w-resize(w-x(), w-y(), w-w(), w-h()+diff); //
change height
break; // done
with first pass
}
}
// Second pass: find widgets below us, move based on clamped diff
for ( int t=0; tgrp-children(); t++ ) {
Fl_Widget *w = grp-child(t);
if ( w-y() = bot )//
found widget below us?
w-resize(w-x(), w-y()+diff, w-w(), w-h()); //
change position
}
// Change our position last
resize(x(),y()+diff,w(),h());
grp-init_sizes();
grp-redraw();
}
public:
ResizerButton(int X,int Y,int W,int H) : Fl_Button(X,Y,W,H,///) {
orig_h = H;
last_y = 0;
min_h = 10;
align(FL_ALIGN_CENTER|FL_ALIGN_INSIDE);
labelfont(FL_COURIER);
labelsize(6);
}
void SetMinHeight(int val) { min_h = val; }
int GetMinHeight() const { return min_h; }
int handle(int e) {
int ret = 0;
int this_y = Fl::event_y_root();
switch (e) {
case FL_FOCUS: ret = 1; break;
case FL_ENTER: ret = 1; fl_cursor(FL_CURSOR_NS); break;
case FL_LEAVE: ret = 1; fl_cursor(FL_CURSOR_DEFAULT); break;
case FL_PUSH: ret = 1; last_y = this_y; break;
case FL_DRAG:
HandleDrag(this_y-last_y);
last_y = this_y;
ret = 1;
break;
default: break;
}
return(Fl_Button::handle(e) | ret);
}
void resize(int X,int Y,int W,int H) {
Fl_Button::resize(X,Y,W,orig_h
Re: [fltk.general] Fl_tile: don't shrink, just shift
On 04/20/13 14:04, dirac wrote: Hi guys, I'm building a stack of horizontal widgets, like that (I hope the ASCII art works): +---Fl_tile---+ | +-+ | | | widget 0| | | +-+ | | +-+ | | | widget 1| | | +-+ | | +-+ | | | widget 2| | | +-+ | |++ I would like to make each widget vertically resizable, so an Fl_tile seems a good choice for a container. Unfortunately I've noticed that Fl_tile shrinks the other widgets: for example if I enlarge Widget 0 completely to the very bottom, widget 1 and widget 2 disappear, i.e. their height becomes zero. My question: is there a way to extend Fl_tile so that it shifts the other widgets below Widget 0, instead of shrink them? Possibly Fl_tile should also expand itself vertically to make room for the other widgets. I made one of these once; in my case I didn't use a tile, just used a regular Fl_Group in which the widgets were positioned, and put a thin widget between each that acted as a 'resizer' which: 1) enlarged/shrunk the widget above it 2) enlarged/shrunk the parent group 3) moved all the children below it up/down The resizer class responded to FL_MOVE so that the cursor would turn into a north/south cursor, and responded to FL_DRAG to handle dragging. So basically: +---Fl_tile---+ | +-+ | | | | | | | widget 0| | | | | | | +-+ | | | resizer | | | +-+ | | | | | | | widget 1| | | | | | | +-+ | | | resizer | | | +-+ | | | | | | | widget 2| | | | | | | +-+ | +-+ You can either have resizer make assumptions about parent() being an Fl_Group and assume all widgets within that parent are inspected to see if the widgets are above or below the current 'resizer' being moved, so that only the widget immediately above is resized, and widgets below are moved, and all the other child widgets are left alone. Then just call the parent's init_sizes() to let it know the children have changed size. I suppose you could then put this entire group inside an Fl_Scroll, so that if the children resize off the screen, a scroller will appear.. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] How to make a 3 position toggel switch
On 04/21/13 02:09, Ian MacArthur wrote: Can someone to point me to a toggle switch widget? There's no 3-position switch that I'm aware of. When I needed this, I just put 3 radio-buttons in a group and that was fine - and trivial to do. Ya, or an Fl_Menu_Button with three items in it -- less screen real estate. Use that if the user only needs to see which state the switch is in. Otherwise, use the radio button approach if it's more useful that the user see all three things, and which one of the three is on. A toggle switch or 3 position dial would simulate the real world better, but is perhaps not a good paradigm visually. But if you really want to go that route, paint three images of the switch in the various positions, and derive a class from Fl_Button that has one of the switch images assigned as the image() for the button, and each hit of the button switches the image() to show the other painting of the switch. Set it up so that each hit toggles to the next of the three states. Use a char or int to keep track of the current state, and just cycle through it each click; 0-1-2-1-0-1-2.. or 0-1-2-0-1-2.. whichever is best. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.development] [RFE] STR #2953: Add append() method to Fl_Multiline_Output and friends
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2953
Version: 1.3-feature
Seems odd that Fl_Multiline_Output and Fl_Multiline_Input
don't have an append() method.
insert(string) is not quite the same, such as if the user has
moved the cursor, but the app wants to append().
Adding this method to Fl_Input_ would effectively add it to the
above two classes, where its absence is felt the most.
I think this method could simply be:
void append(const char s) {
position(size_); // position cursor at end of text
insert(s); // insert text at end
}
Link: http://www.fltk.org/str.php?L2953
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
101 ICONDISCARDABLE sudoku.ico |_ | icon((char *)LoadIcon(fl_display, MAKEINTRESOURCE(101))); Though I'm uneasy about just assuming the value is 101 - in principle we could make it something else... (though likely never would!) Right -- maintaining the 101 value as a macro definition in the .h file is probably better than having that anonymous 101 magic number appear twice in the .rc and .cxx file. But the value itself, 101, has to be hardcoded /somewhere/, and I think its value is quite arbitrary.. probably chosen by a VS template when the project was first created from the VS IDE. Still, there's definitely clarity benefits to having that value assigned a macro name (IDI_ICON) and using it consistently in the .cxx and .rc. Also, it's good to have all resource numbers centralized in a single .h file, esp. if other resources might be needed in the future, to avoid overlapping the resource index numbers. (I assume that's what those are) The reason I mentioned the 101 as clear text in .rc and .cxx is that by doing so, you then don't even need the sudokurc.h file at all. Still, I suppose even if the sudokurc.h file were just a one liner define for IDI_ICON - 101, it's better to have that extra level of indirection than an anonymous magic number in the .rc + .cxx files.. I was thinking we'd just try and make it match the pattern set by the Sudoku example, for consistency? Right, though perhaps the sudoku example could/should be simplified; not sure. I guess if the VS IDE is just going to write over the .rc and .h files with the template junk, then it's probably pointless to simplify these files if they'll just be overwritten. But IIRC, the Express versions of the VS IDE doesn't come with a resource editor anymore; I think it's a Pro only feature now.. so if you click on the .rc file in the project, you get an error. (Something to the effect of go pro if you want to edit resources) So I imagine most folks would be managing the resource files by hand now, so perhaps the simpler they are, the better. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: win32 Fl_Window::icon()vs Fl_Window::xclass()
On 04/16/13 01:57, MacArthur, Ian (Selex ES, UK) wrote: In fact, I think when the following three calls are being used together, they have to appear in this specific order or they won't work right.. at least on win32 anyway: 1) icon() -- if used with xclass(), this must be first 2) xclass() -- if used with icon(), this must come after icon() 3) show() -- if any of the above are used, this must come last I guess the code has diverged a bit from the docs, or MS has changed things whilst we were not looking... Just as a side note; I was using the VS7 (ancient) compiler to do the above tests (I still use VS7 for building my commercial apps), but double checked in VS 2010 as well. Both compilers seemed consistent, so if MS did change something, it would've predated VS7. (Entirely possible, as our docs are much older than that, lol) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Multithreaded windows
On 04/16/13 06:15, Andrew wrote: All process of work with text editor is based on work with text buffer ( which in my design is unique for each window) and reacting on buttons callbacks like copy, open,etc. One thing of importance; Fl_Text_Editor uses the Fl_Text_Buffer to render itself, so you have to be sure if a thread is fiddling around with Fl_Text_Buffer, the main thread has been put to sleep while it does its work. I suppose speed wise this will not be much different. It would only be different if you had multiple threads working at the same time, and even then, if both threads are working with Fl_Text_Buffer, they'll need to lock each other out to prevent races and deadlocks. 1) Is it possible to make callback functions multithreaded? Maybe you can give some example? The callbacks are triggered by FLTK, so they'll be called only from the main thread. You can start threads yourself if you want from those callbacks. 2) The lags(long-term operations) in my program are unexpected by design so I don't know in which place to make FL::awake() to give control back to main thread. Hmm, I think you'll have to figure out where the lags are first. If the lags are because you're doing a 10,000 line insert into the editor's buffer, and the buffer's insert() operation is taking a lot of time doing it, using threads won't be solving that problem, because the entire Fl_Text_Buffer will need to be locked during that time, which means the FLTK thread will need to be on hold. If you have multiple windows each potentially doing operations at the same time, then maybe child threads would be safe to use if they're each working on the different window's Fl_Text_Buffers while the main thread is locked out. The goal is you don't want the FLTK thread (the GUI thread, or main thread) to be doing anything with the Fl_Text_Buffer's while your child threads are modifying them. Have to get back to work ;) perhaps someone else can take on the rest of your questions.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Article/video on Widget design - Was Re: [RFE] STR #2951: DoubleSlider...
On 04/15/13 00:48, Duncan Gibson wrote: I'm diverting this to fltk.development rather than this specific RFE... Sorry about cluttering up your STR, but I was on a roll. Tried to move it to fltk.dev, but I'd've (*) had to make an intro and write for a wider audience.. just the thought of it was messing up my flow. Greg wrote: It occurs to me maybe I should write an article or make a video or something on how to make an FLTK widget, all the wacky details and implications. I wish I had one when I was writing Fl_Tree and Fl_Table, as there's a lot of stuff about keyboard nav and when() that I didn't know about until much later.. making it hard to go back and retrofit..! It would certainly be useful to have a set of hints on all of the areas that need to be considered, and in what order they should be addressed during development. For example, I rarely customize a new desktop and always stick to the default themes, so I have no idea whether themes have to be built in from the start, or if they are easy or difficult to retrofit later. It might actually be useful and fun to work through the design and implementation of a new widget, one step at a time, using such a set of hints, and eliciting feedback from the [widget] developers along the way, in order to (a) debug and improve the hints, and (b) give the basis for a Designing your own widget page in the documentation. Yes, a short list would be good at least. Your widget is interesting in that it has two moving parts. In that cases it usually helps to split the widget up into separate widgets, one widget per moving part, so that each thing that needs focus will be handled by FLTK's own event delivery system through the widget hierarchy, which would also gracefully handle things like focus, keynav, etc. I think your widget could maybe be a simple Fl_Group that could host two Fl_Valuator widgets to handle the two tabs, but it might get tricky. You wouldn't want to overlap them (that would be bad, as they'd disagree over the common real estate for mouse clicks), but perhaps abutting them side-by-side, and let the parent widget handle changing their sizes to always be abutting. That might get tricky though if you decide to support locked behavior, where dragging in the trough between the two tabs moves both. You'd probably want the parent's handle() method to take control at that point, as the parent will doubtless want to resize both valuator's xywh dimensions to keep them abutting while the range is changing. I suppose another route to go would be to make completely custom tab widgets that only have the tab as their governing real estate, and dragging them just changes their xywh position. The widget could have a VERTICAL | HORIZONTAL flag so that its position could be limited to a single dimension of travel, and could have an xmin/xmax ymin/ymax to limit travel along that axis, which the parent group widget could maintain. Then the parent would own the 'trough' and could handle an optional graticule and 'locking bar' that could be slid around to lock the two tabs together. It's definitely easier to plan and conceive new widgets from the perspective of understanding the big picture of FLTK's underlying mechanisms (when()/focus/handle()/event delivery/etc).. which is why it's so important to have something in our docs on how to write custom widgets. This way when folks go off to write custom widgets, they don't leave stuff out. There should probably be separate sections describing different types of widgets, like buttons vs. text vs. tables vs. browsers vs. file browsers vs. radio buttons vs. simple drawing areas, etc. and describe which fltk features each uses, and explain common programming patterns used by these widgets. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 04/15/13 09:53, David FLEURY wrote: I reactivate this, just to known if I had to keep it somewhere on my repo to patch my fltk, or something like this will be apply in the official repo. If I understand this correctly, making a win32 icon for the fluid app so that the fluid.exe will appear in a file browser with an icon? I think the most flexible way of doing this would be to link a resource file with the icon into the binary at link time. Whenever I've needed this, the approach I use is implemented purely in the Makefile, ie: [1] echo 0 ICON /path/to/my/icons/myapp.ico myapp.rc [2] cl myapp.obj myapp.rc $(LIBS) /subsystem:windows This could probably be done as custom build flags in VS as well; step [1] creates a small one line .rc file that defines where the .ico file is, and step [2] links the rc file into the app, which pulls the .ico into the binary. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 04/15/13 13:28, David FLEURY wrote: Le 15/04/2013 21:57, Ian MacArthur a écrit : Is there an STR for this somewhere? I can't find it... so I can't find the patch. I am not used to create a STR. I did not create one. Ian; he included the patch here on fltk.dev at the head of this thread. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 04/15/13 14:28, Ian MacArthur wrote: On 15 Apr 2013, at 22:13, Greg Ercolano wrote: On 04/15/13 13:28, David FLEURY wrote: Le 15/04/2013 21:57, Ian MacArthur a écrit : Is there an STR for this somewhere? I can't find it... so I can't find the patch. I am not used to create a STR. I did not create one. Ian; he included the patch here on fltk.dev at the head of this thread. Oh, OK. I had the sense, from what he was saying, that there were changes to the patch - David and I discussed this patch a few days back, and I think he was tweaking things about, so I wanted to see where we have got to. I also wanted to take a peak at the icon, so I thought that posting all the bits to an STR would be the easiest option. Also, would make it easy for others to pitch in... Ah, OK, yes, agreed it's time for an STR. FWIW, and as a separate issue, I *think* the .rc file can be a simple one liner. (I'm all about simplicity and understanding everything in the files I build) For instance, with sudoku, it seems I can change the sudoku.rc file to just contain: 101 ICONDISCARDABLE sudoku.ico ..and in the sudoku.cxx: icon((char *)LoadIcon(fl_display, MAKEINTRESOURCE(101))); ..and I think that would get rid of the need for a sudokurc.h file, and shortens the .rc file quite a bit. So with those two things, one can compile from the command line (I use gmake scripts); To compile the one line sudoku.rc - sudoku.res: rc -r sudoku.rc ..and to link: link [..] sudoku.obj sudoku.res [..] ..and then the resulting exe shows up in the browser with the icon, and when executed, the titlebar shows the icon as well. This change seems to work within the vs IDE as well. So perhaps fluid could be just as simple. Just seems like the shorter the better, but I really don't know what all that other cruft is in those files. Heh, does anyone, really? :P ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] RFC: win32 Fl_Window::icon() vs Fl_Window::xclass()
I just noticed a few things on win32: [1] If an app sets the window's xclass() *before* it sets the icon(), the icon won't show up in the title bar. [2] In the win32 osissues page, under Setting the Icon of a Window there's a NOTE: that reads: You must call Fl_Window::show(int argc, char** argv) for the icon to be used. The Fl_Window::show() method does not bind the icon to the window. This no longer seems to be true, at least empirically. And I think Albrecht once commented he noticed this as well, and wondered aloud if this comment was outdated, if ever true. Is [1] known behavior that should be documented? Is [2] really obsolete and should be removed, or are the empirical observations simply undefined behavior? Regarding [1], it was driving me nuts today, so if it really is order dependent, we should document to prevent insanity. In fact, I think when the following three calls are being used together, they have to appear in this specific order or they won't work right.. at least on win32 anyway: 1) icon() -- if used with xclass(), this must be first 2) xclass() -- if used with icon(), this must come after icon() 3) show() -- if any of the above are used, this must come last ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selecting low and high values within min/max range
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature Can't say regarding [1] or [2]. For [3], I'd say google for double slider widget and range slider and see what you can gather in the way of options. And maybe check out those widget's API to see if they have anything clever. I guess such things can be used for everything from temperature to date ranges. For the latter, it sounds like a app-provided callback could be used to convert numeric values to/from strings such as dates. Options I noticed from doing the above google searches: a graticule option drawing an optional box between the tabs ability to drag the above box (to move both tabs locked together) option to show text fields above and below the tabs options for text fields to be editable options for text fields to include up/down arrows options for text fields to be integer vs. float support Fl::scheme(gtk+) (and possibly plastic) arrow shaped tabs instead of raised rectangles (tinypic link below) option to show high/low values above or to side of slider at all times (instead of as a tooltip),eg: http://content.w3avenue.com/2009/components/jquery-ui-slider-from-select-element/cover.jpg data string callback (or virtual method) that lets the app convert numeric values to app defined strings (such as int-date conversion) Also: this little 'gif video' is neat; a bit over the top with features, but it shows the 'dragging tab lock' mentioned above: http://www.slicer.org/slicerWiki/images/6/6b/VolumesModuleWindowLevelSliderPopup.gif Also: http://dribbble.s3.amazonaws.com/users/58823/screenshots/303390/slider.png http://i48.tinypic.com/2ebsn5i.jpg Regarding [4], yes, I think a min/max for the entire range would be needed, unless you wanted it to be a fixed 0.0 to 1.0 range slider, which might simplify the API, but makes the user's job harder. (Seems the widget should try to support values the app would want, including ints, floats, and perhaps even strings as described above) Of course doing all the above is probably too much, but perhaps it'll give some idea as to how to design the widget so that such features could be provided by the app by its overloading the widget. Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selecting low and high values within min/max range
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature Oh, and for [5], I think tooltips would be good for some but not all cases.. text fields that are always visible would probably be needed very much as well.. perhaps an option for one or the other or both. Definitely try to plan so the user can override things like draw() and perhaps being responsive to FL_WHEN_CHANGED (so the callback is called during dragging) or on FL_WHEN_RELEASE (only called back when the user is done moving a tab) If you have an option for drawing a box between the tabs, I guess plan it so that the box is reactive to Fl::scheme(gtk+) or plastic so that the box drawing style inherits e.g. gradient behavior.. perhaps even the tabs themselves, and the widget's trough.. Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selecting low and high values within min/max range
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature Oops, and responsive to keyboard navigation. This means: o responding to FL_FOCUS to handle drawing the focus box (or not based on focus visibility) o possibly allowing the two tabs to be keyboard selectable via Tab and Shift-Tab o responding to the arrow keys to let the user alter the tab positions (perhaps the arrow key step value to be selectable in the widget's API), o Perhaps even a separate step rate for Ctrl-Arrows o Probably respond to left/right arrow for horiz slider or up/down arrow for vert slider Perhaps some of the arrow behavior comes for free if you derive from FLTK's existing valuator widgets. Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selecting low and high values within min/max range
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature ..and don't forget to take into account handling deactivation, affecting how the widget draws itself, etc. It occurs to me maybe I should write an article or make a video or something on how to make an FLTK widget, all the wacky details and implications. I wish I had one when I was writing Fl_Tree and Fl_Table, as there's a lot of stuff about keyboard nav and when() that I didn't know about until much later.. making it hard to go back and retrofit..! Link: http://www.fltk.org/str.php?L2951 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Access to Forum and STR pages
Glad you've got the login stuff sorted. However, this is weird: On 04/13/13 03:27, Duncan Gibson wrote: Anyway, I was about to update the commits graph on Article #825, and went to http://fltk.org/site/str.php?L2806 to download the python and gnuplot scripts only to find the attachments all appear to be 0k and then give a Not Found message if I click on them. Hmm, where did you get that link from? It's subtly different than what it should be. (the /site/ after the domain name seems wrong) I looked at article #825 but didn't see that link in there, so curious where it came from. Yes, if I visit that link shown above, the STR shows OK, but none of the attachments work. But if I visit the STR links auto-posted to the fltk.dev group for the changes you made, that link works normally, and all the attachments show up fine. So in other words, comparing the bad link above, and the good link from the STR system: BAD: http://fltk.org/site/str.php?L2806 GOOD: http://www.fltk.org/str.php?L2806 The www. part seems irrelevant, but the /site/ part is what seems to be bad. So removing the 'www.' I get: BAD: http://fltk.org/site/str.php?L2806 GOOD: http://fltk.org/str.php?L2806 In both cases the STR shows fine, just the attachments won't show for the BAD link. (The attachments have the /site/ prefix too, which is the problem) Probably something that can be fixed in the PHP, but I'm wondering where that bad link came from to begin with. Perhaps the BAD link is just old, and the php scripts were modified to have simpler URLs, so links from ages ago might be partially broken, and our str.php script could simply strip off the /site/ part of the URL (if any) to make old links work OK. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] can't get no FL_DRAG event
On 04/13/13 14:47, testalucida wrote:
can someone explain, what's wrong with this code? There's no FL_DRAG event
upcoming in the Box class:
The docs for the FL_DRAG event will tell you why:
http://fltk.org/doc-1.3/events.html
Under the section Mouse Events:
FL_DRAG
[..]
In order to receive FL_DRAG events, the widget must return non-zero
when handling FL_PUSH.
So add this one line to your handle() method:
if (evt == FL_PUSH) rc = 1;
Or, just rewrite the handle() method with a switch(), ie:
int handle(int evt) {
int rc = Fl_Box::handle(evt);
switch (evt) {
case FL_PUSH: rc=1; break
case FL_DRAG: printf(Dragging..\n); rc=1; break;
}
return rc;
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) Albrecht We're only calling const methods anyway, as x(), y(), window(), Albrecht and this code is not subject to be changed in the future. Yes, though for some reason as_window() is not const, (it probably should be), which is why that cheat is necessary at the end there. Maybe using const_castFl_Widget*(w)-as_window() is better, which is what I decided to go with in top_window_offset().. will check. Note in manolo's implementation, const is cast away at the top at the declaration of the variable, but I just switched it to const and cast const away only at the place where it was needed, at the as_window() call. So this does two things: 1) Keeps the variable const so one can't later add code like w-label(yoo hoo); without getting an error.. hey, it could be more subtle ;) 2) Highlights exactly where the cheat is needed (at as_window()) so if as_window() ever changes in the future to be const, it's easier to find and remove the const cast-away. Is there a reason as_window() and friends (other virtual implementations) are not const methods? Fl_Window::window() is. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method toFl_Widget that returns its top-level window
On 04/12/13 01:20, MacArthur, Ian (Selex ES, UK) wrote: @manolo: Great -- agree with all, except perhaps loosing const here: - const Fl_Window *win = (const Fl_Window*)this; + Fl_Widget *win = (Fl_Widget*)this; I think we can maintain const protection on the variable this way: const Fl_Widget *win = this; : return ((Fl_Widget*)win)-as_window(); Does that not throw a warning (or even an error) about casting away the const-ness of win, though? No complaints here; checked the mountain lion compiler, VS 2010, and the most recent linux compiler I have, 4.4.6 I don't see a way around casting away const, because we want to use as_window() which, for some reason (?) is not const itself. (Seems it should be a const method, just like window() is) That certainly sounds like a worthy intent, if it does not trigger any compile-time issues. I suppose we could do a more C++ish cast instead, so the compiler would know we really meant it! (i.e. const_cast) Yes, was thinking that myself, as I used that (a few lines up) at theend of the new top_window_offset() for the exact same reason (calling as_window()); will do that here as well, because that flies on all the compilers I have as well. I think we should go for it... Done; r9875 + r9876. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widgetthatreturns its top-level window
On 04/12/13 10:44, Albrecht Schlosser wrote: Yes, though for some reason as_window() is not const, (it probably should be), which is why that cheat is necessary at the end there. Maybe using const_castFl_Widget*(w)-as_window() is better, which is what I decided to go with in top_window_offset().. will check. Using const_cast is only another way to write it, but means the same essentially, doesn't it? Yes -- just more c++-esque. Should change it I think for two reasons; I already use it for the exact same reason in the new top_window_offset() method (just a few lines up from top_window()), and (2) it's probably clearer readability-wise that the goal is to explicitly cast away const (and not do something else, like a type conversion) However, if some compilers wouldn't flag a warning for const_cast but would for the old-style cast, then we could maybe use it, but according to the CMP this shouldn't be used for fltk 1.1 code, however it should be used for 2.0 code. 1.3 code is not (yet) specified, so we'd have to make a decision about this first. Open to alternative suggestions, but all the code provided here basically casts away const in one way or another, as we're defining a const method that starts with a pointer to 'this' (and therefore has to be const), but also need to call a non-const method as_window() through that pointer. Concerning as_window(): ISTR that the first proposal was const, but for some reason someone removed the const, but I'm not sure about it. Interesting; I'll try to track that conversation down, I'm kinda curious what the reason could possibly be. Seems the code implementation is pretty simple; it either returns '0' or 'this', and the virtual aspect handles the 'logic'. The method itself clearly makes no changes to the class, so it really could be const. 2) Highlights exactly where the cheat is needed (at as_window()) so if as_window() ever changes in the future to be const, it's easier to find and remove the const cast-away. Fair point. Is there a reason as_window() and friends (other virtual implementations) are not const methods? Fl_Window::window() is. You mean: Fl_Window* Fl_Widget::window() const is, right? Yes, emphasis on the method itself being const, not concerned with the return value. window() is a const method, but as_window() is not; seems odd. Other than what ISTR (see above), I don't know. Probably Fl_Window* Fl_Widget::window() could be const as well, but can we change it w/o breaking the ABI? I'm thinking you must have meant: Fl_Window* Fl_Widget::as_window() could be const as well ..emphasis on as_window() as opposed to window(), which already is const. Yes, too late to change I think, unless protected with our friend the ABI macro. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Widget::as_window() and friends const ? [was: STR #2948: Adda method to Fl_Widget that returns its top-level window]
On 04/12/13 11:05, Albrecht Schlosser wrote: Hmm, I'm not a const and ABI specialist, I mean I don't know all the implications that would arise if we changed this method. Ya, I'll have to double check that one, but I think changing the prototypes (args, return values) of existing methods affects ABI, but perhaps not const.. You'd think it wouldn't matter, as const is not really a data size thing, it's just a permissions thing. But not sure. If for no other reason, macro'ing it out would allow it to be investigated easily, and concurrently flagged to be part of the next release. That said, what about one additional method for each of these that is const and returns a const pointer, like this patch: I'm not expert on this either. I'm thinking as_window() (and friends) should be more like the window() prototype (const method, returns non-const pointer) if for no other reason, just to be consistent. window() has been around for a looong time, and I don't think anyone's ever requested const variations, so not sure variations would be needed..? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method toFl_Widgetthat returns its top-level window
On 04/12/13 13:19, Ian MacArthur wrote: I'm in favour of allowing the C++ style casts. I expect that it probably works with all the extant compilers now? Does anyone know for sure? The static_cast mod flew in all my tests on redhat9 and irix6.5, and those are as old as the friggin hills. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) Updated fixes in r9875 and r9876. About to close, unless there's more to add. Regarding const mods to at_window() and friends, let's continue that on fltk.dev and make a separate STR for that. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) Oh, I should add.. all mods to date (r9876, including static_cast) build OK on: redhat9, irix6.5, centos 5.6, Mountain Lion default compiler (picky), Sci Linux 6 (very picky, latest linux I have) gcc 4.4.6, and VS 2010. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) Sorry, as Ian points out on fltk.dev, meant to say const_cast in the above, not static_cast. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9876) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a methodtoFl_Widgetthat returns its top-level window
On 04/12/13 16:17, Ian MacArthur wrote: The static_cast mod flew in all my tests on redhat9 and irix6.5, and those are as old as the friggin hills. You say static_cast here? Bleh, mental typo. I meant this: $ grep const_cast Fl_Window.cxx return const_castFl_Widget*(w)-as_window();// return if window, or NULL if not return const_castFl_Widget*(w)-as_window(); ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) @manolo: Great -- agree with all, except perhaps loosing const here: - const Fl_Window *win = (const Fl_Window*)this; + Fl_Widget *win = (Fl_Widget*)this; I think we can maintain const protection on the variable this way: const Fl_Widget *win = this; : return ((Fl_Widget*)win)-as_window(); ..this ensures const protection for all uses of win within the code, and we only turn it off when we need to (eg. the non-const as_window() call) Also, I should probably change all instances of 'win' - 'w' in the code, since it's really working with widgets now. Thanks for the peer review -- will hold on comments regarding const above, as am curious if there's a reason not to. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
We can probably avoid breaking ABI if we implement this new bitflag
as part of the existing flags, eg:
enum { // values for flags:
:
FL_MENU_NOCLOSE = 0x200 // Don't close menu if submenu|checkbox
clicked
};
Unless I'm missing something, is there a reason to avoid this?
Link: http://www.fltk.org/str.php?L2950
Version: 1.3-feature
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2950: Menu Item behaviour
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature Oh, I see, you are suggesting this, /and/ a global flag to affect the entire menu, yes. I guess we can't avoid breaking ABI for the global flag, which is probably best implemented in Fl_Menu_ by adding an int to the class, protected by our new ABI macro so it can be used during patch releases) Link: http://www.fltk.org/str.php?L2950 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Caps Lock detection
On 04/11/13 02:18, MacArthur, Ian (Selex ES, UK) wrote:
If I understand correctly, the capslock state info is correct during
regular keypresses, just not when the capslock key is hit.
Yes - in all the tests I tried, the Caps Lock state was always correct
during (and after) regular key presses.
Yes.
However, any attempt to discern the Caps Lock state immediately after
the Caps Lock key was pressed / released a few times, with no other
key pressed since, was unreliable.
Right, though this seems to be specific to your VM.
Originally I thought the behavior was random, but looking closer,
it's actually predictable and reliable (just not what I'd expect).
Digging deeper, I found that the behavior across all versions of X
I currently have access to (Irix/redhat9/centos5.6) is /consistent/
and /predictable/ across all of them for this, with both X11 and FLTK
code.
I rewrote the two programs (see below) to show clearer output,
including some fflush()s so that they would pipe correctly through
grep(1).
When capslock is toggled, the state info in the xevent and
Fl::event_state()
for the CapsLock key Press/Release and FL_PUSH/FL_RELEASE events is:
KeyPress: what the state was BEFORE the key was pressed
KeyRelease event: state is *always* 1.
So the reliable info is on KeyPress, it tells you what the state of
capslock
WAS, and not what it will become.
Ditto for FLTK.
So if I pipe both programs thru grep Press, I see the capslock state
flag toggle
reliably, the state being what the key WAS before the key was hit, no
matter how
fast I toggle the key (And if I grep Release, the flag is always on)
Here's the output of the below X11 and FLTK programs piped through
grep Press while I toggle capslock:
$ ./test-capslock-x11 | grep Press
X11 Press: off
X11 Press: on
X11 Press: off
X11 Press: on
X11 Press: off
X11 Press: on
..
$ ./test-capslock-fltk | grep Press
FLTK Press: off
FLTK Press: on
FLTK Press: off
FLTK Press: on
FLTK Press: off
FLTK Press: on
Consistent and reliable behavior.
I guess we should see how Win32 and OSX behave, and if they're
reliable
as well, we should either:
1) Document the OS specific behavior, whether different or same,
and leave the code alone
2) Pick one behavior, and modify the code to enforce it, and
document it
In a perfect world I'd say (2), though if we start fiddling around with
the
FLTK event structure's state info, we might be asking for trouble, not
sure..
at very least we could do (1) for the short term.
Anyway, here's the two test apps, X11 and FLTK, which basically do the
exact same thing, but with clearer messages that are grep(1) friendly:
--- snip: start
//
// X11 CAPSLOCK TEST
// Slightly modified X windows hello world
// ref: http://www.cuillin.demon.co.uk/nazz/trivia/hw/hw_c.html
// compile: g++ test-capslock-x11.c -o test-capslock-x11 -lXtst -lX11 -lXext
#include stdio.h
#include stdlib.h
#include string.h
#include X11/Xlib.h
#include X11/Xutil.h
int main(int argc, char *argv[]) {
Display*dpy;/* X server connection */
Window win;/* Window ID */
XEvent event; /* Event received */
// OPEN DISPLAY
if ((dpy = XOpenDisplay(NULL)) == NULL) {
fprintf(stderr, %s: can't open %s\n, argv[0], XDisplayName(NULL));
exit(1);
}
// CREATE WINDOW, SELECT EVENTS WE WANT, MAP WINDOW
win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), // create
500x500 window
50,50,500,500,// x,y,w,h
0,// border width
0,0); // border
color, bg color
XSelectInput(dpy, win, KeyPressMask|KeyReleaseMask);// select input
events we want
XMapWindow(dpy, win); // map window
// EVENT LOOP
while (1) {
XNextEvent(dpy, event);// get the event
switch ( event.type ) { // event
received?
case KeyPress:
case KeyRelease: {
const char *emsg = (event.type==KeyPress) ? Press :
Release;
const char *lmsg = (event.xkey.state2) ? on : off;
printf(X11 %s: %s\n, emsg, lmsg); fflush(stdout);
break;
}
default:
fprintf(stderr, * Ignored event '%d'\n, (int)event.type);
break;
}
}
return(0);
}
--- snip:end
[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.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Can the knowledge of the top enclosing window of an object be useful without knowledge of the object coordinates relatively to this window? Simple case would be a widget (say a button) that wants to hide the window its in. If the button is in a subwindow, window() wouldn't work, bot top_window() would. May be what is needed would be along this line: Fl_Window* Fl_Widget::top_window_offset(int xoff, int yoff) Actually just added such a thing in r9866 a few days ago to solve STR#2944, but called it window_offset(). Perhaps I should add top_ to it though.. its not too late. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature as_window() Yes, that looks good.. I'll do some tests; want to make sure it inherits through all the window options we have (Fl_Gl_Window, etc) window_offset() vs. top_window_offset(): I strongly vote for the latter and consistent naming Agreed. Will make changes and implement. We should remove this old and error-prone w-type() = FL_WINDOW from the entire lib in favor of as_window(). OK, I'll try to handle that too, but as a separate commit. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Oh, BTW, I think I missed what Manolo might have been getting at wrt the 'top_window_offset()' method. So where we're at now, just to disambiguate: o There's currently a method Fl_Window::top_window_offset() (just renamed it from window_offset() in r9870) o We're proposing in this STR a new Fl_Widget::top_window(). I can see where the existing top_window_offset() should really be a method of Fl_Widget, not just Fl_Window.. so that even non-windows can find their offset relative to the top window to be more useful. So will look into changing that as well. Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature OK: r9871: top_window(): implemented (using as_window()) r9872: top_window_offset() now a member of Fl_Widget (was Fl_Window) and moved it near top_window() and window(). Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) ..and finally: r9873: CHANGES file updated. Comments before close? Link: http://www.fltk.org/str.php?L2948 Version: 1.3-feature Fix Version: 1.3-current (r9871) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.opengl] Fl_Gl_Window flashes on context creation (Windows7)
On 04/09/13 23:24, Ivan Nedrehagen wrote: I also suspect that there might be problems replicating this bug, so I will try to do some digging of my own. Since I have built the FLTK library on my own, I might tinker a bit with the source and might run a strace (or windows equiv.) on the glut demos and the fltk demos to see if there might be a difference. Yes, strace might be good, and also I think there's a way to view the X11 messages going back and forth.. It might be as easy as setting an environment variable, or attaching a program to the process or some such.. can't remember. Sometimes just running the app through a remote xsession would let you sniff the X11 network messages (ethereal, or wireshark, or whatever its called these days which sniffs network packets and deconstructs them at the protocol level into meaningful messages. Used this once to solve an STR a few years ago where our code was creating zero sized windows IIRC) ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
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.development] RFC: method to find top level window?
On 04/09/13 02:42, MacArthur, Ian (Selex ES, UK) wrote: Anyway, since it's not much code, could we probably add it to the header file as an inline method ? Would an inline method in a header file be DLL friendly though? Though that would limit the ABI impact I guess. Right, inlined code gets compiled in to the app's code, so if changes are made to the lib's internals such that the inline code would need to be modified to support it, that discrepancy leaves the app incompatible with a newer version of the fltk dynamic lib. I've found that if there's a chance an inline method would ever need to be changed to support changes to internals, then it should become regular code in the lib, and avoid an inline. However in this case an inline method might make sense for speed. Also, this code is unlikely to ever need changing, as walking the window hierarchy is very unlikely to change. I think so. If there were a vote request, my vote would be +1, unless there are reasons not to do it that I don't know of (yet). Other opinions, votes? I can't think why we wouldn't have this; I can’t immediately spot any downside. I'd vote +1. I'll make an STR suggesting it, and cite the conversation here so we have a record of it. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: method to find top level window?
On 04/08/13 15:50, Greg Ercolano wrote: On 04/08/13 15:32, Albrecht Schlosser wrote: On 06.04.2013 07:55, Greg Ercolano wrote: BTW: toplevel_window() doesn't look bad, but what about top_window(). Less typing ;-) Yes, what I based 'toplevel_window()' on was that in our code, the term 'top-level' is used fairly consistently to refer to the real window in a widget hierarchy. This, as opposed to 'top' as perhaps meaning the window on top of all others in window depth (along the Z axis) I have no real preference otherwise. While writing a test program, I see the point of 'top_window()' being easier to write, and kinda seems more consistent with FLTK's short names for methods. So I'm +1 for top_window() instead of toplevel_window(). ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
This STR spawned from a discussion on fltk.development,
Subject: RFC: method to find top level window?
The suggestion is to add a method that returns the top-level window
for the current widget, i.e. the 'window manager window' the widget
is in.
This differs from Fl_Widget::window() which may return a sub-window,
if there is one, not necessarily the top-level window.
I suggested toplevel_window() because the term 'top-level' seems
to be used in the code comments, Albrecht offered top_window()
as a shorter alternative, which I think I'll go with here.
Attaching a patch suggesting the code implementation,
toplevel_window.patch.
Also attaching a test program, test-top_window.cxx
which compares the return value of window() and top_window() for
various widgets and windows in the presence of sub-windows.
We should also probably do a code check on all of FLTK
to make sure window() isn't being used where top_window()
would be correct. I believe it's only recently that FLTK reliably
supported sub-windows, so the chances of apps using them are
higher now, and little problems are more likely to spring up,
such as STR #2944 [2].
Comments welcome.
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-featureIndex: FL/Fl_Widget.H
===
--- FL/Fl_Widget.H (revision 9868)
+++ FL/Fl_Widget.H (working copy)
@@ -919,12 +919,8 @@
*/
void measure_label(int ww, int hh) const {label_.measure(ww, hh);}
- /** Returns a pointer to the primary Fl_Window widget.
- \retval NULL if no window is associated with this widget.
- \note for an Fl_Window widget, this returns its Iparent/I window
-(if any), not Ithis/I window.
- */
Fl_Window* window() const ;
+ Fl_Window* top_window() const;
/** Returns an Fl_Group pointer if this widget is an Fl_Group.
Index: src/Fl_Window.cxx
===
--- src/Fl_Window.cxx (revision 9868)
+++ src/Fl_Window.cxx (working copy)
@@ -80,11 +80,33 @@
clear_visible();
}
+/** Returns a pointer to the nearest parent window up the widget hierarchy.
+This will return sub-windows if there are any, or the parent window if
there's no sub-windows.
+If this widget IS the top-level window, NULL is returned.
+\retval NULL if no window is associated with this widget.
+\note for an Fl_Window widget, this returns its Iparent/I window
+ (if any), not Ithis/I window.
+\see top_window()
+*/
Fl_Window *Fl_Widget::window() const {
for (Fl_Widget *o = parent(); o; o = o-parent())
if (o-type() = FL_WINDOW) return (Fl_Window*)o;
return 0;
}
+
+/** Returns a pointer to the top-level window for the widget.
+In other words, the 'window manager window' that contains this widget.
+This method differs from window() in that it won't return sub-windows (if
there are any).
+\returns the top-level window, or NULL if no top-level window is
associated with this widget.
+\see window()
+*/
+Fl_Window *Fl_Widget::top_window() const {
+ const Fl_Widget *w = this;
+ while (w-parent()) { w = w-parent(); } // walk up the widget
hierarchy to top-level item
+ return w-type() = FL_WINDOW ? ((Fl_Window*)w) // is top item a
window? If so, return it..
+: ((Fl_Window*)0); // if not, return 0
+}
+
/** Gets the x position of the window on the screen */
int Fl_Window::x_root() const {
Fl_Window *p = window();
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Pending]
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature
Attached file test-top_window.cxx...
Link: http://www.fltk.org/str.php?L2948
Version: 1.3-feature#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Window.H
#include FL/Fl_Button.H
int main(int argc, char **argv) {
Fl_Double_Window win1(900, 400, Top-level Window);
win1.box(FL_FLAT_BOX); win1.color(FL_RED);
Fl_Buttonb1(10,10,140,25,Button1:in top);
Fl_Windowsub1(10,40,win1.w()-20,win1.h()-40-10,Sub Window);
sub1.box(FL_FLAT_BOX); sub1.color(FL_GREEN);
Fl_Buttonb2(10,10,140,25,Button2:in sub1);
Fl_Windowsub2(10,40,sub1.w()-20,sub1.h()-40-10,Sub2 Window);
sub2.box(FL_FLAT_BOX); sub2.color(FL_BLUE);
Fl_Buttonb3(10,10,140,25,Button3:in sub2);
sub2.end();
sub1.end();
win1.end();
win1.show();
Fl_Widget *w;
w = win1; printf( WIN: top_window()=%p/%-20s window()=%p/%s
\n,w-top_window(), w-top_window()-label(),w-window(),
w-window()?w-window()-label():?);
w = b1; printf( B1: top_window()=%p/%-20s window()=%p/%s
\n,w-top_window(), w-top_window()-label(),w-window(),
w-window()?w-window()-label():?);
w = sub1; printf(SUB1: top_window()=%p/%-20s window()=%p/%s
\n,w-top_window(), w-top_window()-label(),w-window(),
w-window()?w-window()-label():?);
w = b2; printf( B2: top_window()=%p/%-20s window()=%p/%s
\n,w-top_window(), w-top_window()-label(),w-window(),
w-window()?w-window()-label():?);
w = sub2; printf(SUB2: top_window()=%p/%-20s window()=%p/%s
\n,w-top_window(), w-top_window()-label(),w-window(),
w-window()?w-window()-label():?);
w = b3; printf( B3: top_window()=%p/%-20s window()=%p/%s
\n,w-top_window(), w-top_window()-label(),w-window(),
w-window()?w-window()-label():?);
return(Fl::run());
}
//
// End of $Id: table-simple.cxx 9086 2011-09-29 21:10:59Z greg.ercolano $.
//
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Menu behaviour...
On 04/09/13 07:08, Roman Kantor wrote:
I have got a number of complains from end users how the menu items behave -
probably different than they are used to or how other toolkits behave.
The complain is that clicking on ANY item causes the whole menu to close,
even if it is:
1) A submenu. Usually submenu is just an entry point and mouse hovering
opens the submenu automatically, an accidental clicking on this entry point
should not
close the whole menu. Not closing the menu would also indicate that no
action was performed and choosing particular submenu-item is required to
invoke an action
Right.
2) If menu item group is set of check-boxes (I have some application-settings
options as menu checkboxes) and user wants to change a few settings at the
same
time, he/she needs to reopen the menu for each single item change. Sometimes
user re-opens the menu even for single change just to visually confirm that
the
state was changed. In such a case they expect that menu closes only if you
either hit Esc or click menu-opening widget (menu-bar or menu-button)
Yes, I could see where that would be a PITA, and have noticed it myself
in my own apps that use a list of checkboxes in a preferences submenu.
Arguably one should create a dialog for such things as preference
panels,
as menus tend not to be a good interface for such things. I use them
myself,
and realize as my app has matured, I should really make a preferences
dialog.
Still, I'd agree changing radio boxes/check boxes in menus probably
shouldn't
close the menu, and perhaps should be 'new' default behavior, with the
old
behavior selectable with a flag.
I don't know much about FLTK's menu internals, but perusing Fl_Menu.cxx,
it seems that while one is navigating the menus, the variable pp.state
maintains the current state of navigation while a menu is open, and
it's only
when that variable is set to DONE_STATE that the menus close.
Also: while sniffing around in Fl_Menu.cxx where I thought this change
should be made (around FL_RELEASE), I noticed this commented out section
(with #if 0) that might actually do what you want (see ***):
case FL_RELEASE:
// Mouse must either be held down/dragged some, or this must be
// the second click (not the one that popped up the menu):
if ( !Fl::event_is_click()
|| pp.state == PUSH_STATE
|| (pp.menubar pp.current_item !pp.current_item-submenu()) //
button
) {
#if 0 // makes the check/radio items leave the menu up ***
const Fl_Menu_Item* m = pp.current_item;
if (m button (m-flags (FL_MENU_TOGGLE|FL_MENU_RADIO))) {
((Fl_Menu_*)button)-picked(m);
pp.p[pp.menu_number]-redraw();
} else
#endif
So it looks like someone's already been here with that in mind.
If uncommenting that works for you, I guess we should add a flag,
as you say, that lets the app control this. Otherwise, we're open
to patches..
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 04/09/13 12:18, Howard Rubin wrote: On Mon, 08 Apr 2013 20:17:31 -0700, Greg Ercolano e...@seriss.com wrote: unsigned n; XkbGetIndicatorState(d, XkbUseCoreKbd, n); caps_state = (n 0x01) == 1; That works perfectly, and even better, needs no timer. Test program below. Will this be fixed in a future release of FLTK? Again, I think FLTK is doing the right thing to pass the state information X11 is providing; seems it's an X11 issue (see the other X11 code I provided that shows the problem is with X11's events for KeyRelease) We could try to hack our events to use the above to test the state whenever the capslock key is set, and force-set the event state info.. but that's kinda hacky. I'd offer it should be investigated first to see if it's an X11 problem. I'd offer that we could perhaps provide a wrapper to get the state of the keyboard LEDs (for operating systems that provide this) e.g. fl_get_indicators() or some such that returns flags. Arguably if we provided that, we should provide fl_set_indicators() as well. And I suppose the return value could indicate if the OS provides this feature or not (assuming there are OS's that don't provide it) Also: not sure if the XkbGetIndicatorState() function is available on all Unix OS's we support; might need a configure option to detect this. Seems easy enough to implement under X11 at least. Anyone familiar with Win32 + OSX keyboard LED access? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 04/09/13 12:29, Greg Ercolano wrote: we could perhaps provide a wrapper to get the state of the keyboard LEDs (for operating systems that provide this) e.g. fl_get_indicators() or some such that returns flags. Maybe fl_get_keyboard_leds() and fl_set_keyboard_leds() would be better. There might be some resistance to adding this though, since FLTK is primarily a GUI toolkit trying to stay light on its API, its intention to abstract GUI related features, and not abstract all features of the window manager. Guess I'd be curious what other devs have to say. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
I tried the following FLTK code with the above X11 only code and it seemed to work more reliably. Ian writes: Not so much for me - though that may be an issue with the VM rather than a real problem. I find that, with this code, if I toggle Caps Lock on/off a few times, I can easily get to a state where the test code is resolutely reporting Caps Lock OFF, but the keybd LED is ON. Try the xkbvled(1) application. Do you find it too doesn't properly represent the shift lock LED? If so, I'd suggest a problem with the VM or X or both; perhaps report to the VM guys, as it sounds like an emulation issue. Or, it might be the VM is exposing a problem with the one of the two OS's interface to reading the keyboard LEDs.. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.opengl] Fl_Gl_Window flashes on context creation (Windows7)
On 04/09/13 10:07, Ivan Nedrehagen wrote: Which version of FLTK (1.3.1, 1.3.2..) I use FLTK 1.3.2 Also: do the FLTK opengl test programs cube.exe and shape.exe exhibit this same behavior? Yes they do. Right, good to know. I cannot replicate with Win7 + mingw-64 (gcc4.5.2) + fltk 1.3.x-svn current; I am using the 4.7.2 rev 9 with Win 7 Hardware is a mac mini running win7/64 ultimate, default drivers. I use a Dell precision What does this means in terms of the graphics card? Those specifics are probably useful to help replicate. I don't have any dell equipment here (though one of the other devs might), but depending on the graphics, that might help zero it in. I am wondering about the drivers also, but I cannot say for sure. I did upgrade my drivers before posting just to make sure, but still it is strange that I cannot see this behaviour on any other opengl program. I did download and compile freeglut, their demos run smooth without any problems. I see. Well, you could open an STR with all the details we've found to date. It's going to be a problem though if the devs can't replicate. If you're able to identify the issue, supply a patch, or at least let us know what changes the problem if you try messing around with the FLTK innards. You may find something in the FLTK opengl win32 initialization code that needs adjusting. You might try tweaking the freeglut examples to enable features FLTK is enabling (double buffer mode, etc) to see if you can perhaps replicate the problem outside FLTK, to see if it's a particular opengl feature causing the problem. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
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.development] RFC: method to find top level window?
On 04/08/13 15:32, Albrecht Schlosser wrote: On 06.04.2013 07:55, Greg Ercolano wrote: BTW: toplevel_window() doesn't look bad, but what about top_window(). Less typing ;-) Yes, what I based 'toplevel_window()' on was that in our code, the term 'top-level' is used fairly consistently to refer to the real window in a widget hierarchy. This, as opposed to 'top' as perhaps meaning the window on top of all others in window depth (along the Z axis) I have no real preference otherwise. BTW, on a similar new method train of thought; had to add a method to Fl_Widget called window_offset() which returns the x/y offset of the current widget relative to the top-level window (top window? ;) to fix STR #2944 (r9866). Again, I'm indifferent on naming; perhaps there's a better name for what this method should be called. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] FLTK-1.3 group button menus in wrong placewherearranged
//hH
int Sbut::handle ( int event )
{
if ( event == FL_PUSH )
{
cout Sbut handle 1: PUSH endl;
do_callback();
return 1;
}
return 0;
}
Also, unrelated, the above bit of code should be repaired.
As it is, the button's own handle() method is being completely eclipsed.
Fl_Button::handle(event); should really be called in there somewhere
to allow the button's mechanics to operate.
If the purpose of this handle() is just to print a message on PUSH,
then:
int Sbut::handle ( int event )
{
if ( event == FL_PUSH )
cout Sbut handle 1: PUSH endl;
return(Fl_Button::handle(event);
}
..and the button's own code will handle the do_callback() on PUSH.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
On 04/08/13 10:35, Howard Rubin wrote:
On Fri, 05 Apr 2013 23:39:28 -0700, Greg Ercolano wrote:
an fltk timer would probably be needed to get the correct
state info shown reliably.
Thanks for the replies.
No luck with an fltk timer, on Ubuntu Linux 10.04. Test program below.
In the console we can see that (Fl::event_state() FL_CAPS_LOCK)
correctly changes to nonzero as soon as you press Caps Lock.
But it doesn't change back to 0 when you press Caps Lock again
until e.g. you move the mouse over the window.
I'm not sure if this is a bug in X11 or not.. kinda seems so.
X11's own KeyRelease events seem to behave similarly;
in my tests with the pure X11 code below, when X11 sends
a KeyRelease event for the capslock key, the event.xkey.state
shows accurate info when capslock is ENABLED, but INACCURATE INFO
when capslock is disabled.
You have to hit some other key to get the accurate state of
capslock after lock release.
So I think FLTK is simply passing this X11 behavior on to the app.
Not really sure if FLTK can fix this if X11 gives similar info.
My X11's a bit rusty, but there might be a way to acquire the realtime
capslock state by a different X library call -- if there is, you should
probably #ifdef that into your code.
#include stdio.h
#include stdlib.h
#include string.h
#include X11/Xlib.h
#include X11/Xutil.h
//
// Slightly modified X windows hello world
//
// ref: http://www.cuillin.demon.co.uk/nazz/trivia/hw/hw_c.html
// compile: g++ hello.c -o hello -lXtst -lX11 -lXext
//
int main(int argc, char *argv[])
{
Display*dpy;/* X server connection */
Window win;/* Window ID */
GC gc; /* GC to draw with */
XFontStruct *fontstruct;/* Font descriptor */
XGCValues gcv;/* Struct for creating GC */
XEvent event; /* Event received */
XSetWindowAttributes xswa; /* Temporary Set Window Attribute struct */
// OPEN DISPLAY
if ((dpy = XOpenDisplay(NULL)) == NULL) {
fprintf(stderr, %s: can't open %s\n, argv[0], XDisplayName(NULL));
exit(1);
}
// CREATE 500x500 WINDOW
win = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy),
50,50,500,500,// x,y,w,h
0,// border width
0,0); // border color, bg color
XSelectInput(dpy, win, ExposureMask|KeyPressMask|KeyReleaseMask);
// MAP WINDOW
XMapWindow(dpy, win);
// EVENT LOOP
while (1) {
XNextEvent(dpy, event);
switch ( event.type ) {
case Expose:
fprintf(stderr, * Expose event\n);
if ( event.xexpose.count == 0) {
while (XCheckTypedEvent(dpy, Expose, event));
// GET CURRENT WINDOW SIZE (FOR TEXT CENTERING)
XWindowAttributes xwa;
if (XGetWindowAttributes(dpy, win, xwa) == 0)
break;
XClearWindow(dpy, win);
}
break;
case KeyPress:
case KeyRelease: {
const char *ename = (event.type==KeyPress) ? Press :
Release;
printf(%s keycode=0X%04x, state=0X%04x\n, ename,
event.xkey.keycode, event.xkey.state);
break;
}
default:
fprintf(stderr, * Ignored event '%d'\n, (int)event.type);
break;
}
}
return(1);
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
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.opengl] Fl_Gl_Window flashes on context creation (Windows7)
On 04/02/13 02:28, Ivan Nedrehagen wrote: Does anyone know how I can get the Fl_Gl_Window to play nicely in windows? Which version of FLTK (1.3.1, 1.3.2..) Also: do the FLTK opengl test programs cube.exe and shape.exe exhibit this same behavior? I cannot replicate with Win7 + mingw-64 (gcc4.5.2) + fltk 1.3.x-svn current; your app opens right up, no weird behavior while it opens. Same with the cube.exe and shape.exe demos. Hardware is a mac mini running win7/64 ultimate, default drivers. If you're getting this behavior with all the GL demos, try downloading GLUT and see if their demos do it too. If so, it's probably your GL drivers. If not, let us know.. ___ fltk-opengl mailing list fltk-opengl@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-opengl
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.development] [RFE] STR #2945: Virus is detected when being compiled in MSVS 2010
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2945 Version: 1.3-feature Have you ruled out this might be a problem with your own machine? Have you had problems with viruses recently? (ie. if you have an out of data java interpreter, etc. that is causing binaries that link against possibly corrupt libraries on your machine to, by extension, appear to be corrupt themselves?) Have you ruled out building code from other toolkits causes the same problem, eg. try building wxwidgets or the opengl demos. Is there a pattern in the files Avira is detecting, such as all the opengl oriented demos? (CubeViewd.exe is a debug build of an opengl oriented app) Please include a list of all files it detected, as there may be a pattern in the files it detects, ie. all the opengl oriented applications, or the opengl debug libraries. (You mentioned cubeviewd, which uses opengl) If there is a pattern, it's possible the problem is a corrupt library on your machine (eg. opengl related) that is getting linked into the executables causing the problem. Let's rule all that out first. Link: http://www.fltk.org/str.php?L2945 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] src/Fl_mac.cxx -- dead code?
On 04/06/13 09:02, Manolo Gouy wrote: Seems nutty, but is the entire file src/Fl_mac.cxx unused code? Perhaps it should be removed from SVN, Yes, Fl_mac.cxx is now totally useless, being replaced by Fl_cocoa.mm. I believe it can be deleted, since one can recover it from svn in the unlikely case it becomes necessary. Thanks, Manolo! Done; r9863 (remove, CHANGES mod) and r9864 (src comment mods). ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Caps Lock detection
On 04/05/13 22:58, Edzard Egberts wrote: It seems, that caps-lock handling starts to work after key handling and I think there might be other problems, like switching caps lock, when there is another window in focus. I think a better way is, to use a timer and to check for change of state e.g. all 0.25 seconds. For humans this is fast enought to appear as instantly. Perhaps this problem is perceived in test/keyboard as well by the 'LOCK' state flag staying set while the caps lock key is toggled repeatedly. I found it updates correctly if I just resize the window, so I was thinking the same thing, Fl::event_state() might not have valid state info for the caps lock key at that point in time in the handle() function, and that indeed an fltk timer would probably be needed to get the correct state info shown reliably. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
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
[fltk.development] mods to fltk-config.cmake.in in r9861
Hmm, aren't we loosing the close of /dict with this change? Modified: branches/branch-1.3/fltk-config.cmake.in === --- branches/branch-1.3/fltk-config.cmake.in2013-04-05 15:09:50 UTC (rev 9860) +++ branches/branch-1.3/fltk-config.cmake.in2013-04-05 15:28:43 UTC (rev 9861) @@ -317,7 +317,8 @@ string$post/string keyCFBundlePackageType/key stringAPPL/string -/dict + keyNSHighResolutionCapable/key + true/ /plist EOF ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Caps Lock detection
On 04/05/13 08:59, Howard Rubin wrote: I need to immediately detect when Caps Lock is turned on or off in our login screen, so I can alert the user. Neither of the approaches I've tried works. Do you see the same problem when using the fltk test/keyboard application? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
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.development] This was proposed before and rejected but just in case here it'sagain Fl_Help_View
On 12/12/10 06:08, Domingo Alvarez Duarte wrote: Due to the massive modifications there is no patch here it's the whole new Fl_Help_View Re-awakening this old thread to revisit.. Domingo, unfortunately I think the code you attached in this thread is the original fltk source code for r7903.. the attachment being different only by having DOS line endings. I just downloaded fltk r7903 (this is the svn ID rev in the code posted) and xdiff'ed the FLTK source against your attachment; seems to be the same code. I know I've seen your mods before.. will look back in the forums and STRs. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Help_View code cleanup and optimizations revised with minimalindentation changes, attached 100KB
On 03/08/10 08:03, Domingo Alvarez Duarte wrote:
I've got the original files and inserted on then only the changes I
made, quite a lot !
OK, here's an older thread with your Fl_Help_View.{cxx,H} files
that have your changes; add these to STR# 2634 as a zipfile:
mingodad--03-08-2010-Fl_Help_View-orig-vs-new-as-patches.zip
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
On 04/04/13 02:52, MacArthur, Ian (Selex ES, UK) wrote: I tried to show some html-text for help, but Fl_Helpview doesn't take care of br and mucks up formatting. Doc tells, Fl_Helpview should take care of br, shouldn't it? Hmm, yes, that does seem a bit broken... As a hackaround, it looks like replacing b with p/p seems to do something... Any good? Yes, P should give you a paragraph break. But sometimes you want to put two, three, or four blank lines. Another trick that seems to work is to inject nbsp; between the BRs, eg: single spaceBRsingle space BRnbsp;BR double spaceBRnbsp;BRdouble space BRnbsp;BRnbsp;BR triple spaceBRnbsp;BRnbsp;BRtriple space It'd be good if we could fix adjacent BR's though. I recall our html parser's source being a bit tricky to grok, but I think I worked on a small part of it once.. will see if I can figure this one out. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
On 04/04/13 09:44, Manolo Gouy wrote:
It'd be good if we could fix adjacent BR's though.
I recall our html parser's source being a bit tricky to grok,
but I think I worked on a small part of it once.. will see if
I can figure this one out.
I've seen that commenting out line 657 of file src/Fl_Help_View.cxx
seems to fix this problem. But does this have other negative effects?
Comment out the 'hh = 0;' line? Interesting:
else if (strcasecmp(buf, BR) == 0)
{
if (line 31)
line ++;
xx = block-line[line];
yy += hh;
hh = 0; // -- COMMENT THIS OUT
}
That does seem to allow multiple BRs to work.
But also seems to badly affect the document height calculations
such that the scrollbar doesn't let one reach the bottom of the
document.
For instance:
#include FL/Fl_Help_Dialog.H
int main() {
Fl_Help_Dialog *help = new Fl_Help_Dialog();
help-value(single aaabrsingle rsingle ccc
brbrdouble dddbrbrdouble eeebrbrdouble fff
brbrbrtriple gggbrbrbrtriple hhhbrbrbrtriple
iii
brbrbrbrquad jjjbrbrbrbrquad
kkkbrbrbrbrquad lll
brEND);
help-show();
return(Fl::run());
return (0);
}
With 657 left alone, one can view the above document up to the last
line (END)
using the scrollbar.
But with 657 commented out, the document becomes larger (due to the
extra lines
the working BR's now do), but the bottom lines are cut off in the
window,
and there's no scrollbar. One can enlarge the window vertically to see
the missing
lines.
Perhaps block-h needs to be adjusted for this to work correctly.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
On 04/04/13 14:32, Greg Ercolano wrote:
On 04/04/13 09:44, Manolo Gouy wrote:
I've seen that commenting out line 657 of file src/Fl_Help_View.cxx
seems to fix this problem. But does this have other negative effects?
[..]
That does seem to allow multiple BRs to work.
But also seems to badly affect the document height calculations
such that the scrollbar doesn't let one reach the bottom of the
document.
[..]
Perhaps block-h needs to be adjusted for this to work correctly.
OK, looks like to solve the scrollbar issue, one has to comment out
the corresponding hh = 0; line in the Fl_Help_View::format() function.
So I think together these two changes work a bit better (still not sure
if there are other negative effects):
_
--- Fl_Help_View.cxx(revision 9857)
+++ Fl_Help_View.cxx(working copy)
@@ -654,7 +654,7 @@
line ++;
xx = block-line[line];
yy += hh;
- hh = 0;
+ //hh = 0;
}
else if (strcasecmp(buf, HR) == 0)
{
@@ -1298,7 +1298,7 @@
xx = block-x;
block-h += hh;
yy += hh;
- hh = 0;
+ //hh = 0;
}
else if (strcasecmp(buf, CENTER) == 0 ||
strcasecmp(buf, P) == 0 ||
_
It looks like Help_View::format() and Help_View::draw() methods
depend on each other's code to be symmetrical.
I usually find code like this hard to maintain if managed in separate
functions, because it's too easy for the code to get out of sync.
I usually try to keep symmetrical code designs such that each block
of code is kept close together, so other programmers can clearly
see modifying one code block affects the other, eg:
void HtmlClass::Handle_BR(..) {
if (formatting) {
..code to handle BR formatting..
} else {
..code to handle BR drawing..
}
}
I've had to do this sort of thing with complex state machines
and receive/transmit code.. works well when the code blocks are short,
so it's easy to see matching code in a single page.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
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.general] best way to get an int from Fl_Menu_Item user data
On 04/03/13 08:44, marty moore wrote:
I notice that old examples used
int i = (int)v;
but that won't work with gcc-4.4.5
Right -- probably a precision loss error during the void* - int,
since sizeof(void*)==8 and sizeof(int)==4.
I think the best approach (in 1.3.x) is to use the new fl_intptr_t, e.g.
int i = fl_intptr_t(v);
Or, you could just use a long instead of an int, but that might cause
trouble on non-64bit builds.. which is I think what fl_intptr_t tries
to solve. (See the definition in FL/Fl_Widget.H)
There is a long Fl_Widget::argument() method which would let you do:
void mycallback(widget* w, void* v) {
long li = w-argument();
[..]
..but again, I think you'd loose on a 32bit build when doing the
long-void* cast.
Which is why I think the fl_intptr_t is probably the best way to go.
While dicking around, of interest I found this also seems to evade
the precision loss error, not completely sure why:
void foo(Fl_Widget *w, void *v) {
int i = (int)(long)(v);
[..]
Should this be covered in a tutorial?
Probably -- I don't think fl_intptr_t is even documented yet
(it has a 'todo' signifier), but it's defined in Fl_Widget.H
and used in some of the examples, like test/tree.cxx.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] best way to get an int from Fl_Menu_Item user data
On 04/03/13 09:05, Ian MacArthur wrote:
void mycallback(widget* w, void* v) {
eop e = (eop) (atoi((char*)v));
What is it you are trying to do here?
Probably trying to sidestep the 'precision loss' error from the
newer compilers due to sizeof(void*) != sizeof(int).
Using a char* is sizeof() compatible with a void*.
This was kinda covered last year in STR #2813:
http://www.fltk.org/str.php?L2813
We might need to see your code.
Just tested with gcc 4.7.2 and that works fine...
Might be a 32bit compile?
I get the precision loss error when I build that example on 4.4.6 with
a 64bit box:
$ make foo2
Compiling foo2.cxx...
foo2.cxx: In function 'void cb_item1(Fl_Menu_*, void*)':
foo2.cxx:15: error: cast from 'void*' to 'int' loses precision
make: *** [foo2.o] Error 1
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] best way to get an int from Fl_Menu_Item user data
On 04/03/13 13:22, marty moore wrote: long i = (long)(w-argument()); compiles, but always results in '0'. Doesn't w point back to the Fl_Menu_Button that had the menu? Probably depends on if you're setting the callback for the widget, or the callback for the items. Each item can have its own callback and userdata. Also, the Menu widget itself can also have its own callback + userdata. (The latter is used for items that have no callback of their own, IIRC.) If you're setting the callback for the widget, then w-userdata() should have any user_data() you'd set. But if you're setting the item's individual callbacks, then to access that item's userdata, your callback would have to first find the last item picked (with 'mvalue()') and then access its user_data(), eg: const Fl_Menu_Item *item = w-mvalue(); // get last picked item long i = (long)item-user_data(); // get user data for that item ..or something like that. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
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.development] [RFE] STR #2942: Buttons keep the same color when clicked
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2942 Version: 1.3-feature Hmm, doesn't that patch take /away/ the current control an app has over the button pushed color via selection_color()? selection_color() can be changed by the app to control what color a button is when it's pressed, and the patch seems to comment that out and replace it with the fl_darker() algorithm. Seems like a step away from what we want. Perhaps Albrecht's comments are more to do specifically with the theme code not taking into account the current selection_color(), as opposed to Fl_Button's existing default draw code..? Link: http://www.fltk.org/str.php?L2942 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
OK, so since Fl_Tabs currently has no defined when() behavior, it seems we can define the behavior of the non-default values how we want, as long as the default behavior remains unchanged. Having looked exhaustively at similar widgets (Fl_Radio_Button Fl_Browser) to divine the when() flags intention I'd like to implement the following behavior which I think makes sense, to me at least: when() Flags | Mouse Behavior | Keyboard Behavior --|-|-- NEVER | change: no callback | change: no callback | no change: no callback | no change: N/A --|-|-- CHANGED| change: callback on PUSH, changed()=true| change: callback on PUSH, changed()=true | no change: no callback | no change: N/A --|-|-- NOT_CHANGED | change: no callback | change: no callback | no change: callback on PUSH, changed()=false| no change: N/A --|-|-- CHANGED + | change: callback on PUSH, changed()=true| change: callback on PUSH, changed()=true NOT_CHANGED | no change: callback on PUSH, changed()=false| no change: N/A --|-|-- RELEASE| change: callback on RELEASE, changed()=true | change: callback on RELEASE, changed()=true | no change: no callback | no change: N/A --|-|-- RELEASE + | change: callback on RELEASE, changed()=true | change: callback on RELEASE, changed()=true CHANGED| no change: no callback | no change: N/A --|-|-- RELEASE + | change: no callback | change: no callback NOT_CHANGED | no change: callback on RELEASE, changed()=false | no change: N/A --|-|-- RELEASE + | change: callback on RELEASE, changed()=true | change: callback on RELEASE, changed()=true CHANGED + | no change: callback on RELEASE, changed()=false | no change: N/A NOT_CHANGED | | +-- Notes on the above: N/A: Not Applicable.. there is no way to keyboard navigate the tabs without making a change. RELEASE: this has (and will continue to be) the default when() value of Fl_Tabs. This default behavior will remain the same. The above departs from the current behavior of Fl_Browser and Fl_Radio_Button in that the keyboard behavior for PUSH vs. RELEASE follows the same logic as the mouse. (In the other widgets, keyboard callbacks are always on RELEASE) You can compare the above to the current radio + browser behavior: http://seriss.com/people/erco/fltk/when-behavior-03-26-2013.html Looking for comments on the above suggestion for tab behavior, and possible problems if any adding this might cause. (I can think of none, other than apps that change when() for Fl_Tabs that would suddenly inherit the new behavior; to date, Fl_Tabs has totally ignored the value of when()) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
*correction* On 03/29/13 17:40, Greg Ercolano wrote: The above departs from the current behavior of Fl_Browser and Fl_Radio_Button in that the keyboard behavior for PUSH vs. RELEASE follows the same logic as the mouse. (In the other widgets, keyboard callbacks are always on *PUSH*) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
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
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
So here's a big table comparing the when() behavior of radio and browser, comparing mouse clicks and keyboard nav clicks: http://seriss.com/people/erco/fltk/when-behavior-03-26-2013.html Fixed that table up a bit to make it easier to read. Hit Reload to see the changes. During testing I noticed some inconsistencies with changed()'s value, so started adding that to the table too. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature Based on fl_measure(), I'd say symbol support isn't hard. The symbols simply scale to the current string height, whatever it is. So if it's a single line, it's exactly fl_height(). If it's multiple lines, it scales to the fl_height() x #lines. The new code I intend to replace fl_measure()'s with will probably be good reference for that. Perhaps I should make it a function that returns the (potentially two) symbol sizes. The symbol size calculations in fl_measure() appear to assume symbols are square, which makes computation easy. Apparently symbol scaling (e.g. @+9- and @-9-) doesn't affect fl_measure() calculations, so I guess it just over-draws or under-draws when the user supplies that in a string. Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature symbols simply scale to the current string height, whatever it is. I should add fltk's @ symbols are not really like characters, they're more like graphics that fill the left and right margins. See this screenshot, esp. see the last example for the behavior of @ symbols in a multiline string: http://www.fltk.org/strfiles/2940/symbol-examples.png I never knew it worked that way; want to add that to the docs, which is what STR# 2940 covers. Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] fltk2.0.x-alpha-r9296 missing
On 03/26/13 16:48, Gonzalo Garramuno wrote: fltk-2 is, as you know, deprecated, and no one is available to maintain nor= fix it, so we can't really go on distributing it, until it gets fixed... Sure you can distribute it. It is there in the main page, what version to download. I don't know anything about 2.x, but indeed it looks like the tar balls are no longer in the download section.. don't know why. You should be able to still access 2.x from SVN; see the instructions under Subversion Access on the downloads page, eg: svn co http://svn.easysw.com/public/fltk/fltk/trunk fltk-2.0 I just checked it out; the last commit was on Mar 2012. Seems to build OK for me, on centos 5.6 at least. You mentioned the trunk doesn't build.. try a fresh checkout. If that doesn't work, what platform and what errors? Not sure I or anyone can advise, all I know is all active alpha dev on 2.x has been redirected to 3.x ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature Would be nice if an alternate version of fl_text_extents() were available that could handle crlfs in the string. Probably wouldn't be too hard; just need to break the one string into separate lines, then run the existing fl_text_extents() on each line. The tricky part would be to take into account FL_ALIGN_* flags.. Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): supportmultiple lines
On 03/27/13 11:41, chris wrote:
Hm, doesn't fl_measure() do all this already?
No, fl_measure() measures typographical area,
whereas fl_text_extents() measures the 'inking area'.
These are very different.
See the test/unittests program, text rendering test for a comparison
of the two functions (red vs green boxes)
In particular how the two functions calculate differently the bounding
region
for the characters ('), (-), and (_); fl_measure() returns the x,y and
height
for those characters, whereas fl_text_extents() does not.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): supportmultiplelines
*Correction*
In particular how the two functions calculate differently the bounding
region
for the characters ('), (-), and (_); fl_measure() returns the *SAME*
x,y and height
for those characters, whereas fl_text_extents() does not.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature @Ian, can't blame you -- impressed you took on fl_text_extents() at all.. big job, multiple platforms! But isn't the multiline issue simpler? Perhaps I'm missing something, but I would think the hard work has been done already.. The case of multiple lines, a three line example might be: First line Middle line Last line Forgetting alignment for now, and assuming first and last lines aren't blank (can be determined with fl_text_extent() to see if there's no inking area) and we want the dx/dy/w/h extents of this multiline string, wouldn't the overall 'h' of all three lines be the sum of FH+MH+LH, where: FH = fl_height()-dy of First line MH = fl_height() LH = dy of Last line e.g: _ _ dy | ## ### | | # ### # # | | # ### # | FH| fl_height() # ### # | | # ## # ## # | | # ### # | | . -- baseline __|___|__ | | ## # # | | ## ## # # # # # # # | | # ## # # # # # # # ### | MH| fl_height()) ## # # # # # # # | | ## # # # # # # # | | ## # | | . -- baseline|___|__ | | # ## # | | ## # # # | LH| # ## # | (dy of last) | fl_height() # ## # # | | # ## ## # | | ## ## # __|___| . -- baseline __|__ And this would of course extend to any number of middle lines. The trick would be to watch out for leading and trailing blank lines, but these could be detected by the existing fl_text_extent() on each line to detect the first and last inked lines, and adjust dy and h. What I figure gets tricky is the mixture of the FL_ALIGN_* flags which affect horiz + vertical orientation (INSIDE, OUTSIDE) as well as the origin of each line (CENTER). Tabs might be another issue, not sure. But I guess all this nothing the multiline fl_draw() doesn't already do to calculate text alignment, and you've already done the hard work to calculate font inking sizes. Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
On 03/25/13 22:51, Greg Ercolano wrote:
On 03/25/13 19:37, Greg Ercolano wrote:
With radio buttons, the behavior is:
[..]
Actually, some elaboration; tests revealed a subtlety I wasn't aware of:
[..]
Oh, and here's a test program (below) I was using to check when() behavior
for Fl_Radio_Button and Fl_Tabs.
(Since Fl_Tabs don't support when() yet, only the radio buttons are worth
using)
When you run the app, change the 'when()' chooser to apply that setting
to the radio buttons and tabs. Then click the radio buttons to see the
behavior
of the callback messages in the terminal, ie. clicking the same button more
than once, etc.
The tests I noted previously were all with the mouse buttons only.
Keyboard nav clicks is a whole other story (e.g. with spacebar or button
shortcuts to trigger radio buttons); callbacks were only ever invoked on
key-down events, and the when() flag behavior seems broken a bit:
WHEN FLAG BEHAVIOR OF RADIO BUTTONS
---
K1) NEVER -- keypress *never* invokes callback (OK)
K2) CHANGED -- keypress invokes callback on PUSH only if
changed (OK)
K3) NOT_CHANGED -- keypress *never* invokes callback (BAD?)
K4) RELEASE -- keypress invokes callback on PUSH *whether
changed or not* (BAD)
K5) CHANGED+NOT_CHANGED -- keypress invokes callback on PUSH *only if
changed* (BAD)
K6) RELEASE+CHANGED -- keypress causes *two callbacks on PUSH* if
changed, *once on no change* (BAD)
K7) RELEASE+NOT_CHANGED -- keypress causes callback on PUSH *whether
changed or not* (BAD?)
Kind of an odd mix of behaviors for the keyboard. Seems like NOT_CHANGED is
ignored
(The K2 + K5 behavior are the same, and K4 + K7 are the same). The presence
of
RELEASE seems to cause NOT_CHANGED behavior. Weird. This should maybe be
'fixed'
if we can agree on the right behavior.
_
#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
// Test when() behavior of tabs and radio buttons
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;
void Tabs_CB(Fl_Widget*w,void*) {
printf(TABS Callback, changed()=%d\n, w-changed());
}
void Radio_CB(Fl_Widget*w,void*) {
printf(RADIO Callback, changed()=%d\n, 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;
// 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);
printf(WHEN IS NOW %d (%s)\n, when, s);
}
int main(int argc, char *argv[]) {
Fl_Window *win = new Fl_Window(500,200,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
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
On 03/26/13 01:54, MacArthur, Ian (Selex ES, UK) wrote: Actually, some elaboration; tests revealed a subtlety I wasn't aware of: Huh; that's not quite what I expected, either. Though, now I think of it, I'm not sure what I *did* expect the behaviour to be. I only rarely use the when options, so had (at best) a vague notion of how they interacted, Ya, ditto. I wonder if it is worth poking at a few non-radio buttons and see if that is the same or whether some of these behaviours are peculiar to the radio-button case? Good idea; Fl_Browser is the only one I can think of that has multiple states that are similar to radio buttons. I can't use Fl_Tree or Fl_Table as examples, as I'm working on those.. Overall, radio and browsers are similar when it comes to mouse clicks, though there are some oddball behaviors. The keyboard behavior is different; the browser is more consistent with what I'd expect, but has some odd behavior too. So here's a big table comparing the when() behavior of radio and browser, comparing mouse clicks and keyboard nav clicks: http://seriss.com/people/erco/fltk/when-behavior-03-26-2013.html RED indicates behavior I think is *wrong and should be fixed*. BLUE indicates behavior I thought *odd* but maybe shouldn't be fixed, not sure. Hover over the colored text to see tooltips for what I think the behavior *should* be. PS. Making that table made me dizzy. PPS. One consistently asymmetrical behavior I notice with mouse clicks in both radio and browser that might be intentional (though I can't think why offhand): WHEN_CHANGED -- callback invoked on *PUSH* WHEN_NOT_CHANGED -- callback invoked on *RELEASE* Not sure why both aren't on the same stroke, as I would think both would work on PUSH unless amended by WHEN_RELEASE.. though maybe that's not how WHEN_RELEASE is supposed to work, and perhaps there's a reason for this during odd things such as DRAGGING. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
On 03/26/13 10:47, Greg Ercolano wrote:
I wonder if it is worth poking at a few non-radio buttons
and see if that is the same or whether some of these behaviours
are peculiar to the radio-button case?
Good idea; Fl_Browser is the only one I can think of that has
multiple states that are similar to radio buttons.
[..]
So here's a big table comparing the when() behavior..
http://seriss.com/people/erco/fltk/when-behavior-03-26-2013.html
Here's the test program used to generate that table.
I'm still fleshing out the data for that table; I keep finding new
boundary cases that have to be documented separately (eg. behavior of clicks
on the empty area of browser), which is why there's now two tables
at the above link:
#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,200,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
[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.development] FLTK '@' symbols question
Question: I want to verify that '@' symbols in labels (eg. @-) are only allowed at either *the very beginning* or *very end* of a string, or at both ends, and nothing else (ie. not in the middle of a string, or mixed into multiple lines). Another interesting thing about symbols I didn't know about @ symbols in labels, and I don't think is documented: The more lines in the string, the larger the symbol will be; the symbol is scaled to the size of all lines, and centered. Here comes some examples that use ascii art (view in a fixed width font!) If the label string is: @ Aaa\nBbb @ You'll get: /| Aaa |\ \| Bbb |/ ..and if the string has more lines, e.g. @ Aaa\nBbb\nCcc\nDdd @ ..then you'll get larger arrow symbols matching the height of all the lines: /| Aaa |\ / | Bbb | \ \ | Ccc | / \| Ddd |/ ..instead of what I was *expecting*, which would have been: | Aaa Bbb Ccc Ddd | This behavior of symbols automatically centering + scaling should really be documented too. I had no idea symbols worked this way until I looked closely at the side effects of fl_measure's code. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
