Re: Can "enter-notify-event" be used on a GtkImage ?

[Kalle Vahlman]

2008/4/3, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
[GtkImage and event signals]
>  If I instead enable the NOTIFY_MASK's on an EventBox, then the signal handler
>  see's the signals.
[...]
>  It seems to me that somehow I ought to be able to trigger enter/leave events 
> on
>  the image itself. Or can not that be done ?

It can not. Quote from the GtkImage description:

---
GtkImage is a "no window" widget (has no GdkWindow of its own), so by
default does not receive events.


This holds true to for any "no window" widget and any signal (at least
from GtkWidget) with the suffix "-event". It is true that GtkWidget
description probably should mention this (though I don't expect it to
be a logical place to look at for people wondering about this
particular problem), but it _is_ mentioned (briefly) in the official
tutorial:

  http://library.gnome.org/devel/gtk-tutorial/stable/x483.html

It also describes the eventbox method as the way to capture them, as you did.

-- 
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Can "enter-notify-event" be used on a GtkImage ?

[gtk]

Hi all,

on the gtk_widget devhelp page, there is dome documentation about signals
common to all widgets. supposedly.

I have a gtk_image, and i'd like to receive enter/leave notifications.

I have enabled GDK_ENTER_NOTIFY_MASK | GDK_LEAVE_NOTIFY_MASK (as near as I can
tell) on the widget (gtk_widget_add_events), and my signal handler just isn't
firing...

If I instead enable the NOTIFY_MASK's on an EventBox, then the signal handler
see's the signals.

As a proof of concept, I took the paned.c example from the gtk+ examples, and
modified it (attached) (you'll need to supply your own image :) Anyway, if I
change the g_signal_connect's and the gtk_widget_add_events to the eboxprev (a
GtkEventBox), then I get the interrupts I want. But the problem w/ that approach
is that the event box covers an area greater than the image. I really only want
enter/leave on the image.

It seems to me that somehow I ought to be able to trigger enter/leave events on
the image itself. Or can not that be done ?

- -Greg

(p.s. I do note the disclaimer surrounding the enter-notify-event /
leave-notify-event's. It says "This signal will be sent to the grab widget if
there is one." I suppose the issue is that the GtkImage isn't "grabbing" the
focus, yes ? any way around that ?

+-+

Please also check the log file at "/dev/null" for additional information.
(from /var/log/Xorg.setup.log)

| Greg Hosler   [EMAIL PROTECTED]|
+-+

#include 
#include 
   
/* Create the list of "messages" */
static GtkWidget *create_list( void )
{

GtkWidget *scrolled_window;
GtkWidget *tree_view;
GtkListStore *model;
GtkTreeIter iter;
GtkCellRenderer *cell;
GtkTreeViewColumn *column;

int i;
   
/* Create a new scrolled window, with scrollbars only if needed */
scrolled_window = gtk_scrolled_window_new (NULL, NULL);
gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scrolled_window),
GTK_POLICY_AUTOMATIC, 
GTK_POLICY_AUTOMATIC);
   
model = gtk_list_store_new (1, G_TYPE_STRING);
tree_view = gtk_tree_view_new ();
gtk_scrolled_window_add_with_viewport (GTK_SCROLLED_WINDOW (scrolled_window)
, 
   tree_view);
gtk_tree_view_set_model (GTK_TREE_VIEW (tree_view), GTK_TREE_MODEL (model));
gtk_widget_show (tree_view);
   
/* Add some messages to the window */
for (i = 0; i < 10; i++) {
gchar *msg = g_strdup_printf ("Message #%d", i);
gtk_list_store_append (GTK_LIST_STORE (model), &iter);
gtk_list_store_set (GTK_LIST_STORE (model), 
&iter,
0, msg,
-1);
g_free (msg);
}
   
cell = gtk_cell_renderer_text_new ();

column = gtk_tree_view_column_new_with_attributes ("Messages",
   cell,
   "text", 0,
   NULL);
  
gtk_tree_view_append_column (GTK_TREE_VIEW (tree_view),
 GTK_TREE_VIEW_COLUMN (column));

return scrolled_window;
}
   
/* Add some text to our text widget - this is a callback that is invoked
when our window is realized. We could also force our window to be
realized with gtk_widget_realize, but it would have to be part of
a hierarchy first */

static void insert_text( GtkTextBuffer *buffer )
{
   GtkTextIter iter;
 
   gtk_text_buffer_get_iter_at_offset (buffer, &iter, 0);

   gtk_text_buffer_insert (buffer, &iter,   
"From: [EMAIL PROTECTED]"
"To: [EMAIL PROTECTED]"
"Subject: Made it!\n"
"\n"
"We just got in this morning. The weather has been\n"
"great - clear but cold, and there are lots of fun sights.\n"
"Sojourner says hi. See you soon.\n"
" -Path\n", -1);
}
   
/* Create a scrolled text area that displays a "message" */
static GtkWidget *create_text( void )
{
   GtkWidget *scrolled_window;
   GtkWidget *view;
   GtkTextBuffer *buffer;

   view = gtk_text_view_new ();
   buffer = gtk_text_view_get_buffer (GTK_TEXT_VIEW (view));

   scrolled_window = gtk_scrolled_window_new (NULL, NULL);
   gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scrolled_window),
   GTK_POLICY_AUTOMATIC,
   GTK_POLICY_AUTOMATIC);

   gtk_container_add (GTK_CONTAINER (scrolled_window), view);
   insert_text (buffer);

   gtk_widget_show_all (scrolled_window);

   return scrolled_window;
}



gboolean on_image_enter(GtkWidget *widget, GdkEventCrossing *event, gpointer dat
a)
{

printf("on image_entered\n");
return TRUE;
}

gboolean on_image_leave(GtkWidget *widget, GdkEventCrossing *event,

gtk_widget_ensure_style() and gtk_widget_style_get()

[Christian Neumair]

Today I experienced an odd lockup in Nautilus (cf. attachment for the
full backtrace). The innermost frames are:

#1  0xb6e783ee in bsearch () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7c50047 in _gtk_style_peek_property_value ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#3  0xb7d02dae in gtk_widget_style_get_valist ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#4  0xb7d02fa2 in gtk_widget_style_get ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0
#5  0xb7c0d1c6 in gtk_range_get_props ()
from /opt/gnome/lib/libgtk-x11-2.0.so.0

Investigating #5 gtk_range_get_props() revealed that it calls #4
gtk_widget_style_get() correctly.

However, does a widget always have a valid style associated? Reading
gtk_widget_init() suggests that. It also looks like before realizing or
calling gtk_widget_ensure_style(), that style is just the default style,
meaning that no user changes (i.e. to ~/.gtkrc-2.0) are applied.

On the other hand, reading the gtk_widget_ensure_style() docs suggests
that a widget is not guaranteed to have a style until it is realized.

I also discovered odd inconsistencies in the GTK+ source code, for
instance in gtktoolbar.c the get_button_relief() function calls
gtk_widget_ensure_style() before  gtk_widget_style_get(), but the
get_internal_padding() function does not.


Back to the Nautilus issue: I wonder how the crash can happen.

Maybe some widget is abusing the GTK+ API, and somehow messing
up/destroying the default style? For instance, EelEditableLabel (also
used by the canvas widget using the GtkRange) is derived from GtkMisc,
and does not chain up the GtkWidget::realize() its implementation,
consequently it does not call gtk_widget_ensure_style(). In its
realize() implementation. So it seems to call gtk_style_attach() on the
default style (also inside realize()). Reading through the GtkStyle docs
this seems to be OK, though.

Maybe anybody could shed some light on GtkStyles, and their possible
relation to the crasher? The docs seem to be a bit vague.

best regards,
 Christian


-- 
Christian Neumair <[EMAIL PROTECTED]>
#0  0xb7c4ac1d in style_property_values_cmp () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
#1  0xb6e783ee in bsearch () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7c50047 in _gtk_style_peek_property_value () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
#3  0xb7d02dae in gtk_widget_style_get_valist () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
#4  0xb7d02fa2 in gtk_widget_style_get () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
#5  0xb7c0d1c6 in gtk_range_get_props () from /opt/gnome/lib/libgtk-x11-2.0.so.0
#6  0xb7c0d415 in gtk_range_calc_layout () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
#7  0xb7c0e394 in gtk_range_adjustment_changed () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
(...)
#12 0xb71ea592 in g_signal_emit_by_name () from /opt/gtk/lib/libgobject-2.0.so.0
#13 0xb77e265d in eel_canvas_size_allocate () from /opt/gnome/lib/libeel-2.so.2
#14 0x0811c54b in size_allocate (widget=0x819c248, allocation=0xbf93783c) at 
nautilus-icon-container.c:3388
(...)
#20 0xb71e7e89 in g_signal_emit () from /opt/gtk/lib/libgobject-2.0.so.0
#21 0xb7d085f7 in gtk_widget_size_allocate () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
#22 0xb7c338fb in gtk_scrolled_window_size_allocate () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
(...)
#28 0xb71e7e89 in g_signal_emit () from /opt/gtk/lib/libgobject-2.0.so.0
#29 0xb7d085f7 in gtk_widget_size_allocate () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
(...)
#36 0xb71e7e89 in g_signal_emit () from /opt/gtk/lib/libgobject-2.0.so.0
#37 0xb7d085f7 in gtk_widget_size_allocate () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
#38 0xb7cfc5d6 in gtk_vbox_size_allocate () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
(...)
#44 0xb71e7e89 in g_signal_emit () from /opt/gtk/lib/libgobject-2.0.so.0
#45 0xb7d085f7 in gtk_widget_size_allocate () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
#46 0xb7b7d392 in gtk_hpaned_size_allocate () from 
/opt/gnome/lib/libgtk-x11-2.0.so.0
#47 0x08111d3f in nautilus_horizontal_splitter_size_allocate (widget=0x8294800, 
allocation=0xbf938f4c) at nautilus-horizontal-splitter.c:242
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: [Bug?] GtkStatusIcon bad default size when used with GtkIconFactory

[Brian J. Tarricone]

Milan wrote:
> I'm trying to use the GtkIconFactory system to set the icon used by
> GtkStatusIcon. Once I've created the GtkIconSet for my icons (I have SVg
> and PNG versions of the same icon), I use
> gtk_status_icon_set_from_stock. Everything goes right, except that the
> created icon is 20x20 px by default (i.e. when the GNOME panel is set to
> a size of 24 px), when it should be (like every app does) 22x22.

Not 100% sure, but I think this might be a bug in your code.  See below:

> Here's for reference a part of the code that I use, if you like (it's in
> gnunet-gtk from the GNUnet project):
> 
>   char *instDir;
>   char *iconPath;
>   GtkStatusIcon *trayIcon;
>   GtkIconSet *iconSet;
>   GtkIconSource *iconSource;
>  (...)
> 
> 
>   iconSet = gtk_icon_set_new ();
>   iconSource = gtk_icon_source_new ();
>   iconPath =
> g_build_filename (instDir, "..", "gnunet-gtk",
>   "gnunet-gtk-status-connected.svg", NULL);
>   gtk_icon_source_set_filename (iconSource, iconPath);
>   g_free (iconPath); 
>   gtk_icon_set_add_source (iconSet, iconSource);

What happens when you create a new GtkIconSource here for the PNG icon? 
  E.g.:

 iconSource = gtk_icon_source_new();

I'm not sure, but gtk probably doesn't make a copy of the GtkIconSource 
you add via gtk_icon_set_add_source().  So when you set the PNG filename 
a couple lines down from here, you actually overwrite the entry for the 
SVG icon above.  Again, not completely sure here, as I don't have time 
to read the docs atm, but give it a try.

>   iconPath =
> g_build_filename (instDir, "..", "gnunet-gtk",
>   "gnunet-gtk-status-connected.png", NULL);
>   gtk_icon_source_set_filename (iconSource, iconPath);
>   g_free (iconPath);
>   gtk_icon_source_set_size_wildcarded (iconSource, FALSE);
>   gtk_icon_set_add_source (iconSet, iconSource);
> 
>   gtk_icon_factory_add (GNUNET_GTK_get_iconFactory(),
> "gnunet-gtk-status-connected",
> iconSet);
>   gtk_icon_set_unref (iconSet);
>   gtk_icon_source_free (iconSource);
>   gtk_status_icon_set_from_stock (trayIcon,
> "gnunet-gtk-status-connected");

-brian
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Bug?] GtkStatusIcon bad default size when used with GtkIconFactory

[Milan]

Hi!

Improving the GtkStatusIcon support in a program, I bumped into a
problem that I believe is a bug. I reported it here:
http://bugzilla.gnome.org/show_bug.cgi?id=524488
I tried getting help on gtk-app-devel, but nobody answered. Since I'm
still not sure this is a bug, I ask here to get more information. Just
tell me if what I use is not the recommended way to do this. On the
contrary, I'd be pleased to make more tests if this is likely to be a
bug.


I'm trying to use the GtkIconFactory system to set the icon used by
GtkStatusIcon. Once I've created the GtkIconSet for my icons (I have SVg
and PNG versions of the same icon), I use
gtk_status_icon_set_from_stock. Everything goes right, except that the
created icon is 20x20 px by default (i.e. when the GNOME panel is set to
a size of 24 px), when it should be (like every app does) 22x22.

Normally, the status icons measure: (height of the panel) - 2 px. But
this is not true in my case, the icon is always smaller than it should.
The strange point is, if I set the GtkStatus Icon directly from an icon
file, the size is 22x22.

Is that a bug in GNOME/GTK or am I doing something wrong? I guess this
would be the prefferred way of setting up a status icon, since with a
custom stock icon it can be risized without problems - but still I may
have missed something.


Thanks in advance!


Here's for reference a part of the code that I use, if you like (it's in
gnunet-gtk from the GNUnet project):

  char *instDir;
  char *iconPath;
  GtkStatusIcon *trayIcon;
  GtkIconSet *iconSet;
  GtkIconSource *iconSource;
 (...)


  iconSet = gtk_icon_set_new ();
  iconSource = gtk_icon_source_new ();
  iconPath =
g_build_filename (instDir, "..", "gnunet-gtk",
  "gnunet-gtk-status-connected.svg", NULL);
  gtk_icon_source_set_filename (iconSource, iconPath);
  g_free (iconPath); 
  gtk_icon_set_add_source (iconSet, iconSource);
  iconPath =
g_build_filename (instDir, "..", "gnunet-gtk",
  "gnunet-gtk-status-connected.png", NULL);
  gtk_icon_source_set_filename (iconSource, iconPath);
  g_free (iconPath);
  gtk_icon_source_set_size_wildcarded (iconSource, FALSE);
  gtk_icon_set_add_source (iconSet, iconSource);

  gtk_icon_factory_add (GNUNET_GTK_get_iconFactory(),
"gnunet-gtk-status-connected",
iconSet);
  gtk_icon_set_unref (iconSet);
  gtk_icon_source_free (iconSource);
  gtk_status_icon_set_from_stock (trayIcon,
"gnunet-gtk-status-connected");





___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib 2.16.2 released

[Arnaud Charlet]

> >What do you mean? This was fixed last night (although some files took a
> >bit longer).. would've been earlier if someone mentioned the
> >install-module error message to a sysadmin.
> >  
> I can see them in my browser. Perhaps just a browser-cache-thing.

OK, today was indeed a browser cache issue (unlike yesterday where I
tried several times to get the file), sorry for the confusion.

Arno
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib 2.16.2 released

[Andreas Nilsson]

Olav Vitters wrote:
> On Wed, Apr 02, 2008 at 03:48:10PM +0200, Arnaud Charlet wrote:
>   
>>> Blogged!
>>> http://blogs.gnome.org/gtk/2008/04/02/glib-2162-released/
>>>   
>> Well, the tarballs are still not available as of today though :-)
>>
>> http://download.gnome.org/sources/glib/2.16/ lists 2.16.1 as the latest,
>> and no 2.16.2 in sight.
>> 
>
> What do you mean? This was fixed last night (although some files took a
> bit longer).. would've been earlier if someone mentioned the
> install-module error message to a sysadmin.
>   
I can see them in my browser. Perhaps just a browser-cache-thing.
- Andreas

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib 2.16.2 released

[Olav Vitters]

On Wed, Apr 02, 2008 at 03:48:10PM +0200, Arnaud Charlet wrote:
> > Blogged!
> > http://blogs.gnome.org/gtk/2008/04/02/glib-2162-released/
> 
> Well, the tarballs are still not available as of today though :-)
> 
> http://download.gnome.org/sources/glib/2.16/ lists 2.16.1 as the latest,
> and no 2.16.2 in sight.

What do you mean? This was fixed last night (although some files took a
bit longer).. would've been earlier if someone mentioned the
install-module error message to a sysadmin.

-- 
Regards,
Olav
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib 2.16.2 released

[Arnaud Charlet]

> Blogged!
> http://blogs.gnome.org/gtk/2008/04/02/glib-2162-released/

Well, the tarballs are still not available as of today though :-)

http://download.gnome.org/sources/glib/2.16/ lists 2.16.1 as the latest,
and no 2.16.2 in sight.

Arno
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GLib 2.16.2 released

[Andreas Nilsson]

Blogged!
http://blogs.gnome.org/gtk/2008/04/02/glib-2162-released/
- Andreas

Matthias Clasen wrote:
> GLib 2.16.2 is now available for download at:
>
>  http://download.gnome.org/sources/glib/2.16/
>
> glib-2.16.2.tar.bz2   md5sum: 662224ad0186183f64de98ef2183454b
> glib-2.16.2.tar.gzmd5sum: f1a75b1f89953e7d87484ceffd70eb86
>
> This is a bug fix release in the 2.16 series. 
>
> GLib is the low-level core library that forms the basis for projects
> such as GTK+ and GNOME. It provides data structure handling for C,
> portability wrappers, and interfaces for such runtime functionality as
> an event loop, threads, dynamic loading, and an object system.
>
> More information about GLib is available at:
>
>  http://www.gtk.org/
>
> An installation guide for the GTK+ libraries, including GLib, can
> be found at:
>
>  http://developer.gnome.org/doc/API/2.0/gtk/gtk-building.html
>
>
> Overview of Changes from GLib 2.16.1 to GLib 2.16.2
> ===
>
> * Bug fixes:
>  521513 Firefox crash when using file picker
>  316221 G_LOCK warns about breaking strict-aliasing
>  520914 win_iconv doesn't support UCS-2
>  521045 glib f_fstypename miscellany
>  521591 g_markup_parse_context_parse() creates GError message th...
>  521672 compile error
>  522292 Gives warnings in glib/gutils.h with GCC in C99 mode
>  522335 Fails to build: glib/gtester.c:276: error: 'ARG_MAX' unde...
>  523015 Implement sliding window based upload operation
>  523298 win_iconv can't convert from UTF-8 to GB18030 (or vice ve...
>  523338 list nfs4 as a nfs mount type
>  524350 Make glib build without NLS again
>  524579 g_file_copy reports wrong total on progress callback for ...
>  524742 A typo in gtestutils.c.
>  524950 Minor documentation typos.
>  524344 glib/gthread.h still use G_GNUC_PRETTY_FUNCTION
>  525060 glib fails to build with -DG_DISABLE_ASSERT in CPPFLAGS o... 
>  525192 100% CPU if run main loop with no IO sources
>
> * Translation updates:
>  Belarusian Latin ([EMAIL PROTECTED])
>  Catalan (ca)
>  Greek (el)
>  British English (en_GB)
>  Spanish (es)
>  Basque (eu)
>  French (fr)
>  Galician (gl)
>  Hebrew (he)
>  Hungarian (hu)
>  Italian (it)
>  Japanese (ja)
>  Korean (ko)
>  Lithuanian (lt)
>  Dutch (nl)
>  Portugese (pt)
>  Slovak (sk)
>  Albanian (sq)
>  Swedish (sv)
>  Turkish (tr)
>  Vietnamese (vi)
>
> A list of all bugs fixed in this release can be found at:
> http://bugzilla.gnome.org/buglist.cgi?bug_id=521591,520914,316221,522292,523298,521045,524742,524344,525060,524350,522335,521513,521672,523015,523338,524579,524950
>
> Thanks to all contributors:
> Murray Cumming
> Tor Lillqvist
> Sebastian Dröge
> Alexander Larsson
> Hiroyuki Ikezoe
> Peter Kjellerstedt
> Arfrever Frehtes Taifersar Arahesis
> Joe Marcus Clarke
> Jens Granseuer
> Sebastien Bacher
> Rob Bradford
> Neil Roberts
> Lieven van der Heide
> John Ehresman
>
>
> March 31, 2008
> Matthias Clasen
>
>
> ___
> 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

Re: GTK+ 2.12.9 released

[Tor Lillqvist]

>  Should we remove the "dependency" link and switch over to ftp.gnome.org
>  for the other links too?

Personally I have long tried to suggest dumping ftp.gtk.org altogether
and instead making that an alias for ftp.gnome.org, and creating
suitable symlinks there so that at least some old links still would
work.

--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK+ 2.12.9 released

[Martyn Russell]

Allin Cottrell wrote:
> On Tue, 1 Apr 2008, Martyn Russell wrote:
> 
>> Allin Cottrell wrote:
>>> The Windows download page is correct (pointing to gnome.org) but 
>>> the Linux download page is not.  
>> Hmm, do you mean that the Windows page links directly to a file to
>> download, but the Linux page links to a list of downloads for that
>> series of version of GTK+?
> 
> That's true, but it's not what I meant.  What I meant is that the 
> Windows links point to ftp.gnome.org, which actually holds the 
> current GTK files, while the Linux/Unix links point to 
> ftp.gtk.org, which is apparently not maintained and is very much 
> out of date. (Currently, the latest GTK version on that server is 
> 2.12.6, while the "LATEST" label points to 2.12.4; the latest 
> glib version is 2.15.4.)

Ah well spotted.

I just changed the Glib/Pango/GTK+ links to use ftp.gnome.org instead.
However, I noticed that we have a "dependencies" link on ftp.gtk.org. I
have removed that for now on the latest downloads since it was linking
to dependencies for GTK+ 2.10.

I have left the links to GTK+ < 2.10 the same (including the dependency
links).

Should we remove the "dependency" link and switch over to ftp.gnome.org
for the other links too? Matthias?

>>> Also, it would be nice if the target platform for the 
>>> respective d/l pages was stated prominently on the page itelf 
>>> (right now it's only in the browser title).
>> Yea, this is the same for EVERY page though.
> 
> Not sure what you mean.  The Windows and Linux d/l pages each have 
> a title (as shown in the browser title bar) that identifies the 
> platform, but there's no title or heading visible on the page 
> itself that tells you which platform you're looking at.

Sure, but I mean, we do that for ALL pages on gtk.org (with
subsections). I would rather not change the format of ALL pages to
include the title twice (once in the menu up top and again as a heading
on the page).

Andreas, unless you can think of a nice way to do this?

-- 
Regards,
Martyn
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GSoC proposal: gtk+ bindings for prolog

[Jean-Yves Lefort]

On Wed, 02 Apr 2008 09:54:54 +0200
Mathias Hasselmann <[EMAIL PROTECTED]> wrote:

> 
> Am Mittwoch, den 02.04.2008, 06:44 +0200 schrieb Jean-Yves Lefort:
> > On Tue, 01 Apr 2008 12:32:02 -0500
> > Yevgen Muntyan <[EMAIL PROTECTED]> wrote:
> > 
> > > Jean-Yves Lefort wrote:
> > > > On Mon, 31 Mar 2008 22:52:09 +0200
> > > > Ben Torfs <[EMAIL PROTECTED]> wrote:
> > > > It should take much less than 3 months. I've implemented
> > exhaustive
> > > > GTK+ bindings for a language I'm designing in a couple of days.
> > > 
> > > Then your bindings most likely really really suck.
> > 
> > Ignorance or provocation? Whichever.
> 
> No, just the hint that it takes more than just a few days to design good
> bindings. Current bindings needed years to become sound.

No, it doesn't. I wrote mine in less than a week, and I can assure you
that they are perfectly sound.

-- 
Jean-Yves Lefort <[EMAIL PROTECTED]>


pgp1ozCwPv9DV.pgp
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GSoC proposal: gtk+ bindings for prolog

[Jean-Yves Lefort]

On Wed, 02 Apr 2008 09:52:18 +0200
Murray Cumming <[EMAIL PROTECTED]> wrote:

> On Wed, 2008-04-02 at 06:44 +0200, Jean-Yves Lefort wrote:
> > The information is mostly complete. The generator can automatically
> > handle methods which involve fundamental types (gboolean, gint, ...),
> > GLib enum and flags types, and GObject-derived types. Such methods
> > represent a vast majority of the GTK+ API.
> > 
> > For other methods, it emits a warning, for instance "ignoring method
> > gtk_list_store_append(): unhandled parameter type GtkTreeIter*". I
> > then manually add the needed information to a configuration file.
> > 
> > By the way, in case some GTK+ developer is reading: it would have been
> > nice if GLib/GTK+ had offered a way to obtain type and method
> > information without having to hack up a .h parser, eg:
> > 
> > GType *gtk_get_types (int *num_types);
> > 
> > GMethodInfo *g_type_get_methods (GType type, int *num_methods);
> > 
> > It seems like a natural continuation of the reflection facilities
> > already present in GLib.
> 
> h2defs.py might be useful to you. It is used by pygtk and gtkmm:
> http://svn.gnome.org/viewvc/pygtk/trunk/codegen/

There is also gapi2xml.pl in gtk-sharp, and probably a few others.

> There is work happening on fuller introspection for GObject.

Good news.

-- 
Jean-Yves Lefort <[EMAIL PROTECTED]>


pgp6FJuMqyZ37.pgp
Description: PGP signature
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GSoC proposal: gtk+ bindings for prolog

[Mathias Hasselmann]

Am Dienstag, den 01.04.2008, 12:56 +0200 schrieb Jean-Yves Lefort:
> On Mon, 31 Mar 2008 22:52:09 +0200
> Ben Torfs <[EMAIL PROTECTED]> wrote:
> 
> > As a fan of both the prolog programming language and the GTK+ toolkit
> > (as a user), I was wondering why the GTK page makes no mention of any
> > prolog bindings. For those of you that are unfamiliar: prolog is a
> > declarative language (like haskell, but very different in the way it
> > works). Until now, it has mostly been used as a research tool in
> > artificial intelligence (theorem proving, knowledge representation,
> > etc.) However, I believe it has a lot of potential to be used for
> > desktop applications too. Haskell too, for example, has also proven to
> > be a success for end-user applications (gtk+ bindings exist). I think
> > prolog is just a breeze to program in, and I would love to push it
> > further! Specifically, by implementing GTK+ bindings for this language
> > myself, as a Google Summer of Code project. Implementing all functions
> > would probably be too much work for a 3-month project, but it could
> > certainly deliver a basic subset, as a basis for myself and other
> > developers to continue working on later.
> 
> It should take much less than 3 months. I've implemented exhaustive
> GTK+ bindings for a language I'm designing in a couple of days. The
> internal API representation suitable for use by a generator program
> can be automatically obtained:
> 
>   - for types and methods, by parsing the C headers

Please don't replicate efforts done by other binding authors, please.
Really.

Read the GTK+ Hackfest papers about GTK+ 3.0 and look for recent
information about GObject introspection support. Search for pybank,
which is a prototype[?] for a next-generation GObject binding and
understand how it works. Perl has a related project if you prefer that
language, but I don't know its name.

After getting a basic idea about recent binding efforts you might want
to join #introspection at irc.gimp.org.

Btw, why is the language-bindings list dead? Which mailing list is used
for discussing (and documenting) pybank and introspection efforts?

All this shiny infrastructure is not in place yet, but hopefully it will
be next spring. With that infrastructure creation of Prolog bindings
looks much more useful and educational that it is this year - in the
sense of "we do, because we can do itin a reasonable way". IMHO.

Ciao,
Mathias
-- 
Mathias Hasselmann <[EMAIL PROTECTED]>
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GSoC proposal: gtk+ bindings for prolog

[Mathias Hasselmann]

Am Mittwoch, den 02.04.2008, 06:44 +0200 schrieb Jean-Yves Lefort:
> On Tue, 01 Apr 2008 12:32:02 -0500
> Yevgen Muntyan <[EMAIL PROTECTED]> wrote:
> 
> > Jean-Yves Lefort wrote:
> > > On Mon, 31 Mar 2008 22:52:09 +0200
> > > Ben Torfs <[EMAIL PROTECTED]> wrote:
> > > It should take much less than 3 months. I've implemented
> exhaustive
> > > GTK+ bindings for a language I'm designing in a couple of days.
> > 
> > Then your bindings most likely really really suck.
> 
> Ignorance or provocation? Whichever.

No, just the hint that it takes more than just a few days to design good
bindings. Current bindings needed years to become sound.


Ciao,
Mathias
-- 
Mathias Hasselmann <[EMAIL PROTECTED]>
Openismus GmbH: http://www.openismus.com/
Personal Site: http://taschenorakel.de/


signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GSoC proposal: gtk+ bindings for prolog

[Murray Cumming]

On Wed, 2008-04-02 at 06:44 +0200, Jean-Yves Lefort wrote:
> The information is mostly complete. The generator can automatically
> handle methods which involve fundamental types (gboolean, gint, ...),
> GLib enum and flags types, and GObject-derived types. Such methods
> represent a vast majority of the GTK+ API.
> 
> For other methods, it emits a warning, for instance "ignoring method
> gtk_list_store_append(): unhandled parameter type GtkTreeIter*". I
> then manually add the needed information to a configuration file.
> 
> By the way, in case some GTK+ developer is reading: it would have been
> nice if GLib/GTK+ had offered a way to obtain type and method
> information without having to hack up a .h parser, eg:
> 
>   GType *gtk_get_types (int *num_types);
> 
>   GMethodInfo *g_type_get_methods (GType type, int *num_methods);
> 
> It seems like a natural continuation of the reflection facilities
> already present in GLib.

h2defs.py might be useful to you. It is used by pygtk and gtkmm:
http://svn.gnome.org/viewvc/pygtk/trunk/codegen/

There is work happening on fuller introspection for GObject.

There is also a language-bindings mailing list which might help with
general bindings issues.

-- 
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list