FVWM: Force application to use my icons
Hello, Is there a effective way to force applications to use the icon I set with Style * Icon someicon.png? I accomplished that for mini icons with: Style * EWMHMiniIconOverride But I couldn't with icons. I've tried IconOverride, Icon[Dont]DonateIcon, both settings fails.
FVWM: ResizeMoveMaximize and EwmhBaseStruts issue
Hello, I discovered today the ResizeMoveMaximize function. I find it useful for maximize windows in half screen. But seems it doesn't understand well EwmhBaseStruts (fvwm.2.6.5). For example: With: EwmhBaseStruts 0 72 0 0 The commands: ResizeMoveMaximize frame 50 100 0 0 ResizeMoveMaximize frame 100 50 0 0 ResizeMoveMaximize frame 100 50 0 50 Ignore the Ewmh setting, and: ResizeMoveMaximize frame 50 100 50 0 besides places the window some pixels to the right. Walter
Re: FVWM: WindowList, WarpToWindow and Focus
Thanks Dominik. I've realized too that not using WarpToWindow in WindowListFunc windows doesn't get the focus when switching desktops (Sloppy or MouseFocus), I mean selecting a window in another desktop from the WindowList. Walter
FVWM: WindowList, WarpToWindow and Focus
Hello, Two things I've noticed. First - Using MouseFocus and WindowList function without WarpToWindow, i.e.: DestroyFunc WindowListFunc AddToFunc WindowListFunc + I Iconify off + I FlipFocus + I Raise #+ I WarpToWindow 5p 5p Key Tab A M WindowList Style * MouseFocus or Style * FPEnterToFocus, FPLeaveToUnfocus I can cycle the focus over all windows using the keyboard (Alt+Tab). But if I move the pointer with my mouse over the background (no window focused) the WindowListFunc is unable to focus again any window. The curious thing is this behaviour isn't strict, some times it gives the focus to some window after two or three Alt+Tab attempts, some times it doesn't, some times it just raises the stacked window but without giving it the focus. Once *magically*, after some Alt+Tab attempts, some window gets the focus, MouseFocus allows me to cycle the focus over windows normally again with the pointer staying on root. It doesn't happen using i.e.: Key Tab A M Next (CurrentPage) Focus So perhaps it's a WindowList issue. Second -- This time commenting out Raise from WindowListFunc: AddToFunc WindowListFunc + I Iconify off + I FlipFocus #+ I Raise + I WarpToWindow 5p 5p Windows are raised anyway, unless I comment out the WarpToWindow too. AddToFunc WindowListFunc + I Iconify off + I FlipFocus #+ I Raise #+ I WarpToWindow 5p 5p Using this: Key Tab A M Next (CurrentPage) WarpToWindow 5p 5p Windows are raised too. I thought that the window was raised by WarpToWindow but using this last Key binding with ClickToFocus it doesn't. Besides, if WarpToWindow raises why to include Raise in default WindowListFunc?
Re: FVWM: Icon name is not correctly set on latest FVWM release
On Mon, Jun 10, 2013 at 11:19:01PM +0200, Walter Alejandro Iglesias wrote:
> On Mon, Jun 10, 2013 at 09:00:26PM +0100, Thomas Adam wrote:
> > On 10 Jun 2013 20:56, "Walter Alejandro Iglesias" wrote:
> > >
> > > Hello all,
> > >
> > > I've noticed two issues with 2.6.5 not present in the version that comes
> > > with Debian (2.5.30). 2.6.5 doesn't show the icon name correctly (it
> > > shows
> > > the title name instead) and it doesn't refresh the icon name when
> > > PROMPT_COMMAND variable is set on bashrc. I don't know if both issues
> > > have
> > > a common origin. The second just happens using utf8 locale, probably
> > > iconv
> > > related because it can be avoided setting xterm*utf8Title to False or
> > > compiling FVWM with --disable-iconv or running FVWM with:
> > >
> > > $ LANG=C fvwm
> > >
> > > For example I use in ~/.bashrc:
> > >
> > > PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD/$HOME/~}\007";'
> > > PROMPT_COMMAND+='echo -ne "\033]1;${PWD/$HOME/~}\007"'
> > >
> > > This should print the typical user@host:/path/dir on window title and just
> > > /path/dir on the icon name (and in FvwmIconMan too).
> > >
> > > 1) Icon and IconMan show the title name. Unsetting the PROMPT_COMMAND
> > > variable and running i.e. xterm -n NAME -title TITLE the icon and
> > > IconMan
> > > show TITLE. I didn't found any workaround to this.
> > >
> > > 2) Using utf8 locale and xterm*utf8Title set to true on Xterm the icon
> > > and IconMan show the $OLDPWD instead of $PWD. The workarounds I mention
> > > in the first paragraph avoid this behavior.
> > >
> > > Finally to discard if Debian use some compile option or patch I've
> > > downloaded the 2.5.30 from fvwm.org and compiled it just with
> > > --prefix=/usr
> > > (the same I use to compile 2.6.5). It shows the icon name correctly like
> > > in Debian binary.
> > >
> > >
> >
> > Hi,
> >
> > See:
> >
> > Style * IconTitleFormat %i
> >
> > Thomas
> >
>
> Hi Thomas,
>
> I forgot to search for some new config option on the man page
> before asking here. Thanks.
>
> This corrected the icon name issue.
>
> But utf8Title xterm resource still gives problem; slightly different. Now,
> when I open the first time the xterm the icon shows the window title and it
> changes to the icon name just after the first cd (change dir command).
>
> With utf8Title set to false works perfectly. It's probably XTerm fault
> because
> it doesn't happen with rxvt-unicode.
>
>
> Walter
>
>
Time ago I bothered you with the above. It wasn't a FVWM issue.
I found the solution; changing this:
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD/$HOME/~}\007";'
PROMPT_COMMAND+='echo -ne "\033]1;${PWD/$HOME/~}\007"'
for this:
(here a two instead of the zero)
/
PROMPT_COMMAND='echo -ne "\033]2;${USER}@${HOSTNAME}:${PWD/$HOME/~}\007";'
PROMPT_COMMAND+='echo -ne "\033]1;${PWD/$HOME/~}\007"'
My fault I should documented myself before.
Walter
Re: FVWM: Icon name is not correctly set on latest FVWM release
On Mon, Jun 10, 2013 at 09:00:26PM +0100, Thomas Adam wrote: > Hi, > > See: > > Style * IconTitleFormat %i > > Thomas > Hi again Thomas, Just to let you know that today I've discovered that using iso latin encoding the issue is present too. It's not an utf-8 issue like I've thought. Even using the above style entry, icons and FvwmIconMan show the window title. In 2.5.30 it doesn't happen. Besides, if Debian people refrained themselves from upgrading to the latest version it's because they found issues. Do you (or some one else here) asked them about?
Re: FVWM: Icon name is not correctly set on latest FVWM release
On Mon, Jun 10, 2013 at 09:00:26PM +0100, Thomas Adam wrote:
> On 10 Jun 2013 20:56, "Walter Alejandro Iglesias" wrote:
> >
> > Hello all,
> >
> > I've noticed two issues with 2.6.5 not present in the version that comes
> > with Debian (2.5.30). 2.6.5 doesn't show the icon name correctly (it shows
> > the title name instead) and it doesn't refresh the icon name when
> > PROMPT_COMMAND variable is set on bashrc. I don't know if both issues have
> > a common origin. The second just happens using utf8 locale, probably iconv
> > related because it can be avoided setting xterm*utf8Title to False or
> > compiling FVWM with --disable-iconv or running FVWM with:
> >
> > $ LANG=C fvwm
> >
> > For example I use in ~/.bashrc:
> >
> > PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD/$HOME/~}\007";'
> > PROMPT_COMMAND+='echo -ne "\033]1;${PWD/$HOME/~}\007"'
> >
> > This should print the typical user@host:/path/dir on window title and just
> > /path/dir on the icon name (and in FvwmIconMan too).
> >
> > 1) Icon and IconMan show the title name. Unsetting the PROMPT_COMMAND
> > variable and running i.e. xterm -n NAME -title TITLE the icon and IconMan
> > show TITLE. I didn't found any workaround to this.
> >
> > 2) Using utf8 locale and xterm*utf8Title set to true on Xterm the icon
> > and IconMan show the $OLDPWD instead of $PWD. The workarounds I mention
> > in the first paragraph avoid this behavior.
> >
> > Finally to discard if Debian use some compile option or patch I've
> > downloaded the 2.5.30 from fvwm.org and compiled it just with --prefix=/usr
> > (the same I use to compile 2.6.5). It shows the icon name correctly like
> > in Debian binary.
> >
> >
>
> Hi,
>
> See:
>
> Style * IconTitleFormat %i
>
> Thomas
>
Hi Thomas,
I forgot to search for some new config option on the man page
before asking here. Thanks.
This corrected the icon name issue.
But utf8Title xterm resource still gives problem; slightly different. Now,
when I open the first time the xterm the icon shows the window title and it
changes to the icon name just after the first cd (change dir command).
With utf8Title set to false works perfectly. It's probably XTerm fault because
it doesn't happen with rxvt-unicode.
Walter
FVWM: Icon name is not correctly set on latest FVWM release
Hello all,
I've noticed two issues with 2.6.5 not present in the version that comes with
Debian (2.5.30). 2.6.5 doesn't show the icon name correctly (it shows the
title name instead) and it doesn't refresh the icon name when PROMPT_COMMAND
variable is set on bashrc. I don't know if both issues have a common origin.
The second just happens using utf8 locale, probably iconv related because it
can be avoided setting xterm*utf8Title to False or compiling FVWM with
--disable-iconv or running FVWM with:
$ LANG=C fvwm
For example I use in ~/.bashrc:
PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}:${PWD/$HOME/~}\007";'
PROMPT_COMMAND+='echo -ne "\033]1;${PWD/$HOME/~}\007"'
This should print the typical user@host:/path/dir on window title and just
/path/dir on the icon name (and in FvwmIconMan too).
1) Icon and IconMan show the title name. Unsetting the PROMPT_COMMAND
variable and running i.e. xterm -n NAME -title TITLE the icon and IconMan show
TITLE. I didn't found any workaround to this.
2) Using utf8 locale and xterm*utf8Title set to true on Xterm the icon and
IconMan show the $OLDPWD instead of $PWD. The workarounds I mention in the
first paragraph avoid this behavior.
Finally to discard if Debian use some compile option or patch I've downloaded
the 2.5.30 from fvwm.org and compiled it just with --prefix=/usr (the same I
use to compile 2.6.5). It shows the icon name correctly like in Debian binary.
Re: FVWM: ImageMagick display style option?
On Mon, Mar 25, 2013 at 05:46:09PM -0600, Jaimos Skriletz wrote: > On Mon, Mar 25, 2013 at 08:45:36PM +0100, > michael.gros...@gmx.de wrote: > > Hello everybody, > > > > I've noted that when I open with (ImageMagick) > > display command an image larger than the screen the > > window geometry doesn't take in care borders and > > title, then right and bottom window borders are > > hidden outside the limit of the screen. Somebody > > knows a style option or another workaround for this? > > > > > > Have you tried the using the -geometry option for display. Yes, I'd tried that. I asked here to know if it exists a better way. Thanks Jaimos
Re: FVWM: ImageMagick display style option?
On Mon, Mar 25, 2013 at 09:59:14PM +0100, Michael Großer wrote: > Walter Alejandro Iglesias wrote: > > Hi Michael, > > > > On Mon, Mar 25, 2013 at 08:45:36PM +0100, michael.gros...@gmx.de wrote: > >> > Hello everybody, > >> > > >> > I've noted that when I open with (ImageMagick) display command > >> > an image larger than the screen the window geometry doesn't take > >> > in care borders and title, then right and bottom window borders > >> > are hidden outside the limit of the screen. Somebody knows a > >> > style option or another workaround for this? > >> > > >> > > >> > Thanks in advance > >> > > >> > Walter > >> > > >> > > >> > >> > >> > >> I have this with XV too, but I like this behavior, because this is > >> exactly what I want: Seeing an unscaled image > > > > By default the display command doesn't scale the image but > > resizes the frame and open the little window with a thumbnail > > where you click and scroll. The problem is Imagemagick > > considers the size of the physical screen without resting the > > width of the window frame and title. > > > > For example if you remove borders and title: > > > > Style display !Title, !Handles, !Borders > > > > and open an image larger than the screen you can scroll the > > whole image using the thumbnail mini-window. With the borders > > and title you can't (unless you scroll along the screen with the > > pager). > > > > > Hi Walter, > > in both of your messages, you described what you get, but you > didn't describe what you want instead. > > Please describe in detail which behavior you exactly want. > Tastes of people are very different, and it is hard to guess > your taste in your case. Probably xv (I haven't it on Debian) doesn't do exactly the same than display command that's why you don't understand me. The behavior expected is the same you get when you maximize a window. Imagine that you maximize a window but the program forces the real screen size on the dimensions of the buffer (not the real size of the content, the image in this case). The result is, if the external +0+0 corner of the title frame is placed on +0+0 of the physical screen the right and bottom borders are drawn out of the screen. Remember that what the program tries to do is to *resize* the frame to fit on the screen, the frame doesn't respect the real size of the image. What you obviously want is to see the whole title and frames on the screen, like any maximized window. > > - Michael -
Re: FVWM: ImageMagick display style option?
Hi Michael, On Mon, Mar 25, 2013 at 08:45:36PM +0100, michael.gros...@gmx.de wrote: > > Hello everybody, > > > > I've noted that when I open with (ImageMagick) display command > > an image larger than the screen the window geometry doesn't take > > in care borders and title, then right and bottom window borders > > are hidden outside the limit of the screen. Somebody knows a > > style option or another workaround for this? > > > > > > Thanks in advance > > > > Walter > > > > > > > > I have this with XV too, but I like this behavior, because this is > exactly what I want: Seeing an unscaled image By default the display command doesn't scale the image but resizes the frame and open the little window with a thumbnail where you click and scroll. The problem is Imagemagick considers the size of the physical screen without resting the width of the window frame and title. For example if you remove borders and title: Style display !Title, !Handles, !Borders and open an image larger than the screen you can scroll the whole image using the thumbnail mini-window. With the borders and title you can't (unless you scroll along the screen with the pager).
FVWM: ImageMagick display style option?
Hello everybody, I've noted that when I open with (ImageMagick) display command an image larger than the screen the window geometry doesn't take in care borders and title, then right and bottom window borders are hidden outside the limit of the screen. Somebody knows a style option or another workaround for this? Thanks in advance Walter
Re: FVWM: Bugreport: fvwm crashes under Debian
On Sun, Feb 10, 2013 at 01:31:19PM +0100, Dirk Thierbach wrote: > Hello, > > if this is the wrong place for bugreports, or if I should use the other > list, please tell me. I couldn't find anything on the homepage, but maybe > I overlooked it. > > I updated fvwm to 1:2.6.5.ds-1 on Debian Sid (unstable), and now I > experience frequent crashes which dump me back to the xdm login screen. > > They happen unpredicatbly when changing or deleting a tab in > iceweasel (which changes the title of the iceweasel window). > I remember having that problem with some version of firefox, not only with FVWM but with fluxbox too. I read people on forums complaining about the same problem with Xfce. I ignore which version of firefox iceweasel sid package fork. Download the latest firefox from mozilla site and try to reproduce the bug. I think that it's some issue with hardware acceleration. You could also try disabling that feature on Iceweasel (on Advanced tag in Options uncheck "hardward accel...") if that version already have it. Walter
FVWM: Missing Font Charsets
On Sun, Oct 28, 2012 at 09:01:52PM -0400, Dan Espen wrote: > > > (Please start new threads for new subjects) Hi again Dan The output of that command in my machine is: $ xlsfonts -fn -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-*-* -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-8 -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-8 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-10 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-10 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-11 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-11 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-13 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-13 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-14 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-14 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-15 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-15 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-16 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-16 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-2 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-2 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-3 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-3 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-4 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-4 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-5 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-5 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-7 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-7 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-8 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-8 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-9 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-9 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-koi8-r -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-koi8-r -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-koi8-r -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-koi8-r -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso10646-1 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso10646-1 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-1 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-1 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-1 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-1 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-10 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-10 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-11 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-11 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-13 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-13 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-14 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-14 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-15 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-15 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-16 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-16 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-2 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-2 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-3 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-3 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-4 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-4 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-5 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-5 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-7 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-7 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-8 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-8 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-9 -misc-fixed-medium-r-semicondensed--13-94-100-100-c-0-iso8859-9
Re: FVWM: Speed on Interactive Move/Resize
On Sun, Oct 28, 2012 at 02:24:42PM -0400, Dan Espen wrote: > Walter Alejandro Iglesias writes: > > > Hello, > > > > On interactive Move/Resize the default step is 5 pixels, 100p holding > > Shift and 1p holding Ctrl. > > > > Is there a way of customize that? > > Currently no. > > The values 1,5,100 are defined in: > > libs/default.h Hi again Dan, off topic but related Reading this header file I discovered something related to other post I did here titled "Bitmap Fonts and UTF-8". That the three fonts that appeared on PrintInfo output (I explained on that post not included by me on any style) are the fonts hard coded on libs/default.h: -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-*-*, -*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*, -*-*-medium-r-normal-*-16-*-*-*-*-*-*-* Now I tried the following. I commented out all Font entries in my styles and let FVWM load the fonts itself. In theory FVWM should load some of the fonts above (Am I wrong?). Once started all defaulted to the first of the three mentioned: -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-*-* with NO errors on start up and rendering the correct characters. But if I include that font in any style entry it appears the error: [fvwm][FlocaleGetFontSet]: (-*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-*-*) Missing font charsets: JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0 Googling, I saw that this is an old issue with utf-8 and X server trying to find the font that matches on all encodings. I don't know if all this comment is useful because that X issue seems not to have a solution.
Re: FVWM: Speed on Interactive Move/Resize
On Sun, Oct 28, 2012 at 02:24:42PM -0400, Dan Espen wrote: > Walter Alejandro Iglesias writes: > > > Hello, > > > > On interactive Move/Resize the default step is 5 pixels, 100p holding > > Shift and 1p holding Ctrl. > > > > Is there a way of customize that? > > Currently no. > > The values 1,5,100 are defined in: > > libs/default.h > #define DEFAULT_KDB_SHORTCUT_MOVE_DISTANCE 5 /* pixels */ > #define KDB_SHORTCUT_MOVE_DISTANCE_SMALL 1 /* pixels */ > #define KDB_SHORTCUT_MOVE_DISTANCE_BIG 100 /* pixels */ > > And the logic is in: > > libs/Target.c > > -- > Dan Espen Hi Dan, Good to know what you point above. Thanks. I'd like to start learning about Xlib programing. I found this: http://www.tronche.com/gui/x/xlib-tutorial/ Could you point me (advice) to more related documentation? Where/how is it convenient to start? Walter
Re: FVWM: Speed on Interactive Move/Resize
On Sun, Oct 28, 2012 at 02:59:34PM +, Thomas Adam wrote: > On 28 October 2012 14:53, Walter Alejandro Iglesias wrote: > > Hello, > > > > On interactive Move/Resize the default step is 5 pixels, 100p holding > > Shift and 1p holding Ctrl. > > > > Is there a way of customize that? > > Are you referring to "MoveThreshold"? > > -- Thomas Adam No. For example, I bind the function Move (as is) to Alt+F7. Once pressed Alf+F7 it starts "interactive" move. Now I can use arrow keys (or vi / emacs keys via readline) to move the window. If I use just that keys the window moves 5 pixels each time, doing the same while I hold Shift the window moves 100 pixels each time and holding Ctrl 1 pixel. I'd like to know if there is a way to customize that and move with a i.e. 10 pixel steps. Thomas, answer just in case you have time, because it is not too important. I can live with the default :). Thanks. Walter
FVWM: Speed on Interactive Move/Resize
Hello, On interactive Move/Resize the default step is 5 pixels, 100p holding Shift and 1p holding Ctrl. Is there a way of customize that? Thanks in advance.
FVWM: Rxvt Run Dialog Tip
Hello, I've found this wonderful tip in fvwmwiki: http://fvwmwiki.xteddy.org/Tips/RxvtRunDialogue/ It has just one typo error. The option --keysym.0xFF0D: " &\nexit\n" shoud be -keysym.0xFF0D " &\nexit\n" Just one hyphen and no colon. It could be writen too in this more comprensible syntax: -keysym.Return " &\nexit\n" Thanks to who wrote it (Thomas?). I will include a link in my website where I have a small window manager tutorial for Linux. Walter
Re: FVWM: Bitmap Fonts and UTF-8
Well I reply myself :) I'd thought it was a fvwm2 problem because I tried fvwm1, twm, fluxbox and they rendered the right characters. But today I've upgraded to Slackware 14 and the problem I had with bitmap fonts and utf-8 despaired. I still ignore the cause (freetype, xorg?). Thanks Thomas and the rest of fvwm develpers for your work! Walter
FVWM: Bitmap Fonts and UTF-8
Hello all, I've read other recent post here about the same issue but the original question is not answered there. Not a big problem but I'd like to know if it's really posible get bitmap fonts rendering utf-8 characters. I use en_US.UTF-8 locale. Using scalable fonts (i.e. xft:sans-10) all utf-8 characters are showed fine. But I couldn't get it work with bitmap fonts like: Style * Font -*-helvetica-medium-r-normal-*-12-*-*-*-*-*-iso10646-1 I read the man page and tried some stated there. The output of PrintInfo: --- fvwm info on locale: locale: en_US.UTF-8, Modifier: Default Charset: X: ISO8859-1, Iconv: Not defined, Bidi: No XOM Charsets: ISO8859-1 ISO8859-1 ISO8859-2 Number of loaded font: 1 * Font number 0 fvwm info: Name: -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-*-*,-*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*,-*-*-medium-r-normal-*-16-*-*-*-*-*-*-* Cache count: 1 Type: FontSet Charset: X: ISO8859-1, Iconv: Not defined, Bidi: No height: 13, ascent: 11, descent: 2 shadow size: 0, shadow offset: 0, shadow direction:0 X info: -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-100-100-100-c-60-iso8859-1 -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso8859-2 - shows three fonts not included by me in any config file. I use just two, the helvetica above and a fixed (both iso10646-1). Some clue? Thanks Walter
Re: FVWM: Focus after Iconify
On Tue, May 29, 2012 at 12:23:57PM -0500, Jonathan Kotta wrote: > On Sun, May 27, 2012 at 2:05 PM, Walter Alejandro Iglesias > wrote: > > On Sun, May 27, 2012 at 01:19:15PM -0500, Jonathan Kotta wrote: > >> On Sun, May 27, 2012 at 10:31 AM, Walter Alejandro Iglesias > >> wrote: > >> > Hello, > >> > > >> > I use ClickToFocus and just IconMan, I don't use icons. > >> > > >> > When I iconify a window I expect the last focused window > >> > recovers the focus. It happens just randomly. > >> > > >> > I use the default Iconify function. I've tried adding custom > >> > functions (following what I've found in some posts in the Fvwm > >> > forum about similar issues) without success. Perhaps I don't > >> > understand well what Fvwm saves for Prev and Next windows; is this > >> > managed by FvwmWindowList function? > >> > > >> > Thanks in advance. > >> > > >> > Walter > >> > > >> > > >> > > >> > > >> > >> I also use ClickToFocus, and use FvwmEvent to switch focus when > >> iconifying. It works well for me. > >> > >> , > >> | DestroyFunc FocusPrev > >> | AddToFunc FocusPrev > >> | + I None (CurrentPage, Focused, AnyScreen) \ > >> | Prev (CurrentPage, !Iconic, !Shaded, Visible, AcceptsFocus, > >> AnyScreen) \ > >> | Focus NoWarp > >> | > >> | DestroyModuleConfig FvwmEventFocus: * > >> | *FvwmEventFocus: Cmd Function > >> | *FvwmEventFocus: new_page FocusPrev > >> | *FvwmEventFocus: new_desk FocusPrev > >> | *FvwmEventFocus: destroy_window FocusPrev > >> | *FvwmEventFocus: iconify FocusPrev > >> | > >> | KillModule FvwmEvent FvwmEventFocus > >> | FvwmEvent FvwmEventFocus > >> ` > >> > >> -- > >> Thanks, > >> > >> Jonathan Kotta > >> > >> Hofstadter's Law: > >> It always takes longer than you expect, even > >> when you take into account Hofstadter's Law. > > > > > > Hy Jonathan > > > > Should I add this function to a custom version of Iconify? > > > > Sounds like you got it working, but I'll follow up anyway. You don't > need to define your own version of Iconify. With the snippet I > posted, FvwmEvent runs FocusPrev every time a window is iconified (and > also whenever a window is destroyed, or the page or desk is changed). > > -- > Thanks, > > Jonathan Kotta > > Hofstadter's Law: > It always takes longer than you expect, even > when you take into account Hofstadter's Law. Hi, Jonathan I'd tried adding your function and activating FvwmEvent module but the issue was still there. More late I released that neither what I said in my last post had fixed it. What finally worked was a little change I did in the function I use for mouse actions on IconMan. Time ago I read this post: http://www.fvwmforums.org/phpBB3/viewtopic.php?f=33&t=1933 and after trying some changes I got the function I was using till now: DestroyFunc IconManClicked AddToFunc IconManClicked + I ThisWindow (Iconic) Iconify + I TestRc (Match) Break + I ThisWindow (Focused) Iconify + I TestRc (Match) Break + I ThisWindow (!Focused) Focus + I TestRc (!Match) Break + I ThisWindow Raise But for some reason, randomly selecting windows by clicking on the iconman several times at some point altered the focus order. Now I've changed it for this: DestroyFunc IconManClicked AddToFunc IconManClicked + I ThisWindow (Iconic) Iconify + I TestRc (Match) Break + I ThisWindow (Focused) Iconify + I TestRc (Match) Break + I ThisWindow (!Focused) FlipFocus + I TestRc (!Match) Break + I ThisWindow Raise and problem solved. It was replacing Focus for FlipFocus the magic touch. Salu2 Walter
Re: FVWM: Focus after Iconify
I've found my error. I used: DestroyFunc FuncIconifyAndFocusPrev AddToFunc FuncIconifyAndFocusPrev + I Prev (AcceptsFocus, CurrentPage, !Iconic) Focus + I Prev (AcceptsFocus, CurrentPage, !Iconic) Raise + I Iconify on for the title iconify button. But for some reason (I don't remember why I included this option) I had this: Style * CirculateSkip, CirculateSkipIcon in my general style options, that's why the above didn't work. After removing it, all works like expected. Thanks Walter PD: If you include my address in Carbon Copy I receive your message twice.
Re: FVWM: Focus after Iconify
On Sun, May 27, 2012 at 01:19:15PM -0500, Jonathan Kotta wrote: > On Sun, May 27, 2012 at 10:31 AM, Walter Alejandro Iglesias > wrote: > > Hello, > > > > I use ClickToFocus and just IconMan, I don't use icons. > > > > When I iconify a window I expect the last focused window > > recovers the focus. It happens just randomly. > > > > I use the default Iconify function. I've tried adding custom > > functions (following what I've found in some posts in the Fvwm > > forum about similar issues) without success. Perhaps I don't > > understand well what Fvwm saves for Prev and Next windows; is this > > managed by FvwmWindowList function? > > > > Thanks in advance. > > > > Walter > > > > > > > > > > I also use ClickToFocus, and use FvwmEvent to switch focus when > iconifying. It works well for me. > > , > | DestroyFunc FocusPrev > | AddToFunc FocusPrev > | + I None (CurrentPage, Focused, AnyScreen) \ > | Prev (CurrentPage, !Iconic, !Shaded, Visible, AcceptsFocus, AnyScreen) \ > | Focus NoWarp > | > | DestroyModuleConfig FvwmEventFocus: * > | *FvwmEventFocus: Cmd Function > | *FvwmEventFocus: new_page FocusPrev > | *FvwmEventFocus: new_desk FocusPrev > | *FvwmEventFocus: destroy_window FocusPrev > | *FvwmEventFocus: iconifyFocusPrev > | > | KillModule FvwmEvent FvwmEventFocus > | FvwmEvent FvwmEventFocus > ` > > -- > Thanks, > > Jonathan Kotta > > Hofstadter's Law: > It always takes longer than you expect, even > when you take into account Hofstadter's Law. Hy Jonathan Should I add this function to a custom version of Iconify?
FVWM: Focus after Iconify
Hello, I use ClickToFocus and just IconMan, I don't use icons. When I iconify a window I expect the last focused window recovers the focus. It happens just randomly. I use the default Iconify function. I've tried adding custom functions (following what I've found in some posts in the Fvwm forum about similar issues) without success. Perhaps I don't understand well what Fvwm saves for Prev and Next windows; is this managed by FvwmWindowList function? Thanks in advance. Walter
