Undock windows to current workspace

[Michael B. Trausch]

Present situation: if I have a window on workspace 1, dock it, move to workspace 2 and undock, that doesn't work. I get an item in the window list, have to click that and then I move to the window on its workspace.

Desired behavior:

 * Undock in active workspace, or
 * Undock to original workspace and gain focus [Implemented already in 0.7.2dev, according to user's WM settings]

Potentially, add these as options in the context menu of the tray-icon for users to toggle.

[Michael B. Trausch (mtrausch)]

Accepting this bug for 0.7.3dev; will consider the user-option, but most likely will implement the first alternative over the second and not provide an option to keep the application simple and intuitive. Discussion on the latter is welcome, though.

[Michael B. Trausch (mtrausch)]

Realizing that my previous comment was somewhat ambiguous, discussion on whether or not to make this a user-switchable option is welcome. My tendency is to simpify the application as much as possible, and my original intent was to have no persistent configuration options since the functionality of AllTray is simply to dock applications into the system tray.

[Martin Koelewijn (vcoolio)]

Agreed with simple and intuitive. But there are two ways with pros and cons:
1. undock on active workspace: e.g. with email-client docked you want to be able to have a quick look at new messages, dock and be back where you were.
2. undock on original workspace: e.g. with several workspaces each with their own class of applications like a. office; b. browser ; c. chat/email; d. torrent/music. Then you wish to keep apps on their own workspaces.
Also: without options config in alltray: default undocking in active workspace would override wm-settings. If not in alltray, where would you change this setting?

Not sure what best way is. Maybe two options in context menu with possibility to switch default; or assigning options to left and middle mouse button.

[Michael B. Trausch (mtrausch)]

On Tue, 28 Apr 2009 12:22:22 -0000
Martin Koelewijn <email address hidden> wrote:
> Agreed with simple and intuitive. But there are two ways with pros
> and cons:
>
> 1. undock on active workspace: e.g. with email-client
> docked you want to be able to have a quick look at new messages, dock
> and be back where you were.
>
> 2. undock on original workspace: e.g. with several workspaces each
> with their own class of applications like a. office; b. browser ; c.
> chat/email; d. torrent/music. Then you wish to keep apps on their own
> workspaces.
>
> Also: without options
> config in alltray: default undocking in active workspace would
> override wm-settings. If not in alltray, where would you change this
> setting?

As far as remaining compliant with standards, there are three options
for AllTray, AFAIK:

  * Force bringing the application back up out of the dock onto the
    user's present workspace,
  * Force the changing of workspaces when bringing the application back
    up, or
  * Rely on the user's window manager to provide the correct behavior
    and do The Right Thing, leaving configuration in a single place
    (the user's window manager, if the window manager supports such
    configuration).

I _think_ that the most common setup (certainly the way that I use it)
would be either the first or third options. Currently, 0.7.2dev
implements the third option (letting the window manager deal with it,
we just hide/show the application at the user's request). This has the
advantage of keeping AllTray simple, but the potential disadvantage of
leaving advanced users who _only_ want to modify AllTray's behavior
when bringing applications up in the dust.

Perhaps the best thing to do would be to have the default remain the
way it is at present, and permit advanced users that just want to tweak
AllTray's “show” behavior to specify either a command line switch or
put an option in config file for AllTray. The former idea complicates
the command line, while the latter idea requires that someone fire up a
text editor. Though, the latter could be changed while AllTray is
_running_, and AllTray could, say, use SIGHUP as a signal to re-read
the config file and modify its running configuration appropriately.

> Not sure what best way is. Maybe two options in context menu with
> possibility to switch default; or assigning options to left and middle
> mouse button.

Hrm. Taking advantage of the middle button on the tray icon would be
an interesting idea. I hadn't thought of that.

A mapping such as the one below could be useful:

 * Left-click: Simple hide/show, the way 0.7.2dev does now,
 * Middle-click: Simple hide, but always show on current workspace,

And it would eliminate the need to have a command line switch or config
file to set the preference, because users that prefer one over the
other would just use the given mouse button. Though, if you're like me
and sometimes bump the middle button that could have strange and
unexpected effects.

My _gut_ says that the window manager should be used for this, though.
I'd love to hear from more users regarding opinions on that, but given
that the window manager, well, manages windows that ar...

[Michael B. Trausch (mtrausch)]

Hi Martin,

Can you try lp:alltray and tell me if the current behavior is good enough to close this bug? It doesn't move the window to the current workspace, but it does change the current workspace to go to the window.

Thanks!

[Michael B. Trausch (mtrausch)]

Hi Martin,

Can you try lp:alltray and tell me if the current behavior is good enough to close this bug? It doesn't move the window to the current workspace, but it does change the current workspace to go to the window.

If needed, I can provide a tarball for you.

Thanks!

[Michael B. Trausch (mtrausch)]

Blah, sorry for the stupid dupe, I pressed "submit" before I was done editing accidentally.

[Martin Koelewijn (vcoolio)]

Hello,

thanks for working on this. You're description sounds promising. I tried
to compile, but failed. First there was a complaint about libwnck-1.0
missing, which was fixed by installing libwnck-dev (this isn't very
clear now, so maybe mention it as a dependency when it's released). Then
it complained: ./configure: line xxxx: valac: command not found. So I
installed valac. Now it says "error: x11 not found in specified Vala API
directories".

If you know how to fix that, plz let me know. In the meantime your
solution seems certainly good enough to close the bug. I never wanted to
file a bug, it was just a feature request. Which seems to be implemented
now. So if my problem is difficult or unknown to you, don't invest too
much time and close the bug anyway. (on the other hand a release of
alltray should not prompt users with this error and scare them off, so
feel free to 'use' me for trouble shooting. I'm on Ubuntu Jaunty i386 by
the way.)

Looking forward to future alltray releases (I still use it),

Martin

On Sun, 2009-05-31 at 19:53 +0000, Michael B. Trausch wrote:
> Hi Martin,
>
> Can you try lp:alltray and tell me if the current behavior is good
> enough to close this bug? It doesn't move the window to the current
> workspace, but it does change the current workspace to go to the window.
>
> If needed, I can provide a tarball for you.
>
> Thanks!
>

[Michael B. Trausch (mtrausch)]

On Tue, 02 Jun 2009 19:48:25 -0000
Martin Koelewijn <email address hidden> wrote:

> thanks for working on this. You're description sounds promising. I
> tried to compile, but failed. First there was a complaint about
> libwnck-1.0 missing, which was fixed by installing libwnck-dev (this
> isn't very clear now, so maybe mention it as a dependency when it's
> released). Then it complained: ./configure: line xxxx: valac: command
> not found. So I installed valac. Now it says "error: x11 not found in
> specified Vala API directories".
>
> If you know how to fix that, plz let me know. In the meantime your
> solution seems certainly good enough to close the bug. I never wanted
> to file a bug, it was just a feature request. Which seems to be
> implemented now. So if my problem is difficult or unknown to you,
> don't invest too much time and close the bug anyway. (on the other
> hand a release of alltray should not prompt users with this error and
> scare them off, so feel free to 'use' me for trouble shooting. I'm on
> Ubuntu Jaunty i386 by the way.)
>
> Looking forward to future alltray releases (I still use it),

You'll need to get valac from git master (mirrored here on Launchpad
with bzr, as well). The reason is that you need a patch for Vala that
was only recently integrated into the mainline.

If you're using packaged Vala, you won't be able to build vala from git
without first upgrading to at least Vala 0.7.0, though 0.7.3 is
preferred. (Sorry, Vala is still young yet and going through lots of
change, though the pace on major, breaking changes is starting to slow
down a bit from what I gather.)

So:

 * Remove the Vala pulled from Ubuntu (0.5.something, way old).
 * Download Vala 0.7.3's tarball, ./configure && make && make install
   it.
 * Then, build Vala's latest available release from either git or bzr
   (the new repo for it --- lp:~vcs-imports/vala/new-trunk). You may
   need to install (some) dependencies to make that work, not sure.
   That contains a patch crucial to making AllTray build correctly with
   Vala due to some recent changes to bindings in Vala.
 * Then you should be able to build AllTray's trunk at lp:alltray to
   check out this change (and some of the others that are there now, if
   you're interested :)).

If you need any help, let me know. If you need a buildable tarball of
the Vala master source tree, I may be able to do that for you to
simplify things a bit.

 --- Mike

--
As iron sharpens iron, so one man sharpens another

[Martin Koelewijn (vcoolio)]

Hi, me again,

Your previous mail helped building 0.7.3, but now now on "make" for the
newest release with your patch I get:

make all-recursive
make[1]: Entering directory `/home/coolio/Desktop/vala'
Making all in gee
make[2]: Entering directory `/home/coolio/Desktop/vala/gee'
/usr/local/bin/valac -C --vapidir ./../vapi --pkg gobject-2.0 -H gee.h
--library gee arraylist.vala collection.vala collectionobject.vala
hashmap.vala hashset.vala iterable.vala iterator.vala list.vala map.vala
readonlycollection.vala readonlylist.vala readonlymap.vala
readonlyset.vala set.vala
/usr/local/bin/valac: symbol lookup error: /usr/local/bin/valac:
undefined symbol: vala_code_context_set_verbose_mode
make[2]: *** [gee.vala.stamp] Error 127
make[2]: Leaving directory `/home/coolio/Desktop/vala/gee'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/coolio/Desktop/vala'
make: *** [all] Error 2

What to do? Does it need an earlier new-trunk version? How to get that?
Regards,

Martin

On Tue, 2009-06-02 at 20:16 +0000, Michael B. Trausch wrote:
> On Tue, 02 Jun 2009 19:48:25 -0000
> Martin Koelewijn <email address hidden> wrote:
>
> > thanks for working on this. You're description sounds promising. I
> > tried to compile, but failed. First there was a complaint about
> > libwnck-1.0 missing, which was fixed by installing libwnck-dev (this
> > isn't very clear now, so maybe mention it as a dependency when it's
> > released). Then it complained: ./configure: line xxxx: valac: command
> > not found. So I installed valac. Now it says "error: x11 not found in
> > specified Vala API directories".
> >
> > If you know how to fix that, plz let me know. In the meantime your
> > solution seems certainly good enough to close the bug. I never wanted
> > to file a bug, it was just a feature request. Which seems to be
> > implemented now. So if my problem is difficult or unknown to you,
> > don't invest too much time and close the bug anyway. (on the other
> > hand a release of alltray should not prompt users with this error and
> > scare them off, so feel free to 'use' me for trouble shooting. I'm on
> > Ubuntu Jaunty i386 by the way.)
> >
> > Looking forward to future alltray releases (I still use it),
>
> You'll need to get valac from git master (mirrored here on Launchpad
> with bzr, as well). The reason is that you need a patch for Vala that
> was only recently integrated into the mainline.
>
> If you're using packaged Vala, you won't be able to build vala from git
> without first upgrading to at least Vala 0.7.0, though 0.7.3 is
> preferred. (Sorry, Vala is still young yet and going through lots of
> change, though the pace on major, breaking changes is starting to slow
> down a bit from what I gather.)
>
> So:
>
> * Remove the Vala pulled from Ubuntu (0.5.something, way old).
> * Download Vala 0.7.3's tarball, ./configure && make && make install
> it.
> * Then, build Vala's latest available release from either git or bzr
> (the new repo for it --- lp:~vcs-imports/vala/new-trunk). You may
> need to install (some) dependencies to make that work, not sure.
> That contains a patch crucial to making AllTray build correctly...

[Michael B. Trausch (mtrausch)]

On Tue, 02 Jun 2009 23:12:59 -0000
Martin Koelewijn <email address hidden> wrote:

> What to do? Does it need an earlier new-trunk version? How to get
> that? Regards,

Did you 'sudo ldconfig' after installing the Vala tarball?

 --- Mike

--
Fix the cause, not the symptom.
                            --- Steve Maguire

[Martin Koelewijn (vcoolio)]

Hi,
thanks for your fast replies. I have it running now. Undocking and
focussing to original workspace works fine. Some issues though:
- when I do "alltray -a" and click a window it creates an icon in the
systray, but doesn't dock the window. I have to minimize the window
before it does that. Is that on purpose?
- when I do "alltray -a" from commandline it gives the output "In
get_command_line()". Don't know if that's a problem.
- alltray doesn't work in Enlightenment anymore. The error is:
(alltray:16197): Wnck-CRITICAL **: wnck_window_get_pid: assertion
`WNCK_IS_WINDOW (window)' failed
The old version of alltray worked in E17, sort of, as it docked the app
but always undocked to workspace 2, no matter where it was docked or
where I undocked. But having alltray functional in E17 may not be a
priority since it's not commonly used and still in heavy development.
But I thought you should know about this worse functioning since it
renders alltray useless in E17 where it was useful despite the bug.

Thanks again and afaic you can close the bug. Should I file a bug for
the E17 thing or isn't that useful considering both the alpha status of
E17 and of this alltray trunk-version?

Martin

On Wed, 2009-06-03 at 06:25 +0000, Michael B. Trausch wrote:
> On Tue, 02 Jun 2009 23:12:59 -0000
> Martin Koelewijn <email address hidden> wrote:
>
> > What to do? Does it need an earlier new-trunk version? How to get
> > that? Regards,
>
> Did you 'sudo ldconfig' after installing the Vala tarball?
>
> --- Mike
>
> --
> Fix the cause, not the symptom.
> --- Steve Maguire
>

[Michael B. Trausch (mtrausch)]

  status fixcommitted
  tag user-verified
  done

On Wed, 03 Jun 2009 08:29:46 -0000
Martin Koelewijn <email address hidden> wrote:

> thanks for your fast replies. I have it running now. Undocking and
> focussing to original workspace works fine. Some issues though:
> - when I do "alltray -a" and click a window it creates an icon in the
> systray, but doesn't dock the window. I have to minimize the window
> before it does that. Is that on purpose?

To toggle whether an application is visible or not, just click on the
(newly created) tray icon. I can change AllTray such that when you use
the selector, the application hides right away, but my thought was that
might be confusing since AllTray handles whole applications instead of
single windows now. For example, if you run AllTray and click on a
gnome-terminal, and then click the gnome-terminal icon in the tray, you
will see all gnome-terminal windows hide.

AllTray will let you show/hide individual windows -- right-click on the
icon to see a menu that will let you do that.

> - when I do "alltray -a" from commandline it gives the output "In
> get_command_line()". Don't know if that's a problem.

Nope, that's a debugging message that I forgot to move to my debugging
infrastructure. That'll be fixed momentarily.

> - alltray doesn't work in Enlightenment anymore. The error is:
> (alltray:16197): Wnck-CRITICAL **: wnck_window_get_pid: assertion
> `WNCK_IS_WINDOW (window)' failed

What application did you try to dock where you got that on?

> The old version of alltray worked in E17, sort of, as it docked the
> app but always undocked to workspace 2, no matter where it was docked
> or where I undocked. But having alltray functional in E17 may not be a
> priority since it's not commonly used and still in heavy development.
> But I thought you should know about this worse functioning since it
> renders alltray useless in E17 where it was useful despite the bug.

AllTray should work in any environment that adheres to the current set
of standards --- if it doesn't, that is definitely a bug. If you could
file a new bug on that, I'd greatly appreciate it. Please include the
version of Enlightenment, whether it's a distribution or otherwise
pre-built package (and from where) or built from source (and
instructions, if possible, on replicating your setup, down to the
distribution), the name and version of the application you're trying to
dock, and the output of alltray when run like this:

  $ ALLTRAY_DEBUG=ALL ALLTRAY_OPTIONS=-D
  $ ./alltray (normal options)

Any other information would of course be appreciated. Thanks!

 --- Mike

--
I'm doing a (free) operating system (just a hobby, won't be big and
professional like gnu) for 386(486) AT clones.
                            --- Linus Torvalds