Sort plugins by categories in the preferences window

Thank you for this wishlist item. Something like this is on my idea board as well, some loose ideas from that:

Plugin Groups
∘ Activate plugins by group and sort by group
∘ Higher-level selection of features (better for most users)
∘ Web browser bookmarks (all browser plugins)
∘ File Management (File Actions, Documents, Templates, Nautilius selected file, Trash)
∘ URL (Shorten Links, URL Actions)
∘ Some groups may be exclusive: Select only one (for example Audacious and Rhythmbox)

While Groups may be exclusive, we can have "tags" for GNOME, XFCE or similar.

A diarial note is that the Kupfer Plugins plugin was added so that I could search & filter the plugin list easily (there is also the Show Souce Button in Kupfer form -- the Show Source Code action on plugins, isn't that great?). Anyway, that's often how it goes: it's much easier to add to Kupfer's catalog than to design new UI in the preferences window. Once you're addicted to one interface (Kupfer) better stick to that!

Anyway, a search/filter box for the list of plugins would be useful.

Also, we should continually try to combine smaller plugins with each other if it makes sense.

Hi,
Please take a look on attached patch.
I have added entry field to filter plugins list. Simple but helpful.

Regards,
Karol

2010/1/24, Karol Będkowski <email address hidden>:
> Hi,
> Please take a look on attached patch.
> I have added entry field to filter plugins list. Simple but helpful.
>
> Regards,
> Karol
>

Hey, very nice!

I think we should use Kupfer's string ranker though, it would be the
least surprising to the users (For example that "ntes" matches
"Notes").

The function is kupfer.core.relevance.score(s, query).

It's slightly more tricky -- do we want to keep the list of matches
sorted or not? For a simple filter it might make sense, you have the
matches all laid out. Also we either use a relevancy ">0" criteria
or a cutoff such as relevancy > 0.1.

It would also be nice if the left hand side switches to the top
plugin. It shouldn't flicker and update for every keystroke, but
gently switching to the first in the list would be fine (a
scheduler.Timer repeatedly set everytime we filter the list would do
fine I think).

Ulrik

And when I say left I sometimes mean right. I must have some brain defect.

2010/1/24, Ulrik Sverdrup <email address hidden>:
> 2010/1/24, Karol Będkowski <email address hidden>:
>> Hi,
>> Please take a look on attached patch.
>> I have added entry field to filter plugins list. Simple but helpful.
>>
>> Regards,
>> Karol
>>
>
> Hey, very nice!
>
> I think we should use Kupfer's string ranker though, it would be the
> least surprising to the users (For example that "ntes" matches
> "Notes").
>
> The function is kupfer.core.relevance.score(s, query).
>
> It's slightly more tricky -- do we want to keep the list of matches
> sorted or not? For a simple filter it might make sense, you have the
> matches all laid out. Also we either use a relevancy ">0" criteria
> or a cutoff such as relevancy > 0.1.
>
> It would also be nice if the left hand side switches to the top
> plugin. It shouldn't flicker and update for every keystroke, but
> gently switching to the first in the list would be fine (a
> scheduler.Timer repeatedly set everytime we filter the list would do
> fine I think).
>
> Ulrik
>

2010/1/24, Ulrik Sverdrup <email address hidden>:
> And when I say left I sometimes mean right. I must have some brain defect.
>
> 2010/1/24, Ulrik Sverdrup <email address hidden>:
>> 2010/1/24, Karol Będkowski <email address hidden>:
>>> Hi,
>>> Please take a look on attached patch.
>>> I have added entry field to filter plugins list. Simple but helpful.
>>>
>>> Regards,
>>> Karol
>>>
>>
>> Hey, very nice!
>>
>> I think we should use Kupfer's string ranker though, it would be the
>> least surprising to the users (For example that "ntes" matches
>> "Notes").
>>
>> The function is kupfer.core.relevance.score(s, query).
>>
>> It's slightly more tricky -- do we want to keep the list of matches
>> sorted or not? For a simple filter it might make sense, you have the
>> matches all laid out. Also we either use a relevancy ">0" criteria
>> or a cutoff such as relevancy > 0.1.
>>
>> It would also be nice if the left hand side switches to the top
>> plugin. It shouldn't flicker and update for every keystroke, but
>> gently switching to the first in the list would be fine (a
>> scheduler.Timer repeatedly set everytime we filter the list would do
>> fine I think).
>>
>> Ulrik
>>
>

Hi, Here is the timer stuff. You might as well include this directly
in your patch

ulrik

Patch for filter using relevance.score attached

Karol

2010/1/24, Karol Będkowski <email address hidden>:
> Patch for filter using relevance.score attached
>
> Karol
>
> ** Attachment added:
> "0001-ui.preferences-using-relevance.score-to-filter-plugi.patch"

Thanks.

All strings returned from PyGTK are always `str` that are
UTF-8-encoded. Kupfer tries to always work with unicode internally. As
you can see, relevance.score raises an exception if one of the
arguments is a `str' and one is a `unicode'; we must pass both
unicode. (Due to Python 2.x's failings, you only get the exception if
you actually use some non-ascii character!) The plugin names and
descriptions are always unicode.

This is actually subtly wrong:
name_filter = self.entry_plugins_filter.get_text().lower()

.lower() only works correctly on unicode objects!

We can be overly clear with this:

s_name_filter = self.entry_plugins_filter.get_text()
us_name_filter = kupferstring.tounicode(s_name_filter).lower()

How nice it would be if we had a consistent style like this in all of
Kupfer, to keep track of the str/unicode problem. (s for byte string /
us for unicode string).

Also, the first argument to relevance.score doesn't need .lower(),
this is done automatically. The query string does though (this is
documented in the docstring).

I might have been wrong about the scoring: being so generous with
description ranking is confusing actually. The first ranking was
really good.. a relevance 0f >= 0.90 is equivalent to the substring
testing; we could use score > 0 for name and > 0.9 for description?
What do you think? I'm making it too complicated?

Please combine everything into one patch.

Ulrik

I have fixed problem with encoding. Also I have added score limit to description.
All in one patch attached, also on my "preferences-plugin_filter" branch on github.

Karol

2010/1/24, Karol Będkowski <email address hidden>:
> I have fixed problem with encoding. Also I have added score limit to
> description.
> All in one patch attached, also on my "preferences-plugin_filter" branch on
> github.
>
> Karol
>
> ** Attachment added: "bug509389_filter_plugins.patch"
> http://launchpadlibrarian.net/38329485/bug509389_filter_plugins.patch
>
> ** Changed in: kupfer
> Status: Confirmed => In Progress

I have pushed a commit to master constructed out of patches. I changed
to use the s_ and us_ syntax (just to try it), and moved the .lower()
from the catalog string to the filter/query string. I also added
matching against the "folded" version of the name (folded = removal of
composed characters) so that we match dokumentow to dokumentów, but no
such matching is done for description ATM.

Thank you!
Hopefully this is going to work out fine without bugs

It seems that it's works ok
Thanks

Karol

While the filtering is nice, this bug is not fixed yet: there are no categories and the other aspects (groups, activate by groups, tags) have not been addressed yet.

Hi,
Another patch - I have added support for plugin categories. Now in preferences plugins are organized into tree.
Of course - categories and plugins assignment are proposition.

Branch: http://github.com/KarolBedkowski/kupfer-adds/tree/ui_preferences_groups-wip

Karol

Hi,

I would prefer a design discussion about this first. I'll add my idea of how it could be done.

Each plugin can belong to one or more categories. I think Categories is a fine name for it, but the implementation is more like tags.

Each plugin has a Categories: line in the plugin information. The categories the plugin belongs to are listed separated by commas. Each category is styled as a hyperlink; if you click on the link, the plugin list changes to show only plugins from that category (the filter field might change to 'tag:Categoryname').

A plugin has multiple category assignations so that we can cover desktops (GNOME/XFCE/etc) and functionality (Communication, File Management, Base Functionality) (for example). Categories are not a total description (i.e. each plugin has only a few categories).

If a plugin doesn't have a category, it is in the 'Application Specific' category (for example Virtualbox plugin or Truecrypt).

Category names are localized so they must be unique and plugins should not invent new.

I don't have so many patch comments at this point. "dunder" names such as __plugin_category__ are reserved by Python -- which means that we should perhaps not use any at all, but instead we only use dunder names that are established (__author__) or begin with kupfer (__kupfer_name__)

Ok, I've updated my changes.
I have added:
- support for many categories
- showing categories in plugin information panel with ability to click on it and show plugins with this tags

First category is "main" plugin category, which is used to organize plugins list into 2-level tree.

Take a look.

Regards,
Karol

2010/2/1, Karol Będkowski <email address hidden>:
> Ok, I've updated my changes.
> I have added:
> - support for many categories
> - showing categories in plugin information panel with ability to click on it
> and show plugins with this tags
>
> First category is "main" plugin category, which is used to organize
> plugins list into 2-level tree.
>
> Take a look.
>
> Regards,
> Karol

Hi,

I have looked at it. It seems nice enough using the links but I wonder
if we can make the links normal links inside texts instead of using
buttons. That's a small thing though. Also, the text field could have
an erase button in it (that's a GTK 2.16 feature I think, but I don't
mind bumping the requirement for next version(?))

I wanted to discuss how this feature could be implemented -- but I'll
take your proposal as a suggestion and comment on it.

What do you think about using the text "Category:" for the plugin
information field? It's a bit reversed now since it uses "category"
terminology in the code but says "Tags" in the interface, which is
sort of the opposite of what I meant.

Also, do we want to have collapsable categories? I don't see it as
giving more overview or easier to find plugins.

+ if isinstance(categories, list):
+ # first category is main plugin category
+ main_category = categories[0]
+ else:
+ main_category = categories
+ categories = [categories]

Kupfer does a lot of isinstance sins but this is not the place. I
think that for this feature we should simply require the attribute to
be an iterable (tuple). But if we would allow both, we should check if
the attribute is iterable, not exactly list (especially since list is
very unnatural). Then if our code needs a list we make it a list.
That's the python way:

if hasattr(C, "__iter__"):
  categories = list(C)
else:
  categories = [C]
main_category = categories[0]

strings don't have an '__iter__' method so the code above is the
common way to do this.

Next try....
+ "clear" icon in filter entry
* LinkButton replaced by Label with "<a href" markup
* fix code style
+ new categories (proposition)
+ assign plugins into categories (proposition)

Karol

2010/2/1, Karol Będkowski <email address hidden>:
> Next try....
> + "clear" icon in filter entry
> * LinkButton replaced by Label with "<a href" markup
> * fix code style
> + new categories (proposition)
> + assign plugins into categories (proposition)
>
> Karol

Hi, your changes look great so far -- including the categories as
links. However you have to understand that I wanted to discuss this
before its implemented so that we know what we want. Just because this
bug says plugins should be grouped by categories doesn't mean that
they should -- we seem to agree that plugins should have categories
but not so much more. So I'd like to know what we want to do with the
user interface.

Categorisation is good in many places IMO but I think it is already
too detailed. Again, if we know what we want to do and *how* we want
to help the user, it's going to be much easier to know how to do this
right.

Ulrik

ok,
Please treat my changes only as my proposal.
I agree - too many or too detailed tags are only confusing.
Grouping plugins into one-level tree is IMHO best solution.

Karol

2010/2/2 Karol Będkowski <email address hidden>:
> Grouping plugins into one-level tree is IMHO best solution.

Why do you think we need a tree? The obvious structure even gets lost
since some plugins may have multiple categories and not all categories
might show up as a collapsable group in the list, so the UI is very
inconsistent.