Context View Bookmarks

Orville Bennett illogical1 at gmail.com
Wed Oct 7 14:47:19 CEST 2009


On Wednesday 07 October 2009 02:22:26 Nikolaj Hald Nielsen wrote:
> 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
Horrible name. It doesn't indicate what this feature/functionality does at 
all. I'd suggest changing it to something more descriptive. Like 'save context 
view layout'

> 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
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel


More information about the Amarok-devel mailing list