diff options
| author | Matthias Clasen <matthiasc@src.gnome.org> | 2002-04-19 23:05:49 +0000 |
|---|---|---|
| committer | Matthias Clasen <matthiasc@src.gnome.org> | 2002-04-19 23:05:49 +0000 |
| commit | 7614512195c93ebb1851efc30b50d4d7141bec61 (patch) | |
| tree | c88125413007cc76a37010166c7c9c88cb9ef473 | |
| parent | ae89375b9e37819371606fafca1e54eaed3d12d4 (diff) | |
| download | gtk+-7614512195c93ebb1851efc30b50d4d7141bec61.tar.gz | |
Remove some files whose content is either obsolete or has been moved
* 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.
| -rw-r--r-- | ChangeLog | 10 | ||||
| -rw-r--r-- | ChangeLog.pre-2-10 | 10 | ||||
| -rw-r--r-- | ChangeLog.pre-2-2 | 10 | ||||
| -rw-r--r-- | ChangeLog.pre-2-4 | 10 | ||||
| -rw-r--r-- | ChangeLog.pre-2-6 | 10 | ||||
| -rw-r--r-- | ChangeLog.pre-2-8 | 10 | ||||
| -rw-r--r-- | Makefile.am | 1 | ||||
| -rw-r--r-- | README.nanox | 32 | ||||
| -rw-r--r-- | TODO | 200 | ||||
| -rw-r--r-- | TODO.xml | 739 | ||||
| -rw-r--r-- | docs/Changes-1.2.txt | 295 | ||||
| -rw-r--r-- | docs/Changes-2.0.txt | 587 | ||||
| -rw-r--r-- | docs/Makefile.am | 1 | ||||
| -rw-r--r-- | docs/debugging.txt | 106 | ||||
| -rw-r--r-- | gdk/TODO | 339 | ||||
| -rw-r--r-- | gtk+.spec.in | 2 |
16 files changed, 61 insertions, 2301 deletions
@@ -1,3 +1,13 @@ +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 diff --git a/ChangeLog.pre-2-10 b/ChangeLog.pre-2-10 index 771542fd86..53a3c6a620 100644 --- a/ChangeLog.pre-2-10 +++ b/ChangeLog.pre-2-10 @@ -1,3 +1,13 @@ +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 diff --git a/ChangeLog.pre-2-2 b/ChangeLog.pre-2-2 index 771542fd86..53a3c6a620 100644 --- a/ChangeLog.pre-2-2 +++ b/ChangeLog.pre-2-2 @@ -1,3 +1,13 @@ +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 diff --git a/ChangeLog.pre-2-4 b/ChangeLog.pre-2-4 index 771542fd86..53a3c6a620 100644 --- a/ChangeLog.pre-2-4 +++ b/ChangeLog.pre-2-4 @@ -1,3 +1,13 @@ +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 diff --git a/ChangeLog.pre-2-6 b/ChangeLog.pre-2-6 index 771542fd86..53a3c6a620 100644 --- a/ChangeLog.pre-2-6 +++ b/ChangeLog.pre-2-6 @@ -1,3 +1,13 @@ +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 diff --git a/ChangeLog.pre-2-8 b/ChangeLog.pre-2-8 index 771542fd86..53a3c6a620 100644 --- a/ChangeLog.pre-2-8 +++ b/ChangeLog.pre-2-8 @@ -1,3 +1,13 @@ +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 diff --git a/Makefile.am b/Makefile.am index 421257277a..096e405dc9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -15,7 +15,6 @@ EXTRA_DIST = \ ChangeLog.pre-1-2 \ README.cvs-commits \ README.win32 \ - README.nanox \ config.h.win32 \ gtk-zip.sh \ sanitize-la.sh \ diff --git a/README.nanox b/README.nanox deleted file mode 100644 index 79909f2a24..0000000000 --- a/README.nanox +++ /dev/null @@ -1,32 +0,0 @@ -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 - @@ -1,200 +0,0 @@ - -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) diff --git a/TODO.xml b/TODO.xml deleted file mode 100644 index 09967526c0..0000000000 --- a/TODO.xml +++ /dev/null @@ -1,739 +0,0 @@ -<!-- 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> - diff --git a/docs/Changes-1.2.txt b/docs/Changes-1.2.txt deleted file mode 100644 index 36d3042f32..0000000000 --- a/docs/Changes-1.2.txt +++ /dev/null @@ -1,295 +0,0 @@ - - -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. diff --git a/docs/Changes-2.0.txt b/docs/Changes-2.0.txt deleted file mode 100644 index 8dfb563dac..0000000000 --- a/docs/Changes-2.0.txt +++ /dev/null @@ -1,587 +0,0 @@ - - - -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. diff --git a/docs/Makefile.am b/docs/Makefile.am index da2d4a909a..103682f86c 100644 --- a/docs/Makefile.am +++ b/docs/Makefile.am @@ -3,7 +3,6 @@ SUBDIRS = tutorial faq reference EXTRA_DIST = \ - debugging.txt \ defsformat.txt \ developers.txt \ dnd_internals.txt \ diff --git a/docs/debugging.txt b/docs/debugging.txt deleted file mode 100644 index 78fde099b6..0000000000 --- a/docs/debugging.txt +++ /dev/null @@ -1,106 +0,0 @@ -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 diff --git a/gdk/TODO b/gdk/TODO deleted file mode 100644 index 982b65d162..0000000000 --- a/gdk/TODO +++ /dev/null @@ -1,339 +0,0 @@ -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); diff --git a/gtk+.spec.in b/gtk+.spec.in index 8a2d69ddda..9fa6645410 100644 --- a/gtk+.spec.in +++ b/gtk+.spec.in @@ -80,7 +80,7 @@ rm -rf $RPM_BUILD_ROOT %files %defattr(-, root, root) -%doc AUTHORS COPYING ChangeLog NEWS README TODO +%doc AUTHORS COPYING ChangeLog NEWS README %{_bindir}/* %{_libdir}/libgtk*.so.* %{_libdir}/libgdk*.so.* |