Thanks. I am going to rebuild Atlas, but not in Cappuccino, in a new JavaScript-only (no Objective-J) framework im calling cupertino.js. Just looking for feedback on the idea right now.
What will your strategy to be to associate widgets to code? Are you going to have target/action and outlet things you can drag to separately displayed controller source code like with Interface Builder?
Why call it the exact same name as the very-similar-but-not-the-same Cappucino/Objective-J IDE product from 280 North?
Even though 280 North's IDE named Atlas is now defunct, think of all the google-search confusion that will result. It'd be kind of like naming a new GNUStep Objective-C IDE for Linux "ProjectBuilder".
It wont be called Atlas. Right now Im just relating it to Atlas, which like you said is defunct. Im just in the early stages of developing the framework and tools and am looking for feedback.
Ah, I see. Hence the quotes, sorry, I should have gotten that.
I developed some pretty complex apps using Cappuccino and Atlas, before Motorola bought them and shitcanned it. But even before that happened, I stopped using Atlas, and I think there are probably a lot of lessons about how not to make a GUI-builder-IDE-like-thing that one could derive from Atlas (and a lot of similar projects). Doing the GUIs in code actually ended up being a lot easier.
Smart guides and drag and drop are great when they work, but infuriating when they don't snap to the right coordinates, and the inspectors don't let you edit all the properties you need.
My advice/feature request for you and anybody contemplating a similar project is to have some part of your GUI builder that lets the user get 'close to the metal', such that in cases where the GUI to build your GUIs isn't yet smart/sophisticated enough to do what they need, they can directly edit the underlying representation of the GUI objects (which kind implies that it is some kind of human readable textual format)/
E.g., if under the hood your GUI definition is a big JSON structure, have an 'Advanced' tab where you can directly edit that JSON, so that the user can edit literally every single property of the objects when they need to.
Thanks for the advice. You are right, each object is serialized as a JSON structure (freeze dried) and then instantiated when the GUI loads. Definitely that JSON should be editable.
7 comments
[ 6.5 ms ] story [ 29.7 ms ] threadEven though 280 North's IDE named Atlas is now defunct, think of all the google-search confusion that will result. It'd be kind of like naming a new GNUStep Objective-C IDE for Linux "ProjectBuilder".
I developed some pretty complex apps using Cappuccino and Atlas, before Motorola bought them and shitcanned it. But even before that happened, I stopped using Atlas, and I think there are probably a lot of lessons about how not to make a GUI-builder-IDE-like-thing that one could derive from Atlas (and a lot of similar projects). Doing the GUIs in code actually ended up being a lot easier.
Smart guides and drag and drop are great when they work, but infuriating when they don't snap to the right coordinates, and the inspectors don't let you edit all the properties you need.
My advice/feature request for you and anybody contemplating a similar project is to have some part of your GUI builder that lets the user get 'close to the metal', such that in cases where the GUI to build your GUIs isn't yet smart/sophisticated enough to do what they need, they can directly edit the underlying representation of the GUI objects (which kind implies that it is some kind of human readable textual format)/
E.g., if under the hood your GUI definition is a big JSON structure, have an 'Advanced' tab where you can directly edit that JSON, so that the user can edit literally every single property of the objects when they need to.