Edit project as regular text file in editor plug-in

[killerbot]

Dear all,

I have developed a plug-in which allows you to open the project file in an editor pane, so you can view (and edit) it as the xml file it actually is.

The plug-in now foresees in 2 choices :
   - edit the project file
   - reload the project file (closing and opening it : mgiht ask to save in between if after modification it has not been saved yet)

The functionality can be accessed through :
  - the project menu (2 new entries : open project for edit , reload project)
  - right clicking on the project name in the project manager pane (2 new entries : open project for edit , reload project)

Install it by copying the ddl in the attached zip file into the CB plug-ins directory. The zip file also contains the cbp project and the sources. It has been developed and tested on Windows XP, so you might need to change the cbp to your setup accordingly.

Enjoy it,
kind regards,
Lieven

PS : I do have some requests for the core developers, here's my story.

When a file has been modified outside Code::Blocks, CB offers to reload it. This works for source files open in a editor pane, but this is not the case for the project file itself.

This plug-in I developed allows you to open the project file in an editor pane, so you can view (and edit) it as the xml file it actually is. After you edit the xml file, CB has no idea that the project file has to changed. It would be nice that CB also check this, so it can be automatically reloaded.

The plug-in now foresees in 2 choices :
   - edit the project file
   - reload the project file (closing and opening it : might ask to save in between if after modification it has not been saved yet)


So I have some questions :
   - Can the core CB developers adjust the code base so CB also checks for external modifications of the project file and offer to reload it as with source files ?
   - if the answer is no, could they pinpoint me the code that does the reloading of the source files, so I could change/adopt it myself  (I prefer a yes on the first quesion ;-) )?



[attachment deleted by admin]

[thomas]

*shudders*

[rickg22]

Thomas: What was that *shudder* for?

[thomas]

For editing config files by hand while the program is running. Things like that make me shudder. 

[rickg22]

Oh, I see. Anywyay, what do you think of editing the checkforexternallymodifiedfiles function?

I find that a valid point, since sometimes i update from CVS but the project isn't reloaded.

[mandrav]

Oh, I see. Anywyay, what do you think of editing the checkforexternallymodifiedfiles function?

I find that a valid point, since sometimes i update from CVS but the project isn't reloaded.

The only bulletproof way of correctly reloading the project is to close and reopen it. Anything else and a million bugs are waiting to happen...

[thomas]

Hmm, personally I am not enthousiastic about that, it's major overkill CPU-wise.

Reloading an editor may take 0.1 seconds, but loading a project can be 5 seconds, too, including parser.

[rickg22]

I see. But what happens if the project is modified externally, and THEN I add a file? The external changes would be lost. And personally I don't have anything against closing and reopening the project.

[killerbot]

That's the way I also implemented it, closing and reopening. Suppose automated checking on changes of the project file would happen, reloading can be just closing and reopening.
If you edit in the editor of cb, it should work rather well. If you 'GUI' changed something to the project and in the mean time you also changed the xml file for example in another editor (gedit, notepad, ..) then you are in for trouble. Because one save can overrule the other save, but this problem is also present for regular source files.

The reason I made this plug-in is, when your project (for example a library) has many targets (for example debug/release builds with different compilers for maybe different platforms); then I might be way easier to make an adjustment (say needed for 'nearly' all targets) if you could do that in the text xml file, instead of wading through all those gui panels.
Gui's are nice and user friendly but sometimes one needs more 'core?/hacking?' power.

Example :the project generated by the plug-in generator plug-in contain incorrect paths for compiler and linker (see another post by me). Each time I generated the plug-in starters I could adjust everything through the gui's. But I could just copy the correct stuff from a correct cbp xml file and copy it in the new wrongly generated cbp. Ok, fair is fair, if that bug is fixed, this example is no longer, but other occasions might benefit from this approach.

Another occasion where at minimum the reload command can be of use, is when you use versioning control system, and you retrieve from the system an older or newer version and CB had the project still open. So then my plgu-in comes to the rescue (you could close CB before you update the stuff from the version control system), it is automated then, or semi-automated since the user still issues to reload command. But it might be nice if CB detects the change and offers you the reload, the user then should decide what to do, if he had already made an unsaved change to the project and now he wants yet another different version of that project.

Hey, these are my pros, no doubt there are good arguments for the cons.

[killerbot]

one more addition.
I do agree on the cpu penalty, but as like in my example (version control retrieval) you need to reload anyway.
If you just add a compiler switch in the gui way of working I guess there's no reloading and no parsing needed. If you close and open, this does happen, so in this case you suffer the penalty. But this might be still quicker then GUI travelling through all the spots where you want to change stuff (considering it is not just a single trivial change).

[MortenMacFly]

The reason I made this plug-in is, when your project (for example a library) has many targets [...]
Each time I generated the plug-in starters I could adjust everything through the gui's. But I could just copy the correct stuff from a correct cbp xml file and copy it in the new wrongly generated cbp. [...]

I agree. It's the same for me. I often create a new project on the basis of an old one. I also edit the XML file directly, e.g. to add/rename certain files or add another target without using the GUI. That's often a simple copy&paste operation (thanks XML!). So this plugin will be helpful for me. Thanks!

Morten.

[killerbot]

Updated project, minor code change, warning removed, and build for svn head revision.

Lieven

[attachment deleted by admin]

[killerbot]

updated to todays revision (plug in name switch, sort of ...)

[attachment deleted by admin]

[LETARTARE]

Hello,
where can I download the plugin ?
Thank you