Re: [Gimp-developer] Re: Menus, keybinding et al, first draft
On , 17 Feb 2002, Rebecca J. Walter wrote: As any looked into how all this will work with different window managers? What window managers grab what keys and can the window managers easily be configured to use alt if gimp isn't using it? It is important to check this since we will otherwise end up with lots of whiny users who can't figure out why thiings aren't happening like expected. I'd like to whine: I use ALT+mouse1 *inside* a window to quickly move it somewhere else on the desktop, therefore any ALT clicking is going to annoy me severly. Could someone post a summary of the differences between the current setup and the proposed new setup? Austin (Sorry to dig up old emails, but I've only just got back from a week's holiday without Internet access - joy!) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Menus, keybinding et al, first draft
On Fri, 22 Feb 2002 12:48:44 +, Austin Donnelly [EMAIL PROTECTED] wrote: On , 17 Feb 2002, Rebecca J. Walter wrote: As any looked into how all this will work with different window managers? What window managers grab what keys and can the window managers easily be configured to use alt if gimp isn't using it? I'd like to whine: I use ALT+mouse1 *inside* a window to quickly move it somewhere else on the desktop, therefore any ALT clicking is going to annoy me severly. Well, then you should reconfigure your WM. ;-) Alt+mouse1 is already used by the current version of the Gimp to move a selection outline without moving its contents. I do not think that we should change that because this is a useful feature. If this feature is not so important for you, then you can of course let your WM grab the Alt+mouse1 combination in your own setup. In general, I think that single modifier+key or +mouse1 should be reserved for the applications (for all modifiers), so the Gimp should make use of these combinations if needed. The WMs should only use some combinations of two modifiers +key or +mouse. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Menus, keybinding et al, first draft
As any looked into how all this will work with different window managers? What window managers grab what keys and can the window managers easily be configured to use alt if gimp isn't using it? It is important to check this since we will otherwise end up with lots of whiny users who can't figure out why thiings aren't happening like expected. Also we will need a howto on the web site about making the different window managers play nice with gimp. Also, are there other apps that use shortcuts like we do that might be using a different set of shift-alt-ctrl keys? Just thinking it would be good to be consistent with what other apps are doing so users don't have to change their window managers back and forth when switching apps. (Or.. horror of horrors.. be unable to use both at once because of this problem) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Menus, keybinding et al, first draft
Hi, On Sun, Feb 17, 2002 at 12:19:46PM +0100, Rebecca J. Walter wrote: As any looked into how all this will work with different window managers? What window managers grab what keys and can the window managers easily be configured to use alt if gimp isn't using it? It is important to check this since we will otherwise end up with lots of whiny users who can't figure out why thiings aren't happening like expected. In my opinion it is impossible to make sure that we do not collide with window manager shortcuts. They are far too different and far too configurable. I think it boils down to: Tell the user that there might be interferences with the window manager and that keys in GIMP can be configured dynamically. Also we will need a howto on the web site about making the different window managers play nice with gimp. That would be useful though. What would also be useful is to make _all_ keybindings in GIMP configurable (like SHIFT, CTRL, ALT etc.). So I would be able to assign Meta1 to GIMP-ALT and Meta2 to WindowManager-ALT. Also, are there other apps that use shortcuts like we do that might be using a different set of shift-alt-ctrl keys? Just thinking it would be good to be consistent with what other apps are doing so users don't have to change their window managers back and forth when switching apps. As far as I know, there are no wide-spread shortcuts involving two modifier keys. It boils down to something like CTRL-Q: Quit, CTRL-W: Close window, CTRL-N: New - very basic stuff. CTRL-ALT and similar bindings are seldomly used by applications and often used by window managers. Bye, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ 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 0939.22 +0100): Something I forget: note that by this definition, the Text Tool isn't a tool either, at least when using Dynamic Text, since the placement of the text depends only on the option in the dialog box. I think Text should be a tool, and, unless otherwise specified in the dialog box, the text should appear in the image at the location that was clicked by the user. This also prevents the problem of having to scroll around to find the text you just made when you are zoomed in. If the text were at the point where you clicked (which is ofcourse within the viewport) you could just finetune it and go on. Text tool is going to be changed, it will be a mix of current gimp freetype (quality) and gdyntext (separate layer, parasite). It should add the layer where the user clicked. GSR ___ 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 0659.48 +0100):
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.
And in non US, maybe the contrary. ;]
Guess why I hate of symbols, and try to find people with other
keyboards. Letters are the few thing everyone has (and with Dvorak,
Azerty and others, some keycombos can be weird).
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
{} ).
Could be an option. Of course, GTK+ must first solve the problems with
keybindings, cos I used some combos that do not work (input as blank
as does nothing), and others are intercepted wrongly (I have to use
Shift+0 for =, and that fails, and if I try to reset it, I get
Shift+=, which is like saying Shift+Shift+0).
GSR
___
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 0929.47 +0100): Well done! I still have some comments though, see below. Thanks, that is why I post. :] I think we need to think very hard about Plug-ins, Filters, Script-Fu, and Tools. Another I forget: no more differences about script-fu, pygimp, perl-fu, C or whatever. If it is under Filter, it is a filter and must behave like any other. I'd like to define a Tool as something that changes the image depending on the coordinates sent by the pointer device. This means that Flip and Transform (which always work on the whole image or the whole selection) aren't tools at all. Things like the Image-Color-* functions, which seem to be implemented as Tools in 1.2, aren't tools either. Interesting definition. Note the implementation is one thing, and you are talking about menu, in this case they are in the right place (well, the one I posted, cos they are Layer level, not Image). I'm not quite sure what to do with the remaining functions. I don't think the user should be able to see the difference between Plug-ins, Script-Fu scripts, and Perl scripts in the interface. That No, they should not. We need a definition for tool, filter and so on. Your tool seems fine, at least to begin with. means that the Xtns-Script-Fu menu entry should go. Throwing them Perl script register under Filter or other places, like C based functions, and that is the way to go with script-fus too. all in one big menu under Filters may be overkill though. I'm open to suggestions for splitting this up (in a way that is based on the function of the plugins) into smaller more manageable parts. By kind, like is now, we have to create the review kind list (starting with current classification, to avoid starting from scratch). Thirdly, we now have three different Transform options. I know that Unix gives you enough rope to shoot yourself in the foot, but with this you can't see the trees for the forest. Why not just a single transform tool, and an option there to do the whole image or just the current layer? Or better even, allow the selection of multiple layers in the layers dialog box, so that you can have finer-grained control over what you are changing and what not. Transform menu entries do some basics and in some cases pretty hardcoded (rotate 90*n degrees), and transform tool is more like the tool definition you use, it uses the mouse, and is more free. Lastly, I think we should look at the names of the functions in relation to their locations in the menu. In GIMP 1.2, there is a function Image-Filters-Color-Map to Gradient..., which is rather confusing. Thing is, there's also an Image-Filters-Map submenu, and I always end up looking for Map to Gradient in the Map submenu. Function-wise I think this is a logical way to organise things, but linguistically it's confusing. I left the Filters one for next step, cos it is tricky, have to add all the scripts, move things around, etc. I wanted to have the basic structure and the other submenus, not the Filter area. GSR ___ 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: - Image/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
