Todo list for Xfce 4.4

Erik Harrison erikharrison at
Fri Jun 24 04:27:21 CEST 2005

How about this

On 6/23/05, Brian J. Tarricone <bjt23 at> wrote:
> Hash: SHA1
> Jasper Huijsmans wrote:
> >
> > 1) Platform
> > ============
> > - libxfce4util
> > - libxfcegui4
> > - libxfce4mcs
> > - libexo (?)
> >
> > * rename libxfcegui4 to libxfce4gui. Hey, we have SVN now ;-) I know it
> >   doesn't buy us anything, but I find the difference annoying.
> Yeah, it annoys me too, but I think we should leave it.  Distro
> packagers will have to deal with the package name change, which can be a
> pain, especially for upgrade path cleanup.  That is, some package
> managers don't support the ability to say "hey, this package name
> changed: here's the upgrade, uninstall the one with the old name".  In
> these cases, the only way to ensure cleanup is by using a "conflicts" or
> "blocks" relationship, which often requires user intervention to resolve.
> > * check if gtk 2.4 provides things we had to provide for 2.2
> >
> >   - Can GtkIconTheme be used? Gtk 2.6 has (I believe) an icon cache that might
> >     speed up lookup and reduce memory usage.
> Yeah, I'd like to do this as well.  XfceIconTheme is just too slow.  In
> preparation for this, we should stop using XfceIconTheme directly and
> use the xfce_themed_icon_*() interface in libxfcegui4/icons.h.  We can
> add to this as necessary, and I'd like to support the
> xfce_icon_theme_category_*() interface as well; I think you use that a
> bit in the panel, and it seems pretty useful.
> There will also be some massaging necessary to ensure that GtkIconTheme
> always does the "right thing": I believe one of my early complaints with
> it was that it didn't make a very good effort to find an icon if it was
> in a legacy location, and that it didn't follow the XDG spec for the
> search path (this may have changed in 2.6).  Also, it doesn't resize
> icons, so if you request an icon of size 16, and the closest is 20, you
> get a 20x20 icon.  In just about any case I can think of, that's
> annoying and useless, and you have to take the extra step to resize it
> yourself.  (Though I can understand why the gtk devs made this choice.)
> > * should xdg menu parsing be in one of the libs? xfdesktop and xfce4-appfinder
> >   use it, maybe other components will be interested as well.
> Quite possibly, yes.  As usual, I need to go over Benny's xfdesktop-ng
> source and puzzle it all out, something I've been meaning to do for many
> months now.  Benny, can you point me to the latest source tarball, or
> CVS/SVN tree, to save me some time?
> >   - I'd be interested in seeing alternative interfaces to acces the menu, like
> >     the appfinder. For instance I think it would be awesome to have a panel
> >     plugin that shows a menubar with all toplevel categories; the simple menu
> >     layout of the system menu directly available on the panel. Perhaps with
> >     an option to show only certain categories. Hmm, I don't think I explained
> >     that very well...
> >
> >     | Accessories Graphics Office Network Development |
> Yeah, that's pretty cool (though kinda GNOMEish ^_~).  I think the real
> way to do this is provide an API that returns a GNode tree (or something
> more efficient if GNode isn't), so applications can generate whatever
> kind of widget structure they want.  I haven't really thought about
> performance implications yet, but that would be a nice thing to do.
> > * Are there relevant xdg standards that we don't support properly at the
> >   moment?
> Possibly, but I don't see "support all the standards" as a useful goal.
>  If we're not supporting a particular standard that we don't know about,
> it's probably because it doesn't fit into Xfce well.  Still, it's worth
> perusing
Having recent files support might be nice, but otherwise we're pretty
good, with Thunar adding support for various file management

I'm going to try to have a GMarkup based recent files implementation
up by the September freeze, assuming all goes well, but it never does.
And it really strikes me as more libexo than anything eles

> > 2) Desktop
> > ===========
> >
> > I split up this category further, because there are so many modules part of it
> > and there are some differences, I think. It's rather difficult to exactly
> > define these categories and the bounderies are not very sharp, though.
> >
> >
> > 2a) Basic, shared components
> > =============================
> > - xfce4-icon-theme
> > - gtk-xfce-engine-2
> > - xfce-utils (perhaps rename to xfce-common or xfce-essentials?)
> > - xfce-mcs-manager
> > - xfce-mcs-plugins
> >
> > * Are there any addional XSETTINGS we should support? XCursors comes to mind.
> IIRC, cursor settings aren't defined in XSETTINGS.  Even if it was, this
> requires toolkit support to change on the fly, and I don't think gtk
> does that yet.
> > * Is the mcs system still sufficient? The main limitation to me seems the fact
> >   that only the plugins can change the settings. The main advantage is the
> >   central location for configuration.
> Personally, I'm just not totally happy with the MCS architecture.  Only
> being able to set settings from the plugins is a pain.  I don't really
> like how the plugins have to explicitly save their settings: this should
> be done automatically any time a setting is modified.  On the other
> hand, what we have *does* work for the core desktop, with a minimum of
> icky workarounds.  As Benny says, as long as we don't use it to store
> application settings, that's fine.
> I like Benny's method of setting GObject properties as it *really* hides
> the settings mechanism from the application.  As long as GObject is
> around, the applications don't have to care what the underlying settings
> manager is or does.  I think this is probably something for 4.6, though.
> > * The .desktop files for separate settings dialogs clutter the menu. I think
> >   we should only have a desktop file for the settings manager.
> I strongly disagree.  Now that the menu entries are there for all of
> them, I almost never open the settings manager proper.  Saving a click
> here and there is nice.
We've had some users complain about not labeling our .desktop files
for settings as being Xfce specific. One guy kept trying to figure out
how to make the Window Manager configuration option in the menu open
up a config dialog for Metacity

> > * I think the startup of Xfce is still rather confusing to most users. Maybe
> >   someone could rewrite the startup scripts? Or maybe everything should be
> >   done by xfce4-session?
> I've thought about this, and about how many times problems with this
> come up on the mailing lists, but I can't think of a good solution.  If
> you have xfce4-session do all of it, you lose some customisation
> ability, and people that don't want to use the session manager are left
> to roll their own startup scripts (which may not be a problem).  There
> are a bunch of things, like setting Xft resources, that need to be done
> before any apps start, and the best place to do that is in the first
> script that runs.
> > * If we are interested in using xfce4-tips (are we?), I think it should be
> >   part of xfce-utils, or perhaps even xfce4-session? Anyway, the xfce4-toys
> >   package should go away.
> Have the tips even been kept updated?  Definitely, xfce4-toys should go
> away, and I'd recommend sticking xfce4-tips in xfce-utils (which should
> really be renamed to xfce4-utils, aside from my package-renaming tirade
> above) rather than xfce4-session.  It would be kinda cool to have
> xfce4-session have an option to display a new tip on startup (assuming
> xfce4-tips is installed).
> > 2b) Main desktop components
> > ============================
> > - xfce4-session
> > - xfwm4
> > - xfdesktop
> > - xfce4-panel (which now includes taskbar and iconbox)
> >
> > * I really think we need a graphical interface to the session manager. It
> >   should allow people to add/remove programs from the saved session and
> >   probably should have a special section for Xfce desktop components. Maybe
> >   this requires communication between xfce4-session and desktop components to
> >   find out if they are running or not. I think we could use a volunteer for
> >   this, since Benedikt will be busy with thunar, I presume.
> Yeah, I'd appreciate this too.  How to stop and start various Xfce
> components is a super-FAQ.
> > * I wonder if, for people who don't want full-scale session management, it
> >   would be possible to disable this: just have xfce4-session start a list of
> >   programs and manage logging out. And I wonder if that would speed things up
> >   a bit.
> That sounds kinda messy.  I like Benny's idea better to just start
> same-priority apps in parallel (actually, I'm kinda surprised this isn't
> already the case, but I guess that's a bit more complex).
> > * Olivier, do you have any specific plans for xfwm4 4.4?
> >
> > * I wonder if it might be nice to create a window matching utility ala
> >   devilspie, either as part of xfwm or a separate daemon. To provide
> >   functionality that was available in xfce3 (and CDE, etc). Most importantly
> >   to change icons or create borderless terminals.
> Eh.  Really, devilspie's only problem is that it has an XML config file
> format with options that aren't easy to remember, and no GUI to edit
> them.  There's no reason to reinvent the wheel.
> > * Xfdesktop. Brian?
> I really don't know.  Stuff on my TODO list:
> * Use Benny's menu system from xfdesktop-ng.
> * Desktop icon support, reusable for Thunar.
> * A bunch of random enhancements that are in Bugzilla.
> I haven't really touched new development on xfdesktop since before
> 4.2.0.  I don't want to say I'm losing interest in it, but I guess I
> kinda am.  Xfmedia and Mailwatch have been far more interesting to me
> lately.  Assuming we don't freeze 4.4 until mid-fall, I'm sure I'll get
> to at least some of this stuff, though.

Perhaps you should collaborate with Benny. Is it possible or a good
idea to make desktop handling a gmodule or similar runtime loadable
component, so that they can code share? Might also drop some tech
support issues trying to figure out whether Xffm, Thunar, or Xfdesktop
are manageing the background, if they share a codebase

> > * For the panel, see my mail about panel plans for 4.4. In summary: new plugin
> >   interface, multiple panels, support out-of-process plugins.
> Yeah, good stuff.
> > 2c) Desktop applications and utilities
> > =======================================
> > - xfcalendar
> > - xfce4-mixer
> > - xfce4-mailwatch
> > - xfprint (Could be seen as part of the platform maybe, since it's used by
> >   mousepad)
> > - xfce4-appfinder (appfinder widget should be part of libxfce4gui if the panel
> >   is going to use that. I keep forgetting to review it, sorry Eduard).
> >
> > * Any others?
> >
> > * I'll remove mailcheck from the panel; mailwatch is much better.
> Mailwatch still needs POP3 support, which shouldn't be too hard since
> the connection setup is almost identical to IMAP, and the protocol for
> getting new messages is trivial compared to IMAP.  First, though, I need
> to clean up the SSL settings for IMAP so I can use the same setup for
> POP3.  My plan was to make SSL a non-setting, so it would always just Do
> The Right Thing[tm], but that's harder to do than I thought, with the
> varying auth methods, and admins who like to foolishly drop packets
> destined for port 143 (/me looks pointedly at Auke).  See section 7 of
> RFC2595 for why the imaps and pop3s ports are stupid.  Granted, many
> IMAP/POP3 clients don't support STARTTLS/STLS, in favor of the alternate
> ports, so... blah.
> > 3) Extras
> > ==========
> > - goodies, including xfce4-eyes and xfce4-trigger-launcher
> > - xfwm4-themes
> >
> > * Do we want to move the goodies to Xfce SVN? Maybe Auke has an opinion on
> >   that as well, from the admin viewpoint?
> Yeah.  Do it, assuming the goodies maintainers don't object, and Auke
> doesn't mind setting up the https/dav accounts.
> > * When there is a new plugin interface for the panel, all modules will have to
> >   be updated. I'm prepared to do much that work (shouldn't be too hard).
> >   Suggestions for the plugin interface are very welcome.
> It should be very simple:
> void main() {
>     XfcePanelPlugin *p = foo_create_plugin();
>     xfce_panel_plugin_do_the_right_thing(p);
>     gtk_main();
> }
> ^_^
> > Hmm, did I miss anything? Maybe there are things in our development process
> > that could be improved, e.g release management, translations management,
> > website / other information sources.
> There's always room for improvement with this kinda stuff, but hard to
> do without listing specific problems and coming up with specific solutions.
> > * Like erik said, we get complaints about the number of components in Xfce.
> Frankly, I don't really care too much about these complaints.  People
> that care that much should go back to openbox or whatever.  Let's focus
> on making Xfce into what we wanted to be, not what some uninformed
> subset of users complains about.
> >   Maybe we should try and combine some of them. Here are some suggestions:
> >
> >   - xfce-libs: I don't think we have ever released one separately, so it may
> >     make sense to combine them into one package. They should still be separate
> >     libraries.
> Hmm, I'm kinda ambivalent on this.  On one hand, sure, we've never
> released them separately.  All apps that use libxfcegui4 use
> libxfce4util implicitly.  On the other hand, I see no reason to have
> libxfce4mcs in there.  Xfmedia doesn't use libxfce4mcs, and someone who
> doesn't use Xfce but wants to use Xfmedia will have to install
> libxfce4mcs for no reason.  So that leaves us with two libraries in the
> xfce-libs package, which doesn't seem like a worthy savings to me.
> >   - xfce-mcs-manager: perhaps include the plugins and have a special
> >     command-line option to disable them (to avoid conflicts). Or even a user
> >     interface to enable/disable any plugin?
> Yeah, I think xfce-mcs-plugins should be merged into xfce-mcs-manager.
> The plugins are (obviously) useless on their own, and I think there are
> probably very few people that install the manager without the plugins.
> A UI to enable/disable plugins would be nice, but not really critical.

xfce-terminal packaged it's own plugin for MCS IIRC, and we are a
highly modular system. Bundling the plugins with it seems kinda
foolish, to me. Maybe I'm wrong.

> >   - xfce-file-managers: nah, not really ;)
> Hehe ^_^.
> > * Documentation. We have some, but I'd like to see the user guide be a bit
> >   more extensive, answering more FAQ's. Have a list of things to configure
> >   after installation (Francois put something on the website, IIRC).
> Yeah, I'll say it outright: I hate writing documentation.  It's one of
> my failings, and I feel bad about it, but... well, that's how it is.

Then I'll write it. I can't meet my code promises as often, but I
think I have demonstrated at least a minimal ability to write.

There. Something decided. What do I need to cover?

> > Remember, these are just some personal ideas, nothing has been decided. The
> > person who writes the code has a strong influence on the decissions. And, none
> > of this will happen if no-one does the work...
> Wouldn't it be cool if we could just think of stuff and it would just
> happen...?
> > Wow, another long e-mail, no wonder I have no time left for coding... I do
> > hope it leads to something or helps someone.
> Yeah, seriously.  I should be doing work or something.
> > PS
> > Speaking of long-windedness, it seems I'm turning into Brian... ~_^ <-- See?
> It's contagious...
>         -brian
> Version: GnuPG v1.4.1 (MingW32)
> FwcoCUPsbjx3rfLyvaQqjx8=
> =b77T
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at

"This brings me back to a time where I had no worries. 
All I needed to do was watch Perfect Strangers."

More information about the Xfce4-dev mailing list