Difference between revisions of "GtkMMification"

From Inkscape Wiki
Jump to navigation Jump to search
(Replaced content with "{{Deleted}}")
Tags: Replaced Visual edit
 
(38 intermediate revisions by 11 users not shown)
Line 1: Line 1:
Gtk+ and GtkMM interact cleanly.  This task is to replace individual widgets and dialogs with their GtkMM ports so as to reduce the code size and make code reading easier.
{{Deleted}}
 
We won't be using Glade, but we may consider other GtkMM-based derived widgetsets, such as the ones used for the new [[The_Gimp]] interface.
 
There are several reasons for not using Glade.  First, it imposes an extra dependency, that has proven problematic in the past.  Second, while it allows for layout of custom widgets, it isn't really designed for that purpose; Inkscape will have its fair share of custom widgets.  Third, it is not felt to be suitable to dynamically laid-out dialogs; we wish to make the new dialogs be responsive to changes in the Action system, so will wish to make the dialogs very dynamic.  Fourth, we will need to be able to specify UI changes triggered by user actions, which glade does not provide.
 
That said, use of Glade is encouraged for prototyping and for module/extension interfaces.  But for core UI, any Glade-generated code will need to be coded up properly using clean Gtkmm.
 
== Things discovered whilst porting from Gtk+ to GtkMM ==
 
*you can get the underlying Gtk+ pointer using the <code>gobj()</code> member.
 
== Theming ==
As part of doing the migration to gtkmm you should try and get icon theming working properly. While not directly related to the port I think fixing it when redoing the GUI anyway is a good time. There are a couple of things to keep in mind. For icon shared by Inkscape with all GTK+ and GNOME apps (file new, file open) etc. you should just use the standard icons. Look at gedit for sample code of how it is done. For icons that Inkscape shares with other drawing apps like [[The_Gimp]] you should adopt the stock icons defined by [[The_Gimp]] (floodfill is a good example here).
 
For the remaining icons you would need to define them yourself, good thing here would be to make sure Sodipodi could use the same stock icons definitions so that when someone icon themes Sodipodi or Inkscape both apps picks up the correct icons.
-- Uraeus
 
== Implementation ==
 
Do not include the generic <gtkmm.h> header, as that includes all gtkmm headers (about a megabyte or so).
Instead include the specific headers needed.
 
[ n.b. if pch is used, including all the gtkmm headers would not impact things so badly. ]
 
An easy first-step in converting existing code to Gtkmm would be to replace existing character strings with
Glib::ustring, which has a similar interface to std::string but supports UTF-8.  Watch out for pointer arithmetic
or functions like strlen().
 
We will need to create a menubar from Gtk::MenuBar.  Ideally, this should be dynamically built based on
registered verbs in the system, as modified by appropriate user preferences.
 
The XML Editor will require refactoring to make use of the TreeView widget.
 
Change the text properties editor to use TextView.  Can we get more powerful text editing than is normally
available?  E.g., search-and-replace, spellcheck, etc.
 
The right-click Popup Menu needs to be redeveloped to also tie into the Action system, such that the
contents of this menu change dynamically based on what the mouse is hovering over - for text, it should
provide text-modification actions, whereas over a node in a path it should show node-editing capabilities.
 
Toolbars will need to be built from the Action tree, as modified by the user preference settings. 
There are four principle toolbars:  The master, auxillary, extension, and custom toolbars.  By default
these are positioned on the left, top, bottom, and right sides of the canvas, respectively.  The master
toolbar is a set of radio buttons corresponding to different aux toolbars; changing the selected radio button
changes which aux toolbar is shown.  The extension toolbar is used to show third-party tools.  The
custom toolbar is left to be defined by the user.
 
Inkscape will require an easy way to get to a variety of dialog pages for setting properties, selecting
options, etc. etc.  In release 0.35 this was handled via a plethora of popup dialogs, however this is not
felt to be an adequate solution.  In the new [[The_Gimp]] 2.0 look and feel, access to properties are through a
combined dialog, where each page of the dialog is accessed via tabbed pages. This is what is being discussed and planned on PreferencesDialog. Other approaches should
be researched and evaluated.
 
The standard Gtk font and color dialogs won't be suited to our needs; we'll need to fold in similar capabilities
into the combined dialog mentioned above.  Additional research into what is needed for Pango support will
need to be done.
 
The default Gtkmm FileSelection dialog is not good enough.  Sodipodi had experimented with the KDE file
dialog and a number of users enjoyed its much improved capabilities.  We need something better than the
default.  It is said that there are alternate options we could consider, or could wait until the next major
release of Gtk+, in hopes that the new lib will provide a new dialog.  This needs to be researched.
 
Drag and Drop will need further investigation.  Widgets can be specified as sources or destinations for
drag and drop actions.  It should be possible to drag text from the canvas, other widgets, or external
sources into any text entry areas.  Dragging of SVG objects off of the canvas into a style editing widget
or panel should cause it to adopt the style settings of the dragged object.
 
Every widget should have a unique, patternized name and take signals in order to operate it.  This is to allow
scripting such as for automated testing purposes.  It should be possible to programmatically drive Inkscape
through invoking signals externally, which should result in testable transforms of the document.  We can
keep a library of these invocation scripts and use them for regression testing.
 
All copy, cut, and paste actions must be tied in with the clipboard system.  These actions should cause the
selected objects to be rendered down to SVG and put into the clipboard.  We'll need to consider whether to
copy as plain SVG, or to include namespaced custom styles such as has been used by Sodipodi.  This also
needs to be tied into the import/export capabilities so that rendering to/from binary formats such as png can
work correctly.
 
Autosave can be implemented during idle or timeout periods.
 
Dialog windows that aren't shown at startup should be built-up after program initialization during idle times
or timeout events.  Action button images that are not shown initially should also be rendered for display
during idle times, after the program has initiated.  The goal is to get the app to the point that it can accept
editing commands as rapidly as possible by putting off program initialization work.
 
We'll need to create a set of our own signals.  This can replace situations where pointers are being
passed around from object to object.  Normal SigC::Signals objects can be used for this.
 
=== Internationalization ===
 
This will muchly work in the same manner as it has in the codebase, using the english versions of text in
gettext() function calls via the _() macro.  The xgettext script extracts the strings into the inkscape.pot
file.  Translators copy this file to languagename.po and edit to suit.  The msmerge script updates the .po
files from the regenerated .pot file.
 
Info on getting the gnome-i18n project to help with translations can be found here:
http://www.gtkmm.org/gtkmm2/docs/tutorial/html/ch20s04.html

Latest revision as of 15:11, 13 March 2023

This page has been deleted

This page is kept for historical reasons, e.g. to document specific decisions in Inkscape development.

Retrieved from "https://wiki.inkscape.org/wiki/index.php?title=GtkMMification&oldid=122245"