[Sugar-devel] [DESIGN] Zoom to width icon
Gary, Here is the icon I am using in Read. Comments welcomed Gonzalo <>___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Zoom to width icon
Hi Gonzalo, On 15 Aug 2012, at 13:13, Gonzalo Odiard wrote: > Gary, > > Here is the icon I am using in Read. > Comments welcomed Fab thanks. Looks good :) Please find the attached clean up version removing all the inkscape xml junk an unnecessary tags. Should go into sugar-artwork with the others. Note that I've not reviewed Daniels ML proposal yet to remove certain grey fill from some of the artwork icons (zoom ones specifically), so we may need revisit this (and others) at some point, though your icon is consistent with the current icons right now for landing it. Regards, --Gary > Gonzalo > <>___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-gtk3-0.96.5
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.96.5.tar.bz2 == News == * Release 0.96.5 (Simon Schampijer) * Replace signal used in UnfullscreenButton to enable use with touch - SL #3798 (Gonzalo Odiard) * Solve errors in ColorToolButton to enable activities to use it (Manuel Quiñones) * Add accelerator functionality to the ToggleToolButton, SL #3774 (Daniel Francis) * presence: use RoomConfig1 to configure channel properties (#3629) (Daniel Drake) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 35 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 23 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 32 of 40 messages translated (1 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 39 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 30 of 40 messages translated (1 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 13 of 40 messages translated (1 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 3 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 0 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 30 of 40 messages translated (1 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 39 of 40 messages translated (1 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user aputsiaq.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-gtk3-0.97.0
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit-gtk3/sugar-toolkit-gtk3-0.97.0.tar.bz2 == News == * Release 0.97.0 (Simon Schampijer) * Replace signal used in UnfullscreenButton to enable use with touch - SL #3798 (Gonzalo Odiard) * Solve errors in ColorToolButton to enable activities to use it (Manuel Quiñones) * Allow to build outside source directory (Daniel Narvaez) * EventIcon: update to the latest implementation used in the shell port (Simon Schampijer) * Add accelerator functionality to the ToggleToolButton, SL #3774 (Daniel Francis) * Commit from Sugar Labs: Translation System by user cjl.: 4 of 40 messages translated (2 fuzzy). (Pootle daemon) * presence: use RoomConfig1 to configure channel properties (#3629) (Daniel Drake) * Icon: remove documentation that has not much of a value (Simon Schampijer) * EventIcon: Have a default create_palette method (Simon Schampijer) * EventIcon: all the events go directly to the event box (Simon Schampijer) * EventIcon: Make the child window of the event box invisible (Simon Schampijer) * Commit from Sugar Labs: Translation System by user cjl.: 25 of 40 messages translated (0 fuzzy). (Pootle daemon) * post-branch catch up, Pushing many PO files (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 31 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 30 of 40 messages translated (1 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 39 of 40 messages translated (1 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 1 of 40 messages translated (18 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 35 of 35 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) * Commit from Sugar Labs: Translation System by user cjl.: 40 of 40 messages translated (0 fuzzy). (Pootle daemon) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-artwork-0.96.5
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.96.5.tar.bz2 == News == * Release 0.96.5 (Manuel Quiñones) * Fix the label text color for checkboxes and radiobuttons in the toolbars and the palettes (Manuel Quiñones) * A scrolled window inside a palette should have a black background - SL #3751 (Gonzalo Odiard) * Apply same style in toolbar RadioToolButton than in the palette SL#3739 SL#3765 (Gonzalo Odiard) * Add help icon for the toolbars - SL #3746 (Manuel Quiñones) * Set background color for GtkTreeView rows with odd-even flags SL #3726 (Manuel Quiñones) * Make the GtkImage background transparent SL #3723 (Manuel Quiñones) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-artwork-0.97.0
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-artwork/sugar-artwork-0.97.0.tar.bz2 == News == * Release 0.97.0 (Manuel Quiñones) * Fix the label text color for checkboxes and radiobuttons in the toolbars and the palettes (Manuel Quiñones) * A scrolled window inside a palette should have a black background - SL #3751 (Gonzalo Odiard) * Apply same style in toolbar RadioToolButton than in the palette SL#3739 SL#3765 (Gonzalo Odiard) * Allow to build outside the source directory (Daniel Narvaez) * Add help icon for the toolbars - SL #3746 (Manuel Quiñones) * Set background color for GtkTreeView rows with odd-even flags SL #3726 (Manuel Quiñones) * Make the GtkImage background transparent SL #3723 (Manuel Quiñones) * Theme ScrolledWindow frame - SL #3561 (Manuel Quiñones) * Make toolbars black background SL #3403 (Manuel Quiñones) * Theme GtkSpinButton buttons SL #3406 (Manuel Quiñones) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unicode strings in translations
On Mon, Aug 13, 2012 at 2:47 PM, S. Daniel Francis
wrote:
> I don't see why do you need to use unicode in this case, you could
> encode all in utf-8 and forget the conflict.
Here you are another good reason to use Unicode instead any other
encoding. A simple test case:
How many letters has the word: "camión" (Spanish Word)? -> ("truck" in
English) . Let's see what Python says
First, I will try to use the way that I'm proposing because I like
Unicode and because using Unicode is *the way to do it*
>>> len(u"camión")
6
Oh, it's OK. I agree with the result. Now, let's check what Python say
if I use my default encoding (UTF8) for this simple task:
>>> len("camión")
7
So, this is really important to have the correct result here. If we
don't use Unicode we will have bugs all around our code and bugs like
this are difficult to find out.
I propose to make this change (gettext returns Unicode) JUST in the
sugar-toolkit-gtk3 to start doing the things in the right way from now
on. Applying this patch at the sugar-toolkit (gtk2) could convey many
problems with the activities that have already hacked this problem.
See you,
--
Kaufmann Manuel
Blog: http://humitos.wordpress.com/
Porfolio: http://fotos.mkaufmann.com.ar/
PyAr: http://www.python.com.ar/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Add icon zoom-to-width
Was made by Gonzalo Odiard for Read activity, based in other zoom icons. And was cleaned by Gary Martin for inclussion in the Sugar Artwork. Signed-off-by: Manuel Quiñones --- icons/scalable/actions/zoom-to-width.svg | 9 + 1 file changed, 9 insertions(+) create mode 100644 icons/scalable/actions/zoom-to-width.svg diff --git a/icons/scalable/actions/zoom-to-width.svg b/icons/scalable/actions/zoom-to-width.svg new file mode 100644 index 000..650af3b --- /dev/null +++ b/icons/scalable/actions/zoom-to-width.svg @@ -0,0 +1,9 @@ +http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>http://www.w3.org/2000/svg"; xmlns:xlink="http://www.w3.org/1999/xlink";> + + + + + + + + \ No newline at end of file -- 1.7.11.2 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unicode strings in translations
On Wed, Aug 15, 2012 at 9:20 AM, Manuel Kaufmann wrote:
> Oh, it's OK. I agree with the result. Now, let's check what Python say
> if I use my default encoding (UTF8) for this simple task:
>
len("camión")
> 7
CAREFUL HERE. You don't understand what is happening -- it is not as
simple as you think it is.
When you say len("camión"), you are writing that from a terminal
(Gnome's Terminal, Sugar Terminal, xterm) that is set to use utf-8.
However, Python expects the sequence between " characters to be
straight ASCII (with a codepage). So your terminal IS sending to
Python what looks like 7 chars -- definitely 7 bytes.
However, there is an ASCII representation of "camión" that has 6
bytes, using the Latin-1 codepage. In fact, install an old Linux
system, open an xterm or a VT, retry your example and you'll probably
see that camión has 6 bytes.
I agree we should all use Unicode, specifically UTF-8, everywhere. We
should also make an effort to understand the mechanics of what is
actually happening behind the scenes.
cheers,
m
--
martin.langh...@gmail.com
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unicode strings in translations
I think the reason this worked in gtk2 activities is that importing
gtk had this side effect (it's in the pango module really)
/* set the default python encoding to utf-8 */
PyUnicode_SetDefaultEncoding("utf-8");
As you can see
>>> u'¡Hola %s!' % 'camión'
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
4: ordinal not in range(128)
>>> import gtk
>>> u'¡Hola %s!' % 'camión'
u'\xa1Hola cami\xf3n!'
Now I don't really like changing default encoding as a side effect but
the simpler solution is probably to just reinstate that, either in
pygi or in sugar-toolkit. Then with python 3 hopefully stuff will work
without this kind of hacks.
On 13 August 2012 18:35, Manuel Kaufmann wrote:
> Hello,
>
> I'm working on Typing Turtle Gtk3 port and I found an error with the
> translations encoding. The thing is we can't combine Unicode strings
> and 8-bits strings:
>
>
'¡Hola %s!' % 'camión'
> '\xc2\xa1Hola cami\xc3\xb3n!'
>
u'¡Hola %s!' % u'camión'
> u'\xa1Hola cami\xf3n!'
>
'¡Hola %s!' % u'camión'
> Traceback (most recent call last):
> File "", line 1, in
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position
> 0: ordinal not in range(128)
>
u'¡Hola %s!' % 'camión'
> Traceback (most recent call last):
> File "", line 1, in
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
> 4: ordinal not in range(128)
>
>
> In Typing Turle the _ function (from gettext import gettext as _) is
> returning 8-bits strings, so it crashes when it tries to do something
> like this:
>
> _('Congratulations! You earned a %(type)s medal!') % u'gold'
> [...]
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
> 4: ordinal not in range(128)
>
> But, if we don't mix Unicode and 8-bits strings it's possible to replace them:
>
_('Congratulations! You earned a %(type)s medal!')
> "Felicidades! Has obtenido una medalla de %(type)s!"
_('Congratulations! You earned a %(type)s medal!') % {'type': 'ORO'}
> "Felicidades! Has obtenido una medalla de ORO!"
>
> To get Unicode strings from gettext I had to put these lines in my
> lesssonscreen.py file:
>
> import gettext
> gettext.install('po', unicode=True)
>
_('Congratulations! You earned a %(type)s medal!')
> u"Felicidades! Has obtenido una medalla de %(type)s!"
_('Congratulations! You earned a %(type)s medal!') % {'type': u'ORO'}
> "Felicidades! Has obtenido una medalla de ORO!"
>
> So, is there a way to make this available at Sugar level? This issue
> appears in many activities and it would be great to solve it
> "upstream" :)
>
> Thanks,
>
> Reference: http://docs.python.org/library/gettext.html
>
> --
> Kaufmann Manuel
> Blog: http://humitos.wordpress.com/
> Porfolio: http://fotos.mkaufmann.com.ar/
> PyAr: http://www.python.com.ar/
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
--
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Zoom to width icon
Great, I will remove it from the activity as soon as is included in sugar-artwork Gonzalo On Wed, Aug 15, 2012 at 9:42 AM, Gary Martin wrote: > Hi Gonzalo, > > On 15 Aug 2012, at 13:13, Gonzalo Odiard wrote: > > > Gary, > > > > Here is the icon I am using in Read. > > Comments welcomed > > Fab thanks. Looks good :) > > Please find the attached clean up version removing all the inkscape xml > junk an unnecessary tags. Should go into sugar-artwork with the others. > > Note that I've not reviewed Daniels ML proposal yet to remove certain grey > fill from some of the artwork icons (zoom ones specifically), so we may > need revisit this (and others) at some point, though your icon is > consistent with the current icons right now for landing it. > > Regards, > --Gary > > > Gonzalo > > > > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unicode strings in translations
2012/8/15 Daniel Narvaez :
> I think the reason this worked in gtk2 activities is that importing
> gtk had this side effect (it's in the pango module really)
>
> /* set the default python encoding to utf-8 */
> PyUnicode_SetDefaultEncoding("utf-8");
>
> As you can see
>
u'¡Hola %s!' % 'camión'
> Traceback (most recent call last):
> File "", line 1, in
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
> 4: ordinal not in range(128)
import gtk
u'¡Hola %s!' % 'camión'
> u'\xa1Hola cami\xf3n!'
>
> Now I don't really like changing default encoding as a side effect but
> the simpler solution is probably to just reinstate that, either in
> pygi or in sugar-toolkit. Then with python 3 hopefully stuff will work
> without this kind of hacks.
Reported bug based on Daniel's findings:
https://bugzilla.gnome.org/show_bug.cgi?id=681915
--
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unicode strings in translations
On Wed, Aug 15, 2012 at 9:48 AM, Daniel Narvaez wrote:
> I think the reason this worked in gtk2 activities is that importing
> gtk had this side effect (it's in the pango module really)
>
> /* set the default python encoding to utf-8 */
> PyUnicode_SetDefaultEncoding("utf-8");
Oh, can you do that? Excellent. Perhaps it's a good idea to include
that in early-execution Sugar shell code, and in Sugar toolkit.
> Now I don't really like changing default encoding as a side effect but
> the simpler solution is probably to just reinstate that, either in
Perhaps inelegant if you were note expecting it. However, I think it
is a sane statement: all Python code in Sugar and activities is in
utf-8. Any strings are utf-8,even if we forget to add the "u"
prefix...
cheers,
m
--
martin.langh...@gmail.com
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add icon zoom-to-width
Looks good, please get it in. Simon On 08/15/2012 03:27 PM, Manuel Quiñones wrote: Was made by Gonzalo Odiard for Read activity, based in other zoom icons. And was cleaned by Gary Martin for inclussion in the Sugar Artwork. Signed-off-by: Manuel Quiñones --- icons/scalable/actions/zoom-to-width.svg | 9 + 1 file changed, 9 insertions(+) create mode 100644 icons/scalable/actions/zoom-to-width.svg diff --git a/icons/scalable/actions/zoom-to-width.svg b/icons/scalable/actions/zoom-to-width.svg new file mode 100644 index 000..650af3b --- /dev/null +++ b/icons/scalable/actions/zoom-to-width.svg @@ -0,0 +1,9 @@ +http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>http://www.w3.org/2000/svg"; xmlns:xlink="http://www.w3.org/1999/xlink";> + + + + + + + + \ No newline at end of file ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unicode strings in translations
2012/8/14 Gonzalo Odiard :
>> - Strings with format
>> Example:
>> button.set_tooltip(_('Append %s') % _('something'))
>>
>
> The problem with this example is when you have language like Spanish,
> where some of the characters can be encoded in ascii, but not all.
> In this case, gettext will return a str or a PyUnicode depending of the
> case,
> and if are not compatibles, the format will break.
>
Well, the PyUnicode type is recommended for index and modify a string,
Manuel gave a good example, but there aren't the necessary cases at
activities for use the PyUnicode format as default in the
translations, non-ascii characters often need more than a byte for
save the character in the memory and the Python str class is made for
index byte per byte, not character per character. That's the main
difference between the Python types str and PyUnicode.
The Python strings are encoded by default in the utf-8 code charset
thanks to the heather line. Another function of the PyUnicode type is
encode a resultant string of type str.
So, the Python strings can be encoded in a Unicode compatible charset
like utf-8, the Python Unicode type is a way to encode a string if you
don't like to add a header and the recommended way to work in the
program internally, so you mustn't use it for output, you will have to
encode the content of type PyUnicode in a PyString with the UTF-8
charset for the output and it'll not generate any conflict.
Cheers.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unicode strings in translations
On Wed, Aug 15, 2012 at 11:40 AM, S. Daniel Francis wrote: > So, the Python strings can be encoded in a Unicode compatible charset > like utf-8, the Python Unicode type is a way to encode a string if you > don't like to add a header and the recommended way to work in the > program internally, so you mustn't use it for output, you will have to > encode the content of type PyUnicode in a PyString with the UTF-8 > charset for the output and it'll not generate any conflict. In general, yes, the switch to assuming strings are in UTF-8 format will not cause any conflict. Specially since we used to have that before, as others pointed out. Outside of existing Sugar code, you have to be careful with libraries that deal with binary data. Before utf-8, handling binary data and handling strings was just about the same. For example, a sequence of bytes and a sequence of chars would both work transparently with len() and general array manipulations (ie: myvar[33]). So for example, a pure python zip compression/decompression implementation now needs to clearly define it is _not_ working on utf-8 streams. We aren't really making an ASCII to UTF-8 transition, we are restoring UTF-8-as-default. So this is not an issue. But anytime you make such a transition, you have to review & retest any code working with raw binary data. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- Software Architect - OLPC - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH sugar] Making the buddy icons in the Views reveal the Palette on left click or touch
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.
Signed-off-by: Simon Schampijer
---
src/jarabe/desktop/groupbox.py | 11 +++
src/jarabe/desktop/meshbox.py | 11 ++-
src/jarabe/view/buddyicon.py | 6 ++
3 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/src/jarabe/desktop/groupbox.py b/src/jarabe/desktop/groupbox.py
index 4fcd6c2..8beec90 100644
--- a/src/jarabe/desktop/groupbox.py
+++ b/src/jarabe/desktop/groupbox.py
@@ -21,6 +21,7 @@ import gconf
from sugar.graphics import style
from sugar.graphics.xocolor import XoColor
+from jarabe.view.buddyicon import BuddyIcon
from jarabe.view.buddymenu import BuddyMenu
from jarabe.view.eventicon import EventIcon
from jarabe.model.buddy import get_owner_instance
@@ -38,15 +39,9 @@ class GroupBox(ViewContainer):
layout = SpreadLayout()
-client = gconf.client_get_default()
-color = XoColor(client.get_string('/desktop/sugar/user/color'))
-owner_icon = EventIcon(icon_name='computer-xo', cache=True,
- xo_color=color)
# Round off icon size to an even number to ensure that the icon
-# is placed evenly in the grid
-owner_icon.props.pixel_size = style.LARGE_ICON_SIZE & ~1
-owner_icon.set_palette(BuddyMenu(get_owner_instance()))
-
+owner_icon = BuddyIcon(get_owner_instance(),
+ style.LARGE_ICON_SIZE & ~1)
ViewContainer.__init__(self, layout, owner_icon)
self._friends = {}
diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/meshbox.py
index 1de3779..8ac5047 100644
--- a/src/jarabe/desktop/meshbox.py
+++ b/src/jarabe/desktop/meshbox.py
@@ -410,18 +410,11 @@ class MeshContainer(ViewContainer):
__gtype_name__ = 'SugarMeshContainer'
def __init__(self):
-
layout = SpreadLayout()
-client = gconf.client_get_default()
-color = XoColor(client.get_string('/desktop/sugar/user/color'))
-owner_icon = EventIcon(icon_name='computer-xo', cache=True,
- xo_color=color)
# Round off icon size to an even number to ensure that the icon
-# is placed evenly in the grid
-owner_icon.props.pixel_size = style.STANDARD_ICON_SIZE & ~1
-owner_icon.set_palette(BuddyMenu(get_owner_instance()))
-
+owner_icon = BuddyIcon(get_owner_instance(),
+ style.STANDARD_ICON_SIZE & ~1)
ViewContainer.__init__(self, layout, owner_icon)
diff --git a/src/jarabe/view/buddyicon.py b/src/jarabe/view/buddyicon.py
index 663bd92..e84e881 100644
--- a/src/jarabe/view/buddyicon.py
+++ b/src/jarabe/view/buddyicon.py
@@ -15,6 +15,7 @@
# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
from sugar.graphics import style
+from sugar.graphics.palette import Palette
from jarabe.view.buddymenu import BuddyMenu
from jarabe.view.eventicon import EventIcon
@@ -33,6 +34,8 @@ class BuddyIcon(EventIcon):
self._buddy.connect('notify::present', self.__buddy_notify_present_cb)
self._buddy.connect('notify::color', self.__buddy_notify_color_cb)
+self.connect('button-release-event', self.__button_release_event_cb)
+
self.palette_invoker.cache_palette = False
self._update_color()
@@ -40,6 +43,9 @@ class BuddyIcon(EventIcon):
def create_palette(self):
return BuddyMenu(self._buddy)
+def __button_release_event_cb(self, icon, event):
+self.props.palette.popup(immediate=True, state=Palette.SECONDARY)
+
def __buddy_notify_present_cb(self, buddy, pspec):
# Update the icon's color when the buddy comes and goes
self._update_color()
--
1.7.11.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add icon zoom-to-width
Pushed as 9ce110b 2012/8/15 Simon Schampijer : > Looks good, please get it in. > Simon > > > On 08/15/2012 03:27 PM, Manuel Quiñones wrote: >> >> Was made by Gonzalo Odiard for Read activity, based in other zoom >> icons. And was cleaned by Gary Martin for inclussion in the Sugar >> Artwork. >> >> Signed-off-by: Manuel Quiñones >> --- >> icons/scalable/actions/zoom-to-width.svg | 9 + >> 1 file changed, 9 insertions(+) >> create mode 100644 icons/scalable/actions/zoom-to-width.svg >> >> diff --git a/icons/scalable/actions/zoom-to-width.svg >> b/icons/scalable/actions/zoom-to-width.svg >> new file mode 100644 >> index 000..650af3b >> --- /dev/null >> +++ b/icons/scalable/actions/zoom-to-width.svg >> @@ -0,0 +1,9 @@ >> +> 'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>> enable-background="new 0 0 55 55" height="55px" version="1.1" viewBox="0 0 >> 55 55" width="55px" xml:space="preserve" xmlns="http://www.w3.org/2000/svg"; >> xmlns:xlink="http://www.w3.org/1999/xlink";> >> + >> +> style="fill:#808284;stroke:#ff;stroke-width:3.5" /> >> + > style="fill:none;stroke:#ff;stroke-width:3.5" /> >> + > style="fill:#ff;stroke:#ff;stroke-width:2.26210141;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4" >> /> >> + > style="fill:#ff;stroke:#ff;stroke-width:2.26210141;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4" >> /> >> + > style="fill:#ff;stroke:#ff;stroke-width:2.6189;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4" >> /> >> + >> + >> \ No newline at end of file >> > > ___ > 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] Unicode strings in translations
2012/8/15 Martin Langhoff : > So for example, a pure python zip compression/decompression > implementation now needs to clearly define it is _not_ working on > utf-8 streams. It started when Humitos saw the Python Unicode handling at Typing Turtle. His purpose is setup gettext for get translated data of type PyUnicode instead of PyString. A big part of the translated messages are often tooltips for the toolbars and other static text. You can get those strings and set them as property of a SugarToolButton without the word unicode in all your activity code. What TypingTurtle does, could be well because it's a long internal work with the strings, but it isn't the same with the big part of the translated messages. Your example doesn't compress translated text; so get translations as PyUnicode for that case is useless. I see you are also looking other issues in this same thread, I'll say +1 to all the good practices with the objective of remove the repetitive code. Use unicode=True as argument for gettext.install could do more short the task with TypingTurtle, but it will be more long at other activities . Cheers. ~danielf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH sugar] Neighborhood View: reveal Palette on left click/touch instead of a primary action
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 touch&hold 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
---
src/jarabe/desktop/meshbox.py | 14 --
src/jarabe/desktop/networkviews.py | 10 +++---
2 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/src/jarabe/desktop/meshbox.py b/src/jarabe/desktop/meshbox.py
index 8ac5047..412a093 100644
--- a/src/jarabe/desktop/meshbox.py
+++ b/src/jarabe/desktop/meshbox.py
@@ -64,7 +64,8 @@ class _ActivityIcon(EventIcon):
EventIcon.__init__(self, file_name=file_name,
xo_color=xo_color, pixel_size=size)
self._model = model
-self.connect('button-release-event', self._button_release_cb)
+self.connect('button-release-event',
+ self.__button_release_event_cb)
def create_palette(self):
primary_text = glib.markup_escape_text(self._model.bundle.get_name())
@@ -82,21 +83,22 @@ class _ActivityIcon(EventIcon):
if joined:
item = MenuItem(_('Resume'), 'activity-start')
-item.connect('activate', self._clicked_cb)
+item.connect('activate', self.__palette_item_clicked_cb)
item.show()
p.menu.append(item)
elif not private:
item = MenuItem(_('Join'), 'activity-start')
-item.connect('activate', self._clicked_cb)
+item.connect('activate', self.__palette_item_clicked_cb)
item.show()
p.menu.append(item)
return p
-def _button_release_cb(self, widget, event):
-return self._clicked_cb(item=None)
+def __button_release_event_cb(self, widget, event):
+self.props.palette.popup(immediate=True,
+ state=palette.Palette.SECONDARY)
-def _clicked_cb(self, item):
+def __palette_item_clicked_cb(self, item):
bundle = self._model.get_bundle()
misc.launch(bundle, activity_id=self._model.activity_id,
color=self._model.get_color())
diff --git a/src/jarabe/desktop/networkviews.py
b/src/jarabe/desktop/networkviews.py
index d2531bf..83269e0 100644
--- a/src/jarabe/desktop/networkviews.py
+++ b/src/jarabe/desktop/networkviews.py
@@ -330,7 +330,8 @@ class WirelessNetworkView(EventPulsingIcon):
self._connect()
def __button_release_event_cb(self, icon, event):
-self._connect()
+self._palette.popup(immediate=True,
+state=palette.Palette.SECONDARY)
def _connect(self):
# Activate existing connection, if there is one
@@ -489,6 +490,7 @@ class SugarAdhocView(EventPulsingIcon):
self._connect_item = MenuItem(_('Connect'), 'dialog-ok')
self._connect_item.connect('activate', self.__connect_activate_cb)
palette_.menu.append(self._connect_item)
+self._connect_item.show()
self._disconnect_item = MenuItem(_('Disconnect'), 'media-eject')
self._disconnect_item.connect('activate',
@@ -498,7 +500,8 @@ class SugarAdhocView(EventPulsingIcon):
return palette_
def __button_release_event_cb(self, icon, event):
-get_adhoc_manager_instance().activate_channel(self._channel)
+self._palette.popup(immediate=True,
+state=palette.Palette.SECONDARY)
def __connect_activate_cb(self, icon):
get_adhoc_manager_instance().activate_channel(self._channel)
@@ -688,7 +691,8 @@ class OlpcMeshView(EventPulsingIcon):
self._connect()
def __button_release_event_cb(self, icon, event):
-self._connect()
+self._palette.popup(immediate=True,
+state=palette.Palette.SECONDARY)
def _connect(self):
self._mesh_mgr.user_activate_channel(self._channel)
--
1.7.11.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/su
Re: [Sugar-devel] pixels to centimeters
2012/8/13 Flavio Danesse :
> Hey.
>
> I'm trying to build a GUI for touch screen and want the widgets have certain
> dimensions in inches or millimeters, so I need to convert from pixels to
> centimeters or millimeters.
>
> So the query is:
>
> How do I convert pixels to centimeters?
>
> What I found on the web is about to 1 pixel measured 0.03 inches
> apromadamente, but in practice the numbers did not close.
>
> I tried doing something like this:
>
> gi import
> gi.repository import from GdkX11
>
> screen = GdkX11.X11Screen()
>
> After which, with: screen.width () get the horizontal resolution 1366, which
> multiplied by 0.03 gives me 40.98 while my monitor actually measures 34.5
> cm.
>
> Another function of GdkX11: screen.width_mm () returns me 361 millimeters.
>
>
> Hola.
>
> Estoy intentando construir una interfaz gráfica para touch screen y quiero
> que los widgets tengan determinadas dimensiones en centímetros o milímetros,
> por lo cual necesito convertir de pixels a centímetros o a milímetros.
>
> De modo que la consulta es:
>
> ¿Cómo convierto pixels a centímetros?
>
> Lo que he encontrado en la web gira en torno a que 1 pixel mide
> apromadamente 0.03 centímetros, pero en la práctica los números no me
> cierran.
>
> He intentado hacer algo como esto:
>
> import gi
> from gi.repository import GdkX11
>
> screen = GdkX11.X11Screen()
>
> Luego de lo cual, con: screen.width() obtengo la resolución horizontal 1366,
> lo cual multiplicado por 0.03 me da 40.98 mientras que mi monitor mide en
> realidad 34.5 cm.
>
> Otra función de GdkX11: screen.width_mm() me devuelve 361 milímetros.
>
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
As per CJL's suggestion, here is what I do in Ruler:
def calc_dpi():
'''Looking for 'dimensions' line in xdpyinfo
dimensions:1280x800 pixels (339x212 millimeters)'''
(status, output) = commands.getstatusoutput('/usr/bin/xdpyinfo')
if status == 0:
strings = output[find(output, 'dimensions:'):].split()
w = int(strings[1].split('x')[0]) # e.g., 1280x800
mm = int(strings[3][1:].split('x')[0]) # e.g., (339x212)
return int((w * 25.4 / mm) + 0.5), True
else:
# just in case the above fails
return 96, False
regards.
-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] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer
On Sun, Aug 12, 2012 at 8:48 PM, Gary Martin wrote: > Hi Anish, > > I've uploaded a mockup image to the wiki [1] which covers most of the items > raised in this thread: > > - a new security section (that should only be shown if there is lease > information) > - lease number of days remaining > - lease absolute expiry date (date string should use correct formatting to > display locale date format) > > Did I miss anything? One nit: There is no such thing as Sugar Labs Inc. Should be: Sugar Labs, a member project of the Software Freedom Conservancy. regards. -walter > > Regards, > --Gary > > [1] > http://wiki.sugarlabs.org/go/File:Settings_About_My_Computer_Security_Section_Mockup.png > > On 7 Aug 2012, at 17:55, Anish Mangal wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi Daniel, >> >> Thanks for replying! >> >> On Tuesday 07 August 2012 10:12 PM, Daniel Drake wrote: >>> On Wed, Aug 1, 2012 at 1:12 PM, Anish Mangal >>> wrote: One problem they were also trying to get around in Paraguay is that during vacations, the kids don't go to the schools and hence the leases expire. If the kids also know about this information, then they can easily make sure that they don't get 'locked out' >>> >>> You'd hope that the project would make provisions for long-enough >>> leases to be supplied before the vacations. But I can see the use >>> for this for when that doesn't happen (which is understandable >>> given high workloads and so on). >>> >>> Talking more with the team in Nicaragua, this functionality would >>> be useful for them too. Similar situations are occuring here where >>> laptops were activated for a certain amount of time, with the >>> strong expectation that internet connectivity would become >>> available in the schools before the activations expire (so that >>> they can be automatically updated/renewed). These expectations look >>> like they won't turn out to be true :( >>> >>> So a manual activation update process will happen and the ability >>> for someone less-technical to be able to quickly check whether this >>> manual update process has completed OK would be of value (that >>> would be the person's only contact with activations - we aren't >>> expecting them to be able to solve any problems if the results are >>> bad, other than report up the chain). >>> >> >> This is exactly the kind of clear info that should have been in the >> feature page in the first place. Sorry for not doing it earlier. >> >>> Anyway, the use cases you describe in your mail don't seem to be >>> described on the feature page. Could you please extend the feature >>> page to go into more detail about this? I'll then add the above >>> local case if its of interest. >>> >> >> +1 >> >>> >>> Why is the proposal to show the number of days remaining? >>> >> >> Yes, I remember discussing specifically this with Roberto (PyEduca >> Technical head) back in Dec 2010, and my suggestion was exactly the >> same (to display the date). >> >> However, as per them (and I know this is not a rational explanation), >> they wanted us to display "no of days remaining". >> >>> The Nicaraguan team have expressed a strong preference that this >>> should (instead, or additionally) display the expiry date. When >>> dealing with long duration activations, which is often the case >>> (until good connectivity is established), having a teacher phone up >>> and say "there are 137 days remaining" (and then having to >>> calculate the day of expiry in order to put an appropriately timed >>> school visit on the calendar) would be a pain. >>> >> >> I agree with this, and since I cannot seem to remember exactly why >> they wanted it to display in terms of no. of days remaining, I'll ping >> them or we can go with this. >> Since this feature is only relevant for the XO at the moment, making use of the bitfrost API would be acceptable to me, but I don't see a lot wrong here by parsing the lease.sig directly. This file is supposed to be automatically generated/updated in normal use cases. >>> >>> Are you planning to parse sig02 (delegated leases) "by hand" as >>> well? What if the lease is corrupt in some way? >>> >>> I can see myself objecting to any implementation of this that >>> doesn't reuse bitfrost. It takes care of all of the corner cases >>> and will avoid code duplication. >>> >> >> Again, it seemed to solve the use case we had in Paraguay, and the >> idea behind upstreaming a feature is that it goes through this process >> of review. I am up for changing the code to use the bitfrost api. It >> should not be complex (if it's adequately documented somewhere). >> >>> Daniel ___ Sugar-devel >>> mailing list Sugar-devel@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/sugar-devel >>> >> >> >> - -- >> Anish Mangal >> Dextrose Project Manager >> Activity Central >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.12 (GNU/Linux) >>
Re: [Sugar-devel] Maintenance, reviews, QA & co
On Sun, Aug 12, 2012 at 2:19 PM, Bernie Innocenti wrote: > Improving the development process is as important as improving the code > itself, so I think it's good to have this sort of discussion every once > in a while. > > About 2 years ago I started a similar discussion on this mailing list > because I thought that our development process was slow and frustrating. > Some things have improved since then, but I feel there's still a lot of > room for further improvement. > > I've not been involved with Sugar development for quite a long time, so > I can't offer any specific advice. If the Sugar maintainers are > interested, I could share some details on the Google review process, > (which is really excellent in my opinion) or the GCC and Linux review > processes, which might be a better fit for a free software project. > > > On Sat, 2012-08-11 at 22:53 +0200, Sascha Silbe wrote: >> Dear Sugar Labs members, >> >> == Executive Summary == >> >> The current review process isn't a good fit for the current Sugar >> contributors and causes a lot of frustration on both sides. There are >> better ways to reach the same goals. The two major changes to the review >> process I'll propose in this email are making in-depth reviews by >> independent senior developers optional and non-blocking as well as >> accepting "no ceiling" and standards compliance patches into >> mainline. Other work to address some of the goals of the previous review >> process has already been going one for quite some time. >> >> >> == Why we should rethink our current approach == >> >> I think it's time to take a step back and reconsider our current >> approach for reviews and QA. For the past few months to years, upstream >> reviews were primarily a QA measure. While hopefully many contributors >> learned to be better developers, the focus clearly was on making sure >> that only "good" patches were merged into mainline. That's the way many >> (maybe most) community-driven Open Source projects work: Downstream >> needs to show their contribution is of value to upstream (including not >> having a negative impact on other parts of the user base) and does not >> impair maintainability. >> >> Sugar, however, currently isn't a community project: Most of the work is >> done by a small number of organisations with a clear commercial >> focus. They have deadlines breathing down their neck and need to care >> about what their costumers want (who are the ones keeping these >> organisations alive), not what's in the interest of the general user >> base. The paying customers are what keeps these organisations alive and >> the organisations in turn are what keeps Sugar Labs alive. The small >> number and similar focus of the organisations means there's not enough >> diversity to address a more general user base. >> >> Tight deadlines and focus on the needs of paying customers doesn't >> really mix with the style of reviews done by community-driven >> projects. This regularly results in frustration on both sides. >> >> We should think about what we want to achieve and how to best achieve >> it. Maybe we still want reviews to take place, but in a different >> manner. Maybe we'll just do something else and do away with reviews. But >> simply continuing the current way is not a good idea. >> >> >> == Goals == >> >> So what do we want to achieve? Some options: >> >> 1. Few obvious mistakes: Making sure the code doesn't contain a lot of >>mistakes that could have been easily spotted by some other developer, >>resulting in bugs affecting the user. >> >> 2. Few bugs affecting the user: Making sure there are few regressions >>and new features work as expected. >> >> 3. Few hard to fix bugs: Making sure that the risk of introducing bugs >>that are hard to diagnose and fix (usually race conditions) is low. >> >> 4. Maintainability: Making sure that the cost of doing code changes >>(including QA as necessary for 1. and 2.) doesn't grow in the long >>term. >> >> 5. Better developers: Constantly increasing our own and others' >>abilities and knowledge. >> >> >> == Means == >> >> There are various ways to achieve one or more of the goals above: >> >> A. Eating our own dog food >> B. Private reviews done amongst colleagues >> C. Public reviews done amongst colleagues >> D. Public in-depth reviews done by senior developers >> E. Public short reviews done by senior developers >> F. Requiring public short reviews by senior developers, usually from >>within the same organisation, before pushing changes >> G. Requiring public in-depth reviews by independent, senior developers >>(AKA upstream maintainers) before pushing changes >> H. Manual UI/UX tests >> J. Automated tests (UI tests, unit tests, etc.) >> K. Automated code checks (e.g. pylint, pep8) >> L. Leveraging the community of upstream components >> >> >> == Proposal == >> >> All of the means listed above have different trade-offs, there's no >> silver bullet. Review bandwidth of senior de
Re: [Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer
On 15 Aug 2012, at 20:14, Walter Bender wrote: > On Sun, Aug 12, 2012 at 8:48 PM, Gary Martin > wrote: >> Hi Anish, >> >> I've uploaded a mockup image to the wiki [1] which covers most of the items >> raised in this thread: >> >> - a new security section (that should only be shown if there is lease >> information) >> - lease number of days remaining >> - lease absolute expiry date (date string should use correct formatting to >> display locale date format) >> >> Did I miss anything? > > One nit: There is no such thing as Sugar Labs Inc. Should be: Sugar > Labs, a member project of the Software Freedom Conservancy. Good catch, this mockup was based on a quick screen grab of the soon to be released 12.1, and wasn't aware of it being updated recently. Hmmm. Not sure who I'd need to bother to correct the license text. Regards, --Gary > > regards. > > -walter >> >> Regards, >> --Gary >> >> [1] >> http://wiki.sugarlabs.org/go/File:Settings_About_My_Computer_Security_Section_Mockup.png >> >> On 7 Aug 2012, at 17:55, Anish Mangal wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Hi Daniel, >>> >>> Thanks for replying! >>> >>> On Tuesday 07 August 2012 10:12 PM, Daniel Drake wrote: On Wed, Aug 1, 2012 at 1:12 PM, Anish Mangal wrote: > One problem they were also trying to get around in Paraguay is > that during vacations, the kids don't go to the schools and hence > the leases expire. If the kids also know about this information, > then they can easily make sure that they don't get 'locked out' You'd hope that the project would make provisions for long-enough leases to be supplied before the vacations. But I can see the use for this for when that doesn't happen (which is understandable given high workloads and so on). Talking more with the team in Nicaragua, this functionality would be useful for them too. Similar situations are occuring here where laptops were activated for a certain amount of time, with the strong expectation that internet connectivity would become available in the schools before the activations expire (so that they can be automatically updated/renewed). These expectations look like they won't turn out to be true :( So a manual activation update process will happen and the ability for someone less-technical to be able to quickly check whether this manual update process has completed OK would be of value (that would be the person's only contact with activations - we aren't expecting them to be able to solve any problems if the results are bad, other than report up the chain). >>> >>> This is exactly the kind of clear info that should have been in the >>> feature page in the first place. Sorry for not doing it earlier. >>> Anyway, the use cases you describe in your mail don't seem to be described on the feature page. Could you please extend the feature page to go into more detail about this? I'll then add the above local case if its of interest. >>> >>> +1 >>> Why is the proposal to show the number of days remaining? >>> >>> Yes, I remember discussing specifically this with Roberto (PyEduca >>> Technical head) back in Dec 2010, and my suggestion was exactly the >>> same (to display the date). >>> >>> However, as per them (and I know this is not a rational explanation), >>> they wanted us to display "no of days remaining". >>> The Nicaraguan team have expressed a strong preference that this should (instead, or additionally) display the expiry date. When dealing with long duration activations, which is often the case (until good connectivity is established), having a teacher phone up and say "there are 137 days remaining" (and then having to calculate the day of expiry in order to put an appropriately timed school visit on the calendar) would be a pain. >>> >>> I agree with this, and since I cannot seem to remember exactly why >>> they wanted it to display in terms of no. of days remaining, I'll ping >>> them or we can go with this. >>> > Since this feature is only relevant for the XO at the moment, > making use of the bitfrost API would be acceptable to me, but I > don't see a lot wrong here by parsing the lease.sig directly. > This file is supposed to be automatically generated/updated in > normal use cases. Are you planning to parse sig02 (delegated leases) "by hand" as well? What if the lease is corrupt in some way? I can see myself objecting to any implementation of this that doesn't reuse bitfrost. It takes care of all of the corner cases and will avoid code duplication. >>> >>> Again, it seemed to solve the use case we had in Paraguay, and the >>> idea behind upstreaming a feature is that it goes through this process >>> of review. I am up for changing the c
Re: [Sugar-devel] Unicode strings in translations
On Wed, Aug 15, 2012 at 10:40 AM, Martin Langhoff
wrote:
> len("camión")
>> 7
>
> CAREFUL HERE. You don't understand what is happening -- it is not as
> simple as you think it is.
>
> When you say len("camión"), you are writing that from a terminal
> (Gnome's Terminal, Sugar Terminal, xterm) that is set to use utf-8.
I don't agree with you on this point, but maybe I'm wrong.
Take a look at this. Following what I understood from your email, if I
set the encoding inside the Python script I won't have this problem,
right?
[humitos@michifus ~]$ cat test.py
#!/usr/bin/python
# -*- coding: utf-8 -*-
s = 'camión'
print 'UTF-8, set by the first line in the script'
print 'len:', len(s)
print 'last but one letter:', s[-2]
print 'second to last:', s[-3]
print
s = u'camión'
print 'Unicode'
print 'len:', len(s)
print 'last but one letter:', s[-2]
print 'second to last:', s[-3]
[humitos@michifus ~]$ python test.py
UTF-8, set by the first line in the script
len: 7
last but one letter: �
second to last:
Unicode
len: 6
last but one letter: ó
second to last: i
[humitos@michifus ~]$
Changing the default encoding, as you said, is dangerous because we
will be hiding the problem instead of resolving it. gtk people say
this on the comments in the ticket that manuq reported.
So, the right way to handle and manipulate strings is using Unicode,
with the "u" at the beginning of each string. That is the recommended
way to do it. This is not me, I mean, it is not a whim. There are many
reasons to use Unicode.
More information that you can read, pros and cons:
*
http://www.shutupandship.com/2012/01/working-with-text-in-python-use-unicode.html
*
http://stackoverflow.com/questions/1116449/should-i-use-unicode-string-by-default
* http://blog.ianbicking.org/illusive-setdefaultencoding.html
* http://nedbatchelder.com/blog/200401/printing_unicode_from_python.html
* http://getpython3.com/diveintopython3/strings.html#one-ring-to-rule-them-all
* http://blog.notdot.net/2010/07/Getting-unicode-right-in-Python
See you around,
--
Kaufmann Manuel
Blog: http://humitos.wordpress.com/
Porfolio: http://fotos.mkaufmann.com.ar/
PyAr: http://www.python.com.ar/
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unicode strings in translations
On Wed, Aug 15, 2012 at 8:12 PM, Manuel Kaufmann wrote: > More information that you can read, pros and cons: * http://packages.python.org/kitchen/unicode-frustrations.html -- Kaufmann Manuel Blog: http://humitos.wordpress.com/ Porfolio: http://fotos.mkaufmann.com.ar/ PyAr: http://www.python.com.ar/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unicode strings in translations
2012/8/15 Manuel Kaufmann : > [humitos@michifus ~]$ python test.py > UTF-8, set by the first line in the script > len: 7 > last but one letter: � We agree sometimes you could need the unicode for solve some conflicts like this, but: How many translated strings are indexed by the programs? I'm really sure there are too many activities where the program doesn't iterate the string or any other possible conflicts. > Changing the default encoding, as you said, is dangerous because we > will be hiding the problem instead of resolving it. gtk people say > this on the comments in the ticket that manuq reported. We are stopping in very technical details, but you're not wrong in it. Latin1 gives one bit for all the represented characters and the supported characters aren't as many as with utf-8, it's for languages with Latin derivation. > So, the right way to handle and manipulate strings is using Unicode, > with the "u" at the beginning of each string. That is the recommended > way to do it. This is not me, I mean, it is not a whim. There are many > reasons to use Unicode. The right way only for handle and manipulate strings internally, and a big part of the translated strings aren't handled or manipulated by the activities, they are tasks for other libraries, preferentially GTK, and it never generates a conflict for draw and format those strings (including line wrapping), but for test it, you can make a gtk.TextView in a python console and try to write only non-ascii characters (for natural English speakers, you could generate many ´strange´ characters with the keyboard distribution "English International"). > More information that you can read, pros and cons: > > * > http://www.shutupandship.com/2012/01/working-with-text-in-python-use-unicode.html > * > http://stackoverflow.com/questions/1116449/should-i-use-unicode-string-by-default > * http://blog.ianbicking.org/illusive-setdefaultencoding.html > * http://nedbatchelder.com/blog/200401/printing_unicode_from_python.html > * > http://getpython3.com/diveintopython3/strings.html#one-ring-to-rule-them-all > * http://blog.notdot.net/2010/07/Getting-unicode-right-in-Python Thanks, there is many information here for read. ~danielf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unicode strings in translations
On Wed, Aug 15, 2012 at 7:12 PM, Manuel Kaufmann wrote:
> Take a look at this. Following what I understood from your email, if I
...
We are veering far far offtopic from the subject. But string encoding
is an important topic, so I'll go offtopic.
> [humitos@michifus ~]$ cat test.py
> #!/usr/bin/python
> # -*- coding: utf-8 -*-
What is the context? Where are you typing this script? An xterm? A VT?
In OFW? Over a serial port? Over SSH?
In all cases, keystrokes have to be interpreted before you get the ó,
and the OS needs to decide what input it'll give to the editor, and
the editor needs to decide whether it will apply any translation.
> s = 'camión'
Think about this: this line in your script could be written in a
number of ways! ISO 8859-1 ("Latin codepage"), UTF-16, UTF-8, UTF-32
just to list the ones _you_ see most often.
But even in Unicode, there are _two_ ways to say ó -- you can say
"letter o with acute" or "acute, composable + letter o". Oops!
Try to install Yudit, or use iconv to transcode your nice python
script to a few other encodings -- then look at it with a hex viewer.
The thing is, when the python interpreter starts up, and reads _the
script_ it doesn't know what encoding it is in. UTF-8 looks
essentially identical to ISO 8859-1 -- so it cannot decide beforehand.
You say, I'm in a modern system, it'll be utf-8! But perhaps it's an
old script. Or your text editor is old and pre-unicode. How will
Python know?
Same applies to data files. That CSV file you are opening, maybe comes
from MS Excel on Windows 3.11, German edition. Oops! But we are more
used to thinking about data files -- every thing you know about data
files also applies to Python program files (they are string data!) and
to user input in the UI (except that you can usually ask the UI
toolkit or the env what encoding it's feeding you).
hth,
m
--
martin.langh...@gmail.com
mar...@laptop.org -- Software Architect - OLPC
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
