It is, and the build process is pretty quick. I thought it will take ages on VM. Thank you, maybe now I’ll be more helpful.
@bogdancovaciu Result with 1260, maybe a bit to wide, but I can’t actually say because I changed display settings to 1920xsomething in VM (my potato have only 1366x768).
It is acceptable, or try with something lower?
I’m a bit puzzled now, it is worth to play with it, or wait for GTK4 and close issue?
Indeed. I never use Pamac UI in maximized window on my desktop, for the same reason why i never walk with my hands spread out sideways 
What’s the point of having maximize button, then? Remove maximize button from CSD and set fixed maximum window size. Problem solved.
Sorry, but it’s not funny at all. You can equally say that everybody who maximize Pamac are dumb. Because you don’t like it doesn’t mean it’s universal truth or way to use software, in this case, Pamac.
Its not that often I agree with @bogdancovaciu but I have to say I’ve never used pamac gui in fullscreen either. I get the point that if there’s a maximise button it should work correctly but on every linux distro I’ve ever used I’ve never had the software manager gui in fullscreen
The Linux UI tool-kits have several distinctions and inconsistencies. This is a known upstream toolkit issue: QT GTK UIs should look the same, to combat this, the Team has made the effort to make things look and feel the same as much as they can be by using theming and other hacks.
Here is what can be done to mitigate a bad experience, don’t modify how your DE looks like, use the defaults.
Pamac has been in development for more than 10 years now, so its going to take a long time for pamac-qt to even come close to it. So if you have any C and QT skills maybe send the developer a PM and ask how you can help.
If you have a work-around then post that.
There is a reason why a UI is usually centered, to accommodate different screen sizes, to improve readability and legibility, this concept of UX design can be researched online, there is always space to improve as with anything but making a design wider is not one from a usability perspective.
You got a better Pamac UI concept and understand are familiar with Gnome Human Interface Guidelines, you can also open a issue and put your concepts there.
I would say it would look stupid or unnatural, commonly speaking, and it doesn’t require any research, we are already used to it. You look at something and see its wrong. When it goes to different screen size, It’s actually not a biggie in GTK, just add two vertical containers and put something (for example list) in one of them, and it will stick to it no mater of window size. I’m not sure if it fit for everything you have on mind.
I’ve red HIG and there is no single word about making list width wider (in this context - embedded list), something bad. In Lists you can find two examples and one of them is list in wide container and second is embedded in. Which means, use which one you like or works for your program better.
If we look at Pamac in Phosh, the embedded list can be considered as wasting space, and the wide container would save space for few more characters in list items. One point for wide container camp.
Other side is it actually will not save any lives and embedded list look better visually with rest of window content.
Present situation is we have only GTK version for both GTK and Qt, even if someone will pick the glove and start learning C it will take time to met with what is already written, plus learn more to improve it. Met in middle ground seems to be a good option if we take in account what you’ve said about “effort to make things look and feel the same as much as they can be by using theming and other hacks”
Middle ground option would be to increase “maximum_size” value or set fixed padding (not sure if it’s proper term), so list don’t take more space than being intended (if it’s possible). I’ve tested maximum_size with 1260 on 1920xsomething in VM, and it looks similar to what is displayed on 1360x768 where spaces between the borders are not that large (maximized window). Which is what users complain.
In Visual layout we can read:
As part of this, it is important to recognise that visual design has a strong impact on how much work is involved in using an application — poor layout results in users having to put in additional effort, while good layout requires less effort.
Value for embedded list is set to 900 which can be a bit annoying on display 1920 and higher. Cursor needs to travel longer distance from corners, or dash/panel on left or right. Is this can be considered as additional effort?
HIG talks about being in front to user, and here we can read “Pamac looks good unmaximized, why would you want to maximize it?”. Kinda in counter.
There is also an argument that most of the packages don’t have enough description to fill the list. It’s visible on a 900 pixel wide list as well. Sure, when the list is wider, the illusion that there is something to read vanish quicker, but there is no “empty space” feeling.
For the record:
I understand that Gnome design is a two edge sword. It looks nice, but it’s easy to create UI which gives the impression that there is nothing to configure and emptiness feeling.
A bit of salt:
.- we are doing these for better UX
.- I would like to have wider list for better experience 
.- nay, nay my friend it’s bad UX
[Bug] In Build Files tab of AUR, the full PKGBUILD text can’t be seen. Clicking on PKGBUILD text, the frame is maximized and can’t be minimized. If again clicked on the first line, the tab title also gone…
2736x1824 screen with 200%
Maximized:
Does someone here have a display bigger than 1920x1080? I’m curious how it looks on wide screen.
@mr_glitch Are you satisfied with this?
Sorry I’m too late to answer 
I was using a color scheme of my taste and pamac was not looking good enough under it. However, I had really liked that “dark lagoon” colors and didn’t want to shift. Now I have just shifted to breath2 2021 colors, and pamac is looking good and practical here. Thank you for your work.
I too am not a fan of the newer pamac, it sticks out like a sore thumb on the KDE edition and doesnt scale well with my 1440P desktop.
I replaced it with octopi which thankfully is still around.
I really wish the KDE version still shipped with octopi out of the box, pamac is so ugly now when dealing with Manjaros KDE flavor.
I’m not sure it is relevant to continue to reply to this thread as it was made when there was a major change in Pamac version earlier this year. Also it could be relevant if at least you talked about something instead of just ranting without any explanation besides “Pamac is ugly”.
At least try (and probably also READ the thread as KDE was brought to the table already multiple times to the thread with Manjaro’s team responses).
It is relevant when the application looks so out of place.
One must know not all of us run manjaro on a phone, there is still such a thing as a desktop and UI elements are always relevant when they effect how an app/program not only looks but also feels from a users perspective.
Pamac QT should have never stopped development otherwise we would not have this issue, instead we KDE users are stuck with this ugly thing unless we use octopi or commandline.
If octopi becomes depreciated then one must consider resuming pamac QT and personally I dont know how to code and nor do i want to know how to code as I am just an end user.
I mean… you can help the development of it if you’d like, or get someone to help do it. Development of pamac-qt won’t continue until someone volunteer to pick it back up.
Reminder that the development of Manjaro are all volunteer based. Porting pamac to pamac-qt isn’t an easy task, not to mention keeping it fully maintained.
Looks fine for me so… -shrugs-
What I mean is you still lack in this message, like the previous one, any relevant information to give to Pamac developer regarding your concerns about Pamac.
You just complain, that’s OK to me if it stays respectful, but without pointing out exactly what is not good to you what do you expect happens?
For now the only purpose of your message is to complain that you don’t like Pamac, and that Pamac-QT dev should rethink how he should have spent and should spend his free time (which is dedicating himself to the project instead of what has higher priority currently for him).
Also as a KDE user you’re not stuck to use Pamac, you’re free to use what you prefer. If you don’t like it, then use another package manager there are others (my personal preference is Pacman, I use Pamac mostly for AUR).
//EDIT: You don’t need to code to make a relevant complaint post.
Trust me i would code if i could but sadly that sort of thing is beyond my skill set, I am good at hardware and knowing more than one operating system, but coding has never been my strong suit.
Just a bravo for @guinux.
I really love how the interface splits now in two columns.
The packages list is compact now, and no more the looong list to scroll, it’s way more modern and usable.
I don’t know if it’s limited at two or adaptative, maybe those with big screens will have more columns.
No more lost space anyway.
It actually scales depending on your window size
Also I didn’t like the right side column with package info, if you click the button to hide it on top right, the previous behavior is back you have a dedicated info page instead of the slim right side info column when you click a package.
Ahh yes, I’ve missed that.
It’s an interesting feature, as you can get the package info directly when scrolling down the list, without entering, going back…
And it’s good to have the old behaviour available too.
A good update 
Edit: indeed, with the upper left toggle, I have three columns displayed instead of two.
I did’nt really notice the change, meaning that it’s just…what it is, really…just optical.
I rarely use pamac via the GUI if only to go look for something, or to quickly see what is in the update. I always use the CLI for updates and installs/maintenances…
But…that’s me… 
If you’re on Stable branch, you have still the same version you were used to.
The 10.2 version is on Unstable and Testing.
