We added code to look for settings.ini in system config dirs,
and then proceeded to move it to /usr/share/gtk-3.0 :-(. So,
look in that location as well.
This reverts commit b2e666bf8f.
We need to keep cursor blinking configurable for accessibility
reasons.
https://bugzilla.gnome.org/show_bug.cgi?id=704134
Conflicts:
gdk/win32/gdkproperty-win32.c
gdk/x11/gdksettings.c
gtk/gtksettings.c
gtk/gtktextview.c
This reverts commit fbbcb5c01b.
We will be doing this in gnome-settings-daemon itself instead,
as some X11 based platforms using GTK+ will want to override this.
This feature offers a number of benefits related to providing
feedback to the user when the password is masked. Some experts have
argued that password masking is harmful. I tend to agree with this
setting providing a better and more moderate solution. Some agree:
https://www.schneier.com/blog/archives/2009/07/the_pros_and_co.html
In order to further lessen the impact I've only enabled the feature
on the primary display since the likelyhood of a non-primary display
being visible by others is higher.
This is very useful for hidpi where the dpi is scaled to make
non-dpi aware apps larger. In that case a dpi aware gtk+ using
GDK_SCALE will be getting huge fonts. You can the set GDK_DPI_SCALE
to compensate for this.
Removing object properties is too much of an API break, even for
properties we don't expect to be used outside of GTK itself.
This reverts commit 8b811b623c.
The default font is no longer handled like a custom style sheet that
overrides everything, but as the initial value. This is the same
behavior as in web browsers.
And it allows the theme to actually use the 'font-family' and
'font-size' properties. Of course, a well behaved theme will respect the
setting as much as possible and for example use relative font sizes
(which aren't yet supported, but will be soon).
This gives a GtkSettings object for resolving system-dependant things -
like the default font family and font size.
No code does this yet, but we have an API.
Only GtkSettings implements this.
Make _gtk_style_provider_private_get_color() return a GtkCssValue (a
GtkCssColorValue to be exact) instead of GtkSymbolicColor.
With this, the symbolic color usage inside GTK is minimized.
This way we create one provider per settings object instead of stuffing
it into a global unchanging never-deleting hash table.
Also, we now reload the theme when instructed instead of keeping the old
loaded (and possibly stale) data forever.
https://bugzilla.gnome.org/show_bug.cgi?id=683896
This makes sure the full theme loading logic resides in one function and
isn't scattered around.
As a side-effect, the hash table kept by gtk_css_provider_get_named()
will now be populated with fallback themes. This will not be a problem
after the next commit though.
This reverts commit 1f5dea9eba,
since it was causeing noticable behaviour changes.
Previously, GTK_DATA_PREFIX=/ ./gtk3-demo would start
gtk3-demo with the Raleigh theme. With that change, it
was starting with no theme at all (i.e. all black).
On Windows, gtkwin32themeprivate.h is needed as
_gtk_win32_theme_get_default() is called on that platform to avoid C4013
warnings/errors (aka implicit declaration of ... for GCC folks).
This is not ideal, we should have a real classic windows theme,
but at least its better than everything being pink, which is what
happens otherwise when theming is not enables.
It was problematic to maintain Raleigh going forward, as any
changes in it affected all themes. Also, its more robust if
each theme is a full standalone css rather than relying on
an inherited css base.
So, this changes Raleigh to a standalone theme that we can tweak
without accidentally breaking other themes, and makes the
default theme empty. In fact, we don't even add the default
provider anymore as its always empty.
We now use the GtkStleProviderPrivate interface, which hopefully is
faster and more conformant to CSS. Long term, it definitely should be
both.
I would have liked to split this up into multiple commits, but couldn't
find a way.
This way we don't need to compute them every lookup. (That's not the
real reason though - the real reason is that I want to add new APIs that
require the caching because they return consts).
This is a boolean property that will be set to TRUE if the current
desktop environment is capable of displaying the application menu as
part of the desktop shell.
If it is FALSE then the application will need to display the menu for
itself.
- add gtkmodulesprivate.h and move stuff there from gtkprivate.h
- add gtkprivate.c and move stuff there from gtkmain.c
- add gtkwin32.c and move stuff there from gtkmain.c
- don't redefine GTK_DATADIR and friends in gtkprivate.h
- have _gtk_get_datadir() and friends on all platforms
- remove the horrid hacks where gtkprivate.h can't be included,
or must be included later due to redefinition of the compile-time
directories
This commit introduces a new setting, gtk-visible-focus, backed
by the Gtk/VisibleFocus X setting. Its three values control how
focus rectangles are displayed.
'always' is equivalent to the traditional GTK+ behaviour of always
rendering focus rectangles.
'never' does what it says, and is intended for keyboardless
situations, e.g. tablets.
'automatic' hides focus rectangles initially, until the user
interacts with the keyboard, at which point focus rectangles
become visible.
https://bugzilla.gnome.org/show_bug.cgi?id=649567
Set the Mac key theme when creating a Quartz settings object instead of
having it the default when quartz is enabled.
This keeps compatibility with the GTK2 behavior that the Mac key theme
is not used for the X11 backend, which could now happen for a
multi-backend build.
Previously we were enabling some settings properties only if the X11
backend was enabled. This worked fine with GTK2 where only one backend
was enabled at a time, but now when multiple backends can be enabled,
this does not make sense.
When loading a theme, make sure we take into account the variant
so we don't use the plain version when the theme changes.
Also make sure to fallback to the plain theme when loading a variant
fails.
https://bugzilla.gnome.org/show_bug.cgi?id=640983
This lets themes override settings values again. We are using
the same priority that was used from the rc file parser, so things
are largely unchanged, relative to other settings sources.
Move key file parsing to gtk_settings_load_from_key_file(), in
preparation for loading per-theme files. Load key files from both
/etc and ~/.config, with the latter overriding the former. Support
parsing enum values.
Most code in gtkrc.c has been turned into a no-op, but that one
reverting in public API (gtk_rc_scanner_new() and such). GtStyle
is also more shallow, now fully relies in the backing
GtkStyleContext and all connection to gtkrc.c has been removed.
GtkBinding has been also affected, there is no replacement yet
for custom keybindings in style files, so that piece of code that
hooked into gtkrc has been replaced by a FIXME so in the future
it may be added back.
Some GtkSettings property are registered by other classes. This leads
to the "interesting" issue that setting GtkSettings:gtk-button-images
requires that the GtkButton class is referenced first - or that a
GtkButton is created.
https://bugzilla.gnome.org/show_bug.cgi?id=632538
32K of border ought to be enough for any pixel dimensions. At least
until screens are so huge we start using doubles.
This saves a nice 64 bits of space when we have a GtkBorder
stored somewhere.
Signed integers are used to avoid surprising unsigned math
issues. Just search GTK's whole git log from inception
for "unsigned" if you want to find any number of commits
fixing signed/unsigned bugs.
https://bugzilla.gnome.org/show_bug.cgi?id=629387
Some types of applications would benefit from having "dark" themes,
usually black backgrounds, such as:
* Movie players
* Photo management and display applications
To make it easy for those applications to prefer a dark theme,
we're adding the "gtk-application-prefer-dark-theme" GtkSetting, which
will make the theme loading code automatically look for a "gtkrc-dark"
file in the same directory you would usually find a gtkrc file.
the same name and a "-dark" suffix.
If no "-dark" gtkrc variant is available, the normal gtkrc will
be used.
https://bugzilla.gnome.org/show_bug.cgi?id=617955
...and show them in menus when navigating the menu with the keyboard.
This is similar to what other platforms do, and reduces visual clutter.
There is a setting to control this. Most of the work on this patch was
done by Thomas Wood. See bug 588554.
The Gtk-custom.c file in gir-repository contained a number of
introspection annotations. Merge those into the GTK source files.
Some documentation was moved from the tmpl/ files to accomodate
the addition of annotations.
* gtk/gtksettings.c: (settings_install_property_parser): Handle enums too.
* gtk/gtktoolbar.c (gtk_toolbar_class_init): Move the gtk-toolbar-style and
gtk-toolbar-icon-size settings into GtkSettings because we now use it in
GtkToolPalette too.
* gtk/gtktoolpalette.[h|c]: Add gtk_tool_palette_unset_style() and
gtk_tool_palette_unset_icon_size(), and use the toolbar-style and
icon-size from GtkSettings if these are not set via the set functions.
* demos/gtk-demo/toolpalette.c (on_combo_style_changed),
(do_toolpalette): Add and handle a -1 value to mean the desktop "Default"
toolbar style.
2009-02-01 Behdad Esfahbod <behdad@gnome.org>
* gtk/gtksettings.c (gtk_settings_class_init): Change the
"gtk-fontconfig-timestamp" property from int to uint. Doesn't affect
anything in practice, except that it overflows years later...
svn path=/trunk/; revision=22270
2009-01-15 Murray Cumming <murrayc@murrayc.com>
* gtk/gtkimcontext.c: documentation description: Mention the various
properties and the environment variable, with links to their
documentation.
* gtk/gtksettings.c:
* gtk/gtktextview.c: Make the im-module property documentation more
expansive.
svn path=/trunk/; revision=22123
