Note: custom CSS properties still use the default GtkCssValue and always
will.
So there is a difference in css values used between those, even though
they both carry a GdkRGBA payload.
This way, we don't have to do magic inside GtkStyleContext, but have a
real API.
As a cute bonus, this object implements GtkStyleProvider itself. So we
can just pretend there's only one provider.
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.
This does nothing but turn all GtkBitmask functions into static inline
functions that call the gtk_allocated_bitmask_*() equivalent.
The implementation of the static functions has also been put into a
private header, to not scare people who want to see how things are
implemented.
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.
Replace the (invalid) DTD in the GtkBuilder docs by a
RELAX NG schema. Also install the schema in /usr/share/gtk-3.0,
so it can be used to validate GtkBuilder ui files.
Change the format of GtkBuilder <menu> to be more in-line with the style
of the rest of GtkBuilder so that we can do translation in a consistent
way.
The format is now substantially more difficult to hand-write, but tools
should be along soon.
There is an xslt program attached to the bug to help you convert your
existing .ui files from the old format to the new one.
https://bugzilla.gnome.org/show_bug.cgi?id=668696
This follows the approach used by the Quartz port - that of a separate
implementation matching GtkClipboard.
The simple clipboard tests in gtk3-demo function correctly but there are
almost certainly leaks and bugs.
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 is the interface for GtkWidgets that can be associated with an
action on a GtkAppicationWindow or associated GtkApplication.
It essentially features 'action-name' and 'action-target' properties
with some associated convenience API.
This interface is implemented by GtkButton and GtkToolButton.
https://bugzilla.gnome.org/show_bug.cgi?id=667394
Move internal accel map API there and update all users.
Also, add an internal function to create an accel path for
an action and parameter, and use it in gtkapplication.c and
gtkmodelmenuitem.c instead of duplicating that code.
Put this in a separate file and substantially refactor it.
Move handling of submenu creation into gtkmodelmenuitem where it
belongs.
Improve our handling of when to show separators or not.
This GtkMenuItem subclass (and GActionObserver implementation) contains
all the knowledge necessary for converting a GMenuModel item description
into a GtkMenuItem.
Remove much of the code that used to do this from
gtkapplicationwindow.c.
This feels premature; we do have the fallback situation covered
adaequately with the menubar, and people can do their own creative
solutions with gtk_application_window_get_menu(), so we don't have
to offer a widget for this right now.
This is a GtkWindow subclass that "application windows" will use. Each
is associated with a GtkApplication, has the ability to show menus and
will have its own associated set of actions.
These were destined for GLib, but they don't really make sense as a
public API. Instead, we'll copy/paste them around between the various
codebases that need to render menus.
GtkIconHelper is a helper object to easily obtain a pixbuf from
different icon sources (e.g. a GIcon, an icon name, a stock id, ...).
Code is ported from GtkImage, which will be adapted in the next commit.
We now support -gtk-win32-theme-part(class,part,state) in background
and border-image CSS properties. This renders the corresponding
theme part using DrawThemeBackground() and acts as a base for a
CSS based windows theme.
Note that we build the parsing code even on non-win32 so that
all themese will parse the same on all arches. We draw pink instead
of the actual theme parts on non-win32 though.
Add missing GDK linking to GIR build and examples:
GISCAN Gtk-3.0.gir
CCLD gtk-query-immodules-3.0
./.libs/libgtk-3.so: undefined reference to `gdk_keymap_get_modifier_mask'
./.libs/libgtk-3.so: undefined reference to `gdk_modifier_intent_get_type'
./.libs/libgtk-3.so: undefined reference to `gdk_window_begin_resize_drag_for_device'
./.libs/libgtk-3.so: undefined reference to `gdk_event_triggers_context_menu'
collect2: ld returned 1 exit status
CCLD grid-packing
../gtk/.libs/libgtk-3.so: undefined reference to `gdk_keymap_get_modifier_mask'
[...]
https://bugzilla.gnome.org/show_bug.cgi?id=664027
Move the remaining struct definition into gtkimcontextinfo.h and include
that header in gtk.h. gtkimmodule.h is now an empty header. We should
probably deprecate it somehow.
This is also necessary so headers used in gtk .c files don't include
gtk.h which in turn includes all the deprecated headers which we want to
avoid so we can include them with deprecation warnings turned off.
- 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
gobject_introspection's G-ir-scanner doesn't like the -xobjective-c
option needed to compile ObjectiveC features in quartz implementations
of certain gtk functions. This rearranges the compiler flag environment
variables in Makefile so that G-ir-scanner doesn't see them.
Make the GtkFontChooser API similar to the Gtk{File,Recent,App}Chooser
APIs by introducing GtkFontChooser as an interface, that has a default
implementation in GtkFontChooserWidget.
https://bugzilla.gnome.org/show_bug.cgi?id=657627
This struct keeps track of an area of text in a CSS file and uses it
when specifying information. Also, the cssprovider keeps track of
sections when parsing a file.
It is now no longer possible to disable it.
This doesn't matter though because GTK will not instantiate a11y
objects until you actually use it. So nothing changes in practice.
This will be used as a base both for parsing text-shadow and box-shadow
properties. The type is private, as there's no real use in exporting
this in a public API.
https://bugzilla.gnome.org/show_bug.cgi?id=649314
Instead of relying on GScanner and its idea of syntax, code up a parser
that obeys the CSS spec.
This also has the great side effect of reporting correct line numbers
and positions.
Also included is a reorganization of the returned error values. Instead
of error values describing what type of syntax error was returned, the
code just returns SYNTAX_ERROR. Other messages exist for when actual
values don't work or when errors shouldn't be fatal due to backwards
compatibility.
Value parsing only sometimes emitted errors. Sometimes it didn't emit
errors but ignored the value, sometimes it took a default, sometimes it
converted it to something it deemed suitable.
While refactoring, I moved the whole GValue <=> char * conversion
routines to a separate file, to make navigating the core css provider
easier.
This is a special-purpose button that can be used together with
GPermission objects to control the sensitivity of system settings.
Suitable permission objects can e.g. be obtained from PolicyKit.
http://bugzilla.gnome.org/show_bug.cgi?id=626457
Fixes a regression introduced in 07d49ee5.
Libtool by default refuses to link static libraries into shared
libraries. In Windows, libuuid is however a static library and needed
for shared libgtk; as a work around, use "-Wl,-luuid" to pass the option
directly to the linker.
https://bugzilla.gnome.org/show_bug.cgi?id=642214
-Update to distribute the VS2010 files.
-Added rules in Makefile.am's of GDK and GTK to fill in the
project/filter files templates with up-to-date source file
listings to simplify maintenace.
Any comments on the usage of the VS2010 files are welcome!
At the same time, change the library sonames for -3.0 to just -3.
This is necessary since the 2.99 releases installed libraries like
libgtk-3.0.so.0.9903.0, and we want to prevent the library version
number from jumping back. So 3.0 will have libgtk-3.so.0.0.0.
Gdk-3.0 is already included above via --include-uninstalled, so
don't also specify it in INCLUDES. Doing so breaks if it isn't
installed already, since we try to find the gdk-3.0.pc.
People agreed that it doesn't make sense to make an xembed
implementation like plug/socket does not make sense on anything but X11.
And as GdkNativeWindow is going away for multibackend portability
reasons, we'd either need API fixes in the plug-socket codee or
constrain the widgets to a single backend. We chose the latter.
