>On 13 October 2011 07:14, Duncan <1i5t5.duncan@xxxxxxx> wrote:
> 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.
I love this explanation. Short, simple, and concise :)
If anyone asks me what Activities are, I will give them this answer.
>
> 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.
>
___________________________________________________
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.
