STR #2675: Patch for a new "oxy" theme of FLTK 1.3 (with gradient).

STR #2675

Application:	FLTK Library
Status:	2 - Closed w/o Resolution
Priority:	1 - Request for Enhancement, e.g. asking for a feature
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Core Library
Summary:	Patch for a new "oxy" theme of FLTK 1.3 (with gradient).
Version:	1.4-feature
Created By:	kdiman
Assigned To:	AlbrechtS
Fix Version:	None
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

Trouble Report Comments:

#1	kdiman 22:46 Jul 04, 2011

Hi guys! I've wrote the new theme for FLTK 1.3. It's supporting gradient, and good-looked boxes and frames + boxes with gradient specially for buttons... For applying scheme to your applications you need call it's: Fl::scheme("Grad1"); FLUID is supporting it too. License is LGPL. Perhaps it will like to you... Screenshot of fluid is here (theme preview): http://www.imgplace.com/viewimg39/5411/88fluidgradient.png PS: Patch was made for fltk-1.3.x-r8800. PSS: `Grad1' is from word of `gradient' and number `1' is numeric identity. Best regards.

#2	kdiman 08:25 Jul 08, 2011

new in the patch: 1) corrected drawing shadows 2) corrected list boxtype in sources 3) fixed size of ROUND_BOX_* for radio buttons and see grad1.fl - file of project for fluid screenshot: http://www.imgplace.com/viewimg192/1842/76fluidgradient3.png The Best Regards.

#3	kdiman 08:18 Jul 12, 2011

correctings in new patch (12 july 2011): 1) drawing of RADIO/CHECK buttons in a menus 2) drawing of focus on Fl_Widget 3) drawing of focus on elements of Fl_Browser 4) drawing of focus on Fl_Choice and changed his divide lines and arrow (fixed size of area arrow too), and popup menu have been shown under box now

#4	kdiman 07:37 Sep 17, 2011

Patch from 17 september of 2011 year. Fixed drawing angles in DOS (set up it to 0). - Georg Potthast was reported me about it. Now this patch is applying clean for current release of fltk-1.3 is r9038.

#5	matt 13:01 Sep 28, 2011

Very beautiful! I will check the source code when all bugs are fixed.

#6	matt 09:34 Oct 01, 2011

Thanks very much for sending this in. Like "Gleam", 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.

#7	kdiman 09:51 Oct 01, 2011

Matthiasm wrote: > 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. When will it done? 1 year or more? ;) Regards.

#8	matt 09:57 Oct 01, 2011

No. I promised that releases will now be much quicker than in 1.1 . As you see from the bug list, the next 1.3 is almost ready. I will release 1.3.1 this week because 1.3.0 has a bug that may make pulldown menus hang. After that, and when all bugs are taken from the list (7 or so), I will release 1.3.2rc1. If no new bugs are found, I will release 1.3.2final two weeks later. Then we will need to decide which items we take form the 1.4 list into 1.3.3 - or if the next version will be 1.4. Or if we stop the 1.x.x branch here and focus on 3.0.0, which could of course also receive your patch. Does that sound reasonable?

#9	kdiman 10:05 Oct 01, 2011

Yes. I am understand about versions of FLTK now, I think... Thanks. Regards.

#10	kdiman 10:14 May 22, 2012

Hi all. I have made the grad1 theme lessen - 350 strings of code (it was reduced). patch by 22 may of 2012 year for fltk-1.3.x-r9525. Best regards.

#11	lm 04:43 Mar 07, 2013

patchscheme.diff includes patches for both grad1 and gleam themes and works against FLTK version 1.3.2. Use with patch -p2 < patchscheme.diff

#12	greg.ercolano 01:56 Mar 08, 2013

Note: STR#2672 (patch for gleam) I think conflicts with this patch, if both are trying to implement gleam. Both STR's are currently active; Edmanuel Torres just updated his gleam patch in that STR yesterday. I was about to take a vote on fltk.development for applying his patch in that STR, as it's very small and simple, though I'd like to change things so that his test/gleam program is moved into being part of the test/unittests program, to avoid having to create a new test program. I think unittests can inherit his test code, and be modified to demo all the schemes we support for artifacts.

#13	greg.ercolano 09:49 Mar 08, 2013

Taking ownership, changing state New -> Active.

#14	greg.ercolano 11:34 Mar 08, 2013

Testing the latest patch -- how do I test it? I tried building fltk and then running e.g.: test/buttons -scheme grad1 test/buttons -scheme gleam ..but not seeing any changes to the look of the interface. Might be missing support for Fl::scheme().

#15	lm 05:21 Aug 09, 2013

> test/buttons -scheme grad1 > test/buttons -scheme gleam >..but not seeing any changes to the look of the interface. >Might be missing support for Fl::scheme(). First, if one's going to apply a theme, the application must be designed to make use of it and not hard-code the look of the controls. Second, the FLTK code applies a theme using the FLTK_SCHEME environment variable. When I set that appropriately and use it with certain FLTK applications, I see differences in the appearance.

#16	greg.ercolano 23:25 Aug 11, 2013

Please note: on Mar 7th, etorres's STR#2672 patch didn't support Fl::scheme(), but Mar 8th he added support for it because it needed it. I believe the attached patch (dated Mar 7th) has the same problem his patch did on Mar 7th; lack of support for Fl::scheme(). When added, any 3rd party app (as well as the FLTK demos) will be able to make use of the new theme with no code changes. > First, if one's going to apply a theme, the application must be > designed to make use of it and not hard-code the look of the > controls. No. An FLTK app should not have to be modified to make use of FLTK schemes. The test/buttons demo has no theme specific code in it, yet it supports both the "plastic" and "gtk+" FLTK themes respectively by invoking: test/buttons -scheme plastic test/buttons -scheme gtk+ The gleam patches from STR#2672 (dated Mar 8th or newer) will also work by invoking: test/buttons -scheme gleam It will inherit the new theme, even though his patch makes no changes to the test/buttons.cxx code. Other 3rd party apps can make use of the new theme similarly with no code changes needed. (Just a re-link) > Second, the FLTK code applies a theme using the FLTK_SCHEME environment variable. > When I set that appropriately and use it with certain FLTK applications, > I see differences in the appearance. Which FLTK applications? Any new FLTK theme really must make use of Fl::scheme(). When it does, "test/buttons -scheme <name>" should show it, a good test that indicates 3rd party apps will be able to use it as well without code mods. Please see STR#2672 for changes etorres made between the Mar 7 and Mar 8 to supports Fl::scheme(). Similar mods are needed here for both themes.

#17	kdiman 05:47 Oct 02, 2013

Dear sirs. I've improved the theme for FLTK 1.3.x (needs only some job for create patch) The theme designed likeness KDE::Oxygen . preview picture: http://postimg.org/image/5d6oequnf Is it needed or don't ? PS: I've find out a little bug in the Fl_Round_Button (r9930): background is not redrawing with widget's color not white under the button. You can reproduce it: declare few buttons (distance must be sufficient between them), and click on first button, click on another, etc ... -- The best regards.

#18	kdiman 05:35 Oct 03, 2013

The patch is created and attached (oxygen_fltk-1.3.0(03.10.2013).patch) for current version 1.3.0 Using the theme: [CODE=CPP] int maint(){ Fl::scheme("oxy"); Fl::get_system_colors(); // etc } [/CODE] -- Have a nice day.

#19	kdiman 18:03 Oct 04, 2013

Was corrected color of arrow in menu when item has event's FL_ENTER (for oxy theme, second patch).

#20	kdiman 19:10 Oct 04, 2013

added patches for 1.3.1 and 1.3.2 version of FLTK

#21	kdiman 16:59 Oct 31, 2013

Dear sirs. I have done draw-clipping text for Fl_Browser, Fl_Check_Browser, Fl_Tree. Patches for 1.3.0, 1.3.1 and 1.3.2 are attached before this post. link to preview: http://postimg.org/image/nk25vt7tz/ But the Fl_Tree has some incorrect redrawing (there is drawing first items, after is scrollbar, which can not be there while items were drawn with(out) calculated width of scrollbar). I do not know how to fix it now, if you know - you are well come or give me tips. For reproduce the behaviour: the root tree must have items , number which are in sum has height more than the Fl_Tree widget (for visible scrollbar), and then: while ( true ) { click_on_openicon_of_ROOT_element(); click_on_ROOT_element(); click_on_closeicon_of_ROOT_element(); click_on_ROOT_element(); } -- Have a nice day.

#22	greg.ercolano 08:16 Nov 03, 2013

Hmm, I might need more info to look into the tree problem. Is there an example program I can use to replicate? Or can e.g. examples/tree-simple be used to replicate? If some mods are needed to replicate, can you include a diff(1) showing what mods are needed to replicate?

#23	greg.ercolano 08:35 Nov 03, 2013

I'm attaching the image 'oxy_preview.jpg' you posted to http://postimg.org/image/nk25vt7tz/ here to this STR so we don't need to rely on external links, which have a way of going 'stale' when one needs them most.. ;) Feel free to include such relevant screenshot images to the STR's.

#24	kdiman 14:27 Nov 04, 2013

Dear Greg. Thanks for yours reply and help. I have attached graphically displayed the "wrong drawing Fl_Tree items" (Fl_Tree.jpg) and menu.fl (file project for testing) . PS : I am not expert in copyright, so you can and/or should to change copyright-headers of *.h,*.cxx in the modified files by me for the theme (fl_oxy.h, fl_oxy.cxx etc) AS DEMANDED for FLTK project & license... -- The best regards.

#25	kdiman 14:56 Nov 04, 2013

Dear Greg. Why Fl_Tree has not horizontal scrollbar ? -- The best regards.

#26	greg.ercolano 18:40 Nov 05, 2013

> I have attached graphically displayed the "wrong drawing > Fl_Tree items" (Fl_Tree.jpg) and menu.fl Great. So I can replicate the problem with your app only when the patch is applied. > Why Fl_Tree has not horizontal scrollbar ? I just never got around to it..! I don't think it'd be hard to add, just ran out of time while writing it, and haven't revisited. Since I'll be looking at the code now, will see if I can add it.

#27	greg.ercolano 21:59 Nov 05, 2013

Regarding the problem with the mis-drawn item: the problem appears to be the fl_push_clip()/fl_pop_clip() that was added to Fl_Tree_Item.cxx on or around line 758. Comment out those two lines, and it should work normally. This causes it to draw the item beyond the bar, so that the bar would draw over it if it is visible. The current logic of the code kinda depends on this. (See below) Also note: the code added to Fl_Tree.cxx that tries to detect the _vscroll->visible() during the _root->draw(..) call is done before the _vscroll visibility has been calculated (that happens several lines below the call to _root->draw()) so the value at that time will be from the /last/ redraw, and thus stale. So I'd comment that change out as well. Currently Fl_Tree's draw logic depends on drawing with the assumption the scrollbar is not visible, and then after drawing, it knows whether it needs to show the scrollbar or not, and then draws the bar over the items to obscure them. Fl_Tree's draw logic needs some mods to first do as pass at the calculations /before/ doing the drawing (currently it does not) so that it knows how high and wide the visible area is to determine if scrollers are needed or not. The code needs to avoid doing more than one full pass at all the data, since the tree can be quite huge; you don't want to do a complete calculation on the tree more than once, or at all if you can avoid it. I think I have an offline version of Fl_Tree that does this, but was in the middle of debugging it when I was forced to work on something else, and had to drop it to move on to other things.. need to revisit it.

#28	greg.ercolano 22:11 Nov 05, 2013

BTW, the oxy scheme looks great -- I like it!

#29	kdiman 12:02 Nov 06, 2013

> Regarding the problem with the mis-drawn item: the problem > appears to be the fl_push_clip()/fl_pop_clip() that was > added to Fl_Tree_Item.cxx on or around line 758. Yes. I've been added them to there for esthetic exterior (text does not must overrun item's selection box). > I think I have an offline version of Fl_Tree that does this, but > was in the middle of debugging it when I was forced to work on something > else, and had to drop it to move on to other things.. need to revisit it. It would be good, if you will include that functional into core of FLTK. > BTW, the oxy scheme looks great -- I like it! Thanks! I have been want for apps based on FLTK has goodlooking and attractiveness (for commerce/free/opensource apps). But job over the scheme is not full complete. I need some time for it... PS: Greg, thanks a lot for your exploring the problem... -- The best regards.

#30	greg.ercolano 16:24 Nov 06, 2013

>> Regarding the problem with the mis-drawn item: the problem >> appears to be the fl_push_clip()/fl_pop_clip() that was >> added to Fl_Tree_Item.cxx on or around line 758. > Yes. I've been added them to there for esthetic exterior > (text does not must overrun item's selection box). I see. Well, let's not let that stop it getting checked in; the problem has more to do with Fl_Tree's draw calculations needing retooling than your mods. So I'd say ignore the problem for now, and let's try to get the code checked in. Once the mods are in the core, the visual problem will be solved later when Fl_Tree's draw calculations are restructured. > But job over the scheme is not full complete. > I need some time for it... Would you rather we wait to merge the patch into svn current, or is it in a state we can check in, and then you can give us patches later that refine it? I'd like to get it in the core as is if possible. The only tricky part is ABI implications. We have ABI macro guards we can use, but we don't want to get too messy with those; too many ABI implications might hold back a merge. > PS: Greg, thanks a lot for your exploring the problem... Ya, your recent patch has got me looking at the Fl_Tree code again, so I'll see if I can get some momentum to make more improvements. Made a few commits earlier today to solve a mild bug, and added a way for the tree to return an array of selected items.

#31	kdiman 20:09 Nov 07, 2013

> Would you rather we wait to merge the patch into svn current, > or is it in a state we can check in, and then you can give us > patches later that refine it? Ok - later! In this moment I have not a time for remake Fl_Tabs for the Oxy ... For now, you can replace draw-function fl_oxy.cxx::_oxy_button_down_box_, with this code: [CODE=CPP] // draw gradient for button down box static void _oxy_button_down_box_(int x, int y, int w, int h, Fl_Color bg){ bg = fl_color_average(bg, FL_BLACK, 0.88); int half_h = h/2, xw = x+w-1; float gradoffset = 0.15f, stepoffset = (1.0/(float)half_h); Fl_Color c = fl_color_average(bg, FL_WHITE, 0.5); for(int _y = y; _y <= y+half_h; _y++){ fl_color(fl_color_average(c, FL_WHITE, (gradoffset<1.0)?gradoffset:1.0)); fl_line(x, _y, xw, _y); gradoffset += stepoffset; } gradoffset = 0.0f; c = bg; for(int _y = y+h-1; _y >= y+half_h-1; _y--){ fl_color(fl_color_average(c, FL_WHITE, (gradoffset<1.0)?gradoffset:1.0)); fl_line(x, _y, xw, _y); gradoffset += stepoffset; } } [/CODE] > Ya, your recent patch has got me looking at the Fl_Tree code again, > so I'll see if I can get some momentum to make more improvements. > Made a few commits earlier today to solve a mild bug, and added > a way for the tree to return an array of selected items. Thanks a lot! -- The best regards.

#32	kdiman 07:55 Nov 14, 2013

Dear sirs. I have made patch for fltk-1.3.x-r10016, fltk-1.3.2, fltk-1.3.1, fltk-1.3.0. New improvements: I have fixed height and obscure color for not selected tabs for the Oxy in the Fl_Tabs class. I want in a future (for the Fl_Tabs): 1) to add button (with image green plus on right side) for make new tabs (optional enable button) 2) if width of all tabs in sum overtops width of the Fl_Tabs widget, then to draw navigation button (with arrows on left side) for scrolling Tabs Headers 3) to draw button on each Tab (with flat box and image with red cross) for closing Tabs (optional enable button) PS: Sorry, I have not the time for remake Fl_Tabs in this moment =(... -- The best regards

#33	kdiman 08:10 Nov 14, 2013

... I have forget to update drawing transparent buttons(down box) in next-to-last patch for fltk-1.3.x-r10016 (first archive by 14.11.2013)... It was corrected in the second archive by 14.11.2013.

#34	kdiman 07:03 Nov 15, 2013

Changes for the Oxy (by 15.11.2013): 1) corrected drawing selectbox for Fl_Tree_Item when the scheme taken from FLTK_SCHEME env var 2) corrected offset for icons in Fl_Tree 3) corrected handle() method for Fl_Check_Browser 4) added class Fl_Toggle_Browser

#35	lm 05:38 Nov 25, 2013

greg.ercolano wrote: >An FLTK app should not have to be modified to make use of FLTK schemes. > > The test/buttons demo has no theme specific code in it, yet it supports > both the "plastic" and "gtk+" FLTK themes respectively by invoking: > > test/buttons -scheme plastic > test/buttons -scheme gtk+ For the record, that's not true on my system whether I use the version I compiled or the version from a Linux distribution. Changing scheme only affects the look of some programs, not all of them.

#36	kdiman 15:24 Nov 29, 2013

I have done Fl_Calendar's new class, which was included int onew patch the Oxy. (screenshot of the calendar attached) the Fl_Calendar has some useful methods for set/get selected time: // set current local time void set_now(); // `-1' - for old values; mday - [1-31]; mon - [0-11]; year - [0-9]{1,4} // example set `5 May 2000 00:20:05': set(5, 04, 2000, 0, 20, 5); void set(int mday, int mon=-1, int year=-1, int hour=-1, int min=-1, int sec=-1); void set(bool utc, time_t t); void set(struct tm *tm); // see man(3):strptime for next function void set(const char* str, const char *fmt); // get time for selected date in the calendar, if `tm' is not NULL then to there will puts info too time_t get(bool utc = true, struct tm *tm = NULL); // get time to cstring `out' by format `fmt' ; see man(3):strftime int get(const char *fmt, char *out, int szout); Changes: Added taking focus in the handle() method of Fl_Check_Browser/Fl_Toggle_Browser NOTES: Fl_Calendar_Prefs has icons (Fl_PNG_Image) for using that you must link to author by adding into your apps link to web site into somewhere a menu->help->about->third_side_of_software. TODO: For reusing icons, needs to add support method for set images from buffer, for users will have possibility to reinstall their own icons. Or may be exists method that not known to me and which does that ? Needs to clean new source files by unused variables - I'm tired for remake patches today (warnings compiler) -- Have a nice day.

#37	kdiman 06:09 Nov 30, 2013

Changes: Cerrected some errors and removed unused variables. Into archive added example project: calendar.fl which is demontrating using of the Fl_Calendar. -- The best regards.

#38	kdiman 12:22 Nov 30, 2013

Changes: Fixed crashes after change date without installed callback. You can use now the Fl_Calendar as child of anyone group (and as before is separated window). If the calendar is a child of another group, then button `close/exit/hide' will be deactivated automatically. -- Have a nice day.

#39	kdiman 22:29 Dec 20, 2013

Dear Greg and other devs. I have made patch for latest release fltk-1.3.x-r10036 . There were corrected some errors in Fl_Calendar (win32), Fl_Choice, Fl_Spinner. in Fl_Browser_.cxx I did some offset for drawing item (after clipping). If you wish, you can check in. PS: I cannot compile for mingw32 (x86_64) (unknown dir ... something about that...) -- regards.

#40	kdiman 22:54 Dec 20, 2013

and maybe replace Fl_PNG_Image in Fl_Calendra to Fl_Pixmap ? does Fl_Pixmap needs to link with libxpm or does not ?

#41	kdiman 01:41 Dec 21, 2013

for the last patch, drawing Fl_Tree_Item is not correct, I am working for correct it (for new Fl_tree)...

#42	kdiman 03:42 Dec 21, 2013

corrected...

#43	kdiman 09:37 Dec 21, 2013

I have changed format of images for Fl_Calendar from Fl_PNG_Image to Fl_Pixmap ...

#44	kdiman 17:36 Dec 21, 2013

Dear Greg. I understand now: I should cover my Oxy code by `FLTK_ABI_VERSION >= 10303'. For it, I will have time about ending january of next year. -- regards.

#45	AlbrechtS 05:19 Dec 30, 2013

Dmitrij, please separate your proposal for a new theme from all other additions like Fl_Calendar and others. Each STR should contain only one proposal that can be implemented as such. If there were dependencies on other STR's this should be mentioned in the STR in text form. Problems with your patch here: http://www.fltk.org/strfiles/2675/oxy_fltk-1.3.x-r10036_3.tar.gz There is no file FL/Makefile in the repository, FL/Makefile will be generated from FL/Makefile.in. If there is anything to be changed, the patch should be against FL/Makefile.in. Please remove all NEW files from the patch, as in this (maybe not complete) list: Fl_Calendar*.*, Fl_Clock_Input.*, Fl_Clock_Spinner.* etc. Also, the first post and patch here were about a "grad1" theme, then there was "oxygen", now we see "oxy". There is also a patch from 'lm' for "grad1" and "gleam" scheme. This is very confusing. Are these all different schemes, or did you change their names, did you change your mind about which schemes you want to be included in FLTK, ... ? After all, this STR is assigned to Greg, and I can also see mention of Fl_Tree in comment #21 and maybe others. There are also Could we please clean up this mess a little bit. Maybe it's best to create new STR's for single, independent items, so that we can apply smaller patches one-by-one. Dmitrij, as said before, if you really want to propose a new Fl_Calendar widget and related widgets, please add a new STR for this alone, so that we can check this independently. Thanks for your work and proposals!

#46	AlbrechtS 05:24 Dec 30, 2013

Continuing this broken sentence: There are also mentions of some bugs in other widgets like Fl_Round_Button (comment #17), changes to Fl_Browser (#21) and maybe more. Are these bugs/changes independent of the patch, and should they be fixed anyway? Greg, maybe you know about all this, because you looked at it before?

#47	AlbrechtS 05:30 Dec 30, 2013

Regarding comment #35 by lm: greg.ercolano wrote: >An FLTK app should not have to be modified to make use of FLTK schemes. lm wrote: > For the record, that's not true on my system ... What Greg wrote is true, but this can only work if the app calls window->show(argc,argv) for the first window (i.e. using argc and argv), so that command line arguments can be considered. Apps failing to do so, or apps that call Fl::scheme(...) internally will not work with commandline scheme arguments. So, to be precise, you mus emphasize "SHOULD"!

#48	greg.ercolano 18:42 Dec 30, 2013

> Also, the first post and patch here were about a "grad1" theme, then > there was "oxygen", now we see "oxy". Right, I think these are separate schemes, oxy being the "shiny" one, and grad being more of a gradient type look IIRC. Been a while since I looked into this, as have been involved (distracted by) other parts of FLTK (Fl_Tree and Fl_Browser..) It's probably fine I think to offer the two schemes in one STR if they're both similarly coded, add value, and are relatively 'simple'. > There is also a patch from 'lm' for "grad1" and "gleam" scheme. I think that was a noble effort by the "gleam" supporters to include the "grad" scheme as well in a single patch. > This is very confusing. Are these all different schemes, AFAIK, "gleam", "grad" and "oxy" are three different schemes; the former from STR#2672, the latter two from STR#2675 (this STR). They're different schemes by different people all with a similar goal; to add nice looking themes to FLTK.. just so happened to be all at once. I assigned this to myself because I could see a path to bring all three together if possible, but got held up on the issue of Fl::scheme() not working for one of them, can't remember which now, it's been too long :/ > After all, this STR is assigned to Greg, and I can also see > mention of Fl_Tree in comment #21 and maybe others. Yes, he found a problem in Fl_Tree (the "selected" item bar was drawing underneath the vertical scroll that hid the edging detail of this scheme's box drawing). I decided to fix that problem as part of a larger undertaking of mods I had in mind for Fl_Tree which I completed over thanksgiving, and that was committed to svn some weeks ago; see the log description for details of what was added: http://www.fltk.org/newsgroups.php?s10545+gfltk.commit+v10559 Those Fl_Tree changes were added as an ABI 1.3.3 feature, and should be stable. I definitely like the look of the oxy theme (see oxy_preview.jpg) and would like to see better themes like this in FLTK. When the gtk+ theme was added, it really brought up the overall look of FLTK I think. I use it a lot now. Love to see more options.

#49	greg.ercolano 18:50 Dec 30, 2013

> I decided to fix that problem as part of a larger undertaking > of mods I had in mind for Fl_Tree which I completed over > thanksgiving, and that was committed to svn some weeks ago; > see the log description for details of what was added: > http://www.fltk.org/newsgroups.php?s10545+gfltk.commit+v10559 Oops, correction, that link should have been: http://www.fltk.org/newsgroups.php?s10565+gfltk.commit+v10580 ..which among other things addressed the issues raised in comments #24 and #25 (and "promised" in #26, and actually followed through..!)

#50	kdiman 13:40 Dec 31, 2013

Dear Greg, Albrecht. All changes (Fl_Round_Button and others) was did for correcting exterior. Oxy is improved grad1 (with new arrows-control). I have renamed that, because `grad1' is ugly (temporary) naming. And I think, oxy best replacement for grad1, I am offering to forget about grad1. In this moment I have not time for work to separate widgets. gleam + oxy will be best way, by my point of view. PS: with congratulation new year, and lucky for all. -- regards

#51	greg.ercolano 17:47 Jan 18, 2014

Changing the subject of this STR to include the term "oxy" so we can search for it.

#52	greg.ercolano 18:58 Jan 18, 2014

As per the issue identified in fltk.general of recent, details here: ..suggesting the strcasecmp() -> strcmp() mods in the attached patch: oxy_fltk-1.3.x-r10036_2--remove--strcasecmp.patch ..which I applied to svn current (aside from a few hunk warnings, it applies) and built in VS2012 to verify it solves the issues in the above mentioned article. It does NOT address the issues Albrecht mentioned (removing the extra widgets). This new patch I've attached is a hand-edited version of the patch: oxy_fltk-1.3.x-r10036(21.12.2013)_2.patch ..that *just* addresses the strcasecmp() issue. You can diff the two patches to see the changes. Since the oxy patch adds fl_oxy.cxx and fl_oxy.h files, in order to build in VS 2012, a few of the ide files (in ide/VisualC2010/) need to be modified to include this in the build; will attach that mod separately as "vs2010-oxy-only.patch" (which only adds the fl_oxy stuff, not the new widget files which as Albrecht says, should be moved to a separate STR)

#53	greg.ercolano 19:03 Jan 18, 2014

> As per the issue identified in fltk.general of recent, > details here: ..that being this message: http://www.fltk.org/newsgroups.php?gfltk.general+v:29199

#54	kdiman 07:33 Feb 08, 2014

Time for create new patch is carrying to 1-2 months next, because I have some problem with health, and my job is not progressing as speed as I had awaited. sorry. I will do that, but little later. -- regards

#55	AlbrechtS 15:28 Feb 08, 2014

Hi Dmitrij, I hope you're well soon. As for your patch: before you start, here are some considerations: I suggest to open a new STR for your oxy-patch and nothing else. Please drop a note that this is a follow-up of this STR (maybe with a link) so that we can compare. Please do not add new widgets. This should be in separate STR's, if you want to add new widgets to FLTK. Ideally this would be one widget at a time, or a small group. Example: Fl_Clock_Input, Fl_Nav_Button, Fl_Calendar and related widgets. If a widget is usable independent of other widgets, use one STR per widget. If one widget depends on others, maybe use a small group in one RFE, or mention the dependencies in the STR. It is not acceptable to change widget hierarchies, as was done in your previous patch. This could break existing user code, if the parent widget of a derived class changes its class from one FLTK release to the next. Example: class Fl_Input_Choice (previously inherited Fl_Group, in your patch: Fl_Menu_). As noted above, do not add generated files. Example FL/Makefile, fluid/alignment_panel.cxx etc. (the latter is generated by fluid from fluid/alignment_panel.fl). Please try not to patch existing widget code (Example: src/Fl_Browser_.cxx). If it is really needed, this should be discussed before. I can see that you sometimes add a few pixels to the size of some objects (e.g. in src/Fl_Browser_.cxx). I wonder if this is necessary, or if we could change the widget so that everything fits? If necessary, please replace code like this: '(Fl::scheme() && !strcmp(Fl::scheme(), "oxy")' with the new function 'Fl::is_scheme("oxy")'. I believe that the gleam patch in STR #2672 is a good example of minimal additions that can be accepted. The latest patch is: http://www.fltk.org/strfiles/2672/fltk-1.3.x-r9835-gleam-4.3.patch I hope this helps to create a new patch with your valuable scheme that can be accepted by the FLTK devs. Thanks for all your work for the FLTK community. Albrecht

#56	kdiman 21:08 Feb 08, 2014

Dear Albrecht and other devs. > Hi Dmitrij, I hope you're well soon. Thanks a lot ! > Thanks for all your work for the FLTK community. Thanks ! I love FLTK for super light API and license, and sometime I feel necessity commit enhancement by my possibilities into project because FLTK is little piece of my "job life" and I should to care about that... I will try your wishes for create the new patch. But I cannot guarantee to do all from your wishes, there are exists things which needed for good-looking the scheme, but I will attempt ! -- regards

#57	kdiman 05:13 Mar 13, 2014

last patch was did with notations of devs of FLTK. PS: Dear Greg, I cannot to draw text in Fl_Tree_Item::draw_item_content with my offests and clips, please help me to do that as I did it before your changes (adding draw_item_content) ... PSS: Sorry for my long silence, I had not internet before this moment ... -- regards

#58	kdiman 10:02 Mar 16, 2014

I was very glad to work for this enhancement for FLTK. Thanks to FLTK for life. Thanks to Bill Spitzak (founder of FLTK) and to all developers, who are had did, doing and will do things for FLTK... -- have a nice day

#59	greg.ercolano 13:32 Oct 27, 2014

Was a new STR opened for just oxy? (as per Albrecht's comments #45 and #55) If so, would be good to list it here. (I couldn't find one searching fltk's bugs for "oxy") Pretty sure the current state of /this/ STR should not affect a 1.3.3 release.

#60	AlbrechtS 07:50 Feb 22, 2015

@Greg: there is no new STR opened for just oxy yet. I'm trying to fix some things in the patch to make it more acceptable, and I'm uploading a new patch file based on Dmitrij's latest patch and current svn (r 10588): http://www.fltk.org/strfiles/2675/oxy_fltk-1.3.3-r10588.patch Changes in this patch: - remove trailing white space - adjust to svn r 10588 - use Fl::is_scheme() where possible. @Dmitrij: please use this version as a base for further modifications, if you're going to work on it again. I believe the basic work is excellent (thanks!) and I'd like to have the oxy scheme included in the FLTK core, but there are some things in the patch that "don't fit" (yet). To do (this is a selection of things that are not 'perfect'): (1) There are too many changes in existing widget code. One really bad example is changing the box widths of Fl_Counter. You can see this in test/unittests -> 'schemes test'. When the scheme 'oxy' is selected there is no counter value visible any more (unless you resize the window). There are more changes of box sizes that may or may not be acceptable. Note: I believe that a scheme should only change the appearance of widgets, but not their layouts. There are examples in existing FLTK code though (e.g. different scrollbar sizes and some more), but I think we should better not change standard widget code to implement new schemes. Ideally a new scheme should be 'loadable' like a plugin: one header file and one .cxx file for implementation. I know that this is not possible right now, but this should be the future development. (2) I don't know what all the changes in Fl_Tree*.* are good for. It's a lot. Maybe Greg can tell, but maybe this is worth a different patch, because there are also functional changes. (3) In src/Fl_Check_Browser.cxx the entire method Fl_Check_Browser::handle() has been rewritten. I don't know what this is good for (didn't bother to understand and/or test it yet), but it looks like an unrelated patch. Dmitrij, can you tell us why you changed this? Is it a general feature (bug fix) we should apply independently of the scheme patch? If yes, could you please open another STR with a description and maybe a demo program and drop a note here? (4) In Fl_Browser and friends the text height (line height, line distance) has been increased by 2 pixels. This doesn't sound much, but it can affect an existing widget's layout. Again you can see the effect in test/unittests (in the left hand function select browser) when you select 'oxy' or any other scheme. Isn't this something that should be implemented in Fl_Browser with another option or generally so that all schemes benefit from this? Why did you want this in the oxy scheme? (5) There are also functional changes in Fl_Tabs that are not acceptable and not necessary. In src/Fl_Tabs, in Fl_Tabs::tab_height() we have (among others): + if (flag_oxy && o->labelsize() > ls) { + // HACK : for preventing growing tab header height we are fixing it with biggest height of child labelsize + 10px + ls = o->labelsize(); + fl_font(o->labelfont(), ls); + HT = fl_height()+10; + } This is not necessary (and does not belong in the scheme patch anyway), because you can achieve this behavior by making one of the child groups the resizable() of the Fl_Tabs widget. You can watch the different scheme behavior if you resize the test/unittests window vertically (make it higher), and change themes. The tab headers show different heights. Here is a simple patch that shows how to achieve the same behavior for all schemes w/o patching the widget code (after applying this patch the heights are roughly the same): Index: test/unittest_schemes.cxx =================================================================== --- test/unittest_schemes.cxx (revision 10588) +++ test/unittest_schemes.cxx (working copy) @@ -107,7 +109,8 @@ { Fl_Tabs* o = new Fl_Tabs(10, 120, 320, 215); o->color(FL_DARK1); o->selection_color(FL_DARK1); - { Fl_Group* o = new Fl_Group(14, 141, 310, 190, "tab1"); + Fl_Group *tab1; + { Fl_Group* o = tab1 = new Fl_Group(14, 141, 310, 190, "tab1"); //o->box(FL_THIN_UP_BOX); o->color(FL_DARK1); o->selection_color((Fl_Color)23); @@ -193,6 +196,7 @@ o->end(); } // Fl_Group* o o->end(); + o->resizable(tab1); } // Fl_Tabs* o { Fl_Box* o = new Fl_Box(341, 10, 80, 50, "thin box\ndown1"); o->box(FL_THIN_DOWN_BOX); Apply this patch before or after the oxy patch (if you do it before, it should apply with a warning because of some line # offsets). (6) Last but not least: the code is not compliant with the CMP in some parts, particularly your own sources (src/fl_oxy.*). You should setup your editor to use a tab width of 8 and use indenting steps of 2 (not 1 as it seems to be in parts of your code).

#61	kdiman 10:23 Feb 22, 2015

> I believe the basic work is excellent (thanks!) and I'd like to have the > oxy scheme included in the FLTK core thanks. I hope for it (for support the oxy from box) Before I want to say: if I had changed something in CORE of FLTK in the oxy theme, that was only for aesthetic exterior (I tryed to reproduce things like in KDE Oxygen theme, not all are similar but majority) (1) I wanted do Fl_Counter's buttons for simmetric width to height IMHO: because that is more good looking (without flowing) (Note: sizes changed for oxy only !) (2) I don't know which patch was used for base, but in all my patches I wanted do for Fl_Tree/Fl_Tree_Item for: ) replace standart icons(open/close) to arrows ) fix drawing boxes for selected items and focus on them (if needs) (3) In src/Fl_Check_Browser.cxx : that was my old hack for avoid selecting an item under scrollbars (try click on scroll and will be selected item under that) needs to rewrite ... (4) "In Fl_Browser and friends the text height (line height, line distance)" ... Ok, I will look there for fixing ... (5) "Fl_Tabs" ... Ok. (6) Ok, I will do settings in my editor as you note me. -- the best regards

#62	AlbrechtS 11:14 Feb 22, 2015

Thanks for your feedback. Dmitrij wrote: > I don't know which patch was used for base,... I used the latest patch posted here (STR #2675, file #28). http://www.fltk.org/strfiles/2675/oxy_fltk-1.3.x-r10115(02.03.2014).patch > if I had changed something in CORE of FLTK in the oxy theme, > that was only for aesthetic exterior I understand your point - however I believe that another theme should not change the widget's layout, as I wrote before. Ideally you could switch themes (schemes) w/o seeing any difference in pixel layout - only different appearance inside a widget. If you want to change a widget's layout (like your Fl_Counter) this might better be done with a different class, i.e. derive a new class with a different layout. > I wanted do Fl_Counter's buttons for simmetric width to height > IMHO: because that is more good looking (without flowing) Imagine the following case: I design a GUI layout for FLTK and distribute my program. In a later version of FLTK people may use your oxy scheme. What happens? My Fl_Counter widget doesn't display the value because the user switched the theme, as seen in the example above (test/unittests). Very bad! We should avoid this. > (Note: sizes changed for oxy only !) That's exactly my problem. Sizes change when the user switches the theme. Another more technical aspect is that the code becomes less maintainable. All these "if flag_oxy() ..." and other scheme-dependent code should be avoided as much as possible. I'm currently analyzing the code to propose a more comfortable theme system. The basic idea is to have more theme specific drawing methods like your oxy_arrow() functions. My idea is that a theme will be a new class (Fl_Scheme or Fl_Theme or similar) and you can derive your own Fl_Theme_Oxy class with your drawing methods. The drawing methods would not only be box drawing mehtods, but also methods for arrows and other elements (radio button 'circles', light button 'lights', etc.). My concept is not yet ready, but I hope you get the idea. What does this mean for the oxy scheme? The question is: can we define a basic scheme that does NOT change widget layouts (even if only by a few pixels), and leave the other changes in widget code for later? > (3) In src/Fl_Check_Browser.cxx : that was my old hack for > avoid selecting an item under scrollbars (try click on scroll > and will be selected item under that) ... Okay, I'll take a look into it. Maybe we can fix this independent of the scheme.

#63	Georg 11:40 Feb 22, 2015

I have been using OXY in the past and I like the scheme. However, I agree with Albrecht that the widget's size should not be changed by the scheme. Also I agree that a central interface (by an Fl_Scheme class) for new scheme developers is ideal instead of making all sorts of changes all over the FLTK code. This interface should not be too restrictive. It should allow e.g. to make a widget transparent so the underlying windows shines through. The Microsoft GUI has that feature. As far as I know Dmitrij is very busy with another project right now, but he planned to add a Win8 scheme if it could find its way into the FLTK code. This scheme could then be derived from the Fl_Scheme class planned by Albrecht.

#64	AlbrechtS 11:44 Feb 22, 2015

>> (3) In src/Fl_Check_Browser.cxx : that was my old hack for >> avoid selecting an item under scrollbars (try click on scroll >> and will be selected item under that) ... > Okay, I'll take a look into it. ... I can't see the behavior as described. I used test/browser and everything worked as expected. I can't see the effect, neither 'under' the horizontal nor under the vertical scrollbar. Can you give more precise instructions or another demo program?

#65	AlbrechtS 11:50 Feb 22, 2015

Sorry, I can see the questionable behavior now, but only if both scrollbars are visible and I click in the area not covered by both scrollbars (in the default browser this is the bottom right corner). Is this what you wanted to fix?

#66	kdiman 19:16 Feb 22, 2015

Sorry Albrecht, but for now I can't to reproduce the checking, perhaps that was for Fl_Check_Browser... PS: I will ignore that modifying and changes for Fl_Countour(I don't using that anyway =) ) ...

#67	AlbrechtS 07:43 Jul 23, 2015

I updated the previous patch to current svn, see oxy_fltk-1.3.4-r10813.patch. This is only a formal upgrade of the patch and does not mean that this patch is applicable. There are still unrelated parts included, as discussed before. Modifications applied: - Remove trailing white space. - Fix indenting. - Use Fl::is_scheme() wherever applicable. - Remove 'FL_EXPORT' from scheme drawing functions. - Add 'oxy' scheme to unittests scheme demo. @Dmitrij: I fixed all sorts of wrong indenting in your patch. Please use my latest version if you want to do further improvements, and *please* set your editor to use tab-width 8, and then use 2 (!) column indenting, as written in the CMP. Thank you. http://www.fltk.org/cmp.php#CODING_STANDARDS

#68	AlbrechtS 03:38 Jun 15, 2018

Please see new STR #3477 for further discussions! http://www.fltk.org/str.php?L3477 I propose to use the reduced version of the oxy scheme (Dmitrij's oxy patch, modified by LM and by me) attached to STR #3477 (latest version as of today: oxy_v3.diff) to get the oxy scheme into FLTK 1.4.0. http://www.fltk.org/strfiles/3477/oxy_v3.diff @Dmitrij: please check this new STR and answer the questions in comment #4 and/or add your comments. Thanks. Dmitrij, can close this STR? If you agree and if you think you can extend your oxy scheme later for general use, then I suggest that you open another STR because *THIS STR* (#2675) is no longer "maintainable". TIA

#69	AlbrechtS 11:14 Dec 06, 2021

This STR has become obsolete and was replaced by STR #3477, I'm closing this one now. https://www.fltk.org/str.php?L3477