euclid-0.2.alpha1 multihead

[diem]

I've started work on multihead support in a svn branch.
It is now to the point that it appears stable (I'm using it now on my
single monitor computer and have had no problems so far).
However, as my setup is single head, and I've missed lots of bugs in
the past, I decided it would be a good time to stick a tarball up and
see if I could get some testers. So it is now available for download.

To switch between monitors use PgUp and PgDown. I'd like to change
this before 0.2.0 comes out, but for initial testing it should work
fine.

The only bug I can predict is that moving to the next and previous
layouts won't do anything if those layouts are already displayed on
another monitor (e.g., if screen 1 is showing layout 1, screen 2
layout 2, you are on screen 1, and you hit alt + m to go to view 2, it
won't shouldn't do anything at all); You will have to use alt + num to
jump past view 2 (or switch to screen2, bring up a different view,
then go back to screen 1, and goto view 2). I plan to correct this
behavior in the future.

Anything else unexpected is probably a bug.

So in sum, if you have a few minutes, please give it a try (even if
you can only try it on a single screen machine, I want this to work on
both and a LOT of things got changed, so there was plenty of
opportunity for bugs to creep in). Of course if you have a multiscreen
setup, please give it a try there.

Thanks.
Cheers,
Will

[BKLive]

So based on your description of expected behavior, is it treating
things as Screen[n][m] where 'n' is the physical monitor and 'm' is
the view (or desktop)? And if I'm wrong (probably true), then I wonder
if dual head support would be better handled by having separate
desktop instances for each screen? Like screen (physical) 1 should
have 9 desktops, and screen 2 should have 9?

Feasibly (talking myself out of it) it would make more sense to have
screen[n][m] where n is just the physical location of the desktop 'm'.
This way you can show desktop 1 on screen 1 and desktop 2 on screen 0,
then move windows between the normal tab order of desktops (alt+shift+$
(m)) without having to specify which monitor to send it to (with what
I believe is the pageup/down purpose you've created). Should it be
more naturally supported as the normal list of desktops (m) and then
just page xinerama (if this is how this works) for the number of
working monitors, then sublet the array to allow for different display
locations (+=n) and then just push by default desktops 1 and 2 to
screens 0 and 1 (or 1 and 2, whatever)?

The way I'm reading your changes looks like you're trying to implement
a function you don't have by using a workaround that isn't necessary
if you had the extra hardware. Something like this. Like if you had
two monitors, there would be no need to change monitor screens with
pageup/down, unless I'm missing what the purpose of these are?

Great work on continuing the development! I had hoped dual-screen
would be next, because my home computer (actually at home) has
multiple screens, and I want to push euclid to it, but can't without
the support. I will try and find another monitor around here (actually
not at home) I can plug in for testing for the next 10 days or so (the
remainder of my term, mostly). I'll see what I can do!

BKL

[BKLive]

Also, as I believe this was the intent of having two AUR versions of
euclid, I updated the svn version of the PKGBUILD to reflect the
branches/multihead svn trunk instead of the base code. I also relabled
it as the "Testing version of euclid-wm...." or some such thing. I
can't really change the name of the package once in AUR, so I will
just update the svn with whatever new changes you're trying to
implement. Deal? Nice...

BKL

[BKLive]

so another question is: since you are now making changes to the normal
trunk and the branch/multihead section of code, should I (or do you
want this) create an alpha version for AUR, update 0.1.1 to the 0.2.a2
version, or just leave the svn as the normal trunk and allow people to
figure out how to get the alpha?

Kind of limits the testing base of the alpha release, so I wanted to
know your idea for it.

BK

On Aug 1, 11:53 pm, diem <wmd...@gmail.com> wrote:

[William Diem]

On 3 August 2010 14:57, BKLive <benjami...@gmail.com> wrote:
> so another question is: since you are now making changes to the normal
> trunk and the branch/multihead section of code, should I (or do you
> want this) create an alpha version for AUR, update 0.1.1 to the 0.2.a2
> version, or just leave the svn as the normal trunk and allow people to
> figure out how to get the alpha?
>
> Kind of limits the testing base of the alpha release, so I wanted to
> know your idea for it.
>> BK

Offhand I'd say it would make sense to keep the svn package pointing
to trunk (as long as development is still going on there anyway). When
I think the multihead branch is getting there (at least not
introducing regressions, even if it still has some issues on new
features) I will merge it into trunk.

I the meantime, people who want to test the multihead branch can do so
either by using svn, or from the tarball snapshot.

Either way would work though. As long as there is a stable version
that people who don't want to deal with development issues can
install, I'm not too worried about it.

But at the end of the day, that's your call.
Will

[William Diem]

On 2 August 2010 15:21, Benjamin Kuhns <benjami...@gmail.com> wrote:
> I think multiple screen-to-desktop arrays would be more useful rather than
> just simple to implement. I think most people have three or four desktops
> (like me) where all their work gets done (don't have to move the hands off
> the keys) and the other desktop is for miscellaneous screens. I've rarely
> seen a person implement two desktops with the intent of working on a screen
> out of their line-of-sight. Maybe this is from lack of "experience" with
> people using multiple heads, but it seems that the primary of work done on
> the one screen would be best kept with its own array. Then if people DO use
> two monitors for work on BOTH screens, then they have multiple instances to
> work (1-4, using my previous example) without having to move through the
> rest of the tab order (and not just for finger-movement limitation, either).
> I think, in essence, it makes more sense to do it this way.

Well, at this point I want to get some sort of basic, minimally useful
multiscreen working (mainly I want to know that what I have now is
working). At this point, doing a separate set of layouts for each
screen would involve redoing a fair amount of code. So let's return to
this issue, after the current implementation is known to work at least
for the most part.

> Similarly, I
> also think it would be a good idea to enable GIANT VIEW mode where the
> second screen just acts like a continuation of the present screen (drag and
> drop not really applicable, but warranting my point). The issue is drawing
> the screen, which isn't a real issue -> window one opens on screen one,
> window two on screen two (still desktop 1), window 3 breaks window 1 in half
> on page, etc.
>
> Some ideas, again, with limited knowledge of how it "works".

This was one of the possibilities I considered, before starting, but
it seemed too limited as the sole way to handle multiscreen. As an
additionally feature, I think this should be considered a phase three
proposal, i.e., something to revisit once we have some sort of
multiscreen working.

So, to both of these, let's come back once we have something to work with.

Thanks,
Will