Re: [Gimp-developer] Search Action dialog feature

[Jehan Pagès <jehan marmottard gmail com>]

Hi,

On Tue, Jan 28, 2014 at 10:23 AM, peter sikking <peter mmiworks net> wrote:
> (first of all I think all blur examples have to be banned. there
> is nothing to search about blur, it is under Filters->blur, end
> of story. if it is not clear that it is to be found in the Filters
> menu, or as a toolbox tool, then this user needs an introductory
> course in GIMP, which can (today) only be delivered by a web browser
> or a book.)

I completely disagree. You may know where it is but still prefer to
get it through the search. This is like 10 times faster and easier.
Seriously this search dialog would be already in GIMP master, I would
use it for most of the features actually. This makes things so much
easier and the use of GIMP so fluider.

Same as my program application list. I know where most of the apps I
installed are, but I nearly never use the menus anymore. I use the
search atop the menu. Why would I bother searching through menus and
submenus when by typing 2, 3 or 4 keys (in natural language of what I
search, not shortcuts, nothing to memorize) at most I get the app I
need?

Apparently also same as GNOME shell (never used, but dixit Mitch in
another email). Same as what Windows does now too (also never used
this, but someone said in another email too), same as Blender.
That's just too useful. *Even for experts*. Even when you know exactly
where each item is.

> anyway, GIMP is a designed to be a tool for masters, or for
> users on their path to become a master (beginners, intermediates).
> any other use is not considered when designing the UI.
>
> so if someone comes to GIMP (s)he is either a master in another
> graphics app, or not. in the latter case (s)he can be considered
> and helped, as a beginner or intermediate GIMP user.
>
> from this there are 2 conclusions:
>
> - we really need to talk about how you envision TITo being useful for
>  GIMP masters, beginners and intermediates; most of this will
>  involve learning to use GIMP;
> - that leaves only masters of other programs coming to GIMP to
>  consider in this discussion.
>
> since they are masters in another programme the will hate not
> being all-powerful in GIMP. so they will want to master GIMP
> as fast as they can (think of it as grokking).
>
> - for all the terms that GIMP has in common with other graphics
>  programs (blur, dodge, fill, paint) the value of searching
>  for them will be nearly zero, they are placed where they belong.

As explained above, I *completely* disagree.

> - the terms that GIMP does not have in common with all other
>  graphics programs need a synonym list, a mapping between the
>  non-GIMP terms in other programs to the GIMP term;

I agree, this would be a very nice thing. And that's what Srihari said
was one of his original plans.

Now this is a huge work. Someone would work full-time on it, yeah it
could take only a few days to have a demo version, but then weeks to
have a *real* stable bug-less version for quality testing and release.

Such a feature implies gathering the data (list of words to get
synonyms for, then list of synonyms in every languages). And
development-wise, to do this feature really well (and not half-baked),
we would have to do at the very minimum tokenization and lexemization,
which implies at least some basic lexical analyzis, which is
language-dependant.

The only word processing I do right now (already implemented) is basic
word-tokenization, which implies that "gaussian blur" as well as "blur
gaussian" would both return gaussian blur, but also that spaces are
irrelevant to a search. But even this current implementation is basic
and would work well mostly for languages where space characters are
token separators (tokenization for non-spaced languages like Japanese
or Chinese are a lot more complicated, and involve machine training;
and not to mention languages which are only partially agglutinative,
like German, which make them also quite particular to tokenize).

But well we don't have full-time developers, and there is also the
priority problem (that's nice, but it may be better to have other
things worked on, no?). Is it really worth to work for weeks on this
when we already have something still quite good?

Moreover I would recommend third-party language analysis dependencies
(libraries) for some parts of the text analysis, rather than
developing all ourselves, and a bunch of text data to embed in our
software. I'm not sure that's ideal.

And honestly, I would love to work on this all, advanced language
processing and all. These kind of things have been my university major
(Artificial Intelligence, Intelligent Multimedia, etc.), also I love
linguistics, I have done any of these things at least once in my life,
and I have worked on these topics in a startup which was working on
translation. I would really enjoy to do it again. But I am also
realistic and I don't think this is prioritary for GIMP and that we
should waste weeks on being as performant as Google (which reached
this quality with thousands of developers over many years) rather than
working on more urgent bugs and features. If this were a
language-related software, well that's a must-have. For a graphics
software though, that's still an awesome plus, but a basic search is
already extremely practical as it is.

Plus, I don't have that much time right now unfortunately.

> - if the search does not give a match to the non-GIMP term
>  this master user entered, this user will be angry within seconds
>  (‘useless!’)

Well I think you should give a little credit to users. There are
always angry users, and there always will. Even with very very good
tools, some users still find ways to complain. But a lot of other
users still prefer to have "just good" tools rather than no tool at
all because developers would be waiting for perfection before release.

> - a lot of these operations are not one-shot, they either fit in
>  a GIMP way of doing things or have their own set of parameters;

Well if you mean that a dialog should open, of course. We don't
one-shot the finale filtering or tools, or anything. When we call it,
then it would open the appropriate dialog (same as when you open a
filter with the menu, it does not "run" the filter on your image, it
opens the dialog for entering the parameters for the filter).
Once again, I would suggest you to try the current implementation.

>  to grok this, invoking it or pointing out where it lives in the
>  UI is not enough; it needs a short, sharp manual page;

Yes improving by adding a link to the manual, as proposed by Mitch
earlier, would be a nice addition too.

> - to summarise the above, TITo has to be competitive with
>  googling "GIMP <user’s search term>"

But that's exactly it! It is a search tool. It allows to search
through everything that the user is able to do (= the developers gave
an "action" name to a specific feature) and will do it better than
searching with Google Search or any other web search engine for that
matter.

Of course, let's be honest, as I said above, we won't be as good as
google would be for text processing, for at least one reason: we don't
have thousands of developers. Google Search does advanced language
processing. They do switch words with synonyms, as you proposed. So
maybe if a user were to tape "undulation", Google might return "wave"
filters. Also Google Search can process plural, fix typing mistakes,
and so on. They can afford it: they are a billion-dollar company with
probably more development time now in a single day that we have had in
the whole GIMP history.

But still, we will be competitive to this, because this search tool
will be embedded in GIMP, it will only search the right things. So it
will be faster (it is nearly instant even, once again, try the current
implementation: you type, it appears on the fly), and more pertinent
(not mixed with non-GIMP related links), and easier (you search, you
find, you run, done. You don't have to get out of GIMP, go in your
browser, open a search page, etc).

So our search algorithm can't be as performant as Google Search. But
since we are dedicated to working on GIMP only, it'll still be more
pertinent and useful than Google.

Honestly you should try the tool in its current state. It isn't bad at
all. It is even pretty good. We can still improve it progressively. I
don't see why we should have an advanced search from the start. Damn,
even Google did it progressively! The initial Google search engine was
probably as simple as what we have (simply on more data).
With our number of developers (none are "employed"), if we want
something as complex as what you seem to want, we would not see this
feature before 5 years, which probably means never because everyone
would have abandonned before it happens.

I really don't see the point of blocking the tool inclusion in its
current state. I don't see how bad it is to improve it progressively.
This is done all the time, and in the Free Software world in
particular because dedicated developers are rare (but even in the
commercial world anyway!).

Jehan

> ...or else be ‘useless!’
>
>     --ps
>
>         founder + principal interaction architect
>             man + machine interface works
>
>         http://blog.mmiworks.net: on interaction architecture