This lets us do fallback in case an image format is not
supported, and also lets us provide solid-color images.
We don't support image fragment notations.
See ttps://www.w3.org/TR/css3-images/#image-notation
https://bugzilla.gnome.org/show_bug.cgi?id=761318
Instead of spamming stderr with g_warning, use the new
emit_error method of the GtkStyleProviderPrivate interface
to emit an error if loading an image fails.
Currently, GtkCssProvider can emit ::parsing-error only during
the actual parsing, although the documentation hints that it might
happen at other times.
This commit adds a emit_error method to the GtkStyleProviderPrivate
interface that will let us emit errors from the compute() implementations
as well, which can be useful (e.g. if an image fails to load).
In some situations (no header bar, save mode), hitting Escape
would not do anything because the entry ate the key event.
Fix this by telling the entry to only handle Escape when there
is something to do, such as switching back to the path bar.
https://bugzilla.gnome.org/show_bug.cgi?id=761026
We should not hardcode a scale of 1, this leads to
pixellated upscaled images at scale=2, even if the source
is an svg. By passing the proper scale, we can load the
svg at the correct size.
When creating icon info objects for unthemed files, we don't
really have a nominal size, so we pass 0 to mean 'load at
original size'. However, this is not what was happening.
To make this possible, add variants of some pixbuf loading
functions that take a scale factor instead of a desired size,
and use those when we don't have a nominal size.
Eventually, we should probably remove the examples that rely
on geometry support, since they probably don't work correctly
anymore. For now, just disable the warnings.
Grabbing must stay a bit longer until all other backends than x11/wayland
catch up with GDK DnD, so ignore deprecation flags are used on those. The
uses of GdkDeviceManager can be entirely avoided though.
People might put all sorts of gunk in their .XCompose file, in
the hope that XLib makes sense of it. Even if we don't make sense
of it, we shouldn't abort, but instead ignore the lines we can't
understand. Pointed out in
https://bugzilla.redhat.com/show_bug.cgi?id=1301254
We connect to the titlebar widgets change notification regardless
whether it is internally created or not, so don't make the signal
handler disconnection conditional on that either.
We need to unset the titlebar manually before chaining up
in destroy, otherwise we trigger the template invariant
checking - GtkWindow would eventually unset it, but too late
for the invariants checking code in gtk_widget_destroy.
Presently, Gtk will only send a startup notification completion message
for the first window that is shown. This is not good for the case of
GtkApplication, where we are expected to participate in
startup-notification for all windows.
We have avoided this problem by manually emitting the startup complete
message from after_emit in GtkApplication.
Unfortunately, this causes problems for windows that are shown with a
delay. It is also a dirty hack.
The reason for the original behaviour is simple: there is a static
boolean in gtkwindow.c which controls it. We remove this.
Instead, clear the startup notification ID stored in GDK when sending
the completion message. GtkApplication will re-set this the next time
an event comes in which needs startup-notification handling. In the
non-GtkApplication case, newly shown windows will still not send the
message, since the cookie will have been cleared.
Finally, we remove the hack from GtkApplication's after_emit.
This will probably cause some regressions in terms of lingering startup
notification messages. The correct solution here is to always use
gtk_window_present(), including when merely opening a new document (with
a new tab, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=690791
gtk_editable_get_selection_bounds() returns UTF-8 character offsets,
but gdk_pango_layout_get_clip_region() wants byte ranges, so convert
from one to the other.
With English, this is especially visible for passwords, which use ●
as the invisible character.
https://bugzilla.gnome.org/show_bug.cgi?id=761128
This was a thinko - what we sometimes do for signal names is to
use I_() to intern them (to avoid a strdup), but I_() is not
currently available in gdk, so lets just skip this
microoptimization for now.
When the spinbutton grows larger, distribute horizontal size to the
entry and vertical size to the buttons.
Obviously, horizontal size only matters for horizontal spinbuttons and
vertical for vertical spinbuttons.
The font features demo started calling the Harfbuzz API directly
starting from commit 9de3b24c20. Harfbuzz
is an implicit dependency of Pango on some platforms, but it's not part
of the public dependencies; this means that we cannot expect to link to
Pango and automatically get Harfbuzz symbols to link against —
especially when things like --as-needed are in play.
This change triggered build failures on non-Unix platforms, fixed by
commit 2a9967731a, as well as build
failures in Continuous, with this error message:
/usr/lib/gcc/x86_64-gnomeostree-linux/4.9.3/../../../../x86_64-gnomeostree-linux/bin/ld:
font_features.o: undefined reference to symbol 'hb_tag_to_string'
//lib/libharfbuzz.so.0: error adding symbols: DSO missing from command
line
collect2: error: ld returned 1 exit status
In order to get the font features demo to build everywhere we should
take an explicit, though optional, check on Harfbuzz, and conditionally
build the font features demo with the right compiler and linker flags.
The fonts features demo now uses fontconfig APIs via PangoFT2, which makes
the code not build on non-Linux, so only include this demo in the build
on UNIX.
Add more features to the list, allow selecting script/language
from the set that is supported by the font, indicate which
features are present in the font for the selected script/language,
and expand the default specimen to cover latin, cyrillic and
greek.
It looks like the gnome-continuous headers haven't quite
caught up yet, so try __NR_memfd_create instead.
If that doesn't work, i'll likely just add in a fallback
code path.
The tmpdir is used for a wide assortment of things, and
can easily fill up. If it fills then desktop will start
crashing with SIGBUS errors.
This commit changes the shm pool allocation code, to use
memfd_create, instead, so the shared memory files will
be anonymous and not associated with /tmp
https://bugzilla.gnome.org/show_bug.cgi?id=761095
(1) Keep priv->text_allocation for the area used by the text
(2) Compute all text coordinates with the help of priv->text_allocation
As a side effect the get_text_area_size and get_frame_size vfuncs are
now unused. If we wanted them back, they should get a single use durig
size_allocate() and then their results should be stored for further
processing.
This complicates refactorings, so remove that feature. It's not used
anywhere and doesn't play well with nodes the way it's implemented.
If we want it back, we can add it back later.
Changing the visibility of child widgets in size-allocate does
not work well with out current allocation and layout machinery.
To avoid the visual fallout, just keep the arrow buttons visible
and only change their sensitivity.
https://bugzilla.gnome.org/show_bug.cgi?id=754868
We don't want to let baseline adjustment shift the child
out of the original allocation. This is purely a sanity
measure - in practice, the baseline should always be bigger
than the child_baseline.
We were adjusting the allocation to line up baselines before
calling gtk_widget_size_allocate_with_baseline, but that function
is doing this alignment internally anyway and expects to be given
a 'fill' allocation.
Move the allocation adjustment code down into
gtk_box_gadget_allocate_child where it only affects child gadgets,
not child widgets.
Make the theme follow our documentation for the various .csd and
.ssd style classes: They all go on the window node. For now, just
add the new selector; the old one will be removed when mutter has
been updated.
https://bugzilla.gnome.org/show_bug.cgi?id=760714
When measuring children while distributing a given height,
we must measure them for the given width that goes with
the height. Otherwise, things will go wrong if some of the
children do actual width-for-height. This was showing up
as misaligned images in anaconda.
https://bugzilla.gnome.org/show_bug.cgi?id=760967
The pointer position is queried to properly trigger the prelight
updates on the new row below it. We store the last coordinates
though, and track crossing events to unset these, so it's safe
to just update_prelight() here on these.
Check that non-native window are indeed children of the event window and
only then confirm that they should be drawn.
Fixes Glade thinking that it's okay to have the draw function do
different things depending on what window to draw. (This should really
be fixed in Glade.)
There's no reason to insta-crash when something goes wrong. Just don't
do anything stupid.
Also, remove the SPCIAL_CONTAINER() exception. Every case where special
containers needed this, it is wrong and made containers draw children
multiple times.
The text view draw function was leaving its cairo context
with a transformation after drawing to all the border windows,
which lead mis-drawing in gitg. Avoid this by moving the
gtk_cairo_transform_to_window call inside the existing
cairo_save/restore calls.
https://bugzilla.gnome.org/show_bug.cgi?id=760942
Add a query implementation to opacity property. Also fix the assert in
gtk_css_style_property_register() to allow registering properties with
query but without assign function.
https://bugzilla.gnome.org/show_bug.cgi?id=760933
The build glue for collecting all the assets in Adwaita as
resources was assuming that they are all pngs, and tried to
preprocess them into embedded GdkPixbufs.
Fix it to leave svgs unmolested, so they can be recolored
at runtime.
If we fail to load the image for a -gtk-recolor() expression,
fall back to using the image-missing icon instead of crashing,
and include more details in the warning message.
Previously, we were only showing the size of the allocation
and clip area. But there is no good reason to hide the position
of these rectangles, so add them, in the traditional format
of X geometry strings: wxh+x+y
GtkShortcutsWindow is among the 'cheating' containers that iterate
over indirect children in forall, and this is now triggering
an assertion in gtk_container_propagate_draw.
For now, just exclude the cheating containers from the assertion.
Eventually, this needs a better solution.
create_shm_pool doesn't need the width or height, it just needs
the total size. By passing it in, we're requiring it to redo
stride calculation unnecessarily.
This commit drops the width and height parameters and makes the
function just take the total size directly.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
Right now, we assume the stride for the image surface needs to
be 4 byte aligned. This is, in fact, true, but it's better to
ask cairo for the alignment requirement directly rather than
assume we know the alignment rules.
This commit changes the code to use cairo_format_stride_for_width
to calculate a suitable rowstride for pixman.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
create_shm_pool unlinks the temporary file a little,
too late. It should be unlinked before ftruncate()
is called for two reasons:
1) if ftruncate fails, the file is currently not
getting cleaned up at all
2) in theory, if the file is public some other process
could muck with it
This commit just moves the unlink call a little higher
up.
https://bugzilla.gnome.org/show_bug.cgi?id=760897
Button state was being kept in two separate variables, which lead
to slight confusions in DnD that caused the notebook to ignore the
first click after DnD happened from (within) it. Unify these two
into one, which helps us keep better track of the really pressed
buttons.
gdk_rectangle_union will happily add all the worlds pixels
to the union if the initial rectangle is initialized to all
zeros. Therefore, explicitly check for an empty rectangle
before calling it.
This function does not ignore empty rectangles. Since this
is a fairly subtle point about the behavior, it is worth
spelling this out in the documentation. We've had a bug
open about this for a long time:
https://bugzilla.gnome.org/show_bug.cgi?id=464528
Move code to properly reinsert the tab label to where it belongs.
The if has the distinction between reparented-to-dnd-window and
just-changed-the-gdk-window-to-draw-to right there.
https://bugzilla.gnome.org/show_bug.cgi?id=760754
The new function, gtk_render_background_get_clip answers the
question: what pixels are affected if I call gtk_render_background ?
The long-term goal is to have APIs that answer this question for
all rendering primitives.
Commit 8e975b2 (Bug 753969) introduced check of parent accessibility.
Consequently it is not possible to save file if executable attribute
is not set, which might happen for some gvfs backends. Let's assume
that the folder is accessible even if the attribute is not set.
https://bugzilla.gnome.org/show_bug.cgi?id=760881
The viewport itself doesn't move, so we cannot use it as the pixel
cache's background. Use the bottommost using element instead, which is
the viewport's child.
This might need adaptations in themes as we want the backgroud to be
opaque to speed up pixel cache performance.
Use gtk_box_gadget_reverse_children and gtk_css_node_reverse_children
to flip the children of the header_gadget and the tabs_gadget when
appropriate.
Add new CSS node tests to verify that the node order is updated
as expected in all cases.
These functions will be automatically called by the windowing backend.
The usual hooks to run this from in gtk/ shouldn't even happen, but
it is worth to document which calls are expected and which aren't.
If the grab window is destroyed the grab will be implicitly removed,
although we won't get GdkSeat:ungrab called in order to clear our
internal window<->seat relation entirely. Setting a weak ref will
nullify the pointer we keep on the seat to the window, avoiding the
expected crashes.
Due to implicit grabs, we basically can guarantee that the pointer
won't have any buttons pressed at the time of wl_pointer.enter.
Seems like a good place to unset any button modifiers that might
have been left stale by compositor grabs.
When this is in use, there's essentially a bunch of dead code here.
When all backends are ported, we'll be able to remove grab/cursor
management plus a bunch of source-side event handlers.
This includes managing input events and source-side DND events,
as well as setting the appropriate cursor and emitting the signals
that are expected in this mode of operation.
This function (most similar to gtk_drag_get_cursor() helps figure out
the right cursor that applies to a given action. To be used by the
various backends.
We've traditionally left GTK+ to handle the input side of things,
letting GDK only manage the windowing-specific messaging. This
way of splitting responsibilities is not compatible however with
some backends, we must fold then input management at the DnD stage
into GDK (and backends) domain.
The gdk_drag_context_manage_dnd() call is meant to be the entry
point for this mode of operation, if the drag and drop operation
becomes managed, the caller (i.e. gtkdnd.c) doesn't need to perform
grabs, nor manage input events itself.
As a consequence of this, different aspects now belong to the
backend GdkDragContext implementation:
- Because the caller doesn't see keyboard events anymore,
keyboard navigation must be managed in GDK, so is the decision
of the current action based on modifiers/button pressed.
- Because the caller won't see input events in general, the lifetime
of the drag and drop operation is now communicated through the
::drop-performed, ::dnd-finished and ::cancel events
- Because the caller doesn't participate anymore on the action
being chosen, the pointer cursor must be set by the backend.
The caller is rather notified of the final action through the
::action signal.
The caller is still responsible of dealing with the corresponding
GdkSelection, ensuring its ownership and communicating the supported
mimetypes.
... and remove the also forgotten void function that lingered around
with it.
Fixes opacity=0 parts like inactive spinners or sort indicators in
treeview headers being drawn since last commit.
Oops.
Previously, we had a special cae to draw subwindows of widgets.
This is not necessary as conformant widgets should be able to properly
render themselves when all windows need to be painted.
From now on assume that is the case.
We therefore paint nonnative GDK windows "inline" by just returning TRUE
for gtk_cairo_should_draw_window() for those windows.
This speeds up hilighting different rows in the listbox gtk-demo example
tremendously (by a factor of 10 or more) as the previous code was
O(<number of non-window subwidgets> *
<number of subwindows>) which in the listbox example were ~15,000 and
~2,000 respectively.
When using forall(), only list the revealer, which lists the box
containing all the children. When using foreach(), bypass revealer and
box and list all children added to the box.
Derived classes like GtkSourceView with their own ::key-event
handler need access to this, in order to make their keynav
as nice as the builtin one, wrt to caret visibility.
https://bugzilla.gnome.org/show_bug.cgi?id=760748
And use it to handle kinetic scrolling in the GtkScrolledWindow.
However, dropping the delta check causes the X11-based kinetic
scroll to break since we don't have the stop event here. Correct handling of
xf86-input-libinput-based scroll events is still being discussed.
https://bugzilla.gnome.org/show_bug.cgi?id=756729
This adds support for the new wl_pointer events available in v5.
The wl_pointer.axis_source events can be ignored for the purposes here, the
main reason they exist is so that the combination of axis_source=finger and
axis_stop triggers kinetic scrolling. We don't need to care about the source,
axis_stop is enough for us to tell us when we're scrolling.
The wl_pointer.frame events group events together and is intended as a
mechanism to coalesce events together. This for example allows us to now
send a single GTK scroll event for a diagonal scroll. Previously, the two
wl_pointer.axis events had to be handled separately.
The wl_pointer.axis_discrete event sends mouse wheel clicks where
appropriate, and is translated into up/down/left/right scroll events.
https://bugzilla.gnome.org/show_bug.cgi?id=756729
Since a41f02f9b1, GtkIMContextSimple
uses threads to load X Compose files. It does that every time a new
im context object is initialized, so we can easily end up with multiple
threads accessing the shared global_tables list at the same time.
Use a lock to prevent that.
https://bugzilla.redhat.com/show_bug.cgi?id=1276432
To ensure that the title moves to the other side as expected
in RTL, use GTK_ALIGN_START/END instead of GTK_ALIGN_FILL
when packing the title gadget into the vertical box, and
flip the alignment when the text direction changes.
This is mostly search and replace ala
GtkButton => button
GtkWindow => window
.button => button
or removing style properties that aren't used anymore like
-GtkButton-default-border: 0
Most uses of builtin icons (check and radio buttons,
expanders, etc) are placed next to labels, so they should
be properly positioned wrt to the baseline. Lacking anything
better, give the builtin icons a baseline that places the
center of the icon at the strikethrough position.
The 'mad hack' that GtkAccelLabel used to affect the GtkLabel
draw function broke with the introduction of gadgets, since
the positioning is no longer relative to the widgets' allocation
at the time of the call, but rather to the gadgets allocation.
Instead of coming up with an even madder hack to keep this
working, give the GtkLabel draw function knowledge about accel
labels.
https://bugzilla.gnome.org/show_bug.cgi?id=760663
Previously this setting would just invalidate the whole CSS tree and
thereby hopefully avoid all cache usage.
Now, we actually don't cause extra invalidations anymore, but instead
avoid ever inserting anything into the cache when this setting is set.
This essentially copies the previous cache implementation. With one
caveat: It is now attached to and maintained by the CssNode, not by the
CssStyle.
And this is important because styles may be reused in incompatible
situations which would cause cache collisions and lead to broken CSS in
weird situations.
For now, the split out style cache doesn't cache anything. This is
mostly to make sure that bisections of wrong caching behavior will
bisect down to the commit that actually adds caching.
Use a vertical box gadget for the overall expander, and a
horizontal one for the title row. This lets us get rid of
all the custom allocation code here.
So far, the box gadget is always allocating all children the
full size in the cross axis. This behavior corresponds to the
align-items: stretch behavior in
https://www.w3.org/TR/css-flexbox-1/#align-items-property
This commit implements the other modes described there.
While widgets have halign/valign properties that we can use for
this, the API for inserting gadgets has to change to take an
extra align parameter. All callers have been updated to pass
GTK_ALIGN_FILL, since that corresponds to the previous behavior.
https://bugzilla.gnome.org/show_bug.cgi?id=760668
From gtk_widget_path_iter_set_object_name documentation:
"When set, the object name overrides the object type when matching CSS"
Update gtk_widget_path_to_string to match this behaviour.
This is sometimes needed, and calling into actual icon theme
code just for it is confusing - the resulting icon does not
depend on the icon theme at all.
https://bugzilla.gnome.org/show_bug.cgi?id=760536
This prevents WM from drawing shadows around tooltip windows,
which, in Adwaita, should have no shadow and are CSD-ish (which means
that tooltip window is larger than it looks, and WM draws the shadow
only on the outside, leaving a gap between the visible tooltip edge and
the shadow).
https://bugzilla.gnome.org/show_bug.cgi?id=759898
With Mingw-w64 fstat() can be an inline function that
calls _fstat32() or _fstat64(), depending on some macros.
And if LFS is enabled, fstat() is defined to turn into
_fstat32i64() or _fstat64(). And some/all of the above
might also be macros as well. Side-step all that mess
and excplicitly re-define fstat as _fstat32, which is
guaranteed to use a version of "stat" struct that
has 32-bit size and time fields, which is what we want.
https://bugzilla.gnome.org/show_bug.cgi?id=760615
While rescanning the object tree, we were emitting ::object-selected
signals, possibly causing wild blinking in the application window.
Don't do that.
https://bugzilla.gnome.org/show_bug.cgi?id=760572
Commit 0b96b8a1 set margins via css, but accidentally changed the
semantics of margins for separators in popovers so that any separator
in a gtkpopover had a margin. This meant that the separators in
GtkListBoxes in popovers also had a margin around their separators, and
this is not what we want because it doesn't match separators in
listboxes not in popovers.
https://bugzilla.gnome.org/show_bug.cgi?id=760427
If a GtkGestureSingle is set as touch-only, pointer events would be
discarded without giving an opportunity to the regular GtkGesture
handler to manage those.
Because the pointer events weren't actually managed by the gesture,
gtk_gesture_get_sequence_state() (rather unhelpfully here) will resort
to returning GTK_EVENT_SEQUENCE_NONE, which is in turn interpreted
by _gtk_widget_consumes_motion() as "may be handling the events for
this sequence", because gestures in this state presumably handle
the events, just that it's not "claimed" yet.
Instead, use gtk_gesture_handles_sequence(), which will perform the
expected check on the event sequence being managed, as we expect
here.
When a tab drag starts, we need to move the tab label into the drag
window via gtk_widget_set_parent_window().
If we don't unparent, but just unrealize the widget, we don't lose the
cssnode position.
GtkNotebook does not switch the current page if all pages are hidden. So
it may be that no visible page exsits, but there still is a current
page set.
We culd clear the current page, but I'm unsure about backwards
compatibility.
So instead, this new function handles that case.
This allows reworking the content node to do real height-for-width.
The content node also takes care of border width, but we might want to
have the toplevel do it or just get rid of it.
Deprecate initial-gap, tab-curvature and tab-overlap properties. All
their features can be achieved using CSS.
This CSS achieves the same effect as a 10px initial gap:
notebook header {
margin-left: 10px;
margin-right: 10px;
}
A tab overlap of 10px can be achieved via:
notebook tabs {
margin-left: 10px;
}
notebook tab {
margin-left: -10px;
}
And tab curvature is essentially the same as padding or border on a tab.
We skip sides with 0 border width in render_border, but when
we collect sides with the same style, we may pass the 0 width
down to render_frame_stroke anyway. So skip width 0 sides
there as well.
Instead of taking the border and manually removing it from the
allocation, render our background over all the border allocation box, as
that's more correct and does not take padding into account twice.
The GtkGesturePan behavior of locking onto certain orientations may
come across as confusing, and is not strictly necessary for mice and
other pointing devices.
As GtkGesturePan is also a GtkGestureDrag, we just use the same
callbacks on both gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=759670
When a cursor is specified in gdk_seat_grab(), the cursor is reverted as
soon as the pointer enters or leaves another window.
To avoid this issue, store the grab cursor separately, so we force-apply
it in ::set_window_cursor(). Also, unset early the seat info from the
window on gdk_seat_ungrab(), so the next time switch_to_pointer_grab()
happens we end up picking the cursor set for the window underneath the
pointer window.
Based on a patch by Olivier Fourdan <ofourdan@redhat.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=760213
the vertical padding from the headerbar has been removed, now the
sizing is done with min-height, this avoids title and subtitle
labels making the headbar.
We are getting the mime data destroy notify called when we
destroy the surface in finalize. Trying to set the XSync counters
at this time is a) pointless and b) yielding an X error because
the counters have already been destroyed.
To avoid this, unhook the damage tracking before destroying
the surface.
https://bugzilla.gnome.org/show_bug.cgi?id=760188
We are setting mime data with a destroy notify on the cairo
surface to get notified when cairo registers damage for the
surface (in that case, it clears the mime data, calling the
destroy notify). Unfortunately, the destroy notify is also
called when we remove the mime data ourselves, which was
not intentional.
Use a flag in the window impl struct to ignore the callback
when we are clearing the hook.
The assumption that MIN() takes care of all infinities here
turns out to be wrong. We were getting inf and -nan for some
combinations of 0 width/height and corners, leading to invalid
matrices and cairo errors.
https://bugzilla.gnome.org/show_bug.cgi?id=759668
Instead of creating an intermediate pixbuf, just render
the window surface onto the new surface. Doing things this
way lets us avoid the cairo_surface_mark_dirty() call in
gdk_pixbuf_get_from_window(), which is not generally safe
to call on 'random' surfaces - it asserts that the surface
has no mime data attached, and the X11 backend uses mime
data for damage tracking purposes...
We destroy the widget that is wrapped around the drag window
when the object data on the drag context gets cleared. Destroying
the window before that happens leads to unpleasantries. E.g. we may
try to access the frame clock, which doesn't exist anymore, and
things go downhill from there. So, keep the window alive for
a little longer.
We destroy the widget that is wrapped around the drag window
when the object data on the drag context gets cleared. Destroying
the window before that happens leads to unpleasantries. E.g. we may
try to access the frame clock, which doesn't exist anymore, and
things go downhill from there. So, keep the window alive for
a little longer.
Renaming the files from -dark to -inverse makes it more obvious
that this is not a dark variant in the sense of the 'prefer-dark'
setting, but rather a separate theme (sharing the same CSS).
Replace the cursor-color and secondary-cursor-color style
properties with the caret-color and -gtk-secondary-caret-color
CSS properties.
For the 'auto' value of these properties, we keep the same
behavior that we used to have when the style properties are
not explicitly set.
This property is defined in http://www.w3.org/TR/css3-ui/#caret-color.
We also add a -gtk-secondary-caret-color property, since GTK+ has
supported differently colored split cursors in the past. Unlike
CSS, we don't support the weakly defined auto keyword, and just
use currentColor as the initial value.
X11 has the notions of "transient for group", and while it's an ICCCM
violation, it's commonly used and documented that a window manager
would treat a window with transient_for set to None to transient for all
windows of its group.
gtk uses this when an application sets a dialog type window but does not
specify an explicit transient.
While this works on X11, there is no such thing as groups in Wayland and
the closest equivalent which is set_parent() in xdg-shell takes only one
parent. This is what is used for modal dialogs.
To get something similar in behavior to what is available on X11, a
solution is to update the parent() of the dialogs without transient when
the active surface changes.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759161
Quite a few applications use GTK_WINDOW_POPUP to create various
temporary windows and place then on screen. That works fine on X11 but
on Wayland there is no global coordinate system for regular surfaces.
If the application is using a gdk temp window and set a parent with
gtk_window_transient_for(), the gdk wayland backend has all it needs to
create a subsurface that can be placed at will by the application.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759738
If the background is transparent, we can't use it for the input shape,
since that will be empty. Draw a box with rounded corners irectly
instead, in fully opaque black.
https://bugzilla.gnome.org/show_bug.cgi?id=759905
I misunderstood what the overlay is good for: We need to allocate
it the full size of the widget. since we are using it to render
a background gradient *over* the application-rendered color.
At the same time, save some 100 lines of code by using an icon
helper as gadget, instead of handling the icon manually.
gtk_render_content_path is expecting the full box dimensions,
not just the content area. So, add the border before calling it.
Note it is still possible to have some separation between the
color and the border, by setting padding.
Recent gettext has a feature to allow consumer projects to supply their
own string extraction rules for XML files, in ITS format.
Gettext still ships the rule for *.ui, but it would be better
maintained in the upstream project.
https://bugzilla.gnome.org/show_bug.cgi?id=760202
Transitioning between linear gradients like
linear-gradient(to top, yellow, green) and
linear-gradient(to left, yellow, green) was yielding
nonsensical results, with the gradient line jumping around
wildly. Fix this by falling back to stupid image interpolation
for these cases.
Always returning a left_ptr if we can't find anything better
broke firefox application-specific fallback for missing cursors.
Keep that working by only doing the fallback for the CSS cursor
names, not for things like hashes.
https://bugzilla.gnome.org/show_bug.cgi?id=760141
Always returning a left_ptr if we can't find anything better
broke firefox application-specific fallback for missing cursors.
Keep that working by only doing the fallback for the CSS cursor
names, not for things like hashes.
https://bugzilla.gnome.org/show_bug.cgi?id=760141
This tests that horizontal boxes flip their child nodes
according to text direction to maintain the left-to-right
ordering of child nodes for both text directions.
CSS nodes have a linear sibling relationship; this is supposed
to correspond to left-to-right placement in horizontal arrangements.
This commit explicitly sets the text direction to rtl if the
filename ends in .rtl.ui, so we can test differences in node
tree layout between text directions.
Follow the generally white background we use everywhere else.
This is not perfect, we get double borders when the search bar
is shown, as can be seen in gtk3-widget-factory.
Gadgets don't connect to style-changed for widget nodes, and
GtkImage uses its widget node for the icon helper. The visible
effect of this is that symbolic icons don't change color when
switching to the dark variant of Adwaita.
Fix this by manually invalidating the icon helper.
Instead of the weird PathElt struct, generate a quick-n-dirty parser
that parses CSS selectors into GtkWidgetPath elements.
Based on a patch by Benjamin Otte.
In https://bugzilla.gnome.org/show_bug.cgi?id=601425 the annotations
were changed to int as they not only take the predefined enum values
but also user defined values registered through gtk_icon_size_register()
As a result the typelib doesn't contain any information about
GtkIconSize for those arguments and the Python docstring only
shows the corresponding Python type "int".
This changes the argument docs to mention the type explicitly
so the Python doc generator can add a link to Gtk.IconSize
which contains the most useful predefined values.
https://bugzilla.gnome.org/show_bug.cgi?id=757411
The Visual Studio versions that we support supports locking functions in
their CRT, so support that to optimize things a bit. Also update the
config.h.win32.in so that its entries are more in line with the ones in
the autootols builds, and make sure that we use UNIX line endings.
Use a custom, empty theme and stop importing reset-to-defaults.css.
This avoids overwriting initial values, so our initial value
filtering works better.
Drop the custom style printing implementation in gtkcssnode.c and
instead reuse the existing gtk_css_style_print function, extending
it a bit to suit our needs.
Instead of computing values, just recognize initial values by
having no CSS section. Also do away with the show-initial flag, and
just always filter out initial values. The flag can come back when
it is needed.
The node declaration has all the information we are printing
here (except for visibility). At the same time, redo the format
to print the information in selector format, and indicate
(in)visibility by enclosing the selector in square brackets.
The previous way of manually juggling the visibility of the
labels doesn't work anymore, now that gadgets of invisible
widgets don't allocate space anymore.
This uses the same function for dumping CSS nodes and styles
as the CSS node test. It can be used to test aspects of inheritance
and matching, as well as initial values.
No actual tests yet.
Add a gtk_style_context_to_string function that can serialize
a CSS node or tree of nodes, optionally including CSS properties
as well.
This will be useful in writing tests.
It turns out we don't really need to use a separate gadget for the
infobar, if all we do is chaining up to the parent GtkBox which already
uses a gadget.
Just remove all the boilerplate.
The notion of a separator being wide or not does not make sense when a
theme can set any CSS property on it, and
separator-width/separator-height are on their way out for
min-width/min-height.
Instead, just rely on the CSS gadget; we can stop using wide-separators,
separator-height and separator-width, and at the same time deprecate the
space-size style property of GtkToolbar.
67ab00e01e removed the fake configure code in gtk_window_show() and
replaced it with a simple gtk_widget_realize(). The initial allocation
code in realize() only allocates the natural size or the last requested
size which now no longer is set, resulting in a too small first allocation.
This builds a configure request to compute the allocation size instead
which includes default size, CSD etc..
This problem could be seen in case of a GtkPaned in a GtkWindow with a
default size set and the pane position set as well. The first allocation
would be the natural size of the GtkPaned which would clamp the pane
position if too larg. Only the second allocation would fill the parent
window using the now wrong pane position.
https://bugzilla.gnome.org/show_bug.cgi?id=759705
In that case, code expects an arrow gadget to be present but we're not
creating it in every occurrence.
Fix it by ensuring there will be an arrow gadget when reserve_indicator
is TRUE.
GtkViewport currently tries to draw a background over the bin window.
The feature is a bit broken at the moment, as it does not take into
account padding that might have been set on the GtkViewport, but in
general it does not seem very useful, and goes somewhat against the CSS
box model where every widget/gadget is responsible to draw its own
background. For a fix, we could either have the viewport gain a "bin"
gadget, or we could stop drawing the background.
As it isn't clear that there are any users of this feature, stop drawing
the background; a client can achieve the same effect by drawing the
background on the widget inside the viewport itself.
As GtkCssNode has the visibility concept, it makes sense to mirror it in
gadgets.
Do what visibility does in widgets: Hidden gadgets can't be drawn or
allocated and request a 0x0 size.
Note that just like widgets, gadget visibility must not be changed in
size request, allocate or draw handlers.
GtkWidget::child-visible has no equivalent yet, code will have to
emulate that manually.
Previously, the ID was only set on the CSS node as a side-effect
of calling gtk_widget_get_style_context. This was showing up
in CSS style tests as nodes lacking their IDs.
The test needs to be updated for the renamed :dnd pseudo class.
We also need to add a .errors file for the deprecation errors
that we are now producing.
Putting the deprecated class behind the official variant does
not work for the case of :focus and :focused - we were matching
:focus and leave a dangling 'ed'. So, put the deprecated classes
before the official variant, and explicitly mark them as deprecated.
Split the CSS docs off from the GtkCssProvider docs and
give them their own chapter. Among other things, this commit
introduces more or less complete definitions of the syntax for
the supported selectors, a complete list of all supported
properties, and definitions for their values. This includes
documentation for GTK+-specific properties such as -gtk-icon-source.
I hadn't noticed the :drop() pseudo state in the CSS4 Selectors
spec when I added this a while ago. This commit renames
GTK_STATE_FLAG_DND to GTK_STATE_FLAG_DROP_ACTIVE and adds
:drop(active) as equivalent to the :dnd pseudo state.
We don't actually do anything when the label is not selectable
except for consuming the event, which breaks for instance titlebar
drags with labels that contain links. Simply deny the gesture in
that case to allow the event to bubble up normally.
https://bugzilla.gnome.org/show_bug.cgi?id=759798
... on older Visual Studio versions, where isinf() is not available, and
copy the isinf() implementation from gdk/fallback-c89.c to
gtk/fallback-c89.c.
gdk_widget_get_frame_clock can return NULL. In particular,
this can happen when the drag window is destroyed at the end
of a DND operation. Handle this gracefully when it happens.
This adds tests for animation-name, animation-duration,
animation-timing-function, animation-iteration-count,
animation-direction, animation-play-state, animation-delay
and animation-fill-mode.
we have to do some assumptions for css selectors limits for this
particular case, so for split headerbars to work correctly the
actual haderbars need not to have the titlebar class applied.
The gtk_builtin_icon_get_default_size_property returns a const char *,
in a way such that some compilers insist that something that is of a
pointer value be returned, so fix that by replacing 0 with NULL.
When clicking "Cancel" on the "Do you want to use GTK+ Inspector?"
dialog, unregister the update_debugging idle handler. Also, steal
reference to 'inspector_window' while gtk_destroy_widget(), to make
further gtk_window_update_debugging() calls as a no-op.
https://bugzilla.gnome.org/show_bug.cgi?id=759764
The GetSize callback *can* assume that minimum and natural are
non-NULL. Buy minimum_baseline and natural_baseline can and
will be NULL, so handle that. This was causing crashes e.g. in
pavucontrol.
applications with split headerbars has a container in the titlebar
slot so the .titlebar style there needs to be reset. Since we can't
go backward with selectors I assumed that any csd application
sports a headerbar hence relying on that styling and resetting
the .titlebar styleclass.
Move the gtk_css_gadget_allocate call before the
gtk_label_update_layout_width call. This fixes the
statusbar label in widget-factory page 2 coming
up fully ellipsized.
Transient nodes should not propagate style-changed signals
that can cause widgets to get reallocated. This was causing
treeviews and iconviews with pixbuf cells to be constantly
resized and redrawn.
Clearing the icon doesn't appear to be necessary with
todays code, and it has the unfortunate side-effect of
temoorarily hiding the icon's window, which breaks grabs
and makes us miss the button release event when the icon
is changed from a button press handler.
We're going to add back the original struct definition removed by
a6e4de28, because using the typedef breaks all sorts of things like
gtkmm and WebKit, and having separate struct definitions allows us to
change the types in GdkBorder from gint16s to gints without breaking
ABI.
Functions requiring CoInitialize are called just in two places:
- the filechooser thread which calls its own CoInitializeEx
- the dnd code
Moving CoInitialize in the dnd specific init is cleaner and
we can pair it with the corresponding CoUninitialize since
CoUninitialize should be called as many times as CoInitialize.
Note that it is ok to call this function multiple times, so it
will not break if another codepath will need it in the future.
The patch also replaces the deprecated CoInitialize with the
equivalent call to CoInitializeEx (already used in the filechooser).
Empty boxes end up setting the clip to { 0, 0, 0, 0}, so warning
for a width or height of 0 triggers false positives. Instead,
initialize the clip to clearly invalid values.
As part of this conversion, remove the hardcoded padding around
the label.
Unfortunately, we cannot use the main gadget for drawing the frame
decoration, since we want to draw a custom border instead of the
stock css border that gadgets insist on drawing for us. Therefore,
add an extra gadget with name border and use it just for rendering
the frame.
Otherwise the gtk_grab_remove() calls on widget destruction will happen
on the default window group, which may leave the real window group
of the popover with a dangling pointer if it is not the default one.
This could be seen on the inspector, open a popover in the properties
list and close the window with alt-F4.
Invisible nodes don't change the first/last-child status of the nodes
after/before them. That means we don't have to just check the state of
the adjacent node when modifying this state, but all their siblings
until we hit a visible node.
The same way, a node is not the first child if it has no previous
sibling, it is the first child if it has no previous visible sibling.
This is important for caching in the global lookup cache.
CSS min-width and min-height on the slider node fit this
perfectly. We still fall back to the slider-width and
slider-height style properties if the CSS properties are
not set.
In most places, we can do with the pointer/keyboard of the default seat
instead of the client pointer. We can also remove some code from
gdk_input_init() because we know for sure there's no floating devices to
care about here.
There's places where we still need to deal with floating devices, which are
unseen by seats. Ignore deprecations and keep using GdkDeviceManager until
we can forget about floating devices.
There's places where we still need to deal with floating devices, which are
unseen by seats. Ignore deprecations and keep using GdkDeviceManager until
we can forget about floating devices.
There's places where we still need to deal with floating devices, which are
unseen by seats. Ignore deprecations and keep using GdkDeviceManager until
we can forget about floating devices.
There's places where we don't set a seat yet, plus the places
outside GTK+ where events are created, we should warn and fall
back to the master device seat with these.
1e1064398c broke the build.
When I run make, I should make sure to run it in the right directory.
And not in the gtk/ subdirectory that will never build widget-factory...
The clipboard emit events after the button we connected it to was
already destroyed (on application close for example), so make sure we
don't try to use that dead button.
Gdk Wayland backend walks up the transient windows tree, but does not
check for cycles when doing so.
As a result, if two or more windows are transient to each other, the
Wayland gdk backend will enter an infinite loop.
While this is clearly a bug in the application, gtk+/gdk should be more
robust and handle such errors more gracefully.
To avoid looping infinitely at various point in the code, check for a
possible loop when setting the transient relationship and deny the
request to set a window transient for another if that would create a
loop.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759299
gdk_pixbuf_get_from_window() paints the given window onto a new cairo
surface. Create that new surface with the same device scale as the
window so that the result is not scaled down on hidpi screens.
This is similar to 657a43e (which was reverted), but doesn't modify the
behavior of gdk_pixbuf_get_from_surface().
https://bugzilla.gnome.org/show_bug.cgi?id=757147
When doing a gtk_widget_show_all() on the shortcuts window,
accelerators for both RTL and LTR directions are being shown.
Make sure that no-show-all is set by default on hidden shortcuts, and
updated if the widget direction changes.
https://bugzilla.gnome.org/show_bug.cgi?id=759541
This was causing problems in the case when only one of the paned
children is visible - we would use uninitialized memory, leading
to invalide clip regions. Concretely, the signal tab in the inspector
would sometimes not render at all.
Make min-width/height have preference over the set default size. This
allows shrinking the widget. The default size is only used if min-width
is not set (or explicitly set to 0.
Drop the margin misuse and use the border allocation of the
handle gadget. We use negative margins to make the border allocation
larger without pushing the paned children out.
Size of the progress element now grows also when it's close to 0 size.
Previously the size was clamped to the minimum size, now it starts
growing from the minimum size.
So for a 100px trough with a 10px min size progress, the sizes of the
progress element change like this:
old new
0% 10 10
5% 10 14
10% 10 19
20% 20 28
50% 50 55
100% 100 100
Our actions on ::device-removed only actually applied to master
pointers, so listening to GdkDisplay::seat-removed and operating
on the seat pointer is equivalent.
We were not supporting plural form of the available space, which
is a problem in some languages.
However in this case is kind of a difficult matter, since we use a
formatted string from glib with g_format_size.
To fix it, use the same behavior as g_format_size to decide when
it should be used a plural form or not.
https://bugzilla.gnome.org/show_bug.cgi?id=759491
gtk_css_node_insert_before/after can easily create cycles
which later lead to stack overflows. Even if we're not
catching all cycles here, at least we can detect obviously
invalid arguments, such as inserting a node next to itself.
This was already mostly done by inheritance from GtkCheckButton.
To complete it, stop using the draw_indicator vfunc for radio
buttons, and instead make the indicator gadget draw either a
check or radio.
Use a gadget for the button, and for the indicator.
A complication here is that GtkCheckButton (and
GtkRadioButton) have a totally different appearance
depending on the ::draw-indicator property. If an
indicator is not required, we just reuse the
GtkButton gadget.
This mostly works; some minor sizing issues left, e.g. cranking
up the indicator-size causes the checkbutton grid in testgtk
to overlap.
This removes some hairy code handling with borders and padding,
which may or may not be correct. The examples in testheightforwidth
all continue to work, and min-width now works for labels.
This gives us min-width/height support. Currently, the spinner
still has a hardcoded minimum size of 16 and doesn't grow beyond
32. We may want to revisit that at some point.
When things change in the iconhelper, queue a resize on the owner widget
so that it automatically resizes.
Only do this for iconhelpers that are used as gadgets though, not for
temporary helpers - and to check this, check if the node is transient.
A gadget is halfway between a widget and a CSS node. It's supposed to
provide the minimum convenicence around CSS nodes until we've figured
out how to integrate them with widgets.
Build the gtk-update-icon-cache, gtk-builder-tool and gtk-query-settings
tools and run gtk-update-icon-cache as part of the post-build
"installation" process.
Pointed out (and reminded) by Paolo Borelli in bug 759436 that we should
build, "install" and run gtk-update-icon-cache in the MSVC builds as well.
Constructing GtkCssStyleChange objects without styles is forbidden, so
don't do it. Instead untangle the callback from the actual update
function and call that untangled function directly.
When we reuse styles that didn't change across changes to the source
CSS, make sure we clear the caches. Otherwise child nodes will pick up
styles from the old source CSS.
We no longer need a grabbed seat, instead we'll just use the default
seat if this happens, not without first warning and recommending
gdk_seat_grab() for the operation.
https://bugzilla.gnome.org/show_bug.cgi?id=759309
This allows GDK to unset the grab itself. Also, make sure we unset
the "pointer emulating" touch on the device if this is the
pointer emulating sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=759309
GdkWaylandDeviceData conceptually gathers the data that belongs to
a seat, so it's been renamed (although the old typedef stays, plenty
of refactoring is due here...).
The methods in GdkSeatClass have also been implemented, the most
remarkable is ::grab, which ensures the grab is performed on all
the relevant "master" devices.
https://bugzilla.gnome.org/show_bug.cgi?id=759309
On some systems, the gtk settings are not used properly for wayland.
Indeed, g_settings_schema_source_get_default is used, and as the docs says it,
"all lookups performed against the default source should probably be done
recursively.".
https://bugzilla.gnome.org/show_bug.cgi?id=759409
Remove some now unused includes and dead code, and rename
gtk_drag_set_icon_window to gtk_drag_set_icon_widget_internal,
since it is no longer restricted to toplevel windows.
Under Wayland, the compositor does it, so there is no need
for us to move the window ourselves. For X11, we are now
doing the animation from the X11 backend. Trigger that by
calling gdk_drag_drop_done().
What changes here is that we have to keep the icon_window
alive for as long as the drag context exists. Use a weak
reference to do so.
Showing the drag cancel animation can be done in the X11
drag context implementation now that we hold the drag
window there, and have the start coordinates.
Since we can't control if and when the application destroys
the drag widget, we take a snapshot of the window contents
and display that during the animation. This should be good
enough for all practical purposes.
Add a variant of gdk_drag_begin that takes the start position
in addition to the device. All backend implementation have been
updated to accept (and ignore) the new arguments.
Subsequent commits will make use of the data in some backends.
In commit 2c61316677 we avoided emitting
the style-changed signal if no CSS property changed.
Unfortunately, this also caused CSS styles to not be updated when
animations started if those animations did not change any CSS value
immediately. In those cases the animation would just never start.
The obvious example was the spinner.
Catch the case where a CSS style did not change and don't emit the
style-changed signal in that case.
This saves not only the emission of the signal, but also doesn't cause
invalidation in child nodes, which would previously get a PARENT_STYLE
Instead of having old and new style, now have a GtkCssStyleChange opaque
object that will compute the changes you are interested in for you.
This simplifies change signal handlers quite a bit and avoids lots of
repeated computation in every signal handler.
We were only storing the dialog size on unmap, but resetting to the
stored default value more often, e.g. on focus-out. This was causing
the dialog to 'jump back' to its remembered size after the user
manually resized it, leading to frustration and bug reports.
Instead, save the dialog size on every ::size-allocate of the toplevel.
To avoid needlessly spamming dconf, only write the new value if it
changed.
In Wayland, the hotspot of a DND icon is set using the buffer offset in
wl_buffer.attach. To implement this, add a private API to cause the
next wl_surface.attach to offset the new buffer with a given offset.
Setting a DND icon hotspot sets this offset while also queuing a redraw
of the window to trigger the wl_surface.attach.
https://bugzilla.gnome.org/show_bug.cgi?id=759168
...in the process simplified the touch-selection styling, check
and radios not fixed there since I'm going to add proper osd assets
for those (istead of forcing the dark variant assets there as before).
The name gtk_text_*_begins_* was used only for begins_tag(). All other
similar functions use "starts": starts_line(), starts_word(), etc.
So for consistency, add gtk_text_iter_starts_tag() and deprecate
gtk_text_iter_begins_tag().
Also change (allow-none) to (nullable), to use the new annotation.
https://bugzilla.gnome.org/show_bug.cgi?id=759092
In Wayland, the hotspot of a DND icon is set using the buffer offset in
wl_buffer.attach. To implement this, add a private API to cause the
next wl_surface.attach to offset the new buffer with a given offset.
Setting a DND icon hotspot sets this offset while also queuing a redraw
of the window to trigger the wl_surface.attach.
https://bugzilla.gnome.org/show_bug.cgi?id=759168
Otherwise rounding errors fool the "tab under coordinates" checks on
crossing events, which will be triggered close enough to the window
rectangle if the pointer moves slowly enough.
With this, the tab_prelight() function correctly figures out we've
moved the pointer outside the tab area when called in
gtk_notebook_leave_notify().
https://bugzilla.gnome.org/show_bug.cgi?id=759091
After removal of the selectable header and separator from the combo box,
the method to update the menu sensitivity must be changed as it assumes
at least two items within each sub menu and contains special handling
for the separator. Removing this fixes bug #759079.
Since we're no longer doing geometry widgets, don't send
base size and increments to the window manager anymore either.
This avoids an ugly 2 pixel gap to the right and bottom of half-tiled
terminals under gnome-shell.
We were getting the "New Accelerator" text mixed with the
content of the underlying cell, since plain labels don't
have a background. Go back to putting the label in selected
state, and fix the theme to render that white-on-blue. This
was lost when we switched to using a selection sub-node.
Showing two lists in a paned was a bit awkward, and space was
getting too limited. Go back to showing just the node list at
first, and make the CSS properties available via a stack. At
the same time, add a right-click context menu to the node list
to make the name and class editing more easily available.
The gesture functionality was taken over by GtkShortcutsShortcut,
so this widget is no longer needed, and it never was in a stable
release, so lets get rid of it.
GtkFontChooserWidget is using a GThemedIcon in its template,
so we need to ensure that the type is registered before
loading it. This was causing the defaultvalue test to fail.
GtkStatusIcon tests don't work well under xwayland either, so just
skip them unconditionally.
GtkEntry now fails because the update of the im-module is no longer
deferred to an idle, and (gtk-im-simple) is not a valid module
name, so skip this property.
The subscript was affecting the vertical alignment too much,
so tweak the rendering of the L/R markers to avoid that. Also,
mark these as translatable.
Instead of creating an icon source, making sure no state is set and
therefore the icon-effect will be applied and then rendering that icon
source, just call the icon-effect apply function.
Also, the new way isn't deprecated.
On Wayland, for tooltips to work as expected, the type hint must be set
to tooltips, otherwise the popup window won't be translated as a
subsurface.
Fix the test do work as expected under Wayland.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=759018
In Gdk, a GdkOffscreenWindow parent has to be the root window. This is
problematic on Wayland because the root window doesn't necessary have the
right information with regard to scale factor.
This patch proposes to rely on the embedder, if available, to derive
surfaces as well as getting the scale factor.
https://bugzilla.gnome.org/show_bug.cgi?id=758936
Applying the client-side decorations in the configure routine greatly
increases the chances of having the right size for the GtkHEaderBar and
border shadows.
Yet, it may be possible that these sizes change at a later point in
time, if for example the GtkHeaderBar grows in height while adding new
controls.
Mention this possible pitfall in the documentation for
gtk_window_resize().
https://bugzilla.gnome.org/show_bug.cgi?id=756618
The entry code passes GTK_DEST_DEFAULT_HIGHLIGHT when setting
up the drop target, but that is ineffective because of the
custom drag_motion implementation. Instead, call
gtk_drag_[un]hightlight ourselves.
This borrows heavily from the CSS4 fonts draft's font-palette, currently
found at https://drafts.csswg.org/css-fonts-4/#font-palette-control
The palette is mainly meant to trigger invalidations when colors used for
symbolic icons change, to potentially allow extending supported colors
in symbolic icons and to recolor all colors of a symbolic icon, not just
the main one.
The syntax for the property goes like this:
Name: -gtk-icon-palette
Value: default | name <color> [ , name <color> ]*
Initial: default
Applies to: all elements with icons
Inherited: yes
Animatable: yes, each color animated separately
The property defines a list of named colors to be used when looking up
icons. If a name is not defined, the value of the current "color"
property is used. Which names are relevant depends on the icons in use.
Currently symbolic icons make use of the names "success", "warning" and
"error".
"default" is the current behavior of the GTK when coloring symbolic
icons and is equal to the string
success @success_color, warning @warning_color, error @error_color
Animation is crudely implemented by animating colors that are in both
palettes that are animated and otherwise keeping the color from the
palette that defined it. Note that this can cause a sharp cut at the
beginning or end of the animation when the color goes away and will
therefore be replaced with the color property.
You can see an example of animations at
http://gfycat.com/CautiousPeacefulIaerismetalmark
When we start a drag cancel animation, we can just keep the existing
window. The reset was only necessary to convert from cursor icon to
window and we removed the cursor handling.
Just like we did for the default size, that reduces the chances of
having the headerbar missing or wrongly sized when computing the client
side decorations controls.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
The Wayland dnd surface must remain in place until the drag
is over. Setting it directly as the hardcoded window of the
widget we construct carries the danger that it might get
destroyed prematurely, e.g. when the application calls
gtk_drag_set_icon_name more than once and we recreate the
widget.
Instead, create a dedicated toplevel, and reparent the widget
into it. To keep the code simple, we use the same approach
under X11 as well, and make it the responsibility of the
GDK dnd code to keep the window position updated. We already
pass the current pointer position to gdk_drag_motion, which
makes this very easy.
As a side-effect of these changes, it is now possible to use
non-toplevel widgets as drag icons.
https://bugzilla.gnome.org/show_bug.cgi?id=748763
If that sounds confusing, it's because GTK and CSS can sometimes not
agree on naming.
:active for CSS means that a button is currently pressed on an element.
And that is clearly not the case for spinning spinners.
This removes the dependency on state, which should be used for selection
CSS styles, not for actually applying them.
And image-effect does exactly what we want already, so we can start
using it.
The size of icons is a property that is relevant to who is rendering the
icon, not to the icon itself.
Example: Starting a DND operation from an entry icon should cause the
icon to resize (from the entr icon's size to the DND icon size).
Make gtk_icon_helper_ensure_surface() a private function that just
ensures the surface was loaded.
Add gtk_icon_helper_load_surface() that is called by the above function
and the dnd code to actually load the surface.
Just do the invalidation check once, there's no need to do it in every
branch of the switch.
Also remove useless checks: These functions will not be called if we
already have a rendered surface.
Just do the invalidation check once, there's no need to do it in every
branch of the switch.
Also remove useless checks: These functions will not be called if we
already have a rendered surface.
It seems this branch is not needed anymore. It was originally added in
1999 to support gtk_widget_realize(), but all those reasons seem
obsolete today.
Instead just call gtk_widget_realize().
If you end up at this commit when bisecting:
There is no bug that made me remove this code, it was purely meant to be
cleanup / dead code removal. I seem to have introduced a new bug or
bisecting wouldn't have let you here. So it seems we should just revert
this commit.
Under X11, popovers are always constrained to the toplevel
window. Under Wayland, they aren't. This commit adds a
property that allows to explicitly constrain popovers to
the toplevel, giving them the same behavior under Wayland
as under X11.
https://bugzilla.gnome.org/show_bug.cgi?id=757474
Widgets such as gtkfilechooser may be saving their size and position on
the unmap callback, if the client-side decoration header bar is removed
first, the reported size will be wrong.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
gdk-wayland backend would not re-configure a surface when its size and
scale match the known size and scale.
But there might be a pending xdg_surface_configure() that would revert
this change so we should re-configure even if the currently known
size/scale match, otherwise we may end up with a wrong size after the
xdg_surface_configure() is received.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=758901
If we "release" the button first, the drag will be eventually cancelled,
we must first signal GDK_DROP_FINISHED, and then release the button so
the success status prevails.
It doesn't make a lot of sense to have this stored as data offer data,
rather together with the source_targets array, which is what we're
poking here in the end.
https://bugzilla.gnome.org/show_bug.cgi?id=758713
Dissociate ownership from our maintenance of wl_data_source objects.
The only place where ownership must be updated together is
data_source.cancelled, for the other places GDK should take care of
setting up the right ownership, even if at a different order than
we'd expect here.
This fixes GTK+ apps on wayland being locally confused about the
current selection ownership. Because gtk_selection_add_targets()
results in a wl_data_source being created, and ownership being
updated right away, early callers of this will change the ownership
even if the widget it's being called on didn't explicitly request
the selection ownership yet.
https://bugzilla.gnome.org/show_bug.cgi?id=758660
'win.lines' contains the same content as the GtkTextBuffer, so to find
@match_start, forward_chars_with_skipping() is called with
skip_decomp=FALSE (the last parameter). So far so good.
On the other hand, the content 'lines' (the needle split in lines) is
casefolded and normalized for a case insensitive search. So,
forward_chars_with_skipping(..., skip_decomp=TRUE) must be called only
for the portion of text containing the needle.
Since 'start_tmp' contains the location at the start of the match, we
can simply begin at that location to find the end of the match.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=758698
Doing things the other way around seems to cause problems in
some cases where children want to do different things depending
on the window position.
https://bugzilla.gnome.org/show_bug.cgi?id=758563
Instead of just listing the return type of get_plus_button() and
get_minus_button() in the documentation, we can use the (type)
annotation to ensure that the introspection data reflects the actual
type of the returned widget.
Fix a regression introduced by:
commit 6866d1c widget: Make gtk_widget_queue_allocate() not resize
Where the dropdown menu in Firefox would not be relocated after the
toplevel window is moved.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=758609
While searching for the cause of bug 746745 it was discovered that one could
not set WS_EX_TOPMOST extended window style with SetWindowLong(),
but must use SetWindowPos() for that purpose.
This was never a problem most likely because it is highly unlikely for windows
to acquire/lose WS_EX_TOPMOST after they are created, by means other
than SetWindowPos() (which GTK does use to raise/lower windows and
set/remove keep_above), and because trying to set/unset WS_EX_TOPMOST with
SetWindowLong() results in WS_EX_TOPMOST merely not being set/unset (that is,
other styles are still set/unset within the same call and no error is
signalled).
https://bugzilla.gnome.org/show_bug.cgi?id=758483
Instead of having our own copy of the pointer gestures XML file, use
the one installed by wayland-protocols.
Since pointer gestures is an unstable protocol, it went through the
unstable protocol naming convention changes, which is reflected in this
commit.
https://bugzilla.gnome.org/show_bug.cgi?id=758634
Just like it happens for window dragging, we're likely to not see the
matching button release for this event, so we must reset the controller
manually here.
https://bugzilla.gnome.org/show_bug.cgi?id=758661
Before calling gdk_window_move_resize(), store the full configure
request, not just width and height.
Fixes firefox randomly losing position of its dropdown windows.
https://bugzilla.gnome.org/show_bug.cgi?id=758609
After the grab is finished, we would expect an enter event, and
GDK updating internally the cursor for that window and device.
This means there is no need at all to store it separately in the
backend.
As a side effect, animated cursors are now also possible on grab
icons.
https://bugzilla.gnome.org/show_bug.cgi?id=735847
The way master devices detach from their other master counterpart is
vulnerable to infinite recursion due to the way we first recurse on
the other device before clearing the pointer, this may happen if
that last reference to the other master device is held by the
device->associated field.
https://bugzilla.gnome.org/show_bug.cgi?id=732742
Other backends take care of the cairo surface destruction in
GdkWindow::destroy. We must do the same here, or the cairo_surface
and its corresponding wl_buffer are left dangling.
https://bugzilla.gnome.org/show_bug.cgi?id=747295
tracker:uri-is-descendant/parent has the unfortunate side effect of
rendering the collation mechanisms in the database useless, so those
require full table scans to be validated.
Performing these as pure string comparisons will perform much better,
as those allow the underlying sqlite to rely on its own collation
to perform the search, which can be significantly faster with many
elements in the database.
https://bugzilla.gnome.org/show_bug.cgi?id=758407
It turns out that it is nicer in glade to have just a single
widget that can show either a shortcut or a gesture, so make
GtkShortcutsShortcut do it both.
GtkShortcutsGesture is now redundant and will be removed before
the next stable release.
The current code in gtkshortcutswindow.c is good enough to
construct a widget once from a .ui file, but fails to handle
changes at runtime, as happen e.g. in glade. Fix this by
listening for changes to section-name and title.
This prevents normal application windows (and other kinds of windows)
from being moved up in Z-order to be above windows that have the
always-on-top bit set. Doing so would make the previously-normal windows
in question also always-on-top implicitly.
Windows that are already always-on-top will be restacked on top of other
always-on-top windows too.
https://bugzilla.gnome.org/show_bug.cgi?id=746745
Empty underlines are hard to make out. Since we get somewhat
unreliable section information from the CSS parser, we just
make sure that we always underline at least one character.
The builder syntax for tags was invalid here (why did this not
get flagged as error ?!). While we're at it, give the warning
underline a nice, orange color.
If the buffer of a cursor is NULL, for example if its an empty cursor,
just set the cursor surface to NULL as well. Not doing this we'll use
uninitialized hotspot coordinates, dimensions and scales.
https://bugzilla.gnome.org/show_bug.cgi?id=758025
We can't use up_panel and down_panel as differentiators for the buttons,
because these window system resources don't exist before realize().
Just use a one-off enum for this purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=758094
This GdkDragContext should be created even if we don't have pointer
capabilities. Make it created on add_seat(), and only set the device
on wl_seat.capabilities, so it can be set to either master pointer.
https://bugzilla.gnome.org/show_bug.cgi?id=741066
This is wrong by all accounts there, as we can do no tricks there to show
a "drag failed" animation, which is performed by the compositor itself
on wayland.
We use the high-level gdk_device_get_window_at_position() to figure
out the window, although this one actually tries to find out the
current window under the device coordinates, which might well fall
outside the window, so NULL is returned in those cases.
Fix this by using the lower level _gdk_device_window_at_position()
that will return the toplevel without further lookups, so is more
desirable here.
https://bugzilla.gnome.org/show_bug.cgi?id=758250
Now that we have multiple master pointers, this call may pick the wrong one.
Instead, pick the GdkWaylandDeviceData from the first device, and pick the
master pointer from there.
The common GDK code accounts for "pointer emulating" touch sequences to be
synchronized with the pointer position by the windowing system.
However on Wayland pointer and touch are completely independent, the backend
attempts to implement pointer emulation, but doesn't account for the
possible crossing events happening when the user switches from pointer to
touch or the opposite.
In order to fix this, and to ensure we don't have to interact with the
master pointer (which backs the wl_pointer), separate the touch interface
to have its own master pointer, and ensure crossing events are emitted on
it, so the picture of an "emulated pointer" is complete above the backend.
Inspired in a former patch by Jonny Lamb <jonnylamb@gnome.org>
https://bugzilla.gnome.org/show_bug.cgi?id=750845
The window button setup depends on properties of the toplevel window.
Instead of updating the setup on realize, do it when the toplevel
changes.
This makes sure that when a GtkHeaderBar is added to a window
all the widgets are present and get_preferred_height() will return
the height the widget will have when finally shown. This allows
the logic in gtkwindow to select the right window size so that
the content size will match the requested default size.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
Before the resulting window size would differ if the default size was set
before adding a headerbar vs after. Now the saved state is again the actual
requested size and it is adjusted at the time we request a window size.
https://bugzilla.gnome.org/show_bug.cgi?id=756618
GtkHeaderBar will not show the maximize button if the window in not of
type normal or not resizeable.
Use the same restriction for double-click actions as well.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=757530
Currently GtkStack has some G_PARAM_CONSTRUCT properties. That means,
the properties are set with its default value after the initializacion
of the object.
When using GtkBuilder to build objects, GtkBuilder creates them and
after that sets the properties found on the xml definition.
However, this is not true for templates because the template is initialized
in the init() function of the actual object, and after that, the construct
properties will be set.
This is a problem when someone wants to use templates with GtkStack and
set those properties, since they will be set on the tempalt initialization
and set again to its default values afterwards.
To fix this, make those properties not G_PARAM_CONSTRUCT.
https://bugzilla.gnome.org/show_bug.cgi?id=758086
There is no GNU Lesser General Public License version 2; it's either GNU
Library General Public License version 2, or GNU Lesser General Public
License version 2.1.
Copy-pasta from GPL instead of LGPL.
Also, there is no GNU Lesser General Public License version 2; either
it's the GNU Library General Public License version 2, or it's the GNU
Lesser General Public License version 2.1.
If the window has not yet been created, then we can't set the invisible
cursor yet. This can happen in situations where the widget is in a
revealer with type-to-search functionality.
An application may use gtk_window_get_size() to retrieve the current
window size and later reuse that size with
gtk_window_set_default_size().
gtk_window_set_default_size() and gtk_window_get_default_size() should
also take client side decorations offset into account.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
We were using that range for the extra buttons after left/right/middle,
while this is harmless for clients not handling extra buttons (we
used to translate those button events into scroll events in x11 anyway)
this will be unexpected for clients that do handle additional mouse
buttons themselves (eg. back/forward buttons present in some mice).
In order to remain compatible with X11, those need to be assigned from
button 8 onwards.
Also, include input.h, and stop using magic numbers here.
https://bugzilla.gnome.org/show_bug.cgi?id=758072
Commit 1266d15c4 also broke Xwayland, as it does the same trick
than VMWare pointers. Let's extend the heuristic to check for "pointer"
in the device name, what can possibly go wrong...
https://bugzilla.gnome.org/show_bug.cgi?id=757358
We currently just look for a master device with input source MOUSE.
After recent changes to the way input devices are classified, xwayland
on my system comes up with a virtual core pointer that has input
source TOUCHSCREEN. This was causing assertion failures. Be a little
more careful and accept a touchscreen as core pointer, if there is
no mouse.
Use G_PARAM_DEPRECATED with deprecated style properties.
This will make it easier to identify and remove such stale
properties from css, since it will now trigger warnings.
When loading a nonexisting CSS file using
gtk_css_provider_load_from_file() or gtk_css_provider_load_from_path()
we would emit the error using a NULL scanner. Don't do that, because
we'll have a NULL section in that case and error handlers don't like
that.
Testcase attached.
https://bugzilla.redhat.com/show_bug.cgi?id=1277959
VMWare seems to create mouse devices with abs axes which confuses
our detection of single-touch touchscreens. Those have though a
name we can match on ("VirtualPS/2 VMware VMMouse"), it should
be pretty safe to assume that no real touchscreens have "mouse"
in their name...
https://bugzilla.gnome.org/show_bug.cgi?id=757358
The prime example for direction-dependent shortcuts is using
<Alt>Left or <Alt>Right to go back. Support this by adding a
direction property to GtkShortcutsShortcut, and filtering by
the current text direction.
https://bugzilla.gnome.org/show_bug.cgi?id=757888
Getting the shadow width must not call gtk_style_context_set_state()
because that will invalidate the node and cause a style-updated emission
which can cause gtk_widget_queue_resize() calls.
And calling queue_resize() from get_preferred_size() essentially means
the size is permanently invalid because you invalidate it while
querying it.
This causes flickering of windows when going from/to backdrop state. To
avoid this we either need to fix the theme to not have different shadow
sizes in those cases or we need to ensure the window doesn't flicker in
the first place.
Only use the hard-coded build-time path given by X11_PREFIX on X11 and
Wayland where a X11 package is normally available. On other platforms,
get the datadir of the running system and mimic the behavior by
constructing the path dynamically. This avoids hardcoding the path for
searching for compose tables where we want to have relocatability.
This fixes the build on Windows/MSVC as well, where we don't normally have
any X11 packages available.
https://bugzilla.gnome.org/show_bug.cgi?id=757984
Since we are now interpreting button press events and
make our own double-click determination, we should not
handle double-click events that are generated by GDK.
https://bugzilla.gnome.org/show_bug.cgi?id=757950
A follow up on the previous patch. We should use DestroyWindow
directly since it has a different calling convention than
the expected callback for g_clear_pointer
Adapt to the changes in the previous commit. In particular, fix
the handling of low and high offsets. Anything below the low offset
gets warning color, anything below high gets selected background,
and anything below the new full offset gets success color.
Avoid crashes when passing an invalid location to a
gtk_text_buffer_get_iter_at_*() function.
A first attempt added boolean return values to know if @iter has been set to
the exact location, but it breaks Python and JS bindings because the out
parameter is already a return value in those languages.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=735341
This reverts commit a9a1c00cc9.
Unfortunately, adding the boolean return broke both the python
and javascript bindings, since they now return a tuple consisting
of the boolean and the out argument.
glib-compile-resources have been updated to ensure that the symbols
generated are referred to, so that they will not be optimized out by the
linker in release builds. We can change from /opt:noref to /opt:ref,
which should improve optimization a bit.
This partially reverts de16a4e.
As we now ensure that items using GResources and GConstructors are always
referenced so that the linker does not optimize them out in a default
Release build, we no longer need to enforce the use of /LTCG, so
/LTCG:incremental will work as well.
Its very easy to get extra references to the NativeDialog so that
when you release your last reference any visible dialog is not
hidden. We handle this by adding a destroy method similar to how
you destroy regular toplevels.
It's not a hugely complicated file, but it's easier to deal with some of
the details of tooltip windows styling if we have a UI file to edit,
instead of source code.
Use the text CSS node for rendering text, and the selection node
for rendering selected text, avoid gtk_style_context_save, update
states of all CSS nodes, and use the proper states when querying
style properties.
Use a CSS node with name selection, like we do for entries
and labels. Unlike those widgets, we currently don't user
gtk_render_background, but just use the background color.
That will require more effort.
Calling gtk_render_background for each rectangle in the region
leads to suboptimal and sometimes weird results. Getting this
right requires more work in Pango first. Go back to just rendering
a single background, and clip it to the selection region. This
matches what GtkLabel does.
At the time gtk_window_move() or gtk_window_resize() get called, there
is no way to predict if a popup window will actually draw its shadow, so
applying an offset in this case may end up with a wrong size or
positioning for such windows.
Changing the logic in gtk_window_should_use_csd() as previously done to
address that issue will cause some other breakage as popup windows may
not draw a shadow but still need CSD.
So best is to actually apply client side decorations offset for regular,
top level windows only. This is actually a lot simpler and safer and
less likely to cause additional breakage.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
Adapt to the changes in the previous commit. Note that tooltip
appearance is currently affected by tooltips having lost their
csd nature, due to a regression.
* Cover letter
Having a single header file for all autocleanups definitions was a
reasonable stop-gap measure, but now GTK+ is starting to use G_DECLARE_*
macros. This means that every class using a G_DECLARE_* macro will need
to include "gtk.h" to avoid compiler warnings, which is not acceptable.
By moving the G_DEFINE_AUTO* use to the header that defines the type we
allow using the G_DECLARE_* macros without sacrificing the ability to
include only the needed files when deriving from a class.
* Commit
This commit changes all includes relative to GtkWindow to define their
own autocleanup macros.
When I added the draw_layer vfunc it accidentally got passed a cairo_t
that was configured with to draw in the viewport coordinate space (rather
than the buffer coordinate space). This makes things unnecessary complex,
because you have to convert between the two.
The pixel cache is shared between the text and the layers, so there is
no way to use draw_layer to get a stationary overlay effect. Thus it makes
much more sense for the draw_layer vfunc to draw in the buffer space.
Just changing this would break ABI for existing code, so this is fixed
by adding new layer types and deprecating the old ones.
Also, we use the new layer types to fix gtk3-widget-factory.
https://bugzilla.gnome.org/show_bug.cgi?id=757856
When moving/scrolling a child window we can't use the current clip
region to limit what is invalidated, because there may be a pixel
cache that listens for changes outside the clip region. Instead
invalidate the entire area and rely on the invalidation code to limit
the repaint to the actually visible area.
git commit a5b1cdd0 introduced a regression where CSD windows are not
resizable with metacity.
Reason being that metacity does not support "_GTK_FRAME_EXTENTS" and
therefore gtk_window_supports_client_shadow() would always return FALSE.
This explains why it works with window managers which support
"_GTK_FRAME_EXTENTS" such as mutter/gnome-shell or xfwm4.
Partially revert commit a5b1cdd0 to reinstate the logic in
get_shadow_width().
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=757805
It is not necessary for the users of this API, and causes things
to not work as intended. Without this transient node, styling
"notebook header tabs arrow" has the desired effect on notebook
arrows.
We were just catching the previous sibling before. Now we properly
invalidate all previous siblings (and also all other wiblings, but we
can think about optimizing that later).
Adapt to the new CSS nodes for trough rendering. This commit
also brings back visible fill-level rendering for scales, which
was not working for a while. The styling provided for that
(scale trough fill) is just a placeholder to aid in debugging
the implementation.
For now, always warn when
gtk_style_context_get()/get_padding()/get_margin()/get_border()
get called with the wrong state.
We used to hide this behind an env var because the warnings were
too frequent, but with the recent refactorings, this warning has become
rather important for detecting bugs.
If it's still problematic, we might want to revert this patch before
3.20.
This is a base class that essentially mirrors GtkDialog, but
it is not a GtkWindow, as the actual implemetation will be using
native code.
The base class has show and hide vfuncs, as well as a helper function
to run the dialog in a modal fashion.
This will be later used by the native file chooser dialog.
Before all GtkFileChooser implementations had to be a GtkWidget,
but we want to introduce one for native implementations that
is not a widget.
This is technically an ABI break, because some code could rely
on the guarantee that GtkFileChoosers are GtkWidgets and do
unchecked GtkWidget calls. However, that does seem unlikely,
and this has not really been documented anywhere.
The introduction of the trough node was not properly carried
into the code constructing stepper nodes, and was causing
assertion failures there. This was only showing up on Windows,
since Adwaita and HighContrast don't have steppers.
We were not queuing a draw (and not updating the CSS node) when
the slider visibility changed. This was exposed by the Trough
button in tests/testscale.
Fix this by taking slider visibility into account when deciding
whether to queue a draw in response to adjustment changes.
We only allocate a size to the currently visible child, so we obviously
need to rerun allocation when the visible child changes.
In the case where the stack is not homogenous, we also need to queue a
resize because our size request just changed.
Using lookup_icon() and lookup_by_gicon() with a size multiplied by a
scaling factor is almost certainly going to get worse results than using
their for_scale() variants.
A GdkPixbuf has no scaling factor, so drawing directly from it can only
using a scale of 1, to avoid blurry, fuzzy icons.
You should be using gtk_render_icon_surface() anyway.
We've by now disabled and then remved all of the tests that use these
functions because they never worked properly. So let's depecate these
functions before somebody starts using them.
It looks like the param spec for interpolate-size was
copied from the line above it, which is a read only property.
There is a setter for interpolate-size, and it is implemented in
set_property().
When setting the parent of a widget, queue_resize() on the widget will
be optimized away if the widget already had a resize queued.
Plus, we do not need to resize the widget as its size request is not
going to change.
This makes sure that hidden widgets always have priv->alloc_needed set
on them.
The constructor sets that flag, so we want to have it back when we
revert to this state.
This fixes GtkWindow skipping a size_allocate() when reshowing a
previously hidden window and thereby not updating its allocation and
clip. And that in turn would lead to draws not happening and us beig
left with a black window.
There was still style context saving in the draw function,
and the CSS node was not always properly updated and positioned.
Fix these things, and use the same CSS node for the arrow
drawing as well.
Similar to buttons-in-toolbars, it can make sense for listbox rows
to not take away the focus from the main application view, for
instance when used for navigation. Support this by taking the newly
added GtkWidget:focus-on-click property into account.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
The differences between the existing properties and the newly added
GtkWidget:focus-on-click property are minimal (different owner_type
in GParamSpec), so it is extremely unlikely that dropping the former
would break anything.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
There are currently three widget that implement such a property, and
there are other widgets for which the behavior can make sense. It
seems like a good time to add the property to GtkWidget itself so
subclasses can choose to respect it without adding their own property.
https://bugzilla.gnome.org/show_bug.cgi?id=757269
The list of popovers will specify the stacking order, a
_gtk_window_raise_popover() private call has been added so popover
widgets can request being on top.
Also, the stacking on popovers is ensured on gtk_window_size_allocate(),
after the size/stacking changes on the child widget have finished, this
will ensure popovers are kept on top of window contents.
https://bugzilla.gnome.org/show_bug.cgi?id=756670
Those won't have ABS_MT_* axes, so won't be reported has having
XITouchClassInfo. Fallback on these to checking whether abs x/y axes are
available. After the Wacom checks, any remaining device with absolute axes
should be touchscreens, and GDK_SOURCE_MOUSE does indeed just make sense on
devices with relative axes.
https://bugzilla.gnome.org/show_bug.cgi?id=757358
Previous commit 305b34a "GtkWindow: fix move/get position with CSD"
introduced a regression because some windows presumably use shadows but
actually don't, resulting in a negative offset being wrongly applied.
Problem is that get_shadow_width() would return non-zero shadows even
for windows that have no shadow, thus causing the negative offset.
Fix the logic in get_shadow_width() and gtk_window_should_use_csd() so
that get_shadow_width() returns accurate values.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
Use the element name menuitem for GtkMenuItem, GtkCheckMenuItem
and GtkRadioMenuItem. GtkSeparatorMenuItem gets the name separator.
Add a subnode with name arrow if a submenu is attached.
Give the radio and check menu items a subnode with name check or
radio.
Use the element name menu for the main node, and use two subnodes
with name arrow and style classes .top and .bottom for the arrows
of scrolling menus.
GtkMenu and GtkMenuBar, the two implementations of GtkMenuShell in GTK,
already draw it.
Furthermore, rendering a background here will overdraw any rendering
that the subclass will do, such as arrows for scrolling menus.
This is kind of a hack the way it's implemented, but it's necessary
for performance to ignore transient nodes as they get created all the
time (via gtk_style_context_save()) and invalidate the whole treeview.
And that causes resizes and redrawing of the treeview and performance of
the inspector would go down the drain now that we display a larger part
of the node tree.
Use combobox as the element name for the main CSS nodes of
GtkComboBox and GtkComboBoxText. Add the .combo style class
to the button and entry. in a GtkComboBox or GtkComboBoxText.
Unfortunately, GtkFileChooserButton is different from the other
pickers in that it is not a button, but rather has a button.
We ignore the difference for styling purposes, and just add
a .file style class to the button.
When the CSS style of a node changes, we want to display the new values
in the inspector.
This for example allows to see how styles update on hover or during
animations.
Instead of handling WM_DISPLAYCHANGE on every GdkWindow, only handle
it on an ad-hoc hidden window we create when opening the display.
This has two reasons:
1) we want emit the display::size-changed signal even if there are no
gtk windows currently open
2) we want to emit the signal just once and not once for every window
https://bugzilla.gnome.org/show_bug.cgi?id=757324
Use a .activatable style class on the color swatch and tie the
hover effect to it. The color editor simply removes this class
now to get an inert color swatch.
This is more flexible and lets us avoid referring to the
GtkColorEditor type in the theme.
Adapt to the new element names in the previous commit.
This also adds back a selected state which gets used
for when the focus is placed on the separator with F8,
just so this functionality is not forgotten.
The current situation is somewhat sad, with the path
label totally misaligned throughout the rows.
This is fixed by using a size group for the path labels,
so they all have the same allocated size (with the max
of 15 chars). Also, instead of hiding the eject button,
set it child-invisible, so it is hidden and yet it's size
is allocated by GtkBox.
https://bugzilla.gnome.org/show_bug.cgi?id=757303
Follow the same approach as used for the toggle button family:
Keep the button element name for button-like rendering, and
use a distinct modelbutton name otherwise, and add a subnode
for the indicator with name check or radio.
Convert GtkToggleButton and its subclasses to CSS nodes.
Keep the button element name for when we want to render
these button-like (but with .toggle, .check and .radio
style classes for differentiation).
When we want to render them with an indicator, use distinct
element names checkbutton and radiobutton, and add a subnode
for the indicator with name check or radio.
Mirror the behavior of gtk_widget_queue_resize() and always queue a
redraw. If we ever want to cause allocates without redraws we can add
gtk_widget_queue_allocate_no_redraw() then.
I had initially assumed gtk_widget_size_allocate() would take care of
queueing redraws, but it does not do that when neither size nor position
change. And that is obviously what's happening after
gtk_widget_queue_allocate().
Fixes buttons sometimes not redrawing (the record button in
widget-factory after locking it, all buttons when switching to the dark
theme).
We have to remove the page itself from the intermediate box
first, before removing the box from the notebook. Otherwise,
reffing the page to keep it alive is ineffective: the box
gets destroyed, and that destruction recurses over the page.
This fixes the problem in
https://bugzilla.gnome.org/show_bug.cgi?id=756385
This commit creates entry and button subnodes for the buttons
in GtkSpinButton. The nodes are ordered like this for horizontal
spinbutton
+ entry
+ image.left
+ image.right
+ progress
+ button.down
+ button.up
and like this for vertical ones:
spinbutton
+ button.down
+ entry
+ button.up
This arrangement requires cooperation from GtkEntry to place
the entry subnodes correctly, and some small changes in the theme.
This commit also fixes progress rendering in vertical spin buttons.
When gtk_widget_show() or gtk_widget_hide() is called, don't queue a
resize on the widget itself but on the parent.
The widget itself may already be marked as in need of a resize and
the call would be optimized out and never reach the parent.
The parent size will change though because a child widget just changed
its visibility.
Fixes a bunch of issues with menus appearing black, toolbas not hiding
in widget-factory and also various reftests.
This commit toggles the big switch. We now don't run size_allocate()
from the toplevel up anymore in cases where we don't need to.
Things might be broken in subtle ways as a result of this commit. We'll
have to find them and fix them.
Widgets that already have a resize queued don't need to walk the whole
parent chain and queue another resize. It's enough to do it once per
resize.
This also means that sizegroups cannot use the shortcut of just
invalidating the first widget in the group anymore. That widget might
already have a resize queued while others don't.
This happens way too much, so it's disabled unless GTK_DEBUG=geometry is
on.
Also, we can't detect it in the call to queue_resize() yet, only during
size_allocate(), so the warning comes after the signal emission.
... and API to set and unset it.
It is set when gtk_widget_queue_resize() is called.
It is unset when gtk_widget_get_preferred_width/height() is called.
So far it is not used.
Before this commit, a widget tree like this:
Window
AnyContainer (part of SizeGroup1)
GtkClutterEmbed
SomeWidget
when calling gtk_widget_queue_resize(SomeWidget), would invalidate
SizeGroup1, when it should have stopped at the GtkClutterEmbed (which is
a RESIZE_IMMEDIATE child).
This is so widgets can queue a rerun of their allocation logic, but
without triggering resizes everywhere.
For now, it just calls gtk_widget_queue_resize().
Ignore the geometry widget passed to gtk_window_set_geometry_hints().
Usind the widget itself was a hack that complicates the size request
machinery.
It is also incorrect in that it doesn't respect height-for-width.
Last but not least, it was only used by gnome-terminal and that
application can easily work without it.
And remove the API to set that variable.
If you want the entry to not fill its whole allocated area,
gtk_widget_set_valign (entry, GTK_ALIGN_FILL);
will give you the old behavior.
Make sure the wayland backend sets a new geometry when the client
resizes itself, otherwise the compositor won't be notified and may
revert to the old size on state changes.
Thanks to Jasper St. Pierre <jstpierre@mecheye.net> who pointed out the
problem in gtk+.
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=755051
When printing a "compound selector", make sure the name and universal
selectors are printed at the beginning and class, id, etc. selectors are
printed last.
If the svg pixbuf loader is not available, we end up with criticals
from gtk_css_image_icon_theme_draw because gtk_icon_info_load_symbolic
returns NULL without setting an error.
Avoid this by propagating the load error.
gdk_pixbuf_get_from_window() paints the given window onto a new cairo
surface. Create that new surface with the same device scale as the
window so that the result is not scaled down on hidpi screens.
https://bugzilla.gnome.org/show_bug.cgi?id=757147
Sadly, interned string properties cannot be handled generically
at all - GObject insists on inserting a strcpy in any attempt
to set a string property with generic api, destroying the
internedness of the string.
Therefore, we have to special-case GtkCssNode in the property
editor code :-(
This changes widget paths for widgets with a CSS name to return that CSS
name, now that we have added API for it.
This means that style properties are now matches using the CSS name.
Also fix the theme to use the correct name when matching style properties.
... and gtk_widget_path_iter_get_object_name(). This allows applications
that still use widget paths to use the new object names to get the
correct styling.
Mutter and webkit-gtk are examples here.
The search window of a tree view was implemented by showing without
making it visible by by positioning it outside the screen edge. This is
not possible on Wayland, so implement another method for being able to
enter text into a non-visible entry.
The new method is implemented by, before showing the window, pass the
key event directly to the IM context backing the entry. If the key
event triggered the context to commit new text or change the preedit
content, the search window is shown, and from that point the key events
are forwarded directly to the entry widget.
https://bugzilla.gnome.org/show_bug.cgi?id=756780
If a GtkMenu (or something else that is mapped as a xdg_popup) tries to
use a subsurface window as a parent, it will be terminated by the
compositor due to protocol violation. So to avoid this, if a parent
window is not a xdg_popup or xdg_surface, i.e. a wl_subsurface, then
traverse up the transient parents until we find the right popup parent.
https://bugzilla.gnome.org/show_bug.cgi?id=756780
Take into account and compensate for the size of the client side
decorations widgets in gtk_window_move() and gtk_window_get_pos()
including gravity.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
When client side decoration is used, the size passed to
gtk_window_resize() or retrieved from gtk_window_get_size() for top-
level windows also accounts for the client side decorations widgets
such as the title bar or the shadow borders.
Add up the size of these additional controls to the given size to get
the size expected.
Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756618
It makes sense that you should be able to type numbers that are
correctly formatted and parsable according to the current locale,
using just the keypad. This patch makes it so by translating
GDK_KEY_KP_Decimal to the decimal separator for the current locale,
instead of hardcoding a '.'.
https://bugzilla.gnome.org/show_bug.cgi?id=756751
gdkcursor-quartz.c uses the instancetype keyword, which doesn't seem to
be supported in the version of Objective C that Snow Leopard uses.
Replacing that keyword with the thing it represents makes it build.
Patch by Ryan Hendrickson,
http://bugzilla.gnome.org/show_bug.cgi?id=756770
gtk_inspector_object_tree_find_object accesses the type information
of the object, so we can't safely use it on an already decaying
object when we get a weak notify. Instead just walk the tree and
compare pointers, that is safe.
https://bugzilla.gnome.org/show_bug.cgi?id=756852
Create css nodes for icons in entries, with name image, and use
gtk_style_context_save_to_node() for them. We still set the
style classes .left and .right on them.
MSVC 2015 changed its default link-time code generation setting to
/LTCG:incremental, which causes problems if /opt:noref is to be used,
meaning that some code will be optimized out by the linker.
Avoid this situtation here by enforcing the use of /LTCG for MSVC 2010+
builds.
Use the new element names instead of the type name and style
classes.
Note that there is one problem with moving away from type names
here: it turns out that style properties only work if the selector
uses the type name.
See the previous commit for why this is necessary.
Also make gtk_widget_class_set_css_name work by looking at
the correct class for the name.
Note for future reference: GTK_WIDGET_GET_CLASS() does not
work in the instance init function.
The widget path machinery assumes that we always have types,
and without this change, it will start spewing warnings when
we start to introduce node names.
A GtkWindow's allocation includes the titlebar, borders, and shadows; we
only want to draw our custom alpha content over the child allocation of
the GtkWindow.
https://bugzilla.gnome.org/show_bug.cgi?id=756886
If a window is decorated, we need to draw the frame and shadow, even if
it is app-paintable - it's just nonsense to have a frame that we handle
events on, but expect the app to paint it. (We paint the titlebar in
any case.) If a client wants to handle all painting, it should use an
undecorated window.
https://bugzilla.gnome.org/show_bug.cgi?id=756886
This commit add some more keyboard shortcuts to gtk3-widget-factory,
and adds a help overlay documenting them. This examle uses the
automatic resource loading support in GtkApplication.
When the $(resource_prefix)/gtk/help-overlay.ui resource exists,
load a GtkShortcutsWindow from it for each GtkApplicationWindow,
and set up a win.show-help-overlay action with accels <Primary>F1
and <Primary>? to show it.
Tooltips tend to be placed on top of a parent surface with a given
relative coordinate, and without any input focus. So lets map them as
subsurfaces.
https://bugzilla.gnome.org/show_bug.cgi?id=756496
Restructure the mapping procedure so that its known up front what the
expected way mapping is to be done (subsurface, popup or stand alone),
and warn if it fails to actually map in such a way (for example a popup
without a parent or device grab, a tooltip without a parent).
https://bugzilla.gnome.org/show_bug.cgi?id=756496
This is a variable holding a ref to an object, so it is
a great case to use g_set_object and g_clear_object.
# Please enter the commit message for your changes. Lines starting
Use CHILD1/CHILD2 instead of 0 and 1, always use the same order and
don't check for child NULL-ness, because it will be done in
gtk_paned_set_child_visible anyways.
Avoid crashes when passing an invalid location to a
gtk_text_buffer_get_iter_at_*() function.
A boolean is returned to know if @iter has been set to the exact
location.
Unit tests are added.
https://bugzilla.gnome.org/show_bug.cgi?id=735341
When the search entry is shown, the 'special' nature of
., ~ and / should not trigger the location entry, because
that interrupts the search and is likely not what the
user intended.
https://bugzilla.gnome.org/show_bug.cgi?id=756505
Disclosure triangles are usually used pointing down, however
in this case the popover spawns in the upper direction, which
makes it odd looking.
Instead of pointing always down or up, point down when not toggled and
animate a rotation when toggled.
https://bugzilla.gnome.org/show_bug.cgi?id=756568
Since the change to use GtkPlacesView we don't want to show
internal storage on the sidebar.
In our case we were checking for drive_can_eject and
drive_is_media_removable.
However for some external hard drives it's reported that they
are not ejectable nor the have removable media. So the only
attribute that they have different from internal drives is that
they can be stopped.
So check for if the drive can be stopped to decide if it is
external or internal.
On the way realized we don't need to check for the mounts associated
with the volume to know if the volume can be ejected or not. So remove
that code.
https://bugzilla.gnome.org/show_bug.cgi?id=756589
It is assumed that border.top is the same than pointing_to.height (which
equals the strong cursor position), which is not since some time ago.
The border calculation has been move on top too, it is now used in the
Y position one, and doesn't depend on anything we calculate later.
Text handles are subsurfaces on wayland, so sort of their own toplevel.
This made gtk_widget_translate_coordinates() to bail out there, resulting
in text handles being mispositioned and jumpy. To fix this, translate to
toplevel GtkWindow coordinates manually, and translate coordinates from
there.
Along the way, the coordinates reported in ::handle-dragged have been
fixed so there is no small jumps in either axis (most noticeable in the
X axis when you started dragging, and in the Y axis when moving between
lines of different heights.
Make it what it is - the enum - so that that it is sure that the hint
will fit in the field. Without this, any hint that doesn't fit in 3
bits will be truncated to the 3 least significant bits, causing
unexpected behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=756496
Using a NULL GAppInfo with g_app_launch_context_get_display() will
generate a critical warning in gio.
Use the display name instead as we don't have any valid GAppInfo to pass
to g_app_launch_context_get_display().
bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=756439
Otherwise the popopver will be automatically unmapped in
_gtk_popover_update_child_visible() when the X axis (coming more
or less directly from events) goes outside the textview.
GDK_NOTIFY_ANCESTOR would happen when the pointer crosses across a direct
parent/child. However nonlinear events are more likely, specially when
the pointer moves across toplevels (either different apps, or menus being
popped up over the pointer position).
This makes popping up comboboxes and other menus that fall over the pointer
position possible. With the previous detail the GtkMenu code misinterpreted
the crossing event, making it think the button release coming right after
should dismiss the popup, which made menus just flash on the screen unless
you kept the button pressed.
Use $(GlibEtcInstallRoot) when invoking glib-compile-schemas, as CopyDir
is not GlibInstallRoot for GTK+ (due to quoting issues), meaning that the
glib-compile-schemas tool may not be found in certain cases.
Issue pointed out by Ignacio Casal Quinteiro.
we used to consider every button inside osd containers linked,
this is not true anymore, now those buttons behave normally.
This will clearly cause breakage in applications.
According to http://datatracker.ietf.org/doc/rfc2911/, The 'name'
attribute syntax is essentially the same as 'text', including the
REQUIRED support of UTF-8 except that the sequence of characters
is limited so that its encoded form MUST NOT exceed 255 (MAX) octets.
CUPS will not print jobs with names exceeding 255 characters.
https://bugzilla.gnome.org/show_bug.cgi?id=755988
Passing GTK_ICON_LOOKUP_GENERIC_FALLBACK to the icon lookup doesn't work
for GIcons, so we have to make sure we use the right GThemedIcon.
Fixes image-icon-name-use-fallback reftest.
After figuring out what the actual problem is, name the reftest
properly.
The actual problem is that the use-fallback property is ignored when
using an icon-name on GtkImage.
Fallback seems to be working in the GtkIconTheme test suite, but fails
in GtkImage itself.
This is a test for a bug in the Bluetooth settings. An icon named
"phone-apple-iphone" should fallback to "phone" if the
gnome-icon-theme-extras package isn't installed.
If the shared context is in legacy mode, or if the creation of a core
profile context failed, we fall back to an EGL context in compatibility
mode.
Since we're relying on a fairly new EGL implementation for Wayland, we
don't fall back to the older EGL API, and instead we always require the
EGL_KHR_create_context extension.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If GLX has support for the GLX_ARB_create_context_profile extension,
then we use the GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB; if it does
not, we fall back to the old glXCreateNewContext() API.
We use the shared GdkGLContext to decide whether the GLX context should
use the legacy bit or not.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If we're using modern GLSL, then we should stop using deprecated
modifiers, like 'varying' and 'attribute', as well as deprecated global
variables, like 'gl_FragColor'.
On the other hand, with legacy contexts we should be using older GLSL
shaders, to maximize compatibility.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
We want to have the ability to fall back to legacy GL contexts when
creating them. In order to do so, we need to store the legacy bit on the
GdkGLContext, as well as being able to query it.
Setting the legacy bit from outside GDK is not possible; we cannot
create GL contexts in 3.2 core profile *and* compatibility modes at the
same time, and if we allowed users to select the legacy mode themselves,
it would break the creation of the GdkWindow's paint GL context.
What we do allow is falling back to legacy GL context if the platform
does not support 3.2 core profiles — for instance, on older GPUs or
inside virtualized environments.
We are also going to use the legacy bit internally, to choose which GL
API we can use when drawing GL content.
https://bugzilla.gnome.org/show_bug.cgi?id=756142
If the last tag toggle is the end iter, the function returned the wrong
tag toggle.
This resulted in some bugs where the view wasn't relayout/redrawn
correctly.
The function also always returned TRUE, probably because the return
value is used nowhere. But for consistency with
_gtk_text_btree_get_iter_at_first_toggle(), it's better to keep the
return value, and also because otherwise the function would be wrong (it
doesn't always return a tag toggle, if there is none).
https://bugzilla.gnome.org/show_bug.cgi?id=755413
keyboard_handle_leave() might be called with a NULL surface resource
(for example if the surface was destroyed after the event was sent). If
so, we should still deal with the keyboard focus lost event, otherwise
we will both leak (the keyboard_focus GdkWindow reference) and miss
stopping the key repeat timer.
https://bugzilla.gnome.org/show_bug.cgi?id=755927
_gtk_accessibility_init() only gets called if the default
display changes, but in case gdk_init() is called before gtk_init()
the default display is already set and no property notification occurs.
This can happen quite easily in pygobject where
"from gi.repository import Gdk, Gtk"
will call gdk_init() followed by gtk_init() in the Python overrides.
This fixes it by checking for a default display in all cases.
Removing pages from the assistant with gtk_widget_destroy() used
to work. It broke with the recent interposition of a box between
each page and the notebook. Fix this by cleaning up when the box
child is removed.
https://bugzilla.gnome.org/show_bug.cgi?id=756042
In fact there were two issues:
1. GtkFlowBoxChild with "can-focus"==FALSE should pass the focus
to its child immediately.
2. GtkFlowBox with "can-focus"==FALSE should cease its custom keynav
implementation and fall back to the default GtkContainer behavior
which is more natural.
Thanks to these changes the flow box can act as a better replacement
for GtkGrid and similar containers.
https://bugzilla.gnome.org/show_bug.cgi?id=753371
Replace checking if the NSView is really a GdkWindow, which will crash
in the likely event it's not a GObject, with ensuring that the parent
GdkWindow is really a GdkWindowQuartz.
Move focus to list when search results appear to make it
possible to select the first search result by just hitting
Enter. To keep this from interfering with keynav, we need
to make sure that we still handle Escape to search. And when
search comes up empty, we need to move the focus back to the
entry.
https://bugzilla.gnome.org/show_bug.cgi?id=755926
The stack calls gtk_widget_grab_focus on the last focus widget,
which selects the text in the entry, so we need to make sure to
move the focus there first to keep that from happening.
https://bugzilla.gnome.org/show_bug.cgi?id=755931
Once a window is maximized/fullscreen, resize increments should be
ignored otherwise the window may appear smaller than the screen size.
That also applies to configure requests as well.
https://bugzilla.gnome.org/show_bug.cgi?id=751368
We were calling gtk_container_should_propagate_draw
twice for each child. We can avoid this by splitting
out an gtk_container_propagate_draw_internal function.
Almost all callers of _gtk_widget_draw already did their own
cairo_save/restore, so drop the save/restore calls inside
_gtk_widget_draw and instead fix the last caller, gtk_widget_draw,
to do the same.
Call gtk_popover_update_position instead which will pick up the new
transition_diff value and pass it on to
_gtk_window_set_popover_position, which in turn will move the window
correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
Check whether the given popover even changed size in
_gtk_window_set_popover_position. If not, just move its GdkWindow
without calling gtk_widget_queue_resize. Using popover_get_rect here is
still relatively costly, but popover_size_allocate would be doing that
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=755435
We can use gdk_window_peek_children here, instead of copying
the list. Note that we preserve the bottom-to-top ordering by
iterating the list from the end.
gdk_window_get_children_with_user_data was doing a list
reversal while filtering the list.
The string we were using is the representation of the internal text
in the popover entry. However that can be freed before setting the
bookmark label, if i.e. the row is destroyed and therefore the popover
as well.
To avoid that, duplicate the label in a local variable.
One of the consequences is that for those people using development version
we migth screwed its bookmarks file, since the bookmark manager wrote
garbage from the already freed label.
https://bugzilla.gnome.org/show_bug.cgi?id=755215
Update the notes that this is also used for Visual Studio 2015 support,
and correct the MSVC_VER_LONG for MSVC 2015, which is 14, not 2015.
Also add a note that this can be used for other projects that have
Visual Studio build support.
We are passing widget coordinates to gtk_text_view_window_to_buffer_coords()
which expects coordinates to be relative to the text window in this case.
This may result in drop coordinates being displaced if the side windows to
the top/left sides are visible and taking space, so the DnD indicator will
point to the wrong position.
This can be seen on gnome-builder and gedit when displaying line numbers.
Some distributions (MSYS2, Debian) call autoreconf on a tarball because
they change the autotools artifacts.
In order to rebuild the Broadway generated files, we need to ship the
scripts that we use when disting a release.
The row and rename popovers are always relative_to a row.
We also keep a pointer to them so we can interact with them in
callbacks.
However, if the row is destroyed its associated popovers will be
destroyed as well as relative_to destroyes and frees memory of its
associated widget when its relative_to widget is destroyed.
If we, for example, update the places while the popover is shown we are
going to access and invalid widget on the next time.
To avoid that, connect to the destroy signal of the popovers and clean
the sidebar pointers when that happens.
https://bugzilla.gnome.org/show_bug.cgi?id=755444
The patch did not check for Visual Studio 2008 correctly, plus it
would break the build on later Visual Studio versions, as it should
be __popcnt(), not __popcount(). Fix that.
The popcount builtin was added in GCC after version 4.2 (which is what
some *BSDs are using), which means we need to be more specific when
using it than just asking for GCC.
While we're at it, we can improve the compiler detection, and use a
builtin popcount on Clang ≥ 3.1 and MSVC 2008.
https://bugzilla.gnome.org/show_bug.cgi?id=755455
Instead of handling the horizontal and vertical peers separately
(and often, duplicatively), collect all peers in one go. At the
same time, avoid creating and destroying hash tables more often
than necessary.
The recent changes to build/win32/vs9|10/Makefile.am fixed 'make distclean'
but broke 'make -jN dist', so fix that by listing the *.headers and using
that list as a dependency and to remove those files in one single command
right after we generate the gtk-install.vsprops template, so that we don't
have to worry about them in 'make distclean'.
At the time we populate the model "initially" in constructed(),
it has already been filled and cleared a couple of times (we do
that every time one of the construct properties gets set). So
we can't assume that the model is empty, and have to clear it
first. Otherwise, we add duplicates to the list.
https://bugzilla.gnome.org/show_bug.cgi?id=748080
Plug and Socket require X11 windowing. Often times this is compiled
on systems with both wayland and x11, but not always. Quartz is an
example where it is usually not compiled.
GTK cannot depend on libcanberra-gtk which depends on GTK. This causes
a circular dependency and is especially neat if installed GTK is
different enough from uninstalled GTK.
The default event bubbling paths are prone to just running event controllers
even after the widget was potentially unrealized/destroyed in an event
handler callback, so bail out early if that's the case.
https://bugzilla.gnome.org/show_bug.cgi?id=755352
To GtkGesture machinery, if an event triggers a controller/gesture signal,
and gesture reset/cancellation as a result, the event has been managed
after all.
Commit e3bd895667 effectively changed the return value of the
wrapping gtk_event_controller_handle_event() function, which broke some
paths (eg. gtk_popover_button_press() wouldn't while the GTK+ grab was
active for this reason because the button press event was consumed early
on gtk_window_check_handle_wm_event()).
That patch is not too off-track given potential child widgets' behavior,
we want nonetheless to distinguish the denied vs cancelled paths here
(because GtkWindow itself relies on the GtkGesture behavior described in
the first paragraph on the begin_move/resize paths), so just reset
gestures after the event has already gone through the GtkEventController
so the return value is unaffected.
This updates the Visual Studio Project GUIDs so that they don't repeat with
the GTK+-2.24.x ones, as the 3.x projects can be used with the 2.24.x in a
all-in-one solution file (such as when one wants to use a complete GTK+2
and GTK+3 stack when porting Windows applications from GTK+2 to GTK+3), and
each project in a solution file is expected to have an unique GUID.
Traditionally a sequence is set to GTK_EVENT_SEQUENCE_DENIED state when
it is to be ignored, which means it is dormant, but still managed by the
gesture (accounting, "denied" sequences still make "slots" in multitouch
gesture busy, etc...).
This gesture will run for all button presses and releases in the window
though when presses happen on the "window content" region, and we can't
account for every children to be as educated as setting the proper mask
on every window, or ensuring events will be propagated as they should.
In order to cater for this, just reset the gestures, we can live without
such accounting in these specific GtkGestureSingle gestures.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
We do not know what happened to this surface outside of GDK.
Especially for foreign windows, they will have been modified
by external applications.
So be on the safe side and tell Cairo to clear all its caches.
https://bugzilla.gnome.org/show_bug.cgi?id=754952
Instead of using a fixed size, use a factor of the surface size. This
helps in situations where animations of surrounding widgets are used
and cause a rapid rate of surface destroy/create cycles.
gdk_wayland_device_update_window_cursor() is inconsistently returning
TRUE/FALSE, despite the timeout being always replaced for new cursor
frames. This could end up in these timeouts being "leaked" and running
as long as the window has an animated cursor.
Fix this by making it really sure we return G_SOURCE_REMOVE, although
now we keep track of animation delays, so the timeout will be reused
for constant time animations.
It makes no sense to skip denied sequences here, the gestures are
still carrying out the accounting for these, which must be also put
to an end if we're possibly not receiving any further events from
this sequence.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
At the time event_check_cancel_sequence_on_hierarchy() is called, the widget
has been already unparented. Given the widget itself is being destroyed,
cancellation on it is impending in one way or another, we still must
propagate cancellation across all parents, so retrieve it early before
possible widget destruction.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
Otherwise it's attempted through a timeout, which gets cancelled early after,
and the slider disappears after a while with no mouse activity despite the
ongoing implicit grab.
Once the grab is finished, check_update_scrollbar_proximity() will be called
again on both scrollbars, and the fade out animation will be triggered as a
result.
https://bugzilla.gnome.org/show_bug.cgi?id=754745
When right-clicking in an empty folder, you should get a context
menu, not a crash. The code for positioning the popover was not
handling the eventuality of no row under the pointer. Just position
the popover right at the click location in this case.
https://bugzilla.gnome.org/show_bug.cgi?id=755021
A lot of time was spend rendering the shadows on windows with CSD, in
particular the corner pieces, since they are the largest parts. This
patch catches this particular case and caches the pre-rendered blur
masks.
This makes the shadow code go from 25% to 8% of the time when resizing
gtk3-demo.
"Add" Visual Studio 2015 projects by what we did before: Copy the Visual
Studio 2010 project files and replace the items in there as needed, as
the formats of the 2010 and 2015 projects are largely the same.
We need to rename the projects so that when these projects are added
into an all-in-one solution file that will build the GTK+ 2/3 stack,
the names of the projects will not collide with the GTK+-2.x ones,
especially as GTK+-2.x and GTK+-3.x are done to co-exist on the same
system. This is due to the case that the MSVC projects are directly
carried over from the GTK+-2.x ones and was then updated for 3.x.
We still need to update the GUIDs of the projects, so that they won't
conflict with the GTK+-2.x ones.
Use the common automake module from the previous commit in the
Makefile.am's, which means that the Makefile.am's in gdk/ and gtk/ can be
cleaned up as a result. As a side effect, the property sheet that is used
to "install" the build results and headers can now be generated in terms of
the listing of headers to copy during 'make dist', where we can acquire
most of the list of headers to "install", so that we can largely avoid the
situation where the property sheet files are not updated in time for this,
causing missing headers when this build of GTK+ is being used.
Also use the Visual Studio Project file generation for the following
projects:
gtk3-demo
gtk3-demo-application
gtk3-icon-browser
gdk-win32
gdk-broadway
gail-util
So that the maintenace of these project files can be simplified as well.
https://bugzilla.gnome.org/show_bug.cgi?id=681965
This adds a common autotools module that can be used by various projects to
generate the Visual Studio projects as needed, and if necessary, generate
the headers listings to "install" for that project, based on items passed
in to this. This is modeled on the Makefile.introspection autotools file
that is used by many GNOME projects to generate the introspection files.
https://bugzilla.gnome.org/show_bug.cgi?id=681965
Initially the subsurface will be in synchronized mode and we will leave
it like this until the first time the parent surface has been committed.
The reason for this is because the subsurface position will be applied
as part of the parent surface state, and we need to synchronize the
initial position with the initial frame, so that we don't accidentally
draw the subsurface at the default position (0, 0) which would happen in
desynchronized mode if the subsurface content is committed before the
next parent surface commit.
https://bugzilla.gnome.org/show_bug.cgi?id=754839
The GtkEventController event mask is private, and set early by GtkGesture
implementations. Being this private data, there is no corresponding
property, so this code is a no-op, there is just no need to listen to
changes there.
We use to rely on grab broken events for most of the event sequence
lifetime, this breaks though on GDK_BUTTON_RELEASE/GDK_TOUCH_END, as there's
no longer a grab at that time.
For these cases (and all others where there's destroy/unrealize calls
involved during event dispatching), catch this on the late
WIDGET_REALIZED_FOR_EVENT calls on widget event handling functions.
https://bugzilla.gnome.org/show_bug.cgi?id=754098
This avoids a lot of overhead in the common case where a signal
is not connected and we're just using the class vfunc (which is true
for all in-libgtk widgets). Additionally it makes backtraces in
debuggers and profiles much much nicer to look at.
https://bugzilla.gnome.org/show_bug.cgi?id=754986
These days exposure happens only on the native windows (generally the
toplevel window) and is propagated down recursively. The expose event
is only useful for backwards compat, and in fact, for double buffered
widgets we totally ignore the event (and non-double buffering breaks
on wayland).
So, by not setting the mask we avoid emitting these events and then
later ignoring them.
We still keep it on eventbox, fixed and layout as these are used
in weird ways that want backwards compat.
There is no need to ref the windows we're ignoring, so collect and ref
only the affected child windows. Also, use a on-stack array rather
than allocating a linked list.
Also, we don't need to ref during the event emissions too, as we
already hold a ref.
https://bugzilla.gnome.org/show_bug.cgi?id=754687
It turns out that xgettext does not understand translatable="1",
so don't make gtk-builder-tool produce this, even though
GtkBuilder can parse it just fine.
https://bugzilla.gnome.org/show_bug.cgi?id=754928
This changes textview to share the style context with the pixelcache.
Doing so allows pixel cache to optimize the surface creation and use
a CAIRO_CONTENT_COLOR instead of CAIRO_CONTENT_COLOR_ALPHA when
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
We can take a fast path if the background for a widget is opaque by using
a CAIRO_CONTENT_COLOR instead of a CAIRO_CONTENT_COLOR_ALPHA surface. Most
blit'ing backends have a fast path for this, including Pixman and Quartz.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
This new private API, _gtk_style_context_is_background_opaque(), is meant to
be used by internal Gtk+ wigets to optimize fast paths for cases where
applicable. One such use would be to use a CAIRO_CONTENT_COLOR surface
instead of CAIRO_CONTENT_COLOR_ALPHA.
https://bugzilla.gnome.org/show_bug.cgi?id=754658
This avoids a bunch of allocations, and additionally it has better
cache behaviour, as we don't follow pointers to the separate GList
node memory areas during traversal.
From Christian Hergert:
This machine is a Retina mac book pro so I've been working on getting
GtkTextView (GtkPixelCache) up to our performance level on
X11/Wayland. I'm seeing a jump from about 43 FPS to about 50 FPS.
https://bugzilla.gnome.org/show_bug.cgi?id=754687
Merge it into GtkWidgetPrivate. In my measurements, about half
of all widgets have a non-default auxinfo struct, and we use this
information in size allocation, so it is nice to avoid the gdata
overhead.
We only use widget paths for a few widgets nowadays (notebook,
treeview, pathbar, combobox), so we can save some space by
not having this field in GtkWidgetPrivate.
The hash table is only accessed at creation and destruction time,
and many widgets don't use templates at all, so no need to have
this permanently occupying space.
This reverts commit 3eacfa88f2.
Apart from the patch not being correct, we don't want to expose private
structures in header files if we can avoid it.
And this type-checking overhead is not an optimization that is even
measurable.
https://bugzilla.gnome.org/show_bug.cgi?id=754932
Statistics for the gtk3-demo listbox example show that the
vast majority of calls to _gtk_allocated_bitmask_resize go
from a size of 2 to 2. Don't needlessly call realloc() in
this case.
The previous code was crashing when used as the returned classes array
would have been invalid after the first deletion. So if a 2nd class
would be deleted, invalid memory might have been referenced.
In order to retrieve the user options for a printer, the respective
printer name is used.
This fixes the comparison of printer names to avoid that the options of
another printer are accidently read whose name starts with the same
letters, but is longer (e.g. "myprinterlongername" instead of
"myprinter").
This fixes Bug 753628.
This function is getting called a lot. Statistics for the gtk3-demo
listbox example show most calls with 0-4 classes. Unrolling the cases
a bit brings the instruction count in callgrind from 93M to 52M.
The same trick that was applied to _gtk_css_change_for_child in
the previous commit can be applied to _gtk_css_change_for_sibling
as well, and that is what this commit does.
With both functions converted, gtk_css_change_translate is no
longer needed and gets dropped.
The function to translate GtkCssChange enum values to the PARENT
ones is called very frequently. This patch speeds it up tremendously.
The callgrind instruction count for this function in the listbox
demo goes from 108M to 7M.
My statistics show that more than half of all calls end up
with 0 matches, so we can avoid some overhead by not allocating
an array at all in this case.
We are dealing with really short lists here.
95% are < 10 matches, and the longest I've been able to record was 19.
So just do away with the hash table and do sorted insertion in
the array directly.
Otherwise the outer loop control variable is messed up, and we end
up with uninitialized axes if there were any more valuators after
the XIKeyClass one.
This bug was sneakily introduced by fdb9a8e14, many thanks to
Carlos Soriano for helping spot the source of this bug.
https://bugzilla.gnome.org/show_bug.cgi?id=753431
The logic here is that G_ENABLE_DEBUG is for compiling out
debug spew that can be triggered at runtime with the GTK_DEBUG
environment variable, while G_ENABLE_CONSISTENCY_CHECKS is for
consistency checks that are applied unconditionally.
Use a separate G_ENABLE_CONSISTENCY_CHECKS define to guard internal
consistency checks that are applied unconditionally if they are enabled,
such as the widget invariants checking. Interactive debug spew that can
be triggered at runtime with the GTK_DEBUG environment variable is still
guarded by the G_ENABLE_DEBUG define.
The mapping from enable-debug levels to defines is as follows:
yes: G_ENABLE_DEBUG G_ENABLE_CONSISTENCY_CHECKS
minimum: G_ENABLE_DEBUG G_DISABLE_CAST_CHECKS
no: G_DISABLE_CAST_CHECKS G_DISABLE_ASSERT G_DISABLE_CHECKS
The speed-up in 7da1f8a1ce was wrong in
certain conditions, even though it didn't trigger the existing
testsuite.
New testcase /bitmask/invert_range_hardcoded included.
Add a --run option which takes the name of an example and
launches it. Also add a --autoquit option which can be used
to quit after a given number of seconds.
If we are using gl for drawing, we don't have a shm surface,
so don't assert that we do. Instead, only call shm-specific
apis when they make sense.
This fixes a crash when showing popovers over a GtkGLArea,
as seen in gdkgears.
https://bugzilla.gnome.org/show_bug.cgi?id=754143
Instead, inherit style from toplevel (because that's the default way,
not because it makes lots of sense).
This way, popovers don't inherit the styling from the widget that popped
them up, which is a problem in selected listbox rows, selection-mode
headerbars.
It also doesn't inherit styling where we might want it, like the osd.
But we can only have one of the two things.
- reshuffled the stylesheet to easily allow having a thicker
border, but decided to keep the 1px borders on entries
as it makes easier to spot the buttons despite being flat.
https://bugzilla.gnome.org/show_bug.cgi?id=753129
If the position of the children is always relative to the box
then we should not take the allocation of the box into account
when flipping the children for RTL text direction.
This patch also removes unused assignments to child_allocation.
https://bugzilla.gnome.org/show_bug.cgi?id=754559
Same as we did for the entry in the previous commit.
Previously, we just hid the cursor if a key event was adding text,
but not when you used backspace, or Ctrl-V. Rearrange things so that
we obscure the cursor whenever the buffer contents change while we
are handling key events.
https://bugzilla.gnome.org/show_bug.cgi?id=754535
Previously, we just hid the cursor if a key event was adding text,
but not when you used backspace, or Ctrl-V. Rearrange things so that
we obscure the cursor whenever the buffer contents change while we
are handling key events.
https://bugzilla.gnome.org/show_bug.cgi?id=754535
When the places view is finalized before the network loading
is finished, the async operation is cancelled, and the callback
accesses the places view while it is already in a state of
disrepair. Avoid that access.
When receiving a selection or when a drag icon enter a window, it was
targeted at a specific window. Lets emit the GDK_OWNER_CHANGE event
only for this window, instead of broadcasting.
Broadcasting has some nasty side effects. For example, if there was n
GdkWindows, and one would for every "owner-change" signal handler
receive n signals about the owner being changed.
An example of where this went a bit out of hand was gnome-terminal,
which added one listener per terminal window. This meant that if
one had m number of terminal windows, each time any one would loose or
gain keyboard focus, O(m^2) owner-change events would be emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=754158
The purpose of this patch is to fix regressions in GtkTextView
scroll behaviours due to commit d138156.
( addition of padding and margins to the view )
Adding some padding is done by, for example, in inspector css tab with:
GtkTextView {
padding: 10px 10px 10px 10px;
}
and adding margins, by changing one of *-margin properties
( * standing for left/right/top/bottom ) or the corresponding
accessor functions.
Understand that none of these bugs are easy to trigger.
What's happened is that a old and wrong version of the code of the code
( lost in the mean time ) was pushed.
These bugs are best seen with wrap mode set to off.
The commit 8baab8f fix a first regression.
This one is about:
- Cursor going out of the view at line ends instead of being visible
or triggering the horizontal scroll.
- Padding not displayed correctly
when moving cursor at beginning/end of lines
- When horizontal scroll position not at left, cursor can make scroll
by more than one character (you need left padding to see this )
- Moving the cursor arround, the rendered text can be shitted in x or y.
( fixed by converting adjustment float values
to integer before calculations )
It can be observed by going down with the cursor more
than the view height then going up
- retval return value of _gtk_text_view_scroll_to_iter wrong in some cases
In addition, this patch re-factor priv->top_border
in screen_dest.y calculation
Of course, all GtkTextView and GtkSourceView based app were impacted
by these bugs ( gedit for example, see bug 754147 )
https://bugzilla.gnome.org/show_bug.cgi?id=753815https://bugzilla.gnome.org/show_bug.cgi?id=75815
This is a 'developer mode' feature, and it can and does interfere
with preexisting key bindings in some applications, so keep it
off by default in stable releases, at least.
http://bugzilla.gnome.org/show_bug.cgi?id=754115
Until now the code was not very clear about why the loading property is
needed, since we didn't forced all the async operations to mark the
view as loading. This cause that clients are not aware when the view
is busy on those situations.
For instance Nautilus uses the property for a few things, one of it
is to show a busy spinner on the tab title.
To improve the situation, mark as loading when a volume operation,
a mount operation or a connect to server operation is being performed.
https://bugzilla.gnome.org/show_bug.cgi?id=754150
We are showing a GtkSpinner on the networks header to provide feedback
to the user if we are fetching networks, therefore we have to modify
the spinner state when doing it.
However GtkListBox doesn't give guarantees about the widgets
set by gtk_list_box_set_header, and we could access an invalid
widget.
To avoid to access invalid widgets, bind the fetching networks
view property to the networks header spinner active property instead
of modifying directly the spinner in the private structure.
Not having the spinner in the private structure also makes the code
cleaner.
https://bugzilla.gnome.org/show_bug.cgi?id=754150
We were filtering out placeholders if the list box filters
while not searching, which is not what we want, since placeholders
should only be hidden if the view is searching.
https://bugzilla.gnome.org/show_bug.cgi?id=754150
The application demo had a "Blue" and a "Bold" menuitem both with
the Ctrl-B accel. This is confusing, since only one of them works.
Change the accelerator for bold to Ctrl-Shift-B, so they both work.
Make this function harmless to call without an open display connection.
This happens during gobject introspection, which instantiates GTK+
types without calling gtk_init.
It needs to open a display connection, which is obviously going to fail
miserably on any headless build machine.
Instead, we need to find where we started requiring to initialize GTK
when calling a get_type() function, and stop doing that.
This commit and commit 15cc85db29 fully
revert commit 6838861d26.
GCC will not do the right thing, and it will just break the build when
trying to include gtk.h first.
We'll have to live with the warning from the compiler about a missing
gtk_init() — though it would be better not to have to init GTK at all to
generate the introspection data.
This commit unbreaks the build in GNOME Continuous introduced by commit
6838861d26.
Having these extra spaces in the accel string is a bit awkward,
since they will be included in text decorations such as underlines.
Removing them has no visible effect.
Calling our get_type functions without prior gtk_init() is not ok,
and causes warnings now. Avoid that by teaching g-ir-scanner to
put a gtk_init() call into its generated code.
Otherwise, we end up using different metaphors in the place view
and in the sidebar, and nobody is going to know what the disconnect
icon means in this context.
http://bugzilla.gnome.org/show_bug.cgi?id=754022
The code in _gdk_wayland_window_dispose was not safe against
being called twice - it would call g_hash_table_destroy twice
on the known_globals hash table, the second time operating on
freed memory. It was also leaking the list of async_roundtrips.
After fixing both of these issues, the displayclose testcase
now works on Wayland.
We call gdk_wayland_window_hide_surface when the window gets
destroyed, and in this case, the frame clock might not exist
anymore.
This was showing up in the displayclose testcase.
While we do not have subwindows in Wayland, we do create an
artificial root window. When the display is closed, the root
window gets destroyed, causing recursing to be true for the
toplevel windows.
Since being 'activatable' istead of 'button' now that reset
is not needed anymore, the patch is pretty noisy since sass
interpreter changes, those look innocuous though.
A * selector applies to all widgets, so even GtkBox or GtkGrid - and
most importantly GtkListBoxRow - need to recompute their style because
of the * selector.
By using a more specific one, these common cases aren't affected
anymore.
Fixes slowdowns in gtk3-demo's listbox demo and in gnome-software.
That way, the GTK engine doesn't think that the general .button CSS
might potentially apply to it.
And because combobox button is overly complex and stupid, it cannot be
cached.
So buttons thought they cannot ever cache anything because they might
suddenly end up inside a combobox without noticing and then they'd need
to round their corners differently. Of course they're just regular
"Remove" buttons like all the other 100s of "Remove" buttons in
gnome-software. But hey, better not cache anything for them and
recompute their CSS every time the :hover state changes on one of the
rows.
We can actually share :first-child/:last-child related things now,
because we special case them. So the only positions we cannot cache are
nth-child/nth-last-child.
This should take care of a lot of Adwaita's styling.
This example populates a flow box with buttons, and makes the
flow box children unfocusable, with the intention that the focus
moves directly between the buttons. Currently, keynav does not
work at all in this case.
This way, we can live without row references.
A side effect is that opening the inspector on the gtk-demo list box
example now only takes 0.5s instead of the previous 3 minutes.
Instead of queueing a new idle handler every time we call
gtk_window_update_debugging(), only queue one if none is queued that.
Saves a lot of work, in particular when templates create context menus
for every row in a large listbox as in the gtk-demo listbox example.
Do not use .button anymore.
This is for 2 reasons:
1. The styling is seperate in our themes, so it doesn't make sense to
share the style class.
2. Due to the shared styling of .buton, listbox rows inherit all the
special case styles that exist for buttons - such as linked buttons,
header buttons, entry buttons, spinbutton buttons, etc. This means
that the code has to check all these special cases all the time and
for listbox rows, this is very slow.
Defer a11y initialization until we have a display. A11y initialization
causes widget classes to be initalized, which in turn needs some
backend-specific information about modifier masks that can't be
obtained before we have a display.
https://bugzilla.gnome.org/show_bug.cgi?id=736125
Add all 388 tweets of the @GTKtoolkit account. This shows the
performance behavior of the listbox (not good with that many rows) and
allows us to quickly notice when things get worse (or better).
And just so I have a place where I can dump how I generated this file:
First, I got Timm Bäder to download me the json for the twitter feed
into a file gtk.json, then I ran the jq tool on it like this:
jq ".[] | if .retweeted_status then .retweeted_status.user.name + \"|\"
+ .retweeted_status.user.screen_name else .user.name + \"|\" +
.user.screen_name end + \"|\" + .text" gtk.json | cat -n | sed
"s/\\s*\([0-9]*\)\t\"\(.*\)\"/\\1|\\2/" > messages.start
jq ".[] | .created_at" gtk.json | sed "s/\"\(.*\)\"/\1/" | while read
in; do date +%s -d "$in"; done > dates
jq ".[] | \"0|\" + if .retweeted_status then .user.screen_name else \"\"
end + \"|\" + (.favorite_count | tostring) + \"|\" + (.retweet_count |
tostring)" gtk.json | sed "s/\"\(.*\)\"/\\1/" > messages.end
paste -d\| messages.start dates messages.end > messages.txt
This whole machinery of going through 3 intermediate files was only
necessary to onvert the dates from ISO format to unix timestamps,
otherwise this could have been a single line.
If we manually enter an unaccessible path in the entry, e.g
"/root/foo.txt", we should receive an error saying that the
folder is not accessible instead of showing the replace
confirmation dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=753969
Previously we were assuming that only list box rows could occur
as focus children of a list box, and would crash if that wasn't
the case. This commit handles this case, and integrates focusable
headers into directional keynav and the focus chain.
The typical case of using separators as headers is not affected
by this change.
https://bugzilla.gnome.org/show_bug.cgi?id=753694
State that the overlays are placed wrt to the GtkOverlay, not
with respect to the main widget. This makes a difference for
small main widgets which are not configured to fill the entire
GtkOverlay.
When an operation is cancelled it's never safe to access
the object itself or the private struct, since it could be
called (and probably is) during finalize.
In case the operation is cancelled, just bail out to fix
the crashes.
Add a spinner when networks are being fetched and make
the network section permanent and show a placeholder with
a message that no networks were found in case there are no
networks. In this way users from previous versions won't be
confused with the fact that no networks are shown.
https://bugzilla.gnome.org/show_bug.cgi?id=753786
Previously we had a network item in the sidebar, which now
is replaced by the network section on other-locations view.
However we were not exposing the networks in network:///.
Fetch them and add them in the network section of other-locations
view.
https://bugzilla.gnome.org/show_bug.cgi?id=753786
As the protocol is still considered unstable (meaning not backward
compatible), we should, as stated in the protocol, only bind the version
advertised is the version we implement.
https://bugzilla.gnome.org/show_bug.cgi?id=753856
Code exists in the wild that calls this function after the widget has
been destroyed (and the pixel cache released). Simply check that the
pixel cache exists to preserve the existing state.
When you move line by line, only padding is
automaticly shown and you need to use Page key to show margin.
This commit also fix cursor going out of the screen bug.
The extra reference will be held from GdkEventPrivate data, so there's
a common place to all events. Without this, events queued after devices/
capabilities disappear (eg. on TTY switch) might hold invalid pointers.
Windowing level operations on those devices (queries, grabs...) are
expected to fail at that time, but we should hold meaningful data for
the regular event handling paths.
https://bugzilla.gnome.org/show_bug.cgi?id=753185
In order to play along with child widgets that use scroll events for anything
else than scrolling, it will be better to do this in the bubble phase, so
the child widget has an opportunity to GDK_EVENT_STOP the event before we
trigger kinetic scrolling.
This of course won't work for widgets that choose to reimplement scroll event
handling themselves, they should be smart at resorting to GtkScrolledWindow's
scroll event handling.
This fixes kinetic scrolling kicking in too pervasively on widgets that eg.
implement zoom on scroll events.
https://bugzilla.gnome.org/show_bug.cgi?id=753495
By assigning an URI to Other Locations item, we
can programaticaly select it. Fixes a bug in Nautilus,
where the Other Locations item is unselected imediately
after being clicked.
GtkPrintOperation was emitting paginate only if a signal was
connected, this meant that subclassing and overriding the
paginate vfunc lead to the unexpected result that paginate did
not run.
Instead we always emit the signal and use a custom accumulator:
if there is a signal we just run that and avoid the default
handler, otherwise we run the default handler which can be the
one by the subclass or the default handler that just skips
pagination.
Patch by Yevgen Muntyan, fixes#345345
Prior to this patch, the ID of the GtkApplication was always used for
clients which were GtkApplications. This would only be guaranteed to be
correct for D-Bus activatable programs. As a result, all
non-D-Bus-activatable applications would set the wrong ID making the
shell unable to find the corresponding .desktop file.
This change makes it so that the GDK backend always uses the name
passed to g_set_prgname, or the default value if not explicitly set, as
this more often corresponds to the .desktop file.
This means that in order to make D-Bus activatable applications set the
correct application ID, they must, for now, manually call
g_set_prgname() with their application ID (basename of the .desktop
file).
If g_get_prgname() returns NULL, fallback to gdk_get_program_class()
even though it will most likely never be correct according to the
xdg_surface.set_app_id specification.
https://bugzilla.gnome.org/show_bug.cgi?id=746435
We were not allowing to cancel the operation at all, and at
most the operation was cancelled only when clicked connect again.
Also due to gvfs bug 753735 we actually weren't cancelling
at all, and therefore creating multiple dialogs.
We don't want to leak references if the widget created to represent the
item in the model does not have a floating reference — which is usually
what happens in bindings, as they automatically sink references when
creating new instances.
See commit 6e03e7e8 for the similar change in GtkListBox.
Sorry, the last commit added a generated file instead of the
template.
G-I has been updated to not require a Windows GCC installation
anymore to generate the .gir files, so update the NMake Makefiles
that are used for this purpose.
As a result, it is no longer necessary to define time_t for the .gir
generation as we are on the same compiler throughout the process.
G-I has been updated to not require a Windows GCC installation
anymore to generate the .gir files, so update the NMake Makefiles
that are used for this purpose.
As a result, it is no longer necessary to define time_t for the .gir
generation as we are on the same compiler throughout the process.
GTK+ now uses pango_attr_foreground_alpha_new, pango_attr_background_alpha_new,
PANGO_ATTR_FOREGROUND_ALPHA, PANGO_ATTR_BACKGROUND_ALPHA,
pango_renderer_set_alpha, pango_renderer_get_alpha, which were all added
after 1.37.2.
wl_log() currently logs using G_LOG_LEVEL_ERROR
(which is fatal). The wayland client library doesn't
expect this behavior. It uses wl_log to log recoverable
errors.
This commit changes the log level to G_LOG_LEVEL_DEBUG
instead.
https://bugzilla.gnome.org/show_bug.cgi?id=753635
On wayland, the gestures protocol defines a wl_pointer_gestures global
object, that will match in number with wl_seats, swipe and pinch
interfaces can be obtained from it, which events are translated into
GdkEventTouchpadSwipe/Pinch events.
These will be mutually exclusive with touch events, so it won't
be possible to trigger gestures through mixed input and whatnot.
The accounting of touchpad events is slightly different, there
will be a single internal PointData struct, stored in the hashtable
with the NULL event sequence/key (same than pointer events in
this regard), just that the events stored will be GdkEventTouchpad*,
so will hold information about all fingers at once.
But this difference is just internal, the GtkGesture API doesn't
make explicit assumptions about the number of points (the closest
to a per-point query API is gtk_gesture_get_sequences()). All
signals emitted just contain the last changed GdkEventSequence,
and API takes GdkEventSequences, so everything is consistent with
sequence=NULL for touchpad events.
Along the code, we're basically asking for 1) the total count of
touchpoints, and 2) the number of active touchpoints (not denied
nor ended).
Wrap both usecases into a _gtk_gesture_get_n_physical_touchpoints(),
and replace all occurrences.
The gestures that don't want touchpad gesture events are majority,
even those that want such events will only listen to subsets (eg.
pinch, swipe,...).
So it makes sense to ignore touchpad events by default, and let
subclasses opt those in.
This will be used right before handle_event() in order to filter
out events, useful to make the previous "no touchpad events" behavior
the default, and have gesture subclasses include manually the touchpad
events they handle.
For all other events, we run the bubble phase deep in the specific
::motion/button-press/release/touch handlers.
For touchpad events, it doesn't make sense to use GtkWidgetClass
slots if the intended way to deal with these are gestures, so we
run the bubble phase directly from gtk_widget_event_internal().
Each gesture type has its separate GdkEvent struct, and begin/update/
end/cancel event types.
There is support for multi-finger swipe (3-4 fingers), and 2-finger
rotate/pinch gestures.
Do not call _gtk_icon_helper_clear explicitely when the properties
are set, since the corresponding _gtk_icon_helper_set_* method
already calls clear internally.
While at it rename the reset function to make it clear that it
is calling notify for the previous image type and avoid the
notification if the image type is not changing.
We have a testcolorchooser test, with a --edit option. It was
supposed to make the color chooser come up in edit mode, but
it didn't work ever since we dropped the ::response handler.
Fix it by resetting show-editor on unmap, instead of on map.
This way, users can set show-editor before showing the dialog,
and it will take effect.
Since we're dealing with networks, terms like "Eject" or
the eject button are misleading, since we're not actually
ejecting but disconnecting.
Fix that by showing the appropriate icon and tooltip.
We are not showing the URL of network locations
anymore, since they are distracting and not
necessary.
The code, however, forgot to cleanup the URL,
so we are still showing the URL for network
locations.
Fix that by properly cleanup the URL for network
locations.
The .button:link .label selector matches any label "inside" a
link button. And a label inside the context menu counts as inside
for this purpose. This causes the text-decoration property to
leak into the context menu, even though the property is not
inherited. Avoid this by tightening the selector to
.button:link > .label.
https://bugzilla.gnome.org/show_bug.cgi?id=753451
When we connect to a server, the default and expected
behavior is going to the default location, which usually
is the home directory or a writable directory.
GtkPlacesSidebar behaves properly, while GtkPlacesView
doesn't.
Fix that by jumping to the default locations instead of
the root location.
Don't use gtk_widget_show_all() on row widgets because that would
unconditionally show all of its children. This might be unwanted in case
the row implementation wants to keep some of its children hidden.
This commit changes it to use show() instead of show_all() and relies on
the row widget to control the visibility of its children itself as
appropriate.
https://bugzilla.gnome.org/show_bug.cgi?id=753392
GtkFileSystem has a complicated way to handle cancellables.
You keep the cancellable pointer that is returned by
_gtk_file_system_get_info and similar methods so that you can
cancel the operation, but you do not own a reference to it.
The only place where it is ok to unref a cancellable is in
your callback, which gets handed a cancellable that you need
to unref at the end. You are expected to compare it to the
pointer you stashed away to find out if the operation has
already been superseded by a newer call, in which case you
disregard the results.
GtkFileChooserButton was following these rules for most of
the cancellables it keeps around, but it was sometimes unreffing
the cancellables that are stored in the model, which could lead
to refcount confusion and crashes. This commit makes it follow
the rules for that case too, which fixes the crash in the bug
below, and does not show up any leaks in valgrind under light
testing.
https://bugzilla.gnome.org/show_bug.cgi?id=737804
The recent change to the enum declaration for GtkCssChange actually
relied on compiler-dependent behavior, which also breaks the build on
some non-GCC compilers, such as Visual Studio. As noted in the
G_STATIC_ASSERT line just beneath this declaration, we need to change
this enum declaration to #define's, in order to fix the build in such
situations.
https://bugzilla.gnome.org/show_bug.cgi?id=752814
2015-08-06 05:48:22 +08:00
1206 changed files with 231548 additions and 178853 deletions
# YourProject_HEADERS_EXCLUDES = ... # <list of headers to exclude from installation, separated by '|', wildcards allowed; use random unsed value if none>
#
# dist-hook: \ # (or add to it if it is already there, note the vs9 items will also call the vs10 items in the process)
1|GTK+ and friends|@GTKtoolkit|GTK+ 3.8.0 (STABLE) released: wayland, Multi-application Broadway, improved CSS support and more ... http://ur1.ca/d6yms #gtk #gtk3|1364338800|0||4|2
2|Daniel Svensson|@dsvensson|Bringing an application up to the new features in GTK 3.x = tons of negative diffs, awesome work by @GTKtoolkit devs <3|1382565600|0|GTK+ and friends|0|1
3|GTK+ and friends|@GTKtoolkit|GLib status update and a warning: http://ur1.ca/awsm1 #glib|1384383600
4|GTK+ and friends|@GTKtoolkit|GProperty status: http://ur1.ca/awslh #glib|1384383300
5|GTK+ and friends|@GTKtoolkit|GTK+ 3.6.2 (STABLE) available: http://ur1.ca/awsl2 #gtk #gtk3|1384383000
6|GTK+ and friends|@GTKtoolkit|GLib 2.34.2 (STABLE) available: http://ur1.ca/awskn #glib|1384383000
7|GTK+ and friends|@GTKtoolkit|GTK+ 3.6.0 (STABLE) released: http://ur1.ca/aj4e0 #gtk #gtk3|1381528800
8|GTK+ and friends|@GTKtoolkit|GLib 2.34.0 (STABLE) released: http://ur1.ca/aj4du #glib|1381522800
1|GTK+ and friends|GTKtoolkit|@breizhodrome yeah, that's for the OpenGL support that has been added recently|1416751697|0||2|1
2|Emmanuele Bassi|ebassi|RT @ebassi: embloggeration happened: http://t.co/9ukkNuSzuc — help out supporting GL on windows and macos in GTK+ 3.16.|1416086824|0|GTKtoolkit|0|9
3|Matthew Waters|ystreet00|RT @ystreet00: .@GTKtoolkit + @gstreamer integration using the new #gtk #opengl support https://t.co/IeBpFjbjes http://t.co/WptPHCfFIb|1416086780|0|GTKtoolkit|0|13
5|Allan Day|allanday|RT @allanday: New Human Interface Guidelines coming for @gnome and @GTKtoolkit . http://t.co/SMNndyo6rl|1408615736|0|GTKtoolkit|0|12
6|Christian Hergert|hergertme|RT @hergertme: being able to set opacity on an individual widget in gtk ... you've come a long way since 2.x days.|1408601183|0|GTKtoolkit|0|2
7|Richard Brown|sysrich|RT @sysrich: hmm, good thing Iike eating with chopsticks #GUADEC http://t.co/7aG9CYpdZg|1406543731|0|GTKtoolkit|0|82
8|Javier Jardón|jjardon|RT @jjardon: #GNOME 3.13.4 has just been released from Strasbourg, this year #GUADEC city. Enjoy! https://t.co/hgHDVOWvRC|1406303072|0|GTKtoolkit|0|6
9|GNOME|gnome|RT @gnome: This year's @guadec schedule has been published. Lots of great talks on there, as usual. https://t.co/rpGPxIRCuB|1405929795|0|GTKtoolkit|0|20
10|GTK+ and friends|GTKtoolkit|New features of GtkInspector : http://t.co/EOgcv1lh8D #gtk #gtk3|1402076874|0||2|3
11|The Valeyard|breizhodrome|RT @breizhodrome: @GTKtoolkit and his multipoint gesture, good thing for mobile applications :) #Gtk|1402076810|0|GTKtoolkit|0|1
12|GTK+ and friends|GTKtoolkit|@Gin_Cheng sorry about that, should be fixed now|1402076785|0||0|0
13|GTK+ and friends|GTKtoolkit|@teadriven sorry about that, should be fixed now|1402076751|0||0|0
15|GTK+ and friends|GTKtoolkit|Gtkparasite has been integrated in #GTK+: Introducing gtkinspector: http://t.co/dP3DzgPNM3 #gtk3|1400231807|0||8|11
16|GTK+ and friends|GTKtoolkit|GTK+ 3.12 released! Improvements in Wayland, Broadway, OSX ... New widgets: GtkFlowBox,GtkActionBar and GtkPopover: https://t.co/5hBIlfrxc3|1395842503|0||5|8
17|Javier Jardón|jjardon|RT @jjardon: Second beta of #GNOME 3.12 just released! https://t.co/8oTfZaatVr|1394147916|0|GTKtoolkit|0|3
18|Javier Jardón|jjardon|RT @jjardon: First beta of GNOME 3.12 (3.11.90) has just been released. Enjoy! https://t.co/d5wzYWXUnv #gnome|1393006697|0|GTKtoolkit|0|4
19|GTK+ and friends|GTKtoolkit|Some thoughts on portability by @desrt : http://t.co/zyFT6i4we3 #glib|1392903834|0||1|0
20|GTK+ and friends|GTKtoolkit|Popovers support merged in master: http://t.co/5JE0RLhEDo Thanks @garnacho for getting this done! #gtk3|1390500627|0||5|7
21|GTK+ and friends|GTKtoolkit|The continuous build environment now generates 64-bit #GTK+ Windows bundles! Read the announcement from @tarnyko : https://t.co/wXVOAzCYTt|1386169565|0||6|10
22|GTK+ and friends|GTKtoolkit|GTK+ 3 packages for Windows available! Thanks for the hard work of @tarnyko to make this possible!\nhttp://t.co/U9JgsGoBLm|1382633636|0||7|23
23|GTK+ and friends|GTKtoolkit|Status of support of high resolution displays in #GTK+ (and #GNOME ) http://t.co/SPQN2E6Qxo Thanks to Brion Vibber for the donation!|1372531560|0||2|3
24|Javier Jardón|jjardon|RT @jjardon: Firefox GTK+3 port ready for testing https://t.co/onpxJaTKO5 #gtk #gtk3|1371557291|0|GTKtoolkit|0|22
25|GTK+ and friends|GTKtoolkit|GTK+ 3.8.0 (STABLE) released: wayland, Multi-application Broadway, improved CSS support and more ... http://t.co/RlLmrNPyYs #gtk #gtk3|1364435230|0||0|5
26|Daniel Svensson|dsvensson|RT @dsvensson: Bringing an application up to the new features in GTK 3.x = tons of negative diffs, awesome work by @GTKtoolkit devs <3|1352906611|0|GTKtoolkit|0|3
27|GTK+ and friends|GTKtoolkit|GLib status update and a warning: http://t.co/quQP8dLf #glib|1352905826|0||1|1
28|GTK+ and friends|GTKtoolkit|GProperty status: http://t.co/Nk28V2Rh #glib|1352905797|0||1|1
29|GTK+ and friends|GTKtoolkit|GTK+ 3.6.2 (STABLE) available: http://t.co/ah87o7cC #gtk #gtk3|1352905768|0||1|2
30|GTK+ and friends|GTKtoolkit|GLib 2.34.2 (STABLE) available: http://t.co/yavkTJwr #glib|1352905722|0||2|1
31|GTK+ and friends|GTKtoolkit|GTK+ 3.6.0 (STABLE) released: http://t.co/3NDAT5K9 #gtk #gtk3|1350075620|0||0|4
32|GTK+ and friends|GTKtoolkit|GLib 2.34.0 (STABLE) released: http://t.co/eWRD7hNy #glib|1350075583|0||0|6
33|GTK+ and friends|GTKtoolkit|GLib 2.33.10 (UNSTABLE) released: http://t.co/3BCdOPDy #glib|1347299317|0||2|2
34|Javier Jardón|jjardon|RT @jjardon: GnomeGoals status update: https://t.co/q5j7mJ1c #gnome|1342143404|0|GTKtoolkit|0|1
35|Emmanuele Bassi|ebassi|RT @ebassi: Saturday, 28/07, 11:45 - I'll be talking about Rainbows and Unicorns @ GUADEC https://t.co/WOiF6QU6|1341984820|0|GTKtoolkit|0|2
36|Harvey|cd0|RT @cd0: According to the sourcecode zipball the browser in the samsung smart tvs (UNxxES8xxx) is webkit-gtk 20120109. Not bad. @GTKtoolkit|1341712733|0|GTKtoolkit|0|3
37|Claudio Saavedra|csaavedra|RT @csaavedra: Accelerated compositing in WebKitGTK+: http://t.co/yxl0BooF #webkit #gnome|1341712291|0|GTKtoolkit|0|2
38|GTK+ and friends|GTKtoolkit|GTK+ 3.5.6 (UNSTABLE) released, now featuring GtkSearchEntry and GtkMenuButton http://t.co/adHtm2OA #gtk #gtk3|1341689740|0||0|3
39|GTK+ and friends|GTKtoolkit|GTK+ 3.4.0 (STABLE) released: http://t.co/KPSfJQSg #gtk #gtk3|1332870781|0||0|17
41|GTK+ and friends|GTKtoolkit|Multitouch is near… by @garnacho http://t.co/68iK8m9S #gtk #gtk3|1327090575|0||1|7
42|GTK+ and friends|GTKtoolkit|@dylanmccall Follow this bug: https://t.co/9vCpBVSm|1326802580|0||0|0
43|GTK+ and friends|GTKtoolkit|@cd0 Nice. Please, report any issue next time ;)|1326802460|0||0|0
44|GTK+ and friends|GTKtoolkit|RFC: new features http://t.co/uiqYWx4O #gtk #gtk3|1326802266|0||1|2
45|GTK+ and friends|GTKtoolkit|@cd0 Did you file a bug?|1326776652|0||0|0
46|GTK+ and friends|GTKtoolkit|@dylanmccall You mean this? http://t.co/BXbocqE9|1326776459|0||0|0
47|GTK+ and friends|GTKtoolkit|@trufae https://t.co/xlq75hDL|1326776153|0||0|0
48|GTK+ and friends|GTKtoolkit|RFC: UI design: http://t.co/Lu8Gnnfg #gtk #gtk3|1326305191|0||2|2
49|GTK+ and friends|GTKtoolkit|#win32 users: GTK+ 2.24.8 bundles available here: http://t.co/WhuY2XoN It not needed to use 2.16 anymore #gtk|1323190462|0||1|4
50|GTK+ and friends|GTKtoolkit|RFC: Model-View-Controller http://t.co/Lmw4lW9V #gtk #gtk3|1321546108|0||1|1
51|GTK+ and friends|GTKtoolkit|RFC:boxes http://t.co/eZABFgTp #gtk #gtk3|1321546061|0||2|1
52|GTK+ and friends|GTKtoolkit|GTK+ 2.24.8 (stable) released: update of the win32 backend, it now works at least as well as the old 2.16.x http://t.co/6wrhs7hm #gtk|1321297367|0||0|2
53|GTK+ and friends|GTKtoolkit|GTK + #Clutter next step(s): http://t.co/UDIezbyW #gtk #gtk4|1318265984|0||3|4
54|GTK+ and friends|GTKtoolkit|Tutorial for #Python, #GStreamer and #GTK 3: http://t.co/hvfRx18E #gtk3|1317781925|0||5|0
55|GTK+ and friends|GTKtoolkit|@jonobacon nice, but pyGTK is deprecated, use pygobject instead|1317353873|0||1|0
56|GTK+ and friends|GTKtoolkit|GTK+ 3.2 (STABLE) released: http://t.co/EqHjTmol #gtk #gtk3|1317043650|0||0|11
57|GTK+ and friends|GTKtoolkit|New D-Bus features in GLib 2.30: http://t.co/rzHui2Q2 #gtk #glib|1316732697|0||3|4
58|Lanedo GmbH|LanedoTweets|RT @TimJanik: New #GTK+ building instructions for #Mac OS X now up in the #GNOME wiki: http://t.co/lLt2fb1B|1316646621|0|GTKtoolkit|0|3
59|GTK+ and friends|GTKtoolkit|GTK+ 3.1.90 (UNSTABLE) released: http://t.co/KRz34jp #gtk #gtk3|1315961535|0||0|3
60|Lanedo GmbH|LanedoTweets|RT @TimJanik: There's a Win32 security advisory for Gtk+, it's recommended to upgrade to latest Gtk+ (2.24.6) if you haven't yet: http:/ ...|1315914861|0|GTKtoolkit|0|5
61|GTK+ and friends|GTKtoolkit|GTK+ 4.0 and #Clutter 2.0: rainbows and unicorns: http://t.co/SKbl0vQ #gtk #gtk4|1314883483|0||2|14
62|GTK+ and friends|GTKtoolkit|Some #Glib plans for the next cycle: http://t.co/a6YybK0 #gtk|1314883427|0||0|3
63|Nat Friedman|natfriedman|RT @natfriedman: Any Gtk+ experts who want to make some consulting money fixing bugs in Gtk/Mac, email me: nat@xamarin.com.|1314355269|0|GTKtoolkit|0|28
64|Kristian Rietveld|krietvel|RT @krietvel: Blog post: 'Merged “treemodel-fix” branch into GTK+: call for testing, blog post series' http://t.co/yAUnneo #gtk|1314096198|0|GTKtoolkit|0|2
65|GTK+ and friends|GTKtoolkit|@ArcherSeven Help improving the patch here: http://t.co/r74hP79|1313493595|0||0|0
66|GTK+ and friends|GTKtoolkit|GTK+ 3.1.12 (UNSTABLE) released: http://t.co/3iPAlNq Try the new Font Dialog! #gtk #gtk3|1313493256|0||0|4
67|GTK+ and friends|GTKtoolkit|@cimi @DanielFore Patches always welcomed!|1313493010|0||0|0
68|GTK+ and friends|GTKtoolkit|a11y branch was merged into master: http://mail.gnome.org/archives/gtk-devel-list/2011-July/msg00004.html #gtk #gtk3|1309962425|0||0|2
69|GTK+ and friends|GTKtoolkit|Another update in the effort to improve #a11y in #gtk: http://mail.gnome.org/archives/gtk-devel-list/2011-June/msg00057.html #gtk3|1309606597|0||0|0
70|GTK+ and friends|GTKtoolkit|@cd0 What is wrong in that page? freetype already appears as a required dependency. Anyway patches always welcomed ;)|1307359139|0||0|0
71|GTK+ and friends|GTKtoolkit|Of course, everyone is welcomed to improve the #gtk website. git repo: http://ur1.ca/4bwbw bugzilla: http://ur1.ca/4bwc1|1307038767|0||0|1
72|GTK+ and friends|GTKtoolkit|Check out the new #gtk website!!: www.gtk.org|1307036644|0||0|4
73|GTK+ and friends|GTKtoolkit|@jikri Take a look to http://live.gnome.org/action/login/GTK+/Roadmap and http://developer.gnome.org/gtk3/stable/gtk-migrating-2-to-3.html|1306673774|0||0|0
74|GTK+ and friends|GTKtoolkit|Introducing Cossa, a GTK+ theme previewer for gedit, by @garnacho http://ur1.ca/4ate8 #gtk #gtk3|1306672611|0||1|5
75|GTK+ and friends|GTKtoolkit|#GProperty, new API for Property and Accessor declaration, by @ebassi : http://ur1.ca/47lgk #gtk #glib|1305717028|0||0|2
76|GTK+ and friends|GTKtoolkit|GLib 2.29.4 (UNSTABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2011-May/msg00012.html #gtk #glib|1304593138|0||0|2
77|GTK+ and friends|GTKtoolkit|RT @acruiz: Gtk+ FontSelection progress http://bit.ly/iikP2f #gtk #gtk3|1303089979|0||0|1
78|GTK+ and friends|GTKtoolkit|RT @krietvel: New blog post: CoreText backend now in Pango master http://bit.ly/dTE0a1 #gtk #pango #osx|1303089938|0||0|0
79|GTK+ and friends|GTKtoolkit|GTK+ 3.0.9 (STABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00087.html #gtk #gtk3|1302883958|0||0|0
80|GTK+ and friends|GTKtoolkit|GLib 2.28.6 (STABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00074.html #gtk #glib|1302780112|0||0|3
81|GTK+ and friends|GTKtoolkit|GTK+ 3.1.2 (UNSTABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00072.html #gtk #gtk3|1302737279|0||0|2
82|GTK+ and friends|GTKtoolkit|GLib 2.29.2 (UNSTABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00071.html #gtk #glib|1302702936|0||0|3
83|Kristian Høgsberg|hoegsberg|RT @hoegsberg: yay, merged the Wayland GTK+ backend to the master branch - no, it's still not compete.|1302621000|0|GTKtoolkit|0|9
84|GTK+ and friends|GTKtoolkit|Someone willing to help with the client side decorations branch? http://git.gnome.org/browse/gtk+/log/?h=client-side-decorations #gtk #gtk3|1302620918|0||1|1
85|GTK+ and friends|GTKtoolkit|#Wayland GTK+ backend merged in master: http://git.gnome.org/browse/gtk+/commit/?id=c7514e8f0d19a833257497caff413bb4dfae6eb4 #gtk #gtk3|1302620838|0||1|9
86|GTK+ and friends|GTKtoolkit|gtkmm 3.0.0 (STABLE) released: http://mail.gnome.org/archives/gtkmm-list/2011-April/msg00025.html #gtk #cpp|1302355894|0||0|3
87|GTK+ and friends|GTKtoolkit|RT @alex_igalia: WebKit2 MiniBrowser for the GTK+ port running! http://ur1.ca/3t3ov #gtk #webkit|1302261488|0||1|0
88|GTK+ and friends|GTKtoolkit|#GNOME3 is out, using all the power of #gtk3 , congrats everyone! #gtk #gnome|1302219444|0||0|2
89|GTK+ and friends|GTKtoolkit|HTML5 backend update, now with real toplevel windows!! http://blogs.gnome.org/alexl/2011/04/07/broadway-update-2/ #gtk #gtk3|1302218981|0||2|10
90|GTK+ and friends|GTKtoolkit|Glade 3.10 (STABLE) released: With support for GTK+3, pygobject and all the new stuff: http://ur1.ca/3s8wk #rad #gtk|1302032523|0||0|6
91|GTK+ and friends|GTKtoolkit|GTK+ 3.0.8 (STABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2011-April/msg00009.html #gtk #gtk3|1301878240|0||0|4
93|GTK+ and friends|GTKtoolkit|Benjamin Otte is improving GTK+ performance with some impressive results, check latest commits #gtk #gtk3|1301409776|0||1|2
94|Javier Jardón|jjardon|RT @jjardon: Also nice to see that a firefox GTK+3 port was started: https://bugzilla.mozilla.org/show_bug.cgi?id=627699 #gtk #gtk3 #fi ...|1301166992|0|GTKtoolkit|0|8
95|GTK+ and friends|GTKtoolkit|RT @krietvel: Oh yea, I still have to upstream the CoreText backend I wrote for Pango. Completely forgot about that. #gtk|1301149034|0||0|0
96|GTK+ and friends|GTKtoolkit|GTK+ 3.0.5 (STABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00099.html #gtk #gtk3|1300925808|0||0|1
97|GTK+ and friends|GTKtoolkit|Nice article of @cgwalters about analyzing memory use in #glib with #SystemTap: http://ur1.ca/3m0ak #gtk|1300672197|0||2|1
98|GTK+ and friends|GTKtoolkit|GLib 2.28.3 (STABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00065.html #gtk #glib|1300374677|0||0|2
99|GTK+ and friends|GTKtoolkit|GTK+ HTML backend merged: http://blogs.gnome.org/alexl/2011/03/15/gtk-html-backend-update/ #gtk #gtk3|1300334447|0||3|4
100|GTK+ and friends|GTKtoolkit|GTK+ 3.0.3 (STABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00059.html #gtk #gtk3|1300151113|0||0|5
101|GTK+ and friends|GTKtoolkit|PyGObject (new gobject introspection-based bindings) 2.28.0 (STABLE) released: http://ur1.ca/3fcsp #python #gtk|1299620983|0||0|1
102|GTK+ and friends|GTKtoolkit|GTK+ team meeting now in #gtk-devel on irc.gimp.net #gtk|1299615099|0||0|1
103|GTK+ and friends|GTKtoolkit|REMINDER: GTK+ Team IRC Meeting - 2011-03-08 at 20:00 UTC: http://ur1.ca/3ezpn Agenda: http://ur1.ca/3ezpp #gtk|1299517986|0||0|0
104|GTK+ and friends|GTKtoolkit|GTK+ 3.0.2 (STABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2011-March/msg00010.html #gtk|1299517909|0||1|3
105|GTK+ and friends|GTKtoolkit|PyGObject, the new Python introspection based bindings almost ready for the 2.28 stable release: http://ur1.ca/3dfaj #python #gtk|1299081554|0||0|5
106|GTK+ and friends|GTKtoolkit|GTK+ 3.0.1 (STABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00088.html #gtk|1298379744|0||0|4
107|GTK+ and friends|GTKtoolkit|More features/ideas for gtk+ 3.2: pictures: https://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00038.html #gtk|1297815657|0||1|2
108|GTK+ and friends|GTKtoolkit|New features/ideas for gtk+ 3.2: Translucent TextViews : http://blogs.gnome.org/tvb/2011/02/14/translucent-textviews/ #gtk|1297707521|0||1|2
109|GTK+ and friends|GTKtoolkit|Blog post of our tireless maintainer, Matthias Clasen: http://blogs.fedoraproject.org/wp/mclasen/2011/02/10/gtk-3-is-here/ #gtk #gtk3|1297378021|0||0|5
110|GTK+ and friends|GTKtoolkit|Highlights: Cairo-based, XI2, new theming API, Flexible geometry management, Multiple backend support for GDK, easy application support ...|1297373117|0||0|3
111|GTK+ and friends|GTKtoolkit|GTK+ 3.0 released!! : http://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00020.html gtk!|1297372977|0||1|20
112|GTK+ and friends|GTKtoolkit|GLib 2.28.0 (stable) released: https://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00014.html #gtk #glib|1297196093|0||0|2
113|GTK+ and friends|GTKtoolkit|GTK+ 2.99.3 released: latest beta before GTK+3 http://mail.gnome.org/archives/gtk-devel-list/2011-February/msg00004.html #gtk|1296609072|0||1|1
114|GTK+ and friends|GTKtoolkit|Glade 3.9.2 released: off screen, workspace new look, GtkComboBoxText, GtkFileFilter, GtkApplication and more! http://ur1.ca/335is #gtk #rad|1296608221|0||1|0
115|GTK+ and friends|GTKtoolkit|GTK+ 2.24 ( STABLE ) released: This will be the latest 2.x release. http://ur1.ca/32cft #gtk|1296438857|0||2|0
116|GTK+ and friends|GTKtoolkit|More progress on #Glade, the GTK+ #interface #designer: http://ur1.ca/2uzpa Note that Glade 3.8 -> #gtk2 and Glade 3.10-> #gtk3 #gtk|1295186227|0||0|2
117|GTK+ and friends|GTKtoolkit|RT @prcutler RT @fcrozat: First shot at GNOME3 evaluation usb stick : http://bit.ly/i1wM8X #gnome #gnome3 #gnome-shell #opensuse #gnome|1295186033|0||1|0
118|GTK+ and friends|GTKtoolkit|If you want to try the #wayland backend, checkout this branch: http://git.gnome.org/browse/gtk+/log/?h=gdk-backend-wayland #gtk|1294739562|0||1|5
119|GTK+ and friends|GTKtoolkit|GTK+ 2.99.1 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2011-January/msg00005.html #gtk|1294738413|0||0|0
120|GTK+ and friends|GTKtoolkit|GTK+ 2.99: It is now possible to include multiple GDK backends in a single library. Use --enable-{x11,win32,quartz}-backend #gtk|1294344201|0||0|0
121|GTK+ and friends|GTKtoolkit|GTK+ 2.99: The removal of GSEALEd struct members has been completed in this release #gtk|1294344070|0||0|1
122|GTK+ and friends|GTKtoolkit|GTK+ 2.99.0 (unstable) released http://mail.gnome.org/archives/gtk-devel-list/2011-January/msg00001.html #gtk|1294344044|0||0|2
123|GTK+ and friends|GTKtoolkit|GLib 2.27.90 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2011-January/msg00000.html #glib|1294343933|0||0|0
124|GTK+ and friends|GTKtoolkit|Glade 3.9.0 (unstalbe) released: snapshot leading up to Glade 3.10 that will depend on GTK+3 http://ur1.ca/2rir0 #gtk #rad|1294343894|0||0|1
125|GTK+ and friends|GTKtoolkit|Glade 3.7.3 (unstable) released: snapshot leading up to Glade 3.8 that\nwill depend on GTK+ 2.24 http://ur1.ca/2riqg #gtk|1294343835|0||0|0
126|GTK+ and friends|GTKtoolkit|RT @hoegsberg: Multi-backend support in GTK+: http://bit.ly/gDwugJ - switch between #Wayland and X11 by setting GDK_BACKEND #gtk|1294201849|0||0|0
127|GTK+ and friends|GTKtoolkit|RT @krietvel Blog post \"GDK 3.0 on Mac OS X\" http://bit.ly/ihr9kH or how GDK became awesome in GTK+ 3.0. #gtk #osx|1293728637|0||0|1
128|GTK+ and friends|GTKtoolkit|RT @krietvel Blog post \"Refactoring GtkTreeView using GtkCellArea\" http://bit.ly/g9aArE #gtk|1293728607|0||0|0
129|GTK+ and friends|GTKtoolkit|Also, the treeview-refactor branch has been merged too|1293036166|0||1|0
130|GTK+ and friends|GTKtoolkit|New in GTK+ 2.91.7: gdk-backend branch have been merged: the goal is allowing to build a single gdk library that contains multiple backends|1293036118|0||0|0
131|GTK+ and friends|GTKtoolkit|GTK+ 2.91.7 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-December/msg00155.html #gtk|1293035980|0||1|2
132|GTK+ and friends|GTKtoolkit|GTK+ 2.23.3 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-December/msg00156.html #gtk|1293035865|0||0|2
133|GTK+ and friends|GTKtoolkit|GLib 2.27.5 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-December/msg00152.html #gtk #glib|1293035786|0||0|0
134|GTK+ and friends|GTKtoolkit|Glade 3.7.2 (unstable) released: http://lists.ximian.com/pipermail/glade-devel/2010-December/001853.html #gtk #RAD|1292589571|0||0|0
135|Andrea Cimitan|cimi|RT @cimi: reading migration docs, later Murrine will start to be ported over GtkStyleContext (so CSS fun :))|1291813590|0|GTKtoolkit|0|1
136|GTK+ and friends|GTKtoolkit|Work to building multiple backends on the same system started: http://ur1.ca/2ieid #gtk|1291614285|0||0|2
137|GTK+ and friends|GTKtoolkit|RT @garnacho : gtk-style-context landed in GTK+ master, if gnome3 looks temporarily uglier that was me :) #gtk #gnome|1291613819|0||0|0
138|Stormy|storming|RT @storming: Anyone know of any call centers that use GNOME? Potential funding for a11y work if we do ...|1291387291|0|GTKtoolkit|0|4
139|GTK+ and friends|GTKtoolkit|Final part of the Benjamin Otte GTK3 rendering\ncleanup has landed: http://ur1.ca/2hrc9 #gtk|1291375493|0||0|0
142|GTK+ and friends|GTKtoolkit|GtkAppChooser landed in master: https://bugzilla.gnome.org/show_bug.cgi?id=582557#c10 #gtk|1291212784|0||0|0
143|GTK+ and friends|GTKtoolkit|larger changes in GTK+ soon: GtkStyleContext, rendering-cleanup, app-chooser branch, GtkRadioGroup branch, http://ur1.ca/2gs5u #gtk|1291211812|0||2|0
144|GTK+ and friends|GTKtoolkit|New widget: GtkSwitch http://blogs.fedoraproject.org/wp/mclasen/2010/11/29/onoff/ thanks to @ebassi and Matthias Clasen for the review #gtk|1291211711|0||2|1
145|GTK+ and friends|GTKtoolkit|GTK+ html backend (broadway branch) landed: http://mail.gnome.org/archives/gtk-devel-list/2010-November/msg00103.html #gtk|1291211452|0||0|1
146|GTK+ and friends|GTKtoolkit|GTK+ 2.91.5 (unstalbe) released: http://mail.gnome.org/archives/gtk-devel-list/2010-November/msg00109.html #gtk|1291211337|0||0|1
147|GTK+ and friends|GTKtoolkit|GLib 2.27.4 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-November/msg00108.html #gtk #glib|1291211331|0||0|0
148|GTK+ and friends|GTKtoolkit|ANNOUNCE: gtkmm 2.91.4 released: http://mail.gnome.org/archives/gtkmm-list/2010-November/msg00095.html #gtk #cplusplus #bindings|1290451737|0||0|0
149|GTK+ and friends|GTKtoolkit|Introducing GtkCellArea: height-for-width geometry management for GtkTreeViews http://ur1.ca/2e5pe #gtk|1290310899|0||1|2
151|GTK+ and friends|GTKtoolkit|WIP Porting guide to migrate from GTK+2 to GTK+3: http://ur1.ca/1xbzs #gtk #xfce #lxde #gnome|1290036396|0||4|6
152|GTK+ and friends|GTKtoolkit|#GSettings is fast (really): http://blogs.gnome.org/desrt/2010/11/15/gsettings-is-fast/ #gtk #glib|1289853926|0||1|2
153|GTK+ and friends|GTKtoolkit|Help making Glade ready for GTK+ 3: http://blogs.gnome.org/johannes/2010/11/15/help-making-glade-ready-for-3-0/ #gtk|1289853600|0||1|0
154|GTK+ and friends|GTKtoolkit|Anyone up to fix it? RT @vwduder: I wish #gtk wouldn't actually show the window until all of the contents have been rendered to the drawable|1289434823|0||0|0
155|GTK+ and friends|GTKtoolkit|PyGObject 2.27.0 (unstable) released: http://mail.gnome.org/archives/python-hackers-list/2010-November/msg00013.html #python #bindings #gtk|1289431671|0||0|0
156|GTK+ and friends|GTKtoolkit|glibmm 2.27.3 (unstable) released: http://mail.gnome.org/archives/gtkmm-list/2010-November/msg00058.html #glib #cplusplus #bindings|1289387769|0||0|0
157|GTK+ and friends|GTKtoolkit|GLib 2.27.3 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-November/msg00043.html #gtk #glib|1289322725|0||0|1
158|GTK+ and friends|GTKtoolkit|GTK+ 2.91.3 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-November/msg00010.html #gtk|1288758787|0||0|1
159|GTK+ and friends|GTKtoolkit|GLib 2.27.2 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-November/msg00002.html #gtk #glib|1288758720|0||0|0
160|GTK+ and friends|GTKtoolkit|Gtk 3.0 motto: \"We are fixing it!\"|1288630204|0||1|4
161|GTK+ and friends|GTKtoolkit|Recent Openismus contributions to @GtkToolkit http://bit.ly/amuAdX Thank you guys!|1288343314|0||0|0
162|GTK+ and friends|GTKtoolkit|ANNOUNCE: gtkmm 2.91.2 (unstable) released: http://mail.gnome.org/archives/gtkmm-list/2010-October/msg00058.html #gtk #cplusplus|1288098381|0||0|0
163|GTK+ and friends|GTKtoolkit|ANNOUNCE: glibmm (unstable) 2.27.1 released: http://mail.gnome.org/archives/gtkmm-list/2010-October/msg00059.html #gtk #cplusplus|1288098335|0||0|0
164|GTK+ and friends|GTKtoolkit|GTK+ 2.91.2 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00230.html #gtk|1288058960|0||0|0
165|GTK+ and friends|GTKtoolkit|GLib 2.27.1 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00222.html #gtk #glib|1288049934|0||0|1
166|GTK+ and friends|GTKtoolkit|@garnacho shows off 3.0 CSS awesomness as a result of his work at #gtkhackfest http://bit.ly/aV99F|1288015424|0||0|0
167|GTK+ and friends|GTKtoolkit|GtkGrid landed:new container similar to GtkTable without unnecessary restrictions.It does height-for-width geometry management. #gtkhackfest|1287759681|0||0|1
168|GTK+ and friends|GTKtoolkit|RT @bertogg: The GTK+ artillery: http://flic.kr/p/8M16nu http://flic.kr/p/8M16d7 #gtkhackfest #gtk|1287744902|0||0|0
169|GTK+ and friends|GTKtoolkit|GtkScrollable interface landed in master: http://git.gnome.org/browse/gtk+/commit/?id=55196a705f00564a44647bfc97981db0a783369a #gtk|1287744793|0||0|0
170|Kristian Rietveld|krietvel|RT @krietvel: Blogged on \"Optimizing legacy code\". Or \"Color space conversion is more expensive than you might think\". http://bit.ly/duA ...|1287711819|0|GTKtoolkit|0|1
171|GTK+ and friends|GTKtoolkit|Rounded corners in GtkEntry (thanks Boram Park!) http://ur1.ca/257f0 #gtk #gtkhackfest|1287711709|0||0|6
172|Berto Garcia|bertogg|RT @bertogg: Ryan and Benjamin discussing GtkStyle at the Hercules Tower #gtkhackfest http://twitgoo.com/1pw774|1287708209|0|GTKtoolkit|0|1
173|GTK+ and friends|GTKtoolkit|RT @bertogg Working late at night #gtkhackfest http://twitgoo.com/1pvw46 #gtk|1287602614|0||0|0
174|GTK+ and friends|GTKtoolkit|WIP docs of the new theme API : http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00134.html #gtkhackfest #gtk|1287564745|0||0|0
175|GTK+ and friends|GTKtoolkit|GtkApplication landed in master: http://ur1.ca/24fhe Feedback welcome #gtk #gtkhackfest|1287564609|0||0|0
176|Emmanuele Bassi|ebassi|RT @ebassi: lots of discussions at the #gtkhackfest - it's great to see the roadmap for 4.0 take shape|1287564383|0|GTKtoolkit|0|2
177|Berto Garcia|bertogg|RT @bertogg: Update from the GTK+ Hackfest 2010: http://blogs.igalia.com/berto/2010/10/19/gtk-hackfest-2010/ #gtkhackfest|1287564380|0|GTKtoolkit|0|3
178|Berto Garcia|bertogg|RT @bertogg: Photos from the #gtkhackfest in Coruña: http://www.flickr.com/photos/tags/gtkhackfest2010/ #igalia #gnome|1287564365|0|GTKtoolkit|0|2
179|GTK+ and friends|GTKtoolkit|ANNOUNCE: gtkmm 2.91.1 released: http://mail.gnome.org/archives/gtkmm-list/2010-October/msg00033.html #gtk #cplusplus|1287478956|0||1|0
180|GTK+ and friends|GTKtoolkit|The #gtkhackfest started today. Thanks a lot to the event sponsors: #igalia, #lanedo, #codethink and the #GNOME foundation.|1287447826|0||0|2
181|GTK+ and friends|GTKtoolkit|#gtkhackfest started today at the #igalia offices in A Coruña http://live.gnome.org/Hackfests/GTK2010 #gnome #gtk|1287422775|0||0|0
182|GTK+ and friends|GTKtoolkit|libnotify, gtk API changes in 2.91.1: http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00193.html #gtk #gnome #xfce #lxde|1287324866|0||0|0
183|GTK+ and friends|GTKtoolkit|GTK+ 2.91.1 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00127.html #gtk|1287324761|0||0|1
184|GTK+ and friends|GTKtoolkit|GTK+ 2.23.0 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-October/msg00128.html #gtk|1287324697|0||0|1
185|GTK+ and friends|GTKtoolkit|RT @bratschegnome: Backported gtk window resize grips to 2.x and posted to ppa:bratsche/gtk for any #ubuntu people who want to use/test it.|1287156390|0||0|1
186|GTK+ and friends|GTKtoolkit|Resize grip in all the GtkWindows now: http://blogs.fedoraproject.org/wp/mclasen/2010/10/09/getting-a-grip/ thanks to @bratschegnome #gtk|1286600672|0||0|1
187|GTK+ and friends|GTKtoolkit|@judsontwit You have some tips for porting here: http://live.gnome.org/PyGObject/IntrospectionPorting No many changes needed #python|1286298188|0||0|0
188|GTK+ and friends|GTKtoolkit|@UstunOzgur take a look here: http://live.gnome.org/PyGTK and here: http://live.gnome.org/PyGObject|1286297979|0||0|0
189|Kristian Rietveld|krietvel|RT @krietvel: Just pushed the last patch that finishes the transition of the OS X backend to the new rendering goodness. #gtk|1286297494|0|GTKtoolkit|0|1
190|GTK+ and friends|GTKtoolkit|ANNOUNCE: gtkmm 2.91.0 (#C++ bindings) released: http://mail.gnome.org/archives/gtkmm-list/2010-October/msg00000.html #gtk|1286128646|0||0|1
191|GTK+ and friends|GTKtoolkit|GTK+ 2.91.0 (unstable) released: http://ur1.ca/1xbzr The rendering cleanup work has landed. Porting guide here: http://ur1.ca/1xbzs #gtk|1286073059|0||0|0
192|GTK+ and friends|GTKtoolkit|Anyone up to the challenge of writing a WebP gdkpixbuf loader?|1285950573|0||0|3
193|Clutter Toolkit|cluttertoolkit|RT @cluttertoolkit: Clutter 1.4.0 - new stable release! grab it while it's hot, on www.clutter-project.org|1285731448|0|GTKtoolkit|0|10
194|GTK+ and friends|GTKtoolkit|We strongly recommend not using PyGTK for new projects and to port existing applications from #PyGTK to #PyGObject #python #gtk|1285721997|0||5|39
195|GTK+ and friends|GTKtoolkit|ANNOUNCE: PyGObject 2.26.0 released:http://mail.gnome.org/archives/python-hackers-list/2010-September/msg00019.html #gtk #python #bindings|1285721968|0||0|0
196|GTK+ and friends|GTKtoolkit|ANNOUNCE: GLib 2.26.0 (STABLE) released: http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00284.html #glib #gtk|1285721379|0||0|0
198|GTK+ and friends|GTKtoolkit|PyGTK 2.22.0 released: http://ur1.ca/1sc2n Note that new and existing PyGtk applications are recommended to use PyGObject|1285596826|0||0|0
199|GTK+ and friends|GTKtoolkit|GTK+ 2.22.0 ( STABLE ) released: http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00263.html #gtk|1285286958|0||2|5
200|GTK+ and friends|GTKtoolkit|Last call for the people interested in attending the #GTK+ hackfest in A Coruña: Please sign up at latest tomorrow! http://ur1.ca/1r2gt|1285255897|0||0|2
201|GTK+ and friends|GTKtoolkit|#GLib status update: GLib 2.25.17 and 2.27.0 released: http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00232.html #gtk|1285245997|0||0|0
202|GTK+ and friends|GTKtoolkit|Thoughts about #GtkTreeView refactoring: http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00260.html #gtk|1285245546|0||0|1
203|GTK+ and friends|GTKtoolkit|GTK+ 2.21.8 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00204.html #gtk|1284485086|0||0|0
204|GTK+ and friends|GTKtoolkit|New GObject API added: g_object_class_install_properties(), an efficient way to install properties: http://ur1.ca/1mh3s #gobject #glib #gtk|1284484816|0||0|0
205|GTK+ and friends|GTKtoolkit|legacy-free grid container proposed by @havocp: http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00089.html #gtk|1283965732|0||0|1
206|GTK+ and friends|GTKtoolkit|Minutes of the #GTK team meeting - 2010-09-07: http://mail.gnome.org/archives/gtk-devel-list/2010-September/msg00115.html|1283965715|0||0|0
207|GTK+ and friends|GTKtoolkit|New work to get #DirectFB backend in a good state, thanks Lionel Landwerlin! #gtk http://ur1.ca/1k0hx|1283965546|0||0|0
208|GTK+ and friends|GTKtoolkit|GTK+ 2.21.7 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00291.html #gtk|1283198533|0||0|0
209|GTK+ and friends|GTKtoolkit|GObject Introspection status: http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00254.html #gtk #glib|1282939837|0||1|2
210|GTK+ and friends|GTKtoolkit|GDateTime, the new time & date API just landed in Glib: https://bugzilla.gnome.org/show_bug.cgi?id=50076#c85 #gtk #glib|1282699797|0||0|1
211|GTK+ and friends|GTKtoolkit|CSS-like styling for #GTK+ thanks to Carlos Garnacho: http://blogs.gnome.org/carlosg/2010/08/23/css-like-styling-for-gtk/ #gtk|1282602303|0||0|3
212|GTK+ and friends|GTKtoolkit|RT @migueldeicaza: Gtk+ getting cascading stylesheets: http://blogs.gnome.org/carlosg/2010/08/23/css-like-styling-for-gtk/|1282594548|0||0|1
213|andreasn1|andreasn1|RT @andreasn1: ♺ @hbons: thanks to gtk+ maintainer mclasen we can now ditch icon-naming-utils :)|1282356193|0|GTKtoolkit|0|2
214|GTK+ and friends|GTKtoolkit|GTK+ schedule: glib 2.26 and #gtk+ 2.22 for #GNOME 2.32 (Sep'10). glib 2.28, gtk+ 2.24 and gtk+ 3.0 for Dec'10 http://ur1.ca/16o49|1282256544|0||0|0
215|GTK+ and friends|GTKtoolkit|@thomasvs I saw someone with an N900 in my lift yesterday, had the same thought|1282217985|0||0|0
216|Simón P.|spenap|RT @spenap: GObject Introspection has landed in Grilo! http://bit.ly/9f4DAa #mswl #igalia #pygobject #gobject-introspection|1282166595|0|GTKtoolkit|0|4
217|GTK+ and friends|GTKtoolkit|Minutes of the GTK+ Team Meeting - 2010-08-17: http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00155.html #gtk|1282094165|0||0|0
218|GTK+ and friends|GTKtoolkit|GTK+ 2.90.6 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00146.html #gtk|1282061092|0||0|0
219|Emmanuele Bassi|ebassi|RT @ebassi: http://bit.ly/9gabxR - @cluttertoolkit + gobject-introspection + pygobject. say goodbye to pyclutter!|1282043493|0|GTKtoolkit|0|3
220|GTK+ and friends|GTKtoolkit|GTK+ 2.21.6 (unstable) Relased: http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00127.html #gtk|1282006494|0||0|0
221|Stormy|storming|RT @storming: Novell is looking for a GNOME developer to work on SUSE Linux. http://linkd.in/bEAUUj|1282001084|0|GTKtoolkit|0|19
222|Tommi Komulainen|tko|RT @tko: I want my libglib-gslist.so and libglib-glist.so .. and some popcorn. maybe just popcorn|1282000936|0|GTKtoolkit|0|1
223|GTK+ and friends|GTKtoolkit|GLib 2.25.14 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00123.html #gtk|1282000398|0||0|0
224|Emmanuele Bassi|ebassi|RT @ebassi: I'm pretty pleased with the API that landed in json-glib for 0.12|1281810990|0|GTKtoolkit|0|1
225|GTK+ and friends|GTKtoolkit|The @ebassi implementation to support common licenses in about dialog has been added to #GTK: http://ur1.ca/11u5a|1281436699|0||0|0
226|GTK+ and friends|GTKtoolkit|Web inspector support lands in #WebKitGtk+ check the screencast demo http://blog.kov.eti.br/?p=118|1281376660|0||1|0
227|GTK+ and friends|GTKtoolkit|#GTK+ #Python developers are recommended to use the\nGObject-Introspection features available in PyGObject. http://live.gnome.org/PyGObject|1281362391|0||0|0
228|GTK+ and friends|GTKtoolkit|PyGTK 2.21.0 (unstable) released: http://ur1.ca/11gse . 2.22 will be the last release in the PyGTK series.|1281362089|0||0|0
229|GTK+ and friends|GTKtoolkit|#GTK+ Hackfest, October 18-22, A Coruña, Spain. http://ur1.ca/11f6u . Add yourself if you are interested in attending http://ur1.ca/11f6v|1281350218|0||0|4
230|GTK+ and friends|GTKtoolkit|Benjamin Otte's proposal for GTK+ drawing API: gtk_widget_draw(): http://ur1.ca/11f5m #gtk|1281350013|0||2|0
231|GTK+ and friends|GTKtoolkit|Some drawing APIs have been deprecated in GTK+ 2.22. Start porting your drawing to Cairo! http://ur1.ca/11f4t|1281349855|0||0|0
232|GTK+ and friends|GTKtoolkit|GLib 2.24.2 (stable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00057.html #gtk|1281349547|0||0|0
233|GTK+ and friends|GTKtoolkit|glib (unstable) 2.25.13 released: http://mail.gnome.org/archives/gtk-devel-list/2010-August/msg00052.html #gtk|1281201884|0||0|0
234|GTK+ and friends|GTKtoolkit|glib 2.25.12 is here! http://mail.gnome.org/archives/gtk-devel-list/2010-July/msg00052.html There have been many API changes in GDBus.|1280601329|0||0|0
235|Chema Casanova|txenoo|RT @txenoo: Dispoñible a foto de grupo de #guadeces2010 http://www.flickr.com/photos/davizin/4822344878/ gracias a David Cabrero|1280002637|0|GTKtoolkit|0|2
237|Alberto Ruiz|acruiz|RT @acruiz: Marker support in GtkScrollbar http://bit.ly/cKUTeW|1279580539|0|GTKtoolkit|0|2
238|GTK+ and friends|GTKtoolkit|RT @ebassi: today I moved #clutter-gtk to depend on #gtk3; tomorrow w I'll fix the double-events bug; on wednesday I'll rework the API|1279561116|0||0|0
239|Sandy Armstrong|sandyarmstrong|RT @sandyarmstrong: @awafaa gconf is obsolete, fool|1279301600|0|GTKtoolkit|0|1
240|Jonh Wendell|jwendell|RT @jwendell: #vinagre ported to GtkApplication :) !gtk|1279228583|0|GTKtoolkit|0|1
241|Clutter Toolkit|cluttertoolkit|RT @cluttertoolkit: #clutter 1.3.8 is the first snapshot with cally, the accessibility library for clutter apps and toolkits|1278972910|0|GTKtoolkit|0|4
242|GTK+ and friends|GTKtoolkit|GTK+ 2.90.5 released: http://mail.gnome.org/archives/gtk-devel-list/2010-July/msg00021.html #gtk|1278952963|0||0|0
243|GTK+ and friends|GTKtoolkit|Glib 2.25.11 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-July/msg00019.html #gtk|1278952925|0||0|0
244|Johan Dahlin|johandahlin|RT @johandahlin: New blog post: Using LLVM to speed up function invocation in a dynamic language binding http://bit.ly/dA6IjH|1278620689|0|GTKtoolkit|0|4
245|GTK+ and friends|GTKtoolkit|GTK+ bindings for #Falcon announced: http://mail.gnome.org/archives/gtk-list/2010-June/msg00183.html #gtk|1278000421|0||0|0
246|GTK+ and friends|GTKtoolkit|#GSettings / #dconf is ready: http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg00226.html . Please port your modules! #gtk|1277909398|0||0|1
247|GTK+ and friends|GTKtoolkit|More work in height-for-width layout system for GTK+ : http://blogs.gnome.org/tvb/2010/06/30/gtk-learns-height-for-width-episode-ii/ #gtk|1277909313|0||0|0
248|GTK+ and friends|GTKtoolkit|GLib 2.25.10 (unstable) released: http://ur1.ca/0ee7o WARNING: There have been API changes in GDBus. #gtk|1277685452|0||0|1
249|GTK+ and friends|GTKtoolkit|gdk-pixbuf is now a standalone package: http://mail.gnome.org/archives/gtk-devel-list/2010-June/msg00172.html #gtk|1277685365|0||0|1
250|GTK+ and friends|GTKtoolkit|GTK+ 2.90.4 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-June/msg00182.html #gtk|1277685274|0||0|0
251|GTK+ and friends|GTKtoolkit|GTK+ 2.21.3 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-June/msg00183.html #gtk|1277685237|0||0|0
252|GTK+ and friends|GTKtoolkit|We are open to fix API that make the life of #bindings harder but only by addition+rename, or addition+deprecation. File bugs, please #gtk|1277312749|0||0|0
253|GTK+ and friends|GTKtoolkit|Minutes of the GTK+ team IRC meeting - 2010-06-22: http://mail.gnome.org/archives/gtk-devel-list/2010-June/msg00155.html #gtk|1277312445|0||0|0
254|GTK+ and friends|GTKtoolkit|GTK+ team IRC meeting 2010-06-22. In #gtk-devel on irc.gnome.org at 20:00 UTC. Agenda: http://ur1.ca/q6jh #gtk|1277226823|0||0|0
255|Clutter Toolkit|cluttertoolkit|RT @cluttertoolkit: the new #clutter website is now live: http://www.clutter-project.org|1276948072|0|GTKtoolkit|0|5
256|GTK+ and friends|GTKtoolkit|Proposed #GNOME goal: Port your #PyGTK to the new #PyGI bindings http://bit.ly/cvfzO8|1276941335|0||1|2
257|Christian Hergert|hergertme|RT @vwduder: im sad because @ebassi doesn't like my in/out param comments :-)|1276904611|0|GTKtoolkit|0|1
259|GTK+ and friends|GTKtoolkit|#java bindings version 4.0.16 released: http://article.gmane.org/gmane.comp.gnome.bindings.java/1796 #gtk|1276885917|0||0|0
260|GTK+ and friends|GTKtoolkit|RT @cwiiis: MxIconTheme and MxIcon respect system's icon theme (and changes) now in #mx master :) Made possible by @thosw's XSettings work|1276883019|0||0|0
261|GTK+ and friends|GTKtoolkit|#javascript mailing list just created. Discuss its usage in GObject libraries: GTK+, Glib ... http://ur1.ca/08lwz by @jwendell #gtk|1276842639|0||0|0
262|GTK+ and friends|GTKtoolkit|Note fot Win32 users: XP theming is back in 2.90.3 . Please test. #gtk|1276829697|0||0|0
263|GTK+ and friends|GTKtoolkit|GTK+ 2.90.3 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-June/msg00137.html #gtk|1276829633|0||0|0
264|GTK+ and friends|GTKtoolkit|GLib 2.25.9 (unstable) released: http://ur1.ca/08hrl WARNING: API changes in GDBus, GSettings and GApplication #gtk|1276829581|0||0|0
265|scaroo|scaroo|RT @scaroo: #SeedKit does RGBA window with css shadows and stuff : http://dl.dropbox.com/u/5746554/seedkit-does-rgba.png|1276734086|0|GTKtoolkit|0|1
266|scaroo|scaroo|RT @scaroo: Great #SeedKit showcase from @cldx3000 : http://bit.ly/cRDosJ :D|1276734071|0|GTKtoolkit|0|1
268|GTK+ and friends|GTKtoolkit|RT @bertogg: GNOME Developer Training at GUADEC, with Claudio Saavedra, Fernando Herrera, Dave Neary and me: http://is.gd/cPkpJ|1276687240|0||0|0
270|Haakon Sporsheim|haaspors|RT @haakonsporsheim: I built my first app for #android today using jni and #glib :P Sweet :)|1276472258|0|GTKtoolkit|0|4
271|GTK+ and friends|GTKtoolkit|Converting libraries and plugins to use GTK+3: http://mail.gnome.org/archives/desktop-devel-list/2010-June/msg00142.html #gtk|1276390360|0||1|0
272|GTK+ and friends|GTKtoolkit|Call to GNOME maintainers: #GNOME 2.31.4 to ship GTK+ 2.90: http://bit.ly/bnuk3e #gtk|1276390311|0||0|0
273|GTK+ and friends|GTKtoolkit|API changes in GLib master: http://mail.gnome.org/archives/gtk-devel-list/2010-June/msg00079.html #gtk|1276390197|0||1|0
274|GTK+ and friends|GTKtoolkit|GLib 2.25.8 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-June/msg00036.html #gtk|1276390151|0||0|0
275|Johan Dahlin|johandahlin|RT @johandahlin: is adding introspection support for GstMiniObject and other weird instantitiable GTypes. Still left: gjs/pygi support.|1276384704|0|GTKtoolkit|0|3
276|Clutter Toolkit|cluttertoolkit|RT @cluttertoolkit: So, yes: we dropped the copyright waiver on Clutter and Cogl. Contributions welcome!|1276281694|0|GTKtoolkit|0|12
279|GTK+ and friends|GTKtoolkit|GTK+ 2.90.2 (unstable) released: http://ur1.ca/06k6o Feedback about GtkApplication apreciated #gtk|1276141907|0||0|0
280|GTK+ and friends|GTKtoolkit|Minutes of the GTK+ team IRC meeting - 2010-06-08: http://mail.gnome.org/archives/gtk-devel-list/2010-June/msg00044.html #gtk|1276040191|0||0|0
281|GTK+ and friends|GTKtoolkit|RT @bratschegnome: @federicomena http://mzl.la/9PoFhD is nice I used to have CSD whr you can drag gtk+ from anywr in a window|1276038852|0||0|0
282|GTK+ and friends|GTKtoolkit|GTK+ team IRC meeting 2010-06-08.In #gtk-devel on irc.gnome.org at 20:00 UTC.Agenda: http://ur1.ca/q6jh Everyone is invited to attend|1276010278|0||0|0
284|GTK+ and friends|GTKtoolkit|GLib 2.25.8 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-June/msg00036.html #gtk|1276003038|0||0|1
285|GTK+ and friends|GTKtoolkit|New version of #pygi (the new #python bindings based in #GObjectIntrospection) released: http://ur1.ca/0623c|1275945620|0||0|3
286|GTK+ and friends|GTKtoolkit|RT @ebassi: aaaand GBinding (a libexo-like binding between object properties) is mostly done: http://ur1.ca/05fz1 #gtk #glib|1275653238|0||1|0
287|GTK+ and friends|GTKtoolkit|RT @ebassi: plus, I have a GIO branch with GController and friends|1275653044|0||0|0
288|GTK+ and friends|GTKtoolkit|RT @ebassi submitted my patch for creating a GObjectController and get bulk notification #gtk|1275653008|0||0|0
289|GTK+ and friends|GTKtoolkit|GTK+ 2.21.1 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00157.html #gtk|1275271768|0||0|0
290|GTK+ and friends|GTKtoolkit|#dtrace and #systemtap support added to #Glib. Enjoy! https://bugzilla.gnome.org/show_bug.cgi?id=606044 #gtk|1275056183|0||0|2
291|GTK+ and friends|GTKtoolkit|GTK+ 2.90.1 (unstable) released: http://ur1.ca/03hbv . Multiple input device support, flippable widgets and more ...|1274845319|0||1|0
292|GTK+ and friends|GTKtoolkit|Minutes of the GTK+ team IRC meeting - 2010-05-25: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00147.html #gtk #meeting|1274826674|0||0|0
293|GTK+ and friends|GTKtoolkit|[REMINDER] GTK+ team IRC meeting 2010-05-25 at 20:00 UTC. Join us in #gtk-devel on irc.gnome.org. Agenda: http://ur1.ca/q6jh #gtk #meeting|1274801128|0||0|1
294|GTK+ and friends|GTKtoolkit|Gtk2Hs 0.11.0 (Haskell bindings) released: http://haskell.org/gtk2hs/archives/2010/05/25/gtk2hs-0110-released/ #gtk #haskell|1274800929|0||0|0
295|GTK+ and friends|GTKtoolkit|dconf 0.3.1 released: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00145.html #gtk|1274800819|0||0|0
296|GTK+ and friends|GTKtoolkit|GLib 2.25.7 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00144.html #gtk|1274800611|0||0|0
297|GTK+ and friends|GTKtoolkit|XI2 @garnacho 's branch ready for review (xi2-for-master): http://mail.gnome.org/archives/gtk-devel-list/2010-May/thread.html #gtk|1274472793|0||0|0
298|GTK+ and friends|GTKtoolkit|ANNOUNCE: gtk-doc 1.15 released: http://mail.gnome.org/archives/gtk-doc-list/2010-May/msg00000.html #gtk|1274446357|0||0|0
299|GTK+ and friends|GTKtoolkit|Ryan Lortie (@desrt) just released #dconf 0.3: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00128.html #gtk|1274311034|0||0|0
300|GTK+ and friends|GTKtoolkit|GLib 2.25.6 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00127.html #gtk|1274310863|0||0|0
301|GTK+ and friends|GTKtoolkit|GLib 2.25.6 (unstable) released:|1274310818|0||0|0
302|GTK+ and friends|GTKtoolkit|GLib 2.25.5 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00078.html #gtk|1273891783|0||0|0
303|GTK+ and friends|GTKtoolkit|Glade 3.7.1 released with lot of improvements: http://ur1.ca/011bc Thanks to #Openismus who helped sponsor this release #gtk|1273885948|0||0|0
304|GTK+ and friends|GTKtoolkit|GDBus merged in Glib master http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00066.html #gtk|1273837079|0||0|1
305|GTK+ and friends|GTKtoolkit|Minutes of the GTK+ team IRC meeting - 2010-05-11 : http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00047.html #gtk|1273636581|0||0|0
306|GTK+ and friends|GTKtoolkit|[REMINDER] GTK+ team IRC meeting - 2010-05-11 at 20:00 UTC. Join us in #gtk-devel on irc.gnome.org. Agenda: http://ur1.ca/q6jh #gtk #meeting|1273606386|0||0|0
307|GTK+ and friends|GTKtoolkit|GTK+ 2.90.0 (unstable) released. This is the first development release leading toward 3.0. http://ur1.ca/006p2 #gtk #gtk3|1273553873|0||0|5
308|GTK+ and friends|GTKtoolkit|Changes in GTK+ master that affect third parties: http://mail.gnome.org/archives/devel-announce-list/2010-May/msg00001.html #gtk #gtk3|1273531549|0||0|0
309|GTK+ and friends|GTKtoolkit|Have dark themes is more easy now thanks to Bastian Nocera work: http://bit.ly/dBJzgn #gtk|1273531264|0||0|2
310|GTK+ and friends|GTKtoolkit|GTK+ 2.21.0 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00026.html #gtk|1273285878|0||0|0
311|GTK+ and friends|GTKtoolkit|Minutes of the GTK+ IRC team meeting - 2010-05-04: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00010.html #gtk|1273024620|0||0|0
312|GTK+ and friends|GTKtoolkit|GTK+ 2.20.1 (stable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00004.html #gtk|1272983158|0||0|0
313|GTK+ and friends|GTKtoolkit|GLib 2.24.1 (stable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-May/msg00005.html #gtk|1272983138|0||0|0
314|GTK+ and friends|GTKtoolkit|Next GTK+ team meeting: 2010-05-04 at 20:00 UTC. More info and agenda: http://ur1.ca/q6jh . As always, everyone is invited to attend. #gtk|1272848781|0||1|0
315|GTK+ and friends|GTKtoolkit|#Perl bindings: Gtk2 1.230 (unstable) available: http://mail.gnome.org/archives/gtk-perl-list/2010-April/msg00120.html #gtk|1272341271|0||0|0
316|Emmanuele Bassi|ebassi|RT @ebassi: for the first time in ages I was able to work a bit on #gtkperl and add missing 2.16 and 2.18 wrappers|1272139155|0|GTKtoolkit|0|1
317|GTK+ and friends|GTKtoolkit|GLib 2.25.3 (unstable) released with more #GSettings fixes: http://mail.gnome.org/archives/gtk-devel-list/2010-April/msg00090.html #gtk|1272118354|0||0|1
318|GTK+ and friends|GTKtoolkit|GLib 2.25.2 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-April/msg00079.html|1272028911|0||0|0
319|GTK+ and friends|GTKtoolkit|GTK+ Learns height-for-width geometry. Thanks Tristan Van Berkom and #Openismus for sponsoring him! http://ur1.ca/wiz3 #gtk|1271969484|0||1|2
321|GTK+ and friends|GTKtoolkit|Major change in Glib 2.25.0: #GSettings framework has been merged. This provides the API to replace #GConf.|1271715090|0||0|0
322|GTK+ and friends|GTKtoolkit|GLib 2.25.0 (unstable) released: http://mail.gnome.org/archives/gtk-devel-list/2010-April/msg00066.html #gtk|1271714608|0||0|1
323|GTK+ and friends|GTKtoolkit|GSettings status update by Matthias Clasen: http://blogs.fedoraproject.org/wp/mclasen/2010/04/17/gsettings/ #gtk #gsettingshackfest|1271519572|0||0|0
324|GTK+ and friends|GTKtoolkit|GNOME Python Hackfest: Day 1 (by John (J5) Palmieri): http://www.j5live.com/2010/04/14/gnome-python-hackfest-day-1/ #python #pythonhackfest|1271291950|0||0|1
325|GTK+ and friends|GTKtoolkit|Colin Walters: PyGTK, PyGI and PyGTK-on-PyGI #python #pythonhackfest http://ur1.ca/v5kw|1271291792|0||0|0
326|GTK+ and friends|GTKtoolkit|Python Hackfest started.Ttwo concrete goals: porting PyGObject to #Python 3.x and giving a push to PyGI. http://ur1.ca/v5jc|1271291075|0||0|0
327|GTK+ and friends|GTKtoolkit|GSettings Hackfest: Day 1 (by Vincent UNTZ) http://www.vuntz.net/journal/post/2010/04/13/GSettings-Hackfest:-Day-1 #gtk|1271290824|0||0|0
328|GTK+ and friends|GTKtoolkit|GSettings Hackfest started. Thanks to #Novell for sponsoring.Also to #RedHat, #Codethink and #Lanedo for sending people! http://ur1.ca/v5i4|1271290481|0||1|0
329|GTK+ and friends|GTKtoolkit|Xan Lopez from #Igalia attends the WebKit Contribution Meeting at the Apple HQ in Cupertino http://bit.ly/bHCqcC|1271247431|0||0|2
330|GTK+ and friends|GTKtoolkit|Kristian Rietveld advances the #GTK+ Quartz/Mac OS X backend http://bit.ly/cJzV2o|1271247006|0||2|0
331|GTK+ and friends|GTKtoolkit|#Openismus sponsors Tristan Van Berkom to complete the work on #GTK+ Natural Layout http://bit.ly/9FD3JC|1271246851|0||0|1
332|GTK+ and friends|GTKtoolkit|RT @bilboed Having trouble reading GObject or GStreamer code ? Here's a small step-by-step rundown : http://is.gd/bk7mD|1270738689|0||0|1
333|GTK+ and friends|GTKtoolkit|Colin Walters shares his thoughts about the new #GTK+ application class and its relationship with #GNOME 3 http://bit.ly/cvcHIG|1270482931|0||0|0
334|Lucas Rocha|lucasratmundo|RT @lucasratmundo: GNOME Shell has been officially proposed as a GNOME module: http://bit.ly/d1yKE2|1269993362|0|GTKtoolkit|0|3
335|Johan Dahlin|johandahlin|RT @johandahlin: New blog post http://blogs.gnome.org/johan/2010/03/30/bridging-the-development-gap-between-desktop-and-web/|1269993352|0|GTKtoolkit|0|1
336|GTK+ and friends|GTKtoolkit|New Glib STABLE release: 2.24 http://mail.gnome.org/archives/gtk-devel-list/2010-March/msg00149.html #gtk|1269892314|0||0|0
337|GTK+ and friends|GTKtoolkit|Help the GNOME Foundation to hire a sysadmin for GNOME! http://www.gnome.org/friends|1269658993|0||0|1
338|GTK+ and friends|GTKtoolkit|Our friends from #Openismus sponsor #Glade 3 improvements http://bit.ly/9GqLDl|1269656334|0||0|0
339|GTK+ and friends|GTKtoolkit|♺ @johandahlin: just commited the last remaining piece for cairo support in #gjs. World domination here we come|1269646821|0||0|0
340|FedericoMenaQuintero|federicomena|RT @federicomena: Yay, the patch for glade is done - https://bugzilla.gnome.org/show_bug.cgi?id=594231|1269616128|0|GTKtoolkit|0|1
341|Jorge Castro|castrojo|RT @castrojo: Become a Friend of GNOME: http://wp.me/poAPi-da|1269616083|0|GTKtoolkit|0|2
342|Johan Dahlin|johandahlin|RT @johandahlin: just commited the last remaining piece for cairo support in #gjs. World domination here we come|1269616001|0|GTKtoolkit|0|2
343|Jono Bacon|jonobacon|RT @jonobacon: New Acire and Python Snippets website! http://is.gd/aZGnF - still a work in progress, working on it as we speak! #pythons ...|1269615964|0|GTKtoolkit|0|5
344|GTK+ and friends|GTKtoolkit|Python Snippets: project to gather an archive of simple Python (with GTK+) examples http://ur1.ca/rru1 !gtk @jonobacon|1269555086|0||0|2
345|GTK+ and friends|GTKtoolkit|#yorbafoundation is hiring #Vala/#Gtk+ developers and summer interns in California to create multimedia apps http://yorba.org/jobs|1269479714|0||0|1
346|GTK+ and friends|GTKtoolkit|♺ @ploum: now that I have to use Qt and Qt documentation, I've only one word : #gtk rocks ! ( yeah for #gnome people)|1269441827|0||0|2
347|GTK+ and friends|GTKtoolkit|Minutes of the GTK+ Team Meeting: http://mail.gnome.org/archives/gtk-devel-list/2010-March/msg00134.html #gtk|1269391167|0||0|0
348|GTK+ and friends|GTKtoolkit|New GTK+ STABLE release: 2.20 http://mail.gnome.org/archives/gtk-devel-list/2010-March/msg00132.html #gtk|1269374138|0||1|1
349|GTK+ and friends|GTKtoolkit|Reminder: GTK+ meeting today at 20:00 UTC. Where: #gtk-devel on irc.gnome.orgAgenda: http://live.gnome.org/GTK+/Meetings|1269358583|0||0|0
350|GTK+ and friends|GTKtoolkit|GLib 2.23.6 (development branch) released: http://mail.gnome.org/archives/gtk-devel-list/2010-March/msg00131.html #gtk|1269264623|0||0|0
351|GNOME|gnome|RT @gnome: RT @rubenv GNOME was accepted for Google Summer of Code 2010! Looking for an IT student job that earns a lot? http://bit.ly/c ...|1269106193|0|GTKtoolkit|0|5
352|FedericoMenaQuintero|federicomena|RT @federicomena: Untested code is broken code, even if it compiles. #yay #me|1269106077|0|GTKtoolkit|0|1
353|Summer of Code|gsoc|RT @gsoc: Mentor organizations for #GSoC have been announced! http://bit.ly/bVMPWe|1268956782|0|GTKtoolkit|0|31
354|Clutter Toolkit|cluttertoolkit|RT @cluttertoolkit: just released clutter-gtk 0.10.4 - depending on clutter 1.2 and gtk+ 2.19|1268956726|0|GTKtoolkit|0|1
355|GTK+ and friends|GTKtoolkit|Support for Class private data will be available in Glib 2.24: https://bugzilla.gnome.org/show_bug.cgi?id=521707|1268848373|0||0|2
356|GTK+ and friends|GTKtoolkit|GTK+ team IRC meeting: March 23, at 20:00. http://ur1.ca/q6jg . Agenda: http://ur1.ca/q6jh #gtk|1268845861|0||0|1
357|GTK+ and friends|GTKtoolkit|GTK+ 2.18.9 (stable branch) released: http://mail.gnome.org/archives/gtk-devel-list/2010-March/msg00115.html #gtk|1268844918|0||0|0
358|GTK+ and friends|GTKtoolkit|GLib 2.22.5 released: http://mail.gnome.org/archives/gtk-devel-list/2010-March/thread.html #gtk|1268748183|0||0|0
359|GTK+ and friends|GTKtoolkit|GTK+ 2.18.8 released: http://mail.gnome.org/archives/gtk-devel-list/2010-March/msg00078.html #gtk|1268700945|0||0|0
360|GTK+ and friends|GTKtoolkit|@chrisblizzard There's a .zip bundle indeed http://bit.ly/9ZkQCM|1268698714|0||0|0
361|Alberto Ruiz|acruiz|RT @acruiz: libmodel and GTK+ from Codethink Labs! http://aruiz.synaptia.net/siliconisland/2010/03/libmodel-and-gtk-from-codethink-labs.html|1268698629|0|GTKtoolkit|0|3
362|GTK+ and friends|GTKtoolkit|New version of the User Interface Designer #Glade released: 3.7.0 http://ur1.ca/phww #gtk|1268458482|0||0|0
363|GTK+ and friends|GTKtoolkit|GTK+ 2.19.7 released: http://mail.gnome.org/archives/gtk-devel-list/2010-March/msg00044.html #gtk|1268174602|0||0|0
364|GTK+ and friends|GTKtoolkit|#GTK + future idea: automatic composite widgets using #GtkBuilder under the hood http://ur1.ca/oxly|1268157762|0||0|0
365|GTK+ and friends|GTKtoolkit|GLib 2.23.5 is released, congrats to @desrt for his first release http://bit.ly/a3th6S|1268070995|0||0|1
366|GTK+ and friends|GTKtoolkit|The first #PyGTK hackfest ever has been announced, 3.0 and Introspection are the major themes http://bit.ly/9Bd31g|1267875279|0||1|1
367|GTK+ and friends|GTKtoolkit|Kristian Rietveld gives an update of the GTK+/Quartz MacOSX native port http://bit.ly/cZ84VN|1267832356|0||2|0
368|Jono Bacon|jonobacon|RT @jonobacon: Merged in more python-snippets: desktop widget, drag and open in PyGTK, GStreamer video playback, and a bunch of fixes! h ...|1267831925|0|GTKtoolkit|0|3
369|GTK+ and friends|GTKtoolkit|#Openismus is looking for C/C++ GTK+/Qt trainees http://bit.ly/c16WEp|1267831840|0||0|0
370|Clutter Toolkit|cluttertoolkit|RT @cluttertoolkit: clutter 1.2.0 - first stable release, with lots of new API - http://bit.ly/ckdS6R|1267561885|0|GTKtoolkit|0|9
371|GTK+ and friends|GTKtoolkit|#Lanedo is hiring GTK+/GNOME hackers! http://bit.ly/d6fTWQ|1267560392|0||0|1
372|GTK+ and friends|GTKtoolkit|You can help to make a difference too, help the #GTK+ maintainers to improve the documetnation infrastructure! http://bit.ly/dmJifE|1267538283|0||0|1
373|GTK+ and friends|GTKtoolkit|Designers bring back excitement around the #GNOME project http://bit.ly/9Zcx8c|1267202696|0||0|1
374|GTK+ and friends|GTKtoolkit|#webkit #gtk gets ARGB support, allowing it to set a transparent background! http://bit.ly/cBeouj|1267146282|0||0|2
375|GTK+ and friends|GTKtoolkit|Follow GNOME TV on Vimeo http://is.gd/96PlT|1267050829|0||0|1
376|GTK+ and friends|GTKtoolkit|Extensive article on the state of #WebKitGtk http://is.gd/95En2|1267031517|0||0|0
377|GTK+ and friends|GTKtoolkit|@ploum Are you hitting !PyGTK or !GTK+ bugs? Are they already reported upstream?|1267029810|0||0|0
378|GTK+ and friends|GTKtoolkit|#GNUStep gets #GTK+ theming http://is.gd/95vHl more at http://is.gd/95wt8|1267029498|0||0|1
379|GTK+ and friends|GTKtoolkit|GTK+ 2.19.6 released: http://mail.gnome.org/archives/gtk-devel-list/2010-February/msg00050.html #gtk|1266966985|0||0|0
380|GTK+ and friends|GTKtoolkit|Did you know that #GTK+ is the official toolkit for the #LiMo software stack? http://bit.ly/cuEdHx|1266925406|0||0|0
381|GTK+ and friends|GTKtoolkit|@lmedinas publishes a #javascript #example on how to put an status icon with #Gtk+ http://bit.ly/9py1uC Thanks a lot Luis!|1266886644|0||1|1
382|GTK+ and friends|GTKtoolkit|♺ @ebassi: I should really finish up the GDom API as well|1266880653|0||0|0
383|GTK+ and friends|GTKtoolkit|♺ @ebassi: I hope to work on this for the next GIO release, and the GTK+ side for 3.0|1266880641|0||0|0
384|GTK+ and friends|GTKtoolkit|♺ @ebassi: just updated the ApplicationClass design wiki page with the stuff @Cwiiis did for Mx - http://bit.ly/cfAOJk|1266880559|0||0|0
385|GTK+ and friends|GTKtoolkit|#GTK+ Kick Start tutorial for #Vala http://www.vimeo.com/9617309 OGG: http://bit.ly/czegmp|1266874471|0||0|1
386|GTK+ and friends|GTKtoolkit|@migheldeicaza shows off #monodevelop on #macosx deploying and debugging #gtk sharp apps on a #MeeGo device http://bit.ly/9XR0Pg|1266874171|0||1|1
387|GTK+ and friends|GTKtoolkit|#GTK+ is the first toolkit to expose the #Xorg multitouch stack through #XI2 http://bit.ly/9tniKu - Nice work @garnacho!|1266863259|0||0|1
388|GTK+ and friends|GTKtoolkit|This is the official GTK+ first micropost!|1266856657|0||0|1
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
