Now that i’m using much more of what PJ has to offer in anger - such as live-compilation via the JIT engine and viewing and debugging components via JIT - I find myself often asking If I should I add/change this code in the PROJUCER editor or switch to XCode and do it there?.
There’s a lot of command-tabs.
There are of course several things that keep one going back to PJ - to add new source files, debugging-viewing components on the fly using PJ and the JIT. And of course the layout editor if one is [gasp] still using that.
It would be nice to be able to stay more and more just in PJ - using the basic but functional C++ editor there. But clearly there are lots of lacking features one gets in XCode - commenting/uncommenting blocks of code seems to be one I often miss - and end up switching to XCode… and so on. Plus of course refactoring and advanced search.
So there seems to be this nagging question of whether PROJUCER will ever be “grown” to become a "Just-good -enough IDE ( ie primarily for editing C++ source files ) - to do the majority of one’s coding. Of course i’m not expecting any more in terms of targets,build etc - that is fine to stay in XCode, VS etc.
But as far as daily coding goes - adding classes, source files etc… seems to me the more time I would be happy and alble to write lines of code in PJ itself instead of flipping to Xcode - the better.
Whats the long-term plan ROLI / Jules ?
What are peeps thoughts here fellow devs ?
Don’t want to commit us publicly to anything specific, but Ed is currently doing some experiments to see how feasible it is to make the projucer more independent as an IDE…
Juce is a lib. Please don’t lose time reinventing the wheel.
Projucer is great to quickly setup a project but IMHO it’s just shouldn’t do more than that or that would ba a waste of time that can be put inside the lib itself.
Agreed.
One nice thing that cmake has is a check mechanism if the project changed. For instance one could start regenerating the XCode project/VS solution if there was a change, instead of having to launch the projucer.
Well, we have groups of users with very different needs and preferences. Some do want to just open the projucer and use it as a simple IDE; others never use it at all. We want to cater for everyone if possible! But we do put the vast majority of our effort into the library rather than the tools.
I think there’s an opportunity to add C++ code-editing/creation features not currently seen in either Xcode or even CLion - which would make coding much more productive - and dare I say enjoyable and less of a chore. But of course I’m not suggesting adding the entire kitchen-sink of build features etc found in Xcode etc… I don’t see any need for a road plan that actually dispenses with the need for Xcode or other IDES for the “last steps”.
But failing that - if there was some means - by which PJ could monitor the Xcode project source-file structure as changed within Xcode - and automatically update the PJ project metadata so file-structures remained “In-sync” whenever one - for example were to add new C++ source files into the Xcode project, or rearrange source files and folders/groups within Xcode - that would be very helpful. Just in avoiding unnecessary flipping in-and-out-of PROJUCER to do such common tasks.
i don’t really use the live build features because the projucer code editor is a bit clunky. One way to make the situation better might be to make an xcode/vs plugin to trigger the compilation in projucer. See here for a way to make xcode source editor extensions talk to other apps:
and Apple seem to have totally abandoned their past support for Xcode extension - or so it seems. Certainly i haven’t heard of any Xcode extensions in the last few years.
You’re totally incorrect I’m afraid! Alcatraz was an unsupported hack. In Xcode eight Apple introduced source code editor extensions, which are The official way of making extensions for Xcode. There are quite a lot on github. With xc8 at least they are a lot more limited than some of the Alcatraz extensions and xc is sandboxed . I had to use an xpc service to communicate with an external application. This is a legit approach though https://developer.apple.com/videos/play/wwdc2016/414/
Reinforcing what @olilarkin said - Alcatraz wasn’t just a hack, it was an extreme hack. Alcatraz plugins functioned by dumping Xcode’s various framework headers via class-dump and extending them. Alcatraz was killed as collateral damage of massively improving the security, stability, and privacy of Xcode.
Unfortunately, the “official” API for source editor extensions is in its infancy, and almost completely useless (especially compared to Alcatraz). It’s basically a programatic way of doing find/replace and macro keys for adding in chunks of code like comment blocks.
git integration: no - i’d be happy to leave that in Xcode ( now its arrived in 9 ). As you suggest - would be a huge and unnecessary ( for me ) unundertaking within PJ.
code completion - definitely needed. Not trivial though for sure - although maybe the enhancements to CLANG for Xcode 9’s new C++ refactoring features might make this much easier now… dunno
custom snippet integration - nah - can do without - except for the common adding closing brackets for and opening one etc…
but just the most common bread and button refactoring operations, search, and certain other features i won’t go into here - that would make day to day coding - in particular when dealing with methods in classes split into .h and .cpp files - easier and less tedious - yes please.
The majority of my time is spent on Windows, where VS provides a decent git integration now. It’s nice to see which branch you’re on, what the previous commit is, let alone interacting with git itself via the Team Explorer. If anything helps me not context switch as much, I’m happy - to me, this would be a selling point for me remaining within the Projucer.
For myself, I couldn’t care less for the automated refactoring - even AppCode doesn’t always get it right.
