theme dev talk

[raveit65]

themes needs a rewrite to 3.20

[raveit65]

@ lukefromdc

OK, I counrt a total of 11 desktop themes that will have to be ported assuming we don't plan to drop any of them. Once you've done one it's about 8 hours work to rough port one, maybe 4 more to finish. The kicker is this: Mint will be updating to Ubuntu's 16.04 release this Spring, but that will be GTK3.18. I don;t know if Mint will then sit on Ubuntu LTS again for the next 4 years, but if they do they won't ever have to support this exact version of GTK3. Thus they might not port anything this time around. Between the two of us we can port a selection of themes, but we'll need more hands if 11 are to be supported. That's a lot of themes for just one or two developers to deal with. First port always takes the longest, the things I learn the hard way on my own theme are quickly reapplied to anything else I port. Should be the same for everyone else.

Yes, there are a lot of themes. But most of them are sister themes which are only different in color scheme.
Menta should be same as BlueMenta.
GreenLaguna is very similar to BlackMate but a bit different.
Traditional themes should be only different in color scheme
Submarine themes are different in colorscheme and some color definitions, but the structure is the same.
Contrast themes are different but they are very simple themes.
So, for half of the themes it is simply a copy/paste action.
Before gtk+-3.20 use a 2 or 3 in minor version it should be sufficient to have only 1 theme from every sister theme ready, because we don't know what will change in gtk+.
In general for me it is sufficient to have only one or 2 themes ready when 3.20.0 will release.

Well i like to port BlueMenta for myself because i want to learn what i have to change.
And doing it for myself is the best way to learn it.
But feel free to start with another theme if you have some free time.
If you catch the Submarine themes, please comment only out stuff which does not work anymore, we can delete the lines later.,.............Blue-Submarine is my real baby.

And thank you again for your efforts.

[lukefromdc]

I just added a mostly complete port of Green-Submarine. Basically usable but probably needs more work. Picked this one so you can fine-tune it for Blue-Submarine. OK, we've now got one light theme and one dark theme usable enough for GTK 3.19/20 testing if nothing else. I only use a limited set of apps, plus check them in gtk3-widget-factory and gtk3-demo, same as my own theme but without the long-term day to day use that always seems to turn up the minor issues.

[raveit65]

Phew, fist raw port for BlueMenta is done, now i can go in details to check if all stuff is working like it should.
Progressbar and Scale is quite broken. I didn't touch mate/gnome/others-application.css.
Looks like that all this settings are lost if we can't use specific 'app selectors'.....this is really a regression for me.
I will take a look at green-submarine over the weekend to find out the button jumping.
I guess it's a issue with .linked button logic.
Sadly, an important page is droped from gtk3-inspector where you could see the theme settings of a widget, with that tool it was easy to find out a padding or border issue for a button. ......another regression for me.
Also it looks like that not all widgets are ported to using nodes.
So i have to look for every widget how they did it with adwaita theme
I guess there will come more changes.
Ok, i didn't test BlueMenta port with Mate, need to set up a VM first with fedora-24.

[raveit65]

PS: i didn't remove the old obsolete selectors for the moment, so we can use this as references for other themes.

[lukefromdc]

I just added a new branch to my repo with some Green-Submarine fixes.

https://github.com/lukefromdc/mate-themes/tree/Green-Submarine-fixes-gtk3.20

Working on those toolbar.primary-toobar selectors right now, will then see if I can do anything about the jumping. The linked-button code is very complex so no guarantees. If you know the offending widgets though, new jumping on a gtk3.19 port is almost always caused by a border that is present in one widget state and absent in another, in a few cases by a missing minimum-width or minimum-height. Only with treeview separators was the latter the culprit in my work, the rest was borders

[lukefromdc]

A quick check of BlueMenta here shows it basically working but with some
issues. Images in some buttons don't show up, no text in switches and
progressbars look like they have only a border of the progressbar progress
portion. Only checked Caja and gtk3-widget-factory though and don't know
really what it's supposed to look like. I figure that out normally by installing the
gtk3.18 version, putting the gtk3.20 version in a gtk-3.20 folder in the theme
directory, and then changing gtk versions. I have multiple GTK 3 versions built
into single debian packages apiece so rolling back and re-updating is a one
package installation.

On 1/29/2016 at 3:46 PM, "Wolfgang Ulbrich" notifications@github.com wrote:

Phew, fist raw port for BlueMenta is done, now i can go in details
to check if all stuff is working like it should.
Progressbar and Scale is quite broken. I didn't touch
mate/gnome/others-application.css.
Looks like that all this settings are lost if we can't use
specific 'app selectors'.....this is really a regression for me.
I will take a look at green-submarine over the weekend to find out
the button jumping.
I guess it's a issue with .linked button logic.
Sadly, an important page is droped from gtk3-inspector where you
could see the theme settings of a widget, with that tool it was
easy to find out a padding or border issue for a button.
......another regression for me.
Also it looks like that not all widgets are ported to using nodes.
So i have to look for every widget how they did it with adwaita
theme
I guess there will come more changes.
Ok, i didn't test BlueMenta port with Mate, need to set up a VM
first with fedora-24.

---

Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-176961961

[raveit65]

See mate-desktop/caja@5b56a80
Now we can style destktop canvas items independent from navigation-window with
.caja-desktop.caja-canvas-item { }
or
.caja-desktop EelEditableLabel.entry { }

Works well with 3.20, i think we need to add more style classes like this for old classes CajaNavigationWindow and CajaDesktopWindow at the top of the tree.
Than we can style caja independent from other applications.
Same for other mate applications which we need to style, ie mate-panel and pluma.

[lukefromdc]

Once toplevel windows are labelled this way, widgets within them are a lot easier to single out, only needing their own style class if it is necessary to distinguish between them in the same app, such as Caja navigation windows vs the Caja desktop.

[raveit65]

I've added some more style classes , see latest commits at caja master.
.caja-navigation-window at top level
.caja-side-pane --> top level for sidebars

I noticed that the .view class for IconView (navigation-window) doesn't work with 3.20, but adding a class 'fm-icon-container' does not help.
Here 'scrolledwindow.frame helps, but this is a bit odd.
Any Ideas?

[lukefromdc]

The .view situation works like this: in gtk3.20, that custom icon-view widget is always transparent. If you look at it in gtk-inspector, the style class is in fact being applied but it is now a backgroundless, always transparent widget, possibly by becoming a "windowless" widget that simply draws its foreground over whatever is beneath. Thus a background cannot be set for it. Anything else set with .view still works, such as the rubberband theming if not otherwise explicitly themes.

Therefore, the only way to set the background is to set it on something underneath the iconview, the scrolled window is the first one underneath. This can put boxes over the scrollbars in list views, however. The only solution I can think of would be to put a frame or some such thing inside the scrolled window, then put the FMIconView inside that. Either leave it out for the desktop or use the navigation window theme class to override an otherwise transparent BG for it so as not to get an opaque background over the desktop background.

Right now I am using the scrolled window to take the background and putting up with the list view scrollbar white box on top.

[raveit65]

OK, understand, we have to live with it for the momment.
I added some more style classes for caja.
.caja-pathbar
.caja-search-bar
.caja-location-entry
If we need some more , ie CajaTrashBar and others, please let me know.

[lukefromdc]

The Caja trashbar can be themed by the # widget name #caja-extra-view-widget ,
which covers the trashbar and I think covers other info bars, though I never see
any but the trashbar with my setup.

On 2/1/2016 at 8:02 PM, "Wolfgang Ulbrich" notifications@github.com wrote:

OK, understand, we have to live with it for the momment.
I added some more style classes for caja.
.caja-location-entry
.caja-search-bar
.caja-location-entry
If we need some more , ie CajaTrashBar and others, please let me
know.

---

Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-178288533

[raveit65]

Thanks for the hint.
Btw, do you see that issue with mate-terminal on bare metal with 3.20 ?
mate-desktop/mate-terminal#111
My rawhide installation is in virtualbox.

[lukefromdc]

Yes I do, that has been going on since the beginning of GTK3.19, but I figured
at the time it was just another gtk3.19 bug. Now it looks like it may be here to
stay.

On 2/2/2016 at 12:32 PM, "Wolfgang Ulbrich" notifications@github.com wrote:

Thanks for the hint.
Btw, do you see that issue with mate-terminal on bare metal with
3.20 ?
mate-desktop/mate-terminal#111
My rawhide installation is in virtualbox.

---

Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-178703510

[lukefromdc]

I just tested the latest BlueMenta, it's coming along nicely but some builtin icons
are still rendering either white on white or transparent in gtk3-widget-factory and
in GtkInspector. Also, you need to set a min-width on menu items containing
checks or radios, as that is defaulting to zero and removing the images.

On 2/2/2016 at 12:32 PM, "Wolfgang Ulbrich" notifications@github.com wrote:

Thanks for the hint.
Btw, do you see that issue with mate-terminal on bare metal with
3.20 ?
mate-desktop/mate-terminal#111
My rawhide installation is in virtualbox.

---

Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-178703510

[raveit65]

I added min-witdh for check/radio buttons, i never known that, thx.
And yes, some symbolic icons don't render very well on selected button state.
Normal symbolic icons change to white fg for a dark bg, i don't know why this doesn't work, maybe the contrast is too low for this bg color.
The missing icon in headerbar button of gtk3-inspector is a result of replacing symbolic icons in windows-control.css with regular icons.
With this line https://github.com/mate-desktop/mate-themes/blob/master/desktop-themes/BlueMenta/gtk-3.0/window-controls.css#L274
i revert the replacement for the menu button. I need to know the exact button name to do the same for this button.

[lukefromdc]

I do not know the name of the one in gtk3-widget-factory, it does not come up
with a name in gtk3-inspector. It has the style class .image-button.popup.toggle
but the problem with fixing buttons by name in test programs like this is that they
are symptoms of larger problems that these programs are designed to reveal.

One tip: I find that different themes with the same icon theme give different results,
I don't get this issue with my theme at all, but in that case the symbolic icons are
rendered white on a dark background in both programs. Most symbolic icons are
disabled in my theme but these still come up as symbolics, perhaps they are
hardcoded as such?

On 2/3/2016 at 11:20 AM, "Wolfgang Ulbrich" notifications@github.com wrote:

I added min-witdh for check/radio buttons, i never known that, thx.
And yes, some symbolic icons don't render very well on selected
button state.
Normal symbolic icons change to white fg for a dark bg, i don't
know why this doesn't work, maybe the contrast is too low for this
bg color.
The missing icon in headerbar button of gtk3-inspector is a result
of replacing symbolic icons in windows-control.css with regular
icons.
With this line https://github.com/mate-desktop/mate-
themes/blob/master/desktop-themes/BlueMenta/gtk-3.0/window-
controls.css#L274
i revert the replacement for the menu button. I need to know the
exact button name to do the same for this button.

---

Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-179320917

[lukefromdc]

Be advised that there were enough changes in today's version (2-4-2016) of
gtk3.19.8 to force me to explicitly theme the wnck workspace switcher in my
own theme, something which had not previously been necessary. Nothing
else seemed to break except Adwaita and only Adwaita forced the panel to
a much larger default height which could not be changed, no doubt due to
accidently matching some selector in Adwaita.

BlueMenta, Green-Submarine, and BlackMATE didn't get any new panel issues,
so an accidental match may have overridden the workspace switcher in my
theme.

The big change was that all those widgets with no name now get a css node name
of widget by default.

EDIT: This selector works for singling out the panel drag handles/grips without matching anything else it seems:

#PanelPlug>#PanelApplet>widget>widget

[lukefromdc]

The panel tray and window list grips were also made transparent by today's
gtk3 change, but the added "widget" name made them a bit easier to
explicitly theme. I used this selector but a style class added to the trays
and window list move grips would probably be a better idea:

window.mate-panel-menu-bar>widget>widget>widget.mate-panel-menu-bar>widget

These selectors work ONLY with gtk3.19.8 built after today's changes but were
not needed in my theme before today. The "widget" css node name is applied
to any widget that otherwise would not have a css node name, so it matches
only deprecated and custom widgets.

On 2/3/2016 at 11:20 AM, "Wolfgang Ulbrich" notifications@github.com wrote:

I added min-witdh for check/radio buttons, i never known that, thx.
And yes, some symbolic icons don't render very well on selected
button state.
Normal symbolic icons change to white fg for a dark bg, i don't
know why this doesn't work, maybe the contrast is too low for this
bg color.
The missing icon in headerbar button of gtk3-inspector is a result
of replacing symbolic icons in windows-control.css with regular
icons.
With this line https://github.com/mate-desktop/mate-
themes/blob/master/desktop-themes/BlueMenta/gtk-3.0/window-
controls.css#L274
i revert the replacement for the menu button. I need to know the
exact button name to do the same for this button.

---

Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-179320917

[lukefromdc]

Got the panel tray icon padding working again for gtk3.19.8 with this code:
#PanelPlug>#PanelApplet {
-NaTrayApplet-icon-padding: 1px;
}

[raveit65]

Do you see the name 'widget' in gtk3-inspector?
I don't see that with gtk3-3.19.8-2.fc24.
I agree with adding a style class for na-try-applet. Maybe we should add style classes for all applets?

Btw., what's the different of using (>)

#PanelPlug>#PanelApplet { }

and

#PanelPlug #PanelApplet { }

in general for theming?

I noticed also a change with spinbuttons. 'spinbutton entry' is working again. See changes in BlueMenta from today.

[raveit65]

I forgot to say the 'grips' i can style in BlueMenta with

MatePanelAppletFrameDBus {
    background-image: -gtk-scaled(url("assets/panel-grid.svg"));
    background-color: transparent;
    background-repeat: no-repeat;
    background-position: left;
}

[lukefromdc]

The difference between #PanelPlug>#PanelApplet { } and #PanelPlug #PanelApplet { }
is that the former cannot accidently match anything else that has something between
those two selectors. In "widget chain" selectors I always seek to use the > character to
limit the match to the exact widget chain I am trying to theme and avoid unwanted
matches.

The "widget" css node works ONLY with versions of gtk3.19.8 built after a commit that
came out yesterday, I buiid gtk3.19 from source each day if anything important
has changed.

https://git.gnome.org/browse/gtk+/commit/?id=f7ec9c98ef0ef8740c93f96af9d971b0211118c1

"Now selecting a widget by class name no longer works.

This is probably most relevant for users outside of GTK that want to
style their own widgets. Those widgets should now either add their own
style classes (if they want to adjust existing CSS) or use
gtk_widget_class_set_css_name() themselves (if they want to get rid of
all "upstream" styling)."

On 2/5/2016 at 11:48 AM, "Wolfgang Ulbrich" notifications@github.com wrote:

Do you see the name 'widget' in gtk3-inspector?
I don't see that with gtk3-3.19.8-2.fc24.
I agree with adding a style class for na-try-applet. Maybe we
should add style classes for all applets?

Btw., what's the different of using (>)

#PanelPlug>#PanelApplet { }

and

#PanelPlug #PanelApplet { }

in general for theming?

I noticed also a change with spinbuttons. 'spinbutton entry' is
working again. See changes in BlueMenta from today.

---

Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-180435551

[raveit65]

Ahh, understand the different now, thx.
I added new style clases:
pluma-window
pluma-print-preview
atril-window
eom-window

[lukefromdc]

GTK Inspector just got harder to use. The no longer used widget names are now
no longer displayed, the css name "widget" plus any style class being all you are
shown now for a custom widget. This may increase the importance of the style
classes for debugging.

While it is also possible to add css node names directly, that is a gtk3.20 and later
only solution, though the older GTK versions would just ignore them and use the
widget names.

Basically, old stuff no longer used withing gtk3.19 is being cleaned out it seems,
hopefully it will stablize soon because GNOME will have to be finalized against
a stable GTK version prior to its own release.

On 2/6/2016 at 1:52 AM, "Wolfgang Ulbrich" notifications@github.com wrote:

Ahh, understand the different now, thx.
I added new style clases:
pluma-window
pluma-print-preview
atril-window
eom-window

---

Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-180708054

[lukefromdc]

What version of Nemo were you using for this commit?
a66c234

.nemo-window does not work with the 2.8.6-1 version in Debian Unstable, and on the Nemo github page I could not find any reference to a commit adding this style class. I suspect it will work in the future though, as Nemo/Cinnamon devs will encounter GTK 3.20 with Debian Unstable probably in May and Ubuntu 16.10 development versions at a similar time. If Mint goes with the Ubuntu LTS again though, they won't actually NEED it to work in their own distro for two years.

The version of Nemo I have can be styled-but only with the long widget chains. EDIT: gtk inspector confirms this style class not present on Nemo 2.8.6-1 from Debian Unstable.

[lukefromdc]

Noticed a Fixme in BlueMenta for progressbar minimum height and widgth:
-GtkProgressBar-min-horizontal-bar-height: 16;
becomes simply
min-height: 16 px

within the relevant selectors. Had to read the actual gtkprogressbar.c source to find this out!

[raveit65]

As linuxmint does not have a focus for gtk+ > 3.18, i helped out with a patch for fedora rawhide.
http://pkgs.fedoraproject.org/cgit/rpms/nemo.git/commit/?id=b65f56bf2343f821229c967bbb734962c3f0490c .
You need to patch nemo-2.8.6.
I guess sooner or later fedora's nemo maintainer will send the patch to linuxmint upstream.

Thanks for the hint for progressbars.

[lukefromdc]

I applied just the nemo_style-classes.patch from there to nemo 2.8.6, it works. Adjusted my theme to it to prevent accidental matches to anything else, figuring it's better to tell users to use a patched build Nemo from the same website (it will go there when the next theme version does) than to have to deal with accidental matches to anything else. Hope that patch goes upstream, I don't want to have to bring those widget chains back. For now I just dumped the modded files into /usr/src and the origin of both the patch and the source download into the changelog so distribution of the Debian package will meet GPL requirements.

EDIT: I just set up this github fork to make the finished code more accessable and easier to maintain:
https://github.com/lukefromdc/nemo/tree/gtk3.20-theme-support

[lukefromdc]

Check and radio boxes also appear in website content and in extension preference dialogs (notably NoScript). Used this code to fix them in my theme, had to split them out from two-part animated checkboxes used elsewhere as a background image can't be used under them in Firefox:

/*for Firefox (FIXME-will this cause unwanted matches?*/
.check:checked  {
    -gtk-icon-source: -gtk-scaled(url("assets/checkbox-checked.svg")); 
}

.check:checked:hover,
.check:active:hover  {
    -gtk-icon-source: -gtk-scaled(url("assets/checkbox-checked-glow.svg")); 
}

.radio:checked {
    -gtk-icon-source: -gtk-scaled(url("assets/radio-checked.svg"));
}

.button {
    border-image: url("assets/button-border-dark.svg") 3 / 3px stretch;
}

Got simliar results fixing scrollbars with .slider, now working on many other theme elements. When I get this done, I will then do the same for BlackMATE, and this will be a guide for fixing these in other themes

[raveit65]

Why .check:active:hover ?
I think this is a remnant from state conversion with gtk+-3.14.
and a hover:active state don't exists for check and radio.
I used only checked:hover in last commits.

[lukefromdc]

Simply copied from what I had been using before, the way many themes
evolve. It has not had a rewrite from scratch since GTK 3.12 when it was
rebased by modifying a different theme than before.

On 4/27/2016 at 3:56 PM, "NO NAME" notifications@github.com wrote:

Why .check:active:hover ?
I think this is a remnant from state conversion with gtk+-3.14.
and a hover:active state don't exists for check and radio.
I used only checked:hover in last commits.

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-215209106

[lukefromdc]

I just uploaded the updated version of UbuntuStudio_Legacy with support for GTK3 Firefox to my usual Archive repo at:

https://archive.org/download/DebianPackagesForMate-desktopWityGtk3AndCustomPanelTheme/gtk-theme-ubuntustudio-legacy-3.21.1git20160504-1_all.deb

When it is superseded and moved into Old_Versions the above link will break but the package will remain available in

https://archive.org/download/DebianPackagesForMate-desktopWityGtk3AndCustomPanelTheme/Old_versions

I would put this stuff on Github but I do not know how to set up makefiles for the normal build system, I might put it there anyway with an INSTALL file explaining that it is only necessary to copy the whole directory into /usr/share/themes and set the correct permissions.

[raveit65]

@monsta
Can you please give Luke a hint how to create a make file?

[monsta]

I can try, but I don't know what should be built with it 😄

[lukefromdc]

The mate-themes include a makefile that guides the installation process.
No binaries are built, but some files get like index.theme get made from
files like index.theme.in, probably for localization reasons.

Without that, "make install" can't install the theme files, and more importantly
the packaging tools used by distros like Debian also break

On 4/28/2016 at 6:36 AM, "monsta" notifications@github.com wrote:

I can try, but I don't know what should be built with it 😄

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-215381619

[lukefromdc]

I just found out why Yelp(help browser) is so hard to theme. Everything in the view contained in it gets hardcoded colors calculated from the base color, the text color-and indirectly from the link color. Yelp makes a temporary link button and uses it's style context to get the color for the text in the (usually)blue box. NOTHING else can theme it, as the application overrides the GTK defaults.

Works OK in all the MATE themes as it stands, though in Green-Submarine-the text in the inner box (blue in most themes) is too bright and could use some darkening as described below. On the other hand, I was getting white text in the light blue box in Ubuntustudio_Legacy. Until GNOME fixed a bunch of style context warnings I got the selected bg color on yelp and at least everything was readable. When that was fixed for 3.20 I had to do some digging. I found it uses the fg color set on a link button, but NOT the color set on a label on a link button, which is what you actually see on a link button! On a theme with dark backgrounds but light views, this will default to a light color and make Yelp nearly unusable unless you know where to fix it.

I set a "fake" link button color just for Yelp, which uses the fg color of the link button itself, then set the color for the label on a real link button to another, lighter value and everything worked. I get the link button labels I want, yet Yelp gets the darker color. For some reason color inheritance often fails for child widgets, but just in case it decided to work after an update, I themed button.link.text-button first, then themed button.link.text-button label, button.link label directly underneath it.

I learned all this digging through Yelp source code with the intention of fixing it there and forking it to my account, then submitting a PR that GNOME would be sure to ignore. Found it could be fixed in themes-and quite independently of what you really want to put on a real link button due to this phony style context. Needless to say, I never saw any documentation of this wierdness.

[lukefromdc]

Has anyone found a selector that works for the Firefox history menu that looks like a popover but ignores popover, .popover, .modelbutton, .menuitem etc?

[raveit65]

The mate-themes include a makefile that guides the installation process. No binaries are built, but some files get like index.theme get made from files like index.theme.in, probably for localization reasons. Without that, "make install" can't install the theme files, and more importantly the packaging tools used by distros like Debian also break

You can try to use obsolete mate-themes-extras as template which is more simple and use index.theme files directly.
https://github.com/raveit65/mate-themes-extras
Every Makefile.am in directories is mentioned in configure.ac.
So, for one theme you don't need the dir desktop-themes, this you need to correct in configure.ac.
I suggest to upload your theme to github and i can help your there with a PR.

[raveit65]

Has anyone found a selector that works for the Firefox history menu that looks like a popover but ignores popover, .popover, .modelbutton, .menuitem etc?

I guess you mean the context menu from * address bar*. Looks like a combobox for me, or old comboxentry which is dropped with 3.20.

[lukefromdc]

Yes, tthat's the one: the history menu from the ittle clock icon on the
toolbar that also includes the address entry(which does not follow the
entry theme).

On 5/2/2016 at 2:11 PM, "NO NAME" notifications@github.com wrote:

Has anyone found a selector that works for the Firefox history
menu that looks like a popover but ignores popover, .popover,
.modelbutton, .menuitem etc?

I guess you mean the context menu from * address bar*. Looks
like a combobox for me, or old comboxentry which is dropped with
3.20.

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-216314840

[raveit65]

Yes, tthat's the one: the history menu from the ittle clock icon on the toolbar that also includes the address entry(which does not follow the entry theme).

That one?
Looks like a dialog window.
........wtf......unusable with submarine themes.....

[lukefromdc]

That's ANOTHER one, and again the hovered item ignores the theme
except for using the color specified for that state. The one I was speaking
of is the "menu" made by clicking on the "clock" toolbar icon, one item
in which is "show all history" from which the dialog is launched.

On 5/2/2016 at 2:45 PM, "NO NAME" notifications@github.com wrote:

Yes, tthat's the one: the history menu from the ittle clock icon
on the toolbar that also includes the address entry(which does not
follow the entry theme).
![bildschirmfoto zu 2016-05-02 20-43-
06](https://cloud.githubusercontent.com/assets/961604/14964004/b673
2f26-10a6-11e6-87f7-eaeeecc821a5.png)
That one?
Looks like a dialog window.
........wtf......unusable with submarine themes.....

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-216324616

[raveit65]

OK, got it :)
I didn't add the clock icon for history to menus here.
And yes this looks like a popup and isn't styled by ie. submarine themes.
...firefox is a mess.

[raveit65]

Maybe you find a hint here https://developer.gnome.org/gtk3/stable/GtkPopover.html

[lukefromdc]

As usual, the popover css node style is ignored in Firefox, and no
.popover style class is being set. It's supposed to get .menu but that
too is ignored with Firefox.

.menu:hover .menu menuitem:hover and even .menu *:hover are all
ignored

On 5/2/2016 at 3:25 PM, "NO NAME" notifications@github.com wrote:

Maybe you find a hind here
https://developer.gnome.org/gtk3/stable/GtkPopover.html

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/mate-desktop/mate-
themes/issues/101#issuecomment-216336038

[lukefromdc]

I just added https://github.com/lukefromdc/gtk-theme-ubuntustudio-legacy to my repo containing the "UbuntuStudio_Legacy" GTK theme, which is an otherwise medium dark theme with white views.
Will work in GTK 3.14 through GTK 3.20 and in GTK 3.21 as of today's version due to versioned subdirectories.

For now no MakeFiles are present as I have yet to figure them out, but it can be installed by simply dragging the entire directory into /usr/share/themes and setting the permissions correctly.

Found these directions for getting around the GIT errors that had stopped me until now on StackOverflow:

git init
git config user.name "someone"
git config user.email "someone@someplace.com"
git add *
git commit -m "some init msg"

I hope the fact that the original UbuntuStudio theme was published under Creative Commons Attribution-ShareAlike 2.5 License Agreement and the later themes used to get things working under GPL v3 does not create compatablity issues that prevent redistribution by MATE or on Github. I have little understanding of that sort of thing and NO ability to resolve it beyond asking the UbuntuStudio development email list if anyone objects. I will continue to use the theme myself with or without redistributability.

Due to contributions from others under two different licenses I dual-licensed my own contributions (now the bulk of the code) under both licenses, but am NOT concerned about which license, any, or none my own contributions must be licensed under and have no objection to relicensing my own contributions. Very little is left of any of the GPLv3 themes I got help from, could resort to "fair use" for those cases if I need to relicense/dual license my own contributions. Public domain fine for my own part of the work. Most contributions from e17GTK are to GTK 3.18 and earlier, as GTK3.20 forced a radical rewrite.

[raveit65]

Some questions:
For what you need the gtk-2.0-key dir?
'UbuntuStudio_Legacy' is the theme name and the name under /usr/share/themes/ ?
I'm not very good in license questions but here is a link to GPL.
https://www.gnu.org/licenses/licenses.en.html

[raveit65]

I added the necessary make and configure files at the forked repo.
https://github.com/raveit65/gtk-theme-ubuntustudio-legacy
But i don't know how to handle the symlink 'assets' in make file.
The make command failed if i use it as folder or as file in make file.

[raveit65]

Done, feel free to ask me if you have questions.
Or visit us at irc freenode channel mate-dev

[raveit65]

Found these directions for getting around the GIT errors that had stopped me until now on StackOverflow:

git init
git config user.name "someone"
git config user.email "someone@someplace.com"
git add *
git commit -m "some init msg"

You should find now those settings in ~.gitconfig.
It's also possible to use a ssh key for connecting with github.
https://help.github.com/articles/generating-an-ssh-key/

[raveit65]

I forgot to tell, this is the explanation from gtk+ dev M.Clasen why we can't use gtk3-inspector for firefox.

<mclasen> raveit: GDK_BACKEND=x11 GTK_DEBUG=interactive firefox works here
<raveit65> mclasen, yes that works, but i can only select the main frame 'window.background widget'
<mclasen> raveit65: the toplevel may be all there is... firefox is not generally using gtk widgets, it just uses gtk for drawing

[lukefromdc]

Thanks, I really appreciate this. Merged your changes back to my repo and got a successful buiild and install the same way I do the MATE themes, so that works. Debian package built and installed fine, it's at https://archive.org/details/DebianPackagesForMate-desktopWityGtk3AndCustomPanelTheme superseding previous versions due the the change to dual licensing my own contributions under both licenses used by others

As for the theme name, that's what I've always used in /usr/share/themes, didn't know of any other name to use. Future work might be to add a "blue" version with the original UbuntuStudio blue color and keep the "green" version in which case the internal names would have to reflect that. This would go well with the "Traditional" and "Submarine" themes which both have blue and green versions. I already have most of the needed image assets for this.

Bumped the version to 3.21.1 to match the maximum supported GTK version the way MATE themes are versioned-and because published versions on Archive had already reached 2.1.4 over the years. Versioning took over from UbuntuStudio's version 0.28 with an 0.3 back in March 2011 that was my first rough GTK3 port. New packages start with 0.1, but in this case that would have been UbuntuStudio's first theme experiments as this is a follow-on.

Next up: the UbuntuStudio-Legacy icon theme and more BlackMATE/Gedit experiments

[raveit65]

I added a style class .tooltip to marco.
mate-desktop/marco@4ab26c4
Now min/max/menu/menu buttons are matched with that selector.

[raveit65]

Et voila,
using .tooltip fixes firefox tooltips :)

[raveit65]

Ok, i fixed that for BlackMATE too, feel free to adjust the settings.
I found out that tooltips match on .csd selector.

[lukefromdc]

Just found that GreenLaguna's window controls work in Gedit. The key is that GreenLaguna uses headerbar unconditionally, not headerbar.titlebar as the selector. I first themed all CSD controls in UbuntuStudio_Legacy to match SSD apps for the first time, then applied this to BlackMATE with
4a59477

[raveit65]

I opened a new topic for communication.
#119