Hi,
hg2398 works fine for me. I can even switch between clients on the
screens with the keyboard. Very nice. The only serious problem I have is
a spurious window border, I posted a bug report on the Google thing.
I think it would be sufficient if the bar was only present on one
screen, because the bar on the second screen would not give more
information. It would be nice to have something in /ctl which specifies
which screen the bar is on. wimenu can be on top of the other windows
when there is no bar, so no need for having wasted space. Just my thoughts.
As for the clients being lost when removing a screen: Couldn't you send
them all to the other screen when this happens? I know, everything gets
complicated when you have more than two screens. But a primary monitor
could be specified just like with the bar I wrote above.
When some commands for sending clients from one screen to another are
implemented, multi screen support would be pretty much complete for me.
Thanks for the nice features till now.
Thomas
Kris Maglione wrote:
> Hi,
>
> In response to the last thread, and as a general announcement, here's
> what's going on with the latest changes to the tree. First of all,
> please report any bugs you find to the Google issue tracker. I'm least
> likely to lose track of them that way.
>
> To start with, I've replaced dmenu with ‘wimenu’. It's very similar in
> appearance and behavior, but has a few significant enhancements. The
> biggest user-noticable change is the addition of an input caret. Now,
> you can type entire command lines without fear of having to start from
> scratch when you spot a typo. Second, it not supports command history.
> The -h flag specifies a history file to load, and the -n flag, when
> present, causes the menu to write back at most n history items to the
> history file. Third, you no longer need (or even can) specify colors,
> fonts, or positioning on the commandline. All such settings are read
> directly from wmii's /ctl. The same now goes for wmii9menu, which has
> also had its flags reduced to single letters. I hope not to make many
> such backwards-incompatible changes in the future. The wimenu does,
> and wmii9menu should in the future, support Xinerama and XRandR. At
> the moment, it opens on the screen that holds the pointer, but that
> will change to the screen with the focused client.
>
> I've also added Xinerama support, which is now usable, and seems to be
> stable, but is far from complete. As some of you have noticed, there's
> no way to modify the bar on the secondary screen. There's also only
> limited support for managed mode on any but the first screen. You can
> move clients into a column with the mouse, and basic keyboard
> manipulation will work, but the rest is yet to come. Fullscreen mode
> should now work fairly well. A fullscreen client will take whichever
> screen most of its window initially resides on. Floating clients don't
> yet care much which screen they open on. They'll pick whichever clear
> region of the screen seems smallest. XRandR screen switching should
> also work. For the moment, once you add a screen, there's no way to
> get rid of it. If you remove a screen, wmii will move all of its
> managed clients off-screen, and there's basically no way to get them
> back until you re-add the screen. In the future, I intend for logical
> screens to be independent of Xinerama screens. So, you'll be able to
> place any logical screen onto any Xinerama screen, and you'll even be
> able to place several logical screens onto one physical screen (so,
> the top may have two columns, the bottom one, for instance). This
> should make it easier to keep your managed area in order without
> worrying about clients getting dumped willy-nilly when you remove a
> separate monitor. I may, after some use, decide that we do, afterall,
> need a way to specify a separate view for each logical screen, but
> we'll see.
>
> Comments welcome.
-- Thomas Dahms Institut fuer Theoretische Physik, TU Berlin Hardenbergstr. 36, D-10623 Berlin web: http://www.itp.tu-berlin.de?dahms phone: +49 30 314-22088Received on Mon Oct 20 2008 - 08:07:39 UTC
This archive was generated by hypermail 2.2.0 : Mon Oct 20 2008 - 08:12:07 UTC