375eea1317
Fri Aug 21 19:02:30 1998 Owen Taylor <otaylor@redhat.com> * gtk/gtkrange.[ch] gtk/gtkhscale.c gtk/gtkvscale.[ch]: Fit scales into the theme-drawing framework. We do this by making them, like check/radio-buttons, no-window widgets with subwindows. We then move the value by calling gtk_widget_queue_clear() and only redraw the value in our draw() / expose() handler. A virtual function clear_background is added which queues a clear on the "background" portion of the widget. Fri Aug 21 13:04:27 1998 Owen Taylor <otaylor@redhat.com> * gtk/gtktext.c (mark_bg_gc): Make background colors work again. (We can't always paint the background with a paint() function - only do that for selected text) Mon Aug 17 20:31:01 1998 Owen Taylor <otaylor@redhat.com> * gtk/gtktearoffmenuitem.c gtk/gtkclist.[ch] gtk/gtkctree.[ch] gtk/gtklabel.c gtk/gtkmenu.c: Merges from main branch. * Makefile.am (SRC_SUBDIRS): Removed themes from SRC_SUBDIRS. the themes can't be built as part of the same build since they depend on gdk_imlib. Fri Aug 14 12:44:30 1998 Owen Taylor <otaylor@redhat.com> * gtk/gtkthemes.c (gtk_theme_engine_get): Removed sample engine code from gtkthemes.c. * configure.in ltconfig.in ltmain.sh gdk/Makefile.am gtk/Makefile.am gtk/ - Upgrade to libtool-1.2b + patch to add shared library dependencies for Linux. (Needs to be extended to other platforms where they are safe) - Check for -ldl so this branch should build on all platforms, though themes will work on all platforms they could work on. - Use -version and -release simultaneously: sonames stay as they are in the current scheme, but -lgtk-1.1 changes to -lgtk. - Added in extra -l flags to library LDFLAGS so we get shared library dependencies against X libs and -ldl. (But not libgtk against libgdk or libglib yet, since dependencies against uninstalled libraries aren't portable) Fri Aug 21 19:08:25 1998 Owen Taylor <otaylor@redhat.com> * Makefile.am: Added support for metal theme. Install/distribute gtkrc's for each theme. Mon Aug 17 20:32:53 1998 Owen Taylor <otaylor@redhat.com> * Makefile.am, pixmap/Makefile.am: Switch back to using automake, fix things up to make dist properly. * pixmap_theme.h: Rationalized. * win95_theme.h motif_theme.h: Removed * Started ChangeLog.
53 lines
2.1 KiB
Plaintext
53 lines
2.1 KiB
Plaintext
GTK+ is part of the GNOME CVS repository. At the current time, any
|
|
person with write access to the GNOME repository, can make changes to
|
|
GTK+. This is a good thing, in that it encourages many people to work
|
|
on GTK+, and progress can be made quickly. However, GTK+ is a fairly
|
|
large and complicated package that many other things depend on, so to
|
|
avoid unnecessary breakage, and to take advantage of the knowledge
|
|
about GTK+ that has been built up over the last 18 months, we'd like
|
|
to ask people commiting to GTK+ to follow a few rules:
|
|
|
|
0) Ask first. If your changes are major, or could possibly break existing
|
|
code, you should always ask. If your change is minor and you've
|
|
been working on GTK+ for a while it probably isn't necessary
|
|
to ask. But when in doubt, ask. Even if your change is correct,
|
|
somebody may know a better way to do things.
|
|
|
|
If you are making changes to GTK+, you should be subscribed
|
|
to gtk-devel-list@redhat.com. (Subscription address:
|
|
gtk-devel-list-request@redhat.com.) This is a good place to ask
|
|
about intended changes.
|
|
|
|
If you just want to make a trivial change, and don't want to subscribe,
|
|
you can also mail gtk-bugs@gtk.org. Or, alternatively, you can look in
|
|
the ChangeLog for somebody who has been making changes to the file
|
|
you want to change and email them.
|
|
|
|
#gimp on byxnet (irc.gimp.org, irc2.gimp.org, irc3.gimp.org,
|
|
irc.germany.gimp.org...)s also a good place to find GTK+ developers to
|
|
discuss changes with, however, email to gtk-devel-list is the most
|
|
certain and preferred method.
|
|
|
|
1) Ask _first_.
|
|
|
|
2) There must be a ChangeLog for every commit. (If you discover that
|
|
you only committed half the files you meant to and need to fix that
|
|
up, or something, you don't need a new ChangeLog entry. But in general,
|
|
ChangeLog entries are mandatory.) Changes with out ChangeLog entries
|
|
will be reverted.
|
|
|
|
3) There _must_ be a ChangeLog for every commit.
|
|
|
|
Notes:
|
|
|
|
* If you are going to be changing many files in an experimental fashion,
|
|
it probably is a good idea to create a separate branch for your changes.
|
|
|
|
Owen Taylor
|
|
13 Aug 1998
|
|
|
|
|
|
|
|
|
|
|