Re: [fltk.bugs] [MOD] STR #2809: Inconsistent events sent when pressing and releasing multiple keys on X11.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2809 Version: 2.0-current Fix Version: 2.0-current (r9296) Fixed in Subversion repository. Thanks for the patch! Link: http://www.fltk.org/str.php?L2809 Version: 2.0-current Fix Version: 2.0-current (r9296) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2809: Inconsistent events sent when pressing and releasing multiple keys on X11.
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2809 Version: 2.0-current Fix Version: 2.0-current (r9296) Link: http://www.fltk.org/str.php?L2809 Version: 2.0-current Fix Version: 2.0-current (r9296) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2784: Relative paths should always be computed from getcwd, not PWD
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2784 Version: 2.0-current Fix Version: 2.0-current (r9194) So I did a bit of research and it turns out you're right -- this was probably a holdover from someone's machine where they couldn't use getcwd() for whatever reason. I committed a slightly modified version of your patch; one that falls back on PWD iff getcwd() returns NULL (which it only does under 3 (relatively rare) conditions). Thanks! Link: http://www.fltk.org/str.php?L2784 Version: 2.0-current Fix Version: 2.0-current (r9194) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2760: fltk-2: FileChooser2.cxx anomaly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2760 Version: 2.0-current What system are you testing this on? On my Ubuntu 10.10 system, selecting coucou.xpm, then double clicking .. takes me up a directory - exactly as I expect. In any case, adding the selected directory to the filechooser string (before the (existing) file that has been selected) was a design decision introduced in 8508; it more closely mimics the win32 FileChooser this way (as this is what it does). Note this is different to GNOME's FileChooser. If you *really* need to do away with this functionality, commenting out lines 597 to 601 (inclusive) in src/FileChooser2.cxx will solve your issue, however I do remember testing this on a WinXP platform earlier this year (when I made these commits). Could perhaps one of the other Devs try to confirm this? Link: http://www.fltk.org/str.php?L2760 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2760: fltk-2: FileChooser2.cxx anomaly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2760 Version: 2.0-current Also, I should add, the issue you're describing isn't specific to .. - any directory you select will be added to the filename string so if you're having an issue with .. you'll end up having an issue with any directory you click on.. Link: http://www.fltk.org/str.php?L2760 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2760: fltk-2: FileChooser2.cxx anomaly
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2760 Version: 2.0-current Ah, okay. I see what you mean now. Perhaps you might need to avoid the return statement you have with if (!filename_exists(...))? As I mentioned earlier, lines 597 to 601 in src/FileChooser2.cxx actually take care of a specific case where the entered name does not actually exist. This was basically done for consistency with WIN32 - if a user types in some file name.cxx, the traversal across directories does *not* modify the user's entered some file name.cxx. It also has the side effect that if a user selects a file that exists and then traverses elsewhere (not just to the parent directory) then this filename is retained. To this end, you'll end up having a problem with all directories, not just .., which is why I suggested commenting out lines 597 to 601 (rather than your patch, which only takes care of one special case). I probably won't end up commenting this out in the repository; it's been there for a little while now and this is the only complaint I've had about it (and I imagine a fair few users pitch to win32), but hopefully this has all helped. Link: http://www.fltk.org/str.php?L2760 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2760: fltk-2: FileChooser2.cxx anomaly
[STR Closed w/Resolution]
Link: http://www.fltk.org/str.php?L2760
Version: 2.0-current
Fix Version: None
Yeah, bracket the code with an else:
if( !filename_exist(cs))
{
alert(%s\n%s, FILE_NOT_FOUND_s,cs);
return;
}
else
{
/* blah */
}
To be honest, you probably don't even need the if statement - unless
you're going to use the alert() as some form of log.
In any case, I'm going to close this STR. Feel free to continue this
discussion over at fltk.general if you need any help :)
Link: http://www.fltk.org/str.php?L2760
Version: 2.0-current
Fix Version: None
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2743: fltk-3 box-image() anomaly
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2743 Version: 3.0 Fix Version: None Closed as per the OPs request in #2744, indicating that no bug actually exists. Hopefully this goes towards helping with #2723! Link: http://www.fltk.org/str.php?L2743 Version: 3.0 Fix Version: None ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2744: Re: fltk-3 box-image() anomaly
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2744 Version: 3.0 Fix Version: None Marked as duplicate of 2743 and closed as requested. Link: http://www.fltk.org/str.php?L2744 Version: 3.0 Fix Version: None ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2239: with --disable-gl, glut/glpuzzle.cxx tries to build anyway and fails
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2239 Version: 2.0-current Wow, I hadn't even seen this STR. Greg, does this still happen? I wouldn't be surprised, but if it does it's an easy fix. Darius, it looks like you're missing the -dev versions of the libraries; you'll most likely need these too. Assuming you have and are intending to build with openGL, you'll need the development versions of these librarie (i.e. libglut3-dev, freeglut3-dev, etc) Link: http://www.fltk.org/str.php?L2239 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2698: ENTER and LEAVE events are always generated by mouse movement
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2698 Version: 2.0-current What sort of highlighting are you attempting? fltk::drawflags() has the HIGHLIGHT flag, which allows you to work all sorts of magic from inside your (overridden) draw() function. The damage(DAMAGE_HIGHLIGHT); function call also forces your widget to redraw its highlight. With reference to the test/subwindow.cxx example, Both ENTER and LEAVE events are sent, however they're actually sent in the order LEAVE / ENTER. This means you should still be able to have highlighting on mouse over working fine - assuming you highlight on ENTER. FWIW, if you add theme(xp_theme); as the first line of main() to test/button.cxx, you should see the attempt at an XP theme being enabled. This should also be a fairly decent test of the highlight functionality on your machine; the Button's all have a separate image for highlighting (which is apparent on my machine, anyway). If the test/button.cxx example doesn't highlight for you, then I might have to dig a little deeper, but ATPIT what you've described isn't unexpected. Link: http://www.fltk.org/str.php?L2698 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2694: FileChooser2.cxx Preferences destructor crash(free memory error).
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current Fix Version: None Closed at the OP's request. Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current Fix Version: None ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2694: FileChooser2.cxx Preferences destructor crash(free memory error).
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current Hey spoony, Any news on this? If you're able to generate a test case, I'd love to get this fixed by Friday's snapshot (if it's possible, of course)! Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2694: FileChooser2.cxx Preferences destructor crash(free memory error).
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current Alright, in which case I'll close this without resolution. If it crops up again, feel free to resubmit a bug, or if you can concoct a test case that'd also be great. Before I close this, would you mind posting the output of (assuming you're on linux) objdump -tC binary_name | grep -i pref* (external quotes for clarity)? It might help me get one last look at what's going on here. Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2694: FileChooser2.cxx Preferences destructor crash(free memory error).
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current Hey spoony, Do you have a minimal test case for this? I've bashed the file chooser around fairly extensively and never come across such an issue, so a test case to help me chase down when this occurs would be good! Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2694: FileChooser2.cxx Preferences destructor crash(free memory error).
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current Just to clarify: Preferences makes its own local copy of the string you pass to it -- sort of. It uses the passed strings to create a proper directory for the preferences file, as well as running newstring() on all the passed strings, which means it's perfectly valid to be deleting these strings. This is why I'm looking for a test case - you're either doing something strange with your code or there's an issue that you're not seeing here, but in any case it's definitely not the Preferences code attempting to free a constant string. Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2694: FileChooser2.cxx Preferences destructor crash(free memory error).
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current Hmm. This *is* interesting. What linker do you use? (ld is smart enough to (usually) strip functions and items that aren't used from the binary) Is there a way for you to strip out the code from your application library and turn it into a test case here? I'd really like to be able to work out what the heck is happening here. Even from within node there should be no segfault. The line that is crashing (according to your backtrace) is guarded by an if (to check if the pointer exists), so the array call entry[i] should be fine. My only theory is that somehow i is going out of bounds (perhaps somewhere the nEntry counter isn't being decremented?) and then dereferencing entry[i] is what causes the crash. Link: http://www.fltk.org/str.php?L2694 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Crashes on double click on browser
Hi Stuart, The application works fine when I use add() to fill the browser. Because I can have up to 10,000 rows I thought I would try overriding list. It is a multiselect browser, so I wrote a class overridging children, child and set-flags (using the documenation in StringHierarchy as a template). I sort and do functions such as select all, invert selection etc on the data class and it shows fine in the browser. However when I double clikc a row it segfaults. I have put event_clicks(0) into my overwritten and this nearly always stops the crash. However I lose my double click action. I have tried setting a double click block before setting event_clicks(o) and acting on the flag in the call back but then it does respond until I go to a new (and thus precipitate a new call back fro it to act). I supposed I could a function in my overriden class but this is becoming pretty ugly and spaghetti like. Even more worrying while the event_clicks(0) stuff stops most crashes I still get occasional crahses and have no idea why. It seems that events must be being calling on zero'd widgets or something. Any help would be appreciated. Setting event_clicks(0) won't solve all these problems, I don't think. 2.0 can triple-click, so occasionally it might interpret your clicks as a series of tripleclicks, which will set event_clicks_ to 2 (and thus double click). However, it sounds like your problem is most likely in your overridden class. Could you please post a minimal compilable example that exhibits the problem (preferably without the event_clicks() kludges - so we can try to get this code as nice as it should be!), and I'll see what I can do? Regards, Ben ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1784: scrolling in ScrollGroup does not take into account labels
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L1784 Version: 2.0-current Fix Version: 2.0-current Yeah, I attempted to follow up the clipping idea earlier and realised that the clipping region was static; it's simply the viewable rectangle inside ScrollGroup. I do agree that the padding functions should definitely be added, and I'll turn this into an RFE (eventually) to make sure I do this. In regards to your point about the displayable region, would the child widget's bounding box not start at (50, 50) in your [scroll2.cxx] example, rather than (0, 0)? This is probably the crux of this discussion; I believe it should start at (50, 50) because that's where you've positioned it to begin with. In terms of the image example, you could set the box to start at (0, 0) and extend to the width and height of the image. Then just use the scrollTo() method to set the initial viewing point to the centre of the image. You shouldn't need to start it at negative coordinates. Link: http://www.fltk.org/str.php?L1784 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1784: scrolling in ScrollGroup does not take into account labels
For the moment, if a user wants colours, etc, one can always revert the
style.
How? As an only occasional FLTK 2 user I don't know how to do that.
Above main, declare bool mytheme() { fltk::reset_theme(); }, then as the
first line of main add theme(mytheme);.
FLTK will work the rest out from there. You can probably call reset_theme()
somewhere else in the code, but then you'd also have to call reload_theme() and
make sure you had called flush() before that.
I do intend to add proper transparency to the images as some point,
as well as segregation the #includes amongst other things, but I really
only forced the XP theme to be the default in an effort to get some
feedback.
Hmm, very little feedback so far, AFAICT. Maybe there are not so many
users that update their FLTK 2 versions frequently...
Little?! Where! :-P
Yeah, there have been surprisingly fewer than I expected.
But, please take care that such incompatible changes don't make more
users drop FLTK, because they say Hey, what are they doing? Now they
broke my working software (again). Rumors say that many FLTK2 users
went away from FLTK2 because of lots of incompatible changes in the
past.
In my head, it worked as so:
Make the theme the default for 2 or 3 weeks. I'd then get feedback and fix what
needed to be fixed, and then move the xp theme from the default (fltk_theme())
to it's own xp_theme(), where a user could then call theme(xp_theme) at the top
of their main function. I'll revert it in the near future, in any case, and
provide it as a xp_theme().
Obviously, I need far more forethought next time!
Ben
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1784: scrolling in ScrollGroup does not take into account labels
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L1784 Version: 2.0-current Fix Version: 2.0-current If you look at line 126 in your scroll2.cxx (and most likely the same line in test/scroll.cxx), the first button will be positioned at (50, 20) with length (75, 25). When the ScrollGroup scrolls over, it _doesn't_ honour this (50, 20) starting point; it shifts it to (0, 0). This isn't so much to do with the labels as it is with the actual positioning of elements within a ScrollGroup; whether or not I use ALIGN_INSIDE on the label or not, it will still shift this if, for whatever reason, I deem there needs to be padding to the left or above the boxes. I claim that this behaviour is buggy, even though it's documented; it shouldn't really be up to FLTK to decide that something is or isn't where I originally put it. Plus, it does look like it was originally intended to do drawing properly anyway; lines 121-123 suggest this. It should simply be a matter of working out where the original placement was and *properly* setting the clip region, rather than overwriting it. Link: http://www.fltk.org/str.php?L1784 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1784: scrolling in ScrollGroup does not take into account labels
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1784 Version: 2.0-current Fix Version: 2.0-current This sounds like it should never happen; as things are scrolled redraw() will be called, but redraw() should also redraw labels. Since the label is drawn over the top of the button, and the button is redrawn, the label will also be damaged (and thus redrawn). I can't reproduce this on my system, and I'm guessing there were a few updates between r5940 and now (r8662). As such, I'm going to close this STR on the assumption that the issue has been fixed; please refile a new one if this bug does in fact still exist. Link: http://www.fltk.org/str.php?L1784 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1998: test/keyboard.cxx example incorrectly draws some keys
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L1998 Version: 2.0-current Fix Version: 2.0-current (r8663) Fixed (sort of) in Subversion repository. The problem here is _only_ with you ./configure with --enbale-cairo; clipping with Cairo is absolutely utterly stuffed ATPIT (and will probably remain this way for a the next 7 or 8 months at least). I won't fix the Cairo issue and I'll still close this STR but there are multiple others regarding clipping and Cairo, so never fear! There was another problem, however, where UTF8 bytes would compare equal, and thus cause the text display to update beyond the first character (even though a UTF8 char could potentially be multibyte). This is now fixed. Link: http://www.fltk.org/str.php?L1998 Version: 2.0-current Fix Version: 2.0-current (r8663) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1998: test/keyboard.cxx example incorrectly draws some keys
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1998 Version: 2.0-current Fix Version: 2.0-current (r8663) Link: http://www.fltk.org/str.php?L1998 Version: 2.0-current Fix Version: 2.0-current (r8663) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1708: Menu accelerators do not work
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1708 Version: 2.0-current Fix Version: 2.0-current (r5910) Fixed in Subversion repository. Bill seemingly fixed this a while ago, so I'll close this now. Everything works as expected - there's no real simple way to trigger a shortcut in a nested menu, and this is pretty counterintuitive anyway. Link: http://www.fltk.org/str.php?L1708 Version: 2.0-current Fix Version: 2.0-current (r5910) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1775: fltk::Group's style is not named
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L1775 Version: 2.0-feature Fix Version: Will Not Fix There's no need for fltk::Group's stile to be named, and *every* style can be created without access to fltk::Group::default_style. All that group's style does is set color_ to GRAY75 and box_ to NO_BOX. Since a group *doesn't do anything specifically*, there's no need to override any of these. The default style in src/Style.cxx should get you going here. In the meantime, because this doesn't actually need to occur, I'm taking the liberty of closing this STR. Link: http://www.fltk.org/str.php?L1775 Version: 2.0-feature Fix Version: Will Not Fix ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2364: The Trouble with 2.0x themes.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR Active]
Link: http://www.fltk.org/str.php?L2364
Version: 2.0-current
Alright, so, here are my thoughts:
Themes aren't broken!
The new WinXP theme (thanks, Sal!) isn't broken - in fact, it works
exactly as I hope it does - and themes don't seem to have a circular
dependence like you say they do. Assuming you're talking about this:
Theme fltk::theme_ = fltk_theme;
This isn't the same thing as having two functions rely on one another.
Instead, fltk::theme_ is a pointer to a boolean function taking no
arguments, typedef'd to the name Theme. This pointer is set to fltk_theme,
so that when it's dereferenced it calls the function fltk_theme.
A user can then call theme(my_theme), which sets fltk::theme_ to my_theme.
This allows the user to supply a billion of their own functions and have
the user select them from, say, a list. This seems to be working as it
should (take the current XP theme in any of your programs, declare
bool my_theme(){
return fltk::reset_theme();
}
/*...*/
int main(){
fltk::theme(my_theme);
if (fltk::theme() == my_theme) {
printf(Working!\n);
}
/* ... */
}
and watch it go!
On top of that, the extern C linkage allows a user to override
fltk_theme in their own code (by naming a function exactly the same) with
their own 'default' theme.
So, with all this in mind:
This doesn't seem to be an issue as you thought it was. Is there any
reason for me to keep this open?
Link: http://www.fltk.org/str.php?L2364
Version: 2.0-current
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2364: The Trouble with 2.0x themes.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current It should work on every compiler though (for the record, I run linux+gcc normally anyway) because it's standard-defined behaviour. The function pointers are a bit tricky, sure, but they're valid and the overloaded functions work specifically because they're 'extern C' and thus name mangling doesn't get to them the way it does with C++ mangling. If you want to test it, use the latest svn revision; the weekly snapshot will be utter garbage as I was in too much of a rush for that! Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2364: The Trouble with 2.0x themes.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current Fixed in Subversion repository. Closing on the confirmation of rainbowsally. Beauty, one STR down, one billion less one to go. Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2364: The Trouble with 2.0x themes.
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current Fix Version: 2.0-current (r8638) Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current Fix Version: 2.0-current (r8638) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2611: Multiple InputBrowsers will cause hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2611 Version: 2.0-current Actually, your fix and the bug you're talking about doesn't explain the behaviour we're seeing. A modal window (or widget) eats all the incoming events, but *can also receive them*. What's happening here is that the window/widget is locking itself in an infinite loop, and thus is unable to receive anything (which is why it exhibits the behaviour you're describing). I probably misspoke - when I said FLTK event loop I didn't mean the capturing of X events, etc. It made sense in my head. :-P Now, of course, once the above behaviour is fixed the *next* item on the agenda would be your fix, as you're right - the InputBrowser would clearly not gain focus and modality. I really need to find some time to do a bit of heavy developing, but I'll be snowed under for the next couple of weeks. In the meantime, I'll commit your fix, because I suppose it does solve the issue, but doesn't triage the underlying problem. I think this problem was specific to X11, which means that there's (most likely) a simple fix somewhere in src/x11/run.cxx, but I'll have to follow this up. Thanks for the bug report and the fix. I hate triaging bugs that lock up X servers, personally!. Link: http://www.fltk.org/str.php?L2611 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2611: Multiple InputBrowsers will cause hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2611
Version: 2.0-current
So it might just be me, but I can't cause a hang with two input browsers.
Could you post a minimal example that exemplifies the problem? I've
attached my own, and aside from the obviously poorly designed UI I don't
see any issues with it - it runs like I would expect.
Link: http://www.fltk.org/str.php?L2611
Version: 2.0-current#include fltk/InputBrowser.h
#include fltk/Window.h
#include fltk/run.h
using namespace fltk;
int main(){
Window win(1000, 150, TEST);
win.begin();
InputBrowser first(20, 10, 400, 100, 1:);
InputBrowser second(520, 10, 400, 100, 2:);
win.end();
win.show();
run();
return 0;
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2611: Multiple InputBrowsers will cause hang
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2611 Version: 2.0-current Ah, okay. I've seen this before - a similar things happens in FLUID when creating a TabGroup, or something similar (it's in the STR system). I'll take a look, but the reason X is hanging is because FLTK is causing/eating an infinite loop of events, or something like that. rainbowsally had a simple method to avoid this bug (though it wasn't a fix). A simple usleep(1) forced FLTK to sleep intermittently and thus would procrastinate the problem effectively. Whilst your fix most likely does the job - and thanks for putting in the work to find and fix this - what I'll do for the time being is investigate this further. The fact that it appears in two different places suggests - to me - that we're doing something stupid, and thus whilst your fix is adequate there must be a slightly smarter one somewhere. Link: http://www.fltk.org/str.php?L2611 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2602: fltk::file_chooser has relative=1 by default in params == fluid is not able to detect the correct path of project file.
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2602 Version: 2.0-current Fix Version: 2.0-current (r8574) Closed. Link: http://www.fltk.org/str.php?L2602 Version: 2.0-current Fix Version: 2.0-current (r8574) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2602: fltk::file_chooser has relative=1 by default in params == fluid is not able to detect the correct path of project file.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2602 Version: 2.0-current Fix Version: 2.0-current (r8574) Fixed in Subversion repository. Whoops, I didn't even consider that this function was used inside fluid - it was so badly broken when I hacked into it that this completely slipped my mind. Apologies for that. Link: http://www.fltk.org/str.php?L2602 Version: 2.0-current Fix Version: 2.0-current (r8574) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2527: right shift key generates left shift key event in keyboard demo
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2527 Version: 2.0-current Fix Version: 2.0-current (r8535) Link: http://www.fltk.org/str.php?L2527 Version: 2.0-current Fix Version: 2.0-current (r8535) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2527: right shift key generates left shift key event in keyboard demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2527 Version: 2.0-current Fix Version: 2.0-current (r8535) Fixed in Subversion repository. Albrecht, a similar fix may be able to be applied to 1.3. I can probably provide a patch if needed, otherwise I'll leave that up to you and I'll close this sometime on Monday. Link: http://www.fltk.org/str.php?L2527 Version: 2.0-current Fix Version: 2.0-current (r8535) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2364: The Trouble with 2.0x themes.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current You may need to re-tarball that file, because it errors out for me and this occurs, too: ben@delta:~/fltk-rs/FTL-Personal-2011-01-01/usr32/src$ find -name *.ui ben@delta:~/fltk-rs/FTL-Personal-2011-01-01/usr32/src$ Also, I haven't been having any trouble with the STR system Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2364: The Trouble with 2.0x themes.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current Sal, have you got code for your WinXP theme? I don't so much want the fltk/theme.cxx code more than the XP theme code. Your tarball in STR #2361 doesn't have compilable themes - time to get these buggers working again! Link: http://www.fltk.org/str.php?L2364 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2593: fltk 2.0 dll version will not compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2593 Version: 2.0-current So from a quick grep (note: nothing I say in this post has been tested under my vbox with MSVS2008. Thus, take everything with a grain of salt), I see that FL_SHARED hasn't been defined. If you want __declspec(dllimport) to work, you need to have FL_SHARED defined. This *may* fix your problem. However, it also may not. Let me know? If this doesn't solve the problem I'll fire up the vbox. Link: http://www.fltk.org/str.php?L2593 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2593: fltk 2.0 dll version will not compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2593 Version: 2.0-current Hmm, so at least the dlls build now. I don't suppose you have a short example that you could attach to this STR that I could then build? Given that the image dll builds (and I haven't modified the core dll), my first thought would be that this has to be a simple omission of linking commands - though I could have forgotten a FL_API somewhere Link: http://www.fltk.org/str.php?L2593 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2593: fltk 2.0 dll version will not compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2593 Version: 2.0-current Gah, stupid MSVS projects. Fix one thing, break 12. I'll try to have this fix in SVN before the next snapshot is created (~a few hours). I only need to remove and add a few files - FTR, static linking of fltk2_images.lib works at the moment. Thanks for the report. Link: http://www.fltk.org/str.php?L2593 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2593: fltk 2.0 dll version will not compile
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2593 Version: 2.0-current Alright, I've committed the new file to SVN. The snapshot should be built in about 3 hours, IIRC (it's set to some strange US timezone...), so after it's released let me know if this solves your problems (it solves the build problems here, but just in case :-)). I'll close this STR if it does. Link: http://www.fltk.org/str.php?L2593 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2591: Keyboard navigation appears to be backwards in mutli-button message boxes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2591 Version: 1.3-current Yeah, this was fixed in the latest revision of 2.0. It's caused by the message box buttons being drawn from right-to-left. Somewhere in the code in src/message.cxx (or the 1.3 equivalent) was this line: bx -= bw + BORDER_W. Essentially, that moved the next button to the *left* of where the current button was drawn - but FLTK thinks the child should be to the right. If there's been no fix by the time I get back home tonight, I'll see if I can contribute the 1.3 patch (or a starting point, anyway). Link: http://www.fltk.org/str.php?L2591 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1631: TextEditor missing stylebuffer()
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L1631 Version: 2.0-current Fix Version: Will Not Fix Link: http://www.fltk.org/str.php?L1631 Version: 2.0-current Fix Version: Will Not Fix ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] Segmentation fault in file_chooser example
Just compiled fltk-2.0.x-r8501, kubuntu 10.4 with kernel
2.6.32-29-generic (#58-Ubuntu SMP Fri Feb 11 19:00:09 UTC 2011)
and gcc 4.4.3 (i486-linux-gnu) and:
./configure --enable-shared --enable-debug
subsequently running test/file_chooser crashes with segmentation fault. Here's
a gdb postmortem:
matthews@skipjack:~/dance_v4/extensions/fltk-2.0.x-r8501/test$ gdb file_chooser
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or laterhttp://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from
/home/matthews/dance_v4/extensions/fltk-2.0.x-r8501/test/file_chooser...done.
(gdb) run
Starting program:
/home/matthews/dance_v4/extensions/fltk-2.0.x-r8501/test/file_chooser
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00196a4d in fltk::Symbol::measure (this=0x80d1830, w=@0xbfffeed8,
h=@0xbfffeed4) at ../fltk/Symbol.h:55
55void measure(int w, int h) const {_measure(w,h);}
(gdb) print w
$1 = (int) @0xbfffeed8: 22
(gdb) print h
$2 = (int) @0xbfffeed4: 22
(gdb) bt
#0 0x00196a4d in fltk::Symbol::measure (this=0x80d1830, w=@0xbfffeed8,
h=@0xbfffeed4) at ../fltk/Symbol.h:55
#1 0x0020938a in fltk::Widget::draw_label (this=0x80d1790, ir=...,
flags=262656) at Widget_draw.cxx:149
#2 0x0018a35a in fltk::Button::draw (this=0x80d1790, glyph_width=0) at
Button.cxx:243
#3 0x0018a3c4 in fltk::Button::draw (this=0x80d1790) at Button.cxx:253
#4 0x001a8ae0 in fltk::Group::draw_child (this=0x80d1630, w=...) at
Group.cxx:757
#5 0x001a8809 in fltk::Group::draw (this=0x80d1630) at Group.cxx:689
#6 0x0020a80f in fltk::Window::draw (this=0x80d1630) at Window.cxx:82
#7 0x001dd5cd in fltk::Window::flush (this=0x80d1630) at x11/run.cxx:2609
#8 0x001deb2a in fl_window_flush (window=0x80d1630) at run.cxx:659
#9 0x001debc3 in fltk::flush () at run.cxx:693
#10 0x001de7a7 in fltk::wait (time_to_wait=1.0002e+20) at run.cxx:488
#11 0x001de5a4 in fltk::run () at run.cxx:401
#12 0x0804b19f in main (argc=1, argv=0xb364) at file_chooser.cxx:349
(gdb) ^CQuit
(gdb)
___
Hmm, this is a tad strange. It seems to be crashing when going into
_measure(), not when actually doing anything
In any case, I don't get the same results on my system, using a clean
svn checkout or using -r8501, so I'm not quite sure what could be
causing this.
I do remember having the filechooser be completely unusable on my system
about 5 kernel's ago (it only happened on this system, which I do my
best to keep up-to-date with kernel releases, and was fixed at the next
release, so something might've been a little screwy there).
For the record, I'm running 2.6.35.26.
Do you have perhaps another system you can test this on?
Regards,
Ben
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1646: TextDisplay does not expose the stylebuffer publically.
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L1646 Version: 2.0-feature Fix Version: Will Not Fix Closed. Link: http://www.fltk.org/str.php?L1646 Version: 2.0-feature Fix Version: Will Not Fix ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1801: When compiling FLTK2 using MinGW/MSYS make fails.
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1801 Version: 2.0-current Fix Version: 2.0-current Fixed in Subversion repository. This looks like it was fixed a while ago. Closed. Link: http://www.fltk.org/str.php?L1801 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1699: Xlib errors
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1699 Version: 2.0-current Fix Version: 2.0-current I can't reproduce this bug on my system, and there doesn't look like any picture references in the current ansiwidget demo. As such, I'm closing this STR. Please re-file if the same bugs still exist. Link: http://www.fltk.org/str.php?L1699 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2554: fltk 3.0 not make on centos
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2554 Version: 2.0-feature Fix Version: None FLTK3.0 is more alpha than 2.0, and significant work on it will (most likely) be done after the 1.3 release. Until then, it is advised you use either of 1.3 or 2.0, as 3.0 is completely experimental. Closed. Link: http://www.fltk.org/str.php?L2554 Version: 2.0-feature Fix Version: None ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1646: TextDisplay does not expose the stylebuffer publically.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1646 Version: 2.0-feature Fix Version: 2.0-current Unless I get reason otherwise, I'm going to file this STR in the Will Not Fix section. My reasoning for this is as follows: Since the style buffer is in no way managed or modified by the user (instead, it's put in place by the developer) and is only set through the highlight_data() function, it should be sufficient enough that a developer is able to keep their own copies of their style buffer. Unlike a text buffer, which is modified every time the user enters a character, the style buffer is essentially static in that it doesn't change. This means that there should be no need for a style_buffer() function that lets you get/set the style buffer; just don't delete your program's copy! If anyone has a reason as to why this _should_ be implemented, fire away, otherwise I'll close this in two days time. Link: http://www.fltk.org/str.php?L1646 Version: 2.0-feature Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #2350: A bug in the bug report url.
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2350 Version: 2.0-current Fix Version: 2.0-current (r8500) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2350 Version: 2.0-current Fix Version: 2.0-current (r8500) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2359: cpu time sharing issues in v1 and v2 (solutions).
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2359 Version: 2.0-current RS, have you got an example where the queue misfires without your modification? The standard test/threads program runs fine Link: http://www.fltk.org/str.php?L2359 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2359: cpu time sharing issues in v1 and v2 (solutions).
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2359 Version: 2.0-current So the problem is that if this *is* a bug, the usleep(1) (or however many milli/micro seconds) isn't really a valid fix. On a kernel level, threading works properly. Which means there's some form of (surprise surprise) bug in the 2.0 code, currently. I'm just trying to see if/where this bug exists, for now. All I've got currently is that it exists _somewhere_ inside the lock code :P The other problem is that this bug is being found in a prime checker - and since the distribution of primes isn't quite linear, we can't really use when Max Prime: is updated as a valid checking mechanism. ... and now that I've written all that, this bug definitely exists. I can only see it when running *two* threading demos at once though, so it's probably slightly dependent on cpu stress. Damnit. Oh well, I'll add this to the todo list, right after I fix the last two FileChooser STRs. Link: http://www.fltk.org/str.php?L2359 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1961: readimage doesn't work with Image as current context
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1961 Version: 2.0-current Fix Version: 2.0-current (r6132) Fixed in Subversion repository. Seems TobiasFar fixed this a while ago. Clsoed. Link: http://www.fltk.org/str.php?L1961 Version: 2.0-current Fix Version: 2.0-current (r6132) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1963: fltk::use_system_file_chooser (bool=true) couse linker error on linux
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1963 Version: 2.0-current Fix Version: 2.0-current (r8492) Fixed in Subversion repository. Fixed - and on top of that, fltk::use_system_file_chooser also means fltk::file_chooser(...) works correctly (at least under Windows - somewhere down the bottom of my todo list is a complete rewrite of fltk2's Mac portions to make them native, and when I get around to that I'll fix file_chooser() there, too). Closed. Link: http://www.fltk.org/str.php?L1963 Version: 2.0-current Fix Version: 2.0-current (r8492) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [LOW] STR #1609: Add a method to Fl_File_Chooser or Fl to save the file chooser favorites
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1609 Version: 2.0-current Fix Version: 2.0-current (r8479) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L1609 Version: 2.0-current Fix Version: 2.0-current (r8479) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2211: FLTK crash at src/x11/Font_xlfd:538
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2211 Version: 2.0-current Fix Version: 2.0-current (r8477) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2211 Version: 2.0-current Fix Version: 2.0-current (r8477) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1580: Deselect all buttons in a radio group
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1580 Version: 2.0-current Fix Version: 2.0-current Fixed in Subversion repository. I can't reproduce this bug, so I'm going to assume it was fixed in an earlier revision. If it still exists, please re-submit a STR Link: http://www.fltk.org/str.php?L1580 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2579: Uable to compile under MS Windows with Visual Studio 2005
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2579 Version: 2.0-current This has been fixed in the latest SVN version - I updated the MSVS projects only slightly after the automatic tarball was generated. The compilation errors should be gone, but the warnings still exist IIRC. I don't know why this is and it seems to be a problem with MSVS (everything compiles cleanly on GCC / mingw). If you have any suggestions on how to remove the warnings, I'm all ears, otherwise I'll close this STR in a day or two as, in essence, the compilation errors have been solved. Link: http://www.fltk.org/str.php?L2579 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1396: Selecting multiple files with FileChooser class doesn't work correct
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1396 Version: 2.0-current Fix Version: 2.0-current I can't reproduce this bug with MSVS 8, WinXP and the latest 2.0 SVN checkout, so I'm going to assume this bug has already been fixed somewhere along the line - possibly even accidentally. Feel free to re-file this bug with more information if it still occurs. Link: http://www.fltk.org/str.php?L1396 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1790: Windows.fullscreen_off(...) don't work under linux
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1790 Version: 2.0-current Fix Version: 2.0-current I can't reproduce this on either of x86 or x86_64 systems running GNOME and X. As such, I'm closing this STR with the presumption that it has been solved. If this issue still exists, please submit a new STR. Link: http://www.fltk.org/str.php?L1790 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2571: File chooser crash
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2571 Version: 2.0-current Fix Version: 2.0-current (r8464) Fixed in Subversion repository. Thanks for the bug report and the line that caused the crash. Now if only all the STR's were as simple to fix as this one. Link: http://www.fltk.org/str.php?L2571 Version: 2.0-current Fix Version: 2.0-current (r8464) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2313: compiling src/filename_list.cxx fails because of HAVE_SCANDIR_POSIX
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2313 Version: 2.0-current Fix Version: 2.0-current (r8433) Urgh, the missing ) was as a result of re-typing it from r8434-8435. Apologies for that. In terms of complexity / double-testing, I'll fix this up tomorrow - I'll close the STR though, as this bug is now fixed and the rest is just janitorial work. Thanks! Link: http://www.fltk.org/str.php?L2313 Version: 2.0-current Fix Version: 2.0-current (r8433) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2313: compiling src/filename_list.cxx fails because of HAVE_SCANDIR_POSIX
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2313 Version: 2.0-current Fix Version: 2.0-current (r8433) Link: http://www.fltk.org/str.php?L2313 Version: 2.0-current Fix Version: 2.0-current (r8433) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2313: compiling src/filename_list.cxx fails because of HAVE_SCANDIR_POSIX
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2313 Version: 2.0-current So from what I was able to glean, in ~'98 Solaris _didn't_ have a scandir() implementation that didn't suck - it was part of the UCB lib which required strange linking and on top of that it was non standard, as well. http://www.unix.com/man-page/OpenSolaris/3c/scandir/ seems to suggest that OpenSolaris has had scandir as part of libc since about Solaris 10 (a few years ago now!) Thus, the next question is this: do we remove the Solaris force to fltk's scandir, thus assuming that it works, or do we undefine HAVE_SCANDIR_POSIX? Based on configure working out that Solaris' scandir is POSIX compliant, I'd be leaning towards the first option... Thoughts? Link: http://www.fltk.org/str.php?L2313 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2313: compiling src/filename_list.cxx fails because of HAVE_SCANDIR_POSIX
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2313 Version: 2.0-current I suppose that's a fair enough option. I might check that change in to 2.0 sometime soon - it's up to you to decide on 1.3/1.4s fate! :) Link: http://www.fltk.org/str.php?L2313 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2313: compiling src/filename_list.cxx fails because of HAVE_SCANDIR_POSIX
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2313 Version: 2.0-current Fix Version: 2.0-current (r8433) Fixed in Subversion repository. Albrecht, I'll leave this STR open for now - if you decide that configure.in needs to be changed in 1.3 or 1.4, feel free to move this STR from 2.0 to 1.3/1.4, modify the svn and close it as you see fit. Otherwise, I'll probably close this STR in 3 days time. Link: http://www.fltk.org/str.php?L2313 Version: 2.0-current Fix Version: 2.0-current (r8433) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2232: FLTK1/2 X11 keyboard handling broken if using a soft keyboard
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2232 Version: 2.0-current Fix Version: 2.0-current Fixed in Subversion repository. I'll close this STR on Matt's behalf - Matt, if you see any problems cropping up, feel free to re-open this, but otherwise this has been solved, from my own tests. Link: http://www.fltk.org/str.php?L2232 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2232: FLTK1/2 X11 keyboard handling broken if using a soft keyboard
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2232 Version: 2.0-current Fix Version: 2.0-current Link: http://www.fltk.org/str.php?L2232 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1596: can'y built library with certain configuration
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1596 Version: 2.0-current Fix Version: 2.0-current (r5785) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L1596 Version: 2.0-current Fix Version: 2.0-current (r5785) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2527: right shift key generates left shift key event in keyboard demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Active] Link: http://www.fltk.org/str.php?L2527 Version: 2.0-current So this is definitely a WIN32 specific bug, but it's not due to the fact that there aren't separate callbacks for the shift functions. It seems like WIN32 doesn't set lParam(121), like it does for all other modifing keys to let the 'user' know that it's a right key vs a left key. If you're capable with the Windows API, do you have any suggestions here? Link: http://www.fltk.org/str.php?L2527 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #826: VC++ chokes on fluid-generated strings of encoded image data
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L826 Version: 2.0-feature Fix Version: 1.1.7 It looks like this has been fixed in 2.0 for a long while. As such, I'll close this STR; please resubmit if the bug *hasn't* been fixed! Link: http://www.fltk.org/str.php?L826 Version: 2.0-feature Fix Version: 1.1.7 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1516: fltk-2.0.x-r5547 doesn't build on i686-apple-darwin9
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1516 Version: 2.0-current Fix Version: 2.0-current (r6063) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L1516 Version: 2.0-current Fix Version: 2.0-current (r6063) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1649: TextEditor's editor.cxx demo works incorrectly on intl. keyboards
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1649 Version: 2.0-current Fix Version: 2.0-current (r6147) Closing this STR; Bill suggests he fixed this quite a few revisions ago Link: http://www.fltk.org/str.php?L1649 Version: 2.0-current Fix Version: 2.0-current (r6147) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2235: gcc preprocessor directive #warning breaks MSVS fltk 2.0.x builds
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2235 Version: 2.0-current Fix Version: 2.0-current (r7680) Fixed in Subversion repository. Thanks to spitzak for this fix Link: http://www.fltk.org/str.php?L2235 Version: 2.0-current Fix Version: 2.0-current (r7680) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2390: #warning preprocessor directive not supported by all compilers
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2390 Version: 2.0-current Fix Version: 2.0-current Link: http://www.fltk.org/str.php?L2390 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2311: #warning unsupported by MSVC
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2311 Version: 2.0-current Fix Version: 2.0-current Link: http://www.fltk.org/str.php?L2311 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2365: FileChooser Berzerk When Typing Paths
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2365 Version: None Fix Version: None (r8385) Fixed in Subversion repository. Thanks for the work, RS. I'll get around to reviewing all your fixes at some point! Link: http://www.fltk.org/str.php?L2365 Version: None Fix Version: None (r8385) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2232: FLTK1/2 X11 keyboard handling broken if using a soft keyboard
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2232 Version: 2.0-current Tested this under FLTK2 and the bug no longer exists - Matt, it looks like you fixed this a while back. Since this was your fix, are you happy if this STR is closed? Link: http://www.fltk.org/str.php?L2232 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1593: using MinGW via MSYS compile FLTK 2.0 fail
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1593 Version: 2.0-current Fix Version: 2.0-current (r5919) Duplicate of #1613, which had been fixed a while back. Link: http://www.fltk.org/str.php?L1593 Version: 2.0-current Fix Version: 2.0-current (r5919) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1798: Win32 filename_list is broken
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1798 Version: 2.0-current Fix Version: 2.0-current (r6038) Link: http://www.fltk.org/str.php?L1798 Version: 2.0-current Fix Version: 2.0-current (r6038) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2363: libpng functions png_check_sig(buf, 8) and setjmp(png_ptr-jmpbuf) are deprecated!
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2363 Version: 2.0-current *shrugs*. The manpages didn't have any mention of it and I didn't really want to have to run bash to find out :-P What I might do is upgrade libpng/zlib/libjpeg and *then* apply this patch - this way I'll be forced to upgrade some of these functions to their more recent versions Link: http://www.fltk.org/str.php?L2363 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2066: crash at fltk::xpmImage::fetch
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2066 Version: 2.0-current I can't reproduce this bug at all, and given the lack of activity by the original submitter (and no subsequent followups), I'm going to assume this bug has been solved. As such, I'll close this STR in a few days if nothing is added to it. If this bug crops up again, it can always be resubmitted and we can go from there :-) Link: http://www.fltk.org/str.php?L2066 Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1637: listing files and dirs in file_chooser is broken on win
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1637 Version: 2.0-current Fix Version: 2.0-current (r8328) Fixed in Subversion repository. Sorting still isn't fixed, but fltk::FileChooser now properly displays unicode filenames on windows, with a slightly more portable suggestion to what Taras had. Thanks for the help though. I'll add proper sorting as soon as I can Link: http://www.fltk.org/str.php?L1637 Version: 2.0-current Fix Version: 2.0-current (r8328) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #1958: FileChooser shows green borders
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1958 Version: 2.0-current Fix Version: 2.0-current (r6132) Link: http://www.fltk.org/str.php?L1958 Version: 2.0-current Fix Version: 2.0-current (r6132) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2326: file chooser bug
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2326 Version: 2.0-current Fix Version: 2.0-current Link: http://www.fltk.org/str.php?L2326 Version: 2.0-current Fix Version: 2.0-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #1702: FileChooser-value() with type: CREATE
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L1702 Version: 2.0-current Fix Version: 2.0-current (r8316) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L1702 Version: 2.0-current Fix Version: 2.0-current (r8316) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2488: fltk::FileChooser removes the suggested filename if you deviate from the base directory
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2488 Version: 2.0-current Fix Version: 2.0-current (r8316) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2488 Version: 2.0-current Fix Version: 2.0-current (r8316) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2325: file chooser bug
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2325 Version: 2.0-current Fix Version: 2.0-current (r8317) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2325 Version: 2.0-current Fix Version: 2.0-current (r8317) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2431: TiledImage line 72 :ir.y(cr.x()-cy); this should be ir.y(cr.y()-cy);
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2431 Version: 2.0-feature Fix Version: 2.0-current (r7723) Seems like yuri forgot to close this one. Thanks for the fix. Link: http://www.fltk.org/str.php?L2431 Version: 2.0-feature Fix Version: 2.0-current (r7723) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2493: Mouse control get's jammed with multiple xkbmaps after the first click
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2318: problems with non-English keyboard layout
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2318 Version: 2.0-current Fix Version: 2.0-current (r8302) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2318 Version: 2.0-current Fix Version: 2.0-current (r8302) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2493: Mouse control get's jammed with multiple xkbmaps after the first click
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature Fix Version: 2.0-current (r8302) Whoops, forgot to change the status to Closed w/Resolution. Sorry for the noise. Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature Fix Version: 2.0-current (r8302) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2318: problems with non-English keyboard layout
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2318 Version: 2.0-current Fix Version: 2.0-current (r8302) Again, forgot to change the status to Closed w/Resolution. Further apologies for the noise. Link: http://www.fltk.org/str.php?L2318 Version: 2.0-current Fix Version: 2.0-current (r8302) ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2493: Mouse control get's jammed withmultiplexkbmaps after the first click
On 24/01/11 03:51, Albrecht Schlosser wrote: On 23.01.2011 17:08, Greg Ercolano wrote: Ben Stott wrote: DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link:http://www.fltk.org/str.php?L2493 Version: 2.0-feature Cool, someone's fixing 2.0 STR's! Yeah, welcome to the team, Ben ! Thanks guys! :) ... and while we're at it :-) I read the discussions about this STR with interest, and I noticed that you had looked at FLTK 1.3 as well in one of your statements: upon digging, I noticed that FLTK1.x suffers the same fate with its use of fl_xevent-xbutton.xstate (which only proves that this bug is consistent between FLTK version), however the default RELEASE event seems to handle things in a different way, which seems to sidestep this bug and provide the desired result. I can provide a patch for both versions Do you have a concrete suggestion for FLTK 1.3? Should we simply discard these two special bits? I could look into it myself, but since you seem to know better what's going on... I really only took a brief look, but FLTK caters for 7 events whereas X, by default, only caters for 5. Thus, when the fl_xevent-xbutton.xstate value is shifted, FLTK ends up keeping 2 bits of X garbage, and it was these two bits that were causing the problems in 2.0. 1.3 seems to manage it's FL_PUSH/FL_RELEASE events slightly differently to 2.0, which subverts this whole problem - 2.0 checks for ANY_BUTTON being pressed (and since X only returns 5 buttons by default, whereas ANY_BUTTON is an 8-button mask, this causes the reported bug). So at this stage, there's no real concrete suggestion. The state mask works, but I don't know how well it works on a mouse with 7 or 8 buttons - I'm testing this currently, but in order to do that I also need to add in horizontal scroll support. I'll have more time to look at this tonight. Ben ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2493: Mouse control get's jammed with multiple xkbmaps after the first click
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature The attached should completely wrap up this bug (Jaromir's second patch missed an event). Further, it extends ANY_BUTTON to cover 8 buttons (as was originally intended, based on the comment). It also cleans up a few magic numbers inside the win32 and osx implementations - although interestingly enough, these magic numbers were 0xff00 (i.e. an 8-button mask) as opposed to the #define'd 0x7f00 (a 7-button mask) that was/is used in the src/run.cxx implementation. Amusingly, svn blame and then svn log reveal Fast-fix for problem reported by Gordon Kindlmann; this seemed to render FLTK2 on Mac OS X broken (as it wouldn't compile). However, there *was* a mask in src/osx/run.cxx that seemed to be a little wrong; perhaps that was causing this problem - although at the moment, FLTK2 doesn't build on OS X as it uses Carbon, a library completely unavailable to 64-bit systems. In any case, I will check this out in the coming days, but I digress. This patch also completely fixes the problems described in STR #2318. Jaromir, could you please test this patch (as rigorously as you can) and tell me how it works? To be honest, I'm still not convinced that this is the correct and/or best solution for this problem - although I'll feel that way until X decide to document what they do with multiple keyboard layouts! Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2493: Mouse control get's jammed with multiple xkbmaps after the first click
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature Yes, as I said, 1.x doesn't suffer the same problem because it handles the RELEASE method differently to the 2.x version. I've yet to get a stable-enough internet connection (not currently at home!) to check out whether or not it's a layout mask or something different, however the X man page (which is marked as current) does seem to indicate that any value above 2^13 - 1 is an illegal - or at the very least undocumented - value for XButtonEvent::state. Although, having said all of this and proposing two solutions above, I've just realised this: Correct me if I'm wrong, but 0x7f00 is 31 digits long (in binary, not counting leading 0s) and the highest value that X can give for an event key is 1 12 (which is Button5Mask), which FLTK then shifts across 16 - thus making the highest key value only 29 digits. So perhaps your fix may actually be the correct one. Yet the fact that the 1.3 dev team haven't run across similar problems with the FL_BUTTONS declaration (which is also 0x7f00) makes me wonder. .Although knowing X, feature is right. Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2493: Mouse control get's jammed with multiple xkbmaps after the first click
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature See, I'd be tentative to use a patch like the one you provided as a permanent fix because it's essentially providing a solution by prolonging the problem Whilst I'm aware that by default X only provides support for 5 buttons, I'm fairly sure that you can (somewhat) configure it to provide support for as many buttons as you need - however, by changing 0x7F00 to 0x1F00, the 2.0 branch is essentially railroaded into using only 5 mouse buttons (which is probably plenty for most, but depending on the application, not enough for others - for instance, you lose the ability to scroll horizontally with a mouse). I'm still searching high and low for whether or not there's a meaning in those bits on XButtonEvent::state that seem to be set under a new keymap, but at this point they can be 'd out, which is a better solution IMO. Link: http://www.fltk.org/str.php?L2493 Version: 2.0-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [CRIT] STR #2493: Mouse control get's jammed with multiple xkbmaps after the first click
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2493
Version: 2.0-feature
Link: http://www.fltk.org/str.php?L2493
Version: 2.0-featureIndex: src/win32/run.cxx
===
--- src/win32/run.cxx (revision 8026)
+++ src/win32/run.cxx (working copy)
@@ -1591,7 +1591,7 @@
// Mask keeps the mouse button state:
// Alt gets reported for the Alt-GR switch on foreign keyboards,
// so we ignore it for WM_CHAR messages:
-e_state = (e_state 0xff00) | shiftflags(uMsg==WM_CHAR);
+e_state = (e_state ANY_BUTTON) | shiftflags(uMsg==WM_CHAR);
if (lParam (131)) { // key up events.
e_is_click = (recent_keysym == e_keysym);
recent_keysym = 0;
Index: src/osx/run.cxx
===
--- src/osx/run.cxx (revision 8026)
+++ src/osx/run.cxx (working copy)
@@ -690,7 +690,7 @@
UInt32 chord;
GetEventParameter( event, kEventParamMouseChord,
typeUInt32, NULL, sizeof(UInt32), NULL, chord );
- e_state = ( e_state 0xff ) | state[ chord 0x07 ];
+ e_state = ( e_state ANY_BUTTON ) | state[ chord 0x07 ];
// make the stylus data produce something useful if there's no pen
//if (no_stylus) {
@@ -792,7 +792,7 @@
if ( mods (controlKey|rightControlKey) ) state |= CTRL;
if ( mods (shiftKey|rightShiftKey) ) state |= SHIFT;
if ( mods alphaLock ) state |= CAPSLOCK;
- e_state = ( e_state 0xff00 ) | state;
+ e_state = ( e_state ANY_BUTTON ) | state;
//printf( State 0x%08x (%04x)\n, e_state, mods );
}
Index: src/x11/run.cxx
===
--- src/x11/run.cxx (revision 8026)
+++ src/x11/run.cxx (working copy)
@@ -1217,7 +1217,12 @@
e_x = xevent.xbutton.x;
e_y_root = xevent.xbutton.y_root;
e_y = xevent.xbutton.y;
- e_state = (xevent.xbutton.state 16) | extra_state;
+ // Only the 1st to the 13th bit in XButtonEvent::state are
+ // relevant to mouse buttons; the rest are a keymap mask,
+ // which can cause problems for FLTK's 6th, 7th and 8th mouse buttons.
+ // If we bitwise the state member with XSTATE_MASK (defined in fltk/x.h)
+ // we remove the conflict.
+ e_state = ((xevent.xbutton.state XSTATE_MASK) 16) | extra_state;
event_time = xevent.xbutton.time;
// turn off is_click if enough time or mouse movement has passed:
static int px, py;
@@ -1548,7 +1553,7 @@
case EnterNotify:
set_event_xy(false);
-e_state = xevent.xcrossing.state 16;
+e_state = (xevent.xcrossing.state XSTATE_MASK) 16;
if (xevent.xcrossing.detail == NotifyInferior) {event=MOVE; break;}
// printf(EnterNotify window %s, xmousewin %s\n,
//window ? window-label() : NULL,
@@ -1569,7 +1574,7 @@
case LeaveNotify:
set_event_xy(false);
-e_state = xevent.xcrossing.state 16;
+e_state = (xevent.xcrossing.state XSTATE_MASK) 16;
if (xevent.xcrossing.detail == NotifyInferior) {event=MOVE; break;}
// printf(LeaveNotify window %s, xmousewin %s\n,
//window ? window-label() : NULL,
Index: fltk/events.h
===
--- fltk/events.h (revision 8026)
+++ fltk/events.h (working copy)
@@ -180,7 +180,7 @@
BUTTON1 = 0x0100, /*! Left mouse button held down */
BUTTON2 = 0x0200, /*! Middle mouse button held down */
BUTTON3 = 0x0400, /*! Right mouse button held down */
- ANY_BUTTON = 0x7f00, /*! Any mouse button (up to 8) */
+ ANY_BUTTON = 0xff00, /*! Any mouse button (up to 8) */
#if defined(__APPLE__)
ACCELERATOR = CTRL,
OPTION = ALT,
Index: fltk/x11.h
===
--- fltk/x11.h (revision 8026)
+++ fltk/x11.h (working copy)
@@ -78,6 +78,7 @@
#include draw.h
extern FL_API Region XRectangleRegion(int x, int y, int w, int h);
+#define XSTATE_MASK 0x1fff
namespace fltk {
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
