[Xfc-dev] Xcfe4 wrapping features ?

[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