Re: Last thought
Hey, time to take this to personal email. Doesn't belong here. This list is public, anything you say here will follow you around. I'm sure you both have good intentions.
Re: FVWM: A problem in FVWM quit abnormally.
source liu sourceo...@gmail.com writes: Yes, which is why I still find xconsole invaluable. :) could you explain this sentence a little bit? :), i mean, how invaluable. In most set ups, it's not easy to tell whether X has crashed or the window manager has crashed. You can use an application like xconsole to hold the session instead of the window manager so that you can tell the difference. It's not something for a beginning user through. To figure out whether X has crashed, take a look at /var/log/Xorg.0.log. See if you can find anything that indicates that it crashed. -- Dan Espen
Re: FVWM: A problem in FVWM quit abnormally.
Thomas Adam tho...@fvwm.org writes: I wouldn't bother with the Xorg logs myself either -- just concentrate on getting a corefile if FVWM really is crashing, which from your description, suggests it is. I'm curious Tom, what makes you think it's Fvwm and not X? Doesn't KDM gain control with either type of crash? Personally, I don't use any kind of DM and use Xlogout to hold the session so I can easily tell what crashed. -- Dan Espen
Re: FVWM: fvwmiconman question
Ingo Wardinski i...@gfz-potsdam.de writes: Hi there, I try to set up fvwmiconman for my needs, therefore I use the conig given in the fvwmiconman manpage. There is a line saying FvwmIconMan: Action Mouse 1 N sendcommand Iconify What does the N stands for? Action is followed by an fvwm command. Therefore, look up Mouse in the main man page. 1 is the button, N means no modifier keys pressed while clicking the button. and; can I swallow fvwmiconman into fvwmbuttons? I think so. -- Dan Espen
Re: FVWM: Stepping down from next year.
Thomas Adam tho...@fvwm.org writes: Hello all, This is a very quick note to let you all know that as of next year I will be stepping down as the maintainer of FVWM -- largely this role is a very loose one, but since I seem to be the most vocal and more visibally active developer here, I felt it wise to mention this just in case people wonder where I've gone. I do not have the time anymore to devote to this project. As such, I will still be providing ad-hoc bug-fixes, and general advice, but that's about all. I will not be working on any major features. My last batch of work on this will be to complete module deprecation, even if that's stub code. Dominik Vogt and I are completing work on the Git conversion still, which I am pleased about. These will be done by early next year. As soon as that happens, I shall release FVWM 2.6.4 -- after that, well, that's someone else's problem. :) Thanks all. It's been fun. :) This is a thankless job and you are far from the first person to feel burnt out. (I'm guessing.) For my purposes, Fvwm was feature complete after the iconboxes, left menus and window minimizing animation made their appearance. I hope that we'll always have enough interested users to at least keep what's currently working up to date. Thanks for all your efforts. -- Dan Espen
Re: FVWM: Stepping down from next year.
Thomas Funk t.f...@web.de writes: Thanks all. It's been fun. :) No, it's not funny ... it's a tragedy ... Fvwm will loose a big part of it's heart ;( What about the other developers? Dominik, Dan, Jason, ... ? Will the project vanish into thin air? I can't believe it ... Years ago we decided that fvwm workers would run the project. For a long time we had 4 or 5 people committing changes every few days. Since then it's been more of a one person at a time situation. Having a single maintainer is too much of a burden. I've always been surprised that anyone would take on that role. If someone comes to this list with a great new idea and convinces the few of us that hang around that he's qualified he'll get commit privileges and Fvwm get new capabilities. It's pretty hard to work up any ambition when Fvwm already does everything a person wants. (It does for me.) Hopefully we have the mechanisms in place for this project to carry on to serve that niche of users that want total control and don't need GUI's to write configuration files. -- Dan Espen
Re: FVWM: Deprecating certain Fvwm* modules
Harry portobello harryportobe...@gmail.com writes: Hi, On 22 October 2011 11:23, Thomas Adam tho...@fvwm.org wrote: Hello all, This has been a while coming since 2.6.0 was released. But I said at the time that since there was no longer ever going to be a split between stable/unstable, and that there was only ever rolling-stable releases, that there was now never any right time to make changes which have an impact. This is one of them. Is this really the right thing to do? Really? How did you come up with this list of depreciated modules to start with? What happens if someone with a config theyve had for ages needs to use a module youve depreciated? Will you personally have to provide the functions of that module in some way? Can you not just leave these modules alone? Deprecating junk is a time honored Fvwm tradition. Reducing the size of the code base helps developers. As it is, Fvwm has grown so large that I can't keep up with the complexity. Anyway, Tom has done the right thing. He made a proposal and now he's getting feedback. -- Dan Espen
Re: Deprecating certain Fvwm* modules
Thomas Adam tho...@fvwm.org writes: * FvwmCpp This one has to go -- no one that I've seen in the years I've been using FVWM actually has a configuration in CPP anymore. If they do, they've not noticed it's been broken since FVWM 2.3.X, and no one has fixed that. I've been using FvwmCPP for quite a while now. Maybe there is a better way I'm not aware of. I have a series of different Fvwm Themes. I read them like this: Module FvwmCpp -I$FVWM_USERDIR .DecorCurrent The pre-processor statements in the decors are usually testing color depth and sometimes just short cutting: #define BACK 21/B9/FD #define FORE 22/59/E9 DestroyDecor recreate DecorVec AddToDecor DecorVec #if PLANES 9 + TitleStyle Centered ActiveUp (Solid cornflowerblue -- Raised) \\ Inactive (Solid Navy -- Flat) \\ ActiveDown (Solid dimgrey -- Sunk) #else /*edgemid-point center */ + TitleStyle Centered ActiveUp (\\ SGradient 128 2 rgb:BACK 20 rgb:33/33/aa 70 rgb:FORE)\\ Inactive (\\ SGradient 128 2 rgb:BACK 50 rgb:44/44/aa 50 rgb:33/33/77)\\ ActiveDown (\\ SGradient 128 2 rgb:00/77/aa 30 rgb:44/88/aa 70 rgb:88/88/aa) #endif Anyway, if it's broken, I'm not aware of it. -- Dan Espen
Re: FVWM: Style related question
Nikos Leonardos nikos.leonar...@gmail.com writes: G On Tue, Sep 20, 2011 at 08:15:09PM -0400, des...@verizon.net wrote: Perhaps the xboard developers could be persuaded to add a -name or -wmname type option. I don't think I saw a complete list of their X Resources. Perhaps there is something that can be set that way. Thanks Dan! It's funny, but after seeing your reply, I tried # xboard -name myname and the resource of the window was set to myname. I'm not sure this is correct behaviour of xboard (I think -name is supposed to do something else), but it works for now. Any better solutions would be appreciated. I missed it in the docs but perhaps the toolkit they are using supplied it and they weren't aware. Or maybe I just missed it. Anyway using -name is the classical, preferred way to go. I don't think anything else could qualify as better. -- Dan Espen
Re: FVWM: Style related question
Thomas Adam tho...@fvwm.org writes: On Tue, Sep 20, 2011 at 08:31:01PM -0400, Nikos Leonardos wrote: On Tue, Sep 20, 2011 at 08:15:09PM -0400, des...@verizon.net wrote: Perhaps the xboard developers could be persuaded to add a -name or -wmname type option. I don't think I saw a complete list of their X Resources. Perhaps there is something that can be set that way. Thanks Dan! It's funny, but after seeing your reply, I tried # xboard -name myname and the resource of the window was set to myname. I'm not sure this is correct behaviour of xboard (I think -name is supposed to do something else), but it works for now. But again, note my previous email. Per the xboard man page: -wname full name -bname full name -name full name -oppname full name The full name of White, Black, yourself or your opponent. Unfortunately, this is not the option per most other applications to set the name of the window, which is mildly irritating. If this is setting the name of the window to whatever you enter here, that's a coincidence, not intended behaviour. I've patched xboard before. I think I might take a look over the weekend to see how difficult it would be to add this option as I'm surprised it's missing. Tom, I saw those options but they are listed under the cmail program. Still, it could be that -name is meant to be something else and works by coincidence. -- Dan Espen
Re: FVWM: Style related question
Nikos Leonardos nikos.leonar...@gmail.com writes: Hello all-- I run the application xboard in two different modes: (1) to connect to a chess server, and (2) to set up a position. I would like to have a different style for each mode. One way to do that would be to use the fact that the window name is different in each mode. It is xboard in mode (1) and it is xboard: 69.36.243.188 in mode (2). However, this doesn't seem to be entirely true. I think what happens is that initially (at the time the style of the window is determined) the window name _is_ the same. One way around that, is to use (the obsolete command) RecaptureWindow after the window name has changed. I don't like this because of the extra keystrokes I need to do. I would like to do that automatically, say through an fvwm-function that calls xboard and also sets the appropriate style. I tried something like the following, but it didn't work. DestroyFunc FvwmFics AddToFunc FvwmFics + I Exec exec $[TERM] -e /usr/games/bin/xboard -ics -icshost 69.36.243.188 + I Wait xboard: 69.36.243.188 + I All (xboard: 69.36.243.188) WindowStyle NeverFocus, Title + I UpdateStyles Thank you in advance for your time. Perhaps the xboard developers could be persuaded to add a -name or -wmname type option. I don't think I saw a complete list of their X Resources. Perhaps there is something that can be set that way. -- Dan Espen
Re: FVWM: dynamic xdg menus
Victor Ananjevsky anana...@gmail.com writes: Hi, List Please look at program i wrote for creating dynamic xdg menus in fvwm. http://pastebin.com/TmhLRFfp This program creates menus with icons and localized names. Each submenu is a dynamic menu creates with DynamicPopupAction. System icons caches in $XDG_CONFIG_HOME/fvwm, so this path mus be added to fvwm's ImagePath Program runs as fvwmmenu [-s SIZE] [-t TERM] MenuName [/Path/To/Submenu] Parameter '-s' sets the size of cached icons. By default size of icons for menu from gtk settings is used. '-t' sets the command for terminal emulator. By default it is sets to xterm. Terminal command must understand '-e' parameter for launching applications. MenuName is a case-insensitive menu name, for example Applications or Settings. Special menu name Recent create menu for recently opened files. Optional argument /Path/To/Submenu specifies only one submenu to create. For example, command 'fvwmmenu Applications /Development' create only Development menu for Applications. Program requires gtk+ and gnome-menus. Hope it will be useful not only for me. Any comments or suggestions are very appreciated. Won't compile here: home pkg-config --cflags --libs gtk+-2.0 libgnome-menu Package libgnome-menu was not found in the pkg-config search path. Perhaps you should add the directory containing `libgnome-menu.pc' to the PKG_CONFIG_PATH environment variable No package 'libgnome-menu' found Running FC15. Not sure what your version does, I haven't looks closely. Any reason you decided not to use or enhance fvwm-menu-desktop? -- Dan Espen
Re: FVWM: fvwm-menu-desktop doesn't recognize --desktop?
Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com writes: Hello. It's been long, but I've been looking the lists nonetheless. I know that something happened in the menu generation tool(s) lately, but I don't know if it's related to my problem. My fvwm-menu-desktop tool doesn't seem to recognize the --desktop option any longer. The output is as follows: $ fvwm-menu-desktop --desktop kde-sys Unknown option: desktop Nothing else. So, where should I be looking to diagnose this? I use Gentoo and fvwm 2.6.1. fvwm-menu-desktop alone produces no output. After much testing and help from Jesús, we've determined that the reason for the lack of generated menus is the missing script kde-config on Gentoo. His Gentoo system does have kde4-config which works as a substitute. Just create a soft link from kde4-config to kde-config. I'm not happy with fvwm-menu-desktop depending on kde-config and will be looking at making changes to fix this issue. Thanks Jesús! -- Dan Espen
Re: FVWM 2.6.X base theme concept
Derek B. Noonburg der...@foolabs.com writes: On 2011 May 03, Thomas Funk wrote: It looks like you set Border/HandleWidth to 1. This should be standard because borders greater 1 looks so ... so frumpy ;-) I agree that narrow (1-pixel) borders look good, but... I also like being able to resize a window from any edge or corner, and it's really hard to grab a 1-pixel border with the mouse. Is there a good solution for that problem? Many solutions: Key F8 A M Resize Hit Alt F8, then move over the frame to resize with the mouse. Key F2 A 4 Maximize grow grow Hit Window Key F2 and grow into available space Key F1 A M Maximize 0 100 Hit Alt F1 and grow to maximum height. You can also initiate actions from menus, title bars and title bar buttons, single clicks, double clicks, strokes. Personally, I like pixmaps in the window border and prefer a wider border so I can see the beautiful blue marble borders. -- Dan Espen
Re: FVWM: fvwm-menu-desktop doesn't recognize --desktop?
Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com writes:
El día 30 de abril de 2011 00:23, Thomas Adam tho...@fvwm.org escribió:
Did you checkout branch-2_6? Only it works fine for me.
That was the problem, but it still doesn't work.
$ grep XDG bin/fvwm-menu-desktop
my $xdg_data_dirs = $ENV{XDG_DATA_DIRS} || '';
my $xdg_config_dirs = $ENV{XDG_CONFIG_DIRS} || '';
my $xdg_menu_prefix = $ENV{XDG_MENU_PREFIX} || '';
Okay, now you have the right version.
$ bin/fvwm-menu-desktop
DestroyMenu FvwmMenu
AddToMenu FvwmMenu Aplicaciones Title
Since you don't have an /etc/xdg/menus/applications.menu
file, this is not expected to work.
$ XDG_MENU_PREFIX=kde- bin/fvwm-menu-desktop
Looks like you don't have an /etc/xdg/menus/kde-applications.menu
file. I don't either, but I do have a
/etc/xdg/menus/kde4-applications.menu
file.
$ XDG_MENU_PREFIX=gnome- bin/fvwm-menu-desktop
DestroyMenu FvwmMenu
AddToMenu FvwmMenu Aplicaciones Title
Looks like you don't have a
/etc/xdg/menus/gnome-applications.menu
file. Neither do I.
$ XDG_MENU_PREFIX=kde- bin/fvwm-menu-desktop --verbose
...
ERROR: Can't find root menu file.
To be expected.
$ XDG_MENU_PREFIX=gnome- bin/fvwm-menu-desktop --verbose
DEBUG: root menu is /etc/xdg/menus/gnome-applications.menu
Hmm, looks like you actually do have an gnome-applications.menu.
Read desktop entry, opening file /usr/share/gnome/apps/amdcccle.desktop.
Read desktop entry, opening file /usr/share/gnome/apps/amdccclesu.desktop.
/usr/share/desktop-directories/kde-development-translation.directory.
/usr/share/desktop-directories/kde-edu-miscellaneous.directory.
/usr/share/desktop-directories/kde-edu-science.directory.
/usr/share/desktop-directories/kde-information.directory.
/usr/share/desktop-directories/kde-graphics.directory.
/usr/share/desktop-directories/kde-edu-mathematics.directory.
/usr/share/desktop-directories/kde-system.directory.
/usr/share/desktop-directories/kde-utilities-pim.directory.
/usr/share/desktop-directories/kde-development-webdevelopment.directory.
/usr/share/desktop-directories/kde-edu-tools.directory.
/usr/share/desktop-directories/X-GNOME-Menu-Applications.directory.
/usr/share/desktop-directories/Network.directory.
/usr/share/desktop-directories/kde-utilities-file.directory.
/usr/share/desktop-directories/Personal.directory.
/usr/share/desktop-directories/kde-science.directory.
/usr/share/desktop-directories/kde-utilities-accessibility.directory.
/usr/share/desktop-directories/kde-games-kids.directory.
/usr/share/desktop-directories/AudioVideo.directory.
/usr/share/desktop-directories/kde-more.directory.
/usr/share/desktop-directories/kde-multimedia.directory.
/usr/share/desktop-directories/kde-utilities.directory.
/usr/share/desktop-directories/kde-utilities-peripherals.directory.
/usr/share/desktop-directories/Utility-Accessibility.directory.
/usr/share/desktop-directories/Utility.directory.
/usr/share/desktop-directories/kde-games-card.directory.
/usr/share/desktop-directories/kde-games-roguelikes.directory.
/usr/share/desktop-directories/kde-settingsmenu.directory.
/usr/share/desktop-directories/kde-games-strategy.directory.
/usr/share/desktop-directories/kde-office.directory.
/usr/share/desktop-directories/kde-internet.directory.
/usr/share/desktop-directories/X-GNOME-Menu-System.directory.
/usr/share/desktop-directories/kde-games-arcade.directory.
/usr/share/desktop-directories/kde-utilities-xutils.directory.
/usr/share/desktop-directories/kde-development.directory.
/usr/share/desktop-directories/Game.directory.
/usr/share/desktop-directories/kde-internet-terminal.directory.
/usr/share/desktop-directories/Settings-System.directory.
/usr/share/desktop-directories/Office.directory.
/usr/share/desktop-directories/kde-games.directory.
/usr/share/desktop-directories/kde-games-logic.directory.
/usr/share/desktop-directories/kde-system-terminal.directory.
/usr/share/desktop-directories/kde-utilities-desktop.directory.
/usr/share/desktop-directories/kde-main.directory.
/usr/share/desktop-directories/LookAndFeel.directory.
/usr/share/desktop-directories/System-Tools.directory.
/usr/share/desktop-directories/Hardware.directory.
/usr/share/desktop-directories/System.directory.
/usr/share/desktop-directories/kde-toys.directory.
/usr/share/desktop-directories/Education.directory.
/usr/share/desktop-directories/kde-education.directory.
/usr/share/desktop-directories/Settings.directory.
/usr/share/desktop-directories/kde-games-board.directory.
/usr/share/desktop-directories/kde-edu-languages.directory.
/usr/share/desktop-directories/Graphics.directory.
/usr/share/desktop-directories/InternetAndNetwork.directory.
/usr/share/desktop-directories/Development.directory.
/usr/share/desktop-directories/kde-unknown.directory.
/usr/share/desktop-directories/kde-editors.directory.
/usr/share/desktop-directories/X-GNOME-Other.directory.
DestroyMenu FvwmMenu
AddToMenu
Re: FVWM 2.6.X base theme concept
Rooster Cogburn rstrcogb...@gmail.com writes: Out of request by a developer here. I've been interested to have fun and give back to the FVWM community with concepts for the default theme. I feel that this can be vectorized properly with built in functionality and maintain it's current look using base X11 fonts like fixed-9. http://dl.dropbox.com/u/17828753/inclusions/inclusions-fvwm.png Some the ideas in involved with this mock up which I'm converting into a real theme as we speak are per the following. Clean lines and neutral colors. Modern asthetics felt similarly in kde oxygen, gnome clearlooks, gnome elementary, and MacOSX themes. There is a careful consideration on not to small to be unusable but also not to big to look old school. Still 3d in the context of modern asthetics to cater to the MWM lovers. Hope my contribution gets the creative juices flowing on this topic if nothing else. I'm guessing that's the Inactive scheme? Looking at Clearlooks, it looks like the ActiveUp titlebar is blue? I'm not sure if ActiveDown has it's own settings. It looks like you set Border/HandleWidth to 1. I'm not sure what the 4 buttons do. I sort of like the gradient. It's almost invisible.
Re: FVWM: fvwm-menu-desktop doesn't recognize --desktop?
Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com writes: Hello. It's been long, but I've been looking the lists nonetheless. I know that something happened in the menu generation tool(s) lately, but I don't know if it's related to my problem. My fvwm-menu-desktop tool doesn't seem to recognize the --desktop option any longer. The output is as follows: $ fvwm-menu-desktop --desktop kde-sys Unknown option: desktop Nothing else. So, where should I be looking to diagnose this? I use Gentoo and fvwm 2.6.1. fvwm-menu-desktop alone produces no output. Thanks beforehand. Is this a relatively recent Gentoo? I looked around and there really should be an applications.menu available. The solution I gave, using lxde-applications should work but I'm reluctant to add that change to Fvwm. The change should be on the Gentoo end unless I can be convinced otherwise.
Re: FVWM: fvwm-menu-desktop doesn't recognize --desktop?
Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com writes: 2011/4/29 des...@verizon.net: The change I committed a day or 2 ago uses XDG_MENU_PREFIX. I am trying but it doesn't seem to work. [Jesus-PC] i92guboj@Jesus-PC:~/tmp/fvwm [Jesus-PC] 23:58:41 $ ls /etc/xdg/menus/ gnome-applications.menu kde-4.6-applications.menu kde-information.menu settings.menu [Jesus-PC] i92guboj@Jesus-PC:~/tmp/fvwm [Jesus-PC] 00:00:15 $ XDG_MENU_PREFIX=gnome- bin/fvwm-menu-desktop ERROR: Can't find root menu file. [Jesus-PC] i92guboj@Jesus-PC:~/tmp/fvwm [Jesus-PC] 00:00:38 $ bin/fvwm-menu-desktop ERROR: Can't find root menu file. If I ln -s the applications.menu file, now it seems to do something. [Jesus-PC] i92guboj@Jesus-PC:~/tmp/fvwm [Jesus-PC] 00:00:44 $ bin/fvwm-menu-desktop DestroyMenu FvwmMenu AddToMenu FvwmMenu Aplicaciones Title Unfortunately the menu is empty. In any case, it seems that the tool still ignore the XDG_MENU_PREFIX variable. Am I missing something here? Do: grep XDG_MENU_PREFIX bin/fvwm-menu-desktop
Re: CVS tadam: Remove hard-coded #! line from fvwm-menu-desktop
c...@math.uh.edu writes: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: tadam 11/04/29 07:05:50 Modified files: bin: Tag: branch-2_6 ChangeLog fvwm-menu-desktop.in Log message: Remove hard-coded #! line from fvwm-menu-desktop @PERL@ always interpolates out to the correct interpreter. Yeah, I know. I stuck that in there for testing purposes. (Yep I sometimes test before commit. :) ) I simply forgot to remove it. If you notice I stick my test line at the bottom of the file for Emacs: # Local Variables: # mode: cperl # compile-command: perl fvwm-menu-desktop.in --enable-mini-icons --fvwm-icons # End: So, at first I thought if I fed the file to the perl interpreter nothing would get in the way and I could test the file directly. But I get: perl fvwm-menu-desktop.in --enable-mini-icons --fvwm-icons Can't exec @PERL@ at fvwm-menu-desktop.in line 1. Just reviewed man perlrun. If there's a solution, it isn't obvious to me. Anyway, thanks.
Re: FVWM: fvwm-menu-desktop doesn't recognize --desktop?
Thomas Adam tho...@fvwm.org writes: On Tue, Apr 26, 2011 at 09:31:02PM -0400, des...@verizon.net wrote: Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com writes: $ ls /etc/xdg/menus/ kde-4.6-applications.menu kde-information.menu lxde-applications.menu I can send you the files if you need to take a look inside. Yes, send me lxde-applications.menu. It's the only one of those that I don't have. I think kde-4.6-applications would serve as a main menu, but obviously, a name like that is a moving target. Can't we just glob() for these or do a readdir() on these? No, you're on the wrong track. All that needs changing is the identifier for the root menu. This code: my @menu_bases = (qw( applications debian-menu ) ); Just add lxde-applications to that list like this: my @menu_bases = (qw( lxde-applications applications debian-menu ) ); and you'll be in business. But none of this makes sense to me. The code we are using came from arch-linux. I'll see if I can figure out what they've been up to.
Re: FVWM: fvwm-menu-desktop doesn't recognize --desktop?
Nathaniel H. Stickney nstick...@gmail.com writes: Also check to see if you have XDG_CONFIG_DIRS set to some value. In a terminal: echo $XDG_CONFIG_DIRS $ echo $XDG_CONFIG_DIRS Ah, I should have asked what's in: $XDG_MENU_PREFIX
Re: FVWM: fvwm-menu-desktop doesn't recognize --desktop?
Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com writes: Hello. It's been long, but I've been looking the lists nonetheless. I know that something happened in the menu generation tool(s) lately, but I don't know if it's related to my problem. My fvwm-menu-desktop tool doesn't seem to recognize the --desktop option any longer. The output is as follows: $ fvwm-menu-desktop --desktop kde-sys Unknown option: desktop It was my intent to support all the old options, even if all the script did was ignore them. Looks like I missed this one. I'll fix it, maybe not right away though.
Re: FVWM: fvwm-menu-desktop doesn't recognize --desktop?
Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com writes: El día 27 de abril de 2011 01:12, Thomas Adam tho...@fvwm.org escribió: On Wed, Apr 27, 2011 at 01:03:37AM +0200, Jesús J. Guerrero Botella wrote: And on Gentoo, do you have any XDG menuing software installed? (However Gentoo defines that?) Well, I have a package called xdg-utils, kde is also installed so I'd hope xdg to work ok. Is there any concrete xdg tool that fvwm-menu-desktop depends upon? The current code will look for both KDE and GNOME definitions, so the option is meaningless to you. That said, if fvwm-menu-desktop is producing no output without supplied options then: * You have no XDG menuing software installed; * The code assumes a path (as defined in the XDG spec) and Gentoo puts it someplace else. I will investigate, it's probably the later, but that will be for tomorrow. Is there really nothing on STDERR when you run this? Were get_root_menu() to fail to find a menu, I would expect to see something. Especially since that's even without the verbose flag set -- something you could also try doing. All the output is the one I pasted above. Nothing else. With verbosity enabled I get something more: $ fvwm-menu-desktop --verbose DEBUG: foreach fvwm_app. ... desktop dirs /usr/share/desktop-directories KDE legacy dirs DEBUG: root menu is DEBUG: charset is UTF-8. DEBUG: language is es_ES.utf8. DEBUG: root-cmd is kdesu. at /usr/bin/fvwm-menu-desktop line 218. ERROR: Can't find root menu file. Yep, tell us what is in /etc/xdg/menus/. There should be a applications.menu or debian-menu.menu file.
Re: FVWM: fvwm-menu-desktop doesn't recognize --desktop?
Jesús J. Guerrero Botella jesus.guerrero.bote...@gmail.com writes: $ ls /etc/xdg/menus/ kde-4.6-applications.menu kde-information.menu lxde-applications.menu I can send you the files if you need to take a look inside. Yes, send me lxde-applications.menu. It's the only one of those that I don't have. I think kde-4.6-applications would serve as a main menu, but obviously, a name like that is a moving target. Also check to see if you have XDG_CONFIG_DIRS set to some value. In a terminal: echo $XDG_CONFIG_DIRS You can send the file and other stuff directly to me. If there is something that needs sharing, I'll take care of it. Thanks.
Re: Scrap Docbook in favour of Asciidoc?
Thomas Adam tho...@fvwm.org writes: Hi all, At the moment though we have a lot man pages which still require raw *roff format to be used (such as those in modules/Fvwm* -- and bringing these in to line with using Asciidoc seems like a good idea as well. ... [1] http://www.methods.co.nz/asciidoc/ Wow, cool. It's yet another documentation language but it looks like they go to pains to make the markup as invisible as possible. I think that might even make Dominik happy.
Re: A couple of questions from a Newbie.
Lars Segerlund lars.segerl...@gmail.com writes: Hello , I am trying to build a module using the composite extension of X, mainly xcompmgr functionality for now ... is anyone else interested or have some opinions ? views ? I have a good idéa of the X part, but I have never written a fvwm module before, so any hints are welcome especially if anyone have some problems they can foresee . Also would 2.6.1 or 2.7.x be the correct branch to use ? 2.6.1. The complete documentation for the module interface is here: http://fvwm.org/documentation/dev_modules.php IMO, the best module to use as an example is FvwmAnimate. What can xcompmgr do for Fvwm?
Re: fvwm-2.6.0 bug(?)
Sergey Vlasov v...@altlinux.ru writes: On Mon, 18 Apr 2011 13:46:22 -0400 des...@verizon.net wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Apr 18, 2011 at 02:14:38PM -0300, Jim Diamond wrote: I am running fvwm 2.6.0 on Slackware64 13.1. When it starts up it (apparently) runs fvwm-menu-desktop, which sends out the following complaints: -- WARNING: '/etc/kde/xdg/menus/applications-kmenuedit.menu' does not exist Unknown 'DefaultLayout': ... I think it's a bug in the kde config files. Actually DefaultLayout and Layout are valid freedesktop menu tags, but they are not implemented in fvwm-menu-desktop. These tags are optional, but should be ignored silently instead of printing such debug output. Ah, sorry. I should have said I think the first line is a bug in the kde config files. (The message about kmenuedit.) I've committed fixes for the Layout and DefaultLayout elements. If anyone has a system they can test this on, it would be nice to get some feedback. Just run fvwm-menu-desktop. From the command line is okay and look for error messages.
Re: fvwm-2.6.0 bug(?)
Thomas Adam tho...@fvwm.org writes: On Mon, Apr 18, 2011 at 02:14:38PM -0300, Jim Diamond wrote: I am running fvwm 2.6.0 on Slackware64 13.1. When it starts up it (apparently) runs fvwm-menu-desktop, which sends out the following complaints: -- WARNING: '/etc/kde/xdg/menus/applications-kmenuedit.menu' does not exist Unknown 'DefaultLayout': ' DestroyMenu FvwmMenu AddToMenu FvwmMenu KDE Menu Title -- I don't see anything in my configuration which is asking fvwm to call this program. Should I be getting this without asking for it, or am I doing something wrong. (If the latter, my apologies for the noise.) It's coming from fvwm-menu-desktop which is called from fvwm.c in liey of no config found, *or* your config doesn't override the builtin menu. There's no way to override the creation of the built in menu. There probably should be. Is there a way to defer creation of the menu until it is invoked? I am not too surprised to see the above, but I don't have the environment installed to reproduce it, as that would mean KDE being installed. The error comes from interpret_menu() -- which it will then spit out the above as a last resort. Probably nothing to worry about, it's just this script is perhaps overly chatty. I think it's a bug in the kde config files. We should probably change the menu generation code to be quiet about it unless a debug or verbose flag is on. I can do that if you like...
Re: fvwm-2.6.0 bug(?)
Thomas Adam tho...@fvwm.org writes: On Mon, Apr 18, 2011 at 01:46:22PM -0400, des...@verizon.net wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Apr 18, 2011 at 02:14:38PM -0300, Jim Diamond wrote: Is there a way to defer creation of the menu until it is invoked? Yes -- this is what MissingSubMenuFunction is for. Aha! No wonder I couldn't find it. IMO, it's not really documented. All the man page has is examples. That keyword is used in place of a menu-name and triggers a special function. Thanks Hope to get some of this done tonight.
Re: fvwm-2.6.0 bug(?)
Thomas Adam tho...@fvwm.org writes: Hi, On 19 April 2011 02:50, des...@verizon.net wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Apr 18, 2011 at 01:46:22PM -0400, des...@verizon.net wrote: Thomas Adam tho...@fvwm.org writes: On Mon, Apr 18, 2011 at 02:14:38PM -0300, Jim Diamond wrote: Is there a way to defer creation of the menu until it is invoked? Yes -- this is what MissingSubMenuFunction is for. Aha! No wonder I couldn't find it. IMO, it's not really documented. All the man page has is examples. I'll add it to my TODO list. :) Didn't mean to put this on you, just seeking comments. That keyword is used in place of a menu-name and triggers a special function. Thanks Hope to get some of this done tonight. There's no rush. :) It's not like we're about to release a stable version or anything. :) stable ≠ perfect :) I'm not seeing email on the fix for delayed menu building. I don't think I'll deal with the warning/error message until tomorrow. Getting late.
Re: TODO for 2.6.1
Thomas Adam tho...@fvwm.org writes: On Sat, Apr 16, 2011 at 11:18:16AM -0400, des...@verizon.net wrote: Creating a branch is much further down the page. I see that now I'm reading two different files, thanks. I've issued the right command, but now all I get is spurious messages: [n6tadam@debian][fvwm-2.6.0][fvwm]% cvs rtag -b -r version-2_6_0 branch-2_6 . cvs rtag: [15:32:06] waiting for cvs's lock in /home/cvs/fvwm/fvwm-web/pictures/decorations/window_deco_ice cvs rtag: [15:32:36] waiting for cvs's lock in /home/cvs/fvwm/fvwm-web/pictures/decorations/window_deco_ice cvs rtag: [15:33:06] waiting for cvs's lock in /home/cvs/fvwm/fvwm-web/pictures/decorations/window_deco_ice cvs rtag: [15:33:36] waiting for cvs's lock in /home/cvs/fvwm/fvwm-web/pictures/decorations/window_deco_ice cvs rtag: [15:34:06] waiting for cvs's lock in /home/cvs/fvwm/fvwm-web/pictures/decorations/window_deco_ice I do not know how long such a command as issued should take, or whether the above output about locking is preventing the command from running, but so far it's been ten minutes, with the same message above being printed out periodically. Something for Jason to investigate? I seem to recall having similar locking problems before when I tried creating a CVS branch in FVWM's repository. Yep, according to this page: http://tinyurl.com/ytdv54 something didn't complete in fvwm-web. Maybe that's why I couldn't find the pictures you uploaded. Looks like we do need help on the server.
Re: Release announcement
Thomas Adam tho...@fvwm.org writes: On Tue, Apr 12, 2011 at 12:34:48AM +0100, Thomas Adam wrote: On Mon, Apr 11, 2011 at 10:35:41PM +0100, Thomas Adam wrote: On Mon, Apr 11, 2011 at 10:00:39PM +0100, Thomas Adam wrote: On Mon, Apr 11, 2011 at 09:40:52PM +0100, Thomas Adam wrote: If anyone feels like somethings should be added/removed/augmented, let me know. More updates -- but the whole document this time -- mostly from authors I've forgotten about, so please, keep your updates coming. I appreciate it: Another update: Unless anyone says so, I'm releasing this tomorrow evening at some point. Just want to say the release announcement is excellent. Nice job.
Re: FVWM: 2.6.0 release candidates?
Thomas Adam tho...@fvwm.org writes: On Sun, Apr 10, 2011 at 02:20:24PM -0400, des...@verizon.net wrote: Thomas Adam tho...@fvwm.org writes: On Sun, Apr 10, 2011 at 12:06:33PM -0400, des...@verizon.net wrote: Thomas Adam tho...@fvwm.org writes: Agreed -- it should only mean a change to SetRCDefaults() -- can you do this, please? Would you mind? I love when things go smoothly. This is not one of those times. I haven't updated in a while so I updated, made changes and restarted. Now my fonts have stopped working: I have this: MenuStyle * Font xft:Sans:bold:antialias=False:pixelsize=15, Animation, Hilight3DThin And I get this messages: [fvwm][FlocaleLoadFont]: WARNING -- can't load font 'xft:Sans:bold:antialias=False:pixelsize=15', trying default: -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-*-*,-*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*,-*-*-medium-r-normal-*-16-*-*-*-*-*-*-* Can't tell if it's a problem on my end or not. It was my own f*** up. Can you cvs up and see if that solves it for you? Yes, fixed now. I still get this warning: [fvwm][FlocaleGetFontSet]: (9x15bold) Missing font charsets: ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, KOI8-R, ISO8859-7, ISO8859-9, ISO8859-13, ISO8859-14, ISO8859-15, JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1 from MenuStyle StartMenu Greyed navy, font 9x15bold, TrianglesRelief I don't think it's new, but while we are on the subject...
Re: 2.6.0 release candidates?
Thomas Adam tho...@fvwm.org writes: Hello all, I'd like to propose that we start building 2.6.0 release candidate tarballs. As far as I know, the only major part left of FVWM was a fvwm-menu-desktop replacement which Dan Espen (and tentatively myself) worked on over Christmas. Can someone please give me an update as to the status of this -- i.e., anyone actually using it in earnest? I'm still unsure as to how complete it is on systems I don't have. Looking at docs/todo-2.6, under A. Release stopping bugs, I have no intention of looking at any of those for 2.6.0. F.3 is the one which interests me more. We really need to start being more pragmatic about making 2.6.0 a reality; my git tree [1] has a bunch of patches which I've written, but can't merge into FVWM because we're in a feature freeze, so the sooner this goes out the door, the better. Obviously though we cannot be too complacement, but I really don't think there's anything seriously stopping us releasing FVWM CVS at this point as potential 2.6.0 release candidates. Someone just has to have the balls to do it. That'd be me. :) If there's nothing major blocking fvwm-menu-desktop, I would like to suggest I go ahead and do this. For fvwm-menu-desktop is see 2 issues: 1. The Fvwm built in menu should invoke fvwm-menu-desktop. I don't know if we can make this conditional on being on Linux, but I don't think it would be a major problem if it was there all the time. This should be addressed before 2.6. 2. We don't have a working option that would use the application specific mini-icons for each menu item. I don't see this as important, just nice to have. This should not interfere with releasing 2.6. Other than that, I see no reason not to release 2.6.
Re: 2.6.0 release candidates?
Thomas Adam tho...@fvwm.org writes: On Sun, Apr 10, 2011 at 12:06:33PM -0400, des...@verizon.net wrote: Thomas Adam tho...@fvwm.org writes: Agreed -- it should only mean a change to SetRCDefaults() -- can you do this, please? Would you mind? I love when things go smoothly. This is not one of those times. I haven't updated in a while so I updated, made changes and restarted. Now my fonts have stopped working: I have this: MenuStyle * Font xft:Sans:bold:antialias=False:pixelsize=15, Animation, Hilight3DThin And I get this messages: [fvwm][FlocaleLoadFont]: WARNING -- can't load font 'xft:Sans:bold:antialias=False:pixelsize=15', trying default: -*-fixed-medium-r-semicondensed-*-13-*-*-*-*-*-*-*,-*-fixed-medium-r-normal-*-14-*-*-*-*-*-*-*,-*-*-medium-r-normal-*-16-*-*-*-*-*-*-* Can't tell if it's a problem on my end or not. Also fvwm-menu-desktop stopped working. Of course, I'll debug that but it might take a little while.
Re: 2.6.0 release candidates?
Thomas Adam tho...@fvwm.org writes: Did this thing ever work for you? I just found a about 15 lines of code missing. It could not work without it.
Re: PATCH: lost window patch
Thomas Adam tho...@xteddy.org writes: On 1 March 2011 14:41, Rich Coe r...@wi.rr.com wrote: The code as it stands now is wrong. It wrongly deletes events from the event queue in a mistaken attempt to fix something. It then leaves the application in a unusable state. I've not looked into this at all, as I'm at work, but I might get round to it at the weekend. If you have a failing Qt test case, please send it to me or a pointer to it. I couldn't find it when I was researching this problem. I'm able to track it down by myself. This is fvwm_workers. = If we have any test cases it would also be good to commit them to the tests directory. I'm not sure I remember any Qt test case but I just developed a medium size Qt application using PyQT4 so I'd recommend Python for setting up a test case.
Re: CVS tadam: Start of perl style cleanup to fvwm-menu-desktop
Thomas Adam tho...@fvwm.org writes: On Mon, Dec 27, 2010 at 08:17:01PM -0500, des...@verizon.net wrote: c...@math.uh.edu writes: Log message: Start of perl style cleanup to fvwm-menu-desktop Tentative leap into cleaning this script up. Hi, Hello, That worked pretty well. I've been working on creating an FvwmForm that prompts for new command line arguments and invoking FvwmForm instead of fvwm-menu-desktop when regenerate menus is selected. I updated and got a few conflicts, but they were easily resolved. How far through that are you? I've a tonne of other cleanups and what have you but don't want to cause you a massive headache with resolving conflicts; and it would be easier for me to fix those up this end. Go ahead. I checked in what I have. I'll lay off for a few days. The cleanups are nice. I have a bunch of basic function issues which I've listed at the front of the file.
Re: CVS tadam: Start of perl style cleanup to fvwm-menu-desktop
Thomas Adam tho...@xteddy.org writes:
On Tue, Dec 28, 2010 at 11:20:30AM -0500, des...@verizon.net wrote:
Go ahead. I checked in what I have.
I'll lay off for a few days.
Well, I've made a lot of changes -- I'd be grateful if you'd have a look and
ensure I've not botched any CVS conflicts which I had to resolve -- it seems
to work for me, but I might not be testing the same areas as you.
I found the easiest way to resolve conflicts is first determine if I
liked the committed code. If so, just delete the whole block.
Then update again.
The cleanups are nice.
I have a bunch of basic function issues which I've listed at the
front of the file.
I'll get to those in a bit. I am more interested in cleaning up what's
currently there, as a lot of the inherited xdg-menu code from the SuSE
people is nothing short of abysmal to be frank.
However, the things to take away from my latest commit are:
* Reindented the entire file by hand (because Vim did a piss-poor job) so
that the following rules hold true:
- Braces are on a line of their own for all block construct, so for
instance:
Yeah, well, I don't like that, but others do so I guess I have no
choice. I'm outvoted it seems.
It seems to me pretty dumb to waste vertical space like that.
if (...)
{
} else {
}
Should be written as:
if (...)
{
}
else
{
}
Yep, 3 lines:
if (...) {
} else {
}
to 6, but I'm pretty lonely in my camp.
Seems other people like to see things line up,
but they don't line up to me.
Anyway, if you download perltidy and give it the right
options, it's deal with most of that.
* In-line logic conditions (if/unless, etc) like this:
foo($bar) unless $baz;
Lots of that, and I think it's all backwards.
if ( ! $baz ) {
foo($bar);
}
Now I'll concentrate on removing the hideous amount of duplication we have
between subroutines, refactoring those, and making the code less unwieldy.
:)
Go for it and don't pay attention to my rants about style.
I have my preferences but I'll live with majority opinion.
Re: Fvwm Menu Directory
Thomas Adam tho...@fvwm.org writes: Hi, On Fri, Dec 24, 2010 at 12:31:37PM -0500, des...@verizon.net wrote: I'm getting near completion on the fvwm-menu-desktop rewrite. I thought I'd solicit some comments. Thanks, Dan. It looks good. Comments in-lined below. I tried it, seems to work OK so far. :) ... But that's not your fault -- it was like that in the original code. It just looks nasty to me. :) I appreciate most of the comments above might not relate to the work you've done, so don't think I'm picking holes unnecessarily. On the contrary, I really appreciate this, it's looking good. But it's these smaller nits that might get over-looked otherwise. Great comments, thanks! I didn't have an opinion about the prototypes but the way the whole thing is organized upside down to use them bothers me. The she-bang line needs to be changed to fvwm standard #...@perl@, it's just the way it is for testing. Same with version number. Ideally, I'd love it if this could go in CVS so it can be worked on collaboratively. I don't plan on releasing the CVS version anytime soon. I was hoping to hear it worked for at least one other person before I did that. I'll get to a commit soon.
Re: FVWM: interference firefox/acroread and fvwm on suse 11.3
Lucio Chiappetti lu...@lambrate.inaf.it writes: I am noting a funny (and sort of annoying behaviour) when using firefox and acrobat reader in a fvmw session under suse 11.3 (newly installed). The topmost menu bar (File Edit ...) has white text onto black background, although I do not have any X resource in .Xdefaults which makes that. The same colour applies to all pull down menus, and for acrobat also to the bookmark window. That's not x-resources, the desktop environments stopped using them. They set their preferences in config files. Look for a .kde, .gnome, .gnome2 file or something like that. Or you could bring up your distros desktop settings dialog and change it there.
Re: FVWM: partial update Re: interference firefox/acroread and fvwm on suse 11.3
Robert Heller hel...@deepsoft.com writes: At Fri, 17 Dec 2010 16:12:52 +0100 (CET) Lucio Chiappetti lu...@lambrate.inaf.it wrote: On Fri, 17 Dec 2010, Lucio Chiappetti wrote: I am noting a funny (and sort of annoying behaviour) when using firefox and acrobat reader in a fvmw session under suse 11.3 (newly installed). Apparently also openoffice is showing the same behaviour. The topmost menu bar (File Edit ...) has white text onto black background, The remaining menu bars and widget are normal (black on light grey). For firefox there is a partial workaround. I always hated themes but I found a sort of lightweight themes called personas. If one goes to the site where one can load them, one can also test them. They appear to replace the menu bar and other bars with some pictured background. My workaround was to choose a persona called simple fox (useless to say, no picture, just solid gray :-)). This makes me think that all those applications are NOT using a specific fg/bg colour for the top menu bar, but leaving it somehow transparent letting some w.m. default shining through. I suppose in KDE what shines through is determined by the default KDE theme ... how could I set a similar super-default in fvwm ? a plain *background: and *foreground: in .Xdefaults is no good. To make FireFox (and other GNome-flavored applications) 'play nice' with FVWM, I fire up a minimal bit of GNome: /usr/libexec/gnome-settings-daemon. By firing this up with a properly setup ~/.gconfmumble directory/files, I can get FireFox to be set up with the proper Gnome 'theme' (I created a minimual theme that suited). (I actually use a 'session manager' I wrote in Tcl/Tk -- the session manager fires up fvwm and the gnome-settings-daemon.) Recently I posted how to start that daemon and some other things from a .xinitrc. Start the .xinitrc like this: if [ -f /usr/bin/ck-xinit-session ] ; then if [ $1 = startsess ] ; then shift else exec ck-xinit-session /home/dane/.xinitrc startsess fi fi If you start using the KDE or Gnome login manager, you don't need to do this. As far as fvwm and gnome and kde getting along, they get along just fine. Just start up your distros preferences dialog. For Fedora, it's gnome-control-center. Then select appearance, and select a theme. Works for me.
Re: FVWM: partial update Re: interference firefox/acroread and fvwm on suse 11.3
Thomas Adam tho...@xteddy.org writes: On 17 December 2010 17:00, Lucio Chiappetti lu...@lambrate.inaf.it wrote: Or will Thomas Adam have a simpler workaround at .fvwmrc level if this diagnosis makes sense to him ? Thomas Adam says it's still not an FVWM problem. :) Agree 100%. I notice that the various settings dialogs don't show up in the new version of fvwm-menu-desktop I'm working on. At some point I'll try to figure out why.
Re: FVWM: compiling with gnome support problem
Jamie ja...@griffin.gnix.co.uk writes: i've been compiling the latest devel release of fvwm2 and despite having gnome and its libraries installed the configure script does not find them. perhaps i need to add an option to configure to point it to those libraries but i'm not sure as the INSTALL INSTALL.fvwm files do not say. After running configure, the relevent line reads this: With GNOME libs support in FvwmGtk? no: Can't find working gnome-config i'm sure i must be missing something simple, just wondering if anyone can give me some help. FvwmGtk uses GTK1. You are unlikely to find a working version of GTK1. You can build and use Fvwm without a working FvwmGtk. So far, no one has expressed an interest in bringing FvwmGtk up to date.
Re: FVWM: libstroke with fvwm
Jamie ja...@griffin.gnix.co.uk writes: hi i thought i'd try out the mouse gestures feature i read about when looking on the net, etc and compiled libstroke-0.5.1. i recompiled fvwm and it picked up the libstroke library; however, when i start the wm it exits and the error says it's libstroke can't open shared libraries. does this mean that libstroke needs other dependencies that aren't on my system? does anyone have a set-up with fvwm that uses this and who might know what i need to do? Always post the exact message you got. also is it worth it :-). Never used libstroke myself, too afraid some random mouse movement will do something I don't want.
Re: FVWM: fvwm on suse 11.3
Lucio Chiappetti lu...@lambrate.inaf.it writes: I've just switched on a new machine with suse 11.3. Apparently it has bundled fvwm 2.5.26. I'm getting some errors using my old .fvwm2rc (happily running on suse 9.2 with fvwm 2.5.10). E.g. no pager, no desktops etc. I suspect some paths have changed. First thing to check, make sure you are NOT setting ModulePath in your config file. Before I look into it directly, I created a fresh dummy user, and started a fvwm session from scratch. That comes out with some default theme, but does not create any .fvwm2rc (or config, as I realize it should now be called based on the man page). So I suspect it uses some system default. It uses the built in default, which is not much, but you should be able to press F1, get a menu and create a config from there. If you liked what you had in your previous config file, it should not be that hard to correct any problems you have in there and continue using it.
Re: FVWM: Documentation
Jason Timrod jtim...@yahoo.com writes: Hi everyone! I notice that there's only the man page for fvwm and some unofficial tutorial. Are they any plans to improve the documentation of fvwm? the man page is huge, and it does explain every option but not always how to use it. this makes learning fvwm difficult. When you start Fvwm with no configuration file, press F1. A menu should appear. You will find 2 Setup options. Pick the one you like. This creates a simple, commented starter configuration that will get you going.
Re: FVWM: Documentation
Jason Timrod jtim...@yahoo.com writes: --- On Sat, 12/4/10, des...@verizon.net des...@verizon.net wrote: To configure fvwm you must edit a configuration file. The comments in the starting configuration file should guide you. For example, search for the offending pink color and change it to a shade of blue. Maybe, my favorite, cornflowerblue. Yes, thanks. I can see how to do this. I appreciate what you're asking of me, Dan, but I don't want to lose sight of what my original question is - of documentation. The man page is large because fvwm is large. Also, if this default theme is tied to this, even a little bit, why does it still look like its from 1994? Yes it does look like Motif. I just committed a change to fix the color. I'm willing to make more changes but I need suggestions. I feel my own personal configuration wouldn't be widely appreciated: http://fvwm.org/screenshots/desktops/Dan-desk-1280x1024/screenshot.gif
Re: physical screen boundaries
Jason Weber baboon.im...@gmail.com writes: How would a module determine the boundaries between physical screens? EdgeMoveResistance snapping seems to know about it, so the data is in there somewhere. For example, if I have two monitors 1600x1200 and 1920x1200, querying X11 about the screen dimensions seems to give me the full 3520x1200. I'd like to know about the implicit barrier at x=1600. Perhaps $[vp.width]/$[vp.height] will work. I'm only using one monitor. Thomas, I notice there is no fvwm2 man page for the unstable branch. I may get time to look but not right now.
Re: physical screen boundaries
Thomas Adam tho...@xteddy.org writes: On Fri, Oct 08, 2010 at 01:33:56PM -0400, des...@verizon.net wrote: Jason Weber baboon.im...@gmail.com writes: How would a module determine the boundaries between physical screens? EdgeMoveResistance snapping seems to know about it, so the data is in there somewhere. For example, if I have two monitors 1600x1200 and 1920x1200, querying X11 about the screen dimensions seems to give me the full 3520x1200. I'd like to know about the implicit barrier at x=1600. Perhaps $[vp.width]/$[vp.height] will work. I'm only using one monitor. Thomas, I notice there is no fvwm2 man page for the unstable branch. I may get time to look but not right now. Err, do you mean on the website or built as part of ./configure make sudo make install -- only for unstable, that will just be fvwm. It's generated from the not-so-lovely XML sources -- and IIRC, the man page is always built, but you would need to pass an option to ./configure to get the HTML documentation. I mean it's missing from the website: http://fvwm.org/documentation/manpages/unstable/ Unless I'm blind...
Generated web pages
Thomas Adam tho...@fvwm.org writes: On Fri, Oct 08, 2010 at 04:06:52PM -0400, des...@verizon.net wrote: Thomas Adam tho...@xteddy.org writes: I notice there is no fvwm2 man page for the unstable branch. I may get time to look but not right now. Err, do you mean on the website or built as part of ./configure make sudo make install -- only for unstable, that will just be fvwm. It's generated from the not-so-lovely XML sources -- and IIRC, the man page is always built, but you would need to pass an option to ./configure to get the HTML documentation. I mean it's missing from the website: http://fvwm.org/documentation/manpages/unstable/ Unless I'm blind... No, your eyesight's fine. I've regenerated the whole lot -- which is what I thought I did when I released 2.5.31, but maybe I was too drunk to remember? :P Either way, the index.php file looks more correct now, so if it still looks odd, let me know. At the bottom of the man page index there is a link: title-format.patch. The link doesn't go anywhere.
Re: FVWM: Identifying a window
Claude Rubinson rubin...@u.arizona.edu writes: There are certain websites for which I like to customize how FVWM treats the browser window (e.g., different styles for different sites). As long as the name of the website is part of the window name, it's not a problem. Occasionally, however, I'll run into a site where there's no stable name. For example, the online music streaming site MOG.com only includes the name of the artist and song in the window name. Many X clients let you specify your own name, but neither Firefox nor Chrome does. Is there a way to uniquely identify such browser windows (whether from within FVWM or not) when the site doesn't provide a fixed reference? For FvwmEvent, I can use the WindowId but as far as I understand, that doesn't work for Style specifications. FvwmIdent gives you the 3 possible values to match on, name, class, resource. Possibly some substring will work, like *Free MP3*.
Re: FVWM: Arrows Key don't works with Xorg 1.7.x
Mauricio E. Silva mauricioesi...@speedy.com.ar writes: Hi, I have a problem that may be related to Xorg instead of the FVWM but i couldn't find a solution there so i ask here to see if someone else got the same problem. I love the CTRL+ARROW KEYS function to change Desktops, but it didn't work on newer version of Xorg. As far as i tested the arrows keys in the Menu and WinList also stop working. The function that I'm talking about is: # Arrow Keys # press arrow + control anywhere, and scroll by 1 page Key LeftA C Scroll -100 0 Key Right A C Scroll +100 +0 Key Up A C Scroll +0 -100 Key DownA C Scroll +0 +100 This problem happens to me in this systems: - Slackware 13.1, FVWM 2.4.20, 2.5.28 and 2.5.30, Xorg 1.7.7 - FreeBSD 8.0, FVWM 2.5.30, Xorg 1.7.2 and works fine on: - Slackware 13.0, FVWM 2.5.28, Xorg 1.6.3 - FreeBSD 7.2, FVWM 2.4.20, Xorg 1.4.0 Using 1.7.6 here. Ctrl+Arrow works fine. Start up xev and verify that the arrow keys return Left/Right/Up/Down as expected. Then examine the keys with xmodmap, like this: home xmodmap -pke | grep Down keycode 88 = KP_2 KP_Down KP_2 KP_Down keycode 116 = Down NoSymbol Down keycode 186 = XF86ScrollDown NoSymbol XF86ScrollDown keycode 232 = XF86MonBrightnessDown NoSymbol XF86MonBrightnessDown keycode 237 = XF86KbdBrightnessDown NoSymbol XF86KbdBrightnessDown
Re: FVWM: Looking for a simple fvwm configuration to run under Cygwin/windows in rootless mode
Jean Florentine jeanflorent...@yahoo.com writes: Hi, But i had the multi desktop working once but i change computer and lost the config. As in .fvwm2rc i know how to set the number of desktop and page per desktop, my only problem is to display a desktop/page manager that remain visible on all desktop/pages, because the one i tried to work out lastly, if i happen to change desktop just by moving the mouse's cursor, then as the desktop manager is not shown on say desktop 2, i am not able to come back on desktop 1, and i have lost all ongoing work in the windows on this desktop. Tried to fixe it but got worse i just lost the desktop manager even on desktop1. Please reply to the list, not the poster. Maybe the Pager would work in rootless mode, I don't use Windows, I don't know. To make the pager appear on every desktop put this in your config file: Style FvwmPager Sticky
Re: FVWM: Looking for a simple rootless configuration for windows
Thomas Adam tho...@xteddy.org writes: On Thu, Jul 08, 2010 at 03:59:23PM -0700, Jean Florentine wrote: Hi All, If somebody would have a ready configuration for a rootless window manager with a button small window and a page manager could you please send me a copy of it. Many thanks. John Oddly enough you'll need to be more specific. Rootless window manager? What's this? I sure didn't know what that meant either. But, Google knows all. My take is it's a misnomer. It's X that starts in rootless mode, not the window manager. Here's a screenshot of Fvwm running under Cygwin/X in rootless mode: http://x.cygwin.com/screenshots/cygx-rootless-fvwm2-20031224-0010.png I have no idea how a pager would make sense in an environment like that.
Re: FVWM: 2.5.29 released.
Thomas Adam tho...@xteddy.org writes: On Fri, Apr 02, 2010 at 04:05:58PM -0400, Bob Woodside wrote: On Friday 02 April 2010, des...@verizon.net wrote: Glyn Millington g...@millingtons.org writes: Thomas Adam tho...@xteddy.org writes: Hello all, As promised earlier, FVWM 2.5.29 has been released. [snip] Hmm, my guess is that this is a forgery. I haven't seem an commit emails, etc. Hmmm...well, yesterday *was* April 1. Sorry -- I feel guilty now. But do you *really* think that a watchdog process to restart FVWM when it crashes for extra stability, is *really* something we'd have? :P Perhaps it's my English subtlty kicking in. Oh yeah, forgot about you being from England. Makes sense now. In my defense, at least I didn't believe it. I think this is an email that had me confused on day one, disbelieving on day two, and tomorrow it will be the funniest email ever.
Re: FVWM: initialmapcommand with restart
David Chanters david.chant...@googlemail.com writes: On 17 March 2010 15:53, Thomas Adam tho...@xteddy.org wrote: On 16 March 2010 21:36, David Chanters david.chant...@googlemail.com wrote: On 16 March 2010 21:15, Thomas Adam tho...@xteddy.org wrote: No, I am afraid not. Before I fixed it, it was broken. I can't even think i dont like this - can you add an option to keep the old behavior? Sorry, but to revert this would just be wrong -- so the answer is no. i find this unreasonable. i liked the old behavior because if i had put the window minimized when fvwm restarted it wouldnt be minimized anymore. so please revert this - or get someone else to do it if you cant Maybe you should describe what you want again. The way I understand your request, you are asking for Fvwm to un-minimize windows on a restart. Fvwm is supposed to restore windows to their previous state and position on a restart. Doing anything else is a bug.
Re: Google Summer Of Code 2010
Viktor Griph vik...@griph.se writes: 2010/3/7 Thomas Adam tho...@xteddy.org: The poignant things any prospective mentors are going to need to know [3] are covered in question 2 -- which I am happy to fill out, but note that this won't and cannot get off the ground without a *backup* mentor. That's critical, and one of the failings from last year's proposal. So -- anyone from fvwm-workers wanting to step up to that? To be clear again -- I am offering to be main point of contact, etc., etc., the role of a backup mentor is to supplement my role should I die, or have no Internet access, etc. Hopefully something unlikely! I could probably serve as a backup mentor, but I will be on vacation sometime this summer (I'm not sure of the timeline currently), at which point I would not be able to step in as a mentor, should the needs appear. I'm not ready to volunteer, but the normal way fvwm developers seek help is through the Fvwm-workers mailing list. That doesn't need to change in this case.
Re: FVWM: KDE/Gnome menus in FVWM
Thomas Adam tho...@xteddy.org writes: On Fri, Feb 26, 2010 at 06:58:59AM +1000, John H. Moe wrote: j...@aus10224 ~ $ fvwm-menu-desktop DestroyMenu gnome-sys AddToMenu gnome-sys Gnome System Menu Title j...@aus10224 ~ $ fvwm-menu-desktop --desktop kde-sys DestroyMenu kde-sys AddToMenu kde-sys Kde System Menu Title j...@aus10224 ~ $ What version of FVWM is this on? I did a tiny amount of work a few years ago now I think to fix the above, but thst was a few years ago. :) My (un)educated guess is that the script is working, but it's not finding menu definitions either where it's expecting, or in the format it's expecting. I am hoping Dan Espen will reply since he likes XDG menus [1]. Yep, hi all. The Fvwm script is broken and it should be removed before we do a 2.6 release. The problem with the script is that the underlying file structure changed. Here's what I'm using now: PipeRead 'xdg_menu --format fvwm2 2/dev/null' AddToMenu Utilities X. XDG Menu Popup xdg_menu I thought I saw this in my distribution's repositories but I guess not. Head over to archlinux.org and you should be able to find it.
Re: FVWM: KDE/Gnome menus in FVWM
Thomas Adam tho...@xteddy.org writes: On Thu, Feb 25, 2010 at 04:51:35PM -0500, des...@verizon.net wrote: Thomas Adam tho...@xteddy.org writes: Better would be to get the various distributions to include xdg_menu along with the other xdg tools I see (in Fedora). Well, I think they do in different guises. Debian has menu-xdg for instance [1]. Question is, can we rely on other distros to do this? Unlikely. And certainly not on any of the BSDes will you find integration like you do in Debian and Fedora. Hmm, I think an FVWM-centric solution is probably the way to go --- assuming its maintainability is easy. I'm betting menu-xdg does something different. Fedora has xdg-desktop-menu but it serves a different purpose. A few of the distro maintainers read here. Lets see if we get anything from them...
Re: FVWM: chromium under fvwm and opening pdf files
des...@verizon.net writes: Thomas Adam tho...@xteddy.org writes: On Sun, Feb 14, 2010 at 12:09:25AM +0100, Nathan Huesken wrote: Hi, When I use chromium under Xfce4, it opens pdf files using evince. When I use chromium under fvwm, it opens pdfs using firefox (which opens pdfs using evince, but is started and takes long to start). I am not sure, if this is really a fvwm thing, but it is my only guess. Maybe someone in the list knows ... Read up on how mailcap entries work. Nothing to do with FVWM. Desktop environments are messing up what used to be a well defined boundary between the window manager and X. On my Fedora system, /etc/mailcap contains: audio/*; /usr/bin/xdg-open %s image/*; /usr/bin/xdg-open %s application/msword; /usr/bin/xdg-open %s application/pdf; /usr/bin/xdg-open %s application/postscript ; /usr/bin/xdg-open %s text/html; /usr/bin/xdg-open %s ; copiousoutput So, from this system's point of view, mailcap is just a thin layer on top of xdg-open. xdg-open on my system only knows to use firefox. I see that xdg-open uses a file named defaults.list. I have 3 of those: /usr/local/share/applications/defaults.list /usr/share/applications/defaults.list /usr/share/kde-settings/kde-profile/default/share/applications/defaults.list I think the trick is to convince xdg-open to use one or more of those files... Following up my own post. xdg-open is a shell script that tries to figure out the desktop environment that is running and then uses a script provided by the desktop environment to open the file. You can take a look yourself. For environments it doesn't recognize it tries to use the following programs: mimeopen, run-mailcap, $BROWSER, htmlview, firefox, mozilla, netscape, links, lynx. (In that order). For kde it uses kde_open. For Gnome it uses gvfs-open or gnome-open. For XFCE it uses exo-open. I tried using kde_open under fvwm, it was too slow. exo-open, gnome-open and gvfs-open seemed ok. So I think hacking up xdg-open to use exo-open is the default might be a good solution for the OP.
Re: FVWM: chromium under fvwm and opening pdf files
Thomas Adam tho...@xteddy.org writes: On Sat, Feb 13, 2010 at 06:45:03PM -0500, des...@verizon.net wrote: Thomas Adam tho...@xteddy.org writes: On Sun, Feb 14, 2010 at 12:09:25AM +0100, Nathan Huesken wrote: Hi, When I use chromium under Xfce4, it opens pdf files using evince. When I use chromium under fvwm, it opens pdfs using firefox (which opens pdfs using evince, but is started and takes long to start). I am not sure, if this is really a fvwm thing, but it is my only guess. Maybe someone in the list knows ... Read up on how mailcap entries work. Nothing to do with FVWM. Desktop environments are messing up what used to be a well defined boundary between the window manager and X. On my Fedora system, /etc/mailcap contains: audio/*; /usr/bin/xdg-open %s image/*; /usr/bin/xdg-open %s application/msword; /usr/bin/xdg-open %s application/pdf; /usr/bin/xdg-open %s application/postscript ; /usr/bin/xdg-open %s text/html; /usr/bin/xdg-open %s ; copiousoutput So, from this system's point of view, mailcap is just a thin layer on top of xdg-open. Ah yes. I'd forgotten about that. I thought this only affected applications running under GNOME or KDE, where those frameworks offer a means of defining known applications. For instance, unless I run gnome-settings-daemon, I get to use .mailcap just fine. I can understand what the XDG are trying to do, but this seems completely bogus, when they should be completely dependant on mailcap entries entirely, rather than reinventing the wheel. Still, not a lot we can do about it. We could ask the xdg folks to try the kde, gnome, or xfce tools BEFORE they resort to mailcap, etc. Then Fvwm users would be okay as long as they had one of the desktop environments installed. Given the way most linux distros are packaged, that would work better almost always. The only problem I can think of is if some of the opens are based on some non-standard part of the DE's WM. This reminds me of the discussion we had a while back about xdg_menu. At first I downloaded and built xdg_menu, now it's a standard part of FC11.
Re: FVWM: Google Summer Of Code 2010
MK halfcountp...@intergate.com writes: On Sat, 30 Jan 2010 17:01:15 + Thomas Adam thomas.ada...@gmail.com wrote: Well, I am no where near coming up with a list of proposals, so I wouldn't get too enamoured with the TODO list. It's still very early days, but I'll keep your name on my list. I finally got some time to start to poking around in the code a little bit this afternoon. I notice fvwm does not have a devel mailing list -- is this the appropriate place to start asking pesky source code questions? fvwm-work...@fvwm.org
Re: FVWM: Application icons in panel and icon man
Nathan Hüsken f...@lonely-star.org writes: Hi, I am using fvwm for not to much time, and I like it very much. Thanks for the great work! What is nagging me: besides urxvt and gvim, every application is shown with the standard rotatet square icon. How can I change it? This is a little simpler than the other reply: First use FvwmIdent to look at the window's name(s). You want to look at the name, class or resource. Then assign an icon using any of the 3 names above: Style name Icon xyz.xpm I'm not sure about urxvt, (I use rxvt) but you may want to use different icons for each urxvt you have open. In that case, I start rxvt like this: rxvt -name xyz The xyz becomes the resource. Than you can assign an icon base on that resource name. In some cases, you may need to add OverrideIcon to the style command.
Re: FVWM: Cursor Position
Davidson Russell rdav...@yahoo.com writes: My company runs 2.5.26. In this release, when we right click on the desktop and select a window to focus on, the cursor automatically moves to the upper left corner of the selected window. Is this a bug? Is this a feature? Is there a way to turn this off? I've been searching for release notes for 2.5.26 and haven't had any luck. Why would you search the release notes? This is clearly described in the man page. Search for WindowList. Like most things in Fvwm, it can be turned off or changed pretty much any way you want.
Recent change to read.c
The recent change to the read logic causes a problem for me. Here's a part of my .fvwm2rc: read .fvwmrc.tile read .fvwmrc.mouse Those really are relative paths...
Re: Recent change to read.c
Thomas Adam thomas.ada...@gmail.com writes: 2010/1/7 des...@verizon.net: The recent change to the read logic causes a problem for me. Here's a part of my .fvwm2rc: read .fvwmrc.tile read .fvwmrc.mouse Those really are relative paths... Indeed -- I am at work, so attaching a patch with this email. I can't reproduce the problem myself, but does the patch attached fix it? If so, I'll clean it up later. There's no hurry on my part to fix it. I've got a local fix in place. I'm not sure why you made the change. Doesn't fopen FVWM_DATADIR/./file work?
Re: Recent change to read.c
Thomas Adam thomas.ada...@gmail.com writes: 2010/1/7 des...@verizon.net: Thomas Adam thomas.ada...@gmail.com writes: 2010/1/7 des...@verizon.net: The recent change to the read logic causes a problem for me. Here's a part of my .fvwm2rc: read .fvwmrc.tile read .fvwmrc.mouse Those really are relative paths... Indeed -- I am at work, so attaching a patch with this email. I can't reproduce the problem myself, but does the patch attached fix it? If so, I'll clean it up later. There's no hurry on my part to fix it. I've got a local fix in place. I'm not sure why you made the change. Doesn't fopen FVWM_DATADIR/./file work? I am sure it would do -- but since -f passing on the command line just uses Read internally, you can't do: fvwm -f some_file or: fvwm -f ./some_file ... and mean CWD -- since FVWM assumes that to be relative to FVWM_USERDIR -- that's fine. But that check should still happen, as it's cumbersome having to keep doing: fvwm -f $(pwd)/somefile It's been annoying me now for about a year. I see. I don't think using CWD is part of documented behavior... Making CWD the new default...hmm. All of my config files start with a dot. At first I thought testing for './' or '../' would be the right fix. Does that seem right to you?
Re: menustyle.c checked in with conflict markers
Thomas Adam thomas.ada...@gmail.com writes: On Tue, Jan 05, 2010 at 11:32:10PM -0500, des...@verizon.net wrote: It looks to me like menustyle.c has some CVS conflict markers in it. You must have local edits to that file when you did a cvs up? The copy of menustyle.c on the CVS server has no such conflict markers. Yep, sorry, problem at my end.
menustyle.c checked in with conflict markers
It looks to me like menustyle.c has some CVS conflict markers in it.
Re: FVWM: fvwm-convert-2.6: Testing needed.
Thomas Adam thomas.ada...@gmail.com writes: All, In preparation in trying to get FVWM 2.5.X stable to FVWM 2.6.0, one of the larger pieces to that puzzle was a converter script which would attempt at converting a FVWM file intended for 2.4.X to 2.6.X (which most people here can read as FVWM CVS for the time-being.) Is there anyone on the list who wouldn't mind checking out the FVWM CVS repository and giving the fvwm-convert-2.6 script a go? It has a manpage as well which describes what the script will try and do -- on the limited amount of testing I've done with configs I've got, and those found on the Internet, it seems to work OK -- and I get minimal errors from fvwm-cvs when I use the converted file. The man page says: Without an absolute path given as the destination path to the destination file, the program will create the destination file in the CWD. I ran: home cd /tmp home fvwm-convert-2.6 /home/dane/.fvwm/.fvwm2rc I found .fvwm2rc.converted in /home/dane/.fvwm. A lot of my functions start with a command on the first line. They all got deleted. AddToFunc Warp I Next [$0] Iconify -1 +I Next [$0] WarpToWindow 24p 24p + I None [$0] Beep I have a lot of bindings formatted like this: Mouse 1 R A Menu Systems Nop There's a comment heading above them indicating what the fields mean. They all got reformatted. It would be good if only lines with real changed got reformatted.
Re: Any outstanding issues/bug-fixes? (FVWM 2.6.0)
Thomas Adam thomas.ada...@gmail.com writes: All, Are there any outstanding bug-fixes which haven't yet been looked into, but were at one point reported to this list? I can't say I reported it, but pinning an Fvwm menu and then clicking on the window button to Delete the menu terminates Fvwm.
Re: Any outstanding issues/bug-fixes? (FVWM 2.6.0)
Thomas Adam thomas.ada...@gmail.com writes: On Sat, Jan 02, 2010 at 12:25:05PM -0500, des...@verizon.net wrote: Thomas Adam thomas.ada...@gmail.com writes: All, Are there any outstanding bug-fixes which haven't yet been looked into, but were at one point reported to this list? I can't say I reported it, but pinning an Fvwm menu and then clicking on the window button to Delete the menu terminates Fvwm. Don't suppose you know who did? :) I can't remember anyone reporting it. I can't reproduce this -- I'm tearing-off as many menus as I can, and then have bound to button 1, the command Close. That closes the menu just fine, leaving FVWM running just fine. I repeated the same thing with the Delete and Destroy commands as well. Same result: no bug. :) Is there anything more I have to do to try and reproduce this, do you know? Got to run more tests...back later.
Re: Any outstanding issues/bug-fixes? (FVWM 2.6.0)
des...@verizon.net writes:
Thomas Adam thomas.ada...@gmail.com writes:
On Sat, Jan 02, 2010 at 12:25:05PM -0500, des...@verizon.net wrote:
Thomas Adam thomas.ada...@gmail.com writes:
All,
Are there any outstanding bug-fixes which haven't yet been looked into,
but
were at one point reported to this list?
I can't say I reported it, but pinning an Fvwm menu and then clicking on
the window button to Delete the menu terminates Fvwm.
Don't suppose you know who did? :)
I can't remember anyone reporting it.
I can't reproduce this -- I'm tearing-off as many menus as I can, and then
have bound to button 1, the command Close. That closes the menu just
fine, leaving FVWM running just fine. I repeated the same thing with the
Delete and Destroy commands as well. Same result: no bug. :)
Is there anything more I have to do to try and reproduce this, do you know?
Got to run more tests...back later.
Okay, a bit more to this than I thought.
I bring up a menu, pin it with button 2 on the title bar, then
click on a pixmap on the title bar with an X.
The button is bound to:
DestroyDecor recreate DecorBase
AddToDecor DecorBase
+ AddButtonStyle 4 Pixmap mini.delete.xpm mini.destroy.xpm
Mouse 0 4 A Function CloseIt
Style * UseDecor DecorBase, ColorSet 3
DestroyFunc CloseIt
AddToFunc CloseIt C Delete
+ D Destroy
I single click so I think I'm running Delete on the window.
What really happens is Fvwm crashes. Here's the back trace:
(gdb) where
#0 PDestroyFvwmPicture (dpy=0x89c0c80, p=0xc8)
at ../../version-2_5_29/libs/Picture.c:182
#1 0x08098225 in menustyle_free_face (mf=0x8a8d9dc)
at ../../version-2_5_29/fvwm/menustyle.c:88
#2 0x080991c1 in menustyle_free (ms=0x8a8d9d0)
at ../../version-2_5_29/fvwm/menustyle.c:466
#3 0x08055128 in do_menu_close_tear_off_menu (mp=
{menu = 0x8a8ff60, parent_menu = 0x0, parent_item = 0x0, pexc =
0xbf98e558, tear_off_root_menu_window = 0x0, ret_paction = 0x0,
event_propagate_to_submenu = 0x0, pops = 0x0, screen_origin_x = 0,
screen_origin_y = 0, flags = {has_default_action = 0, is_already_mapped = 0,
is_first_root_menu = 0, is_invoked_by_key_press = 0, is_sticky = 0, is_submenu
= 0, is_triggered_by_keypress = 0}},
mr=0x8a8ff60) at ../../version-2_5_29/fvwm/menus.c:5718
#4 menu_close_tear_off_menu (mp=
{menu = 0x8a8ff60, parent_menu = 0x0, parent_item = 0x0, pexc =
0xbf98e558, tear_off_root_menu_window = 0x0, ret_paction = 0x0,
event_propagate_to_submenu = 0x0, pops = 0x0, screen_origin_x = 0,
screen_origin_y = 0, flags = {has_default_action = 0, is_already_mapped = 0,
is_first_root_menu = 0, is_invoked_by_key_press = 0, is_sticky = 0, is_submenu
= 0, is_triggered_by_keypress = 0}},
mr=0x8a8ff60) at ../../version-2_5_29/fvwm/menus.c:5831
#5 0x0806eb91 in HandleClientMessage (ea=0xbf98e668)
at ../../version-2_5_29/fvwm/events.c:1812
#6 0x0806b2a9 in dispatch_event (e=0xbf98e6a0)
at ../../version-2_5_29/fvwm/events.c:4105
#7 0x0806b9b5 in HandleEvents () at ../../version-2_5_29/fvwm/events.c:4149
#8 0x0808d785 in main (argc=1, argv=0xbf98ee34)
at ../../version-2_5_29/fvwm/fvwm.c:2581
Re: FVWM: Happy New Year... :)
Thomas Adam thomas.ada...@gmail.com writes: Hi all, Timezones notwithstanding, happy new year to everyone reading this. Mine's in ~4 hours -- doubtless some have had theirs already. :) It's been a good year for FVWM -- I am sure 2010 will hold similar niceties. :) Happy New Year. Same to you. Appreciate all the work you've been doing lately. I'm just learning Qt and I've had some issues getting DD working. When I get some time I'll get current and check it out.
Re: FVWM: Autofocus on matlab windows
math...@iup.physik.uni-bremen.de writes: Dear all, I use fvwm under debian : fvwm -V fvwm 2.5.28 (from cvs) compiled on Aug 17 2009 at 22:43:46 with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, Xinerama, XRender, XCursor, XFT, NLS I haevily use matlab and have the very annoying feature, that every time a figure (coming in an own window) is adressed this window gets the focus. I already searched the web and found three solutions, none of which worked: This appears to be a very old issue, check here: http://www.mail-archive.com/fvwm-work...@lists.math.uh.edu/msg00373.html I don't know if this was ever resolved but you might want to check with Matlab.
Re: FVWM: Basic question about taskbar window
Charlie aries...@clearmail.com.au writes: On Sun, 25 Oct 2009 17:37:39 -0400 des...@verizon.net sent this information: snip There has to be more to it than that? I'm sorry, I don't understand. I admit not having time to look through much of the documentation, but reading snippet and trying a few things out when time permits, But things don't work as the man pages describe: Tell us what you tried. Post your config, etc. You have to restart Fvwm for actions to take effect unless you are using one of the interactive interfaces. Just quickly: Ok, I put all that in a file, changed the colorset numbers to one I have defined, used FvwmTalk to read it then started FvwmTaskBar. Everything seems to be working as it should. Button 1 says FuncFvwmDeiconifyFocusAndRaise is undefined (which I would expect) and button 2 toggles iconification. Remind me again what you want to do and what you think is not working the way you want it.
Re: FVWM: Basic question about taskbar window
Charlie aries...@clearmail.com.au writes: On Sun, 25 Oct 2009 18:33:03 -0400 des...@verizon.net sent this information: snip Ok, I put all that in a file, changed the colorset numbers to one I have defined, used FvwmTalk to read it then started FvwmTaskBar. Everything seems to be working as it should. Button 1 says FuncFvwmDeiconifyFocusAndRaise is undefined (which I would expect) and button 2 toggles iconification. Remind me again what you want to do and what you think is not working the way you want it. Thank you. I think I may not know the terminology. In the screenshot there are two icons? taskbars? There's my problem with terminology. I thought one would be a taskbar - the one on the left? I would like to change the colour of the background in both. Maybe you should show us your colorset definitions. This works for me: DestroyModuleConfig FvwmTaskBar: * *FvwmTaskBar: Colorset 18 *FvwmTaskBar: FocusColorset 19 *FvwmTaskBar: IconColorset 20 *FvwmTaskBar: TipsColorset 4 Colorset 18 fg blue, bg pink Colorset 19 fg red, bg yellow Colorset 20 fg white, bg black To test, I like to put this stuff in a file by itself, maybe /tmp/x Then bring up FvwmTalk Enter: Read /tmp/x KillModule FvwmTaskBar FvwmTaskBar I don't use any taskbar, or anything else that clogs up the screen but Tom is right about FvwmIconMan and FvwmButtons. They are more complex to configure but the end result can be better.
Re: FVWM: question about FvwmButtons config
Thomas Adam thomas.ada...@gmail.com writes: 2009/10/6 Jamie Griffin griff...@cs.man.ac.uk: I've re-read the man page you suggested, however i'm still unclear exactly how i do it. And if i was to try and use two instances of FvwmButtons, how would i do that? *FvwmButtonsGeometry +928+20 That's wrong, even for FVWM 2.4.X -- module commands are now in the form: *Alias: Option value ...note the colon. The colon was added in at some point. Very cleverly, I believe the old syntax still works.
Re: FVWM: starting up applications
Jason Weber bab...@imonk.com writes: On Thu, Sep 24, 2009 at 4:40 PM, Jason L Tibbitts III ti...@math.uh.edu wrote: JW == Jason Weber bab...@imonk.com writes: JW So what is to keep the limitless cash of corporate behemoths from JW poisoning forums such as this with cheap outsourced labor? This seems a non sequitur to me. I suggest the possibility that some day,,, Nope, 6 or 7 billion people in the world. Lots of them with internet access. They're coming out of the woodwork.
Re: FVWM: MissingSubmenuFunction or Piperead or bash simple problem...
alexworld alexwo...@wanadoo.fr writes: hi all, i have a small script, kind of menu directory once reducted to trace, but it can't go to deeper than first directory, and i've looking real much at this but don't find the solution. output is really, really similar to fvwm-menu-directory, at least in console. Am I right in guessing you want to do something like fvwm-menu-directory but you want to include sub-directories? First tell us, do you want the sub-directories in sub-menus OR do you want one menu listing files AND sub-directories?
Re: FVWM: starting up applications
Darren Upsolla abovefrombe...@hotmail.com writes: From: jai...@math.boisestate.edu StartFunction is ran after fvwm starts up and reads though your config. It will run every time fvwm is started. Some things like FvwmModules will need to be started every time while others you may only want to run on the initial start up or on a restart. The Test () option says to only ok - where do i find more information about this? is it in the manpage or somewhere else? i thought i had read about it last week on this list but i think my mind plays tricks - sorry for the question The Fvwm Manpage describes this well. That's the official documentation. Look here: http://fvwm.org/documentation/manpages/unstable/fvwm.php Section 9, Initialization. Generally you should use InitFunction to start applications: DestroyFunc InitFunction AddToFunc InitFunction + I Exec exec xsetroot -solid cyan + I Exec exec xterm + I Exec exec firefox
Re: FVWM: thomas adam ill
Darren Upsolla abovefrombe...@hotmail.com writes: hi, it has been brought to me attention thomas adam is seriously ill - just thought you should know darren Very sad news indeed. His contributions have been much appreciated.
fvwm-menu-directory, xdg-menus
Hi, Fvwm-menu-directory stopped working for me a while back. I'm using FC10 right now and the script doesn't generate anything useful. I still prefer to build my own menus for the things I invoke a lot but having access to the desktop menus is nice for finding things I don't use often. Looking around, it looks like the state of KDE/Gnome menus has advanced significantly. They follow a specification called XDG. As part of ArchLinux I found a package called arch-xdg-menu that generates menus for a whole bunch of window managers including Fvwm2. It's a bit clumsy, it's not easy to find: http://aur.archlinux.org/packages.php?do_Details=1ID=10535 And when I unpack it it creates a few files and sub-directories. The only file I find useful is xdg-menu which I use like this: PipeRead 'xdg_menu --format fvwm2 2/dev/null' AddToMenu Utilities X. XDG Menu Popup xdg_menu The xdg-menu script is Perl and requires the Perl XML parser. Any thoughts on better menu builders, what we should do with fvwm-menu-directory or xdg-menu?
Re: fvwm-menu-desktop, xdg-menus
Thomas Adam thomas.ada...@gmail.com writes: 2009/6/4 des...@verizon.net: Fvwm-menu-desktop stopped working for me a while back. I'm using FC10 right now and the script doesn't generate anything useful. Can you be more specific? :) Oh boy, great start. Should have said fvwm-menu-desktop On FC10: home fvwm-menu-desktop --desktop gnome DestroyMenu gnome AddToMenu gnome Gnome System Menu Title home fvwm-menu-desktop --desktop gnome-redhat DestroyMenu gnome-redhat AddToMenu gnome-redhat Gnome RedHat Menu Title
Re: fvwm-menu-desktop, xdg-menus
Thomas Adam thomas.ada...@gmail.com writes: Hello, 2009/6/4 des...@verizon.net: Thomas Adam thomas.ada...@gmail.com writes: 2009/6/4 des...@verizon.net: Fvwm-menu-desktop stopped working for me a while back. I'm using FC10 right now and the script doesn't generate anything useful. Can you be more specific? :) Oh boy, great start. Should have said fvwm-menu-desktop On FC10: home fvwm-menu-desktop --desktop gnome DestroyMenu gnome AddToMenu gnome Gnome System Menu Title home fvwm-menu-desktop --desktop gnome-redhat DestroyMenu gnome-redhat AddToMenu gnome-redhat Gnome RedHat Menu Title Didn't I fix that in CVS? See: http://www.mail-archive.com/fvwm-workers@fvwm.org/msg01677.html I couldn't tell you what KDE does, Mind you, I am assuming FC10 is using at least FVWM 2.5.27? In which case it's likely to be somethiing else. I certainly can't reproduce it anymore on my Debian installation, and the results you've outlined here were the same symptoms as the problem I (purportedly) fixed. I'm running Fvwm built from CVS. If I understand fvwm-menu-desktop it's looking for .desktop files in /usr/share/gnome/apps or applications. On my FC10 install there is no such directory: home ll /usr/share/gnome drwxr-xr-x 2 root root 4096 2009-04-30 15:59 autostart -rw-r--r-- 1 root root 884 2009-01-15 20:08 default.session drwxr-xr-x 85 root root 4096 2009-05-14 21:33 help drwxr-xr-x 2 root root 4096 2009-04-30 15:47 shutdown drwxr-xr-x 2 root root 4096 2009-04-30 15:58 wm-properties I looked around for a bunch of .desktop files and didn't find them. I came to the conclusion that the right way to build these menus is to use the XDG specified XML files. I don't remember the whole spec but I did find xdg-menus produces useful menus.
Re: FVWM: gedit
christopher floess skepti...@gmail.com writes: Okay, I figured I'd get this, so here goes. I'll start by saying that what I was getting at is that in *all of the time that I've used fvwm*, gedit has followed me from workspace to workspace(viewport to viewport). Whether it's iconified or not, it's there. It's especially troublesome when it's not iconified, and I have a bunch of xterms open on one workspace(viewport), and then some code that I'd like to compare to in gedit in another workspace(viewport). Switching back and forth between gedit and the xterms is difficult if gedit follows me around all the time. So, to address some of the issues, which I didn't clarify phrase properly: Are you therefore saying that currently it does just that? i.e., puts itself in a layer above all others? --- it just follows me from workspace to workspace, i.e one large virtual desktop, in which each viewport has the gedit window in it Looks like you didn't understand my previous reply. I'll try again. First, this has nothing to do with layers. Gedit is making itself sticky. This is new behavior, there are threads about this online with other window managers. Here's how I fixed it. I have a menu where I keep window operations like move, iconify, resize, etc. It also has an entry to toggle stickyness. If you don't have a menu like that I suggest you create one. Here's an excerpt from the menu: DestroyMenu Window-Ops AddToMenu Window-Ops --Window Operations-- Title + %mini.excl.xpm%Restart Fvwm Restart fvwm2 + Nop + %mini.destroy.xpm%Destroy Destroy + %mini.delete.xpm%Delete Delete + %mini.move.xpm%Move Function Move-or-Raise + %mini.resize.xpm%Resize Function Resize-or-Raise + %mini.raise.xpm%Raise Raise + %mini.lower.xpm%Lower Lower + %mini.iconify.xpm%(De)Iconify Iconify + %mini.stick.xpm%(Un)Stick Stick + %mini.maximize.xpm%(Un)Maximize Maximize ... After you've created or modified your menu, restart fvwm and invoke the menu. When you pick the option (Un)Stick the window you are over will have it's stickyness toggled. If you are on the root window, the pointer will change to an + until you click on the window you want to toggle stickyness on. Use this to toggle the stickyness of gedit. Gedit will save that state and won't be sticky anymore. Even when you restart it. Hope this helps.
