From gtk-list-request@redhat.com
Status: U
Return-Path: <gtk-list-request@redhat.com>
Received: from cornell.edu (cornell.edu [132.236.56.6])
by postoffice.mail.cornell.edu (8.8.5/8.8.5) with ESMTP id QAA00683
for <owt1@postoffice.mail.cornell.edu>; Thu, 1 May 1997 16:06:33 -0400 (EDT)
Received: (from daemon@localhost)
by cornell.edu (8.8.5/8.8.5) id QAA28052
for owt1@postoffice.mail.cornell.edu; Thu, 1 May 1997 16:06:32 -0400 (EDT)
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by cornell.edu (8.8.5/8.8.5) with SMTP id QAA28027
for <owt1@cornell.edu>; Thu, 1 May 1997 16:06:30 -0400 (EDT)
Received: (qmail 19395 invoked by uid 501); 1 May 1997 20:06:58 -0000
Resent-Date: 1 May 1997 20:06:58 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From gtk-list-request@redhat.com Thu May 1 16:06:58 1997
Message-ID: <19970501160625.54339@redhat.com>
Date: Thu, 1 May 1997 16:06:25 -0400
X-PH: V4.1@cornell.edu (Cornell Modified)
From: Otto Hammersmith <otto@redhat.com>
To: gtk-list@redhat.com
Subject: anyone here yet?
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
Resent-Message-ID: <"Skbwt3.0.xk4.YVFQp"@mail2.redhat.com>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
X-Mailing-List: <gtk-list@redhat.com> archive/latest/3
X-Loop: gtk-list@redhat.com
Precedence: list
Resent-Sender: gtk-list-request@redhat.com
X-URL: http://www.redhat.com
Hello all,
Just wondering if there's anyone listening, yet. :)
If there are people out there, what is everyone doing with GTK? I've
seen some interesting projects, but want to get a handle on what
people are trying to do... don't want to duplicate any effort, now do
we?:)
--
-Otto.
From gtk-list-request@redhat.com
Status: U
Return-Path: <gtk-list-request@redhat.com>
Received: from cornell.edu (cornell.edu [132.236.56.6])
by postoffice.mail.cornell.edu (8.8.5/8.8.5) with ESMTP id QAA21782
for <owt1@postoffice.mail.cornell.edu>; Thu, 1 May 1997 16:58:54 -0400 (EDT)
Received: (from daemon@localhost)
by cornell.edu (8.8.5/8.8.5) id QAA17941
for owt1@postoffice.mail.cornell.edu; Thu, 1 May 1997 16:58:53 -0400 (EDT)
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by cornell.edu (8.8.5/8.8.5) with SMTP id QAA17899
for <owt1@cornell.edu>; Thu, 1 May 1997 16:58:50 -0400 (EDT)
Received: (qmail 8258 invoked by uid 501); 1 May 1997 20:56:35 -0000
Resent-Date: 1 May 1997 20:56:35 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From gtk-list-request@redhat.com Thu May 1 16:56:35 1997
X-PH: V4.1@cornell.edu (Cornell Modified)
From: Shawn T Amundson <amundson@cs.umn.edu>
Message-Id: <199705012055.PAA11068@augustus-239.cs.umn.edu>
Subject: Re: anyone here yet?
To: gtk-list@redhat.com
Date: Thu, 1 May 1997 15:55:48 -0500 (CDT)
In-Reply-To: <19970501160625.54339@redhat.com> from "Otto Hammersmith"
at May 1, 97 04:06:25 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
Resent-Message-ID: <"jpXJo3.0.l02.2EGQp"@mail2.redhat.com>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
X-Mailing-List: <gtk-list@redhat.com> archive/latest/5
X-Loop: gtk-list@redhat.com
Precedence: list
Resent-Sender: gtk-list-request@redhat.com
X-URL: http://www.redhat.com
Words Of Otto Hammersmith:
>
>Hello all,
>
>Just wondering if there's anyone listening, yet. :)
>
>If there are people out there, what is everyone doing with GTK? I've
>seen some interesting projects, but want to get a handle on what
>people are trying to do... don't want to duplicate any effort, now do
>we?:)
>
I'm working on a calendar widget. I have v0.01 done and will put it
up for ftp soon. It really sucks right now because it is too slow
and is seriously lacking in the features it requires. But it is a
starting place. ;-)
I'd like to do some docs in the tutorial area based on things I am
quickly learning as I go along.
Is this list going to be archived? It would be a *very* good thing.
--
Shawn T. Amundson University of Minnesota
Systems Administration Computer Science System Staff
amundson@cs.umn.edu http://www.cs.umn.edu/~amundson/
I'm fairly convinced that when God drinks beer, he drinks Guinness.
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
From gtk-list-request@redhat.com
Status: U
Return-Path: <gtk-list-request@redhat.com>
Received: from cornell.edu (cornell.edu [132.236.56.6])
by postoffice.mail.cornell.edu (8.8.5/8.8.5) with ESMTP id RAA24358
for <owt1@postoffice.mail.cornell.edu>; Thu, 1 May 1997 17:01:56 -0400 (EDT)
Received: (from daemon@localhost)
by cornell.edu (8.8.5/8.8.5) id RAA20597
for owt1@postoffice.mail.cornell.edu; Thu, 1 May 1997 17:01:55 -0400 (EDT)
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by cornell.edu (8.8.5/8.8.5) with SMTP id RAA20564
for <owt1@cornell.edu>; Thu, 1 May 1997 17:01:53 -0400 (EDT)
Received: (qmail 15824 invoked by uid 501); 1 May 1997 21:02:22 -0000
Resent-Date: 1 May 1997 21:02:21 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From gtk-list-request@redhat.com Thu May 1 17:02:21 1997
Message-ID: <19970501170146.29220@redhat.com>
Date: Thu, 1 May 1997 17:01:46 -0400
X-PH: V4.1@cornell.edu (Cornell Modified)
From: Otto Hammersmith <otto@redhat.com>
To: gtk-list@redhat.com
Subject: Re: anyone here yet?
References: <19970501160625.54339@redhat.com>
<199705012055.PAA11068@augustus-239.cs.umn.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199705012055.PAA11068@augustus-239.cs.umn.edu>;
from Shawn T Amundson on Thu, May 01, 1997 at 03:55:48PM -0500
Resent-Message-ID: <"Gt4zA1.0.8t3.TJGQp"@mail2.redhat.com>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
X-Mailing-List: <gtk-list@redhat.com> archive/latest/6
X-Loop: gtk-list@redhat.com
Precedence: list
Resent-Sender: gtk-list-request@redhat.com
X-URL: http://www.redhat.com
On Thu, May 01, 1997 at 03:55:48PM -0500, Shawn T Amundson wrote:
> Words Of Otto Hammersmith:
> >
> >Hello all,
> >
> >Just wondering if there's anyone listening, yet. :)
> >
> >If there are people out there, what is everyone doing with GTK? I've
> >seen some interesting projects, but want to get a handle on what
> >people are trying to do... don't want to duplicate any effort, now do
> >we? :)
> >
>
> I'm working on a calendar widget. I have v0.01 done and will put it
> up for ftp soon. It really sucks right now because it is too slow
> and is seriously lacking in the features it requires. But it is a
> starting place. ;-)
:) Sounds pretty much like my perdiciment right now.
> I'd like to do some docs in the tutorial area based on things I am
> quickly learning as I go along.
That'd be very cool
> Is this list going to be archived? It would be a *very* good thing.
Number two to ask in the short life of this list.
Yes, it's being archived right now. Read the message you got when you
subscribed.. near the end, I think it says how to get the archive.
As for a web interface, it will probably have to wait until next week,
if it ever gets done. If there's enough demand, I'll bug the right
people... but if no one cares, it's not worth the time. :)
--
-Otto.
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
From gtk-list-request@redhat.com
Status: U
Return-Path: <gtk-list-request@redhat.com>
Received: from cornell.edu (cornell.edu [132.236.56.6])
by postoffice.mail.cornell.edu (8.8.5/8.8.5) with ESMTP id RAA05404
for <owt1@postoffice.mail.cornell.edu>; Thu, 1 May 1997 17:51:23 -0400 (EDT)
Received: (from daemon@localhost)
by cornell.edu (8.8.5/8.8.5) id RAA04761
for owt1@postoffice.mail.cornell.edu; Thu, 1 May 1997 17:51:23 -0400 (EDT)
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by cornell.edu (8.8.5/8.8.5) with SMTP id RAA04738
for <owt1@cornell.edu>; Thu, 1 May 1997 17:51:21 -0400 (EDT)
Received: (qmail 21746 invoked by uid 501); 1 May 1997 21:51:46 -0000
Resent-Date: 1 May 1997 21:51:46 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From gtk-list-request@redhat.com Thu May 1 17:51:45 1997
Date: Thu, 1 May 1997 14:51:35 -0700 (PDT)
X-PH: V4.1@cornell.edu (Cornell Modified)
From: Raph Levien <raph@acm.org>
X-Sender: raph@blacklodge.c2.net
To: gtk-list@redhat.com
Subject: Re: anyone here yet?
In-Reply-To: <19970501160625.54339@redhat.com>
Message-ID: <Pine.BSF.3.91.970501140423.24370A-100000@blacklodge.c2.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Resent-Message-ID: <"mOlY41.0.fJ5.n1HQp"@mail2.redhat.com>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
X-Mailing-List: <gtk-list@redhat.com> archive/latest/7
X-Loop: gtk-list@redhat.com
Precedence: list
Resent-Sender: gtk-list-request@redhat.com
X-URL: http://www.redhat.com
On Thu, 1 May 1997, Otto Hammersmith wrote:
> Hello all,
>
> Just wondering if there's anyone listening, yet. :)
>
> If there are people out there, what is everyone doing with GTK? I've
> seen some interesting projects, but want to get a handle on what
> people are trying to do... don't want to duplicate any effort, now do
> we? :)
Well, now that you ask, I'll fess up. I've just started working on
gzilla. The name is a joke, really, because I have no intention of
building a web browser empire. It's going to be a quick, dirty, fast toy
Web browser. However, because it's built on top of GTK, it's going to be
extremely cool.
My goal is to put together a reasonable HTML viewer, JPG and GIF image
viewers, and a minimalist HTTP layer. The one "fancy" goal is for it to be
completely streaming. As such, it ought to be a reasonable choice for the
help viewer in Gimp. If other people want to develop it further than that,
I'd welcome it, but I don't have the time or energy to devote to releasing
and maintaining (yet another) major piece of software.
The architecture is roughly as follows:
Wedget
/ \
Html WebImage
/ \
GIF JPEG
A "Wedget" is a Web widget. It's just like an ordinary widget except for
one call and a bunch of singals. The new call is more_bytes, which the
application uses to push in bytes that come from the network (otherwise,
it's pretty similar in concept to gtk_label_set). The signals will
include things like link (emitted when a link is clicked), request_url
(emitted whenever an IMG tag is parsed), and maybe a few more. I haven't
designed this part thoroughly, so I'll make it up as I go along.
The Html wedget will be a pretty basic HTML displayer, with one cool
trick: it also act as a container for other widgets or wedgets. This is
how images will happen. It's also the obvious extension mechanism for
forms, tables, applets, and such. I'll support the GTK size negotiation
mechanism so it won't have to hold up page display if the hoser who wrote
the page forgot the WIDTH and HEIGHT parameters in an IMG tag.
The parsing, streaming, and layout will be handled by the simplest
possible mechanism. Html's more_bytes method will tokenize the input and
dispatch on the tag. It will also maintain a stack containing (tag,
attributes) tuples. For example, parsing <B> will just push B onto the
tag stack, push the attribute stack, and set the BOLD bit in the
attributes. Parsing </B> will just pop the stack down one. The text gets
shoved into an array of lines, each of which is an array of words. Each
word contains a string (the text of the word) and an index to the table
of attributes. Word wrapping happens incrementally as the text comes in,
but if the size changes (e.g. a window resize), the text gets rewrapped.
There is a bit of extra information in the line and word structures to
help with this. For example, each line contains a bit stating whether the
line ends with a hard or a soft break, and each word contains the metrics
of the word, to speed up both rewrap and display.
I'll keep you guys posted.
Raph
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
From gtk-list-request@redhat.com
Status: U
Return-Path: <gtk-list-request@redhat.com>
Received: from cornell.edu (cornell.edu [132.236.56.6])
by postoffice.mail.cornell.edu (8.8.5/8.8.5) with ESMTP id CAA03324
for <owt1@postoffice.mail.cornell.edu>; Sat, 3 May 1997 02:35:18 -0400 (EDT)
Received: (from daemon@localhost)
by cornell.edu (8.8.5/8.8.5) id CAA04796
for owt1@postoffice.mail.cornell.edu; Sat, 3 May 1997 02:35:18 -0400 (EDT)
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by cornell.edu (8.8.5/8.8.5) with SMTP id CAA04787
for <owt1@cornell.edu>; Sat, 3 May 1997 02:35:16 -0400 (EDT)
Received: (qmail 29047 invoked by uid 501); 3 May 1997 06:35:41 -0000
Resent-Date: 3 May 1997 06:35:41 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From gtk-list-request@redhat.com Sat May 3 02:35:40 1997
X-PH: V4.1@cornell.edu (Cornell Modified)
From: Shawn T Amundson <amundson@cs.umn.edu>
Message-Id: <199705030635.BAA28762@augustus-239.cs.umn.edu>
To: gtk-list@redhat.com
Date: Sat, 3 May 1997 01:35:02 -0500 (CDT)
X-Mailer: ELM [version 2.4 PL25 PGP3 *ALPHA*]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"ep5oV2.0.f57.yojQp"@mail2.redhat.com>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
X-Mailing-List: <gtk-list@redhat.com> archive/latest/39
X-Loop: gtk-list@redhat.com
Precedence: list
Resent-Sender: gtk-list-request@redhat.com
X-URL: http://www.redhat.com
Subject: [gtk-list] button speed way too slow
The design of the GtkButton is too slow for my calendar widget.
(42 buttons that have labels. Labels all get changed when a
button is clicked.)
I found that the offender was gtk_container_check_resize in the
gtk_label_set. If I just replace that with a gtk_widget_draw
there are no speed problems. However, this has some very messy
results.
I can make a few assumptions: the buttons need not resize, and
the only data in the button label is one or two characters or
nothing. If there is only one character it needs to be right
justified.
How can I make changing a button's label faster?
--
Shawn T. Amundson University of Minnesota
Systems Administration Computer Science System Staff
amundson@cs.umn.edu http://www.cs.umn.edu/~amundson/
You can't talk to a PSYCHO like a normal human being!!!! -Poe
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
From gtk-list-request@redhat.com
Status: U
Return-Path: <gtk-list-request@redhat.com>
Received: from cornell.edu (cornell.edu [132.236.56.6])
by postoffice.mail.cornell.edu (8.8.5/8.8.5) with ESMTP id RAA21626
for <owt1@postoffice.mail.cornell.edu>; Wed, 7 May 1997 17:14:26 -0400 (EDT)
Received: (from daemon@localhost)
by cornell.edu (8.8.5/8.8.5) id RAA24594
for owt1@postoffice.mail.cornell.edu; Wed, 7 May 1997 17:14:23 -0400 (EDT)
Received: from mail2.redhat.com (mail2.redhat.com [199.183.24.247])
by cornell.edu (8.8.5/8.8.5) with SMTP id RAA24428
for <owt1@cornell.edu>; Wed, 7 May 1997 17:14:12 -0400 (EDT)
Received: (qmail 5453 invoked by uid 501); 7 May 1997 21:14:31 -0000
Resent-Date: 7 May 1997 21:14:30 -0000
Resent-Cc: recipient list not shown: ;
MBOX-Line: From gtk-list-request@redhat.com Wed May 7 17:14:30 1997
Message-ID: <3370F0C5.58405A88@acm.org>
Date: Wed, 07 May 1997 14:14:45 -0700
X-PH: V4.1@cornell.edu (Cornell Modified)
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
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"K_pEX.0.-K1.s2FSp"@mail2.redhat.com>
Resent-From: gtk-list@redhat.com
Reply-To: gtk-list@redhat.com
X-Mailing-List: <gtk-list@redhat.com> archive/latest/67
X-Loop: gtk-list@redhat.com
Precedence: list
Resent-Sender: gtk-list-request@redhat.com
X-URL: http://www.redhat.com
Subject: [gtk-list] gtk issues for gzilla
Work on gzilla continues apace. I have, however, run into a few small
glitches. Hopefully, the people here will have some answers.
* Only one qualifies as a bona fide bug in gtk. If a label is inside a
scrolledwindow, and you change the label using gtk_label_set, it is not
always redrawn. It should be easy to duplicate this bug by modifying
(say) the timeout example in testgtk. If anyone has trouble doing so,
let me know and I will post code.
* I'd like to set the initial size of the default window to something
like 500x600. Using gtk_widget_set_usize does _almost_ what I want, but
not quite: it sets a minimum size, after which it's possible to do a
window resize to make the window bigger but not smaller. Also, the
window size info displayed by fvwm95-2 while resizing measures how much
bigger the window is than minimum, not the absolute size of the window.
I suspect that this will cause problems when trying to specify the
geometry of the window as well.
* Removing a widget from a scrolledwindow throws one of these:
** WARNING **: file gtkwidget.c: line 767 (gtk_widget_size_request):
"widget != NULL"
Originally, I was going to jump from doc to doc by removing the old
doc from the scrolledwindow and adding the new, but now I think I'll do
this in a box added between the page and scrolledwindow. There is a
another reason to do this other than just avioding the warning. Thus,
it's not a priority for me that this gets fixed.
* From looking at the code, it appears to me that gtk_preview_size won't
cause a check_resize if the widget is visible. I haven't verified this
in actual code yet. This will be important when an image of unknown size
is created, and the size becomes known later when the image starts
downloading from the network.
* What's the right way for the doc widget to find out the size of the
viewport of the enclosing scrolledwindow (minus the size of the padding
in the enclosing box if there's a box between them)? I think I'll just
walk up the tree by following the parent links until I find one that
meets the gtk_type_is_a predicate for scrolledwindow, then poke around
in the scrolledwindow structure. This feels a little gorpy though - I'd
prefer not to access the widget data structure internals if I can help
it.
* I hope the 0.99.10 release is soon so I can write the HTTP handling
code (which will rely heavily on gdk_input_add) without having to worry
about syntax changes.
Lest this sound like a gripefest, I want to commend you guys for all
the things you did right. So far, the feeling I've been getting is that
gtk+ is working with me, rather than being the beast I have to fight
against to get the UI I want. Coupling gzilla tightly to the gtk+ widget
hierarchy is increasingly looking like a good idea. For example, the
gtk_table widget is going to make it _much_ easier for me to get tables
right. Gambai!
Raph
--
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
From jmacd@CS.Berkeley.EDU
Received: (qmail 31001 invoked from network); 13 May 1997 19:47:51 -0000
Received: from paris.CS.Berkeley.EDU (128.32.34.47)
by mail2.redhat.com with SMTP; 13 May 1997 19:47:47 -0000
Received: from paris.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1])
by paris.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id MAA27860 for
<gtk-list@redhat.com>; Tue, 13 May 1997 12:47:05 -0700 (PDT)
From: Josh MacDonald <jmacd@CS.Berkeley.EDU>
Message-Id: <199705131947.MAA27860@paris.CS.Berkeley.EDU>
To: gtk-list@redhat.com
Subject: GTK text widget (was Re: [gtk-list] Proposal for a new project)
In-reply-to: Your message of "13 May 1997 19:42:55 +0200."
<x7vi4nw9nk.fsf@sn.no>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27853.863552822.1@paris.CS.Berkeley.EDU>
Date: Tue, 13 May 1997 12:47:04 -0700
With all this talk of KDE and HTML and all sorts of other people starting
to really use GTK, it strikes me that someday, someone is going to notice
that the text widget doesn't really work. I suppose I'll be having time
to finish it after finals, but have no immediate motivation because I have
no application demanding its completion. Further, I realized that while
most of the technical details are mostly complete, I have no experience
actually connecting a text widget up to anything non-trivial, and therefore
the API is currently almost non-existent.
It seems to me, that an HTML widget isn't really much different from a
text widget, considering that the GTK text widget, in its current state,
supports variable width fonts. I suspect that any HTML widget is going to
duplicate a lot of code. It would seem to me that adding the ability to
do various justifications and centering, and treating things like images
and tables as things with a unique, specially sized font, gets you almost
all the way there (neglecting the boring part about parsing HTML).
I'm wondering if people have given this any thought to this or could
recommend the appropriate path to completing the text widget and/or any of
your other wild desires. At the bare minimum, does anyone have suggestions
for what the rest of the text widget API should look like?
-josh
From amundson@cs.umn.edu
Received: (qmail 17457 invoked from network); 13 May 1997 20:09:12 -0000
Received: from augustus-228.cs.umn.edu (HELO augustus-239.cs.umn.edu)
(root@128.101.228.69)
by mail2.redhat.com with SMTP; 13 May 1997 20:09:12 -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 PAA24684
for <gtk-list@redhat.com>; Tue, 13 May 1997 15:08:43 -0500 (CDT)
From: Shawn T Amundson <amundson@cs.umn.edu>
Received: (from amundson@localhost) by guinness.cs.umn.edu (8.8.3/8.8.0)
id PAA20196 for gtk-list@redhat.com; Tue, 13 May 1997 15:08:42 -0500
Message-Id: <199705132008.PAA20196@guinness.cs.umn.edu>
Subject: Re: [gtk-list] GTK text widget (was Re: Proposal for a new project)
To: gtk-list@redhat.com
Date: Tue, 13 May 1997 15:08:40 -0500 (CDT)
In-Reply-To: <199705131947.MAA27860@paris.CS.Berkeley.EDU>
from "Josh MacDonald" at May 13, 97 12:47:04 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 Josh MacDonald:
>
>With all this talk of KDE and HTML and all sorts of other people starting
>to really use GTK, it strikes me that someday, someone is going to notice
>that the text widget doesn't really work. I suppose I'll be having time
>to finish it after finals, but have no immediate motivation because I have
>no application demanding its completion. Further, I realized that while
>most of the technical details are mostly complete, I have no experience
>actually connecting a text widget up to anything non-trivial, and therefore
>the API is currently almost non-existent.
I'm glad I haven't tried to use it yet; Aorta will need it, and will
be a big enough app to test it out properly, I'm certain.
I figure a cheap little calendar program that lets you type in stuff
for each day and changes the color dependant on if it's got something
for that day would be a good demo. I don't know if that would constitute
a motivational force or not. ;-)
>
>It seems to me, that an HTML widget isn't really much different from a
>text widget, considering that the GTK text widget, in its current state,
>supports variable width fonts. I suspect that any HTML widget is going to
>duplicate a lot of code. It would seem to me that adding the ability to
>do various justifications and centering, and treating things like images
>and tables as things with a unique, specially sized font, gets you almost
>all the way there (neglecting the boring part about parsing HTML).
Which kind of gets back to my question about making it possible to insert
any old child widget into the text widget: wouldn't that be cool?
>I'm wondering if people have given this any thought to this or could
>recommend the appropriate path to completing the text widget and/or any of
>your other wild desires. At the bare minimum, does anyone have suggestions
>for what the rest of the text widget API should look like?
I've only mildly looked at the text widget, but I'll try and get some
ideas as I work on that demo.
--
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 otto@redhat.com
Received: (qmail 23389 invoked from network); 13 May 1997 20:22:24 -0000
Received: from nimrod.redhat.com (otto@199.183.24.13)
by mail2.redhat.com with SMTP; 13 May 1997 20:22:24 -0000
Received: (from otto@localhost)
by nimrod.redhat.com (8.8.5/8.8.5) id QAA01407;
Tue, 13 May 1997 16:22:00 -0400
Message-ID: <19970513162159.55405@redhat.com>
Date: Tue, 13 May 1997 16:21:59 -0400
From: Otto Hammersmith <otto@redhat.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: GTK text widget (was Re: Proposal for a new project)
References: <199705131947.MAA27860@paris.CS.Berkeley.EDU>
<199705132008.PAA20196@guinness.cs.umn.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199705132008.PAA20196@guinness.cs.umn.edu>;
from Shawn T Amundson on Tue, May 13, 1997 at 03:08:40PM -0500
On Tue, May 13, 1997 at 03:08:40PM -0500, Shawn T Amundson wrote:
> Words Of Josh MacDonald:
[snipage]
>
> >It seems to me, that an HTML widget isn't really much different from a
> >text widget, considering that the GTK text widget, in its current state,
> >supports variable width fonts. I suspect that any HTML widget is going to
> >duplicate a lot of code. It would seem to me that adding the ability to
> >do various justifications and centering, and treating things like images
> >and tables as things with a unique, specially sized font, gets you almost
> >all the way there (neglecting the boring part about parsing HTML).
>
> Which kind of gets back to my question about making it possible to insert
> any old child widget into the text widget: wouldn't that be cool?
Yes.
I've done some thinking... I wonder if it'd be useful to have two text
widgets. One exteremely simple one with just plain text, and a second
for intense things that would allow embedding widgets and such. I
suspect the former would be useful for small apps that don't need the
power of the later.
One comment, though... it should be a "rich text" widget, not and
"HTML widget". I don't think HTML parsing code really belongs in the
widget proper. I see something along the lines of the relationship
between gtk_rc_parse stuff and GtkStyle objects.
In any case, it should be easy to use the widget with something other
than HTML... SGML, texinfo, LaTeX (I'm sure the LyX people would
appreciate that one), and whatnot.
[more snipage]
--
-Otto.
From otaylor@cu-dialup-2004.cit.cornell.edu
Received: (qmail 28842 invoked from network); 13 May 1997 20:32:25 -0000
Received: from cu-dialup-2004.cit.cornell.edu (qmailr@132.236.155.126)
by mail2.redhat.com with SMTP; 13 May 1997 20:32:21 -0000
Received: (qmail 1363 invoked by uid 504); 13 May 1997 20:33:02 -0000
Sender: otaylor@cu-dialup-2004.cit.cornell.edu
To: gtk-list@redhat.com
Subject: Re: [gtk-list] GTK text widget (was Re: Proposal for a new project)
References: <199705131947.MAA27860@paris.CS.Berkeley.EDU>
From: Owen Taylor <owt1@cornell.edu>
Date: 13 May 1997 16:33:02 -0400
In-Reply-To: Josh MacDonald's message of Tue, 13 May 1997 12:47:04 -0700
Message-ID: <lzd8qvaz9d.fsf@cu-dialup-2004.cit.cornell.edu>
Lines: 38
X-Mailer: Gnus v5.4.9/Emacs 19.34
Josh MacDonald <jmacd@CS.Berkeley.EDU> writes:
> With all this talk of KDE and HTML and all sorts of other people starting
> to really use GTK, it strikes me that someday, someone is going to notice
> that the text widget doesn't really work. [ ... ]
Yes, I had noticed ... my first toy app for PerlGtk used a text widget, so
I wrote a bit of code to retrieve all the text from the text widget,
then I found that hitting return in a text widget caused a segfault ...
I looked at it some but it seemed pretty complex (but well designed).
I think having a text widget is important, and that performance should
be one of the design goals - often you want to bring up a bit
of text or have a few lines for the user to edit - and that's what
I see as the important role of a text widget. For major editing,
people will want to use their primary text editor anyways ...
Although combining a text widget and HTML widget is intriguing, I'm
not sure that it's very feasible to combine nice looking layout
with editability.
So it might be good to keep the text widget simple.
> I'm wondering if people have given this any thought to this or could
> recommend the appropriate path to completing the text widget and/or any of
> your other wild desires. At the bare minimum, does anyone have suggestions
> for what the rest of the text widget API should look like?
The minimum enhancements (from my point of view) would be:
1) Make editing work
2) $text_widget->set_point(0)
$text_widget->get_text($text_widget->get_length)
Regards,
Owen
From amundson@cs.umn.edu
Received: (qmail 29612 invoked from network); 13 May 1997 20:33:52 -0000
Received: from augustus-228.cs.umn.edu (HELO augustus-239.cs.umn.edu)
(root@128.101.228.69)
by mail2.redhat.com with SMTP; 13 May 1997 20:33:51 -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 PAA29117
for <gtk-list@redhat.com>; Tue, 13 May 1997 15:33:11 -0500 (CDT)
From: Shawn T Amundson <amundson@cs.umn.edu>
Received: (from amundson@localhost) by guinness.cs.umn.edu (8.8.3/8.8.0)
id PAA20256 for gtk-list@redhat.com; Tue, 13 May 1997 15:33:10 -0500
Message-Id: <199705132033.PAA20256@guinness.cs.umn.edu>
Subject: Re: [gtk-list] Re: GTK text widget (was Re: Proposal for a new project)
To: gtk-list@redhat.com
Date: Tue, 13 May 1997 15:33:09 -0500 (CDT)
In-Reply-To: <19970513162159.55405@redhat.com> from "Otto Hammersmith"
at May 13, 97 04:21:59 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 Otto Hammersmith:
>
>I've done some thinking... I wonder if it'd be useful to have two text
>widgets. One exteremely simple one with just plain text, and a second
>for intense things that would allow embedding widgets and such. I
>suspect the former would be useful for small apps that don't need the
>power of the later.
I was thinking this too. But if the complex text widget, when used only
with text, is no larger than the extremely simple one, then what's the
point? Would it take so much extra room in the struct to have the
embedding done?
>
>One comment, though... it should be a "rich text" widget, not and
>"HTML widget". I don't think HTML parsing code really belongs in the
>widget proper. I see something along the lines of the relationship
>between gtk_rc_parse stuff and GtkStyle objects.
I don't really want to have to submit any layout language when
working with the widget. Except perhaps the normal packing code,
or how you control such things in TK. Widgets should take up the
same space as a character and act accordingly. You should be able
to insert by knowing the row and column of the text, or delete, etc.
Then a harder question: What about doing tags like in TK? Perhaps
an easy way to do links in widgets based off the text widgets, like
the HTML widget.
--
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 jmacd@CS.Berkeley.EDU
Received: (qmail 30027 invoked from network); 13 May 1997 20:35:01 -0000
Received: from paris.CS.Berkeley.EDU (128.32.34.47)
by mail2.redhat.com with SMTP; 13 May 1997 20:35:00 -0000
Received: from paris.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1])
by paris.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id NAA28221 for
<gtk-list@redhat.com>; Tue, 13 May 1997 13:34:35 -0700 (PDT)
From: Josh MacDonald <jmacd@CS.Berkeley.EDU>
Message-Id: <199705132034.NAA28221@paris.CS.Berkeley.EDU>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: GTK text widget (was Re: Proposal for a new project)
In-reply-to: Your message of "13 May 1997 16:33:02 EDT."
<lzd8qvaz9d.fsf@cu-dialup-2004.cit.cornell.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28214.863555673.1@paris.CS.Berkeley.EDU>
Date: Tue, 13 May 1997 13:34:34 -0700
>
> The minimum enhancements (from my point of view) would be:
>
> 1) Make editing work
>
> 2) $text_widget->set_point(0)
> $text_widget->get_text($text_widget->get_length)
Hmm, I thought it worked better than that. I fixed a number of things
in the 41097 snapshot. Was it in a later or ealier version?
-josh
From otto@redhat.com
Received: (qmail 31980 invoked from network); 13 May 1997 20:41:27 -0000
Received: from nimrod.redhat.com (otto@199.183.24.13)
by mail2.redhat.com with SMTP; 13 May 1997 20:41:27 -0000
Received: (from otto@localhost)
by nimrod.redhat.com (8.8.5/8.8.5) id QAA01486;
Tue, 13 May 1997 16:41:03 -0400
Message-ID: <19970513164102.13489@redhat.com>
Date: Tue, 13 May 1997 16:41:02 -0400
From: Otto Hammersmith <otto@redhat.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: GTK text widget (was Re: Proposal for a new project)
References: <lzd8qvaz9d.fsf@cu-dialup-2004.cit.cornell.edu>
<199705132034.NAA28221@paris.CS.Berkeley.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199705132034.NAA28221@paris.CS.Berkeley.EDU>;
from Josh MacDonald on Tue, May 13, 1997 at 01:34:34PM -0700
On Tue, May 13, 1997 at 01:34:34PM -0700, Josh MacDonald wrote:
> >
> > The minimum enhancements (from my point of view) would be:
> >
> > 1) Make editing work
> >
> > 2) $text_widget->set_point(0)
> > $text_widget->get_text($text_widget->get_length)
>
> Hmm, I thought it worked better than that. I fixed a number of things
> in the 41097 snapshot. Was it in a later or ealier version?
>
> -josh
Now that you mention it...
would you like everyone to come up with bugs for the text widget?
I've seen a couple in my cursory playing with it... it just occured to
me that you might not have seen the same ones.
(maybe we need a bug tracking thingy.... ;)
--
-Otto.
From jmacd@CS.Berkeley.EDU
Received: (qmail 89 invoked from network); 13 May 1997 20:43:41 -0000
Received: from paris.CS.Berkeley.EDU (128.32.34.47)
by mail2.redhat.com with SMTP; 13 May 1997 20:43:27 -0000
Received: from paris.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1])
by paris.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id NAA28301 for
<gtk-list@redhat.com>; Tue, 13 May 1997 13:42:41 -0700 (PDT)
From: Josh MacDonald <jmacd@CS.Berkeley.EDU>
Message-Id: <199705132042.NAA28301@paris.CS.Berkeley.EDU>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: GTK text widget (was Re: Proposal for a new project)
In-reply-to: Your message of "Tue, 13 May 1997 16:41:02 EDT."
<19970513164102.13489@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <28294.863556159.1@paris.CS.Berkeley.EDU>
Date: Tue, 13 May 1997 13:42:40 -0700
> On Tue, May 13, 1997 at 01:34:34PM -0700, Josh MacDonald wrote:
> > >
> > > The minimum enhancements (from my point of view) would be:
> > >
> > > 1) Make editing work
> > >
> > > 2) $text_widget->set_point(0)
> > > $text_widget->get_text($text_widget->get_length)
> >
> > Hmm, I thought it worked better than that. I fixed a number of things
> > in the 41097 snapshot. Was it in a later or ealier version?
> >
> > -josh
>
> Now that you mention it...
>
> would you like everyone to come up with bugs for the text widget?
> I've seen a couple in my cursory playing with it... it just occured to
> me that you might not have seen the same ones.
>
> (maybe we need a bug tracking thingy.... ;)
You're welcome to send them. I may know of some of them, but chances are
I don't. I've debugged it very little. One tends not to worry about
minor details when there's things like selections and horizontal scrolling to
finish up.
-josh
From otaylor@cu-dialup-2004.cit.cornell.edu
Received: (qmail 2316 invoked from network); 13 May 1997 20:52:31 -0000
Received: from cu-dialup-2004.cit.cornell.edu (qmailr@132.236.155.126)
by mail2.redhat.com with SMTP; 13 May 1997 20:52:30 -0000
Received: (qmail 4097 invoked by uid 504); 13 May 1997 20:53:18 -0000
Sender: otaylor@cu-dialup-2004.cit.cornell.edu
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: GTK text widget (was Re: Proposal for a new project)
References: <199705132034.NAA28221@paris.CS.Berkeley.EDU>
From: Owen Taylor <owt1@cornell.edu>
Date: 13 May 1997 16:53:17 -0400
In-Reply-To: Josh MacDonald's message of Tue, 13 May 1997 13:34:34 -0700
Message-ID: <lzbu6faybm.fsf@cu-dialup-2004.cit.cornell.edu>
Lines: 38
X-Mailer: Gnus v5.4.9/Emacs 19.34
> Hmm, I thought it worked better than that. I fixed a number of things
> in the 41097 snapshot. Was it in a later or ealier version?
>
> -josh
Not sure when I first noticed it, but (using 0.99.9 gtk):
Bring up testgtk. Click somewhere to bring up the insertion cursor.
Hit return.
Program received signal SIGSEGV, Segmentation fault.
0x40070bb0 in find_line_params (text=0x8069f98, mark=0xbffff324,
tab_cont=0xbffff30c, next_cont=0xbffff318) at gtktext.c:2662
2662 font = MARK_CURRENT_FONT (&lp.end);
(gdb)
#0 0x40070bb0 in find_line_params (text=0x8069f98, mark=0xbffff324,
tab_cont=0xbffff30c, next_cont=0xbffff318) at gtktext.c:2662
#1 0x4006d16e in line_params_iterate (text=0x8069f98, mark0=0xbffff38c,
tab_mark0=0x80701cc, alloc=1 '\001', data=0xbffff358,
iter=0x4006d270 <fetch_lines_iterator>) at gtktext.c:1173
#2 0x4006d3cd in fetch_lines (text=0x8069f98, mark0=0xbffff38c,
tab_cont0=0x80701cc, fl_type=FetchLinesCount, data=1) at gtktext.c:1232
#3 0x4006d538 in fetch_lines_forward (text=0x8069f98, line_count=1)
at gtktext.c:1271
#4 0x400719b5 in expose (text=0x8069f98, area=0xbffff410, cursor=0 '\000')
at gtktext.c:3061
#5 0x4006e01f in insert_char_line_expose (text=0x8069f98, key=10 '\n',
old_pixels=24) at gtktext.c:1537
#6 0x4006c159 in gtk_text_insert_1_at_point (text=0x8069f98, key=10 '\n')
at gtktext.c:915
#7 0x4006c6fb in gtk_text_key_press (widget=0x8069f98, event=0xbffff70c)
at gtktext.c:989
If this doesn't happen for you, I could provide more details.
Owen
From otto@redhat.com
Received: (qmail 18948 invoked from network); 14 May 1997 14:42:40 -0000
Received: from nimrod.redhat.com (otto@199.183.24.13)
by mail2.redhat.com with SMTP; 14 May 1997 14:42:40 -0000
Received: (from otto@localhost)
by nimrod.redhat.com (8.8.5/8.8.5) id KAA05675;
Wed, 14 May 1997 10:42:09 -0400
Message-ID: <19970514104209.52837@redhat.com>
Date: Wed, 14 May 1997 10:42:09 -0400
From: Otto Hammersmith <otto@redhat.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: GTK text widget (was Re: Proposal for a new project)
References: <19970513162159.55405@redhat.com>
<199705132033.PAA20256@guinness.cs.umn.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <199705132033.PAA20256@guinness.cs.umn.edu>;
from Shawn T Amundson on Tue, May 13, 1997 at 03:33:09PM -0500
On Tue, May 13, 1997 at 03:33:09PM -0500, Shawn T Amundson wrote:
> Words Of Otto Hammersmith:
> >
> >I've done some thinking... I wonder if it'd be useful to have two text
> >widgets. One exteremely simple one with just plain text, and a second
> >for intense things that would allow embedding widgets and such. I
> >suspect the former would be useful for small apps that don't need the
> >power of the later.
>
> I was thinking this too. But if the complex text widget, when used only
> with text, is no larger than the extremely simple one, then what's the
> point? Would it take so much extra room in the struct to have the
> embedding done?
Very true, if it doesn't save any memory or resources, there's no
reason for it... but I suspect it will turn out to be otherwise.
> >One comment, though... it should be a "rich text" widget, not and
> >"HTML widget". I don't think HTML parsing code really belongs in the
> >widget proper. I see something along the lines of the relationship
> >between gtk_rc_parse stuff and GtkStyle objects.
>
> I don't really want to have to submit any layout language when
> working with the widget. Except perhaps the normal packing code,
> or how you control such things in TK. Widgets should take up the
> same space as a character and act accordingly. You should be able
> to insert by knowing the row and column of the text, or delete, etc.
>
> Then a harder question: What about doing tags like in TK? Perhaps
> an easy way to do links in widgets based off the text widgets, like
> the HTML widget.
I think I'm being misunderstood. I didn't mean "rich text" as in
RTF... I just meant a widget capable of displaying that kind of text.
As for commenting on how Tk does things... I'm not familiar with Tk,
so someone will have to fill me in a bit. :)
--
-Otto.
From raph@acm.org
Received: (qmail 8958 invoked from network); 15 May 1997 22:21:52 -0000
Received: from callisto.hip.berkeley.edu (136.152.64.218)
by mail2.redhat.com with SMTP; 15 May 1997 22:21:51 -0000
Received: (from raph@localhost) by callisto.hip.berkeley.edu (8.6.12/8.6.12)
id PAA07330 for gtk-list@redhat.com; Thu, 15 May 1997 15:22:44 -0700
Message-ID: <337B8CAF.1C3CB53F@acm.org>
Date: Thu, 15 May 1997 15:22:39 -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: Code escape: Gzilla 0.01
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi gtk people,
After a couple of weeks of hacking, I am eager to show an early
prototype of gzilla to the world. Well, ok, only to gtk developers for
now, at least until the UI gets a lot smoother.
The code is available at http://www.levien.com/gzilla-0.01.tar.gz .
It is only a 30K download, and will probably only take a minute or so to
build.
Here's a very rough outline of the architecture:
In gzilla, the display of a file is handled by two separate, but
linked objects. The first is what I call a "bytesink." It's main purpose
is to implement a "write" method for writing bytes into the object. The
write method typically parses this input and passes it on to the second
object, which is a gtk+ widget.
One reason I did this is so that I could reuse existing gtk+ widgets
when applicable. For example, for gif display, the widget is just a
gtk_preview. The gzilla_gif object is basically just a
progressive-rendering adaptation of giftopnm.
HTML page rendering is also split in two in this way. The bytesink
(gzilla_html) handles the HTML parsing, and hands words, spaces,
linebreaks, attributes, and embedded widgets to the gtk_page widget,
which takes care of the actual formatting (including word wrapping) and
display. The interface between gzilla_html and gtk_page is actually
pretty simple. Of course, that's partly due to the fact that the text
formatting is not very rich yet.
In general, I've tried to follow the gtk+ architecture very closely.
The gtk_page widget configures itself to be the size of the page. It's
displayed in the toplevel window simply by putting it into a
scrolledwindow.
After having gotten this far, I'm having mixed feelings. In the fully
modular widget design, gtk+ simply cannot guarantee me the performance I
feel is necessary for a really cool Web browser. The main problem I'm
running up against is size changes. In _addition_ to the problems I
mentioned a few days ago (that come into play when you put a lot of
widgets into a gtk_page), doing a gdk_window_move_resize is causing the
entire window to be blanked. I _think_ it's the underlying X server
(XFree86 3.2 on an S3 in my case) that's doing this, but I'm not
positive. Either way, it's unacceptable - instead of smooth display when
a page downloads, it flickers like <BLINK> on methamphetamines. Not
good.
I do see a few ways around this - most notably, I could suck the
scrollbar into the gtk_page widget, make gtk_page itself a fixed size
window, and handle all of the size changes and scrolling inside gtk_page
itself. But this has two drawbacks - first, I lose modularity within the
gtk+ framework, and second, I have to repaint the entire window on every
scroll. The way it works now, scrolling causes most of the window to be
preserved, with an expose event for the little bit that scrolled into
visibility. I'm pretty sure this is the approach that Netscape uses, by
the way.
Another possiblility is the way qweb does it - throttle the rate of
window resize calls. This way, the flashing is reduced (so it now looks
like <BLINK> on barbiturates) but not entirely eliminated. Also, updates
don't appear to happen as quickly.
If gzilla is to be used primarily to browse local files (e.g. as the
Gimp's help browser), then the window flashing problem is not nearly so
severe.
So please take a look and let me know what you think. If you have any
ideas about the window flashing problem, I'd certainly like to hear
them.
Raph
From szi@lilly.ping.de
Received: (qmail 28195 invoked from network); 16 May 1997 06:49:15 -0000
Received: from lilly.ping.de (193.100.14.2)
by mail2.redhat.com with SMTP; 16 May 1997 06:49:13 -0000
Received: (qmail 21960 invoked by uid 10); 16 May 1997 06:48:44 -0000
Sender: szi@lilly.ping.de
Message-ID: <337BFDD0.269B91A1@aibon.ping.de>
Date: Fri, 16 May 1997 08:25:20 +0200
From: Sascha Ziemann <szi@aibon.ping.de>
Organization: Chaos Emu v0.0 preAlpha
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.29 i586)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Re: Code escape: Gzilla 0.01
References: <337B8CAF.1C3CB53F@acm.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Raph Levien wrote:
> After a couple of weeks of hacking, I am eager to show an early
> prototype of gzilla to the world. Well, ok, only to gtk developers for
> now, at least until the UI gets a lot smoother.
>
> The code is available at http://www.levien.com/gzilla-0.01.tar.gz .
> It is only a 30K download, and will probably only take a minute or so to
> build.
Can not compile it:
szi@aibon:~/transfer/x/gzilla$ make
gcc -g -Wall -I/usr/ego/include -c gzilla.c -o gzilla.o
gzilla.c: In function `gzilla_con_input_handler':
gzilla.c:198: warning: implicit declaration of function `GTK_CHECK_CAST'
gzilla.c:198: parse error before `GzillaByteSink'
gzilla.c: In function `gzilla_con_query_handler':
gzilla.c:239: parse error before `GzillaByteSink'
make: *** [gzilla.o] Error 1
-- bis später...
- Sascha ---<~>=( http://www.ping.de/sites/aibon/ )=<~>---
() Free speech online
/\ http://www.eff.org/BlueRibbon/bluehtml.html
From otto@redhat.com
Received: (qmail 2399 invoked from network); 16 May 1997 07:21:19 -0000
Received: from nimrod.redhat.com (otto@199.183.24.13)
by mail2.redhat.com with SMTP; 16 May 1997 07:21:19 -0000
Received: (from otto@localhost)
by nimrod.redhat.com (8.8.5/8.8.5) id DAA03616;
Fri, 16 May 1997 03:20:55 -0400
Message-ID: <19970516032055.57369@redhat.com>
Date: Fri, 16 May 1997 03:20:55 -0400
From: Otto Hammersmith <otto@redhat.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Code escape: Gzilla 0.01
References: <337B8CAF.1C3CB53F@acm.org> <337BFDD0.269B91A1@aibon.ping.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <337BFDD0.269B91A1@aibon.ping.de>; from Sascha Ziemann on Fri,
May 16, 1997 at 08:25:20AM +0200
On Fri, May 16, 1997 at 08:25:20AM +0200, Sascha Ziemann wrote:
> Raph Levien wrote:
>
> > After a couple of weeks of hacking, I am eager to show an early
> > prototype of gzilla to the world. Well, ok, only to gtk developers for
> > now, at least until the UI gets a lot smoother.
> >
> > The code is available at http://www.levien.com/gzilla-0.01.tar.gz .
> > It is only a 30K download, and will probably only take a minute or so to
> > build.
>
> Can not compile it:
>
> szi@aibon:~/transfer/x/gzilla$ make
> gcc -g -Wall -I/usr/ego/include -c gzilla.c -o gzilla.o
> gzilla.c: In function `gzilla_con_input_handler':
> gzilla.c:198: warning: implicit declaration of function `GTK_CHECK_CAST'
> gzilla.c:198: parse error before `GzillaByteSink'
> gzilla.c: In function `gzilla_con_query_handler':
> gzilla.c:239: parse error before `GzillaByteSink'
> make: *** [gzilla.o] Error 1
FWIW, it built beautifully for me. Two different Linux machines, one
using gtk+ from 0.99.8 and the other using 0.99.9. (both running Red
Hat) It also probably built just fine on a SPARC running Red Hat... I
presume I would've gotten a question or two had it not.
One thing that would be very nice, is if everyone would start
standardizing on how to include gtk.h (as well as gdk.h and glib.h)...
#include <gtk/gtk.h>
Works best, I think... usually means less fiddling with -I options to
the compiler. Especially if you use the RPMs for gtk on
ftp.redhat.com:/pub/contrib... it puts the gtk include directory in
/usr/include so there's no tweaking necessary. (BTW, there are RPMS in
/pub/contrib... ignore the gimp-data one... 'tis from an older package
built by someone else. :)
In any case, I'm absolutely ecstatic that you released some code! The
GzillaByteSink stuff is precisely what I needed...
Being 3:00am, I think I ought to stop rambling and get some sleep
before I get back to work. :)
Night all.
--
-Otto.
From raph@acm.org
Received: (qmail 5178 invoked from network); 16 May 1997 17:37:32 -0000
Received: from blacklodge.c2.net (208.139.36.35)
by mail2.redhat.com with SMTP; 16 May 1997 17:31:38 -0000
Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3)
id KAA19614; Fri, 16 May 1997 10:32:00 -0700 (PDT)
Date: Fri, 16 May 1997 10:32:00 -0700 (PDT)
From: Raph Levien <raph@acm.org>
X-Sender: raph@blacklodge.c2.net
To: Otto Hammersmith <otto@redhat.com>
cc: gtk-list@redhat.com
Subject: Gtk app build issues
In-Reply-To: <19970516032055.57369@redhat.com>
Message-ID: <Pine.BSF.3.91.970516095422.18359B-100000@blacklodge.c2.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Fri, 16 May 1997, Otto Hammersmith wrote:
> On Fri, May 16, 1997 at 08:25:20AM +0200, Sascha Ziemann wrote:
> > Can not compile it:
> >
> > szi@aibon:~/transfer/x/gzilla$ make
> > gcc -g -Wall -I/usr/ego/include -c gzilla.c -o gzilla.o
> > gzilla.c: In function `gzilla_con_input_handler':
> > gzilla.c:198: warning: implicit declaration of function `GTK_CHECK_CAST'
> > gzilla.c:198: parse error before `GzillaByteSink'
> > gzilla.c: In function `gzilla_con_query_handler':
> > gzilla.c:239: parse error before `GzillaByteSink'
> > make: *** [gzilla.o] Error 1
To compile 0.01 on your machine, you'll probably need -I/usr/ego/include
and -I/usr/ego/include/gtk .
[...]
> One thing that would be very nice, is if everyone would start
> standardizing on how to include gtk.h (as well as gdk.h and glib.h)...
>
> #include <gtk/gtk.h>
>
> Works best, I think... usually means less fiddling with -I options to
> the compiler. Especially if you use the RPMs for gtk on
> ftp.redhat.com:/pub/contrib... it puts the gtk include directory in
> /usr/include so there's no tweaking necessary. (BTW, there are RPMS in
> /pub/contrib... ignore the gimp-data one... 'tis from an older package
> built by someone else. :)
I agree, and have changed all of the #include directives to reflect this
suggestion. It now builds on my system with just -I/usr/local/include .
This is a major improvement. Thanks, Otto!
> In any case, I'm absolutely ecstatic that you released some code! The
> GzillaByteSink stuff is precisely what I needed...
I'm glad...
> Being 3:00am, I think I ought to stop rambling and get some sleep
> before I get back to work. :)
>
> Night all.
Stepping back for a moment, I've noticed that a lot of the problems
people are talking about on this list have to do with using simple.c as
the "hello world" template for building apps. However, simple.c has a lot
of things wrong with it:
+ #include "gtk.h" rather than #include <gtk/gtk.h>
+ signal handlers call gtk_exit (0) rather than gtk_main_quit ()
+ both signal handlers quit
+ no separate build process
I've put a tentative hello world example up at
http://www.levien.com/gimp/hello.html .
One thing this example is sorely lacking is an autoconf script. I have no
idea how to go about building one, but if anyone else here knows how and
would be willing to contribute, I'd be happy to put it on the page.
Raph
From raph@acm.org
Received: (qmail 32622 invoked from network); 17 May 1997 05:19:49 -0000
Received: from callisto.hip.berkeley.edu (136.152.64.218)
by mail2.redhat.com with SMTP; 17 May 1997 05:19:48 -0000
Received: (from raph@localhost) by callisto.hip.berkeley.edu (8.6.12/8.6.12)
id WAA13328 for gtk-list@redhat.com; Fri, 16 May 1997 22:20:44 -0700
Message-ID: <337D4027.19822350@acm.org>
Date: Fri, 16 May 1997 22:20:39 -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: Gzilla 0.02
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi gtk developers,
The newest release of gzilla is available at:
http://www.levien.com/gzilla-0.02.tar.gz
It's still pretty "young" as Owen would say, but it's dramatically
more usable than the 0.01 release. Most importantly, it supports
clickable links and navigation. The flashing problem has been addressed
(although the redraw code is not perfect yet). The HTML layout is
steadily getting better, although still pretty minimal. I used it a
little this evening to surf the Web.
One gtk+ issue: if clicking a button causes its state to go
insensitive (i.e. a function connected to the "clicked" signal handler
calls gtk_widget_set_sensitive on the button), then the background color
usually stays stuck in the prelight color. Similarly when the button
goes sensitive again - it stays in prelight until you pass the mouse
over it. You can see this in the behavior of the navigation buttons.
Enjoy!
Raph
From otto@cu-online.com
Received: (qmail 26717 invoked from network); 19 May 1997 14:33:58 -0000
Received: from nimrod.redhat.com (otto@199.183.24.13)
by mail2.redhat.com with SMTP; 19 May 1997 14:33:58 -0000
Received: (from otto@localhost)
by nimrod.redhat.com (8.8.5/8.8.5) id KAA29725;
Mon, 19 May 1997 10:33:35 -0400
Message-ID: <19970519103335.26202@redhat.com>
Date: Mon, 19 May 1997 10:33:35 -0400
From: Otto Hammersmith <otto@cu-online.com>
To: gtk-list@redhat.com, raph@acm.org
Subject: [patches] more tags for gzilla
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary=6c2NcOVqGQ03X4Wi
X-Mailer: Mutt 0.69
--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Well, I spent some spare time this weekend writing some code for gzilla.
I should've been doing other things, but hey, it's my weekend, right?
This mail should have six patches attached to it.
gzilla-0.02-hr.patch: Added support for the <hr> tag.
gzilla-0.02-address.patch: Added <address> tag. (absolutely trivial)
gzilla-0.02-dl.patch: Added support for description lists.
gzilla-0.02-pre.patch: Added reasonable support for <pre> tags.
gzilla-0.02-jumbo1.patch: Everything up to this point in a single patch to 0.02.
Note that the <pre> tag support is mostly done, except that tabs
aren't handled properly. There's a comment about it in the code... if
anyone can tell me the best way to solve it, I'd really like to know.
In any case, I noticed a few problems with gzilla while I was coding
this stuff.
Resize doesn't work at all. When the window is resized, the text
remains the same size. I presume you (Raph) already know that... just
thought I'd mention it.
Well, actually I suppose that was the only real problem I saw. :) It's
coming along quite nicely.. can't wait for the next code escape.
Thanks a bunch.
--
-Otto.
From raph@acm.org
Received: (qmail 20900 invoked from network); 19 May 1997 21:50:04 -0000
Received: from blacklodge.c2.net (208.139.36.35)
by mail2.redhat.com with SMTP; 19 May 1997 21:50:03 -0000
Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3) id OAA11112;
Mon, 19 May 1997 14:51:03 -0700 (PDT)
Date: Mon, 19 May 1997 14:51:03 -0700 (PDT)
From: Raph Levien <raph@acm.org>
X-Sender: raph@blacklodge.c2.net
To: Otto Hammersmith <otto@cu-online.com>
cc: gtk-list@redhat.com
Subject: Re: [patches] more tags for gzilla
In-Reply-To: <19970519103335.26202@redhat.com>
Message-ID: <Pine.BSF.3.91.970519140528.26615A-100000@blacklodge.c2.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 19 May 1997, Otto Hammersmith wrote:
> Well, I spent some spare time this weekend writing some code for gzilla.
> I should've been doing other things, but hey, it's my weekend, right?
>
> This mail should have six patches attached to it.
>
> gzilla-0.02-hr.patch: Added support for the <hr> tag.
> gzilla-0.02-address.patch: Added <address> tag. (absolutely trivial)
> gzilla-0.02-dl.patch: Added support for description lists.
> gzilla-0.02-pre.patch: Added reasonable support for <pre> tags.
> gzilla-0.02-jumbo1.patch: Everything up to this point in a single patch to 0.02.
>
> Note that the <pre> tag support is mostly done, except that tabs
> aren't handled properly. There's a comment about it in the code... if
> anyone can tell me the best way to solve it, I'd really like to know.
My original idea was to put the entire line, spaces and all, into a
single add_text. This would ensure that the line doesn't get broken. For
tabs (which, to be honest, I hadn't thought about), I'd expand them into
spaces before handing the line to add_text.
I didn't understand your comment about spaces causing the thing to crash.
If an add_text with embedded spaces caused a crash, it's probably just a
silly bug somewhere. Spaces aren't treated any differently.
> In any case, I noticed a few problems with gzilla while I was coding
> this stuff.
>
> Resize doesn't work at all. When the window is resized, the text
> remains the same size. I presume you (Raph) already know that... just
> thought I'd mention it.
Yeah, I know about this. It used to be that the size_alloc routine (the
one which attached to the size_alloc signal of the scrolledwindow) would
cause a gtk_page_set_width. However, gtk didn't like check_resize () being
called in the middle of a size_alloc operation, and, to register its
disapproval, would sometimes make the scrollbar state inconsistent. Thus,
the best approach seems to be to defer the gtk_page_set_width call to an
idle routine, so as to let the original size_all finish its work first.
A case can be made that _all_ check_resize calls should be deferred
until the idle cycle, for performance reasons, but I'll worry about that
later.
> Well, actually I suppose that was the only real problem I saw. :) It's
> coming along quite nicely.. can't wait for the next code escape.
It will probably be a week or so. I've got a paper that really needs to
get written this week.
> Thanks a bunch.
Thanks for the patches. I'm happy to accept contributions, especially as
it means less coding for me. Particular needs include text/plain and
image/jpeg bytesinks. Neither of these is particularly difficult, and it
should be possible to get a good start by looking over the text/html nad
image/gif bytesinks.
The other major usability need is a cache. This one is tricker and should
really only be undertaken by someone who knows the Web protocols and
asynchronous network programming intimately.
> -Otto.
Raph
From otto@redhat.com
Received: (qmail 5400 invoked from network); 20 May 1997 03:22:34 -0000
Received: from nimrod.redhat.com (otto@199.183.24.13)
by mail2.redhat.com with SMTP; 20 May 1997 03:22:34 -0000
Received: (from otto@localhost)
by nimrod.redhat.com (8.8.5/8.8.5) id XAA14547;
Mon, 19 May 1997 23:22:05 -0400
Message-ID: <19970519232204.21050@redhat.com>
Date: Mon, 19 May 1997 23:22:04 -0400
From: Otto Hammersmith <otto@redhat.com>
To: gtk-list@redhat.com, raph@acm.org
Subject: Re: [gtk-list] Re: [patches] more tags for gzilla
References: <19970519103335.26202@redhat.com>
<Pine.BSF.3.91.970519140528.26615A-100000@blacklodge.c2.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.69
In-Reply-To: <Pine.BSF.3.91.970519140528.26615A-100000@blacklodge.c2.net>;
from Raph Levien on Mon, May 19, 1997 at 02:51:03PM -0700
On Mon, May 19, 1997 at 02:51:03PM -0700, Raph Levien wrote:
>
> On Mon, 19 May 1997, Otto Hammersmith wrote:
>
> > Note that the <pre> tag support is mostly done, except that tabs
> > aren't handled properly. There's a comment about it in the code... if
> > anyone can tell me the best way to solve it, I'd really like to know.
>
> My original idea was to put the entire line, spaces and all, into a
> single add_text. This would ensure that the line doesn't get broken. For
> tabs (which, to be honest, I hadn't thought about), I'd expand them into
> spaces before handing the line to add_text.
That's what I did, at first. But it doesn't work...
gtk_page_add_text(page, "\n\t\tSome text");
The newline and tabs just end up disappearing.
Fortunately, the way things are parsed the any newline or tab in the
string is at the front, so they're easy to intercept. So, when (I
forget which function) a newline is found, the function calls
gtk_page_linebreak()... the tricky part is the tabs.
> I didn't understand your comment about spaces causing the thing to crash.
> If an add_text with embedded spaces caused a crash, it's probably just a
> silly bug somewhere. Spaces aren't treated any differently.
When a tab is found, I tried using gtk_page_add_text(page, " ")
but that caused seg faults on exit and when links were activated.
Multiple gtk_page_add_space()'s don't work either... only one space
ends up in the output.
I haven't really looked at the problem, since it wasn't that
important. I presume it's some problem with a counter somewhere not
being updated as it should be...
> > In any case, I noticed a few problems with gzilla while I was coding
> > this stuff.
> >
> > Resize doesn't work at all. When the window is resized, the text
> > remains the same size. I presume you (Raph) already know that... just
> > thought I'd mention it.
>
> Yeah, I know about this. It used to be that the size_alloc routine (the
> one which attached to the size_alloc signal of the scrolledwindow) would
> cause a gtk_page_set_width. However, gtk didn't like check_resize () being
> called in the middle of a size_alloc operation, and, to register its
> disapproval, would sometimes make the scrollbar state inconsistent. Thus,
> the best approach seems to be to defer the gtk_page_set_width call to an
> idle routine, so as to let the original size_all finish its work first.
Does this mean gtk_page_set_width can be used to expand the page after
it's first drawn? I'll give it a try... there are some HTML I'd like
to use gzilla for (HTML source with Global) that's just a tad too big
for the default width.
> A case can be made that _all_ check_resize calls should be deferred
> until the idle cycle, for performance reasons, but I'll worry about that
> later.
Another nice thing would be to only call a redraw when the updates are
to text/graphics in the visable window... i.e., on a big page, there's
a lot of flicker due to data loading way down at the end of the page
off the viewable window. Not sure how easy it would be to figure out
whether something is visable.
> > Well, actually I suppose that was the only real problem I saw. :) It's
> > coming along quite nicely.. can't wait for the next code escape.
>
> It will probably be a week or so. I've got a paper that really needs to
> get written this week.
>
> > Thanks a bunch.
>
> Thanks for the patches. I'm happy to accept contributions, especially as
> it means less coding for me. Particular needs include text/plain and
> image/jpeg bytesinks. Neither of these is particularly difficult, and it
> should be possible to get a good start by looking over the text/html nad
> image/gif bytesinks.
I should have some comments and ideas about the whole bytesink thing,
as soon as I can look at the code for a bit uninterrupted and see how
they fit in with my ideas for the filemanager.
> The other major usability need is a cache. This one is tricker and should
> really only be undertaken by someone who knows the Web protocols and
> asynchronous network programming intimately.
I've had some ideas on this, somewhat related to my thoughts on the
bytesink-similar constructs.... more to come.
I don't suppose you'd like to run the code through indent before the
next release? I did it to a couple files to make it easier to read,
but futzed things around to make the patches minimal.
--
-Otto.
From jmacd@CS.Berkeley.EDU
Received: (qmail 23640 invoked from network); 20 May 1997 11:56:44 -0000
Received: from paris.CS.Berkeley.EDU (128.32.34.47)
by mail2.redhat.com with SMTP; 20 May 1997 11:56:43 -0000
Received: from paris.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1])
by paris.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id EAA22976 for
<gtk-list@redhat.com>; Tue, 20 May 1997 04:56:20 -0700 (PDT)
From: Josh MacDonald <jmacd@CS.Berkeley.EDU>
Message-Id: <199705201156.EAA22976@paris.CS.Berkeley.EDU>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: [patches] more tags for gzilla
In-reply-to: Your message of "Mon, 19 May 1997 23:22:04 EDT."
<19970519232204.21050@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <22969.864129376.1@paris.CS.Berkeley.EDU>
Date: Tue, 20 May 1997 04:56:18 -0700
As I've said in the past, text formatting like this isn't easy.
Handling tabs is not a trivial matter, and was why I suggested
people try and share code with the text widget.
You want tabs to work when you see:
this text follows a tab.
blah so does this, and it's aligned with the above despite the
word "blah" preceding the tab.
I worked on the text widget few days ago and discovered why everyone
had come to the conclusion that it totally didn't work. The last
version I gave Pete, as I said, worked (with a few things I knew
didn't work, but at least it didn't core dump). Pete saw fit to
make a quick change without testing it between my last version
which totally broke things. I'll mail a version out sometime in
the next few weeks that works. In the interest of form over function,
the modifications I recently made were to disable all editing (because
Pete broke it) and make it support background pixmaps which scroll
with the text (this is, of course, far more important than editing,
right?).
People working on a HTML browser without consulting the text widget
are throwing away nearly 3500 lines devoted to text formatting,
drawing, and exposure. It'll probably grow another 1500 by the
time I finish h-scrolling and selection. It's well laid out. I figure
it wouldn't be very difficult even, to allow images or child widgets
to be inserted in the text. The only hard part about an HTML widget
from my perspective, using the text widget as a base, is handling
aligned images (a more general description would be, handling "flows"
in the FrameMaker sense). The text widget assumes there are lines of
text, where each element is a member of some font with known
dimensions. Using this abstraction, you can make embedded widgets
a special case--a unique element in a unique font with the correct
dimensions. The problem is that HTML doesn't always work this way,
because you have images aside a column of text (or, more generally,
two columns of text or any other "flow"). I haven't come up
with the solution to this little complication, but I suspect there
is one--I haven't thought about it much (because its not required
by the text widget.. its required for a word processor or web browser).
Throwing away all that code is not, in my opinion, very wise. Not
only is there a lot to do with simply drawing the text, there's a
lot more to do with efficiently caching the results of the computation
and being able to do reexposures and scrolling quickly.
>From the looks of it, you're charging in without thinking too much
about the design. Doing so, you're likely to miss much more than
tabs. I'm not trying to insult you guys, I'm just urging you to
consider rethinking your approach before you get too commited.
Design is critical. I assure you there's a 10x difference in the
complexity and line-count between a poorly and well-written web
browser. Don't start with the assumption that since the goal is
to end up with something small you should use a small or incomplete
design (what would Brooks say about how much time to spend designing?).
-josh
> On Mon, May 19, 1997 at 02:51:03PM -0700, Raph Levien wrote:
> >
> > On Mon, 19 May 1997, Otto Hammersmith wrote:
> >
> > > Note that the <pre> tag support is mostly done, except that tabs
> > > aren't handled properly. There's a comment about it in the code... if
> > > anyone can tell me the best way to solve it, I'd really like to know.
> >
> > My original idea was to put the entire line, spaces and all, into a
> > single add_text. This would ensure that the line doesn't get broken. For
> > tabs (which, to be honest, I hadn't thought about), I'd expand them into
> > spaces before handing the line to add_text.
>
> That's what I did, at first. But it doesn't work...
>
> gtk_page_add_text(page, "\n\t\tSome text");
>
> The newline and tabs just end up disappearing.
>
> Fortunately, the way things are parsed the any newline or tab in the
> string is at the front, so they're easy to intercept. So, when (I
> forget which function) a newline is found, the function calls
> gtk_page_linebreak()... the tricky part is the tabs.
>
> > I didn't understand your comment about spaces causing the thing to crash.
> > If an add_text with embedded spaces caused a crash, it's probably just a
> > silly bug somewhere. Spaces aren't treated any differently.
>
> When a tab is found, I tried using gtk_page_add_text(page, " ")
> but that caused seg faults on exit and when links were activated.
>
> Multiple gtk_page_add_space()'s don't work either... only one space
> ends up in the output.
>
> I haven't really looked at the problem, since it wasn't that
> important. I presume it's some problem with a counter somewhere not
> being updated as it should be...
>
> > > In any case, I noticed a few problems with gzilla while I was coding
> > > this stuff.
> > >
> > > Resize doesn't work at all. When the window is resized, the text
> > > remains the same size. I presume you (Raph) already know that... just
> > > thought I'd mention it.
> >
> > Yeah, I know about this. It used to be that the size_alloc routine (the
> > one which attached to the size_alloc signal of the scrolledwindow) would
> > cause a gtk_page_set_width. However, gtk didn't like check_resize () being
> > called in the middle of a size_alloc operation, and, to register its
> > disapproval, would sometimes make the scrollbar state inconsistent. Thus,
> > the best approach seems to be to defer the gtk_page_set_width call to an
> > idle routine, so as to let the original size_all finish its work first.
>
> Does this mean gtk_page_set_width can be used to expand the page after
> it's first drawn? I'll give it a try... there are some HTML I'd like
> to use gzilla for (HTML source with Global) that's just a tad too big
> for the default width.
>
> > A case can be made that _all_ check_resize calls should be deferred
> > until the idle cycle, for performance reasons, but I'll worry about that
> > later.
>
> Another nice thing would be to only call a redraw when the updates are
> to text/graphics in the visable window... i.e., on a big page, there's
> a lot of flicker due to data loading way down at the end of the page
> off the viewable window. Not sure how easy it would be to figure out
> whether something is visable.
>
> > > Well, actually I suppose that was the only real problem I saw. :) It's
> > > coming along quite nicely.. can't wait for the next code escape.
> >
> > It will probably be a week or so. I've got a paper that really needs to
> > get written this week.
> >
> > > Thanks a bunch.
> >
> > Thanks for the patches. I'm happy to accept contributions, especially as
> > it means less coding for me. Particular needs include text/plain and
> > image/jpeg bytesinks. Neither of these is particularly difficult, and it
> > should be possible to get a good start by looking over the text/html nad
> > image/gif bytesinks.
>
> I should have some comments and ideas about the whole bytesink thing,
> as soon as I can look at the code for a bit uninterrupted and see how
> they fit in with my ideas for the filemanager.
>
> > The other major usability need is a cache. This one is tricker and should
> > really only be undertaken by someone who knows the Web protocols and
> > asynchronous network programming intimately.
>
> I've had some ideas on this, somewhat related to my thoughts on the
> bytesink-similar constructs.... more to come.
>
> I don't suppose you'd like to run the code through indent before the
> next release? I did it to a couple files to make it easier to read,
> but futzed things around to make the patches minimal.
>
> --
> -Otto.
>
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
>
From raph@acm.org
Received: (qmail 1735 invoked from network); 22 May 1997 18:08:59 -0000
Received: from blacklodge.c2.net (208.139.36.35)
by mail2.redhat.com with SMTP; 22 May 1997 18:08:59 -0000
Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3)
id LAA25945; Thu, 22 May 1997 11:10:13 -0700 (PDT)
Date: Thu, 22 May 1997 11:10:12 -0700 (PDT)
From: Raph Levien <raph@acm.org>
X-Sender: raph@blacklodge.c2.net
To: Josh MacDonald <jmacd@CS.Berkeley.EDU>
cc: gtk-list@redhat.com
Subject: gtk_text vs. gtk_page
In-Reply-To: <199705201156.EAA22976@paris.CS.Berkeley.EDU>
Message-ID: <Pine.BSF.3.91.970522103114.23956A-100000@blacklodge.c2.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 20 May 1997, Josh MacDonald wrote:
> As I've said in the past, text formatting like this isn't easy.
> Handling tabs is not a trivial matter, and was why I suggested
> people try and share code with the text widget.
>
> You want tabs to work when you see:
>
> this text follows a tab.
> blah so does this, and it's aligned with the above despite the
> word "blah" preceding the tab.
Actually, for Netscape-style HTML formatting, you don't ever need tabs
with proportional fonts - you can always do the expansion into spaces
before passing the text to the text widget.
> I worked on the text widget few days ago and discovered why everyone
> had come to the conclusion that it totally didn't work. The last
> version I gave Pete, as I said, worked (with a few things I knew
> didn't work, but at least it didn't core dump). Pete saw fit to
> make a quick change without testing it between my last version
> which totally broke things. I'll mail a version out sometime in
> the next few weeks that works. In the interest of form over function,
> the modifications I recently made were to disable all editing (because
> Pete broke it) and make it support background pixmaps which scroll
> with the text (this is, of course, far more important than editing,
> right?).
>
> People working on a HTML browser without consulting the text widget
> are throwing away nearly 3500 lines devoted to text formatting,
> drawing, and exposure. It'll probably grow another 1500 by the
> time I finish h-scrolling and selection. It's well laid out. I figure
> it wouldn't be very difficult even, to allow images or child widgets
> to be inserted in the text. The only hard part about an HTML widget
> from my perspective, using the text widget as a base, is handling
> aligned images (a more general description would be, handling "flows"
> in the FrameMaker sense). The text widget assumes there are lines of
> text, where each element is a member of some font with known
> dimensions. Using this abstraction, you can make embedded widgets
> a special case--a unique element in a unique font with the correct
> dimensions. The problem is that HTML doesn't always work this way,
> because you have images aside a column of text (or, more generally,
> two columns of text or any other "flow"). I haven't come up
> with the solution to this little complication, but I suspect there
> is one--I haven't thought about it much (because its not required
> by the text widget.. its required for a word processor or web browser).
>
> Throwing away all that code is not, in my opinion, very wise. Not
> only is there a lot to do with simply drawing the text, there's a
> lot more to do with efficiently caching the results of the computation
> and being able to do reexposures and scrolling quickly.
>
> >From the looks of it, you're charging in without thinking too much
> about the design. Doing so, you're likely to miss much more than
> tabs. I'm not trying to insult you guys, I'm just urging you to
> consider rethinking your approach before you get too commited.
>
> Design is critical. I assure you there's a 10x difference in the
> complexity and line-count between a poorly and well-written web
> browser. Don't start with the assumption that since the goal is
> to end up with something small you should use a small or incomplete
> design (what would Brooks say about how much time to spend designing?).
Ok, I sense that a gauntlet has been thrown here.
I agree that studying the gtk_text widget is essential for anyone trying
to build a Web browser. It would also be great if the gtk_text and
gtk_page widgets got unified, to avoid proliferation of widgets that do
similar things. However, at this point, I'm still not completely convinced
that's the way to go.
Let's phrase the question in somewhat objective terms: would a unified
gtk_text/gtk_page widget (a) have fewer lines of code and (b) have
adequate features and performance for Web browsing? I'm not sure, but
here are some thoughts.
First, the gtk_page widget, as currently implemented, has quite a few
features that the gtk_text widget, as currently implemented (at least in
my copy of the 0.99.9 sources) lacks. First and foremost is support for
embedded widgets. It also has support for real line wraps, indentation
(sensitive to both line and paragraph breaks), variable amounts of spacing
in both horizontal and vertical dimensions, a set_width method for
controlling the set width, and clickable links. Further, in combination
with scrolledwindows it implements horizontal scrolling.
In the other direction (and I'll give the benefit of a doubt regarding
incompletely implemented features), gtk_text implements editing,
selection, and a scrollable background pixmap. Selection is definitely
useful for a Web browser, but editing is of questionable value. I suppose
the background pixmap is required for full Netscape HTML compliance, but
it's pretty low on my feature list.
gtk_page is 1500 lines of code, gtk_text is 3500. I think one of the
reasons gtk_page is more concise is its choice of a simpler data structure
to represent the page. gtk_page uses an array of lines, each of which is
an array of words, while gtk_text uses a combination of a gapped text
buffer, a doubly linked list of text properties, and a line start cache.
I'm not claiming that the gtk_page design is better, just that it's
completely appropriate for the goals of gzilla.
You mention throwing away code to do text formatting, drawing, and
exposure. I played with the gtk_text widget demo in testgtk, and found it
to be far from smooth. In particular, inserting characters caused the
entire widget to flash. The gtk_page widget does not have that problem.
(currently, child widget resizes _do_ cause the widget to flash, but that
will be fixed by the next code escape). Thus, you're going to have to make
a stronger case that gtk_text's handling of these issues is superior to
gtk_page's. I'm willing to make the claim that the exposure processing of
gtk_page is about as good as you can get.
Also, adding floating images would be pretty straightforward. Basically,
you'd just add {left,right}_float_{width,height} fields to the GtkPageLine
data structure. The width fields have obvious meaning, and the height
field specifies the height of the rectangle relative to the top of the
line. Thus, the routines that maintain the invariants of the GtkPageLine
data structure would subtract the line height from the previous height
field, saturating at zero. Then, the routine that handles indentation and
alignment would look at the height fields, and if non-zero, treat the
width fields as extra indentation.
I'll make the case that such a change is particularly easy to do in
gtk_page because the data structure is organized around the geometric
layout of the page. gtk_text, on the other hand, is organized around the
structure of the data. It's certainly possible to do everything that you
can do in gtk_page, but it requires at least another level of
indirection. Thus, I think there's a significant chance that adding all
of gtk_page's features to gtk_text will cause the code to grow more than
the size of gtk_page itself.
It may look like I'm jumping into the code of gzilla without having done
my design homework, but that's simply not true. I did a Java-based chat
server that had its own small Web browser in it. The Java display
engine was the prototype for gtk_page. I also thought pretty seriously
about how to implement all the text formatting I needed before committing
to the design.
The one thing I did jump into head first was GTK+ programming. It's been
pretty good, but I feel I've definitely come up against its limitations
(many of which are in the size negotiation mechanism, which I think could
use some serious work). My original plan was to support tables through
the gtk_table mechanism, but now I think there's a good chance that this
would stress GTK+'s poor size negotation well past the breaking point.
There is one serious misfeature in gtk_page: because it creates an X
window to hold the entire page, the size of the page is limited to the
maximum size of an X window: 32767 pixels. gtk_text doesn't have this
problem. However, I'm concerned about the aesthetics of scrolling when
such a widget has embedded widgets (with their own windows). What would
happen is that the page widget would do a pixmap-based scroll, which would
be fine. However, some of the data would scroll to under the child
widget's windows, and be lost. Then, (using size_allocate, I suppose),
the child windows would be moved, causing expose events to go through the
X server, for the areas that the child windows uncovered. These would
then be handled by the page widget. As a consequence, the embedded
widgets would appear to lag behind the text on the page, and also the
text near widgets would flicker. This just wouldn't be cool.
I'm not sure what the best solution is. I'm still open to ideas.
Raph
From jmacd@CS.Berkeley.EDU
Received: (qmail 28835 invoked from network); 22 May 1997 20:43:25 -0000
Received: from paris.CS.Berkeley.EDU (128.32.34.47)
by mail2.redhat.com with SMTP; 22 May 1997 20:43:24 -0000
Received: from paris.CS.Berkeley.EDU (localhost.Berkeley.EDU [127.0.0.1])
by paris.CS.Berkeley.EDU (8.8.3/8.8.2) with ESMTP id NAA27156;
Thu, 22 May 1997 13:42:40 -0700 (PDT)
From: Josh MacDonald <jmacd@CS.Berkeley.EDU>
Message-Id: <199705222042.NAA27156@paris.CS.Berkeley.EDU>
To: Raph Levien <raph@acm.org>
cc: gtk-list@redhat.com
Subject: Re: gtk_text vs. gtk_page
In-reply-to: Your message of "Thu, 22 May 1997 11:10:12 PDT."
<Pine.BSF.3.91.970522103114.23956A-100000@blacklodge.c2.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <27149.864333758.1@paris.CS.Berkeley.EDU>
Date: Thu, 22 May 1997 13:42:39 -0700
> First, the gtk_page widget, as currently implemented, has quite a few
> features that the gtk_text widget, as currently implemented (at least in
> my copy of the 0.99.9 sources) lacks. First and foremost is support for
> embedded widgets. It also has support for real line wraps, indentation
> (sensitive to both line and paragraph breaks), variable amounts of spacing
> in both horizontal and vertical dimensions, a set_width method for
> controlling the set width, and clickable links. Further, in combination
> with scrolledwindows it implements horizontal scrolling.
A quick comment. I guess I wasn't subtle enough in my last mail. I hate
to do this to Pete. Pete broke the text widget VERY BADLY since the last
version I gave him. This is why it crashed when newlines were inserted.
This is why it redraws and recomputes everything when you run your test.
When I fix it once again, it won't redraw the whole widget at each insertion.
Also, selection doesn't work yet. I'll get out a new version sometime.
I think I'll also try to implement embedded widgets, then we can decide
how the performance is.
Also, have you proposed how to fix the size negotiation stuff?
-josh
From amundson@cs.umn.edu
Received: (qmail 27727 invoked from network); 1 Jun 1997 07:41:15 -0000
Received: from augustus-148.cs.umn.edu (HELO augustus-239.cs.umn.edu)
(root@160.94.148.171)
by mail2.redhat.com with SMTP; 1 Jun 1997 07:41:14 -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 CAA09476
for <gtk-list@redhat.com>; Sun, 1 Jun 1997 02:40:46 -0500 (CDT)
Received: from localhost (amundson@localhost) by caesar.cs.umn.edu (8.8.3/8.8.0)
with SMTP id CAA03393 for <gtk-list@redhat.com>; Sun, 1 Jun 1997 02:40:44 -0500 (CDT)
X-Authentication-Warning: caesar.cs.umn.edu: amundson owned process doing -bs
Date: Sun, 1 Jun 1997 02:40:44 -0500 (CDT)
From: Shawn T Amundson <amundson@cs.umn.edu>
To: GTK Mailing List <gtk-list@redhat.com>
Subject: gtkcalendar-0.03 available
Message-ID: <Pine.GSO.3.95q.970601022048.3333A-100000@caesar.cs.umn.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
This is just for those curious developers, because I told
Otto I'd put it up last Monday. ;-) It may also help in
some of the relief and borderwidth discussions as an example.
ftp://ftp.cs.umn.edu/dept/users/amundson/gtkcalendar/gtkcalendar-0.02.tar.gz
It is obviously in flux as I'm not sure how to do some of
the things I have to implement in order to use it for Aorta.
The TODO list is a good list of where I want to go with the
widget.
gtkflattogglebutton.[ch] don't do anything because
the method of drawing the raised relief in gtktogglebutton is
inconsistant with that of gtkbutton.
Suggestions/Comments/Code welcome.
--
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 raph@acm.org
Received: (qmail 13350 invoked from network); 2 Jun 1997 19:11:08 -0000
Received: from callisto.hip.berkeley.edu (136.152.64.218)
by mail2.redhat.com with SMTP; 2 Jun 1997 19:11:01 -0000
Received: (from raph@localhost) by callisto.hip.berkeley.edu (8.6.12/8.6.12)
id MAA31286 for gtk-list@redhat.com; Mon, 2 Jun 1997 12:11:32 -0700
Message-ID: <33931ADF.E84B9D0@acm.org>
Date: Mon, 02 Jun 1997 12:11:27 -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: More gzilla/gtk issues
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hi gtk developers,
I'm continuing to think about the issues involved in implementing
gzilla smoothly on gtk.
I've decided that the page display widget should do its own
scrolling, rather than creating a large window and relying on
scrolledwindow to do the scrolling. The issue here is the 32767 pixel
limit on the height of the window. If I use a scrolledwindow, there just
isn't any good way of getting around it. I am still concerned about
aesthetics problems with doing the scrolling inside the page display
widget (most importantly, embedded widgets without the NO_WINDOW
property will lag slightly while scrolling, and will also cause some
flashing of the underlying text). However, this problem has two
solutions which preserve the interface to the page display widget. Thus,
it's possible to agree on an interface now and possibly fiddle with the
implementation later.
The first possiblity (suggested by Owen Taylor) is to put each
paragraph in its own window. The page display widget would then juggle
these windows, only displaying the ones that were actually visible.
Scrolling would be done by moving each of the windows individually.
The second possibility is to extend the gtk infrastructure to support
events in NO_WINDOW widgets, and retrofit all widgets that would be
included in a page to be NO_WINDOW. This requires a significant change
to all containers: they need to be able to dispatch mouse and keyboard
events to their child widgets. This is a fairly radical change to gtk,
but might be worthwhile anyway for the performance increase.
But, as I said, it's definitely possible to go forward without
implementing either of these alternatives.
Now that I've decided to redo a large part of the page display
widget, it reopens the possibility of merging gtk_page and gtk_text. The
advantages are clear. However, there are certain disadvantages as well.
For one, we'd have to coordinate between the two major developers of the
widget. What I think would work best is for Josh to polish it to the
point that he described a week or so ago, then hand it over to me for
adding all of the Web-specific stuff. Otherwise, I think we'd be
stepping on each other's toes too much. It would also help if Josh gave
me some guidelines on how new attributes should be added.
A second disadvantage is that, to support all of the Web extensions,
the interface would have to change quite dramatically. We could either
go back and change all the code which uses gtk_text, or we could retain
a backwards compatible interface in addition to the extended one. This
may not be a big problem, because the only code that seems to use
gtk_text now is install.c in the Gimp.
Finally, the widget would be huge. It's easy to imagine that it could
hit 10 kloc by the time all the floating images, alignment and spacing
options, etc., are added. It may be that two smaller widgets would be
more manageable than one large one, even if the total number of lines of
code comes out a little bigger.
I'll leave the choice to Josh. If he agrees to hand over a reasonably
full-featured gtk_text widget to be extended for Web page display, I'll
scrap gtk_page and retrofit gtk_text to do what I need. Otherwise, I'll
just continue developing gtk_page.
The next point is size negotiation. There are basically two problems
with size negotiation in the current gtk. The first is that check_resize
often forces a lot more work than really needs to be done. The second is
support for wrapping layouts in general (more on this later).
I'm still not sure whether check_resize presents a real problem. The
disable_resize / enable_resize hack actually works pretty well. If not,
it should be possible for the page display widget to override
need_resize to add the child widget to a queue, and set an idle handler
which will resize only the child widgets that are in the queue. Perhaps
the same change should be made to boxes and tables as well, so as to
avoid the need for the disable_resize / enable_resize hack altogether.
In any case, this doesn't bother me very much now. It's possible to
fix without changing any of the interfaces, and in any case it's just a
performance bug.
The next big decision is how to handle tables. The original design
for gzilla called for a modular structure corresponding exactly with the
gtk widget hierarchy. Thus, a table would be implemented using an
embedded gtk_table widget, and each of the table entries would be a
child widget of the gtk_table. However, as clean as this idea seems
conceptually, in practice there would be a lot of problems:
* Tables would be limited to 32767 pixels in size
* The size negotiation of gtk is inadequate to handle wrapped text
* In the most straightforward implementation, each table entry would
have its own window. That could be a _lot_ of windows, which could be a
big performance hit (on my system, testgtk takes about 2 seconds to pop
up 400 buttons in the scrolledwindow test).
* The gtk_table widget doesn't draw borders, and would have to be
extended to do so
I think I've pretty much figured out how to fix the size negotiation.
Just to recap, gtk's size negotiation is based around the size_request
and size_allocate methods. The size_request method is called as part of
the initialization phase of a widget's lifecycle. It returns a "minimum
comfortable size" for the widget. Containers generally try to allocate
at least this much space to their child widgets. Conversely,
size_allocate is called by the container to tell the child what size it
actually is. This is called at least once in the initialization phase,
and also whenever the container gets rearranged (for example, if the
window is resized).
Whenever a child widget wants to resize, it calls
gtk_container_check_resize on its parent. This, in turn, causes
size_request to get called again on the child, then (after the container
is rearranged), size_allocate and then draw on the child. Most of the
time, size_allocate clears the widget, so draw is drawing on blank
pixels. Thus, check_resize causes a total redraw of the widget, whether
the size has actually changed or not. This is why many of the widgets do
a check_resize whenever their state changes - it's the easiest way to
force a total repaint, even though it may cause serious performance
implications.
Ok, now for some ideas on how to extend this to "wrapping widgets."
Obviously, the way gtk_page wraps text makes it a wrapping widget, but
there are plenty of other possibilites. For example, menus may be
designed to take more than one line if there's not enough horizontal
space for the whole thing. If the gimp's toolbar was defined as a
wrapped collection of rectangles, it could reshape to 21x1, 3x7, 7x3, or
1x21, depending on the user's preference. So this may be something that
belongs in the gtk generally.
The main property of wrapping widgets is that their requisition
height depends on their allocation width. If you make the window wider,
it will (usually) become less deep. In gtk's current size negotiation,
the requisition depends only on the internal state of the widget.
My solution to this problem is to add another method to gtk_widget
called wrap_allocate. It takes a width as an argument, and returns a
height. For a container to do a size_allocate, it will (in general) want
to determine widths for each of its children, call wrap_allocate on each
of the children using this width, then do its usual size allocation,
treating the returned height as the child widget's requisition.
This still leaves the question open of how the container determines
the width of the child widget. For some containers (vbox), it's pretty
simple, but for tables it needs to be a bit more complex. For example,
consider a table with two columns. In the first column of each row is a
single word. In the second column of each row is a good-sized paragraph.
A good table layout would give a hundred pixels or so to the first
column, and the rest of the window to the second. But how does the table
widget know to do this? Certainly, there's not enough information from
just the size_request call. My solution is to add a gtk_wrap_request
method to gtk_widget, which works just like size_request, but returns
both a "minimum comfortable width" and a "maximum comfortable width".
For wrapped text such as a web page, the minimum comfortable width is
the width of the narrowest unbreakable word (or embedded widget), and
the maximum comfortable width is the width of the widest paragraph if
there are no line breaks at all. Both of these are pretty
straightforward and efficient to calculate.
This extra method makes table layout a bit more tricky, but it's not
too bad. Basically, it needs to allocate all of the minimum widths
first. Of the remaining space, it tries to fulfill the maximum width
requests of each of the columns, in order of increasing
(maximum-minimum) width. Finally, as soon as it reaches a column for
which it's not capable of filling the maximum width request, or if it
fills all of them, it distributes the extra space among the remaining
columns, using the same algorithm it already uses (i.e. if the expand
flags are set, it will distribute it evenly across all columns).
In my opinion, this will get table layout exactly right. Have any of
you noticed how sloppy Netscape's table layout is (at least on Unix)? It
almost always causes the set width to exceed the window size, which
causes a horizontal scrollbar. I'm confident my approach will avoid this
problem.
The changes to gtk are nontrivial but not too bad. The default
implementation for wrap_allocate should just be to return the
requisition height. Similarly, wrap_request just returns the requisition
width as both the minimum and maximum values. Thus, non-wrapping widgets
will not have to change at all. Containers will have to change, but not
too dramatically.
I'm pretty comfortable with this recommendation, but am not sure if
the rest of the gtk community is willing to accept the extra complexity.
It's likely that wrapping widgets would only be heavily used in gzilla.
It wouldn't be too hard to just do tables within the page widget, and
I'd also avoid the 32767 pixel limit and thousands-of-teeny-windows
performance bug. But I'd like to avoid the duplication of code with
gtktable.c if it's at all practical.
Again, I'm open to ideas.
Finally, I've been experimenting with antialised text using t1lib.
The initial results are encouraging, but it's going to need a bit more
work. For one, t1lib's antialiasing code is very slow. It's also stuck
at 2x antialiasing, while I think the extra smoothness of 4x is worth
it. In any case, I sent some of my fast antialising code to Reiner, so
it's likely that a future release of t1lib will contain some really
spiffy antialising code. In any case, it's fun to play with.
Raph
From otto@redhat.com
Received: (qmail 31677 invoked from network); 3 Jun 1997 15:50:50 -0000
Received: from nimrod.redhat.com (otto@199.183.24.13)
by mail2.redhat.com with SMTP; 3 Jun 1997 15:50:49 -0000
Received: (from otto@localhost)
by nimrod.redhat.com (8.8.5/8.8.5) id LAA00405;
Tue, 3 Jun 1997 11:50:37 -0400
Message-ID: <19970603115037.31665@redhat.com>
Date: Tue, 3 Jun 1997 11:50:37 -0400
From: Otto Hammersmith <otto@redhat.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] More gzilla/gtk issues
References: <33931ADF.E84B9D0@acm.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.74
In-Reply-To: <33931ADF.E84B9D0@acm.org>; from Raph Levien on Mon, Jun 02, 1997
at 12:11:27PM -0700
On Mon, Jun 02, 1997 at 12:11:27PM -0700, Raph Levien wrote:
>
[lots of thoughts snipped]
>
> I'm pretty comfortable with this recommendation, but am not sure if
> the rest of the gtk community is willing to accept the extra complexity.
> It's likely that wrapping widgets would only be heavily used in gzilla.
> It wouldn't be too hard to just do tables within the page widget, and
> I'd also avoid the 32767 pixel limit and thousands-of-teeny-windows
> performance bug. But I'd like to avoid the duplication of code with
> gtktable.c if it's at all practical.
I could also use some widget-wrapping stuff in gtk. I haven't touched
any of that stuff with my filemanager, just yet... but I had intended
on writing something of the sort into the iconbox widget.
Plus, I like the idea of having menu bars that wrap appropriately, if
I feel like making a window smaller than it wants to be. :)
As for the specific implementation... I haven't given it much thought,
but it seems what you suggest is reasonably thought out. I can't
really think of a good way to deal with it, without creating dozens of
new widgets for each special case. (the idea of having all the
wrapping code in one place gives me the warm fuzzies... I don't want
to debug the same code in a dozen different places)
> Finally, I've been experimenting with antialised text using t1lib.
> The initial results are encouraging, but it's going to need a bit more
> work. For one, t1lib's antialiasing code is very slow. It's also stuck
> at 2x antialiasing, while I think the extra smoothness of 4x is worth
> it. In any case, I sent some of my fast antialising code to Reiner, so
> it's likely that a future release of t1lib will contain some really
> spiffy antialising code. In any case, it's fun to play with.
Ohh! Finally, a web browser with antialised fonts... I'm truly sick
of the lousy job Netscape does. :)
--
-Otto.
From raph@acm.org
Received: (qmail 20755 invoked from network); 5 Jun 1997 18:51:29 -0000
Received: from callisto.hip.berkeley.edu (136.152.64.218)
by mail2.redhat.com with SMTP; 5 Jun 1997 18:51:27 -0000
Received: (from raph@localhost) by callisto.hip.berkeley.edu (8.6.12/8.6.12)
id LAA06500 for gtk-list@redhat.com; Thu, 5 Jun 1997 11:52:50 -0700
Message-ID: <33970AF9.1A4858FF@acm.org>
Date: Thu, 05 Jun 1997 11:52:41 -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: gzilla 0.03
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Gzilla 0.03 is now up on the gzilla Web page:
http://www.levien.com/gzilla/
It's definitely still alpha code, but it's coming along quite nicely.
Try it out and let me know what you think.
Raph
From raph@acm.org
Received: (qmail 26481 invoked from network); 24 Jun 1997 05:02:15 -0000
Received: from blacklodge.c2.net (208.139.36.35)
by mail2.redhat.com with SMTP; 24 Jun 1997 05:02:15 -0000
Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3)
id WAA17948; Mon, 23 Jun 1997 22:02:13 -0700 (PDT)
Date: Mon, 23 Jun 1997 22:02:13 -0700 (PDT)
From: Raph Levien <raph@acm.org>
X-Sender: raph@blacklodge.c2.net
To: gtk-list@redhat.com
Subject: Gzilla widget set design proposal
Message-ID: <Pine.BSF.3.91.970623215809.17798A-100000@blacklodge.c2.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Here's the design proposal for the gzilla widget set. I think overall it's
pretty good, although I'm sure it's going to need some tinkering before
it's finished.
Raph
Preliminary design for Gzilla widget set
23 June 1997
Raph Levien <raph@acm.org>
I've decided that Gzilla will contain its own widget set
specialized for the display of Web pages. The original design for
Gzilla was to use GTK widgets entirely for this purpose, but now it
seems clear that this approach is not adequate. Here are the problems
I see:
1. GTK widgets inherit the 32767 pixel size limitation from X11. Since
Web pages can easily exceed this limit, it's not feasible to use a GTK
widget to represent the Web page (although this is what gzilla
currently does).
For the next two, I'm assuming that tables will be constructed with a
table widget (analogous to gtk_table) , and that each entry in the
table will also be a widget. This approach seems like a really good
idea from a modularity standpoint.
2. For GTK child widgets to get mouse events, they need to have their
own X11 windows. Thus, a good sized table could make hundreds or
thousands of these, probably swamping the X server. (Judging from the
scrolledwindow test in testgtk.c, the overhead for window creation is
in the 10ms range).
3. GTK size negotiation doesn't support wrapped text. In other words,
there's no way for the height of the widget to depend on the width.
4. Performance. When dealing dynamically with large numbers of child
widgets, GTK containers currently _suck_. Basically, they redraw the
entire container every time anything changes. In fairness, these
containers could almost certainly be tuned for better performance.
However, two issues remain: gtk_object method dispatch overhead, and
visibility (if changes happen outside the visible area, then
repainting can be avoided altogether).
Josh MacDonald's gtk_text widget deals with some of these issues,
but cannot be extended in modular fashion to handle things like
tables, and also cannot cleanly support GTK child widgets.
Thus, I propose a new Gzilla widget set to function alongside the
GTK widget set. Gzilla widgets will be extremely specialized - they
will lack all features not required for Web page display (I have in
mind grabs, focus, keyboard accelerators, key events, selections, and
connectable signals, leaving only size negotiation, exposure, and
mouse events). If any of these features are desired, do it in a GTK
widget and embed it in a Gzilla widget that contains embedded GTK
widgets. Similarly, there will be a scrolledwindow that is both a GTK
widget and a container for Gzilla widgets. This widget will handle all
of the gorp that's required to get widgets larger than 32767 pixels to
scroll cleanly.
Architecture
To avoid the overhead of gtk_object signals, and also to make
better use of the C type system, Gzilla widgets will use a simple
class and function pointer dispatch technique.
Specifically, one of the fields of a Gzilla widget will be a
pointer to a klass struct (so named to avoid conflict with a C++
reserved word). The klass struct contains function pointers for each
of the methods. Usually, the klass structures will be set up
statically, one for each type of widget. A method is invoked as
follows:
widget->klass->method (object, args...);
The cost is two dereferences and an indirect function call. There
will be macros to hide some of this syntax, i.e.
#define gzilla_widget_destroy(widget) widget->klass->destroy (widget);
(note: perhaps "methods" would be a slightly better name than
"klass"?)
Widgets will contain the following fields:
struct _GzillaWidget {
gint req_width_min; /* the minimum comfortable width */
gint req_width_max; /* the maximum comfortable width */
/* If the widget is not to be baseline aligned, it sets its
req_height to the height, and req_ascent zero. Conversely, if it
wants to be baseline aligned, it sets req_height and
req_ascent. The descent is the height minus the ascent.
*/
gint req_height;
gint req_ascent;
/* Allocation is similar to GTK.
x, y coordinates are relative to the toplevel Gzilla widget.
*/
GzillaRect allocation;
/* Flags include:
+ alignment options (baseline, vertical, horizontal?)
+ information about what's currently displayed, one of:
+ valid data (no need for repaint)
+ previously valid data (can incrementally repaint)
+ window background (don't need to clear before drawing)
+ good data underneath (don't clear before drawing; for layers)
+ unknown (better clear and repaint)
+ widget needs resize
+ widget contains embedded GTK widget (used to prune propagation
of gtk_foreach calls)
*/
gint flags;
GzillaWidget *parent;
/* Information about the enclosing gtk container. */
GzillaContainerInfo *container;
};
struct _GzillaContainerInfo {
/* The GTK widget that contains the toplevel Gzilla widget */
GtkWidget *widget;
/* x, y coordinates are relative to the toplevel Gzilla widget. */
GzillaRect visibility;
/* Add (x_offset, y_offset) to toplevel Gzilla coordinates to
arrive at X11 window relative coordinates. */
gint x_offset, y_offset;
};
The following methods will be supported:
/* Determine the height of the widget given a width of width, and
store in the req_height, req_ascent, and req_descent fields. */
void
alloc_width_req_height (GzillaWidget *widget, gint width);
/* Set the allocation rectangle in the widget, and propagate to child
widgets if necessary. */
void
size_allocate (GzillaWidget *widget,
GzillaRect *allocation);
/* Paint the expose rectangle. The x and y arguments contain the
coordinates of the upper left corner of the widget with respect
to the enclosing X11 window. This routine is also responsible for
setting the flags to indicate that the window data is valid. */
void
paint (GzillaWidget *widget,
gint x,
gint y,
GzillaRect *expose);
/* Handle a mouse event. The different events (button_press,
button_release, and motion_notify) are combined to avoid code
duplication in containers.
Should we return a boolean to indicate whether the event was
handled?
*/
void
mouse_event (GzillaWidget *widget,
GdkEventAny *event);
/* Do the callback once for every gtk widget inside the active
rectangle. */
void
gtk_foreach (GzillaWidget *widget,
GtkCallback callback,
gpointer callback_data,
GzillaRect *active);
/* Destroy the widget, freeing all resources claimed by the widget. */
void
destroy (GzillaWidget *widget);
In addition, two methods are supported only by containers (they
will never be called on child widgets):
/* Request that the widget be resized. */
void
request_resize (GzillaWidget *container,
GzillaWidget *child);
/* include new widths as arguments, to support incremental updating? */
/* Request that the widget be repainted. */
void
request_repaint (GzillaWidget *container,
GzillaWidget *child);
These requests will generally just set flags asking that the widget
get resized or repainted, then start a GTK idle process that calls
size_allocate to actually change the size. Thus, if a string of resize
requests comes in, the actual recalculation will only be done once.
Widget lifecycle
The widget lifecycle is considerably simplified with respect to
GTK. In particular, the init, realize, and map methods are missing.
The width half of size_request is also missing.
First, a *_new () call creates the widget, which is now in an
unmapped state (container is NULL). Additional calls can be used to
fill it with data, if necessary. At this point, the req_width_min and
req_width_max fields are valid. The widget is then either added to a
container or given to the scroller. Either way, a flag is set
indicating that the widget needs resize (setting the flag is the
responsibility of the container add). The request_resize request
propagates to the top of the widget hierarchy. If it's mapped, then
that starts an idle process which eventually starts the
process.
The container add function loads the req_width_min and
req_width_max fields of the child widget, and updates its own
req_width_min and req_width_max accordingly. In most cases, this
recalculation can be done incrementally, without having to scan all
the child widgets. For example, a vbox container just sets its own
req_width_min to the child widget req_width_min if it's smaller, and
similarly for req_width_max.
The idle process starts the next phase of size allocation with a
call to alloc_width_req_height on the toplevel widget. Now, the
toplevel widget knows how much width it is allocated, decides the
width of each of its child widgets, and propagates the
alloc_width_req_height down the tree.
It then gathers the req_height information from each of its
children an calculates the height of the overall widget (for the vbox
widget, it's just the sum). It then returns to the toplevel container.
The toplevel container then calls size_allocate on the toplevel
widget, which again propagates it to its children, almost entirely
analogous to GTK. Note that the width in the allocation can be
completely different than that in the alloc_width_req_height call
(perhaps the name of the latter should be changed). For example, in a
scrolling widget, the alloc_width_req_height is the width of the
window minus padding for the scrollbars, while the size_allocate width
is the maximum of that width and the req_width_min of the child.
Finally, the toplevel container calls paint on the toplevel widget,
which again propagates it to its children. The window is now painted
and quiesces.
When a widget needs to change size, it calls request_resize on its
container. In general, that just sets a bit and (if the bit was not
already set) propagates the request_resize to the top of the
hierarchy, where it's handled by an idle process associated with the
top container.
When a widget's data changes, it has two choices. First, it can
call request_repaint on its container, which will propagate the "needs
repaint" bit to the top of the hierarchy for handling by an idle
process, much like the resize request. This is especially useful if
the changes might be bursty - they may get clumped together, saving
repaint time. The second choice is to just repaint the data. However,
if the widget is in need of resize, it should always defer the
repainting.
Widgets
Initially, I envision that there would be exactly four Gzilla
widgets and one GTK widget that served as a Gzilla container. These
would be the page, bullet, GTK embedder, and table widgets, and
the scroller. The page widget would be very similar to the existing
gtk_page widget in gzilla 0.0.9. The bullet widget is trivial - it
just draws nice bullets. The GTK embedder would take care of embedding
a GTK widget in the Gzilla framework. The table widget would be quite
analogous to the GTK's table widget, but would be much smarter in
laying out wrapped text. It would also support HTML specific features
such as visible borders, size hints, and background colors for the
table entries.
Finally, the scroller would be responsible for embedding the Gzilla
widget back into GTK. In functionality, it's basically the same as
GTK's scrolled_window widget, but it has to do a lot more to handle
the new size negotiation, especially with widgets greater than 32767
pixels. Implementation of this module will be fairly gorpy, which is
one of the main reasons why I'm proposing splitting the page display
into Gzilla widgets rather than doing a monolithic page widget with
wrapped text, tables, and embedded widgets. Ideally, the scroller can
be reused for other GTK programs that require scrolled windows that
may exceed 32767 pixels.
Scrolling architecture
There are several possible ways to implement scrolling. Gzilla
0.0.9 currently defines a fixed size 32767 pixel window, and uses a
gdk_window_move_resize call (which in turn calls XMoveResizeWindow) to
move the window around inside the viewport. This has a lot of
advantages - child windows move around with the main one, and the X
server is responsible for generating expose events for the regions
that scroll into view. It's pretty nice, but limited to 32767 pixels.
A different approach is taken by GTK's text widget. gtk_text has a
window that's the size of the viewport, and uses the scroll position
as an offset for drawing into the window. It uses a gdk_draw_pixmap
call (which in turn calls XCopyArea) to scroll the window contents.
This is also a pretty good approach, and is what I'd use if I didn't
have to worry about embedded widgets.
However, in GTK, each widget that can accept keyboard and mouse
input must have its own X Window. Thus, in addition to scrolling the
contents of the page with XCopyArea, it would also be necessary to
move each of the child windows separately. The problem is that,
because the child windows can't be moved at the same time as the page
contents, they will uncover and then re-obscure actual page data. This
will generate expose events, so there will be flashing in the wake of
child widgets when the window is scrolled. Even without the flashing,
there would be a lag between the page and the child widgets, which
would not be aesthetically pleasing.
Thus, for Gzilla I plan to use a hybrid approach. For all pages
smaller than 32767 pixels, it will behave exactly as Gzilla 0.0.9. For
larger pages, whenever the scrolling nears the edge of the 32767 pixel
window, the whole contents of the window get shifted by about 20000
pixels, and the page gets completely redrawn. Any child widgets that
jumped off the edge of the window become unmapped, and any that come
inside the new window's coordinates become mapped. Those that stay on
the window simply get moved with a size_allocate method invocation,
which turns into a gtk_window_move_resize call. The gtk_foreach method
will be used to dispatch the appropriate GTK method calls to the
embedded GTK widgets.
Thus, the entire window will flash very infrequently, and only on
large pages. I consider this an acceptable compromise.
Tables
The details of the table widget should help to motivate the design
of the size negotiation mechanism. In this section, I present a very
simplified table widget (no rowspan or colspan, no size hints) and
describe how the size negotiation could get implemented.
Whenever table entries are added, the table widget incrementally
updates its req_width_min and req_width_max fields. The req_width
(either min or max) is the sum of the req widths of all columns, and
the req width of each column is the maximum of the req_width of its
entries.
The next phase of size negotiation is the alloc_width_req_height
call. Here's where the core of the actual table layout happens -
deciding the width to allocate to each column. Expressed formally,
it's a matter of finding x_set such that:
__
\
x_total = / max (req_width_min (i), min (req_width_max (i), x_set))
--
i = 1..n_cols
where req_width_{min,max} (i) is the minimum (or maximum)
requisition width for column i, and x_total is the total width given
in the alloc_width_req_height method invocation.
There are a few ways to solve this. The bisection method will have
good performance and is really easy to code, so that's what I think
I'll use, even though there are no doubt fancier algorithms. The
bisection method will also scale up nicely when rowspans and such are
added.
Once x_set is found, then the width of each column is just max
(req_width_min (i), min (req_width_max (i), x_set)). If you don't
understand the math, don't worry. It basically says that it tries to
make the columns all even width, to fill up the total space given, but
respects the minimum and maximum widths of each entry.
Note: the equation above doesn't have a solution when x_total is
greater than the sum of the req_width_max for all columns. In that
case, you can do basically the same thing but ignoring the
req_width_max'es altogether.
Once the column widths are determined, the table widget call
alloc_width_req_height on each of its children. The total height is
the sum of the heights of all of the columns, each of which is the
maximum of the heights of the entries within the column. Again, this
becomes slightly more complex in the face of colspans.
When the _actual_ width is allocated, in the size_alloc call, the
table widths may be calculated again. However, in most cases the width
given will be the same as in the alloc_width_req_height call.
Painting is pretty straightforward - just dispatching the paint
event to the children. One quirk is when table entries have
backgrounds. In that case, the table widget draws a filled rectangle
with the background color and set's the child widget's flags
indicating what's underneath to "good data underneath" before invoking
the paint method of the child.
Embedded GTK widgets
When adding new GTK widgets, it is imperative to avoid repainting
the entire page. Yet, all GTK containers implement their add or pack
methods by adding the child widget to the data structure, then calling
gtk_container_check_resize on the container, which almost always does
result in a repaint of the entire container.
The Gzilla widget that embeds GTK widgets will simply avoid calling
gtk_container_check_resize when adding new widgets. Instead, it will
directly invoke the GTK methods needed to get the child widget
displayed. Essentially, this sequence is size_request, size_allocate,
realize, and map. If the new widget is outside the visibility
rectangle, it may even be possible to defer the realize and map calls
until it actually does become visible.
I'm not really sure what the hell happens when the child widget
requests a size change. I think the right answer may be as simple as
providing a need_resize method that invokes request_resize on the GTK
widget's Gzilla container, then returns FALSE indicating that no more
work is needed from GTK.
I've just looked through the resize code in GTK, and must confess
that I'm lost. Some of it is clear to me, but it seems to me that the
topmost test in gtk_container_check_resize (i.e. the return value from
the gtk_container_needs_resize call) must always be true, otherwise
the child widget may not get redrawn. Actually, from testing I know
that bugs exist in which the child widget doesn't get redrawn
(especially when the topmost container is a viewport), so maybe the
code is flat out wrong. It looks like some careful hacking is needed.
Baseline alignment
I should say a little about baseline alignment. Putting multiple
widgets on a line with baseline alignment (and perhaps also with other
text) is calculated the same way as a table with two rows. The first
row represents the ascent, and the second row represents the descent.
If a widget is not to be baseline aligned, then it's basically the
same as a colspan of two.
From camm@enhanced.com
Received: (qmail 13312 invoked from network); 25 Jun 1997 12:49:44 -0000
Received: from enhanced.ppp.cyberenet.net (HELO wisdom) (@208.17.129.184)
by mail2.redhat.com with SMTP; 25 Jun 1997 12:49:43 -0000
Received: by enhanced.com
id m0wgrRY-0004KDC
(Debian Smail-3.2 1996-Jul-4 #2); Wed, 25 Jun 1997 08:45:04 -0400 (EDT)
Sender: camm@enhanced.com (Camm Maguire)
Sender: camm@wisdom.m.enhanced.com
To: gtk-list@redhat.com
Subject: New projects
References: <Pine.BSF.3.91.970624095825.29138E-100000@blacklodge.c2.net>
From: Camm Maguire <camm@enhanced.com>
Date: 25 Jun 1997 08:45:03 -0400
In-Reply-To: Raph Levien's message of Tue, 24 Jun 1997 10:07:56 -0700 (PDT)
Message-ID: <54soy697hs.fsf@wisdom.m.enhanced.com>
Lines: 17
X-Mailer: Gnus v5.3/Emacs 19.34
Greetings! I am totally new to X-Wiindow programming, but faily
fluent in generic C. I want to write a text indexing/searching
program, and am considering GTK from the positive reports I've heard
thus far and its GPL licensing.
My question: I need some honest advice about whether the man hours
required for me to get up to speed with GTK are justified given the
sparse GTK documentation, the state of flux of the routines, and the
alternate widget sets available.
Can anyone share their thoughts with me here?
Keep up the good work on this project!
--
cmaguire@enhanced.com Camm Maguire
==================================================================
"The earth is one country, and mankind its citizens." Baha'u'llah
From otto@redhat.com
Received: (qmail 15941 invoked from network); 25 Jun 1997 12:56:50 -0000
Received: from nimrod.redhat.com (otto@199.183.24.13)
by mail2.redhat.com with SMTP; 25 Jun 1997 12:56:50 -0000
Received: (from otto@localhost)
by nimrod.redhat.com (8.8.5/8.8.5) id IAA04192;
Wed, 25 Jun 1997 08:56:51 -0400
Message-ID: <19970625085650.31814@redhat.com>
Date: Wed, 25 Jun 1997 08:56:50 -0400
From: Otto Hammersmith <otto@redhat.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] New projects
References: <Pine.BSF.3.91.970624095825.29138E-100000@blacklodge.c2.net>
<54soy697hs.fsf@wisdom.m.enhanced.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.74
In-Reply-To: <54soy697hs.fsf@wisdom.m.enhanced.com>;
from Camm Maguire on Wed, Jun 25, 1997 at 08:45:03AM -0400
On Wed, Jun 25, 1997 at 08:45:03AM -0400, Camm Maguire wrote:
> Greetings! I am totally new to X-Wiindow programming, but faily
> fluent in generic C. I want to write a text indexing/searching
> program, and am considering GTK from the positive reports I've heard
> thus far and its GPL licensing.
>
> My question: I need some honest advice about whether the man hours
> required for me to get up to speed with GTK are justified given the
> sparse GTK documentation, the state of flux of the routines, and the
> alternate widget sets available.
>
> Can anyone share their thoughts with me here?
>
> Keep up the good work on this project!
The time involved isn't really any more than you'd spend getting going
with most X toolkits, despite the lack of documentation. I'd say Qt
is the only one that's comparable, but that's C++ so if you know C
gtk+ is the way to go. (I think it took me about two weeks to get
going with gtk+... longer to start writing new widgets, which I
haven't quite mastered just yet)
Not to mention the amount of money you'd end up spending on books to
lear something like Motif. Very scarry thought. :)
Good luck.
--
-Otto.
From slow@intergate.bc.ca
Received: (qmail 24654 invoked from network); 25 Jun 1997 20:55:59 -0000
Received: from diablo.intergate.bc.ca (root@205.206.192.2)
by mail2.redhat.com with SMTP; 25 Jun 1997 20:55:58 -0000
Received: from slow (imain@pm19s27.intergate.bc.ca [207.34.180.42])
by diablo.intergate.bc.ca (8.8.5/8.6.9) with SMTP id OAA10464;
Wed, 25 Jun 1997 14:09:51 -0700 (PDT)
Date: Wed, 25 Jun 1997 13:54:47 -0700 (PDT)
From: Ian Main <slow@intergate.bc.ca>
X-Sender: imain@slow
To: Camm Maguire <camm@enhanced.com>
cc: gtk-list@redhat.com
Subject: Re: [gtk-list] New projects
In-Reply-To: <54soy697hs.fsf@wisdom.m.enhanced.com>
Message-ID: <Pine.LNX.3.96.970625135002.3307B-100000@slow>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On 25 Jun 1997, Camm Maguire wrote:
> Greetings! I am totally new to X-Wiindow programming, but faily
> fluent in generic C. I want to write a text indexing/searching
> program, and am considering GTK from the positive reports I've heard
> thus far and its GPL licensing.
>
> My question: I need some honest advice about whether the man hours
> required for me to get up to speed with GTK are justified given the
> sparse GTK documentation, the state of flux of the routines, and the
> alternate widget sets available.
>
> Can anyone share their thoughts with me here?
I just started using gtk about hmm.. 3 weeks ago, and can now write a
decent application with it. There's certainly a lack of documentation,
but if you check out the testgtk.c and other examples, it doesn't take
long to figure it out. I find the API easy to grasp, and the header files
very useful too. The gtk source is well organized, so if you have an idea
of the function your after, its not too hard to find.
If your good at C, it shouldn't take too long at all to figure out.
You should be able to make simple applications in a few hours. :)
Hope that helps,
Ian
From ricardo@calvin.net
Received: (qmail 6257 invoked from network); 18 Sep 1997 21:01:34 -0000
Received: from calvin.net (HELO al.calvin.net) (root@199.199.151.53)
by mail2.redhat.com with SMTP; 18 Sep 1997 21:01:34 -0000
Received: from localhost (ricardo@localhost)
by al.calvin.net (8.8.5/8.8.5) with SMTP id JAA19495
for <gtk-list@redhat.com>; Thu, 18 Sep 1997 09:51:41 -0500
Date: Thu, 18 Sep 1997 09:51:41 -0500 (CDT)
From: Ricardo Muggli <ricardo@calvin.net>
To: gtk-list@redhat.com
Subject: GTK-- easy enough for beginners?
Message-ID: <Pine.LNX.3.96.970918093201.19486A-100000@al.calvin.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I am interested in learning to program with GTK but I am more
knowledgeable with c++ than with c. The question I want to raise is if
there is a tutorial on using GTK-- or can I use Ian's with a little
modification. Is there a big difference between GTK+ with C and GTK-- with
C++? This is my first X tool kit I'm trying to learn. Is GTK-- stable and
advanced enough for a beginner X programmer to learn?
thanks for any response and any pointers to info
- ricardo@calvin.net
From landsh19@starnetinc.com
Received: (qmail 12299 invoked from network); 19 Sep 1997 04:25:50 -0000
Received: from email6.starnetinc.com (204.178.185.4)
by mail2.redhat.com with SMTP; 19 Sep 1997 04:25:49 -0000
Received: from landshark (max01-030.starnetinc.com [207.227.180.30])
by email6.starnetinc.com (8.8.5/8.8.2) with ESMTP id XAA11961 for
<gtk-list@redhat.com>; Thu, 18 Sep 1997 23:28:46 -0500 (CDT)
Message-Id: <199709190428.XAA11961@email6.starnetinc.com>
From: "Landshark" <landsh19@starnetinc.com>
To: <gtk-list@redhat.com>
Subject: Re: [gtk-list] GTK-- easy enough for beginners?
Date: Thu, 18 Sep 1997 23:29:36 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1155
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
> I am interested in learning to program with GTK but I am more
> knowledgeable with c++ than with c. The question I want to raise is if
> there is a tutorial on using GTK-- or can I use Ian's with a little
> modification. Is there a big difference between GTK+ with C and GTK--
with
> C++? This is my first X tool kit I'm trying to learn. Is GTK-- stable and
> advanced enough for a beginner X programmer to learn?
I don't have the url since I'm not at my linux box right now, but there is
a page which has a good set of tutorials on many aspects of GTK.
I started out messing around with plain Xlib, which I found to be rather
tedious and puzzling. I then moved over to lesstif, which again, was quite
puzzling. Next I went to QT, which seemed rather nice also. Finally, I
moved to GTK, which I like alot. It's easier to use than most libraries,
and has an ever growing user base which functions as a great learning
resource -- everyone helps everyone along. I don't think it would be
difficult at all for a new X programmer to learn GTK at all.
There is one thing I was wondering. What if any restrictions are put on
programs made with GTK? Can they be made commercial without worry? Must
source code be released? I haven't looked at the docs for it yet
concerning copyright'sh stuff, but I don't wish to worry about
misinterpreting them.
Dave Marotti
landsh19@starnetinc.com
From sopwith@cuc.edu
Received: (qmail 24261 invoked from network); 19 Sep 1997 04:47:42 -0000
Received: from helix.cs.cuc.edu (HELO cuc.edu) (sopwith@204.32.57.128)
by mail2.redhat.com with SMTP; 19 Sep 1997 04:47:42 -0000
Received: from localhost (sopwith@localhost)
by cuc.edu (8.8.5/8.8.5) with SMTP id AAA09896
for <gtk-list@redhat.com>; Fri, 19 Sep 1997 00:47:43 -0400
Date: Fri, 19 Sep 1997 00:47:43 -0400 (EDT)
From: Elliot Lee <sopwith@cuc.edu>
X-Sender: sopwith@helix
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: GTK-- easy enough for beginners?
In-Reply-To: <199709190428.XAA11961@email6.starnetinc.com>
Message-ID: <Pine.LNX.3.95.970919004140.8780A-100000@helix>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Thu, 18 Sep 1997, Landshark wrote:
> There is one thing I was wondering. What if any restrictions are put on
> programs made with GTK? Can they be made commercial without worry?
> Must source code be released? I haven't looked at the docs for it yet
> concerning copyright'sh stuff, but I don't wish to worry about
> misinterpreting them.
Gtk is under the LGPL, which basically says that the library itself must
be free and you must be able to provide the sources for the library...
Gtk source being online is providing, I guess. :) You can use whatever
license you wish on Gtk software you write, and not pay anything.
-- Elliot
#!/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 raph@acm.org
Received: (qmail 22962 invoked from network); 10 Oct 1997 15:46:59 -0000
Received: from callisto.hip.berkeley.edu (136.152.64.218)
by mail2.redhat.com with SMTP; 10 Oct 1997 15:46:59 -0000
Received: (from raph@localhost)
by callisto.hip.berkeley.edu (8.8.4/8.8.4)
id JAA00254 for gtk-list@redhat.com; Fri, 10 Oct 1997 09:10:57 -0700
Date: Fri, 10 Oct 1997 09:10:57 -0700
Message-Id: <199710101610.JAA00254@callisto.hip.berkeley.edu>
From: raph@acm.org
To: gtk-list@redhat.com
Subject: Nits to pick on gtk+960925 (resend)
Hi gtk people,
I've been working to integrate Gzilla with the latest GTK+, and
I've come across a number of problems, mostly what I'd categorize as
nits rather than serious bugs.
1. Pressing Enter in a file selection dialog does nothing.
The Return button handling in gtk_entry has changed. In Gimp
0.99.10, it was not handled in the entry, so it would get passed up to
the window and down to the default action (pressing the Ok button),
but in gtk+970925, it does get handled in gtk_entry and throws an
activate signal.
The fix is simple - in gtkfilesel.c:gtk_file_selection_init, hook
the activate signal (maybe a gtk_signal_connect_object, use
gtk_button_clicked as the handler, and filesel->ok_button as the
object.
2. size_request of a scrolled window is calculated wrong.
Nobody ever uses the value of size_request of a scrolled window
because it's so damn tiny, but the code is wrong. The last assignment
to extra_width should be calculated using scrolled_window->vscrollbar
rather scrolled_window->hscrollbar.
3. expose of viewport is inefficient.
The handling gtk_viewport_expose passes the widget event to the
child even if the expose event is in one of the viewport's own windows
rather than the child window. It's usually not a correctness problem
to expose in a window, but it still feels wrong.
The fix is to do wrap the child even call in an if (event->window
== widget->window) test.
4. Size negotiation is fubar.
I fear that the queued resize stuff may have made things worse. I
felt I understood the size negotiation in 0.99.10 pretty well and was
capable of working around its efficiency problems, but the cure in
970925 may be worse than the disease.
The main problem is that widget lifecycle events can now occur
outside the order established in 0.99.10. Specifically, the widget can
be mapped and realized before it is size allocated. This is
generally an efficiency problem, because the X call sequence includes
making a dummy window during the realize, then moving it into position
during the size allocate, rather than just making it in the right
position. However, in Gzilla it caused some cosmetic problems as well,
because you could see the window move into position.
I'm not sure what the best fix is to this problem. It's ok to leave
it as it is and take the efficiency hit, but that seems to go against
the whole point of the changes to the size negotiation. At the highest
level, I think now would be a very good idea to write down exactly
what the size negotiation methods are supposed to do, what order
they're supposed to happen in, and what invariants are supposed to be
maintained. I think this will help greatly to avoid bugs in size
negotiation, both in the GTK core and for people writing their own
container widgets, especially if there are going to be multiple people
working on it.
To get a little more specific, what I think would work best is to
go back to the stricter order as in 0.99.10, but change the queued
resize code so that it enforces this order. Thus, the queued resize
handler should be responsible for realizing and mapping the widget
after size allocation, assuming the right conditions are met (as I
understand it, that the container and child widget are both visible,
and that the container is realized and mapped). The same code will
probably also be responsible for drawing the child widget if it's
NO_WINDOW. The responsibility to map and realize should be taken out
of container widgets like gtk_box_pack_start (as was correctly the
case in 0.99.10).
However, I've got reasonable workarounds in Gzilla 0.1.2, so it's
not urgent. I just think this will cause more problems down the road
if it's not addressed now. I'm still having problems with the
scrollbars being out of step with the window size, but I can probably
find the problem and fix that too.
On a personal note, I'm out of town for my father's funeral. I was
hoping to do a stable Gzilla release soon, but that may be a while
hence. If anyone wants to hack on the existing Gzilla code, let me
know and I'll post the most recent semistable source tree.
Raph
From raph@acm.org
Received: (qmail 5960 invoked from network); 26 Nov 1997 12:24:32 -0000
Received: from blacklodge.c2.net (208.139.36.35)
by mail2.redhat.com with SMTP; 26 Nov 1997 12:24:32 -0000
Received: (from raph@localhost) by blacklodge.c2.net (8.8.5/8.7.3)
id EAA12090; Wed, 26 Nov 1997 04:38:33 -0800 (PST)
Date: Wed, 26 Nov 1997 04:38:33 -0800 (PST)
From: Raph Levien <raph@acm.org>
X-Sender: raph@blacklodge.c2.net
To: gtk-list@redhat.com
Subject: Gzilla 0.1.4 released
Message-ID: <Pine.BSF.3.91.971126043242.11991A-100000@blacklodge.c2.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi gtk-developers,
I've just put Gzilla 0.1.4 on the www.gzilla.com website. While still
quite unfinished, this release is basically usable.
This release uses the Gzw (Gzilla Widget) set and is able to scroll
windows > 32kpixels with good performance, even when they contain
embedded widgets. As such, the Gzw framework may be interesting to other
Gtk developers. Gzw is not quite finished yet, but the API is pretty close.
Between research deadlines and wanting to spend the holidays with my
family, I'm not going to get much time to work on the code for a few
weeks. If anyone else wants to bang on the code, now is your chance :).
Raph
From ondrej@idata.sk
Received: (qmail 27630 invoked from network); 17 Feb 1998 15:47:14 -0000
Received: from amber.idata.sk (mail@194.196.155.141)
by mail2.redhat.com with SMTP; 17 Feb 1998 15:47:14 -0000
Received: (from mail@localhost)
by amber.idata.sk (8.8.5/8.8.5) id QAA24922
for <gtk-list@redhat.com>; Tue, 17 Feb 1998 16:46:45 +0100
Received: from corwin.idata.sk(194.196.155.142) by amber.idata.sk via smap (V2.0)
id xma024920; Tue, 17 Feb 98 16:46:23 +0100
Received: from localhost by idata.sk; (5.65v3.2/1.1.8.2/02Dec96-0635PM)
id AA06025; Tue, 17 Feb 1998 16:52:40 +0100
Date: Tue, 17 Feb 1998 16:52:40 +0100 (MET)
From: Ondrejicka Stefan <ondrej@idata.sk>
To: gtk-list@redhat.com
Subject: GtkCalendar widget
Message-Id: <Pine.OSF.3.95.980217164943.6202B-100000@axp.idata.sk>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi all,
I yesterday rewrote my old Xtoolkit Calendar widget to Gtk.
If you want to use it, grab it from my homepage.
Bye,
Stevo.
---
Ondrejicka Stefan <ondrej@idata.sk>
http://www.idata.sk/~ondrej/
From amundson@CompleteIS.com
Received: (qmail 5280 invoked from network); 18 Feb 1998 05:15:20 -0000
Received: from q.completeis.com (206.144.247.110)
by mail2.redhat.com with SMTP; 18 Feb 1998 05:15:20 -0000
Received: from localhost (amundson@localhost)
by q.CompleteIS.com (8.8.8/8.8.8) with SMTP id XAA05420
for <gtk-list@redhat.com>; Tue, 17 Feb 1998 23:15:13 -0600 (CST)
X-Authentication-Warning: q.CompleteIS.com: amundson owned process doing -bs
Date: Tue, 17 Feb 1998 23:15:12 -0600 (CST)
From: "Shawn T. Amundson" <amundson@CompleteIS.com>
X-Sender: amundson@q
To: gtk-list@redhat.com
Subject: Re: [gtk-list] GtkCalendar widget
In-Reply-To: <Pine.OSF.3.95.980217164943.6202B-100000@axp.idata.sk>
Message-ID: <Pine.GSO.3.96.980217215009.5415A-100000@q>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 17 Feb 1998, Ondrejicka Stefan wrote:
> Hi all,
>
> I yesterday rewrote my old Xtoolkit Calendar widget to Gtk.
> If you want to use it, grab it from my homepage.
>
> Bye,
> Stevo.
>
This makes the third GtkCalendar widget. Mine was first about
a year ago, and admittably it was one super-hack and sucked.
Cesar Miquel and I are working on one now; we started this one
with his code base, and I've put some of the code from mine
into it for the date calculation code and reworked portions
to make it layout better.
Ours doesn't quite work fully yet, but promises much more in
the way of flexibility. We have an initial screenshot up
at http://www.gimp.org/~amundson/aorta/calendar-3.gif. It is
by no means finished. This is just an initial version screenshot,
the cool ones are on their way soon.
We have recently gotton permission to use C portions from the
perl DateCalc module under the LGPL (hurray!), which claims
date calculations complying with ISO/R 2015-1917 and DIN 1355
standards (don't ask me, that's why I'm using his stuff).
This is important because of things years such as 2100 not leap
years, etc. (year divisible by 100 is not a leap year unless
it is also divisible by 400) ;-)
Right now we have the following defined in our .h file (minus
obvious other widget stuff):
typedef enum
{
GTK_CALENDAR_SHOW_MONTH_HEADING = 1 << 0,
GTK_CALENDAR_SHOW_WEEKDAY_HEADING = 1 << 1,
} GtkCalendarDisplayOptions;
typedef enum
{
GTK_CALENDAR_FONT_HEADING,
GTK_CALENDAR_FONT_DAY_NAME,
GTK_CALENDAR_FONT_DAY
} GtkCalendarFont;
typedef enum
{
GTK_CALENDAR_COLOR_HEADING,
GTK_CALENDAR_COLOR_DAY_NAME,
GTK_CALENDAR_COLOR_PREV_MONTH,
GTK_CALENDAR_COLOR_NEXT_MONTH,
GTK_CALENDAR_COLOR_NORMAL_DAY
} GtkCalendarColor;
guint gtk_calendar_get_type (void);
GtkWidget* gtk_calendar_new (void);
void gtk_calendar_select_month (GtkCalendar *calendar,
gint year, gint month);
void gtk_calendar_select_day (GtkCalendar *calendar, gint day);
void gtk_calendar_mark_day (GtkCalendar *calendar, gint day);
void gtk_calendar_unmark_day (GtkCalendar *calendar, gint day);
void gtk_calendar_clear_marks (GtkCalendar *calendar);
void gtk_calendar_set_font (GtkCalendar *calendar,
GtkCalendarFont type,
GdkFont *font);
void gtk_calendar_set_color (GtkCalendar *calendar,
GtkCalendarColor type,
GdkColor *color);
void gtk_calendar_display_options (GtkCalendar *calendar,
gint flags);
Suggestions welcome on the coding interface. We need at minimum
to add support for changing the day of week and month strings.
It was suggested we allow making all weekend days seperately marked
with their own color. (Add GTK_CALENDAR_COLOR_WEEKEND_DAY or similar.)
I am toying with the idea of allowing setting pixmaps for some days via
some method so that things like birthdays can have an image of a cake,
etc. (This may be needed for gncal I think.)
Also, perhaps expanding it to allow easy creation of a calendar like
in plan, where the calendar is quite large and can contain text in the
day boxes would be very useful. (Also potentally usable by gncal.)
--
Shawn T. Amundson
amundson@gimp.org
while (i) { last }
i, do exist.
forever;
From nexus@tatoosh.com
Received: (qmail 29673 invoked from network); 22 Feb 1998 18:15:36 -0000
Received: from dialups-83.gig-dial2.ptinet.net (HELO tatoosh.com)
(root@208.157.242.83)
by mail2.redhat.com with SMTP; 22 Feb 1998 18:15:36 -0000
Received: from kermit.tatoosh.com (nexus@kermit.tatoosh.com [192.168.100.3])
by tatoosh.com (8.8.5/8.8.5) with SMTP id KAA09395
for <gtk-list@redhat.com>; Sun, 22 Feb 1998 10:01:53 -0800
Date: Sun, 22 Feb 1998 09:56:10 -0800 (PST)
From: "Brian C. Lane" <nexus@tatoosh.com>
To: gtk-list@redhat.com
Subject: multi-tasking
Message-ID: <Pine.LNX.3.96.980222095116.10267A-100000@kermit.tatoosh.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hello,
I'm new to GTK+ so I apologize if this is covered somewhere. I've
written a cd player control panel and it works, mostly. The problem I'm
having is that when the play, FF and REW buttons are pressed I set the
button's pixmap to its down image and then call the appropriate cdrom
routine.
The problem is that the new pixmap doesn't get drawn until after the
cdrom routine is done and the button press event for the button is exited.
Most of the time the down image doesn't show up at all because you've
already released the mouse button by the time it is done switching to the
next track.
Does anyone have a good solution for this? Someone should, since its
important to have a good user interface and still be able to interact with
real-world devices.
One though I had was maybe starting a timer when the key is pressed and
doing the actual cdrom command when the timer goes off (after, say 100mS).
Any better ideas?
Brian
(BTW, you can see a sample screenshot in the linux software section of
my webpage).
======================================================================
Nexus Computing http://www.eskimo.com/~nexus
Electronics, Embedded Software and Linux nexus@tatoosh.com
From owt1@cornell.edu
Received: (qmail 23993 invoked from network); 22 Feb 1998 19:20:59 -0000
Received: from cu-dialup-0411.cit.cornell.edu (mail@132.236.236.199)
by mail2.redhat.com with SMTP; 22 Feb 1998 19:20:59 -0000
Received: from otaylor by cu-dialup-0411.cit.cornell.edu with local (Exim 1.82 #1)
id 0y6gzj-0003hX-00; Sun, 22 Feb 1998 14:23:23 -0500
To: "Brian C. Lane" <nexus@tatoosh.com>
Cc: gtk-list@redhat.com
Subject: Re: multi-tasking
References: <Pine.LNX.3.96.980222095116.10267A-100000@kermit.tatoosh.com>
From: Owen Taylor <owt1@cornell.edu>
Date: 22 Feb 1998 14:23:23 -0500
In-Reply-To: "Brian C. Lane"'s message of Sun, 22 Feb 1998 09:56:10 -0800 (PST)
Message-ID: <lzzpjj78b8.fsf@cu-dialup-0411.cit.cornell.edu>
Lines: 44
X-Mailer: Gnus v5.5/Emacs 20.2
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?=
=?ISO-8859-4?Q?h=F2ji"?=)
Content-Type: text/plain; charset=US-ASCII
"Brian C. Lane" <nexus@tatoosh.com> writes:
> I'm new to GTK+ so I apologize if this is covered somewhere. I've
> written a cd player control panel and it works, mostly. The problem I'm
> having is that when the play, FF and REW buttons are pressed I set the
> button's pixmap to its down image and then call the appropriate cdrom
> routine.
>
> The problem is that the new pixmap doesn't get drawn until after the
> cdrom routine is done and the button press event for the button is exited.
> Most of the time the down image doesn't show up at all because you've
> already released the mouse button by the time it is done switching to the
> next track.
Well, you should most likely actually be only setting the down
pixmap in the "button_press_event" callback. The actual triggering
should be on the "clicked" event. (Try fooling around some with
how a button triggers) If you unset your pixmap in the
"button_release_event", then that won't be displayed until your
command finishes, but that may be the right effect.
But as of 0.99.4, you should be able to say, in the beginning
of your "clicked" routine:
while (gtk_events_pending())
gtk_main_iteration();
And everything will be redrawn, if that's what you want.
> Does anyone have a good solution for this? Someone should, since its
> important to have a good user interface and still be able to interact with
> real-world devices.
>
> One though I had was maybe starting a timer when the key is pressed and
> doing the actual cdrom command when the timer goes off (after, say 100mS).
If you actually _want_ a button that triggers when the thing is
pressed. (Say you are implementing the typical CD "scan through
track when >> is held down") then this might be a good thing to do -
you can get autorepeat behavior in the bargain.
Hope this helps,
Owen
From nexus@tatoosh.com
Received: (qmail 8749 invoked from network); 23 Feb 1998 02:15:38 -0000
Received: from dialups-44.gig-dial1.ptinet.net (HELO tatoosh.com)
(root@208.157.242.44)
by mail2.redhat.com with SMTP; 23 Feb 1998 02:15:38 -0000
Received: from kermit.tatoosh.com (nexus@kermit.tatoosh.com [192.168.100.3])
by tatoosh.com (8.8.5/8.8.5) with SMTP id RAA21538
for <gtk-list@redhat.com>; Sun, 22 Feb 1998 17:45:23 -0800
Date: Sun, 22 Feb 1998 17:39:43 -0800 (PST)
From: "Brian C. Lane" <nexus@tatoosh.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: multi-tasking
In-Reply-To: <lzzpjj78b8.fsf@cu-dialup-0411.cit.cornell.edu>
Message-ID: <Pine.LNX.3.96.980222173336.11901A-100000@kermit.tatoosh.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On 22 Feb 1998, Owen Taylor wrote:
> Well, you should most likely actually be only setting the down
> pixmap in the "button_press_event" callback. The actual triggering
> should be on the "clicked" event. (Try fooling around some with
> how a button triggers) If you unset your pixmap in the
> "button_release_event", then that won't be displayed until your
> command finishes, but that may be the right effect.
Well, I was using a EventBox for each of the buttons, but apparently it
doesn't have a "clicked" event, so I've switched back to a button. The
reason I wasn't using a button is the border that is placed around the
pixmap -- is there a way to turn this off in butons?
Now I have a problem where it sigsegv's on me when I press the button.
It is related to the clicked event because I have tried removing all other
events related to the button, also it isn't the clicked routine being
called because the routine is successfully called when attached to a
pressed or unpressed event! The other event, when on, all work.
Does this sound like a bug or am I doing something else wrong? I'm using
GTK+ v0.99.3
>
> But as of 0.99.4, you should be able to say, in the beginning
> of your "clicked" routine:
>
> while (gtk_events_pending())
> gtk_main_iteration();
It looks like using the "clicked" event, when I can get it to work, it a
cleaner way of doing it.
> If you actually _want_ a button that triggers when the thing is
> pressed. (Say you are implementing the typical CD "scan through
> track when >> is held down") then this might be a good thing to do -
> you can get autorepeat behavior in the bargain.
That sounds like a good idea, I'd have to fake the advancement until the
mouse is released (moving to the next track takes about a second for some
reason), but that could be a pretty cool feature.
Brian
======================================================================
Nexus Computing http://www.eskimo.com/~nexus
Electronics, Embedded Software and Linux nexus@tatoosh.com
From nexus@tatoosh.com
Received: (qmail 15448 invoked from network); 23 Feb 1998 08:15:43 -0000
Received: from dialups-64.gig-dial2.ptinet.net (HELO tatoosh.com)
(root@208.157.242.64)
by mail2.redhat.com with SMTP; 23 Feb 1998 08:15:43 -0000
Received: from kermit.tatoosh.com (nexus@kermit.tatoosh.com [192.168.100.3])
by tatoosh.com (8.8.5/8.8.5) with SMTP id XAA30358
for <gtk-list@redhat.com>; Sun, 22 Feb 1998 23:40:00 -0800
Date: Sun, 22 Feb 1998 23:34:21 -0800 (PST)
From: "Brian C. Lane" <nexus@tatoosh.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: multi-tasking
In-Reply-To: <Pine.LNX.3.96.980222173336.11901A-100000@kermit.tatoosh.com>
Message-ID: <Pine.LNX.3.96.980222232951.12444A-100000@kermit.tatoosh.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 22 Feb 1998, Brian C. Lane wrote:
> reason I wasn't using a button is the border that is placed around the
> pixmap -- is there a way to turn this off in butons?
I still have the above question, but...
>
> Now I have a problem where it sigsegv's on me when I press the button.
> It is related to the clicked event because I have tried removing all other
> Does this sound like a bug or am I doing something else wrong? I'm using
> GTK+ v0.99.3
I was trying to call a click callback with (GtkWidget *, GdkEvent *), so
I fixed that, and passed it the Widget* when connecting the clicked event.
But now that brings up another question, how do I tell which mouse button
was clicked to activate it? I have a volume button that increases the
volume with a left click and decreases it with a right click.
Also, now my down image is drawn before executing the cdrom function,
but it isn't drawn as back up until it completes, even though my debugging
output shows that it is getting press_event, release_event, click_event.
Apparently the image isn't being redrawn between the release event (where
the image is changed back to the up image) and the click event.
Maybe I am really better off starting a timer when it is hit and letting
that handle the processing...
Thanks!
Brian
======================================================================
Nexus Computing http://www.eskimo.com/~nexus
Electronics, Embedded Software and Linux nexus@tatoosh.com
From owt1@cornell.edu
Received: (qmail 5125 invoked from network); 23 Feb 1998 15:32:22 -0000
Received: from cu-dialup-0820.cit.cornell.edu (mail@132.236.155.66)
by mail2.redhat.com with SMTP; 23 Feb 1998 15:32:22 -0000
Received: from otaylor by cu-dialup-0820.cit.cornell.edu with local (Exim 1.82 #1)
id 0y6zts-0006Fe-00; Mon, 23 Feb 1998 10:34:36 -0500
To: gtk-list@redhat.com
Subject: Re: multi-tasking
References: <Pine.LNX.3.96.980222232951.12444A-100000@kermit.tatoosh.com>
From: Owen Taylor <owt1@cornell.edu>
Date: 23 Feb 1998 10:34:36 -0500
In-Reply-To: "Brian C. Lane"'s message of Sun, 22 Feb 1998 23:34:21 -0800 (PST)
Message-ID: <lzk9am72sz.fsf@cu-dialup-0411.cit.cornell.edu>
Lines: 56
X-Mailer: Gnus v5.5/Emacs 20.2
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?=
=?ISO-8859-4?Q?h=F2ji"?=)
Content-Type: text/plain; charset=US-ASCII
"Brian C. Lane" <nexus@tatoosh.com> writes:
> On Sun, 22 Feb 1998, Brian C. Lane wrote:
>
> > reason I wasn't using a button is the border that is placed around the
> > pixmap -- is there a way to turn this off in butons?
No. (It will be part of the themeability support, but not now)
> I still have the above question, but...
>
> >
> > Now I have a problem where it sigsegv's on me when I press the button.
> > It is related to the clicked event because I have tried removing all other
> > Does this sound like a bug or am I doing something else wrong? I'm using
> > GTK+ v0.99.3
>
> I was trying to call a click callback with (GtkWidget *, GdkEvent *), so
> I fixed that, and passed it the Widget* when connecting the clicked event.
> But now that brings up another question, how do I tell which mouse button
> was clicked to activate it? I have a volume button that increases the
> volume with a left click and decreases it with a right click.
You can't. If you really want that kind of control, you'll have to
go back to the EventBox. It shouldn't be too hard to even duplicate
the way buttons work. (The event triggers on the release, but only
if the pointer is within widget->allocation)
But have some pity on the user. Why not just make the volume control
a scale?
> Also, now my down image is drawn before executing the cdrom function,
> but it isn't drawn as back up until it completes, even though my debugging
> output shows that it is getting press_event, release_event, click_event.
> Apparently the image isn't being redrawn between the release event (where
> the image is changed back to the up image) and the click event.
True. It is just getting queued for redraw. In 0.99.4 you will be able to
fix that by doing the:
while (gtk_events_pending())
gtk_main_iteration();
thing, before going off and doing your long operation. But there is an
even easier way, that I didn't think of mentioning earlier: just call:
gtk_widget_draw (button, NULL);
Which will make the button be redrawn immediately. It has the
downside that the button will later be drawn again, from the queued
idle redraw, but that shouldn't be noticeable.
Regards,
Owen
From nexus@tatoosh.com
Received: (qmail 7460 invoked from network); 24 Feb 1998 02:17:25 -0000
Received: from dialups-39.gig-dial1.ptinet.net (HELO tatoosh.com)
(root@208.157.242.39)
by mail2.redhat.com with SMTP; 24 Feb 1998 02:17:25 -0000
Received: from kermit.tatoosh.com (nexus@kermit.tatoosh.com [192.168.100.3])
by tatoosh.com (8.8.5/8.8.5) with SMTP id RAA24829
for <gtk-list@redhat.com>; Mon, 23 Feb 1998 17:38:05 -0800
Date: Mon, 23 Feb 1998 17:32:40 -0800 (PST)
From: "Brian C. Lane" <nexus@tatoosh.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: multi-tasking
In-Reply-To: <lzk9am72sz.fsf@cu-dialup-0411.cit.cornell.edu>
Message-ID: <Pine.LNX.3.96.980223173016.13439A-100000@kermit.tatoosh.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On 23 Feb 1998, Owen Taylor wrote:
> No. (It will be part of the themeability support, but not now)
Thanks, that's what I groked from the code. I've switched back to an
eventBox.
> But have some pity on the user. Why not just make the volume control
> a scale?
No space for a slider, I'm trying to keep it as compact as possible
(actually it is a slight variation on freeCD for win95, using his
pixmaps).
> True. It is just getting queued for redraw. In 0.99.4 you will be able to
> fix that by doing the:
>
> while (gtk_events_pending())
> gtk_main_iteration();
I'll switch to that when 0.99.4 is released I guess.
>
> thing, before going off and doing your long operation. But there is an
> even easier way, that I didn't think of mentioning earlier: just call:
>
> gtk_widget_draw (button, NULL);
>
Ah! I knew there had to be a call like that. Thanks!
Brian
======================================================================
Nexus Computing http://www.eskimo.com/~nexus
Electronics, Embedded Software and Linux nexus@tatoosh.com
From nexus@tatoosh.com
Received: (qmail 23083 invoked from network); 25 Feb 1998 05:08:52 -0000
Received: from dialups-57.gig-dial2.ptinet.net (HELO tatoosh.com)
(root@208.157.242.57)
by mail2.redhat.com with SMTP; 25 Feb 1998 05:08:52 -0000
Received: from kermit.tatoosh.com (nexus@kermit.tatoosh.com [192.168.100.3])
by tatoosh.com (8.8.5/8.8.5) with SMTP id UAA01788;
Tue, 24 Feb 1998 20:59:40 -0800
Date: Tue, 24 Feb 1998 20:54:13 -0800 (PST)
From: "Brian C. Lane" <nexus@tatoosh.com>
To: linux-announce@news.ornl.gov
Subject: XfreeCD v0.5 (beta) release
Message-ID: <Pine.LNX.3.96.980224205135.15612A-100000@kermit.tatoosh.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
XfreeCD is a Xwindows CD player written using GTK+ v.99.3
This beta release is working perfectly for me, so its time to
release it to the world and watch it crash and burn <G>. It is available
from the Linux Software section of my webpage at:
http://www.eskimo.com/~nexus
Any and all feedback is welcome!
Brian
======================================================================
Nexus Computing http://www.eskimo.com/~nexus
Electronics, Embedded Software and Linux nexus@tatoosh.com
From timg@means.net
Received: (qmail 13742 invoked from network); 2 Mar 1998 16:34:28 -0000
Received: from halstad-59.dialup.means.net (HELO Camille) (timg@206.10.30.64)
by mail2.redhat.com with SMTP; 2 Mar 1998 16:34:28 -0000
Received: from timg by Camille with local (Exim 1.58 #1)
id 0y9YC8-0000tu-00; Mon, 2 Mar 1998 10:36:00 -0600
Message-ID: <19980302103600.52848@Camille.gerla.org>
Date: Mon, 2 Mar 1998 10:36:00 -0600
From: "Tim P. Gerla" <timg@means.net>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: multi-tasking
References: <lzk9am72sz.fsf@cu-dialup-0411.cit.cornell.edu>
<Pine.LNX.3.96.980223173016.13439A-100000@kermit.tatoosh.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.81
In-Reply-To: <Pine.LNX.3.96.980223173016.13439A-100000@kermit.tatoosh.com>;
from Brian C. Lane on Mon, Feb 23, 1998 at 05:32:40PM -0800
Sender: RHS Linux User <timg@Camille>
On Mon, Feb 23, 1998 at 05:32:40PM -0800, Brian C. Lane wrote:
>
> > True. It is just getting queued for redraw. In 0.99.4 you will be able to
> > fix that by doing the:
> >
> > while (gtk_events_pending())
> > gtk_main_iteration();
>
Saw this a while back...I was wondering if it would be safe to put this in a
timeout? Thanks.
--
-Tim
timg@means.net | http://flow.ml.org/
From owt1@cornell.edu
Received: (qmail 12120 invoked from network); 2 Mar 1998 17:28:52 -0000
Received: from cu-dialup-0910.cit.cornell.edu (mail@132.236.155.88)
by mail2.redhat.com with SMTP; 2 Mar 1998 17:28:52 -0000
Received: from otaylor by cu-dialup-0910.cit.cornell.edu with local (Exim 1.82 #1)
id 0y9Z35-0001SO-00; Mon, 2 Mar 1998 12:30:43 -0500
To: "Tim P. Gerla" <timg@means.net>
Cc: gtk-list@redhat.com
Subject: Re: multi-tasking
References: <19980302103600.52848@Camille.gerla.org>
From: Owen Taylor <owt1@cornell.edu>
Date: 02 Mar 1998 12:30:42 -0500
In-Reply-To: "Tim P. Gerla"'s message of Mon, 2 Mar 1998 10:36:00 -0600
Message-ID: <lz3eh1vw3h.fsf@cu-dialup-0910.cit.cornell.edu>
Lines: 16
X-Mailer: Gnus v5.5/Emacs 20.2
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?=
=?ISO-8859-4?Q?h=F2ji"?=)
Content-Type: text/plain; charset=US-ASCII
"Tim P. Gerla" <timg@means.net> writes:
> On Mon, Feb 23, 1998 at 05:32:40PM -0800, Brian C. Lane wrote:
> >
> > > True. It is just getting queued for redraw. In 0.99.4 you will be able to
> > > fix that by doing the:
> > >
> > > while (gtk_events_pending())
> > > gtk_main_iteration();
> >
> Saw this a while back...I was wondering if it would be safe to put this in a
> timeout? Thanks.
Yep.
Owen
From petm@scam.XCF.Berkeley.EDU
Received: (qmail 27695 invoked from network); 12 Mar 1998 23:27:52 -0000
Received: from scam.xcf.berkeley.edu (HELO xcf.berkeley.edu) (128.32.43.201)
by mail2.redhat.com with SMTP; 12 Mar 1998 23:27:52 -0000
Received: (qmail 16505 invoked from network); 12 Mar 1998 23:15:58 -0000
Received: from localhost (127.0.0.1)
by localhost with SMTP; 12 Mar 1998 23:15:58 -0000
To: gtk-list@redhat.com
Date: Thu, 12 Mar 1998 15:15:57 -0800
From: Peter Mattis <petm@scam.XCF.Berkeley.EDU>
------- Forwarded Message
>From rdutt@voxel.net Thu Mar 12 09:58:31 1998
Return-Path: <rdutt@voxel.net>
Delivered-To: petm@xcf.berkeley.edu
Received: (qmail 26490 invoked from network); 12 Mar 1998 09:58:29 -0000
Received: from zinc.singnet.com.sg (165.21.7.31)
by scam.xcf.berkeley.edu with SMTP; 12 Mar 1998 09:58:29 -0000
Received: from voxel.net (root@ts900-5614.singnet.com.sg [165.21.161.98])
by zinc.singnet.com.sg (8.8.7/8.8.7) with ESMTP id SAA01799;
Thu, 12 Mar 1998 18:10:17 +0800 (SGT)
Sender: root@zinc.singnet.com.sg
Message-ID: <3507B434.13728219@voxel.net>
Date: Thu, 12 Mar 1998 10:08:52 +0000
From: rdutt <rdutt@voxel.net>
X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.33 i686)
MIME-Version: 1.0
To: petm@xcf.berkeley.edu, spencer@xcf.berkeley.edu, jmacd@xcf.berkeley.edu
Subject: gtk funding
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
gentlemen:
my company (voxel systems - http://www.voxel.net) has recently set
aside a limited amount of money (very limited at this point since we are
a small startup) to help worthy linux projects.
we feel that gtk can be classified as one of these 'worthy' projects,
as it has shown phenomenal growth in the past few months and an amazing
speed of development.
we are currently thinking of something along the lines of registering a
domain name, providing some PC parts for needy core developers. as you
can see, we are talking about hundreds rather than thousands of dollars
per project. if you are interested, please contact me.
best regards,
raj dutt
rdutt@voxel.net
http://www.voxel.net
------- End of Forwarded Message
From rdutt@voxel.net
Received: (qmail 3346 invoked from network); 15 Mar 1998 09:42:23 -0000
Received: from copper.singnet.com.sg (165.21.7.30)
by mail2.redhat.com with SMTP; 15 Mar 1998 09:42:23 -0000
Received: from vx1.voxel (root@ts900-14124.singnet.com.sg [165.21.182.140])
by copper.singnet.com.sg (8.8.7/8.8.7) with SMTP id RAA00513
for gtk-list@redhat.com; Sun, 15 Mar 1998 17:42:19 +0800 (SGT)
Date: Sun, 15 Mar 1998 17:42:19 +0800 (SGT)
Message-Id: <199803150942.RAA00513@copper.singnet.com.sg>
From: Raj Dutt <rdutt@voxel.net>
To: gtk-list@redhat.com
Subject: gtk_statusbar_new
X-Mailer: XCmail 0.12.4 - with PGP support, PGP engine version 0.5
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
hello,
i am trying to hack together a gtk ftp client.. and i am having some trouble
with gtk, since it is my first time really using it. i have a few questions
that i'd be most greatful for answers :
-1- for the progress bar widget, shouldn't it update itself as soon as you
set the percentage that it is at? why does it wait and put itself in a draw
qeue (i think this is what it is doing)
-2- is the tutorial outdated or am i doing something wrong? i can't seem to
get anywhere with gtk_statusbar_new.. has the function name changed or are
statusbars implemented in a different way?
-3- what are the pros/cons/differences between list and clist. which one
would be better for a scrollable list of files with date,time,size. more
importantly, which one would be better if i need to implement multiple file
selecting (multiple list item tagging)
-4- someone said that are going to be no more architectural changes to gtk
for 1.0 (he said that there have been no signficant changes since .99.4). is
this true?
-5- is there any reason why the panes widget implementation is the way it is?
why can you only change the pane area with that one little square? is it
only because we are trying to implement the ugliest widget set in history
(MOTIF). I think it is a better idea if you can drag panes anywhere along the
borders. this is the way it is done in Windows and Amiga. It makes better
sense. If this has already been brought up, apologies for repetition ; if
not, consider it a proposal. I can see no reason why it should not be this
way.
-6- Speaking of interfaces, I would highly suggest using the IRIX (?) style
scrollbars (with both up and down buttons on the bottom).. this really is a
timesaver once you get used to it. Would this be taken care of through the
planed themes api or should this be discussed atm?
tia for any responses. i appreciate it.
-raj
From rdutt@voxel.net
Received: (qmail 26586 invoked from network); 16 Mar 1998 11:36:06 -0000
Received: from copper.singnet.com.sg (165.21.7.30)
by mail2.redhat.com with SMTP; 16 Mar 1998 11:36:06 -0000
Received: from vx1.voxel (root@ts900-6001.singnet.com.sg [165.21.162.85])
by copper.singnet.com.sg (8.8.7/8.8.7) with SMTP id TAA21769
for gtk-list@redhat.com; Mon, 16 Mar 1998 19:36:02 +0800 (SGT)
Date: Mon, 16 Mar 1998 19:36:02 +0800 (SGT)
Message-Id: <199803161136.TAA21769@copper.singnet.com.sg>
From: Raj Dutt <rdutt@voxel.net>
To: gtk-list@redhat.com
Subject: interface questions/proposals
X-Mailer: XCmail 0.12.4 - with PGP support, PGP engine version 0.5
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
i mentioned this before, but it was hidden in the midst of other questions
and a really bad topic sentence :)
i am really impressed with both the quality and the look of the gtk widget
set.. but there are three issues that really bug me. these are not at all
architectural changes so they wont break anything :)
firstly, the panes implementation. currently, the user can only change the
size of the panes by a small rectangular box placed at the bottom corner of
the pane. This is the way it is done in Motif, but i see no reason why it
should be implemented this way in gtk. i propose that the pane widget be
modified so that size control can be done from any pane boundary..
secondly, the scrollbars. Right now, they are implemented ala
windows95/motif/MacOS.. which is probably the most intuitive for most users.
However, i must take this oppurtunity to propose the alternative style (that
i have seen on some IRIX systems i believe) where the scroll buttons are on
the bottom.. this may take some getting used to but is really a timesaver. i
think that the mainstream can easily adapt and will eventually be pleased..
ps - (just one question =]) - there was some discussion on this list about
the way that progress bar was updated. some feel that the progress bar should
be updated instantly (ie non queued updating) is this being considered atm?
thanks,
nopzor
From roba@dcs.ed.ac.uk
Received: (qmail 2593 invoked from network); 16 Mar 1998 11:53:14 -0000
Received: from muck.dcs.ed.ac.uk (root@129.215.160.15)
by mail2.redhat.com with SMTP; 16 Mar 1998 11:53:14 -0000
Received: from canna.dcs.ed.ac.uk (root@canna.dcs.ed.ac.uk [129.215.216.106])
by muck.dcs.ed.ac.uk with SMTP id LAA27676
for <gtk-list@redhat.com>; Mon, 16 Mar 1998 11:52:33 GMT
Message-Id: <14987.199803161152@canna.dcs.ed.ac.uk>
Received: from dcs.ed.ac.uk by canna.dcs.ed.ac.uk; Mon, 16 Mar 1998 11:52:32 GMT
X-Mailer: exmh version 2.0.1 12/23/97
To: gtk-list@redhat.com
Subject: Re: [gtk-list] interface questions/proposals
In-reply-to: rdutt's message of Mon, 16 Mar 1998 19:36:02 +0800.
<199803161136.TAA21769@copper.singnet.com.sg>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Mon, 16 Mar 1998 11:52:31 +0000
From: Robert Atkey <roba@dcs.ed.ac.uk>
Raj Dutt <rdutt@voxel.net> wrote:
> secondly, the scrollbars. Right now, they are implemented ala
> windows95/motif/MacOS.. which is probably the most intuitive for most u=
sers.
> However, i must take this oppurtunity to propose the alternative style =
(that
> i have seen on some IRIX systems i believe) where the scroll buttons ar=
e on
> the bottom.. this may take some getting used to but is really a timesav=
er. i
> think that the mainstream can easily adapt and will eventually be pleas=
ed..
What if the buttons were left where they are and a right click on the but=
ton =
reversed the direction (as on Acorn RISC OS machines). This would keep th=
e =
same interface that users are used to and add functionality.
Bob
From rdutt@voxel.net
Received: (qmail 4405 invoked from network); 16 Mar 1998 14:17:27 -0000
Received: from copper.singnet.com.sg (165.21.7.30)
by mail2.redhat.com with SMTP; 16 Mar 1998 14:17:27 -0000
Received: from vx1.voxel (root@ts900-4108.singnet.com.sg [165.21.153.124])
by copper.singnet.com.sg (8.8.7/8.8.7) with SMTP id WAA18685;
Mon, 16 Mar 1998 22:17:12 +0800 (SGT)
Date: Mon, 16 Mar 1998 22:17:12 +0800 (SGT)
Message-Id: <199803161417.WAA18685@copper.singnet.com.sg>
From: Raj Dutt <rdutt@voxel.net>
To: gtk-list@redhat.com
Cc: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: interface questions/proposals
In-Reply-To: <14987.199803161152@canna.dcs.ed.ac.uk>
X-Mailer: XCmail 0.12.4 - with PGP support, PGP engine version 0.5
X-Mailerorigin: http://www.fsai.fh-trier.de/~schmitzj/Xclasses/XCmail/
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
---Reply on mail from Robert Atkey about [gtk-list]
Re: interface questions/proposals
>
> What if the buttons were left where they are and a right click on the button
> reversed the direction (as on Acorn RISC OS machines). This would keep the
> same interface that users are used to and add functionality.
>
> Bob
>
that sounds like a very interesting and good compromise. makes alot of sense
interface wise speaking. i was thinking, could the themes api also control
such attributes such as the look of the scrollbar down to the point of
placement of buttons?
--raj
From raster@redhat.com
Received: (qmail 12169 invoked from network); 16 Mar 1998 15:05:43 -0000
Received: from lacrosse.redhat.com (root@207.175.42.154)
by mail2.redhat.com with SMTP; 16 Mar 1998 15:05:43 -0000
Received: from trode.redhat.com (root@trode.redhat.com [199.183.24.80])
by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id KAA13157;
Mon, 16 Mar 1998 10:05:37 -0500
Received: from redhat.com (raster@trode [127.0.0.1])
by trode.redhat.com (8.8.7/8.8.7) with ESMTP id KAA17563;
Mon, 16 Mar 1998 10:02:43 -0500
From: raster@redhat.com
Message-Id: <199803161502.KAA17563@trode.redhat.com>
Date: Mon, 16 Mar 1998 10:02:39 -0500 (EST)
Reply-To: raster@redhat.com
Subject: Re: [gtk-list] interface questions/proposals
To: gtk-list@redhat.com
cc: rdutt@voxel.net
In-Reply-To: <199803161136.TAA21769@copper.singnet.com.sg>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
On 16 Mar, Raj Dutt shouted:
->
-> secondly, the scrollbars. Right now, they are implemented ala
-> windows95/motif/MacOS.. which is probably the most intuitive for most users.
-> However, i must take this oppurtunity to propose the alternative style (that
-> i have seen on some IRIX systems i believe) where the scroll buttons are on
-> the bottom.. this may take some getting used to but is really a timesaver. i
-> think that the mainstream can easily adapt and will eventually be pleased..
even though what you say is true (the Amiga implimented arrows this way
too) - it is much more usable - this is somehting to be left upt to
themes to eventually impliment so the user can eventually choose the
style they want/prefer and we can all stop arguing which way is better
because al ways are correct - just some are more correct for some users
than others.
-> ps - (just one question ÿ - there was some discussion on this list about
-> the way that progress bar was updated. some feel that the progress bar should
-> be updated instantly (ie non queued updating) is this being considered atm?
->
-> thanks,
-> nopzor
->
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com /\___ /\ ___/||\___ ____/|/\___ raster@redhat.com
Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
+1 (919) 929 9443, 801 4392 For pure Enlightenmenthttp://www.rasterman.com/
From raster@redhat.com
Received: (qmail 19407 invoked from network); 16 Mar 1998 15:09:03 -0000
Received: from lacrosse.redhat.com (root@207.175.42.154)
by mail2.redhat.com with SMTP; 16 Mar 1998 15:09:03 -0000
Received: from trode.redhat.com (root@trode.redhat.com [199.183.24.80])
by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id KAA13329;
Mon, 16 Mar 1998 10:08:59 -0500
Received: from redhat.com (raster@trode [127.0.0.1])
by trode.redhat.com (8.8.7/8.8.7) with ESMTP id KAA17579;
Mon, 16 Mar 1998 10:06:05 -0500
From: raster@redhat.com
Message-Id: <199803161506.KAA17579@trode.redhat.com>
Date: Mon, 16 Mar 1998 10:06:02 -0500 (EST)
Reply-To: raster@redhat.com
Subject: Re: [gtk-list] Re: interface questions/proposals
To: gtk-list@redhat.com
cc: rdutt@voxel.net
In-Reply-To: <199803161417.WAA18685@copper.singnet.com.sg>
MIME-Version: 1.0
Content-Type: TEXT/plain; CHARSET=US-ASCII
On 16 Mar, Raj Dutt shouted:
-> ---Reply on mail from Robert Atkey about [gtk-list]
Re: interface questions/proposals
->
-> >
-> > What if the buttons were left where they are and a right click on the button
-> > reversed the direction (as on Acorn RISC OS machines). This would keep the
-> > same interface that users are used to and add functionality.
-> >
-> > Bob
-> >
->
-> that sounds like a very interesting and good compromise. makes alot of sense
-> interface wise speaking. i was thinking, could the themes api also control
-> such attributes such as the look of the scrollbar down to the point of
-> placement of buttons?
yes - in phase 2 of themes. phase one is just replacing all the "look"
phase 2 will allow themes to rearrange widgets so scrollbars are for
example on the left not the right, or the top, not the bottom, arrows
are together, apart, or perhaps not even existant at all. the user will
decide this and so we will have the bets interface for EVERYONE.
-> --raj
->
--
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com /\___ /\ ___/||\___ ____/|/\___ raster@redhat.com
Carsten Haitzler | _ //__\\ __||_ __\\ ___|| _ / Red Hat Advanced
218/21 Conner Drive || // __ \\_ \ | | \ _/_|| / Development Labs
Chapel Hill NC 27514 USA ||\\\/ \//__/ |_| /___/||\\ 919 547 0012 ext 282
+1 (919) 929 9443, 801 4392 For pure Enlightenmenthttp://www.rasterman.com/
From rlb@cs.utexas.edu
Received: (qmail 21395 invoked from network); 18 Mar 1998 22:38:21 -0000
Received: from mail.cs.utexas.edu (root@128.83.139.10)
by mail2.redhat.com with SMTP; 18 Mar 1998 22:38:21 -0000
Received: from nevermore.csres.utexas.edu (mail@dial-128-30.ots.utexas.edu
[128.83.46.174])
by mail.cs.utexas.edu (8.8.5/8.8.5) with SMTP id QAA29302
for <gtk-list@redhat.com>; Wed, 18 Mar 1998 16:38:07 -0600 (CST)
Received: from rlb by nevermore.csres.utexas.edu with local (Exim 1.82 #1)
id 0yFQXF-0002Xm-00 (Debian); Wed, 18 Mar 1998 15:38:05 -0600
To: gtk-list@redhat.com
Subject: Re: [gtk-list] interface questions/proposals
References: <199803161136.TAA21769@copper.singnet.com.sg>
From: Rob Browning <rlb@cs.utexas.edu>
Date: 18 Mar 1998 15:38:05 -0600
In-Reply-To: Raj Dutt's message of "Mon, 16 Mar 1998 19:36:02 +0800 (SGT)"
Message-ID: <8767lb65oi.fsf@nevermore.csres.utexas.edu>
Lines: 21
X-Mailer: Gnus v5.6.2/Emacs 20.2
Raj Dutt <rdutt@voxel.net> writes:
> where the scroll buttons are on the bottom.. this may take some
> getting used to but is really a timesaver. i
Actually my favorite approach is to pair the scroll arrows together in
the center of the thumb (or on one end, top or bottom), and have the
cursor move with the thumb while you're scrolling (by holding down one
of the arrows).
This means that you have "one stop shopping" for all scrolling motion.
For example, if you want to go to a particular location, you click the
middle mouse on the scroll bar at that location -- the thumb jumps
there and the arrows with it, leaving the cursor in exactly the right
position to make fine adjustments with the arrows.
I've forgotten which GUI did this, but I have seen it before.
--
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
From evan@unix.worldpath.net
Received: (qmail 14217 invoked from network); 18 Mar 1998 23:05:54 -0000
Received: from unix.worldpath.net (@206.152.180.10)
by mail2.redhat.com with SMTP; 18 Mar 1998 23:05:54 -0000
Received: from unix.worldpath.net (unix.worldpath.net [206.152.180.10])
by unix.worldpath.net (8.8.5/8.8.5(WPI)) with SMTP id SAA08757;
Wed, 18 Mar 1998 18:02:38 -0500 (EST)
Date: Wed, 18 Mar 1998 18:02:37 -0500 (EST)
From: Evan Lawrence <evan@unix.worldpath.net>
To: Rob Browning <rlb@cs.utexas.edu>
cc: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: interface questions/proposals
In-Reply-To: <8767lb65oi.fsf@nevermore.csres.utexas.edu>
Message-ID: <Pine.GSO.3.95.980318175845.7944B-100000@unix.worldpath.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Yeah, this is what the XView toolkit does... I actually find it a little
awkward, and most 95 users would find it hard to get accustomed to. Since
obviously a lot of people have different tastes in this kind of thing, I
would have to agree with raster (I think he's who's working on it) and say
this kind of thing should be left up to themes.
--
Evan Lawrence
On 18 Mar 1998, Rob Browning wrote:
> Raj Dutt <rdutt@voxel.net> writes:
>
> > where the scroll buttons are on the bottom.. this may take some
> > getting used to but is really a timesaver. i
>
> Actually my favorite approach is to pair the scroll arrows together in
> the center of the thumb (or on one end, top or bottom), and have the
> cursor move with the thumb while you're scrolling (by holding down one
> of the arrows).
>
> This means that you have "one stop shopping" for all scrolling motion.
> For example, if you want to go to a particular location, you click the
> middle mouse on the scroll bar at that location -- the thumb jumps
> there and the arrows with it, leaving the cursor in exactly the right
> position to make fine adjustments with the arrows.
>
> I've forgotten which GUI did this, but I have seen it before.
>
> --
> Rob Browning <rlb@cs.utexas.edu>
> PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
>
> --
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
>
>
From mark@snet.fri.uni-lj.si
Received: (qmail 31772 invoked from network); 19 Mar 1998 18:53:38 -0000
Received: from stealth.fri.uni-lj.si (HELO snet.fri.uni-lj.si) (@193.2.72.13)
by mail2.redhat.com with SMTP; 19 Mar 1998 18:53:38 -0000
Received: from snet.fri.uni-lj.si (6.vppp.kiss.uni-lj.si [193.2.98.38])
by snet.fri.uni-lj.si (8.8.7/8.7.3) with ESMTP id TAA29033 for
<gtk-list@redhat.com>; Thu, 19 Mar 1998 19:53:22 +0100 (MET)
Sender: mark@snet.fri.uni-lj.si
Message-ID: <351159A6.EDB5E125@snet.fri.uni-lj.si>
Date: Thu, 19 Mar 1998 18:45:10 +0100
From: Marko Macek <Marko.Macek@snet.fri.uni-lj.si>
Reply-To: Marko.Macek@snet.fri.uni-lj.si
X-Mailer: Mozilla 4.04 [en] (X11; I; Linux 2.0.33 i586)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: interface questions/proposals
References: <199803161136.TAA21769@copper.singnet.com.sg>
<8767lb65oi.fsf@nevermore.csres.utexas.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rob Browning wrote:
>
> Raj Dutt <rdutt@voxel.net> writes:
>
> > where the scroll buttons are on the bottom.. this may take some
> > getting used to but is really a timesaver. i
>
> Actually my favorite approach is to pair the scroll arrows together in
> the center of the thumb (or on one end, top or bottom), and have the
> cursor move with the thumb while you're scrolling (by holding down one
> of the arrows).
>
> This means that you have "one stop shopping" for all scrolling motion.
> For example, if you want to go to a particular location, you click the
> middle mouse on the scroll bar at that location -- the thumb jumps
> there and the arrows with it, leaving the cursor in exactly the right
> position to make fine adjustments with the arrows.
>
> I've forgotten which GUI did this, but I have seen it before.
OpenLook. The feature that moves the mouse by itself is REALLY
ANNOYING (almost as much as fvwm when opening the menu). I would
never use a system that moves the mouse pointer without me actually
moving the mouse.
Mark
--
... MouseDevice "/dev/null"
--------_--------------------------------------------------------------
Marko.Macek@snet.fri.uni-lj.si http://ixtas.fri.uni-lj.si/~markom/
From amundson@gimp.org
Received: (qmail 10973 invoked from network); 3 Apr 1998 07:09:11 -0000
Received: from graft.xcf.berkeley.edu (HELO wilber.gimp.org) (mail@128.32.43.209)
by mail2.redhat.com with SMTP; 3 Apr 1998 07:09:11 -0000
Received: from amundson by wilber.gimp.org with local-smtp (Exim 1.891 #1 (Debian))
id 0yL0b7-0007v3-00; Thu, 2 Apr 1998 23:09:09 -0800
Date: Thu, 2 Apr 1998 23:09:09 -0800 (PST)
From: "Shawn T. Amundson" <amundson@gimp.org>
To: gtk-list@redhat.com
Subject: ANNOUNCE: gcalendar / gtkcalendar
Message-ID: <Pine.LNX.3.96.980402224828.30191A-100000@wilber.gimp.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
gcalendar 0.5.0 is now available at:
ftp://ftp.gimp.org/pub/users/amundson/gcalendar-0.5.0.tar.gz
gcalendar is the testbed for the gtkcalendar widget written
by myself and Cesar Miquel. gtkcalendar is included in this
distribution as well as in gnome-libs (look for it in the
current CVS of gnome). It is very likely gtkcalendar will be
in GTK+ 1.1 and later.
gcalendar is not a complex program. In fact, all it does
is show you the gtkcalendar widget. So why release it?
I have released it because the widget is generally useful,
and there has been at least a minimal interest in such a
widget. Patches will be accepted and considered. ;-)
We are not finished with the widget, but it does satisfy
the minimum requirements and is generally usable.
--
Shawn T. Amundson
amundson@gimp.org http://www.gimp.org/~amundson
From kenelson@ece.ucdavis.edu
Received: (qmail 27460 invoked from network); 21 May 1998 21:48:05 -0000
Received: from clover.ece.ucdavis.edu (@128.120.57.1)
by mail2.redhat.com with SMTP; 21 May 1998 21:48:05 -0000
Received: from clover.ece.ucdavis.edu (kenelson@localhost)
by clover.ece.ucdavis.edu (8.8.7/8.8.7) with ESMTP id OAA05291;
Thu, 21 May 1998 14:48:01 -0700 (PDT)
Message-Id: <199805212148.OAA05291@clover.ece.ucdavis.edu>
X-Mailer: exmh version 1.6.6 3/24/96
To: gtk-list@redhat.com
cc: kenelson@clover.ece.ucdavis.edu
Subject: [gtk-list] Proposed widget
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 21 May 1998 14:48:00 -0700
From: Karl Nelson <kenelson@ece.ucdavis.edu>
I am about half way through developing a new widget for one of
my own projects. I thought it might be a good idea to show
it off and get some feedback on its design so that it will
fit with the form of the rest of gtk. (I have also run into
some sticky issues that I need addressed.)
The concept of the widget is a triangular selector to
allow the user to choose the ratio between three competing
factors. (A common theme in many games... what ratio
do you want between farming/industry/research for example.)
I have placed a mock up of the widget on web sites. Please
check it out and mail me comments, critisisms and general thoughts.
http://www.ece.ucdavis.edu/~kenelson/gtk/trisel/
Thanks for your time.
--Karl
From kc5tja@topaz.axisinternet.com
Received: (qmail 13861 invoked from network); 21 May 1998 22:13:08 -0000
Received: from axisinternet.com (HELO topaz.axisinternet.com) (root@207.213.59.10)
by mail2.redhat.com with SMTP; 21 May 1998 22:13:08 -0000
Received: from topaz.axisinternet.com (kc5tja@axisinternet.com [207.213.59.10])
by topaz.axisinternet.com (8.8.5/8.8.5) with SMTP id PAA32511;
Thu, 21 May 1998 15:04:03 -0700
Date: Thu, 21 May 1998 15:04:03 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
To: gtk-list@redhat.com
cc: kenelson@clover.ece.ucdavis.edu
Subject: Re: [gtk-list] Proposed widget
In-Reply-To: <199805212148.OAA05291@clover.ece.ucdavis.edu>
Message-ID: <Pine.LNX.3.96.980521150206.18359T-100000@topaz.axisinternet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> The concept of the widget is a triangular selector to
> allow the user to choose the ratio between three competing
> factors. (A common theme in many games... what ratio
> do you want between farming/industry/research for example.)
The Amiga has a "proportional gadget" that can be used for horizontal,
vertical, OR bi-axial selections. If I knew how, I'd write a GTK widget
that did exactly the same thing. However, I found that GTK's object model
is hard to write for.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
From nuke@bayside.net
Received: (qmail 16130 invoked from network); 22 May 1998 00:46:08 -0000
Received: from nuklear.steelcity.net (208.22.42.104)
by mail2.redhat.com with SMTP; 22 May 1998 00:46:08 -0000
Received: from localhost (nuke@localhost)
by nuklear.steelcity.net (8.8.8/8.8.8/Debian/GNU) with SMTP id EAA31977;
Fri, 22 May 1998 04:38:35 -0400
X-Authentication-Warning: nuklear.steelcity.net: nuke owned process doing -bs
Date: Fri, 22 May 1998 04:38:35 -0400 (EDT)
From: <nuke@bayside.net>
X-Sender: nuke@nuklear.steelcity.net
To: gtk-list@redhat.com
cc: kenelson@clover.ece.ucdavis.edu
Subject: Re: [gtk-list] Proposed widget
In-Reply-To: <199805212148.OAA05291@clover.ece.ucdavis.edu>
Message-ID: <Pine.LNX.3.96.980522043353.31950A-100000@nuklear.steelcity.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> The concept of the widget is a triangular selector to
> allow the user to choose the ratio between three competing
> factors. (A common theme in many games... what ratio
> do you want between farming/industry/research for example.)
> http://www.ece.ucdavis.edu/~kenelson/gtk/trisel/
as neat as this is, i don't think it's a very good candidate for the gtk
distribution. i really don't have any authority to say, so don't take my
words to be gold, but IMO gtk shouldn't get much bigger than it already
is. i'm afraid someday in the far future we'll look back and laugh at
"those gtk people, just ended up reinventing Motif".
let's not let gtk get stuffed with every widget ever imagined.. maybe we
could have a text file "EXTERNAL_WIDGETS" with URLs pointing to some other
not-made-for-main-distribution widgets? because personally, i think if
only a few games are going to use this, it should be separate.
_ _ __ __ _ _ _
| / |/ /_ __/ /_____ | Nuke Skyjumper |
| / / // / '_/ -_) | "Master of the Farce" |
|_ /_/|_/\_,_/_/\_\\__/ _|_ nuke@bayside.net _|
From kenelson@ece.ucdavis.edu Thu May 11 19:25:07 2000
Received: (qmail 439 invoked from network); 22 May 1998 01:02:18 -0000
Received: from clover.ece.ucdavis.edu (@128.120.57.1)
by mail2.redhat.com with SMTP; 22 May 1998 01:02:18 -0000
Received: from clover.ece.ucdavis.edu (kenelson@localhost)
by clover.ece.ucdavis.edu (8.8.7/8.8.7) with ESMTP id SAA09127;
Thu, 21 May 1998 18:02:12 -0700 (PDT)
Message-Id: <199805220102.SAA09127@clover.ece.ucdavis.edu>
X-Mailer: exmh version 1.6.6 3/24/96
To: gtk-list@redhat.com
cc: kenelson@clover.ece.ucdavis.edu
Subject: Re: [gtk-list] Re: Proposed widget
In-reply-to: Your message of "Fri, 22 May 1998 04:38:35 PDT."
<Pine.LNX.3.96.980522043353.31950A-100000@nuklear.steelcity.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 21 May 1998 18:02:12 -0700
From: Karl Nelson <kenelson@ece.ucdavis.edu>
> as neat as this is, i don't think it's a very good candidate for the gtk
> distribution. i really don't have any authority to say, so don't take my
> words to be gold, but IMO gtk shouldn't get much bigger than it already
> is. i'm afraid someday in the far future we'll look back and laugh at
> "those gtk people, just ended up reinventing Motif".
I agree. There is not much of a reason to build all of
the external widgets into the source, but that still doesn't mean
the contributed widgets like this shouldn't follow as close as
possible to the gtk form.
>
> let's not let gtk get stuffed with every widget ever imagined.. maybe we
> could have a text file "EXTERNAL_WIDGETS" with URLs pointing to some other
> not-made-for-main-distribution widgets? because personally, i think if
> only a few games are going to use this, it should be separate.
Or it should be part of a contributed widget bundle that builds a
static library and installs as an option to gtk. I never like
having URL pointers all over the place as they are constantly out of
date, so you can never find them.
I can tell you for sure that any pointer I give to this widget
will be gone within the next two years. (when I graduate)
--Karl
From szi@aibon.ping.de
Received: (qmail 9704 invoked from network); 23 May 1998 08:42:59 -0000
Received: from lilly.ping.de (qmailr@195.37.120.2)
by mail2.redhat.com with SMTP; 23 May 1998 08:42:59 -0000
Received: (qmail 15297 invoked by uid 10); 23 May 1998 08:42:43 -0000
Received: from aibon.ping.de by lilly.ping.de with UUCP (rmail-0.1-fdc);
23 May 1998 08:42:42 -0000
Received: (qmail 2361 invoked by uid 1013); 23 May 1998 08:21:49 -0000
To: gtk-list@redhat.com
Subject: Re: Proposed widget
References: <Pine.LNX.3.96.980522043353.31950A-100000@nuklear.steelcity.net>
From: Sascha Ziemann <szi@aibon.ping.de>
Date: 23 May 1998 10:21:49 +0200
In-Reply-To: 's message of Fri, 22 May 1998 04:38:35 -0400 (EDT)
Message-ID: <7u7m3dxuqq.fsf@olivia.aibon.ping.de>
Lines: 10
X-Mailer: Gnus v5.5/Emacs 20.2
<nuke@bayside.net> writes:
| but IMO gtk shouldn't get much bigger than it already is.
Gtk+ should have as much widgets as posible, if they are bug free. On
my system libgtk.so is 989012 Bytes. Where is the problem, when it is
twice as big?
--
http://www.ping.de/sites/aibon/
From kc5tja@topaz.axisinternet.com
Received: (qmail 3463 invoked from network); 23 May 1998 15:25:30 -0000
Received: from axisinternet.com (HELO topaz.axisinternet.com) (root@207.213.59.10)
by mail2.redhat.com with SMTP; 23 May 1998 15:25:30 -0000
Received: from topaz.axisinternet.com (kc5tja@axisinternet.com [207.213.59.10])
by topaz.axisinternet.com (8.8.5/8.8.5) with SMTP id IAA00990
for <gtk-list@redhat.com>; Sat, 23 May 1998 08:16:09 -0700
Date: Sat, 23 May 1998 08:16:09 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Proposed widget
In-Reply-To: <7u7m3dxuqq.fsf@olivia.aibon.ping.de>
Message-ID: <Pine.LNX.3.96.980523080830.19A-100000@topaz.axisinternet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> Gtk+ should have as much widgets as posible, if they are bug free. On
> my system libgtk.so is 989012 Bytes. Where is the problem, when it is
> twice as big?
AmigaOS 3.1 is less than 512K in size (GTK+ seems to be almost a
megabyte), and includes a complete multitasking, near-real-time OS for
free. It includes audio drivers, serial port drivers, and bi-directional
parallel port drivers. It has a world-class user interface as well. It
can do everything GTK can, and then some, and without the bugs.
I think what he was seeing at this point was that GTK is starting to
suffer from "featuritis." GTK, alone, is larger than an already too-big
operating system (I'm striving to make an Amiga-like OS in under 64K; and
I know it's already been done before. Witness QNX and Photon microGUI).
To be honest, your GTK library alone is larger than my entire Linux
kernel, which is also fairly close to 512K (it's around 580K to be exact).
If GTK is to gather all the widgets in the known world, then at least
allow for the ability to use dynamic libraries of widgets; we really
should not use static linking for them. If I don't want a table widget,
why should I have it linked into my executable? On my 2GB Linux
partition, I only have 56MB free. At this point, I must start to worry
about code size.
Don't let the Microsoft way of thinking lure you into this trap: Small
code is usually just as fast and just as powerful as BIG code if done
well.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
From nuke@bayside.net
Received: (qmail 6866 invoked from network); 23 May 1998 18:50:33 -0000
Received: from nuklear.steelcity.net (208.22.42.104)
by mail2.redhat.com with SMTP; 23 May 1998 18:50:33 -0000
Received: from localhost (nuke@localhost)
by nuklear.steelcity.net (8.8.8/8.8.8/Debian/GNU) with SMTP id WAA02631
for <gtk-list@redhat.com>; Sat, 23 May 1998 22:42:26 -0400
X-Authentication-Warning: nuklear.steelcity.net: nuke owned process doing -bs
Date: Sat, 23 May 1998 22:42:26 -0400 (EDT)
From: <nuke@bayside.net>
X-Sender: nuke@nuklear.steelcity.net
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Proposed widget
In-Reply-To: <7u7m3dxuqq.fsf@olivia.aibon.ping.de>
Message-ID: <Pine.LNX.3.96.980523223745.2620B-100000@nuklear.steelcity.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> <nuke@bayside.net> writes:
>
> | but IMO gtk shouldn't get much bigger than it already is.
>
> Gtk+ should have as much widgets as posible, if they are bug free. On
> my system libgtk.so is 989012 Bytes. Where is the problem, when it is
> twice as big?
the problem is that even shared libs can be overkill. sure, try telling
"Gtk+ should have as much widgets as posible" to the guy with the 486 and
8mb of ram. no, we are not microsoft. our solution isn't "BUY NEW
HARDWARE!"
just think.. how long has gtk existed as its own toolkit (not a part of
gimp)? less than a year? and already your binary is a meg. what about next
year after we put every single widget ever announced in it? knowing that
gtk development is going to skyrocket this year because of 1.0 (and due to
so many students being off for the summer), there are going to be LOTS of
widgets. do you want a 5mb binary?
_ _ __ __ _ _ _
| / |/ /_ __/ /_____ | Nuke Skyjumper |
| / / // / '_/ -_) | "Master of the Farce" |
|_ /_/|_/\_,_/_/\_\\__/ _|_ nuke@bayside.net _|
From terop@students.cc.tut.fi
Received: (qmail 23237 invoked from network); 23 May 1998 19:17:56 -0000
Received: from assari.cc.tut.fi (terop@130.230.10.21)
by mail2.redhat.com with SMTP; 23 May 1998 19:17:56 -0000
Received: (from terop@localhost)
by assari.cc.tut.fi (8.8.5/8.8.5) id WAA07866;
Sat, 23 May 1998 22:17:58 +0300 (EET DST)
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Proposed widget
References: <Pine.LNX.3.96.980523223745.2620B-100000@nuklear.steelcity.net>
From: Tero Pulkkinen <terop@students.cc.tut.fi>
Date: 23 May 1998 22:17:58 +0300
In-Reply-To: <nuke@bayside.net>'s message of "Sat, 23 May 1998 22:42:26 -0400 (EDT)"
Message-ID: <xdud8d4eqzd.fsf@assari.cc.tut.fi>
Lines: 41
X-Mailer: Gnus v5.6.9/Emacs 20.2
> > Gtk+ should have as much widgets as posible, if they are bug free. On
> > my system libgtk.so is 989012 Bytes. Where is the problem, when it is
> > twice as big?
<nuke@bayside.net> writes:
> the problem is that even shared libs can be overkill. sure, try telling
> "Gtk+ should have as much widgets as posible" to the guy with the 486 and
> 8mb of ram. no, we are not microsoft. our solution isn't "BUY NEW
> HARDWARE!"
Shared libs are not (I think) loaded fully to mem, only those parts which are
needed.
> just think.. how long has gtk existed as its own toolkit (not a part of
> gimp)? less than a year? and already your binary is a meg. what about next
> year after we put every single widget ever announced in it?
The problem is - if something is not put into gtk, everyone will reinvent it
quite many times and we'll have applications which does not have standard
look. (though maybe it could be different library like "libgtkwidgets.so").
Once something is made well enough, it must go into libraries that are
reused, so that it will be reused in applications. This reuse will eventually
lead to *smaller* system instead of larger system.
> knowing that
> gtk development is going to skyrocket this year because of 1.0 (and due to
> so many students being off for the summer), there are going to be LOTS of
> widgets. do you want a 5mb binary?
on solaris its already like 6 Megs :) (with debugging on of course..)
(though I suspect the machine I compile things on is somewhat broken -
a plain old hello world linked with *shared* library becomes 2Megs
executable in it.. must be something wrong with it - strings-command
reveal it lists every symbol from the shared library, while only few
of them are ever used in the program... I dont think it should do
that... )
--
-- Tero Pulkkinen -- terop@modeemi.cs.tut.fi --
From amundson@gimp.org
Received: (qmail 8516 invoked from network); 24 May 1998 01:39:45 -0000
Received: from graft.xcf.berkeley.edu (HELO wilber.gimp.org) (mail@128.32.43.209)
by mail2.redhat.com with SMTP; 24 May 1998 01:39:45 -0000
Received: from amundson by wilber.gimp.org with local-smtp (Exim 1.92 #1 (Debian))
id 0ydPlD-0004hY-00; Sat, 23 May 1998 18:39:39 -0700
Date: Sat, 23 May 1998 18:39:38 -0700 (PDT)
From: "Shawn T. Amundson" <amundson@gimp.org>
To: gtk-list@redhat.com
Subject: ANNOUNCE: GtkPacker 0.9.0
Message-ID: <Pine.LNX.3.96.980523182823.16080A-100000@wilber.gimp.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
GtkPacker is a Tk-like packer for the GTK toolkit. The
algorithm for the packer is the same as the packer in
Tk 8.0.
Version 0.9.0 is available at:
ftp://ftp.gtk.org/pub/users/amundson/gtkpacker-0.9.0.tar.gz
An demo is included which allows interactive control of
buttons in a packer.
If you are not familiar with using Tk's packer, I suggest
finding info on Tk which explains it. A tutorial on the
packer's layout algorithm is not yet included.
Comments and patches are welcome.
--
Shawn T. Amundson
amundson@gimp.org http://www.gimp.org/~amundson
"The assumption that the universe looks the same in every
direction is clearly not true in reality." - Stephen Hawking
From szi@aibon.ping.de
Received: (qmail 19020 invoked from network); 24 May 1998 08:17:29 -0000
Received: from lilly.ping.de (qmailr@195.37.120.2)
by mail2.redhat.com with SMTP; 24 May 1998 08:17:29 -0000
Received: (qmail 10789 invoked by uid 10); 24 May 1998 08:17:12 -0000
Received: from aibon.ping.de by lilly.ping.de with UUCP (rmail-0.1-fdc);
24 May 1998 08:17:12 -0000
Received: (qmail 2951 invoked by uid 1013); 24 May 1998 08:01:39 -0000
To: gtk-list@redhat.com
Subject: Re: Proposed widget
References: <Pine.LNX.3.96.980523080830.19A-100000@topaz.axisinternet.com>
From: Sascha Ziemann <szi@aibon.ping.de>
Date: 24 May 1998 10:01:39 +0200
In-Reply-To: KC5TJA's message of Sat, 23 May 1998 08:16:09 -0700 (PDT)
Message-ID: <7uhg2gxfks.fsf@olivia.aibon.ping.de>
Lines: 15
X-Mailer: Gnus v5.5/Emacs 20.2
KC5TJA <kc5tja@topaz.axisinternet.com> writes:
| AmigaOS 3.1 is less than 512K in size (GTK+ seems to be almost a
| megabyte), and includes a complete multitasking, near-real-time OS for
| free.
AmigaOS is silly gambler garbage. It does have at least any memory
protection and I can continue the list of not existing features... But
I really do not want to hurt your nostalgic reminders, so we should
not continue the discussion about the Amiga. Every normal PC has 32 MB
RAM today. Is it really not acceptable to spend 10% for a full featured
widget set?
--
http://www.ping.de/sites/aibon/
From szi@aibon.ping.de
Received: (qmail 19050 invoked from network); 24 May 1998 08:17:30 -0000
Received: from lilly.ping.de (qmailr@195.37.120.2)
by mail2.redhat.com with SMTP; 24 May 1998 08:17:30 -0000
Received: (qmail 10794 invoked by uid 10); 24 May 1998 08:17:12 -0000
Received: from aibon.ping.de by lilly.ping.de with UUCP (rmail-0.1-fdc);
24 May 1998 08:17:12 -0000
Received: (qmail 3001 invoked by uid 1013); 24 May 1998 08:12:23 -0000
To: gtk-list@redhat.com
Subject: Re: Proposed widget
References: <Pine.LNX.3.96.980523223745.2620B-100000@nuklear.steelcity.net>
From: Sascha Ziemann <szi@aibon.ping.de>
Date: 24 May 1998 10:12:23 +0200
In-Reply-To: 's message of Sat, 23 May 1998 22:42:26 -0400 (EDT)
Message-ID: <7ug1i0xf2w.fsf@olivia.aibon.ping.de>
Lines: 13
X-Mailer: Gnus v5.5/Emacs 20.2
<nuke@bayside.net> writes:
| there are going to be LOTS of
| widgets. do you want a 5mb binary?
Perhaps you should implement a --without-*-widget commandline option
for configure.
I have to pay 25 DM for 8 MB. I have absolutely no problem to spend 2
pizzas for Gtk+.
--
http://www.ping.de/sites/aibon/
From kc5tja@topaz.axisinternet.com
Received: (qmail 9987 invoked from network); 24 May 1998 15:27:35 -0000
Received: from axisinternet.com (HELO topaz.axisinternet.com) (root@207.213.59.10)
by mail2.redhat.com with SMTP; 24 May 1998 15:27:35 -0000
Received: from topaz.axisinternet.com (kc5tja@axisinternet.com [207.213.59.10])
by topaz.axisinternet.com (8.8.5/8.8.5) with SMTP id IAA16186
for <gtk-list@redhat.com>; Sun, 24 May 1998 08:18:04 -0700
Date: Sun, 24 May 1998 08:18:04 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Proposed widget
In-Reply-To: <7uhg2gxfks.fsf@olivia.aibon.ping.de>
Message-ID: <Pine.LNX.3.96.980524081450.15814F-100000@topaz.axisinternet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> AmigaOS is silly gambler garbage. It does have at least any memory
> protection and I can continue the list of not existing features... But
You don't need memory protection in a single-user OS. Bug-free
programs are the responsibility of the programmer, not the OS. The OS
should, instead, concentrate on providing its services as quickly and as
efficiently as possible.
> I really do not want to hurt your nostalgic reminders, so we should
> not continue the discussion about the Amiga. Every normal PC has 32 MB
> RAM today. Is it really not acceptable to spend 10% for a full featured
> widget set?
My PC only has 16MB of RAM, yet seems perfectly normal to me. In fact,
most machines I come into contact with still only have 16MB of RAM.
Furthermore, I fail to see how RAM size and free disk space have anything
to do with things.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
From kc5tja@topaz.axisinternet.com
Received: (qmail 23687 invoked from network); 24 May 1998 15:51:04 -0000
Received: from axisinternet.com (HELO topaz.axisinternet.com) (root@207.213.59.10)
by mail2.redhat.com with SMTP; 24 May 1998 15:51:04 -0000
Received: from topaz.axisinternet.com (kc5tja@axisinternet.com [207.213.59.10])
by topaz.axisinternet.com (8.8.5/8.8.5) with SMTP id IAA18095
for <gtk-list@redhat.com>; Sun, 24 May 1998 08:41:33 -0700
Date: Sun, 24 May 1998 08:41:33 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Proposed widget
In-Reply-To: <7ug1i0xf2w.fsf@olivia.aibon.ping.de>
Message-ID: <Pine.LNX.3.96.980524083610.15814H-100000@topaz.axisinternet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> I have to pay 25 DM for 8 MB. I have absolutely no problem to spend 2
> pizzas for Gtk+.
Problem is: Linux won't load all 5MB into RAM. It will dump some of that
out to swap file.
Furthermore, we're dealing with harddrive space here as well. a 5MB
binary is absolutely *******HUGE*******, especially for a single
component. If you want to have such huge binaries, please make the switch
to Windows. They have that sort of thing all the time. I don't want it.
If GTK is going to get much larger than 2MB, I will switch to using LibGGI
and implementing my own user interface.
Now, I have absolutely NO objections to having a 1MB or so libgtk.so file,
and having *extensions* to it, a la GGI. That I can handle. But having a
single, monolithic library that is all inclusive is decidedly a
Microsoft-ian way of thinking about the user interface.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
From kc5tja@topaz.axisinternet.com
Received: (qmail 29461 invoked from network); 24 May 1998 15:59:56 -0000
Received: from axisinternet.com (HELO topaz.axisinternet.com) (root@207.213.59.10)
by mail2.redhat.com with SMTP; 24 May 1998 15:59:55 -0000
Received: from topaz.axisinternet.com (kc5tja@axisinternet.com [207.213.59.10])
by topaz.axisinternet.com (8.8.5/8.8.5) with SMTP id IAA18809
for <gtk-list@redhat.com>; Sun, 24 May 1998 08:50:26 -0700
Date: Sun, 24 May 1998 08:50:26 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Proposed widget
In-Reply-To: <7uhg2gxfks.fsf@olivia.aibon.ping.de>
Message-ID: <Pine.LNX.3.96.980524084139.15814I-100000@topaz.axisinternet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On 24 May 1998, Sascha Ziemann wrote:
> AmigaOS is silly gambler garbage. It does have at least any memory
> protection and I can continue the list of not existing features... But
> I really do not want to hurt your nostalgic reminders, so we should
> not continue the discussion about the Amiga. Every normal PC has 32 MB
Actually, I beg to differ. You brought it up on this list, I think you
should explain your reasoning here. Why is AmigaOS, oft considered the
most efficient OS in existance today, "silly gambler garbage" to you?
I think what we have here is a fundamental rift in how one thinks of
building software. AmigaOS tries very hard to include only the things
absolutely necessary to successfully run the computer. It's the
RISC-point of view: simpler is better. UNIX of any sort, Windows, OS/2,
et. al. tries, however, to be all-inclusive of all applications for all
users. It tries to be as COMPLETE as possible: the CISC point of view.
Then people wonder why AmigaOS runs so much faster than other
"heavy-weight" operating systems, then they get jealous and start touting,
"But it doesn't have memory protection!" TOO BAD! It doesn't NEED it!
Therefore, I ask that you have a little more open mind about AmigaOS, and
how its internals work. They are porting AmigaOS to the x86 as we speak,
and when released, I can garuntee you that it *WILL* make a big splash.
> RAM today. Is it really not acceptable to spend 10% for a full featured
> widget set?
Yes. It is truely unacceptable for me. I want my RAM and drive space for
*MY* application's data. Not a tool. Would you want to work on your own
car if the tool you need is the size of your car itself, and just as
heavy?
PS: AmigaOS is still perfectly happy on a 20MB harddrive. If you intend
on running a world-class application like VideoToaster or some of the
Amiga office suites, then you're probably looking at needing around 100MB.
Need Internet? Another 5MB. Linux, in contrast, requires 200MB for a
comparibly equipped system. Still not bad, but I thought I'd put it into
perspective.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
From nils@rhlx01.rz.fht-esslingen.de
Received: (qmail 3480 invoked from network); 24 May 1998 17:21:39 -0000
Received: from rhlx01.rz.fht-esslingen.de (nils@134.108.34.10)
by mail2.redhat.com with SMTP; 24 May 1998 17:21:39 -0000
Received: from localhost (nils@localhost)
by rhlx01.rz.fht-esslingen.de (8.8.8/8.8.8) with SMTP id TAA19897
for <gtk-list@redhat.com>; Sun, 24 May 1998 19:21:17 +0200
Date: Sun, 24 May 1998 19:21:16 +0200 (CEST)
From: Nils Philippsen <nils@rhlx01.rz.fht-esslingen.de>
To: gtk-list@redhat.com
Subject: [OFFTOPIC] Re: [gtk-list] Re: Proposed widget
In-Reply-To: <Pine.LNX.3.96.980524084139.15814I-100000@topaz.axisinternet.com>
Message-ID: <Pine.LNX.3.96.980524190008.19830A-100000@rhlx01.rz.fht-esslingen.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Guys - this actually doesn't belong here, but as not even I conform to my
advices ... :-)
On Sun, 24 May 1998, KC5TJA wrote:
> On 24 May 1998, Sascha Ziemann wrote:
>
[snip]
> Then people wonder why AmigaOS runs so much faster than other
> "heavy-weight" operating systems, then they get jealous and start touting,
> "But it doesn't have memory protection!" TOO BAD! It doesn't NEED it!
Every serious OS needs memory protection. People (most people I know of) run
(ran) an Amiga (with AmigaOS) for games - The important stuff runs (should
run) on something more suitable for it (e.g. Un*x). Your opinion may differ.
>
> Therefore, I ask that you have a little more open mind about AmigaOS, and
> how its internals work. They are porting AmigaOS to the x86 as we speak,
> and when released, I can garuntee you that it *WILL* make a big splash.
>
Splash. Glug.
> > RAM today. Is it really not acceptable to spend 10% for a full featured
> > widget set?
>
> Yes. It is truely unacceptable for me. I want my RAM and drive space for
> *MY* application's data. Not a tool. Would you want to work on your own
> car if the tool you need is the size of your car itself, and just as
> heavy?
Then why would you want to have an OS kernel of > 300-500KB just for running
e.g. awk (135KB here)? Weak argument.
>
> PS: AmigaOS is still perfectly happy on a 20MB harddrive. If you intend
> on running a world-class application like VideoToaster or some of the
> Amiga office suites, then you're probably looking at needing around 100MB.
> Need Internet? Another 5MB. Linux, in contrast, requires 200MB for a
> comparibly equipped system. Still not bad, but I thought I'd put it into
> perspective.
Somehow new widgets must be collected and brought to the programmers,
otherwise everyone has to implement her/his GtkAnyWidget for her/himself
(useless duplication of work), every program will have the code for
GtkAnyWidget in the app's code (instead of in the shared lib) and if I run all
of the simultaneously it is _my_ RAM that's consumed by all those
implementations of GtkAnyWidget. And you have the nerve to call this clever?
If a widget is of general interest (show me one that isn't) it should be
shipped with gtk - whether in libgtk or libgtkwidgets isn't interesting (to
me) - the code for every widget in the lib and therefore one time on the disk,
code of not used widgets will happily get paged into swapspace - what's the
problem?
Bye,
Nils
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nils Philippsen @college: nils@rhlx01.rz.fht-esslingen.de
Vogelsangstrasse 115 @home: nils@wombat.dialup.fht-esslingen.de
D 70197 Stuttgart phone: +49-711-6599405
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wer heute an der Bildung spart, Those who scrimp on education today,
hat morgen noch bloedere Politiker. get even dumber politicians tomorrow.
From kc5tja@topaz.axisinternet.com
Received: (qmail 13840 invoked from network); 24 May 1998 17:40:51 -0000
Received: from axisinternet.com (HELO topaz.axisinternet.com) (root@207.213.59.10)
by mail2.redhat.com with SMTP; 24 May 1998 17:40:51 -0000
Received: from topaz.axisinternet.com (kc5tja@axisinternet.com [207.213.59.10])
by topaz.axisinternet.com (8.8.5/8.8.5) with SMTP id KAA26869
for <gtk-list@redhat.com>; Sun, 24 May 1998 10:31:19 -0700
Date: Sun, 24 May 1998 10:31:19 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] [OFFTOPIC] Re: Proposed widget
In-Reply-To: <Pine.LNX.3.96.980524190008.19830A-100000@rhlx01.rz.fht-esslingen.de>
Message-ID: <Pine.LNX.3.96.980524101817.22644B-100000@topaz.axisinternet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> Every serious OS needs memory protection. People (most people I know of) run
> (ran) an Amiga (with AmigaOS) for games - The important stuff runs (should
> run) on something more suitable for it (e.g. Un*x). Your opinion may differ.
I sure as hell don't use AmigaOS for games. Just because every other OS
you've used has memory protection doesn't make it "necessary to run
serious software." Quite the contrary. Memory protection is NEVER used
when running well-written applications (unless you're working with paged
virtual memory, but there are other ways around that as well). If the
memory protection system needs to kick in, then something is wrong with
the program you're running. It should never have been sold in the first
place.
> Then why would you want to have an OS kernel of > 300-500KB just for running
> e.g. awk (135KB here)? Weak argument.
Precisely the reason I'm writing Dolphin.
> Somehow new widgets must be collected and brought to the programmers,
> otherwise everyone has to implement her/his GtkAnyWidget for her/himself
Use dynamic libraries that are loaded only when necessary. That's what
gadtools.library is.
> (useless duplication of work), every program will have the code for
> GtkAnyWidget in the app's code (instead of in the shared lib) and if I run all
> of the simultaneously it is _my_ RAM that's consumed by all those
> implementations of GtkAnyWidget. And you have the nerve to call this clever?
What? Where did I say that? I don't recall saying that. I distinctly
said that I have "no problems with GTK being 1MB, with dynamically loading
extensions to it on an as-needed basis. But GTK should never be so large
as to be all-encompassing everything for everybody in all situations.
That would be a Microsoft-way of thinking." (Paraphrased, of course) And
I *DO* have the original quote for that. :-)
> If a widget is of general interest (show me one that isn't) it should be
> shipped with gtk - whether in libgtk or libgtkwidgets isn't interesting (to
Precisely. Make the widget's code available, but NOT in libgtk.so, unless
it's imperative to GTK's operation. 5MB of binaries roughly translates to
at least 10 to 20MB of source code, on average. Would you want to
maintain that? And think of the side effects changing a source file
-could- have. I've been a developer for over 10 years, and I've seen many
cases where person A updates his files, no problem. Person B updates his
files, no problem. Person C updates his files. Now all of a sudden the
whole thing doesn't work, because of some unexpected side effect. Now
person C, B, or A needs to rework all of their code to work with C's
changes, or C needs to undo his work (thus hindering progress). I've seen
it happen in the Linux community too.
Keeping the widget libraries physically separated helps in debugging such
things.
> me) - the code for every widget in the lib and therefore one time on the disk,
> code of not used widgets will happily get paged into swapspace - what's the
> problem?
Big software tends to be slower than small software, as perceived by the
user. I am a speed freak. My computer needs to run as fast as possible,
whenever possible. I just don't want Linux to become like Windows.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
From felix@crowfix.com
Received: (qmail 20210 invoked from network); 24 May 1998 18:24:09 -0000
Received: from crowfix.crowfix.com (HELO crowfix.com) (qmailr@207.228.46.42)
by mail2.redhat.com with SMTP; 24 May 1998 18:24:09 -0000
Received: (qmail 21715 invoked by uid 501); 24 May 1998 18:24:27 -0000
Date: 24 May 1998 18:24:27 -0000
Message-ID: <19980524182427.21714.qmail@crowfix.com>
From: Felix Morley Finch <felix@crowfix.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] [OFFTOPIC] Re: Proposed widget
In-Reply-To: <Pine.LNX.3.96.980524190008.19830A-100000@rhlx01.rz.fht-esslingen.de>
(message from Nils Philippsen on Sun, 24 May 1998 19:21:16 +0200)
References: <Pine.LNX.3.96.980524084139.15814I-100000@topaz.axisinternet.com>
<Pine.LNX.3.96.980524190008.19830A-100000@rhlx01.rz.fht-esslingen.de>
X-Mailer: VM 6.34 under Emacs 20.2.1
I have been following this discussion with some interest. I am new to
Gtk, altho not C or unix. In general, I agree that all widgets should
be in the distribution and lib. Gtk is meant (as I understand it) to
be a General Tool Kit. This implies general purpose. This implies a
general purpose OS. Any OS without memory protection is not a general
purpose OS. It may run games fine. It may run a few apps fine. But
it is not a general purpose OS, it is special purpose.
Bragging about AmigaOS running on a 20 MB disk is no big deal; I wrote
a SCSI driver for a UNIX SVR3.2 system, with a 20MB disk as my entire
development and test platform. I sure owuldn't have called that
general purpose, even tho I also used it with uucp to access
newsgroups and email. There are versions of Linux running on dinky
little systems. But they are not general purpose systems.
If you want a special dinky little system, why use Gtk? Why should
the vast majority of general purpose users be held back and have to
re-invent the wheel, over and over again, because you want it to run
on a special purpose dinkly little system?
BTW, as I understand the Amiga announcement, the x86 4.0 release is a
stopgap developers release only, to get development going until the
new Amiga hardware arrives, which will then use OS 5.0. I doubt very
seriously that Gateway is thinking of challenging Mickeysoft with a
brand new OS. About the only splash it will make is in the Amiga world.
--
... _._. ._ ._. . _._. ._. ___ .__ ._. . .__. ._ .. ._.
Felix Finch: scarecrow repairman & rocket surgeon / felix@crowfix.com
PGP = 91 B3 94 7C E9 E8 76 2D E1 63 51 AA A0 48 89 2F ITAR license #4933
I've found a solution to Fermat's Last Theorem but I see I've run out of room o
From kc5tja@topaz.axisinternet.com
Received: (qmail 26380 invoked from network); 24 May 1998 18:41:33 -0000
Received: from axisinternet.com (HELO topaz.axisinternet.com) (root@207.213.59.10)
by mail2.redhat.com with SMTP; 24 May 1998 18:41:33 -0000
Received: from topaz.axisinternet.com (kc5tja@axisinternet.com [207.213.59.10])
by topaz.axisinternet.com (8.8.5/8.8.5) with SMTP id LAA31652
for <gtk-list@redhat.com>; Sun, 24 May 1998 11:32:02 -0700
Date: Sun, 24 May 1998 11:32:02 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: [OFFTOPIC] Re: Proposed widget
In-Reply-To: <19980524182427.21714.qmail@crowfix.com>
Message-ID: <Pine.LNX.3.96.980524112749.31124A-100000@topaz.axisinternet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> general purpose OS. Any OS without memory protection is not a general
> purpose OS. It may run games fine. It may run a few apps fine. But
> it is not a general purpose OS, it is special purpose.
I've yet to see a single reason why an OS MUST have memory protection to
be general purpose. They keep saying you must have it, but I've yet to
see proof.
> If you want a special dinky little system, why use Gtk? Why should
> the vast majority of general purpose users be held back and have to
> re-invent the wheel, over and over again, because you want it to run
> on a special purpose dinkly little system?
Fine. If you want a 20MB binary, so be it.
> BTW, as I understand the Amiga announcement, the x86 4.0 release is a
> stopgap developers release only, to get development going until the
> new Amiga hardware arrives, which will then use OS 5.0. I doubt very
Your point?
> seriously that Gateway is thinking of challenging Mickeysoft with a
> brand new OS. About the only splash it will make is in the Amiga world.
Didn't say they were. I just said that it'd make a splash. It'd be a
commercial alternative to Windows and OS/2. You know, where people can
make money supporting it. Very few people are making money from Linux
right now. A lot more people are making money off of the current AmigaOS
environment. And when AmigaOS hits the x86 market, a lot more people will
start making money.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
From rich@kyoto.noir.com
Received: (qmail 22233 invoked from network); 24 May 1998 19:12:47 -0000
Received: from sendai.vip.best.com (HELO kyoto.noir.com) (rich@204.156.156.216)
by mail2.redhat.com with SMTP; 24 May 1998 19:12:47 -0000
Received: (from rich@localhost)
by kyoto.noir.com (8.8.7/8.8.7) id MAA19181;
Sun, 24 May 1998 12:12:25 -0700
Date: Sun, 24 May 1998 12:12:25 -0700
Message-Id: <199805241912.MAA19181@kyoto.noir.com>
From: "K. Richard Pixley" <rich@kyoto.noir.com>
To: gtk-list@redhat.com
CC: gtk-list@redhat.com
In-reply-to: <Pine.LNX.3.96.980524083610.15814H-100000@topaz.axisinternet.com>
(kc5tja@topaz.axisinternet.com)
Subject: Re: [gtk-list] Re: Proposed widget
References: <Pine.LNX.3.96.980524083610.15814H-100000@topaz.axisinternet.com>
Date: Sun, 24 May 1998 08:41:33 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
> I have to pay 25 DM for 8 MB. I have absolutely no problem to spend 2
> pizzas for Gtk+.
Problem is: Linux won't load all 5MB into RAM. It will dump some
of that out to swap file.
If so, then your linux has a huge bug. Shared libraries, like
executables, should page in from their resident locations on disk,
avoiding the swap area altogether. Staging through swap in unix went
out of fashion prior to the introduction of shared libraries.
With 5M shared libraries, though, I doubt we'd see much win from
optimizing page locations. When we get up to 80M, then we should
think about it.
It's also possible to split the library into pieces. This might help
somewhat, though with a piddly 10M library, I doubt it's worth the
effort.
Furthermore, we're dealing with harddrive space here as well. a
5MB binary is absolutely *******HUGE*******, especially for a
single component.
Actually, no. 5M is not all that much these days. When you work with
500M binaries, you're getting up there. (and yes, I'm serious).
If you want to have such huge binaries, please make the switch to
Windows. They have that sort of thing all the time. I don't want
it.
Disk is cheap. Linux pages well. What's your concern?
If GTK is going to get much larger than 2MB, I will switch to using
LibGGI and implementing my own user interface.
Now, I have absolutely NO objections to having a 1MB or so
libgtk.so file, and having *extensions* to it, a la GGI. That I
can handle. But having a single, monolithic library that is all
inclusive is decidedly a Microsoft-ian way of thinking about the
user interface.
We'd need to bench to be sure, but for small apps, I'd bet that the
overhead of loading numerous pieces of shared libraries combined with
the page rounding overhead would likely overshadow any possible wins.
--rich
From kc5tja@topaz.axisinternet.com
Received: (qmail 27407 invoked from network); 24 May 1998 19:43:23 -0000
Received: from axisinternet.com (HELO topaz.axisinternet.com) (root@207.213.59.10)
by mail2.redhat.com with SMTP; 24 May 1998 19:43:23 -0000
Received: from topaz.axisinternet.com (kc5tja@axisinternet.com [207.213.59.10])
by topaz.axisinternet.com (8.8.5/8.8.5) with SMTP id MAA03798
for <gtk-list@redhat.com>; Sun, 24 May 1998 12:33:42 -0700
Date: Sun, 24 May 1998 12:33:42 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Proposed widget
In-Reply-To: <199805241912.MAA19181@kyoto.noir.com>
Message-ID: <Pine.LNX.3.96.980524122634.2956B-100000@topaz.axisinternet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> If so, then your linux has a huge bug. Shared libraries, like
> executables, should page in from their resident locations on disk,
> avoiding the swap area altogether. Staging through swap in unix went
> out of fashion prior to the introduction of shared libraries.
You're right -- I stand corrected.
> With 5M shared libraries, though, I doubt we'd see much win from
> optimizing page locations. When we get up to 80M, then we should
> think about it.
OK. That, having been said, makes me wonder, "What is a good cut-off size
for GTK, before considering using external modules?"
If you do include stuff into GTK, there should be some research on how
useful the widget will be. GTK currently has rulers, which are godsend
for document-based programs. GTK has support for buttons, lists, trees,
etc. That I can also live with, as they have a high frequency of use in
common software. Font selector was long overdue. :-) But all possible
widgets?
> It's also possible to split the library into pieces. This might help
> somewhat, though with a piddly 10M library, I doubt it's worth the
> effort.
I'd hate to be the person on the other end of a 33.6kbps connection
downloading GTK+-5.0, with its 10MB binary. Imagine the size of the
source code? 8-D OUCH!
> Actually, no. 5M is not all that much these days. When you work with
> 500M binaries, you're getting up there. (and yes, I'm serious).
You are sick and evil if you make a program that's 500MB in size... :D
> Disk is cheap. Linux pages well. What's your concern?
Bloat-ware.
> We'd need to bench to be sure, but for small apps, I'd bet that the
> overhead of loading numerous pieces of shared libraries combined with
> the page rounding overhead would likely overshadow any possible wins.
Perhaps. Is it possible to use external shared libs with GTK now (instead
of static linking)? I'd imagine so, since shared libraries often look
like static libraries to all parties involved.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
From kth@srv.net
Received: (qmail 28015 invoked from network); 24 May 1998 19:44:03 -0000
Received: from snake.srv.net (HELO srv.net) (199.104.81.3)
by mail2.redhat.com with SMTP; 24 May 1998 19:44:03 -0000
Received: from msdos.sofsol.id.us (ras546.srv.net [205.180.127.46])
by srv.net (8.8.7/8.8.5) with SMTP id NAA15783
for <gtk-list@redhat.com>; Sun, 24 May 1998 13:44:00 -0600 (MDT)
Message-Id: <1.5.4.32.19980524194934.00824e64@snake.srv.net>
X-Sender: kth@snake.srv.net
X-Mailer: Windows Eudora Light Version 1.5.4 (32)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 24 May 1998 13:49:34 -0600
To: gtk-list@redhat.com
From: Kevin Handy <kth@srv.net>
Subject: Re: [gtk-list] Re: Proposed widget
At 12:12 PM 5/24/98 -0700, you wrote:
> Date: Sun, 24 May 1998 08:41:33 -0700 (PDT)
> From: KC5TJA <kc5tja@topaz.axisinternet.com>
>
> > I have to pay 25 DM for 8 MB. I have absolutely no problem to spend 2
> > pizzas for Gtk+.
>
> Problem is: Linux won't load all 5MB into RAM. It will dump some
> of that out to swap file.
>
>If so, then your linux has a huge bug. Shared libraries, like
>executables, should page in from their resident locations on disk,
>avoiding the swap area altogether. Staging through swap in unix went
>out of fashion prior to the introduction of shared libraries.
You just beat me to this item. I thought for sure that Linux did this,
but was not sure after so many posted that this shared/nowrite code
would swap out. Many other OS's (Alpha OSF/1, VMS, etc) that I have
worked with use the original binary instead of swapping this out.
(There is no reason to write out code that (has not been)/(can not be)
changed in memory. The MMU will get upset if you try (segmentation
violation)
>With 5M shared libraries, though, I doubt we'd see much win from
>optimizing page locations. When we get up to 80M, then we should
>think about it.
Also, it only pull into memory the pages out of the library that you
are actually referencing. If you don't use them, they don't use
any processor memory. The only memory limit you will have will be
how much disk space do you have available (and with $350 disks that
hold 6.2 gigs, this should'nt be a major problem).
If you hall a huge number of widgets in at the same time, in a limited
memory area, then you may see lot's of disk accesses, but not much of it
will be actual swapping to the swap file. It will be reading code
out of image files.
>It's also possible to split the library into pieces. This might help
>somewhat, though with a piddly 10M library, I doubt it's worth the
>effort.
I doubt that splitting the library up will reduce actual memory used
in any significiant way. Virtual memory strikes again.
> Furthermore, we're dealing with harddrive space here as well. a
> 5MB binary is absolutely *******HUGE*******, especially for a
> single component.
>
>Actually, no. 5M is not all that much these days. When you work with
>500M binaries, you're getting up there. (and yes, I'm serious).
>
> If you want to have such huge binaries, please make the switch to
> Windows. They have that sort of thing all the time. I don't want
> it.
>
>Disk is cheap. Linux pages well. What's your concern?
If you have used windows with these large images, you become concerned
because of the poor paging that windows does. When windows really starts
to page, you are really in trouble. Linux pages much much better.
Try running X11 on a 4Mb 386 sometime. Then try Windows95 on 8Mb pentium.
You'll get about the same performance.
> If GTK is going to get much larger than 2MB, I will switch to using
> LibGGI and implementing my own user interface.
>
> Now, I have absolutely NO objections to having a 1MB or so
> libgtk.so file, and having *extensions* to it, a la GGI. That I
> can handle. But having a single, monolithic library that is all
> inclusive is decidedly a Microsoft-ian way of thinking about the
> user interface.
>
>We'd need to bench to be sure, but for small apps, I'd bet that the
>overhead of loading numerous pieces of shared libraries combined with
>the page rounding overhead would likely overshadow any possible wins.
Virtual memory is very confusing, because there are so many different
memory sized you are talking about in the one phrase: Physical
memory = how much is currently residing in core, Virtual size =
how much memory does the program 'span', and Swap size = how much disk
is required to swap out the process. Your swap size is likely
to be much smaller than your virtual size.
However, since it only loads those portions of the libraries that
you are referencing, you shouldn't have too many problems. Where you
need to be concerned is if all of the widgets call each other
excessively, thus pulling all of them into memory at the same time.
I'd still vote on a larger library to reduce the quantity of
re-developed code as much as possible, but maybe place some of the
stanger (rarely used) widgets in an extension library.
-------------------------------------------------------------
Kevin Handy kth@srv.net Accounting Software for
Software Solutions. Inc. VAX/VMS Computer Systems
Idaho Falls, Idaho
From mvo@zagadka.ping.de
Received: (qmail 863 invoked from network); 24 May 1998 23:15:04 -0000
Received: from lilly.ping.de (qmailr@195.37.120.2)
by mail2.redhat.com with SMTP; 24 May 1998 23:15:04 -0000
Received: (qmail 23099 invoked by uid 10); 24 May 1998 23:14:44 -0000
Received: from zagadka.ping.de by lilly.ping.de with UUCP (rmail-0.1-fdc);
24 May 1998 23:14:44 -0000
Received: (qmail 24539 invoked by uid 1000); 24 May 1998 21:36:48 -0000
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: [OFFTOPIC] Re: Proposed widget
References: <Pine.LNX.3.96.980524112749.31124A-100000@topaz.axisinternet.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: Marius Vollmer <mvo@zagadka.ping.de>
Date: 24 May 1998 23:36:48 +0200
In-Reply-To: KC5TJA's message of Sun, 24 May 1998 11:32:02 -0700 (PDT)
Message-ID: <87btsns64v.fsf@zagadka.ping.de>
Lines: 19
X-Mailer: Gnus v5.5/Emacs 20.1
KC5TJA <kc5tja@topaz.axisinternet.com> writes:
> I've yet to see a single reason why an OS MUST have memory protection to
> be general purpose. They keep saying you must have it, but I've yet to
> see proof.
This is not a thing that can be proved.
I for one couldn't work when I wasn't reasonably sure that Netscape
couldn't crash my Emacs with these all important documents in it.
[Yes, I know, Netscape can take down X11 which can lock up the whole
machine, but only because X11 *circumvents* memory protection.]
But the most important reason for memory protection is maybe
protecting multiple users on one system from each other. Without
memory protection, as soon as you can run programs on an unprotected
OS, you can do everything. Reading/writing other peoples files,
everything. And in these days of `active web content', every general
purpose computer is a multi-user system.
From rich@kyoto.noir.com
Received: (qmail 6234 invoked from network); 25 May 1998 01:41:47 -0000
Received: from sendai.vip.best.com (HELO kyoto.noir.com) (rich@204.156.156.216)
by mail2.redhat.com with SMTP; 25 May 1998 01:41:47 -0000
Received: (from rich@localhost)
by kyoto.noir.com (8.8.7/8.8.7) id SAA29556;
Sun, 24 May 1998 18:41:25 -0700
Date: Sun, 24 May 1998 18:41:25 -0700
Message-Id: <199805250141.SAA29556@kyoto.noir.com>
From: "K. Richard Pixley" <rich@kyoto.noir.com>
To: gtk-list@redhat.com
CC: gtk-list@redhat.com
In-reply-to: <Pine.LNX.3.96.980524122634.2956B-100000@topaz.axisinternet.com>
(kc5tja@topaz.axisinternet.com)
Subject: Re: [gtk-list] Re: Proposed widget
References: <Pine.LNX.3.96.980524122634.2956B-100000@topaz.axisinternet.com>
Date: Sun, 24 May 1998 12:33:42 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
> With 5M shared libraries, though, I doubt we'd see much win from
> optimizing page locations. When we get up to 80M, then we should
> think about it.
OK. That, having been said, makes me wonder, "What is a good
cut-off size for GTK, before considering using external modules?"
I agree that that is a key issue. And I don't know the right answer.
My *preference* at the moment, (subject to change momentarily), would
be to divide widgets into tier 1 and tier 2 (and perhaps "etc"). Tier
1 would be basics, often required. Tier 2 would be "anything else" at
this point.
The only real purpose of tier 2 would be to "bless" certain
widgets/modules like, say, (my own current interest), "master volume"
for sound card support.
Such support is not of "high" interest to most graphics apps, yet does
have *some* interest for apps participating in the process of creating
a simple user environment.
If you do include stuff into GTK, there should be some research on
how useful the widget will be.
I agree. And I support using the result of any such research as the
first cutoff criterion between "core" gtk and anything else that might
exist.
GTK currently has rulers, which are godsend for document-based
programs.
And many other apps.
GTK has support for buttons, lists, trees, etc. That I can also
live with, as they have a high frequency of use in common software.
I agree.
Font selector was long overdue. :-) But all possible widgets?
No. I agree with you. Unless "all possible widgets" have all of:
config, build, compilation, library creation, library location, and
app usage, on a per-widget basis, the "gtk" set must be a human choice
based on usability. And, of course, that usability criterion obviates
the possiblity of any system which *requires* configuration at all
these levels. *laugh*
However, I would support an effort which assumed gtk as a basis, and
left usability of widgets as a contest/open-market for widget writers.
In this scenario, it would be up to the gtk maintainers to
choose/elect things like a "master volume" widget, while also having
the freedom to either make it tier 1 or tier 2. This allows for more
comprehensive paradigms to supplant numerous other paradigms; assuming
a responsible set of moderators. :-). It also allows the moderators
the freedom to chose widgets based on the level of support they've
gotten from the widget's authors. etc, etc, etc.
> It's also possible to split the library into pieces. This might help
> somewhat, though with a piddly 10M library, I doubt it's worth the
> effort.
I'd hate to be the person on the other end of a 33.6kbps connection
downloading GTK+-5.0, with its 10MB binary. Imagine the size of
the source code? 8-D OUCH!
Actually, IME, souce is usually smaller than binary. If your reason
for choosing binary format deals with bandwidth, I suspect that I can
offer you some "helper" functions, (via source), which will offer you
better bandwidth for downloading than what you have now.
Similarly, if your concern is about whether the downloading person
*can* compile, then with SRPMS, (etc), I suspect that I can easily
offer you helper functions to cover these concerns.
However, for a 10M file, forget 33.6, assume 56k. Such modems are
*cheap* now, (ie, <$100 each). 10M = 10,000K. 10,000 / 56 = 178
minutes. That's ~3 hours, which I agree is not an interactive
download, but it *is* easily an overnight download.
> Actually, no. 5M is not all that much these days. When you work with
> 500M binaries, you're getting up there. (and yes, I'm serious).
You are sick and evil if you make a program that's 500MB in size... :D
Nope. Just a professional who's currently dealing with hardware
designers who use automatic tools to create their hardware
simulations.
Follow that? (*laugh*) Their simulations eventually amount to C code
which is compiled, then run, on a large pile of regression tests,
(perhaps 5000 tests at ~1hr run time each). The actual, human
generated, source might be less than 2M, produced by ~100 humans
currently employed in this process. And given current configurations,
might take as much as 15 hours to run them all. (*laugh* Yes.
parallel execution. *sigh*).
> Disk is cheap. Linux pages well. What's your concern?
Bloat-ware.
Gotcha. Then I'm on your side. I prefer that there be some division
between "absolutely, positively, needed-in-damned-near-every-app" vs
"would be nice to have some common way of doing this" functionality.
But then, I'm not sure how to make that division just yet. Good thing
I'm not a gtk maintainer, huh? :-).
> We'd need to bench to be sure, but for small apps, I'd bet that the
> overhead of loading numerous pieces of shared libraries combined with
> the page rounding overhead would likely overshadow any possible wins.
Perhaps. Is it possible to use external shared libs with GTK now (instead
of static linking)? I'd imagine so, since shared libraries often look
like static libraries to all parties involved.
Possible? Of course. *Anything* is possible. (smug laugh)
How much effort? Not much, I'd guess. The real work here would be in
deciding where the break point should be and then optimizing code to
exploit the break point.
--rich
From kc5tja@topaz.axisinternet.com
Received: (qmail 30028 invoked from network); 25 May 1998 04:44:59 -0000
Received: from axisinternet.com (HELO topaz.axisinternet.com) (root@207.213.59.10)
by mail2.redhat.com with SMTP; 25 May 1998 04:44:59 -0000
Received: from topaz.axisinternet.com (kc5tja@axisinternet.com [207.213.59.10])
by topaz.axisinternet.com (8.8.5/8.8.5) with SMTP id VAA14124
for <gtk-list@redhat.com>; Sun, 24 May 1998 21:35:23 -0700
Date: Sun, 24 May 1998 21:35:23 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: [OFFTOPIC] Re: Proposed widget
In-Reply-To: <87btsns64v.fsf@zagadka.ping.de>
Message-ID: <Pine.LNX.3.96.980524213248.13654A-100000@topaz.axisinternet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> But the most important reason for memory protection is maybe
> protecting multiple users on one system from each other. Without
> memory protection, as soon as you can run programs on an unprotected
> OS, you can do everything. Reading/writing other peoples files,
> everything. And in these days of `active web content', every general
> purpose computer is a multi-user system.
This is, to date, the only legitamate reason given, and it's an important
one to boot. You present a point of view which I had not taken in the
past (that of active web content). While it is (reasonably) easy for
commercial companies to ensure mostly-bug-free software, such cannot be
said of web applets written by a neophyte or cracker.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
From kc5tja@topaz.axisinternet.com
Received: (qmail 6007 invoked from network); 25 May 1998 04:57:33 -0000
Received: from axisinternet.com (HELO topaz.axisinternet.com) (root@207.213.59.10)
by mail2.redhat.com with SMTP; 25 May 1998 04:57:33 -0000
Received: from topaz.axisinternet.com (kc5tja@axisinternet.com [207.213.59.10])
by topaz.axisinternet.com (8.8.5/8.8.5) with SMTP id VAA15141
for <gtk-list@redhat.com>; Sun, 24 May 1998 21:47:57 -0700
Date: Sun, 24 May 1998 21:47:57 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Proposed widget
In-Reply-To: <199805250141.SAA29556@kyoto.noir.com>
Message-ID: <Pine.LNX.3.96.980524214225.14423A-100000@topaz.axisinternet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> However, for a 10M file, forget 33.6, assume 56k. Such modems are
> *cheap* now, (ie, <$100 each). 10M = 10,000K. 10,000 / 56 = 178
> minutes. That's ~3 hours, which I agree is not an interactive
> download, but it *is* easily an overnight download.
Modems may be cheap. It's the telephone lines you have to watch for. The
reason AxisInternet does not support 56K of any type for its non-dedicated
dial-ups is due to the horrid phone line quality. It is a rare day in
hell when someone can actually connect at 33.6kbps, much less 56K.
However, a dedicated line is different, since we have some control over
line quality at that point. But if you're going through that kind of
expense, it almost makes more sense to go ISDN... :D
> Follow that? (*laugh*) Their simulations eventually amount to C code
> which is compiled, then run, on a large pile of regression tests,
> (perhaps 5000 tests at ~1hr run time each). The actual, human
> generated, source might be less than 2M, produced by ~100 humans
> currently employed in this process. And given current configurations,
> might take as much as 15 hours to run them all. (*laugh* Yes.
> parallel execution. *sigh*).
Damned simulators...somebody ought to teach them a lesson... ;-)
> But then, I'm not sure how to make that division just yet. Good thing
> I'm not a gtk maintainer, huh? :-).
Somebody will find a way; that's garunteed.
> How much effort? Not much, I'd guess. The real work here would be in
> deciding where the break point should be and then optimizing code to
> exploit the break point.
I should try writing my own widget, just to say that I did it. Hell,
everybody ELSE on this list wrote one! :D I wonder what mine would do
though...:D
Anybody familiar with NoWEB or CWEB? What are your impressions of this
'literate programming' package?
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
From nils@rhlx01.rz.fht-esslingen.de
Received: (qmail 14511 invoked from network); 25 May 1998 07:46:12 -0000
Received: from rhlx01.rz.fht-esslingen.de (nils@134.108.34.10)
by mail2.redhat.com with SMTP; 25 May 1998 07:46:12 -0000
Received: from localhost (nils@localhost)
by rhlx01.rz.fht-esslingen.de (8.8.8/8.8.8) with SMTP id JAA21487
for <gtk-list@redhat.com>; Mon, 25 May 1998 09:45:47 +0200
Date: Mon, 25 May 1998 09:45:47 +0200 (CEST)
From: Nils Philippsen <nils@rhlx01.rz.fht-esslingen.de>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: [OFFTOPIC] Re: Proposed widget
In-Reply-To: <Pine.LNX.3.96.980524213248.13654A-100000@topaz.axisinternet.com>
Message-ID: <Pine.LNX.3.96.980525092304.21363A-100000@rhlx01.rz.fht-esslingen.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 24 May 1998, KC5TJA wrote:
> This is, to date, the only legitamate reason given, and it's an important
> one to boot. You present a point of view which I had not taken in the
> past (that of active web content). While it is (reasonably) easy for
> commercial companies to ensure mostly-bug-free software, such cannot be
Well, I don't want to let this end in the next discussion about paradigms of
software development (open source vs. commercial/proprietary), but:
- Every software may contain bugs/glitches. The probability of bugs in a
program increases with its size.
- As of my experience commercial programs are by far larger than open source
developped ones [OFFTOPIC: anyone got comments on the grammar of this
sentence (especially on the syntax since I'm not a native english-
speaker)? Would be nice if you mailed them to me, thanks]
- Well, if it's so easy for THEM (in comparison to US :-) to ensure bug-free
programs, then why don't they do it (e.g. MS-{Windows,Office,...}, Netscape
Navigator, ... suck big time concerning stability)? Of course this
conclusion is based on empirical studies :-)
> said of web applets written by a neophyte or cracker.
For the last one you're comparing apples to pears (as a cracker would violate
memory intentionally this can not be considered a bug - or did you mean a
hacker? Then this doesn't fit - hackers are per definitionem wit enough to
produce no bugs at all :-).
Have a nice day,
Nils
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nils Philippsen @college: nils@rhlx01.rz.fht-esslingen.de
Vogelsangstrasse 115 @home: nils@wombat.dialup.fht-esslingen.de
D 70197 Stuttgart phone: +49-711-6599405
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Wer heute an der Bildung spart, Those who scrimp on education today,
hat morgen noch bloedere Politiker. get even dumber politicians tomorrow.
From lawrence@mail.tne.net.au
Received: (qmail 23128 invoked from network); 25 May 1998 13:35:49 -0000
Received: from smtp.tne.net.au (HELO mail.tne.net.au) (root@203.22.206.5)
by mail2.redhat.com with SMTP; 25 May 1998 13:35:49 -0000
Received: from tne.net.au (lawrence@brandy.alcohol.tne.net.au [203.29.179.6])
by mail.tne.net.au (8.8.8/8.7.3) with ESMTP id XAA17373 for <gtk-list@redhat.com>;
Mon, 25 May 1998 23:05:19 +0930
Sender: lawrence@mail.tne.net.au
Message-ID: <3569F9A8.C361FD0D@tne.net.au>
Date: Mon, 25 May 1998 23:07:20 +0000
From: Lawrence Sim <wanderer@tne.net.au>
Organization: Kick Butt Software
X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.30 i686)
MIME-Version: 1.0
To: gtk-list@redhat.com
Subject: Re: Planner Widget / Perpetual Calendar
References: <19980525043308.16021.rocketmail@send1e.yahoomail.com>
<19980525045956.8729.qmail@mail2.redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Has anyone created a perpetual Calendar widget. As I am creating a
program using gtk+ that needs a Perpetual Calendar. Well the program
already has one, but I am going to finnish it off and turn it into a
widget.
--
Lawrence Sim
http://www.tne.net.au/wanderer/
mailto:lasim@earthling.net
From owt1@cornell.edu
Received: (qmail 9091 invoked from network); 25 May 1998 14:25:38 -0000
Received: from cu-dialup-2008.cit.cornell.edu (mail@132.236.155.142)
by mail2.redhat.com with SMTP; 25 May 1998 14:25:38 -0000
Received: from otaylor by cu-dialup-2008.cit.cornell.edu with local (Exim 1.82 #1)
id 0ydyDT-00076B-00; Mon, 25 May 1998 10:27:07 -0400
To: Lawrence Sim <wanderer@tne.net.au>
Cc: gtk-list@redhat.com
Subject: Re: Planner Widget / Perpetual Calendar
References: <19980525043308.16021.rocketmail@send1e.yahoomail.com>
<19980525045956.8729.qmail@mail2.redhat.com> <3569F9A8.C361FD0D@tne.net.au>
From: Owen Taylor <otaylor@gtk.org>
Date: 25 May 1998 10:27:07 -0400
In-Reply-To: Lawrence Sim's message of Mon, 25 May 1998 23:07:20 +0000
Message-ID: <lzvhqu4e9w.fsf@cu-dialup-1917.cit.cornell.edu>
Lines: 14
X-Mailer: Gnus v5.5/Emacs 20.2
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?=
=?ISO-8859-4?Q?h=F2ji"?=)
Content-Type: text/plain; charset=US-ASCII
Sender: Owen Taylor <owt1@cornell.edu>
Lawrence Sim <wanderer@tne.net.au> writes:
> Has anyone created a perpetual Calendar widget. As I am creating a
> program using gtk+ that needs a Perpetual Calendar. Well the program
> already has one, but I am going to finnish it off and turn it into a
> widget.
Shawn Amundson wrote a calender widget that is currently in
GNOME. It probably will be part of GTK in the future. (Or maybe
in an auxiliary-widgets package, if we go that route)
Regards,
Owen
From mvo@zagadka.ping.de
Received: (qmail 5671 invoked from network); 25 May 1998 17:31:10 -0000
Received: from lilly.ping.de (qmailr@195.37.120.2)
by mail2.redhat.com with SMTP; 25 May 1998 17:31:10 -0000
Received: (qmail 15338 invoked by uid 10); 25 May 1998 17:30:24 -0000
Received: from zagadka.ping.de by lilly.ping.de with UUCP (rmail-0.1-fdc);
25 May 1998 17:30:20 -0000
Received: (qmail 502 invoked by uid 1000); 25 May 1998 08:03:14 -0000
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Proposed widget
References: <Pine.LNX.3.96.980524122634.2956B-100000@topaz.axisinternet.com>
<199805250141.SAA29556@kyoto.noir.com>
Mime-Version: 1.0 (generated by tm-edit 7.106)
Content-Type: text/plain; charset=US-ASCII
From: Marius Vollmer <mvo@zagadka.ping.de>
Date: 25 May 1998 10:03:14 +0200
In-Reply-To: "K. Richard Pixley"'s message of Sun, 24 May 1998 18:41:25 -0700
Message-ID: <87n2c66am5.fsf@zagadka.ping.de>
Lines: 42
X-Mailer: Gnus v5.5/Emacs 20.1
"K. Richard Pixley" <rich@kyoto.noir.com> writes:
> My *preference* at the moment, (subject to change momentarily), would
> be to divide widgets into tier 1 and tier 2 (and perhaps "etc"). Tier
> 1 would be basics, often required. Tier 2 would be "anything else" at
> this point.
One thing we should not overlook is the `matureness' of the widgets.
While I think it would make certain things easier to put everything
into one big library, it would be a huge PITA to have some half-done,
compiles-only-when-you-have-libunreleased0.0.1 widgets break the
compilation of GtkButton.
>From a technical view, and once everything has been installed, I think
it's pretty irrelevent whether the widgets live in one library or in
many. There is already enough infrastructure in place to deal with
`advanced' build rules, i.e gtk-config.
What is needed is a central repository of widgets, so that everybody
can see what is already available, and what is in the works. This
would foster code-reuse, a concentration of efforts and, maybe most
important, a consistent look&feel.
> Nope. Just a professional who's currently dealing with hardware
> designers who use automatic tools to create their hardware
> simulations.
>
> Follow that? (*laugh*) Their simulations eventually amount to C code
> which is compiled, then run, on a large pile of regression tests,
> (perhaps 5000 tests at ~1hr run time each). The actual, human
> generated, source might be less than 2M, produced by ~100 humans
> currently employed in this process. And given current configurations,
> might take as much as 15 hours to run them all. (*laugh* Yes.
> parallel execution. *sigh*).
Yeah, I have been doing something like this for the last half a year.
Simulating a mobile-radio-system on the bit-level. I never looked at
the size of the binaries, but the boxen there all had something like
2GB RAM. There must be a reason for that. Some simulations ran for
about three days. Takes the fun out of hacking, I tell you.
But what can you do?
From kc5tja@topaz.axisinternet.com
Received: (qmail 8435 invoked from network); 25 May 1998 19:53:31 -0000
Received: from axisinternet.com (HELO topaz.axisinternet.com) (root@207.213.59.10)
by mail2.redhat.com with SMTP; 25 May 1998 19:53:31 -0000
Received: from topaz.axisinternet.com (kc5tja@axisinternet.com [207.213.59.10])
by topaz.axisinternet.com (8.8.5/8.8.5) with SMTP id MAA01012
for <gtk-list@redhat.com>; Mon, 25 May 1998 12:48:46 -0700
Date: Mon, 25 May 1998 12:48:46 -0700 (PDT)
From: KC5TJA <kc5tja@topaz.axisinternet.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: [OFFTOPIC] Re: Proposed widget
In-Reply-To: <Pine.LNX.3.96.980525092304.21363A-100000@rhlx01.rz.fht-esslingen.de>
Message-ID: <Pine.LNX.3.96.980525124511.962A-100000@topaz.axisinternet.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
> For the last one you're comparing apples to pears (as a cracker would violate
> memory intentionally this can not be considered a bug - or did you mean a
> hacker? Then this doesn't fit - hackers are per definitionem wit enough to
> produce no bugs at all :-).
I meant what I wrote: crackers are malicious in intent. :)
Also, it is my belief that bigger companies, who write for Windows and
similar OSes, have come to rely on the MMU too much. Namely, they get
lazy, and expect the MMU to "save the day" if something goes awry.
Non-MMU based systems don't have this luxury, so if your company wants to
make money selling software, it had better damn well NOT touch other
people's memory! It doesn't take a rocket scientist to figure out which
app causes a problem when run in conjunction with another. I prefer not
using an MMU for just this reason -- it FORCES the developer to produce
good, reliable code.
==========================================================================
KC5TJA/6 | -| TEAM DOLPHIN |-
DM13 | Samuel A. Falvo II
QRP-L #1447 | http://www.dolphin.openprojects.net
From amundson@gimp.org
Received: (qmail 26361 invoked from network); 26 May 1998 15:23:45 -0000
Received: from graft.xcf.berkeley.edu (HELO wilber.gimp.org) (mail@128.32.43.209)
by mail2.redhat.com with SMTP; 26 May 1998 15:23:45 -0000
Received: from amundson by wilber.gimp.org with local-smtp (Exim 1.92 #1 (Debian))
id 0yeLZi-0004oO-00; Tue, 26 May 1998 08:23:38 -0700
Date: Tue, 26 May 1998 08:23:38 -0700 (PDT)
From: "Shawn T. Amundson" <amundson@gimp.org>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Proposed widget
In-Reply-To: <199805250214.TAA30947@kyoto.noir.com>
Message-ID: <Pine.LNX.3.96.980526074935.16725B-100000@wilber.gimp.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Sun, 24 May 1998, K. Richard Pixley wrote:
> Date: Mon, 25 May 1998 05:42:11 -0400 (EDT)
> From: <nuke@bayside.net>
>
> oh, how about we just take the linux kernel approach- compile a
> very tiny gtk with buttons/tables/boxes and start a "gtk extra
> widget config" :)
>
> Ok by me. And how about, if glib/gdk/gtk is the small bit, we call
> the rest, say, oh, I dunno, how about, gnome?
>
> *laugh*
>
My personal view on this issue is that as many general purpose widgets
as possible should be distributed with the toolkit. Even if widgets
are broken into different libraries or not even compiled in anywhere, the
important issue here is to provide a common set of tools with which
an application programmer can create an interface.
Special cases always exist. For example, we don't want to
distribute gtk-xmhtml with gtk, because gtk-xmhtml is big and must
be kept in sync with the xmhtml author's work. With those things
considered, the maintainability of gtk-xmhtml becomes more like that
of an application than of a simple widget.
To some extent, there is going to be some overlap between things that
could go into gtk and gnome. I think ideally the widgets would be
written for gtk with intent to be independant of gnome and then a gnome
layer would be added to that widget, therefore ensuring compatibility
in look/feel between gtk non-gnome and gnome applications. (And an
easier transition and/or support for gnome.)
Some issues involved in bloating the toolkit are real; for example, we
don't want to make the core library too large or statically linked
applications will become rediculous. On the other hand, I don't think
that size of the resulting distribution file plays a significant role
in the toolkit's usefulness.
These are issues that will probably be addressed during the 1.1.x series
as we collect more general purpose widgets.
--
Shawn T. Amundson
amundson@gimp.org http://www.gimp.org/~amundson
"The assumption that the universe looks the same in every
direction is clearly not true in reality." - Stephen Hawking
From amundson@gimp.org Thu May 11 19:25:10 2000
Received: (qmail 7344 invoked from network); 26 May 1998 15:37:20 -0000
Received: from graft.xcf.berkeley.edu (HELO wilber.gimp.org) (mail@128.32.43.209)
by mail2.redhat.com with SMTP; 26 May 1998 15:37:20 -0000
Received: from amundson by wilber.gimp.org with local-smtp (Exim 1.92 #1 (Debian))
id 0yeLmw-0004u9-00; Tue, 26 May 1998 08:37:18 -0700
Date: Tue, 26 May 1998 08:37:18 -0700 (PDT)
From: "Shawn T. Amundson" <amundson@gimp.org>
To: gtk-list@redhat.com
cc: Lawrence Sim <wanderer@tne.net.au>
Subject: Re: [gtk-list] Re: Planner Widget / Perpetual Calendar
In-Reply-To: <lzvhqu4e9w.fsf@cu-dialup-1917.cit.cornell.edu>
Message-ID: <Pine.LNX.3.96.980526083247.16725C-100000@wilber.gimp.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On 25 May 1998, Owen Taylor wrote:
>
> Lawrence Sim <wanderer@tne.net.au> writes:
>
> > Has anyone created a perpetual Calendar widget. As I am creating a
> > program using gtk+ that needs a Perpetual Calendar. Well the program
> > already has one, but I am going to finnish it off and turn it into a
> > widget.
>
> Shawn Amundson wrote a calender widget that is currently in
> GNOME. It probably will be part of GTK in the future. (Or maybe
> in an auxiliary-widgets package, if we go that route)
>
> Regards,
> Owen
Note that the widget doesn't require GNOME. It is included there
as a convienence for GNOME apps by the GNOME maintainers.
You can get gtkcalendar from:
ftp://ftp.gtk.org/pub/users/amundson/gcalendar-0.5.0.tar.gz
I'm perfectly happy accepting patches to that widget to expand it to
do additional things. ;-)
--
Shawn T. Amundson
amundson@gimp.org http://www.gimp.org/~amundson
"The assumption that the universe looks the same in every
direction is clearly not true in reality." - Stephen Hawking
From zimerman@earthling.net
Received: (qmail 21105 invoked from network); 26 May 1998 21:14:09 -0000
Received: from slip139-92-98-218.tel.il.ibm.net (HELO hexagon.org) (user@139.92.98.218)
by mail2.redhat.com with SMTP; 26 May 1998 21:14:09 -0000
Received: (qmail 578 invoked by uid 500); 26 May 1998 21:15:00 -0000
Message-ID: <19980527001459.30961@hexagon>
Date: Wed, 27 May 1998 00:14:59 +0300
From: Nimrod Zimerman <zimerman@earthling.net>
To: gtk-list@redhat.com
Subject: Adding more widgets to gtk
Mail-Followup-To: gtk-list@redhat.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.89.1i
Hello.
A small issue that has not been mentioned, as far as I've seen.
As it is today, compiling gtk as a whole on a Linux system requires more
than 25mb of free space (probably about 30mb-35mb). This might not seem too
important to most of you out there, but it probably matters to some, and
this is a fairly large penalty. Personally, I have to endlessly fight
whenever I need to compile a new gtk, in order to free up the required space.
Adding additional widgets as additional library/libraries can improve the
situation, by requiring less free space for independent compilations.
(Just imagine the horror I'm going through now, trying to compile gcc 2.8.1.
It is huge, and I don't even have enough free space to extract the
sources!).
Yes, I know HDs are cheap (they aren't, really. Not too cheap). Still.
Nimrod
From owt1@cornell.edu
Received: (qmail 14518 invoked from network); 26 May 1998 22:40:40 -0000
Received: from cu-dialup-2418.cit.cornell.edu (mail@128.253.44.220)
by mail2.redhat.com with SMTP; 26 May 1998 22:40:40 -0000
Received: from otaylor by cu-dialup-2418.cit.cornell.edu with local (Exim 1.82 #1)
id 0yeSRI-0000Bp-00; Tue, 26 May 1998 18:43:24 -0400
To: Nimrod Zimerman <zimerman@earthling.net>
Cc: gtk-list@redhat.com
Subject: Re: Adding more widgets to gtk
References: <19980527001459.30961@hexagon>
From: Owen Taylor <otaylor@gtk.org>
Date: 26 May 1998 18:43:22 -0400
In-Reply-To: Nimrod Zimerman's message of Wed, 27 May 1998 00:14:59 +0300
Message-ID: <lziumsbqlx.fsf@cu-dialup-2005.cit.cornell.edu>
Lines: 36
X-Mailer: Gnus v5.5/Emacs 20.2
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?=
=?ISO-8859-4?Q?h=F2ji"?=)
Content-Type: text/plain; charset=US-ASCII
Sender: Owen Taylor <owt1@cornell.edu>
Nimrod Zimerman <zimerman@earthling.net> writes:
> Hello.
>
> A small issue that has not been mentioned, as far as I've seen.
>
> As it is today, compiling gtk as a whole on a Linux system requires more
> than 25mb of free space (probably about 30mb-35mb). This might not seem too
> important to most of you out there, but it probably matters to some, and
> this is a fairly large penalty. Personally, I have to endlessly fight
> whenever I need to compile a new gtk, in order to free up the required space.
>
> Adding additional widgets as additional library/libraries can improve the
> situation, by requiring less free space for independent compilations.
>
> (Just imagine the horror I'm going through now, trying to compile gcc 2.8.1.
> It is huge, and I don't even have enough free space to extract the
> sources!).
>
> Yes, I know HDs are cheap (they aren't, really. Not too cheap). Still.
If you configure GTK+ with
CFLAGS="-O2 -Wall" ./configure --disable-static
(I.e., no debugging information, and no static libraries), it
will take _much_ less space to compile. (Just under 10M total)
Just the --disable-static will cut the space approximately in
half, with no penalty for most people.
(This probably should be in the README)
Regards,
Owen
From rlb@cs.utexas.edu
Received: (qmail 17512 invoked from network); 26 May 1998 23:54:31 -0000
Received: from mail.cs.utexas.edu (root@128.83.139.10)
by mail2.redhat.com with SMTP; 26 May 1998 23:54:31 -0000
Received: from nevermore.csres.utexas.edu (dial-20-4.ots.utexas.edu [128.83.128.84])
by mail.cs.utexas.edu (8.8.5/8.8.5) with ESMTP id SAA21020
for <gtk-list@redhat.com>; Tue, 26 May 1998 18:54:15 -0500 (CDT)
Received: from rlb by nevermore.csres.utexas.edu with local (Exim 1.92 #1 (Debian))
id 0yeTXk-0003ae-00; Tue, 26 May 1998 18:54:08 -0500
Sender: rlb@cs.utexas.edu
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: [OFFTOPIC] Re: Proposed widget
References: <Pine.LNX.3.96.980525124511.962A-100000@topaz.axisinternet.com>
From: Rob Browning <rlb@cs.utexas.edu>
Date: 26 May 1998 18:54:07 -0500
In-Reply-To: KC5TJA's message of "Mon, 25 May 1998 12:48:46 -0700 (PDT)"
Message-ID: <87solwsi5c.fsf@nevermore.csres.utexas.edu>
Lines: 24
X-Mailer: Gnus v5.6.9/Emacs 20.2
KC5TJA <kc5tja@topaz.axisinternet.com> writes:
> Also, it is my belief that bigger companies, who write for Windows and
> similar OSes, have come to rely on the MMU too much. Namely, they get
> lazy, and expect the MMU to "save the day" if something goes awry.
> Non-MMU based systems don't have this luxury, so if your company wants to
> make money selling software, it had better damn well NOT touch other
> people's memory! It doesn't take a rocket scientist to figure out which
> app causes a problem when run in conjunction with another. I prefer not
> using an MMU for just this reason -- it FORCES the developer to produce
To me, your arguments are the equivalent of saying "take the seatbelts
out of the car because they encourage people to drive unsafely".
With respect to MMUs making programmers lazy, that's what libraries
like electric fence, dmalloc, etc are for. Debug during development,
but have the safety mechanisms on for the user.
I *don't* trust *anyone* else enough to run their programs on my
system without memory protection if have a choice. Why should I?
--
Rob Browning <rlb@cs.utexas.edu>
PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30
From tml@hemuli.tte.vtt.fi
Received: (qmail 29346 invoked from network); 15 Jun 1998 12:02:56 -0000
Received: from mailgw.vtt.fi (130.188.1.6)
by mail2.redhat.com with SMTP; 15 Jun 1998 12:02:56 -0000
Received: from hemuli.tte.vtt.fi (hemuli.tte.vtt.fi [130.188.52.2])
by mailgw.vtt.fi (8.8.8/8.8.8) with ESMTP id PAA11677
for <gtk-list@redhat.com>; Mon, 15 Jun 1998 15:02:55 +0300 (EET DST)
Received: (from tml@localhost)
by hemuli.tte.vtt.fi (8.8.8/8.8.8) id PAA10079;
Mon, 15 Jun 1998 15:02:55 +0300 (EETDST)
From: Tor Lillqvist <tml@hemuli.tte.vtt.fi>
Message-ID: <13701.3438.733823.790230@hemuli.tte.vtt.fi>
Date: Mon, 15 Jun 1998 15:02:54 +0300 (EETDST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: gtk-list@redhat.com
Subject: Excuse me for mentioning the unmentionable, but...
X-Mailer: VM 6.47 under Emacs 19.34.1
X-Face: 1$Duk4X_P]UyB~=O&4jO#\R-iZMZuT9HUOBKXk{|+s+`U}iB"Pc_2zuFd_=poxGtgr
(4t0PkyBR=,[:]9Hoz(I#P7H"{f"[r$W9}WL_0+eLlMrii-HPeK.`JY#6
Surely somebody has thought about the feasibility of, or even tried,
porting gdk and gtk+ to Win32? (I don't mean just using the X11
libraries under Win32, but native Win32 graphics API. No MFC of
course.) What is the biggest problem? The Win32 color model is quite
different from X11's, isn't it? What about keyboard and mouse focus
related differences? If somebody has any helpful hints, or even
partial attempts, I would be grateful for them.... I might try to port
it myself. (Don't hold your breath, I am talking about a timeframe of
half a year at least.)
I assume one would compile and run it using the cygwin32 environment,
so POSIX-specific stuff could be left as is.
(Don't flame me to death, I dislike Microsoft and Windows as much as
most people on this list, I assume. I just happen to have this Minolta
slide/neg scanner which isn't supported by SANE, and would love to be
able to run the GIMP under Windoze. Even without any plug-ins.
Reverse-engineering the scanner's protocol seems tough.)
From bmccoy@lan2wan.com
Received: (qmail 30461 invoked from network); 15 Jun 1998 13:04:23 -0000
Received: from access1.lan2wan.com (bmccoy@205.177.8.10)
by mail2.redhat.com with SMTP; 15 Jun 1998 13:04:23 -0000
Received: (from bmccoy@localhost) by access1.lan2wan.com
(8.8.5/Config By A.D.Simmons) id JAA28839; Mon, 15 Jun 1998 09:21:33 -0400 (EDT)
Date: Mon, 15 Jun 1998 09:21:33 -0400 (EDT)
From: "Brett W. McCoy" <bmccoy@lan2wan.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Excuse me for mentioning the unmentionable, but...
In-Reply-To: <13701.3438.733823.790230@hemuli.tte.vtt.fi>
Message-ID: <Pine.BSI.3.91.980615091934.28608A-100000@access1.lan2wan.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 15 Jun 1998, Tor Lillqvist wrote:
> Surely somebody has thought about the feasibility of, or even tried,
> porting gdk and gtk+ to Win32? (I don't mean just using the X11
> libraries under Win32, but native Win32 graphics API. No MFC of
> course.) What is the biggest problem? The Win32 color model is quite
> different from X11's, isn't it? What about keyboard and mouse focus
> related differences? If somebody has any helpful hints, or even
> partial attempts, I would be grateful for them.... I might try to port
> it myself. (Don't hold your breath, I am talking about a timeframe of
> half a year at least.)
What would be the point, other than making yet another application
framework that wraps around the windows API?
Brett W. McCoy
http://www.lan2wan.com/~bmccoy
-----------------------------------------------------------------------
"The Number of UNIX installations has grown to 10, with more expected."
-- The UNIX Programmer's Manual, 2nd Edition, June, 1972
From pmc@iskon.hr
Received: (qmail 9041 invoked from network); 15 Jun 1998 16:10:19 -0000
Received: from bach.iskon.hr (root@195.29.170.3)
by mail2.redhat.com with SMTP; 15 Jun 1998 16:10:19 -0000
Received: from midgard (dialin002.iskon.hr [195.29.170.142])
by bach.iskon.hr (8.9.0/8.9.0) with SMTP id SAA21079
for <gtk-list@redhat.com>; Mon, 15 Jun 1998 18:08:01 +0200
Message-ID: <000201bd9878$358be520$8eaa1dc3@midgard>
From: "Marin Purgar - PMC" <pmc@iskon.hr>
To: <gtk-list@redhat.com>
Subject: OffTopic: Re: Excuse me for mentioning the unmentionable, but...
Date: Mon, 15 Jun 1998 15:42:03 +0200
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2106.4
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
>On Mon, 15 Jun 1998, Tor Lillqvist wrote:
>
>> Surely somebody has thought about the feasibility of, or even tried,
>> porting gdk and gtk+ to Win32? (I don't mean just using the X11
>> libraries under Win32, but native Win32 graphics API. No MFC of
>> course.) What is the biggest problem? The Win32 color model is quite
>> different from X11's, isn't it? What about keyboard and mouse focus
>> related differences? If somebody has any helpful hints, or even
>> partial attempts, I would be grateful for them.... I might try to port
>> it myself. (Don't hold your breath, I am talking about a timeframe of
>> half a year at least.)
>
>What would be the point, other than making yet another application
>framework that wraps around the windows API?
The point would be allowing people running M$ Win to easly port (and use)
GTK applications.
Are we trying to do the same thing M$ does? Something like: "If you *want*
to run GIMP you *have* to get Linux (or any other *X with GTK)!"
bb4now,
PMC
From sopwith@redhat.com
Received: (qmail 20448 invoked from network); 15 Jun 1998 16:21:23 -0000
Received: from lacrosse.redhat.com (sopwith@207.175.42.154)
by mail2.redhat.com with SMTP; 15 Jun 1998 16:21:23 -0000
Received: from localhost (sopwith@localhost)
by lacrosse.redhat.com (8.8.7/8.8.7) with SMTP id MAA02654
for <gtk-list@redhat.com>; Mon, 15 Jun 1998 12:21:23 -0400
Date: Mon, 15 Jun 1998 12:21:23 -0400 (EDT)
From: Elliot Lee <sopwith@redhat.com>
To: gtk-list@redhat.com
Subject: Re: [gtk-list] OffTopic: Re: Excuse me for mentioning the unmentionable, but...
In-Reply-To: <000201bd9878$358be520$8eaa1dc3@midgard>
Message-ID: <Pine.LNX.3.96.980615121852.32145J-100000@lacrosse.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Mon, 15 Jun 1998, Marin Purgar - PMC wrote:
> The point would be allowing people running M$ Win to easly port (and use)
> GTK applications.
>
> Are we trying to do the same thing M$ does? Something like: "If you *want*
> to run GIMP you *have* to get Linux (or any other *X with GTK)!"
The port of gtk+ to MS Windows is Somebody Else's Problem. Should you wish
to make it your problem, that'd be cool, but I think most of the People
Who Code would rather work on worthwhile stuff (i.e. enhancing gtk+ to be
cooler) than worry about porting it to a fundamentally broken OS.
-- Elliot
When I die, I want to die peacefully in my sleep like my grandfather...
...not yelling and screaming like the people in the back of the
plane he was flying.
From amundson@gimp.org
Received: (qmail 18683 invoked from network); 15 Jun 1998 20:39:27 -0000
Received: from graft.xcf.berkeley.edu (HELO wilber.gimp.org) (mail@128.32.43.209)
by mail2.redhat.com with SMTP; 15 Jun 1998 20:39:27 -0000
Received: from amundson by wilber.gimp.org with local-smtp (Exim 1.92 #1 (Debian))
id 0ylg2D-0000Ei-00; Mon, 15 Jun 1998 13:39:21 -0700
Date: Mon, 15 Jun 1998 13:39:21 -0700 (PDT)
From: "Shawn T. Amundson" <amundson@gimp.org>
To: gtk-list@redhat.com
Subject: GDK on Win32!!!
Message-ID: <Pine.LNX.3.96.980615132533.249B-100000@wilber.gimp.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
I doubt any of the current main developers is going to waste
time on such a project.
Please discontinue debating the merits of such a thing. If
any of you felt strongly enough to do the port, you probably
would be coding and not debating. If you are coding on it
then we can set up another mailing list I'm sure.
If someone wanted to do a Win32 version of GIMP, I think they
would be best to help seperate out core from GUI and writing
the GUI in Win32's system toolkit.
Thanks,
-Shawn
--
Shawn T. Amundson
amundson@gimp.org http://www.gimp.org/~amundson
"The assumption that the universe looks the same in every
direction is clearly not true in reality." - Stephen Hawking
From tml@hemuli.tte.vtt.fi
Received: (qmail 12689 invoked from network); 16 Jun 1998 08:11:48 -0000
Received: from mailgw.vtt.fi (130.188.1.6)
by mail2.redhat.com with SMTP; 16 Jun 1998 08:11:48 -0000
Received: from hemuli.tte.vtt.fi (hemuli.tte.vtt.fi [130.188.52.2])
by mailgw.vtt.fi (8.8.8/8.8.8) with ESMTP id LAA22160
for <gtk-list@redhat.com>; Tue, 16 Jun 1998 11:11:46 +0300 (EET DST)
Received: (from tml@localhost)
by hemuli.tte.vtt.fi (8.8.8/8.8.8) id LAA05815;
Tue, 16 Jun 1998 11:11:46 +0300 (EETDST)
From: Tor Lillqvist <tml@hemuli.tte.vtt.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <13702.10434.208429.945232@hemuli.tte.vtt.fi>
Date: Tue, 16 Jun 1998 11:11:46 +0300 (EETDST)
To: gtk-list@redhat.com
Subject: [gtk-list] Re: OffTopic: Re: Excuse me for mentioning the unmentionable, but...
In-Reply-To: <Pine.LNX.3.96.980615121852.32145J-100000@lacrosse.redhat.com>
References: <000201bd9878$358be520$8eaa1dc3@midgard>
<Pine.LNX.3.96.980615121852.32145J-100000@lacrosse.redhat.com>
X-Mailer: VM 6.47 under Emacs 19.34.1
X-Face: 1$Duk4X_P]UyB~=O&4jO#\R-iZMZuT9HUOBKXk{|+s+`U}iB"Pc_2zuFd_=poxGtgr
(4t0PkyBR=,[:]9Hoz(I#P7H"{f"[r$W9}WL_0+eLlMrii-HPeK.`JY#6
Elliot Lee writes:
> On Mon, 15 Jun 1998, Marin Purgar - PMC wrote:
> The port of gtk+ to MS Windows is Somebody Else's Problem. Should you wish
> to make it your problem, that'd be cool, but I think most of the People
> Who Code would rather work on worthwhile stuff (i.e. enhancing gtk+ to be
> cooler) than worry about porting it to a fundamentally broken OS.
Sure. I wasn't suggesting that the People Who Code gtk+ would need to
have anything to do with it. One can only wish, though, that *if* a
gdk and gtk+ port to Win32 gets under way, they approve of including
the diffs in the main gtk+ source repository (I know, sprinkling code
with #ifdefs isn't going to look nice, but hopefully those will mostly
show up just in gdk.). Surely we don't need a split of the gtk+
sources into a version with Win32 #ifdefs and one without.
If gtk+ is (continues to be) well written, modular, well layered etc
(is it?), the Win32 stuff should be visible only in the lower layers,
shouldn't it?
--tml
From jlarsen@PIRL.LPL.Arizona.EDU
Received: (qmail 30687 invoked from network); 20 Jun 1998 05:33:03 -0000
Received: from pirl.lpl.arizona.edu (128.196.64.7)
by mail2.redhat.com with SMTP; 20 Jun 1998 05:33:03 -0000
Received: from vanbiesbroeck.PIRL (vanbiesbroeck.LPL.Arizona.EDU [128.196.64.216])
by pirl.lpl.arizona.edu (8.7.1/8.7.3) with SMTP id WAA22384 for <gtk-list@redhat.com>;
Fri, 19 Jun 1998 22:33:01 -0700 (MST)
Received: by vanbiesbroeck.PIRL (SMI-8.6/SMI-SVR4)
id WAA25489; Fri, 19 Jun 1998 22:32:59 -0700
From: jlarsen@PIRL.LPL.Arizona.EDU (Jeffrey Larsen)
Message-Id: <199806200532.WAA25489@vanbiesbroeck.PIRL>
Subject: Xwindow as GTK Widget
To: gtk-list@redhat.com
Date: Fri, 19 Jun 98 22:32:58 MST
X-Mailer: ELM [version 2.3 PL11]
I'm trying to use GTK to wrap our project's real-time asteroid
detection code. One problem I can't solve though...
Our incoming pixel data is displayed on an X window using an
astronomical graphics subroutine library I don't want to mess
with. I would like the X window to be responsive to GTK events
(in particular mouse clicks). I have the Xdisplay and Xwindow
ID's for the X window but can't see how to turn this into a usable
GTK widget. How can one do this?
I've examined gdkx.h and I'm still in the dark. Help?
Regards,
Jeff
---------------------------------------------------------------------------
Dr. Jeffrey Larsen jlarsen@lpl.arizona.edu
Spacewatch Project Telephone: (520) 621-3384
Lunar and Planetary Laboratory FAX: (520) 621-1940
University of Arizona
Tucson, Arizona 85721
"Whether they ever find life there or not, I think Jupiter should be
considered an enemy planet."
-- Jack Handey (Saturday Night Live)
---------------------------------------------------------------------------
From owt1@cornell.edu
Received: (qmail 6961 invoked from network); 20 Jun 1998 23:25:17 -0000
Received: from cu-dialup-1219.cit.cornell.edu (mail@132.236.155.193)
by mail2.redhat.com with SMTP; 20 Jun 1998 23:25:17 -0000
Received: from otaylor by cu-dialup-1219.cit.cornell.edu with local (Exim 1.82 #1)
id 0ynX3C-0006fL-00; Sat, 20 Jun 1998 19:28:02 -0400
To: jlarsen@PIRL.LPL.Arizona.EDU (Jeffrey Larsen)
Cc: gtk-list@redhat.com
Subject: Re: Xwindow as GTK Widget
References: <199806200532.WAA25489@vanbiesbroeck.PIRL>
From: Owen Taylor <otaylor@gtk.org>
Date: 20 Jun 1998 19:28:02 -0400
In-Reply-To: jlarsen@PIRL.LPL.Arizona.EDU's message of Fri, 19 Jun 98 22:32:58 MST
Message-ID: <lzbtrnzm9p.fsf@cu-dialup-1219.cit.cornell.edu>
Lines: 61
X-Mailer: Gnus v5.5/Emacs 20.2
X-Emacs: Emacs 20.2, MULE 3.0 (MOMIJINOGA)
MIME-Version: 1.0 (generated by SEMI MIME-Edit 0.98 - =?ISO-8859-4?Q?"D=F2?=
=?ISO-8859-4?Q?h=F2ji"?=)
Content-Type: text/plain; charset=US-ASCII
Sender: Owen Taylor <owt1@cornell.edu>
jlarsen@PIRL.LPL.Arizona.EDU (Jeffrey Larsen) writes:
> I'm trying to use GTK to wrap our project's real-time asteroid
> detection code. One problem I can't solve though...
>
> Our incoming pixel data is displayed on an X window using an
> astronomical graphics subroutine library I don't want to mess
> with. I would like the X window to be responsive to GTK events
> (in particular mouse clicks). I have the Xdisplay and Xwindow
> ID's for the X window but can't see how to turn this into a usable
> GTK widget. How can one do this?
>
> I've examined gdkx.h and I'm still in the dark. Help?
>
> Regards,
>
> Jeff
It isn't an easy task, and probably can't be done exactly with
writing a small amount of fairly low-level code.
It, to some extent, depends on exactly what the graphics library
needs to do. If the graphics library only needs to draw into
an X window, and you can control which X window it draws into,
then the easy thing to do, is to have it draw into a
GdkDrawingArea. (You can get the X window ID with
GDK_WINDOW_XWINDOW (drawing_area->window), after the window
is realized)
If, however, library is doing more complicated interactions with
X, then it is probably best to give the library its on
separate connect to X. (Display *), either as Jay described, or
possibly in a separate process.
Then, here's how I would set things up:
- I would create a new "Overlay" widget, which is a container
with one child; this widget covers the child window with
a InputOnly window so that it traps all user input to the
child.
This widget could be derived from GtkEventBox - it would
just involve overriding the realize routine.
- Then, as a child of this widget, I would use a Socket widget
from the Plug/Socket widgets.
ftp://ftp.gtk.org/pub/users/otaylor/plugsocket-0.3.tar.gz
Then you can just call
gtk_socket_steal (GTK_SOCKET(socket), window_id);
The first step is probably a bit scary sounding, but actually
should be pretty straightforward. Let me know if you need some
help figuring it out.
Regards,
Owen
From DAChaplin@email.msn.com
Received: (qmail 5732 invoked from network); 28 Jun 1998 11:18:15 -0000
Received: from smtp.email.msn.com (HELO UPIMSSMTPUSR06) (207.68.143.178)
by mail2.redhat.com with SMTP; 28 Jun 1998 11:18:15 -0000
Received: from default - 193.149.84.28 by email.msn.com with Microsoft SMTPSVC;
Sun, 28 Jun 1998 04:17:58 -0700
From: "Damon Chaplin" <DAChaplin@email.msn.com>
To: "GTK List" <gtk-list@redhat.com>
Subject: Data-bound widgets?
Date: Sun, 28 Jun 1998 12:20:06 +0100
Message-ID: <000101bda286$b40fe5a0$1c5495c1@default>
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
Return-Path: DAChaplin@email.msn.com
Hi,
Is anyone working on anything like data-bound widgets? - to make
it easy to write simple GTK apps which connect to PostgreSQL or mSQL?
I think it would be a very useful addition (I want to add them to
Glade!), though I'm not sure how difficult they would be to do.
Damon
From msf@redhat.com
Received: (qmail 6677 invoked from network); 30 Jun 1998 16:27:05 -0000
Received: from lacrosse.redhat.com (root@207.175.42.154)
by mail2.redhat.com with SMTP; 30 Jun 1998 16:27:05 -0000
Received: from majestic.labs.redhat.com (root@majestic.labs.redhat.com [207.175.45.4])
by lacrosse.redhat.com (8.8.7/8.8.7) with ESMTP id MAA19813
for <gtk-list@redhat.com>; Tue, 30 Jun 1998 12:27:04 -0400
Received: from majestic.labs.redhat.com (msf@localhost [127.0.0.1])
by majestic.labs.redhat.com (8.8.7/8.8.7) with ESMTP id MAA07472
for <gtk-list@redhat.com>; Tue, 30 Jun 1998 12:27:10 -0400
Message-Id: <199806301627.MAA07472@majestic.labs.redhat.com>
X-Mailer: exmh version 2.0.2
To: gtk-list@redhat.com
Subject: Re: [gtk-list] Re: Data-bound widgets?
In-Reply-To: Your message of "Tue, 30 Jun 1998 10:54:39 +0200."
<199806300854.KAA15677@loki.gams.co.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 30 Jun 1998 12:27:10 -0400
From: Michael Fulbright <msf@redhat.com>
Hi,
Marc Ewing and I at the RHAD Labs (www.labs.redhat.com) were discussing
writing a scaled down MS Access type frontend for SQL databases, and your
post on the gtk-list about an ODBC interface for gtk sounded very interesting.
Since we haven't started working on this project yet, perhaps you
could give me a little info on what you're working on, and what you know
about other projects related to a GUI frontend for databases.
We were inspired to start a project because we have several marketing/sales
types at Red Hat who need a program like 'File Maker Pro' on their old
macintoshes. If work has already started on this type of project we would
like to know...
Thanks
Dr Mike
msf@redhat.com