Tag : gnome

GNOME Marketing in Greece

Something that the Greek GNOME community has been missing was a good marketing effort to promote GNOME in Greece, both at local FLOSS conferences and online on the Twitters and Facebooks.

Efstathios Iosifidis came in to fill this marketing void. He is currently an active member of the Greek OpenSUSE team and helps with GNOME.

Among the first tasks was to apply for an allocation of GNOME 3 LiveDVDs, from the set of 10.000 disks that OpenSUSE donated to the GNOME Foundation. Vincent Untz has been extremely helpful and sent Efstathios four packs (400 DVD disks) and also about a dozen of GNOME t-shirts.

The first event we participated as Greek GNOME Community was FOSSCOMM, an annual two-day FOSS conference for the Greek free and open-source communities. About 450 people attended, and we had both a presentation and a booth.

Greek GNOME Presentation slides

Click image for Greek GNOME Presentation slides (PDF, 4.2MB)

The presentation was about the efforts of the Greek localisation team, and the introduction of GNOME 3.

Greek GNOME Booth at FOSSCOMM 2011 conference

Efstathios at the Greek GNOME Booth at FOSSCOMM 2011 conference

At this point we did not receive yet our allocation of the LiveDVDs, but Efstathios arranged with an OpenSUSE guest speaker (from Switzerland?) to bring GNOME material for the booth.

Greek GNOME community promotion leaflet (2x2)

Greek GNOME community promotion leaflet (2x2)

Our leaflet.

GNOME Buttons, homemade

GNOME Buttons, homemade

These are locally made GNOME buttons. Apparently there is a tool to make these quite easily.

The next conference was the EL/LAK (“FOSS” in Greek) conference, which is an annual conference that has been running for almost ten years. There were several invited speakers, including Italo Vignoli from The Document Foundation (which produces LibreOffice) and Stefano Zacchiroli (Debian Project Leader).

The conference takes place in four cities in Greece over three days. We managed to represent GNOME in two cities.

Tom Tryfonidis and Kostas Koudaras

Tom Tryfonidis and Kostas Koudaras (in charge of booth) at the booth at Larisa

GNOME booth at Larisa

GNOME booth at Larisa

GNOME booth at Salonica

GNOME booth at Salonica

Efstathios and Tom are also working on the Greek GNOME community website. Apart from the social networking features, we are trying to add more content to the website, including easy programming tutorials.

Πάροχοι mobile internet (3G) στην Ελλάδα και GNOME/Linux

Ο Dan Williams είναι ο βασικός προγραμματιστής για τα NetworkManager και ModemManager.

Πρόσφατα ανακοίνωσε τις νέες δυνατότητες που έχει ο NetworkManager 0.8.

Για να είναι σε θέση να γνωρίζει η διανομής σας όλες τις ιδιαιτερότητες του πάροχού σας για το mobile internet, μπορείτε να καταχωρήσετε τα στοιχεία ρυθμίσεων.

Τα στοιχεία που υπάρχουν ήδη για Ελλάδα είναι

<!-- Greece -->
<country code="gr">
			<network-id mcc="202" mnc="01"/>
			<apn value="3g-internet">
			<network-id mcc="202" mnc="05"/>
			<apn value="internet">
			<apn value="web.session">
				<name>Mobile Broadband On Demand</name>
			<network-id mcc="202" mnc="09"/>
			<network-id mcc="202" mnc="10"/>
			<apn value="gint.b-online.gr">

Πηγή: http://git.gnome.org/browse/mobile-broadband-provider-info/tree/serviceproviders.xml

Αν υπάρχουν άλλοι πάροχοι ή αν οι παραπάνω πληροφορίες θέλουν ανανέωση, είναι σημαντικό να γίνει τώρα. Τυχόν διορθώσεις που θα γίνουν σύντομα θα μπουν κατά πάσα πιθανότητα σε Ubuntu 10.04.1 (αλλιώς στο 10.10) και στη Fedora 13.

Ενημέρωση – Wind «;»: ρυθμίσεις WAP και Internet

Ενημέρωση – Q Telecom «Οικονομική καρτοκινητή»: ρυθμίσεις WAP και Internet

Ενημέρωση – Q Telecom «Συμβόλαιο»: ; (είναι ίδιο με παραπάνω;)

Ενημέρωση – Cosmote «»: ρυθμίσεις WAP+GPRS

Ενημέρωση – Cosmote «Internet On The Go»: ρυθμίσεις

guadec, gsoc l10n-el, ellak-conf


I am attending GUADEC this year, thanks to the sponsorship by the GNOME Foundation!


I am organising the GNOME Localisation BoF, which takes place on Friday, 10th July, 2009, at 17:00. I am also having a session on the GNOME translator command line tool gnome-i18n-manage-vcs on the same day at 15:00.


A few months ago, there was a program in Greece, along the lines of the Google Summer of Code, to help Greek developers in FLOSS projects. The program was organised by EELLAK, a Greek non-profit, composed of 25 institutions of the tertiary education and research centres. As it took place during the spring, it was nicknamed Greek Spring of Code (gsoc).

Apart from developing software, the program had a localisation angle, and we applied for the localisation of GNOME 2.26 to the Greek language. In practice, this meant that we had to lift the documentation translations from 32% to 100%, complete the remaining UI translations.


We achieved the goal 😉.

Many contributors helped in this effort; Jennie Petoumenou (also co-organiser in the effort), Marios Zindilis, Fotis Tsamis, Kostas Papadimas, Nikos Charonitakis, Sterios Prosiniklis, Giannis Katsampiris, Michalis Kotsarinis, Vasilis Kontogiannis and Socratis Vavilis.The overall task was difficult, and our team did an amazing task to complete the translations on time. Thank you all, and especially Jennie and Marios for undertaking huge chunks of the translation effort for this release.

Here are the GNOME EL 2.26 deliverables in HTML, PDF.


The fourth Greek FOSS (ELLAK) conference took place in Athens on the 19-20th June 2009.

p6190288 by Elias Chrysoheris.

We had our annual localisation meetup!

I organised a workshop on git, with a focus on how to use when starting into software development. There was emphasis on using github.com to host and manage the development. In addition, services such as github.com allow to cooperate during the development, making programming a more social and interesting task.

Finally, there was a presentation of the Greek GNOME team efforts for the last year.

Συνέδριο ΕΛΛΑΚ: Εξελληνισμός GNOME 2.26

Στις 19 Ιουνίου 2009 έγινε παρουσίαση του έργου εξελληνισμού του GNOME στο συνέδριο δημιουργών ΕΛ/ΛΑΚ.

Είχαμε την ευκαιρία να μιλήσουμε για το αποτέλεσμα του τελευταίου έργου εξελληνισμού του GNOME όπου ολοκληρώσαμε τη μετάφραση του GNOME 2.26 για το γραφικό περιβάλλον και την τεκμηρίωση στα ελληνικά.

Πριν ξεκινήσουμε στις αρχές της άνοιξης, είχαμε μεταφρασμένο ήδη το 32% της τεκμηρίωσης και το 87% του γραφικού περιβάλλοντος. Με το τέλος του έργου (πλήρης μετάφραση), για την τεκμηρίωση έχουμε μεταφράσει 343.000 λέξεις περίπου και για το γραφικό περιβάλλον 190.000 λέξεις.

Οι μεταφραστές που βοήθησαν στην έκδοση αυτή είναι

  • Μάριος Ζηντίλης
  • Τζένη Πετούμενου
  • Στέργιος Προσινικλής
  • Φώτης Τσάμης
  • Γιάννης Κατσαμπίρης
  • Μιχάλης Κοτσαρίνης
  • Βασίλης Κοντογιάννης
  • Σωκράτης Βαβύλης
  • Κώστας Παπαδήμας (pkst)
  • Νίκος Χαρωνιτάκης (frolix68)
  • Σίμος Ξενιτέλλης (simosx)
  • (κάποια μέλη δεν έδωσαν το πλήρες όνομά τους, παρακαλώ επικοινωνήστε)

Από τα μεγάλα πακέτα της τεκμηρίωσης, έχουμε τα

  • Οδηγός διαχείρισης (Τζένη)
  • Οδηγός προσιτότητας (Τζένη)
  • Τεκμηρίωση Evolution Mail (Μάριος)
  • Τεκμηρίωση Aisleriot (Τζένη)
  • Τεκμηρίωση gedit (Μιχάλης)
  • Τεκμηρίωση gdm (Στέργιος)

Το μεγαλύτερο μέρος από τα στιγμιότυπα οθόνης (screenshots) τα ανέλαβαν οι Φώτης Τσάμης και Μάριος Ζηντίλης.

Το παραδοτέο είναι διαθέσιμο στο http://www.gnome.gr/files/gnome226/ και οι συντονιστές έργου ήταν οι Τζένη Πετούμενου και Σίμος Ξενιτέλλης. Οι commiters ήταν οι Νίκος Χαρωνιτάκης, Κώστας Παπαδήμας και Σίμος Ξενιτέλλης.

Το αρχείο της τεκμηρίωσης είναι ELLAK_Conf2009-GNOME-L10n (.odp, για OpenOffice.org Impress).

Towards a GNOME CLI translation management tool

Update 7/June/2009: The repository was moved to https://github.com/simos/gnome-i18n-manage-vcs/. There was some confusion between this script and intltools, which now is a general localisation tool, not tied to GNOME.

In Designing a command-line translation tool for GNOME, I described how a CLI translation management tool would be used to ease the work of a translator with commit access. The discussion was continued with Leonardo‘s post Parsing damned-lies’ releases.xml.in in the command line.

The stage we are now is that we have a tool (not official GNOME tool, but rather at beta testing phase!) that can manage the repositories for us, so that the checking out and committing can be fairly automated. The source is available at https://github.com/simos/gnome-i18n-manage-vcs/.

We show two working examples.

Let’s say we want to update the documentation for gcalctool. We run

$ ./intltool-manage-vcs --language el --release gnome-2-26 \
--username simos --module gcalctool --transtype doc --init
Release  : gnome-2-26
Language : el
    Category: admin-tools
    Category: dev-tools
    Category: dev-platform
    Category: desktop
        Module:              gcalctool, Branch: gnome-2-26

Download completed successfully.
$ _

In the PO/ subdirectory there is a PO file for gcalctool. We update it using our favourite translation tool, and then

$ ./intltool-manage-vcs --language Greek --commit
Sending        el/el.po
Transmitting file data .
Committed revision 2475.
$ _

Let’s see another example. We want to update the gnome-games documentation. These are several individual PO files, for each of the games.

$ ./intltool-manage-vcs --language el --release gnome-2-26 \
--username simos --module gnome-games --transtype doc --init
Release  : gnome-2-26
Language : el
    Category: admin-tools
    Category: dev-tools
    Category: dev-platform
    Category: desktop
        Module:            gnome-games, Branch: gnome-2-26

Download completed successfully.
$ _

There are several files,

$ ls PO
aisleriot.gnome-2-26.el.po  gnibbles.gnome-2-26.el.po
gnotravex.gnome-2-26.el.po  README
blackjack.gnome-2-26.el.po  gnobots2.gnome-2-26.el.po
gnotski.gnome-2-26.el.po    same-gnome.gnome-2-26.el.po
glchess.gnome-2-26.el.po    gnome-sudoku.gnome-2-26.el.po
gtali.gnome-2-26.el.po      START
glines.gnome-2-26.el.po     gnometris.gnome-2-26.el.po
iagno.gnome-2-26.el.po      gnect.gnome-2-26.el.po
gnomine.gnome-2-26.el.po    mahjongg.gnome-2-26.el.po
$ _

We enter the PO/ subdirectory and we update those files we wish. We can also run scripts on the PO files. For example, all these documentation files contain the same fragment of the FDL license, so we can translate the license once, and then merge automatically to all translations.


$ ./intltool-manage-vcs --language Greek --commit
Sending        el/el.po
Transmitting file data .
Committed revision 9014.
Sending        el/el.po
Transmitting file data .
Committed revision 9015.
Sending        el/el.po
Transmitting file data .
Committed revision 9016.
$ _

In the above example, we updated the documentation of three of the games.

Here are tips when using this tool

  • There is a –dry-run option that is useful when experimenting or trying for the first time.
  • You can filter which group of a release to download, based on category. Existing categories are desktop, admin-tools, dev-tools, dev-platform. Also, on translation type, either documentation or UI (if you do not specify, we get both). On module, by providing the module name.

And the current limitations

  • We currently only support SVN. This will change once the repositories move to git.gnome.org, in about two weeks time.
  • You need to have at least an initial translation (currently, the script does not svn add files). To be fixed once we move to git.
  • We do not currently update ChangeLog files. That’s why gnome-games is so cool for these experiments. Due to the git move, we would not need to mess with ChangeLog files.
  • We are dependent on the http://l10n.gnome.org/languages/el/gnome-2-26/xml URLs (replace el with your language). These URLs expose the release modules information in a nice XML file. Previously, the information used to exist in an XML file in the repository of damned-lies. Now, the information lies in the mysql database of damned-lies+vertimus, and is exposed through the above type of URL.
  • Due to the previous point, we commit to branch or trunk, depending on what is available in the latest release (gnome-2-26). That means, my translation fixes in gnome-games have not made it to trunk (HEAD). This is something that can be fixed with a workaround. It would be actually cool to use this tool to commit to both gnome-2-xx and master at the same time.
  • We currently do not deal with figures.

Considering that damned-lies+vertimus will be having commit functionality soon, I think that having more than one option for easy commiting translations is good.


These are the presentation slides of my talk on improving the writing support in GTK+. It relates to several posts I have in my other (now not used anymore) blog at http://blogs.gnome.org/simos/2008/07/23/guadec-2008-presentation-slides/.

Enhancing the writing support in GTK+

Note: The title may not appear properly because I use a fancy effect that does not support the full range of Unicode characters. It’s a drawback of being trendy. The title says “Éńĥãǹčīṅǧ·ẗḧë·ẃṛīťıñĝ·ṩụṗṗọṙẗ·ıń·ǦŤḰ+”.

Code of conduct και ελληνικές κοινότητες ΕΛ/ΛΑΚ

Ένα πρόβλημα με τις κοινότητες ελ/λακ είναι ότι μερικά από τα μέλη δεν ακολουθούν τους τυπικούς κανόνες συμπεριφοράς, και αυτό έχει το αποτέλεσμα να δημιουργείται συχνά ένα αρνητικό κλίμα.

Ένα πρόσφατο παράδειγμα είναι στη λίστα gnome-i18n, όπου ένας νέος μεταφραστής ήταν πολύ αρνητικός και προσβλητικός στη συμπεριφορά του απέναντι στο συντονιστή της συγκεκριμένης γλώσσας και άλλα άτομα που έλαβαν μέρος στη συζήτηση (=όπως εμένα!). Κατά τη συζήτηση, έγινε αναφορά στο λεγόμενο Code of conduct του GNOME, απλοί κανόνες καλής συμπεριφοράς. Αν θέλεις να συμμετέχεις στο GNOME, πρέπει να ακολουθείς τους κανόνες καλής συμπεριφοράς. Εννοείται ότι ο καθένας που λαμβαίνει μέρος στην ανάπτυξη του GNOME ακολουθεί τους κανόνες αυτούς· ωστόσο μπορεί κάποιος και να υπογράψει ότι ακολουθεί τους κανόνες. Το ίδιο συμβαίνει με την κοινότητα του Ubuntu Linux όπου ο χρήστης μπορεί να υπογράψει ψηφιακά το Code of Conduct με το κλειδί του, και να λάβει το χαρακτηρισμό Ubuntero.

Στην ελληνική πραγματικότητα δεν έχουμε φτάσει ακόμα σε τέτοια επίπεδα και η κατάσταση είναι σχεδόν ad-hoc. Αναφερθήκαμε πρόσφατα στο πρόβλημα με το φόρουμ Linux του Adslgr.com.Ένα πράγμα που θεωρώ πολύ σημαντικό είναι ότι πρέπει να υπάρχει σεβασμός και τήρηση των τυπικών κανόνων καλής συμπεριφοράς. Παλαιότερα που έβλεπα τη λίστα LGU, παρατηρούσα ότι υπήρχαν συχνές «παραβάσεις», με αποτέλεσμα να επικρατεί αρνητικό κλίμα, να μην βγαίνουν αποτελέσματα στις συζητήσεις, ο καθένας να προσπαθεί να κάνει τον έξυπνο και να «την βγει» στον άλλο, και ουσιαστικά να γίνεται κακό στην κοινότητα, στους νέους χρήστες. Για τώρα δεν γνωρίζω, έχω την εντύπωση ότι τα πράγματα δεν έχουν καλυτερέψει σημαντικά. Είδα την πρόσφατη συζήτηση στην LGU για το σχολιασμό της μετάφρασης από ΕΛΟΤ των θεμελιωδών όρων πληροφορικής. Πολλά άτομα απάντησαν, ωστόσο στη συζήτηση αυτή δεν παρατήρησα κάποιο χειροπιαστό αποτέλεσμα.

Ένα άλλο πρόσφατο παράδειγμα είναι με αυτό το γράμμα στη λίστα public@hellug.gr. Ανεξάρτητα αν έχει δίκιο ή όχι ο αποστολέας, το γράμμα αυτό είναι από τα πιο τυπικά για να κάνει μια συζήτηση να αποσυντονιστεί. Ο δε αποστολέας του γράμματος δεν είναι νέος χρήστης· είναι μέλος της κοινότητας πάνω από δέκα χρόνια. Αντί να έχει την ωριμότητα να κλείσει το θέμα, το ανοίγει περισσότερο.

Βλέπω αυτό το εχθρικό περιβάλλον να διαιωνίζεται σε συγκεκριμένες κοινότητες, με μικρές ελπίδες για αλλαγή.

Προσωπικά αφιερώνω χρόνο στο φόρουμ του ελληνικού Ubuntu, στο http://ubuntu.opengr.net/ όπου υπάρχει έντονη προσπάθεια να έχουμε ένα θετικό περιβάλλον. Βλέπουμε να έχουμε αποτελέσματα, και να γίνονται μέλη περισσότεροι νέοι χρήστες της διανομής. Το ίδιο θετικό περιβάλλον υπάρχει στη λίστα του Ubuntu-gr.

Αντιγράφω εδώ τους κανόνες καλής συμπεριφοράς του GNOME,


  • Be respectful and considerate:
    • Disagreement is no excuse for poor behaviour or personal attacks. Remember that a community where people feel uncomfortable is not a productive one.
  • Be patient and generous:
    • If someone asks for help it is because they need it. Do politely suggest specific documentation or more appropriate venues where appropriate, but avoid aggressive or vague responses such as “RTFM”.
  • Assume people mean well:
    • Remember that decisions are often a difficult choice between competing priorities. If you disagree, please do so politely.
    • If something seems outrageous, check that you did not misinterpret it. Ask for clarification, but do not assume the worst.
  • Try to be concise:
    • Avoid repeating what has been said already. Making a conversation larger makes it difficult to follow, and people often feel personally attacked if they receive multiple messages telling them the same thing.

Converting between XKB and XML

I completed the stage that takes keyboard layout files from XKB (X.Org) and converts them to XML documents, based on a keyboard layout Relax NG schema. Then, these XML documents can also be converted back to keyboard layout files.

Here is an imaginary example of a keyboard layout file.

// Keyboard layout for the Zzurope country (code: zz).
// Yeah.

partial alphanumeric_keys alternate_group hidden
xkb_symbols "bare" {
   key <AE01> { [        1, exclam,      onesuperior,  exclamdown      ] };

partial alphanumeric_keys alternate_group
xkb_symbols "basic" {
   name[Group1] = "ZZurope";

   include "zz(bare)"

   key <AD04> { [        r, R,           ediaeresis,   Ediaeresis      ] };
   key <AC07> { [        j, J,           idiaeresis,   Idiaeresis      ] };
   key <AB02> { [        x, X,           oe,           OE              ] };
   key <AB04> { [        v, V,           registered,   registered      ] };

partial alphanumeric_keys alternate_group
xkb_symbols "extended" {
    include "zz(basic)"
    name[Group1] = "ZZurope Extended";
    key.type = "THREE_LEVEL"; // We use three levels.
    override key <AD01> {   type[Group1] = "SEPARATE_CAPS_AND_SHIFT_ALPHABETIC",
[ U1C9, U1C8], [  any,   U1C7 ]   }; // q
    override key <AD02> {   [ U1CC, U1CB, any,U1CA ],
    key <BKSP> {
        symbols[Group1]= [ BackSpace,   Terminate_Server ]
    key <BKSR> { virtualMods = AltGr, [ 1, 2 ] };
    modifier_map Control { Control_L };
    modifier_map Mod5   { <LVL3>, <MDSW> };
    key <BKST> { [1, 2,3, 4] };

When converted to an XML document, it looks like

<?xml version="1.0" encoding="UTF-8"?>
<layout layoutname="zz">
      <tokenkey override="False">
      <tokenname name="ZZurope"/>
      <tokenkey override="False">
      <tokenkey override="False">
      <tokenkey override="False">
      <tokenkey override="False">
      <tokenname name="ZZurope Extended"/>
      <tokenmodifiermap state="Control">
        <keycode value="Control_L"/>
      <tokenmodifiermap state="Mod5">
        <keycodex value="LVL3"/>
        <keycodex value="MDSW"/>
      <tokenkey override="True">
          <typegroup value="SEPARATE_CAPS_AND_SHIFT_ALPHABETIC"/>
      <tokenkey override="True">
          <typegroup value="SEPARATE_CAPS_AND_SHIFT_ALPHABETIC"/>
      <tokenkey override="False">
          <typegroup value="CTRL+ALT"/>
      <tokenkey override="False">
          <tokenvirtualmodifiers value="AltGr"/>
      <tokenkey override="False">

When we convert the XML document back to the XKB format, it looks like

hidden xkb_symbols "bare"
	key <AE01> { [ 1, exclam, onesuperior, exclamdown ] };

xkb_symbols "basic"
	name = "ZZurope";
	include "zz(bare)"
	key <AD04> { [ r, R, ediaeresis, Ediaeresis ] };
	key <AC07> { [ j, J, idiaeresis, Idiaeresis ] };
	key <AB02> { [ x, X, oe, OE ] };
	key <AB04> { [ v, V, registered, registered ] };

xkb_symbols "extended"
	name = "ZZurope Extended";
	include "zz(basic)"
	key.type = "THREE_LEVEL";
	modifier_map Control { Control_L };
	modifier_map Mod5 { <LVL3>, <MDSW> };
	override key <AD01> { [ U1C9, U1C8 ], [ any, U1C7 ], type = "SEPARATE_CAPS_AND_SHIFT_ALPHABETIC"  };
	override key <AD02> { [ U1CC, U1CB, any, U1CA ], type = "SEPARATE_CAPS_AND_SHIFT_ALPHABETIC"  };
	key <BKSP> { [ BackSpace, Terminate_Server ], type = "CTRL+ALT"  };
	key <BKSR> { [ 1, 2 ], virtualMods = AltGr  };
	key <BKST> { [ 1, 2, 3, 4 ] };

Some things are missing such as partial, alphanumeric_keys and alternate_group, which I discussed with Sergey and he said they should be ok to go away.

In addition, we simplify by keeping just Group1 (we do not specify it, as it is implied).

I performed the round-trip with all layout files, and all parsed and validated OK (there is some extra work with the level3 file remaining, though).

Some issues that are remaining, include

  • Figuring out how to use XLink to link to documents in the same folder (+providing a parameter; the name of the variant), and how to represent that in the Relax NG schema.
  • Sort the layout entries by keycode value.

Looking into the symbol files

In the previous post, we talked about the ANTLR grammar that parses the XKB layout files.

The grammar is available at http://code.google.com/p/keyboardlayouteditor/source/browse. I’ll rather push to the freedesktop repository once the project is completed. Now it’s too easy for me, just doing svn commit -m something.

Below you can see the relevant layout files for each country (and in some cases, language), and how the grammar deals with them. First column is filenames from the CVS XKB symbols subdirectory (to be moved eminently to GIT). Last’s week discussion with Sergey helped me figure out issues with the symbol files, simplify what information is needed, and what can be eliminated. Second column has Not OK if something is wrong. Third column tries to explain what was wrong.

gb NOK Non-UTF8
group NOK virtualMods= AltGr
hu NOK Non-UTF8
il NOK key.type=”FOUR_LEVEL” (typically: key.type[something]=….)
in NOK key.type=”FOUR_LEVEL” (typically: key.type[something]=….)
jp NOK key <BKSP> {
type=””,   // empty?
symbols[Group1]= [ bracketright, braceright ]
keypad NOK overlay1=<KO7> }; // what’s “overlay”?
level3 NOK virtual_modifiers LAlt, AlGr; virtualMods= Lalt
nbsp NOK Non-UTF8
pc NOK key <AA00> { type=”SOMETHING” } instead of { type[Group1]=”SOMETHING” }
shift NOK actions [Group1] = [
srvr_ctrl NOK key <AA00> { type=”SOMETHING” } instead of { type[Group1]=”SOMETHING” }

Non-UTF-8 are the files that have characters that are not UTF-8 (are iso-8859-1).

Some layouts have key.type = “something” and others key.type[SomeGroup] = “something”. Apparently, the format allows to infer which is the group that the type acts upon? That’s weird. Would it be better to put the group information? Is it required that the group is not set?

Some files have virtualMods, which I do not know what it is. Is it used?

Should UI strings in source code have non-ASCII characters?

There is a discussion going on at desktop-devel about whether the UI strings in the source code should also have non-ASCII characters. For example, should typical strings with double-quotes have those fancy Unicode double quotes?

printf(_("Could not find file “%s”n"));

instead of

printf(_("Could not find file "%s"n"));

The general view from the replies is to go ahead and add those nice Unicode characters.

Actually, there are UI messages already with non-ASCII characters (the ellipsis character, …) in GNOME 2.22:

  1. glade3
  2. epiphany

In GNOME 2.24, there are even more (with ellipsis):

  1. gucharmap
  2. epiphany
  3. gnome-terminal
  4. gedit
  5. glade3

Regarding the fancy Unicode double quotes, there are UI strings in GNOME 2.22 (same list for 2.24) in the following packages:

  1. evince
  2. cheese
  3. epiphany
  4. eog
  5. gnome-doc-utils

What are the arguments against having non-ASCII characters in UI strings?

  1. There might be systems that still use 8-bit legacy encodings. In this case, the UTF-8 encoded may not be displayed properly. However, when I tried to demonstrate this on my system (Ubuntu 8.04), I failed miserably. I downloaded a small GTK2 text editor (called tea), I changed a source UI string to include “” and ellipsis, compiled and installed. I then opened a shell, set LANG to POSIX (or C), and ran the text editor. The UI message was proper Unicode and I could even type non-ASCII in the text editor. I resorted to changing a system locale (I picked en_IN) to ISO-8859-1, then logged out. In the login screen it did not show the 8-bit encoding. If someone has a proper legacy 8-bit encoding system with GNOME (OpenBSD, FreeBSD, etc), could you please try it out?
  2. As Alan Cox mentioned in the thread, the canonical way to deal with UI strings in the source code should be to keep as ASCII, and put any fancy Unicode characters in the translation files (even for en_US, get an en_US translation file).

Is GNOME (or components) used in a legacy 7-bit/8-bit environment?

If there is any reason to keep UI strings in the source code as plain ASCII, speak now, or the Unicode flood gates are about to open.

Update 16 May 2008:There is a document at the ISO/IEC 9899 website (C programming language), that mentions the issue of character sets in C. It is http://www.open-std.org/jtc1/sc22/wg14/www/docs/C99RationaleV5.10.pdf.

On page 26, section 5.2.1, it says

The C89 Committee ultimately came to remarkable unanimity on the subject of character set requirements. There was strong sentiment that C should not be tied to ASCII, despite its heritage and despite the precedent of Ada being defined in terms of ASCII. Rather, an implementation is required to provide a unique character code for each of the printable graphics used by C, and for each of the control codes representable by an escape sequence. (No particular graphic representation for any character is prescribed; thus the common Japanese practice of using the glyph “¥” for the C character “” is perfectly legitimate.) Translation and execution environments may have different character sets, but each must meet this requirement in its own way. The goal is to ensure that a conforming implementation can translate a C translator written in C.

For this reason, and for economy of description, source code is described as if it undergoes the same translation as text that is input by the standard library I/O routines: each line is terminated by some newline character regardless of its external representation.

With the concept of multibyte characters, “native” characters could be used in string literals and character constants, but this use was very dependent on the implementation and did not usually work in heterogenous environments. Also, this did not encompass identifiers.

It then goes on with an addition to C99:

A new feature of C99: C99 adds the concept of universal character name (UCN) (see §6.4.3) in order to allow the use of any character in a C source, not just English characters. The primary goal of the Committee was to enable the use of any “native” character in identifiers, string literals and character constants, while retaining the portability objective of C.

Both the C and C++ committees studied this situation, and the adopted solution was to introduce a new notation for UCNs. Its general forms are unnnn and Unnnnnnnn, to designate a given character according to its short name as described by ISO/IEC 10646. Thus, unnnn can be used to designate a Unicode character. This way, programs that must be fully portable may use virtually any character from any script used in the world and still be portable, provided of course that if it prints the character, the execution character set has representation for it.

Of course the notation unnnn, like trigraphs, is not very easy to use in everyday programming; so there is a mapping that links UCN and multibyte characters to enable source programs to stay readable by users while maintaining portability. Given the current state of multibyte encodings,
10 this mapping is specified to be implementation-defined; but an implementation can provide the users with utility programs that do the conversion from UCNs to “native” multibytes or vice versa, thus providing a way to exchange source files between implementations using the UCN notation.

Update 7 Aug 2008: According to PEP 8, Style Guide for Python Code, under Encodings, says

    For Python 3.0 and beyond, the following policy is prescribed for
    the standard library (see PEP 3131): All identifiers in the Python
    standard library MUST use ASCII-only identifiers, and SHOULD use
    English words wherever feasible (in many cases, abbreviations and
    technical terms are used which aren't English). In addition,
    string literals and comments must also be in ASCII. The only
    exceptions are (a) test cases testing the non-ASCII features, and
    (b) names of authors. Authors whose names are not based on the
    latin alphabet MUST provide a latin transliteration of their

    Open source projects with a global audience are encouraged to
    adopt a similar policy.

(Emphasis mine)

Προβληματικές συμπεριφορές στο adslgr.com/Forum του Linux

Παρακολουθώ μερικά forum και την ενότητα για Linux που έχουν, και αρκετές φορές απαντώ σε ερωτήματα χρηστών. Μερικά έχουν μικρή κίνηση, άλλα έχουν αρκετή και είναι πολύ ζωντανά. Ένα από τα forum αυτά είναι το ADSLGR.com @ Linux.

Ωστόσο υπάρχει ένα πρόβλημα συμπεριφοράς από μερικά από τα «παλιά» μέλη που χρησιμοποιούν τακτικές bullying για να περάσουν τις απόψεις τους. Είναι πραγματικά παράξενο να έχουμε τέτοια ζητήματα στο ελεύθερο λογισμικό. Ωστόσο έτσι φαίνεται να είναι.

Σε μια συζήτηση, για τα νεότερα στο GNOME 2.22,
http://www.adslgr.com/forum/showthread.php?t=184570 υπήρξαν σχόλια με ύψηλο flameability,

Α. «Ακομα πιο προηγμενο, τωρα ΚΑΙ με υποστηριξη για webcam. »

Β. «χαχαχα, μπήκε download notification στον epiphany.»

Γ. «Σε λίγο θα διαφημίσουν και το κουμπάκι “πίσω”, ε μα είναι πράγματα αυτα?»

Δ. « Αρχικό μήνυμα από simosx Διαβάζω όλα αυτά τα ειρωνικά σχόλια, όπως και στο άλλο thread με τον έξυπνο τίτλο gnome-vs-kde.
Ως ελληνική κοινότητα φαίνεται να είμαστε άσχετοι από τα τεκτενόμενα στο εξωτερικό. Είμαστε θεατές με επιφανειακή γνώση. »

««Συγγνώμη, για να εκφέρουμε άποψη πρέπει να συνεισφέρουμε πρώτα? Έλεος, διαφημίζουν τα αυτονόητα που υπάρχουν σε άλλους browsers εδώ και 10 χρόνια και καμαρώνουν κιόλας…?
Εντάξει, αφου πλέον μπορώ να βλεπω την ώρα στην Αυστραλία για να μην παρεξηγούμαι που δεν απαντάει στο msn η τουρ-τουρίστρια που γνώρισα πέρσυ, όλα καλά .»»

Ε. «Θα σου δώσει κατάλληλη απάντηση κάποιος καλοθελητής σε λίγο.»

ΣΤ. «Χρησιμοποιώ και gnome ενίοτε αλλά με τέτοιες μπαρούφες που κάθονται και του βάζουν…»

Ζ. «το μόνο σίγουρο είναι πως κάναμε hijacked το θέμα του gnome
έτσι κι αλλιώς δεν έχει ενδιαφέρον »

Η. « Αρχικό μήνυμα από no_logo το μόνο σίγουρο είναι πως κάναμε hijacked το θέμα του gnome
έτσι κι αλλιώς δεν έχει ενδιαφέρον
Ποιος το λέει ; Ο καθοδηγητής μήπως ; »

Θ. « Αρχικό μήνυμα από midnightsun Ποιος το λέει ; Ο καθοδηγητής μήπως ;
η πραγματικότητα 1 σελίδα είναι η “είδηση” για το gnome, οι υπόλοιπες είναι bashing από kde χρήστες και το πρόβλημα του ATC
Πάρε μάτι το νήμα του kde 4 που ενώ δεν έχει βγει ακόμα μαζικά έχουν γραφτεί σελίδες επι σελίδων
Αυτή είναι η διαφορά, ψοφοδεής κοινότητα από την μια vs την ζωντανή και ενεργητική κοινότητα του kde »

(σταματώ στη σελίδα 5 του νήματος· πάει μέχρι το 8)

Αυτό που βλέπω είναι ότι η αρνητική συμπεριφορά δεν είναι μεμονωμένη, και υπάρχουν και moderators που λαμβάνουν μέρος.

Αν μια διανομή είναι καλύτερη ή όχι από μια άλλη, αυτό δεν μπορεί να είναι αίτια για τέτοιες αρνητικές συμπεριφορές. Στην πραγματικότητα, οι διανομές/γραφικά περιβάλλοντα αποτελούν απλά αφορμή, κάτι το επιφανειακό.

Ένα άλλο χαρακτηριστικό είναι η κομπλεξική συμπεριφορά και η χρήση γραφικών εκφράσεων όπως «μυκητίαση» ή «μούχλα» (σε κάποια βίντεο κατά την αναπαραγωγή φαίνονται κάποιες περιοχές σε πράσινο χρώμα· πρώτη φορά το ακούω, και η λύση ίσως να είναι ένα απλό «περίμενε να ολοκληρωθεί το torrent»). Ο τίτλος της συζήτησης ήταν «18 μήνες έχει κλείσει αδιόρθωτο το bug της μούχλας του Xine».

Άλλες εκφράσεις συμπεριλαμβάνουν «άθλιο», που είναι μια γενική περιγραφή για τα προγράμματα που δεν καταλαβαίνουμε πως δουλεύουν.

Ένα ακόμα μήνυμα που βλέπουμε να περνάει από το adslgr.com/Linux είναι ότι στο ελεύθερο λογισμικό υπάρχουν κάποιοι «άλλοι» που έχουν υποχρέωση να κάνουν τη δουλειά, και αν δεν την κάνουν σωστά είναι άθλιοι. Αυτοί οι άλλοι είναι ταπεινοί υπηρέτες μας. Εδώ πρέπει να υπάρχει μια υποβόσκουσα σύνδεση στη σειρά Lost και τους Άλλους. (Ωχ, και εγώ κατάντησα να λέω μακίες).

Τι προβλήματα δημιουργεί αυτή η αρνητική συμπεριφορά;

  • Είναι ιδιαίτερα επιβλαβής στην ελληνική κοινότητα ελεύθερου λογισμικού. Η κοινότητα βασίζεται στην «ελεύθερη οργάνωση» που σημαίνει ότι δεν υπάρχουν επίσημες δομές στήριξης που θα περίμενε κάποιος σε ένα επιχειρηματικό περιβάλλον. Αν κάποιος νέος χρήστης τύχει να περάσει πρώτα από το ADSLGR.com για να μάθει για το Linux, τότε η κοινότητα έχει πιθανότατα χάσει ένα μέλος.
  • Τα μέλη διαιωνίζουν την αρνητική συμπεριφορά και σε άλλους χώρους.
  • Προκαλούν burnout (κούραση, μειωμένο ενδιαφέρον) στα άτομα που πραγματικά βοηθάνε. Μερικά από τα άτομα αυτά έχουν ήδη γίνει ban (!) διότι δεν ακολουθούν τη γραμμή των μπούληδων. Πάντως σε τελική ανάλυση κάτι τέτοιο είναι θετικό μιας και δεν ασχολούνται πια με το φόρουμ αυτό.

Για το που πάει το forum αυτό, ας δούμε μια πρόσφατη εγγραφή στο ίδιο φόρουμ κάποιου χρήστη, για τη διανομή Ubuntu (emphasis mine).

Θέμα: Ubuntu 8.04: Κάθε πέρυσι και καλύτερα?

Θα ήθελα τη γνώμη των χρηστών που εγκατέστησαν – δοκίμασαν την πιο πρόσφατη έκδοση της Ubuntu. Θα ήθελα να ξέρω αν, παρά τις διθυραμβικές κριτικές που είχα διαβάσει πριν την έλευσή της σε διάφορα τεχνολογικά sites, έχετε την ίδια αίσθηση με μένα: ΑΠΟΓΟΗΤΕΥΣΗ!
Κατ’ αρχάς να πω ότι το τελευταίο εξάμηνο χρησιμοποιούσα αρχικά την Feisty και ακολούθως την Gutsy. Συγκρίνοντας τις δύο μεταξύ τους θεωρούσα ότι υπήρχε μία αργή αλλά σταθερή βελτίωση στις διανομές. Στο laptop και οι δύο λειτουργούσαν θαυμάσια (ένα Sony Vaio) αλλά στο deskotp η Feisty αρνιόταν να αναγνωρίσει μία ασύρματη κάρτα Linksys WMP54g 4.1. Το πρόβλημα λύθηκε (σχεδόν) με την έλευση της Gutsy οπότε και με μερικά τρικ κατάφερα να εγκαταστήσω επιτυχώς Ubuntu και στο desktop. Το upgrade δε από Feisty σε Gutsy ήταν απλά άψογο.
Για να έρθουμε στην τελευταία έκδοση, Hardy Heron. Κατ’ αρχάς το upgrade και στα δύο μηχανήματα δημιούργησε προβλήματα και αναγκάστηκα να κάνω clean install κρατώντας σταθερό το home. Στο laptop είχα πρόβλημα στην εναλλαγή των layouts στο πληκτρολόγιο, καθώς έπρεπε να το ορίσω σε κάθε boot για να δουλέψει. Επίσης πρόβλημα παρουσιάστηκε στην ομαλή λειτουργία του openoffice (περίεργα κωλύματα που δεν είχα ξανασυναντήσει στην προηγούμενη έκδοση) και στη λειτουργία του emerald theme manager. Στο desktop δεν είχα το πρόβλημα με τα layouts του πληκτρολογίου αλλά είχα τα ίδια με το openoffice και το emerald, ενώ η σταγόνα που ξεχείλισε το ποτήρι ήταν ότι δε δούλευε το number keypad του πληκτρολογίου που δούλευε μία χαρά στην προηγούμενη έκδοση.
Για να μη σας κουράσω, έχω πλέον ξαναγυρίσει στην gutsy και στα δύο μου μηχανήματα. Το ερώτημα: είχατε αντίστοιχα προβλήματα? Και η αγωνία: θα είναι η 8.10 καλύτερη ή χειρότερη (η 8.04 είναι και LTS τρομάρα τους!)
To ADSLGR.com ως δικτυακός τόπος είναι σημαντικός και προσφέρει αρκετά στη γενικότερη κοινότητα. Το θέμα είναι ότι το κομμάτι που έχει να κάνει με το Linux είναι προβληματικό, και κάποιοι από τους συντονιστές διαιωνίζουν αντί να διορθώνουν την κατάσταση.
Αυτό που θα ήθελα να προτείνω στους χρήστες είναι να αποφεύγουν το ADSLGR.com/Linux για το άμεσο μέλλον, μέχρι τουλάχιστον να αλλάξει η κατάσταση.
Ενημέρωση: Όχι άλλα σχόλια πια. Μπορείτε να συνεχίσετε τα σχόλιά σας στο http://adslgr-critics.blogspot.com/.

Using Anjuta in Ubuntu 8.04 to develop a GNOME C++ application (gtkmm)

You can install Anjuta 2.4.1 from the Synaptic package manager. You also need to install a few development packages. I do not know if there is a nice meta-package such as build-essential (used to install compilers et al), so I’ll just ask you to install the packages by hand. A more elegant way would be very much appreciated to see in the comments.

$ sudo apt-get install build-essential libgtkmm-2.4-dev autogen automake libtool intltool libglademm-2.4-dev

That is the order of installation when you go trial by error inside Anjuta to compile a project. Each package draws in several other packages. Also, if you have the Ubuntu 8.04 DVD in your drive, most of these packages will be installed in a jiffy. We have the Greek localisation enabled, so bear with us. Thanks to Giannis Katsampiris for completing the recent update of the Anjuta 2.4 localisation.
Screenshot of Anjuta, initial screen (Localisation: Greek)
Once Anjuta is installed, you are presented with the Anjuta main window.

We then click on File/New/Project (Αρχείο/Νέο/1. Έργο),

Project creation wizard

We click on Forward here.

Choose project type

There are many many project types. We wade through and we pick to use C++ and GTKMM (C++ bindings for GTK+). We could pick any other variation; GTKMM was a request from the Ubuntu-gr mailing list.

Fill in some contact details

We then fill in some contact details.

Sorting out the project settings

There is an option to specify at this stage external packages. We opt not to specify them now.

We are actually done!

Once you click Apply (Εφαρμογή) – the button with the green tick, Anjuta will create an initial dummy package (actually a hello world application), and will run automatically the equivalent of ./configure for you.

Read to work!

Now, this is the final screen, when you start working. Here you would click on Κατασκευή/Κατασκευή έργου (Build/Build Project), so that the project gets compiled.

Then, you would click on Κατασκευή/Εκτέλεση προγράμματος… (Build/Run program…) to run the program!

Start typing!

Here is shows that we have located the source file (main.cc), and we see main().

It takes about 3 second to compile a program with g++ (at least on my system). Therefore, the dead time between (a) Let’s compile it and (b) Oh, I am running my program!, is under 5 seconds, which is good.