- User Since
- Sep 16 2015, 5:33 PM (205 w, 23 h)
Jun 22 2019
The important thing is preserving the current ease in distinguishing active window from inactives (for all windows, not only Qt/KDE ones)
OK, but I don't think that changing Breeze theme for QtWidgets is a good idea to solve an issue with the title bar, only KDE/Qt applications using QtWidgets would benefit of this. And since then Breeze theme for QtWidgets and Breeze window decoration will only make sense if used together.
What do you think about inactive window title bar matching Plasma panels theme (90% opaque white by default with blur)?
Jun 19 2019
The problem with that approach is that with a lot of tabs, the amount of remaining drag area is tiny and borderline useless, just like Firefox with CSD currently has
Jun 18 2019
Hey @ngraham, you said tabs in the title bar prejudice usability in dragging the window like in Firefox and I think you are right, so I did the following mockup with a responsive layout for the title bar, can you let me know if it would be good for you? Thanks!
Jun 13 2019
Another option would be displaying a label "Menu" instead of the hamburger menu when the window is narrow and File Edit View... labels when there is enough space and dragging area
Jun 12 2019
Just a mockup but is this middle ground solution good enough?
Maybe this is just a perception from the point of view of the icons. When looking at the two images, I don't see a perceptible change with the titlebar height, but I notice it with the icons. If the icons were consistently the same size and the titlebar a different height, would that be good?
BTW. There were window tabs (not app controlled though) in KDE4, but nobody ported them.
Jun 11 2019
@ngraham After thinking better, I think you're right but I also think that such a large title bar contributes a lot to making users hate server-side decorations. I can't think of any solution apart from making it more useful with tabs like in the Plasma Sets mockup.
Jun 10 2019
May I suggest to change title bar size from medium to little? I'm on a 169 DPI screen (very high for desktop without UI scaling) and it's still very usable
Jun 9 2019
At 16x16 the symbol could be removed and just show the document frame (I thought about this when I insisted to associate a color with mostly each mimetype).
Anyway consider that any change to mimetype icons imply a lot of work.
In my opinion we shouldn't touch Breeze theme for Qt apps or massively redesign KDE apps.
Please consider that KDE apps with Breeze theme could run in a DE without KWin and that not all the apps use Qt, KDE widgets and Breeze theme: KWin should make obvious for every app if its window is active or not. We should change Breeze theme for window decorations only.
Mar 7 2019
Jan 21 2019
Just a thought: since "alternatives" pattern seems to work, what if Bob find as alternative to application launcher (Kick off) a full screen launcher like the GNOME one, that:
Jan 17 2019
Jan 14 2019
@scherek except for the icon-only tabs (that I don't think would work), do you mean something like this?
@oussemabouaneni it's writter in the very first image: the browser (and other apps with tabs) should hide their tab bar. Managing shortcuts in a meaningful way shouldn't be a problem. The challenge would be integrating existing browsers like Firefox and not only the KDE one, Falkon.
I'm mostly with Andy on this.
Jan 6 2019
I'm the author of this one:
Dec 19 2018
Dec 3 2018
Nov 15 2018
Sep 21 2018
Very cool icons! But in the panic one the padlock is too small :-/ what a about a checkmark (✅) on the wall instead?
Sep 14 2018
Sep 13 2018
Do we want time, stopwatch, alarms and timers to be in the same app? We already have KTimer (h[[ https://phabricator.kde.org/M130 | ere a mockup) ]]. Should we develop the remain apps standalone like KTimer or merge it in this "Clock" app?
Wouldn't tabs and navigation by horizontal swipes better to change location? Same for parameters, maybe with arrows to indicate that you can swipe right/left to view another parameter?
Jul 15 2018
Jun 26 2018
Jun 13 2018
Jun 5 2018
It seems to me that this area intersects with the PIM one. Are we sure we want applications organized this way? It may sound more difficult to implement but I think the most logical design would be the following:
Jun 2 2018
Marco said it's technically impossible.
May 29 2018
May 28 2018
Thank for this, can you please share screenshots with dark themes, at least Breeze Dark?
May 26 2018
Gray seems OK to me. And I confirm the bug with Saturday column.
May 24 2018
Seems that this was posted by the private account of Allessandro Longo: https://peertube.nsa.ovh/accounts/1292/videos
May 23 2018
having a vertical alignment between the icon and the stars breaks the fact that we only had 1 thing at the left on the vertical views. This adds clutter.
The reason is that the current layout makes cards narrow and long, so I tried a modular layout that can make cards longer or shorter according to page width. It would be better to have this in Kirigami so Discover just have to fill the cards.
May 22 2018
Very nice looking 👍🏻
Please provide screenshots when tagging VDG
^ I'm for this one without the quaver
May 21 2018
What about a blue dot on the launcher icon and a new tab in the launcher named "newly installed"? The dot will disappear when the user will open the newly installed tab.
+1 for no-side borders by default. Also, titlebar and bottom border can have custom colors using KWin rules (for example if a distro ships Telegram it can ship in the same package a KWin rule to match colors), so consistency is not a issue there. The real issue is that apps draw widget near the side borders, so we just need to disable them by default. I use this settings since KDE4 and I have no issues with it.
May 20 2018
I did nothing, maybe you subscribed when I was editing the description and things messed up
Yes, the app developer could elide text instead of increasing cards height: but I think it would be nice to have automatic different height managed by Kirigami and the app developer that want cards with fixed height takes care of card content in another way, i.e. eliding text.
Do you mean a icon with the following points?
May 19 2018
Possible interactions on hover (I used the third one and the fourth one when dragging):
I tried with arrows too, but I think the fifth one looks better... my second choice is the third one.
May 18 2018
Cursors and hover: