Pamac's new look

Maybe I didn’t yell enough, I DO like the new UI :stuck_out_tongue:

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…” :wink: . 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.

Thanks for the link, I’ll check it out.

1 Like

Hello all,

just a more technical question for Pamac:

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’ve read these ones:

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”. :grin:

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.

Probably will be more efficient to create an issue on Manjaro’s GitLab for this. Pamac version will be handy as well.

1 Like
1 Like

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.

4 Likes

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.

6 Likes

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.
Screenshot_20210621_161201

1 Like

Pamac GTK uses CSD, KDE Plasma doesn’t … The Qt version of Pamac will integrate better with KDE.

1 Like

How would I know if my pamac-gui is Qt or GTK?

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.

Pamac-QT was a work-in-progress, currently on hold.

If it’s ready to deploy one day, there had been announcements before that.

Color deficiency is irrelevant here. A color deficient can differentiate colors. For green-red deficiency, some green on some blue, etc. may be problem but traditional color codes are ok.

That is just one deficiency and is called deuteranopia. There are types of deficiency for each base colors (red, yellow and blue combination) with different shades variations: protanopia, protanomaly, deuteranopia, deuteranomaly, tritanopia, tritanomaly.

What is relevant? Since color codes got back into Pamac, why getting argumentative again?

I’'m not saying this or that way must be chosen. However color deficiency did not seem to me as a relevant argument for saying not use colors in pamac.

Edit: sorry it is my bad, it was an old discussion, I misunderstood the issue I think :slight_smile:

No worries :slight_smile: sometimes even tho we try to clarify things, is possible that we get different message from the “entire picture”. At that time, the focus was on functionality and because of the switch to gtk4 not all features got into that release and people got upset. Is understandable.
What do you think of the latest release, is more practical, does fulfill the goal to help user identify better the packages, does it look better, does integrate better with the rest of the UI ?
Thanks.

Yes I think it is pamac-gtk too so I am very confused when you say pamac-qt

You could say this is a continuation of this issue, yet now on the new Pamac 10.1.3: Pamac v10 has space wastes and bad alignments - #52 by Chhkuot



Caption: “Description text cuts off, not enough room, yet plenty of unused space on both sides”



Caption: “Even more unused space on both sides, yet hiding the panel menu makes no difference, as the same amount of descriptive text is shown.”


Evidently, what is the purpose of “collapsing” the left panel menu, when it does nothing to benefit the extra space by doing so? Whether or not you hide the left panel, the same amount of text is still cut off. There’s a lot of extra space wasted on both sides that could be used for descriptions, actions, previews, package/file info, etc, that could be displayed when clicking on a package in the list.

Don’t just look at the dead space on the “right”. Add up the dead space on both the “left” and “right” and you’ll see you can fit a lot of useful information to the right side, while the list of packages can be aligned to the left side.

1 Like