Am Montag, den 24.03.2008, 13:08 +0000 schrieb Don Scorgie: > If this were to be proposed for GNOME inclusion (a goal?)
This would be really awesome. BTW do you have any information about
GNOMEs Google SoC plans to enforce development of a mind mapping tool?
> 2. Accessibility. Labyrinth sucks at a11y. I mean, really sucks.
> There is none. In order to be part of GNOME, there'd have to be some
> form of a11y. Whether this is making thoughts visible, or a special
> view, I don't know. More on this later.
> 3. Theming. We currently don't follow the gtk theme for anything. The
> problem is that theming in gtk sucks (from experience). This would
> require some thinking about.
I looked into Gtk theming. I don't really know what needs to be themed
anyway. One thing that needs to be themed is the bounding box selection,
but otherwise I don't see that much parts.
> 4. User manual. Should be relatively straight forward do do a simple
> user manual.
When trying to become a GNOME project, we should follow the paths of all
projects and use DocBook XML which is even for a simple manual quite a
lot of work.
> 7. An applet, like the wonderful tomboy.
This is one of the most interesting and promising feature proposals in
the list. Really, when I saw that, I instantly said to myself "that's a
must-have".
> * Exporting XML. [...]
> For this reason, I came up with a second possibility. If we had an
> option for maps with images in the export dialog "export with images",
> we could basically create a tarball / zip file with the images included
> with the XML (modified to point to the current path). In the import,
> this tarball would be expanded and the images put into a folder
> ("~/.gnome2/labyrinth/images" or whatever), and the path fixed in the
> image thoughts.
This is a great idea (looks like .odf). For simplification reasons we
could always zip/tar exported maps, it doesn't matter for the user if
there are images or not.
> * Speed. I know Matthias has implemented some speedups, but there are
> more available. The biggest problem is when moving the canvas around,
> as all thoughts visible must be redrawn every movement. Maybe we could
> get around this be keeping a cache of the current view and blatting [1]
> that at the correct offset and only redrawing everything once movement
> has stopped.
Hmm, this means all elements need to be drawn off-screen but is
obviously the best solution for scrolling. BTW, is there any reason why
scroll buttons instead of scroll bars are used? I think users are much
more faster dragging a scrollbar to a specific point because of the
visual feedback and reference.
--
Matthias Vogelgesang
Public-Key: http://tinyurl.com/2qcydl
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
