Events editor

[BogDan Vatra]

2008/11/11, Andreas Pakulat <apaku at gmx.de>:
> On 11.11.08 11:13:39, BogDan Vatra wrote:
>> 2008/11/10, Andreas Pakulat <apaku at gmx.de>:
>> > On 10.11.08 19:51:09, BogDan Vatra wrote:
>> >> Hi,
>> >>
>> >
>>
>> I called events editor because I this tool don't connect signals to
>> slots in a .ui, this tool adds and removes slots in source files,
>> functions like this:" void on_<widget name>_<signal name>(<signal
>> parameters>);", and I think the signal slot editor from trolltech is
>> doing his job very well.
>
> Except that it only works for "builtin" signals/slots, which is not
> acceptable in the long-run for KDevelop's Designer integration. Besides,
> the designer integration specifically allows and encourages to provide a
> custom signal/slot editor.

Please give me something to read .

>  Having two "things" do basically the same thing
> is not a good idea. Especially beginners will be confused by this.
>

Ok. But I cant promise you this will be ready for 4.0. I don't want to
think how hard is to rewrite the signal/slot editor.

>
> No thats not correct. setupUi will make all widgets it creates childs of
> the object passed into it. And connectSlotsByName works solely on the list
> of childs from the object passed into the function. So it works without
> subclassing.
>

Yes, you are right, but I think 99.99% will subclass the ui.

>
>> >> 2. Let you create or remove/comments slots.
>> >> 3. Rename all the slots related to a widget when you rename the widget
>> >> name. Here I think is better to search and rename all declarations who
>> >> use this widget.
>> >
>> > Well, a slot connected to a signal of Widget "foo" doesn't necessarily
>> > need
>> > to access "foo". So instead it would be better to do the following two
>> > things:
>> >
>> > a) check for slots that are called on_<xxx>_<yyy> where xxx is a
>> > variable
>> > in the Ui-Class and yyy is a signal of the related class.
>> > b) check for connect statements that use the name of the form variable
>> > in
>> > the whole project (longterm also in all opened projects)
>> >
>>
>> >> 2. Let you create or remove/comments slots.
>> This feature will only create or remove slots that are called
>> "on_<widget name>_<signal name>(<signal parameters>);". I don't want
>> to connect any slots manually, they are connected by the
>> "connectSlotsByName" function when you call setupUI(this).
>
> Thats not going to work in the long run. People want to name their slots
> according to what they do. If you look at existing code very few is
> actually using the on_XXX_YYY syntax, because very few people find
> auto-connection more useful than meaningful method names.
>

For long run maybe not, but for 4.0 I think this is a nice and very
useful feature, just think how easy is for me just to dblclick on a
signal and kdevelop to add for me a slot for that signal, even this
signal is auto-connected by "connectSlotsByName". For lazy developers
like me this is a dream ;).

>
>> >> What I have done:
>> >> 1. I manage to find the ui_<form_name>.h where is it. Please don't
>> >> remove "KDevelop::DUChain::documents( )" function, it helped me a lot.
>> >
>> > I guess starting with the Ui::Class? What about the .ui file that you
>> > actually change? You and the C++ support won't see changes done to that
>> > file, until a re-compile.
>>
>> I can, it's easy.
>> Take a look to QDesignerFormWindowInterface
>> (http://doc.trolltech.com/4.4/qdesignerformwindowinterface.html#mainContainerChanged
>> ,
>> http://doc.trolltech.com/4.4/qdesignerformwindowinterface.html#widgetManaged)
>> and to QDesignerPropertyEditorInterface
>> (http://doc.trolltech.com/4.4/qdesignerpropertyeditorinterface.html#propertyChanged)
>>
>> When you select a widget in designer, the signal "widgetManaged" is
>> emitted, here we can take the object name.When you change the object
>> name to widgets, the signal "propertyChanged" is emited, we have the
>> old name and the new one.
>
> Right, but the C++ support still doesn't see this, so you won't get
> code-completion and other things in the class(es) using the ui file until a
> re-generation of the header file.

After we finish the modification to the ui, can we re-generation ?

> A fully working signal/slot editor is just a first step :) an
> important one though.
>
Please give me some docs.

BogDan,