[sugar] Human Interface Guidelines (update and hosting)
Hello everyone - The Human Interface Guidelines [1] have been stagnant for some time, and I'm starting an initiative to remedy the situation. This effort, as I see it, has two components: 1) update the contents of the HIG and 2) tease apart OLPC guidelines from Sugar guidelines, and adjust hosting accordingly. UPDATE: The content update is something I'll spearhead myself, as I wrote most of the current guidelines. Assistance is certainly welcome, however, /especially/ in amassing lists of holes that need to be plugged; I'm sure there are countless implicit guidelines we all follow that should really be laid down clearly and explicitly. Ideally, we should be able to answer any noob question about visual or interaction design by pointing to a sentence in the HIG. In that regard, there is a component for the HIG in the OLPC trac system, so tickets are welcome. As I mentioned, a small bit of the HIG (mostly the input methods section, but perhaps others) are XO specific. I'll attempt to tease this apart as well. HOSTING: The second aspect of this effort is transitioning the HIG to the sugarlabs wiki, which seems a more appropriate place for the (Sugar) Human Interface Guidelines. I foresee this as a relatively large task, given the size of the HIG and the set of templates, raw HTML, and nested transclusion which makes a quite navigable but relatively complex page structure. I'm not a wiki pro, myself, and I'd be quite grateful to any who have the know-how and are willing to assist with, or even take on, this task. PARALLELISM: Finally, there's a third implied complication, which is how these two efforts can happen simultaneously (or not). Should we a) transition the HIG to sugarlabs, and then update/edit and move any XO specific pieces back to the OLPC wiki or b) perform a complete update in place, teasing XO specific parts into separate pages, and then move it to sugarlabs when we're done or c) come up with a way to work in parallel? Thanks for your assistance! [1] wiki.laptop.org/go/HIG ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Sugar Design Meeting REMINDER (Now)
Here are the details: http://sugarlabs.org/go/DesignTeam/Meetings#Thursday_December_4.2C_2008_-_15.00_.28UTC.29 Apologies for the late reminder. In the back of my head I thought that was automated now, but either I'm wrong, or I failed to set it up. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Announcing a design roadmap meeting, tentatively scheduled for Wed. Nov. 26th, 1500 UTC
Though it's not part of our usual biweekly cycle, we'd like to hold a meeting this week to lay out a loose roadmap for Sugar in the OLPC 9.1 timeframe, taking into account the discussions from SugarCamp last week. I've posted additional details, including a loose agenda, on the wiki: http://sugarlabs.org/go/DesignTeam/Meetings#Wednesday_November_26.2C_2008_-_15.00_.28UTC.29 In order to have a productive planning discussion, we really need all key sugar developers to participate. If the time or date conflicts, please suggest alternatives. As Thursday is Thanksgiving for many, we'd like to find a time tomorrow or Wed. Thanks! - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Reducing activity sharing boilderplate code
Subclassing makes sense to me (though I'm just a designer, so don't give me too much weight.) It seems that we could create a CollaborativeActivity subclass, and perhaps even subclass that if there are several common types of collaboration with different setups. The easier it is for someone to get started with a collaborative code base, the better, in my opinion. - Eben On Fri, Nov 7, 2008 at 7:41 AM, Morgan Collett [EMAIL PROTECTED] wrote: I want to push some of the code required for sharing into sugar-toolkit, for example: def _list_tubes_reply_cb(self, tubes): for tube_info in tubes: self._new_tube_cb(*tube_info) If I put this directly into sugar.activity.activity.Activity, then all activities will gain the code which might impose some overhead. Alternatively I can subclass Activity to SharableActivity or something like that, and add the telepathy/tubes helper code in there. Thoughts? Regards Morgan ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] NO (formal) design meeting this week.
Hello all - I apologize for the lack of organization of the biweekly design meetings as of late. Unfortunately, I'm going to duck out this week as well, as I need to focus heavily on a deadline for next week. However, I will remain on IRC following the sugar meeting and will be more than happy to discuss any thoughts or ideas that are brought there. I just haven't had time to prepare any visuals or set an agenda myself. So, if you have something to say, please say it! The informal meeting is in #sugar-meeting in about 30 minutes, at 15:30 UTC. I look forward to getting back on track with planned meetings on the 20th, - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Consolidating the Feature Roadmap
For those that aren't yet aware, a Feature Roadmap [1] has appeared in our wiki recently, its goal to lay out a long term strategy for prioritizing software development on the XO. It's tied closely to the Feature Request [2] page, which contains verbatim requests and requirements by country, to be consolidated and referenced when adding to the roadmap. At the bottom of the Feature Roadmap you'll currently find a priorities from engineering section, populated with valuable feedback, requirements, and other information from all of you folks; some organized by topic, some by suggester, some not at all. We need to formally add all thoughts in this section (and those below it) to the feature roadmap [3]. Please take a look through the information listed there and attempt to consolidate and organize into features by next Wed., November 5th. Please also remove the content from the bottom section once it has been dealt with. Any remaining content in the priorities from engineering section after that date will be dealt with as best I can manage, but your efforts to reduce the load are much appreciated! Thanks! - Eben [1] http://wiki.laptop.org/go/Feature_roadmap [2] http://wiki.laptop.org/go/Feature_requests [3] http://wiki.laptop.org/go/Feature_roadmap#Adding_to_the_roadmap ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 proposal: Language learning on the XO.
On Tue, Oct 28, 2008 at 7:46 PM, Chris Ball [EMAIL PROTECTED] wrote: Hi, I'm learning Spanish at the moment, and I wish the XO made it easier for me. I don't have any knowledge of what the right way to do either conventional or constructionist language learning on computers is; if anyone has much experience with either, I'd love to hear about it. I have some obvious candidates for software that could be produced in mind: * A method -- similar to Scott's recent GtkLabel overlay for allowing strings inside Sugar and activities to be translated -- that does a dictionary lookup of a word on the screen and overlays the translation of that word into a local language. This should be activity-agnostic, if possible. For bonus points, translate phrases instead of just words. OSX has a really powerful built-in dictionary/thesaurus, which works in a similar manner. It's only available anywhere there is selectable text, but even that is invaluable. Here's a sample: http://niquimerret.com/?p=72 You could imagine offering dictionary/thesaurus/translation all in a similar manner. - Eben * Perhaps some kind of Pronunciation Activity that gives you words in the target language, speaks them to you, explains what they mean in your local language, and asks you to speak them back, perhaps grading your response? (All but the last part is already possible to do manually in the Words activity, but not in a structured way.) * Is there any free content that matches iconic images to words, so that language vocabulary could be taught even without textual translation to a local language? Feel free to come up with questions/ideas around language learning on the XO in general in this thread, and they'll make it into the conference talk. Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Control Facility Improvements
I can sympathize with this perspective. Traditionally, software updates only update software which is already installed. In this perspective, I could see one expecting all those activities already installed being selected by default, and others left unchecked for one to select as desired. On the other hand, I appreciate that our primary use case is for deployments and entire schools of kids, where the set of activities chosen for the update has been carefully selected by the school, and might include a handful of new or customized activities for the upcoming school year, for instance. In such a scenario, selecting all by default is clearly desired. I'm not sure what the answer is. Offering a flag with the activity pack somehow could work, I suppose, but makes the idea less pure. Maybe adding buttons for select all/deselect all and select installed would be better, to make managing the selection easier and more exposed, could work. Or, perhaps better, we could offer a smart activity pack in the list for Installed activities which then presents a list of all installed activities (checked by default, just like the other activity packs). - Eben On Thu, Oct 23, 2008 at 9:09 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: On Thu, Oct 23, 2008 at 9:07 PM, genesee [EMAIL PROTECTED] wrote One more? Software Updates defaults all available Activities pre-selected. Their boxes checked, in other words. I would rather choose the updates I want than de-select the ones I don't. Some of the Activity Groups are huge. It's a hassle clicking on the many not wanted to download a few. Right-click, unselect all. Voila! If only all our 9.1 features were already implemented. ;-) --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] 9.1 Proposal: Clarifying the zoom levels
We've never fully implemented the zoom levels, and since we're going to have to pay some attention to that area in order to provide scalability in the short term, we should ensure that their design offers long term scalability as well. For the purpose of this discussion, I'd like to restrict focus to the Groups and Neighborhood views. Finally, note that I want to clarify the direction for 9.1; aspects of the design may not be implemented in the same timeframe. Current Approach: Groups: People and activities around me or on my collaboration server who are my friends, or members of a group I'm in. A filter in the toolbar allows me to select which group I want to see specifically, or I may see all at once. A mechanism for creating and naming new groups is provided. Neighborhood: People and activities around me or on my collaboration server. Though I can see everyone, I still have a groups filter here as well. Alternative #1: Groups: People and activities around me or on my collaboration server who are my friends, or members of a group I'm in. A filter in the toolbar allows me to select which group I want to see; I must always look at a specific group. A mechanism for creating and naming new groups is provided. Neighborhood: People and activities around me or on a specific collaboration server. Here I can see everyone on the server (though scalability may only show me a subset by default). A filter in the toolbar allows me to select which neighborhood (server) I want to see; I must always look at a specific neighborhood. By default My school or My Neighborhood is seen, though I can select School in Peru if I want to. A mechanism is provided for registering and nick-naming new collaboration servers. Notable differences: In the alternative model, the Groups view is a subset of the Neighborhood which I'm currently viewing. Therefore, if I'm looking at School in Peru, I'll find a different set of Groups there. This could be confusing. On the other hand, this model gives us a way to branch out further and switch collaboration servers in a way friendlier than the control panel. Also, the alternative provides a useful differentiator between Neighborhood and Groups, whereas the current approach makes them nearly identical, except that the largest set of people I can see if Groups is everyone in a group I'm in instead of everyone in my neighborhood. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 9.1 Proposal: Report cards on XO
I'm not sure that such an idea actually requires a special activity, or a report card template with preset fields. It seems to me that the item of importance is the ability for the teacher to give each kid an immutable object which they may then view on their XO, and take home to show their parents. This object might be a .pdf, or it might be an image, or it might be something else, but the teacher could create such an object in Write, or in a spreadsheet activity, or in whatever suits their needs best. It seems to me that the more interesting part of this problem is the distribution method. Unlike a homework assignment where the teacher could share an activity, or (in the future) send an object to everyone in the class group, there is need to distribute files individually to the kids by some unique identifier. Perhaps this is the place where an Evaluate activity does have it's place. If done well, a fresh instance of the activity could provide a way for a teacher to fill out evaluations (or import in their desired format!) and identify which kid each belongs to. Then, upon sharing that single evaluation activity with the class, each kid would receive *only* their own evaluation from the shared instance. That instance would then, every time they open it, simply be a viewer for that particular evaluation. This is a good example where the master-slave (usually discouraged in Sugar) would actually work. - Eben On Wed, Oct 22, 2008 at 11:01 AM, Yamandu Ploskonka [EMAIL PROTECTED] wrote: Following with the Printing support thread, I found out that the only item that _needs_ printing in the conventional school setup is the report cards. Since I militantly believe that XO-supported education we should not depend on printing at all if it were possible, I would want to submit a proposal to have grading information be accessible through the XO. While that is a simple part of student management software that doubtlessly will be part of the server, and thus accessible as a web page, still there would be a need for that information to be copied _into_ the XO for those kids who would have no access to the server from their homes. Thus, in its proposed incarnation, the Work Report activity would exist in the XO, be fed its information updates from the school server. The child and family would have that info as an available reminder of the teacher's feedback and child-specific suggestions. From a security standpoint the server notices via mac address the ID of the child's computer to upload info to. There would be an associated activity, Teacher Reports, available for the teachers' XOs, where the teacher can comment on student work. Simple fields, what is good about this work, what needs improvement, other suggestions. While I personally would avoid there be a grade field, I am aware I will be overruled on this, so I concede. In most cases anyways the report card follows a definite format and is already pre-printed to be filled out by hand. I am sure that improvements on this are possible, but since this is very much a nationally-defined format, it might not make sense to worry at this stage. Last time I was there in 2000, Uruguay High Schools printed reports on dot-matrix plain paper already. Yama ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Clipboard errata (patches)
Thanks for the reviews so far! While updating my jhbuild I came
accros a couple other related patches (attached). I'm building again
as I write this, so I'll try to rebase all of my patches today.
The first is just visual, the second is a change to sugar-toolkit
which is required to support the highlighting of the tray on drag, and
the last just makes use of the go-up/go-down arrows which have been in
the them for some time, but never referenced in the tray code, which
was using left/right instead.
On Mon, Oct 20, 2008 at 6:05 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote:
On Fri, Oct 17, 2008 at 7:06 PM, Eben Eliason [EMAIL PROTECTED] wrote:
On Fri, Oct 17, 2008 at 12:48 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote:
On Fri, Oct 17, 2008 at 6:11 PM, Eben Eliason [EMAIL PROTECTED] wrote:
This is a set of patches I worked on recently, and need to rebase on
the latest jhbuild before I post them officially. I wanted to expose
them for comments before I put in that effort, since there are no
doubt other things that will need to be changed upon review.
Thanks!
- Eben
PS. I just noticed upon attaching that the first isn't actually a
clipboard patch, but it was part of a sprint on clipboard and
drag'n'drop in general, so I include it.
[PATCH] Lock cursor to center of icons in favorites view on drag (#7408)
Looks good, you can as well calculate again the hot point from the
pixbuf in the context, instead of adding two private members more to
the class.
Oh really? I didn't see a way to pull that back out. Could you give
me a pointer?
You are right, I expected that gtk.DragContext would have an accesor
as well as a setter.
[PATCH] Add descriptions to clippings (#5751)
Not sure if we should do the formatting in model/clipboardobject.py,
that looks to me more like a presentation issue so should live in the
view classes?
I debated this back and forth. My decision to put it in the model
meant that we could simple return a description easily in the correct
format given the clipping type. Otherwise, the view needs to special
case based on the type of the clipping. It seemed to me (ignoring the
details of implementation) that I really just wanted description to
be just a string in the model, which the view could call up at any
point. From this perspective, it's natural for the model to return an
appropriate string, and for the view to color, size, position, etc.
that string as it wants, right?
I'm ok with the concept of a single-line description of a clipping
living in the model, but the _MAX_DESCRIPTION_LENGTH value seems to me
like a UI decision. What about moving it to be an argument of
get_description()?
That sounds like a good idea.
+if key == 'STRING':
I'm not sure all text clippings will have the STRING target, I would do
instead:
+if key in ['STRING', 'text/plain', ...]:
(I'm not really sure which are the most common targets that contain
text, I would check the logs after a paste, these are printed in
there).
I'll take a look, thanks. I was always unsure about the best way to
get that info; I just needed something that worked to get the rest up
and running. I'll look at your previous patch to similar effect,
also.
- Eben
[PATCH] Prevent duplicate clippings on drag within clipboard (#8606)
Sounds good as a temporary measure, but I think that Gtk+ has support
in its trays for reordering elements with DnD. Or it may be some
extension to gtk+? Worth investigating.
Yes, that's the long term solution. I just wanted something to clean
up the behavior to prevent confusion in the meantime. There is a TODO
somewhere in there where I mention we should be rearranging instead, I
think. It might be the case that doing it right makes the rest of
this patch obsolete, but I'm not sure.
Sure, I think that your solution is very good in the meantime.
Thanks,
Tomeu
From 7049b8ffc5adee08afa78033cd56e894996154b0 Mon Sep 17 00:00:00 2001
From: Eben Eliason [EMAIL PROTECTED](none)
Date: Tue, 23 Sep 2008 20:36:46 -0400
Subject: [PATCH] Size and position clippings correctly when dragged
---
src/view/clipboardicon.py | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/src/view/clipboardicon.py b/src/view/clipboardicon.py
index c5b6ae7..43f7a6a 100644
--- a/src/view/clipboardicon.py
+++ b/src/view/clipboardicon.py
@@ -21,6 +21,7 @@ import gtk
from sugar.graphics.radiotoolbutton import RadioToolButton
from sugar.graphics.icon import Icon
from sugar.graphics.xocolor import XoColor
+from sugar.graphics import style
from sugar import profile
from model import clipboard
@@ -106,10 +107,10 @@ class ClipboardIcon(RadioToolButton):
self._icon.props.icon_name = 'application-octet-stream'
child = self.get_child()
+child.connect('drag-begin', self._drag_begin_cb)
child.drag_source_set(gtk.gdk.BUTTON1_MASK,
self._get_targets
Re: [sugar] 9.1 Proposal: Printing support
Peter Krenesky (CC'd) from the Open Source Lab at Oregon State has discussed some printing basics with me, and may have already begun further research in this area. There is some info in the wiki on the subject: http://wiki.laptop.org/go/Enabling_CUPS, http://wiki.laptop.org/go/Printing_Design, but I'm not sure how far along any hacking has actually gotten. - Eben On Fri, Oct 17, 2008 at 4:24 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: We should consider adding basic Print support for 9.1. In the past this has foundered on questions like, what brand(s) of printers? what connection mechanism? It seems impossible to support every printer and every connection mechanism in a reasonable amount of NAND space. *But*, we should be able to: * Print postscript (or pdf, or whatever, just pick *one*) to school server via CUP (IPP?), and install a decent selection of printer drivers on the school server. Control panel for 'default printer name', fixed to 'XS' by default. * Add basic printing support to Write, Read, and Browse; set PRINTER env variable. * for future, add support to Paint, Record, etc. for 9.1. Again, I can give a quick talk just restating the above, and hopefully spurring a discussion about how much work this would or would not be and whether we can afford to do this for 9.1 (or can't afford not to do it), but I'd love it if someone would volunteer to 'own' the issue and make a more concrete proposal, present a demo, investigate other issues involved, etc. --scott -- ( http://cscott.net/ ) ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Clipboard errata (patches)
OK, I've pushed all of the patches except for Add descriptions to clippings, which I want to think through carefully before resubmitting. The changes pushed take into account the suggestions here and discussed in IRC, where Tomeu unofficially r-plussed them. I'll take a closer look into adding descriptions tomorrow; Tomeu's effort in this area is already in master, so a very close approximation of the final behavior can already be seen. - Eben On Mon, Oct 20, 2008 at 9:33 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Mon, Oct 20, 2008 at 3:19 PM, Eben Eliason [EMAIL PROTECTED] wrote: Thanks for the reviews so far! While updating my jhbuild I came accros a couple other related patches (attached). I'm building again as I write this, so I'll try to rebase all of my patches today. The first is just visual, the second is a change to sugar-toolkit which is required to support the highlighting of the tray on drag, and the last just makes use of the go-up/go-down arrows which have been in the them for some time, but never referenced in the tray code, which was using left/right instead. Look good, just some nitpicks: 0001-Size-and-position-clippings-correctly-when-dragged.patch +context.set_icon_pixbuf(pixbuf, pixbuf.props.width / 2, +pixbuf.props.height / 2) Named parameters can give very useful info to the casual reader without making the code much more verbose. I prefer to write this instead: +context.set_icon_pixbuf(pixbuf, hot_x=pixbuf.props.width / 2, +hot_y=pixbuf.props.height / 2) 0001-Add-drag-active-property-to-tray-control-8604.patch Cannot we just use gtk.Widget.drag_highlight and gtk.Widget.drag_unhighlight? http://pygtk.org/docs/pygtk/class-gtkwidget.html#method-gtkwidget--drag-highlight I think you can push most of the patches unless you need to do substantial changes. Thanks, Tomeu On Mon, Oct 20, 2008 at 6:05 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Fri, Oct 17, 2008 at 7:06 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Fri, Oct 17, 2008 at 12:48 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Fri, Oct 17, 2008 at 6:11 PM, Eben Eliason [EMAIL PROTECTED] wrote: This is a set of patches I worked on recently, and need to rebase on the latest jhbuild before I post them officially. I wanted to expose them for comments before I put in that effort, since there are no doubt other things that will need to be changed upon review. Thanks! - Eben PS. I just noticed upon attaching that the first isn't actually a clipboard patch, but it was part of a sprint on clipboard and drag'n'drop in general, so I include it. [PATCH] Lock cursor to center of icons in favorites view on drag (#7408) Looks good, you can as well calculate again the hot point from the pixbuf in the context, instead of adding two private members more to the class. Oh really? I didn't see a way to pull that back out. Could you give me a pointer? You are right, I expected that gtk.DragContext would have an accesor as well as a setter. [PATCH] Add descriptions to clippings (#5751) Not sure if we should do the formatting in model/clipboardobject.py, that looks to me more like a presentation issue so should live in the view classes? I debated this back and forth. My decision to put it in the model meant that we could simple return a description easily in the correct format given the clipping type. Otherwise, the view needs to special case based on the type of the clipping. It seemed to me (ignoring the details of implementation) that I really just wanted description to be just a string in the model, which the view could call up at any point. From this perspective, it's natural for the model to return an appropriate string, and for the view to color, size, position, etc. that string as it wants, right? I'm ok with the concept of a single-line description of a clipping living in the model, but the _MAX_DESCRIPTION_LENGTH value seems to me like a UI decision. What about moving it to be an argument of get_description()? That sounds like a good idea. +if key == 'STRING': I'm not sure all text clippings will have the STRING target, I would do instead: +if key in ['STRING', 'text/plain', ...]: (I'm not really sure which are the most common targets that contain text, I would check the logs after a paste, these are printed in there). I'll take a look, thanks. I was always unsure about the best way to get that info; I just needed something that worked to get the rest up and running. I'll look at your previous patch to similar effect, also. - Eben [PATCH] Prevent duplicate clippings on drag within clipboard (#8606) Sounds good as a temporary measure, but I think that Gtk+ has support in its trays for reordering elements with DnD. Or it may be some extension to gtk+? Worth investigating. Yes, that's the long term solution. I just
Re: [sugar] Announce: Screencast activity.
On Fri, Oct 17, 2008 at 3:08 AM, Chris Ball [EMAIL PROTECTED] wrote: Hi, I started work on a Screencast activity tonight. It's a frontend to recordMyDesktop, which is the program Scott used for his screencasts. Having a program on the XO that's capable of preparing shareable tutorials could help out a lot with support, by allowing walkthroughs to be prepared by children, teachers, and the rest of us. Awesome! The activity is (barely) functional now, including Journal integration. The UI is entirely unpolished. Large bugs: * When you're resuming a screencast from the Journal, you have to mouseover Resume and choose Browse from the dropdown, rather than just clicking Resume. Is there a way to tell Sugar that I don't want my activity to be an option for opening the video/ogg files that it creates but doesn't know how to play? It seems that the activity might actually create both a Screencast instance as well as a resulting screencast movie file. The former would be resumable in Screencast, the latter in the default activity for video. As to the usefulness of resuming, it might be possible to add support for callouts (boxes, or arrows, or highlights, etc.) for accentuating a specific part of the screen, or for adding textboxes to the flow either as description aids (if no mic is used) or to break the screencast into short, named chapters, etc. If there truly is nothing that makes sense to resume within Screencast itself for now, we can simply store the artifact instead. * Recordmydesktop is using /tmp as an intermediate location, which means that a long screencast runs the XO into OOM (or worse). * It reuses the icon from Words. I'll think about this. I can see a 4:3 rect with a tiny XO in it being a good starting point, perhaps with an offset record button in one corner. Any better ideas? I can hack an icon together if we get consensus on something reasonable. * I think the Totem plugin might be having a scaling issue when playing back a screencast. What res do you store the final movie at, out of curiosity? Missing features: * There should be a checkbox for whether to include sound from the microphone in the screencast, which should pass --no-sound to recordmydesktop if unchecked. Great idea. * Limits on how long to record, illustration of disk full percentage, progress meter for encoding stage? All good. The first seems quite necessary. Ideally all three of these things would a) be visible all the time while recording b) not appear within the screencast output. I'm not sure that either (a) or (b) is possible, sadly. * i18n, icons for the buttons. * Find the optimal FPS setting to use. * We should avoid having the activity itself be present in the videos; perhaps by minimizing it immediately before starting recording, and then setting up a globally-bound keyboard shortcut for stop? I'd recommend transitioning immediately to the Home view when recording starts, so that screencasts always begin from the same familiar place. This is a natural starting point. However, is it possible for an activity to trigger that event? I'm even less sure about stopping. Ideally a stop button would be another piece of ever-present, non-recorded info on the screen. A keyboard shortcut might work, but can you bind it globally even if the app isn't focused? Another option is to offer (really basic) cropping, with a simple bar beneath the video with two endpoints which can be dragged independently, to trim beginning and end of the screencast as needed. If kids didn't bother, at worst they'd have a 2-3 second part at the end where they focus the screencast activity and press a stop button. Another alternative is to automatically stop recording when the activity is focused, but a) you'd still see the action of selecting the activity again and b) this would prevent any screencasts of the Screencast activity from being made. Would anyone be interested in owning this activity? I don't have time to finish it off properly at the moment, but I'd happily work with a volunteer to answer questions and propose changes. I wish I had time or experience to be able to, but I don't yet. I'd be happy to lend some graphical assistance, such as layout, button icons, etc. to anyone who takes this up. - Eben There's source here: http://dev.laptop.org/git/users/cjb/screencast-activity and a bundle here: http://dev.laptop.org/~cjb/screencast/ Thanks, - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Clipboard errata (patches)
This is a set of patches I worked on recently, and need to rebase on
the latest jhbuild before I post them officially. I wanted to expose
them for comments before I put in that effort, since there are no
doubt other things that will need to be changed upon review.
Thanks!
- Eben
PS. I just noticed upon attaching that the first isn't actually a
clipboard patch, but it was part of a sprint on clipboard and
drag'n'drop in general, so I include it.
From 08d4c23ff0cd0e48842c189711ef1dd7d3a05c05 Mon Sep 17 00:00:00 2001
From: Eben Eliason [EMAIL PROTECTED](none)
Date: Mon, 22 Sep 2008 11:36:22 -0400
Subject: [PATCH] Lock cursor to center of icons in favorites view on drag (#7408)
---
src/view/home/favoritesview.py | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/src/view/home/favoritesview.py b/src/view/home/favoritesview.py
index 0a7f0b3..7449b4c 100644
--- a/src/view/home/favoritesview.py
+++ b/src/view/home/favoritesview.py
@@ -75,6 +75,8 @@ class FavoritesView(hippo.Canvas):
self._pressed_button = None
self._press_start_x = None
self._press_start_y = None
+self._hot_x = None
+self._hot_y = None
self._last_clicked_icon = None
self._box = hippo.CanvasBox()
@@ -221,8 +223,9 @@ class FavoritesView(hippo.Canvas):
# TODO: we should get the pixbuf from the widget, so it has colors, etc
pixbuf = gtk.gdk.pixbuf_new_from_file(icon_file_name)
-hot_spot = style.zoom(10)
-context.set_icon_pixbuf(pixbuf, hot_spot, hot_spot)
+self._hot_x = pixbuf.props.width / 2
+self._hot_y = pixbuf.props.height / 2
+context.set_icon_pixbuf(pixbuf, self._hot_x, self._hot_y)
def __drag_motion_cb(self, widget, context, x, y, time):
if self._last_clicked_icon is not None:
@@ -235,11 +238,14 @@ class FavoritesView(hippo.Canvas):
if self._last_clicked_icon is not None:
self.drag_get_data(context, _ICON_DND_TARGET[0])
-self._layout.move_icon(self._last_clicked_icon, x, y)
+self._layout.move_icon(self._last_clicked_icon,
+ x - self._hot_x, y - self._hot_y)
self._pressed_button = None
self._press_start_x = None
self._press_start_y = None
+self._hot_x = None
+self._hot_y = None
self._last_clicked_icon = None
return True
--
1.5.4.3
From 3f25f0e4701ea485621af7e663388a9c4d16483d Mon Sep 17 00:00:00 2001
From: Eben Eliason [EMAIL PROTECTED](none)
Date: Mon, 22 Sep 2008 11:56:56 -0400
Subject: [PATCH] Title clippings appropriately eg. Text clipping (#5751)
---
src/model/clipboardobject.py | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/model/clipboardobject.py b/src/model/clipboardobject.py
index a4cd388..2f494d0 100644
--- a/src/model/clipboardobject.py
+++ b/src/model/clipboardobject.py
@@ -18,6 +18,7 @@ import os
import logging
import urlparse
+from gettext import gettext as _
from sugar import mime
from sugar.bundle.activitybundle import ActivityBundle
@@ -39,9 +40,12 @@ class ClipboardObject(object):
def get_name(self):
name = self._name
if not name:
-name = mime.get_mime_description(self.get_mime_type())
-if not name:
-name = ''
+type = mime.get_mime_description(self.get_mime_type())
+
+if not type:
+type = 'Data'
+name = _('%s clipping') % type
+
return name
def get_icon(self):
--
1.5.4.3
From 1fea17a5fd980048d74f90dd83dd5591c11fcc32 Mon Sep 17 00:00:00 2001
From: Eben Eliason [EMAIL PROTECTED](none)
Date: Mon, 22 Sep 2008 12:17:30 -0400
Subject: [PATCH] Add descriptions to clippings (#5751)
This patch adds support for descriptions for text clippings,
showing a preview of the clipped string in the primary palette.
In the future we'll want to add meaningful descriptions for
clippings of other types, perhaps by noting what activity they
were clipped from to provide some context.
---
src/model/clipboardobject.py | 27 +++
src/view/clipboardmenu.py|7 ++-
2 files changed, 33 insertions(+), 1 deletions(-)
diff --git a/src/model/clipboardobject.py b/src/model/clipboardobject.py
index 2f494d0..5ecec38 100644
--- a/src/model/clipboardobject.py
+++ b/src/model/clipboardobject.py
@@ -22,6 +22,8 @@ from gettext import gettext as _
from sugar import mime
from sugar.bundle.activitybundle import ActivityBundle
+_MAX_DESCRIPTION_LENGTH = 50
+
class ClipboardObject(object):
def __init__(self, object_path, name):
@@ -48,6 +50,31 @@ class ClipboardObject(object):
return name
+# TODO: This only handles text clippings. We should provide info about
+# where a clipping came from for other formats, eg. Clipped from TamTam
+def get_description(self
Re: [sugar] Clipboard errata (patches)
On Fri, Oct 17, 2008 at 12:48 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Fri, Oct 17, 2008 at 6:11 PM, Eben Eliason [EMAIL PROTECTED] wrote: This is a set of patches I worked on recently, and need to rebase on the latest jhbuild before I post them officially. I wanted to expose them for comments before I put in that effort, since there are no doubt other things that will need to be changed upon review. Thanks! - Eben PS. I just noticed upon attaching that the first isn't actually a clipboard patch, but it was part of a sprint on clipboard and drag'n'drop in general, so I include it. [PATCH] Lock cursor to center of icons in favorites view on drag (#7408) Looks good, you can as well calculate again the hot point from the pixbuf in the context, instead of adding two private members more to the class. Oh really? I didn't see a way to pull that back out. Could you give me a pointer? [PATCH] Title clippings appropriately eg. Text clipping (#5751) OK, you may want to add a TRANS comment with a hint to translators. Sure. [PATCH] Add descriptions to clippings (#5751) Not sure if we should do the formatting in model/clipboardobject.py, that looks to me more like a presentation issue so should live in the view classes? I debated this back and forth. My decision to put it in the model meant that we could simple return a description easily in the correct format given the clipping type. Otherwise, the view needs to special case based on the type of the clipping. It seemed to me (ignoring the details of implementation) that I really just wanted description to be just a string in the model, which the view could call up at any point. From this perspective, it's natural for the model to return an appropriate string, and for the view to color, size, position, etc. that string as it wants, right? [PATCH] Highlight clipboard on drag (#8604) Awesome! =) [PATCH] Prevent duplicate clippings on drag within clipboard (#8606) Sounds good as a temporary measure, but I think that Gtk+ has support in its trays for reordering elements with DnD. Or it may be some extension to gtk+? Worth investigating. Yes, that's the long term solution. I just wanted something to clean up the behavior to prevent confusion in the meantime. There is a TODO somewhere in there where I mention we should be rearranging instead, I think. It might be the case that doing it right makes the rest of this patch obsolete, but I'm not sure. - Eben Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Design-meeting REMINDER (Thursday October 16 2008 - 15.30 (UTC)) --- irc.freenode.net, #sugar-meeting
Hello everyone - We'll be having an open design meeting today. There is but one topic on the agenda: Journal. We've spent some time talking about it recently, but it's a big part of the UI, and one that's been sorely neglected. In particular, we'll be discussing a plan forward given the work that both Tomeu and Scott have put into it. For background: Tomeu's new datastore: http://www.mail-archive.com/[EMAIL PROTECTED]/msg08412.html Scott's new Journal: http://dev.laptop.org/~cscott/journal2-talk.pdf - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Design-meeting REMINDER (Thursday October 16 2008 - 15.30 (UTC)) --- irc.freenode.net, #sugar-meeting
Since we don't have everyone we'd like for proper design input, we're going to hold the meeting from a slightly more technical angle, to determine possible ways to integrate the work being done. - Eben On Thu, Oct 16, 2008 at 10:56 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Would work with me. Regards, Tomeu On Thu, Oct 16, 2008 at 4:51 PM, Christian Marc Schmidt [EMAIL PROTECTED] wrote: Hi everyone Unfortunately I'm travelling today and won't be able to be on the call. Can we do this tomorrow instead? Christian Sent from my iPhone On Oct 16, 2008, at 9:26 AM, Eben Eliason [EMAIL PROTECTED] wrote: Hello everyone - We'll be having an open design meeting today. There is but one topic on the agenda: Journal. We've spent some time talking about it recently, but it's a big part of the UI, and one that's been sorely neglected. In particular, we'll be discussing a plan forward given the work that both Tomeu and Scott have put into it. For background: Tomeu's new datastore: http://www.mail-archive.com/[EMAIL PROTECTED]/msg08412.html Scott's new Journal: http://dev.laptop.org/~cscott/journal2-talk.pdf - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] code contributions to Sugar (was Re: Sugar Clock)
On Wed, Oct 15, 2008 at 4:30 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Tue, Oct 14, 2008 at 9:27 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: P.S. I think this is a good example of why contributing to Sugar is necessarily hard. Many small technical contributions from the community require significant policy decisions by the leaders. When Sugar's subsystems are as mature and rationalized as the kernel's, then perhaps we will be able to add small components without needing big decisions, but that point is still years away. Anybody has ideas about how we could improve this? One thing that may help is the recent refactoring that Marco made in the shell. Adding a clock widget to the frame is now a matter of dropping a .py file in the extensions/deviceicon directory. What else needs to happen? Are you sure that's all? ;) We should likely support dropping in a directory as well, so that an icon can be packed in along with the .py. We don't want every extension to require the author to hack artwork also. Icons should only be in artwork if they are a) part of the core OS or b) potentially useful to many activities. Extensions to the devices, the home layouts, control panel modules, and anything else that we'd like to support should include all necessary components in a self-contained way. But this is a great start! - Eben Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Tagged Journal Proposal
On Wed, Oct 15, 2008 at 6:03 PM, [EMAIL PROTECTED] wrote: a few random observations that i had today, prompted by scott's talk/demo: - while people don't tend to name their jpegs (today), they do tend to group them into folders (e.g. vacation_pix). the equivalent of this in a tagged world would be bulk tagging. i assume scott has thought about this in his UI, though i don't recall noticing it. His prototype did sport the checkboxes for the creation of multiple selections. When such a selection exists, a toolbar with any actions which can be performed on multiple objects (delete, tag, copy, send, etc.) will appear. There are certainly some details to work out. For instance, I expect that we might need a way to show only selected items via a filter, so that managing the selection is easier. We may also need select all so that it's easy to apply actions to the entire set of results in a search. - likewise, removing all the files in a directory, or moving half of them elsewhere (imagine rearranging the photos you just pulled off the camera), implies that there should be equivalent tag operations for doing bulk tag removal, and bulk tag editing. (note that this need is independent of the path-component-as-tag feature -- these operations are simply required of any system intended to replace hierarchy with tags.) Good point. I've been envisioning the tagging UI as a space with current tags (editable), and with tag suggestions (clickable, to add to the current tags). In the case of a multiple selection (made in any manner discussed above), the current tag section would only list tags which apply to all of the items in the selection. The suggested tags, of course, would naturally include many, or all, of the tags which apply to only some of the selected; their frequency would determine which are most important to show (if we need to limit the suggestion list). In this manner, I could select a dozen photos I took in order to tag them all vacation; I might also notice that the photo tag only appeared in the suggestions, implying that some (or all) of these didn't contain that tag. Clicking on the suggestion would then apply it to all. The current tags could also be edited (or removed) directly. - jim made the observation that he found himself using tags less and less over time, once he realized that the full-text indexer he was using made traditional filing unnecessary. i've found the same thing (i index my MH mail folders with mairix) -- but i do still use folders (i.e., tag equivalents) to make it easy to retrieve things for which i think i may not remember the right search terms later on. and of course i especially use them when the tags (folders) can be assigned automatically (with sort filters). all of which is to say that i view tagging as an extension of full-text search, not a replacement. It's certainly an extension in many cases. It is a replacement for most non-text formats. Of course we can hope to depend on some automatic metadata as well, but as we've seen already from experience, the automatic metadata we have now is insufficient. On a related note, the current DS forgets (that's a kind word, I think) all metadata supplied by activities, which undermines a lot of possible advantages to activities (like storing the current page in Read), as well as preventing them from going to the trouble to provide any metadata which might be useful to the kids for finding things later. Proposal (off the cuff, please poke holes in this): We might beef up the HIG in the area of tagging, and even suggest a set of canonical tags for various types of content. (Localized, of course.) Combining this with Scott's path-tags, we might introduce Images/, Videos/, Documents/, and Audio/ tags in such a way that we get the best of both worlds. The system can automatically file things away in a reasonable subdirectory of the Journal, but the kids can always find *anything* they've done, in chronological order, by looking in the Journal itself (before selecting one of these path-tags as a query). - Eben - we need to be mindful of erik's concern that if the goal is to solve the problems deployments are reporting, whether with file management or anything else, that we not over-engineer the design in a way that keeps us from finishing the implementation. while our mission may be to build something better, we shouldn't let that get in the way of building something that, while old, is very useful. (e.g., if we haven't made enough progress on the real solution, and kids would be best served in 9.1 by a file manager activity of some sort, then we should provide one.) =- paul fox, [EMAIL PROTECTED]
Re: [sugar] (very) Little Proposals for 9.1
Hi all, sorry I'm late on this thread.
On Mon, Oct 13, 2008 at 6:53 AM, Carlo Falciola [EMAIL PROTECTED] wrote:
Hi,
during past week-end I spent a few hours playing with the 676 -Candidate ,
mainly in order to check translated strings here an there.
Then let my very personal user base (My children: Nicola, 7 and Giovanna, 6)
to play a bit with the updated XO.
After these user sessions we have a very personal wish list and small
inputs for the next software iteration that we would like to share:
Carlo : nowhere in the default GUI there is a clock, even if, in the control
panel there is a panel to configure it. I think that personal watches are
maybe not so easily owned by kids around the word, so a standard clock could
be a little, but welcomed feature. (not talking about the clock activity that
it is more a learn to read a clock thing than an everyday tool). any
feedback and suggestion regarding how and where to put/show it are welcomed.
I personally would like to see this built. I've always thought that a
clock device would fit perfectly into the bottom edge of the Frame.
I'd really like to see us rework the devices a bit so that they are
more naturally pluggable (at most, the user would only have to add
one directory at some location in the system to add a new device). In
the future perhaps we can extend this to a user-facing management of
installed devices.
Apart from the trickiness (and potential CPU hit) of dynamically
updating the clock icon (I envision an analog clock here, with digital
display and date and/or calendar in the palette, so granularity would
be on the order of a minute or so).
Giovanna: Why not to enable shut-down from the XO icon of any of the standard
view? The icon is always there in the middle of screen but works only in
one... (in general, maybe enabling the hoovering menu in all of the views
Home, Neighborhood, Group could make sense and could be reasonably easy to
do)
I definitely thought I filed a ticket years ago about making the
palettes consistent in the views. I can't find it now, so I must be
mistaken, but I agree this is something to aim for.
I also think that the addition of a computer device to the Frame
might be worth considering, but we should all think carefully about
what it means, and how it relates to the Journal, before diving into
that solution.
Nicola: Should be nice to have a bit more feedback regarding already running
activity into the home view, since now he has a more immediate approach to
the system and he is not, as now, yet really interested to the past story of
his interaction to the system, so he do not care ('till now) so much of the
journal and frame.
For his approach a visual hints of running activities (let's say the activity
icon in the circle to became colored and switch default click acton to be
resume ), maybe could be more useful for his basic approach
Have you looked at the recent designs posted on the wiki, regarding
the new Home view? The current implementation is only half the story,
and I hope the second half appears in Sugar soon. We should make sure
the other half, which exposes recent activities, is actually an
adequate solution.
See: http://wiki.laptop.org/go/Designs/Activity_Management
- Eben
I'm really sorry not to be/feel to master coding yet enoght in order to back
those ideas with any code, but anyway I think it is reasonable to share the
experience.
grazie a tutti
Carlo
(+ Nicola e Giovanna)
Scopri il blog di Yahoo! Mail:
Trucchi, novità e scrivi la tua opinione.
http://www.ymailblogit.com/blog
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Launching activities from other activities
On Mon, Oct 13, 2008 at 6:42 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Morgan wrote: Hopefully Rainbow will grow a mechanism for activities to request it to launch other activities given certain restrictions. += MAX_INT Heh. I really think we need this. The current solution really is a hack which plays nice with rainbow, but doesn't provide an optimal experience. I know Michael has some ideas on how to make things both nice and secure. How far are we from an implementation plan here? This functionality also seems important in relation tot he narrative topic which Michael expressed interest in before. We need to take a lot of steps forward, one at a time, in making information easy to move among various activities, and this includes the ability to launch other activities from within activities. We'll also want to consider how the invoking activity might get access to the result of a launched activity (maybe we get this for free?). - Eben ++1 Please include discussion of such a mechanism in the 0.84/9.1/future planning session that is coming up in mid-November. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] scrolling the journal list view (was Re: alt-tabbing to the Journal)
On Sat, Oct 11, 2008 at 9:38 AM, Walter Bender [EMAIL PROTECTED] wrote: On Sat, Oct 11, 2008 at 6:34 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 5:27 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 3:26 AM, Gary C Martin [EMAIL PROTECTED] wrote: - Realtime scrolling so you can just grab, drag, and look as it goes past. Indeed. I have never been satisfied with the row-by-row scrolling, but we couldn't do better in terms of performance before. In redesigning the Journal, it was very important to us (to me, at the very least) that smooth pixel-scrolling was part of the plan. Tomeu, do you think we can make a transition like this for 9.1? I think it would be another big boost to using the Journal. Sure I think we should do something for 9.1, but right now the resourcing part is a bit complex. Maybe Scott can comment on this? Is this the right place to expend effort? From my experience, better paging control would be more useful than fine-tuning the scrolling. The path to better scroller, actually, is to define a proper form of paging control, which we don't yet have at all. A paging system that works will make it possible to scroll smoothly through the portion of the Journal which is currently visible, so we'll win on both fronts with this effort. The main problem here is potential length of the scrolling page. Its unbounded, except by space constraints, right now. There are two viable options here that we've talked about. First, we could introduce the notion of paging, so that after scrolling to the bottom of a page in the Journal, you have (older) and (newer) buttons to get to other results. Second, and my preference, we could introduce temporal section headers. After scrolling far enough back in time, there might be sections for each month, and further back, for each year, etc., with each section being represented by a header only, and a disclosure button. Clicking on a section would open it inline, closing the currently open section, thus keeping everything in the Journal temporally ordered on a single infinite page, but allowing one to dive into it in any range of time. Yes, I like this idea and I think it's pretty much doable. Eben, weren't there a bunch of sketches regarding smart exponential timescales we had developed early on? Maybe dust those off? Some where quite good. Every time we tried to come up with an inline timeline view for a scrollbar, we hit complications and ultimately wound up simplifying back to a standard scrollbar. I think there are definitely possibilities here still, but in terms of what's feasible for some real improvement in the next 6 months, I think continuing to use the standard scrolling mechanisms while introducing smarter folding of time is the better course. - Eben Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Viewing PDFs from Browse
The user couldn't annotate a file they don't have. Obviously we have to download the bits to a temporary location to view them, but in the normal paradigm of the web, nothing is permanently kept unless you explicitly download it. Perhaps an attempt to navigate away from the page could ask if you wanted to keep it around or not, but I'd just as soon expose the keep button and have kids learn to keep only what they actually want. Everything on the web is transient unless you grab something while you can. It doesn't really make sense to me to add annotation tools and such to the pdf viewer in Browse for this reason. It should remain limited to handy viewing controls, saving the annotation tools for Read once the document is local, I feel. (As an analogy, you wouldn't expect to be able draw on top of or otherwise edit an image within Browse, right? You'd be able to zoom, pan, *maybe* rotate; but you'd download it and edit it in an activity designed for that purpose.) - Eben On Sat, Oct 11, 2008 at 6:21 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 5:01 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 10:53 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 4:46 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 4:24 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 1:40 AM, Eben Eliason [EMAIL PROTECTED] wrote: Hey, this looks pretty cool, actually. One powerful addition which I think is necessary in order to adopt this is the addition of a Keep button in that toolbar, by which one *could* download the pdf for offline reading later if wanted. In a similar vein, would it be possible to create a supplemental toolbar like this for other media types which browse specifically supports? I could see having a similar UI for images, and a perhaps for audio and video, too. The ability to view various formats directly, yet also have a one-click means to download the file, sounds promising. Hmm, shouldn't the act of viewing a PDF create an entry in the journal that allows you to resume this act? If so, shouldn't the viewer plugin create an entry in the journal by itself and that entry would contain the PDF? Well, in this new model, I'd think not, actually. I can view an image directly within Browse without creating a new Journal entry. Basically, anything Browse handles natively remains a part of my Browse session. Anything which it cannot, or which I explicitly wish to keep for myself, becomes a new downloaded object. So Browse would create some kind of entry that would allow resuming the reading of that book? Of course. Basically, the following would happen: 1. Child clicks on a link to a pdf (or natively supported media type) 2. Browse displays the pdf directly, with the contextual toolbar 3. Browse does not yet interact with the DS; this is just part of what it does (Stopping here would result in no Journal entry, apart from the Browse one) Not sure about it, if the user spent some good time reading (and perhaps annotating) the PDF, shouldn't the journal record this in the same way it tries to record all worthy interaction with the machine? Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
On Fri, Oct 10, 2008 at 8:45 AM, Garrett Goebel [EMAIL PROTECTED] wrote: Elana Langer wrote from Mongolia: basically when teachers and students try to find their work (write, record, etoys) in the journal it is hard for them to locate it - especially if it is more than a few days old. This is why everyone is desperate to save their projects on USB keys. This could be made much easier if Sugar apps prompted the user for tags when shutting down an application. Yes, I think we need to assume this model. I don't think this is going to break the basic paradigm of Sugar, since this prompt need only happen for *new* activities. Anything which has been previously kept in the Journal will continue to autosave. It's only the first time that you *really* need to give a meaningful title, and also then that you might decide it's not worth keeping at all. I know it is a goal to require as little text as possible. And I'm not sure what images could universally convey the message correctly... but basically: Would you like to tag the state of this activity? Y/N ...followed by a prompt for the user to enter tags. We can do a little better than that, actually, by making it all one prompt. It can have a name field, already filled out with the best darn attempt at a name we can manage, a tag field (and perhaps even a list of popular tags as well, to apply to it with a click or a drag/drop), and buttons for [Erase] (Or [Don't Keep]?) and [Keep]. - Eben cheers, Garrett ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [Cross Posted] High res screenshots of Sugar
On Fri, Oct 10, 2008 at 12:09 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: Am 10.10.2008 um 18:02 schrieb Sayamindu Dasgupta: On Fri, Oct 10, 2008 at 9:24 PM, Bert Freudenberg [EMAIL PROTECTED] wrote: Yeah - that's what confused me :-S If it's too hard to educate their art department, just make a screenshot and adjust the dpi in PhotoShop to 300. They won't notice. But don't you think the print process will break in that case ? Be sure to find out if they really need 300dpi to print. I suspect they don't. Most printers will print whatever dpi you push them (within reason). It's likely the case that they simply request that as a minimum because, for anything that isn't under a fundamental resolution limitation like a screenshot, anything less will be of noticeably lower quality once printed. In this case, you'll be able to see the actual pixels if the screenshots are printed large enough, but so what? That's the real image. And, as mentioned before, you'll actually have their suggested resolution for anything that's printed at 4x3 inches or smaller. No, why would it? It's just pixels, and this changes a single number in the picture file (if you adjust dpi without resampling). This is a very important point. Don't use any form of resampling when you (if you must) change the dpi, or you'll wind up with a really high res image that has blurry edges where they should be crisp. (If there is no don't resample option, use nearest neighbor, which means the same thing.) If you *really* wanted to get fancy, run Sugar inside a VNC server of say 12000x9000 pixels at 2000 dpi. Sugar is designed to be scalable to all resolutions so in theory this should work. In practice you'll find there are some things that are not really scaled. Fonts will probably be messed up in that case. They shouldn't, Sugar uses scalable fonts. - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
On Fri, Oct 10, 2008 at 1:05 PM, NoiseEHC [EMAIL PROTECTED] wrote: We can do a little better than that, actually, by making it all one prompt. It can have a name field, already filled out with the best darn attempt at a name we can manage, a tag field (and perhaps even a list of popular tags as well, to apply to it with a click or a drag/drop), and buttons for [Erase] (Or [Don't Keep]?) and [Keep]. A little better solution would be if the words in the name would be treated as tags and if the save dialog would offer autocomplete for those tags. I think tag autocompletion is a definite must, to get this system off the ground. Tagging via the Journal could just set words to super tags so they would not be shown in the name but would be handled harder than soft tags in searching or in the proposed tag submenu thing. If the user would type in the tag via autocompletion then it should be treated as an explicit tag. I don't have a clear image in my head from this description, but I do see the direction you're heading, and it's interesting. I'm not sure exactly how the titles are handled right now, but the idea of auto-completing within the title field, in some form, might have promise. An interesting twist on this might be to look for related Journal entries based on the title typed thus far, in order to provide a list of most likely tags to choose from for the entry (tags which are also applied to other things with similar titles, mime-types, etc.). In this manner, once a base set of tags were in use in the Journal, tagging could become as simple as saying yes, these three things you suggest actually do apply to this thing I made, and then optionally and maybe this one other new tag, too. In a sense, this means that tagging is almost free, since the process of creating a good title will provide a solid set of tags to choose from. Tagging becomes an extension of naming, rather than a separate task. I am not sure if you can understand it so here is another try from the opposite side: The problem with tagging is that it is painful to select something on the XO from a drop down menu (the list of available tags). (Note that developing Right, this is why I think intelligent filtering of the list of suggested tags is also needed. Sugar on a Linux PC is cheating...) The whole notion of explicit tagging is also a nuisance and requiring tagging at save time is painful. So this proposal just tries to simplify the process from the user's perspective (and makes coding the Journal very very hard, but since somebody other than me will code it I do not care...). Autocompleting, not only tags but soft tags too, would result in that if the user is doing some project lately then the system would offer him the project's name since probably it would be used lately a lot. Also it could be used for filesystem paths as well but probably I should see that GNOME UI Hackfest video first. Hmm, I'm not sure that autocompletion on full titles is beneficial (that might not be what you're suggesting) because we want to discourage identical names, rather than encourage them. On the other hand, offering completion of words within the title based on tags is interesting. Would these soft tags (tags auto-completed in the title) also appear in the tag field? How would we make the system evident? Maybe it's still most clear if the title just serves as a seed for the recommended tags (some of which might be verbatim in the title) so that a few clicks can apply all those relevant. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Fri, Oct 10, 2008 at 1:42 PM, Gary C Martin [EMAIL PROTECTED] wrote: On 10 Oct 2008, at 14:26, Tomeu Vizoso wrote: On Fri, Oct 10, 2008 at 3:02 AM, Bill Kerr [EMAIL PROTECTED] wrote: On Fri, Oct 10, 2008 at 12:27 AM, Michael Stone [EMAIL PROTECTED] wrote: Bill, Here's a short dialogue between myself, Ben Schwartz, Martin Dengler, and Bobby Powers on my interpretation of narrative as it might apply to a user interface designed for engaging children in the world of learning: http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 Do we have any proposals of changes to Sugar so it better supports learning in light of the reflections on narrative? One random thought that overlaps with some ideas on Activity help... What if Activity and Content bundles were one and the same. You could have bundles that just hold an Activity to install, or just have Content for the library, or more interestingly have it hold both an Activity and library Content. For a concrete example, I could see myself writing a handful of web pages as part help, and part guide, to viewing and understanding the Moon, it's phases, some traditions, stories etc. I do not want to bloat out the Moon Activity UI with help tabs, buttons, and pages of text and images formatted in some weird GTK encoding. The Activity should be clean and light and focused on it's function. All the 'narrative' material should go into the library as html web content (pdf's can be nice but are resource intensive and have interaction issues of their own). It would be great if by installing Moon.xo, the bundle could also contain some library content. Actually this is what the Mac OSX does. Applications contain what is pretty much some indexed html help files that the system auto adds to it's help engine when you install an Application. My MoonDock app uses this to provide a page or two of instruction about the Moon. I guess I could provide something similar today by making two bundles, one of html library content, and one of the Activity bundle. Maybe there are benefits to this dual bundle arrangement (separate the Activity from documentation translation tasks; only install what you need to preserve nand space)? You bring up very good pros and cons. I think it would be convenient indeed if the bundle format allowed activity, help, and content bundles to be packaged up together and handled appropriately by the relevant parts of the system. Making a pluggable help system like this was one hope we had. Maybe the right thing to do instead (or in addition) is to extend the idea that bundles can come in a variety of canonical forms, perhaps each with their own mime-type, so that they can be downloaded from anywhere and then opened by the correct activity when launched (and, better, automatically detected by the relevant activities when needed). We should definitely give another look at bundles and how we expect them to operate in Sugar. All types of bundles currently hobble along; a precise definition for what they are and how they function would be a big step forward. - Eben --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Home view
On Thu, Oct 9, 2008 at 9:45 AM, Bert Freudenberg [EMAIL PROTECTED] wrote: Am 09.10.2008 um 14:20 schrieb Mikus Grinbergs: So, how about removing the list view and leaving that task to the Journal? It's a much more logical place anyway, the list view is basically a filtered view of the activity bundles in the Journal, right? So if the Journal allowed a filter to just show activities we would not need the list view and remove one point of confusion. When I install Activities I do so through 'sugar-install-bundle', not through the Journal. In this proposal, I would be left without a GUI listing of the Activities installed on my system. [I believe a customization key does not journalize the Activities it installs, either.] Well, it should. And using the command line should have the same result as using the GUI. My perception of the list view in Home is here is an user interface specifically suited for the manipulation of activity bundles. I'd prefer to delete/upgrade/install activities through here, rather than through Journal. [The other views of Home show activity labels only with hovering - I have way too many activities installed for me to try to remember what each icon represents.] Good point. The favorites view should be able to show labels, too. But the list view gets in the way more often than it is useful for me (and using activities surely outweighs installing/removing activities by far). I'm curious how it gets in the way. If you don't like it, you needn't ever go there, right? Newly installed activities should be starred by default. (I acknowledge the bug you bring up in which that's not true via all installation methods.) I think the list is useful for (extreme) scalability reasons, to see the title, date, and perhaps later other information (versions, author, etc) directly in the view, and simply as an accessibility solution. More importantly, the Home view is the first to receive the treatment, but for 9.1 all zoom levels will have list views. It's particularly important in the Neighborhood, where the freeform layout will only be able to show a subset of the available information. Switching to the list, however, will provide a neatly categorized and sorted view of all the available people access points, and activities, which can be scrolled or filtered. - Eben - Bert - ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On Thu, Oct 9, 2008 at 11:28 AM, Brian Jordan [EMAIL PROTECTED] wrote: On Thu, Oct 9, 2008 at 4:57 PM, Michael Stone [EMAIL PROTECTED] wrote: Bill, Here's a short dialogue between myself, Ben Schwartz, Martin Dengler, and Bobby Powers on my interpretation of narrative as it might apply to a user interface designed for engaging children in the world of learning: http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 My favorite part was the end: bemasc making content bundles work better sounds very valuable. We certainly don't provide nice content creation tools. I heartily agree that this is an area in which improvements are worth pursuing. m_stone lovely. now if only you weren't in engaged in pursuit of further education... :) bemasc right. === Highlights * By narrative, I mean a rational sequence (or graph) of events. * It's rather hard to use XOs to prepare direct lessons. By direct lesson, I mean a guided learning experience, usable in variable network conditions, which minimizes the amount of decision-making and navigation that the end-user needs to perform in order to experience 'the whole thing' regardless of what software implements each individual experience contained in the lesson. === Toy Problem Concretely, suppose I invent a new Python trick like the ones at http://wiki.laptop.org/go/User:Mstone/Tricks How might a prepare a slick explanation for an inexperienced user? * I might write up a web page for my trick, then write a Pippy bundle showing off the trick in a toy program, then give a pointer to a git repo containing an instance of the trick in 'production'. Question: How do I write web pages on an XO? Question: Do I have to be able to read in order to find and run the Pippy bundle? * I might write up a larger Pippy example for my trick in the literate style. I might also create a puzzle revolving around integrating the trick into some sample code. I might include links to 'advanced reading' or more examples in comments in the source code. Question: Pippy doesn't know anything about hyperlinks. Will my readers? Question: I must either comment out my puzzle so that the example can run or I must provide it in a separate bundle. How many users would figure out how to try both the example and the puzzle? * While not obviously applicable to this specific example, two other common solutions to this sort of problem include the scripted transitions between freeform experiences idea common to wizards and role-playing games and the 'build a custom but user-editable program' idea underlying most EToys lessons. === Larger Concerns Since Sugar is strongly concerned with UI unification, it's worth spending more time thinking about how well each of the solutions to your favorite toy problem integrates with encompassing narratives of reflection, criticism, and human collaboration. (None of the solutions I've proposed above satisfy me in any of these regards.) In any case, I hope this followup helps explain the motivation and 'line-of-thought' behind my initial email. Please discuss. Regards, Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar So, how about (1) a way of creating content bundles with journal content created on the XO, and (2) a way of transferring these bundles and journal items from XO -- XO without having to use a USB key? We've always envisioned (1) as an activity (The Bundle activity, in fact), which would serve both as a way of creating and managing activity and content bundles, as well as provide a generic tool for inspecting , modifying, or creating various type of archived format (zip, tar, gz, etc). Also, please note that Lewis Barnett (CC'd), a professor from the University of Richmond, has adopted this project and is working on it as a class initiative. I had a teleconference with some of his students several weeks ago to discuss initial details, and I'm excited about what we can accomplish with them. I haven't heard from them since, and I'm not sure if a project has been setup for them yet. Perhaps you could give us a breif status update, Lewis? Thanks! (2) Should be handled like any other object transfer between XOs, which hasn't been built yet, but is certainly on the list of needed features. There is, of course, special consideration to be given to the passing of activity bundles, a la the former discussions on implicit sharing, trusted code, etc. - Eben Does (2) currently exist (outside of terminal), by the way? Could (1) and (2) be done as activities? Regards, Brian ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar
Re: [sugar] Viewing PDFs from Browse
On Wed, Oct 8, 2008 at 8:55 AM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 5:10 AM, Eben Eliason [EMAIL PROTECTED] wrote: Hey, this looks pretty cool, actually. One powerful addition which I think is necessary in order to adopt this is the addition of a Keep button in that toolbar, by which one *could* download the pdf for offline reading later if wanted. Yeah - the keep button is in my TODO list. However, something which might be a bit confusing is the fact that when Browse accesses a PDF, it creates an entry for that in the Journal, and once the user presses the Keep button, yet another entry will be created - which can be opened by Read later. Do you think two entries for the same thing might be confusing ? Yes, this actually does run counter to intuition. If we desire to show the pdf within the Browse activity (which is certainly an understandable goal), than we need to embrace the idea fully. It's just another file which gets temporarily cached for viewing purposes, unless a Keep button is pressed to indicate the desire for permanence. We shouldn't be making a new entry when the pdf is viewed within Browse at all. In a similar vein, would it be possible to create a supplemental toolbar like this for other media types which browse specifically supports? I could see having a similar UI for images, and a perhaps for audio and video, too. The ability to view various formats directly, yet also have a one-click means to download the file, sounds promising. For audio/video, it's definitely doable. I'm not sure about images, since I think Browse has its own way of handling images. Hmmm, interesting. I had thought images would be the easiest to handle. I think the ability to scale, rotate, etc. would be really slick to have, and images are something that one finds online quite often. Perhaps there is a way to override the default? It would be really nice to handle various media types consistently, with a short list of tools for interacting with them, and a keep button. - Eben PS. We'll likely want a copy button in addition to keep! Clipping media to the clipboard for direct integration in another activity is just as valid as holding onto it as its own entity. - Eben PS. While I agree this is a nice thing to support in Browse, we'll need to make this change very clear, as teachers and kids are familiar with the current behavior which automatically downloads any .pdf clicked on. We wouldn't want to confuse them when it doesn't appear in their Journal directly. +1 Thanks, Sayamindu On Tue, Oct 7, 2008 at 6:46 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: Hello, It looks like reading PDF files from the web via Browse is a pain, since, Browse saves the file to Journal, and then one has to go to the Journal and open up the saved file via Read (#8330). Can we treat PDF files like we handle media files (oggs mostly) by means of a Browse plugin ? I took a look at this during the weekend, and came up with a hack which looks like http://dev.laptop.org/~sayamindu/Screenshot_browse_pdf.png I used mozplugger and a simple PDF viewer using the Evince python bindings to make my work simpler. Can this be a possible workaround till we find a better solution ? Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Module Proposal: Image Viewer Activity
On Wed, Oct 8, 2008 at 4:34 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 10:27 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Tue, Oct 7, 2008 at 9:04 PM, Sayamindu Dasgupta [EMAIL PROTECTED] wrote: Hello, I would like to propose the inclusion of the Image Viewer Activity into Fructose: Just gave it a try and looks awesome. Should we make it the default activity for images? http://dev.laptop.org/git?p=sugar;a=blob;f=data/mime.defaults;h=1cb26876abb7b2518b5282f474df2567f7356ad0;hb=fb24b313694e06e340be5074d9740e5ef64bb591 I think so. I agree. - Eben Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Viewing PDFs from Browse
On Wed, Oct 8, 2008 at 4:24 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 1:40 AM, Eben Eliason [EMAIL PROTECTED] wrote: Hey, this looks pretty cool, actually. One powerful addition which I think is necessary in order to adopt this is the addition of a Keep button in that toolbar, by which one *could* download the pdf for offline reading later if wanted. In a similar vein, would it be possible to create a supplemental toolbar like this for other media types which browse specifically supports? I could see having a similar UI for images, and a perhaps for audio and video, too. The ability to view various formats directly, yet also have a one-click means to download the file, sounds promising. Hmm, shouldn't the act of viewing a PDF create an entry in the journal that allows you to resume this act? If so, shouldn't the viewer plugin create an entry in the journal by itself and that entry would contain the PDF? Well, in this new model, I'd think not, actually. I can view an image directly within Browse without creating a new Journal entry. Basically, anything Browse handles natively remains a part of my Browse session. Anything which it cannot, or which I explicitly wish to keep for myself, becomes a new downloaded object. - Eben Note that all this shouldn't duplicate files any more. Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Viewing PDFs from Browse
On Wed, Oct 8, 2008 at 10:53 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 4:46 PM, Eben Eliason [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 4:24 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 1:40 AM, Eben Eliason [EMAIL PROTECTED] wrote: Hey, this looks pretty cool, actually. One powerful addition which I think is necessary in order to adopt this is the addition of a Keep button in that toolbar, by which one *could* download the pdf for offline reading later if wanted. In a similar vein, would it be possible to create a supplemental toolbar like this for other media types which browse specifically supports? I could see having a similar UI for images, and a perhaps for audio and video, too. The ability to view various formats directly, yet also have a one-click means to download the file, sounds promising. Hmm, shouldn't the act of viewing a PDF create an entry in the journal that allows you to resume this act? If so, shouldn't the viewer plugin create an entry in the journal by itself and that entry would contain the PDF? Well, in this new model, I'd think not, actually. I can view an image directly within Browse without creating a new Journal entry. Basically, anything Browse handles natively remains a part of my Browse session. Anything which it cannot, or which I explicitly wish to keep for myself, becomes a new downloaded object. So Browse would create some kind of entry that would allow resuming the reading of that book? Of course. Basically, the following would happen: 1. Child clicks on a link to a pdf (or natively supported media type) 2. Browse displays the pdf directly, with the contextual toolbar 3. Browse does not yet interact with the DS; this is just part of what it does (Stopping here would result in no Journal entry, apart from the Browse one) 4. Child clicks Keep button in contextual toolbar 5. Browse initiates a download of the pdf, as it does now 6. The resulting object in the Journal is just a pdf 7. pdfs open in Read by default; Read opens when the child clicks the book Does this model make sense? While within Browse, we're still just browsing about within the context of the Browse session itself. When we keep a media object, we download that object in its raw form, and it can later be opened by any supporting activity, but will always be opened with the default handler for its mime-type by default. (It won't be associated with Browse). - Eben Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] alt-tabbing to the Journal
On Wed, Oct 8, 2008 at 3:26 AM, Gary C Martin [EMAIL PROTECTED] wrote: On 8 Oct 2008, at 03:51, Walter Bender wrote: The bottom line is that, at least as far as the XO is concerned (and other machines with limited memory and no swap) the list of activities to tab through, with or without the Journal, is going to be a short list, so is it really such a pressing issue? For tabbing, I think one frustration here is the current issue with tabbing where the delay is way too short before an Activity you're tabbing past is pulled into focus (I'd argue there should be no auto delay focus, only focus when alt key is lifted, allowing you to easily skip items in the stack). Currently in 8.2, accidentally tabbing the 'wrong way' through the active instances on the XO and getting shown the wrong thing (usually Journal given only having a few activities running) is painful enough time wise to distract you from whatever goal you had in mind. Example: TurtleArt, and 2 x ImageViewers showing some screen shots of different brick code you want to reference. Tabbing between TurtleArt and the images you trying to reference is constantly intruded upon by the redraw, and update of Journal – if you're just mucking around, it's less of a pain, but if you're actually trying to 'get stuff done' it can get quite annoying pretty quickly. I'd love the same passion developed to some of the issues/topics that impact the learning. How can we make the Journal better, regardless of how we open it and regardless of whether we consider it an activity or part of Sugar core? I guess most interested parties on the sugar list are more technical than pedagogical types. Both my parents were teachers, and when computers started to make their way into some of their lessons/labs, way back when, I seem to remember they would come home somewhat bemused, having been handed boxes of cables and computer kit. As an ~11yr old I would set it up, get things going, and show them how to load-up and use the software. It's an interesting generational shift, I wonder what new idea is going to come along and be so far from our expectations that we'll be too inflexible as adults to really pick it up well (here already?). Maybe it's just a personality trait thing and not age at all; I guess I know enough people my age who I wouldn't trust to safely 'shut down' an operating system without being given a lesson or two first ;-) OK. Journal, and its related use, have some UI improvement possibilities that could be targeted (and I think a few might be targeted already for work), without having to solve the big 'impact on learning' type wider research/study goals. Some things that come to mind just now (in no special order and I'm sure most have been discussed already at some point): - Sort view by creation date, not just by last modification date. Currently when you resume something, even just to take a look, it pulls it out of the time context of other entries it was created alongside. One click, and last weeks essays narrative/reflection is lost (the photos you took, the chat discussions you had with classmates, the audio you recorded, the picture you painted etc). This is a big part of the need for versions. What you really get when you worked on something last week, and also today, are two versions of that thing, distributed in time appropriately. Sorting by either creation or modification date is incorrect. - Filter view for starred items only, a single click way to quickly hide the unwanted. Yes! I had hoped this would make 8.2, but we didn't have time to finish it. Right now, starring is utterly useless, apart from the visual indication to the user that they might care about it. Being able to filter to only starred items will be a big big advantage for usability of the Journal. - Improve the 'Anything' pop-up UI. It takes me about 4-5sec of scrolling to get to the bottom of the Activity and mime file type list. And worse, if you do scroll way down, it takes just as long to get the Journal back to default after your search. I guess ideally this would become a custom palette grid of some kind, perhaps with just icons and mouse over text for the full names to save space. Another option could be for a short list of the most That's an interesting idea. In fact, we might consider something like that for all of the filters. They're kind of ugly as is, and take up a lot of horizontal space that could be better used. I'll try some mockups. The time popup, then, could even have a calendar in it, so that in addition to some basic ranges, you could say show me everything I made the month of december last year. frequently used N activities (or the current Home view favourites), and then a 'more...' end item that would reveal a large slide-out, below toolbar dialogue with all installed activities and file types listed. Actually, you could cut to the chase and have an 'Anything' button that just
Re: [sugar] Give a Laptop, Change the World : G1G1 2008
On Wed, Oct 8, 2008 at 7:58 AM, Walter Bender [EMAIL PROTECTED] wrote: I prefer the Sugar learning platform +1 from me as well. (I'm torn on platform vs. environment; the latter actually sounds a little friendlier, to me.) - Eben -walter On Wed, Oct 8, 2008 at 4:35 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Tue, Oct 7, 2008 at 11:49 PM, Samuel Klein [EMAIL PROTECTED] wrote: The laptops feature the latest release of the Sugar window manager, ... I think we should be able to find a better term than window manager, Matchbox is the window manager used in 8.2 and it hasn't been modified by OLPC. Some suggestions: - learning environment, - collaborative user interface, etc Regards, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Give a Laptop, Change the World : G1G1 2008
On Wed, Oct 8, 2008 at 1:05 PM, John Gilmore [EMAIL PROTECTED] wrote: I prefer the Sugar learning platform And my laundress prefers fabric revitalization consultant. Sugar isn't about learning. Sugar is a user interface. It draws I find your first statement wholly contestable. Moreover, the two (user interface, learning; or, stated differently, what Sugar /is/ and what Sugar /is about/) are by no means mutually exclusive. If any one of us thought that Sugar was nothing more than a different way to draw some stuff on a screen, why would we bother? The Sugar interface, as with all interfaces (or, good ones), provides a means to an end; Our end is learning. icons and decorations on the screen, starts and stops programs, and lets you turn control knobs. The things Sugar competes with aren't learning platforms, they're user interfaces, like Gnome or Hildon. That really depends on who's judging the competition, or perhaps, who's even holding one. I don't much care to compete with Gnome. - Eben John ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
On Wed, Oct 8, 2008 at 2:11 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Tue, Oct 07, 2008 at 06:14:16PM +0200, Marco Pesenti Gritti wrote: On Mon, Oct 6, 2008 at 6:33 PM, Erik Garrison [EMAIL PROTECTED] wrote: In my mind the fundamental problem is that users aren't required to fully qualify names for their work. Doing so seems to lie outside of one of the core points of Sugar's design (There are no files, folders, or applications. -- http://sugarlabs.org/go/Main_Page). Is it conceivable that we could change this feature of the system in future releases to clarify data management on Sugar-running XOs? You keep repeating this and it makes no sense. As Eben said we need to encourage people to tag and name things. Saying that it's outside the Sugar philosophy is nonsense. I read there are no files ... to mean that requiring a user to name something before storing it for later retrieval is outside Sugar design philosophy. I don't think this statement is meant as literally as you interpret it. Obviously the system is full of files, and you're correct that a named chunk of data is basically what were talking about. The intent of the no files sentiment is that kids needn't (necessarily) think about named chunks of data. Instead, a child might make [this thing], and then choose to give it [some name]; naming is a natural process that applies to objects in the real world, too. Named chunk of data is pretty much the definition of a computer file. So if we're asking users to name their chunks of data to address a usability problem, aren't we just asking them to engage in file management? Can we do this and still abide by the no files principle? We want the kids to make stuff. Call each thing they make an object; call it a thing; call it whatever you'd like. We just didn't want to force the definition of the term file on them, since this term really stems from the early days of computing in which files were predominantly text. The natural metaphor was files and folders. In Sugar, we want to focus on creation of all sorts of things, and ascribing the term file to [this song I composed] or [this image I drew] seems limiting. - Eben Erik ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] naming, was Re: notes from the field - Mongolia
On Wed, Oct 8, 2008 at 4:32 PM, Yamandu Ploskonka [EMAIL PROTECTED] wrote: snip Obviously the system is full of files, and you're correct that a named chunk of data is basically what were talking about. The intent of the no files sentiment is that kids needn't (necessarily) think about named chunks of data. Instead, a child might make [this thing], and then choose to give it [some name]; naming is a natural process that applies to objects in the real world, too. My pet peeve regarding this is that the process of naming is still uncomfortable, and doesn't show on the desktop Agreed. Look at y'all! You were happilly discussing naming under the moniker of notes from the field - Mongolia, even though it would have been so simple to set it to a more intuitive name for the discussion on hand. Now, under Sugar you have to go to the Activity tab (1 step), then set a 'name' there (second step). Even then the name you assigned will not even show up in the desktop view or to the neighborhood, only in the Journal. The multistep process is something I very much want to avoid, if possible. Encouraging naming when an activity is stopped for the first time is a big step in that direction. Providing really good default names even when we do encourage custom names will also be helpful. The fact that name changes aren't immediately reflected in each of a) the Journal b) the neighborhood view c) a shared instance of the activity d) the activity palette in the Frame e) anywhere else appropriate is a bug (well, lots of bugs). (I didn't check to see which of these do update, by the way...some of these might work.) I also didn't have a chance to dig up tickets on these issues. If anyone knows that they do or don't exist, please link them or create them as needed! That is, you have 3-4 'Write' activities that you are doing at once, you have to open each one to figure out which one is the one you want at a given moment. Yeah, I agree with you. This is no fun, nor is it the intention. Microsoft Word had something that compared looks as a genius feature, that would set as default (editable) name for the .doc document the first few words of the document, which usually is its title. This type of naming is up to the activity authors to provide, since doing something that makes sense depends on the context of the activity. That said, you're right that we could probably do better in many of them. Opening tickets for specific activities would be quite helpful! Write is a good example. Also, by default DOS would add a number when something repeated a name already in the folder, thus at least we would have 'Write Activity 1', different from 'Write Activity 2'. This, and the better default naming you mentioned above, has been planned for a while, but hasn't been built yet. See http://dev.laptop.org/ticket/3900 and http://dev.laptop.org/ticket/3225 for background. Thanks for the feedback! Keep this discussion going so we don't miss any wrinkles that need to be ironed out. I hope that this naming problem (lack of naming, lack of tagging, laborious naming process, poor default names, buggy name updates, etc.) can be nearly if not completely cleared up in the next major release. - Eben Could we have some of that, please? and be able to see the name of an Activity at least when the mouse hovers, if not even better right there under the icon? Yes, usabilitity criteria should be more important than the minimalist look, which is a rather empty artistic statement rather than a practical, useful design decision. Since we're at it, let also be plainly visible with a plain old number which is which of the 3 circles that represent the mesh networks. That would save some useless hovering around when several kids are trying to get on the same one. We want the kids to make stuff. Call each thing they make an object; call it a thing; call it whatever you'd like. We just didn't want to force the definition of the term file on them, since this term really stems from the early days of computing in which files were predominantly text. The natural metaphor was files and folders. In Sugar, we want to focus on creation of all sorts of things, and ascribing the term file to [this song I composed] or [this image I drew] seems limiting When translating file to Aymara the word chosen was 'khepi', which usually means the wrapped up parcel, with a piece of cloth, that you can see in pictures of Andean people carrying all sorts of stuff, even their own babies, thus semantically translated as 'a wrap of stuff to carry or store'. It doesn't matter what it is, when put together to safekeep or move, it is a 'khepi'. Big discussion came up for folder, but that's another story. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list
Re: [sugar] naming
On Wed, Oct 8, 2008 at 6:06 PM, Yamandu Ploskonka [EMAIL PROTECTED] wrote: snip I hope that this naming problem (lack of naming, lack of tagging, laborious naming process, poor default names, buggy name updates, etc.) can be nearly if not completely cleared up in the next major release. - Eben I appreciate your agreement as to easier to use alternatives. I am afraid that part (or the origin?) of the naming/tagging problem is philosophical / ideological / aesthetic. There is a major current of icons only confectioners :-), folks who believe the typical user is illiterate, that cannot read text accompanying the icons, i.e pre-schoolers. Or they suppose localization will be easier, as icons don't need translation? Or is it just the look of the thing overriding its use? To clarify my position on the matter, several considerations did factor into the current approach. The text was kept secondary mostly due to lack of space on the screen, and only in small part because we thought (really young) kids might react better to less text, at first. Pushing the text into the palettes allowed us to make both the icons and the text bigger, which we thought was important, both so the icons could be read more easily and so the clickable areas were easier to hit, especially with the imprecise touchpad. I don't expect all kids using Sugar to be illiterate, and more importantly, I sincerely hope that Sugar will actually aid in teaching children the associations between word and image. It was very important to me that we didn't simply abandon the text altogether; Connecting the text to each object/button/whatever provided a way to keep the interface light, while providing the additional context when needed. Localization certainly isn't any less needed in this modality, as the strings still exist, but it does certainly minimize the impact that localization inflicts upon the layout. Some languages have substantially longer strings for various words and phrases, which can pose difficulty on a screen with space constraints. Additionally, some layouts are affected by this much more than others. In the activities, many of the buttons are self evident, or become so after trying them out once (we encourage exploration, and aim to make it easy by also making it just as easy to undo something). Additionally, most standard applications I know don't show text with buttons in the UI (though the menu system is a different story), and instead depend on tool-tips to reveal what they do upon hover, much like our palettes. In views such as the Neighborhood, of course, you have a valid point. The search field is a partial solution, but we also aim to provide list views in places like the neighborhood, which will reveal both icon and text, ordered and perhaps even sortable, so that finding things can be approached more directly. Then there's those of us who believe in usability and shout fertilizer to cutesy-pooh post-modern fashion statements that block actual results. (oh my, I will be tagged for flaming...) He heh. I hope my explanations make you consider the approach as slightly more valid than just cutesy-pooh, even if you still disagree with it. Anyway, another one: a NEED (yes, I mean to shout it) is that 'file' names or whatever you call them BY DEFAULT carry the author / child / machine ID, so that when that file ends up in the teacher's machine, he can figure out which one of the 35 'Write Activity' that were submitted is Roberto's. Yes, I think making this part of the Sugar default naming scheme makes prefect sense, and also humanizes it a bit more. Eben's Painting 1 sounds much better than Untitled 1, even if Painting of my House might be more appropriate. The tickets I linked to before include this in description of the default name. Additionally, metadata is something that's still being perfected in Sugar, but all activities actually store their author (and, actually, all participants) in metadata, so it should be possible to see who worked on what even without having it in the name. I think some work needs to be done to properly retain and/or expose this type of information. Now, this is one of the serious, serious missing links when it comes to using the XOs for actual schoolwork. Teachers assign homework. Kids do it. In a contemporary-ideal setup :-( these pieces of work are sent to the teacher for evaluation. This has maybe a 50-50 chance of working if the teacher can follow up and figure who's who. Otherwise, it will never fly. (oh yes, the /untrained/ teacher could train kids to name and tag files) Yes yes, in an _ideal_ world teachers do not evaluate schoolwork... I think evaluation is good, but perhaps not in the A,B,C,D scale. Reflection on work, and discussion of progress, is certainly part of learning. I wrote up some thoughts about how we might begin providing better structure for giving and submitting assignments in another recent thread on narrative.
Re: [sugar] adding versions to journal/datastore
On Wed, Oct 8, 2008 at 9:04 PM, Christopher Sawtell [EMAIL PROTECTED] wrote: I am new around here did not realise that the list server doesn't munge the addresses, my apologies. Anyway, I responded to Mikus thus:- I agree the 'effort' is theoretically trivial, what versioning provides is a new version number without the need to _remember_ that one has to create a new file name for the new version, and that, for many people, is far from trivial. Remember that in times of yore - pre 1981 - versioning was a standard feature offered by many O/Ss. These days the need for versioning has become somewhat nebulous because the various source code control systems allow one to check in and out, and to see the differences very simply. Whether or not children should have to deal with that level of complexity in order to be able to 'undo' the latest, erroneous, changes to their current 'magnum opus' is, I suppose, open to debate. We certainly don't plan on exposing them to that, unless they absolutely want it. Instead, the model will simply be along the lines of I messed up this picture, but it looked good yesterday before I scribbled on it. Let me scroll back in time through the Journal to yesterday's entry, when it still looked OK, and resume that. Previews and dates should assist the process of rediscovering old versions. Another potential option is to build versioning support into the undo/redo buttons of an activity, such that it's possible to skip back through old entries by undoing. This idea, of course, has its share of intricacies to figure out, but it could be a powerful system. - Eben -- Sincerely etc. Christopher Sawtell ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
On Mon, Oct 6, 2008 at 8:27 PM, Hal Murray [EMAIL PROTECTED] wrote: Here we come against initial expectations. The whole concept of Sugar is that the user doesn't need to explicitly save files. They are automatically kept in the Sugar datastore, and are accessed through the Journal interface. [In other words: Don't use the traditional hierarchy of directories to locate the saved file -- instead do characterize the object with a description, and use an intelligent search to locate it.] Is there a wiki page that describes things like this? I'm looking for something primarily aimed at people who are already familiar with computers and probably have many inappropriate initial expectations. This is the document I wrote up when work on Sugar began. It's a little out of date, unfortunately, but it was designed specifically to address the target audience who has familiarity with traditional systems. Since, when I wrote this, G1G1 wasn't even an idea yet, it was put in a place specifically for developers; I'm not sure how much of this has emanated through the rest of the wiki. http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience I hope you enjoy it; you feedback would be quite welcome, as it's very much in need of a refresh soon. (And has been for a year...sigh) - Eben -- These are my opinions, not necessarily my employer's. I hate spam. ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Narrative
On Sun, Oct 5, 2008 at 4:29 AM, Bryan Berry [EMAIL PROTECTED] wrote: On Sun, 2008-10-05 at 02:25 -0400, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bryan Berry wrote: | There is something I would like to add. Folks from rich countries (like | myself) underestimate the importance of narratives b/c we are surrounded | by libraries, online tutorials in our native language, extensive | versions of wikipedia in our language, etc. There's a real drought of | narratives for poor countries. I don't know what you mean by narrative. If I were to pick a word to describe libraries, online tutorials, wikipedia, and other similar resources, I would choose information. I go to wikipedia to learn facts, not stories. I basically mean structured information put into a structure by a human(s) intended to best build up concepts. I agree that providing information is good and important for education. I don't see how OLPC or Sugar lacks tools to provide information. Including a digital textbook into a Sugar build for XO is extremely easy. ~ We simply don't have the textbooks. The problem, in this case, seems much more like a lack of content and translators. That effort is important and worthwhile, but seems quite independent of Sugar. I agree on this. I don't see how narratives fit into Sugar. Michael Stone has some interesting ideas on this though. I think that Sugar should focus on collaboration and discovery and tools like Moodle can provide the narrative. Actually, while I may be arguing a point that you might not have been explicitly making, I think there are a few key ways in which we *can* embed a better narrative into Sugar, and I think they will be very powerful. JOURNAL This first of these is the Journal. As Walter has mentioned a few times, the Journal is meant to provide at once a container for all of one's things, as well as a space for reflection upon those things and the actions taken upon them. Right now, all we have is a container. The rest hasn't yet been built. The vision for the Journal includes a view of a child's things which includes context such as when and with whom a given thing was created, who gave it to me, where I downloaded it from, who I gave it to, etc. It should also provide information about events which didn't necessarily produce a tangible thing (file), such as joining a group, making a friend, changing the XO colors, etc. This view will provide all of this context, as well as inline previews of files, in essence creating a true Journal of the actions a child has taken and the objects they've made or interacted with over time. I think this will provide a rich narrative space which is perfect also for reflection. Once we have a backup system in place, as well as a system for cleaning out older and less relevant entries, it will become more of a portfolio than a list of every file ever made, holding on to the items which have been starred, used the most, or otherwise considered important in the history of the child's interaction with the XO, further emphasizing the Journal as a place for reflection. Finally, if we can ever get a reasonable tagging system off the ground, it will be possible to categorize the giant stream that represents the entire Journal into streams for various projects and purposes. By filtering the contents to a specific tag -- say, My final science project, it will be possible to narrow in on a series of actions, or a group of objects, or both, which exist within a particular narrative stream. BULLETIN BOARD (activity) Myriad concepts for the elusive bulletin board have been tossed around since before Sugar existed. These days, we have a revised view which we think, finally, fits the primary need. As an activity, the bulletin board fits nicely within the activity paradigm already setup, allowing kids to create as many of them as they choose, allowing them to retain them in their Journals, and allowing them to share them with their friends, with groups, or with everyone as a public bulletin board. The bulletin board, as envisioned, provides a space for sharing things. A child could post photos she took, or a song she composed, or a story she wrote. Others could then look at, or download, these shared objects. Others, likewise, could also post to the bulletin board, to create a multidirectional sharing space. There are some technical details to work out of course; it's not exactly clear how these posted objects (which are clearly just references to objects hosted by the poster, or perhaps by a server, or perhaps by other who have since downloaded them) get resolved such that I might download one on request. I'm sure we can do something intelligent. Another potential feature for the bulletin board comes in two flavors: notes, and comments. Bulletin boards are often a space for posting messages, as well as objects. Support for this could be built-in, so that it's not necessary to first
Re: [sugar] adding versions to journal/datastore
On Thu, Oct 2, 2008 at 12:57 PM, Walter Bender [EMAIL PROTECTED] wrote: 1 - The primary requirement for the Journal is to never lose data. I Say what? Maybe one could argue that this is the primary requirement for the datastore, but the Journal is there primarily as a place of reflection. The fact that the datastore has been problematic and that the Journal is so underdeveloped relative to our goals may account for the fact that feedback from the field has been so narrow. ++ -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] another response time
Yeah, this sounds like something that should be added to the HIG. Activities should strive to put up a screen as soon as they can, even if it will take more time to fully present the UI or the content. I opened #8739 to keep track of this, when I get a chance to get back into the HIG. - Eben On Wed, Oct 1, 2008 at 8:49 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: as you probably installed previously the Wikipedia activity, my guess is that the jffs2 gc thread was taking most of the CPU. If I understand correctly, this raises the possibility that other actions performed *prior* to the launching of an Activity can noticeably affect the time it takes to launch that Activity. Would someone else please launch XaoS, and see what kind of response time for the launch they get? Tried it again, after the XO had sat there overnight (having now hopefully done everything it needed to, for jffs2 housekeeping). For me, the launch screen for XaoS pulsed for 100 seconds before the activity screen was drawn. [My guess is that it is calculating the fractal picture before showing it.] mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] another response time
On Wed, Oct 1, 2008 at 2:15 PM, Gary C Martin [EMAIL PROTECTED] wrote: On 1 Oct 2008, at 13:49, Mikus Grinbergs wrote: as you probably installed previously the Wikipedia activity, my guess is that the jffs2 gc thread was taking most of the CPU. If I understand correctly, this raises the possibility that other actions performed *prior* to the launching of an Activity can noticeably affect the time it takes to launch that Activity. Would someone else please launch XaoS, and see what kind of response time for the launch they get? Tried it again, after the XO had sat there overnight (having now hopefully done everything it needed to, for jffs2 housekeeping). For me, the launch screen for XaoS pulsed for 100 seconds before the activity screen was drawn. [My guess is that it is calculating the fractal picture before showing it.] Hi Mikus, XaoS on my XO B4, launches instantly. No seriously, it's absolutely the fastest launching activity. Here's the rub, because its so quick, it even beats the launcher window getting going, the working activity is hidden behind the launcher pulse effect window, which now can't tell that the activity is actually already running so does its blind 'I'll sit here and strobe for a fixed time-out because I have no idea what happened.' Yes, ticket please! =) Thanks for the report. Take a look in the frame and you'll see the default grey circle that you can switch to. Worth a ticket if there's not one already, it's an interesting case in how quick XO-1 HW really is with the right software (must be and absolutely massive price being paid currently for having the Pyhton environment I'd guess, but I'm sure there is a whole heap of optimisation to be made if/when made a dev cycle focus and team resources made available). Made some great strides for 8.2, fingers crossed for 9.1. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Mon, Sep 29, 2008 at 3:54 PM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Hi Eben and other sugarites, I'm trying to find a simple way to add some version support to the journal, but for that I need to know what's the sweetest spot (no pun intended) between value and complexity. I'm thinking about making the next notable changes to the UI: - the journal list shows one line per interesting entry. Interesting entries are tips of branches and a branch is created every time the user clicks the Keep button or resumes an entry. Activities can also choose to make a branch in behalf of the user at any moment, for example just before the user selects Erase all in Paint, I'm want to become a bit clearer with your terminology, because I'm not sure that branches line up in my mind. I agree that we could/should have a number of incremental saves which are created within a given activity session. The latest of these would be promoted to a new interesting entry should the activity crash, or the machine restart, etc. I agree that upon closing an activity session, or pressing the keep button, a new interesting entry is created, also. I'm unsure, however, that each of these entries represents the tip of a branch, or that only the tip should be shown. Should a branch only be created when the user duplicates an entry or keeps a copy? A branch would certainly be created when resuming an old entry (not the tip/top entry), but would you branch when the top entry itself is resumed? Also, to clarify, in your vision would resuming a given activity instance (always from the tip, let's assume) several times result in a new interesting entry for each, or would you collapse it into a single entry unless a branch is made? While this results in fewer entries in the Journal, it defeats the idea of the Journal as a historical record of versions, instead making it a flat folder sorted by modification date. - in the detailed view of an entry, all its ancestors are displayed in a list, including non-interesting entries, The latest designs actually include a popup menu in place of the date, which allows one to select versions of the document by date without exposing the whole list permanently in the view. Ideally, this list would include icons which indicate those which have been starred, so that digging through a potentially long history is easier to manage. Walter, could you elaborate on your comment? - Eben - and that's it ;) Eben: is that too simple? If it's enough, I'll propose an API for it. Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] adding versions to journal/datastore
On Wed, Oct 1, 2008 at 3:49 PM, Walter Bender [EMAIL PROTECTED] wrote: Walter, could you elaborate on your comment? My comment was in regard to the anticipated additional complexity we may run into if/when we have versioning between multiple users, as would be dictated by most of the bulletin board schemes. Not sure if Tomeu's model will work, but it doesn't seem a bad first step. I see. I think we partially circumvent the complexities by restricting the notion of versions to, in the end, a flattened tree. That is, the user isn't concerned with the details of branching structure. Instead, the most recent version (from any branch) I've resumed is the one that sits at the top of my Journal. This is consistent with the Journal as a time-based structure, because the tip of that new branch I created was created last in the timeline. When you have several kids, potentially with different versions of the same activity, they can all get back together, do manual merges, and then continue work in whichever instance they choose. When they all stop working on that implicitly agreed upon true version, that then becomes the tip, and the latest entry for all of them in the Journal. This model does, of course, eliminate (at least with the current UI proposal) potential advantages of a truly hierarchical versioning scheme, but I think it simplifies specifically to the point you raised earlier, which is that the last thing I did will be the most important thing to me. - Eben PS. The one place this causes problems is when you go back to an old version, rename it with the intent to use it as a base for a completely different project, and then work from there. In this case, you really want to have a new root node, instead of a new version. We should discuss the implications here, and if we might want to create a copy (a new root node that contains the contents of the copied node) on rename. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison [EMAIL PROTECTED] wrote: Hello all, On tabbing we are currently auto-toggling the frame. Are we sure that this is necessary? Could we include a configuration option to change this? I disagree that showing the Frame is a bad idea. It emphasizes the purpose of the top edge of the Frame, and provides context while tabbing so that it's easy to see where you want to get to. Drawing the frame animation during tabbing robs us of processor right when we need it, slowing the perceived transition time between windows. Drawing the Frame does take a little effort, it's true. Compositing support should later speed this up a good deal. The current reveal/retraction rate of the Frame is at least 2x as slow as I'd like it to be, in practice. Additionally, there *is* a lag on switching windows, and this is, actually, part of the reason that I think the Frame should be shown. Without the Frame, we are forced to expose each window in the tabbing process, which injects delays into each tabbing event. With the Frame shown, we delay the actual window switch slightly so that it's possible to tab quickly past a few activities you're not interested in, pausing only at those that you want to see in more detail. Furthermore, as the XO only has one processor the frame animation (which requires available processor to run smoothly) will skip a lot of frames if the processor is loaded. As we're auto-saving and re-rendering the windows of every window we pass during tabbing, the processor is Saving and re-rendering...could you elaborate? As I mentioned, the point of using the Frame is to *minimize* the number of context switches that need to happen. - Eben invariably quite loaded, and the frame draw consequently is quite clunky. The attached patch to sugar optionally disables frame appearance if the file /home/olpc/no-frame-on-tabbing exists. This is just a proof-of-concept hack to make it easier to quickly enable and disable the functionality and observe the performance change. I have created a trac ticket: http://dev.laptop.org/ticket/8633 Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On Wed, Sep 24, 2008 at 12:37 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 12:25:43PM -0400, Eben Eliason wrote: On Wed, Sep 24, 2008 at 12:18 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Wed, Sep 24, 2008 at 11:25:51AM -0400, Eben Eliason wrote: On Wed, Sep 24, 2008 at 10:52 AM, Erik Garrison [EMAIL PROTECTED] wrote: By saving I mean that changes in activity state trigger Activity.save(). This hits jffs2 and the NAND. Sure, as Tomeu says, we could add a dirty bit. Of course, it seems that the Frame-based solution should actually be preventing this (given a long enough delay on revealing the activity window, or not revealing until releasing alt-tab), since the activities don't even get focused at all immediately. Only those you pause or stop on should be doing any saving of state, and even then only if needed. How long of a pause or stop triggers auto-save? We could also save on user idle. Say, when the user is idle for more than 5 seconds and we haven't saved in the last 2 minutes. Or we could just auto-save every N minutes. Both of these options would decouple CPU-intensive actions from user intervention, with the effect of improved system responsiveness. We could certainly try both of these. To clarify my point above, the basic rule was to auto-save at the activity's discretion (likely when dirty and N minutes have passed, and or idle) and when switching /away/ from the activity (and also dirty). My point, basically, is that we shouldn't be giving windows focus while we're still tabbing, in which case we never leave any activity we tab past, because we never went into it. Perhaps we can acheive the same effect without the Frame, but I'm not sure. The only activity which should do any saving during a tabbing operation, really, is the one we left when starting it. - Eben Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Tagged Journal Proposal
I'm paying attention to this thread, quietly. I like a lot of this. :) I'll let it continue without interfering, for now, but I wanted to point out that the new toolbar design (posted on the wiki) would make that more actions option much nicer. For that matter, as Eduardo mentions, they don't mean anything until you make a selection, so we could reveal them in a toolbar only then, perhaps. - Eben On Tue, Sep 23, 2008 at 6:20 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: I also imagine that the Extra options menu would appear in the main toolbar in the Detailed view. And aditionally, like in one of eben's mockup, once a entry is checked in this list view, either the main toolbar changes to provide contextual actions (those you placed in that menu, copy, apply label, etc.), or a new menu appears bellow the main one with these options, so as not too loose the searching/filtering features which can be handy to have for various journal entries and still have handy the search and filtering features. Eduardo 2008/9/23 [EMAIL PROTECTED]: c. scott ananian wrote: On Tue, Sep 23, 2008 at 5:57 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ah, so that's why you separate these legacy-hierarchical files with a light grey slash (/) . So that a kid who only knows the Journal tagging world can ignore it, and users who have know the hierarchical world can understand it and make advance usage of that knowledge when transfering from or browsing hierarchical filesystems. Exactly. =) seems like acknowledging the path form of these directory-derived tags might also make working with devices for which no tag list has been, or can be, created. i.e., when you first install a large new USB stick, there will certainly be a delay before a tag index can or will be built. the grey slashes might be black during that time. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame gets in the way when alt-tabbing
On Mon, Sep 22, 2008 at 3:14 PM, Erik Garrison [EMAIL PROTECTED] wrote: On Mon, Sep 15, 2008 at 12:59:52AM -0400, Mikus Grinbergs wrote: 760. Running (on my XO) a ported Linux application which puts up multiple screens. As far as I could tell. I was able to access all of those screens by using the alt-tab procedure. But while doing this the Frame was unacceptably intrusive. For instance, I could not see the titles on the top line, which identified each screen. If I rapidly pressed alt-tab and released -- the XO would not bother to switch screens. If I slowly pressed alt, then tab - the XO would bring up the Frame. I would need to release and press tab another time to get the XO to switch to the next screen (while still showing the Frame). I would need to release alt to get the XO to stop overlaying the screen edges with the Frame. [And it seemed to me that sometimes the Frame would not go away even then - I would have to press and release the Frame key to ensure that it was gone for good.] One of the first things I did upon getting my G1G1 was to go into one of the .py files and __NOOP__ the autoraising of the Frame. That gave me Sugar screen behavior that was under *my* control. Now, Sugar has again started to interfere with what I am doing -- by raising the Frame when I alt-tab. I HATE THAT! I HATE THAT! I thought the idea was to have the human in control of the computer, instead of the computer dictating what the human may see. I would like the Frame function in the Control Panel to allow me to optionally disable the automatic showing of the Frame upon alt-tab. [Let *me* decide when I want to see the Frame !] In the meantime, I guess I will have to go back to modifying the .py files in Sugar - to reclaim Sugar screen behavior that does not interfere with my use of the computer. I think the idea is to use the frame to show you which windows you can alt+tab between, such as is done in Gnome or other WMs. This is, in my opinion, quite useful. However, I am unsure of the utility of clumsily animating the transition of the frame into view, or the lack of configurability of this option. So perhaps the best thing to do is to add a configuration option to allow the user to enable or disable this behavior? Would it be better if the frame was quickly displayed instead of sliding into view? Maybe generally we need a configuration option to turn on and off fancy animations to improve system responsiveness? Perhaps in the short term a boolean (exposed or not...I'd lean toward not) would suit. The big isue is lack of composition support. The Frame currently slides in about 1/2 as fast as I'd like it to, and choppily at that. With composition we could get smooth motion and also speed it up significantly. (The only reason it's so slow now, I believe, is because without composition we can't draw frames fast enough to convey the motion unless we increase the length of the reveal.) - Eben Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Second pass in the 0.84 goals
Mikus - You should check out the very recent thread entitled Ideas for Journal: How Epiphany..., because we're discussing just the type of things you bring up here. On Sat, Sep 20, 2008 at 9:54 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: The current plan is to land a rewrite of the datastore early in the release cycle, using the same API and the same user interface. That will mostly help reliability and performance but it's also a prerequisite for the new design and likely for any journal UI improvement. It might or might not support versions. What is not defined is which new features we should aim to develop on the top of the new datastore in the 0.84 release cycle. The Journal concept promised to replace traditional 'hierarchical' access with 'intelligently filtered' data access. But the existing 'filters' available in Journal are pathetic. DESPERATELY needed are There should also be a filter for who you worked with, which hasn't been added for technical reasons I don't fully understand. However, the new back end mentioned should, I believe, make that possible. sorting of displayed entries, Yes, this is something that's been in the designs since early on, but we haven't had time to do yet. We even considered the more advanced concept of sort by, then by, then by.. to allow pseudo-hierarchical structure to emerge. filtering on 'tags', I'm pretty confident that this should work at present. If it doesn't, please open a new ticket for us! There was another recent (as of today) ticket that noted searches don't work correctly on metadata fields (perhaps that's what you meant?), which is definitely a bug we need to fix. There's also a related bug that prevents custom metadata from being preserved across reboots. That's pretty fundamental. I really hope we iron out the tagging and metadata system and search for the next release (even if we don't get to all the fancy stuff being discussed in the other thread, yet), but there's a lot of work to be done there. and stacking of search terms (i.e., to provide the equivalent of search within previous result). This should also work fine, I think. Terms are combined with boolean AND so by typing additional words into the search you should continually narrow your results. If we ever get a tokenized (treating completed words which match on existing tags as single, tokenized, objects in the search field) system, it would be easy to then go back up levels, or remove a level, by deleting specific tokens. Thanks for your feedback; I encourage you to check out the other discussion I mentioned! - Eben mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
On Fri, Sep 19, 2008 at 3:59 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: 2008/9/19 C. Scott Ananian [EMAIL PROTECTED]: On Fri, Sep 19, 2008 at 2:31 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ideas for Journal: How epiphany browser manages bookmarks just with tags (and does it nicely, with potential of improving of course). I made a screenshot slide-show of how tagging and the dynamic bookmarks menu based solely on tags work in Gnome's Epiphany browser. I hope this can be usefull to gather ideas for how the tagging system in the Journal could work. This could also be helpful if tagging in the future can be done within activities, so that they are easily, and thus more often, used. I show how in Epiphany: tags are searched; tags are suggested; pre-existing and new tags are added; tags are presented; and how tagged bookmarks are organized in a menu. The size is a bit big because of all the screenshots, it's 46.7 MB . C_scott uploaded it for me, at http://dev.laptop.org/~cscott/eduardo-epiphany-tags.pdf Eduardo Eben, Eduardo, and I have been chatting about this some over IRC. What I find most interesting here is how *filesystem paths* (well, URL paths in this particular case) are integrated with tags. For example, when you type 'fsf', both 'http://fsf.org/' and other things tagged with 'fsf' show up. This ties in with one of my frustrations with google's tag system: I have olpc, olpc-fedora, olpc-sugar, olpc-sugarlabs, etc tags in google, when what I really want is 'olpc/fedora', 'olpc/sugar', etc. Sometimes I want to see all olpc-related mail, sometimes only sugar-related olpc mail, etc. If you accept that tags can sometimes be ordered, so that a/b is different than b/a (although both will show up on searches for 'a' and 'b'), then this starts looking more and more like a way to view filesystems as well, for those old enough to want to do that. I don't follow this. Thinking in Journal terms, where currently the only access is through the search box, you could search for olpc sugarlabs to see your olpc-sugar e-mails, or olpc to see all which fit under olpc, i.e. olpc-fedora+olpc-sugarlabs+olpc-sugar. A search which doesn't work if you follow the containerization way of directories, would be if you searched just for sugarlabs . This would give you olpc-sugarlabs results, but also would find sugarlabs tagged entries which didn't belong to the olpc- root (like a logo of Sugarlabs, or some document about it). To go back to the way Gmail works, or should work, would be having the ability to assign multiple tags to each label, i.e., make them be virtual folders. So in your case you would have one which showed results with tags olpc, sugar, another olpc, fedora, and olpc, sugar, and olpc, sugarlabs. Then you could still have one just with tag olpc which would show all of the above, or you could just search for olpc tagged entries giving all of the above as well. So I agree that some kind of containerization is needed, but not in the form of a/b being different than b/a, but by using virtual folders or saved searches which would effectively act as virtual folders, with specific tags, search terms, object types, even a period of time if you wished. I don't mean to belittle the utility of virtual folders (I think they're quite powerful), but you can also get a close approximation to them by applying a sufficiently unique tag to a group of items as well. In fact, a basic implementation of such a feature could do exactly that, requesting a name for the virtual folder and then tagging the selected items with vf:Name of virtual folder (or something similar, but you get the idea). The real question (I didn't overlook this!) regarding the concept of virtual folders (or, more specifically, saved searches) is whether or not they are dynamic. That is, does the saved search represent an expression or a value? My above tag idea is only valid, of course, when they are represented in value form. For more power (but more complexity) one would store the search terms, filters, etc. and re-apply them on the fly to a growing list. I'm not sure which of these is more desired. They both have merits. (Debian has had for some time debtags, which are a more advanced method of tagging objects originally developed for libraries, but I think is too formal for kids, since it would need for them to learn a new classification system to categorize their library of objects.) If you have files in ~/Journal/Music/Bach/Disc1 and ~/Journal/Music/Beethoven/Disc1, you can search for 'Bach', 'Music Bach' as well as 'Bach/Disc1' or 'Music/Bach/Disc1' if you want to be specific. When you insert a USB key with files in a directory called 'Music/Mozart', they appear in the journal as if they were tagged 'Music/Mozart' and you can search for 'Mozart' or 'Music' to find them. When I copy them to my XO, the tags come with, and I have operations to retag groups of
[sugar] Design Meeting REMINDER (Thursday September 18, 2008 @ 15.30 UTC) --- irc.freenode.net, #sugar-meeting
Today will mark the first biweekly design meeting on IRC. I hope to see you there. Topics: * Visual clipboard API * Advancing the Journal * Thoughts on some icons - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Design Meeting MINUTES (Thursday September 18, 2008 @ 15.30 UTC)
Our first design meeting was a bit more technical than anticipated, but we did make some progress. Minutes can be found here: http://sugarlabs.org/go/DesignTeam/Meetings#Thursday_September_18.2C_2008_-_15.30_.28UTC.29 Thanks to all that participated! - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Announcing biweekly design meetings
To the designing and implementing masses: I'm happy to announce that, beginning this week, I will begin hosting a biweekly open design meeting on IRC. Though targeted at the core sugar team and activity developers, all interested are more than welcome to attend. We will focus on high level design discussion and planning, feedback and analysis of current designs (both successes and failures), and occasional reviews of new visual design proposals. * Biweekly, 1st and 3rd Thursdays * 15.30 UTC [1] * irc.freenode.net, #sugar-meeting For more information, and to preview or suggest agenda items, please see http://sugarlabs.org/go/DesignTeam/Meetings. - Eben [1] Convert UTC to your local time: http://www.timeanddate.com/worldclock/converter.html?hour=11min=30sec=0p1=0p2=43 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] #7685 NORM 9.1.0: Alternate home layouts; fixed ring scaling; better modularization of layouts
I want to initiate some discussion on a similar topic to the one you
bring up here, regarding the extensibility of the layouts. What I'd
like to see is layout modules which provide translation from a set of
input coordinates to a set of output coordinates (eg,
_calculate_position), which are then fed to a smooth positioning
algorithm, making it possible to transition cleanly between layouts,
and to rearrange layouts via drag'n'drop.
Let me illustrate what I mean by way of an example. Consider the Ring
view you bring up. If we define our translation function to calculate
a radius based on the number of elements in the list, and then
calculate the radial ordering of the elements by calculating the angle
between the center of the ring and their input coordinates
(atan2(y,x)), we can then equally space them around a ring spatially
relative to their initial locations. The beauty of this idea is that
we get drag'n'drop reordering for free. If, every time new
coordinates are calculated, we animate the icons to their new target
positions, we can simply drop an icon anywhere we choose on the screen
and it will neatly slide into the nearest spot in the ring.
Of course, the translation function could do anything. It could force
things onto a grid, into a sunflower, into non-overlapping positions,
etc. All of these types of layouts require merely the list of
coordinates (since we assume equal size elements) as input.
We can make things more interesting, however, by offering further
information, both as input and output. If we define an object which
represents an element in the layout, giving it size, position,
orientation, name, tags, and other metadata, (all of these mutable by
the translation function) it's possible to create layouts that perform
logical grouping, create sortings (even in multiple dimensions),
filter the input, etc. The visualization space is much greater (and
think of how much fun it could be to create new layouts like this for
visualizing the neighborhood view.)
- Eben
PS. You could raise UnimplementedException, or you could simply
define the identity function in the base class.
On Thu, Sep 11, 2008 at 3:07 AM, Zarro Boogs per Child
[EMAIL PROTECTED] wrote:
#7685: Alternate home layouts; fixed ring scaling; better modularization of
layouts
-+--
Reporter: cscott | Owner: marco
Type: defect | Status: new
Priority: normal | Milestone: 9.1.0
Component: sugar | Version: not specified
Resolution: |Keywords: r?
Next_action: never set |Verified: 0
Blockedby: |Blocking:
-+--
Comment(by mtd):
I like the (sugar) patch (it's moved to
http://dev.laptop.org/git?p=users/cscott/sugar;a=summary ), especially the
modularization parts. Comments on the patch are 1) there are a few times
we do y = m*x+b instead of y = m * x + b that'd be nice to tidy up;
and 2) I wish the RingLayout class's name could better express that it
is suitable as a superclass to {Box,Triangle,Sunflower}Layout - perhaps
RingLayout should be renamed BaseLayout and its _calculate_position()
function should raise UnimplementedException, and then a new RingLayout
defined, which implements that function as the current RingLayout does.
If it were up to me it'd be r+ with those comments. I don't know when it
should land, though.
--
Ticket URL: http://dev.laptop.org/ticket/7685#comment:7
One Laptop Per Child http://laptop.org/
OLPC bug tracking system
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Freeform layout algorithm
To all interested: I've uploaded a working demo of the algorithm, with source code: http://interdimensionmedia.com/scratch/placer/ The instructions are listed beneath the applet (sorry, Java required...); you'll have to click on the applet to focus it for keyboard input. You're also welcome to modify the source in any way and post new versions of the demo representing new algorithms. You'll need to download Processing (http://processing.org), an environment built on top of Java for programming 2D and 3D visualizations, in order to modify the demo. I look forward to comments on the behavior of the current algorithm, and faster and/or more accurate algorithms as well! - Eben On Tue, Sep 9, 2008 at 4:42 PM, Eben Eliason [EMAIL PROTECTED] wrote: Renewed interest in improving the layout algorithm (for use in the non-activity zoom levels) has prompted me to create a document summarizing the goals of the layout, the current approach, and a few alternate approaches for consideration. My primary goal was to specify the requirements we wish to evaluate the possible approaches against, and to clarify my (potentially naive) first attempt at satisfying them. My hope is that others will see obvious ways to improve the current approach, or have much better solutions they can put forward (preferably in code!). Please see the attached document for details. Thanks! - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Freeform layout algorithm
Indeed. There are many good layouts for Home view. (And I want to encourage more!) In the interest of keeping the topic clear though, I want to make sure that this thread focuses on a particular and more general layout problem, rather than becoming a long list of alternative layouts. In other words, I'm interested in algorithms for this particular layout, and not in alternative layouts (since placement with minimal overlapping is something we face in all views, and only secondarily relates to the freeform view in Home). - Eben PS. I'll probably start another thread on an Extensible layout system for Home view. I don't find the current satisfactory, so I'd like to outline my ideas for how it could work and get feedback on that as well. On Wed, Sep 10, 2008 at 5:35 PM, C. Scott Ananian [EMAIL PROTECTED] wrote: I'll just briefly mention http://dev.laptop.org/ticket/7685 (patches) which includes differently-shaped activity rings as well as a 'sunflower' layout I rather like. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Freeform layout algorithm
Renewed interest in improving the layout algorithm (for use in the non-activity zoom levels) has prompted me to create a document summarizing the goals of the layout, the current approach, and a few alternate approaches for consideration. My primary goal was to specify the requirements we wish to evaluate the possible approaches against, and to clarify my (potentially naive) first attempt at satisfying them. My hope is that others will see obvious ways to improve the current approach, or have much better solutions they can put forward (preferably in code!). Please see the attached document for details. Thanks! - Eben A SEMI-SMART LAYOUT ALGORITHM FOR FREEFORM VIEWS We desire an algorithm which optimizes the placement of a collection of elements (the set E) of various sizes (and/or weights) so as to minimize overlap while also minimizing memory usage and maximizing speed. 1 REQUIREMENTS We'll discuss the merits and limitations of proposed algorithms based upon their adherence with a general set of requirements, in addition to their memory requirements and speed. The set of requirements we hope to fulfill are: 1. Minimize overlap of elements 2. Support a suggested position for each element 3. Support a suggested radius for each element (in a polar coordinate system) 4. Support addition and removal of elements 5. Support changes in size of elements (both expansion and contraction) 6. Support fixed elements (locked in place) Other considerations include minimizing the total amount of positional change incurred by a given operation on the layout (addition, removal, scaling, etc.). Since the goal is to have a smooth layout in which elements shift (animated) into place, we hope to minimize both the number of elements that need to move and the distance they need to move for any given operation. 2 THE CURRENT ALGORITHM The algorithm currently proposed (although it differs in several key ways from that currently implemented in Sugar) makes use of a weight matrix to make optimal placements, and uses a simple collision detection scheme to handle addition, removal, and scaling of elements. 2.1 The grid The algorithm is built upon a weight matrix which tracks the placement of all elements. This matrix manifests as a 2D integer array containing values in the range [0, 255]. When visualizing the matrix, think instead of an image, where each cell represents a pixel, and the value stored at (x,y) represents the brightness of that pixel. Think of this image as a topographical map of sorts, with bright areas representing peaks and dark areas representing valleys. 2.2 Assigning weights When managing the matrix, we strive to make the weights assigned accurately represent the topology of the elements in the layout. Given an element, e, having dimensions m x n, we create an element matrix of the same dimensions within which which we assign weights to individual cells. The most correct approach (assuming no knowledge about the element other than its dimensions) is to apply weights to the cells of the element matrix in a gaussian fashion, such that the element is represented as a rounded surface, with the middle receiving the highest weight. This method is most consistent with the interpretation of the table as a topographical map, since it results in smooth gradients representing hills and valleys, with the centroid given the highest weight (collisions are worse the more they overlap). However, this approach also takes much effort, since the weight of each cell must be calculated. By extreme simplification, we could assign a constant value to each cell. This uniform approach takes no extra calculation, but results in a plateau rather than a hill, which poses problems in placement. A better solution, which takes only trivial calculation, uses a linear gradient. Using the linear model, we can visualize the element as a pyramid rather than a hill, which still maintains the important (for placement) property that there is a delta between two adjacent values. The following example illustrates a sample of the weights for a 5x5 element. Note that the three examples are not normalized (themselves, or with respect to each other). Gaussian Linear Uniform 0 1 2 1 0 1 1 1 1 1 1 1 1 1 1 1 4 6 4 1 1 2 2 2 1 1 1 1 1 1 2 6 9 6 2 1 2 3 2 1 1 1 1 1 1 1 4 6 4 1 1 2 2 2 1 1 1 1 1 1 0 1 2 1 0 1 1 1 1 1 1 1 1 1 1 Finally, we define the total weight of a given element, W_e, to be the sum over the weights of the cells of the element matrix. 2.2 Placement Placement of a new element is relatively straightforward given the weight matrix, since we can think of finding a good placement as rolling the new element into a valley - an area of low weight. We define the weight of a given placement, W_p to be the sum of the weights of the cells of the weight matrix where the element matrix overlaps. In other words, if
Re: [sugar] [PATCH] REVISED screenshots hurt
This seems like a decent, but lossy reduction. (Though I agree in full that the current behavior is far less than ideal.) There are still some ugly cases, though, which can't be fixed without compositing. Am I correct in thinking this assumes that the activity is visible while keep/close buttons or shortcuts are activated? If the user reveals the Frame and accesses these commands via the activity menu, the Frame will be in the screenshot. Moreover, they might be in another activity, or another zoom level entirely, and actually get misleading screenshots instead of none at all. Should we verify that the activity is the active one, and that the desktop is not shown, before taking an invalid screenshot? Also, when is compositing potentially coming? Is it necessary to do this for 8.2.1 if we'll have a far better solution which handles all cases in a release or two? - Eben On Fri, Sep 5, 2008 at 12:31 AM, Erik Garrison [EMAIL PROTECTED] wrote: Devs, Attached to this email are both the original patch, which removes automated screenshot acquisition from the sugar shell, and a patch to activity.py in sugar-toolkit which adds screenshot acquisition to the user-directed 'keep' (save) event, so that the screenshot can appear in the journal when the user explicitly selects to save their work. Note that the keep event previously did not acquire a screenshot-- it was apparently assumed that it would have been acquired previously by a tabbing event. Additionally, two screenshots were acquired on every close event (one in the Shell.py code and one in the activity.py code). The effect of these patches is to retain the benefits of screenshots without incurring their costs on every window navigation event. Only user-directed 'close' and 'keep' events now trigger the screenshot. This means that there will always be screenshots after activities properly exit, or when the user elects to save data. Other automated screenshot events are removed so that system responsiveness does not suffer during window manager navigation. before, screenshots taken on these events: - frame visibility - tabbing start - activity next tab - activity previous tab - zoom into activity view - activity close (twice) after, screenshots taken on these events: - activity close (once) - activity keep / save Comments welcome. Please test and report results. Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] REVISED screenshots hurt
On Fri, Sep 5, 2008 at 12:31 AM, Erik Garrison [EMAIL PROTECTED] wrote: before, screenshots taken on these events: - frame visibility - tabbing start - activity next tab - activity previous tab - zoom into activity view - activity close (twice) after, screenshots taken on these events: - activity close (once) - activity keep / save perhaps a happy medium: - activity close (once, conditional) - activity keep (conditional) - activity hide (zoom out, switch, tabbing start) This drops the redundant one on close, eliminates it when revealing the frame or zooming in, and ignores toolbar switches, opting to capture it on keep/close only if the activity is shown at the time, and otherwise tries to grab one just before we leave the activity to another zoom level or activity. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Could someone test the Home search entry...?
Hello all - I've recently experienced some very buggy behavior with the search entry in Home in my jhbuild (master). I want to ensure that this gets properly tested in the upcoming joyride build (as I'll be moving/on vacation myself), so I'm going to leave a couple test cases here for someone to take on. 1. Switch to the list view of Home and enter 'bro' into the search entry. The Browse activity should turn up as the only result in the filtered list. 2. Append a nonsense string to your search eg. 'broasdf'. If all goes well, you should have an empty list, though in my jhbuild testing, Browse remained visible. 3. Clear the search entry (select text and delete, or click the little 'x' button within the entry). The full list of installed activities should return. In my jhbuild testing, nothing could be done to restore the full list. If the above all work as expected, please verify the test case attached to http://dev.laptop.org/ticket/7874 as well. Finally, if this is all verified as working in joyride, it's probably still worth testing on the master branch in jhbuild, since I can't seem to get it to work there. Oddly, I tried reverting both sugar and sugar-toolkit to the last commits on August 13th (the day I submitted the patch attached to the aforementioned ticket, at which time that test case DID work fine in jhbuild), but the problem remained after rebuilding. Perhaps git just hates me. In any case, thanks for testing for me! If this IS broken, I nominate it as a blocker for 8.2.0, since it's easy to trigger a search, and impossible to clear it to reveal all installed activities, thus making it impossible to set favorites or launch some activities at all without a reboot. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Landing patches about the network devices UI
On Mon, Aug 25, 2008 at 8:19 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: Hello, we have a couple of patches that should be ready to be reviewed by tomorrow, which solves several issues with the UI of network devices. #6944 UI confuses which AP you are connected to #3993 The color of network icon in Home view becomes white after restarting Sugar. #2866 Network Manager GUI doesn't report success or failure #6995 Add a mesh device to the frame and remove mesh devices from Neighborhood view The tickets are a little confusing, so let me summarize what the patches does: 1 Adds IP address to the mesh wireless palettes, with associated changes to their model classes. 2 Removes the Disconnect or Turn On/off entries from the wireless/mesh palettes. 3 Makes both frame icons pulse. 4 Don't show the mesh icons in the mesh view, instead show them in the frame. 5 Fix some iconsistency in the icon states by cleaning up the code. mtd did quite a bit of testing on them already, but they are pretty invasive and there is some risk of regressions. My opinion is: 2 is controversial and should be left as is for 8.2 It's mainly controversial because they don't do what they say, or what you'd expect them to, but this can wait. Maybe we can actually do it correctly next time around. 1, 5 are important and we should try to get them in. Yup. 4 would be nice to have but I don't consider it essential. Actually, I think this is the most important aspect of the design, and I strongly suggest we try to land it. This has been confusing to many, and when we change it I think we need to commit to going the whole way, instead of leaving it in limbo which will only confuse people more down the road. 3 should be delayed unless it's small and it's easier to take it then to refactor patches. OK. - Eben 1,3,5 has been submitted for review as patch A. 2, 4 will be submitted today as patch B. My suggestion would be: * Rip off 3 from patch A if it's worth it and land it for 8.2.0 (before Friday) * Do *not* land patch B for 8.2.0 mtd has some free time today, so if we can let him know what we want and don't want to land soon it would be great. Thanks, Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Landing patches about the network devices UI
On Mon, Aug 25, 2008 at 11:27 AM, Kimberley Quirk [EMAIL PROTECTED] wrote: I don't agree with adding #4 at this time (changing how/where we see the mesh icons). One of the many work-arounds that we have been telling people in field is that they may need to choose mesh ch 6 or 11 if they want a small group to collaborate in a school setting without any other infrastructure. If the mesh icon doesn't show up in the neighborhood view, that will be a problem. Why would this be a problem? We're not changing the functionality; only the position of the button within the UI, to be more consistent with the device model we're following. I'd like to see this UI change well before it is implemented. Is there a url, Eben? This was mocked up as part of my initial redesign storyboards on the wiki: http://wiki.laptop.org/go/Designs/Frame#09. It's important that the mesh be recognized as a capability of the laptop, and not as a physical device somewhere else in space. The fact that the mesh devices were even added to the Neighborhood view was a last minute hack, and we've been living with it (and confusing people with it) ever since. - Eben I'm less concerned about 1 and 3 because they don't seem invasive from the one line summary... if they get in this week as polish that would be ok. I don't know the depth of 5 or 2... and I'm most worried about 4. If all these fixes come in one patch, then I would ask that we do NOT take this patch. If we can pick and choose from this list to get some polish things into 8.2, then let's pick a few based on the invasiveness. Thanks, Kim 1 Adds IP address to the mesh wireless palettes, with associated changes to their model classes. 2 Removes the Disconnect or Turn On/off entries from the wireless/mesh palettes. 3 Makes both frame icons pulse. 4 Don't show the mesh icons in the mesh view, instead show them in the frame. 5 Fix some iconsistency in the icon states by cleaning up the code. On Aug 25, 2008, at 10:01 AM, Marco Pesenti Gritti wrote: Eben Eliason wrote: On Mon, Aug 25, 2008 at 8:19 AM, Marco Pesenti Gritti 4 would be nice to have but I don't consider it essential. Actually, I think this is the most important aspect of the design, and I strongly suggest we try to land it. This has been confusing to many, and when we change it I think we need to commit to going the whole way, instead of leaving it in limbo which will only confuse people more down the road. Personally I think it's way too late for invasive UI changes. I'm fine to be overridden by Kim/Greg decision in that direction, though. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [PATCH] New Activity Launcher
My recent interactions with the launcher have led me to frustration.
I updated a number of tickets on the subject, and also created an
aggragator to track them all (http://dev.laptop.org/ticket/8090). The
attached patch is an attempt to solve nearly all of the known
problems. Testing would be very much appreciated.
The only known issue I've found with this patch is that you can't
click on the activity level button (in the Frame) while a launcher is
the selected activity (though you can click on the launcher icon
directly). Marco understands this issue, but feels we might be better
off working in a fix separately, since it could be more invasive.
Apart from that know bug, I believe that this new launcher yields
expected behavior everywhere; if you disagree, or find other bugs, let
me know!
- Eben
diff --git a/src/model/homeactivity.py b/src/model/homeactivity.py
index fa50932..34ebda3 100644
--- a/src/model/homeactivity.py
+++ b/src/model/homeactivity.py
@@ -73,9 +73,11 @@ class HomeActivity(gobject.GObject):
dbus_interface=org.freedesktop.DBus)
def set_window(self, window):
-An activity is 'launched' once we get its window.
-if self._window or self._xid:
-raise RuntimeError(Activity is already launched!)
+Set the window for the activity
+
+We allow resetting the window for an activity so that we
+can replace the launcher once we get its real window.
+
if not window:
raise ValueError(window must be valid)
diff --git a/src/model/homemodel.py b/src/model/homemodel.py
index 49f2a23..a35dcc9 100644
--- a/src/model/homemodel.py
+++ b/src/model/homemodel.py
@@ -175,8 +175,10 @@ class HomeModel(gobject.GObject):
home_activity.set_window(window)
-home_activity.props.launching = False
-self.emit('launch-completed', home_activity)
+# We only emit launch-completed if this is not a launcher window
+if service_name:
+home_activity.props.launching = False
+self.emit('launch-completed', home_activity)
if self._active_activity is None:
self._set_active_activity(home_activity)
diff --git a/src/view/Shell.py b/src/view/Shell.py
index 514b500..77280ac 100644
--- a/src/view/Shell.py
+++ b/src/view/Shell.py
@@ -53,6 +53,7 @@ class Shell(gobject.GObject):
self._model = shellmodel.get_instance()
self._hosts = {}
+self._launchers = {}
self._screen = wnck.screen_get_default()
self._screen_rotation = 0
@@ -63,8 +64,6 @@ class Shell(gobject.GObject):
self.home_window = HomeWindow()
self.home_window.show()
-self._launch_window = LaunchWindow()
-
home_model = self._model.get_home()
home_model.connect('launch-started', self.__launch_started_cb)
home_model.connect('launch-failed', self.__launch_failed_cb)
@@ -94,17 +93,24 @@ class Shell(gobject.GObject):
def __launch_started_cb(self, home_model, home_activity):
if home_activity.get_type() != 'org.laptop.JournalActivity':
-self._launch_window.show()
+launch_window = LaunchWindow(home_activity)
+launch_window.show()
+self._launchers[home_activity.get_activity_id()] = launch_window
+self._model.set_zoom_level(shellmodel.ShellModel.ZOOM_ACTIVITY)
def __launch_failed_cb(self, home_model, home_activity):
-self._launch_window.hide()
+launch_window = self._launchers[home_activity.get_activity_id()]
+if launch_window:
+launch_window.destroy()
def __launch_completed_cb(self, home_model, home_activity):
-self._launch_window.hide()
-
activity_host = ActivityHost(home_activity)
self._hosts[activity_host.get_xid()] = activity_host
+launch_window = self._launchers[home_activity.get_activity_id()]
+if launch_window:
+launch_window.destroy()
+
def _activity_removed_cb(self, home_model, home_activity):
xid = home_activity.get_xid()
if self._hosts.has_key(xid):
diff --git a/src/view/launchwindow.py b/src/view/launchwindow.py
index ee3ccfa..2c4d73a 100644
--- a/src/view/launchwindow.py
+++ b/src/view/launchwindow.py
@@ -19,6 +19,7 @@ import hippo
import gobject
import logging
+from sugar import wm
from sugar.graphics import style
from sugar.graphics import animator
from sugar.graphics.xocolor import XoColor
@@ -27,14 +28,15 @@ from model import shellmodel
from view.pulsingicon import CanvasPulsingIcon
class LaunchWindow(hippo.CanvasWindow):
-def __init__(self):
+def __init__(self, home_activity):
gobject.GObject.__init__(
-self, type_hint=gtk.gdk.WINDOW_TYPE_HINT_SPLASHSCREEN)
+self, type_hint=gtk.gdk.WINDOW_TYPE_HINT_NORMAL)
-self._box = LaunchBox()
+self._activity_id =
Re: [sugar] [PATCH] New Activity Launcher
On Fri, Aug 22, 2008 at 4:56 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Haven't tried your new activity launcher (I wait for the binary to show up in Joyride), but your mentioning of the Frame reminded me: I have no idea of how I got there, but I have experienced a situation where there was a disconnect between the session that was being launched, and its icon in the Frame. Basically the session vanished (e.g., couldn't find the executable that was supposed to be launched) but the icon in the Frame kept pulsing. The new(er) launcher in my patch should partially address this, inasmuch as it won't allow the disconnect which existed temporarily in some builds. In my new version, the launcher will *always* be shown in place of an activity until it successfully launches (or officially fails to do so). It is possible to switch away and later switch back to the launcher screen, as if it were a placeholder for the launching activity. That is, as long as there is a pulsing icon in the Frame, there will also be a launcher window present. What I would like to see is for the palette on the icon in the Frame (while the Activity is being launched) to have not just 'Starting' as an entry, but also 'Stop' as an entry. That way, if I am faced with a too-long-a-duration pulsing icon, I can tell the whole launch process -- including the icon -- to just go away. Me too! This is an age-old topic that I brought up a long time ago when we were first designing the activity ring (http://dev.laptop.org/ticket/1166). Unfortunately, it's gone untouched for quite a while, evidently because of difficulties in actually knowing what process a given activity is connected with. I think it's something worth investigating again for 9.1, and I agree that the best way to do this is to allow a Stop action from the icon in the Frame, as usual. We should also make that label read Starting... or Resuming... as appropriate. Finally, something that isn't done yet (but is facilitated by the latest launcher patch and will be added in 9.1) is notification on launch failure. An alert will appear within the launcher window indicating the failure, and offer options such as retry, show logs, and cancel. If the launcher window which fails isn't visible at time of failure, we'll use the notification system to let the user know something went wrong. Thanks for your feedback! Hopefully some other testers will chime in (with nothing but praises) so we can actually get the changes into a build... - Eben mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
This is getting a little out of hand, here. Let's break this down again, because I think we're all arguing for pretty much the same thing. On Wed, Aug 20, 2008 at 12:19 AM, Bastien [EMAIL PROTECTED] wrote: Eduardo Heleno [EMAIL PROTECTED] writes: But my point was that, at the moment, you can choose to Erase an item, and it's gone forever. I expect that many kids will do this, and will at some point regret erasing some item. Yes. This is a request that has been made here in Haïti. The issue of deletion confirmation is covered under ticket http://dev.laptop.org/ticket/7859. I flagged it as blocks?:8.2.0, but I don't think it is going to be nominated as a blocker at this point unless there is a strong push for it. This is, at least for now, independent of the trash can issue itself. On Wed, Aug 20, 2008 at 1:27 AM, Bastien [EMAIL PROTECTED] wrote: Martin Langhoff [EMAIL PROTECTED] writes: AFAIK, the plan is to *discourage* deletion until the disk is getting full. When you are getting to disk-full, trashcan doesn't help. Yes it does: it contains entries that the system can safely delete without forcing the user to go thru the entries and sort them out on the fly. This is no less true in the future Journal design. Anything which has been previously erased can be transparently deleted by the system without another prompt. The Journal should be following a lazy-deletion strategy, making it really no different from the trash can you speak of. The only difference is how the erased but not yet truly gone files get represented to the user. People now want deletion because the Journal is not optimal. They want deletion to sort out entries in the Joural and get rid of unfinished or useless entries. With too many entries, the (current 703/708) Journal becomes unusable. I do recognize this. The one detail we could add to potentially solve this argument is a button which turns on/off visibility of erased entries. That is, a button which basically shows and hides trashed files by toggling their visibility inline within the Journal, in addition to a way to view only those files as well. When you are running out off disk space, we have two cases: - ds-backup has been doing its job, there's a copy of the files in the XS, so the journal has old-and-backed-up files that it can decide to rm I'm afraid XS servers won't be of use in *many* schools. That's fine. The backup solution is an enhancement, not a requirement. Consider the possible states for entries: 1. Normal: file stored locally on the XO 2. Normal+Backup: file stored locally on the XO, and also on the server 3. Lazy-erased: file stored locally on the XO, but rendered differently to indicate transient state 4. Lazy-erased+Backup: same as above, but also backed up to the server 5. Erased: not stored locally on XO 6. Erased+backup: not stored locally on XO, but still available on the server States 1, 3, and 5 are the basic states without backup in the picture. They map directly onto a file, a trashed file, and a file which has been emptied from the trash, respectively. Without a server, you can still recover anything in state 3. When you have a server, you can recover anything in states 3, 4, and 5 (call these the recoverable states). In all of these recoverable states, we will visually represent a the entry in a way distinct from normal, present entries, and the entries in these states will have buttons which allow them to be a) recovered or b) permanently erased. If we want, we can be a bit more clever about which cases require deletion confirmation (based upon whether or not the action results in a recoverable state), but we could simply ask for confirmation all the time for consistency. Or, never. - no old-and-backed-up files we can safely remove? Prompt the user I'm curious whether someone did this job of being prompted. How long does it take? If you can't remember what a file contains, checking if it's safe to delete it by trying to reopen it might be tiring. The Journal does (will do) better than many other systems. The preview is sadly underutilized at the moment, but it should provide a hint without the need to open it. We have a few ideas about how to encourage naming and tagging as well, which will improve this situation a lot. Finally, we have the notion of favorites in the Journal. If we encourage their use as well (which we will in the next version, since it will be possible to filter the list to show only favorites, thus eliminating the unwanted entries which currently make it difficult to find things), then it should be easy to at least preserve the things you've already indicated in the past mean something to you. We'll also have true versioning in the future, so it will be possible to prune the version tree, keeping fewer intermediate versions the further back in time we look. 2008/8/20 [EMAIL PROTECTED]: prompt the user, interrupting whatever they were trying to get done?
Re: [sugar] Please help test our new 8.2.0 weekly beta, joyride-2263!
On Tue, Aug 19, 2008 at 5:42 AM, Eduardo Heleno [EMAIL PROTECTED] wrote: 2008/8/9 Christoph Derndorfer [EMAIL PROTECTED] On Thu, Aug 7, 2008 at 8:45 PM, Michael Stone [EMAIL PROTECTED] wrote: [snip] This isn't really a bug but rather a general observation so I'm not quite sure where to put it... When you're in the software-update panel of the control-panel then there are cancel and ok buttons in the upper right corner. However the ok button seems redundant as they both do exactly the same thing: close the panel and take you back to the main configuration screen. At least that's the case when the software is up-to-date. IIRC you also need to press a button inside the panel for updating when there's new software available which would again make the ok-button redundant. I spotted this as well. Some other wording is necessary in here, perhaps an Accept and Cancel buttons appear when changes are made, otherwise a simple Close button appears. Actually, the intent is to make the Accept button insensitive until changes are made, so that the options are leave without making changes (regardless of whether or not I changed anything), and leave and accept changes made (only available when there are changes). There is a patch for this, but it hasn't yet been accepted. (http://dev.laptop.org/ticket/7643) - Eben Edu Cheers, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] letting the user specify the mesh channel
On Sat, Aug 16, 2008 at 6:45 PM, Eduardo Heleno [EMAIL PROTECTED] wrote: 2008/8/14 Eben Eliason [EMAIL PROTECTED] On Thu, Aug 14, 2008 at 6:26 AM, Eduardo H Silva [EMAIL PROTECTED] wrote: I like a lot the mockup http://dev.laptop.org/~mdengler/6995/6995_screenshot_45.png ... I would just add one more sugestion. Include on the primary palette as a secondary title the word Connected. You may think that the coloring of the mesh icon makes it clear it is connected, but i think it is important to be plan ahead for all potential users of Sugar, like those who are blind (use some kind of text-to-speech interface), color-blind, or even just poor eye-sighted people. Good points. We could add, at a minimum, the Connecting..., Connected, and Disconnecting... states as the secondary text in the palette. Is this clearer, or should we use Starting..., On, and Stopping instead? If we use the former, should we change Turn on and Turn off? I think the terminology should remain Connecting...,Connected,Disconnecting..., and the actions be Connect and Disconnect. Let's not underestimate kids and their inteligence of discernment between turning something on, and making a connection between 2 point. Actually, this is the very reason that the designs had Turn on/Turn off instead. Unlike an AP, to which a direct association is made, the mesh simply enables a protocol of discovery, rather than initiating any direct connection(s). You can have the mesh turned on and have no connection to anyone or anything at all, if no one is in range. Hence, connected could actually be misleading. I was actually considering keeping the terminology consistent just to keep things simple, instead of alluding to the subtler differences between the Mesh and AP devices. I'm still open to argument either way. In the future, one should think how this info will work with the notification system? Yes, they will certainly be accounted for; Mesh, AP, battery, and other devices are a large impetus for the notification system in the first place. - Eben Edu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 0.84 goals
On Fri, Aug 15, 2008 at 10:57 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Why not let accessing of *deferred* Activities be handled by Journal ? Because it involves an extra step or two that in practice people don't take. Personally, I would even go to the extreme that the Home View should by default open the most recent Journal entry. I think that improvement to the Journal will make it a place people *want* to go to. It should be friendly. It should expose previews up front to make browsing easier. *Everything* should have a preview (right now it's often pretty barren). We need to encourage naming so that meaningful titles can be read and searched. We need to get better collaboration, and for more activities, so that the Journal fill sup with a wide palette of colors. All of these things should make it a place rich in info and pleasurable to peruse. That said, we also do have the design for allowing one to resume the most recent Journal entry for any given favorite activity in Home view, as well. I'll be the first to admit that the current implementation of Journal is cumbersome. But if it is possible to add palette entries You're too late! I was first! :-P to Activity icons on Home view (for resuming something), it ought to be possible to add similar short cuts on the Journal screen. I can get to the Home view by pressing the 'Home view' key on the keyboard. I can get to Journal by pressing the 'Journal' key on the keyboard. For me, going to the Journal takes no more steps than going to Home View. [And since Home view provides alternate ways of presenting its information, why oughtn't Journal provide alternate ways of presenting *its* information (including a clickable short cut listing of the most recently saved Activities) ?] Isn't that what you get by default? The most recent n created/saved entries are at the top, so this is really the whole point. - Eben I was speaking from the point of view of *defining* the purpose of the Home view. If 'resume' is there, should 'erase' be there also -- what if the user mis-positions his click ? I'm a procedure-oriented person, not an object-oriented person. So it has taken me effort to mentally construct a role for the Journal. If short cuts to the most-recent uses of the Activities are provided elsewhere, why bother having a Journal in the first place ? mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] letting the user specify the mesh channel
On Thu, Aug 14, 2008 at 6:26 AM, Eduardo H Silva [EMAIL PROTECTED] wrote: I like a lot the mockup http://dev.laptop.org/~mdengler/6995/6995_screenshot_45.png ... I would just add one more sugestion. Include on the primary palette as a secondary title the word Connected. You may think that the coloring of the mesh icon makes it clear it is connected, but i think it is important to be plan ahead for all potential users of Sugar, like those who are blind (use some kind of text-to-speech interface), color-blind, or even just poor eye-sighted people. Good points. We could add, at a minimum, the Connecting..., Connected, and Disconnecting... states as the secondary text in the palette. Is this clearer, or should we use Starting..., On, and Stopping instead? If we use the former, should we change Turn on and Turn off? There is also a ticket around about the lack of information on the stages of connecting to a network. This could be done as a palette for the network icon which would only appear on-mouse-hover and during the period it is connecting. Users diagnosticating or curious about the connection process could easily see it, while others will be just happy with the blinking icon information. Perhaps. I'm curious to know what info/stages we actually have, before specifying any design there. - Eben Eduardo 2008/8/7 Eben Eliason [EMAIL PROTECTED] On Thu, Aug 7, 2008 at 11:45 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: See http://dev.laptop.org/~mdengler/6995/6995_screenshot_45.png for an example of how I currently have it looking. Thank you. Currently, I use the presence of a 'Disconnect' entry in the palette as a mnemonic device to indicate to me that a connection currently exists. Would be nice to keep that. Hey Mikus - In the new designs, the Mesh device icon turns on (becomes colored) when the mesh is active, and is rendered in white when it's off. It should be even easier to tell the present state, without needing to dig into the palette. - Eben p.s. For laughs: Now that you are *explicitly* showing channel numbers -- I have a friend whose home AP is on channel 9. At his house, I manually use 'iwconfig' to set my XO's radio to channel 9, to be able to connect to his AP. I haven't tried setting multiple XOs to channel 9 when there is no AP -- but if mesh were configured to run that way, would your palette show that? ;) No, the mesh channels are independent* of the AP channels; if you connect to an AP on channel 9, you are not on the mesh, which is only offered on channels 1, 6, and 11. If you turn the mesh on, you'll implicitly be disconnected from an AP on channel 9. If you manually set the mesh channel otherwise, I doubt it will be reflected in this palette. * Note that in the future it will be possible to be connected on the mesh and to an AP, assuming they are both on the same channel. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] non-colored activity icons in frame
Certainly not intended. If it persists or appears in a joyride, please ticket it. - Eben On Thu, Aug 14, 2008 at 8:17 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Just tried faster-2301. In the top bar of the Frame, the icons for the currently active Activities were being shown in black-and-white. Looked more aesthetic when they were shown in the user's colors. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Journal view flips topmost entries
On Tue, Aug 12, 2008 at 4:52 AM, Morgan Collett [EMAIL PROTECTED] wrote: On Tue, Aug 12, 2008 at 00:12, Eben Eliason [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 4:51 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: My guess is that flipping of the topmost entries in Journal has to do with scheduling rather than with communications. Though in I'm sure that what you are seeing results from the fact that the Journal defers updating itself until its window is shown, to prevent needless updates from occurring in the background and taking extra CPU cycles. It's unfortunate that the single update that occurs when the Journal is focused has so much latency...this should really be happening so quickly as to be unnoticeable. There are a lot of pieces of the Journal that could use some optimiation, among them the actual rendering of the entries themselves when a change occurs (try starring/unstarring and see how long it takes it to redraw to reflect the change! (http://dev.laptop.org/ticket/7151)). That said, the circumstance you describe is truly not good; in fact, without a confirmation alert upon deletion, this could might even be considered a blocker. Could you open a ticket describing the problem, and note that adding a confirmation might be a valid short term workaround to prevent accidental deletions? (Actually, just found this: http://dev.laptop.org/ticket/3778. Could you update this ticket with your experience and perhaps add a blocks?:8.2.0 tag so it's considered?) Clearly we need to this and also plenty of optimization in the future. - Eben PS. If you truly are seeing the flip apart from the first time the Journal is shown, there is something else amiss. Please keep an eye out and confirm one way or the other if you actually experience such behavior. Thanks! I see the flipping - it's easy to reproduce. With two open terminals (named differently) if I just hit alt-tab from the Journal, to the first terminal, and without releasing alt I hit tab again to the second terminal, and then tab again to the Journal, I get a momentary flip. This sounds wrong (well, over-aggressive) to me. While the Journal does maintain recent-on-top ordering of entries, this shouldn't be reflected at the granularity of activity switches. Instead, it should be at the granularity of saves. It's quite possible that this is in fact the case, and that these activities are saving every time they lose focus; if that's the case, we need to implement a dirty bit paradigm ASAP which prevents activities from needlessly saving themselves all the time. Better still, we might implement logic which brings an entry to the top of the list when it is resumed (or started), and then mostly ignoring its ordering until it is stopped again, at which point it is brought to the top just beneath the entries for activities which are still running. In this manner, we can be satisfied by maintaining an ordering in which all running activities are in somewhat arbitrary order on the top, and all non-running entries are ordering by stop-time below them. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] Trac #7480: Need to 'reset' the network configurations - short term fix
On Tue, Aug 12, 2008 at 4:26 AM, Morgan Collett [EMAIL PROTECTED] wrote: On Tue, Aug 12, 2008 at 03:31, Erik Garrison [EMAIL PROTECTED] wrote: Attached is a patch which adds a 'reset network configuration' button to the network tab of the sugar control panel. Clicking this button simply rotates the config file out of the way, saving it as ~/.sugar/default/nm/networks.cfg.bak.NNN (NNN is the number of previously backed-up configs +1). This is just a short-term fix (hack) to resolve the problem of not having any gui-level method to manipulate the nm network configarion. Eben has noted that we would like to enable config panel level manipulation of the networks.cfg stanzas; but this requires a bit more code than this immediate fix. This needs testing: in some cases NM replaces the config with what was there. I added a different AP to my home network (in parallel with my existing AP). To get the XOs to associate only with the new AP, I thought I'd simply delete networks.cfg and then associate to the new AP. When I rebooted to make sure it did what I wanted, networks.cfg had both the old and the new APs. To end up with only the new AP in networks.cfg, I had to first associate to the new AP, then remove the old one from networks.cfg - then rebooting after that showed only the new one. Hmm, meaning that the other associations were stored in memory at the time and later written back to the file? In other news, do you have a screenshot or a demo of this I can look at, Erik, to sign off on the UI? - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [OLPC Security] P_READ_LOGS
On Mon, Aug 11, 2008 at 10:07 AM, Bastien [EMAIL PROTECTED] wrote: Mikus Grinbergs [EMAIL PROTECTED] writes: The easiest way to present logs, especially failure logs, is to make them available through the standard Journal/Datastore interface. For example, we have some agreement that when an Activity fails to launch, the failure should appear as such in the Journal time-view, connected to an object representing the log file for that failure. This log object has a text type, and so can naturally be opened by any Activity that accepts this type. No additional permissions are required. The user is responsible for determining when to provide both sensitive data and P_NETWORK to the same Activity. I find the Journal interface to be cumbersome. I also do not believe the Journal ought to be cluttered up with footprints a kid would probably not be able to do anything about. -1. Agreed, but... I also think failure logs don't naturally fit into the current Journal. They are a non-desirable side-effect of an activity, not an activity per se. But it could fit okay into the next versions of the Journal, where some kind of pre-filtering would let the user see only the most important entries for him. Failure logs would then be low-level entries, along with other logs (particularily mail logs, when we'll have a native mail client on the XO.) ...I do think they could belong in the Journal specified in the latest designs. The new Journal is divided into actions and objects which adjust the perspective on the available stuff. For this particular case, an action (The action view is most like the current ) would be logged to say Activity X failed to launch., and containing a reference to the log file, which would only appear as a separate entry within the Objects view. This ability to encapsulate several object references into individual, higher level action entries should make the Journal much friendlier, and provide a way to get to details like log files and other such info without cluttering up the view. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] letting the user specify the mesh channel
On Thu, Aug 7, 2008 at 11:45 AM, Mikus Grinbergs [EMAIL PROTECTED] wrote: See http://dev.laptop.org/~mdengler/6995/6995_screenshot_45.png for an example of how I currently have it looking. Thank you. Currently, I use the presence of a 'Disconnect' entry in the palette as a mnemonic device to indicate to me that a connection currently exists. Would be nice to keep that. Hey Mikus - In the new designs, the Mesh device icon turns on (becomes colored) when the mesh is active, and is rendered in white when it's off. It should be even easier to tell the present state, without needing to dig into the palette. - Eben p.s. For laughs: Now that you are *explicitly* showing channel numbers -- I have a friend whose home AP is on channel 9. At his house, I manually use 'iwconfig' to set my XO's radio to channel 9, to be able to connect to his AP. I haven't tried setting multiple XOs to channel 9 when there is no AP -- but if mesh were configured to run that way, would your palette show that? ;) No, the mesh channels are independent* of the AP channels; if you connect to an AP on channel 9, you are not on the mesh, which is only offered on channels 1, 6, and 11. If you turn the mesh on, you'll implicitly be disconnected from an AP on channel 9. If you manually set the mesh channel otherwise, I doubt it will be reflected in this palette. * Note that in the future it will be possible to be connected on the mesh and to an AP, assuming they are both on the same channel. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] New joyride build 2258
On Wed, Aug 6, 2008 at 7:10 AM, Build Announcer v2 [EMAIL PROTECTED] wrote: --- Changes for sugar 0.81.8-2.20080806git0fc57309f3.olpc3 from 0.81.8-1.fc9 --- + 7495 open cp software-updater on first boot after an update I don't want this! I keep shouting about it and no one seems to be listening! Home absolutely needs to be home base, especially after an update. I'm fine with tossing up a non-modal alert at boot which prompts the user to update right away, with a button which reveals the software update control panel module, but I'm NOT OK with anything which, unbeknownst to the user, flits them away to some other part of the system without his/her consent. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Another sugar rant (was: x2o physics problem solving game)
On Wed, Aug 6, 2008 at 2:08 AM, Neil Graham [EMAIL PROTECTED] wrote: On Wednesday 06 August 2008 7:08:33 am Alex Levenson wrote: Searching for X2o using the wiki search doesn't find it. It's Called X2o! it's url is http://wiki.laptop.org/go/X2o for heaven's sake! Somebody either fix the search or just change the search box to go to google. Are you sure? When I search for 'X2o' (case insensitive) I am taken directly to the page you identified, bypassing any search results page altogether. With regards to using activities on the XO I've tried to be accepting of the sugar interface style, but this activity crystallizes things for me. I'm now prepared to move to the sugar-sucks camp. I've used many and written a few I think nearly all of us are in the sugar-sucks-but-is-still-changing-lives-and-we're-gonna-do-everything-in-our-power-to-make-it-rock camp. We like it when people move from the sugar-sucks camp into ours! ;) I'd like to be clear that I don't think there is anything done poorly in the X2o activity itself. I think it all comes from having the sugar interface. The more I encounter sugar interfaced programs, the more I think Activities would be better off with just about anything else. Specific examples would be extremely beneficial here. Is it the fullscreen nature of the window? The toolbars? (Note, there's another interesting design proposed for these: http://wiki.laptop.org/go/Designs/Toolbars) The GTK theme? There's lots of stuff missing still, but feedback on the particulars of what's already there would be great. I gave myself a long time to acclimatise, much longer than I would have for anything else, because the XO is really quite important. I really believe in the goals of the OLPC project, but I cant use the XO effectively! My daughter can't use the XO effectively! Perhaps you mean efficiently? (Most of us would agree with you, there.) However, there are certainly thousands of kids using them effectively despite the inefficiencies and bugs; the work we see coming back from deployments proves this, and keeps all of us going with the hope of making it far better in the future -- perhaps even effective and efficient enough for us spoiled folk. =) At what point does a do-over make more sense? I was prepared to take the resource usage and the slow bits and the joke that is the journal because they were all things that future work would have addressed. The cumbersome user interface is a killer though because it's designed to be like that. Again, without examples a rant is nothing but hot air. What parts are so fundamentally broken that not even future software updates could fix them? The Journal is a pretty good example of a fundamental part of the system that's mostly non-functional at present, but we have some good designs for it (http://wiki.laptop.org/go/Designs/Journal) and I expect that, at some point, hopefully soon, we'll also have the resources to implement them. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Another sugar rant
On Wed, Aug 6, 2008 at 11:30 AM, Ton van Overbeek [EMAIL PROTECTED] wrote: Eben Eliason wrote: On Wed, Aug 6, 2008 at 2:08 AM, Neil Graham [EMAIL PROTECTED] wrote: On Wednesday 06 August 2008 7:08:33 am Alex Levenson wrote: Searching for X2o using the wiki search doesn't find it. It's Called X2o! it's url is http://wiki.laptop.org/go/X2o for heaven's sake! Somebody either fix the search or just change the search box to go to google. Are you sure? When I search for 'X2o' (case insensitive) I am taken directly to the page you identified, bypassing any search results page altogether. I have to agree with Neil. Entering X2o in the Wiki search box on the left hand side of wiki.laptop.org leads to no matches whatsoever. Searching laptop.org via Google gives the correct page as first hit. Sorry, my fault. I failed to realize that the enter key was bound to the Go button instead of the Search button. You're right, I get no results either. It's truly strange that it doesn't recognize the page title direct match. In fact, I can even click on the 'X2o' in the text where it says You searched for X2o and get linked to the correct page! It sounds like a wiki bug, to me...has anyone filed one yet? If not, I guess it should be done. - Eben Ton van Overbeek ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] New joyride build 2258 (Eben Eliason)
On Wed, Aug 6, 2008 at 12:30 PM, Greg Smith [EMAIL PROTECTED] wrote: Hi All, +1 on not reaching out over the network or doing anything without user input. I'm also nervous about the software update icon in the control panel going out over the network and doing something immediately after you click and before you do anything else with the Update interface. Is there any precedent or guidelines on what happens first after you choose a Sugar Control Panel option? These are usually implemented in 1 of 2 ways. It may be implemented as a menu item titled Check for updates or similar, which makes the desire to actually initiate the action implicit in selecting it. It can also be implemented as a control panel module, in which case there's usually a Check now button, in addition to information such as the time/date of the last successful update, and options to set up automatic update checks. In our case, we do offer a Cancel button, which would prevent this update scenario from taking over the system/bandwidth completely. However, a Check now button would also work just fine. - Eben Has anyone tested the SW updater control panel over low-BW or offline? I'd rather see it land on a nice GUI that explains what will happen and gives you the option to click and check for the latest activities. Thanks, Greg S -- Message: 2 Date: Wed, 6 Aug 2008 09:47:42 -0400 From: Eben Eliason [EMAIL PROTECTED] Subject: Re: [sugar] New joyride build 2258 Cc: Sugar Mailing List sugar@lists.laptop.org, [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 6, 2008 at 7:10 AM, Build Announcer v2 [EMAIL PROTECTED] wrote: --- Changes for sugar 0.81.8-2.20080806git0fc57309f3.olpc3 from 0.81.8-1.fc9 --- + 7495 open cp software-updater on first boot after an update I don't want this! I keep shouting about it and no one seems to be listening! Home absolutely needs to be home base, especially after an update. I'm fine with tossing up a non-modal alert at boot which prompts the user to update right away, with a button which reveals the software update control panel module, but I'm NOT OK with anything which, unbeknownst to the user, flits them away to some other part of the system without his/her consent. - Eben -- Message: 3 Date: Wed, 6 Aug 2008 15:57:31 +0200 From: Christoph Derndorfer [EMAIL PROTECTED] Subject: Re: [sugar] New joyride build 2258 To: Eben Eliason [EMAIL PROTECTED] Cc: Sugar Mailing List sugar@lists.laptop.org, [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 On 8/6/08, Eben Eliason [EMAIL PROTECTED] wrote: On Wed, Aug 6, 2008 at 7:10 AM, Build Announcer v2 [EMAIL PROTECTED] wrote: --- Changes for sugar 0.81.8-2.20080806git0fc57309f3.olpc3 from 0.81.8-1.fc9 --- + 7495 open cp software-updater on first boot after an update I don't want this! I keep shouting about it and no one seems to be listening! Home absolutely needs to be home base, especially after an update. I'm fine with tossing up a non-modal alert at boot which prompts the user to update right away, with a button which reveals the software update control panel module, but I'm NOT OK with anything which, unbeknownst to the user, flits them away to some other part of the system without his/her consent. +1 Initially I was all for such first-boot features (especially with regard to G1G1 and the help-activity). But after thinking about Eben's arguments in both cases I agree that user should definitely see the home-view as the first thing when they boot the machine. Especially the Sugar-Control-Panel and its overlay above the home-view (which IIRC isn't used anywhere else in Sugar except for the Journal object chooser instead of the traditional file-choose dialogue) could be quite confusing. Cheers, Christoph - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Question about clipboard service
for the clipboard is as a means to port items around among activities for the purposes of embedding. 14 - Can you copy things directly to a USB drive? Definitely. Anywhere we have a Keep in Journal option we can also have a Keep in External Storage menu, which allows one to keep an item directly onto USB or SD. This option could also be added to items on the clipboard. - Eben I hope that's not too many questions. You don't need to address every one, just wanted to throw out some suggestions to get to the next level of detail. I appreciate the specifying in advance and I think you are on the right track. Since the journal abstracted the file system, its not easy to move files between activities. I think we need an overall strategy for file sharing between activities, HW elements (NAND, USB, SD card), computers (XO - XO, XO - PC), schools (XO - XS - XS) and beyond. Clipboard may be a key part of it. Thanks, Greg S Date: Mon, 4 Aug 2008 14:59:56 -0400 From: Eben Eliason [EMAIL PROTECTED] Subject: Re: [sugar] Question about clipboard service To: Tomeu Vizoso [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=ISO-8859-1 There is a fairly comprehensive specification [1] for the clipboard on the wiki. Most importantly it discusses the use of titles, icons, colors, and previews, which are the 4 elements of clippings that we need to support in various combination to make the clipboard successful. This spec isn't word for word perfect anymore, as some minor details have changed, but it gives the high level picture of the API I want to support. Please ask any questions you may have about what's there so far, and I'll try to clean up some details at some point soon. - Eben [1] http://wiki.laptop.org/go/Specifications/Clipboard ___ Devel mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Question about clipboard service
On Tue, Aug 5, 2008 at 1:33 PM, Gary C Martin [EMAIL PROTECTED] wrote: On 5 Aug 2008, at 16:50, Eben Eliason wrote: On Tue, Aug 5, 2008 at 3:44 AM, Greg Smith [EMAIL PROTECTED] wrote: 7 - Is cut supported? How do you remove things from the clipboard? How many items can it hold? Cut is definitely supported, and will remain mapped to the Ctrl-X shortcut familiar to many, however it will not retain the same name. Instead, we've applied the notion of cut as copy and erase, which makes clear that the result of the action is twofold: first it performs a copy action, and second it erases the item selected. Since these semantics make cut an alternate form of the copy action, copy and erase will actually appear as a secondary option in the palette for the copy button itself. Random though; could there also be potential for a paste and erase? This is already included in the specification, right down to the ALT key as a modifier for accessing the functionality. ;) http://wiki.laptop.org/go/Specifications/Clipboard#Pasting It's currently discussed as paste and remove, but you are correct in identifying the correlation between this action and copy and erase; I think paste and erase is the correct terminology for the feature. - Eben The intention being I could be reading a web article, perform several copy actions of separate text paragraphs I want to quote, then switch to write and perform several paste and erase actions to pop the clippings off the stack. Basically an easy way of unwinding the clipboard stack into another Activity. This could also go hand in hand with a potential keyboard modifier (Alt?) to allow a drag and erase of an clipping out of the clipboard in one step** **usually you only paste an item once, so this extra function would reduce the management steps a kid needs to do to erase each used clipping. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Question about clipboard service
There is a fairly comprehensive specification [1] for the clipboard on the wiki. Most importantly it discusses the use of titles, icons, colors, and previews, which are the 4 elements of clippings that we need to support in various combination to make the clipboard successful. This spec isn't word for word perfect anymore, as some minor details have changed, but it gives the high level picture of the API I want to support. Please ask any questions you may have about what's there so far, and I'll try to clean up some details at some point soon. - Eben [1] http://wiki.laptop.org/go/Specifications/Clipboard On Sat, Jul 19, 2008 at 11:14 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: Well, we can add some sugar API around the gtk clipboard stuff, but I'm not sure there's a lot of value in there, as the gtk+ API is already quite high level. The problem here is how do we extend the existing X specs to deliver the experience we aim for. Last we talked about it, Marco was opposed to use the X selection targets to pass titles and icons around. Eben, now is a good moment to start talking about it, can you summarize what is missing from the clipboard and try to list all that we want to do but the current spec doesn't allow to? Thanks, Tomeu On Sat, Jul 19, 2008 at 5:01 PM, Eben Eliason [EMAIL PROTECTED] wrote: I can't tell from your wording if you are implying that we will or will not be creating some custom wrappers for the clipboard service. I think we absolutely need them to accomplish several critical clipboard issues (among them, specifying icons, colors, titles, and previews for clippings). In fact, getting this API working effectively is high on my list of priorities for 9.1 - Eben On Sat, Jul 19, 2008 at 4:19 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 10:29 PM, Faisal Anwar [EMAIL PROTECTED] wrote: Hi, I'm playing around with the clipboard package on sugar and had a quick question. So, the clipboardservice.py file shows some basic api for getting and setting objects on the clipboard through the dbus. However, the add_object and get_object methods (and their variants) rely on knowing an object_id in order to retrieve something from the clipboard. Typically, a clipboard has some stack like structure where you can automatically retrieve the last thing copied to the clipboard without necessarily knowing its internal id. This would seem especially important fo passing things to other activities, which can't reasonably figure out the object_id created when something is saved to the clipboard by another activity. Does anyone know how to just retrieve the last item saved to the clipboard and also get a list of the last N items saved to the clipboard? Also, the gtk.Clipboard framework allows access to several different clipboards that have slightly different purposes. Is there similar functionality available through sugar/dbus or would one go directly to the gtk implementation? Hi Faisal, we haven't reached any agreement yet about exposing a different clipboard API than the one in gtk+ (that wraps around the different clipboard-related specs used in X). In other words, nobody other than the shell should directly use the clipboard service and this will probably disappear in the future. Activity authors should the use the clipboard functionality as exposed by their toolkits (gtk+) or implement themselves those specs (as etoys has done). Can you add this note somewhere in the almanac? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Faster - how do I bypass look, ma - no hands ??
On Mon, Aug 4, 2008 at 2:05 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote: Tried latest Faster -- is the small 'rodent' supposed to be cute ? ?? Encountered at least two hurdles. Would someone please answer for me: 1) The control panel let me get into xfce. But HOW is one supposed to get back from xfce to Sugar? I did not see anything like a 'Control panel' available within xfce. I couldn't say, but I'm curious. I know there is experimentation going on there, but I'm not aware of a final design choice. What I did was to rename .xsession-xfce. Is there a GUI ? 2) After the build install, I was *automatically* put by Sugar into 'Control Panel - Software update'. Only one difficulty - I do not have wireless, and even ethernet works for me only after I have customized the environmental variables. Auto-starting any activity or control panel is also against the design intent. I really don't want this to happen. If we think it's absolutely necessary to push G1G1s into an update, then we should have an alert (non-modal, perhaps) that appears on first boot instead, which offers to take them directly into software update. Failing to present the Home screen (and a new one, at that) as Home is a bad idea. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] ATTN Activity Authors/Owners: Default activity icon colors
Ticket #7741 [1] points out that inconsistencies in the default colors of activity icons appear in the filter of the Journal. This is Sugar's fault, not yours. Unfortunately, we can't adjust the APIs as needed in order to fix this correctly for 8.2, and so we instead humbly request that all activity icons be bundled with the defaults listed below, to help us hide our indiscretion until we can do so. The appropriate defaults, for now, are: stroke: #010101 fill: #FF Note that it should be easy to fix any icons simply by hand editing the file to adjust the entity definitions (see http://wiki.laptop.org/go/Making_Sugar_Icons#Defining_Entities_2); it's not necessary to export the icon again. Thanks for helping us hide our embarrassment! - Eben, and the Sugar team PS. Note that in the future, even though Sugar will always render icons appropriately in any context, the recommended default for icons will be a #66 stroke (and white fill), so as to match the appearance of the icons when rendered in Home. This will, in particular, improve the consistency of icon appearances of the wiki. The script linked from the above wiki page includes a flag to automatically render icons in the (new) defaults, for future reference. [1] http://dev.laptop.org/ticket/7741 (see also: http://dev.laptop.org/ticket/7578) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] current network differentiation?
On Thu, Jul 31, 2008 at 3:14 PM, [EMAIL PROTECTED] wrote: is it intentional that the currently-connected network is no longer differentiated in the neighborhood view? the outer ring of that network icon used to be white -- it no longer is. This is intentional. The colors of the stroke/fill serve as the visual representation of the identity of the network; changing them effectively strips this identity. The new design does not make any indication of which network is presently associated in the Neighborhood view; perhaps we can find an alternative method. Thoughts? it's been pointed out that you can see your current network on the frame, but somehow that's not quite the same (to me). Yes, that's the preferred model. The Frame serves as a perpetual status element, and is instantly accessible no matter where you are within the UI. I'm open to improvements on the model. i'm also not sure how to disconnect from that network -- there's no disconnect option in the popup anymore. Well, that's a bug, but not really. The problem is that there is no notion of disconnect in network manager at all. The old behavior used to switch into mesh mode, which disassociated with the network itself. However, we now have a more direct means of accomplishing this, via turning the mesh device on or off explicitly. It doesn't make sense to compound these. The more conventional option is something like turn wireless off to disassociate with the current network, but that assumes that there is no other potential use for the wireless at all. In our case we still have the mesh to worry about, so that again doesn't map onto our circumstances. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] current network differentiation?
On Thu, Jul 31, 2008 at 3:42 PM, [EMAIL PROTECTED] wrote: eben wrote: On Thu, Jul 31, 2008 at 3:14 PM, [EMAIL PROTECTED] wrote: is it intentional that the currently-connected network is no longer differentiated in the neighborhood view? the outer ring of that network icon used to be white -- it no longer is. This is intentional. The colors of the stroke/fill serve as the visual representation of the identity of the network; changing them effectively strips this identity. The new design does not make any indication of which network is presently associated in the Neighborhood view; perhaps we can find an alternative method. Thoughts? i get the color thing, though those colors are all arbitrary, right? but i guess you can say connect to the green/orange network as a means of identification, and if the ring is white, you can't do that. but it still feels like the connected network should be special in that view. maybe little radio waves emanating from it or something. :-) They're arbitrary, but the colors are chosen as a hash of the essid, which makes them consistently arbitrary. Your favorite network will always be the same colors, and a given network will be the same colors on everyone's machine. It's just a hint of an identifier, but it's a lot better than nothing. it's been pointed out that you can see your current network on the frame, but somehow that's not quite the same (to me). Yes, that's the preferred model. The Frame serves as a perpetual status element, and is instantly accessible no matter where you are within the UI. I'm open to improvements on the model. it wasn't until charlie came over and showed me the icon in the frame that i'd had the frame up at all today. but it's certainly a good place to go for status information. I hope that the Frame will see much more use as a result of the redesign; it's meant to be a crucial interface element, but until now hasn't had much utility. It will help when the notification system is integrated, since the act of connecting to a network will invoke a pulsing network icon in the corner of the screen, which will then slide into the Frame as a hint at where to go to find it later. i'm also not sure how to disconnect from that network -- there's no disconnect option in the popup anymore. Well, that's a bug, but not really. The problem is that there is no notion of disconnect in network manager at all. The old behavior used to switch into mesh mode, which disassociated with the network itself. However, we now have a more direct means of accomplishing this, via turning the mesh device on or off explicitly. It doesn't make sense to compound i'm not sure what you mean by turning the mesh device on or off explicitly, at least in terms of the current UI. is that the Radio: checkbox in the Network control panel? There has been lots of confusion about the difference between mesh and APs. They're really not the same at all, apart from the fact that they both depend on the radio. The new design no longer treats the mesh channels as objects in the Neighborhood view. Instead, there will be (is? not sure if the patch landed yet) a mesh device in the Frame, which you can turn on (and off?) at whim. these. The more conventional option is something like turn wireless off to disassociate with the current network, but that assumes that there is no other potential use for the wireless at all. In our case we still have the mesh to worry about, so that again doesn't map onto our circumstances. i guess i'm thinking of it in traditional terms. if i'm browsing available nets, i might connect to a network by mistake, and want to disconnect without necessarily connecting to something else, and now it feels (rightly or wrongly) like i can't do that. i guess it's not very important, though. I'm trying to point out that your assumption isn't actually true. I'm not aware of a disconnect option which strictly disconnects from the current network. Instead, there is usually a turn off my ability to connect to any network, disconnecting from the current one in the process option. This isn't what we want, because one may want to disconnect from a network but remain on the mesh. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] current network differentiation?
On Thu, Jul 31, 2008 at 3:37 PM, Martin Dengler [EMAIL PROTECTED]wrote: On Thu, Jul 31, 2008 at 03:23:47PM -0400, Eben Eliason wrote: The new design does not make any indication of which network is presently associated in the Neighborhood view; perhaps we can find an alternative method. Thoughts? Perhaps the currently-associated network's icon can appear below the XO icon, as the Journal does initially in the Home view. Could be tricky, since (hopefully soon) the view will be fixed so that the current activity is beneath the XO, consistent with the Home view. There may be other options, though. i'm also not sure how to disconnect from that network -- there's no disconnect option in the popup anymore. Well, that's a bug, but not really. The problem is that there is no notion of disconnect in network manager at all. cjb suggested to me on IRC that Disconnect/Turn Off (for wireless/mesh, respectively) could just cut power to the radio. I then suggested that this would work if the restoration of power was quick enough that switching to the Neighborhood view could power back on the radio and update the icons in some acceptable lag. Again, I don't think this is really the desired semantic. It's /almost/ right, and is the traditional means of achieving this, but that also turns off the ability to be on the mesh, which isn't necessarily what one means by disconnect from this AP. They should be independent. I realize this isn't as crucial right now, since we can't be on both mesh and AP at the same time, but in the future it's pretty clear that they need to be orthogonal. I have implemented[1] and tested this behavior (as part, but not a necessary part, of #6995) and I believe it fast enough for further investigation and testing. The only problem is that it's very cumbersome to bring back up the msh0 interface correctly, and would require some code changes in a variety of places in sugar. Interesting. This problem (and it affects Extreme power mode too) is recorded in #7690. The old behavior used to switch into mesh mode, which disassociated with the network itself. This is much less desirable than powering off the wireless, IMO. I agree. That's why there's no longer a disconnect option. We thought it was better to remove it until it has a proper semantic, rather than implement it in a peculiar and not readily understandable way. - Eben However, we now have a more direct means of accomplishing this, via turning the mesh device on or off explicitly. This is spec'd but subject to #7690, IIUC. - Eben Martin 1. Some example entry points: wlan_radio.py: http://dev.laptop.org/git?p=users/mdengler/sugar;a=blob;f=src/hardware/wlan_radio.py;h=47b70474fe503e90d74c4aecf5ed4cd1992f8412;hb=4a455159e61ac2ce1ed47059dccf5a8ba18ebd80 MeshBox.pyhttp://dev.laptop.org/git?p=users/mdengler/sugar;a=blob;f=src/hardware/wlan_radio.py;h=47b70474fe503e90d74c4aecf5ed4cd1992f8412;hb=4a455159e61ac2ce1ed47059dccf5a8ba18ebd80MeshBox.pychanges (last last diff block): http://dev.laptop.org/git?p=users/mdengler/sugar;a=commitdiff;h=4a455159e61ac2ce1ed47059dccf5a8ba18ebd80 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] patch for a first boot launch of a Help activity
On Thu, Jul 31, 2008 at 11:29 PM, FFM [EMAIL PROTECTED] wrote: Maybe somewhere in the frame (forever, thus able to provide contextual assistance in the future), or as a throbbing icon on the home view (just for the first launch)? All of our initial discussions on help focused around a contextual help system, and I still hope that this is where we'll be taking this in the future. By embedding (?) icons within the secondary palette menus for various devices, objects, activities, and even individual buttons and controls, we can provide a way to launch into the help activity and dive directly to the relevant info for the activity, control, etc. selected. In addition, I'd like to support a community driven help system by which, in addition to the activity/olpc provided help, it's possible for kids to add tips, tricks, images, tutorials, and other info to these sections for later consumption by peers. This is a noble, but ambitious goal, which is why a simple and static help activity is the present solution, and why it's only integrated into the system at a single point - the activity itself. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Programming environments on the XO
On Wed, Jul 30, 2008 at 12:24 PM, Tomeu Vizoso [EMAIL PROTECTED]wrote: On Tue, Jul 29, 2008 at 12:44 PM, Martin Sevior [EMAIL PROTECTED] wrote: On Fri, 2008-07-18 at 14:50 +1000, Martin Sevior wrote: On Thu, 2008-07-17 at 23:32 -0400, Brian Jordan wrote: The open source project Gobby also uses this sort of who-wrote-what text highlighting, SJ and I have recently (right before he left for Wikimania) been looking into getting similar functionality on the XO. Having this highlighting integrated with Write would be fantastic. OK Guys, I get the message :-) I'll look to see how this can be enabled by default in the most UI-easy way possible. OK Guys, Your wish is my command. See: http://msevior.livejournal.com/2008/07/29/ Awesome, anybody would like to expose this functionality in Write? Should be quite easy, but may involve adding API to abiwidget. The original mockups for Write have been waiting for this moment to arrive. For the reference of any who dare to take on the task (The button being clicked is a Highlight text by author button): http://wiki.laptop.org/go/Image:Activity_write_view.jpg - Eben Thanks a lot, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Killing hung activities
Indeed, the need for this has been expressed in a long forgotten ticket. I do think it's something we should support in some fashion, and something worth a look for 9.1. More comments on the ticket: http://dev.laptop.org/ticket/1166#comment:8 (The in the ring activities mentioned are now in the top edge of the frame.) - Eben On Tue, Jul 29, 2008 at 5:35 AM, Bernie Innocenti [EMAIL PROTECTED]wrote: Today I was testing Paing in Joyride and managed to hung it in a way that hogs the CPU. There seems to be no way to kill such an activity from Sugar. Stop just tries to close the X window, which is ineffective in such cases. We'd need to fire a timer to check if the activity is still there after a few seconds and, in that case, send a SIGKILL. A safer design would pop a Wait/Force Quit window before proceeding. -- \___/ Bernie Innocenti - http://www.codewiz.org/ _| X | Sugar Labs Team - http://www.sugarlabs.org/ \|_O_| It's an education project, not a laptop project! ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] inconsistent identification regarding full-screen sessions
On Mon, Jul 28, 2008 at 6:49 PM, Mikus Grinbergs [EMAIL PROTECTED] wrote:
FYI - I am not writing a ticket at this time (until I can reproduce
consistent misbehavior). G1G1. Joyride manually updated to 2216.
Fair enough. It sounds like we need to tease it apart a bit first; there
might be 3 or 4 separate tickets lurking here...
My biggest confusion arises because I __cannot visually tell__ which
icon in the Frame top bar is associated with which running task.
I did not want to tie up a whole Terminal session to a job which can
peacefully run in the background -- so I normally start such a job
(from Terminal) by appending '' to the command. Afterwards, I can
enter other (foreground) commands using that same Terminal session.
So, first things first: Is it appropriate to represent each process started
from a Terminal session as a separate activity in the Frame? There are
definitely pros and cons. On one hand, they clearly aren't activities (or,
perhaps if they have GUI representations, they are?), and therefore don't
really belong as separate icons in the Frame, which are meant to represent a
unique virtual place which can be reached through the UI. On the other
hand, having them appear there serves as a fairly nice task manager of sorts
(assuming, of course, we actually handle them in a logical and consistent
way such that they can be distinguished and stopped.
Happened to call up Frame. Noticed in the top bar a NUMBER of small
dark circle icons. Turned out that when I clicked on one of these
small dark icons, the frame top bar highlight shifted to that icon
(and a drop-down palette was shown, offering 'Resume' and 'Stop' --
but not identifying what session/task that icon was for).
Not wanting to have these small dark circle icons in my Frame top
bar, I clicked on 'Stop' in the palette in several of them. Did NOT
see any of the small dark circle icons go away. [But afterwards, I
found out that my background job had received a signal 11.]
You mention that the 'Stop' action did terminate the process, but that
wasn't reflected (that's likely worth a ticket). This is likely because
they didn't map to windows which could be closed (but I don't know any
details here). What happens if you instead press 'Resume'? Nothing? Or do
you wind up back in the initial Terminal session? If we choose to support
such processes in this manner, could 'Resume' be clever enough to reveal the
Terminal and fg the process? Would you want it to?
Speculation: After I have started the background job, I start a
full-screen (ported Linux) application from that same Terminal
session. If I now enter a sequence of alt-tab presses, sometimes I
see just the full-screen application (in its proper place in the
sequence of session screens being shown), but sometimes I see
__BOTH__ the full-screen application and (on a SEPARATE screen in
the sequence of screens) the Terminal session from which I launched
the full-screen application. I think it likely that when two
screens get thus shown for what was just a single Terminal session,
the extra screen (is it the 'full-screen'? I don't know) gets
represented in the Frame top bar as a small dark circle icon.
Could you clarify this a bit for me? At what point do multiple screens
arise? Do you mean: sometimes when I launch multiple processes from a
Terminal session I get multiple icons in the Frame or sometimes, after I
launch multiple processes from a Terminal session, alt-tabbing /reveals/
multiple icons in the Frame?
If my speculation happens to be true, then I see 3 inconsistencies:
- If the full-screen application sometimes shows up as an extra
screen, and as an extra icon within the Frame top bar, it
should *always* show up that way.
Agreed. Consistency is needed. Either we support it, or we don't. If we
do, we need to support the available actions ('Stop', 'Resume', etc.) or
remove them completely.
- If running a full-screen application can cause an extra icon
on the Frame top bar, then when the full-screen application is
exited (goes away), its extra icon in the Frame top bar should
'go away as well. [Today my Frame top bar had a considerable
number of small dark circle icons, presumably created on earlier
occasions when I started (and stopped) that full-screen
application. Yet at any one time I had run only a single
instance of the full-screen application, plus the one background
job.]
Yup.
- If running a full-screen application can cause an extra icon
on the Frame top bar, then that icon should be *labeled* with
the name of the command that started that application. [Also,
I normally have two Terminal sessions active -- but I have
filled in the label in the Application top bar to distinguish
between them. Yet when I hover over the icons in the Frame top
bar, both say 'Terminal Activity' instead of using my labels.
Re: [sugar] patch for a first boot launch of a Help activity
My personal opinion on the matter is that we shouldn't be doing the launch automatically, but others are welcome to disagree. =) I think the presence of a nice, clean, question mark icon on the Home screen after boot will be plenty for those that want to jump into help right away, and instilling the Home zoom level as just what it is -- Home -- is equally important. Particularly because of the fullscreen nature of the activities (and the new launcher itself), I actually think it would be more disorienting to be driven directly into the help activity. I'm not sure the decision was finalized, as the ticket you worked from didn't make it clear one way or the other. Thanks for your hard work, either way! - Eben On Tue, Jul 29, 2008 at 10:12 AM, Bobby Powers [EMAIL PROTECTED]wrote: On Tue, Jul 29, 2008 at 5:42 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: I think the agreement when we met about this was to *not* autolaunch the activity. Eben? that could certainly be. it was a fun little project for an hour, and I wasn't aware a decision was reached on whether or not to autolaunch it. bobby Marco On Tue, Jul 29, 2008 at 5:57 AM, Bobby Powers [EMAIL PROTECTED] wrote: Hello, after talking with Seth this evening, I whipped together a small patch (against the current git heads of sugar and sugar-toolkit) to launch an activity with the service name of org.laptop.Help on the first boot of the XO. It checks the user profile for a field called 'ShowHelp' in a category 'FirstBoot', which doesn't exist on the first launch. I know this has been talked about for G1G1, does anyone have any better ideas of how to do this? yours, Bobby ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity name box is too small for localized name
This can be fixed globally, and really, it seems there's no reason for it to be so small. There's room. Could you file a new ticket in trac ( http://dev.laptop.org/) and assign it to the Sugar component? Thanks! - Eben On Mon, Jul 28, 2008 at 10:55 AM, Korakurider [EMAIL PROTECTED] wrote: Hello. It seems that size of name box in top of activity tab in each activity is designed so that English name fit there, and is sometimes small for localized name. See attached screenshot (Write activity) for instance. Is there any way to adjust size of the box of activities globally so that the name is completely shown, or do we need to ask each activity author for change? Thanks in advance. /Korakurider ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] pulsing icon code move from sugar to sugar-toolkit?
On Mon, Jul 21, 2008 at 6:49 AM, Martin Dengler [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 11:49:31AM +0200, Marco Pesenti Gritti wrote: On Mon, Jul 21, 2008 at 7:37 AM, Martin Dengler [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 12:45:16AM +0200, Marco Pesenti Gritti wrote: [...] What user visible feature does it allow to implement? #6995 ( http://dev.laptop.org/ticket/6995 ) - move mesh icon to the frame, and its concomitant make AP and mesh icons pulse and otherwise consistent with Mesh/Neighborhood view's icons work. Yeah, but what if we implement all of that except the pulsing? This is easily doable. True. Is it something we can add incrementally in the next release? Yes. True. This is also a question for Eben. Understood. But... I cringe to think of not having this feedback. Network/mesh behaviors have been a real sore spot in the UI, with confusing icons, indistinguishable states, and lack of feedback. I really think we need some kind of indication when these devices are connecting/disconnecting, and pulsing is the metaphor we've used everywhere else (and is already being used in the Neighborhood view for APs). I'd vote strongly in favor of finding a way to make this happen before we release this. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] pulsing icon code move from sugar to sugar-toolkit?
::sigh:: ok. =) On Mon, Jul 21, 2008 at 11:38 AM, Marco Pesenti Gritti [EMAIL PROTECTED] wrote: On Mon, Jul 21, 2008 at 5:32 PM, Eben Eliason [EMAIL PROTECTED] wrote: But... I cringe to think of not having this feedback. Network/mesh behaviors have been a real sore spot in the UI, with confusing icons, indistinguishable states, and lack of feedback. I really think we need some kind of indication when these devices are connecting/disconnecting, and pulsing is the metaphor we've used everywhere else (and is already being used in the Neighborhood view for APs). I'd vote strongly in favor of finding a way to make this happen before we release this. Let's evaluate them separately. We first land a patch without pulsing and then we figure out how/if we can add pulsing, OK? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Question about clipboard service
I can't tell from your wording if you are implying that we will or will not be creating some custom wrappers for the clipboard service. I think we absolutely need them to accomplish several critical clipboard issues (among them, specifying icons, colors, titles, and previews for clippings). In fact, getting this API working effectively is high on my list of priorities for 9.1 - Eben On Sat, Jul 19, 2008 at 4:19 AM, Tomeu Vizoso [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 10:29 PM, Faisal Anwar [EMAIL PROTECTED] wrote: Hi, I'm playing around with the clipboard package on sugar and had a quick question. So, the clipboardservice.py file shows some basic api for getting and setting objects on the clipboard through the dbus. However, the add_object and get_object methods (and their variants) rely on knowing an object_id in order to retrieve something from the clipboard. Typically, a clipboard has some stack like structure where you can automatically retrieve the last thing copied to the clipboard without necessarily knowing its internal id. This would seem especially important fo passing things to other activities, which can't reasonably figure out the object_id created when something is saved to the clipboard by another activity. Does anyone know how to just retrieve the last item saved to the clipboard and also get a list of the last N items saved to the clipboard? Also, the gtk.Clipboard framework allows access to several different clipboards that have slightly different purposes. Is there similar functionality available through sugar/dbus or would one go directly to the gtk implementation? Hi Faisal, we haven't reached any agreement yet about exposing a different clipboard API than the one in gtk+ (that wraps around the different clipboard-related specs used in X). In other words, nobody other than the shell should directly use the clipboard service and this will probably disappear in the future. Activity authors should the use the clipboard functionality as exposed by their toolkits (gtk+) or implement themselves those specs (as etoys has done). Can you add this note somewhere in the almanac? Thanks, Tomeu ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] URL and Integration
/me feels silly. =) On Sat, Jul 19, 2008 at 2:04 PM, Michael Stone [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 09:31:24PM -0400, Eben Eliason wrote: On the other hand, maybe what we need more is a forum space. You do realize that both forum.laptop.org and the OLPCNews forum have been up and running for months (years?) with thousands of replies? Michael ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
