Re: FVWM: how can i get the fvwm start?
On Wed, 21 Oct 2009 13:06:19 +0800, ch huang justlo...@gmail.com wrote: i use centos5.3,now my desktop is xfce,and i have installed fvwm ./configure make make install and everything is fine.but, now question is how can i get it start? i switch to console 0 ,and type init 3 to stop my xfce,and type fvwm (also tried fvwm2) ,get an error: can not display how can i do to make fvwm work? That depends on how do you start your X session usually. If you use a display manager like [XKG]DM then it should provide an option to load fvwm instead of the desktop you are currently running. If not, you should be able to boot it by selecting something like default session and running fvwm from your ~/.xsession file. If you use startx to startx from the command line, then the file to look at is ~/.xinitrc In any case, this is not an fvwm related topic, but rather related to the config of X or your login manager, depending on how do you enter X. -- Jesús Guerrero
Re: FVWM: Autoraise breaks after upgrade
On Thu, 1 Oct 2009 14:15:13 +0100, Thomas Adam thomas.ada...@gmail.com wrote: 2009/9/29 Jesús Guerrero i92gu...@terra.es: On Mon, 28 Sep 2009 21:49:19 -0600, Kelly Jones kelly.terry.jo...@gmail.com wrote: In an older version of fvwm2, this line in my .fvwm2rc file: FvwmAuto 100 Raise autoraised windows when I hovered over them for 100ms. With the latest fvwm2, it doesn't. How to fix? Remove any references to ModulePath in your .fvwm2rc file then it will work just fine. My brain doesn't remember about older versions. But at least now to load a module you have to use the Module command. Module FvwmAuto whatever else No, this isn't right. See: http://forums.gentoo.org/viewtopic-p-4153230.html#4153230 Thanks for the correction and all the extra information, I was completely wrong. -- Jesús Guerrero
Re: FVWM: Autoraise breaks after upgrade
On Mon, 28 Sep 2009 21:49:19 -0600, Kelly Jones kelly.terry.jo...@gmail.com wrote: In an older version of fvwm2, this line in my .fvwm2rc file: FvwmAuto 100 Raise autoraised windows when I hovered over them for 100ms. With the latest fvwm2, it doesn't. How to fix? My brain doesn't remember about older versions. But at least now to load a module you have to use the Module command. Module FvwmAuto whatever else Out of curiosity, from what version to what version did you upgrade? -- Jesús Guerrero
Re: FVWM: starting up applications
On Mon, 21 Sep 2009 23:26:43 +, Darren Upsolla abovefrombe...@hotmail.com wrote: 388798.76838...@web32903.mail.mud.yahoo.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Date: Mon=2C 21 Sep 2009 15:59:22 -0700 From: ppu...@yahoo.com Subject: Re: FVWM: starting up applications To: fvwm@fvwm.org From: thomas.ada...@gmail.com Date: Mon=3D2C 21 Sep 2009 22:31:24 +0100 Subject: Re: FVWM: starting up applications To: abovefrombe...@hotmail.com CC: jai...@math.boisestate.edu=3d3b des...@verizon.net=3d3b fvwm@fvwm.org So is something like the following patch attached what you meant? To be honest=3D2C I consider the patch to add bloat over any useful explanation. Plus=3D2C since you don't say *which* bits from my original post you consider worthy of inclusion in the manpage=3D2C it makes my job a lot harder. this is like so much worse - now it sucks just like you. please dont update=3D this man page=3D2C let someone else do it who knows what theyre talking abou=3D t Darren Please refrain from such infantile remarks. The man is trying to be helpf= ul=2C and frankly=2C you're not. i am trying - it would be nice to see that intire initilization section rew= orded - now this patch makes it suck donkey i cant read it - get confusing = with restartfunc and startfunc - thomas cant do it - to technical - someone= else will have to do it - you should leave thomas_adam - waste of time No, it's not too technical, it's *fvwm*, in case you missed it. Your you suck argument against someone who's trying to help you is not even proper of a child. i can try and rewrite it - all of it I doubt it, counting on the fact that you can't write about something that in your own words you can't read. But good luck nonetheless with both the patch, and with getting it applied upstream after you came here insulting people. --- @list, something just rang a bell in my head, this guy is the same one that came some days ago spreading FUD about Thomas Adam being ill[1], which was both untrue and of a extremely bad taste, so just ignore him. He's just making noise for who knows what reason. Just forget he exists. [1] http://article.gmane.org/gmane.comp.window-managers.fvwm/5732 -- Jesús Guerrero
Re: FVWM: Tutorial
On Wed, 16 Sep 2009 11:02:07 -0400, Michael Kirsch mkirsch...@gmail.com wrote: I was wondering if you know of a good fvwm tutorial somewhere online, I can't seem to really find anything useful. In addition to the one that Thomas Adam suggests, I wrote another basic tutorial some time ago, but it's in Spanish. I don't know if you can read it, but here you are just in case: http://jesgue.homelinux.org/fvwm-es-tutorial.php -- Jesús Guerrero
Re: FVWM: starting up applications
On Wed, 16 Sep 2009 23:07:31 +, Darren Upsolla abovefrombe...@hotmail.com wrote: 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 Search for StartFunction in the fvwm man page and you'll eventually find all the info you seek. I think the section is called INITILIZATION or something similar. But a search should suffice anyway. -- Jesús Guerrero
Re:
On Fri, August 28, 2009 08:10, Thomas Adam wrote: 2009/8/28 Jesús Guerrero i92gu...@terra.es: It does. Same problem. When I try to open some dialogs, the tabs seem to stop responding to clicks. Keybindings however like alt+number work. Can't reproduce it all. Does: firefox -safe-mode ... still exhibit this? Is this on a 64-bit machine? I can well imagine there's the possibility of patches from Gentoo being applied here as well. Try with firefox by downloading it direct from firefox.com -safe-mode surprisingly works, almost. I get an empty window when I try to open the plugins dialog, but closing it works ok and I can click the tabs. After that, if I open the plugins window again it works. It appears with a very small size but that's a minor annoyance, however, the empty window is a symptom that something is broken in a weird way. All in all it's acting very weird, I tested a clean user, and the same problem persists, unless I use the safe mode. This is on a clean profile without any extension or anything at all. It's indeed a 64 bits build. I am going to test a binary build from mozilla for the same exact version, and see what happens. What amazes me is that I haven't been able to reproduce this under fluxbox. In any case, I am becoming bored of firefox and all the extra pain it causes. I don't use any weird extension, just flashblock. Go figure. Thanks. -- Jesús Guerrero
[no subject]
Hello, I've been suffering some strange behavior in firefox for the last two days of so, but I haven't took the time to narrow it down until now. I can reproduce the problem as follows: -Launch firefox -Try to open the extensions dialog, or right click in a bookmark and choose properties to edit it. -A dialog should come, but it doesn't. -The windowlist doesn't reveal any window either, other than the main firefox window. -From the momment I try to open that dialog, I can no longer change the current tab *with the mouse*, however, alt+1,2,... works, the rest of the interface works without a problem. I tried it in flux, and it seems to work without problems. The dialogs come normally, and nothing screws up. I don't know if the problem is in one of the latest commits, of if it's a firefox problem, but it only seem to happen under fvwm, I tested without any config file at all, so I know that whatever the problem is, it doesn't lie in my config file. Any idea on where to look? Thanks. -- Jesús Guerrero
Firefox annoyances, once more
Sorry for leaving the title blank in the previous post. I have to add a couple of details. When I launch firefox the first time, it looks like this: http://jesgue.homelinux.org/temp/fvwm-firefox.png If I close it and re-open it again, it looks like this: http://jesgue.homelinux.org/temp/fvwm-firefox2.png If I maximize that window then it looks like normal, but it exhibits the behavior I explain on the previous mail. -- Jesús Guerrero
Re:
On Fri, August 28, 2009 07:37, Thomas Adam wrote: 2009/8/28 Jesús Guerrero i92gu...@terra.es: Hello, I've been suffering some strange behavior in firefox for the last two days of so, but I haven't took the time to narrow it down until now. I can reproduce the problem as follows: This should be on fvwm@, not fvwm-work...@. Sorry. I don't know what I was thinking. I tried it in flux, and it seems to work without problems. The dialogs come normally, and nothing screws up. I don't know if the problem is in one of the latest commits, of if it's a firefox problem, but it only seem to happen under fvwm, I tested without any config file at all, so I know that whatever the problem is, it doesn't lie in my config file. Any idea on where to look? Does: fvwm -f /dev/null Still show the same problem? If not, what does your config look like? I can't reproduce it here. It does. Same problem. When I try to open some dialogs, the tabs seem to stop responding to clicks. Keybindings however like alt+number work. It happens with some dialogs only, the properties of a bookmark, the complements dialog, the download dialog... The preferences dialog however is shown correctly. The others do not appear in the screen and after that the tabs stop responding to left clicks. It's the weirdest thing I've ever seen in firefox however, because right click contextual menu still works, and the X button on each tab works as well. It's firefox 3.5.2, by the way. I posted just in case you or anyone else could think of anything in the latest commits that could be interfering with this. But if that's not the case, then probably the bug is somewhere in firefox. I'll try to downgrade it or something. Thank you, Thomas Adam. -- Jesús Guerrero
Re: FVWM: fvwm forum blanked
On Sat, July 4, 2009 12:30, Thomas Adam wrote: 2009/7/4 Jesús Guerrero i92gu...@terra.es: Thank you for the response. I just wanted to make sure that I wasn't the only one. Since I don't do much IRC... It was also mentioned on here a few days ago. Fixed now. I missed that one. Thank you, Thomas. -- Jesús Guerrero
FVWM: fvwm forum blanked
Hi, I've noticed that the forum at fvwm.lair.be has been down for some weeks now. Well, the server seems to respond, but it just shows a blank page no matter which url you open (from a google search for example). Just wanted to know if anyone else noticed and if there's any problem or whatever. Thanks to google cache most contents is accessible still ;p Regards. -- Jesús Guerrero
Re: FVWM: fvwm forum blanked
On Sat, July 4, 2009 05:05, Jaimos F Skriletz wrote: Jesús Guerrero wrote: Hi, I've noticed that the forum at fvwm.lair.be has been down for some weeks now. Well, the server seems to respond, but it just shows a blank page no matter which url you open (from a google search for example). Just wanted to know if anyone else noticed and if there's any problem or whatever. Thanks to google cache most contents is accessible still ;p Regards. Yes, many are aware of it in #fvwm on feenode. I have even seen TheBlackDragon (main admin) mention it. If and when he gets around to fixing what ever the database issue may be I do not know though. *edit* resend to cc fvwm@fvwm.org and move the reply to the bottom as per policy. jaimos Thank you for the response. I just wanted to make sure that I wasn't the only one. Since I don't do much IRC... Regards. -- Jesús Guerrero
FVWM: ButtonStyle, pixmaps and UseTitleStyle
Forgive if this is such a simple question but I have little experience with pixmaps and how they are handled in fvwm. I have this deco: DestroyDecor Decoration AddToDecor Decoration + ButtonStyle All -- UseTitleStyle Flat + BorderStyle Active Colorset 2 -- HiddenHandles NoInset + BorderStyle Inactive Colorset 1 -- HiddenHandles NoInset + ButtonStyle 7 Pixmap application-exit.png -- Flat + TitleStyle Active Colorset 2 + TitleStyle Inactive Colorset 1 + TitleStyle Height 32 -- Flat application-exit.png has some transparent parts, and besides that, it's a 22x22 image, so there's a lot of room around it. I've set all the buttons to use the title style. However instead I see the default grey color around the pixmap. Is there a way to overcome that without resizing the image to fit the whole height of the title bar? Thank you. -- Jesús Guerrero
[Fwd: Re: FVWM: ButtonStyle, pixmaps and UseTitleStyle]
On Thu, June 25, 2009 20:35, Thomas Adam wrote: 2009/6/25 Jesús Guerrero i92gu...@terra.es: Forgive if this is such a simple question but I have little experience with pixmaps and how they are handled in fvwm. I have this deco: DestroyDecor Decoration AddToDecor Decoration + ButtonStyle All -- UseTitleStyle Flat + BorderStyle Active Colorset 2 -- HiddenHandles NoInset + BorderStyle Inactive Colorset 1 -- HiddenHandles NoInset + ButtonStyle 7 Pixmap application-exit.png -- Flat + TitleStyle Active Colorset 2 + TitleStyle Inactive Colorset 1 + TitleStyle Height 32 -- Flat application-exit.png has some transparent parts, and besides that, it's a 22x22 image, so there's a lot of room around it. I've set all the buttons to use the title style. However instead I see the default grey color around the pixmap. Is there a way to overcome that without resizing the image to fit the whole height of the title bar? Have you not looked at using AdjustedPixmap? If that's not reliable, just adjust the PNG file to fit the size you want. Thanks, Thomas, Yes, I've tried, but in the places where the png is transparent (square icons are rare nowadays) I can still see the grey color. Not a big deal, this is easy to automate using imagemagick, but I was just wondering if fvwm was capable of this not to reinvent the wheel. -- Jesús Guerrero -- Jesús Guerrero
Re: a patch to highlight titlebar buttons under mouse pointer
El Dom, 29 de Marzo de 2009, 1:51, David Fries escribió: On Fri, Mar 27, 2009 at 11:19:27PM -0700, Ilya Sandler wrote: Good morning/evening, It seems that most modern GUIs try to highlight a widget under the mouse pointer. This visual feedback is especially useful for closely-spaced widgets like fvwm buttons in window titlebar, so I'm attaching a patch which implements this functionality. If you are going to highlight title bar buttons, why not title, side and corner handles as well? They are usually grabable. A few notes: 1. I used Jes?s Guerrero's hover patch as a starting point (But rather than allowing user to specify hover styles in the configuration, my patch simply highlights the existing button pixmap without any configuration requirements) If by 'without any configuration requirements' means it can't be disabled by the configuration, I'm not going to like it. And an additional note, that patch is not mine, I can't remember who the original author was. I might have modified it to keep it in sync with fvwm, I don't really remember either. But the original patch wasn't mine so I deserve no credit for it. -- Jesús Guerrero
Re: old gtk1 dependency
Hello, I am not sure if this has any value for the thread, so please, if it doesn't just ignore this post and forgive me for disrupting the discussion. I just wanted to illustrate the current state of this in Gentoo, since other people around already did the same for debian based distros. El Mar, 10 de Marzo de 2009, 0:16, Thomas Adam escribió: Note also FvwmGtkDebug -- last I checked that suffers from a similar dependency. In the gentoo ebuild, Gtk.pm and *FvwmGtkDebug* are removed unconditionally since I cleaned up the whole think (for 2.5.25 I think, it's been long since), and no one has even complained about it. This is true for both the official ebuild for 2.5.26 and the unofficial cvs one. Note that this stuff would anyway need gtk-perl, which was gone off the portage tree long ago, so, the official portage can't support that feature unless we add another gtk1-based package that's already deprecated and probably unmaintained. The rest of gtk1 support should work (never used it myself though) and is controlled via an USE flag, but I don't know about anyone using it either. So, I don't think that Gentoo users in general would care about you dropping gtk1 at all. Nowadays no one is going to add any gtk1 based package into portage unless it's needed to save a kitten from an horrible death or something like that. :) -- Jesús Guerrero
[Fwd: Re: FvwmButtons segfaults after updating (cvs)]
El Lun, 23 de Febrero de 2009, 6:00, Thomas Adam escribió: *Please* get a corefile if you can for analysis. Thanks, Thomas. I will try that when I'm at home. -- Jesús Guerrero
Re: [Fwd: Re: FvwmButtons segfaults after updating (cvs)]
El Lun, 23 de Febrero de 2009, 11:20, Jesús Guerrero escribió: El Lun, 23 de Febrero de 2009, 6:00, Thomas Adam escribió: *Please* get a corefile if you can for analysis. Thanks, Thomas. I will try that when I'm at home. I made a debug build and configured the core dumps to unlimited, everything is in this tarball. http://jesgue.homelinux.org/other-files/fvwm-debug.tar.bz2 --- $ gdb -core core GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-pc-linux-gnu. (no debugging symbols found) Core was generated by `/usr/lib/fvwm/2.5.27/FvwmButtons 7 4 none 0 8 -g 1508x64-92-0 FvwmPanel'. Program terminated with signal 11, Segmentation fault. [New process 11715] #0 0x0040d909 in ?? () (gdb) symbol /usr/lib/debug/usr/lib/fvwm/2.5.27/FvwmButtons.debug Reading symbols from /usr/lib64/debug/usr/lib/fvwm/2.5.27/FvwmButtons.debug...done. (gdb) bt #0 0x0040d909 in alloc_buttonlist (ub=0x65e360, num=value optimized out) at button.c:507 #1 0x0040df75 in ShuffleButtons (ub=0x65e360) at button.c:783 #2 0x0040c520 in main (argc=9, argv=0x7fff4c01ff38) at FvwmButtons.c:783 --- If you need something else just let me know. -- Jesús Guerrero
Re: [Fwd: Re: FvwmButtons segfaults after updating (cvs)]
I have some news. For some weird reason, if I use *FvwmPanel: Geometry $[panel_width]x$[panel_height]-$[panel_offset]-0 instead of the -g option when invoking the module, it works without a problem. The config file is still the same, except for that slight change. -- Jesús Guerrero
Re: [Fwd: Re: FvwmButtons segfaults after updating (cvs)]
Index: modules/FvwmButtons/button.c
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmButtons/button.c,v
retrieving revision 1.40 diff -u -r1.40 button.c ---
modules/FvwmButtons/button.c 22 Feb 2009 21:24:48 - 1.40 +++
modules/FvwmButtons/button.c 23 Feb 2009 11:51:06 - @@ -489,6 +489,7
@@
/* needed to prevent a gcc -O3 bug */
volatile int old;
+ old = ub-c-allocated_buttons;
if(num=ub-c-allocated_buttons) {
if(numold || old(old+32)) /* test for numold or for signed overflow */
This indeed seems to work with the old config file.
--
Jesús Guerrero
Re: [Fwd: Re: FvwmButtons segfaults after updating (cvs)]
El Lun, 23 de Febrero de 2009, 14:01, Thomas Adam escribió:
2009/2/23 Jesús Guerrero i92gu...@terra.es:
Index: modules/FvwmButtons/button.c
===
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmButtons/button.c,v
retrieving revision 1.40 diff -u -r1.40 button.c ---
modules/FvwmButtons/button.c 22 Feb 2009 21:24:48 - 1.40
+++
modules/FvwmButtons/button.c 23 Feb 2009 11:51:06 - @@ -489,6
+489,7
@@
/* needed to prevent a gcc -O3 bug */
volatile int old;
+ old = ub-c-allocated_buttons;
if(num=ub-c-allocated_buttons) { if(numold || old(old+32)) /* test
for numold or for signed overflow */
This indeed seems to work with the old config file.
... and hence I assume you can happily invoke FvwmButtons -g blah
SomeAlias?
Yes. I have undone the changes to my config file. I removed the
Geometry option and I've reverted to the -g parameter when
invoking the module. Previously, this caused the segfault, but
after patching FvwmButtons.c it now works.
I wonder however what triggered this problem. It has been working
for years without a problem and I don't see any recent reference
to FvwmButtons.c in the Changelog nor in the CHANGES file in the
FvwmButtons directory.
If the volatile variable wasn't correctly initialized maybe this
can be due to a recent glibc update and the way that the memory
is mapped now or something like that, I updated glibc some
days ago. It's the only thing I can think of.
--
Jesús Guerrero
FvwmButtons segfaults after updating (cvs)
Hello, Seen the last commits I updated today and it seems that something broke. I can't really offer much info besides my configuration file that I'll attach to this mail. The error look like this: Feb 23 01:03:00 jesgue kernel: FvwmButtons[17061]: segfault at 66b000 ip 0040d909 sp 73fcac30 error 4 in FvwmButtons[40+44000] The same configuration file worked without a problem previously. The strange thing is that if I launch the panel without specifying the geometry, then it works as expected (though of course the size and placement are not the desired ones). If I try via FvwmCommand, I can see that all the involved vars do have correct values. Yet the command still fails with a segfault. These commands: Echo $[panel_width]x$[panel_height]-$[panel_offset]-0 Module FvwmButtons -g $[panel_width]x$[panel_height]-$[panel_offset]-0 FvwmPanel Produce this output: [fvwm][Echo]: 1508x64-92-0 Feb 23 01:17:41 jesgue kernel: FvwmButtons[17540]: segfault at 66b000 ip 0040d909 sp 7fffb3d639c0 error 4 in FvwmButtons[40+44000] It's all the info I have for now. Let me know if I can help with additional info or something. I will continue trying to debug this. -- Jesús Guerrero config Description: Binary data
[PATCH]-Slight changelog fix
Today I noticed an error in a date. At least that's what the context seems to suggest since it's a 2006 in between a lot of 2008's. Patch attached. Cheers. -- Jesús Guerrero fvwm-changelog.diff Description: plain/text
[Fwd: Re: FVWM: multi-screen with different configs?]
El Mie, 4 de Febrero de 2009, 20:48, Ken Kwasnicki escribió: Hi all, I'm using fvwm 2.4.20. I have a single graphic card with TV out enabled. X is starting two displays, one on my primary screen, :0.0, and one on my TV, :0.1. So .xinitrc is run once and fvwm2 forks itself to run on the two different displays. [...] Is this possible? I've done this in the past. Look at the -s and -d switches. You can launch fvwm twice, one for each monitor from your ~/.xinitrc if you start X from command line. -- Jesús Guerrero -- Jesús Guerrero
Re: Reporting bug - window titles in UTF-8 environment incorrectly display character ì
On Wed, 05 Nov 2008 14:41:08 -0500 Dan Espen [EMAIL PROTECTED] wrote: Fvwm doesn't use GTK to display titles. The only use of GTK is in the FvwmGtk module. Have you read the Font and string encoding section of the fvwm2 man page? Yup. I think it's just a matter of correctly specifying the fonts. @Pavel Note however that there has been a longstanding bug related to this (that's why I and any non-elglish parlant have been using the DefaultCharset patch around for quite some years). So, be sure to use the latest fvwm version which works without this, and to read all the stuff about fonts and such. Make also sure that your font supports all the special characters (though I am sure you already did that). The gtk stuff is not related. You don't even need it at all to run fvwm. -- Jesús Guerrero [EMAIL PROTECTED] pgpQIGqFLCesB.pgp Description: PGP signature
Re: FVWM: Ban area for window placement
I've had such a setup with two screens (1600x1200 and 1204x768) for a long time and using fvwm. Never had a problem with it. so I suspect it's something to do with xorg not being configured correctly. Unless you didn't compile fvwm with proper xinerama support. Well, I was using nvidia's twinview, but that should be irrelevant. -- Jesús Guerrero [EMAIL PROTECTED] pgpa5tTkAYzzT.pgp Description: PGP signature
Re: FVWM: Ban area for window placement
On Wed, 5 Nov 2008 00:39:36 + Renato Caldas [EMAIL PROTECTED] wrote: On Tue, Nov 4, 2008 at 9:04 PM, Jesús Guerrero [EMAIL PROTECTED] wrote: I've had such a setup with two screens (1600x1200 and 1204x768) for a long time and using fvwm. Never had a problem with it. so I suspect it's something to do with xorg not being configured correctly. Unless you didn't compile fvwm with proper xinerama support. Well, I was using nvidia's twinview, but that should be irrelevant. It's not irrelevant. Nvidia twinview is not xinerama, it actually creates two X screens. I don't know what do you mean by two screens. But it's not like using dual head, it behaves and act by all means like xinerama (you can take one window from one monitor and drop it into the other monitor, and you can resize it so part of the window is on each monitor). Regards. -- Jesús Guerrero [EMAIL PROTECTED] pgpRmHRqUXXeh.pgp Description: PGP signature
Re: FVWM: Some items on a wish list
Hi, About png's Thomas already answered. I'll just add that is also supports svg on latest revisions. Check the man page for more info. On Wed, 6 Aug 2008 13:29:57 -0500 (CDT) [EMAIL PROTECTED] wrote: 2. For a laptop, there are such things as battery and temperature sensors. Fancy environments such as KDE have support for things like indicators for the battery. I wonder how hard it would be to provide this for fvwm? Actually, I conjecture that this would not require a deep dive into the code at all, but rather the hooking up of some already-existing program into a display icon something like the load indicator, which already has been done a long time ago. But I wonder if anyone has done this, or thought of it? I'll say a couple more of words about this. Fvwm is a window manager, and this is no the kind of functionality that a wm should have. IF you want everything working -almost- out of the box, use a Desktop instead. FvwmButtons is an interesting module that can swallow any application. Temperature metters, system tray applets, mail notification applets, clocks, etc. can be embedded simply into FvwmButtons, so, it looks a bit odd to me to hard code such features into fvwm itself. If you want it, add it into your config, that's how fvwm is and I doubt it will change. You can also use gkrellm and conky if you preffer monoliths instead of having a lot of small applets/metters running. -- Jesús Guerrero [EMAIL PROTECTED] pgp76Ru3CtsDb.pgp Description: PGP signature
Re: Padding on the menu separators, some preliminar thoughts
On Fri, 16 May 2008 09:34:56 +0200 Dominik Vogt [EMAIL PROTECTED] wrote: On Tue, May 13, 2008 at 11:25:28AM +0200, Jesús Guerrero wrote: Hello people, I write again about the VerticalSeparatorMargins patch. It's been long since I posted about it and there's been a new release, so maybe this is the right time to ask it. I don't mean to haste the thing or whatever, but I'd like some feedback on this (or just a forget about it would suffice as well). I just want to know if I should hold my breath about this or not. I reattach it for convenience. I'm watching this patch since you first posted it, and I'm still unsure what it is good for. *If* we add more options to configure separators it would be better to do it in a more general way. Perhaps similar to the horizontal item layout or by introducing some kind of separator style or whatever. But that is overkill in my eyes. Ciao Dominik ^_^ ^_^ -- Dominik Vogt Thanks for answering. I will think about that. Feel free to share any idea or something if you can. I wouldn't call this overkill. It's just another option, fvwm has loads of it, that's fvwm itself. But I suppose it's just about opinions. Cheers and thanks :) -- Jesús Guerrero [EMAIL PROTECTED]
Re: Padding on the menu separators, some preliminar thoughts
Hello people,
I write again about the VerticalSeparatorMargins patch. It's been long since I
posted about it and there's been a new release, so maybe this is the right time
to ask it.
I don't mean to haste the thing or whatever, but I'd like some feedback on this
(or just a forget about it would suffice as well). I just want to know if I
should hold my breath about this or not.
I reattach it for convenience.
Cheers.
--
Jesús Guerrero [EMAIL PROTECTED]
diff -U3 -r fvwm/fvwm/menus.c fvwm/fvwm/menus.c
--- fvwm/fvwm/menus.c 2008-03-18 13:17:40.0 +0100
+++ fvwm/fvwm/menus.c 2008-04-16 22:40:48.0 +0200
@@ -1644,7 +1644,8 @@
else if (MI_IS_SEPARATOR(mi))
{
/* Separator */
- MI_HEIGHT(mi) = separator_height;
+ MI_HEIGHT(mi) = separator_height +
+MST_VERTICAL_SEPARATOR_MARGIN_TOP(msp-menu);
}
else if (MI_IS_TEAR_OFF_BAR(mi))
{
@@ -1716,6 +1717,13 @@
}
}
y += MI_HEIGHT(mi);
+ /* Adds the separator magin below the current element
+ if it's a separator, but also if it's a title element,
+ not sure if this is always desiderable though...*/
+ if (MI_IS_SEPARATOR(mi) || MI_IS_TITLE(mi))
+ {
+ y += MST_VERTICAL_SEPARATOR_MARGIN_BOTTOM(msp-menu);
+ }
/* this item would have to be the last item, or else
* we need to add a More... entry pointing to a new menu */
menu_height =
diff -U3 -r fvwm/fvwm/menustyle.c fvwm/fvwm/menustyle.c
--- fvwm/fvwm/menustyle.c 2008-03-17 00:01:03.0 +0100
+++ fvwm/fvwm/menustyle.c 2008-04-16 21:20:47.0 +0200
@@ -427,7 +427,7 @@
TrianglesUseFore,
TitleColorset, HilightTitleBack,
TitleFont,
- VerticalMargins,
+ VerticalMargins, VerticalSeparatorMargins,
NULL
};
@@ -983,6 +983,8 @@
/* common settings */
ST_VERTICAL_MARGIN_TOP(tmpms) = 0;
ST_VERTICAL_MARGIN_BOTTOM(tmpms) = 0;
+ ST_VERTICAL_SEPARATOR_MARGIN_TOP(tmpms) = 0;
+ ST_VERTICAL_SEPARATOR_MARGIN_BOTTOM(tmpms) = 0;
ST_CSET_MENU(tmpms) = 0;
ST_HAS_MENU_CSET(tmpms) = 0;
ST_CSET_ACTIVE(tmpms) = 0;
@@ -1597,6 +1599,12 @@
ST_VERTICAL_MARGIN_BOTTOM(tmpms),
0, 0);
break;
+ case 63: /* VerticalSeparatorMargins */
+ parse_vertical_margins_line(
+args, ST_VERTICAL_SEPARATOR_MARGIN_TOP(tmpms),
+ST_VERTICAL_SEPARATOR_MARGIN_BOTTOM(tmpms),
+0, 0);
+ break;
#if 0
case 99: /* PositionHints */
@@ -1775,6 +1783,9 @@
/* VerticalMargins */
ST_VERTICAL_MARGIN_TOP(destms) = ST_VERTICAL_MARGIN_TOP(origms);
ST_VERTICAL_MARGIN_BOTTOM(destms) = ST_VERTICAL_MARGIN_BOTTOM(origms);
+ /* VerticalSeparatorMargins */
+ ST_VERTICAL_SEPARATOR_MARGIN_TOP(destms) = ST_VERTICAL_SEPARATOR_MARGIN_TOP(origms);
+ ST_VERTICAL_SEPARATOR_MARGIN_BOTTOM(destms) = ST_VERTICAL_SEPARATOR_MARGIN_BOTTOM(origms);
/* SidePic */
if (ST_SIDEPIC(destms))
diff -U3 -r fvwm/fvwm/menustyle.h fvwm/fvwm/menustyle.h
--- fvwm/fvwm/menustyle.h 2008-03-17 00:01:03.0 +0100
+++ fvwm/fvwm/menustyle.h 2008-04-16 21:17:06.0 +0200
@@ -177,6 +177,10 @@
#define MST_VERTICAL_MARGIN_TOP(m) ((m)-s-ms-look.vertical_margins.top)
#define ST_VERTICAL_MARGIN_BOTTOM(s) ((s)-look.vertical_margins.bottom)
#define MST_VERTICAL_MARGIN_BOTTOM(m) ((m)-s-ms-look.vertical_margins.bottom)
+#define ST_VERTICAL_SEPARATOR_MARGIN_TOP(s) ((s)-look.vertical_separator_margins.top)
+#define MST_VERTICAL_SEPARATOR_MARGIN_TOP(m)((m)-s-ms-look.vertical_separator_margins.top)
+#define ST_VERTICAL_SEPARATOR_MARGIN_BOTTOM(s) ((s)-look.vertical_separator_margins.bottom)
+#define MST_VERTICAL_SEPARATOR_MARGIN_BOTTOM(m) ((m)-s-ms-look.vertical_separator_margins.bottom)
/* type definitions --- */
@@ -299,6 +303,11 @@
} vertical_margins;
struct
{
+ unsigned char top;
+ unsigned char bottom;
+ } vertical_separator_margins;
+ struct
+ {
int menu;
int active;
int greyed;
Re: Some questions about dependencies
Hello, On Wed, 7 May 2008 20:19:13 +0100 Thomas Adam [EMAIL PROTECTED] wrote: 2008/5/7 Jesús Guerrero [EMAIL PROTECTED]: They are the following: # XXX: gtk2 perl bindings require dev-perl/gtk2-perl, worth a dependency? GTK2 isn't used anywhere in FVWM that I know of -- not even FvwmTabs uses it. Yes, in the core code of fvwm it doesn't appear for any purpose. But there's a Gtk2.pm module which is distributed with fvwm. I have no idea what is it for, but my guess is that you would need gtk2 to use those bindings, or whatever is contained in that perl module. # XXX: gtk perl bindings require dev-perl/gtk-perl, worth a dependency? Only in terms of FvwmGTK, but I don't think anyone uses it these days. I'm hoping it will get dropped at some point. FvwmDebug can use GTK, mind... I agree with you. I would just drop gtk, because anyway most distros are heading into that direction. Gtk+-1.x packages are getting rarer and rarer and most of them are not supported anymore upstream by their respective creators. # XXX: netpbm is used by FvwmScript-ScreenDump, worth a dependency? Yes, absolutely. Other programs beside FVWM will use this. Yep. I have no doubt about this one. I will either add this as a hard dependency or install it conditionally based on a USE flag. If the later case, if we use USE=netpbm the the dependency will be added. If we USE=-netpbm, the dependency on netpbm will be removed, and the scripts that rely on it (FvwmScript-ScreenDump only, as far as I know) would be removed from the installation as well (it would not work anyway). Thanks for all the input. It's very valuable. -- Jesús Guerrero [EMAIL PROTECTED]
Re: Some questions about dependencies
On Wed, 7 May 2008 21:31:59 +0200 (CEST) Viktor Griph [EMAIL PROTECTED] wrote: If you enable gtk, then fvwm looks for gtk+-1.x. If I am not mistaking, to make these bindings of any use, you would still need to push as dependencies gtk-perl and gtk2-perl respectively (whatever they are called on your distro of choice). Am I right? If I recall correctly the configure option about gtk only controls wether FvwmGtk will be built or not. The perl bindings are only runtime dependencies, when specific modules or parts of the perllib are used. Viktor, sorry to bother you again, but, do you know if FvwmGtk needs Gtk.pm by any chance? Thanks. -- Jesús Guerrero [EMAIL PROTECTED]
Fw: Re: Padding on the menu separators, some preliminar thoughts
Sorry, the attachment got rejected for a good reason, I re-send the message without the video attached, but with a couple of urls linking to my home server. http://jesgue.homelinux.org/other-files/out.ogv http://jesgue.homelinux.org/other-files/out-1.ogv Begin forwarded message: Date: Sat, 19 Apr 2008 00:46:34 +0200 From: Jesús Guerrero [EMAIL PROTECTED] To: fvwm-workers@fvwm.org Subject: Re: Padding on the menu separators, some preliminar thoughts I am attaching a small video capture showing how the menu looks with margins around the separators. This uses the VerticalMargins menustyle (already in CVS), and the new VerticalSeparatorMargins menustyle. It also features a modified version of FlatSeparators patch (which I will not attach for now, until I have any feedback on VerticalSeparatorMargins, because if VerticalSeparatorMargins changes, then I will have to re-do the FlatSeparators patch). Video attached. The relevant pieces are these: MenuStyle * SeparatorsShort, FlatSeparators MenuStyle * VerticalMargins 2 2 MenuStyle * VerticalSeparatorMargins 3 5 -- Jesús Guerrero [EMAIL PROTECTED] -- Jesús Guerrero [EMAIL PROTECTED]
Re: Padding on the menu separators, some preliminar thoughts
On Wed, 12 Mar 2008 01:38:04 +0100
Jesús Guerrero [EMAIL PROTECTED] wrote:
Hello, I quote my post about the separator margins that I wrote some
weeks ago. Just to bring it back to memory:
Hello, to quote myself, from the VerticalMargins menustyle thread:
I hope to sort the separators padding stuff as well. So, if this patch is
right, let me know your thoughts about that. But this is for another thread,
so I will open a new one.
So, I opened this new thread. My thoughts about this:
If the VerticalMargins command is not the right place for this, then
maybe a separate patch would do.
If you think that it shouldn't be into the VerticalMargins stuff, maybe
a new option would be right for that. Something like SeparatorMargins.
This would need that we think about it a bit. I definitely want to add
the possibility to have some padding around the separators because it
doesn't seem right as it's now when the element above or below a separator
is selected.
If we get a SeparatorMargins option, it could be used to specify the
margins not only above and below the separators, but also the margins
on the left and the right. That would send SeparatorsLong and
SeparatorsShort to the list of deprecated stuff (I never liked this
couple to tell the truth).
This would also add a greater degree of flexibility when defining
menu separators. I don't think that separators would be a thing to
write a thesis about, but well... We need the padding above and below,
and adding the configurability for the separators length wouldn't add
much complexity (I think, I haven't done any work on this yet).
I'd like some feedback.
Is this something that fvwm could use? I don't want to waste my time
making patches that will only be used by me unless I really need them.
If yes, is the SeparatorMargins approach correct?
If so, would it be SeparatorMargins l r t b correct? or maybe just
SeparatorMargins top bottom? In the first case, would it eventually
turn SeparatorsLong and SeparatorsShort deprecated?
I guess that if we want l t r b we will probably have some problems
with ItemFormat, wouldn't we?
Since I did not receive any feedback, I took the easy way, and implemented
yet one more option for this. I'd like to know what do you think about it
and if it's a wanted feature on fvwm or not.
The patch is small enough and easy to understand. (Attached).
It adds the VerticalSeparatorMargins option (two arguments, much like
VerticalSeparators). The first one is the gap above the separators, the
second one is the gap below.
Both have a maximum value that is equal to MAX_MENU_MARGIN, no wonder, since
the function I use to parse the arguments is the same function that I used
on the VerticalMargins patch (I found really no reason to duplicate the code,
since both elements have exactly the same nature and the same function can
do the work). Just to refresh your minds, it's called
parse_vertical_margins_line()
The patch does a check around line ~1600 on menus.c which is used to determine
if the item we just procesed was a separator. In that case, the gap below is
added to y. The check also does that if the element is a title... It's
commented in the code. I don't feel that's right, maybe I should also add
another option to add a gap *after* the title underline(s).
My idea, as I explained in any other occasion, is being able to have a visible
separation between the selected menuitem and the separation lines (separators
or title underslines, it's the same). Because otherwise, it looks way too
cluttered.
I don't know if the current approach is right. Ideas are welcome.
Thanks everyone for reading.
--
Jesús Guerrero [EMAIL PROTECTED]
diff -U3 -r fvwm/fvwm/menus.c fvwm/fvwm/menus.c
--- fvwm/fvwm/menus.c 2008-03-18 13:17:40.0 +0100
+++ fvwm/fvwm/menus.c 2008-04-16 22:40:48.0 +0200
@@ -1644,7 +1644,8 @@
else if (MI_IS_SEPARATOR(mi))
{
/* Separator */
- MI_HEIGHT(mi) = separator_height;
+ MI_HEIGHT(mi) = separator_height +
+MST_VERTICAL_SEPARATOR_MARGIN_TOP(msp-menu);
}
else if (MI_IS_TEAR_OFF_BAR(mi))
{
@@ -1716,6 +1717,13 @@
}
}
y += MI_HEIGHT(mi);
+ /* Adds the separator magin below the current element
+ if it's a separator, but also if it's a title element,
+ not sure if this is always desiderable though...*/
+ if (MI_IS_SEPARATOR(mi) || MI_IS_TITLE(mi))
+ {
+ y += MST_VERTICAL_SEPARATOR_MARGIN_BOTTOM(msp-menu);
+ }
/* this item would have to be the last item, or else
* we need to add a More... entry pointing to a new menu */
menu_height =
diff -U3 -r fvwm/fvwm/menustyle.c fvwm/fvwm/menustyle.c
--- fvwm/fvwm/menustyle.c 2008-03-17 00:01:03.0 +0100
+++ fvwm/fvwm/menustyle.c 2008-04-16 21:20:47.0 +0200
@@ -427,7 +427,7 @@
TrianglesUseFore,
TitleColorset, HilightTitleBack,
TitleFont,
- VerticalMargins,
+ VerticalMargins, VerticalSeparatorMargins,
NULL
};
@@ -983,6 +983,8 @@
/* common settings
FVWM: xinerama and $[vp.width]
Hello, I am using things like $[vp.width]/10 on my config (to calculeta the ButtonSize for one FvwmButtons), all is nice except when I use xinerama, because then the total width of the viewport is obtained -logically- summing the widths of the two monitors. Is there any way to get the dimensions of one monitor only? I am looking for a portable setup that can work with or without xinerama, and the monitors might be of equal or different size. That's the main problem :P -- Jesús Guerrero [EMAIL PROTECTED]
Re: FVWM: xinerama and $[vp.width]
On Fri, 11 Apr 2008 13:12:02 -0400 (EDT) Eben King [EMAIL PROTECTED] wrote: On Fri, 11 Apr 2008, Jesús Guerrero wrote: I am using things like $[vp.width]/10 on my config (to calculeta the ButtonSize for one FvwmButtons), all is nice except when I use xinerama, because then the total width of the viewport is obtained -logically- summing the widths of the two monitors. Is there any way to get the dimensions of one monitor only? I am looking for a portable setup that can work with or without xinerama, and the monitors might be of equal or different size. That's the main problem :P How about if instead of width/10 you use height/7.5? It's a pragmatic approach... -- -eben [EMAIL PROTECTED] royalty.mine.nu:81 Your pretended fear lest error might step in is like the man who would keep all wine out of the country lest men should be drunk. -- Oliver Cromwell As I said, it must work in many circumstances. The pragmatic approach would require the edition of the config file each time I switch monitors or the X layout, which is what I intend to avoid. -- Jesús Guerrero [EMAIL PROTECTED]
Re: FVWM: backing windows off currentpage
On Wed, 19 Mar 2008 15:17:30 + Thomas Adam [EMAIL PROTECTED] wrote: On 19/03/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: It seems that FVWM does not back windows which are on some non-CurrentPage. If I run xwd -id $someWindowNotOnCurrentPage the image comes out as completely black. I would request that FVWM exposes a configuration option that would keep windows backed in memory such that programs like xwd produce a usuable result even when they aren't on the current page. Perhaps it would be nice to have this feature be both a global tri-state (off, on for current desk, on for all desks), as well as a per-window option toggleable via Style or Pick type actions. But the window on $SOMEOTHERPAGEORDESK is unmapped, so of course it will come out blank, unless you switch to that page first. -- Thomas Adam I think he means caching a bitmap of that window from the last time that it was mapped, until it's mapped again. However, if fvwm did that, then it's an fvwm thing, and I don't think that xwd looks into fvwm structs to rescue bitmaps. This is an X thing, not an fvwm ones. Or maybe I misunderstood something. -- Jesús Guerrero [EMAIL PROTECTED]
Re: New Menustyle: VerticalMargins, is there any interest on it?
On Tue, 11 Mar 2008 14:12:48 +0100
Dominik Vogt [EMAIL PROTECTED] wrote:
On Tue, Mar 11, 2008 at 07:31:40AM +0100, Jesús Guerrero wrote:
Hello,
I made a new patch which solves one of the longstanding issues I had
with my fvwm menus. It's not that it's something important, but it
was a small annoyance.
... and where is the patch?
Well, I will attach it to this mail. But, as I said, it's not a finished
product. That's why I didn't include it on the first post, but since you
asked... It basically works, but I need to test it extensively to make
sure that nothing strange happens. At the current state, it only support
the top and bottom margins. I will implement margins around separators
probably later today if I can.
The docs and stuff is not done. I don't want to waste my time documenting
it if it's never going to be merged and I am the only one using it. But
I will gladly make the docs and test stuff if you think that this would
be a good addition for fvwm.
The patch works as follows:
MenuStyle * VerticalMargins x y
Where x is the top margin and y is the bottom one. As said, margins around
separators are still not implemented, though I think they would be a good
addition. The separator lines are just next the the selection area, and
that makes them look really bad.
Thanks for your time.
--
Jesús Guerrero [EMAIL PROTECTED]
diff -r -U5 fvwm/fvwm/menuitem.c fvwm/fvwm/menuitem.c
--- fvwm/fvwm/menuitem.c 2008-03-10 22:26:15.0 +0100
+++ fvwm/fvwm/menuitem.c 2008-03-10 21:49:15.0 +0100
@@ -388,10 +388,11 @@
Region region = None;
int i;
int sx1;
int sx2;
FlocaleFont* font;
+ int top_margin = ST_VERTICAL_MARGIN_TOP(ms);
if (!mi)
{
return;
}
@@ -404,11 +405,11 @@
else
{
font = ST_PSTDFONT(ms);
}
- y_offset = MI_Y_OFFSET(mi);
+ y_offset = MI_Y_OFFSET(mi) + ST_VERTICAL_MARGIN_TOP(ms);
y_height = MI_HEIGHT(mi);
if (MI_IS_SELECTABLE(mi))
{
text_y = y_offset + MDIM_ITEM_TEXT_Y_OFFSET(*dim);
}
diff -r -U5 fvwm/fvwm/menus.c fvwm/fvwm/menus.c
--- fvwm/fvwm/menus.c 2008-03-10 22:26:30.0 +0100
+++ fvwm/fvwm/menus.c 2008-03-10 21:23:52.0 +0100
@@ -126,10 +126,12 @@
} max;
struct
{
unsigned is_popup_indicator_used : 1;
} flags;
+ unsigned char top_margin;
+ unsigned char bottom_margin;
} MenuSizingParameters;
typedef enum
{
SCTX_MENU_ROOT,
@@ -1796,11 +1798,13 @@
if (MR_LAST_ITEM(msp-menu) != NULL
MI_IS_SELECTABLE(MR_LAST_ITEM(msp-menu)))
{
y += relief_thickness;
}
- MR_HEIGHT(msp-menu) = y + MST_BORDER_WIDTH(msp-menu);
+ MR_HEIGHT(msp-menu) = y + MST_BORDER_WIDTH(msp-menu)
+ + MST_VERTICAL_MARGIN_TOP(msp-menu)
+ + MST_VERTICAL_MARGIN_BOTTOM(msp-menu);
return has_continuation_menu;
}
/*
diff -r -U5 fvwm/fvwm/menustyle.c fvwm/fvwm/menustyle.c
--- fvwm/fvwm/menustyle.c 2008-03-10 22:26:34.0 +0100
+++ fvwm/fvwm/menustyle.c 2008-03-10 22:14:22.0 +0100
@@ -303,10 +303,31 @@
*below = val[1];
return;
}
+static void parse_vertical_margins_line(
+ char *args, signed char *top, signed char *bottom,
+ signed char top_default, signed char bottom_default)
+{
+ int val[2];
+
+ if (GetIntegerArguments(args, NULL, val, 2) != 2 ||
+ val[0] MIN_VERTICAL_SPACING || val[0] MAX_VERTICAL_SPACING ||
+ val[1] MIN_VERTICAL_SPACING || val[1] MAX_VERTICAL_SPACING)
+ {
+ /* illegal or missing parameters, return to default */
+ *top = top_default;
+ *bottom = bottom_default;
+ return;
+ }
+ *top = val[0];
+ *bottom = val[1];
+
+ return;
+}
+
static MenuStyle *menustyle_parse_old_style(F_CMD_ARGS)
{
char *buffer, *rest;
char *fore, *back, *stipple, *font, *style, *animated;
MenuStyle *ms = NULL;
@@ -404,10 +425,11 @@
PopupIgnore, PopupClose,
MouseWheel, ScrollOffPage,
TrianglesUseFore,
TitleColorset, HilightTitleBack,
TitleFont,
+ VerticalMargins,
NULL
};
return GetTokenIndex(option, optlist, 0, NULL);
}
@@ -906,11 +928,11 @@
while (poption[0] == '!')
{
on ^= 1;
poption++;
}
- switch((i = menustyle_get_styleopt_index(poption)))
+ switch(i = menustyle_get_styleopt_index(poption))
{
case 0: /* fvwm */
case 1: /* mwm */
case 2: /* win */
if (i == 0)
@@ -957,10 +979,12 @@
ST_DO_HILIGHT_BACK(tmpms) = 1;
ST_DO_HILIGHT_FORE(tmpms) = 1;
}
/* common settings */
+ ST_VERTICAL_MARGIN_TOP(tmpms) = 0;
+ ST_VERTICAL_MARGIN_BOTTOM(tmpms) = 0;
ST_CSET_MENU(tmpms) = 0;
ST_HAS_MENU_CSET(tmpms) = 0;
ST_CSET_ACTIVE(tmpms) = 0;
ST_HAS_ACTIVE_CSET(tmpms) = 0;
ST_CSET_GREYED(tmpms) = 0;
@@ -1565,11 +1589,16 @@
ST_PTITLEFONT(tmpms) = new_font;
ST_USING_DEFAULT_TITLEFONT(tmpms) = False;
}
has_gc_changed = True;
break;
-
+ case 62: /* VerticalMargins */
+ parse_vertical_margins_line(
+args, ST_VERTICAL_MARGIN_TOP(tmpms),
+ST_VERTICAL_MARGIN_BOTTOM(tmpms),
+0, 0);
+ break;
#if 0
case 99: /* PositionHints */
/* to be implemented
Re: New Menustyle: VerticalMargins, is there any interest on it?
On Tue, 11 Mar 2008 14:22:19 +0100 (CET) Viktor Griph [EMAIL PROTECTED] wrote: On Tue, 11 Mar 2008, Dominik Vogt wrote: On Tue, Mar 11, 2008 at 07:31:40AM +0100, Jesús Guerrero wrote: MenuStyle * VerticalMargins 2 3 This defines a margin of 2pix from the top border of the menu, and 3pix on the bottom. In my opinion, this improves the look of the menu when you have selected the last/first item. I attach a picture with some notes on it so you can compare. [...] Ah, I see. It may (or may not) be good to have a similar syntax like for the horizontal menu layout, although there probably isn't much to configure. That would add nothing that can't already be configured by tweaking the ItemFormat. /Viktor Correct me if I am wrong, but ItemFormat can only handle horizontal layout, not vertical. And VerticalItemSpacing can't define this either. As far as I know, there's no way to achieve what this patch achieves using the current vanilla fvwm. I'd be glad to be wrong, though. -- Jesús Guerrero [EMAIL PROTECTED]
Re: New Menustyle: VerticalMargins, is there any interest on it?
On Tue, 11 Mar 2008 16:10:42 +0100 Dominik Vogt [EMAIL PROTECTED] wrote: MAX_VERTICAL_SPACING and MIN_VERTICAL_SPACING are not defined in the patch. Anyway, MIN_VERTICAL_SPACING should be just 0 and MAX_VERTICAL_SPACING the same value that is used for MAX_MENU_BORDER_WIDTH. Ah, these values are already defined. It's better to use a new constant MAX_MENU_MARGIN (in libs/defaults.h). Yes. I set it to 50, same value that MAX_MENU_BORDER_WIDTH as you suggested. @Victor: I wanted to say that it might make sense to have a style similar to ItemFormat for the vertical layout too. I would probably be able to implement this that way if you really think it's better. The obvious benefits are: 1.- consistency 2.- leave the doors open to implement options to align the text vertically (I don't know how much could it take me to implement that, maybe it's trivial, I'll have to look). If you prefer it that way, let me know and I'll try to do my best. Thanks so much for all the input, it's much appreciated. -- Jesús Guerrero [EMAIL PROTECTED]
Re: New Menustyle: VerticalMargins, is there any interest on it?
On Tue, 11 Mar 2008 16:03:37 +0100
Dominik Vogt [EMAIL PROTECTED] wrote:
[snip]
See comments below.
Thanks for the extensive comments. I think it's all sorted now.
Most of the fvwm source is pretty new to me and sometimes it's hard
to find the way around. Your guidance has been helpful. If you feel
that something needs some polishing just tell me so and I will
investigate when I have the time and try to find the right way
to do the things.
diff -r -U5 fvwm/fvwm/menuitem.c fvwm/fvwm/menuitem.c
--- fvwm/fvwm/menuitem.c2008-03-10 22:26:15.0 +0100
+++ fvwm/fvwm/menuitem.c2008-03-10 21:49:15.0 +0100
@@ -388,10 +388,11 @@
Region region = None;
int i;
int sx1;
int sx2;
FlocaleFont* font;
+ int top_margin = ST_VERTICAL_MARGIN_TOP(ms);
I don't like initializing variables in the declaration. If you
had compiled with -Wall -Werror you would have noticed that this
variable is not used at all. Please remove it.
if (!mi)
{
return;
}
@@ -404,11 +405,11 @@
else
{
font = ST_PSTDFONT(ms);
}
- y_offset = MI_Y_OFFSET(mi);
+ y_offset = MI_Y_OFFSET(mi) + ST_VERTICAL_MARGIN_TOP(ms);
This is not good. The vertical margin must be added when the
MI_Y_OFFSET is set in the first place. There may be other places
that rely on this value.
I moved it to menus.c. It now shold be ok for all cases.
The rest was just simple stuff that I overlooked or that needed some
cleaning.
New patch attached. If this is ok, do you agree to add a 3rd parameter
to add margins above AND below the separators?
--
Jesús Guerrero [EMAIL PROTECTED]
diff -r -U5 fvwm/fvwm/menus.c fvwm/fvwm/menus.c
--- fvwm/fvwm/menus.c 2008-03-11 17:09:42.0 +0100
+++ fvwm/fvwm/menus.c 2008-03-11 18:02:52.0 +0100
@@ -1601,11 +1603,11 @@
int separator_height;
separator_height = (last_item_has_relief) ?
MENU_SEPARATOR_HEIGHT + relief_thickness :
MENU_SEPARATOR_TOTAL_HEIGHT;
- MI_Y_OFFSET(mi) = y;
+ MI_Y_OFFSET(mi) = y + MST_VERTICAL_MARGIN_BOTTOM(msp-menu);
if (MI_IS_TITLE(mi))
{
MI_HEIGHT(mi) = MST_PTITLEFONT(msp-menu)-height +
MST_TITLE_GAP_ABOVE(msp-menu) +
MST_TITLE_GAP_BELOW(msp-menu);
@@ -1796,11 +1798,13 @@
if (MR_LAST_ITEM(msp-menu) != NULL
MI_IS_SELECTABLE(MR_LAST_ITEM(msp-menu)))
{
y += relief_thickness;
}
- MR_HEIGHT(msp-menu) = y + MST_BORDER_WIDTH(msp-menu);
+ MR_HEIGHT(msp-menu) = y + MST_BORDER_WIDTH(msp-menu)
+ + MST_VERTICAL_MARGIN_TOP(msp-menu)
+ + MST_VERTICAL_MARGIN_BOTTOM(msp-menu);
return has_continuation_menu;
}
/*
diff -r -U5 fvwm/fvwm/menustyle.c fvwm/fvwm/menustyle.c
--- fvwm/fvwm/menustyle.c 2008-03-11 17:09:44.0 +0100
+++ fvwm/fvwm/menustyle.c 2008-03-11 16:23:16.0 +0100
@@ -303,10 +303,31 @@
*below = val[1];
return;
}
+static void parse_vertical_margins_line(
+ char *args, signed char *top, signed char *bottom,
+ signed char top_default, signed char bottom_default)
+{
+ int val[2];
+
+ if (GetIntegerArguments(args, NULL, val, 2) != 2 ||
+ val[0] 0 || val[0] MAX_MENU_MARGIN ||
+ val[1] 0 || val[1] MAX_MENU_MARGIN)
+ {
+ /* illegal or missing parameters, return to default */
+ *top = top_default;
+ *bottom = bottom_default;
+ return;
+ }
+ *top = val[0];
+ *bottom = val[1];
+
+ return;
+}
+
static MenuStyle *menustyle_parse_old_style(F_CMD_ARGS)
{
char *buffer, *rest;
char *fore, *back, *stipple, *font, *style, *animated;
MenuStyle *ms = NULL;
@@ -404,10 +425,11 @@
PopupIgnore, PopupClose,
MouseWheel, ScrollOffPage,
TrianglesUseFore,
TitleColorset, HilightTitleBack,
TitleFont,
+ VerticalMargins,
NULL
};
return GetTokenIndex(option, optlist, 0, NULL);
}
@@ -957,10 +979,12 @@
ST_DO_HILIGHT_BACK(tmpms) = 1;
ST_DO_HILIGHT_FORE(tmpms) = 1;
}
/* common settings */
+ ST_VERTICAL_MARGIN_TOP(tmpms) = 0;
+ ST_VERTICAL_MARGIN_BOTTOM(tmpms) = 0;
ST_CSET_MENU(tmpms) = 0;
ST_HAS_MENU_CSET(tmpms) = 0;
ST_CSET_ACTIVE(tmpms) = 0;
ST_HAS_ACTIVE_CSET(tmpms) = 0;
ST_CSET_GREYED(tmpms) = 0;
@@ -1565,11 +1589,16 @@
ST_PTITLEFONT(tmpms) = new_font;
ST_USING_DEFAULT_TITLEFONT(tmpms) = False;
}
has_gc_changed = True;
break;
-
+ case 62: /* VerticalMargins */
+ parse_vertical_margins_line(
+args, ST_VERTICAL_MARGIN_TOP(tmpms),
+ST_VERTICAL_MARGIN_BOTTOM(tmpms),
+0, 0);
+ break;
#if 0
case 99: /* PositionHints */
/* to be implemented */
break;
@@ -1741,10 +1770,13 @@
ST_HAS_TRIANGLE_RELIEF(destms) = ST_HAS_TRIANGLE_RELIEF(origms);
/* PopupDelayed */
ST_DO_POPUP_IMMEDIATELY(destms) = ST_DO_POPUP_IMMEDIATELY(origms);
/* DoubleClickTime */
ST_DOUBLE_CLICK_TIME(destms) = ST_DOUBLE_CLICK_TIME(origms);
+ /* VerticalMargins */
+ ST_VERTICAL_MARGIN_TOP(destms) = ST_VERTICAL_MARGIN_TOP(origms);
+ ST_VERTICAL_MARGIN_BOTTOM(destms) = ST_VERTICAL_MARGIN_BOTTOM(origms
Re: New Menustyle: VerticalMargins, is there any interest on it?
Hi again,
I attach an updated version of the patch, with test cases, docs, Changelog
and NEWS included. I hope everything is correct. If not, just let me know.
I hope to sort the separators padding stuff as well. So, if this patch is
right, let me know your thoughts about that. But this is for another thread,
so I will open a new one.
Thanks again.
--
Jesús Guerrero [EMAIL PROTECTED]
diff -r -U5 fvwm/fvwm/menus.c fvwm/fvwm/menus.c
--- fvwm/fvwm/menus.c 2008-03-11 17:09:42.0 +0100
+++ fvwm/fvwm/menus.c 2008-03-11 18:02:52.0 +0100
@@ -1601,11 +1603,11 @@
int separator_height;
separator_height = (last_item_has_relief) ?
MENU_SEPARATOR_HEIGHT + relief_thickness :
MENU_SEPARATOR_TOTAL_HEIGHT;
- MI_Y_OFFSET(mi) = y;
+ MI_Y_OFFSET(mi) = y + MST_VERTICAL_MARGIN_TOP(msp-menu);
if (MI_IS_TITLE(mi))
{
MI_HEIGHT(mi) = MST_PTITLEFONT(msp-menu)-height +
MST_TITLE_GAP_ABOVE(msp-menu) +
MST_TITLE_GAP_BELOW(msp-menu);
@@ -1796,11 +1798,13 @@
if (MR_LAST_ITEM(msp-menu) != NULL
MI_IS_SELECTABLE(MR_LAST_ITEM(msp-menu)))
{
y += relief_thickness;
}
- MR_HEIGHT(msp-menu) = y + MST_BORDER_WIDTH(msp-menu);
+ MR_HEIGHT(msp-menu) = y + MST_BORDER_WIDTH(msp-menu)
+ + MST_VERTICAL_MARGIN_TOP(msp-menu)
+ + MST_VERTICAL_MARGIN_BOTTOM(msp-menu);
return has_continuation_menu;
}
/*
diff -r -U5 fvwm/fvwm/menustyle.c fvwm/fvwm/menustyle.c
--- fvwm/fvwm/menustyle.c 2008-03-11 17:09:44.0 +0100
+++ fvwm/fvwm/menustyle.c 2008-03-11 16:23:16.0 +0100
@@ -303,10 +303,31 @@
*below = val[1];
return;
}
+static void parse_vertical_margins_line(
+ char *args, signed char *top, signed char *bottom,
+ signed char top_default, signed char bottom_default)
+{
+ int val[2];
+
+ if (GetIntegerArguments(args, NULL, val, 2) != 2 ||
+ val[0] 0 || val[0] MAX_MENU_MARGIN ||
+ val[1] 0 || val[1] MAX_MENU_MARGIN)
+ {
+ /* illegal or missing parameters, return to default */
+ *top = top_default;
+ *bottom = bottom_default;
+ return;
+ }
+ *top = val[0];
+ *bottom = val[1];
+
+ return;
+}
+
static MenuStyle *menustyle_parse_old_style(F_CMD_ARGS)
{
char *buffer, *rest;
char *fore, *back, *stipple, *font, *style, *animated;
MenuStyle *ms = NULL;
@@ -404,10 +425,11 @@
PopupIgnore, PopupClose,
MouseWheel, ScrollOffPage,
TrianglesUseFore,
TitleColorset, HilightTitleBack,
TitleFont,
+ VerticalMargins,
NULL
};
return GetTokenIndex(option, optlist, 0, NULL);
}
@@ -957,10 +979,12 @@
ST_DO_HILIGHT_BACK(tmpms) = 1;
ST_DO_HILIGHT_FORE(tmpms) = 1;
}
/* common settings */
+ ST_VERTICAL_MARGIN_TOP(tmpms) = 0;
+ ST_VERTICAL_MARGIN_BOTTOM(tmpms) = 0;
ST_CSET_MENU(tmpms) = 0;
ST_HAS_MENU_CSET(tmpms) = 0;
ST_CSET_ACTIVE(tmpms) = 0;
ST_HAS_ACTIVE_CSET(tmpms) = 0;
ST_CSET_GREYED(tmpms) = 0;
@@ -1565,11 +1589,16 @@
ST_PTITLEFONT(tmpms) = new_font;
ST_USING_DEFAULT_TITLEFONT(tmpms) = False;
}
has_gc_changed = True;
break;
-
+ case 62: /* VerticalMargins */
+ parse_vertical_margins_line(
+args, ST_VERTICAL_MARGIN_TOP(tmpms),
+ST_VERTICAL_MARGIN_BOTTOM(tmpms),
+0, 0);
+ break;
#if 0
case 99: /* PositionHints */
/* to be implemented */
break;
@@ -1741,10 +1770,13 @@
ST_HAS_TRIANGLE_RELIEF(destms) = ST_HAS_TRIANGLE_RELIEF(origms);
/* PopupDelayed */
ST_DO_POPUP_IMMEDIATELY(destms) = ST_DO_POPUP_IMMEDIATELY(origms);
/* DoubleClickTime */
ST_DOUBLE_CLICK_TIME(destms) = ST_DOUBLE_CLICK_TIME(origms);
+ /* VerticalMargins */
+ ST_VERTICAL_MARGIN_TOP(destms) = ST_VERTICAL_MARGIN_TOP(origms);
+ ST_VERTICAL_MARGIN_BOTTOM(destms) = ST_VERTICAL_MARGIN_BOTTOM(origms);
/* SidePic */
if (ST_SIDEPIC(destms))
{
PDestroyFvwmPicture(dpy, ST_SIDEPIC(destms));
diff -r -U5 fvwm/fvwm/menustyle.h fvwm/fvwm/menustyle.h
--- fvwm/fvwm/menustyle.h 2008-03-11 17:09:44.0 +0100
+++ fvwm/fvwm/menustyle.h 2008-03-11 16:13:20.0 +0100
@@ -171,10 +171,14 @@
#define MST_DOUBLE_CLICK_TIME(m) ((m)-s-ms-feel.DoubleClickTime)
#define ST_ITEM_FORMAT(s) ((s)-feel.item_format)
#define MST_ITEM_FORMAT(m)((m)-s-ms-feel.item_format)
#define ST_SELECT_ON_RELEASE_KEY(s) ((s)-feel.select_on_release_key)
#define MST_SELECT_ON_RELEASE_KEY(m) ((m)-s-ms-feel.select_on_release_key)
+#define ST_VERTICAL_MARGIN_TOP(s) ((s)-look.vertical_margins.top)
+#define MST_VERTICAL_MARGIN_TOP(m) ((m)-s-ms-look.vertical_margins.top)
+#define ST_VERTICAL_MARGIN_BOTTOM(s) ((s)-look.vertical_margins.bottom)
+#define MST_VERTICAL_MARGIN_BOTTOM(m) ((m)-s-ms-look.vertical_margins.bottom)
/* type definitions --- */
typedef enum
{
@@ -288,10 +292,15 @@
signed char separator_above;
signed char separator_below;
} vertical_spacing;
struct
{
+ unsigned char top;
+ unsigned char bottom;
+ } vertical_margins;
+ struct
+ {
int menu;
int active;
int greyed;
int
Padding on the menu separators, some preliminar thoughts
Hello, to quote myself, from the VerticalMargins menustyle thread: I hope to sort the separators padding stuff as well. So, if this patch is right, let me know your thoughts about that. But this is for another thread, so I will open a new one. So, I opened this new thread. My thoughts about this: If the VerticalMargins command is not the right place for this, then maybe a separate patch would do. If you think that it shouldn't be into the VerticalMargins stuff, maybe a new option would be right for that. Something like SeparatorMargins. This would need that we think about it a bit. I definitely want to add the possibility to have some padding around the separators because it doesn't seem right as it's now when the element above or below a separator is selected. If we get a SeparatorMargins option, it could be used to specify the margins not only above and below the separators, but also the margins on the left and the right. That would send SeparatorsLong and SeparatorsShort to the list of deprecated stuff (I never liked this couple to tell the truth). This would also add a greater degree of flexibility when defining menu separators. I don't think that separators would be a thing to write a thesis about, but well... We need the padding above and below, and adding the configurability for the separators length wouldn't add much complexity (I think, I haven't done any work on this yet). I'd like some feedback. Is this something that fvwm could use? I don't want to waste my time making patches that will only be used by me unless I really need them. If yes, is the SeparatorMargins approach correct? If so, would it be SeparatorMargins l r t b correct? or maybe just SeparatorMargins top bottom? In the first case, would it eventually turn SeparatorsLong and SeparatorsShort deprecated? I guess that if we want l t r b we will probably have some problems with ItemFormat, wouldn't we? I'll better get some sleep for now :P Those are just some ideas and doubts that I have about how to implement this. -- Jesús Guerrero [EMAIL PROTECTED]
Re: bug: hilight gradient position in menu
On Sun, 9 Mar 2008 17:16:21 +0100 Dominik Vogt [EMAIL PROTECTED] wrote: Fixed. Thanks. The gradients now display as they should. :) -- Jesús Guerrero [EMAIL PROTECTED]
Re: WAS fvwm and patches
On Fri, 7 Mar 2008 13:49:30 +0100 Dominik Vogt [EMAIL PROTECTED] wrote: On Fri, Mar 07, 2008 at 12:39:54PM +0100, Jesús Guerrero wrote: On Fri, 7 Mar 2008 06:55:39 +0100 Jesús Guerrero [EMAIL PROTECTED] wrote: On Fri, 7 Mar 2008 00:44:09 +0100 Jesús Guerrero [EMAIL PROTECTED] wrote: Attached: Style InactiveFont patch [...] Isn't this already possible to do with TitleStyle? I don't think so. TitleStyle can't be used to change fonts I think. The purpose of this patch is to be able to use a different font for focused and non-focused windows. For example: to use a standard font for inactive windows, and the same font but bold for the active one. Correct me if I am wrong, but I don't think that TitleStyle can do that. I'd be glad to be wrong. One less patch needed. Regards. -- Jesús Guerrero [EMAIL PROTECTED]
Re: WAS fvwm and patches
On Fri, 7 Mar 2008 06:55:39 +0100 Jesús Guerrero [EMAIL PROTECTED] wrote: On Fri, 7 Mar 2008 00:44:09 +0100 Jesús Guerrero [EMAIL PROTECTED] wrote: Attached: Style InactiveFont patch -- Jesús Guerrero [EMAIL PROTECTED] This patch has some serious problem. It segfaults for me when restarting the wm, but only if there are windows open. The fvwm modules and urxvtc seems to work ok. But if I have firefox, sylpheed, kcalc or any other thing open, it segfaults when restarting. The last thing I can see is the window title and borders being redrawn with the grey default decoration. And with fixed font. I tried gdb but it freezes when it reaches that point. So, it's not of so much help. I have to investigate a bit more. -- Jesús Guerrero [EMAIL PROTECTED]
Re: FVWM: fvwm and patches
On Thu, 6 Mar 2008 22:38:08 +0100 (CET) Viktor Griph [EMAIL PROTECTED] wrote: On Thu, 6 Mar 2008, Ingo Wardinski wrote: I'm sure there are profound reasons not to include such features as menutranslucency, topborder, inactivefont, round corners , etc. into fvwm. Which are these?? In most cases the patches have not been submitted to the fvwm-workers list, and in the cases where they have they mostly lack proper documentation of the features. Also some patches add stuff without adding configuration options to control their behaviour. Most of the patches I know, do have an option to control their behaviour, and they shouldn't interfere with anything, unless you explicitly activate them using the config options. There are a few exceptions, so I will review the patches I know of, and probably, submit a list or something like that later. Appart from that patches require quite some proof reading and some patches tend to be relatively large. I've personally checked on the menu translucency patch a while back, and I think it is mature enough for inclusion. But it lacks documentation, and still has to be checked against the latest CVS to see that there haven't come any new issues since I last checked and updated the patch. This is in Gentoo since the patch was created, and it continues to work ok with both the official releases and the cvs builds. I just checked it, and the patch in my fvwm cvs ebuild for gentoo, and the official tree, are different. The .21 patch in Gentoo, doesn't apply on CVS. The patch I host in my patchset do work. I think it was modified by someone in this list, but I don't really remember. (It wasn't me, that's for sure a good thing). I attach it to this mail in case you need it. I don't know of the state of any other patches. I know that there are some patches that have been sent to the workers list, wich I intend to take a look at once I get a little more time. But I believe that most of the patches that are included with the Gentoo live ebuild have never been submitted to the workers list. I maintain that patchset and the unofficial .23, .24, .25 and cvs ebuilds that can be found in the devnull overlay, and in bugs.gentoo.org. Most of the patches there are from here: http://abdn.ac.uk/~u15dm4/fvwm/ There's also the translucency one, and besides that, there are a couple more that I wouldn't worry about, since they are deliberately hackhish even to my inexpert eye (and they provide no config option, they are irreversible). Besides that, there's also the patch from Thomas Adam to change the colors for each border separately. But I modified that patch, so, it is not the same patch from Thomas, and no one should bother him about that patch I modified. The whole patchset can be found at: http://jesgue.homelinux.org/fvwm-files/fvwm-patchset-20070901.tar.bz2 I don't really use these patches. The only thing I can say is that they apply cleanly. Those patches were taken originally from the link above. But some of them have been heavily modified by me (again, AKA not-a-good-thing) on successive updates because they wouldn't apply. Right now, the original author seems to provide updated patches on his page. I don't know if these are reworked, or if they are taken from my patchset (I highly doubt it). In the next few days I will try to compare them and make some checks. The real problem now to start with, is that there are lots of patches, from lots of sources. The first thing if we want to include anything into fvwm, is to identify what of them are realistic candidates, and which ones are cleaner and tidier. That's just my 2 cents, for what it's worth. -- Jesús Guerrero [EMAIL PROTECTED]
Re: bug: hilight gradient position in menu
On Thu, 6 Mar 2008 09:10:48 +0100 Dominik Vogt [EMAIL PROTECTED] wrote: On Thu, Mar 06, 2008 at 06:29:20AM +0100, Jesús Guerrero wrote: Hello, This problem has been around for some time, though I just ignored it silently. I made a small video (a few secs, 1,4mb or so). http://jesgue.homelinux.org/other-files/out-1.ogv The download does not work. I always just get between 0 and 138k of the file. Can you send me the file in a private email or host it somewhere else? (*Don't* hit the reply button, you have to type my address manually). Sorry, it seems that either my isp and/or my server is acting weird lately. The download is there and *should* work, but since you are not the only one having problems, I just sent it to you attached to a private mail. If anyone else needs it, please, feel free to ask me to send a copy. And please post a minimal config file that shows the problem. Any simple config which has a menu and a gradient-based colorset for the highlighted item would do. Just like this: cut here DestroyMenu menu_RootOps AddToMenu menu_RootOps + 1 a Exec foo + 2 b Exec foo + 3 c Exec foo + 4 d Exec foo + 5 e Exec foo + 6 f Exec foo + 7 g Exec foo + 8 h Exec foo + 9 i Exec foo MenuStyle * HilightBack, Hilight3DThin MenuStyle * ActiveColorset 7 MenuStyle * MenuColorset 8 Mouse 1 R A Menu menu_RootOps Colorset 7 VGradient 24 #225320 #0B0E10, bg #225320, hi #225320, sh #225320, fg #E9E9E9 Colorset 8 bg #232323, fg #FF, sh #232323, hi #232323 end cut Thanks for the attention. -- Jesús Guerrero [EMAIL PROTECTED]
Re: WAS fvwm and patches
On Thu, 06 Mar 2008 20:34:03 -0500
Dan Espen [EMAIL PROTECTED] wrote:
=?ISO-8859-1?Q?Jes=FAs?= Guerrero [EMAIL PROTECTED] writes:
On Fri, 7 Mar 2008 00:44:09 +0100
Jes=FAs Guerrero [EMAIL PROTECTED] wrote:
Conditionals patch revised and attached.
Is it valid? Does it lack something?
My idea is to shorten the list of available patches as much as we can by=20
including those that are evidently clean, useful and harmless upstream.
That way, we can ease the process for the rest of the patches.
Except for not updating test cases (which almost no one is doing),
it looks clean and reasonable to me.
I saw that file and plan to update it. I just need to watch into it
to understand the logic of the thing. Feel free to give any advice if
you feel that there's something relevant that I should know.
For now, I have a preliminary versions with that file included. Attached.
--
Jesús Guerrero [EMAIL PROTECTED]
diff -U5 -r fvwm/ChangeLog fvwm/ChangeLog
--- fvwm/ChangeLog 2008-03-04 01:09:54.0 +0100
+++ fvwm/ChangeLog 2008-03-07 01:33:47.0 +0100
@@ -1,5 +1,13 @@
+2008-03-07 Jesús Guerrero i92guboj(at)terra(dot)es
+
+ * fvwm/contitionals.c (CreateConditionMask):
+ add some conditional masks: HasTitle, HasBorders,
+ TitleAtBottom, TitleAtTop, TitleAtLeft, TitleAtRight
+ * doc/fvwm/conditionals.xml
+ documentation for the new conditions
+
2008-02-29 Viktor Griph griph(at)dd(dot)chalmers(dot)se
* fvwm/add_window.c (setup_frame_window):
fix core dump with ARGB detection code
fix compilation without XRender
diff -U5 -r fvwm/doc/fvwm/conditionals.xml fvwm/doc/fvwm/conditionals.xml
--- fvwm/doc/fvwm/conditionals.xml 2007-08-07 00:24:03.0 +0200
+++ fvwm/doc/fvwm/conditionals.xml 2008-03-07 01:33:06.0 +0100
@@ -187,11 +187,17 @@
emphasis remap='I'StickyAcrossPages/emphasis,
emphasis remap='I'StickyIcon/emphasis,
emphasis remap='I'StickyAcrossDesksIcon/emphasis,
emphasis remap='I'StickyAcrossPagesIcon/emphasis,
emphasis remap='I'Transient/emphasis,
-emphasis remap='I'Visible/emphasis./para
+emphasis remap='I'Visible/emphasis,
+emphasis remap='I'HasTitle/emphasis,
+emphasis remap='I'HasBorders/emphasis,
+emphasis remap='I'TitleAtBottom/emphasis,
+emphasis remap='I'TitleAtTop/emphasis,
+emphasis remap='I'TitleAtLeft/emphasis,
+emphasis remap='I'TitleAtRight/emphasis./para
paraThe
emphasis remap='I'AcceptsFocus/emphasis
condition excludes all windows that do not want the input focus
(the application has set the Input hints for the window to
@@ -454,10 +460,23 @@
emphasis remap='I'Visible/emphasis
condition matches only windows that are at least partially
visible on the current viewport and not completely overlapped by
other windows./para
+paraThe
+emphasis remap='I'HasTitle/emphasis
+condition matches only windows that have a title bar./para
+
+paraThe
+emphasis remap='I'HasBorders/emphasis
+condition matches only windows that have borders./para
+
+paraThe
+emphasis remap='I'TitleAtBottom/emphasis, emphasis remap='I'TitleAtTop/emphasis, emphasis remap='I'TitleAtLeft/emphasis, emphasis remap='I'TitleAtRight/emphasis,
+conditions matches respectively only windows that have a title
+bar, and have it on the specified location./para
+
/section
/section
diff -U5 -r fvwm/fvwm/conditional.c fvwm/fvwm/conditional.c
--- fvwm/fvwm/conditional.c 2007-10-06 11:17:09.0 +0200
+++ fvwm/fvwm/conditional.c 2008-03-07 01:10:54.0 +0100
@@ -598,10 +598,40 @@
else if (StrEquals(cond,HasHandles))
{
SET_HAS_HANDLES(mask, on);
SETM_HAS_HANDLES(mask, 1);
}
+ else if (StrEquals(cond, HasTitle))
+ {
+ SET_HAS_TITLE(mask, on);
+ SETM_HAS_TITLE(mask, 1);
+ }
+ else if (StrEquals(cond, HasBorders))
+ {
+ SET_HAS_NO_BORDER(mask, !on);
+ SETM_HAS_NO_BORDER(mask, 1);
+ }
+ else if (StrEquals(cond, TitleAtBottom))
+ {
+ SET_TITLE_DIR(mask, DIR_S);
+ SETM_TITLE_DIR(mask, 1);
+ }
+ else if (StrEquals(cond, TitleAtTop))
+ {
+ SET_TITLE_DIR(mask, DIR_N);
+ SETM_TITLE_DIR(mask, 1);
+ }
+ else if (StrEquals(cond, TitleAtLeft))
+ {
+ SET_TITLE_DIR(mask, DIR_W);
+ SETM_TITLE_DIR(mask, 1);
+ }
+ else if (StrEquals(cond, TitleAtRight))
+ {
+ SET_TITLE_DIR(mask, DIR_E);
+ SETM_TITLE_DIR(mask, 1);
+ }
else if (StrEquals(cond,Iconifiable))
{
SET_IS_UNICONIFIABLE(mask, !on);
SETM_IS_UNICONIFIABLE(mask, 1);
}
diff -U5 -r fvwm/NEWS fvwm/NEWS
--- fvwm/NEWS 2008-03-04 01:09:54.0 +0100
+++ fvwm/NEWS 2008-03-07 01:50:47.0 +0100
@@ -3,10 +3,15 @@
---
Changes in beta release 2.5.26 (not released yet)
+* New features:
+
+ - Added new condition masks: HasTitle, HasBorders,
+ TitleAtBottom, TitleAtTop, TitleAtLeft, TitleAtRight
+
* Bug fixes:
- Fix crash in ARGB visual detection code
- Fix compilation without XRender support
diff -U5 -r fvwm/tests/purify/purify.fvwm2rc fvwm/tests/purify
Re: WAS fvwm and patches
On Fri, 7 Mar 2008 00:44:09 +0100
Jesús Guerrero [EMAIL PROTECTED] wrote:
I didn't know about the test tools in the package. The test config
file for the menu certainly probed helpful when testing this patch.
This is the patch to get flat 1pix thick separators in the menus.
Patch attached: FlatSeparators
--
Jesús Guerrero [EMAIL PROTECTED]
diff -U5 -r fvwm/doc/commands/MenuStyle.xml fvwm/doc/commands/MenuStyle.xml
--- fvwm/doc/commands/MenuStyle.xml 2007-08-18 00:36:49.0 +0200
+++ fvwm/doc/commands/MenuStyle.xml 2008-03-07 03:24:46.0 +0100
@@ -56,11 +56,11 @@
MenuFace,
PopupDelay,
PopupOffset,
TitleWarp / !TitleWarp,
TitleUnderlines0 / TitleUnderlines1 / TitleUnderlines2,
-SeparatorsLong / SeparatorsShort,
+SeparatorsLong / SeparatorsShort / FlatSeparators,
TrianglesSolid / TrianglesRelief,
PopupImmediately / PopupDelayed,
PopdownImmediately / PopdownDelayed,
PopupActiveArea,
DoubleClickTime,
@@ -429,10 +429,15 @@
set the length of menu separators. Long separators run from the
left edge all the way to the right edge. Short separators leave a
few pixels to the edges of the menu./para
para
+fvwmopt cmd=MenuStyle opt=FlatSeparators/
+changes the separators so that they are a single pixel thick and
+colored the same as the text./para
+
+para
fvwmopt cmd=MenuStyle opt=TrianglesSolid/ and
fvwmopt cmd=MenuStyle opt=TrianglesRelief/
affect how the small triangles for sub menus is drawn. Solid
triangles are filled with a color while relief triangles are
hollow./para
diff -U5 -r fvwm/fvwm/menuitem.c fvwm/fvwm/menuitem.c
--- fvwm/fvwm/menuitem.c 2007-07-26 10:00:43.0 +0200
+++ fvwm/fvwm/menuitem.c 2008-03-07 03:18:49.0 +0100
@@ -80,14 +80,22 @@
*
* Draws two horizontal lines to form a separator
*
*/
static void draw_separator(
- Window w, GC TopGC, GC BottomGC, int x1, int y, int x2)
+ Window w, GC TopGC, GC BottomGC, GC ForeGC, int x1, int y, int x2,
+ Bool do_flat_separators)
{
- XDrawLine(dpy, w, TopGC , x1, y, x2, y);
- XDrawLine(dpy, w, BottomGC, x1-1, y+1, x2+1, y+1);
+ if (do_flat_separators)
+ {
+ XDrawLine(dpy, w, ForeGC, x1, y, x2, y);
+ }
+ else
+ {
+ XDrawLine(dpy, w, TopGC , x1, y, x2, y);
+ XDrawLine(dpy, w, BottomGC, x1-1, y+1, x2+1, y+1);
+ }
return;
}
/*
@@ -380,10 +388,11 @@
int off_cs;
FvwmRenderAttributes fra;
/*Pixel fg, fgsh;*/
int relief_thickness = ST_RELIEF_THICKNESS(ms);
Bool is_item_selected;
+ Bool do_flat_separators;
Bool item_cleared = False;
Bool xft_clear = False;
Bool empty_inter = False;
XRectangle b;
Region region = None;
@@ -598,10 +607,12 @@
/*
* Draw the item itself.
*/
+ do_flat_separators = ST_DO_FLAT_SEPARATOR(ms);
+
/* Calculate the separator offsets. */
if (ST_HAS_LONG_SEPARATORS(ms))
{
sx1 = MDIM_ITEM_X_OFFSET(*dim) + relief_thickness;
sx2 = MDIM_ITEM_X_OFFSET(*dim) + MDIM_ITEM_WIDTH(*dim) - 1 -
@@ -618,13 +629,13 @@
{
if (sx1 sx2)
{
/* It's a separator. */
draw_separator(
-mpip-w, gcs.shadow_gc, gcs.hilight_gc, sx1,
-y_offset + y_height - MENU_SEPARATOR_HEIGHT,
-sx2);
+mpip-w, gcs.shadow_gc, gcs.hilight_gc, gcs.fore_gc,
+sx1, y_offset + y_height - MENU_SEPARATOR_HEIGHT,
+sx2, do_flat_separators);
/* Nothing else to do. */
}
return;
}
else if (MI_IS_TEAR_OFF_BAR(mi))
@@ -660,12 +671,12 @@
text_y += MENU_SEPARATOR_HEIGHT + add;
y = y_offset + add;
if (sx1 sx2)
{
draw_separator(
- mpip-w, gcs.shadow_gc, gcs.hilight_gc,
- sx1, y, sx2);
+ mpip-w, gcs.shadow_gc, gcs.hilight_gc, gcs.fore_gc,
+ sx1, y, sx2, do_flat_separators);
}
}
/* Underline the title. */
switch (ST_TITLE_UNDERLINES(ms))
{
@@ -674,12 +685,12 @@
case 1:
if (MI_NEXT_ITEM(mi) != NULL)
{
y = y_offset + y_height - MENU_SEPARATOR_HEIGHT;
draw_separator(
- mpip-w, gcs.shadow_gc, gcs.hilight_gc,
- sx1, y, sx2);
+ mpip-w, gcs.shadow_gc, gcs.hilight_gc, gcs.fore_gc,
+ sx1, y, sx2, do_flat_separators);
}
break;
default:
for (i = ST_TITLE_UNDERLINES(ms); i-- 0; )
{
diff -U5 -r fvwm/fvwm/menus.c fvwm/fvwm/menus.c
--- fvwm/fvwm/menus.c 2007-11-23 11:12:54.0 +0100
+++ fvwm/fvwm/menus.c 2008-03-07 03:18:49.0 +0100
@@ -1601,10 +1601,14 @@
int separator_height;
separator_height = (last_item_has_relief) ?
MENU_SEPARATOR_HEIGHT + relief_thickness :
MENU_SEPARATOR_TOTAL_HEIGHT;
+ if (MST_DO_FLAT_SEPARATOR(msp-menu))
+ {
+ separator_height += 1;
+ }
MI_Y_OFFSET(mi) = y;
if (MI_IS_TITLE(mi))
{
MI_HEIGHT(mi) = MST_PTITLEFONT(msp-menu)-height +
MST_TITLE_GAP_ABOVE(msp-menu) +
diff -U5 -r fvwm/fvwm/menustyle.c fvwm/fvwm/menustyle.c
--- fvwm/fvwm/menustyle.c 2007-08-07 22:17:43.0 +0200
+++ fvwm/fvwm/menustyle.c 2008-03-07 03:18:49.0 +0100
@@ -403,11 +403,11 @@
PopupActiveArea,
PopupIgnore, PopupClose,
MouseWheel, ScrollOffPage
Re: WAS fvwm and patches
On Fri, 7 Mar 2008 04:13:10 +0100
Jesús Guerrero [EMAIL PROTECTED] wrote:
On Fri, 7 Mar 2008 00:44:09 +0100
Jesús Guerrero [EMAIL PROTECTED] wrote:
I didn't know about the test tools in the package. The test config
file for the menu certainly probed helpful when testing this patch.
This is the patch to get flat 1pix thick separators in the menus.
Patch attached: FlatSeparators
--
Jesús Guerrero [EMAIL PROTECTED]
Ops. Small fix. Changelog and NEWS added (based on the previous
Conditionals patch).
--
Jesús Guerrero [EMAIL PROTECTED]
diff -U5 -r fvwm/doc/commands/MenuStyle.xml fvwm/doc/commands/MenuStyle.xml
--- fvwm/doc/commands/MenuStyle.xml 2007-08-18 00:36:49.0 +0200
+++ fvwm/doc/commands/MenuStyle.xml 2008-03-07 03:24:46.0 +0100
@@ -56,11 +56,11 @@
MenuFace,
PopupDelay,
PopupOffset,
TitleWarp / !TitleWarp,
TitleUnderlines0 / TitleUnderlines1 / TitleUnderlines2,
-SeparatorsLong / SeparatorsShort,
+SeparatorsLong / SeparatorsShort / FlatSeparators,
TrianglesSolid / TrianglesRelief,
PopupImmediately / PopupDelayed,
PopdownImmediately / PopdownDelayed,
PopupActiveArea,
DoubleClickTime,
@@ -429,10 +429,15 @@
set the length of menu separators. Long separators run from the
left edge all the way to the right edge. Short separators leave a
few pixels to the edges of the menu./para
para
+fvwmopt cmd=MenuStyle opt=FlatSeparators/
+changes the separators so that they are a single pixel thick and
+colored the same as the text./para
+
+para
fvwmopt cmd=MenuStyle opt=TrianglesSolid/ and
fvwmopt cmd=MenuStyle opt=TrianglesRelief/
affect how the small triangles for sub menus is drawn. Solid
triangles are filled with a color while relief triangles are
hollow./para
diff -U5 -r fvwm/fvwm/menuitem.c fvwm/fvwm/menuitem.c
--- fvwm/fvwm/menuitem.c 2007-07-26 10:00:43.0 +0200
+++ fvwm/fvwm/menuitem.c 2008-03-07 03:18:49.0 +0100
@@ -80,14 +80,22 @@
*
* Draws two horizontal lines to form a separator
*
*/
static void draw_separator(
- Window w, GC TopGC, GC BottomGC, int x1, int y, int x2)
+ Window w, GC TopGC, GC BottomGC, GC ForeGC, int x1, int y, int x2,
+ Bool do_flat_separators)
{
- XDrawLine(dpy, w, TopGC , x1, y, x2, y);
- XDrawLine(dpy, w, BottomGC, x1-1, y+1, x2+1, y+1);
+ if (do_flat_separators)
+ {
+ XDrawLine(dpy, w, ForeGC, x1, y, x2, y);
+ }
+ else
+ {
+ XDrawLine(dpy, w, TopGC , x1, y, x2, y);
+ XDrawLine(dpy, w, BottomGC, x1-1, y+1, x2+1, y+1);
+ }
return;
}
/*
@@ -380,10 +388,11 @@
int off_cs;
FvwmRenderAttributes fra;
/*Pixel fg, fgsh;*/
int relief_thickness = ST_RELIEF_THICKNESS(ms);
Bool is_item_selected;
+ Bool do_flat_separators;
Bool item_cleared = False;
Bool xft_clear = False;
Bool empty_inter = False;
XRectangle b;
Region region = None;
@@ -598,10 +607,12 @@
/*
* Draw the item itself.
*/
+ do_flat_separators = ST_DO_FLAT_SEPARATOR(ms);
+
/* Calculate the separator offsets. */
if (ST_HAS_LONG_SEPARATORS(ms))
{
sx1 = MDIM_ITEM_X_OFFSET(*dim) + relief_thickness;
sx2 = MDIM_ITEM_X_OFFSET(*dim) + MDIM_ITEM_WIDTH(*dim) - 1 -
@@ -618,13 +629,13 @@
{
if (sx1 sx2)
{
/* It's a separator. */
draw_separator(
-mpip-w, gcs.shadow_gc, gcs.hilight_gc, sx1,
-y_offset + y_height - MENU_SEPARATOR_HEIGHT,
-sx2);
+mpip-w, gcs.shadow_gc, gcs.hilight_gc, gcs.fore_gc,
+sx1, y_offset + y_height - MENU_SEPARATOR_HEIGHT,
+sx2, do_flat_separators);
/* Nothing else to do. */
}
return;
}
else if (MI_IS_TEAR_OFF_BAR(mi))
@@ -660,12 +671,12 @@
text_y += MENU_SEPARATOR_HEIGHT + add;
y = y_offset + add;
if (sx1 sx2)
{
draw_separator(
- mpip-w, gcs.shadow_gc, gcs.hilight_gc,
- sx1, y, sx2);
+ mpip-w, gcs.shadow_gc, gcs.hilight_gc, gcs.fore_gc,
+ sx1, y, sx2, do_flat_separators);
}
}
/* Underline the title. */
switch (ST_TITLE_UNDERLINES(ms))
{
@@ -674,12 +685,12 @@
case 1:
if (MI_NEXT_ITEM(mi) != NULL)
{
y = y_offset + y_height - MENU_SEPARATOR_HEIGHT;
draw_separator(
- mpip-w, gcs.shadow_gc, gcs.hilight_gc,
- sx1, y, sx2);
+ mpip-w, gcs.shadow_gc, gcs.hilight_gc, gcs.fore_gc,
+ sx1, y, sx2, do_flat_separators);
}
break;
default:
for (i = ST_TITLE_UNDERLINES(ms); i-- 0; )
{
diff -U5 -r fvwm/fvwm/menus.c fvwm/fvwm/menus.c
--- fvwm/fvwm/menus.c 2007-11-23 11:12:54.0 +0100
+++ fvwm/fvwm/menus.c 2008-03-07 03:18:49.0 +0100
@@ -1601,10 +1601,14 @@
int separator_height;
separator_height = (last_item_has_relief) ?
MENU_SEPARATOR_HEIGHT + relief_thickness :
MENU_SEPARATOR_TOTAL_HEIGHT;
+ if (MST_DO_FLAT_SEPARATOR(msp-menu))
+ {
+ separator_height += 1;
+ }
MI_Y_OFFSET(mi) = y;
if (MI_IS_TITLE(mi))
{
MI_HEIGHT(mi) = MST_PTITLEFONT(msp-menu)-height +
MST_TITLE_GAP_ABOVE(msp-menu) +
diff -U5 -r fvwm/fvwm/menustyle.c fvwm/fvwm/menustyle.c
--- fvwm/fvwm
Re: WAS fvwm and patches
Patch attached: ButtonWidth
--
Jesús Guerrero [EMAIL PROTECTED]
diff -r -U3 fvwm/ChangeLog fvwm/ChangeLog
--- fvwm/ChangeLog 2008-03-07 05:34:21.0 +0100
+++ fvwm/ChangeLog 2008-03-07 05:28:14.0 +0100
@@ -19,6 +19,14 @@
*fvwm/doc/commands/MenuStyle.xml
added the menustyle FlatSeparators documentation
+ *fvwm/doc/commands/TitleStyle.xml
+ added documentation for the ButtonWidth patch
+
+ *fvwm/frame.c
+ *fvwm/screen.h
+ *fvwm/builtins.c
+ patched for ButtonWidth
+
2008-02-29 Viktor Griph griph(at)dd(dot)chalmers(dot)se
* fvwm/add_window.c (setup_frame_window):
diff -r -U3 fvwm/doc/commands/TitleStyle.xml fvwm/doc/commands/TitleStyle.xml
--- fvwm/doc/commands/TitleStyle.xml 2008-03-07 05:33:39.0 +0100
+++ fvwm/doc/commands/TitleStyle.xml 2008-03-07 05:24:09.0 +0100
@@ -25,6 +25,11 @@
MinHeight optional
replaceablenum/replaceable
/optional
+ /arg
+ arg choice='opt'
+ ButtonWidth optional
+ replaceablenum/replaceable
+ /optional
/arg
/cmdsynopsis
@@ -36,6 +41,9 @@
sets the title bar's height to an amount in pixels.
fvwmopt cmd=TitleStyle opt=MinHeight/
sets the minimal height in pixels of the title bar.
+fvwmopt cmd=TitleStyle opt=ButtonWidth/
+Sets the width of the title bar buttons. Setting a width
+of 0 or no width uses the title height, as before.
Defaults are
emphasis remap='I'Centered/emphasis,
the window's font height and no minimal height.
diff -r -U3 fvwm/fvwm/builtins.c fvwm/fvwm/builtins.c
--- fvwm/fvwm/builtins.c 2008-03-07 05:33:39.0 +0100
+++ fvwm/fvwm/builtins.c 2008-03-07 05:13:38.0 +0100
@@ -492,6 +492,21 @@
if (action)
action += next;
}
+ else if (!do_add StrEquals(parm,buttonwidth))
+ {
+ int width = 0;
+ int next = 0;
+
+ sscanf(action, %d%n, width, next);
+
+ if (decor-button_width != width)
+ {
+decor-button_width = width;
+decor-flags.has_changed = 1;
+ }
+ if (action)
+action += next;
+ }
else if (!do_add StrEquals(parm,MinHeight))
{
int height = 0;
diff -r -U3 fvwm/fvwm/frame.c fvwm/fvwm/frame.c
--- fvwm/fvwm/frame.c 2008-03-07 05:33:38.0 +0100
+++ fvwm/fvwm/frame.c 2008-03-07 05:13:38.0 +0100
@@ -1369,7 +1369,14 @@
tb_thick = fw-title_thickness;
nbuttons = fw-nr_left_buttons + fw-nr_right_buttons;
nbuttons_big = 0;
- b_length = tb_thick;
+ if (fw-decor-button_width == 0)
+ {
+ b_length = tb_thick;
+ }
+ else
+ {
+ b_length = fw-decor-button_width;
+ }
t_length = tb_length - nbuttons * b_length;
if (nbuttons 0 t_length MIN_WINDOW_TITLE_LENGTH)
{
diff -r -U3 fvwm/fvwm/screen.h fvwm/fvwm/screen.h
--- fvwm/fvwm/screen.h 2008-03-07 05:33:38.0 +0100
+++ fvwm/fvwm/screen.h 2008-03-07 05:13:38.0 +0100
@@ -286,6 +286,7 @@
#endif
int title_height; /* explicitly specified title bar height */
int min_title_height;
+ int button_width;
/* titlebar buttons */
TitleButton buttons[NUMBER_OF_TITLE_BUTTONS];
TitleButton titlebar;
diff -r -U3 fvwm/NEWS fvwm/NEWS
--- fvwm/NEWS 2008-03-07 05:34:21.0 +0100
+++ fvwm/NEWS 2008-03-07 05:29:47.0 +0100
@@ -10,6 +10,7 @@
- Added new condition masks: HasTitle, HasBorders,
TitleAtBottom, TitleAtTop, TitleAtLeft, TitleAtRight
- Added new menu separator menustyle: FlatSeparator
+ - Added new menu titlestyle: ButtonWidth
* Bug fixes:
Re: WAS fvwm and patches
On Fri, 7 Mar 2008 05:13:38 + Thomas Adam [EMAIL PROTECTED] wrote: I was the original author of this patch to add HasTitle and HasBorders - it was then augmented by someone else, I forget whom. To be honest, there's all *manner* of different tests one could do here, and this patch is by no means representative enough of them. Although if more conditionals are to be added in this way, the list would get rather long, and an alternative approach might need to be sought after. The guy at http://www.abdn.ac.uk/~u15dm4/fvwm/, who is distributing several more patches on that web, claims to have modified your patch. So I suppose it was him the one who changed them. When you look into the code, as you say, it's evident that a lot of stuff could be added that way and the number of options could get way overwhelming. But that's out of my scope. I just intend (if possible) to get some of those patches included upstream. If someone wants to extend them, that's ok. -- Jesús Guerrero [EMAIL PROTECTED]
Re: WAS fvwm and patches
On Fri, 7 Mar 2008 00:44:09 +0100
Jesús Guerrero [EMAIL PROTECTED] wrote:
Attached: Style InactiveFont patch
--
Jesús Guerrero [EMAIL PROTECTED]
diff -r -U3 fvwm/ChangeLog fvwm/ChangeLog
--- fvwm/ChangeLog 2008-03-07 05:53:47.0 +0100
+++ fvwm/ChangeLog 2008-03-07 06:07:12.0 +0100
@@ -27,6 +27,17 @@
*fvwm/builtins.c
patched for ButtonWidth
+ *fvwm/doc/commands/Style.xml
+ added documentation for Style InactiveFont
+
+ *fvwm/style.c
+ *fvwm/style.h
+ *fvwm/fvwm.h
+ *fvwm/add_window.c
+ *fvwm/window_flags.h
+ *fvwm/borders.c
+ patched to add new Style: InactiveFont
+
2008-02-29 Viktor Griph griph(at)dd(dot)chalmers(dot)se
* fvwm/add_window.c (setup_frame_window):
diff -r -U3 fvwm/doc/commands/Style.xml fvwm/doc/commands/Style.xml
--- fvwm/doc/commands/Style.xml 2008-03-07 05:53:47.0 +0100
+++ fvwm/doc/commands/Style.xml 2008-03-07 06:04:49.0 +0100
@@ -84,6 +84,7 @@
emphasis remap='I'IconBackgroundColorset/emphasis,
emphasis remap='I'IconTitleRelief/emphasis, emphasis remap='I'IconBackgroundRelief/emphasis, emphasis remap='I'IconBackgroundPadding/emphasis,
emphasis remap='I'Font/emphasis,
+emphasis remap='I'InactiveFont/emphasis,
emphasis remap='I'IconFont/emphasis,
emphasis remap='I'StartsOnDesk/emphasis / emphasis remap='I'StartsOnPage/emphasis / emphasis remap='I'StartsAnyWhere/emphasis,
emphasis remap='I'StartsOnScreen/emphasis,
@@ -606,13 +607,14 @@
and it is restored if the argument is omitted./para
paraThe
-fvwmopt cmd=Style opt=Font/ and fvwmopt cmd=Style opt=IconFont/
+fvwmopt cmd=Style opt=Font/, fvwmopt cmd=Style opt=InactiveFont/
+and fvwmopt cmd=Style opt=IconFont/
options take the name of a font as their sole argument. This font
-is used in the window or icon title. By default the font given in
-the
+is used in the active window, inactive window or icon title respectively.
+By default the font given in the
fvwmref cmd=DefaultFont/
command is used. To revert back to the default, use the style
-without the name argument. These styles replace the older
+without the name argument. The first two styles replace the older
fvwmref cmd=WindowFont/ and fvwmopt cmd=Style opt=IconFont/
commands./para
diff -r -U3 fvwm/fvwm/add_window.c fvwm/fvwm/add_window.c
--- fvwm/fvwm/add_window.c 2008-03-07 05:53:47.0 +0100
+++ fvwm/fvwm/add_window.c 2008-03-07 05:58:46.0 +0100
@@ -638,6 +638,18 @@
fw-title_font = Scr.DefaultFont;
SET_USING_DEFAULT_WINDOW_FONT(fw, 1);
+ if (IS_INACTIVE_WINDOW_FONT_LOADED(fw) !USING_DEFAULT_INACTIVE_WINDOW_FONT(fw)
+ fw-title_font != Scr.DefaultFont)
+ {
+ FlocaleUnloadFont(dpy, fw-title_font);
+ }
+ SET_INACTIVE_WINDOW_FONT_LOADED(fw, 0);
+ /* Fall back to default font. There are some race conditions when a
+ * window is destroyed and recaptured where an invalid font might be
+ * accessed otherwise. */
+ fw-title_font = Scr.DefaultFont;
+ SET_USING_DEFAULT_INACTIVE_WINDOW_FONT(fw, 1);
+
return;
}
@@ -1735,6 +1747,25 @@
}
SET_WINDOW_FONT_LOADED(fw, 1);
}
+ /* load inactive font */
+ if (!IS_INACTIVE_WINDOW_FONT_LOADED(fw))
+ {
+ if (S_HAS_INACTIVE_WINDOW_FONT(SCF(*pstyle))
+ SGET_INACTIVE_WINDOW_FONT(*pstyle)
+ (fw-inactive_title_font =
+ FlocaleLoadFont(dpy, SGET_INACTIVE_WINDOW_FONT(*pstyle), FVWM)))
+ {
+ SET_USING_DEFAULT_INACTIVE_WINDOW_FONT(fw, 0);
+ }
+ else
+ {
+ /* no explicit font or failed to load, use active title font
+ * instead */
+ fw-inactive_title_font = fw-title_font;
+ SET_USING_DEFAULT_INACTIVE_WINDOW_FONT(fw, 1);
+ }
+ SET_INACTIVE_WINDOW_FONT_LOADED(fw, 1);
+ }
setup_title_geometry(fw, pstyle);
return;
diff -r -U3 fvwm/fvwm/borders.c fvwm/fvwm/borders.c
--- fvwm/fvwm/borders.c 2008-03-07 05:53:47.0 +0100
+++ fvwm/fvwm/borders.c 2008-03-07 05:58:46.0 +0100
@@ -3525,7 +3525,7 @@
static void border_draw_title_mono(
FvwmWindow *fw, titlebar_descr *td, title_draw_descr *tdd,
- FlocaleWinString *fstr, Pixmap dest_pix)
+ FlocaleWinString *fstr, Pixmap dest_pix, Bool do_hilight)
{
int has_vt;
@@ -3535,7 +3535,8 @@
td-offset - 2, 0, td-length+4, fw-title_thickness);
if (fw-visible_name != (char *)NULL)
{
- FlocaleDrawString(dpy, fw-title_font, fstr, 0);
+ FlocaleDrawString(dpy, do_hilight ? fw-title_font :
+ fw-inactive_title_font, fstr, 0);
}
/* for mono, we clear an area in the title bar where the window
* title goes, so that its more legible. For color, no need */
@@ -3599,7 +3600,7 @@
static void border_draw_title_deep(
FvwmWindow *fw, titlebar_descr *td, title_draw_descr *tdd,
- FlocaleWinString *fstr, Pixmap dest_pix, Window w)
+ FlocaleWinString *fstr, Pixmap dest_pix, Window w, Bool do_hilight)
{
DecorFace *df;
pixmap_background_type bg;
@@ -3621,14 +3622,15 @@
1);
}
}
- FlocaleDrawString(dpy, fw-title_font, tdd-fstr, 0);
+ FlocaleDrawString(dpy, do_hilight ? fw-title_font :
+ fw-inactive_title_font, tdd-fstr, 0);
return;
}
static void
PATCHES COMPILATION AND A NOTE
A quick note, I attack to this mail all the patches, on it's latest
version.
Forgive me for the numbering scheme. It intended to serve a purpose,
but since I added the changelogs on a different order and they are
cumulative, you'd likely get some annoying rejects if you use the
numbering on the file names. The correct order to avoid rejects is
this one, from the first to the last:
03-Conditionals-r3.patch
04-FlatSeparators-r2.patch
10-ButtonWidth-r1.patch
06-InactiveFont-r1.patch
02-ResizeOutlineThin-r1.patch
I am very sorry for the inconvenience.
If any of this is useful and tidy enough for it to be merged, that'd be
great.
All the patches include NEWS, Changelog, documentation and, when relevant,
the matching mods into test/*. If any of them lacks something, just let
me know and I will add it.
--
Jesús Guerrero [EMAIL PROTECTED]
diff -U3 -r fvwm/ChangeLog fvwm-/ChangeLog
--- fvwm/ChangeLog 2008-03-07 07:19:18.0 +0100
+++ fvwm-/ChangeLog 2008-03-07 07:19:42.0 +0100
@@ -38,6 +38,16 @@
*fvwm/borders.c
patched to add new Style: InactiveFont
+ *fvwm/style.c
+ *fvwm/style.h
+ *fvwm/move_resize.c
+ *fvwm/fvwm.h
+ *fvwm/window_flags.h
+ patched to add new style: ResizeOutlineThin
+
+ *fvwm/doc/commands/Style.xml
+ added documentation for Style ResizeOutlineThin
+
2008-02-29 Viktor Griph griph(at)dd(dot)chalmers(dot)se
* fvwm/add_window.c (setup_frame_window):
diff -U3 -r fvwm/doc/commands/Style.xml fvwm-/doc/commands/Style.xml
--- fvwm/doc/commands/Style.xml 2008-03-07 07:19:18.0 +0100
+++ fvwm-/doc/commands/Style.xml 2008-03-07 07:19:42.0 +0100
@@ -180,6 +180,7 @@
emphasis remap='I'MaxWindowSize/emphasis,
emphasis remap='I'IconifyWindowGroups/emphasis / emphasis remap='I'IconifyWindowGroupsOff/emphasis,
emphasis remap='I'ResizeOpaque/emphasis / emphasis remap='I'ResizeOutline/emphasis,
+emphasis remap='I'ResizeOutlineThin/emphasis,
emphasis remap='I'BackingStore/emphasis / emphasis remap='I'BackingStoreOff/emphasis / emphasis remap='I'BackingStoreWindowDefault/emphasis,
emphasis remap='I'Opacity/emphasis / emphasis remap='I'ParentalRelativity/emphasis,
emphasis remap='I'SaveUnder/emphasis / emphasis remap='I'SaveUnderOff/emphasis,
@@ -1078,6 +1079,10 @@
Style emacs ResizeOutline
/programlisting
+parafvwmopt cmd=Style opt=ResizeOutlineThin/
+changes the move/resize box into a single one pixel rectangle. This
+is closer to how many other WMs look./para
+
parafvwmopt cmd=Style opt=Sticky/
makes the window sticky, i.e. it is always visible on each page
and each desk. The opposite style,
diff -U3 -r fvwm/fvwm/fvwm.h fvwm-/fvwm/fvwm.h
--- fvwm/fvwm/fvwm.h 2008-03-07 07:19:18.0 +0100
+++ fvwm-/fvwm/fvwm.h 2008-03-07 07:19:42.0 +0100
@@ -224,6 +224,7 @@
unsigned do_not_show_on_map : 1;
unsigned do_raise_transient : 1;
unsigned do_resize_opaque : 1;
+ unsigned do_resize_outline_thin : 1;
unsigned do_shrink_windowshade : 1;
unsigned do_stack_transient_parent : 1;
unsigned do_window_list_skip : 1;
diff -U3 -r fvwm/fvwm/move_resize.c fvwm-/fvwm/move_resize.c
--- fvwm/fvwm/move_resize.c 2008-03-07 07:19:18.0 +0100
+++ fvwm-/fvwm/move_resize.c 2008-03-07 07:19:42.0 +0100
@@ -108,7 +108,7 @@
extern Window PressedW;
-static void draw_move_resize_grid(int x, int y, int width, int height);
+static void draw_move_resize_grid(int x, int y, int width, int height, Bool thin);
/* - end of resize globals - */
@@ -126,26 +126,33 @@
*
*/
static int get_outline_rects(
- XRectangle *rects, int x, int y, int width, int height)
+ XRectangle *rects, int x, int y, int width, int height, Bool do_outline_thin)
{
int i;
int n;
int m;
- n = 3;
- m = (width - 5) / 2;
- if (m n)
+ if (do_outline_thin)
{
- n = m;
- }
- m = (height - 5) / 2;
- if (m n)
- {
- n = m;
+ n = 1;
}
- if (n 1)
+ else
{
- n = 1;
+ n = 3;
+ m = (width - 5) / 2;
+ if (m n)
+ {
+ n = m;
+ }
+ m = (height - 5) / 2;
+ if (m n)
+ {
+ n = m;
+ }
+ if (n 1)
+ {
+ n = 1;
+ }
}
for (i = 0; i n; i++)
@@ -155,25 +162,28 @@
rects[i].width = width - (i 1);
rects[i].height = height - (i 1);
}
- if (width - (n 1) = 5 height - (n 1) = 5)
+ if (!do_outline_thin)
{
- if (width - (n 1) = 10)
+ if (width - (n 1) = 5 height - (n 1) = 5)
{
- int off = (width - (n 1)) / 3 + n;
- rects[i].x = x + off;
- rects[i].y = y + n;
- rects[i].width = width - (off 1);
- rects[i].height = height - (n 1);
- i++;
- }
- if (height - (n 1) = 10)
- {
- int off = (height - (n 1)) / 3 + n;
- rects[i].x = x + n;
- rects[i].y = y + off;
- rects[i].width = width - (n 1);
- rects[i].height = height - (off 1);
- i++;
+ if (width - (n 1) = 10)
+ {
+int off = (width - (n 1)) / 3 + n;
+rects[i].x = x + off;
+rects[i].y = y + n;
+rects[i].width = width - (off 1);
+rects[i].height = height - (n 1);
+i++;
+ }
+ if (height - (n 1) = 10
Re: PATCHES COMPILATION AND A NOTE (addendum)
On Fri, 7 Mar 2008 07:32:18 +0100 Jesús Guerrero [EMAIL PROTECTED] wrote: Just one more thing. I put my name on the Changelogs, but to tell the truth, no code inside those patches is mine. The conditional stuff patch is from Thomas Adam as seen before in this list, modified by the guy at http://www.abdn.ac.uk/~u15dm4/fvwm/ The rest of patches are -I presume- from that man as well, though I have no way to confirm that. I just didn't know how to actually reflect this in the Changelog. I deserve no merit other than the re'diffs, the docs for these patches, and the slight additions to the test files. Sorry for spamming the list that much today. Regards. -- Jesús Guerrero [EMAIL PROTECTED]
bug: hilight gradient position in menu
Hello, This problem has been around for some time, though I just ignored it silently. I made a small video (a few secs, 1,4mb or so). http://jesgue.homelinux.org/other-files/out-1.ogv You can see it with mplayer. It shows how the gradient is not correctly drawn, I think that there's some problem calculating the height of the item or something. On each step the gradient seems to be drawn 1 or 2 pixels below the previous location (in relative terms). I can't explain too accurately with words, so a video seemed the best option to me. This has been around for a long time, but I don't use to use gradients so it doesn't really bother me. This is on a cvs -unpatched- build from yesterday. I suspect that the problem might be into menuitem.c, but being completely ignorant about fvwm's source and xlib programming in general, it's not easy for me to understand it. So, if anyone can tell me where to look, or just patch it, then it'd be great. Regards. -- Jesús Guerrero [EMAIL PROTECTED]
Re: FVWM: Reasonable looking fonts for fvwm - recommendations please
On Mon, 3 Mar 2008 21:37:32 + Chris G [EMAIL PROTECTED] wrote: What fonts/typefaces look good in fvwm? Specifically I'm looking for ones to use in menus and window headings. I was using adobe helvetica which were OK (but not brilliant) but my new installation doesn't seem to have such a good range of sizes. I'm currently using Schumacher Clean but that's plain ugly, if legible. Has anyone any better suggestions? It depends, do you want ttf fonts of fixed size fonts? If you use ttf fonts you can use any size you need. I use DejaVu because it looks good without any annoying extra fanciness, and it has a good (well, better than most) support for utf8. If you preffer raster fonts, I'd just use fixed just like Thomas Adam suggested. -- Jesús Guerrero [EMAIL PROTECTED]
Re: FVWM: How to make thumbnail WindowListSkip?
On Tue, 19 Feb 2008 16:21:58 +0800 for.register for.register [EMAIL PROTECTED] wrote: Hello, Hi, All How to make thumbnail WindowListSkip? I can't figure what do you mean. There is another question ( I did not find any answer in fvwm manul) How to set the the mouse bindings when I want to use Alt+mouse3(hold) to movesize of the current window directly? The basic scheme for key bindings is Mouse button context modifier_key action So, you probably want: Mouse 3 W M Resize Where 3 is the moust button, W is the Window context and M is the meta key. Change the action if Resize is not what you want. -- Jesús Guerrero [EMAIL PROTECTED]
Re: FLCXOMCharset again
On Sun, 27 Jan 2008 01:26:04 +0100 Dominik Vogt [EMAIL PROTECTED] wrote: On Sat, Jan 26, 2008 at 04:32:08PM +0100, Jesús Guerrero wrote: On Sat, 26 Jan 2008 12:29:14 +0100 Dominik Vogt [EMAIL PROTECTED] wrote: Thanks for the patch (in another message)! @others: Does it fix your problem? It seems so. I have to test a bit more but it seems that it works as it should now. @Olivier, if you are reading this, could you attach the patch here or send me a copy to i92guboj at terra dot es? I have not been able to help in anything because my skills were not enough, specially in which regards the locale stuff, but I made some research into this and learned a lot. I can see if looking at the patch I can learn something about this. It's fixed now, but knowledge never hurts :) You can get the patch with CVS easily: $ cvs diff -u -D 20080124 Thanks. I am plain dumb when it comes to cvs. (I have attached the patch). Thanks again. It's been very clarifying. I am starting to understand this thing. Changing topic: I use to submit improved ebuilds for fvwm on the Gentoo bugzilla. I have updated the 2.5.24 ebuild so it applies this patch over the 2.5.24 release. It works without any problem. So, 2.5.24 users can forget about this bug forever while 2.5.25 comes out. -- Jesús Guerrero [EMAIL PROTECTED]
Re: FLCXOMCharset again
On Sat, 26 Jan 2008 12:29:14 +0100 Dominik Vogt [EMAIL PROTECTED] wrote: Thanks for the patch (in another message)! @others: Does it fix your problem? It seems so. I have to test a bit more but it seems that it works as it should now. @Olivier, if you are reading this, could you attach the patch here or send me a copy to i92guboj at terra dot es? I have not been able to help in anything because my skills were not enough, specially in which regards the locale stuff, but I made some research into this and learned a lot. I can see if looking at the patch I can learn something about this. It's fixed now, but knowledge never hurts :) Thanks everyone and congratulations for such a good job. -- Jesús Guerrero [EMAIL PROTECTED]
Re: FLCXOMCharset again
On Mon, 7 Jan 2008 21:13:16 +0100 Dominik Vogt [EMAIL PROTECTED] wrote: On Sat, Jul 28, 2007 at 01:12:08PM +0200, Jesús Guerrero wrote: On Sat, 28 Jul 2007 11:36:09 +0200 Dominik Vogt [EMAIL PROTECTED] wrote: See below. --- libs/FlocaleCharset.c 2006-12-09 19:43:39.0 +0100 +++ libs/FlocaleCharset.c 2006-12-09 19:46:38.0 +0100 @@ -522,7 +522,7 @@ } if (FLCXOMCharsetList_num 0 FLCXOMCharsetList[0]) - FLCXOMCharset = FLCXOMCharsetList[0]; + FLCXOMCharset = FLCXOMCharsetList[FLCXOMCharsetList_num - 1]; #endif } What is special about the last entry in the charset list? Or are we just picking some random entry and hope that it works? Well, this is the output of PrintInfo Locale 1 on my system: *** FVWM info on locale: locale: es_ES.utf8, Modifier: Default Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No XOM Charsets: ISO8859-1 ISO8859-1 JISX0208.1983-0 KSC5601.1987-0 GB2312.1980-0 JISX0201.1976-0 ISO10646-1 Number of loaded font: 4 * Font number 0 fvwm info: Name: Shadow=0 0:xft:DejaVu Sans:style=Bold:size=7 Cache count: 9 Type: XftFont Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No height: 13, ascent: 11, descent: 3 shadow size: 0, shadow offset: 0, shadow direction:0 * Font number 1 fvwm info: Name: Shadow=0 0:xft:DejaVu Sans:size=7:styName: Shadow=0 0:xft:DejaVu Sans:size=7:style=Bold Cache count: 1 Type: XftFont Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No height: 13, ascent: 11, descent: 3 shadow size: 0, shadow offset: 0, shadow direction:0 * Font number 2 fvwm info: Name: Shadow=0 0:xft:DejaVu Sans:style=Condensed:size=7.2 Cache count: 1 Type: XftFont Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No height: 13, ascent: 11, descent: 3 shadow size: 0, shadow offset: 0, shadow direction:0 * Font number 3 fvwm info: Name: 0 Cache count: 1 Type: XftFont Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No height: 13, ascent: 11, descent: 3 shadow size: 0, shadow offset: 0, shadow direction:0 *** I don't know how the XOM charsets are usually ordered. In case that someone known, drop me a note. I will research about it, and try to find an all-cases solution. But, it is crystal-clear to me that the actual state of the things is not the correct one either. It is not less random than the choice that the patch makes, it just takes the other extreme of the array, but, as shown in the links I posted, and my own case, this is not correct, at least, not for utf8 systems. For now, I just have the empiric note that it works on all systems I tried, better than [0], but I did not try non-alphabetic languages, nor Arabic... so, that belief of mine might be completely false. If someone has some info about the issue that could be helpful, let me know. I will research about the patch, and try to explain how it works so we can discard it. If that happens, I will try to design a better patch that can handle all the locales properly. I'd really want to have this problem fixed. If all else fails, it would be allright to just add an option that tells fvwm which entry to use: +n = n'th entry -n = n'th entry counted from the end of the array 0 = default = either first or last entry Ciao Dominik ^_^ ^_^ -- Dominik Vogt I supposed that could be a good thing. At least, it could give the user a chance to make it work. I mean, I've had a need to patch fvwm since I started to use non standard characters on my fvwm. No other way around it. I lack both, the knowledge about xlib/fvwm and the time to research on this. If no one can do it, then that could be a good solution in the meantime. I suppose. -- Jesús Guerrero [EMAIL PROTECTED]
WindowId/WarpToWindow semantically broken with xinerama?
Hello, I already posted on the forums, and talked with Thomas Adam about this. Still, I can't understand what is going on so I will post it here and see what do the fvwm developers think. Before starting, some conventions: screen is a xinerama screen, which in my case spans across two physical devices. monitor is a physical display device root window is the fvwm root window, which takes the whole screen, as per the screen definition above. Now, I read on the man page this: WindowId [id] [(conditions)] | [root [screen]] command And here comes the questions: 1.- is the definition of screen above applicable to that command line? 2.- if not, what is that root [screen] supposed to do? These two commands do nothing different on my xinerama setup: Key Left A 4 WindowId root 1 WarpToWindow 50 50 Key Right A 4 WindowId root 0 WarpToWindow 50 50 They move the pointer to (50,50) taking as reference the root window, or the whole xinerama screen, if you prefer. So, I can only assume that either the man page or the WindowId/WarpToWindow combo are broken. Another thing is that, if this behaviour is the intended one, then it is missleading because the Move command has also a screen parameter, and it works as expected. If you open a FvwmConsole and do All (FvwmConsole) Move screen 0 0 0 All (FvwmConsole) Move screen 1 0 0 All (FvwmConsole) Move screen 0 0 0 You will see how your FvwmConsole moves from one physical monitor to the other. I don't see why this is a good behaviour for windows and not for the mouse pointer. I am not stating the fact that this is a bug or anything because maybe I am missing something. I just think that there is an inconsistency, and I don't understand what the screen parameter does in that WindowId/WarpToWindow line Thanks in advance for any response and congratulations for the good work :) -- Jesús Guerrero [EMAIL PROTECTED]
Re: Display problems with SVG and Xorg 7.2
On Fri, 28 Sep 2007 16:46:26 +0200 [EMAIL PROTECTED] wrote: Hello, Also I'll test my config with a system that using Xorg 7.3 to see what's wrong with my config. I had some minutes to look into this. Most of the problems about layout were about me not having bc installed, so I installed and the interface comes ok, though the menus and some other stuff doesn't load correctly. I fear that the config is a real mess, and not portable at all. But that is another different story. I tried it in another box with xorg 7.3 and I was able to replicate your problem. Currently it's recompiling the involved packages. I will let you know if that solves anything at all. Mmmm, by the way, what's your librsvg version? -- Jesús Guerrero [EMAIL PROTECTED]
Re: Display problems with SVG and Xorg 7.2
On Fri, 28 Sep 2007 19:12:11 +0200 Jesús Guerrero [EMAIL PROTECTED] wrote: Also, the localization functions are really strange. Fvwm supports localization via gettext. No need to have separate menu files for each language. Just create .po files for each language, and then use $[gt.Office], for example, instead of the menu label Office. If there is a translated string in the po file you use, then it will be used. If not, the sane default Office will be used instead. A big big big flaw is that the current system it implements is not able to load any menu file at all unless your lang is en or de. That is why it doesn't load for me. The function to set lang wouldn't be necessary if this was implemented using gettext instead, but it not, a default value should be used (probably en) if your lang is not supported. -- Jesús Guerrero [EMAIL PROTECTED]
Re: Display problems with SVG and Xorg 7.2
On Fri, 28 Sep 2007 02:10:34 +0200 Thomas Funk [EMAIL PROTECTED] wrote: Hi all, I've display problems with SVG in FVWM 2.5.22/23/24 and Xorg 7.2: http://img473.imageshack.us/img473/1431/screenshot200709280143cs3.jpg on Xorg 7.1 all looks fine: http://img101.imageshack.us/my.php?image=screenshot200709250039lm2.jpg I don't know what's happening but perhaps it is a problem with one of the newer libs needed for displaying SVG in Xorg 7.2 ... I have seen it first on my Fedora 7 and my Debian 4.0 system. On my older Debian (also 4.0 but with Xorg 7.1) all looks good. If you want to test it on your system you can download my config from http://extremeshare.ru/THnXEq9/New_TF_config_070925.tar.bz2.htm It would be great to know what's the problem. It works here with 7.3, and worked as well with 7.2 (not that I use graphics on my configuration, but I would have noticed something if there was some problem). Fvwm uses librsvg to render the svg pictures, so, one thing you could try is to recompile librsvg against the latest xorg libraries. I know it links to libXrender and libX11 at least, and probably many more. Reffer for documentation in your distro to compile programs for source, and to the fvwm web page for info on how to compile fvwm, in case you need to compile it as well. -- Jesús Guerrero [EMAIL PROTECTED]
Re: Fw: Re: 1-2 minutes to load FvwmButtons on latest CVS
On Wed, 8 Aug 2007 08:51:32 +0100 seventh guardian [EMAIL PROTECTED] wrote: On 8/8/07, Jesús Guerrero [EMAIL PROTECTED] wrote: On Wed, 8 Aug 2007 03:15:31 +0100 seventh guardian [EMAIL PROTECTED] wrote: (snip) Can you please check if this solves your problem? (snip) I just recompiled and it is still the same. But as you say, it is time to go to bed. It is +1 hour around here. Does it happen with the previous minimal config? If not, can you provide one that triggers it? I'm still interested in solving this.. Yes, it happens with that same config. I am sure I am using the correct fvwm snapshot, cause I re-compiled it and saw CVS fetching the events.c file. On the other hand, I haven't been able to reproduce that other bug you discovered. I can click the title bars without any strange side effect. -- Jesús Guerrero [EMAIL PROTECTED]
Re: CVS domivogt: * Write fvwm in lower case everywhere
On Wed, 8 Aug 2007 23:31:08 +0200 Dominik Vogt [EMAIL PROTECTED] wrote: On Wed, Aug 08, 2007 at 09:45:12PM +0100, Thomas Adam wrote: On 08/08/07, Dan Espen [EMAIL PROTECTED] wrote: Dominik Vogt [EMAIL PROTECTED] writes: The standard convention is to spell acronyms in capitals. I never thought of fvwm as an acronym. If we say it's not an acronym then it's not. Sure. Whilst we're there we could also that that whilst we don't need full stops, we won't use them either. That might seem facetious, but it's not meant to be. :P In English, normally proper names are capitalized, like Fvwm, put product names are free to do whatever they like, for example, iMac. Yes, but on this occasion, FVWM *stands* for something -- its name *is* the product name which means correct capitalisation of the acronym. Yes, and laser also stands for something and has become so familiar that almost nobody writes it LASER (or knows what the letters stand for). So what? I am not going into the discussion, it is not a thing I am willing to fight for, I just wanted to make a small comment. The fact that 'laser' is written in lower case is not because it is a lower case acronym, but because of the evolution of the language. New words are created each day. By the day the first LASER device was created, there were no word to name that thingy, and that is why it was named with an acronym: 'LASER'. But language evolved, and a new word was created: 'laser'. So, that argument above is pretty much pointless. Nowadays, 'laser' (lower case) is a word, and no longer an acronym, you can look at the dictionary. Of course, the acronym 'LASER' does exists still. But 'laser', is a word, with a meaning, regardless of its etymology or origin. It is a noun, not an acronym. Any dictionary will tell you the same. That is not the case for 'fvwm', so, the two cases are not comparable. Just my .02 Regards everyone :) -- Jesús Guerrero [EMAIL PROTECTED]
1-2 minutes to load FvwmButtons on latest CVS
Hello, Something strange is happening since a few days. There has been some movement in the CVS lately so I did not want to report this too soon in case it was something that was momentarily broken or something like that. I have one FvwmButtons in the right side of the screen, when I start (or restart, it doesn't make a difference), the FvwmButtons instance loads ok, almost instantly, as it always did. The stuff that will go swallowed on it can also be seen lying around the left upper corner until it gets embedded into the panel. That is ok. But for some reason, even if the panel loads instantly, the pointer shows a busy state and the window decorations doesn't load until that goes away. That can be from 1 to 2 minutes. The cpu is totally iddle, and the memory doesn't show a significant hit during that time. You could say that the problem is elsewhere, not in the FvwmButtons. I could also say that, if it wasn't because I have tested this minimal configuration, and the same thing happens: = # PANEL DestroyModuleConfig foo: * *FvwmTaskbar: Frame 1 *FvwmTaskbar: Colorset 6 *FvwmTaskbar: Rows 1 *FvwmTaskbar: Columns 1 *FvwmTaskbar: (1x1, Title foo) Module FvwmButtons -g 100x100-0+0 foo = I name this ~/.fvwm/config, and restart fvwm. I can see foo in the right upper corner, but the cursor hangs for over a minute or even more some times. After that, it just goes to normal state, the window decos appear and I can click anywhere to get the nice fvwm default menu. No patches, no-thing, just current cvs, on amd64. = # fvwm -version fvwm 2.5.22 (from cvs) compiled on Aug 8 2007 at 03:01:47 with support for: ReadLine, XPM, PNG, Shape, XShm, SM, XRender, XCursor, XFT, NLS = The only strange things are amd64, gcc-4.2 and glibc-2.6. Has anyone else experienced this issue? It's getting a bit annoying the fact that I have to wait a couple of minutes to go from console to X. Regards. -- Jesús Guerrero [EMAIL PROTECTED]
Re: Fw: Re: 1-2 minutes to load FvwmButtons on latest CVS
On Wed, 8 Aug 2007 03:15:31 +0100 seventh guardian [EMAIL PROTECTED] wrote: Are you starting FvwmButtons outside the StartFunctions? That's not what the man page recomends :P If you started it inside StartFunction it would work fine. But that was a good thing after all :) Yep, I know it is not a good thing to do. But until now it never exhibited this problem. I can, however, re-think my config in a smarter way. It should not need too much changes. That is not a problem. Can you please specify when this started to happen? It would help identifying the change that led to the bug.. I am not quite sure, but making some memory, I am pretty sure I saw this behaviour on Saturday night, at 21:40, because I was waiting for someone at that concrete hour. I live in GMT+1. I can't tell you if the bug was the present the day before, or even a couple of days before. I rarely restart anything unless I need to, that is why it might have been unnoticed for days. But I usually restart fvwm always after recompiling it. So, there is a big chance that the submission of the buggy piece was around that time or little earlier. I can't be sure, though. Yep, I believe I was the one who introduced the bug recently. It was a problem with startup modules, hopefuly solved now. Well, I guess no release until we get this sorted out.. Can you please check if this solves your problem? Thank you for your quick response. You're welcome. Now I must get some sleep.. Its 3:19 AM :) I just recompiled and it is still the same. But as you say, it is time to go to bed. It is +1 hour around here. Thank you for everything :) -- Jesús Guerrero [EMAIL PROTECTED]
Re: Fw: Re: 1-2 minutes to load FvwmButtons on latest CVS
On Wed, 8 Aug 2007 04:27:23 +0200 Jesús Guerrero [EMAIL PROTECTED] wrote: As you said, it is easily solved just by Read'ing the file holding the panel info from within StartFunction. Thanks again. Now it is time to sleep. :) -- Jesús Guerrero [EMAIL PROTECTED]
Re: FLCXOMCharset again
Hello, Dominik, On Sat, 28 Jul 2007 11:36:09 +0200 Dominik Vogt [EMAIL PROTECTED] wrote: See below. --- libs/FlocaleCharset.c 2006-12-09 19:43:39.0 +0100 +++ libs/FlocaleCharset.c 2006-12-09 19:46:38.0 +0100 @@ -522,7 +522,7 @@ } if (FLCXOMCharsetList_num 0 FLCXOMCharsetList[0]) - FLCXOMCharset = FLCXOMCharsetList[0]; + FLCXOMCharset = FLCXOMCharsetList[FLCXOMCharsetList_num - 1]; #endif } What is special about the last entry in the charset list? Or are we just picking some random entry and hope that it works? Well, this is the output of PrintInfo Locale 1 on my system: *** FVWM info on locale: locale: es_ES.utf8, Modifier: Default Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No XOM Charsets: ISO8859-1 ISO8859-1 JISX0208.1983-0 KSC5601.1987-0 GB2312.1980-0 JISX0201.1976-0 ISO10646-1 Number of loaded font: 4 * Font number 0 fvwm info: Name: Shadow=0 0:xft:DejaVu Sans:style=Bold:size=7 Cache count: 9 Type: XftFont Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No height: 13, ascent: 11, descent: 3 shadow size: 0, shadow offset: 0, shadow direction:0 * Font number 1 fvwm info: Name: Shadow=0 0:xft:DejaVu Sans:size=7:styName: Shadow=0 0:xft:DejaVu Sans:size=7:style=Bold Cache count: 1 Type: XftFont Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No height: 13, ascent: 11, descent: 3 shadow size: 0, shadow offset: 0, shadow direction:0 * Font number 2 fvwm info: Name: Shadow=0 0:xft:DejaVu Sans:style=Condensed:size=7.2 Cache count: 1 Type: XftFont Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No height: 13, ascent: 11, descent: 3 shadow size: 0, shadow offset: 0, shadow direction:0 * Font number 3 fvwm info: Name: 0 Cache count: 1 Type: XftFont Charset: X: ISO10646-1, Iconv: UTF-8, Bidi: No height: 13, ascent: 11, descent: 3 shadow size: 0, shadow offset: 0, shadow direction:0 *** I don't know how the XOM charsets are usually ordered. In case that someone known, drop me a note. I will research about it, and try to find an all-cases solution. But, it is crystal-clear to me that the actual state of the things is not the correct one either. It is not less random than the choice that the patch makes, it just takes the other extreme of the array, but, as shown in the links I posted, and my own case, this is not correct, at least, not for utf8 systems. For now, I just have the empiric note that it works on all systems I tried, better than [0], but I did not try non-alphabetic languages, nor Arabic... so, that belief of mine might be completely false. If someone has some info about the issue that could be helpful, let me know. I will research about the patch, and try to explain how it works so we can discard it. If that happens, I will try to design a better patch that can handle all the locales properly. -- Jesús Guerrero [EMAIL PROTECTED]
Re: FLCXOMCharset again
On Sat, 28 Jul 2007 13:12:08 +0200 Jesús Guerrero [EMAIL PROTECTED] wrote: I don't know how the XOM charsets are usually ordered. FLCXOMCharsetList is generated from a XOMCharSetList entity (cs), I am not much into Xlib, and, besides having read chap 13 or the xlib docs, I cannot find how this structure is initialized, so, I will have to look a bit further into the xlib stuff and see what can I dig. Regards. -- Jesús Guerrero [EMAIL PROTECTED]
FLCXOMCharset again
Hello, Some of you (those not using iso8859-1/15) might know that vanilla Fvwm is not capable of showing accents and such things on the menus. This has come a number of times on forums.gentoo.org and fvwm.lair.be. Probably, in many more places. http://fvwm.lair.be/viewtopic.php?f=6t=1402hilit= http://forums.gentoo.org/viewtopic-p-4047950-highlight-.html?sid=3025a66762f485e4d916bb8c3ae08e66 Just to put a couple of examples, though I am sure I have seen this question much more times, and answered it a lot of times via IM or whatever. I found a bug that someone reported some time ago as well: http://www.fvwm.org/cgi-bin/fvwm-bug/incoming?id=1647;page=4;user=guest Which basically, uses the same patch I do, and that is attached to this mail. I haven't been able to find any reason why this patch has not been merged, I am not completely sure, since I have an utf8'ized system, and can't try, but I have some reports of this working on iso8859 systems as well. The patch seems to work ok, and it is the only way I can correctly spell my native language on FVWM. If there is something obvious that I am missing, just let me know. -- Jesús Guerrero [EMAIL PROTECTED] --- libs/FlocaleCharset.c 2006-12-09 19:43:39.0 +0100 +++ libs/FlocaleCharset.c 2006-12-09 19:46:38.0 +0100 @@ -522,7 +522,7 @@ } if (FLCXOMCharsetList_num 0 FLCXOMCharsetList[0]) - FLCXOMCharset = FLCXOMCharsetList[0]; + FLCXOMCharset = FLCXOMCharsetList[FLCXOMCharsetList_num - 1]; #endif }
Re: Can't compile current CVS (cp ./index.html index.html)
On Tue, 17 Jul 2007 00:13:07 +1000 Scott Smedley [EMAIL PROTECTED] wrote: This seems something trivial, but I can't seem to find the real solution. Ditto. (See the Problems building snap-20070713 thread.) Just out of curiosity, what distro are you using? what version of make? Scott. Yep, I noticed that thread. I use Gentoo, and right now, this is my make: # LC_ALL=C make -v GNU Make 3.81 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This program built for x86_64-pc-linux-gnu -- Jesús Guerrero [EMAIL PROTECTED]
Can't compile current CVS (cp ./index.html index.html)
Hello, This seems something trivial, but I can't seem to find the real solution. ** Making all in doc make[2]: Entering directory `/var/tmp/portage/x11-wm/fvwm--r10/work/fvwm/doc' cp ./index.html index.html Making all in fvwm cp: `./index.html' and `index.html' are the same file make[2]: *** [index.html] Error 1 make[2]: *** Waiting for unfinished jobs [blah blah blah] ** For now, it just compiles fine if you comment out the offending lines in the Makefile. Patch to illustrate the workaround (I know it is not a solution :P ): ** --- doc/Makefile.am 2007-07-15 12:46:07.0 +0200 +++ doc/Makefile.am 2007-07-14 20:57:34.0 +0200 @@ -19,5 +19,5 @@ all: $(HTML_FILES) +#%.html: $(srcdir)/$@ +# cp $(srcdir)/$@ $@ -%.html: $(srcdir)/$@ - cp $(srcdir)/$@ $@ -- ** Regards :) Jesús Guerrero [EMAIL PROTECTED]
PictureImageLoader stuff broken when using --without-xpm-library
Hello, Probably some of the latest changes is breaking this. * In file included from /usr/include/zlib.h:34, from /usr/include/png.h:398, from Fpng.h:12, from PictureImageLoader.c:46: /usr/include/zconf.h:265: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'typedef' /usr/include/zconf.h:274: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'Bytef' In file included from /usr/include/png.h:398, from Fpng.h:12, from PictureImageLoader.c:46: /usr/include/zlib.h:83: error: expected specifier-qualifier-list before 'Bytef' /usr/include/zlib.h:114: error: expected specifier-qualifier-list before 'Bytef' /usr/include/zlib.h:538: error: expected ';', ',' or ')' before '*' token /usr/include/zlib.h:736: error: expected ';', ',' or ')' before '*' token /usr/include/zlib.h:1009: error: expected ')' before '*' token /usr/include/zlib.h:1024: error: expected ')' before '*' token /usr/include/zlib.h:1047: error: expected ')' before '*' token /usr/include/zlib.h:1260: error: expected ';', ',' or ')' before '*' token /usr/include/zlib.h:1285: error: expected ';', ',' or ')' before '*' token PictureImageLoader.c: In function 'PImageLoadCursorFromFile': PictureImageLoader.c:873: error: 'FxpmInfo' undeclared (first use in this function) PictureImageLoader.c:873: error: (Each undeclared identifier is reported only once PictureImageLoader.c:873: error: for each function it appears in.) PictureImageLoader.c:873: error: expected ';' before 'xpm_info' PictureImageLoader.c:875: warning: implicit declaration of function 'XpmReadFileToXpmImage' PictureImageLoader.c:875: error: 'xpm_info' undeclared (first use in this function) make[2]: *** [PictureImageLoader.o] Error 1 make[2]: *** Waiting for unfinished jobs mv -f .deps/Parse.Tpo .deps/Parse.Po make[2]: Leaving directory `/var/tmp/portage/x11-wm/fvwm--r12/work/fvwm/libs' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/x11-wm/fvwm--r12/work/fvwm' make: *** [all] Error 2 * It just compiles fine if I configure without the --without-xpm-library flag. Regards. -- Jesús Guerrero [EMAIL PROTECTED]
Re: Problems building snap-20070419
Hello, El Thu, 19 Apr 2007 03:01:46 -0500 Jason L Tibbitts III [EMAIL PROTECTED] escribió: rm -f fvwm.ar.gmo /usr/bin/msgfmt -c --statistics -o fvwm.ar.gmo fvwm.ar.po fvwm.ar.po:57:10: invalid multibyte sequence fvwm.ar.po:57:12: invalid multibyte sequence /usr/bin/msgfmt: found 2 fatal errors make[1]: *** [fvwm.ar.gmo] Error 1 make[1]: Leaving directory `/home/tibbs/fvwm/po' make: *** [distdir] Error 1 Mmm, strange. Someone changed the string for the arabic translation for More I will not discuss that, cause I don't know any word of Arabic, but looking at it, I see this: msgstr أ٣^ãثر, which seems to be weird. I am not an Arab, but, I bet that that is not correct, uh? The original translation I did was this: أكثر Taken from google, and maybe, not too accurate. Maybe seventhguardian or someone can give a better insight on what happened. Anyhow, if that is the problem, I wonder why is it working for me and some other people. I *think* that the format of the file was messed in the middle, it might have been my MTA or any other thing. All the files I provide *should* be encoded at utf8, if not, there's a problem in the middle. Maybe that was what happened to this patch... And now that I say that... Does someone know why some po files are not using utf8, but iso-8859-whatever? I think they all should be converted. I might make a patch for that, this time, gzipped to avoid any chance that my mail servers mess up my encoding. But I doubt that is the cause... -- Jesús Guerrero
Re: Problems building snap-20070419
El Thu, 19 Apr 2007 19:14:01 +0100 seventh guardian [EMAIL PROTECTED] escribió: It doesn't look good either, but I have no idea on how this should be done.. I will remove the arabic translation for now, hoping someone will do it right eventually.. I think the only right solution, is the total migration to utf8, in which regards the po/ directory. Of course, that implies that to manipulate the files, you will need an unicode capable environment. But it is the only way that you can edit files with different character sets without messing it all up. Converting the files to utf8 is trivial for me, I can easily do that. I can also patch the .po files which have a different charset, to use utf8. Since it is a technical patch, and not a proper locale edition, I don't see a reason to regenerate them, so, original authors and such will still be kept. I can do that and submit the files into a tarball, so we make sure they are not messed in the way. But that would only work if the files are used to substitute the ones in the cvs repository. Any copy paste done in a non utf8 aware environment or with a non aware editor can mess them up again. Anything that's non-utf8 is just not ok when you have to deal with multiple encodings (for me). Let me know what do you think about the idea. As you can see, at the current state, this is just a mess: [snip] $ for i in *.po; do echo -n $i - ; enca -L none $i; done fvwm.ar.po -Universal transformation format 8 bits; UTF-8 Surrounded by/intermixed with non-text data fvwm.de.po -Unrecognized encoding fvwm.fr.po -Unrecognized encoding FvwmScript.ar.po -7bit ASCII characters FvwmScript.de.po -Unrecognized encoding FvwmScript.fr.po -Unrecognized encoding FvwmScript.sv_SE.po -Unrecognized encoding FvwmScript.zh_CN.po -Universal transformation format 8 bits; UTF-8 fvwm.sv_SE.po -Unrecognized encoding FvwmTaskBar.ar.po -Universal transformation format 8 bits; UTF-8 FvwmTaskBar.de.po -7bit ASCII characters FvwmTaskBar.fr.po -7bit ASCII characters FvwmTaskBar.sv_SE.po -Unrecognized encoding FvwmTaskBar.zh_CN.po -Universal transformation format 8 bits; UTF-8 fvwm.zh_CN.po -Universal transformation format 8 bits; UTF-8 [/snip] That is, just like the files are in the repo. A complete mess. All the files should be enconded the same, and the charset line in the po files, changed to reflect utf8. Let me know what do you think, and if there is nothing wrong with this, I will do the job and briefly submit a gzipped tarball to avoid problems with the encoding getting messed in the way. -- Jesús Guerrero
Re: FVWM: Small localization patch
El Wed, 18 Apr 2007 16:12:57 +0100 seventh guardian [EMAIL PROTECTED] escribió: Hello, * First of all, the ChangeLog for the localization files is on the po/ subdir. * The translation entries have a description on top of them that help locating the code to which they apply, so I've added that. * Finally I've compacted a bit the manual page entry and the main ChangeLog entry: usually you don't need a throughly explanation of the changes, a simple note suffices (and usually is more readable). You can check the reviewed patch (on annex), which should help you next time. Other than that, good work :) Thanks for all the notes and corrections. They are much appreciated. In the future I will try to make it better. Thanks for all the attention and your patience. I am glad to be helpful even if it is just a very small piece of the puzzle. -- Jesús Guerrero
Re: CVS renato: Applied Jesus Gerrero's patch (added translation to the More... string)
El Thu, 19 Apr 2007 09:33:22 +1000 Scott Smedley [EMAIL PROTECTED] escribió: Please update the XML documentation. See doc/README file for more info. In this instance, you will need to edit: doc/fvwm/menus.xml Ops, sorry, I completely forgot about that thing. Another thing to annotate for the next patch :) Thank you. -- Jesús Guerrero
Re: FVWM: Small localization patch
El Tue, 17 Apr 2007 15:55:44 +0100 seventh guardian [EMAIL PROTECTED] escribió: Oh!! Sorry for the mess, I was the one who didn't check! [embarassed] Anyway, it's probably better to keep this discussion on the workers list... Sorry, I forgot to include the Changelog entry, new patch attached. Ok, I'll check it as soon as I have some time.. Maybe tonight. Cheers, Renato Nah, I am the one that posted wrongly, and the one to be sorry. The discussion started at fvwm-workers, but I got someone confused in the middle and started posting at [EMAIL PROTECTED] at some point. Don't hesitate to correct me if I do something wrong, and forgive me, please, for any inconvenience caused by my incompetence. -- Jesús Guerrero
