[Thunar-dev] next step in thunar development

[Benedikt Meurer]

[Sorry if this gets to the list twice. I didn't notice that the 
attachment was that large, it's now available at 
http://xfce.org/~benny/tmp/thunar-20050602.xmi.bz2]

Oki doki, let's see. First of all, attached to this mail is short
summary (generated with umbrello, but since it's XMI, other UML tools
should (in theory) be able to read it as well) of what I have worked out
so far, which presents the important parts from my point of view.


The steps for the next weeks:
=============================

     A list of open tasks. So if you plan to contribute to Thunar, pick
up your favourite below. As some tasks cannot (or should not) be
performed by a single person, it would be nice if we are able to
separate the project into some teams, that work on a specific task.


1. Trash system
---------------
     This is one area that is mostly unclear at the moment. I haven't
spend much thought on this yet. There are currently ThunarTrashedFile
and ThunarTrashFolder, where ThunarTrashedFile extends ThunarFile with
the ability to display the realname of the trashed file instead of the
file name. ThunarTrashFolder will be tricky. If somebody feels like this
is an area of interested, read the Trash spec several times, check
Nautilus/Konqueror and try to come up with the basic requirements (from
the VFS side) for the ThunarTrashFolder. Depending on the requirements
and the interface that can be provided, there may also be a need to add
a ThunarTrashModel class as specialization of the ThunarListModel. The
result of this task should be a description (diagrams if necessary),
whats necessary and what can be done, which will then be discussed, and
afterwards implemented. Also some sample code would be good.


2. Preferences
--------------
     Somebody needs to figure out a good set of preferences that will be
presented to the user in order to customize Thunar. There'll most
probably some hidden prefs, that cannot (and should not) be set from the
preferences dialog. The set should be small and effective. In addition,
sane defaults for ALL settings (not only the user-visible) should be
worked out. The best way to get to this is probably to check other file
managers first, collect good and bad examples, talk to possible users or
users of other file managers and talk to the people that
design/implement the Thunar components about what can be made an option
for which price. Once the preferences are collected, the next step is to
figure out, which preferences should be set per-window and which
preferences should be global (and thereby apply to all windows).
There'll be some preferences, that are both global and per-window, like
the view mode (active view mode per-window, default view mode globally),
these setting have to be isolated. The last step (tho this should always
be kept in mind with the former work as well) is to work out a mockup
for the preferences dialog, which can then be integrated into the file
manager. In addition, this task will hopefully also produce some
information about how and why certain settings are hardcoded. Many
people can work on this task in parallel.


3. TreePane
-----------
     This task requires mostly programming work, implementing the
ThunarTreePane and ThunarTreeView classes based on the functionality
provided by ThunarFolder and ThunarFile. The ThunarTreePane class must
implement the ThunarSidePane class/interface, which is not yet defined.


4. Removable devices
--------------------
     We need a portable abstraction for removable devices. This involves
looking at various systems that should be supported by Thunar (at
minimum, these are FreeBSD, NetBSD, Solaris and Linux). The abstraction
must be transparent and should handle atleast mounting, unmounting and
ejecting removable devices (mounting/unmounting harddisks do not need to
be supported, as thats not a common task and people doing that will know
how to do it from the CLI). Unportable technologies such as HAL should
have the lowest priority, and can be added as a gimmick later, once
everything else works.


5. MIME actions/applications
----------------------------
     Analyze requirements for the MIME actions/applications support and
work out a way to integrate this into the user interfaces. Check other
file managers first (for example, the BeOS Tracker provides a nice
interfaces). Once the requirements are clear, we'll work on an interface
to the MIME actions system and implement it.


6. Quality assurance/Testing
----------------------------
     We need a way/framework for quality assurance and testing. This
involves creating a test plan and probably also creating a suite for
unit testing of individual modules. Quality assurance also includes
verifying that the final application meets the initial goals (from the
user's point of view).


7. Feedback management
----------------------
     We need a way to manage user feedback and feature requests, probably
a simple web frontend and a special mailinglist. Some people should be
watching this mailinglist and forward those requests to the bugzilla or
the thunar-dev mailinglist, adjusting the priority as appropriate. It's
better to keep feature requests separate from developers/programmers
first, to aid in keeping the focus on the important stuff.


8. Accessiblity
---------------
     This is less of a separate task rather than a general rule: Whoever
writes GUI components for Thunar has to make sure that all parts of the
application are accessible using ATK. It would also be good if somebody
would volunteer for testing the accessibility of Thunar and making
suggestions for improvements.


9. Website
----------
     This is less important, but at one time, we'll need a website. Maybe
somebody can do it or atleast help Francois. An active website with some
background information, etc. would be nice. Maybe even a forum would
help to keep the most trivial questions and requests away from the
thunar-dev mailinglist (don't get me wrong, I'm not against users, but
users asking questions on thunar-dev can lead to confusion on both sides).


10. Usability review
--------------------
     IIRC, quite a lot of user interface designers have expressed their
interest in Thunar. It would be good if they could start a usability
team, that reviews the usability during the development from time to
time, and works on new suggestions or improvements for the user
interface. The discussion should be kept precise and on-topic. While I
see that this is a difficult topic, where everybody has his very own
opinion, it doesn't help if threads become too long and in the end
there's no result at all.



This list is not complete, but it includes the important points from my
point of view. I'll probably post more tasks in the future, once I have
a better view about how the core will look like exactly.


As said earlier, I also setup a list of limitations for the work on
Thunar, which are:

   * No hack-and-check (that is, think carefully of what you want to do,
don't just fire up your favourite editor and start hacking in the hope
that it will evolve into something useful one day).
   * Maintainability goes over performance (if you have to choose between
a maintainable and a fast solution, always prefer the former, as it's
quite easy to optimize well-designed modules, but very hard and costly
to make spaghetti-code readable).
   * Strict coding style (Glib/Gtk+ coding style with expanded tabs).
   * Write ChangeLog entries (whenever you commit a change or new stuff,
write a good entry per change to the ChangeLog file, see the libexo
ChangeLog for the exact format; it's very important to be descriptive
and correct here, else you'll loose your commit bits).
   * Use GObject whenever possible (OO makes it easier to separate
functionality and also aids in verification and testing, and GObject
provides a very solid base).

This is more a set of simple rules, but I call it "limitations", because
I know that some people will think/complain that they are too
restrictive. Anyways, that's the deal, and more or less the only way to
ensure that fun will remain with Thunar.

greets,
Benedikt