Re: [Patch] apps-menu filtering

Matthew <matth love gmail com> writes:
> On 8/31/2010 2:30 PM, Jeremy Hankins wrote:

>> I was hoping to be able to play with the categories, but this doesn't
>> work:
>> (setq apps-menu-filter
>>        (lambda (ent)
>>          (when ent
>>            (let ((cat (cdr (assoc "Categories" ent))))
>>              (if (string-match "Utility" cat)
>>                  (rplacd (assoc "Categories" ent) "utility")))
>>            ent)))
>> Rather than renaming the "Utility" category, this seems to dump
>> everything in the "Utility" category into limbo -- i.e., those items no
>> longer show up in the menu.  Looking closer at apps-menu.jl you're
>> apparently doing some complicated stuff with categories, so this is
>> probably the wrong way to go about changing a category name.  But
>> dropping the entries is probably not the right thing to do.
> Ah, I misunderstood what you were requesting.  This will not change
> the category name as it is shown in the apps-menu, but change the
> category of given .desktop entries, I'll see what i can do to make the
> category functions more accessible and easier to manipulate.

It's not a big deal that I be able to rename categories -- though it'd
be handy for me since I use the keyboard to navigate them.  But there
should probably be a check for renamed categories (e.g., to exile them)
or a big warning in the docs.

>> In addition to moving emacs to the "System" category I noticed that
>> "File Browser" (i.e., nautilus-browser) shows up there as well.  Without
>> the above snippet it doesn't show up at all -- confirmed by searching
>> the contents of apps-menu.  I don't know why -- there's no "Emacs" in
>> the desktop file for nautilus-browser at all.  If I have a chance over
>> the next few days I'll see if I can trouble-shoot more on this one.
> This likely occured because when you set apps-menu-filter it no longer
> would filter out things like OnlyShowIn, which is probably why
> nautilus-browser showed up all of a sudden when you set the
> apps-menu-filter.

Ah, of course.  That works much better.  ;)

> to use the default filters along with your in a lambda, do something like:
> (setq apps-menu-filter
>        (lambda (ent)
>          (when ent
>            (let ((name (cdr (assoc "Name" ent))))
>              (if (string-match "Emacs" name)
>                  (rplacd (assoc "Categories" ent) "System")))
>            (fdo-hidden-filter (fdo-nodisplay-filter
> (fdo-onlyshowin-filter (fdo-notshowin-filter ent)))))))
> Perhaps there is a better way to go about using the default filters
> when one defines their own...

Here's how I'd do it, just to avoid doing an extra string-match on
entries that aren't going to be shown anyway:

(setq apps-menu-filter
      (lambda (ent)
        (let ((ent (fdo-hidden-filter
                      (fdo-notshowin-filter ent))))))
          (when ent
            (if (string-match "Emacs" (cdr (assoc "Name" ent)))
                (rplacd (assoc "Categories" ent) "System")))

It might be nice if there were an fdo-std-filter or something that did
all four filters, just for ease-of-use and readability.  That would
eliminate three lines from the above, and would mean that if we change
the standard filters user code could automatically get the benefit of
the changes.

>> I have to admit, I don't really understand what all is going on with the
>> categories.  Desktop entries list several categories, not just one.
>> `determine-desktop-category' seems to arbitrarily choose only one -- if
>> there's no reason to choose one rather than another why not use them
>> all?  It seems reasonable for, e.g., emacs to show up under both
>> development and office.  Then the fix-cats and fix-sub-cats are (if I
>> understand them right, and I'm not sure I do) consolidating the category
>> structure according to desktop-cat-alist.  Is that right?
> Yes, that is basically right.  The choosing of categories is that it
> will basically choose the first category it finds that is not
> something like 'Application or 'KDE.  So it could definitely do this
> better, and one of updates i'd like to make, per Chris' suggestion, is
> to add support for sub-menus, which would then be more suited to take
> advantage of the multiple categories in each entry.  And it would be
> nice to be able to simply re-name menu-categories as well....

Ah.  The category reorg could be done as a filter, I'd imagine.  Not
sure if that's a good idea, though.

> It could also easily use all the categories specified, making multiple
> entries per application, if this is something people would like it
> should be pretty easy to change things in this way.

That would make sense to me, anyway.  Otherwise we find ourselves having
to decide which of the categories the app provides is the "proper"

Jeremy Hankins <nowan nowan org>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]