							2000-09-05

							Emil Brink


		Things left to do in gentoo
			(it rhymes!)

0. INTRODUCTION
This little file lists things that I have planned for future
versions of gentoo.
	Please note that gentoo is free software, developed in
my spare time, and distributed free of charge. Therefore, please
don't take the things mentioned in here as promises: I might
implement all of these, or I might implement none of them. Also,
things are likely to be added/removed from this list as time
passes by and I think things through more.
	The purpose of this list is to allow users of gentoo a
way of knowing what to expect from the program, not to generate
mail of the form "when will feature X be implemented?". Please
respect this. :)


1. IDEAS
Here are the ideas, presented in one subsection each. Enjoy!

1.1 Virtualize the File Access
I have an initial implementation of a file system abstraction
layer, which allows neaty stuff like viewing the contents of
an archive as a directory, or using gentoo to get and put files
on an FTP site. The code I've written is based on a URL-like
access scheme, where individual access-schemes (ftp, tgz etc)
cause plug-ins to be dynamically loaded to handle the access.
	Integrating such a system with gentoo is quite a big
task though, and I've been putting it off for almost a year
now... I'm also afraid that implementing virtualized file
access will slow the program down for local accesses. Further,
I think some commands might need to be rewritten, and have
some "intelligence" added that makes them avoid running on
certain access schemes (doing a GetSize on a remote FTP site
might take a while and be difficult to abort, for example).

1.2 Write a Menu Editor
The buttons used in the button bank below the panes support
individual pop-up menus; but there is currently no way of
defining and attaching menus to them. Writing a fully-fledged
menu editor is a lot of work, and I'm close to thinking of
it as duplicated effort, since a menu editor exists in e.g.
Glade already.
	Having a menu editor would allow users to attach their
own menus to every command button. Seldom used commands could
be moved from a button of their own to a related button's
menu, thus saving valuable screen real estate in the button
bank.
	The menu that is typically bound to the right mouse
button in the panes would of course be editable as well, and
the MenuPopup command would be extended to take the name of
the menu to show as an argument. The latter would allow things
like shift-RMB to pop up a different menu in the panes...

1.3 Generalize Buttons
The command buttons displayed under the panes are very general
internally, where they are represented as a specific "sheet"
of buttons. I plan to add ways to add and delete button sheets,
and also lay out the sheets in the window. The layout interface
is what's currently holding this off.

1.4 Remove the Shortcuts
The shortcuts are basically buttons that do stuff, and can
therefore be implemented as a buttonsheet. As soon as the
buttonsheet layout gets implemented, the exceptional treatment
of shortcuts will be gone.
	I'm secretly considering doing this even before it
becomes possible to handle buttonsheets generally, since it
would make things nicer (at least internally).

1.5 Redesign Selection (internal)
The selection handling is way to complicated, and probably hides
a bug or two. Part of the problem is an ambivalence about where
the selection should be handled; in GTK+ or in gentoo's own data
structures. The former is prefered (in contrast to earlier versions
of gentoo, which did it the latter way). This is complicated by
the focusing system, however, especially the flag "Treat Focused
Row As Selection...?".
	What would be nice is either to a) find out how to use
the GtkCList's focusing system from outside the widget; or b) to
design a whole new selection layer, which moves the selection
state from the GtkCList of a pane, to a private struct, and then
back again when needed. Oh, that's the DirHistory thing... Ouch.
I sense a problem already solved... Hm. That might require some
looking into. Later.
