Suggestion on resolution change.

[Teika Kazura]

On Wed, 21 Oct 2009 20:37:39 +0200, Christopher Roy Bratusek wrote:
> [bugfix for] XRandR resolution-changed event.

I've heard that xRandR is not in ewmh. It seems to me that the future
compatible solution is to have a function in edge-flip.jl to update.
And users have to call manually that func after resolution change.

Must be easy, but I don't need it, so I won't do it right now.

I don't recommend to make resolution-change-hook in lack of the
standard.  Those who face this issue are encouraged to post code
snippets to ML or wiki, to make our understanding clear, though. Maybe
we'd better contact other WM community.

Does edge-flip work with multihead? (Ah, I'll take ostrich policy
here. ;)

Regards,
Teika (Teika kazura)

[Flashrider]

Am Montag, den 26.10.2009, 21:17 +0900 schrieb Teika Kazura:

> On Wed, 21 Oct 2009 20:37:39 +0200, Christopher Roy Bratusek wrote:
> > [bugfix for] XRandR resolution-changed event.
>
> I've heard that xRandR is not in ewmh. It seems to me that the future
> compatible solution is to have a function in edge-flip.jl to update.
> And users have to call manually that func after resolution change.
>
> Must be easy, but I don't need it, so I won't do it right now.
>
> I don't recommend to make resolution-change-hook in lack of the
> standard.  Those who face this issue are encouraged to post code
> snippets to ML or wiki, to make our understanding clear, though. Maybe
> we'd better contact other WM community.
>
> Does edge-flip work with multihead? (Ah, I'll take ostrich policy
> here. ;)
>
> Regards,
> Teika (Teika kazura)

Actually the bug also applies for all maximization options, especially
on Multihead. Therefore a resolution-changed-hook is recommended. Other
WMs (eg that M thing) listen to resolution changes. I guess E does, too,
as it also has edge-fliping.

Chris

[Flashrider]

Am Dienstag, den 27.10.2009, 22:18 +0100 schrieb Christopher Roy
Bratusek:

> Am Montag, den 26.10.2009, 21:17 +0900 schrieb Teika Kazura:
> > On Wed, 21 Oct 2009 20:37:39 +0200, Christopher Roy Bratusek wrote:
> > > [bugfix for] XRandR resolution-changed event.
> >
> > I've heard that xRandR is not in ewmh. It seems to me that the future
> > compatible solution is to have a function in edge-flip.jl to update.
> > And users have to call manually that func after resolution change.
> >
> > Must be easy, but I don't need it, so I won't do it right now.
> >
> > I don't recommend to make resolution-change-hook in lack of the
> > standard.  Those who face this issue are encouraged to post code
> > snippets to ML or wiki, to make our understanding clear, though. Maybe
> > we'd better contact other WM community.
> >
> > Does edge-flip work with multihead? (Ah, I'll take ostrich policy
> > here. ;)
> >
> > Regards,
> > Teika (Teika kazura)
>
> Actually the bug also applies for all maximization options, especially
> on Multihead. Therefore a resolution-changed-hook is recommended. Other
> WMs (eg that M thing) listen to resolution changes. I guess E does, too,
> as it also has edge-fliping.
>
> Chris

Plus letting the user manually update screen-width/screen-height and all
stuff making use of it is a no-go, if you ask me.

Regards,
Chris

[Teika Kazura]

On Tue, 27 Oct 2009 22:18:22 +0100, Christopher Roy Bratusek wrote:
> Other WMs (eg that M thing) listen to resolution changes. I guess E
> does, too,

Ok, so there's a way out. Hard study is waiting for us ;)

>> It seems to me that the future compatible solution is to have a
>> function in edge-flip.jl to update.  And users have to call
>> manually that func after resolution change.
>>
> Plus letting the user manually update screen-width/screen-height and all
> stuff making use of it is a no-go, if you ask me.

First I wrote the following answer, but I noticed it's wrong:
------------------------------------------------------------------------
I don't mean the manual update is the final solution, but
(edge-flip-update) is anyway necessary (and it will *never* introduce
any inconsistency), and it can be implemented easily by 1.6. You seem to
want it now, so I propose it as one of goals for 1.6.

Even if there's (edge-flip-update), users have to call it manually
until we support xrandr, which we don't have at all now. (And replace
Xinerama? ... ;/ )
------------------------------------------------------------------------
If resolutions can be changed per screen in RandR, then we need
complete rewritement?

According to Wikipedia, RandR still relies on xinerama, though the
latter is deprecated. Ehh, a conundrum.

Regards,
Teika (Teika kazura)

[Flashrider]

Am Sat, 31 Oct 2009 13:24:01 +0900 (JST)
schrieb Teika Kazura <teika@...>:

> On Tue, 27 Oct 2009 22:18:22 +0100, Christopher Roy Bratusek wrote:
> > Other WMs (eg that M thing) listen to resolution changes. I guess E
> > does, too,
>
> Ok, so there's a way out. Hard study is waiting for us ;)
>
> >> It seems to me that the future compatible solution is to have a
> >> function in edge-flip.jl to update.  And users have to call
> >> manually that func after resolution change.
> >>
> > Plus letting the user manually update screen-width/screen-height
> > and all stuff making use of it is a no-go, if you ask me.
>
> First I wrote the following answer, but I noticed it's wrong:
> ------------------------------------------------------------------------
> I don't mean the manual update is the final solution, but
> (edge-flip-update) is anyway necessary (and it will *never* introduce
> any inconsistency), and it can be implemented easily by 1.6. You seem
> to want it now, so I propose it as one of goals for 1.6.
>
> Even if there's (edge-flip-update), users have to call it manually
> until we support xrandr, which we don't have at all now. (And replace
> Xinerama? ... ;/ )
> ------------------------------------------------------------------------
> If resolutions can be changed per screen in RandR, then we need
> complete rewritement?

wouldn't a resolution changed hook that auto-updates screen-width
screen-height & co be enough?

> According to Wikipedia, RandR still relies on xinerama, though the
> latter is deprecated. Ehh, a conundrum.
>
> Regards,
> Teika (Teika kazura)
>

[GSR - FR]

Hi,
teika@... (2009-10-31 at 1324.01 +0900):
[...]
> Even if there's (edge-flip-update), users have to call it manually
> until we support xrandr, which we don't have at all now. (And replace
> Xinerama? ... ;/ )

Sorry to sneak in, but I wonder what are you refering to, as git grep
-i xrandr (yet another grep method ;] ) says there is something about
Xrandr already.

> ------------------------------------------------------------------------
> If resolutions can be changed per screen in RandR, then we need
> complete rewritement?
>
> According to Wikipedia, RandR still relies on xinerama, though the
> latter is deprecated. Ehh, a conundrum.

Wikipedia could be wrong.

GSR
 

[Teika Kazura]

On Sat, 31 Oct 2009 07:45:00 +0100, Christopher Roy Bratusek wrote:
> wouldn't a resolution changed hook that auto-updates screen-width
> screen-height & co be enough?

On Sat, 31 Oct 2009 20:05:36 +0100, GSR - FR wrote:
> git grep -i xrandr (yet another grep method ;] ) says there is
> something about Xrandr already.

Perhaps Chris is right, but I don't know multi-heads situation. (I
haven't read the thread of multi-heads.)

By the way, restart works in practice, doesn't it?

>> According to Wikipedia, RandR still relies on xinerama, though the
>> latter is deprecated. Ehh, a conundrum.
>
> Wikipedia could be wrong.

Yep. Anyway, we can't do anything without study. :) Thanks for
noticing.

Teika (Teika kazura)