Tristan Van Berkom wrote:
Just use g_io_channel_add_watch(), which installs a GSource for you which
holds an internal reference to the io channel [ ... ]
Ah, yes, that will definitely be a lot simpler. I actually encountered
IO channels in some open source code I read a while back, but
I'm trying to integrate a raw socket based communication link into a
main loop using GMainLoop - on the server-side, i.e. the process that
listens for connections on the sockets. Does anyone have any good
examples on how this might be done? I suppose I want a callback, doing
accept() on the
I just got a crash when using a FileChooser with/
GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER/ on gtk 2.12.5 under win32. Parts
of the call stack is included below. This is after I've created the file
chooser dialog, run gtk_dialog_run() for it, destroyed it, then called
gtk_dialog_run() *for a
I have an odd feeling that this is a stupid question because I'm
overlooking something very obvious, but does Alt+Mouse button click have
any special meaning in Gtk?
What I mean to say is, I have an application where I draw to a drawing
area widget, and also handle various events for it by
richard boaz wrote:
not sure what's could be going wrong since you didn't supply any code,
but...
I thought I would ask some fundamental questions before I presented a
lot of complex code that would more likely than not only confuse
everyone... Or alternatively, I don't want to spend time on
Hans Nieser wrote:
On Wed, 2008-07-09 at 11:56 +0200, Toralf Lund wrote:
[ ... ]
Ah, but it's not the ALT key I don't see, it's the actual button
click/release. That is, the callback simply isn't called, so if I do:
gboolean mouse(GtkWidget *widget, GdkEventButton *event, gpointer nil
Andrew E. Makeev wrote:
В Срд, 09/07/2008 в 10:32 +0200, Toralf Lund пишет:
I have an odd feeling that this is a stupid question because I'm
overlooking something very obvious, but does Alt+Mouse button click have
any special meaning in Gtk?
What I mean to say is, I have an application
Paul Davis wrote:
On Tue, 2008-06-03 at 09:36 +0200, Toralf Lund wrote:
varun shrivastava wrote:
you can access GtkAllocation structure which stores the x, y, width
and height allocated to a widget
That will (only) give me the size of an existing widget, won't
Paul Davis wrote:
On Tue, 2008-06-03 at 13:03 +0200, Toralf Lund wrote:
Paul Davis wrote:
On Tue, 2008-06-03 at 09:36 +0200, Toralf Lund wrote:
varun shrivastava wrote:
you can access GtkAllocation structure which stores the x, y, width
and height
Tor Lillqvist wrote:
GLib-GObject:invalid uninstantiatable type `invalid' in cast to
`GdkWindow'
Then a segfault. This is with Gtk version 2.12.5 on win32.
There are no segfaults as such on Windows, but yeah,
Hmmm... I suppose not, but gdb under MinGW does refer to SEGV...
I know
I'm trying to use some old code using old combo widgets, i.e.
GtkCombo, not GtkComboBox. It doesn't work very well. If I do some sort
of interaction with the pulldown lists, then close my window, I get the
message:
GLib-GObject:invalid uninstantiatable type `invalid' in cast to `GdkWindow'
How exactly is the file chooser expected to behave when the file
chooser action is set to GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER?
I thought I would get more or less exactly the same operation as for
|GTK_FILE_CHOOSER_ACTION_SAVE, except that plain files would be hidden
or grayed out, but based
Tor Lillqvist wrote:
Is this the way it's supposed to be,
Don't think so. What you describe indeed sounds contrary to reasonable
expectation.
or should I consider this as a bug (and perhaps file a bugzilla report)?
Yes please.
I just noticed a minor inconsistency in the win32 version of Gtk: If I
open a transient window like a file chooser, then press the minimize
button on the frame of the main window, both windows, i.e. the main
window and the transient, get minimized. If, on the other hand, I use
the minimize all
Tor Lillqvist wrote:
Our Gtk-based Win32 application have a minimize behaviour that's
confusing to many users wrt handling of transient windows and also
torn-off menus.
There has been lots of issues in GTK+ on Windows related to the
handling of transient windows, focus and activeness,
Maybe a stupid question, but:
A few Gtk revisions ago, I was pleased to find that the FileChooser was
updated so that it would allow me to type in filenames by hand with
auto-completion and all, into a Location: entry in the actual
selection window (once it's enabled.) Like I said, rather nice
Toralf Lund wrote:
Maybe a stupid question, but:
A few Gtk revisions ago, I was pleased to find that the FileChooser was
updated so that it would allow me to type in filenames by hand with
auto-completion and all, into a Location: entry in the actual
selection window (once it's enabled
This is something I've wondered about for a long time. Or maybe I solved
the problem once, but I can't find the code now:
Is there a simple way to tell Gtk to do exactly what it would do when if
the user pressed the window (window manager) close button, when working
with a Window widget?
I
Emmanuele Bassi wrote:
On Fri, 2007-12-14 at 12:55 +0100, Mathias Hasselmann wrote:
I mean, usually gtk_widget_destroy() or gtk_widget_hide() will be called
as part of the handling, but those functions are not what I'm looking
for; I also want to execute the full event handler chain
. Or possibly
100 - page size, but you know what I mean... Can I get it to change
the value to 10 instead, i.e. to essentially start counting from the
beginning when the end is reached?
--
Toralf Lund
___
gtk-list mailing list
gtk-list@gnome.org
http
[ ... ] And I don't see
the GtkEntry in question from inside signal handers for buttons, menu
items etc, of course...
You do. When the action that requires to commit the update
first occurs, use gtk_window_set_focus() (you should be able
to see the window) to get the focused
In one of our applications, we have lots of GtkEntry widgets that
mirror values also stored in variables. For reasons I won't go into
here, we don't want to change the variables in question each and every
time a character is typed, so we are doing updates on the activate and
focus-out, which
I just got the following message while using the FileChooser in Gtk
2.10/Win32:
Gtk:idle activate multiple times without clearing the folder object first.
I'm not yet sure about the exact conditions that trigger this, but while
I'm trying to find out, perhaps someone can tell me what exactly
2. Type #0026FF into the Color name field, then press Enter.
3. Click the eyedropper button.
4. Point at the current colour display field inside the dialog, then
click (so as to select the colour.)
Expected result:
Nothing changes - as I've just selected what was already
I've encountered a problem that I think might be a bug in the colour
picker widget, but I thought I'd run it through the list before adding
an entry to Bugzilla. (But I've searched for bugs, and found nothing.)
Simply put, the problem may be reproduced as follows:
1. Open a ColorPickerDialog
2.
Is there any way I can get at the Eyedropper button inside a
GtkColorSelection widget? From the code, I mean. Or alternatively, is
the eyedropper functionality available independently of the widget?
Some of our users think that clicking a button to activate the selection
dialog, then clicking
I'm having a problem with a Win32/MinGW port of a Gtk program that works
quite all right under X11/Linux. To make a long story short, when I open
a certain window, I get the message:
Gdk:gdkwindow-win32.c:702: CreateWindowEx failed: Not enough storage is
available to complete this operation.
Gdk:gdkwindow-win32.c:702: CreateWindowEx failed: Not enough storage is
available to complete this operation.
I understand on a superficial level what the message is about, of
course; the system has run out of some kind of resource,
Not really likely. The error message is probably
28 matches
Mail list logo
