Context View Bookmarks

[Nikolaj Hald Nielsen]

Some people have been asking about the usefulness of the Context View
bookmarks that I added yesterday, so I thought I had better explain my
reasoning behind this feature. There are a few reasons why I added
this, and I will try to cover them below.


On their own merits (as is):
Personally I find it very useful to be able to have a few predefined
applet setups that you can easily switch between, and this is exactly
what these bookmarks allows in their current form. It also adds
consistency as the 2 other major panels (content and playlist) botjh
have bookmarks of their own. Right now, the bookmarks only stores
which applets are shown, but if we ever get around to adding users
re-sizable applets or other advanced features, the bookmarks can also
store this, which will make them even more useful as it will take
longer to manually reapply such a state. In general, one of he reasons
that I think that the current implementation of this feature as is
useful is of course that there is no intelligent state handling in the
context view currently, and if/when that gets added, the user facing
context bookmarks feature can be reevaluated. Also, more on this
below.


Compound urls (aka future plan 1):
I intend to implement a type of amarok url/bookmark that allows one
url to "encode" several other urls and run them in sequence. There are
a number of uses for this, but one example could be "revert to
defaults" url that we could tell users to click on if they have really
screwed up their Amarok. For this example to work well, we need to be
able to reset which widgets are shown in the context view as well.


Triggers (aka intelligent context view state handling and beyond)
I have floated this idea on #amarok.dev a few times, and I tentatively
call it triggers, although I might come up with a better name later.
trigger is basically a hierarchical description of a user action in
Amarok. In a sense it is the exact opposite of a bookmark. For
instance, when the user activates or clicks something in the
Magnatune.com service, a trigger would get activated with info similar
to "/browse/service/Magnatune.com". With enough of these triggers, it
will be possible to allow Amarok to intelligently react to to
different user actions, and the easy and flexible way to implement
this is simply to allow triggers (or parts of triggers) to activate
amarok urls/bookmarks. So for instance, a context view bookmark that
sets up the "now playing" and "info" applet could get activated on the
trigger "/browse" which matches the "/browse/service/Magnatune.com"
trigger, as well as any other trigger activated because of the user
actively browsing something. This is of course just one small example
of what is possible with triggers, and I personally think that these
could end up being just as powerful and useful as the amarok
urls/bookmarks themselves which are now in use all over the place for
many different things, both user facing an internal.


I think this describes my reasoning for wanting context view
bookmarks, both for their own reason and as a stepping stone to other
things.

-Nikolaj