Re: [Sugar-devel] UI mockups for version support in Journal
On Fri, Apr 17, 2009 at 05:47:08PM +0200, Sascha Silbe wrote: I'm afraid ComboBox and menu items are handling images differently: GtkImageMenuItem supports GtkImages, but ComboBox only pixbufs. s.g.Icon implements GtkImage and draws using cairo, not pixbufs = not usable inside ComboBox. :( Filed upstream bug #579804 [1] about that. I don't think they'll implement it themselves (given that they've not even fixed a simple bug [2] for almost 4 years now), but let's still hope we get it for free. :) [1] http://bugzilla.gnome.org/show_bug.cgi?id=579804 [2] http://bugzilla.gnome.org/show_bug.cgi?id=314926 CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
On Wed, Apr 22, 2009 at 10:49, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Fri, Apr 17, 2009 at 02:06:55AM +0200, Sascha Silbe wrote: [Mockups] The second one [2,3] modifies the date field to be a combo box, like shown in Journal Designs #12 [4]. The fine thing with mockups is that they show just what you imagine, not the complicated reality. How do we actually handle branches? Option 1: * show all versions in the branch of the current entry, including all ancestors on super branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1, 1.1, 1]) * rebuild the date/version box on selection of a version + consistency: no matter how you got to the current version, it will always look the same - oneway: once you select a version on a super branch, you're stuck to it and can't change back to the originally chosen version anymore. Option 2: * show all versions in the branch of the current entry, including all ancestors on super branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1, 1.1, 1]) * always show the date/version box of the originally selected version + oneway: you can go back to the originally selected version from any ancestor - consistency: depending on where you entered the tree, you'll get access to different versions. Option 3: * only show direct linear ancestors, not super branches + no consistency or oneway issues - no access to earlier branches, i.e. any load+save of a non-HEAD version will cut the entire ancestry for the just saved version Option 4: * flatten and sort the entire version tree according to the date + no consistency or oneway issues + access to all branches/versions - no information about ancestry, an intermediate version might lack content that both neighbors (in the list) have Thinking about it, Option 4 is probably the way to go for now (unless someone can come up with a smart #5). Rely on the user to tag the documents well enough to avoid confusion. We probably want to revise this decision later when we got some experience with actual user behaviour. #2 doesn't sound too bad to me. Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
On Wed, Apr 22, 2009 at 5:13 AM, Tomeu Vizoso to...@sugarlabs.org wrote: On Wed, Apr 22, 2009 at 10:49, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Fri, Apr 17, 2009 at 02:06:55AM +0200, Sascha Silbe wrote: [Mockups] The second one [2,3] modifies the date field to be a combo box, like shown in Journal Designs #12 [4]. The fine thing with mockups is that they show just what you imagine, not the complicated reality. How do we actually handle branches? Option 1: * show all versions in the branch of the current entry, including all ancestors on super branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1, 1.1, 1]) * rebuild the date/version box on selection of a version + consistency: no matter how you got to the current version, it will always look the same - oneway: once you select a version on a super branch, you're stuck to it and can't change back to the originally chosen version anymore. Option 2: * show all versions in the branch of the current entry, including all ancestors on super branches (i.e. 1.1.3 shows [1.1.3, 1.1.2, 1.1.1, 1.1, 1]) * always show the date/version box of the originally selected version + oneway: you can go back to the originally selected version from any ancestor - consistency: depending on where you entered the tree, you'll get access to different versions. Option 3: * only show direct linear ancestors, not super branches + no consistency or oneway issues - no access to earlier branches, i.e. any load+save of a non-HEAD version will cut the entire ancestry for the just saved version Option 4: * flatten and sort the entire version tree according to the date + no consistency or oneway issues + access to all branches/versions - no information about ancestry, an intermediate version might lack content that both neighbors (in the list) have Thinking about it, Option 4 is probably the way to go for now (unless someone can come up with a smart #5). Rely on the user to tag the documents well enough to avoid confusion. We probably want to revise this decision later when we got some experience with actual user behaviour. #2 doesn't sound too bad to me. I agree, I think #2 is a good option. I understand the confusion with the inability to show descendants of a given entry, but in practice versioning in Sugar (I expect) will be used more like a history of changes than a full version tree. Merging would complicate this (we can cross that bridge if/when we support it), but until then we always know the full ancestry of a given node as a single ordered path. This history (and not future) of a specific entry is likely of most importance in the context of a Journal which is meant to as a record of the past. One other note on this idea. Technically, we would be able to show *some* future (newer) versions for a given entry...we can show all descendants up until a branch unambiguously. I'm not sure which approach (ancestors only, or ancestors plus un-branching descendants) is the better course. Finally, just for fun, let me offer an option 5... Option 5: * show all versions in the branch of the current entry (including all descendants prior to a branch), including all ancestors on super branches (i.e. 1.1.3 shows [1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1, 1]) * set apart by a separator line at the top of the version menu, show all n children at the first branch in the tree. + you can get to any point in the tree from any other point + the tree is reduced to a manageable list at every step, which shows ancestor history for the current entry and a single choice at the first branch in the tree. - if you navigate to an ancestor, it might not be obvious how to get back to where you started (if there were intermediate branches). - perhaps this exposes too much, making the system more complicated. Food for thought. Eben Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
Every help on the UI side welcome. What I do not get is why there is that navigation bar under the toolbar? It consumes a lot of space and has just that one button which was on the toolbar before. (I just checked the last SoaS image so it appeared in 0.84 I guess). Also the old layout shows a back button which looks like the one in Browse for the same purpose as in Browse. It is clearly a bad design IMHO. ps: Just booted my XO and 801 has this navigation bar (I do not remember it from ~760). So either way can we get rid of it? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
On Fri, Apr 17, 2009 at 7:49 AM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Fri, Apr 17, 2009 at 12:23:16PM +0200, Sascha Silbe wrote: 2. We proposed putting star icons at the left of starred entries in the list, making it easier to identify useful or otherwise important versions amidst a potentially long version history at a glance. (This, of course, assumes versioned metadata.) Preliminary mockup done [1,2], though with no filled star shown (so no favourite tagged) because for that I probably need to do extensive changes to sugar.graphics.ComboBox (or a derivative thereof) in order to display a CanvasIcon (KeepIcon) inside the gtk.ComboBox. You don't need a CanvasIcon to colorize, I don't think. We support colorizing icons in menus, which behave similarly to comboboxes I'd think. Anyway, colored would be preferred. Also (Again wishing I had the mockup), I don't think the star should be shown in the combobox itself. It's redundant info, as the star will always appear to the left of the activity icon. Instead, the star is useful only within the menu itself, where it serves as adde context in leu of a full display of the entry. I'm not sure if that's possible, though...it would be great if it is, because the star in the closed combobox is unwanted, I think. Eben BTW: Is there any tutorial on how to work with / write custom widgets for hippo-canvas? The one link I found is broken, and except for the somewhat lacking API docs there wasn't anything too useful anywhere. Actually I'm not sure if I even should extend it - it seems to be deprecated. But redoing the whole page not to use it is out of scope as well... [1] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-4.png [2] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-5.png CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJJ6GzDAAoJELpz82VMF3DaIOgH/A1dfTl9F4uAG7S5LfiSbcVT g64Nm1xsCm8VTBdUW9xtfORlMKF8z+oQH9xqRf9BhkyNLLsy9KOzMVeYuS6ClHQi wq/IdTpnmeZzvIs7OjGe2ruyoosrPBgwq4q5kjd7GH8Hzrj5QISvhxoDMWTZspSc QyfSJhX4e+bCJSzJialSG3d3t3zgCTm9JNFh9lUd2sF1IDpIiFrzmhJ1JMBuNaY1 Iv/h6m4HcFlMMyjIyiP5+WjOL8HQhfAxsRnlMhS4mS6MI2fxlDZBnSd9/m2RgJRf 2zYjoworYGMLHDQUrrOYrIle0T/pHeZO3TAyO1Z8vrWM9lN+snl4htx2BVWZZSY= =+2o1 -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
On Fri, Apr 17, 2009 at 6:23 AM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Thu, Apr 16, 2009 at 09:10:58PM -0400, Eben Eliason wrote: In any case, I still lean in the direction of the second option, [...] OK, seems like that's a consensus. :) And with that, a here are a few notes which might improve the popup menu itself (I can't seem to find our earlier mockups of this, or I would have attached them. I'll keep looking). Would be quite interested in them and I haven't found any (besides the one I mentioned) myself. Yeah, we had hundreds of iterations on the Journal, so it's probably hidden in some particular layer of an .ai file somehwere on my machine... 1. The dates should be ordered with the most recent at the top, to mirror the list view of the Journal, keeping time flowing in the same direction. Makes perfect sense; I've reversed the mockup. 2. We proposed putting star icons at the left of starred entries in the list, making it easier to identify useful or otherwise important versions amidst a potentially long version history at a glance. (This, of course, assumes versioned metadata.) Interesting idea. Seems like I need to dig deeper into hippo-canvas to do a custom widget (using a light CanvasItem wrapper around sugar.graphics.ComboBox right now). I don't think you'll need a custom widget. Just setup the model correctly and it should all work. Check out this thread. It has some pointers on how to make things work correctly, and some source code is included at the bottom of the 3rd reply, I think: http://www.mail-archive.com/py...@daa.com.au/msg09625.html Eben I'm so excited for versions! Me too. :) Every help on the UI side welcome. CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJJ6FiQAAoJELpz82VMF3DaUZkH/0zh4C5I73sr+P8zid2ayQor 6jx+JgqeoQ4zgxquHTMpTuzvBcVu9lQUnCUxQCFA3UZ8FcsaKVzA6ekNfIJJxLXp h9qn7wvVFlmON1Qr5B2KhpX0KA6ygX7N4GEU2uzE1WM8JyozJKZIE0LiCjYZpkzp Jhtaag7US9mQ6llcrxmiGe79xVdDFxyUbqJTMT8nyLWNAOoYkxG0A7VhJMkPcpyj DvpevDpsc6gaf+h2GDk6wlwbQVLev7mzShcS2BT2rta7Y3nE77X3scYu090/0k/b EJKo80Ikb7xHp15i8lyj1VTFRf75io8iwvlM2ZWg/f6UCspcBx8h4oSyDU6dIMo= =etTO -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
On Fri, Apr 17, 2009 at 12:23:16PM +0200, Sascha Silbe wrote: 2. We proposed putting star icons at the left of starred entries in the list, making it easier to identify useful or otherwise important versions amidst a potentially long version history at a glance. (This, of course, assumes versioned metadata.) Preliminary mockup done [1,2], though with no filled star shown (so no favourite tagged) because for that I probably need to do extensive changes to sugar.graphics.ComboBox (or a derivative thereof) in order to display a CanvasIcon (KeepIcon) inside the gtk.ComboBox. BTW: Is there any tutorial on how to work with / write custom widgets for hippo-canvas? The one link I found is broken, and except for the somewhat lacking API docs there wasn't anything too useful anywhere. Actually I'm not sure if I even should extend it - it seems to be deprecated. But redoing the whole page not to use it is out of scope as well... [1] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-4.png [2] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-5.png CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
On Fri, Apr 17, 2009 at 07:50:07AM -0400, Eben Eliason wrote: I don't think you'll need a custom widget. Just setup the model correctly and it should all work. Check out this thread. It has some pointers on how to make things work correctly, and some source code is included at the bottom of the 3rd reply, I think: http://www.mail-archive.com/py...@daa.com.au/msg09625.html Thanks for the pointer, xalign might certainly get useful. As we only show (filled or non-filled) stars, i.e. always the same width, we don't need it yet. It would require changes to sugar.graphics.ComboBox. On Fri, Apr 17, 2009 at 07:56:05AM -0400, Eben Eliason wrote: You don't need a CanvasIcon to colorize, I don't think. We support colorizing icons in menus, which behave similarly to comboboxes I'd think. Anyway, colored would be preferred. I poked around a bit and found uses of sugar.graphics.Icon that might be what I need. Also erikos pointed out I can use hippo.CanvasWidget instead of a custom wrapper. But it still seems I need to either use gtk.ComboBox directly or extend sugar.graphics.ComboBox as the latter one only allows for icon names, not Icon/pixmap instances to be passed. Unless there is an icon file (name) that contains a filled/colored version of the star, that is (I haven't found one). Also (Again wishing I had the mockup), I don't think the star should be shown in the combobox itself. It's redundant info, as the star will always appear to the left of the activity icon. Instead, the star is useful only within the menu itself, where it serves as adde context in leu of a full display of the entry. I'm not sure if that's possible, though...it would be great if it is, because the star in the closed combobox is unwanted, I think. I'm not sure I understand. Do you mean that you want the stars only in the opened ComboBox, but not the closed one? I.e. [1] not showing the star, but [2] showing it? Apart from doing my own version of gtk.ComboBox, it might be possible to emulate that style using callbacks by (de)activating the icon column upon popup/popdown. [1] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-4.png [2] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-5.png CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
On Fri, Apr 17, 2009 at 07:56:05AM -0400, Eben Eliason wrote: You don't need a CanvasIcon to colorize, I don't think. We support colorizing icons in menus, which behave similarly to comboboxes I'd think. Anyway, colored would be preferred. I'm afraid ComboBox and menu items are handling images differently: GtkImageMenuItem supports GtkImages, but ComboBox only pixbufs. s.g.Icon implements GtkImage and draws using cairo, not pixbufs = not usable inside ComboBox. :( For now I'm going to leave the stars out. If we later decide we really want them, I can still add it, probably using a custom GtkCellRenderer (which could then also support not showing them in closed mode). CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
On Fri, Apr 17, 2009 at 17:47, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: On Fri, Apr 17, 2009 at 07:56:05AM -0400, Eben Eliason wrote: You don't need a CanvasIcon to colorize, I don't think. We support colorizing icons in menus, which behave similarly to comboboxes I'd think. Anyway, colored would be preferred. I'm afraid ComboBox and menu items are handling images differently: GtkImageMenuItem supports GtkImages, but ComboBox only pixbufs. s.g.Icon implements GtkImage and draws using cairo, not pixbufs = not usable inside ComboBox. :( For now I'm going to leave the stars out. If we later decide we really want them, I can still add it, probably using a custom GtkCellRenderer (which could then also support not showing them in closed mode). Don't worry too much about this, I'll be so happy when we get versions working, that I will put all the candy you want* on top of it! Regards, Tomeu * to a reasonable limit ;) CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJJ6KR5AAoJELpz82VMF3Da6ocH/2NJ8qMIr4IDMblj3waP4db6 /UWekp4tg4y7uuv115CA18G4Lpgs81VnY+lxumAC7mfUixrFKo6rOIoELihBkGuM ey2bFYuAMFKbDtELiGV0+lCdIgzG70leH0+/LyoeeqxxqFvKFfNcr4MN6yr4m6Nx pP57fFW5LX6OPznHFp3TZj6CUdDaeXI8vjDN7RX7+cTEb2IjTDHfKQ7PQOacSFz+ OzA+QUvNc7mCzkjbMZSlGJ5B+FjYALQAYSc7kmLoRkouJaD8HIxMl8xuNbiDg1pS ERrX3A5o9MLe4TJr9MH4k1cyQAllntr8dqBKmNJ1ip0ki0Vmii8CTtzdIHlNfcc= =lRUw -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] UI mockups for version support in Journal
Hi! I've just finished two UI mockups for basic (!) version support in the Journal. The first one [1] shows just a previous and a next button like discussed on IRC. I've recycled the BackBar (with hover effect on the buttons instead of the bar) for that since it seemed to be a good fit (it's a kind of navigation bar now). The second one [2,3] modifies the date field to be a combo box, like shown in Journal Designs #12 [4]. I actually like the second one better, though it's not as obvious - but combo boxes usually encourage playing with them, so it will be discovered sooner or later. Seems like a nice tradeoff. Suggestions welcome. [1] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-1.png [2] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-2.png [3] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-3.png [4] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#12 CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
On Fri, 2009-04-17 at 02:06 +0200, Sascha Silbe wrote: Hi! I've just finished two UI mockups for basic (!) version support in the Journal. The first one [1] shows just a previous and a next button like discussed on IRC. I've recycled the BackBar (with hover effect on the buttons instead of the bar) for that since it seemed to be a good fit (it's a kind of navigation bar now). The second one [2,3] modifies the date field to be a combo box, like shown in Journal Designs #12 [4]. I actually like the second one better, though it's not as obvious - but combo boxes usually encourage playing with them, so it will be discovered sooner or later. Seems like a nice tradeoff. I also like the second one a lot better. I would find it immensely frustrating if I had to click a button 10 times to get to a specific older version. Suggestions welcome. [1] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-1.png [2] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-2.png [3] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-3.png [4] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#12 CU Sascha ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] UI mockups for version support in Journal
On Thu, Apr 16, 2009 at 8:06 PM, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: Hi! I've just finished two UI mockups for basic (!) version support in the Journal. The first one [1] shows just a previous and a next button like discussed on IRC. I've recycled the BackBar (with hover effect on the buttons instead of the bar) for that since it seemed to be a good fit (it's a kind of navigation bar now). The second one [2,3] modifies the date field to be a combo box, like shown in Journal Designs #12 [4]. I actually like the second one better, though it's not as obvious - but combo boxes usually encourage playing with them, so it will be discovered sooner or later. Seems like a nice tradeoff. Suggestions welcome. [1] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-1.png [2] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-2.png [3] http://wiki.sugarlabs.org/go/Image:Journal-version-mockup-3.png [4] http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#12 The first screen is an interesting alternative. I agree with Walter that, at the least, the version nav should be separated visually from the back button. In any case, I still lean in the direction of the second option, since I don't think we need to expose this more prominently, and because it's really useful to be able to jump to any given version directly. And with that, a here are a few notes which might improve the popup menu itself (I can't seem to find our earlier mockups of this, or I would have attached them. I'll keep looking). 1. The dates should be ordered with the most recent at the top, to mirror the list view of the Journal, keeping time flowing in the same direction. 2. We proposed putting star icons at the left of starred entries in the list, making it easier to identify useful or otherwise important versions amidst a potentially long version history at a glance. (This, of course, assumes versioned metadata.) I'm so excited for versions! Eben CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iQEcBAEBAgAGBQJJ58gcAAoJELpz82VMF3DadrwH/A3T85kKU81AJ71pYCEOX4Bm iDhSDmqneDXiizkb5F2C6UYa1ptb0T8cubLGV7ccrGOA9rOhFvHeogNRJVzWmMug 4Fks3xB16tNbCtMRBmEvcVAHgeskV0jXQri5tknC/cq8YgNI8fLBCxVN9i3x4Qyt Krk4P1N9sAplKDYo/SJ005ED6aW3g0Y9rhAdkEC87x0gCu2JPU8gnkyeMREKP0J5 w5Albc/5GTi2fB+QU0fvIel5acXV8dqsxZRCMDhiitYKWENBMXxcvdzRQ0RtVnXF Gx0HmYACsHn9DJ91NWLkmwYCnPKB35SDX0MhvbkQe3wbA0URDAK7gNt3jaOhM2k= =S2Ze -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
