New gnome-libs stuff (need help from you guys)

[George <jirka 5z com>]

[BTW: I'm experimenting with not putting '...' in the message :) ]

OK, I need you guys to test some stuff to see if it's stable and compatible
enough change for it to go into the head of gnome-libs. These changes need to
be backward binary compatible and need to be very stable. That is why I am
asking for your help.

Check out the cvs branch of WM_CLASSES_AND_DND_DENTRY from gnome-libs and
gnome-core (with cvs -z3 update -rWM_CLASSES_AND_DND_DENTRY) And please test
this. Also can people test this with as many different combinations of
gnome-core as possible to guarantee it's really binary compatible? However
You will need the WM_CLASSES_AND_DND_DENTRY branch of gnome-libs to compile
the WM_CLASSES_AND_DND_DENTRY branch of gnome-core.


The problem(s):

Problem 1:
	No visual feedback for starting applications. I've had this on my
todolist for months. The solution that is the nicest seems to be a solution
in the spirit of FvwmButtons or WindowMaker dock.

Problem 2:
	No dropping on the icons on the panel, and generally no such
information is stored about applications from our menus. Using metadata for
this is inadequate for this as it makes it 1) impossible for the panel to
use, 2) hard to distribute, 3) unreliable as metadata is not 100% solid on
unix in the first place, 4) won't work over network.

Solution 1:
	Add a field to the .desktop file which is a vector of WM_CLASS
strings of any window which when mapped, indicates that the application is
now running. My current solution takes strings from the vector one by one,
waits for newly mapped windows, and tries to match the strings against one of
the WM_CLASS strings (either one). The entry in the .desktop files looks
like this:

WMClasses=gnomecc

This works for the gnome control center .desktop for example.

Solution 2:
	Add a series of fields to the .desktop files describing different
actions the program taking care of the actual launching should take depending
on the type of the drop that occured. My implementation stores the whole
thing in a single vector, in which the first vector is the mime type of the
drop, and the rest of the fields are the command line of the action. In the
command line %s will be substituted directly by the dropped data (for example
if the drop was a string or an URL). %f will be a list of files from a
text/uri-list type drop, and %u will be a list of files in url format. The
last two are what KDE uses so we may actually make this work with kde as
well.

Example for the gnome-help-browser:

DropAction0=text/uri-list gnome-help-browser %f
DropAction1=x-url/http gnome-help-browser %s
DropAction2=_NETSCAPE_URL gnome-help-browser %s

NOTE: In my implementation on the WM_CLASSES_AND_DND_DENTRY branch only the
.desktop's that are in gnome-core are of course "treated". Though the panel
and the API will work with .desktops which don't have these fields, they are
purely OPTIONAL.


So can you guys please test this so that we can be sure it's a rock solid
scheme and that it doesn't have any problems and that it's completely
backward binary compatible? As far as I see it all should be compatible and
the new changes are optional. These are some of the most requested features
for the panel and that is why I want this to get into one of the 1.0 releases
of gnome-libs/gnome-core.

George

-- 
------------------------------------------------------------------------------
George Lebl <jirka@5z.com> http://www.5z.com/jirka/
------------------------------------------------------------------------------
  The following implements RSA in perl and is illegal to export from the US:

          #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
          $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
          lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)