On Fri, Mar 13, 2009 at 11:07 AM, Richard Dale <[email protected]> wrote:
> On Thu, Mar 12, 2009 at 11:25 AM, Koen Deforche <[email protected]> wrote:
>> Hey Pau,
>>
>> 2009/3/12 Pau Garcia i Quiles <[email protected]>:
>>> On Wed, Mar 11, 2009 at 11:45 AM, Koen Deforche <[email protected]> wrote:
>>>> Hey Pau,
>>>>
>>>> 2009/3/9 Pau Garcia i Quiles <[email protected]>:
>>>>> Hello,
>>>>>
>>>>> I have two requests:
>>>>> - Properties (like Q_PROPERTY)
>>>>
>>>> I can understand why that would be useful, but since you ask, do you
>>>> see a way of achieving this without a 'moc' ?
>>>
>>> I have the feeling boost::proto may work but I'm not 100% sure.
>>>
>>>>> - A keyword to indicate we want a class' implementation to be
>>>>> generated by Wt on the client-side instead of C++ code generated
>>>>> server-side. That would make my life easier with WWizard (which is
>>>>> stagnating in gitorious for now :-( )
>>>>
>>>> I'm not sure I understand, but you would like Wt to generate a
>>>> JavaScript 'class' ?
>>>
>>> Yes, something like that. Something which allows lazy evaluation (i.
>>> e. at run-time, not at compile-time).
>>
>> I have been reading about it, and I can see that boost::proto could in
>> principle allow this.
>> It seems its compiler support is not very good though (e.g. Sun Studio
>> is not listed), so we would have to see if this is a fundamental
>> problem or simply lack of interest.
>>
>> This would allow us to generalize the stateless slot learning also for
>> 'stateful' slots, e.g. slot methods that use function arguments.
>>
>> Then the idea would be to define to prototype evaluation contexts, one
>> is native C++ evaluation, and the other is a JavaScript context that
>> generates a JavaScript script.
>>
>> It sounds quite funky, I am not sure how many problems you would run
>> into before you get something working :-)
>>
>> This is what you are getting at ?
> Personally I don't think properties should be added unless there is a
> specific use case. For instance, a Qt Designer-like visual tool for
> interface design is the most likely use. Would boost::proto help with
> implementing that? Is a tool like that better written in Java or Ruby
> where we already have full introspection over the whole Wt api?

IMHO we do not need to start a new tool: we can just take Qt Designer,
remove the Qt widgets plugin and add a Wt widgets plugin. We would
then write a uic-like tool (wuic being the obvious name :-) which
translates the .ui file to Wt code.

Having properties would certainly help in that regard. Another feature
present in Qt Designer which we would not be able to use directly is
signal-slot autoconnection. I personally don't care about signal-slot
autoconnection (I think I've never used that in Qt) but properties are
convenient. But anyways, none of those features are actually required:
by making wuic a bit more intelligent, it could translate all that
into code.

> It seems to me there are two camps of Wt users - those that think it
> is really good because it uses boost, and those that think it is
> really good in spite of using boost. I'm the latter sort, and so
> becoming more dependent on esoteric boost features is a bit of a turn
> off.

I also belong to the "in spite of using boost" group but some features
require that Wt either uses esoteric parts of Boost, or creates its on
"woc" tool.

-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest

Reply via email to