Re: [gtk-list] Re: Proposed widget

["K. Richard Pixley" <rich kyoto noir 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