On Mon, 2006-10-09 at 21:54 -0400, Philip Ganchev wrote: > Not all content inside a window should be draggable, only inactive > content, like the part of the menu bar that is not taken up by the > menu, and spece on a panel that is not taken up by active controls > like buttons, menus, lists, etc. Does the window manager have > knowledge about what part of the window content is a panel versus a > button? While, as others have said, moving the window around is normally in the purview of the window manager, GTK could do as you suggest. It is possible that GTK could capture mouse events over inactive areas and if the user tries to drag an inactive area, GTK can send X11 hints that the window is to be moved (bypassing the window manager). I've actually implemented this for a special program that displayed on the old KDE login window where there was no window manager present. I made a special area in the GTK window that I captured drag events and used those to move the window. XMMS does this too, as its windows are not decorated (and thus moved) by the window manager at all. The real question is, should GTK do this? I would far rather favor an approach where a modifier key plus a mouse drag moves the window. It's more consistent this way and less confusing to the end user. On Gnome and Metacity, this is already accomplished by alt-click dragging. There is one major problem with getting GTK to do this anyways. That is that only widgets that receive events actually have X windows capable of receiving mouse events. So to do this at the GTK level would involve some re-engineering of how GTK uses GDK windows (which wrap X windows). It's just not worth it. Also no other widget set does this either (not even normal Aqua windows). > there is at least 1 window manager that implements each model. > > In popular window managers like KWin, Sawfish, Metacity and others, > Alt+Button1 starts moving the window by default. I was talking about > using *only* the mouse for this. In some applications, like Real > Player and iTunes, clicking on an area that is not an active widget > (like a button) and dragging, drags the window. I would think that > this has to do with the tool kit those applications use. Personally I think we should leave this as it is. There are far more important things in GTK that deserve the developers attention. Things that will help GTK to become faster, more flexible, and more powerful. (Maybe a file dialog box that doesn't frustrate people? :) > > It is considerably more convenient for users who use the mouse a lot, > as well as for disabled users. GTK already has a very extensible accessibility framework. You should be able to use a well-designed GTK app without a mouse at all, which would be more appropriate for many disabled users (the ones I know anyway). And for those that use the mouse a lot, alt-click is fast and doesn't require any hand movements on the part of your left hand. > _______________________________________________ > gtk-list mailing list > gtk-list@xxxxxxxxx > http://mail.gnome.org/mailman/listinfo/gtk-list > _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
