Re: [fltk.general] Fl_tile: don't shrink, just shift
Hmm, now, I seem to recall that Jason Bryan's FLU widget extensions = for fltk had something like that - they wo uld be worth a look. OK; his pages at OSC.edu appear to be down, but there's a mirror here = that still seems to work: This came up a year ago - check STR2795 Latest FLU is hosted on sourceforge http://sourceforge.net/projects/flufltk/ Thanks Martin; I did not know about that Sourceforge location. That could be handy. Though... does that actually work for anyone? I just tried, and there don't seem to be any files to download there? Probably I'm doing something stupid again... Jason gave permission to integrate them, Fabien Constantini reported that he had ported the full FLU2.14 widget set to 1.3 and volunteered to integrate (at least?) its Fl_Tree implementation in 1.3/3.0 Though we now have Greg's tree widget implemented anyway, so the need is less pressing now! Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_tile: don't shrink, just shift
Thank you all so much for your hints: now I understand the real purpose and design of Fl_tile! I think I'll opt for a derived Fl_Group as suggested by Ian and Greg. Mainly by Greg, I thought his description was pretty good. I might be tempted to make his resizer widget out of a group, so that it could contain the widget(s) that it was resizing, without have to search quite so much for them. Or... that might be a bad idea. Dunno... Let us know what happens! Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] RFC: win32 Fl_Window::icon()vs Fl_Window::xclass()
Just as a side note; I was using the VS7 (ancient) compiler to do the above tests (I still use VS7 for building my commercial apps), but double checked in VS 2010 as well. Both compilers seemed consistent, so if MS did change something, it would've predated VS7. (Entirely possible, as our docs are much older than that, lol) Yes, indeed. I'm thinking, if MS did change something, it likely is not in the compiler toolchain, but in some system lib or DLL...? So, to track this down, we'd need a bunch of systems with different Windows versions, with different service packs applied, to see if we could see where the behaviour changed... Or, you know, just not. :-) Selex ES 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] fluid - Adding win32 icon
FWIW, and as a separate issue, I *think* the .rc file can be a simple one liner. (I'm all about simplicity and understanding everything in the files I build) For instance, with sudoku, it seems I can change the sudoku.rc file to just contain: 101 ICONDISCARDABLE sudoku.ico ..and in the sudoku.cxx: Yup - that was one of the things David and I had discussed. I think he was going to try and reduce the .rc/.h files in the patch to a bare minimum, much as you are suggesting. icon((char *)LoadIcon(fl_display, MAKEINTRESOURCE(101))); ..and I think that would get rid of the need for a sudokurc.h file, and shortens the .rc file quite a bit. Though I'm uneasy about just assuming the value is 101 - in principle we could make it something else... (though likely never would!) So with those two things, one can compile from the command line (I use gmake scripts); To compile the one line sudoku.rc - sudoku.res: rc -r sudoku.rc ..and to link: link [..] sudoku.obj sudoku.res [..] ..and then the resulting exe shows up in the browser with the icon, and when executed, the titlebar shows the icon as well. This change seems to work within the vs IDE as well. So perhaps fluid could be just as simple. Just seems like the shorter the better, I was thinking we'd just try and make it match the pattern set by the Sudoku example, for consistency? but I really don't know what all that other cruft is in those files. Heh, does anyone, really? :P I very doubt it... Selex ES 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] fluid - Adding win32 icon
I think the best thing would be to create an STR and post the icon and your patches there, for folk to take a look at. Ok, I will do it so (at least I will try) It's not so hard; you'll be fine! The icon file is 32k bytes now? That seems OK, maybe a bit larger than I'd have expected... OK, just checked, and the icon I've been using for my app is 29k, but it has sizes from 16x16 up to 256x256 in it. May be the tool I used add some garbage in it. Possible, though seems unlikely. Is the source image very complex? I guess the size of the ico file might be dominated by the complexity of the source image? Or are they uncompressed images? Oh, maybe it's a colour depth thing, then? Is that possible... Now I can't remember what information is in the .ico format... My understanding is that, for Win7 at least, we'd really want a 128x128 as well, possibly even a 256x256 just in case! Just checked the MS docs; I was wrong about the 128x128 size. Vista/Win7 wants the 256x256 size, and older versions (i.e. XP) only go up to 64x64, so the 128 size is probably less useful... Sounds like we'd want, as a minimum: quote Application icons and Control Panel items: The full set includes 16x16, 32x32, 48x48, and 256x256 (code scales between 32 and 256). The .ico file format is required. For Classic Mode, the full set is 16x16, 24x24, 32x32, 48x48 and 64x64. http://msdn.microsoft.com/en-us/library/windows/desktop/aa511280.aspx#size /quote So... I guess we would want a superset of these... 16x16, 24x24, 32x32, 48x48, 64x64, 256x256 How does that sound? Selex ES 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: win32 Fl_Window::icon() vs Fl_Window::xclass()
I just noticed a few things on win32: [1] If an app sets the window's xclass() *before* it sets the icon(), the icon won't show up in the title bar. Hmm, odd. I did not know that... We have kinda changed the way the xclass is done, more recently than the icon stuff was done. That may be relevant? [2] In the win32 osissues page, under Setting the Icon of a Window there's a NOTE: that reads: You must call Fl_Window::show(int argc, char** argv) for the icon to be used. The Fl_Window::show() method does not bind the icon to the window. This no longer seems to be true, at least empirically. And I think Albrecht once commented he noticed this as well, and wondered aloud if this comment was outdated, if ever true. ISTR it *was* true at some point (though may date back to NT4 or early XP) so things may well have changed. Indeed, the changes to the way we handle xclass in WIN32 might even have had an effect here? Is [1] known behavior that should be documented? Is [2] really obsolete and should be removed, or are the empirical observations simply undefined behaviour? Dunno! Regarding [1], it was driving me nuts today, so if it really is order dependent, we should document to prevent insanity. Yup! In fact, I think when the following three calls are being used together, they have to appear in this specific order or they won't work right.. at least on win32 anyway: 1) icon() -- if used with xclass(), this must be first 2) xclass() -- if used with icon(), this must come after icon() 3) show() -- if any of the above are used, this must come last I guess the code has diverged a bit from the docs, or MS has changed things whilst we were nto looking... Also, I do think we should look again at STR #2816, as that improves the icon handling on *all* platforms anyway, and may be useful here. Selex ES 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] Multithreaded windows
Generally said, what I am trying to do is to make separate thread for displaying each window. I thought about creating multithreaded callback function for each window's redraw,or redesigning main loop's work, or something like that.The aim is to make each window run absolutely separately,so that if there is some ,for example, endless loop in one of it, you 'd have a possibility to switch to another window and continue work there. I know that maybe it's kind of wrong idea, but maybe you'll give me some clues for that, I really need that. thanks in advance. We might need to get more insight into what you actually need to achieve, before we can know how best to advise you, as there are multiple ways to get to the endpoint you describe here... Which is best for you, will depend on what you are hoping to achieve. So, anyway, some notes: - most host platforms only have a single graphics card, and access to the display through that cards is inherently serialised and single threaded - in particular, modifying the GUI context from multiple threads can be fraught with difficulties - threading is an option, but there are issues you need to take care of - many apps achieve the same effect by use of timer callbacks from a single thread - most host platforms very much prefer it if you access the graphics card from the main thread of your app, i.e. the thread in which the main() function was called; this thread is often anointed with special privileges that other child threads don't get by default... In particular creating / deleting / hiding / showing windows from a child thread often goes quite badly! (Only do that from the main() thread as a rule.) What I usually do is put all the GUI work in the main() thread, and spawn off child threads to do the actual work - these threads communicate back to the GUI thread via the Fl::awake(...) mechanism. However, with judicious use of Fl::lock() and Fl::unlock() the child threads can safely update widgets and windows that the main() thread has created. (Though the child threads must not call redraw() on the widgets - again, use of Fl::awake() is the way.) That's the basics for using multiple threads with multiple windows, I think - did that make sense? Did it help? The alternative (using multiple timer callbacks in a single thread to emulate multiple threads, might actually be simpler in many cases..) What is it you need to achieve? Selex ES 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] Multithreaded windows
Thanks a lot, that information was really useful, but I need to clear few more things. You are welcome - but as Roman has pointed out, this is off-topic for this list: I'll move my reply over to fltk.general, where it is more appropriate. Join us over there... (This list is for discussing development *of* the library, not with the library.) Selex ES 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.general] [FLTK 1.3] Filesystem list in Fl_File_Browser(STR#2935)
Michael Baeuerle wrote: I will add the test information to the STR and update the patch. Done. All - I'm looking at this patch #2935 and it looks OK, and Michael reports that it works well on the problem targets. I find it does not break my linux builds. I propose to apply this patch sometime soon'ish - hope to get to it during the course of today. Anyone have any objections? Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Filesystem list inFl_File_Browser(STR#2935)
Michael Baeuerle wrote: I will add the test information to the STR and update the patch. Done. All - I'm looking at this patch #2935 and it looks OK, and Michael reports that it works well on the problem targets. I find it does not break my linux builds. I propose to apply this patch sometime soon'ish - hope to get to it during the course of today. Anyone have any objections? Not from me, please go ahead. Thanks. OK - pushed at #9884 Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
[fltk.general] Thread moved: Was [fltk.development] Multithreaded windows
First of all, let me describe my task to make it easier for you to understand what I need. I am trying to make a multithreaded text editor. To what end? In most cases, manipulation of text is easy enough that a single thread can support multiple views into the same buffer - indeed you can easily make an editor based on Fl_Text_Buffer and Fl_Text_Editor that maintains multiple views into the same text buffer in separate windows. Though whether it is a good idea to do that or not I'm not sure...! (I'm not sure how safe the Fl_Text_Buffer implementation is if used like that, though I have actually done it...) Creating a multi-threaded tool to do this may be a lot of work, so you'd really need to be sure you needed it! Firstly I thought to make full process of redrawing of each window of the editor multi threaded, but as I understood from your arguments it's impossible because of graphics card restrictions. Not impossible. But tricky to do safely and robustly. Threads can be quite difficult... So my aim now is to make functionality of this windows multithreaded. All process of work with text editor is based on work with text buffer ( which in my design is unique for each window) and reacting on buttons callbacks like copy, open,etc. So, now my questions are: 1) Is it possible to make callback functions multithreaded? Maybe you can give some example? Not sure what you are asking here. Are you asking about putting the functionality of the callbacks, into separate threads? As a general rule, callbacks need to run in the context of the main() thread, and they really want to return as soon as possible. If you want to perform some long lived action, triggered by a callback, then it is best *not* to perform that action in the context of the callback at all. You can have the callback spawn a worker thread and return immediately, then reap the results of that worker thread at some later time, e.g. via an Fl::awake() call or a timer or some such... Is that what you mean? 2) The lags(long-term operations) in my program are unexpected by design so I don't know in which place to make FL::awake() to give control back to main thread. Um, that's not really the way it works. You call Fl::awake() from your worker thread any time you have changed something that you want the main thread to display. You do not give control back to the main thread, since all threads run at the same time, in parallel. So I guess I need to combine multi threading with timer callbacks mechanism. Like if window not responding for 2 sec, give control to another thread, while operation is still in progress. Again, that's not really the way it works - all the threads run at the same time, you don't really choose which runs when, so there is no scope to give control to another thread per se. The main idea is that you work in one window while some operation continues in another one. What are your ideas/experience about these? Maybe some example? So far, if i do some long-time loop in one of the window's callback function another just stops as well. Never do long operation in a callback, as that will stall the fltk loop. Always do long operations outside the fltk context (e.g. in a worker thread) or contrive for your long operation to call Fl::check() quite often... 3)How can I pass control back to child's thread from main thread? For example I made fl::awake() during some long-term operation,because user started input in other window but i need that operation to be done till end, so when user stopped input i want main thread to return to that position in child's thread where it was left. It sounds like you have misunderstood what Fl::awake() does... P.S. I I know that most of this things can be done ( and possibly easier) single threaded , but multiple threads is a must for this project. Thanks for your fast and informative response. I'm not sure how much experience you have of using threads, but it does not sound like you are that familiar with the techniques involved. You probably need to spend a little time getting more familiar with how threads work and how to make multi-threaded programs, as that foundation will make your project much more robust. Multi-threading is complicated to do well with current C/C++ tools, and very easy to get wrong (in confusing and herd-to-debug ways!) I'm not sure how to describe to you, how to make these things work, as I'm not sure how much understanding you have of the issues surrounding threading. What is your background in multi-threading? We can maybe build up from there? Selex ES 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
Re: [fltk.development] Article/video on Widget design - Was Re: [RFE] STR #2951: DoubleSlider...
Greg wrote: It occurs to me maybe I should write an article or make a video or something on how to make an FLTK widget, all the wacky details and implications. I wish I had one when I was writing Fl_Tree and Fl_Table, as there's a lot of stuff about keyboard nav and when() that I didn't know about until much later.. making it hard to go back and retrofit..! It would certainly be useful to have a set of hints on all of the areas that need to be considered, and in what order they should be addressed during development. For example, I rarely customize a new desktop and always stick to the default themes, so I have no idea whether themes have to be built in from the start, or if they are easy or difficult to retrofit later. It might actually be useful and fun to work through the design and implementation of a new widget, one step at a time, using such a set of hints, and eliciting feedback from the [widget] developers along the way, in order to (a) debug and improve the hints, and (b) give the basis for a Designing your own widget page in the documentation. Hi Duncan (and Greg), Yes, sounds like a worthy endeavour. Certainly seems to have rung a bell with Greg too! Cheers! Selex ES 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.general] FLTK Platform
If any of you are familiar with Netbeans, you will know that there is something called the 'Netbeans Platform', which is a pre-configured framework with all the standard bells and whistles for your average forms-based application: E.G. - Main Window - Menu (File, Open, Save, Help - all functional) - Toolbar with shortcuts to menu above - Perhaps an OK or Cancel button (ala MFC wizard?) - etc. Lately I have found myself writing quite a few new FLTK based apps and I always seem to be reinventing the wheel. Is there an out-of-the-box skeleton framework I can re-use for this purpose? If not then should I release one? I specifically need a v1.3.x example but it should exist for all versions I reckon. It's an interesting idea, but I have to confess I never found them (predefined templates and frameworks) all that helpful in the past. Certainly, I have had better (in the sense of being quicker, easier, and better tailored to my needs) results just throwing together an initial template in fluid then building out from that. But I have no idea what suits others in terms of workflow and such... Contributions welcome of course! Cheers, -- Ian Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widget that returns its top-level window
@manolo: Great -- agree with all, except perhaps loosing const here: - const Fl_Window *win = (const Fl_Window*)this; + Fl_Widget *win = (Fl_Widget*)this; I think we can maintain const protection on the variable this way: const Fl_Widget *win = this; : return ((Fl_Widget*)win)-as_window(); Does that not throw a warning (or even an error) about casting away the const-ness of win, though? Without actually trying it, I imagined that it might... Maybe that's what Manolo was hoping to avoid? ..this ensures const protection for all uses of win within the code, and we only turn it off when we need to (eg. the non-const as_window() call) That certainly sounds like a worthy intent, if it does not trigger any compile-time issues. I suppose we could do a more C++ish cast instead, so the compiler would know we really meant it! (i.e. const_cast) Also, I should probably change all instances of 'win' - 'w' in the code, since it's really working with widgets now. Yes, I guess that would be right. Thanks for the peer review -- will hold on comments regarding const above, as am curious if there's a reason not to. I think we should go for it... Selex ES 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 #2950: Menu Item behaviour
I have put the functions in Fl_Menu_Item namespace only because maming them that way seems to make sense. As far as I know, static functions (and static class variables) do not break ABI: they are not really class members, just additional ordinary functions and global variables with fancy naming sugar (functions with class namespace scope). For that matter even addition of a non-virtual class function should not break ABI either - any compiler guru can confirm this or am I wrong? I'm in favour of this change, if we are happy it's not ABI breaking. I'm not even sure, but Roman's discussion sounds right! Selex ES 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.general] Docking Panels
Can I use FLTK to develop a GUI with panels where I can, for example, drag drop different tabs from different dialogs/panels to other dialogs/panels - in short, move action items to menus, toolbars, panels, create new panels, etc. That is, can I use FLTK to create a dynamic GUI like that of MS-Office? I can use the most advanced object-oriented design techniques but I do want to know if FLTK does have the required functions. The glib answer is yes, you can do this. The more detailed answer is that you need to do a fair bit of groundwork first, since the native fltk widgets don't support that behaviour out of the box, so you need to derive your own container (e.g. from Fl_Group) that can handle the drag/drop events associated with moving the widgets form one to the other, and then do the various widget add/remove operations as required. Also, note that fltk has no layout manager per se, other than Fl_Pack (which I don't much like) so your container widgets would have to manage the positioning of their children as widgets are added and removed. Though Fl_Pack might be good enough for your needs? There are worked examples of this out in the wild. Indeed, if you have used fluid much to do GUI designs, you will have seen that you can drag and drop widgets from the fluid toolbar onto your GUI, and move them about. The concepts there are the same, pretty much... Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK-1.3 group button menus in wrong placewherearranged
2. This program still uses Fl_Pack. I had originally tried Fl_Pack to see what it would do. When changed over to Fl_Group, buttons lower in the window don't respond properly. It seems like the clicked button and above are the only responding buttons. I quit playing with Fl_Group since I couldn't remedy the unpredictable buttons. Sounds like you have put the buttons outside the bounding box of the group, so they don't get any key clicks. You need to ensure the parent group is sized to properly contain its children, or Bad Things can happen. Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Filesystem list in Fl_File_Browser(STR #2935)
I have tested the new code block for AIX on version 5.1 (which lacks the prototype for 'mntctl()' in the header file). I have tested the code block for NetBSD on versions 2.0 and 5.1 to check that the version detection works as intended (and old versions that don't support 'getvfsstat()' behave as before). OK, that sounds good; if you are feeling keen, might be worth recording those results in the STR in case anyone else is looking at it too? - The code doesn't seem to quite match the supposed fltk coding style, see: http://www.fltk.org/cmp.php#CS_GENERAL_CODING_STYLE for more guidelines. (I confess this is often an issue for me, the fltk style is not my default style...) Yes, the braces are not correctly placed. But this is wrong in many other places of the current code inside 'Fl_File_Browser.cxx'. I noticed that, too... To make it look consistent, should I repair this in the rest of the file too? I don't really know, but my feeling is that we should make the minimal change, so that people can more easily see what has *actually* changed. So... in that case I'd propose that you leave the existing code, even where it is wrong, but just try and make the new stuff be right. Does that sound sensible? What do others think? - Is there a possibility that the AIX branch can call free((void *) list); even if list has not been malloc'd? Would it be bad if it did? I have verified this before and initialized 'list' to NULL. 'free(NULL)' executes as NOP. This behaviour is required by POSIX and is documented in the IBM manual page too: http://pubs.opengroup.org/onlinepubs/7908799/xsh/free.html http://www.ualberta.ca/dept/chemeng/AIX- 43/share/man/info/C/a_doc_lib/libs/basetrf1/malloc.htm My intention was to make it obvious that the memory is released in any case. OK, agreed. - This is a nit-pick of mine, but I prefer: if (strcmp(/, filename) != 0) No problem, I will change this. As I say, it's a personal nit-pick of mine. I'd imagine the majority don’t' care either way! Cheers, -- Ian Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Filesystem list inFl_File_Browser(STR #2935)
I don't really know, but my feeling is that we should make the minimal change, so that people can more easily see what has *actually* changed. So... in that case I'd propose that you leave the existing code, even where it is wrong, but just try and make the new stuff be right. Does that sound sensible? What do others think? I've worked on projects which have had a mass reformatting to fit with some code standard, or new layout tool, and it's a nightmare. Trying to diff against the versions before the big change becomes useless, so trying to find code regressions becomes impossible. Urgh! Been there... useless anecdote follows One time, when we had to change the code to match some prescribed format, what we actually did was fed all the code through an indenter (ISTR we used astyle in practice) with the rules set to get as close as possible to the desired format. Did a reasonable job on the code, though messed up the comments a bit, particularly where the original authors had tried to lay out the comments with ASCII art and stuff... We then compiled the new code and showed that the resulting stripped binary was identical to the un-re-formatted version. And that became our baseline. All diffs were then against that code, in the new style. It pretty much worked, aided considerably by the fact that the diff tool we were using was language sensitive, so ignored changes in the comments, allowing us to progressively fix the messed up comments and put them back as originally intended. Though I'd not necessarily suggest anyone else go this path! Since then I try to keep the same formatting style as the old code. If you must, reformat the new/changed code only, but leave the old. Yes. Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] fltk and high res retina display?
Indeed, that did the trick! Thanks so much! I updated my make_bundle script, presumably fltk could do the same with the official one, provided there are no side-effects on non-retina systems. I think Manolo has already tweaked the plist files in the fltk-1.3 svn... Selex ES 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.general] Caps Lock detection
If I understand correctly, the capslock state info is correct during regular keypresses, just not when the capslock key is hit. Yes - in all the tests I tried, the Caps Lock state was always correct during (and after) regular key presses. However, any attempt to discern the Caps Lock state immediately after the Caps Lock key was pressed / released a few times, with no other key pressed since, was unreliable. (For X11 on Linux, in a VBox VM... real systems may be more consistent!) As a rider, I suggested in an earlier post that the OSX hosted VM was not even delivering the Caps Lock key down/up events to the hosted OS until the next regular key was pressed. However, subsequent testing using xev shows this is not strictly true; however, the keyboard state in the VM is so messed up by the flurry of events that are delivered (for a single Caps Lock key transition, I see half a dozen events, where a normal key sends 1...) that any attempt to discern the Caps Lock state (e.g. via XQueryKeymap or otherwise) returns unreliable status... Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Filesystem list in Fl_File_Browser (STR #2935)
I have found some problems with the file chooser on AIX and NetBSD operating systems and opened STR #2935 with a patch to fix them: Selecting File systems from the menu shows either nothing (not even the root filesystem on AIX) or many entries that make no sense or are not available (like swap partitions on NetBSD). The problem is that the method 'Fl_File_Browser::load()' can't determine the mount points correctly. Unfortunately there seems to be no portable way to get this information, therefore I have added special handling code inside '#ifdef' for both cases. Up to here the first part should not affect other operating systems at all. In addition the patch adds a general default section to show at least the root filesystems if all other options have failed (and show the root filesystem consistenly as / on all Unix systems). This second part may affect other operating systems but is completely independent from the first part. Is this patch acceptable? Hi Micha, The patch looks OK for the most part, though I have a few small comments; note also I have neither a AIX nor BSD system to actually test on, so this is just inspections really! - The code doesn't seem to quite match the supposed fltk coding style, see: http://www.fltk.org/cmp.php#CS_GENERAL_CODING_STYLE for more guidelines. (I confess this is often an issue for me, the fltk style is not my default style...) - Is there a possibility that the AIX branch can call free((void *) list); even if list has not been malloc'd? Would it be bad if it did? - This is a nit-pick of mine, but I prefer: if (strcmp(/, filename) != 0) instead of if (strcmp(/, filename)) simply because it reminds me that strcmp returns 0 for a match... I doubt most people care about that though! Cheers, -- Ian Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
Try the xkbvled(1) application. Do you find it too doesn't properly represent the shift lock LED? It also fails. I've tried this now with F17 and Ubuntu-12.10, hosted on Win7 and OSX 10.6.8, though in VirtualBox VM's in each case. I don't have ready access to another brand of VM to try at present. If anything, the Win7 hosted version might have been slightly better, but none worked right. Well, in passing, I poked at the VM's a bit more, though nothing useful arises... In summary, it looks as if the Caps Lock key is subject to special handling, probably both in X11 itself *and* by the VM. For comparison, the Num Lock key appears to map straight through to xkbvleds (and my own test code) entirely unmolested and can be read reliably within the VM. But the Caps Lock shows some unusual features. - With the VBox VM hosted on Win7: I can read the keyboard in real time with XQueryKeymap and see the Caps Lock key being pressed and released. I take this to mean that the VM is passing the key stokes through pretty much unmolested on Win7. However, the state reported for Caps Lock (either by X11 or by fltk) does not reliably reflect the true state until after the *next* key is pressed (sometimes it is OK, but not often enough to be considered reliable!) This, I *assume* is special handling within X11 in some way. Num Lock is always fine, AFAICT. - With the VBox VM hosted on OSX: When I read the keyboard in real time with XQueryKeymap I *never* see the Caps Lock key being pressed and released. It just never seems to get flagged, ever. I take this to mean that the VM is NOT passing the Caps Lock key stokes through at all. I think the Caps Lock state is somehow only coming through to the VM on the next key stroke. As a result, the state reported for Caps Lock (either by X11 or by fltk) does not reliably reflect the true state until the *next* key is pressed. So in this case, it would appear there is special handling of the Caps Lock key by *both* the VM and by X11. Num Lock is always fine, AFAICT. The end. Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] RFC: method to find top level window?
ISTR that we discussed adding such a method a while ago, Oh! Now that does seem somehow familiar... When I saw Greg's post, it did sort of seem like we'd been here before, but... and that it probably wasn't done for some reasons. Though I can't (now) imagine why not. It sounds perfectly sensible... However, thinking about it, I don't know what this might have been. Too simple ? What, if the top-level window still has a (non-window) parent widget? Does it matter ? I don't know. Oh, like a window enclosed within a group or something? I dunno... Anyway, since it's not much code, could we probably add it to the header file as an inline method ? Would an inline method in a header file be DLL friendly though? Though that would limit the ABI impact I guess. I think so. If there were a vote request, my vote would be +1, unless there are reasons not to do it that I don't know of (yet). Other opinions, votes? I can't think why we wouldn't have this; I can’t immediately spot any downside. I'd vote +1. -- Ian Selex ES 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.general] Caps Lock detection
X11's own KeyRelease events seem to behave similarly; in my tests with the pure X11 code below, when X11 sends a KeyRelease event for the capslock key, the event.xkey.state shows accurate info when capslock is ENABLED, but INACCURATE INFO when capslock is disabled. You have to hit some other key to get the accurate state of capslock after lock release. Yes - though with Howard's example I find (on a F17 VM, not a real computer) that (as Howard said) quite often (not always!) just wiggling the mouse about in the window gets the state to update correctly... (Or, hitting the space bar always seems to!) So, something in the state is getting updated by other events, and perhaps not just the X11 KeyRelease ones? Or I'm missing the point again... Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Caps Lock detection
I tried the following FLTK code with the above X11 only code and it seemed to work more reliably. Not so much for me - though that may be an issue with the VM rather than a real problem. I find that, with this code, if I toggle Caps Lock on/off a few times, I can easily get to a state where the test code is resolutely reporting Caps Lock OFF, but the keybd LED is ON. Hitting any key (focus to any window) then seems to fix it up... Also, I tweaked the Tiiner_CB to show what fltk's event_state shows for FL_CAPS_LOCK, and it is not always (at least for me) the same as the X11 XkbGetIndicatorState seems to be showing... Which seems... odd... Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK-1.3 group button menus in wrong place whe rearranged
Oh! I was mid-reply, and I see Albrecht has already said most of what I was
going to say...
So it appears that when a previous button in the group is removed, the
button's menu position doesn't get updated.
As Albrecht said, the way Fl_Pack behaves in practice is probably not what you
want for your use case.
I have to confess I don't much care for Fl_Pack in general; every time I tried
to use it, I ended up in difficulties.
Albrecht suggests deriving your own container from Fl_Group - this is probably
the best bet; looks like more work initially but in practice it will be easier
as it gives you so much more control over the way your widgets are positioned,
sized and redrawn...
Albrecht also suggests a workaround based on timers. I think this might work
out pretty well, though I'd consider having my own derived Fl_Pack (or similar
container widget) that, in its derived draw() method, sets a flag to tell
whether the draw has actually been enacted (and hence the sizes properly
recalculated) and have that flag cleared down by the callback that triggers the
timer.
The timer can then poll until it sees that the widget has been drawn (the
flag is re-set) and thence that the sizes ought to be correct, for popping up
the menus now...
Well, something like that...
Also, some entirely spurious critique of the example code, for no other reason
than I was part way through rewriting it anyway...
static Fl_Font LFONT = FL_BOLD;
Would be better to say:
static Fl_Font LFONT = FL_HELVETICA | FL_BOLD;
Which is actually the same thing, but makes it explicit: It is (kinda) just
chance that FL_BOLD on its own works (since FL_HELV... == 0). Really it is
meant as a modifier, not a name in its own right!
class Sbut : public Fl_Menu_Button
{
public:
Sbut (int i);
~Sbut ();
static void onButton ( Fl_Widget* w, void* v);
int handle ( int event );
int i() { return _i; }
int _i;
/// char* _cstr; // not really needed
};
//cc
Sbut::Sbut (int id )
: Fl_Menu_Button( 0, 0, 100, 50)
{
//cout Sbut(s) 0: id endl;
_i = idx;
callback(onButton);
//_cstr = new char[sizeof(int)]; // not needed, and maybe too small
anyway?
char _cstr[16]; // use a stack automatic temp instead, cheaper than
calling new
sprintf(_cstr, %i, id);
// label(_cstr);
copy_label(_cstr); // use copy_label so the widget manages the label
string for you
//cc
Sbut::~Sbut ()
{
// delete _cstr;
}
//***
int main (int argc, char **argv)
{
WIN-end();
//WIN-resizable(G1);
// With a pack, it may be that...
WIN-resizable(WIN); // might work out better...
// Passing argc, argv to show() ensures that fltk picks up
// the system default settings... Useful on some host systems.
WIN-show(argc, argv);
return Fl::run();
}
Selex ES 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 mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] fltk and high res retina display?
There is kWindowHighResolutionCapableAttribute but it's for Carbon. The implication seems to be that for Cocoa apps it should just work. Any of the more mac knowledgeable sorts know what's going on here, or should I keep poking through the apple docs? And by Any of the more mac knowledgeable sorts I guess you mainly mean Manolo, since he was the driving force behind the Cocoa porting! I have no ideas myself... Selex ES 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.general] best way to get an int from Fl_Menu_Item user data
marty wrote: long li = (long)v; works fine. Yes; this is a good option, everywhere *except* Win64... On Win64, a long is still only 32-bit (everyone else decided that in their 64-bit generation a long would be 64-bits, but MS decided they needed to preserve the sizeof(long) == sizeof(int) relationship that is assumed in the WIN32 API...) So, probably, fl_intptr_t is the more portable choice. Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] [FLTK 1.3] Fl_Helpview doesn't take care of br?
I tried to show some html-text for help, but Fl_Helpview doesn't take care of br and mucks up formatting. Doc tells, Fl_Helpview should take care of br, shouldn't it? Hmm, yes, that does seem a bit broken... As a hackaround, it looks like replacing b with p/p seems to do something... Any good? Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk3 compile error
marty moore said: Hi all, I get the following error when trying to compile fltk3: $make === making src === 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 marty@fltk-3.0.x-r9831$ I'm running debian 6.5, emacs 23, and gcc 4.4.5-1. libpng3 and libpng12-0 are installed. Anyone have any ideas?? Yes: note that fltk3 is still alpha, and is intended for experiments only at this stage, so has a few rough edges. What you are hitting is STR #2833 http://www.fltk.org/str.php?L2833 In summary, there is a bug in fltk3's configure mechanism such that it attempts to build fltk's built-in PNG lib version, even if there is a system wide one available. (The earlier fltk variants only compile the built-in PNG lib if there is no system-wide one found...) However, when building the built-in PNG, the system PNG headers get found first, and they are *not* compatible (too old), and Bad Things ensue. If you can be bothered, tweaking the paths in makeinclude so that the correct set of PNG headers are found when building the local built-in PNG lib will fix this. Or, you could try configuring with --enable-local-png as I think that might help... Or, you could update your system PNG to something recent, and that should help to! Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] RFC: Adding when() support in Fl_Tabs
Actually, some elaboration; tests revealed a subtlety I wasn't aware of: Huh; that's not quite what I expected, either. Though, now I think of it, I'm not sure what I *did* expect the behaviour to be. I only rarely use the when options, so had (at best) a vague notion of how they interacted, but apparently that notion was incorrect in the details... I wonder if it is worth poking at a few non-radio buttons and see if that is the same or whether some of these behaviours are peculiar to the radio-button case? Selex ES 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 '@' symbols question
I'm working on fixing STR #2772 (removing extraneous code in fl_measure()) and need to understand in detail how we support '@' symbols in FLTK. Eek! That seems brave! (To me, at least!) Selex ES 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] fluid - Adding win32 icon
- I know it is normal for MS stuff to call the resource file just resource.h, but it seems suspect to me; we should call it something that makes it clearer what it is, even fluid_resource.h would be better, IMHO. Also, there's cruft in there we do not need for the simple case of adding an icon, anyway. Ok I will try to fluid_resource.h filename and removing all unecessary lines. I note that the Sudoku demo in the test folder calls these files sudokurc.h and sudoku.rc, though they have not been de-crufted as I was suggesting... That naming pattern might make sense though? At least to be consistent? As far as I know (and I'm not exactly an expert here! Win32 is not my main thing...) then all you *need* to have in these files is something like... --- my-icon_hdr.h --- // Win32 icon resource header file #define IDI_ICON 101 // End of file --- my-icon.rc --- // Win32 icon resource file #include my-icon_hdr.h // Icon with lowest ID value placed first to ensure application icon // remains consistent on all systems. IDI_ICONICONDISCARDABLE media/my-icon.ico // End of file It seems that the rest of the stuff that is in there is not really necessary. I think... - If we are going to do this, then the provided icon in the fluid/icons/fluid.ico folder needs to be improved; it does not have enough of the bigger sizes for the modern systems, so looks a bit duff most of the time. Clearly, yes. I have not succeed to include the png provided into th resource. I am on it, But don't have good resource editor. Is there not one built in to the VS tools? Last time I looked (which may have been VC6!) ISTR there was... Or maybe that's false memory syndrome? In any case, the web seems to have plenty of tools for editing Win32 ico files, so you'll easily find something that works. Another point, is Visual Studio 2012 project files are welcome ? I have migrate (by duplicating) the existing one to VS 2012. If anyone is interested. Can VS12 cope with the existing project files? If so, we'd rather distribute (and maintain) the smallest set of project files that actually work, so if VS12 can handle the existing project files correctly, then that is better for us. That said, if you have working VS12 files, then maybe you can post them on an STR so that others can find them... You never know, someone might find them useful in the future. Selex ES 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] fluid - Adding win32 icon
Clearly, yes. I have not succeed to include the png provided into th resource. I am on it, But don't have good resource editor. Is there not one built in to the VS tools? Last time I looked (which may have been VC6!) ISTR there was... Or maybe that's false memory syndrome? In any case, the web seems to have plenty of tools for editing Win32 ico files, so you'll easily find something that works. Doh! I suppose it would have helped if I'd said what I actually use, too... I use Matthias S. Benkmann's png2ico, which is a nice little command line tool for the job, you just make up your PNG's in the sizes you want then do: png2ico my-icon.ico image16x16.png image32x32.png (...etc...) And that seems to do the trick just fine. Selex ES 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.general] fltk2.0.x-alpha-r9296 missing
The 2.0.x branch is missing from the download area and the trunk does not compile out of the box. Note that these two observations may not be un-related... fltk-2 is, as you know, deprecated, and no one is available to maintain nor fix it, so we can't really go on distributing it, until it gets fixed... Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Tabs: How to find the tab that is clicked upon
On 03/25/13 05:16, testalucida wrote: _ /x\ o I'm interested in click x but not in click o. What Ian said, and I'd offer that setting when(FL_WHEN_NOT_CHANGED) /should/ work for your case, but does not. Yes; I tried that too, to no avail... However, I now think we may be missing a real easy trick here. Fl_Tabs has an (apparently undocumented) public method which() that takes (int event_x, int event_y) and returns non-zero if it hits a valid tab... Well, I think that's what it does, anyway... So, harking back to testalucida's original query, he had the event positions from his handle() method, so this might be enough to get him sorted out? This is probably a bug in Fl_Tabs; I opened STR#2939 http://fltk.org/str.php?L2939 and suggested a patch there which makes that work, e.g. Looks about right - though I do wonder if it is a bug or not? Do we want to be able to reselect an already selected tab? Dunno... Though if FL_WHEN_NOT_CHANGED is set, maybe it should allow the tab to be reselected...? Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Widget ordering in group
I have a window with full of widgets made with fluid. Some of them are text fields to be user filled in order. When I hit the tab key to change widget focus, the ordering is haphazard. Do widgets in groups have a tab-key ordering ? How do you change the order? Can you change the ordering between two widgets. I think they are navigated in the order that they are added to their parent group, are they not? So, if they are ordered in fluid in the way you want them, that ought to pretty much do it. Does that not work? Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fltk Preferences are noisy...
Yes indeed; that looks like the same issue. Does look like something that could be changed without harm, too. Be handy if someone who is familiar with the preferences stuff had a view on this - Matthias' DSL is back on we hear; maybe he's still a little busy after the moves though! I think there was alreay a STR for that (with a possible solution): http://www.fltk.org/str.php?L2823+P0+S-2+C0+I0+E0+QFl_Preference Cheers, chris Widget handle() method upon first use calls Fl::visible_focus() which through Fl::option() reads fltk standard preferences (that is (Fl_Preferences::SYSTEM, fltk.org, fltk) and (Fl_Preferences::USER, fltk.org, fltk)). Fl::option() function (Fl.cxx, line around 1944) just constructs these preferences, uses only get() methods and then destructs these preferences. However upon destruction the preferences are flushed/re-written on the disk. Is that necessary if only get() methods are used and preferences are not changed? R. Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] fltk1.3 namespace in fluid
I am trying to port my software from flkt2 to fltk1.3. However fluid1.3 complains due to lacking namespaces. Any chance of adding namespaces to fluid1.3 or a work-around? Gonzalo, I've opened STR #2936 for this feature request, so that it doesn't get lost. Oh, was Gonzalo asking whether fluid could support namespaces? I had thought he was asking if fltk-1.3 itself would have namespaces (which for compatibility I guess it can't). I suppose in fluid a namespace might be entered a bit like a grouping widget, such that other entities would be declared nested inside it? Is that the sort of thing? Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] R: Re: R: Re: Smooth blinking
just pure Linux amp; microwindows on a 400 MHz PowerPC embedded platform ;-) If you have a 400 MHz PPC, is microwindows the best choice? That should be easily able to run a real X11 server, (I'm thinking of the TinxX / K-drive stuff, for example.) I only ask because (admittedly a *long* time ago now) I had a project using microwindows and it was just a world of hurt - it was really awful. So we switched to a real X-server and then things Just Worked. That said, I am led to believe the microwidows got a lot better since then, but I was too badly burned to consider going back... Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] maximize, minimize to taskbar and open again
Maximizing a window, then minimizing it to an icon in the taskbar, and then opening that same icon creates a window that covers up to the taskbar, but it is behind it. The problem shows in all demos of fltk2.0. Fltk1.2 seems fine. Can somebody help? Gonzalo, Do you *really* mean fltk2.0 and fltk1.2? Sorry. I meant fltk2.0 and fltk1.3. Ah, right: OK, then note that the fltk-1.x was buggy in this area too, but a lot of work was done to try and resolve that. In particular you need to look at the changes that went into fltk-1.3 in the Fl::screen_xywh(); and Fl::screen_work_area(); methods. These were adjusted to take better account of the position of taskbars and so forth, and to do more sensible things in that regard. Note that the changes were not limited to these functions - they propagated into many other places in the library where these functions were used (e.g. when computing the placement of menus and dialog boxes and so forth) so ended up being pretty involved. I don't know what svn rev numbers are pertinent, but there were some relevant STR's that covered this work, so it may be possible to find those and see what was done. I don't know fltk-2 well enough to say for sure, but I doubt that importing the fixes into fltk-2 would be trivial...! Though, fltk3 may have the equivalent functionality now? Not sure. Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Smooth blinking
You have to realize a blinking message, or an object which
periodically swaps two images :
think of an alarm icon.
The alarm is sounding, and the icon keeps alternating red/yellow horn
images until the user pushes the ack button.
Use a timer to blink... but things are not always smooth blinking.
Not a big problem, anyway... just would like to know if there is a
clever way to assure a smooth blinking
(usually we are speaking of small objects).
Not really sure this is what was being asked, but here's a simple demo of
blinking widgets.
Maybe this is what was wanted?
--
//
// Flashing Boxes
//
#include FL/Fl.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Button.H
#include FL/Fl_Box.H
static Fl_Double_Window *main_win = 0;
static Fl_Button *quit_bt = 0;
static Fl_Box *box1 = 0;
static Fl_Box *box2 = 0;
static void cb_quit(Fl_Widget *, void *) {
main_win-hide();
} // cb_quit
void update_box1(void *) {
static int state = 0;
if(state) {
state = 0;
box1-color(FL_GREEN);
}
else {
state = -1;
box1-color(FL_RED);
}
Fl::repeat_timeout(0.7, update_box1);
box1-redraw();
} // update_box1
void update_box2(void *) {
static int state = 0;
static int step = 1;
const int thd = 15;
state += step;
if(state = thd) {
step = -1;
}
else if (state = 0) {
step = 1;
}
float alpha = (float)state / (float)thd;
Fl_Color col = fl_color_average(FL_RED, FL_BACKGROUND_COLOR, alpha);
box2-color(col);
Fl::repeat_timeout(0.05, update_box2);
box2-redraw();
} // update_box2
int main(int argc, char ** argv) {
main_win = new Fl_Double_Window(370, 230, Flashing Widgets);
main_win-begin();
box1 = new Fl_Box(10, 10, 60, 30, ALERT!);
box1-box(FL_FLAT_BOX);
box1-color(FL_GREEN);
box2 = new Fl_Box(80, 10, 60, 30, ALERT!);
box2-box(FL_FLAT_BOX);
box2-color(FL_BACKGROUND_COLOR);
quit_bt = new Fl_Button(300, 190, 60, 30, Quit);
quit_bt-box(FL_THIN_UP_BOX);
quit_bt-callback(cb_quit);
main_win-end();
main_win-show(argc,argv);
Fl::add_timeout(0.3, update_box1);
Fl::add_timeout(0.05, update_box2);
return Fl::run();
} // main
// end of file //
Selex ES 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 mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Correct way to fire graphics updates from abackground thread
The question: what is the correct way to fire a graphics update from a thread ? Others will probably chime in and tell you more about programming with threads and FLTK. Ah... That quite possibly means me then... OK, at a high level, it goes something like this: Firstly, a caveat: Rendering to the display device from any thread other than the main thread is not robust (may work on some systems, will fail in horrible, hard to debug ways, on others, so do not do that.) Instead, all drawing is done from the main thread. In particular, note that creating/deleting/hiding/showing windows *has* to be done by the main thread. However, if you create your widgets in the main thread, you can alter them from other threads quite safely, if you use the fltk locking methods. You can signal updates between threads using Fl::awake(); there's no need to get fancy with pipe's and so forth (fltk is handling that internally) and it is more portable. Here's a simple recipe for this: - in the main thread, before you create any windows, call Fl::lock(); *just once* to enable thread support. (Do not do any more locking/unlocking in the main thread, let fltk manage that for you.) - in a worker thread, if you want to update a widget, do: Fl::lock(); my_widget-change_this(); my_other_widget-change_that(value); etc.; Fl::unlock(); Fl::awake(); And that should update the widgets in a thread-safe way, then flag the main thread to manage the redraw sequence. Note that Fl::awake can also be passed a callback function - the main thread will then execute that callback in its context, allowing the worker threads to do some operations that would not otherwise be allowed (e.g. you may be able to use this to create new windows under the control of a child thread, since the actual creation will occur in the context of the main thread.) However, that is often not necessary, the simple case I outlined above covers a lot of use cases. Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Correct way to fire graphics updates from a background thread
In my first app I used Fl::lock, but when the app is growing I have to be careful not to create deadlocks, as threads can communicate with each other. Sure; but the Fl::lock() is a mutex, so you must only take it immediately before you want to modify the widgets, and you release it as soon as possible. You never hold the lock for any longer than is necessary, and you do nothing but fltk GUI operations within the lock, so there should be no scope for deadlocking. That said, if you need to be handling incoming data asynchronously (and at a high rate) you want to be separating that out from the GUI update process anyway - see Edzard's note on queuing up data for processing, then dealing with that at user rates, not at input rates. Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Bargraph object with Fl_Group
Each whole page is a group-derived object ; I keep a list of pointers to these objects and jumping to another page is easy. Just make the current group invisible and make visible another. The redraw() caused by the bargraph goes to the current visible page group ; a typical plant can have 20-30 different pages. OK: but my suggestion was that you have groups nested within groups, so that the redraw's can be localised to just one specific sub-group... Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Bargraph object with Fl_Group
Messages from the plant data driver can arrive at different rates (say from 200 ms up, depending on what is written in the config file) ; if I fire a redraw() each time I receive the bargraph level my CPU utilization for the graphics app goes from 4-5% to 60%, so I simply redraw() when the new bargraph value is different from the previous. Yes, checking for differences, and only then triggering a redraw, is a useful optimization in most cases. Note that it can also help to limit the refreshes even in that case - e.g. have an Fl_timeout that fires every so often (say 1 Hz) and triggers the redraw based on the latest state, ignoring any intermediate inputs... Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] R: Bargraph object with Fl_Group
Simply forced redraw() of the parent solved the problem. It's a bit inefficient, because if the parent is a big window with many objects I have to redraw everything. Masked by redrawing only when the bargraph value changes, for now. Any way to invalidate to the parent only the bargraph area ? Derive a widget from Fl_Box to draw your graph, and have its handle method do the actual drawing etc. Set the boxtype of your derived widget to a BOX rather than a FRAME type (and certainly NOT to NO_BOX) and then the background should be handled automatically. FL_FLAT_BOX is probably favourite for this sort of thing. Deriving from group is probably a Bad Thing here, since IIRC the default boxtype for a group is NO_BOX, which probably explains the behaviour you are seeing? Indeed, simply setting the boxtype of your group might actually help... Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] R: Bargraph object with Fl_Group
thanks for your answer. I am writing to you directly, Best not - I very seldom reply to off-list posts... will post solutions on list ; for now maybe there is a bit of misunderstanding, I try to explain better. The object is a bargraph, let's assume the classic vertical one ; a green rectangle on a white background. Can derive from Fl_Group or, better as you say, from Fl_Box. The problem comes when I want the white background to be invisible: I would like to see a green rectangle growing or shrinking representing a tank level. If the background is invisible I can place the object over a photo of a plant, for example. OK: Then you need to composite the bar graph on top of the image. Fltk does not provide support for transparent widgets (yet) as it is a hard thing to do in a consistent cross-platform way, so the best bet may be for you to just blit the image into the box, then render the bar on top of it. This is easy and cheap to do, if you are rendering the graph on top of an image your app owns. If you want to render the graph transparently on top of (for example) the desktop then you are on your own out there, since fltk can't really do that without a lot of platform specific code...! Hope that made sense! FWIW, I think Greg's cheat pages have examples of doing some of this, so it would be worth a look... http://www.seriss.com/people/erco/fltk/ Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Missing scandir() (STR #2687) - now STR #2931
Michael Baeuerle wrote: I will test on the other systems this evening ... Tested again on NetBSD, AIX and HP-UX. Still works on all of them. Great, thanks... Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Invalid messages showing up in fltk.general
PS. I haven't checked, but maybe this is only a problem with Firefox. No, I think I have seen that with other browsers too - sure IE does, think Safari does... So, anyway, not a Firefox feature! Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Question about Fl_Input
But, I'm still thinking that loading a musical font is the best way
to go, and on that basis I was keen to show how to measure a font
symbol so that you can render it in the right place.
And I was rushing anyway...!
Really, I meant for the code to support resizing, but the version I
posted doesn't (yet) - though the bits for that are more or less in
place. Probably today...
OK - lunch break over; here's the revised version.
It should now support resizing and do something reasonable.
Also;
IF you are on a Windows platform,
AND you create a folder called fonts under the build folder,
AND you place a copy of Musica306.otf in the fonts folder,
THEN there's a fair chance that the code will use a real treble clef glyph...
Musica306.otf is the font file for version 3.06 of George Douros' Musica font,
which looks OK on the screen and is fairly free.
I wonder where to download it? Hmm, maybe here?
http://users.teilar.gr/~g1951d/Musica306.zip
I did this on the wild assumption that Edgar probably has access to a Windows
machine...
This code (Windows build) tested on Win7 with Msys/mingw, and works nicely.
--
//
// Test demo - draw a staff
//
// fltk-config --compile staff-demo.cxx
//
#ifdef WIN32 // need this dance to make font handling load on Win32
# define _WIN32_WINNT 0x0500
# include windows.h
#endif
#include FL/Fl.H
#include FL/Fl_Group.H
#include FL/Fl_Double_Window.H
#include FL/Fl_Button.H
#include FL/Fl_Box.H
#include FL/Fl_Output.H
#include FL/fl_draw.H
#include stdlib.h
#include stdio.h
#include time.h
// some widgets we will use...
static Fl_Double_Window *main_win = 0;
static Fl_Button *quit_bt = 0;
static Fl_Button *repeat_bt = 0;
static Fl_Button *note_bt[8]; // 8 note names is enough for now...
static Fl_Output *out_txt = 0;
static int score = 0;
// Special platfom code to handle app specific fonts under Windows
static int have_music_font = 0;
/*/
static void load_extra_font(void)
{
#ifdef WIN32
/* Load the font using the Windows API */
have_music_font = AddFontResourceEx(./fonts/Musica306.otf, FR_PRIVATE, 0);
#endif
/* setup the extra font */
Fl::set_font(FL_SYMBOL,
#ifdef __APPLE__
Musica);
#else
Musica);
#endif
} // load_extra_font
/**/
static void free_extra_font(void)
{
#ifdef WIN32
if (have_music_font) {
DWORD fl = FR_PRIVATE;
PVOID pdv = 0;
RemoveFontResourceEx(./media/Musica306/Musica306.otf, fl, pdv);
}
#endif
} // free_extra_font
/**/
// class to display the staff
class staff_view : public Fl_Box {
protected:
void draw();
public:
// index used to hold the current note. Only 11 values used here,
// 0..10, for notes D to G, since I can't be bothered drawing any
// ledger lines...
// For ease, I have made D == 0 here, but we really want A == 0 later
so... yuck..
int note;
// constructor
staff_view(int X, int Y, int W, int H) : Fl_Box(X, Y, W, H), note(0) {
};
};
void staff_view::draw() {
static char clef_G[2] = {'G', 0}; // a G clef... sort of...
// U_treble_clef = 0x1d11e; Unicode code-point for a treble clef
static char treble_clef[5] = {0xF0, 0x9D, 0x84, 0x9E, 0}; // a G
clef... as UTF8
Fl_Box::draw(); // draw the base-class box first to give us an outline
to fill...
// determine some limits for us to draw staff lines into
int ww = w();
int hh = h();
int gap = hh / 8; // space between the lines...
int ht = gap * 4; // 5 lines, 4 gaps...
int yo = y() + (2 * gap); // Y origin
int xo = x() + 20; // X origin
int len = ww - 40; // staff length
int xe = xo + len; // X end
fl_color(FL_BLACK); // set the colour first
fl_line_style(FL_SOLID, 2); // then set the line style
// draw the endcaps... this is not pretty code...
// get rid of all these dodgy hard-coded offsets...
fl_line(xo, yo, xo, yo + ht);
fl_line(xe-8, yo, xe-8, yo + ht);
fl_line_style(FL_SOLID, 4);
fl_line(xe-2, yo, xe-2, yo + ht);
fl_line_style(FL_SOLID, 2);
// draw 5 lines for stave
int yl = yo;
for (int idx = 0; idx 5; ++idx) {
fl_line(xo, yl, xe, yl);
yl += gap;
}
// draw the clef - measure the clef symbol, so we can figure out where
to draw it...
int dx1, dy1, cw1, ch1; // for real clef
int dx2, dy2, cw2, ch2; // for fallback clef
if(have_music_font)
{
// get the music font, and ask for it a bit bigger
fl_font(FL_SYMBOL, (ht + (gap * 3)));
Re: [fltk.development] FLTK version number update and release process [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packaged properly]
1) For large commercial software, I have a VERSION file in the main directory with a single line in it: VERSION=#.# This can be include'ed from Makefiles to define macros used on everything from compile lines to Makefile construction to documentation builds and tar filenames. In some way, the value in Enumerations.H is what we'd want to pick up - but that is not perhaps the most accessible format for it? Oh, and another question: WHEN do we upgrade the version number(s)? (a) immediately after one release, for the next release, or What Mike said: As soon as *anything* in SVN changes after a release, we need to bump the version numbers in some way. Ideally, I suppose, we might bump it to a temporary number, then change that to the formal number for the next release, so that folks can determine if the build they have is a formal release or some svn checkout or something...? (I sort of have this in some of my own builds, where the Makefile calls a script, which calls svnversion -n . at build time to get the rev number from the rep,o and writes that into a version.h header that the code pulls in. For formal releases I can override that behaviour to put in an actual number... The downside is that I can only build this on hosts that use Makefiles and have svn installed, which can be a pain on some Windows machines...) Selex ES 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: decision on license to use forfltk/examplessource code
IIRC I haven't seen a real freeware (public domain) proposal. Wouldn't this be appropriate for the example code? I see Mike's already said this, but thought I'd re-iterate: way back when, in my naivety, I went looking for a Public Domain license, and was told that such a thing really doesn't work well, as the whole concept of public domain doesn't even exist in a lot of legal systems... As ever, IANAL... Selex ES 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.general] Question about Fl_Input
Is it possible to send text typed into an Fl_Input box to another box
without using a callback via an enter button?
Sure; pretty much any fltk widget (including the windows themselves) can be
associated with a callback.
So for a Fl_Input you can set the when() as FL_WHEN_ENTER_KEY, then if you hit
the enter key, the callback for the input widget should run.
If this can work, what functions would be used and could you provide a
short statement for syntax?
Also, if I am wanting to loop this series of events, how would I go
about this if the Input box and the other text box are dynamically
allocated? Should they be destroyed and recreated with each iteration
to avoid memory leaks?
Can you clarify; I'm not clear what you are asking here, can you outline what
you are trying to achieve, then we can suggest some ways you might implement
that.
Anyway, here's a little fluid file that might show how the enter key stuff
works...
--
# data file for the Fltk User Interface Designer (fluid)
version 1.0302
header_name {.h}
code_name {.cxx}
decl {\#include stdio.h} {selected private local
}
Function {} {open
} {
Fl_Window main_win {open
private xywh {856 299 543 337} type Double visible
} {
Fl_Button quit_bt {
label Quit
callback {main_win-hide();}
private xywh {455 280 80 45} box THIN_UP_BOX
}
Fl_Browser brws {
private xywh {40 80 405 245} box THIN_DOWN_BOX
}
Fl_Input input_widget {
label {input:}
callback {printf(Enter key hit: value is %s\\n, input_widget-value());
fflush(stdout);
brws-add( input_widget-value());}
private xywh {65 31 190 28} box THIN_DOWN_BOX when 10
}
}
}
--
Ian
Selex ES 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 mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] change labelfont and labelize in fltk 1.3.2
Thanks for responding, Greg. I made an error writing the report from the compiler. The code is a copy from the hello.cxx on the fltk.org site. The compiler statement actually reads : /hello.cxx:7: undefined reference to 'Fl_Box::Fl_Box(int, int, int, int, char const*)' Assuming your code is short, post it here. I'm guessing you have forgotten to include the FL/Fl_Box.H header files... 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] change labelfont and labelize in fltk 1.3.2
Hmm, the error message is a linker error, so the compiling stage should have passed successfully. Maybe a library version mix, as I wrote in my other post? Oops, oh yeah! 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn'texactly native on linux
AFAIK kdialog is often distributed with KDE, which isn't the case for zenity/Gnome. Of the gnome-using boxes I have ready access to, the Ubuntu 12.10 and F17 versions do appear to have zenity, but some others do not (though these are for particular uses and may be atypical!) But there's still the issue of coming to depend on it, if we can not be sure it is always available... But in any case, as long as we can fall back to the fltk built-in chooser, then the user will always get something, so maybe that does not matter? In any case: We still need to address the issue of guessing what desktop the user is running and then choosing either zenity or kdialog accordingly... There is a env variable XDG_CURRENT_DESKTOP and should indicate the name of running desktop; however, the variable was added silently (which is unfortunate) by Canonical, RedHat, who knows, and there is no definitive spec about it on freedesktop.org. You can check how it is used (with a couple of hacks for other desktops) at http://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-utils- common.in (search for 'detectDE'). That might do, though I'd worry about ending having to maintain a list of different distros and so on; I guess what I had envisaged was a magic env var that said I am gtk-based or I am KDE/QT based. For example, gnome and mate are shown as being different values, but AFAICT from our perspective they are The Same Thing... (Also XFCE, it's GTK based too, is it not?) And so on... Also to not forget 'xdg-file-dialog' intended to be portable among desktops and if another desktop adds a tool like kdialog, it will probably end up there. Yes, that might be a better option, insofar as, if the distro implements it, then *should* sort out the choice of host file-chooser for us. But of course it triggers all of Mike's concerns about execing external processes and so on, since it is a shell script wrapper for zenity and kdialog... It's tricky... 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.general] Missing scandir() (STR #2687)
Though we need to be cautious about not breaking the alternate implementation of fl_scandir() given in scandir_win32.c also. Maybe the win32 version needs tweaked to match the more const-correct prototype anyway? I have made the default prototypes for all 'scandir()'s and the sort functions to be POSIX compliant. Leaving typecasts only for the cases this doesn't match. Anyway - if you have the bits for this working, would it be possible for you to create an STR and upload the files there? After testing it inside the source tree I will open an STR. Great. Thanks. 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Unable to change labelsize and labelfont fltk1.3.2
We have built FLTK1.3.2 on x86 with the following configuration $ ./configure --prefix=/home/sachin/FLTK1.3.2_test/ --enable-threads -- enable-shared --enable-gl --enable-Xft --enable-x11 --with-x --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib What host system are you building on? And is it necessary to force the X libs like that? I guess you are cross-compiling for an arm target, but would perhaps need to know more. Or are you building on the arm system itself? If so, forcing the X values for configure is probably not helpful, it would be better to let the configure script find the X values for itself I think... If you are cross-compiling, should you not be setting the X values to point to the arm target files? Those look like paths to host files you see, and that seems odd to me. When we run the test/fonts.cxx we are not able to choose between the fonts and the font size on the X window.It shows the default. Hmm, I don't know what that would be. I ran your sample code on several machines, including a linux/arm board, and it worked fine in each case. Which is why I have to assume that something is awry in the configuration of the build, since the code itself seems to be OK... 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] change labelfont and labelsize?
On 18 Feb 2013, at 22:38, edgar wrote:
Hi.
I am not able to change labelfont() and labelsize() in fltk-1.3.2
I am using the g++ compiler and Ubuntu 12.10.
Here is an example of the code with Hello World:
#include FL/Fl.H
#include FL/Fl_Window.H
#include FL/Fl_Box.H
int main(int argc, char **argv) {
Fl_Window *window = new Fl_Window(340,180);
Fl_Box *box = new Fl_Box(20,40,300,100,Hello, World!);
box-box(FL_UP_BOX);
box-labelfont(FL_BOLD);
FL_BOLD is not a font face name; it is a modifier.
Perhaps you meant FL_HELVETICA or FL_HELVETICA_BOLD or some such?
Note that, FL_HELVETICA_BOLD is actually the value (FL_HELVETICA |
FL_BOLD)
Actually - I am sort of talking bollocks here: due to a
weird consequence of the way that the FLK numbers are set,
FL_BOLD on its own, does happen to equate to
FL_HELVETICA_BOLD in practice, though I'd be wary of relying
on that!
Given that that is the case, I do not know why your code does
not work.
It probably does not help if I say I just ran your code on this
test box, and it works fine here...
How did you build the fltk libs?
Do you have all the necessary dependencies in place (in my
experience, Ubuntu is very bad for *not* including dev
packages that you need by default!)
Was anything odd flagged up during the configure or
make phases?
How did you compile / link your code?
Given that your code appears to be correct, I have to guess
that something is a bit crook in your build environment,
though I can't see what it could be...
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 mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Missing scandir() (STR #2687)
This archive contains the patched files, the content is intended to be copied over a vanilla 1.3.x-r9824 source tree: http://micha.freeshell.org/tmp/scandir_patches_for_fltk-1.3.x-r9824.tar Can you please open the STR for it? I have forgotten the password of my account and the recovery mechanism don't seem to work (no E-Mail after hours). Uploaded as STR #2931. Not sure what to do about a password reset - presumably your account is still active since your email posts are making it to the list OK though! One for Mike maybe... 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Missing scandir() (STR #2687)
Uploaded as STR #2931. Thanks. Somebody with a Windows machine should verify the code. Yes, I did; at least on WinXP. Built and ran fine. I guess the only issue would be if someone was secretly using fl_scandir() directly in their own code and got caught out by the prototype being made more strict, but that might count as a self-inflicted injury? Other than that, I guess we need to verify it on a few more systems - e.g. OSX before and after the 10.8 transition where they made their scandir() prototype more POSIX compliant. (I only have access to 10.6 these days...) I guess most Linuxes will be fine, though have not checked; what systems have you tested on? Also, maybe need to get you to assign the copyright of scandir_posix.c to the fltk project? Not sure how that is handled, actually... Not sure what to do about a password reset - presumably your account is still active since your email posts are making it to the list OK though! I don't use the mailing list, I read and post via USENET (feed from news.easysw.com). No account seems to be required to do that, probably because spammers no longer know what USENET is. Ha, yeah, that sounds right... 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] OT: Making application run once
How would I go about coding this? Pipes? Sockets? None of the above. AFAIK mutex or semaphore are ment to realise this. Well, maybe not - a lock file (or in my case a named pipe) can be a better bet, since it will work across processes on all platforms, whereas not all hosts systems will support mutexes across processes in that way... 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Missing scandir() (STR #2687)
To include the new code into FLTK I would consider the following
things:
1) Import new code to 'src/scandir.c'
Yes - I guess this takes it back to being similar to
what it was prior to STR #2687 or so...
2) Change function name from 'scandir_new()' to 'fl_scandir()'
3) '#include ../config.h' at the beginning so that 'HAVE_PTHREAD'
from autoconf becomes visible.
The feature test macros must stay before the first '#include'
of a system header file to work correctly
4) Ensure that 'src/scandir.c' is not build with a C++ compiler
(Looks like this is already the case)
Yes, the fltk Makefile ought to be doing this right already
5) List the FLTK license text in the header instead of hyperlink
6) Change the switching code in 'src/filename_list.cxx' like this:
--
extern C {
#ifndef HAVE_SCANDIR
int fl_scandir (const char *dir, dirent ***namelist,
int (*select)(dirent *),
int (*compar)(dirent **, dirent **));
#endif
}
...
#ifndef HAVE_SCANDIR
// This version is when we define our own scandir
int n = fl_scandir(dirloc, list, 0, sort);
--
should become something like this:
--
extern C {
#ifndef HAVE_SCANDIR
int fl_scandir (const char *dir, struct dirent ***namelist,
int (*sel)(const struct dirent *),
int (*compar)(const struct dirent **, const struct dirent **));
#endif
}
...
#ifndef HAVE_SCANDIR
// This version is when we define our own scandir
int n = fl_scandir(dirloc, list, 0, (int(*)(const struct dirent **,
const struct dirent **)) sort);
--
Though we need to be cautious about not breaking
the alternate implementation of fl_scandir()
given in scandir_win32.c also.
Maybe the win32 version needs tweaked to match
the more const-correct prototype anyway?
Anyway - if you have the bits for this working, would
it be possible for you to create an STR and upload the
files there?
Just so we keep a record of all this stuff...
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 mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Missing scandir() (STR #2687)
I recently have noticed, that FLTK 1.3.2 don't build any more on SunOS 5.7 because the fl_scandir() funktion was removed since 1.3.0 (the version I have used before). This was documented in STR #2687. Yes - we were pulling in an implementation that was *probably* not compatible with our licence and had to drop it. But... we thought that it was unlikely to affect any users. Does your SunOS not have an implementation of scandir that can be used? (I confess I thought it did, but do not know...) Is it possible the problem is that our configure script is not detecting scandir correctly on your host? Because FLTK is one of the last GUI toolkits that don't add some kind of mega-bloat to any application that use it, it is still useful today for old machines with limited ressources. If I have understand it correctly, the function was removed due to license issues. So is there a chance that it will come back if someone (like me) would provide a new implementation with appropriate license? Yes, we would accept that, I think. I guess there are two things to try here: 1. If your machine has a scandir but we are not detecting it, how do we correct our configure script so that it works? 2. If no scandir exists on SunOS-5.7, can you implement one that works (e.g as is done for win32, and used to be done...) If so, we'd also want to know what would be useful #defines to check for so that we would incorporate that code at build time (without it also being pulled into other hosts that might not need it!) Cheers... 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Missing scandir() (STR #2687)
I recently have noticed, that FLTK 1.3.2 don't build any more on SunOS 5.7 because the fl_scandir() funktion was removed since 1.3.0 (the version I have used before). This was documented in STR #2687. Yes - we were pulling in an implementation that was *probably* not compatible with our licence and had to drop it. But... we thought that it was unlikely to affect any users. Does your SunOS not have an implementation of scandir that can be used? (I confess I thought it did, but do not know...) I don't have access to any SunOS machines these days, but a brief sojourn on the Oracle docs site yielded: http://docs.oracle.com/cd/E19620-01/805-3175/6j31emp7u/index.html (Setting aside any issues I may have with looking on Oracles site to find out about SUN, or course...) Which appears to indicate that SunOS 5.7 (Last Revised 28 Jan 1998) has a scandir with this prototype; #include sys/types.h #include sys/dir.h char *dirname; struct direct *(*namelist[]); int (*select(.),(*dcomp)(); int scandir(dirname, namelist, select, dcomp); Whereas we are more hoping for something like... #include dirent.h int scandir(const char *dirp, struct dirent ***namelist, int (*filter)(const struct dirent *), int (*compar)(const struct dirent **, const struct dirent **)); But it does look as if, with a bit of poking, that (the SunOS version) ought to work. So... Is it possible the problem is that our configure script is not detecting scandir correctly on your host? I have to suspect that this is the case. Can you investigate (if you have access to a suitable host to test on) and see if we can figure out what's up here. Or... make an fl_scandir() wrapper for the SunOS scandir() to see if that will work instead. 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK pronunciation [was: EDE/FLTK talks on FOSDEM]
[2] http://edeproject.org/slides/fosdem-2013-fltk.pdf FLTK - pronounced 'fulltick' Accurate by the docs, but I've just gotta say, I don't think I've ever actually heard anyone refer to fltk as 'fulltick' in real life. Pretty sure even Bill himself has always pronounced it Eff-Ell- Tee-Kay. I know I do in casual conversations with programmers in the special fx community. I haven't polled the net or anything, but pretty sure most of us call it by the letters. Though pretty much everyone here *does* call it fulltick. (Though I have to concede that's likely because that's how I pronounce it, and they all got it from me...) If it's a unanimous thing, we should probably change the docs.. or just leave it as one of those odd cultural things? Sure. Like: How do you pronounce OSX? -- Ian 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FL_LEAVE in Fl_Menu_Bar
It seems that pulldown() doesn't return until I press Esc, and handle(FL_LEAVE) doesn't get called until then. Yup - this seems to be a weakness here; we have the pulldown method which allows us to programmatically show the menu, but I can't see an equivalent method to ask the menu to close again, programmatically... I tried a few tests around your code, and what I wanted was a method I could call to ask the menu to close again (pushup ?) in response to some event, e.g. a leave or similar... but... Anyone? I'm now thinking that creating a whole hierarchy of (borderless) dialog windows that pretend to be menus might actually be easier... and would respond to show/hide enter/leave etc... events... Or... 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] FLTK pronunciation [was: EDE/FLTK talks on FOSDEM]
Greg Ercolano e...@seriss.com wrote: Accurate by the docs, but I've just gotta say, I don't think I've ever actually heard anyone refer to fltk as 'fulltick' in real life. Really? There isn't many FLTK users around me so I just followed the docs, but if you guys prefer it be called by spelling the letters (albeit a bit hard for the tongue), I'll try to adopt it :) Nah! The docs say fulltick, so that *must* be right. The docs are *always* right... MacArthur, Ian (Selex ES, UK) ian.macart...@selex-es.com wrote: Sure. Like: How do you pronounce OSX? Lol, really good comparison; when people spell it fast, it starts to sound like O-six ;) It is worse than that - real Mac fans (i.e. not me) pronounce it Oh - Ess - ten, since it came after OS9, OS8, etc... (That X is not an X, it is a Roman numeral 10...) 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Building code examples using FLTK on recent Linux, and Raspberry Pi
This code uses FLTK for its GUI examples. A link is provided ( http://www.stroustrup.com/Programming/FLTK/ ) to FLTK-1.1.9 sources, to build that version to be linked with the relevant example code. In attempting to doing this I've experienced slight problems, and am seeking advice on these. The nearest stable release to 1.1.9 is 1.1.10 so that might be worth a try, too. Note that, for statically linked code, the API for 1.3 is pretty much the same as fltk-1.1, so you can (I do) use fltk-1.3 for all my old fltk-1.1.x era code. (The binary ABI has changed, but if you are always linking static, as we recommend, then that should not be an issue.) What I tried to do was simply a build of the FLTK lib on Ubuntu 12.04, and on a Raspberry Pi ( http://www.raspberrypi.org/ ), running its current Debian wheezy os (Raspbian), and w/ their default g++, 4.6.3 for both of these, IIRC. The problems include: 1) In building the supplied FLTK code, there is a conflict found with an installed file, /usr/include/dirent.h . Ah... the glibc folk changed the way they define some of the dirent stuff, and we patched for that, but 1.1.9 may predate the patches (indeed, 1.1.10 may do so too - 1.3.2 should be fine!) aside FWIW I have a bunch of code running with fltk-1.3.2 on my R-Pi (Raspbian) and it has been fine. GL performance is disappointing, since the Xserver does not hook the GPU properly for accelerated GL rendering, but otherwise it is fine. GL performance native on the bare GPU is very fast, which makes the Xserver behaviour all the more disappointing...! /aside 2) A few simple, compilation problems in the example code that were easy to fix. Though perhaps unexpected? I'd imagine those examples are well-tried, so if errors are being encountered that might hint at some underlying problem? How sure are you that your setup is solid? (no offence, BTW!) Problem 1) above was encountered with or without an (1.3) version of FLTK separately installed on the machine. By installed do you really mean installed or just on the same machine? Note that the fltk-1.1 and fltk-1.3 headers DO NOT play nice together, so you can not actually *install* both at the same time. For my part, I have half a dozen different fltk trees on this machine, but none are actually installed at all - fltk works perfectly fine right out of the build tree, so actual installation is seldom necessary. This was worked round by not attempting to build the (PPP) supplied source for FLTK, but just using the 1.3 versions available in the relevant distros. Of course this left the GUI code being build against a lib that it was not written for. Though with the fltk-1.1 / fltk-1.3 transition that *ought* not to matter... ;-( But there were no huge issues seen with the results, apart from those covered below, which might be unrelated to this change. In running the built example code, there was a problem related to closing the example window. Several of the samples have a Next button which worked - at least reasonably - reliably to effect closing. But the window's 'x' or close on its menu seemed to result in the app's looping. Is this to be expected? I've seen references saying that windows under FLTK, Fl::run() does not return until all of the windows under user control are hidden or closed. Is this related? Would have to see the sample code to know. I'm not at all familiar with the examples from the book. It is *possible* that if you have some unhappy mix of fltk-1.1 and fltk-1.3 bits getting pulled into your build, you might see some odd effects... Though it seems more likely that something has just not built right...! Grab a tarball of fltk-1.3.2 from here, and then do the: ./configure ; make dance. Do the samples in the fltk /test folder work OK? If not, something is hosed in your setup. If the fltk /test samples are OK, then something is awry in the building of the PPP examples, I guess. Finally, on the Raspberry Pi's display, the lines are over-thin, and the colours (colors ;-)) are somewhat poor. I _expect_ that these issues might be related to use of a different screen, and in any event could be addressed by slight tweaks to the example code, rather than being related to FLTK version changes - but if anyone has first-hand experience of this, I'd appreciate their comments. I haven't yet looked at the rendering of text. Hmm, what display are you using with your Pi? I have used: - Older, 19 4:3 aspect DVI monitor. Worked like a charm. - 32 widescreen HDMI TV - worked once I figured out the correct incantation to put in my boot config... See the Pi wiki for hints! In both cases, the rendering of the widgets looked OK, and colours were good. I have *not* tried the composite video output. I'd assume it would look a lot like 1980-something... However: What I actually *normally* do is run the Pi headless and connect to it from another machine using: ssh -X
Re: [fltk.general] Code into Fl_group ?
In fact I'm not using fluid. You must be using fluid: you are presenting fragments of fluid output here, which you presumably must be translating into C++ for compilation, and AFAIK fluid is the only tool around that knows how to convert fluid files into C++. However, perhaps you are hand-editing the fluid files? If so, do not do that! The fact that fluid files are *apparently* human-readable is not meant to indicate that they should be human-edited! It is possible, but that is *not* the point. Use the fluid GUI editor to manipulate the files. Don't hand-edit them! If you are determined to hand-edit the fluid files, then your best bet is to use fluid's GUI editor to make small, stand-alone, compileable and testable examples that implement the features you want. Then, for each of these, test the generated C++ to ensure that it does what you want, and if it does, study the fluid files and C++ files to see how that was done. Then copy those features into your hand-edited fluid sources. But... Really, just don't! Use fluid the way it was intended! 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Unable to change labelsize and labelfont fltk 1.3.2
We are facing issue in setting the labelsize and labelfont using fltk1.3.2 , It always sets to default size,font and color. We have build fltk1.3.2 with ./configure --shared --thread options. We were using fltk2.0 and were able to change the label size,font,color.Since after going through the articles on version we considered fltk1.3.2 is a stable version and moved from fltk2.0 to fltk1.3.2. Please can you help us in resolving this issue, You'll need to show us what you are doing, since (as the saying goes) It works OK for me... Can you post a minimal, complete, compileable, sample that shows what you are doing and exhibits the fault? 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Code into Fl_group ?
I have a button that allows me to upload a specific object in a
Fl_group named test:
Fl_Button {} {
label {Show Voice Parameters}
callback {ADnoteVoice-position(541,35);test-
add(ADnoteVoice);ADnoteVoice-show();}
xywh {5 400 170 25} labelsize 12
}
This code run well.
The problem is: I want the object loads automatically without the need
to click on the this button . I have tested this
Fl_Group test {
label {VOICE PARAMETERS} open
xywh {540 5 768 922} box UP_FRAME labeltype EMBOSSED_LABEL
labelfont 1 labelsize 13 align 17
code0 {ADnoteVoice-position(541,35);test-
add(ADnoteVoice);ADnoteVoice-show();}.
The compilation is alright, but nothing occur.
}
What is wrong ?
Impossible to say: you have not provided enough information in your post, nor
enough context to make sense of the fluid fragments.
Can you take another stab at explaining?
Also, a more complete (by which I mean complete enough to compile and test)
fluid or C++ example that exhibits the feature you are asking about would help
clarify the question.
It sounds to me as if you are asking about how to add widgets to a group, but
it surely can not be that straightforward, so I guess there's something more to
it than that...
How are you generating these fluid files? If you are in fluid then surely you
can just drag the widgets you want into the group as you edit it?
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 mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Sys_Menu_Bar not honouring programmatic updates to check boxes
I have an app that, in its menu structure, has some FL_MENU_TOGGLE entries that show a check mark... Now, depending on various happenings within the code, these check marks may be set or cleared programmatically at runtime, using e.g. item-set(); and item-clear(); All well and good - except on OSX where I am using Fl_Sys_Menu_Bar, where the changes to the state of the toggles are never shown by the menus... Anyone else seeing this? Is there a workaround? How do I cause the Fl_Sys_Menu_Bar to be refreshed to reflect the actual state? I guess this may be a bug? Or is this Just The Way Things Are on OSX and we are stuck with it? (Replying to my own post here...) I took a brief look at this, and it does seem as if the Fl_Sys_Menu_Bar on OSX does not get updated to reflect the changes caused by the Fl_Menu_Item::set(),clear() and set_only() methods, in its current form. Not sure how to make that work (it is beyond my OSX-fu skills) but I guess it might be possible to sledgehammer it by triggering a call to convertToMenuBar(...) which would tear down and then rebuild the entire Fl_Sys_Menu_Bar. Sounds a bit heavy-handed, but should work and mean that the state is reported correctly... Anyway, that looks like something that I can do by deriving my own class from Fl_Sys_Menu_Bar and adding a few new methods to test it, so I'll maybe take a stab at that later. (No OSX machines in this office, so can't test now!) -- Ian 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Detect Resizing
How can I detect Window resizing since it doesn't provide any resize events or callbacks from what I've read? I'm current writing my first FLTK program for a 2D game and I want to remove the scrollbars when they aren't required. This is when the width or height of the world can be fully displayed in an FL_GL_Widget. FL_GL_Widget ? I assume you are deriving your own window class from Fl_Gl_Window then? If so, can you not just override the resize() method in your derived class and then use that to detect resize events happening? Or am I missing the point here? 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Detect Resizing
Turns out it was a stupid question. There are no stupid questions... (Well, not the first time anyway: Ask the same thing 6 times, I might change my opinion...! ;-) ) I wasn't aware that could override the resize method although now I that I think about it, nothing had said otherwise. Yup, override is probably the way (indeed, at certain levels in the hierarchy, the resize method is explicitly virtual, to encourage override, but that maybe is not obvious if you are looking at the Fl_Gl_Window docs, of course...) I think Edzard's example in his post is useful here, in that it makes the point about calling the base class resize(); as well as doing whatever actions you add - this is an important point that often gets missed, and failing to call the base class methods does often lead to unexpected behaviours that can be hard to debug, so... Also, he shows how you can use that to trigger a callback - though in your case you may be able to do what you need directly in the resize() method itself? Another tricky little wrinkle to this can be what happens if the resize() method itself causes the view to be resized (e.g. by removing some feature, such as, say, a scrollbar...) Does that then trigger a recursion...? Somethimes you need to watch out for that too, though I'd guess you'll be fine in this case. Cheers, hope that helps... 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Menu_Item offset calculation
I am using fltk-1.1.10 and I have in my menu some check menu items. Their settings shall be updated according to some preference information. I do this using the 'Name' of the menu item defined by FLUID in the property dialog of the item. So I write PTimeBaseRELA-setonly(); (with PTimeBaseRela being the 'name' of the menu item) But it doesn't work. Instead the predecessor menu item is set! Looking in the generated .h file the 'Name' is defined (in my case) as #define PTimeBaseRELA (menu_PMenuBar+23) But for my opinion it should be #define PTimeBaseRELA (menu_PMenuBar+24) Indeed, it can be fixed by using (PTimeBaseRELA+1)-setonly(); But this behaviour is very confusing. I thing the calculation of the menu item offsets in fluid is buggy. Hmm, that does sound wrong: if possible, can you post a minimal fluid file, maybe just showing your menu layout, that exhibits the fault? It would be very useful to see how your menus are laid out, so we can see where the discrepancy arises! Thanks... 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Menu_Item offset calculation
Below is my .fl file with the original menu bar reproducing the error. Hope it helps! Thanks Hmm, OK - I *think* the problem is the empty Recent Files submenu item... If that item is made to be not-empty, then things seem to work a whole lot better! Though, for what it is worth, I don't think that using the fluid-generated offsets is going to work all that well if you are using any dynamically generated menu content, since the computed offsets will likely always be wrong. (Though, indeed I could be wrong too!) I'd favour doing what Greg does, and build and manipulate the menus dynamically... Um, try starting about here: http://www.seriss.com/people/erco/fltk/#Menu_ChangeLabel The alternate might be, if you plan on having a fixed number of previous files listed, to pre-populate the Recent Files submenu with unused entries, then either hiding or inactivating those until they are populated. That should work... I think... Maybe... Yup, just tested that and it seems to be fine (used inactive entries in my test, though I assume hidden would do too!) 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Fl_Menu_Item offset calculation
It's ok that it will not work when the menu is modified at run time; but I think the menu_item access should work correctly as long as the menu is *not* modified. (This is given in my case.) Yup: I think it would be good if you filed an STR recording this stuff, because it does look like there's something a bit, erm, suspect about the current behaviour... Alternatively FLUID could generate the menu_item pointer in the .h file as a function call (using Gregs recommendation) like : #define PTimeBaseTEST (menu_PMenuBar-find_item(Settings/TimeBase/Test Time)) That should work even on modified menus. Indeed. [OK, but only as long as the the menu_item name is not modified... :-( ] Though I think Greg also has a demo showing how to change the menu items name without actually changing its name too, for internationalization purposes and etc... 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Changing an Fl_Menu_Bar item colors
Here's a test - is this any better? If you send a message that uses characters from certain character sets in the message body. Messages that use character sets from the following code pages are encoded as Base64 messages when they are sent from an Exchange 2000 computer: Shift-JIS EUC-KR ISO-2202-JP BIG5 ISO-2202-KR GB18030 GB2312 Yup - though I don't use any CJK language normally, so I don't think that can be it. I do wonder if it is struggling with something else that is getting encoded as UTF-8 in my posts though? That might do it I guess, if it is 7-bit cleanness that is the issue here? 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Changing an Fl_Menu_Bar item colors
Thanks for the reply. This code works well for changing the text foreground color. However I also need to change the background color (the gray box behind the text). Any ideas how to change the background color in an Fl_Menu_Bar item? I don't think there is an easy fix for this (though hopefully others will know better!) but you might be able to make it so... The method that actually draws the menu items, Fl_Menu_Item::draw(...), is defined in Fl_Menu.cxx, so I guess it might be possible to derive your own Fl_Menu class (and maybe also Fl_Menu_Bar class and Fl_Menu_Item struct...) and then add in the ability to set the menu item background... Note that Fl_Menu_Item::draw(...) actually can cope with drawing different boxtypes and colours and so forth, but there's no way to ask for those features for regular menu items, it is meant for menu buttons and so forth... Though maybe you can do something with selection_color(); I wonder if that would work...? Um, probably not... Anyway; best bet is probably to hope that Sanel or someone knows a workaround for this! Cheers, -- Ian 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] [RFC] a new class to supportInternationalization
True, but not everything can be changed that way, e.g. file chooser, fatal errors... Ah, right - I thought that was covered too. Oh well, I always use the native file chooser these days anyway! Also fluid can't be translated and adopted to user specific locales. Yes, fluid is more problematic - though I was more focussed on the end user facing aspects of the lib; it does seem to me that the developer facing elements, such as fluid, might tolerate a lesser standard of i18n. Indeed, looking at the recent posts to the lists here, it looks as if *most* of the recent posters (apart from me!) are not native English speakers, and most are making a better job of it than I am! Cheers, -- Ian 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.general] Changing an Fl_Menu_Bar item colors
Hi Sanel,
That's neat - I didn’t know that worked!
First you need to assign callback to desired Fl_Menu_Item, whose colors
you are going to change. From callback you can access Fl_Menu_Bar and
by
using mvalue() member, you can access to selected item; from there you
can change label color, background and etc.
Here is example:
static void color_cb(Fl_Widget *w, void*) {
Fl_Menu_Bar *bar = (Fl_Menu_Bar*)w;
if(!bar-mvalue()) return;
Fl_Menu_Item *self = (Fl_Menu_Item*)bar-mvalue();
self-labelcolor(FL_RED);
}
// your Fl_Menu_Item table:
static Fl_Menu_Item table[] = {
{File, 0,0,0,FL_SUBMENU},
{To red, 0, color_cb},
{0}
};
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 mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Showing hex value in Fl_Value_Input
I'm using Fltk 1.3 In an Fl_Value_Input I can manually input a hex value by prefixing it with 0x, but I can't figure out how to put a value in programmatically and have it show it in hex. Is there a way to do this? Well... yes, but probably not as easy as you'd want... You can derive your own widget from Fl_Value_Input then override the format() method to do what you want. Or... just not bother with Fl_Value_Input, just use a text-only widget (e.g. Fl_Input) then in the callback function do the formatting and decoding the way you like it... I think I've done both of the above at various times in the past, and didn't much care for either approach! 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Changing an Fl_Menu_Bar item colors
I have an Fl_Menu_Bar with a few added items that have the FL_MENU_TOGGLE property. This adds checkboxes to the menu. I need to change the visual indication that each menu item has been clicked from the checkbox to toggling menu item foreground (text) and background colors. Obviously I could eliminate the FL_MENU_TOGGLE property if that'd help. I don't know... for historical reasons, the menu entries in the fltk-1.x menus aren't proper widgets in the usual fltk sense, so changing their behaviour and appearance is a pain. Though I think it can be - but I don't have any example code here; perhaps others have something? (I think fltk3, and indeed fltk2, are attempting to address that menu discrepancy and make menu items more normal so this problem might go away. Eventually...) 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] GIF Image
On 17 Jan 2013, at 22:54, George wrote: I am trying to insert a gif into a window but even though i use = FL_GIF_Image and even the picture is .gif , it' s still looking just = like a normal static picture in the window. Fltk's built-in GIF handling does not support animated GIF's, only = static GIF's. Somebody (maybe Albrecht? Can't recall now, it was a while ago...) did = post patches to implement animated GIF's, but that was some time (years) = ago, and there seemed to be no demand for that ability, so it never = happened... That was probably this: http://www.fltk.org/newsgroups.php?s16+gfltk.general+v25+T0+Qanimated The link within is still working. Oh yes, that's the thread - it was Marc, not Albrecht then, I see; though Albrecht obviously helped! 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.development] Strange build error on Mac OS X
Hi Peter, I don't have anything useful to suggest, just wondered about this: When building a shared library of FLTK 1.3.2 on Mac OS X 10.4 (Linux cross compilation), we get this exotic error message: So... from that, I understand that you are building fltk dylibs for an OSX target system, on a linux host system? Well, that is an interesting idea... I have some code for which I need to maintain an OSX 10.4 build (for x86 and ppc32) and the current Apple tools don't really want to do that anymore (unless I stare at them very sternly for a while!)... but if it is possible to build this target from a non-Apple host, well that opens up some new possibilities indeed...! Or have I got that backwards, and you are building code for a linux target on an OSX host? (Ah! No, must be the first option, as I see you are compiling .mm files, and creating a dylib using Apples bodged-up ld, so must be for an OSX target then. Interesting...) Linking CXX shared library ../lib/libfltk.dylib /usr/lib/gcc/i686-apple-darwin8/4.5.3/../../../../i686-apple- darwin8/bin/ld: CMakeFiles/fltk_SHARED.dir/Fl_Native_File_Chooser_MAC.mm.o literal pointer section (__OBJC,__cls_refs) does not have is exactly one relocation entry for each pointer collect2: ld returned 1 exit status -- Ian 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 #2659: support conversion from Fl_Pixmap to Fl_RGB_Image
Manolo, what do you reckon - I think you have looked at this and know what it is; looks fine to me, and useful too... Thoughts? -Original Message- DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2659 Version: 1.4-feature Yes, please apply. The pixmap_v2.patch has been adapted to FLTK 1.3.2. Hopefully applies to trunk as well. Link: http://www.fltk.org/str.php?L2659 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev 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.general] OpenGL + widgets
One trivial observation is that the use of FLU / flu as a namespace confused me, since there is already a (fltk-1.1) third-party add-onn lib called FLU, that I used to use quite a lot! I was inspired by a moderate fever at the time, and evidently didn't check thoroughly enough for existing uses. I'm open to suggestions for other names. I don't think the FLU stuff is actively maintained, nor do I know how widely used it is: I used to use it a lot, but many of the features I liked eventually appeared in the core libs... I guess we don't care what the namespace you set is though, so long as folk can spot what it relates to...! Oh, now that's a thought - for the embedded targets, an EGL driver rather than a GL one, might be really neat too... That reminds me...with an OpenGL driver, widgets can be drawn in any OpenGL context, from GLUT, SDL, etc. Event handling is another matter, though. Is there a simple way to feed FLTK events from an outside framework, rather than using its internal native code? Some of these other frameworks have rather more sophisticated and complete interfaces for setting up OpenGL contexts. (BTW, I noticed multisampling support was lacking from the OS X code...it's straightforward to add, see https://github.com/cjameshuff/fltkstuff/blob/master/src/pixfmt.cpp) Can probably cobble something together using Fl::add_handler() and have that parse the incoming events, perhaps? Also, it seems that fltk3::gl_visual() has no effect on the settings GLWindows use...this was not what I expected. I dunno... I can't recall using it - was it not meant to make normal windows have the same config as the GL windows or something? Someone must know, but it sure is not me! 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Manage focus with Suggestions popup/win/menu
I am trying to create a little widget/group made of an Fl_Input (or text editor) and a drop-down-menu-like suggestions box. The end goal is to make something similar to an AJAX-y suggestions box found on google, or the firefox sites suggestions, etc. It's easy for me to create/fill/show a popup made of an Fl_Select_Browser inside an Fl_Menu_Window. If I use an Fl_Menu_Window, though, show() steals focus and the mouse cursor from my Fl_Input widget. I can't send back focus because the menu is a new window ... or at least I haven't figured out how to send it back ... ? In short, I have something like the pseudo-code below. I'm happy to post my full test/draft if that helps. Maybe someone else has been through this before? Without actually thinking about your problem much (or indeed at all!) my initial reaction is that Fl_Menu_Window is the wrong way to go (menu windows tend to grab, and that is *not* what you want!) I think you'd be better off just popping up a regular Fl_Double_Window with your controls in it, then setting that popup window to non-modal, which will cause it to stay on top of your main window, but *not* grab the focus (though it may take the focus when it pops up, it will not grab it, so you should be able to give it back to your main window...) Also, I think setting the popup window non-modal will usually also remove the window decorations (may depend on how your window manager behaves though I suspect!) so it will look much like a menu window would... 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Scrolling Fl_Browser with hidden scrollbars.
I am going to use Fl_Browser with non-standard scrollbar (my own draw() function). When I disable standard Fl_Browser scrollbar by has_scrollbar(0), calling topline(i) does not scroll browser content. Is there a way to completely hide standard scrollbar, and control browser from outside? Hmm, that is an odd one - you are right, that doesn't work... The browser does not get redrawn if has_scrollbar() is set to zero. Though, clicking on the browser items, it would appear that internally the browser thinks the list *has* been scrolled, and returns the line item that *would* be at the clicked position, if the scroll had happened... If I set the scrollbar width to 1 and set has_scrollbar() non-zero then it does work (though a very tiny scroll bar is visible of course...) Bit of an odd one then... Anyone know what is going on here...? Selex ES 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
Re: [fltk.general] Subwindow show/hide behavior
I've come across some odd behavior with windows as subwindows, when trying to show/hide or add/remove the subwindow. The subwindow remains invisible until the containing window is resized. When I replace the subwindow with a group, I get the behavior I expect. My understanding is that behavior should be identical in this case. I've reproduced this under both FLTK 1.3.2 and 3 from a recent svn checkout, under OS X 10.6.8. Hmm - do you *really* need to use a sub-window rather than a group here? The reason I ask is that OSX doesn't really have sub-windows per se, and we are kinda faking it. And it doesn't always work as well as we'd like (Matthias or Manolo may have a better idea about this...) So... I've had code in the past that worked nicely on WinXX and Linux with subwindows, but was a bit flaky under OSX. Though that was a while back and it may have been fixed in the meantime, though it does sound like you are hitting similar issues here. I assume your code is fine on WinXX / Linux hosts then? 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 mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
