On Wed, Oct 03, 2012 at 09:42:24AM -0500, Yury Alyaev wrote:
What is the right way to catch Enter pressing at the end of the
text input to GtkEntry. The obvious way is conecting the callback to
the activate signal, but for some reason documentation says
Applications should not connect to it.
I need to catch when the file has changed in a
GtkFileChooserButton. I thought connecting to file-set was
enough but this signal is not emitted when the user cancels
(although bug 555351 does not agree [1]). Here is the proof:
#include gtk/gtk.h
int main(int argc, char **argv)
{
GtkWidget
On Wed, 2012-10-03 at 20:18 +0200, David Nečas wrote:
On Wed, Oct 03, 2012 at 09:42:24AM -0500, Yury Alyaev wrote:
What is the right way to catch Enter pressing at the end of the
text input to GtkEntry. The obvious way is conecting the callback to
the activate signal, but for some reason
On Wed, Oct 03, 2012 at 10:23:12PM +0200, Nicola Fontana wrote:
I need to catch when the file has changed in a
GtkFileChooserButton. I thought connecting to file-set was
enough but this signal is not emitted when the user cancels
(although bug 555351 does not agree [1]). Here is the proof:
Il Wed, 3 Oct 2012 23:28:23 +0200 Rafał Mużyło
galtge...@gmail.com scrisse:
On Wed, Oct 03, 2012 at 10:23:12PM +0200, Nicola Fontana wrote:
I need to catch when the file has changed in a
GtkFileChooserButton. I thought connecting to file-set was
enough but this signal is not emitted when
On Thu, Oct 04, 2012 at 12:33:24AM +0200, Nicola Fontana wrote:
Il Wed, 3 Oct 2012 23:28:23 +0200 Rafał Mużyło
galtge...@gmail.com scrisse:
but the change on cancel was
recently fixed in bug . in regard of gtk 3.4 and 3.6 (unfortunately, not in
2.24 though, even if it seems to be only a
On Wed, Oct 3, 2012 at 7:42 AM, Yury Alyaev muta...@rambler.ru wrote:
What is the right way to catch Enter pressing at the end of the text input
to GtkEntry
gtk_entry_set_activates_default() is probably what you want.
___
gtk-app-devel-list mailing
On Wed, Oct 03, 2012 at 12:35:57AM -0400, Matthias Clasen wrote:
I have now created a glib-2-34 branch, so master is now open for
... GTask ...
Is this also intended, at least in the future, for things like
long-running calculations that need some monitoring/reporting of
progress not just the
Debarshi Ray rishi...@lostca.se writes:
Also to note is that non-GNOME (and even non-desktop) GLib-based
applications were seen in the wild. Consider, e. g., the OpenBSD
version of the Netcat command-line networking diagnostic tool (as of
the version currently in Debian stable [4].)
On Wed, 2012-10-03 at 08:20 +0200, David Nečas wrote:
On Wed, Oct 03, 2012 at 12:35:57AM -0400, Matthias Clasen wrote:
I have now created a glib-2-34 branch, so master is now open for
... GTask ...
Is this also intended, at least in the future, for things like
long-running calculations
Not a lot of serious feedback here, but I also worry about the
implicitness about this API. Its really not well defined what it does,
and the fact that it may change over time as functions are implemented
differently or new things support reversible just seems scary.
Hi Tristan!
I suggest you start by filing an enhancement bug against GtkImage for this.
Yes, I can do that. Just to make sure, I file a new bug for component gtk,
severity set to enhancement, and put somethign like Size request of GtkImage
into the title. Is this correct?
If you have a
Hello everyone,
I have several RadioButtons in the same group, but I would like that
when first shown they would all be un-active and when the user selects
one of them then have the expected behavior. Is this possible? I know
I've seen it somewhere, just not sure if somewhere using Gtk+3.
Best
On Thu, Oct 4, 2012 at 1:46 AM, Steffen Gutmann muib...@yahoo.com wrote:
Hi Tristan!
I suggest you start by filing an enhancement bug against GtkImage for this.
Yes, I can do that. Just to make sure, I file a new bug for component gtk,
severity set to enhancement, and put somethign like
I've just pushed publically wip/frame-synchronization branches for
Mutter and GTK+ that include my long-delayed work to get proper
synchronization going between the toolkit and the compositor. This
is the work that I spoke about and demo'ed at GUADEC.
The patches are also in bugs:
GTK+:
One of the concepts of the paint-clock work is that it also should be
used for event delivery and compression. The idea is that instead of
continually delivering events and possibly never getting to updating,
we batch up events and deliver them right before doing the other work
of the frame. This
Here's the dump of my current TODO list for finishing up the frame
synchronization work. If things on this list are things you
want to work on, speak up - there's more here than I'll be able to do in
any short amount of time.
Major Stuff Inside GTK+
===
* Implement paint
Some open questions in my head about the frame synchronization work:
* Is GdkPaintClock the right name? It might imply that it only has to
do about painting and not about other things like layout.
GdkFrameClock would be an alternative. GdkClock is possible but
likely too generic.
* For
18 matches
Mail list logo
