Re: [IAEP] journal criticism (was Re: Re: Re: [RELEASE] TurtleArt-51)
this mail got lost in the ether for 2 days, its old stuff and has been discussed long ago: > [sorry, I am not on sugar-devel list] > > Hi Tomeu > Two points expanded: > > > > altering the filenames and extensions of email attachments > > > > Could you please expand on this use case? > > Using webmail, you save a mail attachment to the journal, the filename is not > preserved. Using webmail you retransmit the attachment, the filename and > extension are lost. > > > > >> > "File turtle_art-51.xo from > > >> > http://activities.sugarlabs.org/en-US/sugar/downloads/file/26052/turtle_art-51.xo."; > > >> > > > >> > As soon as I downloaded to Windows it was obvious that this was not > > >> > the file that downloaded. > > > > I'm failing to understand the problem. Could you please explain further? > > Due to some server error, the server is serving turtle_art-48.xo when the > turtle_art-51.xo link is clicked. Because Windows preserves the filename, you > can see that you have downloaded turtle_art-48.xo whereas Sugar uses some > other process to name the downloaded file and its very hard to understand why > you have v48 rather than v51 installed. > > Tony ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
[IAEP] journal criticism (was Re: Re: Re: [RELEASE] TurtleArt-51)
[sorry, I am not on sugar-devel list] Hi Tomeu Two points expanded: > > altering the filenames and extensions of email attachments > > Could you please expand on this use case? Using webmail, you save a mail attachment to the journal, the filename is not preserved. Using webmail you retransmit the attachment, the filename and extension are lost. > >> > "File turtle_art-51.xo from > >> > http://activities.sugarlabs.org/en-US/sugar/downloads/file/26052/turtle_art-51.xo."; > >> > > >> > As soon as I downloaded to Windows it was obvious that this was not the > >> > file that downloaded. > > I'm failing to understand the problem. Could you please explain further? Due to some server error, the server is serving turtle_art-48.xo when the turtle_art-51.xo link is clicked. Because Windows preserves the filename, you can see that you have downloaded turtle_art-48.xo whereas Sugar uses some other process to name the downloaded file and its very hard to understand why you have v48 rather than v51 installed. Tony ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Journal criticism
On Thu, May 28, 2009 at 09:58:27AM +1000, fors...@ozonline.com.au wrote: hierarchical views of the underlying filesystem Which parts of the filesystem are you talking about (other than external storage) exactly? The system (i.e. anything outside /home)? Sugar config files? Installed activities? The Journal? Files saved using legacy applications? the ability to copy between the journal and a filesystem with user control of mime type and extension the ability to inspect and alter journal items' mime type You mean a graphical equivalent of copy-to/from-journal? PS: Not sure this is still on topic for iaep, suggesting moving to sugar-devel. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Journal criticism
Thanks for this great summary and for getting the discussion moving again. Now we need to turn the talk in to code :) -walter On Wed, May 27, 2009 at 7:58 PM, wrote: > Thanks to Tomeu and others for your contributions. My summary: > > Browse not naming a downloaded file so it includes the name of the file > actually downloaded has been registered as a bug on Trac > > My comments on autosave and journal spam relate to release 0.82, releases > 0.84 and 0.86 have changes which may address my concerns > > The flat journal is to remain as the primary method of saving and retrieving, > but a number of enhancements are on the wish list: > > hierarchical views of the underlying filesystem and for external devices: USB > and SD card > > the ability to copy between the journal and a filesystem with user control of > mime type and extension > > the ability to inspect and alter journal items' mime type > > use the SD card to extend journal capacity > > sort journal by title metatag > > where multiple activities can open a mime type, there is a default activity > which the user can change > > multiple item selection in journal > > Thanks all > Tony > ___ > IAEP -- It's An Education Project (not a laptop project!) > IAEP@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/iaep > -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Journal criticism
Thanks to Tomeu and others for your contributions. My summary: Browse not naming a downloaded file so it includes the name of the file actually downloaded has been registered as a bug on Trac My comments on autosave and journal spam relate to release 0.82, releases 0.84 and 0.86 have changes which may address my concerns The flat journal is to remain as the primary method of saving and retrieving, but a number of enhancements are on the wish list: hierarchical views of the underlying filesystem and for external devices: USB and SD card the ability to copy between the journal and a filesystem with user control of mime type and extension the ability to inspect and alter journal items' mime type use the SD card to extend journal capacity sort journal by title metatag where multiple activities can open a mime type, there is a default activity which the user can change multiple item selection in journal Thanks all Tony ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Journal criticism
On Thu, May 28, 2009 at 5:49 AM, Jonas Smedegaard wrote: > On Thu, May 28, 2009 at 04:58:17AM -0400, Albert Cahalan wrote: >>Tomeu Vizoso writes: >>> 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. >> >>You say that like it would be a bad thing. The existing desktops >>are at least time-tested. Learning to deal with the common features >>of modern desktop systems is very valuable for children. > > I flat out disagree that Sugar should be a learning experience towards > using alternative user interfaces. > > In that mindset we should mimic Word, Excel and the Windows desktop, not > for the quality of their interface designs, but simply because they are > expremely popular so getting acquainted to them is "very valuable for > children". To the extent that there are common features that are highly unlikely to change across versions or even OSes, definitely. MacOS System 6, MacOS X, OS/2 Warp, and Windows Vista have certain basic features in common. It's a safe bet to say that most of these features will remain in the computers of 2017. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Journal criticism
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Thu, May 28, 2009 at 04:58:17AM -0400, Albert Cahalan wrote: >Tomeu Vizoso writes: >> 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. > >You say that like it would be a bad thing. The existing desktops >are at least time-tested. Learning to deal with the common features >of modern desktop systems is very valuable for children. I flat out disagree that Sugar should be a learning experience towards using alternative user interfaces. In that mindset we should mimic Word, Excel and the Windows desktop, not for the quality of their interface designs, but simply because they are expremely popular so getting acquainted to them is "very valuable for children". Kind regards, - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEAREDAAYFAkoeXhkACgkQn7DbMsAkQLgOQACghzX9Ts4NNCUR09PevDZi9LDs /1wAniwQFsPTn6KXe74NOEmuG/NpZjFt =PWgK -END PGP SIGNATURE- ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Journal criticism
Tomeu Vizoso writes: > On Wed, May 27, 2009 at 04:54, wrote: >> I am happy to expand this to the list. I have raised the journal once >> or twice before but mainly kept quiet not wanting to be trollish. ... >> The journal and sharing are probably the two central things that >> distinguish sugar as as a purpose built learning platform. The team have >> a huge investment of time and energy and are rightly proud of their >> achievement. That presents a problem for constructive discussion around >> the journal, the last thing I want to do is be trollish and destructive. You probably would look trollish and upset a few people, but this can be good for sugar and/or education. If few people ever dare to point out problems, we have useless groupthink. I certainly point out problems, but you can't rely on me alone. It's easy to dismiss one person as a grumpy old troll, but not so easy to dismiss a variety of unrelated people pointing out that something isn't right. The more fundamental/core/central the issue, the more this applies. >> For me, the workings behind the journal are hidden and there is a lack of >> tools to make it do different things when the default operation is not >> what you want. Also temporal and tagging is fine as a primary method of >> storage but hierarchical storage is not offered as an alternate method. Instead of trying to add hierarchical storage to the journal, consider inverting the issue. Modern desktop systems often have special ways to view particular directories. For example, Windows does something special with the directory you use for MP3 files. It also does something special for the font directory. Suppose that one directory got a special view called "journal view". This could be a "My Documents" or "Desktop" directory. Activities throw stuff in there using the journal API. AFAIK, GNOME's Nautilus just needs a plug-in to enable a journal view to work there. The hiding of the file system was well intended, files and directories are probably just a passing phase in computing and they cause some confusion to beginners, but they are the system which underlies the Journal and the way we interface with the www > > I agree that it would be helpful to have hierarchical views of the > file system in Sugar, though I don't think they should be the default Given that they are everywhere, it's an educational issue. This isn't like the particulars of Microsoft Office 2007. This is something pervasive throughout the world of computing. > one because IMO a flat view like gmail with good filtering and search > capabilities is more efficient for users that don't want to spend > their energy in keeping their data in directories. I understand this > opinion is very debatable, but it comes from my observation of how > people around me use their computers and also from the feedback about > Sugar from the field. The most interesting feedback from the field was about the kids teaching each other to wipe the journal with "rm". ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Journal criticism
Tomeu Vizoso writes: > On Wed, May 27, 2009 at 20:20, Lucian Branescu > 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? There are big differences in the problem space. GMail is dealing with text. Text search is somewhat reliable. Sugar is dealing with all sorts of random data, like video. GMail can briefly throw **lots** of beefy hardware at the problem, allowing searches to be fast. Sugar can operate a single wimpy processor. Also, lack of folders in GMail is a common complaint. People put up with it because they like other things about GMail. I switched partly because Evolution was eating my inbox. > 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, Now we have equality. The technical users are now also unable to find their files. :-( > 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. You say that like it would be a bad thing. The existing desktops are at least time-tested. Learning to deal with the common features of modern desktop systems is very valuable for children. > And btw, the Sugar people aren't alone in this, as GNOME will ship > with a very similar journal concept in their 3.0 version. You can > find info in the net and read their own justifications for it. > > Would be awesome if the Sugar Journal and the GNOME one could share > its backend. Could someone check out the current state of the GNOME > one and compare with our needs? It looks like a heavy-duty version of "Recent Documents". It's far from being a Journal clone as far as I can tell, but it certainly deals with the concerns that led to the creation of the Journal. Converting the Journal database is possible I think, allowing for an excellent migration path. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Journal criticism
Lucian, Other than the criticisms I mentioned in my email, I like the Journal. Even after years of working with PCs I still find myself occasionally saving something to the hard drive, then wondering where I saved it. My parents probably won't ever really master working with hierarchical file systems, and it's probably a difficult concept for children to master. Even Microsoft recognizes the need to have standard folders like "My Documents", "My Pictures", etc. Hierarchical file systems made a lot of sense in the DOS world with 8 character file and directory names. However, if you have a Journal that can have long titles, free form notes, screenshots of what the Activity looked like when it closed, icons indicating what Journal entry belongs to what Activity, other icons indicating that a Journal entry was the result of a shared Activity, etc. then you don't really need to group things into folders. The Journal gives you better ways to organize your work. It may grow on you. Give it a chance. James Simmons Lucian Branescu 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. ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Journal criticism
Tomeu Vizoso wrote: 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++ At the moment I feel more comfortable working on Activities, and there are still a lot of things I want to do with the two Activities I have. When I have more experience I might think about working on Sugar proper, but that could be a long way off. 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? Sounds good to me. Maybe display the icon of said Activity in the Journal entry to indicate how it will be opened? Regards, Tomeu ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] Journal criticism
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 : > On Wed, May 27, 2009 at 20:20, Lucian Branescu > 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 : >>> On Wed, May 27, 2009 at 19:34, James Simmons >>> 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
Re: [IAEP] Journal criticism
On Wed, May 27, 2009 at 20:39, Tomeu Vizoso wrote: > On Wed, May 27, 2009 at 20:20, Lucian Branescu > 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. And btw, the Sugar people aren't alone in this, as GNOME will ship with a very similar journal concept in their 3.0 version. You can find info in the net and read their own justifications for it. Would be awesome if the Sugar Journal and the GNOME one could share its backend. Could someone check out the current state of the GNOME one and compare with our needs? Thanks, Tomeu > Regards, > > Tomeu > >> 2009/5/27 Tomeu Vizoso : >>> On Wed, May 27, 2009 at 19:34, James Simmons >>> 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 entr
Re: [IAEP] Journal criticism
On Wed, May 27, 2009 at 20:20, Lucian Branescu 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 : >> On Wed, May 27, 2009 at 19:34, James Simmons >> 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 >> > ___
Re: [IAEP] Journal criticism
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. 2009/5/27 Tomeu Vizoso : > On Wed, May 27, 2009 at 19:34, James Simmons > 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
Re: [IAEP] Journal criticism
On Wed, May 27, 2009 at 19:34, James Simmons 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] Journal criticism
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. 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. 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. 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. James Simmons ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] journal criticism (was Re: Re: Re: [RELEASE] TurtleArt-51)
On Wed, May 27, 2009 at 16:09, Walter Bender wrote: > On Wed, May 27, 2009 at 9:45 AM, Tomeu Vizoso wrote: > [snip] >> > "File turtle_art-51.xo from >> > http://activities.sugarlabs.org/en-US/sugar/downloads/file/26052/turtle_art-51.xo."; >> > >> > As soon as I downloaded to Windows it was obvious that this was not >> > the file that downloaded. I'm failing to understand the problem. Could you please explain further? >>> >>> Due to some server error, the server is serving turtle_art-48.xo when the >>> turtle_art-51.xo link is clicked. Because Windows preserves the filename, >>> you can see that you have downloaded turtle_art-48.xo whereas Sugar uses >>> some other process to name the downloaded file and its very hard to >>> understand why you have v48 rather than v51 installed. >> >> This sounds like a simple bug, could you file a ticket, please? > > Actually, it was a bad symlink unrelated to the Journal. No need for a > ticket. But it suggests that somewhere in the download process we > should reveal the actual filename of the file being downloaded.\ Yeah, that's why I asked to file a bug: because Browse is supposed to title the journal entry with the file name sent by the server. Regards, Tomeu > -walter > > -- > Walter Bender > Sugar Labs > http://www.sugarlabs.org > ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] journal criticism (was Re: Re: Re: [RELEASE] TurtleArt-51)
On Wed, May 27, 2009 at 9:45 AM, Tomeu Vizoso wrote: [snip] >>> >> > "File turtle_art-51.xo from >>> >> > http://activities.sugarlabs.org/en-US/sugar/downloads/file/26052/turtle_art-51.xo."; >>> >> > >>> >> > As soon as I downloaded to Windows it was obvious that this was not >>> >> > the file that downloaded. >>> >>> I'm failing to understand the problem. Could you please explain further? >> >> Due to some server error, the server is serving turtle_art-48.xo when the >> turtle_art-51.xo link is clicked. Because Windows preserves the filename, >> you can see that you have downloaded turtle_art-48.xo whereas Sugar uses >> some other process to name the downloaded file and its very hard to >> understand why you have v48 rather than v51 installed. > > This sounds like a simple bug, could you file a ticket, please? Actually, it was a bad symlink unrelated to the Journal. No need for a ticket. But it suggests that somewhere in the download process we should reveal the actual filename of the file being downloaded.\ -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
Re: [IAEP] journal criticism (was Re: Re: Re: [RELEASE] TurtleArt-51)
On Wed, May 27, 2009 at 14:37, wrote: > [sorry, I am not on sugar-devel list] > > Hi Tomeu > Two points expanded: > >> > altering the filenames and extensions of email attachments >> >> Could you please expand on this use case? > > Using webmail, you save a mail attachment to the journal, the filename is not > preserved. Using webmail you retransmit the attachment, the filename and > extension are lost. Ok, I think that Simon has plans to fix this in this release. Wonder what should happen if the user renames the journal entry, should the original file name be used? Or a new one based on the journal entry would be used instead? >> >> > "File turtle_art-51.xo from >> >> > http://activities.sugarlabs.org/en-US/sugar/downloads/file/26052/turtle_art-51.xo."; >> >> > >> >> > As soon as I downloaded to Windows it was obvious that this was not the >> >> > file that downloaded. >> >> I'm failing to understand the problem. Could you please explain further? > > Due to some server error, the server is serving turtle_art-48.xo when the > turtle_art-51.xo link is clicked. Because Windows preserves the filename, you > can see that you have downloaded turtle_art-48.xo whereas Sugar uses some > other process to name the downloaded file and its very hard to understand why > you have v48 rather than v51 installed. This sounds like a simple bug, could you file a ticket, please? Thanks, Tomeu ___ IAEP -- It's An Education Project (not a laptop project!) IAEP@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep
