Todo list for Xfce 4.4

[Jasper Huijsmans]

On Thu, Jun 23, 2005 at 06:08:35PM -0700, Brian J. Tarricone wrote:
...
> > 
> > * 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.
> 

Hmm, yeah, you are right. Too bad.

...

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

GNOMEish, maybe, but with an Xfce touch of non-hierarchical (?) menus ;-)

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

Yeah, that's what I meant, although it was kind-of hidden in my use of 
'relevant' ;-) 


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

Hmm, I thought it might be, dunno why.

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

Ok ;-)

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

It still feels we use too many scripts to achieve this. Maybe there is no
solution.

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

No, they haven't been kept up to date, and Benny said something about a
first usewelcome screen for xfce4-session, so maybe it should just go away.

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

Ok, I admit I know nothing of devilspie ;-)

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

...
> > * 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();
> }
> 
> ^_^
> 

You're not wrong ;-) I found I already made a bit of a prototype some weeks
ago, which does most of the work for the plugin; it uses pipes for
communication, but I'm thinking of using Xmessages to a special IPC window (we
have one already for the XFCE4_PANEL manager selection). Or DBus if it is
ready, but I don't think it will be.

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

Ok ;-)

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

Yeah, they are also still well-separated (non-gui, gui, settings) although
with the addition of libexo -- if we decide to do that -- that would change a
bit, but it's not like we have 100 libraries or something.

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

Doesn't sound too hard to make though.

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

I would love to see our docs be of the same standard as Jeff has done for XFC, 
but that might be too much for us...

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

Well, if think about that for a moment... no, that would really suck ;-) I
don't want to imagine the amount of bad ideas that this would let loose on
the world ;-)

	Jasper