Re: [gtk-list] Re: Proposed widget

[<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" :)

>    > 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
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null
> 

 _        _  __     __             _ _                                  _
|        / |/ /_ __/ /_____         |       Nuke Skyjumper               |
|       /    / // /  '_/ -_)        |         "Master of the Farce"      |
|_     /_/|_/\_,_/_/\_\\__/        _|_           nuke@bayside.net       _|