Move some GUI code from sdk to src

[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.