subject:"\[Gimp\-developer\] An update on the menu search"

Re: [Gimp-developer] An update on the menu search

2012-09-09 Thread Srihari Sriraman

Tito is now faster with fuzzy search! :)

Familiar with the file finder on emacs/vim/textmate/sublime-text?
You can now type in abstract characters from the menu item to find it.
appcan = Apply Canvas
gablr = Gaussian Blur
shgr = Show grid
jgs = Jigsaw
drpsh = Drop Shadow
...
I'll leave the rest to your creativity and imagination :)
[of course, you can still type in the name fully if you want to]

On Wed, Jun 6, 2012 at 1:39 PM, Srihari Sriraman tec...@visishta.netwrote:

 A few more updates:

- Works in any (all) languages supported by gimp.
- Opacity is now a preference.
- Width, Height and position are based on main window, not screen
(Tito resizes on Gimp resize).
- No more mark-up warnings in other languages.
- Code further tuned to Gimp style.
- Optimized code, removed unnecessary lines.

 A ton of thanks to Michael Muré (aka Bat`O) for his help!

 On Tue, Apr 17, 2012 at 9:01 AM, Srihari Sriraman tec...@visishta.netwrote:

 Firstly, We've fixed those buffer, malloc bugs in Tito.

  you have an opportunity to do something good for...
 ... 1/3 of the GIMP interaction system.
 is that worth it?


 Making a significant contribution to 1/3rd of the interaction system
 seems like a big deal to me.
 So yes, I think its worth it.


 You can Apply Canvas by typing in AC and hitting enter.
  Or say Gaussian Blur by just GB.


 The resolution of these 2 character inputs is done on the go.
 It should work irrespective of the language.
 I shall confirm this once I have tried this out.

 We tried developing the mac-like interface. It didn't work out.
 There isn't a sane way to do it in Gtk. [See Pitfalls in 
 specshttp://dl.dropbox.com/u/28366148/TITO-Specifications
 ]

 I think Tito is quite a cool tool to have. Even though it might not find
 an exact fit into the product vision.
 And since quite some people like Tito, my thoughts are in line with 
 Aleksandar
 Kovač.

 Please, let's afford ourselves some (U)ser e(X)perience with this work

 Tito has the potential to spur new ideas and solutions.

 I'll start a thread on the command system so there can be focussed
 healthy/lengthy discussions.



 On Sun, Apr 1, 2012 at 12:04 AM, peter sikking pe...@mmiworks.netwrote:

 Srihari Sriraman wrote:

  A command system would really boost the speed of interaction.

 now that would really depend a lot on how you design this.
 I must admit there is a tiny opportunity to come out faster than
 mousing the menus for a plugin without a shortcut key (ctrl-...).
 where is comes to menu items with shortcut keys, I am not sure you
 ever can.

 so let's see, you have an opportunity to do something good for
 a minority part of the menu structure, which by itself forms 1/3 of the
 GIMP interaction system.

 is that worth it?

 this of course apart form the help/explore/documentation system we
 talked about here and on irc. I thought we had understand each other
 during those talks.

  We're headed there.
  Blender's and Rhino's systems are great, so we'll be taking inputs
 from their design too.

 that does not sound like a confident approach to designing this
 for GIMP. think about the whole context of GIMP, its vision and
 its core users. all the work on the canvas.

 it starts with that realisation that you are working on what is
 a minority part of  1/3 of GIMP's interaction.

  Currently we're thinking of using a command syntax similar to that of
 ImageMagick..
  Would be great if we could pool in ideas regarding the command system
 here...
  (Will probably start a new thread on that soon).
 
  Just to note, Tito has this handy feature.
  If you enter 2 letters, it matches those actions with those 2 letters
 as the first letters of its words...
  Ex:
  You can Apply Canvas by typing in AC and hitting enter.
  Or say Gaussian Blur by just GB.

 have you run statistic on how many clashes (same 2 or 3 letters for
 different commands) in english? and then on to other languages, where
 the 2 or 3 words english needs to describe something (a peculiarity)
 is localised with a single word.

 there is 76 localisations of GIMP, I would not blame you if it can be
 made to work for all languages apart from urdu (or something like that).
 but if at the end it only works for 5 languages out of 76, then
 it would of course go nowhere.

 then on to non-latin input methods, on those standard latin keyboards
 computers are sold with. how would that be fast?

--ps

founder + principal interaction architect
man + machine interface works

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



 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gimp-developer-list




 --
 *
 *
 *Regards,
   *
 *Srihari Sriraman
   *





 --
 *
 *
 *Regards,
 *
 *Srihari Sriraman
 *





-- 
*
*
*Regards*
*Srihari

Re: [Gimp-developer] An update on the menu search

2012-04-16 Thread Srihari Sriraman

Firstly, We've fixed those buffer, malloc bugs in Tito.

 you have an opportunity to do something good for...
 ... 1/3 of the GIMP interaction system.
 is that worth it?


Making a significant contribution to 1/3rd of the interaction system seems
like a big deal to me.
So yes, I think its worth it.

You can Apply Canvas by typing in AC and hitting enter.
  Or say Gaussian Blur by just GB.


The resolution of these 2 character inputs is done on the go.
It should work irrespective of the language.
I shall confirm this once I have tried this out.

We tried developing the mac-like interface. It didn't work out.
There isn't a sane way to do it in Gtk. [See Pitfalls in
specshttp://dl.dropbox.com/u/28366148/TITO-Specifications
]

I think Tito is quite a cool tool to have. Even though it might not find an
exact fit into the product vision.
And since quite some people like Tito, my thoughts are in line with Aleksandar
Kovač.

 Please, let's afford ourselves some (U)ser e(X)perience with this work

Tito has the potential to spur new ideas and solutions.

I'll start a thread on the command system so there can be focussed
healthy/lengthy discussions.



On Sun, Apr 1, 2012 at 12:04 AM, peter sikking pe...@mmiworks.net wrote:

 Srihari Sriraman wrote:

  A command system would really boost the speed of interaction.

 now that would really depend a lot on how you design this.
 I must admit there is a tiny opportunity to come out faster than
 mousing the menus for a plugin without a shortcut key (ctrl-...).
 where is comes to menu items with shortcut keys, I am not sure you
 ever can.

 so let's see, you have an opportunity to do something good for
 a minority part of the menu structure, which by itself forms 1/3 of the
 GIMP interaction system.

 is that worth it?

 this of course apart form the help/explore/documentation system we
 talked about here and on irc. I thought we had understand each other
 during those talks.

  We're headed there.
  Blender's and Rhino's systems are great, so we'll be taking inputs from
 their design too.

 that does not sound like a confident approach to designing this
 for GIMP. think about the whole context of GIMP, its vision and
 its core users. all the work on the canvas.

 it starts with that realisation that you are working on what is
 a minority part of  1/3 of GIMP's interaction.

  Currently we're thinking of using a command syntax similar to that of
 ImageMagick..
  Would be great if we could pool in ideas regarding the command system
 here...
  (Will probably start a new thread on that soon).
 
  Just to note, Tito has this handy feature.
  If you enter 2 letters, it matches those actions with those 2 letters as
 the first letters of its words...
  Ex:
  You can Apply Canvas by typing in AC and hitting enter.
  Or say Gaussian Blur by just GB.

 have you run statistic on how many clashes (same 2 or 3 letters for
 different commands) in english? and then on to other languages, where
 the 2 or 3 words english needs to describe something (a peculiarity)
 is localised with a single word.

 there is 76 localisations of GIMP, I would not blame you if it can be
 made to work for all languages apart from urdu (or something like that).
 but if at the end it only works for 5 languages out of 76, then
 it would of course go nowhere.

 then on to non-latin input methods, on those standard latin keyboards
 computers are sold with. how would that be fast?

--ps

founder + principal interaction architect
man + machine interface works

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



 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gimp-developer-list




-- 
*
*
*Regards,
  *
*Srihari Sriraman
  *
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] An update on the menu search

2012-03-31 Thread peter sikking

Srihari Sriraman wrote:

 A command system would really boost the speed of interaction.

now that would really depend a lot on how you design this.
I must admit there is a tiny opportunity to come out faster than
mousing the menus for a plugin without a shortcut key (ctrl-...).
where is comes to menu items with shortcut keys, I am not sure you
ever can.

so let's see, you have an opportunity to do something good for
a minority part of the menu structure, which by itself forms 1/3 of the
GIMP interaction system.

is that worth it? 

this of course apart form the help/explore/documentation system we
talked about here and on irc. I thought we had understand each other
during those talks.

 We're headed there.
 Blender's and Rhino's systems are great, so we'll be taking inputs from their 
 design too.

that does not sound like a confident approach to designing this
for GIMP. think about the whole context of GIMP, its vision and
its core users. all the work on the canvas.

it starts with that realisation that you are working on what is
a minority part of  1/3 of GIMP's interaction.

 Currently we're thinking of using a command syntax similar to that of 
 ImageMagick..
 Would be great if we could pool in ideas regarding the command system here...
 (Will probably start a new thread on that soon).
 
 Just to note, Tito has this handy feature.
 If you enter 2 letters, it matches those actions with those 2 letters as the 
 first letters of its words...
 Ex:
 You can Apply Canvas by typing in AC and hitting enter.
 Or say Gaussian Blur by just GB.

have you run statistic on how many clashes (same 2 or 3 letters for
different commands) in english? and then on to other languages, where
the 2 or 3 words english needs to describe something (a peculiarity)
is localised with a single word.

there is 76 localisations of GIMP, I would not blame you if it can be
made to work for all languages apart from urdu (or something like that).
but if at the end it only works for 5 languages out of 76, then
it would of course go nowhere.

then on to non-latin input methods, on those standard latin keyboards
computers are sold with. how would that be fast?

--ps

founder + principal interaction architect
man + machine interface works

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



___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] An update on the menu search

2012-03-30 Thread Kevin Cozens


On 12-03-27 10:50 AM, Srihari Sriraman wrote:

We've developed TITO further.

[snip]

We're hoping to develop this further and build the command system...


It looks promising. It helps to find all features with a given key word but 
there still seems to be a bit of scrolling up/down the list which would seem 
to slow down the selection of functions/features.


One program that allows selection of operations via a command line interface 
and allows setting/changing of command parameters is Rhinocerus 3d. You can 
see a video of it at: http://www.youtube.com/watch?v=hJVrUqytvhA


When using the program I select a few things from the menus, often use the 
icons I have on the screen, but I use the command line to invoke some common 
operations for which I know the name. I can type SW, then tab which uses 
completion to turn that into Sweep followed by either a 1 or 2 
depending on if I want a one or two rail sweep. All options for the sweep 
command are shown with keyboard shortcuts so it is very quick/easy to select 
an operation and set its parameters.


The one difference between what you have done so far and Rhino's use of a 
command line is that Tito is useful when you don't know the name of a 
command but Rhino's use is good when you know the name of a command.


--
Cheers!

Kevin.

http://www.ve3syb.ca/   |Nerds make the shiny things that distract
Owner of Elecraft K2 #2172  | the mouth-breathers, and that's why we're
| powerful!
#include disclaimer/favourite | --Chris Hardwick
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] An update on the menu search

2012-03-15 Thread Aleksandar Kovač


On 2012-10-03 4:11 AM, peter sikking wrote:

sorry to spoil the party, but to see how think this is a good thing,
when it can be so treacherous, is quite dangerous.
But Peter, that's how all the experiments, prototypes, working models 
are! It has to be treacherous and it has to be dangerous. But exciting 
and inspirative, too. It's the fun of creation. So we can learn. Please, 
let's afford ourselves some (U)ser e(X)perience with this work before we 
judge it with too much ossified experience. No one will be hurt.


To use the example from the video: Ellipse. Yes, I agree with the 
assertion that clicking the icon is faster. How about typing even this 
expression in Srihari's prototype: e.g. 'selectellipse 304.4*304.4mm'. 
Results in: a 304.4*304.4mm elliptic selection loaded right on the 
cursor. It is arguable that this example would have an equally effective 
counterpart in either of suggested visceral/hands-on/shortcut approaches.


There are possibly a few more benefits. For example, if we imagine that 
each word is perhaps auto-filled, that the word order can be changed 
(i.e. '304.4*304.4mm selectellipse' = 'selectellipse 304.4*304.4mm'), 
that it 'gets' the meaning (these commands would have the same result: 
'selectcircle 304.4mm', 'selectelipse 304.4mm', '304.4mm*304.4mm 
selectellipse', ...), or that the thesauri and the dictionaries could be 
'translated' for other applications.

...

Maybe I am missing a point, but what is the substance of this 
'tick-tick-tick' heuristics/metaphor? ...I like it very much, tho! ;)
I did observe guys and girls working in newspaper offices, printing 
offices, etc. working like that. They are fast. But, they are not 
creating, they are editing. On the other hand, I have observed creatives 
whose rhythms are much different than that.

Or is it to suggest the access time for individual commands and operations?

On 2012-13-03 7:49 AM, peter sikking wrote:

I think it is becoming really clear that that is what it is in
this form: help/explore/documentation.
I am fine with that,
but the presentation of the system has to be one that is
tied to the help system (see for instance apple's system-wide
help system); not present it as some shortcut/command/quicksilver
system.
Rhino, Wolfram Alpha, Blender and even Spotlight provide some capable 
'command-lineish' interaction approaches. All of them mostly outside of 
the suggested help/explore/documentation category. Turning Srihari's 
command line into spoken commands, even. (and then we have Siri ;)). 
Would I let Siri be an mediator between GIMP and the user? Not sure, but 
I would like to try and experience it. By leaving intact, of course, all 
the great UI/UX work so far and the core elements of GUI; besides the 
issues, this prototype suggests some interesting things to me:


- Possibility of using human language (text or utterances) in GIMP to 
accomplish goals.

- Possibly more humane or even faster way to executing complex commands.
- Possibility of linking macros or actions to custom commands.
- Allowing users variance in commands, with predictive results.
- A small step towards a more universally designed GIMP.
- A valuable UX, UI experience and a possibility to disseminate new 
ideas or solutions.



... all essential commands need to be
uniquely invokable with a 2 character code, the rest (any
plugin) with a 3 character code. ...

I did not understand this, sorry.


---
Alex
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] An update on the menu search

2012-03-15 Thread Liam R E Quin

On Fri, 2012-03-16 at 04:44 +0900, Aleksandar Kovač wrote:
 How about typing even this 
 expression in Srihari's prototype: e.g. 'selectellipse 304.4*304.4mm'. 
 Results in: a 304.4*304.4mm elliptic selection loaded right on the 
 cursor.


Especially useful in inkscape; one might be more likely to want just
pixels in gimp rather than mm of course, although people working with a
single specific print use do often think in mm/inches.

Bigger is to note that this is drawing-as-maths not as manipulation.
There are times you want both, which is why Tool Options lets you enter
the numbers too.

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 www.advogato.org

___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] An update on the menu search

2012-03-10 Thread Srihari Sriraman

The correct git repo-
https://github.com/ssvz4/gimp-tito


On Sat, Mar 10, 2012 at 12:19 AM, Alexandre Prokoudine 
alexandre.prokoud...@gmail.com wrote:

 On Fri, Mar 9, 2012 at 9:42 PM, Srihari Sriraman wrote:

  Also, do you have a public Git repo or something?
 
  We do now - https://github.com/ssvz4/tito

 Oh..kay... This is going to be a bit of an issue. It looks like you
 are changing stuff on top of a code from a tarball or a Git snapshot.
 In that case merging your changes is going to be an issue, because by
 the time you end the project, the upstream project will move further,
 and thus merging your changes is going to be pain in the arse.

 We recommend working on top of the current Git master and merging
 upstream changes to your branch and publishing all of it.

  Talking of improvements, we're thinking of regex, adaption, vocabulary,
  auto-complete, hierarchy based search, etc.

 Depending on what exactly you mean with regex this could be an
 overkill, especially since there are so many of variants of it :) The
 rest needs at least a rough spec. We are passing most/all UI changes
 through Peter Sikking who is our UX architect, and I'm heavily betting
 that right now he's preparing one of his (in)famous Stern Looks for
 you :)

 Alexandre Prokoudine
 http://libregraphicsworld.org
 ___
 gimp-developer-list mailing list
 gimp-developer-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gimp-developer-list




-- 
*
*
*Regards,
  *
*Srihari Sriraman
  *
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] An update on the menu search

2012-03-10 Thread Srihari Sriraman

the above requires that GIMP is a tool that gets out of the way

...your tool is the opposite of that...
...you get right in the way.

Very true. We din't have this perspective.
Using keyboard shortcuts indeed gives the 2 operations per second thats
required in production environments.

However, I guess the video has been a little misleading...
The manner and frequency in which this tool is used, is up to the user.
i.e, the tool is meant to be complementary. It is not meant to be a
substitute for keyboard shortcuts.
So, a power user would be experiencing a smooth workflow (which GIMP
clearly provides) and this tool would help him when he's either stuck or
trying to find something. (i.e, help/explore/documentation)

Almost forget that there is a menu-bar

This anyhow, remains true.

tick-tick-tick-tick

So beautifully put. I've quoted this to a few people already! :)
The menu search tool will not give this speed.

Talking about increasing productivity, we've had ideas of extending the
concept to offer a command execution.
Wrt
http://www.gimpusers.com/forums/gimp-developer/13823-fw-suggestion-for-new-versions-of-gimp#message63546
that
is.
This perhaps, would really mean maximising productivity.

On Sat, Mar 10, 2012 at 12:41 AM, peter sikking pe...@mmiworks.net wrote:

Srihari Sriraman wrote:

can you give a statement what this is suppose to achieve.

Maximize productivity
Almost forget that there is a menu-bar. Use the mouse/touchpad lesser.

I accept the 3 points you write below, it is that
help/explore/documentation system I can see in this.

but the statement above? you do realise what GIMP is being
(re)designed for, no? it is for serious image manipulation,
seriously creative working and for production environments.

a lot of this work is hands-on on the canvas, in the context of the
graphics on the canvas, which are not like vector graphics or files
in a browser something that can be keyboard transversed.

the above requires that GIMP is a tool that gets out of the way,
by being visceral, part of motor memory. you tool is the
oposite of that, by users having to formula what they want
and type (part) in to get a query going then scan the results
and pick one, you get right in the way.

GIMP also requires that everything designed for it can support
working at a speed of 2 operations per second. just for a moment
say tick-tick-tick-tick-etc. at that speed. I do it every time
I bring this up in a lecture or when I teach interaction design.
it gets the point across right away.

so I have given you now 2 concrete requirements in a GIMP
context how you can prove the phrase Maximize productivity.
one is even quantitate, which is rare in user interaction design.

tell me how you meet them. if you don't, you are providing
anti-usability. (that is apart from the help/explore/documentation
system below:)

Intent driven rather than hierarchy driven navigation
Focus on 'what' rather than 'how'.
Discover functionality
For new users
Help transition
From proprietary software. What is 'smth' in GIMP?

sorry to spoil the party, but to see how think this is a good thing,
when it can be so treacherous, is quite dangerous.

--ps

founder + principal interaction architect
man + machine interface works

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

--
*
*
*Regards,
*
*Srihari Sriraman
*
___
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Re: [Gimp-developer] An update on the menu search

2012-03-10 Thread Michael Muré

I also think that it does not collide with the product vision. Even a
professional user need to learn a tool before using it. Also, I know a lot
of people that see GIMP as an enhanced MS Paint, because what GIMP is
capable of is not obvious. The menu search allow to answer the question
what can I do with X (layer, selection, image ..), without needing to
search in all the menu.

Also, I think you really should display the keyboard shortcut next to the
name of each item. It would allow to learn easily these shortcut, to use
them later at high speed.

My 2 cents.

2012/3/11 Srihari Sriraman tec...@visishta.net

the above requires that GIMP is a tool that gets out of the way

...your tool is the opposite of that...
...you get right in the way.

Very true. We din't have this perspective.
Using keyboard shortcuts indeed gives the 2 operations per second thats
required in production environments.

Almost forget that there is a menu-bar

This anyhow, remains true.

tick-tick-tick-tick

So beautifully put. I've quoted this to a few people already! :)
The menu search tool will not give this speed.

On Sat, Mar 10, 2012 at 12:41 AM, peter sikking pe...@mmiworks.netwrote: