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.
