scwm-devs — For developer discussions regarding the Scheme Constraints Window Manager

[Scwm-devs] done testing stylist.scm

[Scott L. <sl...@cs...>]

I'm done testing stylist.scm.  This completes the
"display control"/"customization" category of scheme files (except for
the window manager hint stuff which I haven't been able to test yet
[see next message]).

Summary:

Works fine except for one option that is broken in the C code.

Changelog:

	* stylist.scm: Removed styling of #:start-iconfied option because
	this option is currently broken.

:-)

- Scott

[Scwm-devs] Re: done testing style.scm (mostly) (help needed)

[Scott L. <sl...@cs...>]

Ah, cool.  I didn't know about xprop.
Also, I just looked at it looks like I might be able to
use 'X-get-property' plus some extra code to find all the
properties.

Thanks.

- Scott

> The only way I know to see what hints an app has set is to use xprop to
> look at the window's properties. For example the mwm hints go into an
> atom called MOTIF_WM_HINTS. You might be able to tell from the code
> exactly what atoms correspond to each of those hints. I'll take a look
> at some of the apps on my system to see if I come across any of the
> one's you're looking for.
> 
> Jason
> 
> On Thu, 2002-04-04 at 00:53, Scott Lenser wrote:
> > 
> > I've mostly finished testing style.scm.  Ugh, this file is
> > annoying :-(.  I wasn't able to test the following functions
> > because I need to find apps that set the hints and I don't know
> > how to check reasonably easily whether an app uses these hints
> > and I don't know which apps set this hints.  This is where the
> > help comes in.  I need to find apps that set these hints.  If you
> > know of such apps I can just use them.  If you know how to
> > check what hints an app has set I can look through a lot of apps
> > that seem likely to be setting hints until I find ones to use
> > to test these hints.
> > 
> > The untested hint stuff is:
> > 
> > #:hint-override, #:mwm-decor-hint, #:mwm-func-hint,
> > #:PPosition-hint, #:OL-decor-hint, #:lenience
> > 

[Scwm-devs] Re: done testing style.scm (mostly) (help needed)

[Greg B. <ba...@cs...>]

It might be worth checking in with some other wm developers to see if
anyone has got a simple command line tool that fires off X11 windows
with properties/hints set by options to the tool.  It'd be
straightforward to write, too, but it seems like someone should've
already done it (maybe part of an X11 contrib package).

Thanks,
Greg


Jason Lowdermilk <low...@ea...> writes:

> The only way I know to see what hints an app has set is to use xprop to
> look at the window's properties. For example the mwm hints go into an
> atom called MOTIF_WM_HINTS. You might be able to tell from the code
> exactly what atoms correspond to each of those hints. I'll take a look
> at some of the apps on my system to see if I come across any of the
> one's you're looking for.
> 
> Jason
> 
> On Thu, 2002-04-04 at 00:53, Scott Lenser wrote:
> > 
> > I've mostly finished testing style.scm.  Ugh, this file is
> > annoying :-(.  I wasn't able to test the following functions
> > because I need to find apps that set the hints and I don't know
> > how to check reasonably easily whether an app uses these hints
> > and I don't know which apps set this hints.  This is where the
> > help comes in.  I need to find apps that set these hints.  If you
> > know of such apps I can just use them.  If you know how to
> > check what hints an app has set I can look through a lot of apps
> > that seem likely to be setting hints until I find ones to use
> > to test these hints.
> > 
> > The untested hint stuff is:
> > 
> > #:hint-override, #:mwm-decor-hint, #:mwm-func-hint,
> > #:PPosition-hint, #:OL-decor-hint, #:lenience
> > 
> > Anyway, everything else in the file is tested.
> > 
> > Summary:
> > Mostly doc fixes.  Added new concepts 'Style Option' and 'Style Entry'.
> > A few documentation of broken C routines breaking the scheme stuff.
> > A couple of fixed functions.
> > 
> > Changelog:
> > 
> > Changes in scheme/:
> > 
> >         * style.scm:
> >         Added comment about what the structure for a style looks like.
> >         Added docs for 'style-one-window', 'clear-window-style', 'make-style',
> >           'make-conditional-style', 'apply-style'.
> >         Improved doc for 'window-style'.
> >         Fixed 'window-unstyle' so that it works for splicing styles.  Also,
> >           added note to doc that it removes all instances of the style.
> >         Fixed 'clear-window-style' which was accessing an undefined variable.
> >         Added comments explaining private functions 'mcs-complain',
> >           'mcs-parse-args'.
> >         Added concept for 'Style Entry'.
> >         Formatting improvements for style-entry:* functions.
> >         Improved 'simplify-style' by making it actually do some simplification.
> >           Specifically, made it remove empty styles (which get created all the
> >           time by splicing styles).
> >         Added BROKEN comments to #:icon-title, #:start-iconified,
> >           #:decorate-transient.
> >           #:start-iconified crashes scwm because the 'iconify-window' call
> >           is made before the icon window created because of where the hook
> >           runs.  This appears to be in order to make #:start-iconified sort
> >           of work.  Removed #:start-iconified option until this can be
> >           fixed.
> >         Discovered that #:show-icon only works as a hint and only when set to
> >           #f.  Changed from style to hint to reflect when it actually works.
> >         Found out #:icon only works as hint.  Changed to hint from style until
> >           'set-icon!' gets fixed.  Causes window to vanish when applied to an
> >           existing window.
> >         Added FIXME noting that #:button x only shows the button if it is bound
> >           to a mouse event (very unintuitive).
> >         Added FIXME about adding documentation to style options.
> >         Fixed #:other-proc style option which was not setting the option type.
> >         Added FIXMEs for the following style options which have not been tested
> >           yet: #:hint-override, #:mwm-decor-hint, #:mwm-func-hint,
> >           #:PPosition-hint, #:OL-decor-hint, #:lenience.
> > 
> >         * style-options.scm: Added concept for 'Style Option'.
> > 
> > Changes in src/:
> > 
> >         * face.c:
> >         Added FIXME for documenting style options.
> >         Improved doc for 'Window Style' concept and added references to
> >           new concepts added 'Style Option' and 'Style Entry'.
> > 
> > Whew.
> > 
> > Glad that one's mostly over :-)
> > 
> > - Scott
> > 
> > 

[Scwm-devs] Re: done testing style.scm (mostly) (help needed)

[Jason L. <low...@ea...>]

The only way I know to see what hints an app has set is to use xprop to
look at the window's properties. For example the mwm hints go into an
atom called MOTIF_WM_HINTS. You might be able to tell from the code
exactly what atoms correspond to each of those hints. I'll take a look
at some of the apps on my system to see if I come across any of the
one's you're looking for.

Jason

On Thu, 2002-04-04 at 00:53, Scott Lenser wrote:
> 
> I've mostly finished testing style.scm.  Ugh, this file is
> annoying :-(.  I wasn't able to test the following functions
> because I need to find apps that set the hints and I don't know
> how to check reasonably easily whether an app uses these hints
> and I don't know which apps set this hints.  This is where the
> help comes in.  I need to find apps that set these hints.  If you
> know of such apps I can just use them.  If you know how to
> check what hints an app has set I can look through a lot of apps
> that seem likely to be setting hints until I find ones to use
> to test these hints.
> 
> The untested hint stuff is:
> 
> #:hint-override, #:mwm-decor-hint, #:mwm-func-hint,
> #:PPosition-hint, #:OL-decor-hint, #:lenience
> 
> Anyway, everything else in the file is tested.
> 
> Summary:
> Mostly doc fixes.  Added new concepts 'Style Option' and 'Style Entry'.
> A few documentation of broken C routines breaking the scheme stuff.
> A couple of fixed functions.
> 
> Changelog:
> 
> Changes in scheme/:
> 
>         * style.scm:
>         Added comment about what the structure for a style looks like.
>         Added docs for 'style-one-window', 'clear-window-style', 'make-style',
>           'make-conditional-style', 'apply-style'.
>         Improved doc for 'window-style'.
>         Fixed 'window-unstyle' so that it works for splicing styles.  Also,
>           added note to doc that it removes all instances of the style.
>         Fixed 'clear-window-style' which was accessing an undefined variable.
>         Added comments explaining private functions 'mcs-complain',
>           'mcs-parse-args'.
>         Added concept for 'Style Entry'.
>         Formatting improvements for style-entry:* functions.
>         Improved 'simplify-style' by making it actually do some simplification.
>           Specifically, made it remove empty styles (which get created all the
>           time by splicing styles).
>         Added BROKEN comments to #:icon-title, #:start-iconified,
>           #:decorate-transient.
>           #:start-iconified crashes scwm because the 'iconify-window' call
>           is made before the icon window created because of where the hook
>           runs.  This appears to be in order to make #:start-iconified sort
>           of work.  Removed #:start-iconified option until this can be
>           fixed.
>         Discovered that #:show-icon only works as a hint and only when set to
>           #f.  Changed from style to hint to reflect when it actually works.
>         Found out #:icon only works as hint.  Changed to hint from style until
>           'set-icon!' gets fixed.  Causes window to vanish when applied to an
>           existing window.
>         Added FIXME noting that #:button x only shows the button if it is bound
>           to a mouse event (very unintuitive).
>         Added FIXME about adding documentation to style options.
>         Fixed #:other-proc style option which was not setting the option type.
>         Added FIXMEs for the following style options which have not been tested
>           yet: #:hint-override, #:mwm-decor-hint, #:mwm-func-hint,
>           #:PPosition-hint, #:OL-decor-hint, #:lenience.
> 
>         * style-options.scm: Added concept for 'Style Option'.
> 
> Changes in src/:
> 
>         * face.c:
>         Added FIXME for documenting style options.
>         Improved doc for 'Window Style' concept and added references to
>           new concepts added 'Style Option' and 'Style Entry'.
> 
> Whew.
> 
> Glad that one's mostly over :-)
> 
> - Scott
> 
> 

[Scwm-devs] done testing style.scm (mostly) (help needed)

[Scott L. <sl...@cs...>]

I've mostly finished testing style.scm.  Ugh, this file is
annoying :-(.  I wasn't able to test the following functions
because I need to find apps that set the hints and I don't know
how to check reasonably easily whether an app uses these hints
and I don't know which apps set this hints.  This is where the
help comes in.  I need to find apps that set these hints.  If you
know of such apps I can just use them.  If you know how to
check what hints an app has set I can look through a lot of apps
that seem likely to be setting hints until I find ones to use
to test these hints.

The untested hint stuff is:

#:hint-override, #:mwm-decor-hint, #:mwm-func-hint,
#:PPosition-hint, #:OL-decor-hint, #:lenience

Anyway, everything else in the file is tested.

Summary:
Mostly doc fixes.  Added new concepts 'Style Option' and 'Style Entry'.
A few documentation of broken C routines breaking the scheme stuff.
A couple of fixed functions.

Changelog:

Changes in scheme/:

        * style.scm:
        Added comment about what the structure for a style looks like.
        Added docs for 'style-one-window', 'clear-window-style', 'make-style',
          'make-conditional-style', 'apply-style'.
        Improved doc for 'window-style'.
        Fixed 'window-unstyle' so that it works for splicing styles.  Also,
          added note to doc that it removes all instances of the style.
        Fixed 'clear-window-style' which was accessing an undefined variable.
        Added comments explaining private functions 'mcs-complain',
          'mcs-parse-args'.
        Added concept for 'Style Entry'.
        Formatting improvements for style-entry:* functions.
        Improved 'simplify-style' by making it actually do some simplification.
          Specifically, made it remove empty styles (which get created all the
          time by splicing styles).
        Added BROKEN comments to #:icon-title, #:start-iconified,
          #:decorate-transient.
          #:start-iconified crashes scwm because the 'iconify-window' call
          is made before the icon window created because of where the hook
          runs.  This appears to be in order to make #:start-iconified sort
          of work.  Removed #:start-iconified option until this can be
          fixed.
        Discovered that #:show-icon only works as a hint and only when set to
          #f.  Changed from style to hint to reflect when it actually works.
        Found out #:icon only works as hint.  Changed to hint from style until
          'set-icon!' gets fixed.  Causes window to vanish when applied to an
          existing window.
        Added FIXME noting that #:button x only shows the button if it is bound
          to a mouse event (very unintuitive).
        Added FIXME about adding documentation to style options.
        Fixed #:other-proc style option which was not setting the option type.
        Added FIXMEs for the following style options which have not been tested
          yet: #:hint-override, #:mwm-decor-hint, #:mwm-func-hint,
          #:PPosition-hint, #:OL-decor-hint, #:lenience.

        * style-options.scm: Added concept for 'Style Option'.

Changes in src/:

        * face.c:
        Added FIXME for documenting style options.
        Improved doc for 'Window Style' concept and added references to
          new concepts added 'Style Option' and 'Style Entry'.

Whew.

Glad that one's mostly over :-)

- Scott

[Scwm-devs] done testing rectangle.scm

[Scott L. <sl...@cs...>]

Hehe, got this one for free.  Realized I'd already tested everything
in it when checking tile.scm.  Forgot to check in before though.

Only change is switching 'window-corners' and 'enclosing-rectangle'
to use the frame size instead of the window size.

- Scott

[Scwm-devs] done testing style-options.scm

[Scott L. <sl...@cs...>]

I'm done testing style-options.scm.

Summary:

All fine, just added docs. :-)

Changelog:

	* style-options.scm:
	Made window-style-options public for debugging purposes (with comment).
	Modified comment on add-window-style-option to add 'both type to list
	  of type we use.
	Added doc strings on all the public functions.
	Slight formatting improvements to code.

:-)

- Scott

[Scwm-devs] done testing face.scm

[Scott L. <sl...@cs...>]

I'm done testing face.scm.  This file exercises quite a bit of C code
so a lot of C code got tested in the process.  Semantics of some of
the *-style functions is pretty bizarre but doesn't seem to be a critical
problem.  I doc'd the way the functions actually behave.  Improved some
C docs and some minor tweaks and added some FIXME notes in the C code.

Changelog for scheme/:

	* face.scm: 
	'title-style' - Added FIXME because the sense of #:relief for
	active-down gets reversed even if it was explicitly set in
	the 'title-style' call.
	Add warning about #:pixmap sometimes crashing scwm.  Filed bug
	  report.
	Improved doc string to document the way the function actually
	  operates.  The function has odd semantics and should probably
	  be changed at some point.

	'border-style' - Added FIXME about lack of option.
	Added suggestion of using mwm style borders with #:pixmap option
	  since otherwise they tend to be mostly occluded by the relief.

	'button-style' - Added to doc string about reversal of #:relief
	flag in active-down.

	Improved formatting of code in much of the file.
	Rearranged file so that flow of control goes from bottom of file
	  to top instead of jumping around.

Changelog for src/:

	* face.c: Drastically improved the doc string for gradients.
	Better doc string for 'set-title-face!'.
	Improved formatting of code in several places.

	* color.c: Improved formatting of code.

	* image.c: Added FIXME about way to crash scwm.

Your local substitute for Raid(TM),

  Scott

Re: [Scwm-devs] Re: question about VALIDATE macros

[Scott L. <sl...@cs...>]

> 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

Re: [Scwm-devs] Re: question about VALIDATE macros

[Greg B. <ba...@cs...>]

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


> 
> - Scott
> 
> > So that they work as you'd expect when preceded by an if clause-- they
> > need to be a single statement (which many of them happen to already be,
> > but if the macro definition got any more complicated, they wouldn't
> > be).  E.g., consider:
> > 
> > #define DO_STUFF(x) \
> >    do something;
> >    do something else;
> > 
> > being used as:
> > 
> > if (...) 
> >   DO_STUFF(x)
> > 
> > it'll expand into:
> > 
> > if (...)
> > {
> >   do something;
> > }
> > do something else;
> > 
> > I've added braces to stress the problem.  The do/while(0) makes it work
> > as the user of the macro probably expected, w/o requiring her to
> > remember to use braces everytime she uses DO_STUFF.
> > 
> > I think the GNU C programming standards mention this coding style, but I
> > don't have a reference handy.
> > 
> > Thanks,
> > Greg
> > 
> > 
> > Scott Lenser <sl...@cs...> writes:
> > 
> > > Greg,
> > > 
> > > In the validate macros such as:
> > > 
> > > #define VALIDATE_WIN_USE_CONTEXT(win) \
> > >   do { if ((win = ensure_valid(win,1,FUNC_NAME, SCM_BOOL_T, SCM_BOOL_F)) == 
> > > SCM_BOOL_F) \
> > >           return SCM_BOOL_F; } while (0)
> > > 
> > > Why do they all have a do { } while(0) around the code?
> > > 
> > > Thanks.
> > > 
> > > - Scott
> > 
> > _______________________________________________
> > Scwm-devs mailing list
> > Scw...@li...
> > https://lists.sourceforge.net/lists/listinfo/scwm-devs

Re: [Scwm-devs] Re: question about VALIDATE macros

[Scott L. <sl...@cs...>]

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?

- Scott

> So that they work as you'd expect when preceded by an if clause-- they
> need to be a single statement (which many of them happen to already be,
> but if the macro definition got any more complicated, they wouldn't
> be).  E.g., consider:
> 
> #define DO_STUFF(x) \
>    do something;
>    do something else;
> 
> being used as:
> 
> if (...) 
>   DO_STUFF(x)
> 
> it'll expand into:
> 
> if (...)
> {
>   do something;
> }
> do something else;
> 
> I've added braces to stress the problem.  The do/while(0) makes it work
> as the user of the macro probably expected, w/o requiring her to
> remember to use braces everytime she uses DO_STUFF.
> 
> I think the GNU C programming standards mention this coding style, but I
> don't have a reference handy.
> 
> Thanks,
> Greg
> 
> 
> Scott Lenser <sl...@cs...> writes:
> 
> > Greg,
> > 
> > In the validate macros such as:
> > 
> > #define VALIDATE_WIN_USE_CONTEXT(win) \
> >   do { if ((win = ensure_valid(win,1,FUNC_NAME, SCM_BOOL_T, SCM_BOOL_F)) == 
> > SCM_BOOL_F) \
> >           return SCM_BOOL_F; } while (0)
> > 
> > Why do they all have a do { } while(0) around the code?
> > 
> > Thanks.
> > 
> > - Scott
> 
> _______________________________________________
> Scwm-devs mailing list
> Scw...@li...
> https://lists.sourceforge.net/lists/listinfo/scwm-devs

[Scwm-devs] Re: question about VALIDATE macros

[Greg B. <ba...@cs...>]

So that they work as you'd expect when preceded by an if clause-- they
need to be a single statement (which many of them happen to already be,
but if the macro definition got any more complicated, they wouldn't
be).  E.g., consider:

#define DO_STUFF(x) \
   do something;
   do something else;

being used as:

if (...) 
  DO_STUFF(x)

it'll expand into:

if (...)
{
  do something;
}
do something else;

I've added braces to stress the problem.  The do/while(0) makes it work
as the user of the macro probably expected, w/o requiring her to
remember to use braces everytime she uses DO_STUFF.

I think the GNU C programming standards mention this coding style, but I
don't have a reference handy.

Thanks,
Greg


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

> Greg,
> 
> In the validate macros such as:
> 
> #define VALIDATE_WIN_USE_CONTEXT(win) \
>   do { if ((win = ensure_valid(win,1,FUNC_NAME, SCM_BOOL_T, SCM_BOOL_F)) == 
> SCM_BOOL_F) \
>           return SCM_BOOL_F; } while (0)
> 
> Why do they all have a do { } while(0) around the code?
> 
> Thanks.
> 
> - Scott

[Scwm-devs] question about VALIDATE macros

[Scott L. <sl...@cs...>]

Greg,

In the validate macros such as:

#define VALIDATE_WIN_USE_CONTEXT(win) \
  do { if ((win = ensure_valid(win,1,FUNC_NAME, SCM_BOOL_T, SCM_BOOL_F)) == 
SCM_BOOL_F) \
          return SCM_BOOL_F; } while (0)

Why do they all have a do { } while(0) around the code?

Thanks.

- Scott

[Scwm-devs] Re: fvwm pager info

[Greg B. <ba...@cs...>]

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

> One more tidbit on the fvwm pager.
> 
> It has a very interesting architecture for handling all of the drawing and
> what not.  It simply makes a window inside itself for each window out on the
> desktop.  This lets X handle much of the redrawing logic.  It then mirrors
> update on the desktop with its own little windows.

Ten years ago that would've been considered overkill and way too
heavyweight, but it is a clever design to make it pretty darned simple!

Thanks,
Greg

P.S. Great (!) work!!

[Scwm-devs] fvwm pager info

[Scott L. <sl...@cs...>]

One more tidbit on the fvwm pager.

It has a very interesting architecture for handling all of the drawing and
what not.  It simply makes a window inside itself for each window out on the
desktop.  This lets X handle much of the redrawing logic.  It then mirrors
update on the desktop with its own little windows.

- Scott

Re: [Scwm-devs] Re: fvwm pager support broken for newest fvwm

[Scott L. <sl...@cs...>]

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
> 

[Scwm-devs] done testing decor.scm

[Scott L. <sl...@cs...>]

done testing decor.scm

added doc

changelog:

	* decor.scm: Added doc string to 'with-decor'.

- Scott

[Scwm-devs] done testing cursor.scm

[Scott L. <sl...@cs...>]

done testing cursor.scm

everything works fine. :-)

added a few comments

added FIXME about different cursors for each nonant (no sharing requirement)

changelog:

	* cursor.scm: Added some comments.
	Added FIXME about allowing different cursors for each nonant.

- Scott

[Scwm-devs] done testing basic-styles.scm

[Scott L. <sl...@cs...>]

I'm done testing basic-styles.scm.

It all works, nothing to do. :-)

'Course it is kind of trivial and practically correct by definition.

- Scott

Re: [Scwm-devs] Re: fvwm pager support broken for newest fvwm

[Scott L. <sl...@cs...>]

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

[Scwm-devs] updated hierarchy

[Scott L. <sl...@cs...>]

Meant to include this with last message.

Here's what the updated scheme hierarchy looks like:

Display control: control over visual appearance
  Customization: changing visual appearance
    basic-styles
    cursor
    decor
    face
    style-options
    style
    stylist
  Optional features: optional visual features
    animated-edge-moves
    animated-iconify
    animation
    constraint-animation
    desk-background
    menus-extras
    focus-titlebar
Events:
  Handling:
    modifier-key-bindings
    quote
  Generating:
    Keys:
      send-string
    Mouse:
      key-mover-xtest
      key-mover
      synth-events
Window control:
  group (FULLY TESTED)
  undo (FULLY TESTED)
  window-configuration (FULLY TESTED)
  winops-menu (FULLY TESTED)
  Constraints:
    constraints
    constraint-investigator
    nonants
    simple-constraints
    ui-constraints-classes
    ui-constraints-composition
    ui-constraints-gdk-drawing
    ui-constraints-toggle-menu
    ui-constraints
  Focus: (FULLY TESTED)
    dir-focus (FULLY TESTED)
    focus-stack (FULLY TESTED)
    hover-focus (FULLY TESTED)
    last-mapped-window (FULLY TESTED)
    task-switcher (FULLY TESTED)
  Stacking: (FULLY TESTED)
    auto-raise (FULLY TESTED)
    easyraise (FULLY TESTED)
    stacking (FULLY TESTED)
  Position/size: (FULLY TESTED)
    auto-shrink (FULLY TESTED)
    auto-unobscure (FULLY TESTED)
    cascade (FULLY TESTED)
    placement (FULLY TESTED)
    shove-window (FULLY TESTED)
    snap (FULLY TESTED)
    tile (FULLY TESTED)
  Hints:
    gnome-hints
    kde-hints
  Virtual desks/viewports: (FULLY TESTED)
    edge-ops (FULLY TESTED)
    shutdown-opts (FULLY TESTED)
    virtual (FULLY TESTED)
Themes:
  theme-impl
  themes
Utility functions:
  Code: utility functions to be used by other scheme code
    bincomm
    corba
    file
    fvwm-compat
    fvwm-eval
    fvwm-module
    gtk
    hooks
    image-loaders
    listops
    number-convert
    optargs
    path-cache
    primopts
    rectangle
    reexport
    register
    rgb-database
    sort
    stringops
    time-convert
    window-locations
    xprop-extras
  Development support: utility functions to aid development/debugging
    property-respond
    reflection
    test-case
    visibility-reporter
    wininfo
    winlist
  Input: utility functions that get input from the user
    gtk-menu
    gtk-table-display
    prompt-binding
    prompt-bool
    prompt-color
    prompt-enum
    prompt-file
    prompt-font
    prompt-proc
    prompt-range
    prompt-string
    prompting-shell
    window-selection
    winlist-menu
    ViaVoice:
      viavoice-smrc
      viavoice
  Output: utility functions that display output to the user
    flash-window
    gtk-about
    gtk-message
    higlight-current-window
    lambda-startup-logo
    wavplay
    where-is
Extras: (Optional functionality that is not really related to manipulating 
windows)
  ScwmBiff
  ScwmClock
  netscape
  debianapps-menu
  simplebiff
  xlock-menus
Windowing applets: (Optional windowing functionality that uses windows for 
interface)
  ScwmButtons
  ScwmDeskButtons
  scwm-gtk-pager
  ui-constraints-buttons
Help:
  describe
  doc
  image-path-suggestor
  report-usage
  Configuration:
    preferences
    prefs-menu
Misc: stuff that didn't easily fall into above categories (needs further 
investigation)
  base
  minimal
  advice
  flux-gtk
  flux
  message-window
  module-types
  primopts
  report-usage
  session
  std-menus
  titlebar-buttons
  wmconfig-menu

- Scott

[Scwm-devs] moving on to "display control"

[Scott L. <sl...@cs...>]

With the completion of testing group.scm, I've now tested all of the "window 
control"
group with the exception of "constraints" (cassowary stuff) and "hints" 
(desktop
interaction stuff).  I'm going to postpone testing those two categories, the
cassowary stuff because I don't use cassowary much and I suspect many people 
don't;
the desktop stuff because I don't run a desktop and don't feel like setting 
one up
for testing any time soon (hopefully someone else will get a chance to test it 
and
I won't have to [hint, hint]).

So far 3267 lines of scheme code have been tested representing 13.4% of the 
24447
lines of scheme code in the system.

I'm going to start working on the "display control" hierarchy.

- Scott

[Scwm-devs] occasional crashes

[Scott L. <sl...@cs...>]

I'm getting occasional crashes from set-window-highlighted-nonant! because it
is occasionally getting called with invalid windows.  Get back traces like 
this:

ERROR: In procedure set-window-highlighted-nonant!:
ERROR: Window no longer valid.

Backtrace:
0* [mark-nonant-motion-handler 1085 414 ...]
1* (if (and lastwin (not #)) (set-window-highlighted-nonant! #f lastwin))
2  [set-window-highlighted-nonant! #f #<window (invalid)>]

/usr/local/share/scwm/modules/app/scwm/nonants.scm:128:7: In procedure 
set-window-highlighted-nonant! in expression (set-window-highlighted-nonant! 
#f lastwin):
/usr/local/share/scwm/modules/app/scwm/nonants.scm:128:7: Window no longer 
valid.

In the log file before scwm bites the dust.
Looks like I'll have to add some protection against this somewhere.

- Scott

[Scwm-devs] done testing group.scm

[Scott L. <sl...@cs...>]

I'm done testing group.scm.

Summary:

Few bugs.
Few doc changes.
Few sorely needed enhancements.
Most of the iconify functions are broken because set-show-icon!
  is broken.

Changelog:

	* group.scm:
	Removed redundant :use-module declaration.
	Fixed 'group-leader-id' so it returns the right thing on windows
	  without any WM_HINTS set.
	Enhanced 'seperate-group-windows' so that it can take a 
	  group-leader-id or a group (either list of windows or example
	  window) and do the right thing.  This fixes some of the routines
	  that call this so that they can use any type of group.
	Changed 'raise-group' to use the new 'seperate-group-windows' in such
	  a way that a list of windows is now accepted as the group parameter.
	Made same change to 'lower-group' that was made to 'raise-group'.
	Changed doc for 'move-group' to match what the function does (change
	  from virtual coordinates to viewport coordinates).
	Modified 'interactive-move-group' so that it uses virtual coordinates
	  rather than viewport coordinates to make the other windows tag along.
	  This fixes the movement behavior for when an 'interactive-move-group'
	  causes the viewport to scroll.
	Marked 'deiconify-group', 'deiconify-group-or-window', and 'iconify-group'
	  broken since they all use the busted 'set-show-icon!' function and
	  hence can't be tested (but don't work now in any case).
	Improved doc string for 'make-window-group-menu' noting that W can be
	  passed as #f.
	Changed 'make-window-group-menu' so that it allows group operations on
	  a single window selection since they work just fine.
	Enhanced 'make-window-group-menu' by adding an option to (un)select all
	  the windows in the same group as this window (as indicated by their
	  group-leader-id).
	Enhanced 'make-window-group-menu' by adding move to the list of operations.
	Moved the close-window option of 'make-window-group-menu' down near the end
	  by the destroy option.
	Changed iconify option of 'make-window-group-menu' to use 
	  'iconify-group-individually' since 'iconify-group' is currently
	  broken.  This should be changed back once 'iconify-group' is fixed.
	  I left a FIXME behind as a reminder.

*whew*

- Scott

[Scwm-devs] Re: fvwm pager support broken for newest fvwm

[Greg B. <ba...@cs...>]

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