Thread: [Scwm-devs] done testing key-mover-xtest.scm

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Works fine.  :-)

Complete duplicate of functionality in key-mover.scm. :-(

- Scott

But it uses the xtest extension, right?  This is a more reliable way to
move the cursor around if (and only if) your X server supports the XTest
extension.

Thanks,
Greg

Scott Lenser <sl...@cs...> writes:

> Works fine.  :-)
> 
> Complete duplicate of functionality in key-mover.scm. :-(
> 
> - Scott

Ah, I see.  I didn't realize one was more robust than the other.  I didn't
actually look to see how they were implemented much.  Couldn't this
be folded into the move-pointer primitive so that you always get the
best one that your version of X supports?  In any case, the function
to move the virtual viewports is identical between the two versions.

- Scott

> But it uses the xtest extension, right?  This is a more reliable way to
> move the cursor around if (and only if) your X server supports the XTest
> extension.
> 
> Thanks,
> Greg
> 
> Scott Lenser <sl...@cs...> writes:
> 
> > Works fine.  :-)
> > 
> > Complete duplicate of functionality in key-mover.scm. :-(
> > 
> > - Scott

Scott Lenser <sl...@cs...> writes:

> Ah, I see.  I didn't realize one was more robust than the other.  I didn't
> actually look to see how they were implemented much.  Couldn't this
> be folded into the move-pointer primitive so that you always get the
> best one that your version of X supports?  In any case, the function
> to move the virtual viewports is identical between the two versions.

It's possible, but sometimes you specifically want one or the other, so
the "smart" one would have to be another layer of abstraction.  The
stuff that's truly duplicated definitely should be factored out into
something separate.

Thanks,
Greg

> Scott Lenser <sl...@cs...> writes:
> 
> > Ah, I see.  I didn't realize one was more robust than the other.  I didn't
> > actually look to see how they were implemented much.  Couldn't this
> > be folded into the move-pointer primitive so that you always get the
> > best one that your version of X supports?  In any case, the function
> > to move the virtual viewports is identical between the two versions.
> 
> It's possible, but sometimes you specifically want one or the other, so
> the "smart" one would have to be another layer of abstraction.  The
> stuff that's truly duplicated definitely should be factored out into
> something separate.
> 
> Thanks,
> Greg
> 

When would you want the non-xtest one if it the xtest one is available?

- Scott

To test it, for one. :-)

Greg

Scott Lenser <sl...@cs...> writes:

> > Scott Lenser <sl...@cs...> writes:
> > 
> > > Ah, I see.  I didn't realize one was more robust than the other.  I didn't
> > > actually look to see how they were implemented much.  Couldn't this
> > > be folded into the move-pointer primitive so that you always get the
> > > best one that your version of X supports?  In any case, the function
> > > to move the virtual viewports is identical between the two versions.
> > 
> > It's possible, but sometimes you specifically want one or the other, so
> > the "smart" one would have to be another layer of abstraction.  The
> > stuff that's truly duplicated definitely should be factored out into
> > something separate.
> > 
> > Thanks,
> > Greg
> > 
> 
> When would you want the non-xtest one if it the xtest one is available?
> 
> - Scott

I don't know, I didn't bother to test it.  I just reverted to the old
pager for now and recorded it as another thing to fix before the next
release.  I know the drawing of the viewport updates and I doubt they
would ship with a broken pager so my guess is that the interface for
window updates probably changed slightly.  Probably just an extra field
or something, but won't know without spending some time investigating.
Making good progress on the scheme code so don't really want to divert
at this point.

As long as the pager works, I'm happy.  I don't think we really need any
of the other modules.  Our winlist stuff is as good as the FvwmWinList so
I don't really see the need for it.  Our native pager is missing a bunch
of features (like interaction with windows/viewports using the pager).

- Scott

> Yea, I've known this for a while.  I've just continued using the old
> pager.  Do you know if the module interface itself has changed or just
> the pager?  E.g., do new FvwmWinList modules still work (that was
> the only other fvwm module that I used with Scwm).
> 
> Thanks,
> Greg
> 
> 
> Scott Lenser <sl...@cs...> writes:
> 
> > Bad news.
> > 
> > The newest version of the fvwm pager (2.4.x) breaks our compatibility
> > layer.  It prevents it from displaying windows.  The old version
> > from 2.2.x works fine.
> > 
> > Probably is just a minor change but need to determine what the change
> > is a find out if there is a way to autodetect which version of the
> > pager is being used.
> > 
> > - Scott
> 
> _______________________________________________
> Scwm-devs mailing list
> Scw...@li...
> https://lists.sourceforge.net/lists/listinfo/scwm-devs

Couldn't sleep, so gathered some more info.

Looks like fvwm is moving to a per message type structure for each module
message.  Currently the only message that is different is the one for the
pager so I expect all other fvwm modules will still work.  As for the pager,
they replaced the flags field with a layer field.  They also changed the
border_width field to a short but I don't think it matters since it will
get padded out to a long anyway.  Might make a difference on machine with
a different endianess though.  Most likely changing it so it sends 0 instead
of flags will make it work with the new pager.

- Scott

> Yea, I've known this for a while.  I've just continued using the old
> pager.  Do you know if the module interface itself has changed or just
> the pager?  E.g., do new FvwmWinList modules still work (that was
> the only other fvwm module that I used with Scwm).
> 
> Thanks,
> Greg
> 
> 
> Scott Lenser <sl...@cs...> writes:
> 
> > Bad news.
> > 
> > The newest version of the fvwm pager (2.4.x) breaks our compatibility
> > layer.  It prevents it from displaying windows.  The old version
> > from 2.2.x works fine.
> > 
> > Probably is just a minor change but need to determine what the change
> > is a find out if there is a way to autodetect which version of the
> > pager is being used.
> > 
> > - Scott
> 

> Scott Lenser <sl...@cs...> writes:
> 
> > Ah, I see.  And the do .. while(0) part is so that stuff like
> > 
> > if(a)
> >   DO_STUFF(1);
> > else
> >   DO_STUFF(2);
> > 
> > works as expected.  Is there a reason they aren't inline functions?
> 
> FUNC_NAME wouldn't properly expand to be the function name of the
> location where the inline function was invoked, but would rather just
> always name the inline function (not very useful for finding your errors!)
> 
> Thanks,
> Greg
> 

Heehee, I knew there must be a reason.  That's certainly a good one. :-)

Thanks.

- Scott

There are other ways to test this without exposing a dual interface though.
For instance, you could expose a function that sets debugging flags that
disallow the use of certain features of the X server.  Seems bad to make
the client decide which one they want when we can easily determine it
for them (perhaps on the scheme side, perhaps on the C side).

- Scott

> To test it, for one. :-)
> 
> Greg
> 
> Scott Lenser <sl...@cs...> writes:
> 
> > > Scott Lenser <sl...@cs...> writes:
> > > 
> > > > Ah, I see.  I didn't realize one was more robust than the other.  I didn't
> > > > actually look to see how they were implemented much.  Couldn't this
> > > > be folded into the move-pointer primitive so that you always get the
> > > > best one that your version of X supports?  In any case, the function
> > > > to move the virtual viewports is identical between the two versions.
> > > 
> > > It's possible, but sometimes you specifically want one or the other, so
> > > the "smart" one would have to be another layer of abstraction.  The
> > > stuff that's truly duplicated definitely should be factored out into
> > > something separate.
> > > 
> > > Thanks,
> > > Greg
> > > 
> > 
> > When would you want the non-xtest one if it the xtest one is available?
> > 
> > - Scott

I agree with you that an interface to the "preferred" functionality is
in order, and that we need an interface to the primitive functionality,
as well.  I dislike global state side-effects, though, so I still prefer
an extra level of indirection that folks can use.  There may be other
reasons why folks want to send synthetic events (I can't think of
anything esp. compelling right now, but it's been a while for me).

Thanks,
Greg

Scott Lenser <sl...@cs...> writes:

> There are other ways to test this without exposing a dual interface though.
> For instance, you could expose a function that sets debugging flags that
> disallow the use of certain features of the X server.  Seems bad to make
> the client decide which one they want when we can easily determine it
> for them (perhaps on the scheme side, perhaps on the C side).
> 
> - Scott
> 
> > To test it, for one. :-)
> > 
> > Greg
> > 
> > Scott Lenser <sl...@cs...> writes:
> > 
> > > > Scott Lenser <sl...@cs...> writes:
> > > > 
> > > > > Ah, I see.  I didn't realize one was more robust than the other.  I didn't
> > > > > actually look to see how they were implemented much.  Couldn't this
> > > > > be folded into the move-pointer primitive so that you always get the
> > > > > best one that your version of X supports?  In any case, the function
> > > > > to move the virtual viewports is identical between the two versions.
> > > > 
> > > > It's possible, but sometimes you specifically want one or the other, so
> > > > the "smart" one would have to be another layer of abstraction.  The
> > > > stuff that's truly duplicated definitely should be factored out into
> > > > something separate.
> > > > 
> > > > Thanks,
> > > > Greg
> > > > 
> > > 
> > > When would you want the non-xtest one if it the xtest one is available?
> > > 
> > > - Scott