Re: [paragui-users] Puzzled newbie question

[Alexander Pipelka]

Am Don, 2002-05-02 um 19.52 schrieb 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
> :)

I'm just trying to eliminate all event functions that are based upon
this design. These will be replaced by sigc signals. But I think some of
these event handlers are quite convenient (like eventKeyXXX) which
enables any widget to react on key events individually. Nevertheless
this design causes performance loss. Maybe a better solution will be
found.

<snipped large block of text after reading an trying to understand :))>

The factory design is an approach that came into my mind after
rethinking the XML layout stuff. Such a design would enable any widget
(even custom user widgets) to handle XML layout loading (without a
static layout loader).

> 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...

The implications sound very very cool,..
But one template parameter is missing: "backendRenderObject" :))

> 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.

This one sounds manageable to me. Combined with a factory for
dynamically creating objects and transparent XML layout handling this
could be a doable way that wouldn't take lifetime to implement :))

Maybe a simple combination of A & B could also be doable (e.g. just for
refcounting, factory).

> 
> 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.

Disagree. I have to use up my spare time :))

Alex