Subject: fvwm-ewmh pre-announce

From: Olivier Chapuis <[email-masked]>
Date: Fri, 4 May 2001 22:04:21 +0200

Hello,

fvwm-ewmh is almost ready. I will send  the announcement that
follow to the world when FVWM 2.4.0 or 2.3.32 will be released 
(if there is no serious objection). I do not know if it is better to do
the announce with 2.4.0 or soon with 2.3.32.
Oops, fvwm-2.3.32 has been released, during I wrote this mail.
The download links at the home page are not active, however,
if you want to test fvwm-ewmh you can download a pre-version at:

http://fvwm-ewmh.sourceforge.net/testing/

you just have to use the 2.3.32 tarball and follow the instructions
given in the README or at the home page.

Any suggestions or comments are really welcome.

Regards, Olivier

-----------------------------------------------------
Subject: fvwm-ewmh-0.1 is released

I am glad to announce the first version of fvwm-ewmh.

fvwm-ewmh is constituted by a module, FvwmNetHints, and a patch
against  the last stable FVWM version/candidate: fvwm-2.3.32/2.4.0.
With these FVWM can handle Extended Window Manager Hints from the
freedesktop group.
This allows, for example, to run FVWM with KDE version 2. 
 
This package is alpha, however, it works not so bad on my machine.

Home Page (Download, Installation, Running, FAQ):
    http://fvwm-ewmh.sourceforge.net/

Screen Shots:
    http://fvwm-ewmh.sourceforge.net/screenshots/

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

---

From: Mikhael Goikhman <[email-masked]>
Date: Fri, 4 May 2001 23:15:33 +0000

> Any suggestions or comments are really welcome.

This is a suprise to me. Seems like a serious work.
I guess we should just include FvwmNetHints module and patch FvwmPager.
Including a module, which does not need a configure support is as simple
as adding one word in modules/Makefile.am.

I probably can't test the functionality for some time, I don't have KDE2.

Regards,
Mikhael.

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 5 May 2001 06:25:52 +0200

Le Samedi  5 Mai 2001 01:15, vous avez écrit :
> > [snip]

I warn the fvwm-workers a few weeks a ago:

http://www.hpc.uh.edu/fvwm/archive/0104/msg00141.html

but maybe I was not clear. Also, I was not sure that I will finish
the work at all (but it was so funny to see kicker respecting all my desire;
on the other hand kdesktop is really a problem).

> as adding one word in modules/Makefile.am.

I am not sure that we have to include fvwm-ewmh in FVWM now. Maybe,
we can include it in the 2.4.x series. The reasons are:
- We should not do anything that delays 2.4.0
- fvwm-ewmh needs some change to fvwm2 source codes (for the (mini)icons
functionality and for applications of Desktop type). 
- The FvwmPager patch is a bit sensible: there is a "big" change to the
windows stacking Pager code.
- In fact, FvwmNetHints needs a change to the configure procedure: the
FVWM configure procedure define IMLIB if it found the gdk imlib as
FvwmNetHints needs only the imlib (this save a lot of memory).
- The code and the man page are really alpha.

> I probably can't test the functionality for some time, I don't have KDE2.

There is one functionality that does not need any "compliant" applications
and that you may found funny.
If you use:

*FvwmNetHints: SendMiniIcon All
*FvwmNetHints: MiniIconSize w h

Then, all your mini icons (from the MiniIcon Style option) will have size wxh.

Regards, Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 5 May 2001 20:01:20 +0000

> - We should not do anything that delays 2.4.0

Yes, of course.

> FvwmNetHints needs only the imlib (this save a lot of memory).

Exactly. I will finish to rename the current IMLIB to GDK_IMLIB.

Later we will need both GDK_IMLIB for FvwmGtk and pure IMLIB for fvwm,
because we will want to support all image types, not only xpm.

Regards,
Mikhael.

---

From: Danek Duvall <[email-masked]>
Date: Sat, 5 May 2001 19:37:32 -0700

> because we will want to support all image types, not only xpm.

Please don't make it a requirement, though; I truly dislike having to
compile all sorts of extra things for something that should be pretty
simple.

Danek

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 6 May 2001 09:59:50 +0000

> compile all sorts of extra things for something that should be pretty

I only meant that we need to autoconfigure support for both, not only one.
You will be able to turn them off, like it is possible with xpm now.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 6 May 2001 13:10:46 +0200

> - The code and the man page are really alpha.

What about the more esoteric features of the spec like unicode
icon titles?  The spec demands that the window manager provides a
unicode window title even if the application did not.

Bye

Dominik ^_^  ^_^

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

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 6 May 2001 15:08:52 +0200

> unicode window title even if the application did not.

Nothing about unicode is implemented (yet ?) in fvwm-ewmh. This does
not cause problems with applications that I known and which respect the
spec.
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 6 May 2001 15:32:13 +0200

> not cause problems with applications that I known and which respect the

I'd expect problems with the desktop environment, not with the
applications.  I'm not a big fan of that unicode "feature" in the
spec anyway.  The corresponding paragraph in the spec can be
interpreted like this:

  The window manager should implement unicode window titles.  If
  it does not, it must implement unicode window titles instead.

The spec forces the window manager to translate eight bit
characters to unicode.  I reported this to the list along with
other inconsistencies in the spec several months ago, but nobody
seems to care :-(

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Sun, 6 May 2001 21:28:48 +0200

>   it does not, it must implement unicode window titles instead.

Basically this is true, but in practice, IMHO, this is not a problem:
1. The ewmh spec is build on the ICCCM draft.
2. The client (application) should set _NET_WM_NAME (utf-8 encoding), this
is not a problem for the wm. 
3.  "*if* the Window Manager displays a window name other than
_NET_WM_NAME the Window Manager MUST set  _NET_WM_NAME_VISIBLE
to the title displayed in UTF-8 encoding.", So: 

  A desktop environment, should see if _NET_WM_NAME_VISIBLE
  is set, if not set then it has to look at  _NET_WM_NAME and if this
  one too is not set  then the desktop env should respect the ICCCM and
  use the usual WM_NAME. Of course KDE do that.

4. An application should set WM_NAME, and the wm can use it (we just
have to do not say that to the free desktop group :o).

The situation is the same with icon name, so it seems to me that a wm can
be ewmh compliant without using utf-8 encoding. There is also the
 _NET_NET_DESKTOP_NAMES which use utf-8 string, but it is clearly say
in the spec. that this is not an important thing (but I've got problems with
KDE here :o) for an other reason I think)

Any way, I am interested by the utf 8 stuff. It is a good solution for
supporting all the languages. So, maybe I will implement the utf-8 part
of the spec. in the future. At the present time I have to take a look at
the different C libraries available. Any suggestion is welcome.

> other inconsistencies in the spec several months ago, but nobody

Yes, there are problems in the spec., there are also good ideas and
things that I do not like (e.g., Desktop applications implementation).
Also, the spec. is young and there is only one "full" implementation
of it. So, we may hope that version 2 will be good enough. And it
seems to me that the current version is "OK" for an implementation.

Regards, Olivier