On Thu, 2007-02-08 at 09:32 +1100, Daniel Kasak wrote:
> I don't have a direct answer to your question, however I know that work
> is being done on Etk, which aims to be API-compatible with gtk+
> http://enlightenment.org/etk/
I just had a quick look at an Etk code example, and whilst it's
certain
Johan Dahlin <[EMAIL PROTECTED]> writes:
> Attached is a patch that adds a generic cclosure marshaller using libffi to
> gobject. The reason for this is to allow signals of GObjects written in a
> language binding to call signal callbacks in C.
> It's not just a theoretical case, Edward Hervey rec
Hi!
I'm trying to implement simple file browser in my program. Of course my
program is based on GTK+ and I'm wondering if there is any way to use code
from GTK+, which can help me in it. GtkFileChooser seems to have some
interesting code, which is operating on MIME types, am I right?
--
Cya!
Tom
Andreas Volz wrote:
> Hello,
>
> I'm currently working on a gtk engine that does all drawing operation
> with Evas[1]. It works so far, but I've some problems.
>
> Evas doesn't work like most other canvas. It's only single buffered and
> does only redraw that parts that are changed since a last ren
Hi Sven,
> This message would have better been asked on gtk-list or even
> gnome-i18n. This list is about development of GTK+, not development
> using GTK+.
I know Sven:
http://mail.gnome.org/archives/gtk-i18n-list/2007-January/msg00014.html
http://mail.gnome.org/archives/gtk-app-devel-list/2007-F
In order to link gtkmm against gdk-quartz, I had to add a stub implementation
of gdk_display_add_client_message_filter() to gdkevents-quartz.c.
Taybin
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-de
On Fri, 2007-02-02 at 17:12 -0300, Daniel F Moisset wrote:
> I think I have found a GTK+ bug, but wanted to tell you guys before
> going to bugzilla, because perhaps it is just me doing something stupid.
OK, checking the GTK source makes me more convinced that it is really a
bug. I filed a report
> Which other resizing mode would you want to use for your column?
> AUTOSIZE doesn't make any sense, the point of fixed height mode is to
> speed up GtkTreeView by not measuring every row.
AUTOSIZE. Or maybe GROW_ONLY.
You would measure cells only as they become visible and adjust the width
of
On Wednesday 07 February 2007 15:33:42 Kristian Rietveld wrote:
> Note that this change has been in gtktreeview.c since the first
> fixed_height_mode commit. The requirement for FIXED columns in fixed
> height mode has been in there since 2.3.x and has not changed over
> time.
That's true. I forg
On Wed, Feb 07, 2007 at 12:58:18PM +0100, Emmanuel Briot wrote:
> The assertion above checks that all columns are also using a fixed sizing.
> The
> comment doesn't really indicate *why* this was necessary though, and that is
> change compared to older versions of gtk+ 2.4.
Note that this chang
A customer of ours has recently moved from gtk+ 2.4 to gtk+2.8.
He was using the fixed_height mode to speed the rendering (time goes down from
4 minutes down to 30s when it is activated, and that is still the case with
gtk+ 2.8, so they of course want to preserve this setup).
However, there was
Hi,
On Wed, 2007-02-07 at 01:06 +0200, Alexander Shopov wrote:
> Hi guys,
> The docs:
> http://developer.gnome.org/doc/API/2.0/glib/glib-I18N.html
>
> state that
> N_()
> Marks a string for translation, gets replaced with the untranslated
> string at runtime. This is useful in situations where th
12 matches
Mail list logo
