Move some GUI code from sdk to src

[oBFusCATed]

I don't like much that the sdk target contains lots of UI code.
And I want gradually to remove all of it.

The first step in this direction I want to make is to move the EditorConfigurationDlg from sdk to src.
Currently there are two reason for its presence in the sdk:
1. It is shown by the context menu in the editor
2. There is a script binding to it

Is there anyone which will suffer much by such a change?

The reason I want to move the class is that I want to make changes to it and it will make it easier (faster compilation)
to do it.

[MortenMacFly]

1. It is shown by the context menu in the editor
2. There is a script binding to it

Is there anyone which will suffer much by such a change?

Do you mean both functionalities would be removed? I use the first quite some times.

But generally I have no objections against making the SDK UI independent. I would (however) welcome any ability to re-use dialogs from within plugins to avoid re-inventing the wheel. Just like you did with the debugger. Maybe another "sdk_ui" layer makes sense...

Also keep in contact with Jens - the overall goal should be a C::B build system w/o GUI like he did in the console branch.

[oBFusCATed]

Do you mean both functionalities would be removed? I use the first quite some times.

Yes, both of them. The (1) is the same as "Settings -> Editor...", which is not that much harder to reach.
And if you really need it, probably we can restore it with some kind of message.

But generally I have no objections against making the SDK UI independent. I would (however) welcome any ability to re-use dialogs from within plugins to avoid re-inventing the wheel. Just like you did with the debugger. Maybe another "sdk_ui" layer makes sense...

Probably it will be a good idea to have libcodeblocksui.so but the problem is that almost every part of the sdk has the ui bolted into it.

Also keep in contact with Jens - the overall goal should be a C::B build system w/o GUI like he did in the console branch.

The console branch removes the GUI with the use of lots of ifdefs without much changes to the API or moving stuff around.

p.s. I'll post a patch tonight.

[oBFusCATed]

I've skipped the patch and just committed - if you don't like it now is the time.

Also I've started the extraction of the GUI part from ProjectManager and I'm not sure I want to continue.

Is there any technical reason for the singleton infestation caused by the Manager?

[MortenMacFly]

Is there any technical reason for the singleton infestation caused by the Manager?

Sure - There should an can only be one project manager..?!

[oBFusCATed]

Sure - There should an can only be one project manager..?!

Why? What if I want to have two workspaces loaded?
And by the way this is not a technical reason.

[MortenMacFly]

Why? What if I want to have two workspaces loaded?

Why would you want to do that? The design is 1 workspace with n projects with m targets. Do you want to change that? Why? I don't know any software that supports more that one WS opened.

And by the way this is not a technical reason.

Nut sure what you mean - but well: There is never a strict technical reason for a singleton pattern. Its more enforcing discipline for developers. Its a design pattern - full stop. You can (of course) question design patterns... Start by writing an email to Erich Gamma... ;-)

[oBFusCATed]

A technical reason would be if we want to have proper initialization before the "main" function call.
Otherwise a singleton is just a glorified global variable.

Anyway, I've just being wondering about it. Because the Manager/Singleton stuff makes the code a bit messy and tightly coupled.

BTW: Here is a first patch of the extraction of the UI code from ProjectManager: http://cmpt.benbmp.org/codeblocks/patches/no_ui/0001-sdk-Start-the-extraction-of-the-UI-related-code-from.patch

[killerbot]

hmm, and a war on singletons is starting ;-)

I do agree, it would be better to not have a singleton, and pass a reference to the resource.
Makes things more explicit, and is also beneficial for testing purposes and one reduces coupling.

So it is a refactoring which improves the code quality.

[oBFusCATed]

hmm, and a war on singletons is starting ;-)

No, because it will take years to remove them.

[oBFusCATed]

Here you can find the current status of the work.
https://github.com/obfuscated/codeblocks_sf/tree/no_ui_sdk

If anyone is interested in helping patches are welcome.

BTW: this is a git clone of the sf repo, I'll try keep it synced...
https://github.com/obfuscated/codeblocks_sf/

[MortenMacFly]

Here you can find the current status of the work.
https://github.com/obfuscated/codeblocks_sf/tree/no_ui_sdk

Well nice, but why didn't you just start a SVN branch so that we can merge and keep your changes tracked in our repo?

Its useless if you want to commit all this in one go at the end. You are the person that always reminds about atomic commits you know... What are your plans with these changes? Flush them in the end?

[oBFusCATed]

Well nice, but why didn't you just start a SVN branch so that we can merge and keep your changes tracked in our repo?

1. I'm not using svn any more. All my svn checkouts are put inside git repos.
2. With this one I'm testing git <-> svn syncing.
3. With git branches you have a single repo checkout on disk, which saves a lot of space

Its useless if you want to commit all this in one go at the end. You are the person that always reminds about atomic commits you know... What are your plans with these changes? Flush them in the end?

git rebase master will put them at the top
git svn dcommit will commit them as single commits.

[MortenMacFly]

git rebase master will put them at the top
git svn dcommit will commit them as single commits.

My Git-Foo is not that powerful. Does that mean we will get all your commits as single commits in the end merged into trunk? How does that work? As trunk moves on I see no possibility to "replay" all SVN commits w/o serious hassle.

The only feasible option I see is still a SVN branch in the background where you push from time to time so that we keep the changes in SVN and can do a proper merge once gone gold. Its OK if you use GIT - no problem, but we should be able to follow all steps later on in SVN. Just as you did with tiny commits in the past. I juts don't see how this is supposed to work if you massively touch the core w/o a SVN branch as a backend. Maybe you can enlighten me on that...

But if its really going to be one large commit (to use your words:) "I am going to revert it immediately". ;-)

[oBFusCATed]

My Git-Foo is not that powerful. Does that mean we will get all your commits as single commits in the end merged into trunk? How does that work? As trunk moves on I see no possibility to "replay" all SVN commits w/o serious hassle.

The thing is that git rebase is pretty powerful. It is the same as if you manually apply all the patches, but it is a bit smarter.
So in the end, when I/we are done with this feature, all git commits will be converted to svn commits.
And svn users will see them as a string of commits with very close times.
This is it.
git makes managing patches an easy task.... using svn diff + patch is so old school and PITA.

The only feasible option I see is still a SVN branch in the background where you push from time to time so that we keep the changes in SVN and can do a proper merge once gone gold. Its OK if you use GIT - no problem, but we should be able to follow all steps later on in SVN. Just as you did with tiny commits in the past. I juts don't see how this is supposed to work if you massively touch the core w/o a SVN branch as a backend. Maybe you can enlighten me on that...

Wait and see
Only I have to find time to work on this feature.

But if its really going to be one large commit (to use your words:) "I am going to revert it immediately". ;-)

In fact if you like it could be made as a single commit (I suppose).

[MortenMacFly]

In fact if you like it could be made as a single commit (I suppose).

No, please don't. If what you described works I am surely fine with it.

[oBFusCATed]

Anyone willing to test if the branch compiles (and works) on Windows?

[MortenMacFly]

Anyone willing to test if the branch compiles (and works) on Windows?

Compiling requires some more patching (i.-e. the CodeSnippets plugin). I can tell you where once I've got it completed...

Concerning the interface: Is there a reason why GetUI() returns a reference and not a pointer? It looks a bit weird, especially things like this:
Manager::Get()->GetProjectManager()->GetUI().GetTree()->Whatever();

[MortenMacFly]

...turns out it wasn't much in the end - the most places were due to my local changes.

So, attached is a patch to fix the build errors on Windows. Starting C::B and (little) working with it seems to be normal... anything special one should test?

[oBFusCATed]

anything special one should test?

Virtual folders, I never use them

GetUI returns reference to document that the result is always valid
I'll probably move it to the Manager class.

[oBFusCATed]

Code

diff --git a/src/batch_build_all.bat b/src/batch_build_all.bat
index 15b600e..e6aad9d 100644
--- a/src/batch_build_all.bat
+++ b/src/batch_build_all.bat
@@ -6,7 +6,7 @@ if not defined CB_ROOT set CB_ROOT=C:\Devel\CodeBlocks
 rem ------------------------------------------
 rem Setup GCC root folder with "bin" subfolder
 rem ------------------------------------------
-if not defined GCC_ROOT set GCC_ROOT=C:\Devel\GCC46TDM
+if not defined GCC_ROOT set GCC_ROOT=%CB_ROOT%\MinGW
 rem change this name to suit your needs
 rem if not defined CB_RUN_UPDATE_BAT set CB_RUN_UPDATE_BAT=0

This seems like a separate change...

[MortenMacFly]

This seems like a separate change...

Ooops - yes, this was needed so I could batch-compile it on my PC.

I'll play with virtual folders in the evening...

[oBFusCATed]

Do you have some feedback, because I want to merge this code in trunk?

[MortenMacFly]

Do you have some feedback, because I want to merge this code in trunk?

Sorry for the late answer, I've been taking holidays for ~2 weeks. I was unexpectedly off-line due to being nearby the Danish border which caused by mobile internet connection to log into the Danish network all the time. To avoid massive roaming costs I had to switch it off completely.

Well up to now I didn't see any crash, bugs, missing features or alike. It seemed to work with already with the version I used dating ~3 weeks ago. If you did further changes since then I cannot tell...

[oBFusCATed]

I've merged the code already...

Also I've found an issue - clicking in the empty space of the tree doesn't popup the context menu

[MortenMacFly]

I've merged the code already...

Ooops - seems I am in the beginning of catching up...

Also I've found an issue - clicking in the empty space of the tree doesn't popup the context menu

Question is: What happened earlier? Maybe it was always like that?

[oBFusCATed]

No, it is a regression for sure, because I've used this feature a lot and now I'm just clicking in the empty space without result.

[oBFusCATed]

The problems is pretty strange. The EVT_COMMAND_RIGHT_CLICK is there, but it never gets fired
Using Connect doesn't work, too. The same code in the old revision works fine....

[MortenMacFly]

The problems is pretty strange. The EVT_COMMAND_RIGHT_CLICK is there, but it never gets fired
Using Connect doesn't work, too. The same code in the old revision works fine....

In which part of the code are you?

[oBFusCATed]

src/src/projectmanagerui.cpp

[thomas]

I only read about 50% of the posts within, but why should GUI code be moved into src at all anyway?

Actually, both sdk and src should preferrably be as GUI-independent as they can be, but surely src even more so than sdk.

Implementing batch build functionality back then was quite a bit of pain due to GUI dependencies, and it still "kind of sucks". A good implementation would allow Code::Blocks for example to run via SSH on a headless machine.

Not that most people urgently need this, but it would be nice to have and very useful, for example if you have one of those modern fuckshit-Atom tablets and want to develop on it while sitting in the garden in summer.
You could edit on the tablet (it's just about good enough for that, if you own a bluetooth keyboard) and compile using a second instance of Code::Blocks that runs on a server in the house (they'd communicate via some sort of IPC), connected via SSH. Or, something different. Compile farm at SF or Amazon cloud if you want.

As it is, that isn't possible, and it will never be possible, because Code::Blocks is tightly bound to the presence of a GUI and a main window (I'm using Windows remote desktop for the same effect, which works fine, but it's a very poor solution compared to something that could be a lot more elegant).

Moving more GUI stuff into src makes the matter worse. If anything, I'd try to move "everything GUI" into a gui target, if that is possible.

[MortenMacFly]

Moving more GUI stuff into src makes the matter worse. If anything, I'd try to move "everything GUI" into a gui target, if that is possible.

Thomas, I think the approach here is similar:

src means GUI, all the time, but thats fine. But then, if the SDK is non-GUI bound, there could be an additional src-nongui target by means of a command line tool or tools. Similar to what VS does: They have dedicated build tools and the UI.

So in the end I think with this approach you can surely achieve what we have in mind.

[oBFusCATed]

Not that most people urgently need this, but it would be nice to have and very useful, for example....

In fact many people need this, we've had tons of request for this feature.

For other things Morten has explained why I'm doing this.

src is codeblocks.exe <-- here we are ok with GUI code, because this is the main app
sdk is codeblocks.dll <-- here we are less ok with GUI code

Unfortunately I'm not sure if this task could be fully completed. The cbProject and ProjectFile classes are too tightly bound to the wxTreeItemID stuff.
Also the cbEditor class is a GUI class in its nature and I'm not sure it could be made less GUI.

[MortenMacFly]

Unfortunately I'm not sure if this task could be fully completed. The cbProject and ProjectFile classes are too tightly bound to the wxTreeItemID stuff.

Maybe a wrapper of the TreeItemID is a solution? So if you are in GUI is uses wx (GUI), if you are in the console it uses a simpler (own) implementation... but I need to look deeper into it to better understand the coupling...

Also the cbEditor class is a GUI class in its nature and I'm not sure it could be made less GUI.

Why would you need cbEditor for compilation purposes?

[oBFusCATed]

Why would you need cbEditor for compilation purposes?

You don't probably, but the cbEditor/EditorBase/EditorManager are part of the codeblocks.dll, so there is a dependence on the gui parts of wx widgets.

[MortenMacFly]

You don't probably, but the cbEditor/EditorBase/EditorManager are part of the codeblocks.dll, so there is a dependence on the gui parts of wx widgets.

...right.

[ollydbg]

Maybe, two sdk dll, one is codeblocks_core.dll (which contains all No GUI), then codeblocks_ui.dll(which contains ui and depend on codeblocks_core.dll)
Then main_ui.exe (depend on codeblocks_core.dll and codeblocks_ui.dll), main_console.exe only depend on codeblocks_core.dll.

[oBFusCATed]

Yes, but someone has to do it...

[ollydbg]

Yes, but someone has to do it...

Ok, but in my mind there are other thing which take more precedence:
1, better CodeCompletion plugin. (I'm not fully understand the currently implementation.... its source are dirty as I see, a lot of lockers....)
2, better GDB plugin support (GDB/MI interface)

[oBFusCATed]

This won't stop a volunteer to work on UI part.

[thomas]

Unfortunately I'm not sure if this task could be fully completed. The cbProject and ProjectFile classes are too tightly bound to the wxTreeItemID stuff.

Though that happened out of lack of thinking, not out of necessity. A cbProject is actually little more than a std::list<ProjectFile>, except it uses the obnoxious wxWidgets containers instead. Same could be said about ProjectFile. There's no reason it needs any GUI, all it does is store some information about a filename, which compiler type to invoke, some custom compile flags, and a few utility functions to make your life easier. None of that needs a GUI. We only tainted it with GUI stuff by accident or out of laziness back then, a decade or so ago.

Also the cbEditor class is a GUI class in its nature and I'm not sure it could be made less GUI.

It's true that an editor is somewhat "necessarily GUI" unless it's a console text editor. On the other hand, the "editor" name is totally bogus, people have written games as "editors" if you remember. So it's perfectly conceivable to write a "null editor" too. One would just have to make sure that the application works fine with whatever editor is loaded, even if it doesn't do anything useful (tbh I don't know if that's the case, but it should be?).

[golgepapaz]

Seems like projectmanagerui.cpp and .h files are not added to other project configurations. (wx29 and wx29-64 are the ones I've noticed)

 

[oBFusCATed]

Windows patch welcomed as I cannot test.
I've just added it to wx29-unix.

[golgepapaz]

will do. Also I've noticed there are other inconsistencies. Many files are missing from some configurations Like project_options ,find_replace , whole propgrid
stuff . Is there a reason to not include them into other configurations? If not I'll try to fix all of them.

[Jenna]

Propgrid is not needed/used/compiled for wx2.9 projects, as it is included in wx2.9.

[golgepapaz]

Here you go. Patch is created in src directory

[oBFusCATed]

In svn, thank you.