Dia goes Gtk2, anyone else with it ?
- From: Hans Breuer <hans breuer org>
- To: dia-list gnome org
- Subject: Dia goes Gtk2, anyone else with it ?
- Date: Sat, 08 Jun 2002 12:52:42 +0200
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]