Events editor

[Andreas Pakulat]

On 11.11.08 13:29:59, BogDan Vatra wrote:
> 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 .

Ok, this one I don't understand :)

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

I don't expect any of this to be done for 4.0 actually. I'm also not saying
you need to start on this right now. I was just trying to explain what the
ultimate goal is for the signal/slot editor in KDevelops designer
integration. Its totally fine if you start with adding a new editor that
allows to create auto-connect slots.

I still am not sure I want to ship the designer integration with 4.0,
because its still "half-baked" and needs quite a bit of work. 

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

I think its rather that only 1% will subclass the ui. In fact my experience
on the Qt list tells me that most people prefer a private member for the
ui-class. Some are even loading .ui files "on the fly" while the
application runs.

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

For quickly hacking together an app, its fine. But in real-life full-blown
projects you can seldomly allow yourself to be very lazy, you have to think
about what names you use for methods - especially public ones.

Anyway, as I said above, its good to start with "something", back when I
brought the designer integration to what it is right now I was kinda scared
on starting a signal/slot editor, because a) language-support wasn't there
yet and b) it seemed like a hell of a lot of work. So its probably best to
start with small steps :)
 
> >> >> 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 ?

Maybe, you could try to find the .ui file in the project tree, get its
parent which should be a ProjectTargetItem and let the projectbuilder build
the target item. This would automatically re-generate them, which might
work for now. See the ProjectItem classes, the IProject class,
IBuildSystemManager and IProjectbuilder for information on this. Oh and
probably also IProjectController. api.kde.org is your friend, look into the
interfaces and project libraries.

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

Docs for what? You mean what a fully integrated designer might allow? Well
for one, it'll provide the language information for the .ui files, i.e. a
declaration for each widget, with declarations for all the subwidgets.
(similar to what the C++ support knows after seeing the ui_xxx.h file).
Then there is custom widgets which we want to support, i.e. write a class
inside KDevelop and kdevelop will show it inside the designer - on-the-fly.

I think we currently don't have any real docs of these ideas, there might
be some available in our wiki in the KDevelop4 section though.

Andreas

-- 
Exercise caution in your daily affairs.