[prev in list] [next in list] [prev in thread] [next in thread]
List: kwin
Subject: Re: Review Request 109832: New tabbox layout with scaling thumbnails
From: Martin_Gräßlin <mgraesslin () kde ! org>
Date: 2014-10-29 11:35:35
Message-ID: 20141029113535.23655.51314 () probe ! kde ! org
[Download RAW message or body]
--===============1724135528992450779==
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
> On Oct. 21, 2014, 2:32 p.m., Martin Gräßlin wrote:
> > <offtopic>How did you convince reviewboard to accept a patch for a different git \
> > repository?</offtopic>
> > ontopic: we still don't know what to do with multiple switchers. We probably \
> > shouldn't include all of them in KWin, but get them from somewhere else - I agree \
> > that this shouldn't be kde-look and that it bitrots there. We need a better third \
> > party story. Muon is going to become part of 5.2 and thus maybe it can offer some \
> > help there.
> > I'm a little bit reluctant to take on more styles as in general it increases the \
> > work load. If I think about it, we should even remove all except the default one \
> > and make all others 3rd-party.
>
> Andre Heinecke wrote:
> > How did you convince reviewboard to accept a patch for a different git \
> > repository?
>
> Uploaded a git format-patch and explicitly told reviewboard the full commit id of \
> the parent commit.
> > I'm a little bit reluctant to take on more styles as in general it increases the \
> > work load. If I think about it, we should even remove all except the default one \
> > and make all others 3rd-party.
>
> I can understand your reluctance to avoid having to maintain a load of different \
> window switchers especially as the used API changes so rapidly. (Well this might \
> not be the case anymore now that 5 is out) But to declare them third party (Not our \
> Problem) and move them out is not the right solution imho. I doubt that suddenly a \
> "Plasma Windowswitcher Plugin" community will emerge to maintain plugins. So you \
> (or other people that are already part of Kwin anayway) will probably end up having \
> to keep a third party repository in step with the KWin API. And as you need a \
> different plugin for KDE 4.8, 4.10 and 5.x I would argue to keep them close at hand \
> as their versions are closely linked to kwin.
>
> Anyhow. If KWin decides in the future to move the plugins out and only maintain the \
> default window switcher it should not hurt that much to have nine plugins to move \
> instead of eight ;-) But atm I think it is the best place for this code.
> Martin Gräßlin wrote:
> nah, it's not about keeping it compatible to API changes. It's about being high \
> polished. Not all of the switchers we have are polished and to be honest they are \
> not in a quality allowing them to be part of the official release. If they are 3rd \
> party provided the quality doesn't have to be up to the standard one should be able \
> to expect from something shipped together with KWin.
> Andre Heinecke wrote:
> I disagree with your last statement but I do not think this is the place to discuss \
> it.
> A more fundamental discussion should be held on a mailing list. But I don't see why \
> the outcome of this discussion should block this commit.
> If you think that some layouts should be removed Ok. But this is not just another \
> "Small vs. Big Icons" thing this is a different approach to the scrolling tabbox \
> layouts that always show the same information regardless of how much windows a user \
> has opened. There is a demand for such a layout (as shown with the Box switch and \
> in Bugreports). It has been available (and the default) in KDE until the KDE 4.7 / \
> 4.8 qmlification of KWin took it away. In \
> https://bugs.kde.org/show_bug.cgi?id=292566#c9 you are even telling a user who is \
> unhappy with the available layouts to write an alternative. Here is the \
> alternative.
> It has been available on KDE-Look.org for over a year so it already is tested and \
> the general reception on KDE-Look was favorable.
> Please be more specific here and give me a hard reason why you do not want to \
> accept this plugin so that I can work on resolving the issue either through \
> discussion or code. If you find some faults with or have improvement suggestions we \
> should try to resolve those. But I think it is unfair that you keep rejecting this \
> plugin for reasons that are not related to it and about which I can do nothing.
> Martin Gräßlin wrote:
> ok I have to agree with your reasoning and cannot say anothing against it :-). I'll \
> do another review on the QML code and give it a try. If I haven't done so by Friday \
> please yell again.
> Thomas Lübking wrote:
> Disclaimer:
> I don't use a "tabbox", no matter which. It's an indirection layer and i deem that \
> a stupid.
> That being said, I tested the "scaling" (then name is meaningless and has to change \
> in any case) switcher against the available ones, notably the two related ones \
> "thumbnails" and "grid".
>
> Observations:
> --------------
> For few windows,
> the switchers behave "similar", "thumbnails" and "scaling" are indistiguishable, \
> except for the second (...) indirection, ie. the icon+label on the bottom. In this \
> scenario, "grid" is probably worst, since it covers the screen for no actual \
> reason. Whether one likes the "one label" or "all labels" approach of "thumbnails" \
> resp. "scaling" better, is propbably subjective. I'd prefer the "one label" aspect, \
> since it allows me to steer on the center of the screen and wait until the wanted \
> label appears.
> For many windows (tested 30+) things flip.
> Both, "thumnails" and "scaling" now need to scroll (and suddenly show only one \
> label) - "scaling" needs to scroll less, but as trade-off only shows icons, no more \
> thumbnails. "Grid" is in clear advance here, since it makes by far better usage of \
> the available space. If one should change a thing, i'd flip rows (it's still a \
> stupid sequential switcher), ie.
> 1 2 3
> 6 5 4
> 7 8 9
>
> For a mid-range amount of window (roundabout 12),
> "scaling" again only shows one label like "thumbnails".
> "Scaling" is better than "thumbnails" in that it does give you an idea about how \
> many windows there are and where they are (for switching direction) while \
> "thumbnails" is (as "scaling" becomes for many windows) a surprise game. Otoh, \
> "scaling" scales down thumbnails to a degree where they're nearly useless.
>
> Summary & suggestion:
> ---------------------
> "thumbnails" and "scaling" are somewhat equal for few windows and both fail \
> (differently) for many windows, ie. they do not scale. If one ignores that the \
> entire sequential window switching concept does not scale (present windows easily \
> beats both), my suggestion would be to merge all three approaches and have a \
> switcher that seeks to show thumbnails at a reasonable size, starts \
> one-dimensionally ("scaling") while possible for a reasonable thumbnail size, falls \
> over to 2D ("grid") and finally resorts to scrolling (rather than scaling \
> thumbnails to a degree where they turn useless, or starts being an icon-only \
> switcher) The 2D mode should flip rows, so that your eye doesn't have to perform a \
> CR.
> If there's only one label, it should always (1D and 2D) be in the same position of \
> the switcher (bottom center, resp. center for 2D)
> Marcus Moeller wrote:
> I would not welcome to completely switch the style on a larger number of windows. \
> 30+ windows is a special scenario and not a typical one. The scaling switcher might \
> be a trade-off, but it's a good one.
> Thomas Lübking wrote:
> The point is that the scaling switcher becomes useless for 10+ windows (you could \
> just as well use a pure icon switcher, since the thumbnails become too tiny) - and \
> for 3-4 windows, there's no actual difference to "thumbnails" at all. So the range \
> where it makes a difference is 5-10 windows and in that range the approach can be \
> used to a benefit.
> You're probably right in that 10+ windows are not "typical", yet that can hardly \
> mean that we should leave the user with a inferior/useless window switcher in that \
> case.
> My point is that atm. there're two switchers which cover a distinct windowcount \
> range and now it's suggested to even introduce a third one, but instead of having 3 \
> switchers which all work good in *some* cases and have defects otherwise, it would \
> be good to have one switcher which the user can rely one in any case.
> It's also not like the layout would usually switch while you're invoking the \
> switcher and, just for the records, the pitched "scaling" switcher already *does* \
> alter it's style depending on the amount of windows.
> Marcus Moeller wrote:
> Yes, scaling also changes it's style, but not completely. What about replacing \
> thumbnails with scaling and to drop grid? I have asked a collegue who works with \
> scaling and 15+ windows and he is fine with it.
> Martin Gräßlin wrote:
> > What about replacing thumbnails with scaling and to drop grid?
>
> no, thumbnails is not scaling to address the shortcomings of the pre-QML based \
> ones. And grid exists as a replacement for Present Window's Alt+Tab mode. Please \
> explain to the angry mob why we had to drop it ;-)
> Marcus Moeller wrote:
> Ok, then I would suggest, just to add scaling.
>
> Andre Heinecke wrote:
> To respond to some of Thomas points:
> (First thanks for testing and the feedback)
>
> Yes the elements in this tabbox plugin are also found in the other layouts but uhe \
> whole idea is that there are layouts that work ok for different amounts of windows. \
> But I don't want to change the tabbox plugin to match my opened windows as the \
> amount changes over my workday so the scaling switcher (maybe a better name would \
> be adaptive or so, suggestions welcome) switches between those layouts when \
> appropiate.
> If you think the thumbnail is scaled down too much we could make the switch to \
> icons only earlier.
> But I usually start my workday with around 4-5 open windows and end it with ~20. On \
> my screen with a 1920x1080 resolution this is fine with the scaling switcher. The \
> most useful information for me is the Icon of a Program, the thumbails are nice \
> (even small ones) to distinguish between the same program without having to read \
> the title.
> Btw. I do not like present windows as I find it too distruptive and it does not \
> work well for multiple screens where I have to search the Windows on my screens. \
> And a tabbox is also something I'm very much used to. But I won't argue against \
> present windows it is a great mode for users who prefer it. Choice and \
> configurability is great! :-)
> I'm not totally against changing State 3 (icons only) to a state where the tabbox \
> has multiple rows. Or adding a fourth state to avoid scrolling when even the icons \
> are too much to fit into one row. But I would prefer not to do this here and now as \
> I think this is an improvement which could be made later and is a bit of a taste \
> issue.
> This is not a tabbox plugin to end all tabbox other tabbox layout. I don't want to \
> force this layout on anybody. It should just be an alternative for those missing \
> the old behavior and which have a window behavior for which this layout works.
> Thomas Lübking wrote:
> Unless you're in hurry because of some external force, i don't see any reason to \
> act in a rush. There /is/ a way to install this switcher (took me less than 5s via \
> GHNS) and plasma next isn't very widespread on enduser systems yet.
> My suggestion -this very switcher aside- is to have a small default set of largely \
> different (eg. thumbnail aren't avialable w/o compositing and there's a difference \
> between a vertical and horizontal layout, latter available as all time tiny list) \
> switchers shipped w/ kwin - and have all "my small pet deviation" switcher at GHNS. \
> That's what it was made for.
> So, with all due to respect, my vote is to "think, decide, act" rather than "act, \
> think, redecide" unless immediate action is really require ("hotfix") - what I do \
> not see here. You waited a year, it should be no problem to think this through for \
> two weeks, maybe invoke HIG and VDG team, and then push something to not revert it \
> the next month.
> Marcus Moeller wrote:
> I guess Andres offer to change some parts of the Switcher have been directly \
> related to your complaints, Thomas. For us, the switcher works perfectly as it is. \
> There is no need to change it, please just include it in the official release.
> Thomas Lübking wrote:
> Since you've blatantly ignored my entire argumentation on the topic of what should \
> be in the "official release" (a well thought minimum set of switchers, different in \
> key aspects) and what not (everyones pet project), I'll be more direct.
>
> I do not see why we should accomplish one half-baked solution w/ a second one, \
> notably since the (very good indeed) reasoning behind this variant is "I don't want \
> to change the tabbox plugin to match my opened windows as the amount changes over \
> my workday" and everyone can add his most beloved deviation with ease.
> In the end, we'd be shipping 100 variations ("oooohhh... you took Andys, why don't \
> you accept mine then?") of basically the same switcher out of the box and to be \
> very clear on this: in most cases this variant is either not different from \
> "thumbnails" or defective just as much (both do not scale very good w/ amount of \
> windows)
> Whether it "works perfectly" for "you" (anon. pl.), I frankly do not care in this \
> regard, since NOTHING hinders you (sg.) or anyone else from using it right now.
> Also please notice: once upstreamed, it's no longer a pet project.
> WRT Martins consideration "we should even remove all except the default one" and if \
> discussion with HIG/VDG eg. ends up in "merge with thumbnails and grid" that will \
> just happen, possibly even before the next release.
> So basically, you're asking to intentionally clutter the git history and piss \
> Andre, by ripping his code after feigning a merge. Sorry, but that doesn't sound \
> like a very smart strategy to me.
> Marcus Moeller wrote:
> Scaling is different from classic thumbnails, because thumbnails is scrolling even \
> on a few windows. This leads to the fact, that one does not have an overview of all \
> active open windows, which is very annoying. Only this fact, is a good argument for \
> inclusion of the scaling switcher.
> Concerning the general discussion, what I see is that contributions are not \
> honoured within the project, but that's another topic. In the past, KDE was known \
> for it's flexibility and options, but this does not seem to be the case anymore. \
> When it comes to quality, I do not share your concerns about the Scaling switcher, \
> as it works well, even for a large number of applications.
> Marcus Moeller wrote:
> Btw. for reference: here is the original bug I have opened \
> https://bugs.kde.org/show_bug.cgi?id=292566 to get a full view of what happened. \
> Maybe you can get my point, too Thomas.
> Martin Gräßlin wrote:
> > Only this fact, is a good argument for inclusion of the scaling switcher.
>
> well grid would also solve this, so that's not really a good argument
>
> > Concerning the general discussion, what I see is that contributions are not \
> > honoured within the project, but that's another topic.
>
> no, we just don't have concluded yet *where* to put the contribution. As you might \
> notice I suggested here to remove all switchers which I implemented.
> > When it comes to quality, I do not share your concerns about the Scaling \
> > switcher, as it works well, even for a large number of applications.
>
> any idea how many corner cases we have hit in the past with the switchers? \
> Personally I doubt that they are handled as they cannot be known to external \
> contributors. As always getting the last 10 % right costs 90 % of the work. Thus I \
> don't believe in that it "works well". That might be me just overly negative or one \
> could call it experience.
> Anyway I'll raise a discussion on plasma-devel and in the VDG forum on the strategy \
> for further switchers.
> Martin Gräßlin wrote:
> forum thread created: https://forum.kde.org/viewtopic.php?f=285&t=123383
>
> Marcus Moeller wrote:
> As the conclusion seems to be to move all switchers but sidebar to \
> kdeplasma-addons, it would be great if you could continue to review the current \
> status of the scaling switcher.
could you please add plasma to the review group: there are our QML experts :-)
- Martin
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/109832/#review68803
-----------------------------------------------------------
On Oct. 21, 2014, 2:19 p.m., Andre Heinecke wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/109832/
> -----------------------------------------------------------
>
> (Updated Oct. 21, 2014, 2:19 p.m.)
>
>
> Review request for kwin and Martin Gräßlin.
>
>
> Bugs: 292566
> http://bugs.kde.org/show_bug.cgi?id=292566
>
>
> Repository: kde-workspace
>
>
> Description
> -------
>
> I'm reopening this review request as I have updated this Window Switcher for Plasma \
> 5.1 and would like to get another review to check if there are any suggestions or \
> issues regarding the port to the new API.
> Secondly I would like to ask again to have this Window Switcher Layout included in \
> the KWin repository. I would prefer it if users could obtain this layout from their \
> trusted distributors and did not have to rely on an unverifyable third party \
> download to obtain this plugin.
> As suggested in the original review I've put this up on kde-look and recieved some \
> positive feedback. But I really feel that it is rotting away there and that \
> KDE-Look is not a good place to distribute executable plugins.
> IMHO the approach of this Window Switcher is different enough from the others \
> included in KWin to be a useful addition to the fold. Especially as this behavior \
> is already familiar to KDE users from some versions < 4.6
> It should also be close enough to the other layouts like thumbnails to keep \
> maintenance very similar (I've mostly looked at the changes made to thumbnails to \
> adapt this for Plasma 5)
>
> Original description:
>
> This Layout tries to mimic some of the old KDE 4.6 tabbox behavior and layout, it \
> scales the thumbnails shown in the tabbox to avoid scrolling. There are also three \
> different states in this layout depending on the size of the scaled thumbnails to \
> provide appropriate information even when there are many opened windows.
> States:
> 1. Thumbnails are larger then 200px: Show the Title and the Icon of the Window \
> directly below the thumbnail. 2. Thumbnails are between 200px and 64px: Thumbnails \
> are shown together with the icon but only the title of the currently selected \
> window is shown. 3. Thumbnails would be smaller then 64px: Only the Icons of the \
> windows are shown and the title of the currently selected window (like big icons) \
> If the Thumbnails would be smaller then 32px the tabbox starts to scroll in the \
> Icon Only state.
> Size of the thumbnails depends on the screen size and the number of opened windows.
>
>
> Diffs
> -----
>
> tabbox/qml/CMakeLists.txt fc55ab9
> tabbox/qml/clients/scaling/contents/ui/main.qml PRE-CREATION
> tabbox/qml/clients/scaling/metadata.desktop PRE-CREATION
>
> Diff: https://git.reviewboard.kde.org/r/109832/diff/
>
>
> Testing
> -------
>
> Tested with plasma 5.3.1 from Kubuntu next / unstable repositories.
>
>
> Thanks,
>
> Andre Heinecke
>
>
--===============1724135528992450779==
MIME-Version: 1.0
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 8bit
<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="12" style="border: 1px #c9c399 \
solid; border-radius: 6px; -moz-border-radius: 6px; -webkit-border-radius: 6px;"> \
<tr> <td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://git.reviewboard.kde.org/r/109832/">https://git.reviewboard.kde.org/r/109832/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <p style="margin-top: 0;">On October 21st, 2014, 2:32 p.m. CEST, <b>Martin \
Gräßlin</b> wrote:</p> <blockquote style="margin-left: 1em; border-left: 2px solid \
#d0d0d0; padding-left: 10px;"> <pre style="white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;"><offtopic>How did you convince reviewboard to \
accept a patch for a different git repository?</offtopic></p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">ontopic: we still don't know what to do with multiple switchers. We \
probably shouldn't include all of them in KWin, but get them from somewhere else - I \
agree that this shouldn't be kde-look and that it bitrots there. We need a better \
third party story. Muon is going to become part of 5.2 and thus maybe it can offer \
some help there.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">I'm a little bit reluctant to take on \
more styles as in general it increases the work load. If I think about it, we should \
even remove all except the default one and make all others 3rd-party.</p></pre> \
</blockquote>
<p>On October 21st, 2014, 3:09 p.m. CEST, <b>Andre Heinecke</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote \
style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">How did you convince reviewboard to accept a patch for a different git \
repository?</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Uploaded a git format-patch and explicitly told \
reviewboard the full commit id of the parent commit.</p> <blockquote \
style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">I'm a little bit reluctant to take on more styles as in general it \
increases the work load. If I think about it, we should even remove all except the \
default one and make all others 3rd-party.</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">I can understand your reluctance to avoid having to \
maintain a load of different window switchers especially as the used API changes so \
rapidly. (Well this might not be the case anymore now that 5 is out) But to declare \
them third party (Not our Problem) and move them out is not the right solution imho. \
I doubt that suddenly a "Plasma Windowswitcher Plugin" community will emerge to \
maintain plugins. So you (or other people that are already part of Kwin anayway) will \
probably end up having to keep a third party repository in step with the KWin API. \
And as you need a different plugin for KDE 4.8, 4.10 and 5.x I would argue to keep \
them close at hand as their versions are closely linked to kwin.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Anyhow. If KWin decides in the future to move the plugins out and only \
maintain the default window switcher it should not hurt that much to have nine \
plugins to move instead of eight ;-) But atm I think it is the best place for this \
code.</p></pre> </blockquote>
<p>On October 21st, 2014, 3:17 p.m. CEST, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">nah, \
it's not about keeping it compatible to API changes. It's about being high polished. \
Not all of the switchers we have are polished and to be honest they are not in a \
quality allowing them to be part of the official release. If they are 3rd party \
provided the quality doesn't have to be up to the standard one should be able to \
expect from something shipped together with KWin.</p></pre> </blockquote>
<p>On October 22nd, 2014, 1:44 p.m. CEST, <b>Andre Heinecke</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I \
disagree with your last statement but I do not think this is the place to discuss \
it.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">A more fundamental discussion should be held on a \
mailing list. But I don't see why the outcome of this discussion should block this \
commit.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">If you think that some layouts should be removed Ok. \
But this is not just another "Small vs. Big Icons" thing this is a different approach \
to the scrolling tabbox layouts that always show the same information regardless of \
how much windows a user has opened. There is a demand for such a layout (as shown \
with the Box switch and in Bugreports). It has been available (and the default) in \
KDE until the KDE 4.7 / 4.8 qmlification of KWin took it away. In \
https://bugs.kde.org/show_bug.cgi?id=292566#c9 you are even telling a user who is \
unhappy with the available layouts to write an alternative. Here is the \
alternative.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">It has been available on KDE-Look.org for over a year \
so it already is tested and the general reception on KDE-Look was favorable.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Please be more specific here and give me a hard reason why you do not want \
to accept this plugin so that I can work on resolving the issue either through \
discussion or code. If you find some faults with or have improvement suggestions we \
should try to resolve those. But I think it is unfair that you keep rejecting this \
plugin for reasons that are not related to it and about which I can do \
nothing.</p></pre> </blockquote>
<p>On October 22nd, 2014, 3:05 p.m. CEST, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">ok I \
have to agree with your reasoning and cannot say anothing against it :-). I'll do \
another review on the QML code and give it a try. If I haven't done so by Friday \
please yell again.</p></pre> </blockquote>
<p>On October 22nd, 2014, 4:01 p.m. CEST, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Disclaimer: I don't use a "tabbox", no matter which. It's an indirection \
layer and i deem that a stupid.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">That being said, I \
tested the "scaling" (then name is meaningless and has to change in any case) \
switcher against the available ones, notably the two related ones "thumbnails" and \
"grid".</p> <h2 style="font-size: 100%;text-rendering: inherit;padding: \
0;white-space: normal;margin: 0;line-height: inherit;">Observations:</h2> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">For few windows, the switchers behave "similar", "thumbnails" and "scaling" \
are indistiguishable, except for the second (...) indirection, ie. the icon+label on \
the bottom. In this scenario, "grid" is probably worst, since it covers the screen \
for no actual reason. Whether one likes the "one label" or "all labels" approach of \
"thumbnails" resp. "scaling" better, is propbably subjective. I'd prefer the "one \
label" aspect, since it allows me to steer on the center of the screen and wait until \
the wanted label appears.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">For many windows (tested 30+) things \
flip. Both, "thumnails" and "scaling" now need to scroll (and suddenly show only one \
label) - "scaling" needs to scroll less, but as trade-off only shows icons, no more \
thumbnails. "Grid" is in clear advance here, since it makes by far better usage of \
the available space. If one should change a thing, i'd flip rows (it's still a stupid \
sequential switcher), ie.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">1 2 3 6 5 4
7 8 9</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">For a mid-range amount of window (roundabout 12), \
"scaling" again only shows one label like "thumbnails". "Scaling" is better than \
"thumbnails" in that it does give you an idea about how many windows there are and \
where they are (for switching direction) while "thumbnails" is (as "scaling" becomes \
for many windows) a surprise game. Otoh, "scaling" scales down thumbnails to a degree \
where they're nearly useless.</p> <h2 style="font-size: 100%;text-rendering: \
inherit;padding: 0;white-space: normal;margin: 0;line-height: inherit;">Summary & \
suggestion:</h2> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">"thumbnails" and "scaling" are somewhat equal for few \
windows and both fail (differently) for many windows, ie. they do not scale. If one \
ignores that the entire sequential window switching concept does not scale (present \
windows easily beats both), my suggestion would be to merge all three approaches and \
have a switcher that seeks to show thumbnails at a reasonable size, starts \
one-dimensionally ("scaling") while possible for a reasonable thumbnail size, falls \
over to 2D ("grid") and finally resorts to scrolling (rather than scaling thumbnails \
to a degree where they turn useless, or starts being an icon-only switcher) The 2D \
mode should flip rows, so that your eye doesn't have to perform a CR.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">If there's only one label, it should always (1D and 2D) be in the same \
position of the switcher (bottom center, resp. center for 2D)</p></pre> \
</blockquote>
<p>On October 22nd, 2014, 4:07 p.m. CEST, <b>Marcus Moeller</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I \
would not welcome to completely switch the style on a larger number of windows. 30+ \
windows is a special scenario and not a typical one. The scaling switcher might be a \
trade-off, but it's a good one.</p></pre> </blockquote>
<p>On October 22nd, 2014, 4:25 p.m. CEST, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">The \
point is that the scaling switcher becomes useless for 10+ windows (you could just as \
well use a pure icon switcher, since the thumbnails become too tiny) - and for 3-4 \
windows, there's no actual difference to "thumbnails" at all. So the range where it \
makes a difference is 5-10 windows and in that range the approach can be used to a \
benefit.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">You're probably right in that 10+ windows are not \
"typical", yet that can hardly mean that we should leave the user with a \
inferior/useless window switcher in that case.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">My \
point is that atm. there're two switchers which cover a distinct windowcount range \
and now it's suggested to even introduce a third one, but instead of having 3 \
switchers which all work good in <em style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: normal;">some</em> cases and have \
defects otherwise, it would be good to have one switcher which the user can rely one \
in any case.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">It's also not like the layout would usually switch \
while you're invoking the switcher and, just for the records, the pitched "scaling" \
switcher already <em style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: normal;">does</em> alter it's style depending on the amount of \
windows.</p></pre> </blockquote>
<p>On October 22nd, 2014, 4:41 p.m. CEST, <b>Marcus Moeller</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Yes, \
scaling also changes it's style, but not completely. What about replacing thumbnails \
with scaling and to drop grid? I have asked a collegue who works with scaling and 15+ \
windows and he is fine with it.</p></pre> </blockquote>
<p>On October 22nd, 2014, 4:51 p.m. CEST, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote \
style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">What about replacing thumbnails with scaling and to drop grid?</p> \
</blockquote> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">no, thumbnails is not scaling to address the \
shortcomings of the pre-QML based ones. And grid exists as a replacement for Present \
Window's Alt+Tab mode. Please explain to the angry mob why we had to drop it \
;-)</p></pre> </blockquote>
<p>On October 22nd, 2014, 5:01 p.m. CEST, <b>Marcus Moeller</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Ok, \
then I would suggest, just to add scaling.</p></pre> </blockquote>
<p>On October 22nd, 2014, 5:06 p.m. CEST, <b>Andre Heinecke</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">To \
respond to some of Thomas points: (First thanks for testing and the feedback)</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Yes the elements in this tabbox plugin are also found \
in the other layouts but uhe whole idea is that there are layouts that work ok for \
different amounts of windows. But I don't want to change the tabbox plugin to match \
my opened windows as the amount changes over my workday so the scaling switcher \
(maybe a better name would be adaptive or so, suggestions welcome) switches between \
those layouts when appropiate.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">If you think the \
thumbnail is scaled down too much we could make the switch to icons only earlier.</p> \
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">But I usually start my workday with around 4-5 open \
windows and end it with ~20. On my screen with a 1920x1080 resolution this is fine \
with the scaling switcher. The most useful information for me is the Icon of a \
Program, the thumbails are nice (even small ones) to distinguish between the same \
program without having to read the title.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">Btw. I do not like \
present windows as I find it too distruptive and it does not work well for multiple \
screens where I have to search the Windows on my screens. And a tabbox is also \
something I'm very much used to. But I won't argue against present windows it is a \
great mode for users who prefer it. Choice and configurability is great! :-)</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">I'm not totally against changing State 3 (icons only) to a state where the \
tabbox has multiple rows. Or adding a fourth state to avoid scrolling when even the \
icons are too much to fit into one row. But I would prefer not to do this here and \
now as I think this is an improvement which could be made later and is a bit of a \
taste issue. </p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">This is not a tabbox plugin to end all tabbox other \
tabbox layout. I don't want to force this layout on anybody. It should just be an \
alternative for those missing the old behavior and which have a window behavior for \
which this layout works.</p></pre> </blockquote>
<p>On October 22nd, 2014, 10:06 p.m. CEST, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Unless you're in hurry because of some external force, i don't see any \
reason to act in a rush. There /is/ a way to install this switcher (took me less than \
5s via GHNS) and plasma next isn't very widespread on enduser systems yet.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">My suggestion -this very switcher aside- is to have a small default set of \
largely different (eg. thumbnail aren't avialable w/o compositing and there's a \
difference between a vertical and horizontal layout, latter available as all time \
tiny list) switchers shipped w/ kwin - and have all "my small pet deviation" switcher \
at GHNS. That's what it was made for.</p>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">So, with all due to respect, my vote is to "think, \
decide, act" rather than "act, think, redecide" unless immediate action is really \
require ("hotfix") - what I do not see here. You waited a year, it should be no \
problem to think this through for two weeks, maybe invoke HIG and VDG team, and then \
push something to not revert it the next month.</p></pre> </blockquote>
<p>On October 23rd, 2014, 8:25 a.m. CEST, <b>Marcus Moeller</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">I \
guess Andres offer to change some parts of the Switcher have been directly related to \
your complaints, Thomas. For us, the switcher works perfectly as it is. There is no \
need to change it, please just include it in the official release.</p></pre> \
</blockquote>
<p>On October 23rd, 2014, 10:13 a.m. CEST, <b>Thomas Lübking</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Since \
you've blatantly ignored my entire argumentation on the topic of what should be in \
the "official release" (a well thought minimum set of switchers, different in key \
aspects) and what not (everyones pet project), I'll be more direct.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">I do not see why we should accomplish one half-baked solution w/ a second \
one, notably since the (very good indeed) reasoning behind this variant is "I don't \
want to change the tabbox plugin to match my opened windows as the amount changes \
over my workday" and everyone can add his most beloved deviation with ease.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">In the end, we'd be shipping 100 variations ("oooohhh... you took Andys, \
why don't you accept mine then?") of basically the same switcher out of the box and \
to be very clear on this: in most cases this variant is either not different from \
"thumbnails" or defective just as much (both do not scale very good w/ amount of \
windows)</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Whether it "works perfectly" for "you" (anon. pl.), I \
frankly do not care in this regard, since NOTHING hinders you (sg.) or anyone else \
from using it right now.</p> <p style="padding: 0;text-rendering: inherit;margin: \
0;line-height: inherit;white-space: inherit;">Also please notice: once upstreamed, \
it's no longer a pet project. WRT Martins consideration "we should even remove all \
except the default one" and if discussion with HIG/VDG eg. ends up in "merge with \
thumbnails and grid" that will just happen, possibly even before the next \
release.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">So basically, you're asking to intentionally clutter \
the git history and piss Andre, by ripping his code after feigning a merge. Sorry, \
but that doesn't sound like a very smart strategy to me.</p></pre> </blockquote>
<p>On October 23rd, 2014, 10:47 a.m. CEST, <b>Marcus Moeller</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Scaling is different from classic thumbnails, because thumbnails is \
scrolling even on a few windows. This leads to the fact, that one does not have an \
overview of all active open windows, which is very annoying. Only this fact, is a \
good argument for inclusion of the scaling switcher.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Concerning the general discussion, what I see is that contributions are not \
honoured within the project, but that's another topic. In the past, KDE was known for \
it's flexibility and options, but this does not seem to be the case anymore. When it \
comes to quality, I do not share your concerns about the Scaling switcher, as it \
works well, even for a large number of applications.</p></pre> </blockquote>
<p>On October 23rd, 2014, 10:53 a.m. CEST, <b>Marcus Moeller</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">Btw. \
for reference: here is the original bug I have opened \
https://bugs.kde.org/show_bug.cgi?id=292566 to get a full view of what happened. \
Maybe you can get my point, too Thomas.</p></pre> </blockquote>
<p>On October 23rd, 2014, 11:08 a.m. CEST, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><blockquote \
style="text-rendering: inherit;padding: 0 0 0 1em;border-left: 1px solid \
#bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: inherit;"> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Only this fact, is a good argument for inclusion of the scaling \
switcher.</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">well grid would also solve this, so that's not really \
a good argument</p> <blockquote style="text-rendering: inherit;padding: 0 0 0 \
1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 0 0 0.5em;line-height: \
inherit;"> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Concerning the general discussion, what I see is that \
contributions are not honoured within the project, but that's another topic.</p> \
</blockquote> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">no, we just don't have concluded yet <em \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
normal;">where</em> to put the contribution. As you might notice I suggested here to \
remove all switchers which I implemented.</p> <blockquote style="text-rendering: \
inherit;padding: 0 0 0 1em;border-left: 1px solid #bbb;white-space: normal;margin: 0 \
0 0 0.5em;line-height: inherit;"> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">When it comes to \
quality, I do not share your concerns about the Scaling switcher, as it works well, \
even for a large number of applications.</p> </blockquote>
<p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">any idea how many corner cases we have hit in the past \
with the switchers? Personally I doubt that they are handled as they cannot be known \
to external contributors. As always getting the last 10 % right costs 90 % of the \
work. Thus I don't believe in that it "works well". That might be me just overly \
negative or one could call it experience.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">Anyway I'll raise a \
discussion on plasma-devel and in the VDG forum on the strategy for further \
switchers.</p></pre> </blockquote>
<p>On October 23rd, 2014, 11:18 a.m. CEST, <b>Martin Gräßlin</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">forum \
thread created: https://forum.kde.org/viewtopic.php?f=285&t=123383</p></pre> \
</blockquote>
<p>On October 29th, 2014, 12:27 p.m. CET, <b>Marcus Moeller</b> wrote:</p>
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: \
10px;"> <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">As \
the conclusion seems to be to move all switchers but sidebar to kdeplasma-addons, it \
would be great if you could continue to review the current status of the scaling \
switcher.</p></pre> </blockquote>
</blockquote>
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: \
-pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;"><p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: inherit;">could \
you please add plasma to the review group: there are our QML experts :-)</p></pre> \
<br />
<p>- Martin</p>
<br />
<p>On October 21st, 2014, 2:19 p.m. CEST, Andre Heinecke wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="12" style="border: \
1px #888a85 solid; border-radius: 6px; -moz-border-radius: 6px; \
-webkit-border-radius: 6px;"> <tr>
<td>
<div>Review request for kwin and Martin Gräßlin.</div>
<div>By Andre Heinecke.</div>
<p style="color: grey;"><i>Updated Oct. 21, 2014, 2:19 p.m.</i></p>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Bugs: </b>
<a href="http://bugs.kde.org/show_bug.cgi?id=292566">292566</a>
</div>
<div style="margin-top: 1.5em;">
<b style="color: #575012; font-size: 10pt;">Repository: </b>
kde-workspace
</div>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" \
style="border: 1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">I'm reopening this review request as I have updated \
this Window Switcher for Plasma 5.1 and would like to get another review to check if \
there are any suggestions or issues regarding the port to the new API.</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Secondly I would like to ask again to have this Window Switcher Layout \
included in the KWin repository. I would prefer it if users could obtain this layout \
from their trusted distributors and did not have to rely on an unverifyable third \
party download to obtain this plugin. </p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">As suggested in the \
original review I've put this up on kde-look and recieved some positive feedback. But \
I really feel that it is rotting away there and that KDE-Look is not a good place to \
distribute executable plugins.</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">IMHO the approach of \
this Window Switcher is different enough from the others included in KWin to be a \
useful addition to the fold. Especially as this behavior is already familiar to KDE \
users from some versions < 4.6</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">It should also be close \
enough to the other layouts like thumbnails to keep maintenance very similar (I've \
mostly looked at the changes made to thumbnails to adapt this for Plasma 5)</p> <p \
style="padding: 0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">Original description:</p> <p style="padding: 0;text-rendering: \
inherit;margin: 0;line-height: inherit;white-space: inherit;">This Layout tries to \
mimic some of the old KDE 4.6 tabbox behavior and layout, it scales the thumbnails \
shown in the tabbox to avoid scrolling. There are also three different states in this \
layout depending on the size of the scaled thumbnails to provide appropriate \
information even when there are many opened windows.</p> <p style="padding: \
0;text-rendering: inherit;margin: 0;line-height: inherit;white-space: \
inherit;">States: 1. Thumbnails are larger then 200px: Show the Title and the Icon of \
the Window directly below the thumbnail. 2. Thumbnails are between 200px and 64px: \
Thumbnails are shown together with the icon but only the title of the currently \
selected window is shown. 3. Thumbnails would be smaller then 64px: Only the Icons of \
the windows are shown and the title of the currently selected window (like big icons) \
If the Thumbnails would be smaller then 32px the tabbox starts to scroll in the Icon \
Only state.</p> <p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Size of the thumbnails depends on the screen size and \
the number of opened windows.</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: \
1px solid #b8b5a0"> <tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: \
-moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: \
break-word;"><p style="padding: 0;text-rendering: inherit;margin: 0;line-height: \
inherit;white-space: inherit;">Tested with plasma 5.3.1 from Kubuntu next / unstable \
repositories.</p></pre> </td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
<li>tabbox/qml/CMakeLists.txt <span style="color: grey">(fc55ab9)</span></li>
<li>tabbox/qml/clients/scaling/contents/ui/main.qml <span style="color: \
grey">(PRE-CREATION)</span></li>
<li>tabbox/qml/clients/scaling/metadata.desktop <span style="color: \
grey">(PRE-CREATION)</span></li>
</ul>
<p><a href="https://git.reviewboard.kde.org/r/109832/diff/" style="margin-left: \
3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>
--===============1724135528992450779==--
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic