public inbox for rhdb@sourceware.org
 help / color / mirror / Atom feed
From: Brett Schwarz <brett_schwarz@yahoo.com>
To: Fernando Nasser <fnasser@redhat.com>
Cc: rhdb@sources.redhat.com
Subject: Re: rhdb-admin
Date: Wed, 23 Oct 2002 13:14:00 -0000	[thread overview]
Message-ID: <1035404052.6559.110.camel@thor> (raw)
In-Reply-To: <3DB6FCDE.2030901@redhat.com>

On Wed, 2002-10-23 at 12:47, Fernando Nasser wrote:
> Brett Schwarz wrote:

> 
> > 2) To load Itcl, Itk, and Iwidgets, you only need to do package require
> > Iwidgets ... it loads Itk, and Itcl as well...
> > 
> 
> Any harm in leaving them there?  The packages should all be loaded very
> early in the execution anyway and having the explicit require better
> documents things. Besides we may depend on a specific version of some
> of these packages one day.
> 

No, there is no harm. The package command won't load them again, if they
are already loaded, so there is no performance hit...

> 
> > 3) You also gain some by packing widgets together that have the same
> > pack options.
> > 
> 
> I do have the feeling that we have too many packages.  Maybe it is a
> good idea to simplify this for next version.

I was actually talking about the 'pack' geometry manager. For example,
if you have several widgets being packed:

    pack .w1
    pack .w2
    pack .w3
    pack .w4

This can be done as:
    pack .w1 .w2 .w3 .w4

If all of the pack options are the same (i.e. -side, -expand, etc). 

Even if one widget differs, it still might be advantageous to do:
    pack .w1
    pack .w2
    pack .w3
    pack .w4

    pack configure .w2 -fill both


As far as packages go, you might want to look into tclIndex instead of
using the package mechanism for internal "packages". The one advantage
is that it "loads on demand", so presumably, your startup time will be
less, and then you just take small incremental hits during interaction
with the user. However, it is a little more maintenance, since you have
to create the tclIndex file whenever you add/remove a proc/method/etc.
This is something you might want to investigate...might not make a
difference for this app...

> 
> > 4) In some of the classes, the Itcl commands are not fully qualified,
> > and rhdb-admin doesn't even startup. I just added namespace import
> > ::itcl::* to make it work, but maybe a better idea is to fully qualify
> > the Itcl commands, unless you know for sure there won't be any name
> > clashing. (I think the one I remember was configbody in
> > NewDisjointListBoxWidget class)
> > 
> 
> We fixed this already and will be checking this and a few other things in
> cvs soon.  I run into this problem myself when I upgraded my version of
> itcl/iwidgets.
> 

Cool...


Thanks,

    --brett

-- 
Brett Schwarz
brett_schwarz AT yahoo.com

      reply	other threads:[~2002-10-23 20:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-23 11:20 rhdb-admin Brett Schwarz
2002-10-23 12:47 ` rhdb-admin Fernando Nasser
2002-10-23 13:14   ` Brett Schwarz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1035404052.6559.110.camel@thor \
    --to=brett_schwarz@yahoo.com \
    --cc=fnasser@redhat.com \
    --cc=rhdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).