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 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 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
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
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 A few minor comments: - It looks to me as if the patch changes the behaviour of Fl_get_system_colors for all schemes, not just for the gleam patch. I don't think that's acceptable, as it may have backwards compatability issues and so forth (or at least may unexpectedly change the appearance of apps that do not use the new scheme.) - The patch needs to include a mod to test/demo.cxx to make the new scheme selectable in testing; actually, I'm surprised that is missing, as it would make it very easy to exercise the new scheme on a variety of different widget styles. - Should we bump this to 1.4 for now? Or is it OK to be a 1.3 RFE now that 1.3.0 is out? -- Ian 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
[fltk.development] Flth3 build error on win32/msys/mingw
Just refreshed my fltk3 snapshot - fails with the following errors. (NOTE: I don't think I've ever seen one of those errors before, now we have several!) Compiling Fl_File_Chooser2.cxx... Fl_File_Chooser2.cxx: In member function `void fltk3::FileChooser::fileNameCB()': Fl_File_Chooser2.cxx:870: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: ../fltk3/ask.h:61: note: candidate 1: void fltk3::alert(char*, const char*) ../fltk3/ask.h:60: note: candidate 2: void fltk3::alert(const char*, ...) Fl_File_Chooser2.cxx: In member function `void fltk3::FileChooser::newdir()': Fl_File_Chooser2.cxx:1058: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: ../fltk3/ask.h:70: note: candidate 1: const char* fltk3::input(char*, const char*, const char*) ../fltk3/ask.h:69: note: candidate 2: const char* fltk3::input(const char*, const char*, ...) Fl_File_Chooser2.cxx:1079: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: ../fltk3/ask.h:61: note: candidate 1: void fltk3::alert(char*, const char*) ../fltk3/ask.h:60: note: candidate 2: void fltk3::alert(const char*, ...) Fl_File_Chooser2.cxx: In member function `void fltk3::FileChooser::showChoiceCB()': Fl_File_Chooser2.cxx:1229: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: ../fltk3/ask.h:70: note: candidate 1: const char* fltk3::input(char*, const char*, const char*) ../fltk3/ask.h:69: note: candidate 2: const char* fltk3::input(const char*, const char*, ...) make[1]: *** [Fl_File_Chooser2.o] Error 1 make: *** [all] Error 1 This is an older mingw: gcc version 3.4.2 (mingw-special) SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Flth3 build error on win32/msys/mingw
On 20.06.2011, at 11:39, MacArthur, Ian (SELEX GALILEO, UK) wrote: Just refreshed my fltk3 snapshot - fails with the following errors. (NOTE: I don't think I've ever seen one of those errors before, now we have several!) Compiling Fl_File_Chooser2.cxx... Fl_File_Chooser2.cxx: In member function `void fltk3::FileChooser::fileNameCB()': Fl_File_Chooser2.cxx:870: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: ../fltk3/ask.h:61: note: candidate 1: void fltk3::alert(char*, const char*) ../fltk3/ask.h:60: note: candidate 2: void fltk3::alert(const char*, ...) Wow, no, I have never seen those before either. I am using va_list as an argument. Maybe that's what's causing it. I will look into this later. ___ 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
What I'd suggest doing is simply explicitly casting the first parameter to a char*; this _should_ fix your issue (at least it doesn't create any on gcc under Ubuntu 10.10). I suspect the only person who could confirm such a fix would be Ian, though Yes, that does work, e.g: (Fl_File_Chooser2.cxx, line 870:) // fltk3::alert(%s,existing_file_label); // error fltk3::alert((char*)%s,existing_file_label); // ok (This pattern is required in several places, and in Fl_Text_Buffer.cxx, Fl_Function_Type.cxx, etc...) Though I have concerns about casting a fixed string like that just to trick the compiler into doing the obvious conversion. Google produces a fair few hits for this failure pattern, but I didn't immediately see any suggestions for a fix we could apply easily, without requiring that any use of fltk3::alert() do the explicit cast, which may well confuse end users. And me. I suppose the best bet *might* be to add a third option that expands to (const char *, const char*) that would then take precedence over either of the ambiguous cases here and so avoid the problem...? -- Ian SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Flth3 build error on win32/msys/mingw
// fltk3::alert(%s,existing_file_label); // error fltk3::alert((char*)%s,existing_file_label); // ok Though I have concerns about casting a fixed string like that just to trick the compiler into doing the obvious conversion. From what I understand of the mechanics of const vs. non-const, it shouldn't have any effect on the mechanics of the executable. const just forces the variable / etc. into read-only memory which has no write access (hence writing to const strings causes a segmentation fault). Yup - my worry is that if we use %s like that, the compiler will create a const char array, we then cast away the const-ness, and (conceivably) could then write to that string - segfault, bad. So I'm not keen on casting away the inherent const-ness of the fixed string... Though in practice I don't think alert() and so forth do ever actually write to the passed string, so in practice we are surely OK to do that? I suppose the best bet *might* be to add a third option that expands to (const char *, const char*) that would then take precedence over either of the ambiguous cases here and so avoid the problem...? TBH it looks like existing_file_label shouldn't be declared const anyway, and on top of that I'm not sure why the first parameter in alert isn't const - it seems to me that this parameter should always be const? This no doubt makes sense to Matt though! 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? If existing_file_label were to be changed to char*, this should then be matched to the second version of alert() Though we need a general solution too, since it is not just alert() that has problems, also message(), choice() etc... All the places where we've added va_list I suspect (though have not checked in detail...) so I'm not sure how best we proceed. SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] Flth3 build error on win32/msys/mingw
Yup - my worry is that if we use %s like that, the compiler will create a const char array, we then cast away the const-ness, and (conceivably) could then write to that string - segfault, bad. So I'm not keen on casting away the inherent const-ness of the fixed string... Though in practice I don't think alert() and so forth do ever actually write to the passed string, so in practice we are surely OK to do that? I do have to agree, but from what I understand of the standard, because it's only implicitly const you can force the compiler to make it a char* and then you're free to write to it - the same reason an explicit cast to char* when setting a (c-)string lets you overwrite the string later on. I suppose the best bet *might* be to add a third option that expands to (const char *, const char*) that would then take precedence over either of the ambiguous cases here and so avoid the problem...? TBH it looks like existing_file_label shouldn't be declared const anyway, and on top of that I'm not sure why the first parameter in alert isn't const - it seems to me that this parameter should always be const? This no doubt makes sense to Matt though! 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! If existing_file_label were to be changed to char*, this should then be matched to the second version of alert() Though we need a general solution too, since it is not just alert() that has problems, also message(), choice() etc... All the places where we've added va_list I suspect (though have not checked in detail...) so I'm not sure how best we proceed. Yes, that's true. Time for Matt's thoughts on all of this, I think... Ben ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [RFE] STR #2641: Implement proper fullscreen support
DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW. [STR New] Link: http://www.fltk.org/str.php?L2641 Version: 1.4-feature Attached patch fullscreen17.patch, update patch to better deal with the Windows coordinate mess and to fix windows starting in fullscreen. Link: http://www.fltk.org/str.php?L2641 Version: 1.4-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
[..] 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 *); const issues aside, (A) says there's an fl_alert() that takes a char* argument and some other arguments, while (B) says there's one that takes some arguments and a char*. Isn't that bound to be ambiguous in some cases? For instance, imagine maybe const char* a, b, c; fl_alert(a, b, c) No matter whether the declarations of (A) and (B) include const, won't there always be some combination of const/non-const a,b,c that makes the fl_alert call ambiguous? Or have I missed something? ___ 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
No need to fiddle something. The va_list version is only there to support the sealers and would be rarely used by an app developer. Somewhat like fprint vs vfprint. All we need to do is rename the second fltk3::alert to fltk3::va_alert and the ambiguity is gone. It's interesting that va_list expands to char*. ts ts. On 20.06.2011, at 15:27, s...@sjssoftware.com wrote: [..] 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 *); const issues aside, (A) says there's an fl_alert() that takes a char* argument and some other arguments, while (B) says there's one that takes some arguments and a char*. Isn't that bound to be ambiguous in some cases? For instance, imagine maybe const char* a, b, c; fl_alert(a, b, c) No matter whether the declarations of (A) and (B) include const, won't there always be some combination of const/non-const a,b,c that makes the fl_alert call ambiguous? Or have I missed something? ___ 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] Flth3 build error on win32/msys/mingw
No need to fiddle something. The va_list version is only there to support the sealers and would be rarely used by an app developer. Somewhat like fprint vs vfprint. All we need to do is rename the second fltk3::alert to fltk3::va_alert and the ambiguity is gone. It's interesting that va_list expands to char*. ts ts. Yup - that's got it, r8834 now builds fine up until... Compiling shape.cxx... Linking shape.exe... === making test1 === make[1]: *** No rule to make target `Preferences.h', needed by `unittests.o'. Stop. make: *** [all] Error 1 SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [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] 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] Flth3 build error on win32/msys/mingw
Ahrgh. Go into the fltk directory and run make depend. I keep forgetting to do that before I run svn commit and after make clean. On 20.06.2011, at 16:30, MacArthur, Ian (SELEX GALILEO, UK) wrote: No need to fiddle something. The va_list version is only there to support the sealers and would be rarely used by an app developer. Somewhat like fprint vs vfprint. All we need to do is rename the second fltk3::alert to fltk3::va_alert and the ambiguity is gone. It's interesting that va_list expands to char*. ts ts. Yup - that's got it, r8834 now builds fine up until... Compiling shape.cxx... Linking shape.exe... === making test1 === make[1]: *** No rule to make target `Preferences.h', needed by `unittests.o'. Stop. make: *** [all] Error 1 SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev ___ 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 20.06.2011, at 16:43, Michael Sweet wrote: 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); 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? ___ 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
Ahrgh. Go into the fltk directory and run make depend. I keep forgetting to do that before I run svn commit and after make clean. The makedepend file appears to be configured - so I just hand edited it to fix the one typo and commited that, it then seems to work just fine right up until colbrowser as expected (as you reported earlier). SELEX Galileo Ltd Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England Wales. Company no. 02426132 This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ___ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
Re: [fltk.development] [fltk.commit] [Library] r8835 - branches/branch-3.0/test1
On 20.06.2011, at 16:41, fltk-dev@easysw.com wrote: Author: ianmacarthur Date: 2011-06-20 07:41:23 -0700 (Mon, 20 Jun 2011) New Revision: 8835 Log: Trivial mod to makedepend to get test1 folder to build on Msys/mingw. Now builds as far as colbrowser... Yes, colbrowser is where it's stuck right now. This is because some of the virtual functions in Fl_Browser_ are not implemented, which means that gcc can't crete the vtable. But other test programs later in the test directory do compile as well. ___ 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 20.06.2011 17:42, MacArthur, Ian (SELEX GALILEO, UK) wrote: Ahrgh. Go into the fltk directory and run make depend. I keep forgetting to do that before I run svn commit and after make clean. The makedepend file appears to be configured - so I just hand edited it to fix the one typo and commited that, it then seems to work just fine right up until colbrowser as expected (as you reported earlier). No, it's not 'configured'. What Matt wrote is (AFAICT?) partly correct. Although it could be generated by the make process, we (someone?) decided to put it under svn. To be correct it should be generated on a Linux system (with all other platform dependent dependencies ;-) edited in the Makefile), so that it can be used by end users as-is. I'm frequently updating the makedepend files in the fltk 1.3 branch, but yes, they should be updated and committed in fltk 3 branch as well. I do suspect, however, that running make depend after make clean wouldn't work, since this would remove the fluid-generated files, and one of them is: preferences.h, tada! ;-). Albrecht ___ 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 20.06.2011, at 18:11, MacArthur, Ian (SELEX GALILEO, UK) wrote: I'm frequently updating the makedepend files in the fltk 1.3 branch, but yes, they should be updated and committed in fltk 3 branch as well. I do suspect, however, that running make depend after make clean wouldn't work, since this would remove the fluid-generated files, and one of them is: preferences.h, tada! ;-). OK, but... The file at issue is not preferences.h (the test) but in fact ../fltk3/Preferences.h (the fltk3 header file of a similar name!) Yes, that's exactly right. 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. But I will get to that when everything else works. - Matthias ___ 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
Attached file gleam-fltk-1.3.x-rev8836.patch...
Link: http://www.fltk.org/str.php?L2672
Version: 1.3-featureIndex: src/fl_gleam.cxx
===
--- src/fl_gleam.cxx(revision 0)
+++ src/fl_gleam.cxx(revision 0)
@@ -0,0 +1,158 @@
+//
+// Gleam drawing routines for the Fast Light Tool Kit (FLTK).
+//
+// These box types provide a sort of Clearlooks Glossy scheme
+// for FLTK.
+//
+// Copyright 2001-2005 by Colin Jones.
+//
+// This library is free software; you can redistribute it and/or
+// modify it under the terms of the GNU Library General Public
+// License as published by the Free Software Foundation; either
+// version 2 of the License, or (at your option) any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+// Library General Public License for more details.
+//
+// You should have received a copy of the GNU Library General Public
+// License along with this library; if not, write to the Free Software
+// Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
+// USA.
+//
+// Please report all bugs and problems on the following page:
+//
+// http://www.fltk.org/str.php
+//
+
+// Box drawing code for an obscure box type.
+// These box types are in seperate files so they are not linked
+// in if not used.
+
+#include FL/Fl.H
+#include FL/fl_draw.H
+
+static void gleam_color(Fl_Color c) {
+ if (Fl::draw_box_active()) fl_color(c);
+ else fl_color(fl_inactive(c));
+}
+
+static void shade_rect_up(int x, int y, int w, int h, Fl_Color bc, float th) {
+ // Draws the shiny
+ int h_top = h/4;
+ int h_bottom = h/6;
+ float h_flat = h-(float)(h_top+h_bottom);
+ gleam_color(bc);
+ fl_rectf(x, y+h_top, w, h_flat+1);
+
+ float step_size_top=0.10;
+ float step_size_bottom=0.10;
+ int j = 0;
+ step_size_top = (1.0/(float)h_top);
+ step_size_bottom = (1.0/(float)h_bottom);
+
+ // This loop generates the gradient at the top of the widget
+ for (float k = 1; k = 0; k -= step_size_top){
+j++;
+gleam_color(fl_color_average(fl_color_average(bc, FL_WHITE, th), bc, k));
+fl_line(x, y+j, x+w-1, y+j);
+ }
+ // This loop generates the gradient at the bottom of the widget
+ for (float k = 1; k = 0; k -= step_size_bottom){
+ j++;
+ gleam_color(fl_color_average(bc, fl_color_average(bc, FL_WHITE, th), k));
+ fl_line(x, y+j+h_flat-3, x+w-1, y+j+h_flat-3);
+ }
+}
+
+static void shade_rect_down(int x, int y, int w, int h, Fl_Color bc, float th)
{
+ // Draws the shiny
+ int h_top = h/4;
+ int h_bottom = h/6;
+ float h_flat = h-(float)(h_top+h_bottom);
+ gleam_color(bc);
+ fl_rectf(x, y+h_top, w, h_flat+1);
+
+ float step_size_top=0.10;
+ float step_size_bottom=0.10;
+ int j = 0;
+ step_size_top = (1.0/(float)h_top);
+ step_size_bottom = (1.0/(float)h_bottom);
+
+ // This loop generates the gradient at the top of the widget
+ for (float k = 1; k = 0; k -= step_size_top){
+j++;
+gleam_color(fl_color_average(fl_color_average(bc, FL_BLACK, th), bc, k));
+fl_line(x, y+j, x+w-1, y+j);
+ }
+ // This loop generates the gradient at the bottom of the widget
+ for (float k = 1; k = 0; k -= step_size_bottom){
+ j++;
+ gleam_color(fl_color_average(bc, fl_color_average(bc, FL_BLACK, th), k));
+ fl_line(x, y+j+h_flat-3, x+w-1, y+j+h_flat-3);
+ }
+}
+
+static void frame_rect_up(int x, int y, int w, int h, Fl_Color bc, float th) {
+ // Draw the outline around the perimeter of the box
+ gleam_color(fl_color_average(bc, FL_WHITE, th));
+ fl_line(x+1, y, x+w-1, y); //Go across.
+ fl_line(x, y+h-1, x, y+1); //Go to top
+ gleam_color(fl_color_average(bc, FL_BLACK, th));
+ fl_line(x+1, y+h, x+w-1, y+h); //Go across again!
+ fl_line(x+w, y+h-1, x+w, y+1); //Go to top
+}
+
+static void frame_rect_down(int x, int y, int w, int h, Fl_Color bc, float th)
{
+ // Draw the outline around the perimeter of the box
+ gleam_color(fl_color_average(fl_darker(bc), FL_BLACK, th));
+ fl_line(x+1, y, x+w-1, y); //Go across.
+ fl_line(x, y+h-1, x, y+1); //Go to top
+ gleam_color(fl_color_average(bc, FL_WHITE, th));
+ fl_line(x+1, y+h, x+w-1, y+h); //Go across again!
+ fl_line(x+w, y+h-1, x+w, y+1); //Go to top
+}
+
+static void up_frame(int x, int y, int w, int h, Fl_Color c) {
+ frame_rect_up(x, y, w-1, h-1, fl_darker(c),0.35);
+}
+
+static void up_box(int x, int y, int w, int h, Fl_Color c) {
+ shade_rect_up(x+1, y, w-2, h-1, c, 0.25f);
+ frame_rect_up(x, y, w-1, h-1, fl_darker(c),0.35);
+}
+
+static void thin_up_box(int x, int y, int w, int h, Fl_Color c) {
+ shade_rect_up(x+1, y, w-2, h-1, c, 0.65f);
+ frame_rect_up(x, y, w-1, h-1, fl_darker(c),0.85);
+}
+
