Can't drag a window to another workspace

Using the mouse wheel on the desktop switches between workspaces. This is different from metacity's behaviour.

Bruce- this has the obvious disadvantage that it doesn't work when there are open windows on these desktops. So it's not a substitute.

On Tue, 2007-10-09 at 16:29 +0000, Paulus Esterhazy wrote:
> Bruce- this has the obvious disadvantage that it doesn't work when there
> are open windows on these desktops. So it's not a substitute.
>

That was supposed to be my point, but oh well.
--
Bruce Cowan <email address hidden>

I just found that there is a difference between the notion of a large
desktop ("horizontal virtual size") and and that of virtual desktops in
the General Options section of ccsm. If you use the latter, then you
_can_ use the mouse wheel in the panel, and also drag windows around.

But a large desktop in compiz is vastly superior to separate virtual
desktops, so setting this is a bad workaround.

Conclusion: The workplace switcher should work with the large desktop, too.

There is another functional regression in Compiz: https://bugs.launchpad.net/ubuntu/+bug/155438/

In short: you cannot set name for workspaces, and you cannot display these names in the Workspace Switcher applet in the Panel.

Please don't spam other bugs with details of another one.

Are there plans to correct this at the compiz proyect?

Please file a bug at http://bugs.opencompositing.org, I am now using metacity.

Actually this is a problem with the workspace switcher applet but I've left it filed against compiz so I remember to look at it.

I can confirm at least the second point of the original bug report ("cycle virtual desktops by using the mouse wheel on the switcher applet") - the wheel apparently no longer has any effect on the desktop switcher applet if Desktop Effects are enabled. In my opinion switching on "Visual Effects" should not change the actual functionality of the desktop :-) and personally I would prefer it if the taskbar switcher would with compiz the same as without compiz.

OpenCompositing bug opened http://bugs.opencompositing.org/show_bug.cgi?id=703.

Status set to confirmed and importance set to Wishlist

According to Compiz developers, this problem must be fixed in the gnome-panel workspace switcher applet so I set back libwnck to Confirmed.

Because the "mousewhell" problem is already described in Bug #150443, I adjust the bug title to only speak about the "drag windows" problem.

For Hardy and Intrepid: I still can't drag a window in workplace switcher applet from one desktop to the other while Compiz is enabled.
Is there a as fast workaround? ( Dragging to the side is way slower if you want the window to go to workplace 3 from 1. And so is clicking the window icon and selecting move to different workplace)

Tom,

This has been annoying me for awhile but I worked out an alternate method of doing almost the same thing. Press Super-E (super = windows key) to enter Expose mode, then grab the window you want to move and drop it onto another workspace. Double-click a workspace to get out of Expose mode.

It's not as simple or quick as the pre-compiz drag-n-drop but it's faster than dragging the window across a bunch of workspaces.

I concur that the bug exists, but I've used the compiz-fusion-icon to turn on metacity instead of compiz, and I still cannot drag a window from one workspace to another in the workspace applet.

Ubuntu 8.10, all current updates.

I had to completely removed compiz in order to restore functionality --

I need to be able to switch workspaces. Being locked to one workspace is hideous. Ubuntu 8.10 with all updates.

Wayno

I confirm on Ubuntu 8.10 Intrepid, the workspace applet does not allow moving windows from one desktop to another by drag and drop with compiz as a wm.

is this supposed to be fixed in 9.04? (the behavior is unchanged)

I have no idea when this will-be/should-be/was fixed; I'm simply the
guy who reported the problem. As a "post mortem" (if they/you/we are
doing those) it'd be great to analyze this bug and see why it has
taken so long to get it fixed (esp. since it _used_ to work!)

I think it works under at least _some_ conditions now... happy to do
some testing to verify; I'll follow up with another email after I do
that.

Regards,
-pbr

On Wed, Apr 22, 2009 at 1:54 PM, Chris Roddy <email address hidden> wrote:
> is this supposed to be fixed in 9.04? (the behavior is unchanged)
>
> --
> Compiz Gutsy : Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
http://reiber.org

I would like this fixed. But (works for me) there is an acceptable workaround: Disable visual effects. System -> Preferences -> Appearance -> Visual effects -> None. Then apps can be dragged workspace to workspace in the workspace switcher app.

Paul Beardsell

Interesting... maybe this can help the developers w/ their debugging.
-pbr
http://reiber.org

On Sun, Apr 26, 2009 at 8:51 AM, Paul Beardsell <email address hidden> wrote:
> I would like this fixed.  But (works for me) there is an acceptable
> workaround:  Disable visual effects.  System -> Preferences ->
> Appearance -> Visual effects -> None.  Then apps can be dragged
> workspace to workspace in the workspace switcher app.
>
> Paul Beardsell
>
> --
> Compiz Gutsy : Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
http://reiber.org

@paul beardsell: that sets the window manager back to metacity instead of compiz which is why it works again.

The 'about' option on the workspace switcher states:
"The Workspace Switcher shows you a small version of your workspaces that lets you manage your windows."

It allows you to do no such thing now. IMHO this is a bug and not a wishlist item.

IMO the switcher should be like a mini 'expo' when in compiz mode, and
classic style when in metacity.

2009/5/6 wdesmet <email address hidden>

> @paul beardsell: that sets the window manager back to metacity instead
> of compiz which is why it works again.
>
> The 'about' option on the workspace switcher states:
> "The Workspace Switcher shows you a small version of your workspaces that
> lets you manage your windows."
>
> It allows you to do no such thing now. IMHO this is a bug and not a
> wishlist item.
>
> --
> Compiz Gutsy : Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

I'm unaware of expo's drag/drop interface, so I can't comment, other
than to say I found it REALLY REALLY useful to be able to move windows
from workspace to workspace (on or off of the current workspace, for
example) before this bug was introduced.

Indeed, it _was_ a great way to "manage my windows". I'm happy to see
some other people taking interest in this bug; it's a significant
usability problem.

-pbr
http://reiber.org

On Wed, May 6, 2009 at 5:44 AM, dougfractal <email address hidden> wrote:
> IMO the switcher should be like a mini 'expo'   when in compiz mode,  and
> classic style when in metacity.
>
> 2009/5/6 wdesmet <email address hidden>
>
>> @paul beardsell: that sets the window manager back to metacity instead
>> of compiz which is why it works again.
>>
>> The 'about' option on the workspace switcher states:
>> "The Workspace Switcher shows you a small version of your workspaces that
>> lets you manage your windows."
>>
>> It allows you to do no such thing now. IMHO this is a bug and not a
>> wishlist item.
>>
>> --
>> Compiz Gutsy : Can't drag a window to another workspace
>> https://bugs.launchpad.net/bugs/150690
>> You received this bug notification because you are a direct subscriber
>> of a duplicate bug.
>>
>
> --
> Compiz Gutsy : Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
http://reiber.org

Hi folks,

I've been doing some investigating and maybe you already know this but in libwnck in screen.c the function update_workspace_list this always sets n_space to 1 without printing my warning. From my understanding this goes all the way to compiz land which hacks the workspaces to always be set to one.

  n_spaces = 0;
  if (!_wnck_get_cardinal (screen->priv->xroot,
                           _wnck_atom_get ("_NET_NUMBER_OF_DESKTOPS"),
                           &n_spaces)) {
    fprintf(stderr, "WARNING WARNING could not get Atom _NET_NUMBER_OF_DESKTOPS, setting n_spaces to 1\n");
    n_spaces = 1;
  }

Because of this the method wnck_screen_get_workspace_count will always return 1 and therefore also workspace_at_point will return 1 and the move will then fail because we're moving from workspace 1 to workspace 1.
What I can understand this is the same reason bug #150443 fails.

The strange thing is that the drawer somehow can figure out how many workspaces there really is - why this is so I couldn't find but I suspect that it checks some gconf values because of the rows thing.

Maybe someone who knows a little bit more about compiz internal can explain why _NET_NUMBER_OF_DESKTOPS is set to 1?

> can explain why _NET_NUMBER_OF_DESKTOPS is set to 1?

I don't know a lot about how compiz work but it's using viewports and not workspaces and libwnck viewports is suboptimal

Aha. If I understand it correct, a viewport is just a part of a "large desktop" (vm-spec).
But how can the pager display get the number of viewports correctly when drawing the switcher, I might be blind but I just can't find the code that draws ALL (iterating thru the list and calls the appropriate drawing function) the viewports/workspaces in pager.c because this one seems to get the correct number... or I'm I completely wrong here?

NOTE I've not looked at the code in question - though I plan to - this
is just some potential insight into the situation.

Seems to me, if compiz was "taking over" for the other multi-workspace
code, it might do just what was observed - force the number of
workspaces (from all the other/old codes perspective) to be 1, so it
could render its own new-style workspaces into that one old-style
workspace.

If that's whats going on this starts to make more sense.

Best,
-Paul
http://reiber.org

I just thought I would make a mock up of a more colourful workspace switcher.

Since expo already has the functionality that we want, it must be possible to overlay expo into the workspace switch applet.

I've made a kinda hackish patch that lets you move the window to another workspace (actually its a viewport).
Known bugs
 - The window isn't moved to the same position as the last workspace
 - No highlight during drag
 - Probably something more...

Note I'm not a C developer and I really haven't got a clue of the internals of X, gtk, libwnc, etc. If I get more time during the weekend I might fix the last things. Otherwise if someone else is willing to fix the code, feel free ;-)

Also, making diff isn't my cup of tea... Hope it works ;-)

Marcus Carlson : Wow, thanks for your hack! :-) Thought this patch probably need some modifications, if it works, it's already a good step. Can you post your patch on libwnck upstream bug report? That is the right place to discuss about this since GNOME developers are there.

http://bugzilla.gnome.org/show_bug.cgi?id=505367

Saïvann Carignan: It surly did need some modifications, in fact I felt ashame of the patch so I had to do a better one ;-)

So here we go again, the window is now moved to the right position after the move and won't activate (unless moved to the current workspace/viewport). Very annoying having awn making jumps ;-) No highlighting this time either.

Will also post upstream so they can give comments on the code.

assigning it to One Hundred Paper Cuts because :

- it clearly impacts the usability of the desktop
- it is by default for most users (as desktop effects are enabled when possible)

BTW - the tool tip for the workspace switcher still says "click to start dragging" when hovering over an application, even though this clearly doesn't work. I suggest disabling the tool tip until such time that the functionality is put back (as I understand its hard).

Oded, actually patches to make it work is availble and i think Fedora includes those in their package. The problem is that Vincent would like to rewrite the whole workspace/viewport code to make it generic. I guess he doesn't have time to fix this atm as all work goes towards gnome-shell and gnome 3.0.

Not that I'm complaining, but I think the current situation is sub-optimal and there are a few ways to fix this in Ubuntu (i.e. not upstream):
1) wait until a rewrite is done, either for GNOME 2 or GNOME 3. This will take a long time to deliver.
2) Apply the patches available elsewhere
3) Fix the tool tip

As far as i'm concerned, even though I'd love to use this feature, either 2 or 3 would be just as acceptable and can be handled in Ubuntu, without waiting for upstream, to fix the user experience today.

[Today = "some amount of time that is shorter then waiting for GNOME 3.0"]

rewriting the tooltip is just plain wrong. This bug is a regression (it doesn't happen with Metacity) and some people are used to it.
 Just changing the tooltip is *NOT* solving the bug and will send a wrong signal. It's like closing the door when you see that your kitchen is on fire. By closing the door, you don't see it anymore, isn't it?

No Lionel. Changing the tool-tip when compiz is active (since, compiz breaks the DnD functionality) would then make everything work as expected & keep the tool-tips useful for both cases. Yes, changing the tool-tip won't fix the DnD problems when compiz is loaded, but it will correct the problem of the tool-tip telling the user they can do something when they clearly cannot do it.

Have two tool-tips: 1 for metacity, 1 for compiz. Tool-tip issue is fixed - reporting correct functionality in both cases. DnD works with plain vanilla metacity; therefore the tool-tip should stay stating "Click to start dragging...". However, if compiz is being used & DnD doesn't work, then changing the tool-tip - in that circumstance - is the right solution, as the functionality is not there.

Why would you keep a known wrong, easily fixed tool-tip for functionality that isn't there? "Some people are used to it" - it should not have even gotten to that point. Stealing from your analogy: Just because you're used to the kitchen being on fire doesn't mean it's OK for it to be on fire.

And what is the wrong signal? "We acknowledge this functionality is broken for the time being; so, we will update the tool-tip to help the user know what will happen with metacity & with compiz. Once the functionality is restored the tool-tip will again be changed to help the user know what happens." How is that the wrong signal? Sounds like what open software is all about to me.

This tool-tip issue has nothing to do with the REAL bug.

Please, let's stay on focus. If you think the tool-tip issue is
serious enough, open a NEW bug, and discuss it there.

This bug's about broken functionality, not about tool-tips.

Kind regards,
-Paul Reiber
Email: <email address hidden>
Web: http://bit.ly/reiber

On Sat, Nov 14, 2009 at 8:36 PM, Derek White <email address hidden> wrote:
> No Lionel. Changing the tool-tip when compiz is active (since, compiz
> breaks the DnD functionality) would then make everything work as
> expected & keep the tool-tips useful for both cases. Yes, changing the
> tool-tip won't fix the DnD problems when compiz is loaded, but it will
> correct the problem of the tool-tip telling the user they can do
> something when they clearly cannot do it.
>
> Have two tool-tips: 1 for metacity, 1 for compiz. Tool-tip issue is
> fixed - reporting correct functionality in both cases. DnD works with
> plain vanilla metacity; therefore the tool-tip should stay stating
> "Click to start dragging...". However, if compiz is being used & DnD
> doesn't work, then changing the tool-tip - in that circumstance - is the
> right solution, as the functionality is not there.
>
> Why would you keep a known wrong, easily fixed tool-tip for
> functionality that isn't there? "Some people are used to it" - it should
> not have even gotten to that point. Stealing from your analogy: Just
> because you're used to the kitchen being on fire doesn't mean it's OK
> for it to be on fire.
>
> And what is the wrong signal? "We acknowledge this functionality is
> broken for the time being; so, we will update the tool-tip to help the
> user know what will happen with metacity & with compiz. Once the
> functionality is restored the tool-tip will again be changed to help the
> user know what happens." How is that the wrong signal? Sounds like what
> open software is all about to me.
>
> --
> Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Seems from comment #37 , that upstream hasnt moved on this issue since they are considering re-writing libwnck for gnome 3.0

Either Marcus' patch is good to be applied for Lucid or could someone request changes to Marcus' patch.

Subscribing main sponsors

I am unsubscribing ubuntu-sponsors, because there is no debdiff to sponsor, and subscribing ubuntu-reviewers instead.

This is still present in 9.10. I believe the most important issues are those a) visible to new users out-of-the-box and b) which obviously differ from Windows. Hence this is a very important issue which is very likely to be noticed by new users, who will base their opinion of Ubuntu (and Linux) on first impressions.

This discussion has been underway for 2.5 YEARS and from a user perspective NOTHING has happened.

If the tooltip is removed or amended to say how to move windows between desktops then the new-user damage is removed.

This is a serious reputational damage issue.

Cheers, allan.

Hear! Hear!

Paul Beardsell
<email address hidden>

On 9 April 2010 08:39, allankelly <email address hidden> wrote:

> This is still present in 9.10. I believe the most important issues are
> those a) visible to new users out-of-the-box and b) which obviously
> differ from Windows. Hence this is a very important issue which is very
> likely to be noticed by new users, who will base their opinion of Ubuntu
> (and Linux) on first impressions.
>
> This discussion has been underway for 2.5 YEARS and from a user
> perspective NOTHING has happened.
>
> If the tooltip is removed or amended to say how to move windows between
> desktops then the new-user damage is removed.
>
> This is a serious reputational damage issue.
>
> Cheers, allan.
>
> --
> Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of the bug.
>

This only affects the workplace switcher applet, which I thought windows didn't have? You can still move windows between desktops using the option menu or the keyboard shortcut (ctr-alt-shift left/right). Or just dragging them to the edge of the screen.

Not that I don't think it's important to fix something like this (a thousand paper cuts and all that), but there's no need for the hyperbole.

Something is going wrong when my favourite o/s (of which I am a deeply
appreciative long time desktop user and boring evangelist) can have all its
window buttons moved top left and the background changed to lurid purple but
the desktop switcher does not work (for ordinary mortals) as it should.
 Still broken in 10.04. Hyperbole? I don't think so.

Paul Beardsell
<email address hidden>

On 9 April 2010 09:01, wdesmet <email address hidden> wrote:

> This only affects the workplace switcher applet, which I thought windows
> didn't have? You can still move windows between desktops using the
> option menu or the keyboard shortcut (ctr-alt-shift left/right). Or just
> dragging them to the edge of the screen.
>
> Not that I don't think it's important to fix something like this (a
> thousand paper cuts and all that), but there's no need for the
> hyperbole.
>
> --
> Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of the bug.
>

On Fri, Apr 9, 2010 at 2:39 AM, allankelly <email address hidden> wrote:
> This is still present in 9.10. [...affecting...] first impressions.

Yes - depressing isn't it? However there doesn't appear to be a
clear-cut fix because of how the implementation of workspaces differs
from metacity to compiz. (oversimplifying a little but that appears to
be the gist of it; please don't take my word on this, however; take a
look at the code and make your own assessment - please!)

> This discussion has been underway for 2.5 YEARS and from a user
> perspective NOTHING has happened.

Well, I've done my best to ensure that this bug stayed open; there is
that. I've have coded a fix for it myself if I could see any light at
the end of any reasonable tunnel.

> If the tooltip is removed or amended to say how to move windows between
> desktops then the new-user damage is removed.

I personally think that approach is a bandaid as it doesn't solve the
real problem.

My take: if you can drag windows using the applet under metacity, you
should be able to do so under compiz. That end-user functionality is
darn handy, and I miss it. It deserves to work. (there, I said it.)

Compiz is simply failing to deliver on the existing workspace API that
metacity had implemented. Unlike some other interfaces that were
considered "standard" enough that they had to be implemented,
metacity's workspace API wasn't considered a "spec" that needed to be
adhered to. I believe a backwardly-compatibile interface could indeed
be implemented but no-one on the compiz team appears to be interested,
since not very much metacity code actually needs an interface to
workspaces.

One possible light at the end of a tunnel just a bit longer than I
care to traverse myself is the following. One workable solution would
be to code a brand new compiz workspace applet that ignores the
current codebase and simply uses the same gesture handling and
look-n-feel as the current applet, but interfaces with workspaces in a
fully compiz-compatible way like lots of other compiz-only components
do. (there are a myriad of effects available for workspace->workspace
transition rendering, for example)

If I was a college professor I'd have given this to a grad student as
a project some time ago. Maybe this message will do the trick, and
someone will pick up this ball and run with it?

> This is a serious reputational damage issue.

With that I agree fullheartedly. It's a UI blemish that's really
apparent to newbies and old-timers alike.

> Cheers, allan.

Thanks for your support and comments! Hopefully, ongoing dialog will
help bring a solution to bear.

Kind regards,
-Paul Reiber
Email: <email address hidden>
Web: http://bit.ly/reiber

On Fri, Apr 9, 2010 at 3:01 AM, wdesmet <email address hidden> wrote:
> This only affects the workplace switcher applet, which I thought windows
> didn't have?

Indeed that appears to have been Allen's point - that workspace
switching is something "new" that you don't see in Windows. Thus, new
users try it out and like it and use it and play with all the
features. Then they later switch on compiz and it starts working
differently and with fewer features. Yuck.

> You can still move windows between desktops using the
> option menu or the keyboard shortcut (ctr-alt-shift left/right).

(aside: the right-button menu on a windowframe shows _what_ as the
keyboard accelerators for moving the window to workspace
left/right/up/down? ...certainly not ctrl-alt-shift-arrowkey as you
say above, though those DO seem to work just fine, although NOT solve
the problem; see below

> Or just dragging them to the edge of the screen.

Both the arrow-keys solution and the window-dragging solution need the
mouse to be in the window to be moved. The
window-moving-in-the-applet functionality allows _any_ window to be
moved to _any_ workspace, regardless of what windows are showing and
what the current workspace is. So please don't confuse window control
and virtual-workspace-window-management; they're very very different.

> Not that I don't think it's important to fix something like this (a
> thousand paper cuts and all that), but there's no need for the
> hyperbole.

The word hyperbole infers that Allen exaggerated something; I don't
find that to be the case. Nothing he said was an exaggeration, even
his wrap-up that this is a reputational damage issue. It is.

Kind regards,
-Paul Reiber, the guy who opened this bug in the first place and won't
let it die till its fixed
Email: <email address hidden>
Web: http://bit.ly/reiber

On Fri, Apr 9, 2010 at 3:29 AM, Paul Beardsell <email address hidden> wrote:
> Something is going wrong when my favourite o/s (of which I am a deeply
> appreciative long time desktop user and boring evangelist) can have all its
> window buttons moved top left and the background changed to lurid purple but
> the desktop switcher does not work (for ordinary mortals) as it should.
>  Still broken in 10.04.  Hyperbole?  I don't think so.
>
> Paul Beardsell
> <email address hidden>

In one of my other replies on this thread I've identified a light at
the end of the tunnel.

Here's hoping someone codes up something like that for Google's
summer-of-code, or a grad student does it to get an A, or some
up-and-coming superstar does it in a weekend just to hone his skills a
bit more. :-)

Then all we'll need to do is to get the two look-alike-work-alike
applets to know enough about each other to defer to the other one
if/when compiz or metacity are running. Or something similarly
effective.

-pbr

I also experienced a crash of the workspace-switcher applet when using simple effects in Lucid, and trying repeatedly to move a window from one window to another.

Hi again, I've installed 10.04 LTS and one of the first things I did was check this out. Nope, it's broken in the same way.

Thanks to Paul for the comments above and if it's possible to ++ this by keeping it under discussion then I hope I've helped.

Cheers, al.

Yes allankelly, same here.. This is an essential desktop usability issue! If you just try to drag the windows, the cursor changes, but then still nothing is happening.

Is this patch still applicable to Lucid? I'm unable to locate pager.c

On Fri, May 21, 2010 at 10:17 AM, Ryan Beard <email address hidden> wrote:
> Is this patch still applicable to Lucid?  I'm unable to locate pager.c
>
> --
> Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Some time ago Marcus wrote:

"Oded, actually patches to make it work is availble and i think Fedora
includes those in their package. The problem is that Vincent would like
to rewrite the whole workspace/viewport code to make it generic. I guess
he doesn't have time to fix this atm as all work goes towards gnome-
shell and gnome 3.0."

Is that the patch you are referring to?

I'm here to help get this resolved; please let me know how I can assist.

Kind regards,
-Paul Reiber
Email: <email address hidden>
Web: http://bit.ly/reiber

Paul -

I'm actually referring to the patch attached to this bug (posted in comment #34: betterpatch.diff). It appears to target pager.c, but I can't find that file in 10.04.

I haven't researched the Fedora patch yet, but I will look into that.

I'm new to Gnome, and linux in general (been an OpenSuse/Kubuntu/LinuxMint user for the past year), but I actually noticed this bug within the first 30 minutes after installation. I'd like to help if at all possible (I was a heavy .net programmer, but I've been living in Qt Creator for the last 6 months), but I figured I should start with whatever work has already been accomplished - this patch, and the alleged Fedora patch - and build from there.

Thanks for the help.

Ryan,

If you're willing to dig/investigate, code, debug, and submit, I'm
certainly willing to help.

I've been programming/administering UNIX for ~30 years, Linux for ~15.
My strengths are... well, pretty wide-reaching, but not so much in the
GUI/Gnome/Window-manager/Virtual-Desktop coding details, or I would
have fixed this myself a long time ago.

Let me know if/when you get stuck and I'll do my best to get you
un-stuck. Contact me off-list at <email address hidden> any time.

Kind regards,
-Paul Reiber

On Fri, May 21, 2010 at 2:48 PM, Ryan Beard <email address hidden> wrote:
> Paul -
>
> I'm actually referring to the patch attached to this bug (posted in
> comment #34: betterpatch.diff).  It appears to target pager.c, but I
> can't find that file in 10.04.
>
> I haven't researched the Fedora patch yet, but I will look into that.
>
> I'm new to Gnome, and linux in general (been an
> OpenSuse/Kubuntu/LinuxMint user for the past year), but I actually
> noticed this bug within the first 30 minutes after installation.  I'd
> like to help if at all possible (I was a heavy .net programmer, but I've
> been living in Qt Creator for the last 6 months), but I figured I should
> start with whatever work has already been accomplished - this patch, and
> the alleged Fedora patch - and build from there.
>
> Thanks for the help.
>
> --
> Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Thanks Paul. I've downloaded the Grub development kit, and I'll be
setting up conary today. I'll let you how things go.

-ryan

On Fri, 2010-05-21 at 22:36 +0000, PaulReiber wrote:
> Ryan,
>
> If you're willing to dig/investigate, code, debug, and submit, I'm
> certainly willing to help.
>
> I've been programming/administering UNIX for ~30 years, Linux for ~15.
> My strengths are... well, pretty wide-reaching, but not so much in the
> GUI/Gnome/Window-manager/Virtual-Desktop coding details, or I would
> have fixed this myself a long time ago.
>
> Let me know if/when you get stuck and I'll do my best to get you
> un-stuck. Contact me off-list at <email address hidden> any time.
>
> Kind regards,
> -Paul Reiber
>
>
> On Fri, May 21, 2010 at 2:48 PM, Ryan Beard <email address hidden> wrote:
> > Paul -
> >
> > I'm actually referring to the patch attached to this bug (posted in
> > comment #34: betterpatch.diff). It appears to target pager.c, but I
> > can't find that file in 10.04.
> >
> > I haven't researched the Fedora patch yet, but I will look into that.
> >
> > I'm new to Gnome, and linux in general (been an
> > OpenSuse/Kubuntu/LinuxMint user for the past year), but I actually
> > noticed this bug within the first 30 minutes after installation. I'd
> > like to help if at all possible (I was a heavy .net programmer, but I've
> > been living in Qt Creator for the last 6 months), but I figured I should
> > start with whatever work has already been accomplished - this patch, and
> > the alleged Fedora patch - and build from there.
> >
> > Thanks for the help.
> >
> > --
> > Can't drag a window to another workspace
> > https://bugs.launchpad.net/bugs/150690
> > You received this bug notification because you are a direct subscriber
> > of a duplicate bug.
> >
>

@Marcus: I've tried Fedora 13, and they have the same issue - when Compiz desktop effects are enabled, hovering the mouse over an image for an application in the workspace switcher shows the tooltip "drag to move application to a different workspace", but dragging doesn't do anything.

Ryan - here's my understanding of this issue. I believe, at the heart
of the issue is that Compiz handles virtual desktops quite differently
than Metacity.

Because of this, it "fakes" any apps using the Metacity virtual
desktop API into thinking there's only one virtual desktop. I'm not
sure of the details of how it does this; review the thread on this bug
for some leads (hopefully).

I haven't reviewed any of the patches that've been identified, because
they slipped my attention; I wasn't aware any coding work had been
done by anyone to attempt to address this. I believe the key to doing
this right is to have the applet be compiz-aware, and use the proper
API if it's running; it'll be interesting to see what the patches do.

Looking forward to collaborating with you on a solution.

Kind regards,
-Paul Reiber
Phone: (210)854-8253
Email: <email address hidden>
Web: http://bit.ly/reiber

On Sat, May 22, 2010 at 9:32 AM, Ryan Beard <email address hidden> wrote:
> Thanks Paul.  I've downloaded the Grub development kit, and I'll be
> setting up conary today.  I'll let you how things go.
>
> -ryan
>
> On Fri, 2010-05-21 at 22:36 +0000, PaulReiber wrote:
>> Ryan,
>>
>> If you're willing to dig/investigate, code, debug, and submit, I'm
>> certainly willing to help.
>>
>> I've been programming/administering UNIX for ~30 years, Linux for ~15.
>> My strengths are... well, pretty wide-reaching, but not so much in the
>> GUI/Gnome/Window-manager/Virtual-Desktop coding details, or I would
>> have fixed this myself a long time ago.
>>
>> Let me know if/when you get stuck and I'll do my best to get you
>> un-stuck.  Contact me off-list at <email address hidden> any time.
>>
>> Kind regards,
>> -Paul Reiber
>>
>>
>> On Fri, May 21, 2010 at 2:48 PM, Ryan Beard <email address hidden> wrote:
>> > Paul -
>> >
>> > I'm actually referring to the patch attached to this bug (posted in
>> > comment #34: betterpatch.diff).  It appears to target pager.c, but I
>> > can't find that file in 10.04.
>> >
>> > I haven't researched the Fedora patch yet, but I will look into that.
>> >
>> > I'm new to Gnome, and linux in general (been an
>> > OpenSuse/Kubuntu/LinuxMint user for the past year), but I actually
>> > noticed this bug within the first 30 minutes after installation.  I'd
>> > like to help if at all possible (I was a heavy .net programmer, but I've
>> > been living in Qt Creator for the last 6 months), but I figured I should
>> > start with whatever work has already been accomplished - this patch, and
>> > the alleged Fedora patch - and build from there.
>> >
>> > Thanks for the help.
>> >
>> > --
>> > Can't drag a window to another workspace
>> > https://bugs.launchpad.net/bugs/150690
>> > You received this bug notification because you are a direct subscriber
>> > of a duplicate bug.
>> >
>>
>
> --
> Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

Paul - I had a similar prognosis. My initial plan is to develop a
universal workspace switcher - one that will query (and monitor) the
window manager to determine the compositing engine, and then play along.
I'm reading up on some of the compiz APIs now. I'd really like to
incorporate some additional GUI mechanisms while I'm at it. For
example, I think it would greatly enhance the functionality to have OS X
Dock-like 'zoom-on-mouse-over' to allow for easier and more accurate
selection/placement of windows within the applet. I probably won't get
started coding until Monday, but hopefully I can have something to play
with next week. This will be a bit of a learning experience for me, but
I figure this is a good place to get introduced to linux development.

-ryan

On Sat, 2010-05-22 at 19:41 +0000, PaulReiber wrote:
> Ryan - here's my understanding of this issue. I believe, at the heart
> of the issue is that Compiz handles virtual desktops quite differently
> than Metacity.
>
> Because of this, it "fakes" any apps using the Metacity virtual
> desktop API into thinking there's only one virtual desktop. I'm not
> sure of the details of how it does this; review the thread on this bug
> for some leads (hopefully).
>
> I haven't reviewed any of the patches that've been identified, because
> they slipped my attention; I wasn't aware any coding work had been
> done by anyone to attempt to address this. I believe the key to doing
> this right is to have the applet be compiz-aware, and use the proper
> API if it's running; it'll be interesting to see what the patches do.
>
> Looking forward to collaborating with you on a solution.
>
> Kind regards,
> -Paul Reiber
> Phone: (210)854-8253
> Email: <email address hidden>
> Web: http://bit.ly/reiber
>
>
>
> On Sat, May 22, 2010 at 9:32 AM, Ryan Beard <email address hidden> wrote:
> > Thanks Paul. I've downloaded the Grub development kit, and I'll be
> > setting up conary today. I'll let you how things go.
> >
> > -ryan
> >
> > On Fri, 2010-05-21 at 22:36 +0000, PaulReiber wrote:
> >> Ryan,
> >>
> >> If you're willing to dig/investigate, code, debug, and submit, I'm
> >> certainly willing to help.
> >>
> >> I've been programming/administering UNIX for ~30 years, Linux for ~15.
> >> My strengths are... well, pretty wide-reaching, but not so much in the
> >> GUI/Gnome/Window-manager/Virtual-Desktop coding details, or I would
> >> have fixed this myself a long time ago.
> >>
> >> Let me know if/when you get stuck and I'll do my best to get you
> >> un-stuck. Contact me off-list at <email address hidden> any time.
> >>
> >> Kind regards,
> >> -Paul Reiber
> >>
> >>
> >> On Fri, May 21, 2010 at 2:48 PM, Ryan Beard <email address hidden> wrote:
> >> > Paul -
> >> >
> >> > I'm actually referring to the patch attached to this bug (posted in
> >> > comment #34: betterpatch.diff). It appears to target pager.c, but I
> >> > can't find that file in 10.04.
> >> >
> >> > I haven't researched the Fedora patch yet, but I will look into that.
> >> >
> >> > I'm new to Gnome, and linux in general (been an
> >> > OpenSuse/Kubuntu/LinuxMint user for the past year), but I actually
> >> > noticed this bug within the first 30...

Go, Ryan, Go! Wahoo!

Kind regards,
-Paul Reiber
Phone: (210)854-8253
Email: <email address hidden>
Web: http://bit.ly/reiber

On Sat, May 22, 2010 at 7:21 PM, Ryan Beard <email address hidden> wrote:
> Paul -  I had a similar prognosis.  My initial plan is to develop a
> universal workspace switcher - one that will query (and monitor) the
> window manager to determine the compositing engine, and then play along.
> I'm reading up on some of the compiz APIs now.  I'd really like to
> incorporate some additional GUI mechanisms while I'm at it.  For
> example, I think it would greatly enhance the functionality to have OS X
> Dock-like 'zoom-on-mouse-over' to allow for easier and more accurate
> selection/placement of windows within the applet.  I probably won't get
> started coding until Monday, but hopefully I can have something to play
> with next week.  This will be a bit of a learning experience for me, but
> I figure this is a good place to get introduced to linux development.
>
> -ryan
>
> On Sat, 2010-05-22 at 19:41 +0000, PaulReiber wrote:
>> Ryan - here's my understanding of this issue.  I believe, at the heart
>> of the issue is that Compiz handles virtual desktops quite differently
>> than Metacity.
>>
>> Because of this, it "fakes" any apps using the Metacity virtual
>> desktop API into thinking there's only one virtual desktop.  I'm not
>> sure of the details of how it does this; review the thread on this bug
>> for some leads (hopefully).
>>
>> I haven't reviewed any of the patches that've been identified, because
>> they slipped my attention; I wasn't aware any coding work had been
>> done by anyone to attempt to address this.  I believe the key to doing
>> this right is to have the applet be compiz-aware, and use the proper
>> API if it's running; it'll be interesting to see what the patches do.
>>
>> Looking forward to collaborating with you on a solution.
>>
>> Kind regards,
>> -Paul Reiber
>> Phone: (210)854-8253
>> Email: <email address hidden>
>> Web: http://bit.ly/reiber
>>
>>
>>
>> On Sat, May 22, 2010 at 9:32 AM, Ryan Beard <email address hidden> wrote:
>> > Thanks Paul.  I've downloaded the Grub development kit, and I'll be
>> > setting up conary today.  I'll let you how things go.
>> >
>> > -ryan
>> >
>> > On Fri, 2010-05-21 at 22:36 +0000, PaulReiber wrote:
>> >> Ryan,
>> >>
>> >> If you're willing to dig/investigate, code, debug, and submit, I'm
>> >> certainly willing to help.
>> >>
>> >> I've been programming/administering UNIX for ~30 years, Linux for ~15.
>> >> My strengths are... well, pretty wide-reaching, but not so much in the
>> >> GUI/Gnome/Window-manager/Virtual-Desktop coding details, or I would
>> >> have fixed this myself a long time ago.
>> >>
>> >> Let me know if/when you get stuck and I'll do my best to get you
>> >> un-stuck.  Contact me off-list at <email address hidden> any time.
>> >>
>> >> Kind regards,
>> >> -Paul Reiber
>> >>
>> >>
>> >> On Fri, May 21, 2010 at 2:48 PM, Ryan Beard <email address hidden> wrote:
>> >> > Paul -
>> >> >
>> >> > I'm actually referring to the patch attached to this bug (posted in
>> >> > comment #34: betterpatch.diff).  It appears to target pager.c, but I
>> >> > can't find that file...

In my opinion the whole workspace thing is a hack implemented against the
way X is supposed to work. Each workspace is not traditionally addressable.
 E.g. I cannot choose which workspace/pane my windowed application opens in
- it's always the current one. E.g both

xterm -display :0 &
xterm -display :0.0 &

open a window in the current workspace but

xterm -display :0.1 &

fails with an error. In my opinion

xterm -display :0 &

should best open in the first (or, better, current) workspace on the current
X server

xterm -display :0.0 &

should open in the 1st workspace and

xterm -display :0.1 &

should open in the 2nd etc

Even if you "fix" the current problem the original hack remains. Workspaces
should have been implemented differently. Having said that I am very much
in favour of a fix to the hack rather than the current situation.

Paul Beardsell
(another Paul)

On 23 May 2010 02:21, Ryan Beard <email address hidden> wrote:

> Paul - I had a similar prognosis. My initial plan is to develop a
> universal workspace switcher - one that will query (and monitor) the
> window manager to determine the compositing engine, and then play along.
> I'm reading up on some of the compiz APIs now. I'd really like to
> incorporate some additional GUI mechanisms while I'm at it. For
> example, I think it would greatly enhance the functionality to have OS X
> Dock-like 'zoom-on-mouse-over' to allow for easier and more accurate
> selection/placement of windows within the applet. I probably won't get
> started coding until Monday, but hopefully I can have something to play
> with next week. This will be a bit of a learning experience for me, but
> I figure this is a good place to get introduced to linux development.
>
> -ryan
>
> On Sat, 2010-05-22 at 19:41 +0000, PaulReiber wrote:
> > Ryan - here's my understanding of this issue. I believe, at the heart
> > of the issue is that Compiz handles virtual desktops quite differently
> > than Metacity.
> >
> > Because of this, it "fakes" any apps using the Metacity virtual
> > desktop API into thinking there's only one virtual desktop. I'm not
> > sure of the details of how it does this; review the thread on this bug
> > for some leads (hopefully).
> >
> > I haven't reviewed any of the patches that've been identified, because
> > they slipped my attention; I wasn't aware any coding work had been
> > done by anyone to attempt to address this. I believe the key to doing
> > this right is to have the applet be compiz-aware, and use the proper
> > API if it's running; it'll be interesting to see what the patches do.
> >
> > Looking forward to collaborating with you on a solution.
> >
> > Kind regards,
> > -Paul Reiber
> > Phone: (210)854-8253
> > Email: <email address hidden>
> > Web: http://bit.ly/reiber
> >
> >
> >
> > On Sat, May 22, 2010 at 9:32 AM, Ryan Beard <email address hidden>
> wrote:
> > > Thanks Paul. I've downloaded the Grub development kit, and I'll be
> > > setting up conary today. I'll let you how things go.
> > >
> > > -ryan
> > >
> > > On Fri, 2010-05-21 at 22:36 +0000, PaulReiber wrote:
> > >> Ryan,
> > >>
> > >> If you're willing to dig/investigate, code, debug, and submit, I'm
> > >> c...

I wish I had the time and skill to help.
But if the expo function code was used it might give even more dynamic look.
Example attached.

Paul Beardsell wrote:
> In my opinion the whole workspace thing is a hack implemented against the
> way X is supposed to work. Each workspace is not traditionally addressable.
> E.g. I cannot choose which workspace/pane my windowed application opens in
...
> fails with an error. In my opinion
>
> xterm -display :0 &
>
> should best open in the first (or, better, current) workspace on the current
> X server
>
> xterm -display :0.0 &
>
> should open in the 1st workspace and
>
> xterm -display :0.1 &
>
> should open in the 2nd etc

I think you have a misunderstanding of how the display parameter works -
from 'man X':
---8<---
DISPLAY NAMES
       From the user's perspective, every X server has a display name of the form:
                                                              hostname:displaynumber.screennumber
...
  screennumber
               Some displays share their input devices among two or more monitors. These may be configured as a single logical screen, which allows windows to move across screens, or as individual screens, each with their own set of windows. If configured such that each monitor has its own set of windows, each screen is assigned a screen number (beginning at 0) when the X server for that display is started. If the screen number is not given, screen 0 will be used.
---8<---

In a nutshell, X11 allows you to address a machine, then a server on that machine, then a specific logical screen on that server (for example when running with dual monitors and without Xinerama). Window managers add on top of that the notion of workspaces, but it was never something inherent in X. Granted different window manager implement workspaces in different and conflicting manners, but that is not because of some misuse of X semantics.

Freedesktop.org's window manager spec (EWMH) has this to say about workspaces (http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552820):
---8<---
This spec assumes a desktop model that consists of one or more completely independent desktops which may or may not be larger than the screen area. When a desktop is larger than the screen it is left to the Window Manager if it will implement scrolling or paging.
...
Window Managers that require / desire additional functionality beyond what can be achieved using the mechanisms set out in this specification may choose to implement their own pagers, which communicate with the Window Manager using further, window manager specific hints, or some other means.
---8<---

In a nutshell "we don't know what to tell you, go ahead and do what you want". Oh well.

I'm not sure I would change hardly a word of my posting. It seems to me the
multi-monitor Unix systems I was lucky enough to work on sometimes in the
1990's could have been implemented just as poorly as the multi-workspace
idea we have in Gnome and similar on Linux. But they were not. If I wanted
an app's display to open on a particular workspace on a monitor I could do
so by specifying '-display xxxx:0.3' or to choose a particular monitor I
could use '-display xxxx:3'. We miss a trick or two now. And whereas
implmentation details are left unspecified the intention is clear. Where
and when do we get the opportunity to use anything other than :0.0 on a
modern Linux box, now? If that was sorted then this bug would not exist in
its current form i.e. with a workaround simply being to disable Compiz.

Paul Beardsell
<email address hidden>

On 23 May 2010 18:41, Oded Arbel <email address hidden> wrote:

> Paul Beardsell wrote:
> > In my opinion the whole workspace thing is a hack implemented against the
> > way X is supposed to work. Each workspace is not traditionally
> addressable.
> > E.g. I cannot choose which workspace/pane my windowed application opens
> in
> ...
> > fails with an error. In my opinion
> >
> > xterm -display :0 &
> >
> > should best open in the first (or, better, current) workspace on the
> current
> > X server
> >
> > xterm -display :0.0 &
> >
> > should open in the 1st workspace and
> >
> > xterm -display :0.1 &
> >
> > should open in the 2nd etc
>
> I think you have a misunderstanding of how the display parameter works -
> from 'man X':
> ---8<---
> DISPLAY NAMES
> From the user's perspective, every X server has a display name of the
> form:
>
> hostname:displaynumber.screennumber
> ...
> screennumber
> Some displays share their input devices among two or more
> monitors. These may be configured as a single logical screen, which allows
> windows to move across screens, or as individual screens, each with their
> own set of windows. If configured such that each monitor has its own
> set of windows, each screen is assigned a screen number (beginning at 0)
> when the X server for that display is started. If the screen number is not
> given, screen 0 will be used.
> ---8<---
>
> In a nutshell, X11 allows you to address a machine, then a server on
> that machine, then a specific logical screen on that server (for example
> when running with dual monitors and without Xinerama). Window managers
> add on top of that the notion of workspaces, but it was never something
> inherent in X. Granted different window manager implement workspaces in
> different and conflicting manners, but that is not because of some
> misuse of X semantics.
>
> Freedesktop.org's window manager spec (EWMH) has this to say about
> workspaces (
> http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552820):
> ---8<---
> This spec assumes a desktop model that consists of one or more completely
> independent desktops which may or may not be larger than the screen area.
> When a desktop is larger than the screen it is left to the Window Manager if
> it will implement scrolling or paging.
> ...
> Window Managers that...

On Sun, May 23, 2010 at 12:17 PM, Paul Beardsell <email address hidden> wrote:
> I'm not sure I would change hardly a word of my posting.  [...]

Me either; deficiencies are deficiencies, and X has some.

Paul, check out this tool: http://foosel.org/linux/devilspie

I think you'll be a happy camper unless you're allergic to things that
look like lisp.

Kind regards,
-Paul Reiber
Email: <email address hidden>
Web: http://bit.ly/reiber

Followup: the link I posted before is to a great documentation site;
the Devils Pie website itself is:
http://www.burtonini.com/blog/computers/devilspie

Aside: Please, let's try to keep messages to
<email address hidden> relevant to Bug 150690. (I know, I'm as
guilty as the next guy...)

Kind regards,
-Paul Reiber
Email: <email address hidden>
Web: http://bit.ly/reiber

On Sun, May 23, 2010 at 6:59 PM, Paul Reiber <email address hidden> wrote:
> On Sun, May 23, 2010 at 12:17 PM, Paul Beardsell <email address hidden> wrote:
>> I'm not sure I would change hardly a word of my posting.  [...]
>
> Me either; deficiencies are deficiencies, and X has some.
>
> Paul, check out this tool:  http://foosel.org/linux/devilspie
>
> I think you'll be a happy camper unless you're allergic to things that
> look like lisp.

On Sun, 2010-05-23 at 17:17 +0000, Paul Beardsell wrote:
> If I wanted
> an app's display to open on a particular workspace on a monitor I could do
> so by specifying '-display xxxx:0.3' or to choose a particular monitor I
> could use '-display xxxx:3'. We miss a trick or two now. And whereas
> implmentation details are left unspecified the intention is clear. Where
> and when do we get the opportunity to use anything other than :0.0 on a
> modern Linux box, now?

I would like you to know that multiple X servers on a single box are
used heavily in enterprise and academic installations to run thin X
clients, and multi-screen X servers (not Xinerama) are used to provide
multiple consoles on a single desktop computer in many educational
installations as well as a few home installations I've seen.

Please don't knock off existing functionality just because you don't
understand what it is used for - it is often there to provide for a
legitimate need that cannot be satisfied otherwise, even if you have not
personally have required it.

> If that was sorted then this bug would not exist in
> its current form i.e. with a workaround simply being to disable Compiz.

I don't agree, and I think the implementation details for workspace
management and paging should stay firmly inside a specific WM's
implementation. I might be a good idea to specify a freedesktop.org API
for pagers to talk to window managers, but if you've hardcoded in a spec
how workspaces should be implemented then a lot of cool things like
GNOME Shell's dynamic workspaces wouldn't happen (or be so much harder
to implement).

--
Oded Arbel <email address hidden>

I had not realised I was criticising you so very personally as to provoke
that outburst.

Perhaps it is you who misunderstand. The current workaround for this bug is
to disable compiz. But, one has to ask, and this is my point: Why should
compiz even have the opportunity of breaking workspaces? Were the
underlying design better then compiz would need to know *nothing* of
workspaces. A way, perhaps, to have a better design, would be to have the
workspace functionality built in at a more fundamental lower level within
Gnome etc. Perhaps my suggestion is flawed, perhaps not, BUT either way:
that compiz breaks this aspect of workspace functionality shows something is
wrong - something is too closely coupled to something else.

And, whatever you say, it would be very neat to have the various workspaces
addressable as :0.0, :0.1, :0.2 etc etc This suggestion would not break the
thin client functionality to which you allude.

Paul Beardsell

On 24 May 2010 10:09, Oded Arbel <email address hidden> wrote:

> On Sun, 2010-05-23 at 17:17 +0000, Paul Beardsell wrote:
> > If I wanted
> > an app's display to open on a particular workspace on a monitor I could
> do
> > so by specifying '-display xxxx:0.3' or to choose a particular monitor I
> > could use '-display xxxx:3'. We miss a trick or two now. And whereas
> > implmentation details are left unspecified the intention is clear. Where
> > and when do we get the opportunity to use anything other than :0.0 on a
> > modern Linux box, now?
>
> I would like you to know that multiple X servers on a single box are
> used heavily in enterprise and academic installations to run thin X
> clients, and multi-screen X servers (not Xinerama) are used to provide
> multiple consoles on a single desktop computer in many educational
> installations as well as a few home installations I've seen.
>
> Please don't knock off existing functionality just because you don't
> understand what it is used for - it is often there to provide for a
> legitimate need that cannot be satisfied otherwise, even if you have not
> personally have required it.
>
> > If that was sorted then this bug would not exist in
> > its current form i.e. with a workaround simply being to disable Compiz.
>
> I don't agree, and I think the implementation details for workspace
> management and paging should stay firmly inside a specific WM's
> implementation. I might be a good idea to specify a freedesktop.org API
> for pagers to talk to window managers, but if you've hardcoded in a spec
> how workspaces should be implemented then a lot of cool things like
> GNOME Shell's dynamic workspaces wouldn't happen (or be so much harder
> to implement).
>
> --
> Oded Arbel <email address hidden>
>
> --
> Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Does anyone have a fix for lucid? This is ridiculous, after 3 years man, still nothing.

The only available workaround: Disable compiz. Compiz is but eye-candy, you
and your users will prefer Ubuntu with unbroken multiple workspaces. And
candy isn't good for you :-)

Some would say that complaining about this bug means:
* you misunderstand the Ubuntu bug reporting politics
* you are ungrateful about others' hard work
* you do not understand how X11 ought to work
* you are mentally unstable and ought to switch to Windows XP

I'm now compiz free for 18 months. One day at a time.

Paul Beardsell
<email address hidden>

On 14 June 2010 03:29, eats7 <email address hidden> wrote:

> Does anyone have a fix for lucid? This is ridiculous, after 3 years man,
> still nothing.
>
> --
> Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I'll admit i'm a novice at linux but i do use compiz for more than eyecandy. i use it for its expose like qualities, and coming from a mac, it's hard to get un-used to it lol. i don't mean to sound ungrateful. but i just think about how long this bug has been here, and all the people it affects, something should have been done by now more than just "disabling it". and dont even get me started on the external monitor problems with compiz.

I don't think anyone's ungrateful. The problem is that the default is broken. On my system, "Normal" visual effects are enabled by default (resulting in Compiz being used). In that configuration, I cannot drag windows between workspaces - making the tooltips a liar. Can I survive without Compiz? Of course. But new users are going to be confused when a tooltip tells them they can do something and then they can't, especially when they're running the default configuration. It reflects poorly on the system.

Paul Beardsell wrote on 2010-06-15:
The only available workaround: Disable compiz. Compiz is but eye-candy, you
and your users will prefer Ubuntu with unbroken multiple workspaces. And
candy isn't good for you :-)

Some would say that complaining about this bug means:
* you misunderstand the Ubuntu bug reporting politics
* you are ungrateful about others' hard work
* you do not understand how X11 ought to work
* you are mentally unstable and ought to switch to Windows XP

I'm now compiz free for 18 months. One day at a time.

Paul Beardsell
<email address hidden>

On 14 June 2010 03:29, eats7 <email address hidden> wrote:

> Does anyone have a fix for lucid? This is ridiculous, after 3 years man,
> still nothing.
>
> --
> Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Using Exposé is a little workaround.

In Exposé-View you can drag an drop app-windows. Its very fast, you dont need to press any button, just assign one edge to exposé.

What you can't do with expose but with workplace switcher is for example drag an image from a firefox window, hover over a different workspace in the switcher. This switches workspace to the application that is waiting for the dragged input image.

Ugh. So yeah, these Compiz/Workspace Switcher bugs still obviously exist.

1. Can't use mouse wheel to scroll workspaces in the switcher.
2. Can't drag from the window list to the workspace switcher to send a window to another workspace.
3. Can't drag a window from the window switcher and drop it on itself to do the same thing.

Those are three things I do often in Metacity that I can't do in Compiz. These issues are literally the only reasons I have Visual Effects set to None. I don't understand why I can't at least use my mouse wheel to change workspaces in the switcher when clicking works.

The bug there is nontrivial to change, not really an hundredpapercut task but rather a lot of libwnck changes

Closing papercut task as per Sebastien's comment.

Closing this, marking it "invalid", is inappropriate. "100 paper cuts"
doesn't mean 100 trivial bugs which are easy to fix, it means 100 small
annoyances that piss off users, particularly newbie ones who don't know the
workarounds. Please UNDO this change of status.

Paul Beardsell
<email address hidden>

On 17 August 2010 09:18, Vish <email address hidden> wrote:

> Closing papercut task as per Sebastien's comment.
>
> ** Changed in: hundredpapercuts
> Status: Triaged => Invalid
>
> --
> Can't drag a window to another workspace
> https://bugs.launchpad.net/bugs/150690
> You received this bug notification because you are a direct subscriber
> of the bug.
>

On Tue, 2010-08-17 at 08:40 +0000, Paul Beardsell wrote:
> Closing this, marking it "invalid", is inappropriate. "100 paper cuts"
> doesn't mean 100 trivial bugs which are easy to fix, it means 100 small
> annoyances that piss off users, particularly newbie ones who don't know the
> workarounds. Please UNDO this change of status.
>
A paper cut should be a small usability issue, in the default Ubuntu install, that affects many people and is quick and easy to fix.
-For further information about papercuts criteria, please read https://wiki.ubuntu.com/PaperCut.

Don't worry though, this bug has been marked as "Invalid" only in the papercuts project.

"Disable compiz" isn't a sensible workaround for this bug. Compiz offers more than eye candy. Many new users wouldn't know how to replace it with xfwm4 and would be stuck with metacity, so they'd be replacing a window manager with a problem that can be worked around (Expo etc) with one which is unusable by design.

Bump, since the problem is also present in 10.10.

... and another bump, couple of months later.

Stanislaw, Corona: patches welcomed!

Added as dub bug 789381 - still exists in clean 10.04.2

in clean Ubuntu 10.04.2 Workspace Switcher cant drag windows onto other workspaces
see video http://videobin.org/+4j6/4wv.html it has 3 bugs about workspace switcher

Problem still persists in Natty.

HAL kr LOWEEN SA pua LES!
EVERYTHING YOU NEED for a great and exciting day you can buy HERE!
Only TODAY ANY GOODS you can get with a next code 4437 which gives you a 40% dis jh count.
Be prepared for a scary day and make a show!

Get the great di dal scou be nts on popular so hn ft lv wa etj re today at www.greatrivercityone.com.ua
All s oq of xwx wa za re is instantly available to do vuc wnl pf oad - No Need Wait!
ALL OUR SO xkx FTW nkm ARE bs S ON ALL EUROPEAN LANGUAGES -
USA, English, France, Italy, Spanish, German and more!!!

SO kw FTW wf ARE:Windows 7 Ultimate 32 bit99.95Windows 7 Ultimate 64 bit99.95Windows XP Professional with Service Pack 369.95Office Professional Plus 2010 32-bit89.95Office Professional Plus 2010 64-bit89.95Adobe Photoshop CS5.1 Extended99.95Office Professional 200769.95Adobe Acrobat 9 Pro Extended59.95Office Home and Student 200749.95
Also we have so mu lx ch s pk of qe t for MA pg CIN cp TO phv SH!!!Adobe Creative Suite 5.5 Master Collection for MAC269.95Adobe Creative Suite 5.5 Design Premium for MAC219.95Microsoft Office 2008 Standart Edition for MAC119.95Aperture 3 for MAC79.95Adobe Photoshop CS5.1 Extended for MAC89.95
To re gbd vi qj ew full list of the offers, v cvi is qvi it www.greatrivercityone.com.ua

Sebastien,

This bug is marked as affecting nearly 5 dozen people. Some (including me) consider it a regression, as the functionality used to work.

It has 12 other bugs (affecting who knows how many people) all marked as duplicates. It was reported in 2007, possibly one or more of the 12 duplicates is even older than that. Who knows.

While I guess it's certainly your prerogative to decide to decline to fix this, it really would be nice to see the functionality, or similar, added back into the software.

Thanks in advance, and here's hoping this matter can be resolved within the next few years - before its 10th birthday in 2017.

I think this bug broke my desktop when upgrading to Ubuntu 17, but I'm not sure if it's the originally reported component that has the bug as I don't know if the re-write for gnome 3 that was mentioned above actually happened.

In any case, why are the compiz packages available for new installations if they are clearly broken and won't be fixed?