I don’t know if this could be caused by the patches, the version of fvwm that I am using, or my shotty coding…but anytime I try to close gaim fvwm exits (crashes?)
I can reproduce the problem. Do you guys have any idea what the problem could be?
fvwm 2.5.17 (from cvs) compiled on May 30 2006 at 23:24:27
with support for: XPM, PNG, Shape, XShm, SM, XRender, NLS
Set an appropriate ulimit before you start FVWM:
ulimit -c 9000
exec fvwmIf FVWM crashes, obtain a backtrace:
gdb fvwm ./core
(gdb) where– Thomas Adam
I don’t really understand what I am suppose to do. I tried to type “ulimit -c 9000” then startx fvwm…but that didn’t do anything 
Can you be more specific or point me in the direction of something I can read to figure this out. I couldn’t find “ulimit” in the man pages. Thanks for your help.
edit: I use gdm–if it matters.
OK. “ulimit” is a shell builtin. I am assuming you’re using bash. Most distributions disable core file generation from applications because generally nobody bothers with them. It used to be the case long ago that most of the “housekeeping” distributions did used to search for them and remove them. Of course, this was suboptimal if one was able to turn them off. So, we need to ensure that you can at least create them.
Ditch GDM for the moment, and switch back to the console with no X11 running. If you type in xinit, you should just get presented with a terminal. Into that type:
ulimit -c 90000That just informs the current shell that we’re allowing core-file creation to be no more that that size in bytes. Then type:
fvwm… and go about your business. Make it crash. When it does so, if you:
ls $HOME/core… you should see that file. If it’s there, it would be nice to analyse it, for which you’ll need to install the GNU Debugger (gdb). The command you’ll need to use is:
gdb fvwm ~/core… that forces gdb to load fvwm whilst analysing the corefile during its execution. To see what went wrong, at gdb’s prompt you can type in the command “where” (or “bt”), hence:
(gdb) where… which should spit out some information — indeed, it’s this information I am interested in.
– Thomas Adam
Thanks for the help Thomas. I am at work from 3-11 tonight but I will do that as soon as I get home and post the results.
The oddest thing is happening. This is what error I get when gaim crashes fvwm (via gdb: where):
code where
#0 __get_corner (corner=PART_BORDER_NW, fw=0x0) at frame.c:2193
#1 0x08091e75 in frame_make_rounded_corners (fw=0x0) at frame.c:2249
#2 0x08073bf6 in AddWindow (exc=0x81503d0, ReuseWin=0x0, win_opts=0xbff75760)
at add_window.c:2566
#3 0x08066160 in HandleMapRequestKeepRaised (ea=0xbff757f4, KeepRaised=0,
ReuseWin=0x0, win_opts=0xbff75760) at events.c:2859
#4 0x0806659c in HandleMapRequest (ea=0xbff757f4) at events.c:2800
#5 0x08067b86 in dispatch_event (e=0xbff75824) at events.c:3855
#6 0x08067c99 in HandleEvents () at events.c:3896
#7 0x0808b32c in main (argc=1, argv=0xbff75f24) at fvwm.c:2529
[/code]
The odd thing is…if I have gdb fvwm ~/core running WHEN I open and attempt to close gaim–it doesn’t crash fvwm. 0_o
Looks like a null pointer. To fix, edit fvwm/frame.c and change line 2244 from
if (!FShapesSupported)to
if (!FShapesSupported || fw == 0)Test it and see if it works. I’ll upload some fixes soon.
Alright, I will fix it as soon as I get home 
EDIT:
WORKS LIKE A CHARM 8) Thanks for your help!
I get this strange error:
[FVWM][__execute_function]: <<ERROR>> Command can not be added to a decor; executing command now: 'ButtonState Hover true'It works, but, why this error?
I use a gentoo with fvwm patched with fvwm-9999…so from cvs.
BTW, great patches! You rocks!
–
Vieri
It can’t be used with addtodecor, you should put “buttonstate hover true” on a line of its own. If you have, then posting your config would help.
This command should have the same behaviour of commands such as “buttonstate activedown true” which works in previous versions. Anyone know if this can work with addtodecor?
None of the commands in an “AddToDecor” block, actually need to exist as a member of a decor – it’s just for convenience that they’re defined this way.
– Thomas Adam
i’m trying to use the RoundedCorners patch but i can’t find any style.c file…
im’working in: /usr/lib/fvwm/2.5.16 or /usr/share/fvwm but doesn’t work
I have changed the patches slightly and uploaded them to the webpage:
Applied against 2.5.18
FluxboxHandles changes height based on handlewidth (must update your config to use), and width based on cornerwidth (a new style).
FluxboxHandles can display corners in a different color.
MultiBorder and RoundedCorners can now be used with menus.
MultiBorder tries to display consistent titlebars when shaded.
New patches for padding and rounded buttons on FvwmIconMan.
Simple patch for thin outline on FvwmProxy and geometry windows.
Download the source code for 2.5.18 and apply the patch in that directory. Then ./configure && make; make install.
or you can try downloading this archive abdn.ac.uk/~u15dm4/fvwm/fvwm-2.5 … hed.tar.gz and install it.
Cool ! 
I will update my CVS ebuild tonight, and test it 
Are all the patches independant this time ?
I have a bug with FluxboxHandles : see my left buttons decorations when I use Style * HandleWidth 5 here 
My last screenshot to compare (don’t worry, I will post it when finished 
).
And it seems that some patches still need others to apply correctly (Fluxbox handles need BorderUnderTitle for example).
However, nice job
They have the same dependance as before. I’m not sure if it’s possible to make them work in any combination because of the way diff/patch works. Making all patches against 2.5.18 has the problem that multiple changes to the same function are ambiguous at best. Maybe some of them could be merged together.
I’m not sure if the added complexity of making this work has many advantages. Applying all the patches together shouldn’t have much overhead or undesired behaviour. If there are any particular problematic patches, then I could separate them.
Can you post some sample decor config that causes this?
Here is the related part :
[code]Colorset 10 fg #808080, bg white, hi #ffffff, sh #cccccc, IconAlpha 60
Colorset 11 fg black, bg white, hi #ffffff, sh #cccccc, IconAlpha 100
Colorset 20 fg black, bg white
DestroyDecor recreate White
AddToDecor White
TitleStyle Centered Height 16 ButtonWidth 20
TitleStyle AllActive MultiPixmap Main White/main.png, LeftButtons White/buttons.png, RightButtons White/buttons.png – flat
TitleStyle AllInactive MultiPixmap Main White/main.png, LeftButtons White/buttons.png, RightButtons White/buttons.png – flat
ButtonStyle 1 Active (Pixmap White/winmenu.png) ActiveDown (Pixmap White/winmenup.png) Inactive (Simple) - Clear
ButtonStyle 2 Active (Pixmap White/close.png) ActiveDown (Pixmap White/closep.png) Inactive (Simple) - Clear
ButtonStyle 3 Active (Pixmap White/ontop.png) ActiveDown (Pixmap White/ontopp.png) Inactive (Simple) - Clear
ButtonStyle 4 Active (Pixmap White/max.png) ActiveDown (Pixmap White/maxp.png) Inactive (Simple) - Clear
ButtonStyle 5 Active (Pixmap White/onbottom.png) ActiveDown (Pixmap White/onbottomp.png) Inactive (Simple) - Clear
ButtonStyle 6 Active (Pixmap White/min.png) ActiveDown (Pixmap White/minp.png) Inactive (Simple) - Clear
ButtonStyle All – Flat UseTitleStyle
BorderStyle Simple, Colorset 20 – Flat HiddenHandles NoInset
Style * BorderWidth 1, Handles, FluxboxHandles, HandleWidth 5, CornerWidth 20
Style * !StickyWindowStipples, !IconStickyStipples
Style * Colorset 10, HilightColorset 11
Style * IndexedWindowName, IndexedIconName
Style * UseDecor White
Style * Font “xft:DejaVu Sans:pixelsize=11:style=Book:rgba=rgb:minspace=true:antialias=True”[/code]
EDIT: was wrong HandleWitdh 
