Hi, On Tue, Jan 28, 2014 at 10:23 AM, peter sikking <peter@xxxxxxxxxxxx> 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 > > > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
