Okay, I'm a newbie with Gtk. I'm designing with glade-3. I've got an
annoying problem with my about dialog.
I connected the help-about menu item to a callback that pops up the
dialog. The Credits and License buttons work fine. The Close
button does nothing. I've seen a bug report in one
Roland Roberts wrote:
How can I get the Close button to just hide the dialog so I don't have
to do the run/hide thing in the callback?
Ack, I posted this after fighting with it all day and then found my
answer right after posting.
Apparently, the correct signal is to attach a callback to the
On Fri, 15 Aug 2008 10:58:59 +0300 Tor Lillqvist wrote:
The documentation for g_thread_init() says (in the stable branch):
You must call g_thread_init() before executing any other GLib
functions in a threaded GLib program.
[..]
The real use case reported on gtk-list looked much more
Hi,
I'm wring a DnD feature, most knowledge is from
http://live.gnome.org/GnomeLove/DragNDropTutorial
I want to check whether action is GDK_ACTION_MOVE during drag-begin
phase, if yes, end this DnD. Unfortunately, I found that context-action
is always 0 during drag-begin even SHIFT is hold.
On Fri, Aug 15, 2008 at 11:51 AM, Brian J. Tarricone [EMAIL PROTECTED] wrote:
Yes to that last bit. If it really truly does matter that
g_thread_init() be called before other glib functions, then no *library*
should *ever* call g_thread_init(). If a library needs it, it should
check
For example, Glib have g_mem_set_vtable() that alose requires to be first.
Whee, so GLib documentation is internally inconsistent then. What a mess.
Current wording of the g_thread_init() documentation doesn't
introduces such ambiguility at least...
It doesn't? I think You must call
On Fri, 2008-08-15 at 15:45 +0300, Tor Lillqvist wrote:
For example, Glib have g_mem_set_vtable() that alose requires to be first.
Whee, so GLib documentation is internally inconsistent then. What a mess.
Current wording of the g_thread_init() documentation doesn't
introduces such
If your program uses threads (or other libraries that use threads),
then you must call g_thread_init() before calling any other GLib
function
It's not using threads that is the key point here. Calling
g_thread_init() is. That already changes some GLib functions to work
in different ways,
Am Fri, 15 Aug 2008 15:45:29 +0300
schrieb Tor Lillqvist [EMAIL PROTECTED]:
For example, Glib have g_mem_set_vtable() that alose requires to be
first.
Whee, so GLib documentation is internally inconsistent then. What a
mess.
Current wording of the g_thread_init() documentation doesn't
On Fri, Aug 15, 2008 at 3:45 PM, Tor Lillqvist [EMAIL PROTECTED] wrote:
For example, Glib have g_mem_set_vtable() that alose requires to be first.
Whee, so GLib documentation is internally inconsistent then. What a mess.
Current wording of the g_thread_init() documentation doesn't
introduces
On Fri, 2008-08-15 at 16:05 +0300, Tor Lillqvist wrote:
If your program uses threads (or other libraries that use threads),
then you must call g_thread_init() before calling any other GLib
function
It's not using threads that is the key point here. Calling
g_thread_init() is. That
2008/8/15 Matt Keenan [EMAIL PROTECTED]:
Hi,
Just doing a functions diff between Gtk 2.12.9 (Gnome 2.22) and Gtk 2.13.5
(Current for 2.24), and I've noticed about 60 function calls have been
removed.
See the (now removed) comment in gtkfilesystem.h:
/* This is a semi-private header; it is
On Fri, 2008-08-15 at 10:58 +0300, Tor Lillqvist wrote:
The documentation for g_thread_init() says (in the stable branch):
You must call g_thread_init() before executing any other GLib
functions in a threaded GLib program.
Is there a good reason to not compile separate threaded and
Hi,
on the Printing Summit in Atlanta in 2006 it was decided that the
standard print job format should be PDF and not PostScript any more, as
this has many advantages for the printing workflow, especially
reliability and quality.
Recently the needed CUPS filters for the PDF printing
Also, is there any specific reason *not* to call g_thread_init() in glib's
init routine by default anyway? Any penalties?
2008/8/15 Patrick Hallinan [EMAIL PROTECTED]
On Fri, 2008-08-15 at 10:58 +0300, Tor Lillqvist wrote:
The documentation for g_thread_init() says (in the stable branch):
On Fri, Aug 15, 2008 at 12:39 PM, Till Kamppeter
[EMAIL PROTECTED] wrote:
Hi,
on the Printing Summit in Atlanta in 2006 it was decided that the standard
print job format should be PDF and not PostScript any more, as this has many
advantages for the printing workflow, especially reliability
I meant a function marked with the constructor attribute.
2008/8/15 Matthias Clasen [EMAIL PROTECTED]
2008/8/15 Milosz Derezynski [EMAIL PROTECTED]:
Also, is there any specific reason *not* to call g_thread_init() in
glib's
init routine by default anyway? Any penalties?
What init routine
Am Fri, 15 Aug 2008 19:20:10 + (UTC)
schrieb Luke Kenneth Casson Leighton [EMAIL PROTECTED]:
folks, hi, just an update: i was advised kindly to look at
pywebkitgtk - which i downloaded and compiled from source, this
morning. _wow_ am i dead impressed with this project! the demo
browser
I'd argue mandatory init functions are more or less always wrong, they
all train-wreck in a similar way ... unfortunately every G-inspired
library seems to gratuitously have them.
If the init function has no args, then it should be possible for the
library to just deal with it and call it
I forgot g_thread_init takes args, so nvm the constructor version.
2008/8/15 Havoc Pennington [EMAIL PROTECTED]
I'd argue mandatory init functions are more or less always wrong, they
all train-wreck in a similar way ... unfortunately every G-inspired
library seems to gratuitously have them.
On Fri, 2008-08-15 at 19:20 +, Luke Kenneth Casson Leighton wrote:
it's _essential_ that GTK have similar such functionality. implementing these
features outside of the core gtk widget set - using pygtk2 alone - registers
on the awkward to literally impossible scale.
i haven't looked at
Havoc Pennington wrote:
If the init function does have arguments, then you end up with a
requirement that all libraries and modules calling it must call it
with the same args ... which isn't possible ... so init functions with
arguments are broken unless the *app* and never a library will
Am Freitag, den 15.08.2008, 15:06 +0200 schrieb Christian Dywan:
Am Fri, 15 Aug 2008 15:45:29 +0300
schrieb Tor Lillqvist [EMAIL PROTECTED]:
I think both is rather open for missunderstandings actually, before and
after the improvement of the g_thread_init documentation.
g_mem_set_vtable
Hi,
On Fri, Aug 15, 2008 at 5:55 PM, Brian J. Tarricone [EMAIL PROTECTED] wrote:
This breaks for libraries that require locking in threaded programs but
(obviously) not in non-threaded programs. You can get into a situation
where you call a lock() without threads initialised, then something
On Fri, 2008-08-15 at 01:51 -0700, Brian J. Tarricone wrote:
On Fri, 15 Aug 2008 10:58:59 +0300 Tor Lillqvist wrote:
... Should ORBit2 g_error() out if
it notices that it wants to use threads but g_thread_init() has not
been called, instead of calling it itself?
Yes to that last bit. If
On Fri, 2008-08-15 at 19:09 +0200, Milosz Derezynski wrote:
Also, is there any specific reason *not* to call g_thread_init() in
glib's init routine by default anyway? Any penalties?
As was pointed out, there's no GLib init routine, but from the
standpoint of a prominent library that we use a
2008/8/16 Andrew Cowie [EMAIL PROTECTED]:
[...]
At the very least across the rest of the GNOME stack, but if it's a
behaviour change we want to encourage not just there but beyond, I
wonder how could we go about incenting library authors to adopt this
pattern?
I would expect an author of a
27 matches
Mail list logo
