On Tue, Nov 29, 2011 at 11:37 AM, Jim Michaels wrote:

Is there some way to make textures?

hi Jim,

I am not a code developer but a user, a researcher and, I like to think, user experience designer.
So, please take my words with a grain of salt.

'Open source' is fundamentally different from 'for-profit'. No, really! :) A paradigm shift on economy, politic, social and management levels. It is sometimes hard for us to completely switch in our minds between the two and very often the learned 'commercial' side leaks in our 'open source' brains. I am repeatedly baffled why some open-source websites still use marketing lingo to describe their efforts, when a simple human language would do. But, hey, we are all learning and we will get it right, eventually.

There might be some concepts you are familiar with. For example: market, customer, consumer, demand, warranty, proprietary, intellectual property, price, patent, production schedule, ... Those concepts do not translate in the open-source. But, open source offers some other concepts. Such as: freedom, openness, transparent, for fun, itch, modularity, activity driven, personal contribution, collaboration, fork, and many other concepts that matter to people. 'For-profit' paradigm is a paradigm of 'consumers'. 'Open-source' world is a paradigm of 'doers'. Consumers demand, pay and, well ... consume. The doers, do, contribute, create and initiate. Now, there is no market or competition GIMP or any other open source software has to put up against. So why cram everything inside? There are other projects that might perform the functions you need, and more often than not, you will find that your data is welcome in many of those.

I would argue from my experience in User interaction, that featuritis is NOT just 'how you organize the features and plugins'. The Mix of functions you put in any software beyond the core ones is an endless debate. Always. 'Handy' for someone is 'full blown ridiculous' to someone else. For excellent ideas, you don't need abundunce. In fact, scarcity breeds mastery. There are numerous cases in music, art, design, science, engineering... I firmly believe that. But to someone else, this is just BS. The key-word here is 'workflow'. If a piece of software can integrate in your preferred workflow, it will work for you. Your 'excellent' workflow in GIMP might be just a nonsensical ritual to someone else and the other way around, and both of you will be right.

I can see that you are active with GIMP Massive package. Your experience and insights in dealing with immense amount of plugins and addons might be a valuable contribution to user experience. From this experience, you might want to create an idea how to implement what you know would be a better way, or would like to see in GIMP, or some other future graphics project.

The same factors that contribute to acceptance of some code, will contribute to the acceptance of your ideas. If your ideas are articulated, presented and clear enough, and just work for other people, (i.e. clearly indicate the 'excellence' of your approach) they will be created/implemented/improved somehow somewhere by someone. That's how open source works ;). Maybe I am painting an idealized picture, here? ...

darktable is an admirable open-source effort to create a digital photography manager and RAW developer. It is a separate piece of software that might fit your workflow. You might find it roughly comparable (but not equivalent to!) Adobe Lightroom, silkyPix. If you have some time, please give it a try! Darktable comes among the top results if you google it.

Unfortunately, I was not able to see the reference on Topaz address you provided.

cheers,

Alex

On 11-11-29 16:37 , Jim Michaels wrote:

The only reason I am making the point is because I try to suggest GIMP to people who can't afford Photoshop or are looking for a free photo editor.
maybe it's not the best reason in the world. I just wanted to give people a solution they could afford. I was hoping to be able to give them something high end, intuitive, and hopefully easy to use.

Is there some way to make textures? stitch photos taken from various points of view? well, I can always do that with microsoft ICE or other programs made for panos, but not everybody knows about that - people will use what is built into the program they have (after all, that's all that can be done, right...?). - and I know this is wrong thinking, but when you don't implement features, the user doesn't know any better - most of the time, but then there are the power users who want it all and do just about everything with the program, and there are plenty of them out there.

I don't think feature-itis is a bad thing. it's just -well, how do you organize lots of features and plugins? when you have a large collection of plugins from the registry installed, you get REALLY WIDE, long menus. especially if you have photoshop filters for pspi.exe you want to add to that collection as well.

There is some significant functionality provided by photoshop filters. again, take a look at http://alienskin.com/eyecandy/index.aspx these can make the difference between a toy-looking site and a professional site with some skill. there are a lot of junk filters out there that simply just ruin an image. I have had to wade through them. But once in a while you find out about companies like http://Topaz.com

"Please use darktable" what darktable? it doesn't exist in 2.6.11 nor in the plugin registry. vaporware. or someone is just being dark. :-/ I don't even like the name.

"Gimp is just GIMP." seems so mediocre. I was hoping to spur some Excellence. maybe someone can come up with some radical new ideas for photo imaging and put it into GIMP. I have already heard of one excellent idea which became a plugin.

On Mon, Nov 28, 2011 at 11:37:27PM -0800, Jim Michaels wrote:

The only reason I am making the point is because I try to suggest GIMP to people who can't afford Photoshop or are looking for a free photo editor.
Maybe it's not the best reason in the world.

Definitely but understandable.

2011/11/29 Aleksandar Kovač wrote:

The same factors that contribute to acceptance of some code, will contribute to the acceptance of your ideas. If your ideas are articulated, presented and clear enough, and just work for other people, (i.e. clearly indicate the 'excellence' of your approach) they will be created/implemented/improved somehow somewhere by someone. That's how open source works ;). Maybe I am painting an idealized picture, here?

You aren't :) Peter started the brainstorm blog exactly with intention to get input from users and see a bigger picture. One of the points in that blog is that if you can't present your idea in a clear concise way, maybe you didn't really think much about it.

On top of that I can only add that the existing set of plug-ins and scripts deserves a long overdue refresh. I think we could smarten up the default package.

Alexandre Prokoudine http://libregraphicsworld.org

On Tue, 2011-11-29 at 12:32 +0100, Marco Ciampa wrote:

See: http://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy

And think about this: it is the sole 40 years old OS working (well) out there. There should be a reason.

TBH, Unix is only a family of operating systems, not even with the oldest heritage, or the best compatibility. Take IBM OS/360...z/OS where you can still run programs from the mid-60s on a mainframe of today, both older and more compatible. Not that it would be of any use to a casual user of image manipulation software ;-).

Nils

On Tue, 2011-11-29 at 16:03 +0400, Alexandre Prokoudine wrote:

On top of that I can only add that the existing set of plug-ins and scripts deserves a long overdue refresh. I think we could smarten up the default package.

Do you mean "trim down" ;-)? In that case, we need a way for users to easily find and (eventually build) and install them... integrated with distributions ideally. This would ask too much of the current registry.

Nils

On Tue, Nov 29, 2011 at 6:05 PM, Nils Philippsen wrote:

On Tue, 2011-11-29 at 16:03 +0400, Alexandre Prokoudine wrote:

On top of that I can only add that the existing set of plug-ins and scripts deserves a long overdue refresh. I think we could smarten up the default package.

Do you mean "trim down" ;-)?

Both refresh and trim down. We ship tons of scripts that generate art that looked a bit weird even for late 90s, but we also do not provide good enough features for e.g. handling guides [1]. I'd say we need to analyze what needs to go, what needs refactoring and what's missing.

In that case, we need a way for users to easily find and (eventually build) and install them... integrated with distributions ideally. This would ask too much of the current registry.

An easy way to install extensions is in plans since dawn of times :) We even had a failed GSoC project for that in 2005 or so :)

[1] http://bit.ly/sLnD3b

Alexandre Prokoudine http://libregraphicsworld.org

I see there is a lot of concern regarding the placement of plugins in menus, the menu hierarchy...
Its true that the menus contribute greatly to the UI and UX...

So why not leave it to the user to decide how they want their menus? We could implement something like chrome's bookmark manager [1] where one can just drag and drop the plugin from the current-menu to the target--menu
(where the 'menu's refer to the folders in the bookmark mgr and the plugins refer to the bookmarks).

So we could call this a '*menu-manager*'. I've been using GIMP for 4 years now... and I'd love to have such a feature! what do you think?

[1]
http://www.blogcdn.com/downloadsquad.switched.com/media/2008/11/chrome-bookmark-manager.jpg

I see there is a lot of concern regarding the placement of plugins in menus, the menu hierarchy...
Its true that the menus contribute greatly to the UI and UX...

So why not leave it to the user to decide how they want their menus? We could implement something like chrome's bookmark manager [1] where one can just drag and drop the plugin from the current-menu to the target--menu
(where the 'menu's refer to the folders in the bookmark mgr and the plugins refer to the bookmarks).

So we could call this a '*menu-manager*'. I've been using GIMP for 4 years now... and I'd love to have such a feature! what do you think?

[1]
http://www.blogcdn.com/downloadsquad.switched.com/media/2008/11/chrome-bookmark-manager.jpg

On Tue, Nov 29, 2011 at 8:05 PM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

On Tue, Nov 29, 2011 at 6:05 PM, Nils Philippsen wrote:

On Tue, 2011-11-29 at 16:03 +0400, Alexandre Prokoudine wrote:

On top of that I can only add that the existing set of plug-ins and scripts deserves a long overdue refresh. I think we could smarten up the default package.

Do you mean "trim down" ;-)?

Both refresh and trim down. We ship tons of scripts that generate art that looked a bit weird even for late 90s, but we also do not provide good enough features for e.g. handling guides [1]. I'd say we need to analyze what needs to go, what needs refactoring and what's missing.

In that case, we need a way for users to easily find and (eventually build) and install them... integrated with distributions ideally. This would ask too much of the current registry.

An easy way to install extensions is in plans since dawn of times :) We even had a failed GSoC project for that in 2005 or so :)

[1] http://bit.ly/sLnD3b

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

On Tue, Nov 29, 2011 at 8:18 PM, Srihari Sriraman wrote:

So why not leave it to the user to decide how they want their menus?

So that GIMP on someone else's computer becomes unusable for you? :)

Alexandre Prokoudine http://libregraphicsworld.org

On 11/29/11 18:48, Alexandre Prokoudine wrote:

On Tue, Nov 29, 2011 at 8:18 PM, Srihari Sriraman wrote:

So why not leave it to the user to decide how they want their menus?

So that GIMP on someone else's computer becomes unusable for you? :)

I'd rather that than it be "unusable" on mine.

Is firefox unusable on on someone else's machine because I have my own bookmarks.

Is Gimp unusable on someone else's machine because I have set up my own short cuts.

Please consider suggestions others make rather than being so dismissive.

The idea seemed a lot better than the current jungle of options and filters.

regards, gg

Alexandre Prokoudine
http://libregraphicsworld.org

On Tue, Nov 29, 2011 at 10:08 PM, wrote:

Please consider suggestions others make rather than being so dismissive.

In my experience "leave it to the user" kind of attitude regarding essential features leads to poor usability way too often. Thus before we introduce some sort of editor to the existing XML menu structure personally I'd really like to make sure that we did our best to make the defaults most reasonable. Agreed? :)

Alexandre Prokoudine http://libregraphicsworld.org

On Tue, Nov 29, 2011 at 6:43 PM, Alexandre Prokoudine wrote:

On Tue, Nov 29, 2011 at 10:08 PM,

On Wed, Nov 30, 2011 at 1:29 AM,

ok...
If the user rearranges his Menu badly, then maybe we could give a "*reset menu*" option?
but ya, maybe we can't trust users with their menus... they might get lost... :)
I've got another idea...

How about a *Gnome-Do* or a *Launchy *for GIMP?

- Alt+Space could bring up a small window just like in [1]. - The user then types his keyword, and that would bring a dropdown of all the matched plugins

(Example: typing *blur *could drop down all blur-related plugins -or- typing *canvas *could dropdown all canvas related plugins)

- The user uses arrow keys to choose and hits Enter to run plugin. (Or just hit Enter for the 1st suggestion) - The suggestions would be adaptive, i.e, more frequently used plugins appear higher in the drop-down
- The search could span the plugin-name, menu-position and the description

(Example: typing *logo *could dropdown 3DOutline, and so on)

This way, the placement of plugins in the menu could remain unchanged, and the user still gets to his plugin easily. I seldom use the Applications Menu in my Ubuntu. I don even know where the application is in the menu. I just Win+Space! People using Gnome-Do or something similar can easily relate to this suggestion.

[1] http://peterstuifzand.nl/images/gnome-do-screenshot.png

On Wed, Nov 30, 2011 at 3:26 AM, Alexandre Prokoudine < alexandre.prokoudine@gmail.com> wrote:

On Wed, Nov 30, 2011 at 1:29 AM, Øyvind Kolås wrote:

A change that might make things better for all users, is an ability to search the menus/filters as an efficient part of a workflow.

And we had a failed GSoC project for that too :)

[key
combo][gauss]][enter] to start doing a gaussian blur would make at least me much happier than permitting manual menu management.

That kinda reminds me Blender :)

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
                  *

On 11-11-30 12:12 , Srihari Sriraman wrote:

ok...
If the user rearranges his Menu badly, then maybe we could give a "*reset menu*" option?
but ya, maybe we can't trust users with their menus... they might get lost... :)
I've got another idea...

How about a *Gnome-Do* or a *Launchy *for GIMP?

* Alt+Space could bring up a small window just like in [1]. * The user then types his keyword, and that would bring a dropdown of all the matched plugins

(Example: typing /blur /could drop down all blur-related plugins -or- typing /canvas /could dropdown all canvas related plugins)

* The user uses arrow keys to choose and hits Enter to run plugin. (Or just hit Enter for the 1st suggestion) * The suggestions would be adaptive, i.e, more frequently used plugins appear higher in the drop-down * The search could span the plugin-name, menu-position and the description

(Example: typing /logo /could dropdown 3DOutline, and so on)

This way, the placement of plugins in the menu could remain unchanged, and the user still gets to his plugin easily. I seldom use the Applications Menu in my Ubuntu. I don even know where the application is in the menu. I just Win+Space! People using Gnome-Do or something similar can easily relate to this suggestion.

[1] http://peterstuifzand.nl/images/gnome-do-screenshot.png

Hi Srihari,

Yes, that's how Blender does it, but it's more than a search bar. You can use it for almost any command Blender can do via 'conventional' GUI. Anyone interested might want to check out the theory behind, and the implementation of, Aza Raskin's 'Enso'. AFAIK, that was the first implementation of the idea. It is system wide, customizable, and if I am not wrong, context aware.
...
(I can not connect why would typing /'logo'/ result in 3DOutline? But don't fret. I can not connect great many things...)

...

This is an interesting approach. Perhaps the scope of it is even beyond GIMP and maybe should have a dedicated place for discussion. Hybrids between the command line and GUI can be very powerful, but I do have a couple of boring questions.

- How would another gnome-do or launchy-like utility sit in user's understanding of the overall computer environment? - Should this utility be a part of 'standard issue' GIMP or be something separate, a matter of user's preference? - Will it ask for some 'compliance' from GIMP and plugin developers? - Would it accept any syntax/expressions? (e.g.: "select inverse, gaussian blur 30px", allowing me to avoid ever increasing GUI creativity of plugin developers) ;)

A wide-eyed child in me fantasizes this workflow: For the reasons of focus and sanity of the respective project's developers, I imagine a separately developed 'thingy'. This 'thingy' accepts installable 'command' bundles for various applications. The bundles are made by users and collected at thingybundles.org. Currently, I have GIMP, Inkscape, Libre Office and Scribus command bundles. Thanks to command bundles, 'thingy' talks to applications, providing me, the majestic user, a relatively consistent way to do an awful lot (and still suck at it)... Someone really smart even provided 'thingy' with a command thesaurus of sorts. Thesaurus allows me some freedom of expression when typing, so to say. 'Move', 'translate', 'grab'? It's all the same... You get the point.

For example, to scale, all I have to do when using 'thingy' is make a selection in either of the aforementioned applications and just type 'scale' which will, in turn, put me in scaling mode for that, currently active application. For the 'thingy', you see, is context aware, too. ;). Since I rely on 'thingy' in my everyday workflow, I turned off most of the application's panels and enjoy more 'screen'. When I really need those GUI elements, 'thingy' will show them for me and hide them later.

The wide-eyed adolescent shouts: Hell yeah! Give it cross application scripting ability, too! So I can type: 'Gramma's party', which will import all the photos from gramma's birthday, process them in GIMP or Darktable using my personal 'Trip-o-vision-kolorz' megaplugin that granny likes so much, place them in Scribus template, export PDF, print it and call me on the phone when it's done. Oh yes, and an integrated command bundle editor and manager would be sweet, too! ...
The 'real' me wonders by now, should I just stop and go and see a specialist... :)
...
Almost forgot. Frequency based adaptive lists are a disaster. MS Office? Anyone?

Alex

On 11/29/2011 10:56 PM, Alexandre Prokoudine wrote:

[key

combo][gauss]][enter] to start doing a gaussian blur would make at least me much happier than permitting manual menu management.

That kinda reminds me Blender :)

Another example would be Rhinocerus 3d: http://www.youtube.com/watch?v=hJVrUqytvhA

The interesting parts starts at 0:20, until toolbars are discussed, then from 4:10 on.

Another example would be Rhinocerus 3d: http://www.youtube.com/watch?**v=hJVrUqytvhA The interesting parts starts at 0:20, until toolbars are discussed, then from 4:10 on.

I would say 4.:20... this is more or less what I was suggesting, but perhaps a little more, perhaps a little less.

- Typing 'L' would bring up all the plugins or commands that start with L

(I can not connect why would typing *'logo'* result in 3DOutline?

'*Logo*' is a part of the *description *of the 3DOutline plugin. I might not know there is a plugin called 3DOutline, but this command bar would suggest it to me.

- Suggestions would include searches from plugin/tool name *and*description

How would another gnome-do or launchy-like utility sit in user's

understanding of the overall computer environment?

- It would be just a command-line just as in Rhino

Should this utility be a part of 'standard issue' GIMP or be something

separate, a matter of user's preference?

- This command line could be a plugin in itself, standard issue/user preference would be a wider debate :)

- Will it ask for some 'compliance' from GIMP and plugin developers?

- No, because the plugin will just use the name and description of all currently installed plugins and tools

- Would it accept any syntax/expressions? (e.g.: "select inverse, gaussian

blur 30px", allowing me to avoid ever increasing GUI creativity of plugin developers) ;)

- No... IMHO, it would be just a plugin/tool selector, so the result would just be running a plugin or selecting a tool. (So in this view, it is not a *command *bar, just a *selector *bar) - Like 'thingy', this too would have to be context aware... like suggest layer tools/plugins only when a layer is selected. But again, maybe the context can be deducted from the existing plugin/tool information. - The suggestion dropdown, could include a subtitle, with the description of the tool or plugin, with the searched text highlighted.

The scope of this would be very well within GIMP :) *
*
*Bottom-line,*
*I just would love to reduce the pain to go through all the menus searching through everything for what i want.*

On 11/30/11 14:56, Srihari Sriraman wrote:

*

- Would it accept any syntax/expressions? (e.g.: "select inverse, gaussian blur 30px", allowing me to avoid ever increasing GUI creativity of plugin developers) ;)

* No... IMHO, it would be just a plugin/tool selector, so the result would just be running a plugin or selecting a tool. (So in this view, it is not a *command *bar, just a *selector *bar) * Like 'thingy', this too would have to be context aware... like suggest layer tools/plugins only when a layer is selected. But again, maybe the context can be deducted from the existing plugin/tool information.
* The suggestion dropdown, could include a subtitle, with the description of the tool or plugin, with the searched text highlighted.

The scope of this would be very well within GIMP :) *
*
/Bottom-line,/
/I just would love to reduce the pain to go through all the menus searching through everything for what i want./ --

I feel your pain ! ;)

however, extending the concept to offer a command execution seems both a logical extension of the idea and damn useful thing.

GUI is fine for finding your way around but it quickly becomes labourious once you know what you want to do. Setting up some short-cuts can help.

For those who can not type without searching for every key on the key board and checking on the screen whether they got it right, it's wonderful.

As someone who can type , the idea of hitting one key to bring up such a tool and typing : exec gaussian blur 30px " , "resize 50 pc" or whatever is very appealing.

I often use gimp gui to find out what settings I need then repeat on a small group of similar images. It's not enough of a batch job to work out imagemagick settings and run as batch process, but some short hand way to do it in gimp would be great.

=======

The standard set of plugins in good to let new users see what is possible and to give ideas. After you have found the 5% that are likely to be useful, it becomes very cumbersome and requires far too much interaction.

while some clever UI design tricks may ease the pain, I don't think it will be able to do more without shackling the user.

Since menus are xml based providing some editing facility should be quick and efficient to implement. Allowing total restructuring of the main menus would probalby be a step too far but earlier mention idea of restructuring the plug-ins in a similar way to browser bookmarks seems to be a good one.

And no, this would not make Gimp unusable on someone else's system it would just make it as unusable as gimp currently is out of the box.

m2c

/gg

*
*
*Regards, *
*Srihari Sriraman *

On Tue, Nov 29, 2011 at 9:29 PM,

On Wed, 30 Nov 2011 15:22:39 +0100, gg@catking.net wrote:

/Bottom-line,/
/I just would love to reduce the pain to go through all the menus searching through everything for what i want./

I feel your pain ! ;)

however, extending the concept to offer a command execution seems both a logical extension of the idea and damn useful thing.

[...]

Hopefully searching the name of a menu positon will be in whatever language the UI is used, not the English hard coded name :)

Cristi

Just adding to the bookmark-manager-idea...

If using GIMP on another system is so vital, we could have an "*Export/Import menu*" similar to "*Export/Import Bookmarks *".
This could help in good portability... considering it would be just an xml import/export...

2011/11/30 Cristian Secară

On Wed, 30 Nov 2011 15:22:39 +0100, gg@catking.net wrote:

/Bottom-line,/
/I just would love to reduce the pain to go through all the menus searching through everything for what i want./

I feel your pain ! ;)

however, extending the concept to offer a command execution seems both a logical extension of the idea and damn useful thing.

[...]

Hopefully searching the name of a menu positon will be in whatever language the UI is used, not the English hard coded name :)

Cristi

-- Cristian Secară
http://www.secarica.ro
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

*
*
*Regards,
                      *
*Srihari Sriraman
                  *

Some time ago I uploaded GIMPScripter plugin to the GIMP registry. It somewhat allowed what is discussed in this thread: ability to browse the GIMP menus, choose a sequence, enter or defer parameters, and execute the sequence. It still is a prototype, not finished. It is written in Python. (It didn't allow searching the menus for a string but would be an easy enhancement.)

One implementation problem was parsing and recreating a shadow of the GIMP menu tree. As I recall, I didn't understand the GIMP internals so I just recreated a small sample of the specification for the GIMP menus. Another well known problem is that the default parameters values for many commands and plugins are not available.

The notion of this thread (an alternative or user-chosen view of the GIMP commands) is also related to the PDB Browser, the Plugin Browser, the keyboard shortcuts dialog, various batch processor plugins, and to a GUI to a GEGL graph of commands.

Meta-programming of the GUI (which is really not essential to GIMP) can already be done in plugins, to some extent. We need concrete proposals how to change GIMP to make meta-programming from plugins easier and better, and more prototype demonstrations proving the utility to users.

Hi!

Based on what I picked up from the ideas so far in this thread, and if I understood them correctly: Although 'selector bar' sounds simpler, Rhino/blender like command bar still tickles my fancy a bit more than selector bar.
1) command bar could perform comparably to selector bar + the commands. 2) the idea of 'selector bar' feels like a fix for a fix.; i.e. historically, menus have been introduced as GUI fix for overcrowded main bar, now, 'selector' bar helps us go thru overcrowded menus. Doesn't sound like a solution.
3) 'selector bar' presumes that users use lots of plugins. Therefore, selector bar's usefulness is questionable in cases with no or few plugins. ...

My 2 yen while blowing my own horn, all at the same time: If people happen to like this new mode of interaction in GIMP, they might like to use it in other applications, too. Please excuse me for I am ignorant of how GIMP and other applications' guts really-really work, but I like to imagine that there are hooks in GIMP etc. that this tool could pull 'from the outside'. In that case, we would have to tell 'thingy' where the hooks in the respective applications are. If this is possible, this tool might become relevant for more than just GIMP people. Using it could feel almost like pulling strings to achieve some effect.
(Maybe those are imaginary hooks... will try to learn more how stuff works, I promise :)

If this is true, then organizationally, it would be convenient to run it as an independent, modular project maintained by a community of interested developers/reasonably skilled users where it won't get in the way of stuff that matters. (I think we all like to see the next version of ____!) Perhaps an online tool to contribute command dictionaries and thesauri? A simplish way to indicate/correlate equivalent/similar basic commands across the applications? Something where we could add commands for any future software?

What's so cool about it? - People choose to use it or not. Either way it won't obstruct their workflow.
- People choose to maintain it or not. Either way it won't obstruct the development of the applications it serves. - It presents only 'another way to do things'. nothing more. All GUI improvement efforts currently on the way in GIMP are very, very much crucially important.
- Nice people from GIMP, Inkscape, etc. do not have to waste a cycle implementing 'another hip thing that could fail' + the original modes of interaction with respective software stay intact. - Might become another way to integrate various software on a human level.

Famous last words? 'What could go wrong?' - If this idea never gets articulated enough, it won't fly. Has to be as tight as... something really tight.
- There might be actions impossible to achieve using 'strings'. Would this fact break the UI consistency?
- The localizations will never be of consistent quality. - GIMP, Inkscape, etc. updates might break the 'strings'? - This suggestion might just be a misinformed megalomaniac's wishful thinking. :)
...

Greetings!

Alex

On 11-12-01 1:40 , Cristian Secară wrote:

On Wed, 30 Nov 2011 15:22:39 +0100,gg@catking.net wrote:

Hopefully searching the name of a menu positon will be in whatever language the UI is used, not the English hard coded name :)

Cristi

+1
Internationalization and localization in this position is crucial and would help many.
I am always trying to think how to disperse, spread and delegate potential workload away, away from girls and guys that create core code magic. Internationalization and localization are especially strong candidates for this delegation, I think. If this makes sense, how can we setup, initiate and maintain this diverse internationalization effort? Hypothetically...
I guess the same way localization is done now? Any ideas? ...

Thanks to the previous convincing mails, I'm slowly blending into the idea of *selection+command* bar... I think this would be lovely! [I'm wondering if I should make this my first attempt at writing a GIMP plugin :) ]

Um... this might not be much, but if the selection+command bar just searches through existing plugin/tools data,
then internationalization shouldn't be a problem as along as the plugin/tool data itself is internationalized... no?

ps: I think we should give this selection+command bar a name... even if its just for this discussion :p
How about just... "Bar"... like... "The GIMP Bar"

2011/12/1 Aleksandar Kovač

On 11-12-01 1:40 , Cristian Secară wrote:

On Wed, 30 Nov 2011 15:22:39 +0100,gg@catking.net wrote:

Hopefully searching the name of a menu positon will be in whatever language the UI is used, not the English hard coded name :)

Cristi

+1
Internationalization and localization in this position is crucial and would help many.
I am always trying to think how to disperse, spread and delegate potential workload away, away from girls and guys that create core code magic. Internationalization and localization are especially strong candidates for this delegation, I think. If this makes sense, how can we setup, initiate and maintain this diverse internationalization effort? Hypothetically... I guess the same way localization is done now? Any ideas? ...

______________________________**_________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/**listinfo/gimp-developer-list

*
*
*Regards,
                      *
*Srihari Sriraman
                  *

2011/12/1 Aleksandar Kovač wrote:

2) the idea of 'selector bar' feels like a fix for a fix.; i.e. historically, menus have been introduced as GUI fix for overcrowded main bar, now, 'selector' bar helps us go thru overcrowded menus. Doesn't sound like a solution.

True, but computers in general are just a fix for a fix a fix for a fix for the fact that unary numbers are really hard to work with. More powerful tools are required to manage things effectively as the number of things to manage increases.

Rockwalrus

Hello Aleksandar,

Am 30.11.2011 09:10, schrieb Aleksandar Kovac:

Anyone interested might want to check out the theory behind, and the implementation of, Aza Raskin's 'Enso'. AFAIK, that was the first implementation of the idea. It is system wide, customizable, and if I am not wrong, context aware.

also worth mentioning: ubiquity, a commandline for firefox: https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_Tutorial Also by Aza Raskin.

BR,
yahvuu

On 11-12-05 8:08 , yahvuu wrote:

Hello Aleksandar,

Am 30.11.2011 09:10, schrieb Aleksandar Kovac:

Anyone interested might want to check out the theory behind, and the implementation of, Aza Raskin's 'Enso'. AFAIK, that was the first implementation of the idea. It is system wide, customizable, and if I am not wrong, context aware.

also worth mentioning: ubiquity, a commandline for firefox: https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_Tutorial Also by Aza Raskin.

BR,
yahvuu

Ah Yes! Thank you yahvuu!
Excellent explanations and images on the ubiquity website! Once more: (if you have the time and/or interest) https://wiki.mozilla.org/Labs/Ubiquity/Latest_Ubiquity_User_Tutorial

Thanks!

Alex

On 11-12-02 3:44 , Nathan Summers wrote:

2011/12/1 Aleksandar Kovač wrote:

2) the idea of 'selector bar' feels like a fix for a fix.; i.e. historically, menus have been introduced as GUI fix for overcrowded main bar, now, 'selector' bar helps us go thru overcrowded menus. Doesn't sound like a solution.

True, but computers in general are just a fix for a fix a fix for a fix for the fact that unary numbers are really hard to work with. More powerful tools are required to manage things effectively as the number of things to manage increases.

Rockwalrus

And I did failed to write above that 'a fix for a fix' relates to 'a fix within windowed GUI paradigm'. Sorry 'bout that!

...

Yes. (sad but) true.... a fix for a fix for a fix... and the ever increasing number of things to manage gave me dismanagement blues.:)... beh. This entropy of the things to manage is human's doing. Sometimes, instead of adding a new coat of complexity (or re-thinking the whole thing) it is worthwhile and possible to back-trace occasionally and present things in a way less complex... or so I like to believe. (Hegel would be proud of me :)))
Of course, only if it works better and only if it doesn't ruin the fun for people.

Too many words for a simple concept :). Cleaning up the room? :) Science uses something like 'more elegant theory'. 'More accessible'? or like Alexandre said - 'smartened-up'.Dunno.

...

Unary. Easy to write. :)

Alex