Handling of .ui files for code-information

[Andreas Pakulat]

On 20.09.07 07:42:44, Kris Wong wrote:
> > I recently thought a bit how we could handle .ui files in kdevelop4.
> > 
> > I'm thinking about a language part for .ui file which would simply
> > create a DUContext of type class and a couple of declarations for the
> > widgets in it. That way a C++ or Python language support just needs to
> > find out that
> > 
> > #include "ui_foo.h" (or import ui_foo) means asking the 
> > ui-language part
> > for the DUContext for that file.
> > 
> > Another option would be making a .ui file parser available as library
> > and then each language support would have to create the 
> > contexts itself
> > using their own custom types and such things. 
> > 
> > Any other ideas I haven't thought of? Or problems with either 
> > approach?
> 
> I don't know that the time required to do such a thing would be worth
> the investment (especially for 4.0).  With the new C++ parsing framework
> in kdevelop 4, as long as the generated headers exist on the disk they
> will be parsed correctly. 

Yes, but for that I have to build the project once. So no help while
writing the app. Also I won't see changes done to a .ui file.

Parsing the .ui files should be pretty simple as we don't need that much
information from it.

>  What do you imagine this special .ui file
> information would be used for?

Code-Completion, directly after I change a .ui file inside KDevelop.
Also I think for some 4.x version (x>0) we might think about
code-refactoring including .ui files (so I can rename a widget in my
form "everywhere"). Code-Navigation might also be interesting: 

void foo()
{
  my_ui->textEdit->setText("foo");
}

Now you bring the cursor to "textEdit" and hit the "go-to-declaration"
shortcut and voila, the .ui file opens with the widget selected.

Andreas

-- 
Expect the worst, it's the least you can do.