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

[Scwm-devs] next on testing list

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

I'm going to start on the "Utility"/"Development support" section
next.  I'll do winops.scm at some point too.

- Scott

[Scwm-devs] done testing quote.scm

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

I'm done testing quote.scm.  This completes the "Events" hierarchy.
I found a file that was missing from my taxonomy (winops.scm).  I
put it in the "Window control" group.

Summary:

This file has problems.  I fixed some of them, but changes need to
be done to event binding to fix the rest.  There is no reliable
way to test from scheme the method used to grab an event and the
undo-passive-grab/redo-passive-grab calls only works for events
that were not specified with context 'all.   The problem is these
get grabbed on the root window, but undo-passive-grab/redo-passive-grab
assume the event was grabbed on the client window.  The net
result is that quoting doesn't work for events bound using the 'all
context (and has the atrocious property of installing a bogus
passive X grab).  The addition of bogus passive X grabs was also
happening when quoting events that the window manager was ignoring
anyway.  The basic problem is that undo-passive-grab/redo-passive-grab
do no error checking because we don't bother to store the passive
grabs we have done anywhere and they are hard to look up from the
binding list.  Added BROKEN docs to these functions explaining the
situations that have problems.

Rest of the file is fine.

In process of testing this, got bitten by bug in binding.c which
prevents mouse bindings bound with 'all from ever removing the
passive X grab.  The code was grabbing again instead of ungrabbing.
I fixed it in this commit.

There are problems in the binding code at the moment.  The
undo-passive-grab/redo-passive-grab duo seem to be out of sync
with the way the grabs for 'all are being done.  I added BROKEN
docs to them.

Changelog:

In scheme:
        * quote.scm:
        'quote-key-event', 'quote-mouse-event' added test to
        see if we even have a passive grab on this event before ungrabbing
        and regrabbing which caused it to be grabbed in the end when it
        wasn't before.  Added BROKEN doc about quote events which have been
        grabbed via the context 'all.  The problem is that the C code for
        'undo-passive-grab' assumes the grab was done on the client window
        but grabs for context 'all are done on the root window.  This doesn't
        work so well and then the 'redo-passive-grab' ends up installing a
        passive grab on the client windows as well, very annoying.  Not enough
        info available to fix at the scheme level.  Need to fix the API to the
        C stuff to fix this.

        A few formatting improvements.

        Added docs for 'xtest-fake-modmask', 'xtest-fake-modmask-key', and
        'xtest-fake-modmask-button'.

In src:
        * binding.c: Added FIXMEs for bugs noticed in passing.
        Doc fix for 'unbind-key'.
        Added BROKEN docs for 'undo-passive-grab' and 'redo-passive-grab'.
        Fixed 'ungrab_button_all_windows' so that it ungrabs the button for
          the 'all context rather than regrabbing it!
        Code formatting improvements.

:-(

- Scott

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

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

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

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

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

> 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

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

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

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

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

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

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

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

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

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

[Scwm-devs] Re: FYI

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

Good luck on your move!  We'll anxiously await your return!

Thanks,
Greg

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

> There'll probably be a big gap in development starting sometime before the
> end of the month since I am moving and thus will be losing my DSL connection
> over which I'm checking everything in for an indeterminate amount of time.
> Should get back up eventually though in one form or another.
> 
> - Scott

[Scwm-devs] FYI

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

There'll probably be a big gap in development starting sometime before the
end of the month since I am moving and thus will be losing my DSL connection
over which I'm checking everything in for an indeterminate amount of time.
Should get back up eventually though in one form or another.

- Scott

[Scwm-devs] done testing send-string.scm

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

Works fine. :-)

- Scott

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

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

Works fine.  :-)

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

- Scott

[Scwm-devs] done testing key-mover.scm

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

Works fine.  :-)

- Scott

[Scwm-devs] done testing synth-events.scm

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

Works fine.  Added comment to docs noting that these synth events can
be ignored.

Changelog:

	* synth-events.scm: Added commentary to doc noting that the synthetic
	events sent are ignored by some applications.

- Scott

[Scwm-devs] done testing modifier-key-bindings.scm

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

I'm done testing modifier-key-bindings.scm

Summary:

binding on all pressed works fine
binding on the release is broken due to something in C code

changelog:

	* modifier-key-bindings.scm:
	Improved docs.
	Noted that the proc-release option for the key bindings is broken
	  due to some problem in the C stuff.
	Modified 'unbind-two-modifier-key-events' to have the same arguments
	  as all the other unbind functions in this file.

:-(

- Scott

[Scwm-devs] done testing #:PPosition-hint

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

I managed to test #:PPosition-hint from style.scm.
It works (although it almost never comes into play).

Only

#:mwm-func-hint
#:OL-decor-hint

are left which I don't know of any apps that use.

- Scott

[Scwm-devs] partial testing of window hint stuff

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

I was able to test some of the window hint stuff.

I've tested #:hint-override, #:mwm-decor-hint, and #:lenience.

All work except #:hint-override doesn't override hints on the
visibility of the border.

Found a missing :use-module in the process so added it.

Checks in some pending changes to window.c while I was add it
since wanted to add the right BROKEN comments to the docs for
this stuff.

changelog:

In scheme/:
        * style.scm:
        Added missing :use-module for listops.
        Tested #:hint-override, #:mwm-decor-hint, #:lenience and thus remove
          FIXMEs asking for testing.
        Added FIXME about #:hint-override being broken for overriding border
          hint.

In src/:
        * window.c: Added FIXME for border override in 'set-hint-override!'.
        Added BROKEN to doc string about this problem.
        Improved doc for 'move-window'.
        Added BROKEN doc to 'set-icon-title!'.
        Added BROKEN doc to 'set-show-icon!'.
        Added comment header to ensure_valid function.
        Added comment in ensure_valid function.

Need to find an app that sets mwm function hints to test that (or just
write one).  Also need to find something that use OL hints.

- Scott

Re: [Scwm-devs] Re: testing of window manager hint options

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

> The contents of the MOTIF_WM_HINTS atom is a C struct, which is defined
> in /usr/X11R6/include/Xm/MwmUtil.h as the struct "MotifWmHints". It's
> basically 5 ints that represent various bit-masked flags.
> 
> Later,
> 
> Jason
> 

Ah, great!  Now I can test the motif stuff at least.  This documentation
makes sense to me.

- Scott

[Scwm-devs] Re: testing of window manager hint options

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

The contents of the MOTIF_WM_HINTS atom is a C struct, which is defined
in /usr/X11R6/include/Xm/MwmUtil.h as the struct "MotifWmHints". It's
basically 5 ints that represent various bit-masked flags.

By the way... I'm right in the middle of changing jobs, so my schedule
is again in turmoil. I had been doing all my scwm stuff on my work
laptop, which I have to return at the end of this week. I just bought a
new laptop of my own to replace it and loaded Skipjack (Redhat 7.3 beta)
from ISO's, so now I'm going to spend some time getting everything I
need installed and configured (including scwm). And then in 2 weeks I'll
be repeating this on my new work computer at my new job. *sigh*

Later,

Jason

On Mon, 2002-04-08 at 21:04, Scott Lenser wrote:
> 
> I still haven't been able to test the window manager hint stuff
> since I have found a way to display the options that I can
> understand.  I can get stuff from xprop like this:
> 
> 850> xprop
> WM_STATE(WM_STATE):
>                 window state: Normal
>                 icon window: 0x80015b
> _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0xbffffc84, 0x0, 0x8186fb0, 0x810f83c
> XdndAware(ATOM) = ARC
> _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x18, 0x40, 0x10, 0x0, 0x0, 0x0
> WM_CLASS(STRING) = "XMMS_Playlist", "xmms"
> WM_LOCALE_NAME(STRING) = "en_US"
> WM_CLIENT_MACHINE(STRING) = "strider"
> WM_ICON_NAME(STRING) = "XMMS Playlist"
> WM_NAME(STRING) = "XMMS Playlist"
> WM_CLIENT_LEADER(WINDOW): window id # 0x2a00001
> WM_HINTS(WM_HINTS):
>                 Client accepts input or input focus: True
>                 Initial state is Normal State.
>                 window id # of group leader: 0x2a00001
> WM_NORMAL_HINTS(WM_SIZE_HINTS):
>                 program specified minimum size: 275 by 319
>                 program specified maximum size: 275 by 319
> WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS
> WM_TRANSIENT_FOR(WINDOW): window id # 0x2a0001a
> 
> 
> I thought I would look at the Motif hints first since they seem to
> be the most common, but I haven't been able to find anything that
> documents what
> 
> _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0xbffffc84, 0x0, 0x8186fb0, 0x810f83c
> 
> means.  I've looked on Google a while but didn't find anything particularly
> useful.  Any hints?
> 
> - Scott
> 
> 

[Scwm-devs] done testing focus-titlebar.scm

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

just a typo fix in this one.

This completes the "display control" group except for the following
exceptions:

- the window manager hint stuff hasn't been tested yet
- I'm postponing testing constraint-animation.scm for when I test
  all the other constraint stuff (which I also postponed testing)

This completed about 20% of the testing of the scheme files.

I'm moving on to the "events" hierarchy next.

Here's the current state of the testing:

Categories:

Display control: control over visual appearance 1635
  Customization: changing visual appearance 1115
    basic-styles (FULLY TESTED)
    cursor (FULLY TESTED)
    decor (FULLY TESTED)
    face (FULLY TESTED)
    style-options (FULLY TESTED)
    style (FULLY TESTED) (well, almost. no really)
    stylist (FULLY TESTED)
  Optional features: optional visual features 520
    animated-edge-moves (FULLY TESTED)
    animated-iconify (FULLY TESTED)
    animation (FULLY TESTED)
    constraint-animation (wait to test with constraint stuff)
    desk-background (FULLY TESTED)
    menus-extras (FULLY TESTED)
    focus-titlebar (FULLY TESTED)
Events: 461
  Handling:
    modifier-key-bindings
    quote
  Generating:
    Keys:
      send-string
    Mouse:
      key-mover-xtest
      key-mover
      synth-events
Window control: 7165
  group (FULLY TESTED)
  undo (FULLY TESTED)
  window-configuration (FULLY TESTED)
  winops-menu (FULLY TESTED)
  Constraints: 3015
    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) 361
    dir-focus (FULLY TESTED)
    focus-stack (FULLY TESTED)
    hover-focus (FULLY TESTED)
    last-mapped-window (FULLY TESTED)
    task-switcher (FULLY TESTED)
  Stacking: (FULLY TESTED) 373
    auto-raise (FULLY TESTED)
    easyraise (FULLY TESTED)
    stacking (FULLY TESTED)
  Position/size: (FULLY TESTED) 1114
    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: 883
    gnome-hints
    kde-hints
  Virtual desks/viewports: (FULLY TESTED) 450
    edge-ops (FULLY TESTED)
    shutdown-opts (FULLY TESTED)
    virtual (FULLY TESTED)
Themes: 307
  theme-impl
  themes
Utility functions: 7966
  Code: utility functions to be used by other scheme code 3950
    bincomm
    corba
    file
    fvwm-compat
    fvwm-eval
    fvwm-module
    gtk
    hooks
    image-loaders
    listops
    number-convert
    optargs
    path-cache
    primopts
    rectangle (FULLY TESTED)
    reexport
    register
    rgb-database
    sort
    stringops
    time-convert
    window-locations
    xprop-extras
  Development support: utility functions to aid development/debugging 1084
    property-respond
    reflection
    test-case
    visibility-reporter
    wininfo
    winlist
  Input: utility functions that get input from the user 2508
    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 424
    flash-window
    gtk-about
    gtk-message
    highlight-current-window
    lambda-startup-logo
    wavplay
    where-is
Extras: (Optional functionality that is not really related to manipulating windows) 731
  ScwmBiff
  ScwmClock
  netscape
  debianapps-menu
  simplebiff
  xlock-menus
Windowing applets: (Optional windowing functionality that uses windows for interface) 682
  ScwmButtons
  ScwmDeskButtons
  scwm-gtk-pager
  ui-constraints-buttons
Help: 1028
  describe
  doc
  image-path-suggestor
  report-usage
  Configuration:
    preferences
    prefs-menu
Misc: stuff that didn't easily fall into above categories (needs further investigation) 2697
  base
  minimal
  advice
  flux-gtk
  flux
  message-window
  module-types
  primopts
  report-usage
  session
  std-menus
  titlebar-buttons
  wmconfig-menu

[Scwm-devs] done testing menus-extras.scm

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

I'm done testing menus-extras.scm.

Summary:

This file stinks.
Made interface to stuff in module slightly sane.  Needs major
  cleanup.
Made doc strings usable.
Fixed a few bugs.

Changelog:

	* menus-extras.scm: 
	Removed unneeded :use-module.
	Changed 'sorted-by-car-string' to sort in alphabetical order.
	Added comment for 'split-list' and changed name to 'split-list!' to
	  reflect its destructive nature.
	Fixed bug in 'split-list!' where it would create an extra empty list
	  if the group size divided the number of elements.
	Changed name of 'fold-menu-list' to 'fold-menu-list!' to reflect its
	  destructive nature.
	Fixed doc for 'fold-menu-list!' to give the correct variable name for
	  where the default menu length comes from.
	Added FIXMEs about stupid interface to several functions in this file.
	Made the comment for 'split-list-by-group' complete enough to be useful.
	Moved recursive accumulator variable of 'split-list-by-group' into a
	  helper function rather than exposing it to the world as a default
	  parameter.
	Made 'split-list-by-group' preserve the order of the input list
	  reasonably.
	Updated the commented out tests for 'split-list-by-group'.
	Improved doc string for 'fold-menu-list-by-group' so that it is actually
	  useful.

	* std-menus.scm, xlock-menus.scm:
	Modified to match new name ('fold-menu-list!') for 'fold-menu-list'.

- Scott

[Scwm-devs] done testing desk-background.scm

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

done testing desk-background.scm

summary:
made 'desk-background' apply the change immediately if the change
is to the current desktop

changelog:

	* desk-background.scm: Made 'desk-background' apply the change
	immediately if you happen to be on the desktop that is being
	changed.

- Scott

[Scwm-devs] done testing animation.scm

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

done testing animation.scm

not much to test, all works.  Changed some comments.

changelog:

	* animation.scm: Removed some poor comments and tests.

- Scott

[Scwm-devs] done testing animated-iconify.scm

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

done testing animated-iconify.scm

No changes!!!

:-) (-: :-) (-:

- Scott

[Scwm-devs] done testing animated-edge-moves.scm

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

done testing animated-edge-moves.scm

changelog says it all:

	* animated-edge-moves.scm: Removed incorrect comment.

otherwise no problems :-)

- Scott

[Scwm-devs] testing of window manager hint options

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

I still haven't been able to test the window manager hint stuff
since I have found a way to display the options that I can
understand.  I can get stuff from xprop like this:

850> xprop
WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x80015b
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0xbffffc84, 0x0, 0x8186fb0, 0x810f83c
XdndAware(ATOM) = ARC
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x40, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x18, 0x40, 0x10, 0x0, 0x0, 0x0
WM_CLASS(STRING) = "XMMS_Playlist", "xmms"
WM_LOCALE_NAME(STRING) = "en_US"
WM_CLIENT_MACHINE(STRING) = "strider"
WM_ICON_NAME(STRING) = "XMMS Playlist"
WM_NAME(STRING) = "XMMS Playlist"
WM_CLIENT_LEADER(WINDOW): window id # 0x2a00001
WM_HINTS(WM_HINTS):
                Client accepts input or input focus: True
                Initial state is Normal State.
                window id # of group leader: 0x2a00001
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified minimum size: 275 by 319
                program specified maximum size: 275 by 319
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS
WM_TRANSIENT_FOR(WINDOW): window id # 0x2a0001a


I thought I would look at the Motif hints first since they seem to
be the most common, but I haven't been able to find anything that
documents what

_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0xbffffc84, 0x0, 0x8186fb0, 0x810f83c

means.  I've looked on Google a while but didn't find anything particularly
useful.  Any hints?

- Scott