Re: test -e not supported on Solaris (configure.in perl test)
On 11:21 19 Apr 2002, tim phipps [EMAIL PROTECTED] wrote: | Description: | configure bombs out becasue /bin/sh on Solaris 2.5 doesn't | do [ -e $PERL ] | | -f works for me but it's probably not the right thing because | that just tests for a regular file. -x (executable regular file) and -d (directory) are also fairly specific and portable, depending what you're testing. -- Cameron Simpson, DoD#743[EMAIL PROTECTED]http://www.zip.com.au/~cs/ ..to know him was to love him. And to love him was to know him. Those who know him LOVED him - while those who did not know him, loved him from afar... - Data/Graves, The Schizoid Man, stardate 42437.5 -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: test -e not supported on Solaris (configure.in perl test)
On 26 Apr 2002 19:10:00 +1000, Cameron Simpson wrote: On 11:21 19 Apr 2002, tim phipps [EMAIL PROTECTED] wrote: | Description: | configure bombs out becasue /bin/sh on Solaris 2.5 doesn't | do [ -e $PERL ] | | -f works for me but it's probably not the right thing because | that just tests for a regular file. -x (executable regular file) and -d (directory) are also fairly specific and portable, depending what you're testing. There is no portable way to test for symlinks that I know of, except for replacing ancient /bin/sh like the ones in ULTRIX, AIX, SunOS. Anyway, this is not needed, since we test perl by running. Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Tear off menus stop module messages
fvwm-workers@fvwm.org wrote: Fixed. Thanks, that's much better. Cheers, Tim. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
core dump in menus with SelectOnRelease
I can reproduce this easily. Press the default Alt-Tab, move mouse outside of the menu, release Alt. The problem is not in 2.4.x. #0 0x08050c1c in MenuInteraction (pmp=0xbfffedd0, pmret=0xbfffed40, pdkp=0xbfffeb50, pdo_warp_to_title=0x80b2058) at menus.c:2449 2449 if (pmret-rc == MENU_SELECTED MI_FUNC_TYPE(mi) == F_TEARMENUOFF) (gdb) where #0 0x08050c1c in MenuInteraction (pmp=0xbfffedd0, pmret=0xbfffed40, pdkp=0xbfffeb50, pdo_warp_to_title=0x80b2058) at menus.c:2449 #1 0x08055721 in do_menu (pmp=0xbfffedd0, pmret=0xbfffed40) at menus.c:6039 #2 0x0808dfa3 in CMD_WindowList (cond_rc=0x0, eventp=0x80b57e0, w=4198014, fw=0x81719a0, context=1, action=0x81765bb Root c c NoDeskSort, SelectOnRelease Meta_L, Module=0xbfffef08) at windowlist.c:639 #3 0x0807c5e5 in execute_function (efa=0xbfffeef0) at functions.c:1394 #4 0x0807c744 in old_execute_function (cond_rc=0x0, action=0x80d9f50 WindowList Root c c NoDeskSort, SelectOnRelease Meta_L, fw=0x81719a0, eventp=0x80b57e0, context=1, Module=-1, exec_flags=0, args=0x0) at functions.c:1467 #5 0x0806e41f in HandleKeyPress () at events.c:1757 #6 0x0806fe72 in DispatchEvent (preserve_Fw=0) at events.c:3096 #7 0x0806ff14 in HandleEvents () at events.c:3151 #8 0x08082b3a in main (argc=3, argv=0xb434) at fvwm.c:718 #9 0x42017499 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) print mi $1 = (MenuItem *) 0x0 Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Default Alt-Tab does not focuses
Gee, why I notice problems _after_ release. With no config file. Open 2 xterm (or FvwmConsole). Press Alt-Tab-Tab, release Alt. The pointer is warped, but not the focus. Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Restart from non desk 0 does not decorate
Do Restart without parameters from non first desk. Any existing windows are not (correctly) decorated until the pointer enters them. Reproducible with no config too. Just open xterm on Desk 1 and Restart. Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
resize problem in FvwmIconMan
I just installed 2.5.1 (which includes the weighted sorting patch I submitted), and I'm seeing a strange bug in FvwmIconMan. Sometimes when I iconify a window, the FvwmIconMan window doesn't get resized to hold the extra button. (I have showonlyiconic turned on.) Sometimes it works, sometimes it doesn't. If I uniconify the window and reiconify, it usually ends up correct. I did not see this behavior in 2.4.7 (also with my patch). I did some debugging within FvwmIconMan, and it looks like XMoveResizeWindow is being called (from resize_window) with the correct values, but the X server is just ignoring it. XMoveResizeWindow is always called correctly, but the results are random - sometimes the window gets resizes, sometimes it doesn't. I know the window manager interacts with the X server on window moves and resizes, but I'm not familiar with the details, and I have no idea how this would relate to module windows (if at all). Did something get changed in 2.5.x that would cause this problem? Any other ideas? - Derek -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
FvwmPager initially drawn incorrectly
Strange that noone who use a non-swallowed pager did not report it. FvwmPager is initially drawn incorrectly (for example top title is drawn at the bottom with no text). May be reproduced with no config. WindowShade refreshes FvwmPager well. 2.4.x is ok. Regards, Mikhael. -- Visit the official FVWM web page at URL:http://www.fvwm.org/. To unsubscribe from the list, send unsubscribe fvwm-workers in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
Re: Bidi status/help
On Thu, 25 Apr 2002 23:26:17 +0200, Olivier Chapuis olivier chapuis free fr wrote: On Wed, Apr 24, 2002 at 12:41:38PM -0700, Nadim Shaikli wrote: On Wed, 24 Apr 2002 06:56:05 +0200, Olivier Chapuis wrote: [snip snip] It seems that there is two problems here. - Displaying string with a core *-iso10646-1 font: at the present time this should work only with fvwm compiled with MB support, an utf8 locale and a libc that support utf8 locale (also X should reconize the locale as an utf locale: see /usr/X11R6/lib/X11/locale/loacle.alias). Unfortunately, I cannot test this as my libc does not support utf8 locale. Mikhael, can you confirm that this work? - To apply bidi fvwm should reconize a core *-10646-1 font, I think that fvwm fail to do this because I think that the default charset with the utf8 XFree-4 locale is iso8859-1. This may be fixed after a confirmation that the first point work. I will see if we can implement the use of core *-iso10646-1 font without all the above requirement (but with XFree-4). On the other hands, I think that with a true type iso10646-1 font there is no problem (needs XFree-4.x, x=1 and iso10646-1 ttf with arabic/hebrew/persian characters to see bidi in work) Well, I'm not sure why all that is needed (I'm simply trying to display a few glyphs not alter my keyboard mapping, or specify date/currency settings, etc). By the way, I'm able to use multiple Arabic-enabled utilities without having to touch any of what is noted above (locales, libc support, etc) given the availability of the fonts and a rendering engine (glyph displayer) and Bidi (fribidi) - one such application is vim-6.0/6.1. Yes and you use a special font made for vim ... Maybe you start vim with some options? Moreover, I think that vim use an other method than fvwm to display strings. Also some applications (KDE23/GNOME2) use only utf8, but this is not possible with fvwm (we cannot ask everybody to use only utf8 in configuration files). Moreover, most of these applications use (lib)iconv which can cause portability problem (basically we should also ask everybody with a non (or old) GNU system to install gnu libiconv). Just in passing, those fonts are not specific to vim and no special options are needed to use 'em (ie. start options). BTW, couldn't those methods (libiconv and others) be things that could be included during configure time ? Here the problems: 1 - if we want to make some bidi conversion on a string we _must_ know the encoding used by the string. The only good general method I found is to look at the font name of the used font and to extract the charset/encoding from this name. There is a precise specification here from the X Consortium, the last two items of a font name should be the CHARSET_REGISTRY and the CHARSET_ENCODING. Then, if you use a font which does not respect this standard no conversion will be done. If you use a font which use a strange charset name as say my_arabic-36 we may fix fvwm so that fvwm understand this name in one second (if it correspond to an encoding that fribidi support). This may become configurable in a special way in the future. A simple alternative would be to add a new fvwm Style (and new module config options) to specify the charset of the font ... (basically xterm use this method with the -u8 option), but I do not like so much this idea. I prefer that the font define the encoding used by the user. A couple of things - a. You can run Bidi on any string irrespective of its encoding and it ought to work (only encodings that it cares about will be touched - namely 8859-6 and 8859-8) - so, unless I'm missing a detail, I don't see why fvwm needs to know the encoding of the strings at all (except in the case where it needs to display 'em, of course :-) b. I think we are discussing an optimization regarding the loading of the fonts, no ? Meaning, why not simply load all the fonts a user specifies even if it were a 10646 with english, russian, arabic, japanese, hebrew, chinese, etc when a user specifies all (or similar somehow within fvwmrc file) 2 - After fvwm have determined the charset and load the font it should display the string (forget bidi here). With an unibyte font (as iso8859-X) there are no problems. Why do you not use iso8859-6 fonts with fvwm? Do you need others characters than ASCII and Arabic one's? Yup, Arabic requires Form-B glyphs rendering iso8859-6 useless for display. In brief (beyond the realm of fvwm really, but you asked :-), Arabic has complexities which few other languages have in which characters are displayed differently based on their location within the word and sentence. All files are stored with 8859-6 encodings, but for those applications which don't use an external display engine (and most don't :-) one is required to get the extra display glyphs from somewhere else (Unicode's Form-B
