I don’t think the problem of this discussion is that the JUCE team has better things to do. Adding some lines of code to let files be temporarily disabled from the build process sounds like an evening of work or a week at best. And it would get us both the ability to keep track of cool outtakes and a nice workflow for refactoring files that skips the need to make multiple repositories of the same thing. The JUCE team is working on some much bigger things, like web views, that require much more thought and development time and it’s not even clear to me why we need it.
The real problem that I see in this discussion is that people just read “Projucer” and immediatly think “wasted development time” because for them it is not a professional tool, but just the thing beginners use before daring to learn CMake. But I see it more as a project management tool, and it has the potential to become as big and useful as any other project management tool out there.
Also I think there is a bit of a pretentious energy in this forum. People trying to look all professional by distancing themselves from anything that could look “chaotic”. You guys pretend like you always sketch out the perfect code structure on a piece of paper before you start coding and once you started writing it out it can just be thrown into a sub module and never be touched again and things are never interconnected in weird ways that just make you want to rewrite a bigger part of it. I’m just honest, my first attempts at writing some code are rarely the best ones, so I rewrite things a lot until I feel good about it. And if I am not the completely only person in the world who does that my feature request is alright.
You act as if you’re the only creative coder here. Very arrogant viewpoint.
You can even experiment with new code without using branches. You can change your code over and over again as long as you commit between these changes. Now you can compare one commit against another easily. All without creating branches. And yes, you can certainly view and compare branches and/or commits with each other.
Hey, I was not the one who started talking about wether or not coding is creative. I’m just reacting.
But you can’t read the code of both commits at the same time. When I think of refactoring code I have 2 things in mind. Thing no 1 is the stuff I wanna do differently this time. I have an idea in my head how the structure should be different and I follow that idea from my mind. But thing no 2 is all the stuff that should still work the same as before. I might not have every detail of that in mind, it’s just something that requires to copy/paste stuff from the last attempt. That’s why it would be cool to see it side-by-side.
It’s not even that I’m the first person who ever wanted to do something like that. For example the software “Beyond Compare” is designed to let you compare 2 different (but similiar) projects with each other in order to copy stuff from one side to the other. My idea is similiar to that, but not about comparing whole projects, but just about managing the currently not-used stuff of a project.
Once again, that doesn’t really address what we’ve been discussing so far.
Commits are primarily for updates and fixes that show clear, linear progression and have a motive.
Creative modifications exist in superposition.
I think many would deem it important to maintain clear separation between the two.
@PeterRoos Would you say there is no benefit to using the Projucer’s Comboboxes over using Macros?
I find it slightly alarming that a post with 1 vote is being targeted with replies that mimic the argument “Why even suggest your workflow when I believe there is a better one.”
It’s starting to seem like the motivation here is less about a lack of affinity for the request and more about a lack of personal affinity.
that wouldn’t make a difference. you might vote NO on this workflow request. but I would vote NO on web views and all that fancy stuff I don’t care about, not because any of us made an informed decision, but simply because we have no idea what the other person is talking about. What I try to say is: This whole voting system for feature requests is kinda flawed and doesn’t really reflect what should actually be done. For example if people just don’t vote for my FR because they don’t like the Projucer, then that wouldn’t do my idea justice, because it requires the base assumption that the Projucer is something valuable to begin with. If all people, who hate on the Projucer every single time they have the opportunity to, were banned from participating in discussions about its development there’d be relatively more positivity about good ideas. That’s why you don’t see me in the WebView posts. I have no idea why you all want them, but maybe I’ll find out one day until then my opinion about WebViews is of limited value. But as a Projucer user I can tell you something about its workflows.
Of course, you can view different commits side by side. Numerous Git tools are available that can do just that.
All I’m saying is that we have tools for that. There are easy methods without renaming files, namespaces, copying files to old projects, etc.
What should a developer do? Use the tools specifically designed for these things, or devise a chaotic, time-wasting way to achieve the exact same?
The JUCE team only has so much bandwidth. This ill-advised feature request should be ignored. It only benefits a tiny minority that doesn’t know how to use their tools.
ok maybe we should focus on that. If these methods exist, what do they actually look like? what do I have to do to have the best workflow? How can I use Git to maximize the workflow in this exact kind of situation, where I would typically want to refactor a bunch of files while watching their last state on a 2nd monitor? If you can convince me that the workflow is cool I would have to agree that this FR is ill-adviced
The easiest possible way, IMHO, would be to first commit the previous state (before the refactor), and then while you’re making local changes you can look at the previous state in your browser in the GitHub code viewer.
Yeah, I’d agree that this would not be a much worse workflow than disabling files in the Projucer. But it wouldn’t work for the usecase of keeping track of outtakes, that I described earlier. So it’s not 100% there
I use TortoiseGit. Without uploading anything, I can right-click on a file, show its individual history, and display the code from that commit in a window. The code can then easily be dragged to a second monitor to act as a reference. You can do that with files, folders, commits, branches, etc., without ever uploading anything anywhere. It will show you your own local Git history.
There are similar tools available on macOS, too. SourceTree, GitKraken, etc.
Modern IDEs can also show you which lines you’ve changed, and you can hover over the “changed” marks to see the old code.
I’ve also opened a browser and looked at older files via our private GitHub repo, because it was convenient then.
The point is that the Projucer is not a source control tool. At one point the JUCE team did seem to have a vision of making it into a full-fledged IDE / project management tool, but those efforts have been largely abandoned since the addition of CMake support to JUCE. Not to further derail this thread, but my opinion is actually that the Projucer should be deprecated. Even if that never happens, I think it’s unlikely the JUCE team will invest significant time into adding new features to the Projucer any time soon.
I use Fork as a Git management tool. I like that it’s visual and easy to use. The fact that its control is very limited to the most basic Git commands makes it nice and approachable and less errorprone than tools where you can break a lot accidently. Maybe some of the tools you suggested are also like that, and if they have a feature where you can look into some fragments of older code without having to load the whole repository another time, you might be right and it would be a good workflow too.
Alright guys, we have 2 valid alternative workflows now. They are not perfect, but they are also not bad. I think that proves that my feature request is indeed not the most significant feature request of all time. But I would still say it’s useful. First of all because disabling files is still a better workflow than the other 2, even if it’s only a little bit better, secondly because it’s probably really easy to implement and not an ambitious project that really consumes development time from other features and 3rdly because it’s always nice to have different similiar workflows available, even if all of them accomplish the same thing. It relaxes development by enabling the programmer to not always have to think in a strict sequence of actions, but just in whatever way human thought forms
If you don’t want to wait for the JUCE team to get around to this feature request, you could make your own fork of JUCE and add whatever features to the Projucer you want. Then you can tailor the workflow to be exactly the way you want it for your projects.
that would make a lot of sense if new updates of the framework wouldn’t overwrite the whole Projucer everytime they are pulled. And I don’t wanna miss out on everything that is added to JUCE just because I have a few additions
That’s not how git works. If you have a fork that has diverged from the upstream, you can always merge new upstream commits into your fork without losing your changes. You may have to resolve merge conflicts, but it won’t overwrite your changes unless you tell it to.
