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 <dominik.v...@gmx.de> wrote:
> > 1. In the log there is
> >
> > Traceback (most recent call last):
> > File "/home/luthien/bin/fvwm-menu-desktop", line 78, in <module>
> > 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 4 T A MoveClickX Nop Raise "WindowShade True"
> > Mouse 5 T A MoveClickX Nop Raise "WindowShade False"
> >
> > Also, this should really be just
> >
> > Mouse 4 T A WindowShade True
> > Mouse 5 T A 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 1 FS 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 4 T A 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 1 T A MoveClickX Move Raise Maximize
> > Mouse 1 I A 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 ThisWindow (Iconic) Iconify
> >> + I ThisWindow (AcceptsFocus) FlipFocus
> >
> > Most conditions are not necessary:
> >
> > AddToFunc IconManClick
> > + I ThisWindow (Raised, !Shaded, !Iconic, CurrentPage) Iconify
> > + I TestRc (Match) Break
> > + I ThisWindow WindowShade off
> > + I ThisWindow Iconify off
> > + I ThisWindow Raise
> > + I ThisWindow (AcceptsFocus) FlipFocus
> >
> > (Also reordered to reduce the number of expose events.)
> >
>
> Okay, can update this.
>
> > This should also add
> >
> > + I MoveToPage
> > + I MoveToDesk
> >
> > (or GotoDesk/GotoPage to the window's desk and page).
> >
>
> Why? In my tests FlipFocus moves you to the Desk/Page the window is on
> when clicked. Or are you saying you would prefer it moved the window
> to the current Desk/Page when clicked?
>
> > 12. Shouldn't the icon manager show an indication of whether a
> > window is hidden or not?
> >
>
> Yea, I can add another colorset for this. Or I can just go for the
> defaults in FvwmIconMan and let the miniicon be the symbol for
> iconified windows. I prefer to always see the icons so I'll add a new
> colorset for incoified windows.
>
> > 13. The window menu should have a SendToPage button too.
> >
>
> Okay.
What is actually the "Current desk" option good for?
See dv/devel.
> > 14. Raising windows issue with FvwmButttons:
> >
> > * Move some window partially over the panel, then
> > * Click on its button in the icon manager.
> > => The panel is raised, hiding the window, then the window
> > is raised over the panel. Looks weird.
> >
>
> Okay, I'll put the pannel on bottom so it can't be raised over windows.
I wonder if this is good. There should be some other way to
prevent this flashing.
>
> > 15. Not sure why, but if you press a button in the icon manager
> > and hold it for some time, releasing it does not activate the
> > window.
> >
>
> Hmm this is weird? Something to do with FvwmIconMan? I experience this
> in a standalone FvwmIconMan too that is not swallowed in FvwmButtons.
> I don't see why the function that gets called would have an affect on
> this.
Hm, does FvwmIconMan have some kind of "hold" action?
>
> > 16. That just wastes resources for nothing:
> >
> > *FvwmIconMan: Action Mouse 2 A sendcommand Nop
> >
>
> It was meant to disable the default action of FvwmIconMan, but this
> should be mouse button 0 not 2 to disable the default for all buttons,
> not just button 2. I personally don't want other buttons to iconfiy,
> but this might just be my personal preference.
See dv/devel for a patch.
>
> > 17. Fvwm can *really* do better than "TileCascadePlacement". I
> > suggest to use MinOverlapPlacement.
> >
>
> Okay, MinOverlapPlacement is what I prefer anyways, I was just trying
> to be more traditional.
:-)
See dv/devel.
> > 18. Just do that without decors:
> >
> > DestroyDecor FvwmDecor
> > AddToDecor FvwmDecor
> > ...
> > Style * BorderWidth 5, HandleWidth 5, MWMButtons, \
> > FvwmBorder, FirmBorder, UseDecor FvwmDecor
> >
>
>
> > 19. This depends on undefined behaviour and might as well disable
> > opaque moves completely:
> >
> > OpaqueMoveSize -1
> >
>
> It is mentioned in the manpage, "or if a negative percentage is given
> all windows are moved as solid windows", but didn't not realize it had
> an issue using -1 vs unlimited.
>
> > Instead, use
> >
> > OpaqueMoveSize unlimited
Yeah, the -1 stuff is probably just some historical curiosity.
> I'll make the change.
See dv/devel.
> > 20. This is never used anyway, since moving and resizing is always
> > in opaque mode:
> >
> > XorValue 55555
> >
>
> Okay I'll remove it.
See dv/devel.
> > 21. Why?
> >
> > HideGeometryWindow
> >
>
> Personal choice as I don't like it, but sure I'll remove it.
This should rather be over the panel instead of the top left
corner, but it's hard coded at the moment.
See dv/devel.
> I'll make some updates and send a patch,
Hope you've not duplicated all my patches yet...
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
