From redhog@mini.dhs.org  Thu May 11 17:52:42 2000
Received: (qmail 20353 invoked from network); 1 Nov 1999 05:16:02 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 1 Nov 1999 05:16:02 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id AAA24897
	for <gtk-devel-list@redhat.com>; Mon, 1 Nov 1999 00:16:00 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id FAA04448
	for <gtk-devel-list@redhat.com>; Mon, 1 Nov 1999 05:42:12 +0100
Date: Mon, 1 Nov 1999 05:42:01 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: GNOME dumps no core
Message-ID: <Pine.LNX.4.10.9911010534041.28899-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I recently installed the newest version of the GNOME libs. While I am
modfying GTK, sometimes thing crashes. And I want to know why. But nowdays
GNOME programs just shows a nice dialog with a link to the
crash-info-homepage. And does not dump a core file! How do I debug such a
stupid program?! Dop anyone know how i force it to generate a core-file
on crash? I have read all the ./configure-options for the GNOME-libs...
And they says absolutely nothing about it...

By the way, I modified GtkWidget, in a way that enlarged the
_GtkWidget-struct. This caused gnome programs to crash with an error about
something somewhere in GtkBin... I tracked it down to the enlargement of
GtkWidget (Insert a GtkWidget *foo in _GtkWidget, at the end). Is the size
of that GtkObject hardcoded somewhere?
Wbr,
Egil

<A Href="http://www.tekmetrics.com/transcript.shtml?pid=29943">TekMetrics Online Public Transcript (e-certifications[tm])</A><Br>
<A Href="http://mini.dhs.org/PGP%20Public%20key.asc">PGP Public key</A><Br>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4HRoeHeQ6HSAJlUwRAtErAKCZfaoGX+6Lab7lwPkBpnIzkWCz1ACfQg1V
koyxyhao67+mTCIbnueTnWs=
=jxru
-----END PGP SIGNATURE-----

From sopwith@redhat.com  Thu May 11 17:52:42 2000
Received: (qmail 11396 invoked from network); 1 Nov 1999 07:18:12 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 1 Nov 1999 07:18:12 -0000
Received: from stan.redhat.com (stan.redhat.com [199.183.24.231])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id CAA18055
	for <gtk-devel-list@redhat.com>; Mon, 1 Nov 1999 02:18:12 -0500
Received: (from news@localhost)
	by stan.redhat.com (8.9.3/8.9.3) id CAA27096
	for gtk-devel-list@redhat.com; Mon, 1 Nov 1999 02:18:59 -0500
To: gtk-devel-list@redhat.com
Path: sopwith
From: sopwith@redhat.com (Elliot Lee)
Newsgroups: gated.gtk-devel-list
Subject: Re: GNOME dumps no core
Date: 1 Nov 1999 07:18:59 GMT
Organization: Red Hat Software
Lines: 36
Distribution: gated
Message-ID: <slrn81qflk.8s5.sopwith@lacrosse.corp.redhat.com>
References: <Pine.LNX.4.10.9911010534041.28899-100000@mini.dhs.org>
NNTP-Posting-Host: lacrosse.corp.redhat.com
X-Trace: stan.redhat.com 941440739 27060 207.175.42.154 (1 Nov 1999 07:18:59 GMT)
X-Complaints-To: abuse@redhat.com
NNTP-Posting-Date: 1 Nov 1999 07:18:59 GMT
User-Agent: slrn/0.9.5.4 (UNIX)

On 1 Nov 1999 00:16:56 -0500, redhog@mini.dhs.org <redhog@mini.dhs.org> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>I recently installed the newest version of the GNOME libs. While I am
>modfying GTK, sometimes thing crashes. And I want to know why. But nowdays
>GNOME programs just shows a nice dialog with a link to the
>crash-info-homepage. And does not dump a core file! How do I debug such a
>stupid program?! Dop anyone know how i force it to generate a core-file
>on crash?

export GNOME_DUMP_CORE=1

There is also the GNOME_DISABLE_CRASH_DIALOG environment variable, so you
can avoid the annoying dialog while debugging. (This will leave crash
handling to the default handlers, which just dump core.)

However, you would be a lot better off just using gdb to attach to the
process and catching the crash in the act.

>By the way, I modified GtkWidget, in a way that enlarged the
>_GtkWidget-struct. This caused gnome programs to crash with an error about
>something somewhere in GtkBin... I tracked it down to the enlargement of
>GtkWidget (Insert a GtkWidget *foo in _GtkWidget, at the end). Is the size
>of that GtkObject hardcoded somewhere?

When you make binary-incompatible changes, you need to recompile everything
that depends on that structure.

If you don't want to rebuild things, instead of putting something in the
struct, you probably should just use object data and a couple of accessor
functions.

-- Elliot
Do not meddle in the affairs of dragons,
for you are crunchy and good with ketchup. 

From redhog@mini.dhs.org  Thu May 11 17:52:42 2000
Received: (qmail 26164 invoked from network); 1 Nov 1999 16:53:54 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 1 Nov 1999 16:53:54 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id LAA10766
	for <gtk-devel-list@redhat.com>; Mon, 1 Nov 1999 11:53:53 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id RAA23350
	for <gtk-devel-list@redhat.com>; Mon, 1 Nov 1999 17:20:03 +0100
Date: Mon, 1 Nov 1999 17:19:58 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: Re: GNOME dumps no core
In-Reply-To: <slrn81qflk.8s5.sopwith@lacrosse.corp.redhat.com>
Message-ID: <Pine.LNX.4.10.9911011716560.28899-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thankyou.

I did realize, after sending the e-mail that that was the reason for
the crashes of GNOMEified program. I OK, it's not that fun to recompile,
but to store the data somewhere else seems to me like huge an uggly
kludge... But I may be rwong on this point. How do you suppose me to store
the data? As a global associative glist?

<A Href="http://www.tekmetrics.com/transcript.shtml?pid=29943">TekMetrics Online Public Transcript (e-certifications[tm])</A><Br>
<A Href="http://mini.dhs.org/PGP%20Public%20key.asc">PGP Public key</A><Br>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4Hb2yHeQ6HSAJlUwRAmIKAJ9wTivoSMqYl5YUn+Jxde/Sq2regQCgrOLN
efcJqlvjos0uDbeEsEGZuvU=
=Dtpa
-----END PGP SIGNATURE-----

From redhog@mini.dhs.org  Thu May 11 17:52:42 2000
Received: (qmail 10836 invoked from network); 2 Nov 1999 13:07:58 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 2 Nov 1999 13:07:58 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id IAA08308
	for <gtk-devel-list@redhat.com>; Tue, 2 Nov 1999 08:07:57 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id NAA31352
	for <gtk-devel-list@redhat.com>; Tue, 2 Nov 1999 13:34:04 +0100
Date: Tue, 2 Nov 1999 13:33:59 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: Patches
Message-ID: <Pine.LNX.4.10.9911021326520.31347-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have developed a patch for Gtk that adds a new feature. How, and where,
do I submit it for review for merging it into the main developement tree?

The patch is available at http://GBlippie.mini.dhs.org

The patch adds a functionality i call blippieness; which is, that the
menus and toolbars are hidden as long as the mouse is not in the window,
hence, the document or other, keyboard modifiable widgets are given more
space. Other widgets may as well be registered to blipp, but only menus
and toolbars do it by default (But that's easy to change). The main usage
of this is if someone implements a driver for the new MS mouse that sends
a signal when you touch a releases it. This driver may then send a enter
nodify/leave notify to the window with the cursor when the mouse is
tuched and released, respectively. This would result in, that when you put
your hands on the keyboard to write a text in your textprocessor, the
menus dissapear, and your possible maximized window is filled with the
text you are editing, only. As soon as you put your hand on the mouse
again, the mouse-modifiable widgets appears again.

More conceptional/philosophical information is available from
http://blippie.mini.dhs.org

<A Href="http://www.tekmetrics.com/transcript.shtml?pid=29943">TekMetrics Online Public Transcript (e-certifications[tm])</A><Br>
<A Href="http://mini.dhs.org/PGP%20Public%20key.asc">PGP Public key</A><Br>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4Hto6HeQ6HSAJlUwRAtslAKCpXDvNG+RMdgDwBI+OXkMOhXpt9QCgoyE9
JRRmrvUX04VwFjSoEjKBIc4=
=NzCR
-----END PGP SIGNATURE-----

From tml@sgic.fi  Thu May 11 17:52:42 2000
Received: (qmail 5682 invoked from network); 2 Nov 1999 22:05:16 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 2 Nov 1999 22:05:16 -0000
Received: from m2.pp.htv.fi (m2ep.pp.htv.fi [212.90.64.98])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id RAA12803
	for <gtk-devel-list@redhat.com>; Tue, 2 Nov 1999 17:05:14 -0500
Received: from m7.pp.htv.fi (m7.pp.htv.fi [212.90.64.22])
	by m2.pp.htv.fi (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id AAA29621
	for <gtk-devel-list@redhat.com>; Wed, 3 Nov 1999 00:04:49 +0200 (EET)
Received: from tippen.tml.iki.fi (cs78232.pp.htv.fi [212.90.78.232])
	by m7.pp.htv.fi (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id AAA13762
	for <gtk-devel-list@redhat.com>; Wed, 3 Nov 1999 00:04:42 +0200 (EET)
Message-ID: <14367.20981.480000.333673@gargle.gargle.HOWL>
Date: Tue, 2 Nov 1999 23:04:53 +0200 (FLE Standard Time)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: gtk-devel-list@redhat.com
Subject: Suggested addition to gtk 1.3: XListFonts wrapper
From: Tor Lillqvist <tml@sgic.fi>
Reply-To: Tor Lillqvist <tml@iki.fi>
X-Mailer: VM 6.73 under Emacs 20.4.1

Does anybody object if I add to gdk (in gtk+'s head branch) two simple
new functions, that on X11 would just be wrappers to XListFonts and
XFreeFontNames. Suggested API:

gchar **gdk_font_list_new (const gchar *pattern, gint **num_returned);
void    gdk_font_list_free (gchar **font_list);

Or, would it be better if the list was returned as a NULL terminated
array, so that g_strfreev could be used to free it, and no separate
freeing function was needed?

I'm not totally happy with that choice of names, but can't think of
any better right now. Suggestions welcome.

--tml

From kde@sun.ceronet.com  Thu May 11 17:52:42 2000
Received: (qmail 1777 invoked from network); 4 Nov 1999 00:30:32 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 4 Nov 1999 00:30:31 -0000
Received: from sun.ceronet.com (root@sun.ceronet.com [195.76.46.98] (may be forged))
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA21425
	for <gtk-devel-list@redhat.com>; Wed, 3 Nov 1999 19:30:30 -0500
Received: from ceronet.com ([213.4.35.175])
	by sun.ceronet.com (8.8.7/8.8.7) with ESMTP id BAA11069
	for <gtk-devel-list@redhat.com>; Thu, 4 Nov 1999 01:26:27 +0100
Sender: kde@sun.ceronet.com
Message-ID: <3820D40C.B0D4D703@ceronet.com>
Date: Thu, 04 Nov 1999 01:32:12 +0100
From: Antonio Campos <acampos@ceronet.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Why gtk applications redraw so slow?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Why gtk applications redraw so slow compared to KDE applications or
others X-Window applications?
Is it inherent to the design of gtk?

From federico@redhat.com  Thu May 11 17:52:42 2000
Received: (qmail 26229 invoked from network); 4 Nov 1999 00:44:29 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 4 Nov 1999 00:44:29 -0000
Received: from guanabana.labs.redhat.com (root@guanabana.labs.redhat.com [207.175.42.58])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA23757
	for <gtk-devel-list@redhat.com>; Wed, 3 Nov 1999 19:44:29 -0500
Received: (from federico@localhost)
	by guanabana.labs.redhat.com (8.9.3/8.9.3) id TAA12583;
	Wed, 3 Nov 1999 19:44:58 -0500
Date: Wed, 3 Nov 1999 19:44:58 -0500
Message-Id: <199911040044.TAA12583@guanabana.labs.redhat.com>
X-Authentication-Warning: guanabana.labs.redhat.com: federico set sender to federico@redhat.com using -f
From: Federico Mena Quintero <federico@redhat.com>
To: gtk-devel-list@redhat.com
In-reply-to: <3820D40C.B0D4D703@ceronet.com> (message from Antonio Campos on
	Thu, 04 Nov 1999 01:32:12 +0100)
Subject: Re: Why gtk applications redraw so slow?
X-Fact-of-life: Some days you are the bug, other days you are the windshield.
References:  <3820D40C.B0D4D703@ceronet.com>

>  Why gtk applications redraw so slow compared to KDE applications or
>  others X-Window applications?
>  Is it inherent to the design of gtk?

Do you have any benchmarks?

If you are using the pixmap theme engine, you are screwed, because it
is buggy.  Use the default theme engine or one of the Gdk-based ones
(like ThinIce).

  Federico

From kde@sun.ceronet.com  Thu May 11 17:52:42 2000
Received: (qmail 6819 invoked from network); 4 Nov 1999 00:51:16 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 4 Nov 1999 00:51:16 -0000
Received: from sun.ceronet.com (root@sun.ceronet.com [195.76.46.98] (may be forged))
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA25570
	for <gtk-devel-list@redhat.com>; Wed, 3 Nov 1999 19:51:15 -0500
Received: from ceronet.com ([213.4.35.175])
	by sun.ceronet.com (8.8.7/8.8.7) with ESMTP id BAA11143
	for <gtk-devel-list@redhat.com>; Thu, 4 Nov 1999 01:47:43 +0100
Sender: kde@sun.ceronet.com
Message-ID: <3820D91A.7AC62B8C@ceronet.com>
Date: Thu, 04 Nov 1999 01:53:47 +0100
From: Antonio Campos <acampos@ceronet.com>
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: Why gtk applications redraw so slow?
References: <3820D40C.B0D4D703@ceronet.com> <199911040044.TAA12583@guanabana.labs.redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Federico Mena Quintero wrote:

> >  Why gtk applications redraw so slow compared to KDE applications or
> >  others X-Window applications?
> >  Is it inherent to the design of gtk?
>
> Do you have any benchmarks?
>
> If you are using the pixmap theme engine, you are screwed, because it
> is buggy.  Use the default theme engine or one of the Gdk-based ones
> (like ThinIce).
>
>   Federico
>
> --
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with
>                        "unsubscribe" as the Subject.

I don't have any benchmarks, but with the same SVGA-Server in 16 bits and
800x600, KDE draws the windows a lot faster than GNOME or
GTK applications do. (The same is true for the Banshee server, as I have
seen it...)
What I mean is that if it's possible than the redrawing of GTK
applications is slower by a factor of design of the API? Does anybody
knows something? Can it be solved?

From dereks@kd-dev.com  Thu May 11 17:52:42 2000
Received: (qmail 19195 invoked from network); 4 Nov 1999 00:57:02 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 4 Nov 1999 00:57:02 -0000
Received: from archer.kd-dev.com (dereks@archer.kd-dev.com [206.124.150.175])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA26967
	for <gtk-devel-list@redhat.com>; Wed, 3 Nov 1999 19:57:01 -0500
Received: from localhost (dereks@localhost)
	by archer.kd-dev.com (8.8.7/8.8.7) with ESMTP id QAA18295
	for <gtk-devel-list@redhat.com>; Wed, 3 Nov 1999 16:51:54 -0800
Date: Wed, 3 Nov 1999 16:51:54 -0800 (PST)
From: Derek Simkowiak <dereks@kd-dev.com>
To: gtk-devel-list@redhat.com
Subject: Re: Why gtk applications redraw so slow?
In-Reply-To: <3820D91A.7AC62B8C@ceronet.com>
Message-ID: <Pine.LNX.4.04.9911031649230.18109-100000@archer.kd-dev.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> knows something? Can it be solved?

	Your information is not specific enough.  What applications are 
you using to compare?  What window manager are you using?  What theme?
What factor of speed difference?  What other apps are you running?

	For me, GTk+ applications seem to redraw FASTER than KDE/Qt apps.
The discussion is pointless unless you have specific details...

--Derek

From federico@redhat.com  Thu May 11 17:52:42 2000
Received: (qmail 1189 invoked from network); 4 Nov 1999 05:43:30 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 4 Nov 1999 05:43:30 -0000
Received: from smtp7.atl.mindspring.net (smtp7.atl.mindspring.net [207.69.128.51])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id AAA16065
	for <gtk-devel-list@redhat.com>; Thu, 4 Nov 1999 00:43:28 -0500
Received: from guanabana.labs.redhat.com (user-2ivf7u2.dialup.mindspring.com [165.247.159.194])
	by smtp7.atl.mindspring.net (8.8.5/8.8.5) with ESMTP id AAA07565
	for <gtk-devel-list@redhat.com>; Thu, 4 Nov 1999 00:43:26 -0500 (EST)
Received: (from federico@localhost)
	by guanabana.labs.redhat.com (8.9.3/8.9.3) id AAA15013;
	Thu, 4 Nov 1999 00:43:57 -0500
Date: Thu, 4 Nov 1999 00:43:57 -0500
Message-Id: <199911040543.AAA15013@guanabana.labs.redhat.com>
X-Authentication-Warning: guanabana.labs.redhat.com: federico set sender to federico@redhat.com using -f
From: Federico Mena Quintero <federico@redhat.com>
To: gtk-devel-list@redhat.com
In-reply-to: <3820D91A.7AC62B8C@ceronet.com> (message from Antonio Campos on
	Thu, 04 Nov 1999 01:53:47 +0100)
Subject: Re: Why gtk applications redraw so slow?
X-Indecision: is the key to Flexibility.
References: <3820D40C.B0D4D703@ceronet.com> <199911040044.TAA12583@guanabana.labs.redhat.com> <3820D91A.7AC62B8C@ceronet.com>

>  What I mean is that if it's possible than the redrawing of GTK
>  applications is slower by a factor of design of the API? Does anybody
>  knows something? Can it be solved?

You didn't say what theme engine you are using.

  Federico

From redhog@mini.dhs.org  Thu May 11 17:52:42 2000
Received: (qmail 32547 invoked from network); 4 Nov 1999 07:32:49 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 4 Nov 1999 07:32:49 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id CAA02408
	for <gtk-devel-list@redhat.com>; Thu, 4 Nov 1999 02:32:47 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id HAA10131
	for <gtk-devel-list@redhat.com>; Thu, 4 Nov 1999 07:58:46 +0100
Date: Thu, 4 Nov 1999 07:58:40 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: Re: Why gtk applications redraw so slow?
In-Reply-To: <Pine.LNX.4.04.9911031649230.18109-100000@archer.kd-dev.com>
Message-ID: <Pine.LNX.4.10.9911040757320.9801-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I think the key here is "what theme are you using"? SLow themes will of
course slow down Gtk. Much more than an evil window manager or application
can ever do...

<A Href="http://www.tekmetrics.com/transcript.shtml?pid=29943">TekMetrics Online Public Transcript (e-certifications[tm])</A><Br>
<A Href="http://mini.dhs.org/PGP%20Public%20key.asc">PGP Public key</A><Br>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4IS6kHeQ6HSAJlUwRAqd9AJ4vh4EHhp2omV34e+wgvxf2qtHrlgCfdneK
VVvFY+djuYBOl9vdggy2H+w=
=fbCT
-----END PGP SIGNATURE-----

From sd90034@lanet.lv  Thu May 11 17:52:42 2000
Received: (qmail 22738 invoked from network); 4 Nov 1999 08:32:13 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 4 Nov 1999 08:32:13 -0000
Received: from ieva06.lanet.lv (ieva06.lanet.lv [195.13.129.106])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id DAA10141
	for <gtk-devel-list@redhat.com>; Thu, 4 Nov 1999 03:32:10 -0500
Received: from ieva01.lanet.lv (ieva01 [195.13.129.101])
	by ieva06.lanet.lv (8.9.3/8.9.1) with ESMTP id KAA20722
	for <gtk-devel-list@redhat.com>; Thu, 4 Nov 1999 10:18:46 +0200
Received: from localhost (sd90034@localhost)
	by ieva01.lanet.lv (8.9.3/8.9.0) with ESMTP id KAA90356
	for <gtk-devel-list@redhat.com>; Thu, 4 Nov 1999 10:18:46 +0200
X-Authentication-Warning: ieva01.lanet.lv: sd90034 owned process doing -bs
Date: Thu, 4 Nov 1999 10:18:45 +0200 (WET)
From: Alexander Piskunov <sd90034@lanet.lv>
To: gtk-devel-list@redhat.com
Subject: Re: Why gtk applications redraw so slow?
In-Reply-To: <3820D40C.B0D4D703@ceronet.com>
Message-ID: <Pine.A41.4.05.9911041013280.163758-100000@ieva01.lanet.lv>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Thu, 4 Nov 1999, Antonio Campos wrote:

> 
> Why gtk applications redraw so slow compared to KDE applications or
> others X-Window applications?
> Is it inherent to the design of gtk?
> 
To many overhead, too many unneeded redraws - this is a reason. Hundreds
of X calls to draw ordinary window.
Drawing engine will be changed in future versions to pixmap backed. All
drawing will go to memory buffer and only resulting pixmap will be
displayed.
Perhaps this technique is used in Motif, Qt, Win9x and other toolkits (at
least it seems so:)

From ee96090@fe.up.pt  Thu May 11 17:52:42 2000
Received: (qmail 27150 invoked from network); 4 Nov 1999 12:51:56 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 4 Nov 1999 12:51:56 -0000
Received: from deec01ws60.fe.up.pt (ee96090@deec01ws60.fe.up.pt [193.136.54.60])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id HAA28633
	for <gtk-devel-list@redhat.com>; Thu, 4 Nov 1999 07:51:54 -0500
Received: from localhost (ee96090@localhost)
	by deec01ws60.fe.up.pt (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA01305
	for <gtk-devel-list@redhat.com>; Thu, 4 Nov 1999 12:51:29 GMT
X-Authentication-Warning: deec01ws60.fe.up.pt: ee96090 owned process doing -bs
Date: Thu, 4 Nov 1999 12:51:29 +0000 (WET)
From: =?ISO-8859-1?Q?Gustavo_Jo=E3o_Alves_Marques_Carneiro?= <ee96090@fe.up.pt>
To: gtk-devel-list@redhat.com
Subject: Re: Why gtk applications redraw so slow?
In-Reply-To: <Pine.A41.4.05.9911041013280.163758-100000@ieva01.lanet.lv>
Message-ID: <Pine.LNX.4.20.9911041246040.1303-100000@deec01ws60.fe.up.pt>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 4 Nov 1999, Alexander Piskunov wrote:

> 
> 
> On Thu, 4 Nov 1999, Antonio Campos wrote:
> 
> > 
> > Why gtk applications redraw so slow compared to KDE applications or
> > others X-Window applications?
> > Is it inherent to the design of gtk?
> > 
> To many overhead, too many unneeded redraws - this is a reason. Hundreds
> of X calls to draw ordinary window.
> Drawing engine will be changed in future versions to pixmap backed. All
> drawing will go to memory buffer and only resulting pixmap will be
> displayed.

Yes, that is true. I've seen it myself when I was trying to change the
gtkruler sources to make a custom ruler. I found something odd: the
Gtk?Ruler (GtkHRuler or GtkVRuler) uses an memory pixmap to instead of
drawing directly to the window. But, every time it receives an expose
event, it completely redraws the memory pixmap and then blits it to
widget's x window. I simply cannot understand why it was done that way.


> Perhaps this technique is used in Motif, Qt, Win9x and other toolkits (at
> least it seems so:)
> 
> 
> 

-- 
Gustavo J.A.M. Carneiro
World::Portugal::FEUP::DEEC::LEEC::TEC
[reinolinux.fe.up.pt/~ee96090]
                                       

From hp@redhat.com  Thu May 11 17:52:42 2000
Received: (qmail 27150 invoked from network); 5 Nov 1999 17:34:14 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 5 Nov 1999 17:34:14 -0000
Received: from icon.labs.redhat.com (root@icon.labs.redhat.com [207.175.42.144])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA13902
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 12:34:13 -0500
Received: from localhost (hp@localhost)
	by icon.labs.redhat.com (8.9.3/8.9.3) with ESMTP id MAA06774
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 12:24:19 -0500
X-Authentication-Warning: icon.labs.redhat.com: hp owned process doing -bs
Date: Fri, 5 Nov 1999 12:24:19 -0500 (EST)
From: Havoc Pennington <hp@redhat.com>
X-Sender: hp@icon.labs.redhat.com
To: gtk-devel-list@redhat.com
Subject: hash table freeze is useless
Message-ID: <Pine.LNX.4.10.9911051217300.6499-100000@icon.labs.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hi,

I was just noticing that g_hash_table_insert() performs a hash lookup.  
This means that if you freeze the hash table, then insert a lot of items,
the performance of g_hash_table_insert() will be degenerating into O(n)
over time, so your insert-items loop will have O(n^2) performance. Without
the freeze, it is basically O(n) (with the hash resizes amortized, and
each insertion constant time).

For small values of n, it's probably a toss-up; for large values of n,
freeze() almost certainly causes a performance hit.

Unless I'm wrong of course, please comment. ;-)

Recommended solution would be to make freeze/thaw no-ops and say in the
docs that they are deprecated.

A better solution than freeze/thaw might be a way to set the expected
number of items, g_hash_table_resize_for(hash, n_items) which would resize
the table in advance to accomodate that number of additional items, saving 
n_items re-insertions and perhaps reducing the total number of resizes.

Havoc



From daveb@idealab.com  Thu May 11 17:52:42 2000
Received: (qmail 22126 invoked from network); 5 Nov 1999 17:57:15 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 5 Nov 1999 17:57:15 -0000
Received: from idealab.com (santino.idealab.com [206.132.100.34])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id MAA16978
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 12:57:14 -0500
Received: (qmail 31246 invoked by uid 535); 5 Nov 1999 17:57:21 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 5 Nov 1999 17:57:21 -0000
Date: Fri, 5 Nov 1999 09:57:21 -0800 (PST)
From: David Benson <daveb@idealab.com>
X-Sender: daveb@luca.hivemind.idealab.com
To: gtk-devel-list@redhat.com
Subject: Re: hash table freeze is useless
In-Reply-To: <Pine.LNX.4.10.9911051217300.6499-100000@icon.labs.redhat.com>
Message-ID: <Pine.LNX.4.10.9911050956120.30832-100000@luca.hivemind.idealab.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> I was just noticing that g_hash_table_insert() performs a hash lookup.  
> This means that if you freeze the hash table, then insert a lot of items,
> the performance of g_hash_table_insert() will be degenerating into O(n)
> over time, so your insert-items loop will have O(n^2) performance. Without
> the freeze, it is basically O(n) (with the hash resizes amortized, and
> each insertion constant time).
> 
> A better solution than freeze/thaw might be a way to set the expected
> number of items, g_hash_table_resize_for(hash, n_items) which would resize
> the table in advance to accomodate that number of additional items, saving 
> n_items re-insertions and perhaps reducing the total number of resizes.

I believe the intent is so you can freeze a hashtable that is 
large, delete half the items, insert a bunch of new items
without resizing the table extraneously.

- Dave

From kaz@FootPrints.net  Thu May 11 17:52:43 2000
Received: (qmail 3370 invoked from network); 5 Nov 1999 18:28:33 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 5 Nov 1999 18:28:33 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id NAA21578
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 13:28:28 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11jo6A-00044T-00
	for gtk-devel-list@redhat.com; Fri, 05 Nov 1999 10:28:30 -0800
Date: Fri, 5 Nov 1999 10:28:30 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
Subject: Re: hash table freeze is useless
In-Reply-To: <Pine.LNX.4.10.9911050956120.30832-100000@luca.hivemind.idealab.com>
Message-ID: <Pine.LNX.4.10.9911051023240.15542-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Fri, 5 Nov 1999, David Benson wrote:
> 
> > I was just noticing that g_hash_table_insert() performs a hash lookup.  
> > This means that if you freeze the hash table, then insert a lot of items,
> > the performance of g_hash_table_insert() will be degenerating into O(n)
> > over time, so your insert-items loop will have O(n^2) performance. Without
> > the freeze, it is basically O(n) (with the hash resizes amortized, and
> > each insertion constant time).
> > 
> > A better solution than freeze/thaw might be a way to set the expected
> > number of items, g_hash_table_resize_for(hash, n_items) which would resize
> > the table in advance to accomodate that number of additional items, saving 
> > n_items re-insertions and perhaps reducing the total number of resizes.
> 
> I believe the intent is so you can freeze a hashtable that is 
> large, delete half the items, insert a bunch of new items
> without resizing the table extraneously.

In Kazlib I have a different approach: there is a special delete function
which does not resize the table. The documented intent is not for performance,
but rather to allow the current item to be deleted during table traversal
without destroying the validity of the iterator.

Also, hash_insert doesn't perform any lookup: the constraint prohibiting
duplicate keys must be validated by the application.  If the app can ensure by
means other than a lookup that keys are unique, it shouldn't have to pay for
a redundant lookup buried in the insertion.

From jirka@5z.com  Thu May 11 17:52:43 2000
Received: (qmail 4923 invoked from network); 5 Nov 1999 21:39:29 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 5 Nov 1999 21:39:29 -0000
Received: from zinc.5z.com (jirka@5z.com [208.137.250.195])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA18132
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 16:39:28 -0500
Received: (from jirka@localhost)
	by zinc.5z.com (8.8.7/8.8.7) id NAA06138
	for gtk-devel-list@redhat.com; Fri, 5 Nov 1999 13:39:38 -0800
Message-ID: <19991105133937.A6121@zinc.5z.com>
Date: Fri, 5 Nov 1999 13:39:37 -0800
From: George <jirka@5z.com>
To: gtk-devel-list@redhat.com
Subject: Re: hash table freeze is useless
References: <Pine.LNX.4.10.9911051217300.6499-100000@icon.labs.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93.2
In-Reply-To: <Pine.LNX.4.10.9911051217300.6499-100000@icon.labs.redhat.com>; from Havoc Pennington on Fri, Nov 05, 1999 at 12:24:19PM -0500

On Fri, Nov 05, 1999 at 12:24:19PM -0500, Havoc Pennington wrote:
> I was just noticing that g_hash_table_insert() performs a hash lookup.  
> This means that if you freeze the hash table, then insert a lot of items,
> the performance of g_hash_table_insert() will be degenerating into O(n)
> over time, so your insert-items loop will have O(n^2) performance. Without
> the freeze, it is basically O(n) (with the hash resizes amortized, and
> each insertion constant time).

perhaps if a hash table is frozen then insert should not do a lookup, it
would do a lookup only when it's thawed (it would loop over the list of
queued inserts)

George

From hp@redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 2831 invoked from network); 5 Nov 1999 22:51:05 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 5 Nov 1999 22:51:05 -0000
Received: from icon.labs.redhat.com (root@icon.labs.redhat.com [207.175.42.144])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id RAA30322
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 17:51:04 -0500
Received: from localhost (hp@localhost)
	by icon.labs.redhat.com (8.9.3/8.9.3) with ESMTP id RAA01506
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 17:25:19 -0500
X-Authentication-Warning: icon.labs.redhat.com: hp owned process doing -bs
Date: Fri, 5 Nov 1999 17:25:19 -0500 (EST)
From: Havoc Pennington <hp@redhat.com>
X-Sender: hp@icon.labs.redhat.com
To: gtk-devel-list@redhat.com
Subject: Re: hash table freeze is useless
In-Reply-To: <Pine.LNX.4.10.9911050956120.30832-100000@luca.hivemind.idealab.com>
Message-ID: <Pine.LNX.4.10.9911051722590.6499-100000@icon.labs.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Fri, 5 Nov 1999, David Benson wrote:
> 
> I believe the intent is so you can freeze a hashtable that is 
> large, delete half the items, insert a bunch of new items
> without resizing the table extraneously.
> 

Ah yes, it works for that. I do think the function is intended (or at
least documented) to work in the case where the table was not already
large, however. And even in the above case it breaks if you insert more
items than you delete.

Havoc

From daveb@idealab.com  Thu May 11 17:52:43 2000
Received: (qmail 32706 invoked from network); 5 Nov 1999 23:11:13 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 5 Nov 1999 23:11:13 -0000
Received: from idealab.com (santino.idealab.com [206.132.100.34])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id SAA01113
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 18:11:12 -0500
Received: (qmail 23247 invoked by uid 535); 5 Nov 1999 23:11:20 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 5 Nov 1999 23:11:20 -0000
Date: Fri, 5 Nov 1999 15:11:20 -0800 (PST)
From: David Benson <daveb@idealab.com>
X-Sender: daveb@luca.hivemind.idealab.com
To: gtk-devel-list@redhat.com
Subject: Re: hash table freeze is useless
In-Reply-To: <Pine.LNX.4.10.9911051722590.6499-100000@icon.labs.redhat.com>
Message-ID: <Pine.LNX.4.10.9911051504550.22807-100000@luca.hivemind.idealab.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

I think it was kaz who pointed out that
it is safe to add and remove items
while iterating a frozen hashtable.  (At least according
to my quick inspection.)  Of course,
you'd better not delete the node you are visiting.

No strategy which supports resizing can easily support that
feature...

- Dave


On Fri, 5 Nov 1999, Havoc Pennington wrote:

> 
> On Fri, 5 Nov 1999, David Benson wrote:
> > 
> > I believe the intent is so you can freeze a hashtable that is 
> > large, delete half the items, insert a bunch of new items
> > without resizing the table extraneously.
> > 
> 
> Ah yes, it works for that. I do think the function is intended (or at
> least documented) to work in the case where the table was not already
> large, however. And even in the above case it breaks if you insert more
> items than you delete.
> 
> Havoc
> 
> 
> -- 
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with 
>                        "unsubscribe" as the Subject.
> 
> 

From dereks@kd-dev.com  Thu May 11 17:52:43 2000
Received: (qmail 6017 invoked from network); 5 Nov 1999 23:14:53 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 5 Nov 1999 23:14:53 -0000
Received: from archer.kd-dev.com (dereks@archer.kd-dev.com [206.124.150.175])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA01751
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 18:14:52 -0500
Received: from localhost (dereks@localhost)
	by archer.kd-dev.com (8.8.7/8.8.7) with ESMTP id PAA22543
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 15:09:51 -0800
Date: Fri, 5 Nov 1999 15:09:51 -0800 (PST)
From: Derek Simkowiak <dereks@kd-dev.com>
To: gtk-devel-list@redhat.com
Subject: Re: hash table freeze is useless
In-Reply-To: <Pine.LNX.4.10.9911051023240.15542-100000@ashi.FootPrints.net>
Message-ID: <Pine.LNX.4.04.9911051507240.22469-100000@archer.kd-dev.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> In Kazlib I have a different approach: there is a special delete function
> which does not resize the table. The documented intent is not for performance,
> but rather to allow the current item to be deleted during table traversal
> without destroying the validity of the iterator.

	In Glib, the hash table is opaque and the iterator is never known
to the user.  That is how Glib lets you use strings, structs, and other
such goodies as keys to your key/value pairs.

> Also, hash_insert doesn't perform any lookup: the constraint prohibiting
> duplicate keys must be validated by the application.

	Glib overwrites the value of the key/value pair if you supply a
key that already exists.

--Derek

From dereks@kd-dev.com  Thu May 11 17:52:43 2000
Received: (qmail 5084 invoked from network); 5 Nov 1999 23:35:09 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 5 Nov 1999 23:35:09 -0000
Received: from archer.kd-dev.com (dereks@archer.kd-dev.com [206.124.150.175])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA05121
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 18:35:08 -0500
Received: from localhost (dereks@localhost)
	by archer.kd-dev.com (8.8.7/8.8.7) with ESMTP id PAA22562
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 15:30:08 -0800
Date: Fri, 5 Nov 1999 15:30:08 -0800 (PST)
From: Derek Simkowiak <dereks@kd-dev.com>
To: gtk-devel-list@redhat.com
Subject: Re: hash table freeze is useless
In-Reply-To: <Pine.LNX.4.10.9911051722590.6499-100000@icon.labs.redhat.com>
Message-ID: <Pine.LNX.4.04.9911051455300.22469-100000@archer.kd-dev.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> > I believe the intent is so you can freeze a hashtable that is 
> > large, delete half the items, insert a bunch of new items
> > without resizing the table extraneously.
[...]
> Ah yes, it works for that. I do think the function is intended (or at
> least documented) to work in the case where the table was not already
> large, however. And even in the above case it breaks if you insert more
> items than you delete.

	Why does g_hash_table_insert perform a lookup (by calling
g_hash_table_lookup_node)?

	It does so because if the node already exists, then we simply want
to overwrite the value (of the key/value pair) that is already there.  As
the source says:

  if (*node)
    {
      /* do not reset node->key in this place, keeping
       * the old key might be intended.
       * a g_hash_table_remove/g_hash_table_insert pair
       * can be used otherwise.
       *
       * node->key = key; */
      (*node)->value = value;
    }

	...but if the node does *not* exist, then we must create a new
node with g_hash_node_new.  And after adding a new node, we should see if
the hash table needs resizing:

  else
    {
      *node = g_hash_node_new (key, value);
      hash_table->nnodes++;
      if (!hash_table->frozen)
        g_hash_table_resize (hash_table);
    }  

	Notice that the g_hash_table_resize only gets called if the table
is not frozen.  g_hash_table_resize does a few calculations to determine
whether or not a resizing of the table is actually necessary.  Here
are those calculations:

  if ((nodes_per_list > 0.3 || hash_table->size <= HASH_TABLE_MIN_SIZE) &&
      (nodes_per_list < 3.0 || hash_table->size >= HASH_TABLE_MAX_SIZE))
    return;

	When the table is frozen, you save those calculations (and any
actual resizing that would occur) every time you insert an item.

	When the table is thawed, the table is resized one time only.  A
resize involves going through this loop:

  for (i = 0; i < hash_table->size; i++)
    for (node = hash_table->nodes[i]; node; node = next)
      {
        next = node->next;
  
        hash_val = (* hash_table->hash_func) (node->key) % new_size;
                   
        node->next = new_nodes[hash_val];
        new_nodes[hash_val] = node;
      }

	...which can take a while.  Calling this loop once, instead of
several times (as you add a large number of items) speeds things up.

	Havoc's complaint, if I read it correctly, is with the
g_hash_table_lookup_node that gets called every time you insert an item.
To remove that call from g_hash_table_insert, we would have to have some
other way to see whether or not the node holding the given "key" (of the
key/value pair) already exists.  Otherwise, how will we know whether or
not to allocate the memory for a new node (instead of simply overwriting
the value in the given key/value pair)?

	In short, I think this is a problem caused by having keys which
are not the same thing as your calculated hash value.  Glib handles
collisions with linked lists, so when your table is frozen and you add a
large number of items, your insertions will approach the speed of a
linked-list lookup.  It's anyone's guess as to whether that will slow
things down more than performing the resize test calculations plus
periodic resizing of the table.  It might be fun to write a test program
and run some benchmarks....


--Derek Simkowiak
  dereks@kd-dev.com

From kaz@FootPrints.net  Thu May 11 17:52:43 2000
Received: (qmail 15615 invoked from network); 6 Nov 1999 00:00:04 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 6 Nov 1999 00:00:04 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA09847
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 19:00:02 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11jtH2-0005oG-00
	for gtk-devel-list@redhat.com; Fri, 05 Nov 1999 16:00:04 -0800
Date: Fri, 5 Nov 1999 16:00:04 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
Subject: Re: hash table freeze is useless
In-Reply-To: <Pine.LNX.4.10.9911051504550.22807-100000@luca.hivemind.idealab.com>
Message-ID: <Pine.LNX.4.10.9911051542210.21915-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Fri, 5 Nov 1999, David Benson wrote:

> while iterating a frozen hashtable.  (At least according
> to my quick inspection.)  Of course,
> you'd better not delete the node you are visiting.

Being able to delete the node you are visiting is lets you easily implement
search-and-destroy type operations such as, oh, cache expiry and the like.

> No strategy which supports resizing can easily support that
> feature...

It's as easy as advancing to the next node and then deleting the previous one,
which is no longer the currently visited node.  This strategy can be
internalized by the traversal interface so the user can simply go ahead and
delete the visited node.

In kazlib, the ``iterator'' object (hscan_t) knows in advance which node is
going to be visited next, so deleting the currently visited node is of no
consequence. However, deleting the next-to-visit node and then advancing would
be disastrous. (The interface spec makes it clear that the *only* deletion that
may be done without invalidating an iterator is in fact the deletion of the
node most recently returned by the iterator; all other deletions invalidate the
iterator). 

From kaz@FootPrints.net  Thu May 11 17:52:43 2000
Received: (qmail 21695 invoked from network); 6 Nov 1999 00:46:39 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 6 Nov 1999 00:46:39 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA21088
	for <gtk-devel-list@redhat.com>; Fri, 5 Nov 1999 19:46:39 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11ju0B-00065I-00
	for gtk-devel-list@redhat.com; Fri, 05 Nov 1999 16:46:43 -0800
Date: Fri, 5 Nov 1999 16:46:43 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
Subject: Re: hash table freeze is useless
In-Reply-To: <Pine.LNX.4.04.9911051455300.22469-100000@archer.kd-dev.com>
Message-ID: <Pine.LNX.4.10.9911051600370.21915-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Fri, 5 Nov 1999, Derek Simkowiak wrote:

> Date: Fri, 5 Nov 1999 15:30:08 -0800 (PST)
> From: Derek Simkowiak <dereks@kd-dev.com>
> Reply-To: gtk-devel-list@redhat.com
> To: gtk-devel-list@redhat.com
> Subject: Re: hash table freeze is useless
> Resent-Date: 5 Nov 1999 23:35:09 -0000
> Resent-From: gtk-devel-list@redhat.com
> Resent-cc: recipient list not shown: ;
> 
> > > I believe the intent is so you can freeze a hashtable that is 
> > > large, delete half the items, insert a bunch of new items
> > > without resizing the table extraneously.
> [...]
> > Ah yes, it works for that. I do think the function is intended (or at
> > least documented) to work in the case where the table was not already
> > large, however. And even in the above case it breaks if you insert more
> > items than you delete.
> 
> 	Why does g_hash_table_insert perform a lookup (by calling
> g_hash_table_lookup_node)?
> 
> 	It does so because if the node already exists, then we simply want
> to overwrite the value (of the key/value pair) that is already there.  As
> the source says:

On a different topic, this is a waste for the sake of convenience. It means
that every insertion of a *new* key is at least as expensive as a search for a
non-existent node, which requires traversing a chain all the way to the end.
The task of checking for a duplicate could be delegated to the application,
which could then replace the data value if a matching node is found, else
allocate a new one.  Hrm. It's a matter of interface religion, I suppose.

>   if (*node)
>     {
>       /* do not reset node->key in this place, keeping
>        * the old key might be intended.
>        * a g_hash_table_remove/g_hash_table_insert pair
>        * can be used otherwise.
>        *
>        * node->key = key; */
>       (*node)->value = value;
>     }
> 
> 	...but if the node does *not* exist, then we must create a new
> node with g_hash_node_new.  And after adding a new node, we should see if
> the hash table needs resizing:
> 
>   else
>     {
>       *node = g_hash_node_new (key, value);
>       hash_table->nnodes++;
>       if (!hash_table->frozen)
>         g_hash_table_resize (hash_table);

Ah, so if a table was just thawed after massive deletion, an insertion could,
paradoxically, trigger shrinkage. Thus this algorithm has to check for both
possibilities (growth or shrinkage) after each insert or delete operation.

>     }  
> 
> 	Notice that the g_hash_table_resize only gets called if the table
> is not frozen.  g_hash_table_resize does a few calculations to determine
> whether or not a resizing of the table is actually necessary.  Here
> are those calculations:
> 
>   if ((nodes_per_list > 0.3 || hash_table->size <= HASH_TABLE_MIN_SIZE) &&
>       (nodes_per_list < 3.0 || hash_table->size >= HASH_TABLE_MAX_SIZE))
>     return;
> 
> 	When the table is frozen, you save those calculations (and any
> actual resizing that would occur) every time you insert an item.

Why do they do all the floating point math? The trigger load factors could be
converted to integers each time a shrinkage or growth occurs.  Then to decide
whether to grow or shrink, all you need is to compare the number of nodes
against the integral trigger bounds. 

The nodes_per_list is simply the load factor, or nodes / chains. Thus

	nodes_per_list > 0.3

can be rewritten as

	nodes / chains > 0.3

Then multiplying both sides by chains yields

	nodes > 0.3 * chains

and of course, the right hand side does not vary with insertions and
deletions, since the number of chains changes only during a growth or
shrinking! Thus the right hand side can be pre-computed into an integer.
So you never have to compute or maintain the nodes_per_list (load factor)
value.

My current implementation uses load factors 0.5 and 2.0: load greater than
or equal to 2.0 triggers growth, half or less triggers shrinking.
The table size, and limits, are always powers of two, so they simply 
shift left or right during growth and shrinking.

I also resize the table in place.

> 	When the table is thawed, the table is resized one time only.  A
> resize involves going through this loop:
> 
>   for (i = 0; i < hash_table->size; i++)
>     for (node = hash_table->nodes[i]; node; node = next)
>       {
>         next = node->next;
>   
>         hash_val = (* hash_table->hash_func) (node->key) % new_size;

This could be improved by storing the hashed value in each node instead of
calling the hashing function again?  It would not only speed up grow and shrink
operations, but insert and lookup operations too.

If you have the hash value stored in each node, you can use it to quickly
reject keys that do not match simply by comparing hashed values. A failed
search then will perform, in many cases, no comparisons at all, and in many
cases a successful search for a key will perform only one comparison to verify
the match. The rare exceptions occur when there is a false positive match on
the hash value between distinct keys.

Of course, these two advantages must be weighed against the extra storage per
node.

>       node->next = new_nodes[hash_val];
>       new_nodes[hash_val] = node;

The resizing could actually be done in place with a little cleverness, if the
table sizes are constrained to powers of two.  Note that when you double the
size of a table, you expose one extra bit in each hash value.
What happens is that the nodes from each chain either stay in the same
chain C, or they go to chain N + C, where N is the old table size.
(Let's call this the cousin chain).

So you can grow the table in place (at least potentially) using realloc()
and then do this chain splitting where you use the newly exposed bit as
a discriminator---zero == node stays, one == node moves to new cousin chain in
the upper half of the table.

Shrinking is then nice too. Merge cousin chains from the upper and lower
half of the table, so that the upper half of the table is vacated. Then realloc
the table to half the original size. Note that you never have to examine the
keys (never mind calling the hashing function). Depending on the chain
implementation, the merge might even be done without tail chasing.

Anyway, those are just my rants based on the presented code snippets. ;)

From chak@is.tsukuba.ac.jp  Thu May 11 17:52:43 2000
Received: (qmail 32185 invoked from network); 6 Nov 1999 07:15:40 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 6 Nov 1999 07:15:40 -0000
Received: from greyarea.is.tsukuba.ac.jp (root@greyarea.is.tsukuba.ac.jp [130.158.80.163])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id CAA26712;
	Sat, 6 Nov 1999 02:15:38 -0500
Received: from enki.is.tsukuba.ac.jp (ppp0.score.is.tsukuba.ac.jp [130.158.80.222])
	by greyarea.is.tsukuba.ac.jp (8.9.1/8.9.1) with ESMTP id QAA18412;
	Sat, 6 Nov 1999 16:23:33 +0900
Received: from localhost (localhost [127.0.0.1])
	by enki.is.tsukuba.ac.jp (8.9.3/8.9.3) with ESMTP id QAA12990;
	Sat, 6 Nov 1999 16:12:27 +0900
To: gtk-devel-list@redhat.com, hp@redhat.com
Subject: Re: hash table freeze is useless
In-Reply-To: Your message of "Fri, 5 Nov 1999 12:24:19 -0500 (EST)"
	<Pine.LNX.4.10.9911051217300.6499-100000@icon.labs.redhat.com>
References: <Pine.LNX.4.10.9911051217300.6499-100000@icon.labs.redhat.com>
X-Mailer: Mew version 1.92.4 on XEmacs 20.4 (Emerald)
X-URL: http://www.score.is.tsukuba.ac.jp/~chak/
Reply-To: chak@is.tsukuba.ac.jp
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <19991106161227H.chak@is.tsukuba.ac.jp>
Date: Sat, 06 Nov 1999 16:12:27 +0900
From: "Manuel M. T. Chakravarty" <chak@is.tsukuba.ac.jp>
X-Dispatcher: imput version 990425(IM115)
Lines: 75

Havoc Pennington <hp@redhat.com> wrote,

> I was just noticing that g_hash_table_insert() performs a hash lookup.  
> This means that if you freeze the hash table, then insert a lot of items,
> the performance of g_hash_table_insert() will be degenerating into O(n)
> over time, so your insert-items loop will have O(n^2) performance. Without
> the freeze, it is basically O(n) (with the hash resizes amortized, and
> each insertion constant time).
> 
> For small values of n, it's probably a toss-up; for large values of n,
> freeze() almost certainly causes a performance hit.
> 
> Unless I'm wrong of course, please comment. ;-)
> 
> Recommended solution would be to make freeze/thaw no-ops and say in the
> docs that they are deprecated.
> 
> A better solution than freeze/thaw might be a way to set the expected
> number of items, g_hash_table_resize_for(hash, n_items) which would resize
> the table in advance to accomodate that number of additional items, saving 
> n_items re-insertions and perhaps reducing the total number of resizes.

Did anybody ever notice a performance problem when inserting
or removing a large number items without freezing the table?
I believe that there won't be any performance problem and
table freeze is indeed useless.

The reason for this claim is that table resizing is done in
exponential steps, ie, in the current implementation the
table size is tripled when growing or divided by three when
shrinking.  Let's suppose, we insert `n' elements into an
empty table.  There will be `ld3 n' resizes, where `ld3' is
denoting the logarithm to base 3.  The size of the table
during resizing will be 3^1, 3^2, 3^3, 3^4, etc., or in
other words, the sum of the number of items touched during
all resize operations together is

    \sum_{n=1}^{ld3 n} 3^n 
  <
    2 * n

(This calculation neglects that hash table sizes are
required to be prime numbers, but that won't change the
qualitative result, I believe.)

This means that doing all the intermediate resize operations
is less than twice as much work as doing only a single
resize in the end, or in other words, the last resize will
dominate the overall cost anyway.

Even g_hash_table_resize_for() won't help much.  Compared to 
inserting `n' elements, resizing a table with `n' elements
(the dominate cost of resizing) is relatively cheap.
Resizing is done in a compact nested loop:

  new_nodes = g_new0 (GHashNode*, new_size);
  for (i = 0; i < hash_table->size; i++)
    for (node = hash_table->nodes[i]; node; node = next)
      {
	next = node->next;

	hash_val = (* hash_table->hash_func) (node->key) % new_size;

	node->next = new_nodes[hash_val];
	new_nodes[hash_val] = node;
      }

In contrast, insert requires a function call for each insert
and allocates each node at a time.  In fact resizing may be
beneficial for performance, because all nodes are getting to
be in a consecutive memory area, which will usually improve
the cache hit rate when there are successive hash table
operations.

Manuel

From miguel@gnu.org  Thu May 11 17:52:43 2000
Received: (qmail 5324 invoked from network); 6 Nov 1999 19:11:22 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 6 Nov 1999 19:11:22 -0000
Received: from erandi.nuclecu.unam.mx (root@WHITAKER-TWENTY-SIX.MIT.EDU [18.56.5.26])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA00019
	for <gtk-devel-list@redhat.com>; Sat, 6 Nov 1999 14:11:21 -0500
Received: (from miguel@localhost)
	by erandi.nuclecu.unam.mx (8.9.3/8.9.3) id EAA10017;
	Thu, 4 Nov 1999 04:21:55 -0600
Date: Thu, 4 Nov 1999 04:21:55 -0600
Message-Id: <199911041021.EAA10017@erandi.nuclecu.unam.mx>
From: Miguel de Icaza <miguel@gnu.org>
To: gtk-devel-list@redhat.com
In-reply-to: <3820D91A.7AC62B8C@ceronet.com> (message from Antonio Campos on
	Thu, 04 Nov 1999 01:53:47 +0100)
Subject: Re: Why gtk applications redraw so slow?
X-Info: When in doubt, blame the network
References: <3820D40C.B0D4D703@ceronet.com> <199911040044.TAA12583@guanabana.labs.redhat.com> <3820D91A.7AC62B8C@ceronet.com>


> I don't have any benchmarks, but with the same SVGA-Server in 16 bits and
> 800x600, KDE draws the windows a lot faster than GNOME or
> GTK applications do. (The same is true for the Banshee server, as I have
> seen it...)
> What I mean is that if it's possible than the redrawing of GTK
> applications is slower by a factor of design of the API? Does anybody
> knows something? Can it be solved?

Wonder what exactly your test for performance is.

Popping up a window takes pretty much the same speed as raw Xlib.

Miguel

From rodrigc@mediaone.net  Thu May 11 17:52:43 2000
Received: (qmail 5280 invoked from network); 7 Nov 1999 04:29:19 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 7 Nov 1999 04:29:19 -0000
Received: from dibbler.ne.mediaone.net (root@dibbler.ne.mediaone.net [24.218.56.16])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id XAA17058
	for <gtk-devel-list@redhat.com>; Sat, 6 Nov 1999 23:29:18 -0500
Received: (from rodrigc@localhost)
	by dibbler.ne.mediaone.net (8.9.3/8.9.3) id XAA01206
	for gtk-devel-list@redhat.com; Sat, 6 Nov 1999 23:33:49 -0500
Date: Sat, 6 Nov 1999 23:33:49 -0500
From: Craig Rodrigues <rodrigc@mediaone.net>
To: gtk-devel-list@redhat.com
Subject: Question about Makefile templates for gtk
Message-ID: <19991106233349.B1155@mediaone.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i

Hello,

For gtk 1.2.6,
I have encountered a bug in the template Makefile for
building libgtk.  Under AIX, when libgtk was built,
it was not being linked against libgdk.  So, when
gdk_check_init() was called within a function in libgtk,
any binary linked against libgtk would crash.

So basically, gtk was unusable under AIX.

I would like to submit a patch, but I would first
like to communicate with the person who maintains
the Makefile.in templates.  Is there any special
reason why libgdk was not included in the link flags
when building libgtk?

Thanks.
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

From hp@redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 14367 invoked from network); 7 Nov 1999 04:43:50 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 7 Nov 1999 04:43:50 -0000
Received: from icon.labs.redhat.com (root@icon.labs.redhat.com [207.175.42.144])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id XAA23689
	for <gtk-devel-list@redhat.com>; Sat, 6 Nov 1999 23:43:50 -0500
Received: from localhost (hp@localhost)
	by icon.labs.redhat.com (8.9.3/8.9.3) with ESMTP id XAA19782
	for <gtk-devel-list@redhat.com>; Sat, 6 Nov 1999 23:33:00 -0500
X-Authentication-Warning: icon.labs.redhat.com: hp owned process doing -bs
Date: Sat, 6 Nov 1999 23:33:00 -0500 (EST)
From: Havoc Pennington <hp@redhat.com>
X-Sender: hp@icon.labs.redhat.com
To: gtk-devel-list@redhat.com
Subject: Re: Question about Makefile templates for gtk
In-Reply-To: <19991106233349.B1155@mediaone.net>
Message-ID: <Pine.LNX.4.10.9911062331450.19546-100000@icon.labs.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


On Sat, 6 Nov 1999, Craig Rodrigues wrote:
> 
> I would like to submit a patch, but I would first
> like to communicate with the person who maintains
> the Makefile.in templates.  Is there any special
> reason why libgdk was not included in the link flags
> when building libgtk?
> 

Makefile.in is autogenerated from Makefile.am, then Makefile is generated
from Makefile.in. If gdk wasn't linked it would have to be a bug in one of
the build tools, maybe libtool or automake; gdk is specified in
Makefile.am.

Havoc


From rodrigc@mediaone.net  Thu May 11 17:52:43 2000
Received: (qmail 5227 invoked from network); 7 Nov 1999 05:28:14 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 7 Nov 1999 05:28:14 -0000
Received: from dibbler.ne.mediaone.net (root@dibbler.ne.mediaone.net [24.218.56.16])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id AAA11264
	for <gtk-devel-list@redhat.com>; Sun, 7 Nov 1999 00:28:12 -0500
Received: (from rodrigc@localhost)
	by dibbler.ne.mediaone.net (8.9.3/8.9.3) id AAA01698
	for gtk-devel-list@redhat.com; Sun, 7 Nov 1999 00:32:43 -0500
Date: Sun, 7 Nov 1999 00:32:43 -0500
From: Craig Rodrigues <rodrigc@mediaone.net>
To: gtk-devel-list@redhat.com
Subject: Re: Question about Makefile templates for gtk
Message-ID: <19991107003243.A1667@mediaone.net>
References: <19991106233349.B1155@mediaone.net> <Pine.LNX.4.10.9911062331450.19546-100000@icon.labs.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <Pine.LNX.4.10.9911062331450.19546-100000@icon.labs.redhat.com>; from hp@redhat.com on Sat, Nov 06, 1999 at 11:33:00PM -0500

On Sat, Nov 06, 1999 at 11:33:00PM -0500, Havoc Pennington wrote:
> 
> Makefile.in is autogenerated from Makefile.am, then Makefile is generated
> from Makefile.in. If gdk wasn't linked it would have to be a bug in one of
> the build tools, maybe libtool or automake; gdk is specified in
> Makefile.am.
> 
> Havoc

I'm not so sure.
Take a look at Makefile.am in the gtk subdirectory:

libgtk_la_LDFLAGS = @STRIP_BEGIN@ \
        -version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)    \
        -release $(LT_RELEASE)                                  \
        -export-dynamic                                         \
        @GLIB_DEPLIBS@                                          \
        @x_ldflags@                                             \
        @x_libs@                                                \
        -lm                                                     \
@STRIP_END@
#       $(top_builddir)/gdk/libgdk.la                              
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Why is this line commented out?  I think this is what caused me loads of
grief.

I have a related question regarding the configure.in file in the glib
subdirectory, lines 796-807:

                if test "$ac_cv_func_getpwuid_r" = "yes"; then
                        AC_MSG_CHECKING(whether getpwuid_r is posix like)
                        # getpwuid_r(0, NULL, NULL, 0) is the signature on
                        # solaris, if that is not found, the prog below won't
                        # compile, then the posix signature is assumed as
                        # the default.
                        AC_TRY_COMPILE([#include <pwd.h>],
                                [getpwuid_r(0, NULL, NULL, 0);],
                                [AC_MSG_RESULT(no)],
                                [AC_MSG_RESULT(yes)
                                AC_DEFINE(HAVE_GETPWUID_R_POSIX)])
                fi                                                   


The AIX xlc compiler has a brain-dead behavior, where
if it finds a function with an incorrect number of arguments,
it will flag it as an error, will still return an errno of 0.

eg. "conftest.c", line 4.14: 1506-098 (E) Missing argument(s). 

Under AIX 4.3, the prototype for getpwuid_r() is the POSIX one.  But
when xlc compiles the non-POSIX prototype, getpwuid_r(0, NULL, NULL, 0),
it says: "Missing argument(s)", but still accepts the non-POSIX prototype.
The binary will then build, and then every subsequent call to the
libglib will coredump!

Can the above test be changed to check for the POSIX prototype?
That would be:  
int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **);

If the test fails, then default to getpwuid_r(0, NULL, NULL, 0).

I have no experience with automake, so I could use some assistance.
I have been spending hours tracking these bugs down on AIX............

Thanks.

-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

From leon@lota.izhcom.ru  Thu May 11 17:52:43 2000
Received: (qmail 7819 invoked from network); 7 Nov 1999 12:36:18 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 7 Nov 1999 12:36:18 -0000
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id HAA22678
	for <gtk-devel-list@redhat.com>; Sun, 7 Nov 1999 07:36:16 -0500
From: leon@udmnet.ru
Received: from udmnet.ru (A178.dialup.udm.net [213.24.0.178])
	by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id QAA92105
	for <gtk-devel-list@redhat.com>; Sun, 7 Nov 1999 16:41:27 +0400 (SAMT)
Sender: leon@lota.izhcom.ru
Message-ID: <382571D4.72FF94B8@udmnet.ru>
Date: Sun, 07 Nov 1999 16:34:28 +0400
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: CList glitch
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

I'm developing a small application (it's a dictionary for translating
words from one language to another) and discovered a problem with 
CList widget. It's *very* slow on big list of words. When I fill it
with some thousand words, it is fast (it takes only a fraction of
a second to fill), but when I fill it with contents of the entire
dictionary (50 thousand words approx.) it takes some minutes to fill.
Seems there is a design flaw somewhere in memory management system,
isn't it? The problem was discovered with gtk 1.2.3 and exists in 1.2.6.
Can something be done about that? I want user to be able to view all
dictionary at once, and now seems it can't be done. 

Leon.

From rodrigc@mediaone.net  Thu May 11 17:52:43 2000
Received: (qmail 6754 invoked from network); 7 Nov 1999 19:34:57 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 7 Nov 1999 19:34:57 -0000
Received: from dibbler.ne.mediaone.net (root@dibbler.ne.mediaone.net [24.218.56.16])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA07258
	for <gtk-devel-list@redhat.com>; Sun, 7 Nov 1999 14:34:56 -0500
Received: (from rodrigc@localhost)
	by dibbler.ne.mediaone.net (8.9.3/8.9.3) id OAA00773;
	Sun, 7 Nov 1999 14:39:22 -0500
Date: Sun, 7 Nov 1999 14:39:22 -0500
From: Craig Rodrigues <rodrigc@mediaone.net>
To: gtk-devel-list@redhat.com
Cc: Valdis.Kletnieks@vt.edu
Subject: Patch for configure.in in glib
Message-ID: <19991107143922.A759@mediaone.net>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="Kj7319i9nmIyA2yE"
X-Mailer: Mutt 1.0i


--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii

Hi,

This patch cleans up the test for POSIX getpwuid_r().
Under AIX, the test wasn't executing properly, so the
wrong version of getpwuid_r() was being used, and the glib
library would coredump.

-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

--Kj7319i9nmIyA2yE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="glib-configure.in.patch"

*** configure.in.old	Thu Oct  7 17:27:43 1999
--- configure.in	Sun Nov  7 19:34:36 1999
***************
*** 795,809 ****
  		fi
  		if test "$ac_cv_func_getpwuid_r" = "yes"; then
  			AC_MSG_CHECKING(whether getpwuid_r is posix like)
! 			# getpwuid_r(0, NULL, NULL, 0) is the signature on
! 			# solaris, if that is not found, the prog below won't 
! 			# compile, then the posix signature is assumed as 
! 			# the default.
! 			AC_TRY_COMPILE([#include <pwd.h>],
! 				[getpwuid_r(0, NULL, NULL, 0);],
! 				[AC_MSG_RESULT(no)],
! 				[AC_MSG_RESULT(yes)
! 				AC_DEFINE(HAVE_GETPWUID_R_POSIX)])
  		fi
  	fi
  	if test x"$have_threads" = xposix; then
--- 795,809 ----
  		fi
  		if test "$ac_cv_func_getpwuid_r" = "yes"; then
  			AC_MSG_CHECKING(whether getpwuid_r is posix like)
! 			# The signature for the POSIX version is:
! 			# int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)
! 			AC_TRY_COMPILE([#include <pwd.h>
!                                         #include <sys/types.h>
!                                         #include <stdlib.h>],
! 				[getpwuid_r((uid_t)0, NULL, NULL, (size_t)0, NULL);],
! 				[AC_DEFINE(HAVE_GETPWUID_R_POSIX)
! 				AC_MSG_RESULT(yes)],
! 				[AC_MSG_RESULT(no)])
  		fi
  	fi
  	if test x"$have_threads" = xposix; then

--Kj7319i9nmIyA2yE--

From wilhelmi@ira.uka.de  Thu May 11 17:52:43 2000
Received: (qmail 7107 invoked from network); 8 Nov 1999 09:39:22 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 09:39:22 -0000
Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id EAA18623
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 04:39:21 -0500
Received: from i80fs2.ira.uka.de [129.13.18.2] by iraun1 with SMTP (PP) local;
          Mon, 8 Nov 1999 10:39:10 +0100
Received: from ira.uka.de [129.13.18.174] (actually i81pc4) by i8fs1 
          with SMTP (PP); Mon, 8 Nov 1999 10:39:08 +0100
Sender: wilhelmi@ira.uka.de
Message-ID: <38269A3B.32055C2B@ira.uka.de>
Date: Mon, 08 Nov 1999 09:39:07 +0000
From: Sebastian Wilhelmi <wilhelmi@ira.uka.de>
Organization: IRF Uni Karlsruhe
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.10 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
CC: Craig Rodrigues <rodrigc@mediaone.net>
Subject: Re: Patch for configure.in in glib
References: <19991107143922.A759@mediaone.net>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, Craig =


> This patch cleans up the test for POSIX getpwuid_r().
> Under AIX, the test wasn't executing properly, so the
> wrong version of getpwuid_r() was being used, and the glib
> library would coredump.

Ok, I checked that patch in.

Still I think, that xlc_r is broken, because it wouldn't notice, if AIX h=
adn't
a POSIX version of getpwuid_r even with your test (or am I missing someth=
ing
here?)

Bye,
Sebastian
-- =

Sebastian Wilhelmi                   |            h=E4r ovanf=F6r alla mo=
lnen
mailto:wilhelmi@ira.uka.de           |     =E4r himmlen s=E5 f=F6runderli=
gt bl=E5
http://goethe.ira.uka.de/~wilhelmi   |

From J.A.K.Mouw@its.tudelft.nl  Thu May 11 17:52:43 2000
Received: (qmail 16639 invoked from network); 8 Nov 1999 10:28:04 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 10:28:04 -0000
Received: from duteinh.et.tudelft.nl (duteinh.et.tudelft.nl [130.161.42.1])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id FAA23730
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 05:28:03 -0500
Received: from dutein71 (dutein71.et.tudelft.nl) by duteinh.et.tudelft.nl (4.1/BB-2.0)
	id AA15651; Mon, 8 Nov 99 11:27:56 +0100
Date: Mon, 8 Nov 99 11:27:56 +0100
Message-Id: <9911081027.AA15651@duteinh.et.tudelft.nl>
From: Erik Mouw <J.A.K.Mouw@its.tudelft.nl>
To: gtk-devel-list@redhat.com
Subject: Re: Question about Makefile templates for gtk
In-Reply-To: <Pine.LNX.4.10.9911062331450.19546-100000@icon.labs.redhat.com>
Organization: Eric conspiracy secret labs
X-Face: "!Z|1XjFg!3Iw)BwM^M\k)J5KHiPddz}#/Zw%?$&Q!xqob"OA|})3_@&BTTiQERo?/^g[Z<9P4R8:5C:aqq.cw!hotLc=+u-"+1rq@9$V^8PbOUlodyi_sejt+D`iqkLpx$>.aXl%vnfPIt"LK|/%>94_Zrm8jy?`_[RKt'TuoxUxfk(gMhY(n|DBBl~c$dhO>G%6}R4+DGX3|idBm4oU&UM/XUP4I9aoN{]`ax%B?rgD(I3OJ<62Y6L
X-Mailer: XCmail 0.99.6 - with PGP support, PGP engine version 0.5
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
X-Eric-Conspiracy: There is no conspiracy!
X-Loop: erik@it.et.tudelft.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

On Sat, 06 Nov 1999 23:33:00 -0500 (EST), Havoc Pennington wrote:
> On Sat, 6 Nov 1999, Craig Rodrigues wrote:
>> I would like to submit a patch, but I would first
>> like to communicate with the person who maintains
>> the Makefile.in templates.  Is there any special
>> reason why libgdk was not included in the link flags
>> when building libgtk?
>> 
> 
> Makefile.in is autogenerated from Makefile.am, then Makefile is generated
> from Makefile.in. If gdk wasn't linked it would have to be a bug in one of
> the build tools, maybe libtool or automake; gdk is specified in
> Makefile.am.

No, it is not a bug in the build tools. It (usually) makes no sense to
link with other libraries when you build a library. The linker won't
include the other libraries anyway.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2785859  Fax: +31-15-2781843  Email J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/


From David.Odin@bigfoot.com  Thu May 11 17:52:43 2000
Received: (qmail 22356 invoked from network); 8 Nov 1999 11:45:54 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 11:45:54 -0000
Received: from front7.grolier.fr (front7.grolier.fr [194.158.96.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id GAA28691
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 06:45:53 -0500
Received: from coruscant.ddx.fr (Lyon-1-53.club-internet.fr [195.36.209.53])
	by front7.grolier.fr (8.9.3/No_Relay+No_Spam_MGC990224) with ESMTP id MAA00540;
	Mon, 8 Nov 1999 12:45:32 +0100 (MET)
Received: (from dindinx@localhost)
	by coruscant.ddx.fr (8.8.8/8.8.8) id MAA04767;
	Mon, 8 Nov 1999 12:44:36 +0100
Date: Mon, 8 Nov 1999 12:44:35 +0100
From: David Odin <David.Odin@bigfoot.com>
To: gtk-devel-list@redhat.com, Nathan Froyd <maestrox@geocities.com>,
        Tony Gale <gale@gimp.org>, Emmanuel Deloget <logout@free.fr>,
        "Shawn T . Amundson" <amundson@gimp.org>
Subject: Translation of the GTK-FAQ.
Message-ID: <19991108124435.A4699@bigfoot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.95.6us


    Hi,

  I'm writing a book about GTK+ in french. I wanted to add a FAQ in the
last part of the book. This book is going to be sold by Eyrolles and is
*not* open-source. It's a normal book.

  I was wondering if I'm allowed to translate the GTK-FAQ to put it in my book.
I guess I'll have to credit the authors of the original FAQ.
  
Of course, if I'm allowed to include a translation of it in my book, I'll
send the translation back to you so french speaking people can have a FAQ.

           Best REgards,

                  DindinX

-- 
David.Odin@bigfoot.com

Welcome to Utah.
If you think our liquor laws are funny, you should see our underwear!

From rodrigc@mediaone.net  Thu May 11 17:52:43 2000
Received: (qmail 27869 invoked from network); 8 Nov 1999 14:29:13 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 14:29:13 -0000
Received: from dibbler.ne.mediaone.net (root@dibbler.ne.mediaone.net [24.218.56.16])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id JAA08957
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 09:29:13 -0500
Received: (from rodrigc@localhost)
	by dibbler.ne.mediaone.net (8.9.3/8.9.3) id JAA11064
	for gtk-devel-list@redhat.com; Mon, 8 Nov 1999 09:33:42 -0500
Date: Mon, 8 Nov 1999 09:33:42 -0500
From: Craig Rodrigues <rodrigc@mediaone.net>
To: gtk-devel-list@redhat.com
Subject: Re: Patch for configure.in in glib
Message-ID: <19991108093342.B11034@mediaone.net>
References: <19991107143922.A759@mediaone.net> <38269A3B.32055C2B@ira.uka.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <38269A3B.32055C2B@ira.uka.de>; from wilhelmi@ira.uka.de on Mon, Nov 08, 1999 at 09:39:07AM +0000

On Mon, Nov 08, 1999 at 09:39:07AM +0000, Sebastian Wilhelmi wrote:
> Hi, Craig 
> 
> > This patch cleans up the test for POSIX getpwuid_r().
> > Under AIX, the test wasn't executing properly, so the
> > wrong version of getpwuid_r() was being used, and the glib
> > library would coredump.
> 
> Ok, I checked that patch in.
> 
> Still I think, that xlc_r is broken, because it wouldn't notice, if AIX hadn't
> a POSIX version of getpwuid_r even with your test (or am I missing something
> here?)

No, you're not missing anything.  If xlc_r wasn't brain-dead, the test
would be fine.  It doesn't seem to return an error code if it finds
a C funtion with an incorrect number of arguments.  (However, the C++
compiler, xlC_r, does return an error).

The change I submitted works under Solaris and Linux as well as AIX,
things will be OK.  I *really* hate finding bugs in compilers. :) 
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

From rodrigc@mediaone.net  Thu May 11 17:52:43 2000
Received: (qmail 5226 invoked from network); 8 Nov 1999 14:43:51 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 14:43:50 -0000
Received: from dibbler.ne.mediaone.net (root@dibbler.ne.mediaone.net [24.218.56.16])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id JAA10093
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 09:43:50 -0500
Received: (from rodrigc@localhost)
	by dibbler.ne.mediaone.net (8.9.3/8.9.3) id JAA11102
	for gtk-devel-list@redhat.com; Mon, 8 Nov 1999 09:48:19 -0500
Date: Mon, 8 Nov 1999 09:48:19 -0500
From: Craig Rodrigues <rodrigc@mediaone.net>
To: gtk-devel-list@redhat.com
Subject: Re: Question about Makefile templates for gtk
Message-ID: <19991108094819.C11034@mediaone.net>
References: <Pine.LNX.4.10.9911062331450.19546-100000@icon.labs.redhat.com> <9911081027.AA15651@duteinh.et.tudelft.nl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <9911081027.AA15651@duteinh.et.tudelft.nl>; from J.A.K.Mouw@its.tudelft.nl on Mon, Nov 08, 1999 at 11:27:56AM +0100

On Mon, Nov 08, 1999 at 11:27:56AM +0100, Erik Mouw wrote:
> > Makefile.in is autogenerated from Makefile.am, then Makefile is generated
> > from Makefile.in. If gdk wasn't linked it would have to be a bug in one of
> > the build tools, maybe libtool or automake; gdk is specified in
> > Makefile.am.
> 
> No, it is not a bug in the build tools. It (usually) makes no sense to
> link with other libraries when you build a library. The linker won't
> include the other libraries anyway.

Well, when you build libgtk, you ARE linking in other libraries:
libgmodule, libglib, libXll, libXext, and libm.  The Makefile
currently comments out the libtool flag to link in libgdk:

#$(top_builddir)/gdk/libgdk.la

I tried uncommenting the line out, and when I tried to rebuild,
I got the error:
libtool: link: error: cannot link shared libraries into libtool libraries

I looked in libtool and found:

      link_against_libtool_libs=

      # How the heck are we supposed to write a wrapper for a shared library?
      if test -n "$link_against_libtool_libs"; then
         $echo "$modename: error: cannot link shared libraries into libtool libraries" 1>&2
         exit 1
      fi

So as Joel Becker pointed out, this looks like a libtool problem.

Joel, can you forward me your copy of libtool which can do this?

-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

From J.A.K.Mouw@its.tudelft.nl  Thu May 11 17:52:43 2000
Received: (qmail 19035 invoked from network); 8 Nov 1999 15:02:58 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 15:02:58 -0000
Received: from duteinh.et.tudelft.nl (duteinh.et.tudelft.nl [130.161.42.1])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id KAA11534
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 10:02:57 -0500
Received: from dutein71 (dutein71.et.tudelft.nl) by duteinh.et.tudelft.nl (4.1/BB-2.0)
	id AA17489; Mon, 8 Nov 99 16:02:56 +0100
Date: Mon, 8 Nov 99 16:02:56 +0100
Message-Id: <9911081502.AA17489@duteinh.et.tudelft.nl>
From: Erik Mouw <J.A.K.Mouw@its.tudelft.nl>
To: gtk-devel-list@redhat.com
Subject: Re: Question about Makefile templates for gtk
In-Reply-To: <19991108094819.C11034@mediaone.net>
Organization: Eric conspiracy secret labs
X-Face: "!Z|1XjFg!3Iw)BwM^M\k)J5KHiPddz}#/Zw%?$&Q!xqob"OA|})3_@&BTTiQERo?/^g[Z<9P4R8:5C:aqq.cw!hotLc=+u-"+1rq@9$V^8PbOUlodyi_sejt+D`iqkLpx$>.aXl%vnfPIt"LK|/%>94_Zrm8jy?`_[RKt'TuoxUxfk(gMhY(n|DBBl~c$dhO>G%6}R4+DGX3|idBm4oU&UM/XUP4I9aoN{]`ax%B?rgD(I3OJ<62Y6L
X-Mailer: XCmail 0.99.6 - with PGP support, PGP engine version 0.5
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
X-Eric-Conspiracy: There is no conspiracy!
X-Loop: erik@it.et.tudelft.nl
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

On Mon, 08 Nov 1999 09:48:19 -0500, Craig Rodrigues wrote:
> On Mon, Nov 08, 1999 at 11:27:56AM +0100, Erik Mouw wrote:
>> No, it is not a bug in the build tools. It (usually) makes no sense to
>> link with other libraries when you build a library. The linker won't
>> include the other libraries anyway.
> 
> Well, when you build libgtk, you ARE linking in other libraries:
> libgmodule, libglib, libXll, libXext, and libm.  The Makefile
> currently comments out the libtool flag to link in libgdk:

No, you are linking objects into a shared library. You are not linking
other shared libraries into a new shared library. In other words: libgtk
*depends* on libgdk, libglib (etc.), but it does not *link* them.
Otherwise making a separate library for gdk and glib would be useless.

> #$(top_builddir)/gdk/libgdk.la
> 
> I tried uncommenting the line out, and when I tried to rebuild,
> I got the error:
> libtool: link: error: cannot link shared libraries into libtool libraries

That's correct.

> I looked in libtool and found:
> 
>       link_against_libtool_libs=
> 
>       # How the heck are we supposed to write a wrapper for a shared library?
>       if test -n "$link_against_libtool_libs"; then
>          $echo "$modename: error: cannot link shared libraries into libtool
> libraries" 1>&2
>          exit 1
>       fi
> 
> So as Joel Becker pointed out, this looks like a libtool problem.

No, it really makes no sense. The application that *uses* libgtk is
supposed to link all the other libraries that libgtk depends on.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2785859  Fax: +31-15-2781843  Email J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/


From otaylor@redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 2228 invoked from network); 8 Nov 1999 17:04:35 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 17:04:35 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA22556
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 12:04:35 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id MAA17653;
	Mon, 8 Nov 1999 12:03:52 -0500
To: gtk-devel-list@redhat.com
Subject: Re: Question about Makefile templates for gtk
References: <9911081502.AA17489@duteinh.et.tudelft.nl>
From: Owen Taylor <otaylor@redhat.com>
Date: 08 Nov 1999 12:03:52 -0500
In-Reply-To: Erik Mouw's message of "Mon, 8 Nov 99 16:02:56 +0100"
Message-ID: <ybek8nssyo7.fsf@fresnel.labs.redhat.com>
Lines: 50
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


To hopefully cut through some of the confusion:

 - On some systems, linking one shared library against another is meaningless,
   so libtool does not do it.

 - On sane systems, linking one shared library against another means that 
   the linked against library is added as a dependency to the library
   that is being linked.

   That means, that when you load one library, the other library is automatically
   loaded.

   Adding a library to _LIBADD will cause this sort of dependency to be 
   made by libtool when possible. 

   The library being linked against must be installed on many systems.
   (I think because these systems actually put a full path to the 
   library in the dependency.) This is not necessary on other systems,
   such as ELF systems. However, libtool never allows you to link one 
   library against another uninstalled library.

 - AIX does its own peculiar thing. Shared libraries on AIX are
   different from on any other system known to man.

   The details were explained to me at one point, but I no longer
   remember them. Basically, though, AIX really wants to actually
   link against all the symbols in the shared library when the 
   shared library is created.

   At least later versions of AIX have a compiler flag to
   allow undefined symbols when building a shared library.
   I presume that this flag does not result in a completely
   broken library if undefined symbols are encountered - 
   it would seem to be pointless.

   This flag was added to libtool; I presume with some testing.

So, though I don't claim to understand everything that is going on,
that's a rough outline.

We can't simply link against gdk in the gtk/ Makefile.am because
libtool will barf on it since that library isn't installed.

We can possibly do magic in an automake conditional - though
I have a bad feeling that the different versions of AIX are
somewhat different in how this all works.

Regards,
                                        Owen

From logout@free.fr  Thu May 11 17:52:43 2000
Received: (qmail 14229 invoked from network); 8 Nov 1999 17:20:30 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 17:20:30 -0000
Received: from smtp3.free.fr (root@smtp3.free.fr [212.27.32.72])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA23754
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 12:20:29 -0500
Received: from dks12 (marseille1-55-209.dial.proxad.net [212.27.55.209])
	by smtp3.free.fr (8.9.3/8.9.3/Debian/GNU) with SMTP id SAA20199
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 18:20:27 +0100
Message-ID: <002901bf2a0e$30d04ed0$d1371bd4@dks12>
From: "Emmanuel DELOGET" <logout@free.fr>
To: <gtk-devel-list@redhat.com>
References: <382571D4.72FF94B8@udmnet.ru>
Subject: Re: CList glitch (some kind o off-topic response)
Date: Mon, 8 Nov 1999 18:25:01 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

> Hi!
>
> I'm developing a small application (it's a dictionary for translating
> words from one language to another) and discovered a problem with
> CList widget. It's *very* slow on big list of words. When I fill it
> with some thousand words, it is fast (it takes only a fraction of
> a second to fill), but when I fill it with contents of the entire
> dictionary (50 thousand words approx.) it takes some minutes to fill.
> Seems there is a design flaw somewhere in memory management system,
> isn't it? The problem was discovered with gtk 1.2.3 and exists in 1.2.6.
> Can something be done about that? I want user to be able to view all
> dictionary at once, and now seems it can't be done.
>
> Leon.
>

    Hi Leon,

    I don't think it is a very good idea to use a list widgetto display more
    than a few hundreds of line. There should be some reasons for that :

        * user may have to scroll during four hours to find the thing he
wants
        * if the entry are sorted, finding stuff is easier but the insertion
of
        items is very slow (something like O(n^2) if I remember the last
        discussion about GList sorting here). That's probably why your
        application is so slow when you use 50000 words (up to
        2 500 000 000 operations ! whow !)

    A better solution should be to use some kind of pre-sorting (A, B, C,
...
    should do it well, since it will reduce most of your list to handle
something
    like 2000/3000 words - that's really a big list :)

    Hope it helps,

    Emmanuel


From leon@lota.izhcom.ru  Thu May 11 17:52:43 2000
Received: (qmail 29395 invoked from network); 8 Nov 1999 19:28:51 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 19:28:51 -0000
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA05165
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 14:28:49 -0500
From: leon@udmnet.ru
Received: from udmnet.ru (U125.dialup.udm.net [192.168.53.125])
	by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id XAA22786
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 23:34:16 +0400 (SAMT)
Sender: leon@lota.izhcom.ru
Message-ID: <38271EC7.E5AE18F@udmnet.ru>
Date: Mon, 08 Nov 1999 23:04:39 +0400
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: CList glitch (some kind o off-topic response)
References: <382571D4.72FF94B8@udmnet.ru> <002901bf2a0e$30d04ed0$d1371bd4@dks12>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Emmanuel DELOGET wrote:

> 
>     I don't think it is a very good idea to use a list widgetto display more
>     than a few hundreds of line. There should be some reasons for that :
> 
>         * user may have to scroll during four hours to find the thing he
> wants

Oh, that's not a problem because list is sorted and I nailed it 
into scrolled window. So no problem finding needed word.

>         * if the entry are sorted, finding stuff is easier but the insertion
> of
>         items is very slow (something like O(n^2) if I remember the last
>         discussion about GList sorting here). That's probably why your
>         application is so slow when you use 50000 words (up to
>         2 500 000 000 operations ! whow !)
> 

I'm just wondering why I see only two kinds of speeds of 
filling the list: fast and very slow, with no intermediate. 
There are no fillings which are some seconds long.

BTW, if I *prepend*, not *append* to the list, will it reduce the time
to O(n)? Is it possible?


-- 
Leon. 

### Born in USSR ###

From sandmann@daimi.au.dk  Thu May 11 17:52:43 2000
Received: (qmail 31923 invoked from network); 8 Nov 1999 20:00:43 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 20:00:43 -0000
Received: from humulus.daimi.au.dk (humulus.daimi.au.dk [130.225.16.6])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id PAA08433
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 15:00:42 -0500
Received: (from sandmann@localhost)
	by humulus.daimi.au.dk (8.9.3/8.9.3) id VAA27607;
	Mon, 8 Nov 1999 21:00:32 +0100 (MET)
Sender: sandmann@daimi.au.dk
To: gtk-devel-list@redhat.com
Subject: Re: CList glitch (some kind o off-topic response)
References: <382571D4.72FF94B8@udmnet.ru> <002901bf2a0e$30d04ed0$d1371bd4@dks12> <38271EC7.E5AE18F@udmnet.ru>
From: Soeren Sandmann <sandmann@daimi.au.dk>
Date: 08 Nov 1999 21:00:32 +0100
In-Reply-To: leon@udmnet.ru's message of "Mon, 08 Nov 1999 23:04:39 +0400"
Message-ID: <ye8bt94kb33.fsf@humulus.daimi.au.dk>
Lines: 14
User-Agent: Gnus/5.070097 (Pterodactyl Gnus v0.97) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

leon@udmnet.ru writes:

> BTW, if I *prepend*, not *append* to the list, will it reduce the time
> to O(n)? Is it possible?

Yes, prepending is much faster. GLib does not keep track of the tail
of lists, so appending an item will be an O(n) operation, making
appending n items an O(n^2) operation.

Prepending is O(1), so prepending n items will be O(n).

In my opinion it is a mistake that GLib doesn't keep track of tails.
I don't think it is possible to fix it, though, since lists are not
opaque and a lot of code depends on the structure of list items.

From redhog@mini.dhs.org  Thu May 11 17:52:43 2000
Received: (qmail 26470 invoked from network); 8 Nov 1999 20:21:25 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 20:21:25 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id PAA11935
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 15:21:24 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id VAA10702
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 21:48:22 +0100
Date: Mon, 8 Nov 1999 21:48:17 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: Re: CList glitch (some kind o off-topic response)
In-Reply-To: <ye8bt94kb33.fsf@humulus.daimi.au.dk>
Message-ID: <Pine.LNX.4.10.9911082146320.1224-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

WHy not implement a new list structure that supports that (e.g. double
linked lists, but that would perheaps be too much overhead? Simply
storing the adress of the last item would make appending O(1), while not
adding no more than O(1) memory overhead), and use it for Clist?

<A Href="http://www.tekmetrics.com/transcript.shtml?pid=29943">TekMetrics Online Public Transcript (e-certifications[tm])</A><Br>
<A Href="http://mini.dhs.org/PGP%20Public%20key.asc">PGP Public key</A><Br>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4JzcVHeQ6HSAJlUwRAnA0AJwLvOOwXYvk/fD9oeIJoM6ZV6tg2wCgsoS2
cJJfG2ttPrkc8LWJ35S6njI=
=0ogL
-----END PGP SIGNATURE-----

From federico@redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 1610 invoked from network); 8 Nov 1999 20:27:49 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 20:27:49 -0000
Received: from guanabana.labs.redhat.com (root@guanabana.labs.redhat.com [207.175.42.58])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id PAA12984
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 15:27:48 -0500
Received: (from federico@localhost)
	by guanabana.labs.redhat.com (8.9.3/8.9.3) id PAA01549;
	Mon, 8 Nov 1999 15:28:36 -0500
Date: Mon, 8 Nov 1999 15:28:36 -0500
Message-Id: <199911082028.PAA01549@guanabana.labs.redhat.com>
X-Authentication-Warning: guanabana.labs.redhat.com: federico set sender to federico@redhat.com using -f
From: Federico Mena Quintero <federico@redhat.com>
To: gtk-devel-list@redhat.com
In-reply-to: <ye8bt94kb33.fsf@humulus.daimi.au.dk> (message from Soeren
	Sandmann on 08 Nov 1999 21:00:32 +0100)
Subject: Re: CList glitch (some kind o off-topic response)
X-asperating: a recalcitrant window system
References: <382571D4.72FF94B8@udmnet.ru> <002901bf2a0e$30d04ed0$d1371bd4@dks12> <38271EC7.E5AE18F@udmnet.ru> <ye8bt94kb33.fsf@humulus.daimi.au.dk>

>  In my opinion it is a mistake that GLib doesn't keep track of tails.
>  I don't think it is possible to fix it, though, since lists are not
>  opaque and a lot of code depends on the structure of list items.

The standard idiom here is to keep track of the end of the list
yourself if you need a constant time append operation.  This is what
GtkCList does.

  Federico

From otaylor@redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 16866 invoked from network); 8 Nov 1999 20:45:40 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 20:45:40 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id PAA14573
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 15:45:40 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id PAA18964;
	Mon, 8 Nov 1999 15:44:56 -0500
To: gtk-devel-list@redhat.com
Subject: The great move to gdk/x11/ 
From: Owen Taylor <otaylor@redhat.com>
Date: 08 Nov 1999 15:44:56 -0500
Message-ID: <ybezowor9vb.fsf@fresnel.labs.redhat.com>
Lines: 164
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


OK, I made an initial commit of moving all the X-specific code
in GDK into the x11/ subdirectory.

I decided against going with include files in favor of simply
using simply using separate object files for the windowing-system
indepedent and dependent parts of each module.

To avoid having duplicate file names (making working with emacs,
etc, easier) I used the naming convention:

 gdk/gdkfont.c
 gdk/x11/gdkfont-x11.c

Right there is some schizophrenia in the way I handled making
the various structures in GDK suitable for this move:

For some XXXPrivate structures 
(GdkCursorPrivate / GdkRegionPrivate / GdkVisualPrivate)
I moved the private structure wholesale into gdk/x11/gdkprivate-x11.h.

For other XXXPrivate structures
(GdkColormapPrivate / GdkFontPrivate / GdkImagePrivate)
I split the structure into a windowing-system-dependent part
that includes a copy of the window-system-independent part nested
inside.

Finally, for a few other structures
(GdkDrawablePrivate / GdkWindowPrivate / GdkGCPrivate)
where windowing-system-independent includes a pointer to 
an auxilliary structure which holds the windowing-system-dependent
data.

This variety corresponds partly to some indecision on my part
as to how things should be, and partly to a real variety in
the circumstances for various structures.

(Eventually, I want GdkDrawable, GdkGC, and probably GdkRegion
to be virtualized sufficiently so that a custom implementation
can be supplied at runtime.)

There will be still some changes in this stuff, but I'll be
interested in hearing from Tor and Shawn what works well for
them, and what doesn't work.

I'd also be interested in comments from anybody else brave enough
to dive into my current mess. (My feeling in checking this in
right now is somewhat akin to the feeling of having visitors without
a chance to clean up one's apartment first.)

I've appended a short module-by-module status summary below.

Regards,
                                        Owen

gdk

 Much of the contents have been moved to x11/gtkmain.c. 
 I've added a little argument-parsing abstraction.
 (Currently called gdk_arg_context_*) that allows 
 arguments from multiple places to be combined - that
 probably needs to be either fixed up and moved into
 GLib or replaced with some existing solution like
 popt.

gdkcc

 This will be removed for GTK+-1.4. Right now, it has been moved
 completely into the x11/ directory to avoid having to port it.

gdkcolor

 There are a few common utility functions, and the rest
 is in the port-specific files.

gdkcursor

 No shared code - completely port-specific.

gdkdnd

 No shared code - completely arch-specific. It's possible that some
 common code for handling GdkDragContext could exist, but the
 GdkDragContextPrivate will be different on each port.

gdkdrawable

 Pretty much done. GdkDrawable is completely virtualized.

gdkevents

 There are a few common utility functions, and the rest
 is in the port-specific files.

gdkfont

 Pretty much done for now - gdkfont.c contains a number of functions
 reimplemented as utility functions, and the rest is
 ports-specific. It will be obsoleted by pango before 1.4.

gdkgc

 GdkGC is virtualized to go along with GdkDrawable. There are
 a couple of functions I punted on for now and moved into the
 port-specific files - the clipmask functions (because gdkregion
 is not finalized) and also gdk_gc_copy, which I'm not sure
 I like enough to put into the vtable.

gdkim

 All in the port-specific directories. The abstraction here probably
 will be changed at some point to something more convenient and
 more Unicode-based.

gdkimage

 GdkImage is virtualized - all of the code except for ref/unref
 is in the port-specific files.

gdkinput

 Right now all the code is port-specific. It should be possible 
 to share the code in gdkinputnone.c, but probably not worth it; 
 I'd like to get rid of the gdk_input_vtable in X11 code - 
 it doesn't make sense since you can't switch the type of input
 on the fly.

gdkpixmap

 All moved into the port-specific file for now. The xpm loader
 should be changed to render with GdkRGB, and thus be 
 windowing-system independent, but that requires
 first making GdkRGB able to render onto any arbitrary visual.

gdkproperty

 All port-specific. Possibly should be X-specific with a higher-level
 clipboard API on top of it.

gdkregion

 Right now punted to being port-specific, but that probably needs
 to change with the virtualized drawables and GC's.

gdkrgb

 With a few changes to debugging code, it was already port-independent.

gdkselection

 Completely port specific. (In fact, really doesn't make sense
 on anything other than X; a higher-level clipboard facility
 should be provided somewhere, though.)

gdkvisual
 
 Completely port-specific. (The concepts are rather X-specific)

gdkwindow

 The window-private data is split between windowing-system independent
 parts and windowing system dependent parts. There are a few
 functions in gdk/gdkwindow.c and the rest is moved off
 into x11/gdkwindow-x11.c

From kenelson@ece.ucdavis.edu  Thu May 11 17:52:43 2000
Received: (qmail 20871 invoked from network); 8 Nov 1999 21:13:13 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 21:13:13 -0000
Received: from sequoia.ece.ucdavis.edu (root@sequoia.ece.ucdavis.edu [169.237.32.12])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA18263
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 16:13:11 -0500
Received: from sequoia.ece.ucdavis.edu (kenelson@localhost [127.0.0.1])
	by sequoia.ece.ucdavis.edu (8.9.3/8.9.3) with ESMTP id MAA04364;
	Mon, 8 Nov 1999 12:36:30 -0800 (PST)
Message-Id: <199911082036.MAA04364@sequoia.ece.ucdavis.edu>
X-Mailer: exmh version 2.0.3
X-face: 
 RinRV?cII^~g?cLc9;-D}8xnP^:6hX}*,%&@y"6p7xm^Z]V<7(`zzI!/#s%[2G'fTVC+b"*
 4eYfecJ4=,gHu4o_{Z[VG{Em*{tC^LKZ6eUDc?PI0@dk}3"kJ7*"y8*hMv\qz[C5djlU#AQh0Cq.%W
 @2kSd~S<<NcD7L4'O#`737_IEe02\s!gB6HW13]sD)'$+''!eRE7jPH\G(R&(+:Tu8bs[kr?ixX}x!
 -6`4*-B[UB_Wl!rZyL/$R(xi`vb"+t6osqR?gPX^r);Zpm'5(b/Rs[uGBN>&}]!;ZNm(wUE4=
X-url: http://www.ece.ucdavis.edu/~kenelson
To: gtk-devel-list@redhat.com
cc: kenelson@sequoia.ece.ucdavis.edu
Subject: Re: CList glitch (some kind o off-topic response) 
In-reply-to: Your message of "08 Nov 1999 21:00:32 +0100."
             <ye8bt94kb33.fsf@humulus.daimi.au.dk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 08 Nov 1999 12:36:29 -0800
From: Karl Nelson <kenelson@ece.ucdavis.edu>


I have a fully compatible implementation of glist that does track
tails.  (There does not need to be a new structure the current
system could easily have been expanded.)

It changes the glist structure to

  struct GList
    { void * data;
      GList *next,*prev,*aux
    };

Heads and tails are represented as before with NULLs in the next and
prev,  however, now the aux pointer completes the circular linked list.
All the algorithms for working through the lists still work without
modification.  

        next prev aux
Head  { NEXT, 0, PREV }
Body  { NEXT, PREV, 0 }
Tail  { 0, PREV, NEXT }

Only a handful of the functions in g_list need to be modified
to use this and as it changes none of the user code, I think
it should be the default.  g_list_first and g_list_last become
O(1) from the head and tail (but remain O(n) in general).

Unfortunately, Owen has been very clear that he does not want 
this implementation.  The glib crew wants you to track your
own tails, but as the list abstraction has no hooks to
do so you can't use the g_list methods and track the tail 
at the same time.  (This gives fits to the gtk-- wrapper which
tries to provide STL wrappers which requires and uses O(1) 
tail operations.)  You can not track the tail unless you only
use non g_list_* operations and never pass it to out to 
any other part of the system.  

Unless a large group of programmers can convince the glib 
crew otherwise, you should avoid append and never count on being able 
to cache the end.  I spent enough time and effort but failed.

--Karl

From kth@srv.net  Thu May 11 17:52:43 2000
Received: (qmail 23034 invoked from network); 8 Nov 1999 21:14:20 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 8 Nov 1999 21:14:20 -0000
Received: from srv.net (snake.srv.net [199.104.81.3])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA18389
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 16:14:18 -0500
Received: from srv.net (ras221-54.srv.net [12.7.221.54] (may be forged))
	by srv.net (8.8.7/8.8.5) with ESMTP id OAA01448
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 14:14:16 -0700 (MST)
Message-ID: <3827E5CD.E81CBE89@srv.net>
Date: Tue, 09 Nov 1999 02:13:49 -0700
From: Kevin Handy <kth@srv.net>
Organization: Software Solutions, Inc
X-Mailer: Mozilla 4.7 [en] (Win95; I)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: CList glitch (some kind o off-topic response)
References: <382571D4.72FF94B8@udmnet.ru> <002901bf2a0e$30d04ed0$d1371bd4@dks12> <38271EC7.E5AE18F@udmnet.ru> <ye8bt94kb33.fsf@humulus.daimi.au.dk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Soeren Sandmann wrote:
> 
> leon@udmnet.ru writes:
> 
> > BTW, if I *prepend*, not *append* to the list, will it reduce the time
> > to O(n)? Is it possible?
> 
> Yes, prepending is much faster. GLib does not keep track of the tail
> of lists, so appending an item will be an O(n) operation, making
> appending n items an O(n^2) operation.
> 
> Prepending is O(1), so prepending n items will be O(n).
> 
> In my opinion it is a mistake that GLib doesn't keep track of tails.
> I don't think it is possible to fix it, though, since lists are not
> opaque and a lot of code depends on the structure of list items.

Since glib scans to find the end of the list, your big loss of
speed is probibly caused by paging/(swapping). Once everything won't fit
in RAM, it starts to store stuff in the page file, and scanning through
the whole list is likely to be paging everything in/out as it moves
across
the data.

From rodrigc@mediaone.net  Thu May 11 17:52:43 2000
Received: (qmail 13274 invoked from network); 9 Nov 1999 00:07:46 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 00:07:46 -0000
Received: from dibbler.ne.mediaone.net (root@dibbler.ne.mediaone.net [24.218.56.16])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA06547
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 19:07:45 -0500
Received: (from rodrigc@localhost)
	by dibbler.ne.mediaone.net (8.9.3/8.9.3) id TAA11645
	for gtk-devel-list@redhat.com; Mon, 8 Nov 1999 19:12:08 -0500
Date: Mon, 8 Nov 1999 19:12:08 -0500
From: Craig Rodrigues <rodrigc@mediaone.net>
To: gtk-devel-list@redhat.com
Subject: Re: Question about Makefile templates for gtk
Message-ID: <19991108191208.A11632@mediaone.net>
References: <9911081502.AA17489@duteinh.et.tudelft.nl> <ybek8nssyo7.fsf@fresnel.labs.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <ybek8nssyo7.fsf@fresnel.labs.redhat.com>; from otaylor@redhat.com on Mon, Nov 08, 1999 at 12:03:52PM -0500

On Mon, Nov 08, 1999 at 12:03:52PM -0500, Owen Taylor wrote:
> 
> 
>  - AIX does its own peculiar thing. Shared libraries on AIX are
>    different from on any other system known to man.

You've got that right! :)

> 
>    The details were explained to me at one point, but I no longer
>    remember them. Basically, though, AIX really wants to actually
>    link against all the symbols in the shared library when the 
>    shared library is created.

Yes.  The problem is basically this:  If A is a program, and B
and C are shared modules:
                          ------
                         |   A  |
                          ------ 
                       /         \
                ------             ------
               |   B  |           |   C  |
                ------             ------

On AIX, if B calls a function which is in C, then the AIX linker wants you
to link C to B when you create B.

The current gtk Makefile comments out linking gdk to gtk (B to C).

>    At least later versions of AIX have a compiler flag to
>    allow undefined symbols when building a shared library.
>    I presume that this flag does not result in a completely
>    broken library if undefined symbols are encountered - 
>    it would seem to be pointless.

This flag is for AIX's ld (-berok).  It is in the current libtool.
What this flag does, is it allows the module to be built even if
some symbols are unresolved.  So it would allow B to be built without
linking it to C.

However, when you build A and link B and C, then A will dump core
under AIX when B calls a function in C.

> 
>    This flag was added to libtool; I presume with some testing.
> 
> So, though I don't claim to understand everything that is going on,
> that's a rough outline.

You've outlined it accurately.  I don't know what's going no either....
I don't consider writing linkers for operating systems my specialty. :)

What's your recommendation on what to do from here?
Fix something in the Makefile?  Fix libtool?

-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

From w.schuller@gpph.unimelb.edu.au  Thu May 11 17:52:43 2000
Received: (qmail 28329 invoked from network); 9 Nov 1999 00:14:54 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 00:14:54 -0000
Received: from crusher.buseco.monash.edu.au (crusher.buseco.monash.edu.au [130.194.172.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA07957
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 19:14:51 -0500
From: w.schuller@gpph.unimelb.edu.au
Received: from chpe (chpe.buseco.monash.edu.au [130.194.172.65])
	by crusher.buseco.monash.edu.au (8.8.7/8.8.7) with SMTP id LAA20159
	for gtk-devel-list@redhat.com; Tue, 9 Nov 1999 11:30:01 +1100
Date: Tue, 9 Nov 1999 11:30:01 +1100
Message-Id: <199911090030.LAA20159@crusher.buseco.monash.edu.au>
To: gtk-devel-list@redhat.com
Subject: Re:Re: CList glitch (some kind o off-topic response)

hi,

> Yes, prepending is much faster. GLib does not keep track of the tail
> of lists, so appending an item will be an O(n) operation, making
> appending n items an O(n^2) operation.
> 
> Prepending is O(1), so prepending n items will be O(n).

Wow, this kind of information is really useful. It would be great if this kind of info became part of the API docs, when they are finished.

ta,
wayne 

From jlbec@innerx.net  Thu May 11 17:52:43 2000
Received: (qmail 16243 invoked from network); 9 Nov 1999 00:43:16 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 00:43:16 -0000
Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA13746
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 19:43:15 -0500
Received: from rtpmail03.raleigh.ibm.com (rtpmail03.raleigh.ibm.com [9.37.172.47])
	by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA20430
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 19:43:06 -0500
Received: from lig32-226-32-77.us.lig-dial.ibm.com (jlbec@lig32-227-29-173.us.lig-dial.ibm.com [32.227.29.173])
	by rtpmail03.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id TAA28236
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 19:43:07 -0500
Received: (from jlbec@localhost) by lig32-226-32-77.us.lig-dial.ibm.com (8.8.0/8.8.0) id TAA01288 for gtk-devel-list@redhat.com; Mon, 8 Nov 1999 19:43:02 -0500
Date: Sun, 7 Nov 1999 18:59:03 -0500
From: Joel Becker <jlbec@innerx.net>
To: gtk-devel-list@redhat.com
Subject: Re: Question about Makefile templates for gtk
Message-ID: <19991107185903.A8298@vertsmile.jlb.ibm.com>
Mail-Followup-To: gtk-devel-list@redhat.com, rodrigc@mediaone.net,
	hp@redhat.com
References: <19991106233349.B1155@mediaone.net> <Pine.LNX.4.10.9911062331450.19546-100000@icon.labs.redhat.com> <19991107003243.A1667@mediaone.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <19991107003243.A1667@mediaone.net>
X-Burt-Line: Trees are cool.

On Sun, Nov 07, 1999 at 12:32:43AM -0500, Craig Rodrigues wrote:
> On Sat, Nov 06, 1999 at 11:33:00PM -0500, Havoc Pennington wrote:
> > 
> > Makefile.in is autogenerated from Makefile.am, then Makefile is generated
> > from Makefile.in. If gdk wasn't linked it would have to be a bug in one of
> > the build tools, maybe libtool or automake; gdk is specified in
> > Makefile.am.

    It is commented out in Makefile.am, just like glib is commented out
in glib/{gmodule,gthread}/Makefile.am.  This is to get around some build
issues in libtool.  Namely, libtool does not support linking aginst 
relative paths.  If you included ../gdk/libgdk.la on the gtk link line
libtool would link with "gcc -o libgtk.so.x.y $(objects) -L ../gdk/.libs
-lgdk $(OTHER LIBS)".  If you are not careful, this will hardcode
"../gdk/libs" as a library search path into libgtk.  This can be fixed
on most platforms (-rpath on solaris, -blibpath on AIX, etc), but
libtool long ago gave up trying, and instead just prints an error and
exits.
    I have a personal copy of libtool that handles this correctly.  If
you want it, I can send it to you.  It is against libtool 1.2b, because
frankly I haven't had the time to merge against the largely new 1.3
(which still gets this wrong last I checked).  All you need to do is
uncomment those pesky libgdk.la lines and off you go.

> @STRIP_END@
> #       $(top_builddir)/gdk/libgdk.la                              
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Why is this line commented out?  I think this is what caused me loads of
> grief.

    See above.

> I have a related question regarding the configure.in file in the glib

> subdirectory, lines 796-807:
> 
>                 if test "$ac_cv_func_getpwuid_r" = "yes"; then
>                         AC_MSG_CHECKING(whether getpwuid_r is posix like)
>                         # getpwuid_r(0, NULL, NULL, 0) is the signature on
>                         # solaris, if that is not found, the prog below won't
>                         # compile, then the posix signature is assumed as
>                         # the default.
>                         AC_TRY_COMPILE([#include <pwd.h>],
>                                 [getpwuid_r(0, NULL, NULL, 0);],
>                                 [AC_MSG_RESULT(no)],
>                                 [AC_MSG_RESULT(yes)
>                                 AC_DEFINE(HAVE_GETPWUID_R_POSIX)])
>                 fi                                                   
> The AIX xlc compiler has a brain-dead behavior, where
> if it finds a function with an incorrect number of arguments,
> it will flag it as an error, will still return an errno of 0.

    This is because (IIRC) it is a macro on AIX.  Yes, I agree this
should still return 1 (and if you increase the error level it will),
but it doesn't.  I've been planning to find a change that will error
on AIX, but still pass on Solaris (maybe non-NULL values?), but I've
been lazy.
    Short answer to this one is to let it fail in configure, then
edit config.h to define HAVE_GETPWUID_R_POSIX.

Joel

-- 

"Hell is other people." 
        - Jean-Paul Sartre 

                                  jlbec@evilplan.org
                                  http://ocala.cs.miami.edu/~jlbec

From jlbec@innerx.net  Thu May 11 17:52:43 2000
Received: (qmail 20511 invoked from network); 9 Nov 1999 00:45:39 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 00:45:39 -0000
Received: from fwns1.raleigh.ibm.com (fwns1d.raleigh.ibm.com [204.146.167.235])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA14338
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 19:45:32 -0500
Received: from rtpmail02.raleigh.ibm.com (rtpmail02.raleigh.ibm.com [9.37.172.48])
	by fwns1.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id TAA27970
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 19:45:17 -0500
Received: from lig32-226-32-77.us.lig-dial.ibm.com (jlbec@lig32-227-29-173.us.lig-dial.ibm.com [32.227.29.173])
	by rtpmail02.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id TAA28266
	for <gtk-devel-list@redhat.com>; Mon, 8 Nov 1999 19:45:07 -0500
Received: (from jlbec@localhost) by lig32-226-32-77.us.lig-dial.ibm.com (8.8.0/8.8.0) id TAA01320 for gtk-devel-list@redhat.com; Mon, 8 Nov 1999 19:45:04 -0500
Date: Mon, 8 Nov 1999 19:45:04 -0500
From: Joel Becker <jlbec@innerx.net>
To: gtk-devel-list@redhat.com
Subject: Re: Question about Makefile templates for gtk
Message-ID: <19991108194503.A994@vertsmile.jlb.ibm.com>
Mail-Followup-To: gtk-devel-list@redhat.com
References: <9911081502.AA17489@duteinh.et.tudelft.nl> <ybek8nssyo7.fsf@fresnel.labs.redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre2i
In-Reply-To: <ybek8nssyo7.fsf@fresnel.labs.redhat.com>
X-Burt-Line: Trees are cool.

On Mon, Nov 08, 1999 at 12:03:52PM -0500, Owen Taylor wrote:
> To hopefully cut through some of the confusion:

    And clarify where AIX is "wierd" (in the sense of not being ELF).

>  - On some systems, linking one shared library against another is meaningless,
>    so libtool does not do it.
> 
>  - On sane systems, linking one shared library against another means that 
>    the linked against library is added as a dependency to the library
>    that is being linked.

    This is what AIX does.  However, it tries to verify the symbols are
sane before it defines the dependancy.  Sometimes a definite pain, but
perfectly solvable.

>    The library being linked against must be installed on many systems.
>    (I think because these systems actually put a full path to the 
>    library in the dependency.) This is not necessary on other systems,
>    such as ELF systems. However, libtool never allows you to link one 
>    library against another uninstalled library.

    On AIX, you can specify the path, so that non-installed libraries
can be linked against.  This is what my copy of libtool does.  AFAICT,
ELF systems don't care, and I'm not sure of any system that can't really
handle this.  eg, for an AIX link, it ends up:

ld -o libgtk.so.x.y $(OBJECTS) -blibpath:/usr/lib:/lib -L ../gdk/.libs -l gdk $(OTHER LIBS)

While the linker would want to add "../gdk/.libs" to libgtk's paths, it
won't because the paths are specified by the -blibpath option.  libtool
is afraid of the former, so it doesn't try to do the latter.

>    This flag was added to libtool; I presume with some testing.

    Libtool may have the flag, but it still does the wrong thing.  It
still postpones linking libgtk until libgdk is installed (in "make
install").  It cannot therefore link testgtk, and you cannot find out if
gtk is working for you until "make install" completes (for the normal
libtool).

> We can't simply link against gdk in the gtk/ Makefile.am because
> libtool will barf on it since that library isn't installed.

    That's what it comes down to.  Should libtool barf?  IMHO no, but
until they fix it (or I find all the machines necessary to test my
fix:-) we have to go that way.  That's why I no longer advocate such
a change in the GTK build files.  I simply uncomment the libgdk.la line
whenever I build.

Joel

-- 

"Only a life lived for others is a life worth while."
							-Albert Einstein  

                                  jlbec@evilplan.org
                                  http://ocala.cs.miami.edu/~jlbec

From gale@syntax.dera.gov.uk  Thu May 11 17:52:43 2000
Received: (qmail 7036 invoked from network); 9 Nov 1999 10:10:04 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 10:10:04 -0000
Received: from syntax.dera.gov.uk (syntax.dera.gov.uk [146.80.9.50])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id FAA04181
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 05:10:02 -0500
Received: (qmail 14236 invoked from network); 9 Nov 1999 10:10:01 -0000
Received: from syntax.dera.gov.uk (146.80.9.50)
  by syntax.dera.gov.uk with SMTP; 9 Nov 1999 10:10:00 +0000
Message-ID: <XFMail.991109101000.trog@gtk.org>
X-Mailer: XFMail 1.4.0 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <19991108124435.A4699@bigfoot.com>
Date: Tue, 09 Nov 1999 10:10:00 -0000 (GMT)
Sender: gale@syntax.dera.gov.uk
From: Trog <trog@gtk.org>
To: David Odin <David.Odin@bigfoot.com>
Subject: RE: Translation of the GTK-FAQ.
Cc: "Shawn T . Amundson" <amundson@gimp.org>,
        Emmanuel Deloget <logout@free.fr>,
        Nathan Froyd <maestrox@geocities.com>, gtk-devel-list@redhat.com


The Copyright Notice at the end of the FAQ details what you need to
do when wanting to use the FAQ in published works. Basically as long
as you keep the Copyright notice, you can include the FAQ.

-tony 

On 08-Nov-99 David Odin wrote:
> 
>     Hi,
> 
>   I'm writing a book about GTK+ in french. I wanted to add a FAQ in
> the
> last part of the book. This book is going to be sold by Eyrolles
> and is
> *not* open-source. It's a normal book.
> 
>   I was wondering if I'm allowed to translate the GTK-FAQ to put it
> in my book.
> I guess I'll have to credit the authors of the original FAQ.
>   
> Of course, if I'm allowed to include a translation of it in my
> book, I'll
> send the translation back to you so french speaking people can have
> a FAQ.
> 

---
E-Mail: trog@gtk.org
Intel CPUs are not defective, they just act that way.
		-- Henry Spencer

Go Bezerk! http://www.gtk.org/~trog

From leon@lota.izhcom.ru  Thu May 11 17:52:43 2000
Received: (qmail 40 invoked from network); 9 Nov 1999 15:01:46 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 15:01:46 -0000
Received: from lota.izhcom.ru (lota.izhcom.ru [213.24.0.2])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id KAA28102
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 10:01:45 -0500
From: leon@udmnet.ru
Received: from udmnet.ru (A151.dialup.udm.net [213.24.0.151])
	by lota.izhcom.ru (8.9.3/8.9.3/Izhcom-V1.0m) with ESMTP id TAA88313
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 19:07:30 +0400 (SAMT)
Sender: leon@lota.izhcom.ru
Message-ID: <38283329.D6D2551A@udmnet.ru>
Date: Tue, 09 Nov 1999 18:43:53 +0400
Organization: Midnight greppers corp.
X-Mailer: Mozilla 4.08 [en] (X11; I; Linux 2.2.12 i686)
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: CList glitch (some kind o off-topic response)
References: <199911082036.MAA04364@sequoia.ece.ucdavis.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Karl Nelson wrote:
> 
> I have a fully compatible implementation of glist that does track
> tails.  (There does not need to be a new structure the current
> system could easily have been expanded.)
> 
> It changes the glist structure to
> 
>   struct GList
>     { void * data;
>       GList *next,*prev,*aux
>     };
> 
> Heads and tails are represented as before with NULLs in the next and
> prev,  however, now the aux pointer completes the circular linked list.
> All the algorithms for working through the lists still work without
> modification.
> 
>         next prev aux
> Head  { NEXT, 0, PREV }
> Body  { NEXT, PREV, 0 }
> Tail  { 0, PREV, NEXT }

Why simply not to link the head of the list to the tail, so making 
it circular, not linear? Have someone suggested this idea to glib 
maintainers? No structure change in list items at all. The only
(possibly) bad thing is if someone counts on NULLs in head and 
tail of list. But IMHO such programs are very few, and it is 
bad style to rely on internal representation. So I see no obstacles.

-- 
Leon. 

### Born in USSR ###

From otaylor@redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 32721 invoked from network); 9 Nov 1999 15:27:35 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 15:27:35 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id KAA31286
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 10:27:34 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id KAA26452;
	Tue, 9 Nov 1999 10:26:47 -0500
To: gtk-devel-list@redhat.com
Subject: Re: CList glitch (some kind o off-topic response)
References: <199911082036.MAA04364@sequoia.ece.ucdavis.edu> <38283329.D6D2551A@udmnet.ru>
From: Owen Taylor <otaylor@redhat.com>
Date: 09 Nov 1999 10:26:46 -0500
In-Reply-To: leon@udmnet.ru's message of "Tue, 09 Nov 1999 18:43:53 +0400"
Message-ID: <ybeogd3r8i1.fsf@fresnel.labs.redhat.com>
Lines: 58
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


leon@udmnet.ru writes:

> Karl Nelson wrote:
> > 
> > I have a fully compatible implementation of glist that does track
> > tails.  (There does not need to be a new structure the current
> > system could easily have been expanded.)
> > 
> > It changes the glist structure to
> > 
> >   struct GList
> >     { void * data;
> >       GList *next,*prev,*aux
> >     };
> > 
> > Heads and tails are represented as before with NULLs in the next and
> > prev,  however, now the aux pointer completes the circular linked list.
> > All the algorithms for working through the lists still work without
> > modification.
> > 
> >         next prev aux
> > Head  { NEXT, 0, PREV }
> > Body  { NEXT, PREV, 0 }
> > Tail  { 0, PREV, NEXT }
> 
> Why simply not to link the head of the list to the tail, so making 
> it circular, not linear? Have someone suggested this idea to glib 
> maintainers? No structure change in list items at all. The only
> (possibly) bad thing is if someone counts on NULLs in head and 
> tail of list. But IMHO such programs are very few, and it is 
> bad style to rely on internal representation. So I see no obstacles.

Any guesses to how many times code like:

 tmp_list = foo;
 while (tmp_list) 
   {
     MyStruct *x = tmpl_list->data;
     tmp_list = tmp_list->next;

      /* do something with x */
   }

Occurs within GTK+? I don't have an exact count - but its certainly
in more than 100 places; there is no way we could change GLists
to be circular without breaking massive amounts of library
and application code.

If you want a tail pointer, IMO, you should store a tail pointer
for the list.

GLib-1.3 already includes a GQueue data structure which does
this.

Regards,
                                        Owen

From kaz@FootPrints.net  Thu May 11 17:52:43 2000
Received: (qmail 15743 invoked from network); 9 Nov 1999 18:33:46 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 18:33:46 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id NAA19060
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 13:33:44 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11lG5P-0005dE-00
	for gtk-devel-list@redhat.com; Tue, 09 Nov 1999 10:33:43 -0800
Date: Tue, 9 Nov 1999 10:33:42 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
Subject: Re: CList glitch (some kind o off-topic response)
In-Reply-To: <ybeogd3r8i1.fsf@fresnel.labs.redhat.com>
Message-ID: <Pine.LNX.4.10.9911091027370.21411-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On 9 Nov 1999, Owen Taylor wrote:

> Date: 09 Nov 1999 10:26:46 -0500
> From: Owen Taylor <otaylor@redhat.com>
> Reply-To: gtk-devel-list@redhat.com
> To: gtk-devel-list@redhat.com
> Subject: Re: CList glitch (some kind o off-topic response)
> Resent-Date: 9 Nov 1999 15:27:35 -0000
> Resent-From: gtk-devel-list@redhat.com
> Resent-cc: recipient list not shown: ;
> 
> 
> leon@udmnet.ru writes:
> 
> > Karl Nelson wrote:
> > > 
> > > I have a fully compatible implementation of glist that does track
> > > tails.  (There does not need to be a new structure the current
> > > system could easily have been expanded.)
> > > 
> > > It changes the glist structure to
> > > 
> > >   struct GList
> > >     { void * data;
> > >       GList *next,*prev,*aux
> > >     };
> > > 
> > > Heads and tails are represented as before with NULLs in the next and
> > > prev,  however, now the aux pointer completes the circular linked list.
> > > All the algorithms for working through the lists still work without
> > > modification.
> > > 
> > >         next prev aux
> > > Head  { NEXT, 0, PREV }
> > > Body  { NEXT, PREV, 0 }
> > > Tail  { 0, PREV, NEXT }
> > 
> > Why simply not to link the head of the list to the tail, so making 
> > it circular, not linear? Have someone suggested this idea to glib 
> > maintainers? No structure change in list items at all. The only
> > (possibly) bad thing is if someone counts on NULLs in head and 
> > tail of list. But IMHO such programs are very few, and it is 
> > bad style to rely on internal representation. So I see no obstacles.
> 
> Any guesses to how many times code like:
> 
>  tmp_list = foo;
>  while (tmp_list) 
>    {
>      MyStruct *x = tmpl_list->data;
>      tmp_list = tmp_list->next;
> 
>       /* do something with x */
>    }
> 
> Occurs within GTK+? I don't have an exact count - but its certainly

Oops... that's why one should at the very least hide the ->next operation
behind a macro, which can produce a null pointer under the right
circumstances. The application should not know that there exists a member
called ``next'' within the list node and directly access it; it should be
``private''. That's called information hiding.

One possibility is to use an abstract list-specific nil pointer rather than
null:

	nil = list_nil(list);
	tmp = list_first(list);

	while (tmp != nil) {
	    /*...*/
	    tmp = list_next(tmp);
	}

With this interface, you iterate over any kind of list, since nothing is
revealed about its structure. Oh well, hind and lateral vision is always 20-20,
isn't it?

From kenelson@ece.ucdavis.edu  Thu May 11 17:52:43 2000
Received: (qmail 4313 invoked from network); 9 Nov 1999 18:55:13 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 18:55:13 -0000
Received: from sequoia.ece.ucdavis.edu (root@sequoia.ece.ucdavis.edu [169.237.32.12])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id NAA22023
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 13:55:11 -0500
Received: from sequoia.ece.ucdavis.edu (kenelson@localhost [127.0.0.1])
	by sequoia.ece.ucdavis.edu (8.9.3/8.9.3) with ESMTP id KAA10520;
	Tue, 9 Nov 1999 10:55:09 -0800 (PST)
Message-Id: <199911091855.KAA10520@sequoia.ece.ucdavis.edu>
X-Mailer: exmh version 2.0.3
X-face: 
 RinRV?cII^~g?cLc9;-D}8xnP^:6hX}*,%&@y"6p7xm^Z]V<7(`zzI!/#s%[2G'fTVC+b"*
 4eYfecJ4=,gHu4o_{Z[VG{Em*{tC^LKZ6eUDc?PI0@dk}3"kJ7*"y8*hMv\qz[C5djlU#AQh0Cq.%W
 @2kSd~S<<NcD7L4'O#`737_IEe02\s!gB6HW13]sD)'$+''!eRE7jPH\G(R&(+:Tu8bs[kr?ixX}x!
 -6`4*-B[UB_Wl!rZyL/$R(xi`vb"+t6osqR?gPX^r);Zpm'5(b/Rs[uGBN>&}]!;ZNm(wUE4=
X-url: http://www.ece.ucdavis.edu/~kenelson
To: gtk-devel-list@redhat.com
cc: kenelson@sequoia.ece.ucdavis.edu
Subject: Re: CList glitch (some kind o off-topic response) 
In-reply-to: Your message of "Tue, 09 Nov 1999 10:33:42 PST."
             <Pine.LNX.4.10.9911091027370.21411-100000@ashi.FootPrints.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 09 Nov 1999 10:55:08 -0800
From: Karl Nelson <kenelson@ece.ucdavis.edu>


> > > Why simply not to link the head of the list to the tail, so making 
> > > it circular, not linear? Have someone suggested this idea to glib 
> > > maintainers? No structure change in list items at all. The only
> > > (possibly) bad thing is if someone counts on NULLs in head and 
> > > tail of list. But IMHO such programs are very few, and it is 
> > > bad style to rely on internal representation. So I see no obstacles.
> > 
> > Any guesses to how many times code like:
> > 
> >  tmp_list = foo;
> >  while (tmp_list) 
> >    {
> >      MyStruct *x = tmpl_list->data;
> >      tmp_list = tmp_list->next;
> > 
> >       /* do something with x */
> >    }
> > 
> > Occurs within GTK+? I don't have an exact count - but its certainly

My problem with owens argument is that last time I checked there
was not a full set of algorithms for manipulating a gqueue like a 
glist,  thus there is no glist equivalent with O(1) tail and no
one is likely to replace uses of glist where is was used with
lots of appends in gtk+ already.  Thus is is only a token effort
to correct the problem.  

The problem I see with the whole glib structure is that often
the concept of what is the list and what is a place in the list
are confused.  It should have been designed so that the first
argument to all list operations was a pointer to a list abstraction.
This could contain head/tail as well as pointers to allocator and
interator routines.  That would have allowed abstractions of the list
rather than this transparent structure.

> Oops... that's why one should at the very least hide the ->next operation
> behind a macro, which can produce a null pointer under the right
> circumstances. The application should not know that there exists a member
> called ``next'' within the list node and directly access it; it should be
> ``private''. That's called information hiding.

Well, whether you hide it or not the information has to be somewhere.  
Glib chose not to have more that one node type for a simple list.  
This how do you store a head and tail description with just 3 void*?
If it is a circular structure and the data field is allowed to be arbitrary
you need at least one other flag to denote the head and tail element.  
Unfortunately, if you allocate a bit your will end up allocating an aligned
word.  This is why I just used another void*.  The space is going to get
allocated and you might as well make it compatible.
  
> One possibility is to use an abstract list-specific nil pointer rather than
> null:
> 
> 	nil = list_nil(list);
> 	tmp = list_first(list);
> 
> 	while (tmp != nil) {
> 	    /*...*/
> 	    tmp = list_next(tmp);
> 	}
> 
> With this interface, you iterate over any kind of list, since nothing is
> revealed about its structure. Oh well, hind and lateral vision is always 20-20,
> isn't it?

Yes, it always is.  But glib was built to be so transparent that
it can not accept new types without breaking tons of code.  Within 
the limit of not breaking old code there is very little that can 
be done.

Again, this is just the opinion of a C++ coder... 

--Karl

From federico@redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 26077 invoked from network); 9 Nov 1999 19:16:00 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 19:16:00 -0000
Received: from guanabana.labs.redhat.com (root@guanabana.labs.redhat.com [207.175.42.58])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA24307
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 14:16:00 -0500
Received: (from federico@localhost)
	by guanabana.labs.redhat.com (8.9.3/8.9.3) id OAA18182;
	Tue, 9 Nov 1999 14:16:51 -0500
Date: Tue, 9 Nov 1999 14:16:51 -0500
Message-Id: <199911091916.OAA18182@guanabana.labs.redhat.com>
X-Authentication-Warning: guanabana.labs.redhat.com: federico set sender to federico@redhat.com using -f
From: Federico Mena Quintero <federico@redhat.com>
To: gtk-devel-list@redhat.com
In-reply-to: <199911091855.KAA10520@sequoia.ece.ucdavis.edu> (message from
	Karl Nelson on Tue, 09 Nov 1999 10:55:08 -0800)
Subject: Re: CList glitch (some kind o off-topic response)
X-Indecision: is the key to Flexibility.
References:  <199911091855.KAA10520@sequoia.ece.ucdavis.edu>

>  My problem with owens argument is that last time I checked there
>  was not a full set of algorithms for manipulating a gqueue like a 
>  glist,  thus there is no glist equivalent with O(1) tail and no
>  one is likely to replace uses of glist where is was used with
>  lots of appends in gtk+ already.  Thus is is only a token effort
>  to correct the problem.

If there is a portion of code in GTK+ that creates long lists by
appending, and that code is not keeping its own tail pointer, then it
should be considered buggy for lack of performance.  It should be
fixed.

>  The problem I see with the whole glib structure is that often
>  the concept of what is the list and what is a place in the list
>  are confused.  It should have been designed so that the first
>  argument to all list operations was a pointer to a list abstraction.

Glib lists are designed to be like Lisp lists.  The STL way is not the
only way possible.

  Federico

From redhog@mini.dhs.org  Thu May 11 17:52:43 2000
Received: (qmail 1638 invoked from network); 9 Nov 1999 19:58:12 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 19:58:12 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA30375
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 14:58:11 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id VAA28759
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 21:25:06 +0100
Date: Tue, 9 Nov 1999 21:25:01 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: GBlippie version redhog.3 patch for Gtk/Gnome
Message-ID: <Pine.LNX.4.10.9911092124130.1224-201000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: MULTIPART/Mixed; BOUNDARY="-327014936-508538613-942150891=:1224"
Content-ID: <Pine.LNX.4.10.9911092124140.1224@mini.dhs.org>

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to mime@docserver.cac.washington.edu for more info.

---327014936-508538613-942150891=:1224
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-ID: <Pine.LNX.4.10.9911092124141.1224@mini.dhs.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a patch to add blippieness to Gtk/Gnome. The concept of
blippieness is described in the README (Attached), and at
http://blippie.mini.dhs.org. This patch has been uploaded to
ftp.gimp.org/incoming. I do hope it will make its way into the main
developement trunk.

<A Href="http://www.tekmetrics.com/transcript.shtml?pid=29943">TekMetrics Online Public Transcript (e-certifications[tm])</A><Br>
<A Href="http://mini.dhs.org/PGP%20Public%20key.asc">PGP Public key</A><Br>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4KIMhHeQ6HSAJlUwRAuV/AJ4rLJrGkpQkYSCk2zku0kcaQ53m4gCgmkoX
3uYd1AF28Vbo3HXM+4mfzfg=
=VDc8
-----END PGP SIGNATURE-----

---327014936-508538613-942150891=:1224
Content-Type: APPLICATION/OCTET-STREAM; NAME="GBlippie-redhog.3.tgz"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9911091334510.1224@mini.dhs.org>
Content-Description: Gtk Blippie patch version redhog.3
Content-Disposition: ATTACHMENT; FILENAME="GBlippie-redhog.3.tgz"

H4sIABwMKDgAA+0ba3PTSJKv+FcM2SrWziqOJb+AQOoCcbK5DQmVhGXvk2ts
jW0dssankRK8C3/7Pl/3PPTyM7vBbB2egtjW9HT39HseOn3te5OJx/Yffb1G
GrV2s0keEULarYb8tBvqU7ca9NRsp1Zrtpvw3bbrTuMRaX5FnpIWi4iGhDwK
mTviw2VwLBSbYGiz7dTofxh9/Fo2cA/9t2o1G3qdWru91f8mWk7/8H/MgrhH
w2q/6nqDwcPQsEGvWt9z9d9q2Ub/DadVh95mo2Y/IrWHIb+8fef6dxrUaVrO
89IhIbvyD3nLQfUec0nEiYgnEx5GpKesJGBCkN6UXDH3Zz4k5c7Q88nb//o+
Cytq8Eslx3/4U0EjHlZ9L64KdlglJzwkYx4y4gUDHo5p5PGA0B6PE+SC0MBV
WKKRJwAa+ehLSIsIxuAxM8Ckz4M+m0RkxMdsQofMUiNHUTR5sb+voapjL/Cq
7khUeTisluo2rbcB7gcv6Puxy8gOWPyd5w5ZVB3tlOz6c2o3WpbdQHEgPrK/
S26QFwVE4JuADxCMJECoIC4b0NiPJPTuvvwApF01oKv56OKo8unNL90PZ8en
nZsyulkX/KxikYv35+cWwb7Obzedi+Pu6/Ozd+/OOuRz9uF15+L68qpyUHpg
/Rf9P+Lc37z/12b83976/0aa06ROy6rXvg//r9P688X+D1UHdeyG5djtr+3/
2s2+ufvP+L+WxkO6/wr/t9tOs170/3qttvX/TTSn0XcamP9foveAxf1EaEQG
0ongbxVMAn1nfxL3pIlUSWlvb0/52hrQ30dYadKGbTWcYmTpeQGGlcLTEbDj
sx7/pEqOBpQcjmW3MAJDtNHuSBRUSCY0pGMWwTeXRlQxc5aZqheAMPsjQomI
wrgfWRijwFb1jCFApRhA8NmpahJ6hncjD9AAuigOA4NE6UpMWODiUI3TdT1J
mw+ArMEmWCBAF3EQge4SWB03k4A5AoYossSCSBkHxFdGxmzcA/eS3ciiAI5J
AH8yyosFqINogGRS8JOr/tmoW1bGg0E5mk4YRGotJNI9jT5qSb9DTKTw+0DF
/wXQ0POHDPTw/IOaoGq7iv7B/E4loaRTYzzx6VAQMsAP7PsiadvPdCpynuXt
wgtg0gPaZ2QQB31Ug0gmCZEs8vrklnvuvBw08lz4o+1KtnLKo+YOjeGxbMCj
+7FzC3oC7Aw/c33pQEWlcrCaATHid9+UAZeBRvk0w0N5Bs+6DAwnXOoCkPSp
D8m8/7GLLroOHzkZzAjifnwULXlXuobkotR4/uwZbdbqNavpOBievii7XtOe
kH34WGVKi5W4kPE56kucyhuQMkqkbAa/CbkQXjAkuxUisZDK3qHLIgqB5skr
cnr8S/fi8ubs5F/ds4uTztXZ5ZXEg+3pU4nrCVZSZ9fdn48ujs873deXv5Fy
ShaE+PmzgkkBTP/eYX/k+W4X6fVHzFUDAO+TtJrrXnXeHV11Lm46x2ZYRbPw
R8JKRooovXLGalXL4LuG/yfnR6fXGkrVh7Iw7BwnQ74k4lJQe4cqrhraGYr/
iVnMuiET3u+sCH2Q2sVihedc92+p8MeLlZ3XNdm0ulF2S9X9/uLvp/BiqFwc
oORkFqmdLAmUiQHMIR8HsGLKCm0lwysZXcInIQvjaM5KV4o9s9wry/F7h0ah
ap2nH8psn53X/u66bVGxo0T2QnUT8j6QS86+z2CVmSv7dKEGJSRUYnq5Z0bR
cBiPYWoiwUM0yAuJQ5dzAU9LOgm4blueVZTSl0QK6Lrs/Zv1k5LKzMm0V1L9
GgaiR+qLXD7rIjk0PrkWv3z9z86bG2NlFtnR6HYqxSJNm0TR1hS5PEzl3uQM
OkU2MTYzN4h4aDvzQ4zwhgH1u64nYOESIMnetIuZ3AzPeiIyey0HnABEhTxd
kdlzY40bV8hMKPsqjGQzzjdlpBAJs8OlXvLkteJDNua3bH1Tywb3opX9SQPI
kC1g3DtUMaByb+NYqo4CVEYwg5CxIhN/TW55nzHye7hgmg2l17iAXTOAng1I
CJklFAyX0CdH59cdKxs54SF4mMsCWG+zwIxCgDGP1SAMrl4gwA/VUlhR03SA
gBmUoXNz9X4ZmXQ5TlIyC0lkpjLTiQNVIsMuGvTBNziswfkgOxUNC0kSRtMQ
66ictACIRrjWN4O8SKQFz1lH73biVmuWG/YpYoHb7QHn6aSp2plI+TMDwB2g
YAyAtBcAZYzTXmAp0hq4x/p8zJIRRr+AP6Iwjg/UhpHJ4CHrx6Hwbpk/BT9N
JwwIgSdkKU8TFDkC98VdoHvm11xulUBKCy/m2aEak4Jqu3hhvojsINxpS0Ez
En2hf+S25JAPOROt5wfM9WpDfP7+iY4vCzZQ0t45OyiZohJiCW5ldb1Bd4Ar
Bx1EknB6sABMLx9UbZ6sE/O5WdIiT+ds289G6TtYUDC5MsmXj8lq5KnCAzRf
n13MFJlyBaJZf1VAkc8d65TRin1tOa8WJRY1vc+vZk8g0qBtcJDsnhdR21cL
haSPMZbISKGdJ6PsCswEiqvO9c3V2Zubyys9p8qiETeX7847v3bOV8HlQ5CB
luDJjPM8piLBST/BSaxB9/NnspqqhP5DDdlXO6XaElzORPAjBtFblmyokqn2
HXQW0osjlU6MqvoQKz3IrMwigpM7lkBKJODrd9SL9AYufAEy6V5tihY3kUOq
U4+Mz/L5vvoyfxV1oDrl9wVF8xiWhrxfxvUqHxQBlPcZDGZNlbO9tLOgpnyn
sslX6Xbr41wZpWuobOmRL5WknneUTDCG7WSf37+EIoUSKt27U+1xrjgS91pN
WPMRP8YMgRFP/viSM9686a5yMjDhNJBktljAUi/jibAydvcjJlsZbJBOkrEe
gz15aGQRn0x8SFcQfi94pq6Qe/sIlZicqiP0oaumUKlqqMtQFiZQd9zJc4YQ
S3evD6gwIfMYkiWdVqsaXJpsKos0kBaD1xU48NX1nNB+L8vZYaiKLlQF3mDa
ldsPifX8yZXZuouhNZjzGQj4zzM3Z7W2hDklZuYL9m1Fej+uNyzS++k7LQHy
DHbpAMDnRYwkAu2YFW6ex7+yOia5tfF9Q1g+dGmxPvzVh217tPD+x2hz9z+I
03Jm7n85zeb2/scm2nd1/7NV77eeWe0GXnbRmf1N5+zXznX3uHNy9P78BipD
m7x8SZyaueWyAkxSXXCeihWEis76XticLQ5sBpltzUClpVcC5VgZtsw5FDHN
QNULuDIgGahGqdWk7bb1rCl3zYhaSWOJhZJesGo358Sl4t0KFsR4NcIk80zl
VKCrJzrv0pvhbBbCCExD1BHgS/Eehbo7UXOoDRKwl9ydMLqRE/gBuPcCtmRB
BmJQhwnlzCU+dWJHVOfTOdqt4F5DrbKcQqa6lojWpJAOW0olf1RZSSxgBZV0
2Oo5FFGvKaUUdavepq1Ww2q1a6X7Xk9ISC7a/NAMLdhpkgXKKjwJlsV4kgsZ
0miX7lsVTxtzu1ebL3KS/O97vWEAsTT2Hvw1oPu9/9WC3nqjtX3/ayNtnv7l
557L+x/3vIiN//Jl4BX1H8Rrp1D/tZvt1rb+20RzHAqp0mTK/9/SzySNkm23
29S2nzUs+NM25dsHRlyO21R3NIjmHcWogzRzLag6U9fN3NzKXPZHJ6pYxcSq
ahWweShWbBuqFbtRSt86+MBSVnC8ZISB1HxW4IlGK3jKXi9ag6tvbZHbtsmW
xP+rztHx285XobFq/Q8emeT/Zgvzv1O3t+v/jTT5dtOERnj3H6LwkOLpN1bB
P+3ZVafakgfsqiCACkHAw1q1WS+VMuOo6+JmuynQqe9FU+LJy37Z5HFgXjEQ
+hQebyXge5BCHeKrN6KEvDagLy9QQXweDM2l/8IVCR2mA5ffWSWIhH2mriVA
4SIP2QmkHXkEb5GPbNrjNHR1YpFRVAV4RW/o3QI5zFElMYHVRpVcyrN7AzOm
U2TijuGUGAnZ0BOwMFGJUs7RkudtPPCnRM6plJuTy/FEDbKnObgov47VNYgf
BWFUTBFPf0SDIatU1RsRoAj1ykPJ3EPAfwMiQBUclmHeeOIzeZcAz0NCmECY
rNwDdkfeXmt5SVnDEsQFnojaHFaJY8pjIKteHgmZD2xAHvaiqnrjTaPEmUcI
jRgAUO64lwIU43Rf7nATtcNt3i5RCoGPaCR/450JvKWg76EkSixFsbwYgnLS
1F28YyEmDMwIL1loRu547COIQLmlVzjMDCZxVJri0Q7uQAvQgKSSKByPNUNI
dXjIxD5Js5HQ+GMS8j4YJlenRtoWXU8IOmE0VHdLJPAE7yOjzYzpJ2/s/Q5s
62kCfwMPaiA3mXBJkkHO0LAYvioTDC1pGVVyJEB/XBq25p0kvBvWpYBK0hOt
9MHePMudIJ/aa6ul0lussXRxJB1xfzLyfC44fIA35sovdPZb6vkS4SDk49KS
8gndXVoVg9iA53D67Z8oHzx8/45OF+E1iSaP+FuHv23btm3btm3btm3btm3b
tu+q/Q8sQyn9AFAAAA==
---327014936-508538613-942150891=:1224
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME="GBlippie-redhog.3.README"
Content-Transfer-Encoding: BASE64
Content-ID: <Pine.LNX.4.10.9911091334511.1224@mini.dhs.org>
Content-Description: Gtk Blippie README - describes what this is all about...
Content-Disposition: ATTACHMENT; FILENAME="GBlippie-redhog.3.README"

VGhpcyBwYXRjaCBpcyBhZ2FpbnN0IGd0aystMS4yLjYgYW5kIGdub21lLWxp
YnMtMS4wLjUzDQoNClRoaXMgcGF0Y2ggYWRkcyBhIGZ1bmN0aW9uYWxpdHkg
aSBjYWxsIGJsaXBwaWVuZXNzOyB3aGljaCBpcywgdGhhdCB0aGUNCm1lbnVz
IGFuZCB0b29sYmFycyBhcmUgaGlkZGVuIGFzIGxvbmcgYXMgdGhlIG1vdXNl
IGlzIG5vdCBpbiB0aGUgd2luZG93LA0KaGVuY2UsIHRoZSBkb2N1bWVudCBv
ciBvdGhlciwga2V5Ym9hcmQgbW9kaWZpYWJsZSB3aWRnZXRzIGFyZSBnaXZl
biBtb3JlDQpzcGFjZS4gT3RoZXIgd2lkZ2V0cyBtYXkgYXMgd2VsbCBiZSBy
ZWdpc3RlcmVkIHRvIGJsaXBwLCBidXQgb25seSBtZW51cw0KYW5kIHRvb2xi
YXJzIGRvIGl0IGJ5IGRlZmF1bHQgKEJ1dCB0aGF0J3MgZWFzeSB0byBjaGFu
Z2UpLiBUaGUgbWFpbiB1c2FnZQ0Kb2YgdGhpcyBpcyBpZiBzb21lb25lIGlt
cGxlbWVudHMgYSBkcml2ZXIgZm9yIHRoZSBuZXcgTVMgbW91c2UgdGhhdCBz
ZW5kcw0KYSBzaWduYWwgd2hlbiB5b3UgdG91Y2ggYSByZWxlYXNlcyBpdC4g
VGhpcyBkcml2ZXIgbWF5IHRoZW4gc2VuZCBhIGVudGVyDQpub2RpZnkvbGVh
dmUgbm90aWZ5IHRvIHRoZSB3aW5kb3cgd2l0aCB0aGUgY3Vyc29yIHdoZW4g
dGhlIG1vdXNlIGlzDQp0dWNoZWQgYW5kIHJlbGVhc2VkLCByZXNwZWN0aXZl
bHkuIFRoaXMgd291bGQgcmVzdWx0IGluLCB0aGF0IHdoZW4geW91IHB1dA0K
eW91ciBoYW5kcyBvbiB0aGUga2V5Ym9hcmQgdG8gd3JpdGUgYSB0ZXh0IGlu
IHlvdXIgdGV4dHByb2Nlc3NvciwgdGhlDQptZW51cyBkaXNzYXBlYXIsIGFu
ZCB5b3VyIHBvc3NpYmxlIG1heGltaXplZCB3aW5kb3cgaXMgZmlsbGVkIHdp
dGggdGhlDQp0ZXh0IHlvdSBhcmUgZWRpdGluZywgb25seS4gQXMgc29vbiBh
cyB5b3UgcHV0IHlvdXIgaGFuZCBvbiB0aGUgbW91c2UNCmFnYWluLCB0aGUg
bW91c2UtbW9kaWZpYWJsZSB3aWRnZXRzIGFwcGVhcnMgYWdhaW4uDQoNCk1v
cmUgY29uY2VwdGlvbmFsL3BoaWxvc29waGljYWwgaW5mb3JtYXRpb24gaXMg
YXZhaWxhYmxlIGZyb20NCmh0dHA6Ly9ibGlwcGllLm1pbmkuZGhzLm9yZw0K
DQpUaGUgbmV3ZXN0IHZlcnNpb24gb2YgdGhpcyBwYXRjaCBpcyBhbGx3YXlz
IGF2YWlsYWJsZSBmcm9tDQpodHRwOi8vR0JsaXBwaWUubWluaS5kaHMub3Jn
DQo=
---327014936-508538613-942150891=:1224--

From redhog@mini.dhs.org  Thu May 11 17:52:43 2000
Received: (qmail 6700 invoked from network); 9 Nov 1999 20:02:00 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 20:02:00 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id PAA30792
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 15:01:59 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id VAA28771
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 21:28:54 +0100
Date: Tue, 9 Nov 1999 21:28:45 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: Re: CList glitch (some kind o off-topic response)
In-Reply-To: <38283329.D6D2551A@udmnet.ru>
Message-ID: <Pine.LNX.4.10.9911092126510.1224-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

How do you then know when you've reached the end of the list? And it won't
help you anyway, since there are no bacvk-pointers, so knowing the start
och the list doesn't mean you know the end without traversing the whole
list. This will just help you get the start, if you know the end...

I may be wrong on this, though...

<A Href="http://www.tekmetrics.com/transcript.shtml?pid=29943">TekMetrics Online Public Transcript (e-certifications[tm])</A><Br>
<A Href="http://mini.dhs.org/PGP%20Public%20key.asc">PGP Public key</A><Br>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4KIQFHeQ6HSAJlUwRAvEGAKCCR+p6bkvpxWXDIDhQUIdN5UWBqACfUGZB
oHhoi44x5FglVxcNkvJpSwA=
=fLpw
-----END PGP SIGNATURE-----

From j-hanson@dsv.su.se  Thu May 11 17:52:43 2000
Received: (qmail 529 invoked from network); 9 Nov 1999 21:12:42 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 21:12:42 -0000
Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA06699
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 16:12:41 -0500
Received: from knesset.dsv.su.se (knesset.dsv.su.se [130.237.161.199])
	by info.dsv.su.se (8.8.8/8.8.8) with ESMTP
	id WAA23544 for <gtk-devel-list@redhat.com>;
	Tue, 9 Nov 1999 22:12:39 +0100 (MET)
Date: Tue, 9 Nov 1999 22:12:38 +0100 (MET)
From: Johan Hanson <j-hanson@dsv.su.se>
To: gtk-devel-list@redhat.com
Subject: GtkTable replacement
Message-ID: <Pine.GSO.4.20.9911092204440.18919-100000@knesset.dsv.su.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hello all.

I have rewritten the GtkTable widget. (as of GTK+ 1.2.3)
My contributions are:
 * make it easier to subclass and give more functionality,
   which is difficult with GtkTable.
 * relative rows and columns

My class is an early beta. I am currently writing a subclass, which would
test the subclass-ability of my GtkTable.
You will be able to find it at:
  http://www.dsv.su.se/~j-hanson/pfxtable.tar.gz

I used the prefixes "Pfx", "PFX_" and "pfx_" respectivelly so that it
could be tested together with a stable GTK library.

I want your feedback before I upload it to ftp.gtk.org.

Thanks.
 / Johan
         --  johan@tiq.com  --  http://www.dsv.su.se/~j-hanson/ --

From redhog@mini.dhs.org  Thu May 11 17:52:43 2000
Received: (qmail 9281 invoked from network); 9 Nov 1999 21:31:58 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 9 Nov 1999 21:31:58 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA09298
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 16:31:57 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id WAA29067
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 22:58:52 +0100
Date: Tue, 9 Nov 1999 22:58:52 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: Re: GtkTable replacement
In-Reply-To: <Pine.GSO.4.20.9911092204440.18919-100000@knesset.dsv.su.se>
Message-ID: <Pine.LNX.4.10.9911092257370.1224-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

>From what I know, a GtkTable can not be resized (You can not add new
columns/rows after creating it). Is this true? In that case, is that true
for your GtkTable version too?

<A Href="http://www.tekmetrics.com/transcript.shtml?pid=29943">TekMetrics Online Public Transcript (e-certifications[tm])</A><Br>
<A Href="http://mini.dhs.org/PGP%20Public%20key.asc">PGP Public key</A><Br>

From oconnor@mail.redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 5989 invoked from network); 10 Nov 1999 02:35:25 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 10 Nov 1999 02:35:25 -0000
Received: from pompeii.ise (troy.eiffel.com [198.68.147.5])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id VAA06428
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 21:35:24 -0500
Received: from cannes.ise
	([10.0.10.100] helo=eiffel.com ident=oconnor)
	by pompeii.ise with esmtp (Exim 3.02 #2)
	id 11lNb3-0007E4-00
	for gtk-devel-list@redhat.com; Tue, 09 Nov 1999 18:34:53 -0800
Sender: oconnor@mail.redhat.com
Message-ID: <3828D9CC.E0557E42@eiffel.com>
Date: Tue, 09 Nov 1999 18:34:52 -0800
From: "Sam O'Connor" <oconnor@eiffel.com>
Reply-To: oconnor@eiffel.com
Organization: ISE
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Proposal: gtk_object to emmit reference changed signals
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I would like some kind of hook to do stuff
when an object's reference count changes.
I guess a signal for ref and one for unref.
I need to be able to do stuff when the count
goes from 1 to 2 and when it goes from 2 to 1.

I am currently working on a problem that
involves getting the GTK+ reference counting
system to cooperate nicely with a mark & sweep
GC in an Eiffel system.

I would like to add these signals and would like
to know if they have any chance of being included
in some future release.

<At this point if you can say "Absolutely no way in
hell" then don't bother reading the gumph below.>

I have Eiffel objects that act as proxies for
the GTK objects. They create a gtk object, ref it
and sink it, thus taking control of its lifetime.

When I tell an eiffel box to add an eiffel button,
gtk_container_add (box, button) is done, I have no
need to hold a reference to my eiffel button in my
eiffel box. Later if I ask for the box's child the
GtkButton is extracted and I can look up the eiffel
object in a global C pointer -> eiffel object map.
This saves me from mirroring knowledge of the box
contents in eiffel, I let GTK be the master and
query it's state when I am interested.

I want my mark & sweep GC in eiffel to clean up
eiffel objects that have GTK objects that have
ref counts of 1.
(ie only the E object refs the GTK one)

But if the GTK object has 2 refs the second one
may end up being used to get to the eiffel object
so I want to keep the eiffel object.

I can have the GTK object hold a reference to
the eiffel object (One that causes the GC not to
kill it (this is done through some magic involving
talking to the Eiffel GC from C)),
so what I want is to detect when the ref count in GTK
drops to 1 and remove the eiffel reference. And also
detect when it goes to 2 and attach the eiffel reference.
(Basically a toggle between a weak/strong ref in eiffel)

This way stuff that the GC doesn't reach in it's marking
phase and that doesn't have a ref from GTK gets killed.
(This eventually leads to little substructures that can
not be reached from the root object being killed as well.)

Basically I want to have a reference to a gtk object
count as a reference to the corresponding eiffel object
as far as the GC is concerned.
(Ignoring the ref the eiffel object itself holds on the GTK object)

As I said above, I'm happy to implement the new signals
but I'd like to get a feel for weather this sounds
outlandish to those of you who know better before
I start.

Thanks

Sam O'Connor

From sopwith@redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 297 invoked from network); 10 Nov 1999 04:36:28 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 10 Nov 1999 04:36:28 -0000
Received: from stan.redhat.com (stan.redhat.com [199.183.24.231])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id XAA13163
	for <gtk-devel-list@redhat.com>; Tue, 9 Nov 1999 23:36:28 -0500
Received: (from news@localhost)
	by stan.redhat.com (8.9.3/8.9.3) id XAA06515
	for gtk-devel-list@redhat.com; Tue, 9 Nov 1999 23:37:20 -0500
To: gtk-devel-list@redhat.com
Path: sopwith
From: sopwith@redhat.com (Elliot Lee)
Newsgroups: gated.gtk-devel-list
Subject: Re: Proposal: gtk_object to emmit reference changed signals
Date: 10 Nov 1999 04:37:20 GMT
Organization: Red Hat Software
Lines: 39
Distribution: gated
Message-ID: <slrn82htic.oid.sopwith@lacrosse.corp.redhat.com>
References: <3828D9CC.E0557E42@eiffel.com>
NNTP-Posting-Host: lacrosse.corp.redhat.com
X-Trace: stan.redhat.com 942208640 6514 207.175.42.154 (10 Nov 1999 04:37:20 GMT)
X-Complaints-To: abuse@redhat.com
NNTP-Posting-Date: 10 Nov 1999 04:37:20 GMT
User-Agent: slrn/0.9.5.4 (UNIX)

On 9 Nov 1999 21:36:24 -0500, Sam O'Connor <oconnor@eiffel.com> wrote:
>I would like some kind of hook to do stuff
>when an object's reference count changes.
>I guess a signal for ref and one for unref.
>I need to be able to do stuff when the count
>goes from 1 to 2 and when it goes from 2 to 1.
>
>I am currently working on a problem that
>involves getting the GTK+ reference counting
>system to cooperate nicely with a mark & sweep
>GC in an Eiffel system.

Trying to mirror refcounts between different objects didn't work very well
for the ObjC bindings when I was doing them. I'm not quite clear on how the
Eiffel GC works - does it allow you to have an is_object_in_use() method
called? The best way seems to be to just have an Eiffel object with no
explicit refcounts on a GtkObject, and then when the 'destroy' signal on the
GtkObject fires, you mark your Eiffel object as being no longer in use. You
also have a way to turn a GtkObject into an Eiffel object
(gtk_object_[gs]et_data():).

Since the GtkObject has the final word on whether the "object" lives or
dies, and is in fact the "real" object, you shouldn't need to necessarily
have an Eiffel object around even when the GtkObject is still alive. The
Eiffel object is only used by Eiffel stuff, not by gtk+, so you should
ignore any gtk+ refcounts when determining whether the Eiffel object lives
or dies.

Another data point - What the ObjC bindings do is keep the ObjC Object alive
until the 'destroy' signal is received on the gtk+ object. If the ObjC
object is freed explicitly, the signal handler is removed and then the
GtkObject is destroyed. No reference counts either way are involved.

Besides, the gtk signal system needs to acquire & release refcounts on
objects, which would cause a nice amount of infinite recursion if your
suggestion were to be implemented.
-- Elliot
Do not meddle in the affairs of dragons,
for you are crunchy and good with ketchup. 

From oconnor@mail.redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 4964 invoked from network); 10 Nov 1999 06:17:42 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 10 Nov 1999 06:17:42 -0000
Received: from pompeii.ise (troy.eiffel.com [198.68.147.5])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id BAA19951
	for <gtk-devel-list@redhat.com>; Wed, 10 Nov 1999 01:17:41 -0500
Received: from cannes.ise
	([10.0.10.100] helo=eiffel.com ident=oconnor)
	by pompeii.ise with esmtp (Exim 3.02 #2)
	id 11lR4A-00018D-00
	for gtk-devel-list@redhat.com; Tue, 09 Nov 1999 22:17:10 -0800
Sender: oconnor@mail.redhat.com
Message-ID: <38290DE5.8294640E@eiffel.com>
Date: Tue, 09 Nov 1999 22:17:09 -0800
From: "Sam O'Connor" <oconnor@eiffel.com>
Reply-To: oconnor@eiffel.com
Organization: ISE
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.2.10 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: Proposal: gtk_object to emmit reference changed signals
References: <3828D9CC.E0557E42@eiffel.com> <slrn82htic.oid.sopwith@lacrosse.corp.redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for your reply.

Elliot Lee wrote:
> 
> On 9 Nov 1999 21:36:24 -0500, Sam O'Connor <oconnor@eiffel.com> wrote:
> >I would like some kind of hook to do stuff
> >when an object's reference count changes.
> >I guess a signal for ref and one for unref.
> >I need to be able to do stuff when the count
> >goes from 1 to 2 and when it goes from 2 to 1.
> >
> >I am currently working on a problem that
> >involves getting the GTK+ reference counting
> >system to cooperate nicely with a mark & sweep
> >GC in an Eiffel system.
> 
> Trying to mirror refcounts between different objects didn't work very well
> for the ObjC bindings when I was doing them. I'm not quite clear on how the
> Eiffel GC works - does it allow you to have an is_object_in_use() method
> called?

The Eiffel GC in the runtime I'm using GC the mark and sweep algorithm.
To the best of my knowlege it goes somthing like this:
Start with set of all objects + the root object.
Recursivly follow references from the root object marking each object reached.
Destroy all objects that are not marked.
So event if you have some big structure with cycles where everything is
referenced, if it is not reachable from the root it gets killed.
There is no way to know if an object is "in use", if it isn't it gets collected
somtime later, in any case, if you have a reference to an object in order to
ask it if it is in use the it is because yuo have a reference to it.

> The best way seems to be to just have an Eiffel object with no
> explicit refcounts on a GtkObject, and then when the 'destroy' signal on the
> GtkObject fires, you mark your Eiffel object as being no longer in use. You
> also have a way to turn a GtkObject into an Eiffel object
> (gtk_object_[gs]et_data() :).

Storing a reference to an Eiffel object in GTk object data is no problem
although it is a bit tricky because Eiffel objects are moved around by the
GC quite often.
The things is, I want to be able to remove an eiffel object from it's parent,
and have the GTK object live on until it gets reparented. I want to hold a
refernece on the GTK obj for this reason. (So I dont have to catch every reparenting
operation with the right ref wrappers.)

> Since the GtkObject has the final word on whether the "object" lives or
> dies, and is in fact the "real" object, you shouldn't need to necessarily
> have an Eiffel object around even when the GtkObject is still alive. The
> Eiffel object is only used by Eiffel stuff, not by gtk+, so you should
> ignore any gtk+ refcounts when determining whether the Eiffel object lives
> or dies.

I would love to have super thin stateless wrappers and just make a new one
for every C pointer I come accross and destroy them when I'm done, letting
the GTK object be the real object but wearing a new shell every time it
pops into eiffel land. The problem is I can't because if I see a pointer
to a GtkHBox I have no idea if I should create an EIFFEL_H_BOX or a
EIFFEL_COMPLICATED_TOOLBAR_THING that happens to look like a GtkHBox
from the outside. Perhaps there is some way that I can store the type
in the object data, Eiffel is staticaly types so I can't exactly do
this but I might be able to store a pointer to a factory or somthing
like that.

> Another data point - What the ObjC bindings do is keep the ObjC Object alive
> until the 'destroy' signal is received on the gtk+ object. If the ObjC
> object is freed explicitly, the signal handler is removed and then the
> GtkObject is destroyed. No reference counts either way are involved.

The features i am tyring to achive are:
Coupling:
	Eiffel object never exists without GTK object.
	GTK object may exist without eiffel object if
	I find a good way to make a new Eiffel object
	from the GTK object.

Garbage:
	Unreachable (from eiffel) eiffel objects
	connected to unreachabe (from eiffel through
	some GTK refrence path) GTK objects.

Not garbage:
	Unreachable (from eiffel) eiffel objects
	connected to reachable (from eiffel through
	some GTK refrence path) GTK objects.

	GTK objects connected to reachable (from eiffel)
	eiffel objects.

> 
> Besides, the gtk signal system needs to acquire & release refcounts on
> objects, which would cause a nice amount of infinite recursion if your
> suggestion were to be implemented.
> -- Elliot

I will investigate the "Make new eiffel objects from GTK ones just in time"
angle further.
Would somthing like the weakref system get around the loopieness problem?
It seems to be just a linked list of function/data pairs. It seems to me
that this would work, just call the list in _ref and _unref, obviously
you can shoot yourself in the foot quite easily if you change a reference
in the callback, this could be just bad luck or I could keep a little
context stack to detect cycles and raise an exception.

Perhaps a good idea will arrive avter I've slept some.

Sam

From gale@syntax.dera.gov.uk  Thu May 11 17:52:43 2000
Received: (qmail 1651 invoked from network); 10 Nov 1999 09:09:33 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 10 Nov 1999 09:09:33 -0000
Received: from syntax.dera.gov.uk (syntax.dera.gov.uk [146.80.9.50])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id EAA21501
	for <gtk-devel-list@redhat.com>; Wed, 10 Nov 1999 04:09:32 -0500
Received: (qmail 26174 invoked from network); 10 Nov 1999 09:09:31 -0000
Received: from syntax.dera.gov.uk (146.80.9.50)
  by syntax.dera.gov.uk with SMTP; 10 Nov 1999 09:09:31 +0000
Message-ID: <XFMail.991110090930.trog@gtk.org>
X-Mailer: XFMail 1.4.0 on Linux
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
In-Reply-To: <199911091916.OAA18182@guanabana.labs.redhat.com>
Date: Wed, 10 Nov 1999 09:09:30 -0000 (GMT)
Sender: gale@syntax.dera.gov.uk
From: Trog <trog@gtk.org>
To: gtk-devel-list@redhat.com
Subject: Re: CList glitch (some kind o off-topic response)


On 09-Nov-99 Federico Mena Quintero wrote:
>>  My problem with owens argument is that last time I checked there
>>  was not a full set of algorithms for manipulating a gqueue like a
>>  glist,  thus there is no glist equivalent with O(1) tail and no
>>  one is likely to replace uses of glist where is was used with
>>  lots of appends in gtk+ already.  Thus is is only a token effort
>>  to correct the problem.
> 
> If there is a portion of code in GTK+ that creates long lists by
> appending, and that code is not keeping its own tail pointer, then
> it
> should be considered buggy for lack of performance.  It should be
> fixed.
> 

Fine, but what about users code?

For users to keep a tail pointer thay need to make assumptions about
the implementation of lists that GLib uses.

I don't agree with Owen that using list->next in code is OK when we
have a g_list_next() function for just that purpose.

It *is* possible to fix the GList implementation to provide O(1)
appending without breaking any code. Indeed, Owen, Karl and I have
discussed this at great length previously, but Owen wasn't convinced
by our argument.

-tony


---
E-Mail: trog@gtk.org
I brake for chezlogs!

Go Bezerk! http://www.gtk.org/~trog

From eeyem@u.washington.edu  Thu May 11 17:52:43 2000
Received: (qmail 3339 invoked from network); 10 Nov 1999 09:48:45 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 10 Nov 1999 09:48:45 -0000
Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id EAA26027
	for <gtk-devel-list@redhat.com>; Wed, 10 Nov 1999 04:48:45 -0500
Received: from mailhost2.u.washington.edu (mailhost2.u.washington.edu [140.142.33.2])
	by mxout2.cac.washington.edu (8.9.3+UW99.09/8.9.3+UW99.08) with ESMTP id BAA28467
	for <gtk-devel-list@redhat.com>; Wed, 10 Nov 1999 01:48:44 -0800
Received: from trout (D-128-95-49-181.dhcp.washington.edu [128.95.49.181])
	by mailhost2.u.washington.edu (8.9.3+UW99.09/8.9.3+UW99.08) with SMTP id BAA09820
	for <gtk-devel-list@redhat.com>; Wed, 10 Nov 1999 01:48:44 -0800
Message-ID: <006901bf2b60$a5190b80$b5315f80@trout>
From: "Evan Martin" <eeyem@u.washington.edu>
To: "Gtk Devel" <gtk-devel-list@redhat.com>
Subject: Widgets in CLists
Date: Wed, 10 Nov 1999 01:47:47 -0800
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200

The documentation leads me to believe that I could insert a widget as the
content of a CList cell.  Browsing the GTK source, though, seems to indicate
that it is unimplemented.

Am I missing something?  Are there plans to implement it?  If not, is there
a reason it shouldn't be implemented?  If I implemented it reasonably, would
my patch be accepted?

Evan.

From john@mail.redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 26535 invoked from network); 10 Nov 1999 11:50:19 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 10 Nov 1999 11:50:19 -0000
Received: from www.ng-london.org.uk (mailhost.ng-london.org.uk [195.195.116.33])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id GAA05552
	for <gtk-devel-list@redhat.com>; Wed, 10 Nov 1999 06:50:19 -0500
Received: from ng-london.org.uk (cima.ng-london.org.uk [195.195.116.63]) by www.ng-london.org.uk with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3)
	id 4Y7RHRQJ; Wed, 10 Nov 1999 11:50:14 -0000
Sender: john@mail.redhat.com
Message-ID: <38295BEE.329A7A46@ng-london.org.uk>
Date: Wed, 10 Nov 1999 11:50:06 +0000
From: John Cupitt <john.cupitt@ng-london.org.uk>
Organization: The National Galley
X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: CList glitch (some kind o off-topic response)
References: <Pine.LNX.4.10.9911091027370.21411-100000@ashi.FootPrints.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Karl Nelson wrote:
> The problem I see with the whole glib structure is that often
> the concept of what is the list and what is a place in the list
> are confused.  It should have been designed so that the first
> argument to all list operations was a pointer to a list abstraction.

I have a LISPy background, and I like the way g_slist_*() works now :) If glib
had C++-style lists with iterators, I'd probably be clamoring for my
lispy-list stuff to be added. 

LISP lists have some advantages over C++ interators: because they are
recursive data structures (take the tail of a list, you still have a list),
lots of list manipulation operators have simple recursive implementations. 

For example, mkset() is a standard LISP thing to remove duplicates from a
list. You can do an efficient implementation in a few lines of C for g_slist,
it's far harder (I think) for g_list, and also much harder with iterators.

Also (we're really on a minor side-track here) program proofs are much easier
with g_slist ... you can just do induction. iterator-style interfaces require
list invariants, elaborate iterator axiom things and stuff like that. So I
find I'm more confident my program works if I use g_slist.

I'm not saying C++-style lists are bad, just that there are arguments for the
way things are now.

John
--
John Cupitt, john.cupitt@ng-london.org.uk, +44 (0)171 747 2570
VASARI Lab, The National Gallery, Trafalgar Square, London, WC2N 5DN

From j-hanson@dsv.su.se  Thu May 11 17:52:43 2000
Received: (qmail 1747 invoked from network); 10 Nov 1999 13:22:19 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 10 Nov 1999 13:22:19 -0000
Received: from info.dsv.su.se (info.dsv.su.se [130.237.161.221])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id IAA13736
	for <gtk-devel-list@redhat.com>; Wed, 10 Nov 1999 08:22:18 -0500
Received: from knesset.dsv.su.se (knesset.dsv.su.se [130.237.161.199])
	by info.dsv.su.se (8.8.8/8.8.8) with ESMTP
	id OAA29415;
	Wed, 10 Nov 1999 14:22:16 +0100 (MET)
Date: Wed, 10 Nov 1999 14:22:15 +0100 (MET)
From: Johan Hanson <j-hanson@dsv.su.se>
To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
cc: gtk-devel-list@redhat.com
Subject: Re: GtkTable replacement
In-Reply-To: <Pine.LNX.4.10.9911092257370.1224-100000@mini.dhs.org>
Message-ID: <Pine.GSO.4.20.9911101402040.19654-100000@knesset.dsv.su.se>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 9 Nov 1999 redhog@mini.dhs.org wrote:

> From what I know, a GtkTable can not be resized (You can not add new
> columns/rows after creating it). Is this true? In that case, is that true
> for your GtkTable version too?

You can add and remove child widgets in both the existing GtkTable and in
my version. I don't about the 1.0.x series, but it works in 1.2.x.

There are three groups of functions that I know would be useful in my
subclass, that I am not sure would fit in GtkTable. These are:

* Hide/show a square of table cells.

* Insert/remove rows and columns within the table, and not just at the
  right and/or the bottom.

* Resize columns/rows. Either by moving an imaginary border a relative
  amount or set a new width or height for a row, column or child widget.

I would like to get people's opinions on this.

 / Johan
         --  johan@tiq.com  --  http://www.dsv.su.se/~j-hanson/ --

From ad@papyrus-gmbh.de  Thu May 11 17:52:43 2000
Received: (qmail 18184 invoked from network); 10 Nov 1999 14:01:20 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 10 Nov 1999 14:01:20 -0000
Received: from mail.mediascape.de (root@mail.mediascape.de [212.105.192.3])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id JAA18058
	for <gtk-devel-list@redhat.com>; Wed, 10 Nov 1999 09:01:20 -0500
Received: from lx2.noname (papyrus-gmbh.de [212.105.195.67])
	by mail.mediascape.de (8.9.3/8.9.2) with ESMTP id PAA09486
	for <gtk-devel-list@redhat.com>; Wed, 10 Nov 1999 15:04:29 +0100
Received: from speedy ([132.147.160.218]) by lx2.noname
	 with esmtp (ident root using rfc1413) id m11lYJ0-00113HC
	(Debian Smail-3.2.0.102 1998-Aug-2 #2); Wed, 10 Nov 1999 15:00:58 +0100 (CET)
Received: by speedy
	id m11lYIz-000B1rC
	(Debian Smail-3.2.0.101 1997-Dec-17 #2); Wed, 10 Nov 1999 15:00:57 +0100 (CET)
To: gtk-devel-list@redhat.com
Subject: Re: Proposal: gtk_object to emmit reference changed signals
References: <3828D9CC.E0557E42@eiffel.com> <slrn82htic.oid.sopwith@lacrosse.corp.redhat.com>
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
From: Andreas Degert <ad@papyrus-gmbh.de>
Date: 10 Nov 1999 15:00:57 +0100
In-Reply-To: sopwith@redhat.com's message of "10 Nov 1999 04:37:20 GMT"
Message-ID: <873dueh2ee.fsf@papyrus-gmbh.de>
Lines: 28
X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald"

sopwith@redhat.com (Elliot Lee) writes:

[...]
> Trying to mirror refcounts between different objects didn't work very well
> for the ObjC bindings when I was doing them. I'm not quite clear on how the
> Eiffel GC works - does it allow you to have an is_object_in_use() method
> called? The best way seems to be to just have an Eiffel object with no
> explicit refcounts on a GtkObject, and then when the 'destroy' signal on the
> GtkObject fires, you mark your Eiffel object as being no longer in use. You
> also have a way to turn a GtkObject into an Eiffel object
> (gtk_object_[gs]et_data() :).

I have used that in pygtk (python language binding) to permanently
associate python class instances with gtk objects. The current way is
to always create a new instance (e.g. for signal handlers), so the
state of the python instance is not preserved. It works quite well,
though there is one problem: it doesn't work for destroy signal
handlers, because the handler to clean up the reference on destroy is
installed first. My current workaround is to remove and reinstall this 
signal handler when another handler for destroy is to be installed.

Anyone a better idea?

ciao
Andreas

PS: python objects aren't moved around, so its only storing and using
    a simple C pointer.

From glaurent@worldnet.fr  Thu May 11 17:52:43 2000
Received: (qmail 27705 invoked from network); 10 Nov 1999 14:15:46 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 10 Nov 1999 14:15:46 -0000
Received: from rogue.worldnet.fr (root@p12-056.province.worldnet.fr [195.3.12.56])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id JAA19354
	for <gtk-devel-list@redhat.com>; Wed, 10 Nov 1999 09:15:43 -0500
Received: (from glaurent@localhost)
	by rogue.worldnet.fr (8.9.3/8.9.3) id PAA12525;
	Wed, 10 Nov 1999 15:15:49 +0100
Sender: glaurent@worldnet.fr
To: gtk-devel-list@redhat.com
Subject: Re: CList glitch (some kind o off-topic response)
References: <Pine.LNX.4.10.9911091027370.21411-100000@ashi.FootPrints.net> <38295BEE.329A7A46@ng-london.org.uk>
From: Guillaume Laurent <glaurent@worldnet.fr>
Date: 10 Nov 1999 15:15:49 +0100
In-Reply-To: John Cupitt's message of "Wed, 10 Nov 1999 11:50:06 +0000"
Message-ID: <m3g0yetotm.fsf@rogue.worldnet.fr>
Lines: 22
X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches"

John Cupitt <john.cupitt@ng-london.org.uk> writes:

> LISP lists have some advantages over C++ interators: because they are
> recursive data structures (take the tail of a list, you still have a list),
> lots of list manipulation operators have simple recursive implementations. 

This is because iterators aren't for lists only.

> For example, mkset() is a standard LISP thing to remove duplicates from a
> list. You can do an efficient implementation in a few lines of C for g_slist,
> it's far harder (I think) for g_list, and also much harder with iterators.

It may be harder, but it's already defined in the STL, so why care ? :-)
 
> I'm not saying C++-style lists are bad, just that there are
> arguments for the way things are now.

I don't think any of them is worth being forever tied to an
implementation.

-- 
						Guillaume

From per@lain.idonex.se  Thu May 11 17:52:43 2000
Received: (qmail 306 invoked from network); 11 Nov 1999 04:00:45 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 11 Nov 1999 04:00:45 -0000
Received: from jolt.idonex.se (jolt.idonex.se [194.52.182.67])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id XAA11854
	for <gtk-devel-list@redhat.com>; Wed, 10 Nov 1999 23:00:44 -0500
Received: from lain.idonex.se (per@lain.idonex.se [194.52.182.122])
	by jolt.idonex.se (8.8.8/8.8.8) with SMTP id FAA02732
	for <gtk-devel-list@redhat.com>; Thu, 11 Nov 1999 05:00:39 +0100 (MET)
Sender: per@lain.idonex.se
To: gtk-devel-list@redhat.com
Subject: Re: Proposal: gtk_object to emmit reference changed signals
References: <3828D9CC.E0557E42@eiffel.com> <slrn82htic.oid.sopwith@lacrosse.corp.redhat.com> <873dueh2ee.fsf@papyrus-gmbh.de>
Content-Transfer-Encoding: 8BIT
X-Face: n@|LL~4jUz:`2>~UueTS[l'>cXzj*h3O*tB,vl%'OqRB>s*_Q)\rDXrb1{zbN6+PU4StNKR
 br,h]\pC-JHyFj7Y}mwb8.RGcX*SJ~E4zbN|R'_7SVFe~eqY2%YFGs?.5JSg2-;G3;w]nMKw?yEEoI
 NWf3a0</\9D$0D)ZxX0LP&Yq$Ft$IC9G<P3M#V0ucU@tz20AyogguLS[Sa06zR%-~z)a5YNo1'W*VI
 /4db@&zt0TU#%WB2wqGt<j7B0sfmM`qM_yX-CO;Sz<ULkpk1Xj?D'EOPXuLc1.'7ig>Zx$zgn8Q'^W
Content-Type: text/plain; charset=iso-8859-1
From: Per Hedbor <per@idonex.se>
Date: 11 Nov 1999 05:00:51 +0100
In-Reply-To: Andreas Degert's message of "10 Nov 1999 15:00:57 +0100"
Message-ID: <861z9xvfrg.fsf@lain.idonex.se>
Lines: 76
User-Agent: Gnus/5.070095 (Pterodactyl Gnus v0.95) XEmacs/21.2 (Shinjuku)
MIME-Version: 1.0

Pike GTK uses gtk_object_set_data_full, with a free function that
frees the extra reference to the pike object.

Basically:


void my_destroy( struct object *o )
{
  GtkObject *go = pgtk_get_gtk_object( o );
  if(!go) 
    return;
  pgtk_set_gtk_object( o, NULL );
  free_object( o );           /* Free pike object */
}


void pgtk_init_object( struct object *o )
{
  GtkObject *go = pgtk_get_gtk_object( o );

  if(!go)
    fatal("pgtk__init_object called on a non-pgtk object!\n");

  ref_object( o ); /* Reference pike object */

  gtk_object_set_data_full( go, "pike_object", (void*)o,
                            (void*)my_destroy );
}



Also, this makes it very easy to get the pike object associated with
the arguments in, as an example, signal functions, which makes it easy
to make your own widgets from pike.

You can inherit, say, GTK.Window in your own class, then redefine some
functions, and add your own code (especially, you often redefine the
constructor), then, when you receive this window object in a signal
call-back, it will be _your_ window object, not a the actual generic
Gtk-Window associated with it.


void pgtk_push_gtkobject_with_default_class(GtkObject *obj, 
                                            struct program *def_class)
{
  struct object *o;

  if(!obj)
  {
    push_int(0);
    return;
  }

  if( (o=gtk_object_get_data(GTK_OBJECT(obj), "pike_object")) )
  {
    ref_push_object( o );
    return;
  }


 /* All of this is here to avoid calling the constructor method
  * in the class (since that would create a new instance of the
  * associated GTK widget, which is not what we want)
  */
  o = low_clone( def_class );
  call_c_initializers( o );
  pgtk_set_gtk_object( o, obj );
  pgtk_init_object( o );
  ref_push_object( o );
  return;
}

I hope some of this helps.

-- 
Per Hedbor                                              http://per.hedbor.org/

From otaylor@redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 2382 invoked from network); 11 Nov 1999 16:34:31 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 11 Nov 1999 16:34:31 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id LAA24414
	for <gtk-devel-list@redhat.com>; Thu, 11 Nov 1999 11:34:31 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id LAA23658;
	Thu, 11 Nov 1999 11:32:43 -0500
To: Martin Oberzalek <oberzalek@chello.at>
Cc: gtk-devel-list@redhat.com
Subject: Re: gtk-oberzalek-991111-1.patch.README
References: <Pine.LNX.4.10.9911111642060.16568-200000@leo.chello.at>
From: Owen Taylor <otaylor@redhat.com>
Date: 11 Nov 1999 11:32:43 -0500
In-Reply-To: Martin Oberzalek's message of "Thu, 11 Nov 1999 16:44:42 +0100 (MET)"
Message-ID: <ybeg0yd7zv8.fsf@fresnel.labs.redhat.com>
Lines: 71
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Martin Oberzalek <oberzalek@chello.at> writes:

> This is the README file of the gtk-oberzalek-991111-1.patch.gz
> in  the incoming directory of ftp.gtk.org
> 
> Note:
> That's a patch for the glib, but I named it gtk-ob... because of 
> your instructions at ftp.gtk.org

Actually, naming it glib-* would be more appropriate. The instructions
may not be very clear.

> I added the g_strinstr function to g_str* functions.
> g_strinstr -> g_str in string
> That's a port of INSTR command from basic. 
> I actually port a basic application to gnome and so I need that function.
>
> gint g_strinstr( gchar *text, gchar *word )

Hmmm, this looks a lot like strstr, except that it is case-insensitive.

If we added a function like this, it should be called something like:

 g_strcasestr() or g_strstr_insensitive()

I'm not sure if such a function is useful or not for general purpose
implementation - if we did add such a function, I'd like to see
a more efficient implementation - you might want to look at 
a text like Knuth for information about string searching algorithms.

(A simple optimization is to scan text for the initial character
of the word before trying a strncasecmp. Also, the inner copy in your
implementation is going to be very slow.)

> text: A string where should be searched for the keyword.
> word: The keyword.
> returns: The function returns the position of the keyword, if the keyword
> 	 is found. If not it returns -1.
> 	 The functions starts counting the position with 0.
> 
> I hope I helped you.

=============

> I added some BASIC string functions to the glib:
> 
> BASIC        GLIB                                                           DESCRIPTION
> LEFT$        #define g_strleft(text, len) g_strndup(text, len)              only to complete the functions
> RIGHT$	     gchar* g_strright(gchar *text, gint len)                       same as g_strleft, but fromthe right side of the string
> MID$         gchar* g_strmid(gchar *text, guint pos, guint len)             copies a string out of a string
> INSTR$	     gint g_strinstr(gchar *text, gchar* word)                      finds a string in a string and gives it's position back
> 
> 
> These functions are very useful for porting applications from BASIC to C
> I actually port eliza, so I needed them. 

Hmmm, your implementations suffer from a bit of inefficiency:

#define g_strmid(text,pos,len) g_strndup ((text) + (pos), len)
#define g_strright(text,len) g_strdup ((text) + strlen(text) - (len))

I'd be inclined to say that these wrappers don't add enough convenience
to really be worth adding into GLib ... there are various other 
string manipulation libraries that one might want to emulate 
Perl, Java, STL, etc... and I don't think we want to have 
#define's for all possible names...

Regards,
                                        Owen

From lemingse@[160.205.112.149]  Thu May 11 17:52:43 2000
Received: (qmail 16762 invoked from network); 12 Nov 1999 19:14:53 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 12 Nov 1999 19:14:52 -0000
Received: from mailgw1a.lmco.com (mailgw1a.lmco.com [192.31.106.7])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA04000
	for <gtk-devel-list@redhat.com>; Fri, 12 Nov 1999 14:14:51 -0500
Received: from emss02g01.ems.lmco.com (emss02g01.ems.lmco.com [198.7.15.39])
	by mailgw1a.lmco.com (8.8.8/8.8.8) with ESMTP id MAA01676
	for <gtk-devel-list@redhat.com>; Fri, 12 Nov 1999 12:14:50 -0700 (MST)
Received: from CONVERSION-DAEMON by lmco.com (PMDF V5.2-32 #38887) id <0FL300001MQ9T5@lmco.com> for gtk-devel-list@redhat.com;
 Fri, 12 Nov 1999 12:14:46 -0700 (MST)
Received: from lmco.com ([160.205.112.149]) by lmco.com (PMDF V5.2-32 #38887) with ESMTP id <0FL300KTPMPGVY@lmco.com> for
 gtk-devel-list@redhat.com; Fri, 12 Nov 1999 12:12:52 -0700 (MST)
Date: Fri, 12 Nov 1999 12:11:54 -0700
From: Eric Lemings <eric.b.lemings@lmco.com>
Subject: GLib: g_array_new
Sender: lemingse@[160.205.112.149]
To: gtk-devel-list@redhat.com
Message-id: <382C667A.F683F5B2@lmco.com>
Organization: Lockheed Martin
MIME-version: 1.0
X-Mailer: Mozilla 4.61 [en] (X11; U; SunOS 5.5.1 sun4m)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en

Dear GLib developers,

In the g_array_new function, are the zero_terminated and clear flags
really required to create the array?  Or can default values be used and
the flags changed later on if need be?

Thanks,
Eric.

From sopwith@redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 7924 invoked from network); 12 Nov 1999 22:44:06 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 12 Nov 1999 22:44:06 -0000
Received: from stan.redhat.com (stan.redhat.com [199.183.24.231])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id RAA16895
	for <gtk-devel-list@redhat.com>; Fri, 12 Nov 1999 17:44:05 -0500
Received: (from news@localhost)
	by stan.redhat.com (8.9.3/8.9.3) id QAA08407
	for gtk-devel-list@redhat.com; Fri, 12 Nov 1999 16:46:41 -0500
To: gtk-devel-list@redhat.com
Path: sopwith
From: sopwith@redhat.com (Elliot Lee)
Newsgroups: gated.gtk-devel-list
Subject: Re: GLib: g_array_new
Date: 12 Nov 1999 21:46:41 GMT
Organization: Red Hat Software
Lines: 16
Distribution: gated
Message-ID: <slrn82p2kb.9dg.sopwith@lacrosse.corp.redhat.com>
References: <382C667A.F683F5B2@lmco.com>
NNTP-Posting-Host: lacrosse.corp.redhat.com
X-Trace: stan.redhat.com 942443201 8363 207.175.42.154 (12 Nov 1999 21:46:41 GMT)
X-Complaints-To: abuse@redhat.com
NNTP-Posting-Date: 12 Nov 1999 21:46:41 GMT
User-Agent: slrn/0.9.5.4 (UNIX)

On 12 Nov 1999 14:16:01 -0500, Eric Lemings <eric.b.lemings@lmco.com> wrote:

>In the g_array_new function, are the zero_terminated and clear flags
>really required to create the array?  Or can default values be used and
>the flags changed later on if need be?

1. You should really ask this question on gtk-app-devel-list and not gtk-devel-list, which
is for the discussion of the development of glib & gtk+ themselves.

2. I don't see any reason to have separate accessor functions for zero_terminated and
clear properties, or to allow changing them after array creation. Arrays are so generic
that the use context almost always makes the needed flags obvious at creation time.

-- Elliot
Do not meddle in the affairs of dragons,
for you are crunchy and good with ketchup. 

From redhog@mini.dhs.org  Thu May 11 17:52:43 2000
Received: (qmail 16565 invoked from network); 13 Nov 1999 11:44:13 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 13 Nov 1999 11:44:13 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id GAA24279
	for <gtk-devel-list@redhat.com>; Sat, 13 Nov 1999 06:44:12 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id NAA10686
	for <gtk-devel-list@redhat.com>; Sat, 13 Nov 1999 13:10:50 +0100
Date: Sat, 13 Nov 1999 13:10:45 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: Unused signals
Message-ID: <Pine.LNX.4.10.9911131301530.13701-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Is it possible to do this:

I have a se of widgets, contained in each other, and all of them inside
some other widget. I now want to know if the user pressed some mouse
button(s) (possibly together with some modifiers) inside any of these
widgets, but only if those widgets haven't handled the event by
themselves.

Example:

+-------------------------------------+
|                           <-----------------Here I allways want to know what's happening (This container doesn't catch anything by itself).
|  +--------------+                   |
|  |Button    <-------------------------------Here I want to know everything, except from a left-klick (That is used to klick the button).
|  +--------------+                   |
|                                     |
|  +-------------------------------+  |
|  |      +--------------+     <--------------Everything.
|  |      |Button     <-----------------------Everything except left-klick.
|  |      +--------------+         |  |
|  +-------------------------------+  |
+-------------------------------------+

Is this possible to do in Gtk? If it is, how?
TIA,
Egil

<A Href="http://www.tekmetrics.com/transcript.shtml?pid=29943">TekMetrics Online Public Transcript (e-certifications[tm])</A><Br>
<A Href="http://mini.dhs.org/PGP%20Public%20key.asc">PGP Public key</A><Br>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4LVVJHeQ6HSAJlUwRAjR+AJ4sgqcRBMchbiOPKEH5pdYHFy1RRwCeMf5T
OF34QKD/4i3YnToEHYojAz0=
=JG2z
-----END PGP SIGNATURE-----

From otaylor@redhat.com  Thu May 11 17:52:43 2000
Received: (qmail 31917 invoked from network); 15 Nov 1999 20:09:06 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 15 Nov 1999 20:09:06 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id PAA23818
	for <gtk-devel-list@redhat.com>; Mon, 15 Nov 1999 15:09:05 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id PAA07549;
	Mon, 15 Nov 1999 15:07:44 -0500
To: gtk-devel-list@redhat.com
Subject: Plans for drawing in GDK-1.4.
From: Owen Taylor <otaylor@redhat.com>
Date: 15 Nov 1999 15:07:44 -0500
Message-ID: <ybe66z38qnj.fsf@fresnel.labs.redhat.com>
Lines: 13
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


I've been recently planning some changes
to the draw/update model in GDK for 1.4. 

I've put a description of some of my plans at:

 http://www.gtk.org/~otaylor/gdk-1.4.html

I'd be interested in feedback people have on these
ideas.

Regards,
                                        Owen

From redhog@mini.dhs.org  Thu May 11 17:52:43 2000
Received: (qmail 8743 invoked from network); 15 Nov 1999 20:47:44 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 15 Nov 1999 20:47:44 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id PAA27225
	for <gtk-devel-list@redhat.com>; Mon, 15 Nov 1999 15:47:42 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id WAA25364
	for <gtk-devel-list@redhat.com>; Mon, 15 Nov 1999 22:14:08 +0100
Date: Mon, 15 Nov 1999 22:14:01 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: Ad-on hook idea
Message-ID: <Pine.LNX.4.10.9911152155030.19388-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Follows an idea of mine. Please critisize, extend and change! And please
tell me if this is something desired for Gtk!

 To enhance the look of Gtk, the theme system was created. This enables=20
users to easily change the look and feel of Gtk programs.
 The feature I am to describe implements something similar in
functionality: it adds an option for users to change, not the look and
feel, but the behaviour, of Gtk programs.
 From the user's view, she'l see a list of installed ad-ons, an uninstall=
=20
and an install button in some configure app (Perheaps in the gnomecc). She
may download a new add-on, and install it, and all programs immideately
changes their behaviour to include the functionality of the new add-on.
Examples of possible add-ons: Changes so that a user may scroll a=20
GtkScrolledWindow by klicking (with some user defined modifiers) and
moving inside the scrolled widget, so that menus dissapears and reappears
when the mouse leafes and reenters the window (What my GBlippie patch
does), etc.
 What is needed to be implemented? In order for an add-on to be able to
hook in its functionality, it needs to know when an object (Of any type)
is created (The rest of the functionality could easily be added as signal
handlers connected to the signals of the newly created object). This is
easiest achived, I think, by creating a global variable that holds an
object, that emits a signal whenever an object is created. WHen a program
is started, the add -ons installed are loaded as dynamically loadable
libraries, and their init function is run. That init function then
attaches some signal handler to that global object.
 This solution doesn't provide for the immediately change option, but at
leaste enables us to create some kind of add-ons. Please come up with a
better solution!
 What is this good for? The main reason for me coming up with this idea is
that I failed to get my SuperCool<TM> functionality hack into the Gtk
source tree. And I can understund the reason - the source should be cept
clean, and not implement a huge set of strange features that only a few
appreciates, or we will end up in some kind of enlightenment :)
 But of course some strange peoples (strange as in "like me") wants those
strange features. If this idea is implemented, they could just implement
their hacks as add-ons, and distribute them as separate programs, that do
not even depend on the version of Gtk (As a patch does), witout disturbing
the Gtk ftp admins with a huge load of unrelevant code, and without
cluttering the Pure GTk Code.
With best regards,
Egil m=F6ller

<A Href=3D"http://www.tekmetrics.com/transcript.shtml?pid=3D29943">TekMetri=
cs Online Public Transcript (e-certifications[tm])</A><Br>
<A Href=3D"http://mini.dhs.org/PGP%20Public%20key.asc">PGP Public key</A><B=
r>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4MHeeHeQ6HSAJlUwRApsAAKC9oCq8AMN9r5D2yMCCLxCE1HhWAwCgjQVY
aCnRKBPYvv8p7jlG/FB39nQ=3D
=3D6D0N
-----END PGP SIGNATURE-----

From dereks@kd-dev.com  Thu May 11 17:52:43 2000
Received: (qmail 20417 invoked from network); 15 Nov 1999 20:58:23 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 15 Nov 1999 20:58:23 -0000
Received: from archer.kd-dev.com (dereks@archer.kd-dev.com [206.124.150.175])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id PAA28314
	for <gtk-devel-list@redhat.com>; Mon, 15 Nov 1999 15:58:22 -0500
Received: from localhost (dereks@localhost)
	by archer.kd-dev.com (8.8.7/8.8.7) with ESMTP id MAA13319
	for <gtk-devel-list@redhat.com>; Mon, 15 Nov 1999 12:52:57 -0800
Date: Mon, 15 Nov 1999 12:52:57 -0800 (PST)
From: Derek Simkowiak <dereks@kd-dev.com>
cc: gtk-devel-list@redhat.com
Subject: OFF-TOPIC: gcc and comments
In-Reply-To: <Pine.LNX.4.10.9911152155030.19388-100000@mini.dhs.org>
Message-ID: <Pine.LNX.4.04.9911151249390.13317-100000@archer.kd-dev.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

    All,
	This is somewhat off topic, my apologies.  I just know somebody
here has the answer...

	I have just taken over a code base of C code that contains C++
style comments  // like this.

	I want to compile this with gcc, but it complains about the non-C 
comments.  Do I need to use g++, or can I make gcc recognize the //
comments somehow?

	Sorry about the stupid question.  I couldn't find anything about
this in the man page...


Thanks,
Derek

From otaylor@redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 210 invoked from network); 15 Nov 1999 21:12:13 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 15 Nov 1999 21:12:13 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA29632
	for <gtk-devel-list@redhat.com>; Mon, 15 Nov 1999 16:12:13 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id QAA07867;
	Mon, 15 Nov 1999 16:10:52 -0500
To: gtk-devel-list@redhat.com
Subject: Re: OFF-TOPIC: gcc and comments
References: <Pine.LNX.4.04.9911151249390.13317-100000@archer.kd-dev.com>
From: Owen Taylor <otaylor@redhat.com>
Date: 15 Nov 1999 16:10:52 -0500
In-Reply-To: Derek Simkowiak's message of "Mon, 15 Nov 1999 12:52:57 -0800 (PST)"
Message-ID: <ybewvrj795v.fsf@fresnel.labs.redhat.com>
Lines: 28
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Derek Simkowiak <dereks@kd-dev.com> writes:

>     All,
> 	This is somewhat off topic, my apologies.  I just know somebody
> here has the answer...
> 
> 	I have just taken over a code base of C code that contains C++
> style comments  // like this.
> 
> 	I want to compile this with gcc, but it complains about the non-C 
> comments.  Do I need to use g++, or can I make gcc recognize the //
> comments somehow?
> 
> 	Sorry about the stupid question.  I couldn't find anything about
> this in the man page...

This would be off-topic on gtk-list, or other lists about GTK+
programming. It is utterly off-topic here, which is about
the development of GTK+ itself.

Perhaps you are specifying the -ansi flag? Otherwise gcc does
accept such comments. Look at the info page for GCC.

Regards,
                                        Owen


From rodrigc@mediaone.net  Thu May 11 17:52:44 2000
Received: (qmail 11933 invoked from network); 15 Nov 1999 23:51:31 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 15 Nov 1999 23:51:31 -0000
Received: from dibbler.ne.mediaone.net (root@dibbler.ne.mediaone.net [24.218.56.16])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA09065
	for <gtk-devel-list@redhat.com>; Mon, 15 Nov 1999 18:51:28 -0500
Received: (from rodrigc@localhost)
	by dibbler.ne.mediaone.net (8.9.3/8.9.3) id SAA08533
	for gtk-devel-list@redhat.com; Mon, 15 Nov 1999 18:55:57 -0500
Date: Mon, 15 Nov 1999 18:55:57 -0500
From: Craig Rodrigues <rodrigc@mediaone.net>
To: gtk-devel-list@redhat.com
Subject: Who maintains libtool?
Message-ID: <19991115185557.A8526@mediaone.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i

Hi,

Does anyone know if libtool is actively being maintained?
I accessed their website at: http://www.gnu.org/software/libtool/libtool.html
but when I tried to subscribe to their mailing list, I didn't get
back any responses.  I wanted to report some of the problems
I had with libtool under AIX, and since libtool is an integral
part of building GTK, I thought someone on this list would know.

Thanks.
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

From J.A.K.Mouw@its.tudelft.nl  Thu May 11 17:52:44 2000
Received: (qmail 13194 invoked from network); 16 Nov 1999 08:52:58 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 08:52:58 -0000
Received: from duteinh.et.tudelft.nl (duteinh.et.tudelft.nl [130.161.42.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id DAA20717
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 03:52:58 -0500
Received: from dutein71 by duteinh.et.tudelft.nl (8.9.3/BB-2.0)
	id JAA01977; Tue, 16 Nov 1999 09:52:56 +0100 (MET)
Date: Tue, 16 Nov 1999 09:52:56 +0100 (MET)
Message-Id: <199911160852.JAA01977@duteinh.et.tudelft.nl>
From: Erik Mouw <J.A.K.Mouw@its.tudelft.nl>
To: gtk-devel-list@redhat.com
Subject: Re: Who maintains libtool?
In-Reply-To: <19991115185557.A8526@mediaone.net>
Organization: Eric conspiracy secret labs
X-Face: "!Z|1XjFg!3Iw)BwM^M\k)J5KHiPddz}#/Zw%?$&Q!xqob"OA|})3_@&BTTiQERo?/^g[Z<9P4R8:5C:aqq.cw!hotLc=+u-"+1rq@9$V^8PbOUlodyi_sejt+D`iqkLpx$>.aXl%vnfPIt"LK|/%>94_Zrm8jy?`_[RKt'TuoxUxfk(gMhY(n|DBBl~c$dhO>G%6}R4+DGX3|idBm4oU&UM/XUP4I9aoN{]`ax%B?rgD(I3OJ<62Y6L
X-Mailer: XCmail 0.99.6 - with PGP support, PGP engine version 0.5
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
X-Eric-Conspiracy: There is no conspiracy!
X-Loop: erik@it.et.tudelft.nl
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

On Mon, 15 Nov 1999 18:55:57 -0500, Craig Rodrigues wrote:
> Does anyone know if libtool is actively being maintained?

Yes.

> I accessed their website at: http://www.gnu.org/software/libtool/libtool.html
> but when I tried to subscribe to their mailing list, I didn't get
> back any responses.  I wanted to report some of the problems
> I had with libtool under AIX, and since libtool is an integral
> part of building GTK, I thought someone on this list would know.

The libtool mailing list as active as the gtk-devel mailing list (low
volume), the last message is dated November 5.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2785859  Fax: +31-15-2781843  Email J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/


From dave@dccs.com.au  Thu May 11 17:52:44 2000
Received: (qmail 30078 invoked from network); 16 Nov 1999 11:38:21 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 11:38:21 -0000
Received: from term1.dccs.com.au (root@davidc1.lnk.telstra.net [139.130.52.223])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id GAA31287
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 06:38:19 -0500
Received: from devel.dccs.com.au (root@devel.dccs.com.au [203.16.37.2])
	by term1.dccs.com.au (8.9.3/8.9.3/Debian/GNU) with ESMTP id WAA24558
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 22:38:09 +1100
Received: from devel.dccs.com.au (dave@localhost [127.0.0.1])
	by devel.dccs.com.au (8.9.3/8.9.3/Debian/GNU) with ESMTP id WAA05347
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 22:39:45 +1100
Sender: dave@dccs.com.au
To: gtk-devel-list@redhat.com
Subject: Re: Plans for drawing in GDK-1.4.
References: <ybe66z38qnj.fsf@fresnel.labs.redhat.com>
From: Dave Cole <dave@dccs.com.au>
Date: 16 Nov 1999 22:39:45 +1100
In-Reply-To: Owen Taylor's message of "15 Nov 1999 15:07:44 -0500"
Message-ID: <m3zowe4qda.fsf@devel.dccs.com.au>
Lines: 21
User-Agent: Gnus/5.070096 (Pterodactyl Gnus v0.96) Emacs/20.3
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

>>>>> "Owen" == Owen Taylor <otaylor@redhat.com> writes:

Owen> I've been recently planning some changes to the draw/update
Owen> model in GDK for 1.4.

Owen> I've put a description of some of my plans at:

Owen>  http://www.gtk.org/~otaylor/gdk-1.4.html

Owen> I'd be interested in feedback people have on these ideas.

I read through the document and it looks quite good.  I have done a
bit of Windows programming with their version of flicker free updates
and I do not envy your task.

In my experience of Windows, there are ways to cause buggy
interactions between the dirty region and window scrolling.  Their
flashing software caret is another thing that buggers up...

- Dave


From sd90034@lanet.lv  Thu May 11 17:52:44 2000
Received: (qmail 3423 invoked from network); 16 Nov 1999 11:53:13 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 11:53:13 -0000
Received: from ieva06.lanet.lv (ieva06.lanet.lv [195.13.129.106])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id GAA31963
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 06:52:58 -0500
Received: from ieva01.lanet.lv (ieva01 [195.13.129.101])
	by ieva06.lanet.lv (8.9.3/8.9.1) with ESMTP id NAA31514
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 13:39:18 +0200
Received: from localhost (sd90034@localhost)
	by ieva01.lanet.lv (8.9.3/8.9.0) with ESMTP id NAA76434
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 13:39:15 +0200
X-Authentication-Warning: ieva01.lanet.lv: sd90034 owned process doing -bs
Date: Tue, 16 Nov 1999 13:39:15 +0200 (WET)
From: Alexander Piskunov <sd90034@lanet.lv>
To: gtk-devel-list@redhat.com
Subject: Re: Plans for drawing in GDK-1.4.
In-Reply-To: <ybe66z38qnj.fsf@fresnel.labs.redhat.com>
Message-ID: <Pine.A41.4.05.9911161229150.223268-100000@ieva01.lanet.lv>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On 15 Nov 1999, Owen Taylor wrote:

> 
> I've been recently planning some changes
> to the draw/update model in GDK for 1.4. 
> 
> I've put a description of some of my plans at:
> 
>  http://www.gtk.org/~otaylor/gdk-1.4.html
> 
> I'd be interested in feedback people have on these
> ideas.

This is what I always wanted to see in GTK+.
Today opaque resize is completely unusable on my Pentium 120, S3 V+, but
when I switch to Win95, difference is _very_ noticeable. I don't know if
Win9x toolkit uses backing pixmap, but opaque resize is _much_ faster.
The same goes for expose/redraw events.
So using offscreen drawing is definitely a very good idea:)

AlexP

From Elliott.Hughes@genedata.com  Thu May 11 17:52:44 2000
Received: (qmail 2711 invoked from network); 16 Nov 1999 12:25:06 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 12:25:06 -0000
Received: from mail.core.genedata.com (mentolat-e0.core.genedata.com [157.161.173.16])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id HAA00976
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 07:25:05 -0500
Received: from relay.core.genedata.com (nila-e0.core.genedata.com [157.161.173.44])
	by mail.core.genedata.com (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dAGCP3d32600
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 13:25:04 +0100
Received: from relay.ch.genedata.com (pinatubo-e0.ch.genedata.com [157.161.173.48])
	by relay.core.genedata.com (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dAGCP3214870
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 13:25:03 +0100
Received: from stromboli (enh@stromboli.ch.genedata.com [157.161.173.81])
	by relay.ch.genedata.com (8.9.3/8.9.3) with SMTP id NAA1208406
	for gtk-devel-list@redhat.com; Tue, 16 Nov 1999 13:25:02 +0100 (CET)
Date: Tue, 16 Nov 1999 13:25:02 +0100 (CET)
Message-Id: <199911161225.NAA1208406@relay.ch.genedata.com>
From: Elliott Hughes <Elliott.Hughes@genedata.com>
To: gtk-devel-list@redhat.com
Subject: Re: Plans for drawing in GDK-1.4.

Alexander Piskunov <sd90034@lanet.lv> wrote:
> This is what I always wanted to see in GTK+.
> Today opaque resize is completely unusable on my Pentium 120, S3 V+, but
> when I switch to Win95, difference is _very_ noticeable. I don't know if
> Win9x toolkit uses backing pixmap, but opaque resize is _much_ faster.
> The same goes for expose/redraw events.
> So using offscreen drawing is definitely a very good idea:)

i'm not sure this is the reason. a lot of Windows stuff i've seen doesn't
actually resize the contents of the window until the user finishes resizing
the window frame.

whatever, low-level support for double-buffered drawing is long overdue.
the change to gint coordinates makes sense too. from my point of view,
the scrolling changes are less of a priority, and problems there should be
ameliorated at least in part by double-buffering.

i'm not sure i'd have the two suggested routines, though. why not have
this done by default, with a flag to turn it off, rather than make it
necessary for people to explicitly use double-buffering?

on the subject of scrolling, will the set_scroll_adjustments stuff go into
GtkWidget? that would be nice.

-- 
"As the Chinese say, 1001 words is worth more than a picture."
	-- John McCarthy

From sandmann@daimi.au.dk  Thu May 11 17:52:44 2000
Received: (qmail 27731 invoked from network); 16 Nov 1999 14:19:14 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 14:19:14 -0000
Received: from vertigo.daimi.au.dk (vertigo.daimi.au.dk [130.225.19.42])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id JAA08192
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 09:19:13 -0500
Received: (from sandmann@localhost)
	by vertigo.daimi.au.dk (8.9.3/8.9.3) id PAA8209581;
	Tue, 16 Nov 1999 15:19:12 +0100 (MET)
Sender: sandmann@daimi.au.dk
To: gtk-devel-list@redhat.com
Subject: GQueue
References: <199911082036.MAA04364@sequoia.ece.ucdavis.edu> <38283329.D6D2551A@udmnet.ru> <ybeogd3r8i1.fsf@fresnel.labs.redhat.com>
From: Soeren Sandmann <sandmann@daimi.au.dk>
Date: 16 Nov 1999 15:19:12 +0100
In-Reply-To: Owen Taylor's message of "09 Nov 1999 10:26:46 -0500"
Message-ID: <ye8ln7yecyn.fsf_-_@vertigo.daimi.au.dk>
Lines: 22
User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Owen Taylor <otaylor@redhat.com> writes:

> GLib-1.3 already includes a GQueue data structure which does
> this.

I have a few problems with the GQueue from 1.3.

(a) It is not opaque. I think data structures almost always should be
    opaque.

(b) The names of the operations are different from those of GList's
    and GSList's.

(c) Its set of operation is not as complete as GS?List's.

(d) Since it supports adding and deleting in both ends, it should be
    called a GDeque.

(e) It would be easy to replace it with a priority queue supporting
    not only O(1) inserting and removing from the ends, but also
    O(log n) sorted inserting. Well, perhaps not easy, but at least
    not very difficult.

From wilhelmi@ira.uka.de  Thu May 11 17:52:44 2000
Received: (qmail 11827 invoked from network); 16 Nov 1999 14:45:07 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 14:45:07 -0000
Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id JAA09858
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 09:45:07 -0500
Received: from i80fs2.ira.uka.de [129.13.18.2] by iraun1 with SMTP (PP) local;
          Tue, 16 Nov 1999 15:44:45 +0100
Received: from ira.uka.de [129.13.18.174] (actually i81pc4) by i8fs1 
          with SMTP (PP); Tue, 16 Nov 1999 15:44:42 +0100
Sender: wilhelmi@ira.uka.de
Message-ID: <38316DDB.B6100D11@ira.uka.de>
Date: Tue, 16 Nov 1999 14:44:43 +0000
From: Sebastian Wilhelmi <wilhelmi@ira.uka.de>
Organization: IRF Uni Karlsruhe
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.10 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Proposal: g_set_out_of_mem_handler
Content-Type: multipart/mixed; boundary="------------F109EA16017D35D33CD3F373"

This is a multi-part message in MIME format.
--------------F109EA16017D35D33CD3F373
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, all

We recently had a discussion on orbit-list about the current fail at "out=
 of
memory" behaviour of GLib. While I still think, out of memory can in gene=
ral
not be handled sane, we might as well add a hook to be called whenever Gl=
ib
find itself out of mem. For the greatest possible generality this routine=
 only
have to return a pointer to the requested memory, thus this memory can be=

taken from a preallocated place in memory, and now comes the clue: gmem.c=

keeps a list of pointers, that are obtained that way. This list is normal=
ly
empty (almost no overhead in testing it) and if not empty every freed mem=
ory
is testet against that list and if contained freed with another callback.=
 That
way you can preallocate, say, 500 KB and whenever an "out of mem" occurs =
you
just give out the requested memory and be fine. (and hope, XLib will not =
try
allocate memory, that is ;-). That might actually work, is not much overh=
ead
and will at least save us from more and more questions regarding that. I
appended a sample implementation. Its not yet fully testet, but should
actually work. Then you could do something like:

#define SIZE 100000
static int mem_count =3D 0; /* whenever this is not zero, we are in some
                             kind of trouble */

gpointer my_malloc(gulong size)
{
  static long mem[SIZE]; /* It's long for alignment reasons */
  static gunit next_free_index =3D 0;
  gpointer ret_val;

  if (mem_count=3D=3D0) /* No emergency till now */
    next_free_index =3D 0;

  ret_val =3D &mem[next_free_index];

  next_free_index +=3D (size - 1) % sizeof (long) + 1;

  if (next_free_index > SIZE)
    return NULL; /* Oops; fatal */

  mem_count++;

  return ret_val;
}

gpointer my_free(gpointer mem, gulong size)
{
  mem_count--; /* This is a very unsophisticated memory handler, but
                  anyway it works */
}

main()
{
  g_set_out_of_mem_handler (my_malloc, my_free);
}

BTW.: Now, that we have memprof (Great work...), isn't it about time to r=
emove
some of that memory profiling in GLib. Its really looking ugly and I doub=
t,
anybody use it...

Bye,
Sebastian
-- =

Sebastian Wilhelmi                   |            h=E4r ovanf=F6r alla mo=
lnen
mailto:wilhelmi@ira.uka.de           |     =E4r himmlen s=E5 f=F6runderli=
gt bl=E5
http://goethe.ira.uka.de/~wilhelmi   |
--------------F109EA16017D35D33CD3F373
Content-Type: text/plain; charset=us-ascii;
 name="glib.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="glib.diff"

Index: glib.h
===================================================================
RCS file: /cvs/gnome/glib/glib.h,v
retrieving revision 1.148
diff -u -b -B -r1.148 glib.h
--- glib.h	1999/11/16 10:30:25	1.148
+++ glib.h	1999/11/16 14:38:23
@@ -1453,6 +1453,14 @@
 
 /* Memory allocation and debugging
  */
+
+typedef gpointer	(*GOutOfMemMallocFunc) (gulong   size);
+typedef void		(*GOutOfMemFreeFunc)   (gpointer mem,
+					        gulong   size);
+
+void    g_set_out_of_mem_handler (GOutOfMemMallocFunc new_malloc, 
+				  GOutOfMemFreeFunc   new_free);
+
 #ifdef USE_DMALLOC
 
 #define g_malloc(size)	     ((gpointer) MALLOC (size))
Index: gmem.c
===================================================================
RCS file: /cvs/gnome/glib/gmem.c,v
retrieving revision 1.16
diff -u -b -B -r1.16 gmem.c
--- gmem.c	1999/09/17 09:02:48	1.16
+++ gmem.c	1999/11/16 14:38:23
@@ -150,6 +150,72 @@
 
 #ifndef USE_DMALLOC
 
+static GOutOfMemMallocFunc     out_of_mem_malloc = NULL;
+static GOutOfMemFreeFunc       out_of_mem_free   = NULL;
+
+typedef struct _OutOfMemHeader OutOfMemHeader;
+struct _OutOfMemHeader
+{
+  OutOfMemHeader *next;
+  gulong size;
+};
+
+static OutOfMemHeader *first_out_of_mem_allocation = NULL;
+
+void    
+g_set_out_of_mem_handler (GOutOfMemMallocFunc new_malloc, 
+			  GOutOfMemFreeFunc   new_free)
+{
+  out_of_mem_malloc = new_malloc;
+  out_of_mem_free = out_of_mem_malloc ? new_free : NULL;
+}
+
+static gpointer
+g_out_of_mem_malloc (gulong size)
+{
+  OutOfMemHeader *mem;
+  gulong needed_size = size + sizeof (OutOfMemHeader); 
+
+  if (!out_of_mem_malloc || !(mem = out_of_mem_malloc (needed_size)))
+    {
+      g_error ("could not allocate %ld bytes", size);
+      return NULL; /* Just to make gcc -Wall happy, will not be reached */
+    }
+
+  mem->next = first_out_of_mem_allocation;
+  mem->size = needed_size;
+  first_out_of_mem_allocation = mem;
+
+  return ((gpointer)mem) + sizeof (OutOfMemHeader); 
+}
+
+static void
+g_out_of_mem_free (gpointer mem)
+{
+  OutOfMemHeader *header = mem - sizeof (OutOfMemHeader);
+  OutOfMemHeader **last_next_pointer = &first_out_of_mem_allocation;
+  gulong size;
+
+  while (*last_next_pointer != NULL && (*last_next_pointer) != header)
+    last_next_pointer = &((*last_next_pointer)->next);
+
+  if (*last_next_pointer == NULL)
+    {
+      /* This mem was not allocated while "out of mem" */
+      free(mem);
+      return;
+    }
+    
+  if (!out_of_mem_free)
+    /* Just ignore it */
+    return;
+
+  size = (*last_next_pointer)->size;
+  (*last_next_pointer) = (*last_next_pointer)->next;
+
+  out_of_mem_free (mem, size);
+}
+
 gpointer
 g_malloc (gulong size)
 {
@@ -176,7 +242,7 @@
   
   p = (gpointer) malloc (size);
   if (!p)
-    g_error ("could not allocate %ld bytes", size);
+    p = g_out_of_mem_malloc (size);
   
   
 #ifdef ENABLE_MEM_CHECK
@@ -241,7 +307,10 @@
   
   p = (gpointer) calloc (size, 1);
   if (!p)
-    g_error ("could not allocate %ld bytes", size);
+    {
+      p = g_out_of_mem_malloc (size);
+      memset(p, 0, size);
+    }
   
   
 #ifdef ENABLE_MEM_CHECK
@@ -315,6 +384,8 @@
 #else /* !REALLOC_0_WORKS */
       p = (gpointer) malloc (size);
 #endif /* !REALLOC_0_WORKS */
+      if (!p)
+	p = g_out_of_mem_malloc (size);
     }
   else
     {
@@ -334,13 +405,26 @@
 	g_warning ("trying to realloc freed memory\n");
       mem = t;
 #endif /* ENABLE_MEM_CHECK */
-      
+      if (!first_out_of_mem_allocation)
+	{
       p = (gpointer) realloc (mem, size);
+	  if (!p)
+	    {
+	      p = g_out_of_mem_malloc (size);
+	      g_memmove (p, mem, size);
+	      free (mem);
     }
   
+	}
+      else
+	{
+	  p = (gpointer) malloc (size);
   if (!p)
-    g_error ("could not reallocate %lu bytes", (gulong) size);
-  
+	    p = g_out_of_mem_malloc (size);
+	  g_memmove (p, mem, size);
+	  g_out_of_mem_free (mem);
+	}
+    }
   
 #ifdef ENABLE_MEM_CHECK
   size -= SIZEOF_LONG;
@@ -408,7 +492,11 @@
       
       memset ((guchar*) mem + 8, 0, size);
 #else /* ENABLE_MEM_CHECK */
+      if(!first_out_of_mem_allocation)
       free (mem);
+      else
+	g_out_of_mem_free (mem);
+      
 #endif /* ENABLE_MEM_CHECK */
     }
 }


--------------F109EA16017D35D33CD3F373--

From sandmann@daimi.au.dk  Thu May 11 17:52:44 2000
Received: (qmail 32465 invoked from network); 16 Nov 1999 14:58:23 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 14:58:23 -0000
Received: from bradbury.daimi.au.dk (bradbury.daimi.au.dk [130.225.19.219])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id JAA10926
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 09:58:21 -0500
Received: (from sandmann@localhost)
	by bradbury.daimi.au.dk (8.9.3/8.9.3) id PAA354560;
	Tue, 16 Nov 1999 15:58:20 +0100 (MET)
Sender: sandmann@daimi.au.dk
To: gtk-devel-list@redhat.com
Subject: Re: GQueue
References: <199911082036.MAA04364@sequoia.ece.ucdavis.edu> <38283329.D6D2551A@udmnet.ru> <ybeogd3r8i1.fsf@fresnel.labs.redhat.com> <ye8ln7yecyn.fsf_-_@vertigo.daimi.au.dk>
From: Soeren Sandmann <sandmann@daimi.au.dk>
Date: 16 Nov 1999 15:58:18 +0100
In-Reply-To: Soeren Sandmann's message of "16 Nov 1999 15:19:12 +0100"
Message-ID: <ye8ln7yiiut.fsf@bradbury.daimi.au.dk>
Lines: 8
User-Agent: Gnus/5.070098 (Pterodactyl Gnus v0.98) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Soeren Sandmann <sandmann@daimi.au.dk> writes:

> (e) It would be easy to replace it with a priority queue supporting
>     not only O(1) inserting and removing from the ends, but also

That is nonsense. What meant was: it is easy to create thin wrappers
around a priority queue that will behave like a stack or a queue with
O(1) inserting and removing.

From wilhelmi@ira.uka.de  Thu May 11 17:52:44 2000
Received: (qmail 1020 invoked from network); 16 Nov 1999 14:59:19 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 14:59:19 -0000
Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id JAA11025
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 09:59:18 -0500
Received: from i80fs2.ira.uka.de [129.13.18.2] by iraun1 with SMTP (PP) local;
          Tue, 16 Nov 1999 15:58:54 +0100
Received: from ira.uka.de [129.13.18.174] (actually i81pc4) by i8fs1 
          with SMTP (PP); Tue, 16 Nov 1999 15:58:40 +0100
Sender: wilhelmi@ira.uka.de
Message-ID: <38317121.CE099DAF@ira.uka.de>
Date: Tue, 16 Nov 1999 14:58:41 +0000
From: Sebastian Wilhelmi <wilhelmi@ira.uka.de>
Organization: IRF Uni Karlsruhe
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.10 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Proposal: GLib tests.
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, all

Two proposals:

1. Either when doing "make" or "make install", the Makefile should also
   do a "make check". Otherwise there might exist GLib installations
   somewhere out there, that just dont work.

2. Remove testglib.c and testgdate.c (already covered by tests/*) and
   convert testgdateparser.c and gmodule/gtestmodule.c to
   tests/date-parser-test.c and tests/module-test.c resp. (I would do
   that, if there is some consensus)

Bye,
Sebastian
-- =

Sebastian Wilhelmi                   |            h=E4r ovanf=F6r alla mo=
lnen
mailto:wilhelmi@ira.uka.de           |     =E4r himmlen s=E5 f=F6runderli=
gt bl=E5
http://goethe.ira.uka.de/~wilhelmi   |

From hp@redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 19719 invoked from network); 16 Nov 1999 15:16:48 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 15:16:48 -0000
Received: from icon.labs.redhat.com (root@icon.labs.redhat.com [207.175.42.144])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id KAA12457
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 10:16:48 -0500
Received: from localhost (hp@localhost)
	by icon.labs.redhat.com (8.9.3/8.9.3) with ESMTP id KAA04690
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 10:14:00 -0500
X-Authentication-Warning: icon.labs.redhat.com: hp owned process doing -bs
Date: Tue, 16 Nov 1999 10:14:00 -0500 (EST)
From: Havoc Pennington <hp@redhat.com>
X-Sender: hp@icon.labs.redhat.com
To: gtk-devel-list@redhat.com
Subject: Re: Proposal: g_set_out_of_mem_handler
In-Reply-To: <38316DDB.B6100D11@ira.uka.de>
Message-ID: <Pine.LNX.4.10.9911161012010.4579-100000@icon.labs.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hi,

I agree that we should go for the out of mem handler because:

 - it will use only a few bytes; one global function pointer, one 
   function to set that pointer, one default handler that calls abort()
 - it will make lots of people feel better, and who knows, may genuinely 
   be useful in some cases

Havoc



From redhog@mini.dhs.org  Thu May 11 17:52:44 2000
Received: (qmail 14908 invoked from network); 16 Nov 1999 16:24:00 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 16:24:00 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id LAA17655
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 11:23:59 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id RAA02142
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 17:50:23 +0100
Date: Tue, 16 Nov 1999 17:50:22 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: Re: Ad-on hook idea (fwd)
Message-ID: <Pine.LNX.4.10.9911161749130.2120-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

Oups, Alexander wrote the wrong adress (He said that to me in a later
letter):

Date: Tue, 16 Nov 1999 13:49:31 +0200 (WET)
From: Alexander Piskunov <sd90034@lanet.lv>
To: Egil M=F6ller <redhog@lysator.liu.se>
Subject: Re: Ad-on hook idea



On Mon, 15 Nov 1999 redhog@mini.dhs.org wrote:

>  The feature I am to describe implements something similar in
> functionality: it adds an option for users to change, not the look and
> feel, but the behaviour, of Gtk programs.

I like this idea. Im currently messed up with MS Intellimouse scroll wheel
behaviour under GTK+. When I scroll wheel in AbiWord,it crashes, some
widget behave incorrectly too, when event with button 4 or 5 is emitted.
Many people never use mouse with wheel, so it is better not to mess this
code with main source, but make it as plugin, as Egil describes. Main
source should be free of various bells&whistles.

AlexP

From redhog@mini.dhs.org  Thu May 11 17:52:44 2000
Received: (qmail 27412 invoked from network); 16 Nov 1999 16:36:25 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 16:36:25 -0000
Received: from mini.dhs.org (root@a37.ryd.student.liu.se [130.236.232.37])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id LAA18638
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 11:36:24 -0500
From: redhog@mini.dhs.org
Received: from localhost (redhog@localhost)
	by mini.dhs.org (8.9.3/8.9.3) with ESMTP id SAA02198
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 18:02:48 +0100
Date: Tue, 16 Nov 1999 18:02:42 +0100 (CET)
Reply-To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
To: gtk-devel-list@redhat.com
Subject: Re: Ad-on hook idea (fwd)
In-Reply-To: <Pine.LNX.4.10.9911161749130.2120-100000@mini.dhs.org>
Message-ID: <Pine.LNX.4.10.9911161753190.2158-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While someone pointed out there is allready a module functionality in
place, there is not simple user interface for it, and no repository of
such plug-ins as there is for themes (gtk.themes.org). I've checked out
hacks.org, and it's unregistered. Somone wants to register and create such
a repository? I am unable to register one for my own computer, due to
restrictions from my ISP... But I'l gladly helping manage such a web-site!
In addition, if it is desirable, I'l create such a user front end as a
gnomecc plug-in (That modifies the .bashrc to set the GTK_MODULE env.
variable to what the users wants).

When it comes to the wheel-scrolling thing, I have a little problem - I
want _every_ button press/move/release that vis not used for something
else for a the widget inside the scrolledwindow widget, to scroll the
scrolledwindow widget. But I don't know how to get the knowledge of if
some event has been used allready. If someone could help me with this, I
would be ready with such a module in a few days!

Last, a question about the module system: Is it possible to create a
library call that Gtk programs could do to the module, that just returns
an error message if that module isn't loaded, and that calls some function
inside the module if it is loaded? Is there such a call allready?
With best regards,
Egil M=F6ller

<A Href=3D"http://www.tekmetrics.com/transcript.shtml?pid=3D29943">TekMetri=
cs Online Public Transcript (e-certifications[tm])</A><Br>
<A Href=3D"http://mini.dhs.org/PGP%20Public%20key.asc">PGP Public key</A><B=
r>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.9 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4MY43HeQ6HSAJlUwRAkX+AJ42qspaJE0yhb7t0hsLDWOjTEweGQCdGZwL
fz2b71gWeDgupe4QJVN7GqM=3D
=3DjnHS
-----END PGP SIGNATURE-----

From kaz@FootPrints.net  Thu May 11 17:52:44 2000
Received: (qmail 2888 invoked from network); 16 Nov 1999 16:47:30 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 16:47:30 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id LAA19449
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 11:47:29 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11nllQ-0005KL-00
	for gtk-devel-list@redhat.com; Tue, 16 Nov 1999 08:47:28 -0800
Date: Tue, 16 Nov 1999 08:47:28 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
Subject: Re: Proposal: g_set_out_of_mem_handler
In-Reply-To: <Pine.LNX.4.10.9911161012010.4579-100000@icon.labs.redhat.com>
Message-ID: <Pine.LNX.4.10.9911160839380.20274-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Tue, 16 Nov 1999, Havoc Pennington wrote:

> Date: Tue, 16 Nov 1999 10:14:00 -0500 (EST)
> From: Havoc Pennington <hp@redhat.com>
> Reply-To: gtk-devel-list@redhat.com
> To: gtk-devel-list@redhat.com
> Subject: Re: Proposal: g_set_out_of_mem_handler
> Resent-Date: 16 Nov 1999 15:16:48 -0000
> Resent-From: gtk-devel-list@redhat.com
> Resent-cc: recipient list not shown: ;
> 
> 
> Hi,
> 
> I agree that we should go for the out of mem handler because:
> 
>  - it will use only a few bytes; one global function pointer, one 
>    function to set that pointer, one default handler that calls abort()
>  - it will make lots of people feel better, and who knows, may genuinely 
>    be useful in some cases

I think that this technique is pretty gross. Why not implement some kind of
exception handling instead? I've been working on a small exception handling
library which which is written in portable C and gives you things like: nested
try-catch regions which specify a list of what they catch; exceptions that have
code and group ID's so groups of exceptions can be caught as well as specific
exceptions; clean-up handlers for releasing resources during unwinding; passage
of arbitrary dynamic data from throw to catch site, etc.  With POSIX thread
support enabled, each thread has its own exception stack context, including its
own own allocator routines and unhandled exception catcher.

From otaylor@redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 15838 invoked from network); 16 Nov 1999 17:07:44 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 17:07:44 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA20974
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 12:07:44 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id MAA17642;
	Tue, 16 Nov 1999 12:06:18 -0500
To: gtk-devel-list@redhat.com
Subject: Re: Proposal: GLib tests.
References: <38317121.CE099DAF@ira.uka.de>
From: Owen Taylor <otaylor@redhat.com>
Date: 16 Nov 1999 12:06:18 -0500
In-Reply-To: Sebastian Wilhelmi's message of "Tue, 16 Nov 1999 14:58:41 +0000"
Message-ID: <ybe66z274dx.fsf@fresnel.labs.redhat.com>
Lines: 32
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Sebastian Wilhelmi <wilhelmi@ira.uka.de> writes:

> Hi, all
> 
> Two proposals:
> 
> 1. Either when doing "make" or "make install", the Makefile should also
>    do a "make check". Otherwise there might exist GLib installations
>    somewhere out there, that just dont work.

 - This slows down building.
 - I don't know any other packages that automatically do tests
   (including some with very complete test suites, such as Perl or gcc)
 - We'd have to make the g_log tests say:

   HEY! DON'T SUBMIT A BUG REPORT ABOUT THE FOLLOWING!

But in general, I don't think it is necessary. It's not like it is
typical for GLib to be broken in subtle ways.
 
> 2. Remove testglib.c and testgdate.c (already covered by tests/*) and
>    convert testgdateparser.c and gmodule/gtestmodule.c to
>    tests/date-parser-test.c and tests/module-test.c resp. (I would do
>    that, if there is some consensus)

I have no particular feelings about this one way or the other.

Regards,
                                        Owen


From wilhelmi@ira.uka.de  Thu May 11 17:52:44 2000
Received: (qmail 19946 invoked from network); 16 Nov 1999 17:17:26 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 17:17:26 -0000
Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id MAA21460
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 12:17:15 -0500
Received: from i80fs2.ira.uka.de [129.13.18.2] by iraun1 with SMTP (PP) local;
          Tue, 16 Nov 1999 18:16:54 +0100
Received: from ira.uka.de [129.13.18.174] (actually i81pc4) by i8fs1 
          with SMTP (PP); Tue, 16 Nov 1999 18:16:52 +0100
Sender: wilhelmi@ira.uka.de
Message-ID: <38319184.9C925EC6@ira.uka.de>
Date: Tue, 16 Nov 1999 17:16:52 +0000
From: Sebastian Wilhelmi <wilhelmi@ira.uka.de>
Organization: IRF Uni Karlsruhe
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.10 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: Proposal: GLib tests.
References: <38317121.CE099DAF@ira.uka.de> <ybe66z274dx.fsf@fresnel.labs.redhat.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, Owen

> > Hi, all
> >
> > Two proposals:
> >
> > 1. Either when doing "make" or "make install", the Makefile should
> >    also
> >    do a "make check". Otherwise there might exist GLib installations
> >    somewhere out there, that just dont work.
> =

>  - This slows down building.

Yes, but not much.

>  - I don't know any other packages that automatically do tests
>    (including some with very complete test suites, such as Perl or gcc)=


Yes, but there it would slow down the whole thing much. Here it only is
something like 30 seconds.

>  - We'd have to make the g_log tests say:
> =

>    HEY! DON'T SUBMIT A BUG REPORT ABOUT THE FOLLOWING!

The tests for 'make check' are not supposed to print anything, so we woul=
d
automatically get rid of those bug reports too ;-)
 =

> But in general, I don't think it is necessary. It's not like it is
> typical for GLib to be broken in subtle ways.

I would say, that there are some sublte ways, that GLib could fail. I onc=
e got
a bug report regarding the G_MAXLONG etc. macros, that only showed up bec=
ause
of such a test and especially such things will make error detection for t=
he
user of software, that uses GLib, very hard.
 =

Bye,
Sebastian
-- =

Sebastian Wilhelmi                   |            h=E4r ovanf=F6r alla mo=
lnen
mailto:wilhelmi@ira.uka.de           |     =E4r himmlen s=E5 f=F6runderli=
gt bl=E5
http://goethe.ira.uka.de/~wilhelmi   |

From otaylor@redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 2322 invoked from network); 16 Nov 1999 17:40:33 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 17:40:33 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA23017
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 12:40:33 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id MAA17750;
	Tue, 16 Nov 1999 12:39:07 -0500
To: gtk-devel-list@redhat.com
Subject: Re: Plans for drawing in GDK-1.4.
References: <199911161225.NAA1208406@relay.ch.genedata.com>
From: Owen Taylor <otaylor@redhat.com>
Date: 16 Nov 1999 12:39:07 -0500
In-Reply-To: Elliott Hughes's message of "Tue, 16 Nov 1999 13:25:02 +0100 (CET)"
Message-ID: <ybeyaby5oas.fsf@fresnel.labs.redhat.com>
Lines: 61
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Elliott Hughes <Elliott.Hughes@genedata.com> writes:

> Alexander Piskunov <sd90034@lanet.lv> wrote:
> > This is what I always wanted to see in GTK+.
> > Today opaque resize is completely unusable on my Pentium 120, S3 V+, but
> > when I switch to Win95, difference is _very_ noticeable. I don't know if
> > Win9x toolkit uses backing pixmap, but opaque resize is _much_ faster.
> > The same goes for expose/redraw events.
> > So using offscreen drawing is definitely a very good idea:)
> 
> i'm not sure this is the reason. a lot of Windows stuff i've seen doesn't
> actually resize the contents of the window until the user finishes resizing
> the window frame.
> 
> whatever, low-level support for double-buffered drawing is long overdue.
> the change to gint coordinates makes sense too. from my point of view,
> the scrolling changes are less of a priority, and problems there should be
> ameliorated at least in part by double-buffering.

How does this help? Double buffering wouldn't decrease the amount
of time until the newly scrolled-in areas are updated as far
as I can see.
 
> i'm not sure i'd have the two suggested routines, though. why not have
> this done by default, with a flag to turn it off, rather than make it
> necessary for people to explicitly use double-buffering?

Well, I don't really see how to do this. You would need an "end_paint"
in any case to know when to copy the back-buffer onto the window;
and besides that you would have to track the changed regions or
copy the whole pixmap every time. And also, the begin_paint / end_paint
saves memory since you don't have to always keep a backing-pixmap
for each window around.

At the widget level double-buffering will appear to be automatic,
since GTK+ will do the begin_paint / end_paint around handling
an expose event.
 
> on the subject of scrolling, will the set_scroll_adjustments stuff go into
> GtkWidget? that would be nice.

Just because there is a scroll-window call doesn't mean that scrolling
is generic. A widget would have to keep track of the coordinate
offsets. Also, scrolleable widgets will want to be able to do things
like GtkCList which scrolls the titles horizontally, but not
vertically.

The whole point of not putting set_scroll_adjustments into GtkWidget
was to avoid bloating the GtkWidget interface with yet more signals.

Adding support for interfaces to GtkObject is still in the plans
for 1.4, and set_scroll_adjustments is a prime target for making
an interface.

Regards,
                                        Owen




From kenelson@ece.ucdavis.edu  Thu May 11 17:52:44 2000
Received: (qmail 1408 invoked from network); 16 Nov 1999 22:11:09 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 22:11:09 -0000
Received: from sequoia.ece.ucdavis.edu (root@sequoia.ece.ucdavis.edu [169.237.32.12])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id RAA13228
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 17:11:08 -0500
Received: from sequoia.ece.ucdavis.edu (kenelson@localhost [127.0.0.1])
	by sequoia.ece.ucdavis.edu (8.9.3/8.9.3) with ESMTP id OAA00779;
	Tue, 16 Nov 1999 14:11:06 -0800 (PST)
Message-Id: <199911162211.OAA00779@sequoia.ece.ucdavis.edu>
X-Mailer: exmh version 2.0.3
X-face: 
 RinRV?cII^~g?cLc9;-D}8xnP^:6hX}*,%&@y"6p7xm^Z]V<7(`zzI!/#s%[2G'fTVC+b"*
 4eYfecJ4=,gHu4o_{Z[VG{Em*{tC^LKZ6eUDc?PI0@dk}3"kJ7*"y8*hMv\qz[C5djlU#AQh0Cq.%W
 @2kSd~S<<NcD7L4'O#`737_IEe02\s!gB6HW13]sD)'$+''!eRE7jPH\G(R&(+:Tu8bs[kr?ixX}x!
 -6`4*-B[UB_Wl!rZyL/$R(xi`vb"+t6osqR?gPX^r);Zpm'5(b/Rs[uGBN>&}]!;ZNm(wUE4=
X-url: http://www.ece.ucdavis.edu/~kenelson
To: gtk-devel-list@redhat.com
cc: kenelson@sequoia.ece.ucdavis.edu
Subject: Glib Semaphores
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 16 Nov 1999 14:11:05 -0800
From: Karl Nelson <kenelson@ece.ucdavis.edu>


Since glib already provides Mutex and Conditional_Signals, it would
seem like a good idea to provide a common usage of those in the
form of Semaphores.  Many threading codes in text books are commonly
expressed in terms of semaphores as there are conceptually simple
to do things like lock step producer/consumer, flow combining and
one pass.  

The total amount of necessary code is minimal as it uses the high
level interface.  It is all of 50 lines... (This is just
example, I have not fully tested it.)

--------------------------------------------------------------------
struct _GSemaphore 
{
  gint value;
  GMutex* access;
  GCond* sig;
};

typedef struct _GSemaphore GSemaphore;
#define g_semaphore_new() g_semaphore_new_with_value(1)
GSemaphore* g_semaphore_new_with_value(gint value);
void g_semaphore_free(GSemaphore*);
void g_semaphore_up(GSemaphore*);
void g_semaphore_down(GSemaphore*);
---------------------------------------------------------------------
GSemaphore* g_semaphore_new_with_value (gint value)
{
  if (!g_thread_supported ())
    return NULL;
  
  GSemaphore *sema = (GSemaphore *) g_new ( GSemaphore, 1);
  sema -> value = value;
  sema -> access = g_mutex_new();
  sema -> sig = g_cond_new();
}

void g_semaphore_free(GSemaphore*)
{
  g_return_if_fail (sema != NULL);
  g_mutex_free (sema->access);
  g_cond_free (sema->sig); 
}

void g_semaphore_up(GSemaphore* sema)
{
  g_return_if_fail (sema != NULL);
  g_mutex_lock (sema->access);
  sema->value ++;
  g_mutex_unlock (sema->access);
  g_cond_signal (sema->signal);
}

void g_semaphore_down(GSemaphore* sema)
{
   g_return_if_fail (sema != NULL);
   g_mutex_lock (sema->access);
   while (sema->value<1)
     g_cond_wait (sema->sig,sema->access);
   sema->value --;
   g_mutex_unlock (sema->access);
}
--------------------------------------------------------------------

We could even define an abstract semaphore with a vfunc up_action, 
down_action, and pass routine, but I think just a basic 
semaphore is useful enough.

Does this sound like a reasonable thing to add to glib?

--Karl


From dereks@kd-dev.com  Thu May 11 17:52:44 2000
Received: (qmail 6397 invoked from network); 16 Nov 1999 22:15:19 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 22:15:19 -0000
Received: from archer.kd-dev.com (dereks@archer.kd-dev.com [206.124.150.175])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id RAA13582
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 17:15:18 -0500
Received: from localhost (dereks@localhost)
	by archer.kd-dev.com (8.8.7/8.8.7) with ESMTP id OAA17178;
	Tue, 16 Nov 1999 14:09:45 -0800
Date: Tue, 16 Nov 1999 14:09:45 -0800 (PST)
From: Derek Simkowiak <dereks@kd-dev.com>
To: gtk-devel-list@redhat.com
cc: kenelson@sequoia.ece.ucdavis.edu
Subject: Re: Glib Semaphores
In-Reply-To: <199911162211.OAA00779@sequoia.ece.ucdavis.edu>
Message-ID: <Pine.LNX.4.04.9911161408341.14867-100000@archer.kd-dev.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

[re: g_semaphore API]
> Does this sound like a reasonable thing to add to glib?

	Looks great!  I think it's worth adding.

	Just my $.02.

--Derek

From kaz@FootPrints.net  Thu May 11 17:52:44 2000
Received: (qmail 32691 invoked from network); 16 Nov 1999 23:04:46 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 23:04:46 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA16516
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 18:04:45 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11nreR-0007Az-00; Tue, 16 Nov 1999 15:04:39 -0800
Date: Tue, 16 Nov 1999 15:04:39 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
cc: kenelson@sequoia.ece.ucdavis.edu
Subject: Re: Glib Semaphores
In-Reply-To: <199911162211.OAA00779@sequoia.ece.ucdavis.edu>
Message-ID: <Pine.LNX.4.10.9911161425590.26909-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Tue, 16 Nov 1999, Karl Nelson wrote:

> Date: Tue, 16 Nov 1999 14:11:05 -0800
> From: Karl Nelson <kenelson@ece.ucdavis.edu>
> Reply-To: gtk-devel-list@redhat.com
> To: gtk-devel-list@redhat.com
> Cc: kenelson@sequoia.ece.ucdavis.edu
> Subject: Glib Semaphores
> Resent-Date: 16 Nov 1999 22:11:10 -0000
> Resent-From: gtk-devel-list@redhat.com
> Resent-cc: recipient list not shown: ;
> 
> 
> Since glib already provides Mutex and Conditional_Signals, it would
> seem like a good idea to provide a common usage of those in the
> form of Semaphores.  Many threading codes in text books are commonly
> expressed in terms of semaphores as there are conceptually simple
> to do things like lock step producer/consumer, flow combining and
> one pass.  

Semaphores are a poor synchronization primitive from a software engineering
standpoint, because it's harder to verify code which uses them to be free of
deadlocks and race than equivalent code that uses condition variables.  I
believe that semaphores do not provide added utility over conditions and
mutexes.

Certain kinds of problems may be expressed more succinctly using sempahores;
typically problems in which the semaphore's internal counter is exploited
in some way to represent some quantity in the problem space. Among such
problems are resource counting and producer-consumer queues.

A possible advantage of semaphores is that because the shared data they protect
is a simple counter, atomic operations may be exploited to perform the
increment and decrement operations. For that, semaphores have to be implemented
specially, rather than in terms of other primitives such as mutexes and
conditions.  This advantage disappears when the semaphores are used in
conjunction with data that must be separately protected anyway (such as
consumer/producer queue), for then the counter might as well be made part of
the queue structure and protected by the queue's mutex, e.g.

	/* wait for item to become available */

	mutex.lock();

	while (count == 0)
	    item_avail_cond.wait(monitor);

	count--;
	/* remove item */
	mutex.unlock();
	space_avail_cond.signal();

If a semaphore is used instead, a mutex is still needed to protect the
queue. 

	item_avail_sem.wait();
	mutex.lock();
	/* remove item */
	mutex.unlock();
	space_avail_sem.signal();

The succint notation comes from the semaphore's internal management of the
queue counter.  Note that the counter is not kept coherent with the queue state
of the queue structure at all times, because the states of the semaphores
change outside of the region protected by the mutex. This means that the
semaphore which represents the number of items doesn't always have a value that
accurately reflects the number of things actually in the queue.  And also note
how there are really two redundant counters: one semaphore measuring available
items, and one counting the remaining space. The invariant that space + items
== max_len is not satisfied at all times! To prove that the queue is not
misused, for example by trying to remove an item from the empty queue, one has
to prove that the semaphores have reasonable values at all times.  In a trivial
example, this doesn't pose a problem, but in large, complex multithreaded
software, this kind of uncertainty can cause real headaches.

From dereks@kd-dev.com  Thu May 11 17:52:44 2000
Received: (qmail 2356 invoked from network); 16 Nov 1999 23:09:16 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 16 Nov 1999 23:09:16 -0000
Received: from archer.kd-dev.com (dereks@archer.kd-dev.com [206.124.150.175])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA16789
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 18:09:16 -0500
Received: from localhost (dereks@localhost)
	by archer.kd-dev.com (8.8.7/8.8.7) with ESMTP id PAA17422
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 15:03:49 -0800
Date: Tue, 16 Nov 1999 15:03:49 -0800 (PST)
From: Derek Simkowiak <dereks@kd-dev.com>
cc: gtk-devel-list@redhat.com
Subject: Question about autogen.sh
In-Reply-To: <Pine.LNX.4.10.9911152155030.19388-100000@mini.dhs.org>
Message-ID: <Pine.LNX.4.04.9911161458220.14867-100000@archer.kd-dev.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


	Is there an argument to GNU's ./autogen.sh or ./configure script
to have it compile a statically linked binary executable?

	I've used Glade to build a U.I., now I want to link the GTK+ libs
statically into my program.  I'm used to just going into the Makefile and
adding "--static" to the CFLAGS variable, but that doesn't seem to work
here (adding --static to the GTK_CFLAGS variable in the Makefile didn't
work).

	I also didn't see anything in config.h that looked like it
applied.

	Any suggestions?  

Thank You,
Derek Simkowiak
dereks@kd-dev.com

From kenelson@ece.ucdavis.edu  Thu May 11 17:52:44 2000
Received: (qmail 9510 invoked from network); 17 Nov 1999 02:19:31 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 17 Nov 1999 02:19:31 -0000
Received: from sequoia.ece.ucdavis.edu (root@sequoia.ece.ucdavis.edu [169.237.32.12])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id VAA24098
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 21:19:30 -0500
Received: from sequoia.ece.ucdavis.edu (kenelson@localhost [127.0.0.1])
	by sequoia.ece.ucdavis.edu (8.9.3/8.9.3) with ESMTP id SAA01536;
	Tue, 16 Nov 1999 18:19:27 -0800 (PST)
Message-Id: <199911170219.SAA01536@sequoia.ece.ucdavis.edu>
X-Mailer: exmh version 2.0.3
X-face: 
 RinRV?cII^~g?cLc9;-D}8xnP^:6hX}*,%&@y"6p7xm^Z]V<7(`zzI!/#s%[2G'fTVC+b"*
 4eYfecJ4=,gHu4o_{Z[VG{Em*{tC^LKZ6eUDc?PI0@dk}3"kJ7*"y8*hMv\qz[C5djlU#AQh0Cq.%W
 @2kSd~S<<NcD7L4'O#`737_IEe02\s!gB6HW13]sD)'$+''!eRE7jPH\G(R&(+:Tu8bs[kr?ixX}x!
 -6`4*-B[UB_Wl!rZyL/$R(xi`vb"+t6osqR?gPX^r);Zpm'5(b/Rs[uGBN>&}]!;ZNm(wUE4=
X-url: http://www.ece.ucdavis.edu/~kenelson
To: gtk-devel-list@redhat.com
cc: kenelson@sequoia.ece.ucdavis.edu, kenelson@sequoia.ece.ucdavis.edu
Subject: Re: Glib Semaphores 
In-reply-to: Your message of "Tue, 16 Nov 1999 15:04:39 PST."
             <Pine.LNX.4.10.9911161425590.26909-100000@ashi.FootPrints.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 16 Nov 1999 18:19:26 -0800
From: Karl Nelson <kenelson@ece.ucdavis.edu>


[...]
> A possible advantage of semaphores is that because the shared data they protect
> is a simple counter, atomic operations may be exploited to perform the
> increment and decrement operations. For that, semaphores have to be implemented
> specially, rather than in terms of other primitives such as mutexes and
> conditions.  This advantage disappears when the semaphores are used in
> conjunction with data that must be separately protected anyway (such as
> consumer/producer queue), for then the counter might as well be made part of
> the queue structure and protected by the queue's mutex, e.g.

Probably true, but then some things are better represented one way 
while others are better represented in others.  I assume the user
will chose the most appropriate representation.

[...]
A typical example of producer/consumer expressed if lock step operation
is necessary can be cleanly written with semaphores like this. 

 main:
   // spawn threads
   process.down();  // wait until all processes die to terminate
   process.down();

 consumer:
   while (want_items)
     {
       consumer.down();
       // eat up an item
       producer.up();
       // do some more processing which is not shared
     }
   process.up();

 producer:
   while (can_produce)
     {
       producer.down();
       // produce some items.
       consumer.up();
       // more unshared processing
     }
   process.up();

Here, I don't need any more mutexs nor do I need to worry about
the recombining.  The semaphore process represents threads completed
so arguments about representing some queue length don't really 
apply.
     
[...]
> To prove that the queue is not
> misused, for example by trying to remove an item from the empty queue, one has
> to prove that the semaphores have reasonable values at all times.  In a trivial
> example, this doesn't pose a problem, but in large, complex multithreaded
> software, this kind of uncertainty can cause real headaches.

This simply means that semaphores weren't the proper way to express that
large, complex multithreaded software.  They do have their uses especially 
for tasks where you spawn some threads let then work and then recombine.
I certain don't think adding a semaphore concept is likely to force it
on the users.  

You seem to be implying that since you can do it one way, there is 
no need for a simpler to use concept for quick and dirty threading tasks.  
I think that it certain is safe for some tasks and some programmer will
find it of use.   Since the cost of adding it is fairly insignificant, I 
don't see the fact that is not useful in very complex programs as being 
a reason for not adding such a common concept.

--Karl


From kaz@FootPrints.net  Thu May 11 17:52:44 2000
Received: (qmail 21212 invoked from network); 17 Nov 1999 03:40:37 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 17 Nov 1999 03:40:37 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id WAA26722
	for <gtk-devel-list@redhat.com>; Tue, 16 Nov 1999 22:40:36 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11nvxT-00005S-00
	for gtk-devel-list@redhat.com; Tue, 16 Nov 1999 19:40:35 -0800
Date: Tue, 16 Nov 1999 19:40:35 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
Subject: Re: Glib Semaphores 
In-Reply-To: <199911170219.SAA01536@sequoia.ece.ucdavis.edu>
Message-ID: <Pine.LNX.4.10.9911161843530.31849-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Tue, 16 Nov 1999, Karl Nelson wrote:

> Probably true, but then some things are better represented one way 
> while others are better represented in others.  I assume the user
> will chose the most appropriate representation.
> 
> [...]
> A typical example of producer/consumer expressed if lock step operation
> is necessary can be cleanly written with semaphores like this. 
> 
>  main:
>    // spawn threads
>    process.down();  // wait until all processes die to terminate
>    process.down();

This is almost always done best by a special ``join'' system call.  E.g.
pthread_join() in POSIX, or, heaven forbid, WaitForSingleObject() on a thread
handle in Win32.

Failing that, the down() function could easily be implemented by
a condition.

	process_type::join()
	{
	    mutex.lock();
	    while (state != dead)
		cond.wait(mutex);
	    mutex.unlock();
	}

When the thread dies, it sets the state to dead and broadcasts the condition.
All waiting threads are released, and anyone who subsequently acquires the
mutex finds the thread in a dead state. Note that you can safely call

	process.join();

multiple times without deadlocking; it's an idempotent operation. Also,
multiple threads can call process.join() to wait for a given process to die,
(so long as cond.broadcast() is used to indicate the termination.) 

>  consumer:
>    while (want_items)
>      {
>        consumer.down();
>        // eat up an item
>        producer.up();
>        // do some more processing which is not shared
>      }
>    process.up();
> 
>  producer:
>    while (can_produce)
>      {
>        producer.down();
>        // produce some items.
>        consumer.up();
>        // more unshared processing
>      }
>    process.up();
>
> Here, I don't need any more mutexs nor do I need to worry about
> the recombining.

Instead you now have to worry whether the initial states of your semaphores
is logically correct with respect to the item list.

What has to be true initially? Suppose the queue starts empty, a reasonable
initial state. Then the producer semaphore should be up, so that the producer
can get in to the code that produces items.  The consumer semaphore should be
down, so the consumer is forced to wait.  With conditions, you don't worry,
because they have no state.

I find the code snippet surprisingly difficult to understand given its trivial
size. I can't see how it can work unless I work backward to what the correct
values for the semaphores must be. It's not even immediately obvious that
the queuing operations are properly protected from each other.

It's only easy if you have a textbook example that you can trust.  To that I
say, get a textbook that teaches semaphores as well as conditions.

> so arguments about representing some queue length don't really 
> apply.

It's true that you are now not representing queue length, but you are using the
semaphores to represent some other attribute of the queue: namely empty
and non-empty.

Note the producer is waiting on the ``empty'' predicate, which is is
unnecessarily strong; the weakest precondition for adding something to a queue
is that it's not full, not that it's empty.

The excessively weak predicates that are implied result in strict alternation
between producer and consumer, which wastes cycles. An implementation of this
could run thousands of times slower than similar code that context switches
only involuntarily or at queue boundaries---for example by using conditions
or by using counting semaphores rather than binary semaphores.

From Elliott.Hughes@genedata.com  Thu May 11 17:52:44 2000
Received: (qmail 8360 invoked from network); 17 Nov 1999 09:57:38 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 17 Nov 1999 09:57:38 -0000
Received: from mail.core.genedata.com (mentolat-e0.core.genedata.com [157.161.173.16])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id EAA05148
	for <gtk-devel-list@redhat.com>; Wed, 17 Nov 1999 04:57:36 -0500
Received: from relay.core.genedata.com (nila-e0.core.genedata.com [157.161.173.44])
	by mail.core.genedata.com (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dAH9vXU07907
	for <gtk-devel-list@redhat.com>; Wed, 17 Nov 1999 10:57:33 +0100
Received: from relay.ch.genedata.com (pinatubo-e0.ch.genedata.com [157.161.173.48])
	by relay.core.genedata.com (8.10.0.Beta6/8.10.0.Beta6) with ESMTP id dAH9vU216530
	for <gtk-devel-list@redhat.com>; Wed, 17 Nov 1999 10:57:30 +0100
Received: from stromboli (enh@stromboli.ch.genedata.com [157.161.173.81])
	by relay.ch.genedata.com (8.9.3/8.9.3) with SMTP id KAA1258024
	for gtk-devel-list@redhat.com; Wed, 17 Nov 1999 10:57:29 +0100 (CET)
Date: Wed, 17 Nov 1999 10:57:29 +0100 (CET)
Message-Id: <199911170957.KAA1258024@relay.ch.genedata.com>
From: Elliott Hughes <Elliott.Hughes@genedata.com>
To: gtk-devel-list@redhat.com
Subject: Re: Plans for drawing in GDK-1.4.

Owen Taylor <otaylor@redhat.com> wrote:
> How does this help? Double buffering wouldn't decrease the amount
> of time until the newly scrolled-in areas are updated as far
> as I can see.

no, but it will improve the appearance. as you note on your web page,
it's not speed that's the problem, it's perceived quality, and flicker plays
a large part in this perception.

> At the widget level double-buffering will appear to be automatic,
> since GTK+ will do the begin_paint / end_paint around handling
> an expose event.

sorry, this is what i meant. i'd misunderstood you, and you misunderstood
my misunderstanding! this sounds fine.

> Just because there is a scroll-window call doesn't mean that scrolling
> is generic. A widget would have to keep track of the coordinate
> offsets.

my contention is that scrolling is almost ubiquitous, particularly in
user-written widgets. there aren't many little widgets not already
available, so widget writers will almost certainly have to deal with
scrolling. i accept that they'll have to take the scroll offsets into
account, but i find it unfortunate that they have to write the
set_scroll_adjustments code each time.

> The whole point of not putting set_scroll_adjustments into GtkWidget
> was to avoid bloating the GtkWidget interface with yet more signals.

how about in GtkDrawingArea then? because it actually has a window,
this tends to be more convenient for the widget writer than direct use of
GtkWidget.

> Adding support for interfaces to GtkObject is still in the plans
> for 1.4, and set_scroll_adjustments is a prime target for making
> an interface.

i just have the feeling that the current situation is less convenient than
it could be. i don't much mind how it gets resolved, as long as it does.

this is the reason that i find low-level support for double-buffering so
critical. relatively inexperienced Java programmers can produce
good-looking widgets with Swing because it automatically does the
double-buffering behind the scenes. even if they redraw their widget
slowly, it still has a certain gracefulness that even the best-written
GTK+ widgets lack at the moment. the first thing that Java programmers
notice about GTK+ is how badly ir flickers.

i think one of the reasons for the failure of Xt was the belief that writing
widgets was hard, for experts, and not something that should be par for
the course when writing a GUI program. failure? compare with what we
see done with Java's toolkit, where writing one's own widget _is_ seen
as easy, and _is_ seen as a normal, reasonable part of the development
process for just about any program of any interest. (i.e. not just another
bleedin' IRC client.)

-- 
"As the Chinese say, 1001 words is worth more than a picture."
	-- John McCarthy

From sd90034@lanet.lv  Thu May 11 17:52:44 2000
Received: (qmail 29142 invoked from network); 17 Nov 1999 10:44:19 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 17 Nov 1999 10:44:19 -0000
Received: from ieva06.lanet.lv (ieva06.lanet.lv [195.13.129.106])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id FAA06616
	for <gtk-devel-list@redhat.com>; Wed, 17 Nov 1999 05:44:15 -0500
Received: from ieva01.lanet.lv (ieva01 [195.13.129.101])
	by ieva06.lanet.lv (8.9.3/8.9.1) with ESMTP id MAA18142
	for <gtk-devel-list@redhat.com>; Wed, 17 Nov 1999 12:30:33 +0200
Received: from localhost (sd90034@localhost)
	by ieva01.lanet.lv (8.9.3/8.9.0) with ESMTP id MAA224006
	for <gtk-devel-list@redhat.com>; Wed, 17 Nov 1999 12:30:31 +0200
X-Authentication-Warning: ieva01.lanet.lv: sd90034 owned process doing -bs
Date: Wed, 17 Nov 1999 12:30:30 +0200 (WET)
From: Alexander Piskunov <sd90034@lanet.lv>
To: gtk-devel-list@redhat.com
Subject: Re: Plans for drawing in GDK-1.4.
In-Reply-To: <199911170957.KAA1258024@relay.ch.genedata.com>
Message-ID: <Pine.A41.4.05.9911171157330.160974-100000@ieva01.lanet.lv>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



On Wed, 17 Nov 1999, Elliott Hughes wrote:

> Owen Taylor <otaylor@redhat.com> wrote:
> > How does this help? Double buffering wouldn't decrease the amount
> > of time until the newly scrolled-in areas are updated as far
> > as I can see.
> 
> no, but it will improve the appearance. as you note on your web page,
> it's not speed that's the problem, it's perceived quality, and flicker plays
> a large part in this perception.

This is the point of making flicker-free drawing. Speed is second,
appearance is first. Tcl/TK is damned slow, but it looks better than GTK+
because redrawing is flicker-free.

AlexP

From J.A.K.Mouw@its.tudelft.nl  Thu May 11 17:52:44 2000
Received: (qmail 3260 invoked from network); 17 Nov 1999 12:27:57 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 17 Nov 1999 12:27:57 -0000
Received: from duteinh.et.tudelft.nl (duteinh.et.tudelft.nl [130.161.42.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id HAA09337
	for <gtk-devel-list@redhat.com>; Wed, 17 Nov 1999 07:27:57 -0500
Received: from dutein71 by duteinh.et.tudelft.nl (8.9.3/BB-2.0)
	id NAA11362; Wed, 17 Nov 1999 13:27:55 +0100 (MET)
Date: Wed, 17 Nov 1999 13:27:55 +0100 (MET)
Message-Id: <199911171227.NAA11362@duteinh.et.tudelft.nl>
From: Erik Mouw <J.A.K.Mouw@its.tudelft.nl>
To: gtk-devel-list@redhat.com
Subject: Re: Question about autogen.sh
In-Reply-To: <Pine.LNX.4.04.9911161458220.14867-100000@archer.kd-dev.com>
Organization: Eric conspiracy secret labs
X-Face: "!Z|1XjFg!3Iw)BwM^M\k)J5KHiPddz}#/Zw%?$&Q!xqob"OA|})3_@&BTTiQERo?/^g[Z<9P4R8:5C:aqq.cw!hotLc=+u-"+1rq@9$V^8PbOUlodyi_sejt+D`iqkLpx$>.aXl%vnfPIt"LK|/%>94_Zrm8jy?`_[RKt'TuoxUxfk(gMhY(n|DBBl~c$dhO>G%6}R4+DGX3|idBm4oU&UM/XUP4I9aoN{]`ax%B?rgD(I3OJ<62Y6L
X-Mailer: XCmail 0.99.6 - with PGP support, PGP engine version 0.5
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
X-Eric-Conspiracy: There is no conspiracy!
X-Loop: erik@it.et.tudelft.nl
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

On Tue, 16 Nov 1999 15:03:49 -0800 (PST), Derek Simkowiak wrote:
>      Is there an argument to GNU's ./autogen.sh or ./configure script
> to have it compile a statically linked binary executable?

No.

>      I've used Glade to build a U.I., now I want to link the GTK+ libs
> statically into my program.  I'm used to just going into the Makefile and
> adding "--static" to the CFLAGS variable, but that doesn't seem to work
> here (adding --static to the GTK_CFLAGS variable in the Makefile didn't
> work).

No, because it should be in the linker flags, not in the compiler flags.
It is also possible that it just doesn't work on your platform. Yes,
-static works on Linux, but it fails miserably on IRIX.

>      I also didn't see anything in config.h that looked like it
> applied.
> 
>      Any suggestions?  

Assumed that you use Linux (you didn't tell us), you can use:

  gcc -o foo foo.o bar.o gnu.o gnats.o -Wl,-B,static -lgtk -lgdk -lglib \
    -Wl,-B,dynamic -lXext -lX11 -lm

This switches back and forth between static (gtk, gdk, and glib) and
dynamic linking (all other libraries).


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2785859  Fax: +31-15-2781843  Email J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/


From otaylor@redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 27973 invoked from network); 17 Nov 1999 17:29:41 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 17 Nov 1999 17:29:41 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA04283
	for <gtk-devel-list@redhat.com>; Wed, 17 Nov 1999 12:29:41 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id MAA22601;
	Wed, 17 Nov 1999 12:28:09 -0500
To: gtk-devel-list@redhat.com
Subject: Re: Plans for drawing in GDK-1.4.
References: <199911170957.KAA1258024@relay.ch.genedata.com>
From: Owen Taylor <otaylor@redhat.com>
Date: 17 Nov 1999 12:28:09 -0500
In-Reply-To: Elliott Hughes's message of "Wed, 17 Nov 1999 10:57:29 +0100 (CET)"
Message-ID: <ybehfil3u52.fsf@fresnel.labs.redhat.com>
Lines: 77
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Elliott Hughes <Elliott.Hughes@genedata.com> writes:

> Owen Taylor <otaylor@redhat.com> wrote:
> > How does this help? Double buffering wouldn't decrease the amount
> > of time until the newly scrolled-in areas are updated as far
> > as I can see.
> 
> no, but it will improve the appearance. as you note on your web page,
> it's not speed that's the problem, it's perceived quality, and flicker plays
> a large part in this perception.

Double buffering only helps for scrolling if we make a change to
set a background pixmap of 'None' while scrolling. Otherwise, 
when you scroll, areas get cleared to the background color 
by the X server before being refreshed, and you get flicker
even if the update in one pass. (This is very obvious with
Mozilla which double-buffers all drawing and flickers like
crazy while scrolling.)
 
> > Just because there is a scroll-window call doesn't mean that scrolling
> > is generic. A widget would have to keep track of the coordinate
> > offsets.
> 
> my contention is that scrolling is almost ubiquitous, particularly in
> user-written widgets. there aren't many little widgets not already
> available, so widget writers will almost certainly have to deal with
> scrolling. i accept that they'll have to take the scroll offsets into
> account, but i find it unfortunate that they have to write the
> set_scroll_adjustments code each time.
> 
> > The whole point of not putting set_scroll_adjustments into GtkWidget
> > was to avoid bloating the GtkWidget interface with yet more signals.
> 
> how about in GtkDrawingArea then? because it actually has a window,
> this tends to be more convenient for the widget writer than direct use of
> GtkWidget.
> 
> > Adding support for interfaces to GtkObject is still in the plans
> > for 1.4, and set_scroll_adjustments is a prime target for making
> > an interface.
> 
> i just have the feeling that the current situation is less convenient than
> it could be. i don't much mind how it gets resolved, as long as it does.

I don't see scrolling as ubiquitous - most cases in which I've written
a custom control for an application, with GtkDrawingArea,
or as a from-scratch widget, I haven't needed scrolling.

But even if scrolling was ubiquitously needed, the way to add scrolling
to a non-scrolling widget is to add it to a GtkViewport; just as
the way to add a border to a borderless widget is to add it to
a GtkFrame, or the way to add alignment to a non-aligneable widget
is to add it to a GtkAlignment. ("The decorator pattern" for those
so inclined).

Remember that simply having the ability to scroll the window doesn't
make you a scrollable widget. You need the ability to define the
scrollable region, and you need to keep track of the scroll offsets
when drawing. GtkViewport hides these details from the widget
writer in a way that adding scrolling directly to GtkWidget could
not.

And if I manage to do all I plan to do with hiding the 16-bit nature
of X, it should be possible to use GtkViewport even for widgets
that need to scroll over a > 16bit range.

Admittedly, having GtkViewport as the default scrolling method
forces people using the toolkit to know about the difference
between scrollable and non-scrollable widgets, but I think that
is a manageable concept when well documented.

Thanks for your comments. Hopefully I'll have some of this implemented
soon.

Regards,
                                        Owen

From otaylor@redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 5773 invoked from network); 17 Nov 1999 17:41:42 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 17 Nov 1999 17:41:42 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA05008
	for <gtk-devel-list@redhat.com>; Wed, 17 Nov 1999 12:41:42 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id MAA22638;
	Wed, 17 Nov 1999 12:40:08 -0500
To: gtk-devel-list@redhat.com, xinput@gtk.org
Subject: XInput changes for GTK+-1.4
From: Owen Taylor <otaylor@redhat.com>
Date: 17 Nov 1999 12:40:08 -0500
Message-ID: <ybed7t93tl3.fsf@fresnel.labs.redhat.com>
Lines: 27
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Being about to make some binary-incompatible changes to the GdkEvent
structures, I thought I'd work on figuring out the changes to 
XInput support (which will also involve GdkEvent structure changes)
for GTK+-1.4.

The primary motivation for such changes is supporting the extra valuators
from the Wacom Intuos tables, but there also is some definite
cleanup of the API's possible, and it may also be desirable to 
make some changes to make the API abstract better on top of both
XInput and the Win32 tablet support that Tor has added.

I've put a description of my ideas at:

 http://www.gtk.org/~otaylor/gtk/1.4/xinput.html

This tries to address the extra-valuator problem, but doesn't
go very far in addressing the problem of configuration. In
fact, we probably need some extensions to the XInput extension
to allow for properly dealing with the configuration problem,
since the driver knows things like the type of each valuator
(location, pressure, tilt, wheel position) and also the
type of the device, but there is no way of conveying that
information to client applications or toolkits.

Regards,
                                        Owen

From timj@gtk.org  Thu May 11 17:52:44 2000
Received: (qmail 19180 invoked from network); 18 Nov 1999 23:28:42 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 18 Nov 1999 23:28:42 -0000
Received: from birgrave.birnet.private (dip-03-040.misc.net [212.20.139.40])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA24208
	for <gtk-devel-list@redhat.com>; Thu, 18 Nov 1999 18:28:37 -0500
Received: from birgrave (timj@localhost)
	by birgrave.birnet.private (8.9.3/8.8.5) with internal id AAA03068;
	Fri, 19 Nov 1999 00:32:32 +0100
From: Tim Janik <timj@gtk.org>
Message-Id: <199911182332.AAA03068%timj@gtk.org>
Date: Fri, 19 Nov 1999 00:32:31 +0100 (CET)
To: gtk-devel-list@redhat.com
Subject: Re: Proposal: g_set_out_of_mem_handler
In-Reply-To: <38316DDB.B6100D11@ira.uka.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Tue, 16 Nov 1999, Sebastian Wilhelmi wrote:

> Hi, all
> 
> We recently had a discussion on orbit-list about the current fail at "out of
> memory" behaviour of GLib. While I still think, out of memory can in general
> not be handled sane, we might as well add a hook to be called whenever Glib
> find itself out of mem. For the greatest possible generality this routine only
> have to return a pointer to the requested memory, thus this memory can be
> taken from a preallocated place in memory, and now comes the clue: gmem.c
> keeps a list of pointers, that are obtained that way. This list is normally
> empty (almost no overhead in testing it) and if not empty every freed memory
> is testet against that list and if contained freed with another callback.

note that -using this approach- after a short period of memory bottleneck, you
might end up with a significant amount of small memory portions (a bunch of
which can actually be RO allocations) that are all kept in your pointer list
and are checked against upon all further free() operations (a very frequently
used function btw, due to the highly dynamic nature glib/gtk code is coded in
general). this can cause a major slowdown for the rest of the application's
runtime, eventhough the real bottleneck quickly vanished.

> That
> way you can preallocate, say, 500 KB and whenever an "out of mem" occurs you
> just give out the requested memory and be fine. (and hope, XLib will not try
> allocate memory, that is ;-).

which is pretty naive as soon as you get into matters of handling the event
queue...

> That might actually work, is not much overhead
> and will at least save us from more and more questions regarding that. I
> appended a sample implementation. Its not yet fully testet, but should
> actually work. Then you could do something like:
[...]

> BTW.: Now, that we have memprof (Great work...), isn't it about time to remove
> some of that memory profiling in GLib. Its really looking ugly and I doubt,
> anybody use it...

ok, i should note first that i wholeheartedly agree with you that out-of-memory
situations can't be handled comprehensively (and portably!) in a sane way at
the application level.
but since the "broad public" (whatever that is ;) seems to feel a need to be
enabled to handle this situations at least in edge cases, i think we should
come up with a more generic solution that will:

1) get rid of the old half-backed debugging/"profiling" code in gmem.c.
   we got three different defines to alter allocation/reporting behaviour
   currently, which tend to be rarely used and over-complexify glib's
   basic allocation strategies.
2) be comprehensible enough to cover future feature requests that may popup
   in this area, for instance to facilitate platform specific allocation
   debuggers or memory-region locks (the interested linux user may want to
   ponder about mprotect(2) for a moment).

some considerations that imho should be taken into account:
- we certainly can't feature something as versatile as the GAllocator
  mechanism, since g_malloc() is used for probably 90% of a normal gtk
  program's allocations at all programming layers, including the low-level
  glib stuff.
- this seems like a good opportunity to make an effort on specializing for
  read-only allocated regions, so we
  * avoid a major portion of so-thought-leak "bug reports"
  * can use provided hooks to report real leaks and meaningfull statistics
    of the g_malloc() allocations being made by the application
  * provde hints for the fallback-allocation routines used upon EMEM, so
    it can deal with allocation requests cleverly, i.e. not bother about
    RO regions being freed.
  (i estimate about a 1/2 to 1 day (for a core hacker) to go over glib/gtk
  code and substitute ro allocations with the new function calls)

i think a good aproach on this, would be:

typedef struct _GMallocTable GMallocTable;
struct _GMallocTable
{
  gpointer (*malloc)		(gulong         size); /* obligatory */
  gpointer (*romalloc)		(gulong         size);
  void     (*free)		(gpointer       mem);  /* obligatory */
  gpointer (*fallback_malloc)	(gulong         size,
                                 gboolean       ro_allocation);
  void     (*report)            (const gchar   *log_domain,
                                 GLogLevelFlags log_level);
};

extern GMallocTable *g_default_malloc_table;

/* this function has to be called *prior* to any other
 * GLib function if at all (including g_thread_init()).
 */
GMallocTable* g_malloc_table_set (GMallocTable *table);

void g_malloc_report (const gchar   *log_domain,
                      GLogLevelFlags log_level);

#define g_new(type, count)		/* as present */
#define g_new0(type, count)		/* as present */
#define g_renew(type, mem, count)	/* as present */

gpointer g_malloc      (gulong    size);
gpointer g_malloc0     (gulong    size);
gpointer g_realloc     (gpointer  mem,
                        gulong    size);
void     g_free        (gpointer  mem);

/* ReadOnly allocations, memory portions returned from these allocators
 * may *never* be passed into g_free(), no further checks are performed
 */
gpointer g_romalloc    (gulong    size);
gpointer g_romalloc0   (gulong    size);
#define g_ronew(type, count)		/* g_new(), calling g_romalloc() */
#define g_ronew0(type, count)		/* g_new0(), calling g_romalloc0() */

sample implementation:

#include <stdlib.h>
static GMallocTable default_malloc_table = { malloc, malloc, free, NULL };
GMallocTable *g_default_malloc_table = &default_malloc_table;
static GMallocTable *g_malloc_table = &default_malloc_table;

gpointer
g_malloc (gulong size)
{
  gpointer p;
  
  /* we guarrantee to *never* return NULL; except for size==0 */
  if (size == 0)
    return NULL;
        
  p = g_malloc_table->malloc (size);
  if (!p)
    {
      p = g_malloc_table->fallback_malloc (size, FALSE);
      if (!p)
        g_error ("could not allocate %ld bytes", size);
    }

  return p;
}

this will even allow to keep maintaining the current ENABLE_MEM_CHECK
behaviour by providing

extern GMallocTable *g_debug_malloc_table;

if people insist on the possibility (though there are better ways to
facilitate allocation debuging/bounds checking).

a viable implementation for customized fallback_malloc()/free() implementations
could then be, to

- preallocate a certain memory region, sticking to sebastian's example: 512KB
  keep the start and end pointers of that region
- return NULL for memory requests that could not be fullfilled
- allocate ro regions from the top, shrinking the end pointer
- allocate rw regions from a freed_regions list or from the bottom
- check regions to be freed against the end and start pointers then
    add them to the freed_regions list (with optional merging)
  else
    defer freeing to the underlying system specific implementation


the ->report() member of GMallocTable would be otionally featured by
g_malloc_report() to print a detailed allocation report at a certain
log level, this is optional suggar that i just throw in for discussion.
more sophisticated approaches are also possible, e.g. ->report() filling
some GMallocStats structure

struct _GMallocStats
{
  gulong  current_rw_allocations;
  gulong  current_ro_allocations;
  gulong  total_rw_allocations; /* since app start */
  gulong  total_freed_allocations; /* since app start */
  gulong  total_ro_allocations; /* since app start */
  guint   n_listed_rw_allocations;
  gulong *rw_allocations; /* to be free()ed after usage */
  guint   n_listed_ro_allocations;
  gulong *ro_allocations; /* to be free()ed after usage */
};

i'm not really proposing this last part, implementation depends on what
people think would be necessary and usefull.

> 
> Bye,
> Sebastian

---
ciaoTJ

From timj@gtk.org  Thu May 11 17:52:44 2000
Received: (qmail 25252 invoked from network); 19 Nov 1999 03:19:14 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 19 Nov 1999 03:19:14 -0000
Received: from birgrave.birnet.private (dip-03-032.misc.net [212.20.139.32])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id WAA00380
	for <gtk-devel-list@redhat.com>; Thu, 18 Nov 1999 22:19:12 -0500
Received: from birgrave (timj@localhost)
	by birgrave.birnet.private (8.9.3/8.8.5) with internal id EAA05927;
	Fri, 19 Nov 1999 04:18:29 +0100
From: Tim Janik <timj@gtk.org>
Message-Id: <199911190318.EAA05927%timj@gtk.org>
Date: Fri, 19 Nov 1999 04:18:29 +0100 (CET)
To: =?iso-8859-1?Q?Egil_M=F6ller?= <redhog@lysator.liu.se>
cc: Gtk+ Developers <gtk-devel-list@redhat.com>
Subject: Re: Ad-on hook idea (fwd)
In-Reply-To: <Pine.LNX.4.10.9911161753190.2158-100000@mini.dhs.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN
Content-Transfer-Encoding: QUOTED-PRINTABLE

On Tue, 16 Nov 1999 redhog@mini.dhs.org wrote:

> When it comes to the wheel-scrolling thing, I have a little problem - I
> want _every_ button press/move/release that vis not used for something
> else for a the widget inside the scrolledwindow widget, to scroll the
> scrolledwindow widget. But I don't know how to get the knowledge of if
> some event has been used allready. If someone could help me with this, I
> would be ready with such a module in a few days!

event handlers return a boolean value indicating whether an event has
been processed or not (and should be propagated uop the widget heirarchy).
though this is pretty unelegant and may not be supported in future versions=
,
you could cod eup a gtk module that patches GtkScrolledWindow's button_pres=
s
handler. this would look something like this (upon module initialization):

static gboolean (*orig_button_press_event) (GtkWidget *widget, GdkEvent *ev=
ent) =3D NULL;
static GtkWidgetClass *scrolled_window_class =3D NULL;


  class =3D gtk_type_class (GTK_TYPE_SCROLLED_WINDOW);
  orig_button_press_event =3D class->button_press_event;
  class->button_press_event =3D my_scrolled_window_button_press_event;


static gboolean
my_scrolled_window_button_press_event (GtkWidget *widget,
                                       GdkEvent  *event)
{
  /* chain original class handler first */
  if (orig_button_press_event && orig_button_press_event (widget, event))
    return TRUE;
 =20
  /* button press unhandled */
=20
  if (event->button.button =3D=3D 4)
    {
      do_stuff_here ();
   =20
      return TRUE; /* we handled the event now */
    }
  else
    return FALSE; /* event unhandled */
}

> Last, a question about the module system: Is it possible to create a
> library call that Gtk programs could do to the module, that just returns
> an error message if that module isn't loaded, and that calls some functio=
n
> inside the module if it is loaded? Is there such a call allready?

there are actually two fucntions featured and you need to define both,
the first is called by the GModule code to check for versioning and
similar stuff, you can cut and paste this code:

G_MODULE_EXPORT const gchar* g_module_check_init (GModule *module);
const gchar*
g_module_check_init (GModule *module)
{
  GModule *main_module;
  gchar *version_check =3D NULL;

  main_module =3D g_module_open (NULL, 0);
  if (!main_module)
    return "no main handle";
  if (!g_module_symbol (main_module, "gtk_major_version", (gpointer*) &vers=
ion_check) && version_check)
    return "no gtk library?";

  version_check =3D gtk_check_version (GTK_MAJOR_VERSION,
                                     GTK_MINOR_VERSION,
                                     GTK_MICRO_VERSION - GTK_INTERFACE_AGE)=
;
  if (version_check)
    return version_check;

  return NULL;
}

the second is called by gtk for actuall module initialization, this is wher=
e
you should put the above code:

G_MODULE_EXPORT void gtk_module_init (gint *argc, gchar ***argv);
void
gtk_module_init (int            *argc,
                 char           ***argv)
{
  /* freak out on the scrolled window class */
}

gtk modules are always resident, so you don't need to worry about destructi=
on/
unloading.


> With best regards,
> Egil M=F6ller
>=20

---
ciaoTJ

From dm@mail.redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 24358 invoked from network); 20 Nov 1999 16:32:47 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 20 Nov 1999 16:32:47 -0000
Received: from mailhost.vlsivie.tuwien.ac.at (root@mouse.vlsivie.tuwien.ac.at [128.130.40.221])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id LAA06604
	for <gtk-devel-list@redhat.com>; Sat, 20 Nov 1999 11:32:46 -0500
Received: from vlsivie.tuwien.ac.at (really [128.130.40.155]) by vlsivie.tuwien.ac.at
	via smail with esmtp (ident dm using rfc1413)
	id <m11pDRN-001FHBC@mailhost.vlsivie.tuwien.ac.at> (Debian Smail3.2.0.102)
	for <gtk-devel-list@redhat.com>; Sat, 20 Nov 1999 17:32:45 +0100 (CET) 
Sender: dm@mail.redhat.com
Message-ID: <3836CD2D.D57BF00A@vlsivie.tuwien.ac.at>
Date: Sat, 20 Nov 1999 17:32:45 +0100
From: Dietmar Maurer <dm@vlsivie.tuwien.ac.at>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: de-AT, en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: [Fwd: gtkplug commit]
Content-Type: multipart/mixed;
 boundary="------------7F79F706936EBDF628960A14"

This is a multi-part message in MIME format.
--------------7F79F706936EBDF628960A14
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------7F79F706936EBDF628960A14
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit
Content-Disposition: inline

Return-Path: <gnome-components-list-request@redhat.com>
Received: from lists.redhat.com (really [199.183.24.247]) by vlsivie.tuwien.ac.at
	via smail with smtp
	id <m11pDMz-001FKNL@mailhost.vlsivie.tuwien.ac.at> (Debian Smail3.2.0.102)
	for <dm@vlsivie.tuwien.ac.at>; Sat, 20 Nov 1999 17:28:13 +0100 (CET) 
Received: (qmail 22852 invoked by uid 501); 20 Nov 1999 16:28:09 -0000
Resent-Date: 20 Nov 1999 16:28:09 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From gnome-components-list-request@gnome.org  Sat Nov 20 11:28:09 1999
Sender: dm@mail.redhat.com
Message-ID: <3836CC17.13479D34@vlsivie.tuwien.ac.at>
Date: Sat, 20 Nov 1999 17:28:07 +0100
From: Dietmar Maurer <dm@vlsivie.tuwien.ac.at>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: de-AT, en
MIME-Version: 1.0
To: gnome-components-list@gnome.org, otaylor@redhat.com,
  gtk-devel-list@gtk.org
Subject: Re: gtkplug commit
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Resent-Message-ID: <"SDnRu3.0.fa5.PmiDu"@lists.redhat.com>
Resent-From: gnome-components-list@gnome.org
X-Mailing-List: <gnome-components-list@gnome.org> archive/latest/104
X-Loop: gnome-components-list@gnome.org
Precedence: list
Resent-Sender: gnome-components-list-request@gnome.org
X-URL: http://www.gnome.org
X-Mozilla-Status2: 00000000

I´ve observed the following problem with gtk_plug/sockets:

void
gtk_plug_construct (GtkPlug *plug, guint32 socket_id)
{
  plug->socket_window = gdk_window_lookup (socket_id);
  plug->same_app = TRUE;

  if (plug->socket_window == NULL)
    {
      plug->socket_window = gdk_window_foreign_new (socket_id);
      plug->same_app = FALSE;
    }
}

if gdk_window_lookup return something != NULL we use the existing window

(without increasing the reference count!). But gtk_plug_unrealize
always  unrefs the window wich causes the window to be destroyed.

This is why bobobo doesn´t work.

A quick fix would be to "gdk_window_ref" the window:

gtk_plug_construct (GtkPlug *plug, guint32 socket_id)
{
  plug->socket_window = gdk_window_lookup (socket_id);
  plug->same_app = TRUE;

  if (plug->socket_window == NULL)
    {
      plug->socket_window = gdk_window_foreign_new (socket_id);
      plug->same_app = FALSE;
    }
  else gdk_window_ref (plug->socket_window);   /* reference the window
*/
}

I´m sure this change will not break any code.

Owen Taylor wrote:

> (I have at least one reservation about it the patch... there
> are other ways that a plug/socket doesn't work in the same
> application, so this may just be papering over deeper
> problems.)

in the same application? The problem occurs also when plug and socket
are in different applications (see bonobo). I think the delete event
gets lost?






-- 
        FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
         To unsubscribe: mail gnome-components-list-request@gnome.org with 
                       "unsubscribe" as the Subject.



--------------7F79F706936EBDF628960A14--

From otaylor@redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 8559 invoked from network); 21 Nov 1999 17:21:32 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 21 Nov 1999 17:21:32 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA10665
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 12:21:31 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id LAA23113;
	Sun, 21 Nov 1999 11:23:34 -0500
To: gtk-devel-list@redhat.com
Subject: Re: Ad-on hook idea (fwd)
References: <Pine.LNX.4.10.9911161753190.2158-100000@mini.dhs.org>
From: Owen Taylor <otaylor@redhat.com>
Date: 21 Nov 1999 11:23:34 -0500
In-Reply-To: redhog@mini.dhs.org's message of "Tue, 16 Nov 1999 18:02:42 +0100 (CET)"
Message-ID: <ybewvrb7r09.fsf@fresnel.labs.redhat.com>
Lines: 46
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


redhog@mini.dhs.org writes:

> When it comes to the wheel-scrolling thing, I have a little problem - I
> want _every_ button press/move/release that vis not used for something
> else for a the widget inside the scrolledwindow widget, to scroll the
> scrolledwindow widget. But I don't know how to get the knowledge of if
> some event has been used allready. If someone could help me with this, I
> would be ready with such a module in a few days!

FWIW, to deal with this problem, the existing mouse-wheel support
catches the scroll button events _before_ they are handled by anything
else. Search for 'scrollwheel' in gtkmain.c.

It isn't possible to add such a possibility in any sane way right now
from a module, though perhaps we should add generic "event snoopers"
like the key snoopers we have now.

So, two points:

 - I considered the left-over-mouse even approach before implementing
   the current mechanism and decided it wasn't useful.

 - A module that redirects left-over scrollwheel events to
   the relevant scrolled window would be rather useless, since
   GTK+ already will have sucked out all scrollwheel events
   that have a relevant scrolledwindow and sent them there
   before any other event processing happens.

I haven't tested the scrollwheel code recently, but when I
wrote it, I rebound my mouse to simulate the events and it
seemed to work.

Regards,
                                        Owen

[ Also, some people have suggested converting the button
  4-5 presses to a separate scrollwheel event at the GDK
  level for GTK+-1.4, which makes some sense to me,
  assuming that scrollwheel mice are here to stay. ] 





 

From nelson@crynwr.com  Thu May 11 17:52:44 2000
Received: (qmail 10827 invoked from network); 21 Nov 1999 17:28:00 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 21 Nov 1999 17:28:00 -0000
Received: from ns.crynwr.com (ns.crynwr.com [192.203.178.14])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id MAA10865
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 12:28:00 -0500
Received: (qmail 16784 invoked from network); 21 Nov 1999 17:28:26 -0000
Received: from desk.crynwr.com (206.150.82.98)
  by ns.crynwr.com with SMTP; 21 Nov 1999 17:28:26 -0000
Received: (qmail 3681 invoked by uid 501); 21 Nov 1999 17:28:25 -0000
From: Russell Nelson <nelson@crynwr.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun, 21 Nov 1999 12:28:24 -0500 (EST)
To: gtk-devel-list@redhat.com
Subject: Re: Ad-on hook idea (fwd)
In-Reply-To: <ybewvrb7r09.fsf@fresnel.labs.redhat.com>
References: <Pine.LNX.4.10.9911161753190.2158-100000@mini.dhs.org>
	<ybewvrb7r09.fsf@fresnel.labs.redhat.com>
X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs  Lucid
Message-ID: <14392.11077.358664.457143@desk.crynwr.com>
X-Face:  $K'YURj"g6ImvqTS_=]8)gqh!5;ElY<[.Rao%j8r+]iUfE{%|v%F<=mcq<6l{K=~mf&#:?"
 nslS]U~|x{2V=Eex_I#"9K~9)>?m7Lm={(j_&)SX~fzg&ST~P%QUhc{1p]c3@Zn1u*PZlkHM**X^vV
 l>GkB5y^Kz%w5p~^uDue]hL&ke,N;+Q<ImMCdCr~Kz--?|SS?DbZiaE;xPW/7k9u_cc(It%mvMNVk;
 qVk~

Owen Taylor writes:
 > [ Also, some people have suggested converting the button
 >   4-5 presses to a separate scrollwheel event at the GDK
 >   level for GTK+-1.4, which makes some sense to me,
 >   assuming that scrollwheel mice are here to stay. ] 

They do seem to be.  You can get them without paying much of a price
premium, from the various taiwanese vendors.  I've got one from A4Tech
which has four buttons and two scrollwheels (one for left/right, the
other for up/down).  Paid $25 for it as I recall, and it's the top of
their line.

-- 
-russ nelson <sig@russnelson.com>  http://russnelson.com
Crynwr sells support for free software  | PGPok | Government schools are so
521 Pleasant Valley Rd. | +1 315 268 1925 voice | bad that any rank amateur
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | can outdo them. Homeschool!

From glaurent@worldnet.fr  Thu May 11 17:52:44 2000
Received: (qmail 18600 invoked from network); 21 Nov 1999 17:43:55 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 21 Nov 1999 17:43:55 -0000
Received: from rogue.worldnet.fr (glaurent@p12-111.province.worldnet.fr [195.3.12.111])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA11297
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 12:43:53 -0500
Received: (from glaurent@localhost)
	by rogue.worldnet.fr (8.9.3/8.9.3) id SAA13148;
	Sun, 21 Nov 1999 18:43:27 +0100
Sender: glaurent@worldnet.fr
To: gtkmm@modeemi.cs.tut.fi, gtk-devel-list@redhat.com,
        gnome-announce-list@gnome.org
Subject: Announce: Gtk-- 1.1.4  
From: Guillaume Laurent <glaurent@parasoft.com>
Date: 21 Nov 1999 18:43:27 +0100
Message-ID: <m3g0xzbv0g.fsf@rogue.worldnet.fr>
Lines: 47
X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches"


Gtk-- 1.1.4
----------------- 
Gtk-- is a C++ interface for the popular GUI library gtk. Gtk-- provides 
convinient interface for C++ programmers to create graphical user 
interfaces with gtk's flexible OO framework. Highlights include typesafe 
callbacks, widgets extensible using inheritance and over 110 classes that 
can be freely combined to quickly create complex user interfaces. Gtk-- 
is free software distributed under GNU Library General Public License (LGPL). 

Gnome-- is starting to take shape.  A port of gnome-hello examples
actually compiles and run now. NOTE : you will have problems building
it if gnome is installed in /usr and Gtk-- in /usr/local - just
symlink /usr/local/lib/gnomemmConf.sh to /usr/lib and things will go
fine.

Special thanks to Malcolm Edwards for contributing a tutorial section,
as well as all our other tutorial contributors (Bernhard Rieder, Amy
Fong).  Keep up the good work.

Not much change to Gtk-- proper this time, but expect some big changes
next version when we start to cut over to namespaces.


Homepage: http://lazy.ton.tut.fi/gtk--/gtk--.html 
Ftp: ftp://ftp.gtk.org/pub/gtk/gtk-- 
Maillist: gtkmm@modeemi.cs.tut.fi 

Release Notes: 
Release: Gtk-- 1.1.4 (21 November 1999)
Get: gtkmm-1.1.4.tar.gz http://lazy.ton.tut.fi/gtk--/gtkmm-1.1.4.tar.gz

 * Alterations to improve gtkmmproc. 
 * Installation fixes for 3rd party widgets 
 * Data members accessors for Gtk_Adjustment. 
 * Spec file fixes (hvr). 
 * Tutorial improvements by Malcolm Edwards Bernhard Rieder 
 * Gnome-- example (NOTE : there is a Makefile problem - case where
   gnome is installed in /usr and Gtk-- gets installed in /usr/local
   aren't handled correctly).
 * Gnome_Stock namespace renamed to Gnome_Menu_Helpers for consistency 
 * Testdnd now works with largely gtk-- code 
 * Removed redundant 'box_' from Gnome_PropertyBox methods names.

-- 
					Guillaume
					http://www.worldnet.fr/~glaurent

From otaylor@redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 9592 invoked from network); 21 Nov 1999 18:28:15 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 21 Nov 1999 18:28:15 -0000
Received: from fresnel.labs.redhat.com (root@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id NAA12717
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 13:28:15 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id LAA23141;
	Sun, 21 Nov 1999 11:31:21 -0500
To: gtk-devel-list@redhat.com
Subject: Re: [Fwd: gtkplug commit]
References: <3836CD2D.D57BF00A@vlsivie.tuwien.ac.at>
From: Owen Taylor <otaylor@redhat.com>
Date: 21 Nov 1999 11:31:21 -0500
In-Reply-To: Dietmar Maurer's message of "Sat, 20 Nov 1999 17:32:45 +0100"
Message-ID: <ybeso1z7qna.fsf@fresnel.labs.redhat.com>
Lines: 62
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


Dietmar Maurer <dm@vlsivie.tuwien.ac.at> writes:

> I´ve observed the following problem with gtk_plug/sockets:
> 
> void
> gtk_plug_construct (GtkPlug *plug, guint32 socket_id)
> {
>   plug->socket_window = gdk_window_lookup (socket_id);
>   plug->same_app = TRUE;
> 
>   if (plug->socket_window == NULL)
>     {
>       plug->socket_window = gdk_window_foreign_new (socket_id);
>       plug->same_app = FALSE;
>     }
> }
> 
> if gdk_window_lookup return something != NULL we use the existing window
> 
> (without increasing the reference count!). But gtk_plug_unrealize
> always  unrefs the window wich causes the window to be destroyed.
> 
> This is why bobobo doesn´t work.

This looks like a real bug to me ... but it doesn't make
any sense to me that it would ever be triggered in
actual code unless the plug and socket were in the
same application, since a socket can only be used
once, so the gdk_window_lookup() is not going to return
non-null unless someone else did a gdk_window_lookup()
on that window for some reason. 
 
> A quick fix would be to "gdk_window_ref" the window:
> 
> gtk_plug_construct (GtkPlug *plug, guint32 socket_id)
> {
>   plug->socket_window = gdk_window_lookup (socket_id);
>   plug->same_app = TRUE;
> 
>   if (plug->socket_window == NULL)
>     {
>       plug->socket_window = gdk_window_foreign_new (socket_id);
>       plug->same_app = FALSE;
>     }
>   else gdk_window_ref (plug->socket_window);   /* reference the window
> */
> }

This is what I meant about GTK+ coding style:

 else
  gdk_window_ref (plug->socket_window);

> I´m sure this change will not break any code.

I'll look into this a bit more and probably apply the
patch once I commit the (very large) merge I'm currently
working on from the 1.2 branch to HEAD.

Regards,
                                        Owen

From oliver@samera.com  Thu May 11 17:52:44 2000
Received: (qmail 10454 invoked from network); 21 Nov 1999 19:11:24 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 21 Nov 1999 19:11:24 -0000
Received: from Polaris.Pla.net.PY (uucp@polaris.pla.net.py [198.67.140.10])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA14241
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 14:11:17 -0500
Received: (from uucp@localhost) by Polaris.Pla.net.PY (8.9.3/8.6.12) with UUCP id QAA26668 for gtk-devel-list@redhat.com; Sun, 21 Nov 1999 16:10:45 +0400
Received: from pla.net.py (IDENT:oliver@sojourner.samera.com [192.168.1.1])
	by samera.com (8.9.3/8.9.3) with ESMTP id QAA07761
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 16:10:30 -0300
Sender: oliver@samera.com
Message-ID: <38384395.39F89F02@pla.net.py>
Date: Sun, 21 Nov 1999 16:10:13 -0300
From: "Oliver Schulze L." <oliver@pla.net.py>
Reply-To: oliver@pla.net.py
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 i586)
X-Accept-Language: es-PY, es, en
MIME-Version: 1.0
To: "gtk-devel-list@redhat.com" <gtk-devel-list@redhat.com>
Subject: Posible theme refresh bug
Content-Type: multipart/mixed;
 boundary="------------5CCE602DB7C89E3278B6F7E0"

This is a multi-part message in MIME format.
--------------5CCE602DB7C89E3278B6F7E0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
I am experiencing a refreshing problem.

When you put a label inside an event_box, and make sucesive call
to the gtk_label_set_text() function, the text in the label
overwrite with the new label string.

This happend only with some pixmap themes.
I have spoken with the author of the theme and he believes that
maybe there is a problem with the gtk+-engine package.

I have include a simple code that reproduces the issue.

Some themes where I can reproduce the issue:
AbsoluteE
BeCool
Beta
BlueSteel
BlueTheme
Bluthe
Crome
E-Mac
Expensive
GTK_LARS
Gradient
IceBerg
Jander
Jed3
LCARS
LCD
LightSpeed
Marble
Marble3D
Metallic
MockMack
Pixmap
Porcelain
ShinyMetal
SkiBerg
Smoke-full
Torpedo
TrueBe
WoodenScraps
Yell-O
eMock
etheme
metallic_plum
odo
tildouf


I have: 
- RedHat 6.1
- RedHat 6.1 updates
- gnome-october (rpm distribution)
- gtk+ 1.2.5

Regards,
Oliver
-- 
Oliver Schulze L.
oliver@pla.net.py
Asuncion-Paraguay
http://www.pla.net.py/home/oliver/
--------------5CCE602DB7C89E3278B6F7E0
Content-Type: text/plain; charset=us-ascii;
 name="label_test.c"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="label_test.c"

/* example-start helloworld helloworld.c 
 * 
 * Modified helloworld.c from the gtk_tutorial
 * http://www.gtk.org
 * 
 * In this example, the label that is in the event_box does not refresh.
 * This happend if you are using the 'Marble3D' theme.
 * 
 * The vbox is in the main window.
 * The upper label(normal_label) is in the vbox
 * The event box(ebox) is in the vbox.
 * The lower label(event_label) is in the event box.
 * The button is in the vbox
 * 
 * oliver@pla.net.py
 */

#include <gtk/gtk.h>
#include <stdio.h>
#include <stdlib.h>

//-------------------------------------------------------------------------
GtkWidget *normal_label,
          *event_label;

gint timeout_callback()
{
	static char str[10];

	sprintf(str, "%ld", random());

	gtk_label_set_text(GTK_LABEL(normal_label), str);
	gtk_label_set_text(GTK_LABEL(event_label), str);
	
	return TRUE;
}
//-------------------------------------------------------------------------

/* This is a callback function. The data arguments are ignored
 * in this example. More on callbacks below. */
void hello( GtkWidget *widget,
            gpointer   data )
{
    g_print ("Hello World\n");
}

gint delete_event( GtkWidget *widget,
                   GdkEvent  *event,
		   gpointer   data )
{
    /* If you return FALSE in the "delete_event" signal handler,
     * GTK will emit the "destroy" signal. Returning TRUE means
     * you don't want the window to be destroyed.
     * This is useful for popping up 'are you sure you want to quit?'
     * type dialogs. */

    g_print ("delete event occurred\n");

    /* Change TRUE to FALSE and the main window will be destroyed with
     * a "delete_event". */

    return(TRUE);
}

/* Another callback */
void destroy( GtkWidget *widget,
              gpointer   data )
{
    gtk_main_quit();
}

int main( int   argc,
          char *argv[] )
{
    /* GtkWidget is the storage type for widgets */
    GtkWidget *window;
    GtkWidget *button,
              *vbox,
              *ebox;
    gint id_timeout;
    
    /* This is called in all GTK applications. Arguments are parsed
     * from the command line and are returned to the application. */
    gtk_init(&argc, &argv);
    
    /* create a new window */
    window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
    
    /* When the window is given the "delete_event" signal (this is given
     * by the window manager, usually by the 'close' option, or on the
     * titlebar), we ask it to call the delete_event () function
     * as defined above. The data passed to the callback
     * function is NULL and is ignored in the callback function. */
    gtk_signal_connect (GTK_OBJECT (window), "delete_event",
			GTK_SIGNAL_FUNC (delete_event), NULL);
    
    /* Here we connect the "destroy" event to a signal handler.  
     * This event occurs when we call gtk_widget_destroy() on the window,
     * or if we return 'FALSE' in the "delete_event" callback. */
    gtk_signal_connect (GTK_OBJECT (window), "destroy",
			GTK_SIGNAL_FUNC (destroy), NULL);
    
    /* Sets the border width of the window. */
    gtk_container_set_border_width (GTK_CONTAINER (window), 10);
    
    /* Creates a new button with the label "Hello World". */
    button = gtk_button_new_with_label ("Hello World");
    
    /* When the button receives the "clicked" signal, it will call the
     * function hello() passing it NULL as its argument.  The hello()
     * function is defined above. */
    gtk_signal_connect (GTK_OBJECT (button), "clicked",
			GTK_SIGNAL_FUNC (hello), NULL);
    
    /* This will cause the window to be destroyed by calling
     * gtk_widget_destroy(window) when "clicked".  Again, the destroy
     * signal could come from here, or the window manager. */
    gtk_signal_connect_object (GTK_OBJECT (button), "clicked",
			       GTK_SIGNAL_FUNC (gtk_widget_destroy),
			       GTK_OBJECT (window));
    
    /* This packs the button into the window (a gtk container). */
    //gtk_container_add (GTK_CONTAINER (window), button);

//-------------------------------------------------------------------------
/*
 *	label_test block
 */
		//vertical box
		vbox  = gtk_vbox_new(FALSE, 0);
		gtk_container_add (GTK_CONTAINER (window), vbox);

		gtk_box_pack_end (GTK_BOX(vbox), button, FALSE, FALSE, 10);

		//label in an event box
		ebox = gtk_event_box_new();
		normal_label = gtk_label_new("12345678901234567890");

		gtk_container_add(GTK_CONTAINER(ebox), normal_label);
		gtk_box_pack_end (GTK_BOX(vbox), ebox, FALSE, FALSE, 10);

		//normal label
		event_label = gtk_label_new("12345678901234567890");

		gtk_box_pack_end (GTK_BOX(vbox), event_label, FALSE, FALSE, 10);

		//the timeout
		id_timeout = gtk_timeout_add(100,
		                            (GtkFunction)timeout_callback, NULL);
//-------------------------------------------------------------------------
		    
    /* The final step is to display this newly created widget. */
    //gtk_widget_show (button);
    
    /* and the window */
    gtk_widget_show_all (window);
    
    /* All GTK applications must have a gtk_main(). Control ends here
     * and waits for an event to occur (like a key press or
     * mouse event). */
    gtk_main ();
    
    return(0);
}
/* example-end */

--------------5CCE602DB7C89E3278B6F7E0--

From kde@sun.ceronet.com  Thu May 11 17:52:44 2000
Received: (qmail 13752 invoked from network); 21 Nov 1999 23:37:06 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 21 Nov 1999 23:37:06 -0000
Received: from sun.ceronet.com (root@sun.ceronet.com [195.76.46.98])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA23920
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 18:37:06 -0500
Received: from ceronet.com ([195.235.214.149])
	by sun.ceronet.com (8.8.7/8.8.7) with ESMTP id AAA01734
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 00:32:03 +0100
Sender: kde@sun.ceronet.com
Message-ID: <383882C3.814ACE4A@ceronet.com>
Date: Mon, 22 Nov 1999 00:39:47 +0100
From: Antonio Campos <acampos@ceronet.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: gtk redraw improvement
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

GTK redraws a little slowly. Would it be nice if the containers (or the
parent widgets) got a pixmap buffer for drawing the children into it, so
that when the widget has to redraw, it splash the final image completely
on the screen?.
This way, the number of redraw calls to the windowing system will reduce
to only draw the final image. You don't have to call for the redraw
every time a child widget is being draw (which is one of the things that
slow down GTK, I think. Correct me if I am wrong, please.).

A last question:
Double buffered widgets could speed things up? I have heared some rumors
about new versions of GTK having this feature. How can this speed things
up?. I don't understand why. I think that the pixmap method described
earlier could totally resolve the problem, couldn't it?

From damon@mail.redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 17118 invoked from network); 21 Nov 1999 23:39:59 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 21 Nov 1999 23:39:59 -0000
Received: from mail1.svr.pol.co.uk (mail1.svr.pol.co.uk [195.92.193.18])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA24004
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 18:39:58 -0500
Received: from modem-60.lutetium.dialup.pol.co.uk
	([62.136.35.60] helo=karuna.freeserve.co.uk ident=damon)
	by mail1.svr.pol.co.uk with esmtp (Exim 3.03 #0)
	id 11pgaL-0001mB-00
	for gtk-devel-list@redhat.com; Sun, 21 Nov 1999 23:39:57 +0000
Sender: damon@mail.redhat.com
Message-ID: <38388091.AAF62EA@karuna.freeserve.co.uk>
Date: Sun, 21 Nov 1999 23:30:25 +0000
From: Damon Chaplin <damon@karuna.freeserve.co.uk>
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.36 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: Plans for drawing in GDK-1.4.
References: <ybe66z38qnj.fsf@fresnel.labs.redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Owen Taylor wrote:
> 
> I've been recently planning some changes
> to the draw/update model in GDK for 1.4.
> 
> I've put a description of some of my plans at:
> 
>  http://www.gtk.org/~otaylor/gdk-1.4.html


I noticed in gtklayout.h that you didn't think the freeze & thaw functions
worked. I just wanted to point out that I have found them useful, when using
a GnomeCanvas.

I needed to scroll the canvas, but have the entire canvas redrawn since
parts of it needed updating. Without the freeze/thaw calls this would flicker,
as the bits were copied around and then the canvas was later redrawn in an
idle handler.

So I hope something like this stays in 1.4, if it is still useful.


Another minor point is that I'm not sure the default widget draw function
(gtk_widget_real_draw) should send an expose event. If you use a widget
like a drawing area, and connect to both "draw" and "expose_event", then
when a "draw" signal is emitted both handlers get called. I'm not sure
it's good for consistency. It took me a while to figure out why I was
drawing everything twice all the time. (Though since this 'feature' is used
in the scribble-simple example, it may be used in a lot of code.)

Damon

From dereks@kd-dev.com  Thu May 11 17:52:44 2000
Received: (qmail 17049 invoked from network); 21 Nov 1999 23:59:00 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 21 Nov 1999 23:59:00 -0000
Received: from archer.kd-dev.com (dereks@archer.kd-dev.com [206.124.150.175])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA25120
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 18:58:59 -0500
Received: from localhost (dereks@localhost)
	by archer.kd-dev.com (8.8.7/8.8.7) with ESMTP id PAA03347
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 15:53:24 -0800
Date: Sun, 21 Nov 1999 15:53:24 -0800 (PST)
From: Derek Simkowiak <dereks@kd-dev.com>
To: gtk-devel-list@redhat.com
Subject: Re: gtk redraw improvement
In-Reply-To: <383882C3.814ACE4A@ceronet.com>
Message-ID: <Pine.LNX.4.04.9911211547180.3318-100000@archer.kd-dev.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

[re: Gtk+ being too slow in redrawing:]
> I think that the pixmap method described earlier could totally resolve
> the problem, couldn't it?

	Why do people keep posting that Gtk+ is slow to redraw?

	Havoc has said that Gtk+ redraws are fast because they are so
close so Xlib.  I believe him.  In my experience, Gtk+ redraws are fairly
fast (I've never noticed them being slow).

	Are these people just confusing slowness in Gnome with slowness in
Gtk+?  Or are they confusing single-buffered flickering with slowness of
redraw?  Or is some extra pixmap buffering system really called for?

	...and in answer to the double-buffering question of the original
poster, it wouldn't make redraws faster, but *smoother*.  Things like
smooth scrolling (as found in MS-Windows) would happen without flickering.

--Derek

From kde@sun.ceronet.com  Thu May 11 17:52:44 2000
Received: (qmail 15550 invoked from network); 22 Nov 1999 00:42:21 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 00:42:21 -0000
Received: from sun.ceronet.com (root@sun.ceronet.com [195.76.46.98])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA26774
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 19:42:20 -0500
Received: from ceronet.com ([195.235.214.149])
	by sun.ceronet.com (8.8.7/8.8.7) with ESMTP id BAA01940
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 01:37:13 +0100
Sender: kde@sun.ceronet.com
Message-ID: <38389224.11F7F91F@ceronet.com>
Date: Mon, 22 Nov 1999 01:45:24 +0100
From: Antonio Campos <acampos@ceronet.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: gtk redraw improvement
References: <Pine.LNX.4.04.9911211547180.3318-100000@archer.kd-dev.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Derek Simkowiak wrote:

> [re: Gtk+ being too slow in redrawing:]
> > I think that the pixmap method described earlier could totally resolve
> > the problem, couldn't it?
>
>         Why do people keep posting that Gtk+ is slow to redraw?
>
>         Havoc has said that Gtk+ redraws are fast because they are so
> close so Xlib.  I believe him.  In my experience, Gtk+ redraws are fairly
> fast (I've never noticed them being slow).
>
>         Are these people just confusing slowness in Gnome with slowness in
> Gtk+?  Or are they confusing single-buffered flickering with slowness of
> redraw?  Or is some extra pixmap buffering system really called for?
>
>         ...and in answer to the double-buffering question of the original
> poster, it wouldn't make redraws faster, but *smoother*.  Things like
> smooth scrolling (as found in MS-Windows) would happen without flickering.
>
> --Derek
>
> --
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with
>                        "unsubscribe" as the Subject.

So, are all those improvements going into the API...?
I think that a widget set for the future has be smooth. By now, KDE is by far
smoother than GTK.
So, I think is a very very important think to have in mind...

From glaurent@worldnet.fr  Thu May 11 17:52:44 2000
Received: (qmail 19522 invoked from network); 22 Nov 1999 00:49:55 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 00:49:55 -0000
Received: from linux2.worldnet.fr (p12-111.province.worldnet.fr [195.3.12.111])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA27113
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 19:49:53 -0500
Received: (from glaurent@localhost)
	by linux2.worldnet.fr (8.9.3/8.9.3) id BAA21080;
	Mon, 22 Nov 1999 01:49:32 +0100
Sender: glaurent@worldnet.fr
To: gtk-devel-list@redhat.com
Subject: Re: Ad-on hook idea (fwd)
References: <Pine.LNX.4.10.9911161753190.2158-100000@mini.dhs.org> <ybewvrb7r09.fsf@fresnel.labs.redhat.com>
From: Guillaume Laurent <glaurent@worldnet.fr>
Date: 22 Nov 1999 01:49:31 +0100
In-Reply-To: Owen Taylor's message of "21 Nov 1999 11:23:34 -0500"
Message-ID: <m3yabrxsdg.fsf@linux2.worldnet.fr>
Lines: 10
X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches"

Owen Taylor <otaylor@redhat.com> writes:

>   assuming that scrollwheel mice are here to stay.

Yes. Everyone I've seen starting to use one has never gone back. It's
a real comfort you can hardly do without once you got used to it.

-- 
					Guillaume.
					http://www.worldnet.fr/~glaurent

From miguel@gnu.org  Thu May 11 17:52:44 2000
Received: (qmail 28195 invoked from network); 22 Nov 1999 01:09:55 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 01:09:55 -0000
Received: from erandi.nuclecu.unam.mx (miguel@[132.248.237.35])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id UAA27908
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 20:09:54 -0500
Received: (from miguel@localhost)
	by erandi.nuclecu.unam.mx (8.9.3/8.9.3) id OAA01211;
	Sun, 21 Nov 1999 14:02:34 -0600
Date: Sun, 21 Nov 1999 14:02:34 -0600
Message-Id: <199911212002.OAA01211@erandi.nuclecu.unam.mx>
From: Miguel de Icaza <miguel@gnu.org>
To: gtk-devel-list@redhat.com
In-reply-to: <383882C3.814ACE4A@ceronet.com> (message from Antonio Campos on
	Mon, 22 Nov 1999 00:39:47 +0100)
Subject: Re: gtk redraw improvement
X-FileLength: are infinite where infinity is set to 255 characters
References:  <383882C3.814ACE4A@ceronet.com>


> Double buffered widgets could speed things up? I have heared some rumors
> about new versions of GTK having this feature. How can this speed things
> up?. I don't understand why. I think that the pixmap method described
> earlier could totally resolve the problem, couldn't it?

This is going to appear on Gtk 1.4

And as far as I know the approach used in Gtk 1.4 is basically what
you propose.

Miguel.

From miguel@gnu.org  Thu May 11 17:52:44 2000
Received: (qmail 32145 invoked from network); 22 Nov 1999 01:19:05 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 01:19:05 -0000
Received: from erandi.nuclecu.unam.mx (miguel@[132.248.237.35])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id UAA28245
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 20:19:04 -0500
Received: (from miguel@localhost)
	by erandi.nuclecu.unam.mx (8.9.3/8.9.3) id OAA01241;
	Sun, 21 Nov 1999 14:11:44 -0600
Date: Sun, 21 Nov 1999 14:11:44 -0600
Message-Id: <199911212011.OAA01241@erandi.nuclecu.unam.mx>
From: Miguel de Icaza <miguel@gnu.org>
To: gtk-devel-list@redhat.com

In-reply-to: <38389224.11F7F91F@ceronet.com> (message from Antonio Campos on
	Mon, 22 Nov 1999 01:45:24 +0100)
Subject: Re: gtk redraw improvement
FCC: ~/Mail/outbox.txt
X-FileLength: are infinite where infinity is set to 255 characters
References: <Pine.LNX.4.04.9911211547180.3318-100000@archer.kd-dev.com> <38389224.11F7F91F@ceronet.com>
--text follows this line--

> I think that a widget set for the future has be smooth. By now, KDE is by far
> smoother than GTK.

By far is an exageration, but yes, they look better in some limited setups.

From kde@sun.ceronet.com  Thu May 11 17:52:44 2000
Received: (qmail 3839 invoked from network); 22 Nov 1999 01:23:57 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 01:23:57 -0000
Received: from sun.ceronet.com (root@sun.ceronet.com [195.76.46.98])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id UAA28474
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 20:23:56 -0500
Received: from ceronet.com ([195.235.214.149])
	by sun.ceronet.com (8.8.7/8.8.7) with ESMTP id CAA02025
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 02:18:56 +0100
Sender: kde@sun.ceronet.com
Message-ID: <38389BEB.7F69515E@ceronet.com>
Date: Mon, 22 Nov 1999 02:27:07 +0100
From: Antonio Campos <acampos@ceronet.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: Unidentified subject!
References: <199911212011.OAA01241@erandi.nuclecu.unam.mx>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Miguel de Icaza wrote:

> In-reply-to: <38389224.11F7F91F@ceronet.com> (message from Antonio Campos on
>         Mon, 22 Nov 1999 01:45:24 +0100)
> Subject: Re: gtk redraw improvement
> FCC: ~/Mail/outbox.txt
> X-FileLength: are infinite where infinity is set to 255 characters
> References: <Pine.LNX.4.04.9911211547180.3318-100000@archer.kd-dev.com> <38389224.11F7F91F@ceronet.com>
> --text follows this line--
>
> > I think that a widget set for the future has be smooth. By now, KDE is by far
> > smoother than GTK.
>
> By far is an exageration, but yes, they look better in some limited setups.
>
> --
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with
>                        "unsubscribe" as the Subject.

Hey, it's not of my interest to bother GTK people with my own problems. I don't know GTK or
GNOME internals either. So my only interest is to point out some features that I think GTK should have if
we want to beat Windows or KDE... (By now Windows is quite smooth, and this is something desktop users
feel instantenously)...

From kaz@FootPrints.net  Thu May 11 17:52:44 2000
Received: (qmail 10897 invoked from network); 22 Nov 1999 01:29:13 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 01:29:13 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id UAA28741
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 20:29:13 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11piHy-0001vf-00
	for gtk-devel-list@redhat.com; Sun, 21 Nov 1999 17:29:06 -0800
Date: Sun, 21 Nov 1999 17:29:06 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
Subject: Re: Unidentified subject!
In-Reply-To: <38389BEB.7F69515E@ceronet.com>
Message-ID: <Pine.LNX.4.10.9911211724430.7367-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Mon, 22 Nov 1999, Antonio Campos wrote:

> we want to beat Windows or KDE... (By now Windows is quite smooth, and this
> is something desktop users feel instantenously)...

Last I checked, Windoze still doesn't let you move the window of an app that
has stopped ``responding''. So we can safely say that it has a few unresolved
problems.:)  The smoothness is thanks to advances in the fabrication of faster
processors and graphics chipsets.

From kde@sun.ceronet.com  Thu May 11 17:52:44 2000
Received: (qmail 13878 invoked from network); 22 Nov 1999 01:34:35 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 01:34:35 -0000
Received: from sun.ceronet.com (root@sun.ceronet.com [195.76.46.98])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id UAA28963
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 20:34:35 -0500
Received: from ceronet.com ([195.235.214.149])
	by sun.ceronet.com (8.8.7/8.8.7) with ESMTP id CAA02044
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 02:29:35 +0100
Sender: kde@sun.ceronet.com
Message-ID: <38389E6A.7412E02D@ceronet.com>
Date: Mon, 22 Nov 1999 02:37:46 +0100
From: Antonio Campos <acampos@ceronet.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: Unidentified subject!
References: <Pine.LNX.4.10.9911211724430.7367-100000@ashi.FootPrints.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Kaz Kylheku wrote:

> On Mon, 22 Nov 1999, Antonio Campos wrote:
>
> > we want to beat Windows or KDE... (By now Windows is quite smooth, and this
> > is something desktop users feel instantenously)...
>
> Last I checked, Windoze still doesn't let you move the window of an app that
> has stopped ``responding''. So we can safely say that it has a few unresolved
> problems. :)  The smoothness is thanks to advances in the fabrication of faster
> processors and graphics chipsets.
>
> --
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with
>                        "unsubscribe" as the Subject.

Certainly we have beaten Windows in a lot a questions, but the smoothness of
Windows is not only due to the graphics chipset (it's an important factor
obviously). I think that Windows is not using GDI on a few applications. I think
is really using DirectDraw to write directly to video memory. If it is so, I don't
like this way of doing things, because DirectDraw is a focus of security problems
(no restrictions over who writes to video memory...).
Nevertheless, I expect GTK to include double buffered widget in future releases...

From dereks@kd-dev.com  Thu May 11 17:52:44 2000
Received: (qmail 16121 invoked from network); 22 Nov 1999 01:42:11 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 01:42:11 -0000
Received: from archer.kd-dev.com (dereks@archer.kd-dev.com [206.124.150.175])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id UAA29196
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 20:42:11 -0500
Received: from localhost (dereks@localhost)
	by archer.kd-dev.com (8.8.7/8.8.7) with ESMTP id RAA03660
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 17:36:35 -0800
Date: Sun, 21 Nov 1999 17:36:35 -0800 (PST)
From: Derek Simkowiak <dereks@kd-dev.com>
To: gtk-devel-list@redhat.com
Subject: Widget smoothness (was: Unidentified subject!)
In-Reply-To: <Pine.LNX.4.10.9911211724430.7367-100000@ashi.FootPrints.net>
Message-ID: <Pine.LNX.4.04.9911211730470.3318-100000@archer.kd-dev.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

>  The smoothness is thanks to advances in the fabrication of faster
> processors and graphics chipsets.

	I don't like MS one bit, but this is not necessarily true.
Certain operations are much smoother in MS-Windows than it is in GTK+,
even running on the same "processors and graphics chipsets".

	I don't know anything about the MSFC, but I'm guessing they are
using double-buffering.  Another factor in the illusion of smoothness is
their "smoothscroll" feature, which quickly scrolls down a window only a
few pixels (or one pixel?) at a time rather than jumping down 10 or 20
pixels per keystroke/scrollwheel movement.

	GTK+ 1.4 will have double-buffering, so that problem has already
been addressed.  The real question is, will GTK+ have the smoothscroll
feature (which has alot to do with user interaction but very little to do
with redrawing)?


--Derek

From kde@sun.ceronet.com  Thu May 11 17:52:44 2000
Received: (qmail 25478 invoked from network); 22 Nov 1999 01:55:02 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 01:55:02 -0000
Received: from sun.ceronet.com (root@sun.ceronet.com [195.76.46.98])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id UAA29596
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 20:55:01 -0500
Received: from ceronet.com ([195.235.214.149])
	by sun.ceronet.com (8.8.7/8.8.7) with ESMTP id CAA02087
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 02:50:01 +0100
Sender: kde@sun.ceronet.com
Message-ID: <3838A334.F17BABE@ceronet.com>
Date: Mon, 22 Nov 1999 02:58:12 +0100
From: Antonio Campos <acampos@ceronet.com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-15 i586)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Re: Widget smoothness (was: Unidentified subject!)
References: <Pine.LNX.4.04.9911211730470.3318-100000@archer.kd-dev.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Derek Simkowiak wrote:

> >  The smoothness is thanks to advances in the fabrication of faster
> > processors and graphics chipsets.
>
>         I don't like MS one bit, but this is not necessarily true.
> Certain operations are much smoother in MS-Windows than it is in GTK+,
> even running on the same "processors and graphics chipsets".
>
>         I don't know anything about the MSFC, but I'm guessing they are
> using double-buffering.  Another factor in the illusion of smoothness is
> their "smoothscroll" feature, which quickly scrolls down a window only a
> few pixels (or one pixel?) at a time rather than jumping down 10 or 20
> pixels per keystroke/scrollwheel movement.
>
>         GTK+ 1.4 will have double-buffering, so that problem has already
> been addressed.  The real question is, will GTK+ have the smoothscroll
> feature (which has alot to do with user interaction but very little to do
> with redrawing)?
>
> --Derek
>
> --
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with
>                        "unsubscribe" as the Subject.

I don't think smooth scroll is a must have... It can grow up cpu
utilization, and it's something not strictly necessary... Faster redrawing
(with double-buffering) is something to have, because it can even decrease
cpu utilization...

From dereks@kd-dev.com  Thu May 11 17:52:44 2000
Received: (qmail 4267 invoked from network); 22 Nov 1999 02:10:10 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 02:10:10 -0000
Received: from archer.kd-dev.com (dereks@archer.kd-dev.com [206.124.150.175])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id VAA30305
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 21:10:08 -0500
Received: from localhost (dereks@localhost)
	by archer.kd-dev.com (8.8.7/8.8.7) with ESMTP id SAA03739
	for <gtk-devel-list@redhat.com>; Sun, 21 Nov 1999 18:04:33 -0800
Date: Sun, 21 Nov 1999 18:04:33 -0800 (PST)
From: Derek Simkowiak <dereks@kd-dev.com>
To: gtk-devel-list@redhat.com
Subject: Re: Widget smoothness (was: Unidentified subject!)
In-Reply-To: <3838A334.F17BABE@ceronet.com>
Message-ID: <Pine.LNX.4.04.9911211751550.3318-100000@archer.kd-dev.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

> I don't think smooth scroll is a must have... It can grow up cpu
> utilization, and it's something not strictly necessary...

	It is one of those eye-candy things that can make a big difference
to people coming from an MS or Mac background.  I believe it is important
to have it--regardless of whether or not it's an effective use of
processor power, the current state of the personal computing world is that
people like to see it, and have already become accustomed to it under
other platforms.

	Do we want people to fire up a GTK+-based app (or Gnome, for that
matter) and have it seem primitive?  MS's IE, one of the most-used apps in
the world (as sad as that is) has had the smooth scroll feature for a
couple of years now--an app without it will feel like 1995 to all
non-technical endusers who will be switching to Linux in the near future.

	If CPU utilization really is an issue, we could build in an option
into the toolkit to turn it off.  Personally, I do not believe it would be
that big a deal (testing is necessary to confirm either viewpoint).

>  Faster redrawing (with double-buffering) is something to have,
> because it can even decrease cpu utilization...

	Although a pixmap buffer would obviously cut CPU usage, I don't
see how double-buffering can decrease processor usage more than a single
buffer. If you have the time, please email me (privately) explaining how
that works...?


Thank You,
Derek Simkowiak
dereks@kd-dev.com

From miguel@gnu.org  Thu May 11 17:52:44 2000
Received: (qmail 7585 invoked from network); 22 Nov 1999 05:54:12 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 05:54:12 -0000
Received: from erandi.nuclecu.unam.mx (miguel@cs3-3.modems.unam.mx [132.248.64.3])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id AAA03506
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 00:54:10 -0500
Received: (from miguel@localhost)
	by erandi.nuclecu.unam.mx (8.9.3/8.9.3) id SAA01612;
	Sun, 21 Nov 1999 18:46:51 -0600
Date: Sun, 21 Nov 1999 18:46:51 -0600
Message-Id: <199911220046.SAA01612@erandi.nuclecu.unam.mx>
From: Miguel de Icaza <miguel@gnu.org>
To: gtk-devel-list@redhat.com
In-reply-to: <3838A334.F17BABE@ceronet.com> (message from Antonio Campos on
	Mon, 22 Nov 1999 02:58:12 +0100)
Subject: Re: Widget smoothness (was: Unidentified subject!)
X-Lost: In case of doubt, make it sound convincing
References: <Pine.LNX.4.04.9911211730470.3318-100000@archer.kd-dev.com> <3838A334.F17BABE@ceronet.com>


> I don't think smooth scroll is a must have... It can grow up cpu
> utilization, and it's something not strictly necessary... Faster redrawing
> (with double-buffering) is something to have, because it can even decrease
> cpu utilization...

it is an illusion.

The draw process is exactly the same, and it might even be slower on
some video cards that can accelerate various graphics commands.

Miguel

From dm@mail.redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 7143 invoked from network); 22 Nov 1999 08:01:51 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 08:01:51 -0000
Received: from mailhost.vlsivie.tuwien.ac.at (root@mouse.vlsivie.tuwien.ac.at [128.130.40.221])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id DAA06199;
	Mon, 22 Nov 1999 03:01:50 -0500
Received: from vlsivie.tuwien.ac.at (really [128.130.40.155]) by vlsivie.tuwien.ac.at
	via smail with esmtp (ident dm using rfc1413)
	id <m11poQ1-001FHBC@mailhost.vlsivie.tuwien.ac.at> (Debian Smail3.2.0.102)
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 09:01:49 +0100 (CET) 
Sender: dm@mail.redhat.com
Message-ID: <3838F86C.5E51CC9F@vlsivie.tuwien.ac.at>
Date: Mon, 22 Nov 1999 09:01:48 +0100
From: Dietmar Maurer <dm@vlsivie.tuwien.ac.at>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: de-AT, en
MIME-Version: 1.0
To: otaylor@redhat.com, gtk-devel-list@redhat.com
Subject: [Fwd: gtkplug commit]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

>This looks like a real bug to me ... but it doesn't make
>any sense to me that it would ever be triggered in
>actual code unless the plug and socket were in the
>same application, since a socket can only be used
>once,

I observed that the bonobo code uses the same socket window more than
once? Why can it only be used once? Here is the putput of my program. If
I start it multiple times it aquires the same socket window! (which
causes the problems on the component plug which is only started once)

nui# ./gshell
set_remote_window 134798632
nui# ./gshell
set_remote_window 134800488
nui# ./gshell
set_remote_window 134798632
nui# ./gshell
set_remote_window 134800488
nui# ./gshell
set_remote_window 134798632

>so the gdk_window_lookup() is not going to return
>non-null unless someone else did a gdk_window_lookup()
>on that window for some reason.


From pbg1854@garnet.acns.fsu.edu  Thu May 11 17:52:44 2000
Received: (qmail 24542 invoked from network); 22 Nov 1999 17:26:52 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 17:26:52 -0000
Received: from garnet.acns.fsu.edu (gmhub.acns.fsu.edu [146.201.2.30])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA30254
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 12:26:52 -0500
From: pbg1854@garnet.acns.fsu.edu
Received: from garnet2.acns.fsu.edu (garnet2-fi.acns.fsu.edu [192.168.197.2])
	by garnet.acns.fsu.edu (8.9.3/8.9.3) with ESMTP id MAA136494
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 12:26:40 -0500
Received: from dial922.acns.fsu.edu (dial922.acns.fsu.edu [146.201.36.58])
	by garnet2.acns.fsu.edu (8.9.3/8.9.3) with ESMTP id MAA121598
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 12:26:36 -0500
Received: (qmail 3264 invoked by uid 500); 22 Nov 1999 16:48:43 -0000
Date: Mon, 22 Nov 1999 11:48:43 -0500
To: gtk-devel-list@redhat.com
Subject: Re: Unidentified subject!
Message-ID: <19991122114843.A3204@omega.heresy>
References: <Pine.LNX.4.10.9911211724430.7367-100000@ashi.FootPrints.net> <38389E6A.7412E02D@ceronet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <38389E6A.7412E02D@ceronet.com>; from acampos@ceronet.com on Mon, Nov 22, 1999 at 02:37:46AM +0100

On Mon, Nov 22, 1999 at 02:37:46AM +0100, Antonio Campos wrote:
> Certainly we have beaten Windows in a lot a questions, but the
> smoothness of Windows is not only due to the graphics chipset (it's
> an important factor obviously). I think that Windows is not using
> GDI on a few applications. I think is really using DirectDraw to
> write directly to video memory. If it is so, I don't like this way
> of doing things, because DirectDraw is a focus of security problems
> (no restrictions over who writes to video memory...).  Nevertheless,
> I expect GTK to include double buffered widget in future releases...

Don't forget that sometimes X programs are run over a network link.
Smooth scrolling would be slow as hell if it has to be transfered over
that, even if it's 100 BaseT ethernet. It doesn't matter *what* you
use for graphics hardware in this case. And wouldn't double buffering
be *slower* over a network link? If you use standard X calls, only the
commands for those calls are transmitted, but if you use a buffer, you
have to send every pixel in the region over the link, right?

Pete

From daveb@idealab.com  Thu May 11 17:52:44 2000
Received: (qmail 29137 invoked from network); 22 Nov 1999 18:13:56 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 18:13:56 -0000
Received: from idealab.com (santino.idealab.com [206.132.100.34])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id NAA00440
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 13:13:55 -0500
Received: (qmail 13378 invoked by uid 535); 22 Nov 1999 18:13:55 -0000
Received: from localhost (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 22 Nov 1999 18:13:55 -0000
Date: Mon, 22 Nov 1999 10:13:55 -0800 (PST)
From: David Benson <daveb@idealab.com>
X-Sender: daveb@luca.hivemind.idealab.com
To: gtk-devel-list@redhat.com
Subject: Re: Unidentified subject!
In-Reply-To: <19991122114843.A3204@omega.heresy>
Message-ID: <Pine.LNX.4.10.9911221007420.12909-100000@luca.hivemind.idealab.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Actually in double-buffering X one usually uses
server-side pixmaps.  Only in rare apps that
want to render pixels themselves into XImages (like doom)
are pixels transmitted.

Another key point is that windows apps gain speed by doing
the scrolling copy in hardware (in X one uses via XCopyArea...).
This is what makes it so generally speedy, and would
generally be hampered by double-buffering, esp if the
buffer winds up in main memory as opposed to on card memory.

- Dave

On Mon, 22 Nov 1999 pbg1854@garnet.acns.fsu.edu wrote:

> On Mon, Nov 22, 1999 at 02:37:46AM +0100, Antonio Campos wrote:
> > Certainly we have beaten Windows in a lot a questions, but the
> > smoothness of Windows is not only due to the graphics chipset (it's
> > an important factor obviously). I think that Windows is not using
> > GDI on a few applications. I think is really using DirectDraw to
> > write directly to video memory. If it is so, I don't like this way
> > of doing things, because DirectDraw is a focus of security problems
> > (no restrictions over who writes to video memory...).  Nevertheless,
> > I expect GTK to include double buffered widget in future releases...
> 
> Don't forget that sometimes X programs are run over a network link.
> Smooth scrolling would be slow as hell if it has to be transfered over
> that, even if it's 100 BaseT ethernet. It doesn't matter *what* you
> use for graphics hardware in this case. And wouldn't double buffering
> be *slower* over a network link? If you use standard X calls, only the
> commands for those calls are transmitted, but if you use a buffer, you
> have to send every pixel in the region over the link, right?
> 
> Pete
> 
> 
> -- 
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with 
>                        "unsubscribe" as the Subject.
> 
> 

From kaz@FootPrints.net  Thu May 11 17:52:44 2000
Received: (qmail 6831 invoked from network); 22 Nov 1999 18:33:01 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 18:33:01 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id NAA01807
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 13:33:00 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11pyGm-0006z9-00
	for gtk-devel-list@redhat.com; Mon, 22 Nov 1999 10:32:56 -0800
Date: Mon, 22 Nov 1999 10:32:56 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
Subject: Re: Unidentified subject!
In-Reply-To: <19991122114843.A3204@omega.heresy>
Message-ID: <Pine.LNX.4.10.9911221022240.26651-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Mon, 22 Nov 1999 pbg1854@garnet.acns.fsu.edu wrote:

> Don't forget that sometimes X programs are run over a network link.
> Smooth scrolling would be slow as hell if it has to be transfered over
> that, even if it's 100 BaseT ethernet. It doesn't matter *what* you
> use for graphics hardware in this case. And wouldn't double buffering
> be *slower* over a network link? If you use standard X calls, only the
> commands for those calls are transmitted, but if you use a buffer, you
> have to send every pixel in the region over the link, right?

There is no point to doing double buffering for scrolling, because it's just a
bitblt operation, followed by a redraw of some small area. So there may be some
lack of smoothness near the edge away from which the scrolling is taking place.

Double buffering doesn't mean doing image puts over the network; it means that
you draw to a hidden canvas, and then blit from the canvas to the window.  Thus
the user doesn't see the construction of the drawing, just the final result
appearing simultaneously. 

This can be nice if you have a complex drawing, such as dialog box with many
widgets.

Smooth scrolling means scrolling text at a better resolution than the height of
a row of text, for example, scrolling by a single raster line at a time. This
creates an illusion of continous motion, allowing the eye to better track to 
the next line when you are reading.  Some existing X apps have smooth
scrolling: e.g.  ghostview.

From ee96090@fe.up.pt  Thu May 11 17:52:44 2000
Received: (qmail 19134 invoked from network); 22 Nov 1999 20:46:47 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 20:46:47 -0000
Received: from tweety.fe.up.pt (tweety.fe.up.pt [193.136.28.27])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id PAA10494
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 15:46:46 -0500
Received: from lorosae.fe.up.pt (lorosae.fe.up.pt [193.136.28.35])
	by tweety.fe.up.pt (8.9.3/8.9.3) with ESMTP id UAA32420
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 20:46:38 GMT
Received: from riff.fe.up.pt (ee96090@riff.fe.up.pt [193.136.28.14])
	by lorosae.fe.up.pt (8.9.3/8.9.3) with ESMTP id UAA20988
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 20:46:38 GMT
Received: from localhost (ee96090@localhost)
	by riff.fe.up.pt (8.9.3/8.9.3) with SMTP id UAA12484
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 20:46:36 GMT
X-Authentication-Warning: riff.fe.up.pt: ee96090 owned process doing -bs
Date: Mon, 22 Nov 1999 20:46:36 +0000 (WET)
From: =?iso-8859-1?Q?Gustavo_Jo=E3o_Alves_Marques_Carneiro?= <ee96090@fe.up.pt>
To: gtk-devel-list@redhat.com
Subject: Re: Widget smoothness (was: Unidentified subject!)
In-Reply-To: <Pine.LNX.4.04.9911211730470.3318-100000@archer.kd-dev.com>
Message-ID: <Pine.OSF.3.96.991122203618.17964A-100000@riff.fe.up.pt>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

	If I may say my opinion, double buffering can be either good or
terrible, depending on how much free memory the X server has. 
	While the X server has free memory to create pixmaps, everything
works fine and redrawing is usually faster (depending on the widget,
theme, etc.). 
	When the X server stops having enough memory to create offscreen
pixmaps, I'm not sure what would happen. I don't actually know how it
works, but supposing the pixmap has to be created on the client side, then
wverything would become very slow.
	I think it would be safer to keep a boolean in every widget
indicating if double buffering should be used for that widget (instance). 
Then, the user would be able to customize if all widgets would be double
buffered, or gtk would autodetect for each widget if double buffering
should be used, depending on the amount of free X memory. 
	


Gustavo J. A. M. Carneiro
[http://reinolinux.fe.up.pt/~ee96090]

From garetxe@euskaltel.es  Thu May 11 17:52:44 2000
Received: (qmail 2606 invoked from network); 22 Nov 1999 21:10:01 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 21:10:01 -0000
Received: from eui1m.euskaltel.es (eui1m.euskaltel.es [212.55.8.5])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA11992
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 16:10:00 -0500
Received: from euskalnet.net ([212.8.67.61]) by eui1m.euskaltel.es
          (Netscape Messaging Server 3.6)  with ESMTP id AAA5E5A
          for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 22:27:11 +0100
Sender: garetxe@euskaltel.es
Message-ID: <384458CE.3E77AB09@euskalnet.net>
Date: Wed, 01 Dec 1999 00:07:58 +0100
From: =?UTF-8?B?ScOxYWtpIEdhcmPDrWE=?= Etxebarria <garetxe@euskalnet.net>
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: gtk-devel-list@redhat.com
Subject: Keypad and GtkEntry
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

    Hi,

  I'm developing an application that at some point wants to accept some
input from the keyboard in a Gtkentry. When the user hits enter, the
focus should go to some other Gtkentry, so he can continue typing in it.
The program catches the activate signal and everything goes well, but
only if you hit the "usual" enter. If you hit the enter in the keypad,
it doesn't emit this activate signal. It it quite annoying for the user,
since the Gtkentries in this program are intended to receive numbers, so
the Keypad is the best place to type them.
    I have made a quick patch to gtkentry.c (against gtk 1.2.6), but
maybe this behaviour has some advantage, I would like to know it, if
this is the case. Or maybe I am missing something. Just forgive my
ignorance if I am mistaken.
    Anyway, here goes the patch:

--- gtkentry.c.old Wed Dec  1 00:04:09 1999
+++ gtkentry.c Tue Nov 30 23:30:23 1999
@@ -1114,6 +1114,7 @@
  gtk_move_forward_character (entry);
       break;
     case GDK_Return:
+    case GDK_KP_Enter:
       return_val = TRUE;
       gtk_widget_activate (widget);
       break;

Greets,
Iñaki

From kenelson@ece.ucdavis.edu  Thu May 11 17:52:44 2000
Received: (qmail 2696 invoked from network); 22 Nov 1999 21:33:16 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 22 Nov 1999 21:33:16 -0000
Received: from sequoia.ece.ucdavis.edu (root@sequoia.ece.ucdavis.edu [169.237.32.12])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA12842
	for <gtk-devel-list@redhat.com>; Mon, 22 Nov 1999 16:33:15 -0500
Received: from sequoia.ece.ucdavis.edu (kenelson@localhost [127.0.0.1])
	by sequoia.ece.ucdavis.edu (8.9.3/8.9.3) with ESMTP id NAA28172;
	Mon, 22 Nov 1999 13:33:13 -0800 (PST)
Message-Id: <199911222133.NAA28172@sequoia.ece.ucdavis.edu>
X-Mailer: exmh version 2.0.3
X-face: 
 RinRV?cII^~g?cLc9;-D}8xnP^:6hX}*,%&@y"6p7xm^Z]V<7(`zzI!/#s%[2G'fTVC+b"*
 4eYfecJ4=,gHu4o_{Z[VG{Em*{tC^LKZ6eUDc?PI0@dk}3"kJ7*"y8*hMv\qz[C5djlU#AQh0Cq.%W
 @2kSd~S<<NcD7L4'O#`737_IEe02\s!gB6HW13]sD)'$+''!eRE7jPH\G(R&(+:Tu8bs[kr?ixX}x!
 -6`4*-B[UB_Wl!rZyL/$R(xi`vb"+t6osqR?gPX^r);Zpm'5(b/Rs[uGBN>&}]!;ZNm(wUE4=
X-url: http://www.ece.ucdavis.edu/~kenelson
To: gtk-devel-list@redhat.com
cc: kenelson@sequoia.ece.ucdavis.edu
Subject: Re: Glib Semaphores 
In-reply-to: Your message of "Tue, 16 Nov 1999 19:40:35 PST."
             <Pine.LNX.4.10.9911161843530.31849-100000@ashi.FootPrints.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Mon, 22 Nov 1999 13:33:12 -0800
From: Karl Nelson <kenelson@ece.ucdavis.edu>


On addition of GSemaphore:

We seem not to have a conclusion to this yet.  One person 
said great idea, one concludes horrible.  

I don't agree that join is equal to semaphores.  That is 
only true in the limited case of threads which terminate
imediately.  When doing some computation work like filtering
in semaphores may be used for check pointing prior to a thread
terminating.  But I doubt that Kaz Kylheku and I will ever
agree on this point.  

Does everyone agree with Kaz's opinion?  If so I won't 
bring up the issue again, but I just want to be sure.  

Do we have some sort of vote site to decide these things or does 
one person objecting equal exclude?  Who decides this kind of thing?

--Karl 

From kaz@FootPrints.net  Thu May 11 17:52:44 2000
Received: (qmail 13571 invoked from network); 23 Nov 1999 18:17:09 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 23 Nov 1999 18:17:09 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id NAA23952
	for <gtk-devel-list@redhat.com>; Tue, 23 Nov 1999 13:17:05 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11qKUx-0005Wj-00; Tue, 23 Nov 1999 10:17:03 -0800
Date: Tue, 23 Nov 1999 10:17:03 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
cc: kenelson@sequoia.ece.ucdavis.edu
Subject: Re: Glib Semaphores 
In-Reply-To: <199911222133.NAA28172@sequoia.ece.ucdavis.edu>
Message-ID: <Pine.LNX.4.10.9911230938320.20563-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Mon, 22 Nov 1999, Karl Nelson wrote:

> On addition of GSemaphore:
> 
> We seem not to have a conclusion to this yet.  One person 
> said great idea, one concludes horrible.  
> 
> I don't agree that join is equal to semaphores.  That is 
> only true in the limited case of threads which terminate
> imediately.  When doing some computation work like filtering
> in semaphores may be used for check pointing prior to a thread
> terminating.  But I doubt that Kaz Kylheku and I will ever
> agree on this point.  
> 
> Does everyone agree with Kaz's opinion?  If so I won't 
> bring up the issue again, but I just want to be sure.  

You can make a binary semaphore very easily using mutexes and conditions.  Just
protect a binary flag with a mutex, and then your up and down operations (or
signal and wait, or v and p) are just:

	semaphore::up()
	{
	    mutex.lock();
	    flag = true;
	    mutex.unlock();
	    cond.signal();
	}

	semaphore::down()
	{
	    mutex.lock();
	    while (!flag)
		cond.wait(mutex);
	    mutex.unlock();
	}

A counting semaphore can be dome similarly, just replace the flag with
a counter. This one assumes that the counter varies between zero and
some per-object configured maximum.

	semaphore::up()
	{
	    mutex.lock();
	    old = counter;
	    if (counter < maximum)
		counter++;
	    mutex.unlock();

	    if (old == 0)
		cond.signal(); // signal only on transition from 0
	}

	semaphore::down()
	{
	    mutex.lock();
	    while (counter == 0)
		cond.wait(mutex);
	    counter--;
	    mutex.unlock();
	}


This is probably less efficient than a carefully coded semaphore implemented
using lower level primitives, which will be different on each supported
platform. Such an implementation could, for example, use atomic operations to
update the counter or flag instead of relying on a mutex. There is no
standard API for such operations.

For a challenge, try implementing mutexes and conditions using only semaphores.
Don't forget the condition broadcast operation! ;)

From federico@redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 14145 invoked from network); 24 Nov 1999 09:00:10 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 24 Nov 1999 09:00:10 -0000
Received: from guanabana.labs.redhat.com (root@inter1201.internet.com.mx [200.34.210.121])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id EAA12979
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 04:00:09 -0500
Received: (from federico@localhost)
	by guanabana.labs.redhat.com (8.9.3/8.9.3) id UAA30173;
	Mon, 22 Nov 1999 20:51:37 -0500
Date: Mon, 22 Nov 1999 20:51:37 -0500
Message-Id: <199911230151.UAA30173@guanabana.labs.redhat.com>
X-Authentication-Warning: guanabana.labs.redhat.com: federico set sender to federico@redhat.com using -f
From: Federico Mena Quintero <federico@redhat.com>
To: gtk-devel-list@redhat.com
In-reply-to: <38388091.AAF62EA@karuna.freeserve.co.uk> (message from Damon
	Chaplin on Sun, 21 Nov 1999 23:30:25 +0000)
Subject: Re: Plans for drawing in GDK-1.4.
X-FYI: Jack the ripper was a flatulent man.
References: <ybe66z38qnj.fsf@fresnel.labs.redhat.com> <38388091.AAF62EA@karuna.freeserve.co.uk>

>  I noticed in gtklayout.h that you didn't think the freeze & thaw functions
>  worked. I just wanted to point out that I have found them useful, when using
>  a GnomeCanvas.

The freeze/thaw functions of the GtkLayout widget are essentialy a
hack (they are my fault) :-)  The problem I was trying to address was
that when you change the GnomeCanvas zoom factor, you have to:

	1. Calculate the new size in pixels of the scrolling region,

	2. tell the GtkLayout to set its new size,

	3. scroll the GtkLayout so as to keep the view centered,

	4. redraw the whole thing since the zoom factor changed.

The actual problem is that GtkLayout provides no way to set an
absolute scrolling offset; you have to modify each adjustment
separately, and so if you scroll diagonally things will move in one
direction after another.  This looks really bad.

The correct solution is to provide Owen's GdkSuperwin functionality
for GtkLayout.  This thing can do diagonal guffaw scrolling properly;
it is the thing used in Mozilla these days.

  Federico

From federico@redhat.com  Thu May 11 17:52:44 2000
Received: (qmail 14218 invoked from network); 24 Nov 1999 09:00:14 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 24 Nov 1999 09:00:14 -0000
Received: from guanabana.labs.redhat.com (root@inter1201.internet.com.mx [200.34.210.121])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id EAA12983
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 04:00:10 -0500
Received: (from federico@localhost)
	by guanabana.labs.redhat.com (8.9.3/8.9.3) id VAA06859;
	Mon, 22 Nov 1999 21:01:50 -0500
Date: Mon, 22 Nov 1999 21:01:50 -0500
Message-Id: <199911230201.VAA06859@guanabana.labs.redhat.com>
X-Authentication-Warning: guanabana.labs.redhat.com: federico set sender to federico@redhat.com using -f
From: Federico Mena Quintero <federico@redhat.com>
To: gtk-devel-list@redhat.com
In-reply-to: <Pine.LNX.4.04.9911211751550.3318-100000@archer.kd-dev.com>
	(message from Derek Simkowiak on Sun, 21 Nov 1999 18:04:33 -0800
	(PST))
Subject: Re: Widget smoothness (was: Unidentified subject!)
X-strfry: Sautee STRING briskly.
References:  <Pine.LNX.4.04.9911211751550.3318-100000@archer.kd-dev.com>

>  	Do we want people to fire up a GTK+-based app (or Gnome, for that
>  matter) and have it seem primitive?  MS's IE, one of the most-used apps in
>  the world (as sad as that is) has had the smooth scroll feature for a
>  couple of years now--an app without it will feel like 1995 to all
>  non-technical endusers who will be switching to Linux in the near future.
>  
>  	If CPU utilization really is an issue, we could build in an option
>  into the toolkit to turn it off.  Personally, I do not believe it would be
>  that big a deal (testing is necessary to confirm either viewpoint).

You cannot say whether CPU utilization is an issue until you have
profiled the thing.  Period.

And the point is moot.  What you do to smooth-scroll is create an
off-screen pixmap, draw a thin region there (say, your scrolling
increment), and then bitblt the contents of the screen pixel by
pixel.  The bitblt is essentialy free, since the video card does it.
So it should not use much more CPU than not doing smooth scrolling.

  Federico

From otaylor@redhat.com  Thu May 11 17:52:45 2000
Received: (qmail 10182 invoked from network); 24 Nov 1999 15:08:25 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 24 Nov 1999 15:08:25 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id KAA29317
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 10:08:24 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id JAA28340;
	Wed, 24 Nov 1999 09:10:11 -0500
To: gtk-devel-list@redhat.com
Subject: Re: [Fwd: gtkplug commit]
References: <3838F86C.5E51CC9F@vlsivie.tuwien.ac.at>
From: Owen Taylor <otaylor@redhat.com>
Date: 24 Nov 1999 09:10:10 -0500
In-Reply-To: Dietmar Maurer's message of "Mon, 22 Nov 1999 09:01:48 +0100"
Message-ID: <ybeyabovv3x.fsf@fresnel.labs.redhat.com>
Lines: 46
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Dietmar Maurer <dm@vlsivie.tuwien.ac.at> writes:

> >This looks like a real bug to me ... but it doesn't make
> >any sense to me that it would ever be triggered in
> >actual code unless the plug and socket were in the
> >same application, since a socket can only be used
> >once,
> 
> I observed that the bonobo code uses the same socket window more than
> once? Why can it only be used once? Here is the putput of my program. If
> I start it multiple times it aquires the same socket window! (which
> causes the problems on the component plug which is only started once)
> 
> nui# ./gshell
> set_remote_window 134798632
> nui# ./gshell
> set_remote_window 134800488
> nui# ./gshell
> set_remote_window 134798632
> nui# ./gshell
> set_remote_window 134800488
> nui# ./gshell
> set_remote_window 134798632

Well, yes, if you run a X client multiple times then the resource ID's
will be recycled. In fact, eventually they will be recycled within
the same running X client.

But, as I thought, if the above causes problems for the plug component,
then there is a bug, either in plug/socket or in Bonobo. 

For gdk_window_lookup() to return the same GdkWindow for two different
X windows is simply not correct. There are two possibilities here:

 - The DestroyNotify is not being caught at all.
 - The CORBA transport and X event queue are out of sync so
   that the new plug window is received before the DestroyNotify
   is received for the old one.

The first is a memory leak, the second, worse because the
DestroyNotify would be interpreted as referring to the old
X window, not the new X window.

Regards,
                                        Owen

From dm@mail.redhat.com  Thu May 11 17:52:45 2000
Received: (qmail 4527 invoked from network); 24 Nov 1999 16:01:25 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 24 Nov 1999 16:01:25 -0000
Received: from mailhost.vlsivie.tuwien.ac.at (root@mouse.vlsivie.tuwien.ac.at [128.130.40.221])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id LAA32725;
	Wed, 24 Nov 1999 11:01:24 -0500
Received: from vlsivie.tuwien.ac.at (really [128.130.40.155]) by vlsivie.tuwien.ac.at
	via smail with esmtp (ident dm using rfc1413)
	id <m11qer8-001FKWC@mailhost.vlsivie.tuwien.ac.at> (Debian Smail3.2.0.102)
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 17:01:18 +0100 (CET) 
Sender: dm@mail.redhat.com
Message-ID: <383C0BC4.5392B234@vlsivie.tuwien.ac.at>
Date: Wed, 24 Nov 1999 17:01:08 +0100
From: Dietmar Maurer <dm@vlsivie.tuwien.ac.at>
X-Mailer: Mozilla 4.5 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: de-AT, en
MIME-Version: 1.0
To: otaylor@redhat.com, gtk-devel-list@redhat.com,
        "gnome-components-list@gnome.org" <gnome-components-list@gnome.org>
Subject: gtk-plug
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Owen Taylor wrote:
>    Well, yes, if you run a X client multiple times then the resource
ID's
>    will be recycled. In fact, eventually they will be recycled within
>    the same running X client.
>    But, as I thought, if the above causes problems for the plug
component,
>    then there is a bug, either in plug/socket or in Bonobo.
>    For gdk_window_lookup() to return the same GdkWindow for two
different
>    X windows is simply not correct. There are two possibilities here:
>     - The DestroyNotify is not being caught at all.
>     - The CORBA transport and X event queue are out of sync so
>      that the new plug window is received before the DestroyNotify
>      is received for the old one.
>    The first is a memory leak, the second, worse because the
>    DestroyNotify would be interpreted as referring to the old
>    X window, not the new X window.

I'm not an gtk/XWindows expert,  but I think the Destroy Notify is too
late. Simply increasing the reference count (when it is returned from
gdk_window_lookup) solves the problem, and I don't understand what's
wrong with it, because we also do a gdk_window_unref in
gtk_plug_unrealize. Bonobo depends on a working Plug/Socket
implementation.

wfw

    Dietmar

From oliver@samera.com  Thu May 11 17:52:45 2000
Received: (qmail 5983 invoked from network); 24 Nov 1999 17:48:29 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 24 Nov 1999 17:48:29 -0000
Received: from Polaris.Pla.net.PY (uucp@polaris.pla.net.py [198.67.140.10])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA08085
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 12:48:23 -0500
Received: (from uucp@localhost) by Polaris.Pla.net.PY (8.9.3/8.6.12) with UUCP id OAA05862 for gtk-devel-list@redhat.com; Wed, 24 Nov 1999 14:47:51 +0400
Received: from pla.net.py (IDENT:oliver@sojourner.samera.com [192.168.1.1])
	by samera.com (8.9.3/8.9.3) with ESMTP id OAA32607
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 14:45:12 -0300
Sender: oliver@samera.com
Message-ID: <383C2414.19576370@pla.net.py>
Date: Wed, 24 Nov 1999 14:44:52 -0300
From: "Oliver Schulze L." <oliver@pla.net.py>
Reply-To: oliver@pla.net.py
X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.13 i586)
X-Accept-Language: es-PY, es, en
MIME-Version: 1.0
To: gtk-devel-list <gtk-devel-list@redhat.com>
Subject: Re: Posible theme refresh bug
References: <38384395.39F89F02@pla.net.py>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Oliver Schulze L." wrote:
> 
> Hi,
> I am experiencing a refreshing problem.
> 
> When you put a label inside an event_box, and make sucesive call
> to the gtk_label_set_text() function, the text in the label
> overwrite with the new label string.
> 
> This happend only with some pixmap themes.
> I have spoken with the author of the theme and he believes that
> maybe there is a problem with the gtk+-engine package.
> 
> I have include a simple code that reproduces the issue.
> 
> Some themes where I can reproduce the issue:
> AbsoluteE
> BeCool
> Beta
> BlueSteel
> BlueTheme
> Bluthe
> Crome
> E-Mac
> Expensive
> GTK_LARS
> Gradient
> IceBerg
> Jander
> Jed3
> LCARS
> LCD
> LightSpeed
> Marble
> Marble3D
> Metallic
> MockMack
> Pixmap
> Porcelain
> ShinyMetal
> SkiBerg
> Smoke-full
> Torpedo
> TrueBe
> WoodenScraps
> Yell-O
> eMock
> etheme
> metallic_plum
> odo
> tildouf
> 
> I have:
> - RedHat 6.1
> - RedHat 6.1 updates
> - gnome-october (rpm distribution)
> - gtk+ 1.2.5
> 
> Regards,
> Oliver
> --
> Oliver Schulze L.
> oliver@pla.net.py
> Asuncion-Paraguay
> http://www.pla.net.py/home/oliver/
> 

Hi,
I'm writing againg about this issue.
I want to know if this is a know issue. 
Is there is a gtk-engine devel list? So I can try to find a
solution there.

I have developed a program that use this kind of configuration,
and have recived many feedback regarding this issue.
I always says that this is a problem of gtk or gtk-engine, but
I'm not for sure. I can only reproduce it.

thanks
Oliver  
-- 
Oliver Schulze L.
oliver@pla.net.py
Asuncion-Paraguay
http://www.pla.net.py/home/oliver/

From otaylor@redhat.com  Thu May 11 17:52:45 2000
Received: (qmail 682 invoked from network); 24 Nov 1999 19:58:06 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 24 Nov 1999 19:58:06 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA18801
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 14:58:06 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id OAA01897;
	Wed, 24 Nov 1999 14:00:47 -0500
To: gtk-devel-list@redhat.com
Subject: First pass at double-buffered drawing
From: Owen Taylor <otaylor@redhat.com>
Date: 24 Nov 1999 14:00:47 -0500
Message-ID: <ybeaeo31zq8.fsf@fresnel.labs.redhat.com>
Lines: 26
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Since there seems to be a strong interest in the idea
of double-bufferingback, I've checked my current working
tree into CVS on the branch gtk-no-flicker. 

So, (allowing for usual anon-cvs propagation delays),
you should be able to get it from there.

 - This code/API is still very much in flux
 - There are no docs, not even a ChangeLog. 
 - Some things don't work even in testgtk, it has not been
   tested with _anything_ other than testgtk.
 - It's completely unoptimized; it creates and destroys
   GC's all over the place, etc.

But it is sort of neat; it certainly opaque-resizes
far, far, better than GTK+ has ever done before.

And in general, the code is much simpler than it was
before; I was able to remove a considerable amount
of the most complex parts of gtkwidget.c by putting the
draw queueing logic into GDK.

Regards,
                                        Owen

From eeyem@u.washington.edu  Thu May 11 17:52:45 2000
Received: (qmail 20003 invoked from network); 24 Nov 1999 20:42:09 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 24 Nov 1999 20:42:09 -0000
Received: from jason04.u.washington.edu (root@jason04.u.washington.edu [140.142.78.5])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id PAA21548
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 15:42:08 -0500
Received: from dante42.u.washington.edu (eeyem@dante42.u.washington.edu [140.142.15.202])
	by jason04.u.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id MAA21282
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 12:42:06 -0800
Received: from localhost (eeyem@localhost)
	by dante42.u.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id MAA12934
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 12:42:06 -0800
Date: Wed, 24 Nov 1999 12:42:05 -0800 (PST)
From: Evan Martin <eeyem@u.washington.edu>
To: gtk-devel-list@redhat.com
Subject: GtkCList row operations
Message-ID: <Pine.A41.4.10.9911241233550.117608-100000@dante42.u.washington.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Wouldn't it make more sense for the gtk_clist_* functions to operate on
GtkCListRow*'s instead of row numbers?

If I want to do an operation on each row of a clist, I currently must
write something like:

	int i;
	for (i = 0; i < GTK_CLIST(clist)->rows; i++)
		gtk_clist_<some_operation>(GTK_CLIST(clist), i);

The clist operations all internally call g_list_nth(clist->row_list, row),
which means that this for loop iterates through (rowcount*(rowcount-1))/2
list items.  I believe that translates to O(n**2) time.  It would be O(n)
time with GtkCListRow*'s.

Or is there another reason to use row indicies?

Evan.


From Jens-Reimer@t-online.de  Thu May 11 17:52:45 2000
Received: (qmail 22846 invoked from network); 24 Nov 1999 21:56:09 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 24 Nov 1999 21:56:09 -0000
Received: from mailout04.btx.dtag.de (mailout04.btx.dtag.de [194.25.2.152])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA25595
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 16:56:07 -0500
Received: from fwd01.btx.dtag.de ([194.25.2.161])
	by mailout04.btx.dtag.de with smtp 
	id 11qkMM-0004Ig-00; Wed, 24 Nov 1999 22:53:54 +0100
Received: from meinpc.t-online.de (0402102285-0001(btxid)@[62.158.174.177]) 
	by fwd01.btx.dtag.de with smtp
	id <m11qkLf-0004lnC>; Wed, 24 Nov 1999 22:53:11 +0100
Received: from localhost (jens-reimer@localhost [127.0.0.1])
	by meinpc.t-online.de (8.9.3/8.9.3) with ESMTP id WAA02182
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 22:49:02 GMT
Date: Wed, 24 Nov 1999 22:49:02 +0000 (GMT)
Reply-To: jens reimer <jens-reimer@t-online.de>
To: GTK Mailinglist <gtk-devel-list@redhat.com>
Subject: GTK--1.0.2 Make-Fehler
Message-ID: <Pine.LNX.4.20.9911242246020.2139-100000@meinpc.t-online.de>
X-No-Archive: Yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Sender: 0402102285-0001@t-dialin.net
From: Jens-Reimer@t-online.de (jens reimer)

Hallo,
i have problems to compile the GTK-1.0.2

Make stops with the following message:

 /bin/sh ../../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -DG_LOG_DOMAIN=\"Gnome--\"            -I. -I./.. -I..             -I../../src -I../../src -I../../src/gtk--            -I../../gdk-- -I../..            -I/usr/local/include -I/usr/X11R6/include -I/usr/lib/glib/include    -g -O2 -Wall -Wno-unused  -c icon-list.cc
 c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -DG_LOG_DOMAIN=\"Gnome--\" -I. -I./.. -I.. -I../../src -I../../src -I../../src/gtk-- -I../../gdk-- -I../.. -I/usr/local/include -I/usr/X11R6/include -I/usr/lib/glib/include -g -O2 -Wall -Wno-unused -c  -fPIC -DPIC icon-list.cc -o icon-list.lo
 icon-list.gen_h: In method `Gnome_IconList::Gnome_IconList(GnomeIconList *)':
 icon-list.gen_h:165: `struct GnomeIconList' has no member named `icon_width'
 icon-list.gen_h:167: `struct GnomeIconList' has no member named `is_editable'
 make[4]: *** [icon-list.lo] Error 1
 
Which package do i need to successfully compile?
 
 
I`m using Suse 6.2
with gnome-libs, gnome-core

-- 
Tschau ;-)
jens



From glaurent@worldnet.fr  Thu May 11 17:52:45 2000
Received: (qmail 22240 invoked from network); 24 Nov 1999 22:26:56 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 24 Nov 1999 22:26:56 -0000
Received: from rogue.worldnet.fr (glaurent@p12-111.province.worldnet.fr [195.3.12.111])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id RAA27392
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 17:26:55 -0500
Received: (from glaurent@localhost)
	by rogue.worldnet.fr (8.9.3/8.9.3) id XAA19162;
	Wed, 24 Nov 1999 23:26:27 +0100
Sender: glaurent@worldnet.fr
To: jens reimer <jens-reimer@t-online.de>
Cc: GTK Mailinglist <gtk-devel-list@redhat.com>
Subject: Re: GTK--1.0.2 Make-Fehler
References: <Pine.LNX.4.20.9911242246020.2139-100000@meinpc.t-online.de>
From: Guillaume Laurent <glaurent@worldnet.fr>
Date: 24 Nov 1999 23:26:26 +0100
In-Reply-To: Jens-Reimer@t-online.de's message of "Wed, 24 Nov 1999 22:49:02 +0000 (GMT)"
Message-ID: <m3puwz1q7h.fsf@rogue.worldnet.fr>
Lines: 20
X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches"

Jens-Reimer@t-online.de (jens reimer) writes:

> Hallo,
> i have problems to compile the GTK-1.0.2

It's very old, next to obsolete. I suggest you get v1.1.5 as soon as we 
release it.

>  icon-list.gen_h:165: `struct GnomeIconList' has no member named `icon_width'
>  icon-list.gen_h:167: `struct GnomeIconList' has no member named `is_editable'
> Which package do i need to successfully compile?

Older gnome-libs. :-)

Actually, for a quick temporary fix : just edit the file
(gnome--/icon-list.gen_h), and comment out the call to
gnome_icon_list_construct().

-- 
						Guillaume

From jrb@aware-of-vacuity.labs.redhat.com  Thu May 11 17:52:45 2000
Received: (qmail 20649 invoked from network); 24 Nov 1999 23:56:22 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 24 Nov 1999 23:56:22 -0000
Received: from aware-of-vacuity.labs.redhat.com (root@aware-of-vacuity.labs.redhat.com [207.175.42.55])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA31733
	for <gtk-devel-list@redhat.com>; Wed, 24 Nov 1999 18:56:22 -0500
Received: from localhost (IDENT:jrb@localhost [127.0.0.1])
	by aware-of-vacuity.labs.redhat.com (8.9.3/8.9.3) with ESMTP id SAA10787;
	Wed, 24 Nov 1999 18:56:27 -0500
Message-Id: <199911242356.SAA10787@aware-of-vacuity.labs.redhat.com>
To: gnome-devel-list@gnome.org
cc: gtk-devel-list@redhat.com
From: jrb@redhat.com
Reply-to: jrb@redhat.com
Subject: GTK+ Widget Repository.
Date: Wed, 24 Nov 1999 18:56:27 -0500
Sender: jrb@aware-of-vacuity.labs.redhat.com

Hi,

I set up a Widget repository for GTK+/GNOME widgets.  It's a little bare
right now, but if anyone has any code that they can contribute, I'd
appreciate it.

Check out http://developer.gnome.org/tools/repo/

Thanks,
-Jonathan

From J.A.K.Mouw@its.tudelft.nl  Thu May 11 17:52:45 2000
Received: (qmail 31296 invoked from network); 25 Nov 1999 09:11:21 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 25 Nov 1999 09:11:21 -0000
Received: from duteinh.et.tudelft.nl (duteinh.et.tudelft.nl [130.161.42.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id EAA22840
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 04:11:20 -0500
Received: from dutein71 by duteinh.et.tudelft.nl (8.9.3/BB-2.0)
	id KAA22800; Thu, 25 Nov 1999 10:11:16 +0100 (MET)
Date: Thu, 25 Nov 1999 10:11:16 +0100 (MET)
Message-Id: <199911250911.KAA22800@duteinh.et.tudelft.nl>
From: Erik Mouw <J.A.K.Mouw@its.tudelft.nl>
To: jens-reimer@t-online.de
Cc: gtk-devel-list@redhat.com
Subject: Re: GTK--1.0.2 Make-Fehler
In-Reply-To: <Pine.LNX.4.20.9911242246020.2139-100000@meinpc.t-online.de>
Organization: Eric conspiracy secret labs
X-Face: "!Z|1XjFg!3Iw)BwM^M\k)J5KHiPddz}#/Zw%?$&Q!xqob"OA|})3_@&BTTiQERo?/^g[Z<9P4R8:5C:aqq.cw!hotLc=+u-"+1rq@9$V^8PbOUlodyi_sejt+D`iqkLpx$>.aXl%vnfPIt"LK|/%>94_Zrm8jy?`_[RKt'TuoxUxfk(gMhY(n|DBBl~c$dhO>G%6}R4+DGX3|idBm4oU&UM/XUP4I9aoN{]`ax%B?rgD(I3OJ<62Y6L
X-Mailer: XCmail 0.99.6 - with PGP support, PGP engine version 0.5
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
X-Eric-Conspiracy: There is no conspiracy!
X-Loop: erik@it.et.tudelft.nl
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

On Wed, 24 Nov 1999 22:49:02 +0000 (GMT), jens reimer wrote:
> i have problems to compile the GTK-1.0.2

This is really ancient, use gtk+-1.0.6 if you want to stick to the 1.0
series, or better use gtk+-1.2.6. Note that gtk+-1.0.6 hasn't been
maintained for over a year.

> Make stops with the following message:
> 
>  /bin/sh ../../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../..
> -I../.. -I../.. -DG_LOG_DOMAIN=\"Gnome--\"            -I. -I./.. -I..          
>   -I../../src -I../../src -I../../src/gtk--            -I../../gdk-- -I../..   
>         -I/usr/local/include -I/usr/X11R6/include -I/usr/lib/glib/include    -g
> -O2 -Wall -Wno-unused  -c icon-list.cc
>  c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -DG_LOG_DOMAIN=\"Gnome--\"
> -I. -I./.. -I.. -I../../src -I../../src -I../../src/gtk-- -I../../gdk-- -I../..
> -I/usr/local/include -I/usr/X11R6/include -I/usr/lib/glib/include -g -O2 -Wall
> -Wno-unused -c  -fPIC -DPIC icon-list.cc -o icon-list.lo
>  icon-list.gen_h: In method `Gnome_IconList::Gnome_IconList(GnomeIconList *)':
>  icon-list.gen_h:165: `struct GnomeIconList' has no member named `icon_width'
>  icon-list.gen_h:167: `struct GnomeIconList' has no member named `is_editable'
>  make[4]: *** [icon-list.lo] Error 1
>  
> Which package do i need to successfully compile?

None (read on).

> I`m using Suse 6.2

Just install the gtk+-1.2 package and the gtk+-1.2 developer package. SuSE
6.2 comes standard with gtk+-1.2.x.

> with gnome-libs, gnome-core

SuSE also comes with GNOME stuff and AFAIK there are newer packages on the
GNOME site (sorry I can't check, the GNOME web site is down).


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2785859  Fax: +31-15-2781843  Email J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/


From glaurent@worldnet.fr  Thu May 11 17:52:45 2000
Received: (qmail 21027 invoked from network); 25 Nov 1999 10:05:59 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 25 Nov 1999 10:05:59 -0000
Received: from rogue.worldnet.fr (glaurent@p12-111.province.worldnet.fr [195.3.12.111])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id FAA24478
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 05:05:58 -0500
Received: (from glaurent@localhost)
	by rogue.worldnet.fr (8.9.3/8.9.3) id LAA20562;
	Thu, 25 Nov 1999 11:05:59 +0100
Sender: glaurent@worldnet.fr
To: gtk-devel-list@redhat.com
Cc: Erik Mouw <J.A.K.Mouw@its.tudelft.nl>
Subject: Re: GTK--1.0.2 Make-Fehler
References: <199911250911.KAA22800@duteinh.et.tudelft.nl>
From: Guillaume Laurent <glaurent@worldnet.fr>
Date: 25 Nov 1999 11:05:59 +0100
In-Reply-To: Erik Mouw's message of "Thu, 25 Nov 1999 10:11:16 +0100 (MET)"
Message-ID: <m31z9e28e0.fsf@rogue.worldnet.fr>
Lines: 15
X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches"

Erik Mouw <J.A.K.Mouw@its.tudelft.nl> writes:

> On Wed, 24 Nov 1999 22:49:02 +0000 (GMT), jens reimer wrote:
> > i have problems to compile the GTK-1.0.2
> 
> This is really ancient, use gtk+-1.0.6

He was talking about Gtk--.

> >  c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../.. -DG_LOG_DOMAIN=\"Gnome--\"

See ? 'c++'. :-)

-- 
						Guillaume

From J.A.K.Mouw@its.tudelft.nl  Thu May 11 17:52:45 2000
Received: (qmail 21697 invoked from network); 25 Nov 1999 10:08:00 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 25 Nov 1999 10:08:00 -0000
Received: from duteinh.et.tudelft.nl (duteinh.et.tudelft.nl [130.161.42.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id FAA24553
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 05:07:59 -0500
Received: from dutein71 by duteinh.et.tudelft.nl (8.9.3/BB-2.0)
	id LAA23259; Thu, 25 Nov 1999 11:07:47 +0100 (MET)
Date: Thu, 25 Nov 1999 11:07:47 +0100 (MET)
Message-Id: <199911251007.LAA23259@duteinh.et.tudelft.nl>
From: Erik Mouw <J.A.K.Mouw@its.tudelft.nl>
To: glaurent@worldnet.fr
Cc: gtk-devel-list@redhat.com
Subject: Re: GTK--1.0.2 Make-Fehler
In-Reply-To: <m31z9e28e0.fsf@rogue.worldnet.fr>
Organization: Eric conspiracy secret labs
X-Face: "!Z|1XjFg!3Iw)BwM^M\k)J5KHiPddz}#/Zw%?$&Q!xqob"OA|})3_@&BTTiQERo?/^g[Z<9P4R8:5C:aqq.cw!hotLc=+u-"+1rq@9$V^8PbOUlodyi_sejt+D`iqkLpx$>.aXl%vnfPIt"LK|/%>94_Zrm8jy?`_[RKt'TuoxUxfk(gMhY(n|DBBl~c$dhO>G%6}R4+DGX3|idBm4oU&UM/XUP4I9aoN{]`ax%B?rgD(I3OJ<62Y6L
X-Mailer: XCmail 0.99.6 - with PGP support, PGP engine version 0.5
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
X-Eric-Conspiracy: There is no conspiracy!
X-Loop: erik@it.et.tudelft.nl
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

On Thu, 25 Nov 1999 11:05:59 +0100, Guillaume Laurent wrote:
> Erik Mouw <J.A.K.Mouw@its.tudelft.nl> writes:
> 
>> On Wed, 24 Nov 1999 22:49:02 +0000 (GMT), jens reimer wrote:
>> > i have problems to compile the GTK-1.0.2
>> 
>> This is really ancient, use gtk+-1.0.6
> 
> He was talking about Gtk--.
> 
>> >  c++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../.. -I../..
> -DG_LOG_DOMAIN=\"Gnome--\"
> 
> See ? 'c++'. :-)

Oops! Sorry, you're right.


Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2785859  Fax: +31-15-2781843  Email J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/


From plessis@deesse.univ-lemans.fr  Thu May 11 17:52:45 2000
Received: (qmail 25546 invoked from network); 25 Nov 1999 12:07:09 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 25 Nov 1999 12:07:09 -0000
Received: from aviion.univ-lemans.fr (aviion.univ-lemans.fr [192.93.244.3])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id HAA27631
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 07:07:07 -0500
Received: from ham.univ-lemans.fr (ham.univ-lemans.fr [172.16.100.10])
	by aviion.univ-lemans.fr (8.8.8+Sun/8.8.8-V2610199) with ESMTP id NAA15004;
	Thu, 25 Nov 1999 13:06:22 +0100 (MET)
Received: from plessis (helo=localhost)
	by ham.univ-lemans.fr with local-smtp (Exim 3.03 #1 (Debian))
	id 11qxgX-00033w-00; Thu, 25 Nov 1999 13:07:37 +0100
Date: Thu, 25 Nov 1999 13:07:37 +0100 (CET)
From: Benoit Plessis <plessis@deesse.univ-lemans.fr>
X-Sender: plessis@ham.univ-lemans.fr
To: gtk-devel-list@redhat.com
cc: glaurent@worldnet.fr
Subject: Re: GTK--1.0.2 Make-Fehler
In-Reply-To: <199911251007.LAA23259@duteinh.et.tudelft.nl>
Message-ID: <Pine.LNX.3.96.991125130558.11775A-100000@ham.univ-lemans.fr>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII



So Gtk-- 1.0.2 is old too :
you should get Gtk-- 1.1.4 and his lib : libsig++ 0.8.5

Benoit Plessis
Benoit.Plessis@univ-lemans.fr

From glaurent@worldnet.fr  Thu May 11 17:52:45 2000
Received: (qmail 29079 invoked from network); 25 Nov 1999 13:18:45 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 25 Nov 1999 13:18:45 -0000
Received: from rogue.worldnet.fr (glaurent@p12-111.province.worldnet.fr [195.3.12.111])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id IAA29816
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 08:18:43 -0500
Received: (from glaurent@localhost)
	by rogue.worldnet.fr (8.9.3/8.9.3) id OAA21576;
	Thu, 25 Nov 1999 14:18:39 +0100
Sender: glaurent@worldnet.fr
To: gtk-devel-list@redhat.com
Subject: Re: GTK--1.0.2 Make-Fehler
References: <Pine.LNX.3.96.991125130558.11775A-100000@ham.univ-lemans.fr>
From: Guillaume Laurent <glaurent@worldnet.fr>
Date: 25 Nov 1999 14:18:39 +0100
In-Reply-To: Benoit Plessis's message of "Thu, 25 Nov 1999 13:07:37 +0100 (CET)"
Message-ID: <m3emdezp3k.fsf@rogue.worldnet.fr>
Lines: 10
X-Mailer: Gnus v5.6.45/XEmacs 21.1 - "Arches"

Benoit Plessis <plessis@deesse.univ-lemans.fr> writes:

> So Gtk-- 1.0.2 is old too :
> you should get Gtk-- 1.1.4 and his lib : libsig++ 0.8.5

Better wait for 1.1.5, we'll be adding namespaces to it. This will be
the last major API update before we freeze it.

-- 
						Guillaume

From logout@free.fr  Thu May 11 17:52:45 2000
Received: (qmail 2809 invoked from network); 25 Nov 1999 17:35:37 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 25 Nov 1999 17:35:37 -0000
Received: from postfix2.free.fr (postfix@postfix2.free.fr [212.27.32.74])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA07333
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 12:35:36 -0500
Received: from dks12 (marseille1-54-185.dial.proxad.net [212.27.54.185])
	by postfix2.free.fr (Postfix) with SMTP id 1228874676
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 18:35:31 +0100 (MET)
Message-ID: <003a01bf376c$303fdab0$b9361bd4@dks12>
From: "Emmanuel DELOGET" <logout@free.fr>
To: <gtk-devel-list@redhat.com>
References: <Pine.LNX.4.10.9911211724430.7367-100000@ashi.FootPrints.net>
Subject: Re: Unidentified subject!
Date: Thu, 25 Nov 1999 18:40:38 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300



> On Mon, 22 Nov 1999, Antonio Campos wrote:
>
> > we want to beat Windows or KDE... (By now Windows is quite smooth, and
this
> > is something desktop users feel instantenously)...
>
> Last I checked, Windoze still doesn't let you move the window of an app
that
> has stopped ``responding''. So we can safely say that it has a few
unresolved
> problems. :)  The smoothness is thanks to advances in the fabrication of
faster

    If I'm not stupid (and I really think that I'm not stupid :) when a GTK
application
    enters in a blocking loop (just as windows programs when they stop
responding)
    it cannot redraw the content of the window. Of course, you can move the
window,
    but this is not GTK+ related (the WM and X lets you resize or move the
window,
    but the window content is still not updated).

> processors and graphics chipsets.

    Not at all. Windows draws fast on an old cirrus logic too :)
    The smoothness is thanks to the way the toolkit is designed. That's why
    using double buffering will help a lot.

Emmanuel

From miguel@gnu.org  Thu May 11 17:52:45 2000
Received: (qmail 30342 invoked from network); 25 Nov 1999 19:08:41 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 25 Nov 1999 19:08:41 -0000
Received: from erandi.nuclecu.unam.mx (miguel@erandi.nuclecu.unam.mx [132.248.29.4])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA10884
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 14:08:40 -0500
Received: (from miguel@localhost)
	by erandi.nuclecu.unam.mx (8.9.3/8.9.3) id IAA08698;
	Thu, 25 Nov 1999 08:01:12 -0600
Date: Thu, 25 Nov 1999 08:01:12 -0600
Message-Id: <199911251401.IAA08698@erandi.nuclecu.unam.mx>
From: Miguel de Icaza <miguel@gnu.org>
To: gtk-devel-list@redhat.com
CC: gtk-devel-list@redhat.com, recipient list not shown: ;
In-reply-to: <ybeaeo31zq8.fsf@fresnel.labs.redhat.com> (message from Owen
	Taylor on 24 Nov 1999 14:00:47 -0500)
Subject: Re: First pass at double-buffered drawing
X-Windows: It could happen to you.
References:  <ybeaeo31zq8.fsf@fresnel.labs.redhat.com>


> Since there seems to be a strong interest in the idea
> of double-bufferingback, I've checked my current working
> tree into CVS on the branch gtk-no-flicker. 

Very nice!

I tried to figure out on my own a few things, please tell me if I am
correct:

	1. The idea is to have as many window-less widgets as possible
           to take as much advange of the setup.

	2. I could not figure out how you do the double buffering.

	   I saw you create the backing pixmap.  But say the pixmap is
	   not relative to 0,0, but to 10, 10, and you draw a line
	   from 0,0 to 20,20 that it actually needs to call XDrawLine
	   with -10,-10, 10,10?

Miguel.

From miguel@gnu.org  Thu May 11 17:52:45 2000
Received: (qmail 31147 invoked from network); 25 Nov 1999 19:09:31 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 25 Nov 1999 19:09:31 -0000
Received: from erandi.nuclecu.unam.mx (miguel@erandi.nuclecu.unam.mx [132.248.29.4])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA10942
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 14:09:30 -0500
Received: (from miguel@localhost)
	by erandi.nuclecu.unam.mx (8.9.3/8.9.3) id IAA08703;
	Thu, 25 Nov 1999 08:01:59 -0600
Date: Thu, 25 Nov 1999 08:01:59 -0600
Message-Id: <199911251401.IAA08703@erandi.nuclecu.unam.mx>
From: Miguel de Icaza <miguel@gnu.org>
To: gtk-devel-list@redhat.com
In-reply-to: <ybeaeo31zq8.fsf@fresnel.labs.redhat.com> (message from Owen
	Taylor on 24 Nov 1999 14:00:47 -0500)
Subject: Re: First pass at double-buffered drawing
X-Quote: If at first you don't succeed, redefine success.
References:  <ybeaeo31zq8.fsf@fresnel.labs.redhat.com>


>  - Some things don't work even in testgtk, it has not been
>    tested with _anything_ other than testgtk.

Seems like the GtkLayout sample demo is less buggy than the regular
Gtk+ version though ;-)

Miguel.

From Jens-Reimer@t-online.de  Thu May 11 17:52:45 2000
Received: (qmail 20595 invoked from network); 25 Nov 1999 21:10:00 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 25 Nov 1999 21:10:00 -0000
Received: from mailout07.btx.dtag.de (mailout07.btx.dtag.de [194.25.2.155])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA14887
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 16:10:00 -0500
Received: from fwd08.btx.dtag.de ([194.25.2.168])
	by mailout07.btx.dtag.de with smtp 
	id 11r69L-0003m2-00; Thu, 25 Nov 1999 22:09:55 +0100
Received: from meinpc.t-online.de (0402102285-0001(btxid)@[193.159.151.89]) 
	by fwd08.btx.dtag.de with smtp
	id <m11r68s-0003ItC>; Thu, 25 Nov 1999 22:09:26 +0100
Received: from localhost (jens-reimer@localhost [127.0.0.1])
	by meinpc.t-online.de (8.9.3/8.9.3) with ESMTP id RAA00851
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 17:31:57 GMT
Date: Thu, 25 Nov 1999 17:31:57 +0000 (GMT)
Reply-To: jens reimer <jens-reimer@t-online.de>
To: GTK Mailinglist <gtk-devel-list@redhat.com>
Subject: Strange!! Mails come twice
Message-ID: <Pine.LNX.4.20.9911251730580.824-100000@meinpc.t-online.de>
X-No-Archive: Yes
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Sender: 0402102285-0001@t-dialin.net
From: Jens-Reimer@t-online.de (jens reimer)

Hello,
strange effect to me.
I get all mail twice!?!

-- 
Tschau ;-)
jens


From kaz@FootPrints.net  Thu May 11 17:52:45 2000
Received: (qmail 8834 invoked from network); 25 Nov 1999 22:02:29 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 25 Nov 1999 22:02:29 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id RAA16426
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 17:02:28 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11r6yA-0006Xs-00; Thu, 25 Nov 1999 14:02:26 -0800
Date: Thu, 25 Nov 1999 14:02:26 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: jens reimer <Jens-Reimer@t-online.de>
cc: GTK Mailinglist <gtk-devel-list@redhat.com>, recipient list not shown: ;
Subject: Re: Strange!! Mails come twice
In-Reply-To: <Pine.LNX.4.20.9911251730580.824-100000@meinpc.t-online.de>
Message-ID: <Pine.LNX.4.10.9911251401180.25116-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Thu, 25 Nov 1999, jens reimer wrote:

> Hello,
> strange effect to me.
> I get all mail twice!?!

Because people often reply both to the mailing list as well as sending
a ``courtesy copy'' to you directly, as I'm about to do in order
to illustrate.

From otaylor@redhat.com  Thu May 11 17:52:45 2000
Received: (qmail 14572 invoked from network); 26 Nov 1999 00:11:59 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 26 Nov 1999 00:11:59 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA20833
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 19:11:59 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id SAA20994;
	Thu, 25 Nov 1999 18:14:34 -0500
To: gtk-devel-list@redhat.com
Subject: Re: First pass at double-buffered drawing
References: <ybeaeo31zq8.fsf@fresnel.labs.redhat.com> <199911251401.IAA08698@erandi.nuclecu.unam.mx>
From: Owen Taylor <otaylor@redhat.com>
Date: 25 Nov 1999 18:14:34 -0500
In-Reply-To: Miguel de Icaza's message of "Thu, 25 Nov 1999 08:01:12 -0600"
Message-ID: <ybebt8i88px.fsf@fresnel.labs.redhat.com>
Lines: 41
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Miguel de Icaza <miguel@gnu.org> writes:

> > Since there seems to be a strong interest in the idea
> > of double-bufferingback, I've checked my current working
> > tree into CVS on the branch gtk-no-flicker. 
> 
> Very nice!
> 
> I tried to figure out on my own a few things, please tell me if I am
> correct:
> 
> 	1. The idea is to have as many window-less widgets as possible
>            to take as much advange of the setup.

The techinque works for both window-less and windowed widgets.
Yes, things work a bit better for window-less widgets,
(since you don't temporarily get unexposed areas when
a subwindow is moved) but it does a reasonably good job
on window-widgets as well. I don't see really see changing
widgets over for 1.4,since that would either require changes
in even propagation, or lots of tricky use of input-only
widgets.
 
> 	2. I could not figure out how you do the double buffering.
> 
> 	   I saw you create the backing pixmap.  But say the pixmap is
> 	   not relative to 0,0, but to 10, 10, and you draw a line
> 	   from 0,0 to 20,20 that it actually needs to call XDrawLine
> 	   with -10,-10, 10,10?

Heh, it's a little tricky. In 1.4 every drawable has a vtable.
The vtable for GdkWindow normally passes the event directly
along to the platform-specific vtable, but if a paint is
in effect, then it translates the coordinates and draws onto
the double-buffering pixmap.

Regards,
                                        Owen


From popivan@gmx.net  Thu May 11 17:52:45 2000
Received: (qmail 155 invoked from network); 26 Nov 1999 00:49:34 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 26 Nov 1999 00:49:34 -0000
Received: from www2.gmx.net (www2.gmx.net [195.63.104.42])
	by mail.redhat.com (8.8.7/8.8.7) with SMTP id TAA21873
	for <gtk-devel-list@redhat.com>; Thu, 25 Nov 1999 19:49:34 -0500
Message-Id: <199911260049.TAA21873@mail.redhat.com>
Received: (qmail 15820 invoked by uid 0); 26 Nov 1999 00:49:33 -0000
Date: Fri, 26 Nov 1999 01:49:33 +0100 (MET)
From: Ivan Popivanov <popivan@gmx.net>
To: gtk-devel-list@redhat.com


MIME-Version: 1.0
Subject: Re: Unidentified subject!
X-Authenticated-Sender: #0001323561@gmx.net
X-Authenticated-IP: [128.100.3.10]
Message-ID: <15816.943577373@www2.gmx.net>
X-Mailer: WWW-Mail 1.5 (Global Message Exchange)
X-Flags: 0001
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

pbg1854@garnet.acns.fsu.edu wrote:
> 
> On Mon, Nov 22, 1999 at 02:37:46AM +0100, Antonio Campos wrote:
> > Certainly we have beaten Windows in a lot a questions, but the
> > smoothness of Windows is not only due to the graphics chipset (it's
> > an important factor obviously). I think that Windows is not using
> > GDI on a few applications. I think is really using DirectDraw to
> > write directly to video memory. If it is so, I don't like this way
> > of doing things, because DirectDraw is a focus of security problems
> > (no restrictions over who writes to video memory...).  Nevertheless,
> > I expect GTK to include double buffered widget in future releases...
> 
> Don't forget that sometimes X programs are run over a network link.
> Smooth scrolling would be slow as hell if it has to be transfered over
> that, even if it's 100 BaseT ethernet. It doesn't matter *what* you
> use for graphics hardware in this case. And wouldn't double buffering
> be *slower* over a network link? If you use standard X calls, only the
> commands for those calls are transmitted, but if you use a buffer, you
> have to send every pixel in the region over the link, right?
> 
> Pete
> 
> --
>          To unsubscribe: mail gtk-devel-list-request@redhat.com with
>                        "unsubscribe" as the Subject.

Windows is using GDI in almost all applications! There was no
flickering, before DirectDraw also! In my opinion, Windows application
do not flicker mainly of two reasons:
        1) They are written accurately
        2) The Windows model (GDI) gives programers flexible ways to
avoid
flickering.
The proposed in  http://www.gtk.org/~otaylor/gdk-1.4.html drawing
(begin/end_paint and so on) is something like the Windows model and it
is fine! But I do not believe in putting all of the flicker less drawing
in the library! Live to programers. For example: writing a Windows
application that uses ListView (an extended control similar to the Gtk's
CList control) you will have flickering if you just refill the ListView
every time! But the Windows Explorer right pane (that uses the ListView)
does not flickers on resizing and so on. What happens? The guys are
doing something like that (I have used it and it works) in every paint,
they tell the ListView to redraw itself, but in a back bitmap (Pixmap in
X terms). The pixmaps is cleared and refilled, but there is no
flickering, when you output the pixmap's contents on the screen!

I think it is possible in current release of Gtk to avoid flickering
using similar methods! We can set the window member of a widget to be a
pixmap and to output it to a real window only after the Pixmap is
redrawed. The problem is that widgets depend on their window member. So
another decision is to add in the draw method a parameter which is the
destination where the widget should be drawn and you can just call the
real draw with a pixmap and show that pixmap on the screen. This is my
suggestion for avoiding flickering. Please, do not try to solve the
problem using a general way! You will get a lot of other problems. Just
try to give careful programers a way to avoid flickering.

I am very happy to see such a discussion in this group, because I am
using both windows and Unix and EVERY Gtk application looks ugly
compared to its windows equivalent! The Graphic Interface is something
very important, but till yet there are no fine redrawing Unix programs.

        Ivan

-- 
Sent through Global Message Exchange - http://www.gmx.net

From logout@free.fr  Thu May 11 17:52:45 2000
Received: (qmail 28995 invoked from network); 26 Nov 1999 11:49:44 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 26 Nov 1999 11:49:44 -0000
Received: from postfix1.free.fr (postfix@postfix1.free.fr [212.27.32.21])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id GAA05119
	for <gtk-devel-list@redhat.com>; Fri, 26 Nov 1999 06:49:43 -0500
Received: from dks12 (marseille1-55-170.dial.proxad.net [212.27.55.170])
	by postfix1.free.fr (Postfix) with SMTP id A01312831B
	for <gtk-devel-list@redhat.com>; Fri, 26 Nov 1999 12:48:53 +0100 (MET)
Message-ID: <000e01bf3805$0a9d82f0$aa371bd4@dks12>
From: "Emmanuel DELOGET" <logout@free.fr>
To: <gtk-devel-list@redhat.com>
Subject: Proposal for a new ghash table
Date: Fri, 26 Nov 1999 12:54:12 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_000B_01BF380D.5628D4B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01BF380D.5628D4B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi everibody.

I've just looked at the code of the current ghash
(i was wondering what was the underlying code
for the hash table resizing). Here is another
approach for a dynamic hash table, based upon
an article or Per-Ake (Paul) Larson (can't find the=20
reference of this article). I will code it in the
next days, and will post results here.

The Larson's algorithm does not introduce any
freeze/thaw statements. It increases the size
of the hash table in order to limit the size of the
hash node list. Basically, it starts with a 2^n
size. When the number of hash node is bigger
than its current size, the size of the hash table
grows to 2^(n+1). This happens on the insertion
of a new hash node. then it computes the new=20
hash key and insert the node at the right place.

The key problem is the hash table lookup.
Since the size of the table grows and the
since the nodes are not moved in the table
(well... you can move the nodes too, see later),
it is possible to not find the node on the very
first look up. Consider a table with a base size
of 4 that has gown to have have a size of 32.
The hash val of the first element you have added
was 123456. In a table of 4 nodes, the resulting
hash val is 0. In a table of 32 nodes, the resulting
hash val is 8. In order to find the correct key for
a particular node, you'll have to
    1) compute the current hash value V from the=20
        key K (store it as V1)
    2) if the node is found, return it.
    2) if not, find the greater n value defined by
       2^n < V
    4) compute the new K value
    5) go to step 2
Before returning, a good thing should be to move
the node to position V1 if V !=3D V1. The next time
you'll want to access to the node, the look up
will be faster.=20

Of course, an extra thaw function can be provided
to reorganize the entire hash table for faster
look up when all the elements have been added
to the table...=20

The table is not collapsed when the number of
node decreases.=20

[the following assumes that the base size is 1 -
this is only assumed to show the algorithmes]

In order to minimize the allocations, the table is
not entirely reallocated when its size changes.
you simply use an array of 32 tables (looks like)

g_hash_node **hash_tables[32];

The insertion code looks like (pseudo-code):

node =3D create node(key, value);
if (nbnodes > current size) {
  current_array++;
  hash_tables[current_array] =3D=20
    allocate new table(current_size);
  current_size *=3D 2;
}
hash_val =3D compute_val(node, key) % current_size;
cur_size =3D current_size / 2;
cur_array =3D current_array;
while (cur_size > hash_val) {
  cur_array--;
  cur_size /=3D 2;
}
add_node_to_array(node,=20
                            hash_tables[cur_array],=20
                            hash_val - cur_size);

The look up code looks like :

node =3D NULL;
cur_loop =3D 0;
cur_size =3D curent_size;
V =3D V1 =3D compute_val(node, key) % current_size;
while (cur_loop <=3D current_array) {
  if (node is found at pos V) break;
  n =3D (int)log2(V);
  cur_size =3D 2^n;
  V =3D compute_val(node, key) % cur_size;
  cur_loop++;
}
if (node) {
  if (V1 !=3D V) move_node_from_to(node, V, V1);
}
return (node);

To be found at position V in the whole table, a
node should be at pos (V - cur_size) in table
hash_tables[log2(cur_size)].=20

Hope this is of interest.

Yours,=20

Emmanuel

------=_NextPart_000_000B_01BF380D.5628D4B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hi everibody.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I've just looked at the code of the =
current=20
ghash</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>(i was wondering what was the =
underlying=20
code</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>for the hash table resizing). Here is=20
another</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>approach for a dynamic hash table, =
based=20
upon</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>an article or Per-Ake (Paul) Larson =
(can't find the=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>reference of this article). I will code =
it in=20
the</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>next days, and will post results =
here.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The Larson's algorithm does not =
introduce=20
any</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>freeze/thaw statements. It increases =
the=20
size</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>of the hash table in order to limit the =
size of=20
the</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>hash node list. Basically, it starts =
with a=20
2^n</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>size. When the number of hash node is=20
bigger</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>than its current size, the size of the =
hash=20
table</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>grows to 2^(n+1). This happens on the=20
insertion</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>of a new hash node. then it computes =
the new=20
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>hash key and insert the node at the =
right=20
place.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The key problem is the hash table=20
lookup.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Since the size of the table grows and=20
the</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>since the nodes are not moved in the=20
table</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>(well... you can move the nodes =
too</FONT><FONT=20
face=3DArial size=3D2>, see later),</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>it is possible to not find the node on =
the=20
very</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>first look up. Consider a table with a =
base=20
size</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>of 4 that has gown to have have a size =
of=20
32.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>The hash&nbsp;val of the first element =
you have=20
added</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>was 123456. In a table of 4 nodes, the=20
resulting</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>hash val is 0. In a table of 32 nodes, =
the=20
resulting</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>hash val is 8. In order to find the =
correct key=20
for</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>a particular node, you'll have =
to</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 1) compute the =
current&nbsp;hash=20
value V from the </FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; key K=20
(store it as V1)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 2) if the node is =
found, return=20
it.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 2) if not, find the =
greater n=20
value defined by</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2^n=20
&lt;&nbsp;V</FONT></DIV>
<DIV>&nbsp;<FONT face=3DArial size=3D2>&nbsp;&nbsp; 4) compute&nbsp;the =
new&nbsp;K=20
value</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; 5) go to step =
2</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Before returning, a good thing should =
be to=20
move</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>the node to position V1 if V !=3D V1. =
The next=20
time</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>you'll want to access to the node, the =
look=20
up</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>will be faster. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Of course, an extra thaw function can =
be=20
provided</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>to reorganize the entire hash table for =

faster</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>look up when all the elements have been =

added</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>to the table... </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The table is not collapsed when the =
number=20
of</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>node decreases. </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>[the following assumes that the base =
size is 1=20
-</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>this is only assumed to show the=20
algorithmes]</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>In order to minimize the allocations, =
the table=20
is</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>not entirely reallocated when its size=20
changes.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>you simply use an array of 32 tables =
(looks=20
like)</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>g_hash_node =
**hash_tables[32];</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The insertion code looks like=20
(pseudo-code):</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>node =3D create node(key, =
value);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>if (nbnodes &gt; current =
size)</FONT><FONT=20
face=3DArial size=3D2> {</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; current_array++;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; hash_tables[current_array] =3D =
</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp;&nbsp;&nbsp; allocate new=20
table(current_size);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; current_size *=3D =
2;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>hash_val =3D compute_val(node, key) %=20
current_size;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>cur_size =3D current_size / =
2;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>cur_array =3D =
current_array;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>while (cur_size &gt; hash_val) =
{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; cur_array--;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; cur_size /=3D 2;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>add_node_to_array(node, </FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;hash_tables[cur_array],=20
</FONT></DIV>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;hash_val=20
- cur_size);</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The look up code looks like =
:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>node =3D NULL;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>cur_loop =3D 0;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>cur_size =3D curent_size;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>V =3D V1 =3D compute_val(node, key) %=20
current_size;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>while (cur_loop &lt;=3D =
current_array)</FONT><FONT=20
face=3DArial size=3D2> {</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; if (node is found at pos=20
V)&nbsp;break;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; n =3D (int)log2(V);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; cur_size =3D 2^n;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; V =3D compute_val(node, key) %=20
cur_size;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; cur_loop++;</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>if (node)</FONT><FONT face=3DArial =
size=3D2>=20
{</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&nbsp; if (V1 !=3D V) =
move_node_from_to(node, V,=20
V1);</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>}</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>return (node);</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>To be found at position V in the whole =
table,=20
a</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>node should be at pos (V - cur_size) in =

table</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>hash_tables[log2(cur_size)]. =
</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Hope this is of interest.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Yours, </FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Emmanuel</FONT></DIV></BODY></HTML>

------=_NextPart_000_000B_01BF380D.5628D4B0--

From logout@free.fr  Thu May 11 17:52:45 2000
Received: (qmail 18046 invoked from network); 26 Nov 1999 15:51:11 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 26 Nov 1999 15:51:11 -0000
Received: from postfix1.free.fr (postfix@postfix1.free.fr [212.27.32.21])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id KAA12642
	for <gtk-devel-list@redhat.com>; Fri, 26 Nov 1999 10:51:10 -0500
Received: from dks12 (marseille1-54-93.dial.proxad.net [212.27.54.93])
	by postfix1.free.fr (Postfix) with SMTP id 342DA287A4
	for <gtk-devel-list@redhat.com>; Fri, 26 Nov 1999 16:50:20 +0100 (MET)
Message-ID: <002e01bf3826$c5e93150$aa371bd4@dks12>
From: "Emmanuel DELOGET" <logout@free.fr>
To: <gtk-devel-list@redhat.com>
References: <000e01bf3805$0a9d82f0$aa371bd4@dks12>
Subject: Re: Proposal for a new ghash table
Date: Fri, 26 Nov 1999 16:56:15 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

> was 123456. In a table of 4 nodes, the resulting
> hash val is 0. In a table of 32 nodes, the resulting
> hash val is 8. In order to find the correct key for
> a particular node, you'll have to
>     1) compute the current hash value V from the 
>         key K (store it as V1)
>     2) if the node is found, return it.
>     2) if not, find the greater n value defined by
>        2^n < V
>     4) compute the new K value

    Oups... This should be 'the new V value'. K is
    invariant, but since V is (f(K) % size), the value
    of V changes on each iteration...

>     5) go to step 2
> Before returning, a good thing should be to move
> the node to position V1 if V != V1. The next time
> you'll want to access to the node, the look up
> will be faster. 


Yours, 

Emmanuel

From kaz@FootPrints.net  Thu May 11 17:52:45 2000
Received: (qmail 29432 invoked from network); 26 Nov 1999 17:03:03 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 26 Nov 1999 17:03:03 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id MAA16649
	for <gtk-devel-list@redhat.com>; Fri, 26 Nov 1999 12:03:03 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11rOly-0003Fy-00
	for gtk-devel-list@redhat.com; Fri, 26 Nov 1999 09:03:02 -0800
Date: Fri, 26 Nov 1999 09:03:01 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
Subject: Re: Proposal for a new ghash table
In-Reply-To: <000e01bf3805$0a9d82f0$aa371bd4@dks12>
Message-ID: <Pine.LNX.4.10.9911260827290.11865-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Fri, 26 Nov 1999, Emmanuel DELOGET wrote:

> Date: Fri, 26 Nov 1999 12:54:12 +0100
> From: Emmanuel DELOGET <logout@free.fr>
> Reply-To: gtk-devel-list@redhat.com
> To: gtk-devel-list@redhat.com
> Subject: Proposal for a new ghash table
> Resent-Date: 26 Nov 1999 11:49:44 -0000
> Resent-From: gtk-devel-list@redhat.com
> Resent-cc: recipient list not shown: ;
> 
> Hi everibody.
> 
> I've just looked at the code of the current ghash
> (i was wondering what was the underlying code
> for the hash table resizing). Here is another
> approach for a dynamic hash table, based upon
> an article or Per-Ake (Paul) Larson (can't find the 
> reference of this article). I will code it in the
> next days, and will post results here.
> 
> The Larson's algorithm does not introduce any
> freeze/thaw statements. It increases the size
> of the hash table in order to limit the size of the
> hash node list. Basically, it starts with a 2^n
> size. When the number of hash node is bigger
> than its current size, the size of the hash table
> grows to 2^(n+1).

I have an implementation of this in Kazlib, minus
the refinements described below.
http://users.footprints.net/~kaz/kazlib.html The license is BSD-like, meaning
that it can readily be used in GPLed code.

> a particular node, you'll have to
>     1) compute the current hash value V from the 
>         key K (store it as V1)
>     2) if the node is found, return it.
>     2) if not, find the greater n value defined by
>        2^n < V
>     4) compute the new K value
>     5) go to step 2


> Before returning, a good thing should be to move
> the node to position V1 if V != V1. The next time
> you'll want to access to the node, the look up
> will be faster. 

This is an interesting refinement that I do not have in the aforementioned
library (but which could be easily added); the grow is done synchronously
rather than distributed in this fine-grained manner. 

This is obviously better when it's undesirable to have wide variations in
response time; that is, no particular insertion should eat the sudden cost of a
resizing.

The only problem I see, the way I understand it, is that unsuccessful lookups
are now O(log n), so this neat algorithm is paid for by an order increase in
one of the hash operations. 

Thus I'd be feeling ambivalent about adding this to general-purpose, reusable
hash implementation, for which I can't anticipate the frequency of unsuccessful
lookups. 

From mikeh@bahnhof.se  Thu May 11 17:52:45 2000
Received: (qmail 1241 invoked from network); 27 Nov 1999 00:20:11 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 27 Nov 1999 00:20:11 -0000
Received: from sunny.bahnhof.se (ns.bahnhof.se [195.178.160.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA01631
	for <gtk-devel-list@redhat.com>; Fri, 26 Nov 1999 19:20:10 -0500
Received: from garfield.mikeh (pm4-43.bahnhof.se [195.178.166.236])
	by sunny.bahnhof.se (8.8.8+Sun/8.8.8) with ESMTP id BAA04558
	for <gtk-devel-list@redhat.com>; Sat, 27 Nov 1999 01:20:08 +0100 (MET)
Received: (from mikeh@localhost)
	by garfield.mikeh (8.8.7/8.8.7) id PAA11225;
	Fri, 26 Nov 1999 15:27:36 +0100
Date: Fri, 26 Nov 1999 15:27:35 +0100
From: Mikael Hermansson <mikeh@bahnhof.se>
To: gtk-devel-list@redhat.com
Cc: Clipboardbugingtk+orinX?@garfield.mikeh
Message-ID: <19991126152735.A11222@garfield.mikeh>
Reply-To: Mikael Hermansson <mikeh@bahnhof.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: Balsa 0.5.0

Hello!

I have a Question:

I have written a new text widget for gtk (gtkextext)
I am using the GtkEditable as baseclass and using its clipboard.

No I have seen that the GtkEditable clipboard don't takes 
windows text files because Windows have '\r' and '\n' as linebreaks.
As we already knows Linux/Unix only using '\n' as linebreak. 

This means before you try to Cut to the GtkEditable clipboard you must
remove '\r' character. 

Is this because X11 clipboard don't understand its a Text 
because of the '\r'(0xA) character or is it a GtkEditable bug?

Btw. The problem is also happen in GtkText widget.

Greats

Mikael Hermansson

---

Check out my homepage at (under heavy reconstruction): 
http://www.bahnhof.se/~mikeh	

Email: mikeh@bahnhof.se
international Phone 46-44-126995
Sweden Phone: 044-126995
ICQ: Error fix later

From mikeh@bahnhof.se  Thu May 11 17:52:45 2000
Received: (qmail 1776 invoked from network); 27 Nov 1999 00:20:19 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 27 Nov 1999 00:20:19 -0000
Received: from sunny.bahnhof.se (ns.bahnhof.se [195.178.160.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id TAA01667
	for <gtk-devel-list@redhat.com>; Fri, 26 Nov 1999 19:20:18 -0500
Received: from garfield.mikeh (pm4-43.bahnhof.se [195.178.166.236])
	by sunny.bahnhof.se (8.8.8+Sun/8.8.8) with ESMTP id BAA04537
	for <gtk-devel-list@redhat.com>; Sat, 27 Nov 1999 01:20:06 +0100 (MET)
Received: (from mikeh@localhost)
	by garfield.mikeh (8.8.7/8.8.7) id PAA11228
	for gtk-devel-list@redhat.com; Fri, 26 Nov 1999 15:31:26 +0100
Date: Fri, 26 Nov 1999 15:31:26 +0100
From: Mikael Hermansson <mikeh@bahnhof.se>
To: gtk-devel-list@redhat.com
Subject: X11 clipboard bug or GtkEditable bug?
Message-ID: <19991126153126.A10305@garfield.mikeh>
Reply-To: Mikael Hermansson <mikeh@bahnhof.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
X-Mailer: Balsa 0.5.0

Hello!
 
I have a Question:

I have written a new text widget for gtk (gtkextext)
I am using the GtkEditable as baseclass and using its clipboard.
 
No I have seen that the GtkEditable clipboard don't like 
windows text because Windows have '\r' and '\n' as linebreaks.
As we already knows Linux/Unix only using '\n' as linebreak. 

This means before you try to Cut to the GtkEditable clipboard you must
remove '\r' character before cut. 
 
Is this because X11 clipboard don't understand its a Text 
because of the '\r'(0xA) character or is it a GtkEditable bug?
 
Btw. The problem is also happen in GtkText widget.

Greats
 
Mikael Hermansson
 

---

Check out my homepage at (under heavy reconstruction): 
http://www.bahnhof.se/~mikeh	

Email: mikeh@bahnhof.se
international Phone 46-44-126995
Sweden Phone: 044-126995
ICQ: Error fix later

From Sebastien.Rougeaux@syseng.anu.edu.au  Thu May 11 17:52:45 2000
Received: (qmail 31602 invoked from network); 27 Nov 1999 04:16:46 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 27 Nov 1999 04:16:46 -0000
Received: from localhost.localdomain (root@fujiko.anu.edu.au [150.203.126.175])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id XAA09239
	for <gtk-devel-list@redhat.com>; Fri, 26 Nov 1999 23:16:41 -0500
Received: (from rougeaux@localhost)
	by localhost.localdomain (8.9.3/8.9.3) id PAA02958;
	Sat, 27 Nov 1999 15:17:29 +1100
Date: Sat, 27 Nov 1999 15:17:29 +1100
Message-Id: <199911270417.PAA02958@localhost.localdomain>
X-Authentication-Warning: localhost.localdomain: rougeaux set sender to Sebastien.Rougeaux@syseng.anu.edu.au using -f
From: Sebastien Rougeaux <Sebastien.Rougeaux@syseng.anu.edu.au>
To: gtk-devel-list@redhat.com
Subject: is the GSList library MT safe ?
Reply-to: Sebastien.Rougeaux@syseng.anu.edu.au


I am wondering if the GSList utility provided by glib is really
Multi-Thread safe. Here is a little example that do simple list
operations in two separate threads (for 2 separate lists), and
that crashes all the time for me (using redhat 6.1, gtk+-1.2.5)

/* compile with > gcc gslist.c `gtk-config --cflags --libs` -lpthread */

#include <stdio.h>
#include <errno.h>
#include <pthread.h>
#include <glib.h>

void *myLoop(void *data) {
  GSList *list=NULL;
  int i,n=30;

  for (i=0;i<n;i++) list = g_slist_append(list,(gpointer *)i);

  while (1) {
    list = g_slist_append(list,list->data);
    list = g_slist_remove(list,list->data);
  }
  return NULL;
}

int main(int argc, char *argv[]) {
  GSList *list=NULL;
  int i,n=30;
  pthread_t t_id;

  for (i=0;i<n;i++) list = g_slist_append(list,(gpointer *)i);

  if (pthread_create(&t_id, NULL, myLoop, (void *)NULL) == -1) 
    perror("pthread_create");

  while (1) {
    list = g_slist_append(list,list->data);
    list = g_slist_remove(list,list->data);
  }
  return 0;
}

And here is what gdb has to say:

>gdb gslist
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run
Starting program: /home/rougeaux/src/test/gslist/gslist 
[New Thread 3646 (manager thread)]
[New Thread 3645 (initial thread)]
[New Thread 3647]
[Switching to Thread 3647]

Program received signal SIGSEGV, Segmentation fault.
0x401868b9 in g_slist_alloc () from /usr/lib/libglib-1.2.so.0
(gdb) info stack
#0  0x401868b9 in g_slist_alloc () from /usr/lib/libglib-1.2.so.0
#1  0x40186aba in g_slist_append () from /usr/lib/libglib-1.2.so.0
#2  0x80487bf in myLoop (data=0x0) at gslist.c:13
#3  0x40264eca in pthread_start_thread (arg=0xbf7ffe60) at manager.c:213

Any clue ?

Sebastien Rougeaux
RSISE, The Austrlian National University

From otaylor@redhat.com  Thu May 11 17:52:45 2000
Received: (qmail 17219 invoked from network); 27 Nov 1999 05:37:15 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 27 Nov 1999 05:37:15 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id AAA10667
	for <gtk-devel-list@redhat.com>; Sat, 27 Nov 1999 00:37:14 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id XAA24747;
	Fri, 26 Nov 1999 23:39:43 -0500
To: gtk-devel-list@redhat.com
Subject: Re: is the GSList library MT safe ?
References: <199911270417.PAA02958@localhost.localdomain>
From: Owen Taylor <otaylor@redhat.com>
Date: 26 Nov 1999 23:39:43 -0500
In-Reply-To: Sebastien Rougeaux's message of "Sat, 27 Nov 1999 15:17:29 +1100"
Message-ID: <ybe4se8fsz4.fsf@fresnel.labs.redhat.com>
Lines: 33
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Sebastien Rougeaux <Sebastien.Rougeaux@syseng.anu.edu.au> writes:

> I am wondering if the GSList utility provided by glib is really
> Multi-Thread safe. Here is a little example that do simple list
> operations in two separate threads (for 2 separate lists), and
> that crashes all the time for me (using redhat 6.1, gtk+-1.2.5)

[...]

> int main(int argc, char *argv[]) {
>   GSList *list=NULL;
>   int i,n=30;
>   pthread_t t_id;
> 
>   for (i=0;i<n;i++) list = g_slist_append(list,(gpointer *)i);
> 
>   if (pthread_create(&t_id, NULL, myLoop, (void *)NULL) == -1) 
>     perror("pthread_create");
> 
>   while (1) {
>     list = g_slist_append(list,list->data);
>     list = g_slist_remove(list,list->data);
>   }
>   return 0;
> }

Compile with glib-config --libs gthread and add a 
call g_thread_init(NULL) at the beginning of
main(), and things should work better.

Regards,
                                        Owen

From otaylor@redhat.com  Thu May 11 17:52:45 2000
Received: (qmail 22072 invoked from network); 27 Nov 1999 05:45:20 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 27 Nov 1999 05:45:20 -0000
Received: from fresnel.labs.redhat.com (otaylor@fresnel.labs.redhat.com [207.175.42.57])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id AAA10889
	for <gtk-devel-list@redhat.com>; Sat, 27 Nov 1999 00:45:20 -0500
Received: (from otaylor@localhost)
	by fresnel.labs.redhat.com (8.9.3/8.9.3) id XAA24772;
	Fri, 26 Nov 1999 23:47:48 -0500
To: gtk-devel-list@redhat.com
Subject: Re: X11 clipboard bug or GtkEditable bug?
References: <19991126153126.A10305@garfield.mikeh>
From: Owen Taylor <otaylor@redhat.com>
Date: 26 Nov 1999 23:47:48 -0500
In-Reply-To: Mikael Hermansson's message of "Fri, 26 Nov 1999 15:31:26 +0100"
Message-ID: <ybezow0ee17.fsf@fresnel.labs.redhat.com>
Lines: 69
User-Agent: Gnus/5.070088 (Pterodactyl Gnus v0.88) Emacs/20.4
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii


Mikael Hermansson <mikeh@bahnhof.se> writes:

> Hello!
>  
> I have a Question:
> 
> I have written a new text widget for gtk (gtkextext)
> I am using the GtkEditable as baseclass and using its clipboard.
>  
> No I have seen that the GtkEditable clipboard don't like 
> windows text because Windows have '\r' and '\n' as linebreaks.
> As we already knows Linux/Unix only using '\n' as linebreak. 
> 
> This means before you try to Cut to the GtkEditable clipboard you must
> remove '\r' character before cut. 
>  
> Is this because X11 clipboard don't understand its a Text 
> because of the '\r'(0xA) character or is it a GtkEditable bug?

>From http://bugs.gnome.org/db/17/1704.html

=================
The problem here is that \r is not a legitimate character
to be transferred by the X selections; the only
control characters allowed are \n and \t.

When transferring non-internationalized text via the
STRING, you can get away with it; however, GTK+
will transfer via COMPOUND_TEXT when communicating
with itself, and thereby goes through the X conversion
routines, which refuse to accept strings with
invalid control characters. [ though they happily
generate them when converting the other way ]

There are a couple of possible solutions:

 1) Strip out control characters before converting to 
    compound text.

 2) For strings that are only ASCII + C0, transfer
    by default as STRING instead of COMPOUND_TEXT
    and include the C0 characters verbatim, even
    though they are (strictly speaking) also [not] allowed
    for STRING.

I'll put in at least 2). The problem with 1) is that 
some multi-byte encodings might include control
characters.

This will all work better in future versions of GTK+
when we move to using Unicode.

Regards,
                                        Owen
==================

I haven't actually implemented either of the above
yet, but that should give you an idea about the
problem and possible solutions. Another possibility
would be to always convert \r\n and \r alone
to \n when inserting text into an editable widget,
though that might be considered tampering with
the users data. (And would presumably not meet with
approval for the Win32 port...)

Regards,
                                  Owen

From hp@redhat.com  Thu May 11 17:52:45 2000
Received: (qmail 10681 invoked from network); 28 Nov 1999 23:28:26 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 28 Nov 1999 23:28:26 -0000
Received: from icon.labs.redhat.com (root@icon.labs.redhat.com [207.175.42.144])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA13510
	for <gtk-devel-list@redhat.com>; Sun, 28 Nov 1999 18:28:26 -0500
Received: from localhost (hp@localhost)
	by icon.labs.redhat.com (8.9.3/8.9.3) with ESMTP id SAA17282;
	Sun, 28 Nov 1999 18:23:01 -0500
X-Authentication-Warning: icon.labs.redhat.com: hp owned process doing -bs
Date: Sun, 28 Nov 1999 18:23:01 -0500 (EST)
From: Havoc Pennington <hp@redhat.com>
X-Sender: hp@icon.labs.redhat.com
To: gnome-hackers@gnome.org
cc: gtk-devel-list@redhat.com
Subject: help sys API
Message-ID: <Pine.LNX.4.10.9911281704330.17047-100000@icon.labs.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


Hi,

I can't find Sopwith on IRC so here are some thoughts on help before I
forget.

 The Qt interface for this is here:
   http://www.troll.no/qt/qwhatsthis-h.html

 It's a good bit simpler and easier to understand than our current mess.
It also brings up a good point; support for What's This should probably be
in GTK, because you need a virtual "get what's this text" function for
complex widgets with more than one what's this "target". Alternatively
we'd have a set_whatsthis_func call or something.

I would like to see:

 - one interface to get/set three different help levels on a widget:
    tooltip, whatsthis, and long URL; these interfaces should be in GTK
    and may be virtualized. Then you can choose your own way to 
    display the stuff if you want
 - tooltip and whatsthis popup widgets (the actual windows that pop up)
   available for separate use. (I have a tooltip widget in Guppi, 
   come to think of it, that could be easily modified to support the 
   nice ivory-with-shadow look the Qt popup help has)
 - GTK should have a widget_set_tooltip function, the need to manually
   create and attach a tooltip is gratuitous
 - convenience functions to create what's this toolbar button and menu
   item in GTK
 - GNOME code to let doc authors fill in the widget<->help association 
   file 
 - GNOME code that uses some sort of hook to load the widget<->help
   file and attach the help to the widgets
 - functions to enter/leave "what's this" mode, so you can have your 
   own UI to do that ("what's this" mode is the mode where the cursor 
   is a question mark and you click to get help) - this way you can 
   create custom ways to start/stop whatsthis mode.
   (this could actually call a generic callback when a widget is chosen, 
   so you can also use the code for other "pick a widget" situations)
 - GnomeHelpView widget is a way to magically display help in a GnomeApp

Between GtkTooltip, GtkTipsQuery, gnome-popup-help, and gnome-helpsys I
think this is another case of a confusing collection of semi-solutions. We
should talk about how to create a nice, clean, single API that looks like
it's been planned. Specific points in this email aside, the overall help
picture is definitely cleaner in Qt; it feeds the "Qt benefits from
unified commercial design" claim; we should address this problem.

As a programmer I think I'd like to say this for each widget:
 gtk_widget_set_name(widget, "blah"); /* Glade should do this automatically */
 gtk_widget_set_help(widget, _("tooltip"), _("whatsthis"), "url");

In GNOME we could replace gtk_widget_set_help() with loading some kind of
resource file that keys on widget names; I don't know if that's 
good or not (for tooltip and whatsthis it seems that we may as well just
use gettext's message catalog, programmers are more likely to write the
help if they can do it "inline").

Then something like:
 button = whatsthis_make_button();
 gtk_toolbar_add(toolbar, button); 
 menuitem = whatsthis_make_menuitem();
 gtk_menu_append(help_menu, menuitem);

with gnome-app-helper doing that automatically if requested.

I don't know the best solution, I just think this is a problem that should
be addressed by GTK and Gnome together and I think we need a clean,
easy-to-use solution.

Havoc


From miguel@gnu.org  Thu May 11 17:52:45 2000
Received: (qmail 103 invoked from network); 28 Nov 1999 23:55:31 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 28 Nov 1999 23:55:31 -0000
Received: from erandi.nuclecu.unam.mx (miguel@[132.248.237.29])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id SAA14419
	for <gtk-devel-list@redhat.com>; Sun, 28 Nov 1999 18:55:30 -0500
Received: (from miguel@localhost)
	by erandi.nuclecu.unam.mx (8.9.3/8.9.3) id SAA22239;
	Sun, 28 Nov 1999 18:47:10 -0600
Date: Sun, 28 Nov 1999 18:47:10 -0600
Message-Id: <199911290047.SAA22239@erandi.nuclecu.unam.mx>
From: Miguel de Icaza <miguel@gnu.org>
To: gtk-devel-list@redhat.com
In-reply-to: <ybebt8i88px.fsf@fresnel.labs.redhat.com> (message from Owen
	Taylor on 25 Nov 1999 18:14:34 -0500)
Subject: Re: First pass at double-buffered drawing
X-Info: When in doubt, blame the network
References: <ybeaeo31zq8.fsf@fresnel.labs.redhat.com> <199911251401.IAA08698@erandi.nuclecu.unam.mx> <ybebt8i88px.fsf@fresnel.labs.redhat.com>


> Heh, it's a little tricky. In 1.4 every drawable has a vtable.
> The vtable for GdkWindow normally passes the event directly
> along to the platform-specific vtable, but if a paint is
> in effect, then it translates the coordinates and draws onto
> the double-buffering pixmap.

Ahaha!  Ok, this one was the one I was looking for. 

OK, back to the source to check where the smart bits are.

miguel

From sgifford@sgifford.tir.com  Thu May 11 17:52:45 2000
Received: (qmail 28114 invoked from network); 29 Nov 1999 05:49:38 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 29 Nov 1999 05:49:38 -0000
Received: from sgifford.tir.com (sgifford.tir.com [216.40.129.22])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id AAA24322
	for <gtk-devel-list@redhat.com>; Mon, 29 Nov 1999 00:49:37 -0500
Received: (from sgifford@localhost)
	by sgifford.tir.com (8.9.3/8.9.3) id AAA08112;
	Mon, 29 Nov 1999 00:49:36 -0500
X-Authentication-Warning: sgifford.tir.com: sgifford set sender to sgifford@tir.com using -f
Sender: sgifford@sgifford.tir.com
To: gtk-devel-list@redhat.com
Subject: Patch for timer problem in glib 1.2.6
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: multipart/mixed;
 boundary="Multipart_Mon_Nov_29_00:49:36_1999-1"
Content-Transfer-Encoding: 7bit
From: Scott Gifford <sgifford@tir.com>
Date: 29 Nov 1999 00:49:36 -0500
Message-ID: <m33dtpc0en.fsf@sgifford.tir.com>
Lines: 66
X-Mailer: Gnus v5.6.45/Emacs 20.3

--Multipart_Mon_Nov_29_00:49:36_1999-1
Content-Type: text/plain; charset=US-ASCII

I found a problem with the timer code in glib 1.2.6.  If the time
moves around in unexpected ways, either being set back slightly or
jumping forward, the timer code chokes.  This time moving happens on
my laptop when it enters APM suspend mode, and resets the clock when
it comes back up.

This bug was causing asclock-gtk to hang for what appears to be
indefinitely (although further investigation showed it to be a mere 40
days), ignoring X events and not updating the clock.  A small sample
program that just set the timer to go off every second and printed the
time whenever it went off didn't receive any timer events for at least
an hour after suspending and waking up my laptop.

The fix is to simply do some sanity checking on the times.  In the
code in gmain.c:g_timeout_prepare which sets the timer expiration,
it checks if the time it has calculated it should wait is longer than
the interval, which should never happen in normal operation.  If it
finds this, it sets the time to wait to the timer interval.  And in the
code in gtimer.c:g_timer_elapsed which calculates the difference
between two times, if the difference is negative, it sets it to zero.
This also shouldn't happen in normal operation.

Patch is attached.

Let me know if there are any problems with this,

-----ScottG.


--Multipart_Mon_Nov_29_00:49:36_1999-1
Content-Type: application/octet-stream; type=patch
Content-Disposition: attachment; filename="glib-timer.patch"
Content-Transfer-Encoding: 7bit

diff -c glib-1.2.6/gmain.c glib-1.2.6-sg/gmain.c
*** glib-1.2.6/gmain.c	Mon Aug 23 15:41:20 1999
--- glib-1.2.6-sg/gmain.c	Sun Nov 28 12:35:04 1999
***************
*** 1242,1247 ****
--- 1242,1248 ----
    msec = (data->expiration.tv_sec  - current_time->tv_sec) * 1000 +
           (data->expiration.tv_usec - current_time->tv_usec) / 1000;
  
+   if (msec > data->interval) msec = data->interval;
    *timeout = (msec <= 0) ? 0 : msec;
  
    return (msec <= 0);
diff -c glib-1.2.6/gtimer.c glib-1.2.6-sg/gtimer.c
*** glib-1.2.6/gtimer.c	Sun Mar 21 02:05:58 1999
--- glib-1.2.6-sg/gtimer.c	Sun Nov 28 23:37:13 1999
***************
*** 182,187 ****
--- 182,189 ----
  
    elapsed.tv_usec = rtimer->end.tv_usec - rtimer->start.tv_usec;
    elapsed.tv_sec = rtimer->end.tv_sec - rtimer->start.tv_sec;
+   if (elapsed.tv_sec < 0) elapsed.tv_sec=0;
+   if (elapsed.tv_usec < 0) elapsed.tv_usec=0;
  
    total = elapsed.tv_sec + ((gdouble) elapsed.tv_usec / 1e6);
  

--Multipart_Mon_Nov_29_00:49:36_1999-1--

From logout@free.fr  Thu May 11 17:52:45 2000
Received: (qmail 16635 invoked from network); 29 Nov 1999 19:47:17 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 29 Nov 1999 19:47:17 -0000
Received: from postfix2.free.fr (postfix@postfix2.free.fr [212.27.32.74])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id OAA32577
	for <gtk-devel-list@redhat.com>; Mon, 29 Nov 1999 14:47:15 -0500
Received: from dks12 (marseille1-54-95.dial.proxad.net [212.27.54.95])
	by postfix2.free.fr (Postfix) with SMTP id C1CE774E07
	for <gtk-devel-list@redhat.com>; Mon, 29 Nov 1999 20:26:24 +0100 (MET)
Message-ID: <000e01bf3aa0$5c5b7820$5f361bd4@dks12>
From: "Emmanuel DELOGET" <logout@free.fr>
To: <gtk-devel-list@redhat.com>
References: <Pine.LNX.4.10.9911260827290.11865-100000@ashi.FootPrints.net>
Subject: Re: Proposal for a new ghash table
Date: Mon, 29 Nov 1999 20:31:39 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300

>
> I have an implementation of this in Kazlib, minus
> the refinements described below.
> http://users.footprints.net/~kaz/kazlib.html The license is BSD-like,
meaning
> that it can readily be used in GPLed code.
>
>
>
> > Before returning, a good thing should be to move
> > the node to position V1 if V != V1. The next time
> > you'll want to access to the node, the look up
> > will be faster.
>
> This is an interesting refinement that I do not have in the aforementioned
> library (but which could be easily added); the grow is done synchronously
> rather than distributed in this fine-grained manner.
>
> This is obviously better when it's undesirable to have wide variations in
> response time; that is, no particular insertion should eat the sudden cost
of a
> resizing.
>
> The only problem I see, the way I understand it, is that unsuccessful
lookups
> are now O(log n), so this neat algorithm is paid for by an order increase
in
> one of the hash operations.
    Not really. If the hash fuction is good enough to have a O(1) search in
    a classic hash table, then you'll end up with a O(32) [:)] search in
this
    implementation since you do not have more that 32 tables to search
    (well, actually you may have more than 32 tables if you have more
    than 2^32 bytes to store the tables :)

    By using a base size of 2^5 and reducing the max size to 2^20
    (these are good limits since you do not have to alloc too many tables
    for a small set of nodes, but you still have the possibility to store a
    large number of nodes in the two or three last tables), you limit
    to 16 the number of search in the worst case.

    And assuming you really don't want to lose time on hash search, you
    can implement

> Thus I'd be feeling ambivalent about adding this to general-purpose,
reusable
> hash implementation, for which I can't anticipate the frequency of
unsuccessful
> lookups.

    Well. We can compare this to the current implementation :

[predicates]
1/ freeze/thaw around one insertion is equivalent to no freeze/thaw
2/ large number of items : more than 1.000.000
3/ small number of items : less than 500.

* adding a lot of elements in the hash table without using freeze/thaw
is not really practicable since the ghash->frozen is set to FALSE during
the ghash creation (the resize func is called for each inserted node if
frozen is FALSE). Even if we lose some time on the first hash query, we
are the winner since we do not spend so much time during insertion.
Remember the second query is as fast as the first one in the current ghash.

* adding a small number of elements in the hash table without free/thaw
(ie small number of resize). We achive the same with the proposed
implementation

* freeze, adding a small number of items, thaw -> really the same as the
last point :)

* freeze, adding a large number of items, thaw -> Bang, the big resize
from an overfull hash table to a large, well-formed one. Of course, we
do not freeze the machine with the proposed implementation, except
if we do the same (calling the thaw/rearrage/
whatever-you-want-to-call-it function). In this case, we have the same
performance than the current implementation. If we do not, we simply
have a penality on the first request - not the second.

* freeze, adding a large number of item, and do not thaw -> leads to
a small hash tables with big node lists (the search becomes O(n), not
O(1)). So we win.

When we are not better than the current implementation, we have three
possibilities:
* we do the same or
* we can do the same or
* we are going to do the same :)

Yours,

Emmanuel

From kaz@FootPrints.net  Thu May 11 17:52:45 2000
Received: (qmail 2559 invoked from network); 29 Nov 1999 21:25:55 -0000
Received: from mail.redhat.com (199.183.24.239)
  by lists.redhat.com with SMTP; 29 Nov 1999 21:25:55 -0000
Received: from ashi.FootPrints.net (mail@ashi.FootPrints.net [204.239.179.1])
	by mail.redhat.com (8.8.7/8.8.7) with ESMTP id QAA06517
	for <gtk-devel-list@redhat.com>; Mon, 29 Nov 1999 16:25:54 -0500
Received: from kaz (helo=localhost)
	by ashi.FootPrints.net with local-esmtp (Exim 3.03 #1)
	id 11sYIy-0007LO-00
	for gtk-devel-list@redhat.com; Mon, 29 Nov 1999 13:25:52 -0800
Date: Mon, 29 Nov 1999 13:25:52 -0800 (PST)
From: Kaz Kylheku <kaz@ashi.footprints.net>
To: gtk-devel-list@redhat.com
Subject: Re: Proposal for a new ghash table
In-Reply-To: <000e01bf3aa0$5c5b7820$5f361bd4@dks12>
Message-ID: <Pine.LNX.4.10.9911291203490.26676-100000@ashi.FootPrints.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: Kaz Kylheku <kaz@FootPrints.net>

On Mon, 29 Nov 1999, Emmanuel DELOGET wrote:

> > The only problem I see, the way I understand it, is that unsuccessful
> lookups
> > are now O(log n), so this neat algorithm is paid for by an order increase
> in
> > one of the hash operations.
>     Not really. If the hash fuction is good enough to have a O(1) search in
>     a classic hash table, then you'll end up with a O(32) [:)] search in
> this
>     implementation since you do not have more that 32 tables to search
>     (well, actually you may have more than 32 tables if you have more
>     than 2^32 bytes to store the tables :)

Heh heh. Thus, by this logic, binary trees have constant time lookup too.
Assuming my nodes are 12 bytes <left, right, data> I can fill up most of the
4GB address space with a full, balanced tree having 2^28-1 nodes. Therefore any
search is O(28), therefore constant time! ;)

>     By using a base size of 2^5 and reducing the max size to 2^20
>     (these are good limits since you do not have to alloc too many tables

You just about might as well use a balanced binary search tree then.

>     for a small set of nodes, but you still have the possibility to store a
>     large number of nodes in the two or three last tables), you limit
>     to 16 the number of search in the worst case.

The worst case for a search remains bounded by O(n), because it's still
a hash table. ;)

>     Well. We can compare this to the current implementation :

My concern was whether the lazy movement of nodes after a growth is superior
to doing immediate movement, not whether any of this is better than the
current implementation (which is obviously less than state of the art in
some areas).

The conclusion is that the lazy transfer raises the *minimum* bound on the time
for *unsuccessful* lookups from o(1) to o(log n), (with the upper bound
remaining at O(n)) which could adversely impact the performance of some hash
uses. 

Thus, for instance, the operation of inserting n nodes into a table,
which duplicate checking for each insertion, now has a minimum
performance bound of o(n log n), which is also the average case
assuming a well-behaved hashing function.

If you are going to pay o(n log n) time to construct a dictionary, you might
has well have something to show for it, like having it in sorted order.

With immediate movement (nodes are transferred to their proper chain on
each growth) the cost of populating the hash table has an o(n) lower bound,
rather than o(n log n), because searches for non-existent entries can be
declared unsuccessful after traversing just one chain. That's without
any freezing/thawing, which would actually be detrimental by slowing
down the dupe checks.

You might not thing that unsuccessful hash table lookups are important.  But
the fact is that g_hash_insert actually performs a lookup before inserting; the
authors apparently thought that checking for duplicates is so important that it
should be buried in the interface.