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 > > > ... > > > 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] 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 > ... > 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] 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] 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] 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] 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
> Your suggestion to use the FLTK name of the font was promising. > I went ahead with it and tried to make it more general. > > But I think it can be used only with Fl::set_font() afterwards. OK, but is that a bad thing necessarily? I tend to do something like this anyway... (pseudo-code warning...) Say I wanted a bold italic Lucida, I might put Fl::set_font(FL_SYMBOL,"Plucida"); Then if I want to assign that font to a widget... widget->labelfont(FL_SYMBOL); I tend to "reuse" the FL_SYMBOL item for this since I never actually use thwe symbol fonts... However, you can assign multiple "user" fonts in this way too. Again the utf8.cxx example code shows some of this, and ways it can be done. > What I would have liked to have was a way to set an attributed font > in (derived) draw() methods temporarily using fl_font(fnum), like > it is done right now in Fl_Browser and Fl_Help_View. > > What I missed from the FLTK API was a method to get the font-index of > a font with a given name, something like: > >Fl_Font Fl::get_font( const char *name); > > Going this way I also added fl_get_font(Fl_Font fnum, int style) and > others > to be able to replace the OR'ing methods comfortably. > > So for example in Fl_Browser.cxx instead of writing > >font = (Fl_Font)(font|FL_BOLD); > > it is now possible to write > >font = fl_get_font(font,FL_BOLD); > > Similar changes are possible in Fl_Help_View.cxx. > > With this changes *all* fonts would work. > > Could you see a need to integrate such methods into FLTK? > I could file a patch, but I am waiting until someone tells > me, that they could be useful for general usage. > (For me certainly they are). If you have working patches, I suggest you post them to an STR, so there's a record of them - even if we don't integrate them, the patches will be accessible to others, so that always has some value. 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 distrib
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? 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
> 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? 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
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
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
[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 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
[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] 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): > > 2>jpeg : warning PRJ0009 : Build log could not be opened for writing. > 2>Make 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_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: 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: 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-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" > and " This 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-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
> 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] 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
> 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
> > 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
[fltk.development] fltk3 currently NOT building on win32/mingw r9440
All, 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 Compiling fltk3/utf8.cxx... Compiling fltk3/vertex.cxx... ../include/fltk3/Device.h: In member function `virtual void fltk3::GDIGraphicsDriver::gap()': ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::n' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::n' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::gap_' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::gap_' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:119: error: `XPoint*fltk3::GraphicsDriver::p' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:119: error: `XPoint*fltk3::GraphicsDriver::p' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::n' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::n' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:119: error: `XPoint*fltk3::GraphicsDriver::p' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:119: error: `XPoint*fltk3::GraphicsDriver::p' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::gap_' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::gap_' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:119: error: `XPoint*fltk3::GraphicsDriver::p' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:119: error: `XPoint*fltk3::GraphicsDriver::p' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::n' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::n' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:119: error: `XPoint*fltk3::GraphicsDriver::p' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:119: error: `XPoint*fltk3::GraphicsDriver::p' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::gap_' is private fltk3/vertex.cxx:273: error: within this context ../include/fltk3/Device.h:118: error: `int fltk3::GraphicsDriver::gap_' is private fltk3/vertex.cxx:273: error: within this context ... etc ... Is this peculiar to my build, or are others seeing this too? FWIW, the OSX build I did earlier seemed to be fine, so this may be WinXX or mingw specific. -- 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 #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
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
[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] MinGW - how to?
> And no, they decided to roll their own, with their own package > description format (manifest, aka catalogue files), etc. The > command line and functions are intended to be similar to apt-get, > but that's it... Oh joy... 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] Add background colors to Fl_Text_Display
> Thanks Ian for the info. I --enable-local*'ed everything anyhow and it all > (Ubuntu'd) ok.I still have some related questions, but I will post again > later after I have a look. > Pause... Did OpenGL build OK? Last time I started with a "fresh" Ubuntu install I had to faff about for a while getting all the GL dev stuff installed... 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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?
> 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
> 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/ so I can not see the output (well, it is OK at home...!) Any http://matthiasm.com/ 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] 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] 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] 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] Some cairo performance numbers
> I'm still not entirely sure what that ideal situation is supposed to > be... > The only thing that's holding me back from trying to render into a > cairo_image_surface instead of a cairo_xlib_surface is that I'm > still using XFT for text. I expect the practical performance of > double buffering into an image surface and using Cairo's 'extents' > functionality to avoid copying anything but the affected areas to > the front buffer is probably going to be better than the current > FLTK model regarding the number of actual pixels pushed through > Xlib. But the bottom line is that drawing anything curved repeatedly > is a bad idea with Cairo and the only solution in situations that > require speed is to draw the shape once offscreen and copy it as > many times as necessary. I'm pretty sure this is how most GTK > widgets operate efficiently. This is also going to be true when > using the OpenGL backend etc... It'll only be fast if you're caching > everything you draw since Cairo's antialiasing of curves is so slow. > Having a doublebuffer() property (defaulting to off) on individual > widgets like GTK does would make this easier on the library user in > most cases. I'll probably do this in my fork. So, hmm, I wonder... When we render text in GL contexts, both the X11 and OSX versions actually render the text into a "cache" the first time the text is rendered, then render it from that cache on subsequent calls (though they appear to use different caching schemes to achieve this - or am I getting confused with the fltk2 X11 GL rendering again? Who knows...?) (Also, note that the WinXX WGL_ methods handle text in GL without this caching scheme.) Anyway, what I was wondering was whether, at least for your use case, it would be feasible to render the Cairo widgets into an offscreen cache on first use, then just blit them into an X11 surface on subsequent calls - overlaying them with XFT text as required? That might give a Cairo-like rendering with XFT text without totally subverting fltk's existing (albeit perhaps non-optimal) render path? Would that work? Might be OK and faster than "pure" Cairo - though would mean subclassing each widget to do the render/cache thing. And might not work at all for that set of your end-users for which offscreen buffers appear to be painfully slow... Just a thought in passing. To be honest, I haven't really thought this through at all, but is *seems* quite attractive on first glance... -- 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] 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] "tooltip" or "hint" or ...?
> How do I called it (the widget?, Hint? ...?), Represented in the figures. > I want to try to implement this for fltk. Who has the thread has any ideas > on this subject (hint, algorithms, etc.)? > http://img268.imageshack.us/img268/230/79021471.jpg > http://img196.imageshack.us/img196/4518/pic1h.png fltk already has support for the "popup" style tooltips so you can probably leverage that. I think what you are asking about is a mechanism such that, IF the widget label is partially obscured, then when you mouse over the widget the full label will be shown, over the obscuring widgets, so you can read it. I guess you could get a similar effect using the stock tooltips actually, though maybe not quite the same thing... What's your use-case for this? Is there some other approach that might work? In any case, I guess if you make your own derived widget you could do something in its handle method to detect the mouse entry/leave events and show the widget label popup in response... 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] 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] 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] fltk-1.3 r9310 build failing on WinXP / mingwbuilds...
> aWJ1dGUgaXRzIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24uCioqKioqKioqKioqKioqKi > oq > > KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqCg== > > > > hard to read! Blimey! OK - no idea why that happened. Pretty sure I had plain-text set on the M$ POS mail client... > The fix in r.9311 is indeed correct. OK, 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
[fltk.development] fltk-1.3 r9310 build failing on WinXP / mingw builds...
Fails with: Compiling Fl_Pixmap.cxx... Fl_Pixmap.cxx:157: error: conflicting declaration 'COLORREF Fl_Pixmap::pixmap_bg_color' ../FL/Fl_Pixmap.H:66: error: 'Fl_Pixmap::pixmap_bg_color' has a previous declaration as `UINT Fl_Pixmap::pixmap_bg_color' make[1]: *** [Fl_Pixmap.o] Error 1 make: *** [all] Error 1 Looks like a loose end in the patch maybe, don't know... I'm in a Windows only place at present so can't see what happens on other hosts. 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 and sub-windows, and the fltk-1 compat layer
> > > OK, more details; fails in the same way on OSX and Linux so I guess it > = > > > is something generic in what we are doing and not a bug peculiar to > the > > > win32 code... > > > This is now fixed with r.9304, that repairs function > > void Fl_Group::add(Fl_Widget&) of the FLTK 1 compatibility layer. > > > Cheers Manolo, that got it.. Argh! Maybe I spoke too soon... Oh, no, wait a minute, fltk-1.3 is broken too, hmm, that is odd. Oh, and also the fltk3 "native" test... OK, here's the thing: On this box, if I run the fullscreen test in "dual-window" mode, i.e. ./fullscreen -2 then, whenever I click the "Double Buffered" button (to force the GL window into double buffered mode) the control panel window (which is meant to be set modal) disappears, leaving me with a GL window that I can't close (it shrugs of ESC and close events...) I wonder if something is hosed on this machine? What do others see? I'm pretty sure I've seen this work in the past, so this seems very odd. Maybe this machine is borked... 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 and sub-windows, and the fltk-1 compat layer
> > OK, more details; fails in the same way on OSX and Linux so I guess it = > > is something generic in what we are doing and not a bug peculiar to the > > win32 code... > This is now fixed with r.9304, that repairs function > void Fl_Group::add(Fl_Widget&) of the FLTK 1 compatibility layer. Cheers Manolo, that got 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
[fltk.development] fltk3 and sub-windows, and the fltk-1 compat layer
Here's a thing... Playing about with the fltk-1 compat layer in fltk3, I notice that when running the fullscreen test app (at least on Win32) then the GL subwindow that shows the shape is not drawn. However, if I remove the window.end(); call at line 196 of fluscreen.cxx (r9302) then all is well (so long as the test is only run in single-window mode of course...) So, it would appear that creating the parent window, then "end"ing it, creating a GL window, then adding it as a subwindow of the parent window, does not work. Creating the GL subwindow while the parent window is still "begin"'d however does work. Note that the "same" (i.e. equivalent) test works fine in "pure" fltk3 and in fltk-1.3, so this is some sort of interaction at the compatibility layer, AFAICT. FWIW, I have a slightly modified "working" version of the fltk-1.3 test code that works fine in either fltk-1.3 or fltk3-compat builds, but that was done by avoiding "end"ing the parent window before creating the GL window, IFF the GL window is to be nested as a subwindow... So, it *can* work, but that's not quite the same thing as proving that the compat-layer is working! I have not tried on a non-WinXX system yet, so I do not know how generic this problem is; it may be peculiar to the fltk3 port on Win32, or it may be more general. I wonder how Matthias is these days; hope he's well! 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] Cairo drawing [was: Doublebuffering issues and general thoughtsfrom a frustrated long time FLTK user.]
> > OK. I know I said I was going to go work on something useful... Well, I > > lied. > > No, you didn't ;-) > > > I made a pretty set of Cairo-native boxtypes instead. Behold: > > > > http://non-mixer.tuxfamily.org/non-mixer-cairo-theme.png > > That was *very* useful! Looks really pretty good. Yup - very pretty indeed... Great stuff. > May we use your code in FLTK (copyright), if we decide to add > Cairo drawing support, as you did? Yes, I guess we'd want agreement to use the fltk-style "LGPLv2 but with static linking allowed and derived widgets allowed" waivers - but I think the modified code is with the fltk license at present so that'd be OK? > Should we dump the Cairo > Window support we have now in favor of (your) full(?) Cairo > drawing? Yes, the existing fltk-1.x Cairo stuff only allows you to have a cairo surface inside a fltk window, in effect. If we have "cairo all the way down" then that would no longer make sense - though it might make sense in some other context potentially, though that is easily down in other ways; I quite often draw Cairo into a fltk window, but never use the baked-in Cairo support... So, I don't think we need it and it collides with the "new" cairo stuff, so let's think about removing it. (Is it even in fltk3 anyway? I guess not...) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Doublebuffering issues and general thoughts from a frustrated long time FLTK user.
Hi Bill, > I think I had better respond to some of this. You know better than anyone what's going on with this stuff, so it's great to get your input. I (for one) always think that your ideas and understanding are really sound. We need more of that... 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] 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 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] 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] 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] [Library] r9234 - branches/branch-1.3/FL
> On 19.02.2012 00:39, Bill Spitzak wrote: > > > I believe changing the scope of non-virtual methods is also ok. The > > mangled name does not change. > > That's not true, according to the articles referenced below (see link). > It seems to be true for gcc, however, but not for MSVC. Actually, that seems to tie in with what I remember, too - more or less by accident (read: carelessness...) I changed the visibility of some methods, and the stock gcc compiles went OK so the error went unnoticed for a wee while. Then it choked when we compiled for another target (possibly DIAB compiler? Or maybe MSVC...?) 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: libraries in general
> I believe the split of libraries in fltk can be removed. This was > initially done so that the libraries can be shared while avoiding the > problem that shared libraries don't work (at least on Linux, and I think > on Windows too) unless *all* symbols in them can be resolved, whether or > not they are ever called. > > This was done for OpenGL, and for the jpeg and png libraries. As far as > I know OpenGL exists on all platforms of interest today, and jpeg/png > have been fixed by including the source for these libraries in fltk. No, I still have embedded targets where I don't have any GL support, so need to be able to split that out. Though we are increasingly seeing EGL support, so maybe... > It would seem that building everything into one library will be a lot > easier. Yes - though since I usually link static anyway, it not like I have deployment issues, just build time issues so... If we were deploying shared libs I think one big chunk might be siimpler than several small ones... > If a .a file is made, the linker still only picks out the pieces that > are used, so this will not change the size of statically-linked programs. 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 libpng/jpeg/etc
> It appears on Linux that compiling 3.0 will link the "local" copies of > these libraries, no matter how much I try to stop it with config switches. I think this is just a WIP issue - linking against the system libs (or the shared libs) works fine on 1.3.x and others so presumably will in fltk3 once we get around to it... > This is VERY bad because this code is vastly out of date and bloated, > and skips processor optimizations that the main ones have in them. > Basically on Linux and BSD, these should NEVER be used. Um, I don't understand. What's out of date? My fltk3 checkout seems to have pretty current versions of jpeg (8c) and png(1.5.4) and so on in it. Or am I missing the point? > I recommend the following fixes: > > 1. Make it impossible to compile and/or use these libraries through the > gmake system. They are only used by IDE's for systems that don't have > them. Not quite true. I often use the "built-in" image libs with make/gmake builds on WinXX/mingw deploys, and I imagine that I'm not the only one. Yes, I could (probably should) just install jpeg/png/zlib/etc in the mingw environment, but using the fltk built-ins is much easier... > 2. When they are built, merge them with the images library. This will > avoid the need for the "fltk3" prefix on their names. Fair enough. > 3. (the hard one) The systems that lack these libraries have their own > methods to read .jpeg and .png files. FLTK should just call these > methods directly, rather than (in effect) emulating Linux. Hmm, not keen. The jpeg/png libs aren't that big so I'm not sure how much we'd save, for the extra complexity if supporting a different image API. Though maybe it is trivial? What systems does that apply to? Is it Microsoft? All the systems I see on a regular basis just use libjpeg and libpng for this anyway, but I'm not all that familiar with the MS API's for image handling. 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
> I very much dislike all the "fltk3" stuff everywhere in the code. Hmm, I'm OK with it I think. I like it better than just "fl". > It sounds like the most popular solution is to call the namespace "fl" > (all lowercase). This avoids collisions with fltk2 and fltk1 names. The > assumption is that fltk3 will be so perfect that future collisions are > not a worry! Yup - though see Albrecht's point about the un-google-ability of "fl". If we don't care about fltk2 collisions, I'd quite like to go with "fltk". Again. > I also think it will be acceptable to collide with fltk2 names. > > Can you please rename everything back, or explain why this is necessary? 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
> The biggest question is exactly what to do if such rewriting is > attempted. Is there a plan to stop contributions to the fltk1 branch, or > to carefully reproduce any and all fixes in fltk3, even if the base code > diverges a lot? The loss of all fixes to fltk1 in fltk2 is what killed > it, apparently. I think the "plan" is that once fltk3 works well enough to stand in for fltk-1.3.x, then that becomes the current version, and fltk-1.3.x is frozen in some known-good state... 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] new a fltk window will takes more memory
> > > I have a simple large window, it contains nothing, only display > black, > > > but it will consumes lots of memory (totally w * h * 4 Bytes), ps: > my > > > platform is 32bpp. > > > = > > > > > Why such a simple window consume so much memory? How to reduce the > > > memory consume. Thanks. > > > > How much memory would you expect it to consume? > > I expected it consume not more than 1MB, and it should not related to > window size, maybe it is a stupid thinking. The "system" needs to represent the whole window somewhere, at least once (a double buffered window will need at lest two instances...) and if the GPU and CPU use the same RAM... Then it depends on how the GPU and its driver represent the window data in RAM, of course, but the "simplest" (and often fastest) thing to do is simply to represent each pixel directly in RAM. So, a 640x480 window with 32bpp would need about 1MB, double-buffered would double that up... Note that this is not really a fltk question - we only use the underlying windowing system, we don't control how the memory is allocated to the window. 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 a fltk window will takes more memory
> I have a simple large window, it contains nothing, only display black, > but it will consumes lots of memory (totally w * h * 4 Bytes), ps: my > platform is 32bpp. > > Why such a simple window consume so much memory? How to reduce the > memory consume. Thanks. How much memory would you expect it to consume? The GPU needs to create a representation of the window in the video memory. If you are on a system where the GPU and CPU memory are shared... 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 run fltk based on DFB
> Now the fltk is running on XWindow, can we set the fltk running on > DirectFB? I don't think so - there were ports for DirectFB, but the main fltk core does not include that. You might be able to use some of the patches if you want, though I would recommend against it, since X11 just is not that big of an issue these days. Certainly, with the tinyX/Kdrive stuff you can run on systems with a very small footprint and it makes your code very much more "standard". > My fltk version is 2.0 Fltk-2 is deprecated and should not be used for new designs or deliverable code. If you want to use fltk-2, you are pretty much on your own, only Ben still works on fltk-2 much. You should be using fltk-1.3. 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] Regarding FLTK licences for free use.
> Now, we were used Qt 4.6.2 version in our embedded device. It is going > to be licences very soon. so we plan to switch over fltk. We would like > to make sure that software is free or license. We would like to know > whether we have to satisfy any licensing agreement to make the software > freely available. I Hope that reply from your side. FLTK is licensed under the LGPL v.2, but with specific exceptions to allow for static linking (static linking is often preferred for fltk apps) without invoking the "derived works" aspect of the LGPL. This is covered in the fltk license file (See the file "COPYING" in the tarball) and in this FAQ: http://www.fltk.org/articles.php?L364+I0+TFAQ+P1+Q As an overview, the intention of the devs is to allow you to link to fltk without causing your program to be automatically subject to the LGPL/GPL terms (though you may want to release your code anyway.) It is expected/required that you will acknowledge (in the docs, in an about screen, etc.) the use of fltk code in your application, and that any changes you have made to fltk will be released to your end-users and to the general community. I'd imagine that would be fine for most uses? What is it about Qt that you don't like? What changes are they making to licensing that are "negative" for you? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Are spammers are using the front page ofFLTK?
> I did click to all of them. Most of them take you to webpages > not related to the software they should be pointing to. Hmm, I just tried this, and apart from the ones that are marked stale (by Greg I think), they all seemed to be OK. Are you sure you aren't getting DNS redirects or something weird? 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_ABI_VERSION mods
Greg, Albrecht, Should we put a version of FLTK_ABI_VERSION in Enumerations.h, maybe set to 10300 or such, and a commented out version set to 10302, along with some comments outlining their purpose? And maybe Albrecht's suggestion for an FLTK_ABI_LATEST key as well? -- 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] 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] RFC: Handling ABI features
> > I really need to check these Fl_Tree ABI features to get it off > > my plate, otherwise I fear I'll forget to get around to it. > > > > In the interest of time, I'm going to go with Albrecht's idea > > of using FLTK_ABI_VERSION with a release number, eg: > > > > FLTK_ABI_VERSION 10302 > > +1 > > > > Under discussion is where to put the definition of the macro > > in order for users to enable special ABI features: > > http://fltk.org/newsgroups.php?gfltk.development+v:13202 > > > > For now, I'll recommend folks hack it into FL/Enumerations.H > > until we decide. > > ... or compile with this macro defined in the commandline, i.e. > -DFLTK_ABI_VERSION=10302 Yes, I think command-line or FL/Enumerations.H would be the way to go, at least for now... I guess what I'd really want is a macro like: I_AM_LINKING_STATIC_SO_GIVE_ME_THE_LATEST_AND_GREATEST_ABI_OPTIONS (well, maybe the actual name might be shorter than that) to get at the latest supported ABI without having to actually know what that "magic number" was... 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 [1m and I think "Bold", [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 [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 [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 boldbold > italic" 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 . 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] A second flag for Fl_Widget::changed ?
> I'm proposing to add a second changed flag to Fl_Widget, this > second one > will not be reseted after a callback like the actual one is. > > I'm working with windows with several Fl_Inputs and some of > then uses > callback to allow calculations when the value changes, but at > the end I > need to know which ones have changed over the session and > because the > CHANGED flag is cleared after the callbacks this information is lost. > > With a second flag that is not reset by the callback I can > easily get the > changes over the section. > > I think that this can be util for more people and for FLTK as > well, so I > propose to add to the official distribution, this change is > transparent > for applications that do not use it explicitly, so all code > made till now > should work as before. I think, if it were me, I'd just derive my own widget to add that functionality, rather than changing the core lib. Oh, I see Mike suggests using the user_data instead - yes, that seems like a good way to go. Maybe use that to point to a struct that holds interesting details fo whether the widget is dirty or not, and which group it belongs to and so forth... 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
> > > >> Talking about copy/paste on windows at least apparently > the clipboard can > >> hold a reference for the original source and in case the > receiver can't > >> handle the original code it's converted somehow to plain > text sometimes. > ... > > > I think the fltk core just basically says (whether acting > as a sender or as a receiver) that it can handle UTF8 plain > text, and nothing else, > > Yep, that's true, IIRC. > > > so ideally the app would convert whatever it has into plain > text before the clipboard was loaded. > > > > Though there are subtleties to this I am glossing over and > there may well be bits of this I simply do not understand... > > I'm not sure if I'm mixing something from Windows and X, but maybe > they are very similar in this regard. That said,... > > At least on Windows, you can push more than one format (text, html, > image, whatever) to the clipboard, and the receiver can request more > than one format. IIRC, the order the receiver requests the format is > used to match the best format in the clipboard. (From memory only, I have not checked recently!) I don't think X11 DnD can work like this it is more like... > Second, you can delay the conversion (and actually putting anything > on the clipboard) until the receiver decided which format it requests. > Of course, the sender must specify which format(s) it can supply. This > is maybe only true for drag'n'drop though, since normal copying to the > clipboard can not be delayed. Maybe. This is, I think, what DnD under X11 does. The conversion happens when the receiver asks for one of the formats the sender claimed it knew how to send... > Third (again I know for sure only from Windows) the OS can convert > some compatible formats (e.g. UTF-8 text and "ANSI" text, as it is > called in Windows, or Wide Character format, and also some different > graphics formats like bitmaps and JPEG). I don't think the X11 layer supports any "magic" translations - it is only the messenger, the sender has to do the actual work. > > The question is: in which cases could FLTK improve it to provide > multiple clipboard formats? I can only think of Fl_Help_View (html > and oridinary text). Anything else? The original context of the question was striping markup (of any sort) from fltk labels, e.g. the escaping (or not) of "@" symbols etc. So I guess any sort of markup, really. However, if we exposed more of the underlying logic, we might make it easier to DnD binary blobs or files around. At present, if I want to drag a PNG image from my app to another app, all I can do is send a path / UNC / whatever to locate the file, as that is all that will fit in a plain-text string. And generally, that's OK. But some apps could actually take the PNG blob directly, if I could send it that way. 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
Re: [fltk.development] [RFE] STR #2766: New configurable optiontochangesymbolprefixcharacter
> On Sat, 10 Dec 2011, Domingo Alvarez Duarte > wrote: > > I found this link about Flterm > http://www.9edgedown.talktalk.net/flterm.html Well, there's a thing. I was just flushing the backlog that builds up in this inbox over the weekend, and I noticed the URL on that link. Now, that URL links to space provided by an ISP I left some years ago... Pages still seem to work though. I'm not even sure if I ever posted that stuff somewhere else, given all the ISP hoping that happened after I moved house! 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] 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 #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] Good tutorial for complex drawing functions
Jens, First off, you are posting in the wrong list (the dev list is for development *of* fltk, not *using* fltk) so you will more likely get a constructive answer over in fltk.general, which is also more active anyway... > I want to draw comlex geometries and keep hitting this one in > the documentation: "the functionality matches that found in > the Adobe PostScript". I searched already a lot on the net > but could not find a concise, good and easy to read > explanation of the complex drawing functions (like tranform, > scale, translate etc.). > > Does someone in the forum could point me to some good > documentation regarding the postscript-like functionality of > the complex drawing functions? What are you actuallly trying to draw? If you post over in fltk.general, outlining something of what you are trying to do, I'm sure you'll get somne answers. For what it is worth, I tend to favour GL for any complex drawing anyway, so that might be your best bet, create an Fl_Gl_Window for your drawing and use regular GL drawing (for which there are many examples on the web, of course!) 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
