Re: [fltk.bugs] [LOW] STR #2714: FLTK headers have shadow lint
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2714 Version: 1.4-feature Matt: wait, are you sure it needs to be 1.4? I think this str can be solved within the 1.3.x series without variable name changes by simply moving source in the .H for the methods he's cited from .H - .cxx. Note he's not trying to get the fltk lib to compile with -Wshadow, just his own apps. So that could just mean relocating code, without changing anything. (I've already modified Fl_Tree's in r9085, and working on Fl_Table. In my case I moved all the code, not just his methods, but for other fltk files, small amounts of code could be moved) I don't think we need to bump to 1.4 to fix this; no abi issues. It can probably be held for 1.3.2, unless the plan is to go for a 1.4.x asap. I figure there's still room for a few maintenance releases for 1.3. To test for shadow problems for apps, we could make one test program that #include's all fltk widgets, instancing them once, and have just that test program compile with -Wshadow. This way future builds will note shadow errors in our .H's. Link: http://www.fltk.org/str.php?L2714 Version: 1.4-feature ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [RFE] STR #2721: Fl_Text_Display: patch for to draw cursor on a selected text area.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2721 Version: 1.3-feature Regarding this STR (cursor position within a selection), I've can't say I've ever seen this before anywhere. When something is selected, the selection *is* the 'cursor': o if you hit Delete, the whole selection is deleted o if you do a paste, the whole selection is replaced with the paste o if you hit arrow keys, the selection disappears It would only make sense to show the cursor if there was something the user could do with it. Is there a built-in feature that the user can access that Fl_Text_Editor supports? If not, it seems wrong to show it. Perhaps it can be a behavior with an on/off flag that defaults off, in case it's somehow useful for derived widgets to make use of. Link: http://www.fltk.org/str.php?L2721 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] FLTK 1.3.1 release planning
On 09/30/11 04:00, Matthias Melcher wrote: I may no be able to go through the regular release cycle because of the urgency of the 1.3.0 bug! Sounds good to fix the bad problem. I wonder if you can just apply the patch to the 1.3.0 code base that just fixes this one issue and release a 1.3.1? This would minimize issues sneaking in frmo changes made since 1.3.0 that would probably necessitate extensive testing. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fl_color() crashing program
On 09/30/11 07:45, Paul R wrote: I just linked back to a build of 1.3 rc2 It worked fine, i am thinking i might need to rebuild the 1.3 library, i used msys and no errors were reported but i think i looked around for a snapshot that included the config and used that instead of the actual final release.. I'd agree with Ian, sounds like you might be linking against one version of FLTK, but #include'ing against another. This kind of mixup can cause weird crashes. Try this test: go into the 'examples' subdirectory of the FLTK release you're trying to work with, and paste the contents of the 'simple x' program into a file called foo.cxx in that directory. Then run 'make foo; ./foo' and see if it works. While in the examples subdir with the above foo.cxx, maybe also try building with: ../fltk-config -compile foo.cxx ..and again, run the resulting binary. If those all work, it's likely your tests that crash are building against the wrong libs or include files or both. Be sure your app's compile/link flags for -I and -L are all referring to the correct location of FLTK, and be sure you don't have an old install of FLTK lying around in /usr/include/FL that the compiler might be picking up. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [LOW] STR #2714: FLTK headers have shadow lint
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2714 Version: 1.3-current According to the thread on fltk.development, it sounds like moving code from .H - .cxx won't affect the ABI, and may improve code maintainability (regarding the affect on DLLs for consistency in code use) So when I get a chance, I'm going to commit the mods to Fl_Tree, which is such a new widget, that a large code re-org shouldn't be an issue. This should solve the variable shadowing for app code, while not needing to change the variable names. Link: http://www.fltk.org/str.php?L2714 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2687: src/scandir.c should probably be removed or rewritten
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 +1 for remove it and see if this causes any trouble. Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] An ABI issue with moving code from .H - .cxx?
On 09/25/11 13:09, Bill Spitzak wrote: Inline is only implied if the method is defined inside the class definition. Right, clear on that now. What's interesting are the implications this has on dynamic libs; code changes made to lib methods implemented in .h won't be 'seen' by 'old' dynamic apps running with the new lib installed, whereas changes made to methods implemented in .cxx /will/ be seen by the app at runtime. Or so my tests on linux seem to show, where I made a small dynamic lib with 3 methods called a/b/c: a() implemented in .h b() implemented in .h as 'inline', c() implemented in .cxx file When I make changes to the lib, and run the old app with the new dynamic lib present, I get this behavior at runtime: o Calls to a() runs the old lib code o Calls to b() runs the old lib code o Calls to c() runs the new lib code What's interesting is that even when the new lib calls a() and b(), the new lib runs the OLD code. This seemed surprising to me, even for the 'inline' method! I would have expected that the lib's calls would have invoked the new method code, and the app would get the old code. So apparently in this way, inline methods really aren't 'inline'; the run time linker can still force the lib to call the older method code. I guess that ensures 'consistency' at least. Anyway, I guess it's /not/ an issue to move code from .h - .cxx during a minor release of a dynamic lib; it seems to have no effect on older apps, which continue to run the older code. I guess having code in .cxx gives devs more flexibility during minor releases; one doesn't have to be concerned as much with code incompatibilities that can be caused if some methods are in .h, some in .cxx, and both are changed. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] An ABI issue with moving code from .H - .cxx?
I hope I haven't asked this one before: Does it create any kind of ABI issue if one moves a class method's code implementation from the .H file to the .cxx file? (ie. doesn't change the calling params or return value, just moves the code from one to the other) I'm sure the compiler/linkers handle this 'the right way', but it occurs to me I'm not sure what the compiler does when code is implemented in the .H; does it get compiled each time it's #include'd, then sorted out at link time? If so, in the case of a class that's entirely implemented in a .H, what happens when an app is built against a new version of the lib, but runs in an environment that dynamically links against an older version of the lib? I imagine the runtime link is going to choose only one implementation of the method code, and use it consistently for both the lib and the app code that uses it, and I /imagine/ it chooses code that was built into the lib? (So that the runtime lib controls which version of the code is used, and not some mix of new and old code?) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] An ABI issue with moving code from .H - .cxx?
On 09/23/11 09:40, Bill Spitzak wrote: Functions defined in the body of the code in a .h file end inlined: Ick, I didn't know 'inline' would be implied if the code was implemented in the .H file. So it sounds like if an app /dynamically/ builds against a lib whose version is 1.1, any app calls to that method get the 1.1 version of the code 'burned' into it. Then later, if the app is run on a user's machine with an older 1.0 version of the lib installed, the lib's calls to that function run the older 1.0 version, and the app's version runs the newer 1.1 version? If so.. that sounds a bit scary in a dynamic lib environment. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Bye bye Quickdraw fltk-2.0
On 18.09.2011, at 19:46, Jonathan Egstad wrote: (a big hi to all the old DD guys on this list) Egg! And old we are.. Someone kindly fetch me my cane and stool softener.. Is anyone touching 2.0 at all or should I look at the latest 1.3 to figure out the replacements for the deprecated calls? I'd suggest 1.3. Are you trying to build new code (then go with 1.3) or are you somehow working with some existing project that (mistakenly) went with 2.x before it released? On 09/18/11 11:08, Matthias Melcher wrote: nice to read from you! This is Wonko. LOL, funny I couldn't remember your old DD login name, though now that I hear it, I remember. (Someone fetch me my ALZ pills as well..) But since nobody maintains 2.x anymore, ..well, except for Ben.. ;) ..you should be able to compile most DD tools without much effort. Did DD eventually start using FLTK for its internal tools? I left DD soon after Titanic and Dante's Peak wrapped, which was right around when Bill was talking about taking FLTK public (1997 or so), so I didn't get to see it gain acceptance internally. I think I was still using Xforms at that time, and others were using either TCL/TK or SGI's RapidApp/Motif. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [MOD] STR #2711: FL_NORMAL_SIZE and menus
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2711 Version: 1.3-current Attached file menubutton.png... Link: http://www.fltk.org/str.php?L2711 Version: 1.3-currentattachment: menubutton.png___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2711: FL_NORMAL_SIZE and menus
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2711 Version: 1.3-current Attached file radio.png... Link: http://www.fltk.org/str.php?L2711 Version: 1.3-currentattachment: radio.png___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.general] triggering buttons from the keyboard
On 09/10/11 10:39, corvid wrote: With 2.0, pressing Enter triggers a button. In 1.3, only Space works. I believe Fl_Return_Button is what you'd want to use in 1.3.x to have the enter key trigger a button. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] triggering buttons from the keyboard
On 09/10/11 11:47, Greg Ercolano wrote: On 09/10/11 10:39, corvid wrote: With 2.0, pressing Enter triggers a button. In 1.3, only Space works. I believe Fl_Return_Button is what you'd want to use in 1.3.x to have the enter key trigger a button. I should add: Fl_Return_Button will trigger even if it doesn't have focus. So if the Enter key isn't already being handled by something else (like an Fl_Multiline_Input widget), this button will take the event for itself. Otherwise, for focus-only oriented behavior, besides deriving your own widget (eg. MyButton) that handles this, I suppose a method could be added to Fl_Button, with 'space' being the default. So for instance, something like: button-trigger_key_clear();// clear previous trigger keys, including 'space' button-trigger_key_add(FL_Enter); // add regular enter key button-trigger_key_add(FL_KP_Enter); // add keypad enter key ..this way both enter keys can trigger the button. Perhaps too, this could be a global preference, the way we currently have Fl::scrollbar_size() to set things globally, and Fl_SomeWidget::scrollbar_size() to affect just one widget. Or, if there's some agreement that 'space' is not the right key anymore, and Enter is, then perhaps a petition to change. (I'm almost sure that would break some existing apps though.) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] triggering buttons from the keyboard
On 09/10/11 12:40, corvid wrote: Which environments tend to use Space to trigger buttons? Linux is one. For instance if I run system-config-date (just picking a system gui at random), if I tab focus to the Help key, both Space and Enter trigger the button. Also, Thunderbird 6.0.2 (Linux) I upgraded to this morning, 'space' triggers buttons that have focus in the Preferences dialogs. (as does Enter) Space-triggered buttons are probably a holdover from old X application behavior, which FLTK has its original roots. FLTK was originally designed on SGI's in the mid 90's, before the PC standard behaviors were adopted, where the emacs culture was used for GUI text editing functions. We've been slowly trying to identify and remove these X specific holdovers in favor of prevailing standards. Emacs editing keys like ^A (move to start of line) had to be replaced with 'select all'. Tab keys doing focus navigation is something we recently addressed in the final months before 1.3.0 was released. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
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 @Ben: yes, just tested with 2.0 r8800 (current tar snapshot), got the same errors. In my case I'm using centos 5.5, and used: make distclean; ./configure --disable-gl --with-optim=-Os; make 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.general] FLTK with XFCE
On 09/05/11 06:04, Steve Underwood wrote: I have finally posted some files showing this issue at http://www.soft-switch.org/fltk-bug/ . There are image captures of a fresh window, and the same window after partially covering and uncovering it. The code for the little program which produced this window is also there. What happens if you change the main window from an Fl_Window to an Fl_Double_Window ? D. Single and double windows seem to behave exactly the same. Do all the fltk test programs portray this weird behavior as well? Try running 'xrefresh' while your app is running; do the artifacts change? Have you tested a lot of other GUI apps with this configuration? eg. 'old reliable' X apps (like 'xeyes', xclock, xlogo) Try resizing these real large and real small, looking for drawing artifacts. This sure looks like a driver issue of some kind, the way there appears to be 'echos' of other screen data. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Fl_Native_File_Chooser on OSX
If I run that app and do these steps: 1) File - Save As, filter appears 2) File - Open, *filter is missing* 3) File - Save As, *filter is missing* The filter being missing is the problem. [..] Perhaps _filt_total shouldn't be reset to zero in show()? Or instead, maybe the checks for _filt_total in post() should be replaced with checks to see if filter() is NULL/ and if not, call prepareMacFilter() so that the filter gets re-applied. Opinions? Or perhaps other options? I agree with you. r.9030 should fix this issue. Confirmed r9030 fixes the problem; thanks! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Native_File_Chooser on OSX
On 09/03/11 14:47, Manolo Gouy wrote: All (but especially Greg I guess...) I have an app that uses the FNFC, and the OSX version crashes quite = often when I use the BROWSE_SAVE_AS mode - but the regular open file = case seems to be fine... Now, the app has been kicking about for a while, but it's fairly = specialist and there are a grand total of 3 users worldwide (myself and = two others) and it was not until recently we noticed there's an issue. = The regular workflow is such that the save-as case is seldom used, and = even now there's only one of us who does use it much if at all... But we = are about to deploy more widely, so we need to get it fixed... So, is anyone else seeing issues with the FNFC save-as option on OSX I see here, that there is a bug on OS X with the BROWSE_SAVE_FILE mode when the filter() function is used: the filter string needs to end with a \n; without it the program crashes. Do you see that as well ? Sounds like I should add a check for this in filter() and append a trailing \n if it's missing. I just tried to replicate with the examples/native*.cxx program, removing the trailing \n on the filter() and it didn't crash. Tested on OSX Tiger. Can you replicate with that program, and show me the modified filter(), and describe the target system? Perhaps it's OS specific. Ian if you can replicate, please follow up with an STR, and I'll jump on it. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Native_File_Chooser on OSX
On 09/04/11 12:47, Manolo Gouy wrote: I see here, that there is a bug on OS X with the BROWSE_SAVE_FILE mode when the filter() function is used: the filter string needs to end with a \n; without it the program crashes. Do you see that as well ? Sounds like I should add a check for this in filter() and append a trailing \n if it's missing. Please, don't do that. With r.9029, the requirement for a terminal \n is removed. Oh, OK. I guess that explains why I couldn't replicate ;) since I updated to latest SVN before testing. I forgot you ported my Mac version of FNFC to cocoa, so there's a bit of new stuff in there. Manolo -- while looking into this, playing around with examples/native*.cxx program, I noticed a different problem. If I run that app and do these steps: 1) File - Save As, filter appears 2) File - Open, *filter is missing* 3) File - Save As, *filter is missing* The filter being missing is the problem. In the example code, it sets the filter() once at the beginning of the app, the assumption being it remains in effect for the widget unless changed. But it seems the way the FNFC mac code is written, it doesn't re-apply the filter on subsequent calls to posting the dialog. filter() shows the string still set, but internally the code is skipping calling prepareMacFilter() I think because _filt_total is getting reset to zero in show(), just after post() is called. I could change the example program to always call filter() before calling show(), which does fix the problem, but I'm not sure it should need to. Perhaps _filt_total shouldn't be reset to zero in show()? Or instead, maybe the checks for _filt_total in post() should be replaced with checks to see if filter() is NULL/ and if not, call prepareMacFilter() so that the filter gets re-applied. Opinions? Or perhaps other options? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.bugs] [MOD] STR #2709: Windows7/x64 drawing problems in buttons.exe demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Posting this on Chao Han's behalf, who reported black pixels in lower/right corner of pressed buttons. See thread in fltk.general entitled Black dot on the bottom right corner. I investigated a bit, found I could replicate with VS2010 on Win7/x64. Attaching two images here showing problem. (bad1.png, bad2.png) I found the problem moved around, sometimes lower right, sometimes upper right. Could see problems with other widgets too. Interestingly, other test programs did NOT have the problem (button.exe, unittests.exe). Seemed specific to buttons.exe. The 'buttons' app demonstrates several different button widgets, so going on a hunch that one of the widgets was affecting the problem, I commented out one at a time until the problem went away. Fl_Round_Button seemed to be the cause. I commented out all other widgets except a regular button and Fl_Round_Button and could still replicate. Then reversed the commenting so only Fl_Round_Button was commented out, and problem was gone. I imagine it has to do with the Win32 circle drawing code, or some such..? Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2709: Windows7/x64 drawing problems in buttons.exe demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Attached file buttons-draw-problem.png... Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0attachment: buttons-draw-problem.png___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2709: Windows7/x64 drawing problems in buttons.exe demo
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0 Attached file buttons-draw-problem2.png... Link: http://www.fltk.org/str.php?L2709 Version: 1.3.0attachment: buttons-draw-problem2.png___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] FL_INTERNALS not needed for fl_xid()
On 09/02/11 07:32, Manolo Gouy wrote:
Greg: I don't think FL_INTERNALS should be defined before
function fl_xid() is called, as implied in your r.9025 doc change.
In files x.H and win32.H, fl_xid() is declared twice according
to whether FL_INTERNALS is defined or not. In mac.H, it is defined
outside of the #if defined(FL_INTERNALS)/#endif block.
The system-specific return type of this funtion is defined
by including x.H, as specified in the OS-issues doc.
It's weird, because the errors refer to Fl_X being
undefined, and the osissues doc for that say to
#define FL_INTERNALS, eg:
--- snipped quote
Note:
Access to the Fl_X hidden class requires to #define FL_INTERNALS before
compilation.
--- snipped quote
Do you agree ?
Thanks Manolo; it's good this is getting scrutiny.
Perhaps the use of FL_INTERNALS is no longer the recommended
solution? (It has been recommended in the past)
I have no opinion on this, just trying to make sure the docs
reflect the correct use, so when the question comes up, we can
refer to docs.
So the question is:
Is #include FL/x.H the recommended way to access fl_xid()?
If so, I can update the fl_xid() docs to mention that.
FWIW, the following little app calls fl_xid(), and compiles OK
on linux/win/mac without FL_INTERNALS, so perhaps that's correct?
--- snip
#include FL/x.H // --
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/fl_ask.H
int main() {
Fl_Window *win = new Fl_Window(200,200);
win-show();
fl_alert(XID=%p\n, (void*)fl_xid(win)); // --
return(Fl::run());
}
--- snip
If so, has this always been the case, or is it 1.3.0 specific?
(docs should probably mention if it's the latter case)
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FL_INTERNALS not needed for fl_xid()
On 09/02/11 10:56, Manolo Gouy wrote: Also, fl_xid() was part of the API and declared in x.H already in 1.1, without need for any extra symbol definition. OK, good. So just confirming: Should the public docs for fl_xid() indicate one should #include FL/x.H to make use of it? It's the docs I'm trying to nail down, as to date they make no mention of what to include, and folks seem to trip up on errors with fl_xid() a lot. From what I can tell, fl_xid() is only documented in osissues, which to date only had once sentence describing it, and doesn't cover what to include to reach it. Whatever mention there is of x.H currently in osissues, I don't think it clearly connects to fl_xid(). If it is, apparently it's unclear, as others including myself have run into this. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FL_INTERNALS not needed for fl_xid()
On 09/02/11 12:54, Manolo Gouy wrote: This common header requirement is clearly stated at the top of the Operating System Issues section of the doc. Isn't that enough ? LOL, believe it or not, I missed it ;) Yes, it's certainly clear, right at the top. Actually, I'd never thought of this document as a collection of functions that might all be defined in a single #include file; I thought it was a collection of miscellaneous OS specific functions. Probably also, the name (x.H) threw me; can't say as I've ever needed it, and would never have associated it with this doc or os specific functions. So I'll back out my doc changes, it's certainly clear enough to refer to the docs at the top for the include to x.H. As long as there's something to point to when folks run into this, it's all good. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Black dot on the bottom right corner
On 09/01/11 21:06, Chao Han wrote: Another screenshot - http://www.ge.tt/#!/8cjIDN7 http://www.ge.tt/#!/8FUGCN7 Received, confirming a dark pixel in the lower right corner of each depressed button. It would appear when a normal button is drawn, the right and bottom edges of the button are a black line, and when pressed, a white line. In this case, it seems like the white line is not erasing over the black line at the bottom right corner where the two lines should meet, ie. the x+w-1, y+h-1 coordinate of the button's xywh position. Could this be that n+1/n-1 problem mentioned in the recent win32-X11 drawing coordinates thread..? ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Black dot on the bottom right corner
On 09/02/11 00:33, Greg Ercolano wrote: On 09/01/11 21:06, Chao Han wrote: Another screenshot - http://www.ge.tt/#!/8cjIDN7 http://www.ge.tt/#!/8FUGCN7 Received, confirming a dark pixel in the lower right corner of each depressed button. Yes, I can replicate OP's exact problem on my win7 64bit system with a version of 1.3.0 I compiled some time ago; black pixel in lower right corner. Sometimes I've gotten the problem to move around, where the black pixel appears at the upper right when pressed instead of the lower left, eg: http://seriss.com/people/erco/fltk/tmp/buttons-draw-problem2.png And when that happens, I can see problems with the a 'white' dot over the black line when the buttons are up, eg: http://seriss.com/people/erco/fltk/tmp/buttons-draw-problem.png There seems to be problems all over the place if one looks closely. I don't see any of this on fltk/linux: http://seriss.com/people/erco/fltk/tmp/buttons-draw-noproblem-linux.png ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Black dot on the bottom right corner
On 09/02/11 01:09, Greg Ercolano wrote: On 09/02/11 00:33, Greg Ercolano wrote: On 09/01/11 21:06, Chao Han wrote: Another screenshot - http://www.ge.tt/#!/8cjIDN7 http://www.ge.tt/#!/8FUGCN7 Yes, I can replicate OP's exact problem on my win7 64bit system with a version of 1.3.0 I compiled some time ago; black pixel in lower right corner. The plot thickens. Now that I can replicate, I played around with it. Went directly to unittests, but *could not* replicate there. In fact, could not replicate with other test programs that drew regular buttons (eg. button.exe) Didn't see any problems with other button-like widgets (scrollbars, scroll buttons, boxes with insets, etc) So I focused on buttons.exe which has the problem. I imagined one of the other button widget's presence influences the problem. I started commented out one at a time until the problem disappeared: Fl_Round_Button seems to be the culprit. To be sure, I commented out everything except a regular button and the Fl_Round_Button, and the problem remained. Then switched it to only comment out Fl_Round_Button, and the problem was gone. Where to go from here I'm not sure, other than to post an STR for the problem on OP's behalf with these details. So please follow up on STR#2709: http://fltk.org/str.php?L2709 ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Black dot on the bottom right corner
On 09/02/11 01:30, MacArthur, Ian (SELEX GALILEO, UK) wrote: Also seen on WinXP/32 with mingw and fltk-1.3 r9025. But only in certain cases... E.g. running examples from the test folder, I see problems with the buttons.exe but *not* with button.exe. The radio.exe seems to show it too, but most others (in a very brief survey) appear not to. Yes, found similar results. Seems the presence of Fl_Round_Button causes the issue in buttons.exe. Although unittests.exe exercises circles and stuff, I didn't see any trouble in unittests. (It has no buttons, but scrollers and scroll buttons seemed OK. Maybe both have to be onscreen at the same time?) Also, the same demos from fltk-1.1 appear to be OK. I made an STR #2709 for this problem, so feel free to add details there. I'm about to kick for the day, but someone can hopefully pick up from here.. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] fl_xid() -- needs docs?
On 08/06/11 10:07, Greg Ercolano wrote: After reading STR #2696 http://www.fltk.org/str.php?L2696 it sounded like we should add some docs for fl_xid() to mention the need for apps to #define FL_INTERNALS. I'm not sure what to write or I'd write it. This keeps coming up, so I added 'something' as r9025 to the osissues.dox, which is the only place I think fl_xid() is mentioned. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Fl_X undefined
On 09/01/11 12:08, Chao Han wrote: I just updated to the latest version 1.3.x-r9013, and my application failed to compile under VS 2008 (debug x64), complaining that Fl_X was undefined. Please give me some advice. See: http://fltk.org/newsgroups.php?gfltk.development+v:12524 Add this line: #define FL_INTERNALS ..above your FLTK #include's in your app, and it should work. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Black dot on the bottom right corner
On 09/01/11 14:32, Chao Han wrote: While running the test project - buttons in the solution ‘fltk’, I have found an issue. When pushed the one button, you can see a black DOT at the bottom right corner. Notes: Under the VS2008 - debug x64 (window7)-latest version 1.3.x-r9013, Sorry to forget the fltk version in the previous post. Can you post a link to a screenshot showing the problem? Also: does window placement affect this problem? Have you ruled out graphics driver problems? (eg. try disabling/enabling hardware acceleration) Unless you downloaded a completely new tar file, try a clean rebuild, just in case there were some old .o files lying around. Anything special about this machine's fonts or config? Kinda sounds like it could be graphics driver or font related, not sure till we can see a screenshot of some kind. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Black dot on the bottom right corner
On 09/01/11 16:50, Chao Han wrote: Can you post a link to a screenshot showing the problem? 1) how to post a link to a screenshot. Use whatever technique you like to take the screenshot (Shift-PrtScreen, then paste into ms paint), upload the resulting image to some public location (like pastebin.com), and paste the URL here. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK with XFCE
On 08/29/11 19:19, Steve Underwood wrote: I've been using FLTK for years on Linux and Windows machines. For the first time I have tried using it with XFCE 4.8, and I find a problem that doesn't seem to occur anywhere else. I am using FLTK 1.10. If I run Fluid, and create a window with some coloured background areas, those background are not updated properly. The window is initially drawn OK. However, if another window then overlaps it and is moved away, the background areas in the window I am creating are not properly restored. If I finish my Fluid development work, and build the resulting application, the application behaves in the same way. If I restart the same machine running Gnome 3 instead of XFCE, both Fluid and the application behave properly. The same code also behaves OK on a Windows XP machine. Is this a known issue? Is there a workaround? I just tried yum installing xfce, whipped up an .xinitrc to start xfwm4 and xfdesktop, and fluid from both 1.1.10 and 1.3.0 seem to work fine; I made colored areas and can resize the windows OK. This on 64bit Centos 5.5 on a mac mini. Usually problems with background drawing are graphics driver related. Are these Fl_Double_Window's or just plane Fl_Window's in your app? Are there certain FLTK test programs that exhibit this behavior, and not others? What kind of update problem is it; does it leave echos of the window's own borders behind as you make windows larger, or does it 'see through' to windows below? Or perhaps leaves partially drawn flashes of the current window behind? Is there anything unusual or new about your graphics driver or equipment? Is it well supported? Or maybe testing new settings in the x config file? Perhaps hardware acceleration related settings? Can you paste a simple compilable fltk program the exhibits the problem on your box? Does changing the window from an Fl_Window - Fl_Double_Window make a difference? Are there scrollers in your app, and does the problem only happen during scrolling or resizes. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] FLTK3: Status
On 08/29/11 01:26, MacArthur, Ian (SELEX GALILEO, UK) wrote: The example opens up a tcsh prompt. See, that's gotta be a bug, right there! ;-) You're right, it is a bug.. in bash! During dev, I was getting inconsistent behavior from bash on an old OSX 10.4.11 system; both the bash and ksh on that system would suspend itself when both input and output were pipes. At first I thought it was my app, but could replicate from the cli: # echo echo hello | sh -is 21 | cat [1]+ Stopped(SIGTTIN)echo echo hello | sh -is 21 | cat ^^ Heh? # fg echo echo hello | sh -is 21 | cat [1]+ Stopped(SIGTTIN)echo echo hello | sh -is 21 | cat ^^ wat # fg echo echo hello | sh -is 21 | cat [1]+ Stopped(SIGTTIN)echo echo hello | sh -is 21 | cat ^^ Won't go away! # ps aux | grep sh..is | grep -v grep root 2980 0.0 0.127812552 p2 S 6:07AM 0:00.01 sh -is # kill -9 2980-- kills it, finally # sw_vers ProductName:Mac OS X ProductVersion: 10.4.11 BuildVersion: 8S165 This was pretty bad, cause the app would get no prompt, and the sh was bg'ed in the invoking shell, and would remain until killed. Perhaps fixed in an update, but I didn't want folks running into that. tcsh worked fine, so I left that in. I've run into a lot of weird bugs on OSX with unix stuff.. really unsettling. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] FLTK terminal apps
On 08/29/11 01:26, MacArthur, Ian (SELEX GALILEO, UK) wrote: It uses pthreads and bidirectional pipe(2)s. All FLTK operation is handled by the parent; the threads are just data pumps. [I chose not to use add_fd() to facilitate a Windows port] On WIN32, add_fd() will work OK for sockets, so I wonder if we could spawn/create a (win32 specific) process that handles the remote end of the connection and talk to that via sockets using add_fd() etc. That might be a portable way of isolating the win32 specific weirdness from the fltk end of things? Mmm, good point. That indeed might be more portable. Win32's berkeley sockets are very unixy and behave pretty well. I know the native win32 pipe/thread approach works well and is not buggy; I've used that in closed source apps since the WinNT days, and those apps get a lot of 24 hour use and very stable. But I don't know if I ever tried using bsd sockets on windows for unbuffered stdio interaction with a child process; do you know that to be a stable route? I kinda like using threads though, cause I know any weird blocking won't hiccup the UI; the read/writes can block all day and not affect FLTK's response. For this purpose, I do like threads and feel I can trust them. Oh, and BTW, I did try your fl_term app -- neat! It worked really well. I see it derived from Fl_Box, so it implements all the text handling itself, and seemed pretty fast even with big reports, like 'find /'. (In mine, I cheated and used Fl_Text_Editor which is imperfect for a tty, but it gets you copy/paste and screen history for free) I didn't have any trouble playing with fl_term in man pages, vi, and messing with colors, which is saying a lot for a new terminal app. Usually tty emulation is buggy, but it seemed pretty good. Too bad about copy/paste, screen history, and 80x25. But I see you've got the bsd + sysv pty stuff in there; nice! Hopefully one of us will get enough time to make an actual xterm compatible terminal out of it. I never liked xterm (too much ancient athena), and kde's term seems to want a bunch of KDE daemons running, which drives me nuts. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK3: Status
On 08/26/11 23:55, Matthias Melcher wrote: Well, for now the popen solution is somewhat OK. I want Fluid to launch all kinds of tools, which usually only requires reading characters from the tools. It would be nice to have some way to send characters as well, for example for launching gdb I had some time this weekend to make a variation that works with interactive programs like gdb(1). It's unix only, but handles stdin, stdout, and stderr asynchronously: http://seriss.com/people/erco/fltk/unix-bidir-dumb-terminal.cxx It uses pthreads and bidirectional pipe(2)s. All FLTK operation is handled by the parent; the threads are just data pumps. [I chose not to use add_fd() to facilitate a Windows port] With some work, it could be extended to support windows; the mechanics should be able to be ported to use the WIN32 CreatePipe()/CreateThread()/CreateProcess() and friends. Basically the MyTerminal class from my original example has been extended to handle bi-directional interaction with the child process. You'll see actual prompts from the shell and interactive tools, and can interact with them asynchronously. The example opens up a tcsh prompt. So you can fire off interactive programs like gdb(1) and nslookup(1), and you can interact with them normally. (see caveats below) Tested on linux and osx. CAVEATS Some simple line editing is supported: backspace, ^U, ^W, Enter. That's it. Other special characters may yield 'undefined behavior'. Does NOT support pty features like job control, EOF, 'raw' modes. So for instance, ^Z, ^C, or ^D are not supported. Also: no inline editing like ^A, ^E, ^P, ^N, arrow keys, etc. Because this is implemented around Fl_Text_Editor, many of the editor's features are available that shouldn't be; the arrow keys and mouse clicks can move the text cursor up into the screen history. Some additions are necessary to handle reaping the child process, and to allow the ability to kill the child and start a new one. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK3: Status
On 08/26/11 09:05, Matthias Melcher wrote: If anyone has code that can act as a frontend to command line tools, and that can handle stdin, stdout, stderr, and signals simultaneously, please send code ;-). I need some kind of simple FLTK text terminal. This is as close as I'd ever gotten to that: http://seriss.com/people/erco/fltk/#SimpleTerminal It's pretty much a dumb terminal; you can only append, and of course it doesn't understand ANSI sequences. But it does handle stdin,out,err. For signals, I can't remember if things like ^C and ^Z pass thru to the shell in a way that it recognizes, but I suppose you can always handle() them if they don't, and send the appropriate kill() to the child process. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK3: Status
On 08/26/11 10:27, Greg Ercolano wrote: On 08/26/11 09:05, Matthias Melcher wrote: If anyone has code that can act as a frontend to command line tools, and that can handle stdin, stdout, stderr, and signals simultaneously, please send code ;-). I need some kind of simple FLTK text terminal. This is as close as I'd ever gotten to that: http://seriss.com/people/erco/fltk/#SimpleTerminal It's pretty much a dumb terminal; you can only append, and of course it doesn't understand ANSI sequences. But it does handle stdin,out,err. Oh wait, since it uses popen() to read output from the cmds, it probably /doesn't/ handle stdin. Mmm, it probably could by replacing popen() with pipe()'s and fork()/exec(), with select() to watch the stdout/err pipe, and trapping keystrokes yourself and sending them to the stdin pipe. Tricky though. I'd do it myself, but this week is nuts for me schedule wise. Perhaps someone else has something further along.. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK3: Status
On 08/26/11 13:13, Evan Laforge wrote: Mmm, it probably could by replacing popen() with pipe()'s and fork()/exec(), with select() to watch the stdout/err pipe, and trapping keystrokes yourself and sending them to the stdin pipe. Tricky though. I'd do it myself, but this week is nuts for me schedule wise. Don't you need a pty for that? Nah, not for simple stdio. Depends on what Matt needs it for though. I've done quite a few apps that interact with each other bidirectionally thru pipes and over serial with the tty stuff turned off. As long as you don't deadlock, you're good. (non-blocking IO is the key there, or threads). If you're just moving characters back and forth, pty isn't needed. Even ansi and cursor positioning can all be done without a pty. But if you're interacting with programs that assume a tty, like vi or emacs, or programs that are curses based or use terminal ioctl()'s, then you do usually need a pty or they won't act well. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.bugs] [MOD] STR #2704: Fl_Text_Editor: text cursor 'disappears' when buffer()-remove() is used
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2704 Version: 1.3.0 Oh, getting this on both OSX 10.6.8 and centos 5.5 with 1.3.x current (r9010). Link: http://www.fltk.org/str.php?L2704 Version: 1.3.0 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2704: Fl_Text_Editor: text cursor 'disappears' when buffer()-remove() is used
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2704
Version: 1.3.0
Attached file cursor-problem-v2.cxx...
Link: http://www.fltk.org/str.php?L2704
Version: 1.3.0#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Input.H
#include FL/Fl_Text_Editor.H
#include FL/Fl_Text_Buffer.H
class MyOneLineInput : public Fl_Text_Editor {
// Example: prevent user from hitting 'Enter' by deleting it as soon as
it's typed.
static void ModifyCallback(int pos, int nins, int ndel, int nrest, const
char *deltext, void *cbdata) {
MyOneLineInput *edit = (MyOneLineInput*)cbdata;
if ( nins 0 edit-buffer()-text()[pos] == 10 ) { // disallow
typing of CR
int pos = edit-insert_position(); // save insert
position
edit-buffer()-remove(pos,pos+1);
edit-insert_position(pos); // restore
insert position
/*** NONE OF THIS SEEMS TO HELP
Fl::focus(edit);
edit-insert_position(1);
edit-show_cursor(1);
edit-cursor_style(NORMAL_CURSOR);
edit-cursor_color(FL_BLACK);
***/
}
}
public:
MyOneLineInput(int X,int Y,int W,int H,const char *L=0) :
Fl_Text_Editor(X,Y,W,H,L) {
buffer(new Fl_Text_Buffer()); // set
up buffer
buffer()-add_modify_callback(ModifyCallback, (void*)this); // set
up mod callback
}
void value(const char *s) {
buffer()-text(s);
}
const char *value(void) const {
return(buffer()-text());
}
};
int main(int argc, char **argv) {
Fl_Double_Window *main_win = new Fl_Double_Window(460, 496, Tiled Window);
MyOneLineInput *in = new MyOneLineInput(140,10,300,70,MyOneLineInput);
main_win-resizable(main_win);
main_win-show(argc, argv);
return Fl::run();
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2699: fltk 1.3 e.g fullscreen border off disappeared after Alt-Tab
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2699 Version: 1.3-current Matt: can I close this bug? Seems more like a behavior of windows. If there's a way to control it and is something we should add to FLTK, then I guess it can be changed to an RFE. Link: http://www.fltk.org/str.php?L2699 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2699: fltk 1.3 e.g fullscreen border off disappeared after Alt-Tab
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2699 Version: 1.3-current Cannot replicate with win7 + VS 2010 Express. If I Alt-Tab to another application, the borderless 'fullscreen' application remains. Are you sure you're not Alt-Tab'ing to the 'Desktop', which causes Win7 to stow /all/ applications? That's the only way I can seem to replicate the behavior you're describing, which sounds more like a feature of Win7; a means to access an empty desktop via Alt-Tab by having it stow all applications. If that's not it, check the task manager to see if the program is still running when it disappears. Also, check if it disappears from the Alt-Tab menu. Link: http://www.fltk.org/str.php?L2699 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2699: fltk 1.3 e.g fullscreen border off disappeared after Alt-Tab
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2699 Version: 1.3-current Right, which sounds normal; borderless windows don't appear in Alt-Tab or the taskbar. If you restore the border, it will re-appear in both. I notice this with splash banners on programs where they toss up a borderless window while coming up, and these don't appear in the taskbar or alt-tab either. I think I can close this as not a bug, but will await your feedback. Link: http://www.fltk.org/str.php?L2699 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.general] Resizing behaviour of nested widgets
On 08/23/11 03:14, MacArthur, Ian (SELEX GALILEO, UK) wrote: See below - based on Greg's suggestion to use a tile Looks like we both wrote the same code. Interesting to compare the two programs. For the lulz, I decided to score based on coding practice: GE IM -- -- +1 - shortness of example code +1 - avoided globals +1 - dynamic menubar +1 - all groups indented (including tile) +1 - xywh value clarity +1 - look of resulting interface +1 - consistent widget UI labeling +1 - compile docs +1 - end()ed window +1 - all OP's widgets demonstrated +1 - use of double window to avoid flicker -- -- 4 7 Damn, I never tested well. ;) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Automatic adding of children to FLTK groups
On 08/22/11 00:29, Matthias Melcher wrote: If you end() the parent window, for instance, then widgets will be created but not attached to a parent [..] No, sorry, that's not true. Fl_Group::end() basically calls begin() on the parent group Well, kinda. If end() is called on the *parent window*, this effectively calls current(0), because its parent() will be 0. But it's true for the general case, calling w-end() won't disable the parenting stuff if 'w' is itself a child of something else. The only way to temporarily disable auto-adding is calling Fl_Group::current(0L) right after creating any group style widget. Yes, that's probably more correct for the general case. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Resizing behaviour of nested widgets
On 08/22/11 14:49, Jeff Paranich wrote: Hi All, I've read Article 415: How Does Resizing Work? and have been battling with trying to get one of my windows to behave how I'd like. I have done a mock sketch of my interface... it can be viewed here: http://i56.tinypic.com/2i94b4z.png The behavior I'm seeking may not be possible in FLTK, but I was hoping that in the picture where Fl_Hold_Browser is located, that the right-face of the widget (highlighted in yellow) would be clickable and could be resized horizontally, and in doing so Fl_Box, Fl_Table_Row, and Fl_Text_Display would be compressed. And with this functionality, Fl_Window should still be resizable however when resized Fl_Hold_Browser would remain horizontally fixed but can stretch vertically, and all other widgets resize both horizontally and vertically. Hope this makes sense. Is this or something very similar achievable? Sounds like you should use Fl_Tile to manage the resizable aspect in this case. I'd suggest putting all that stuff to the right of the yellow bar in a group, and make an Fl_Tile that contains the hold browser (left of yellow bar) and the aforementioned group (to the right of the yellow bar), and have the edges common so that when you glide over the border between the two, Fl_Tile will let you interactively resize them. Here's an example of using Fl_Tile to resize between 4 different widgets (in your case you'd only want two): http://seriss.com/people/erco/fltk/#GL4PortResizable ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Resizing behaviour of nested widgets
On 08/22/11 18:31, Greg Ercolano wrote:
On 08/22/11 14:49, Jeff Paranich wrote:
Hi All,
I've read Article 415: How Does Resizing Work? and have been battling with
trying to get one of my windows to behave how I'd like. I have done a mock
sketch of my interface... it can be viewed here:
http://i56.tinypic.com/2i94b4z.png
The behavior I'm seeking may not be possible in FLTK, but I was hoping that
in the picture where Fl_Hold_Browser is located, that the right-face of the
widget (highlighted in yellow) would be clickable and could be resized
horizontally, and in doing so Fl_Box, Fl_Table_Row, and Fl_Text_Display
would be compressed. And with this functionality, Fl_Window should still be
resizable however when resized Fl_Hold_Browser would remain horizontally
fixed but can stretch vertically, and all other widgets resize both
horizontally and vertically.
Hope this makes sense. Is this or something very similar achievable?
Sounds like you should use Fl_Tile to manage the resizable aspect
in this case.
I'd suggest putting all that stuff to the right of the yellow bar
in a group, and make an Fl_Tile that contains the hold browser (left of
yellow bar)
and the aforementioned group (to the right of the yellow bar), and have
the edges common so that when you glide over the border between the two,
Fl_Tile will let you interactively resize them.
Here's the above implemented as code.
To get Fl_Tile to act as a resizer, it's important that the tile's
two children (the hold browser and the group) have their common edges
/touching/ each other. This causes Fl_Tile to make this boundary mouse
sensitive to interactive resizing.
I was lazy and left out the two widgets at the lower-right, cause
their behavior will just be an extension of the others.
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Group.H
#include FL/Fl_Tile.H
#include FL/Fl_Menu_Bar.H
#include FL/Fl_Box.H
#include FL/Fl_Table_Row.H
#include FL/Fl_Text_Display.H
#include FL/Fl_Hold_Browser.H
int main() {
Fl_Window *win = new Fl_Window(400,500);
Fl_Menu_Bar *menu = new Fl_Menu_Bar(0,0,400,25);
menu-add(File/Foo);
menu-add(Edit/Bar);
Fl_Tile *tile = new Fl_Tile(10,menu-y()+menu-h()+10,
400-20, 500-(menu-y()+menu-h()+10)-10);
tile-box(FL_FLAT_BOX);
tile-color(9);
tile-begin();
Fl_Hold_Browser *hold = new Fl_Hold_Browser(10,40,150-10,500-40-10);
hold-add(One);
hold-add(Two);
hold-add(Three);
Fl_Group *group = new Fl_Group(150,40,400-150-10, 500-40-10);
group-box(FL_FLAT_BOX);
group-color(FL_BLUE+8);
group-begin();
Fl_Box *box = new
Fl_Box(group-x()+10,40,400-(group-x()+10)-10,25,Fl_Box);
box-align(FL_ALIGN_INSIDE|FL_ALIGN_CENTER);
box-box(FL_FLAT_BOX);
box-color(FL_GREEN+8);
Fl_Table_Row *table = new Fl_Table_Row(box-x(),
box-y()+box-h()+10,
box-w(),
group-h()-(box-h()+10));
group-end();
group-resizable(table);
tile-end();
win-resizable(tile);
win-show();
return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] dynamic gui widgets
On 08/21/11 09:06, asif saeed wrote: Is there any code example illustrating constructing an FLTK based GUI dynamically? Particularly, the menu bar/menus/menu items? Can you provide any guidelines as to how to proceed in this direction? See the fltk 1.3.0 example/menubar-add.cxx which shows how to dynamically construct a menu bar, and also how to dynamically change an item's state using find_item(). Also, there's several Fl_Menu oriented examples on my cheat page, in particular: http://seriss.com/people/erco/fltk/#Menu_ChangeLabel find_item() can be used to find an item pointer by its 'pathname'; once you have the item's pointer, you can mess around with its contents using the Fl_Menu_Item methods (see the docs). Conversely, item_path() can be used to convert an item back into a pathname. If you ^F search the cheat page for Fl_Menu, you'll find other insights as well on working with Fl_Menu and its derivatives (such as Fl_Menu_Bar) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Automatic adding of children to FLTK groups
On 08/21/11 09:22, asif saeed wrote: Hi, Is there any way I could prevent my widgets from getting added to fltk groups automatically and have the ability to add fltk widgets to fltk groups myself - dynamically? begin() and end() are the way to control this. If you end() the parent window, for instance, then widgets will be created but not attached to a parent, in which case to attach them, you can use the appropriate Fl_Group::add(Fl_Widget*) to parent them, which is something you should do quickly, otherwise the widget might pop up in a window of its own. When I want to add widgets, I usually call the parent's begin(), then create the widget, then call the parent's end(). If I don't want the widget to show up right away, I'd call hide() to hide it from being shown, then later call show() to show it. If you're trying to create a bunch of widgets that you want to be able to re-parent from one widget to another, you should be able to use Fl_Group::remove() and Fl_Group::add() to move the widgets around. Note that Fl_Window derives from Fl_Group, so the add()/remove() methods mentioned above applies to windows too. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] some doubt
On 08/19/11 08:00, Chris wrote:
this-win-label(TEST);
First: is it correct to set the label inside the constructor
or is the space for TEST released at the end of function?
Yes, that's fine.
All quoted strings are static, so it survives
the entire program's execution.
Static strings are not allocated or freed the way
dynamic memory is; static data is compiled into the
executable, so it's there for as long as the executable
runs.
Second: is it the right way to release win (and it's child) with the call in
the destructor?
Normally the way to do this would be to derive Test
from Fl_Window, so that the widget's destructor gets
called automatically. eg:
class Test : public Fl_Window {
Fl_Multiline_Output *output;
public:
Test(int X,int Y,int W,int H):Fl_Window(X,Y,W,H) {
label(TEST);
begin();
output = new Fl_Multiline_Output(0,20,250,150);
end();
show();
}
~Test() {
// fltk will handle the widget destructions.
// the only code you need here is to destroy non-fltk stuff,
// which in this case is nothing
}
}
That said, you can probably do it your way, perhaps someone
else can weigh in on that.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Problem with Fl_Double_Window
On 08/19/11 03:47, PARAJU wrote: I made a program using the class Fl_Double_Window to make a graph, the problem is that when I open and close a window of another program, a part of my graphic disappears. But when I use the Fl_Window class, do not. What could be happening? To rule out it being a graphics driver problem, try compiling this simple example, and see if it you get the same problem: http://seriss.com/people/erco/fltk/#FltkX If you do get the problem, it might be an issue either with the graphics driver, window manager, FLTK, or some such. If you don't get the problem, then it might be your program; make sure your widget sizes are right, that all child widgets are within the bounds of their parents, and that you're not drawing outside of your widget's xywh extents. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] Fl_Button::activate() doesn't
Please do not post general questions here. Post to fltk.general. This list is for bug reports generated by the automated STR system only. Sorry for the confusion. ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.general] Fl_Tree does not display widgets correctly
On 08/16/11 00:25, Julian Schindler wrote:
1. When adding some more items to the tree (more than matching into a window)
and adding a widget to each of them, the visualization is not correct, as the
items are displayed outside the tree. The simply are added below the others,
not taking into account the end of the Fl_Tree widget.
Can you show some code demonstrating this?
I can't quite tell what you mean here.
Not surprised there might be problems with
grouping widgets into the tree; the tree widget is
new in this release, and in particular, parenting widgets
to the tree is not well tested.
2. When scrolling, all the items with widgets disappear. They are simply not
drawn, but can still be clicked. When doing so, they reappear magically. But
when clicking on other items, they disappear again.
You can test that behaviour when simply adding this to the test/tree.cxx
I modified your example a little, which seems to work for me:
// Add 500 items in numerical order
tree-sortorder(FL_TREE_SORT_NONE);
for ( int t=0; t500; t++ ) {
static char s[80];
sprintf(s, 500 Items/item %04d, t);
Fl_Tree_Item *i = tree-add(s);
tree-begin(); // -- ensure new
group parented to tree
Fl_Group *grp = new Fl_Group(0,0,140,18); // make group at 0,0
grp-begin();
Fl_Button *abut = new Fl_Button(0,2,65,15); // ensure x/y is
within group
sprintf(s, A-%04d, t); abut-copy_label(s); // unique label
abut-labelsize(10);
abut-callback(Button_CB);
Fl_Button *bbut = new Fl_Button(75,2,65,15);// ensure x/y is
within group
sprintf(s, B-%04d, t); bbut-copy_label(s); // unique label
bbut-labelsize(10);
bbut-callback(Button_CB);
grp-end();
grp-resizable(grp);
i-widget(grp);
tree-end();
}
The main thing being adding tree-begin() and tree-end()
around each child group creation that's assigned to each item.
This was just to make it consistent with the other working code
in the example that shows parenting buttons into the tree.
I changed a few other things to suit my taste for debugging,
but probably aren't necessary to make it work; made the labels
of the buttons unique to check they were showing up correctly,
and changed the coordinate space of the group and buttons
to be 0,0 to simplify the positioning math.
// Add 500 items in numerical order
tree-sortorder(FL_TREE_SORT_NONE);
for ( int t=0; t500; t++ ) {
static char s[80];
sprintf(s, 500 Items/item %04d, t);
Fl_Tree_Item *i = tree-add(s);
static Fl_Group *grp[500];
grp[t] = new Fl_Group(100,100,140,18); // build group.. tree
handles position
grp[t]-color(FL_WHITE);
grp[t]-begin();
Fl_Button *abut = new Fl_Button(grp[t]-x()+0
,grp[t]-y()+2,65,15,D1);
abut-labelsize(10);
abut-callback(Button_CB);
Fl_Button *bbut = new
Fl_Button(grp[t]-x()+75,grp[t]-y()+2,65,15,D2);
bbut-labelsize(10);
bbut-callback(Button_CB);
grp[t]-end();
grp[t]-resizable(grp[t]);
i-widget(grp[t]);
}
3. I wanted to have a widget added to an item with the exact width
of the item from the tree structure on the left to the slider on the right.
I hoped to get that size with Fl_Tree_Item::w(), but unfortunately this
function always returns 0. Esp. when the resize function is called
(e.g. when scrolling), the width argument of it is always 0 as well.
So how can I get the width?
Again, can you include a small compilable example showing how
you're getting the width of the item?
I believe the widths are calculated when the widget is draw()n,
so if you're calling it before it's drawn, that might be the issue.
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [OT] Siggraph/Vancouver
On 8/11/11 1:37 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: Congratulations on the the Academy Award btw.! Ah, you found out my secret ;) Sure - but you did put it up on your news page, so not all that much of a secret... LOL, I wouldn't have guessed anyone on FLTK keeps up with my render queue pages. (The page maybe needs updated a bit, BTW? Copyright says 2009, and the download button references 102.42a9c event though 102.42a9d appears to be current...) Thanks -- I figure as long as I'm within 75 years or so, I'm safe with the copyright banners. ;) Regarding a9c vs a9d, like FLTK's releases, it's complicated. a9c is still the current release, a9d was a fix release only for the mac. Never bothered to rebuild the other platform releases for a9d because there's zero changes on those. Oh, and Congratulations! Thanks! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] how to erase line
On 8/11/11 9:50 AM, ahmad wrote: Hello: can someone please tell me how to do you erase a line with a use of a button. For example if I have drawn 5 lines but the fifth line is icorrect, I would like to erase it. Need more info. What widget is drawing the lines, is it a label() or the contents of an Fl_Text_Editor, or are you using fl_draw(), or..? If you're drawing text with fl_draw(), you'd call redraw() on the parent window (so that the entire background redraws) then draw the correct 5 lines. Or you can draw an fl_rectf() over the old 5 lines and draw the correct 4. If you're using a label(), I'd do the redraw() on the parent window followed by changing the label text. If you're using Fl_Text_Editor and friends, you'd use the edit methods in that widget. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.development] [OT] Siggraph/Vancouver
Any of you FLTK devs at Siggraph this week? If so, hit me up on email 'n we can haz cheezburgerz ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [OT] Siggraph/Vancouver
On 8/10/11 10:32 AM, Matthias Melcher wrote: On 10.08.2011, at 14:36, Greg Ercolano wrote: Any of you FLTK devs at Siggraph this week? If so, hit me up on email 'n we can haz cheezburgerz Aw man! I would love to, but I have not been at Siggraph *forever*. Sigh. I always loved that show. Plus Vancouver's nice! Yes, good show, lots of good films and masterful work. CG is really showing it's maturity and quality of work. Are you going to promote Rush? Ha, I think it's the other way around; it seems to promote me ;) Congratulations on the the Academy Award btw.! Ah, you found out my secret ;) Thanks! It's been a trip -- red carpet, cameras, interviews, penguin suit and everything. The recognition is quite an honor. Can we now say that FLTK has won two Academy Awards? ;-) Yes, I'd say so..! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Launching web browser from fltk
On 8/10/11 1:51 AM, Stuart Shepherd wrote:
do you know if it is possible to have some clickable text
as part of a label and when you click it
Yes, if the label is instead a sufficiently disguised
Fl_Help_View (or similar), then it will work in 1.3.0, eg:
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Help_View.H
int main() {
Fl_Window win(300,200);
win.color(0xbb00);
Fl_Help_View html(10,10,300-20,25);
html.value(BODY BGCOLOR=#bb
This is a link to a href='http://google.com'google/a.);
html.box(FL_FLAT_BOX); // hide box around help widget
html.Fl_Group::child(0)-hide();// XXX: hide scrollbar
win.end();
win.show();
return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
[fltk.development] fl_xid() -- needs docs?
After reading STR #2696 http://www.fltk.org/str.php?L2696 it sounded like we should add some docs for fl_xid() to mention the need for apps to #define FL_INTERNALS. I'm not sure what to write or I'd write it. Looks like documenation/src/osissues.dox is the file where fl_xid() is documented, and where clarifications could be made. FWIW, there is a tiny 'Note' in the docs about FL_INTERNALS, but it's floating in the middle of the osissues.html page where I think few would find it: http://fltk.org/doc-1.3/osissues.html ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] command line options error
On 08/04/11 00:43, asif saeed wrote: Is there any way to eliminate the fltk command-line options error dialog? You can either replace: window-show(argc,argv); ..with just: window-show(); Or, if you want to be able to pass FLTK arguments along with your own, you can use the technique shown in the FLTK 1.3.0 examples directory (e.g. examples/howto-parse-args.cxx) ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] best way to view html in my app
On 08/01/11 15:46, Andrew Waldrum wrote: I am trying to add an help/instruction widget to my application and am having some trouble with the Fl_Help_View http://www.fltk.org/doc-1.3/classFl__Help__View.html in 1.3. It renders my page, kind of, but hotlinks do not work and images(neither png nor gif) show up. All I really need is basic formating, links, and images of some kind. According to the online documentation FL_Help_View supports Most HTML 2.0, including png and gif image formats. I am using the latest Ubuntu 10.04 with either Gnome or E16 window manager. By hotlinks, do you mean http:// links? If so, Fl_Help_View only supports online documentation internally (eg. file:// urls), and IIRC any http:// style links call call fl_open_uri() to resolve, which under linux currently tries to fork() off one of these commands to handle web browsing (I believe in this order): xdg-open, // Portland htmlview, // Freedesktop.org firefox, mozilla, netscape, konqueror, // KDE opera, hotjava, // Solaris mosaic, So long story short, you'll need one of those installed on your OS to have it resolve http: style links. Or, I imagine you can hack the src/fl_open_uri.cxx file to include other options. Unfortunately the target system is stripped down so having a browser external to the application is probably not an option. Any ideas? I don't think there's a solution unless you change the code. Perhaps you can hack Fl_Help_View to fire off curl(1) or GET(1) or one of those web retrieval tools, so that the URL first pulls the file local, then opens it in Fl_Help_View either as an in memory string, or a temp file on disk. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] *crickets*
Posting just to make sure the group is still working.. Everyone must be bbq'ing or something. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK 1.3 and Mac OS X Lion
On 07/25/11 02:27, Matthias Melcher wrote: 2: This one is big! Apple has gone the Microsoft path and finally allows resizing of windows from every corner and side! It's about time! :D With that, I'd almost consider using OSX as a workstation. But lack of 'focus follows mouse' will probably always hold me back. (I don't think Apple can ever support it if they stick with that global main menu bar) The little engraved bottom right corner on resizable windows is now gone. W00t! Always hated that thing.. FLTK still draws it though, and we should consider removing it if an app runs on OS X Lion or better, and keep if for SL and earlier. +1 ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Table::add() doesn't work properly?
On 07/21/11 14:16, Percy wrote:
Hi, I'm using FLTK 1.3.x r8861 with VS2008. I'm having a lot of trouble
working with the Fl_Table class' add function. Here's some code:
Fl_Window win( 800, 600, Window );
win.end();
// MyTable inherits from Fl_Table
MyTable* t = new MyTable( 400, 0, 400, 600 );
t-end();
win.add( t );
t-rows( 10 );
t-cols( 2 );
for ( int r = 0; r t-rows(); r++ )
{
for ( int c = 0; c t-cols(); c++ )
{
int X,Y,W,H;
t-cell_dimensions( r, c, X, Y, W, H );
Fl_Widget* w = new Fl_Button( X, Y, W, H, Table Widget );
t-add( w );
}
}
//t-end(); // if I add this line, it works, even though t-end() was
already called
win.resizable( win );
win.show();
return Fl::run();
I can get this to work normally if I use the normal begin()-end() setup or if
(for some reason) I add the the extra t-end(). It seems as though add() does
not work. I know that begin() and end() work, but for my particular
application, add() is much more convinient.
And just to clarify, MyTable overrides only the constructor, destructor and
draw_cell. If also has a public function cell_dimensions, which simply calls
find_cell.
Can I see a more complete, compilable program so that I can replicate.
eg. the complete definition of the MyTable class, including the definition
of the method cell_dimensions().
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Table::add() doesn't work properly?
Hmm, I think I see the problem.
In short, the following patch to Fl_Table.H should solve it.
I've applied this patch as svn r8868.
Index: FL/Fl_Table.H
===
--- FL/Fl_Table.H (revision 8865)
+++ FL/Fl_Table.H (working copy)
@@ -854,9 +854,14 @@
}
void add(Fl_Widget w) {
table-add(w);
+if ( table-children() 2 ) {
+ table-show();
+} else {
+ table-hide();
+}
}
void add(Fl_Widget* w) {
-table-add(w);
+add(*w);
}
void insert(Fl_Widget w, int n) {
table-insert(w,n);
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Table::add() doesn't work properly?
FWIW, here's a (compilable) test program similar to your
code snippet I was using to test your issue.
Note the -- comment below, as well as the additional
calls to col_width_all() and row_height_all(), which I'd
recommend you use, so that the table knows the width/height
of your child widgets.
-
#include stdio.h
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Button.H
#include FL/Fl_Table.H
class MyTable : public Fl_Table {
protected:
void draw_cell(TableContext context, int R=0, int C=0, int X=0, int Y=0, int
W=0, int H=0) {
switch ( context ) {
case CONTEXT_STARTPAGE:
break;
case CONTEXT_RC_RESIZE: {
int X, Y, W, H;
int index = 0;
for ( int r = 0; rrows(); r++ ) {
for ( int c = 0; ccols(); c++ ) {
if ( index = children() ) break;
find_cell(CONTEXT_TABLE, r, c, X, Y, W, H);
child(index++)-resize(X,Y,W,H);
}
}
init_sizes(); // tell group children resized
return;
}
case CONTEXT_CELL:
return; // fltk handles drawing the widgets
default:
return;
}
}
public:
MyTable(int x, int y, int w, int h, const char *l=0) : Fl_Table(x,y,w,h,l) {
end();
}
~MyTable() { }
};
int main() {
Fl_Double_Window win(800, 600, Window);
win.end();
MyTable *t = new MyTable(400, 0, 400, 600);
t-end();
win.add(t);
t-cols(2);
t-rows(10);
t-col_width_all(200); // set column widths
t-row_height_all(25); // set row heights
for ( int c = 0; c t-cols(); c++ ) {
for ( int r = 0; r t-rows(); r++ ) {
int X,Y,W,H;
W = t-col_width(c);
H = t-row_height(r);
X = t-x() + (c * W);
Y = t-y() + (r * H);
Fl_Button *b = new Fl_Button(X, Y, W, H, Table Widget);
t-add(b);
}
}
t-show();// -- IF ABOVE PATCH IS APPLIED, CAN COMMENT THIS OUT
win.resizable(t);
win.show();
return(Fl::run());
}
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Add a controllable timeout
On 07/21/11 04:45, Paul R wrote:
Hi all, i am a bit stuck with a program that is running far too fast
it is an 3d implementation on the game of life and i am not sure where
and or how to place fl timeouts, or even if that is the right option.
First: short answer, if your program is already written
like your example, just change the Fl::check() to Fl::wait(0.1)
and you're done. No timeout code needed.
However, if you want to use timeouts, and want to rewrite
your app to be more like most GUI apps that are 'callback'
oriented, you'd have to change your program around a bit
to be more like a regular GUI 'callback' app, eg:
class YourWindow : public Fl_Window {
float speed;
YourWindow(..) {// CTOR
..add sliders, init variables, whatever..
speed = 0.1;
Fl::add_timeout(speed, TimerCallback);
}
void TimerCallback(..) {// invoked when timer goes off
CalculateWorld();
redraw();
Fl::repeat_timeout(speed, CalculateWorld);
}
void CalculateWorld() {
..your calculations..
}
void draw() {
..your draw code..
}
};
main() {
YourWindow win(..);
return(Fl::run());
}
For an example of this, see:
http://seriss.com/people/erco/fltk/#AnimateDrawing
..which shows how to draw a clock's second hand
at almost exact 1.0 second intervals.
In that example, the calculation (sin/cos) is done in
the draw() routine.
But if your app works with an array of data,
you could do your calculation in the timer routine
so that the draw() code just draws the array.
This keeps your calculation code separate from the draw() code.
Either way, the timer callback should always finish
by calling redraw() and repeating the timeout
before returning to the app loop so it can call draw(),
and later invoke the next timer callback.
To make the speed adjustable, add a slider with a callback
that adjusts the speed variable, and use the speed variable
in the add_timeout/repeat_timeout calls.
That's the normal way to write GUI applications; with
callbacks, and surrendering to FLTK's 'application loop'
Fl::run() to handle all execution of your app. The app
spends most of its time waiting, the timer basically
keeps the app 'alive', giving you cpu every 1/10th of
a second (due to the 0.1 in the timer calls).
The way the machine actually runs your app would be:
FLTK run() loop (waits for stuff to happen)
|
\|/
0.1 timer goes off, invokes
your timer callback --- YourTimerCallback()
|
you do calculations
|
you call redraw() which schedules next draw
|
you call repeat_timeout to schedule next timer event
|
|--- you return
|
\|/
FLTK run() loop continues
|
\|/
FLTK sees redraw() scheduled,
calls your draw() --- draw()
|
you draw stuff
|
| you return
|
\|/
FLTK run() loop continues
|
(back to top)
But if you want to do it this way:
void UpdateWorld()
{
while(running)
{
//code to examine each cell and determine its status
//
//
Fl::check();
if(running) //button callback controls bool member
DrawWorld(); //step through arrays drawing live cells or not
//includes call to cellGrp-redraw()before returns
}
}
..then you don't really need add_timeout/repeat_timeout,
just change the Fl::check() line to Fl::wait(0.1) instead.
To make the time adjustable, make the 0.1 a variable,
and add a slider that invokes a callback to adjust the variable.
Either way should work. If your app is already written
with the above while(running) loop, it's probably easiest
to change Fl::check() to Fl::wait(0.1).
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Add a controllable timeout
On 07/21/11 06:01, Greg Ercolano wrote: Fl::repeat_timeout(speed, CalculateWorld); Oops, that line should have been: Fl::repeat_timeout(speed, TimerCallback); Also, I see it took so long to write my last post, that in the mean time you already had an exchange with ian.. that'll teach me to write long posts..! ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Can't get text working
On 07/21/11 04:27, Stuart Shepherd wrote: Thanks for all your replies. I'm as sure as I can be that I have the fonts installed, and that nanoX and nxlib are pointed to the right place to find them. I have complied without xft and with, made no difference. The thing that is confusing me most is that the symbols didn't work if I tried to display @cirlce that wouldn't work either, that can't be a font issue surely? Would that be a problem with nanoX being non standard? Also if I wrote nanoX programs they would display text no problem. Next week I will try using kdrive instead of nanoX and see if that works. If you still have trouble, I'd suggest drilling down into the fltk code, and try finding the font calls to the OS. Make sure the font calls are doing error checking, and if not, add checks for failures and print diagnostics; this might lead you to where the problem is occurring. There are probably several files to check; fl_font_x.cxx (for the regular X font stuff), fl_font_xft.cxx (for the antialiased xft stuff), perhaps Fl_x.cxx, and not sure what all else. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] src/scandir.c
On 07/20/11 03:14, Albrecht Schlosser wrote: On 20.07.2011 10:04, MacArthur, Ian (SELEX GALILEO, UK) wrote: Agreed, but then we might have to maintain dead code, and given the complexity of all that #if HAVE_something stuff, i'd like to remove it for all times... Suggest we comment out the file and see what happens. To prevent having to modify all the Makefile/VS files, I'd recommend we just change the file to be a one line comment that says '// Removed due to non-LGPL/static license. See STR# . Original in svn r.' and if we find it's needed, we can revert to r and re-implement an equivalent. Or, remove just the code but leave the #ifdef's in place and add a #warning or #error macro that gets triggered if built on the magic platform that turns out to need this, and have the error mention the above comment. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Input_Choice suggestions
On 07/20/11 02:11, MacArthur, Ian (SELEX GALILEO, UK) wrote: Pretty sure the others would have no impact. I think adding new methods is OK. (But see above!) Does it change the size of the class though? No changes in size, just adding code. Changing the return value might be processor dependent, I'm not sure. Some compilers might return the integer in a register, some might return it through the stack. Thing is any existing code wouldn't look at the return value because its been 'void' to date, so I'm thinking if no code checks it, nothing breaks. If it's too dicey, making that change can wait for 1.4. b) Assuming no ABI issues, any other objections? Sounds good to have - but might have to be 1.4 for now? Yes, for anything that affects the ABI I could delay for 1.4. The others that don't can probably fit into 1.3.1 I'm thinking. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.bugs] [HIGH] STR #2687: src/scandir.c should probably be removed or rewritten
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 The issue being this appears to be GPL code that is probably not compatible with our LGPL/static exception. There's some question as to what platform(s) trigger using this code. Submitting this STR so we don't forget to follow through on investigation. Marking this high in priority, since it should probably hold a 1.3.1 release for resolution. Link: http://www.fltk.org/str.php?L2687 Version: 1.3.1 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] LGPL question
Great, I've made STR#2685 and assigning it to myself.
Big thank you for volunteering for such a big task. One question
though: are we (you) going to do this for 1.3, 3.0, or both? ;-)
I guess both in the longer term, but we do 1.3 first... and it appears
Greg would agree, as he's taken a big chunk out of the 1.3 ones already!
Right -- I think I got em all in 1.3.
It's a little tricky, cause there's different comment styles
('#', '*', //, dnl..), licenses that are part of code
(fluid/comments.h) and different copyright notices to keep intact.
Have to avoid editing the .svn files (grep -v /\.svn/).
So it was basically one big vi/grep command line, and a some
lot of c14j's
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LGPL question
On 07/19/11 05:52, Greg Ercolano wrote: Great, I've made STR#2685 and assigning it to myself. Big thank you for volunteering for such a big task. One question though: are we (you) going to do this for 1.3, 3.0, or both? ;-) I guess both in the longer term, but we do 1.3 first... and it appears Greg would agree, as he's taken a big chunk out of the 1.3 ones already! Right -- I think I got em all in 1.3. [ah, disregard last post. Was using the web form instead of my usual newsreader, and of course I typed a tab+space which posted the text while I was editing.. meh. Probably a big cause of the multiple posts we see from new users] For anyone doing this in the future, some breadcrumbs: I think my favorite 'do everything' command was something like: vi `grep -r //.This.library.is.free . | grep -v /\.svn/ | grep -v Binary | cut -d: -f1 | uniq` ..and using a repeat (.) of a c14j command to change the 14 lines of the license header to the new text, and a keyboard macro for :w and :n. So pretty much it was hitting two keys to edit each file, and adjusting the macro a bit when files differed. The rest is just eye-balling to make sure the edit looks right, (since license formats and commenting styles differed a bit). Then ran a 'grep -r WARRANTY' (the text I removed) to make sure there weren't any un-edited stragglers. The different comment styles I encountered were '#', '*', //, dnl (Makefiles, C files, C++ files, and doxygen or something for dnl) There were a few others. Did a little at a time, then did something else, then did a little more. Then did a few 'svn diff' checks to make sure things looked right. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] src/scandir.c
On 07/19/11 08:14, MacArthur, Ian (SELEX GALILEO, UK) wrote: I just tried a test on linux + osx where I removed the file and ran a 'make clean; make'. The build stopped at that file on both platforms, so it *is* getting linked on normal builds. Seems like we gotta fix this. Bother. Did it choke because we *need* the file, or just 'cause it could not find it and the Makefile calls it up? The latter; I didn't try the former. My concern (as a commercial developer that releases static builds) is not whether the code is used, but that it's in the lib at all. True: if the code is not called, it shouldn't appear in the linked executables by optimization. And legally I imagine that's all that matters. And in my quick builds on linux, if I put some unique strings in the body of the scandir code and do a static build against the lib, I don't see that string in the executable, so offhand it seems app developers have nothing to worry about regarding released binaries. Still though, it should be fixed, by which I mean either rewritten or removed. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] src/scandir.c
On 07/19/11 07:56, Albrecht Schlosser wrote: On 19.07.2011 15:29, Greg Ercolano wrote: I just tried a test on linux + osx where I removed the file and ran a 'make clean; make'. The build stopped at that file on both platforms, so it *is* getting linked on normal builds. That's not a valid test[1]. Right, well sort of. Actually, my test was to see if it was referenced at all on build. The #ifdef's didn't matter to me, I just wanted to know if the code was completely unused (ie. not referenced by the builds). It is referenced, which means under 'some' circumstance it might be linked, and that concerned me. In the end, my real concern is whether the code is getting linked into any of my release binaries. Due to the #ifdef's it seems it's not (whew!), but I've only checked unix, haven't checked windows. The fact it's there at all means we should either remove or rewrite. Functionally the code simple and easily rewritten. I'd be happy to take a stab at it myself if no one else wants to. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fl_Input_Choice suggestions
Would like to suggest adding a few things to Fl_Input_Choice:
1) Change the existing method:
void add(const char *s) { menu_-add(s); }
to instead:
int add(const char *s) { return(menu_-add(s)); }
This corrects an omission, allowing the user to access
the integer value that is the index for the menu item.
2) Add an additional add() method with extra args:
/** Adds item \p name to the menu, with shortcut \p sc,
callback \p cb, optional callback data \p cbd (default 0),
and optional \p flags (default 0). For more info, see
Fl_Menu_::add().
\returns the integer index into the menu() array for the created
menu item.
**/
int add(const char *name, int sc, Fl_Callback *cb, void *cbd = 0, int
flags = 0) {
return(menu_-add(name,sc,cb,cbd,flags));
}
This gives the user to access all extended arguments of the
underlying menu widget, as well as avoiding the unusual behavior
of add(const char*) which interprets '|' like '/', only it cannot
be escaped. (An old FORMS holdover that should probably be
disabled..yuck!)
3) Add a size() method:
/** This returns the total menu items in the menu().
This includes the terminator item at the end.
See Fl_Menu_::size() for more info.
**/
int size() const { return(menu_-size()); }
This solves another omission which would allow the
caller to walk the menu() items by accessing its size.
A few questions:
a) Does (1) break the ABI (by changing the return value from void to int)?
Pretty sure the others would have no impact.
b) Assuming no ABI issues, any other objections?
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] src/scandir.c
[..] Made STR #2687 to track this issue. http://fltk.org/str.php?L2687 ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] How can I get system fonts and them sizes?
On 07/19/11 04:52, kdi...@live.ru wrote: MacArthur, Ian (SELEX GALILEO, UK) wrote: If I understand the question right, you are saying that if you post to the list from your email client, then your messages appear in the list OK, but you do not get a copy returned to you? No Ian! Anyway letters not comeing into my the mail-box (AND into forums of fltk) if I'm sending them not through a web form of forum. - My the letters are loseing somewhere (via mail-client). Not sure what the problem is with the email. You might try switching to using the NNTP access to the newsgroups instead. Outlook Express, Thunderbird, and Opera all have NNTP news readers built in, which IMHO are the best ways to read and post to the fltk groups. Just point your news reader at news://news.easysw.com/ and 'subscribe' to fltk.general, and whatever other groups. This way you can see all posts and reply easily. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] How can I get system fonts and them sizes?
On 07/19/11 08:16, kdi...@live.ru wrote: Do you want to receive messages that do not match any topic filter?: no I'm not sure, but try setting that option to 'yes'. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] smallest possible C++ subset for C programmers?
On 07/19/11 14:04, Patrick Mc(avery wrote: I don't really know much about the standard library, friend functions, overloading and exceptions but should I care? If I understand the C++ subset that deals with the above code am I pretty much ready good to go? Many folks in your position start with a simple program that kinda does what they want, then slowly get more involved as needed during the process of trying to get it to do what they want. Some folks fall down the rabbit hole and become C++ programmers, others try to keep a distance by partnering up with others, or hiring someone to write what they need. Indeed fltk itself doesn't use the more exotic C++ stuff like templates, exceptions, namespaces, RTTI. But I'd say understanding classes and class inheritance is fairly hard to avoid, just to understand how to read the docs. For instance, if you make a button, you'd have to know that it inherits from Fl_Widget, and that to find out how to change the label or color of the button, you'd need to know to look at the docs for Fl_Widget to find those methods (functions). I'd suggest taking a look at the FLTK video tutorials (just google for that and you should find them), and see if you get lost while watching. A lot of the C++ stuff is probably something you can pick up just by looking.. kinda like walking into the middle of a movie. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.bugs] [HIGH] STR #2683: Crash Fl_Text_Display when I'm calling disp-show_cursor(true);
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2683 Version: 1.3-current This is because the text buffer hasn't been assigned to the display yet when show_cursor() is being called. If you move the call to show_cursor() after disp-buffer(tbuff), it will work normally, eg: Fl_Text_Buffer *tbuff = new Fl_Text_Buffer(); // text buffer Fl_Text_Buffer *sbuff = new Fl_Text_Buffer(); // style buffer disp-buffer(tbuff); disp-show_cursor(true); // MOVE HERE To prevent this from crashing FLTK, tests could be added to check to see if buffer() is set, and if not, call the fatal error handler. But to work properly, the show_cursor() call still needs to be moved. Link: http://www.fltk.org/str.php?L2683 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2683: Crash Fl_Text_Display when I'm calling disp-show_cursor(true);
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New]
Link: http://www.fltk.org/str.php?L2683
Version: 1.3-current
Attached file show_cursor.patch...
Link: http://www.fltk.org/str.php?L2683
Version: 1.3-currentIndex: src/Fl_Text_Display.cxx
===
--- src/Fl_Text_Display.cxx (revision 8861)
+++ src/Fl_Text_Display.cxx (working copy)
@@ -615,6 +615,8 @@
*/
void Fl_Text_Display::show_cursor(int b) {
mCursorOn = b;
+ if (!buffer())
+Fl::fatal(Fl_Text_Display: show_cursor() called before buffer()
assigned);
redisplay_range(buffer()-prev_char_clipped(mCursorPos),
buffer()-next_char(mCursorPos));
}
___
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [HIGH] STR #2683: Crash Fl_Text_Display when I'm calling disp-show_cursor(true);
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2683 Version: 1.3-current Suggested patch attached. Or, modify docs for show_cusor() to indicate textbuffer() must first be set. Many other methods would need to be modified if we want this to be consistent. Not sure which is better; docs or code mod. Docs, probably. Link: http://www.fltk.org/str.php?L2683 Version: 1.3-current ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
[fltk.bugs] [MOD] STR #2685: Clarify LGPL license headers in all source code
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2685 Version: 1.3.1 The FLTK source code headers currently refer to the LGPL at GNU, which doesn't include the FLTK 'static link' exception. To clarify this, suggesting we modify all the FLTK source code headers to refer to the FLTK version of the LGPL, and not refer to gnu.org. The suggested change from Mike/Albrecht (07/18/11 on fltk.development): // Copyright 1998-2011 by Bill Spitzak and others. // // This library is free software. Distribution and use rights are outlined in // the file COPYING which should have been included with this file. If this // file is missing or damaged, see the license at: // // http://www.fltk.org/COPYING.php // // Please report all bugs and problems on the following page: // // http://www.fltk.org/str.php // Link: http://www.fltk.org/str.php?L2685 Version: 1.3.1 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2685: Clarify LGPL license headers in all source code
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2685 Version: 1.3.1 Link: http://www.fltk.org/str.php?L2685 Version: 1.3.1 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.bugs] [MOD] STR #2685: Clarify LGPL license headers in all source code
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2685 Version: 1.3.1 Applied as r8864, one giant code change. Link: http://www.fltk.org/str.php?L2685 Version: 1.3.1 ___ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
Re: [fltk.development] [RFE] STR #1725: FLTK2's FLUID (and FLTK lib) should handle better UTF8 input/output chars
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L1725 Version: 2.0-feature Fix Version: 2.0-feature Amy/cg.amit: the developers are wondering why you attached this very old (circa 2001) enumerations.H file to this FLTK 2.0 STR. Perhaps you meant to reply to another STR? If so, be sure to check you have the right enumerations.H file, as the one posted here appears to be very old (at least 10 years old) which probably isn't relevant to any of the supported versions of FLTK, unless there's something worth noting, in which case please include some text with details. Link: http://www.fltk.org/str.php?L1725 Version: 2.0-feature Fix Version: 2.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] src/scandir.c
Hmm, can someone check the LGPL header src/scandir.c? While doing the LGPL header mods for STR #2685, I noticed this file appears to be part of the GNU C Library, which may not be compat with the FLTK static LGPL exception. This code might need to be re-written. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] How can I get system fonts and them sizes?
On 07/18/11 20:39, Dmitrij K wrote: Hi there! It needs me for setup them in my apps... Which platform? If linux, try 'xfontsel' (old X font names) or 'fc-list' (newer names). Not sure about windows and osx; on those, I usually open a text editor or paint program and browse the font dialogs. ___ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] 1.3.0 ABI
On 07/16/11 20:57, Michael Sweet wrote: Yes, no incompatible ABI changes in patch releases (you could have a method that refers to the global default, but not add something to the class that would change the size...) If someone can supply the new text, I can do the footwork of the mega-diff. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2679: Fl_Table: this is patch is changeing size of scrollbar (for the size is takeing from scheme/theme, but do not from constant of source).
[STR Closed w/Resolution] Link: http://www.fltk.org/str.php?L2679 Version: 1.3-feature Fix Version: 1.3.1 (r8863) Fixed in Subversion repository. Link: http://www.fltk.org/str.php?L2679 Version: 1.3-feature Fix Version: 1.3.1 (r8863) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] [RFE] STR #2681: Fl_Table::scrollbar_size() method needed
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2681 Version: 1.4-feature Fl_Table needs a local scrollbar_size() method, similar to Fl_Tree, Fl_Browser, etc. Once added, adjust test/unittest_scrollbarsize.cxx to call this method. Implementing this will break the ABI, so needs to be implemented in 1.4.0. Release of 1.4.0 should be held for this fix. Link: http://www.fltk.org/str.php?L2681 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] 1.3.0 ABI
On 07/17/11 02:01, Albrecht Schlosser wrote: On 17.07.2011 08:24, Greg Ercolano wrote: On 07/16/11 20:57, Michael Sweet wrote: Yes, no incompatible ABI changes in patch releases (you could have a method that refers to the global default, but not add something to the class that would change the size...) If someone can supply the new text, I can do the footwork of the mega-diff. Hmm, I didn't understand this on my first reading, but then I realized that it was probably intended to be posted to the license thread LGPL question, right? Gak, yep. Will update that thread. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LGPL question
On 07/16/11 20:37, Michael Sweet wrote: We should drop the reference to gnu.org and just refer to it as the FLTK License... If someone can supply the new license text that we should use, I can do the footwork of the mega-diff. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2679: Fl_Table: this is patch ischangeing size of scrollbar (for the size is takeing from scheme/theme, but do not from constant of source).
On 07/16/11 06:15, Dmitrij K wrote: Albrecht Schlosser albrec...@go4more.de wrote: -#define SCROLLBAR_SIZE 16 +#define SCROLLBAR_SIZE (Fl::scrollbar_size()) Perhaps it will to have conflicts for names of variables from users (SCROLLBAR_SIZE), But maybe and not... It shouldn't conflict because the above #define is in the .cxx file, which is not exposed to users. If it had been in the .H file, then yes, that would be a conflict.. but not the case here, so Albrecht's suggestion would be OK. When the _scrollbar_size member is added, there would need to be some special logic when finding the scrollbar size to be consistent with the other widgets, eg: int actual_size = _scrollbar_size ? _scrollbar_size : Fl::scrollbar_size(); This allows the widget to have its own 'local' size for the scrollbar, or the default which would be _scrollbar_size being set to zero, using the global scrollbar size instead. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.general] Problem with Fl_PNG_Image and longfilename path(Windows XP)
Reposting the OP's code reformatted.
OP, why would you be specifying anything other than
the absolute path to the image?
You surely can't make assumptions about the current
working directory being set to anything in particular
unless you force it to be something specific with chdir().
snip
#include stdio.h
#include string.h
#include FL/Fl.H
#include FL/Fl_Double_Window.H
//#include FL/Fl_Scroll.H
#include FL/Fl_PNG_Image.H
// Test the Fl_OpDesk widget
#include Fl_OpDesk.H
#include Fl_OpBox.H
#include Fl_OpButton.H
int main() {
// If I specify the whole path for each image, everything works ok
Fl_PNG_Image
imagen(D:\\Tzarls\\Cpp\\Fl_OpDesk\\Fl_OpDesk\\Release\\mas.png);
Fl_PNG_Image
imagen2(D:\\Tzarls\\Cpp\\Fl_OpDesk\\Fl_OpDesk\\Release\\Gentoo-small.png);
// Comment out previous lines and uncomment these two lines; app won´t
work anymore,
// (unless you change the .exe file and the images to a folder with a
shorter path name)
//Fl_PNG_Image imagen(mas.png);
//Fl_PNG_Image imagen2(Gentoo-small.png);
Fl_Double_Window *win = new Fl_Double_Window(720,486);
// ... but if you comment all previous 4 Fl_PNG_Image lines and
uncomment these two,
// effectively placing them after the double window, it works again.
//Fl_PNG_Image imagen(mas.png);
//Fl_PNG_Image imagen2(Gentoo-small.png);
Fl_Group *g = new Fl_Group(10,10,win-w()-20,win-h()-20);
g-box(FL_DOWN_BOX);
const int deskw = 1500;
const int deskh = 1500;
// This is a class of mine (actually, a class made by Greg Ercolano).
// Weird thing is that, if I remove
//the following line, then the app will work ok no matter which one
// of the previous options you choose...
Fl_OpDesk *opdesk = new Fl_OpDesk(g-x() + 2,g-y() +
2,g-w()-4,g-h()-4);
// Yes, you could say that the problem is inside the Fl_OpDesk class,
// but if that was the case,
// then why by just changing the folder of a non-working version
// of the app it would start working again?
// BTW, every option works perfectly when running the debug app.
// The problem appears only for releases.
g-end();
win-resizable(g);
Fl::scheme(gtk+);
win-show();
return(Fl::run());
}
snip
___
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
