windows and default activity assignment

[Ivan Cukic]

First of all, none of the following is regarding a perfect world where apps support 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?

If the application wants to handle its document windows, it should be able to. Not by default.

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

Yes, and that is the reason for the configuration option I’ve mentioned before. Since heuristics can't be precise, it can be useful for the users to create custom 
rules as it is currently possible for a lot of other things.

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

"Should" is the keyword here.

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

I can't consider this to be "obvious" as you've put it. Users asked Chani to make the windows tied to a single activity (I had the idea even before that, but didn't 
want to impose on others) - it wasn't done out of a whim. I agree that the 'window vanishing' effect is rather irritating, but for me the previous behaviour was 
even more. (I usually have only three windows that I want on all activities - iceweasel, kontact, konversation - while everything else I like to be per-activity)

One thing I'm sure of is that we'll get bug reports to change the behaviour either way :)

Hmh, what about a /bit/ smarter heuristic for apps that don't support activities - if the user chooses for one of the app windows to be on all activities, further 
on (across sessions) that app's new windows are on all activities by default. I the user chooses a specific activity, all newly created windows will be by default 
on the current activity.

IMO, in this case, the default behaviour wouldn't matter much.

That way, the system will know that the web browser, mail, etc... should be on all activities, while vim, kate etc... shouldn't - *even* is the apps themselves 
don't tell us that.

> * 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)

I know I'm always a pessimist here, and I'm certainly hoping you're right and activities will be supported by more than just KDE-world.



Cheerio

-- 
While you were hanging yourself on someone else's words
Dying to believe in what you heard
I was staring straight into the shining sun
    -- Pink Floyd