Re: FVWM: icons
found the error. was something in my settings that screwed thinks up. sorry for bothering ingo
Re: FVWM: icons
On 04/25/2013 10:38 PM, Dan Espen wrote: Ingo Wardinski writes: Dear all, perhaps, this is a problem with a very simple solution. I try to force applicitions to iconify without icons. So I set Style "Thunderbird" NoIcon,!IconTitle and Style * NoIcon this is working for xterm, but not for thunderbird, firefox emacs and some others. Certainly, I'm overlooking something simple here any help would be very much appreciated I can't duplicate the problem. The applications you mention provide their own icons which is controlled by the IconOverride style. (You can get xterm to generate it's own icon using the -ai option.) I tried to duplicate the problem using IconOverride, couldn't do it but you might still want to look at whether you use IconOverride. What release of fvwm are you using? I'm using 2.5.30. that's the version which comes with ubuntu 12.04 (lts). Are you saying I should set Style * NoIcon, IconOverride I also tried Style ** EWMHMiniIconOverride, IconOverride but strangely this is working for the first time I minimize the application and the second time the application the icon appears again. greets ingo
FVWM: icons
Dear all, perhaps, this is a problem with a very simple solution. I try to force applicitions to iconify without icons. So I set Style "Thunderbird" NoIcon,!IconTitle and Style * NoIcon this is working for xterm, but not for thunderbird, firefox emacs and some others. Certainly, I'm overlooking something simple here any help would be very much appreciated greets ingo
Re: FVWM: windowlist question
Good Morning, I had a look at FvwmWindowMenu, and I have a couple of questions. Is there a way to sort the window entries in FvwmWindowMenu either by class name, or any other criteria? The manpage says that menu entries are placed by WindowListFunc. How could I sort entries by using WindowListFunc? Also, I would like to perform different actions on the entries of FvwmWindowMenu, e.g. warptowindow or move the window to this page. I was thinking to define some submenus with addtomenu and popup actions. Has anyone done something like that before and would give some advice? I also would like to print the specific page number of a window, and the manpage of FvwmWindowMenu gives the format specifiers of the item string, but there is no specifier for the page number. Am I right? I would be very happy if that could be included in a future version of FvwmWindowMenu. Thanks in advance ingo
Re: FVWM: windowlist question
[ On Tuesday, November 8, 2011 at 18:35:30 (+), Thomas Adam wrote: ] > Subject: Re: FVWM: windowlist question > > On Tue, Nov 08, 2011 at 07:09:37PM +0100, Ingo Wardinski wrote: > > Hi there, > > this afternoon I was playing around with fvwmiconman, windowlist and > > fvwmwinlist just to figure out what may be the best for me. So > > Do not use FvwmWinList for anything. > > > windowlist is my favorite. Unfortunately, I cannot tweak it not to > > display miniicons. I set something like > > Mouse 2 R A WindowList NoCurrentDeskTitle, NoGeometry, \ > > CurrentAtEnd, NoIcons, MaxLabelWidth 50, SelectOnRelease Alt_L > > > > This works also when the options are not seperated by comas. I also > > No -- this is simply a facet of ParseTokens(). > > > tried the fvwmwinlist module, but I cannot avoid icons be displayed, > > unless I discard definitions of miniicons for applications. > > Correct. How else is the WindowList to know which miniicons to use? Ok, this was my question, actually. I will have a look on FvwmWindowMenu too. thanks ingo
FVWM: windowlist question
Hi there, this afternoon I was playing around with fvwmiconman, windowlist and fvwmwinlist just to figure out what may be the best for me. So windowlist is my favorite. Unfortunately, I cannot tweak it not to display miniicons. I set something like Mouse 2 R A WindowList NoCurrentDeskTitle, NoGeometry, \ CurrentAtEnd, NoIcons, MaxLabelWidth 50, SelectOnRelease Alt_L This works also when the options are not seperated by comas. I also tried the fvwmwinlist module, but I cannot avoid icons be displayed, unless I discard definitions of miniicons for applications. I'm currently running fvwm 2.5.26 on linux (2.6.32-34) Any help would be very much appreciated ingo
FVWM: fvwmiconman question
Hi there, I try to set up fvwmiconman for my needs, therefore I use the conig given in the fvwmiconman manpage. There is a line saying FvwmIconMan: Action Mouse 1 N sendcommand Iconify What does the N stands for? and; can I swallow fvwmiconman into fvwmbuttons? TIA and greets, ingo
FVWM: acroread9 -- Where's the minimize button?
[ On Friday, October 28, 2011 at 14:12:09 (-0700), Ronald F. Guilmette wrote: ] > Subject: FVWM: acroread9 -- Where's the minimize button? > > > Is it just me, or has anyone else experienced an oddity where the window > containing acroread, unlike all other applications windows, fails to have > a standard sort of minimization button in the upper right hand corner of the > window frame? > > Is this is a known problem? > > Is there a workaround? buttons are working for me on a acroread window (fvwm2.5.26) You want to set Style * MWMFunctions, MWMDecor, HintOverride greets, ingo
Re: FVWM: EWMH hints and fvwm
[ On Saturday, October 9, 2010 at 14:01:15 (+0100), Thomas Adam wrote: ] > Subject: Re: FVWM: EWMH hints and fvwm > > On Sat, Oct 09, 2010 at 02:54:33PM +0200, Ingo Wardinski wrote: > > Hi there, > > I have a simple question concerning ewmh and fvwm. Recently I was > > forced to recompile fvwm on my machine, since then I have been getting > > (.xsession-errors) > > > > [fvwm][__execute_function]: <> No such command > > 'EWMHActivateWindowFunc' > > > > which caused by this line in my settings > > > > DestroyFunc EWMHActivateWindowFunc > > > > at least this is the only occurence of it. I thought that I have > > missed something while compiling fvwm, because > > Yes -- that's right. Some actions on windows (such as when activity happens > if a window were in a EWMH-compliant taskbar) would trigger this window. > The error is harmless in this case, and you're definitely better off doing: > > DestroyFunc EWMHActivateWindowFunc > > Than you are doing this: > > AddToFunc EWMHActivateWindowFunc I Nop > > As that still grabs the window, which might be undesirable in some > situations. But either way, FVWM will still spit that line out to STDERR if > the function cannot be found, as the code expects to call it. > > > fvwm --version gives > > > > fvwm 2.5.26 compiled on Oct 8 2010 at 12:29:31 > > with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, > > SM, Xinerama, XRender, XCursor, XFT, NLS > > > > How can I add EWMH hints to the support list? I guess this is done > > while configuring the makefile, at least the manpage is telling that > > it should be possible to compile fvwm with EWMH hints. > > No, you get them all for free, you can't turn them off. Thanks for reply, this is good to know. > > > p.s.: For some reasons I would like to stay with fvwm 2.5.26 > > Why? Well, it is not a profound reasoning, but I do have a collection of patches for round corners, translucency, and some other fancy features which only applies to this version. I'm not skilled enough to port them to a more recent version. greetz, ingo
FVWM: EWMH hints and fvwm
Hi there, I have a simple question concerning ewmh and fvwm. Recently I was forced to recompile fvwm on my machine, since then I have been getting (.xsession-errors) [fvwm][__execute_function]: <> No such command 'EWMHActivateWindowFunc' which caused by this line in my settings DestroyFunc EWMHActivateWindowFunc at least this is the only occurence of it. I thought that I have missed something while compiling fvwm, because fvwm --version gives fvwm 2.5.26 compiled on Oct 8 2010 at 12:29:31 with support for: ReadLine, RPlay, Stroke, XPM, PNG, SVG, Shape, XShm, SM, Xinerama, XRender, XCursor, XFT, NLS How can I add EWMH hints to the support list? I guess this is done while configuring the makefile, at least the manpage is telling that it should be possible to compile fvwm with EWMH hints. What would be the right optio(s)? many thanks in advance ingo p.s.: For some reasons I would like to stay with fvwm 2.5.26
Re: FVWM: focus question
[ On Wednesday, June 10, 2009 at 16:23:09 (+0100), Thomas Adam wrote: ] > Subject: Re: FVWM: focus question > > 2009/6/10 Ingo Wardinski : > > Hi all, > > I recently upgraded to fvwm 2.5.26. Since then I have been observing > > that gnuplot x11 windows steal focus. for instance, I type a gnuplot > > plotting command in an xterm then window showing the plot is getting > > the focus even if the mouse is not in this window. In order to put the > > focus back on my xterm I have to move the mouse out of the xterm and > > back in. Sometimes, I feel very unpleasant with this behaviour. > > Further details, I use: > > ColormapFocus FollowsFocus > > Style * GrabFocusOff > > Style * MouseFocus > > Style * SloppyFocus > > This is silly -- in this case SloppyFocus overrides the definition for > MouseFocus -- so remove the MouseFocus style completely. > > > # > > I tried > > > > Style Gnuplot FPClickToFocus, !FPFocusByProgram > > You would have meant "!FPFocusByFunction" in this case, and -not- > !FPFocusByProgram since in this case, the GnuPlot window you're > describing is subject to the EWMHActivateWindowFunc -- the actual > solution to your problem would be the following: > > DestroyFunc EWMHActivateWindowFunc > > ... as many users find the default behaviour annoying. > > -- Thomas Adam Thanks, it werks. ingo
FVWM: focus question
Hi all, I recently upgraded to fvwm 2.5.26. Since then I have been observing that gnuplot x11 windows steal focus. for instance, I type a gnuplot plotting command in an xterm then window showing the plot is getting the focus even if the mouse is not in this window. In order to put the focus back on my xterm I have to move the mouse out of the xterm and back in. Sometimes, I feel very unpleasant with this behaviour. Further details, I use: ColormapFocus FollowsFocus Style * GrabFocusOff Style * MouseFocus Style * SloppyFocus # I tried Style Gnuplot FPClickToFocus, !FPFocusByProgram which doesn't change the above behaviour I start gnuplot like gnuplot -noraise. Finally, xprop tells me: WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _WIN_AREA(CARDINAL) = 6, 0 _WIN_WORKSPACE(CARDINAL) = 0 _WIN_LAYER(CARDINAL) = 4 _WIN_STATE(CARDINAL) = 0 _NET_FRAME_EXTENTS(CARDINAL) = 1, 1, 20, 1 _KDE_NET_WM_FRAME_STRUT(CARDINAL) = 1, 1, 20, 1 _NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_SHADE, _NET_WM_ACTION_STICK _NET_WM_DESKTOP(CARDINAL) = 0 _NET_WM_ICON_VISIBLE_NAME(UTF8_STRING) = 0x47, 0x6e, 0x75, 0x70, 0x6c, 0x6f, 0x74, 0x20, 0x28, 0x77, 0x69, 0x6e, 0x64, 0x6f, 0x77, 0x20, 0x69, 0x64, 0x20, 0x3a, 0x20, 0x30, 0x29 _NET_WM_VISIBLE_NAME(UTF8_STRING) = 0x47, 0x6e, 0x75, 0x70, 0x6c, 0x6f, 0x74, 0x20, 0x28, 0x77, 0x69, 0x6e, 0x64, 0x6f, 0x77, 0x20, 0x69, 0x64, 0x20, 0x3a, 0x20, 0x30, 0x29 WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x420008b bitmap id # of mask for icon: 0x420008c window id # of group leader: 0x421 _NET_WM_ICON(CARDINAL) = 64, 64, [!!!numbers deleted, otherwise the mail is getting to long!!!] _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x3e, 0x7e, 0x0, 0x0 _NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 69206153 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL _NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x4200088 WM_CLIENT_LEADER(WINDOW): window id # 0x421 _NET_WM_PID(CARDINAL) = 26516 WM_LOCALE_NAME(STRING) = "C" WM_CLIENT_MACHINE(STRING) = "mag33" WM_NORMAL_HINTS(WM_SIZE_HINTS): program specified location: 0, 0 program specified minimum size: 100 by 100 window gravity: NorthWest WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST WM_CLASS(STRING) = "", "" WM_ICON_NAME(STRING) = "Gnuplot (window id : 0)" _NET_WM_ICON_NAME(UTF8_STRING) = 0x47, 0x6e, 0x75, 0x70, 0x6c, 0x6f, 0x74, 0x20, 0x28, 0x77, 0x69, 0x6e, 0x64, 0x6f, 0x77, 0x20, 0x69, 0x64, 0x20, 0x3a, 0x20, 0x30, 0x29 WM_NAME(STRING) = "Gnuplot (window id : 0)" _NET_WM_NAME(UTF8_STRING) = 0x47, 0x6e, 0x75, 0x70, 0x6c, 0x6f, 0x74, 0x20, 0x28, 0x77, 0x69, 0x6e, 0x64, 0x6f, 0x77, 0x20, 0x69, 0x64, 0x20, 0x3a, 0x20, 0x30, 0x29 Any help would be very much appreciated. ingo
Re: FVWM: Off topic: Weather applet
[ On Thursday, September 18, 2008 at 20:31:23 (+0200), Ingo Wardinski wrote: ] > Subject: Re: FVWM: Off topic: Weather applet > > [ On Thursday, September 18, 2008 at 11:01:08 (-0700), Perry Hutchison wrote: > ] > > Subject: Re: FVWM: Off topic: Weather applet > > > > > http://xoap.weather.com/weather/local//GMXX0109?dayf=5&unit=m). > > > However, since a while I can't get the current weather only the > > > forecast for 5 days ... > > > > I know nothing at all about xoap, but that "dayf=5" in the URL > > sure looks like a request for a 5-day forecast. Maybe visit > > the site with a browser, and see what kind of URLs are involved > > in retrieving current conditions? > I found the missing option by myself. So the complete url should be http://xoap.weather.com/weather/local//GMXX0109?cc=*&dayf=5&unit=m Thanks anyway ingo
Re: FVWM: Off topic: Weather applet
[ On Thursday, September 18, 2008 at 11:01:08 (-0700), Perry Hutchison wrote: ] > Subject: Re: FVWM: Off topic: Weather applet > > > http://xoap.weather.com/weather/local//GMXX0109?dayf=5&unit=m). > > However, since a while I can't get the current weather only the > > forecast for 5 days ... > > I know nothing at all about xoap, but that "dayf=5" in the URL > sure looks like a request for a 5-day forecast. Maybe visit > the site with a browser, and see what kind of URLs are involved > in retrieving current conditions? Exactly, and I have already done it. What is missing on these sites are the information of the actual/current weather, which have been there. So it seems that something changed on the xoap site. Certainly, I'm not the only one who is fetching the weather report and forecast this way from these sites. What I'm asking is if someone knows how to get the actual weather conditions? TIA and regards, ingo
FVWM: Off topic: Weather applet
Dear all, I'm fetching the weather information of my home town from xoap.weather.com using wget (precisely: http://xoap.weather.com/weather/local//GMXX0109?dayf=5&unit=m). However, since a while I can't get the current weather only the forecast for 5 days. Does anyone else had have a similar problem, solved it and would like to share some insights? TIA and regards, ingo
FVWM: fvwm and patches
Hi all, since a while several patches have been existing to allow fvwm to exhibit menutranslucency and other features. However, a part of these features never made into fvwm. Currently, the users (which want such features) have to apply patches to the actual fvwm-version in order to get these, again and again as the fvwm-version changes. This seems to me slightly dissatisfactory, as it consumes time which has been spent already to patch a previous version, not to mention the time which is needed to adjust the patches. I'm sure there are profound reasons not to include such features as menutranslucency, topborder, inactivefont, round corners , etc. into fvwm. Which are these?? kindly, ingo
Re: FVWM: Widget fg color
[ On Wednesday, February 27, 2008 at 07:18:30 (-0700), Jaimos Skriletz wrote: ]
> Subject: Re: FVWM: Widget fg color
[snip]
>
> notice that the script isn't striping out any spaces, the reason it
> can't find that color is because you have additional spaces. when it
> tries to find the color " orange " in the list it can't match it to
> anything.
>
> What you want is ForeColor {orange}
Exactly!! Thank you!!
ingo
FVWM: Widget fg color
Hi all,
I try to set a widget foreground color to differ from the default, i.e.
WindowTitle {Weather_applet}
WindowSize 210 210
WindowPosition 1038 634
Colorset12
Widget 1
Property
TypeItemDraw
Size100 15
Position71 82
Font"shadow=0 se:xft:sans:size=7:antialias=True"
Flags NoFocus NoReliefString Left
ForeColor { orange }
Main
Case message of
SingleClic:
Begin
Quit
End
End
where the default is defined by coloset 9
Colorset 9 fg #ff, bg #f1eee0, hi #f1eee0, sh #f1eee0, fgsh #f1eee0, Tint
black 35, RootTransparent
However, fvwm(-2.5.23) is complaining: Cannot parse color " orange "
What does that mean, and more generally, how can I set up a widget fg
color differently from the default?
TIA
ingo
Re: FVWM: fvwm patches and esperanza
[ On Tuesday, February 26, 2008 at 15:29:38 (+0100), Dominik Vogt wrote: ] > Subject: Re: FVWM: fvwm patches and esperanza > > On Tue, Feb 26, 2008 at 03:24:17PM +0100, Ingo Wardinski wrote: > > [ On Tuesday, February 26, 2008 at 15:20:19 (+0100), Dominik Vogt wrote: ] > > > Subject: Re: FVWM: fvwm patches and esperanza > > > > > > On Tue, Feb 26, 2008 at 03:07:04PM +0100, Ingo Wardinski wrote: > > > > I managed to get core file and I attached the output of gdb fvwm2 core > > > > and where below. It seems something related to ewmh. > > > > Any help would be very appreciated. > > > [snip] > > > > #0 ewmh_MoveResizeWindow (fw=0x0, ev=0x6cb9e0, style=0x0, any=0) > > > > at ewmh_events.c:194 > > > > > > You need to upgrade to the latest code from CVS (e.g. a daily > > > snapshot). The crash is already fixed in 2.5.25 (not released > > > yet). > > > > > > > Thanks, for sharing this information. Do I still need the patches for > > menutranlucency, roundedcorners etc or are all these features included > > in .25? > > You still need the patches. > > By the way, I am just building the 2.5.25 release, so if you don't > want to use code from CVS, just wait until the tarball is > available on the ftp server (probably today or tomorrow). Cool!! Hopefully, the patches for menutranslucency etc want work for .25. But anyway thanks for your and all the others help on this issue. ingo
Re: FVWM: fvwm patches and esperanza
[ On Tuesday, February 26, 2008 at 15:20:19 (+0100), Dominik Vogt wrote: ] > Subject: Re: FVWM: fvwm patches and esperanza > > On Tue, Feb 26, 2008 at 03:07:04PM +0100, Ingo Wardinski wrote: > > I managed to get core file and I attached the output of gdb fvwm2 core > > and where below. It seems something related to ewmh. > > Any help would be very appreciated. > [snip] > > #0 ewmh_MoveResizeWindow (fw=0x0, ev=0x6cb9e0, style=0x0, any=0) > > at ewmh_events.c:194 > > You need to upgrade to the latest code from CVS (e.g. a daily > snapshot). The crash is already fixed in 2.5.25 (not released > yet). > Thanks, for sharing this information. Do I still need the patches for menutranlucency, roundedcorners etc or are all these features included in .25? ingo
FVWM: fvwm patches and esperanza
I managed to get core file and I attached the output of gdb fvwm2 core and where below. It seems something related to ewmh. Any help would be very appreciated. ingo GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". Reading symbols from /usr/lib/libXft.so.2...done. Loaded symbols for /usr/lib/libXft.so.2 Reading symbols from /usr/lib/libX11.so.6...done. Loaded symbols for /usr/lib/libX11.so.6 Reading symbols from /usr/lib/libfreetype.so.6...done. Loaded symbols for /usr/lib/libfreetype.so.6 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /usr/lib/libfontconfig.so.1...done. Loaded symbols for /usr/lib/libfontconfig.so.1 Reading symbols from /usr/lib/libXrender.so.1...done. Loaded symbols for /usr/lib/libXrender.so.1 Reading symbols from /usr/lib/libXpm.so.4...done. Loaded symbols for /usr/lib/libXpm.so.4 Reading symbols from /usr/lib/libstroke.so.0...done. Loaded symbols for /usr/lib/libstroke.so.0 Reading symbols from /usr/lib/libSM.so.6...done. Loaded symbols for /usr/lib/libSM.so.6 Reading symbols from /usr/lib/libICE.so.6...done. Loaded symbols for /usr/lib/libICE.so.6 Reading symbols from /usr/lib/libXinerama.so.1...done. Loaded symbols for /usr/lib/libXinerama.so.1 Reading symbols from /usr/lib/libXext.so.6...done. Loaded symbols for /usr/lib/libXext.so.6 Reading symbols from /lib/libm.so.6...done. Loaded symbols for /lib/libm.so.6 Reading symbols from /usr/lib/libXcursor.so.1...done. Loaded symbols for /usr/lib/libXcursor.so.1 Reading symbols from /usr/lib/libfribidi.so.0...done. Loaded symbols for /usr/lib/libfribidi.so.0 Reading symbols from /usr/lib/libpng12.so.0...done. Loaded symbols for /usr/lib/libpng12.so.0 Reading symbols from /usr/lib/librsvg-2.so.2...done. Loaded symbols for /usr/lib/librsvg-2.so.2 Reading symbols from /usr/lib/libgdk_pixbuf-2.0.so.0...Reading symbols from /usr/lib/debug/usr/lib/libgdk_pixbuf-2.0.so.0.1000.11...done. done. Loaded symbols for /usr/lib/libgdk_pixbuf-2.0.so.0 Reading symbols from /usr/lib/libgobject-2.0.so.0...Reading symbols from /usr/lib/debug/usr/lib/libgobject-2.0.so.0.1200.11...done. done. Loaded symbols for /usr/lib/libgobject-2.0.so.0 Reading symbols from /usr/lib/libgmodule-2.0.so.0...Reading symbols from /usr/lib/debug/usr/lib/libgmodule-2.0.so.0.1200.11...done. done. Loaded symbols for /usr/lib/libgmodule-2.0.so.0 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libglib-2.0.so.0...Reading symbols from /usr/lib/debug/usr/lib/libglib-2.0.so.0.1200.11...done. done. Loaded symbols for /usr/lib/libglib-2.0.so.0 Reading symbols from /usr/lib/libcairo.so.2...done. Loaded symbols for /usr/lib/libcairo.so.2 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libXau.so.6...done. Loaded symbols for /usr/lib/libXau.so.6 Reading symbols from /usr/lib/libXdmcp.so.6...done. Loaded symbols for /usr/lib/libXdmcp.so.6 Reading symbols from /usr/lib/libexpat.so.1...done. Loaded symbols for /usr/lib/libexpat.so.1 Reading symbols from /usr/lib/libXfixes.so.3...done. Loaded symbols for /usr/lib/libXfixes.so.3 Reading symbols from /usr/lib/libgsf-1.so.114...done. Loaded symbols for /usr/lib/libgsf-1.so.114 Reading symbols from /usr/lib/libcroco-0.6.so.3...done. Loaded symbols for /usr/lib/libcroco-0.6.so.3 Reading symbols from /usr/lib/libxml2.so.2...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /usr/lib/libpangoft2-1.0.so.0...done. Loaded symbols for /usr/lib/libpangoft2-1.0.so.0 Reading symbols from /usr/lib/libpangocairo-1.0.so.0...done. Loaded symbols for /usr/lib/libpangocairo-1.0.so.0 Reading symbols from /usr/lib/libpango-1.0.so.0...done. Loaded symbols for /usr/lib/libpango-1.0.so.0 Reading symbols from /lib/ld-linux-x86-64.so.2...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libbz2.so.1.0...done. Loaded symbols for /lib/libbz2.so.1.0 Reading symbols from /usr/lib/gconv/ISO8859-1.so...done. Loaded symbols for /usr/lib/gconv/ISO8859-1.so Core was generated by `fvwm2'. Program terminated with signal 11, Segmentation fault. #0 ewmh_MoveResizeWindow (fw=0x0, ev=0x6cb9e0, style=0x0, any=0) at ewmh_events.c:194 194 if ( (gdb) where #0 ewmh_MoveResizeWindow (fw=0x0, ev=0x6cb9e0, style=0x0, any=0) at ewmh_events.c:194 #1 0x00466f4f in EWMH_ProcessClientMessage ( exc=) at ewmh_events.c:1485 #2 0x0042c43f in HandleClient
Re: FVWM: fvwm patches and esperanza
[ On Monday, February 25, 2008 at 17:39:53 (+0100), Jesús Guerrero wrote: ] > Subject: Re: FVWM: fvwm patches and esperanza > > On Mon, 25 Feb 2008 17:31:14 +0100 > Ingo Wardinski <[EMAIL PROTECTED]> wrote: > > > [ On Monday, February 25, 2008 at 17:15:43 (+0100), Jesús Guerrero wrote: ] > > > Subject: Re: FVWM: fvwm patches and esperanza > > > > > > On Mon, 25 Feb 2008 16:31:36 +0100 > > > > > > Mmmm, I can't be sure, but I don't think that those patches can be > > > applied without manually fixing some rejects. Those are the original > > > patches, and were designed to be used against older fvwm versions. > > > > > > > Currently, there two sets of patches available at the above url, one > > for 2.5.18 and the other 2.5.23. The author tested tohose against > > 2.5.18 and 2.5.23, respectively. I took and applied the patches for > > 2.5.23. > > Oh, I see. Sorry. I didn't know. > > > > I don't know what do you mean. Transparent colorsets on panels and > > > the like were supported on .18 as well. If you are talking about the > > > translucency patch for menus, you need that on .23 as well. That patch > > > has never been integrated into fvwm. So, you need it anyway. > > > > I meant menutranslucency. > > You still need the patch. .23 has no additional support for translucency. Yes I know. I downloaded the set of patches for .23 and applied it to .23 and menutranslucency is working as expexted. This is not a problem at all. My initial guess was that these patches caused esperanza and then x to crash. Now I think it is something in .23 which makes the cock up (broadly speaking). Because, recent esperanza works with .18 _but_ the same version _do not_ with .23 with and without the patches. > > > Okay, I will give it a try, but I'm afraid my ~/.xinitrc isn't read by > > gdm. > > You need to boot on console. Usually this is achieved by booting on runlevel > 3. If you are in X, you can shut down Xdm usually doing "init 3", which in > turn > will drive you to runlevel 3. > > After that, you can use startx to start an X session. And then, ~/.xinitrc > should > be read. This may hold for xdm, I'm not sure about gdm I'll give it go. Otherwise I have to switch to xdm. cheers, ingo
Re: FVWM: fvwm patches and esperanza
[ On Monday, February 25, 2008 at 17:15:43 (+0100), Jesús Guerrero wrote: ] > Subject: Re: FVWM: fvwm patches and esperanza > > On Mon, 25 Feb 2008 16:31:36 +0100 > > Mmmm, I can't be sure, but I don't think that those patches can be > applied without manually fixing some rejects. Those are the original > patches, and were designed to be used against older fvwm versions. > Currently, there two sets of patches available at the above url, one for 2.5.18 and the other 2.5.23. The author tested tohose against 2.5.18 and 2.5.23, respectively. I took and applied the patches for 2.5.23. > > > 1.) fvwm-2.5.23 + patches + xmms2-0.4DrKosmos + esperanza > > 2.) fvwm-2.5.23 + xmms2-0.4DrKosmos + esperanza > > 3.) fvwm-2.5.23 + patches + xmms2-0.2DrJekyll + esperanza > > 4.) fvwm-2.5.23 + xmms2-0.2DrJekyll + esperanza > > There's also a chance that the xmms2 stuff is acting in a broken way, > just like xmms used to. That shouldn't make fvwm segfault, though. > > > this used to work fine before I updated to fvwm-2.5.23 in order to > > have neat features like translucency etc. > > I don't know what do you mean. Transparent colorsets on panels and > the like were supported on .18 as well. If you are talking about the > translucency patch for menus, you need that on .23 as well. That patch > has never been integrated into fvwm. So, you need it anyway. I meant menutranslucency. > > > I would appreciate very much any advice on how to debug my fvwm > > session. Can I force fvwm to output/log any communication between > > applications and X server? > > I use this in my ~/.xinitrc > > fvwm &>~/logs/fvwm.log 2>&1 Okay, I will give it a try, but I'm afraid my ~/.xinitrc isn't read by gdm. ingo
Re: FVWM: fvwm patches and esperanza
[ On Monday, February 25, 2008 at 16:31:36 (+0100), Ingo Wardinski wrote: ] > Subject: Re: FVWM: fvwm patches and esperanza > > [ On Monday, February 25, 2008 at 16:06:32 (+0100), Jesús Guerrero wrote: ] > > Subject: Re: FVWM: fvwm patches and esperanza > > > > On Mon, 25 Feb 2008 04:14:09 -0700 > > Jaimos Skriletz <[EMAIL PROTECTED]> wrote: > > > > > On Mon, Feb 25, 2008 at 11:35:55AM +0100, Ingo Wardinski wrote: > > > > Hi all, > > > > I see some oddities in the behaviour of fvwm after I installed > > > > fvwm-2.5.23 and applied various patches to obtain translucency, > > > > roundcorners, etc. In fact when I start esperanza (xmms2 client) my X > > > > crashes. I checked several logs, but I couldn't find what is causing > > > > the problem. So my primary guess is that it might be related to the > > > > applied patches, because everything was fine before the patches > > > > applied. Does someone else have similar problems? > > > > > > You'll probabaly have to do some debugging to fix your issue. > > > > > > One method might be to use Style statments to ensure esperanza is not > > > using any of the features provided by the patches. If this gives you the > > > stability you can then start applying the styles you want one at a time > > > until you find which one is causing the crash. > > > > > > another option is to figure out what patch(s) are causing the conflict by > > > applying them one at a time and testing the results. > > > > > > Once you figure out what patch(s) are causing the problem then you can > > > direct the bug to the patch matainer and hope he is helpful in solving > > > the issue. > > > > > > these are just suggestions to try to get you up and running. > > > > > > > > > jaimos > > > > > > > > I don't know if you are using the patches that I host at > > jesgue.homelinux.org, > > but if that's the case then you'll probably need to debug a bit. > > > > I just host them, and I modified some of them several times to allow them > > to continue living, but I just did the necessary modifications, and I don't > > understand most of them at all, since the code is not mine and I didn't > > really look too deep at the fvwm source code. > > > > Some structures in fvwm changed/got added, and those patches were planed > > against > > older fvwm versions. It is highly probable that something is seriously > > screwed in > > some of them (specially the fluxbox borders one hehehe). I don't have the > > time > > nor the interest to look into them (otherwise I would probably try to clean > > them to integrate some of them into fvwm properly). > > > > You should try to apply on one of them, and try, and so on, Until you find > > which > > is the responsible for the segfault. Looking into the X logs and output on > > console > > might (or might not) give you some hints on what is causing the problem. > > > > I took the patches from http://www.abdn.ac.uk/~u15dm4/fvwm/ > and I tried different setups > 1.) fvwm-2.5.23 + patches + xmms2-0.4DrKosmos + esperanza > 2.) fvwm-2.5.23 + xmms2-0.4DrKosmos + esperanza > 3.) fvwm-2.5.23 + patches + xmms2-0.2DrJekyll + esperanza > 4.) fvwm-2.5.23 + xmms2-0.2DrJekyll + esperanza > > all don't work and led to crash the X!! > > 5.) fvwm-2.5.18 + xmms2-0.4DrKosmos + esperanza > > this used to work fine before I updated to fvwm-2.5.23 in order to > have neat features like translucency etc. > > As I mention earlier, I checked the X logs, but there were no > indications what went wrong. The X crashes when I call esperanza via > Fvwmscript or from command line. > > I would appreciate very much any advice on how to debug my fvwm > session. Can I force fvwm to output/log any communication between > applications and X server? I did some further "research" in tcsh I did unlimited coredumpsize and in bash I set ulimit -c 1 then I called esperanza to get a corefile , but I even do not get a core file. I'm puzzled, any suggestions? ingo
Re: FVWM: fvwm patches and esperanza
[ On Monday, February 25, 2008 at 16:06:32 (+0100), Jesús Guerrero wrote: ] > Subject: Re: FVWM: fvwm patches and esperanza > > On Mon, 25 Feb 2008 04:14:09 -0700 > Jaimos Skriletz <[EMAIL PROTECTED]> wrote: > > > On Mon, Feb 25, 2008 at 11:35:55AM +0100, Ingo Wardinski wrote: > > > Hi all, > > > I see some oddities in the behaviour of fvwm after I installed > > > fvwm-2.5.23 and applied various patches to obtain translucency, > > > roundcorners, etc. In fact when I start esperanza (xmms2 client) my X > > > crashes. I checked several logs, but I couldn't find what is causing > > > the problem. So my primary guess is that it might be related to the > > > applied patches, because everything was fine before the patches > > > applied. Does someone else have similar problems? > > > > You'll probabaly have to do some debugging to fix your issue. > > > > One method might be to use Style statments to ensure esperanza is not using > > any of the features provided by the patches. If this gives you the > > stability you can then start applying the styles you want one at a time > > until you find which one is causing the crash. > > > > another option is to figure out what patch(s) are causing the conflict by > > applying them one at a time and testing the results. > > > > Once you figure out what patch(s) are causing the problem then you can > > direct the bug to the patch matainer and hope he is helpful in solving the > > issue. > > > > these are just suggestions to try to get you up and running. > > > > > > jaimos > > > > > I don't know if you are using the patches that I host at jesgue.homelinux.org, > but if that's the case then you'll probably need to debug a bit. > > I just host them, and I modified some of them several times to allow them > to continue living, but I just did the necessary modifications, and I don't > understand most of them at all, since the code is not mine and I didn't > really look too deep at the fvwm source code. > > Some structures in fvwm changed/got added, and those patches were planed > against > older fvwm versions. It is highly probable that something is seriously > screwed in > some of them (specially the fluxbox borders one hehehe). I don't have the time > nor the interest to look into them (otherwise I would probably try to clean > them to integrate some of them into fvwm properly). > > You should try to apply on one of them, and try, and so on, Until you find > which > is the responsible for the segfault. Looking into the X logs and output on > console > might (or might not) give you some hints on what is causing the problem. > I took the patches from http://www.abdn.ac.uk/~u15dm4/fvwm/ and I tried different setups 1.) fvwm-2.5.23 + patches + xmms2-0.4DrKosmos + esperanza 2.) fvwm-2.5.23 + xmms2-0.4DrKosmos + esperanza 3.) fvwm-2.5.23 + patches + xmms2-0.2DrJekyll + esperanza 4.) fvwm-2.5.23 + xmms2-0.2DrJekyll + esperanza all don't work and led to crash the X!! 5.) fvwm-2.5.18 + xmms2-0.4DrKosmos + esperanza this used to work fine before I updated to fvwm-2.5.23 in order to have neat features like translucency etc. As I mention earlier, I checked the X logs, but there were no indications what went wrong. The X crashes when I call esperanza via Fvwmscript or from command line. I would appreciate very much any advice on how to debug my fvwm session. Can I force fvwm to output/log any communication between applications and X server? TIA ingo
FVWM: fvwm patches and esperanza
Hi all, I see some oddities in the behaviour of fvwm after I installed fvwm-2.5.23 and applied various patches to obtain translucency, roundcorners, etc. In fact when I start esperanza (xmms2 client) my X crashes. I checked several logs, but I couldn't find what is causing the problem. So my primary guess is that it might be related to the applied patches, because everything was fine before the patches applied. Does someone else have similar problems? I'm running xmms2-0.4DrKosmos and esperanza-0.4.0 on Linux 2.6.20-16-generic x86_64 GNU/Linux. TIA ingo
