Events editor

[BogDan Vatra]

2008/11/10, Andreas Pakulat <apaku at gmx.de>:
> On 10.11.08 19:51:09, BogDan Vatra wrote:
>> Hi,
>>
>> I want to create an event editor for qt designer integration plugin.
>> First, let me say something about the event editor.
>> An event editor is an editor for signals (events) like property
>> editor, but instead to set properties you will use this to manage the
>> slots. This editor will create (if they not exists or remove/comment
>> if they already exists) for you slots: void on_<widget name>_<signal
>> name>(<signal parameters>);
>
> Thats actually called a signal/slots editor and IMHO we should (in the
> midterm) simply replace the "builtin" one from Qt Designer with one that
> uses all our facilities to allow adding slots for code thats "yet going to
> be written".
>

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.

>
>> What I want the event editor to do:
>> 1. If you don't subclass the form, the event editor can subclass the
>> form for you.
>
> Subclassing is not needed for ui-files to work, so we shouldn't enforce
> that. Its also not needed for the auto-connect feature to work, you can
> simply call a method (I can't recall the name right now) to get it.
>

If you refer to "void QMetaObject::connectSlotsByName ( QObject *
object )" function, I think subclassing it is a must, this function is
called, when you call setupUi(this).

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

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

> We might need a mapping from the generated header
> back to its source-files with CMake.
>

>
>> P.S. I hope you understand what I want to say, my English is not so good.
>
> Its good enough to understand you IMHO. Oh and btw, Welcome aboard :)
>
Thank you very much, I hope I can help.
>
> Andreas
>
> --
> Go to a movie tonight.  Darkness becomes you.
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
BogDan,