36

Are you sure it wouldn't mess with something else? Like sidebars / toolbars / etc. Some of them are draggable by themselves.

Menu bar probably is fine unless it can be moved by itself. There are some apps like that though they probably don't use standard menu bar anyway.

Tenno Seremel wrote:

Madman wrote:Then you should have a problem with moving windows from the title bar and by alt-clicking. Two ways to do the same thing. isn't that duplication?

Some windows do not have title bars. It happens.

The logical conclusion, then, is to get rid of moving via the title bar and only ever use alt-click. There. One way to do one thing. Problem solved.

Tenno Seremel wrote:Are you sure it wouldn't mess with something else? Like sidebars / toolbars / etc. Some of them are draggable by themselves.

Menu bar probably is fine unless it can be moved by itself. There are some apps like that though they probably don't use standard menu bar anyway.

That's the tricky one, because it depends on how we treat it.

The best method I can think of involves a mask, and would be on the toolkit level.

1. We would define which widgets are considered "draggable", like frames, menubars, statusbars, separators (buttons?), etc. Any widgets we don't define, are assumed not draggable (scrollbars, lists, etc).

2. We would build a "dragging-mask" using areas the toolkit defines as actual chrome or chrome-like; chrome-like might be video or a static image, not-chrome-like is anything undefined.

3. We punch holes into our dragging mask anywhere non-draggable widgets are. We would just use the rectangular width/height of most widgets, we don't need to trace their exact shape. To be safe, we might punch holes slightly bigger than the widgets so users have room to breathe. Because widgets don't often move, we would only need to calculate the drag-mask on resize or when the program re-draws widgets.

Once we have a dragging-mask, it's just a matter of setting some sort of standard on how the window manager will receive the dragging mask. If the window manager doesn't receive the mask (legacy programs, non-supported platforms, etc) it just assumes there are no draggable areas. We could probably use something like Dbus to send masks to the WM. The WM might just start with an empty dragging mask until it receives any new ones.

The mask would probably just be a black & white pixmap calculated the same time the window content is actually drawn. Or, an array of rectangles defining draggable and non-draggable areas; this could be more efficient but less accurate.

If we go with a standard, there's no reason GTK, XUL and even WINE based programs can't be patched on the toolkit level. Other window-managers with programs using patched toolkits could also use the masks, Compiz, Metacity, anything could probably reap the benefits.

Well, I guess I'll just change my vote to neutral :}

It already works in Bespin and i think it's a nice feature.

This is available in oxygen in 4.5, although it is a little buggy.

... Which is the point of a beta/first implementation. At least it's there, which means it can be fixed.

Yes, I understand that, I just thought a warning was warranted.

Just went to SC 4.5b, indeed it is working for native KDE apps. Being said though, Firefox and GTK apps don't seem to be playing in the same band on this one, obviously.

Do you think it might be better to do a new idea specifically for GTK/firefox support, a bug-report, or move this back to the ideapile?

Either way, it seems to be working quite excellently on the native apps! It feels good, now I need to bug-report myself because I still use the titlebar, fwahah!

I'm not sure it is possible for gnome apps, I would suspect that has to be built into gnome. I don't think KDE has any real control over it, in fact I don't think KDE even has a way to identify if the proper area is being dragged in a gnome app to begin with. But I am not certain.