SDK refactoring for non UI builds

[oBFusCATed]

BTW: Is there any reason for this code to be part of the sdk and not part of the application in src?

For me this (having gui code in the sdk) is one serious problem, which we have to fix in the future.
So if these two files can be move in src/src I'll be happy:)

[dmoore]

BTW: Is there any reason for this code to be part of the sdk and not part of the application in src?

For me this (having gui code in the sdk) is one serious problem, which we have to fix in the future.
So if these two files can be move in src/src I'll be happy:)

Right now, those dialogs get used by code snippets, but I suspect it would be better for CodeSnippets to have their own. I think it will be difficult to remove all of the dialogs from the SDK because some should be accessible to plugins. Find/replace might be a good candidate though.

Still not loving the find/replace dialog after my latest changes. The multi line option creates a bit of a mess. Not sure why it is necessary because you can do virtually the same in a more robust way in a single line of regexp. I will play with the layout some more...

Furthermore, the modeless operation of thread search and incremental search plugins seem to be a better model. I think this is the way to go. I will experiment with porting all the good bits of those plugins across.

[oBFusCATed]

I think it will be difficult to remove all of the dialogs from the SDK because some should be accessible to plugins.

Examples?

[MortenMacFly]

Examples?

Well you never know - that's why the dialogs are part of the SDK, isn't it? Plugins might use it and I could think of use-cases for many dialogs. For example: a language (like Fortran) specific find dialog. For such it would be nice if you could simple derive from the existing class and change what's needed. I wonder what's so bad about it.

[MortenMacFly]

...reminds me on something else I noticed with the ThreadSearch dialog: I regularly become warnings that ThreadSearch tries to find in binary files, like icons. This is rather annoying and makes me use the "normal" find dialog more often.

[oBFusCATed]

For such it would be nice if you could simple derive from the existing class and change what's needed.

For a class to be derivable, it should be designed with this in mind and I doubt this is the case for most of them.

I wonder what's so bad about it.

Because we can't have a console-only executable on linux, which can be used for building cb projects.

...reminds me on something else I noticed with the ThreadSearch dialog: I regularly become warnings that ThreadSearch tries to find in binary files, like icons. This is rather annoying and makes me use the "normal" find dialog more often.

Fix your file mask and you won't get such problems.

[MortenMacFly]

Because we can't have a console-only executable on linux, which can be used for building cb projects.

I think a more clever way would be to re-factor the build system and compiler plugin so it offers a way to be bundled into a console version. You don't need any UI/other plugin if you want to compile from console.

Fix your file mask and you won't get such problems.

My file mask is: "*.cpp;*.c;*.h". Something else is wrong - it might be related that I search the whole workspace. It seem to happen only then.

Edit: Concerning: "You don't need any UI/other plugin if you want to compile from console" - maybe you do: the EnvVars plugin.

[MortenMacFly]

I think a more clever way would be to re-factor the build system and compiler plugin

BTW: What I did in one of my own applications that is similar:
- all classes accessing files are based on non-GUI components (and are also part of a SDK)
- for the UI version of the software I have a gateway class that "connects" low-level stuff to high-level UI events/commands.
- for the non-UI version I use this specific part of the SDK decoupled and wrapped with a command line interface around it.
In a similar fashion the build system could be designed.

Also, for these things I wonder why people don't simply use i.e. the Makefile generator available for Code::Blocks. OK - it won't be scriptable and alike, but would you need it for such special cases?

[oBFusCATed]

Also, for these things I wonder why people don't simply use i.e. the Makefile generator available for Code::Blocks. OK - it won't be scriptable and alike, but would you need it for such special cases?

Because we advertise it as working, try codeblocks --help  

[Jenna]

Because we can't have a console-only executable on linux, which can be used for building cb projects.

I think a more clever way would be to re-factor the build system and compiler plugin so it offers a way to be bundled into a console version. You don't need any UI/other plugin if you want to compile from console.

Fix your file mask and you won't get such problems.

My file mask is: "*.cpp;*.c;*.h". Something else is wrong - it might be related that I search the whole workspace. It seem to happen only then.

As far as I know, the filemask is not used in this case, all project/workspace files are used.
The filemask is only used when searching in a given directory.

EDIT:
That's why the possibility to ignore some errors was added in the config-dialog, we might add one to ignore e.g. binary file-errors.
This should be easy to implement. I can do this.

Edit: Concerning: "You don't need any UI/other plugin if you want to compile from console" - maybe you do: the EnvVars plugin.

In this case a user should either use cb_share_config to export the envvars or set the needed vars in a shell-script and run C::B from inside it.

[killerbot]

Also, for these things I wonder why people don't simply use i.e. the Makefile generator available for Code::Blocks. OK - it won't be scriptable and alike, but would you need it for such special cases?

Because we advertise it as working, try codeblocks --help  

using CB from within CI is great and powerfull, no need for makefiles, the console branch for that matter, and when the next step is there that it can also run plugins, then you could have a target that runs a valgrind sessions, a cppcheck, a doxygen, and so on ...

[MortenMacFly]

Because we advertise it as working, try codeblocks --help  

Yes, but we don't advertise its working w/o UI. And batch build is working just great - I do it nearly every day. Its really fast and has a lot advantages in contrast to Makefiles. What I meant is if you really need a build w/o UI you could do it with the Makefile generator. Jens did a trial in the console branch - this could be a starter for what I had in mind (or maybe a solution already).

I know it would be nice to have the build system decoupled - but I think the effort of re-factoring the whole SDK - especially removing all UI parts to achieve this - is just too much if there are other way easier possibilities. Just my 2 cents...

[oBFusCATed]

Yes, but we don't advertise its working w/o UI. And batch build is working just great - I do it nearly every day. Its really fast and has a lot advantages in contrast to Makefiles. What I meant is if you really need a build w/o UI you could do it with the Makefile generator. Jens did a trial in the console branch - this could be a starter for what I had in mind (or maybe a solution already).

Yes, but you're a windows user and the ui is built-in. On linux you can have pure systems without ui, there it is not working.

I know it would be nice to have the build system decoupled - but I think the effort of re-factoring the whole SDK - especially removing all UI parts to achieve this - is just too much if there are other way easier possibilities. Just my 2 cents...

We will see in the future. Anyway having less gui in the SDK will always be good.

[MortenMacFly]

Yes, but you're a windows user and the ui is built-in. On linux you can have pure systems without ui, there it is not working.

I know, but the batch build feature was never intended to be used without UI, just for batching C::B in a UI capable environment.

However - I indeed have a question: I don't use Linux regularly as you know - so what is the use-case actually that you need to compile projects on a OS without UI? From my limited point of view it only makes sense to compile console projects under such OS'es as everything else won't work. And this works just fine with a Makefile export. Why would you want to compile more complex projects (i.e. UI capable ones) on such OS'es where you cannot test what you've compiled and need a UI capable OS then anyways? This isn't clear to me.

[Jenna]

It's very useful for build-robots for example.