I hope you don’t put all this in the main JUCE repo. It’s already got too much stuff in it, I wish that JUCE had its own repository, with the demos and extras in a separate repository (but keep the static library projects with JUCE sources so we can browse).
Nope, I’m not going to do that.
In fact, I may not even open-source it at all - I’ve not yet decided exactly what I’m going to do with it.
I think you should polish it up, frame it, and mount it on the wall in the living room and go back to giving JUCE a good beating with your enormous talent. I’ll take a TextEditor with centered justification (for example) over clicking on a piece of code to change an RGB colour any day of the week. Besides, have you seen those awesome colour constants in juce_Colours.h? They stir the emotions… juce::Colours::lemonchiffon or juce::Colours::dodgerblue have a much nicer ring than “H=123, S=210, B=90” don’t ya think?
If this could be turned into a suitable replacement for Visual Studio that would be awesome. One with a good debugger that works on all platforms and uses a good compiler, so we can use c++11 on all platforms. If this was available, I would probably switch to Linux for development. But the lack of any serious alternative to Visual Studio is a major obstacle.
Visual Studio 2012 looks like a shitpile and I’m not looking forward to being forced to “upgrade” to Windows 8 just so I can have improved tools (and its questionable if the new VS is really an improvement).
Yes, I think the ultimate goal is to build it up into a full IDE. But even before it gets that far, it’ll still be extremely useful.
For the initial version, I want it to offer enough functionality that you’d spend perhaps 30% of your coding time using it. Managing your project files and settings, writing and testing individual components and bits of code, quickly being able to run the app (but without any debugging support). And you’d spend the other 70% of your time in the various native platform IDEs doing your debugging and misc development.
But when I’ve added a debugger (and thanks to lldb that’s probably not quite as scary as it sounds), I reckon it’d provide enough functionality to spend the majority of your dev time in the projucer, only needing to switch to a native IDE for the edge-cases, and to compile your release binaries.
I totally agree with you about the lack of a good cross-platform IDE, so I guess this is really my attempt to build the tool that I want to use myself. And since I’m extremely hard to please, I hope that if I can make something that I’m satisfied with, then other people will like it too. I mean… it really can’t be that hard - there are lots of people who actually like eclipse… and that’s a god-awful mess of an app! Surely I can create something better than that!
Wow! I love it.
What about the components that have been created with the Jucer, will the XML that describes the layout and such be stripped automatically when we use the Projucer or do we need to do that ourselves.
From the projucer’s point of view, they’re no different to any other component. The XML comments are just comments, so it’ll ignore them - you could remove them if you wanted to, but it wouldn’t make any difference.
Ok cool, although the XML (for layout) wouldn’t be up to date anymore when you start moving things about with the Projucer. So a strip step to remove old Jucer comments/xml could be handy.
Can you post a style example of a file created in ProJucer? For instance, a light version of the WidgetsDemo?
Bruce
It’ll look like any of my hand-written classes! That’s really the point, there’s no metadata or anything to distinguish it from normal code.
Microsoft is dying and soon we will lose the best IDE, and there’s no replacement on the horizon.
Microsoft is dying and soon we will lose the best IDE, and there’s no replacement on the horizon.[/quote]
I find QtCreator pretty good. Being cross-platform is a major deal - the same UI for all OSes!
(I think I’ll create a topic on how to set it up with Juce… )
You know, Code::Blocks isn’t bad, and the latest Linux desktop setups are pretty sharp. I actually like it better than the last two Mac OSes, to be honest - at least from casual use.
I can perceive of ProJucer + debugging being very usable.
Jules - remote debugging or running with ProJucer? Doing those nifty changes between machines?
It’s a sidebar, but Value changes across the network would probably cover that, and be very useful all over.
Bruce
[quote=“falkTX”]I find QtCreator pretty good. Being cross-platform is a major deal - the same UI for all OSes!
(I think I’ll create a topic on how to set it up with Juce… )[/quote]
Qt Creator is the next best thing, for sure. It has a great editor, nice integration with gcc. I’d like to see LLVM support as well. The problem with Qt Creator is that linking to the static runtime (instead of the DLL) is a pain in the ass. I was never able to get it to work. If IntroJucer could add an export target for QMake that resolved the static linking problems, I would switch to it (both IntroJucer and Qt). Note that this is a problem with MingW and not Qt directly.
[quote=“TheVinn”][quote=“falkTX”]I find QtCreator pretty good. Being cross-platform is a major deal - the same UI for all OSes!
(I think I’ll create a topic on how to set it up with Juce… )[/quote]
Qt Creator is the next best thing, for sure. It has a great editor, nice integration with gcc. I’d like to see LLVM support as well. The problem with Qt Creator is that linking to the static runtime (instead of the DLL) is a pain in the ass. I was never able to get it to work. If IntroJucer could add an export target for QMake that resolved the static linking problems, I would switch to it (both IntroJucer and Qt). Note that this is a problem with MingW and not Qt directly.[/quote]
I just tried a new Juce project, and it builds fine in Linux.
Here’s the project file:
[code]# QtCreator project file
CONFIG = debug
CONFIG = release
CONFIG += warn_on
TARGET = NewProject
TEMPLATE = app
SOURCES =
Source/*.cpp
JuceLibraryCode/modules/juce_core/juce_core.cpp
JuceLibraryCode/modules/juce_data_structures/juce_data_structures.cpp
JuceLibraryCode/modules/juce_events/juce_events.cpp
JuceLibraryCode/modules/juce_graphics/juce_graphics.cpp
JuceLibraryCode/modules/juce_gui_basics/juce_gui_basics.cpp
HEADERS =
Source/*.h
INCLUDEPATH =
JuceLibraryCode
Source
QMAKE_CXXFLAGS = -std=c++0x
unix:!macx{ # linux
CONFIG += link_pkgconfig
LIBS *= -ldl -lpthread -lrt -lX11 -lXext -lXinerama
PKGCONFIG = freetype2
}
[/code]
I can make a project to build a static juce lib if you want to try it out.
Am I being dense? If you like Qt, why wouldn’t you use Qt (now it’s not a billion dollars per seat).
If you prefer Juce, doesn’t it make more sense to point out what about Qt’s IDE is good, so that Jules (who is obviously going ahead with this, now he’s come so far) can make sure Projucer matches up?
Don’t get me wrong, after 15 years of flitting between IDEs from platform to platform (I still miss Codewarrior, where I can make exe’s on my Mac) I’d love to standardize, even better if it did cross-compiling, but I also think Juce is the way forward. Qt is way too quirky for me, although I love the feature set. If I’d have liked their tools more, I wouldn’t be here.
Jules - have you considered that this new direction may be Earth-shattering enough for you to gear up a bit and expand your team?
Bruce
I do use Qt actually, and I prefer it over Juce - main reason being that Juce on Linux has its issues (but I’m no X11 expert to help).
Juce has its good points againt Qt though, specially in Audio. And I have great plans for Juce in distance…
but in any case, I don’t see what’s bad in using a Qt IDE to build Juce stuff.
A Juce-based IDE would be ideal, but this sord of thing takes a lot of time to create.
Yep, you’re being dense 
There’s often confusion between Qt the cross platform library (which I do not like) and Qt Creator the IDE. It is possible to use Qt Creator to build apps that are not Qt apps. It uses MinGW for the back end and gdb for debugging I suppose. There’s a problem when you try to link with the C runtime statically. It is described in more detail here:
Why Does Static Build use DLL Runtime?
I tried to fix it using various “tips” from the web but failed.
Qt Creator as far as the IDE goes, has a lot to like! It was designed for speed. In terms of keyboard shortcuts, minimizing the use of the mouse, intelligent window panes. Very nice and fast redraw of text in the editor, and crisp font rendering that is easy to read. It has a nice layout of the build panels and the source code browser. Pretty decent auto-complete and symbol browsing and find in files. It has these shortcomings:
-
Problem with the static linking of the runtime
-
Confusing system of setting build switches and what not
-
Debugger could use work
Impressive, indeed.
Just to refocus the discussion, I wonder if a debugger is required at all, once you get realtime update when you modify it ?
I mean, you need a debugger for:
- Inspecting/Set the values for a variable (which you can probably add for almost nothing already)
- Pausing/Resuming execution of threads (deal with the JIT machine ?)
- Get the callstack (which is easy with backtrace or contact me for a demangling - real backtrace walker)
- Display signals/exceptions (again, the JIT machine could probably be configured to log such events)
On the sad note, in Visual Studio’s debugger, you’ve the feature called “Edit and continue”, which is not as fast as what you’ve shown, but it’s 99% of what you’ve shown (that is, realtime editing & compiling & linking of the code in a running process). When doing GUI work, I usually do it with the debugger running for this exact feature.
I wonder if the current demo hold the “state” of the application when applying the changes in the code ?
I mean, let’s take the example of the Juce’s Demo, if I run the Projucer on the demo, navigate to whatever component, and then change some values in the code for that component, will it update in the component I’m seeing, or, will I need to navigate to the same component like if the main process was restarted ?