[Thunar-dev] next step in thunar development

[Benedikt Meurer]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thunar.xmi
Type: text/x-xmi
Size: 652851 bytes
Desc: not available
URL: <http://mail.xfce.org/pipermail/thunar-dev/attachments/20050602/845d67a2/attachment.bin>