Re: Looks switching bug

Randall Hopper (
Thu, 7 Jan 1999 07:03:11 -0500

 |Randall Hopper:
 |> Hey, great work on the looks!  I like it.  Running 1.6.6 here.  
 |> (Now if we can just figure out how to keep Feels/Looks with a customized
 |> start menu.)
 |You mean, keep the default Feels/Looks as well as custom ones?  If you 
 |only care about seeing the ones in ~/G/L/A, just create an empty dir in 
 |the start menu called "Look" and/or "Feel", and it will be automagically 
 |filled in when the menu is updated.

Unfortunately, this isn't the case here.  I did:

     > cd ~/.GNUstep/Library/AfterStep
     > mkdir looks feels pictures

, then rebuilt the start menu via Desktop->Update-Start-Menu, and the
Looks, Feels, and Pictures menus are gone from the Desktop menu, as before.
If I nuke non-configurable/startmenu and restart AfterStep, they're back.

When I don't see the menus, AfterStep has generated
non-configurable/startmenu to contain:

     Popup "Feel"
      Title "Feel"
      MiniPixmap "mini-as.xpm"

but there is no invocation of this Popup anywhere.  Now if I rmdir the
directories we created in the local AfterStep cfg dir above and rebuild the
Start menu, then I get filled-out popups e.g.:

     Popup "Feel"
      Title "Feel"
      MiniPixmap "mini-as.xpm"
      ChangeFeel "feel.AutoRaise" /home/rhh/software/AfterStep-1.6.6/share/afterstep/feels/feel.AutoRaise
      ChangeFeel "feel.ClickToFocus" /home/rhh/software/AfterStep-1.6.6/share/afterstep/feels/feel.ClickToFocus

(presumably populated from the global cfg dir).  "However", still there is
no invocation of this Popup anywhere in the startmenu file.

 |If you want to see both the defaults and the custom ones, get the 1.7 
 |patches and experiment with .include files.

Sounds good.  Guess I'll wait for 1.7 or 1.8 and try another upgrade.

 |> One quirk I noticed with the looks though is that if I have some icons on
 |> the desktop and I switch looks between two that have different IconBoxes,
 |> the icons don't move into the new box until I iconify/deiconify something
 |> (i.e. force reevaluation of the icons).
 |> Certainly not a big deal.  Just thought I'd make a note of it in case its
 |> an easy fix.
 |Yup, it was an easy fix. :)  Fixed in 1.7.0 patch 18.


Randall Hopper