Todo list for Xfce 4.4

[Brian J. Tarricone]

-----BEGIN PGP SIGNED MESSAGE-----
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 freedesktop.org/Standards.

> 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.

> * 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.

> * 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-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.

> 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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFCu10T6XyW6VEeAnsRAmlDAKDVW7qIZpPqFSFbSoVKGu2L0X3cyQCeLsPt
FwcoCUPsbjx3rfLyvaQqjx8=
=b77T
-----END PGP SIGNATURE-----