[Sugar-devel] Article on Why files need to die
Hi all, I just saw this article over on O'Reilly Radar and a lot of what the author says also applies to the Journal: Why files need to die: Files are an anachronism in the digital age. It's time for something better. ( http://radar.oreilly.com/2011/07/why-files-need-to-die.html). So while it's still early days I definitely feel that the Journal is generally moving into the right direction, especially with all the new features and whatnot discussed during the eduJAM! summit:-) Cheers, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Article on Why files need to die
On Fri, Jul 15, 2011 at 4:03 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi all, I just saw this article over on O'Reilly Radar and a lot of what the author says also applies to the Journal: Why files need to die: Files are an anachronism in the digital age. It's time for something better. ( http://radar.oreilly.com/2011/07/why-files-need-to-die.html). So while it's still early days I definitely feel that the Journal is generally moving into the right direction, especially with all the new features and whatnot discussed during the eduJAM! summit:-) I am not purely convinced on eliminating the files paradigm, maybe the folders would be a different conversation. But files are well... pretty obiquos. Since you seem very interesting in having this paradigm of a journal. I wonder if you got inspired out of Zeitgeist project in gnome (I think they rename it now to something more normal like gnome-journal or something). I would like to hear your validation of the journal and why is it a good idea, and how deep will this change goes beyond the UI and apps to a commandline environment. Cheers, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Article on Why files need to die
On Fri, Jul 15, 2011 at 11:13 AM, Alexandro Colorado j...@openoffice.orgwrote: On Fri, Jul 15, 2011 at 4:03 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi all, I just saw this article over on O'Reilly Radar and a lot of what the author says also applies to the Journal: Why files need to die: Files are an anachronism in the digital age. It's time for something better. ( http://radar.oreilly.com/2011/07/why-files-need-to-die.html). So while it's still early days I definitely feel that the Journal is generally moving into the right direction, especially with all the new features and whatnot discussed during the eduJAM! summit:-) I am not purely convinced on eliminating the files paradigm, maybe the folders would be a different conversation. But files are well... pretty obiquos. Since you seem very interesting in having this paradigm of a journal. I wonder if you got inspired out of Zeitgeist project in gnome (I think they rename it now to something more normal like gnome-journal or something). Not sure that there's necessarily a direct connection between Sugar's Journal and Gnome's Zeitgeist but if there were then I'd probably argue that it went from Sugar to Gnome rather than the other way 'round;-) I would like to hear your validation of the journal and why is it a good idea, and how deep will this change goes beyond the UI and apps to a commandline environment. See the aforementioned article, it really contains most of the reasons why I personally think that something like the Journal is a good idea. It seems to be that a stream-like interface combined with a database based backend is a good combination for today's computing context. On an even a broader scale back in Uruguay in early May Bert Freudenberg pointed out that mobile operating systems such as Android and iOS and now increasingly even desktop operating systems (e.g. OS X Lion) are moving into a direction where you're not really interacting with files anymore. Cheers, Christoph Cheers, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Article on Why files need to die
On Fri, Jul 15, 2011 at 11:50 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: On Fri, Jul 15, 2011 at 11:13 AM, Alexandro Colorado j...@openoffice.orgwrote: On Fri, Jul 15, 2011 at 4:03 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi all, I just saw this article over on O'Reilly Radar and a lot of what the author says also applies to the Journal: Why files need to die: Files are an anachronism in the digital age. It's time for something better. ( http://radar.oreilly.com/2011/07/why-files-need-to-die.html). So while it's still early days I definitely feel that the Journal is generally moving into the right direction, especially with all the new features and whatnot discussed during the eduJAM! summit:-) I am not purely convinced on eliminating the files paradigm, maybe the folders would be a different conversation. But files are well... pretty obiquos. Since you seem very interesting in having this paradigm of a journal. I wonder if you got inspired out of Zeitgeist project in gnome (I think they rename it now to something more normal like gnome-journal or something). Not sure that there's necessarily a direct connection between Sugar's Journal and Gnome's Zeitgeist but if there were then I'd probably argue that it went from Sugar to Gnome rather than the other way 'round;-) I would like to hear your validation of the journal and why is it a good idea, and how deep will this change goes beyond the UI and apps to a commandline environment. See the aforementioned article, it really contains most of the reasons why I personally think that something like the Journal is a good idea. It seems to be that a stream-like interface combined with a database based backend is a good combination for today's computing context. On an even a broader scale back in Uruguay in early May Bert Freudenberg pointed out that mobile operating systems such as Android and iOS and now increasingly even desktop operating systems (e.g. OS X Lion) are moving into a direction where you're not really interacting with files anymore. Please also see this article ( http://blogs.gnome.org/mccann/2011/06/08/new-pony/) which Tomeu Vizoso (one of the early Sugar developers) just shared on Google+, well worth a read! Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Article on Why files need to die
On Fri, Jul 15, 2011 at 4:54 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: On Fri, Jul 15, 2011 at 11:50 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: On Fri, Jul 15, 2011 at 11:13 AM, Alexandro Colorado j...@openoffice.orgwrote: On Fri, Jul 15, 2011 at 4:03 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi all, I just saw this article over on O'Reilly Radar and a lot of what the author says also applies to the Journal: Why files need to die: Files are an anachronism in the digital age. It's time for something better. ( http://radar.oreilly.com/2011/07/why-files-need-to-die.html). So while it's still early days I definitely feel that the Journal is generally moving into the right direction, especially with all the new features and whatnot discussed during the eduJAM! summit:-) I am not purely convinced on eliminating the files paradigm, maybe the folders would be a different conversation. But files are well... pretty obiquos. Since you seem very interesting in having this paradigm of a journal. I wonder if you got inspired out of Zeitgeist project in gnome (I think they rename it now to something more normal like gnome-journal or something). Not sure that there's necessarily a direct connection between Sugar's Journal and Gnome's Zeitgeist but if there were then I'd probably argue that it went from Sugar to Gnome rather than the other way 'round;-) I would like to hear your validation of the journal and why is it a good idea, and how deep will this change goes beyond the UI and apps to a commandline environment. See the aforementioned article, it really contains most of the reasons why I personally think that something like the Journal is a good idea. It seems to be that a stream-like interface combined with a database based backend is a good combination for today's computing context. On an even a broader scale back in Uruguay in early May Bert Freudenberg pointed out that mobile operating systems such as Android and iOS and now increasingly even desktop operating systems (e.g. OS X Lion) are moving into a direction where you're not really interacting with files anymore. Please also see this article ( http://blogs.gnome.org/mccann/2011/06/08/new-pony/) which Tomeu Vizoso (one of the early Sugar developers) just shared on Google+, well worth a read! Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com Well is interesting, nevertheless I think that we are sugarcoating the real OS. GUI is a represntation of the CLI which arguably is the Real interface. Changing a DE will just make the perception change, but the actual files will still be there. It can't be an eternal stream of information. However I remember in college I watched David Gelernter http://www.youtube.com/watch?v=0Gd6jX40Kn4 talked about the same issue, and even did a DE with the paradigm of the eternal stream of information related to date as opposed to Folders, Cabinets and Files. The issue with the stream is that it doesnt really works either. If you see twitter, is impossilbe to look without search at your tweets from last month or last years. While folders present you with a cognotive map that holds more information. Dates are well... rigid. Even technology such as Beagle or Kat hasn't really taken off. Extended filesystems in the commandline also hasn't taken off either, even with things like pyaxttr http://pyxattr.sourceforge.net/html/ There are two paradigms, making people think like computers, and making computers think like people. A failure of example is what you are seen with the ipad and even newest OSX that spend too much time on 'page turning' because we want to emulate the analog world. And we want to see pages turn like in books. http://www.thegraphicmac.com/wp-content/uploads/mac_lion-screenshot.jpg This is a waste of time and productivity. I always thought that the menu was a bit of a failure, because is grouped list which are useful in the beginning but how many times you need to think Edit to think cut versus simply call cut command as an action. I loved linux because I never really touch the menu. I just type ctrl-f2 and type whatever program I want to launch. The same can be said about dates, I dont need to think an exact month to remember my trip to new york. I usually think rather.. new york and then I just have 3 times I have been there. So forcing me to go through 2009 2008 2007 to find the right time I went to new york, seems like a waste of time as well. I guess the invention of tagging, hashtagging and keywords really improved things. But I still think is hard to use even for things like bookmarks, adding all these keywords and remembering on time usually is not practical. -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org ___ Sugar-devel mailing list
Re: [Sugar-devel] Article on Why files need to die
On Fri, Jul 15, 2011 at 5:31 AM, Alexandro Colorado j...@openoffice.orgwrote: On Fri, Jul 15, 2011 at 4:54 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: On Fri, Jul 15, 2011 at 11:50 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: On Fri, Jul 15, 2011 at 11:13 AM, Alexandro Colorado j...@openoffice.org wrote: On Fri, Jul 15, 2011 at 4:03 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi all, I just saw this article over on O'Reilly Radar and a lot of what the author says also applies to the Journal: Why files need to die: Files are an anachronism in the digital age. It's time for something better. ( http://radar.oreilly.com/2011/07/why-files-need-to-die.html). So while it's still early days I definitely feel that the Journal is generally moving into the right direction, especially with all the new features and whatnot discussed during the eduJAM! summit:-) I am not purely convinced on eliminating the files paradigm, maybe the folders would be a different conversation. But files are well... pretty obiquos. Since you seem very interesting in having this paradigm of a journal. I wonder if you got inspired out of Zeitgeist project in gnome (I think they rename it now to something more normal like gnome-journal or something). Not sure that there's necessarily a direct connection between Sugar's Journal and Gnome's Zeitgeist but if there were then I'd probably argue that it went from Sugar to Gnome rather than the other way 'round;-) I would like to hear your validation of the journal and why is it a good idea, and how deep will this change goes beyond the UI and apps to a commandline environment. See the aforementioned article, it really contains most of the reasons why I personally think that something like the Journal is a good idea. It seems to be that a stream-like interface combined with a database based backend is a good combination for today's computing context. On an even a broader scale back in Uruguay in early May Bert Freudenberg pointed out that mobile operating systems such as Android and iOS and now increasingly even desktop operating systems (e.g. OS X Lion) are moving into a direction where you're not really interacting with files anymore. Please also see this article ( http://blogs.gnome.org/mccann/2011/06/08/new-pony/) which Tomeu Vizoso (one of the early Sugar developers) just shared on Google+, well worth a read! Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com Well is interesting, nevertheless I think that we are sugarcoating the real OS. GUI is a represntation of the CLI which arguably is the Real interface. Changing a DE will just make the perception change, but the actual files will still be there. It can't be an eternal stream of information. However I remember in college I watched David Gelernter http://www.youtube.com/watch?v=0Gd6jX40Kn4 talked about the same issue, and even did a DE with the paradigm of the eternal stream of information related to date as opposed to Folders, Cabinets and Files. The issue with the stream is that it doesnt really works either. If you see twitter, is impossilbe to look without search at your tweets from last month or last years. While folders present you with a cognotive map that holds more information. Dates are well... rigid. Even technology such as Beagle or Kat hasn't really taken off. Extended filesystems in the commandline also hasn't taken off either, even with things like pyaxttr http://pyxattr.sourceforge.net/html/ There are two paradigms, making people think like computers, and making computers think like people. A failure of example is what you are seen with the ipad and even newest OSX that spend too much time on 'page turning' because we want to emulate the analog world. And we want to see pages turn like in books. http://www.thegraphicmac.com/wp-content/uploads/mac_lion-screenshot.jpg This is a waste of time and productivity. I always thought that the menu was a bit of a failure, because is grouped list which are useful in the beginning but how many times you need to think Edit to think cut versus simply call cut command as an action. I loved linux because I never really touch the menu. I just type ctrl-f2 and type whatever program I want to launch. The same can be said about dates, I dont need to think an exact month to remember my trip to new york. I usually think rather.. new york and then I just have 3 times I have been there. So forcing me to go through 2009 2008 2007 to find the right time I went to new york, seems like a waste of time as well. I guess the invention of tagging, hashtagging and keywords really improved things. But I still think is hard to use even for things like bookmarks, adding all these keywords and remembering on time usually is not practical. -- *Alexandro Colorado* *OpenOffice.org* Español
Re: [Sugar-devel] [IAEP] Article on Why files need to die
On Fri, Jul 15, 2011 at 5:03 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi all, I just saw this article over on O'Reilly Radar and a lot of what the author says also applies to the Journal: Why files need to die: Files are an anachronism in the digital age. It's time for something better. (http://radar.oreilly.com/2011/07/why-files-need-to-die.html). So while it's still early days I definitely feel that the Journal is generally moving into the right direction, especially with all the new features and whatnot discussed during the eduJAM! summit:-) Cheers, Christoph -- I am surprised noone mentioned OS X Lion yet. With Resume, opening the application in the last state, automatic document versions, and Autosave, (all ideas that were is Sugar first, of course) a mainstream operating system is going to bring these concepts to many more people. On Fri, Jul 15, 2011 at 6:31 AM, Alexandro Colorado j...@openoffice.org wrote: The issue with the stream is that it doesnt really works either. If you see twitter, is impossilbe to look without search at your tweets from last month or last years. I think search is the answer. There's no reason why a hierarchal categorization can't be one of the wants to access information, but it certainly isn't the only way. I used recent documents feature very often, I usually search for downloads in my browser instead of opening the folder where they are automatically stored. I send myself email to my gmail account for anything I want to remember (except passwords) and rely on the search feature to find it again. Another area I think is interesting are launcher/search type tools such as Quicksilver (google hired the author, but I haven't seen anything interesting from them based on that yet), Gnome Do, and Alfred for OS X. The main issue with tings like this is learning how to ask for the right thing so it gives you what you want. I am not sure the interfaces make sense if you just walk up to the computer. Then again, many people's browser opens to a search engine with the search box highlighted and they'll type the URL they want to go to in there. So again, guessing what the user meant and giving it to them might be the future. When OS X starts up with a search box open instead of a blank desktop we'll know we are there :) For me, I think these ideas, plus new ones we haven't thought of, combined with refined user interfaces developd based on user behaviors are the future. The more the computer can predict what you want, the more it can help you get your work done. You just have to give it a hint. Dave ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Article on Why files need to die
When OS X starts up with a search box open instead of a blank desktop we'll know we are there :) What a nightmare !I'm sorry, but once you move past trivial amounts of information, correctly specifying the search or filtering through the results of a loosely specified search takes forever. My laptop has over a half-million files on it, with only a small fraction of my photos/music/movie collection and no files older than five years old on it. I use iMail and Spotlight as much as the next Mac user, but finding the right mail from (who was that ?) on (what month/year was that ?) about a common topic can be very frustrating.Whereas the spatial localization paradigm works wonderfully for me (perhaps as it is how I find things in the physical world ?)If I want to find something again, I put it in a certain place in my desktop/hierarchical file system/office/home. For me, I think these ideas, plus new ones we haven't thought of, combined with refined user interfaces developd based on user behaviors are the future. The more the computer can predict what you want, the more it can help you get your work done. You just have to give it a hint. Secretaries and personal assistants have done this for years, but I don't believe that AI is up to the challenge yet. Of course, this doesn't mean we shouldn't try to improve the current UIs... Cheers, wad ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Article on Why files need to die
On Fri, Jul 15, 2011 at 9:01 AM, John Watlington w...@laptop.org wrote: When OS X starts up with a search box open instead of a blank desktop we'll know we are there :) What a nightmare ! I'm sorry, but once you move past trivial amounts of information, correctly specifying the search or filtering through the results of a loosely specified search takes forever. My laptop has over a half-million files on it, with only a small fraction of my photos/music/movie collection and no files older than five years old on it. I use iMail and Spotlight as much as the next Mac user, but finding the right mail from (who was that ?) on (what month/year was that ?) about a common topic can be very frustrating. Whereas the spatial localization paradigm works wonderfully for me (perhaps as it is how I find things in the physical world ?) If I want to find something again, I put it in a certain place in my desktop/hierarchical file system/office/home. I can understand that. What if you forgot where you put it last year? I either don't remember where/how I filed something, or I specifically didn't think about it, because I knew I could search for it later. I remeber instead, the keywords I can use to bring something back up in a search. Maybe it's functionally equivlant, we should get MRIs to find out :) More relevant, has anyone studied how typical users manage a hierarchal filesystem? Do they put everything straight into My Documents? I don't have a large sample size to compare. There definitely is a spectrum of users. Casual home users who mainly use email and the internet along with downloading photos or videos from their camera. Small office users, corporate users with a WAN, users without persistent internet etc. I am sure someone has, but I haven't ever looked for this type of literature beyond reading a couple of books on web site usability years ago. Dave For me, I think these ideas, plus new ones we haven't thought of, combined with refined user interfaces developd based on user behaviors are the future. The more the computer can predict what you want, the more it can help you get your work done. You just have to give it a hint. Secretaries and personal assistants have done this for years, but I don't believe that AI is up to the challenge yet. Of course, this doesn't mean we shouldn't try to improve the current UIs... Cheers, wad -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] icon for search in wikipedia activity
This is for sugarlabs ticket #2971 [1] with the following summary and description: [1] http://bugs.sugarlabs.org/ticket/2971 Wikipedia: Loupe icon is not of the right size The Loupe icon is designed to be inside the search entry. We are using it in the toolbar but looks bad. We need a different icon for the toolbar. Here are two variants I did: http://dev.laptop.org/~manuq/wikipedia_design/wikipedia_search_icon.png 1. current search icon 2. search icon based on the zoom icons 3. custom icon with the magnifying glasses over a book Comments and critics welcome. Regards, -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Article on Why files need to die
On Fri, Jul 15, 2011 at 8:12 AM, Dave Bauer d...@solutiongrove.com wrote: On Fri, Jul 15, 2011 at 9:01 AM, John Watlington w...@laptop.org wrote: When OS X starts up with a search box open instead of a blank desktop we'll know we are there :) What a nightmare !I'm sorry, but once you move past trivial amounts of information, correctly specifying the search or filtering through the results of a loosely specified search takes forever. My laptop has over a half-million files on it, with only a small fraction of my photos/music/movie collection and no files older than five years old on it. I use iMail and Spotlight as much as the next Mac user, but finding the right mail from (who was that ?) on (what month/year was that ?) about a common topic can be very frustrating.Whereas the spatial localization paradigm works wonderfully for me (perhaps as it is how I find things in the physical world ?)If I want to find something again, I put it in a certain place in my desktop/hierarchical file system/office/home. I can understand that. What if you forgot where you put it last year? I either don't remember where/how I filed something, or I specifically didn't think about it, because I knew I could search for it later. I remeber instead, the keywords I can use to bring something back up in a search. Maybe it's functionally equivlant, we should get MRIs to find out :) More relevant, has anyone studied how typical users manage a hierarchal filesystem? Do they put everything straight into My Documents? I don't have a large sample size to compare. There definitely is a spectrum of users. Casual home users who mainly use email and the internet along with downloading photos or videos from their camera. Small office users, corporate users with a WAN, users without persistent internet etc. I know there might be places that I dont want anyone to wonder off, so I have it pretty deep in my filestructure not to popup just randomly. Having a search based paradigm will also present a risk just like google searching for the wrong Swedish Girls semantics in Google Images. I am sure someone has, but I haven't ever looked for this type of literature beyond reading a couple of books on web site usability years ago. Dave For me, I think these ideas, plus new ones we haven't thought of, combined with refined user interfaces developd based on user behaviors are the future. The more the computer can predict what you want, the more it can help you get your work done. You just have to give it a hint. Secretaries and personal assistants have done this for years, but I don't believe that AI is up to the challenge yet. Most users use the desktop to store everything and I mean everything. Reminds me of an episode of the Website is down up in youtube. http://www.youtube.com/watch?v=W8_Kfjo3VjUt=7m54s (NSFW!) Of course, this doesn't mean we shouldn't try to improve the current UIs... Cheers, wad -- Dave Bauer d...@solutiongrove.com http://www.solutiongrove.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- *Alexandro Colorado* *OpenOffice.org* Español http://es.openoffice.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] icon for search in wikipedia activity
2011/7/15 manuel quiñones manuel.por@gmail.com: This is for sugarlabs ticket #2971 [1] with the following summary and description: [1] http://bugs.sugarlabs.org/ticket/2971 Wikipedia: Loupe icon is not of the right size The Loupe icon is designed to be inside the search entry. We are using it in the toolbar but looks bad. We need a different icon for the toolbar. Here are two variants I did: http://dev.laptop.org/~manuq/wikipedia_design/wikipedia_search_icon.png 1. current search icon 2. search icon based on the zoom icons 3. custom icon with the magnifying glasses over a book I prefer #3 as it gives some context for what will be searched. -walter Comments and critics welcome. Regards, -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] icon for search in wikipedia activity
El día 15 de julio de 2011 10:25, Walter Bender walter.ben...@gmail.com escribió: 2011/7/15 manuel quiñones manuel.por@gmail.com: This is for sugarlabs ticket #2971 [1] with the following summary and description: [1] http://bugs.sugarlabs.org/ticket/2971 Wikipedia: Loupe icon is not of the right size The Loupe icon is designed to be inside the search entry. We are using it in the toolbar but looks bad. We need a different icon for the toolbar. Here are two variants I did: http://dev.laptop.org/~manuq/wikipedia_design/wikipedia_search_icon.png 1. current search icon 2. search icon based on the zoom icons 3. custom icon with the magnifying glasses over a book I prefer #3 as it gives some context for what will be searched. Thanks Walter. Yes I think I can do a bigger and more identifiable magnifying glass for #3 . -walter Comments and critics welcome. Regards, -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Article on Why files need to die
On 07/15/2011 05:54 AM, Christoph Derndorfer wrote: Please also see this article (http://blogs.gnome.org/mccann/2011/06/08/new-pony/) which Tomeu Vizoso (one of the early Sugar developers) just shared on Google+, well worth a read! I see this movement, along with Gnome-3's work on tablet compatibility, as a reason why the next generation of Sugar (or OLPC OS) should be based on Gnome 3. We have neither the need nor the ability to duplicate this effort. Better that we shape Gnome to serve the children. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] Article on Why files need to die
On Fri, Jul 15, 2011 at 8:32 AM, Dave Bauer d...@solutiongrove.com wrote: I think search is the answer. There's no reason why a hierarchal categorization can't be one of the wants to access information, but it certainly isn't the only way. I used recent documents feature very often, I usually search for downloads in my browser instead of opening the folder where they are automatically stored. I send myself email to my gmail account for anything I want to remember (except passwords) and rely on the search feature to find it again. I agree with some of the sentiments tha Dave expresses. My expereince is in running enterprise systems for pharmaceutical research. In that industry documents are created by large teams of people all referring to a compound, or group of related compounds which have code names (that often change through-out the process of development). Often the most important element relating two documents is a common bit of chemical structure (e.g. a pyrrolidine ring). This differs from the chronological sequencing on the Journal, but bears some relationship as a criteria other than files/folders as key organizational principals. Hierarchical files systems fall short of having sufficient metadata to enable full retrieval of all relevant documents in that setting. There are software companies pursuing Web 2.0 enabled approaches to enterprise document / content management, in particular, my good friends at ArtusLabs developed a system where you could find documents / spreadhssets, etc. (of nearly any type) by performing a chemical substructure search (e.g. find me all documents that contain a chemical structure with a pyrrolidine ring). Full disclosure - I am a member of the Scientific Advisory Board of ArtusLabs and have benefited financially from that relationship, most recently when Perkin Elmer bought them out. cjl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Article on Why files need to die
Christoph, I've been a fan of the Journal idea from the beginning, but I think it could be improved in a couple of small ways: 1). Don't make things that aren't in the Journal look and (try to) work like they are in the Journal. Example: SD cards and USB drives. 2). Make it possible to link Journal entries to files outside the Journal. I did this with Read SD Comics. The idea is that the Journal on an XO-1 has very limited space: 600 megabytes at the most. If you make a Journal entry that links to a file outside of the Journal proper (say on an SD card) you can cheaply and easily give the Journal 8 GB of additional space. This space is read-only but maybe we could do something about that in some future version of the Journal. What you have then is removable storage that actually acts like it is in the Journal . 3). The idea of having your most recently updated items float to the top of the Journal is useful, until you're done with that item. When I'm finished with an e-book I don't want to delete it but I don't want it cluttering up the top of my Journal entries either. It would be nice to have a way to tell the Journal I'm not going to need this for awhile, send it to the bottom. I have the same issue with my Kindle. To get to some new reading material I have to page through stuff I've finished. James Simmons On Fri, Jul 15, 2011 at 4:03 AM, Christoph Derndorfer christoph.derndor...@gmail.com wrote: Hi all, I just saw this article over on O'Reilly Radar and a lot of what the author says also applies to the Journal: Why files need to die: Files are an anachronism in the digital age. It's time for something better. ( http://radar.oreilly.com/2011/07/why-files-need-to-die.html). So while it's still early days I definitely feel that the Journal is generally moving into the right direction, especially with all the new features and whatnot discussed during the eduJAM! summit:-) Cheers, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Ruler-10
Activity Homepage: http://activities.sugarlabs.org/addon/4192 Sugar Platform: 0.82 - 0.92 Download Now: http://activities.sugarlabs.org/downloads/file/27475/ruler-10.xo Release notes: 10 * Fix scaling problem for Angles rulers on non-OLPC XO hardware Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] icon for search in wikipedia activity
On 15 Jul 2011, at 14:22, manuel quiñones manuel.por@gmail.com wrote: This is for sugarlabs ticket #2971 [1] with the following summary and description: [1] http://bugs.sugarlabs.org/ticket/2971 Wikipedia: Loupe icon is not of the right size The Loupe icon is designed to be inside the search entry. We are using it in the toolbar but looks bad. We need a different icon for the toolbar. Here are two variants I did: http://dev.laptop.org/~manuq/wikipedia_design/wikipedia_search_icon.png 1. current search icon 2. search icon based on the zoom icons 3. custom icon with the magnifying glasses over a book Comments and critics welcome. If we go for something like 2. I think the magnifying glass could be just a little larger; as for 3. it can work as well but the magnifying glass needs to be a little stronger (perhaps slightly larger and/or thicker stroke and/or moved a little up). Thanks for making the variants, I can take it off my todo list :) Regards, --Gary Regards, -- .. manuq .. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Sugar-toolkit: Pack page in ToolbarButton when is conected to the window - OLPC #10930
On 07/12/2011 09:18 PM, Gonzalo Odiard wrote: Thanks Simon, attached is a patch with the comments you did. The patch does double the No gtk.AccelGroup in the top level window warnings printed in the logs. I don't think those are really useful for anything I would remove that (in a separate patch for master) and if at all add a comment there. May be we can remove the callback when the accelerator is set, and add it again if the accelerator is changed. I did not wanted to do it in this patch because the patch would be more difficult to test/understand/review/accept but can be a god improvement. Gonzalo Thanks Gonzalo, pushed. http://git.sugarlabs.org/sugar-toolkit/mainline/commit/3a81ba74385881b8638e800cdfdbb73a3708e7af Yes, let's discuss the rest in a follow-up patch, can you open us a reminder bug? Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [SWEETS] glucose-0.92 via sweets
Hi all, There are changes in glucose versions via sweets. For now it is: 0.93testing 0.92stable 0.88stable 0.9x versions contain stabilizing patches for collaboration: #2964 Race condition while buddy initiation #2963 Sugar telepathy code does not take into account presence status of buddies #2967 Disable telepathy plugins on sugar shell level #2979 Jobject value is being created after joining #2973 telepathy-gabble segfaluts on activity launch (patched gabble version) Please test 0.92 collaboration using jabber.sugarlabs.org. The jabber server on jabber.sl.o has initial version of sugar support and has several issues: * 2K of off-line users, so sugar might be not too fast on startup * not all buddies are both-subscribed, so run 0.88 sugar (see Sweets_Usage wiki page about starting particular sugar version) at first in your current sugar environment, it will cause to subscribe all buddies presence statuses, then run 0.92 sugar See http://wiki.sugarlabs.org/go/Platform_Team/Guide/Sweets_Usage for information how to use sweets. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
