raveit65 commented 8 years ago

themes needs a rewrite to 3.20

raveit65 commented 8 years ago

@ 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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

lukefromdc commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

See https://github.com/mate-desktop/caja/commit/5b56a80e6d57e2d4d1236dfcd7683f377d29bb5c 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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

lukefromdc commented 8 years ago

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 ? https://github.com/mate-desktop/mate-terminal/issues/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 commented 8 years ago

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 ? https://github.com/mate-desktop/mate-terminal/issues/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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

Got the panel tray icon padding working again for gtk3.19.8 with this code:

PanelPlug>#PanelApplet {

-NaTrayApplet-icon-padding: 1px;

}

raveit65 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

lukefromdc commented 8 years ago

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 commented 8 years ago

What version of Nemo were you using for this commit? https://github.com/mate-desktop/mate-themes/commit/a66c23491fcc6acb6040ae00c465c20a770ea6e4

.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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

raveit65 commented 8 years ago

I noticed that .caja-notebook .view { } styles now icon view again with 3.19.8-4. Can you confirm? And maybe we can revert https://github.com/mate-desktop/caja/commit/e5c29655e5301b6d4ba19a3d4970745804039c0e ? What do you think?

lukefromdc commented 8 years ago

I just did some tests with today's gtk 3.19.9 and here's what I found: caja-notebook .view { } is styling the very scrolledwindow I attached the .view class to, and that is what you are seeing. The icon view itself also catches it but applies it only to the rubberband, theming it solid color unless explicitly re-themed. The icon view widget (icon container) remains transparent. I don't normally get the rubberband issue because the main .view and rubberband are themed together in my theme so that's all the .view style class on the icon container catches unless it is explicitly overridden as your code will do.

I proved this by using .caja-navigation-window scrolledwindow.view {} to set the scrolledwindow transparent explicitly, equivalent to reverting the commit so far as icon views are concerned. The result was the background window color (gray in my theme) showing through plus the rubberband being themed solid white (the theme base color) since the explicit theming of that one view overrode the general .view rubberband style and wasn't included in the test. GTK inspector still shows the "background-color" as white (in my theme) but it is not actually applied to the overall background in this widget-not in Caja, not in Nemo, not in Nautilus 3.19.2 even.

Nothing has changed for the better concerning this in any GTK 3.19 version I've gotten from git master since the problem first started. GNOME's Adwaita themes always use similar base and background colors, so it doesn't seem to bother them.

Reverting this commit would thus once again force an unconditional theming of the scrolledwindow, bringing back the unremovable white squares at the top of list view scrollbars in themes with white views and dark background colors. The point to my commit was to theme the scrolledwindow when and only when it contains an icon view.

You didn't get a patched version of GTK 3.19 by any chance? I've not seen any version 3.19.8 dash anything in GIT master, so I am assuming this was a binary build from someone else.

lukefromdc commented 8 years ago

These two screenshots show the effect of being able to single out scrolledwindows containing icon views/compact views only. In Caja my commit attaches the style class only to scrolled windows containing icon/compact views, so when a list view is selected the scrolled window looks as it should. Nautilus does not have this, so to put the white background in the icon view it must be applied unconditionally to the scrolled window or a widget containing that scrolled window. Thus with my white icon views and medium gray background color, you get the white squares. The only fixes are to either use overlay scrolling (ugh!) or patch Nautius too. Were I putting out a public distro using Nautilus I would still have to do exactly that. This is GTK 3.19.9 just built today(Feb 18) from unmodified GIT master, Nautilus 3.19.2 also from GIT master a couple days ago, and Caja from GIT master as of yesterday (Feb 17).

reverting https://github.com/mate-desktop/caja/commit/e5c29655e5301b6d4ba19a3d4970745804039c0e would either put the white squares seen over the Nautilus scrollbars on Caja too in any similar theme using white views, or force use of views the same color as the background color

nautilus_scrollbars

caja-scrollbars

lukefromdc commented 8 years ago

Here's what GNOME just did for Nautius, and yes, it leaves the white scrollbar tops in list views when dropped into my theme. Those are also visible in Adwaita, though the difference is faint there. They said they got a white window "by luck" into now.

.nautilus-window notebook,
.nautilus-window notebook > stack {
    background: white;
}

This does have the advantage for them that these widgets are explicily set transparent for the desktop, so they don't have to theme it back out again for the desktop icon view. They've had a lot of issue with widgets that draw their color on the desktop, making Nautilus very tricky to theme.

Wonder if I should fork Nautilus with the same patch, it would solve their problem...

lukefromdc commented 8 years ago

Here's what GNOME just did for Nautius, and yes, it leaves the white scrollbar tops in list views when dropped into my theme. Those are also visible in Adwaita, though the difference is faint there. They said they got a white window "by luck" into now.

.nautilus-window notebook,
.nautilus-window notebook > stack {
    background: white;
}

This does have the advantage for them that these widgets are explicily set transparent for the desktop, so they don't have to theme it back out again for the desktop icon view. They've had a lot of issue with widgets that draw their color on the desktop, making Nautilus very tricky to theme.

Just submitted this PR for Nautilus since they are now using a workaround that only helps Adwaita:

https://github.com/GNOME/nautilus/pull/12

raveit65 commented 8 years ago

You're right, i was a bit confused that the bg color was fine with blue-submarine out of box, without porting mate-applications.css to 3.20. Of course with your commit the setting for .view in gtk-widget.css will apply to caja. Sorry for that noise.

raveit65 commented 8 years ago

I' ve add more style classes and css names to code: mate-media --> css name GvcMixerDialog eom & atril --> css name EggToolbarEditor atril --> atril-window style class at top level eom --> eom-window style class at top level mate-terminal --> mate-terminal style class at top level pluma --> style class pluma-window and pluma-print-preview caja --> style class caja-property-browser mate-panel --> style class wnck-pager mate-panel --> css names MatePanelAppletFrameDBus, PanelSeparator and PanelToplevel

raveit65 commented 8 years ago

Well, i finished porting Blue-Submarine for now, i think most stuff works now with gtk+-3.19.10. I expect more adjustments until gtk+ is stable or later, but B-S is good at this point. So, my question, should i sync Green-Submarine with Blue-Submarine, or do you want to maintain Green-Submarine as independent theme ? I don't want to break your nice work. Maybe you want to mantain BlackMate which will help me a lot and we let B-S and G-S as sister themes only different in colors? I will start now with porting TraditionalOk (clearlooks). Anyway, thanks for your help here and in other packages.

lukefromdc commented 8 years ago

Go ahead and sync it up, I've got my hands full mantaining one theme and a whole bunch of Debian packages that are published on Archive. It will be easier to mantain the two themes if they are based on the same code, and my version has gotten a little old.

BlackMATE I should be able to handle, though since I only do work other than theme work in my own theme I will need to get reports of issues with it. I will go over it for any obvious issues with the current GTK 3.19 and again at release of 3.20.

On 2/26/2016 at 5:07 PM, "Wolfgang Ulbrich" notifications@github.com wrote:

Well, i'm finished with porting Blue-Submarine for now, ithink most stuff works now with gtk+-3.19.10. I expect more adjustments until gtk+ is stable or later, but B-S is good now. So, my question, should i sync Green-Submarine with Blue- Submarine, or do you want to maintain Green-Submarine as independent theme ? I don't want to break your nice work. Maybe you want to mantain BlackMate which will help me a lot and we let B-S and G-S as sister themes only different in colors? I will start now with porting TraditionalOk (clearlooks). Anyway, thanks for your help here and in other packages.

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

lukefromdc commented 8 years ago

Ugly breakage to scrollbars and scales sliders today (2-29-2016) caused by a very late sequence change to gtk3.19.10 from git master. Lots of work to fix in first my theme, then BlackMATE. Results at https://github.com/lukefromdc/mate-themes/tree/BlackMATE-gtk3.20

Mostly works except that arrows on scrollbars (not used in Adwaita) point the wrong way. Fixed that in my own theme with force-loaded icons on the buttons but should be able to revert it if GNOME fixes that bug. Had to leave that out of BlackMATE after github didn't take the svg images for it.

To raveit65: Blue-Submarine et all now need more work as soon as you get this update, you may have to wait a while for it if not building gtk3.19 yourself, may WANT to wait a while in case more of this bullshit is coming down the line. Many more items concerning sliders and troughs needed to have min-width and min-height explicitly set and background handling also changed. Bunch of scale, range, and "gadget" changes that should have been done much earlier as GTK3.20 is getting close to release time!

raveit65 commented 8 years ago

Well, as expected damage.inc breaks more stuff which they dont use for their own theme. I noticed that GtkArrow is gone in several places, ie. menuitems. If you want use symbolic arrows you can use first - last-child logic to terminate the scrollbar button. Ie. scrollbar.vertical button:first-child --> top button scrollbar.vertical button:last-child --> bottom button

BlackMATE I should be able to handle, though since I only do work other than theme work in my own theme I will need to get reports of issues with it.

Thank you, i will ask Clem or Stefano to give you commit rights for mate- themes. Than you should receive a mail if someone report a issue and you can commit directly.

raveit65 commented 8 years ago

Upps, i see you use scrollbar.vertical button.up/down

lukefromdc commented 8 years ago

I actually HAD to do that, because I found GTK using up and down for left and right scrollbar buttons too. This is probably a GTK bug, and probably related to the arrows pointing the wrong way. I had to force a temporary solution in my own them and this is part of how I did it. Thanks for allowing me to work on BlackMATE directly, it will make things easier.

raveit65 commented 8 years ago

You're welcome, ....not only for mate-themes, you're member of artwork-maintainer team https://github.com/orgs/mate-desktop/teams/artwork-maintainers which include also access to icon-themes. Maybe you visit us as mate-dev irc chanel at freenode.

raveit65 commented 8 years ago

I forgot to say, please keep 3.20 branch in sync with master. Because we create tarballs not from master. I created branches for every gtk+ version, which is the only way to handle the differents. For this reason i mention in every commit header if a commit is only good for a specific gtk+ version. If a commit is good for all branches than feel free to cherry-pick them to all branches (include master). Syncing is easy with the git cherry-pick command.

'git clone git@github.com:mate-desktop/mate-themes.git'
'git log' , which gives you the commit id.
'git checkout gtk3.20' , to switch to 3.20 branch
git cherry-pick command-id , from the commit from master shown by git log
'git push' , if all is fine.

That's all......feel free to ask me if you need help with git. If you add an image or any other file, you need to add it to the Makefile.am file in folder, otherwise the file won't get in the tarball. But i can do that for you, np, only inform me.

lukefromdc commented 8 years ago

For some reason https://github.com/mate-desktop/mate-themes/pull/106 to sync up GTk 3.20 with master cannot be auto merged. I don't have the bandwidth available where I am sitting right now (at home) to clone the repo thus cannot use the command line instructions. I will clone it sometime when I am on the road and can use wifi. I don't have a landline at home at all. All changes are to BlackMATE only but there is a conflict somewhere.

raveit65 commented 8 years ago

Ok, i will look into it , np

raveit65 commented 8 years ago

Ok, all cherry-picked to 3.20 branch, hope i did not forget something. I 've no clue why some commit didn't clean apply, i guess it comes from the PR. The order of the commits are different but the context should be the same, please check this. Anyways, i suggest to work directly on the upstream repo to avoid using PRs and having the merge commits when you update your githup repo with upstream repo. Normal i use PRs only if i make a bunch of changes which are critical and i want that other people test this, ie. caja desktop flash fix PR. But this should not be needed for themes.

A hint, before you change and commit something use 'git pull' to keep you local repo up to date, to avoid a resulting merge commit. And simply cherry-pick one commit to another branch before you commit more, this makes it simple. Git-gui is a nice GUI to work on git repos, very useful for the beginning.

Don't worry, you will learn that....everything is fine :smile:

lukefromdc commented 8 years ago

At least I've now got the local repo to work with

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

Ok, all cherry-picked to 3.20 branch, hope i did not forget something. I 've no clue why some commit didn't clean apply, i guess it comes from the PR. The order of the commits are different but the context should be the same, please check this. Anyways, i suggest to work directly on the upstream repo to avoid using PRs and having the merge commits when you update your githup repo with upstream repo. Normal i use PRs only if i make a bunch of changes which are critical and i want that other people test this, ie. caja desktop flash fix PR. But this should not be needed for themes.

A hint, before you change and commit something use 'git pull' to keep you local repo up to date, to avoid a resulting merge commit. And simply cherry-pick one commit to another branch before you commit more, this makes it simple. Git-gui is a nice GUI to work on git repos, very useful for the beginning.

Don't worry, you will learn that....everything is fine :smile:

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

raveit65 commented 8 years ago

gtk+-3.19.11 was landed in fedora 24 and could fix notebooks, srollbars, scales and spinbuttons in Submarine themes. But GtkSale and GtkColorScale is a little bit weird, without using margins and paddings you see no sliders, here i expect more changes from gtk+.

lukefromdc commented 8 years ago

You have to use the min-width and min-height CSS properties to make more and more widgets show up, as they increasingly default to zero and disappear.

On 3/5/2016 at 7:49 AM, "Wolfgang Ulbrich" notifications@github.com wrote:

gtk+-3.19.11 was landed in fedora 24 and could fix notebooks, srollbars, scales and spinbuttons in Submarine themes. But GtkSale and GtkColorScale is a little bit weird, without using margins and paddings you see no sliders, here i expect more changes from gtk+.

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

mate-desktop / mate-themes

theme dev talk #101

PanelPlug>#PanelApplet>widget>widget

PanelPlug>#PanelApplet {