Re: Signal handlers: parameter names
- From: Diego Zuccato <cssl geocities com>
- To: Padraig O'Briain <Padraig Obriain Sun COM>
- Cc: jmargaglione yahoo com, timj gtk org, gtk-devel-list gnome org
- Subject: Re: Signal handlers: parameter names
- Date: Tue, 13 Mar 2001 11:41:28 +0100
Padraig O'Briain wrote:
> > Then, why don't you use an XML file that describes them ? So :
> > 0) no runtime penalty, except at startup (scan the XML file once and
> > build tables in memory)
> Startup costs are not insignificant. Perception of performance is probably more
> important than the results of any benchmark you run and perception of
> performance is very heavily influenced by startup time.
Well, I know. One of my programs needs to run some slow queries (about
4-5 sec on a P120) on a database.
So I just draw a dialog with a jumping penguin ASAP. The penguin keeps
jumping while I read the db. :-)
This way the user can see that SOMETHING is happening. But these are
simple tricks to "fool" the users.
There are many ways you could speed up parsing a rarely-modified file...
one for all: parse it JUST after it's modified, and store a binary-image
of the structs you parsed to. Reading it takes just some ns (a malloc
and a call to read() ) more than having it statically linked, compiling
it could take a bit longer, but you could use an externale "compiler" if
a trick like my dialog is not enough...
> > 2) it could be auto-generated from source scanning (like docs)
> > 3) adding support for new widgets from 3rd party libraries (for example
> > GtkExtra) becomes quite easy
These two are (IMVHO) the most missing features of tools like glade:
when a new (version of a) toolkit is released, it requires a lot of work
from the GUI editor author to support it...
BYtE,
Diego.
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]