Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
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:
--- Quote from: thomas on July 17, 2013, 01:34:57 pm ---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.
--- End quote ---
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:
--- Quote from: thomas on July 17, 2013, 01:34:57 pm ---Not that most people urgently need this, but it would be nice to have and very useful, for example....
--- End quote ---
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:
--- Quote from: oBFusCATed on July 17, 2013, 03:20:23 pm ---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. :(
--- End quote ---
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...
--- Quote from: oBFusCATed on July 17, 2013, 03:20:23 pm ---Also the cbEditor class is a GUI class in its nature and I'm not sure it could be made less GUI.
--- End quote ---
Why would you need cbEditor for compilation purposes?
oBFusCATed:
--- Quote from: MortenMacFly on July 17, 2013, 03:46:45 pm ---Why would you need cbEditor for compilation purposes?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version