[haiku-development] Re: TrackerGrep [was Re: missing -lm?]
- From: "Jonas Sundström" <jonas@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 04 May 2008 01:56:08 +0200 CEST
"Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> wrote:
> Hi Jonas,
Hi,
...
> Anyway, I don't think that adding the history
> to the menu is a good idea, because it doesn't
> fit that well there
I agree that one might want to keep menus for
pure actions, and have preference items and
things like grep history separate from the menu.
The menu is often abused but few seems to mind.
...
> it doesn't remember its history,
I think the previous versions use a separate
file for the history, TrackerGrepHistory,
so moving from old TG to new TG you start out
with an empty history.
Additionally, new TG's history gets wiped by the
old TG, if you switch between them, as new TG
stores its history in the primary settings file,
TrackerGrepSettings.
Hindsight, one might have wanted to keep using
TrackerGrepHistory. I found it wasteful to have
two separate files. Oh well.
...
> > I admitt a few of the menu item names and shortcuts
> > could be improved. (Alt-F vs Alt-O, etc)
> >
> > I've found the "Trim to Selection" feature the most
> > useful of my changes. It limits the next search to
> > current hits, or selection thereof. Speeds up things
> > considerably. Command-N isn't bad either.
>
> I obviously haven't used them, but since it is usually
> always used with a directory originating from Tracker,
> I don't think that Command-N will get much use,
Sometimes I want to search for something else in the same
place, right away, without closing the current results.
Alt-N opens a new window on the same set of files.
...
> I don't see the need for "Trim to Selection" either,
> as it doesn't make any sense to me to manually filter
> out results that I already see in front of me.
It's primarily meant to filter out all the things
you -don't- see, all the files that didn't match.
If you start out searching, say the Haiku source,
and get 50 hits, you can trim the selection to all
(or some) of those 50 files, so you can refine your
search, without having to search those hundreds of
thousands of files -again-.
> > I don't agree with the notion that a Tracker add-on
> > has to be small or simple. They're just a way to
> > launch an app/utility on/with a set of files. (Not
> > all that different from how applications and
> > documents often find each other.*)
>
> But then you could use "Open" or "Open With" instead.
> An add-on should
> be an extension of the original application, IMO.
Tracker add-ons are rarely extensions of Tracker.
They're just utilities, which to me, are single-
purpose applications. Unless Tracker add-ons need
access to Tracker internals, there is no need to
load them in Tracker's memory.
I don't see why applications and Tracker add-ons
have to be so separate. There's already similar
filtering on supported types, via both mechanisms.
There's already convergence.
Adding shortcuts for launching a preset application
on a selection of files should not be hard to implement,
or to present in the "Open With..." menu. (It wouldn't
be much different from how in regular menu bars, some
items have shortcuts and others don't, except you can
change which ones do.)
> > If you prefer Tracker Grep to be a shallow front-end,
> > then we have different creative vision for it.
> > I don't mind stepping aside though, honestly.
>
> Well, just don't step aside because of me :-)
Nah, it's not you. No worries. :)
I'm just tired.
> But in any case, I don't see any added value in
> making TrackerGrep a standalone application
Alt-Q works! ;)
> - IMO that's not really how you would ever use
> it; it creates an alternative usage pattern that
> is not as useful or powerful as the original one.
It doesn't take away the original usage pattern though.
> > *(IMO every BApplication should be possible to set
> > up with a shortcut in Tracker, replacing Tracker's
> > "Add-Ons" menu with user-configurable shortcuts in
> > the "Open with..." menu.)
>
> I like usage oriented better than program oriented, ie.
> I would like to have a shortcut to edit a file instead
> of just view it (or vice versa),
But that's a different thing! Currently we only have
B_OPEN and Alt-O. I suppose one might want to reserve,
say, Ctrl-Alt-V (View), Ctrl-Alt-E (Edit), Ctrl-Alt-P
(Print), etc, and have a preferred appliction per
mode and filetype.
Or perhaps a complete overhaul in R2.
/Jonas.
Other related posts: