windows and default activity assignment

[Aaron J. Seigo]

On Wednesday, December 1, 2010, you wrote:
> On Tuesday, 30. November 2010. 23.36.15 Aaron J. Seigo wrote:
> > On Tuesday, November 30, 2010, Ivan Čukić wrote:
> > > There are a few things more that need to be done for 4.7:
> > > - In 'Advanced Window/Application Settings' - show on specified/all
> > > activities - an application should be able to request to be on all
> > > activities (because it handles them internally - kmail, kopete..., or
> > > don't care at all about them - amarok, yakuake...)
> > 
> > i agree .. sort of.
> > 
> > i really don't think this should be up to apps in an explicit "set on all
> > activities" sense, anymore than how they are displayed in the system tray
> > is
> 
> Well, those settings in kwin wouldn't really exist if apps would behave as
> they should - it would be for /evil/ apps that don't want to support
> anything related to activities.

i'm not sure i understand what you mean by this. are you suggesting that even 
document windows (e.g. a pdf viewed by okular) should be managed by the app 
(okular) and shown/hidden on activity changes?

> Amarok and similar is an interesting case - I guess most ppl would want it
> on all activities, but someone would want it on a specific activity called
> "Media" or something. Further, not every non-document related application
> should be on all activities.

no automatic heuristic will be 100% accurate, so that can not be the goal. the 
idea is to get it to where it isn't making mistakes and helping to automate 
things where possible.

> For example, you could use some kind of timer
> application to measure your pay-per-hour job, and in other activities, it
> shouldn't be present.

this isn't a document centric application. it should be internally aware of 
activities, not externally managed.

> > there will always be exceptions. the goal should probably be to get
> > something 95% right with ways to alleviate the occassional incorrect
> > guesses. the gimp is not particularly interesting, tbh: it's document
> > centric, and can stop/start with activities just fine?
> 
> The problem I was referring to with gimp is the fact that it has document
> windows, and tool-windows. By the default logic - document windows will be
> tied to activities, while the toolboxes would be shown always - which
> would be quite strange :)

yes, this would be up to the application (gimp, in this case) to mark all 
relevant windows properly. however, for things like toolbox windows, i believe 
there are ways to know they "belong to" the application, as this is used to 
associate such windows with the main window in libtaskmanager iirc. or maybe 
it's in kwin? anyways ... 

> --------
> 
> Marco wrote:
> > I see it more:
> > application says nothing->all activities
> > appliction says it's about document -> single activity
> > something else -> figure out later
> 
> The second line is obvious, but the first  and the last are problematic.
> The fact an application is not reporting that it is about documents
> doesn't imply it isn't. So the user will get a quite irritating behaviour
> - some apps disappear when switching activities (KWord) while others,
> essentially the same (OOo Writer) don't.

and there is going to be nothing we can do about that. i'd rather have some 
manual intervention needed for, e.g., OOo Writer, than annoy people with 
windows doing the "obviously" wrong thing, and then not using activities at 
all as a result (which is what will happen if we don't get the window 
association mechanisms into a non-irritating state)
 
> The main problem is that we can't expect most non-KDE applications to
> support activities, while activities need to work consistently with all
> applications.

i don't agree at all. on two points:

* we _can_ get non-KDE applications to support activities, especially if it is 
done in a simple manner (such as setting simple attributes on the window, or 
interacting with a dbus service)

* consistency is not as important as not getting in the way of the user. it's 
acceptable, if not optimal, when a document window doesn't automatically 
associate itself with an activity. it's irritating, potentially confusing, and 
likely to be a reason to avoid activities altogether, if a window 
automatically associates itself with an activity when it shouldn't.

every window that behaves perfectly is a win. windows that are "dumb" are just 
unfortunate but not a deal breaker; manual intervention on the part of the 
user can fix that, and at least it's the result of direct action by the user 
(so they know what is going on). windows that are categorized incorrectly and 
moved around against the user's wishes are deadly.

the goal should be to get as many "wins" as possible while avoiding like the 
plague "losses". the "dumb" windows are just draws: neither helpful nor 
hurtful.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101201/3cd542ad/attachment.sig