gmane.comp.kde.devel.plasma

Review Request 110588: active-aboutapp: change version number to 4.0

Michael Bohlender — 2013-05-21T21:39:21

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/110588/
-----------------------------------------------------------

Review request for Plasma.


Description
-------

change displayed version number from 3.0 to 4.0

pushed to git as mbohlender/about_version


Diffs
-----

  applications/about/src/aboutapp.cpp 8278ee5 

Diff: http://git.reviewboard.kde.org/r/110588/diff/


Testing
-------

build, installed and run 


Thanks,

Michael Bohlender

_______________________________________________
Plasma-devel mailing list
Plasma-devel< at >kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Usability issue in the task bar applet

Eike Hein — 2013-05-21T21:18:26

No, otherwise Aaron couldn't have reported to have tried it.

It's at clones/kde-workspace/hein/kde-workspace<http://quickgit.kde.org/?p=clones%2Fkde-workspace%2Fhein%2Fkde-workspace.git>for
quite some time now.


Cheers,
Eike
_______________________________________________
Plasma-devel mailing list
Plasma-devel< at >kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Usability issue in the task bar applet

Mark — 2013-05-21T19:27:15

Where is your branch anyway? Or is it still private on your computer only? ;)

Re: Usability issue in the task bar applet

Eike Hein — 2013-05-21T12:44:18

I understand and actually pretty much agree with all of that, however at
this time there are some big ticket things I still need to merge in, in par-
ticular the finished launcher layout and support for manual grouping along
with uncollapsing groups inline (currently only the popup is there). There
are also some bugs I am are of, including a nasty memory corruption in
the model that hits during a series of complicated grouping-related actions.

When I'm saying "take it to hard freeze" what I mean is "I'm probably not
going to make it by the 22nd, but let's merge it ASAP once I've got the
branch in a state of completeness where it makes sense to compile an
issue list" - and hopefully that'll be rather closer to the 22nd than to
June
5th (hard freeze). So I'd still ask to wait a bit for the moment :).

But I fully agree with merging as soon as possible (in context of the above)
to maximize on QA time and flexibility. And FWIW, I don't intend to just
drop this stuff and move on; I fully intend to maintain it g

Re: Usability issue in the task bar applet

Aaron J. Seigo — 2013-05-21T12:13:40

my concern with waiting until hard freeze is that we will end up with a major 
component in master with not a lot of time to hammer out any remaining issues 
(and realistically, there will be some somewhere)

typically what happens is that the biggest issues are found first, then fixed, 
then we repeat with the next biggest issue. having only the freeze period to 
sort it all out means we usually only get to iterate the big issues and then 
the small issues end up in the release .. leading to the innevitable results 
of a feeling of lack of polish. a release or two later and it is all good, but 
i'm increasingly conservative about this (which is why we now have integration 
branches in plasma-mobile, bodega-server, etc)

in a worst case scenario, we find reasons to delay and delay and then it 
doesn't even make the hard freeze and then we're right and truly screwed.

having tried your replacement out, it already works reasonably well. i'd like 
to see it merged into master sooner rather than later so we can

Re: Usability issue in the task bar applet

Marco Martin — 2013-05-21T11:25:56

the "expected behavior" "actual behavior" of bugzilla is in the right 
direction, but again bugzilla isn't really helpful for this.

what would be needed is recording the discrepancies between expected and 
actual behaviors, but with a sample big enough. unfortunately i sense that 
relying on any kind of online poll/report tool it automatically skews the 
data. (preselects the passionate minority vs the casual users mayority)

in the end evolving very slowly and organically as plasma did for the 4.x 
series (correcting small bits tryuing in different ways from one revision to 
another, for instance greyed out vs translucent of this particular case) tends 
to give pretty good results not having big data samples

Re: Usability issue in the task bar applet

Eike Hein — 2013-05-21T10:39:35


I had been hoping to make soft freeze, but due to other commitments I've
been
delayed a bit further - and today there's more Folder View stuff to do as
well, it
seems.

So while I'm getting nervous as well I have to ask for a little more
waiting un-
fortunately, so I can get the remaining bits integrated properly.
Fortunately we're
in the feature plan so we can take it to hard freeze, as unpretty as that
is - but
should work out.
_______________________________________________
Plasma-devel mailing list
Plasma-devel< at >kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Usability issue in the task bar applet

Veeti Paananen — 2013-05-21T10:38:22

Instead of thinking along the lines of "you can disable it if wanted"
think why that behavior *exists in the first place*. I personally see
very little reason or utility for removing all contrast and
distinguishability from the icons.

The transparency effect applied to the task is already a sufficient
indication of minimization by itself. Obscuring the application icon is
unnecessary and counterproductive.

In addition, having to disable an effect related to the task bar in some
deep corner of the system settings is not very intuitive nor discoverable.

Of course, these are just my two cents.

Re: Usability issue in the task bar applet

Marco Martin — 2013-05-21T10:38:25

I think in this case a simple alpha instead of the "standard" disabled effect 
is fine.
this because the "minimized" concept is not the same as "disabled" concept, 
therefore the disabled effect is indeed not 100% correct, and just a light 
alpha may make more sense

Re: Usability issue in the task bar applet

Aaron J. Seigo — 2013-05-21T10:32:26

just make something that is reasonably good. you will never please everyone 
with the tasks widget, but you can make life good for 99% of people (you'll 
still hear from the 1%). i know that first hand from many years of working on 
the tasks widget :)

Re: Usability issue in the task bar applet

Aaron J. Seigo — 2013-05-21T10:31:28

as a bonus to using just alpha: this is easy to do in QML.

btw.. when can we merge your branch? we are up against the soft feature freeze 
for 4.11 now.

Re: Usability issue in the task bar applet

Aaron J. Seigo — 2013-05-21T10:30:26

i've described a possible solution in another email. so hopefully we can 
improve this a bit in 4.11 with the QML replacement.


sidenote 1: often when we get feedback on such things, it is due to poor 
quality hardware (e.g. a screen with horrific contrast) or incorrectly 
configured hardware (e.g. gamma and color that is so far off as to ruin any 
subtlety). screenshots capture what the computer thinks it is painting to the 
screen, not necessarly what is on screen. i've witnessed this in person a 
couple of times .. the screenshots posted to this email do not look *that* 
bad, but they could be on the wrong screen. 

sidenote 2: this is a "i don't need it, and it breaks my workflow." email

i would LOVE to have a way to accurately gauge a statistically significant 
agglomeration of user experience on such things as the inherently selfish first-
person POV (which each of us has) is utterly useless as design input. 

we have no adequate solutions to either sidenote above. ah well ..

Re: Usability issue in the task bar applet

Eike Hein — 2013-05-21T10:28:31


Hm, I'll experiment a bit and see if there's a compromise variant that
looks decent.
_______________________________________________
Plasma-devel mailing list
Plasma-devel< at >kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Usability issue in the task bar applet

Veeti Paananen — 2013-05-21T10:27:38

It is. The KDE "start menu" also has a translucent effect. The
screenshot doesn't show it very well, but another part of the task bar
clearly shows the desktop background below.

The grayscale icons are just as problematic with and without
compositing/effects and this problem is not changed by the effects in
any way.

_______________________________________________
Plasma-devel mailing list
Plasma-devel< at >kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Usability issue in the task bar applet

Eike Hein — 2013-05-21T10:26:44


Yeah, that conceptual problem - nothing guarantees that the widget is
located
on a panel, and picking the category based on containment constraints makes
things complex fast - is another reason why I haven't pursued a patch for
the
icon item ...

But I'm not keen on adding a widget-level config checkbox for this behavior
either
personally, so it's a dilemma.
_______________________________________________
Plasma-devel mailing list
Plasma-devel< at >kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Usability issue in the task bar applet

Aaron J. Seigo — 2013-05-21T10:23:44

nearly every change made is "unpopular" as measured by "someone spoke up". the 
number of changes that were wildly unpopular at first but which later become 
very popular and even immitated by other environments speaks to this.

we should be convinced by reason, not by which way the feedback wind blows.


i'm fine with bringing back some colour to the icons to aid such people. 
painting it with some alpha might work nicely to preserve both indication of 
minimization and preserving colour cues.

Re: Re: Re: Usability issue in the task bar applet

Eike Hein — 2013-05-21T10:23:44

In that case: It's still bad in a composited setup with the default theme
according
to many users, and while it doesn't bother me personally as I have
different usage
habits, I can see their point. It comes down to what on considers more
important
info to have - the icon color to recognize the app by, or an overt tell for
minimized
state.
_______________________________________________
Plasma-devel mailing list
Plasma-devel< at >kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Re: Re: Usability issue in the task bar applet

Martin Gräßlin — 2013-05-21T10:18:43

it is relevant. If it works fine in the composited setup, then the problem is 
not that it's put to grayscale, but that the contrast in the non-composited 
setup is too bad. Which would mean that should be fixed. But it doesn't 
question whether it's overall bad.

--
Martin Gräßlin_______________________________________________
Plasma-devel mailing list
Plasma-devel< at >kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Usability issue in the task bar applet

Aaron J. Seigo — 2013-05-21T10:18:39

imho this is not a good solution. the idea of "icons in the panel" is broken 
in a number of ways: the icons may not only be in the panel at all, there is 
no "the" panel (or put another way: panels may have very different purposes), 
etc. the icon handling reflects how things were a decade ago.

Re: Re: Usability issue in the task bar applet

Eike Hein — 2013-05-21T10:08:09

He's right though, this is entirely unrelated to using desktop effects or
not,
and that the icons of minimized icons get desaturized as of 4.10, with no
good way to disable that behavior, is indeed quite unpopular over in #kde.

The main reason being given is that users rely on telling windows apart by
the color of the window icon, and the effect removes but all color, so there
is significant information loss.
_______________________________________________
Plasma-devel mailing list
Plasma-devel< at >kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel

Re: Usability issue in the task bar applet

Eike Hein — 2013-05-21T10:03:53

FWIW, IMHO the real problem there is that the task manager uses the generic
Disabled icon effect via KIconEffects, instead of using the "Panel"
category. If
it used the proper category, the user could disable this effect
specifically only
for the panel via Icons -> Advanced in System Settings.

Unfortunately I have not been able to correct this bug in the QML port,
because
the QML bindings we currently have to KIconEffects are quite indirect by way
of the icon item's active prop, and there is no way to tell it what icon
category
to use. This would either need a QML API extension in libplasma1, which the
Plasma team is very reluctant to do these days, or me forking the component,
which I'm quite reluctant to do myself.




On Tue, May 21, 2013 at 11:31 AM, Veeti Paananen
<veeti.paananen< at >rojekti.fi>wrote:

_______________________________________________
Plasma-devel mailing list
Plasma-devel< at >kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel