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

[Martin Gräßlin]

> On March 17, 2015, 9:53 a.m., 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.

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


- Martin


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


On March 17, 2015, 10:59 a.m., Martin Gräßlin wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/122985/
> -----------------------------------------------------------
> 
> (Updated March 17, 2015, 10:59 a.m.)
> 
> 
> 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/03856bd2/attachment.html>