Events editor

[Andreas Pakulat]

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

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. Having two "things" do basically the same thing
is not a good idea. Especially beginners will be confused by this.
 
> >> 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).

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. 
 
> >> 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.
 
> >> 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. Thats the ultimate goal for our designer
integration, to really integrate it with all other parts of the IDE so its
more useful than a standalone designer (so far there's basically no
difference and I tend to use the standalone one because it doesn't clutter
the ui). A fully working signal/slot editor is just a first step :) an
important one though.

Andreas

-- 
You have a deep appreciation of the arts and music.