GNOME Bugzilla – Bug 759648
Proposed Light Theme for 2.9/git master
Last modified: 2016-03-22 12:30:06 UTC
Created attachment 317643 [details] Proposed Light Theme for 2.9/git master I revamped my old themes and am proposing this one for the Light theme.
Created attachment 317645 [details] Light Theme Screenshot
Very nice, but very gray. I wonder if would not become depressed if I worked with a full-gray UI all day long. So should this replace the default theme or be an additional one?
Thanks, i was thinking of it as an addition. Yeah i made it like that but like i explained it in the other theme, too much white kills the eyeballs when working on photos at 2am lol. I tried to be neutral with this one. Ditto about the images as for the other theme.
Jehan, we have a comment from a user who has bifocals that she need a grey theme, because really dark is unusable for her. So while I'm not sure this is a perfect grey theme for her, we actually might need something like this. @Ben, if you can, please check out Krita and see how their grey themes look. For either general acknowledgment or stealing ideas in broad daylight :)
(In reply to Alexandre Prokoudine from comment #4) > Jehan, we have a comment from a user who has bifocals that she need a grey > theme, because really dark is unusable for her. So while I'm not sure this > is a perfect grey theme for her, we actually might need something like this. I can give it a go basically make a third greyer one. > > @Ben, if you can, please check out Krita and see how their grey themes look. > For either general acknowledgment or stealing ideas in broad daylight :) Didn't realize they had themes in there. Not sure i'm a fan of all those gradients in the ui lol. I guess something closer to that level of grey is possible.
@Prokoudine Will upload a new greyish theme in a bit that i just did per the request :)
Created attachment 317660 [details] Updated light theme Updated the theme text, credited everyone in the gtkrc. Removed all unused assets.
Created attachment 317689 [details] Update 3 to fix some warnings, adds an extra image Fixes some warnings from the last update, adds entry-border-notebook-null.png
Ben > now that you have a grey theme proposition, could I propose you to have the light theme even lighter? The current default may disappear at stable release, replaced by a nicer theme. But then we would need at least a real light theme for people who like these if we lose the default theme. So basically what I am saying is that your light theme could replace Default in the end. Then everyone gets what one wants: people who like light, dark, and grey. For any more nuance of course, users will be welcome to create or install third-party themes. :-)
I'll make another one and call it white to keep it on a separate bug thread, guess i'll see what i can do. Though by how much would you like it brightened up?
Created attachment 317838 [details] New gtkrc for light theme Fixes the color issue for scrolled windows and fixes text color selection.
Created attachment 318031 [details] Update - adds fixes for KDE - 2015/12/30
Created attachment 318032 [details] [review] Update - adds fixes for KDE - 2015/12/30 - git patch
Created attachment 318033 [details] Screenshot - 2015/12/30
Created attachment 318123 [details] Screenshot 2016/01/01
Created attachment 318124 [details] Update v0.1.0 2016/01/01 complete theme zip file
For now i'll be tracking changes to these themes here https://github.com/Draekko-RAND/gimp-themes
Created attachment 318502 [details] v0.1.2 complete .zip theme files
Hi Ben, Could you commit this theme to master please? :-) Only this one for now (even though, by the sound of it, we may end up committing most of your proposed theme, since there seem to be a lot of different taste in themes). I want to play with theme's gtkrc factorisation so that we manage only one piece of code at once, and I will need at least 2 of your themes in the tree to do so. :-)
Done, btw your commit 3275ea4a29a6f938ad311ea010ed00f4037280e6 fails to symlink properly causes make install to fail here.
Thanks for the build fix. A small "rule" we have is to write down the commit when it corresponds to a bug report. This allows to easily find it later from the bug report, if needed. I'll do it for this one. :-) commit b3dc5db2a2751b4172c162aeae5bd1f360ccb61e Author: draekko <draekko.sofware@gmail.com> Date: Mon Jan 11 09:53:41 2016 -0500 themes: adding The-Light-Side-of-Gimp theme Adding light theme as per request: https://bugzilla.gnome.org/show_bug.cgi?id=759648#c19
Ah, ok.
Welcome, btw there is still an issue with that bug but wasn't sure how you would want to tackle it https://bugzilla.gnome.org/show_bug.cgi?id=760469 and i ran out of time this morning to give it a go.
commit 079e113dd99d20298d9343db1b3f162f29ffb99c Author: Benoit Touchette <draekko.sofware@gmail.com> Date: Mon Jan 11 09:53:41 2016 -0500 themes: update/fixes for 'The-Light-Side-of-Gimp' theme Updated & fixed KDE plugins/filters not being skinned properly. Fixed Ubuntu overlay scrollbars. Minor colort weak to UI menu bar. https://bugzilla.gnome.org/show_bug.cgi?id=759648
In style "tlsog|tdsog-menu_item", there is a: file = "ui/entry-border-fill-active-item.png" The Dark theme has a file = "ui/entry-border-fill-active.png" for the same function. Shouldn't it be "ui/entry-border-fill-active.png" also in the Light theme? Or at the opposite, maybe a new "ui/entry-border-fill-active-item.png" has to be created in the dark theme? For info, I would prefer not to create a new file, and at the opposite remove "ui/entry-border-fill-active-item.png" and reuse "ui/entry-border-fill-active.png" *if it makes sense*. I prefer a theme with not too many things loaded if possible. But of course, if you believe a different image is needed for some very important aesthetic reason, suit yourself. ----------------- Also in commits 4dbc68be and 079e113d, you respectively fixed Dark and Light theme for seamingly the same issues (according to the commit logs). But for the Dark theme, you added: GtkComboBoxText::shadow_type = GTK_SHADOW_NONE And for the light theme: GtkScrolledWindow::shadow-type = GTK_SHADOW_NONE I want to assume these 2 lines have a similar result, but could you choose one of them? As I said, I'm trying to get a shared code to make themes the more maintainable possible. If you could fix these 2 issues so that both themes would be similar, it would be better. And if possible don't do other changes than these for the time beings until I commit my refactorization (which should be quick once you fixed these). Thanks!
1) the png i remember creating a different (active-item) one as i needed a slightly different color tone as from the plain active. I did edit some of these i will double check to see if its still needed. 2) each of those shadow_types need to be added to both files.
Dunno if my comment got lost on IRC, so here it is again: Both this and the dark theme lack prelight for a large number of widgets, which is a rather serious usability regression.
Also, the selection is not visible in entries, and completely back in GimpSpinScales.
Ben > I have added the shadow_type-s to be similar on both themes. Could you just check the active-item file issue and fix this before you take care of Mitch's bug reports? I really want to factor the code before any more changes are done. Having diverging theme codes make maintenance a bitch, especially if we want more than these 2 themes.
I'm not near my computer right now, i'll take care of it in the morning (my local time).
Jehan: Is there an easier way to have the commit message here other than cut and paste the info? Also i updated the meuitem prelight to more accurately reflect the proper png filenames for both light and dark.
commit 127fdff9c73f3f2c6b77cb982eeaf413a408327c Author: Benoit Touchette <draekko.sofware+gimp@gmail.com> Date: 2016-01-17 11:58:43 (GMT themes: Updated both dark and light themes menuitem prelight. Updated both themes menuitem prelight to use same filename in gtkrc. Added new ui/menuitem-prelight.png
commit: 2144a7ceb90e17a4631a9436478ece71c4d385a2 Author: Benoit Touchette <draekko.sofware+gimp@gmail.com> Date: 2016-01-17 12:08:49 (GMT) themnes: Updated light theme menuitem prelight
There is git-bz: http://git.fishsoup.net/man/git-bz.html
So to confirm if i understand it correctly i would do 'git bz add-url 759648 2144a7ceb90e17a4631a9436478ece71c4d385a2" after i push the commit (as an example)?
Ben > I have now committed my code factorization. Normally it's all good but you should check if I broke anything: commit 6e109052ca8c431644ce6e75693d7865cd2f1673 Author: Jehan <jehan@girinstud.io> Date: Sun Jan 17 19:53:04 2016 +0100 themes: use a common gtkrc and correctly named colors. All our new themes should now use a common gtkrc base. Colors only should be different, as included from a colorrc. This way we ensure a consistent behavior throughout all themes. Also we should use meaningful color names to make maintenance easy. As you can see, you should now work in a single gtkrc. This will ensure that all themes are consistent with each others, and will make discrepancy bugs like the ones in comment 26 not possible anymore. The differences between the themes should go in the colorrc, and these should be only colors, basically. Also I have renamed the colors. Let's use clear naming rather than @clr1/2/3… That's a general rule in software development, and makes the gtkrc much much more maintainable. Finally going through your gtkrc, I really felt that you should use style parenting more. Of course, I have not checked out the details, so I may be wrong. But I feel like a lot more widget styles could be derivated from "default-style", or maybe from each others… If possible, you should subclass (or whatever they call it for styles) since I feel it would make the gtkrc and colorrc clearer.
Yeah i don't like that idea of having a common file for both it really ties both of my hands behind my back. It also makes it a pain in the ass. As for deriving the styles no don't do that it will definitely break everything. There's a whole lot of little reasons why things are the way they are and it's hard enough to keep it all straight and working. If you do make changes, please test them on all os'es because it takes me many hours (several dozen so far) to make sure it all works on everything and i don't always have the time for that.
Particularly problematic are KDE with QtCurves and oxygen-GTK.
> If you do make changes I am not planning to do any changes. I let this to you. :P I was only proposing what seems to me a common good usage in development and because I saw many very similar style rules applied over and over to various widgets in your gtkrc. But maybe in the case of GTK+ styles, this is better? I will trust your word on that. > Yeah i don't like that idea of having a common file for both If we don't do this, we will end up having basically the same file duplicated several times, slowly diverging as time goes. The previous issues from comment 26 were actually good examples: all divergences ended up being bugs in the themes. And we would not be able to have more than 2 themes with separate codes (actually even 2 themes with separate gtkrc, I find it already messy). Whereas now I feel a lot more confident to have even maybe all your variants of greys. > it really ties both of my hands behind my back This is the whole point, having to think things globally, as generically as possible. We can't go around duplicating codes everywhere. Because the day you decide you don't have time for GIMP anymore (I really hope you don't. We need you!), nobody will be able to maintain the 4/5 themes that we may have by then. Note that our themes don't have to be the best in the world necessarily (well it's good if they are of course), but they have to be maintainable. This is the most important feature for the long term and what people expect from the core project (robustness over bling-bling). Also my commit made absolutely no functional changes. That proves that it does not really tie your hands in term of feature. :-) You can still do everything this way. Simply we should really think in a robust way. So we should indeed tie ourselves in term of code design.
> Particularly problematic are KDE with QtCurves and oxygen-GTK. Good example of why we need to do this. They day we have a problem, if codes really diverged over time, we may have to do different fixes depending on the theme, diverging things more and more. With shared style code, we fix issues once for every themes and know if works everywhere the same. You also write code, so think of this as using functions rather than copy-pasting the same code everywhere. :-) This should also definitely save your time!
Created attachment 319751 [details] v0.1.4 Jehan: I don't agree and i never intended them to be the same, being force to keep them in sync was my problem and caused errors. Note right now I don't have the time or the inclination to update and reconcile to the new format you've chosen. Also between an eye infection and my computer borking out on me its made me get behind on some work so i probably won't be around much for the next few weeks. I'll upload version 0.1.4 for both dark and light variants which fixes a number of issues. I leave it to you to reconcile both sets.
Created attachment 320080 [details] v0.1.5 Update to fix menu item style name and menu item prelight on Unbuntu Unity.
Ben > the themes don't have to be the same. But we should share as much as we can. This is the intended goal of this common gtkrc. The layout in particular should be the same on all themes. Colors on the other hand are obviously diverging. If for some reason, some things other than colors had to diverge. Even the layout (for some reason which could make sense when the case happens), we could also have this piece of style code in the dedicated colorrc files. This should be as rare as possible, and in the better case never happen. Yet if it had to be, the current code organization absolutely does not block you from doing so. I can't accept the 1 gtkrc file per theme as finale code organization because I don't believe this is clean and I fear it would bite us back in the ass in some distant future. Now if others are OK with it, I am not one to go absolutely against it. Mitch > you have an opinion?
Hi Ben, So we've discussed on IRC. I still believe that the theme code should be better organized, especially since it does not remove any theming capabilities to reorganize files a little. Anyway it seems you have stopped contributing because of this and that is sad. So I've decided to revert the commit. The fact that we will anyway have to redo all theming from scratch after GIMP 2.10 release (because GTK+3 use CSS) helped this decision. It is acceptable for more or less short term code, even though it does not make it very robust. Having a common layout for all themes is still a requirement since many users seem to have the need to regularly change the theme, and the layout cannot just change all the time (well for the official themes. We don't control user themes). But we'll trust you to ensure it stays the case. :-) Also I've made only a small change, which is that the default size of tool icons are the same size as the "Default" theme. The reason for this is that the small sized icons are just really too small on many devices (especially with HiDPI screens many have nowaydays, where small icons would be close to invisible). Of course larger icons are a little big on other kind of devices, but let's say they are an acceptable average. In any cases, this won't be a problem soon since we will be able to customize icon sizes for any theme (see bug 745835). And that's it! Have fun hacking. :-)
I still have another two weeks of catching up on work, getting sick (not having a thyroid sucks often) and the computer borking didn't help any, hoping to be able to spend more time soonish on these. As for the themes files you should have made that a requirement from the beginning for them to be exactly identical. Personally I intended them to be similar in format so that the users wouldn't notice but not behind the scenes (as far graphics files and resource files). Anyways good to know. Things should be very different for gtk3 thankfully css is far easier to use ( though until they have real/complete css it won't be 100%, heard that was going to show up someday in gtk4 lol).
i didn't intend is what i meant *smh* time for a break.
commit 0d692eadc00600e4d357bf9e0cf9b86733c11b5a Author: Benoit Touchette <draekko.sofware@gmail.com> Date: 2016-02-14 17:10:10 (GMT) themes: updates to TLSOG & TDSOG (prelight, text, bug fixes, (C)) Updates to copyright, some button contrast for TDSOG, TDLSOG. Added comment for button focus area. Fixed selected text for TLSOG themes. Redid screenshots to match changes. Fixed menu style name. Updated copyright year. Fixed menu items for Ubuntu unity. Fixed prelight and fg for widget text. Updated to v0.1.6. https://bugzilla.gnome.org/show_bug.cgi?id=759648
Created attachment 321133 [details] v0.1.6
commit ab8aa3bd83907710ef21f3d3ae33c4dba1507a97 Author: Benoit Touchette <draekko.software+gimp@gmail.com> Date: Sun Mar 20 08:42:20 2016 -0400 Themes: Renamed themes. Added 3 themes (Lighter, Gray, Dark). Updated themes, renamed The-Dark-Side-Of-Gimp to Darker, and renamed The-Light-Side-Of-Gimp to Light. Added three themes, Lighter, Gray, and Dark. https://bugzilla.gnome.org/show_bug.cgi?id=759648 (Light) https://bugzilla.gnome.org/show_bug.cgi?id=759649 (Darker) https://bugzilla.gnome.org/show_bug.cgi?id=759663 (Gray) https://bugzilla.gnome.org/show_bug.cgi?id=759830 (Lighter) https://bugzilla.gnome.org/show_bug.cgi?id=759996 (Dark)