Re: [Sugar-devel] Sugar Presence Service and Resume Behavior
On Tue, Jun 30, 2009 at 06:01, Eben Eliasone...@laptop.org wrote: On Mon, Jun 29, 2009 at 11:03 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Eben Eliason wrote: On Mon, Jun 29, 2009 at 10:34 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Eben Eliason wrote: I know GroupThink does everything it can to prevent collisions, but with this we should also be thinking about the worst case. The intended baseline behavior (before we get into any fancy merging libraries) was to allow two instances with the same activity_id but different version_ids to run simultaneously, and be joined by any of their participants, thus allowing manual copy/paste merging. The instance left open last would then become, naturally, the most recent and therefore the agreed upon version moving forward. Hmm. This creates a bit of a dilemma. In Groupthink, there is no such thing as a collision. You could say collisions are not supported. Therefore, my model has been that different versions of a document should always be launched into a single shared session, where the data will be merged immediately and automatically. If the user wishes to create a separate branch not to be automatically merged with the existing document, she should create a copy of the journal entry with a new activity_id. (No, we don't seem to have a UI for that.) The most basic UI for that, as I see it, is a Keep a copy secondary item under the Keep button. Yep. This is what I expected the Copy option in the Journal to do, but that copies to the clipboard. Two options, Copy to Clipboard and Copy this Entry would be necessary If the system is designed to prevent different versions from joining into a single shared session, then perhaps this explains the observed behavior. It also entirely prevents automerging of offline work. I don't think they're incompatible at all. I think we agree that they are incompatible as currently implemented, and that any implementation that permits this sort of automerging looks substantially different from what we have now, as you detail. Yup. Hence, perhaps some need for asking an open activity instance if it can successfully merge (whatever that means to the activity) some other object handle its given. If success is returned, the merge happens; if failure is returned, the shell opens the requested activity normally. I do not think an object-based merge system is best for this purpose. It seems to me that such a system would prevent any online negotiation between the two sides. Things get dramatically uglier if you consider joining a session containing many members, but not the initiator. Which user gets to decide whether the new one can join, when all users are equal? The leaderless merge issue doesn't seem any harder than the basic leaderless collaboration issue. But I might be missing some obvious complications. The short of it seems to be that the activity would have to elect a given client to handle the merge. It's not exactly a beautiful solution, but I'd prefer a toggle in activity.info: automerge=True/False. If automerge is False or unspecified, then we retain the current behavior (for the sake of And because the current behavior is the correct thing to do if merge can't be automatic anyway! compatibility). If automerge is True, then different versions are always combined into a single shared session. I'd carefully word this as always attempted to be combined... To support unreliable merge, we can use a self.unshare() method. If the local activity process, after negotiating with other group members, decides that merge is impossible, then it may leave the shared session shortly after joining and return to private scope. How does that sound? This sounds almost exactly like what I was suggesting, but in the opposite direction. I was proposing to ask the activity on the fly if it could perform a merge (this method would return false if unimplemented), returning false when it wasn't possible (after whatever negotiation was necessary...this method could be async). You're suggesting to first check a global constant defined by the activity to see if it will even try to merge at all, and a second fallback method to be called (by the activity) in the case of a failure. Actually, I guess if it's async, our two methods are basically the same, except that you suggest the addition of the flag in .info, which seems like a reasonable enough idea, though not strictly necessary. In any case, both seem roughly equivalent in terms of experience, in which case I don't really care. =) Ben and Eben, do we have now a clear idea of where the problem lies and which API needs to be added to solve it? Thanks, Tomeu Eben --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Telepathy] Sugar Presence Service and Resume Behavior
On Tue, Jun 30, 2009 at 10:57, Guillaume Desmottesguillaume.desmot...@collabora.co.uk wrote: Le lundi 29 juin 2009 à 22:12 -0400, Benjamin M. Schwartz a écrit : My GSoC project involves getting offline collaboration working. My model for this is that two users can join a shared session, then go offline, resume the session from the journal, continue working, and then later resume again when they are on the same network/server and have the two instances merge. In Groupthink, all of my algorithms are designed to support this. However, I have discovered that when two such instances are resumed, they do not connect to each other.* I believe the problem lies in the interaction between the Presence Service and the Datastore, and before I spend too many hours puzzling out how it works, I wonder if anyone could tell me what changes are likely to be necessary to achieve the desired behavior. From my limited understanding of the code, it seems that if an instance is resumed from the Journal, its unique activity_id might change, and this might prevent it from being correctly identified as an instance of an existing shared session. PS doesn't know anything about Journal or DS. He just allows you to create activity, share it (using the D-Bus API) and discover shared ones. I can't really tell you more as I never been involved in the Journal/DS bits. I also wonder what the status of the Presence Service rewrite/removal is. Mission-Control 5 was finally released (!) so it would be good to start considering actually killing PS. Unfortunately, no body is working on this afaik. Hmm, a crazy idea: how hard would be to cook a pygtk app that can run both inside Sugar and inside GNOME and have collaboration working? Or in other words: what would need to be changed in the Sugar shell, toolkit and PS so that we can support current activities and also new ones that don't use anything sugar-specific in their collaboration code? That could be a good step forward. Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). Thanks! Tomeu ___ 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] [API proposal] toolbox.get_toolbars()
On Wed, Jul 01, 2009 at 11:11:30AM +0200, Tomeu Vizoso wrote: On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). In my case(writing activities for 0.82+) it doesn't make any sense to have this patch in sugar-toolkit because its 0.86 feature. Moreover I did similar thing in sugar-port(and use sugar-port wrapper instead of using sugar-toolkit directly) http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/activity.py#line312 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Wed, Jul 01, 2009 at 11:38:51AM +0200, Tomeu Vizoso wrote: On Wed, Jul 1, 2009 at 11:31, Aleksey Limalsr...@member.fsf.org wrote: On Wed, Jul 01, 2009 at 11:11:30AM +0200, Tomeu Vizoso wrote: On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). In my case(writing activities for 0.82+) it doesn't make any sense to have this patch in sugar-toolkit because its 0.86 feature. Moreover I did similar thing in sugar-port(and use sugar-port wrapper instead of using sugar-toolkit directly) http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/activity.py#line312 How that line of code relates to the toolbar patch? It was just an example, the idea is - adding new features to sugar-toolkit API leads activity developers to write 0.86+ code but having these features in libraries like sugar-port let them write 0.82+ code. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Mon, Jun 29, 2009 at 18:14, Gary C Marting...@garycmartin.com wrote: On 29 Jun 2009, at 16:07, Tomeu Vizoso wrote: On Mon, Jun 29, 2009 at 16:55, Aleksey Limalsr...@member.fsf.org wrote: On Sun, Jun 21, 2009 at 02:39:22PM -0700, Edward Cherlin wrote: We have about 60 characters worth of blank space in every Journal entry. It would be a great help if we could display 40-50 characters from the description field for each entry on the main page. We could also drop off the word Activity from every Activity name. maybe using several views * one line view * full view(multi lined view) * thumbs btw I hope we'll decide to work on all these object list related features in one place, now we have Journal, Library(partially implemented) and not implemented Dairy(http://erikos.sweettimez.de/?p=742) Yup, I personally love the mockups at http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal . Other opinions? I like the intent, but I don't think the activity centric view has concrete enough spec to consider implementing yet. There is just way too much magic sauce in those mock-ups to my mind. The closest I've seen something like this implemented, is with Apple's iPhoto, where imported photos are auto arranged into single expandable events based on each photos date/time metadata. You're given a couple of preferences for adjusting the granularity (one event per week, one event per day, one event per 8hrs, one event per 2hrs). Works quite well most of the time, you can always manually merge two events into one, or split one event into two, if it gets them wrong. I don't see that as so problematic. Activities are already saving the items that go to the Objects view, we just may need (or not) to remove some of the metadata and make them more document-like. About the Actions view, we have a baseline for activities that is Worked on Paint for 15 minutes. But activities would be free to change that to whatever makes most sense. I can see how the shell would have a very hard time guessing how best to represent what the user did in activities, but activities have much more information and I think it's where we should put this logic. I guess we could make the activity centric view work in the same way, a fixed time slice that rolls up N hrs work into a collapsable/expandable block that the user can custom name (and/or some auto name based on the content). Not sure we would need that, but we could use Projects as containers ;) The still raises lot's of questions, what happens when you resume some image you painted from way back to take a quick look? Where does it now show in activity centric view? Does it get removed from its old block positioning and to some new active block; perhaps it get multi-linked so now appears twice (you can still find it in the original old place and also find it in new place)? I see past actions as immutable. In that case a new action entry would be added, and if the Paint activity wishes, it can label it Looked at paint 'My house' if it detects that no change happened. Or it can just not create any entry if it makes most sense from that point of view. -=-=-=-=-=- The grid/thumb view should be a top level button, not as is shown buried in a sub palette here: http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#09 I'd consider 2 primary view type buttons: 1). List view, just as we get now 2). Grid view, much like as implemented in Library Sure, I don't see those mockups as a detailed spec for implementing right now, but I think they explain some very exciting ideas for moving forward. -=-=-=-=-=- Having said all this, it seems sensible to pick a few solid Journal improvements and just make some robust steps forward, like: Totally agreed! - Showing tags under the title would be great (Tomeu, I will help where I can) Hope to push my work on the journal treeview soon, then you can take it and do whatever graphics modifications you want. - Batch entry modification (FWIW, don't like the tick box, that feels like an old school html web form hack) Any alternative? - Better Anything toolbar filter palette (use a grid layout to minimise scrolling) Yeah, that will be great. I think Walter already submitted a patch to move the file types up. - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) Could you draw a quick napkin mockup to illustrate that? Thanks, Tomeu Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Browse.xo -- preserving a downloaded filename?
On Tue, Jun 30, 2009 at 7:46 PM, Martin Langhoffmartin.langh...@gmail.com wrote: We need a file manager IMHO. Michael asks about this specific statement, as it is fairly broad. Let's keep it in the context of it is worth fixing bugs that mangle filenames so the Journal can indeed double up as a passable (if limited) file manager :-) We need to do some file management sanely. Not an easy line to walk, but doable. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Wed, Jul 1, 2009 at 11:44, Aleksey Limalsr...@member.fsf.org wrote: On Wed, Jul 01, 2009 at 11:38:51AM +0200, Tomeu Vizoso wrote: On Wed, Jul 1, 2009 at 11:31, Aleksey Limalsr...@member.fsf.org wrote: On Wed, Jul 01, 2009 at 11:11:30AM +0200, Tomeu Vizoso wrote: On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). In my case(writing activities for 0.82+) it doesn't make any sense to have this patch in sugar-toolkit because its 0.86 feature. Moreover I did similar thing in sugar-port(and use sugar-port wrapper instead of using sugar-toolkit directly) http://git.sugarlabs.org/projects/sugar-port/repos/mainline/blobs/master/activity.py#line312 How that line of code relates to the toolbar patch? It was just an example, the idea is - adding new features to sugar-toolkit API leads activity developers to write 0.86+ code but having these features in libraries like sugar-port let them write 0.82+ code. Sure, I have no problem with activity developers using sugar-port or whatever they find appropriate. We need to add new features to sugar-toolkit for the activity authors that need new stuff. If sugar-toolkit is not going to keep being improved, then people would be better off not using sugar-toolkit and just using sugar-port or whatever. If they use sugar-port and it is installed at the system-level, then we have something that is exactly the same as sugar-toolkit. If it is copy-pasted inside every activity, then sugar core developers won't be able to help activity authors debug issues in their activities and the first step to develop sugar activities will be a bit higher. I would say it's up to activity authors, though distro packagers might be also bothered to have to package duplicated code. But I think that activities shouldn't be packaged by distros anyway. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Tue, Jun 30, 2009 at 19:02, Gary C Marting...@garycmartin.com wrote: On 30 Jun 2009, at 00:32, Michael Stone wrote: -- big snip from old thread --- - Better Anything toolbar filter palette (use a grid layout to minimise scrolling) How do you think http://wiki.sugarlabs.org/go/Design_Team/Designs/Toolbars would work out here? An 'Anything' filter button opening a palette with a grid layout of filter options could work as is right now. It could be a relatively small and contained code change, for a relatively large improvement in usability. I guess (in Ebens toolbar mock-ups) a pop-up row could be filled with the same filter options, but it would need to cope with multi row layouts as the number of filter options grows over time (i.e. as more Activities are installed). More generally regarding the toolbar mock-ups, some points needing clarification: - Stop button must be visible at ALL times, none of these mock-ups show a stop - Activity collaboration control has disappeared, assume this should be a primary icon - No solution yet for textual names/labels (inventing unique and clear icons is going to get real tough, real fast, and many Activity authors already struggle creating decent activity icons). - Activity title has disappeared from toolbar is that intentional to rely on the naming dialogue every-time? Yup, I guess one more refining step would be needed to move forward. Being Mr ActivityTeam at the moment, I do really worry about the amount of work this is going to be to get Activities updated and complying to a large toolbar redesign. Supporting both toolbar API styles will help, but I think we'll end up with multiple toolbar styles in different Activities for perhaps 6 months to a year or more. That's a bad backward step for usability. Just look at the amount of time/effort it is taking to migrate Activities over to SL infrastructure, let alone making anything but minor maintenance code changes to them. True, so what do you suggest here? Thanks, Tomeu - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) What do you think of Scott's journal2 design here? Technically? A massive redesign requiring a rock-star lead developer and a long-term commitment to refine, debug, and stabilise over several Sugar platform release cycles. There are nice ideas in there, I particularly like the idea of turning directory paths into tags as a way to access the file system. But, a much simpler option would be to let a user type something like /usr/local/... in the existing Journal search and have the Journal display a basic folders/files view, typing just / would show the root level and a user could navigate old school style from there. Copy/paste could be extended to move content between Journal/file-system views, and external devices could show the file-system view by default so a USB key or SD card could be more easily managed. Regards, --Gary ___ 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] [IAEP] Sugarcamp - November 7th-12th 2009 ?
On 07/01/2009 12:49 AM, David Farning wrote: On Tue, Jun 30, 2009 at 5:45 PM, Simon Schampijersi...@schampijer.de wrote: On 06/29/2009 10:09 PM, David Farning wrote: On Mon, Jun 29, 2009 at 9:55 AM, Simon Schampijersi...@schampijer.de wrote: Hi, the SFScon 2009 will be held in Bolzano [1]. As part of that the TIS[2] would be willing host a Sugarcamp. The camp would be part of the free software week [3], where a GNOME Hackfest will happen as well. It fits quite well in our release cycle (0.88 planning/hacking) and having the GNOME Hackfest next door would create nice synergies. We would start on a weekend to have better chances on getting (students and people who have to work during the week) everyone a chance to attend. How does that sound? Sounds good. Any one in mind to champion the event? Do you have a point of contact with event organizers so we can start working on the admin? I'll help. But based on LinuxTag you seem to have event organization pretty much figured out. david The Sugarcamp will be a different event than Linuxtag. Linuxtag was a show where you have to setup gear and get promotion material together, the camp is more planning what you want to discuss during those days. That time we have local help from the freesoftwareweek people, that I guess take care of the rooms etc. The actual work is then staying in contact with them regarding our needs, setting up a wiki, getting in contact with the GNOME organizers... I would like someone else to champion that (better two people so they can discuss things) - as I want to focus on 0.86. Should not be too time consuming, maybe a nice way to start contributing to the project. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Enhancing Activity updator
On Mon, Jun 29, 2009 at 17:35, Aayushaay...@olenepal.org wrote: Due to large size of EPaath activity we r having trouble updating it, it takes almost 15-20 min to update it using current updating technique what we want to implement is , only download the changed portion of the activity comparing the crc32 value and we are able to do that and significantly reduce the updating time ( 3 min ) when we simulate updating outside sugar we r having trouble integrating that method into current sugar activity update mechanism we want any of u to guide us where should we change in current (Controlpanel - Model - updator.py) and place our code to implement our ides i think def download_selected_updates(self, progress_cb=(lambda n, row: None), dir=None): in (Controlpanel - Model - updator.py) is where i should satrt doing my thing ... where could i find documentation about current sugar activity update process The only person I know to be familiar with that code is Scott, thus adding him to CC. My recommendation is that you get yourself familiar with the activity updater code before you try to implement your ideas in a definitive way. As a first, read the code as you have already done and identify the most interesting methods. Once you have a model of how approximately things work, add some logging.debug calls and verify your hypothesis by seeing at which point those methods get called and with which parameter values. Once you have some idea of what to change and where, do some first changes (don't try to implement everything at once), then see if the modifications work as expected. Then repeat. If you are patient and persistent, you will notice how things that seemed before impenetrable start making some sense. That may not be enough to get you where you want to be at first, but keep on with the process and I'm sure that you will succeed. Good luck, Tomeu ___ 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] [GSoC] I need help for Webified - SSB activity favicons
I've put that on hold for now. It's rather low-impact high-effort when compared to userstyles and userscripts. I'll try downloading the favicon with stuff in nsChannel, but I'm not sure I can embed that in an SVG (especially since gtk's SVG support is very bad). 2009/7/1 Tomeu Vizoso to...@sugarlabs.org: On Thu, Jun 25, 2009 at 02:56, Lucian Branesculucian.brane...@gmail.com wrote: In case you don't know what Webified is http://wiki.sugarlabs.org/go/Webified http://honeyweb.wordpress.com In short, I have added to Browse the ability to create SSB (http://en.wikipedia.org/wiki/Site-specific_browser) activities. Since I'm generating activities, they need to have icons. After some discussions, I have decided to use a .svg wrapper icon for all SSBs that includes the website favicon. I need to extract the favicon from a website and include it in the .svg icon. Any thoughts? Can SVG images contain bitmaps? Because I guess that most sites will be using a PNG or GIF. Right now, I'm doing code cls = components.classes['@mozilla.org/network/io-service;1'] io_service = cls.getService(interfaces.nsIIOService) ns_uri = io_service.newURI(uri, None, None) cls = components.classes['@mozilla.org/browser/favicon-service;1'] favicon_service = cls.getService(interfaces.nsIFaviconService) favicon_service.getFaviconData(ns_uri) /code But the last line throws xpcom.Exception: -2147221231. I haven't been able to figure out what that error is. At this point, I would debug the mozilla side of things. It may seems like a pain, but may actually save you time when compared with trying things randomly. Another option is once you get the URI to download it (see nsChannel components). HTH, Tomeu ___ 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] Wise Qatar award
An award for Sugar Labs? http://www.wise-qatar.org/en/awards Deadline for applications is July, 15th. -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal and filenames on USB disks - more leases.sig problems
On Tue, Jun 30, 2009 at 19:41, Martin Langhoffmartin.langh...@gmail.com wrote: I am trying to get leases.sig from the XS to the USB stick. On 8.2.x, Browse.xo saves the file as File leases.sig from http://... ... two possible ways to move next. Copy and rename 1 - Insert (fat-formatted) USB stick, once mounted copy the file to the USB stick. Check on Terminal indicates that the file has the LFN we expect (File leases.sig from http://...;). 2 - Switch to the 'USB disk' view of the Journal. 3 - Rename the file to leases.sig . A check from the commandline shows that the file has not been renamed. Oops?. The Journal only renames the metadata. Bug? Rename and copy 1 - Rename the file in the Journal to 'leases.sig' 2 - Insert (fat-formatted) USB stick, once mounted copy the file to the USB stick. The Journal reports that the file is called lease.sig. From terminal I can see that the file is called lease.sig.txt . Bug? Is there a better way to do this? If you go through the archives, you will find that this was discussed some weeks ago, I think it was Tony Forster who started the discussion. And we have tickets in trac as well. Regards, Tomeu cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ 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] Wise Qatar award
Bastien bastiengue...@googlemail.com writes: An award for Sugar Labs? http://www.wise-qatar.org/en/awards Deadline for applications is July, 15th. Redirected this to marketing@ -- sorry for the noise. -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [API proposal] toolbox.get_toolbars()
On Wed, Jul 1, 2009 at 15:18, Lucian Branesculucian.brane...@gmail.com wrote: Sorry about that. I've attached another patch which follows the guidelines. I'm not sure I should be opening a ticket about this, though. I've had a chat with Walter last night and he said that since the toolbar will get a re-haul in 0.86, it's a chance to improve the API as well. If we really manage to implement that feature for 0.86 (the design is not agreed on as of yet), the API will have to be a separate addition because we'll need to keep both the old tabs-based toolbox and the new one as not all activities will be able to move to the new one at the same time. That said, your patch seems clean enough to be added now and the fact this API is going to get deprecated makes it easier to add API to it. Regards, Tomeu 2009/7/1 Tomeu Vizoso to...@sugarlabs.org: On Tue, Jun 30, 2009 at 04:55, Lucian Branesculucian.brane...@gmail.com wrote: While adding the bookmarklet functionality to Browse, I realised that the toolbox API is hard to work with if your toolbars change. For example, set_current_toolbar() takes the index of the toolbar as a parameter, something which you can't really know if your toolbars move around. Tomeu suggested I propose to extend the toolbox API with a get_toolbars() method. This method returns a list of the actual Toolbar objects, in the order they currently have in the gtk.Notebook. This method allows for things like if toolbar in toolbox.get_toolbars() or toolbar_index = toolbox.get_toolbars().index(toolbar), giving a lot more flexibility in manipulating toolbars. It could also kill off the ugly _TOOLBAR_FOO globals in Browse. I've made toolbox.toolbars a property for get_toolbars(). I have attached a patch to toolbox.py, in the sugar.graphics package. Could you please follow http://wiki.sugarlabs.org/go/Development_Team/CodeReview#Patch_guidelines ? I would also like to hear from the activity team (Gary?) if they have any objection to this API addition (I would like to see sugar-toolkit changes being driven by them at some point in the future). Thanks! Tomeu ___ 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] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 1, 2009 at 15:43, Eben Eliasone...@laptop.org wrote: On Tue, Jun 30, 2009 at 3:43 PM, Simon Schampijersi...@schampijer.de wrote: Hi, in this week we want to talk about the Journal and datastore [1] improvements planned for 0.86. The Library activity [2] has shown some interesting concepts as well. What are the common goals, how to move forward, where to invest? All the people involved - please attend, would be awesome if UI designers would attend too. I'd love to join, though I'm not sure how much attention I can give the meeting while at work. I'll try to peek in. During this weekend would work fine for me, as well. Alternatively, if we take good minutes we can have a productive thread on the mailing list afterwards. Regards, Tomeu Eben Regards, Simon [1] http://wiki.sugarlabs.org/go/Version_support_for_datastore/Proposal [2] http://wiki.sugarlabs.org/go/Activities/Library ___ 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 mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Limalsr...@member.fsf.org wrote: On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: Hi, in this week we want to talk about the Journal and datastore [1] improvements planned for 0.86. The Library activity [2] has shown some interesting concepts as well. What are the common goals, how to move forward, where to invest? Just some thoughts before meeting. For new Journal we have: * action-centric view * object-centric view In my mind they are quite different, action-centric view relates to timelines when object-centric is more like a browsing of objects(sort, tag them etc). So, what about using Library's code base for object-centric view? I think Library and Scott's Journal 2 are both good sources to pull from. From a UI perspective, however, I think keeping to something very much like the existing mockups is the best course, both because this is a familiar ground for users (the initial vision for object view is nearly identical to the current Journal UI) and because it's important to keep it simple while finding intuitive ways to extend functionality. I think exposing tags, adding tag autocompletion, and improving the selection filters in the toolbar are good places to start. Adding the grid view to expose object previews would also be a great addition! I also like that Library has started to support sharing. I think there have been a number of interesting proposals for how this might work in the Journal, and I'd love to see the feature added. Perhaps by selecting View Journal in the palette for a buddy it would be possible to see anyone's shared content. Eben -- Aleksey ___ 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] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 1, 2009 at 9:46 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Wed, Jul 1, 2009 at 15:43, Eben Eliasone...@laptop.org wrote: On Tue, Jun 30, 2009 at 3:43 PM, Simon Schampijersi...@schampijer.de wrote: Hi, in this week we want to talk about the Journal and datastore [1] improvements planned for 0.86. The Library activity [2] has shown some interesting concepts as well. What are the common goals, how to move forward, where to invest? All the people involved - please attend, would be awesome if UI designers would attend too. I'd love to join, though I'm not sure how much attention I can give the meeting while at work. I'll try to peek in. During this weekend would work fine for me, as well. Alternatively, if we take good minutes we can have a productive thread on the mailing list afterwards. That sounds fine. Don't reschedule on account of me. I'll try to keep one eye in that direction, and just ping me specifically as needed if I'm not paying close enough attention. ;) Eben Regards, Tomeu Eben Regards, Simon [1] http://wiki.sugarlabs.org/go/Version_support_for_datastore/Proposal [2] http://wiki.sugarlabs.org/go/Activities/Library ___ 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 mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
Eben wrote: On Tue, Jun 30, 2009 at 3:43 PM, Simon Schampijersi...@schampijer.de wrote: All the people involved - please attend, would be awesome if UI designers would attend too. I'd love to join, though I'm not sure how much attention I can give the meeting while at work. I'll try to peek in. As with Eben, I'm interested but regularly unavailable during those hours for real-time conversation due to other commitments. Apologies, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Presence Service and Resume Behavior
On Wed, Jul 1, 2009 at 4:57 AM, Tomeu Vizosoto...@sugarlabs.org wrote: On Tue, Jun 30, 2009 at 06:01, Eben Eliasone...@laptop.org wrote: On Mon, Jun 29, 2009 at 11:03 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Eben Eliason wrote: On Mon, Jun 29, 2009 at 10:34 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Eben Eliason wrote: I know GroupThink does everything it can to prevent collisions, but with this we should also be thinking about the worst case. The intended baseline behavior (before we get into any fancy merging libraries) was to allow two instances with the same activity_id but different version_ids to run simultaneously, and be joined by any of their participants, thus allowing manual copy/paste merging. The instance left open last would then become, naturally, the most recent and therefore the agreed upon version moving forward. Hmm. This creates a bit of a dilemma. In Groupthink, there is no such thing as a collision. You could say collisions are not supported. Therefore, my model has been that different versions of a document should always be launched into a single shared session, where the data will be merged immediately and automatically. If the user wishes to create a separate branch not to be automatically merged with the existing document, she should create a copy of the journal entry with a new activity_id. (No, we don't seem to have a UI for that.) The most basic UI for that, as I see it, is a Keep a copy secondary item under the Keep button. Yep. This is what I expected the Copy option in the Journal to do, but that copies to the clipboard. Two options, Copy to Clipboard and Copy this Entry would be necessary If the system is designed to prevent different versions from joining into a single shared session, then perhaps this explains the observed behavior. It also entirely prevents automerging of offline work. I don't think they're incompatible at all. I think we agree that they are incompatible as currently implemented, and that any implementation that permits this sort of automerging looks substantially different from what we have now, as you detail. Yup. Hence, perhaps some need for asking an open activity instance if it can successfully merge (whatever that means to the activity) some other object handle its given. If success is returned, the merge happens; if failure is returned, the shell opens the requested activity normally. I do not think an object-based merge system is best for this purpose. It seems to me that such a system would prevent any online negotiation between the two sides. Things get dramatically uglier if you consider joining a session containing many members, but not the initiator. Which user gets to decide whether the new one can join, when all users are equal? The leaderless merge issue doesn't seem any harder than the basic leaderless collaboration issue. But I might be missing some obvious complications. The short of it seems to be that the activity would have to elect a given client to handle the merge. It's not exactly a beautiful solution, but I'd prefer a toggle in activity.info: automerge=True/False. If automerge is False or unspecified, then we retain the current behavior (for the sake of And because the current behavior is the correct thing to do if merge can't be automatic anyway! compatibility). If automerge is True, then different versions are always combined into a single shared session. I'd carefully word this as always attempted to be combined... To support unreliable merge, we can use a self.unshare() method. If the local activity process, after negotiating with other group members, decides that merge is impossible, then it may leave the shared session shortly after joining and return to private scope. How does that sound? This sounds almost exactly like what I was suggesting, but in the opposite direction. I was proposing to ask the activity on the fly if it could perform a merge (this method would return false if unimplemented), returning false when it wasn't possible (after whatever negotiation was necessary...this method could be async). You're suggesting to first check a global constant defined by the activity to see if it will even try to merge at all, and a second fallback method to be called (by the activity) in the case of a failure. Actually, I guess if it's async, our two methods are basically the same, except that you suggest the addition of the flag in .info, which seems like a reasonable enough idea, though not strictly necessary. In any case, both seem roughly equivalent in terms of experience, in which case I don't really care. =) Ben and Eben, do we have now a clear idea of where the problem lies and which API needs to be added to solve it? I think we're close. The high level requirement is an API by which an activity can attempt to perform a merge operation before the shell simply opens two
Re: [Sugar-devel] [IAEP] Sugarcamp - November 7th-12th 2009 ?
On Wed, Jul 1, 2009 at 6:41 AM, Simon Schampijersi...@schampijer.de wrote: On 07/01/2009 12:49 AM, David Farning wrote: On Tue, Jun 30, 2009 at 5:45 PM, Simon Schampijersi...@schampijer.de wrote: On 06/29/2009 10:09 PM, David Farning wrote: On Mon, Jun 29, 2009 at 9:55 AM, Simon Schampijersi...@schampijer.de wrote: Hi, the SFScon 2009 will be held in Bolzano [1]. As part of that the TIS[2] would be willing host a Sugarcamp. The camp would be part of the free software week [3], where a GNOME Hackfest will happen as well. It fits quite well in our release cycle (0.88 planning/hacking) and having the GNOME Hackfest next door would create nice synergies. We would start on a weekend to have better chances on getting (students and people who have to work during the week) everyone a chance to attend. How does that sound? Sounds good. Any one in mind to champion the event? Do you have a point of contact with event organizers so we can start working on the admin? I'll help. But based on LinuxTag you seem to have event organization pretty much figured out. david The Sugarcamp will be a different event than Linuxtag. Linuxtag was a show where you have to setup gear and get promotion material together, the camp is more planning what you want to discuss during those days. Having participated in SugarCamp Paris and some FudCons. How do you feel about the participant led format of the event? FWIW, SugarCamp Paris was intentional in it's lack of pre-organization to break from the 'Sage on Stage' broadcasting to the unwashed masses nature of previous Sugar Labs meetings. Caroline and I have been working with http://www.aspirationtech.org/ , one of the leaders in non-profit events. They have been a great help is asses what we have been doing right and what we can improve in upcoming meetings. That time we have local help from the freesoftwareweek people, that I guess take care of the rooms etc. The actual work is then staying in contact with them regarding our needs, setting up a wiki, getting in contact with the GNOME organizers... I would like someone else to champion that (better two people so they can discuss things) - as I want to focus on 0.86. Should not be too time consuming, maybe a nice way to start contributing to the project. I'll start the admin stuff. Thanks, Simon -- David Farning Sugar Labs www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 01, 2009 at 09:48:23AM -0400, Eben Eliason wrote: On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Limalsr...@member.fsf.org wrote: On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: Hi, in this week we want to talk about the Journal and datastore [1] improvements planned for 0.86. The Library activity [2] has shown some interesting concepts as well. What are the common goals, how to move forward, where to invest? Just some thoughts before meeting. For new Journal we have: * action-centric view * object-centric view In my mind they are quite different, action-centric view relates to timelines when object-centric is more like a browsing of objects(sort, tag them etc). So, what about using Library's code base for object-centric view? I think Library and Scott's Journal 2 are both good sources to pull from. From a UI perspective, however, I think keeping to something very much like the existing mockups is the best course, both because this is a familiar ground for users (the initial vision for object view is nearly identical to the current Journal UI) and because it's important to keep it simple while finding intuitive ways to extend functionality. I think exposing tags, adding tag autocompletion, and improving the selection filters in the toolbar are good places to start. I'm a bit concerned by having(many?) filter combo-boxes in toolbar[1], maybe having sidebar(like in Library[2]) could make more sense(btw user can hide sidebar to browse objects in full window mode), moreover we could use several views for entries in sidebar: list(tree) view, tag cloud[3]. Adding the grid view to expose object previews would also be a great addition! I also like that Library has started to support sharing. I think there have been a number of interesting proposals for how this might work in the Journal, and I'd love to see the feature added. Perhaps by selecting View Journal in the palette for a buddy it would be possible to see anyone's shared content. The original idea of Library in case of sharing was shared(common) collections of sugar objects i.e.: * user #1 creates collection(Library object), creation means choosing filter for local objects(user tags, properties like mime-type, another DS fields) * user #1 shares his collection(Library object) * user #2 can join #1's session and see(download) objects from his collection * user #2 can add his local objects to this shared collection(by setting filter for his local objects) so, all joined users can view all(from all users) shared objects in one place Having View Journal option in buddy menu makes sense as well But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). And Library's method doesn't fit well for this(since it uses filter and adding one particular object to collection(shared list) is a problem). I thought about this issue in context of Library.. and what about: Extend conception of Favorites to Pins. The idea is: - having implicit list of Library-collections/shared-collections means problem to support these lists(if user deletes some object, sugar should update all these collection lists implicitly) - contrariwise, having in object implicit list of all collection links that this object participates in, means also some odd implicit job to support these links + so, what about delegation this job to users and make this process explicit + sugar does not do odd job of implicit supporting lists of links + users can understand what objects go to what collections(like collection of objects to share, collection of starred objects, users collections) * old Favorites mark would be a pre-installed pin so, we could have several standard pins: * pins for objects to share * Favorites could be transformed to pins to show objects in home view so any object(not only activities) could appear in home view * ... * each pin could have unique color(and name) * like Favorites pins could be attached to objects from list view(there is no needs to open details dialog) * each objects can have several pins attached at the same time * we can render all these attached pins in one cell(not in per-pin cells like for participants) i.e. pins will overlap each over [1] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#3 [2] http://wiki.sugarlabs.org/go/File:-1.png [3] http://wiki.sugarlabs.org/go/File:-2.png -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sunjammer down for unplanned maintenance
Hello, sorry for the late notice: (19:46:49) bernie: (19:46:08) upd...@identi.ca/identi_cajabber: djbclark: !fsfstatus brief downtime for colonialone and many domUs including www.fsf.org, sunjammer, gnewsense. All are coming back up now. The FSF admins are working on fixing the problem. The server should be back up and running within a few minutes. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal and filenames on USB disks - more leases.sig problems
On Wed, Jul 1, 2009 at 3:08 PM, Tomeu Vizosoto...@sugarlabs.org wrote: On Tue, Jun 30, 2009 at 19:41, Martin Langhoffmartin.langh...@gmail.com wrote: Is there a better way to do this? If you go through the archives, you will find that this was discussed some weeks ago, I think it was Tony Forster who started the discussion. True - thanks for the tip. I didn't find any specific workaround (but I found one of my own, as I mentioned before). And we have tickets in trac as well. Cool. I will create an additional ticket, related to file renames on a USB drive. If I can find my way around the relevant code, I'll try to prep a patch. cheers, martin -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar Digest 2009-07-01
^Eva^Rita -walter On Wed, Jul 1, 2009 at 4:21 PM, Walter Benderwalter.ben...@gmail.com wrote: ===Sugar Digest=== 1. It has been a busy week for Sugar Labs. The center piece was the announcement of Sugar on a Stick, Strawberry. May thanks due to Sebastian Dziallas and the Fedora packaging team as well as Sean Daly and the Sugar Labs marketing team (we got unprecedented international coverage). Simon Schampijer organized a Sugar Labs booth at LinuxTag (see his write-up below). The bookends were the FOSSed and NECC meetings. Caroline Meeks and I ran a workshop for teachers at [http://www.fossed.com] and along with Caryl Bigenho, Stephen Jacobs, and Mike Lee, we presented at [http://www.neccunplugged.com/]. Caroline and I also made several trips to the Gardner and Lilla G. Frederick schools, where we are conducting Sugar on a Stick pilot programs this summer. We are running planning sessions with the teachers and start working with the students next week. Both schools have structured programs in the morning and open-ended discovery in the afternoon. It is in these afternoon sessions that we'll be using Sugar, as a compliment to the morning activities. 2. Two high-school students from Rwanda are interning with me this summer. Eric and Peter will be adding some debugging features to Turtle Art and following up with some classroom experiments when they return to Rwanda in August. We'll take some inspiration from some observations Raúl Gutiérrez Segalés and I made while debugging Turtle Art project remotely. It was clear that it wasn't clear to the programmer where in the code one was executing at the time of an error. Eric and Peter's goal is to highlight the brick being executed as one steps through the program. Raúl, for his part, has taken on the challenge of adding hover-activated tool tips. 3. Alan Kay, Tony Forster, Ed Cherlin et al. have been in a discussion ([http://lists.sugarlabs.org/archive/iaep/2009-June/006853.html], [http://lists.sugarlabs.org/archive/iaep/2009-June/006831.html]) about teaching physics that highlights the difference between diagnostic aids and physical thinking. Worth a read. K. K. Subramaniam (Subbu) pointed to a parody [http://solar.physics.montana.edu/tslater/montillation_of_traxoline.html], The Montillation of Traxoline that really spoke to me about the problem of the 'intermediation' that has crept into the science education in recent decades. It is no longer about direct experience. It is about dealing with text in books, pictures on charts and movies on screen. It is about literacy, not comprehension. 4. Meanwhile, in the spirit of Sugar, we now have [[Modifying_Activities#Modifying_Physics]] page in the wiki describing how modify the Physics Activity. 5. Simon made regular reports from LinuxTag [http://erikos.sweettimez.de/]. Kudos to Simon for all his work in organizing the booth and to Tony Anderson, David Van Assche, Sean Daly, Sebastian Dziallas, Bert and Eva Freudenberg and the Squeak Team, Adam Holt, and James Zaki. Also thanks to our booth partners, Skolelinux, X2GO, and Linux4Afrika. ===Help Wanted=== 6. Maria del Pilar Saenz has put out a call for participation [http://co.sugarlabs.org/go/Convocatoria] in the various Sugar Labs Colombia programs. If you are a teacher, engineer, student, free software enthusiast or related, you can collaborate. No matter the experience you have, what Most importantly, the dedication that can be given to projects. ===In the community=== 7. I'll be giving a keynote at GUADEC [http://www.grancanariadesktopsummit.org/]; my plan is to both introduce Sugar to the broader desktop community (with the goal of recruiting more contributors), to sing the praises of the desktop—the cloud is not the solution to all problem—but also articulate the need for more simplicity along the entire spectrum from developers to end users. 8. Squeakfest [http://squeakfest.org] will be held in Los Angeles 10–12 August and in Porto Alegre 23–25 Julho. 9. There will be a Sugar track at the Free Software Week [http://www.freesoftwareweek.org/] in Bolzano, Italy, the week of 9 November 2009. We will likely start the Sugar Hackfest the weekend before (7 Nov.) in order to accommodate the restricted schedules of some of our community members, e.g., students. Free Software Week culminates with the South Tyrol Free Software Conference 2009 [http://www.sfscon.it/2009/]) and is sponsored by TIS innovation park [http://www.tis.bz.it/]. ===Tech Talk=== 10. Fred Grose continues to keep watch over [http://wiki.suagrlabs.org]. It remains a navigable site despite our growth in content and diversity over the past year. 11. Thomas C Gilliard has added a Sugar VM [http://www.vmware.com/appliances/directory/216653] to the Virtual Appliance Marketplace. 12. Aleksey Lim announced V3 of the Sugar Activities Library [http://activities.sugarlabs.org]. Aleksey merged and adapted the
Re: [Sugar-devel] [IAEP] Sugar Digest 2009-07-01
On Wed, Jul 1, 2009 at 18:21, Walter Benderwalter.ben...@gmail.com wrote: 10. Fred Grose continues to keep watch over [http://wiki.suagrlabs.org]. It remains a navigable site despite our growth in content and diversity over the past year. 11. Thomas C Gilliard has added a Sugar VM [http://www.vmware.com/appliances/directory/216653] to the Virtual Appliance Marketplace. In the last weeks I have been impressed at Fred's and Thomas' work, big kudos! Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 01, 2009 at 05:42:14PM +, Aleksey Lim wrote: On Wed, Jul 01, 2009 at 09:48:23AM -0400, Eben Eliason wrote: On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Limalsr...@member.fsf.org wrote: On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: Hi, in this week we want to talk about the Journal and datastore [1] improvements planned for 0.86. The Library activity [2] has shown some interesting concepts as well. What are the common goals, how to move forward, where to invest? Just some thoughts before meeting. For new Journal we have: * action-centric view * object-centric view In my mind they are quite different, action-centric view relates to timelines when object-centric is more like a browsing of objects(sort, tag them etc). So, what about using Library's code base for object-centric view? I think Library and Scott's Journal 2 are both good sources to pull from. From a UI perspective, however, I think keeping to something very much like the existing mockups is the best course, both because this is a familiar ground for users (the initial vision for object view is nearly identical to the current Journal UI) and because it's important to keep it simple while finding intuitive ways to extend functionality. I think exposing tags, adding tag autocompletion, and improving the selection filters in the toolbar are good places to start. I'm a bit concerned by having(many?) filter combo-boxes in toolbar[1], maybe having sidebar(like in Library[2]) could make more sense(btw user can hide sidebar to browse objects in full window mode), moreover we could use several views for entries in sidebar: list(tree) view, tag cloud[3]. Adding the grid view to expose object previews would also be a great addition! I also like that Library has started to support sharing. I think there have been a number of interesting proposals for how this might work in the Journal, and I'd love to see the feature added. Perhaps by selecting View Journal in the palette for a buddy it would be possible to see anyone's shared content. The original idea of Library in case of sharing was shared(common) collections of sugar objects i.e.: * user #1 creates collection(Library object), creation means choosing filter for local objects(user tags, properties like mime-type, another DS fields) * user #1 shares his collection(Library object) * user #2 can join #1's session and see(download) objects from his collection * user #2 can add his local objects to this shared collection(by setting filter for his local objects) so, all joined users can view all(from all users) shared objects in one place Having View Journal option in buddy menu makes sense as well But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). And Library's method doesn't fit well for this(since it uses filter and adding one particular object to collection(shared list) is a problem). I thought about this issue in context of Library.. and what about: Extend conception of Favorites to Pins. The idea is: - having implicit list of Library-collections/shared-collections means problem to support these lists(if user deletes some object, sugar should update all these collection lists implicitly) - contrariwise, having in object implicit list of all collection links that this object participates in, means also some odd implicit job to support these links + so, what about delegation this job to users and make this process explicit + sugar does not do odd job of implicit supporting lists of links + users can understand what objects go to what collections(like collection of objects to share, collection of starred objects, users collections) * old Favorites mark would be a pre-installed pin so, we could have several standard pins: * pins for objects to share * Favorites could be transformed to pins to show objects in home view so any object(not only activities) could appear in home view * ... * each pin could have unique color(and name) * like Favorites pins could be attached to objects from list view(there is no needs to open details dialog) * each objects can have several pins attached at the same time * we can render all these attached pins in one cell(not in per-pin cells like for participants) i.e. pins will overlap each over [1] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#3 [2] http://wiki.sugarlabs.org/go/File:-1.png [3] http://wiki.sugarlabs.org/go/File:-2.png sorry, forgot to mention - its all about object-centric view -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Systems] Sunjammer down for unplanned maintenance
On Wed, 2009-07-01 at 19:49 +0200, Bernie Innocenti wrote: The FSF admins are working on fixing the problem. The server should be back up and running within a few minutes. Sunjammer has been bought back up a few hours ago. Anyone who would like to receive notifications regarding our servers hosted at the FSF, you can subscribe to this feed: http://identi.ca/group/fsfstatus -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Show Must Go On - SoaS for the XO-1
On Wed, Jun 17, 2009 at 2:12 AM, Martin Denglermar...@martindengler.com wrote: I'd suggest you ask sdz to make the .iso that he used to create the .img file. On Wed, Jun 17, 2009 at 12:37 AM, Sebastian Dziallassebast...@when.com wrote: I'm very pleased to announce the first early preview of a new generation of SoaS XO-1 images. Sir, could you upload the .iso for this image somewhere, maybe in a subdirectory of http://download.sugarlabs.org/soas/xoimages/ ? On Wed, Jun 17, 2009 at 3:24 AM, Martin Langhoffmartin.langh...@gmail.com wrote: Actually, a tool that's most of this smartly, it's called jigdo, http://atterer.net/jigdo/ is indeed cool. It's presented as a tool for delivering and updating pieces of a single big file and all examples are a .iso big file. So long as it can also/instead use the same pieces to create a different kind of big file such as a bootable Live USB, or a writable SD partition, or XO-1 NAND contents, then it is indeed a great solution. Do the developers who work on Live USB Creator know about jigdo? Cheers, -- =S Page ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On 1 Jul 2009, at 10:54, Tomeu Vizoso wrote: On Mon, Jun 29, 2009 at 18:14, Gary C Marting...@garycmartin.com wrote: - Showing tags under the title would be great (Tomeu, I will help where I can) Hope to push my work on the journal treeview soon, then you can take it and do whatever graphics modifications you want. Fab. - Batch entry modification (FWIW, don't like the tick box, that feels like an old school html web form hack) Any alternative? I see multi selection Journal operations as a more advanced (occasional use) feature, so it would be OK not being directly visually exposed. So, no tick box column (save all that space for useful information), instead use a shift key modifier so that when clicking an entry its selection state is toggled on/off (grey backing fill of the entry row). When hovering over (or right clicking) a multi selected entry, display a new palette with just the features that function on a multiple selection. Erase being the obvious multiple selection command asked for in the past; the other useful multiple selection function would be drag and drop for copying a batch of Journal entries to and from external media (i.e. teacher comes back from the city with a USB stick full of downloaded ebooks). - Better Anything toolbar filter palette (use a grid layout to minimise scrolling) Yeah, that will be great. I think Walter already submitted a patch to move the file types up. Yea, saw the patch from Walter, that alone should help even if we stall on doing more. I have a mock-up I was experimenting with grid layouts, still tinkering, and I can't think of a good 'filter' icon for the replacement button (a common one seems to be a funnel shape) :-) The Journal filters for 'Anything', 'Anytime', the proposed 'Anyone', and my below 'Tag' filters can all become toolbar icons (not text). This saves a heap of toolbar space, and allows room for a couple more buttons on the far right for 'Grid' and current 'List' view. - Perhaps a Tag toolbar filter palette (could be a mini tag cloud) Could you draw a quick napkin mockup to illustrate that? Sure, but don't think I'll have anything in time for the dev meeting. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: in this week we want to talk about the Journal and datastore [1] improvements planned for 0.86. I really hope to make it (my GSoC work depends on it - there's a lot of stuff to talk about and some decisions to make) but am not sure I can (especially given how flakey internet access is ATM). Would be great to at least be able to read the meeting logs afterwards (as usual). [1] contains my thoughts on a VCS based datastore rewrite - a bit fleshed out now, but still not finished. The most important part for now is that I'd like to change the find() API call to take two parameters instead of one. Right now, the single parameter is a mixture of a query (giving key-value pairs that entries must match to be returned) and of output options (sorting order etc.). As we need to change API for version support anyway I'd like to seize that opportunity to fix this mess (no offense intended). While the document currently mentions the index backend quite often I might actually skip it at first and use only the database backend instead. Xapian (an Information Retrieval system used by the current datastore to provide simple metadata search) is very interesting and could be quite useful for a future FindMyData activity - but IMO with a new API focussing on probabilistic information retrieval, including spell checking and partial queries (Xapian terms seem to correlate quite well with Sugar tags, BTW). The basic attribute search stuff currently used is IMO best done using a database, not an IR system. The document is largely a braindump, not a design document yet. So please overlook the rough edges and the fact that I'm proposing a full rewrite - I might end up recycling a large part of the current code base, but thinking of it as a new thing helps me see things more clearly. [1] http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
