Subject: Re: FvwmKb (fwd)

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 16 Sep 1999 07:54:08 +0300 (IDT)

---------- Forwarded message ----------
Date: 12 Sep 1999 21:34:57 +0400
From: Alexander Vorobiev <[email-masked]>
To: Mikhael Goikhman <[email-masked]>
Subject: Re: FvwmKb

Hello, Mikhael!

Mikhael Goikhman <[email-masked]> writes:

> 1) What are your plans about FvwmKb, are you still interested to continue
> developing it?

Yes, I plan to release v0.3 soon.

> 
> 2) Do you prefer FvwmKb to be an external fvwm module or an internal fvwm
> module? In the first case you maintain it and, for example, can add support
> for other window managers. In the second case fvwm-workers (probably with
> you included) maintain it inside fvwm.

My main idea was/is to make FvwmKb as window manager-independent as
possible so if some wm supports external modules which are able to
send it decoration changing messages, it should be fairly easy to
adapt FvwmKb to this wm.

On the other hand I think it would be a good idea to distribute FvwmKb 
within fvwm as well as a stand alone application. So if fvwm
development team included the module into the fvwm source tree I
would take full responsibility of maintaining it and synchronizing
with stand alone version.

My todo list for v0.3 is

1. make it compile with egcs-1.1.2 (see below)
2. couple of minor bugfixes
3. instruction on how to use FvwmKb with scwm (it involves several
   simple enhancements to scwm's fvwm compatibility module

For v0.4 I plan to add support for accepting commands from fvwm to
change keyboard layouts so it would be possible to add, say, a menu
with items "Russian", "English", etc and change layouts with mouse clicks.
Another possible improvement in v0.4 would be to rewrite all communication
with wm using c++ streams

> 
> 3) In my opinion, the idea of FvwmKb is very good and we would want to
> include it into the core fvwm distribution. But there is a problem here.
> Currently we don't have any C++ code in the fvwm distribution and are
> very happy with this fact, because the current state is that C++ compilers
> have many problems on various systems in addition to C compiler problems.
> And autoconf does not always help.
> 
> So, I believe, the question is what do you think about rewriting it in C?
> I know it sounds bad, but are all Exceptions or an abstract wm-module layer
> really needed? The benefits of C is that you can use libfvwm, which has
> many useful things for fvwm modules. Also it helps us maintain all modules
> if they have similar implementations.

No, I don't plan/want to rewrite FvwmKb in C. There are several
reasons, main of which are

1. I use hashtable to store window-id/current-xkb-layout pairs. The
   hash table implementation I deploy is from STL (standard template
   library). I hate reinventing wheels and I don't like the idea of
   spending my time (re)implementing efficient hash table myself.

2. I believe that programming with exceptions makes programmer's life
   much easier and, more important, makes programs less error-prone
   and _much_ easier to debug. 

Look at it from another side: I tried to carefully rewrite/enhance all
functions I use from fvwm library, libc and Xlib to generate
exceptions at the lowest levels instead of returning error codes. So
why don't consider my exceptions-enabled code as a foundation to, say, 
libfvwm++ - library for writing modules in c++. I'm sure this would
encourage many new would-be modules writers to join the team :) All
exceptions related things are separated in FvwmKb source so it would
be very easy to move them to some other place in fvwm source.

And there still is a reason

3. I still hope to add support for other window managers so the
   abstract wm layer is essential in my opinion

> 
> BTW, I didn't manage to compile FvwmKb-0.2:

I developed FvwmKb using egcs-1.0.3 and glibc-2.0 from RedHat 5.2. New
RedHat 6.0 delivers egcs-1.1.2 and glibc-2.1. New glibc defines
sa_handler as a macro making it impossible to have such a variable. Do
the following changes to the FvwmKb source:

[ a patch is skipped ]

It should compile without errors now.

Regards,
Alexander

-- 
If you shoot yourself in the foot in lisp, your foot
hurts.  If you shoot yourself in the foot in C++, you die.
		Duane Rettig

--
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-masked].
To report problems, send mail to [email-masked]