I'm not sure it's "expected"; no other desktop lets you move maximized
windows AFAIK.

It might be interesting to experiment with turning a maximized window
into a non-maximized-but-full-sized window when you tried to move it,
but I can imagine that might confusing too...

This bug is a dup, need to find the other one.

I don't think it's right in general to allow moving the window.

#91685 should just be fixed; it's never a bug that there's no way to
work around another bug, just fix the first bug. ;-)

I do think it would be nice to allow a maximized window to be "shaken
loose" if you grab it and move it far enough. At least you should be
able to drag a maximized window between xinerama heads. So I do want
to experiment there as Calum says. But I don't want clicking a
maximized window and moving just a few pixels to result in
unmaximizing; you should be able to click-to-focus on the titlebar for
example without fear of unmaximizing accidentally.

*** Bug 93600 has been marked as a duplicate of this bug. ***

oh I didnt know it was a dup, sorry, its good that others feel the same:-)

Yeah I have been asking for this feature too, I would love to be able
to move a maximized window.

I'd take a patch for the "shake loose" feature (allow moving the
maximized window by unmaximizing it if the window is moved by some N
number of pixels threshold).

where N is some factor of the system drag and drop threshold and not
some hard-coded value I trust :)

*** Bug 93188 has been marked as a duplicate of this bug. ***

It be correct to close this bug and open a new one for the "shake
loose" enhancement, no?

Let's just change this one to the feature request.

Okay, thanks.

Created attachment 12336 [details] [review]
Patch allows moving maximized windows between xinerama heads

I'm also missing the feature to move maximized windows among xinerama
heads. I'm new in coding for gnome (linux generally) but I've tried to
implement something like that for my own purpose. Perhaps you can use
it altough it is not perfectly solved.

See attached patch (to 2.4.3).

So a UI question here is whether to move between monitors you need to
"shake loose" (thus unmaximizing the window), move the window, then 
re-maximize on the other monitor; or whether to just snap to xinerama 
monitors and don't allow shaking loose otherwise.

I'd lean a bit toward the "shake loose" since it solves the problem
more generally.

The problem with "shake loose" is that - as you've written - one has 
to re-maximize the window after moving it. I wouldn't prefer this 
method - I got used to it in Windows some time ago (with add-on 
tool).

A compromise is perhaps if we can add another function like "hook 
in" a window - the exact opposite of "shake loose". Probably this 
should only be enabled if the user had just before shaken the window 
loose. I hope you understand my idea despite my English. What do you 
think about it? When I get time, I'll try to implement it.

I can see some sort of "hook in" feature working well, though it will 
probably require some experimentation to make it smooth. Agree that 
it would probably only "auto-hook-in" if the window was maximized at
the start of the move operation.

I've implemented the shake loose and the hook/snap in feature. I 
just installed it on my main system, I definitively don't want to 
miss that anymore... ;)

BTW: During the tests I've found a bug in metacity: The 
meta_window_get_work_area() function returns sometimes a too large 
area. Concrete situation to reproduce the problem: Xinerama with two 
monitors, the secondary right monitor has more vertical pixels. 
Enable the standard gnome panels (one top, one bottom) and maximize 
a window on the left monitor. A port of the window will be covered 
by the bottom panel. I've (hopefully) fixed this bug and included it 
in the patch, because it is multi-monitor-related, too. Or is it too 
off-topic and shall I open an other bug?

Created attachment 14163 [details] [review]
Add "shake loose" and "hook in" features to Metacity and fix a multi-monitor work-area bug

Thanks for the patch, I'm out of town for a bit here but 
once I get back and put out any large fires I'll have a look at this
(and other pending metacity patches)

Xinerama work-areas are fixed in a (hopefully) definitive manner in
the per-xinerama work areas patch in #95014.  This is still pending,
and it will conflict pretty heavily with the changes you made to work
areas in this patch.

Try playing around with that patch and see if it fixes the problem
that you're describing.

-Rob

Thanks for the clue with Bug 95014. I should have looked at the bug 
list first... I don't have access at my xinerama system at the 
moment. In about a week I'll test your patch and adapt my patch, so 
it will use the new xinerama work area calculation functions.

I adapted my patch to work well with the patch of Bug 95014 and use
one of its new functions.

Created attachment 14346 [details] [review]
Patch for shake loose / snap in, works only with patch of Bug 95014

Oh baby that patch rocks my world.  Totally sweet.  This is the kind
of thing that just makes life worth living.  This is elevated to "I
can no longer live without it" status, and I only applied it two
minutes ago.

there's something fishy going on here.  I usually run evolution
maximized on the right xinerama on my system.  When I start it up, it
starts on the left xinerama.  So I try to move it over to the right by
dragging without unmaximizing first.  Seems great.  But as soon as I
do an action that changes the evolution display (such as viewing a
different message, or changing the folder, but not clicking a menu or
button), it "pops" back to the old xinerama.  This only seems to
happen with evolution but there are probably other apps that this
affects.  It also only happens if I've moved it to another xinerama by
shaking it loose then snapping it in.

Another quick comment -- when the window is unmaximized, it should be
moved so that the titlebar is under the pointer.

Created attachment 14523 [details] [review]
modified patch which fixes the problem with evolution that I observed.

bug #94111 results in this patch being a bit confusing, since the 
current code is clearly hosed it's hard to know if this code 
is right. This may be something that's most efficient if 
I go in and sort it out myself.

Now that I think about it more, I wonder if this is a race condition
somewhere.  Really the only difference between what my modification
does and the original patch did is that maximizing gets put into the
idle queue rather than happening immediately.

Just to be sure: there is nothing concrete I can do, as I have to 
wait until Havoc isn't anymore as busy, or?

well I think bug #94111 needs sorting out, if someone wants to look 
at that and make it all rational that may speed things up. 
Otherwise I'll get to it when I can.

I haven't tried the patch but I notice it hard-codes a
shake_loose_threshold, which I presume is the amount you need to click
and drag before a maximised window becomes movable.

I'd say we ought to use the system drag threshold for this (as defined
in the Mouse Preferences dialog), or at least be some multiple of it.

See also bug #107776, which discusses the amount of snap/gravity
panels now have-- I think this "shaking loose" feature probably ought
to share that setting, so Havoc and Mark probably need to talk about
this :)

This isn't Solaris specific, is it? Change the OS to reflect that?

No, it's not... changed to 'All'.

I've updated my patch to not (wrongly) multiply the
meta_window_{,un}maximize functions, this fixes an issue with a
wrongly saved rect after snap in. It's also updated to apply against
metacity-2.5.2 with my patch of Bug 94111.

Created attachment 17175 [details] [review]
Updated patch against metacity-2.5.2

I forgot to mention that the threshold is still hard-coded. I wanted
to change this but I couldn't find a nice way of using the already
defined drag and drop threshold. The only function I found was
gtk_drag_check_threshold () but it needs a GtkWidget wheras there is
none. If anyone has a suggestion for a better solution I'm happy to
update my patch.

Havoc, could you please comment? - I don't want to miss this feature
in Gnome 2.4.

Thx

I didn't try this patch out but it looks pretty reasonable and it's 
pretty much how I would implement the feature. Removing the 
has_move_func = FALSE for maximized windows should be correct 
based on my understanding of bug 94111.

As always, a few random comments:

 - the way to do the drag threshold is exactly the way 
   we're currently doing the double click timeout - you 
   may want to have a look at that, meta_ui_get_double_click_timeout()
or something in ui.c. Look at the source 
   code to gtk_drag_check_threshold() in gtk/gtkdnd.c also. You don't
want to 
   use gtk_drag_check_threshold() though since you only 
   care about the Y coordinate.

 - in the initial shake loose case, it seems you only update 
   saved_rect if the window has a frame. Don't you need to 
   handle the no-frame case? The idea here is so the shaken-loose 
   window appears at the current pointer position right?

 - I think updating the saved_rect could maybe use a short 
   comment saying why we're doing it. Or maybe just a comment 
   before all the shake loose stuff saying what the overall block 
   of code does. Maybe even break the shake loose code 
   into a separate function like check_shake_loose() but I'm 
   not sure that works out well, use your judgment.

 - "guint shaken_loose : 1" should be "unsigned int shaken_loose : 1"
    and should be up alongside other bitfields so they are all 
    packed together in memory

 - when moving between xineramas, can you think of a way to avoid 
   the flicker of unmaximizing then remaximizing? Would it 
   work to just meta_window_move_resize() over to the new Xinerama?

Anyhow, see what you think of these ideas and implement the ones that
make sense to you, attach a new patch and I think we'll go ahead and
put it in.

Thanks

Thx for your comments. I've updated my patch as following:

- According to your comments on bug 94111 I've adapted this patch to
work without a patch to bug 9411 and to reflect the intended use of
the variables, i.e. I've changed the META_WINDOW_ALLOWS_MOVE macro to
include maximized windows as the has_move_func shall be independent of
the maximized status.

- The double_click_time is implemented (in display.c BTW) as a member
variable of MetaDisplay whereas the value is once initialized and then
remains constant. I've left my threshold implementation as it is
because I don't know if you want me to add a shake_loose_threshold
member to MetaDisplay. If you intended to change it this way, I'll try
that. As far as I understand it, we can't use something similar to
gtk_drag_check_threshold as gtk uses widget attributes.

- The save_rect issue shall be fixed now, the repositioning works now
very nice. Thx for the hint, I don't know what I thought of while
doing this that badly...

- I've added some comments here and there.

- Changed the bitfield declaration as proposed but I don't understand
why this shall be a "unsigned int" wheras all other bitfields are
"guint"s.

- I couldn't find a way to avoid the flicker. I tried it in my first
two patches with meta_window_move_resize but that leads to the race
condition noticed and fixed by Rob. But as you didn't try out the
patch you couldn't see that one doesn't really notice the flicker and
as you can see in the code it only shows up when moving directly
between two heads (without ever going beyond the threshold). So I
don't think it's an issue.

I hope everything is ok now.

Created attachment 17431 [details] [review]
Updated patch as commented

Ah, on the unsigned int thing I was confused; normally I never use 
guint, but apparently I adopted that policy post-writing-metacity.

I think you must be looking at older source code for the
double_click_time thing; it's different in CVS.

I can polish up the remaining issues here and commit if you want.

Ah ok. Committing would be nice :)

Thx

Created attachment 17479 [details] [review]
patch in CVS

I checked in the attached patch, cleaned up some unrelated mess 
I stumbled on in the process.

If I broke things, please file new bugs for each specific breakage.

Thanks a lot!