Re: Blacklisting themes?
On Wed, 2007-07-04 at 01:48 +0200, Milosz Derezynski wrote: > Reminds me all of http://bugzilla.gnome.org/show_bug.cgi?id=326249 > > I'm not sure this ever got a proper audit and all themes in general > could need one. Hmm, didn't that get fixed? At least for the well-known themes? > Does there exist a unittest suite for theme engines (and yeah i gues i > just volunteered to write one if it doesn't. heh :) ? AFAIK there's just Manu Cornet's torture test. It's not a unit test, but more of a "does the engine crash when it gets passed funny values?". Federico ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Gtk2::Assistant: Access to Buttons
On Jul 3, 2007, at 1:59 PM, Torsten Schoenfeld wrote:
> On Tue, 2007-07-03 at 18:21 +0200, Peter Daum wrote:
>
>> To make usage as convenient as possible, I would like the return
>> key to always
>> do the next logical step (focus the next entry field or trigger
>> the "forward"
>> button)
The first thing to come to mind is to be sure to set activates-
default on the Entries you add to your Assistant (it appears from
your code snippet that you did that already), and then set the
Forward button to be the default. But, there's no way to get to the
Forward button without either walking the widget tree or adding a
struct binding:
> Indeed, there seems to be no convenient way to do this in the Perl
> bindings. The only way I see is:
>
> $e1->signal_connect(activate => sub {
> $assistant->set_current_page ($assistant->get_current_page + 1);
> });
>
> Although they are not documented, the C header file does export struct
> members corresponding to the buttons:
>
> struct _GtkAssistant
> {
> GtkWindow parent;
>
> GtkWidget *cancel;
> GtkWidget *forward;
> GtkWidget *back;
> GtkWidget *apply;
> GtkWidget *close;
> GtkWidget *last;
>
> /*< private >*/
> GtkAssistantPrivate *priv;
> };
>
> So you actually can access the buttons from C and I wonder if we
> should
> provide accessors in the bindings?
The fact that there's a priv pointer *and* these members in the
instance seems to indicate that the idea is to make the buttons
available via the instance. However, gtk+ has a policy of "instance
members are private unless otherwise stated"... No other bindings
appear to wrap these instance members.
So, to the gtk+ developers: are these fields something we should
expose in language bindings?
--
One, two, free, four, five, six, sebben, eight, nine, ten, elebben,
twull, fourteen, sickteen, sebbenteen, eightteen, elebbenteen,
fiffeen, elebbenteen!
-- Zella, aged three, counting to twenty.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gnome-power-manager and IDLETIME (setting alarms using GDK)
I'm looking to implement X11 IDLETIME counter support for
gnome-power-manager. To do this I need to setup alarms on the new X11
counter (see attached code[1]) but obviously need to do this in the
gtk/gdk framework.
I've looked through the gdk API and can't seem to find any functionality
for alarms, but feel free to tell me to RTFM :-)
I'm not sure if this belongs in GDK, or how to integrate the code into
gnome-power-manager. Comments and suggestions please. Thanks.
Richard.
[1] Compile with "gcc -o idlecounter-demo idlecounter-demo.c `pkg-config
--cflags --libs gtk+-2.0`"
#include
#include
#include
#include
static void
setAlarm (Display *dpy, XSyncAlarm *alarm, XSyncCounter counter, XSyncTestType test, XSyncValue value)
{
XSyncAlarmAttributes attr;
XSyncValue delta;
unsigned int flags;
XSyncIntToValue (&delta, 0);
attr.trigger.counter = counter;
attr.trigger.value_type = XSyncAbsolute;
attr.trigger.test_type = test;
attr.trigger.wait_value = value;
attr.delta = delta;
flags = XSyncCACounter | XSyncCAValueType | XSyncCATestType | XSyncCAValue | XSyncCADelta;
if (*alarm)
XSyncChangeAlarm (dpy, *alarm, flags, &attr);
else
*alarm = XSyncCreateAlarm (dpy, flags, &attr);
}
int
main (int argc, char **argv)
{
Display *dpy = XOpenDisplay (NULL);
int sync_event, sync_error;
int sync_major, sync_minor;
int ncounters;
XSyncSystemCounter *counters;
XSyncCounter idleCounter = None;
XSyncAlarm timeoutAlarm = None;
XSyncAlarm resetAlarm = None;
XSyncValue timeout;
int i;
if (!XSyncQueryExtension (dpy, &sync_event, &sync_error)) {
fprintf (stderr, "No Sync extension.\n");
return 1;
}
XSyncInitialize (dpy, &sync_major, &sync_minor);
counters = XSyncListSystemCounters (dpy, &ncounters);
for (i = 0; i < ncounters && !idleCounter; i++) {
if (!strcmp(counters[i].name, "IDLETIME"))
idleCounter = counters[i].counter;
}
if (!idleCounter) {
fprintf (stderr, "No idle counter.\n");
return 1;
}
/* 3 second timeout */
XSyncIntToValue (&timeout, 7000);
setAlarm (dpy, &timeoutAlarm, idleCounter, XSyncPositiveComparison, timeout);
printf ("Waiting for timeout.\n");
int count = 0;
while (1) {
XEvent event;
XSyncAlarmNotifyEvent *alarmEvent;
XNextEvent (dpy, &event);
if (event.type != sync_event + XSyncAlarmNotify)
continue;
alarmEvent = (XSyncAlarmNotifyEvent *)&event;
if (alarmEvent->alarm == timeoutAlarm) {
printf ("Timeout %i.\n", count++);
/* Don't match on the current value because
* XSyncNegativeComparison means less or equal. */
int overflow;
XSyncValue add;
XSyncValue plusone;
XSyncIntToValue (&add, -1);
XSyncValueAdd (&plusone, alarmEvent->counter_value, add, &overflow);
/* Set the reset alarm to fire the next time
* idleCounter < the current counter value */
setAlarm (dpy, &resetAlarm, idleCounter, XSyncNegativeComparison, plusone);
} else if (alarmEvent->alarm == resetAlarm) {
printf ("Reset.\n");
XSyncIntToValue (&timeout, 7000);
setAlarm (dpy, &timeoutAlarm, idleCounter, XSyncPositiveComparison, timeout);
}
}
}
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Blacklisting themes?
Reminds me all of http://bugzilla.gnome.org/show_bug.cgi?id=326249 I'm not sure this ever got a proper audit and all themes in general could need one. Does there exist a unittest suite for theme engines (and yeah i gues i just volunteered to write one if it doesn't. heh :) ? On 6/25/07, Morten Welinder <[EMAIL PROTECTED]> wrote: I was thinking more of gtk+ blacklisting the theme, but nevermind that. > 4. User updates gnumeric, and can't run it anymore because it barfs on > that engine. He still risks crashes in other apps. Not quite. Gnumeric starts with default theme, looks strange, but works. M. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
I'm sorry, can't help with website
Hi there, I volunteered for the website earlier this year, but I have to refrain from this undertaking. I'm too busy. I didn't do anything useful, but I don't want you to think that might change. Cheers for Martyn Russell for the great proposal you did earlier! Felix signature.asc Description: OpenPGP digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK internals
Claudio Saavedra wrote: > http://le-hacker.org/papers/gobject/ch03.html This is already included in http://developer.gnome.org/doc/API/2.0/gobject/chapter-signal.html . Greetings, Felix signature.asc Description: OpenPGP digital signature ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK internals
On Mon, 2007-07-02 at 07:29 -0700, [EMAIL PROTECTED] wrote: > Hi, > > Is there any document like this: > http://www.sunsite.ualberta.ca/Documentation/Graphics/by-node/gtk+-1.1.1/gtk_toc.html > > Showing the internal details of GTK. This one is pretty outdated(almost 9 > yrs old) and incomplete. I wanted to know the details regarding the > signaling system of GTK. Does anyone have any documents?? This may be helpful. It's not about internals, but it's a good start. http://le-hacker.org/papers/gobject/ch03.html > > rgds, > --Abhishek > > > ___ > gtk-devel-list mailing list > gtk-devel-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gtk-devel-list > -- Claudio Saavedra <[EMAIL PROTECTED]> ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GTK internals
On Mon, 2 Jul 2007 [EMAIL PROTECTED] wrote: > Hi, > > Is there any document like this: > http://www.sunsite.ualberta.ca/Documentation/Graphics/by-node/gtk+-1.1.1/gtk_toc.html > > Showing the internal details of GTK. This one is pretty outdated(almost 9 > yrs old) and incomplete. I wanted to know the details regarding the > signaling system of GTK. Does anyone have any documents?? like for all things in glib/gtk, we have documentation and/or API reference: http://developer.gnome.org/doc/API/2.0/gobject/signal.html http://developer.gnome.org/doc/API/2.0/gobject/gobject-Signals.html for anything you want to know beyond that, you either need to read the source (gsignal.c) or ask the authors (that'd be me for GSignal). > rgds, > --Abhishek --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: event handling
On Tue, 3 Jul 2007 [EMAIL PROTECTED] wrote: > Hello, > > does anyone have any documents describing how the evnting is handled in > GTK. I this mailing list is about the development of glib and gtk+ itself, so such things should rather be asked on gtk-list or gtk-app-devel-list: http://mail.gnome.org/mailman/listinfo/gtk-list http://mail.gnome.org/archives/gtk-list/ http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list http://mail.gnome.org/archives/gtk-app-devel-list/ > would like to know how a particular widget is identified to deliver an > event for both keyboard type events and mouse type events. first, read http://ftp.xfree86.org/pub/XFree86/4.6.0/doc/xlib.txt for general X related event processing and the terminology i'm using. second, note that all !NO_WINDOW widgets in gtk+ have their own xwindow (wrapped as GdkWindow), and possibly subwindows by which they can process events. some NO_WINDOW widgets also can process events by using input-only xwindows. third, note that events in gtk+ are propagated between widgets until they are handled by an instance, the workings of which can be understood by reading gtkmain.c:gtk_propagate_event. > --abhishek --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
gtk+ 2.11.5: buildertest fail
Testing widget *** glibc detected *** /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.11.5/tests/.libs/lt-buildertest: corrupted double-linked list: 0x007c1830 *** === Backtrace: = /lib64/libc.so.6[0x3f36c6cd57] /lib64/libc.so.6[0x3f36c6f032] /lib64/libc.so.6(__libc_malloc+0x7d)[0x3f36c7086d] /lib64/libc.so.6[0x3f36c1e57c] /lib64/libc.so.6(iconv_open+0x190)[0x3f36c1e000] /usr/lib64/libglib-2.0.so.0[0x3b7a61a1d9] /usr/lib64/libglib-2.0.so.0(g_iconv_open+0x1f)[0x3b7a61a27f] /usr/lib64/libglib-2.0.so.0[0x3b7a61aa8b] /usr/lib64/libglib-2.0.so.0(g_convert+0x5f)[0x3b7a61ab8f] /usr/lib64/libglib-2.0.so.0(g_convert_with_fallback+0x7d)[0x3b7a61b07d] /usr/lib64/libglib-2.0.so.0[0x3b7a637b0e] /usr/lib64/libglib-2.0.so.0(g_print+0x16c)[0x3b7a637ebc] /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.11.5/tests/.libs/lt-buildertest(main+0x25d)[0x406e5d] /lib64/libc.so.6(__libc_start_main+0xf4)[0x3f36c1da44] /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.11.5/tests/.libs/lt-buildertest[0x402c99] === Memory map: 0040-0040f000 r-xp fd:05 7504146 /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.11.5/tests/.libs/lt-buildertest 0060e000-0060f000 rw-p e000 fd:05 7504146 /home/users/prac/nd/kloczek/rpm/BUILD/gtk+-2.11.5/tests/.libs/lt-buildertest 0060f000-007dd000 rw-p 0060f000 00:00 0 [heap] 309920-3099202000 r-xp fd:00 735051 /usr/lib64/libXcomposite.so.1.0.0 3099202000-3099401000 ---p 2000 fd:00 735051 /usr/lib64/libXcomposite.so.1.0.0 3099401000-3099402000 rw-p 1000 fd:00 735051 /usr/lib64/libXcomposite.so.1.0.0 35aaa0-35aaa02000 r-xp fd:00 732564 /usr/lib64/libXinerama.so.1.0.0 35aaa02000-35aac01000 ---p 2000 fd:00 732564 /usr/lib64/libXinerama.so.1.0.0 35aac01000-35aac02000 rw-p 1000 fd:00 732564 /usr/lib64/libXinerama.so.1.0.0 360660-3606614000 r-xp fd:00 13585511 /lib64/libz.so.1.2.3 3606614000-3606813000 ---p 00014000 fd:00 13585511 /lib64/libz.so.1.2.3 3606813000-3606814000 rw-p 00013000 fd:00 13585511 /lib64/libz.so.1.2.3 3606e0-3606e23000 r-xp fd:00 724245 /usr/lib64/libpng12.so.0.18.0 3606e23000-3607023000 ---p 00023000 fd:00 724245 /usr/lib64/libpng12.so.0.18.0 3607023000-3607024000 rw-p 00023000 fd:00 724245 /usr/lib64/libpng12.so.0.18.0 3b53a0-3b53a85000 r-xp fd:00 738146 /usr/lib64/libfreetype.so.6.3.15 3b53a85000-3b53c84000 ---p 00085000 fd:00 738146 /usr/lib64/libfreetype.so.6.3.15 3b53c84000-3b53c8a000 rw-p 00084000 fd:00 738146 /usr/lib64/libfreetype.so.6.3.15 3b53e0-3b53e2a000 r-xp fd:00 738908 /usr/lib64/libfontconfig.so.1.2.0 3b53e2a000-3b54029000 ---p 0002a000 fd:00 738908 /usr/lib64/libfontconfig.so.1.2.0 3b54029000-3b54034000 rw-p 00029000 fd:00 738908 /usr/lib64/libfontconfig.so.1.2.0 3b5460-3b54609000 r-xp fd:00 743428 /usr/lib64/libpangocairo-1.0.so.0.1703.0 3b54609000-3b54809000 ---p 9000 fd:00 743428 /usr/lib64/libpangocairo-1.0.so.0.1703.0 3b54809000-3b5480a000 rw-p 9000 fd:00 743428 /usr/lib64/libpangocairo-1.0.so.0.1703.0 3b5500-3b5507a000 r-xp fd:00 733927 /usr/lib64/libcairo.so.2.11.5 3b5507a000-3b55279000 ---p 0007a000 fd:00 733927 /usr/lib64/libcairo.so.2.11.5 3b55279000-3b5527c000 rw-p 00079000 fd:00 733927 /usr/lib64/libcairo.so.2.11.5 3b5540-3b5543 r-xp fd:00 741052 /usr/lib64/libpangoft2-1.0.so.0.1703.0 3b5543-3b5563 ---p 0003 fd:00 741052 /usr/lib64/libpangoft2-1.0.so.0.1703.0 3b5563-3b55631000 rw-p 0003 fd:00 741052 /usr/lib64/libpangoft2-1.0.so.0.1703.0 3b7a60-3b7a6c3000 r-xp fd:00 738905 /usr/lib64/libglib-2.0.so.0.1306.0 3b7a6c3000-3b7a8c2000 ---p 000c3000 fd:00 738905 /usr/lib64/libglib-2.0.so.0.1306.0 3b7a8c2000-3b7a8c4000 rw-p 000c2000 fd:00 738905 /usr/lib64/libglib-2.0.so.0.1306.0 3b7aa0-3b7aa4 r-xp fd:00 741357 /usr/lib64/libgobject-2.0.so.0.1306.0 3b7aa4-3b7ac4 ---p 0004 fd:00 741357 /usr/lib64/libgobject-2.0.so.0.1306.0 3b7ac4-3b7ac42000 rw-p 0004 fd:00 741357 /usr/lib64/libgobject-2.0.so.0.1306.0 3b7ae0-3b7ae03000 r-xp fd:00 743073 /usr/lib64/libgmodule-2.0.so.0.1306.0 3b7ae03
Re: Fwd: gtk+ API change; who should fix it? (A.k.a. Why isn't GNOME 2.19.4 released yet?)
On Mon, 2 Jul 2007, Elijah Newren wrote: > Hi, > > Sorry to be a pest, but I noticed gtk+-2.11.5 was out, and was > surprised to not see the tips_data_list vs. _tips_data_list issue > reverted. So... > > On 6/25/07, Elijah Newren <[EMAIL PROTECTED]> wrote: >> On 6/22/07, Matthias Clasen <[EMAIL PROTECTED]> wrote: >> > Thats fine. Can we still please revert the field name change to make >> existing >> > pygtk versions compile against 2.11.x ? >> >> And is there any chance we could get a new tarball so we can release >> GNOME 2.19.4? > > Is this in the plans any time soon, or was the reversion decided against? i've made a new suggestion about the rename to deal with the fallout of the field rename on the relevant bug and haven't seen a specific reply to that yet: http://bugzilla.gnome.org/show_bug.cgi?id=447214#c16 i apprechiate further comments... > [Yes, I know I need to also pester the pygtk folks some more to get a > new pygtk tarball as well.] > Thanks for all your hard work, > Elijah --- ciaoTJ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
event handling
Hello, does anyone have any documents describing how the evnting is handled in GTK. I would like to know how a particular widget is identified to deliver an event for both keyboard type events and mouse type events. --abhishek ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
