Revision as of 05:17, 12 April 2009 by Cjl (Talk | contribs)
(diff) ← Older revision | Current revision (diff) | Newer revision → (diff)
Jump to: navigation, search

see also Talk:Old Develop activity.

Font size in editor?

I first tried Develop in the beta of Sugar on a Stick. It looks really useful EXCEPT the font in the editor is microscopic. Much too small for anyone to actually use. I get the same result when I tried Develop in my Sugar test environment running on Fedora 10. Since this hasn't been reported as a bug, I have to wonder if there is some workaround to get Develop to use a larger font size.

James Simmons

Journal resume, tabbed editing.

Response to [1], copied here:

Adding tabbed editing has made me rethink how Develop works. Before, when you hit Keep, Develop saved the activity with a copy of the file that you were editing. This way you could come back to an older version. With tabbed editing, my plan now is:

  • each file (eventually, only each changed file) gets an object in the datastore.
  • when we keep, we keep each of the individual files that's opened, and then store the object ids
  • if we want to go back in time, we can resume either an individual file or the whole activity at that time

This means Develop needs to support being resumed with a file or a saved Develop activity. Eventually, it should also support being resumed with an Activity, to start development on that.

I think that for now, keep should bundle up the whole activity. It should automatically do a keep when first started on an activity. When restarted with a bundle, it should check that there is an older bundle of the same activity. If there is, it should overwrite the activity in the unbundled directory structure; if not, it should do a "copy of"-type renaming. To export individual files for editing, there should be another button, not "keep". Homunq 12:43, 5 February 2008 (EST)

Right now, keep just saves all the files. I like the idea of Keep bundling the Activity into an .xo file; but then what happens when we resume? We're no longer talking about a directory on the disk, but a single file. Paulswartz 01:25, 6 February 2008 (EST)

As I said, I think that it should check if there's something to "go back" to. If there is, it should overwrite. If not, it should make a new directory called "copy of ..." or some such. I know, that feels bad for duplicated storage and for dangerous overwriting, but I think it is not as bad as it seems. The current state and future plans for the journal should mitigate or remove both of these problems, I hope.
One thing that this makes me wonder, though, is the logic of having the xo file be compressed with zip. If jffs compresses anyway, there's no win; and the loss is that any future incremental-diff smarts in the journal are just out. But I guess we can cross that bridge, make the format also accept tar or something, if we come to it. Homunq 12:20, 6 February 2008 (EST)
We did a chat on this and thought a bit about the dangerous case when an activity is running and being edited and is resumed from the journal all at the same time. I think that there are solutions but it is tricky. Homunq 17:30, 6 February 2008 (EST)

Dead? Interest?

No activity on the repository on this activity for a while... what is the consensus?

Develop incarnation #3? Start with Pippy, and build/test features slowly?

--Bjordan 14:45, 18 June 2008 (EDT)

Hmmm looks like it is being worked on to me considering there have been several builds of it.

--Tinker 03:41, 1 September 2008 (UTC)

Personal tools
  • Log in
  • Login with OpenID
About OLPC
About the laptop
About the tablet
OLPC wiki