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.
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
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.
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.
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
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.
The deprecated and a11y sources of GTK+ were spun off some time ago into
their own Makefile.inc, which is then included by gtk/Makefile.am. Fix the
generation of file sources for the GTK+ .gir.
Windows does not send any release key event for one of the shift keys
when both shift keys were pressed together. This commit solves
the problem by sending the extra release key event for the shift key
which was released as first, when the other shift key is released.
Other modifiers (e.g. Ctrl, Alt) do not have this problem.
https://bugzilla.gnome.org/show_bug.cgi?id=751721
(cherry picked from commit 44608dadc6)
We automatically pick up an adjustment from our parent
scrollable, but we failed to update it when it changes.
This is happening in the places sidebar, and it was causing
the focus-tracking to fail there, letting the focus move
out of view. With this change, the focus remains visible.
We need to check on realize if we have access to a GL context, before
calling GL functions. We use gtk_gl_area_get_error() for that.
We also need to tear down the resources during unrealization, instead
of leaking them.
The menu tracker does a better job of this than we can, so move over to
using it instead.
This fixes issues with './testgmenu --import' not properly displaying
the language submenu.
https://bugzilla.gnome.org/show_bug.cgi?id=752016
In case the X11 backend is not enabled, we still need to include the
pangofc-fontmap.h header file, as we use the Pango/FontConfig API in
both the X11 and Wayland case.
https://bugzilla.gnome.org/show_bug.cgi?id=751625
I believe that first_column can only ever be NULL here if
last_column is NULL too, in which case we'd exited already.
But coverity doesn't see that, so add an explicit exit.
We don't care about the error here, but we were relying on
g_resources_get_info to zero the size even in case of error.
No need to do that, we can just check the return value. Plus,
it makes coverity happy.
The way this code is written, we know that there is an item in
the hash table and the iter_next call will give it to us, so
no need to check the return value. Annotate the call to tell
coverity.
When using frame times from _NET_WM_FRAME_DRAWN and _NET_WM_FRAME_TIMINGS, we
were treating them as local monotonic times, but they are actually extended-precision
versions of the server time, and need to be translated to monotonic times in the
case where the X server and client aren't running on the same system.
This fixes rendering stalls when using X over a remote ssh connection.
https://bugzilla.gnome.org/show_bug.cgi?id=741800
Support was added for GDK_HINT_ASPECT in
gdk_quartz_window_set_geometry_hints though with one restriction:
min_aspect and max_aspect have to be equal, which I believe corresponds
to the most common usage. A warning will be printed if this condition is
not met but min_aspect will be used anyway.
We used to "invalidate" scroll valuators, so the next scroll event could
be used as the base for the next scroll deltas. This has the inconvenience
that it invariably consumes the first event received after enter and,
due to interactions with WM overeager passive button grabs, there's a
possibility we don't scroll at all if we receive interleaved "smooth
scroll" XI_Motion events and XI_Enter events (Normally triggered by regular
scroll wheels in mice).
In order to fix this, and at the expense of some sync-call overhead on
XI_Enter events (one XIQueryDevice call per slave device), query the
current scroll valuator state for all the slaves of the entered pointer,
so we do know beforehand the right base values. If new devices are plugged
while the pointer is on top of the client, the initialized scroll values
will match the valuators'.
https://bugzilla.gnome.org/show_bug.cgi?id=750994https://bugzilla.gnome.org/show_bug.cgi?id=750870
gdk_x11_device_xi2_window_at_position() may attempt to push/pop
a few error trap pairs while traversing the window tree. Move it
outside the server grab, and around the multiple XIQueryPointer
calls we may do here.
https://bugzilla.gnome.org/show_bug.cgi?id=751739
The WM isn't aware of O-R (popup) or offscreen windows. If somebody
maps an offscreen or a popup GTK+ window before the main window, we'll
complete the sequence before a "real" window is mapped. Make sure to
ignore these for startup notifies.
gtk_image_set_from_resource was setting the resource_path,
only to have it overwritten again before returning. That
is not as it should be, so change things to set the resource
path late.
https://bugzilla.gnome.org/show_bug.cgi?id=751443
The calculation to update the initial slider position on zoom
changes was not working correctly when using keys to toggle
zoom on and off for scales. Avoid it by updating the position
beforehand.
Moving the mouse while pressing one of the steppers was making
the slider jump to the end, unexpectedly. This was caused by the
drag gesture kicking in when it shouldn't. Fix this by making
all drag gesture signal handlers only do something if we are in
a drag thats started on the slider.
https://bugzilla.gnome.org/show_bug.cgi?id=751050
The filter combo box in the file chooser was stretching to match
the height of the extra widgets next to it. Since, stretched combo
boxes are not a pretty sight, make it stick to the top instead.
Patch by Caolán McNamara,
https://bugzilla.gnome.org/show_bug.cgi?id=751227
GtkTreeView has a particularly expensive drawing path. This can cause
issues when part of animated widget sequences. Caching the content while
a model is attached helps reduce the number of full redraws during
exposure greatly.
https://bugzilla.gnome.org/show_bug.cgi?id=751082
Some widgets have very expensive drawing paths. So caching the content
can be useful even when not scrolling.
This can help speed up widgets that are part of animation sequences and
thereby go through spurious expose events.
https://bugzilla.gnome.org/show_bug.cgi?id=751082
Background patterns are often updated when style changes. In many cases,
the new pattern will match the previous. We can optimize out the
invalidation that will occur upon resetting the same pattern.
GtkInspector is opening a separate display connection, which makes
it more likely that gtk_get_current_event() returns an event from
the "wrong" display.
We were getting ourselves in trouble by casting touch events
to GdkEventButton and poking directly at their internals. Instead,
use GdkEvent API to get what we need.
This fixes a crash when using the gear menu in epiphany with
touch. The same crash also occurred in testmenubutton.
When recoloring symbolic SVG, do not modify the original width and
height of the passed-in file; the function later will scale the image
through gdk_pixbuf_new_from_stream_at_scale(), but we should still
use the original size to create the proxy SVG, or the image will
possibly be doubly-resized or blurry.
https://bugzilla.gnome.org/show_bug.cgi?id=750605
The button and menu item icons settings are deprecated; application
developers should control whether or not a widget should show an icon,
using the existing API.
https://bugzilla.gnome.org/show_bug.cgi?id=750718
So objects connected by g_signal_connect_after actually get
the signal.
This was causing an issue in the dnd highlight, since there
a cairo rectangle is draw using g_signal_connect_after on the draw
signal.
These are fixed pipeline functions, and Mesa will warn (if debugging
messages are enabled). At best, they are poinless calls.
(cherry picked from commit 6bd7526ee7)
Signed-off-by: Emmanuele Bassi <ebassi@gnome.org>
The font chooser delays creating the font description from the font face
as long as possible (it's slow). Because we use fixed height mode, we
only have to create font descriptions for rows we are actually going to
show.
This was achieved by looking at the font description column and if it
was NULL, we created a font description and gtk_list_stiore_set() it.
Unfortunately this caused a "row-changed" signal to be emitted and this
emission could happen during the cell data func.
And that caused infinite loops with accessibility when you were unlucky.
This change replaces the NULL font description with an empty one and
instead of setting the correct font description, we
pango_font_description_merge() it in. This way, the list store doesn't
change and no signals are emitted.
https://bugzilla.redhat.com/show_bug.cgi?id=1197267
Also make them more scary so people really really don't use it as a
random knob when trying to make things go fast.
//bugzilla.gnome.org/show_bug.cgi?id=750505
The changes in commit 13e22e2030 made
_gtk_window_check_handle_wm_event() indirectly depend on
gtk_get_current_event_time() which relies on the current event being
available on the current_events stack.
Since the current event is only pushed on the stack afterwards we get
an invalid timestamp which breaks ewmh window moving.
This fixes the issue by pushing the current event before we start
relying on it being there in gtk_main_do_event() and, as a byproduct,
also fixes a potential memory leak when we have a rewritten event and
return early due to _gtk_window_check_handle_wm_event() being TRUE.
https://bugzilla.gnome.org/show_bug.cgi?id=750384
To generate the icon cache files.
We want to avoid a dependency loop if possible; additionally, on some
Debian-based systems gtk-update-icon-cache maps to the GTK2 version of
the utility and the GTK3 version is renamed to
gtk-update-icon-cache-3.0.
To avoid a build dependency on GTK2, use the binary that we just built
in-tree.
https://bugzilla.gnome.org/show_bug.cgi?id=749593
On some slower machines (e.g. an ARM OBS builder), this test is failing
with a race condition where we're trying to fetch the style before it's
applied.
https://bugzilla.gnome.org/show_bug.cgi?id=749593
gtk_tree_view_set_tooltip_column() specifies that markup in the text
should be escaped.
This fixes critical warnings when hovering over items in the sidebar for
bookmarks that have markup characters in their names.
https://bugzilla.gnome.org/show_bug.cgi?id=719683
The drag destination might be empty, we shouldn't be checking whether
it contains pages at all. Instead, check the source notebook, which
ought to have a selected page if you're dragging something from there.
https://bugzilla.gnome.org/show_bug.cgi?id=749893
If a GtkScrolledWindow is just unmapped and promptly mapped again, the
indicators are left in a semi-visible state, so the GdkWindow isn't raised
properly above scrolledwindow content. This inconsistent state went away
the next time the indicator is hidden.
So, reset all state about indicator window visibility, animation
progress and conceil timer on ::unmap, this will be enough to make the
indicators start out hidden like on newly created scrolledwindows.
Even if a window doesn't support client side shadow
(gtk_window_supports_client_shadow returns FALSE), don't assume the
shadow width is zero, as CSD may have been enabled anyway (meaning
priv->client_decorated is TRUE). In that case we still need to report
the correct width.
https://bugzilla.gnome.org/show_bug.cgi?id=749451
Add parameter for specification of port to gtk_cups_connection_cups_new().
Use default port returned by ippPort() if the given port is lower than 0.
https://bugzilla.gnome.org/show_bug.cgi?id=693738
Even when the program itself calls gdk_set_program_class(). There's
currently no way for this function to be called without breaking gdk's
--class command line option, because you cannot call it before
gtk_init().
https://bugzilla.gnome.org/show_bug.cgi?id=747634
If CSD is enabled with shadow even though it "shouldn't"*, the width
should still be calculated correctly. This fixes a regression caused by
b1e5ad469c.
* gtk_window_should_use_csd () returns false
https://bugzilla.gnome.org/show_bug.cgi?id=748615
The window state 'client_decorated' will only be set the window is being
realized. If anyone tries to get the shadow size before that it'd get
the with as if there always was no shadow.
This avoids negative sized opaque regions caused by the allocation being
smaller than shadow.
https://bugzilla.gnome.org/show_bug.cgi?id=748615
We were relying on indirectly getting notify when fontconfig
configuration changes, by GtkSettings translating the timestamp
change into a style-invalidation, which gets fed through the
css invalidation machinery. That machinery has gotten good enough
at optimizing away redundant changes that it no longer emits
::style-updated in this case.
So, instead make the font chooser listen directly to what it
cares about: the fontconfig change notification from GtkSettings.
We can use the GtkSettings:gtk-fontconfig-timestamp property to decide
whether or not we should reload fonts on style and screen changes. This
should avoid doing a lot of work with large font collections when only
the theme has changed.
https://bugzilla.gnome.org/show_bug.cgi?id=748782
If we have a GObject property that is also a GObject, we should be able
to view additional information on that object (even if the param spec
is read-only).
This is purely to support gdk_cursor_new_from_name().
In particular, its counterpart, gdk_cursor_new_for_display(), will not
be affected, because there's no GDK_LEFT_PTR_WATCH cursor type,
and because i don't have a fallback cursor bitmask for gdk/win32/xcursors.h
We interpret buttons 4-7 as old-school scroll events, so it does
not make sense to add these to the mask. Also fix an off-by-one
in the loop here, buttons_mask is 1-based.
Making a container focusable is rarely the right thing to do.
It typically breaks the focus chain, and makes the container
contents unfocusable, as was the case here.
Just using tracker does not work well if you are searching in
non-indexed locations, such as git checkouts or network mounts.
Ideally, we'd decide the 'best' engine to use for each location.
Since that is not easy to do, just run them in parallel for now,
which is the same strategy that nautilus uses.
I was getting really weird values for scale for the blank cursor used
when hiding the cursor in a GtkEntry when typing, this was caused
by gdk_wayland_device_update_window_cursor sending random values
when the returned buffer was NULL.
We fix this by just not sending any buffer or scale updates in this
case.
gdk_wayland_drop_context_set_status() can't do much else currently besides
picking a mimetype (the first one is currently chosen). This may incorrectly
unset the mimetype chosen on .receive(), so the transfer is cancelled before
it even starts.
At the time drop_reply happens, we should have already picked a mimetype
along the way, so only cover for accepted=FALSE in order to unset it.
During drag operations from another client, we currently set no window as
the DnD source. There's paths in upper layers though that rely on it being
set, just that we don't trigger these yet.
Added another :not() to fix the first and last swatches in the
first section of colorpicker.
Dodge the artifacts due to stacked anti-aliased rounded corners by
increasing the radius of the base object by 1px.
Synchronizing the visible child with the switcher's toggle buttons can
lead to GtkButton::clicked being emitted twice. Once for the button
that was active before, and once for the button that we just activated.
This leads to notify::visible-child being called twice and one of
them is with the wrong child.
Let's deal with this in the same way we handle the visible child
changing underneath us.
https://bugzilla.gnome.org/show_bug.cgi?id=749021
isatty() on MSYS2 returns non-zero if the fd is stdout and is redirected
to /dev/null. That lets xgettext to produce colorized output and leads
to an assertion failure during terminal type detection.
Although the problem should be fixed in MSYS2, isatty() could behave
wrongly in many ways on Windows. Since gtk+ doesn't need colorized
output, it would be safer to bypass the terminal dependent code.
See also:
https://lists.gnu.org/archive/html/bug-gettext/2015-04/msg00004.htmlhttps://bugzilla.gnome.org/show_bug.cgi?id=748346
To calculate the shadow width, we look at the value of priv->fullscreen
and priv->maximized.
Those fields will have the actual value only after GTK receives back a
window state event though, so they will be wrong in _realize(). Look at
priv->fullscreen_initially and priv->maximize_initially too, to avoid
the size changing right after realize, which would make the window
flicker if maximized at startup.
https://bugzilla.gnome.org/show_bug.cgi?id=747808
Libinput will use 0.0f on the "scrolling finished" event, so check for this
instead of rounding (<1 values are sort of frequent on touchpads). This
impedes bug #745315 to resurface after commit d563b943ed.
When the scrolledwindow receives scroll events, it ensures the timeout to
maybe start the "snap back to edges" animation is reset, but it does nothing
about the animation source. It must be reset just the same, to maybe be
started after the timeout fires up.
We were only updating window buttons when the headerbar was
a direct child of the window. That is not the case in more
complicated situations, such as the split headers in gedit
or polari. To fix such cases, make the headerbar itself listen
for state changes on its toplevel.
https://bugzilla.gnome.org/show_bug.cgi?id=747805
This used to do the right thing, practically ignoring those event
if they went all through the event handler, unless this motion event
triggered the cancellation of this gesture from the event handler
of another controllers.
In this case, the controller would be reset, but the motion event
would still go through its handler, setting again
current_button/sequence as the motion event has buttons in its
modifiers. This leaves GtkGestureSingle with inconsistent data
that may interfere with future runs.
https://bugzilla.gnome.org/show_bug.cgi?id=747469
The code managing scrollbars visibility was too pervasively checking for
mouse devices, leaving pen/eraser/cursor devices with no scrollbars at
all. Relax these checks a bit, and actually toggle full-width scrollbars
on pen/eraser devices, so it is an easier target.
https://bugzilla.gnome.org/show_bug.cgi?id=747608
XSetWindowBackgroundPixmap() will throw BadMatch only in the case of a
different parent window depth. Different visuals are fine and actually
expected in Gtk+ 3.16 (since we don't stick to the system default visual
but try to pick a better one).
https://bugzilla.gnome.org/show_bug.cgi?id=747524
Since windows can be intermediate containers this is somewhat redundant,
plus gtk_window_size_allocate() will do additional things like allocating
the popovers, which was mistakenly skipped by local plugs not chaining up.
https://bugzilla.gnome.org/show_bug.cgi?id=747553
This is a workaround for atspi-atk behaviour.
atspi-atk uses signal emission hooks. So it to already catches
signal emissions on creation of objects, before anyone could even
think of g_signal_connect()ing.
https://bugzilla.gnome.org/show_bug.cgi?id=746706
Put the equality check in front. This allows better detection of when an
insert or delete needs to be emitted.
Also, only emit text-changed:delete if the deleted text is not the empty
string. Only emit text-changed:insert if the inserted text is not the
empty string.
https://bugzilla.gnome.org/show_bug.cgi?id=746706
Compute the new text and its length in advance. This way those
computations will not confuse us when they happen in the middle of the
actual action.
https://bugzilla.gnome.org/show_bug.cgi?id=746706
gtk_application_shutdown clears the impl member, so all
callbacks, signal handlers, etc that might still be triggered
between a shutdown call and the return from the mainloop
better be prepared to deal with impl being NULL.
When we open the connection, we get the wl_output object,
but we return before all the information such as monitor
geometry has arrived, which causes us to misinform early
users of this information. Do a roundtrip here that causes
us to wait until the information is complete. Do the same
for seats, just in case.
https://bugzilla.gnome.org/show_bug.cgi?id=747471
When a treeview is destroyed while rubberbanding is going
on, we crash because the rb tree is nuked before we want
to access it to stop the rubberbanding. To avoid this crash
end the rubberbanding early in destroy().
See
https://bugzilla.redhat.com/show_bug.cgi?id=1173904
It can apparently happen that we get focus in events
on windows after gtk_application_shutdown() has been
called. Avoid an unnecessary crash in this case.
See
https://bugzilla.redhat.com/show_bug.cgi?id=1176339
The coordinate translations here were not working properly
for window widgets inside the scrolled window, as can be
seen e.g. for the horizontal scrollbar of the 'Tree View'
example in gtk3-demo.
https://bugzilla.gnome.org/show_bug.cgi?id=747406
When moving over a non-expanded indicator from the outside, we were
not expanding it, due to on_scrollbar being true. This can be seen
e.g. when moving from the content pane over to the sidebar indicator
in gtk3-demo. We must still ensure that the indicator is expanded
when receiving motion events over the indicator.
https://bugzilla.gnome.org/show_bug.cgi?id=747407
This path is only intended to be triggered on events directed towards the
child of the scrolledwindow, so make it explicitly so. This avoids scrollbar
"over" state flashing when dragging finishes within the slider.
https://bugzilla.gnome.org/show_bug.cgi?id=746961
If the icon happened to come from the drag site icon helper (ie. set through
gtk_drag_source_set_icon*), it would be referenced on the GtkDragInfo,
but not hooked into its context. This results on non visible drag windows,
until set_icon_helper() happened to be called on some path.
GtkRadioButton had a deficient copy of the focus sort code
in GtkContainer, causing focus to jump over the next button
in the list. Just use _gtk_container_focus_sort() here,
which fixes the bug _and_ saves 80 lines of code.
https://bugzilla.gnome.org/show_bug.cgi?id=746817
As of 74405cc, progress bars use a new design with values drawn on top
(or to the left) of the through instead of inside of it. This change
brought a number of regressions: the min-horizontal-bar-height and
min-vertical-bar-width style properties are not respected anymore. For
vertical progress bars, the value was drawn too close to the bar and not
centered vertically.
Fix this by respecting the style properties and drawing the value label
at the correct position.
Also, the xspacing and yspacing properties didn't server any apparent
purpose. Change their semantics to mean "the spacing between the label
and the bar". Hence, they only need to be added to the size request when
showing the label. Since we are changing semantics anyway, reduce their
default values from 7 to 2, to avoid and excessive gap.
https://bugzilla.gnome.org/show_bug.cgi?id=746688
Make it possible to control libcanberra support so we don't risk ending up with
a cyclic dependency when using packages: gtk+ -> libcanberra-gtk3 -> gtk+
https://bugzilla.gnome.org/show_bug.cgi?id=746904
I managed to stall recent files today while trying to save a GTK
testcase in glade that contained enough spinning spinners that the CPU
was saturated just redrawing things.
I had to navigate the filesystem!
The direction in which the slider moves can be inverted by setting the
inverted property. But the draw method does not check this, instead it
checks if the direction of the widget is set to be right to left.
Call the should_invert function in order to determine if the direction
of the range should be inverted. It too checks the widget's direction,
but also checks the "inverted" property, and allows the range to be
drawn inverted even if it is vertically oriented.
https://bugzilla.gnome.org/show_bug.cgi?id=746712
Compute the proportion of the range that should be filled to match the
fill level, and use it to compute the starting point and length of the
area between the slider and the fill level.
https://bugzilla.gnome.org/show_bug.cgi?id=734741
As it is, GtkListBox model binding will work nicely as long as your
create_widget_func returns a floating reference on the newly-created
widget.
If you try to return a full reference (as any higher-level language
would do) then you will leak that reference.
Fix that up by converting any floating references into full references
and then unconditionally releasing the full reference after adding to
the box.
https://bugzilla.gnome.org/show_bug.cgi?id=746893
If the GLX_EXT_texture_from_pixmap extension is not available when we
did the extensions check, then there's no point in using the backend
specific code paths that rely on it.
Use screen workarea to *also* set the position of a maximized window,
not just its size. Without this the window position defaults to 0:0
(the topleft corner), which is wrong when taskbar is position along the
top or left edge of the screen.
https://bugzilla.gnome.org/show_bug.cgi?id=746821
Clang complains that this check can never be true. Since this
is a argument range check which we do to catch bad input,
convince clang to not complain instead of taking it out.
clang complains that the expression involving sqrt() is not
constant, and thus refuses to accept it as a case label. So,
use precomputed values instead.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
Break out a setter that manages the weak pointer, and
use it in finalize. This also fixes a bug where we were
forgetting to disconnect the right signal handler in
some cases.
Some arguments, like the group and the label of a RadioMenuItem, can be
NULL: the RadioMenuItem has all the code to deal with them. The argument
validation is too strict, though, for instance doing:
return_if_fail (IS_RADIO_MENU_ITEM (foo))
if (foo != NULL)
set_foo (foo)
Which is obviously incorrect.
This commit also modifies the annotations of the API, to ensure that
language bindings do the right thing.
https://bugzilla.gnome.org/show_bug.cgi?id=671362
If we create a RadioMenuItem without a group, and then set a group, the
menu item will still be set as active, which means an inconsistently
drawn radio menu item - as the RadioMenuItem will set the active flag on
itself, but then it won't reset it when it gets a new group.
https://bugzilla.gnome.org/show_bug.cgi?id=671362
It turned out that using mwm hints to instruct wms to
create border-only decorations is not really working
universally. So, instead of doing this, render a solid
frame without shadow on the client-side to handle this
case.
https://bugzilla.gnome.org/show_bug.cgi?id=746222
Signed-off-by: Olivier Fourdan <fourdan@xfce.org>
If the widget has been destroyed since a DBus message had been sent,
we could be in a condition that the widget pointer exists but it does
not have a window.
This bails as if the widget didn't exist if there is no available
GdkWindow.
We also set the extents to 0 to be defensive since this is a vfunc
implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=746586
Since these part really are the same in all of the x or y direction
and we don't blur in that direction we can just blur one line and
repeat it during drawing.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
There is no need to e.g. blur in the x-direction for the top part
of a box shadow. Also, there is no need to extend the mask in the
non-blurred direction.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
For radius 1px the current implementation rounds down to a 1 px box
filter which is a no-op. Rather than creating useless shadow masks
in this case we bail out blurring early.
Another alternative would be to make radius 1px round up to a 2 px box
filter, but that would change the rendering of Adwaita which is probably
not a great idea this late in the cycle.
https://bugzilla.gnome.org/show_bug.cgi?id=746468
gtk-reftest already had an --output=DIR option to tell it where
to save all the resulting images. Now you can combine this with
the --compare-with=DIR option in a second run to make gtk-reftest
compare the .out.png files from the first run with the .out.png
files of the current run, instead of producing .ref.png files.
The intended use for this is to verify that changes do not affect
the generated output.
This commit adds the GtkTextTag:underline-rgba and :strikethrough-rgba
properties and the necessary plumbing to apply these colors in GtkTextLayout.
With this change, you can alter the color of underlines including those
of type PANGO_UNDERLINE_ERROR.
You might want to alter the underline color to differentiate between
spelling and grammer mistakes. In code editors, it is convenient to
differentiate between errors and warnings.
Note that the GtkTextAppearance struct is public ABI and has no spare
room for new fields, so we are resorting to some tricky packing to store
the colors in the unused pixel field of the fg_color and bg_color structs.
This packing is accomplished by the macros in gtktextattributesprivate.h.
Signed-off-by: Christian Hergert <christian@hergert.me>
https://bugzilla.gnome.org/show_bug.cgi?id=402168
It has been a long-standing request to interpret scroll events
with Shift held down as horizontal instead of vertical, and
some applications are already doing this on their own.
https://bugzilla.gnome.org/show_bug.cgi?id=132197
During copy/paste, it may be common that we receive several property changes
around the selection atom, this results in warnings when cancelling the previous
write attempt. We already honor the last request properly, so we should just
cancel silently.
The wl_data_source may be the clipboard's. Looking up the drag context in
order to get the display isn't going to fare well there. So, just use the
default display, and only look up the drag context when we know we need it.
https://bugzilla.gnome.org/show_bug.cgi?id=746386
This causes pixman warnings, or worse.
Clearly, something is not quite right here, if we end up
redrawing tabs at a time when the allocation is set to (1, 1).
For now, avoid straining the error handling in the lower layers.
https://bugzilla.gnome.org/show_bug.cgi?id=746301
On popover_unmap(), perform the gtk_widget_unmap() call last, so the
GtkWindowPopover data is ensured to be alive throughout the function
if the popover widget is destroyed right on ::unmap.
https://bugzilla.gnome.org/show_bug.cgi?id=745829
This ensures the widget data stays live long enough to perform invariants
check after emission if the widget happens to be destroyed on a callback.
https://bugzilla.gnome.org/show_bug.cgi?id=745829
We are testing -gtk-icon-style and assume the theme doesn't touch it.
But HighContrast forces symbolic icons. And that breaks the reference
images.
So explicitly set "requested" for everything.
Support scaling of cursors created from themes. The default scale is
always 1, but if the pointer cursor surface enters an output with a
higher scale, load the larger version of the cursor theme and use the
image from that theme.
This assumes the theme size is set to one that fits with an output scale
= 1.
https://bugzilla.gnome.org/show_bug.cgi?id=746141
The setting of the the surface scale even when the surface is not
created from a surface was introduced due to a crash when getting the
buffers when dividing by the scale. The only reason I can see this is
that we get the buffer from a non-existing surface when the wl_cursor
has not yet been set.
Instead, use the name field to avoid trying to use the non-existing
surface, effectively avoiding the division-by-zero that way.
https://bugzilla.gnome.org/show_bug.cgi?id=746141
`bundle install` command on fedora 21 was failing
with following message:
Your Gemfile has no gem server sources. If you need
gems that are not already on your machine, add a line
like this to your Gemfile:
source 'https://rubygems.org'
After adding that line it worked again.
https://bugzilla.gnome.org/show_bug.cgi?id=746205
With the 3.0 transition, this code went from just querying the entry's
height request to doing a full size request.
Then it got code to revert the features that a full size request does.
And then it grew code that manually computed the baseline.
Avoid this and just do what happened back in the days: Do a regular
height request.
This changes the semantics of the get_frame_size() vfunc wrt its
behavior towards subclasses overwriting the get_height() vfuncs, but I'm
happy to live with that.
Applications forget to set the follow-state property and then some
themes used a style where normal symbolic icons have the same color as
prelit or selected backgrounds and that suddenly made icons invisible
and who wants that?
https://bugzilla.gnome.org/show_bug.cgi?id=746201
Rework the way we assign an accessible name to menu buttons,
to make sure we pick up a label, should the button contain
one, and only override the name with "Menu" as a fallback.
It seems to be buggy in ways that make the test fail
with a critical when the test bus is brought down.
At the same time, drop manual settings of environment
variables that we can set globally.
This reverts commit 63f59dde3a.
It turns out, the state was not just necessary for style computation,
but also for tracking RTL and LTR. And so it broke the reftests.
gtk_tree_selection_real_modify_range() has a g_return_if_fail() if the
start or end paths passed to it do not correspond to real tree nodes.
However, GtkTreePaths inherently do not have to be valid, so it should
be acceptable to call gtk_tree_selection_select_range() with
non-existent paths. Replace the g_return_if_fail() by a silent return,
and add a unit test.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
The gtk-shell Wayland protocol extension is not meant to be backward
compatible right now, so avoid binding to any version that is not the
one supported.
https://bugzilla.gnome.org/show_bug.cgi?id=745721
We need to filter out platform-specific sources from the files that we
use with the introspection scanner.
In this specific case I could have moved the gtkclipboard-quartz.c and
the gtkdnd-quartz.c files out of the $(gtk_base_c_sources) variable, but
doing a filter-out on the variable itself is more resilient in case we
eventually add files and we forget about the result.
Now that this is split in two separate gestures, both must be reset
when the WM grabs the pointer. Also, do on resize drags like on move
drags, and claim the gesture before resetting, so the ownership is
properly transferred across any other widgets.
https://bugzilla.gnome.org/show_bug.cgi?id=745969
gtk_entry_set_completion() (and _gtk_entry_completion_connect underneath)
may happen when the entry has no toplevel yet. This window acts as the
"parent" for subsurface windows on wayland, and is indispensable to create
its backing wl_subsurface, so this resulted in non-visible popups there.
Fix this by ensuring transient_for is set before showing the popup.
https://bugzilla.gnome.org/show_bug.cgi?id=745463
This reverts commit fb9a6bb6d8.
In a recent test, I've found that Xfce and Mate now support
this, so they will not be affected by this requirement. And
adding the check back will solve the 'client-side shadow'
problem in KDE.
The page_setup of a GtkPrintContext or GtkPrintUnixDialog is nullable,
so all reference count changes to it have to be guarded against NULL
values.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
_gtk_rbtree_first() can potentially return NULL if the RB tree is empty,
which would result in NULL pointer dereferences in the GtkTreeSelection
code. Gracefully handle them.
Found by scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
These vfuncs cannot be NULL: implementations are provided by GtkEntry,
and subclasses should not set them to NULL. Instead of conditionalising
the calls to the vfuncs, assert that they’re set and call them
unconditionally.
This prevents the possibility of a subclass setting the vfunc to NULL
and then a gtk_entry_get_*_size() call returning undefined values in its
out variables.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
gdk_window_ensure_native() can end up with a NULL parent pointer, which
it passes to find_native_parent_above()…but that expects a non-NULL
parent.
Found with scan-build.
https://bugzilla.gnome.org/show_bug.cgi?id=712760
If auth_info_required is only set to "negotiate" the
request password dialog is shown anyway for each print
job without any input fields. As the request_password
dialog only handles username, password and domain.
https://bugzilla.gnome.org/show_bug.cgi?id=669008
They are a bit terse, and they should point to the preferred way of
overriding the theme, i.e. using a GtkStyleProvider for your
application, and custom style classes.
When the scrollbars are overlayed, the size requisition of the
scrolled window should not depend on whether the scrollbars are
visible or not. This was not quite the case, because we forgot
one case where scrollbar size was still added to the requisition.
This is somewhat tricky to work out, so put some example
code here for future reference. The tricky part is that
GtkAccelLabel tries to be smart about hiding the accel
if there's not enough space, so we have to make sure to
pack the label with expand=TRUE and set align=GTK_ALIGN_FILL,
or things won't work.
Make sure that variables are declared at the top of the block.
Break up one of the sincos() calls into individual calls to sin() and cos()
so that we do not have to complicate the initialization of the following
GLfloat array.
If the user requests a version less than 3.2 the version is forced to 3.2.
Previous checking code have an inconsistent behavior depending on which
minor version number was specified. This is avoided now by temporarily
converting the major/minor pair into a single integer.
https://bugzilla.gnome.org/show_bug.cgi?id=744288
There was an added check in configure.ac for sincos() for gtkgears.c, where
that function is actually a GCC- and glibc-specific extension, which is
not available on Windows. Reflect on this in config.h.win32.in for the
Visual Studio/Windows builds.
"Install" the .pdb files that were generated along with the build, to make
it easier for people to develop and debug GTK+, especially when used as a
stack, and as the .pdb files are already generated with all builds.
Also make the copy of the .dll, .lib and .exe files more selective so that
we do not accidently copy files that are not meant to be "installed", or
end up making extra copies of plugin DLLs in the wrong places, when the
projects here are included as a part of a grand solution that is used to
build the entire GTK+ stack, for example.
For Visual Studio 2010 and later, the .pdb filename needs to be explicitly
specified so that it will match the filename of the target, if the project
name differs from the filename of the target. Make sure that is the case
for the 3 DLLs that we build for Visual Studio 2010 and later.
Postpone until the last moment whether the target widget still
potentially uses updates from this sequence, or window dragging
actually applies because all gestures on the target went to denied
state.
This fixes window dragging on empty space in a headerbar that is
contained in a paned (as in e.g. gedit).
https://bugzilla.gnome.org/show_bug.cgi?id=745562
These types are not covered by g_test_register_all_types,
and having the types registered when a print dialog is used
helps in cases where GTK+ is dlopened.
https://bugzilla.gnome.org/show_bug.cgi?id=745065
GtkPlacesSidebar applies a sorting function on
the tree model that does not consider the case
of bookmarks, which are sorted by their indexes.
By adding the bookmarks corner case and comparing
then by their indexes, GtkPlacesSidebar can sort
the bookmarks properly in the order they're saved.
https://bugzilla.gnome.org/show_bug.cgi?id=744589
This signal can be emitted by GtkSearchEntry after search has been
cancelled, and other operation mode is set. It doesn't make sense to
populate the search model in that state anymore, so just avoid doing it.
https://bugzilla.gnome.org/show_bug.cgi?id=745479
The object might be destroyed when mid operation, causing crashes as the
query callback still expects the object pointer to be valid. Also, remove
the gdk_threads_enter/leave pairs, the callback will be executed on the
caller (UI) thread, so this is not necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=745479
The search engine might stay alive longer due to extra temporary refs, so
the signal handlers should be removed for the filechooser to ignore these
properly.
https://bugzilla.gnome.org/show_bug.cgi?id=745479
Use the /MP compiler option, where the build time for release builds can
be cut down by quite a bit. This will however cause a brief warning with
debug builds due to the use of /Gm, but the code will otherwise build
normally. Unlike the Visual Studio 2010+ builds, we can't use /d2Zi+ as
Visual Studio 2008 does not support that, so we can't get a better
debugging experience for release builds here.
Use Multiprocessor compilation which can cut down build times by quite a
bit and use the /d2Zi+ flag to have better debugging info being logged to
the .pdb for release builds.
These are only applicable for Visual Studio 2010/2012 and later.
This file now uses round(), which was not available until C99, so include
fallback-c89.c instead of math.h, which includes math.h and does a fallback
implementation of round().
Instead of using glxgears, which still uses OpenGL 2.1 and the fixed
pipeline, we use a slightly modified es2gears, OpenGL 3.2, and the
programmable pipeline.
Avoid scrolling animation when scrolling to where we want
to insert the new folder, since adding the entry doesn't
do the right thing if the treeview is still scrolling.
An alternative would be to wait for the animated scrolling
to reach its target before starting the editing, but this
is easier.
https://bugzilla.gnome.org/show_bug.cgi?id=729366
And use these for the missing axes if the valuator mask is incomplete.
This used to work fine on tablets because the Wacom driver ensures all
valuators are sent, which is not true if using the evdev driver.
https://bugzilla.gnome.org/show_bug.cgi?id=703610
This is not specified specifically by the attached controllers, so let
the scrolledwindow set the mask, as motion events with no buttons pressed
are interesting to it.
https://bugzilla.gnome.org/show_bug.cgi?id=745344
When a window is hidden, its surface and all its roles are destroyed,
if this happens when we already issued a wl_surface_commit and are
awaiting for a frame callback, the clock will remain frozen for the
next time the window is shown.
To avoid this, keep track of the wl_surface_frame() calls issued,
and ensure the clock is thawed after hiding. If we happen to receive
the frame callback, it is just ignored.
https://bugzilla.gnome.org/show_bug.cgi?id=743427
The gesture is hooked to the capture phase, so it works for buttons in
header bars and whatnot. In order to be friendly to the widget it is
capturing events from, an ugly hack is in place to avoid capturing
events when the target widget has a gesture that would consume motion
events.
This happens on button release, which is more convenient if the gesture
can be consumed by something else (eg. window dragging), and already behaves
correctly wrt cancelled gestures, broken grabs, etc.
This also allows us to unify pointer and keyboard behavior, popping up the
menu widget in a single place.
There are two scenarios. A widget sub-class owns a GtkEventController
and passes itself to it, or a controller owned by something else is
passed a widget.
In the second case, if the widget is destroyed before the controller,
we will have a crash when destructing the controller because we will
be accessing invalid memory. Adding a weak reference on the widget
addresses that problem.
This leads to a crash in the first case. When the widget is getting
destroyed, it will drop the reference to its own controller. The
controller will skip touching the widget because the weak reference
would have turned it to NULL. However, when the widget sub-class chains
up to GtkWidget it will try to free all the controllers in its list.
Unfortunately, all these controllers have already been destroyed. So
we need to guard against this too.
https://bugzilla.gnome.org/show_bug.cgi?id=745225
We were trying to start search when the user types anything,
but this is annoying more often than helpful, and interferes
with the location entry. So, stick with explicitly enabled
search (via the search button or Alt-S) for now.
We were just throwing the request away if the app asks to
fullscreen or maximize a window before it has been mapped.
This is something the GdkWindow API explicitly supports,
so make it work by saving the state until the surface exists.
This fixes things under weston. There are bugs in mutter
that keep this from working correctly with gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=745303
When the Wayland compositor vanishes, all applications connected will
receive a SIGPIPE as soon as they try to use wl_display_dispatch().
Do not use g_error() to terminate the applications when this occurs,
g_error() means an error in the application while here it's not truly
the case.
Use g_warning() and exit() instead.
Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=745289
Although gtk_list_box_row_grab_focus() is not a public function
it can be easily called by gtk_widget_grab_focus() with a row argument
which has been removed from the list box and has box == NULL.
https://bugzilla.gnome.org/show_bug.cgi?id=744879
The height of the text buttons depends on the font height,
whereas the search button has a fixed-size icon in it...
Prevent unevent heights by putting them all in a size group.
https://bugzilla.gnome.org/show_bug.cgi?id=745263
The height of the text buttons depends on the font height,
whereas the search button has a fixed-size icon in it...
Prevent unevent heights by putting them all in a size group.
Before this patch, we'd always allocate a full size SHM buffer via
the wl_shm_pool, even though it would never be used. Instead allocate a
logical 1x1 cairo image surface.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
In order to support window scales for EGL windows, resize the
wl_egl_window to the window dimension multiplied with the window scale,
just as with SHM window buffers.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
When the preferred surface scale changes, for example when entering a
wl_output with a higher scale than any previous entered output, recreate
the shm surface and redraw the window content with the new window scale.
Before this patch, the internal scale would be changed, but the shm
surface would not be recreated given the new scale, i.e. we'd attach a
buffer for a different scale than wl_surface.set_scale specified.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
If the compositor is too old for handling surface buffer scales, never
tyr to set change it. This will effectively always leave it to its
initial state, i.e. 1.
https://bugzilla.gnome.org/show_bug.cgi?id=745076
Don't try to paint onto an error surface. This happens for example when
gdk_cairo_set_source_pixbuf() is called with a pixbuf that is too big
for Cairo to handle.
Spotted by Christian Boxdörfer
If a scrollbar is not shown (because of policies, or because it isn't
necessary), it doesn't make sense to start fade animations on its window
on captured motion events.
This was added a few years ago, as a way to have _no_ im context
at all. But it didn't actually work. Make it work, and streamline
the handling of none by moving it all to gtkimmodule.c.
As part of this, add context to the translated names of all
im modules we ship.
In order to provide a constant mtime between OS build and deploy time,
while also maintaining a hardlink content-addressed model independent of
timestamps, ostree sets all mtimes to 0.
The icon cache code currently ignores directories with mtime 0, assuming
they don't exist.
Track directory existence in a more precise way.
https://bugzilla.gnome.org/show_bug.cgi?id=745052
When loading SVGs from ICON_THEME_DIR_UNTHEMED GtkIconInfos,
such as those created for a GLoadableIcon, the size of the pixbuf to
load is set as a product of icon_info->scale.
But a few lines above, icon_info->scale is set to -1 for
ICON_THEME_DIR_UNTHEMED GtkIconInfos, so we'll end up always passing a
negative size to the GdkPixbuf loader, which is interpreted as the
nominal size of the image file.
Instead load the SVG at the desired scaled size in that case.
This fixes blurry icon in the notification panel in gnome-shell.
https://bugzilla.gnome.org/show_bug.cgi?id=744991
When loading a GResource-backed GFileIcon into a GtkIconInfo we
currently fail to populate the is_resource private field.
Also, since is_svg is set by looking at the filename, and
g_file_get_path() returns NULL for a GResourceFile, is_svg was always
FALSE.
https://bugzilla.gnome.org/show_bug.cgi?id=744991
Add a way to set a delay factor that can be used
to make the long press more or less sensitive.
Making this a factor instead of exposing the delay
itself preserves the value of the setting as an
overall 'slow down long press' setting.
As Sebastian pointed out, just resetting the initial slider
position was an incomplete fix, because it does not cause the
delta to be recomputed, which is important in this scenario,
because you've likely travelled some distance over the slider
before the long press kicks in.
Instead, explicitly record both the slider position and the
delta.
We record the starting position on button press, but only
start the zoom mode when the long press timeout kicks in.
Depending on circumstances, this can cause a noticable jump.
Avoid this by resetting the recorded starting position after
the long press timeout. Suggested by Sebastian Keller.
First, attributes can be NULL (which is always the case when calling
gdk_window_ensure_native) so do not unconditionally dereference it.
Then the window_type should be taken directly from the GdkWindow as
in other backends (such as the X11 one for example).
https://bugzilla.gnome.org/show_bug.cgi?id=744942
While a popover is hiding, the modal grab is already gone and the toggle
button is clickable again, but clicking again at that time will result in
gtk_widget_show() trying to show an already shown widget (although fading
out and hidden soon) and the toggle button activated.
So let the menubutton set the active status only if the menu/popover
widget wasn't already shown, and ensure this doesn't get triggered by
double/triple button press events.
As an implementation detail, the popover hooks the fade out animation
on ::hide. Destroying the popover right away here is not a problem, but
prevents the animation from actually running. ::unmap will be run after
the animation is finished, so destroy the popover there.
These have the same visual effect and timing than the gnome-shell ones.
During the hide animation, the popover has been made to take focus
elsewhere, and refuse to take any pointer/keyboard input until the popover
is shown again.
This has been based on work from Timm Bäder.
https://bugzilla.gnome.org/show_bug.cgi?id=741405
gtk_scrolled_window_allocate_scrollbar was calling
gtk_scrolled_window_allocate_child just to get the relative
allocation, overlooking the fact that that function is only
safe to call if the scrolled window _has_ a child. Unfortunately,
gtk_scrolled_window_allocate_scrollbar will sometimes get called
when that is not the case. Since we are really only interested
in the relative allocation, just get that directly. This
fixes a segfault in the style-properties-nth-child reftest.
Also try and clarify a few things about event propagation. Move
input-handling.xml into gtk-doc’s expand_content_files variable so it
automatically links to widget documentation. Add links from
gtk_widget_add_events() and friends to the new documentation.
https://bugzilla.gnome.org/show_bug.cgi?id=744054
It will be useless to check the source window on the destination side,
it's at the moment always NULL. Fetch the display from the device instead,
which will be set for every GdkDragContext.
At the time of creating the indicator window, the scrollbar allocation is
poked and reused as the initial window dimensions. This usually happens
on two circumstances, either initially (so a ::size-allocate is emitted,
relocating the windows in the right places), or post-initialization when
calling set_overlay_scrolling() (so the scrollbars already have a valid
size allocation)
However, if the scrolledwindow is unrealized, and later re-realized again,
the scrollbars will already have a valid allocation, although 0,0 based
due to being contained in the previous indicator window. This comes out
wrong then, and the indicator window is given 0,0 based coordinates too.
Fix this by refactoring the scrollbar allocation code out of size_allocate,
and also use that given size at the time of creating the indicator windows,
this will provide the right widget-relative allocation anytime.
Currently, GtkGLArea will leak GError instances set during the context
creation, if an error is set.
If any error is set post-context creation, it should be displayed even
in the case a GL context exists; for instance, we can use the error
display facility for shader compilation errors.
Make that variable go from 0.0 to 1.0 where 0.0 means inactive (slider
is on the left) and 1.0 means active (slider is on the right).
The math is simpler that way and most importantly the value is
independent of size.
Add a button to allow restricting search to the current
folder (and subdirectories). This makes the search more
useful, and makes the file chooser more similar to
nautilus.
In search, we show files from differnt locations, and it makes
sense to show where they come from. This makes the file chooser
more similar to nautilus, too.
Folders that show up among search results were unexpectedly
returned even for GTK_FILE_CHOOSER_ACTION_OPEN. Change things
around so that we switch to the folder instead, which is the
behavior we had in GTK+ 2.x.
https://bugzilla.gnome.org/show_bug.cgi?id=744204
Some compositors might not offer wl_seat 4 resulting in GTK+ clients not
working on that compositor.
wl_seat 4 introduces keyboard repeat information, but when that information
is missing it is retrieved from settings, hence there's no reason to
require wl_seat 4.
This patch was tested against QtCompositor (5.5, dev branch)
and Weston 1.6.1.
Reviewed-by: Daniel Stone <daniels@collabora.com>
https://bugzilla.gnome.org/show_bug.cgi?id=744172
This is necessary to avoid unwanted drag cancel animations,
now that GtkNotebook is careful about cancelling a drag
when the dragged tab disappears unexpectedly.
The existence of OpenGL implementations that do not provide the full
core profile compatibility because of reasons beyond the technical, like
llvmpipe not implementing floating point buffers, makes the existence of
GdkGLProfile and documenting the fact that we use core profiles a bit
harder.
Since we do not have any existing profile except the default, we can
remove the GdkGLProfile and its related API from GDK and GTK+, and sweep
the whole thing under the carpet, while we wait for an extension that
lets us ask for the most compatible profile possible.
https://bugzilla.gnome.org/show_bug.cgi?id=744407
Store the OpenGL version when we first do the extensions check; this
allows client code to check the available GL version without requiring a
call to gdk_gl_context_make_current() and epoxy_gl_version().
When using GDK_GL_PROFILE_3_2_CORE, we are not only specifying that the
GDK should create a core profile; we are also specifying that the
minimum required version of OpenGL is set to 3.2.
We should also specify that the GDK_GL_PROFILE_DEFAULT profile is an
alias for GDK_GL_PROFILE_3_2_CORE.
Now that we have a two-stages GL context creation sequence, we can move
the profile to a pre-realize option, like the debug and forward
compatibility bits, or the GL version to use.
gtk_list_box_bind_model() binds a GListModel to a GtkListBox.
This is a first step towards having GListModel support in Gtk. It's not
useful for large models, because GtkListBox always creates all widgets
for all rows.
Emit an error if the profile is different.
This is a follow-up commit to commits cc45e82 (x11/gl: Ensure we use the
3.2 core profile) and 2d9081d (wayland/gl: Ensure we use the 3.2 core
profile), so that we do the same on GDK-Win32. Update variable names and
comments so that the code is clearer to people, as we still need a
temporary legacy WGL context first before we can use
wglCreateContextAttribsARB() to create a WGL core (3.2+) context.
https://bugzilla.gnome.org/show_bug.cgi?id=741946
Using version 1.20 with a forward compatible 3.2 core context is incorrect
since OpenGL 3.2 deprecates shader version 1.20 (See section E.2). The latest
fglrx drivers will not compile these shaders.
https://bugzilla.gnome.org/show_bug.cgi?id=744203
Since we dropped the legacy OpenGL compatibility profile, we need to use
recent OpenGL APi and concepts. This also means that the example code
gets a tad more complicated.
https://bugzilla.gnome.org/show_bug.cgi?id=741946
We simply don't want to care about legacy OpenGL.
All supported platforms also have support for OpenGL ≥ 3.2; it would
complicate the internal code; and would force us to use legacy GL
contexts internally if the first context created by the user is a legacy
GL context, and disable creation of core-3.2 contexts after that.
We will need to fix all our code examples to use the Core 3.2 profile.
https://bugzilla.gnome.org/show_bug.cgi?id=741946
Like what is being done in the X11 and Wayland backends, create the
GdkWin32GLContext in 2 steps, where we only create the actual WGL context
in _gdk_win32_gl_context_realize().
https://bugzilla.gnome.org/show_bug.cgi?id=741946
Users of the GdkGLContext API should be allowed to set properties on the
shim GdkGLContext instance prior to realization, so that the
backend-specific implementation can use the value of those properties
when creating the windowing system specific resources.
The main three options are:
• a major/minor version tuple, to request a specific GL version
• a debug bit, to request a "debug context", which provides additional
validation and run time checking
• a forward compatibility bit, to request a context that does not
have deprecated functionality
See also:
- https://www.opengl.org/registry/specs/ARB/glx_create_context.txthttps://bugzilla.gnome.org/show_bug.cgi?id=741946
One of the major requests by OpenGL users has been the ability to
specify settings when creating a GL context, like the version to use
or whether the debug support should be enabled.
We have a couple of requirements in terms of API:
• avoid, if at all possible, the "C arrays of integers with
attribute, value pairs", which are hard to write and hard
to bind in non-C languages.
• allow failing in a recoverable way.
• do not make the GL context creation API a mess of arguments.
Looking at prior art, it seems that a common pattern is to split the
construction phase in two:
• a first phase that creates a GL context wrapper object and
does preliminary checks on the environment.
• a second phase that creates the backend-specific GL object.
We adopted a similar pattern:
• gdk_window_create_gl_context() creates a GdkGLContext
• gdk_gl_context_realize() creates the underlying resources
Calling gdk_gl_context_make_current() also realizes the context, so
simple GL users do not need to care. Advanced users will want to
call gdk_window_create_gl_context(), set up the optional requirements,
and then call gdk_gl_context_realize(). If either of these two steps
fails, it's possible to recover by changing the requirements, or simply
creating a new GdkGLContext instance.
https://bugzilla.gnome.org/show_bug.cgi?id=741946
This guarantees we only create 1 extra style cascade in total for hidpi
and not one per style context.
Style cascades are now nested like this:
GtkSettings root cascade (scale == 1)
|
+-- GtkSettings per scale cascade (for any scale, no custom providers)
|
+-- GtkStyleContext custom cascade (for any scale, custom providers)
This requires a bunch of care when changing cascade-related properties
inside GtkStyleContext, so that it ends up with a properly setup
cascade, but I think I got those cases right.
The only thing we don't do yet is reverting to a GtkSettings cascade
when the last custom provider is removed from a custom cascade.
The default ->upload_texture() works also for Windows since commit 27cf0fa,
as some of the problems described in 742953 also applied for GL core
contexts on Windows as well before 27cf0fa. Clean up the GDK-Win32 code a
little bit as a result.
This property is necessary to ensure widgets automatically update after
the text scale factor is changed desktop-wide.
And if I'm already doing a property like this, I can make it
overridable. So now you can override the dpi per-widget with CSS like
GtkSwitch {
-gtk-dpi: 48;
}
if you want to debug things.
Long-term, we want to get rid of this property and insist on dpi being
96 everywhere and people can change the font size to get larger fonts.
GPUs generally have problems when you create a 35000px wide surface.
Luckily X catches this and sends a BadAlloc. Which GTK immediately
abort()s on.
Testcase included.
https://bugzilla.redhat.com/show_bug.cgi?id=1163579
We should remove the mir and cairo surface before rendering the
transient_for, which will regenerate the cairo surface anyways.
Otherwise, we end up releasing both, when we only really want to get rid
of the mir surface.
Mouse over a parent menu[bar] didn't work while the menu was open.
The fix was to correct the behaviour of pointer crossing events so that
the pointer appears to be only inside one window at a time.
See: http://tronche.com/gui/x/xlib/events/window-entry-exit/normal.html
We need this because it fixes menu activation. The menu activation code
looks at the time between events to determine if mouse clicks happen too
quickly.
This avoids showing the scrollbars if we are positive the child widget
is being manipulated, regardless of the pointer being close to any of these.
On the next motion event after finishing the operation, the scrollbar will
be shown if necessary.
https://bugzilla.gnome.org/show_bug.cgi?id=743894
is_visible() wasn't the right check to perform here before unmapping,
and gtk_widget_unmap() already avoids being doubly called by checking
gtk_widget_get_mapped() anyway.
Rename the "install" projects as "gtk-install" as we are planning to have a
grand solution file that incorporates all project files of the GTK+ stack
with their dependencies, to make it easier for people to build GTK+ from
scratch from a stock installation of Visual Studio 2008 and later.
In that case the scrolledwindow still gets events through the captured
handler, and can thus still control visibility, so hiding the indicators
in this case can only lead to flashing.
This will be used to just detect when an edge of the scrollable area is
reached - as opposed to the edge-overshot signal that is emitted when
the user scrolls past the edge.
https://bugzilla.gnome.org/show_bug.cgi?id=742848
If a side of the box is 0px wide, make the corners owned by the adjacent
sides. This avoids spilling over of unwanted colors from the 0-width
side into the corner.
This is the fix that should actually have been part of
7e5ac3a58d but my amazing amending skills
got rid of it when amending the test.
Commit ff256956b2 introduced a frame_clock_events_paused
flag, but only ever set it to TRUE, instead of unsetting it when
events are resumed. This was leading to assertion failures in
_gdk_display_unpause_events().
Arrange things so that gtk-xdg-hinting==-1 and gtk-xfg-antialias==-1
end up as CAIRO_HINT_STYLE_DEFAULT and CAIRO_ANTIALIAS_DEFAULT in the
cairo font options.
This will not change anything on Linux desktops where xsettings will
always provide values different from -1. But on other platforms, we
can benefit from getting the platform-specific defaults in cairo.
Based on the first patch in:
https://bugzilla.gnome.org/show_bug.cgi?id=735316
If we are disconnecting from a frame clock that has paused event
processing and hasn't issued a resume yet make sure we resume the
events or they will stay blocked forever.
https://bugzilla.gnome.org/show_bug.cgi?id=742636
The code here was always a bit buggy: We removed the tab from
the notebook in a ::drag-data-received handler. But with
GTK_DEST_DEFAULT_DROP, that signal is emitted before we inform
the source side that the drag is finished. With its improved drag
handling, GtkNotebook now interprets this as a 'spontaneous'
removal of the tab being dragged, and cancels the drag, leading
to an unwanted cancel animation.
The easiest fix is to just defer the tab removal to an idle.
When a tab is dropped, we have to remove it from the notebook to
insert it elsewhere. This is expected part of the tab dnd operation,
and we need to differentiate it from 'spontaneous' removals which
cause us to cancel the drag operation.
when the dragged tab is being removed during the drag operation,
we need to cancel the drag. To do so, we have to keep around
a reference to the drag context.
This should fix
https://bugzilla.gnome.org/show_bug.cgi?id=732051
Add a gtk_drag_cancel() function that can be used on the
source side to cancel an ongoing drag operation. This can
be useful, e.g. if the data that is being dragged becomes
unavailable.
It is a bit misleading to have one of the places in the sidebar
selected while in search mode, since the search is not relative
to any location. So, unset the sidebar selection when we enter
search mode.
If the search entry doesn't consume the key event, don't
change to search mode. Otherwise, we interfere e.g. with
Ctrl and Shift keys for selection.
https://bugzilla.gnome.org/show_bug.cgi?id=743660
If the grab belongs elsewhere, the window won't claim the sequence right
away. The sequence may still be claimed afterwards when window dragging
starts, but simple clicks won't be consumed this way.
This makes it possible to close popovers when clicking on the title region,
while still permitting touch/button 1 interaction for every other purpose.
https://bugzilla.gnome.org/show_bug.cgi?id=743257
This function is given a barely setup GdkEvent, so the GdkDevice field
is still unset, causing warnings and misbehaviors when the position
is queried for it.
Given that the wintab GTK+ code seems to rely somewhat hard on the wintab
device managing the pointer cursor, query the pointer position from the
pointer itself.
https://bugzilla.gnome.org/show_bug.cgi?id=743330
The window used NULL as a parent window, which defaults internally to
using the root window of the default screen. But at the time wintab is
initialized, there is no default display/screen yet.
Fix this by retrieving this information from the given GdkDeviceManager,
so we don't have to wait for the display to be in place before
initialization.
https://bugzilla.gnome.org/show_bug.cgi?id=743330
In some layouts this inconsistency results in crashes in
gdk_gl_texture_from_surface() since it uses gdk_gl_context_get_window() but
the returned window is not the same as the one that is being painted so
"window->current_paint.surface" is NULL. I saw this problem when packing a
GdkGLArea into a GtkPaned.
https://bugzilla.gnome.org/show_bug.cgi?id=743146
- Specifically request GL version when creating context. Just specifying core
profile bit results in the requested version defaulting to 1.0 which causes
the core profile bit to be ignored and an arbitrary compatability context to be
returned.
- Fix GL painting by removing GL calls that have been depricated by the 3.2 core
profile.
- Additionally remove glInvalidateFramebuffer() call, it is not supported by 3.2
core.
https://bugzilla.gnome.org/show_bug.cgi?id=742953
Add helper for getting the main clipboard. This makes
the API usable for bindings (as GdkAtoms aren't usable through
gobject-introspection), and easier to use in C.
https://bugzilla.gnome.org/show_bug.cgi?id=712752
The property is useless to set (it only allows 'initial', 'inherit' and
'unset' as values), but it is used to track changes to the icon theme.
And as such, it can ensure that widgets can track when they need to
reload icons.
https://bugzilla.gnome.org/show_bug.cgi?id=743341
Gtk_container_cell_widget_set should chain up to its parent's set
function, not its parent's unset function. This was resulting in
accessibles being erroneously marked defunct after being created.
The ICCCM says:
If the specified property is None, the requestor is an obsolete client.
Owners are encouraged to support these clients by using the specified
target atom as the property name to be used for the reply.
Lets do that, instead of crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=740613
The previous fix for this issue in 732af31424 was incomplete.
The GtkSelectionData does not own the model set with
gtk_tree_set_row_drag_data so change the out param to "transfer none".
This fixes a crash after multiple DnD actions due to the bindings
stealing a reference each time this function is called.
This also adds nullable and optional annotations for tree_model and path while at it.
https://bugzilla.gnome.org/show_bug.cgi?id=743193
Add ::next-match, ::previous-match and ::stop-search keybinding
signals that are bound to Ctrl-g, Ctrl-Shift-g and Escape. Also
add a gtk_search_entry_handle_event() function to handle key events.
If a side of the box is 0px wide, make the corners owned by the adjacent
sides. This avoids spilling over of unwanted colors from the 0-width
side into the corner.
New test for this case is included.
Previously, we would not include any child widget on the first
allocation, which happens right after realize(), but before map(). No
widget is drawable at that point.
The rotation code in the draw_arrow function was assuming that the arrow
would be drawn pointing upwards but it was pointing to the right
resulting in the rotated arrows pointing in the wrong direction.
The recent refactoring caused a pi/2 rotation to be lost. Rather than
adding that back somehwere (to lose it again in the future), we just
draw the arrow pointing upwards as it is expected to do with a 0 angle.
Yes, I like playing around. To enjoy, add this CSS to your application
of choice (preferrably glade or something with lots of images):
GtkImage { animation: spin 2s linear infinite; }
You can thank me later.
The spinner is a regular builtin image now. There is no need to go
through the shadows code manually anymore as regular items do get
shadows automatically.
This also allows simplifying the actual spinner drawing code so that it
actually works.
The order in which properties are defined depends on the order in which
they are computed. And that means that properties can only depend on
other properties that are defined before them.
The next patches will need this reordering.
Instead of supporting every angle, just support top, right, bottom and
left and round the angle to one of those directions.
Adwaita overrides arrows anyway and doesn't even look at the angle, so
this should not be a problem.
Also, make it have a generic entry point with
gtk_css_image_builtin_draw().
The only feature lost so is the drawing of shadows for spinners, but
that will come back later.
The file chooser code now calls into the path bar in init,
starting an async operation. This unveiled that the path bar
code was not safe against being disposed early, by causing
a crahsh of the objects-finalize test.
Fix this by making the callback check for CANCELLED.
When removing all rows, trying to add rows would not work
and throw criticals. This is fallout from a recent change
to insert rows at the right position. Fix this by handling
the 'empty model' case separately.
https://bugzilla.gnome.org/show_bug.cgi?id=743157
This was left unmodified when GtkScrolledWindow was made a windowed widget.
Displacing here by the widget allocation is not necessary anymore, since
we are invalidating the window set at these coordinates.
This patch is a simplification of a previous one by Timm Bäder.
https://bugzilla.gnome.org/show_bug.cgi?id=742243
GtkImageMenuItem always packs a GtkImage when it is synced with a
related action. This is unnecessary when the action doesn't have an icon
set and results in excess padding when a GtkImageMenuItem is put in a
menu bar (GtkUIManager does this).
Fix this by not creating the GtkImage for icon-less actions.
https://bugzilla.gnome.org/show_bug.cgi?id=742181
Just add a 3rd stop in the place where the gradients for the other
states have a 3rd stop. When running transitions between states, this
avoids cross-fades and instead uses the much faster gradient
transitioning code.
Instead of asserting, just print a g_warning() and try to work around
the problem.
I hope that g_warning() isn't too spammy for people that are hit with
it.
Also clarify the docs that not restore()ing after a save() is a bad
idea.
https://bugzilla.gnome.org/show_bug.cgi?id=743101
When creating the query path, explicitly specify if it's for a root node
or for a child. Relying on gtk_style_context_is_saved() is unreliable
(for example when updating the cache).
The last round of filechooser redesign work had left
search somewhat dysfunctional. This commit fixes things
up enough that search is once again a working feature
of the file chooser.
There are some cases where we can end up showing the path
bar without ever setting a file on it. One example is:
1) Open file chooser
2) Hit ~
3) Hit Ctrl-L
While this is a bit of a workaround, at least it makes sure
that we never end up with an empty space where the path bar
is supposed to be.
It seems that posix_fallocate gives an ENODEV error when
called on an fd opened with shm_open on freebsd. Fix up
the error check to only trigger if we get ENOSPC.
https://bugzilla.gnome.org/show_bug.cgi?id=742980
This gets rid of a bunch of awkward transitions. It's not a perfect
solution to the problem of "should we transition from this state" but it
gets rid of the ugliest offenders.
If this is done on dispose(), the widget may be destroyed (and its
controllers list NULLified) within _gtk_widget_run_controllers(),
causing warnings/crashes when it just tried to hop on the next
controllers.
Freeing the controllers here should be a safety net for implementations,
so it also makes sense to do this late. The widgets that choose to
free their controllers on dispose can still do so, and get
_gtk_widget_remove_controller() called for these as an indirect result.
g_utf8_get_char_validated() may return -1 or -2
return type is gunichar(guint32)
Therefore such checks like 'gunichar < 0' or 'gunichar > 0'
are always 'false' or 'true'(except when gunichar == 0).
Signed-off-by: Maks Naumov <maksqwe1@ukr.net>
https://bugzilla.gnome.org/show_bug.cgi?id=742774
If a gtk_style_context_invalidate() is called on a widget's style
context (which nobody should ever do, sheesh!) and we're animating, stop
the animations.
Fixes crashers in Nautilus.
When we get a leave event, we need to remove the over bit,
since we may not get motion events that tell us when we lose
proximity, but we don't have to fade out right away - that
will happen on its on due to inactivity a bit later. Having
the indicator stay visible for a bit feels more relaxed.
If we use GDK_GL_PROFILE_3_2_CORE we are asking for a core profile
according to the GLX_ARB_create_context_profile extension. For that,
we pass the GLX_CONTEXT_CORE_PROFILE_BIT_ARB value for the
GLX_CONTEXT_PROFILE_MASK_ARB attribute.
The specification for the extension says that:
If the requested OpenGL version is less than 3.2,
GLX_CONTEXT_PROFILE_MASK_ARB is ignored and the functionality
of the context is determined solely by the requested version.
Since we're asking for a core profile, we assume a GL version greater
than or equal to 3.2; thus, we don't need to specify the
GLX_CONTEXT_MAJOR_VERSION_ARB or the GLX_CONTEXT_MINOR_VERSION_ARB
attributes, and instead just rely on whatever version GLX gives us.
This seems to work around a strange issue in Mesa; if we ask for a core
profile and any version > 3.0, we get broken rendering on any shared
context we create.
Since gsize doesn't work as a typename in a ui file,
we have to be careful not to pass pointers to wrongly
sized variables when getting the guint64 values out
of the model.
https://bugzilla.gnome.org/show_bug.cgi?id=742664
We still use symbolic icons for Copy, Cut, and Delete operations inside
toolbars and some menus, so it's worth pointing to the symbolic icon
names in the deprecation notices.
https://bugzilla.gnome.org/show_bug.cgi?id=741969
We need to clear the cache manually on full revalidates because
_gtk_css_change_for_child() will clear the full revalidation flags.
And then gtk_style_context_update_cache() will not do the right thing
(which is to clear itself).
Because we can switch from animating to non-animating pretty much
anywhere, do the check for animations unconditionally instead of trying
to cram it into the correct if path (and failing).
We now cache the results of lookups on the parent GtkCssStyle. This
allows sharing styles between widgets (recursively). However, this
only works if the styles can't potentially depend on siblings -
neither directly via sibling selectors or via position pseudo-classes
like :first-child.
Unfortunately, Adwaita currently uses first-child a lot, and in
particular for labels, which are the most common widgets.
The big benefits of this change are both less CPU - due to not needing
to compute styles again - and less memory usage - due to sharing of
the styles between widgets. Here's some nonscientific numbers I
collected while pondering the usefulness of this patch:
glade glade widget
demo demo factory
runtime styles styles
Adwaita before 19.1s 5800 1150
Adwaita now 18.9s 3800 970
Adwaita hacked now 14.5s 3100 910
simple before 11.3s 5800 1150
simple now 10.8s 1300 590
Adwaita: Adwaita as provided by GTK
Adwaita hacked: Adwaita with the first/last-child for GtkLabel removed
simple: A 250 lines simple GTK theme I use for testing
before: This patch not applied
now: this patch applied
glade demo runtime: Starting glade opening a large file and closing it
glade demo styles: GtkCssStaticStyle objects after opening glade with
the large file as per inspector
widget factory styles: GtkCssStaticStyle objects after startup as per
inspector
Previously we looked at the save/restore state when determining the
parent. This is wrong in the case where we're updating the cache though.
So we now save the parent in the style info.
After the parent changes in commit
3a337156d1 we need to refresh the cached
styles after the current style. After all, they now depend on the base
style.
After 3a337156d1 style lookups still used
the parent context's style as the parent style, even though after a
gtk_style_context_save() the root style of the style context is the
proper parent.
Testcase attached.
Instead of keeping an animated style everywhere, we replace it with the
static style when nothing gets animated.
Apart from making the code cleaner, this gets rid of a bunch of animated
style values that do nothing but wrap a static style.
The only style that is animated is the style of the unsaved primary
node. So there's no need to create animated style objects for the other
ones.
There is a bunch of ugliness in the code currently. Further commits are
expected to fix them.
For now, this is only an implementation detail of the animated style.
The idea is to use GtkCssStaticStyle as the result of CSS queries and
then put a GtkCssAnimatedStyle on top that manages the animations. The
neat thing about this is that you can cache the static values.
GtkCssStyle is the base class to be used for all types of styles that do
exist.
GtkCssAnimatedStyle is the only implementation so far, that is exactly a
copy/paste of the old GtkCssStyle code.
I removed it in 14f5ce7108 because I
thought it was unnecessary, but it wasn't. When we build a tree like
this:
.matches ─┬─ .doesntmatch
└─ .alsodoesntmatch
We would get the changes for the .matches part returned. This is however
only right if that node of the tree contains results. If results only
exist with the child nodes (all of which don't match), then this part
should not match either.
GtkCalendar can have an invalid date — mostly at initialization. This
means that GDateTime construction may fail. We need to handle that case
gracefully, like the old code did.
This fixes the `notify` test suite, which started failing with:
/Notification/GtkCalendar:
GLib-CRITICAL **: g_date_time_get_day_of_week: assertion 'datetime != NULL' failed
inside the Continuous builder.
Sending backingScaleFactor to a NULL NSWindow will silently give the
value 0 for the scale factor, causing insidious divide-by-zero bugs down
the line. This checks if the NSWindow is NULL first, as seems to happen
throughout the rest of the file.
Note that I don't have a hi-DPI OS X machine to test this on, though.
https://bugzilla.gnome.org/show_bug.cgi?id=738338
This is so we can detect crossing events on the scrolledwindow widget,
which can be useful for toggling certain behaviors or not depending on
whether the mouse is on the widget.
If the first of the month was falling on a Sunday, we would not
render any days of the previous month, and instead show two weeks
of the next month at the bottom. Improve this by showing one week
of each.
https://bugzilla.gnome.org/show_bug.cgi?id=301835
Changing font size does not cause widgets to update their size
properly anymore, since we forgot an invalidation flag. The
problem can be observed e.g. by running gtk3-demo and calling
gsettings set org.gnome.desktop.interface font-name "Cantarell 22"
On the wayland backend, set up GDK_WINDOW_SUBSURFACE windows
for popovers. In the popover code, the popover-relative-to-parent
calculation had to be tweaked, and it's been made to always prefer
the given popover position, since there's no sizing limitations.
https://bugzilla.gnome.org/show_bug.cgi?id=738891
We were asserting priv->filename != NULL in various places,
which leads to apps refusing to work when HOME is set to a
nonexisting or nonwritable value. Since it isn't hard, just
make GtkRecentManager survive without a filename. We won't
save or read any recently used files in this state, but
thats ok.
https://bugzilla.gnome.org/show_bug.cgi?id=739038
Provide a mechanism for hiding the "Quit", "About" and "Preferences"
menu items from the normal places in a traditional menubar layout (in
the File and Edit menus) when the menu is being rendered in the Mac OS
menubar.
These items can already be found in the application menu.
With this feature, applications can now define a single menu to use in
all 'traditional' scenarios.
Use this new attribute in Bloatpad.
https://bugzilla.gnome.org/show_bug.cgi?id=741610
In addition to the fixed-size mode that is used by the text view,
add a mode in which the magnifier requests enough size to render
the entire inspected widget at the current magnification. In this
mode, the magnifier will update its size when the size of the
inspected widget changes. Also, make the magnifier redraw on its
own whenever the inspected widget draws.
There is no good reason to assign the value directly.
Also, this fixes d23f3254b7
where widgets that chained up instead of calling
gtk_widget_set_allocation() would not draw becaues of empty clip.
(1) Get rid of supports_clip flag. All widgets (implicitly) support
clip.
(2) Don't reset the clip to { 0, 0, 0, 0 } before the "size-allocate"
signal.
(3) Make gtk_widget_set_allocation() set the clip (to the allocation).
This ensures that eveyr widget has a clip set.
Note: It overrides previous calls to gtk_widget_set_clip(), while in
3.14 this didn't happen.
(4) As the clip is set by gtk_widget_set_allocation() now, don't set
it after the "size-allocate" signal anymore.
This fixes calls to gtk_widget_queue_draw() from inside the
size_allocate vfunc.
We've observed hangs of mutter when it initializes GTK+, which
are caused by initializing GL, which in turn makes xwayland
call back into mutter. With this change, mutter should just
disable GL support in GDK, and things will work.
Override the gtk-shell-shows-app-menu and gtk-shell-shows-menubar
settings to FALSE, if we can detect that we are not on the same
session bus as the xsettings provider that we got these settings
from.
We determine this by comparing the bus ID of 'our' session
bus with the one reported in the Gtk/SessionBusId xsetting.
If they are different, then it very likely that we are in an ssh
situation where we see the forwarded X display, but not the
session bus. The D-Bus based menu exporting will not work
in this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=671802
The magnifier is now set enough height to show the line being currently
manipulated, which makes it just big enough to show the layout height at
that size and magnification.
- It is not possible anymore to trigger text DnD through touch, pressing
and dragging from within the selection will instead extend it. Text
shrinking is still available through the handles
- The selection mode for touch is per-word, char-level manipulation is
still available through the handles.
- Tapping within the selection will bring in text handles, and toggle
text selection popover.
This mode could also shrink the selection, plus the starting point would
seem somewhat arbitrary (actually dependent on the dragging direction of
the last selection).
Made this mode more consistent by only allowing it to extend the selection,
only in one direction for each operation, and so it keeps the current
selection as a minimum.
Instead of passing a GdkEvent and let the function figure out whether the
selection should be extended, let that to the caller and just pass a
boolean here.
Using the parent widget context is a leftover of the pre-popover
implementation, which used GdkWindows directly. This will make the context
reflect widget state, at the expense of changing the selector paths
that used to match the handles.
Checking the return value was valid for most gestures, but
GtkGestureLongPress, where the first press triggers internally an action,
but does nothing for the sequence to be claimed/denied, FALSE was eventually
returned, and the button/sequence functions would be incorrect when
::pressed is emitted.
So check that the sequence is being handled by the gesture, this is more
desirable than the return value as it's independent of sequence state,
and still will be FALSE for the cases we want to catch here.
When a RTL paragraph is not set to wrap, the right margin is not respected
because of the margins counted twice so we replace
display->width by PIXEL_BOUND (extents.width), the same quantity
without the margins.
https://bugzilla.gnome.org/show_bug.cgi?id=741702
GtkIconTheme doesn't scale icons beyond the size specified in the theme
anymore. This can result in arbitrarily large menu items when a theme
only provides large icons.
Force icons to always be 16x16 to ensure that menu items always have the
same height.
https://bugzilla.gnome.org/show_bug.cgi?id=741259
Since the support for GL support in the GDK Windows backend has landed in
master, we need to build it in the Visual Studio builds. Update the
projects for that and "install" the public header that was added.
This adds support for OpenGL to the GDK Windows backend using the WGL API
calls, which enables programs that uses the GTK+ GLArea widgets to work on
Windows as well.
This also adds a simple utility function to query for the version of OpenGL
that is supported by the Windows system, like the one provided by the X11
backend.
Many thanks to Alex (and Emmanuele, who started the OpenGL integration in
GTK+) who offered advice and help along the way, as well as the X11 and
Wayland backend for this work to refer to and to model upon.
https://bugzilla.gnome.org/show_bug.cgi?id=740795
As the alignments, strides and image formats may be different across
platforms, make the texture upload a vfunc to allow backends to override
the GL commands for uploading textures for the software implementation for
gdk_gl_texture_from_surface(), if necessary.
Suggested by Alex to avoid copying non-trivial portions of code which would
then add maintainenace burden.
https://bugzilla.gnome.org/show_bug.cgi?id=740795
This drops the maybe_allocate_buffers that re-allocates buffers
at any point. Instead we just set have_buffers to FALSE and have
the buffers re-created when needed.
This also makes the buffer creation code imdeponent and makes it
clean up no longer needed buffers in order to handle being called
multiple times due to the above.
We also ensure we re-allocate the buffers when we're resizing
and the buffers are already created.
We can't combine multiple draws into one for the software fallback,
because each quad has a different texture. And we generally don't
want to make a larger single texture because then we would have
to upload more data.
On creation, we call action_removed() in case the action was missing
from the start. Because we just created the action, 'can_activate' will
always be FALSE here and this function will therefore always do nothing.
We do want the visibility state to be updated though, for the case where
the action is missing but the item should still be visible from the
start.
Update the visibility directly instead of trying to call
action_removed().
https://bugzilla.gnome.org/show_bug.cgi?id=735122
We were only properly setting the "is-visible" flag to TRUE for menu
items with associated actions and not (for example) on submenus.
This was fine because the code for building GtkMenus from models
(correctly) assumed that submenus should always be visible and never
checked the property.
This is not true for the Mac OS code, which actually checked the
property and found it to be false for submenus.
Initialise the property to TRUE so that we get the correct value
reported for items that don't have actions.
https://bugzilla.gnome.org/show_bug.cgi?id=735122
All popover sides have extra margins to possibly hold the tail, this is
accounted for in gtk_popover_get_rect_coords(), and should be accounted
for too in the tail position calculation.
This fixes the gtk_render_frame_gap() warnings seen when a popover is
pushed far too close to window sides.
After b49c7c3421 we were no longer doing a
full revalidate after GTK_CSS_CHANGE_SOURCE changes.
This fixes spurious failures of widgets not properly updating when
changing the theme.
These functions, while added for use by the GTK inspector, are generally
useful to applications that need to resolve what action groups are
available to a particular GtkWidget.
https://bugzilla.gnome.org/show_bug.cgi?id=741386
Without this, the focus will not be inside the top_stack when
we switch to the statistics page and it shows the excuse. This
in turn will make the next page not take focus as expected when
switching away from the statistics page again.
Add notebook-like focus handling: Keep track of the last focused
descendent of each page, and focus it again when switching back
to the page. If there is no last focused child, we move the focus
into the page as if the user had hit Tab.
When using a completion with some custom cells in the cell layout,
if would often size wrong when first presented on screen.
The entry completion is the only place in the entire gtk code base
that calls gtk_tree_view_column_cell_get_size outside of gtktreeview
itself. It calls into the function before the tree view has done some
important validation on its cell state, the net result of which is
only the first element in the gtkcellareabox the entry completion uses
well actually have its size respected.
We now call gtk_widget_get_preferred_size on the tree view before
calling into the individual cell size routines, to guarantee that the
tree view has run its validate_rows routine and cell state is valid.
https://bugzilla.gnome.org/show_bug.cgi?id=741130
Use the new scrollable API for getting non-scrollable borders
and draw over/undershoot at the right place. In practice, this
means that they now appear below treeview headers.
Add a vfunc to return a non-scrollable border around scrollables.
This would be nicer as a property, but we can't add properties
to an interface without breaking 3rd party implementations, so
make this an optional vfunc, and handle it not being set.
The new region selector tracks more than just one soimple selector, so
it requires some more advanced specificity tracking.
Technically, this is still not correct, because it will report the same
specificity for
tab:sorted
and
tab:sorted:sorted
(and the second selector will be printed as the first) but this is
regions, so meh.
This is just a way to handle regions more conveniently. What this does
is to change the descendant matcher into a maybe-descendant matcher
whenever the current object we're parsing might be a region. Because "*"
might also refer to a region and not just a new element.
See testsuite/reftests/css-match-region-matches-star.ui for a testcase.
When parsing a selector like
tab:active
We used to create 2 selector objects, one for the region, and one for
the pseudoclass. Now, for convenience, we special-case region
pseudoclass parsing so that the active flag is added to the region
selector.
A side effect is that ":nth-child(1)" no longer works for regions.
Hopefully people didn't use this but used the saner ":first-child"
instead.
We used to switch to the objects tab when an object is
picked, but now may have two places with picker buttons:
the objects tab and the interactive tab.
So, just don't do that anymore.
Currently we only take into account the window GActionGroup for
activating the accels.
However, the application could have some custom GActionGroup in the
chain of focused widgets that could want to activate some action if
some accel is activated while that widget is focused.
To allow applications to set accels on widgets that use custom
GActionGroups, simply use the muxer of the focused widget, which
already contains the actions of the parents.
https://bugzilla.gnome.org/show_bug.cgi?id=740682
Add links from gtk_icon_theme_list_contexts() to
gtk_icon_theme_list_icons(), and from there to the Icon Theme
Specification and the Icon Naming Specification.
https://bugzilla.gnome.org/show_bug.cgi?id=461249
Adding rows to the bottom of the list is confusing as you cannot see
them if the window is small so it is not apparent that anything has
happened. Fix this by adding the new row immediately below the current
row and set the cursor on the new row so it is ready to be edited.
https://bugzilla.gnome.org/show_bug.cgi?id=721939
Most of the core GNOME applications (eg., gnome-control-center,
gnome-documents, and nautilus) start searching as soon as the text
changes, and don't wait for the user to hit ENTER. It would be nice to
follow the same pattern.
https://bugzilla.gnome.org/show_bug.cgi?id=739977
Since widgets subelements are now both widget childs and widget
classes, say .spinbutton.button and .spinbutton .button,
the linking logic needs to be adapted to be stricter with
child selectors. This fixes vertically linked spinbuttons.
Since widgets subelements are now both widget childs and widget
classes, say .spinbutton.button and .spinbutton .button, the linking
logic needs to be adapted to be stricter with child selectors.
This fixes vertically linked spinbuttons.
If the previous focus widget is unmapped (eg. hidden, scheduled for
destruction, etc), make the popover forget about it and grant focus
back to the window itself.
The shadow rendering code had code to exit early if we determine
that the shadow is entirely clipped away. Unfortunately, the check
based on cairo clip extents fails for any clip regions that are
more complicated than axis-aligned rectangles, and we are using
a hollow rounded rectangle here. So, instead, do the check manually,
using the just-introduced API in GtkRoundedBox.
This adds two functions for checking whether an axis-aligned
rectangle is completely outside or inside of a rounded box.
These are not trying to be exact, but fast.
As the print preview command is moved into the sources, don't define it in
the preprocessor definitions. However, define the
GTK_PRINT_BACKEND_ENABLE_UNSUPPORTED in the preprocessor definitions, to
make the build in-line with the autotools builds.
We were concatenating "file://" to the result of g_get_user_special_dir() to build
a URI, but this is not enough on Windows. Use g_filename_to_uri() instead.
See https://bugzilla.gnome.org/show_bug.cgi?id=739453
Previously, the inspector would not change the hilight while the
previous hilight was still flashing.
This is inconvenient while arrowing through the object selection
treeview though where you want the currently selected row to hilight
when arrowing quickly.
The GTK_FILE_SYSTEM_ENABLE_UNSUPPORTED define is not used anymore,
and we don't install a gtk.css file for Raleigh, so no need to
uninstall one either.
gtk-update-icon-cache is no longer used at build time, so a lot
of the complicated machinery we have around that (conditional
build, cross build, etc) are no longer required.
The files for build of GtkInspector have been intergrated into the build of
the main GTK+ DLL, and the Visual Studio project templates for those have
been removed as well. Make that removal complete by removing from the
solution files references to it and make the 'gtk' project not to depend on
the gtk-inspector project.
1) Use font-size instead of color
This makes it easier to compare reference and test because the values
don't change.
2) Actually sort the reference properly
This unbreaks the test.
This subdirectory gets in the way when integrating the inspector
build more fully with GTK+, and does not really add anything.
Just move everything one level up.
I checked Cairo source code (actually pixman, as Cairo just passes
through) to make sure that the behavior stays identical: negative values
cause an error message from pixman, zero is allowed. Both return an
empty region which gtk_widget_queue_draw_region() would then proceed to
ignore.
The calls to cairo_translate in
_gtk_print_context_rotate_according_to_orientation,
_gtk_print_context_reverse_according_to_orientation and
_gtk_print_context_translate_into_margin assume an unscaled context.
These functions should therefore be called before scaling the context,
otherwise the origin does not always end up in the top left corner.
https://bugzilla.gnome.org/show_bug.cgi?id=740742
The ICCCM says:
If the specified property is None , the requestor is an obsolete client.
Owners are encouraged to support these clients by using the specified
target atom as the property name to be used for the reply.
Lets do that, instead of crashing.
https://bugzilla.gnome.org/show_bug.cgi?id=740613
gtk_window_propagate_key_event() will run unstopped from the focus widget up to the
popover if GDK_EVENT_PROPAGATE was returned along the chain, resulting in infinite
recursion. This could be just triggered by pressing some modifier key on an entry...
If a file system event arrives while GtkFileChooserWidget is asking the
user to edit the name of a newly created folder, the file system model
will drop the row with the editable cell, and the user will have to
start from scratch.
This makes creating new directories impossible inside a directory with a
file currently being downloaded, for instance, and it's really unhelpful
to the user because the editable row simply disappears.
We already have a mechanism in place to freeze the file system model, so
we can reuse it between the add_editable() and the remove_editable()
calls.
https://bugzilla.gnome.org/show_bug.cgi?id=729927
We directly get the length of the secret from the g_variant
and use it in a following g_strndup which ensures that the
resulting string is terminated.
This fixes reading secrets which were stored by system-config-printer.
https://bugzilla.gnome.org/show_bug.cgi?id=740612
This is a bit bizarre, but the cell renderer can apply different
flags from the actual style context, and we should use those instead
of the widget flags.
:not() works for names, ids, classes and pseudoclasses based on states.
It does not yet work for positional pseudoclasses (like :last-child or
:even) as there is region madness going on with those.
The adjustment value being equal is checked by
gtk_adjustment_set_value() and the necessity of calc_layout() is handled
by the value_changed signal handler.
This is the expected behavior while the popover keeps the grab, leaving
this up to the toplevel implementation gives place to key handlers
connected there to handle the event otherwise, and maybe redirect key
events somewhere else.
NULL-plus-something could be seen by the compiler to attempt to do
arithmetic with void *, which is a GCCism. Instead, do the math normally
and cast the results as a void *.
https://bugzilla.gnome.org/show_bug.cgi?id=740605
Use xdg_surface_set_window_geometry() to tell the compositor about the
shadow widths, this makes some gnome-shell/mutter features (edge resistance,
frames around windows in the overview, side maximization, ...) work alright
with GTK+.
In order to add this, some other places in gdkwindow-wayland had to gain
some knowledge about margins:
- xdg_surface_configure() now syncs the shadow after applying the state,
and gdk_wayland_window_set_shadow_width() possibly reconfigures the
window in order to preserve window geometry. This is necessary to keep
shadows in sync with state/geometry changes, as this does not happen
all at once.
- xdg_popups relative to an xdg_surface are shown relative to buffer
coordinates, so the left/top margins must be added there.
https://bugzilla.gnome.org/show_bug.cgi?id=736742
This requires us to use GL_TRIANGLES and six verts per quad instead
of four, which makes me think it might not be worth it on
well-optimized GL drivers. However, from talking to some driver
developers about it, the GL_TRIANGLES should be faster, since this
means that there's one giant contiguous buffer instead of many small
buffers.
If we were really rendering a lot of quads, I'd use an element buffer
and GL_PRIMITIVE_RESTART, but we're really not ever rendering that
many quads, and the setup cost for that would just be too annoying.
It's unused. At the same time, rename "begin_paint_region" to
"begin_paint". This will help us clean up how GDK painting works
in the future to allow more creative use of double-buffering.
...for Broadway builds, as it was producing a wrongly-named check file for
that configuration, so that a clean would not be correctly performed and
subsequently affected rebuilds.
This is needed in the edge case where the X11 backend rounded the actual
size, and the GL flipping really needs the correct window height to
do proper Y coordinate flipping.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
This is required for the X backend GL integration. If the
window has a height that is not a multiple of the window scale
we can't properly do the y coordinate flipping that GL needs.
Other backends can ignore this and use the default implementation.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
Rather than just rounding down the position *and* the size separately
we correctly calculate a rectangle in scaled window coords that fully
covers the real window size. This really only makes a difference
when the window size/position isn't a multiple of the window scale.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
Keep track of the exact size of X windows in underlying pixels; we
generally use the scaled size instead, but to properly handle the GL
viewport for windows that aren't a multiple of window_scale,
we need to know the real size.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
Although we specify a resize increment to try and get a size that is
a multiple of the window scale, maximization typically wins
over the resize increment, so the window might be odd sized.
Round *up* in this case, rather than down, since it's better to
truncate a line or two at the bottom and right of the window rather
than have a line or two that we don't know what to do with.
https://bugzilla.gnome.org/show_bug.cgi?id=739750
The intention was that ::iconic indicates which representation is
preferred (text or icon). We fall back to the other representation
if one is missing.
If the widget is an action widget, it's been previously added with
gtk_dialog_add_action_widget, which calls add_response_data on it, which
in turn connects to the clicked/activate signal of that widget, so we
don't need to connect to that signal a second time in
gtk_buildable_custom_finished.
When overshooting through touchpad kinetic scrolling, the scrollbar remains
mostly static as it already hit a boundary. However, the fade in/out checks
are constantly run during scroll events, causing needless redraws in this
specific case.
The scrollbars are still internal children of the GtkScrolledWindow
and handled in ::forall(), no need to propagate draw here again
after chaining up in ::draw().
During size request, all sides' margins are ensured to be as big
as TAIL_HEIGHT, just to avoid possible relocation loops if the
popover doesn't fit in its original position. This must be
accounted for in size_allocate() as well.
Look for themes in $prefix/themes/$name/gtk-$version/ (for
version = 3.16, 3.14, ...), before using the old location
$prefix/themes/$name/gtk-3.0/. This gives theme authors a
way to support multiple versions of GTK+ 3 with separate
css files.
We really want margins around the scrollable content, not around
the viewport. Make it so by using textview-specific properties.
This is unfortunately a little complicated for top/bottom.
Css margin now works on the slider as they do on the trough.
The margin is not considered in the space allocation as it is for
the trough, so the slider width will be the set slider-width -
margins. Spefifying margins on the main widget in the css will
clearly affect both the trough and the slider, so theme changes are
needed.
The current way of exposing GDK API that should be considered internal
to GTK+ is to append a 'libgtk_only' suffix to the function name; this
is not really safe.
GLib has been using a slightly different approach: a private table of
function pointers, and a macro that allows accessing the desired symbol
inside that vtable.
We can copy the approach, and deprecate the 'libgtk_only' symbols in
lieu of outright removal.
https://bugzilla.gnome.org/show_bug.cgi?id=739781
Instead of possibly calling wl_surface_commit() out of
GdkFrameClock::after-paint, tick the transient parent clock so ::after-paint
can be eventually run.
This ensures that the subsurface coordinates (considered part of the state
of the parent) aren't committed untimely, and guaranteed to be orderly with
the wl_subsurface-relative state.
This is a gtk-side fix for https://bugzilla.gnome.org/show_bug.cgi?id=738887
cairo_region_copy(NULL) will effectively return an empty region, as this
function is always meant to return valid memory. This however inverts the
meaning of the NULL region and results in entirely non-clickable windows.
This event might not have an action yet, but certainly accounts, and
should be triggering recognition.
This fixes a crash when attempting to drag CSD windows through touch. As
since cfaec2d2f5, gtk_gesture_single_get_current_sequence() would
rightfully return NULL if the gesture didn't enter recognition, making
event lookup fail.
We need to export the symbols so they can be used in the
inspector, but we don't really want to make this supported
public API, so keep them out of installed headers.
Store the cursor name on the cursor (rather than always using its type).
Use this when setting a cursor on a surface.
The mir server will fallback to using standard cursors from the cursor
theme if the name used is not one of those defined by mir, which is more
or less what we want to happen here in case of creating a cursor by
name.
If buffer age is undefined and the updated area is not the whole
window then we use bit-blits instead of swap-buffers to end the
frame.
This allows us to not repaint the entire window unnecessarily if
buffer_age is not supported, like e.g. with DRI2.
This moves the GDK_ALWAYS_USE_GL env var to GDK_GL=always.
It also changes GDK_DEBUG=nogl to GDK_GL=disable, as GDK_DEBUG
is really only about debug loggin.
It also adds some completely new flags:
software-draw-gl:
Always use software fallback for drawing gl content to a cairo_t.
This disables the fastpaths that exist for drawing directly to
a window and instead reads back the pixels into a cairo image
surface.
software-draw-surface:
Always use software fallback for drawing cairo surfaces onto a
gl-using window. This disables e.g. texture-from-pixmap on X11.
software-draw:
Enables both the above.
The Mir backend was checking for button mask changes to generate the appropriate
GDK event. When Mir generates a touch event it has no button mask. In this case
we'll just generate a primary button event.
This was unnecessarily creating a framebuffer in the texture case,
and it was not properly setting up a framebuffer with the texture
as source in the software fallback w/ texture source case.
Commit afd9709aff made us keep impl window
cairo surfaces around across changes of window scale. But the
window scale setter forgot to update the size and scale of the
surface. The effect of this was that toggling the window scale
from 1 to 2 in the inspector was not causing the window to draw
at twice the size, although the X window was made twice as big,
and input was scaled too. Fix this by updating the surface when
the window scale changes.
We need to use this in the code path where we make the context
non-current during destroy, because at that point the window
could be destroyed and gdk_window_get_display() would return
NULL.
The child property setting must be prepared to deal with any
child property for any child, even if it doesn't make sense,
like the pack-type for the custom title. This is happening
in glade when undoing a change in the custom-title property.
When a GtkRadioButton has no focus, it will accept it when there is no
other active button in its group.
If the active button in the group is hidden, for example because the UI
desires not to have a default option pre-selected, currently the focus
will not be accepted, which is not desired behavior.
This commit changes the code to only consider visible buttons in the
group when checking whether another button is active.
https://bugzilla.gnome.org/show_bug.cgi?id=739474
Stop using activate-on-single click for the property list -
it is a little annoying to have the popover come up when you
just click in the list to get the focus there.
This restructures the way buffers are allocated and bound in a way
that is more flexible.
Buffer operation happens in three phases:
create_buffer() - Creates the gl objects
allocate_buffers() - Allocates space for the buffers at a given size
attach_buffers() - Attaches the buffers to the framebuffer and makes
the framebuffer the default drawing target
And destroy via
delete_buffers()
We call all these the first draw, and after that we allocate buffers
each time the widget changes size until the buffers are deleted.
We delete the buffers at unrealize.
However, anyone that wants to manually control buffer allocation strategies
can manually call allocate/delete_buffers().
There are also some other changes:
* Support for stencil buffers.
* A manual render mode where ::draw doesn't render unless you manually
invalidated the previous rendering.
This moves the code related to the frame sync code into
the is_attached check, which means we don't have to ever
run this when making non-window-paint contexts current.
This is a minior speed thing, but the main advantage
is that it makes making a non-paint context current
threadsafe.
This is not really needed. The gl context is totally tied to the
window it is created from by virtue of sharing the context with the
paint context of that window and that context always has the visual
of the window (which we already can get).
Also, all user visible contexts are essentially offscreen contexts, so
a visual doesn't make sense for them. They only use FBOs which have
whatever format that the users sets up.
We had some code that tried to reuse the context over realize, but
that doesn't work as we need to share with the possibly new
paint context of the re-realized window.
To properly support multithreaded use we use a global GPrivate
to track the current context. Since we also don't need to track
the current context on the display we move gdk_display_destroy_gl_context
to GdkGLContext::discard.
Removed bright translucent outer border for "top level" osd widgets,
insensitive osd entry styled, more meaningfull color variables and
some code rationalization.
We used to have a weak ref to the cairo surface and it was keep
alive by the references in the normal windows, but that reference
was removed by d48adf9cee, causing
us to constantly create and destroy the surface.
https://bugzilla.gnome.org/show_bug.cgi?id=738648
We want to create windows with the default visuals such that we then
have the right visual for GLX when we want to create the paint GL
context for the window.
For instance, (in bug 738670) the default rgba visual we picked for the
NVidia driver had an alpha size of 0 which gave us a BadMatch when later
trying to initialize a gl context on it with a alpha FBConfig.
Instead of just picking what the Xserver likes for the default, and just
picking the first rgba visual we now actually call into GLX to pick
an appropriate visual.
Add a menu-name property and use it in a default implementation
of ::clicked to switch menus if we are inside a stack. This means
GtkModelButton is no longer entirely generic, but rather expects
to be used inside a GtkPopoverMenu. It still works in other contexts
too, of course.
Rename the "toggled" property to "active", since that is what
GtkActionHelper expects to update for check and radio actions.
Also make the property readable, since GtkActionHelper wants
to read it.
The visuals are typically sorted by some sort of "most useful first"
order. And picking the last one is likely to give us the weirdest
matching glx visual.
Under wayland, the compositor doesn't have a 'overall window alpha'
knob, we just need to add the alpha to the buffers we send.
Client-side alpha, if you want to call it that.
Implement this by reusing the existing alpha support for non-toplevel
widgets. As a side-effect of the implementation, windows with RGBA
visual under X will now also use per-pixel alpha, instead of
overall alpha.
The differences between the mutter and GTK+ code are subtle, but it
turns out that _gtk_cairo_blur_compute_pixels actually returns the
shadow *spread*. Since we use a triple box blur, the constant was
multiplied by 1.5 to approximate three chained box blurs. Split this
out and use the correct value for the lobe width.
We weren't passing in the right "d" value, which was causing the blur to
behave incorrectly, especially in the case of 1px blurs, which would
cause no blurs at all.
The blur should now match the web.
We don't want separators in both side of an iconic section
and use a 10px margin to separate two iconic sections.
Separators are also updated in case of dynamic insertion
( often used with menu items for plugins )
https://bugzilla.gnome.org/show_bug.cgi?id=738650
We want to be able to style the empty blocks independently of all the
offset styles, so remove the current style class when painting an empty
block.
https://bugzilla.gnome.org/show_bug.cgi?id=707695
It is not possible to successfully build GTK+ on OS X 10.6 and below
since NSFullScreenWindowMask is only available starting with 10.7. Add
ifdef guards around setStyleMask: in order to allow it to build on
earlier OS X releases.
https://bugzilla.gnome.org/show_bug.cgi?id=737561
Commit 30a1c4ab fixed several memleaks including one in
gtk_font_chooser_widget_find_font.
However, the fix causes one extra call to gtk_tree_model_iter_next()
after finding the font we look for (ie pango_font_description_equal
returns TRUE): the 'increment' part of the for loop
(gtk_tree_model_iter_next) is run before the 'exit condition' of the for
loop is evaluated.
This commit reverts this part of commit 30a1c4ab and adds an extra
call to pango_font_description_free in order to fix the leak.
https://bugzilla.gnome.org/show_bug.cgi?id=739111
When using GtkFontChooserButton, the same GtkFontChooserWidget can be
hidden and shown multiple times. When doing that, the font that was
chosen the previous time should be the selected one in the
GtkFontChooserWidget, however this does not work as expected and a
somehow 'random' font gets selected (or none) instead.
Every time the font chooser widget is shown, its style will be updated,
causing gtk_font_chooser_widget_style_updated and then
gtk_font_chooser_widget_load_fonts to be called.
gtk_font_chooser_widget_load_fonts starts by clearing the GtkListStore
listing the available fonts, repopulates it, and then makes sure the
current font is selected.
However, this does not work as expected, as during the call to
gtk_list_store_clear, the cursor_changed_cb will be invoked multiple
times when the GtkTreeView cursor gets moved when the line where the
cursor currently is gets removed. This will cause the 'current font'
state (priv->font_desc) to be unexpectedly modified, and when
gtk_font_chooser_widget_load_fonts tries to reposition the cursor to the
'current font', we won't get the expect result.
This commit avoids that by making sure cursor_changed_cb does not get
called when we call gtk_list_store_clear in
gtk_font_chooser_widget_load_fonts.
https://bugzilla.gnome.org/show_bug.cgi?id=739111
Commits 314b6abbe8 and eb9223c008 were ignoring
the fact that the code where found is set to 1 was modifying
col - which was an ok thing to do when that part of the code
was still breaking out of the loop, but it is no longer doing
that (since 2003 !). Fix things up by storing the final col
value in a separate variable and using that after the loop.
https://bugzilla.gnome.org/show_bug.cgi?id=738886
Failure to do so results in custom styling leaking through in
the inspector. This is pretty obvious, now that the inspector
is using a separate display connection and is generally isolated
from style changes.
In various places, the broadway backend was just using
the default display and assumed that it is the broadway
display. That may not be the case in a multi-backend world,
so instead iterate over all displays and use the first
broadway display - still not perfect, but enough to survive
for now.
When the window is on a non-default screen, popover_realize
ended up passing a visual and a parent_window from different
screens into gdk_window_new, which doesn't work. Fix it by
using the visual of the parent window.
GtkStyleContext was not properly handling the style cascade when
setting a screen, causing the inspector global CSS to affect the
inspector window, even though the inspector is using a different
screen now.
This helps isolate the inspector from some of the changes that
it can trigger. To specify a different display, set
GTK_INSPECTOR_DISPLAY to the name of the display to use for
the inspector window. If no display is specified, GTK+ will
use a separate connection to the default display.
When a new screen is set on a window, we unrealize it, to
recreate all the resources. But we don't reset the client_decorated
flag, so realize() doesn't call create_decoration() - which makes
sense, since the decoration already exists. But the side-effect
of create_decoration() is to select the rgba visual, and visuals
are per-screen.
Fix this by looking for the rgba visual in set_screen(), and
replacing it with the rgba visual for the new screen, if necessary.
This special code was added back in the days when computation wasn't
idemptotent. These days it is.
Also, the bypass code path is only used in fallback code that is pretty
much unused.
The gtkglarea and sidebar demos have been added, so build them in the
projects. Note that the gtkglarea code is not usable under Windows at this
point as implementation is needed for the GDK-Win32 backend.
Patches have been submitted to the libepoxy project so that it can be built
under Visual Studio. This will allow the GDK, GTK and gtk3-demo projects
to build, but the gtkglarea code is not usable at this time as
implementation needs to be added to the GDK-Win32 backend for it.
"Install" gdkbroadwaydisplay.h, as it is a public header of GDK Broadway,
also fix the MSVC 2010+ gtk-copy-gdk-broadway.props property sheet as a
'>' is missing. Sorry for not noting these issues earlier, as MSVC
Broadway builds were recently restored. My bad :|
The current implementation of this script generate headers with \x-escaped
strings that can become too long (> 65535 characters) for Visual Studio
to consume, hence the build of broadwayd would break on Visual Studio.
This changes the script to instead format the string as an array of hex
characters, not unlike what GResource does, so that builds can continue as
normal on Visual Studio builds as well.
https://bugzilla.gnome.org/show_bug.cgi?id=739001
We recently changed the uppercase licensing text to lower case. The
reference test that checks the contents of the about dialog has to be
fixed to reflect that change.
There is now a broadway-buffer.c source that needs to be built for this, so
add it into the projects. Since crypt() is no longer used, don't include
crypt.c in the builds, and so clean up the projects a bit.
This is what the old adwaita did, not having a better solution for
removing double borders, better to have this back even if it can
be problematic in certain cases.
wayland doesn't strictly follow the XDG_RUNTIME_DIR spec by falling back
to another directory in case the runtime dir is not properly set.
When this variable is unset, wayland will log an error to us, which we
treat as fatal, aborting the entire program.
Skip ourselves all the trouble and don't try to bring up the wayland
backend when we know it will fail in this way.
https://bugzilla.gnome.org/show_bug.cgi?id=738873
... and make it the default. This takes over the meaning from "none" for
this property in that it draws the fallback builtin image.
"none" now literally means no image will be drawn.
This commit adds a mode to GtkScrolledWindow in which it puts
narrow, auto-hiding scrollbars over the content, instead of
allocating room for the scrollbars outside of the content. We
use traditional scrollbars if we find a mouse or if overlay
scrolling has explicitly turned off.
For test purposes, GTK_TEST_TOUCHSCREEN can be used to get
overlay scrolling even in the presence of a mouse. The
environment variable GTK_OVERLAY_SCROLLING can also be used
to force overlay scrolling on or off.
This is just meant as a prototype for how we can show a
scroll position indicator for touch. This uses GTK_POLICY_EXTERNAL
to hide the scrolled windows scrollbar while still allowing
scrolling.
This will be used to identify a scrollbar is being dragged - we
don't actually need the style class; another way to keep track
of the dragging status would be ok too.
When a getter function (like get_color()) is called and the passed in
state doesn't match the current state returned via get_state(), we used
to do a trick: We called save()/set_state() on the context before
getting the values.
Unfortunately, since 3a337156d1 this
has the unfortunate side effect that it also creates a child element.
This breaks various old codebases (spinbutton has been fixed in
998feeb2bc, Webkit is fixed in
https://bugs.webkit.org/show_bug.cgi?id=137803 ) unfortunately.
So instead, look up the values manually ensuring that no child element
is created but the correct state is used.
Keeping them is a bad idea now where the widget paths are actually
changed by a save(). And almost all of the time, state or style classes
will be changed anyway.
Looking them up again is just a hash table lookup anyway.
GtkCssNodeDeclaration is a new struct with copy-on-write semantics.
It encapsulated the properties used to define a node in the CSS tree.
The idea is to use it in various places for caching, in particular as
key in hash tables.
This signal is emitted whenever user scrolling hits the overshoot
edge in the given direction. May be useful to add "reload" or "load
more" behaviors in apps.
https://bugzilla.gnome.org/show_bug.cgi?id=738534
With my latest changes we have a darker text color for views and
entries (which I assume are content), the places sidebar is totally
chrome though so it needs the chrome text color back.
This can be used by applications to indicate that a paned is expected
to be actively used by the users for configuring the UI, and needs
a prominent handle.
https://bugzilla.gnome.org/show_bug.cgi?id=738860
Implement Federico's suggestion:
In single-selection mode, just use the selected row,
In multi-selection mode, use the cursor row as long as it is
in the selection.
https://bugzilla.gnome.org/show_bug.cgi?id=154709
It doesn't report -I${prefix}/include in cflags, even if .pc
files explicitly put it there. This was breaking the build
outside of a jhbuild shell when libepoxy is in the jhbuild tree
but not in /usr.
There are legit reasons for GtkGesture::handle_event to return FALSE,
GtkGestureSingle objects should be unsetting the current button/sequence
if that happens, in order to avoid inconsistent states.
https://bugzilla.gnome.org/show_bug.cgi?id=738591
When gtk_window_set_titlebar (win, NULL) is called, we were taking
an early exit and forgot to re-map the window. This does not normally
happen in practice, but glade is about to get a 'csd' switch which
lets one toggle back and forth between titlebar and no titlebar.
With the recent save-is-child changes, using
gtk_style_context_get_padding (context, different_state)
will now open a subelement.
This is not what we want, so we check the state whenever we get the
button contexts.
Now it's based of fg color, so the list row gets darker on the
bright variant and brighter on the dark variant, similarly to what
we do for spinbutton buttons.
Flat buttons gets the button decoration on hover, while transitioning
the decorations of adiacent flat buttons are both shown (one fading in
and the other fading out) so the borders clashes, since normally there's
no spacing between them, to avoid it the transition on the normal state
is set to none and added back to the hover state, so the decoration
won't fade out. To make the transition more evident the duration is
increased.
This is mostly useful for fallback testing.
I suppose if people want finer grained GL ability testing, they can use
Mesa environment variables to tune things.
This is a change for how CSS is applied.
Previously, subelements (I'll take GtkEntry icons as an example) were
treated as having the same parent as the regular elements. So a selector
such as
.entry
would match an entry inside a window. But it'd also match the icon image
inside the entry. So CSS like
.entry { padding: 10px; }
would add 10px of padding to both the entry itself and to the icon image
inside the entry, so the icon would effective have 20px padding. To get
around that, one would have to unset it again like so:
.entry { padding: 10px; }
.entry.image { padding: unset; }
This is getting more and more of a problem as we make subelements
respect more properties that aren't inherited by default anyway, like
backgrounds and padding/margin/border.
This patch has one caveat though: It makes calling
gtk_style_context_save() the first time have an important side effect.
It's important to audit code to make sure it is only used for
subelements.
And last but not least, this patch is only useful if code unsets
parent's style classes that it doesn't want to apply any longer. Because
style classes are inherited by default (and I don't think we want to
change that), the example will still apply until the subelements no
longer contain the .entry style class.
If the menubar has an app-menu popover, and it is shown at the time of
disposing the window, it will attempt to transfer focus back to the
previous focus widget when undoing modality, even though the dispose()
code already did set_focus(NULL) previously.
At the time the popover is removed, there aren't many hints as to whether
the toplevel or the focus widget are being destroyed (ie. not still under
in_destruction), so just swap the order of these two calls.
For every other popover, this would all happen within dispose/destroy,
which is handled better.
This way we don't have to clear/refill the model every time but can keep
the existing model and only update the values.
A nice side benefit is that running an update keeps the current selection.
Its not really reasonable to handle failures to make_current, it
basically only happens if you pass invalid arguments to it, and
thats not something we trap on similar things on the X drawing side.
If GL is not supported that should be handled by the context creation
failing, and anything going wrong after that is essentially a critical
(or an async X error).
We make user facing gl contexts not attached to a surface if possible,
or attached to dummy surfaces. This means nothing can accidentally
read/write to the toplevel back buffer.
This adds the new type GdkGLContext that wraps an OpenGL context for a
particular native window. It also adds support for the gdk paint
machinery to use OpenGL to draw everything. As soon as anyone creates
a GL context for a native window we create a "paint context" for that
GdkWindow and switch to using GL for painting it.
This commit contains only an implementation for X11 (using GLX).
The way painting works is that all client gl contexts draw into
offscreen buffers rather than directly to the back buffer, and the
way something gets onto the window is by using gdk_cairo_draw_from_gl()
to draw part of that buffer onto the draw cairo context.
As a fallback (if we're doing redirected drawing or some effect like a
cairo_push_group()) we read back the gl buffer into memory and composite
using cairo. This means that GL rendering works in all cases, including
rendering to a PDF. However, this is not particularly fast.
In the *typical* case, where we're drawing directly to the window in
the regular paint loop we hit the fast path. The fast path uses opengl
to draw the buffer to the window back buffer, either by blitting or
texturing. Then we track the region that was drawn, and when the draw
ends we paint the normal cairo surface to the window (using
texture-from-pixmap in the X11 case, or texture from cairo image
otherwise) in the regions where there is no gl painted.
There are some complexities wrt layering of gl and cairo areas though:
* We track via gdk_window_mark_paint_from_clip() whenever gtk is
painting over a region we previously rendered with opengl
(flushed_region). This area (needs_blend_region) is blended
rather than copied at the end of the frame.
* If we're drawing a gl texture with alpha we first copy the current
cairo_surface inside the target region to the back buffer before
we blend over it.
These two operations allow us full stacking of transparent gl and cairo
regions.
This is a new function that gets called every time we're drawing
some area in the Gtk paint machinery. It is a no-op right now, but
it will be required later to keep track of what areas which
we previously rendered with GL was overwritten with cairo contents.
First of all we track the current update area during an
update in window->active_update_area. This will be used later
in end_paint to know the damaged area.
Secondly we keep track of old update areas for the last 2
frames. This will later allow us to reuse old framebuffer
contents in double or tripple buffer setups, only painting
what has changed since then.
If we want to use OpenGL in GDK then we have two choices; either:
- find the GL headers on each platform
- do extension discovery
- implement all the crazy dlopen()/dlsym() dispatch tables
*or* use libepoxy, which shields us from all this madness and provides a
decent layer for GL clients to use, without creating its own namespace.
Epoxy is also used by other projects, like Xorg and piglit, and it's
portable to all the platforms GDK cares about.
https://bugzilla.gnome.org/show_bug.cgi?id=119189
Request "sides-supported" and "sides-default" attributes through
IPP if there is no PPD for selected printer.
Pass "sides" option with other options in printer_get_options().
Add function setup_ipp_option() for creating of IPP option
of given name with passed choices and default value.
Mark such an option as "is-ipp-option" so we can distinguish it
later.
https://bugzilla.gnome.org/show_bug.cgi?id=725441
Before 5e325c4, the default BitGravity was NorthWestGravity.
When static gravities were removed in 5e325c4, the BitGravity regressed
to the X11 default, Forget. Forget causes giant graphical glitches and
black flashes when resizing, especially in some environments that aren't
synchronized to a paint clock yet, like XWayland.
I'm assuming that the author assumed that the default of BitGravity was
NorthWestGravity, which is the default of WinGravity. Just go ahead and
fix this regression to make resizing look smooth again.
When the searchbar is hidden, a 1-pixel-high piece of it is
still peeking out, because visible widgets are always allocated
at least 1x1. Work around this by setting child-visible to FALSE
in this situation.
https://bugzilla.gnome.org/show_bug.cgi?id=724096
The last change accidentally removed the later restore, and
left the earlier, so we ended up with a restore-save sequence.
Thankfully, GtkStyleContext warns about this.
Apparently it's not possible in GtkTextView to say "this style should
apply to all text, including newly inserted text. Or I'm just too stupid
to use its API.
So instead, keep using override_color().
There is not much room in the inspector window; squeezing a
tree and a detailed view in the same page is not great. Instead,
make the details a separate page.
Currently writing wl_data_offer data into the fd is 1) synchronous, which
is noticeable when transferring large amounts of data, and 2) buggy, write()
error checking is done on the accumulator, breaking both the written data
accounting and error checking itself.
Fix both by making writes asynchonous through GOutputStream, the operation
is spun off and either finished, or cancelled if new data is stored in the
selection while the transfer is active.
When a drive is ejected or a volume unmounted the current directory
doesn't change most of the times being empty or being a directory that
user shouldn't take care about, like /run/media
Seems more useful to change to $HOME directory in that case so the user
can see something useful and familiar just after unmounting.
https://bugzilla.gnome.org/show_bug.cgi?id=737983
Currently we change the current location if we click the eject button of
a mount.
Check whether the user actually clicked the eject button and don't
change location in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=737983
Query printer via IPP for paper sizes if there is no
or empty PPD file.
Parse "media-supported" and "media-size-supported" attributes for list
of paper sizes. Parse "media-default" and "media-col-default" attributes
for default settings.
https://bugzilla.gnome.org/show_bug.cgi?id=725441
Instead of making assumptions about enum value ordering,
introduce a helper function to determine policy values
for which the scrollbar may be visible.
Add a new policy, GTK_POLICY_EXTERNAL, which hides the scrollbar,
but does not force the scrolled windows size to be determined by
its child. This can be used to keep two scrolled windows in sync,
while sharing a single scrollbar.
https://bugzilla.gnome.org/show_bug.cgi?id=730730
As an actionable (inherited from GtkButton), a GtkMenuButton
should not set its own sensitivity when it has an action-name
set, but just follow the enabled state of the associated
action.
https://bugzilla.gnome.org/show_bug.cgi?id=738083
Dimmed inner colorswatch shadow to make brighter colors looks nice,
increased the padding to make button states more evident, 0 border
radius to match the padding change and no colorswatch shadows when
the button is insensitive.
The code did weird things with drawing backgrounds sometimes but not
really. Now it does this:
(1) render a background
(2) render a frame
(3) render an icon
- if no icon exists, draw the generic handle icon
We want to render a background *and* the current color (if there is
one).
This also adds a custom function gtk_render_add_content_path() which
adds the path of the current content area to a cairo_t.
This adds a CSS box (complete with padding and border) for the icon. The
box is even drawn when no icon is present. Use the ".image" as the style
class here instead of -active-color-badge.
Use this box to draw the circle around the selection icon in Adwaita.
auth_info should be a NULL-terminated array as it is used in
e.g. g_strdupv invocations iterating over its elements until
a NULL element is encountered.
https://bugzilla.gnome.org/show_bug.cgi?id=737777
This is a convenient shortcut for a common case. It is implemented
by adding a .monospace style class to the text view, and letting
the theme decide about the monospace font to use.
Same here: We need to synchronize the visible child with the
selected row when setting a stack on the sidebar. I've noticed
this problem in the sidebar example in gtk3-widget-factory.
The documentation explicitly states that 0 is an allowed value for using
the same scale as the window. This 0 value is also explicitly checked
down in the call chain and handled.
Drawing text with Pango is quite expensive, and drawing text and also
blurring it is *really* expensive. To prevent us from drawing a lot of
text and then blurring it a lot is *really* expensive.
We now cache the blurred pixels for the last layout and shadow we made,
which means we can repeatedly draw labels with a blurred text-shadow
extremely fast.
To detect whether the shadow is up-to-date, we track the serial of the
PangoLayout alongside the radius of the box shadow. We don't support
inset shadows nor spread on text-shadow, so we don't need to track
these.
There is no need for a critical warning just because somebody
asked for a property that is not meaningful for the device.
Just document it as not useful for keyboard devices.
We get multiple notifications from the bookmark manager when
something changes. Every time, we reconstruct the sidebar contents
completely, by clearing the store. The bookmarks are added with
async calls though, and the code was forgetting to cancel outstanding
async requests, leading to multiple instances of the same bookmark
getting added. Use the cancellable we already have to prevent that.
This could be made much more efficient by not recreating the entire
sidebar quite so often (3-5 times for a single bookmark rename).
https://bugzilla.gnome.org/show_bug.cgi?id=737679
Parent is guaranteed to not be NULL. It can only ever be NULL for root
windows and root windows cannot be created with gdk_window_new() and
gdk_window_ensure_native() will exit early because they already are
native.
Also, both functions would crash a few lines below where parent gets
dereferenced.
I've noticed a missing image show up in my print dialog, where
the printer reported "printer-paused" as icon. Rearrange things
so we always fall back to "printer" for printer icons.
We still need to possibly scan the toplevel after selecting
a widget, since we don't monitor the list of toplevels, so
the window may not be in our tree yet. This was broken in
commit e7bd73f2b0.
2014-10-03 22:12:54 -04:00
1343 changed files with 266702 additions and 187209 deletions
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
<pathinkscape:connector-curvature='0'd='m 446.21875,-34 c -0.64785,0 -1.1875,0.539653 -1.1875,1.1875 l 0,4.625 c 0,0.647847 0.53965,1.1875 1.1875,1.1875 l 11.65625,0 c 0.64785,0 1.15625,-0.539653 1.15625,-1.1875 l 0,-4.625 c 0,-0.647847 -0.5084,-1.1875 -1.15625,-1.1875 l -11.65625,0 z m 0,1 11.65625,0 c 0.11114,0 0.15625,0.07636 0.15625,0.1875 l 0,4.625 c 0,0.111144 -0.0451,0.1875 -0.15625,0.1875 l -11.65625,0 c -0.11114,0 -0.1875,-0.07636 -0.1875,-0.1875 l 0,-4.625 c 0,-0.111144 0.0764,-0.1875 0.1875,-0.1875 z'id='rect7030'style='font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-indent:0;text-align:start;text-decoration:none;line-height:normal;letter-spacing:normal;word-spacing:normal;text-transform:none;direction:ltr;block-progression:tb;writing-mode:lr-tb;text-anchor:start;baseline-shift:baseline;color:#000000;fill:#bebebe;fill-opacity:1;stroke:none;stroke-width:1;marker:none;visibility:visible;display:inline;overflow:visible;enable-background:new;font-family:Sans;-inkscape-font-specification:Sans'/>
<pathinkscape:connector-curvature='0'd='m 446.21875,-26 c -0.64785,0 -1.1875,0.539653 -1.1875,1.1875 l 0,4.65625 c 0,0.647847 0.53965,1.1875 1.1875,1.1875 l 11.65625,0 c 0.64785,0 1.15625,-0.539653 1.15625,-1.1875 l 0,-4.65625 c 0,-0.647847 -0.5084,-1.1875 -1.15625,-1.1875 l -11.65625,0 z m 0,1 11.65625,0 c 0.11114,0 0.15625,0.07636 0.15625,0.1875 l 0,4.65625 c 0,0.111144 -0.0451,0.1875 -0.15625,0.1875 l -11.65625,0 c -0.11114,0 -0.1875,-0.07636 -0.1875,-0.1875 l 0,-4.65625 c 0,-0.111144 0.0764,-0.1875 0.1875,-0.1875 z'id='rect7811'style='font-size:medium;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-indent:0;text-align:start;text-decoration:none;line-height:normal;letter-spacing:normal;word-spacing:normal;text-transform:none;direction:ltr;block-progression:tb;writing-mode:lr-tb;text-anchor:start;baseline-shift:baseline;color:#000000;fill:#bebebe;fill-opacity:1;stroke:none;stroke-width:1;marker:none;visibility:visible;display:inline;overflow:visible;enable-background:new;font-family:Sans;-inkscape-font-specification:Sans'/>
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.
