My analogy was addressed to gtk3-nocsd and gtk3-classic.
Technically you’re not forced to use it, you can always delete Pamac, nobody catches your hand and say “nay, nay”. Besides, it’s not guinux fault that there are no metal bands in the neighborhood, plus it’s for greater good. I’ll be happy to buy a smartphone without android on a board.
Another thing is that Pamac is not even finished yet. I believe that when basic functionality will be in place for desktop and mobile, there will be time to thinker about how to make desktop experience better.
What if guinux actually likes the gnome look, or it’s in his opinion the best way to achieve the goal?
guinux is only one guy, not a team of programmers, M-Team and testers help as they can, but he’s the only one who type code. Will be cool to have proper UI, UX designers but instead of that everybody engaged in Pamac are learning new things on the fly and under pressure.
Talking about how everything related with gnome and CSD sucks doesn’t make the situation better, and doesn’t make morale on proper level to work. If I was on guinux place, after update to 10.1.x, KDE, gtk3-nocsd and gtk3-classic users will be welcomed with full-screen dialog box with middle finger in center and sentence: “For everyone who hate CSD :)” or something like that.
And mobile user don’t deserve for nothing? I know that if something is for everything it’s actually for nothing. But in current situation, both sides needs to be addressed. Like I mentioned before, we can learn how to program in Vala fast or rather very fast, or figure out how to clone guinux.
If you navigate in the center of the screen it’s pretty comfortable, but with one thing I can agree. GTK apps on wide or ultra-wide screens in full screen mode can look like a missed idea. Few options in center and blank background all around. Personally my biggest concern are title bars, sometimes they are look like they can be arranged better. In other hand many of GTK programs are rather simple, so even if we want to fill CSD better there are not enough options to populate it. Kinda paradox.
If we are talking about Pamac… we have Pamac developers but without “s” at the end.
If we are talking about GTK in general, the idea is a universal layout, at least for simpler apps or not that complex like software for graphics etc. I’m not sure, but I have never seen something like hidden elements in GTK. When the window is small, part of options are moved to a dropdown menu or something like that. Wider window more options in CSD. That would be cool. Maybe my brain fools me, it is a bit late in my area.
I completely agree with michaldybczak : new Pamac is a disaster, big mistakes on the design point of view. I would be sad to see a fork here (many have left XFCE when 4.16 was announced with the horrible CSD mess)…please consider staying with KDE look & feel and backtrack to previous UI design (can be improved without going the ugly and inconsistent GNOME way). This is just my opinion.
True. However, what do you propose? We dislike CSDs (well, they look good in certain situations but in overall their functionality is limited) and what? We can’t talk about it? If we stay silent as we did for a long time, too many assume that CSDs are the future and happily promote them. This feels like we didn’t exist and we have nothing to say. And then when we speak up, it’s not welcomed. So what is the right approach here?
I believe we should voice our opinion, because too many voice opposite ones, so it feels like you are trampled by not doing anything. So here we are discussing and showing that there is a strong group of users who have VALID REASONS to dislike the UI choices of pamac or UI trends in general.
Thanks for the info. That is really a hard situation to be in. This is understandable that with limited time, there is no time to reflect on the many aspects of UI, while the horde of users voices their opinions, not always positive ones. So probably till there will be no stronger development group, we can’t really expect some things to change, which is regretful, but it is how it is.
Agreed, but too many development trends feel like throwing baby with the water. Let’s make app mobile friendly - and then the desktop app becomes mobile app, barely usable on desktop. Heh?
For example, hamburger menu is HORRIBLE from usability point of view on desktop, but is needed and a genius solution on mobile or with limited space. So it’s great if app is adaptive and with limited space converts menus or toolbar to hamburger menu. What is wrong is that normal, desktop UI elements get throw up and REPLACED with mobile one (hamburger menu) and then it’s called progress and expect us to be happy with it. Again, adaptive UI that looks or works good both on desktop and mobile is the goal, not the replacement of desktop UI for mobile UI.
However, given the limited human resources, I know understand that proper solution may be harder to implement and that is why we get this bad, one-sided design. Having pamac as GTK app feels even more limiting with time. KDE with Kirigami gives more flexible choices for proper adaptive behavior. Or maybe this is also possible on GTK but we simply don’t know it? If so, it probably needs more coding, which means time. In Kirigami this behavior is built in so to speak. Since pamac was always GTK, I can’t expect it to be rewritted for kirigami. Pamac-Qt was started but paused because lack of time and it also doesn’t use Kirigami if I’m not mistaken, so it’s also not properly adaptive.
See how Discover behaves when you change the size of a window. The same with Elisa (with some limited scope thou). Those apps are desktop and mobile ready, and they work properly on both platforms. No bad compromises and throwing baby with the water. I wished the same for pamac, GTK or not, doesn’t really mater. It should be adaptive and designed for both desktop and mobile, alas, this probably require more time on GTK, time which guinux doesn’t have.
You dislike CSD, so you want to force everybody who likes it to don’t create software with it?
The issue is not because you talk about it. But how this “debates” looks like. I’m reading this tread from the beginning and when I think about CSD/new Pamac look opponents my first thought is “new look/CSD is utter s##t, kill it with fire”. It reminds me how Philip was treated some time ago when he was saying something on forum. You’re doing something for people, and in return you’re thrown invectives. That’s the spirit.
I use Catfish and Lifrea and in both you can switch between CSD and traditional toolbar. In Catfish you can switch in preferences and in Lifrea there is Header Bar plugin which changes header bar into Gnome style. So it’s possible to make everybody happy.
Same thing rather can be done with Pamac, but it will require help not just talking how bad is CSD.
I don’t see a reason why unhappy users just can’t do something to help with improvement, development instead of preaching opinions.
In other hand, there are others distributions which use Pamac, and in theory work on Pamac should go fast and smooth but in reality everybody run in exercise wheel like hamsters, because maintenance takes every spare minute.
Sure they can, but the limits they have are serious. Nate Graham already covered it in full in his articles, so it’s pointless to repeat it all.
CSDs are currently native to Gnome apps where this look is dominating. Of course, every developer can implement CSDs if they like. The problem here is quite different. Pamac is a utility used in many distros and even more environments. If it was only a Gnome app for Gnome environment only, no problem then. However, Gnome look and CSDs forced on all environments where it looks out of place, foreign, confusing is just an odd decision. Again, if the goal was to make the app mobile ready, Gnome-like design is not the only choice here. However, I get it that since it was CSD and gtk from the beginning, with limited resources this was the easiest route.
First and foremost, I never throw any invectives on anyone. It was always clearly stated that this is my opinion and my feelings. I was being honest and blunt and for that, I won’t apologize.
Second, this was not only pure subjective and empty discussion. I stated my opinion and then added arguments why.
This is probably the culture difference. This way of approach is perfectly fine and common in my culture. If you disagree with someone, it’s fine to say “you’re full of shit and here is why…” . In fact, the more you are friends or close with someone, or if you respect someone, the more likely you get this brutal honesty. It’s a way of showing that you care. Believe me, I’m very polite and respectful here IMO. Well, I may have offended someone inadvertently with such blunt statements, but I hope you see the difference between a troll who just starts a flame war and someone who is trying to discuss it for real.
I agree, but the problem is, most of us, users don’t have time to be involved with a project. Giving opinion is often the only and simplest way to show feedback. In ideal word, we should join the substantive discussion on given topic, provide with mockups, propositions, etc. This takes time, knowledge and skills. Only a fraction of users will do that. In fact, I often do try to be involved, although in a limited manner, but I find even hard time to check out this forum. I’m too busy lately.
Packages that are listed as IgnorePkg in /etc/pacman.conf still appear in Pamac’s search results.
So far, so…I don’t know because:
If you inadvertently click on such a package, trying to install it, you get a message that the package could not be found in the repository.
This is misleading. There should be a message as clear as with pacman:
:: {packagename} is in IgnorePkg/IgnoreGroup. Install anyway? [Y/n]
I think we need proof of concept in that area, because of full potential of CSD wasn’t shown yet. Too many programs are made with the same template, so it can give false impression. Given examples (On Headerbars) was for different programs, so what is an issue in one, don’t exist in second, and it can lead to conclusion that every program with implemented CSD have or repeat same issues.
Those serious limitations exist only in theoretical sphere. Everything depends on how CSD will be programmed. Don’t know did you used Foliate before, this one have cool CSD behavior implemented. When you have opened e-book, CSD is visible only when you hover it.
KeePassXC is also widely used, should I go then and try to convince developers to change it to look to be more gnomish because it doesn’t fit to my desktop? Plus default theme is ridiculously different that I adore it.
However, Gnome look and CSDs forced on all environments where it looks out of place, foreign, confusing is just an odd decision.
Honestly, I don’t understand this “obsession”, whenever it’s from GTK Team or QT Team side.
I wasn’t talking about you specifically, but impression. You can be politeness and kindness man in the world, but what you say will be mixed and/or covered when “impolite” comments came into action.
This is probably the culture difference.
I don’t think so, more or less we are behaving in the same way, especially in internet space.
What is convenient in face to face between pack of friends it’s not necessary good for text communication between people you don’t know or barely know, plus how words can be taken depends on mood. If someone had long tough day will rather not be in mood for jokes, for example. Sometimes it’s better to type few more words without using strong language for the sake of everybody.
Btw, if I’m not wrong we are leaving in the same swamp. Made from “dykta”.
I’ll be a bit abrasive if you don’t mind, and it will be in general, not pointed in you directly.
If you have time to talk about how much you don’t “like” something, take this time to actually learn something which will be helpful.
The biggest problem with CSDs and not a theoretical one is that they have to be designed by every dev each time. So instead of having consistent, customizable, coherent with environment look, behavior and settings, you get some limited idea of the dev what is the best for the app, regardless of the environment. Developers are rarely good UI designers… which is sad.
So it doesn’t matter if a cool abilities can be programmed in into CSD, the problem is, they have to be programmed in each time for every app separately!!! That is the biggest flaw of CSDs and no matter what you do, you can’t change it. This is basic flaw.
Do titlebars have limitations? Sure, they have, but they are designed by bigger groups of developers for windows managers, so within a desktop environment, they are consistent. So titlebars in KDE are more capable than titlebars in XFCE, but not that titlebar is limiting, but because XFCE devs don’t add extra features to it, while KDE devs are more open. So we have differences between WMs and environments. In CSDs, the differences will be on app level.
In Mac OS, this is a big and prominent target. MacOS devs have some UI guidance for apps. The same is for Android. However, in Windows there are no such coherent points of how to design UIs.
For many developers, Linux is a small niche and they don’t have resources to create and maintain Linux version. However, if they do that, they won’t create extra features for it. They will do the minimum. So the problem of CSDs (and of Gnome devs as well), that they naively expect everybody to follow their design. This won’t ever happen, because we have no strength to enforce it like Apple or Gnome can on their systems.
So when CSD trend will continue and some devs will ride on it, we end up with incoherent, problematic UIs. So that what was the strength of LInux, will be no more. This is dangerous and this is not in real of theory. We see that already everywhere. Even in Gnome apps you get this inconsistency with CSDs and some programs you will use in Gnome, will never look like native to Gnome and vice versa.
The mixed approach and have certain area in titlebar that cab be programmable by devs (but it’s an option, not a must) is more interesting and should be discussed, but in the end titlebars should be ruled by WM, not the app developer. CSDs look cool on Mac OS, but there is consistency there and enforcement + global menus, so even more complex, productive programs can use CDS as some basic toolbars, while still giving us the full access to details on the upper panel - if needed. This was never the case in Gnome. Flawed CSDs are their child and they don’t do well, so if current CSD apps are problematic in overall, how can you believe that it will better, especially if you can’t enforce any standards? Additionally, CSDs add work to developers and deepen the fragmentation. Not a good direction IMO. No matter how cool CSDs may look like, the flaws are too serious.
As far as I can say: Pamac will follow the new HIG for GTK4 which will be used in v11.0. v10.1 is a pre-step until Phosh is able to display GTK4 in the wanted way. This will bring the usage of libhandy and libadwaita to the table, so we can design Pamac in a more adaptive way. Also we will split-out libpamac so other UIs can be created, such as an upcoming Qt5 UI by @LordTermor. More info about the plans of the new HIG can be found here.
Also we will rollout Pamac 10.1.x to our Testing branch with the upcoming Gnome 40 release we will do with Manjaro 21.1 Pahvo.
How about reducing the title bar to the system-default size? You can see that it is about 2 times larger. I have been waiting for this change for a long time.
AFAIK Pamac is GTK only. Or at least, at this point in time.
Why do I say that? Because I use KDE, but Pamac uses the GTK theme, not the Qt theme.
Also, according to Pamac, the Qt version a prereleease version as well as is not installed at the moment, as well as that pamac-gtk is installed at the moment.
$ pamac search pamac
[...]
pamac-qt 0.3.2-2 extra
A Qt5 frontend for libalpm - prerelease version
[...]
pamac-gtk [Installed] 10.0.6-2 extra
A Package Manager based on libalpm with AUR and Appstream support
[...]
So you can check that way.
(It being pre-release makes me think that it’s not officially out and released yet.)
Go in About menu, it is the same for basically all programs, you’ll have infos on the dev, the application website, things like that.
Also Pamac-QT is a completely different application, it is not Pamac it is the QT counterpart made by another dev (and it doesn’t have active development currently). Just check if you have it installed.
voices their opinions, not always positive ones. So probably till there will be no stronger development group, we can’t really expect some things to change, which is regretful, but it is how it is.
