On 5/8/10 14:01, Justin Johansson wrote:
> bearophile wrote:
>> Justin Johansson:
>>> Whilst QtD looks like a cool project, my question was really about
>>> whether D could achieve the same sorts of things that Qt does with
>>> its meta-object compiler.
>>>
>>> In other words, and calling a spade a spade, Qt is a "hack" to make
>>> C++ more pleasant for GUI. Would it be possible for D to achieve
>>> natively the same sorts that Qt does via preprocessing to C++.
>>
>> I suggest you to explain what such things are, and to give some
>> examples too.
>>
>> Bye,
>> bearophile
>
> Okay, perhaps not everybody here is across Qt.
>
> Programming in Qt is almost C++ bu not exactly C++ as Qt uses a
> preprocessor to translate "enhanced C++" into "vanilla C++".
>
> Here is an example that demonstrates that "Qt C++" is not "vanilla C++".
>
> In Qt, one adorns class declarations with things that are not valid C++.
>
> So in a class declaration you can say
>
> class MyWidget
> {
> public:
> // regular C++ stuff, attributes and methods
>
> public slots:
> // method declarations for intercepting event signals
> };
>
> You will observe that "public slots" is not valid C++. Qt's meta-object
> compiler does a preprocessing of the MyWidget class so that methods
> declared under the "public slots:" scope are subject to some kind of
> reflection or introspection that enables events (signals) to be delegate
> to the respective methods.
>
> In doing so, according to my naive understanding, the Qt MOC
> (meta-object compiler) compiles the MyWidget class retaining knowledge
> of compile time analysis of the MyWidget class methods which are
> designated as slots.
>
> So this is some kind of black magic that the MOC does to Qt source code
> in order to make event routing easier. The concepts of reflection come
> to mind here. In a way the MOC processor must be keeping a lot of the
> static analysis of classes around in similar fashion that Java does.
>
> Accordingly it is fair to ask why does Qt do this? Obviously Qt
> designers do not feel that vanilla C++ is adequate for cutting GUI apps
> which is why they resort to a preprocessor.
>
> Now I was thinking about why is C++ deficient for Qt to go to such
> resorts. And if vanilla C++ is deficient for GUI programming, and given
> that D is viewed by many as a "better C++", then can D do natively what
> Qt has to do with a preprocessor?
>
> I'm not an expert on Qt or its MOC (only 2 weeks into it). Perhaps
> others on this NG might cotton on to what I'm trying to express and
> chime in.
>
> Does the simple example above help explain what I'm on about?
>
> Cheers
>
> Justin Johanssom

I've read the two links bearophile posted and I think that Qt signals and slots look similar to C# events. This can easily be implemented using delegates. Basically create a new template type (a struct for example) called Event. Event contains a data structure (a linked list for example) of delegates. Then you have a function that adds new delegates to the data structure and finally a function that calls all the delegates in the data structure.

This code is basically the same thing as the Counter example on Qt site.

class Counter
{
	int value_;
	Event!(void, int) valueChanged;

	void value (int value)
	{
		if (value != value_)
		{
			value_ = value;
			valueChanged(value);
		}
	}

	int value ()
	{
		return value_;
	}
}

auto a = new Counter;
auto b = new Counter;

a.valueChanged += &b.value; // I'm hoping this will choose the right method based on the signature that is needed

a.value = 12;
b.value = 48;

Am I missing something? This seems pretty simple. If some additional support is needed there is always compile time reflection in the form of __traits: http://www.digitalmars.com/d/2.0/traits.html and runtime reflection in the form of flectioned: http://www.dsource.org/projects/flectioned

/Jacob Carlborg

On 2010-05-08 09:24:55 -0400, Lutger <lutger.blijdestijn@gmail.com> said:

> 2: It's attractive not only because it is so huge, well designed and
> supported, but also because it performs, is cross-platform and looks good
> everywhere (as opposed to Java and gtk)

Everywhere? Saying Qt apps looks good and behave well on a Mac is kind of a stretch. I have yet to see one that is not sub-par compared from what I would expect from an equivalent Cocoa implementation.

It's the same for all cross-platform toolkits really: they were first meant to work on Windows or Linux, so they're designed as such and it shows. Here's a nice comment to read:
http://illogic-al.org/blog/look-before-you-leap#comment-74


> 3: The C++ and meta-object compiler are not the core of it's success, but
> rather the combination of:
> - well-designed
> - HUGE coherent framework
> - good cross-platform capability
> - both open source and commercial
> - used by KDE, sponsored by Nokia

Very true. Qt is well designed and is huge, and is one of the very few sane C++ framework on Windows. I don't want my comment about the Mac look and feel above to diminish that. Qt is a platform that can stand by itself.


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

Michel Fortin wrote:

> On 2010-05-08 09:24:55 -0400, Lutger <lutger.blijdestijn@gmail.com> said:
> 
>> 2: It's attractive not only because it is so huge, well designed and supported, but also because it performs, is cross-platform and looks good everywhere (as opposed to Java and gtk)
> 
> Everywhere? Saying Qt apps looks good and behave well on a Mac is kind of a stretch. I have yet to see one that is not sub-par compared from what I would expect from an equivalent Cocoa implementation.
> 
> It's the same for all cross-platform toolkits really: they were first meant to work on Windows or Linux, so they're designed as such and it shows. Here's a nice comment to read: http://illogic-al.org/blog/look-before-you-leap#comment-74
> 
> 

Ah sorry I didn't know it was so crappy. Qt used to look different on windows too, not crap but just not native. In this area Qt is rapidly improving, the comment you cited is posted a while ago. Qt 4.6 can use Cocao now, I found this link in the docs:

http://doc.qt.nokia.com/4.6/qtmac-as-native.html

Hi Justin,

looking at QtD, it seems like it can be done :

In file http://www.dsource.org/projects/qtd/browser/demos/browser/browsermainwindow.d

        m_historyHome.triggered().connect(&this.slotHome);

        // ...

 	public:

 	    void slotHome()
 	    {
 	        // ...
	    }

I however believe that this kind of delegate-connection can also be performed in C++ (with templates?). Maybe Qt developers simply continue using the MOC because they don't want to break backwards compatibility.

-- Auria

Marianne Gagnon wrote:

> Hi Justin,
> 
> looking at QtD, it seems like it can be done :
> 
> In file
> 
http://www.dsource.org/projects/qtd/browser/demos/browser/browsermainwindow.d
> 
>         m_historyHome.triggered().connect(&this.slotHome);
> 
>         // ...
> 
>  public:
> 
>  void slotHome()
>  {
>  // ...
> }
> 
> I however believe that this kind of delegate-connection can also be performed in C++ (with templates?). Maybe Qt developers simply continue using the MOC because they don't want to break backwards compatibility.
> 
> -- Auria

Yes, but there is another reason: the signal/slot design is part of the reflection system that MOC generates. The idea is that this makes it more flexible and dynamic. For example you hook signal / slots in their gui designer or expose them as a dbus api, provide easy scripting access, etc.

On 05/08/2010 06:27 PM, Marianne Gagnon wrote:
> Hi Justin,
>
> looking at QtD, it seems like it can be done :
>
> In file http://www.dsource.org/projects/qtd/browser/demos/browser/browsermainwindow.d
>
>          m_historyHome.triggered().connect(&this.slotHome);

The example is outdated. Now it's like

connect(m_historyHome, "triggered", this, "slotHome").

>
>          // ...
>
>   	public:
> 	
>   	    void slotHome()
>   	    {
>   	        // ...
> 	    }
>
> I however believe that this kind of delegate-connection can also be performed in C++ (with templates?). Maybe Qt developers simply continue using the MOC because they don't want to break backwards compatibility.
>
> -- Auria

Here's why they are not using templates http://doc.trolltech.com/4.5/templates.html

> The example is outdated. Now it's like
> 
> connect(m_historyHome, "triggered", this, "slotHome").
>

Interesting. Does QtD use some MOC-like to generate code like C++ Qt, or is there some magic? I was searching for examples of how it was done, but if they're outdated... ^^

"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:hs3rju$ac1$1@digitalmars.com...
>
> I'm in the middle of reading the PyQt book, and I really appreciate how easy it is to implement GUI design & behavior in Qt using Python. I have yet to try mixing Python with D, but it should be possible. Personally, I would leave all the GUI stuff to Python, and most of the data manipulation (where speed is crucial) to C/D.
>
> It's probably best to pick the best language for a particular job. Unless the coder is stuck using only one language, for whatever reason it may be.

Years of web development has led me to the conclusion that there's significant, but frequently overlooked, benefit in sticking to as few languages as possible (preferably one that's as general-purpose as possible) as opposed to spreading an app across a variety of languages.

But then, of course, web development isn't so much a case of "choosing the best languages for the individual jobs" as it is "being forced into the worst languages for the individual jobs" ;)

"Jacob Carlborg" <doob@me.com> wrote in message news:hs3su9$c7k$1@digitalmars.com...
>
> I've read the two links bearophile posted and I think that Qt signals and slots look similar to C# events. This can easily be implemented using delegates. Basically create a new template type (a struct for example) called Event. Event contains a data structure (a linked list for example) of delegates. Then you have a function that adds new delegates to the data structure and finally a function that calls all the delegates in the data structure.
>

When I looked into Qt, that was my impression as well. Seemed like a slightly more clumbsy/awkward version of C#'s events. That plus D's reflection (or at least an improved version of D's reflection anyway) seems to cover all the bases. But then, I'm no Qt expert.

"Michel Fortin" <michel.fortin@michelf.com> wrote in message news:hs3uft$efc$1@digitalmars.com...
> On 2010-05-08 09:24:55 -0400, Lutger <lutger.blijdestijn@gmail.com> said:
>
>> 2: It's attractive not only because it is so huge, well designed and supported, but also because it performs, is cross-platform and looks good everywhere (as opposed to Java and gtk)
>
> Everywhere? Saying Qt apps looks good and behave well on a Mac is kind of a stretch. I have yet to see one that is not sub-par compared from what I would expect from an equivalent Cocoa implementation.
>

This is first I've heard of that. I find it interesting though. Can you post comparison screenshots and explain some of the behavioral differences? I promise I'll try my best to refrain from another of my "Apple sucks" rants ;) (I saw the screenshot that was linked to in the comment that you linked to, but I couldn't quite make heads or tails of what exactly it was demonstrating.)