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