Cinnamon: All dialogues now bordered regardless of theme.

[azariah001]

So I'm on Antergos Arch running Cinnamon 3.2.1 and ever since yesterday, when I updated Cinnamon to 3.2.0, all of the panel dialogues regardless of whether it's the Menu, Calendar, Network, Sound, etc. have this border around them. Pre-update this wasn't there and I don't want it there, I've tested this by changing my theme to the default 'cinnamon' theme and a couple of others and the borders persists completely unchanged by any of the themes.

Why? Please fix, it's an eyesore.

Screenshots:

[Odyseus]

Hello, @azariah001.

This isn't a Cinnamon issue. Cinnamon 3.2.x uses a new class for menus (menu). All themes need to be updated to reflect this change.

In the mean time, you can edit your themes by adding something like the following to the cinnamon.css file of your theme:

.menu {
    border: none;
}

Depending on the theme, the changes will be more or less complex.

[azariah001]

Ok thanks for the reply but I still question why border: none; isn't the default, if only for the sake of reducing the impact of this change. Because currently, it's a breaking change that's going to cause issues across every single existing theme, some of which may not have an active developer behind them currently.

Now that I'm aware I'm going to be sure to assist with changes to the theme I'm using but yeah the decision for the default value still bugs me. And this isn't the only change either, just noticed that the font color declarations aren't working as expected either. I guess this is what I get for living on the cutting edge. :stuck_out_tongue_closed_eyes:

[Odyseus]

Well, I just suggested you border: none; because you said you wanted to get rid of the border. But the vast majority of Cinnamon themes uses some kind of styling for their borders on menus. And using border: none; by default would have been even more horrendous in my opinion. LOL

This is what I did to make my Mint-X based themes to set the correct appearance to all Cinnamon menus.

Original CSS not compatible with Cinnamon 3.2:

.popup-menu-boxpointer {
    -arrow-border-radius: 4px;
    -arrow-background-color: #ececec;
    -arrow-border-width: 1px;
    -arrow-border-color: rgba(40, 40, 40, 0.3);
    -arrow-base: 18px;
    -arrow-rise: 10px;
    -st-shadow: 0px -1px 2px 0px rgba(255, 255, 255, 0.9);
    -boxpointer-gap: 2px;
}

.popup-menu {
    color: rgb(70, 70, 70);
    min-width: 100px;
}

.popup-menu StEntry {
    /* CSS */
}

.popup-menu StEntry:focus {
    /* CSS */
}

CSS compatible with Cinnamon 3.2:

.popup-menu-boxpointer {
    -/* CSS left untouched for retro-compatibility */
}

.popup-menu {
    -/* CSS left untouched for retro-compatibility */
}

.menu {
    border-radius: 4px;
    background-color: #ececec;
    border-width: 1px !important;
    border-color: rgba(40, 40, 40, 0.3);
    color: rgb(70, 70, 70);
    font-size: 9.5pt;
    min-width: 100px;
}

.menu StEntry,
.popup-menu StEntry {
    /* CSS */
}

.menu StEntry:focus,
.popup-menu StEntry:focus {
    /* CSS */
}

As you can see, it wasn't that complicated. I just _merged_ the styles of two unused classes (popup-menu-boxpointer and popup-menu) into the menu class and I also added the menu StEntry selector so it can also modify the search boxes.

I could assist you further, but first you should close this issue.

[dobragab]

Is there a collection of _breaking changes_ in Cinnamon 3.2 or do theme maintainers have to find them by debugging?

[JosephMcc]

The main one is the menu. The other is of course the vertical panels that themes need to add support for.

[dobragab]

Don't you feel you should provide some extra information about breaking changes, like deprecated or ignored stuff, behavior changes? Maybe an upgrade guide around README.md would cause that theme devs won't have to track down what you've exactly changed all over the API that you must know about.

[JosephMcc]

Possibly, but keep in mind that I don't think we actually released this yet to Mint users which are our main priorities. The arch maintainer jumped the gun with releasing this on Arch. That can clearly be seen by all the Arch specific issues being opened because it was released before all the parts were even tagged at new versions and with all sorts of missing dependencies.

[collinss]

@dobragab There is a blog post in the works that explains the changes to theming the menu, but it hasn't been completed yet due to lack of time and technical difficulties on my end which should be resolved soon.

[dobragab]

@JosephMcc

_Possibly, but keep in mind that I don't think we actually released this yet to Mint users which are our main priorities._

So you just added Release label 3.2.0 without feeling an urge to actually release it to your users? Well, this is a common thing but there is a commonly used word for this kind of release: beta.

_The Arch maintainer jumped the gun with releasing this on Arch._

Yes, Arch maintainers released some packages without proper dependencies, keeping some packages at 3.0.7. This issue has been already resolved, but all themes still look s**t.

Are you expecting non-Mint maintainers to watch packages released to Mint / Ubuntu? You've decided to keep Cinnamon a separated project from Mint, and this Github page is THE source. This is the place where you should express that a version is stable, not Mint packages.

It messed up all existing themes, without even noticing _anything_ around the README.md, the release tag, or the release notes. These are the places one should look at before releasing this to e.g. Arch, and nothing has been put there about breaking changes. Which is mostly interpreted as if there were no breaking changes. You just misinformed everyone that this version is stable. Even theme maintainers, who will find out their theme is broken when they actually get the Mint package, which is way too late.

However, releasing a package that contains breaking changes is welcome if you flag it as beta: it tells the theme maintainers that they should upgrade their themes, it even helps them with developing by providing a preview version. This is how it's done in software culture.

@collinss

Great, thanks! This should have been out along with 3.2.0 beta...

[collinss]

@dobragab This should have been posted BEFORE Cinnamon 3.2 was tagged, but I have a life, and it's been busy lately. That's what you get with open source. This isn't my job. I just do it for fun, and things like job and family usually take precedence.

[dobragab]

@collinss don't get me wrong, I'm not blaming you personally, I'm not saying you should have posted this earlier, but the other way around. A post like this should be essential part of the release.

I'm saying that you (plural) should not have released 3.2.0 without proper release notes about breaking changes. Practically you should have waited with 3.2.0 until someone writes a nice description about this. And still, 3.2.0 should have been flagged as beta to give theme maintainers a chance for the smooth upgrade.

As this is already messed up, I suggest you should pay attention to this thing next time. I'm not asking much, just better timing and a bit different release tags. If you edited 3.2.0 tag with some warning about breaking changes, that could prevent further harm and maybe warns theme maintainers.

I have a busy life too, this release just made it more complicated. I know what I get with open source, and I've never seen "silent breaking changes" without any notice in any popular open source project. It takes just a little effort.

[collinss]

Technically, Cinnamon 3.2 hasn't been officially released yet as evidenced by the lack of a blog post to that effect. I believe there is an issue or two that need to be fixed before then, but I've been a little bit out of the loop the last few days.

Also, the alternative in this case would be to delay the release process in order to wait for such a post, which would make a lot of people unhappy, and doesn't really make sense. And since it hasn't been released yet (tagging is NOT the same as releasing to the public), there shouldn't be any expectation that such information needs to be provided right now.

[dobragab]

Technically, 3.2 is released, but not officially announced. Look at Cinnamon's official Github page, under Releases tag. There you can see 3.2, there are archives containing the source code as well. Github is the main source of information, this is what you get with open source. I'm not the only one who thought this was a release.

_Also, the alternative in this case would be to delay the release process in order to wait for such a post, which would make a lot of people unhappy, and doesn't really make sense._

Yes, it's your job to decide which is worse, a possibly delayed or a premature release, but my bet would be the latter. Mint users, who are your main priorities, usually get packages in delay anyway. And you can see many unhappy users submitting issues from Arch.

_I believe there is an issue or two that need to be fixed before then_

You just said it should have been tagged as beta.

[azariah001]

Ok, so, I work in software development and understanding how semver works in the context of NPM and Bower gives me some perspective here. If you tag a commit with an explicit version number you are indicating that it has been tested and is ready for use in some way shape or form. And regardless of whether you're ready or not that will get pushed out to users, simply because you've tagged it. That's just how software works, it's just zero's and one's after all.

Now with NPM and Bower they are thankfully smart enough to use filters so that people have to explicitly change the tag from 0.0.x versions for their installations to 0.x.x or (a really bad idea) x.x.x But to drive a point home here. If you tag a version of your codebase as x.x.0 that is considered tagging as stable and final and the various package management systems, in this case the AUR, will automatically push out what it thinks is a stable release. Now that release can contain minor breaking changes but unlike an x.0.0 release there _should_ be fallbacks and aliases in place to minimise breakages.

Oh and btw having had cause to read the package files that come from the AUR for a lot of projects there aren't any actual maintainers that manually check that there's an actual release and flag it as an update. The local machines just execute the package file's that just check to see if the source repository has a new release tag and if it does, then performs an upgrade.

It's pretty clever but for those unfortunate enough to have their development repository tracked by the AUR directly they need to be aware that any and all releases will be pushed out to users with no intervention required by a third party. Ideally for the developer, and this is basically what happens with Ubuntu repositories, the repository is basically a mirror of the development repository which means that updates are only pushed when the maintainer tests and merges code from a release on the master. But those of us on Arch like our packages kept super crispy and fresh so we live at the mercy of the developers.

For example, I've had a few jenky updates recently including one that borked the lightdm login dialogue and another in the same lot of updates that prevented all file managers from reading any mounted partitions. You could see the files in terminal though which was weird, but anyway they've all since been patched. So I'm not unhappy about this as such as this breakage was a lot more minor than others I've had to deal with recently but... like this is UI we're talking about so tiny things can easily kill usability. Bottom line please be more careful in future because once you tag a release any further changes to that release are considered hot patches and that's suboptimal for everyone, developers included. :smile:

[ghost]

@azariah001 I'm agree with you, in an ideal world that will be the best, but linux and specially for cinnamon, it' s not an ideal world. So, as the development take on consideration what user want, some changes will be placed before the release when user test the product and he can emit his comments... In my opinion then, will be in this context, very difficult to know if 3.2.0 it's more stable than 3.2.5, in the case of cinnamon i will said that's not possible, 3.2.5 will be more stable... This is taking in consideration my historical appreciation, that of course it's subjective, to the set of specific features that i use more.

Out of all this, I don' t know the reason of why cinnamon jump from version 3.0.7 to version 3.2. This is in my opinion a more dramatical change that really can cause some controversy...

[dominichayesferen]

@lestcape The only reason I can think of for the dramatic version bump is Vertical Panels, No boxpointers, and the new Applet Configurator / Lockscreen

[ghost]

@feren I don't think so, when you do a big change, have more sense to me and it's more important for me release a new version, otherwise you can not receive a good user feedback, because you will need to find what big change is the cause some issue and it's more difficult in this context. Normally it's preferable release a new version and while user test the change, you can continue the development. It's in any case more efficient separate the things.