Status of Develop.activity?

[Jameson "Chema" Quinn]

>
>
> Hey folks:
>
> I'm glad to see some interest in getting the Develop project going
> again.
>
> A few comments/notes:
>
> - we really need to hash out the requirements for the first iteration.
>

You, who have actually worked on this, are probably best positioned to make
a first draft... This email covers the trickier cases, I think almost
nothing here is a v0.5 requirement. I'd like to see your ideas on what is.

>
> - version control.  Activity Sharing (see below) only really covers the
> Pair Programming use case.  The version control concept covers a range
> of other issues.  Develop should track changes made by programmers, and
> provide them with a means to share and merge their changes. This one I
> spent a fair amount of time on.  The current version of Develop uses bzr
> for version control, and it actually works in a very minimal way (or
> did, anyway).  However, by doing so I was duplicating logic; in my view
> the correct approach would be to truly use DataStore/Yellow as our
> storage mechanism.  However, the DS isn't a true source code management
> system with merging and distributed history.  The models just don't
> *quite* fit.


Even  though this is probably not an initial requirement, it is clearly an
eventual feature. It would be great to hear some more details of what it
actually did with Bazaar and what would/would not have worked with Yellow.


>
> - the editor component has already been prepared for us;  AbiWord has
> added source editing features like a line number ruler, syntax
> highlighting, and of course the collaborative editing mode (which will
> be very useful for Pair Programming).


This is one case where an important decision needs to be made up front. In
favor of Abiword, there is the collaborative editing mode, and to a lesser
extent there are probably some minor UI quirks which will be familiar to
users from the Write activity. In contra, there is the data model. If we
hope to have live syntax coloring, translation, rudimentary error checking,
drag+drop UI editing while the source file is open, etc., we will want
higher-level code to be intimate with the data structure which holds the
text, able to link an arbitrary span of text with an arbitrary in-memory
data structure. But the AbiWord project (to their own chagrin) has no
concept in their data structures of "an arbitrary span of text". Formatting
is turned on and turned off by separate tags, not start/end tags.

My own instinct is that in the long run, it will be easier to add
collaboration to a clean underlying model, than to inherit and shoehorn a
giant codebase into a use it was not really designed for. There is a real
sacrifice there, though: it means that collaboration will come much later.

I've touched this issue with Andrew and I think we sympathize somewhat with
each other but not enough to change our overall vote. It would be good to
get some other opinions.

>
>
> - Pippy and Develop should be worked on in concert.  Right now Pippy
> just uses gtksourceview, and really should end up sharing a lot of
> common logic.


Check.

>
>
> - Chema's been looking into internationalising Python.  I do not envy
> him in this task. :)


That's me. It is, indeed, a bigger task the deeper I dig. I still think it's
feasible though, and worthwhile especially for OLPC.

>
>
> Develop also proved tricky to work on, simply because I was outside of
> OLPC proper.  Develop will likely require some work done on the design
> of the sugar platform itself (the DS comes to mind).
>
> The current code is rather over-engineered.  I tried to create a
> so-called "object model" to describe every aspect of an Activity, and
> eventually got lost in a big pile of classes and interactions.


Develop clearly needs some MINIMAL awareness of all the parts that make up
an activity. That includes source, graphics, .po language files, etc. I
think that it should do as little magic handling of interactions as possible
though - don't fix things for me, just give me the right tool to do it
myself.

>
>
> I began to tumble down the rabbit hole of stressing over all these
> issues, rather than focusing on having a minimal program that does the
> simplest thing that could possibly work.  I did have a working tabbed
> editor with TreeView and bzr version control, but it was very slow when
> working with large trees.  Eventually I ended up losing interest simply
> because I didn't really have much to show for my efforts, and now the
> code is both broken and incompatible with the current version of Sugar.
> Shame on me.
>
> I think it might be appropriate to start over, and merely use the
> current version as a reference.


>
> What do you guys think?


Starting over sounds good. However, as I said above, I'd love to hear some
more details about lessons learned - I'm sure you know more than your source
code comments.

>
> >
> --
> Regards,
> Andrew Clunis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.laptop.org/pipermail/devel/attachments/20071206/85edb149/attachment.html>