Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

New scripts through plugin installation

(1/4) > >>

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:

--- Quote ---How can these be available to the user after the plugin installation?
--- End quote ---
Read this.



--- Quote ---How can I set the "Make commands" and the "Using Make" attributes of the project using the project and target creation scripts?
--- End quote ---
Use the script counterparts of CompileTargetBase::GetMakeCommandFor and CompileTargetBase::SetMakeCommandFor (they are basically the same both in C++ and scripts).



--- Quote ---How can I set "Extended" (you know the ones provided by the plugins) attributes of the project using the project creation scripts?
--- End quote ---
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:

--- Quote from: mandrav on August 05, 2007, 05:55:56 pm ---Read this.

--- End quote ---

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)


--- Quote from: mandrav on August 05, 2007, 05:55:56 pm ---Use the script counterparts of CompileTargetBase::GetMakeCommandFor and CompileTargetBase::SetMakeCommandFor (they are basically the same both in C++ and scripts).

--- End quote ---

Clear enough


--- Quote from: mandrav on August 05, 2007, 05:55:56 pm ---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?

--- End quote ---

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.


--- Quote ---The first two are native, the third is an "Extended" attribute.
--- End quote ---

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:

--- Quote from: mandrav on August 06, 2007, 10:35:27 am ---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).

--- End quote ---

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


--- Quote from: mandrav on August 06, 2007, 10:35:27 am ---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.

--- End quote ---

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.

Navigation

[0] Message Index

[#] Next page