New scripts through plugin installation

[yop]

I 'm going to need a few scripts installed with my plugin:

• A new project template
• A new target template
• Some new debugger stuff (understanding of QString much like wxString is already implemented)

My questions are:

• How can these be available to the user after the plugin installation?
• How can I set the "Make commands" and the "Using Make" attributes of the project using the project and target creation scripts?
• How can I set "Extended" (you know the ones provided by the plugins) attributes of the project using the project creation scripts?

[mandrav]

How can these be available to the user after the plugin installation?

Read this.

How can I set the "Make commands" and the "Using Make" attributes of the project using the project and target creation scripts?

Use the script counterparts of CompileTargetBase::GetMakeCommandFor and CompileTargetBase::SetMakeCommandFor (they are basically the same both in C++ and scripts).

How can I set "Extended" (you know the ones provided by the plugins) attributes of the project using the project creation scripts?

You can't. Not by scripts. These are plugin-specific sections and no generic script interface is provided for it. What are you interested in?

[yop]

Read this.

So I can have relative paths in the manifest.xml and drop them to wherever the project generation scripts are right? For the debugger I don't have to touch the original script but provide a new one and it will automagically be used? (Haven't searched the last one enough yet)

Use the script counterparts of CompileTargetBase::GetMakeCommandFor and CompileTargetBase::SetMakeCommandFor (they are basically the same both in C++ and scripts).

Clear enough

You can't. Not by scripts. These are plugin-specific sections and no generic script interface is provided for it. What are you interested in?

I did see this coming... Let me explain where QtWorkbench is going. You have a typical C::B project and then the user can request that it will use QtWorkbench in the build process (there is a dialog for doing so in the Project Properties). The choice of the user is written in the project file (remember this thread?). Now when the user requests a build I catch the build started event and run qmake to generate the Makefiles and then leave C::B alone to handle the rest of the build process (using custom Makefile and some specific build commands). The whole process from the user perspective has become really transparent he just has to press "Build" and everything happens automagically (just like I always had in mind for the plugin). As you can tell from the rest of my questions there are some prerequisites for using the plugin:

• The user must select a custom Makefile build - OK, we got this covered
• The user must change the "make" commands - also covered
• The user must select that he will use QtWorkbench - :-(

To provide a project creation wizard I 'm going to need to set all three of the above attributes of the project. The first two are native, the third is an "Extended" attribute.

Oh and a sidenote for possible current QtWorkbench users that don't see the above features in the current implementation (0.5.x). These are mostly new features I 'm talking about that are in the plugin svn and will be available in future releases.

[mandrav]

You have to excuse me but I haven't used your plugin (qt programming doesn't interest me . Obviously I am missing something.

The first two are native, the third is an "Extended" attribute.

The <Extensions> node in the project file provides a way for plugins to store per-project attributes that are only of interest to the specific plugin.
From what I have understood, you want your plugin to know that a specific project should be "treated" by it. This is a property of your plugin and it shouldn't matter (at runtime) whether it is written inside the <Extensions> node or not. This xml node is useful only when loading a project so your plugin can see that it should "handle" this project in a special way (or whatever it is your plugin is doing).

As I said, I might have not understood the problem completely so feel free to explain more .

Anyway, if you prove that reading/writing the <Extensions> node at runtime (i.e. outside project loading/saving scope) is needed/useful, it should be pretty easy to expose such functionality. For a few revisions now this node is being kept in memory throughout the project's lifetime so all it would take is expose it through the SDK API.

[yop]

The <Extensions> node in the project file provides a way for plugins to store per-project attributes that are only of interest to the specific plugin.
From what I have understood, you want your plugin to know that a specific project should be "treated" by it. This is a property of your plugin and it shouldn't matter (at runtime) whether it is written inside the <Extensions> node or not. This xml node is useful only when loading a project so your plugin can see that it should "handle" this project in a special way (or whatever it is your plugin is doing).

You got everything right and what you describe is exactly what I do.

Anyway, if you prove that reading/writing the <Extensions> node at runtime (i.e. outside project loading/saving scope) is needed/useful, it should be pretty easy to expose such functionality. For a few revisions now this node is being kept in memory throughout the project's lifetime so all it would take is expose it through the SDK API.

What I need is a way to write that xml node from a project creation wizard, I don't actually know what this will mean internally. This project creation wizard will prepare projects that are "handled" by my plugin and I need a way to set the property that tells my plugin when the respective project opens to actually handle it.

[mandrav]

What I need is a way to write that xml node from a project creation wizard, I don't actually know what this will mean internally. This project creation wizard will prepare projects that are "handled" by my plugin and I need a way to set the property that tells my plugin when the respective project opens to actually handle it.

OK, now I get what you want .
Let me think about it for a while and get back to you.

[mandrav]

Update your C::B working copy and look for cbProject::AddToExtensions() [documented].
You should use it inside your script's SetupProject(theproject)...

[yop]

I can't get it to work 
In the script I have

Code

project.AddToExtensions(_T("qtworkbench/+enabled:value=true"));

and I get in the cbp file

Code

<qtworkbench>
	<enabled value="false" />
</qtworkbench>

then I changed in the script to set a different attribute (just for testing) and I got the exact same results:

Code

project.AddToExtensions(_T("qtworkbench/+enabled:price=1"));

output:

Code

<qtworkbench>
	<enabled value="false" />
</qtworkbench>

It seems that always the same attribute (named "value") gets set with "false"

[mandrav]

I can't get it to work 
...
It seems that always the same attribute (named "value") gets set with "false"

Works For Me (tm)
Seriously, I just tried it and it worked fine. Have a look at the code if you want. It's in cbproject.cpp, line 1978. You will see that there is no hardcoded "value" or "false" there (why would there be?).
My guess is that the script you 're editing is NOT the one actually ran by the wizard. Are you sure you 're editing the correct script?

[yop]

I 'll check again, probably I did something wrong. The strange thing is that I never AFAIR set this thing to false either editing the correct script or not. Where on earth could it get it? Anyway I 'll check again...

As a side note many congratulations on the scripting facilities. They are impresive :-)
You know what comes next don't you? I 'll ask for adding new project wizards automatically ;-)

[mandrav]

You know what comes next don't you? I 'll ask for adding new project wizards automatically ;-)

Hehe, I saw this one coming .

[mandrav]

@yop:

btw, have you seen this?. Maybe it could be of help for QT's moc/uic tools?

[yop]

Yeap I 've seen it (since I picked up on my plugin again I 'm watching the project closely ) and it sure can work. I am trying to find some time to check how it would work for Qt (moc has to be run on the project header files and uic in the ui (designer) files) and post it on the wiki. But still using the plugin will be easier to set the whole thing up and will feel closer to what Qt devs have learned to expect and use when setting up Qt projects (my ui ideas come from existing projects for Qt support like the eclipse integration, KDevelop etc). I can cover the whole Qt support either way, my issue is that I don't have that much time to work on it (I 'm trying though)

[yop]

OK it was my fault, I regenerated the node in the plugin's registered hook for project loading, the script had nothing to do with it. I have a strange behavior though as it seems that the hook doesn't get called on the first project startup (or the "extended" project properties are not taken into account) right after the wizard has ended. If I reopen the project then everything is as expected. I 'll investigate a bit further.

[yop]

I 'm on to something. I have this hooked to the project load/unload:

Code

void QtWorkbench::OnProjectLoadingHook(cbProject* project, TiXmlElement* elem, bool loading)

Now when the new project wizard finishes this function get called 3 times and each time it gets called with loading = false  :?. This is why I had the strange behavior all the way. When the project gets loaded the plugin checks if it should handle the project and then when the project closes it writes back (depending on the user requests) if it should handle the specific project. Now since the loading never gets the true value my plugin doesn't get the state that it should handle the project and during the project closing it always writes the false value in the project file. What I would expect:

Wizard finishes -> hook gets called with loading = true and nothing else, just resume the typical handling of an open project.