Path to IDE

[msteghofer]

Independently of the chosen compiler, there is always an (sometimes deactivated) input field for the Path to Visual Studio. We could replace this by a set of input fields that depend on the chosen compiler. That would have the following advantages:

• We can store paths to (non-default) kdevelop and make installations and use them to launch the IDE and to compiler stuff automatically
• We can distinguish between several Visual Studio installations. The selected version will be used both as the target type for CMake and to call the correct IDE/compiler.

There could be the following input fields:

Visual Studio:

• Path to the installation directory of every specific version (can be used to launch IDE and to compile automatically)

KDevelop:

• Path to the KDevelop executable (to launch IDE)
• Path to Make executable (to compile automatically)

Unix Makefiles:

• Path to Make executable (only to compile, no IDE)

Qt Creator (we can then add Qt Creator, internally use the target "Unix Makefiles" and when it comes to launching the IDE we know that the user wants to use Qt Creator and where it can be found):

• Path to the Qt Creator executable (to launch IDE)
• Path to Make executable (to compile automatically)

[mnieber]

Hey Martin,

this is what the new GUI in the dev branch does. I started working on merging my dev branch with the main branch (doing small changes in the main branch, and big ones in my dev branch, with the idea of merging them in the end), but then I was halted because Yves wanted to review my changes to the main branch (but I think he is not working on that).

Maarten

---

From: msteghofer reply@reply.github.com To: hallomaarten@yahoo.com Sent: Monday, August 8, 2011 2:17 PM Subject: [CSnake] Path to IDE (#38)

Independently of the chosen compiler, there is always an (sometimes deactivated) input field for the Path to Visual Studio. We could replace this by a set of input fields that depend on the chosen compiler. That would have the following advantages:

• We can store paths to (non-default) kdevelop and make installations and use them to launch the IDE and to compiler stuff automatically
• We can distinguish between several Visual Studio installations. The selected version will be used both as the target type for CMake and to call the correct IDE/compiler.

There could be the following input fields:

Visual Studio:

• Path to the installation directory of every specific version (can be used to launch IDE and to compile automatically)

KDevelop:

• Path to the KDevelop executable (to launch IDE)
• Path to Make executable (to compile automatically)

Unix Makefiles:

• Path to Make executable (only to compile, no IDE)

Qt Creator (we can then add Qt Creator, internally use the target "Unix Makefiles" and when it comes to launching the IDE we know that the user wants to use Qt Creator and where it can be found):

• Path to the Qt Creator executable (to launch IDE)
• Path to Make executable (to compile automatically)

Reply to this email directly or view it on GitHub: https://github.com/csnake-org/CSnake/issues/38

[msteghofer]

OK, that's good to know. Then we wait for that review and decide then how to go on (if your branch is too far away from the master, maybe it's worth creating a new one and trying to do the same changes there again based on your changes in the dev branch - instead of trying to automatically merge all that). Yves was on vacations for some time, that's why he couldn't review anything. Anyway there's no hurry at all! It's done when it's done. Can we assign you for this issue then - now that you've already done the work? Btw. does your branch do anything else new than this issue? Then you might create a new issue for that stuff.

[msteghofer]

Sorry about the two commits that popped up above. They were just experiments about git/github and didn't actually have anything to do with this issue. I didn't think that they would still be visible here after deleting that experimental branch. But it looks like github doesn't call the garbage collection very often (or not at all). Let's hope they disappear at some point!

[mnieber]

Hi Martin,

don't worry! :-) Maarten

---

From: msteghofer reply@reply.github.com To: hallomaarten@yahoo.com Sent: Wednesday, August 10, 2011 7:13 PM Subject: Re: [CSnake] Path to IDE (#38)

Sorry about the two commits that popped up above. They were just experiments about git/github and didn't actually have anything to do with this issue. I didn't think that they would still be visible here after deleting that experimental branch. But it looks like github doesn't call the garbage collection very often (or not at all). Let's hope they disappear at some point!

Reply to this email directly or view it on GitHub: https://github.com/csnake-org/CSnake/issues/38#issuecomment-1774546

[msteghofer]

I've had a look at the GUI in the development branch and have got 2 remarks:

• The changes in the GUI were mainly about the "Options" tab and implement in part, what I've proposed in this ticket. However it's only a first step, there are more changes necessary to implement the features of this ticket, especially behind the scenes: E.g. the same path is used, independently of the chosen IDE (paths to different IDEs should be stored separately); there is always only one IDE path, but e.g. for KDevelop you need two.
• The development branch is really, really far away from the master branch. I think it's nearly impossible to merge them or possible only with an unreasonable amount of work.

So what I would propose for this ticket is the following: We stop trying to merge the whole development branch, but pick out the code that is interesting for the implementation of the features proposed here.

And for the development branch in general: We could make a list of the features that the development branch has and master doesn't have (maybe as github issues). Then transfer them one by one to the master branch, copying code if possible, rewriting code if necessary (where the branches have diverged too much).

What do you think, Maarten and Yves?

[mnieber]

Hey Martin,

my idea was to only swap the GUIs, since the new GUI has much cleaner code. I'm not saying that this is per se the direction we should choose, but what I managed to do was to use the development branch GUI with the core from the main thread. If you prefer to cherry pick some changes from the dev branch, that would also be fine. My main concerns with the current main branch are:

• i think the main branch GUI code is not clean (hence my proposal to use the dev branch one)
• some dev branch GUI features area real improvement, mainly the use of marker files (small text files in your source tree that tell csnake GUI where all the source folders & third party folders are, as well as other information that the end-user would otherwise have to set manually in the GUI)
• in my opinion, some parts of the main branch are not clean, such as the use of Listener wherea simple callback object would be sufficient

Im just giving my opinion (and at the moment, I can't do much more :-) ) Best Maarten

From: msteghofer reply@reply.github.com To: hallomaarten@yahoo.com Sent: Wednesday, August 24, 2011 6:05 PM Subject: Re: [CSnake] Path to IDE (#38)

I've had a look at the GUI in the development branch and have got 2 remarks:

• The changes in the GUI were mainly about the "Options" tab and implement in part, what I've proposed in this ticket. However it's only a first step, there are more changes necessary to implement the features of this ticket, especially behind the scenes: E.g. the same path is used, independently of the chosen IDE (paths to different IDEs should be stored separately); there is always only one IDE path, but e.g. for KDevelop you need two.
• The development branch is really, really far away from the master branch. I think it's nearly impossible to merge them or possible only with an unreasonable amount of work.

So what I would propose for this ticket is the following: We stop trying to merge the whole development branch, but pick out the code that is interesting for the implementation of the features proposed here.

And for the development branch in general: We could make a list of the features that the development branch has and master doesn't have (maybe as github issues). Then transfer them one by one to the master branch, copying code if possible, rewriting code if necessary (where the branches have diverged too much).

What do you think, Maarten and Yves?

Reply to this email directly or view it on GitHub: https://github.com/csnake-org/CSnake/issues/38#issuecomment-1891248