Thanks for the reality check. But:<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>I don't see any reason to include Glade, unless you also intend to include

complete a complementary graphical interface builder tuned for Activities.  That would be a multi-year project. </blockquote><div> I disagree, it's just a matter of making a widget catalog. The reason I ask now, at the start, is that if eventually I plan to do this - and there ARE real advantages, for instance it makes it much easier to make an app which works on Sugar and other platforms - I want to do Develop itself with libglade. I do not plan to spend any time making the GUI editor until I have a usable release.

<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>I feel strongly that you are making Develop too ambitious.  A simple Python

editor that supports collaboration and editing copies of installed activities would be groundbreaking, and cause for celebration.  It would be the most revered Activity of all.</blockquote><div> Version control is at the heart of real collaboration. How many real-world programs are done with pair programming? How many of them use version control?

But actually, both of these are gravy. I want to first make something with neither. But I'd rather know what I'm working towards before I start. As for "copies of installed activities", you're right. I was wasting time worrying about copy-on-write hard links, I should just copy for now and get to that later. Still, for all my talk, I was not coding any Bazaar in, just copy-on-write.

As for translatable code, sorry, that's the horse I rode in on. It's the reason I first looked at the wiki and learned about the project beyond the headlines. It's not in step one, but personally speaking its what I want to contribute, and what I'll be working on as soon as step 1's done.

</div></div><br>Jameson<br><br>ps. I'd feel better about how source control 'might be solved by the journal' if I had more of a sense of the plans and priorities there. Even the most basic possible Develop is going to be pushing the envelope (and helping fine-tune the spec) with both Bitfrost and the Journal. Yet the only coherent docs for either are way out of date, and though both are heavy with promise, even the present reality is underdocumented, let alone the future plans. If there are any secret archives on these, it would be great to know. 

<br>