+2002-04-20 Matthias Clasen <maclas@gmx.de>
+
+ * TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
+ docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
+ gdk/TODO: Remove some files whose content is either obsolete or
+ has been moved elsewhere.
+
+ * Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
+ to these files.
+
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
+2002-04-20 Matthias Clasen <maclas@gmx.de>
+
+ * TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
+ docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
+ gdk/TODO: Remove some files whose content is either obsolete or
+ has been moved elsewhere.
+
+ * Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
+ to these files.
+
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
+2002-04-20 Matthias Clasen <maclas@gmx.de>
+
+ * TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
+ docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
+ gdk/TODO: Remove some files whose content is either obsolete or
+ has been moved elsewhere.
+
+ * Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
+ to these files.
+
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
+2002-04-20 Matthias Clasen <maclas@gmx.de>
+
+ * TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
+ docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
+ gdk/TODO: Remove some files whose content is either obsolete or
+ has been moved elsewhere.
+
+ * Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
+ to these files.
+
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
+2002-04-20 Matthias Clasen <maclas@gmx.de>
+
+ * TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
+ docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
+ gdk/TODO: Remove some files whose content is either obsolete or
+ has been moved elsewhere.
+
+ * Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
+ to these files.
+
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
+2002-04-20 Matthias Clasen <maclas@gmx.de>
+
+ * TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
+ docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
+ gdk/TODO: Remove some files whose content is either obsolete or
+ has been moved elsewhere.
+
+ * Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
+ to these files.
+
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
ChangeLog.pre-1-2 \
README.cvs-commits \
README.win32 \
- README.nanox \
config.h.win32 \
gtk-zip.sh \
sanitize-la.sh \
+++ /dev/null
-Gtk port to nano-X
-
-STATUS
-
-Once upon a time I got a few apps working, then started merging
-the new features added by Owen (32 bit sizes for windows and buffering).
-Since then I haven't found the time to work on it:-/
-
-
-TODO
-
-Finish internal window manager abstraction or add proper support in nano-X.
-Fix event polling.
-Implement GdkImage, GdkRgb stuff.
-Put generic region code in generic gdk and/or use the region code from nano-X.
-Fix ugly automake stuff for make dist.
-
-TODO in nano-X
-
-We need to be able to clip and change the background of windows at runtime
-for apps to not look so ugly!
-Fonts: wait for better nano-X font implementation.
-Properties on windows.
-Provide a pango module.
-
-If you want to work on this port or get additional informnation, get in
-touch with me.
-Configure gtk with the --with-gdktarget=nanox to compile with nano-X support.
-
-Paolo Molaro
-lupus@linuxcare.com
-
+++ /dev/null
-
-Outstanding items:
-
- * focus handling for GtkOptionMenu (needs the previous)
-
- * implement gtk_default_draw_oval and other missing things in gtkstyle.c.
-
- * enforce invariants on *_RESIZE* and *_REDRAW* flags.
-
- * GtkToolTips: allocate GtkTooltipsData from memchunks
-
- * Make all widget attributes configurable after the widget is created (timj).
-
- * Radio buttons need to display CAN/HAS_DEFAULT correctly, if draw_inidicator
- is TRUE. (Radio buttons do not need to CAN_DEFAULT! OWT)
-
- * More dialogs: Print, maybe others...
-
- * make the gtk_main callbacks consistent in their add/remove behaviour.
-
- * Check return values on all calls to XIC[Get/Set]Values
-
- * The "--geometry" option should be supported
-
- - Having gdk_init() parse the geometry option. (putting it into
- GDK means you can use XParseGeometry() without wrapping it)
-
- - Add a call gdk_get_geometry() that retrieves the results
- in a form like that returned by XParseGeometry()
-
- - The application then can modify the results (as would gemvt)
- then call a routine gtk_window_set_geometry() on whatever
- it considers to be its main window.
-
- - Then in some manner GtkWindow takes that into account when
- setting its hints. (Probably it uses the size and position
- as the current uposition and usize, and modulates that
- be the equivalents of the X flags
-
- XValue, YValue, WidthValue, HeightValue, XNegative, or YNegative
-
- ( You'd have to extend gdk_window_set_hints to accept the
- window gravity option to get it right. )
-
- * Allow moving the separator for paned widgets by dragging
- it directly instead of using the handle.
-
- * Check into XAddConnectionWatch - is this needed for XIM?
-
- * Places where a _full variant is needed:
-
- gtk_init_add
- gtk_menu_popup
- gtk_toolbar_prepend_element
- gtk_toolbar_insert_element
-
- * Try to rationally deal with someone else deleting one of our
- windows??? This would mean keeping track of our window heirarchy
- ourselves, for one thing, and will never be safe, because of
- race conditions.
-
- * Should all the default handlers really return FALSE? This can
- cause confusing presses to be sent to containers that actually
- want to get events on themselves.
-
- * The menu code should skip separators during keyboard navigation,
- whether they are sensitive or insensitive.
-
- * OwnerButtonPressGrab needs to go!
-
-Text/Edit widget:
-
- Bugs:
-
- - Really big font (150 pt), plus lots of editing caused segfault
-
- Improvements:
-
- - Unify the key binding support in some fashion between the
- Entry and Text widget widgets, use GtkBindings for this.
-
- - Figure out a way not to recompute the geometry on insertions/deletions
- which are large, but not a significant fraction of the
- entire text. (e.g., compute the changes as when the widget
- is not frozen, but without the actual scrolling)
-
- - Prune the line start cache. But since it is only 68 bytes
- per line, and it is a lot faster when lines are in the cache,
- it may be better not to, at least for now.
-
- - Show the non-editable state by changing colors. (Use the
- style entries for insensitive?)
-
- - Multibyte support for the Text widget.
-
- - Unicode support to do the multi-byte right.
-
- - Support an .inputrc. (The readline one doesn't really work,
- unless it is extended because it can't represent X keysyms,
- just terminal type input)
-
- - A vi mode
-
- - Word wrap, instead of line folding. (Should the continuation
- characters be shown?)
-
- - Horizontal scrolling
-
- - Disable pasting compound text
-
- - When showing background pixmap (not editable) actually set
- the background pixmap as the windows bg pixmap, to improve
- appearance on exposes. But this would require using another
- window to get the origins.
-
- - In word wrap mode, break:
-
- aaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
-
- as:
- | Maximum column
- aaaaaaaaaaa bbbbbbbbbbb|
- bbbbbbbbbbbbbbbbbbbbbbb|
- bbbbbbbbb |
-
- Instead of:
- |
- aaaaaaaaaaa |
- bbbbbbbbbbbbbbbbbbbbbbb|
- bbbbbbbbbbbbbbbbbbbb |
-
- - Blinking cursor
-
- - API's : gtk_text_clear, gtk_text_delete_lines (gint start, gint end),
- gtk_text_append/prepend, gtk_text_insert_at (gint row, gint column),
- some function to get the row/column from the x/y-coordinates of a
- mouse click, some function to get the word/line under the mouse pointer
- [ From: Stefan Jeske <jeske@braunschweig.netsurf.de> ]
-
- - "changed" emitted when doing deletes on empty Text widget.
-
- - Delete IC in editable->unrealize, not editable->finalize?
-
-Themes
-======
-
- - When a scale gets shown/hidden only queue a redraw on the
- non-window portion, not the whole area.
-
- - In various places, to avoid shaping windows excessively,
- we set parent relative backgrounds. This is an ugly
- hack and needs a better solution. Plus, I don't think
- these parent-relative backgrounds always persist to
- when they are actually needed.
-
- Such calls exist in: GtkButton, GtkHandeBox, GtkItem,
- GtkListItem, GtkMenu, GtkMenuItem, GtkMisc,
- GtkNoteBook, GtkOptionMenu, GtkPaned, GtkPreview,
- GtkSpinButton and GtkTreeItem.
-
- - For menus and for GtkWindow's, the realize() function
- calls paint(), so that background pixmaps can be set
- ahead of time, and prevent flashing when the window is
- shown. This is an ugly hack and needs a better solution.
-
-=======
-
-Calendar Widget:
-
- - The widget should be nicely resizeable vertical too.
-
- - CALENDAR_MARGIN should be removed, uses INNER_BORDER and
- style->class->[xy]thickness insted.
-
- - Flag to choose between using standard three letter abbreviated
- weekday name or just the first character from it. It looks like
- that is what most other calendar-widgets do.
-
- - Arrows should resize with the header-font.
-
- - The keyboard support has to be finished.
-
-DND
-===
-
- - Use a cursor instead of an ICON when over Motif windows,
- to get rid of the current junk that Motif leaves because
- of its XCopyArea stupidity for doing highlighting.
-
- - Add a GTK_DRAG_VERIFY target flag and a "drag_data_verify"
- signal so that apps can easily check if a, say,
- text/uri-list URL looks OK during the drop.
-
- - Check more for memory leaks.
-
- - Drag and drop for Entry and Text widgets.
-
- - Send synthetic motion events on structure changes so
- drag_enter/leave get sent properly. (See the popup
- in testdnd)
+++ /dev/null
-<!-- This is used to generate the online TODO list for GTK+ using
- the script docs/make-todo. Whenever a change to this file is
- committed to CVS,the file is run through make-todo and the online
- version updated. If you modify this file, you should check for
- parse errors by running:
-
- $ docs/make-todo TODO.xml > /dev/null
-
- before committing, or you may screw up the online version -->
-<todo logourl="gtk-logo-rgb.gif">
- <title>GTK+ TODO list</title>
- <section>
- <title>GDK</title>
-
- <entry size="medium" status="90%" target="2.0">
- <title>Add backing store support</title>
- <description>
- <p>
- GTK+'s drawing model involves clearing to a background, and
- then drawing widgets on top of this. Without having
- backing-store support, this results in flickering in various
- situations. Backing store cannot be added widget-by-widget,
- because the drawing in a particular window is not confined
- to a single widget. Instead it needs to be added per GDK
- window.
- </p>
- <p>
- The way this is done is by having
- <tt>gdk_window_begin_paint()</tt>
- and <tt>gdk_window_end_paint()</tt> functions that
- redirect all drawing to a particular window to an offscreen
- pixmap, and then copy that offscreen pixmap back onto the
- screen when the paint operation is done. The implementation
- of this is mostly complete in the <tt>gtk-no-flicker</tt> branch of
- GTK+.
- </p>
- </description>
- <url>http://www.gtk.org/~otaylor/gtk/1.4/gdk-drawing.html</url>
- <contact>Owen Taylor <otaylor@redhat.com></contact>
- </entry>
-
- <entry size="medium" status="90%" target="2.0">
- <title>32 Bit Coordinates</title>
- <description>
- <p>
- GTK+-1.2 and earlier share X's limitation on the
- size of coordinates and restrict all dimensions
- to 16 bit quantities. By clever use of X it is
- possible to lift this restriction and present a
- full 32-bit space to the user.
- </p>
- <p>
- There are some difficulties with performance in this
- approach - mostly because scrolling can involve mapping and
- unmapping lots of widgets, but in general, current
- trials in this area seem to work pretty well.
- </p>
- </description>
- <url>http://www.gtk.org/~otaylor/gtk/1.4/gdk-drawing.html</url>
- <contact>Owen Taylor <otaylor@redhat.com></contact>
- </entry>
-
- <entry size="small" status="0%" target="2.0">
- <title>Customizable double-click timeout</title>
- <description>
- <p>
- The current fixed double-click timeout in GTK+
- is too small for some users. This needs to be
- customizable
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- <bugs>#3958</bugs>
- </entry>
-
- <entry size="small" status="0%" target="2.0">
- <title>Make color handling more convenient</title>
- <description>
- <p>
- Add some color convenience functions; such as a way to get an
- allocated GdkColor from GdkRGB, and export functions from gtkstyle.c
- that lighten/darken a given color, and set a color from HSV in
- addition to RGB. Also, consider having static variables that contain
- preallocated common colors (gdk_blue, gdk_red, etc.), the problem
- being colormap issues.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="small" status="0%" target="2.0">
- <title>Cursors</title>
- <description>
- <p>
- Two tasks: 1) move the cursors in the cursor font that people actually
- care about to the top of the gdkcursor.h header file, and put a nice
- list of the 15 cursors people actually care about in the docs 2) if
- the cursor font lacks some commonly-useful cursors (like magnifying
- glass), add these cursors to gdkcursor.h and then emulate them in
- gdk_cursor_new by transparently creating the cursor from a bitmap.
- The list of Qt cursors is worth http://doc.trolltech.com/qcursor.html
- looking at for this task.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="medium" status="100%" target="2.0">
- <title>Make GdkRGB work on any visual</title>
- <description>
- <p>
- GdkRGB should be able to render to an arbitrary visual
- (i.e. the visual shouldn't be fixed at gdk_rgb_init()
- time). This will break gdk_rgb_gc_set_foreground() and
- friends, though.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- </section> <!-- GDK -->
-
- <section>
- <title>Internationalization</title>
-
- <entry size="big" status="90%" target="2.0">
- <title>Integrate Pango</title>
- <description>
- <p>
- The purpose of the Pango project is to provide a system for
- layout and rendering of internationalized text. It handles
- most of the issues necessary to
- </p>
- </description>
- <url>http://www.pango.org</url>
- <contact>gtk-i18n-list@redhat.com</contact>
- </entry>
-
- <entry size="medium" status="90%" target="2.0">
- <title>Switch to using UTF-8</title>
- <description>
- <p>
- This is closely related to Pango integration. Pango deals
- with all strings in terms of UTF-8; by switching GTK+ over
- to UTF-8 we make it considerably simpler for developers to
- support multiple languages properly while still retaining
- a large degree of compatibility with existing programs.
- </p>
- <p>
- Some work has already been done on this as part of the Win32
- port, since the Win32 port is currently using UTF-8 for all
- strings. In general, this should be an easy job; the hardest
- parts are places like GtkFileSelection, cut and paste, and
- input method support where there is interaction between GTK+
- and the operating system.
- </p>
- </description>
- <contact>gtk-i18n-list@redhat.com</contact>
- </entry>
-
- <entry size="big" status="60%" target="2.0">
- <title>Rewrite Input Method Support</title>
- <description>
- <p>
- Support for Input Methods is GTK+-1.2 is done via XIM, with
- supported styles being over-the-spot and the root-window
- styles. However, the over-the-spot style is not going to
- work well with the Pango integration, since it relies on the
- text rendering in the program being done in the standard
- Xlib style, so it will be necessary to also support
- on-the-spot input. On-the-spot input is done by supplying a
- set of callbacks that are invoked by the input methods.
- </p>
- <p>
- GTK+-2.0 will have a new system with loadable input method
- modules. These modules can either be implemented using XIM,
- or written from scratch.
- </p>
- </description>
- <contact>gtk-i18n-list@redhat.com</contact>
- </entry>
- </section> <!-- i18n -->
-
- <section>
- <title>GTK+ Core</title>
-
- <entry size="big" status="60%" target="2.0">
- <title>GLib based object and type system</title>
- <description>
- <p>
- The GTK+ object system is already in use in quite a few different
- non-GUI applications; it would be desirable for these uses
- to have the object and type systems separated from the GUI portions
- of GTK+ and be generalized for non-GUI usage.
- </p>
- </description>
- <contact>Tim Janik <timj@gtk.org></contact>
- </entry>
-
- <entry size="big" status="1%" target="2.0">
- <title>Overall callback improvements</title>
- <description>
- <p>
- The GTK+ type and signal systems need significant improvements to
- allow signal creation with default handlers from language bindings
- and to aid language bindings in deriving new objects.
- One aspect of this is the Closure support, recently suggested by
- Karl Nelson <kenelson@ece.ucdavis.edu>, but this also
- requires a GLib based type and parameter system (ties in with
- "GLib based object and type system").
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="big" status="0%" target="2.0">
- <title>State change notification</title>
- <description>
- <p>
- GTK+ objects emit various types of signals, some to perform
- arbitrary actions, some to allow customization from user code,
- and some signals are emitted to notify of certain changes
- of an object. For the latter, what really is required is a
- gneneric signal that can be used to monitor *any* kind of object
- changes. For that, all object changes need to be routed through
- a central point (otherwise the signal emissions are spread all
- over the object implementation), i.e. an object argument setter.
- The state change notification signal doesn't need to be emitted
- syncronously, in fact, it's probably most effective to always
- emit this asynchronously, so subsequent changes are accumulated.
- </p>
- </description>
- <contact>Tim Janik <timj@gtk.org></contact>
- </entry>
-
- <entry size="big" status="5%" target="2.0">
- <title>Widget as sensitivity/grab state machine</title>
- <description>
- <p>
- Maintenance of pointer and keybnoard grabs is currently very
- tedious and error-prone, most widget's cook up their own stuff
- in this regard.
- By moving the general concept of "Grabs" to the GTK+ level as
- a widget state, and providing a new signal for alterations of
- a widget's state ("visible", "visible+insensitive",
- "visible+grab", "hidden", "hidden+insensitive", etc.), things
- can be unified and more stabelize. A couple of bugs, such as
- insensitive widgets still holding a grab, or buttons that
- still think they are depressed when hidden, will be squeezed
- automatically with that.
- </p>
- </description>
- <contact>Tim Janik <timj@gtk.org></contact>
- </entry>
-
- <entry size="big" status="0%" target="2.0">
- <title>Allow argument customization</title>
- <description>
- <p>
- Many types of object arguments (expander style in the CList,
- default padding in button boxes, etc), conceptually go with
- the theme, or as user preferences; they should not be set by
- a particular program.
- </p>
- <p>
- There needs to be a mechanism for themes to be able to
- control these arguments from the RC file.
- </p>
- </description>
- </entry>
-
- <entry size="medium" status="0%" target="2.0">
- <title>Allow global customization</title>
- <description>
- <p>
- There are a number of global parameters in GTK+ and GDK that should be
- customizable by the user, such as the double-click timeout,
- or whether widgets should be backing-stored by default.
- </p>
- <p>
- If we had argument customization from an RC file, it might
- be possible to do this simply with a global object with
- arguments for the various global parameters that was
- customized in the same fashion as object arguments.
- </p>
- </description>
- </entry>
-
- <entry size="small" status="0%" target="2.0">
- <title>Gtk+ Modules installation directory</title>
- <description>
- <p>
- Gtk+ needs to support an extra lib/ directory, to search
- for dynamically loadable modules, it also needs to support
- an environment variable to specify module search paths.
- This has quite some cross-platform issues with the GModule
- code (especially on AIX).
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
-
- <entry size="small" status="20%" target="2.0">
- <title>Convenient widget setup</title>
- <description>
- <p>
- Make it simpler to set all the basic attributes of a widget. Might
- want set_tooltip(), set_accel(), set_color(FOREGROUND, color),
- set_min_size() (usize does this, but needs a rename), set_whatsthis(),
- etc. set_accel() may not work for all widgets, may need a convenience
- API for button and label accelerators specifically.
- </p>
- <p>
- The idea is that it should be easy, out of the box, to set up a widget
- with all the nice touches and features the widget really should
- have. Users shouldn't need to do their own convenience functions for
- this.
- </p>
-
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="medium" status="0%" target="> 2.0">
- <title>Make selections/clipboard more convenient</title>
- <description>
- <p>
- Make GtkSelectionData more like the MIME blobs in Swing and Qt.
- Consider a GtkClipboard object to simplify cut-and-paste handling.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
-
- <entry size="small" status="80%" target="2.0">
- <title>Stock label/icon system</title>
- <description>
- <p>
- A system like GnomeStock for getting a standard labels/icons
- for menus and toolbars. Should be extensible by themes, and
- by libgnomeui. Some work already done on this.
- </p>
- </description>
- <contact>hp@redhat.com</contact>
- </entry>
-
-
- <entry size="big" status="0%" target="> 2.0">
- <title>Session Management</title>
- <description>
- <p>
- Look in to session management. Consider whether to use
- X11R6 SM, or some custom spec shared with KDE. Create
- GTK+ API for this.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="big" status="0%" target="> 2.0">
- <title>Online help enhancements</title>
- <description>
- <p>
- Look at a small "What's This" popup widget,
- and a What's This system in general (this part
- could maybe be done for 2.0). A more difficult, probably
- a post-2.0 task, is to integrate a very simple little
- help browser gizmo into GTK.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
-
- <entry size="medium" status="0%" target="2.0">
- <title>GUI-editable means of user configuration</title>
- <description>
- <p>
- Need to be able to set double click time, whether cursors
- blink, etc., from a control panel type of deal.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- </section> <!-- Core -->
-
- <section>
- <title>GTK+ Widgets</title>
-
- <entry size="small" status="100%" target="2.0">
- <title>Make GtkFrame use a label</title>
- <description>
- <p>
- The title of a frame should simply be another child widget
- which, by default, holds a label widget. This will important
- with Pango where proper text behavior will be more complex to
- implement, but is also useful for certain user-interface
- designs. (It can be useful, for example, to put a checkbutton
- in that slot.)
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="big" status="90%" target="2.0">
- <title>Replace GtkText Widget</title>
- <description>
- <p>
- The GtkText widget is badly in need of replacement, since it
- is buggy and insufficiently feature rich. This is being done
- using Havoc Pennington's port of the Tk Text widget.
- </p>
- <p>
- As part of this job <a href="http://www.pango.org">Pango</a>
- support is being added to the replacement. The structure of
- the Tk text widget port is suited to this as it works
- paragraph-by-paragraph, and Pango works at a sub-paragraph
- scale. The main remaining tasks here are to implement
- incremental reflow to make performance acceptable and to
- implement embedded pixmaps and widgets.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="small" status="20%" target="2.0">
- <title>Improve Radio/Checkbutton Look</title>
- <description>
- <p>
- The default look for the radio and checkbuttons is both
- unattractive and not friendly to the user . Motif did not
- get this one right, and we should not keep on following the
- Motif look. The right thing here is probably to copy the
- Windows appearance for these controls fairly closely. This
- will fit in with well with the rest of the GTK+ look.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="small" status="99%" target="2.0">
- <title>Improve Submenu Navigation</title>
- <description>
- <p>
- Navigating through a deep menu tree in GTK+ is currently
- quite tricky, because as soon as one leaves a menu item,
- the submenu disappears. The way that the Macintosh is
- reputed to handle this is that to pop down the current
- submenu, you have to leave the triangle defined by the
- upper left hand corner of the menu item and right
- side of the submenu.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="small" status="0%" target="2.0 ?">
- <title>Improve Spinbutton Look</title>
- <description>
- <p>
- Spinbuttons currently appear to have lumpy boundaries,
- because sides of the arrows aren't at an angle that
- meshes well with the pixel grid. However, fixing this
- would require making the spinbuttons narrower and
- harder to hit. This points out a general problem with
- the spinbutton (and the arrows on the scrollbars) - the
- target area for clicks actually the bounding box of the
- arrows, but the user thinks that they must click on the
- arrows themselves. It would probably be more friendly
- to use a square button with an arrow drawn on top instead
- of a arrow-shaped button, the approach taken by most other
- windowing systems.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="big" status="90%" target="2.0">
- <title>Supply horizontable/vertical wrapping boxes</title>
- <description>
- <p>
- An often requested feature are wrapping containers, at this
- point, gimp's development version already uses such widgets:
- horizontable/vertical wrap boxes, that need to go into 2.0
- proper at some point.
- </p>
- </description>
- <contact>Tim Janik <timj@gtk.org></contact>
- </entry>
-
- <entry size="medium" status="90%" target="2.0">
- <title>Improved generic combo support</title>
- <description>
- <p>
- Gtk+'s combo box has several drawbacks in design and
- implementation. An new attempt at providing the combo box
- functionality with improved flexibility has been made with
- the GtkClueHunter widget, sitting in the CVS module "gle".
- </p>
- </description>
- <contact>Tim Janik <timj@gtk.org></contact>
- </entry>
-
- <entry size="big" status="40%" target="2.0?">
- <title>Add unified set of List/Tree/Grid widgets</title>
- <description>
- <p>
- Currently, GTK+ has a large number of list and tree widgets
- (GtkList, GtkTree, GtkCList, GtkCTree), none of which are
- ideal. The GtkList and GtkTree widgets perform badly on large
- number of items. (GtkTree widget is also quite buggy.) GtkCList
- and GtkCTree mostly solve the size problem, but are quite
- complex and, despite that, not very flexible. They are limited to
- displaying pixmaps and text, and can neither support arbitrary
- widgets nor custom drawing functions.
- </p>
- <p>
- In addition to list and tree widgets, a closely related need
- is a sheet widget that displays a (possibly editable) 2-D grid.
- It would be desirable to have a complete set of widgets that
- could be presented as the one-true-solution for these needs.
- Model/View techniques could be used effectively to increase
- both the simplicity and power of the interfaces.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="small" status="0%" target="2.0">
- <title>GtkImage</title>
- <description>
- <p>
- gdk-pixbuf is moving to become a GTK+ dependency, a new image-display
- widget is thus needed.
- </p>
- </description>
- <contact>hp@redhat.com</contact>
- </entry>
-
- <entry size="small" status="0%" target="2.0">
- <title>Attempt to fix GtkStatusbar</title>
- <description>
- <p>
- GtkStatusbar is too inconvenient to use.
- The only non-breakage-inducing fix we could
- come up with is to permit 0 as a context ID, so you
- don't have to use gtk_statusbar_get_context_id().
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="small" status="95%" target="2.0">
- <title>Decruft GtkProgress, GtkProgressbar</title>
- <description>
- <p>UPDATE: this is done, just need to apply the patch.
- </p>
-
- <p>
- This interface is just a disaster of overcomplexity;
- it should pretty much just be set_percentage(),
- pulse() (to move during activity mode), and set_text().
- There's no reason that there are two objects, should
- just be one interface. Almost all the functions
- that currently exist should be deprecated.
- </p>
- </description>
- <contact>hp@redhat.com</contact>
- </entry>
-
- <entry size="small" status="0%" target="2.0">
- <title>Entry validation hooks</title>
- <description>
- <p>
- Simple hooks for validation in a GtkEntry. Pretty much just a
- "validate" callback which takes a string (current entry contents) and
- returns either VALID, INVALID, or COULDBEVALID. Then the
- GtkEntry calls this function if it's set, and does the appropriate
- UI things. GTK should come with validators for int and float,
- see GtkSpinButton where these are already implemented.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="big" status="0%" target="> 2.0">
- <title>pseudo-MDI Widget</title>
- <description>
- <p>
- Add a widget that lets you rearrange various views (similar to many
- IDEs, like Visual SlickEdit or JBuilder). Basically there should be a
- central slot and 4 slots around the sides; each slot holds one or more
- views. If two views are dropped in the same slot, then a notebook is
- created displaying both views. If a view is dropped outside the
- application window, it becomes a standalone window. It should be
- possible to restrict whether a view can be dropped on the sides,
- horizontal/vertical sides only, in the central content area, or in
- any of those places.
- </p>
- <p>
- (Havoc has a proposed interface for this, mail hp@redhat.com)
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="medium" status="0%" target="> 2.0">
- <title>Icon List Widget</title>
- <description>
- <p>
- A simple icon list widget, suitable for creating a file selector or
- the like.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="medium" status="0%" target="> 2.0">
- <title>Dock widget</title>
- <description>
- <p>
- Add a widget like GnomeDock (perhaps based on GnomeDock)
- that allows people to put rearrangeable toolbars, menubars, etc.
- around a central content area. The widget should have hooks for
- saving the current positions of the various docked bars.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="big" status="0%" target="> 2.0">
- <title>Canvas widget</title>
- <description>
- <p>
- Figure out how to get GnomeCanvas or a derived work into GTK+ itself.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="medium" status="57%" target="2.0">
- <title>Menu scroll</title>
- <description>
- <p>
- When menus are bigger than the screen, allow scrolling
- as on the Mac.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="medium" status="20%" target="2.0">
- <title>Toolbar/menubar wrap</title>
- <description>
- <p>
- When toolbars and menubars are too wide, do some sort of
- wrapping or drop-down deal. (See Windows/Mac apps for examples.)
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="small" status="0%" target="2.0">
- <title>Blink cursor in GtkEntry</title>
- <description>
- <p>
- Make the cursor optionally blink in GtkEntry. Beware, the entry code
- is somewhat in flux; mail Owen and ask.
- </p>
- </description>
- <contact>otaylor@redhat.com</contact>
- </entry>
-
- <entry size="small" status="100%" target="2.0">
- <title>Don't highlight first menu item when menus come up</title>
- <description>
- <p>
- Keep GtkMenu from prelighting the first menu item.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="small" status="100%" target="2.0">
- <title>Integrate new color selector</title>
- <description>
- <p>
- There's a new color selector in CVS (module gnome-colorsel),
- it needs to be folded in to GTK and any remaining issues resolved.
- (This new selector is API-compatible with the old one, and
- still called GtkColorSelector).
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="medium" status="70%" target="2.0">
- <title>Write new font selector</title>
- <description>
- <p>
- Pango introduces a new font handling system,
- replacing the XLFD system. Need a font selector for this.
- The XLFD selector should probably remain, for apps where
- it makes sense (like gnome-terminal probably).
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- <entry size="small" status="0%" target="2.0">
- <title>Stack Widget</title>
- <description>
- <p>
- Jonathan has a widget like a tabless/frameless notebook, used for
- something like the GNOME control center where you want to toggle which
- widget is visible to the user. Needs to be cleaned up and considered
- for GTK.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org, jrb@redhat.com</contact>
- </entry>
-
- <entry size="small" status="0%" target="2.0">
- <title>Clean up GtkNotebook</title>
- <description>
- <p>
- GtkNotebook currently breaks GTK invariants about
- mapping/visibility/etc., needs fixing.
- </p>
- </description>
- <contact>gtk-devel-list@gnome.org</contact>
- </entry>
-
- </section> <!-- GTK+ -->
-</todo>
-
+++ /dev/null
-
-
-DON'T EDIT THIS FILE - changes are now maintained in the reference
-manual, see docs/reference/gtk/changes-*.sgml. Also, when adding a
-change to the manual, you should amend the docs for all
-newly-deprecated features to point to the replacement for that
-feature, and be sure the GTK_DISABLE_DEPRECATED guards are in place in
-the header files. Be sure to add a note to the docs for EACH
-deprecated function; don't just do the changes-*.sgml change.
-
-
-
-Incompatible Changes from GTK+-1.0 to GTK+-1.2:
-
-* GtkAcceleratorTable has been replaced with GtkAccelGroup
-
-* GtkMenuFactory has been replaced with GtkItemFactory, although
- a version of GtkMenuFactory is currently still provided to ease
- the migration phase.
-
-* The GtkTypeInfo structures used in the gtk_*_type_init() functions have
- changed a bit, the old format:
- GtkTypeInfo bin_info =
- {
- "GtkBin",
- sizeof (GtkBin),
- sizeof (GtkBinClass),
- (GtkClassInitFunc) gtk_bin_class_init,
- (GtkObjectInitFunc) gtk_bin_init,
- (GtkArgSetFunc) NULL,
- (GtkArgGetFunc) NULL,
- };
-
- needs to be converted to:
-
- static const GtkTypeInfo bin_info =
- {
- "GtkBin",
- sizeof (GtkBin),
- sizeof (GtkBinClass),
- (GtkClassInitFunc) gtk_bin_class_init,
- (GtkObjectInitFunc) gtk_bin_init,
- /* reserved_1 */ NULL,
- /* reserved_2 */ NULL,
- (GtkClassInitFunc) NULL,
- };
-
- the GtkArgSetFunc and GtkArgGetFunc functions are not supported from the
- type system anymore, and you should make sure that your code only fills
- in these fields with NULL and doesn't use the deprecated function typedefs
- (GtkArgSetFunc) and (GtkArgGetFunc) anymore.
-
-* A number of Gtk functions were renamed. For compatibility, gtkcompat.h
- #define's the old 1.0.x function names in terms of the new names.
- To assure your Gtk program doesn't rely on outdated function
- variants, compile your program with -DGTK_DISABLE_COMPAT_H to disable
- the compatibility aliases.
-
- Here is the list of the old names and replacements:
-
- Old: Replacement:
-
- gtk_accel_label_accelerator_width gtk_accel_label_get_accel_width
- gtk_check_menu_item_set_state gtk_check_menu_item_set_active
- gtk_container_border_width gtk_container_set_border_width
- gtk_label_set gtk_label_set_text
- gtk_notebook_current_page gtk_notebook_get_current_page
- gtk_packer_configure gtk_packer_set_child_packing
- gtk_paned_gutter_size gtk_paned_set_gutter_size
- gtk_paned_handle_size gtk_paned_set_handle_size
- gtk_scale_value_width gtk_scale_get_value_width
- gtk_style_apply_default_pixmap gtk_style_apply_default_background (1)
- gtk_toggle_button_set_state gtk_toggle_button_set_active
- gtk_window_position gtk_window_set_position
-
- (1) gtk_style_apply_default_background() has an additional
- argument, gboolean set_bg. This parameter should be FALSE if
- the background is being set for a NO_WINDOW widget, otherwise
- true.
-
-* During the development phase of the 1.1.x line of Gtk certain functions
- were deprecated and later removed. Functions affected are:
-
- Removed: Replacement:
- gtk_clist_set_border gtk_clist_set_shadow_type
- gtk_container_block_resize gtk_container_set_resize_mode
- gtk_container_unblock_resize gtk_container_set_resize_mode
- gtk_container_need_resize gtk_container_check_resize
- gtk_ctree_show_stub gtk_ctree_set_show_stub
- gtk_ctree_set_reorderable gtk_clist_set_reorderable
- gtk_ctree_set_use_drag_icons gtk_clist_set_use_drag_icons
- gtk_entry_adjust_scroll (1)
- gtk_object_class_add_user_signal gtk_object_class_user_signal_new
- gtk_preview_put_row gtk_preview_put
- gtk_progress_bar_construct gtk_progress_set_adjustment
- gtk_scrolled_window_construct gtk_scrolled_window_set_{h|v}adjustment
- gtk_spin_button_construct gtk_spin_button_configure
- gtk_widget_thaw_accelerators gtk_widget_unlock_accelerators
- gtk_widget_freeze_accelerators gtk_widget_lock_accelerators
-
-(1) This function is no longer needed as GtkEntry should automatically
- keep the scroll adjusted properly.
-
-* Additionally, all gtk_*_interp functions were removed.
- gtk_*_full versions were provided as of GTK+-1.0 and should
- be used instead.
-
-* GtkButton has been changed to derive from GtkBin.
- To access a button's child, use GTK_BIN (button)->child, instead
- of the old GTK_BUTTON (button)->child.
-
-* The selection API has been slightly modified:
-
- gtk_selection_add_handler() and gtk_selection_add_handler_full()
- have been removed. To supply the selection, one now register
- the targets one is interested in with:
-
- void gtk_selection_add_target (GtkWidget *widget,
- GdkAtom selection,
- GdkAtom target,
- guint info);
-
- or:
-
- void gtk_selection_add_targets (GtkWidget *widget,
- GdkAtom selection,
- GtkTargetEntry *targets,
- guint ntargets);
-
- When a request for a selection is received, the new "selection_get"
- signal will be called:
-
- void "selection_get" (GtkWidget *widget,
- GtkSelectionData *selection_data,
- guint info,
- guint time);
-
- A "time" parameter has also been added to the "selection_received"
- signal.
-
- void "selection_received" (GtkWidget *widget,
- GtkSelectionData *selection_data,
- guint time);
-
-* The old drag and drop API has been completely removed and replaced.
- See the reference documentation for details on the new API.
-
-* Support for Themes has been added. In general, this does
- not affect application code, however, a few new rules should
- be observed:
-
- - To set a shape for a window, you must use
- gtk_widget_shape_combine_mask() instead of
- gdk_window_shape_combine_mask(), or the shape will be
- reset when switching themes.
-
- - It is no longer permissable to draw directly on an arbitrary
- widget, or to set an arbitrary widget's background pixmap.
- If you need to do that, use a GtkDrawingArea or (for a
- toplevel) the new GtkDrawWindow widget.
-
-* The ScrolledWindow widget no longer creates a Viewport
- automatically. Instead, it has been generalized to accept
- any "self-scrolling" widget.
-
- The self-scrolling widgets in the Gtk+ core are GtkViewport,
- GtkCList, GtkCTree, GtkText, and GtkLayout. All of these widgets can
- be added to a scrolled window as normal children with
- gtk_container_add() and scrollbars will be set up automatically.
-
- To add scrollbars to a non self-scrolling widget, (such as a GtkList),
- first add it to a viewport, then add the viewport to a scrolled window.
- The scrolled window code provides a convenience function to do this:
-
- void gtk_scrolled_window_add_with_viewport (GtkScrolledWindow *scrollwin,
- GtkWidget *child);
-
- This does exactly what it says - it creates a Viewport, adds the child
- widget to it, then adds the Viewport to the scrolled window.
-
- The scrollbars have been removed from the GtkCList and GtkCTree,
- because they are now scrolled by simply adding them to a Scrolled
- Window. The scrollbar policy is set on the scrolled window with
- gtk_scrolled_window_set_policy() and not on the child widgets
- (e.g. GtkCList's gtk_clist_set_policy() was removed).
-
-* The "main loop" of GTK+ has been moved to GLib. This should not
- affect existing programs, since compatibility functions have
- been provided. However, you may want to consider migrating
- your code to use the GLib main loop directly.
-
-* the GTK_BASIC flag was removed, and with it the corresponding
- macro and function GTK_WIDGET_BASIC() and gtk_widget_basic().
-
-* All freeze/thaw methods are now recursive - that is, if you
- freeze a widget n times, you must also thaw it n times.
-
- Therefore, if you have code like:
-
- gboolean frozen;
- frozen = GTK_CLIST_FROZEN (clist);
- gtk_clist_freeze (clist);
- [...]
- if (!frozen)
- gtk_clist_thaw (clist);
-
- it will not work anymore. It must be, simply:
-
- gtk_clist_freeze (clist);
- [...]
- gtk_clist_thaw (clist);
-
-* The thread safety in GTK+ 1.2 is slightly different than
- that which appeared in early versions in the 1.1
- development track. The main difference is that it relies on
- the thread primitives in GLib, and on the thread-safe
- GLib main loop.
-
- This means:
-
- - You must call g_thread_init() before executing any
- other GTK+ or GDK functions in a threaded GTK+ program.
-
- - Idles, timeouts, and input functions are executed outside
- of the main GTK+ lock. So, if you need to call GTK+
- inside of such a callback, you must surround the callback
- with a gdk_threads_enter()/gdk_threads_leave() pair.
-
- [ However, signals are still executed within the main
- GTK+ lock ]
-
- In particular, this means, if you are writing widgets
- that might be used in threaded programs, you _must_
- surround timeouts and idle functions in this matter.
-
- As always, you must also surround any calls to GTK+
- not made within a signal handler with a
- gdk_threads_enter()/gdk_threads_leave() pair.
-
- - There is no longer a special --with-threads configure
- option for GTK+. To use threads in a GTK+ program, you
- must:
-
- a) If you want to use the native thread implementation,
- make sure GLib found this in configuration, otherwise,
- call you must provide a thread implementation to
- g_thread_init().
-
- b) Link with the libraries returned by:
-
- gtk-config --libs gthread
-
- and use the cflags from:
-
- gtk-config --cflags gthread
-
- You can get these CFLAGS and LIBS by passing gthread
- as the fourth parameter to the AM_PATH_GTK automake
- macro.
-
-* Prior to GTK+-1.2, there were two conflicting interpretations
- of widget->requistion. It was either taken to be
- the size that the widget requested, or that size
- modified by calls to gtk_widget_set_usize(). In GTK+-1.2,
- it is always interpreted the first way.
-
- Container widgets are affected in two ways by this:
-
- 1) Container widgets should not pass widget->requisition
- as the second parameter to gtk_widget_size_request().
- Instead they should call it like:
-
- GtkRequisition child_requisition;
- gtk_widget_size_request (widget, &child_requisition);
-
- 2) Container widgets should not access child->requisition
- directly. Either they should use the values returned
- by gtk_widget_size_request(), or they should call
- the new function:
-
- void gtk_widget_get_child_requisition (GtkWidget *widget,
- GtkRequisition *requisition);
-
- which returns the requisition of the given widget, modified
- by calls to gtk_widget_set_usize().
-
-
-
-DON'T EDIT THIS FILE - changes are now maintained in the reference
-manual, see docs/reference/gtk/changes-*.sgml. Also, when adding a
-change to the manual, you should amend the docs for all
-newly-deprecated features to point to the replacement for that
-feature, and be sure the GTK_DISABLE_DEPRECATED guards are in place in
-the header files. Be sure to add a note to the docs for EACH
-deprecated function; don't just do the changes-*.sgml change.
+++ /dev/null
-
-
-
-DON'T EDIT THIS FILE - changes are now maintained in the reference
-manual, see docs/reference/gtk/changes-*.sgml. Also, when adding a
-change to the manual, you should amend the docs for all
-newly-deprecated features to point to the replacement for that
-feature, and be sure the GTK_DISABLE_DEPRECATED guards are in place in
-the header files. Be sure to add a note to the docs for EACH
-deprecated function; don't just do the changes-*.sgml change.
-
-
-
-
-
-Incompatible Changes from GTK+-1.2 to GTK+-2.0:
-
-* gtk_container_get_toplevels() was removed and replaced with
- gtk_window_list_toplevels(), which has different memory management
- on the return value (gtk_window_list_toplevels() copies the GList
- and also references each widget in the list, so you have to
- g_list_free() the list after first unref'ing each list member).
-
-* The gdk_time* functions have been removed. This functionality
- has been unused since the main loop was moved into GLib
- prior to 1.2.
-
-* The signature for GtkPrintFunc (used for gtk_item_factory_dump_items)
- has been changed to take a 'const gchar *' instead of 'gchar *', to
- match what we do for glib, and other similar cases.
-
-* The detail arguments in the GtkStyleClass structure are now 'const gchar *'.
-
-* gtk_paned_set_gutter_size() has been removed, since the small handle tab
- has been changed to include the entire area previously occupied by
- the gutter.
-
-* gtk_paned_set_handle_size() has been removed, in favor of a style property,
- since this is an option that only makes sense for themes to adjust.
-
-* GDK no longer selects OwnerGrabButtonMask for button presses. This means
- that the automatic grab that occurs when the user presses a button
- will have owner_events = FALSE, so all events are redirected to the
- grab window, even events that would normally go to other windows of the
- window's owner.
-
-* GtkColorSelectionDialog has now been moved into it's own set of files,
- gtkcolorseldialog.c and gtkcolorseldialog.h.
-
-* gtk_widget_shape_combine_mask() now keeps a reference count on the
- mask pixmap that is passed in.
-
-* the GtkPatternSpec has been moved to glib as GPatternSpec, the pattern
- arguments to gtk_item_factory_dump_items() and gtk_item_factory_dump_rc()
- have thusly been changed to take a GPatternSpec instead of GtkPatternSpec.
-
-* Type system changes:
- - GTK_TYPE_OBJECT is not a fundamental type anymore. Type checks of the
- style (GTK_FUNDAMENTAL_TYPE (some_type) == GTK_TYPE_OBJECT)
- will not work anymore. As a replacement, (GTK_TYPE_IS_OBJECT (some_type))
- can be used now.
- - The following types vanished: GTK_TYPE_ARGS, GTK_TYPE_CALLBACK,
- GTK_TYPE_C_CALLBACK, GTK_TYPE_FOREIGN. The corresponding GtkArg
- fields and field access macros are also gone.
- - The following type aliases vanished: GTK_TYPE_FLAT_FIRST,
- GTK_TYPE_FLAT_LAST, GTK_TYPE_STRUCTURED_FIRST, GTK_TYPE_STRUCTURED_LAST.
- - The type macros GTK_TYPE_MAKE() and GTK_TYPE_SEQNO() vanished, use of
- GTK_FUNDAMENTAL_TYPE() is discouraged. Instead, the corresponding GType
- API should be used: G_TYPE_FUNDAMENTAL(), G_TYPE_DERIVE_ID(),
- G_TYPE_BRANCH_SEQNO(). Note that the GLib type system doesn't build new
- type ids based on a global incremental sequential number anymore, but
- numbers new type ids sequentially per fundamental type branch.
- - The following type functions vanished/were replaced:
- Old Function Replacement
- gtk_type_query() - being investigated -
- gtk_type_set_varargs_type() -
- gtk_type_get_varargs_type() -
- gtk_type_check_object_cast() g_type_check_instance_cast()
- gtk_type_check_class_cast() g_type_check_class_cast()
- gtk_type_describe_tree() -
- gtk_type_describe_heritage() -
- gtk_type_free() -
- gtk_type_children_types() g_type_children()
- gtk_type_set_chunk_alloc() GTypeInfo.n_preallocs
- gtk_type_register_enum() g_enum_register_static()
- gtk_type_register_flags() g_flags_register_static()
- gtk_type_parent_class() g_type_parent() / g_type_class_peek_parent()
- Use of g_type_class_ref() / g_type_class_unref() and g_type_class_peek()
- is recommended over usage of gtk_type_class().
- Use of g_type_register_static() / g_type_register_dynamic() is recommended
- over usage of gtk_type_unique().
-
-* Object system changes:
- GtkObject derives from GObject, so is not the basic object type anymore.
- This imposes the following source incompatible changes:
- - GtkObject has no klass field anymore, an object's class can be retrived
- with the object's coresponding GTK_<OBJECT>_GET_CLASS (object) macro.
- - GtkObjectClass has no type field anymore, a class's type can be retrived
- with the GTK_CLASS_TYPE (class) macro.
- - GtkObjectClass does not introduce the finalize() and shutdown() methods
- anymore. While shutdown() is intended for GTK+ internal use only, finalize()
- is required by a variety of object implementations. GObjectClass.finalize
- should be overriden here, e.g.:
- static void gtk_label_finalize (GObject *gobject)
- {
- GtkLabel *label = GTK_LABEL (gobject);
-
- G_OBJECT_CLASS (parent_class)->finalize (object);
- }
- static void gtk_label_class_init (GtkLabelClass *class)
- {
- GObjectClass *gobject_class = G_OBJECT_CLASS (class);
-
- gobject_class->finalize = gtk_label_finalize;
- }
-
- - the GtkObject::destroy signal can now be emitted multiple times on an object.
- ::destroy implementations should check that make sure that they take this
- into account, by checking to make sure that resources are there before
- freeing them. For example:
- if (object->foo_data)
- {
- g_free (object->foo_data);
- object->foo_data = NULL;
- }
-
- Also, ::destroy implementations have to release object references that
- the object holds. Code in finalize implementations such as:
- if (object->adjustment)
- {
- gtk_object_unref (object->adjustment);
- object->adjustment = NULL;
- }
- have to be moved into the ::destroy implementations. The reason for doing
- this is that all object reference cycles should be broken at destruction
- time.
-
- Because the ::destroy signal can be emitted multiple times, it no longer
- makes sense to check if a widget has been destroyed using the
- GTK_OBJECT_DESTROYED() macro, and this macro has been removed. If
- catching destruction is still needed, it can be done with a signal
- connection to ::destroy.
-
-* Signal system changes:
- The Gtk 2.0 signal merly proxies the GSignal system now.
- For future usage, direct use of the GSignal API is recommended,
- this avoids significant performance hits where GtkArg structures
- have to be converted into GValues. For language bindings,
- GSignal+GClosure provide a much more flexible and convenient
- mechanism to hook into signal emissions or install class default
- handlers, so the old GtkSignal API for language bindings is not
- supported anymore.
- Functions that got removed in the Gtk signal API:
- gtk_signal_n_emissions(), gtk_signal_n_emissions_by_name(),
- gtk_signal_set_funcs(), gtk_signal_handler_pending_by_id(),
- gtk_signal_add_emission_hook(), gtk_signal_add_emission_hook_full(),
- gtk_signal_remove_emission_hook(), gtk_signal_query().
- Also, the GtkCallbackMarshal argument to gtk_signal_connect_full() is
- not supported anymore.
- For many of the removed functions, similar variants are available
- in the g_signal_* namespace.
- The GSignal system perfomrs emissions in a slightly different manner than
- the old GtkSignal code. Signal handlers that are connected to signal "foo"
- on object "bar" while "foo" is being emitted, will not be called anymore
- during the emission they were connected within.
-
-* Inserting and deleting text in GtkEntry though functions such
- as gtk_entry_insert_text() now leave the cursor at its original
- position in the text instead of moving it to the location of
- the insertion/deletion.
-
-* The ->label field of GtkFrame widgets has been removed. (As part of
- a change to allow the arbitrary widgets in the title position.) The
- text can now be retrieved with the new function gtk_frame_get_text().
-
-* The 'font' and 'font_set' declarations in RC files are now ignored. There
- is a new 'font_name' field that holds the string form of a Pango font
-
-* A number of types in GDK have become subclasses of GObject. For the
- most part, this should not break anyone's code. However, it's now
- possible/encouraged to use g_object_ref()/g_object_unref() and other
- GObject features with these GDK types. The converted types are:
- GdkWindow, GdkDrawable, GdkPixmap, GdkImage, GdkGC, GdkDragContext,
- GdkColormap
-
-* All drawables including pixmaps used to have a type tag, the
- GdkWindowType enumeration, which included GDK_WINDOW_PIXMAP.
- GdkWindowType is now a property of GdkWindow _only_, and there is
- no GDK_WINDOW_PIXMAP. You can use the GDK_IS_PIXMAP() macro to see
- if you have a pixmap, if you need to know that.
-
-* GtkStyle and GtkRcStyle are now subclasses of GObject as well. This
- requires fairly extensive changes to theme engines quite badly, but
- shouldn't affect most other code.
-
-* xthickness/ythickness have moved from GtkStyleClass to GtkStyle
- (from class to instance). This gives themes a bit more flexibility
- and is generally more of the Right Thing. You can trivially fix
- your code with s/style->klass->xthickness/style->xthickness/g and
- same for ythickness.
-
-* Some GtkStyle draw_ methods have been removed (cross, oval, ramp)
- and others have been added (expander, layout). This will require
- changes to theme engines.
-
-* If you were using private GDK types, they have been rearranged
- significantly. You shouldn't use private types. ;-)
-
-* The visual for a widget, and also the default visual is now derived
- from the colormap for the widget and the default colormap.
- gtk_widget_set_visual(), gtk_widget_set_default_visual(), gtk_widget_push_visual()
- and gtk_widget_pop_visual() now do nothing. Since the visual always
- had to match that of the colormap, it is safe to simply delete
- all references to these functions.
-
-* A number of functions in GDK have been renamed for consistency and
- clarity. #defines to provide backwards compatibility have been
- included, but can be disabled by defineing GDK_DISABLE_DEPRECATED.
-
- #define gdk_draw_pixmap gdk_draw_drawable
- #define gdk_draw_bitmap gdk_draw_drawable
-
- #define gdk_window_get_size gdk_drawable_get_size
- #define gdk_window_get_type gdk_window_get_window_type
- #define gdk_window_get_colormap gdk_drawable_get_colormap
- #define gdk_window_set_colormap gdk_drawable_set_colormap
- #define gdk_window_get_visual gdk_drawable_get_visual
-
- #define gdk_window_ref gdk_drawable_ref
- #define gdk_window_unref gdk_drawable_unref
- #define gdk_bitmap_ref gdk_drawable_ref
- #define gdk_bitmap_unref gdk_drawable_unref
- #define gdk_pixmap_ref gdk_drawable_ref
- #define gdk_pixmap_unref gdk_drawable_unref
-
- #define gdk_gc_destroy gdk_gc_unref
- #define gdk_image_destroy gdk_image_unref
- #define gdk_cursor_destroy gdk_cursor_unref
-
- (Note that g_object_ref() and g_object_unref() may be used for all of
- the above _ref and _unref functions.)
-
- #define gdk_window_copy_area(drawable,gc,x,y,source_drawable,source_x,source_y,width,height) \
- gdk_draw_pixmap(drawable,gc,source_drawable,source_x,source_y,x,y,width,height)
-
- #define gdk_rgb_get_cmap gdk_rgb_get_colormap
-
- gtk_widget_popup() was removed, it was only usable for GtkWindows, and
- there the same effect can be achived by gtk_widget_set_uposition() and
- gtk_widget_show().
-
-* gdk_pixmap_foreign_new() no longer calls XFreePixmap() on the
- pixmap when the GdkPixmap is finalized. This change corresponds
- to the behavior of gdk_window_foreign_new(), and fixes a lot
- of problems with code where the pixmap wasn't supposed to be
- freed. If XFreePixmap() is needed, it can be done using the
- destroy-notification facilities of g_object_set_data().
-
-* GtkProgress/GtkProgressBar had serious problems in GTK 1.2.
- - Only 3 or 4 functions are really needed for 95% of progress
- interfaces; GtkProgress[Bar] had about 25 functions, and
- didn't even include these 3 or 4.
- - In activity mode, the API involves setting the adjustment
- to any random value, just to have the side effect of
- calling the progress bar update function - the adjustment
- is totally ignored in activity mode
- - You set the activity step as a pixel value, which means to
- set the activity step you basically need to connect to
- size_allocate
- - There are ctree_set_expander_style()-functions, to randomly
- change look-and-feel for no good reason
- - The split between GtkProgress and GtkProgressBar makes no sense
- to me whatsoever.
- This was a big wart on GTK and made people waste lots of time,
- both learning and using the interface.
- So, we have added what we feel is the correct API, and marked all the
- rest deprecated. However, the changes are 100% backward-compatible and
- should break no existing code.
- The following 5 functions are the new programming interface and you
- should consider changing your code to use them:
- void gtk_progress_bar_pulse (GtkProgressBar *pbar);
- void gtk_progress_bar_set_text (GtkProgressBar *pbar,
- const gchar *text);
- void gtk_progress_bar_set_fraction (GtkProgressBar *pbar,
- gfloat fraction);
-
- void gtk_progress_bar_set_pulse_step (GtkProgressBar *pbar,
- gfloat fraction);
- void gtk_progress_bar_set_orientation (GtkProgressBar *pbar,
- GtkProgressBarOrientation orientation);
-
-* The GtkNotebookPage structure has been removed from the public header files;
- this was never meant to be a public structure, and all functionality that
- could be done by accessing the struct fields of this structure should be
- accesible otherwise.
-
-* GtkMenuPositionFunc has a new parameter push_in which controls how
- menus placed outside the screen is handled. If this is set to true and
- part of the menu is outside the screen then Gtk+ pushes it into the visible
- area. Otherwise the menu is cut of at the end of the visible screen area.
-
- Regardles of what happens to the size of the menu, the result is always
- that the items are placed in the same place as if the menu was placed
- outside the screen, using menu scrolling if necessary.
-
-* The "draw" signal and virtual method on GtkWidget has been removed.
- All drawing should now occur by invalidating a region of the widget
- (call gdk_window_invalidate_rect() or gtk_widget_queue_draw() for
- example to invalidate a region). GTK+ merges all invalid regions,
- and sends expose events to the widget in an idle handler for the
- invalid regions. gtk_widget_draw() is deprecated but still works; it
- adds the passed-in area to the invalid region and immediately sends
- expose events for the current invalid region.
- Most widgets will work fine if you just delete their "draw"
- implementation, since they will already have working expose_event
- implementations. The draw method was rarely called in practice
- anyway.
-
-* The GdkExposeEvent has a new region field. This can be used instead
- of the area field if you want a more exact representation of the
- area to update.
-
-* Sending synthetic exposes using gtk_widget_event is no longer allowed.
- If you just need an expose call you should use gdk_window_invalidate_rect()
- or gdk_window_invalidate_region() instead. For the case of container
- widgets that need to propagate expose events to NO_WINDOW children
- you can either use gtk_container_propagate_expose(), or chain to the
- default container expose handler.
-
-* The draw_default and draw_focus methods/signals on GtkWidget are
- gone; simply draw things in your expose handler.
- gtk_widget_draw_focus() and gtk_widget_draw_default() wrapper
- functions are also gone; just queue a draw on the widget,
- or the part affected by the focus/default anyway.
- Also, GtkWidget now has default implementations for focus_in_event
- and focus_out_event. These set/unset GTK_HAS_FOCUS, and queue a
- draw. So if your focus in/out handler just does that, you can delete
- it.
-
-* GtkText and GtkTree are buggy and broken. We don't recommend using
- them, and changing old code to avoid them is a good idea. The
- recommended alternatives are GtkTextView and GtkTreeView. The
- broken widgets are not declared in the headers by default; to use
- them, define the symbol GTK_ENABLE_BROKEN during compilation. In
- some future release, these widgets will be removed from GTK+.
-
-* GdkColorContext is gone; you probably weren't using it anyway.
- Use GdkColormap and the gdk_rgb_* functions instead.
-
-* GtkMenuBar now draws the GtkContainer::border_width space outside
- the frame, not inside the frame
-
-* In GTK 1.2, if an event handler returned TRUE it prevented
- propagation of that event to parent widgets. That is, the
- event signal would not be emitted on parent widgets. In
- GTK 2.0, if an event handler returns TRUE, the current signal
- emission on the current widget is immediately stopped. That is,
- other callbacks connected to the signal will not be invoked.
-
-* gtk_toolbar_new() no longer has arguments. This function
- was broken because the default GtkToolbarStyle (icons, text, both)
- is now a user preference, which is overridden when you call
- gtk_toolbar_set_style(). The constructor forced everyone to
- override the preference, which was undesirable. So to port
- your app, decide if you want to force the toolbar style
- or conform to the user's global defaults; if you want to force
- it, call gtk_toolbar_set_style().
-
- The orientation arg was removed from toolbar_new() as well, just
- because it wasn't very useful and we were breaking the function
- anyway so had an opportunity to lose it. Call
- gtk_toolbar_set_orientation() to set toolbar orientation.
-
-* GtkRange/GtkScrollbar/GtkScale were rewritten; this means that most
- theme engines won't draw them properly, and any custom subclasses of
- these widgets will need a rewrite (though if you could figure out
- how to subclass the old version of GtkRange, you have our
- respect). Also, GtkTroughType is gone.
-
-* The GtkContainer::focus signal/virtualfunction and
- gtk_container_focus() call were replaced by
- GtkWidget::focus and gtk_widget_child_focus().
- The semantics are the same, so you should be able to just
- replace "container_class->focus = mywidget_focus" with
- "widget_class->focus = mywidget_focus" and replace
- gtk_container_focus() calls with gtk_widget_child_focus() calls.
-
- The purpose of this change was to allow non-containers to have
- focusable elements.
-
-* gtk_rc_set_image_loader() and gtk_rc_load_image() has been removed, now
- that GTK+ includes decent image loading capabilities itself.
-
-* An extra GtkSettings argument has been added to
- gtk_rc_find_pixmap_in_path(). This function is only actually useful
- from a theme engine during parsing, at which point the GtkSettings
- is provided.
-
-* The child argument facility in gtkcontainer.c has been converted
- to a child property facility using GParamSpec and other facilities
- for GObject.
-
- - The set_child_arg and get_child_arg virtual methods have been
- replaced with set_child_property / get_child_property, which
- work similar to GObject->set_property/get_property.
-
- - Other removed functions with the replacements:
-
- gtk_container_add_child_arg_type => gtk_container_class_install_child_property
- gtk_container_query_child_args => gtk_container_class_list_child_properties
- gtk_container_child_getv => gtk_container_child_set_property
- gtk_container_child_setv => gtk_container_child_get_property
- gtk_container_add_with_args => gtk_container_add_with_properties
- gtk_container_addv => gtk_container_add / gtk_container_child_set_property
-
-* gdk_image_get() (or rather its replacement,
- gdk_drawable_get_image()) now handles errors properly by returning
- NULL, previously it would crash. Also, a window being offscreen is
- no longer considered an error; instead, the area being contains
- undefined contents for the offscreen areas. In most cases, code
- using gdk_image_get() should really be ported to
- gdk_pixbuf_get_from_drawable().
-
-* gtk_widget_set_usize() has been renamed to
- gtk_widget_set_size_request(), however the old name still exists
- unless you define GTK_DISABLE_DEPRECATED.
-
-* gtk_widget_set_uposition() is deprecated; use gtk_window_move(),
- gtk_fixed_put(), or gtk_layout_put() instead.
-
-* gtk_window_set_policy() is deprecated. To get the effect of
- "allow_shrink", call gtk_widget_set_size_request(window, 0, 0). To
- get the effect of "allow_grow", call
- gtk_window_set_resizable(window, TRUE). You didn't want the effect
- of auto_shrink, it made no sense. But maybe if you were using it you
- want to use gtk_window_resize (window, 1, 1) to snap a window back
- to its minimum size (the 1, 1 will be rounded up to the minimum
- window size).
-
-* The core GTK+ now takes care of handling mapping, unmapping and
- realizing the child widgets of containers in
- gtk_widget_set_parent(). In most cases, this allows container
- implementations to be simplifid by removing the code in add()
- methods to map and realize children. However, there are
- a couple of things to watch out for here:
-
- - If the parent is realized before the add() happens,
- gtk_widget_set_parent_window() must be called before
- gtk_widget_set_parent(), since gtk_widget_set_parent()
- will realize the child.
-
- - If a container depended on its children not being mapped
- unless it did so itself (for example, GtkNotebook only
- mapped the current page), then the new function
- gtk_widget_set_child_visible() must be called to keep
- widgets that should not be mapped not mapped.
-
- As part of this change, most containers also will no longer need
- custom implementations of the map() and unmap() virtual
- functions. The only cases where this is necessary are:
-
- - For !NO_WINDOW widgets, if you create children of widget->window
- and don't map them in realize() then you must map them
- in map(). [ In almost all cases, you can simply map the
- windows in realize() ]
-
- - For NO_WINDOW widgets, if you create windows in your realize()
- method, you must map then in map() and unmap them in unmap().
-
-* gtk_widget_set_default_style (), gtk_widget_push_style (),
- and gtk_widget_pop_style () have been removed, since they
- did not work properly with themes and there were better
- alternatives for modifying the appearance of widgets.
-
- You should generally use gtk_widget_modify_fg/bg/base/text/font
- instead.
-
-* gtk_image_new() now takes no arguments and creates an empty GtkImage
- widget. To create a GtkImage widget from a GdkImage (the least
- common usage of GdkImage), use gtk_image_new_from_image.
-
-* GTK_SELECTION_EXTENDED is now deprecated, and neither the
- GtkList/GtkTree nor the GtkCList/GtkCTree support
- GTK_SELECTION_EXTENDED anymore. However, the old extended behavior
- replaces MULTIPLE behavior.
-
-* The following variables are no longer exported from GDK. (Other variables
- are also no longer exported; the following are the ones found used
- externally in a large sample of GTK+ code.)
-
- Variable Replacement
- ======== ===========
- gdk_null_window_warnings None - did nothing in GTK+-1.2.
- gdk_leader_window None - private variable
- gdk_screen gdk_x11_get_default_screen ()
- gdk_root_window gdk_x11_get_default_root_xwindow ()
- gdk_root_parent gdk_get_default_root_window ()
- gdk_error_code/gdk_error_warnings gdk_error_trap_push()/pop()
- gdk_display_name gdk_get_display ()
- gdk_wm_delete_window gdk_atom_intern ("WM_DELETE_WINDOW", FALSE)
- gdk_wm_take_focus gdk_atom_intern ("WM_TAKE_FOCUS", FALSE)
- gdk_wm_protocols gdk_atom_intern ("WM_PROTOCOLS", FALSE)
-
-* The handling of Colormaps and widgets has been changed:
-
- - The default colormap for widgets is now the GdkRGB colormap, not
- the system default colormap. If you try to use resources created for
- a widget (e.g., widget->style) with a window using the system
- colormap, errors will result on some machines.
-
- - gtk_widget_push/pop_colormap() only cause the colormap to be
- explicitely set on toplevel widgets not on all widgets. The
- colormap for other widgets (when not set using
- gtk_widget_set_colormap()), is determined by finding the nearest
- ancestor with a colormap set on it explicitely, or if that
- fails, the default colormap.
-
-* The default selected day for GtkCalendar is now the current day in the
- month, not the first day in the month. The current month and year
- were already used.
-
-* GDK is no longer put into threaded mode automatically when
- g_thread_init() has been called. In order to use the
- global GDK thread mutex with gdk_threads_enter() and
- gdk_threads_leave(), you must call gdk_threads_init() explicitely.
-
- If you aren't using GDK and GTK+ functions from multiple threads,
- there is no reason to call gdk_threads_init().
-
-* The GtkPreviewInfo struct has had its visual and colormap fields
- removed. Also, gtk_preview_get_cmap() and gtk_preview_get_visual()
- are deprecated, as GdkRgb works on any colormap and visual. You no
- longer need to gtk_widget_push_cmap (gtk_preview_get_cmap ()) in
- your code.
-
-* The GtkBox, GtkTable, and GtkAlignment widgets now call
- gtk_widget_set_redraw_on_allocate (widget, FALSE); on themselves.
- If you want to actually draw contents in a widget derived from
- one of these widgets, you'll probably want to change this
- in your init() function.
-
-* A number of widgets are now NO_WINDOW widgets (most importantly
- GtkButton, but also GtkRange and GtkNotebook)
-
- This has a couple of effects:
-
- - If you are deriving from one of these widgets, you need to
- adapt your code appropriately -- for instance, drawing coordinates
- start from widget->allocation.x, widget->allocation.y.
-
- - If you are embedding one of these widgets in a custom widget,
- you must make sure you call gtk_container_propagate_expose()
- correctly, as you must for any NO_WINDOW widgets.
-
- GtkFixed is a little special; it is now created by default as
- a NO_WINDOW widget, but if you do
-
- gtk_fixed_set_has_window (fixed, TRUE);
-
- after creating a fixed widget, it will create a window and
- handle it properly.
-
-* GtkLayout no longer has the xoffset, yoffset fields, which used
- to store the difference between world and window coordinates for
- layout->bin_window. These coordinate systems are now always
- the same.
-
-* gtk_paint_focus(), gtk_draw_focus() and GtkStyle::draw_focus()
- have been changed a bit:
-
- - A GtkStateType argument has been added to gtk_paint_focus()
- - The default implementation of GtkStyle::draw_focus virtual
- function now draws a focus rectangle whose width is
- determinted by the GtkWidget::focus-width style property.
- - The rectangle passed in is the bounding box, instead of
- the rectangle used in the gdk_draw_rectangle() call, so it is
- no longer necessary to subtract 1 from the width and height.
-
-
-
-DON'T EDIT THIS FILE - changes are now maintained in the reference
-manual, see docs/reference/gtk/changes-*.sgml. Also, when adding a
-change to the manual, you should amend the docs for all
-newly-deprecated features to point to the replacement for that
-feature, and be sure the GTK_DISABLE_DEPRECATED guards are in place in
-the header files. Be sure to add a note to the docs for EACH
-deprecated function; don't just do the changes-*.sgml change.
SUBDIRS = tutorial faq reference
EXTRA_DIST = \
- debugging.txt \
defsformat.txt \
developers.txt \
dnd_internals.txt \
+++ /dev/null
-The GLIB, GDK, and GTK libraries have extensive support for
-debugging the library and your programs.
-
-The amount of debugging being done can be determined both
-at run time and compile time.
-
-COMPILE TIME OPTIONS
---------------------
-
-At compile time, the amount of debugging support included is
-determined by four macros:
-
-G_ENABLE_DEBUG
- If set, enable support for runtime checking.
-
-G_DISABLE_ASSERT
- If set, disable g_assert macros
-
-G_DISABLE_CHECKS
- If set, disable the g_return_if_fail and g_return_val_if_fail macros
-
-G_DISABLE_CAST_CHECKS
- If set, don't check casts between different object types
-
-
-Whether these macros are defined is controlled at configuration
-time by the --enable-debug option.
-
---enable-debug=minimum [default]
- Enable only inexpensive sanity checking
- sets G_DISABLE_CAST_CHECKS
-
---enable-debug=yes
- Enable all debugging support
- sets G_ENABLE_DEBUG
-
---enable-debug=no (or --disable-debug)
- Disable all debugging support (fastest)
- sets G_DISABLE_ASSERT, G_DISABLE_CHECKS, and G_DISABLE_CAST_CHECKS
-
-Note that !G_DISABLE_CHECKS and --enable-debug=no are to be considered
-not only fast, but dangerous as they tend to destabilize even mostly
-bug-free software by changing the effect of many bugs from simple warnings
-into fatal crashes. Thus --enable-debug=no should *not* be used for
-stable releases of gtk+.
-
-
-RUNTIME OPTIONS
-----------------
-
-At run time, if GTK+ was compiled with debugging enabled, different
-types of debugging information can be printed out. This is controlled
-by the:
-
- GTK_DEBUG and GDK_DEBUG environment variables
- --gtk-debug and --gdk-debug command line options
- --gtk-no-debug and --gdk-no-debug command line options
-
-First the environment variables are applied, then the command line
-options are applied in the order given on the command line.
-
-Each of these can either be the special value 'all', or a sequence of
-':' separated options. (case is ignored). The environment variables
-and the --gtk-debug and --gdk-debug options add debugging options and
-the --gtk-no-debug and --gdk-no-debug options remove them.
-
-As noted below, some of these are useful in application debugging, but
-most are only interested to those debugging the libraries
-
-For instance:
-
- GDK_DEBUG_FLAGS=misc:dnd testgtk --gdk-no-debug dnd --gdk-debug events
-
-runs testgtk with the 'misc' and 'events' debugging options.
-
-See glib/docs/debugging.txt for information about debugging signal emission
-and the object system.
-
-
- GDK_DEBUG
- ---------
-
- Application relevant options:
-
- 'events' - Show all events received by GTK
-
- Options only interesting to library maintainers:
-
- 'misc' - Miscellaneous information
- 'dnd' - Information about drag-and-drop
- 'xim' - Information about X Input Method support
-
-
- GTK_DEBUG
- ---------
-
- Options only interesting to library maintainers:
-
- 'misc' - Miscellaneous information
- 'text' - Information about text widget internals
- 'tree' - Information about tree widget internals
- 'updates' - Visual feedback about window updates
-
-
- - 2001-08-13 Matthias Clasen
- - 98/02/19 Owen Taylor
+++ /dev/null
-General
-=======
-
-- gdk_pointer_grab() and gdk_keyboard_grab() are logically member
- functions of GdkWindow.
-
-X specific Functions that need to be moved out of the common header files
-=========================================================================
-
-
-Dir structure for ports
-=======================
-
-The directory structure here is:
-
- gdk/
- gdk/x11
- gdk/win32
- ...
-
-The gdk/ directory directly contains all public
-header files (that are not specific to one
-windowing system).
-
-There, in general should be no system dependency
-
-For each set of functionality, there are the following
-files:
-
- gdkwindow.h: public header file
- gdkwindow.c: common implementation
- x11/gdkwindow.i: functionality specific to X11
- win32/gdkwindow.i: functionality specific to win32
-
-The gdkwindow.c file looks like:
-
-====
-#include "gdkwindow.h"
-
-#ifdef GDK_WINDOWING_X11
-#include "x11/gdkwindow.i"
-#elif defined(GDK_WINDOW_WIN32)
-#include "win32/gdkwindow.i"
- fo#endif
-
-[ generic implementation bits ]
-====
-
-x11/gdkwindow.i should only assume that gdkwindow.h has been
-included and included all other dependencies explicitely.
-
-The x11/ directory will contain:
-
- .i files
- .c files specific to X
- .h files specific to X
-
-And a Makefile.am that takes care of distributing the
-files in the directory, and also for building any
-X-specific utilities. (Such as the gxid daemon).
-
-
-Port Status for Files
-=====================
-
-gdk
-
- Much of the contents have been moved to x11/gtkmain.c.
- I've added a little argument-parsing abstraction.
- (Currently called gdk_arg_context_*) that allows
- arguments from multiple places to be combined - that
- probably needs to be either fixed up and moved into
- GLib or replaced with some existing solution like
- popt.
-
-gdkcc
-
- This will be removed for GTK+-1.4. Right now, it has been moved
- completely into the x11/ directory to avoid having to port it.
-
-gdkcolor
-
- There are a few common utility functions, and the rest
- is in the port-specific files.
-
-gdkcursor
-
- No shared code - completely port-specific.
-
-gdkdnd
-
- No shared code - completely arch-specific. It's possible that some
- common code for handling GdkDragContext could exist, but the
- GdkDragContextPrivate will be different on each port.
-
-gdkdrawable
-
- Pretty much done. GdkDrawable is completely virtualized.
-
-gdkevents
-
- There are a few common utility functions, and the rest
- is in the port-specific files.
-
-gdkfont
-
- Pretty much done for now - gdkfont.c contains a number of functions
- reimplemented as utility functions, and the rest is
- ports-specific. It will be obsoleted by pango before 1.4.
-
-gdkgc
-
- GdkGC is virtualized to go along with GdkDrawable. There are
- a couple of functions I punted on for now and moved into the
- port-specific files - the clipmask functions (because gdkregion
- is not finalized) and also gdk_gc_copy, which I'm not sure
- I like enough to put into the vtable.
-
-gdkim
-
- All in the port-specific directories. The abstraction here probably
- will be changed at some point to something more convenient and
- more Unicode-based.
-
-gdkimage
-
- GdkImage is virtualized - all of the code except for ref/unref
- is in the port-specific files.
-
-gdkinput
-
- Right now all the code is port-specific. It should be possible
- to share the code in gdkinputnone.c, but probably not worth it;
- I'd like to get rid of the gdk_input_vtable in X11 code -
- it doesn't make sense since you can't switch the type of input
- on the fly.
-
-gdkpixmap
-
- All moved into the port-specific file for now. The xpm loader
- should be changed to render with GdkRGB, and thus be
- windowing-system independent, but that requires
- first making GdkRGB able to render onto any arbitrary visual.
-
-gdkproperty
-
- All port-specific. Possibly should be X-specific with a higher-level
- clipboard API on top of it.
-
-gdkregion
-
- Right now punted to being port-specific, but that probably needs
- to change with the virtualized drawables and GC's.
-
-gdkrgb
-
- With a few changes to debugging code, it was already port-independent.
-
-gdkselection
-
- Completely port specific. (In fact, really doesn't make sense
- on anything other than X; a higher-level clipboard facility
- should be provided somewhere, though.)
-
-gdkvisual
-
- Completely port-specific. (The concepts are rather X-specific)
-
-gdkwindow
-
- The window-private data is split between windowing-system independent
- parts and windowing system dependent parts. There are a few
- functions in gdk/gdkwindow.c and the rest is moved off
- into x11/gdkwindow-x11.c
-
-Virtualization
-==============
-
-The concept of virtualization is that calls to draw
-on a drawable are dispatched through a function table.
-This potentially allows for:
-
- Postscript drawables
- metafiles
-
-It also provides a nice clean framework for multi-windowing
-support - instead of reimplementing a whole bunch of function
-calls, one provides an implementaiton for the vtables.
-
-X works in this way internally - per-screen functions are
-virtualized inside a screen structure, and drawing functions
-are virtualized inside the GC structure.
-
-For the virtualization of drawing, clearly GdkDrawable needs
-to be virtualized. Beyond that, one has to decide on
-a case-by-case basis whether a particular structure is
-drawing-mode independent (like GdkRectangle) or not.
-
-The most important GDK structures that are involved drawing are:
-
- GdkColor
- GdkGC
- GdkFont
- GdkRegion
-
-The whole font aspect of Gdk is going to get heavily
-reworked with the introduction of "Pango".
-GdkRegion almost certainly needs to be virtualized,
-if you, way, want to do postscript drawables.
-
-While doing so, the API of GdkRegion should be
-changed so that the region operations take 3 parameters
-instead of returning a newly created region.
-
-
-Drawable operations:
- destroy
- create_gc
- get_values
- set_values
- set_dashes
- copy
-
-GC Operations:
- draw_point
- draw_line
- draw_rectangle
- draw_arc
- draw_polygon
- draw_string
- draw_text
- draw_text_wc
- draw_pixmap
- draw_bitmap
- draw_image
- draw_points
- draw_segments
- draw_lines
-
-
-Adding multi-screen, display support.
-=====================================
-
- The following functions need to have per-display variants:
-
-void gdk_pointer_ungrab (guint32 time);
-void gdk_keyboard_ungrab (guint32 time);
-gint gdk_pointer_is_grabbed (void);
-
-gint gdk_screen_width (void);
-gint gdk_screen_height (void);
-
-gint gdk_screen_width_mm (void);
-gint gdk_screen_height_mm (void);
-
-void gdk_beep (void);
-
-gint gdk_visual_get_best_depth (void);
-GdkVisualType gdk_visual_get_best_type (void);
-GdkVisual* gdk_visual_get_system (void);
-GdkVisual* gdk_visual_get_best (void);
-GdkVisual* gdk_visual_get_best_with_depth (gint depth);
-GdkVisual* gdk_visual_get_best_with_type (GdkVisualType visual_type);
-GdkVisual* gdk_visual_get_best_with_both (gint depth,
- GdkVisualType visual_type);
-
-void gdk_query_depths (gint **depths,
- gint *count);
-void gdk_query_visual_types (GdkVisualType **visual_types,
- gint *count);
-
-GList* gdk_list_visuals (void);
-
-void gdk_add_client_message_filter (GdkAtom message_type,
- GdkFilterFunc func,
- gpointer data);
-
-guint32 gdk_drag_get_protocol (guint32 xid,
- GdkDragProtocol *protocol);
-
-GdkCursor* gdk_cursor_new (GdkCursorType cursor_type);
-GdkCursor* gdk_cursor_new_from_pixmap (GdkPixmap *source,
- GdkPixmap *mask,
- GdkColor *fg,
- GdkColor *bg,
- gint x,
- gint y);
-GdkColormap* gdk_colormap_get_system (void);
-gint gdk_colormap_get_system_size (void);
-
-GdkFont* gdk_font_load (const gchar *font_name);
-GdkFont* gdk_fontset_load (gchar *fontset_name);
-
-gint gdk_selection_owner_set (GdkWindow *owner,
- GdkAtom selection,
- guint32 time,
- gint send_event);
-GdkWindow* gdk_selection_owner_get (GdkAtom selection);
-
-void gdk_selection_send_notify (guint32 requestor,
- GdkAtom selection,
- GdkAtom target,
- GdkAtom property,
- guint32 time);
-gint gdk_text_property_to_text_list (GdkAtom encoding, gint format,
- guchar *text, gint length,
- gchar ***list);
-void gdk_free_text_list (gchar **list);
-gint gdk_string_to_compound_text (gchar *str,
- GdkAtom *encoding, gint *format,
- guchar **ctext, gint *length);
-void gdk_free_compound_text (guchar *ctext);
-GdkAtom gdk_atom_intern (const gchar *atom_name,
- gint only_if_exists);
-gchar* gdk_atom_name (GdkAtom atom);
-GList *gdk_input_list_devices (void);
-void gdk_input_set_source (guint32 deviceid,
- GdkInputSource source);
-gint gdk_input_set_mode (guint32 deviceid,
- GdkInputMode mode);
-void gdk_input_set_axes (guint32 deviceid,
- GdkAxisUse *axes);
-void gdk_input_set_key (guint32 deviceid,
- guint index,
- guint keyval,
- GdkModifierType modifiers);
-gint gdk_im_ready (void);
-void gdk_im_end (void);
-GdkIC* gdk_ic_new (GdkICAttr *attr,
- GdkICAttributesType mask);
-GdkRegion* gdk_region_new (void);
-void gdk_event_send_clientmessage_toall (GdkEvent *event);
-gboolean gdk_event_send_client_message (GdkEvent *event,
- guint32 xid);
-
- And maybe:
-
-void gdk_error_trap_push (void);
-gint gdk_error_trap_pop (void);
%files
%defattr(-, root, root)
-%doc AUTHORS COPYING ChangeLog NEWS README TODO
+%doc AUTHORS COPYING ChangeLog NEWS README
%{_bindir}/*
%{_libdir}/libgtk*.so.*
%{_libdir}/libgdk*.so.*
projects / ~andy / gtk / commitdiff