[paragui-users] Paragui redesign

[Andrew Ford]

I'm glad you like it.  I think the possibilities are
really cool too.  I was thinking about it again, and I
think that event if things like the backend,
allocation, and reference types were templatized and
instantiated at compile time that it would be easy to
decouple it from the paragui internals by using
interface functions that would be generated at
compile-time, via virtual functions in a
non-templatized base-class.  It seems like some people
are doing commercial development with paragui, but
they haven't given their opinions.  It's too bad there
isn't more participation, because changes like these
are are going to be a big-deal to people developing
with the library, and more people putting their heads
together right now while it's being designed will
really help.      Anyway Alex, what are the plans for
the XML layout and how does it interact with a
widget-factory?  I haven't even used the layout engine
yet.

Andrew.

--- Alexander Pipelka <address@hidden> wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> paragui-users mailing list
> address@hidden
>
http://mail.freesoftware.fsf.org/mailman/listinfo/paragui-users


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