Hmmm, it looks like Nemo is preinstalled. So, can you remove Nautilus and make Nemo file manager by default?
1 Like
My dream is turning into reality… Man, gonna help this project the way I can!
Kudos from Brazil!
3 Likes
Do you plan to release a guide or a howto to manually configure an stock Ubuntu to Ubuntu Remix. I have Ubuntu 18.04 with Unity and I have no plans to reinstall my system rather than upgrade it.
I am mainly interested in enable cliend-side decorations globally.
Indeed. It’s hard to mantain good old Unity. Do you guys have a roadmap?.
The first task is to test and identify the bugs before to add something new. There are some ideas of features, but we need to build “the base of house” first.
3 Likes
@toptnc I’ll be writing a script soon with which people can upgrade from stock Ubuntu to Ubuntu Unity Remix.
I recently removed CSD on popular demand.
3 Likes
I look forward to trying it out.
1 Like
I have tried installing Unity on 18.04, 20.04, and always have a problem about visual consistency. That is why I still running 16.04 as it’s still supported
The cause of your visual consistency is not the desktop itself but the specific applications of GNOME. This was not a problem in 16.04 because of this project: Bug #1131664 “The default apps should have standard menubars und...” : Bugs : Ayatana Design but it’s right now a problem because the project was discontinue. See the last message.
As i said is not just a problem of an specific desktop. Is also the reason of why i discontinued the Global Menu in gnome-shell. So, this is a big problem of consistency to Linux in general. GNOME people just break all things with his HIG.
3 Likes
Thanks for the link. Yep, I saw your reply on askubuntu and removal of headerbar patches and impact on Unity discussion. It explains everything
1 Like
Sorry guys I’m a noob. What are Client Side Decorations (CSD)? What’s the point of having them enabled or disabled?
Do you remember the Nautilus in 16.04? It had a title bar. Since then, the Gnome community modified the nautilus and others gnome applications to have a merged header bar plus title bar. The debated is about whether we must force the applications with CSD to have a title bar.
My personal opinion is that not, because the title bar is created using a patch, which one day (depends of modifications by Gnome), can stop to work, and we have a lot of work to do.
The applications which aren’t developed by Gnome will keep its own title bar (whether they have one). About the CSD applications, they fits perfectly in Unity.
The prove of it that the only one other SO which has a global menu is the Mac OS X, and all applications developed by Apple (and some of other enterprises) use the CSD pattern.
And whether you want the title bar, you just need to install a library of ~150kb called “libgtk3-nocsd”
Sorry guys I’m a noob. What are Client Side Decorations (CSD)? What’s the point of having them enabled or disabled?
The are basically two ways of decorate a windows. The Client Side Decorations (CSD) and Server Side Decorations (SSD). See the picture:
We have in red the area that is painting by the application itself (CLIENT SIDE) and in blue the area that is painting by the windows manager (SERVER SIDE). Note this is an approximation, where we don’t included the windows borders and shadows. In the left there are a window that was decorated with SSD and in the right a windows that was decorated with CSD. Also note that we called SSD to something than in practice have both type of decorations, because in the picture just the titlebar was decorated in the side of the server. Actually the server side decoration what it does is create a container (box) on the server side with a title bar at the top and then puts everything that was decorated on the client inside this container.
The SSD are the traditional Linux way to paint windows while the CSD is a relative new implementation in Linux made by GNOME. As it’s relative new it have not a good support outside GNOME. One link that can help you to understand the problematic and the decision of Microsoft about the usage of CSD, can be found here . Please read it fully.
Basically if all is implemented ok in all environments, you can emulate the same result of a SSD in a CSD implementation. So, CSD is a more general way to decorate the windows, but as the decoration is in the side of the application, is the author of that specific application who need to decide how it want to decorate his window. As you can notice, this introduce more flexibility and then more different ways of decorate a window. So, this fully break all uniformity of your desktop, as some developers can decide made one thing while others can decide made a different thing. In that context the user behavior are lost, because one application can look like in one way, while another in another way. To make it much more complicate, GNOME decided do NOT emulate the SSD in his CSD, and then his applications are look like really different than the traditional onces.
How now you can have several different representations of the same application, is necessary make explicit how a desktop want his applications and this is why is now commons speak about HIG. This concept was not needed before because all Linux applications was looking more or less the same. Now this is not true (thanks to GNOME). In fact is worse, because the GNOME HIG is changing in the time, and it’s much more difficult to be follow by the developers. So one application can follow the version 3.32.1 while other can have the 3.16.2, because his author don’t update it yet to the last version. To me this is just crazy and specially in Linux where we know people work more for love than for money.
In that context, GNOME begin to forced his own developers to support CSD, when in some cases is clear they don’t want to do it. Also they try to force others external Gtk developers to support it only explaining the advantage of CSD inside GNOME, but hiding the disadvantage outside it.
On the another hands and to satisfy both perspectives, some applications decide to support both types of decorations, like was gnome-terminal and firefox. So, this is why is now a decision of the user what type of decoration it want to use and then I hope read this will help you to understand the point of having them enabled or disabled…
I wrote also something relate to CSD here:
https://askubuntu.com/questions/1050378/for-ubuntu-18-04-is-there-a-way-to-show-drop-down-menus-for-a-certain-applicati/1050565#1050565
This is the vision of the KDE developers about the GNOME way:
Also i will need to add, that others external GNOME developers think that CSD just break the Linux way and they try to fix that problematic creating a hack to force to disable the CSD. This is the case of the library called gtk3-nocsd. Just read what think his author, who is a developer of the LXDE and LXQT desktop, about it here.
In LinuxMint the solution to the GNOME CSD iniciative was that the Mint developers create a different set of applications called XApps, to fork all GNOME core applications and continuous making it SSD. As his principal developer and author of the LinuxMint project Clement Lefebvre said:
GTK itself and many of the GNOME applications now integrate better with GNOME Shell and look more native in that environment. The bad news, is that they now look completely out of place everywhere else.
3 Likes
Wow, that was a GOOD explanation, thank you! I agree with all of the statements made in the articles. While visually appealing, CSD give a lot of problems, expecially with GNOME implementation (without a global menubar). This last decision by gnome is to me the reason we should entirely drop gnome core applications and CSD in unity, using MATE or Cinnamon xApps. I love global menubar and Unity is the only DE in the linux space to actually support them out of the box. So we should do whatever we can to preserve this functionality and them work! GNOME is encouraging people to use hamburger menus, so they are killing global menus this way. I think we should conform to other Linux DEs and avoid using GNOME apps outside GNOME. In alternative we could develop a patch that forces menus in the hamburgers to also show in the menubar. But I don’t know if it’s feasible.
In alternative we could develop a patch that forces menus in the hamburgers to also show in the menubar. But I don’t know if it’s feasible.
Any modification that you create from outside an application is called a hack and also even when technically is possible, made this is really complex and your code can be break in any update of the upstream app. Also the change can not be general, because all applications have a different set of actions. This is not at same as how gtk3-nocsd work and how is implemented the unity-gtk-module and his appmenu-gtk-module fork of the vala-panel project (where i’m a developer), because what that projects are doing, is the same to all applications.
Any way, I was trying to make this possible, but at same time the Gtk developers was working to prevent that this will be possible. The result was i lost the interest on make it. It’s to much of work make it with the Gtk developers help and try to make it working against hims, is really almost impossible.
Well you don’t really need gtk-nocsd, gtk-mushrooms will do the trick. Just recompile gtk(3) with with a simple patch (I only take nocsd patch there are many other patches). I use all the time with ubuntu-mate. Since gtk3 api is stable it will work all the time.
As for applications, patched version of nautilus 3.26 (which has desktop) is still maintained. It is more powerful, doesn’t use buggy memory leak app like tracker, works very well on traditional desktop environment like unity,mate. I also use a patch for nautilus-share which lets you send file not just email but to bluetooth, imgur, gdive etc.
I use patches for all the gnome app I use with traditional menus without csd and with extra function like deep integration with desktop. Eog, file-roller, evince, gnome-calendar, eds (for calendar notification).
I am lazy. I don’t make those apps for myself. Instead I let them do the coding and then bend it to my will.
There was a proposal before or rather a dream. To bring Mate, Budgie, Cinnamon, Xfce teams together. Create HIG, make modern common xdg apps which will work on all environment, for example it will use csd on budgie but ssd on mate depending on simple gsettings key. There will be common settings-daemon and common control-center which will share same codebase but work differently on different desktop sessions. A concept like xdg-dock or xdg-dash is also possible. That way we may finally be free from gnome-ecosystem and the self-righteousness
Well you don’t really need gtk-nocsd, gtk-mushrooms will do the trick.
I don’t use any of this alternatives as i considered this type of solutions inferior to the alternative of not use the GNOME applications at all. I’m against make a fork of Gtk to do a thing like that. So, i always prefer a solution with base on hack the specific applications from outside and at my demand just in time in a module, than patch the GTK in all my sessions at once. Also will be always preferable to me install Cinnamon, or Mate, for example, and then do not use any of the default GNOME apps at all.
There are not any general module or a general toolkit change that can really solved all problems that the specific GNOME developers are creating in his specific applications. Just to add an example: We can not invented a general menubar, that will work for all GNOME applications. We need to create instead one specific menubar for the specific application we want to patch in that moment.
Since gtk3 api is stable it will work all the time.
That is not necessary true, because Gtk is not changing, but the specific applications of GNOME are changing in the time and they probably are waiting for something that you removed form Gtk in the last GNOME release.
I am lazy. I don’t make those apps for myself. Instead I let them do the coding and then bend it to my will.
It’s the opposite. To do your will, you need to work a lot, returning to the life the things they removed one by one, and also application by application, otherwise what you did is make an ugly patch.
There was a proposal before or rather a dream. To bring Mate, Budgie, Cinnamon, Xfce teams together.
You said it. This was a dream… It will never happen as they have also some short differences that can become big when they need to take design decisions.
Perhaps you could make the headerbars lose the window controls and change color to the color of a regular panel when maximized, to make them fit in with the space-effiecient look of Unity?
I am not asking to fork entire gtk (which is not possible anyway) just the small extra patches. This is no different than what debian/ubuntu does. They already add patches. I am only adding few more.
Of course it would be better if we have something like no-csd as module (like unity-gtk-module).
True. But gtk-3 headerbar and appmenu/gmenu api doesn’t chnage. Since they removed appmenu, it is even easier to patch it back. It is not possible for any other feature they removed, but works well just for csd and menubar.
If I do all these by myself then yes it will become ugly in time. But that is not the case here.
Ubuntu/Debian use lots of patches and with git/gbp/quilt it works flawlessly. And I am not always exactly favor of using the latest version. Sometime I use older version with cherry pick fixes. For example I still nautilus 3.26 with desktop which works better than any file-manger in flashback session.
May be not for cinnamon, xfce…
It doesn’t need to happen in ui level, even if it happens in non ui level, libraries and all, common settings-daemon, common libdesktop-library, common schemas etc, it will still be huge. (Those libraries are 90% same.)
Ayatana indicators was one such example. Now everybody can enjoy Ubuntu’s indicators. If a foundation can be formed (with monetary backup; yup that’s the main thing) it is not that far fetched. Ubport did it even without initial backers.
I will try to float that idea in next debconf (provided it happens this year) and see what happens.
I am not asking to fork entire gtk
Where is the middle point between speak of a fork or speak of a little patch? I already saw the repository, the middle point was exceeded to me and also the result doesn’t satisfy me.
True. But gtk-3 headerbar and appmenu/gmenu api doesn’t chnage. Since they removed appmenu, it is even easier to patch it back. It is not possible for any other feature they removed, but works well just for csd and menubar.
I don’t understand what is your intentions. In Gtk they don’t touch anything about the appmenu or the menubar or the option to be exported as a global menu. They just removed the global appmenu support from the shell and the appmenu support from his specific applications, never from Gtk. Gtk support fully the appmenu and the menubar and the global menu of both features. The problem is not Gtk in that case. The problem are the specific GNOME developers. You can not fix specific applications patching Gtk.
May be not for cinnamon, xfce…
Yes, Clement have not any intention to collaborate with anything externally to LinuxMint and xfce announced they will embrace CSD. Also not matter in what level occurs. Design are not only the ui things.
Ayatana indicators was one such example. Now everybody can enjoy Ubuntu’s indicators.
That is not true. Not one love the Appindicators and also the Appindicators are bad fork of the KDE implementations of StatusNotifier. For example Mint fork the libappindicator only to redirect it to his own xapp implementation. LinuxMint is another little GNOME that do not collaborate with the Linux community in general, specially Clement, see this as an example.