Xcfe4 wrapping features ?

[Bo Lorentsen]

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 :

1. MCS setting access (cool thing, are there at standard for setting layout)
2. libexo (is it mature and do we need more ?)
3. FileDialog (will this have Thunar relation/bindings)
4. xfprint system (Does this work if GTK+ gets its own printing service ?)
5. Panel extension
6. Thunar extension

Is this about it (this really is a nice chunk of work :-)) ?

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 ?

/BL
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Erik Harrison]

On 12/14/06, Bo Lorentsen <bl@...> 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 :
>
> 1. MCS setting access (cool thing, are there at standard for setting layout)

MCS fills a nice niche, but the system is a little byzantine. Probably
the whole MCS system will be replaced during 4.6 development. I
wouldn't worry about it during this point, and wait for it's
replacement to arrive.

> 2. libexo (is it mature and do we need more ?)
> 3. FileDialog (will this have Thunar relation/bindings)

If you mean XfceFileChooser, this is part of libxfcegui4, and is/will
be deprecated for the GtkFileChooser. It is a product of Xfce trying
to support older versions of Gtk+

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

xfprint is really just a utility for pretty printing various kinds of
files. It's not something you should worry about.

> 5. Panel extension
> 6. Thunar extension

>From a language bindings point of view, you can take a look at what
the Perl and Python bindings support. Here is an overview of the
various libraries, from the point of view of someone writing language
bindings.

libxfce4util provides various stuff, such as a config file parser.
libxfcegui4 has some handy widgets
The panel library permits you to write panel plugins

These three (the panel, libgui and libutil) would be a nice binding of
the "core" desktop APIs. That's where I would start if you were going
to do C++ bindings for Xfce.

Beyond that there is:
libexo: a higher level library for building user applications, as
opposed to libgui and libutil which are really targeted at providing
an API for the core desktop.
thunarx: the system for extending Thunar itself.
Thunar-vfs - the VFS that Thunar and xfdesktop use. Potentially useful
to those writing applications that want a nice rich set of filesystem
operations.

And I would consider, if you were going to write C++ bindings for
things beyond the "core" three, that I would go in this order. exo
first, thunarx second, thunar-vfs third.

>
> Is this about it (this really is a nice chunk of work :-)) ?
>
> 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 ?
>
> /BL
> _______________________________________________
> Xfc-dev mailing list
> Xfc-dev@...
> http://foo-projects.org/mailman/listinfo/xfc-dev
>

--
Erik

<@kazin> why does php have 'echo' and 'print'?  Do they do different things?
<Bluefoxicy> kazin:  echo prints in a big empty room
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[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-----
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Bo Lorentsen]

Erik Harrison wrote:

> MCS fills a nice niche, but the system is a little byzantine. Probably
> the whole MCS system will be replaced during 4.6 development. I
> wouldn't worry about it during this point, and wait for it's
> replacement to arrive.
Ok, so I forget that binding totally ...

> If you mean XfceFileChooser, this is part of libxfcegui4, and is/will
> be deprecated for the GtkFileChooser. It is a product of Xfce trying
> to support older versions of Gtk+
Nice, I keep learning :-)

> xfprint is really just a utility for pretty printing various kinds of
> files. It's not something you should worry about.
And GTK+ has its own, so no reason to worry about this either.

>>From a language bindings point of view, you can take a look at what
> the Perl and Python bindings support. Here is an overview of the
> various libraries, from the point of view of someone writing language
> bindings.
Good point, I may just do that, these (python) could tell me something
about the structure too.

> libxfce4util provides various stuff, such as a config file parser.
> libxfcegui4 has some handy widgets
> The panel library permits you to write panel plugins

> These three (the panel, libgui and libutil) would be a nice binding of
> the "core" desktop APIs. That's where I would start if you were going
> to do C++ bindings for Xfce.
And, except for the deprecated stuff this should be the core part of the
new Xfce C++ binding ?

> And I would consider, if you were going to write C++ bindings for
> things beyond the "core" three, that I would go in this order. exo
> first, thunarx second, thunar-vfs third.
This is because the exo are more general and useful, and thunar things
are more specific to a few selected developers :-)

/BL
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Bo Lorentsen]

Brian J. Tarricone wrote:

> Unfortunately, your order of importance is a bit off.
Well that is OK, I wrote it just to get some feedback ... and I succeed :-)

> 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.
Check, no MCS (strange name btw).

> libexo is certainly useful from an app-builder's perpsective,
> though I wouldn't put it at #2.
Its number 3 in the next plan

> 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.
Ok, I will be more careful next time :-)

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

> I'd rate this up higher.
Ok, set as number 2 in the next plan

> 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.
Ok, makes sense ..

> 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.
Ok, sorry about that, I guess that libexo looked pretty basic to me, but
I was "a bit off" here ... too :-)

> 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:
Thanks, it was helpful, I really need an overview for developers ...
maybe you should på this text onto your wiki page ?

> - --> xfce4-session.  This guy controls the X session and launches
> the rest of the desktop.  It supports standard X11 session
> management for user applications.
How much application control, are expected here ?

> - --> 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.
I would be cool to be able to make new panel plugins with a minimum
effort in XFC.

> 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.
Ok, so thunar API is not stable yet, at least not stable enough for C++
bindings.

> 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++.
Yes that was my original focus, and I still like my apps to be able to
run on as many window managers as possible, but I also like the small
and fast goal of Xfce.

> 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).
Hmm, right now XFC is a pure GTK+ C++ wrapper, and I have been trying to
find the missing parts in XFC to be a more active part of Xfce. I think
that is a Xfce related focus, what else do you have in mind.

But, I admit my primary focus is XFC as a GTK+ C++ wrapper, but I am
sure that Xfce and XFC both will be best off sticking together :-)

Thank for the useful overview !

/BL
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev

[Bo Lorentsen]

Bo Lorentsen wrote:

> 1. MCS setting access (cool thing, are there at standard for setting layout)
> 2. libexo (is it mature and do we need more ?)
> 3. FileDialog (will this have Thunar relation/bindings)
> 4. xfprint system (Does this work if GTK+ gets its own printing service ?)
> 5. Panel extension
> 6. Thunar extension
Ok, so the new wrapper plan could be :

1. libxfce4util, libxfcegui4
2. panel extension
3. libexo
4. thunar-vfs and thunar

I need to read a bit more code, and to start using XFC too.

/BL
_______________________________________________
Xfc-dev mailing list
Xfc-dev@...
http://foo-projects.org/mailman/listinfo/xfc-dev