[Gimp-developer] Image history access from python

2014-01-15 Thread Paco Garcia 
hi, it would be very helpful to have access to the history of each image object
from python, at least to the coordinates where the user has pressed, for
example in two of my scripts to take coordinates from the user I force them
to create paths of only use the coordinates of two nodes, if I had access
to the user history clicks only have to access the last two clicks, for
example:
img = gimp.image_list () [0]
h = img.History
x1, y1 = h.mousePos [h.Length-1]
x2, y2 = h.mousePos [h.Length]
Or something like this
Currently forced the user to create paths which then has to clear, the
examples are:
http://www.arakne.es/en/dessign/gimp-python-plugin-rotate-image-using-paths/
http://www.arakne.es/en/dessign/gimp-script-stitch-layers/
Paco García
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread Tobias Jakobs 
Hello Peter!

2014/1/14 peter sikking pe...@mmiworks.net

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

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread Chris Mohler 
On Tue, Jan 14, 2014 at 5:54 PM, peter sikking pe...@mmiworks.net 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:
arrogance
... 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]
/arrogance


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?  sarcasmMakes your input more user-friendly, perhaps - or
maybe you are a disciple of Larry Wall?/sarcasm
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread Chris Mohler 
On Wed, Jan 15, 2014 at 4:15 AM, peter sikking pe...@mmiworks.net 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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread Tobias Jakobs 
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 pe...@mmiworks.net

 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 Pagès 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 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.

 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

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

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread Chris Mohler 
On Wed, Jan 15, 2014 at 4:32 AM, Simon Budig si...@budig.de wrote:

 Chris Mohler (cr33...@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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread Simon Budig 
Chris Mohler (cr33...@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

-- 
  si...@budig.de  http://simon.budig.de/
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread peter sikking 
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



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

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread Chris Mohler 
On Wed, Jan 15, 2014 at 4:57 AM, Simon Budig si...@budig.de 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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread Tobias Oelgarte 

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 Pagès 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 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.

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

Re: [Gimp-developer] Image history access from python

2014-01-15 Thread Joao S. O. Bueno 
Hi Pacco-

yes, subverting Path creation for getting user coordinates is currently the only
way GIMP plug-ins have to get them. (You could however, clear the
paths on the plug-in call if in your workflow clearing them become a
burden)


It is interesting to note that even the C plug-ins that ship with GIMP can only
get image coordinates by re-creating an image preview inside their window
(that could be done from Python plug-ins as well). But this is done by
old-style plug-ins  - new style plug-ins, using GEGL, don have much
of an UI definition yet, besides automatically generated UIs from the
GEGL-operation parameters.

I had proposed a couple of times in the past (distant past by now) to have
a way to call-back plug-ins upon user
actions on the images. Such a discussion should pop back
anytime soon, since on-dialog image previews for plug-ins
are now a thing of the past.

I don't think your proposal as is should fly though - I can't see
how to define
an image click from within a plug-in like you do. A click using what
tool? What settings?

Maybe a plug-in tool that would give a plug-in (or Gegl-op ) access
to all stroke parameters, more or less as specified in the ink markup
language would be a
more solid approach for GIMP (http://www.w3.org/TR/InkML/) in the
foreseable future.

  js
 --

On 15 January 2014 07:42, Paco Garcia jfga...@gmail.com wrote:
 hi, it would be very helpful to have access to the history of each image 
 object
 from python, at least to the coordinates where the user has pressed, for
 example in two of my scripts to take coordinates from the user I force them
 to create paths of only use the coordinates of two nodes, if I had access
 to the user history clicks only have to access the last two clicks, for
 example:
 img = gimp.image_list () [0]
 h = img.History
 x1, y1 = h.mousePos [h.Length-1]
 x2, y2 = h.mousePos [h.Length]
 Or something like this
 Currently forced the user to create paths which then has to clear, the
 examples are:
 http://www.arakne.es/en/dessign/gimp-python-plugin-rotate-image-using-paths/
 http://www.arakne.es/en/dessign/gimp-script-stitch-layers/
 Paco García
 ___
 gimp-developer-list mailing list
 List address:gimp-developer-list@gnome.org
 List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
 List archives:   https://mail.gnome.org/archives/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread 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).



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

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread Tobias Oelgarte 

Am 15.01.2014 19:11, schrieb Simon Budig:

Tobias Oelgarte (tobias.oelga...@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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread Jehan Pagès 
Hi Peter, and all,

Wow this created quite a discussion. I am on the road, so I have just
been skimming through the whole thread, and I will answer to the
first.

On Wed, Jan 15, 2014 at 7:52 AM, peter sikking pe...@mmiworks.net wrote:
 Srihari Sriraman wrote:

 Have we had a chance to look into this?

 On Sat, Nov 30, 2013 at 11:06 AM, Jehan Pagès jehan.marmott...@gmail.com 
 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

This is none of them. This is a search tool through available
contextual commands. So that's kind of 1) help system, but not with
learning as intent. Only with searching as intent (you may
discover some commands or filters of course, but that would be a
happy coincidence, same as when you may discover these same filters by
wandering in menus. There is no learning intent at all in this tool).

And this is definitely not a command line system. At least, when I
hear command line, I would usually hear language script. Here
that's just a list of commands, and you can search through them.
This is, in 2 words, a search tool.

 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;

I am pretty sure that this was written in the bugzilla thread: the
name TITo is only a working name. Actually I am very careful to
never use it when I present the tool (the original email I wrote was
titled Search Action dialog tool, and I think I did not say tito
anywhere in it, except as a git branch name). This name was originally
given by the original contributor (Srihari), but it does *not* exist
anymore. There is absolutely no tito written anywhere in our code. I
even wrote in the spec «The tito feature would be named more
generically: Action Search »

So please do not focus on this name. This is only a code and it is
non-existing in GIMP. If this name makes you uneasy, just don't use
it, just as I do (I always say the action search tool).
And we do not plan on creating synonyms for any command in all
localizations! uhuh :p

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

As said above, this is neither 1) nor 2). Really this is a very common
UI tool. I can see the same feature in blender (they call it the
space menu). And my program menu in my desktop has the exact same
tool. When I want to start a program, instead of searching through
submenus (which may have a huge list since a lot of programs are
installed), I can just type the name of the program and it finds it
for me.
So if I want to find GIMP in my application menu, I just type gimp
in the search. Even better, if I don't remember the name (let's say I
use GIMP once in a while and can't remember its name), I just write
image, or even photo and it will list various software, among them
GIMP (or dartktable, etc. Note that it does not search by name only,
but also description, etc. And it is localization aware, which is also
great).

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

Re: [Gimp-developer] Search Action dialog feature

2014-01-15 Thread Srihari Sriraman 
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,DR ;)

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