Re: [fltk.development] RFC: decision on license to use forfltk/examplessource code
Albrecht, On 2013-02-28, at 8:24 PM, Albrecht Schlosser wrote: > On 28.02.2013 04:47, Greg Ercolano wrote: >> Would like to hear from Albrecht, Matt, and Mike on this as well. > > Sorry, it's too late over here to reply now (with real content), but > I have it on my to-do-list. Need some time to look at the different > licenses, but OTOH, if Mike and Matt propose MIT (or say it's okay), > then I'm probably okay with this, too. IANAL ;-) > > IIRC I haven't seen a real "freeware" (public domain) proposal. > Wouldn't this be appropriate for the example code? Unfortunately, "public domain" isn't a universally-recognized status for copyrightable works. What you ultimately have to do is say "I hold the copyright on this code and I say you can do whatever you want with it." _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK version number update and release process [WAS: Re: [fltk.bugs] [MOD] STR #2932: 1.3.2 tarball not packaged properly]
On 2013-02-28, at 8:15 PM, Albrecht Schlosser wrote: > On 01.03.2013 01:04, Greg Ercolano wrote: >> On 02/28/13 15:24, Albrecht Schlosser wrote: >>> We'll need to take care of this for the next release. Unfortunately there >>> are several places with version numbers that need to be adjusted manually >>> for each release. :-( >> >> We probably should have a checklist as part of the CMP, or similar >> document to describe the release process, so that we don't miss anything >> obvious. > > I've started developing such a checklist. It's only a raw list for now, > but I've managed to describe a few search commands (grep... | cut... | > sort...) and so on to FIND the version numbers in the source files. > > (And, BTW, I still found a few old version numbers, see svn r FWIW, I added checks to the CUPS makesrcdist script that verifies that all of the source files have the correct version number. Feel free to copy: http://svn.easysw.com/public/cups/trunk/tools/makesrcdist > ... > Oh, and another question: WHEN do we upgrade the version number(s)? > > (a) immediately after one release, for the next release, or > (b) short before the next release ? I generally advocate bumping the version number as soon as a change is committed after a release. But whatever works process-wise, it is important for the SVN repository to have a different version number than the released version as soon as it differs. _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: decision on license to use forfltk/examples source code
I'm OK with MIT. On 2013-02-27, at 10:47 PM, Greg Ercolano wrote: > Would like to hear from Albrecht, Matt, and Mike on this as well. > > Greg: Zlib or MIT with exceptions to relax use and not require citations > Ian: Zlib, add exception to relax code use > > Recommendations of other licenses are fine too. > > I think all we really want people NOT to do is attempt to declare ownership > to themselves, then try to leverage others with it, as well as including a > "limited warranty" and "liability waiver". > > As an example of usurping ownership, say someone at Company A uses some > of our example code, then he leaves the company. Years later, Company A > thinks our examples were taken from their code (due to the similarity) > and attempt to take us, or others to task about it. > > I did some research trying to figure out what license books use for their > examples, but couldn't find much. > > O'Reilly has the following general policy for reuse of code examples from his > books, but it's not really "a license", it's just a FAQ response from Tim > O'Reilly: > http://oreilly.com/pub/a/oreilly/ask_tim/2001/codepolicy.html > > In general, all books have copyright notices at the front, but don't generally > discuss the use of example code.. the implication is to of course use them, > and people usually reference the source if they want when appropriate, but > are certainly not forced. > > It'd be nice if our example code didn't need paragraphs of license prologue, > and could just reference a file (eg. README-License.txt) that comes with > the examples. > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ 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
There is also the issue of how to safely execute programs from the library; it is incredibly difficult to safely deal with file descriptors and signals/handlers from a library without some coordination with the application... On 2013-02-17, at 4:35 PM, Ian MacArthur wrote: > > 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 _ Michael Sweet ___ 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
Manolo, On 2012-12-05, at 10:02 AM, Manolo Gouy wrote: > ... > I tend to believe the shell wrapper created for each > application by fltk-config --post is not useful. Opinions? It allows command-line users to more easily access the program; for example, I might use it for HTMLDOC which offers both GUI and command-line functionality. ____ Michael Sweet, Easy Software Products ___ 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.1for unbundled applications
On 2012-11-26, at 5:38 AM, Matthias Melcher wrote: >>> ... >>> "Software releases shall be generated for each successfully completed >>> software trouble report." >>> >>> although this is not like the current (past) practice. >> >> >> Well, I suppose we *could* sort of claim that the weeklies fulfil that >> role... >> >> >>> Shall we change the CMP? >> >> >> Maybe; though evidence suggests that no one would notice the changes anyway! >> ;-) > > LOL, yes. > > In the past, we would generate new patch releases whenever *all* STRs were > fixed. Hence the enormous time between patches. I would suggest to release a > new patch whenever a critical STR (preferable several critical STRs within a > short period, say a week) has been fixed. The FLTK CMP came from the CUPS CMP, which has "grown" over the years from its roots. One of the things we did was drop the "one release per change" and "no bug unfixed" verbiage. Instead, we adopted simpler goals - a new patch release every 6-8 weeks, no release containing a P4 or P5 bug unless absolutely necessary - and that allows us to keep updates coming out as needed without (too long) delays or too much overhead for keeping new releases coming out. Seems like this kind of a yardstick could be used for FLTK as well... _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Release 1.3.1 ?
Matt, The fltk-announce group/list is "read-only"; at some point (very soon, I hope) I will have a chance to get that new VPS setup, at which point I will reconfigure fltk-announce to either accept posts from specific email addresses or setup an "announce" form on the fltk.org web admin pages. In the meantime I posted a copy of your web site announcement to the fltk-announce list... On 2012-11-07, at 3:58 AM, Matthias Melcher wrote: > > On 07.11.2012, at 06:02, Greg Ercolano wrote: > >> Looks like Matt released 1.3.1 -- thank you! >> >> Don't forget to post on fltk.announce as well. > > I tried. Either I forgot how, or I don't have access anymore. Tsts. > > ___ > 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] Release 1.3.1 ?
Done! On 2012-11-07, at 12:02 AM, Greg Ercolano wrote: > Looks like Matt released 1.3.1 -- thank you! > > Don't forget to post on fltk.announce as well.. > ___ > 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] CRIT STR #2881
Use malloc()? On 2012-11-05, at 8:22 AM, Manolo Gouy 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 > ... > 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? > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev ____ Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Critical issue moderated
New bugs get forwarded to the fltk-bugs list, which can hold the notification for a number of reasons - not subscribed, message above a preset limit, etc. I process moderated messages once a day. Sent from my iPhone On 2012-11-03, at 9:56 AM, Sanel Zukan wrote: > Hi, > > I just filled one critical issue (http://www.fltk.org/str.php?U2881) and > I received moderation pending mail for fltk-bugs. Is this related only > for critical bugs or only developers posts/replies get there? > > Regards, > Sanel > ___ > 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 #2860: Multi-head full screensupport
I have a system I can test with... On Aug 27, 2012, at 1:19 PM, Greg Ercolano wrote: > On 08/27/12 07:48, Pierre Ossman wrote: >> Link: http://www.fltk.org/str.php?L2860 >> Version: 1.3-feature >> >> Updated patch. Finally got a OS X test machine, and of course found a bug. > > Sounds good -- any devs with multiple monitors to verify? > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [fltk.commit] [Library] r9646 - in branches/branch-3.0: include/fltk src/fltk3
I'd recommend against providing strcasecmp and strncasecmp functions in the
library - too much chance for name collisions from other projects, instead
define fltk-prefixed versions or go back to defining strcasecmp to stricmp, etc.
Sent from my iPad
On Jul 27, 2012, at 5:22 AM, fltk-dev@easysw.com wrote:
> Author: matt
> Date: 2012-07-27 05:22:58 -0700 (Fri, 27 Jul 2012)
> New Revision: 9646
> Log:
> Fixed VisualC build issue which I recently introduced
>
> Modified:
> branches/branch-3.0/include/fltk/flstring.h
> branches/branch-3.0/src/fltk3/flstring.c
> branches/branch-3.0/src/fltk3/flstring.h
>
> Modified: branches/branch-3.0/include/fltk/flstring.h
> ===
> --- branches/branch-3.0/include/fltk/flstring.h2012-07-26 00:40:37 UTC
> (rev 9645)
> +++ branches/branch-3.0/include/fltk/flstring.h2012-07-27 12:22:58 UTC
> (rev 9646)
> @@ -50,8 +50,8 @@
> /* Windows has equivalent functions, but being Microsoft they added
>gratuitoius changes to the names to stop code from being portable: */
> #if (defined(_WIN32) && !defined(__CYGWIN__)) || defined(__EMX__)
> -inline int strcasecmp(const char *s, const char *t) { return _stricmp(s, t);
> }
> -inline int strncasecmp(const char *s, const char *t, int n) { return
> _strnicmp(s, t, n); }
> +extern int strcasecmp(const char *s, const char *t);
> +extern int strncasecmp(const char *s, const char *t, int n);
> # define vsnprintf_vsnprintf
> # define snprintf_snprintf
> #endif
>
> Modified: branches/branch-3.0/src/fltk3/flstring.c
> ===
> --- branches/branch-3.0/src/fltk3/flstring.c2012-07-26 00:40:37 UTC (rev
> 9645)
> +++ branches/branch-3.0/src/fltk3/flstring.c2012-07-27 12:22:58 UTC (rev
> 9646)
> @@ -27,6 +27,16 @@
>
> #include "flstring.h"
>
> +#if defined(WIN32) && !defined(__CYGWIN__)
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +int strcasecmp(const char *s, const char *t) { return _stricmp(s, t); }
> +int strncasecmp(const char *s, const char *t, int n) { return _strnicmp(s,
> t, n); }
> +#ifdef __cplusplus
> +}
> +#endif
> +#endif
>
> /*
> * 'fl_strlcat()' - Safely concatenate two strings.
>
> Modified: branches/branch-3.0/src/fltk3/flstring.h
> ===
> --- branches/branch-3.0/src/fltk3/flstring.h2012-07-26 00:40:37 UTC (rev
> 9645)
> +++ branches/branch-3.0/src/fltk3/flstring.h2012-07-27 12:22:58 UTC (rev
> 9646)
> @@ -49,8 +49,14 @@
> # endif /* index */
>
> # if defined(WIN32) && !defined(__CYGWIN__)
> -#define strcasecmp(s,t)_stricmp((s), (t))
> -#define strncasecmp(s,t,n)_strnicmp((s), (t), (n))
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +extern int strcasecmp(const char *s, const char *t);
> +extern int strncasecmp(const char *s, const char *t, int n);
> +#ifdef __cplusplus
> +}
> +#endif
> /* Visual C++ 2005 incorrectly displays a warning about the use of POSIX APIs
> * on Windows, which is supposed to be POSIX compliant... Some of these
> * functions are also defined in ISO C99...
>
> ___
> fltk-commit mailing list
> fltk-com...@easysw.com
> http://lists.easysw.com/mailman/listinfo/fltk-commit
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] UnregisterClass
Note that dynamically loading/unloading code like this generally does not work and is not portable, particularly where C++ is involved... On Jun 24, 2012, at 12:35 PM, Mikhail Tchernychev wrote: > Hello Everyone, > > First of all many thanks for making this nice toolkit available to us! > > I have a suggestion about improvement I see could be useful. The > scenario is the following: > > 1. From another win32 application, DLL is loaded using LoadLibrary() > 2. Library starts new thread and call FLTK program from this thread. > It does work fine. > 3. After job is done, library is unloaded from the program space > using FreeLibrary(). > > The procedure (1-3) also works under Linux using dlsym(). > In fact in both cases I use pthreads :)) > > The problem is that under Win32 FLTK window class is not unregistered > therefore (1-3) works only once; if DLL is loaded again, FLTK tries to > register class again and CreateWindowEx() function from Fl_win32.cxx fails. > > I found a work around by obtaining FLTK class name in UTF16 as the following: > > > wchar_t class_namew[100]; > > > char class_name[100]; > strcpy(class_name, "FLTK"); > > // convert UTF-8 class_name to wchar_t for RegisterClassExW and > CreateWindowExW > > fl_utf8toUtf16(class_name,strlen(class_name), // in >(unsigned short*)class_namew, // out >sizeof(class_namew)/sizeof(wchar_t)); > > > Now in DllMain wheh DLL is unloaded I call > > case DLL_PROCESS_DETACH: >HINSTANCE hInst = GetModuleHandle(NULL); >BOOL ret = UnregisterClass(class_namew, hInst); > > After these fixes DLL can be loaded and FLTK code used multiple > times. > > I would suggest to add something to Fl class to allow user to > unregister class under Win32 on demand, or have access to class ATOM This > would help if class name in future versions would change. > > Just a suggestion, > > Best Regards, > > Mikhail > > > > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 fltk3connect issues?
Ian, The code is provided under the LGPL2 (that's what the LICENSE.txt file ends up saying, since CUPS has both library and program bits covered under GPL2 and LGPL2) with some exceptions for Apple OS's and OpenSSL. On Jun 19, 2012, at 2:16 AM, "MacArthur, Ian (SELEX GALILEO, UK)" wrote: >>> ... >>> Since we already provide an API that lists a directory contents, should >> we provide other information about directory entries as well? I added this >> to FLTK2 many years ago because the FileChooser need a sort-by-date >> function. >> >> >> CUPS has code for this already and abstracts away from Windows/POSIX, >> providing filename and stat info in one place. >> >> http://svn.easysw.com/public/cups/trunk/cups/dir.c >> http://svn.easysw.com/public/cups/trunk/cups/dir.h > > > Mike, > > Those files have Apple copyright statements on them... are we allowed to > "look" at them for our purposes? > > Or... if we dig back far enough, can we find the same code with an "easier" > copyright (is that even a valid thing to do?) > > Or...? > > > > SELEX Galileo Ltd > Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 > 3EL > A company registered in England & Wales. Company no. 02426132 > > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******** > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 fltk3connect issues?
Matthias, On Jun 18, 2012, at 7:25 AM, Matthias Melcher wrote: > ... > Since we already provide an API that lists a directory contents, should we > provide other information about directory entries as well? I added this to > FLTK2 many years ago because the FileChooser need a sort-by-date function. CUPS has code for this already and abstracts away from Windows/POSIX, providing filename and stat info in one place. http://svn.easysw.com/public/cups/trunk/cups/dir.c http://svn.easysw.com/public/cups/trunk/cups/dir.h ________ Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 fltk3connect issues?
OS X tracks nanosecond modification times in the file system, but there are defines in the system headers to expose the standard st_mtime, etc. members. When building 64-bit time_t is 64-bit, not 32-bit... Sent from my iPhone On Jun 17, 2012, at 1:59 PM, Ian MacArthur wrote: > > 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 ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [OT] Bret Victor - Inventing on Principle -- Incredible user interface/programming integration
Definitely a great presentation, and not just because of the cool UI he demoed. On Jun 3, 2012, at 7:12 PM, Greg Ercolano wrote: > This has been floating around on other lists.. > if you haven't seen it, don't miss it: > > http://www.youtube.com/watch?v=PUv66718DII > > ~2:40 -- Visual programming >~10:50 -- Game visual programming >~16:50 -- Visual program simulation >~23:35 -- Electronics simulation >~29:20 -- Animation UI > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ 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..)
"Dispatch", as in "Grand Central Dispatch", Apple's answer to Life, the
Universe, and Everything.
Basically GCD is a threading mechanism combined with C/C++/ObjC/ObjC++ language
extensions for "blocks" (lamdas) that allow you to do fine-grain thread
scheduling inline, like this (going from memory so I'm sure the following code
won't compile as-is):
dispatch_async(dispatch_global_queue(), ^{
/* code that runs in a thread */
});
Blocks can also be used in place of callback functions in most places now as
well.
On Jun 3, 2012, at 8:59 AM, Greg Ercolano wrote:
> On 06/02/12 17:50, Michael Sweet wrote:
>> NSThread uses dispatch threads on newer versions of OS X - 10.6 and higher
>> IIRC...
>
> I'll bet that means something, but I don't know what ;)
>
> I try to remain as blissfully ignorant of carbon/cocoa
> as possible, but had to dive deep on two occasions;
> once to do the add_fd()/OSX code, the other for the
> NativeFileChooser stuff.
>
> Each time it was like going into a dark cave to slay a dragon,
> finding several dragons, and coming out burned and "slimed",
> but somehow victorious. After each battle, I took a long shower
> and tried to forget what I saw..
>
>
>
>
> _______
> fltk-dev mailing list
> fltk-dev@easysw.com
> http://lists.easysw.com/mailman/listinfo/fltk-dev
_
Michael Sweet
___
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..)
NSThread uses dispatch threads on newer versions of OS X - 10.6 and higher IIRC... Sent from my iPad On Jun 2, 2012, at 6:58 PM, Ian MacArthur wrote: > > 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 ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Website suggestion: FLTK Library/Fluid GUIBuilder/Forum/Links...
On May 15, 2012, at 2:06 PM, Greg Ercolano wrote: > ... > BTW feel free to put the videos on the FLTK site if you want, > if OK w/Mike re: disk use and bandwidth use. > My three videos are around 7MB each. They can probably > be checked in with svn using a proper mimetype. I'm in the process of moving the site over to Torsten's server, so he would be the one to ask... _____ Michael Sweet ___ 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
I thought default_callback set some global state, too? IIRC fl_ask() and friends used it as part of the old forms compatibility layer??? On May 2, 2012, at 8:43 AM, Bill Spitzak wrote: > On 05/02/2012 02:45 AM, chris wrote: >> 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 >> >> >> Attached file "Fl_Widget_do_callback_check_for_null_callback_patch.txt"... >> >> >> Link: http://www.fltk.org/str.php?L2835 >> Version: 1.3-feature > > Note that this probably means default_callback can be zero. > > The only reason for default_callback was to avoid this if statement. > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Old FLTK2/Cairo poll Was: Re: Doublebuffering issues and generalthoughtsfroma frustrated long time FLTK user.
Autoconf isn't needed on enduser systems as the configure script is bundled
with the tar balls.
Make is native on most unix systems out of the box and comes with every
compiler I've ever used.
Sent from my iPhone
On Apr 7, 2012, at 6:07 AM, Albrecht Schlosser wrote:
> On 06.04.2012 04:49, Greg Ercolano wrote:
>> On 04/05/12 19:41, Greg Ercolano wrote:
>>> On 04/05/12 16:26, Fabien Costantini wrote:
Today, I would vote for removing the visual studio 2xxx ide projects and
stick with cmake.
>>>
>>>I'd like to use cmake, but it's distressing that it isn't native
>>>to any of the OS's we support. ('Command not found' on OSX/Lion,
>>>Linux/Centos5, and Windows)
>
> autoconf, configure, make etc. must be installed as well, they're not
> "native" on any OS.
>
>>>If cmake were something we could include in the FLTK package,
>>>I'd be for it. Is it a pretty tight tool?
>
> I don't know. However, I believe that we should rely on a user
> installing it, if it can be downloaded and installed for a normal
> Windows (MS IDE) user.
>
>>>I know that I can get FLTK to build on Windows with gmake
>>>by just including a gmake.exe and some Makefiles specific to MS.
>
> Could you please tell us what "gmake.exe" is? Is it GNU make, or is
> it something else? Sorry, I saw your suggestion some days ago, but
> didn't find the time to reply then..
>
> Albrecht
> ___
> 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] There is a spam attack on FLTK bugs ?
I'll look into it; I'm no longer subscribed to the bugs group so I haven't noticed, but moderated spam is its normal steady 50 or so a day on the list... Sent from my iPhone On Mar 26, 2012, at 11:37 AM, "Domingo Alvarez Duarte" wrote: > Today I noticed several posts to fltk bugs that seems to be spam attack, > no one else noted it ? > ___ > 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] Problems with Fl_Sys_Menu_Bar and Fl_Overlay_Window?
After some more testing it turns out this was just pilot error... I forgot to change the definition of the menubar widget... Anyways, current TOT now works as designed. On Feb 6, 2012, at 8:47 AM, Michael Sweet wrote: > All, > > Just a head's up - on TOT 1.3 I am not able to get Fl_Sys_Menu_bar to work > with Fl_Overlay_Window. I'll be filing a bug later today when I get a > chance... > > Found while adding some minor features to fldiff - check out: > > http://svn.easysw.com/public/fltk/applications/trunk/fldiff > > to play with it... > > _________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #1114: fltk.spec relfect cvs snapshot
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L1114 Version: 2.0-feature Link: http://www.fltk.org/str.php?L1114 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 #1017: Add support for i18n to FLUID
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L1017 Version: 2.0-feature Link: http://www.fltk.org/str.php?L1017 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 #2: Unclamped ROLLER with delta()
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L2 Version: 2.0-feature Link: http://www.fltk.org/str.php?L2 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 #214: function objects for callbacks.
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR Pending] Link: http://www.fltk.org/str.php?L214 Version: 1.4-feature Link: http://www.fltk.org/str.php?L214 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 #45: Help_View does not handle tables with border properly (and more)
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L45 Version: 1.4-feature Link: http://www.fltk.org/str.php?L45 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Problems with Fl_Sys_Menu_Bar andFl_Overlay_Window?
On Feb 6, 2012, at 9:13 AM, Albrecht Schlosser wrote: > On 06.02.2012 17:51, Michael Sweet wrote: > >> Found while adding some minor features to fldiff - check out: >> >> http://svn.easysw.com/public/fltk/applications/trunk/fldiff >> >> to play with it... > > Nice new features, thanks for updating fldiff. > > Found two small issues though: > > (1) after toggling line numbers the display is not updated, unless > you press a key or click somewhere inside the display. Yeah, I just started adding them; need to flag the view for redraw... > (2) after toggling whitespace-diff the original method by changing > the preferences did a re-diff automatically - using the new menu > needs an additional CTRL-R. Yeah, I think I'll update that (and also have it remember the scroll position on reload - annoying that it puts you back at the top every time...) > Side note (OT): did you take a look at STR #2778 ? > http://www.fltk.org/applications/str.php?L2778 No, I hadn't noticed but will take a look now... _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] Problems with Fl_Sys_Menu_Bar and Fl_Overlay_Window?
All, Just a head's up - on TOT 1.3 I am not able to get Fl_Sys_Menu_bar to work with Fl_Overlay_Window. I'll be filing a bug later today when I get a chance... Found while adding some minor features to fldiff - check out: http://svn.easysw.com/public/fltk/applications/trunk/fldiff to play with it... _____ Michael Sweet, Senior Printing System Engineer, PWG Chair ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: website comments for docs (doxygen)
Fwiw, comments are currently cc'd to the owner of the page or the person you are replying to. It would be trivial to send them to a read only list that devs or users could subscribe to, or to add a page (and user data) to view and search current/new comments in the database. Sent from my iPhone On Jan 24, 2012, at 10:39 AM, Greg Ercolano wrote: > On 01/24/12 10:35, Greg Ercolano wrote: >>Doc comments are kinda nice, cause it's contextual. >>For instance, being a dev on Fl_Table, it's easy for >>me to keep an eye on Fl_Table related comments, b/c I often >>refer to the docs on the website. > >BTW, not sure if it's appropriate, but it might be fun if >doc comments were cc'ed to an fltk.xxx newsgroup, so that >one can see the whole stream of comments for the docs, and >replies there would be cc'ed to the comments section. > >Just a thought. > ___ > 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] Are spammers are using the front page ofFLTK?
On Jan 23, 2012, at 10:40 AM, Greg Ercolano wrote: > On 01/23/12 10:12, Greg Ercolano wrote: >>> On 01/21/12 19:05, E. Torres wrote: >>>> Are spammers are using the front page of FLTK? > > Oh, and I should add, I think the reason the 'STALE' > links have bubbled to the 'top 10' on the FLTK site > is because I marked a bunch of them as 'stale' a few > weeks ago, and this modification apparently "woke them up" > to appear on the main page. > > Mike: Is there a good way to mark old submissions stale > without them appearing on the main site? I would just delete them; you should have permission to do so as a developer (but if not I can fix that... :) _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Are spammers are using the front page of FLTK?
Are you sure you don't have a proxy or DNS redirector provided by your ISP? On Jan 22, 2012, at 9:26 PM, E. Torres wrote: > I did click to all of them. Most of them take you to webpages not related to > the software they should be pointing to. > > On Sat, Jan 21, 2012 at 11:20 PM, Greg Ercolano wrote: > On 01/21/12 19:05, E. Torres wrote: > > Are spammers are using the front page of FLTK? > > > > Most of the Top 10 Links take you strange pages. > >I didn't see anything unusual -- which ones in particular >did you click on that seem unusual? > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev > > > > -- > --- > Cheers, > > Gnusci > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Are spammers are using the front page of FLTK?
I think the issue is that they are bad (stale) links. (we *do* regularly get a variety of, um, questionable submissions, but I think I am able to purge them and the user accounts that are creating them...) On Jan 21, 2012, at 7:04 PM, E. Torres wrote: > Are spammers are using the front page of FLTK? > > Most of the Top 10 Links take you strange pages. > > -- > --- > Cheers, > > Gnusci > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Server for FLTK.org is ready, not installed yet, but available
Torsten, Great, thanks for setting this up! Sent from my iPhone On Jan 15, 2012, at 4:35 PM, Torsten Giebl wrote: > Hello ! > > > Great News. Today i recieved an email from Filemedia.de with > infos about the Server, IP Adress, VNC Password, ... > > In the next days i will set up the basic system, then get in contact > with Michael Sweet about the needed data from the actual FLTK.org server. > > After all is done you can test the new Server the whole february, > then you can say if you are happy with it or not. > > If people are not happy about it, we still have the whole march to > find a different place. > > PS: Sorry if you recieved another email with the same content. > > > CU > > ___ > 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] Check it out
This person has been removed from the list and banned. On Jan 10, 2012, at 9:09 AM, Greg Ercolano wrote: > On 01/10/12 06:50, Yujun Guo wrote: >> > > Right.. > > Don't open. > > Suspecting it's either a virus or spam, I ran it through strings(1); > looks like a payload of PDF javascript that's probably bad for your > health: > >
Re: [fltk.development] RFC: New home needed for fltk.org...
Torsten, On Jan 2, 2012, at 10:28 AM, Torsten Giebl wrote: > ... > Good news. I got positive responses about sponsoring hosting from > Filemedia.de. > What they want, would be a text message on the site: "Sponsored Hosting by > Filemedia.de" or something similar. > and their (static) logo on the site. > > Would that be okay for the FLTK people ? OK with me; the example banner logo looks a little big to me, but maybe we can work with them on the size/position (maybe under the search field?) _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: New home needed for fltk.org...
On Jan 8, 2012, at 9:42 AM, Manuel Barros Reyes wrote: > On Wed, Dec 28, 2011 at 12:38 PM, Michael Sweet wrote: >> Disk space: ~2.4GB >> Monthly bandwidth: 41.5GB (from previous message) >> The current web site uses Apache, PHP, MySQL, Mailman, Newsd, Postfix, and >> Spamassassin on a RHEL5-based Linux server. > > Hi, just my 2 cents, maybe I'm missing something that can not be > solved with this solution but I have to tell you I am a happy customer > of Linode (http://www.linode.com) and they offer virtual linux servers > from 25USD month with 20Gb of disk space and 200GB of monthly > transfer, that would reduce the costs 10x (paying monthly) not to > mention we could also move the repositories to Github which is free. Thanks for the pointer; I will definitely look into this provider (and maybe look for others with similar offerings) - the current pricing appears to be a little less ($19.95 for the base config) but we'll need more RAM - the current server has only 2GB RAM with another 1GB of swap and generally is using ~250MB of swap depending on the time and load. (20% of memory is used for SpamAssassin and Mailman, another 20-25% for Apache...) _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: New home needed for fltk.org...
Torsten, Thanks for the offer; I've already completed most of the move for Mini-XML and am in the process of moving the others to github. Still need to redirect minixml.org to the github site, but look at: http://michaelrsweet.github.com/ http://michaelrsweet.github.com/Mini-XML On Jan 7, 2012, at 3:45 PM, Torsten Giebl wrote: > Hello ! > > > Please DO NOT move anything away from FLTK.org, (HTMLDOC, EPM, ...) > I am working on a hosting for FLTK.org and we may also have a nice > solution for the other projects. > > I just need some more time. > > > CU > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] GIT for FLTK?
On Dec 28, 2011, at 10:10 AM, Mariwan wrote: > HI, > As I read and heard, how difficult developer's life could be when you use SVN > or CVS "you may heard that also from Linus Torsvald". I have never used SVN > and I have no good idea about it but I am using "newbies" git and I think it > works good. > My question is : Don't you (FLTK developers) think that using Git could solve > many problems for you as FLTK, FLTK manager and developers could have? AFAIK, we have no problems with SVN per-se. GIT is just another version control system with a particular feature set, and Linus obviously has a vested interest in promoting it, but FLTK doesn't require that feature set. Moreover, if individual FLTK developers want to do remote/offline/distributed development with GIT they can already do so against the current SVN repository using the SVN support included with GIT... _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: New home needed for fltk.org...
On Dec 28, 2011, at 8:12 AM, Torsten Giebl wrote: > ... > Would you or Carl Thompson still be willing to pay the yearly cost > for the fltk.org domain and the others ? epmhome.org, htmldoc.org, ... ? I'm planning on keeping my domains going, and moving my personal projects to github. CUPS is moving to an Apple server. The only outstanding issue is where FLTK will live... I've sent email to Carl, but one of us will take care of the domain renewal for fltk.org. _____ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: New home needed for fltk.org...
On Dec 28, 2011, at 5:24 AM, Albrecht Schlosser wrote: > On 28.12.2011 00:54, Michael Sweet wrote: > >> I am in the process of closing down Easy Software Products. As many of >> you know, fltk.org <http://fltk.org> is hosted on the easysw.com >> <http://easysw.com> server. Our current colocation contract ends in >> April 2012, and while I might be able to extend things on a >> month-to-month basis I can't do so indefinitely out of my own pocket >> (costs for 2011 were $250/month or $2500/year). > > Thanks for hosting fltk.org for all these years! I hope that we can > find a good new home. I was glad to host for all these years. > ... > HTML sites on github are maybe only static pages. Wouldn't it be easier > to use another hoster supporting php and mysql? Is there such a hoster > available for free (for open source projects)? Github *does* provide GIT-based sites with wikis, so while it wouldn't quite be what we have with the custom PHP web site we currently use, I think it would be enough to cover at least the usual articles and how-tos we post (no "links"/"bazaar" page, though...) Bug tracking is on-par with the system I setup for FLTK, but I admit it will take some getting used to (old habits and what-not...) > BTW: fltk.org's registration seems to expire soon: I'll contact Carl Thompson who still owns/manages the domain... _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: New home needed for fltk.org...
On Dec 28, 2011, at 1:09 AM, Torsten Giebl wrote: > ... > What about disc space of fltk.org and so on. > Some stats would be usefull, maybe there are people > here working for an ISP or Hosting Provider. OK, some stats for those interested: Disk space: ~2.4GB 700MB for message archive 655MB for SVN 332MB for web site and files attached to bugs 650MB for release/download files 14MB for MySQL database Monthly bandwidth: 41.5GB (from previous message) The current web site uses Apache, PHP, MySQL, Mailman, Newsd, Postfix, and Spamassassin on a RHEL5-based Linux server. _________ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: New home needed for fltk.org...
On Dec 28, 2011, at 1:03 AM, Torsten Giebl wrote: > ... > It would be usefull to know > how much traffic was used by fltk.org per month ? Over the last year: Direct downloads: 27GB/month Web site traffic: 12GB/month (approximately 1M hits or 75k visits/month) Subversion: 2.5GB/month - --- Total Monthly: 41.5GB/month FYI, this makes FLTK my third-most bandwidth intensive site (2nd for open source sites): CUPS: 91GB/month EASYSW: 49GB/month FLTK: 41.5GB/month HTMLDOC: 19.5GB/month Mini-XML: 1GB/month _____ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
[fltk.development] RFC: New home needed for fltk.org...
All, I am in the process of closing down Easy Software Products. As many of you know, fltk.org is hosted on the easysw.com server. Our current colocation contract ends in April 2012, and while I might be able to extend things on a month-to-month basis I can't do so indefinitely out of my own pocket (costs for 2011 were $250/month or $2500/year). I am in the same boat for the other open source projects I host (EPM, fldiff, flphoto, HTMLDOC, Mini-XML, Newsd, RasterView), and I am 99% sure that I will be moving those to Github and migrating everything over to GIT... I also looked at GoogleCode, but you can't host your own domain with them (or at least that I've seen). Aside from the web site and repositories, we will also need mailing lists; Google and others offer free "groups" complete with searchable archives. Thoughts? _____ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] A second flag for Fl_Widget::changed ?
On Dec 13, 2011, at 1:43 AM, Domingo Alvarez Duarte wrote: > Transparency ! Been done by the fltk kernel means no effot must be done by > end users and the proposed modifications are minimal. Granted putting it in FLTK proper would mean apps won't need to do the "heavy lifting" themselves, but FLTK has been around for almost 14 years and I don't remember seeing a lot of complaints about the current system (and the ones we did get were that changed() previously only worked if you didn't use a callback - the original implementation did exactly what you propose for changed2...) Perhaps this could be a new poll to judge whether such a feature is wanted? My concern is that adding a "changed2" bit for all widgets will incur an additional processing overhead to applications that need to track and clear such things; if the changes are tracked by the application the change information can be localized so that a simple memset (or even a change counter) is sufficient to reset the changed state of widgets rather than traversing the widget hierarchy to clear all of the set bits. > On Mon, 12 Dec 2011 20:48:47 +0100, Michael Sweet wrote: > >> Is there a reason why user_data() (or some other application-specific >> data) can't be used for this? > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] A second flag for Fl_Widget::changed ?
Is there a reason why user_data() (or some other application-specific data)
can't be used for this?
On Dec 12, 2011, at 11:44 AM, Domingo Alvarez Duarte wrote:
> I'm proposing to add a second changed flag to Fl_Widget, this second one
> will not be reseted after a callback like the actual one is.
>
> I'm working with windows with several Fl_Inputs and some of then uses
> callback to allow calculations when the value changes, but at the end I
> need to know which ones have changed over the session and because the
> CHANGED flag is cleared after the callbacks this information is lost.
>
> With a second flag that is not reset by the callback I can easily get the
> changes over the section.
>
> I think that this can be util for more people and for FLTK as well, so I
> propose to add to the official distribution, this change is transparent
> for applications that do not use it explicitly, so all code made till now
> should work as before.
>
> CHANGED2 = 1<<22, ///< the widget value changed and is not reseted
> by the callback call
>
> unsigned int changed() const {return flags_&CHANGED;}
> unsigned int changed2() const {return flags_&CHANGED2;}
>
> /** Marks the value of the widget as changed.
> \see changed(), clear_changed()
>*/
> void set_changed() {flags_ |= (CHANGED|CHANGED2);}
> void set_changed2() {flags_ |= CHANGED2;}
>
> /** Marks the value of the widget as unchanged.
> \see changed(), set_changed()
>*/
> void clear_changed() {flags_ &= ~CHANGED;}
> void clear_changed2() {flags_ &= ~CHANGED2;}
> void clear_changed_all() {flags_ &= ~(CHANGED|CHANGED2);}
> _______
> fltk-dev mailing list
> fltk-dev@easysw.com
> http://lists.easysw.com/mailman/listinfo/fltk-dev
_
Michael Sweet
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to silence new compilerwarnings(gcc4.6.1)
Bill, Neither the C standard nor POSIX require anything other than values from -1 (EOF) to 255 to work. Since we are dealing with char strings we are not going to see an EOF except in the case where a character has the value 255 but is interpreted as a signed value (which is allowed). Thus, masking with 255 is both safe and necessary for cross-platform code... On Dec 9, 2011, at 12:02 PM, Bill Spitzak wrote: > Sorry I misinterpreted the 255 as being 127. > > That said, correct isdigit() implementations are supposed to handle the > native compiler char->int conversion of the argument. This masking can > make the -1 EOF match the 255 character and thus is really incorrect. > > On 12/07/2011 09:25 PM, Michael Sweet wrote: >> Bill, >> >> A digit is just 0 to 9, per the definition of isdigit. Masking off the sign >> extension of the char value will just keep the values from 0 to 255 - UTF-8 >> sequences will have bit 7 set which will prevent isdigit from matching. >> >> >> On Dec 7, 2011, at 11:09 PM, Bill Spitzak wrote: >>> On 10/18/2011 11:43 AM, Michael Sweet wrote: >>>> In this case I would not use strtol to skip digits, but a simple while >>>> loop instead: >>>> >>>> while (isdigit(*str& 255)) >>>> str ++; >>>> >>>> (the "& 255" part is necessary to avoid portability issues with UTF-8 >>>> strings) >>> >>> That seems wrong. That will actually turn some parts of UTF-8 characters >>> into digits and thus match. You actually do not want to change the >>> bytes, all the bytes in a multi-byte UTF-8 character will fail the >>> isdigit() test and thus this will stop at that point. >>> >>> ___ >>> fltk-dev mailing list >>> fltk-dev@easysw.com >>> http://lists.easysw.com/mailman/listinfo/fltk-dev >> >> _ >> Michael Sweet >> > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to silence new compiler warnings(gcc4.6.1)
Bill, The results of anything other than values from -1 to 255 are undefined, per POSIX and Standard C. On Dec 7, 2011, at 11:12 PM, Bill Spitzak wrote: > On 10/18/2011 03:36 PM, Michael Sweet wrote: >> C doesn't define whether a "char" is signed or unsigned, so masking makes >> sure that you don't pass in a negative number, and also keeps the value >> within the range supported by the ctype functions (-1 to 255 in most cases - >> -1 because that is the "EOF" character...) > > I think the isdigit() and similar functions are required to work with > the result of char->int conversion, so they should already be doing this > sort of masking. > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to silence new compiler warnings(gcc4.6.1)
Bill, A digit is just 0 to 9, per the definition of isdigit. Masking off the sign extension of the char value will just keep the values from 0 to 255 - UTF-8 sequences will have bit 7 set which will prevent isdigit from matching. On Dec 7, 2011, at 11:09 PM, Bill Spitzak wrote: > On 10/18/2011 11:43 AM, Michael Sweet wrote: >> In this case I would not use strtol to skip digits, but a simple while loop >> instead: >> >> while (isdigit(*str& 255)) >> str ++; >> >> (the "& 255" part is necessary to avoid portability issues with UTF-8 >> strings) > > That seems wrong. That will actually turn some parts of UTF-8 characters > into digits and thus match. You actually do not want to change the > bytes, all the bytes in a multi-byte UTF-8 character will fail the > isdigit() test and thus this will stop at that point. > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Linux 32-bit build on 64-bit OS?
The other thing you can do is use the "--with-archflags" configure option which adds architecture compiler options to the C and C++ compilers and the linker. That's how I do "fat" builds on Mac OS X. On Nov 23, 2011, at 4:07 PM, Ian MacArthur wrote: > > On 23 Nov 2011, at 16:44, Jim Schatzman wrote: > >> Most Linux open-source packages have some method for building 32-bit >> libraries on 64-bit platforms. Typically, setting >> >> export CFLAGS=-m32 >> export CXXFLAGS=-m32 >> >> does the trick, possibly along with making sure that 64-bit libraries go to >> /usr/lib64 or /usr/local/lib64 and 32-bit libraries go to /usr/lib or >> /usr/local/lib. >> >> However, this does not work with fltk 1.1.10 because the build system >> ignores CFLAGS and CXXFLAGS. It does use ARCHFLAGS, but if you set >> ARCHFLAGS=-m32, you eventually get >> >> Linking fluid... >> /usr/bin/ld: skipping incompatible ../lib/libfltk_png.a when searching for >> -lfltk_png >> /usr/bin/ld: cannot find -lfltk_png >> >> I am attempting to build a 32-bit version on Centos 6.0 x8_64. >> >> Any ideas? > > If Greg's method doesn't work for you, then you can try my less graceful > approach, which is to run configure as normal, then hand-edit the makeinclude > file to set the options and paths the way I want them. (All the interesting > stuff is in the makeinclude file, though you might want to take a peek into > config.h as well, just in case there are any data sizes or etc that you are > concerned about!) > > ...Which almost certainly is exactly what you were hoping to avoid in the > first place... > > But Greg's way *ought* to work. > > As an aside, I think this all works a bit better in 1.3.x so you might want > to give that a whirl too - it's almost as stable as 1.1.10, and has a bunch > of useful extra functionality. > > > > > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to silence new compiler warnings(gcc4.6.1)
On Oct 19, 2011, at 1:08 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: > ... > Fair enough, seems like a Good Thing To Do. > (Though possibly redundant in this case? Are there char values that > would sign extend for which isidigit() holds true?) The issue is how isdigit() is implemented, as a macro in many cases that does a table lookup... Out-of-range values can cause a crash... _________ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to silence new compiler warnings(gcc4.6.1)
The usage of strtol in this case always wanted a base-10 number, so to "fix"
this particular case we want:
while (isspace(*str & 255))
str ++;
if (*str == '+' || *str == '-')
str ++;
while (isdigit(*str & 255))
str ++;
However, this has always been documented as "Cnnn" - decimal number, no sign,
whitespace, etc. allowed - and the original "fix" should be sufficient...
(The inline function solution, while effective, is a bit too "hacky" for my
taste...)
On Oct 18, 2011, at 3:53 PM, Albrecht Schlosser wrote:
> On 18.10.2011 20:43, Michael Sweet wrote:
>> In this case I would not use strtol to skip digits, but a simple while loop
>> instead:
>>
>> while (isdigit(*str& 255))
>> str ++;
>>
>> (the "& 255" part is necessary to avoid portability issues with UTF-8
>> strings)
>
> Nice idea, but strtol() would also skip white space (at the beginning of
> the string), an optional '+' or '-' sign, a "0x" prefix, and also
> use hex digits, if base is 16...
>
> Honestly said, I don't know which number formats FLTK supports when
> parsing Fl_Browser items - just to leave the code as-is I added an
> inline function to replace strtol() for this special case. This
> function fools the compiler in that it returns the return value of
> strtol(), but is not "declared with attribute warn_unused_result".
>
> Maybe strtol() was (and is) the wrong function in the first place,
> but I'm not going to check the docs now (is it documented at all?).
>
> This is the patch:
>
> --- snip ---
> Index: Fl_Browser.cxx
> ===
> --- Fl_Browser.cxx (revision 9137)
> +++ Fl_Browser.cxx (working copy)
> @@ -56,6 +56,18 @@
>char txt[1]; // start of allocated array
> };
>
> +/*
> + static inline helper function to skip a (color) number in a string.
> + This is to avoid a (gcc) compiler warning "ignoring return value of
> + long int strtol(const char*, char**, int), declared with attribute
> + warn_unused_result". This could also be achieved by a while loop
> + skipping digits, but strtol() would also skip leading white space,
> + a sign, and maybe a "0x" prefix.
> +*/
> +inline static long int skip_num(const char *nptr, char **endptr, int
> base) {
> + return strtol(nptr,endptr,base);
> +}
> +
> /**
>Returns the very first item in the list.
>Example of use:
> @@ -372,7 +384,6 @@
> if (hh > hmax) hmax = hh;
>} else {
> const int* i = column_widths();
> -long int dummy;
> // do each column separately as they may all set different fonts:
> for (char* str = l->txt; str && *str; str++) {
>Fl_Font font = textfont(); // default font
> @@ -387,7 +398,7 @@
> case 'i': font = (Fl_Font)(font|FL_ITALIC); break;
> case 'f': case 't': font = FL_COURIER; break;
> case 'B':
> - case 'C': dummy = strtol(str, &str, 10); break;// skip a color
> number
> + case 'C': skip_num(str, &str, 10); break;// skip a color number
> case 'F': font = (Fl_Font)strtol(str,&str,10); break;
> case 'S': tsize = strtol(str,&str,10); break;
> case 0: case '@': str--;
> @@ -440,7 +451,6 @@
>int done = 0;
>
>while (*str == format_char_ && str[1] && str[1] != format_char_) {
> -long int dummy;
> str ++;
> switch (*str++) {
> case 'l': case 'L': tsize = 24; break;
> @@ -450,7 +460,7 @@
> case 'i': font = (Fl_Font)(font|FL_ITALIC); break;
> case 'f': case 't': font = FL_COURIER; break;
> case 'B':
> -case 'C': dummy = strtol(str, &str, 10); break;// skip a color number
> +case 'C': skip_num(str, &str, 10); break;// skip a color number
> case 'F': font = (Fl_Font)strtol(str, &str, 10); break;
> case 'S': tsize = strtol(str, &str, 10); break;
> case '.':
> @@ -535,7 +545,6 @@
> //#warning FIXME This maybe needs to be more UTF8 aware now...?
> //#endif /*__GNUC__*/
> while (*str == format_char() && *++str && *str != format_char()) {
> - long int dummy;
>switch (*str++) {
> case 'l': case 'L': tsize = 24; break;
>case 'm': case 'M': tsize = 18; break;
> @@ -549,7 +558,7 @@
> if (!(l->flags & SELECTED)) {
> fl_color((Fl_Color)strtol(str, &str, 10));
> fl_rectf(X, Y, w1, H);
> - } else dummy = strtol(str, &str, 10);
> + } else skip_num(str, &str, 10);
> break;
>case 'C':
> lcol = (Fl_Color)strtol(str, &str, 10);
> --- snip ---
>
> Advantages:
> (1) No dummy variables.
> (2) No runtime overhead, since static and inline.
>
> Any comments?
>
> Albrecht
> ___
> fltk-dev mailing list
> fltk-dev@easysw.com
> http://lists.easysw.com/mailman/listinfo/fltk-dev
_
Michael Sweet
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to silence new compiler warnings (gcc4.6.1)
C doesn't define whether a "char" is signed or unsigned, so masking makes sure that you don't pass in a negative number, and also keeps the value within the range supported by the ctype functions (-1 to 255 in most cases - -1 because that is the "EOF" character...) On Oct 18, 2011, at 3:06 PM, Ian MacArthur wrote: > > On 18 Oct 2011, at 19:43, Michael Sweet wrote: > >> In this case I would not use strtol to skip digits, but a simple while loop >> instead: >> >> while (isdigit(*str & 255)) >> str ++; >> >> (the "& 255" part is necessary to avoid portability issues with UTF-8 >> strings) > > > OK - I'm feeling particularly stupid now: how does masking a byte with 0xFF > help? Is it that isdigit() thinks it gets an int, or... > I'm missing something key here, obviously... > > > > > _______ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to silence new compiler warnings (gcc4.6.1)
In this case I would not use strtol to skip digits, but a simple while loop
instead:
while (isdigit(*str & 255))
str ++;
(the "& 255" part is necessary to avoid portability issues with UTF-8 strings)
On Oct 18, 2011, at 10:59 AM, Albrecht Schlosser wrote:
> On 18.10.2011 18:48, Michael Sweet wrote:
>
>> ... an unused assignment is an unnecessary one.
>
> Yep, that's why I was asking for better ideas.
>
>> The unused return value warnings can be silenced with "(void)" in front of
>> the call, if desired...
>
> Thanks, but unfortunately this doesn't work (same warning). :-(
>
> This is what I tried:
>
> $ make
> Compiling Fl_Browser.cxx...
> Fl_Browser.cxx: In member function ‘virtual int
> Fl_Browser::item_height(void*) const’:
> Fl_Browser.cxx:389: warning: ignoring return value of ‘long int
> strtol(const char*, char**, int)’, declared with attribute
> warn_unused_result
> /usr/bin/ar cr ../lib/libfltk.a ...
> $ gcc --version
> gcc (Ubuntu/Linaro 4.4.4-14ubuntu5) 4.4.5
> ...
> $ svn diff
> Index: Fl_Browser.cxx
> ===
> --- Fl_Browser.cxx (revision 9133)
> +++ Fl_Browser.cxx (working copy)
> @@ -372,7 +372,6 @@
> if (hh > hmax) hmax = hh;
>} else {
> const int* i = column_widths();
> -long int dummy;
> // do each column separately as they may all set different fonts:
> for (char* str = l->txt; str && *str; str++) {
>Fl_Font font = textfont(); // default font
> @@ -387,7 +386,7 @@
> case 'i': font = (Fl_Font)(font|FL_ITALIC); break;
> case 'f': case 't': font = FL_COURIER; break;
> case 'B':
> - case 'C': dummy = strtol(str, &str, 10); break;// skip a color
> number
> + case 'C': (void)strtol(str, &str, 10); break;// skip a color number
> case 'F': font = (Fl_Font)strtol(str,&str,10); break;
> case 'S': tsize = strtol(str,&str,10); break;
> case 0: case '@': str--;
>
>
> Better ideas, anybody?
>
> (Note that this is a step back, trying to fix the previous warning
> to avoid adding the dummy variable).
>
>
>> FYI, the Clang-based static analyzer lives here:
>>
>> http://clang-analyzer.llvm.org/
>>
>> Binaries are provided for Mac OS X, and it is actually pretty easy to build
>> on Linux, too.
>
> Thanks for the hint, I'll take a look at it...
>
> Albrecht
> ___
> fltk-dev mailing list
> fltk-dev@easysw.com
> http://lists.easysw.com/mailman/listinfo/fltk-dev
_
Michael Sweet
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] How to silence new compiler warnings (gcc 4.6.1)
I'd actually recommend running FLTK through Clang's (new) C++ static analyzer, but regardless an unused assignment is an unnecessary one. The unused return value warnings can be silenced with "(void)" in front of the call, if desired... FYI, the Clang-based static analyzer lives here: http://clang-analyzer.llvm.org/ Binaries are provided for Mac OS X, and it is actually pretty easy to build on Linux, too. On Oct 18, 2011, at 4:49 AM, Albrecht Schlosser wrote: > Hi (sigh), > > there are new warnings generated by gcc 4.6.1 (latest MinGW gcc > version, released Sep 15, 2011) about unused, but set variables, > e.g.: > > Compiling Fl_Browser.cxx... > Fl_Browser.cxx: In member function 'virtual int > Fl_Browser::item_height(void*) const': > Fl_Browser.cxx:375:14: warning: variable 'dummy' set but not used > [-Wunused-but-set-variable] > > (2 more warnings in the same file, and a few more elsewhere). > > The problem with these warnings is that we (Matt) *introduced* some > dummy variables (in svn r 7765) to silence other warnings (the > following is from FLTK 1.1 that doesn't have this change (on > Linux, gcc 4.4.4): > > Compiling Fl_Browser.cxx... > Fl_Browser.cxx: In member function ?virtual int > Fl_Browser::item_height(void*) const?: > Fl_Browser.cxx:236: warning: ignoring return value of ?long int > strtol(const char*, char**, int)?, declared with attribute > warn_unused_result > > The same applies to some other similar warnings, e.g. for fwrite(). > > > So, what to do to silence the new warnings? I tried two solutions > that both made the warnings go away, but both appear to be hacks, > and they are confusing (w/o an appropriate comment): > > Possible solutions: add one of these two lines to reference the > dummy variable: > > if (dummy); // silence gcc warning [-Wunused-but-set-variable] > dummy++;// silence gcc warning [-Wunused-but-set-variable] > > Both statements could easily be optimized away by the compiler, > but the 2nd would have a side effect (if not removed, if the > variable were used elsewhere in a later version). So I'd tend > to use the former... > > Are there any better ideas (except disabling the warnings?). > > Should I go ahead and add such silly statements? > > Dev's (and others), what do you think? > > Albrecht > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev _ Michael Sweet ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 build issues on OSX with Makefile
On Aug 22, 2011, at 9:06 AM, Matthias Melcher wrote: > On 22.08.2011, at 17:54, Michael Sweet wrote: > >> On Aug 22, 2011, at 12:25 AM, Matthias Melcher wrote: >>> >>> OK, I made a design decision here that will haunt me for a while. I figured >>> it would be useful to compile jpeg, png, and zlib from scratch always. >> >> Note that this will *not* work for Mac OS X since a lot of the system >> libraries link against the supplied zlib - you'll find a configure test >> explicitly to prevent --enable-local-zlib on Mac OS X that we've had since >> FLTK 1.1.x... > > Oh? Will that give naming conflicts? The command line version currently works > AFAIKT (maybe *because* of the messed up link order), but I have not finished > the Xcode setup yet. My guess is that the current Xcode tools are preferring the system zlib over the local one, or it could be a link order thing (and you are just "lucky" right now), but I know from experience that you can't override the system-supplied zlib and still link against ApplicationServices, Foundation, or CoreFoundation and get a stable (or even functioning) executable, particularly for a shared library setup where parts of libfltk_z.a are part of libfltk.dylib. Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fltk3 build issues on OSX with Makefile
On Aug 22, 2011, at 12:25 AM, Matthias Melcher wrote: > > On 21.08.2011, at 22:20, Ian MacArthur wrote: > >> Matt, >> >> Yes, OK, I know the Xcode project is the preferred build option on OSX, but >> I always just use the Makefiles anyway. > > Oh no. Makefiles are supposed to work too, but there will be changes... . > >> Except that now it chokes on OSX... > > Ooops... > >> Compiling fl_images_core.cxx... >> /usr/bin/ar cr ../lib/libfltk_images.a ... >> make[1]: *** No rule to make target `../lib/libfltk_png.a', needed by `all'. >> Stop. >> make: *** [all] Error 1 > >> Hmm, that's odd - it ought to be using the system image libs, so it has not >> bothered to build the fltk_png at all, hence the choke: > > OK, I made a design decision here that will haunt me for a while. I figured > it would be useful to compile jpeg, png, and zlib from scratch always. Note that this will *not* work for Mac OS X since a lot of the system libraries link against the supplied zlib - you'll find a configure test explicitly to prevent --enable-local-zlib on Mac OS X that we've had since FLTK 1.1.x... Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] RFC: FLTK3 and VisualC 6
+1 for #1...
On Aug 13, 2011, at 1:20 PM, Matthias Melcher wrote:
>
> Well, I managed to install VC6 (from 1998 - that's thirteen years ago -
> whew!) on Windows 7. After a bit of fiddling, I made large parts of FLTK3
> compile. 8.3 filenames. What a blast form the past ;-)
>
> Anyway, what doesn't work is - not surprisingly - compiling the png library.
> I have not tried jpeg, but I am pretty sure it's not going to work either.
>
> What is the general opinion on supporting VisualC 6 ('98) and with it Windows
> 95 and Windows NT?
>
> So the choices are, as I see it:
> 1: drop VC6 and Windows 95/NT support
> 2: add libpng and libjpeg in the last version that builds under VC6, best
> probably as a binary
>
>
> - Matthias
> ___
> fltk-dev mailing list
> fltk-dev@easysw.com
> http://lists.easysw.com/mailman/listinfo/fltk-dev
Michael Sweet, Easy Software Products
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk3 build issue
On Aug 9, 2011, at 6:53 PM, Ben Stott wrote: > ... > The overhead is relatively minimal if the exception isn't thrown - in fact, > if the exception isn't thrown it's more likely than not that the overhead > will be less than checking a return value more once. OTOH, a thrown exception > the overhead balloons out - but I'd argue if something has gone wrong enough > for an exception to be thrown, you can probably justify the overhead. > However, I didn't know that about Macs - I was under the impression that an > exception occurring in a thread, blocking or not, would be held by the same > thread and at worst force a return of the thread if it weren't handled? The issue is that blocks operate outside the normal (POSIX) threading model, and so code that might throw an exception could be running in a completely different thread with a completely different stack (while the code that dispatched the block(s) waits for the work to complete...) Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk3 build issue
On Aug 9, 2011, at 1:39 AM, Ben Stott wrote: > ... > (depending on how things go), if the RAII graphics lock (fltk::GSave, > currently) is unable to save the graphics state through the inability to > acquire or init. resources, an exception could be thrown to inform the user > that anything that happens from that point in the code is going to hell in a > handbasket. How does throwing an exception help here - more than likely the app will not be written to catch the exception (you'd need to wrap all drawing in a try/catch block) and in the end you'll just end up with a crashed app and lost data. OTOH, overflowing a matrix stack will just result in some strange drawing, which is visible to the user and developer but allows the user a chance to save their data. > ... > > I see Ben says "They're portable (except perhaps to some really obscure > > embedded systems)" - I guess he means me! > > I'd be surprised if most of these, nowadays, didn't support exceptions. Given > the push towards an attempt at standard-compilance (and even pre-empting the > c++0x standard) by most major compiler vendors, I don't see why embedded > system compilers would be *that* much different Doing exceptions properly requires a LOT of overhead in the compiler and runtime, and there exist today threading implementations which are not safe to use with C++ exceptions, and not on obscure platforms, either - throwing an exceptions from a dispatch thread (block) on Mac OS X will do an excellent job of crashing your program, and blocks are literally used *everywhere* in the system libraries now. Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk3 build issue
On Aug 9, 2011, at 1:26 AM, Evan Laforge wrote: > ... > So it's not really about trying to clean up mistakes after the fact. > There's just not much a library can do if you passed an index out of > bounds, but it's nicer to print a trace and quit rather than segfault. This amounts to the same thing - an uncaught exception will cause a crash, in many cases without any visible logging. Again, I'm -1 on using exceptions in FLTK. ________ Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fltk3 build issue
On Aug 9, 2011, at 1:02 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: >> Ah, thanks. I was using exception to verify my code. Now >> should I enable them for fltk3, or should I remove the >> try-catch-throw? > > I see Ben's already answered in favour of exceptions, but I have to say > that (at least for the core library) I'm not in favour. (Though, like > the STL, I have no problem with using it in user-code, of course.) I'd have to vote -1 on exceptions. FLTK already has a mechanism for reporting exceptional conditions (Fl::fatal and friends), and the default handlers can be overridden by an app. Moreover, exceptions don't play nicely with threading and add a huge amount of overhead for simple error reporting. Better to simply make a library that doesn't crash and returns errors (when appropriate) or calls the existing exception points than to force C++ exceptions on everyone. Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Developer Roadmap broken?
I just checked in a fix that retains the desired validation behavior without creating a new instance of "str" for the master_id (which then calls validate, causing the loop...) On Aug 3, 2011, at 2:30 AM, Matthias Melcher wrote: > > On 03.08.2011, at 11:01, Albrecht Schlosser wrote: > >> On 03.08.2011 10:47, MacArthur, Ian (SELEX GALILEO, UK) wrote: >> >>>> 2686 and 2689 have produced empty output in the log and can >>>> not be viewed anymore. What did you change? Maybe we can un-change it? >>> >>> It's maybe some sort of circular reference? >>> >>> They are "the same" bug AFAICT,and I was trying to set the duplicate >>> field when things went bad... >> >> Oh, I remember another (maybe related?) issue when I tried to *reset* >> the duplicate field recently. The update failed with the message >> >> "Unable to save STR!" >> >> See my post on Jul 20, 2011 to STR #2490 >> <http://www.fltk.org/str.php?L2490> > > Yeah, I just tried some trickery, but without modifying str.php, I will not > be able to fix this. Maybe I have some time later to do just that. Maybe Mike > can put a few thoughts into the "duplicate" field?! > > - Matthias > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Developer Roadmap broken?
On Aug 3, 2011, at 2:30 AM, Matthias Melcher wrote: > ... > Yeah, I just tried some trickery, but without modifying str.php, I will not > be able to fix this. Maybe I have some time later to do just that. Maybe Mike > can put a few thoughts into the "duplicate" field?! It is just a single ID in the db schema (master_id) and I'm using the same thing on half a dozen other web sites I'm hosting... Will take a look... ________ Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Fl_Input_Choice suggestions
On Jul 20, 2011, at 12:15 AM, Greg Ercolano wrote:
> Would like to suggest adding a few things to Fl_Input_Choice:
>
>1) Change the existing method:
>
> void add(const char *s) { menu_->add(s); }
>
> to instead:
>
> int add(const char *s) { return(menu_->add(s)); }
>
> This corrects an omission, allowing the user to access
> the integer value that is the index for the menu item.
> ...
> A few questions:
>
> a) Does (1) break the ABI (by changing the return value from void to int)?
> Pretty sure the others would have no impact.
Yes, 1) changes the ABI and so can't be introduced in 1.3.x. The others are
fine (although it will complicate the 1.3/2.0 -> 3.0 transition a bit...)
Michael Sweet, Easy Software Products
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] multilingual not fully work fltk
On Jul 18, 2011, at 4:43 PM, Ian MacArthur wrote: >> ... >> Ooops, must have deleted the rest by accident - "This could be used to >> reposition widgets and change the appearance of widgets." > > Oh, I see; so if we determine the text is predominantly r2l for example, we > could redraw the widgets for a r2l biased layout, that sort of thing? > E.g. move the buttons in a stock dialog to the lower left rather than lower > right, and so on? (Do we / should we, do that for r2l text? I don't know...) On the Mac, at least, we localize R2L languages with the position and order of controls reversed. ____ Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LGPL question
// Copyright 1998-2011 by Bill Spitzak and others. // // This library is free software. Distribution and use rights are outlined in // the file "COPYING" which should have been included with this file. If this // file is missing or damaged, see the license at: // // http://www.fltk.org/COPYING.php // // Please report all bugs and problems on the following page: // // http://www.fltk.org/str.php // On Jul 18, 2011, at 12:22 PM, Albrecht Schlosser wrote: > On 18.07.2011 17:12, Michael Sweet wrote: >> The new header should look like this: >> >> // Copyright 1998-2011 by Bill Spitzak and others. >> // >> // This library is free software. Distribution and use rights are outlined in >> // the file "COPYING" which should have been included with this file. If >> this >> // file is file is missing or damaged, see the license at > > s/file is file/file/ > >> // "http://www.fltk.org/";. > > Wouldn't it be better to have a direct (complete) link? > > // "http://www.fltk.org/COPYING.php";. > > ...snipped... > > Albrecht > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LGPL question
On Jul 18, 2011, at 12:30 PM, MacArthur, Ian (SELEX GALILEO, UK) wrote: > >> Wouldn't it be better to have a direct (complete) link? >> >> // "http://www.fltk.org/COPYING.php";. >> >> ...snipped... > > Oh yes, if that's allowed, then that seems like it would be better. > > And while I remember, do we want to update COPYING.php to remove the > reference to "fltk-b...@fltk.org" and instead refer folk to the STR > pages? Yes. > > ISTR we made that change, or something like it, elsewhere in the > documentation and it seemed like a Good Idea, in case we are at risk of > losing bits and pieces in the background noise on the bugs list... > > > > SELEX Galileo Ltd > Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 > 3EL > A company registered in England & Wales. Company no. 02426132 > > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] multilingual not fully work fltk
On Jul 18, 2011, at 10:55 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: > ... > This is true, of course, but could be a fair bit of work for us to make > it fly - we would certainly be into the 1.4/3.x range for this! We could certainly introduce Pango or ICU support as an experimental addition in 1.3 and default in 3.0 for X11. The current situation definitely limits how much Unicode can be supported without platform-specific code. > ... > - switch to rendering (at least) word-by-word rather than > glyph-by-glyph, as this makes it easier to interpret the context of each > glyph in the word and composite it correctly. You want line (or phrase) rendering; word rendering loses bi-dir text handling. Basically, fl_draw would need to be modified slightly to pass each line it formats through Pango (or ICU) to generate the final display sequences. >> ... >> There are some other helpful things that FLTK could provide without a >> lot of overhead/bloat: > > Though maybe with some extra dependencies... True, but the point would be to use "native" libraries whenever possible. >> 1. A number formatter and scanner that uses the current locale - >> particularly for Arabic, but also to handle decimal and thousands >> separators. > > I'd guess that ICU / PanGo / iconv must know this stuff anyway? I don't think iconv supports this; ICU and Pango do though... > ... > Is there something specific about number handling for Arabic texts? I > don't know but I always assumed, since the number system in Arabic texts > is derived from broadly the same Indic sources as the numbers used in > modern LGC scripts, that they would be more or less the same - is that > not the case? It is, unfortunately, not the case... >> ... >> This could be used to reposition > > Something got clipped here? > I guess "reposition the text on the line" or something? Ooops, must have deleted the rest by accident - "This could be used to reposition widgets and change the appearance of widgets." >> 3. Methods to implement localization of strings (perhaps layered >> on top of the corresponding OS API, or using FLTK-specific code - I >> can contribute a .po/.strings file loader) > > Yup - gettext / catgets / whatever OSX and WINXX do... I have no real > idea about this... I've done enough wrappers - not a big deal to implement efficiently. Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LGPL question
The new header should look like this: // Copyright 1998-2011 by Bill Spitzak and others. // // This library is free software. Distribution and use rights are outlined in // the file "COPYING" which should have been included with this file. If this // file is file is missing or damaged, see the license at // "http://www.fltk.org/";. // // Please report all bugs and problems on the following page: // // http://www.fltk.org/str.php // On Jul 17, 2011, at 12:54 PM, Greg Ercolano wrote: > On 07/16/11 20:37, Michael Sweet wrote: >> We should drop the reference to gnu.org and just refer to it as the FLTK >> License... > > If someone can supply the new license text that we should use, > I can do the footwork of the mega-diff. > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] multilingual not fully work fltk
On Jul 18, 2011, at 4:49 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: > > Unfortunately it seems that nitin, the OP, is on a Linux system... > > I guess the best bet is for him to pre-format the strings into display order > before rendering - this is what ICU or PanGo can help with, of course, but in > this case, if it is just a few simple transpositions, some language-specific > hook might be the easier option. > > I.e. write a little function that scans the passed in string, finds the > specific transposition cases and swaps the chars over, before passing the > "corrected" string to the renderer for display... > > I think that should Just Work, but who knows! FWIW, I would actually prefer that FLTK handles the conversion to display order (as needed) since otherwise you end up with every Unicode app re-implementing the same damn code, and all of the other (mainstream/popular) GUI toolkits handle this for the developer as well. Since Mac OS X and Windows provide the necessary support already, we would just need to use ICU or Pango on the X11-based platforms to achieve parity. There are some other helpful things that FLTK could provide without a lot of overhead/bloat: 1. A number formatter and scanner that uses the current locale - particularly for Arabic, but also to handle decimal and thousands separators. 2. A method that returns the default display order for the current locale - left to right, right to left, top to bottom, bottom to top. This could be used to reposition 3. Methods to implement localization of strings (perhaps layered on top of the corresponding OS API, or using FLTK-specific code - I can contribute a .po/.strings file loader) ____ Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] 1.3.0 ABI
Yes, no incompatible ABI changes in patch releases (you could have a method that refers to the global default, but not add something to the class that would change the size...) On Jul 16, 2011, at 12:41 AM, Greg Ercolano wrote: > Ah, crap. > > The 1.3.0 opportunity passed for me to add an integer > to the Fl_Table class for "_scrollbar_size" so that it > would be like the other scrollbar oriented widgets > where the scrollbar size can have a local override > to the global one. > > STR#2679 reminded me of this. > > Are we planning on being 100% ABI compatible with 1.3.0 > for the next 1.3.x release? > > If so, guess I'll hold off, and submit an STR for 1.4.x > to do this. > > Dang shared libs, anyhow.. :/ > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] LGPL question
We should drop the reference to gnu.org and just refer to it as the FLTK
License...
On Jul 14, 2011, at 4:48 PM, Greg Ercolano wrote:
> As we all know, FLTK has its own "static link exception"
> in our license file included with the toolkit ("COPYING").
>
> However, of *possible* confusion:
>
> The headers in all our source files refer to the raw LGPL
> from gnu.org, which *might* be a point of confusion,
> since IIRC *that* license would make no mention of our
> exception.
>
> Arguably our COPYING license overrides this, but perhaps our
> headers should be more clear about the static exception.
> ___
> fltk-dev mailing list
> fltk-dev@easysw.com
> http://lists.easysw.com/mailman/listinfo/fltk-dev
Michael Sweet, Easy Software Products
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] fluid printing on OS X [was: Fltk3: fails onwin32 building "fluid1"]
On Jul 12, 2011, at 6:46 PM, Albrecht Schlosser wrote:
>>
>> On 12 Jul 2011, at 18:08, Albrecht Schlosser wrote:
>>
>>> Yep, fixed in svn for FLTK 1.3, and going to do it for 3.0 as well ...
>>> FWIW: the same was true for template_panel.{fl|cxx|h}.
>>
>> Ah, I see you've changed that already - thanks for that.
>> Thought, being pedantic, we need to do the duplicates in fluid1/ as well =
>> for completeness...=20
>>
>> Um, I can't remember the svn commands for setting the appropriate tags, =
>> anybody?
>>
>> What tags do we usually set on source files? I guess EOL=3Dnative, and =
>> something for the ID, and anything else?
>
> Yep, you can run `svn pl -v *.fl´ or something like that, and then modify
> what you see slightly, to get:
>
> $ svn ps svn:eol-style native files ...
> $ svn ps svn:keywords "author date id revision" files ...
>
> Strictly speaking, we're only using 'id', but I've seen all these 4 keywords
> on some source files, and I'm using them always. You never know...
Yeah, those came across in the original conversion from CVS to SVN. "Id" is all
that we require for the standard source file header/footer.
Michael Sweet, Easy Software Products
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK3: make examples compile
On Jul 9, 2011, at 5:43 PM, Ian MacArthur wrote: > ... > I may be going off at a slight tangent here, but it occurs to me that there > are two sides to to making the examples folder build under fltk3; > > a) tweak the examples to be fltk3 like > > b) tweak fltk3 so that it correctly builds the fltk1 examples, thus proving > the compatibility layer works. > > > It looks like Alex has been taking a run at (a) here, but I'd suggest that at > this stage in the game, getting (b) to work would be more useful. > > Thoughts? Why not have an examples1 and examples directory, with the examples1 directory containing the original examples (that get built with the compatibility layer) and the examples directory containing the FLTK 3 versions. That will allow us to catch both compatibility issues and regressions, since presumably all of the ported examples should behave the same as the originals. ____ Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Change default font - text mode
Linux uses the URW versions of Helvetica which ARE free... On Jul 2, 2011, at 3:43 AM, Georg Potthast wrote: > Thank you Matthias, > > I tried again and changed the first four entries in the Fl_Fontdesc > built_in_table[] from Helvetica to dejavu and that did work now. > > However, I think FLTK is free of charge and therefore should not use a font > as a default font which is not free. If you want to download the font, you > have to pay for it. You are not allowed to use it without paying a licence > fee. > > Georg > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev ____ Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2672: Updated Gleam patch against FLTK1.3.x-r8816
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2672 Version: 1.3-feature I preferred the up boxes from v3; the down boxes in v4.1 are pretty good - perhaps we can combine the two? As for updating the default look - no objections as long as the old box types are still available. Link: http://www.fltk.org/str.php?L2672 Version: 1.3-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Flth3 build error on win32/msys/mingw
I think it would be far more practical for fluid3 to be able to read fluid1 and fluid2 files, read and write fluid3 files, and generate FLTK 3 code (only). If someone wants FLTK 1 or FLTK 2 code, they can use the corresponding version of FLTK and fluid. If they are using FLTK 3 then fluid should generate FLTK 3 code exclusively. On Jun 21, 2011, at 2:07 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: > >> BTW: I included preferences.cxx/.h because FLTK3 Fluid at the >> moment would write a mishmashed FLTK3 cxx/h pair. In an >> effort to generate the FLTK3 FileChooser UI from the .fl >> file, I forgot that an FLTK1 .fl file should still generate >> FLTK1 code, and an F3 .fl file should generate F3 code. >> Optionally, an F1 .fl file should be saved (exported) as an >> F3 .fl file, which will of course fail for user generated code. > > Oh, that's a point - it had not occurred to me that we will need a > "super-fluid" that can create fltk1 and/or fltk3 (or even fltk2) source > as its output. > > That's quite tricky. > > How do we even represent that? Does the fluid file specify what > output-style it should be, or does the user click a check-box when > generating the code, or...? > > >> But I will get to that when everything else works. > > Indeed... > > > > SELEX Galileo Ltd > Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 > 3EL > A company registered in England & Wales. Company no. 02426132 > > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > > > ___________ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Flth3 build error on win32/msys/mingw
On Jun 20, 2011, at 8:41 AM, Matthias Melcher wrote: > ... > At first, I had va_list as the last argument, but then I received a similar > warning, which is why I moved it to the front. I now added va_ as a prefix > and everything is fine. Should I also move va_list to the end of the argument > list again? I would for consistency with other uses of va_list. Also, I'm not keen on the "va_" prefix to the function since a) everyone else uses "v" and b) "va_" is already used for several functions and a type, and it is conceivable that some implementation of stdarg might use va_alert internally... Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Flth3 build error on win32/msys/mingw
On Jun 20, 2011, at 5:24 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: > I just noticed I mis-spelled the lib name in the title; fltk or flth > anyone? > > >>> The "first" option that the compiler offers is the one expanding >>> "alert(va_list, const char *);" where the va_list is >> expanded here as a >>> "char*", so it's (possibly) not really in our remit to be >> able to set >>> how the va_list is interpreted? >> >> Oh, I was under the impression there explicitly exist 2 alert() >> functions - this is what I get for not reading the source! > > There are two, being: > > A) FLTK3_EXPORT void alert(const char *,...) __fl_attr((__format__ > (__printf__, 1, 2))); > B) FLTK3_EXPORT void alert(va_list, const char *); FWIW, the normal convention for these sorts of things is to put the va_list argument last to be consistent with the variable argument version (e.g. snprintf vs. vsnprintf), however in this case it looks like MingW is not providing a true type for va_list but it simply mapping it to char * (!?!) which is causing problems here and likely elsewhere for other C++ code. Since we've had issues with this in the past (look at the mess we have to Fl_Pixmap constructors) I would recommend renaming to avoid ambiguity, e.g.: FLTK3_EXPORT void alert(const char *, ...) __fl_attr((__format__(__printf__, 1, 2))); FLTK3_EXPORT void valert(const char *, va_list); Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2672: Updated Gleam patch against FLTK1.3.x-r8816
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2672 Version: 1.3-feature For a strict adherence to the CMP, all features need to be pushed to 1.4 or later. Link: http://www.fltk.org/str.php?L2672 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 #2672: Updated Gleam patch againstFLTK1.3.x-r8816
Agreed - I like v3 the best so far... On Jun 20, 2011, at 1:38 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: > > >> Here there is the modified version of fl_gleam. I think it >> looks better >> with the gradients on the top and the bottom, so the the >> middle area of >> the widgets it is no strongly affected. Here an screen shot: >> >> https://sites.google.com/site/eetorres/fl_gleam >> >> The new gleam can be found here >> >> https://github.com/eetorres/fl_gleam/blob/master/fl_gleam.cxx > > Looks nice (though I'm not sure if I like it better than your earlier > styles...) > > There's no patch file for the core lib, just the gleam.cxx file - do we > just use the patchfile from your previous snapshot? > > (I didn't try that, but assume it would be.) > -- > Ian > > > > SELEX Galileo Ltd > Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 > 3EL > A company registered in England & Wales. Company no. 02426132 > > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > > > ___________ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Announcing 1.3 ?
I usually posted an announcement on freshmeat.net as well as fltk.announce and fltk.org. I'll send you a link to a page that will post to fltk.announce, the rest can be handled through the corresponding web sites. On Jun 17, 2011, at 5:29 AM, Matthias Melcher wrote: > > I remember that we used to announce new versions in several places. I just > don't remember which ones. > > Any suggestions? > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev ________ Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] 1.3.1 option in STR's
I've updated the original (private) 1.3.0 version number to be 1.3.1. You can go to "http://www.fltk.org/strversions.php"; to update versions you've created. On Jun 16, 2011, at 5:13 PM, Greg Ercolano wrote: > Can a 1.3.1 option be added to the STR system's submenus? > > I noticed 1.3.0 appears *twice* in the "Fix Version:" submenu, > so I'm guessing something needs to be tickled for 1.3.1 to show up. > > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] FLTK 1.3 release date: Remaining OpenGL error
Ship it! :) On Jun 15, 2011, at 1:38 PM, Matthias Melcher wrote: > > Hi guys, > > one "new" bug appeared that seems to be related to a driver error for OpenGL > on Windows 7. It doesn't seem like there is a true fix. I don't use Windows > 7, so I can't really say how bad this is, but I tend to push this back to > 1.3.1 and release 1.30 as is tomorrow (Thursday). > > Any suggestions? > > - Matthias > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Dynamic linking with VS 2010
On May 24, 2011, at 1:00 PM, Greg Ercolano wrote: > Albrecht Schlosser wrote: >>> Assuming that works, the only thing that might be wrong with this >>> (having a small static link stub to access the DLL) would be an >>> LGPL issue, believe it or not. >>> >>> >> [...] >>> >> >> IANAL, but... Our FLTK library allows to link statically as an explicit >> exception, so why wouldn't it be allowed to link most of FLTK dynamically >> (DLL) and a small part (WinMain()) statically ? > > Oh, guess I forgot about that ;) > Indeed the discussion I cited was about another LGPL library. > > However; I wonder how compatible our LGPL exception is > with the other libs we include (png, jpeg). I guess those > are optional libs that the user can link against as dlls, > but if one uses them, perhaps our exception becomes disabled. PNG, JPEG, and ZLIB are all BSD-style copyright licenses - no problems there. Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Dynamic linking with VS 2010
On May 24, 2011, at 11:55 AM, Greg Ercolano wrote: > (Moving the fltk.general thread "Link Errors / Visual C++ 2010 Express" here) > > Asif writes: >>> May be you can name such header dll_linked_app.h or something like that. > > Albrecht writes: >> I think that winmain.h is a good choice, isn't it? > >This would mean the user program would have to have an #ifdef >in their main.cxx to handle a DLL vs non-DLL build, which is a >detail I'd think we should want to avoid if we can. > >My thinking on how this all worked before: > > fltkdll.lib -- has WinMain(), no fltk code (basically a /very/ small > static lib) > fltkdll.dll -- has the fltk code, but no WinMain() That's not how Windows import libraries work; fltkdll.lib has to be generated from fltkdll.dll, otherwise we'll never load fltkdll.dll. What we'd need is a fltkmain.lib static library that just has the WInMain junk. > ... >Assuming that works, the only thing that might be wrong with this >(having a small static link stub to access the DLL) would be an >LGPL issue, believe it or not. That's why FLTK isn't pure LGPL - we include an exception for static linking... Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2633: New methods for Fl_JPEG_Image and Fl_PNG_Image to encode from Fl_Image
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2633 Version: 1.4-feature Probably default to white... Link: http://www.fltk.org/str.php?L2633 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 #2633: New methods for Fl_JPEG_Image and Fl_PNG_Image to encode from Fl_Image
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2633 Version: 1.4-feature Might be useful to include a background color for saving to JPEG - then the colors in the image can be composited with the background color... Link: http://www.fltk.org/str.php?L2633 Version: 1.4-feature ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [fltk.commit] [Library] r8659 - branches/branch-1.3/src
Valgrind *is* available for Mac OS X, and has been for a while now (and
actually works very well...)
On May 13, 2011, at 12:58 AM, fltk-dev@easysw.com wrote:
> Author: matt
> Date: 2011-05-13 00:58:26 -0700 (Fri, 13 May 2011)
> New Revision: 8659
> Log:
> STR 2630: added bounds check for very narrow text editing widgets, wishing
> that Valgrind was available for OS X
>
> Modified:
> branches/branch-1.3/src/Fl_Text_Display.cxx
>
> Modified: branches/branch-1.3/src/Fl_Text_Display.cxx
> ===
> --- branches/branch-1.3/src/Fl_Text_Display.cxx 2011-05-12 15:53:59 UTC
> (rev 8658)
> +++ branches/branch-1.3/src/Fl_Text_Display.cxx 2011-05-13 07:58:26 UTC
> (rev 8659)
> @@ -420,7 +420,8 @@
> /* if empty lines become visible, there may be an opportunity to
>display more text by scrolling down */
> } else {
> -while ( (mLineStarts[mNVisibleLines-2]==-1)
> +while ( mNVisibleLines>=2
> + && (mLineStarts[mNVisibleLines-2]==-1)
>&& scroll_(mTopLineNum-1, mHorizOffset))
> { }
> }
> @@ -974,7 +975,7 @@
>
> if (insert_position() < mFirstChar) {
> topLine -= count_lines(insert_position(), mFirstChar, false);
> - } else if (mLineStarts[mNVisibleLines-2] != -1) {
> + } else if (mNVisibleLines>=2 && mLineStarts[mNVisibleLines-2] != -1) {
> int lastChar = line_end(mLineStarts[mNVisibleLines-2],true);
> if (insert_position() >= lastChar)
> topLine += count_lines(lastChar - (wrap_uses_character(mLastChar) ? 0 :
> 1),
>
> ___
> fltk-commit mailing list
> fltk-com...@easysw.com
> http://lists.easysw.com/mailman/listinfo/fltk-commit
Michael Sweet, Easy Software Products
___
fltk-dev mailing list
fltk-dev@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] About the 1.3 STR's...
On May 11, 2011, at 3:45 AM, Matthias Melcher wrote: >> ... >> I don't know how far #2500 is currently. > > It feels like it's done, I can't verify it though. Maybe Mike can give me a > green light soon. Everything looks good. +1 ________ Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] /MD vs /MT for fltk builds under VS [DLL hell]
On May 10, 2011, at 8:38 AM, Greg Ercolano wrote: > I was noticing yesterday fltk (1.3.x) builds the "fltk" subproject > in DLL hell mode, ie. with the compiler flag /MD (DLL runtime libs) > instead of /MT (static runtime libs). > > Using /MD creates a situation where the resulting exe ends up > requiring MSVCRXXX.DLL file in order to run on other machines > that don't have VS installed. > > I'm wondering if: > > a) the /MD flag is a good default, given the DLL hell > it seems to incur on unsuspecting programmers; > perhaps /MT instead? The static libraries have their own problems, particularly if you use FLTK as part of a plug-in for another application or if you link to any other DLL, which will be compiled against the dynamic runtime, pulling in different C runtime definitions that clash with the static libraries... Trust me, I've run into too many problems with different versions of malloc and free getting used, leading to some non-obvious crashes/bugs. > b) Is there an easy way to change this for the entire lib > if an app programmer needs to? I dunno, VC++ doesn't offer solution-level settings like Xcode projects... Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] About the 1.3 STR's...
On May 8, 2011, at 1:01 PM, Matthias Melcher wrote: > > Thanks to you all so much for keeping on working on the STR's. I am still > quite busy at work and I was no help at all. I will try to add a bit more man > power in the next days as I get back to coding a bit. > > As you know, I tried at the beginning of the year to set 1.3.0 in stone by > creating a few release candidates, but bugs kept creeping in. At this point, > I would like to do another RC soon, seeing that there are only six bugs. So > here's my list: > > > * 2500fltk.list.in (EPM) is outdated Config FilesNew HIGH > > Mike, will you have time to do this? If not, can we do this? Not sure if I have time, but the format is dead-simple: http://www.epmhome.org/documentation.php The trickiest part is the conditional symlinks, but that can be addressed using %if SOMETHING, where SOMETHING is defined in the configure script. ____ Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Transparent Image Dsiplay
I'll give them your email address <> On Mar 31, 2011, at 12:37 PM, Greg Ercolano wrote: > Michael Sweet wrote: >> Done! > > Nice! > > I hope folks don't ask 'where's the old non-alpha version'? lol > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Transparent Image Dsiplay
Done! On Mar 31, 2011, at 10:14 AM, Greg Ercolano wrote: > MacArthur, Ian (SELEX GALILEO, UK) wrote: >>> I am using fltk2.0 for my development. >> >> That may not be wise, as fltk2 is the experimental branch, has never had >> a release, and is still considered alpha for most practical purposes. > > Can we insert "-alpha-' into the 2.0.x tar snapshot filenames? > > This would I think help warn folks stumbling onto 2.0.x, > as I think the higher version numbers (2.0 vs 1.3) sound too optimistic > otherwise ;) > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Transparent Image Dsiplay
I'll see what I can do... On Mar 31, 2011, at 10:14 AM, Greg Ercolano wrote: > MacArthur, Ian (SELEX GALILEO, UK) wrote: >>> I am using fltk2.0 for my development. >> >> That may not be wise, as fltk2 is the experimental branch, has never had >> a release, and is still considered alpha for most practical purposes. > > Can we insert "-alpha-' into the 2.0.x tar snapshot filenames? > > This would I think help warn folks stumbling onto 2.0.x, > as I think the higher version numbers (2.0 vs 1.3) sound too optimistic > otherwise ;) > ___ > fltk-dev mailing list > fltk-dev@easysw.com > http://lists.easysw.com/mailman/listinfo/fltk-dev Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Xcode 4 project
On Mar 28, 2011, at 6:06 AM, MacArthur, Ian (SELEX GALILEO, UK) wrote: > >> But the main reason is that Xcode 4 compiles for 10.6 only >> (at least out of the box), whereas Xcode 3 comes with the >> 10.5 SDK as well. So if one targets SOX 10.5 or even lower, >> additional downloads of SDKs would be required. >> >> What do you think? > > Also, Xc4 will not build PPC binaries for you either, so is of little > use to me. > It appears I'm going to stick with 3.2.5 for the foreseeable future... > > (NOTE: I have not tried 3.2.6, but am told it does not do PPC either.) Getting 3.2.6 via the iOS SDK will not give you the PowerPC bits, but getting 3.2.5 and then doing the software update will keep them. Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Xcode 4 project
On Mar 28, 2011, at 5:17 AM, Matthias Melcher wrote: > ... >> I see that Xcode 3 handles without any warning this Xcode 4 project, >> so wonder if it's not possible to have a single project for the two >> Xcode versions. > > Well, Apple offers to save the project file in 3.x or 4.x format, so I assume > it may be different in future revisions of Xcode4, or support features we > have not used yet, and may then be unable to load in 3.x then. Apple is intentionally keeping the project file format (the project.pbxproj file in the bundle) the same for Xcode 4. The only difference is where the user and shared settings get stored, which we don't normally put in the repository... > But the main reason is that Xcode 4 compiles for 10.6 only (at least out of > the box), whereas Xcode 3 comes with the 10.5 SDK as well. So if one targets > SOX 10.5 or even lower, additional downloads of SDKs would be required. You can set the deployment version down to 10.4 IIRC, independent of the SDK. (i.e. build against the 10.6 SDK but warn for anything that was introduced after 10.4). That said, Xcode4 does not include the PowerPC compiler or SDK bits so you can only build Intel binaries - kind of kills things if you want to still support PowerPC... It also drops support for v2 NIB files, but that doesn't affect FLTK - NIB files are serialized object containers for Cocoa UIs... Michael Sweet, Easy Software Products ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
