Re: [fltk.development] [RFE] STR #2951: DoubleSlider for selecting low and high values within min/max range
On 14 Apr 2013, at 13:57, Duncan Gibson wrote: I have an application with a colour bar type legend which does not give the required resolution, so I needed to be able to adjust the low and high values in an intuitive but minimally invasive way on screen. I hacked together the following demonstrator, drawing some inspiration from Fl_Slider. The features I required were: - a vertical slider - possibility of setting min and max values of continuous range (no step) - possibility to move low and high sliders (min = low high = max) I then hacked it further to fit directly with the rest of my application. Questions: 1. Does anybody know of a similar widget out there? 2. Is it worth factoring out a separate DoubleValuator base class? 3. Apart from vertical/horizontal what other features are needed? 4. Does it require min/low/high/max fields? 5. Would a floating tooltip with feedback be enough? (eg Greg's TipWin) I'd be willing to have a go a this, but can't provide any timeframes. Coming to this party late, but I just remembered that Jason Bryan's FLU widgets have a double-slider widget. His pages at OSC.edu appear to be gone but the mirror here still seems to be working: http://src.gnu-darwin.org/ports/x11-toolkits/flu/work/FLU_2.14/ His FLU_Dual_Slider might be relevant, to see how what he did compares. He derived a pile of new fltk based widgets, so there may be clues in that work for a template for future derivations? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 16 Apr 2013, at 19:03, Greg Ercolano wrote: So I imagine most folks would be managing the resource files by hand now, I honestly don't know: I've been using the mingw tools in preference to the MS tools for so long now, that I'm not sure what would be deemed normal any more! I know that I manage the .rc files by hand, and use the mingw resource compiler, but have no ide what the equivalent MS tools would be... so perhaps the simpler they are, the better. Could not agree more. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 15 Apr 2013, at 17:53, David FLEURY wrote: Le 25/03/2013 22:07, David FLEURY a écrit : I found an easy tool (VarilconsRevolve) Here a new patch. I remove all unnecessary lines from the rc file and fluid_resource.h I just remove cygwin (I have no cygwin installed, I can't not test). I have to 2 more icons on the fluid.ico file (48*48 and 64*64) so its not so big. Not sure I can do better. Hi, I reactivate this, just to known if I had to keep it somewhere on my repo to patch my fltk, or something like this will be apply in the official repo. Is there an STR for this somewhere? I can't find it... so I can't find the patch. Anyway: what sizes are in the icon file now? We need to be sure there are enough sizes to cover the range expected by XP through Win7 (and I suppose Win8, though I don't know what sizes it likes; I assume same as Win7?) As fas as the patch goes, I imagine the only material change to the code is to add a #ifdef to load the icon, e.g. as is done on the sudoku example in the test folder? That is certainly what I do in my own code, at any rate. Regarding changes to the Makefile, I'm only likely to use the mingw tools any time soon, so if a suitable icon is available I can adjust fluid's Makefile to do the resource compilation and so forth for the mingw (and hence probably cygwin too...) builds. Again, that'll largely be a matter of cloning the suduko build target really...! Which reminds me... whilst we are on the subject of Windows icons; we really need to look at #2816 again and get that merged, as it would be useful... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 15 Apr 2013, at 21:28, David FLEURY wrote: Le 15/04/2013 21:57, Ian MacArthur a écrit : Is there an STR for this somewhere? I can't find it... so I can't find the patch. I am not used to create a STR. I did not create one. Ah. That's gong to make it very hard for us to view and comment on it, then. 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. Anyway: what sizes are in the icon file now? 32k 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. I have added a 64*64 and a 48*48 icons So, it has 16x16 32x32 48x48 and 64x64 then, is that right? My understanding is that, for Win7 at least, we'd really want a 128x128 as well, possibly even a 256x256 just in case! Is the image you are using for the icon very complex? I'm a bit puzzled why the icon is bigger than mine when it does not have as many sizes in it...? We need to be sure there are enough sizes to cover the range expected by XP through Win7 (and I suppose Win8, though I don't know what sizes it likes; I assume same as Win7?) I have tested it against win8. The icon look fine (64*64) not succeeded to put a bigger one (size increase to much too) Yup, that seems odd. WOnder why it seems to be so big... As fas as the patch goes, I imagine the only material change to the code is to add a #ifdef to load the icon, e.g. as is done on the sudoku example in the test folder? Yes exactly That is certainly what I do in my own code, at any rate. Regarding changes to the Makefile, I'm only likely to use the mingw tools any time soon, so if a suitable icon is available I can adjust fluid's Makefile to do the resource compilation and so forth for the mingw (and hence probably cygwin too...) builds. Again, that'll largely be a matter of cloning the suduko build target really...! I have no mingw installed. I have excluded mingw for this patch since I cannot test it. If you post what you have to an STR, we can certainly look at making it work for mingw too... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid - Adding win32 icon
On 15 Apr 2013, at 22:13, Greg Ercolano wrote: On 04/15/13 13:28, David FLEURY wrote: Le 15/04/2013 21:57, Ian MacArthur a écrit : Is there an STR for this somewhere? I can't find it... so I can't find the patch. I am not used to create a STR. I did not create one. Ian; he included the patch here on fltk.dev at the head of this thread. Oh, OK. I had the sense, from what he was saying, that there were changes to the patch - David and I discussed this patch a few days back, and I think he was tweaking things about, so I wanted to see where we have got to. I also wanted to take a peak at the icon, so I thought that posting all the bits to an STR would be the easiest option. Also, would make it easy for others to pitch in... Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method to Fl_Widgetthat returns its top-level window
On 12 Apr 2013, at 18:44, Albrecht Schlosser wrote: Using const_cast is only another way to write it, but means the same essentially, doesn't it? However, if some compilers wouldn't flag a warning for const_cast but would for the old-style cast, then we could maybe use it, but according to the CMP this shouldn't be used for fltk 1.1 code, however it should be used for 2.0 code. 1.3 code is not (yet) specified, so we'd have to make a decision about this first. I'm in favour of allowing the C++ style casts. I expect that it probably works with all the extant compilers now? Does anyone know for sure? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2948: Add a method toFl_Widgetthat returns its top-level window
On 13 Apr 2013, at 00:07, Greg Ercolano wrote: On 04/12/13 13:19, Ian MacArthur wrote: I'm in favour of allowing the C++ style casts. I expect that it probably works with all the extant compilers now? Does anyone know for sure? The static_cast mod flew in all my tests on redhat9 and irix6.5, and those are as old as the friggin hills. You say static_cast here? Would we not be wanting const_cast in this case...? Or am I missing something obvious again? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2945: Virus is detected when being compiled in MSVS 2010
Actually, I suspect it is more likely to be a false positive than anything else.At various times in the past I have had AVG, Norton or McAfee all throw warnings when configure was running; and not just on fltk builds but on other packages too.I suspect that the AV authors aren't particularly focussed on the developer community and there may be things configure does that look suspect if viewed in a general context...That said, I'm not sure any of that's pertinent to the OP's case, where I can't imagine configure is involved at all...!-- IanSent, much to my surprise, from my Palm Pre3On 6 Apr 2013 14:51, Greg Ercolano e...@seriss.com wrote: DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2945 Version: 1.3-feature Have you ruled out this might be a problem with your own machine? Have you had problems with viruses recently? (ie. if you have an out of data java interpreter, etc. that is causing binaries that link against possibly corrupt libraries on your machine to, by extension, appear to be corrupt themselves?) Have you ruled out building code from other toolkits causes the same problem, eg. try building wxwidgets or the opengl demos. Is there a pattern in the files Avira is detecting, such as all the opengl oriented demos? (CubeViewd.exe is a debug build of an opengl oriented app) Please include a list of all files it detected, as there may be a pattern in the files it detects, ie. all the opengl oriented applications, or the opengl debug libraries. (You mentioned cubeviewd, which uses opengl) If there is a pattern, it's possible the problem is a corrupt library on your machine (eg. opengl related) that is getting linked into the executables causing the problem. Let's rule all that out first. Link: http://www.fltk.org/str.php?L2945 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2945: Virus is detected when being compiled in MSVS 2010
Oh, and it's probably worth saying that I've run a variety of virus scanners over my current stock of fltk builds, with no warnings flagged.That said, I can't reproduce the OP's environment since I have neither VS2010 nor Avira readily to hand.Does look a lot like a false positive... Or maybe the OP's machine is compromised?-- IanSent, much to my surprise, from my Palm Pre3On 6 Apr 2013 14:07, faywong philip584...@gmail.com wrote: DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2945 Version: 1.3-feature Operate Environment: Windows 7 SP1 32bit, MSVS 2010, Avira Free Anti-virus 2013 Actual Steps: 1) import/open the projects for MSVS 2010, and compile them totally 2) when compile is in progress, the Avira starts to complain and request me to delete several files generated from FLTK's source code And I will take one as an example: in file: C:\Users\faywong\Downloads\fltk-1.3.2\test\CubeViewd.exe found a virus: TR/Crypt.XPACK.Gen2 Link: http://www.fltk.org/str.php?L2945 Version: 1.3-feature___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature This may be possible, but I didn't do it (thinking about it was making my head hurt...) I guess the idea is to use the typographical height of the folded string, which will take into account the vertical leading between rows of text and so forth; but tailor that to take account of the inked height of the first and last rows... Or something... In any case, I think we'd maybe want to make that a distinct function from fl_text_extents() if we did that ? I also wonder about (somehow) handling fltk @ symbol expansion and so forth in the improved mechanism. If we go that way... Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): supportmultiplelines
On 27 Mar 2013, at 20:16, chris wrote: Ah, I think I understand the difference now, will have a look at the test tomorrow... Though at now cannot imagine a use case for knowing the inking area. Ah, but it turns out that there are quite a lot of uses for knowing the inked area of a typographical element. Not so much for rendering strings of text though; in that case fl_measure if usually the right thing. But if you are rendering text for other purposes, it is often beneficial to know what the actual extents are, since they are usually smaller, some times much smaller, than the sizes reported by fl_measure. Even using fonts decoratively, it is useful to know the extents... For my own part, for example, I often use fl_text_extents to measure glyphs from musical fonts, to ensure that they are positioned on the staff accurately, and suitably sized. The values returned by fl_measure are pretty well useless for this purpose. So, maybe not all that everyday a use case for most folks, I guess, but a real one nonetheless! Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2941: RFE: fl_text_extents(): support multiple lines
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature Yes, I thought about that at the time, but chose not to do it. The problem is, it is not obvious what the right answer is, for a string that has carriage returns / line feeds in it. In particular; What is the resulting vertical height? It will presumably *not* be the sum of the vertical heights of the constituent sub-strings, since that will not account for the vertical leading between the rows of text - assuming the rows are rendered by the host system's regular text drawing mechanism. So, for multi-line text, you probably *need* to render each line yourself, if you care about the inked extent, so that you can directly control the vertical leading between rows. Or, use fl_measure and accept that it will return a bounding box that is larger than the inked extent... I suspect that in the case of multi-line text that fl_measure will usually be more useful anyway. Hmm, now I think about it, I'm not even sure I know what the various different host text systems do with measuring the extents of wrapped text... It is even possible that *some* of them might even get this right, i.e. return a bounding box that describes the inked extents, incorporating the vertical leading. But I do not know for sure, and certainly some of the text systems Do Not get this right, so... It's tricky. Link: http://www.fltk.org/str.php?L2941 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Vote request: addition of two new schemesgrad and gleam
On 9 Mar 2013, at 01:57, Greg Ercolano wrote: I added a chooser for the different schemes, and squeezed in Edmanuel's widget panel that shows how the schemes look with different widgets. Here's a thought (I haven't checked the latest svn!) do we need to also tweak the test/demo wrapper program too, then? It has a scheme picking drop-down too, so I guess it needs to know about the new schemes? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Vote request: addition of two new schemes grad and gleam
On 8 Mar 2013, at 17:31, Greg Ercolano wrote: A request to vote on the addition of the gleam and grad patches to FLTK. There's two STRs for this: http://www.fltk.org/str.php?L2672 http://www.fltk.org/str.php?L2675 Would like to combine and apply. Code seems OK, looking for consensus and comments on patches. I've not looked at the patches in detail recently - looked at the gleam patch a while back, but Edmanuel has been working on it more since then... If it looks OK to others, then I'd be +1 on adding it, as more schemes would probably be a popular option! My only comment is I'd like to modify the unittests program to have a test for all our scheme options (plastic, gtk+, etc) so it can be used to look for artifacts. Basically taking STR#2672's test/gleam application and moving it into unittests as one of the test screens (with some mods). This sounds like a good idea in any case: this is what the unittests framework was meant for really, I think! (I mean, adding on all sorts of useful testing features without having to ad new test programs directly.) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK version number update and releaseprocess [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packagedproperly]
On 1 Mar 2013, at 15:39, Greg Ercolano wrote: On 03/01/13 01:33, MacArthur, Ian (Selex ES, UK) wrote: What Mike said: As soon as *anything* in SVN changes after a release, we need to bump the version numbers in some way. Or, just change it immediately after release. Changing the version number is itself a change, and would therefore bump the svn version#. Ah, fair point. Though in a sort of self-fulfilling prophecy kinda way... Right, I think linux (or something) used even release numbers for dev (.0, .2, etc), and odd numbers for release versions (eg. .1, .3, etc). Yes - I always quite liked that, but they stopped doing it that way... Or, we could work the SVN version number into Enumerations.H (eg. FL_SCCS_VERSION?) which might be nice to have anyway so that someone with an app can see the FLTK version /and/ SCCS #. I think svn allows for hook scripts to be triggered whenever there's a checkin for this kind of thing. Pretty sure cvs had this too. I use svnversion for this in my own build script, but you are right, the svn hooks can probably do this in a neater way. Not sure what that number becomes if we ever move to git, though.. What it becomes, as you know, is a human-opaque string of gibberish... (Technically I understand why it is like that, but I really can't believe we couldn't figure out some way to hide that behind some human-friendly index...) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] C API experiment
Hi Patrick,Sounds like you are working your way through the history of language development, but in reverse order!;-)C++ - Ada - Cobol ...!Cheers,-- IanSent, much to my surprise, from my Palm Pre3On 22 Feb 2013 14:46, Patrick patr...@spellingbeewinnars.org wrote: Hi Sanel Thanks for responding to my post. Your ideas are terrific. I know a little about swig and pyFLTK but I didn't know anything about the other two options. So I have been going around it circles on and off for two years with GUI tookkits. I have tried virtually all of them now. I don't want to code in C/C++. I have been obsessed with Ada for about 15 months and the GUI options for it are horrible. Bindings for other languages are available but I couldn't figure out how to call back to and forth from Ada with them without somethign whacked liked using D-Bus. I have realized that pretty much everything I like about Ada is available from Cobol too and I have recently switched my focus. Open Cobol compiles to intermediate C. I was trying to figure out how to call back into C++ from C but then I finally realized I could just run the C code through a C++ compiler and have code at the same "level" as C++ and now I don't think I need to figure out a way to call "up" into C++. Having said that, I think that a C binding would really help the project and I would like to help, please let me know if I can. Thanks again-Patrick P.S have you tried chicken scheme? Is it suitable for you? You could also run it's intermediate C code through a C++ compiler and then you would be able to call into FLTK C++ ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] C API experiment
On 21 Feb 2013, at 14:36, Patrick wrote: I've only been using Fltk in pure C++ applications so far. Fltk is worth programming in C++ but I am not crazy about it. I don't like C either actually but it's easier to work with from other languages. I have read some other posts in the past about creating a C API and it looks like the main issue is that it would bloat FLTK. I doubt that bloat is the key - I suspect the problem is that many C++ projects, such as fltk, have a lot of overloaded function calls (that is, functions with the same name, but which take or return different parameters.) There's no way in plain C to have more than one function with a particular name, so there's no easy way to make a C API that maps one-to-one onto the C++ API. And from there on out, it just gets messy... I was thinking that if I was able to find a way to auto-generate a whole bunch of C functions that contain calls to all the C++ methods I could create the C binding and that if each was in it's own C++ file that contained the extern C brackets then there would be a mechanism to mitigate bloat. You probably need to investigate whether some form of IDL (Interface description language) could be used to specify the interface you want and have that create the C/C++ code for you. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature A thought: Should Fl_X11_File_Chooser maybe be called Fl_Fltk_File_Chooser or some such thing? In that, it is not really X11 specific, it is just a wrapper for the basic FLTK file chooser, so could be used on any host in principle (though in this case likely only under X11 I concede!) Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature Cool tweaks: very good stuff. But, addressing Sanel's observations: Do we want to do this? I wrote the code more as a proof of concept in response to the STR than as an indication of intent to do this... Sanel said: Sorry guys for commenting here (or maybe 'devel' list will be fine), but adding Gtk+ dialog in form of 'native' one, makes absolutely no sense. Yes, it is a tricky one, though I suspect for the majority of users, the gtk chooser is more familiar than our native one... So, what for example if I install Kubuntu where Qt is reference toolkit and remove all Gtk+ stuff? Is it then normal to expect FLTK to show Qt dialog as 'native' one? Yes, in particular this is awkward - though note that this already happens to me anyway; I have often had apps I'm running open the gtk file chooser, even though I'm running some KDE-based desktop. I assume I am not unique in this regard, so perhaps this is considered normal these days? In any case, if we go this way, we have to dlopen the gtk libs or the kde libs, having somehow decided which to actually use...? I *assume* there is some way (environment variables?) to determine what flavour of desktop the user is running? IMHO if user wants Gtk+-like dialog, how hard for him would be to dlopen() Gtk+/Motif/whatever... Yup - this code was meant to show exactly how hard it would be, and to provide a working example... not necessarily intended to be included into fltk core. In any case, if we did include this, it would need to ahve the ABI runtime guards around it for 1.3.3 or something? Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn'texactly native on linux
On 16 Feb 2013, at 07:07, Bill Spitzak wrote: Has anybody looked at exec'ing zenity or kdialog, etc? I'd never even heard of zenity until Greg mentioned that JUCE used it... It certainly looks like it could work for us; we'd want zenity --file-chooser zenity --file-chooser --multiple zenity --file-chooser --directory I guess to cover our normal cases. BUT... How widely deployed is it? A lot of the test boxes I have do not have zenity installed, though they do have gtk libs... Though these machines may be non-standard and therefore unrepresentative of course! 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... Thoughts? ___ 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 for fltk/examples source code
On 16 Feb 2013, at 02:19, Greg Ercolano wrote: I guess I kinda like Zlib (#2) or MIT(#3). #4(GPL2) if we can settle on exceptions. I would vote for zlib (#2) but suggest we add an explicit statement that is is OK to take these code examples and incorporate them into your own modules. I'm not keen on the MIT license these days, and very wary of the GPL, I don't think we can really use it for code that we *intend* people to modify without attribution, or other hindrance! On the more general note of licenses, I'm coming round to the MPL-2 these days, it seems to be a nice balance for things... But again, not appropriate for the examples folder I think... IANAL, as ever... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFC] a new class to support Internationalization
On 29 Jan 2013, at 17:35, Sanel Zukan wrote: Maybe question is why FLTK does not support (GNU) gettext across whole library? This way translation strings could be handled in more standard way and you will get for free a bunch of tools or services like Transifex. Hi Sanel, I'm not clear what you are proposing here: it doesn't seem to me that there are all that many strings in the library that are exposed in GUI elements, so I'm not sure what we would i18n here... What am I missing? There are a few places, e.g. in the fl_ask (and related) dialog boxes where strings are coded in, be ISTR that they are all accessible to be changed from user code at runtime? Other than that...? -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2925: Inherit Fl_Menu_Window from Fl_Double_Window to avoid flickering
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2925 Version: 1.3-feature I'm not sure what's being reported/requested here, or the context in which it is needed, can the OP please expand or clarify the situation? In particular, from the attached screen-grab, I infer that the host platform is probably OSX, in which case the single/double buffering thing is more confusing, since rendering on OSX tends to be buffered and composited in such a way that it is inherently double-buffered anyway, even if we use a single buffered window... So... Perhaps somnething else is causing flickering in this case? Anyway, I'm confused... Perhaps some example code that exhibits the problem might be helpful here? Link: http://www.fltk.org/str.php?L2925 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2926: Remove hardcoded extra pixels from menu window size
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2926 Version: 1.3-feature Can you mock up some expamples of how you'd expect it to look, and post these here too, for reference? Link: http://www.fltk.org/str.php?L2926 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2927: Please replace LEADING constant in FL_Menu.cxx to something changeable
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2927 Version: 1.3-feature Not sure what's being asked for here - the menu's look OK to my eyes... Can you post a mock-up of how you expected it to look? Link: http://www.fltk.org/str.php?L2927 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2925: Inherit Fl_Menu_Window from Fl_Double_Window to avoid flickering
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2925 Version: 1.3-feature Closed at the request of the OP Link: http://www.fltk.org/str.php?L2925 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2929: New Fl_I18n class to support internationalization of FLTK apps
On 28 Jan 2013, at 21:49, Manolo Gouy wrote: Link: http://www.fltk.org/str.php?L2929 Version: 1.3-feature A major issue: Fluid support for i18n is missing. I thought fluid could help with i18n... Yes, if you go Edit-Project Settings then you can select catgets or gettext support, and then use File-Write Strings to output the actual strings for processing... Or, is that not what you are meaning? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2816: Add ability to set proper window icons
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature This being so (the ABI safety of said patch) then I think this would be good to add... What do others think? Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2636: notification of clipboard changes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2636 Version: 1.4-feature Great - if this is indeed ABI-neutral then I am in favour... What do others think? Link: http://www.fltk.org/str.php?L2636 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #829: Support for animated GIFs in Fl_GIF_Image
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L829 Version: 2.0-feature Yes, I agree with Greg, this looks do-able now, with the ABI guards and so forth in place, and Marc's code looks decent, though might need poking a bit to make it more fltk-compliant! So, maybe an option for 1.3.x where x 2 then? Link: http://www.fltk.org/str.php?L829 Version: 2.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #829: Support for animated GIFs in Fl_GIF_Image
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L829 Version: 3.0-feature For now, I'm moving this to 3.0 (as it seems more appropriate there than 2.0) but I think we should consider putting onto 1.3.x with a suitable ABI-define guard around it... Link: http://www.fltk.org/str.php?L829 Version: 3.0-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2918: fltk-config adds unneeded libraries
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2918 Version: 1.3-feature I can't see how this patch can be correct for the general case where the linked libs refferd to are needed... In the general case, XFT et al will be needed, so removing them from the link, as shown in this patch, seems wrong. Perhaps the OP's system does not use or provide these libs? That does seem odd though, nowadays, unless it is a cut down system, or embedded, or something? In any case, I suspect the problem lies elsewhere - probably makeinclude or configure should not be setting those libs into the @LIBS@ symbol, if they are not needed by the system. Anyone have a view on this? Link: http://www.fltk.org/str.php?L2918 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2816: Add ability to set proper window icons
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature The patch looks OK to me, but I worry it may be ABI breaking? If so, we'll need to put ABI guards around it to stop it breaking any builds that are using dynamic loading of the fltk libs... Thoughts? Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2860: Multi-head full screen support
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2860 Version: 1.3-feature I quite like the idea of this patch, but do we need ABI guards around the new bits to prevent it breaking builds for folk using dynamic linking? Link: http://www.fltk.org/str.php?L2860 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2636: notification of clipboard changes
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2636 Version: 1.4-feature I think this would be useful - but it looks like an ABI-breaker to me (but what do I know!?) so maybe we need to defer it...? Thoughts? Link: http://www.fltk.org/str.php?L2636 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2816: Add ability to set proper window icons
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature @Greg: Quite probably - I'm quite happy to be wrong about ABI issues here, which is really why I flagged it up, so that someone who knows what they are talking about (rarely me) can say! It seems worth having, so if it will fly right, we should do it... Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Amalgamation
On 2 Jan 2013, at 11:08, superbem wrote: Happy new year! Another very nice feature regarding amalgamation, to the Fluid, would be a feature to have an generate code option to produce an amalgamation with the widgets used, then it includes the code on 3 files, the 2 as it are already now, then on the main one, include de generated sub amalgamation, instead the include pointers. That way the size isn't any more an issue. And very portable. As an option would be great. Something like that might be an interesting feature, more like modularization than strictly amalgamation - reminiscent of what JUCE's infojuicer can do with its modules in many ways. We'd probably still need some metadata for the widgets classes so we could resolve the dependencies quickly, so possibly non-trivial to implement. It may be possible to auto-generate the dependencies though? Might need a bit of though... Anyway, if you have patches to implement this, please post them on an STR so we can take a look. Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Text dragdrop within Fl_Text_Editor
On 28 Dec 2012, at 21:27, Manolo Gouy wrote: Both the Fl_Text_Editor and Fl_Input widgets support dragdrop of text, but only Fl_Input draws the cursor while dragging text around from the same widget to indicate where the drop would act. There's code in Fl_Text_Editor (case FL_DND_DRAG of Fl_Text_Editor::handle(int)) that moves the insertion point while text is dragged around, but the code for drawing cursor in Fl_Text_Display::draw() disables cursor drawing when there is a text selection. Thus, when doing a dragdrop of text within an Fl_Text_Editor widget, the user does not get an indication of where the drop would act through cursor drawing. Is this difference between the two text widgets a desired behaviour? I don't think it is intended: more consequential... The text editor is complex, and I suspect it is tricky (sometimes) to figure out where the insertion point really is... (or something like that?) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] New Cursors in fltk-3
On 22 Dec 2012, at 16:17, w. szukalski wrote: I need some more cursors e.g. for WebKit. So I have added them to 'src/fltk3/cursor.cxx' and 'include/fltk3/enumberations.h'. The test can be made with 'test/cursor'. The cursors are for Linux and X only. Winfried, Probably best to attach this to an STR so we have a record of it: though note it is more likely to be adopted if it exists for all 3 core platforms. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Amalgamation
On 26 Dec 2012, at 19:47, superbem wrote: With this we can do compilation cross-platform very trivial. It is already trivial: we worked hard to make it so. The fltk lib compiles on the majority of systems with no problems, and once you have it working fltk-config makes it possible to hide any platform variation in a simple way... Just add the one source file, change the compiler, whatever the ide, whatever the platform, always so easy to compile with the working project. Just add the source file to project, no linking headaches when we want avaiable x64 or x86 and so on. I think you can see the vision and get why is so straightforward. No, rather, I think you do not understand the complexities of interfacing at the OS and GUI layer, that we are hiding in the fltk libs. The one magic source file needs to conditionally compile for all the differing platform combinations we cover - hence the use of configure scripts and fltk-config to cope with that variation. Think about it, with all source in one source file, you can be 100% compatible with all platforms in a very simple way. We already are, as far as is possible. Another advantage FLTK will get is the audience will expand, as Amalgamations are so easy to implement. No, really, they are not. Not once the code goes above a moderate level of complexity. And they are not worth the effort to create in those circumstances either. This is an old story: I'm ancient enough to have been there when folk went through this before. Recall that once upon a time, all code was written as one big file. We invented linkers and so forth specifically so it did not have to be done like that any more. Why would we go back? The perceived advantages of a single file have been shown to be illusory so many times... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Amalgamation
On 28 Dec 2012, at 11:57, superbem wrote: Here are the script to produce the sqlite3 amalgamation http://www2.sqlite.org/cvstrac/fileview?f=sqlite/tool/mksqlite3c.tclv=1.26 I wonder how to adapt it to FLTK. Starting from sqlite3 may be a bad choice: it is small in comparison to fltk, and has few of our host/platform dependencies. (Also, they wrote their script in TCL, which would never have been my choice of language!) If you are set on trying this, you need to figure out how you plan on addressing the conditional inclusion of platform specific code into the core file, and how to resolve the dependencies. This is non-trivial and will be challenging. And, as you already know, I think it is a waste of time anyway... However, trying is good; even if it does not work, useful things may be learned, so go ahead, and let us know how you get on. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Amalgamation
On 26 Dec 2012 15:35, superbem super...@gmail.com wrote: I was seeking for a FLTK Amalgamation with no luck. An Amalgamation of FLTK will be very straightforward. Please consider. (reply)Um, I don't understand what's being asked here.Anybody?-- IanSent, much to my surprise, from my Palm Pre3___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
On 20 Dec 2012, at 16:46, Manolo Gouy wrote: Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature It works well here: Linux Debian 2.6 in VirtualBox with Gtk2 Cheers Manolo, Reassuring to know! I'm also in the process of creating an Ubuntu 12.04 LTS VM, for testing there, though I assume that would be A Lot like your Debian set up in most cases. Thanks, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature Attached file fnfc-gtk-patch-v2.zip... Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature Attachment: http://www.fltk.org/strfiles/2904/fnfc-gtk-patch-v2.zip ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature OK: revised version of previous patch. This now loads all the GTK and GLib dependencies (of which there are many...) at run time so that we do not have to link against any GLib libs at compile time (though you DO still need the GLib/GTK headers in place to compile the code, IFF you want to use the GtkFileChooserDialog mechanism. However, I still have not fixed the filter patterns - and to be honest, I doubt I ever will; this has been an interesting diversion thus far but I'm getting bogged down in details now and losing momentum. I also have not fixed configure, so you need to have a configured version of r9760 of fltk-1.3, then drop in the tweaked makeinclude in the V2 patch, and the new source file. What configure ought to do is figure out which version(s) of gtk are installed on the dev machine at compile time and adjust makeinclude accordingly. It should also set some #defines for the lib names to be used in src/Fl_Native_File_Chooser_GTK_Test.cxx. At present, you need to adjust both files manually for the purposes of testing. A further step might be to have src/Fl_Native_File_Chooser_GTK_Test.cxx probe first for gtk+-3.0 then for gtk+-2.0 then fall back to plain fltk chooser - that would be pretty easy to add, if we can be bothered... Note also that now, if the #define _TEST_GTK_FILE_CHOOSER is not set, then src/Fl_Native_File_Chooser_GTK_Test.cxx reverts to being the moral equivalent of src/Fl_Native_File_Chooser_FLTK.cxx at compile time and so can build on a machine that does not have the GTK/GLib dev headers installed. The changes here should be transparent on OSX and WinXX. I'd be interested to her whether they actually work on any system other than the F17 test box I've been playing on - I think it should work, but who knows!? -- Ian Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature Indeed so - and I was not suggesting I was all that keen on that approach - only that it looks feasible! I suppose a safe fallback might be to have it as an add-on, in the way the FNFC used to be, so folks could add it if they wanted it, since making fltk depend on GTK seems like an unusual' choice... Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature OK... So, despite saying I wouldn't, I had a quick stab at this. It is *very* incomplete, and I have made no attempt to load the GTK libs via dlopen() or otherwise, so to make this work it will link in the GTK dependencies directly, which is not what we want for every day use! Also, I never got around to implementing the filter patterns, so you get All Files mode all the time. Attached is a patch against r9760 of fltk-1.3, plus one new file src/Fl_Native_File_Chooser_GTK_Test.cxx which needs to be dropped into the appropriate place. I have NOT modified the configure script at all - you need to have an initialised, configured, checkout of 9760, then lay this patch on top of it. Then it Might Just Work. NOTES: The new file is really just src/Fl_Native_File_Chooser_FLTK.cxx hacked about; the intention is, once the dlopen() stuff is in place, that *IFF* we find usable GTK libs and so forth we use that, if not, the code falls back to doing what the stock linux FNFC does. However, this code is just a test and incomplete; in particular, there are a lot of places where I ought to have ifdef'd out some GTK stuff, that is always on here. so this will not build at all if the GTK dev packages are not on your machine. And, as noted above, a lot of the capabilities of FNFC, in particular the filter patterns, are not implemented - though the GTK widget should be able to do them, I never got around to it; it may be a fair chunk of work... Setting the working directory probably will not work - and the GTK widget has some odd ideas about that anyway... What works is selecting single / multiple files, single / multiple directories, file save, directory create. Finally; this is what it is - do not assume I will *ever* do any more work on this... Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature Attached file fnfc-gtk-patch.zip... Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature Attachment: http://www.fltk.org/strfiles/2904/fnfc-gtk-patch.zip ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature No, perhaps you misunderstand: it is not necessary to copy/paste anything from gtk. What we'd have to do would be something like this: (note that this is essentially what the Win32 and OSX cases do...) - We write a (probably C language) wrapper for launching GtkFileChooserDialog programmatically from within fltk, and passing in the various options that fltk knows and converting them to the GtkFileChooserDialog equivalents. (Turns out this might be quite straightforward, I had a brief look at the GTK+ docs last night and it seems do-able!) - At runtime, if someone wants a file-chooser, we use dlopen (or something...) to check for the presence of the required gtk/glib .so files and load them if available, then use our GtkFileChooserDialog wrapper. - if the gtk .so are not available, we use our stock fltk file-chooser instead, as we do at present. - Of course, on subsequent calls to the file-chooser we don't have to re-check for gtk, we already know the answer... As I say, this is very similar to what we do on other platforms, and only one file will contain any gtk+ code, so we are not importing large chunks of another toolkit or anything, just using their public API and calling the existing libs. Also, by loading the gtk libs via dlopen that ensures we do not need to link against those libs if we are not using them. Well, something like that, anyway. FWIW, I wrote a simple wrapper to test opening GtkFileChooserDialog in Open File and Save As mode, and it seemed to work and wasn't all that much code, so I think this can be made to function. Though creating the code to map all the fltk options onto GTK options is going to be non-trivial! Also, and this may be relevant, the GtkFileChooserDialog API seems to be more or less identical in gtk+2 and gtk+3 so there's a fair chance we could write one version of our wrapper function that would work in either case, regardless of what version of GTK the end-user had installed... Maybe... Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature No, I was mistaken about XDG, well at least xdg-open and the xdg-mime stuff does not do what is wanted, so the .../defaults.list file is not going to help: it is useful in determining what application the user wishes to use to open a given file type, but it does not appear to have a mechanism for identifying which file dialog to use for the file-open, file-save, file-save-as preferences. Rather, at least under GTK based systems (e.g. Gnome or LXDE) that appears to be done via the GtkFileChooserDialog mechanism. Now, in principle, it looks like we could *probably* detect the presence of the GTK mechanisms and then spawn a GtkFileChooserDialog, falling back to the fltk chooser if the GTK one was not detected. There's a bit of work integrating that though, because, as with other platforms, pulling in bits from another GUI toolkit gets messy... Looks like it could be made to work, in much the way the Win32 one does though, I *think*... (without trying to write the necessary code of course!) To the OP (netrick): if you want this, I suggest you take a run at it yourself and let us know how it goes - this is open source after all, and all are welcome. Otherwise, it may be some time before this gets looked at, as I doubt any of the core devs can take a run at this in the short term (too much to do...!) Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2904: Native file chooser isn't exactly native on linux
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature Is there an XDG code for this sort of thing? Does anyone know? Re: Greg's suggestion of a stand-alone chooser; ISTR that some tool (maybe LVE or something that no longer exists...) did exactly that, and I cobbled together a basic chooser that used fltk for my system, since the default source code that distributed with it used some GUI toolkit that I did not have on that machine... So, anyway, it is a well established idea, and maybe something to consider... Link: http://www.fltk.org/str.php?L2904 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Create a simple project with FLTK and use CMake
On 9 Dec 2012, at 15:04, giorgio wrote: Hello everyone, wanting to fill out a simple sample project with FLTK 1.3.1, using CMake what should I do ? Strictly speaking, you are asking this question in the wrong place; I've posted a redirected response over in fltk.general. See if that takes you anywhere. Note that as a rule, there are more folks active over in fltk.general, so always post there first since it is much more likely to get a quick (and helpful!) response! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] MacOS-specific bug in FLTK 1.3.1forunbundledapplications
On 2 Dec 2012, at 21:45, Manolo Gouy wrote:
The console thrown up by unbundled apps has always been with us
(in 1.3.0 and 1.1).
Hmm, that's not what I find: for me, the 1.1.10 tarball builds fine on =
OSX 10.6.8 and does not throw a console when I click on an exe in the =
finder...
Both the 1.3.0 and 1.3.1 tarballs do throw the console if I click from =
the finder though (unless the exe is bundled, then it is fine...)
One thing I do note is that the default icon shown for the exe's in the =
1.1.10 test folder differs from that shown in the 1.3.1 test folder... =
The 1.3.x ones have a console icon, whereas the 1.1.10 exe's have a =
default app sort of icon, so there is some underlying difference in =
play here...
Yes indeed, 1.1.10 executables don't throw a console when started
from the finder (I had not used 1.1.10 yet to see that).
I have seen that this is the result of running
this command after the executable link command:
Rez -t APPL -o myprog ../FL/mac.r
where the file mac.r contains
data 'carb' (0) {
};
This command can still be run on Mac OS X 10.8, even with 64-bit
executables, and still makes the console disappear. Also,
the Rez utility is still installed in /usr/bin/ when installing
the last c/c++ Apple compiler. So, all of this could be added back to
the current build scheme with configure+make. But that is very
Carbon-like. I wonder whether it would be a good thing to add it?
I also see it has been removed from 1.3.0 at some stage.
As I remember it, it was taken out of 1.3.x at about the same time that
fltk-config was modified to make bundles out of the exe and then create a basic
shell wrapper that points inside the bundle to allow easy command-line
invocation...
With those elements in place it is no longer necessary to attach a resource
fork to the exe, and it will all Just Work.
Well, probably...
The key here, it seems to me, is that the makefile is not taking advantage of
that facility when it builds the samples in the test folder, or indeed when it
builds fluid, and so we get the aberrant behaviour as reported.
If we tweaked the Makefile to do a fltk-config --post on the exe's as they
are built, then all may be well?
IIRC, the --post action is null on *nix and WinXX, and used to attach a rez
fork on OSX (in 1.1.x), and now (1.3.x) on OSX it makes a minimal bundle of the
exe instead...
That ought to be what we want?
--
Ian
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] MacOS-specific bug in FLTK 1.3.1forunbundled applications
On 1 Dec 2012, at 07:55, Manolo Gouy wrote: Launched from the finder, it works fine, but I'm still getting the console thrown up as well, which ideally I'd rather not have. Of course, it works fine if I bundle the exe in my regular build, or if I use fltk-config --post to wrap up the exe that way. The console thrown up by unbundled apps has always been with us (in 1.3.0 and 1.1). Hmm, that's not what I find: for me, the 1.1.10 tarball builds fine on OSX 10.6.8 and does not throw a console when I click on an exe in the finder... Both the 1.3.0 and 1.3.1 tarballs do throw the console if I click from the finder though (unless the exe is bundled, then it is fine...) One thing I do note is that the default icon shown for the exe's in the 1.1.10 test folder differs from that shown in the 1.3.1 test folder... The 1.3.x ones have a console icon, whereas the 1.1.10 exe's have a default app sort of icon, so there is some underlying difference in play here... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] MacOS-specific bug in FLTK 1.3.1 for unbundled applications
On 30 Nov 2012, at 15:52, Manolo Gouy wrote: MacOS-specific bug in FLTK 1.3.1 for unbundled applications I have noticed with STR #2890 a Mac OS X-specific bug present in FLTK 1.3.1: unbundled applications don't appear in the dock and don't show their system menu. [For developers unfamiliar with Mac OS X: a standard Mac OS application with GUI is normally bundled, that is, made of a number of files, among which the executable program, all belonging to a directory. Non GUI-using applications are usually unbundled, that is, made of a single executable file. A GUI-using, unbundled app is nevertheless possible, but suboptimal.] . This bug is worse than that because unbundled applications can't take keyboard focus at all. New FLTK 1.3.1 users on the Mac who use the configure+make or Cmake build systems see a very bad image of FLTK test applications. I therefore believe 1.3.2 should be released to fix that. Not yet... Testing on my 10.6.8 Mac, and building at the command line using configure/make I find that: - the current SVN does not work, though it *nearly* does. If I launch the executable from the shell itself, it works, but if I launch it from the test/demo wrapper, then it does not accept input. If clicked in the finder it works but I get a console that I do not really want. - the fltk-1.3.1 tarball does not work. At all. If launched from the shell then all typing goes to the shell, not to the exe. If launched from the finder, I also get an unwanted console. - the fltk-1.3.0 tarball does work, the exe's behave as expected whether they are launched from the shell or from the test/demo wrapper. Or, indeed, from the finder, though the finder does throw a console that I don't need. Of course, I never really noticed this before as I always build my own code as a bundle anyway, which makes the problem go away... Didn't fltk-config used to bundle everything up on OSX? Does it not do that any more? OK... Just checked it, and it looks like it does (fltk-config --post)... Can we not leverage that to make all the OSX tests be bundles and then it will Just Work? Or do you have a better solution? -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] MacOS-specific bug in FLTK 1.3.1 forunbundled applications
On 30 Nov 2012, at 18:25, Manolo Gouy wrote: Testing on my 10.6.8 Mac, and building at the command line using = configure/make I find that: - the current SVN does not work, though it *nearly* does. If I launch the executable from the shell itself, it works, but if I launch it from the test/demo wrapper, then it does not accept input. If clicked in the finder it works but I get a console that I do not really want. I can see that as well. ... Or do you have a better solution? I believe it's now fixed with r.9734. Almost... launched from the shell seems good now, and from the test/demo wrapper. Launched form the finder, it works fine, but I'm still getting the console thrown up as well, which ideally I'd rather not have. Of course, it works fine if I bundle the exe in my regular build, or if I use fltk-config --post to wrap up the exe that way. So... very near; certainly much better than the fltk-1.3.1 tarball does. Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] When compiling fltk 1.3.1 with gcc4 on mingwcross compiler under cygwin, configure can not detect pthread and dies
On 28 Nov 2012, at 18:08, ggiorgio63 wrote: I was able to complete the FLTK library using MinGW + MSYS. I would like to solve the problem, however, is this: in MSYS (automatically installed with MinGW 4.6.2 using mingw-get-inst-20120426.exe) sometimes does not work the unix command ls, autoconf and fltk-config. How can I do ? I have no idea - I've been using Msys for years now, and it has pretty much always Just Worked. Which shell terminal are you actually using with Msys? It comes with several, and the default DOS box one is not to my taste, so I usually use their mingw-rxvt or mintty options instead. See if that makes it work better... Other than that, I don't know what to suggest - might get more sense out of the mingw lists, if there is a problem, then surely folk over there will be seeing it too. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fl_register_images() for FLTK2
On 27 Nov 2012, at 19:19, Jerome M. Berger wrote: Ian MacArthur wrote: And to answer your specific question, there is no fl_register_images() function in fltk-2; that function is from fltk-1.x series... However, there is a fltk::register_images() function in the fltk2_images library... Yes, fair point. As a general rule, a lot of things that were fl_something... in fltk-1.x became fltk::something... in fltk-2 (though not always!) My concern would be that the OP really needs fltk-1.x, from the context of the question, so that would be the safer option in this case. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fl_register_images() for FLTK2
On 27 Nov 2012, at 21:26, ggiorgio63 wrote: where can I download the fltk-1.3 ? The http://bibosoft.spacequadrat.de/pub/devpaks/fltk-1.3.x-r7996-bibosoft.DevPak the server does not work... help We don't provide the fltk libs in the form of devpaks, they are generated by users out in the community. There may be suitable bundles for fltk-1.3.1 available but I do not know of, nor can I recommend, any. We would recommend that you obtain the fltk-1.3.1 tarball here: http://www.fltk.org/software.php?VERSION=1.3.1FILE=fltk/1.3.1/fltk-1.3.1-source.tar.gz And build that yourself - building fltk from scratch is (almost!) trivial and a useful exercise, and using the resulting libs with whichever IDE is straightforward. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] When compiling fltk 1.3.1 with gcc4 on mingw cross compiler under cygwin, configure can not detect pthread and dies
On 27 Nov 2012, at 21:28, green fox wrote:
Enviroment:
OS Windows7 , cygwin 1.7.14(0.260/5/3) , gcc 4.5.3
Used ./configure --enable-threads --prefix=/usr --host=x86_64-w64-mingw32-gcc
Problem:
Dies when compiling threads.cxx... with
threads.h:56:74: error: `_beginthread' was not declared in this scope
Due to headers for _beginthread() missing in some mingw packages.
MingW packages are supposed to have them.But current cygwin package
somehow does not have it.
Digging around cygwin mailing list, there appears to be fix on the
next release, however ETA is unknown.
Using gcc3 is a workaround, but defeats the whole purpose of
mingw-gcc4, and -mno-cygwin is long gone.
For the current situation, most likely one has pthread, so the logical option
is to use pthreads instead of the native _beginthread(). Am I on the
right track ?
It is possible, but I'd caution against that - fltk on WinXX is intended to run
native and use Windows threads, not pthreads, so if you end up in a odd mix
of Windows and pretend-unix runtime code, things can go awry...
I gave up on cygwin a long time ago, switched to mingw, and never looked back.
IFF you actually *need* the pretend-unix runtime that cygwin provides (e.g.
if you are porting a large body of unix-specific code and you really, really,
really need fork and pthreads and so forth) then cygwin is a good idea, but
otherwise I'd bin it and do a mingw thing instead. Really... save yourself the
pain...
Though to be honest, it wasn't the poor compatibility that drove me away from
cygwin, it was the performance; a long time ago we had a large cross-platform
codebase, where the Win32 build was done with cygwin and it was dog slow...
Some brief experiments with mingw showed it was about 3 times faster executing
our code - we switched, and never went back. We never even bothered trying to
scope out where the bottlenecks were, we just moved on...
Sure, it is a bit more hassle in the code (we need to ifdef the Win32 stuff vs
the unix stuff that linux and OSX use) but that turns out to be mostly trivial,
and the resulting code works well everywhere.
What would be the better option
1) Patch configure.in so that it has --enable-pthreads or such
Patch towards 1.3.1 ? or would it be better to do work on the 1.4/3.0?
2) Fiddle with config.h for HAVE_PTHREAD_H 1
3) Throw away cygwin :-)
Option 3 every time.
My limited knowledge tells me that _beginthread() is defined in process.h
http://msdn.microsoft.com/en-gb/library/kdzttdcb%28VS.80%29.aspx
And looking at ./test/threads.h , under #elif defined(WIN32)
!defined(__WATCOMC__)
we have #include process.h , so all is good.
We have
mingw64-x86_64-{gcc,gcc-core,gcc-g++,gcc-objc,headers,pthreads,runtime}
installed, good.
But we do not have _beginthread() anywhere. So I need a header for that, or
if we can use pthread,that can provide equlavant.
The _beginthread() function is the Win32 equivalent to pthread_create(), and it
should be in the Win32 header file process.h. If the version of process.h that
your compiler provides (assuming it is meant to be emulating the MS headers of
course!) does not provide _beginthread, then I'd hazard that it is broken, and
should be discarded or fixed...
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fl_register_images() for FLTK2
On 26 Nov 2012, at 21:37, giorgio wrote: hello all. I have FLTK2 (fltk-2.0-win-bin.zip) with MinGW 4.6.2 on Windows XP. I can not find the function fl_register_images() How should I do ? You most probably do not want to have fltk-2; it is generally deprecated for new projects and never left alpha. You should be using fltk-1.3 (note that 1.3 is much later than 2.0, despite the apparent ordering that 2 1 implies!) If you want the current alpha build you could try fltk-3, but in practice you would be better off starting with fltk-1.3.1 and see how you get on. And to answer your specific question, there is no fl_register_images() function in fltk-2; that function is from fltk-1.x series... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Q: Why does --enable-xft modify CPPFLAGS and CXXFLAGS but not CFLAGS ?
On 24 Nov 2012, at 11:34, Jeremy Henty wrote: Ian MacArthur wrote: On 23 Nov 2012, at 19:29, Jeremy Henty wrote: Looking through configure.in I am surprised that --enable-xft does not modify CFLAGS as it does CXXFLAGS and CPPFLAGS . It seems natural to treat CFLAGS the same way. Why is it different? I suspect that reason *may* be simply that CFLAGS is only used within fltk for a few special utility files that don't do text rendering or something, so there was no need to alter it ..? But CFLAG also determines the output of fltk-config --cflags which is publicly advertised in fltk-config --help as flags to compile C using FLTK, so it hshould really do the right thing. Yes, I understand why it may be an issue; I was just theorising about why it might be the way it is... I guess, realistically, it is hugely more likely that fltk-config will be called upon when processing C++ code than C code though, at least for anything that is rendering text, so maybe the fact that its C output is broken only affects a very small set of users, hence it has never been noted before? In any case, I'd suggest that posting an STR recording your findings is a good idea, in the hope that we get around to fixing this! Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Q: Why does --enable-xft modify CPPFLAGS and CXXFLAGS but not CFLAGS ?
On 23 Nov 2012, at 19:29, Jeremy Henty wrote: Looking through configure.in I am surprised that --enable-xft does not modify CFLAGS as it does CXXFLAGS and CPPFLAGS . It seems natural to treat CFLAGS the same way. Why is it different? Dunno. History? I suspect that reason *may* be simply that CFLAGS is only used within fltk for a few special utility files that don't do text rendering or something, so there was no need to alter it ..? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] CRIT STR #2881
Fixing STR #2881 (Check image bounds before allocation) requires
to check for failed memory allocation. Without exception handling,
I believe the only way to do it is:
#include new
...
array = new(std::nothrow) char[xxx];
if (!array) longjmp(xxx, 1);
which violates the CMP because it uses the standard library and
the std namespace.
What should we do?
So, here's a thought; though this will require close examination by those who
know C++ better than Iâ¦
Today, while reviewing some old code, I was reminded of the existence of the
so-called placement new operator in C++ (which, as we are surely all aware,
allows for the creation of an object into memory in a previously allocated
buffer.)
So, that goes something like this (dodgy psuedo-code from memory alert!)
#include new
:
:
:
void *pv = malloc(sizeof(object_we_want) + a_bit_more_for_safety);
if(pv)
{
my_widget *widget = new (pv) my_widget(params...);
}
else
{
print(failed to alloc object);
}
That means we can allocate the buffer and make sure it is valid, before we
new the array on it. And without throwing the exception. And it is (AFAIK)
widely supported by compilers, if little used!
However; I'm not actually sure this will work - it may be the case that if we
new the array with the placement new operation, then maybe just calling
delete will not work? I do not know.
Note that where I had used this before was in an embedded system, and we needed
to precisley control the placememnt and alignment in memory of all our objects,
so we created them this way rather than allowing them to be constructed on the
stack or with a plain new call.
But we never deleted anything; we just turned the power off...
Here, we will want to delete the allocation, with (I assume) something that
looks like an ordinary delete call.
Maybe the (std::nothrow) option is the best bet!
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] CRIT STR #2881
On 5 Nov 2012, at 20:55, LZAntal wrote: Fixing STR #2881 (Check image bounds before allocation) requires to check for failed memory allocation. Without exception handling, I believe the only way to do it is: = #include new ... array = new(std::nothrow) char[xxx]; if (!array) longjmp(xxx, 1); = which violates the CMP because it uses the standard library and the std namespace. = What should we do? Can we just use malloc instead of new, then check whether we get a NULL pointer or not? Yes, but this would require to rewrite the deallocating code to use free() instead of delete, and make sure every possible instance is changed. Ah, ok... I don't think we should throw an exception, so if here's no other way to prevent new from throwing the exception, I guess we are forced down this route? Anybody…? Could we just do a temporary allocation with malloc() and check if it worked, if so free it and use new on it. We did this many years ago to load assets. Probably there is a modern approach to this by now I am still a little rusty with c++ No, you get a race, or at least the possibility of a race, on any modern (i.e multi-threaded, multi-core) CPU, so the fact that malloc succeeded does not mean that new will too, even if called just after you free the malloc. And of course, new may try to allocate more memory than malloc, since it will probably be storing additional meta-data about the object just allocated that malloc doesn't bother with... So, in practice, probing the heap with malloc would probably work most of the time, right up until it doesn't and the whole thing blows up. If it is the case that new wants to throw the exception (I just do not know if that is the case!) then maybe we do need to use the std lib calls to suppress that behaviour? ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK ANSI C API
On 28 Oct 2012, at 00:04, Patrick wrote: Thanks for responding to my post Ian No worries. It doesn't sound like it's a totally insane thing, so I am going to go for it. Even if I fail, I will learn something. It is certainly feasible, and others have used this approach for their problems in the past. Though, I would suggest that before doing that, you play around with fltk, in C++, until you have a good feel for which widgets (and which bits of those widgets!) you will most want to use, and focus on creating bindings for that subset first, and build out form there... Then, if nothing else, you will pick up a little C++ by osmosis along the way! I really love Ada! Yep, I hope things will turn around but right now it looks like it's best days are behind it. It does have very good support, built right into the language, for threading. Maybe this will be a draw in the age of multicores. SUre, though I was never that keen on the Ada approach (indeed, and this may be age revealing...) at the point I first picked up Ada, I'd been developing and maintaining a codebase written in CORAL-66 with the MASCOT extensions, which had a tasking model I actually quite liked... More than Ada's anyway. And of course many modern languages have tasking/threading models built in now, even C++11... I think Ada is the perfect tool for me, the police-state compiler will help me ship less bugs and I love the language itself. Though I'm not that convinced by the police-state compiler argument; one of the ideas that led to the aerospace folk going for Ada heavily was that the compiler would help folk make fewer mistakes. But in practice, it never really happened; it turned out that a lot of the mistakes people make are, in large part, not the ones the compiler catches, at least over a complex code base. Far more of the expensive issues are/were conceptual problems with the design and that sort of thing, far fewer of the buffer over-run and incorrect types problems. That is, the real problems with programming complex things often tend to be independent of the language chosen to code the solution. And of you want a strict check of your code, there are good static analysis tools for most languages these days, that will point out all the weaknesses that the Ada compilers find, and more besides... Though over time I have come round to the view that passing your code through a strict static analysis tool every now and then is helpful and informative: I used to be very against them, but I have been converted! (more or less.) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] support for scaling text?
Hi Evan, On 24 Oct 2012, at 20:26, Evan Laforge wrote: fl_draw has some hardcoded support for rotating text, but what about scaling? Well, scaling along one axis, obviously scaling on both axes is wel supported :) I noticed that whether or not it pays attention to the transformation matrix is undefined, and on OS X at least, it doesn't. Does anyone know of the top of their head if there is some way to stretch text vertically or horizontally? If you are happy with a nasty(ish) looking hack, then a while back, in response to a forum question, I posted a working example that simply wrote the text into an offscreen then stretch-blited that onto the screen, allowing for vertical or horizontal stretching... Didn't look all the great at large scales mind you! However, I suspect you want something more elegant that takes advantages of the anti-aliasing inherent in proper text rendering engines... Still, it will be in the archives somewhere, or I can post the code again tomorrow if I can find (and if you are interested!) A brief look at the Cocoa docs yields this page: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CocoaDrawingGuide/Transforms/Transforms.html It implies that the current transformation matrix applies to text too, which implies that if the fltk transformation matrix maps directly to the OS X one then this support should come for free. However, if this can't be supported on other platforms, perhaps the cocoa fl_draw explicitly disables the transformation matrix for the sake of consistency. In that case, it would be nice to have an escape hatch explicitly marked as non-portable, with perhaps a TODO to see if this can't be extended to all platforms. My understanding is that over the years X and Windows get fancier drawing systems that tends to bring them towards the OS X level of fanciness. I suspect (but am not certain) that it is possible on all platforms (XFT will support a transform matrix, for example, and which I think might also allow scaling per-axis) and ISTR that the WIN32 API can too. So... the kicker may mainly be that no one has done the work? Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2842: putting new widget on place of user's click
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2842 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2842 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2841: preventing of unintentional removing in Fluid
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2841 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2841 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2876: Make xft font sorting work (patch supplied)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2876 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2876 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2867: ADding bgcolor to Style_Table_Entry
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2867 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2867 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2840: Fluid doesn't release images
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2840 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2840 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2838: Add Colors to FL_Text_Display (+ underscore + strikethru)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2838 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2838 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2835: Fl_Widget::do_callback() should check callback_ for NULL
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2835 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2835 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2830: Fl_Input is limited to 1023 bytes but not documented
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2830 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2830 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2834: Make Fl_Help_View draw() and handle() public
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2834 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2834 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2815: Implementation of Fl_Text_Display backdrop
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2815 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2815 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2816: Add ability to set proper window icons
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2816 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2817: Add a hook to track timeouts
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2817 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2817 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2821: MouseWheel acceleration patch
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2821 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2821 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2860: Multi-head full screen support
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2860 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2860 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2824: Adding scroller animation to FLTK
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2824 Version: 1.3-feature Link: http://www.fltk.org/str.php?L2824 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fluid broken in fltk3?
Getting a lot of this when fluid runs in fltk3 builds... Generating CubeViewUI.cxx and header from CubeViewUI.fl... Compiling cursor.cxx... 2012-09-27 19:00:02.744 fluid[5003:903] *** __NSAutoreleaseNoPool(): Object 0x100303400 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-09-27 19:00:02.747 fluid[5003:903] *** __NSAutoreleaseNoPool(): Object 0x1003175e0 of class NSCFData autoreleased with no pool in place - just leaking Compiling curve.cxx... Compiling device.cxx... Compiling doublebuffer.cxx... Compiling editor.cxx... Generating fast_slow.cxx and header from fast_slow.fl... 2012-09-27 19:00:02.893 fluid[5042:903] *** __NSAutoreleaseNoPool(): Object 0x100303400 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-09-27 19:00:02.895 fluid[5042:903] *** __NSAutoreleaseNoPool(): Object 0x1003175e0 of class NSCFData autoreleased with no pool in place - just leaking Compiling file_chooser.cxx... Compiling fonts.cxx... Compiling fractals.cxx... Compiling fracviewer.cxx... Compiling fullscreen.cxx... Compiling glpuzzle.cxx... Compiling gl_overlay.cxx... Compiling hello.cxx... Compiling help.cxx... Compiling iconize.cxx... Compiling image.cxx... Generating inactive.cxx and header from inactive.fl... 2012-09-27 19:00:03.537 fluid[5122:903] *** __NSAutoreleaseNoPool(): Object 0x100303400 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-09-27 19:00:03.539 fluid[5122:903] *** __NSAutoreleaseNoPool(): Object 0x1003175e0 of class NSCFData autoreleased with no pool in place - just leaking Compiling input.cxx... Compiling input_choice.cxx... Compiling keyboard.cxx... Generating keyboard_ui.cxx and header from keyboard_ui.fl... 2012-09-27 19:00:03.576 fluid[5144:903] *** __NSAutoreleaseNoPool(): Object 0x100303400 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-09-27 19:00:03.579 fluid[5144:903] *** __NSAutoreleaseNoPool(): Object 0x1003175e0 of class NSCFData autoreleased with no pool in place - just leaking Compiling label.cxx... Compiling line_style.cxx... Compiling list_visuals.cxx... Compiling mandelbrot.cxx... Generating mandelbrot_ui.cxx and header from mandelbrot_ui.fl... 2012-09-27 19:00:03.768 fluid[5177:903] *** __NSAutoreleaseNoPool(): Object 0x100303400 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-09-27 19:00:03.771 fluid[5177:903] *** __NSAutoreleaseNoPool(): Object 0x1003175f0 of class NSCFData autoreleased with no pool in place - just leaking ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2874: Allow turning off Xft support without recompiling FLTK
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2874 Version: 1.3-feature Fix Version: 1.3-current Though note that, as it stands, we can't actually support this; there are some low-level choices made at compile time that mean our X11 code is either set for XFT or for Xlib fonts, and dynamically switching at runtime is not feasible. So... we would maybe have to rework quite a lot of code to make this fly, I think... Link: http://www.fltk.org/str.php?L2874 Version: 1.3-feature Fix Version: 1.3-current ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2874: Allow turning off Xft support without recompiling FLTK
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2874 Version: 1.3-feature Fix Version: 1.3-current Yes, I'm not all that keen on adding this: That said, it might not require a conditional test for every font API call - I had sort of imagined that (if we did this) we'd have both the XFT and Xlib font code in the fltk lib (and in the app binary) and at app launch we'd attach one or other mechanism to the actual runtime code... I guess the abstracted rendering code in the fltk-1.3 and fltk-3 might even help with this...? Anyway, then the user could change font rendering with an env var, but changing would entail exiting and restarting the app I guess. In any case, I'm not all that keen... Link: http://www.fltk.org/str.php?L2874 Version: 1.3-feature Fix Version: 1.3-current ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2866: FLTK performace is too low?
[STR Closed w/o Resolution] Link: http://www.fltk.org/str.php?L2866 Version: 1.3-feature Fix Version: 1.3-current General support is not available via the STR form. Please post to the FLTK forums and/or mailing lists for general support. All, I am now closing this STR (in line with policy, I believe) since this is clearly neither a bug nor a feature request but is a discussion on implementational aspects specific to the OP's platform. Please move this discussion to the fltk.general list. If further issues are identified that are demonstrably bugs, please post those specific issues here. To the OP (qixinrenzz) please come join us on the fltk.general list and we can talk at length about your problem and see if we can identify the cause of your issues. It is fair to say that I am *not* seeing the performance problems that you report! Thank you. Link: http://www.fltk.org/str.php?L2866 Version: 1.3-feature Fix Version: 1.3-current ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2866: FLTK performace is too low?
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2866 Version: 1.3-feature All, I'm going to suggest we close this STR and ask that the OP bring the questions to the fltk.general list for a more appropriate discussion. Does that sound OK? Before I go, to the OP: Can you provide more detail of what you are doing? The timings you report are so far out of synch with my experience that I wonder what it is you are measuring - can you explain, please? Post more details over in the fltk.general list where we can all take a look at what is going on... Also, that configure line looks bogus for an ubuntu system; the --disable-cygwin only has meaning on a Windows system, and if you --disable-x11 what windowing system are you using? Also, linking shared is probably not helpful as that will not make for the smallest or fastest loading binaries, if that is what is important to you. In general, fltk is better suited to static linking, and that is the preferred usage pattern. What version of fltk are you testing with? Link: http://www.fltk.org/str.php?L2866 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 r9661 build errors on centos 5.6 x64
On 13 Aug 2012, at 20:06, Greg Ercolano wrote: Just updated fltk3 to current (9661), and am getting these build errors on a default 'make distclean; make': * * * [..] Compiling fltk3gl/glut_font.cxx... /usr/bin/ar cr ../lib/libfltk3gl.a ... Compiling fltk3images/BMPImage.cxx... Compiling fltk3images/FileIcon2.cxx... Compiling fltk3images/GIFImage.cxx... Compiling fltk3images/HelpDialog.cxx... Compiling fltk3images/images_core.cxx... Compiling fltk3images/JPEGImage.cxx... Compiling fltk3images/PNGImage.cxx... Compiling fltk3images/PNMImage.cxx... /usr/bin/ar cr ../lib/libfltk3images.a ... Compiling fltk3png/png.c... fltk3png/png.c:14:21: error: pngpriv.h: No such file or directory Yup, I think I reported that a while back; might even have flagged an STR now that I think of it... Um... 2833 is the one. Comments there please, I guess. The crux appears to be that if you build fltk3 with the system PBG (etc.) libs the Makefile still tries to build the private PNG lib too, but on many systems the system PNG headers do not match (are older, in my case) than the fltk byult-ins and so compilation fails... Now, I tweaked the Makeinclude to do the right thing, so I guess we could make a similar change in the makeinclude.in and it would stay fixed. Or... maybe not. Note that Jenkins does not flag this error since it always explicitly uses the built-in libs rather than allowing the system ones to be picked up. Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Term license?
Well, for what it is worth, I used my flterm code to run vim on linux and OSX, though only to see if it worked. I didn't try emacs, since I still don't know how to actually use it... (emacs that is.) As far as it goes, the terminal emulation is really the easy part, actually interfacing that to the system is much harder - almost easy enough on *nix like boxes, but harder on WIN32. Also, once you want to deal with resizing the window and all that it starts to get tricky, even on a *nix system, so flterm nearly has support for being resized, but it doesn't really work: I started to get into the nasty details of handling the signals and ioctl and so on and it stopped being any fun and... I also had a partial telnet client running that did work on winxx as well as the *nix like machines, but again lost interest once it started to be actually hard. So, overall, the terminal emulation part is mostly OK, in a sort of early 80's terminal that will not handle Unicode or anything sort of way, and which doesn't handle resizing at all well. If you can contrive to deliver a stream of ASCII characters into the input buffer (and read them from the output buffer) it may be just fine, but anything more complex may get real tricky, real fast. What exactly would you want to use it for? Maybe it is good enough... Maybe not! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Term license?
On 3 Aug 2012, at 20:46, Greg Ercolano wrote: On 08/03/12 12:31, Cliff Yapp wrote: In looking around at available FLTK widgets, I came across this page: http://www.9edgedown.talktalk.net/flterm.html Pretty sure this is Ian MacArthur's work.. He's still active on the list, so I'm sure he can weigh in. Yes, I did that as a hack way back when, but no work has been done on it since. I've PM'd the OP (Cliff Yapp) saying basically he can use the code if he likes; I posted it on the web with no explicit license, which in retrospect was a mistake I guess. Anyway, I guess I had the fltk license in mind, though if CY wants the use of the flterm code then he's basically welcome to it. If I had more time, I'd probably be all over this project, as working on vt100 emulation (and xterm) has always been an interest since my early days, but never had the time to follow through. Yup. me too... Like a lot of projects, I worked on it until it *nearly* worked the way I wanted then lost interest...! Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Term license?
On 3 Aug 2012, at 21:54, Matthias Melcher wrote: FLTK2 has an ANSI widget. OK, it's by no means an XTerm, but there may be some overlap?! I tried it (though not recently) but I found that in practice it did not work very well, nor consistently across platforms, so I wasn't all that keen on it (I'm referring to the fltk-2 ANSI widget here, that is...) That said, there are a heap of widgets in fltk-2 that strike me as non-core and that shouldn't be in the library; maybe in an add-ons package, but not in the main lib. And the ANSI widget (and indeed my terminal widget) are in that category! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK - memory leaks
On 27 Jun 2012, at 19:28, Mikhail Tchernychev mikhail_tchernyc...@yahoo.com wrote: There is also other tool, valgrind, widely used under Linux. Yes, we are familiar with valgrind, and FLTK is checked with it fairly often. Be aware that interpreting the output of such tools is quite tricky. Are you sure you know how to discriminate between leaks, and the normal runtime footprint of the code? Note that allocations that are made when the app starts, and are not free'd until the runtime releases them on app exit are *not* leaks. Similarly, it is not always a leak if a widget destructor is not called. It is only a leak if the memory footprint increases over time due to memory management. AFAIK there are currently no leaks in FLTK. If you have evidence to the contrary, please post an STR detailing your findings and the steps to reproduce, so that we can investigate further. Thanks... -- Ian Sent, much to my surprise, from my iPhone ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] font problem : probably not fltk
On 25 Jun 2012, at 16:25, David Currie curri...@iinet.net.au wrote:
had to fresh install ubuntu 12.04 + reconfigure various packages.
Now.
static int G_usesymbols = 1;
cMeasure(int pPixlW, int pPixlH,const char* pStr, Fl_Font pFont,
Fl_Fontsize pFontSize) {
fl_font(pFont, pFontSize);
fl_measure(pStr, pPixlW, pPixlH, G_usesymbols);
} // gregs function stolen from the doco
previously used to give different results for different pFontSize's
Now all fontsizes return font 10 results.
This feels like a graphics library problem. (Ubuntu Software Centre found NO
FLTK - only FLUID)
so I used Ubuntu Software Centre to install FLUID which I assume installs
FLTK.
I un tar'd fltk-1.3.x-r9625 as I would prefer to have this as the only
version.
My test program worked before the fresh install (12.04) but now has ONLY font
10.
What (graphics??) Libraries am I missing ? Is this a Ubuntu problem ?
I suspect I must install some more standard packages. If so What ?
In general I'm a big fan of ubuntu but it is certainly true that their releases
have been getting progressively less developer friendly such that I end up
spending a lot of time adding dev packages to every fresh install.
If I were as smart as I pretend, I'd have made a list or even a script to
automate that but I end up doing it by hand every time.
FWIW I think Greg did make a list and post it on his site...
Anyway sounds like you are missing (at least) the XFT and possibly Fontconfig
dev packages.
--
Ian
Sent, much to my surprise, from my iPhone
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 / mingw / winXP - fluid currentlyborked for me...
Thanks. Fluid3 suffered somewhat from the recent changes. I will see what I can do. FWIW, the failure seems to be peculair to my old mingw set-up, that uses the older gcc-3.4.x toolchain. #If I build from clean on a new mingw set-up using whatever is current from their repo, it seems to build OK (that's using gcc-4 etc...) So... quite possibly something in my configuration rather than anything in our code. Maybe...! ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 fltk3connect issues?
On 16 Jun 2012, at 23:48, Matthias Melcher wrote: On 16.06.2012, at 22:58, Ian MacArthur wrote: On 16 Jun 2012, at 00:10, Matthias Melcher wrote: OK, I think I have Connect pretty stable. I will implement HTTP GET in the next days and then fix FTP (I may remove the file date stuff...). Comments and suggestions are welcome ;-) (Without actually writing any code to use...) I had imagined we could do the time / date stuff just by reverting to some sort of lowest common denominator (e.g. time_t perhaps) and convert the OSX stat values to that format internally... And then it would all just work and ... Well. I don't know really... Yes, sounds like a good idea. I think that Apple used a struct instead of time_t to avoid running into some y2k issue. Not sure when time_t will wrap?! Ah, well that depends on what size you think time_t is... If it is a signed 32-bit int, then sometime in 2038. If it's 64-bit, well, then we are not so worried I guess! (Approx. 292 Billion years, in case anyone was wondering...) ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 fltk3connect issues?
On 16 Jun 2012, at 00:10, Matthias Melcher wrote: OK, I think I have Connect pretty stable. I will implement HTTP GET in the next days and then fix FTP (I may remove the file date stuff...). Comments and suggestions are welcome ;-) (Without actually writing any code to use...) I had imagined we could do the time / date stuff just by reverting to some sort of lowest common denominator (e.g. time_t perhaps) and convert the OSX stat values to that format internally... And then it would all just work and ... Well. I don't know really... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] fltk3 fltk3connect issues?
All, The new fltk3connect stuff seems a little fragile right now... Jenkins seems broadly unhappy about building it... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Manolo: can you check STR#2848? (Fl_Cocoa.mmrelated..)
On 1 Jun 2012, at 22:59, Greg Ercolano wrote: On 06/01/12 14:33, Ian MacArthur wrote: I was under the impression that it would play fine with pthreads, if you made at least one (possibly dummy) NSThread first, just to wake up the thread safe mechanisms Yes, that is true and is one of the two approaches we can use. The STR goes into the details. I was thinking the 'correct' approach would be to use Apple's native NSThread library in our Fl_cocoa.mm code. But if that turns out to be bumpy, the approach you mention is surely the easier of the two to implement. One reason that might be necessary; the code uses pthread_join() which might not have an NSThread equivalent. Here's the thread features the add_fd() code currently uses on the mac (cocoa and carbon): mutex lock/unlock pthread_create pthread_cancel pthread_join The thread cancel stuff is used by the destructor code to ensure any child thread started is stopped. 'join' is used to wait for completion. Yup - that would be my worry though; we need to join so we can wait for the worker thread expiring... But will that play well mixing pthreads and NSThread's...? I just don't know (though on OSX it is entirely possible the NSThread and pthread have a common underlying implementation of course, I guess... This can perhaps be done differently with NSThread, but sometimes it's better to change less code than to be 'native'. Wasn't sure on this, which is why I seek Manolo's input, as he's probably the most familiar with the NSThread stuff. Seems like a sound idea! Cheers, -- Ian ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Manolo: can you check STR#2848? (Fl_Cocoa.mm related..)
On 1 Jun 2012, at 20:46, Greg Ercolano wrote: Hi Manolo, Since you're our Fl_Cocoa.mm guru, was wondering if you could weigh in on the bug Peeter found a few weeks ago, and my proposed solution that advises we perhaps switch our use of pthreads in Fl_Cocoa (for handling add_fd()) over to using NSThread. I think I did all the investigative work and found the solution, but not sure I'm the right person to code it. I wrote the original carbon threading code in question (the add_fd() threading stuff), and I think that's been fairly bug free, but apparently during the recent port to cocoa pthreads apparently doesn't play nice with the cocoa libs. By switching from using pthreads to NSThread in just the Fl_Cocoa code might solve the memory leak. Please see the STR for details: http://fltk.org/str.php?L2848 This should maybe be a HIGH instead of a MED, as apparently a lot of memory is leaking.. On the basis of no useful knowledge at all, I was under the impression that it would play fine with pthreads, if you made at least one (possibly dummy) NSThread first, just to wake up the thread safe mechanisms... So it may NOT be necessary to change the code much, just add in a dummy NSThread somewhere that we then immediately expire... But most likely I'm talking nonsense... ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Release 1.3.1 ?
On 29 May 2012, at 21:46, Matthias Melcher wrote: Hi guys, I think that releasing 1.3.1 would now be as good as any other time. Some very important issues were fixed and we should have done this a long time ago. Can I please get a count on who is for or against releasing the current FLTK 1.3 SVN as 1.3.1? Thanks! Works OK for me; +1 ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
