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
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.
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 90000
That 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.
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
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.
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.
I have a bug with FluxboxHandles : see my left buttons decorations when I use Style * HandleWidth 5hereMy 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).
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.