Re: Improving the default config

[Jaimos Skriletz]

On Sat, Dec 31, 2016 at 8:31 AM, Dominik Vogt  wrote:
> On Sat, Dec 31, 2016 at 04:18:26PM +0100, Dominik Vogt wrote:
>> See branch dv/devel for various patches.
>
> (Feel free to use any of these patches to build a new patch.)
>

Thanks. I incorporated some of your suggestions.

I have hopefully made fvwm-menu-desktop error out nicer when either
python-xdg or a .menu file is not found.

In additions I have grouped some of your config changes (and some I
had in mind) into a single patch on js/default-config-changes.

Hopefully the commits explain enough, if you have any questions please ask.

happy new year.

jaimos

Re: Improving the default config

[Dominik Vogt]

See branch dv/devel for various patches.


On Sat, Dec 31, 2016 at 07:26:54AM -0700, Jaimos Skriletz wrote:
> On Sat, Dec 31, 2016 at 6:03 AM, Dominik Vogt  wrote:
> > 1. In the log there is
> >
> > Traceback (most recent call last):
> >   File "/home/luthien/bin/fvwm-menu-desktop", line 78, in 
> > import xdg.Menu
> > ImportError: No module named xdg.Menu
> >
> >We should get rid of any error messages during startup, even if
> >some things may not be installed.
> >
> > 1b. In the builtin menu (if no config is used), the above message
> >is generated every time you move the pointer over the xdg menu
> >item.
> >
> 
> Yes we should deal with the case either python or python-xdg is not
> installed. Unsure if there is a way we can test for python-xdg with
> Test or if that should be done in the fvwm-menu-desktop script. I
> would like the script to error out if run from a console and
> python-xdg is not installed so the user is aware of a missing
> component, so maybe add a -q/--quiet option that can be used in the
> config to just have it quietly exit if python-xdg is not installed.
> 
> > 2. Are the buttons of inactive windows really meant to look like
> >in the attached image?  NeverFocus windows like Xclock don't
> >ever get their buttons drawn properly.
> >
> 
> Yes that is how the config draws inactive buttons. This can be
> changed, I just copied this from my setup.
> 
> > 3. The main menu has a submenu for module manpages, but not a
> >submenu to start them.  Weird.
> >
> 
> This was brought up and is something that could be added. Though
> outside of FvwmConsole I personally don't know what other modules
> would be that useful to have in a menu to be launched, without some
> additional configurations of the module. But by all means add a
> submenu.
> 
> > 4. The "Copy config" dialog should *really* state the filename of
> >the config file it generates, not just the target directory.
> >
> 
> Okay.
> 
> > 5. Double clicking the top left window button does not close the
> >window.  The menu needs a doubleclick action:
> >
> > Mouse 1 1 A Menu MenuWindowOps delete
> >
> >(or maybe "destroy" instead).
> >
> 
> I would not think that double clicking the menu button would close a
> window. But this could be added, though I don't see why since this can
> be done via the X button.

It's a historical thing.  Double clicking that button close
windows long before the X button even appeared.

See dv/devel.

> > 6. Clicking the "X" button works only with a delay.
> >
> 
> It is set up for a single click is Close and a double click is
> Destroy. So the delay is just the function waiting for ClickTime to
> pass to make sure it wasn't a double click.

I know, but it's annoying.  Shouldn't that button just bind
"Delete" on a click?  More forceful methods of closing are
available through the window menu.

The first patch on the branch is an attempt to close the window
earlier, but it doesn't actually work as we have to wait for the
end of the function anyway.

> > 7. The config uses button 4+5 for window shading.  It shouldn't
> >require any non-standard mouse buttons for that.
> >
> >  Mouse 4TA MoveClickX Nop Raise "WindowShade True"
> >  Mouse 5TA MoveClickX Nop Raise "WindowShade False"
> >
> >Also, this should really be just
> >
> >  Mouse 4TA WindowShade True
> >  Mouse 5TA WindowShade False
> >
> >Otherwise it may or may not raise the window when pushing a
> >mouse wheel, depending on the speed of the wheel.
> 
> Fine, again just another thing adopted because I prefer the double
> click here, but your solution is simpler.

See dv/devel.

> > 8. The MoveClickX function is used even for functions that do not
> >have a doubleclick action ("Nop" instead).  Therefore clicking
> >such a indow button works only with a delay (coubleclicktime),
> >and it won't work at all if you double click:
> >
> >  Mouse 1FS   A MoveClickX Resize Raise Nop

See dv/devel.

> > 9. Similarly, a button with "Nop" move action won't do anything if
> >you happen to move the mouse while clicking:
> >
> >  Mouse 4TA MoveClickX Nop Raise "WindowShade True"
> >
> 
> Didn't consider that as I'm just use to it, I was just trying to avoid
> writing multple functions, but I agree it would be better to not have
> the Nop there now that I look at it in a different light.

See dv/devel.

> > 10. Moving a window from the titlebar or icon should also raise
> > it:
> >
> >  Mouse 1TA MoveClickX Move Raise Maximize
> >  Mouse 1IA MoveClickX Move Nop Iconify
> >
> 
> Okay.

See dv/devel.

> > 11. The function
> >
> >> AddToFunc   IconManClick
> >> + I ThisWindow (Raised, !Shaded, !Iconic, CurrentPage) Iconify
> >> + I TestRc (Match) Break
> >> + I ThisWindow (!Raised) Raise
> >> + I ThisWindow (Shaded) WindowShade
> >> + I