Hello Jehan, Peter,

Have we had a chance to look into this? Just wanted to check in here in case I've missed discussions on IRC.

On Sat, Nov 30, 2013 at 11:06 AM, Jehan Pagès wrote:

Hello Peter,

Some time ago, a contributor developed a very interesting feature, allowing to search actions with natural language keywords (https://bugzilla.gnome.org/show_bug.cgi?id=708174).

For instance, if you want to search a "blur" filter to apply to your image, you could just type in "blur" and see a list of relevant actions: for instance you'll find in the list the "blur / sharpen" tool, but also the "Gaussian Blur", "Selective Gaussian Blur", "Tileable Blur", "Circular Motion Blur" filters, and even "Difference of Gaussians..." (because it does a difference of 2 gaussian blurs!).

No need to search in infinite menus and submenus. If you know a common natural language keyword, you can just search for it, which also makes it even easier for users of other software who don't know in which menu to look for which filter, but even for advanced GIMP users when they know a filter's name but don't remember where to find it. Such a search would be even localization-aware, since a French would search for "flou" and a German for "weichzeich" instead of "blur".

In summary, the user could open the action search dialog (default shortcut: '/') anytime, type a keyword, select the desired command in the list and run it.

The original proposition has been largely improved, and is now in the branch origin/tito on the GNOME git repository of GIMP. Since I know you have a working development installation now, that would be easy to check out, and test. Of course, if any question on how to do so, do not hesitate to ask.

I have also written an exhaustive specification draft of the current implementation:
http://wiki.gimp.org/index.php/Specs:Action_Search_Dialog

This specification details the search algorithm, and the GUI interaction.

We would appreciate a feedback from you, about this feature and the user interaction.
Thank you very much!

Jehan
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership:
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Regards,
Srihari Sriraman -- ⌀ -- nilenso.com

Srihari Sriraman wrote:

Have we had a chance to look into this?

On Sat, Nov 30, 2013 at 11:06 AM, Jehan Pags wrote: Hello Peter,

Some time ago, a contributor developed a very interesting feature, allowing to search actions with natural language keywords (https://bugzilla.gnome.org/show_bug.cgi?id=708174).

I have also written an exhaustive specification draft of the current implementation:
http://wiki.gimp.org/index.php/Specs:Action_Search_Dialog

This specification details the search algorithm, and the GUI interaction.

OK, I have looked at that spec.

then I thought about it for hours, and here is why:

this thing is still giving me a serious stomach ache

(I hope you guys realise that when something that is 100% UI gives me a stomach ache, that is quite significant)

even trying to explain to you (and me) why this gives me a stomach ache, gives me a stomach ache.

I could talk long or short about all its aspects, but I have decided to cut it short and tell you this about it: when I read the spec or think about TITo, this comes to my mind, second by second:

that is OKish, give these guys a break that is awful, completely misguided
that is OKish, give these guys a break that is awful, completely misguided
that is OKish, give these guys a break that is awful, completely misguided
that is OKish, give these guys a break that is awful, completely misguided

so after hours of thinking I have come to this conclusion:

the problem with TITo is that as it stands now it is a conflicted mix of two intentions:

1) a help system via text search to learn using GIMP

2) a command-line system for operating GIMP

some note:

- yes, for me 1) maps to give these guys a break and 2) to completely misguided sort term _and_ long term; - if you are serious about Text-based Intent driven Tool then you have to build a synonym list for all keywords, in all localisations; else you are just bluffing; - with different people working on it, I suspect they have different intentions, or are conflicted internally themselves; - since TITo is right now a random mix of 1) and 2), it is really not working for either intentions; things implemented for 1) get in the way of 2) (and vice versa);

when I had me face-to-face meeting with Mitch to patch things up we did talk about TITo (thats how big an issue it is...).

I said: when a version of GIMP comes out with TITo in it and the press writes about it:

GIMP now has a command-line system for operate it

then we have a all lost, big time, because a million users then expect that this will actually make sense (and btw: I lose the most, because this is a pure UI matter)

when the press writes:

GIMP now has a help system via text search to learn

then we have a chance that this will be useful for a good chunk of our users, some of the time.

all this is not about what we tell the press for that release, this is about what TITo _is_, what it is designed to be.

being a conflicted mix of two intentions is certainly not going to help TITo in any way.

some more things that are very important:

- even if TITo response time is instant, keyword formulation -> typing in a text based interface is not exactly fast; please drop the its fast argument; - I read in the bug report that peple are contemplating changing labels of menu items to help TITo to perform better; that is the most dangerous thing I have heard in a long while; - if anyone is serious about solving how to help serious GIMP users with faster use of plugins and other sprawling stuff, let me know; it can be designed...

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

On Tue, Jan 14, 2014 at 12:52 PM, peter sikking wrote:

- even if TITo response time is instant, keyword formulation -> typing in a text based interface is not exactly fast; please drop the ‘its fast’ argument;

And yet the desktop menu in Mint/Cinnamon does precisely this and it *is* fast. I type "Win-key,c,h,r,Enter" and have Chromium running. Easy. Faster than the menu navigation. I go without clicking an item in the system menu for weeks at a time, on a desktop I use daily.

Nor do I see adding a text-driven action/menu system as any sort of UI failure. or being in the least bit "misguided". What's inherently evil about adding shortcuts to get things done?

And if some labels aren't clear in TITo, might they need to be looked at anyway - maybe they really are ambiguous or could be worded better? The couple mentioned in the BZ report seemed a little funky.

(note: I haven't checkout out the TITo branch - only watched a couple of videos, went through the spec and the bug report.)

Chris

As Peter pointed out - what do you type in on Mint/Cinnamon if you happen to speak Chinese?

On 01/14/2014 01:43 PM, Chris Mohler wrote:

And yet the desktop menu in Mint/Cinnamon does precisely this and it *is* fast. I type "Win-key,c,h,r,Enter" and have Chromium running. Easy. Faster than the menu navigation. I go without clicking an item in the system menu for weeks at a time, on a desktop I use daily.

On Tue, Jan 14, 2014 at 4:48 PM, Burnie West wrote:

As Peter pointed out - what do you type in on Mint/Cinnamon if you happen to speak Chinese?

Either the same string, or a string that matches the translated portions of the menu entry (or its description).

Staying with the same example, then English menu entry is 'Chromium Web Browser'. When switching to Spanish or Chinese, the 'Chromium' remains the same while 'Web Browser' is translated. So in Chinese one can either enter 'chr' or a portion of the translated 'Web Browser' in Chinese. I'm assuming most if not all menu entries in GIMP are already translated - am I missing something?

(getting my dekstop back to English was a small adventure, not being able to speak Chinese even a little ;)

Chris

On Jan 14, 2014, at 22:43, Chris Mohler wrote:

On Tue, Jan 14, 2014 at 12:52 PM, peter sikking wrote:

- even if TITo response time is instant, keyword formulation -> typing in a text based interface is not exactly fast; please drop the its fast argument;

And yet the desktop menu in Mint/Cinnamon does precisely this and it *is* fast. I type "Win-key,c,h,r,Enter" and have Chromium running. Easy. Faster than the menu navigation. I go without clicking an item in the system menu for weeks at a time, on a desktop I use daily.

let me give an example of what I mean in a GIMP context (because that is the only thing that counts).

if a particular user uses Layer->New from Visible regularly, then invoking it with a mouse from the menu will be nigh impossible to beat with TITo, even if TITo manages to have a unique 2 char code for it in the given localisation (fat chance). the time loss is already there before the / shortcut is hit because it takes mental time and effort for users to get to the point of hitting that key (and you and I and all other users do not record that time loss, because we are so busy figuring out the shortcut; this means none of us is a reliable witness where it comes to how fast this stuff is)

Nor do I see adding a text-driven action/menu system as any sort of UI failure. or being in the least bit "misguided". What's inherently evil about adding shortcuts to get things done?

now that you ask: I would be misguiding one million users by saying on the record: here is a way to use GIMP, for intense use.

And if some labels aren't clear in TITo, might they need to be looked at anyway - maybe they really are ambiguous or could be worded better? The couple mentioned in the BZ report seemed a little funky.

I am happy to change a menu label for any good reason (that is helping users), but never to help TITo out (which is helping a mechanical robot).

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

On 01/14/2014 03:13 PM, Chris Mohler wrote:

Staying with the same example, then English menu entry is 'Chromium Web Browser'. When switching to Spanish or Chinese, the 'Chromium' remains the same while 'Web Browser' is translated.

I read peter's objection to the requirement that the entire language translation process would be impacted, making maintenance nearly impossible.

On 01/14/2014 11:48 PM, Burnie West wrote:

As Peter pointed out - what do you type in on Mint/Cinnamon if you happen to speak Chinese?

On 01/14/2014 01:43 PM, Chris Mohler wrote:

And yet the desktop menu in Mint/Cinnamon does precisely this and it *is* fast. I type "Win-key,c,h,r,Enter" and have Chromium running. Easy. Faster than the menu navigation. I go without clicking an item in the system menu for weeks at a time, on a desktop I use daily.

I don't think it is applicable here because you can be pretty much mouse-less on a desktop so that you can type everything with two hands.

In Gimp you have only one hand (the other one is on the mouse/tablet). Either you lose time going back and forth between mouse and keyboard to use both hands on the keyboard, or your non-mouse hand goes in hunt-and-peck mode on the keyboard half it is not accustomed to.

On Tue, Jan 14, 2014 at 6:45 PM, Ofnuts wrote:

On 01/14/2014 01:43 PM, Chris Mohler wrote:

And yet the desktop menu in Mint/Cinnamon does precisely this and it *is* fast. I type "Win-key,c,h,r,Enter" and have Chromium running. Easy. Faster than the menu navigation. I go without clicking an item in the system menu for weeks at a time, on a desktop I use daily.

I don't think it is applicable here because you can be pretty much mouse-less on a desktop so that you can type everything with two hands.

In Gimp you have only one hand (the other one is on the mouse/tablet). Either you lose time going back and forth between mouse and keyboard to use both hands on the keyboard, or your non-mouse hand goes in hunt-and-peck mode on the keyboard half it is not accustomed to.

So I'm the only one using keyboard shortcuts then? You actually File->Save with your *mouse*? How to you enter text on your text layers?

For the record: some shortcuts require me to drop the pen, others I can swing with it between fingers. But I doubt I've done File->Save with mouse or pen for 15 years, consecutively. And yet there are items deep within menus I've forgotten that take hunting for. If I remember the name or the description of the thing, why must I wander around seeking the right menu or sub-menu?

What is TITo really, aside from more robust/intelligent keyboard shortcuts? I'll try and checkout the branch and see what it's like in person, but I can't see what the harm is. From the what I've seen so far, it could only be a slight asset to a (granted) small sub-set of users, but not something that would hamper *anyone's* workflow/experience, whether they actively use it or not.

Chris

On Tue, Jan 14, 2014 at 6:22 PM, Burnie West wrote:

Staying with the same example, then English menu entry is 'Chromium

Web Browser'. When switching to Spanish or Chinese, the 'Chromium' remains the same while 'Web Browser' is translated.

I read peter's objection to the requirement that the entire language translation process would be impacted, making maintenance nearly impossible.

How so - are the menus/actions not translated already? I thought they were, but I've been wrong before (and often ;).

Chris

On Tue, Jan 14, 2014 at 5:54 PM, peter sikking wrote:

it takes mental time
and effort for users to get to the point of hitting that key (and you and I and all other users do not record that time loss, because we are so busy figuring out the shortcut; this means none of us is a reliable witness where it comes to how fast this stuff is)

I want to quote this bit on it's own, because frankly it's damned silly. Until you get down to weird sub-atomic particles, just about everything can be measured.

Learned keystrokes are going to beat "menu click" every time, when it comes to speed of experienced users. Yikes. It's the linux CLI wars all over again :(

Chris

PS - perhaps unfortunately, full response to follow...

On Wed, 2014-01-15 at 00:08 -0600, Chris Mohler wrote: [...]

So I'm the only one using keyboard shortcuts then? You actually File->Save with your *mouse*? How to you enter text on your text layers?

My partner is an artist and almost never uses keyboard shortcuts. I use them all the time.

It seems to vary depending on the individual and circumstance.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

15 . 2014 . 4:45 "Ofnuts" :

In Gimp you have only one hand (the other one is on the mouse/tablet).

Either you lose time going back and forth between mouse and keyboard to use both hands on the keyboard, or your non-mouse hand goes in hunt-and-peck mode on the keyboard half it is not accustomed to.

This, however, appears not to bother Blender users all that much. Although you'd have to do a real study to be sure.

Alexandre

Hello Peter!

2014/1/14 peter sikking

Srihari Sriraman wrote:

Have we had a chance to look into this?

OK, I have looked at that spec.

... (removed lines about the stomach)

the problem with TITo is that as it stands now it is a conflicted mix of two intentions:

1) a help system via text search to learn using GIMP

2) a command-line system for operating GIMP

Can you tell us which feature is 1) and which is 2)?

some note:

- yes, for me 1) maps to give these guys a break and 2) to completely misguided sort term _and_ long term; - if you are serious about Text-based Intent driven Tool then you have to build a synonym list for all keywords, in all localisations; else you are just bluffing;

Why? All command lines I use (Windows Start searchbox, Gnome 3 searchbox, Firefox Actionbar, the Terminal, a searchbox in the ERP-System at work) work nice without a synonym list for keywords. I think a synonym list could even be annoying, because it could give me too much search results.

- with different people working on it, I suspect they have different intentions, or are conflicted internally themselves;

Can you give us some examples?

- since TITo is right now a random mix of 1) and 2), it is really not working for either intentions; things implemented for 1) get in the way of 2) (and vice versa);

Can you give us some examples? (I'm repeating myself.)

... (removed more lines)

some more things that are very important:

- even if TITo response time is instant, keyword formulation -> typing in a text based interface is not exactly fast; please drop the its fast argument;

Sorry, but all command line text based interfaces I use are feeling fast to me. Why do you expect it to be different in GIMP?

- I read in the bug report that peple are contemplating changing labels of menu items to help TITo to perform better; that is the most dangerous thing I have heard in a long while;

Here I'm 100% with you.

- if anyone is serious about solving how to help serious GIMP users with faster use of plugins and other sprawling stuff, let me know; it can be designed...

I'm not a programmer, but I'm interested in the solution you would provide.

Regards, Tobias

Burnie West wrote:

On 01/14/2014 03:13 PM, Chris Mohler wrote:

Staying with the same example, then English menu entry is 'Chromium Web Browser'. When switching to Spanish or Chinese, the 'Chromium' remains the same while 'Web Browser' is translated.

I read peter's objection to the requirement that the entire language translation process would be impacted, making maintenance nearly impossible.

I actually did not say that. I do not see it that way.

and instead of going into the smaller points that are being raised in the replies to my previous post, I am going concentrate on the main point.

Structuring the design process is half the work in my daily practice and in order to enable the TITo situation to turn from negative to positive, I will contribute this:

1) the people who are really driving this (Srihari Sriraman and Jehan Pags I believe) have to take a hard choice; is TITo

a) a help system via text search to learn using GIMP

b) a command-line system for operating GIMP

these things are mutually exclusive (too long to explain, but see below...) and that is why there is no fudging possible. Make the choice and write it at the top of the spec page (TITo is ...)

2) remove from the spec (and the code) everything that belongs to what you chose TITo _not_ to be (not to worry, I will point out what will have to go).

examples:

if you chose TITo to be a) (a help system) then things that belong to b) have to go. this include the 2-char command thing and the f-recency prioritisation (or, you will need to change that for learning situations so much that you would not recognise it anymore).

if you chose TITo to be b) (a command-line system) then things that belong to a) have to go. this includes verbose explanations when showing the actions that match the query string.

3) now you have to design TITo, for the goal you set.

examples:

if you chose TITo to be a) (a help system) then you must build a bridge to the docs.gimp.org (in the right localisation); there are many ways to do this. as I said before, if you are serious about Text-based Intent driven Tool then you have to build a synonym list for all GIMP command keywords, in all localisations; since this is open source, I recommend you design a system where users playfully add synonyms themselves to their own localisation (which is then shared across the GIMP community). also you need to concentrate on teaching users where they find the thing they have queried in the UI (show it, not say it), instead of invoking it.

if you chose TITo to be b) (a command-line system) then you need to design a super-fast input method, maybe permanently available if users chose so. and you need to design a command language (a difficult job I would not like to take on, even if they paid me double); the current 2-char lets-see-if-we-get-lucky is simply not going to cut it.

4) we review the spec, and adjust until you have something that realises you stated goal.

5) implement. you can do this before, during or after you write your spec. the spec however is authoritative, and at the moment that you want TITo to be included in a GIMP release, that implementation most match the spec. no fudging with less or more features.

when you have successfully taken steps 15 you can get TITo into the standard GIMP release. if you decline, or are unable, to complete any steps, then as far as I am concerned TITo will not get into the standard GIMP release.

in that case you better think of how TITo can be distributed as a user-installable add-on. in that case you can also make TITo whatever you want (it is a free world), because it no longer reflects on the GIMP project how it turns out.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

On Tue, Jan 14, 2014 at 5:54 PM, peter sikking wrote:

And yet the desktop menu in Mint/Cinnamon does precisely this and it *is* fast. [...]

let me give an example of what I mean in a GIMP context (because that is the only thing that counts).

if a particular user uses Layer->New from Visible regularly, then invoking it with a mouse from the menu will be nigh impossible to beat with TITo, even if TITo manages to have a unique 2 char code for it in the given localisation (fat chance). the time loss is already there before the / shortcut is hit because it takes mental time and effort for users to get to the point of hitting that key (and you and I and all other users do not record that time loss, because we are so busy figuring out the shortcut; this means none of us is a reliable witness where it comes to how fast this stuff is)

That would certainly be faster when using a direct shortcut or a button. Oh, if there *was* a direct shortcut or button (hint, hint, oh UI architect ;).

A counter-example: I need the 'Newsprint' filter every 2 months or so, but for some reason can't seem to remember which filter menu it's under. Why is it such a disaster to expose that filter to a search? A follow-up question: (without looking - no cheating) which menu/sub-menu would *you* look under to find 'Newsprint'? Find that answer intuitive? How about 'wavelet decompose'? And how about a myriad of other third-party plug-ins?

I _must_ know: what unit(s) do you use to describe 'mental time'? Are they accurate? Precise? Both? Do tell. Call it "burning curiosity" on my part.

do I see adding a text-driven action/menu system as any sort of UI

failure. or being in the least bit "misguided". What's inherently evil about adding shortcuts to get things done?

now that you ask: I would be misguiding one million users by saying on the record: here is a way to use GIMP, for intense use.

How many millions use Windows? The start menu in Win7 is remarkably similar to the behavior of Mint15+Cinnamon (I won't speak to who's copying whom).

(in case it's not easily detected, the use of "million" here and again is an *ancient* fallacy, and sarcasm is notably hard to detect via email ;)

In OS9 I could open Illustrator or PS, and punch in commands so fast they would never hit the screen, walk away and the work was done before I came back. Yes, I doubt GIMP+TITo can match that, but it seems to be a start. With time+effort and an input buffer(!) it could be more than "intense" if not "amazing/brilliant/awesome" (thanks to Sriraman and Jehan so far!).

And if some labels aren't clear in TITo, might they need to be looked at anyway - maybe they really are ambiguous or could be worded better? The couple mentioned in the BZ report seemed a little funky.

I am happy to change a menu label for any good reason (that is helping users), but never to help TITo out (which is helping a mechanical robot).

Robot? Please clarify the difference between GIMP and other "robots". Is GIMP *not* an artificial construct between me and an image? ie if you label TITo a "robot" then that term then applies to GIMP. You seem to be wading/wallowing into philosophy (as opposed to UI) at this point, but might (though I doubt it) forgive my earlier (impertinent) questions ;)

To quote your message: ...‘that is OKish, give these guys a break’ ...‘that is awful, completely misguided’ [repeats]

Interpreted, to the best of my understanding:

... "I'm a UI god and as long as it does't threaten my credibility it's OK" ... "gods forfend *anyone* make something work better when *I* haven't thought of it yet"
[repeats]

My interpretation is (deliberately) awful - and I ***hope*** it is incorrect.

Unless I'm missing something your arguments against TITo are _purely_ philosophical and (at least by me) poorly understood. Give me (objectively) *measurable* objections and I'll (probably) shut the hell up ;).

Chris

PS - Peter: would it kill you to start a sentence with a capitalized letter, or is that some "UI secret" you've left us all out on? Is there some measurable advantage you attain by not capping your sentences? Makes your input more user-friendly, perhaps - or maybe you are a disciple of Larry Wall?

On Wed, Jan 15, 2014 at 4:15 AM, peter sikking wrote:

when you have successfully taken steps 1–5 you can get TITo into the standard GIMP release. if you decline, or are unable, to complete any steps, then as far as I am concerned TITo will not get into the standard GIMP release.

$ui_god has spoken, and wrothfully: look out!

Chris

Hi Chris.

Chris Mohler (cr33dog@gmail.com) wrote:

$ui_god has spoken, and wrothfully: look out!

I don't think it is fair to get snarky at peter, especially after he has carefully explained what his concerns are.

Thanks, Simon

simon@budig.de              http://simon.budig.de/

Hello Peter,

thank you for this mail. It answers all my questions and I think it is very productive. Perhaps even both 1) and 2) can be implemented as two separate systems.

Regards
Tobias

2014/1/15 peter sikking

Burnie West wrote:

On 01/14/2014 03:13 PM, Chris Mohler wrote:

Staying with the same example, then English menu entry is 'Chromium Web Browser'. When switching to Spanish or Chinese, the 'Chromium' remains the same while 'Web Browser' is translated.

I read peter's objection to the requirement that the entire language

translation process would be impacted, making maintenance nearly impossible.

I actually did not say that. I do not see it that way.

and instead of going into the smaller points that are being raised in the replies to my previous post, I am going concentrate on the main point.

Structuring the design process is half the work in my daily practice and in order to enable the TITo situation to turn from negative to positive, I will contribute this:

1) the people who are really driving this (Srihari Sriraman and Jehan Pags I believe) have to take a hard choice; is TITo

a) a help system via text search to learn using GIMP

b) a command-line system for operating GIMP

these things are mutually exclusive (too long to explain, but see below...) and that is why there is no fudging possible. Make the choice and write it at the top of the spec page (TITo is ...)

2) remove from the spec (and the code) everything that belongs to what you chose TITo _not_ to be (not to worry, I will point out what will have to go).

examples:

if you chose TITo to be a) (a help system) then things that belong to b) have to go. this include the 2-char command thing and the f-recency prioritisation (or, you will need to change that for learning situations so much that you would not recognise it anymore).

if you chose TITo to be b) (a command-line system) then things that belong to a) have to go. this includes verbose explanations when showing the actions that match the query string.

3) now you have to design TITo, for the goal you set.

examples:

if you chose TITo to be a) (a help system) then you must build a bridge to the docs.gimp.org (in the right localisation); there are many ways to do this. as I said before, if you are serious about Text-based Intent driven Tool then you have to build a synonym list for all GIMP command keywords, in all localisations; since this is open source, I recommend you design a system where users playfully add synonyms themselves to their own localisation (which is then shared across the GIMP community). also you need to concentrate on teaching users where they find the thing they have queried in the UI (show it, not say it), instead of invoking it.

if you chose TITo to be b) (a command-line system) then you need to design a super-fast input method, maybe permanently available if users chose so. and you need to design a command language (a difficult job I would not like to take on, even if they paid me double); the current 2-char lets-see-if-we-get-lucky is simply not going to cut it.

4) we review the spec, and adjust until you have something that realises you stated goal.

5) implement. you can do this before, during or after you write your spec. the spec however is authoritative, and at the moment that you want TITo to be included in a GIMP release, that implementation most match the spec. no fudging with less or more features.

when you have successfully taken steps 15 you can get TITo into the standard GIMP release. if you decline, or are unable, to complete any steps, then as far as I am concerned TITo will not get into the standard GIMP release.

in that case you better think of how TITo can be distributed as a user-installable add-on. in that case you can also make TITo whatever you want (it is a free world), because it no longer reflects on the GIMP project how it turns out.

--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

On Wed, Jan 15, 2014 at 4:32 AM, Simon Budig wrote:

Chris Mohler (cr33dog@gmail.com) wrote:

$ui_god has spoken, and wrothfully: look out!

I don't think it is fair to get snarky at peter, especially after he has carefully explained what his concerns are.

His concerns seem to be be... unfounded. I'm trying to be tactful but "imaginary" might be a better term.

I mean: where does the "it must be A or B" come from? Wherever it is, I'm not following said path. It does not make sense to me. Please explain.

And yes, I've been an ass tonight - I ask no forgiveness, but a little tolerance.

Chris

Chris Mohler (cr33dog@gmail.com) wrote:

His concerns seem to be be... unfounded.

So, what *is* Tito? A help system or a command line system? I have not seen an answer to that yet.

And yes, I agree with Peter that this is a vital question.

I mean: where does the "it must be A or B" come from? Wherever it is, I'm not following said path. It does not make sense to me.

Because "I think if I add this feature there might be someone who might possibly find this helpful" is not a good guide when sharpening the features of your system. We want to avoid ad-hoc-design-descisions and that means that we need to decide on the scope we want to cover with a new system.

Bye,
Simon

simon@budig.de              http://simon.budig.de/

Tobias Jakobs wrote:

the problem with TITo is that as it stands now it is a conflicted mix of two intentions:
1) a help system via text search to learn using GIMP 2) a command-line system for operating GIMP

Can you tell us which feature is 1) and which is 2)?

I think you are proving my point. it is TITo, trying to be both.

some note:

- yes, for me 1) maps to give these guys a break and 2) to completely misguided sort term _and_ long term; - if you are serious about Text-based Intent driven Tool then you have to build a synonym list for all keywords, in all localisations; else you are just bluffing;

Why? All command lines I use (Windows Start searchbox, Gnome 3 searchbox, Firefox Actionbar, the Terminal, a searchbox in the ERP-System at work) work nice without a synonym list for keywords. I think a synonym list could even be annoying, because it could give me too much search results.

because it says Text-based Intent driven Tool not a command line where you have to learn the ropes before it gets useful.

(see my other mail for the main point that we should be discussing; it does contain quite a few examples that you are asking for, I think)

- if anyone is serious about solving how to help serious GIMP users with faster use of plugins and other sprawling stuff, let me know; it can be designed...

I'm not a programmer, but I'm interested in the solution you would provide.

the problem is concentrated on the plugins and GEGl operations.

so what I am thinking of is a (maybe radical) redesign of the Filters menu. with the following goals:

- faster and surer (slip of the mouse with sub-menus) invocation of all plugins and GEGl operations (and browsing them); - right-sized lists of recent items, recent items with values; most used items, favourites (?), all for direct + fast invocation; - user configuration (dicey theme);
- an accompanying dockable dialog, for those with the space

my 2

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

On Wed, Jan 15, 2014 at 4:57 AM, Simon Budig wrote:

So, what *is* Tito? A help system or a command line system? I have not seen an answer to that yet.

Why the distinction? We now have A vs B when neither were the intent... (or maybe I'm wrong - ask the authors, see the video ;)

(actually I'm pretty sure A nor B never came up - they're *new* as of this afternoon/evening)

AFAICT TITo is a keyboard way of getting to things quicker (so not case 'A' nor case 'B'), and I still fail to see the problem with it. Please someone tell me what is so horrible about getting there quicker. I'd really like to known how (specifically) it will fail *millions* of users.

Chris

Am 15.01.2014 11:15, schrieb peter sikking:

I actually did not say that. I do not see it that way.

and instead of going into the smaller points that are being raised in the replies to my previous post, I am going concentrate on the main point.

Structuring the design process is half the work in my daily practice and in order to enable the TITo situation to turn from negative to positive, I will contribute this:

1) the people who are really driving this (Srihari Sriraman and Jehan Pags I believe) have to take a hard choice; is TITo

a) a help system via text search to learn using GIMP

b) a command-line system for operating GIMP

these things are mutually exclusive (too long to explain, but see below...) and that is why there is no fudging possible. Make the choice and write it at the top of the spec page (TITo is ...)

2) remove from the spec (and the code) everything that belongs to what you chose TITo _not_ to be (not to worry, I will point out what will have to go).

examples:

if you chose TITo to be a) (a help system) then things that belong to b) have to go. this include the 2-char command thing and the f-recency prioritisation (or, you will need to change that for learning situations so much that you would not recognise it anymore).

if you chose TITo to be b) (a command-line system) then things that belong to a) have to go. this includes verbose explanations when showing the actions that match the query string.

3) now you have to design TITo, for the goal you set.

examples:

if you chose TITo to be a) (a help system) then you must build a bridge to the docs.gimp.org (in the right localisation); there are many ways to do this. as I said before, if you are serious about Text-based Intent driven Tool then you have to build a synonym list for all GIMP command keywords, in all localisations; since this is open source, I recommend you design a system where users playfully add synonyms themselves to their own localisation (which is then shared across the GIMP community). also you need to concentrate on teaching users where they find the thing they have queried in the UI (show it, not say it), instead of invoking it.

if you chose TITo to be b) (a command-line system) then you need to design a super-fast input method, maybe permanently available if users chose so. and you need to design a command language (a difficult job I would not like to take on, even if they paid me double); the current 2-char lets-see-if-we-get-lucky is simply not going to cut it.

4) we review the spec, and adjust until you have something that realises you stated goal.

5) implement. you can do this before, during or after you write your spec. the spec however is authoritative, and at the moment that you want TITo to be included in a GIMP release, that implementation most match the spec. no fudging with less or more features.

when you have successfully taken steps 15 you can get TITo into the standard GIMP release. if you decline, or are unable, to complete any steps, then as far as I am concerned TITo will not get into the standard GIMP release.

in that case you better think of how TITo can be distributed as a user-installable add-on. in that case you can also make TITo whatever you want (it is a free world), because it no longer reflects on the GIMP project how it turns out.

I can't really follow your arguments. You want something to be either the one thing or the other. But does a user really want the one thing or the other?

Many users do not need a real help system (a long boring text document with a full text search) or a console (shortcuts or a history are usually the best way for repeated actions). They actually search for a functionality (action) that does the trick, while the function itself is usually self explanatory (otherwise it is badly designed itself). The worst part of complex software programs is not the amount of functionality, but to find the right menu entry or shortcut in the endless list of possibilities. A simple search tool for this actions is big help for new and even experienced users that don't know where a functionality is hidden or how it even has been named. That is it's purpose:

1. Finding an functionality by typing in a related term 2. Looking up or changing the shortcut for a functionality 3. Finding and executing an functionality that is used quite seldom. While the name might be known, the location often is not (hovering over menus takes way longer as typing).

Greetings from Tobias Oelgarte

Tobias Oelgarte (tobias.oelgarte@googlemail.com) wrote:

I can't really follow your arguments. You want something to be either the one thing or the other. But does a user really want the one thing or the other?

Well, as far as I interpreted peter it could be a third thing also.

However, what is lacking is a design goal: What is it you're trying to achieve? Stating negative goals ("it is not a help system" or "it is not a command line language") can help, but ultimately you need to describe what you want to achieve. And for the first step you probably should avoid incorporating your proposed solution ("typing") into the goal ("finding actions"):

That is it's purpose:

1. Finding an functionality by typing in a related term 2. Looking up or changing the shortcut for a functionality 3. Finding and executing an functionality that is used quite seldom. While the name might be known, the location often is not (hovering over menus takes way longer as typing).

What has the higher priority? Finding actions? Speeding up frequently used operations? Speeding up rarely used functions? Exploring functionality?

If you look at the product vision for gimp you'll see that we use it as a tool to set priorities: We focus on complex image manipulation tasks and we don't focus on Gimp being used as a JPEG viewer.

The same focussing is necessary for individual features to make sure that there is a clear target for the UI architecture. And I think this is the background for peters questions: He wants to understand the targets for development: If it is about exploring functions then this *might* collide with the goals for accellerating work. And unless we clarify our priorities here, we'll be stuck with a swiss army knife, which comes in handy at times, but is not really a good tool for any of the functions it offers.

Bye,
Simon

simon@budig.de              http://simon.budig.de/

On 01/15/2014 07:08 AM, Chris Mohler wrote:

On Tue, Jan 14, 2014 at 6:45 PM, Ofnuts > wrote:

On 01/14/2014 01:43 PM, Chris Mohler wrote:

And yet the desktop menu in Mint/Cinnamon does precisely this and it
*is* fast. I type "Win-key,c,h,r,Enter" and have Chromium running.
Easy. Faster than the menu navigation. I go without clicking an item
in the system menu for weeks at a time, on a desktop I use daily.

I don't think it is applicable here because you can be pretty much mouse-less on a desktop so that you can type everything with two hands.

In Gimp you have only one hand (the other one is on the mouse/tablet). Either you lose time going back and forth between mouse and keyboard to use both hands on the keyboard, or your non-mouse hand goes in hunt-and-peck mode on the keyboard half it is not accustomed to.

So I'm the only one using keyboard shortcuts then? You actually File->Save with your *mouse*? How to you enter text on your text layers?

Inputting text for text layers is a completely different matter.

I do use shortcuts (including Ctr-S and Ctrl-E...) but these are mostly on the left side of the keyboard. Ctrl-shift-N is already rather awkward despite my long fingers. The [] tp set the brush size are out of reach (on my AZERTY, these require the AltGr key). I mostly switch tools using the tools palette (where I removed those I seldom use and added some others).

What I would love is an extension of the Tool palette to include filters.

On 01/15/2014 11:18 AM, Chris Mohler wrote:

A counter-example: I need the 'Newsprint' filter every 2 months or so, but for some reason can't seem to remember which filter menu it's under. Why is it such a disaster to expose that filter to a search? A follow-up question: (without looking - no cheating) which menu/sub-menu would *you* look under to find 'Newsprint'?

"Help/Plugin browser"

To be honest, I sometimes don't remember the menu locations for some of my own scripts... but I don't remember their exact names either. And very often you don't even know what word to search for, or the word you would search for ("halftoning") is not the one used ("newsprint").

Am 15.01.2014 19:11, schrieb Simon Budig:

Tobias Oelgarte (tobias.oelgarte@googlemail.com) wrote:

I can't really follow your arguments. You want something to be either the one thing or the other. But does a user really want the one thing or the other?

Well, as far as I interpreted peter it could be a third thing also.

However, what is lacking is a design goal: What is it you're trying to achieve? Stating negative goals ("it is not a help system" or "it is not a command line language") can help, but ultimately you need to describe what you want to achieve. And for the first step you probably should avoid incorporating your proposed solution ("typing") into the goal ("finding actions"):

That is it's purpose:

1. Finding an functionality by typing in a related term 2. Looking up or changing the shortcut for a functionality 3. Finding and executing an functionality that is used quite seldom. While the name might be known, the location often is not (hovering over menus takes way longer as typing).

What has the higher priority? Finding actions? Speeding up frequently used operations? Speeding up rarely used functions? Exploring functionality?

If you look at the product vision for gimp you'll see that we use it as a tool to set priorities: We focus on complex image manipulation tasks and we don't focus on Gimp being used as a JPEG viewer.

The same focussing is necessary for individual features to make sure that there is a clear target for the UI architecture. And I think this is the background for peters questions: He wants to understand the targets for development: If it is about exploring functions then this *might* collide with the goals for accellerating work. And unless we clarify our priorities here, we'll be stuck with a swiss army knife, which comes in handy at times, but is not really a good tool for any of the functions it offers.

Bye,
Simon

It's about to make Gimp more accessible and to increase work speed at the same time.

Work speed:
For example we can look at the multitude of filter effects. I for myself struggle with the common task to find the right filter inside the UI. It's not that i wouldn't know which filter i want to use - i even know it's name -, but it is hard to locate it inside the main menu and sub menus, searching for it's menu item by looking at all the names. A search functionality can speed this task up immensely, by just typing in a fraction of the filters name.

Now we could say that we only want a filter navigator or something like that. But why should we limit it to that, when we could also provide a general interface to explore functionality? At the same time it could (optionally) include a history of recently used actions (with last settings). We do that for filters already, but the history is limited to one entry and it only works for filters.

If you know all your tools and also know exactly where to find them, then you might ignore a search. It's like typing in an URL that you know. But if you are not sure, then you use search engine or the browser history, which is quicker as trying to enter the right URL multiple times.

Accessibility for new users: New users are not used to the names of various menu items and tools. A search can also include alternative names for the same functionality (maybe used by other programs). It can additionally expose more information about the tool (for example a short description, a link to the help page, the shortcut if present, ...) or allow to directly adjust major settings of an action without to open the settings popup dialog.

That would be more or less my expectations of such a search functionality. I really like this features in Blender (Operator search [SPACE], History of Operators with previous settings [F3]) already, even though they could need even further improvements.

Greetings from Tobias Oelgarte

Am 15.01.2014 23:15, schrieb Ofnuts:

On 01/15/2014 11:18 AM, Chris Mohler wrote:

A counter-example: I need the 'Newsprint' filter every 2 months or so, but for some reason can't seem to remember which filter menu it's under. Why is it such a disaster to expose that filter to a search? A follow-up question: (without looking - no cheating) which menu/sub-menu would *you* look under to find 'Newsprint'?

"Help/Plugin browser"

To be honest, I sometimes don't remember the menu locations for some of my own scripts... but I don't remember their exact names either. And very often you don't even know what word to search for, or the word you would search for ("halftoning") is not the one used ("newsprint").

I'm the same. But in way more then 50% of the cases i know the name quite well and still find myself searching through the sub menus, just to locate it. A search could also easily avoid the "halftoning"/"newsprint" issue. It just needs to contain both or more search terms for the same item. This would also increase the impression for people that are used to other graphic programs and try to find the same or similar functionality in Gimp. Switching to Gimp isn't that hard, but not finding the stuff you are used to (even though it exists) can be quite headache.

Greetings from Tobias Oelgarte

Hey everyone,

Thanks a lot Jehan. My opinions are almost the same as yours. Tito is a cute internal/code name, but an action search dialog is what it is now.

Here's something that'll hopefully clarify a couple of things:

Earlier, during the early development stages of 'tito', it was envisioned to be literally all the things tabled above. I actually wanted to build a whole thesaurus and give the ability to search with synonyms ('scale' = 'resize', etc). At some point, I think I did implement something to the effect of => gaussblur(5,
5) in tito.
I wanted to do => new-layer | fill #aaa | text 100,100, 'foo' But then I also wanted to dominate, conquer the world, etc.

At that point, learning and discovering were a mild side effect. I did bring this up, and discuss this with Peter in IRC sometime back. So yes, to a good extent I think I stirred up the cross cutting intentions, feature muddle for tito.
Sorry.. G,D&R ;)

However, we have come a long way since then, and Jehan has helped pull this together.
Realistically, tito is what it is today. An action search dialog. If necessary, we could call it something that also suggests you can 'invoke' the action, and not just 'search' for it.

Off the top of my head, here's a sample of my usage patterns: I use the keyboard shortcuts for all select tools, new image, layer, save, export, close, delete, etc, show guides, etc. I use the action search for things like: 'blur', 'snap'ping to things, 'show'ing things, drop 'shadow', 'autocrop' image or layer, 'tile' filters, etc (Where things inside ''s are the things I type in).

Regards,
Srihari Sriraman -- ⌀ -- nilenso.com

El jue, 16-01-2014 a las 14:29 +1300, Jehan Pagès escribió:

Well that's the same but inside GIMP for internal commands. You want a blur command? You type "blur", and it will propose all the various filters, like "gaussian blur".

This is such a common feature, and useful as hell!

I think a search command would be useful for filters indeed. I can understand that less used filters grouped in categories are sometimes quite difficult to find, but that shouldn't be the case for the rest of the tools.

So, if the proposal is to improve the filters dialog, adding a search function and some other useful features (I think Peter mentioned a better method for accessing frequently used filters, for instance), I'm all for it.

But a search tool for every function in GIMP seems a terrible idea. You should learn to use the program, the tools should be arranged in a way it's useful and easy to reach/discover. And they are. I think GIMP UI has a decent distribution of commands in its menus and a search function there would be completely unnecesary. I use GIMP daily and I don't think I remember a single time I coudn't remember where to find a command.

Filters are a different thing, as they co-exist with plugins and addon scripts, under group names that aren't always so obvious, and under a menu that can become quite large.
I'd definitely a search function for filters, but not for the rest of the program. It seems silly. The menus make sense, the keyboard shortcuts are there.

Gez.

On Fri, 2014-01-17 at 01:15 -0300, Gez wrote:

I think a search command would be useful for filters indeed.

We already have one, although it could be improved - the plugin browser.

(I think Peter mentioned a
better method for accessing frequently used filters, for instance),

There used to be a "recently used" menu from Filters (actually there still is, but it doesn't list filters implemented in GEGL in 2.9; I expect this will get fixed and I should check there's a bug for it) A useful enhancement would for Recently Used Filters to be remembered between sessions.

I don't think that precludes a search function for other things. Some things I always have trouble finding include . text to path
. save channel to file
. crop to selection (hint: it's not under Edit or Layers)

Can you find "delete undo history"? (hint: it's not under Edit)

The bindings aren't logical to everyone and never will be, as there are too many of them.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

Srihari Sriraman wrote:

So yes, to a good extent I think I stirred up the cross cutting intentions, feature muddle for tito. Sorry.. G,D&R ;)

this matches what my conclusions is about TITo (having an internal code name that is as snappy as that is a good thing):

moving goal posts up to the point where the completely vanished.

However, we have come a long way since then, and Jehan has helped pull this together. Realistically, tito is what it is today. An action search dialog.

I see you are trying to make it through step one of the structured process that I contributed, as part of making it possible that TITo actually makes it into a GIMP release.

An action search dialog is a pure functional statement, it does not express why GIMP users (that is the context, read
to get in tune with that context) would find it valuable, and would bother to use it.

it just takes a few extra words to express that.

once you have completed step one, step two and three (rip out what does not belong there, and design that what makes TITo useful for GIMP users) becomes so much easier to define.

sit down, think about it, and take step one.

good luck,

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

this matches what my conclusions is about TITo

Admitting to confusion in the past isn't the same as being confused today. That is a straw man fallacy, and is not cool. https://yourlogicalfallacyis.com/strawman

An action search dialog is a pure functional statement, it does not

express why GIMP users..[snip]. would find it valuable, and would bother to use it. it just takes a few extra words to express that.

Well, I didn't express it because I thought 90% of this thread did a pretty good job.
A lot of people, and especially Jehan, have made excellent points above (to which I was hoping you'd reply).
It is not rocket science. Really, just use the thing, it works well, and I think you will find it very useful.

sit down, think about it, and take step one.

Hm, no. Not after years of writing and discussing this, sorry.

I am excited, and look forward to putting in the effort to make this possible.
But I think I'll have to drop out if this is the only way forward.

Regards,
Srihari Sriraman

On Fri, Jan 17, 2014 at 12:05 AM, Liam R E Quin wrote:

Some things I always have trouble finding include . text to path
. save channel to file
. crop to selection (hint: it's not under Edit or Layers)

I look for 'flatten image' under 'Layers' every single time it seems :/ Don't know if it's habit from PS or that's simply the place I think it ought to be.

Chris

El vie, 17-01-2014 a las 01:05 -0500, Liam R E Quin escribió:

There used to be a "recently used" menu from Filters (actually there still is, but it doesn't list filters implemented in GEGL in 2.9; I expect this will get fixed and I should check there's a bug for it) A useful enhancement would for Recently Used Filters to be remembered between sessions.

Yes, I know and I use the "recently used" section of the filters menu a lot (on the stable version), it's very convenient.

I meant improvements on that area, like the one you mentioned (remembering recent filters between sessions) or maybe a section for the filters that are used more frequently, not just the immediate recent ones.

I don't think that precludes a search function for other things. Some things I always have trouble finding include . text to path

This is a good example because it's something I never use so I didn't know where to find it.
But using the same logic I'd use with any other coomand I found it in the first try: right click on text (both on the text on canvas and on the thumbnail icon in the layers dialog).

. save channel to file

I agree on this one. But it seems more a workflow problem than discoverability. Channels manipulation is in my opinion one of GIMP's weakest points.

. crop to selection (hint: it's not under Edit or Layers)

Crop affects the entire image, so the command seems well placed where it is.

Can you find "delete undo history"? (hint: it's not under Edit)

Never had problems with this one, I have the undo history window docked and there's a pretty obvious icon for that. And the undo history window can be invoked from the edit menu, so your hint isn't exactly correct :-)

The bindings aren't logical to everyone and never will be, as there are too many of them.

Sure. Don't get me wrong, I'm not saying that all of them are obvious for every user out there. But I think that in general terms, the placement of commands follows some logic.

Gez.

El vie, 17-01-2014 a las 13:58 -0600, Chris Mohler escribió:

I look for 'flatten image' under 'Layers' every single time it seems :/ Don't know if it's habit from PS or that's simply the place I think it ought to be.

You nailed it: it's habit from PS. :-) I remember having troubles with that particular command when I switched to GIMP. It took me a while to re-wire my brain, but after using GIMP exclusively for several years I can't remember where it was in PS :-p

Anyway, I think you brought a valid example because it's both reasonable to look for it under "layers" or under "image" (where it is). That's why I don't invoke the command from the menu and I use right click on a layer thumbnail in the layers dialog. It's the last command in the list, so it's really easy to spot it there.

Gez.

Hi,

now that I i see the discussion has started and have to see how it ends with frustration let me contribute my 2c, too.

As far as I could reproduce the former discussions the whole topic started at the GIMP developer mailing list in February 2012. For instance see the history at
http://gimp.markmail.org/search/?q=tito#query:tito%20order%3Adate-forward+page:1+mid:6h6gse4ypiben2h3+state:facets

Srihari has brought up this topic often and informed about the progress. Many people, including Peter, joined the discussion and the purpose was already discussed. So, many things are not really new.

I understand both sides: Srihari who wants to contribute a thing he (and others) find very useful. I also understand Peter, who wants to make the best UI solution out of it and thus contributes his evaluation.
Earning respect for each ones work isn't demanded too much.

Can we agree to continue with the last state that was discussed here earlier and not step back to things that were already discussed? This would bring us forward. If somebody wants to test it him/herself out, you find a binary build at our Jenkins download page: https://gimptest.flamingtext.com:9090/view/AllDownloads/ The build is in the line 'GIMP menu search'. Please make sure to also install the babl master and GEGL master builds. It is all built for Linux/64-bit platforms.

Also (from own painful experiences), please note that purely textual conversations can't transport all the little human things you remark when speaking to each other face-to-face. Thus plain words can easily be misunderstood. So let's keep this in mind and finish the topic fairly and with respect to each other.

Kind regards,

Sven

Sven,

I appreciate that you want to mediate to make things go forward.

Srihari has brought up this topic often and informed about the progress. Many people, including Peter, joined the discussion and the purpose was already discussed. So, many things are not really new.

as things stand right now, the biggest thing that is wrong with TITo is that there seems to be no underlying purpose. lacking this it is a rather jumbled combination of features, which exactly expresses this purposelessness.

if the purpose of TITo is so clear, then tell me what it is, including a few words why it is valuable for GIMP users.

(anybody can contribute to this, it is just that Srihari and Jehan have to the final say on this definition, that is the right they earned by putting in the bulk of the code contribution)

I give you an example, so you know what I am asking for:

the Undo system is valuable to GIMP users because it allows them to proceed without fear (of doing something wrong).

you see I defined Undo not by its functionality, but by what it means to users.

people have already asked me: just say what should be changed about TITo.

I can tell you, once I know what it should be.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

On Mon, Jan 20, 2014 at 12:53 AM, peter sikking wrote:

Sven,

I appreciate that you want to mediate to make things go forward.

Srihari has brought up this topic often and informed about the progress. Many people, including Peter, joined the discussion and the purpose was already discussed. So, many things are not really new.

as things stand right now, the biggest thing that is wrong with TITo is that there seems to be no underlying purpose. lacking this it is a rather jumbled combination of features, which exactly expresses this purposelessness.

if the purpose of TITo is so clear, then tell me what it is, including a few words why it is valuable for GIMP users.

This conversation makes me sick.

Peter, you have been already told exactly that, in few words. There is absolutely no need to pretend you haven't heard about the search system. You did read that definition.

I appreciate your willingness to do everything right, but right now it looks like you are trying to be a problem instead of solving one.

Alexandre

On Sun, 2014-01-19 at 11:03 -0300, Gez wrote:

[...]

Don't get me wrong, I'm not saying that all of them are obvious for every user out there. But I think that in general terms, the placement of commands follows some logic.

I'd leave it to Peter Sikking and his team of experts, by and large, but for my own part I'm with Alan Cooper in "About Face" - design _first_ for the "perpetual intermediate", not the absolute beginner and also not the person who uses the application for hours a day every day.

The "perpetual intermediate" is unlikely to use enough of the program to grasp the logic behind placement of commands, especially when a command could reasonably go in more than one place.

I know there are times I use the plugin browser myself, but then, there are whole days when I forget to wear shoes and socks :-) I don't want to expect perfection in others, either...

best,

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On Mon, 2014-01-20 at 01:03 +0400, Alexandre Prokoudine wrote:

On Mon, Jan 20, 2014 at 12:53 AM, peter sikking wrote:

if the purpose of TITo is so clear, then tell me what it is, including a few words why it is valuable for GIMP users.

Peter, you have been already told exactly that, in few words.

Since Peter is intelligent and volunteering time, I'm pretty patient...

I'm with Peter in that I don't have a clear idea, but how about,

[[ Users who are less visual can quickly find and invoke image editing commands without having to memorize the structure of the whole interface. This helps people find their way around GIMP and also helps both intermediate and experienced users work faster when they prefer the keyboard to the mouse.
]]

It's not as succinct as it could be and to be honest I don't know if it's right, but that's the feel I get from the discussion.

Liam

Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On Sun, Jan 19, 2014 at 3:53 PM, peter sikking wrote:

(anybody can contribute to this, [...])

Allow me to contribute what I would like to see from a feature like this.

the Undo system is valuable to GIMP users because it allows them to proceed without fear (of doing something wrong).

My description is a bit longer than yours, so [a] indicates background, [b] is the statement, and [c] are additional vision/requirements.

[a] GIMP has more commands(/scripts) than can be reasonably managed by shortcut keys.

[b] The 'X(=tito?)' system allows easy(/rapid) keyboard access to functions that are either deep in the menu hierarchy or that are used too infrequently to assign shortcuts to. This benefits users by allowing them to streamline the creative process by using more input from the keyboard, much as Toolbox shortcuts currently allow.

[c.1] This system provides additional benefits over traditional shortcuts because the input text is searched for. This means that the shortcut doesn't have to first be memorized and that the system can also find 3rd-party/addon functionality that may have been bundled with the distro/binary package(s).

[c.2] Like in the menus, results will show any existing shortcuts. Unlike external "browser" tools, this will not interfere with the creative flow (i.e. Searches can begin with a single keystroke and can be used to abort a search without affecting other program state (actually, may be a good key to begin a search: easily discovered)).

Regards, Chris

My version of what it is:

"Action Search (aka TITO) is valuable to gimp users because it provides easy access to moderately used features of the gimp without memorization of the gimp's menu layout or keyboard shortcuts."

Even experienced power users won't know (shouldn't be forced to memorize) where *everything* is located. Now, they only need to know the name.

On Sun, Jan 19, 2014 at 3:53 PM, peter sikking wrote:

Sven,

I appreciate that you want to mediate to make things go forward.

Srihari has brought up this topic often and informed about the progress. Many people, including Peter, joined the discussion and the purpose was already discussed. So, many things are not really new.

as things stand right now, the biggest thing that is wrong with TITo is that there seems to be no underlying purpose. lacking this it is a rather jumbled combination of features, which exactly expresses this purposelessness.

if the purpose of TITo is so clear, then tell me what it is, including a few words why it is valuable for GIMP users.

(anybody can contribute to this, it is just that Srihari and Jehan have to the final say on this definition, that is the right they earned by putting in the bulk of the code contribution)

I give you an example, so you know what I am asking for:

the Undo system is valuable to GIMP users because it allows them to proceed without fear (of doing something wrong).

you see I defined Undo not by its functionality, but by what it means to users.

people have already asked me: just say what should be changed about TITo.

I can tell you, once I know what it should be.

--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

On 19.01.2014 21:53, peter sikking wrote:

as things stand right now, the biggest thing that is wrong with TITo is that there seems to be no underlying purpose. lacking this it is a rather jumbled combination of features, which exactly expresses this purposelessness.

if the purpose of TITo is so clear, then tell me what it is, including a few words why it is valuable for GIMP users.

I'm not sure if I have a real idea of TITo's purpose.

But if I'd use it, I think I'd use it like the prodecure browser or plug-in browser - to get an idea of what a procedure or plug-in does.

I'm not sure if I would use it to apply what I found on my image immediately then - probably because that image would not in the right state for this, e.g. lacking a selection, or set to work on a layer mask instead of the layer, stuff like this.

Regards,
Michael
GPG: 96A8 B38A 728A 577D 724D 60E5 F855 53EC B36D 4CDD

Hi,

thank you for your replies. I thought by myself it could be of value to summarize the former discussions here and in IRC etc. to give all the people involved the same state of knowledge.
But doing this would take some time and require to have less time for other tasks on my todo list (Wiki, Jenkins, techdoc and real life (what was that, again? ;-)). I guess I could get it done by the end of the week. Is there a need on your sides or do you all (at least Peter, Srihari and Jehan) already know it?

Kind regards,

Sven

Jehan,

thank you for making this step.

with some effort from me (moderating) and some from you (making clarifying choices) we will have this thing shaped. it will just take an email exchange.

allow me to summarise what you said:

The "action search" tool allows to search for and run commands in a natural way (with natural language text). It is for searching tools, plugins and filters in GIMP when one knows they exist but can't find anymore.

(you see I removed everything that is not in GIMP context, they do not mean anything. context is _everything_ in interaction design)

the statement above is not precise enough. so I am going to ask some questions to get us there:

1) you say action search tool. is it not menu item search tool? an _action_ search would search the toolbox tools, the layer stack and all dockable dialogs too (the latter being super useful).

2) you say natural language text, the definition of which is very wooly. similar as with Text-based Intent driven Tool it promises way too much (e.g. user types in blown highlights and TITo responds with burn tool). you need to be very precise in defining how sophisticated you want to be here (want to be, not describing the actual bit you do right now).

there are more questions, but these only make sense when you have answered the two above.

thanks,

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

On Tue, 2014-01-21 at 00:10 +0100, peter sikking wrote:

1) you say “action search tool.” is it not menu item search tool? an _action_ search would search the toolbox tools, the layer stack and all dockable dialogs too (the latter being super useful).

"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

2) you say “natural language text,” the definition of which is very wooly. similar as with ‘Text-based Intent driven Tool’ it promises way too much (e.g. user types in “blown highlights” and TITo responds with “burn tool”). you need to be very precise in defining how sophisticated you want to be here (want to be, not describing the actual bit you do right now).

Please let's forget about the name "TITO", it was a bad choice to begin with. This is about searching whatever text is associated with the action:

- its name (as in technical name e.g. "file-open") - its label (e.g. "Open...")
- its tooltip (e.g. "Open a file blah foo") - with a little effort all those things both in the english original and the translated local language

This is for initially finding the action, and this is the current state of affairs. Currently we are only talking about invoking the found action and should probably restrict the discussion to that, or it will get out of hand (like, let's not go into passing whatever parameters in that search entry)

However, what we IMO could talk about is having a little "help" button/icon in each row of the search results, for the case where searching "foo" gives you some results, and you'd rather look them up in help before applying them to your image.

regards, --mitch

Jehan,

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.

On Tue, Jan 21, 2014 at 12:47 PM, Michael Natterer wrote:

On Tue, 2014-01-21 at 00:10 +0100, peter sikking wrote:

1) you say action search tool. is it not menu item search tool? an _action_ search would search the toolbox tools, the layer stack and all dockable dialogs too (the latter being super useful).

"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.

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.

2) you say natural language text, the definition of which is very wooly. similar as with Text-based Intent driven Tool it promises way too much (e.g. user types in blown highlights and TITo responds with burn tool). you need to be very precise in defining how sophisticated you want to be here (want to be, not describing the actual bit you do right now).

Please let's forget about the name "TITO", it was a bad choice to begin with.

Yes! Please all, stop saying "tito", especially if that confuses you. TITO does not exist. This is an action search.

I am not confused.

you said natural language text, and I told you that is a huge can of worms if you put that in you goal.

I think it is best to say text search for now. interim version:

The "action search" tool allows to search for, and run, menu items via text search. It is for searching tools, plugins and filters in GIMP when one knows they exist but can't find anymore.

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.

thanks,

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Hi people,

look what I found in the former Google Summer of Code ideas:
http://wiki.gimp.org/index.php/Hacking:GSoC/Future/Ideas#Make_menus_searchable

I think it could perhaps shed some light about the Action Search Tools purpose and further treatment, at least it's an attempt.

Kind regards,

Sven

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 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 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.)

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. - 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; - 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!)
- 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; to grok this, invoking it or pointing out where it lives in the UI is not enough; it needs a short, sharp manual page;

- to summarise the above, TITo has to be competitive with googling "GIMP "

...or else be useless!

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Sven wrote:

look what I found in the former Google Summer of Code ideas:
http://wiki.gimp.org/index.php/Hacking:GSoC/Future/Ideas#Make_menus_searchable

I think it could perhaps shed some light about the Action Search Tools purpose and further treatment, at least it's an attempt.

I think both the intentions of the developers and the code have moved on a lot from there.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

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 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 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.)

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. - 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; - 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!’)
- 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; to grok this, invoking it or pointing out where it lives in the UI is not enough; it needs a short, sharp manual page;

- to summarise the above, TITo has to be competitive with googling "GIMP "

...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@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

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

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

On Mon, Jan 27, 2014 at 3:23 PM, peter sikking wrote:

TITo has to be competitive with
googling "GIMP "

...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

Alexandre Prokoudine writes:

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.

Even in English, people new to GIMP may look for "Resize" when they actually want "Crop", especially if they're transitioning from programs that don't use the word "Crop". I know that was a problem for me when I first started learning GIMP, and a search tool that told me something called "Crop" exists when I searched for "Resize" would have helped a lot.

...Akkana

On Tue, 2014-01-28 at 13:47 +0100, peter sikking wrote:

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.

It's not trying to be both, it's a menu/action search.

(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.

Nobody ever claimed it was a command interpreter.

All discussion aside, I have promised the guys that this would go in a long time ago, and just needs some cleanup. That cleanup has happened now and i suggest we merge it, also to prevent the (very real) danger of bitrot. Improvements happen a lot faster once an initial version is in git.

Also, a lot of time has passed since the initial proposal (code included) and now, and we cannot piss off people who put a lot of work into that by now rolling back to a state where no code even existed, especially given that merging it was already agrees upon. We can't retroactively change such decisions. Now that we are in this state, we have to work based on what we have.

Regards,
--Mitch

On Wed, Jan 29, 2014 at 12:12 AM, Chris Mohler wrote:

I bet I could type 'wav' and it would head the list (if not, 'wavel' should bring it to #1).

I finally checked out the branch and it's really quite nice. '/, w, a, v, enter' and the Wavelet decompose dialog pops up.

I mostly use key shortcuts for tools, but I like how it shows 'Dodge/Burn' and 'Blur/Shapen' tools with their respective shortcuts if I enter 'burn'. Beats having to hover the toolbox and wait for the tooltip.

I've only spent about 10 or 15 minutes with it so far, but I'm impressed and would use it as-is in stable. So much the better if the search algorithm gets some more tweaking (eg, not sure why entering 'layer' brings up the crop tool as #1). I can already tell it would be handy when looking for actions that I don't use that often and are under some filter sub-menu, or on a dockable menu that might not be focused.

I'm already in the habit of 'ALT+i, f' to flatten, but might come to use '/,f,l,enter' instead.

UI-wise, [deleted a bunch here]. It's nice that it remembers the pop-up placement and size. I moved the window up a bit and made it a bit taller and that works for me ;)

Nice job! Any chance we can pretend all the ideological debate never happened and just merge it? ;)

Chris

Also, having the recent file names available/listed is a fantastic. CTRL-$N is nice, but I tend to remember *what* I was working on recently as opposed to exactly *when*.

Chris

On Jan 29, 2014, at 23:04, Michael Natterer wrote:

All discussion aside, I have promised the guys that this would go in a long time ago, and just needs some cleanup.

then it was a complete waste of my time and expertise to get involved. it should not have been asked, if no one wanted to know anyway.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture