This is a similar question to one I asked last week, but I'm not spamming,
fishing for another response with a re-send. I actually made quite a bit of
progress towards a solution but ran into another tangle of confusion, and
possibly a Gtk bug (described below).
I am creating a GtkContainer su
on would be
carrying the GTK_NO_WINDOW flag.
Thanks,
Brian
--- On Tue, 11/23/10, Mike Massonnet wrote:
> From: Mike Massonnet
> Subject: Re: GtkButton, enter-notify signal, and GdkWindow
> To: "Brian Tietz"
> Cc: gtk-app-devel-list@gnome.org
> Date: Tuesday, November 23
I am creating two widget subclasses, one which is a subclass of GtkContainer
and one which is a subclass of GtkButton. Both need to receive the
enter-notify signal. I can successfully obtain the enter-notify signal fot
GtkButton in my_button_subclass_init:
g_gtk_button_mouse_enter_notify_
When creating a window, the application I'm working on won't know whether the
contents will fit onscreen or not. I won't go into details, but suffice it to
say that the contents can vary greatly in the required size. The window
manager deals with that just fine up to a point. But if a poorly
is only for sending events of type
GDK_CLIENT_EVENT, and no other. I'm not sure you can actually send
arbitrary event types to other apps using gdk. You may need to drop
down to the win32 APIs for that (or at least the gdk-win32 APIs).
-brian
___
Hate to answer my question, but sometimes finding the answer is the
process of quantifying the question.
I ran it generating and freeing 2500 elements 3 times. Seems that it
is freeing the memory. See output below.
brian
br...@davostro:~/school/Project/a5$ ./test_array_ptr
GLib Memory
_ptr_array_free(myAry, TRUE);
return 0;
}
--
Brian Lavender
http://www.brie.com/brian/
"There are two ways of constructing a software design. One way is to
make it so simple that there are obviously no deficiencies. And the other
way is to make it so complicated that there are no ob
for the same resource.
It is your typical dining philosopher problem. An atomic operation
is used in place of a mutex (may actually use a mutex or a semaphore
underneath), so that access to a resource is synchronized.
I haven't quite figured out the resource that is being guarded here, but
it look
pass arguments!
void load_array( GArray *(*garray)[NUM_ARYS] );
I will check out the g_ptr_array!
brian
On Sat, Feb 27, 2010 at 06:50:34PM -0800, Brian Lavender wrote:
> === simplearray2.c ===
>
>
> #include
>
> #define NUM_ARYS 5
>
> void load_array( GArray *(*garray)
\n", j);
for (i = 0; i < 10; i++)
g_print ("index %d value %d\n",
i, g_array_index (garrays[j], gint, i));
}
for (j=0; j < NUM_ARYS; j++)
g_array_free (garrays[j], TRUE);
}
On Sun, Feb 28, 2010 at 02:48:01PM -0800, Brian Lavender wrote:
> On Sat, Feb 27,
On Sat, Feb 27, 2010 at 10:06:46PM -0500, Tristan Van Berkom wrote:
> On Sat, Feb 27, 2010 at 9:50 PM, Brian Lavender wrote:
> > I guess the list stripped the attachments. The code is included in this
> > message.
> >
>
> Hi,
> First of all it would be help
Sorry, the second set of code is what I want to do, but if you run it,
the arrays have all the same values, instead of the values actually
inserted, not quite what I had wanted.
On Sat, Feb 27, 2010 at 10:06:46PM -0500, Tristan Van Berkom wrote:
> On Sat, Feb 27, 2010 at 9:50 PM, Brian Laven
I guess the list stripped the attachments. The code is included in this
message.
brian
On Sat, Feb 27, 2010 at 06:47:30PM -0800, Brian Lavender wrote:
> I was experimenting with creating an array of arrays. Maybe I shouldn't
> be using GArray but something different such as pointer
know if I have a problem with
operator precedence or if the GArrays point to just one array.
The two programs are the following.
simplearray.c - loads just one array
simplearray2.c - loads an array of arrays
Any input is appreciated.
brian
--
Brian Lavender
http://www.brie.com/brian/
"
ed at this point. Any pointers would be
appreciated. I'd rather not have to write my own GtkMenuShell
subclass, but if people here think that's the best (or least-worst)
way to go, I'll do it.
Thanks,
Brian
___
gtk-app-devel-list mailing
Then I write to that
pipe in my signal handler. When the main loop wakes up again, it'll run
the IO watch's callback function. See:
http://git.xfce.org/xfce/libxfce4util/tree/libxfce4util/xfce-posix-signal-handler.c
for some example code. It's simple and does
e lower level event interface?
I usually use gdk_window_add_filter() on the root GdkWindow, after
gdk_window_set_events().
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
is that the widget's size is not known until the widget gets
> visible
> so I need to workaround that.
Without thinking about this too much (so this may not fit your code or
use model), you could defer placing widgets in subcontainers until the
container is realized. At that point you&#x
ocs, instead of just
"Foo".
2. I can't seem to figure out how to get documentation for signals
and properties into the docs.
3. Possibly related to #1, I'm not sure how to make the docs
understand the class hierarchy. The \extends command in doxygen
doesn't seem
kEditable-changed
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
On 09/30/2009 04:57 PM, John Coppens wrote:
> On Wed, 30 Sep 2009 16:38:10 -0700
> "Brian J. Tarricone" wrote:
>
>> That's odd. Are you sure you don't have mixed versions of glib
>> installed somehow?
>
> I was convinced that I hadn't, be
On 09/30/2009 04:25 PM, John Coppens wrote:
> On Wed, 30 Sep 2009 16:12:50 -0700
> "Brian J. Tarricone" wrote:
>
>>> if (G_LIKELY ((gpointer) g_atomic_pointer_get (value_location) !=
>>> NULL)) return FALSE;
>>> else
>>> return g_o
gt; while loop until the idle function removes itself by returning FALSE.
Yes, that's expected. And idle function is *always* ready to run, and
so gtk_events_pending() will *always* return true if an idle function is
present.
-brian
___
g
ondary thread)
Yes, also fine.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
equests the height (and paints the box
border) based on the font size.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
o it uses
GtkEventBox's impl), then it prints "IT WORKS!" as you'd expect.
Perhaps perusing gtkeventbox.c might help you figure out what else is
needed if you really want to just subclass GtkWidget.
-brian
___
gtk-app-devel-list
o it uses
GtkEventBox's impl), then it prints "IT WORKS!" as you'd expect.
Perhaps perusing gtkeventbox.c might help you figure out what else is
needed if you really want to just subclass GtkWidget.
-brian
___
gtk-app-devel-list
d I'm
> certain that the "widget_class->event = &any_event_r" line really does
> execute.
>
> Any suggestions?
You're setting ->event to a pointer to a pointer to a function when all
it wants is a pointer to a function.
-brian
__
on themes. Nothing at all (at least that I can find)
pertaining to how widget sizing is affected by GNOME Appearance Preferences
selection.
Thanks,
Brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
On Tue, Jul 21, 2009 at 17:57, Brian Tietz wrote:
>
> I noticed that if I create a GtkButton, call gtk_widget_show for the button,
> then call gtk_widget_size_request, it returns a guesstimate. With my current
> theme selection, this turns out to be a few pixels too small.
>
>
on the fly, the display server must be able to somehow notify
the existing windows that this has occurred. In either case, how does this
work? The "Understanding Metacity Themes" GNOME library documentation doesn't
cover this aspect of themes at all - what to expect from
GET_RTF },
{ "STRING",0, TARGET_STRING },
{ "TEXT", 0, TARGET_TEXT }
};
Is it possible that the Mac clipboard system uses UTIs[1] instead of
mime types to identify content? Perhaps try "public.rtf" as the target
string and
b world?
Not really on-topic for this list, but check out libgudev or DeviceKit.
Or HAL, but that's slowly being phased out.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
sure about the win32
issues, though.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
sure about the win32
issues, though.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
wrong?
Try this:
WnckScreen *wnck_screen = wnck_screen_get_default();
wnck_screen_force_update(wnck_screen);
... before your wnck_window_get() call.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailma
at the key
regardless.
And besides, even if you do find a solution for GNOME, what about people
who run KDE? Xfce? LXDE? *box? Ratpoison? ..
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
On 05/27/2009 09:45 PM, Emmanuel Rodriguez wrote:
On Wed, May 27, 2009 at 9:04 PM, Brian J. Tarriconewrote:
Bill Farmer wrote:
I am porting a native windows application to linux gtk. I want to stop the
alt-spacebar key combination popping up the application window menu. This
can be done in
fficial release copies of the gtk 2.x source
include gdk. Where did you get your copy?
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
t;%20"
They're URI-encoded, so you'll need to decode such sequences.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
;t have needed color:
You really just can't use this method at all. Some widgets won't have a
color as a background; they'll have a pixmap. You won't be able to
paint it using this method.
-brian
___
gtk-app-devel-list m
tk_widget_destroy() will always destroy all child widgets in
addition to the widget you pass it.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
x27;d
likely be saving yourself some time and frustration by learning how to
use GtkTreeView properly.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Don't use GtkList or GtkTree. They've been deprecated for... I dunno...
7 or 8 years now, and are unmaintained. You should be using GtkTreeView
in conjunction with a GtkTreeStore or GtkListStore.
-brian
Dave Luttinen wrote:
2nd post. I'm just getting warmed up .
Brian J. Tarricone wrote:
[EMAIL PROTECTED] wrote:
For non-console apps, MSDN says I need to set up a
WindowProc callback to catch WM_QUERYENDSESSION messages.
But to register it, it seems I need hWnd from the main
window which is somewhere hidden by gtk+...
That's odd -- on X11, yo
ugh, g_signal_handlers_unblock_matched() should
take a GCallback as the 6th param, not a gpointer. C just doesn't
care, while C++ does.)
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
backtrace() and backtrace_symbols() (or
backtrace_symbols_fd()). I've never used it myself, but that might be
what you're looking for.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
ng saved?.
The documentation on quarks should tell you all you need:
http://library.gnome.org/devel/glib/stable/glib-Quarks.html
If not, please ask specific questions about specific sections of the
documentation that you don't understand.
-brian
___
imum version
(say, 2.8), then you should develop against that version.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Roland Roberts wrote:
I have a notebook where one of the tabs is another notebook. When the
device which corresponds to that tab is disconnected, I want to make the
tab insensitive. So in the callback I have something like this:
g_object_set(tab_widget, "sensistive", FALSE, NULL);
When I
ike to start
off showing 3 columns and 4 rows, or whatever.
Is there any way to do this without writing a bunch of nasty hacky code?
It seems like these widgets are much less useful without some sort of
intelligent autosizing.
-brian
___
gtk-
aking the library's ABI. A side-effect of this
is that you can't allocate one statically.
I imagine there are other reasons as well, but this was the first that
came to mind.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
I am having a problem with my gtk program doing a seg fault after
running for a long period of time. My application redraws the screen
with quite a high frequency. I decided to to creating a tiny test
program that simply sets icons on a toolbar over and over to see if I
could replicate the pro
signal",
> G_CALLBACK (callback), data);
Definitely not this one... *waves arms* GtkObject doesn't exist! *waves
arms*
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
tkWidget
> *tlwin=gtk_widget_get_toplevel(GTK_WIDGET(menuitem));
> gtk_widget_hide(tlwin);
>
> Any ideas why the main window is still there?
The toplevel of a menu item is the GtkMenu it's in, not your window.
Assuming I'm understanding correctly what you&
Tom Machinski wrote:
> On Fri, May 23, 2008 at 9:52 AM, Brian J. Tarricone <[EMAIL PROTECTED]>
> wrote:
>
>> Well, it works here, using straight C. I don't really know Python, so I
>> can't really say why it wouldn't work there.
>
>
> Thanks
Tom Machinski wrote:
> On Thu, May 22, 2008 at 11:52 PM, Brian J. Tarricone <[EMAIL PROTECTED]>
> wrote:
>
>> gtk_window_set_focus_on_map() (or presumably
>> window.set_focus_on_map(False) in... whatever langauges you're using).
>
>
> Thanks Brian, anik
cus_on_map(False) in... whatever langauges you're using).
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
will likely be confused that yours behave differently, and will
assume your application is broken.
If you really want to do this, I believe you can unset the widget's drag
source and drag destination. See the API reference for how to do this.
-brian
; signal. You cannot
rely on signal callbacks being called in any particular order. In your
case, likely your handler (gtk_widget_destroy()) is getting called
before gtk_dialog_run()'s response handler, so you destroy the widget
before the gtk_dialog_run() response handler can run.
royed.
Probably your best bet would be to create your shared data in the
instance_init function on first run (just make it a static global var in
the file), and then refcount it. When your last instance is destroyed,
the refcount of the shared data drops to zero and you can destroy it.
gboolean return_val = g_file_move (g_file_source, g_file_dest,
> > G_FILE_COPY_OVERWRITE , NULL, NULL, NULL, &error);
>
> Be sure you're including libs and cflags for gio-2.0 as well.
And also make sure you're not just linking to the new glib at link
time, but also at
at that's less 'persistent', but no luck.
Am I missing something, or just going about this the wrong way?
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
On Mon, 14 Apr 2008 02:38:27 -0700 Brian J. Tarricone wrote:
> Anybody know of a way to munge a cairo_path_t into at
> least an approximate GdkRegion (i.e. suitable for
> gdk_window_shape_combine_region())? Or is there a better way to do
> this?
Figured out something, in c
munge a cairo_path_t into at
least an approximate GdkRegion (i.e. suitable for
gdk_window_shape_combine_region())? Or is there a better way to do
this?
Thanks,
Brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org
ndow that you
yourself have created *in the same application* that you call this from.
You can't use this, for example, to get a GtkWidget created in another
application -- there's no way to do that.
-brian
___
gtk-app-devel-list mai
(or just something incorrect) if you change
window managers while the particular app is running. Might no longer be
true, though; try it and see!
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org
can catch
these as Mike already noted.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
ure if it's even possible, and I doubt it would be
performant). That way lies madness, though...
-brian
>
> bye
>
>
> On Mon, Mar 17, 2008 at 3:12 PM, Damien Caliste <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> Le 17/03/2008, mbrz <[EMAIL P
ur the overhead of doing a composite operation...
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
er function
Sure it does:
http://library.gnome.org/devel/gtk/stable/GtkTreeView.html#gtk-tree-view-set-rules-hint
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Again you'd
probably want to just take a normal reference on the widget and then
unref it when you don't need it anymore. When you add a widget to a
container, it will take care of ditching the floating reference and
taking a real reference.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
erence to the actual functioning of the program. Just be
sure to use the class-cast macros when needed and you'll be fine.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
/leave(). A
bit simpler that way.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
o end up in a stable platform library
> when they're ready.
>
> Whats the meaning?
libegg is intended to be a sort of staging ground for experimental
widgets (and other functionality) that in theory will get merged into
gtk (or glib) if/whe
hreads.
Alternatively, you can *not* initialise gdk's threading at all, and use
g_idle_add() from your worker thread to schedule a function to call
gtk_widget_queue_draw_area() (the idle function will run in the main
thread, regardless of where you call g_idle_add()).
-brian
Michael McCann wrote:
> Brian J. Tarricone wrote:
>> Don't use gdk in the CPU-intensive function:
> Unfortunately, the GDK calls _are_ what is CPU-intensive. I believe the
> gdk_pixbuf_get_from_drawable() call is the most intensive. None of my
> "regular" code is
gdk_threads_enter()/leave() in the CPU-intensive
> function, but X gives me errors.
Don't use gdk in the CPU-intensive function:
while(1) {
sleep(1);
do_time_consuming_task();
gdk_threads_enter();
update_ui();
gdk_threads_leave();
}
You may need to factor out
; gtk_main( );
... unless you're doing something very very odd somewhere else.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
a gtk_widget_modify_font() Call on each widget,
> isn't it? :)
Not 100% sure, but this might be what you're looking for:
http://library.gnome.org/devel/gtk/stable/gtk-Resource-Files.html#gtk-rc-reset-styles
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
states that gtk_exit free
> all resources allocated for GTK+. gtk_exit is depricated and using
> exit is recommended.
It's deprecated for a reason -- it doesn't free all memory allocated by
gtk (or glib, or gobject, or gdk). It's not p
On Fri, 9 Nov 2007 14:40:53 -0600 ying lcs wrote:
> Can you please tell me how can I tell programmically if a GTKWidget
> is realized?
http://library.gnome.org/devel/gtk/stable/GtkWidget.html#GTK-WIDGET-REALIZED:CAPS
-brian
___
gtk-app
n assignment
to a temporary variable."
At any rate, I'm pretty sure all platforms that glib supports have the
same size pointers for all kinds of pointers, so it's probably moot.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
In
general, foo_get_bar() (where bar is an object) will not increment the
refcount on the returned bar. If the caller is required to unref (or
otherwise free) the return value, this should be stated in the API
docs. If nothing is stated, assume _get_bar()-type functions do
ing your app with
"-mno-cygwin" to avoid the cygwin dependency (and the non-Windows-ish
path structure cygwin uses). IIRC, most gtk packages are compiled that
way. As for the actual packaging, that's a question that's asked here
often; I'm sure
t
is not a good choice if you need to search it for particular items
often. Perhaps consider a GHashTable or GTree.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
if it's not your own widget, you can
connect to the widget's "expose-event" signal. Do your drawing in that
handler.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
label1),"Hi!");
}
Like I said, this runs w/o any compile errors, but when I run it in the
terminal, I see the following:
Gtk-CRITICAL **: gtk_label_set_text: assertion `GTK_IS_LABEL (label)' failed
So something went wrong. Can anyone help me out here?
Regards
call
gdk_threads_init(). This is still, IMHO, the easier and more reliable
approach (and will work on win32 as well as x11, whereas the above
approach will not).
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
/src/test/Release# gcc -o test test.c -I
>/usr/include/glib-2.0/ -I /usr/lib/glib-2.0/include/
Don't hard-code the include/library paths. Use pkg-config, something
like this:
gcc -o test test.c `pkg-config glib-2.0 --cflags --libs`
-brian
_
There may be a more elegant way
of handling that, but this'll work.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
want to look at the size-request and/or size-allocate signals
(on GtkWidget).
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Replying to myself...
On Tue, 29 May 2007 16:29:12 -0700 Brian J. Tarricone wrote:
>Actually, you might want to poke around in gdk/quartz/ inside gtk+
>SVN. I imagine autorelease pools are used in the MacOSX backend; maybe
>you can find some hints there as to what's best.
I was
t is only invoked
when it needs to be.
Actually, you might want to poke around in gdk/quartz/ inside gtk+
SVN. I imagine autorelease pools are used in the MacOSX backend; maybe
you can find some hints there as to what's best.
-brian
get machine, but that might
be acceptable in your situation.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
ped by gdk (by the application) using gdk_window_foreign_new().
To actually get all the toplevel windows, you could either use raw
Xlib, or there's probably something in libwnck that could help you.
-brian
___
gtk-app-devel-list mailing
On Wed, 16 May 2007 20:54:34 +0200 David Nečas (Yeti) wrote:
>On Wed, May 16, 2007 at 11:28:55AM -0700, Brian J. Tarricone wrote:
>
>> This is caused by the window manager, not gtk. It thinks the
>> application isn't responding because it takes too long to return from
>
ecause it takes too long to return from
the delete-event handler. You should probably return from the handler
and open a dialog box via an idle function or something like that.
-brian
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
you can do what the Gimp's screenshot app does: allow the user to
start the screenshot process, and then have it delay a couple seconds.
So the usage could be:
1. Tell the app to do a screenshot in 3 seconds. (Maybe
ctrl+PrintScreen could be "delayed capture".)
2. Pop up the men
gdk_window_foreign_new() on) to find all
the children of that window, and call gdk_window_foreign_new() on those
as well. At least that way gdk will always be able to see them. There
might be a way to grab new X windows as they appear as well, but I'm
not sure about that without digging a b
1 - 100 of 167 matches
Mail list logo
