Boost logo

Boost :

Subject: Re: [boost] [gui] Help with a little experiment.
From: pavel (paul.cpprules_at_[hidden])
Date: 2011-06-20 12:25:31


 German wrote on Sunday, June 19, 2011 at 21:31:01:
>> - A library for designing dialogs and forms
>> - A library for specifying bindings between the interface and the
>> application's data (or creating a view of it).

> I think I will start by these two fundamental libraries on top of gtk.

> I want that the specification of the gui can directly be embedded in C++
> at compile time and that signals and bindings can also be given at
> runtime by name.

perhaps my opinion is biased by qt framework influence but it's a
very mature product with 15 years of development history so i think
they know what they are doing

i think it's a mistake to try to do everything at compile time

let's say half of the time the gui elements are dynamic in runtime
sense

so the compile-time-magic code would be used only roughly in 50% of
cases while the runtime api should be there anyway

once you start speaking about model-view-controller and variations you
should drop the static (i.e. compile time) thing because the model,
for instance, may be changed not only from the "gui end" but from some
other place (e.g. from a non-gui-message handler) and the view may or
may not be notified of this change and everything is setup at runtime
in non trivial case

i can't imagine a compile time code that will manage all the combined
cases which may appear

so my point is that primarily you should provide the "runtime" api
rather than try to make a compile time dsel or the like (which means,
yes, inheritance, virtual functions etc.)

sorry for lengthy message, i hope you got my point

but let me add that for me a portable gui library should be that with
"qt spirit" which is, in fact, qt itself

-- 
Pavel
P.S.
if you notice a grammar mistake or weird phrasing in my message
please point it out

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk