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 slougi on Monday 19/Mar/2007, @08:49

In Qt there is no onclick event. Rather, a signal is emitted. You connect this signal to a slot, where you respond to it. There is a graphical signal/slot connection editor. This is one of the elementary principles of Qt. IMO there is no point in catering to someone who does not understand the basic principles of the software stack he is working with.

Related Links

·   Articles on Developer
·   Also by slougi
·   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 Michael on Monday 19/Mar/2007, @12:42

I disagree. There is very well a point in catering to everyone who wants to build a KDE application right away without endless studying of hundreds of manual pages. This is what the original post is about. And besides there is not much difference between event/event-handler and signal-slot anyway. At least not for a novice user. You have a button. And you want to do something as soon as someone clicks on it. This should be extremely easy to achieve. It's just basic functionality for a development environment. It isn't right now. Delphi can do that. KDevelop can't. So as much as I like KDevelop I think the original poster has a very valid point here.

[ Reply To This | View ]

Re: True RAD still missing in KDevelop 3.4
by Jonas on Monday 19/Mar/2007, @20:04

what's so difficult about QObject::connect(&myButton, SIGNAL(clicked()), &myObject, SLOT(myFunction()))?
It's just as hard to do that in Delphi if you aren't willing to learn :-)

[ Reply To This | View ]

Re: True RAD still missing in KDevelop 3.4
by eMPee on Tuesday 20/Mar/2007, @08:05

well BUT the Delphi form designer adds that line by itself when you double click a button..! ...
sometimes it's the atom-layers you're ahead of the competition that actually enable the average Joe user to use your application..

[ Reply To This | View ]

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...

[ Reply To This | View ]

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 )


		"Don't code today what you can't debug tommorow." -- Ariya Hidayat
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.