Dia goes Gtk2, anyone else with it ?



Hi all,
below you'll find some kind of 'plan' what more or less
needs to be done to make Dia a first class Gtk2 citizen.

The first step just landed in cvs. [Beware: it will _not_
build as is on Linux and other *nix cause the auto/configure 
stuff needs some love first.]

Further steps could easily be shared between intersted 
developers. But IMHO some coordination is needed to avoid 
duplicated effort.

The list below is meant to be a starting point for this.
So if you always wanted to get your hands dirty with
hacking on Dia, take one ...

For the curious who not yet know about the benefits of
Gtk2 here are some of it :

- Gtk2 talks utf8 - Dia does it - no conversion needed anymore
- Gtk2 has a much more appealing visual appearence
- Gtk2 uses Pango for font handling which should highly simplify 
  support for different languages, even in one diagram
- Gtk2 has learnded many of the nice things formerly only
  available in gnome libs (menus and buttons with icons, etc)
- Gtk2 has a stable api across all supported platforms, so more bugs 
  would occur and can be fixed on any platform
. ...

Anyway here's the list. Some more thoughts and details can be found
at http://hans.breuer.org/dia/dia-todo.htm

My GTK2 fixmes are FIXME? or GTKBUG?

app/interface.c:123 /*static*/
app/interface.c:839 static void fill_sheet_menu
app/render_libart.c probably broken on X11
app/sheet.c:207 move message_notice out of loop
app/ps_utf8.c : not yet build on win32
app/render_eps.c : some further utf8 cleaning needed

The current plan is:
- merge all Gtk2 specific changes done on TARGET_GTK2_0 into HEAD.
  (it would be much simpler if I haven't tried to keep both trunks
   in sync, see the other ChangeLog.)
- merge in utf8-ness (my branch apperas to be almost clean)
- do one large commit, which allows to build with GTK2
  (some of Akira's changes probably will vanish by this, at least
   the reformatting which IMHO should never had happen [Dia's tab
   size is 8 not 2!] and some of the XIM stuff which I neither can 
   test nor does it seem to be not applicable with GTK2)

- add a file 'todo.gtk2' which is an extract from the todo.hb
  with some additional steps to be taken. Post it to the 
  mailing list.

---> You are here <---

[the following tasks could easy be shared]
- let someone else do the auto-break stuff
  - no more: libunicode, separte gdk-pixbuf, charconv.[hc], HAVE_DIRENT
  - require: gtk2, libxml2

- convert Renderer interface to GObject
  - change init_*_*ops() to *_class_init, virtual function support 
    (should be done by/with the help of GObject)
  - lib/render.c includes most of the base DiaRenderer
    plug-ins/renderer.inc has code to approximate ellipse by arcs
    app/renderer_gdk.c : has a bezier by line approximation
  - try to involve original plug-in authors (to at least 
    take a look if something got broken during the transition)

- make PlugInInfo opaque again in the good tradition of information 
  hiding and clean-up some other global vars which where intoduced 
  by the shape editor patch
  - try to move object_types_detect_nosheet() etc out of object.h ...
  - (see fixmes above)

- split out HAVE_FREETYPE stuff in own files *_ft2.c to keep 
  the know-how for later possible reintegration

- remove the font name trough gettext hack

- do basic GdkFont -> Pango conversion

- remove the scrolling menu hack (Gtk2 does handle such)

- make it compile without GTK_ENABLE_BROKEN

- make it compile with GTK_DISABLE_DEPRECATED
  - maybe split in parts by un-defining it in single files,
    which need more work (diagram_tree.c, ...)

- simplify render_pixmap.c : by inheritance from DiaGdkRenderer 

- fix Arrow widget to properly scale and make thicker lines
  again (they IMHO looked much prettier)

- remove LIBXML1 #hell

- remove as much as obvious not needed anymore GNOME #hell

- do some gui tweaking to try to conform to new HIG (at 
  least button ordering)
  - try to involve the Gnome Useability Group
  - maybe add hooks for online help, cause any widget
    probably needs to be touched anyway

- try again to get a 'complete' hotkey/accelerator
  specification

- common default object properties load/save implementation 
  to be merged 
  - remove all object implementation specifc 

- make a plan about further GObject-ification
  Some thoughts on this at http://hans.breuer.org/dia/dia-todo.htm

Future:

- Make printing backends runtime configurable plug-in

- ...
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]