| Time | Nick | Message |
|---|---|---|
| 10:14 | cms | tomeu, do you want to give us an overview of the issues being discussed? |
| 10:14 | tomeu | cms: about the home view? |
| 10:14 | or all of them? | |
| 10:14 | cms | actually, i was thinking more of the topics for today |
| 10:14 | tomeu | ok |
| 10:15 | so about the home view, http://dev.sugarlabs.org/ticket/806 is only about children deleting all activities | |
| 10:15 | we should ask for feedback as well about the usefulness of favorites | |
| 10:15 | cms | the home view is a separate discussion, though the ticket points out an important defect |
| 10:15 | tomeu | right |
| 10:15 | cms | i agree that the similarity between the journal and list view is confusing |
| 10:16 | tomeu | we cannot expect to be given a new design from olpc-sur, but they can point out aspects that are important and we overlooked |
| 10:16 | cms | we need to find a solution to the problem, which i think will be more structural than visual |
| 10:16 | tomeu | the fact that they feel compelled to delete stuff is also interesting |
| 10:16 | bemasc | it's worth pointing out that 806 could be solved by simply disabling deletion from that menu |
| 10:16 | cms | that's true--it is not something we wanted sugar to encourage |
| 10:16 | walterbender | we also need to consider the idea of tags to bring different homeviews into play |
| 10:16 | tomeu | yeah, may be good to find a short term solution for the 8.2.x branch |
| 10:16 | bemasc | It would be a very simple patch to remove the "delete" menu item. |
| 10:16 | eben | walterbender: yeah, we're working on those mockups. |
| 10:16 | garycmartin | bemasc: yes and moving managment of bundles to the Journal where is should realy be. |
| 10:17 | tomeu | but we should be using this feedback for the home view redesign we have already talked aobut |
| 10:17 | bemasc | garycmartin: I mean this only as a way for Uruguay to quickly prevent this problem from spreading, not as a "design solution". |
| 10:17 | eben | Right, if we always show activities in the Journal, then they can be managed from there. |
| 10:17 | The naming issue is another one which we've had a proposed solution to for a long time, and it just hasn't been done. | |
| 10:17 | tomeu | bemasc: dsd has find a solution for .py: making easier to reinstall the activities |
| 10:18 | using the activity updater (that we don't have in 0.84, btw) | |
| 10:18 | cms | eben: that makes sense--but it also removes activity management from home (that might be a good thing, but something to consider) |
| 10:18 | eben | cms: Well, right. That was the point. |
| 10:18 | bemasc | please, let's not discuss this now. Tomeu, could you just list the topics on the agenda today? |
| 10:18 | eben | Make the Journal the one-top "file manager", and leave Home as a place to launch stuff. |
| 10:18 | cms | eben: i'm not sure it is the right solution, from an experiential standpoint |
| 10:19 | i agree--let's save this topic for the next meeting | |
| 10:19 | it warrants more time than we have today | |
| 10:19 | tomeu | ok |
| 10:20 | Sayamindu's dictionary dialog. See http://www.mail-archive.com/su[…]org/msg04042.html | |
| 10:20 | cms | should we start with the clock activity? |
| 10:20 | eben, you mentioned you had mockups to share | |
| 10:20 | tomeu | was going in the order in http://wiki.sugarlabs.org/go/Design_Team/Meetings |
| 10:20 | cms | sorry--that's fine |
| 10:20 | tomeu | as you prefer |
| 10:20 | the disctionary is quite simple, just read that thread and see sayamindu's mockup | |
| 10:20 | cms | sure |
| 10:20 | eben | can someone link to screenshots of the dictionary proposal? I can't play that movie file. |
| 10:21 | tomeu | I can screenshot it |
| 10:21 | eben | thanks |
| 10:22 | bemasc | eben: you probably want http://www.xiph.org/quicktime/ |
| 10:22 | tomeu | http://shell.sugarlabs.org/~to[…]lla%20Firefox.png |
| 10:23 | this is the dialog | |
| 10:23 | the sentence in blue is what was selected when the dialog was invoked | |
| 10:23 | cms | that looks pretty good |
| 10:24 | we can clean up the typography | |
| 10:24 | walterbender | It wasn't obvious to me why there is this one level of indirection: select a sentence and then a word |
| 10:24 | tomeu | I guess sometimes that's what you want, sometimes not |
| 10:24 | bemasc | walterbender: if you select only one word, then it should (and perhaps does) just show the definition. |
| 10:24 | tomeu | maybe we could autoselect the first word? |
| 10:24 | eben | walterbender: Yeah, it would be more direct if it just worked on word level. |
| 10:25 | cms | eben: i agree |
| 10:25 | unmadindu | does not like the sentence thing as well :) |
| 10:25 | bemasc | There's no way to prevent the user from selecting more than one word |
| 10:25 | tomeu | actually likes it ;) |
| 10:25 | walterbender | eben: does it work with phrases too? |
| 10:25 | eben | walterbender: few dictionaries have phrases, though. |
| 10:25 | yoshu | I like the sentence thing |
| 10:25 | cms | perhaps instead of being based on selection it is a toggle |
| 10:25 | eben | cms: ? |
| 10:25 | unmadindu | eben: uploaded to youtube: http://www.youtube.com/watch?v=wlnnw3haxds |
| 10:25 | cms | to allow you to select only individual words |
| 10:25 | eben | unmadindu: sweet, thanks |
| 10:26 | cms | the issue seems to be how to invoke the dictionary, and currently it's based on selection |
| 10:26 | bemasc | It has to be based on selection, because that is the X Selection mechanism is the only way the dictionary knows the text. |
| 10:26 | walterbender | in any case, it is a great feature... I was picking nits |
| 10:26 | tomeu | yeah, using the x selection is a very clean mechanism that we should keep, I think |
| 10:26 | eben | I guess the sentence structure isn't a problem...it''s a fair solution for a selection of multiple words. |
| 10:26 | cms | but it could also be a toggle button in the toolbar (similar to a help button), that brings up clarification for any word that is selected |
| 10:26 | eben | If you select one, it behaves the "simple" way. |
| 10:26 | tomeu | that makes no need to implement anything in the activity level |
| 10:27 | cms | well-- |
| 10:27 | walterbender | maybe just define all the words selected? |
| 10:27 | cms | i think i agree with walter and eben though, that it doesn't seem intuitive to parse an entire selection |
| 10:27 | tomeu | cms: because of the implementation, it should be a global action, so not triggered from the activity window |
| 10:27 | eben | cms: Toolbar is one option. A persistent device is another. |
| 10:27 | tomeu | if it's in the activity, then each activity that wishes to benefit from it needs to implement something |
| 10:27 | cms | it's usually a single word you are looking for clarification on |
| 10:27 | eben | It would be nice if it "just worked" for all activities. |
| 10:28 | tomeu | something in the frame would be better |
| 10:28 | garycmartin | unmadindu: If you spell check a selection from a view source window (hey perhaps a python term dictionary could go in there as well ;-) ) do the modal dialogues conflict? |
| 10:28 | eben | Right. |
| 10:28 | bemasc | cms: if you select a single word, then there is no problem. |
| 10:28 | tomeu | if it's a global action such as view source, it will just work for all activities |
| 10:28 | I think that's very important | |
| 10:28 | unmadindu | garycmartin: good catch - I think they would. I'll have to check :) |
| 10:28 | cms | bemasc: that's true, but it seems potentially confusing to have more functionality than that |
| 10:28 | eben | cms: Not necessarily. |
| 10:28 | walterbender | if it is a python keyword or module name... |
| 10:28 | cms | bemasc: i.e., i don't know a case in which one would actually want to select an entire sentence |
| 10:28 | eben | cms: What would it do with a multiple word selection? |
| 10:28 | tomeu | walterbender had good ideas about how to use the frame instead of a modal dialog |
| 10:29 | eben | Just refuse to work? Pick the first word? |
| 10:29 | bemasc | cms: inter-language dictionary, trying to work out a sentence in a foreign language. |
| 10:29 | cms | eben: right, but why would you need to select multiple words? |
| 10:29 | tomeu | should we move to the next topic? everybody seems to be well aware of the problem now |
| 10:29 | eben | While the sentence structure is a little unfamiliar, it's actually an interesting solution, and could work if it looked a little better than blue hyperlinks. :) |
| 10:29 | bemasc | I do think it needs an indication for which word is currently being viewed. |
| 10:29 | cms | eben: i need to give it some more though |
| 10:30 | eben | cms: Who cares? If you do happen to, isn't this a reasonable thing to do with them? |
| 10:30 | bemasc | and I do think it should default to the first word if multiple are selected. |
| 10:30 | eben | If you just select one word, as most people will, it will behave exactly as we'd expect. |
| 10:30 | cms | eben: i don't know--i think it may be more intuitive to restrict it |
| 10:30 | eben | bemasc: Yes, that's the other logical option, I think. |
| 10:30 | unmadindu | maybe we can use back/forward buttons to switch between words ?? |
| 10:31 | cms | the implication for making a selection is translation |
| 10:31 | whereas dictionary does seem to apply more to individual words | |
| 10:31 | eben | Where does the dictionary content come from? Can we rich-text style it? This version looks a little overwhelming because it's all plain text with no spacing... |
| 10:31 | cms | maybe if we had a built-in translation functionality...? |
| 10:31 | unmadindu | eben: we can (to some extent at least) |
| 10:32 | cms: +1 on that - I'll look if there are tools which can be used in the backend to do that | |
| 10:32 | eben | cms: Yes, that would also be fantastic. And it could be the same feature, actually... |
| 10:32 | tomeu | should we move on? |
| 10:33 | eben | tomeu: I'm not sure we decided where this should live... |
| 10:33 | cms | tomeu: sure |
| 10:33 | bemasc | machine translation is not easy. The only way to do it is basically to use Google. |
| 10:33 | cms | bemasc: that would be fine, i think... |
| 10:33 | tomeu | eben: I thought we were just giving a quick overview of all issues |
| 10:33 | eben | Should it be a shortcut? A Frame device? If it's a Frame device, can I open it without a selection and just type in a word to look up? (I'd say yes.) |
| 10:33 | cms | bemasc: it would still be helpful, and would extend the dictionary functionality |
| 10:33 | bemasc | So, I floated an idea on the list: that these things should live in the Frame. |
| 10:33 | eben | tomeu: Oh...ok, that's fine. |
| 10:34 | bemasc: Yeah, that's my inclination as well. | |
| 10:34 | tomeu | so, mtd_ has proposed adding an icon in the frame and we have asked people in opc-sur about it |
| 10:34 | cms | eben: where do you see it in the frame? i have my doubts... |
| 10:34 | tomeu | s/icon/clock |
| 10:34 | bemasc | Right, the problem is: it's not a "device". |
| 10:34 | eben | cms: In the bottom edge, next to "speak text" and other similar tools. |
| 10:34 | cms | eben: doesn't this make more sense in the toolbars? |
| 10:34 | cahalan | for a dictionary or a clock? |
| 10:34 | tomeu | as the dictionary works on a text selection, it could be in the clipboard |
| 10:35 | cahalan: I think we are still in the dic | |
| 10:35 | eben | cms: Not really....then it's not consistent across all activities. |
| 10:35 | cms | tomeu: that's a great idea |
| 10:35 | tomeu | eben: do you know how text selections work in X? |
| 10:35 | bemasc | Maybe it could go on the bottom bar, but starting on the left side? |
| 10:35 | tomeu | you will need to know that stuff to make a design that involves the x selection and the clipboard |
| 10:35 | cms | it would make sense to combine with the clipboard |
| 10:35 | walterbender | aside: we should think about how to interface all of this with accessibility tools as well |
| 10:36 | eben | cms: I don't think I agree. |
| 10:36 | cms | eben: why not? |
| 10:36 | tomeu | walterbender: yeah, I'm curious about xo 662 |
| 10:36 | eben | That confuses the purpose of the left edge...it's just a storage space. If you start adding several custom features, it takes away space from the clipboard and you won't know what's a clipping and what's a button. |
| 10:36 | tomeu | need to look at it |
| 10:36 | cahalan | eben: the x selection and clipboard is more compatible |
| 10:37 | tomeu | eben: read about x selections and you may come with a solution that you like |
| 10:37 | eben | I think the dictionary is more like a persistent tool, like speech, or a clock, etc. |
| 10:37 | cms | eben: i see your point. |
| 10:37 | unmadindu | had to shut the clipboard up temporarily to make the dictionary work |
| 10:37 | tomeu | unmadindu: I think we can fix that |
| 10:37 | cms | eben: so you see it more as a device |
| 10:37 | garycmartin | eben: +1, for a persistant tool. |
| 10:38 | eben | cahalan: I understand the technical similarities that go with acting on a selection, but looking a word up in the dictionary has nothing to do with storing it in a temp location for later use. |
| 10:38 | cahalan | eben: "later use" == "look it up" |
| 10:38 | bemasc | X makes a very hard distinction between the clipboard and the selection. |
| 10:38 | eben | cahalan: No, "look it up" == "take an immediate action on this selection, and then I'm done with it" |
| 10:38 | cms | eben, i think i agree, though one could perhaps contemplate extending the clipboard section to include other tools for working with text |
| 10:38 | eben | the "later use" storage is the brain of the child learning the meaning of the word. :) |
| 10:39 | cahalan | bemasc: right, any sane code will shove data into both to mitigate the disaster :-( |
| 10:39 | eben | cms: But the clipboard isn't just about text... |
| 10:39 | cms | but perhaps it's cleaner to keep as a device in the frame (even though the metaphor doesn't quite work) |
| 10:39 | bemasc | cms: for that reason, I think the "tools" should grow from the left side of the bottom edge, and the "devices" should grow from the right side. |
| 10:39 | cms | eben: right, but not sure that really matters |
| 10:40 | bemasc | This places them in proximity to the clipboard, and also creates a (soft) distinction to indicate that they are of slightly different types. |
| 10:40 | cms | bemasc: i do think we need to stick to the organizational methods we currently have in the frame |
| 10:40 | bemasc: worried it would become too cluttered if we started running tools from both sides | |
| 10:41 | cahalan | eben: it makes more sense if you consider the way copy-and-paste works in the traditional X UI. The "copy" operation is merely a mouse movement to select the text. There is no ^C. |
| 10:41 | tomeu | people, it's 40 minutes since we started |
| 10:41 | eben | cms: Yeah, and then what happens when they meet? Heh. |
| 10:41 | tomeu | we are not going to deal with everything |
| 10:41 | eben | OK, let's move on. |
| 10:41 | bemasc | eben: the same thing that would happen if the number of devices exceeds the available space. |
| 10:41 | tomeu | ok, clock |
| 10:42 | eben | Let me paste links to my (rough) mockups. |
| 10:42 | tomeu | martin has proposed adding a clock to the frame and we have asked people in olpc-sur about it |
| 10:42 | olpc-sur is our main way to get feedback about sugar, specially about 0.82 | |
| 10:42 | cahalan | should provide seconds during mouse hover |
| 10:42 | eben | https://dl.getdropbox.com/u/10[…]digital_basic.jpg |
| 10:42 | https://dl.getdropbox.com/u/10[…]ital_settings.jpg | |
| 10:43 | cms | eben: suggestion: can't we use the analog clock icon instead? |
| 10:43 | eben | https://dl.getdropbox.com/u/10[…]ital_calendar.jpg |
| 10:43 | https://dl.getdropbox.com/u/10[…]/clock_analog.jpg | |
| 10:43 | tomeu | last proposal from mtd here: http://www.mail-archive.com/su[…]org/msg03996.html |
| 10:43 | cahalan | maybe more... default: HH:MM With mouse hover: HH:MM:SS.S |
| 10:43 | cms | the analog clock looks good |
| 10:43 | eben | Yeah, I included an analog mockup. I like it the best in terms of appearance in the frame, but it's not the most easily readable. That might be OK. |
| 10:44 | cms | eben: i think that's fine, as you can rollover and see the exact time |
| 10:44 | eben | We could simply show digital on hover, as in the analog mockup, and omit the digital option in the icon... |
| 10:44 | bemasc | I really don't understand the desire for analog clocks |
| 10:44 | garycmartin | cms: yep + one for analogue, I was thinking to let mtd do all the hard word and add an analoge mode myself later :-) |
| 10:44 | cahalan | cms: analog clocks are slowly passing into history, they vary across culture, etc. |
| 10:44 | bemasc | Outside the first world, analog clocks are dead |
| 10:44 | tomeu | do you want to hear what said the teachers in .uy about the clock? |
| 10:45 | eben | tomeu: please |
| 10:45 | cms | i'm partial to the analog clock because it works within the square icon module (and also looks more elegant!) |
| 10:45 | bemasc | cms: form over function is always a bad idea. |
| 10:45 | yoshu | analog clock fits nicely with the ui |
| 10:45 | tomeu | one person said that there should be no clock widget, but a clock activity that teaches various topics about time |
| 10:45 | cms | bemasc: not always... ;) |
| 10:45 | tomeu | the rest of the people said that they wanted a clock in the inferior frame |
| 10:45 | cms | tomeu: that isn't a bad idda |
| 10:46 | tomeu | several also requested it to display the date |
| 10:46 | cms | i think generally this makes sense in the frame, as a "device" |
| 10:46 | tomeu | one person requested it to be analog as well, in order to teach analog clocks, but I think that could be in the Clock activity (we already have it) |
| 10:46 | eben | cms: Yeah, I agree. (That doesn't preclude a clock activity, which we already have in fact) |
| 10:47 | tomeu | we have also been asked for a chronometer |
| 10:47 | garycmartin | I was always told reading analogue face helped with other math concepts. |
| 10:47 | cms | eben: i think whether digital or analog, the icon needs to fit within the square module |
| 10:47 | tomeu | so kids can measure the time it takes to them to do something in some activity |
| 10:47 | bemasc | tomeu: There's already a stopwatch activity. |
| 10:47 | eben | cms: I agree. |
| 10:47 | It's a little tight, but I think it can work. | |
| 10:47 | tomeu | though that perhaps should be integrated in each activity |
| 10:47 | walterbender | eben: why doesn't a multiple of the 75x75 work? |
| 10:47 | tomeu | bemasc: we should tell them |
| 10:47 | bemasc | oh |
| 10:47 | cms | eben: you could stack the digits...? |
| 10:47 | tomeu | bemasc: maybe the activity team should adopt it if it's orphaned |
| 10:48 | cahalan | Analog still needs 12-hour and 24-hour variants. I believe it also needs a 6-hour variant somewhere in SE Asia. |
| 10:48 | eben | walterbender: because then we give device developers freedom to make arbitrarily large devices. The grid is a rule that's never been broken to date, and it would be nice to keep things simple. |
| 10:48 | bemasc | tomeu: I wrote it. It works. |
| 10:48 | tomeu | bemasc: ok, we need to publicicze it |
| 10:48 | cms | walter: i think a larger size starts to suggest that some activities may be more "important" than others, due to larger scale |
| 10:48 | eben | cms: I tried digit stacking. Looked really weird. |
| 10:49 | tomeu | eben: I think your proposal matches very well what's being asked |
| 10:49 | cms | eben: i'm still in favor of analog... especially since the exact time is visible on rollover. |
| 10:49 | cahalan | 75x75 can fit HH:MM just fine |
| 10:49 | bemasc | If you're going to provide an analog clock, you must at least make it optional |
| 10:49 | eben | cms: I'm in favor of analog by default, with a digital (still 75x75 px) option |
| 10:49 | walterbender | eben: then a device for hours and a separate device for minutes? |
| 10:49 | cms | https://dl.getdropbox.com/u/10[…]/clock_analog.jpg looks great |
| 10:49 | bemasc | cms: yes, it looks great, but you can't tell what time it is. |
| 10:49 | eben | walterbender: he heh |
| 10:50 | cms | bemasc: i think you can! |
| 10:50 | bemasc | cms: are you 9 years old? |
| 10:50 | eben | cms: I think we have to have a digital option. |
| 10:50 | cahalan | cms: oh that is truly awful; there are no numbers! |
| 10:51 | cms | eben: not sure we do |
| 10:51 | tomeu | we should take into account that frame devices are very easily modified, so we don't need to reach a solution that pleases everybody around the world: each deployer can put the implementation they want |
| 10:51 | cms | eben: again, it's in the rollover menu |
| 10:51 | cahalan | cms: an analog clock requires lots of numbers. There is not enough room for them. |
| 10:51 | yoshu | I think there should be a digital option - I like analog, but it might be hard to read for some |
| 10:51 | cms | cahalan: what's wrong with eben's mockup? |
| 10:51 | eben | cms: he's arguing that because there are no numbers....not even tick marks...it's hard to read. |
| 10:52 | cahalan | cms: I'm looking at https://dl.getdropbox.com/u/10[…]/clock_analog.jpg which has no numbers. |
| 10:52 | cms | eben: right, i know, but i don't think it's that hard to read |
| 10:52 | eben | Which is true. If you're not familiar with reading analog clocks, they are hard to read without at least an indication of the hours, if not the numbers themselves. |
| 10:52 | bemasc | for children, they're hard to read even with complete numbering |
| 10:52 | eben | cms: But you've been reading analog clocks for 25 years. |
| 10:52 | bemasc | even for adults they're significantly harder to read |
| 10:53 | cms | ok, as long as we stick with 75x75 |
| 10:53 | bemasc | I guarantee that any adult takes at least 3 times as long to tell you the time from an analog clock |
| 10:53 | 5 times as long if there aren't any numbers | |
| 10:53 | eben | I switched back to an analog watch a couple years ago, and my face has no numbers or tick marks....it took some time to adjust to, actually. |
| 10:53 | bemasc | I make this guarantee even for eben, who apparently wears such a watch every day. |
| 10:53 | tomeu | 53 minutes since the start of the meeting, should we move on (the biggest topics are yet to come)? |
| 10:53 | cahalan | bemasc: probably half a minute for me, since I've never owned an analog clock |
| 10:54 | cms | we can split hairs over which is better (functionality vs elegance) |
| 10:54 | tomeu: let's move on | |
| 10:54 | walterbender | eben: I was serious about two devices: hours & minutes |
| 10:54 | eben | cms: I think making it an option gets us past it. |
| 10:54 | We can make elegant default if we want to... | |
| 10:54 | cms | eben: agreed |
| 10:54 | cahalan | walterbender: they both fit in 75x75 |
| 10:54 | walterbender | cahalan: 75x75 each |
| 10:55 | tomeu | ok |
| 10:55 | bemasc | I don't think enormous numbers are necessary. All the other text in the UI is quite small |
| 10:55 | cahalan | walterbender: not needed; you can fit into 75x75 without making the font too small |
| 10:55 | eben | OK, I'll try to refine the mockup and post a more final version to the list. |
| 10:55 | cms | thanks eben! |
| 10:55 | tomeu | eben: tell me when you want feedback from olpc-sur |
| 10:55 | cahalan | 15x30 characters |
| 10:55 | eben | The small clock icon uses the "standard" system font size, btw. |
| 10:56 | tomeu | jameson is proposing changing the current rules for accelerators, and making them more pervasive: http://wiki.sugarlabs.org/go/D[…]s#Keyboard_Action |
| 10:56 | IMO, accelerators will make sugar much more usable for a considerable portion of our users | |
| 10:56 | walterbender | tomeu: for a growing portion of our users: the non-XO community |
| 10:57 | tomeu | walterbender: true |
| 10:57 | I haven't thought much about jameson's proposal, but really think we need to move forward regarding this issue | |
| 10:58 | bemasc | I don't think homunq means his proposal to be too strict. It's more of a starting point for discussion. |
| 10:58 | tomeu | jameson has proposed a rule to decide which accelerator modifiers are used and also proposed a way to make accelerators more discoverable |
| 10:58 | eben | I like the overlay idea...but I think it should be on a short delay (so it doesn't flash if you already know your shortcuts), and I don't like the idea of flashing on button press... |
| 10:58 | cms | can somebody explain this to me |
| 10:58 | tomeu | he proposes that when a modifier key such as <alt> is pressed, an overlay with the acclerator keys appear on each control that is activatable |
| 10:59 | bemasc | cms: there are two, mostly-independent components. |
| 10:59 | cms | this is a way for assigning keyboard shortcuts? |
| 10:59 | eben | Most of his basic ideas for ctrl, alt, and shift match our design intentions (there's a ticket somewhere spec'ing this). |
| 10:59 | cms: no...it's a way to discover them. | |
| 10:59 | bemasc | 1. A standard for assigning shortcuts, dividing up ctrl, alt, etc. |
| 10:59 | eben | A cheat sheet which appears overlaid on the UI when you hold a modifier key down. |
| 10:59 | cms | i see |
| 10:59 | bemasc | 2. A visual display so that when you press Ctrl, all the available Ctrl+* shortcuts appear. |
| 11:00 | tomeu | likes a lot the overlay idea, but is worried it may be hard to find a way that works fine without lots of added custom code |
| 11:00 | cahalan | it better not mess with Terminal |
| 11:00 | cms | that's nice. i think the visuals need refinement, but the general idea is great |
| 11:01 | walterbender | again, we should probably get an accessibility review |
| 11:01 | cms | do the left and right panels also appear only when i press CTRL? |
| 11:01 | eben | cms: Oh, where'd you finda mockup? |
| 11:01 | bemasc | cms: that's not a mockup of this |
| 11:01 | cms | ah |
| 11:01 | that explains my confusion | |
| 11:02 | there is no mockup? | |
| 11:02 | bemasc | there is no mockup |
| 11:02 | eben | oh, right...that's home stuff. unrelated. |
| 11:02 | tomeu | walterbender: we should get in contact with the people doing accessibility work in gnome (mostly sun) |
| 11:02 | garycmartin | I think this proposal need breaking down into individual items, it hits way to many things all over the place so I find it hard to agree with. |
| 11:02 | eben | Imagine a bunch of little rounded rectangles with letters in them, superimposed over the corresponding buttons in the UI when holding down a modifier key. |
| 11:02 | cms | eben: what are you looking at? |
| 11:02 | eben | cms: I'm not. |
| 11:03 | I'm painting you a mental image. :) | |
| 11:03 | cms | eben: i'm not following this discussion then |
| 11:03 | tomeu | garycmartin+++++ |
| 11:03 | cms | so the proposal is for key commands to appear on the view when you hit ctrl--that sounds like a good idea |
| 11:03 | tomeu | I'm finding very hard to follow people's proposals |
| 11:03 | bemasc | so you start an Activity, and you open the edit toolbar |
| 11:03 | but you've forgotten the shortcuts for copy and paste | |
| 11:04 | so you hold down Ctrl | |
| 11:04 | and "Ctrl+V" appears in a box on top of the Paste button. | |
| 11:04 | eben | bemasc: I'd say just the [v], but yeah. |
| 11:04 | cms | bemasc: that sounds good |
| 11:04 | eben | (since you're already holding control) |
| 11:04 | garycmartin | bemasc: for this use, the hover accelerators already provide this feedback. |
| 11:05 | bemasc | garycmartin: right. This is a faster-than-hover optimization. |
| 11:05 | cms | garycmartin: i think this could be an added benefit, in addition to hover states |
| 11:05 | garycmartin | bemasc: seems a small gain for what seems a lot of work. |
| 11:05 | bemasc | garycmartin: homunq is already doing the work. |
| 11:06 | tomeu | bemasc: homunq is doing the implementation, that's a small part of all the work |
| 11:06 | but anyway, I think the overlay is a superior way to give feedback about the accelerators than the tooltip | |
| 11:07 | but it would be already much much better than what we have now if all accelerators were set and showing in the tooltip | |
| 11:07 | eben | tomeu: Right...we should make that first priority. |
| 11:07 | garycmartin | tomeu: +1 |
| 11:07 | tomeu | so maybe the overlay can be seen as an optimization that can come later |
| 11:07 | eben | Getting a consistent ruleset for assigning shortcuts, and making them ubiquitous, is first order. |
| 11:07 | tomeu | yeah |
| 11:08 | eben | Optimizing their discoverability seems second to making them available and consistent. |
| 11:08 | bemasc | eben: I do not believe this is likely to be accomplished, especially because we are trying to support a wide variety of different keyboards. |
| 11:08 | tomeu | we have already stopped doing critical things because we couldn't agree on the advanced, less useful stuff |
| 11:08 | bemasc | Thankfully, we can proceed in parallel here. |
| 11:08 | cms | tomeu: do we have any other list items? |
| 11:08 | tomeu | cms: only print left |
| 11:08 | http://wiki.sugarlabs.org/go/D[…]m/Meetings#Topics | |
| 11:08 | cms | maybe we should move on to print--walter has to leave soon |
| 11:08 | tomeu | see the links there about printing |
| 11:08 | as well | |
| 11:09 | we have a gsoc student that is going to work on printing, and several members of the community that are enthusiastic about helping out | |
| 11:09 | on the other side, teachers in .uy have said that printing won't be very useful in thier schools | |
| 11:09 | bemasc | We have already debated this design to death, IMHO. |
| 11:09 | cms | a while ago, we had talked about printers appearing in the neighborhood, as networked devices |
| 11:09 | similar to access points | |
| 11:10 | tomeu | bemasc: to be true, I have never understood any of the proposals, I think we should get better at explaining our proposals |
| 11:10 | not everybody can put so much energy on these debates | |
| 11:10 | cms | eben: do we have any of those early mockups on the wiki? |
| 11:10 | bemasc | doesn't think any devices should appear in the neighborhood |
| 11:11 | cms | bemasc: explain? |
| 11:11 | tomeu | doesn't see printers appearing in the neighborhood as a critical part of the feature |
| 11:11 | bemasc | cms: we don't have time for this discussion. Basically, I think neighborhood, group, and home all need to be revised rather dramatically. |
| 11:12 | eben | cms: I don't think that we do, but the idea is simple enough. |
| 11:13 | bemasc | anyway, Vamsi is working diligently on this, and I think an iterative design process is probably best. |
| 11:13 | tomeu | I'm more interested on what the user does when she wants to print, rather than how to find a printer |
| 11:13 | cms | i think there is a larger discussion to be had, but given where we are currently, it makes sense that printers appear in neighborhood alongside people and access points |
| 11:13 | tomeu | at least 80% of the time, the printer will be connected directly to the xo |
| 11:14 | cms: I doubt sugar will be used often in environments with network printers in at least the near future | |
| 11:14 | cms | i suppose one could print from the activity dialog, or from the printer dialog (it would print the in-focus activity) |
| 11:14 | eben | cms: I think the neighborhood idea only makes sense if the printer is actually networked....if, for instance, the kid with the printer attached to his XO can allow others to print through him... |
| 11:14 | cahalan | tomeu: right, sadly -- network printers are complicated and expensive |
| 11:14 | tomeu | btw, teachers in .uy have noted that paper is part of the old way of doing things and that xos and internet access being ubiquitous make paper much less needed |
| 11:14 | bemasc | The biggest problem we have here is a lack of feedback from actual users. |
| 11:14 | eben | Like a mesh portal....a printer portal |
| 11:15 | cms | eben, tomeu: i agree with that |
| 11:15 | if connected directly to the XO, it probably should appear in the frame as a device | |
| 11:15 | bemasc | My high school had networked laser printers in all the computer labs. Is this common? I have no idea. |
| 11:15 | tomeu | bemasc: we have had quite a bit of feedback in olpc-sur in the last days |
| 11:15 | I guess will be different in each country | |
| 11:15 | eben | cms: like an AP, it probably would anyway... |
| 11:16 | bemasc | tries to subscribe to Sur again, after last attempt failed entirely. |
| 11:16 | cms | eben: exactly |
| 11:16 | tomeu | but for now, teachers have explained why printing won't work in their schools |
| 11:16 | eben | So, then the proposal here, really, is to make the attached printer appear in the Frame as a device (makes perfect sense), but then how does one print to it? |
| 11:16 | cms | ok, so if we assume that the printer appears as a device in the frame, one could either go to the printer dialog to print the in-focus activity, or accomplish the same thing from the activity toolbar |
| 11:17 | eben | Drag'n'drop? A print option in the activity menu? both seem logical, but both are entirely different than the proposals that have been talked about recently on the list (I think) |
| 11:17 | cahalan | eben: print button in the activity |
| 11:17 | tomeu | I see why using the neighborhood to show printers is very appealing design-wise, but I think it won't be useful at all |
| 11:17 | cms | cahalan: that's one solution--the other would be to print using the printer device in the frame |
| 11:17 | eben | cahalan: Sure. I think of the activity menu and the activity toolbar as synonymous. |
| 11:17 | cms: Actually, that direction is kind of confusing to me.... | |
| 11:17 | cahalan | cms: printer device in the frame sounds useful for managing print jobs, etc. |
| 11:18 | eben | But maybe if the button reads "Print 'A picture of my house'" it would work. |
| 11:18 | It could actually just have a submenu for all of the open activities which support printing. | |
| 11:18 | cms | i think it's a question of which comes first--printing an activity, or selecting print from an activity. that's why there might be two parallel ways to accomplish the same thing |
| 11:18 | cahalan | eben: well I **have** a print button |
| 11:19 | cms | eben: right |
| 11:19 | cahalan: i think a print button should also exist | |
| 11:19 | garycmartin | eben: is the journal still keeping it's bottom tool bar for showing sd and usb cards? Could the printer appear there, then you just transfer a pdf into it from the journal? |
| 11:19 | eben | Yeah, definitely not arguing against a print button in each activity. |
| 11:20 | garycmartin: No, that's the device edge of the Frame, now. | |
| 11:20 | garycmartin | eben: understood, I thought so. |
| 11:20 | tomeu | having a print button in each activity fits the gnome way, btw. and if we use that infrastructure instead of inventing our own, we'll be better off |
| 11:20 | walterbender | is still in favor of pushing all this to the realm of the Journal... |
| 11:20 | eben | Which is why the bottom edge of the Frame makes sense for the printer too....of course...the Frame is available from the Journal, so you can still do what you say. |
| 11:21 | bemasc | I think this sort of interactive design is best accomplished in a tight loop. |
| 11:21 | eben | walterbender: could you describe how that would work? |
| 11:21 | tomeu | walterbender: the problem I see with that is that it's harder that way to get the activities to participate in how the content is formatted for printing |
| 11:21 | cahalan | walterbender: the print button can certainly put something in the journal, via a command (/usr/bin/lpr for example) that the activity can invoke |
| 11:21 | bemasc | My main opinion here is: there's a tremendous amount of work needed to cover all use cases with printing. |
| 11:22 | Vamsi is going to do a piece of it, and I think we should observe the result and build from there. | |
| 11:22 | walterbender | However activities choose to format things, let the journal be the place where we manage the queue... |
| 11:23 | bemasc | walterbender: that depends on whether you see print jobs as creations or ephemera. |
| 11:23 | walterbender | bemasc: you are worried about journal spam? |
| 11:23 | bemasc | walterbender: right. |
| 11:23 | cahalan | walterbender: That works for me, as long as there is a command to stuff my postscript into the journal. Of course, then some poor kid will need to actually find it in his journal. |
| 11:24 | cms | using the journal to track print jobs makes sense |
| 11:24 | walterbender | cahalan: at some level each activity needs to make its own choices about how to export for printing... |
| 11:24 | tomeu | bemasc: I'm ok with taking a progressive approach, but if we can help telling what's the approach that will bring the biggest benefit, now is the best moment |
| 11:24 | cahalan | bemasc: print jobs **being** spam, or being lost among spam? (IMHO, both are very true) |
| 11:25 | bemasc | cahalan: the first, though I agree on both counts. |
| 11:25 | walterbender | cahalan: but we'd support some basics, including print screen |
| 11:25 | eben | cms: I think that statement negates having print device in the frame |
| 11:25 | walterbender | cahalan: there is not much spam in the Journal these days. |
| 11:25 | bemasc | I don't think the Journal is the place to "Track print jobs". |
| 11:26 | cms | eben: couldn't the journal simply track your print jobs, in addition to having the device in the frame? |
| 11:26 | eben | bemasc: Well, it depends. If every print job results in a PDF first, and then also a physical document, it could work... |
| 11:26 | cms | don't forget that the purpose of the journal is to keep track of your interactions with the system |
| 11:26 | bemasc | If we an actions/objects split, then a "I printed this thing" action would seem reasonable. |
| 11:26 | walterbender | bemasc: I think it is the place for activities to put things and those things might want to be printed... |
| 11:26 | eben | cms: Yes, but until we have an "actions" view, we shouldn't overdo it. |
| 11:26 | bemasc | eben: what if you're printing a PDF! |
| 11:26 | walterbender | maybe in addition to resume, there is print |
| 11:26 | cms | bemasc: agreed, that would be ideal |
| 11:26 | eben | If the print job creates a document (like a PDF), it works; if not, what good is it in the current design? |
| 11:27 | cms | eben: maybe we should start incorporating actions already--it wouldn't hurt |
| 11:27 | eben | bemasc: Heh. Good question. hard link. ;) |
| 11:27 | cms: easier said than done. | |
| 11:27 | cms | eben: well, for now they could be visually differentiated |
| 11:27 | bemasc | eben: what if you're printing page 3 of a PDF? Now you create a new PDF object in the journal for that page? This seems... non-ideal. |
| 11:28 | cms | eben: and we could implement a way to filter them from the view if necessary |
| 11:28 | eben | bemasc: hmm, true. |
| 11:28 | cms: It seems like that might be over-engineering things for this one use case. | |
| 11:29 | cms | bemasc: it's really more of a reference, but would allow you to invoke the same print job again in the future |
| 11:29 | cahalan | Printing sounds really painful for XO users. How many mouse clicks are we up to now? |
| 11:29 | bemasc | There are about a million different use cases here. We're not going to settle it now. |
| 11:29 | cms | eben: it's setting a precedent for the way other activities/tools could behave |
| 11:29 | cahalan: i think we're still taking about having a simple button in the activity toolbar/activity menu | |
| 11:30 | bemasc | From Activities that can generate their own postscript to activities that have no knowledge of printing. From usb printers that are attached to the laptop, to networked printers that live behind a server with a moderated (or rate-limited) queue... |
| 11:30 | cms | the limitation for actions in the journal should be that they have to be invoked by the user |
| 11:30 | cahalan | cms: OK, one click? (the norm for Tux Paint on Linux, Windows, or MacOS X) |
| 11:30 | eben | bemasc: If we could pick a simple base case to get working, and then extend that later, that would be good. |
| 11:30 | cms | cahalan: one click if there is only one printer connected, yeah |
| 11:30 | cahalan | ah, it's 2 -- still not bad |
| 11:31 | eben | cahalan: 3...another to say "go" |
| 11:31 | bemasc | vamsi picked the naive activity + moderated server print queue case. (He did so with a lot of advice from the list.) |
| 11:31 | cms | eben: couldn't we simplify that to one click? |
| 11:32 | eben | cms: if there is one printer, and we don't want to support print options, yes. |
| 11:32 | walterbender | it would be one click from the Jorunal... |
| 11:32 | cahalan | walterbender: switching to the journal counts, as does everything before that |
| 11:32 | cms | eben: clicking the icon in the toolbar would simply print, while options could be available in the hover menu |
| 11:32 | eben | I could also see having a print button in the Journal, which sent the selected Journal entry to the printer... |
| 11:32 | cahalan | walterbender: switching back counts too |
| 11:33 | eben | But can we even print without an activity being open to handle it? |
| 11:33 | walterbender | eben: yes |
| 11:33 | tomeu | bemasc: my favorite proposal is adding a print to PDF and print to printer button to each activity and perhaps as well sending a journal entry to the printer queue. I think that covers decently most of the use cases and is very simple to implement |
| 11:33 | walterbender | cahalan: I think the model of printing you are espousing is not realistic in a classroom... |
| 11:33 | eben | cahalan: depends on your context. If it's already open, it's easier from the activity. If it's not, printing from the Journal (if we can) is much faster. |
| 11:33 | cms | i do see the argument for printing from the journal... though it may not be the most intuitive to have to first switch to the journal |
| 11:33 | cahalan | walterbender: it's used all the time in classrooms |
| 11:33 | bemasc | I think we should close this discussion. Without aa or iwikiwi, there's not much point. |
| 11:34 | walterbender | kids aren't going to be printing all the time... |
| 11:34 | eben | cms: I like it as an addition, not an alternative. |
| 11:34 | cms | maybe the button in the activity toolbar could be visually aligned with "keep in journal" and provide a shortcut |
| 11:34 | bemasc | Moreover, they've already considered it extensively, including the available programmer skills. |
| 11:34 | eben | select an activity, click print. Could be in the Journal, could be the active activity... |
| 11:34 | tomeu | bemasc: I think all the proposals should be discussed in the mailing list, this meeting is just to facilitate starting the process |
| 11:34 | walterbender | cahalan: we heard as much from the teachers on the Sur list... |
| 11:34 | cms | eben: yes, i agree. the function would exist in the journal, but activities could have a shortcut |
| 11:34 | cahalan | walterbender: of course (they can be scolded, disconnected, rate limited, etc.) |
| 11:34 | cms | eben: makes sense |
| 11:35 | tomeu | eben, cms: I like that |
| 11:35 | cms | eben: it could exist in the activity menu, then |
| 11:35 | simple, clear--and it works in all views | |
| 11:36 | eben | cms: that, too, yes. |
| 11:36 | activity menu/toolbar, and the Journal | |
| 11:36 | cahalan | walterbender: printing restrictions should be exactly that -- restrictions -- not ease-of-use hurdles |
| 11:36 | cms | that seems like our solution |
| 11:36 | eben | And is there still a device, to let you know that you have a printer attached? I would say yes. |
| 11:37 | cms | i'm also in favor of recording print jobs in the journal--again, to prevent spam actions need to be limited to only those invoked by users, specifically |
| 11:37 | eben | And it would be the place for status about printing...maybe the queue....and the place you get errors and such. |
| 11:37 | cms | eben: yes, there should be a device |
| 11:37 | the printer device would be found in the frame | |
| 11:37 | garycmartin | eben: and if you have no printer setup/defined, none of the print cruft (buttons/menus) should show up any where. |
| 11:37 | eben | cms: I don't think the action needs to go in the Journal unless it's a "print to PDF." I think we should save the "let's add actions" action-item as a separate topic. |
| 11:38 | cms | garycmartin: that would be nice |
| 11:38 | eben | garycmartin: Yes, that could be good. |
| 11:38 | tomeu | cms, eben: I see an issue with being able to print from both the activity and the journal: different code is involved in the formatting of the document for printing |
| 11:38 | cms | eben: ok, we can save this for the actions debate... ;_ |
| 11:38 | ;) | |
| 11:39 | eben | cms: Yeah...I like the idea, but let's not confuse basic print support with journal actions... |
| 11:39 | cms | tomeu: is it a time/resource issue? |
| 11:39 | we could probably prioritize one over the other to at least start with something | |
| 11:40 | tomeu | cms: the problem is that when we try to print a Write entry from the journal, it's not clear how the Write code will be involved in formatting it to pdf or ps |
| 11:41 | cms | tomeu: but it still seems doable in the long-term? |
| 11:41 | tomeu | cms: it's totally doable, but it may be hard to find a solution that can be implemented with enough quality given the resources available |
| 11:41 | cms | we could start by supporting printing from the activity (the most intuitive use-case), and extend the capabilities later to include journal and other views |
| 11:42 | tomeu: if we start with printing from the activity, it wouldn't preclude us from addressing the other views later, right? | |
| 11:42 | tomeu | my favorite plan of action is to implement printing (PDF and to printer) in Write and Read, and allow sending PDFs from the journal to the printer |
| 11:42 | as a start | |
| 11:43 | cms: sure not | |
| 11:43 | eben | tomeu: why just those activities? |
| 11:43 | tomeu | eben: I think are the most likely to be used for printing |
| 11:43 | maybe imageviewer as well, it should be quite trivial | |
| 11:43 | cms | i think we could begin by focusing on only printing from activities |
| 11:43 | eben | tomeu: I think clicking print should do all the work....shouldn't have to go to the Journal and push it along. |
| 11:43 | cms | we could start with the activities most likely to be use for printing |
| 11:43 | tomeu | eben: yeah, I think I explained bad myself |
| 11:43 | cahalan | tomeu: paint programs are more likely IMHO, and Tux Paint already has printing support |
| 11:44 | cms | i think read needs to be among them |
| 11:44 | tomeu | cahalan: that fine |
| 11:44 | eben | Can we setup a default for all activities? If the activity doesn't define it, just print a screenshot, for instance? |
| 11:44 | cms | tomeu: i think your plan makes sense--and is a good starting point |
| 11:44 | cahalan | tomeu: it's suitable for testing everything else |
| 11:44 | tomeu | I would say starting with Read, Write, ImageViewer and Browse beucase I know their internals and I think it will be relatively easy to implement it |
| 11:45 | other activities are of course nice to have as well | |
| 11:45 | eben | tomeu: Oh, I parse your previous comment correctly now. :) |
| 11:45 | cms | eben: we already have a print icon--is it shown anywhere in the current UI? |
| 11:45 | eben | cms: no, but we have it, you're right. |
| 11:45 | tomeu | eben: yeah, we could add generic code for printing the screenshot very easily |
| 11:46 | though don't know how useful that may be | |
| 11:46 | eben | It might be in the artwork repo already...not sure. |
| 11:46 | tomeu: might be nice for lots of activities that wouldn't bother otherwise... | |
| 11:46 | cahalan | plain text from the clipboard is a good one to support |
| 11:46 | eben | In fact, it could just always be an option, in addition to "Print" and "Print to PDF", have "Print screenshot"? |
| 11:46 | tomeu | eben: yeah, I like the idea of providing a base line when we can |
| 11:47 | cms | sounds like we have a plan |
| 11:47 | eben | tomeu: It seems like a good way to give some WYSIWYG printing options and give basic print support to all of Sugar. |
| 11:48 | cms | tomeu: what do you need from the design team to get started? |
| 11:48 | eben | Awesome. |
| 11:48 | bemasc | So, Vamsi just finished the first step, making CUPS handle ODT (Write) documents directly |
| 11:48 | eben | cms: Sounds like we need to make sure they have the icon, and maybe try out some printer device palettes to show printing status. |
| 11:48 | tomeu | eben, cms: what we need is to establish a good communication between the new contributors and the design team |
| 11:48 | new contributors need to explain the ideas so the design team can understand what is proposed | |
| 11:48 | bemasc | So now CUPS can directly print PDF, PS, TXT, PNG, JPG, ODT, HTML... |
| 11:49 | cms | tomeu: agreed. how can we best facilitate that? |
| 11:49 | tomeu | and the design team needs to give design proposals so that contributors can understand them |
| 11:49 | cms: at this point, I would say to explain the proposed design in the mailing list | |
| 11:49 | eben | tomeu: Yes, definitely. Christian and I should get into the habit of putting more "short" mockup sequences (3-5 slides) in the design section of the wiki for things like this, perhaps. |
| 11:49 | tomeu | cms, eben: I love your mockups, but sometimes we may need something dirtier but quicker |
| 11:49 | specially at the early stages of the discussions | |
| 11:50 | cms | ok |
| 11:50 | eben | tomeu: Yeah, that sounds good. We can verbally describe our thoughts and then add mockups to support as we have the opportunity. |
| 11:50 | tomeu | something I haven't liked is how the proposals of new features have had requirements and implementation all mixed up |
| 11:50 | that makes hard for non-technical people to contribute | |
| 11:50 | well, it also made hard for me to understand what was proposed | |
| 11:51 | vamsi sent some use cases that I think are good for printing | |
| 11:51 | I think the design team can send proposals as a reply to that | |
| 11:51 | cms | so let's start by recording our thoughts (incl. mockups where necessary) on these issues |
| 11:52 | we'll put them in the design team section on the wiki and send out notifications to the mailing list | |
| 11:52 | tomeu | sounds cool |
| 11:52 | I see the design team wiki has already a section about proposals | |
| 11:53 | homunq | hi |
| 11:53 | tomeu | see these use cases: http://lists.sugarlabs.org/arc[…]9-May/014164.html |
| 11:53 | cms | thanks, that's helpful |
| 11:53 | eben | Yeah...actually, I've been meaning to move that out of "Vision"....seems it should just be DesignTeam/Proposals... |
| 11:53 | tomeu | sounds good |
| 11:53 | homunq: hi | |
| 11:53 | one more thing we need is to ask contributors to read the HIG | |
| 11:53 | cms | i'm going to have to run |
| 11:54 | we addressed everything, tomeu? | |
| 11:54 | tomeu | so they understand the reasons for the current design, and also why consistency is important |
| 11:54 | cms: I think so. do we know how to move forward? | |
| 11:54 | cms | tomeu: believe so |
| 11:54 | eben | Yeah, we need to revise the HIG, too....big chore. |
| 11:54 | There's lots of outdated material there, and it's also incomplete. | |
| 11:54 | cms | eben: let's talk offline when you have a chance |
| 11:54 | tomeu | eben: well, it's already useful as is, I think |
| 11:54 | no need to block on that, I think | |
| 11:55 | eben | shoot. I've gotta run! |
| 11:55 | I have to be somehwere. | |
| 11:55 | Bye all! | |
| 11:55 | tomeu | yeah, I need to go as well |
| 11:55 | garycmartin | bye! |
| 11:55 | cms | #endmeeting |
![http://shell.sugarlabs.org/~to[…]lla%20Firefox.png](http://shell.sugarlabs.org/~tomeu/Screenshot-global_dictionary.ogv%20(video-ogg%20Object)%20-%20Mozilla%20Firefox.png){kind=link}
![https://dl.getdropbox.com/u/10[…]digital_basic.jpg](https://dl.getdropbox.com/u/1085311/clock_digital_basic.jpg){kind=link}
![https://dl.getdropbox.com/u/10[…]ital_settings.jpg](https://dl.getdropbox.com/u/1085311/clock_digital_settings.jpg){kind=link}
![https://dl.getdropbox.com/u/10[…]ital_calendar.jpg](https://dl.getdropbox.com/u/1085311/clock_digital_calendar.jpg){kind=link}
![https://dl.getdropbox.com/u/10[…]/clock_analog.jpg](https://dl.getdropbox.com/u/1085311/clock_analog.jpg){kind=link}