Dan Williams wrote:
One thing we had discussed with respect to an IDE was that it should
hide all directory structure in the GUI. The child could create
categories or something, but there's really no reason whatsoever to
expose that when the only thing that needs it is the activity.info file
and the icon, both of which are in the same directory.
We don't have a "file manager", so there's no other place where
directories are/should be exposed right now. "objects" added to the
project (be they icons, python code, pictures, whatever) could be tagged
with arbitrary tags and sorted by those tags in the project layout.
Python makes things somewhat complicated by imposing a directory
structure underneath the 'imports' command, but for the moment we had
thought that a simplified activity IDE for children should just show a
flat structure.
Ah, directories, filenames, and compound documents -- the big open
issues in the document store / journal.
An activity in this sense is something like a compound document. It's a
single entity with many pieces. These pieces are all related to each
other. The way these relations are traditionally represented is through
filenames. (Many of the same issues apply to a compound HTML document,
which refers to things like images by filename as well)
Well, if it's more palatable to the people who dislike files, "filename"
isn't *strictly* what is required here. It could also be called a
"resource name". And indeed, we can hack around Python's imports fairly
easily to have it load things from the document store instead of reading
concrete directories and files (though this may or may not end up being
useful). But we *can't* remove the idea of named resources. You can do
that in Squeak because it's been built that way, but it's way too far
from any of the other programming environments to be reasonable.
This doesn't mean we need a global directory structure. I think it does
mean we need two things:
* The idea of a bunch of resources collected together. In the case of
an activity, that means some source code, some images, the .info file,
and whatever else. We've already given this a name: an Activity Bundle.
It's important for more than just Activities, but we don't have a name
or clear idea for what that larger concept is.
* The idea that, inside that bundle scope, things have names. These
names might be "activity.info", or "mypackage/mymodule.py".
Traditionally / indicates hierarchy; but you can also just view them all
as string identifiers. The string identifiers are important, of course
-- mypackage/mymodule.py maps to mypackage.mymodule in Python. We can't
choose these identifiers randomly, these need to be explicit and
persistent identifiers created by the author.
In some cases we *can* create names. For instance, if you have an HTML
page and an image (or a Crossmark document and an image), the name of
the image isn't that important. But once it gets a name, the other
document will also get a reference to the name (e.g., in <image
filename>). So the name has to be persistent, even as the resources are
moved around. It can't be a hash, for instance, nor something that is
volatile when the bundle is moved around (as some resource-UUID
proposals use the UUID). In that case the name is a kind of reference,
and we need to keep the integrity of that reference and the relation
between the resources, but the name of the reference is incidental.
It's just that not all names are incidental.
--
Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
