Right, that does make it a bit more clear. I feel however that there should be a way to mount the Journal as a regular filesystem without losing too much information (put stuff in folders according to labels, put activities in their own folder, etc.)
2009/5/27 Tomeu Vizoso <to...@sugarlabs.org>: > On Wed, May 27, 2009 at 20:20, Lucian Branescu > <lucian.brane...@gmail.com> wrote: >> I'm new to Sugar, so I may be horribly wrong. >> >> But to me, the Journal seems more of an annoyance than anything else. >> A lot of the work I see done is towards bringing back some of the >> properties that regular filesystems have >> >> What advantage does it have as opposed to a regular filesystem with >> support for versioning and metadata? A filesystem would be more >> compatible with existing software (which could just ignore the >> metadata), at least. > > I can very easily understand that for someone who is used to a regular > filesystem, the journal may seem as an annoyance when an attempt to > use it in the same way is done. The same can be said of any other > diversion in Sugar from how Windows/OSX behave. > > Though, interestingly, many people have successfully switched from > files-in-folders-in-folders email clients to GMail. Maybe it is > because the journal is not as mature as gmail? > > If I think that something like the journal is worth having, it is: > > - because I can easily observe how non-technical users are unable to > find the files that they stored in folders some time ago, or forget to > save an important document, or modify a file that Firefox saved to > /tmp and it got deleted after a reboot, etc, > > - because people working with children using Sugar have said it's useful. > > I think it's very important if we want to keep pushing Sugar that we > distinguish between design decisions and bugs and unimplemented > features. If we bring down good design ideas not by themselves but > because of its implementation status, we risk ending up with nothing > that brings new value compared to existing desktops. > > Note that I'm not going to the extreme of saying that we shouldn't > consider the feasibility of a design before pushing for it. > > Regards, > > Tomeu > >> 2009/5/27 Tomeu Vizoso <to...@sugarlabs.org>: >>> On Wed, May 27, 2009 at 19:34, James Simmons <jim.simm...@walgreens.com> >>> wrote: >>>> Tomeu, >>>> >>>> I've said this before, but maybe I can repeat it once more: >>>> >>>> 1). I like the idea of the Journal. I would not want to change the >>>> Journal >>>> proper to support putting items in hierarchies. >>>> >>>> 2). Having said that, I don't always like the Journal Activity. The >>>> biggest problem I have with it is it insists on making things that are NOT >>>> in the Journal kind of look like they are. That's a big mistake. I would >>>> prefer that SD cards and USB thumb drives that may have files and folders >>>> have a totally different user interface from the Journal interface. The >>>> interface could be made with a Pygtk tree view. You could copy a file into >>>> the Journal, as a Journal entry, or copy a Journal entry into a directory >>>> as >>>> a file. The file would be named with the title meta tag plus a suffix >>>> based >>>> on MIME type. Maybe some kind of Journal entries couldn't be copied this >>>> way, so copying would not be supported for them. >>> >>> I agree, and thought I was clear in my last email about this. In 0.84 >>> has been work to make this possible, though isn't user visible at this >>> moment. >>> >>>> 3). Maybe there would be an option to use the SD card as expansion for the >>>> Journal. If you had a 2 gig SD card you could specify that you wanted it >>>> treated this way, and from then on your Journal would be 2 GB larger. This >>>> option would destroy whatever data was on the SD card to begin with. If >>>> you >>>> didn't do this, the SD card would have the same interface as a thumb drive. >>> >>> This is part of the original vision but is another task up for grabs. >>> >>>> 4). For the Journal proper, I agree that a temporal view has value. >>>> However, in addition to that I'd like to sort by the Title meta tag. This >>>> would be a natural for etexts, because you could look for a book more >>>> easily >>>> if they were all in alphabetical order. If you had a large library on your >>>> XO the temporal sequence would be annoying. >>> >>> Yup, we have mockups that add this functionality. n_tasks_up_for_grabs++ >>> >>>> 5). When several Activities support the same MIME type (Zip files are >>>> BOUND >>>> to be popular) then there needs to be a way of specifying that a particular >>>> Journal entry should be resumed by a particular Activity by default. You >>>> should be able to change that default at any time, but once changed you'd >>>> be >>>> able to open any entry with that default with one click. >>>> >>>> Right now the only way to make a Zip file Journal entry open with the right >>>> Activity with one click is to make the Activity open the Journal entry with >>>> the Object Chooser, then save it back out as a new Journal entry. Then the >>>> user deletes the original Journal entry. We need something easier than >>>> that. >>> >>> Maybe open by default in the last activity it was open with? >>> >>> Regards, >>> >>> Tomeu >>> >>>> James Simmons >>>> >>>> >>>> >>> _______________________________________________ >>> IAEP -- It's An Education Project (not a laptop project!) >>> IAEP@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/iaep >>> >> > _______________________________________________ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
