[Xfc-dev] Xcfe4 wrapping features ?

[Brian J. Tarricone]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Erik pretty much said what I planned to say, but perhaps I have
something to add...

Bo Lorentsen wrote:
> Hi ...
> 
> I have tried to find a way to get an overview of the components in xfce 
> desktop, while waiting to be able to submit my sourceview port :-)
> 
> As I can see it, we have the following systems (in the order of 
> importance as I see it) that need attention :

Unfortunately, your order of importance is a bit off.

> 1. MCS setting access (cool thing, are there at standard for setting layout)

MCS is useless from a bindings perspective.  At best, it's only
really intended to be used by the core Xfce desktop components
(which are all written in C, and will likely remain that way).
As I mentioned in a previous email, MCS (and therefore
libxfce4mcs) will likely (hopefully!) disappear by 4.6.

> 2. libexo (is it mature and do we need more ?)

libexo is certainly useful from an app-builder's perpsective,
though I wouldn't put it at #2.

> 3. FileDialog (will this have Thunar relation/bindings)

Are you talking about XfceFileChooser?  It's deprecated.
Grepping for 'DEPRECATED' in the library header files will tell
you what definitely doesn't need to be wrapped at this point.
Not sure how this relates to thunar.

> 4. xfprint system (Does this work if GTK+ gets its own printing service ?)

It should (note that gtk already does have its own printing API).
 I think this is a relatively low priority, regardless.

> 5. Panel extension

I'd rate this up higher.

> 6. Thunar extension

That's about right.  libthunarx only really applies to one
application (sorta), so it's probably low-priority.  If you were
to wrap libthunarx, you'd have to wrap libthunar-vfs for all
practical purposes, anyway.

However, you've missed what I'd consider #1, and mentioned in a
previous email: libxfce4util and libxfcegui4.  Feel free to leave
out anything that's deprecated, of course.

> It is hard to get some understanding of what Xfce really is (yes it is 
> an desktop), and I think some kind of introduction is needed somewhere. 
> What is the main goal for this desktop, and how does the peaces fit 
> together ?

I believe I more or less gave an overview of the libraries I
believe should be wrapped in another email, but here's a quick
summary:

- --> libxfce4util: base non-GUI utility library.  You could think
of this sort of on par with glib.  There's a .desktop file
parser, an RC file (i.e., Windows .ini, glib 'keyfile')
reader/writer, a freedesktop.org-compliant resource lookup
mechanism, and some portable function wrappers (beyond what glib
provides) and other utility functions.

- --> libxfce4mcs, xfce-mcs-manager: settings system, library and
daemon.  Don't worry about this too much; from a bindings
perspective, it's not useful.  The system works well enough for
what we're doing now, but it's not really suitable as a generic
configuration system.  Currently only core Xfce desktop
components really use it, and by 4.6 we should hopefully have a
replacement.

- --> libxfcegui4: base GUI utility/widget library.  This library
has unfortunately become a bit of a mess.  the netk-*.h files are
our private copy of libwnck (a netwm-compliant WM interaction
library, essentially), that was imported back when libwnck wasn't
stable.  Nowadays we could probably just ditch it and depend on
libwnck (or maybe just rewrite it entirely, as libwnck is pretty
slow and bloated), but... all this requires time, and what we
have works well enough.  You might skip this part of libxfcegui4
if wrapping it.

Also in libxfcegui4, we have an about dialog (yes, gtk has one
now too, but it didn't always, and ours has a different
look'n'feel), a GtkMenuItem subclass to represent an executable
app (that really only xfdesktop uses), a clock widget (that
really only the panel uses), some startup-notification-aware
app-spawning functions (very useful, IMHO), some gdk/gtk
extensions (helper functions, mainly), a scaled image widget
(eh), a system tray icon object (it's a bit crufty and gtk should
have GtkStatusIcon soon), XfceTitledDialog (gives us a unified
look'n'feel for prefs dialogs, mainly for panel plugins, but
others could find this useful as well), and some convenience
functions for HIG-compliant notification dialogs.

There are also a bunch of deprecated things in libxfcegui4 as
well: XfceFileChooser (used to be an abstraction over both
GtkFileChooser and GtkFileSelection; not needed anymore),
XfceFramebox (an indented layout widget that was implemented
poorly), XfceIconTheme (used to be a reimplementation of
GtkIconTheme for gtk versions <2.4), and a bunch of button types
that the panel used to use but aren't very useful, etc.

For the core desktop, basically everything is built on that.  We
have:

- --> xfce4-session.  This guy controls the X session and launches
the rest of the desktop.  It supports standard X11 session
management for user applications.

- --> xfwm4.  The window manager.  Pretty self-explanatory.  It has
a built-in compositor, which is cool.

- --> xfce4-panel.  Floating window, taskbar, toolbar, application
launchers, menus, status displays, system tray, pager; whatever
you can think of.  It of course has a plugin architecture; you
can find weather applets, keyboard layout switchers, mail
checkers, media player controllers, etc.

- --> xfdesktop.  Draws the desktop window, wallpaper, desktop
icons.  The file icon support is based on libthunar-vfs, and it
also supports Thunar's extension mechanism via libthunarx.

That's the base desktop right there.  On top of that, new for
4.4, we have Thunar, our file manager.  The libraries developed
for it, libthunar-vfs and libthunarx, might be useful enough to
wrap in XFC, but probably later on.

I understand that you're approaching XFC from a different
perspective: just as someone who wants to write GUI apps in C++
using gtk, not as someone who wants to write Xfce-related apps in
C++.  However, XFC *is* an Xfce project, and I believe it should
have an Xfce-related focus.  I would have trouble endorsing a new
maintainer for XFC who did not share that goal (of course, one is
free to start a new project based on XFC, with a new name, hosted
on non-Xfce resources).

	-brian

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFgx/o6XyW6VEeAnsRA6nHAJ9gx0txm6E83ho5b1BG85byYiTuPgCfT8Lz
iHhuHnfLV+FiVfK0AkuVCyw=
=Pa1L
-----END PGP SIGNATURE-----