Re: [Gimp-developer] Search Action dialog feature
Hi all, (evil top quoting because I don't really know where to start replying) I really don't know where the problem is here. Peter, when we spoke in Berlin last time we discussed tito aka menu search, the outcome was: - it's not even visible by default - it has a shortcut that pops up a simple search entry - as you enter text, you essentially search all the text associated with menu items and their actions - you select an item, done It was pretty much our agreement that it's an unobtrusive additional way to find stuff in our huge menu forest, for people who have a text based memory rather than one that easily remembers menu locations. It's also good for people who prefer to use the keyboard instead of a menu. There are simply not enough shortcuts, let alone mental capacity to remember potential shortcuts for all menu items. It's basically what gnome shell does: enter activity mode, enter some text, press return, done. Now this is exactly what the current state of the implementation already is (alomst), it just needs a little fine tuning. Sorry but I'm really confused. Regards, --Mitch On Mon, 2014-01-27 at 22:23 +0100, peter sikking wrote: Jehan, please read again what I wrote: let me first of all say this in general about the process we are doing. at this moment I feel we are still working backwards, i.e. you are answering to me what the code does. we have to work forward, else there will be no progress. this means we write down the goal/purpose/vision that you have for TITo (sorry, internal code name still rocks for discussions). you make the choices, I just make sure that what we end up with 1) makes sense in GIMP context 2) is internally consistent 3) is short, sharp and complete once we got this goal written down, it is possible to review the spec to see what is missing and what is getting in the way of the goal. now it would be good if we actually start doing that. On Tue, Jan 21, 2014 at 12:47 PM, Michael Natterer mi...@gimp.org wrote: action is meant as technical term here. A menu item is a view on an internal action, and they include: - all menu items - all tools - all menu-invokable dialogs - some esoteric stuff which we'd probably filter out to avoid confusion Indeed. if I read that right it still boils down to that you only want to search menu items. this needs to be called that way for clarification. No. As said above, actions are *not* just menu items. There are a wide list of commands that Mitch listed above. aha, that was completely not clear. now if I am wrong, and you do want to be able to search more like am the ‘actions’ in the dockable dialogs (example: Brushes dialog-Create a new brush) then you need to make that clear explicitly. Well, yes. We made it clear by saying we search all actions. :-) actions are a means to an end. we are in the process of clarifying the ‘end’ here, not the means (picking the means comes later). so now we better get busy. the word ‘actions’ is now loaded as an internal implementation detail. to avoid confusion, it cannot be used in a goal definition. you could take the wide-ranging option and say: ‘search all that users can perform and change in GIMP’ or get specific and make a complete list (‘types’, not ‘instances’) of what you want to be searched by TITo, for instance: - all menu items - everything that can be performed in dockable dialogs - all tool options - all operations tools can perform on the canvas - all settings in preferences and co. it needs to be in language that gets the point across exactly, without the reader being required to be a GIMP developer. it is better now to concentrate on _all_ the reasons you want this to be useful for GIMP users. now is the time for you to decide whether ‘when one knows they exist but can't find anymore’ is the one and only reason TITo is valuable/useful for GIMP users. if there is more, you have to clarify that mow. No it is not the only reason. This was more an example, thus an error on my side to cite here. The real goal is «searching and running» actions. And this by itself contains all the reasons I think it is useful for. Now searching can imply a lot of sub-reasons. yes, and we need to get these reasons on the table, because without them there is no point in introducing the tool (and certainly not claim a keyboard shortcut). The «I know this action exists (because I used it before, for instance) and I want to find it again» would indeed be a typical one. and here is where some QA form my side has to start: Another would be «I don't know GIMP by heart, but I know graphics editing, and there are usually blur effects. So instead of going through endless menus, I open the search and type blur and search through the 3/4 results I get». (first of all I think all blur examples have to be banned. there is
Re: [Gimp-developer] Google Summer of Code 2014
On Tue, Jan 28, 2014 at 12:44 AM, scl wrote: 1) Do we want to participate this year, again? Yes. 2) If yes, which programming tasks do we want to offer? In my opinion, we should stick with the GEGL/OpenCL ports and integration of the results of former GSoC projects. Yes for the former, no for the latter. Hiring a new student to complete the work of another one would be a horrible PR move. It means we failed to do our job in the first place. Yes, it might sound boring, but on the other hand the GEGL and OpenCL ports have been our high priority for many years and there's still something to do, see the [GEGL Porting Matrix]. Both GEGL ports _and_ speeding up GEGL has to be done, but I'm not sure if the latter is GSoC material. We also have tons of usability issues, such as: - with the existing Text tool implementation, you can't select font in the on-canvas toolbar and start typing with it; - with transformation tools, the layer you are transforming blocks the view of layers beneath it, so you end up guessing what you are actually doing; - when you change brush size/rotation with a slider using a Wacom pen or a mouse pointer, you can't preview the changes; - the whole floating selection thing. A project that would focus on fixing usability issues could make a nice GSoC project. It would mean a lot for the community, especially for the most vocal part of it :) Of course, it only makes sense, if Peter can/wants to join us for the summer. Building and prioritizing a list of most notorious usability issues that could be fixed as part of a GSoC project is perfectly doable. Personally, I think that GIMP GAP is in need of help. Animation is a rather popular topic among GIMP users, but GAP's UI scares the living daylight out of people (me included) and being implemented as a set of plugins doesn't really help there. I don't think I've seen a well formulated opinion on GAP becoming part of GIMP (last time I asked, some developers were against, others were indifferent), but some streamlining of user experience regarding basic animation could be both useful and GSoC material. Of course, that's just my personal opinion, and besides, upcoming frame-by frame animation in Synfig could render the whole idea obsolete. 4) What can we learn from the former GSoCs: what have we done well, Historically, students who performed best were the ones who joined early to study the code and maybe send a couple of patches, sticked around on IRC and were generally open about their work. They were also the students who came up with an idea of their own or even had done some prior work (last year's N-Point deformation tool is one such example). what could be improved? Off top of my head: 1) Even more explicitly encourage original thinking and genuine interest in a proposed project. Implementing something that stems from a cool SIGGRAPH paper is good, competing against 5 other students for a slot that isn't even all that critical for GIMP -- not so much :) 2) Make 100% sure that students are familiar with the code. Inkscape has a two-patches rule to even start considering a submitted application. We didn't want to do that before, but we did have disappearing students in the past. Something to think of, IMO. 3) Demand public weekly reports on progress, sent to gimp-developer@/gegl-developer@, no excuses. 4) Only allow UI-related projects if we have a usability person to design new interaction/UIs. Last year's selection tools project is why we need that. Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
Mitch wrote: I really don't know where the problem is here. now that I was asked to get involved, read the spec and made an analysis, here is what the problem is: TITo, as it stands today, is a UI subsystem for which it was never decided whether it was a search/help system or a command interpreter. trying to be both, it is simply substandard at either tasks. (yes, there is a hard trade-off between the two: a search/help system must be compassionate and forgiving, mapping a large set of search terms to a range of answers. a command interpreter has a tight, _designed_ command set whose only goal is to get users as fast a possible to one unique command to invoke.) since it is a 100% UI subsystem and I am involved anyway, I realised that the only thing I can do is to help the makers step by step to get TITo into a shape that makes sense to release. (OK, the other thing that I can do is to refuse that this goes into GIMP, but that is not constructive). we are at step one which is simple and hard at the same time: define what TITo is and why it makes sense in a GIMP context. already a couple of surprises came out of the woodwork, information that was not available to me before. for the rest it is slow going, ‘why does it make sense in GIMP?’ seem to be a fresh question, where the answers still need to be found. up to now various people have offered a lot of tautologies, and the fact that it has been implemented in completely other contexts. that is not convincing at all. also that answers from everyone have a different view on whether it is a search/help system or a command interpreter. this reflects exactly the jumbled state TITo is in. --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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
On Tue, Jan 28, 2014 at 4:47 PM, peter sikking wrote: TITo, as it stands today, is a UI subsystem for which it was never decided whether it was a search/help system or a command interpreter. trying to be both, it is simply substandard at either tasks. (yes, there is a hard trade-off between the two: a search/help system must be compassionate and forgiving, mapping a large set of search terms to a range of answers. a command interpreter has a tight, _designed_ command set whose only goal is to get users as fast a possible to one unique command to invoke.) This actually makes sense. If [whatever you want to name it] is supposed to be an even simple search system, it needs to support morphology in every locale we ship GIMP with. While it's possible to use e.g. hunspell for morphological analysis and stemming, and its coverage of languages seems OK, it very well could be an overkill. If it is supposed to be a _state of the art_ search system, it needs to go beyond morphology all the way to understanding user's intent, which is where lists of synonyms become a requirement. A choice of words heavily depends on user's background. E.g. younger and less experienced users don't get the way all crop-related functions in GIMP are translated into Russian, because typically they are not familiar with photography terminology and expect simpler words. Alexandre ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Any way to convince Gimp installed in a prefix to only use the plugins in the prefix?
Recently I tried to update Gimp from git, which I've done quite a few times before without any problems. This time several things went wrong, the main symptom being that Gimp couldn't open a png file. I asked about the problem on IRC and several people came up with possible sources of the problem. Actually all the suggestions were correct! as there was more than one problem going on. The most difficult issue to track down was related to libpng. I had recently updated Gentoo, which updated libpng. The updated Gimp was compiled using the new libpng. But when I tried to run Gimp, it used plugins from a previous installation (this is what took a long time to figure out), and of course those plugins were compiled using the old libpng library. Tracking down exactly what was happening was not easy because I didn't realize that plugins were installed not only in the prefix but also in hidden home config folders. Eventually I found and deleted the hidden home config folders and got Gimp in the first prefix properly installed, which created new hidden home config folders. Then I installed Gimp in a second prefix, and modified one of the plugins in the second prefix. But Gimp in the second prefix didn't see the modified plugin because it too was looking in the hidden home config folder, which it very politely didn't overwrite during the installation process. I found the Preferences dialog for setting where to look for the various brushes, plugins, etc. That's a lot of folders to reset/reorder one by one! as the default order of where to look puts the hidden home config folder first. So that is why I asked about convincing Gimp in a prefix to only use plugins installed in the prefix. Now that Mitch has fixed the absolute/relative path problem when using the configure option --with-gimpdir=, each Gimp is only looking for plugins and etc in the specified folder inside the prefix. So that problem is solved, hopefully! On 01/26/2014 03:15 PM, Michael Schumacher wrote: Am 24.01.2014 20:58, schrieb Elle Stone: I usually have three or four separate installations of Gimp from git, each in its own prefix. Is there a way to tell Gimp in a prefix to only use the plugins in its own prefix, other than resetting the folder preferences every time I want to switch prefixes? You could set the environment variable GIMP2_DIRECTORY to a different personal directory altogether, or set GIMP2_PLUGINDIR to point to a different plug-in location - see http://www.gimp.org/man/gimp.html#sect4 for more information about these variables. The info on the page you reference is very interesting and I'm really hoping that the configure option --with-gimpdir= sets all of these folders to only look in the prefix-specific directory: GIMP2_DIRECTORY to get the name of the personal GIMP directory. If unset .gimp-2.6 is used. If this is an absolute path, it is used as is. If it is a relative path, it is taken to be a subdirectory of the home directory. GIMP2_DATADIR to get the base location for data files such as brushes and patterns. If unset /usr/share/gimp/2.0 is used. GIMP2_LOCALEDIR to get the base location for translations. If unset /usr/share/locale is used. GIMP2_PLUGINDIR to get the base location for plug-ins and modules. If unset /usr/lib64/gimp/2.0 is used. GIMP2_SYSCONFDIR to get the location of configuration files. If unset /etc/gimp/2.0 is used. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Any way to convince Gimp installed in a prefix to only use the plugins in the prefix?
On Tue, 2014-01-28 at 09:59 -0500, Elle Stone wrote: The info on the page you reference is very interesting and I'm really hoping that the configure option --with-gimpdir= sets all of these folders to only look in the prefix-specific directory: The --with-gimpdir configure option *only* changes your personal gimp directory, the remaining directories are relative to --prefix and work perfectly fine since forever. GIMP2_DIRECTORY to get the name of the personal GIMP directory. If unset .gimp-2.6 is used. If this is an absolute path, it is used as is. If it is a relative path, it is taken to be a subdirectory of the home directory. GIMP2_DATADIR to get the base location for data files such as brushes and patterns. If unset /usr/share/gimp/2.0 is used. GIMP2_LOCALEDIR to get the base location for translations. If unset /usr/share/locale is used. GIMP2_PLUGINDIR to get the base location for plug-ins and modules. If unset /usr/lib64/gimp/2.0 is used. GIMP2_SYSCONFDIR to get the location of configuration files. If unset /etc/gimp/2.0 is used. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] Search Action dialog feature
Hi, On Tue, Jan 28, 2014 at 10:23 AM, peter sikking pe...@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
Re: [Gimp-developer] Search Action dialog feature
On Mon, Jan 27, 2014 at 3:23 PM, peter sikking pe...@mmiworks.net wrote: TITo has to be competitive with googling GIMP user’s search term ...or else be ‘useless!’ That's a rather remarkable statement ;) Try replacing any instance of blur in the discussion so far with Wavelet Decompose. Oh, but you say 'Wait, that filter doesn't come with GIMP' and you are right. I find it useful enough to install, yet don't use it often enough to always find it under 'Filters-Generic' on the first try. I bet I could type 'wav' and it would head the list (if not, 'wavel' should bring it to #1). Consider the many other 3rd-party plug-ins. Ubuntu ships a collection of ~20 of them in one package - which makes them really easy to install, but if they end up in a funky menu (and some do), moving one of them means finding and downloading the plug-in separately, editing (and in some cases compiling), and installing it locally. And these are just a couple of examples. I know my way around graphics software, and yet I sometimes find myself hunting around for an obscure, hardly-used function that I *know* the name of and I *really need* right now, but has been organized by someone whose brain doesn't work the way mine does :/ Chris ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
