Re: [fltk.development] MacOS-specific bug in FLTK 1.3.1for unbundled applications
Software releases shall be generated for each successfully completed software trouble report. although this is not like the current (past) practice. Well, I suppose we *could* sort of claim that the weeklies fulfil that role... Shall we change the CMP? Maybe; though evidence suggests that no one would notice the changes anyway! ;-) SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] CRIT STR #2881
Fixing STR #2881 (Check image bounds before allocation) requires to check for failed memory allocation. Without exception handling, I believe the only way to do it is: #include new ... array = new(std::nothrow) char[xxx]; if (!array) longjmp(xxx, 1); which violates the CMP because it uses the standard library and the std namespace. What should we do? Can we just use malloc instead of new, then check whether we get a NULL pointer or not? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] CRIT STR #2881
Fixing STR #2881 (Check image bounds before allocation) requires to check for failed memory allocation. Without exception handling, I believe the only way to do it is: = #include new ... array = new(std::nothrow) char[xxx]; if (!array) longjmp(xxx, 1); = which violates the CMP because it uses the standard library and the std namespace. = What should we do? Can we just use malloc instead of new, then check whether we get a NULL pointer or not? Yes, but this would require to rewrite the deallocating code to use free() instead of delete, and make sure every possible instance is changed. Ah, ok... I don't think we should throw an exception, so if here's no other way to prevent new from throwing the exception, I guess we are forced down this route? Anybody...? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK ANSI C API
If worst-comes-to-worst I could code in the FLTK subset of C++ and call Ada from there. I have learned a lot about C++ by studying Ada. In your position, I'd maybe favour that; do the GUI in fltk/C++ and the working logic in Ada called from the GUI... Well, maybe... It scares me that you say that the strict Ada compiler did not stop as many bugs as expected. Hopefully it will help me but I guess I can always convert to C++ later if it doesn't. There's a fair bit of literature out there now, where folk have studied this (though of course a lot of the really big Ada users are such that their metrics don't get out into the wild.) The upshot (summarising wildly) is that it helps with a lot of the more mechanical issues (e.g. buffer overruns and so on) and that has a positive effect on robustness and security and so on. But it seems it didn’t really help with the things that were really killing these big complex contracts, which went on being too expensive, late and full of operational bugs... I guess it all came down to complexity, design, requirements capture and so on, and using a better language didn't change things there in the end, and set against the apparent increased cost of using a niche language and tool chain, well, you can get all the same design errors much more cheaply in C++ it turns out... ;-) But this is wy off topic for this list so I'll shut up now. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Release 1.3.1 ?
2682HIGHNew ALL Vertical scrollbar of Fl_Text_Editor have a strange behavior. Or is bug? 1.3-current Dec 10, 2011Unassigned Probably survivable for now? It looks like a real bug, but it doesn't seem to be fatal, more just annoying when it happens... 2761HIGHNew ALL Force break when wrapping long words 1.3-current Apr 21, 2012Unassigned Not keen on rushing into this one - I think it needs more testing, and we need to make sure it behaves nice when we intermix this with fltk @-symbol expansion and so forth (which is a bit broken in places already without adding this... #2689) 2730HIGHNew ALL valgrind, out of bounds access, Fl_Text_Display wrapping 1.3-current Oct 03, 2012Unassigned Yup... Though I can't say what... This looks like a Real Thing, but I guess we'd need Corvid or Matt to propose a patch since they are most likely to know what is actually going on! 2705HIGHNew OS FL_EXPORT that should not exist: See STR #2632 for FL_Button subclasses 1.3-current Apr 20, 2012Unassigned I don't know this stuff; Albrecht is maybe the best for this one? 2845HIGHNew OS image test program blank on cygwin/GDI 1.3-current May 16, 2012Unassigned I can't reproduce this one - it looks like it maybe specific to some display configuration, or some driver or something? I've tried a few things and it (the image demo) always seems to work OK for me. Though... note that I'm testing with mingw rather than cygwin (the STR reports that mingw exhibits the failure too, however...) and I don't have a Win7 VM at present, so I tested with a WinXP VM in various configurations, but that may not be representative... Anyway, maybe it is acceptable for now, if the trigger condition is rare enough? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Release 1.3.1 ?
Reawakening this thread. +1 for 1.3.1 release, with the ABI breaking stuff turned off by default, and calling it 1.3.1 (not .2) Yes. I probably voted before (!) but I'm +1 on just pushing out what we have... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 build errors: centos 5.6
Hi Greg, Just pulled r9698 to check on a 3.x question on fltk.general, but could not run a default build on linux centos 5.6: --- snip [..] Compiling fltk3images/GIFImage.cxx... Compiling fltk3images/HelpDialog.cxx... Compiling fltk3images/images_core.cxx... Compiling fltk3images/JPEGImage.cxx... Compiling fltk3images/PNGImage.cxx... Compiling fltk3images/PNMImage.cxx... /usr/bin/ar cr ../lib/libfltk3images.a ... Compiling fltk3png/png.c... fltk3png/png.c:14:21: error: pngpriv.h: No such file or directory fltk3png/png.c:17: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Your_png_h_is_not_version_1_5_10' fltk3png/png.c:559: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' fltk3png/png.c:649: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' fltk3png/png.c:680: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' fltk3png/png.c:687: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' fltk3png/png.c:695: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' fltk3png/png.c:762: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'PNGAPI' make[1]: *** [fltk3png/png.o] Error 1 make: *** [all] Error 1 --- snip I think this is #2833. The kicker is that the fltk3 makefile tries to always build the built-in PNG lib, whether it finds the system PNG or not. But, it seems that the system headers get picked up (or something!) when building the built-in PNG (or maybe vice versa...) and the build fails as the headers are not quite compatible. Well, that sort of thing... If you build fltk3 with an explicit --enable-local-png in the configure, it then works fine. But yes, this is a bit annoying! Note that is does not show up in the Jenkins builds since they always use the built-ins. Also, when making the docs, lots of doc errors. I have doxygen 1.7.4 installed: I don't think I've ever tried the fltk3 docs to be honest...! SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Painless cross compiling
I know how to cross compile stuff (using cmake), but I'm having trouble cross compiling fltk-1.3.x-r9683 from a x86 linux host to an ARM target. Not really; we don't generally construct our build tools to support cross-compilation, and that can make it tricky at times. Personally, I usually build on the target system, and I suspect most others do to. When I do cross-compile fltk for other targets, I've always just hand-tweaked the build files anyway, since in general my cross-targets are custom platforms for which the cross-tools don't really work... Though I concede that's of little help to you! FWIW, if the ARM target is Linux, or Linux-like, then doing the standard configure process on your host machine, and then hand-editing the generated makeinclude that produces (i.e. to change the paths for the cross tools, libs, etc.) will often take you all the way there. Or most of the way, anyway (indeed I have cross-compiled for VxWorks from a non-VxWorks host in this way, and that's really quite *not* Linux-like!) Also, note that the cmake files are not all that actively maintained - they were largely contributed, and few of the regular devs are regular cmake users, so they may not be the ideal starting place... the autoconf/configure tools are more active and would be a better staring place in general. Finally, you will probably get more help and feedback posting over in the fltk.general list; this list (fltk.dev) is intended for discussing dev *within* the library, rather than for dev *using* the library, so your post (and my reply) are off-topic for this list! Cheers, HTH, -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FL_BOLD,FL_ITALIC Xft font sorting
But I think it can be used only with Fl::set_font() afterwards. OK, but is that a bad thing necessarily? Of course not generally, but it may not always be possible or useful in a certain context. For example if you are in the draw method of a string with escape codes like Fl_Browser has, and want to bolden just the 'current font' fl_font(), whatever it is? Yes, you are quite right. To be honest, when faced with something similar I did a hack thing (more dodgy pseudo-code...) // never actually used this in the end! The idea // was to use attrs to check the state of the current // face but that was never done...! fnt_name = Fl::get_font_name(curr_font, attrs); fltk_name = Fl::get_font(curr_font); : : // Make curr font bold... Hack-o-rama... fltk_name[0] = 'B'; Fl::set_font(user_font, fltk_name); And bizarrely, in the limited scope I was using it, that actually worked. Of course, for real I'd want to actually check that the modified fltk_name actually referenced a font and so forth... Your suggested additions could be a better way to get to the same place, I think. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FL_BOLD,FL_ITALIC Xft font sorting
There is some code in FLTK e.g. in the browser widget, that uses the method of OR'ing the constants FL_BOLD, FL_ITALIC,.. to the current Fl_Font (which is just an index into the font table) to get the font index of the bold, italic,.. font of the current font family. In Enumerations.H the comment says that this constants can be added to the FLTK internal fonts HELVETICA and COURIER. Thats certainly due to the fact, that only for *these fonts* it can be guarranted that their position in the font table starts at a multiple of 4. Yes - OR'ing in the modifiers is fine with the built-in fonts. I wouldn't recommend it with the extended fonts though, for the reasons you identify below...! On the other hand there seems to be some effort in the font routines to sort the fonts to the specific order normal-bold-italic-bold/italic. So I assume it was meant to make the logic of OR'ing in the style attribute also available for other fonts. That was (maybe) the original intent, but as the available fonts become more complex, and we added Unicode support, a lot of the things that make sense for a Latin font, don't really apply so well any more. Anyway the sorting in the Xft file fl_set_fonts_xft.cxx is currently broken if it was meant to achieve this sorting order. This is mainly because most fonts nowadays have style descriptions in multiple languages and there seems to be no defined order of the language terms within the style string. Yup - it was never meant to support that sorting. To be honest, I wrote most of that code and it was really only meant to fill a need (we were missing the ability to load the XT fonts.) The idea was always to try and get to something better; but it has never been really clear what that better thing would be... And it very quickly becomes messy, depending on what fonts a given platform has, since what you actually find inside each font can be quite... variable... hmm... On my machine it now sorts in the order bold/italic-bold-normal-italic. It can be seen for example with the 'fonts' program in the test folder. My questions are: 1. Was there really the intention to have this sorting order so that the OR'ing method could be used for other fonts than the FLTK internal ones too? Not really; it was a good idea once upon a time, and a nice aspiration, but not always practical in the current situation. 2. Would it be of benefit if sorting in Xft would work as planned? (I would have a patch for it already). Patches are always welcome; that's what the STR pages are for - though I've no idea whether it'd be implemented, at least having it logged must be a good thing. 3. Should there not be a more reliable method to find the bold/italic,.. fonts, or is there already one? I think there possibly is: I don't have a XFT box to hand right now, but I think the way the XFT (and WIN32) hosts store the fonts internally, you can tell from the FLTK name what the font style is... Try this; run the utf8 test demo, in a shell, pick a font name and click the Select button. In the shell, you get something like this (this form a WinXP host, but the behaviour is similar I think!) $ ./utf8.exe idx 19 User name :Fixedsys bold: FLTK name :BFixedsys: size 9 idx 106 User name :Lucida Console: FLTK name : Lucida Console: size 9 idx 108 User name :Lucida Console italic: FLTK name :ILucida Console: size 9 idx 109 User name :Lucida Console bold italic: FLTK name :PLucida Console: size 9 So... that's four font selections, and for each we see: - the index number the font was enumerated with (this is not relaible and may change from time to time.) - The User name - basically the name extracted from the font - The FLTK name - a name that fltk makes up to hold the font internally; the interesting thing here is the first character of the name: -- regular font names all begin with -- bold font names begin with B -- italic font names begin with I -- bold italic font names begin with P (There are no other supported states) - size, which is, um, the size... So, anyway, from the FLTK name you can tell some stuff about the font style - and you can use the FLTK name to load that face in that style too, so if you know you want Lucida Console bold italic you can ask for PLucida Console in your call to Fl::set_font(...) and there's a fair chance it will do the Right Thing. Well, maybe... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person.
Re: [fltk.development] Compilation failure under MacOSX
OS: MacOSX Mountain Lion. Revision: 9678 Using CMake and generators Xcode and Unix Makefiles. Stops in scandir.c: /* This warning added to help identify any non-WIN32 hosts that actually try to use * our private implementation of the scandir function, which was suspect... */ #if defined(__GNUC__) # warning Attempting to use the deprecated scandir() replacement function #endif /*__GNUC__*/ #error No compatible scandir implementation found (STR 2687 applies!) Not quite clear if the function should exist or not. Used from fl_filename_list in filename_list.cxx. Your build should not be using that function, OSX has its own, suitable, version - indeed we are not aware of *any* target that actually needs that file and we want to remove it, which is what that warning was put in for; to help identify any aberrant host systems. The fact that it has triggered for you, when clearly it should not, would seem to imply that the CMake setup is failing in some way. Note that whilst we provide some CMake scripts in our tarball, they are not all that actively maintained (none of the core devs use CMake AFAIK) so may be in need of some TLC (help welcomed, if you are familiar with CMake!) Anyway - just to make sure all is well with your setup, can you run the conventional configure ; make sequence to ensure that the stock Makefile builds works correctly (oh!, assuming the stock Makefile isn't overwritten by CMake of course? I assume it is not!). Also, the built-in Xcode project ought to just work too, AFAIK, though I never use it, I always just use the stock Makefile build on my OSX targets... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] getting usable space per screen? alsocompilation failure on OS X
Thirdly, I wanted to see if the behaviour had been fixed in recent versions so I did an svn update, but it looks like the build is broken, coincidentally also with a bunch of screen-related symbols: You may have a version that includes local changes or that's not up to date. Here, the current FLTK 1.3 from svn compiles without error. I wonder if the Xcode project is borked in some way though? Jenkins didn't like it yesterday when I checked but the Makefile went fine. Also, I ran a Makefile build on my system at home and that was fine - didn't get a chance to try a Xcode build at home (small child wrangling takes precedence!) SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Compilation failure under MacOSX
My first intention was to build ftlk using regular makefiles, but seems that after I upgraded to Mountain Lion and upgraded Xcode the autotools are no longer present in MacOSX (even installing the command line tools from Xcode). So as CMake was already in my system I tried to build fltk with it. In order to test the autoconf/configure/make option I will need to install MacPorts or Homebrew I guess. Hm, OK - I am told (I have not tried) that Apple still distribute the autotools, but you have to do (something extra that I don't recall) to get them to install, over and above the usual command line tools thing. So I don't think MacPorts or etc. is necessary for that... I may be wrong. It works fine on my Mac, but I do not have (probably will never have) Mountain Lion so... The Xcode4 project in the ide directory builds fine. OK, that's a good sign, that means all is well... I will have a look at the CMake scripts to see what's wrong with them (or with my system). Since the Xcode project builds, I'm guessing your system is fine and that it is the CMake script that is awry. Probably! SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] getting usable space per screen? also compilation failure on OS X
Thanks for the long and detailed mail. The errors you describe below remind me of an issue more than halve a year ago, which was fixed. I am very surprised that it reappeared, but I also know that Subversion (or its users ;-) can sometimes mess things up. Jenkins also show that the OS X 1.3 build fails. I will try to fix things in the next days. Hmm, OSX build of 1.3 worked OK for me, at the weekend, just using the stock Makefile build. I wonder why? screen_xywh is supposed to give you the screen size in pixels of each individual attached screen. Fl::w() and h(), x() and y() should give you the usable area of the main screen (so for the Mac, that would be the desktop minus menu bar and tool bar). Creating and resizing of a window should not change the size (by FLTK). This is because the user could have multiple screens with higher resolution. As long as the title bar is visible, the window can still be dragged somewhere else. We do not interfere with whatever the window manager will do to the window. So if the OS X window manager reduces the image on creation, we will let it do so (I'd have to look into the source to verify that this is actually so). The stroy is different with popup menus where we make sure that the window fits and uses only a single screen. Yes, there are methods now for getting at the actual size of the display and the usable size (which we maybe called work_area or something...? I forget...Oh yes Fl::screen_work_area(...) ) AFAIK this was all working right at some point recently... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fltk-3 fluid mods broken on mingw?
Matt, I got this from my recent build: Compiling Fl_Type.cxx... In file included from ../include/fltk3/Browser.h:38:0, from WidgetBrowser.h:32, from Fl_Type.cxx:45: ../include/fltk3/Browser_.h: In destructor 'virtual Fl_Type::~Fl_Type()': ../include/fltk3/Browser_.h:174:10: error: 'void fltk3::Browser_::deleting(void*)' is protected Fl_Type.cxx:482:52: error: within this context In file included from ../include/fltk3/Browser.h:38:0, from WidgetBrowser.h:32, from Fl_Type.cxx:45: ../include/fltk3/Browser_.h: In member function 'void Fl_Type::move_before(Fl_Type*)': ../include/fltk3/Browser_.h:177:10: error: 'void fltk3::Browser_::inserting(void*, void*)' is protected Fl_Type.cxx:534:36: error: within this context make[1]: *** [Fl_Type.o] Error 1 make: *** [all] Error 1 $ svnversion . 9650 Haven't looked at the cause (late for a meeting...) SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-3 fluid mods broken on mingw?
Weird! It works here. I knew the change was too big ;-) Well, FWIW, it fails if I build with mingw gcc-4.7.0 but is OK with mingw gcc-3.4.2... Also, I can't seem to egt through to Jenkins to see what it thinks about things! Cheers, -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-3 fluid mods broken on mingw?
Seems to work now. It was a namespace issue. Yup, cheers! SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fltk-3 build broken on linux and winXX
I notice that the fltk3 build is currently borked on linux and winXX: For example, from a Win32/Msys/mingw build I get: $ make === making src === Compiling fltk3/CheckBrowser.cxx... In file included from ../include/fltk3/run.h:39:0, from ../include/fltk3/CheckBrowser.h:34, from fltk3/CheckBrowser.cxx:32: ../include/fltk3/utf8.h:190:20: error: expected primary-expression before 'const' ../include/fltk3/utf8.h:190:20: error: expected ')' before 'const' ../include/fltk3/utf8.h:193:20: error: expected primary-expression before 'const' ../include/fltk3/utf8.h:193:20: error: expected ')' before 'const' make[1]: *** [fltk3/CheckBrowser.o] Error 1 make: *** [all] Error 1 Also, looking at Jenkins, I notice that the OSX MacBook target is offline. I guess Matt took it on his travels with him! :-) SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk-3 build broken on linux and winXX
I notice that the fltk3 build is currently borked on linux and winXX: For example, from a Win32/Msys/mingw build I get: $ make === making src === Compiling fltk3/CheckBrowser.cxx... In file included from ../include/fltk3/run.h:39:0, from ../include/fltk3/CheckBrowser.h:34, from fltk3/CheckBrowser.cxx:32: ../include/fltk3/utf8.h:190:20: error: expected primary-expression before 'const' ../include/fltk3/utf8.h:190:20: error: expected ')' before 'const' ../include/fltk3/utf8.h:193:20: error: expected primary-expression before 'const' ../include/fltk3/utf8.h:193:20: error: expected ')' before 'const' make[1]: *** [fltk3/CheckBrowser.o] Error 1 make: *** [all] Error 1 Also, looking at Jenkins, I notice that the OSX MacBook target is offline. I guess Matt took it on his travels with him! :-) Ahh, the MacBook probably barfed. I can't reach it ATM though. Well, I guess that means you didn’t take it with you on a travel then! Hmm, is there something wrong about the 'const'? Is it a newer C dialect? I can't see what is wrong; here's the failing lines (190) - FLTK3_EXPORT int strncasecmp(const char *s1, const char *s2, int n); and (193) FLTK3_EXPORT int strcasecmp(const char *s1, const char *s2); Which look fine - there are many other lines in the same file that look similar and work OK, e.g. just above the failing line, at line 181, we have: FLTK3_EXPORT char *locale_to_utf8(const char *s, int len, unsigned int codepage); which compiles without issue and uses const char* as a type. I wonder if its some weird thing with strncasecmp being expanded by some macro or other so that the code that is compiled is not what it appears to be at all!? Other than that, a bit lost... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 fltk3connect issues?
... Since we already provide an API that lists a directory contents, should we provide other information about directory entries as well? I added this to FLTK2 many years ago because the FileChooser need a sort-by-date function. CUPS has code for this already and abstracts away from Windows/POSIX, providing filename and stat info in one place. http://svn.easysw.com/public/cups/trunk/cups/dir.c http://svn.easysw.com/public/cups/trunk/cups/dir.h Mike, Those files have Apple copyright statements on them... are we allowed to look at them for our purposes? Or... if we dig back far enough, can we find the same code with an easier copyright (is that even a valid thing to do?) Or...? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fltk3 / mingw / winXP - fluid currently borked for me...
Buidling fltk-3 current (r9619) I find that fluid crashes *on exit*. Haven't had much of a chance to look at why. When building the test folder, it croaks on every call to ../fluid/fluid -c whatever.fl, though not until after succefullt generating the .cxx/.h output files. The GUI version of fluid also chokes on exit. A clean/rebuild does not help. With -g added to makeinclude, gdb says: $ gdb fluid/fluid.exe GNU gdb 5.2.1 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i686-pc-mingw32... (gdb) set args -c test/CubeViewUi.fl (gdb) (gdb) r Starting program: d:\IanMacarthur\svn\fltk3/fluid/fluid.exe -c test/CubeViewUi.fl Program received signal SIGSEGV, Segmentation fault. 0x80070002 in ?? () (gdb) bt #0 0x80070002 in ?? () #1 0x745d26f0 in _libuser32_a_iname () #2 0x745d1696 in _libuser32_a_iname () #3 0x745d1483 in _libuser32_a_iname () #4 0x745d14fe in _libuser32_a_iname () #5 0x745d44f8 in _libuser32_a_iname () #6 0x745d45a0 in _libuser32_a_iname () #7 0x7c90118a in _libuser32_a_iname () #8 0x7c91b5d2 in _libuser32_a_iname () #9 0x7c9162db in _libuser32_a_iname () #10 0x7c91643d in _libuser32_a_iname () #11 0x7c801bbd in _libuser32_a_iname () #12 0x7c90e457 in _libuser32_a_iname () (gdb) quit The program is running. Exit anyway? (y or n) y Which... isn't helping me much... Samples from the test folder seem to be OK though, and Jenkins seems happy enough. So, probably just me... but odd - suggestions welcomed! SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 fltk3connect issues?
Yes. I am focussing on what has now become a rewrite. It was too late when I realized I could have done this in an svn branch instead and just add an experimental build.set to Jenkins. So. Sorry about the mess. It should be fixed by Sunday. I started to look at fixing up the issues so it would build, but backed off because I didn't want to tread on what you were doing, and it was getting late so the chances of me messing badly up were high! The OSX stat sruct is irritiatingly non-standard; I wonder why they did that...? I guess if we convert everything back to time_t within our code, that should better match the *nix and windows stat times, and be OK as a way forward? Or did you have a better plan? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3::Box
Is fltk-3 broken on linux just now? I got a choke trying to build, complaining abouyt box issues... Wonder what Jenkins says... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Problems building with VC2008 and VC2010 (Windows XP - fltk 1.3.0)
Hi. I´m having some problems when trying to build from the latest archive on the web site (fltk-1.3.0-source.tar.gz). When building with VC2008 (Microsoft Visual C++ Express Edition under Windows XP) I get this error (right at the beginning of the process): 2jpeg : warning PRJ0009 : Build log could not be opened for writing. 2Make sure that the file is not open by another process and is not write- protected. It then fails when trying to create any log, or any .lib file. This has been confirmed on 2 different computers, both running Windows XP and VC2008. A previous version of the file (which I downloaded from the web site months ago and which I foolishly deleted) built with no problems at all. That sounds weird - Sorry, but I don't have anything more useful to conribute, since I gave up on the MS tools, I generally use mingw for Windows builds these days... (And the word seems to be that VS11 will not even have a free mode at all...) If I were to take a wild guess, it really sounds like the project is trying to open/create files in a protected location, but you'll have checked for that of course, so I can't think what else might cause it. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Website suggestion: FLTK Library/Fluid GUIBuilder/Forum/Links...
I'm in the process of moving the site over to Torsten's server, so he would be the one to ask... Ah - Can anyone remember the syntax for the svn relocate command? I never remember it; sounds like we'll be needing it soon! Cheers all, -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Fl_Spinner API additions
I'd like to make a few additions to Fl_Spinner; comments? Fl_Spinner is a group with an Fl_Input and a few buttons; looks like this: _ | | ^ | | input area |---| |_|_v_| In my application, I need to change the color of the input area based on if the value is negative or positive, but it seems I can't because the input area is a private member of the Fl_Group. To do this, I could see a few approaches to modifying the widget: 1) Add a color() method to override the invisible Fl_Group::color(), and have it call the input's color() instead. 2) Make the input and buttons 'protected' instead of 'private' so that one can derive classes from it to access the members directly. 3) Do what other widgets do (like Fl_Scroll) and expose the internal widgets with methods, eg. myspinner-input() myspinner-up_button() myspinner-down_button() ..so that an app can access these directly without deriving a class. My thinking is all three should be done, though perhaps #3 is too much?. #2 breaks ABI, so that would have to be #ifdef'ed. Comments? #1 and #2 sound good (ABI issues aside) - not all that keen on #3, but then I'm not all that keen on it in Fl_Scroll either and it actually works ok... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Fl_Tooltip API additions
Curious if there's any objections to adding the following controls to the Fl_Tooltip API. Would like to be able to have more control over global tooltips: // Set/get the left/right and top/bottom margins for all tooltips // These allow the app to control the margin area around tooltips on X and Y. // Currently these are hard coded to 6 pixels on X and Y. // void Fl_Tooltip::margin_width(int val); int Fl_Tooltip::margin_width() const; void Fl_Tooltip::margin_height(int val); int Fl_Tooltip::margin_height() const; // Set/get the tooltip maximum width //Currently this is hardcoded in Fl_Tooltip to 400. // void Fl_Tooltip::max_width(int val); int Fl_Tooltip::max_width() const; Looking for +/-1 dev votes and/or comments, alternative names, etc. Yes, sure; +1 SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Measuring text for X11 16-bitcoordinate clipping
I believe the same goes for vertical white space as well, ie. \nTesting\n\n\n and Testing would I think return the same vertical size. Yes - that is what I expect/believe it does! fl_text_extent() does, however, give you the offset from the string origin, so for instance the X offset for This is a test andThis is a test will be different. Yup. For the offscreen coordinate problem, it was the wrapping of the string and symbol expansion I was really worried about, which measure does and text_extents does not... However, as Albrecht points out, we probably don't care about that, since we want to measure strings that have already been formatted for output by fl_draw, so maybe text_extents would be the way to go. Though I do suspect that the calls to measure the font glyphs can involve server trips, and so become uweildy... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Measuring text for X11 16-bitcoordinate clipping
Okay, so if we'd look directly at the label on a higher level draw function, then wrapping and symbol expansion would be needed, and fl_measure() would be appropriate, but here in the given context we're probably looking at broken-up strings ready to be rendered, and then fl_text_extents() would be the better function? Yes - good point; I'd not taken account of the fact that the string would already be formatted for output, so text_extents likely would be the better choice. Server round trips aside, of course... Maybe there are other examples, or is it really *that* simple to check only the x/y coordinates for far away, and clip the entire text then? I don't know - I was trying to think about it hard, but I think my brain melted. What if we have coordinate transformations with a transformation matrix? Are these basic text drawing functions located after the transformation, and therefore in device coordinate space, or do we have to do coordinate transformations (or at least take them into account, if they would be done later by the X11 drawing functions)? Do the transforms apply to text rendering? I thought they didn't... I do not know. I know XFT can do text transforms, but I don't think fltk has that, does it? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: Measuring text for X11 16-bit coordinate clipping
Question: How expensive would measuring the text before doing the real output in X11 be? I do not know. It is likely that the correct answer will be That depends I guess. If the code is running on a local server, the round-trip will be a lot quicker than a transaction over the network... And I don't know to what extent things like glyph sizes or etc. may be cached either in the server, the client or even (in some places) by fltk itself... Reasoning: In STR #2798 [1] there's a proposal to clip text before drawing in X11, because of the problem with 16-bit coordinates in X11 vs. 32-bit coordinates in FLTK. The proposed patch [2] is incomplete (and not correct), but a correct clipping algorithm would IMHO mean that we'd need to measure the text. The problem is that text that would normally be outside the clipping range could wrap into the display because X11 ignores the upper 16 bits of the (FLTK) coordinate space. Note that this is not a problem for Windows and OS X, since these are using 32-bit coordinates anyway. Does anybody here know how expensive this would be in terms of CPU usage and - probably *much* more important - X11 server interactions? The measuring would have to be right before calling XUtf8DrawString(fl_display, fl_window, font_descriptor()-font, fl_gc, x, y, c, n); I'd guess it could be pretty costly in the worst case - i.e. if you are on a remote display and need to make round trips over the network to the font server and so forth for each measurement... in fl_font_x.cxx (isn't there another one for XFT?), so the font for measuring the text would probably be set up already. That would be XftDrawString32() - or for the Cygwin/winxx X11 version, we use XftDrawString16() for compatibility with Windows 16-bit wchars. Would this introduce more X server messages, or would measuring be a local operation? I don't think we cache the fonts locally, so I'd expect (but certainly do not know for sure) that this would involve a round trip. Second question: What function should be used: fl_measure() or fl_text_extents()? Would there be a performance difference to be expected, or would it only be the small difference in the exact layout? The latter could IMHO be ignored, I'd suggest to use the faster method, because exactness wouldn't matter here, anyway. They also do slightly different things: fl_text_extents measures the inked area of the string, but assumes that the text is ready to be rendered when measured, whereas fl_measure does text wrapping and symbol expansion and so forth before measuring the string, so the results are not directly analogous. Note that fl_measure attempts to expand symbols and wrap text in exactly the same fashion as fl_draw would do when rendering a widget label, so it is probably the more appropriate method for this particular job. I assume what we are looking at here is how to stop widget labels from wrapping back onto the screen inappropriately? Though it may well be slower than fl_text_extents in the general case? Is there some brute force thing we can do, where we just say that is Far Away from the screen, so I'll not bother even trying to draw it...? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 currently NOT building on win32/mingw r9440
I can't check Jenkins from here (due to my ongoing inablility to sneak around the security firewall here at work...) to see what it says, but when I do a build here it dies with There's no MinGW build for FLTK 3 yet on Jenkins, but it fails here with the same errors: OH! Good point... Still, somewhat reassured to know that it is not just my build that's broken! Cheers, -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 currently NOT building on win32/mingw r9440
Can you connect to my server directly? This does not use mooo.com at all, but just my current IP: http://93.201.233.111/jenkins/ Yes - that seems fine. How static is that IP address? Redirecting via some dynamic dns service seems the most flexible option, but the security here seems to be blocking anything in the mooo.com space. FWIW, they don't seem to be blocking dyndns.org domains which is what I usually use, if that's an option? Also, if the server can run https, even with a self-signed certificate, that would probably work too. That's how I usually get access to SVN servers from here, since WEBDAV (which svn needs) is blocked by the firewall, but access via https allows that to pass through. Cheers, -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 currently NOT building on win32/mingw r9440
Yes - that seems fine. How static is that IP address? Redirecting via some dynamic dns service seems the most flexible option, but the security here seems to be blocking anything in the mooo.com space. I have no idea. But there are web sites out there that convert a give host name into the IP address. Or indeed on most systems... $ ping matthiasm.mooo.com Pinging matthiasm.mooo.com [93.201.233.111] with 32 bytes of data: So, that'll probably work fine for now... FWIW, they don't seem to be blocking dyndns.org domains which is what I usually use, if that's an option? DynDNS is no longer free. I don't mind paying fr a service, but I do mind the hassle of keeping track of these mini payments every month or year. Oh? I still have my free accounts - AFAIK they do still have a free service, they just hide it to make it harder for folk to find! That said, it may be academic, because it looks like they may be blocking dyndns domains now too - presumably fallout from the upgrade that broke my svn access yesterday! Or maybe not... Also, if the server can run https, even with a self-signed certificate, that would probably work too. That's how I usually get access to SVN servers from here, since WEBDAV (which svn needs) is blocked by the firewall, but access via https allows that to pass through. I have no idea what's involved in that, or how his works. It sounds like an OK option. Maybe it even helps me to get SVN going since my ISP seems to block any port but 80 (http). Um, I used to know - add the modules to apache, generate a certificate (and give that to apache too) and tweak a few config files and then it Just Works... hand wave... cough... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 currently NOT building on win32/mingw r9440
This error is fixed in r.9442. Sorry, that was my mistake. That seems good now... Cheers. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2834: Make Fl_Help_View draw() and handle() public
All, I've shifted this out of the STR and into the group so that brains smarter than mine can join in and say what's what... Link: http://www.fltk.org/str.php?L2834 Version: 1.3-feature @Ian, I don't think calling ((Fl_Widget *)this)-draw() will work in my Fl_Help_View subclass's draw() method (it will recurs) - or am I misunderstanding you? I tried calling ((Fl_Group *)this)-draw() but this doesn't work also. OK, here's what I thought was going on... You have a derived widget, derived from Fl_Help_View, and in your derived draw method you wanted to call the base class by doing: Fl_Help_View::draw(); But for whatever reason (scope I imagine) that's not allowed. So I wondered if we can trigger the base class by indirection via the (public, virtual) draw method of Fl_Widget. But you indicate that this will nto work... Anybody care to pitch in here? The same with handle(), I believe.. @Albrecht Looking at other widgets I guess FLTK's design deliberately not intended a subclass to use the draw() method of it's inherited class, which is okay for simple widgtes as you have draw_box() and draw_label() that can be used. Nevertheless I think it might be usefull for extending widgets to have a protected (you are right about not needing public) access to draw(). Or am I missing something - how else could one extend the inherited draw() without duplicating the whole drawing code (which is huge in case of Fl_Help_View) or using some dirty tricks? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] SVN down??
Is anyone (other than me!) having trouble accessing the fltk svn repos just now? I can't get in... I'm using https to allow webdav access through the secure firewall here, so that may be relevant... though it has always Just Worked in the past. Anyway, is it just a problem at my end, or is there something more general gone awry? Cheers, -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] SVN down??
It works for me right now, using command line svn. And so it does for me. Just svn up'd my sources. OK - something at my end then. Ho hum... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] New jobs in Jenkins
Try http://evbuilder.de/ . It's just an alias, but maybe enough to fool your firewall? Worth a try, but no - it resolves the URL to mooo.com and then blocks... I'll just have to live without the Jenkins access from work I guess. Though, here's a thought; does it support https at all? If so, I might be able to tunnel out past the proxy in the firewall here... I've used that approach to access SVN repos via https rather than http in the past (the proxy can be inclined to block WEBDAV access to, which the SVN http protocols use...) SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] New jobs in Jenkins
Also, I got MinGW running. Only caveat: if the script fails, the .BAT still does not fail, hence the result is alway success. Maybe anyone has an idea? I see Greg has some suggestions, but I wonder if we can get away with something really crude here... What I'm thinking is that: - Before we invoke sh.exe, the BAT script deletes some marker file - We invoke sh.exe with the build script - The build script recreates the marker file on success, just before it returns to the BAT script - the BAT script then checks for the presence of the marker file, and we use that test to flag pass/fail to Jenkins... Well, or some variation on that, where we can create differently named markers depending on the exit status (pass, warning, error, etc.) and have the BAT script do something with ERRORLEVEL on that basis.. Any use? -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] MinGW - how to?
Ah, OK. This whole package manager thing is new to me under mingw... I guess it is modelled apt-get on debian? (With which I am not all that familiar...) Yes, I think so (is there another one?). I was thinking of the whole rpm/yum/whatever stuff, which is a possible alternate model for the mingw folk I guess... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Can Fl_Text_Display have abackground colorin V1.3
Somebody (might have been Greg?) had a widget for interpreting ANSI terminal sequences, that could presumably set foreground and background colours, Yes, not so much a widget, but a patch to Fl_Browser to support ANSI sequences that can change both fg + bg color as well as bold, underline, intensity, etc. down to a per character basis if desired. It doesn't include font face or font size control; I didn't need it for my situation. Not sure if that's easy to add or not (since it affects the vertical size of items). Here's an example image from the test program: http://seriss.com/people/erco/fltk/tmp/Fl_Browser-ansi-test.png Here's a paste from my 03/10/08 posting here on fltk.dev with the subject Fl_Browser mod for ANSI which has links to the patch and some test programs. 2008! Huh! I rembered the discussion, but thought it was maybe a few months ago or something... I'm too old. Hey, what did I come up here for, again? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] MinGW - how to?
OK, on my VM that has current mingw I did mingw-get update to make sure all was current, That's not true, mingw-get update only loads the new manifest files, i.e. the package definitions and dependencies (mingw-get is modelled like apt-get). It's not yet full-featured, but you can now upgrade individual packages with all dependencies, i.e. mingw-get upgrade gcc etc., and you can upgrade all packages w/o a package specification: mingw-get upgrade Ah, OK. This whole package manager thing is new to me under mingw... I guess it is modelled apt-get on debian? (With which I am not all that familiar...) SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] diff: Add background colors to Fl_Text_Display
Please note, I am currently moving from Windows to Ubuntu and am new to many protocols.I notice from the main websites that there are various versions and their weekly snapshots (1.3.x ??). Yup - many versions. 1.3.x is the current stable tree, 1.1 is the old stable, 2.x is an experimental branch (now largely deprecated) and fltk-3 is the current experimental branch. You want 1.3.something I dont know what STR means Software Trouble Report, though we use it for feature requests as well as bug reports... Try: http://www.fltk.org/str.php but I would OFFER to implement Add background colors to Fl_Text_Display myself. To me HOW this is done will affect which version it should be integrated into. Ubuntu Software Centre automatically downloaded and installed V1.3 for me.What is the install technique for snapshots? Is all source code given? Is it protected? I assume it is well make'd. What is a .tar.gz,a .tar.bz2? What is a diff? There's a howto here: http://www.fltk.org/articles.php?L598 That describes using the mingw tools to unpack a tarball on Windows and building fltk-1.1.7 (yup, it is old...) but the process is identical for any posix-like host (linux, osx, etc.) so the steps should help you get going. The only extra step for the weeklies is that theu may not have been autoconf'd whereas a relases tarball would be. So, once you unroll the tarball and cd into the build dir, run: autoconf just the one time to make sure the autoconf is done, then proceed with the configure stage as normal. Note that on any non-Windows host it is safe to assume that the image libs are all available directly from the system, so you can leave off all the --enable-local-whatever options and it should Just Work. Though, that said, current Ubuntu distros leave out all the dev packages so you probably need to make sure they are all installed or the build will not work. This is a Royal Pain, but that's what they opted for, who am I to argue with Canonical...? Once the configure ; make sequence is done, cd into the tests folder and type ./demo and see what flies. Do not bother with the make install phase, fltk works well from the build tree and it avoids any issues with trashing any system hosted variants... Who decides whether I can do this and how should I proceed? It's open source. Go for it, then let us know! SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Package 1.1.9 in community devpaks has problem
For those following along at home who may not know, the only IDE's we do support are Xcode and some of the more or less sort of compatible with each other VS variants. For OSX only? That's a strange choice. What about Windows? Huh? Wha...? Dude - VS means Visual Studio. That's, you know, the dominant toolchain on Windows, provided by the OS creator. And also, note that VS is available free these days, for most purposes. That said, I don't use it for my WinXX builds - I just use mingw/Msys, since that means that the Makefiles I use to build my projects work Just The Same on every platform. I *have* IDE's on most of my systems - I just quit Eclipse before reading this email - but they are in general not much use for truly portable code (some notable exceptions there, but still harder to use than a Makefile, and much less flexible...) I would have expected you concentrated your effort on something like Netbean which is cross-platform (just like FLTK itself!) Sure, you can use fltk with Netbean, and with Eclipse, and, well, any IDE really. Sometimes I do. But we lack the resources to track all the variants of all the IDE's. In most cases, the person best placed to know what they want from the IDE setup is the person using the tool, so trying to second guess that is often fruitless anyway... As far as I could see, we have to hand-code everything with FLTK (eg window dimension, etc). For people like me who would like to concentrate more time and effort into logic than aesthetic, we prefer something like Netbean or wxWidget with wxDev-C++ (no flame war intended :p) in which we could create windows/dialogs easily and all we need to do is to glue the logic behind the feedbacks. Um, you have seen fluid running, right? Unless you want to get into hand coding your GUI, you really should just let fluid generate the code for you... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Package 1.1.9 in community devpaks has problem
Oh, sorry, dude, I didn't get the word and right after Xcode in your message :D I thought you're talking about things in OSX, ^_^ OK, so I should leave Dev-C++ *at the bottom of my drawer* and go to VS 2010 Express, right? Probably - it's not a toolchain I'm all that keen on, but others around here do use it for fltk, and we provide the requisite project files in the standard tarballs (in .../ide/VisualC2010 folder ) That said, I don't use it for my WinXX builds - I just use mingw/Msys, since that means that the Makefiles I use to build my projects work Just The Same on every platform. I see. What do you use to develop? Just the Makefiles in the shell, plus whatever editor grabs my fancy on any given day... currently favouring scite, textpad, notepad++, sublime-2, vim, gedit, Eclipse, in no particular order. Almost anything but emacs, really... I *have* IDE's on most of my systems - I just quit Eclipse before reading this email - but they are in general not much use for truly portable code (some notable exceptions there, but still harder to use than a Makefile, and much less flexible...) I quitted Eclipse years ago, because I no longer needed to program Java for my job. Oh, I'm only using it for C and C++. It's fine - if you like that sort of thing. Not that interested in java myself... Um, you have seen fluid running, right? Nope! This leads me to see another problem in FLTK website. You don't know what to look for when you have no prior knowledge, but your website doesn't even give the least clue to great things like fluid. I've just spotted the word in that little box on the left and only one mention of the word! How could you expect people to get to know your great products? If I were you, I would at least make a hyperlink to the word FLUID and make it bold. You guys really need to learn some techniques from salesmen ^_^ We have nothing to sell... You probably need to see Greg's video's, and Robark's tutorials, that'll show some of the tips for fluid use etc... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] New jobs in Jenkins
On 23.04.2012, at 23:53, Matthias Melcher wrote: I added the OS X command line build for FLTK 1.3 to Jenkins. I also added all jobs for FLTK 3.0. Ooops: http://matthiasm.mooo.com/jenkins Matt (et al) Two things: 1: I accidentally triggered a fltk3 Ubuntu rebuild last night - I was on a Mac with the tablet-thing attached and as I swept the cursor around I managed to hit the start build button... I'm going to assume that was cack-handedness on my part, but wonder if we need a pop-up to check that I meant it in future? 2: The brain-dead firewall we have here at work blacklists the url http://matthiasm.mooo.com/anything so I can not see the output (well, it is OK at home...!) Any http://matthiasm.com/anything url seems to be fine though so I do not know what their blocking criteria is... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] MinGW - how to?
I downloaded MinGW-get from mingw.org and ran it (it seems that they uploaded it only 24 hours ago - should I use a different version). Using the included package, it does not install the C compiler (it does compile C++ though). Using the option to download the newest version, I get tons of download errors from sourceforge. What am I doing wrong? Don't know. It has always Just Worked for me... At work I use an *old* version of mingw, hand-installed, but I set up a VM at home with the then-current mingw about 3 weeks ago and everything was fine. If you can hang on 'til later, I'll send some details of what I installed in that setup, and see. Or Albrecht may have ideas - I thik he uses the current mingw more than I do. Oh, and a second thing: I am also trying to find a way to run MinGW scripts from the MSWindows shell (which is what Jenkins does). You can run the mingw tools from a DOS batch script, and that pretty much Just Works once you have the paths set up OK for the batch script environment - or you can have your DOS shell invoke /whatever/Msys/path/sh.exe some-script.sh (note: is it still sh.exe or did they swith to another sh version? Can't remember now...) and run the build in a posix enviroment from there. I guess that might allow the linux script to be re-used for the mingw build? (If mingw works at all of course!) Any use? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] New jobs in Jenkins
Their GUI reporter is cute, which apparently parses gcc's error output and gives a condensed report and lots of cute bar graphs. Looks like r9390 gave these non-fatal warnings: Fl_x.cxx: In function �int fl_handle(const XEvent)�: Fl_x.cxx:1292:9: warning: variable �len� set but not used [-Wunused-but- set-variable] ./.. Yeah well, these few are left to Ian I guess (after he left them here, joking of course! ); as you may have noticed already I removed tons of them in most platforms and I'm getting tired a bit :) Did I? Oh, what did I do? (I can't see the Jenkins form here due to firewall...) This is in fltk-1.3 I guess? Is the problem just that I set the value explicitly to zero in the declaration, but it is always set again before it is ever used? I get that all the time from the static-analysis tools here - though I think I'm just be cautious! SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] MinGW - how to?
One more note: although some people recommend changing the Windows system PATH environment variable, I never do this for MinGW. IMHO it is much better to change the path only in the MinGW environment. I also *remove* some Windows path components which I don't like in the MinGW environment, e.g. /c/Windows/System32/WindowsPowerShell/v1.0/ (why would I want this in a MinGW environment?). So, what I do in .bashrc is something like this: Yes, strongly agree. What I usually do is edit the /path/to/msys/1.0/etc/profile script to set up the path and environment correctly for any msys shell I invokein this machine, regardless of which user I am, and that generally seems to be good. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Can Fl_Text_Display have a background colorin V1.3
By using repeated replaces the entire display's colours can be controlled BUT NOT THE BACKGROUND. Why can't each Style_Table_Entry contain background color information somehow? Sorry - it just wasn't designed that way... Somebody (might have been Greg?) had a widget for interpreting ANSI terminal sequences, that could presumably set foreground and background colours, would that be any good? Or do you actually need it to be a text editor too? In which case, well, that may take a wee bit of subclassing of the Fl_Text_* widgets to implement, I'm afraid... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Can Fl_Text_Display have a background color in V1.3
I am using FLTK Version 1.3 Can Fl_Text_Display text have a background color ? It seems to me it should be in Style_Table_Entry somewhere. eg : I would like my Fl_Text_Display to look like -- - This line has yellow background black foreground - -- - This line has white background blue foreground - -- - etc - -- Please. Thanks. Hmm, I don't think out style logic has a case for handling background colour settings... Which seems like a useful thing to have... Might be possible to do something using the highlight_data() method perhaps? I really don't know... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Some cairo performance numbers
AFIAK, drawing pretty much anything 'interesting' in OpenGL is only fast if you cache things in textures on the card and then just use OpenGL to move them around. Yeah, and now I think of it, I'm pretty sure that the X11/GL text rendering in fltk-1.x doesn't have the caching I described, and doesn't really work. OSX does, and I think fltk-2 does... Presumably fltk-3 will have also.. Yes, doublebuffering (triplebuffering?) all FLTK widgets individually would be fast, but it would also waste a lot of memory. GTK users might be OK with this, but I like to keep memory usage to a minimum. Agree. For ordinary buttons and things it really doesn't matter how many thousands of times slower drawing a curve is in Cairo, because the button simply isn't drawn frequently enough to be perceptibly slow. And if you're using a theme with perfectly rectangular FL_UP_BOX etc, the difference in speed is negligible. Yup, sounds right too. The use kind of use-case I'm thinking of for a doublebuffer() property on individual widgets is... say you are beginning a drag operation on a widget on a canvas... Set the doublebuffer() property to true at the beginning of the drag and set it back to false at the end.. This way during the draw the backing image is just copied to the screen without having to redraw the entire widget (this assumes that the need to re-display is differentiated from the need to redraw, currently the only way to do that is with damage(FL_DAMAGE_EXPOSE). Obviously this can already be done with the existing offscreen stuff, but it's a bit of a hassle. Also, this might fly differently depending on host system or WM: IIRC both WinXX and OSX freeze the window background during drag operations anyway (I guess pretty much like you describe, and quite possibly for exactly the same reason!) BTW, here's screenshot of SSM rendered using my Cairo fork of FLTK with the 'Cairo' theme: http://non.tuxfamily.org/spiralsynthmodular-cairo1.png And also ZynAddSubFX (a program which many people love but often complain is ugly due to FLTK) http://non.tuxfamily.org/zynaddsubfx-theme6.png Those are very pretty - curvy lines for the patch-cords next? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Package 1.1.9 in community devpaks has problem
I don't know how community devpaks servers are organized, but I see that: Nor do we... 1. the 1.1.9 package was done by www.bibosoft.de Do you recognize this webiste? Some active contributor to FLTK? Don't know - maybe that was Dejan's stuff? (Though that's a guess.) He's not around much these days, worked and all that... In computer science, we are always taught not to reinvent the wheel, ie not to waste time and effort to do basic things which are already done (at least it's supposed to be done by contributions by others) -- instead we'd better use our time on advanced things. Indeed, you are absolutely correct here, but have perhaps grasped the wrong end of the stick - and therein lies the problem; we already have packaging mechanisms that work flawlessly, yet the IDE people all seem to think they need to invent some new, incompatible, mechanism. Which then is never adequately supported and causes fragmentation. (Though note that some tools do know how to work with tarballs directly, so I have to assume that the Dev-C++ folk decided on purpose to do something else... What did they hope to achieve? I do not know.) The only correct way to install fltk is from the tarballs, which work everywhere. All other package formats are a resource sapping distraction. I consider myself as most of simple users in the sense that I don't want to spend a lot of time in basic things before I could do the real job. If I can't get to the main target after spending quite a lot of time working around obstacles, I'd just forget about it and look at something else, even though that something else might be considered as inferior as people, but at least it works. We, simple users, are pragmatic! Um, how hard is it to install fltk? If you are going to construct any piece of software that is non-trivial, then unpacking the fltk tarballs is well within your abilities, however simple you may perceive your own abilities to be. Open a terminal (not that tricky) Unpack the tarball (tar -jxf fltk-whatever.bz2) Change in to the package folder (cd fltk-whatever) Build fltk (make) Job done. Now all you need to do is set the include and lib paths in your IDE (which you already know how to do) so that they point at the fltk-whatever folder, and the job's a good 'un... Where's the hard part? This process is identical to almost every other lib I've ever used, and is well known, and if not known is a directly pertinent thing to learn, so... I'm at a loss to understand why... Also, note that if you are using Dev-C++ on Windows, then under the covers you are using the mingw toolchain - which comes with the Msys terminal shell; from within that shell, using mingw on Windows is identical to using gcc on Linux, for most practical purposes, so things learned on one host system then become directly relevant on the others; surely that is a useful and advantageous position from which to develop your code? IDE's of any sort (all of them) are essentially a form of walled garden and constrain your use to the workflow and targets they envisage - in the end, that is not an advantage... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Can Fl_Text_Display have a background color in V1.3
Perhaps you can use Fl_Browser for your needs? There you can set the background color of lines individually: Oh yes - that's an idea: might suit the OP's needs just fine... Wonder what is really needed? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues andgeneralthoughtsfrom a frustrated long time FLTK user.
It should be possible to have a coding style flag in each widget that - among other things - makes a widget window or group relative. The code is all there already because OS X has no convept of subwindows and implements group-relative coordinates in FLT 1 already. I'm liking the sound of that, actually... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK rendering and compositing
Bill mentio.ed that some engines reneder into RAM and copy a single rectangle to the screen. Also, converting everything to ARGB internally seems like a good idea. Future 'beautiful' widgets will likly be drawn with scaled images instead of lines anyway, so FLTK compositing should be really fast doing that. Transparency also plays a huge role here. So: O. Fast bitmap handling O. Compositing in RAM O. Must still run on embedded systems O. Support for multiple 'surfaces' like Cairo and OpenGL Suggestion: O. Current interface using drivers is already good O. Improve bitmap capabilities O. Improve offscreen rendering O. Seperatedrivers into their own modules O. Add minimal driver that can be used as a base for all other implemetations (i can do that) O. Add Cairo driver and OpenGL driver This all sounds like good stuff. One thing in particular that I find with the current offscreen mechanism (at least on Windows, not sure about others) is that if I create an offscreen window and then draw into it in various widgets, then when I display the content of the offscreen surface, and GL drawing is just blank rectangles, so clearly I'm not understanding how to get GL to render into our offscreen, and that is a nuisance... If we opt for all our rendering to be composited in some RAM buffer before display, then I guess we need to get on top of the GL aspects of that too? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Old FLTK2/Cairo poll Was: Re: Doublebuffering issues and general thoughtsfrom a frustrated long time FLTK user.
Cairo support on 1 was quite limited. On 2 it was better, but never complete IIRC. Sinc 1.3/3.0 we have a driver system for rendering which means that any frontend can be added to FLTK in a somewhat ordeely fashion. I suggest to add Cairo support as an optional library. This allows for the end user to decide if he wants Cairo or not for any available FLTK app. In any case, we want to get J.Liles Cairo stuff captured - maybe not in fltk-1.3, but feeding into 3.x I guess, along with the fltk-2 Cairo stuff. The Cairo stuff in 1.x is of very limited scope, so possibly not that useful to preserve... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues and general thoughtsfrom a frustrated long time FLTK user.
This way, approximately the same amount of work as fixing all FLTK2's bugs (and trust me; I only fixed four or five in the file chooser and it took me a month) is done but we have an almost-working 3.0 where *everyone* can work on the same thing, rather than some of us on 1.3 and some of us on 2.0 and some of us on 3.0 Yeah, +1. What Ben said... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issuesandgeneralthoughtsfroma frustrated longtime FLTK user.
Yeah, I'd say it's pretty good. And it has backends for Win32, Quartz, and Wayland (not that I care) and also *OpenGL*--hello awesome--and who knows what else in the future. Which is why I think it might be perfectly valid to just do what GDK did and rip all that crap out and leave it to Cairo to deal with. This would actually *reduce* the bloat of FLTK and boil it down to what's really important. I guarantee you that there are now and will forever be more people working on optimizing the rendering path of Cairo than the graphics drivers of FLTK. Yup - I'd love to have a Cairo back-end, as an option (ideally a run-time option, but I'd settle for build-time right now...) but I'm uneasy about losing the native back-ends; the Xlib back-end is very handy in simple embedded devices, where Cairo can be more problematic, and there's a lot of code out there in that space. People would miss it... I know I would! SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues and generalthoughtsfroma frustrated long time FLTK user.
Of course, it looks amazing. Especially for the Control Sequence polygons in Non-DAW and the Ambisonics panners in Non-Mixer, as they're quite curvy. It is indeed slightly slower (but I expected that because it's still going through FLTK's double buffer). Cool. Screenshots at all? (Before/after, just to emphasise the advantages etc. would be really neat...) However, when I dig into the FLTK code to look for a place to install this permanently, I find a bizarre mess of #if defined(USE_X11) type junk. What is the point of having different classes that inherit from Fl_Graphics_Driver if you're just going to implement everything in the base class using conditional compilation? History. Most of the code, in particular a lot of the ifdefs, predate the graphics driver abstraction, and so the code is still working its way to becoming clean. It's a work in progress. But it is getting there... Would it not be infinitely more sane to have Fl_Xlib_Graphics_Driver.cxx and Fl_Quartz_Graphics_Driver.cxx (and now Fl_Cairo_Graphics_Driver.cxx) instead of trying to blend them all into a single class? Yes. See above. You can still conditionally compile whole files, you know, and it is far easier to read and maintain that way. I wanted to just make a copy of Xlib graphics driver and start swapping in the cairo calls, but, due to the strangeness of the Fl_Graphics_Device hierarchy, it doesn't look like it's going to be that easy. I think it may actually be less weird than it looks; that is, I think the historic file hierarchy obscures things and makes it look less organised than it really is... For new work, having a driver-layer per-file must surely be a cleaner separation. I'm open to suggestions, especially if you guys ever want to merge this into the mainline. Looks like my nice clean 1 hour hack is going to turn into several days of reorganizing the hierarchy. I think you need, if possible, to liaise with the people doing the graphics driver abstraction, get them to outline how it is supposed to work, and see if that makes sense for you. I think there were docs posted about this, but, erm, I can't find them now... I wasn't really paying attention. Manolo knows how it works, so he might be best? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues andgeneralthoughtsfroma frustrated long time FLTK user.
Sure. Before and after can be found here: http://non.tuxfamily.org/cairo-test Pretty. How did you handle text? Is that still the stock fltk/XFT text interface? I struggled with the Cairo text interfaces! The vector knobs and the spatializer widget benefit the most. Ordinary rectangular FLTK widgets look identical, except for the possibility of alpha (I added an fl_color_alpha( Fl_Color, float alpha ) call to set color with alpha. Is there already some other mechanism for dealing with alpha as part of Fl_Color that I'm missing?) One for someone other than me I think... And here we begin to see why having three different branches of development without three independent teams to go along is just a hinderance to progress... I can't work with FLTK 2 or (FLTK 3?) because they senselessly change a lot of symbols and semantics and I have too large a code base to play around with porting it. I made that mistake before, porting Non-DAW to FLTK 2, only to discover that (at the time) FLTK 2 was far, far too buggy to be useful. There aren't three branches, or teams. Fltk-2 is pretty much moribund (Ben pokes it from time to time) and shouldn't be used for new work. Fltk-3 is being developed in slow-time by (some of) the fltk-1 team, but uses a mechanism to wrap the API such that (as it stands right now) fltk-1.3 source will compile in fltk-3 with no changes. Fltk3 exposes its own API and a fltk-1.3 compatible API. At some point it may also expose a fltk-2 API. You can even mix 1.3 and 3.x API calls and it mostly works already... The plan is that at some point we migrate to pure fltk3, but in the meantime we have a working platform for existing users to migrate. And we can break the ABI as we go along, since there is no installed user base to support. In that case, I should point out that liasing isn't really my style--too slow. I'll just do what makes sense to me and whoever tries to merge it can sort it out... That's a pity, since you clearly have valuable stuff to bring to the party... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK on uCOSII
I ported FLTK to uCOSII, and found FLTK never release CPU therefore other tasks in uCOSII can't run. Is there any way can make FLTK release CPU to other tasks? This sounds like it may be a feature of your port, as fltk does release the CPU on every system I've ever tried... Can you give more detail of how you implemented the port? I guess that we'd be interested in particular in how the (equivalent of) select() and poll() work on your uCOS system, as they might be the key to this (wild guess mode...) SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk 3.0 namespace - OT drift...
end to that this endless confusion with users starting new development with FLTK 2 would have an end... I think this could be solved by changing the php code in software.php to highlight the FLTK2 and FLTK3 releases *IN RED* with a header that says DEVELOPMENT USE ONLY, and perhaps even a click on the tar file would first pop a web browser alert dialog saying they're for dev use only, and are not official releases yet. That sounds, to me at least, like it might be a Really Useful Thing... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] controlling scroll
hi I made a a spreed sheet and I want to make the labels of rows not to move by horizontal scroll bar and labels of columns not to move by vertical one what should I do? The first thing you should do is post over in fltk.general, since it is more suited to questions of this nature. In answer to your question: I don't know, you would need to provide more detail of your current implementation. Post a more complete description over in fltk.general and we can take it from there. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Linux unicode support
We are using the FLTK Fast Light Tool Kit (FLTK) Version 1.1.7 in our embedded system application.Now currently exploring the Cyrillic script support for our application.Can the above version of FLTK support Unicode or Cyrillic script? Do we need to migrate to the latest FLTK libraries for this? Can you kindly give us some reference documentation for migrating to higher libs. You'd do better upgrading to 1.3.x - 1.1.7 is pretty old now, and the 1.3 series supports UNICODE which makes non-Latin scripts easier to handle. That said, if you are careful with your locale's and code pages, you should be able to render Cyrillic script with 1.1.7, though I have not tried that myself! SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Is there a toolbar can be dragged in fltk?
Is there a toolbar like CToolBar in MFC? Can be dragged,docked. Thank you! There's no dockable toolbar widget built-in to fltk but it is pretty easy to make your own. A quick search through the Links page on the fltk site should find several you could try. FWIW, my own hack attempt is here... http://www.9edgedown.talktalk.net/dock_grp.html And there are many others, several of which may be better than mine! SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR#2766:Newconfigurableoptiontochangesymbolprefixcharacter
On 12/14/11 13:26, Ian MacArthur wrote: #define BOLD_ON \e[1m #define BOLD_OFF \e[0m const char *msg = BOLD_ON Alert! BOLD_OFF \nYour printer is on fire; Ah, but I see ESC[1m and I think Bold, ESC[0m and I think attributes off... Maybe that's just me... That's true -- technically I should have used: #define BOLD_OFF \e[21m ..but \e[0m is so much easier to remember to turn off everything :P Ah, we may be talking at crossed-purposes - I was not meaning to be pedantic about your ESC sequences, rather I was saying that I spent so long working with those sequences that (to me) they are just as readable as html mark-up! That said, and being pedantic after all, I'd caution against using ESC[21m to turn bold off, as in my experience it wasn't all that widely supported. (Though things may have got better since then, it was a while ago!) I found that the most portable option, if I wanted to toggle BOLD off, was to use ESC[0m to turn off everything, then turn back on whatever other attributes were set, since the 21m sequence only seemed to work on some devices, not on others... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2766: New configurableoptiontochangesymbolprefixcharacter
If such changes are being considered, I would MUCH prefer changing to the limited pseudo-html syntax that is used by Qt and Pango and possibly a large number of other pieces of software. This would let users write foo bboldibold italic/i/b and so on. The version I am thinking of would never produce errors. Any ... that does not match a known command will print literally. The must be immediately followed by a letter or '/' or it is printed literally. There is no requirement for matching close delimiters. Unexpected '' print literally. '' followed by anything other than the few recognized chars is also printed literally. And newlines act exactly like br. Greg's idea (ANSI inspired sequences) does have some appeal too, though, and the extended version of Greg's proposal was that we could have support for different mark-up styles, flagged in the widget. Not sure how useful that would really be but it is an interesting concept, I think... -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2737: New option to copy Fl_Widgetlabels automatically
This was done with a different function, Widget::copy_label() in fltk 2. Hi Bill, I don't think that's what the OP is asking for - the fltk2 copy_label() method was added to later 1.1 and is in 1.3, but *I think* what the OP wants is a global control to make *all* labels behave as copy_label(). I may be mis-interpreting... If my interpretation is correct, wll, I'm not keen, I quite like the current mechanism... On 10/17/2011 10:22 AM, David wrote: DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2737 Version: 1.3-feature I've enhanced FLTK to include a new application level option Fl::copy_labels(int v) to enable (1) or disable (1) an option to automatically copy (allocate memory for) Fl_Widget labels. Also added Fl:copy_labels() to return status of option (enabled or disabled). Changed Fl.H and Fl_Widget.cxx Link: http://www.fltk.org/str.php?L2737 Version: 1.3-feature Attachment: http://www.fltk.org/strfiles/2737/label_changes.zip SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to silence new compilerwarnings(gcc4.6.1)
I think the isdigit() and similar functions are required to work with the result of char-int conversion, so they should already be doing this sort of masking. Yeah, that's what I thought, it seems like the sensible thing, but Mike pointed me at some other resources, and I did a few tests, and was rather disapointed by the results... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2766: New configurable option tochangesymbol prefix character
In fltk2 a flag was added to the widget and to the arguments
to the draw
functions that disabled all interpretation of '@'.
I think that's in fltk-1 also.
There was also an @ command (I forget which)
which disabled interpretation for the rest of the label.
I think it was @., at least it is in fltk-1
I think what the OP wants is a way to (globally) change the @ symbol
to some other symbol, to make it easier to use @ as a symbol in its
own right.
This is non-trivial though since we have the @ value hard-coded in a few
places...
On 11/09/2011 06:06 PM, Greg Ercolano wrote:
On 11/09/11 14:06, David wrote:
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES
TO THE LINK BELOW.
Link: http://www.fltk.org/str.php?L2766
Version: 1.3-feature
This change allows someone to configure FLTK to use 0x0F
as the symbol
prefix character instead of @. This allows the use of @
without special
handling which can be troublesome since internal widgets
use @ for things
like arrows and special characters. To enable support for
the new prefix
you'd run ./configure with the --enable-newprefix option
(you may have to
remake the configure first, make clean seems to do that for you).
I like the idea of being able to change or disable the
symbol prefix char,
I don't think it works as a config option. (For
instance, this would break
in a dll environment, where the user's system would
have stock fltk dlls)
I'd offer this alternative suggestion: to retain back
compatibility
with old apps, but allow new apps to still
use/change/disable symbols,
I could see creating two new api calls;
Fl::symbol_char() and Fl::symbol_str():
Fl::symbol_char(0); // disables
symbols throughout FLTK app
Fl::symbol_char('@'); // sets
the symbol char (default)
Fl::symbol_char(0x0f); // sets
symbol char to 0x0f
char c = Fl::symbol_char(); // gets the
current symbol char
std::string rightarrow = Fl::symbol_str(-); // get
an FLTK symbol string
This way if the symbol char is default (@), Fl::symbol_str(-)
would return @-, but if the symbol char were 0,
Fl::symbol_str(-)
would return .
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
SELEX Galileo Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England Wales. Company no. 02426132
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] New FLTK3 user -- layout feature request
I am a new user of FLTK3 who is migrating from using Tcl/Tk for GUI development. My software development is in Common Lisp (SBCL). I have some tests successfully running using FLTK3 in combination with OpenGL. Maybe a bit premature for fltk3 - expect a lot of change before we put it into beta... I like everything I am seeing in FLTK3, EXCEPT for (semi-)automatic layout of widget arrangements. Tk has simple, yet effective ways to control widget placement. I am willing to write layout class methods for FLTK, but some basic infrastructure appears to be missing. Fltk has it own ways of handling layout. They are flexible and powerful, but also seem to be alien to users coming from other toolkits, so YMMV. An outside_measure() method should be implemented for classes, such as Button and all of its subclasses, so that the outside dimensions of those widgets can be determined. The existing measure() method returns the dimensions of the label string and/or image. I have implemented such methods for Menubar and Widget, but the implementations are fragile, depending on FLTK internal details. Huh? I don't understand the question. You get the size of a button just by calling its w() and h() methods. What property of the widget are you trying to measure other than its width and height? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC -- how to instrument a test program to testfor shadow variables
I can think of two approaches to doing this, which I've attached to STR #2728 http://www.fltk.org/str.php?L2728 Curious which you think is better.. I kinda like (A) the most: A. Have the test/Makefile automatically generate a shadow_variables.cxx file on the fly via a one-liner perl command in the Makefile. (No svn check in of the file is needed, it's automatically generated) PROS: Automation -- in the future if devs add new .H files, the Makefile will automatically include and test them.. no special steps needed. Pretty much fool-proof. CONS: This creates a perhaps undesirable dependency on perl. B. Create a static shadow_variables.cxx and check it in. PROS: The test program is like all the others, and no automation dependency on perl. CONS: Devs would have to *manually* maintain the shadow_variables.cxx file, updating it whenever new .H files are added to FLTK, which if forgotten would go silently untested. ..or if you have better suggs, feel free to follow up. Option (A) seems the more thorough - and if we put the generated file in the repo too, then we can fix it up so that anyone who does not have perl can still get something. I guess when we make up an official tarball, or even a weekly, then there's a good chance that perl wil be in place, so we can ensure the generated file goes into the tarball. And is it safe to assume that anyone who's working from svn directly probably has perl installed too? They would need (at least) all the autotools stuff, for example, and I'd hazard that on many hosts perl is more common than autotools... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fltk3 shaped window bails on win32
The fltk3 build is bailing on me right now, with r9175. This is on WinXP with mingw/Msys. $ make === making src === Compiling fltk3/ShapedWindow.cxx... fltk3/ShapedWindow.cxx: In function `HRGN__* unnamed::bitmap2region(fltk3::Image*)': fltk3/ShapedWindow.cxx:66: error: `ALLOC_UNIT' undeclared (first use this function) fltk3/ShapedWindow.cxx:66: error: (Each undeclared identifier is reported only once for each function it appears in.) fltk3/ShapedWindow.cxx:65: warning: unused variable 'alloc_unit' make[1]: *** [fltk3/ShapedWindow.o] Error 1 make: *** [all] Error 1 SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] should I branch?
Should I create a new branch and do the updates to it, try to do incrementally, because some of the files change a few times for different things. Do I have access to branch? Subversion is not git, so the workflow if different. In general, no you should not branch, and you probably don't have the necessary access rights on the repo to do so anyway. Easiest (for certain interpretations of easy) is probably to make a couple of parallel checkouts, one of which is pristine and matches the repo, and as many as you need for your experiments, then diff between them to generate the patches. Well, that works for me anyway, though again not everybody likes that approach. YMMV etc... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] should I branch?
Yes write, to create a branch so you guys can see the incremental updates easily (I presume svn keeps a history that can be used to see various versions). If I just did diff's you'd only see the changes combined with the other changes. We need unified diff patch files - these allow us to easily see each change, in its context. This is the way of yore, and most devs are familiar with it and used to working with patch sets. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to silence new compilerwarnings(gcc4.6.1)
... Fair enough, seems like a Good Thing To Do. (Though possibly redundant in this case? Are there char values that would sign extend for which isidigit() holds true?) The issue is how isdigit() is implemented, as a macro in many cases that does a table lookup... Out-of-range values can cause a crash... Ah OK - I assumed that it would be a function, but I can see that a lookup might be a credible implementation... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2741: Get text/label sizebeforeassigning to widget
measure_label() works after set, but I'd like to know before setting, without knowing the font/size used. fl_measure didn't work for me, weird values, plus requires knowning font and font size, that's why having one that can just be called with NULL/0 as font and/or size would use defaults. Also would like to be able to set the size that will be used for wrapping width as an option. What you are asking for makes no sense, really. There is (strictly speaking) no concept of a default font in fltk (though many widgets default to FL_HELVETICA at 14-pixel size, it is not strictly a default) so until you set a face/size for the measure functions to utilise, there is nothing to measure... Did you read the docs for fl_meaure? It describes how setting the w param before calling it is used to set the wrap width - this sounds like exactly what you are asking for, so I don't see what the problem is...? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] masking?
+-- label --+ | | | | +---+ Seems like one could create a mask just before drawing the border box so it leaves a 'hole' where the label() is. This way the background could be a gradient or an image and still look right. I don't think this could be done with fl_clip().. it's almost like one needs the opposite of a clip. Curious if there's a right way to do this in FLTK 1.x.x? Hmm, not that I know of - indeed, although it seems like a useful concept, I don't know if any toolkit supports it... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to silence new compiler warnings(gcc4.6.1)
OK - I'm feeling particularly stupid now: how does masking a byte with 0xFF help? Is it that isdigit() thinks it gets an int, or... I'm missing something key here, obviously... C doesn't define whether a char is signed or unsigned, so masking makes sure that you don't pass in a negative number, and also keeps the value within the range supported by the ctype functions (-1 to 255 in most cases - -1 because that is the EOF character...) OK - so it is just sign-extension in the promotion to int that we are dealing with then, that makes sense... E.g. if the char in *str is 0x83 say, and is promoted to int, we have to assume (for safety) that it will be sign extended to 0xF..F83, so we mask it with 0xFF to ensure the actual int value is the same as the original char value. Fair enough, seems like a Good Thing To Do. (Though possibly redundant in this case? Are there char values that would sign extend for which isidigit() holds true?) SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Lambda function in FLTK how to use?
You need to ask over in fltk.general. This list is specifically for development *of* the library. Development *using* the library comes under fltk.general. Also - you are going to have to clarify the question; there's not enough context there to begin to know what you are asking... e, how? Maybe in callbacks? (Anonymous function) What language? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Fltk3 deps suspect?
This is not to say that there *is* a problem, just flagging up that I think something odd happened... I was rebuilding fltk3 on my OSX host, and svn had pulled in a few revisions (e.g. Manolo's cocoa_font commit etc.) but some of the files I thought were touched did not get rebuilt. This seemed odd to me, so I did a make clean ; make to force it, and of course all is now well. Still, it did look as if the dependency check maybe didn't work - but of course, once I'd done the clean, well, it was hard to tell... This was building from the Makefile on OSX, so may be a non-standard configuration for the current state of fltk3, but I wonder if there is an issue with the dependencies in fltk3 in it's current state? Anyone know? And of course, it is entirely possible I'm mistaken anyway! -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3.1 release planning
There are also some Mac OS bug fixes in the svn version that would be good to be present in 1.3.1. Is that possible ? Sure. I will do an svn diff to figure out what is needed. Any suggestions welcome. There was a probvlem with opening the native file_chooser on OSX, that I tripped over and Manolo fixed. I'd be very keen to ensure that was in the 1.3.1 snapshot... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ 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?
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! Yup - though I think that's normal; the build *usually* emits a callable version of the inline function if it thinks that *something* might call it externally, even though it inlines the body in the places that it sees it being called, and that's the version you are seeing called here. Note that the way that linux and win32 handle dynamic linking are different, so the results you see are probably not consistent across platforms, which may introduce some oddities? 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. Well, the code is (probably) inlined in all the obvious places, but the compiler/linker may still emit an actual implementation too... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] problem with fl_draw(s,n,x,y)
I have changed (r.9055) the Doxygen doc of fl_draw() functions to state explicitly that all involved strings are UTF-8 encoded and all lengths are in bytes. Good idea. I would suggest to use the fl_utf8decode() function in your case. It will successively compute the byte length of each Unicode character in your UTF-8 string. When you have reached the maximum allowed number of characters or the string end, you'll know how many bytes to send to fl_draw(). This would work for LGC scripts provided accented characters are encoded with a single Unicode value. Yes - I think that sounds better than my idea of walking backwards along the string to clip off excess characters.. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] problem with fl_draw(s,n,x,y)
But in UTF-16 all symbols have size two bytes. There is no problem to set specified size of string as opposed to UTF8 where every symbol can have own size (from 1 up to 5?) . Not true I'm afraid - only glyphs from the BMP are sure to be two bytes in UTF16. Any glyph from a higher plane will be 4 bytes. Check up on surrogate pairs to see what I mean. I see no way to use it. Shortly - I have to print column of text lines restricted by specified length. I use the Courier font. The lines can contain any symbols - latin, cyrillic etc. I can't evaluate needed size of line in bytes if I use UTF8. Only via conversion into any accessible format with monosized symbols. I might need to see an example to help visualize what you are doing... I'm not sure I'm understanding all the nuances of your problem. Anyway, best post an STR, and maybe a simple example we can use for testing. It's no problem, but... my latest STR (fl_draw_image_mono(...) has no body at all!) hang there without any interest Oh we read them - we're just busy, so don't get much time to actually do anything about them... I still think that posting the STR with details, examples, etc., greatly increases the chance that *something* might get done! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] problem with fl_draw(s,n,x,y)
The only reliable way to get the width of whatever is printed is using fl_width() after setting the font and size. Or my preferred option of fl_text_extents() SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK -cross compile problem
Your post is off-topic for this list; you would get more useful feedback posting over in fltk-general. (This list is for development of the library itself, not for use or development using the library.) Also, whenever possible, please post in plain text, not html or rtf, as it makes it more generally readable. Anyway, that aside, it looks as if you still have the wrong paths - the link is failing because it is trying to link the fluid exe, and I would say that it looks as if it is finding your host system libs (which are presumably x86 binary) rather than the arm binaries it needs. So you need to sort your paths (probably in makeinclude) and also ensure that your cross-compilation environment actually has all the libs you need, in this case it looks like it can not find libpthread, libdl or the libX11 stuff, so without them you are not going to be able to build any GUI code for your target. Have you successfully built other executable code that runs on your target using this toolchain? Have you built any X11 executables that run on your target using this toolchain? If so, it should be easy to crib the required linker paths from the builds that work to get the fltk makeinclude set up correctly. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK3: Status
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] 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? 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. Yup... The example opens up a tcsh prompt. See, that's gotta be a bug, right there! ;-) SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Yet another way fluid generated codecancrashthe application
All right. All who commented seem to be just as undecided about this as I was. Clearly neither solution is clean. So I went with the one that does not break the ABI: just add one more -parent() in the fluid code generator. Patch and a simple fluid test program are coming up in two follow-up file attachments. Test program crashes when compiled with 1.3.0's fluid, does not crash when compiled with the patched one. Great: Can you post a report, describing your findings and attaching your patch and test code, on the STR page at: http://www.fltk.org/str.php to make sure we don't lose sight of this. I guess file it against fltk-1.3-current, though in practice I'd guess it applies to all variants. Thanks, -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Funny build warning in VisualC 6 / FLTK 3core
Hmm, currently I can't follow what the new scheme means exactly, but I'd say that config.h should _not_ be in the include directory, i.e. it shouldn't be in any directory used for building user code. It's only an include dir in the local-to-the-fltk-build-tree sense, so probably does not appear in the user scope... Probably... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Funny build warning in VisualC 6 / FLTK 3core
PS: with Ian's correction to makeinclude (adding -I.. three times), everything except CubeView built now with MinGW. Errors: That's odd - I just built r8998 on mingw with the following mods: - add the -I.. paths to makeinclude - hand-edit test/makedepend to sort some paths (has ../include/config.h rather than ../config.h in several places.) Therafter build went cleanly. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Funny build warning in VisualC 6 / FLTK 3core
Hmm, I think I lean the other way. What we learn from the ongoing trickle of posts from users asking about fltk2 is that the users see a number, and think that bigger is better. So we *should* number our releases, and (in future) try to ensure that biggest is the latest and most current... So fltk3 for me, then fltk4, fltkX That said, can we move the branches around in svn so that fltk2 is not head, but is in a branch, then we can put fltk-1.x or fltk3 or whatever as head, moving forwards? Side note: I don't like the fltk3 naming convention anyway. Some day in the future we will have fltk4 and fltk5, maybe - my favourite naming would be that the newest and best FLTK version would always be fltk, but I know that this would conflict with FLTK2 compatibility, and so we *had* to choose fltk3 for now. :-( Sigh. Yes. Let's just assume for now that the jump from FLTK3 to FLTK4 will be so huge, that we will later be glad we did it this way :*) I have to say I agree with Albrecht; it's probably best that the most up-to-date (or current-heavy-development?) version has the FLTK tag, and the older versions take the FLTKversion_number tag. I'm happy to convert all the fltk2 stuff to the fltk2 naming convention to make this easier for you. I'm also happy to wear all the flak from the current set of 2.0 users over this change (if it's something you'd prefer for fltk3)! If we do decide to give 3.0 the fltk tag and fltk2 the fltk2 tag, we can always just invoke the fact that 2.0 is still alpha (and thus such huge changes aren't completely a Bad Thing ;-) Ben SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] CubeView build problems (was: Re: Funny build warning in VisualC 6 / FLTK 3core)
And last but not least, all GL demos still fail to run. Ian, do they work for you with MinGW? Hold on... Still building... OK, done: $ svnversion . 8999 $ svn stat ? test1\preferences.h ? test1\tabs.cxx ? test1\keyboard_ui.h ? test1\inactive.cxx ? test1\inactive.h ? test1\CubeViewUI.h ? test1\resize.cxx ? test1\fast_slow.cxx ? test1\valuators.h ? test1\mandelbrot_ui.h ? test1\tabs.h ? test1\radio.cxx ? test1\CubeViewUI.cxx ? test1\radio.h ? test1\tree.h ? test1\preferences.cxx ? test1\resize.h ? test1\fast_slow.h ? test1\tree.cxx ? test1\valuators.cxx ? test1\mandelbrot_ui.cxx ? test1\keyboard_ui.cxx ? include\config.h ? include\fltk3\Makefile OK - builds fine, despite not applying your patch... Testing... Yup, GL demos seem to run. Recall that I have a much older mingw than you, maybe it is being less picky about something? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 build issues on OSX with Makefile - OK! Now with added win32 goodness...
OK, I made a design decision here that will haunt me for a while. I figured it would be useful to compile jpeg, png, and zlib from scratch always. This will reduce special cases at compile time and simplify the autoconf/configure process. It will ensure that these libraries exist, even if FLTK was configured on a machine that has built-in jpeg libraries, but a resulting app was distributed to a machine without that library (say you build Fluid on machine a and statically link fltk and fltk_images, but not fltk_jpg etc. . On a machine that has no libjpeg, the app will not launch at all). The overhead is close to zero (jpeg.png/zlib compile in less then ten seconds on my machine), and the developer can of course still decide to dynamically link with libjpeg instead of fltk3jpeg. This is only relevant for the test/example/fluid apps. Ah, right, I get it - this ensures that fluid and the test examples will always work, for the small overhead of always building the image built-ins. Seems reasonable, except we don't (yet) always build the built-ins so it cchoked, but it *will* work... Anyway, going OT, I got a choke on win32 right now: Compiling Fl_get_key.cxx... In file included from Fl_get_key.cxx:29: Fl_get_key_win32.cxx: In function `int fltk2ms(int)': Fl_get_key_win32.cxx:114: warning: comparison between signed and unsigned integer expressions Fl_get_key_win32.cxx:114: warning: comparison between signed and unsigned integer expressions Fl_get_key_win32.cxx:115: warning: comparison between signed and unsigned integer expressions Fl_get_key_win32.cxx:115: warning: comparison between signed and unsigned integer expressions Fl_get_key_win32.cxx: At global scope: Fl_get_key_win32.cxx:130: error: `int fltk3::get_key(int)' should have been declared inside `fltk3' make[1]: *** [Fl_get_key.o] Error 1 make: *** [all] Error 1 Hmm, some kinda scope thing I guess (didn't bother to check...) Cheers, -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 build issues on OSX with Makefile -OK! Now with added win32 goodness...
Ah, no. I removed all the signed/unsigned warnings from OS X, changing the APIs for shortcut keys (and basically for characters and modifiers in general) form signed int to unsigned int. Xcode only finds teh OS X files, so win32 and X11 files may be behind in this change. I only test those once a week (at most). Ah OK. If there are easy things in fltk3 that I stumble across, how do you feel about others (me, Albrecht...) committing fixes into the fltk3 tree whist you are still hacking away at it...? Is it best I just hold off for now, or are trivial fixes OK? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 build issues on OSX with Makefile -OK!Now with added win32 goodness...
Is it best I just hold off for now, or are trivial fixes OK? Please hold off until Wednesday. I am currently shuffling files around a lot. I am relatively certain that all files will then be in their final position, and unless there are grave concerns, will remain there. After that, please do fix things in any way you like Ah, OK. Will do. In the meantime, there's something awry with the generated Makefiles, I don't know if you've seen this in the OSX tests or not? For example, on WinXP I get: Linking file_chooser.exe... ../lib/libfltk_images.a(Fl_File_Icon2.o)(.text+0x185c):Fl_File_Icon2.cxx : undefined reference to `fltk3::filename_ext(char const*)' ../lib/libfltk_images.a(Fl_File_Icon2.o)(.text+0x1d75):Fl_File_Icon2.cxx : undefined reference to `fltk3::filename_ext(char const*)' collect2: ld returned 1 exit status make[1]: *** [file_chooser.exe] Error 1 If I suppress the .SILENT in the makeinclude that becomes: Linking file_chooser.exe... g++ -O3 -Wall -Wunused -Wno-format-y2k -fno-exceptions -fno-strict-aliasing -mwindows -o file_chooser.exe file_chooser.o ../lib/libfltk.a ../lib/libfltk_images.a ../lib/libfltk_png.a ../lib/libfltk_jpeg.a ../lib/libfltk_zlib.a -lole32 -luuid -lcomctl32 ../lib/libfltk_images.a(Fl_File_Icon2.o)(.text+0x185c):Fl_File_Icon2.cxx : undefined reference to `fltk3::filename_ext(char const*)' ../lib/libfltk_images.a(Fl_File_Icon2.o)(.text+0x1d75):Fl_File_Icon2.cxx : undefined reference to `fltk3::filename_ext(char const*)' collect2: ld returned 1 exit status make[1]: *** [file_chooser.exe] Error 1 And it is apparent that the fltk libs have been linked in the wrong order, since libfltk.a needs to come after libfltk_images.a here. The test Makefile now has: file_chooser$(EXEEXT): file_chooser.o $(FLTK_LIB_NAME) $(FLTK_IMAGES_LIB_NAME) $(FLTK_PNG_LIB_NAME) $(FLTK_JPEG_LIB_NAME) $(FLTK_ZLIB_LIB_NAME) echo Linking $@... $(CXX) $(ARCHFLAGS) $(LDFLAGS) -o $@ file_chooser.o $(LINK_FLTK) $(LINK_FLTK_IMAGES) $(LINK_FLTK_PNG) $(LINK_FLTK_JPEG) $(LINK_FLTK_ZLIB) $(LDLIBS) Which does look to be calling out the fltk libs in the wrong order, I guess that's a feature of the new build system that still needs fettling? Cheers, -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 build issues on OSX with Makefile-OK!Now with added win32 goodness...
The Makefile generator still leaves a lot to be desired, I'm impressed it works at all... but yes, link order is currently just copied from the order of dependencies in the .flw framework file. SO it's really easy to fix in Fluid. Longer term, is the plan to make fluid know the right order and enforce it in the files it generates? I know that in the past we've had a fair number of posts from people tripping up over link-order dependency, so if we made it easy for them to get it right... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Yet another way fluid generated code cancrash the application
On 19.08.2011 02:18, Csaba Biegl wrote: Consider a fluid class containing an Fl_Input_Choice widget. If this widget has Fl_Menu_Item-s that have their own callbacks then these will crash the program. Reason is that Fl_Input_Choice itself is a group containing an FL_Input and a Fl_Menu_Button. It is the latter component that executes its menu item callbacks on their behalf. Fluid generated callbacks find their class instance using repeated -parent() calls. Because Fl_Input_Choice adds an other group to the hierarchy, the fluid generated callback will access the wrong object. Good catch - that sounds plausible (although I'm not very familiar with fluid code). I can post a patch to fix this, but we need to decide where to fix it. Thanks for the offer! Option 1: Fix it in fluid so that for Fl_Input_Choice menu item callbacks it adds one more -parent(). Advantage: This fix would be local to fluid. Drawback: special handling in fluid. Option 2: Fix it in Fl_Input_Choice so that its own subclassed version of Fl_Menu_Button passes up menu item callbacks to its parent. This is what I'd prefer on a first thought. But then there is the possibility that this would break user code that handled this correctly (code *not* generated by fluid). Just my 2 ct; I'll leave the final decision to others... I'm not keen on special handling in fluid - though that might be most compatible. So changing Fl_Input_Choice seems favourite, but... If we do change the structure of Fl_Input_Choice that may have to be deferred to 1.4 as it'll be a breaker I guess? SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] What's new in Fluid3? - fluid behaving badly in WinXX builds?
Does it fix it with my test ( -g 600x400+0+0 ) for you? Yes, but I only have access to single-head systems now, so my testing is not indicative for the multi-head case... In my case it still positions the window on the 2nd screen, just as I found during my tests before (this is as expected, since the only effective changes in both our patches was to reset the num_screens variable before enumerating the monitors). Now I wonder why there's still a difference between FLTK 1.1 and 1.3, but I can't check it now. Anyway, it's a step forward, and there are other issues with finding the correct monitor and position to display the window in Fl_X::fake_X_wm(). First of all I wonder why we first substract the border widths and then try with these modified values that may be outside the screen (e.g. [0,0] - [-8,-30]), whereas we would probably better use the requested client area coordinates directly (in this example [0,0]) to find the correct monitor... I guess so - maybe someone else can remember why we did it this way... It may have made sense when we were dealing with the work-area rather than the screen=area or something, though I confess I can't see how... Anyway, I think it is better than it was (certainly the handling of num_screens before was an error) even if not fully fixed for all the cases... SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
