| |
| #1 | etorres
13:52 Jun 17, 2011 |
| Updated gleam patch to work with the main branch FLTK 1.3.x. I think this patch should be included in FLTK 1.3. This is only the patch to include Gleam in FLTK. Gleam itself can be found at http://ergoeclectic.com/projects/fltk-gleam.html. | |
| |
| #2 | greg.ercolano
09:27 Jun 19, 2011 |
| This sounds really cool.. and the patch is small and the code is small.
Sounds great -- my initial reaction is +1 to add it, but I want to withhold comment until I have time to actually try it out.
I'll try to play with it soon, as I hope other devs will as well. | |
| |
| #3 | etorres
16:40 Jun 19, 2011 |
| I am working on Gleam to make it more FLTK-like feel and look, and considering more modern theme appealing. | |
| |
| #4 | etorres
00:42 Jun 20, 2011 |
| 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 | |
| |
| #5 | ianmacarthur
02:07 Jun 20, 2011 |
| 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 | |
| |
| #6 | mike
07:34 Jun 20, 2011 |
| For a strict adherence to the CMP, all features need to be pushed to 1.4 or later. | |
| |
| #7 | etorres
15:03 Jun 20, 2011 |
| I have added a complete fl_gleam patch for FLTK-1.3.x rev8836. It contains gleam with a better shading theme. The thin option of the widgets is implemented. There is a demo called gleam in the test directory, gleam is also included in the demo form.
There is a new screen shot at:
https://sites.google.com/site/eetorres/fl_gleam
The one labeled fl_gleam-4.1.cxx | |
| |
| #8 | ianmacarthur
02:42 Jun 21, 2011 |
| Comments on revised patch:
- the copyright attribution in fl_gleam.cxx needs to be thought about; it attributes Colin Jones as the copyright holder - this is unlikley to be accpetable for fltk, and is also probably wrong - if we have not used any of his code directly (and I imagine we have not) then it is probably more appropriate to acknowledge that the design was inspired by him, rather than attributing the copyright in the sources to him.
- I'm still not happy about the changes to Fl_get_system_colors.cxx as regards setting the default colours.
- if the test program is created by fluid it is approporaite to only configure the .fl file and generate the .cxx/.h at build time; they do not need to be (usually should not be) configured (fluid and the fltk lib itself violate this rule in a few places since they are built before fluid can exist - all test programs are built after fluid exists and so should always use fluid.) | |
| |
| #9 | etorres
07:18 Jun 21, 2011 |
| This is not Colin's code. I rewrote the whole drawing code, FLTK only needs to acknowledge Colin for the inspiring work. | |
| |
| #10 | matt
02:55 Jun 23, 2011 |
| I am considering making Gleam 3 the default look for FLTK 3. Would that be OK? | |
| |
| #11 | mike
09:27 Jun 23, 2011 |
| 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. | |
| |
| #12 | etorres
13:19 Jun 23, 2011 |
| The reason why I remove the shiny from the text area, it is because it makes it a bit hard to read the text. I think it can be eye tiring with the time. The buttons of Gleam 3.0 look great but not the boxes. I think the thin box of gleam 4.1 does a better job in this case. Maybe it is better idea to keep both. | |
| |
| #13 | etorres
14:40 Jun 23, 2011 |
| Another good think of gleam 4.1 it is that with a little bit more coding can be themed, so everyone will have control on the shading. Then gleam 3.0 and 4.1 can be just themes, I think is worth. I would do that if you agree. You can leave either or a mix by default for FLTK. | |
| |
| #14 | etorres
20:39 Jun 28, 2011 |
| New improvements to Gleam in the patch gleam-4.2-fltk-1.3-rev8842.patch. I have debugged and cleaned up the code. | |
| |
| #15 | etorres
21:36 Jun 28, 2011 |
| Check the screen shot of fl_gleam-4.2:
https://sites.google.com/site/eetorres/fl_gleam | |
| |
| #16 | etorres
21:26 Jun 30, 2011 |
| I have put full gradient, I think it really looks better. | |
| |
| #17 | etorres
17:49 Aug 04, 2011 |
| Updated Gleam patch to Gleam 4.3. | |
| |
| #18 | xentalion
09:54 Sep 09, 2011 |
| Hello all,
I'm the original developer of the FLTK Gleam patch, and I just wanted to explain a bit of my reasoning for doing things.
The patch does modify the FL_get_system_colours to change the default colours, but I can easily remove this. I originally changed this because I also found that the gleam was a bit hard on the eyes otherwise, but I've more recently figured out how to change the widget colours through the Xresources.
The reasoning for the gradient in the middle is so that it fits in better with the Clearlooks GTK+ theme and other widget schemes use on my desktop.
Thanks,
Colin | |
| |
| #19 | matt
09:32 Oct 01, 2011 |
| Thanks very much for sending this in. I will consider it for the next version. Right now, we have to release two urgent fixes in 1.3.1 and 1.3.2 . After that, I am open to new features.
Again, thanks. Looks very pretty! | |
| |
| #20 | etorres
12:59 Oct 02, 2011 |
| Good to know. I am working in a slightly more rounded corners version, I am keeping the code small and fast as possible, as the original GLEAM does! I am removing the part that modify Fl_get_system_colors.cxx. I will only add the .fl and then let FLUID generate the .cxx/.h at building time. | |
| |
| #21 | etorres
09:46 Dec 10, 2011 |
| Patch updated. The modification to Fl_get_system_colors.cxx were removed. The gleam test program is created by fluid at build time. | |
| |
| #22 | etorres
09:48 Dec 10, 2011 |
| The only necessary file is fl_gleam-4.3.3-fltk-1.3-rev9209.patch to use the Gleam theme. | |
| |
| patchscheme.diff includes patches for both gleam and grad1 themes and works against FLTK version 1.3.2. | |
| |
| #24 | etorres
13:00 Mar 07, 2013 |
| Here a Gleam 4.3 patch for the fltk-1.3.2. Here the steps to use it;
1) get fltk-1.3.2-source.tar.gz
2) untar it
$ tar -xvzf fltk-1.3.2-source.tar.gz
3) copy the patch file fltk-1.3.2-gleam-4.3.patch to the fltk-1.3.2 directory
4) patch it:
$ patch -p0 < fltk-1.3.2-gleam-4.3.patch
5) then compile it with make and run the example:
$ ./test/gleam
6) enjoy.... | |
| |
| #25 | greg.ercolano
13:20 Mar 07, 2013 |
| Hi Edmanuel,
Thanks for the great work -- can I suggest attaching a screenshot
showing what glean does? It would help motivate a merge. | |
| |
| #26 | greg.ercolano
13:36 Mar 07, 2013 |
| Nevermind; I've pasted a screenshot here
showing the demo both with and without gleam.
I've applied your patch, and demo works well.
Nice small patch.. I like it for that alone ;) | |
| |
| #27 | greg.ercolano
13:45 Mar 07, 2013 |
| Question about this patch: I noticed this line in the patch
that adds the scheme "gleam" to fluid:
+ Fl::scheme("gleam");
..but support of the Fl::scheme() name 'gleam' is not actually
implemented by the patch, is that correct?
From what I can tell by a brief look at the patch, it seems to
show it adds the new FL_GLEAM* box types, but I don't think
I see it handling Fl::scheme() yet.. is that correct?
For instance, I tried running: test/unittests -s gleam
..and didn't see a difference. | |
| |
| #28 | etorres
14:01 Mar 07, 2013 |
| Yes, you are right, I will fix that asap!
// + Fl::scheme("gleam");
//..but support of the Fl::scheme() name 'gleam' is not actually
//implemented by the patch, is that correct?
//From what I can tell by a brief look at the patch, it seems to
//show it adds the new FL_GLEAM* box types, but I don't think
//I see it handling Fl::scheme() yet.. is that correct? | |
| |
| #29 | etorres
14:41 Mar 07, 2013 |
| Thank Greg for your feedback. I just updated the patch, hopefully Fl::scheme() is working now. | |
| |
| #30 | greg.ercolano
02:04 Mar 08, 2013 |
| Note: STR #2675 may be in conflict; it is suggesting a patch
that is a combo of gleam and grad schemes.
Both STRs are currently active; L Michaels just updated that
patch today.
I guess we need to either combine or sync these two STRs.
BTW, would like to suggest we integrate your gleam test program
into the unittests program, and set it up so that can test ALL
of our schemes (so we can check for artifacts across platforms).
This would also avoid us having to create new Visual Studio
project files for the new test program, and avoid adding the new
project to all the fltk.dsw/fltk.sln files. | |
| |
| #31 | greg.ercolano
09:25 Mar 08, 2013 |
| > BTW, would like to suggest we integrate your gleam test program
> into the unittests program..
Oh, and I'll do that -- don't worry, not asking you to do it for us ;)
Just letting you know we might implement it that way. | |
| |
| #32 | etorres
09:31 Mar 08, 2013 |
| // Oh, and I'll do that -- don't worry, not asking you to do it for us ;)
// Just letting you know we might implement it that way.
Anyway, I am glad to help, but great! :D | |
| |
| #33 | greg.ercolano
09:58 Mar 08, 2013 |
| Checking your latest patch, and will start work on modifying unittests to integrate your test program into it.
I have a vote up on fltk.development asking the other devs if they'll vote to apply this patch. If we get a few +1's, it'll become part of FLTK. | |
| |
| #34 | greg.ercolano
10:32 Mar 08, 2013 |
| Ran a few of the widgets through the gleam scheme.. looks great!
One comment; when widgets are sized large, the bg gradient at
especially the top edge gets large enough that lines of dark text
become lost due to lack of contrast.
(See attached gleam-darkness.png snapshot)
A possible solution, hoping you can implement: perhaps when the
gradient area's height is larger than some amount, the gradient
doesn't scale quite as large, so that a line of text at the top
can still be readable? Or perhaps scale the brightness of the
starting edge color a bit when the area height exceeds e.g.
100 pixels or some such. | |
| |
| #35 | etorres
10:43 Mar 08, 2013 |
| // A possible solution, hoping you can implement: perhaps when the
// gradient area's height is larger than some amount, the gradient
// doesn't scale quite as large, so that a line of text at the top
// can still be readable? Or perhaps scale the brightness of the
// starting edge color a bit when the area height exceeds e.g.
// 100 pixels or some such.
I will work on a fix using either of your approaches. | |
| |
| #36 | greg.ercolano
12:02 Mar 08, 2013 |
| Attaching a patch for test/unittests that implements the test/gleam program code into it. (unittests-schemes.patch)
Also, attached screenshot (unittest-mods.png) showing the result. | |
| |
| #37 | etorres
18:32 Mar 08, 2013 |
| Here the fixed patch, the first approach worked like a charm, thanks Greg. I removed the test program, so to test with: unittests -s gleam | |
| |
| #38 | AlbrechtS
04:19 Mar 09, 2013 |
| BUG REPORT
----------
System: Linux Ubuntu 12.04
FLTK 1.3.2 svn -r 9834
with patch http://www.fltk.org/strfiles/2672/fltk-1.3.2-gleam-4.3c.patch
(uncommented gleam entries in test/unittest_gleam.fl/.cxx, but this probably doesn't matter, but makes testing easier).
Warning: testing this hogs the cpu, and the app becomes unresponsive - I could not even close the app with the window's close button. CTRL-C from the console that started the app can stop it though.
Test: run test/unittests -s gleam, then go to the scroll size test and try to move the top right "A: Scroll Size" scrollbar. The app hangs. Stop it.
Start again, w/o "-s gleam", go to the same test, move that scrollbar to a value like 10 (that works), select "schemes test", select the gleam scheme, select "scrollbar size" test again, click on the slider in the same scroll bar, and move it step by step with the left arrow key down until the app hangs. This happens when you try to go from 2 to 1, at least for me. Assumption: box drawing goes into an endless loop when the box width is too small. | |
| |
| #39 | AlbrechtS
04:32 Mar 09, 2013 |
| Other than the mentioned bug, I like this gleam patch, but would like to ask for your opinions. Although it looks good, I can't seem to "interpret" the boxes well as up and/or down boxes.
ISTR that I once learned that we (our brain) usually interpret(s) flat drawings as 3-dimensional according to some light effects, so that our impression of "up and down" is best, if the light seems to come from top left. This is used in the standard box types, and it seems to be utilized in widgets of other apps (e.g. firefox).
The clue is that...
- for an UP box, the top and left side are brighter, the bottom and right side are darker
- for a DOWN box, this is just the opposite.
In the gleam patch, there is only the top-down gradient (not left-right), but this would be okay, IMHO. However, could we (Edmanuel ?) try to change the patch so that it is like described above ? I'd like to see that as an example, to be able to decide if this is better.
OTOH, if this is not intended, then I'm also okay with the patch as-is. Just wanted to ask for a possible improvement or other opinions. | |
| |
| #40 | AlbrechtS
04:42 Mar 09, 2013 |
| Well, here are more test results. In the test/unittests "schemes test" (BTW: big thanks to Edmanuel for the code and Greg for inclusion - this is a nice new test) I see:
(1) The white selection box(es) seem too dark at the top and at the bottom. Wouldn't it be better to make them only some kinda gray, but not black at the border? In general: should the darkest color be something like fl_darker(original_color, FL_BLACK, some-value) instead of FL_BLACK? Note that I wrote this w/o looking at the code, I may be wrong, but this is what it looks like.
(2) The colored buttons become black'n'white (gray) when clicked, i.e. they lose ther colors. Wouldn't it be better if they only changed their up-down-box, but not the color? Again, this is what I see, not something I read in the code. | |
| |
| #41 | etorres
09:24 Mar 09, 2013 |
| Fixed the bug reported by Albrecht (04:32 Mar 09, 2013)
The gleam uses front light 3d effect. I didn’t work on that for a while, but I will work in some improvements.
I will include left-right gradients, I think it would be nice and it will be small piece of code.
IMHO, I think the front light effect looks more modern.
// (1) The white selection box(es) seem too dark at the top and at the bottom.
I have made some improvement to this.
// (2) The colored buttons become black'n'white (gray) when clicked, i.e. they lose ther colors. Wouldn't it be better if they only changed their up-down-box, but not the color? Again, this is what I see, not something I read in the code.
This seems to be the default behaviour of FLTK. | |
| |
| #42 | AlbrechtS
08:08 Mar 10, 2013 |
| Thanks for fixing the bug so quickly, I can confirm that it works now.
WRT "front light 3d effect" being "more modern": I'm not a 3d expert, and I don't know much about what is "modern" in GUI design. My PERSONAL opinion is that I don't like this because I don't get a correct "3d impression". However, as I said before, if this is intendend, and if others want this scheme to be included, then I won't object. Maybe it needs some more fine tuning, but we should first think about including it in the FLTK core before there is too much work done... Thanks for your efforts, Edmanuel.
Looking forward to seeing the left-right gradients, too.
I can see the difference in white box backgrounds in your new patch (4.3d), and I believe it's better now, but IMHO it could still be a little brighter...
I can also confirm that colored buttons become black..gray..white (or get the default system color?) when pressed in other schemes (gtk+, none, plastic), but I wonder why this is so and whether it could be changed (a) generally, or (b) for the gleam scheme? | |
| |
| #43 | etorres
17:23 Mar 10, 2013 |
| // Looking forward to seeing the left-right gradients, too.
Done, but you need to change shade_rect_top_bottom to shade_rect_left_right in src/fl_gleam.cxx
// I can see the difference in white box backgrounds in your new patch (4.3d), and I believe it's better now, but IMHO it could still be a little brighter...
Now it is a bit brighter. | |
| |
| #44 | etorres
12:19 Mar 16, 2013 |
| Gleam 4.3 against fltk-1.3.x-r9835 with some improvements as suggested by Albrecht. | |
| |
| #45 | greg.ercolano
23:47 Aug 11, 2013 |
| This patch is looking good.
Albrecht; you seemed to be testing this quite a bit..
any further comments?
Will try to find some time in the next week to give this
a real once over, and then apply to current. | |
| |
| #46 | greg.ercolano
23:55 Aug 11, 2013 |
| Regarding the bump to 1.4; assuming there's no ABI issues,
would it not be safe to put into 1.3.x?
The fact it's a separate theme really means its code won't be used
by any existing app unless that app goes out of its way to make use
of this new theme, so it's pretty safe.
Also, at the snails pace we seem to be putting out releases,
I'm not sure I'll be alive long enough to see 1.4 ;) so would like
to see this in the next 1.3.x release. (Remember linus's words:
"release early, release often")
I want to carefully investigate ABI issues, and assuming they can be avoided, it should be clear sailing.
And even if there were ABI issues (I haven't looked), we do have those
new ABI macros to make adding it "safe" for those that want it. | |
| |
| #47 | AlbrechtS
05:15 Sep 01, 2013 |
| Greg wrote:
> Albrecht; you seemed to be testing this quite a bit..
> any further comments?
No, good to go for me.
> Will try to find some time in the next week to give this
> a real once over, and then apply to current.
I'd appreciate that.
> Regarding the bump to 1.4; assuming there's no ABI issues,
> would it not be safe to put into 1.3.x?
Yes, since it extends the array of schemes, I think it would be okay, if there are no ABI issues. The only problem I can see with others' code is that someone might have his own schemes so that the schemes array(s) would have to be changed. But that is independent of the FLTK version anyway. | |
| |
| #48 | greg.ercolano
20:29 Feb 24, 2014 |
| OK, patch applied.
Some small mods to add doxygen docs for the box types.
Made some hand tweaks to add fl_gleam.cxx to the Visual Studio
IDE files.
Used Xcode 3 to add it to the Xcode3 project files;
couldn't hand edit those damn Xcode hashes. :(
All that's left is to use Xcode 4 to add fl_gleam.cxx
to the Xcode4 project file.. leaving this open for that. | |
| |
| #49 | greg.ercolano
20:31 Feb 24, 2014 |
| Adding r10113 to the Fix Version.. | |
| |
| #50 | greg.ercolano
20:15 Apr 28, 2014 |
| Fixed in Subversion repository.
According to manolo's recent commit in r10131, I believe that solves
the left over issue with the Xcode 4 files mentioned at the end of
comment #48, so I'm closing this with his rev as the fix version.
(Looks like Manolo has a later commit r10133 that includes a README
mod, but I'm going to cite r10131 as the fix for the code)
If any issues still exist with the fl_gleam addition,
please open a new STR.
Thanks to everyone for this patch, especially etorres for sticking
with us for the last several years getting his patch properly
implemented. Sorry we're so slow. | |
