Comments for …for the adult in you

Comment on The overview series: Drag and drop. You complain, we explain. by evacchi

evacchi — Tue, 08 Jul 2008 11:40:08 +0000

The first idea coming in mind was the same as Rémi’s: adding a timeout; probably that would still be hack-ish but it would be a nice workaround while waiting for a better solution.

Comment on The overview series: Drag and drop. You complain, we explain. by Elijah Newren

Elijah Newren — Mon, 16 Jun 2008 03:55:57 +0000

@Robert:

You seem to be talking about raising other windows when the mouse enters them during DND operations. That’s not really what this post was about (though Thomas did refer to it; see the bug 112308 reference near the end). And the problem in that case is that we don’t know when the mouse enters the window, due to how grabs & X11 work. (Though, yes, the Metisse folks apparently figured out something clever with the XFixes extension…)

The problem being discussed is about not raising windows on mouse button press, when that button press could begin a DND operation. (It would instead be raised on mouse button release, if no DND operation was started between the button press and button release.) The problem here is that the WM needs some kind of hint from the app about whether certain button press/release combos could start a DND operation and whether they actually did. That info isn’t currently available to the WM.

Comment on The overview series: Drag and drop. You complain, we explain. by Robert Pogson

Robert Pogson — Sun, 15 Jun 2008 13:34:47 +0000

Can drag-and-drop not be connected to the clipboard? If we define drag-and-drop as putting something into the clipboard and pasting it somewhere, then moving from one window to another should be easy: if the pointer enters a window with the left key of the mouse already active, be ready to paste from the clipboard that something. The action is separated from dragging a window around by the presence or absence of the left click on the window frame or the depression of Alt.

Just my opinion as a user. I do not code in C or anything that complex.

Comment on Justifying window titles by ᛏᚦ » Blog Archive » Thomas Thurman does not like cold meals because of broken applications

Thu, 12 Jun 2008 21:05:16 +0000

[…] be an obvious disproportionality. Something that struck me today was Mårten Woxberg mentioning the proliferation of Metacity themes; I think we see so many of them because they’re something relatively harmless and easy for […]

Comment on Justifying window titles by Thomas Thurman

Thomas Thurman — Thu, 12 Jun 2008 16:00:08 +0000

Mårten:
It’s funny though– if a person looked at, say, Crux and decided they wanted it red, and they made it red, they could either have done so by going through some rather complicated set of reconfigurations, in which case they couldn’t easily share it with their friends, or they could have made it so that they made a theme file, in which case they could just give their friends the theme file.

So I think what we have here, with the proliferation of versions, is a better example of the advantages of free software than most actual software. Users understand that they can modify themes even if they’re afraid of digging into code– so they do, and they share it. And nobody has to do patch review or anything, so everyone’s happy. ;)

Comment on Justifying window titles by Mårten Woxberg

Mårten Woxberg — Thu, 12 Jun 2008 15:55:06 +0000

I haven’t even thought of it as a problem, since I use the default setting of any theme.
But It seems like there are ALOT of theme’s that are forks of popular themes that really could have been just color corrections or options in the main theme.

Though this isn’t a Metacity problem.

Comment on The overview series: Drag and drop. You complain, we explain. by Rémi Cardona

Rémi Cardona — Thu, 12 Jun 2008 15:25:21 +0000

@Thomas,

Metisse currently listens for DnD events using XFixes (although a better solution such as _NET_WM_MOUSE_ACTION is *definitely* needed).

As for the interaction, we are currently implementing the following inside Metisse’s window manager:
- during the drag, hovering and staying still over a window will bring it on top after a timeout,
- if at the end of the drop, the user clicks on the destination window after the drop (within say 500ms), then the destination window stays on top,
- if the user does not click before the timeout, the window stacking is restored to what it was before the drag operation started.

The folding operation Frederic and I both described is only used in Metisse for text selection operations (see Fred’s URLs) but it can also be used for drag and drops : http://www.lri.fr/~dragice/foldndrop/ (this works great but we are working on a faster solution for Metisse, one that could be more easily picked up by Metacity)

Comment on The overview series: Drag and drop. You complain, we explain. by Elijah Newren

Elijah Newren — Thu, 12 Jun 2008 14:43:06 +0000

@Thomas:

That quote of mine was from Oct 2005; comment 28 of bug 154260 is from May 2006. The original _NET_WM_MOUSE_ACTION, to be fully implemented, would take an unrealistic amount of work, but implementing just the sane subset is already nearly done. So, yeah, it was a chronological thing. :-)

Comment on The overview series: Drag and drop. You complain, we explain. by Thomas Thurman

Thomas Thurman — Thu, 12 Jun 2008 12:34:37 +0000

@Rémi:
But the point is, how does Metisse know that this IS a drag operation?

Comment on The overview series: Drag and drop. You complain, we explain. by Rémi Cardona

Rémi Cardona — Thu, 12 Jun 2008 12:06:15 +0000

Metisse (see URL) does this by peeling windows like a piece of paper on a drag operation and then rolling the window back. Another solution :)