> 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 > >
_______________________________________________ Plasma-devel mailing list [email protected] https://mail.kde.org/mailman/listinfo/plasma-devel
