Re: Help on installing FVWM-2.4.19

2005-02-02 Thread Mikhael Goikhman
On 01 Feb 2005 23:19:27 +, Mikhael Goikhman wrote:
 
 Don't specify --without-gnome, it does not do what you think it does.

Sorry, this specific advice was bad, using --without-gnome is useful.

I refered to --disable-gnome-hints (or --disable-gnome in the past).

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: Help on installing FVWM-2.4.19

2005-02-01 Thread Mikhael Goikhman
On 29 Jan 2005 13:33:54 -0500, I. Thomas Cundiff wrote:
 
 Since then, on August 25, 2004, I installed GLIB-2.4.2 and GTK+-2.4.2 
 since it was my understanding that these could coexist with versions 
 1.2.10 of both (which I needed at least for GIMP 1.2.5).
 
 Today I tried installing FVWM-2.4.19 and after the usual decompression 
 using BZIP2 and untarring, in the FVWM-2.4.19 subdirectory I gave 
 ./configure --without-gnome.

Don't specify --without-gnome, it does not do what you think it does.
In 2.5.x this option is removed, the GNOME hints should be disabled
at config time, not at build time.

 In the messages at the end of the configuration, I got that GTK was not 
 detected and to see config.log for details.  After quite a bit of work 
 which included invoking gtk-config --version to get 1.2.10 (and other 
 information as well), I tried ./configure again with the argument list 
 --without-gnome --disable-gtktest --disable-imlibtest, but I still got 
 that configure could not detect GTK.  So I am attaching the file 
 config.log (here called fvwm-config.log) since in looking at the file it 
 seems clear it recognized the --disable-gtktest but then went ahead and 
 did it anyway.

config.log says that the test program failed. Can you compile this failed
test program included in config.log manually with the gcc flags specified
above that program? I suppose no. If you can find some missing gcc flags
that make that not fvwm specific program, tell us. Otherwise, it just
means that your gtk-1.2 installation is somehow incomplete or broken.

Anyway, the GTK support is only used in FvwmGtk module, nowhere else,
so unless you use this module you should not worry about GTK support.

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]


Help on installing FVWM-2.4.19

2005-01-31 Thread I. Thomas Cundiff
I am not sure whom to send this e-mail to, so out of desperation and am 
sending it to the fvwm-workers.  If this is the wrong place, I would 
appreciate it if you could tell me where I could get help.


On April 10, 2004, I installed FVWM-2.4.18 using ./configure 
--without-gnome and got, among many other pieces of information:


With GTK support for FVWMGTK?  yes
With GDKImlib support in FvwmGTK?  yes

As far as I could tell, the installation (make followed by make install) 
went fine and version 2.4.18 is still my working version (as of today).


Since then, on August 25, 2004, I installed GLIB-2.4.2 and GTK+-2.4.2 
since it was my understanding that these could coexist with versions 
1.2.10 of both (which I needed at least for GIMP 1.2.5).


Today I tried installing FVWM-2.4.19 and after the usual decompression 
using BZIP2 and untarring, in the FVWM-2.4.19 subdirectory I gave 
./configure --without-gnome.
In the messages at the end of the configuration, I got that GTK was not 
detected and to see config.log for details.  After quite a bit of work 
which included invoking gtk-config --version to get 1.2.10 (and other 
information as well), I tried ./configure again with the argument list 
--without-gnome --disable-gtktest --disable-imlibtest, but I still got 
that configure could not detect GTK.  So I am attaching the file 
config.log (here called fvwm-config.log) since in looking at the file it 
seems clear it recognized the --disable-gtktest but then went ahead and 
did it anyway.


I also invoked imlib-config with the argument --version and got 1.9.14.

In installing [glib,gtk+]-1.2.10 I took all the defaults so the 
libraries are in /usr/local/lib.  I even tried the ./configure with 
--with-gtk-prefix=/usr/local --with-gtk-exec-prefix=/usr/local both of 
which I obtained from gtk-config with the arguments --prefix and 
--exec-prefix.


And in /usr/local/lib/pkgconfig there are .pc files for gtk+, gtk+-2.0, 
and imlib.


I really don't understand what has now gone wrong and, if I am doing 
something wrong, what it is.  I would appreciate any help you could give 
me as I would like to be able to use the latest version of FVWM which I 
have been using now for about a year and a half and like it very much.


If you need any further information, I would be happy to send it to you.

Tom Cundiff
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

It was created by configure, which was
generated by GNU Autoconf 2.54.  Invocation command line was

  $ ./configure --without-gnome --disable-gtktest --disable-imlibtest

## - ##
## Platform. ##
## - ##

hostname = localhost.localdomain
uname -m = i686
uname -r = 2.2.26
uname -s = Linux
uname -v = #1 Thu Mar 11 10:07:21 EST 2004

/usr/bin/uname -p = unknown
/bin/uname -X = unknown

/bin/arch  = i686
/usr/bin/arch -k   = unknown
/usr/convex/getsysinfo = unknown
hostinfo   = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /usr/kerberos/sbin
PATH: /usr/kerberos/bin
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /sbin
PATH: /bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /usr/X11R6/bin
PATH: /root/bin


## --- ##
## Core tests. ##
## --- ##

configure:1317: checking for a BSD-compatible install
configure:1371: result: /usr/local/bin/install -c
configure:1382: checking whether build environment is sane
configure:1425: result: yes
configure:1458: checking for gawk
configure:1474: found /usr/local/bin/gawk
configure:1484: result: gawk
configure:1494: checking whether make sets ${MAKE}
configure:1514: result: yes
configure:1707: checking whether to enable command logging
configure:1725: result: no
configure:1730: checking whether to enable debugging messages
configure:1748: result: no
configure:1753: checking whether to enable multibyte character support 
(experimental)
configure:1771: result: no
configure:1777: checking whether to enable compound text conversion support
configure:1795: result: yes
configure:1812: checking imagepath
configure:1838: result: /usr/include/X11/bitmaps:/usr/include/X11/pixmaps
configure:1887: checking for gcc
configure:1903: found /usr/local/bin/gcc
configure:1913: result: gcc
configure:2155: checking for C compiler version
configure:2158: gcc --version /dev/null 5
gcc (GCC) 3.3.3
Copyright (C) 2003 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.

configure:2161: $? = 0
configure:2163: gcc -v /dev/null 5
Reading specs from 
/usr/local/gcc-3.3.3/lib/gcc-lib/i686-pc-linux-gnu/3.3.3/specs
Configured with: ../gcc-3.3.3/configure --prefix=/usr/local/gcc-3.3.3 
--enable-threads --enable-languages=c,c++,objc,java
Thread model: posix
gcc version 3.3.3
configure:2166: $? = 0
configure:2168: gcc -V /dev/null 5
gcc: `-V

Re: Please Help on Customizing Start-Menu

2004-11-29 Thread David Sun
Hi Dominik
?? 2004-11-29 ?? ?? 01:23?? Dominik Vogt ??
 On Fri, Nov 26, 2004 at 10:51:54AM +0800, David Sun wrote:
  Hi all
  I'm planning to customize the Start Menu on the taskbar based on fvwm
  2.4.18.The thing I would like to do is:
  
  when people left-mouse-click on the Start Menu, fvwm will look for
  certain place on local disk for some certain files, and spawn the menu
  on the fly according to the lookup result.
  
  Could you please advise which files/functions I should look into?
 
 Take a look at the DynamicPopUpAction menu option and the
 fvwm-menu-directory script.
thanks for your advice, unfortuantely, my target machine is too
size-limited to have perl. I have achieved the purpose by playing with
the FvwmTaskBar code which get called when the Start button is pressed
 
  And
  how can I look into a running FVWM for what call-chains are performed
  when certain event happens? The more detailed is more appreciated^_^
 
 You can attach a debugger to the running fvwm process from a
 console or a second X server (*not* from the X server running
 fvwm).  With gdb:
 
   $ gdb fvwm processid
 
 Ciao
 
 Dominik ^_^  ^_^
 
  --
 Dominik Vogt, [EMAIL PROTECTED]

--
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]


Please Help on Customizing Start-Menu

2004-11-25 Thread David Sun
Hi all
I'm planning to customize the Start Menu on the taskbar based on fvwm
2.4.18.The thing I would like to do is:

when people left-mouse-click on the Start Menu, fvwm will look for
certain place on local disk for some certain files, and spawn the menu
on the fly according to the lookup result.

Could you please advise which files/functions I should look into? And
how can I look into a running FVWM for what call-chains are performed
when certain event happens? The more detailed is more appreciated^_^

thanks for your help
David Sun

--
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]


Help

2004-04-28 Thread jipallaresv
Hi,

I have some problem with my fvwm95 in fedora core, the description is:

/usr/X11R6/lib/X11/fvwm95//FvwmTaskBar: can`t load library `libXpm.so.4`

This library is in /usr/X11R6/lib/libXpm.so.4, the same happend with the other 
modules: FvwmButtons, because of that this doesn`t work..

Thanks for your help... what i can do??


--
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: Help

2004-04-28 Thread Dan Espen
[EMAIL PROTECTED] writes:
 Hi,
 
 I have some problem with my fvwm95 in fedora core, the description is:
 
 /usr/X11R6/lib/X11/fvwm95//FvwmTaskBar: can`t load library `libXpm.so.4`
 
 This library is in /usr/X11R6/lib/libXpm.so.4, the same happend with the othe
 r modules: FvwmButtons, because of that this doesn`t work..
 
 Thanks for your help... what i can do??

This list does not support fvwm95.

Fvwm95 is a fork.  My advice is to use Fvwm instead.  Fvwm does a good
fvwm95 imitation.  See also fvwm-themes.

You've got some kind of LD_LIBRARY_PATH or -rpath issue.

-- 
Dan Espen   E-mail: [EMAIL PROTECTED]
--
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]


CVS migo: * hints_test: reformatted, added --help and basic argument checking

2003-04-13 Thread FVWM CVS
CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: migo03/04/13 09:31:10

Modified files:
tests  : ChangeLog 
tests/hints: README hints_test.c 

Log message:
* hints_test: reformatted, added --help and basic argument checking

--
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]


CVS migo: * all programs now support --help, -h, -?, --version, -V

2002-11-10 Thread FVWM CVS
CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: migo02/11/10 16:33:36

Modified files:
bin: ChangeLog fvwm-bug.1 fvwm-bug.in fvwm-config.1 
 fvwm-config.in fvwm-menu-desktop.1 
 fvwm-menu-desktop.in fvwm-menu-directory.1 
 fvwm-menu-directory.in fvwm-menu-headlines.1 
 fvwm-menu-headlines.in fvwm-menu-xlock.1 
 fvwm-menu-xlock.in fvwm-perllib.1 
 fvwm-perllib.in fvwm-root.1 fvwm-root.c 

Log message:
* all programs now support --help, -h, -?, --version, -V
_ and some (that supported it in 2.4.x continue to support -v)

--
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]


CVS migo: * corrected and lined up several help lines

2002-10-27 Thread FVWM CVS
CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: migo02/10/27 20:38:51

Modified files:
.  : ChangeLog INSTALL.fvwm acinclude.m4 
 configure.in 

Log message:
* corrected and lined up several help lines
_ the substr code now works with autoconf-2.53 and not 2.13 (it was vice versa)
* INSTALL.fvwm: added --enable-xinerama-emulation description

--
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]


reson module pipe deadlock, need some help

2002-07-06 Thread Dominik Vogt
Okay, this is why busy modules using synchronized messages can run
into a deadlock with fvwm:  take for example FvwmEvent with the
sync'ed M_DESTROY_WINDOW message.

1) When a lot of things are going on on the desktop (many X events
   are coming in), fvwm handles all of them and puts the module
   messages into the module queues (PositiveWrite()).
2) Now that we have a long message queue for our module, an event
   arrives that triggers a synchronized module message.  In the
   case of FvwmEvent, a dying window triggers a M_DESTROY_WINDOW
   message.
3) The new message is added to the queue via PositiveWrite().
   Afterwards, fvwm looks at the packet type and sees that the
   module requested synchronized transmission and goes into the
   part dealing with synchronization.
4) Next, FlushMessageQueue(module) is called.  This function
   spits the data into the module pipe at full speed - and because
   the queue is so large, it pipe gets finally full and the next
   write() call returns EWOULDBLOCK or EAGAIN.
5) FlushMessageQueue stops writing data and simply returns.

Result: fvwm entered the sync'ed code branch and waits for the
   unlock message from the module.  But because the pipe is full,
   the M_DESTROY_WINDOW message that needed synchronization in the
   first place is never sent.  The module simply waits for further
   input that never comes since fvwm waits for the unlock message.

What do we do about this?

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
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: reson module pipe deadlock, need some help

2002-07-06 Thread Dominik Vogt
On Sat, Jul 06, 2002 at 09:12:50PM +0200, Dominik Vogt wrote:
 Okay, this is why busy modules using synchronized messages can run
 into a deadlock with fvwm:  take for example FvwmEvent with the
 sync'ed M_DESTROY_WINDOW message.
 
 1) When a lot of things are going on on the desktop (many X events
are coming in), fvwm handles all of them and puts the module
messages into the module queues (PositiveWrite()).
 2) Now that we have a long message queue for our module, an event
arrives that triggers a synchronized module message.  In the
case of FvwmEvent, a dying window triggers a M_DESTROY_WINDOW
message.
 3) The new message is added to the queue via PositiveWrite().
Afterwards, fvwm looks at the packet type and sees that the
module requested synchronized transmission and goes into the
part dealing with synchronization.
 4) Next, FlushMessageQueue(module) is called.  This function
spits the data into the module pipe at full speed - and because
the queue is so large, it pipe gets finally full and the next
write() call returns EWOULDBLOCK or EAGAIN.
 5) FlushMessageQueue stops writing data and simply returns.
 
 Result: fvwm entered the sync'ed code branch and waits for the
unlock message from the module.  But because the pipe is full,
the M_DESTROY_WINDOW message that needed synchronization in the
first place is never sent.  The module simply waits for further
input that never comes since fvwm waits for the unlock message.
 
 What do we do about this?

I tried to fix it by adding another fvwmSelect call in
FlushMessageQueues() that waits for the write pipe to accept
further input.  I'm not sure if I've done this right.  Could
someone with a better knowledge of pipe communication please take
a look at the patch?  I'm quite sure the select call is correct,
but I'm not sure that how the code reats to errors is right and
that it's ok to always retry writing.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
--
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

2002-05-01 Thread Nadim Shaikli
On Mon, 29 Apr 2002 11:31:28 +0200,
 Olivier Chapuis olivier chapuis free fr wrote:
 
 MenuStyle * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1

 # replace /opt/kde to KDE3 dir
 ImagePath
+:/opt/kde/share/icons/hicolor/16x16/:/opt/kde/share/icons/locolor/16x16/

 DestroyMenu kde-sys
 AddToMenu kde-sys DynamicPopupAction PipeRead 'fvwm-menu-desktop --desktop 
   kde-sys --lang ar --enable-mini-icons --mini-icons-path apps'
 
 Then, Menu kde-sys gives me an Arabic KDE3 menu which seems
 good (however, Arabic characters are separated and not ligatured,
 is this fvwm fault?).
 
 What's may happen on your system is that bidi conversion is
 not applied because your font name does not say to fvwm that
 the font is an iso10646-1 font.
 
 Nadim, can you test a today snapshot when you have time (really
 not urgent).

Olivier, in short - it works :-)

For completeness, I downloaded 'snap-20020501' and did the following,

 MenuStyle  Black white Blue \
-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 fvwm
 
 Style  * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
 Style  * IconFont
-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1

And both the menu and title worked flawlessly - Great work Olivier/Mikhael.

BTW: don't know if the \ above works, just added it for readability
 (it would be nice if fvwm groked it correctly, it might - dunno)

Now for the questions :-)

In order to get the various other modules to work (such as FvwmWinList,
FvwmPager, FvwmIdent, etc) - each one of those modules has its own
font specification.  Has any thought been given to having all these
modules default to the main font setting style (ie. style * font ...)
when nothing is specified.  If a user wants to define NO font (rather
unlikely), then 'none' or 'nil' ought to suffice.  It just seemed a bit
silly to paste that long font name all over the place (as is noted above).

In passing, I'm assuming FvwmPager (and thus fvwm) is not able to
dynamically size a font.  What I'm getting at is whether there is a
way to get a smaller font setting in order to set the FvwmPagerSmallFont
setting.  I'm not sure I'll be able to find a 5x8 iso10646-1 font :-)

Thanks again...

 - Nadim


__
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
--
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

2002-04-29 Thread Olivier Chapuis
On Fri, Apr 26, 2002 at 06:07:37PM -0700, Nadim Shaikli wrote:
 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]
 
  
  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).

So I download your 10x20.bdf.gz vim font put it in a directory
arabic/, run mkfontdir and add arabic/ to my fonts path.
First, mkfontdir gives the following name to the font:

-misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1

:o).

Secondly, is that I use current cvs which now support iso10646-1
without any requirement (you may try the next snapshot, but 2.5.1
does not work).
And the last thing is that every things seems to work. The test
I done:

MenuStyle * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
# replace /opt/kde to KDE3 dir
ImagePath 
+:/opt/kde/share/icons/hicolor/16x16/:/opt/kde/share/icons/locolor/16x16/
DestroyMenu kde-sys
AddToMenu kde-sys DynamicPopupAction PipeRead 'fvwm-menu-desktop --desktop 
kde-sys --lang ar --enable-mini-icons --mini-icons-path apps'

Then, Menu kde-sys gives me an Arabic KDE3 menu which seems
good (however, Arabic characters are separated and not ligatured,
is this fvwm fault?).

What's may happen on your system is that bidi conversion is
not applied because your font name does not say to fvwm that
the font is an iso10646-1 font.

Nadim, can you test a today snapshot when you have time (really
not urgent).

 BTW, couldn't
 those methods (libiconv and others) be things that could be included
 during configure time ?


For portability reason I prefer to use iconv only if there are no
other choice.

  [snip]
 
  With a multibyte font (as iso10646) locale is important, as fvwm use a
  (powerful) method from X to display string and load font. Good fonts
  are automatically loaded (no need to specify the charset) and string
  are well displayed without the need to think to much :o)
  So with iso10646, at the present time, you should use an utf8
  locale (or good ttf font and XFree-4.good_version, here yet an
  other method is used).
  
  Now as utf8 grow in importance and a lot of system does not support
  utf8 locale I will see if fvwm can support utf8 on system which does
  not support utf8 locale. You may be happy with this but you should
  wait a bit. Ooops, this works now on my machine but I cannot commit
  the change before Monday, this should work on any X server (I have
  added a 4th method to display string ...).
 
 OK, I think you are saying that with 10646 fonts the locale will
 specify which subsections will be loaded and ought to be used as
 the charsets to display within fvwm, right ?

Yes and no. The most important thing is that using the good locale
allows to use the Xmb* X functions which do a lot of conversion work
for fvwm. Here an example among others:

With an utf8 locale if we want to display an utf8 string we just
have to call XmbDrawString.
Without an utf8 locale we first have to convert the utf8 string into
USC-4 encoding (not so difficult) and then use XDrawString16.
This is not so difficult (as we know that the string is in utf8),
but we should do an other conversion for JIS encoding, GB encoding,
...etc. As with Xmb* functions conversion are handled by X.
There are other important issues with window names.

 What will a person
 need to do in order to display say 4 languages (english, arabic,
 japanese, russian) all within the same the 10646 font file - a
 single locale won't suffice or will it ?  Seems like a more dynamic
 solution ought to be sought.
 

The xlfd say that this can be done by the user:

Style * Font -blabla-*-iso10646-1[characters_that_the_users_want]

see the xlfd X doc for more details. Unfortunately, the doc does
not claim that only the characters_that_the_users_want must be
loaded and it seems that this does not work with fvwm ...

 Before I got this email, I was thinking more along a way to specify
 the usage of utf8 within fvwm2rc (or fvwmrc :-); something along the
 lines,
 
   Style * Charset utf8// meaning all of 'em (*utf8* :-)
-or-
   Style * Charset english:arabic:sv.UTF-8:iso8859-7
 
 Just an idea.


Yep this can be an idea. however, as Mikhael says that leads to
duplications. What we can do is to extend a bit font name as

MenuStyle * 

Re: Bidi status/help

2002-04-29 Thread Olivier Chapuis
On Mon, Apr 29, 2002 at 11:31:28AM +0200, Olivier Chapuis wrote:
 
 Nadim, can you test a today snapshot when you have time (really
 not urgent).


Ooops, with the today snap fvwm will probably core dump with
certain fonts ...

Olivier
--
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

2002-04-29 Thread Mikhael Goikhman
On 29 Apr 2002 11:31:28 +0200, Olivier Chapuis wrote:
 
 And the last thing is that every things seems to work. The test
 I done:
 
 MenuStyle * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
 # replace /opt/kde to KDE3 dir
 ImagePath 
 +:/opt/kde/share/icons/hicolor/16x16/:/opt/kde/share/icons/locolor/16x16/
 DestroyMenu kde-sys
 AddToMenu kde-sys DynamicPopupAction PipeRead 'fvwm-menu-desktop --desktop 
 kde-sys --lang ar --enable-mini-icons --mini-icons-path apps'
 
 Then, Menu kde-sys gives me an Arabic KDE3 menu which seems
 good (however, Arabic characters are separated and not ligatured,
 is this fvwm fault?).

I did the same test with KDE 2.2 with your yesterday's commit (it does not
work without it) using C locale.

It seems that KDE 2.2 was not translated to Arabic, so no results here.
Russian - fully works, French - minor problems, Hebrew - minor problems.
All problems are KDE-specific, not FVWM. For example, they use 'é' (which
is not how it should be written in utf8) in all Programmes submenus, so
entries look like Syst*, Multim*ia etc, other submenus are good. And
they use visual Hebrew, so together with Bidi it becomes logical (i.e.
reversed). I hope that KDE 3.0 has logical Hebrew and Arabic.

 i.e., if the font name does not use a standard charset/encoding
 the encoding can be added after the font name and after a /
 separator. Other info can be given:
 
  font_name/encoding[/iconv_name[/mb_info]]
 
 where encoding is a standard encoding (supported by fvwm) and
 iconv_name is the encoding for the system iconv implementation
 (there are no standard here). Maybe some multibyte font info
 maybe needed in a near future (specially for Xft font).
 The advantage of this method is that we do not need to add new
 config command (for fvwm and all the modules that load font),
 we keep the idea that font define the encoding and that in most
 situation nothing special should be added to a config file.
 I propose the / for separation as ,, ; and : are already
 used in font name but any suggestion is welcome.

I think it is good. This is needed anyway for unicode that has more than
one encoding, i.e. utf16 and so on.

And I think we should support also specifying an encoding with the string
itself (this overrides the default encoding used from fonts). I suppose
this should work already when XbmString* functions are used; an encoding
may be specified using escape sequences (would be nice to have any spec
about this).

Nice work, Olivier. We have a nice internationalization.

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

2002-04-29 Thread Olivier Chapuis
On Mon, Apr 29, 2002 at 04:02:43PM +, Mikhael Goikhman wrote:
 On 29 Apr 2002 11:31:28 +0200, Olivier Chapuis wrote:
  
  And the last thing is that every things seems to work. The test
  I done:
  
  MenuStyle * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1
  # replace /opt/kde to KDE3 dir
  ImagePath 
  +:/opt/kde/share/icons/hicolor/16x16/:/opt/kde/share/icons/locolor/16x16/
  DestroyMenu kde-sys
  AddToMenu kde-sys DynamicPopupAction PipeRead 'fvwm-menu-desktop --desktop 
  kde-sys --lang ar --enable-mini-icons --mini-icons-path apps'
  
  Then, Menu kde-sys gives me an Arabic KDE3 menu which seems
  good (however, Arabic characters are separated and not ligatured,
  is this fvwm fault?).
 
 I did the same test with KDE 2.2 with your yesterday's commit (it does not
 work without it) using C locale.
 
 It seems that KDE 2.2 was not translated to Arabic, so no results here.
 Russian - fully works, French - minor problems, Hebrew - minor problems.
 All problems are KDE-specific, not FVWM. For example, they use 'é' (which
 is not how it should be written in utf8) in all Programmes submenus, so
 entries look like Syst*, Multim*ia etc, other submenus are good. And
 they use visual Hebrew, so together with Bidi it becomes logical (i.e.
 reversed). I hope that KDE 3.0 has logical Hebrew and Arabic.


Here 3 screenshots with the KDE-3.0 head menu. The hebrew and arabic
screenshot are done with  Mark Leisher ClearlyU fonts (Roman Czyborra
has also done Unicode font which cover a very large part of the
unicode). The Japanese menu is done with the Bitstream Cyberbit ttf
which contains a big part of the unicode (Roman, Cyrillic, Greek,
Hebrew, Arabic, Chinese, Korean, Japanese ...etc!!). 
Mikhael is the hebrew menu ok?
Nadim is the arabic menu ok?
Can some one can comment on the Japanese menu?

Olivier


hebrew.png
Description: PNG image


arabic.png
Description: PNG image


japanese.png
Description: PNG image


Re: Bidi status/help

2002-04-29 Thread Nadim Shaikli
--- Olivier Chapuis wrote:
 On Mon, Apr 29, 2002 at 04:02:43PM +, Mikhael Goikhman wrote:
 
 Here 3 screenshots with the KDE-3.0 head menu. The hebrew and arabic
 screenshot are done with  Mark Leisher ClearlyU fonts (Roman Czyborra
 has also done Unicode font which cover a very large part of the
 unicode). The Japanese menu is done with the Bitstream Cyberbit ttf
 which contains a big part of the unicode (Roman, Cyrillic, Greek,
 Hebrew, Arabic, Chinese, Korean, Japanese ...etc!!). 
 Mikhael is the hebrew menu ok?
 Nadim is the arabic menu ok?
 Can some one can comment on the Japanese menu?

Arabic looks fine.  The reason it might look odd or incomplete
is because Arabic now needs what's termed 'shaping' to join
the characters, but its nothing that you should concern yourself
with (unless you are really interested :-).  I'll take a look
into adding the shaping code to fvwm once I have some time.

BTW: for what it's worth - fribidi will include a library call to
 do the shaping for us; on second thought, let me double-check
 with them on a release date before I start adding potentially
 redundant code.

I'll download tomorrow's fvwm-snapshot to confirm usage :-)

Thanks for all your help !!!

 - Nadim


__
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
--
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

2002-04-29 Thread Mikhael Goikhman
On 30 Apr 2002 00:29:47 +0200, Olivier Chapuis wrote:
 
 Here 3 screenshots with the KDE-3.0 head menu. The hebrew and arabic
 screenshot are done with  Mark Leisher ClearlyU fonts (Roman Czyborra
 has also done Unicode font which cover a very large part of the
 unicode). The Japanese menu is done with the Bitstream Cyberbit ttf

Olivier, when you have some time can you please document these tips in
docs/i18n or docs/TrueTypeFonts whatever is more appropriated.

 which contains a big part of the unicode (Roman, Cyrillic, Greek,
 Hebrew, Arabic, Chinese, Korean, Japanese ...etc!!). 
 Mikhael is the hebrew menu ok?

Yes, it seems like KDE 3.0 added Bidi support, so uses logical order.

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

2002-04-27 Thread Mikhael Goikhman
On 26 Apr 2002 18:07:37 -0700, Nadim Shaikli wrote:
 
 On Thu, 25 Apr 2002, 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:

- 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?
   
   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). 

This is not quite correct. You add to .vimrc these lines:

  set guifont=-misc-fixed-medium-r-normal--20-200-75-75-c-100-arabeyes-1
  set encoding=utf-8

So you explicitly request utf-8. In fvwm it is currently determined
automatically by font and locale.

 BTW, couldn't those methods (libiconv and others) be things that could
 be included during configure time ?

libiconv is already auto-configure'd like any other non-portable thing.

  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.

I think too that a font should define the encoding used by the user
(together with locale if a font information is not enough), although it
may sound strange. The logic is that a user would not use that font if it
is not suitable for his text to display.

An alternative would be to require to specify an encoding together with
every string. Or adding Encoding option. But in the end we will find that
a user should usually specify Encoding and Font in the same place (for
example in MenuStyle, or like with .vimrc), so there is a duplication.

 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 :-)

Because a string  should only be Bidi'd if its encoding is iso8859-6,
but not koi8-r. Even vim should know string encoding (you specified utf8).

fvwm should also know to translate between charsets used by locales to the
ones fribidi_parse_charset knows about. For example on Solaris 8859-6,
on hpux iso86, but fribidi_parse_charset knows only about iso8859-6,
at least we can't risk. It also seems that fribidi does not know about the
iso8859-6.8x charset, still fvwm supports it. If you have any info on the
subject (fribidi or iso8859-6.8x), share it.

 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,

Re: Bidi status/help

2002-04-26 Thread Nadim Shaikli
 -- http://www.unicode.org/charts/PDF/UFE70.pdf).

 With a multibyte font (as iso10646) locale is important, as fvwm use a
 (powerful) method from X to display string and load font. Good fonts
 are automatically loaded (no need to specify the charset) and string
 are well displayed without the need to think to much :o)
 So with iso10646, at the present time, you should use an utf8
 locale (or good ttf font and XFree-4.good_version, here yet an
 other method is used).
 
 Now as utf8 grow in importance and a lot of system does not support
 utf8 locale I will see if fvwm can support utf8 on system which does
 not support utf8 locale. You may be happy with this but you should
 wait a bit. Ooops, this works now on my machine but I cannot commit
 the change before Monday, this should work on any X server (I have
 added a 4th method to display string ...).

OK, I think you are saying that with 10646 fonts the locale will
specify which subsections will be loaded and ought to be used as
the charsets to display within fvwm, right ?  What will a person
need to do in order to display say 4 languages (english, arabic,
japanese, russian) all within the same the 10646 font file - a
single locale won't suffice or will it ?  Seems like a more dynamic
solution ought to be sought.

Before I got this email, I was thinking more along a way to specify
the usage of utf8 within fvwm2rc (or fvwmrc :-); something along the
lines,

  Style * Charset utf8  // meaning all of 'em (*utf8* :-)
   -or-
  Style * Charset english:arabic:sv.UTF-8:iso8859-7

Just an idea.

  On the same related-topic what about those that are not running linux
  per se, but are using various unix flavors (at work, for instance, I'm
  on a Sparc Solaris (SunOS-5.7)).
 
 Fvwm is not written for Linux. We try to do so that fvwm can work
 on any system that can run an X server. I hope that fvwm has no
 problem with Sparc Solaris. However, some fvwm developers use Linux,
 GNU tools/libs and XFree so it may happen that there are some problems
 with exotic architecture (specially if there are not gnushed or/and
 XFreed), but we always try to fix these problems.

Yeah I know.  I was just noting it as food for thought and
a reminder :-)

Thanks for all your help and your very helpful explanations.

 - Nadim


__
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com
--
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

2002-04-25 Thread Olivier Chapuis
On Thu, Apr 25, 2002 at 12:36:58AM +, Mikhael Goikhman wrote:
 On 24 Apr 2002 18:15:49 +, Mikhael Goikhman wrote:
  
  On 24 Apr 2002 06:56:05 +0200, Olivier Chapuis wrote:
   
   On Fri, Apr 19, 2002 at 01:21:55AM +, Mikhael Goikhman wrote:

I don't know how to tell fvwm that the encoding is utf8; using *-10646-1
font is not enough. Setting $LC_CTYPE to, say, ar_JO.utf8 does not work.
I suppose Olivier knows.
   
   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?
  
  Hmm, not yet.
  
  My glibc-2.2.90 does not support utf8 locales (I don't know how .90 is
  possible if the latest is 2.2.5).
  
  I upgraded to glibc-2.2.5. This broke all my programs that use atexit(),
  I don't know why they did it. Anyway, glibc-2.2.5 supports utf8 locales.
  
  XFree86-4.1.0 does not seem to support utf8 locales, at least I added
  as you suggested these lines to locale.alias, it does not work.
  
ar_JO.utf8   ar_JO.UTF-8
en_US.utf8   en_US.UTF-8
he_IL.utf8   he_IL.UTF-8
ru_RU.utf8   ru_RU.UTF-8
  
  So I upgraded X to XFree86-4.2.0. The same result.
  Xlib does not support locale en_US.utf8. Ideas?
 
 Ok, changes to locale.alias do not work, but if I use the locales from the
 right column, both glibc and Xlib support them.
 

It seems that XFree-4 has only one utf8 locale en_US.utf8 and that
there are at the present time discussion/problems (i18n@XFree86.Org)
on how this locale force font loading ...

 I am now experimenting, the main problem is that I don't have true unicode
 fonts, specifying *-iso10646-1 gives some subset.


Yes, it seems that XFree  *-iso10646-1 fonts contains only a few part
of the all iso10646-1 characters. An other problems is that I think
that when you load a core X font all the characters are loaded, this
can cause memory problems. I think there is a way to load only
a part of an iso10646-1 font as iso10646[blabla]-1 or someting like
this I need to re found a doc on this.

 I also get this behaviour. When running with LC_CTYPE=en_US.UTF-8 and I
 specify incorrect font, it may wait several seconds. Error messages are
 not polished. I will try to improve them a bit later.
 
 *-iso8859-1 font gives this: *T*i*t*l*e where * is empty square, while
 *-iso8859-N (where N is from 2 to 15) shows it right: Title. Why is it?


I do not know.

Olivier
--
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

2002-04-25 Thread Olivier Chapuis
On Wed, Apr 24, 2002 at 12:41:38PM -0700, Nadim Shaikli wrote:
 On Wed, 24 Apr 2002 06:56:05 +0200,
   Olivier Chapuis olivier chapuis free fr wrote:
  
  On Fri, Apr 19, 2002 at 01:21:55AM +, Mikhael Goikhman wrote:
   On 18 Apr 2002 16:37:00 -0700, Nadim Shaikli wrote:

Mikhael/Olivier, I downloaded a recent snapshot (20020416) to test
out the Bidi code that was recently added.  I compiled with fribidi;
everything went smoothly - configure noted,

  With Bi-directional text support?   yes

yet I'm not sure how to go about displaying a window title in Arabic.
I tried the following,

  Using a 10646 font (its used successful in many other applications),
  I defined the following entries in my fvwm2rc file,

  Style * Font
 -misc-fixed-medium-r-normal--20-200-75-75-c-100-full10x20-1

  
  Nadim, can you send me a pointer to a doc about the full10x20 notation
  for loading iso10646 font?
 
 I'm not sure what you mean by loading the 10646 font, but you can
 download the non-truncated 10x20 font using the link(s) below,
 
   http://www.arabeyes.org/download/external/vim/10x20.bdf.gz
-or-
   http://www.arabeyes.org/download/external/vim/10x21.pcf.Z
 
 Note: the internal names of the fonts within the files might differ,
   please check 'mkfontdir' output (fonts.dir) for appropriate
   names -- if you have problems, don't hesitate to let me know.
 

The problem here is that the end of an X font name should/must be
the charset. So I was/am surprised by full10x20-1. So it seems
that full10x20 denote a font size ??? If this is the case I suggest
that you send a bug report to  http://www.arabeyes.org/ :o)

  AddToMenu arabic-test
  + Arabic Title 
  + ar-testExec exec xterm -title ?? -e rsh otho 
  + ??  Exec exec xterm -title test -e rsh otho 

  In my .xinitrc prior to starting fvwm2, I 'xset fp+
 my_10646_font_file',
  I then start fvwm2; I invoke that ar-test entry, the xterm appears,
  but the title is NOT displayed in arabic.  The menu entry is not noted
  in Arabic either.  Do note that the environment is set so that I can
 use
  other applications that require the Bidi library and the 10646 font 
(so
  they're very much loaded - I hope I don't need to muck with locales 
and
  such :-)
   
   I don't know how to tell fvwm that the encoding is utf8; using *-10646-1
   font is not enough. Setting $LC_CTYPE to, say, ar_JO.utf8 does not work.
   I suppose Olivier knows.
  
  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).

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 

Re: Bidi status/help

2002-04-24 Thread Olivier Chapuis
On Fri, Apr 19, 2002 at 01:21:55AM +, Mikhael Goikhman wrote:
 On 18 Apr 2002 16:37:00 -0700, Nadim Shaikli wrote:
  
  Mikhael/Olivier, I downloaded a recent snapshot (20020416) to test
  out the Bidi code that was recently added.  I compiled with fribidi;
  everything went smoothly - configure noted,
  
With Bi-directional text support?   yes
  
  yet I'm not sure how to go about displaying a window title in Arabic.
  I tried the following,
  
Using a 10646 font (its used successful in many other applications),
I defined the following entries in my fvwm2rc file,
  
Style * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-full10x20-1
  

Nadim, can you send me a pointer to a doc about the full10x20 notation
for loading iso10646 font?

AddToMenu arabic-test
+ Arabic Title 
+ ar-testExec exec xterm -title Ù?رحØ?ا -e rsh otho 
+ Ù?رحØ?ا  Exec exec xterm -title test -e rsh otho 
  
In my .xinitrc prior to starting fvwm2, I 'xset fp+ my_10646_font_file',
I then start fvwm2; I invoke that ar-test entry, the xterm appears,
but the title is NOT displayed in arabic.  The menu entry is not noted
in Arabic either.  Do note that the environment is set so that I can use
other applications that require the Bidi library and the 10646 font (so
they're very much loaded - I hope I don't need to muck with locales and
such :-)
 
 I don't know how to tell fvwm that the encoding is utf8; using *-10646-1
 font is not enough. Setting $LC_CTYPE to, say, ar_JO.utf8 does not work.
 I suppose Olivier knows.


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)

 I only tested 8-bit encodings, iso8859-6 and iso8859-8.
 
 Do the following. Install iso8859-6.8x fonts from:
 
   http://www.langbox.com/bidimozilla/fontXFE/
 
 Do the same with iso8859-6 fonts in old/ subdirectory.
 Run xmessage from a script (if 8-bit chars can't be typed in your shell):
 
   xmessage -name a) ÓáÑ - Åâäêåê, Î×è× ÌèêÉ this message is not really 
 important, just long enough
 
 I don't know what the string means, I copied it from some web site.
 Do the following:
 
   Style Xmessage Font *-iso8859-6 # Bidi applied, visual Arabic
   Style Xmessage Font *-iso8859-6.8x  # Bidi not applied, logical Arabic
 
 The same with Hebrew:
 
   xmessage -name a) îùôè áòáøéú this message is not really important
   Style Xmessage Font *-iso8859-8 # Bidi applied, visual Hebrew
 
 I tried to add now iso8859-6.8x as bidi-enabled in libs/FlocaleCharset.h,
 but it failed. I tried all cases including iso8859-6.8x (what fonts.dir
 says), iso8859-6.8X (what pcf says), iso-8859-6.8X (what url says),
 nothing works. Olivier, what should be done?
 

Hum ..., do you try to add the line
CT_ENTRY(ISO8859-6.8X,   iso8859_6,   ISO8859-6)
at the end of the FlocaleCharsetTable[] initialization (around line 338
of libs/FlocaleCharset.h)?

What is the difference between ISO8859-6 and ISO8859-6.8X ?

Olivier
--
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

2002-04-24 Thread Nadim Shaikli
On Wed, 24 Apr 2002 06:56:05 +0200,
  Olivier Chapuis olivier chapuis free fr wrote:
 
 On Fri, Apr 19, 2002 at 01:21:55AM +, Mikhael Goikhman wrote:
  On 18 Apr 2002 16:37:00 -0700, Nadim Shaikli wrote:
   
   Mikhael/Olivier, I downloaded a recent snapshot (20020416) to test
   out the Bidi code that was recently added.  I compiled with fribidi;
   everything went smoothly - configure noted,
   
 With Bi-directional text support?   yes
   
   yet I'm not sure how to go about displaying a window title in Arabic.
   I tried the following,
   
 Using a 10646 font (its used successful in many other applications),
 I defined the following entries in my fvwm2rc file,
   
 Style * Font
-misc-fixed-medium-r-normal--20-200-75-75-c-100-full10x20-1
   
 
 Nadim, can you send me a pointer to a doc about the full10x20 notation
 for loading iso10646 font?

I'm not sure what you mean by loading the 10646 font, but you can
download the non-truncated 10x20 font using the link(s) below,

  http://www.arabeyes.org/download/external/vim/10x20.bdf.gz
   -or-
  http://www.arabeyes.org/download/external/vim/10x21.pcf.Z

Note: the internal names of the fonts within the files might differ,
  please check 'mkfontdir' output (fonts.dir) for appropriate
  names -- if you have problems, don't hesitate to let me know.

 AddToMenu arabic-test
 + Arabic Title 
 + ar-testExec exec xterm -title Ù?رحØ?ا -e rsh otho 
 + Ù?رحØ?ا  Exec exec xterm -title test -e rsh otho 
   
 In my .xinitrc prior to starting fvwm2, I 'xset fp+
my_10646_font_file',
 I then start fvwm2; I invoke that ar-test entry, the xterm appears,
 but the title is NOT displayed in arabic.  The menu entry is not noted
 in Arabic either.  Do note that the environment is set so that I can
use
 other applications that require the Bidi library and the 10646 font (so
 they're very much loaded - I hope I don't need to muck with locales and
 such :-)
  
  I don't know how to tell fvwm that the encoding is utf8; using *-10646-1
  font is not enough. Setting $LC_CTYPE to, say, ar_JO.utf8 does not work.
  I suppose Olivier knows.
 
 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.

On the same related-topic what about those that are not running linux
per se, but are using various unix flavors (at work, for instance, I'm
on a Sparc Solaris (SunOS-5.7)).

Thanks  let me know if you need more info.

 - Nadim (please continue to CC for a faster response :-)


__
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/
--
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

2002-04-24 Thread Mikhael Goikhman
On 24 Apr 2002 06:56:05 +0200, Olivier Chapuis wrote:
 
 On Fri, Apr 19, 2002 at 01:21:55AM +, Mikhael Goikhman wrote:
  On 18 Apr 2002 16:37:00 -0700, Nadim Shaikli wrote:
   
   Mikhael/Olivier, I downloaded a recent snapshot (20020416) to test
   out the Bidi code that was recently added.  I compiled with fribidi;
   everything went smoothly - configure noted,
   
 With Bi-directional text support?   yes
   
   yet I'm not sure how to go about displaying a window title in Arabic.
   I tried the following,
   
 Using a 10646 font (its used successful in many other applications),
 I defined the following entries in my fvwm2rc file,
   
 Style * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-full10x20-1
 
 Nadim, can you send me a pointer to a doc about the full10x20 notation
 for loading iso10646 font?
 
 AddToMenu arabic-test
 + Arabic Title 
 + ar-testExec exec xterm -title Ù?رحØ?ا -e rsh otho 
 + Ù?رحØ?ا  Exec exec xterm -title test -e rsh otho 
   
 In my .xinitrc prior to starting fvwm2, I 'xset fp+
 my_10646_font_file', I then start fvwm2; I invoke that ar-test
 entry, the xterm appears, but the title is NOT displayed in
 arabic.  The menu entry is not noted in Arabic either.  Do note
 that the environment is set so that I can use other applications
 that require the Bidi library and the 10646 font (so they're very
 much loaded - I hope I don't need to muck with locales and such
 :-)
  
  I don't know how to tell fvwm that the encoding is utf8; using *-10646-1
  font is not enough. Setting $LC_CTYPE to, say, ar_JO.utf8 does not work.
  I suppose Olivier knows.
 
 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?

Hmm, not yet.

My glibc-2.2.90 does not support utf8 locales (I don't know how .90 is
possible if the latest is 2.2.5).

I upgraded to glibc-2.2.5. This broke all my programs that use atexit(),
I don't know why they did it. Anyway, glibc-2.2.5 supports utf8 locales.

XFree86-4.1.0 does not seem to support utf8 locales, at least I added
as you suggested these lines to locale.alias, it does not work.

  ar_JO.utf8   ar_JO.UTF-8
  en_US.utf8   en_US.UTF-8
  he_IL.utf8   he_IL.UTF-8
  ru_RU.utf8   ru_RU.UTF-8

So I upgraded X to XFree86-4.2.0. The same result.
Xlib does not support locale en_US.utf8. Ideas?

 - 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)
 
  I only tested 8-bit encodings, iso8859-6 and iso8859-8.
  
  Do the following. Install iso8859-6.8x fonts from:
  
http://www.langbox.com/bidimozilla/fontXFE/
  
  Do the same with iso8859-6 fonts in old/ subdirectory.
  Run xmessage from a script (if 8-bit chars can't be typed in your shell):
  
xmessage -name a) ÓáÑ - Åâäêåê, Î×è× ÌèêÉ this message is not really 
  important, just long enough
  
  I don't know what the string means, I copied it from some web site.
  Do the following:
  
Style Xmessage Font *-iso8859-6 # Bidi applied, visual Arabic
Style Xmessage Font *-iso8859-6.8x  # Bidi not applied, logical Arabic
  
  The same with Hebrew:
  
xmessage -name a) îùôè áòáøéú this message is not really important
Style Xmessage Font *-iso8859-8 # Bidi applied, visual Hebrew
  
  I tried to add now iso8859-6.8x as bidi-enabled in libs/FlocaleCharset.h,
  but it failed. I tried all cases including iso8859-6.8x (what fonts.dir
  says), iso8859-6.8X (what pcf says), iso-8859-6.8X (what url says),
  nothing works. Olivier, what should be done?
  
 
 Hum ..., do you try to add the line
   CT_ENTRY(ISO8859-6.8X,   iso8859_6,   ISO8859-6)
 at the end of the FlocaleCharsetTable[] initialization (around line 338
 of libs/FlocaleCharset.h)?

I tried to extend the iso8859_6 definition instead. Now it works.

 What is the difference between ISO8859-6 and ISO8859-6.8X ?

I don't know. Probably there were a revision of a charset specification.
I am still waiting for a confirmation that bidi works correctly for both.

Regards,
Mikhael.
--
Visit the official FVWM web page at URL:http://www.fvwm.org/.
To unsubscribe from the list, send 

Re: Bidi status/help

2002-04-24 Thread Mikhael Goikhman
On 24 Apr 2002 18:15:49 +, Mikhael Goikhman wrote:
 
 On 24 Apr 2002 06:56:05 +0200, Olivier Chapuis wrote:
  
  On Fri, Apr 19, 2002 at 01:21:55AM +, Mikhael Goikhman wrote:
   
   I don't know how to tell fvwm that the encoding is utf8; using *-10646-1
   font is not enough. Setting $LC_CTYPE to, say, ar_JO.utf8 does not work.
   I suppose Olivier knows.
  
  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?
 
 Hmm, not yet.
 
 My glibc-2.2.90 does not support utf8 locales (I don't know how .90 is
 possible if the latest is 2.2.5).
 
 I upgraded to glibc-2.2.5. This broke all my programs that use atexit(),
 I don't know why they did it. Anyway, glibc-2.2.5 supports utf8 locales.
 
 XFree86-4.1.0 does not seem to support utf8 locales, at least I added
 as you suggested these lines to locale.alias, it does not work.
 
   ar_JO.utf8   ar_JO.UTF-8
   en_US.utf8   en_US.UTF-8
   he_IL.utf8   he_IL.UTF-8
   ru_RU.utf8   ru_RU.UTF-8
 
 So I upgraded X to XFree86-4.2.0. The same result.
 Xlib does not support locale en_US.utf8. Ideas?

Ok, changes to locale.alias do not work, but if I use the locales from the
right column, both glibc and Xlib support them.

I am now experimenting, the main problem is that I don't have true unicode
fonts, specifying *-iso10646-1 gives some subset.

I also get this behaviour. When running with LC_CTYPE=en_US.UTF-8 and I
specify incorrect font, it may wait several seconds. Error messages are
not polished. I will try to improve them a bit later.

*-iso8859-1 font gives this: *T*i*t*l*e where * is empty square, while
*-iso8859-N (where N is from 2 to 15) shows it right: Title. Why is it?

  - 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)

When I use:

  Style * Font xft:Luxi Mono:Medium:Roman:size=14:encoding=iso10646-1

only latin is displayed, but I can see where are spaces and see that Bidi
is applied to Arabic/Hebrew in utf8.

I use this app for testing (where ar_JO may be replaced by he_IL, ru_RU):

  xmessage -name `env LANG=ar_JO.UTF-8 date '+%a %d/%b/%Y'` nothing

When I use (fvwm is still run under LC_CTYPE=en_US.UTF-8):

  Style * Font *something_from_426_unicode_fonts*-iso10646-1

it works as expected except that I don't have unicode fonts for Arabic
(*-arabeyes-1 seems unusable at all, and another my *-iso10646-1 has only
Arabic, not latin). I am able to see Russian and Hebrew without problems.
Bidi works well with utf8.

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]


Bidi status/help

2002-04-18 Thread Nadim Shaikli
Mikhael/Olivier, I downloaded a recent snapshot (20020416) to test
out the Bidi code that was recently added.  I compiled with fribidi;
everything went smoothly - configure noted,

  With Bi-directional text support?   yes

yet I'm not sure how to go about displaying a window title in Arabic.
I tried the following,

  Using a 10646 font (its used successful in many other applications),
  I defined the following entries in my fvwm2rc file,

  Style * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-full10x20-1

  AddToMenu arabic-test
  + Arabic Title 
  + ar-testExec exec xterm -title Ù?رحبا -e rsh otho 
  + Ù?رحبا  Exec exec xterm -title test -e rsh otho 

  In my .xinitrc prior to starting fvwm2, I 'xset fp+ my_10646_font_file',
  I then start fvwm2; I invoke that ar-test entry, the xterm appears,
  but the title is NOT displayed in arabic.  The menu entry is not noted
  in Arabic either.  Do note that the environment is set so that I can use
  other applications that require the Bidi library and the 10646 font (so
  they're very much loaded - I hope I don't need to muck with locales and
  such :-)

What am I missing (and/or doing wrong).  The documentation (fvwm.1)
along the lines of usage are somewhat lacking and so I'm wondering
if you could give me some snippets of things that have worked for ya
(ie. some guidance).

Regards,

 - Nadim


__
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/
--
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

2002-04-18 Thread Mikhael Goikhman
On 18 Apr 2002 16:37:00 -0700, Nadim Shaikli wrote:
 
 Mikhael/Olivier, I downloaded a recent snapshot (20020416) to test
 out the Bidi code that was recently added.  I compiled with fribidi;
 everything went smoothly - configure noted,
 
   With Bi-directional text support?   yes
 
 yet I'm not sure how to go about displaying a window title in Arabic.
 I tried the following,
 
   Using a 10646 font (its used successful in many other applications),
   I defined the following entries in my fvwm2rc file,
 
   Style * Font -misc-fixed-medium-r-normal--20-200-75-75-c-100-full10x20-1
 
   AddToMenu arabic-test
   + Arabic Title 
   + ar-testExec exec xterm -title Ù?رحبا -e rsh otho 
   + Ù?رحبا  Exec exec xterm -title test -e rsh otho 
 
   In my .xinitrc prior to starting fvwm2, I 'xset fp+ my_10646_font_file',
   I then start fvwm2; I invoke that ar-test entry, the xterm appears,
   but the title is NOT displayed in arabic.  The menu entry is not noted
   in Arabic either.  Do note that the environment is set so that I can use
   other applications that require the Bidi library and the 10646 font (so
   they're very much loaded - I hope I don't need to muck with locales and
   such :-)

I don't know how to tell fvwm that the encoding is utf8; using *-10646-1
font is not enough. Setting $LC_CTYPE to, say, ar_JO.utf8 does not work.
I suppose Olivier knows.

I only tested 8-bit encodings, iso8859-6 and iso8859-8.

Do the following. Install iso8859-6.8x fonts from:

  http://www.langbox.com/bidimozilla/fontXFE/

Do the same with iso8859-6 fonts in old/ subdirectory.
Run xmessage from a script (if 8-bit chars can't be typed in your shell):

  xmessage -name a) ÓáÑ - Åâäêåê, Î×è× ÌèêÉ this message is not really 
important, just long enough

I don't know what the string means, I copied it from some web site.
Do the following:

  Style Xmessage Font *-iso8859-6 # Bidi applied, visual Arabic
  Style Xmessage Font *-iso8859-6.8x  # Bidi not applied, logical Arabic

The same with Hebrew:

  xmessage -name a) îùôè áòáøéú this message is not really important
  Style Xmessage Font *-iso8859-8 # Bidi applied, visual Hebrew

I tried to add now iso8859-6.8x as bidi-enabled in libs/FlocaleCharset.h,
but it failed. I tried all cases including iso8859-6.8x (what fonts.dir
says), iso8859-6.8X (what pcf says), iso-8859-6.8X (what url says),
nothing works. Olivier, what should be done?

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]


a little CVS help

2001-09-19 Thread Sidik Isani
Hi folks -

  What's the CVS checkout tag we are using for the 2.4.x releases?

Thanks,

- Sidik
--
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: a little CVS help

2001-09-19 Thread Dan Espen
Sidik Isani [EMAIL PROTECTED] writes:
 Hi folks -
 
   What's the CVS checkout tag we are using for the 2.4.x releases?

Do cvs -v status on ChangeLog to see all the tags applied.
Look in configure.in at AM_INIT_AUTOMAKE to see the current branch.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214   E-mail: [EMAIL PROTECTED]
Piscataway, NJ 08854 Phone: (732) 699-5570
--
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]


CVS migo: * line up the output of ./configure --help

2001-08-15 Thread FVWM CVS
CVSROOT:/home/cvs/fvwm
Module name:fvwm
Changes by: migo01/08/15 14:45:21

Modified files:
.  : ChangeLog configure.in acinclude.m4 
 INSTALL.fvwm 
utils  : ChangeLog fvwm-config.1 

Log message:
* line up the output of ./configure --help
* small improvements in documentation

--
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]