Re: True RAD still missing in KDevelop 3.4

faq
flatforty
contribute
subscribe
configure
search
rdf

main
parent
thread

Re: True RAD still missing in KDevelop 3.4
by Pino Toscano on Monday 19/Mar/2007, @17:52

> In Qt there is no onclick event. Rather, a signal is emitted. You connect this signal to a slot, where you respond to it.

Absolutely wrong.
Most of the event handling of Qt is based on reimplementing the virtual function that represent the event handlers, eg mouseEvent(), paintEvent(), etc. If not that, you can attach an event filter for a generic QObject (and every widget is a QObject, too).
But there are no signals about the events, unless you provide them on your own.

> This is one of the elementary principles of Qt.

You know that pretty well, it seems...

Related Links

·   Articles on Developer
·   Also by Pino Toscano
·   Contact author

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Re: True RAD still missing in KDevelop 3.4
by slougi on Tuesday 20/Mar/2007, @02:52

Ok, and I did know that. Perhaps I posted in haste. However, the usual model is to connect to the QAbstractButton::clicked signal, and not to reimplement the event handlers. I'd argue that reimplementing an event handler is quite a lot more involved than responding to a signal.

[ Reply To This | View ]

Re: True RAD still missing in KDevelop 3.4
by slougi on Tuesday 20/Mar/2007, @03:12

Adding to my previous post (again having posted to quickly :), there is also the issue of which event handler to reimplement.

Let's take the simple mouse click. For correct handling, the mouseReleaseEvent is probably correct, and if you want to go there it could probably be automated in the IDE to reimplement this function. Were it not automated, it would be quite easy to make the mistake of reimplementing for instance mousePressEvent, at which point the applications behaviour would deviate from other applications.

Also, as far as I know, Qt events differ from Delphi events in several aspects. It's been a while since I wrote any delphi code, but as I recall events there are more like static slot connections. That is, a certain callback is defined (usually in the form holding e.g. the button), and the button from which the event originated is passed as a parameter. I don't have any profound insights (not that I usually have any :) on what this difference means, just pointing it out.

QMetaObject::connectSlotsByName could probably be used in an IDE to achieve something similar to Delphi.

[ Reply To This | View ]

The Fine Print: The previous comments are owned by whomever posted them.
( Reply )


		"I can't describe the scene as this is a G-rated site, but think Pulp Fiction." -- Sirtaj Singh Kang
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.