Activity epiphany

[Duncan]

Over the months and years since kde4 came out, I've read a lot about 
activities... and they always seemed "nice" in an abstract "wow, it's 
nice they can do that" kind of way, but not necessarily something I'd use 
a lot, personally, tho I couldn't really put my finger on why I wasn't as 
personally enamored with them as I might be.

Today I figured it out.

The trigger for my epiphany was reading yet another blurb about another 
article by Aaron Seigo on activities, as it happened, on his epiphany 
that lead to the ideas that have gradually evolved into activities as we 
know them in kde (and the new plasma-active).

Here's the article:

http://aseigo.blogspot.com/2011/10/activities.html

Quoting the first couple paragraphs (combined) as they appeared in my 
feed reader:

> Several years ago now I had a minor epiphany while doing field research
> in the offices of friends and work associates on how people use their
> computers. The ideas led to the concept of "Activities", which I
> originally called "Projects" (we changed the name because it was about
> more than just things we could call a "project").The idea was fairly
> grand: you communicate to the computer what you are currently doing and
> it adapts to that. You would be able to teach it what it means to be
> doing that thing: "I use these files, talk to these people, need this
> network connection, want these applications ..." The teaching would
> happen over time as you engage in your activity, whatever it might be.


As I said, I finally got it, I think, and why altho it's a great feature 
for general computer newbies, it's not all that impressive in actual 
practice for me personally, because my personal assumptions are that of a 
power user comfortable at the command line and with scripting.

Basically, all activities are, from a computer power-user perspective, is 
an automated method to batch a bunch of apps with their content together, 
launching and shutting them down as a unit, potentially at the same time 
changing configuration options that affect that activity -- disabling 
screensavers and automatic display sleep cycles when activating a movie 
activity, for instance, then activating them again when switching to some 
other activity.

For a relative computer novice, or one more accustomed to taking an 
adversarial position regarding their computer because they can never seem 
to get it to work the way they want, as opposed to a computer power user 
who appreciates the way computers work, and uses that to their advantage, 
to the point they don't even realize half the stuff they're doing any 
more as it's so intuitive to them now... to that non-power-user, 
activities have the potential to open up a whole new world of automation 
for them, one they never appreciated as existing, before.

But, for the already computer power user, the story is far different.  To 
them, if they want a bunch of things to startup together, including a few 
config changes, the intuitive answer is to write a script.  This script 
starts the apps and loads the appropriate data; if the intent is to watch 
a movie, it runs xset and etc to turn the display sleep timeout off if; 
if necessary, apps are started with a different title or profile or 
whatever, using command line options, so the appropriate kwin window 
rules will apply and place and size the window appropriately for that 
activity, including the appropriate virtual desktop, always-on-top, etc, 
settings; the script will either launch everything and quit, or wait 
around to reset things when the user's done and shuts down the key app; 
if necessary, the script will sleep a few seconds and then launch wmctrl 
to reposition the windows; etc.

FWIW, it can be noted that /exactly/ this sort of thing is what I do, 
routinely.  When kde4 killed khotkey multi-key support, I grumbled quite 
a bit, then had the insight that I could accomplish the same thing by 
having an initial key launch a customized menu app, that took the second 
key and issued the appropriate command; a few hours later, I had exactly 
that sort of solution scripted and running.  As part of that solution, I 
start a konsole session with a special profile, so kwin can detect that 
it's not a normal konsole window, and treat it differently using window 
rules.  I routinely setup window rules as needed to get windows to go 
where I want and behave as I want.  At one point, the window name was 
changing after launch and I couldn't get window rules to put it where I 
wanted without using force, which then wouldn't let me move it if 
desired, so I searched for, installed, and setup a wrapper script that 
handled it all for me.  I have scripts that launch a whole series of 
commands in a particular order, waiting when necessary, etc.

All this is now second nature to me, just part of using the computer.  So 
activities don't actually do much for me that I couldn't do already, only 
with more control, because I setup the script/config/whatever to do 
exactly what I wanted, when I wanted it.
 
For this power user, therefore, activities aren't a big deal, since they 
don't really offer me any sort of functionality I don't already have and 
use more or less routinely.

Meanwhile, that one word I mentioned two paragraphs up, control, is 
important to me.  Certainly at this stage, and I expect for some time 
altho the kinks should be worked out eventually, there's all sorts of 
bugs and unimplemented features in the activities implementation, at 
least compared to what I'm already using.  That's no fault of activities; 
they're simply at an early stage in their evolution at this point, while 
the various tools I currently use are reasonably mature by this point, 
and my comfort and confidence level in using them relatively high.

But, as someone mentions in the comments as an example; say they need to 
know the bus schedule.  They resume their laptop, start up the app, load 
the schedule, find when the bus comes, then put the laptop to sleep.  
Later, they shutdown.  Oops, they forgot to shutdown this one-time-needed 
schedule-lookup before the activity quit for shutdown -- now the thing's 
associated with the activity!  What they SHOULD have done was switch to 
the "other/misc" activity, before starting the lookup, so it'd be 
associated with it if they forgot, instead of with whatever other 
activity they had been working on last.

The non-power-user could well learn to take that sort of issue in stride 
and live with it as a cost of all the power they now have with 
activities.  But that'd never satisfy a power user.  When they startup 
that activity, they want the stuff they configured for that activity in 
the way they configured it, no more, no less, no unexpected bus schedule 
apps starting just because that's they activity they were in when they 
happened to check the bus schedule.

With a script, that's how it works.  The script only includes what you 
put in the script in the first place, no weird bus schedule app because 
you forgot to shut it down before shutting down the activity.  It does 
what it has been programmed to do, no more, no less.

Plus, activities simply aren't that powerful yet.  The features will 
likely come, but there's a lot of experimentation and development, and 
buggy first implementations to work thru, between now and then.  
Meanwhile, the power user already has the tools at his disposal, or knows 
where to get them, to do what he needs to do.  They're reasonably mature 
and do what they're supposed to do.  No experimentation and development, 
no buggy first implementations (but a script-writer's own) to go thru 
before it's working exactly as the power-user desires.


So, yeah, activities might be nice... someday.  But now I understand why 
they don't seem like that big a deal to me, today, and why I've been 
disappointed and frustrated with the still missing features and bugginess, 
when I /have/ experimented with them.  That's not their fault, or that of 
the kde or plasma devs.  That's just the state those tools are in.  
Meanwhile, power users at least have had alternatives that do very much 
the same thing, except with more predictability and control, for years.  
It's the non-power-users that might at some point seriously benefit, and 
yes, at some point, when it all "just works", it might be a reasonable 
and by then lower hassle replacement for the existing tools the power-
user is using today, but even then, for the power-user, it won't be that 
big of a deal, because they'll have been used to being able to do that 
for years, and will have taken the ability to do so for granted.  This 
new tool will be just that, simply another tool in the toolbox to be 
used, but not the only one that can do the job, and probably quite often, 
not the /best/ one for the job, not because the tool isn't good at what 
it does, but because what it does is a poor fit for the exact purpose the 
power user had in mind.  After all, a knife can often be used as a 
screwdriver, but using the correct size/type screwdriver for the screw 
does tend to make the job go much smoother. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.