Re: [Sugar-devel] [DESIGN] Frame Device icon Volumes

[Simon Schampijer]

On 08/19/2012 08:04 PM, Gary Martin wrote:

On 19 Aug 2012, at 15:54, Simon Schampijer si...@schampijer.de wrote:


On 08/19/2012 03:45 PM, Gonzalo Odiard wrote:

There are a convention about the position of the primary action?
Should be the closest to the button or the first at top of the palette?


The palettes reflow based on how close to a screen edge it is, so in some cases 
it might not be easily to know which end of the palette is closest to the 
button. I'd also call out that reordering a palettes content is a worse UI 
crime for consistency. At Sugar Camp Paris 2, Simon and I did mock-up a range 
of 'put the primary action by the button' type designs, until we realised the 
issues with reflow when near screen edges.

So that's a +1 for top of the palette. I've always assumed this was the 
convention and implicit in the current implementation, but perhaps it's not 
explicitly documented (seemingly like so many other items).


I think is important have this defined, and may be show it in a special way.
In this particular case, the option is between the label, another action and
the widget showing the size, and is not obvious.

Gonzalo


So, in this particular case, there is no primary action anymore. Left click 
will always bring up the Palette, then it is up to the user to decide.


+1


Let's look at another case: the Activity Palettes in the Frame (see 
activity_palette_1.png). The primary action there is to resume the Activity. 
When you click on the button that activity is resumed. The action is drawn 
right below the label. That is where I would put it as well. But in this case, 
I think the separator should then be drawn below the primary option (see 
activity_palette_2.png).


Yes, for this case I think that's a reasonable amendment. The only other 
variation for this that came to mind would be to make the primary action text 
bold (as adding/moving separators might not always be the right treatment).


Attached is an example with the text being bold for the primary action. 
Is subtle. Not sure it will make clear what it is about.


Simon
attachment: bold_primary.png___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] conversations about sugar ui design

[Aleksey Lim]

On Mon, Aug 20, 2012 at 01:56:39PM +1000, David Brown wrote:
 this note embraces several different emails from Aleksey and Walter
 
 The Sugar learner engages in the cycle of
 activities by using the Sugar tools as individual building blocks,
 
 ah if the objective were to produce sugar-literacy, that would
 make sense, but if sugar were merely a tool to facilitate learning of
 things that are going to be of use to the kid in the outside world,
 then every effort should be made to make sugar itself as transparent
 as possible, rather like google chrome tries to get out of the way
 just as internet explorer tries to get in the way with thousands of
 toolbars

A couple of general thoughts.

My own background, when I started contributing to Sugar Labs, was that
I didn't see how Sugar Shell might be particular useful in educational
process (but I saw technical potency of having community of doers
targeted to learning platform, whatever it might be at the end).
At the same time, Sugar Shell has OLPC roots when OLPC needed, in my
mind, desktop environment for XO laptops. And, Sugar Shell is much
better, imho, option than regular desktops existed in the past and
present right now.

I mean, attempt to create entire desktop environment should not be
dominant effort on Sugar Labs level when there is no urgent need in
having desktop environment (different to office desktops) to install
on particular hardware. Obviously, high aged students, most likely,
will prefer not Sugar Shell as a regular desktop environment. Low aged
students, at least in my mind, don't exactly need desktop environment,
but rather some environment (maybe pretty isolated from the rest of
current desktop) that will be useful for them from teacher's pov.

In other words, it will be useful if software, created within the Sugar
Labs, will run on regular desktops to give more flexibility for people
in the field. For example, particular school/region might decide to
spread tablets on Android among students. The lets port Sugar [as a
desktop environment] on Android sounds scary for me. Much better if
there will be a way to launch some Sugar activities as a regular Android
apps and having a kind of shell (most likely created from scratch to
make it more Android) for cases when students [low aged] need
limited/restricted environment.

-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] conversations about sugar ui design

[Walter Bender]

On Sun, Aug 19, 2012 at 11:56 PM, David Brown djhbr...@gmail.com wrote:
 this note embraces several different emails from Aleksey and Walter

 What you see on http://network-testing.sugarlabs.org
 is a first rough and implementation for webui,

 you have put quite some effort into presenting your sketches, Aleksey:
 whilst that is in itself impressive, i'm not keen on the sketches
 themselves:  using icons instead of words is presumably an attempt to
 make the ui accessible to the illiterate, but in my view it only
 complicates matters.  icons would be effective if they were
 universally obvious a priori, but that is not possible - icons have to
 be learned just as do the symbols of any alphabet.  mother tongue is
 preferable, as it contributes to the learning of literacy useful in
 the broader context of the language world within which they live.  a
 single release of a ui could have a feature that allows the ui to be
 displayed in any of the languages that have been implemented.

 the choices of names are developer-oriented rather than user-oriented:
 for example, the name turtle-art makes sense only to people who are
 already familiar with Logo.  Whereas, draw a picture (or its
 translation) would make sense to any kid who can read her mother
 tongue.  for those who can't read, a thumbnail of a half-finished
 painting and a brush might work - it would take up more pixels than an
 icon, but i don't think there should be many app-triggers on view at
 the same time.

 with 69 apps already mooted (and presumably a thousand more waiting to
 be added), that creates a navigation issue which needs to be
 addressed.  i feel that it could be done by creating categories of
 activity (such as learn, play and meet) and subcategories etc,
 making a simple tree structure (or maybe a network with cross-links).
 the one thing i am sure of is that trying to put buttons for
 everything on one screen creates information overload.

As regard the activity icons on the home page (as several people have
responded already) we haven't observed this as being a major problem
with Sugar in the field. Also, at least in the beginning, we were
disciplined about naming activities as actions, e.g., Paint, Browse,
etc. Turtle Art was a bit of an exception and probably could have been
named Program.

It has been oft observed that children will push buttons in order to
find out what they do, as oppose to adults, who like to know what
buttons do before they push them.

In general, there are roll-over text hints for every icon in Sugar.
We've had a long (4+ years) argument about the length of the delay in
revealing those texts and in the most recent Sugar, all secondary
palettes will appear immediately.


 I've been thinking for quite some time that we need a new approach to
 the problem of toolbar items following off the end of the toolbar
 .A simple solution would be to double the vertical size of the
 toolbar and wrap the icons onto a second row.

 perhaps there are too many tool buttons on screen at the same
 time! - but in general, one way to display long lists of items is
 to use scrolling, whether by mouse or finger slide - if the scrolled
 list were an imaginary wheel viewed edge-on with, say, half a dozen
 items in view at any one time, you wouldnt need a scrollbar, just a
 single button to rotate it (or a wheel mouse, which i find quite handy
 for scanning up and down lines of text).

We had extensive use of scrolling in earlier versions of Sugar and
found that it was not readily discoverable, even by curious kids.
Maybe it was simply a matter of poor design and it certainly could be
revisited.

Another argument against scrolling is that it requires you to remember
where things are. Not sure that is necessary.




 The model we have been using is one of imagine and realize and
 critique and reflect.

 sounds good but these are things that a kid would do within an
 activity (aka app) - getting to that activity should not require
 detective work.

Agreed. But as per above, kids seem to engage in such detective work
anyway. In a recent study in Ethiopia, it was reported that kids
explored thousands of activities per month. This was all done through
clicking on icons (Android in this case) to see what they do.




 The Sugar learner engages in the cycle of
 activities by using the Sugar tools as individual building blocks,

 ah if the objective were to produce sugar-literacy, that would
 make sense, but if sugar were merely a tool to facilitate learning of
 things that are going to be of use to the kid in the outside world,
 then every effort should be made to make sugar itself as transparent
 as possible, rather like google chrome tries to get out of the way
 just as internet explorer tries to get in the way with thousands of
 toolbars

Apparently I was not clear. Let me explain by example.

Sugar has a Record activity used to record still images, sound, and video.
Sugar also has a Write activity, used to write texts.

Re: [Sugar-devel] [PATCH sugar] Frame: new behavior for revealing/hiding the Frame with the mouse

[Manuel Quiñones]

2012/8/17 Simon Schampijer si...@schampijer.de:
 On 08/17/2012 12:48 AM, Manuel Quiñones wrote:

 I've tested an earlier patch for this and now I reviewed it.  This is
 a much more solid interaction with the frame, and less error prone.

 All looks good.  Please commit.


 Thanks Manuel for testing and the review. I have fixed the 'cycling through
 activities' in v2 of the patch.

 Something we have to look at as a follow-up would be the Frame 'animation'.
 When you switch between the Home View and the Neighborhood View for example
 you see the Frame disappear and then the toolbar is drawn. And in general
 the Frame animation should really be smoother...

Yes, and that makes me think, why not leave the frame open while
switching zoom views?  I think that would be better.

-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Frame: new behavior for revealing/hiding the Frame with the mouse

[Manuel Quiñones]

2012/8/17 Simon Schampijer si...@schampijer.de

 After discussing with Gary I prepared this patch to change the
 interaction with the Frame in the following manner:

 - you can reveal the Frame by going with the cursor in one of the
   hot corners

 - you can hide the Frame by going with the cursor in one of the
   hot corners (and the Frame is visible)

 - the Frame is not hidden on mouse out (leaving the Frame)

 - (as before) you can hide/reveal the Frame with the designated keys

 - the Frame is hidden when you switch between activities
   (todo: hide as well when resume in the Palette is clicked)

 - the Frame is hidden when a zoom level is selected

As I suggested, maybe leave the frame open whle switching zoom views?

 - (as before) you can use 'alt-tab' to cycle through the
   running activities

 - drag  drop is currently not working, SL #3811

 v2: fixed cycling through running activities

Tested, works as expected.

Another thing to think is the frame in relation with the Control
Panel.  I think the frame should be hidden when the control panel is
opened.

 Signed-off-by: Simon Schampijer si...@laptop.org

 ---
  src/jarabe/frame/activitiestray.py |  2 ++
  src/jarabe/frame/frame.py  | 53
 ++
  src/jarabe/frame/zoomtoolbar.py|  6 +
  src/jarabe/view/tabbinghandler.py  |  2 +-
  4 files changed, 22 insertions(+), 41 deletions(-)

 diff --git a/src/jarabe/frame/activitiestray.py
 b/src/jarabe/frame/activitiestray.py
 index 9590bce..d386b3b 100644
 --- a/src/jarabe/frame/activitiestray.py
 +++ b/src/jarabe/frame/activitiestray.py
 @@ -287,6 +287,8 @@ class ActivitiesTray(HTray):
  window = home_activity.get_window()
  if window:
  window.activate(gtk.get_current_event_time())
 +frame = jarabe.frame.get_view()
 +frame.hide()

  def __remove_invite_cb(self, icon, invite):
  self._invites.remove_invite(invite)
 diff --git a/src/jarabe/frame/frame.py b/src/jarabe/frame/frame.py
 index 7407e18..ee112a1 100644
 --- a/src/jarabe/frame/frame.py
 +++ b/src/jarabe/frame/frame.py
 @@ -57,29 +57,12 @@ class _Animation(animator.Animation):
  class _MouseListener(object):
  def __init__(self, frame):
  self._frame = frame
 -self._hide_sid = 0

  def mouse_enter(self):
 -self._show_frame()
 -
 -def mouse_leave(self):
 -if self._frame.mode == Frame.MODE_MOUSE:
 -self._hide_frame()
 -
 -def _show_frame(self):
 -if self._hide_sid != 0:
 -gobject.source_remove(self._hide_sid)
 -self._frame.show(Frame.MODE_MOUSE)
 -
 -def _hide_frame_timeout_cb(self):
 -self._frame.hide()
 -return False
 -
 -def _hide_frame(self):
 -if self._hide_sid != 0:
 -gobject.source_remove(self._hide_sid)
 -self._hide_sid = gobject.timeout_add(
 -  _FRAME_HIDING_DELAY, self._hide_frame_timeout_cb)
 +if self._frame.visible:
 +self._frame.hide()
 +else:
 +self._frame.show()


  class _KeyListener(object):
 @@ -88,23 +71,16 @@ class _KeyListener(object):

  def key_press(self):
  if self._frame.visible:
 -if self._frame.mode == Frame.MODE_KEYBOARD:
 -self._frame.hide()
 +self._frame.hide()
  else:
 -self._frame.show(Frame.MODE_KEYBOARD)
 +self._frame.show()


  class Frame(object):
 -MODE_MOUSE = 0
 -MODE_KEYBOARD = 1
 -MODE_NON_INTERACTIVE = 2
 -
  def __init__(self):
  logging.debug('STARTUP: Loading the frame')
 -self.mode = None

  self._palette_group = palettegroup.get_group('frame')
 -self._palette_group.connect('popdown',
 self._palette_group_popdown_cb)

  self._left_panel = None
  self._right_panel = None
 @@ -143,6 +119,9 @@ class Frame(object):
  visible = property(is_visible, None)

  def hide(self):
 +if not self.visible:
 +return
 +
  if self._animator:
  self._animator.stop()

 @@ -150,16 +129,12 @@ class Frame(object):
  self._animator.add(_Animation(self, 0.0))
  self._animator.start()

 -self.mode = None
 -
 -def show(self, mode):
 +def show(self):
  if self.visible:
  return
  if self._animator:
  self._animator.stop()

 -self.mode = mode
 -
  self._animator = animator.Animator(0.5)
  self._animator.add(_Animation(self, 1.0))
  self._animator.start()
 @@ -180,6 +155,7 @@ class Frame(object):
  zoom_toolbar = ZoomToolbar()
  panel.append(zoom_toolbar, expand=False)
  zoom_toolbar.show()
 +zoom_toolbar.connect('level-clicked', self._level_clicked_cb)

  activities_tray = ActivitiesTray()
  panel.append(activities_tray)
 @@ -208,7 +184,6 @@ class Frame(object):
   

Re: [Sugar-devel] Gio.VolumeMonitor.get() crash

[Manuel Quiñones]

2012/8/18 Daniel Narvaez dwnarv...@gmail.com:
 As mentioned on the wiki shell port page, calling
 Gio.VolumeMonitor.get() inside sugar was causing  a segfault.

 I found this was due to the fact that we was mixing statinc and
 dynamic bindings by importing gst. Now I added the gstreamer 1.0 port
 of gst-plugins-espeak to sugar-build and posted a patch to port sugar
 to use pygi for gstreamer. With these changes journal_gtk3-2.patch
 doesn't crash anymore.

Daniel, thank you very much!  I was looking for the faulty import,
grepping the code, but couldn't find it.  Thanks!

-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Frame: new behavior for revealing/hiding the Frame with the mouse

[Simon Schampijer]

On 08/20/2012 04:44 PM, Manuel Quiñones wrote:

2012/8/17 Simon Schampijer si...@schampijer.de:

On 08/17/2012 12:48 AM, Manuel Quiñones wrote:


I've tested an earlier patch for this and now I reviewed it.  This is
a much more solid interaction with the frame, and less error prone.

All looks good.  Please commit.



Thanks Manuel for testing and the review. I have fixed the 'cycling through
activities' in v2 of the patch.

Something we have to look at as a follow-up would be the Frame 'animation'.
When you switch between the Home View and the Neighborhood View for example
you see the Frame disappear and then the toolbar is drawn. And in general
the Frame animation should really be smoother...


Yes, and that makes me think, why not leave the frame open while
switching zoom views?  I think that would be better.



The idea is to have the upper Frame section (Views and Activities) 
behave the same. The primary action for those should be switching 
between them. But after I switched the Frame should be away so I can 
interact with the new Zoom level/Activity I am in.


Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Port the gstreamer code to pygi

[Manuel Quiñones]

2012/8/18 Daniel Narvaez dwnarv...@gmail.com:
 Feel free to ignore this, I pushed it on the manuqs-erikos-shell-port
 branch. I think the idea everything will be posted for review here as
 soon as the port is in good shape.

Yes, thanks for pushing it and help with the shell port :)  Added your
name to http://wiki.sugarlabs.org/go/Features/GTK3/Shell#Done

-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Frame: new behavior for revealing/hiding the Frame with the mouse

[Manuel Quiñones]

2012/8/20 Simon Schampijer si...@schampijer.de:
 On 08/20/2012 04:44 PM, Manuel Quiñones wrote:

 2012/8/17 Simon Schampijer si...@schampijer.de:

 On 08/17/2012 12:48 AM, Manuel Quiñones wrote:


 I've tested an earlier patch for this and now I reviewed it.  This is
 a much more solid interaction with the frame, and less error prone.

 All looks good.  Please commit.



 Thanks Manuel for testing and the review. I have fixed the 'cycling
 through
 activities' in v2 of the patch.

 Something we have to look at as a follow-up would be the Frame
 'animation'.
 When you switch between the Home View and the Neighborhood View for
 example
 you see the Frame disappear and then the toolbar is drawn. And in general
 the Frame animation should really be smoother...


 Yes, and that makes me think, why not leave the frame open while
 switching zoom views?  I think that would be better.


 The idea is to have the upper Frame section (Views and Activities) behave
 the same. The primary action for those should be switching between them. But
 after I switched the Frame should be away so I can interact with the new
 Zoom level/Activity I am in.

I understand.  So yes, for consistency's sake is ok.  We should fix
the toolbar appearence then.


-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Testing Rotate in sugar-jhbuild

[Manuel Quiñones]

2012/8/19 Walter Bender walter.ben...@gmail.com:
 On Thu, Aug 16, 2012 at 5:27 PM, Gary Martin garycmar...@googlemail.com 
 wrote:
 Hi Walter,


 On 16 Aug 2012, at 16:53, Walter Bender walter.ben...@gmail.com wrote:

 On Thu, Aug 16, 2012 at 11:36 AM, Gonzalo Odiard gonz...@laptop.org wrote:

 In anybody want test how activities work with the screen rotated in

 sugar-jhbuid,

 can do in the terminal:


 xrandr -o left


 when your neck hurts, or you have finished...


 xrandr -o normal


 Gonzalo


 ___

 Sugar-devel mailing list

 Sugar-devel@lists.sugarlabs.org

 http://lists.sugarlabs.org/listinfo/sugar-devel



 Works great. Check out
 http://wiki.sugarlabs.org/images/c/cb/Portfolio-27.xo which support
 rotation. But I am curious why the stop button runs off the edge... it
 would appear there is plenty of room for it.


 Not sure if this is your issue (my land line has been down most of the day
 and am on GSM network), but invisible separators still take space unless you
 explicitly tell them not to:

 separator.set_size_request(0, -1)

 So your separator factory might need a tweak. See Physics activity.py line
 103 for a working example.

 Regards,
 --Gary


 -walter

 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

 I've been thinking for quite some time that we need a new approach to
 the problem of toolbar items following off the end of the toolbar This
 problem will be greatly exacerbated by the more frequent use of screen
 rotate one would expect with more use of tablet mode on XO 4.0 Touch.
 Most activities have not taken into account the potential squeezing of
 the toolbar by 25% even of they take into consideration general
 resizing of the screen due to rotation.

+1 I think this should be solved somehow, is not easy.

 A simple solution would be to double the vertical size of the toolbar
 and wrap the icons onto a second row.

Yeah but how the subtoolbars and the icons that toggles them would
look in this case?


-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] unfocus search entries in Views and the Journal

[Gary Martin]

Hi Simon,

On 20 Aug 2012, at 12:56, Simon Schampijer si...@schampijer.de wrote:

 Hi,
 
 I have been thinking a bit about how we can enhance the interaction with the 
 search entries in the Shell so they will work well in touch as well [1].
 
 When you have a touchscreen device focusing an entry will automatically bring 
 up the onscreen keyboard (OSK). We are currently doing this in the Home 
 View/Neighborhood View and in the Journal. For keyboard devices this makes 
 absolute sense, having first to move the pointer towards the entry, click on 
 it before you can type in the search is a too long interaction. With a touch 
 interface however it is ok to touch the search field to bring up the OSK in 
 most of the cases. Otherwise the OSK might cover parts of the screen without 
 need.
 
 I would suggest the following new behavior:
 
 - the entry is unfocused by default, the canvas is focused

+1

 - the entry contains a hint (e.g. Search in your Journal...), adding a 
 placeholder text is available in GTK+3.2 [2]

Nice find. The place holder text would need to vary from place to place e.g. 
Search journal, Search neighbourhood, Search group [1], Search favourite 
activities, Search all activities.

 - when the user starts typing the entry is focused automatically (listening 
 on the canvas and switching focus)

+1

 I think this will give a good behavior for both worlds.

Yes, agreed. The search placeholder text also provides additional context 
indicating which view you might be in. At one point we discussed the 
possibility of adding each zoom view icon to each view's toolbar to improve 
context, but that design wasn't complete, the search placeholder text would be 
a step in that direction.

Regards,
--Gary

[1] The Group view still doesn't have a minimal toolbar or search facilities ;)

 I have attached as well a GTK+ 3 example. Let me know what you think.
 
 Regards,
   Simon
 
 [1] 
 http://wiki.sugarlabs.org/go/Features/Touch/Development#Reveal_on_text_input_focus.2C_auto_.2A.2Adismiss.2A.2A_on_loss_of_focus
 [2] 
 http://developer.gnome.org/gtk3/3.4/GtkEntry.html#gtk-entry-set-placeholder-text
 
 focus_entry.py___
 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] Testing Rotate in sugar-jhbuild

[Manuel Quiñones]

2012/8/19 Gonzalo Odiard gonz...@laptop.org:

 I've been thinking for quite some time that we need a new approach to
 the problem of toolbar items following off the end of the toolbar This
 problem will be greatly exacerbated by the more frequent use of screen
 rotate one would expect with more use of tablet mode on XO 4.0 Touch.
 Most activities have not taken into account the potential squeezing of
 the toolbar by 25% even of they take into consideration general
 resizing of the screen due to rotation.

 A simple solution would be to double the vertical size of the toolbar
 and wrap the icons onto a second row.

 comments?


 It's a really good question.
 I am thinking another: We really need rotate the toolbar?
 May be had more sense when the old toolbar had text in the tabs...
 Is very difficult design a interface making good use of the toolbar size,
 and have a option were the toolbar have half the size.
 Not all the activities have this problem, but if have more than six buttons,
 probably yes.

 Maybe we can use the toolbar vertical, in the long side of the screen,
 and rotate the icons and the palettes.
 The problem with this approach are the activities with wide widgets in the
 toolbars.

I don't think this is an option as we have text entries.  For example
always for the title, in the main toolbar or in the activity
sobtoolbar.  I've seen that rotate icons toolbars for example in the
android while taking photos, but that's a icons-only toolbar.

 Another option is have the option of inhibit rotate in a activity,
 but is not so easy, what happen when the user switch activities?

-1 to inhibit rotate, this is an overall feature.of Sugar.

-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Call For Proposals: OLPC SF Community Summit 2012

[rihowa...@gmail.com]

OLPC-SF has opened proposal submission for the 2012 Community Summit
held in San Francisco, California during the weekend of October
19th-21st. Submission form here:

http://olpcsf.org/submit-proposal-2012

Workshops range from topics in Technology to Education to Outreach and
are generally in the range of 60-75 minutes. Group organized workshops
are also encouraged. You can read more about proposal submission on our
blog:

http://olpcsf.org/node/66


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] SpreadLayout: do not remove items from the grid if there is none yet, SL #3814

[Manuel Quiñones]

Good fix.  I was seeing this issue of not initialized grid in the
shell port too.

2012/8/19 Simon Schampijer si...@schampijer.de:
 A grid is added to the ViewContainer when the children
 are allocated, we can not do it earlier because we need to
 pass the allocation details. The allocation happens when
 the children needs to be shown. Therefore if the container
 and it's children have not been shown yet, removing the
 child from the grid would fail.

 This patch does check if a grid exists already before trying
 to remove items from it.

 Signed-off-by: Simon Schampijer si...@laptop.org

Acked-by: Manuel Quiñones ma...@laptop.org

 ---
  src/jarabe/desktop/favoriteslayout.py | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/src/jarabe/desktop/favoriteslayout.py 
 b/src/jarabe/desktop/favoriteslayout.py
 index 0f63f95..e0ee80e 100644
 --- a/src/jarabe/desktop/favoriteslayout.py
 +++ b/src/jarabe/desktop/favoriteslayout.py
 @@ -150,6 +150,11 @@ class SpreadLayout(ViewLayout):
  ViewLayout.__init__(self)

  def remove(self, child):
 +if self._grid is None:
 +# the Grid is created during allocation time, so it might not
 +# exist yet when this method is called, SL #3814
 +return
 +
  if self._grid.is_in_grid(child):
  self._grid.remove(child)

 --
 1.7.11.4

 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel



-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Testing Rotate in sugar-jhbuild

[Gary Martin]

Hi Walter,

On 20 Aug 2012, at 00:57, Walter Bender walter.ben...@gmail.com wrote:

 On Thu, Aug 16, 2012 at 5:27 PM, Gary Martin garycmar...@googlemail.com 
 wrote:
 Hi Walter,
 
 
 On 16 Aug 2012, at 16:53, Walter Bender walter.ben...@gmail.com wrote:
 
 On Thu, Aug 16, 2012 at 11:36 AM, Gonzalo Odiard gonz...@laptop.org wrote:
 
 In anybody want test how activities work with the screen rotated in
 
 sugar-jhbuid,
 
 can do in the terminal:
 
 
 xrandr -o left
 
 
 when your neck hurts, or you have finished...
 
 
 xrandr -o normal
 
 
 Gonzalo
 
 
 ___
 
 Sugar-devel mailing list
 
 Sugar-devel@lists.sugarlabs.org
 
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 
 
 Works great. Check out
 http://wiki.sugarlabs.org/images/c/cb/Portfolio-27.xo which support
 rotation. But I am curious why the stop button runs off the edge... it
 would appear there is plenty of room for it.
 
 
 Not sure if this is your issue (my land line has been down most of the day
 and am on GSM network), but invisible separators still take space unless you
 explicitly tell them not to:
 
separator.set_size_request(0, -1)
 
 So your separator factory might need a tweak. See Physics activity.py line
 103 for a working example.
 
 Regards,
 --Gary
 
 
 -walter
 
 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel
 
 I've been thinking for quite some time that we need a new approach to
 the problem of toolbar items following off the end of the toolbar This
 problem will be greatly exacerbated by the more frequent use of screen
 rotate one would expect with more use of tablet mode on XO 4.0 Touch.
 Most activities have not taken into account the potential squeezing of
 the toolbar by 25% even of they take into consideration general
 resizing of the screen due to rotation.

I know this is a tough line to take, but we should file tickets against 
activities that overflow in portrait orientation – that includes Physics and 
Calculate ;)

It is quite an effort making a complicated multi-function Activity appear 
simple, but letting activity developers off the hook to pile on features 
without keeping their UI under control seems like a loosing direction to take. 
Max ten icons in the toolbar (that includes the Activity toolbar icon and the 
Stop toolbar icon). We've had decent sub-toolbar support in Sugar for a long 
time now, lets make sure we prioritising that primary tool bar space and 
putting the less used features into secondary toolbars.

Regards,
--Gary

 A simple solution would be to double the vertical size of the toolbar
 and wrap the icons onto a second row.
 
 comments?
 
 -walter
 -- 
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Testing Rotate in sugar-jhbuild

[Walter Bender]

On Mon, Aug 20, 2012 at 12:25 PM, Gary Martin
garycmar...@googlemail.com wrote:
 Hi Walter,

 On 20 Aug 2012, at 00:57, Walter Bender walter.ben...@gmail.com wrote:

 On Thu, Aug 16, 2012 at 5:27 PM, Gary Martin garycmar...@googlemail.com 
 wrote:
 Hi Walter,


 On 16 Aug 2012, at 16:53, Walter Bender walter.ben...@gmail.com wrote:

 On Thu, Aug 16, 2012 at 11:36 AM, Gonzalo Odiard gonz...@laptop.org wrote:

 In anybody want test how activities work with the screen rotated in

 sugar-jhbuid,

 can do in the terminal:


 xrandr -o left


 when your neck hurts, or you have finished...


 xrandr -o normal


 Gonzalo


 ___

 Sugar-devel mailing list

 Sugar-devel@lists.sugarlabs.org

 http://lists.sugarlabs.org/listinfo/sugar-devel



 Works great. Check out
 http://wiki.sugarlabs.org/images/c/cb/Portfolio-27.xo which support
 rotation. But I am curious why the stop button runs off the edge... it
 would appear there is plenty of room for it.


 Not sure if this is your issue (my land line has been down most of the day
 and am on GSM network), but invisible separators still take space unless you
 explicitly tell them not to:

separator.set_size_request(0, -1)

 So your separator factory might need a tweak. See Physics activity.py line
 103 for a working example.

 Regards,
 --Gary


 -walter

 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

 I've been thinking for quite some time that we need a new approach to
 the problem of toolbar items following off the end of the toolbar This
 problem will be greatly exacerbated by the more frequent use of screen
 rotate one would expect with more use of tablet mode on XO 4.0 Touch.
 Most activities have not taken into account the potential squeezing of
 the toolbar by 25% even of they take into consideration general
 resizing of the screen due to rotation.

 I know this is a tough line to take, but we should file tickets against 
 activities that overflow in portrait orientation – that includes Physics and 
 Calculate ;)

 It is quite an effort making a complicated multi-function Activity appear 
 simple, but letting activity developers off the hook to pile on features 
 without keeping their UI under control seems like a loosing direction to 
 take. Max ten icons in the toolbar (that includes the Activity toolbar icon 
 and the Stop toolbar icon). We've had decent sub-toolbar support in Sugar for 
 a long time now, lets make sure we prioritising that primary tool bar space 
 and putting the less used features into secondary toolbars.

 Regards,
 --Gary

 A simple solution would be to double the vertical size of the toolbar
 and wrap the icons onto a second row.

 comments?

 -walter
 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org


OK. I can accept that decision, but I expect that many many activities
will have to change (including all the Turtle Art variants).

-walter

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [RELEASE] sugar-0.97.1

[Simon Schampijer]

The 'no-hippo' release.

== Source ==

http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.97.1.tar.bz2

== News ==

* Release 0.97.1 (Simon Schampijer)
* SpreadLayout: do not remove items from the grid if there is none yet, SL 
#3814 (Simon Schampijer)
* Use the gdk window to get the depth of the preview pixmap - SL#3804 (Manuel 
Quiñones)
* Debug log before and after running ssh-keygen (Daniel Narvaez)
* Journal, no-hippo: set white background for no-matching-entry message, SL 
#3808 (Simon Schampijer)
* Update Sucrose version for upcoming 0.97.1 (Simon Schampijer)
* Drop unused intro.py (Daniel Narvaez)
* Remove hippo mentions (Daniel Narvaez)
* Views: Replace the hippo based layout with one using GTK+ containers (Simon 
Schampijer, Manuel Quiñones, Daniel Drake, Walter Bender, Raul Gutierrez 
Segales)
* ControlPanel AboutMe section: use the EventIcon from the shell (Simon 
Schampijer)
* SugarEventIcon: Add a hippo-free implementation of the CanvasIcon (Simon 
Schampijer)
* Allow to build outside the source directory (Daniel Narvaez)
* Commit from Sugar Labs: Translation System by user cjl.: 5 of 387 messages 
translated (33 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 358 of 387 messages 
translated (14 fuzzy). (Pootle daemon)
* Drop obsolete and non-functional sugar-ui-check script (Daniel Narvaez)
* Enable gnome-keyring-daemon to start inside emulated session (Daniel Narvaez)
* Commit from Sugar Labs: Translation System by user cjl.: 285 of 387 messages 
translated (14 fuzzy). (Pootle daemon)
* post-branch catch up, Pushing many PO files (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 93 of 387 messages 
translated (5 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 50 of 387 messages 
translated (19 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 152 of 387 messages 
translated (9 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 188 of 387 messages 
translated (46 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 0 of 387 messages 
translated (43 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 258 of 387 messages 
translated (9 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 260 of 389 messages 
translated (9 fuzzy). (Pootle daemon)
* sugar-session: disable Metacity mouse button modifiers, OLPC #11781 (Daniel 
Drake)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 212 of 389 messages 
translated (4 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 183 of 387 messages 
translated (4 fuzzy). (Pootle daemon)
* Commit from Sugar Labs: Translation System by user cjl.: 387 of 387 messages 
translated (0 fuzzy). (Pootle daemon)
* Push many PO files (Pootle daemon)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] SpreadLayout: do not remove items from the grid if there is none yet, SL #3814

[Simon Schampijer]

On 08/20/2012 05:45 PM, Manuel Quiñones wrote:

Good fix.  I was seeing this issue of not initialized grid in the
shell port too.

2012/8/19 Simon Schampijer si...@schampijer.de:

A grid is added to the ViewContainer when the children
are allocated, we can not do it earlier because we need to
pass the allocation details. The allocation happens when
the children needs to be shown. Therefore if the container
and it's children have not been shown yet, removing the
child from the grid would fail.

This patch does check if a grid exists already before trying
to remove items from it.

Signed-off-by: Simon Schampijer si...@laptop.org


Acked-by: Manuel Quiñones ma...@laptop.org


Thanks for the quick review. Pushed, is part of the 'no-hippo' release 
0.97.1.


Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Is there a way to purposefully do synchronous GUI updates?

[Ajay Garg]

Hi all.

I frequently happen to encounter cases, where GUI updates do not happen in
the in-order manner.
For eg, if the code is on the lines ::

  logic statement 1
  update GUI
  logic statement 2



the actual procedure that happens is ::

 logic statement 1
 logic statement 2
 update GUI




However, if I do something like

 logic statement 1
 update GUI
 gobject.idle_add(logic statement 2)

the procedure now runs in in-order.



The above is not a problem for such trivial cases, but it IS a problem,
when we want to have seemingly in-order GUI updates, when the code runs
deep.


So, is there a way to have the code always in-order; in other words, have
the GUI updates absolutely synchronous?


WIll be grateful for a reply.


Thanks and Regards,
Ajay
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] conversations about sugar ui design

[Sebastian Silva]

We have an opportunity in Peru to do some experiments. - WB

Hi David,
As a member of the Somos Azucar research  development team and direct
responsible for the software distribution prototypes to be piloted in
Peru, I warmly welcome your constructive offer of help.
We (Laura and I) are responsible for the Sugar Network sketches presented
to you by Aleksey, who is doing the back-end implementation to support 
specific functionality.

It is important to underline that the Sugar Network client (webui) is an 
experimental intervention that hopes to facilitate knowledge exchange
within an initial environment (Sugar and Sugar Activities in Perú).
Of course, there are a wide set of constraints (**).

You can find more information about the Sugar Network project as it is
being implemented for Perú at: http://pe.sugarlabs.org/go/Red_Az%C3%BAcar

Specific goals of the system are: to provide a de-centralized network for 
feedback, support and learning resources exchange and distribution.

The current UI implementation is expected to evolve quickly and our
goal is to have a 1.0 release by December 2012 with main functionality.

The UI dev strategy has been to rely on standard HTML+CSS+JS in order to 
facilitate rapid UI experimentation by the widest possible group of people 
including ourselves.

So far we've sought to directly expose functionality, trying to follow 
Sugar's UI style and paradigms of simplicity, reflection and collaboration.
However we are at a stage of reflection into how to better expose 
functionality to reflect the system's stated goals to the local community.

As for a design forum, Sugar Network is hoped to become such a forum where
feedback can be collected with the purpose of improving specific system
components (for example, Sugar itself). Your feedback / proposals for improving
the Sugar Network experience are welcome and will be taken into consideration.

I recommend installing Sugar Network locally from the sweets-desktop packages
for you to be able to explore functionality specific to Sugar.
Regards,
Sebastian

(**) most notable constraints in no particular order:
- (almost) no connectivity
- slow hardware / crappy touchpads
- language/cultural barrier
- remote locations
- not skilled deployment personnel
- disreputed laptop project
- conflicted national education system


On Mon, 20 Aug 2012 13:56:39 +1000
David Brown djhbr...@gmail.com wrote:

 this note embraces several different emails from Aleksey and Walter
 
  What you see on http://network-testing.sugarlabs.org
  is a first rough and implementation for webui,
 
 you have put quite some effort into presenting your sketches, Aleksey:
 whilst that is in itself impressive, i'm not keen on the sketches
 themselves:  using icons instead of words is presumably an attempt to
 make the ui accessible to the illiterate, but in my view it only
 complicates matters.  icons would be effective if they were
 universally obvious a priori, but that is not possible - icons have to
 be learned just as do the symbols of any alphabet.  mother tongue is
 preferable, as it contributes to the learning of literacy useful in
 the broader context of the language world within which they live.  a
 single release of a ui could have a feature that allows the ui to be
 displayed in any of the languages that have been implemented.
 
 the choices of names are developer-oriented rather than user-oriented:
 for example, the name turtle-art makes sense only to people who are
 already familiar with Logo.  Whereas, draw a picture (or its
 translation) would make sense to any kid who can read her mother
 tongue.  for those who can't read, a thumbnail of a half-finished
 painting and a brush might work - it would take up more pixels than an
 icon, but i don't think there should be many app-triggers on view at
 the same time.
 
 with 69 apps already mooted (and presumably a thousand more waiting to
 be added), that creates a navigation issue which needs to be
 addressed.  i feel that it could be done by creating categories of
 activity (such as learn, play and meet) and subcategories etc,
 making a simple tree structure (or maybe a network with cross-links).
 the one thing i am sure of is that trying to put buttons for
 everything on one screen creates information overload.
 
-- 
Sebastian Silva sebast...@somosazucar.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] unfocus search entries in Views and the Journal

[Manuel Quiñones]

2012/8/20 Gary Martin garycmar...@googlemail.com:
 Hi Simon,

 On 20 Aug 2012, at 12:56, Simon Schampijer si...@schampijer.de wrote:

 Hi,

 I have been thinking a bit about how we can enhance the interaction with the 
 search entries in the Shell so they will work well in touch as well [1].

 When you have a touchscreen device focusing an entry will automatically 
 bring up the onscreen keyboard (OSK). We are currently doing this in the 
 Home View/Neighborhood View and in the Journal. For keyboard devices this 
 makes absolute sense, having first to move the pointer towards the entry, 
 click on it before you can type in the search is a too long interaction. 
 With a touch interface however it is ok to touch the search field to bring 
 up the OSK in most of the cases. Otherwise the OSK might cover parts of the 
 screen without need.

 I would suggest the following new behavior:

 - the entry is unfocused by default, the canvas is focused

 +1

 - the entry contains a hint (e.g. Search in your Journal...), adding a 
 placeholder text is available in GTK+3.2 [2]

 Nice find. The place holder text would need to vary from place to place e.g. 
 Search journal, Search neighbourhood, Search group [1], Search 
 favourite activities, Search all activities.

On one hand it provides context, agreed.  On the other, it adds text
in the Sugar views.  I thought the magnifying glass icon was enough
metaphor.  Specially in the home spiral, which is the face of Sugar,
this placeholder would be the only text in it.  Not saying I'm not
open to change, just pointing this out.

 - when the user starts typing the entry is focused automatically (listening 
 on the canvas and switching focus)

 +1

+1 this is indeed a better behaviour.  Testing the OSK it becomes
obvious that autofocus the entry should not be the default for touch
mode.


 I think this will give a good behavior for both worlds.

 Yes, agreed. The search placeholder text also provides additional context 
 indicating which view you might be in. At one point we discussed the 
 possibility of adding each zoom view icon to each view's toolbar to improve 
 context, but that design wasn't complete, the search placeholder text would 
 be a step in that direction.

 Regards,
 --Gary

 [1] The Group view still doesn't have a minimal toolbar or search facilities 
 ;)

 I have attached as well a GTK+ 3 example. Let me know what you think.

 Regards,
   Simon

 [1] 
 http://wiki.sugarlabs.org/go/Features/Touch/Development#Reveal_on_text_input_focus.2C_auto_.2A.2Adismiss.2A.2A_on_loss_of_focus
 [2] 
 http://developer.gnome.org/gtk3/3.4/GtkEntry.html#gtk-entry-set-placeholder-text

 focus_entry.py___
 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



-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Journal: confirmation before erasing/duplicating an entry

[Manuel Quiñones]

2012/8/19 Simon Schampijer si...@schampijer.de:
 Hi,

 I have been working on the confirmation alert for the Journal, submitted a
 patch [1].

 Erasing an entry in the Journal does not ask for confirmation
 before doing the erase. This patch adds an alert to the ListView
 and the DetailView that asks for confirmation before doing the
 erase. This is part of the touch interaction work [2].

 I think the need is clear, I just want to confirm the wording of the message
 and title.

This will erase the object... can also work, but I think This will
erase the entry... works better.

 About the alert for the duplication. I am not 100% convinced it is needed.

+1 to not add an alert in duplication too.

 There is not much harm in duplicating an entry (unless it is really big). I
 try to avoid confirmation alerts when possible. I think the only thing which
 is critical is feedback in that case. In the ListView the feedback is given.
 Duplicating an entry in the DetailView lacks a bit the feedback what has
 happened. Long term an animation would be nice here. Short term options that
 would help giving feedback here (please not an alert:)?

What about a message duplicating entry... that dissapears in a few
seconds?  Yes, is an alert :) but without Accept/Cancel buttons.

-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Is there a way to purposefully do synchronous GUI updates?

[James Cameron]

On Tue, Aug 21, 2012 at 12:11:13AM +0530, Ajay Garg wrote:
 So, is there a way to have the code always in-order; in other words,
 have the GUI updates absolutely synchronous?

No, not without waiting for the update to complete, and if you do
this, the code runs very slowly.

(When there is only one CPU, only one process can execute on it at a
time.  The updates are placed in a pipeline to the display, and the
display process runs them as soon as it is practical to do so.  If
your process does not release the CPU, then your process will likely
continue executing until it hits something that will cause it to
release.  It is better to be specific and use idle_add to release.)

-- 
James Cameron
http://quozl.linux.org.au/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] gst-plugins-espeak port to gstreamer 1.0

[Aleksey Lim]

On Mon, Aug 20, 2012 at 05:28:04PM -0300, Flavio Danesse wrote:
 Hello, on this subject, I think it is not necessary to create a special
 plugin for sugar,

Sorry, what kind of plugins you mean?

 you can do the same in this way:
 Check it out at: http://git.sugarlabs.org/speak/mainline

There are also gst-plugins-espeak examples on wiki,
http://wiki.sugarlabs.org/go/Activity_Team/gst-plugins-espeak#Python_examples

-- 
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] unfocus search entries in Views and the Journal

[Gonzalo Odiard]

  - the entry contains a hint (e.g. Search in your Journal...), adding
 a placeholder text is available in GTK+3.2 [2]
 
  Nice find. The place holder text would need to vary from place to place
 e.g. Search journal, Search neighbourhood, Search group [1], Search
 favourite activities, Search all activities.

 On one hand it provides context, agreed.  On the other, it adds text
 in the Sugar views.  I thought the magnifying glass icon was enough
 metaphor.  Specially in the home spiral, which is the face of Sugar,
 this placeholder would be the only text in it.  Not saying I'm not
 open to change, just pointing this out.



But we have a lot of reports of people confusing the activity list view in
the home with the journal,
may be this change helps to avoid this issue.
+1 from my part.

Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Making the buddy icons in the Views reveal the Palette on left click or touch

[Simon Schampijer]

On 08/16/2012 02:07 PM, Manuel Quiñones wrote:

Very good Simon,

2012/8/15 Simon Schampijer si...@schampijer.de:

The owner icon (in the Home, Group and Neighborhood View) has
no primary action. On left click we agreed to always reveal the
Palette. This will give a better experience for users with a
mouse/trackpad and for those with a touchscreen.

This patch also changes the behavior of the buddy icons that
represent other learners which appear in the Neighborhood
and Group View. Here as well we do not have currently a primary
action. Left click does currently not do anything. We change this
to revealing the Palette on left click now as well.


Nice description.  I think this changes improve the mouse interaction
in addition to prepare Sugar for touch.  They are welcome.

I'm testing them on the XO too.


Signed-off-by: Simon Schampijer si...@laptop.org


Acked-by: Manuel Quiñones ma...@laptop.org


Thanks Manuel for the review and testing, I pushed it as
071e534d44a2294ca8e27fe854a16644fc8e35d7

Regards,
   Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Neighborhood View: reveal Palette on left click/touch instead of a primary action

[Simon Schampijer]

On 08/16/2012 02:10 PM, Manuel Quiñones wrote:

2012/8/15 Simon Schampijer si...@schampijer.de:

Having a primary action for the icons in the Neighborhood View
like the AP icon, the Ad-hoc, the Mesh network icon and the icon
for a shared activity has never been a fully working UI design because
the result you get by clicking on the icon was not fully clear to
the user (e.g. I clicked on the AP icon to connect to it, when I
click again will it deconnect?).

With the mouse you have a way of discovering secondary information
by hovering over the icon, this is not as elegant with touch. You would
need to use touchhold for that but the 'failure' rate of
undesired actions is much higher.

In long discussions with Gary we agreed on always revealing the
Palette on left-click/touch and giving the learner the
information to make his choice. We think this is the best behavior
for both worlds.

For the SugarAdhoc Palette we make sure it has the connect option in
the Palette. Until now, the Palette did only have the connect
option shown when the device state had changed once.

This patch applies on top of Making the buddy icons in the Views
reveal the Palette on left click or touch

Signed-off-by: Simon Schampijer si...@laptop.org


Acked-by: Manuel Quiñones ma...@laptop.org


Thanks for the review, pushed as 682c6c2fdebb8dcc2ee16ece2330c4d840806273

Regards,
   Simon

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Frame: new behavior for revealing/hiding the Frame with the mouse

[Simon Schampijer]

On 08/20/2012 05:06 PM, Manuel Quiñones wrote:

2012/8/20 Simon Schampijer si...@schampijer.de:

On 08/20/2012 04:44 PM, Manuel Quiñones wrote:


2012/8/17 Simon Schampijer si...@schampijer.de:


On 08/17/2012 12:48 AM, Manuel Quiñones wrote:



I've tested an earlier patch for this and now I reviewed it.  This is
a much more solid interaction with the frame, and less error prone.

All looks good.  Please commit.




Thanks Manuel for testing and the review. I have fixed the 'cycling
through
activities' in v2 of the patch.

Something we have to look at as a follow-up would be the Frame
'animation'.
When you switch between the Home View and the Neighborhood View for
example
you see the Frame disappear and then the toolbar is drawn. And in general
the Frame animation should really be smoother...



Yes, and that makes me think, why not leave the frame open while
switching zoom views?  I think that would be better.



The idea is to have the upper Frame section (Views and Activities) behave
the same. The primary action for those should be switching between them. But
after I switched the Frame should be away so I can interact with the new
Zoom level/Activity I am in.


I understand.  So yes, for consistency's sake is ok.  We should fix
the toolbar appearence then.


Thanks for all the feedback on this one Manuel,
pushed this one as 238338d4b5d6a065eb81bd118a8c0b7ca83717bf

About the Frame behavior in regards to the CP, I remember we had some 
discussions on that already, maybe Gary can chime in.


Regards,
   Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Journal: confirmation before erasing/duplicating an entry

[Simon Schampijer]

On 08/20/2012 11:21 PM, Manuel Quiñones wrote:

2012/8/19 Simon Schampijer si...@schampijer.de:

Hi,

I have been working on the confirmation alert for the Journal, submitted a
patch [1].

Erasing an entry in the Journal does not ask for confirmation
before doing the erase. This patch adds an alert to the ListView
and the DetailView that asks for confirmation before doing the
erase. This is part of the touch interaction work [2].

I think the need is clear, I just want to confirm the wording of the message
and title.


This will erase the object... can also work, but I think This will
erase the entry... works better.


About the alert for the duplication. I am not 100% convinced it is needed.


+1 to not add an alert in duplication too.


There is not much harm in duplicating an entry (unless it is really big). I
try to avoid confirmation alerts when possible. I think the only thing which
is critical is feedback in that case. In the ListView the feedback is given.
Duplicating an entry in the DetailView lacks a bit the feedback what has
happened. Long term an animation would be nice here. Short term options that
would help giving feedback here (please not an alert:)?


What about a message duplicating entry... that dissapears in a few
seconds?  Yes, is an alert :) but without Accept/Cancel buttons.


Yes, I thought about that as well, actually. In the ListView I think 
feedback is great, in the DetailView not so much, so the alert would be 
only in the DetailView?


Simon




___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH sugar] Fix drag and drop to the clipboard - SL #3811

[Manuel Quiñones]

gtk.gdk.DragContext.get_source_widget returns None if the drag is not
made within the same application.  This is enough test to say that
it's not an internal drag.  The gtk.Viewport comparison is left as
fallback.

Signed-off-by: Manuel Quiñones ma...@laptop.org
---
 src/jarabe/frame/clipboardtray.py | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/src/jarabe/frame/clipboardtray.py 
b/src/jarabe/frame/clipboardtray.py
index 37d5e1a..779ffed 100644
--- a/src/jarabe/frame/clipboardtray.py
+++ b/src/jarabe/frame/clipboardtray.py
@@ -216,7 +216,10 @@ class ClipboardTray(tray.VTray):
 context.drop_finish(True, gtk.get_current_event_time())
 
 def _internal_drag(self, context):
-view_ancestor = context.get_source_widget().get_ancestor(gtk.Viewport)
+source_widget = context.get_source_widget()
+if source_widget is None:
+return False
+view_ancestor = source_widget.get_ancestor(gtk.Viewport)
 if view_ancestor is self._viewport:
 return True
 else:
-- 
1.7.11.2

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Fix drag and drop to the clipboard - SL #3811

[Manuel Quiñones]

2012/8/21 Manuel Quiñones ma...@laptop.org:
 gtk.gdk.DragContext.get_source_widget returns None if the drag is not
 made within the same application.

pygtk documentation for reference:
http://www.pygtk.org/docs/pygtk/class-gdkdragcontext.html#method-gdkdragcontext--get-source-widget

This is enough test to say that
 it's not an internal drag.  The gtk.Viewport comparison is left as
 fallback.

 Signed-off-by: Manuel Quiñones ma...@laptop.org
 ---
  src/jarabe/frame/clipboardtray.py | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

 diff --git a/src/jarabe/frame/clipboardtray.py 
 b/src/jarabe/frame/clipboardtray.py
 index 37d5e1a..779ffed 100644
 --- a/src/jarabe/frame/clipboardtray.py
 +++ b/src/jarabe/frame/clipboardtray.py
 @@ -216,7 +216,10 @@ class ClipboardTray(tray.VTray):
  context.drop_finish(True, gtk.get_current_event_time())

  def _internal_drag(self, context):
 -view_ancestor = 
 context.get_source_widget().get_ancestor(gtk.Viewport)
 +source_widget = context.get_source_widget()
 +if source_widget is None:
 +return False
 +view_ancestor = source_widget.get_ancestor(gtk.Viewport)
  if view_ancestor is self._viewport:
  return True
  else:
 --
 1.7.11.2




-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel