Re: [paragui-users] Puzzled newbie question

[Andrew Ford]

--- Alexander Pipelka <address@hidden> wrote:

> I think the overhead isn't too bad because it is a
> very responsive gui.
> But you're right: things could be faster.

A common opinion I find is that a certain level is
"fast enough" and people can't use anything faster.  I
don't find that very convincing though.  I think it's
more a case of people not being able to quantify the
quickness after a point.
  If you look at quake or other fpses, for example,
players notice that the play is smoother with
high-framerates.  People have a high-capacity for
timing things when they can foresee them, like moving
a mouse over a button and clicking it.  I figure that
that means it's always worth it to make it quicker
because it will give the gui a better "feel". 
Besides, asynchronous communication between widgets
through the event queue may not be the best fit with
double-buffered frame-by-frame renderers where
everyone seems to draw a frame at every pass through
the event loop.  The change to libsig++ should be cool
:)

> But i just asked myself if it's neccessary to use
> mutices at all!
> Considering the eventqueue is thread-safe there is
> no need for a lock
> because there will be exactly one event at once.
> 
> If the user want's to pump events to the queue from
> different threads
> the user should introduce something like a
> queue-lock.
> 

Pushing thread safety onto the user is the easy to
handle it, heheh.
  I've been thinking about reference counting so I
thought I'd talk about it a bit and get any thoughts. 
Introducing such a thing is definately a paragui2
thing (or paragui-3000 for the pythonistas).  It's a
bigger change than going with libsig++...

If we use reference counting, then either:
- It's non-destructive when the count goes to zero
because of a possible external reference (such as a
regular pointer to a widget or a locally declared
widget in user code), the user could still get a
reference count in this case to see if it's ready to
go away yet.  Alternatively, the widget knows how to
remove itself from all referers on explicit delete
(doable).
- It's destructive when the reference count goes to
zero, which is the usual case for reference counters
as far as I know.  In this case, standard pointers and
local declarations become either illegal or unsafe for
user code.  It can be made illegal to get a pointer or
local declaration by forcing the use of an abstract
factory for widgets (which, incidently, could handle
any registrations in whatever on creation). 
Basically, you would call the factory create<
whateverWidgetType >() and get a reference-counted
smart-pointer-style object back to reference it. 
While the user holds the reference, we are guaranteed
that the widet is still around in the library. 
References can be more flexible and are definately
safer to work with than pointers to objects.
  In the case where it's not illegal use a
non-reference for a widget it becomes unsafe.  In this
case paragui assumes ownership of all widgets on
creation and the user uses any non-references to
widgets at his own risk (since he knows what paragui
is doing, this can be manageable).  We can still make
it easy for him to get a reference, so it's not so
bad.  For instance, PG_Widget::operator*() could
return a counted-reference...
  The funny thing about reference counting for paragui
is that the benefit will pretty much only be on the
user's side, I think.  Inside paragui every widget can
have only one parent/owner, either its actual parent
or the single central PG_Application object.  Paragui
always knows what's going on with the widget
internally since ownership is always hierarchial. 
Using reference counting, or giving the users the
option of using it makes it safer for them to use in
their applications when they're trying to delete it in
one thread and and access it in another or inside
paragui.  Reference counting or smart-pointers can
even give the user the option of safely getting rid of
the widget "right now", invalidating all references to
it.
So, some options:

Plan A (pie in the sky, almost totally unrealistic):
  Either templatize PG_Application with objects
implementing any desired policies or have a
"PG_Policy" class, i.e. PG_Application<
referenceCheckingCodeObject,
referenceThreadingCodeObject,
referenceCountingPolicyObject, memoryAllocatorObject,
debugChecksObject, abstractSomethingElseObject,
etc...>
The user wouldn't have to see this unless he needed
custom behaviour since we would have default policy
objects and a typedef to a standard name, like how
string is typedefed from basic_string< char >.
With proper decoupling and other buzzwords applied to
things that don't need to know about the policies,
most of the code would stay out of the headers and
would be precompiled.

cons:  Massive rewrite required, lots of user-code
changes for those who want to upgrade to the new
version, lots of code will inevitably end up in the
headers which may make for slow compilations (I think
it would be manageable).  Difficult.

pros:  Library could be extremely customizable at
application compile-time.  In fact, it could be
customizable enough to be very cool.  Would ensure
entry of our names into the annals of C++ bad-assdom. 
Chicks would dig us because it would be so pleasant to
set the library up the way you need it...

Plan B (more realistic):
  Use reference counting both internally and
externally as discussed above.  Lots of ways of doing
it, we could even give the user the option of deciding
what counting policies he wants at compile time by
abstracting the reference counter for the rest of the
library and letting the user instantiate some
sub-class of a base-counter used in the library.

cons:  Have to implement it.  Other cons according to
the actual scheme chosen.

pros:  Should benefit the user, could be a good and
realistic solution and may make the library easier to
use, especially in larger-scale apps.

Plan C (easiest):
Don't reference count, let the user handle his end of
the application.

cons:  doesn't assist the user at all.  The user has
to know what's going on inside the library and who
exactly owns and is referencing widgets at what time.

pros: easy since it's the status quo.

So, if anybody has actually read down this far, does
anybody have any thoughts?  Did I get something wrong?

Andrew.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - your guide to health and wellness
http://health.yahoo.com