Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Gtk+
C CSS Objective-C JavaScript Python C++ Other
branch: master

GtkPopover: Don't ref NULL widgets

gtk_window_get_default_widget returns NULL if the window does not have a
default widget, so don't ref it in that case.
latest commit c28275f4ec
@baedert baedert authored
Failed to load latest commit information.
build Makefile-newvs: some .vcxproj.filters files are in builddir, some in …
demos demo/glarea: Check errors on GtkGLArea
docs Add default widget handling to popovers
examples Update hello-world.c to GtkApplication, document
gdk docs: Add a note about button 4 & 5
gtk GtkPopover: Don't ref NULL widgets
libgail-util libgail: Add deprecation guards
m4 Do not use AC_CANONICAL_TARGET
m4macros Deprecate GTK_CHECK_BACKEND in favour of PKG_CHECK_MODULES
modules Prevent empty password request popup for kerberos
po-properties Updated POTFILES.skip
po Updated POTFILES.skip
tests testgtk: Respect display cursor size limitations
testsuite gtk-builder-tool: Run the tests installed too
AUTHORS small update
COPYING Change FSF Address
HACKING docs: Fix some old live.gnome.org URLs
INSTALL.in Cosmetic formatting fixes
MAINTAINERS update file format
Makefile.am Make a pot generating command available
Makefile.decl build: Set no_undefined in Makefile.decl
NEWS 3.17.1
NEWS.pre-1-0 ooops, fogot this on my last commit...
README.commits Update README files to refer to git
README.in Add to release notes
README.win32 docs: Fix some old live.gnome.org URLs
acinclude.m4 Copy newer versions of JH_CHECK_XML_CATALOG and JH_PATH_XML_CATALOG from
autogen.sh autogen.sh: fail faster/clearer if g-i not found
config.h.win32.in Update config.h.win32.in for sincos()
configure.ac gtk-builder-tool: Add some tests
gail-3.0.pc.in Bump the version to 3.0.0
gdk-3.0.pc.in Try to fix linking
git.mk Update git.mk
gtk+-3.0.pc.in Move pangoft2 to Requires.private
gtk+-unix-print-3.0.pc.in configure.ac: Support multiple GDK backends in one build
gtk+.doap doap category core
gtk-zip.sh.in Drop gdk-pixbuf files
make-pot make-pot: Document variables
makefile.msc win32: update msvc build
sanitize-la.sh Some people use a hacked libtool that doesn't even install .la files

README.commits

GTK+ is part of the GNOME git 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 years, we'd like to ask
people committing 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@gnome.org. (Subscription address:
   gtk-devel-list-request@gnome.org.) This is a good place to ask
   about intended changes.

   #gtk+ on GIMPNet (irc.gimp.org, irc.us.gimp.org, irc.eu.gimp.org, ...)
   is 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) With git, we no longer maintain a ChangeLog file, but you are expected
   to produce a meaningful commit message. Changes without a sufficient
   commit message will be reverted. See below for the expected format
   of commit messages.

Notes:

* When developing larger features or complicated bug fixes, it is
  advisable to work in a branch in your own cloned GTK+ repository.
  You may even consider making your repository publically available
  so that others can easily test and review your changes.

* The expected format for git commit messages is as follows:

=== begin example commit ===
Short explanation of the commit

Longer explanation explaining exactly what's changed, whether any
external or private interfaces changed, what bugs were fixed (with bug
tracker reference if applicable) and so forth. Be concise but not too brief.
=== end example commit ===

  - Always add a brief description of the commit to the _first_ line of
    the commit and terminate by two newlines (it will work without the
    second newline, but that is not nice for the interfaces).

  - First line (the brief description) must only be one sentence and
    should start with a capital letter unless it starts with a lowercase
    symbol or identifier. Don't use a trailing period either. Don't exceed
    72 characters.

  - The main description (the body) is normal prose and should use normal
    punctuation and capital letters where appropriate. Normally, for patches
    sent to a mailing list it's copied from there.

  - When committing code on behalf of others use the --author option, e.g.
    git commit -a --author "Joe Coder <joe@coder.org>" and --signoff.


Owen Taylor
13 Aug 1998
17 Apr 2001

Matthias Clasen
31 Mar 2009
Something went wrong with that request. Please try again.