Re: [Gimp-developer] Menus, keybinding et al, first draft
On Sat, 16 Feb 2002, Guillermo S. Romero / Familia Romero wrote: >Zoom In + [Yes, changed, a bit more logical, no?] >Zoom Out- If you have an US keyboard you'll notice that while the minus "-" is immediatly accessible, the plus "+" is obtained by pressing Shift + "=". I think that "+"/"=" it's a faster keybinding for an US-keyboard layout user. What about of a bit "nationalized" keyboard layout, they should be selected through the Options menu and NOT by using the locale, just because it's possbile that someone uses a keyboard layout different from the specified locale (just think a programmer often needing "{}" ). Happy GIMPing, Marco -- //\/\ Marco (LM) Lamberto e-mail:lm(.)sunnyspot.org (replace '(.)' -> '@') The Sunny Spot - http://the.sunnyspot.org/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Menus, keybinding et al, first draft
[EMAIL PROTECTED] (2002-02-16 at 0006.34 +0100): > This is the doc I have now. Any comments? Suggestions? Fixes? I got some questions and suggestions on IRC, so to avoid forgetting and repetitions, I self reply: - /Layer is the same menu the will be used for MB3 in Layers dialog. That way you have same layout and same bindings, no more wrong duplication, but perfect one. Sorry for forgetting to write it, I thought but did not type, that was one of the basic ideas behind cleaning menu system. - I have to add Channel menu, and using the same principle that with Layer, share the menu, and so share keybindings and layout. But also share bindings with layers, otherwise it gets mad. Check next to see what and how. - I guess then we need a toggle key to move from Layer to Channel and back. Shift-Tab, ie, and check what does Ctrl-Tab for reasoning (did you know that one? I want it for channels too ;] ). And add new layer keybinding will be the same than add new channel, just change to channels to change the behaviour, like you do now with mouse. I just hope it does not get impossible due coding limitations (resync of changed bindings, ie). Quick example: Shift+Ctrl+N creates new layer or new channel depending if you are working in layers or channels. Branko and Simon talked about indicators for active layer or channel, I think the change key will suit nice with them. Branko should post something soon. Of course we can avoid key reuse, but then if we want bindings for things, we have to duplicate a lot (new, duplicate, delete, move, select, both for layer and channel, instead of one set of commands and operate in current context). Sven talked about drawables but we can not expect to push it to user level, as he pointed. So channels and layers must be separate, but I do not think too much if we do not want it to go out of control with keys. I think users can grasp the idea of channel or layer, and reuse keys, indicators would make even easier. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] UI suggestions
Here are two UI suggestions of me that we discussed at #gimp last night. Perhaps those who weren't there would like to give some input. 1) show selected layer/channel clearer 2) give user a sort of wizard at start-up Re: 1) It happens frequently to me that I paint in a layer or channel that I did not mean to paint in. If I had the LCP dialog open all the time, and on top all the time, and both layers and channels would be showed simultaneously, and the selection indicator for layer masks would not be so thin, this would not happen so often. But it does, and I don't like to waste screen estate on an extra dialog and I'd like to decide for myself which dialogs are on top. In other words, I think it would be handy if the GIMP would signal more clearly which layer or channel is currently active. Simon Budig suggested that the toolbox could contain two previews, one for the active image and one for the active layer or channel. I myself was thinking more along the lines of some text in the status bar (or a second status bar) in the image window that shows which layer or channel is active. These indicators could be optional of course. Re: 2) No, I do not want to dumb the GIMP down, but I want to make often used functions more accessible. The average user will do only a few of the many actions possible on start-up: - click away the tips dialog - open a file - browse images - start a new file - any more? These options could be beneath buttons in a dialog that appears on start-up instead of or along side the tool box. Sure, they only save some scrolling in a menu, but I believe these extra transactional costs become a burden to a user who has gotten to know the alternative method. This dialog should also be optional, so that power users will still keep that power feeling. WinZip does this very nicely (unfortunately, I do not know a Linux tool that gives you the choice between wizard and power access). -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Menus, keybinding et al, first draft
Hi: This is the doc I have now. Any comments? Suggestions? Fixes? Global ideas for this: - Use common keys first (letters, numbers, Shift, Control) - Use Alt but not alone, to allow _Foo with Alt+F, and not the first thing to use - Try to make rules, by mnemonics (C-q) or by pure tradition (C-z) - Use Shift for related (negative, special) cases if possible, and only for unrelated if not usage found - Remove rarely used keys to avoid getting crowded but as this is a pro tool, it is not the first thing I am going to do (those who are cut happy should check the number of combos in other pro tools and how many times they are used once the user is working and not playing) - Leave Fkeys for user (have fun with yellow notes ;] ) Global functions and keys: Hide and unhide extras Tab Show image menu Space [New, cool for tablets or in general] [ to allow menu invocation from ] [ keyboard, anytime ] Menus: > [Suggestion: make it a single root item like image menu?] [ That would be a bit rare, but would make all fit fine ] [ Could be named "Menu [>]" and give hint for "[>]" ] [ Yes, I am mad and I will get flamed by GUI purists but] [ think about the space we get, and the standarization, ] [ all menus would be vertical and "[>]" is taught ] File> New... Ctrl+N Open... Ctrl+O Open Recent> 1. filename [No keybindings, they change a lot, also see zooms] 2. filename ... n. filename --- Aquire> Screen Shot... Scan... --- Preferences --- Dialogs> Layer... --- QuitCtrl+Q Xtns> Module Browser... DB Browser... Plug-in Details... Unit Editor... Script-Fu> Web Browser> Tools> Default Colors D Swap Colors X --- Color PickerO Magnify Shift+M Measure Paint> Bucket Fill Shift+B Blend L Pencil Shift+P Paintbrush P Eraser Shift+E AirbrushA Clone C ConvolveV Ink K Dodge or Burn Shift+D Smudge Shift+S Selection> Rectangle R Ellipse E FreeF Fuzzy Z Bezier B Intelligent ScissorsI TextT Transform> MoveM Crop and Resize Shift+C Transform Shift+T FlipShift+F Dialogs> Layer, Channels and Paths Shift+Alt+L Tool Options... --- Brushes... Shift+Alt+B Patterns... Shift+Alt+P Gradients...Shift+Alt+G Palettes... Shift+Alt+P --- Input Devices... Device Status... --- Document Index... Error Console... Undo History... Help> Help... F1 Context Help... Shift+F1 Tip of the Day... About... > [Suggestion: tooltip "Image menu" when over "[>]"] File> New... Ctrl+N Open... Ctrl+O Revert... --- SaveCtrl+S Save As... Shift+Ctrl+S Save Copy As... --- Print...Ctrl+P Mail Image... --- Close Ctrl+W QuitCtrl+Q View> Zoom In + [Yes, changed, a bit more logical, no?] Zoom Out- Zoom Presets> [One linear vs one with mod. Still dunno which one ] [ One is more compact and provides some hints based ] [ in powers of 2] [ The second is more linear, not so easy to remember] [ or center hand, but linear] [ I vote for first, you always have key 1 located ] [ 5 would be a more complex, IMHO ] [ Some people want to numbers for brushes, so lets ] [ talk about it, I think brushes need more things ] 16:1
Re: [Gimp-developer] Changes between 1.2.2 and 1.2.3
Sven Neumann wrote: > very nicely done, Raphael. Perhaps we should make this list of changes > available somewhere (www.gimp.org)? Done. The list is now on the page that describes the stable version (http://www.gimp.org/stable_ver.html). It contains direct links to Bugzilla for the important bugs that have been fixed. -Raphael P.S.: I will be at http://www.fosdem.org/ for the next two days. If any GIMP developer plans to be there as well, I would be happy to say hello and offer you a (Belgian) beer. ;-) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer