Re: Improving the default config
> 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: >> > 13. The window menu should have a SendToPage button too. >> > >> >> Okay. > > What is actually the "Current desk" option good for? > It was meant to bring the window the the current desk/page when working with FvwmIconMan. In my setup clicking on a button in FvwmIconMan brings you to the desk/page the window is on. Use SendTo current to bring the window to you. In my patch I tried to clean this up so now there is a Current (meaning desk and page) and the the option to send to different desks or pages. > >> > 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. > Yea unsure here. I left it as is. >> >> > 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? I don't think so, but it appears that some actions are triggered on a button press and others on a button release. From the FvwmIconMan man page: Normally, actions bound to a mouse click are executed when the button is pressed. In transient mode, the action is executed when the button is released, since it is assumed that FvwmIconMan was bound to some mouse event. So I think that the action is triggered as soon as the button is pressed, and then it is something in the function handling that causes the issue. When I hold the button for what would be the time for a Hold to happen Fvwm gives me this error: [fvwm][ComplexFunction]: <> Grab failed in function IconManClick, unable to execute immediate action So it seems that something in function handling is breaking the function if the button is held down to long. jaimos
Re: Improving the default config
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
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.) > ... Ciao Dominik ^_^ ^_^ -- Dominik Vogt
Re: Improving the default config
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 ThisWindow (Iconic) I
Re: Improving the default config
On Sat, Dec 31, 2016 at 6:03 AM, Dominik Vogt wrote:
> Fiddling with the fdefault config to reproduce a bug, there are
> some things that I don't understand or that should be improved.
>
Thank you.
> 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.
> 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.
> 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.
>
> 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
>
> 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.
> 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.
> 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 win
Improving the default config
Fiddling with the fdefault config to reproduce a bug, there are
some things that I don't understand or that should be improved.
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.
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.
3. The main menu has a submenu for module manpages, but not a
submenu to start them. Weird.
4. The "Copy config" dialog should *really* state the filename of
the config file it generates, not just the target directory.
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).
6. Clicking the "X" button works only with a delay.
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.
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
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"
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
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.)
This should also add
+ I MoveToPage
+ I MoveToDesk
(or GotoDesk/GotoPage to the window's desk and page).
12. Shouldn't the icon manager show an indication of whether a
window is hidden or not?
13. The window menu should have a SendToPage button too.
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.
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.
16. That just wastes resources for nothing:
*FvwmIconMan: Action Mouse 2 A sendcommand Nop
17. Fvwm can *really* do better than "TileCascadePlacement". I
suggest to use MinOverlapPlacement.
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
Instead, use
OpaqueMoveSize unlimited
20. This is never used anyway, since moving and resizing is always
in opaque mode:
XorValue 5
21. Why?
HideGeometryWindow
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
