Commit 0e3d5070 authored by Owen Taylor's avatar Owen Taylor Committed by Owen Taylor

Extended for the 1.0 release. Eliminated the "before 1.0" section

Fri Apr 10 00:10:16 1998  Owen Taylor  <owt1@cornell.edu>

	* README/INSTALL: Extended for the 1.0 release.
  	* TODO:           Eliminated the "before 1.0" section
parent 1cf58006
Fri Apr 10 00:10:16 1998 Owen Taylor <owt1@cornell.edu>
* README/INSTALL: Extended for the 1.0 release.
* TODO: Eliminated the "before 1.0" section
Thu Apr 9 19:31:51 PDT 1998 Shawn T. Amundson <amundson@gtk.org>
* AUTHORS NEWS README configure.in gtk+.spec glib/configure.in:
......
Fri Apr 10 00:10:16 1998 Owen Taylor <owt1@cornell.edu>
* README/INSTALL: Extended for the 1.0 release.
* TODO: Eliminated the "before 1.0" section
Thu Apr 9 19:31:51 PDT 1998 Shawn T. Amundson <amundson@gtk.org>
* AUTHORS NEWS README configure.in gtk+.spec glib/configure.in:
......
Fri Apr 10 00:10:16 1998 Owen Taylor <owt1@cornell.edu>
* README/INSTALL: Extended for the 1.0 release.
* TODO: Eliminated the "before 1.0" section
Thu Apr 9 19:31:51 PDT 1998 Shawn T. Amundson <amundson@gtk.org>
* AUTHORS NEWS README configure.in gtk+.spec glib/configure.in:
......
Fri Apr 10 00:10:16 1998 Owen Taylor <owt1@cornell.edu>
* README/INSTALL: Extended for the 1.0 release.
* TODO: Eliminated the "before 1.0" section
Thu Apr 9 19:31:51 PDT 1998 Shawn T. Amundson <amundson@gtk.org>
* AUTHORS NEWS README configure.in gtk+.spec glib/configure.in:
......
Fri Apr 10 00:10:16 1998 Owen Taylor <owt1@cornell.edu>
* README/INSTALL: Extended for the 1.0 release.
* TODO: Eliminated the "before 1.0" section
Thu Apr 9 19:31:51 PDT 1998 Shawn T. Amundson <amundson@gtk.org>
* AUTHORS NEWS README configure.in gtk+.spec glib/configure.in:
......
Fri Apr 10 00:10:16 1998 Owen Taylor <owt1@cornell.edu>
* README/INSTALL: Extended for the 1.0 release.
* TODO: Eliminated the "before 1.0" section
Thu Apr 9 19:31:51 PDT 1998 Shawn T. Amundson <amundson@gtk.org>
* AUTHORS NEWS README configure.in gtk+.spec glib/configure.in:
......
Fri Apr 10 00:10:16 1998 Owen Taylor <owt1@cornell.edu>
* README/INSTALL: Extended for the 1.0 release.
* TODO: Eliminated the "before 1.0" section
Thu Apr 9 19:31:51 PDT 1998 Shawn T. Amundson <amundson@gtk.org>
* AUTHORS NEWS README configure.in gtk+.spec glib/configure.in:
......
The 'configure' script can be given a number of options to
enable and disable various features. For a complete list,
type:
Simple install procedure
========================
% gzip -cd gtk-1.0.0.tar.gz | tar xvf - # unpack the sources
% cd gtk-1.0.0 # change to the toplevel directory
% ./configure # run the `configure' script
% make # build GTK
[ Become root if necessary ]
% make install # install GTK
The Nitty-Gritty
================
The 'configure' script can be given a number of options to enable
and disable various features. For a complete list, type:
./configure --help
A few of the more important ones:
* --prefix=PREFIX install architecture-independent files in PREFIX
[ Defaults to /usr/local ]
* --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
[ Defaults to the value given to --prefix ]
* --with-xinput=[no/gxi/xfree] support XInput [default=no]
The --with-xinput flag specifies whether to compile with support
for the XInput extension (mainly used for graphics tablets), and
which form of support to use:
no : no support
gxi : Use generic XInput support
xfree : Use special features in the Wacom drivers in XFree86 3.3.1
and later.
For more information, follow the link from http://www.gtk.org
* --enable-xim support XIM [default=yes]
Specifying --disable-xim will disable support for entering
internationalized text using X Input Methods. This will give
some slight savings in speed and memory use and might be necessary
internationalized text using X Input Methods. This will give some
slight savings in speed and memory use and might be necessary
with older versions of X.
* --with-locale=LOCALE locale name you want to use
* --with-locale=LOCALE locale name you want to use
The --with-locale options is used to determine if your operating
system has support for the locale you will be using. If not, X's built
in locale support will be used.
system has support for the locale you will be using. If not, X's
built in locale support will be used.
Because of bugs in autoconf, it is necessary to specify this option
even if your LANG environment variable is correctly set.
Because of bugs in autoconf, it is necessary to specify this
option even if your LANG environment variable is correctly set.
This option does not determine which locale GTK will use at
runtime. That will be determined from the usual environment variables.
If you will be using multiple locales with GTK, specify the one
for which your operating system has the worst support for the
--with-locale option.
runtime. That will be determined from the usual environment
variables. If you will be using multiple locales with GTK,
specify the one for which your operating system has the worst
support for the --with-locale option.
Options can be given to the compiler and linker by setting
environment variables before running configure. A few of the more
important ones:
CC : The C compiler to use
CPPFLAGS : Flags for the C preprocesser such as -I and -D
CFLAGS : C compiler flags
The most important use of this is to set the
optimization/debugging flags. For instance, to compile with no
debugging information at all, run configure as:
CFLAGS=-O2 ./configure # Bourne compatible shells (sh/bash/zsh)
or,
setenv CFLAGS -O2 ; ./configure # csh and variants
Installation directories
========================
The location of the installed files is determined by the --prefix
and --exec-prefix options given to configure. There are also more
detailed flags to control individual directories. However, the
use of these flags is not tested.
One particular detail to note, is that the architecture-dependent
include file glibconfig.h is installed in:
$exec_pref/lib/glib/include/
if you have a version in $prefix/include, this is out of date
and should be deleted.
A shell script gtk-config is created during the configure
process, and installed in the bin/ directory
($exec_prefix/bin). This is used to determine the location of GTK
when building applications. If you move GTK after installation,
it will be necessary to edit this file.
For complete details, see the file docs/gtk-config.txt
Notes for using XIM support for Japanese input
----------------------------------------------
==============================================
* There is a bug in older versions of kinput2 that will cause
GTK to hang when destroying a text entry. The latest versions
of kinput is available from:
* There is a bug in older versions of kinput2 that will cause GTK
to hang when destroying a text entry. The latest versions of
kinput is available from:
ftp://ftp.sra.co.jp/pub/x11/kinput2
* The locale information file for the ja_JP EUC locale
distributed with some recent versions of X11 specifies to
use the C library multibyte functions. Unless your C library
has support for Japanese locales, this is incorrect, and
will cause problems for GTK's internationalization.
(In particular, this occurs with GNU libc 2.0 and 2.1, in which the
multibyte functions always translate to and from UTF-8; but the
problem may occur for other C libraries, and other operating systems
as well.)
distributed with some recent versions of X11 specifies to use the
C library multibyte functions. Unless your C library has support
for Japanese locales, this is incorrect, and will cause problems
for GTK's internationalization.
(In particular, this occurs with GNU libc 2.0 and 2.1, in which
the multibyte functions always translate to and from UTF-8; but
the problem may occur for other C libraries, and other operating
systems as well.)
To fix this, change the line:
......
General Information
===================
This is GTK+ version 1.0.0. GTK, which stands for the Gimp ToolKit,
is a library for creating graphical user interfaces.
......@@ -8,11 +10,64 @@ The official ftp site is:
The official web site is:
http://www.gimp.org/gtk
Patches can be uploaded to:
ftp://ftp.gimp.org/incoming
A mailing list is located at:
gtk-list@redhat.com
To subscribe: mail -s subscribe gtk-list-request@redhat.com < /dev/null
(Send mail to gtk-list-request@redhat.com with the subject "subscribe")
Installation
============
See the file 'INSTALL'
How to report bugs
==================
To report a bug, send mail either to gtk-list, as mentioned
above, or to gtk-bugs@gtk.org. If you send mail to gtk-list, you
must be subscribed yourself.
In the mail include:
* The version of GTK
* Information about your system. For instance:
- What operating system and version
- What version of X
- For Linux, what version of the C library
And anything else you think is relevant.
* How to reproduce the bug.
If you can reproduce it with the testgtk program that is built
in the gtk/ subdirectory, that will be most convenient. Otherwise,
please include a short test program that exhibits the behavior.
As a last resort, you can also provide a pointer to a larger piece
of software that can be downloaded.
(Bugs that can be reproduced within the GIMP are almost as good
as bugs that can be reproduced in testgtk. If you are reporting a
bug found with the GIMP, please include the version number of the GIMP
you are using)
* If the bug was a crash, the exact text that was printed out
when the crash occured.
* Further information such as stack traces may be useful, but
is not necessary. If you do send a stack trace, and the error
is an X error, it will be more useful if the stacktrace
is produced running the test program with the --sync command
line option.
Patches
=======
Patches can be uploaded to the incoming/ directory on
ftp.gtk.org. Please follow the instructions there, and include
your name and email address in the README file.
If the patch fixes a bug, it is usually a good idea to include
all the information described in "How to Report Bugs".
\ No newline at end of file
TODO BEFORE GTK 1.0
-------------------
Bugs:
* Scrolled windows (GtkList?) get cought in an endless reallocation loop
under certain (rare) circumstances.
......@@ -37,7 +34,7 @@ Bugs:
segfault in malloc
-timj
* Change bitfields to guints from enums for C++ ?
* Change bitfields to guints from enums, or vice versa?
* Expose events aren't being generated correctly for DND demo
......@@ -69,9 +66,6 @@ Additions:
* Should release grab before activating menu item (and remove
menu from screen?)
TODO AFTER GTK 1.0
------------------
* Make all widget attributes configurable after the widget is created (timj).
* Widgets dervied from GtkButton need to be able to override
......@@ -144,11 +138,70 @@ TODO AFTER GTK 1.0
( You'd have to extend gdk_window_set_hints to accept the
window gravity option to get it right. )
* Text/Edit widget: (some of these might be bugs that should be fixed now)
? Allow moving the separator for paned widgets by dragging
it directly instead of using the handle.
? Mark public use of gtk_tree_remove_item as deprecated - it should be used
as:
gtk_container_remove (GTK_CONTAINER(tree), widget);
* Standardize that all strings should be passed as gchar *, not
guchar *. But what about non-string data? (gdk_property_change,
gtk_selection_data_set) X makes these sort of things guchar...
* Check into XAddConnectionWatch - is this needed for XIM?
* Places where a _full variant is needed:
gtk_clist_set_row_data
gtk_init_add
gtk_menu_popup
gtk_toolbar_prepend_element
gtk_toolbar_insert_element
gtk_widget_dnd_data_set (should be guchar * with a copy?
shouldn't be there at all...)
??? GtkDrawingarea.draw_data
* gtk_rc_add_[name/class]_style are broken for bg pixmaps, because
styles are broken for bg pixmaps, and RC styles only hack around
that.
* 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.
* --g-fatal-warnings flag that does
g_set_warning_handler ((GWarningHandler)g_error);
* If a window spontaneously resizes itself N times before any
ConfigureNotify events are received, then due to the interaction
of the ConfigureNotify compression code in GDK and the resize
count used for the window, the window will be size_allocated
the next N-1 times it is moved.
Fix: Only send GDK_EVENT_CONFIGURE when the window is resized,
create a new event type for toplevel motion. (GDK_EVENT_REPOSITION?)
and eliminate the resize count in GtkWindow.
* Generic ScrolledWindow interface, which provide automatic scrollbar
capability to Viewport, Text, and CList widgets.
GTK_POLICY_NEVER for scrolled windows.
* Consider caching more state in GdkWindowPrivate. Currently,
every widget realization involves a XGetGeometry and a
XGetWindowAttributes. And every GdkWindow destruction
involves a XQueryTree.
* Scrolled windows need to be smarter about when they size-request/allocate
their children.
Text/Edit widget:
Bugs:
- Who knows?
- Really big font (150 pt), plus lots of editing caused segfault
Improvements:
......@@ -213,65 +266,5 @@ TODO AFTER GTK 1.0
mouse click, some function to get the word/line under the mouse pointer
[ From: Stefan Jeske <jeske@braunschweig.netsurf.de> ]
- Really big font (150 pt), plus lots of editing caused segfault
- "changed" emitted when doing deletes on empty Text widget.
? Allow moving the separator for paned widgets by dragging
it directly instead of using the handle.
? Mark public use of gtk_tree_remove_item as deprecated - it should be used
as:
gtk_container_remove (GTK_CONTAINER(tree), widget);
* Standardize that all strings should be passed as gchar *, not
guchar *. But what about non-string data? (gdk_property_change,
gtk_selection_data_set) X makes these sort of things guchar...
* Check into XAddConnectionWatch - is this needed for XIM?
* Places where a _full variant is needed:
gtk_clist_set_row_data
gtk_init_add
gtk_menu_popup
gtk_toolbar_prepend_element
gtk_toolbar_insert_element
gtk_widget_dnd_data_set (should be guchar * with a copy?
shouldn't be there at all...)
??? GtkDrawingarea.draw_data
* gtk_rc_add_[name/class]_style are broken for bg pixmaps, because
styles are broken for bg pixmaps, and RC styles only hack around
that.
* 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.
* --g-fatal-warnings flag that does
g_set_warning_handler ((GWarningHandler)g_error);
* If a window spontaneously resizes itself N times before any
ConfigureNotify events are received, then due to the interaction
of the ConfigureNotify compression code in GDK and the resize
count used for the window, the window will be size_allocated
the next N-1 times it is moved.
Fix: Only send GDK_EVENT_CONFIGURE when the window is resized,
create a new event type for toplevel motion. (GDK_EVENT_REPOSITION?)
and eliminate the resize count in GtkWindow.
* Generic ScrolledWindow interface, which provide automatic scrollbar
capability to Viewport, Text, and CList widgets.
GTK_POLICY_NEVER for scrolled windows.
* Consider caching more state in GdkWindowPrivate. Currently,
every widget realization involves a XGetGeometry and a
XGetWindowAttributes. And every GdkWindow destruction
involves a XQueryTree.
* Scrolled windows need to be smarter about when they size-request/allocate
their children.
\ No newline at end of file
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment