1. It is shown by the context menu in the editorDo you mean both functionalities would be removed? I use the first quite some times.
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.Yes, both of them. The (1) is the same as "Settings -> Editor...", which is not that much harder to reach.
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.
Is there any technical reason for the singleton infestation caused by the Manager?Sure - There should an can only be one project manager..?!
Sure - There should an can only be one project manager..?!Why? What if I want to have two workspaces loaded?
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... ;-)
hmm, and a war on singletons is starting ;-)No, because it will take years to remove them.
Here you can find the current status of the work.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?
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?1. I'm not using svn any more. All my svn checkouts are put inside git repos.
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 rebase master will put them at the topMy 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.
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 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.
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 :)
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).
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.
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...
anything special one should test?Virtual folders, I never use them :)
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...Ooops - yes, this was needed so I could batch-compile it on my PC.
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.
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?
The problems is pretty strange. The EVT_COMMAND_RIGHT_CLICK is there, but it never gets fired :(In which part of the code are you?
Using Connect doesn't work, too. The same code in the old revision works fine....
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:
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.
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?
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.
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. :P :-\
Yes, but someone has to do it...Ok, but in my mind there are other thing which take more precedence:
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?).