Review Request 122985: [kcmkwin/deco] Hide button layout on small screen estate

[Thomas Lübking]

> On März 17, 2015, 8:53 vorm., Martin Klapetek wrote:
> > kcmkwin/kwindecoration/qml/main.qml, line 52
> > <https://git.reviewboard.kde.org/r/122985/diff/1/?file=355356#file355356line52>
> >
> >     This should end with "..." to hint that new dialog will show (it will right?) and the text should be capitalized as per the HIG
> >     https://techbase.kde.org/Projects/Usability/HIG/Capitalization
> 
> Martin Gräßlin wrote:
>     My understanding was that "..." is needed when a dialog is opened - adding Thomas as expert
> 
> Martin Klapetek wrote:
>     Ah sorry, I posted that comment only after looking at the screenshots and thought this /does/ open a new dialog. In that case, I think some drop-down arrow would be more helpful rather than "..."
> 
> Martin Gräßlin wrote:
>     yes, I also thought about an arrow, but was unsure on how to do it.
> 
> Thomas Lübking wrote:
>     There's no way back, is there?
>     -> Tabs?
>     
>     "Style" / "Layout"
> 
> Martin Gräßlin wrote:
>     would prefer to not have tabs as it makes everything (option syncing, updating previews) more complicated and the second tab would have lots of whitespace ;-)
> 
> Thomas Pfeiffer wrote:
>     Even though you might not like it, I have to side with my namesake here: Now that I - admittedly - see the button config UI in the context of the list, it really feels like two things that don't belong together have been put in the same UI. We have a list of windecos to select from and then below it, barely separated from it - is a UI that does a completely different thing. This may already confuse users into mistaking the button config UI for just another windeco preview if they don't look closely enough, and the new situation with a button expanding into the full UI when the window is resized might just add to the confusion ("jumpy" UIs should be avoided if possible, as they are less predictable).
>     I'm not exactly a huge tab fan in general, but in this case it makes perfect sense since we have two related, yet distinct sets of controls.
>     Unless the added complexity would very likely cause tons of nasty bugs, a UI with a bit of whitespace would be a perfectly okay trade-off for reduced confusion and no need to come up with workarounds for a space limitation problem.
> 
> Martin Gräßlin wrote:
>     I just tried with tabs and that is challenging. We have two options:
>     * move the tabs outside with decoration list on one and buttons on other
>     * have the quick part being the tab view
>     
>     The first one causes the problem that we have two QtQuick view with all the nastyness this brings including possible breakage. I expect this to be so bad that I did not even try.
>     
>     The second makes the UI strange by still showing the search field when being on the buttons and even more: the layouts break when switching tabs. See http://paste.opensuse.org/77641900
>     
>     I can give a try to the option 1 but I doubt it will work.
> 
> Martin Gräßlin wrote:
>     > I can give a try to the option 1 but I doubt it will work.
>     
>     No, that's nothing I want to spend time on, it's complex and most likely wouldn't work anyway.
>     
>     I'm open for other suggestions.
> 
> Thomas Lübking wrote:
>     Have a QWidget QTabBar (but no QStackedWidget) and bind the tab signals to hiding QML elements?
>     That's oc. not very elegant :-(
> 
> Martin Gräßlin wrote:
>     that could work. Not elegant, but could work. But would of course not be consistent from styling point of view. The TabBar would be dsconnected from the tab content, wouldn't it?

You'd have a TabBar w/o a TabWidget (like konsole) - there would be no containment for the tabbed content, no.


- Thomas


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122985/#review77608
-----------------------------------------------------------


On März 17, 2015, 9:59 vorm., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122985/
> -----------------------------------------------------------
> 
> (Updated März 17, 2015, 9:59 vorm.)
> 
> 
> Review request for kwin, Plasma, Kai Uwe Broulik, and Thomas Pfeiffer.
> 
> 
> Repository: kwin
> 
> 
> Description
> -------
> 
> If the window is small the list of decorations might not be visible at
> all giving a bad first impression on opening systemsettings and also
> making the user interface difficult to use.
> 
> This change ensures that at least two decorations are visible before
> we try to show the buttons view. So only if the window is large enough
> the button configuration will be shown.
> 
> Otherwise a push button is displayed to explicitly show the button config
> interface. This explicit show is not bound to the size of the window.
> 
> If the window gets resized in a way that there is enough place for the
> button interface the view is shown autmatically and the button is hidden.
> 
> There is no button to hide the view again. This is considered not needed
> as at that point a user already has seen the view and recognized that
> the list of decorations can be scrolled.
> 
> 
> Diffs
> -----
> 
>   kcmkwin/kwindecoration/qml/Previews.qml eabc666432b5df04e929f1ba640a79cd99714a9d 
>   kcmkwin/kwindecoration/qml/main.qml 4d8bcf8c98f238676e9128da20f4969980bf143c 
> 
> Diff: https://git.reviewboard.kde.org/r/122985/diff/
> 
> 
> Testing
> -------
> 
> 
> File Attachments
> ----------------
> 
> Buttons hidden on small window
>   https://git.reviewboard.kde.org/media/uploaded/files/2015/03/17/fe54076a-1d58-49c4-a27d-f49da4f3bb97__view-small.png
> Buttons automatically shown if window is large enough
>   https://git.reviewboard.kde.org/media/uploaded/files/2015/03/17/29970eae-8189-47c3-b942-6aade7111956__view-large.png
> 
> 
> Thanks,
> 
> Martin Gräßlin
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150318/46e1ab21/attachment-0001.html>