[Xfce4-commits] r25185 - in libfrap/trunk/libfrap/menu: . tests

[Olivier Fourdan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hi

Stephan Arts wrote:

>>> Now that the most important menu spec tests are passed and Brian
>>> already uses FrapMenu in xfdesktop, shouldn't we move FrapMenu out of
>>> libfrap and into Xfce trunk? Of course this raises the question about
>>> how we plan to reorganize our libraries for Xfce 4.6 again - I'd be
>>> glad if we could come to a conclusion here soon.
>> No opinions?
> 
> Well, if we can agree on which Gtk+ version will be the minimal
> requirement for 4.6 (2.10 has been mentioned more then once on this
> list) we can decide which stuff is deprecated regarding this and
> perhaps some (new) freedesktop.org standards.

I'd really prefer 2.8 instead of 2.10, Edgy will ship with 2.8 and
setting a dependency on gtk+-2.10 would exclude a large part of our user
base.

One could argue that we are distro agnostic and we should not care much
about Debian or any other distribution (being Linux or any other Unix or
more), but I believe xfce doesn't really target the people who always
get the latest version...

> About xfce-mcs-manager:
> Could it be replaced by a construction around D-Bus?

MCS stands for multi-channel settings. It's an enhancement of Xsettings
that use X atoms to store key/values.

The pros of MCS are:

- - Host transparent settings. No matter on what host the application is
running, as long as it connects to a display, it use the settings set on
the corresponding MCS manager.

- - MCS shares the same architecture as Xsettings. As long as Xsettings is
the standard, you won't be able to remove it completely.

- - It stores and loads values to/from XML file, and is able to read/save
the channel automatically. The API is very simple.

The cons:

- - Settings are set by the MCS manager. There is no way for an
application to set the values by itself. Actually, MCS was never
designed for that.

- - The daemon sets the values and also run the various UI.

Now, ideally, we should have an Xsettings daemon separate from the UI
and separate from the settings storage.

It should be as simple to use as the current MCS, ideally with an API
that would ease migration of existing apps. Keeping network transparency
would be a plus, not necessarily mandatory.

Cheers,
Olivier.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFF/vxCFHBtvh5LRUARAmXeAJwMJXXw0pMXVEPPeencAm1iQ6t/eQCfXvBA
9G1wx/vl4amob2O51JCbMPw=
=YFol
-----END PGP SIGNATURE-----