[boost] Re: Re: Re: Java style GUI in C++

From: Edward Diener (eddielee_at_[hidden])
Date: 2004-08-23 19:47:06

John Torjo wrote:
> Edward Diener wrote:
>> John Torjo wrote:
>>
>>> .
>>>
>>>>
>>>> Borland's C++ Builder was very nice, but of course it wasn't
>>>> standard C++.
>>>
>>> True.
>>>
>>>
>>>> VC++ Managed C++ .NET is very nice but it is even further away from
>>>> standard C++. In neither do you have to write hundreds of lines of
>>>> code to do any GUI programming of significance. In order to have a
>>>> really top-rate C++ GUI library I believe one needs reflection in
>>>> C++ in order to do the sort of
>>>
>>> Not true. It would be great if you had reflection, but it's not a
>>> necessity.
>>>
>>> I'll show you (in about 3-4 months) that you don't need reflection
>>> to set GUI properties at design time. It'll be just like VB, but
>>> only better ;)
>>
>>
>> I am very interested in this and would like very much to see how you
>> will do this at design time. In particular I am interested in how
>> event handlers can be set at design time. All without C++ reflection
>> of course and using strictly the C++ standard, since you are
>> confident that this can be done. My
>
> You can emulate "design time". This is what both C++ Builder/ .Net do.
> You set an event at design time, but behind the scenes, a new event
> handler is created.

That is true, but there is the ability to create properties and event
handlers before the program is running in a visual design time environment.
That is why I believe one needs reflection in C++ in order to do this. While
you are right that the design time environment is able to write code in
files in order to create the handler, which the programmer will then fill in
himself with whatever functionality he chooses, there is more to it. The
design time environment must also hook the event handler to the event when
the objects encapsulating the event and the event handler are created at
run-time. In C++ Builder this is done by actually writing strings to a
resource file, which afterward gets read in at run-time and, through
reflection implemented as an extension to C++, the event handler and the
event source are hooked together. In .NET, whose inner workings I understand
less, I am pretty sure the same technique is being used but with .NET
attributes holding special information which then works at run-time to hook
handlers to events via delegation. Delegation is built into the .NET
run-time as is reflection. Without run-time reflection in .NET I doubt this
can be done, but I could be wrong.

I know much can be done through boilerplate code, so it is possible that all
the code to do this could be done by a design-time environment which creates
enough code to make this automatically work at run-time. But even in this
latter case, I think that run-time reflection makes a much cleaner
environment in which to bridge the gap between a design-time/run-time
environment than does boilerplate code.

>
> Now, you can easily set event handlers at compile time. It'll get even
> better (look out for CUJ November issue ;)).

I understand this possibility and applaud your work, but it still is not
design time programming ( yet ).

>
> Having said that, you only need to come up with a wizard that
> understands what events can be generated for a dialog, and make sure
> you can edit them. Not very complex, especially knowing how easily
> you can parse a C++ file for win32gui events.

See above. Perhaps the wizard can produce the correct code without
reflection, as you hope to prove. I look forward to seeing how you get it
done via templates.

>
>
>> view of event handlers is that any "component" ( see below ) within
>> such a system should be capable of handling any event generated by
>> any other component; which is true of both C++ Builder and Managed
>> C++/.NET.
>
> I don't think you'd want any component to catch events generated by
> any other component.
> What I think you'd like is: handle on a dialog, any notification
> coming from its controls. If the dialog does not/cannot handle this
> notification, propagate it up the chain (dialog's parent, grand
> parent, etc.).

I heavily disagree with this model. That's MFC/OWL and I would guess plenty
of other GUI environments, and it is old. There is no reason why any
component shouldn't be able to hook events.

>
> This is how win32gui handles events right now.
>
> And I think this is how C++ Builder/.net handles events as well.

You are completely wrong on this last point. Any C++ Builder component can
hook an event ( called a __closure ). Any .NET component can hook an event
( called a delegate ). I am not trying to put down what seems to be your
excellent work in any way, but you are conceptually following a model for
event generation/event handling which has been superceded IMHO. If you like
that model, fine. But I want to point out to you that a much better model,
and much more in the spirit of C++, is to allow any functor to handle an
event. And of course boost::signal<> is built around this idea. If your
events are multi-casting, which I am sure they must be, there is no reason
putting limitations on who can handle them unless you are using a means of
event generation which is in itself restrictive in what it can do. All you
end up doing is making programmers who want to use your GUI angry that they
must find workarounds for event handling for many cases for which you
haven't yet conceived.

>
>>
>>
>>>> easy RAD programming which C++ Builder and Managed C++ .NET
>>>> provide. Needless to say, both use extensions to C++ to do
>>>> reflection. This is not a knock on any of the GUI libraries
>>>> mentioned, but after using C++ Builder and Managed C++ .NET, even
>>>> despite their non-C++-isms, most C++ GUI libraries are very
>>>> primitive by contrast.
>>>
>>> I donot understand what you mean by the last sentence.
>>
>>
>> In the sense that one has to do work at run-time when it could be
>> done at design time. Please notice I said 'most', not all. If you,
>> or anyone else, could come up with a RAD C++ GUI development
>> environment which works with 98%+ conforming C++ compilers ( Como,
>> gcc, VC++ 7.1, Intel etc. ) and
>
> So far win32gui works for como, gcc, vc71.
> I intend to port it to other *modern* compilers as I have the time.
> But I think this will be most likely 3-5 months from now.

Sounds great ! I look forward to reading more about it.

>
>> enables one to easily set properties and events at design time, ala
>> C++ Builder and Managed C++/.NET, I would be very interested in it
>> and would contribute to it any way that I can if I liked the design.
>> By GUI I also means the sort of components ( properties and events
>> along with traditional C++ method-based programming ) which are
>> supported by C++ Builder and Managed C++. I think non-visual
>> components are also very important and
>
> It'll be possible. Also - I plan to allow it 3-4 months from now.

Good luck !