Wed, Jul 17
More technical info:
Outputs may be in a cloned view because they share the same CRTC. Such outputs can only be driven in a cloned mode, here meaning same resolution and frame rate.
GNOME does something pretty nice: they draw a blank/white background with a monochrome desaturated version of the app's icon in the middle. It looks really classy IMO. We could do the same, maybe also with a monochrome desaturated indeterminate progress bar below the icon.
One probably needs to consider that progress indicators may be determinate or indeterminate.
Tue, Jul 16
Mon, Jul 15
I would think we only need two different sidebar appearances for this: The one used in System Settings when there are many entries and D20908: RFC: Redesign QML applet configuration windows when there are few.
There's something I've noticed that's inconsistent between applications - how loading is represented. There's not really any consistency at all, excluding Kirigami applications.
I sure hope so! Yeah, we're working on that particular issue too. @mthw may be interested in this!
@ngraham I have been tracking this for a while but finally created an account to contribute some comments. As a newcomer to KDE from gnome-based desktops I am reliant on apps like firefox and thunderbird. The GTK Breeze theme has some minor usability issues with tabs in these apps. See these screenshots:
Thanks for taking care of this!
Both to the submitter of the patch and all reviewers.
Can I change the selection background color and use the selection color for the background of highlights? Then the regular highlight color could be used mainly for line highlights and outlines.
Thanks for the color overview. I'll avoid changing the highlighted text color in the colorscheme.
Personal opinion follows.
Few words about colors (sorry if you know all about it already)
Some of the Buttons in Spectacle are Toolbuttons instead of Pushbuttons. Namely "Save" and "Copy to Clipboard"
@ngraham Unfortunately there is no way with UI files to dynamically modify the layout depending on the size of the container, so munging the layout in C++ is the best way I know so far :)
Sun, Jul 14
- For the record: toolbar buttons (or rather QToolButtons) can have focus too, when they are used outside of toolbars (and there are examples of such everywhere, for instance when you have an "open" button next to a text entry for selecting a file.
your enumeration did not mention
- checkboxes and radiobuttons who also have hove/focus + the various selected states.
- tabbar entries (hover, focus, selected)
Hmm, munging the layout that's provided by the UI file in QWidgets code doesn't sit that well with me (especially grid layout code, which is already quite difficult to read). Is there no other way?
:=) I see, I should have properly read the description.
Ok. Note that the layout is still the one you currently use when toolview is at the bottom (when toolview.width >= toolview.height)
Ok, I see, for the search stuff at the left/right, it makes sense, thought I normaly keep it at the bottom.
I agree about reverting the search.ui changes. I made these changes when trying the 2nd layout but they do not make any sense now. Fixed.
The double space was unintentional and it is fixed.
I need some help coming up with a consistent way of showing a distinct difference between mouse hover, keyboard focus and the sunken state. Here's what I know about how different widget types use these.
Sat, Jul 13
I am a bit concerned about the height increase. As most people have 16:9/10 screens, screen height is always sparse.