I'm using Ubuntu 12.04 LTS using the default (unity?) interface (with some gnome-panel stuff running too).  At the top I have the time, networking, switch user stuff along with the menu of whatever application I'm using.  At the left (on autohide) I have the "dock" where I can launch applications.  At the bottom I have the old gnome  taskbar.
 
The problem is that whenever I drag a window partially off my screen, by default, it autosnaps back to being completely on the screen (when I release the mouse). This is a problem because I will often be visually aligning two windows one on top of the other and each takes up (due to poor application interface design) over half of the screen vertically (and resizing every window is not feasible).  So, every time it snaps back, it covers up the other window at least partially. Further, it sometimes will snap to the bottom of the screen regardless of where on the screen I had dragged a window to (even if the window is fully on the screen). In CompizConfig I disabled the "grid" plugin, and still had this problem.
 
On CompizConfig I found the option in Window Management for the "Move" plugin. I found the box "Constrain Y" which, when unchecked, will allow me to partially drag windows off the bottom of the screen.  However, when I do this, new windows that spawn on application launch (e.g. if I launch firefox) will have their title bars under my OS header bar (with the time/date, etc). To close windows, I right click on their entry on my taskbar and select "close" or exit the application completely on the main menu. Further, the application that I'm using to do the visual comparison has the ability to launch sub-windows of its own. For some insane, non-configurable reason some of these windows will spawn COMPLETELY off the screen on the bottom. To move these, I right click on the taskbar entry, select "move" and then move my mouse upward to drag the window back on the screen (and then click to deposit it). So, for two reasons having the "constrain y" seems to be a necessity.
 
Is there a middle ground somewhere?  Can I constrain the Y of just the window title line between the 2nd "text line" and the 2nd from last line on the screen (so I can click on it directly to drag it around the screen whereever I want and not having it hide under interface reserved lines). Alternatively can I "fake" my y resolution as being 150% greater than it really is, so that I can have extra space to dump windows to go off the bottom of my screen? Is there an alternate plug-in that accomplishes either of these? Also, out of curiosity, why is there not a "constrain x" if there's a "constrain y"?

I've been poking around a bit more, but still have the problem.
 
Under Window Management:
Enabled plugins: Move, Resize, Place, Scale
(Scale is required by Ubuntu Unity Plugin, which I assume I need)
Move: if I turn this off, I can't drag/drop to move windows, so I need it.  Similar for "resize".
Place options: workarounds enabled, use active device.  The "force placement windows" line is blank.
Fixed windows placement: I now have an entry for my application that spawns windows off-screen to to to (x,y)=(20,20).  I keep unchecking "keep in workarea" but any time I come back to the settings screen from another control panel, it's re-enabled.
In Move: I have the constrain y off.
 
If I disable "fixed windows placement" and have "constrain y" (from move) off it doesn't snap the windows to the bottom of the screen.  If I have "fixed windows placement" enabled, I can get the problematic application to spawn new windows on-screen...at the cost of keeping everything on-screen (whenever any window loses focus, it generally snaps to the bottom of the screen, regardless of if it was dragged off or not)

That is probably exactly what I need.  However, for some reason right now when I have the grid box checked, I get a segfault and my display manager shuts down.  Fortunately my terminal was loaded and the config settings wizard was still open and responsive on my system, so I was able to uncheck the grid box and do a compiz --replace.
 
However, it seems that "grid" is corrupt, so I need to do something about that before I can get a responsive system.
Checking if settings need to be migrated ...no
Checking if internal files need to be migrated ...no
Backend     : gconf
Integration : true
Profile     : unity
Adding plugins
Initializing core options...done
Initializing composite options...done
Initializing opengl options...done
Initializing decor options...done
Initializing move options...done
Initializing grid options...done
Segmentation fault (core dumped)

I'm not sure what you mean by it is unchecking unity.  The Compiz Ubuntu Unity Plugin is enabled.
 
I have a .gconf directory, but what I'm looking for there I'm not sure:P I do see the "desktop" subdirectory has only a gnome sub.
In my CCSM preferences I have my profile set to "unity" (rather than "default".  The backend is GConf Configuration Backend (rather than flat file).  The "integration" box is checked
 
I have an xml file at apps/compiz-1/plugins/grid/screen0/options that indicates my modifications from default.

okay...resetting has solved most of my issues.  However, with "Place windows" off, new windows of any application when launched from the dock or desktop invariably open with the title bar of the application merged with the OS title bar, lacking the minimize/maximize/close buttons in the process. There are about 2 pixels (vertically) selectable that you can drag the window from that position (or you can alt+click on the window body can allow you to move the window).  Playing with values in the Put plugin (or move, grid, etc) don't seem to affect this behavior.
 
The place windows plugin handles this aspect better, but it snaps partially offscreen windows back to the screen fully (as referred to earlier in this thread).
 
Sometimes the global bar also displays text of a not-in-focus application until you click on the global bar.

Thanks for all the help thusfar.  It has been excellent.
In any case, I had been planning on using CentOS on this laptop way back when I was installing linux. However, CentOS, Debian and another distro failed to recognize my display adapter.  I played with CentOS in command-prompt (runlevel 3?) mode for a while to try to find alternate/experimental drivers, but none of them could handle graphics for my computer.  Ubuntu worked straight off the install.
I regret having "upgraded" to the latest Ubuntu when they introduced Unity. I'm a focus-follows-mouse diehard (I've "hacked" windows 7 to allow linux-like FFM), and that is fundamentally damaged in unity due to the mac-like global menu, so have suffered without it.  Most of my work and all of my recreational computer use is in windows, but there are some applications for work that I cannot run in an windows environment.
Unfortunately I also didn't put much effort into finding a good emulation environment for linux within windows - I was partially concerned with processor speed, but given the amount of time I waste on rebooting to switch OSes, the speed advantage of a native linux environment is neutralized or reversed.
 
If I were to abandon-ship on unity, what would be the best windows-like FFM-supporting GUI overlay to use? Would that be supported within ubuntu, or would I have to install a different distro and re-install all my apps as well?

James_L
Did you also use the settings for 'Put' in the CCSM to keep that control portion from disappearing? That might no longer be set since the 'unity --reset' was done.

Put is set to "avoid offscreen"
But the window isn't off the screen...it's just (potentially) off the usable area of the desktop.
 
I guess if the windows were on top of the header bar/general menu in z-stack space, that'd be fine...but I wouldn't want it to be over my gnome taskbar at the bottom.  I'm not sure if it matters or not if it's over the dock/dash...but right now it's putting the new windows flush left with the right of that, so it's a non-issue (it's kind of odd that it respects dash's placement, but not the header menu).
 
I've tried setting "pad top" within "Put" to 50, but that doesn't do anything that I can detect.
 
As to your edit on the other post: what module are you saying I could disable?  I've had "snapping windows" disabled all along.  Disabling Put doesn't do what I need.  If I disable Move/Resize I can't even shuffle around my windows to my desire.  Scale can't be disabled without disabling the unity plugin, which I assume (perhaps falsely:P) is essential for this desktop manager.
 
Edit: based on the documentation of Put, it is used to place windows that already exist (with key presses or mouse actions to affect the active window).  Is there a way to pass windows to Put (with a placement parameter) on instantiation/creation? 

no.  I have not had the opportunity to do that.  I have gnome-panel running already and may be hiding various toolbars normally associated, so I don't know if I would lose critical functionality. In other words, it's not something that I wish to deal with in the middle of a workday, but only after having backed up critical data and interface info.

hey cool.  a thread you linked linked to this one: https://bugs.launchpad.ne...rce/compiz/+bug/974242
 
so it looks like I install the PPA in #23, assuming they have a 64 bit ver?  then re-enable place?

other than compiz crashing when I disabled Put, everything seems perfect. Thanks again.
 
Edit: I think we have to wait on the final call until tomorrow.  I'm at home now and at home I use a 4:3 aspect ratio external monitor rather than my letterbox laptop monitor...so it's always possible it responds well to the desktop dimensions of the 4:3, but not generally.
 
 

Since I haven't seen a reply for a few days I'll consider this resolved. At least to a workable solution till the next iteration of Unity is released. Hopefully they'll implement the patched solution. Everything seems to be working on this end for both the x86 but the amd64 (x86_64) implementations.

Glad to see the annoyances are resolved. I think we can safely mark this [Solved] until the next discussion we have about Linux.
 
I'll be installing BakcTrack 5.3 onto a laptop here in the mean time so that I can test out the tools using an older range of hardware. Should prove interesting.