Tag : mailing-list

Προβληματικές συμπεριφορές γύρω από το hellug

(σχετική δημοσίευση)

Δε λαμβάνω τακτικά φαν μέηλ, ωστόσο όταν λαμβάνω, τα διαβάζω με προσοχή.

(Κάντε κλικ στο σύνδεσμο παρακάτω για περισσότερα)

Ενημέρωση 18 Οκτ 2008:

Θα ήθελα εδώ να κάνω μια περίληψη όσων έχουν ειπωθεί.

Η αντίδρασή μου είναι στο ύφος ατόμων που είναι γύρω από το Hellug, όταν συζητούν σε λίστες όπως public@hellug.gr. Μπορείτε να δείτε παραδείγματα παραπάνω. Το ύφος μπορεί να είναι προσβλητικό, αρνητικό, stop-energy, κτλ.

Το ειρωνικό είναι ότι οι απαντήσεις που έλαβα ήταν του ίδιου ύφους που κατακρίνω. Οι περισσότερες απαντήσεις ήταν προσωπικές επιθέσεις, ότι κάνω κριτική στο Hellug διότι θέλω να είμαι ηγετική φιγούρα, ότι είμαι «κομπλεξικός», άλλοι (ανώνυμοι!) να παραποιούν το όνομά μου σε Σίμωνα ή Σιμούλη. Στις απαντήσεις στην ανάρτηση αυτή είχαμε και άσχετα σχόλια, προσωπικές επιθέσεις σε τρίτα άτομα.

Από τα επώνυμα άτομα που απάντησαν σε αυτό, είχαμε τον πρόεδρο και αντιπρόεδρο του συλλόγου Hellug.

Ο πρόεδρος του συλλόγου δήλωσε ότι πιστεύει ότι δεν υπάρχει πρόβλημα με τις αρνητικές συμπεριφορές. Αυτή είναι μια άποψη, που όμως καταστρέφεται όταν προσθέτει ότι η κριτική που κάνω εγώ (!) αποτελεί αρνητική συμπεριφορά! Το pattern που βλέπω στον πρόεδρο του hellug είναι ότι μερικά γράμματά του έχουν ποιοτικό περιεχόμενο που αξίζουν σε πρόεδρο. Ωστόσο, στο τέλος υπάρχει ένας χαρακτηρισμός ή ένα σχόλιο που καταστρέφει το όλο μήνυμα.

Το ελεύθερο λογισμικό βασίζεται στους χρήστες του που επικοινωνούν και συζητούν ηλεκτρονικά. Αυτού του είδους η επικοινωνία είναι πολύ σημαντική, και πρέπει να έχουμε ένα επίπεδο συζήτησης. Ο σύλλογος hellug ασχολείται κατά βάση με τη διάδοση και τις δημόσιες σχέσεις για το ελεύθερο λογισμικό στην Ελλάδα. Είναι πολύ σημαντικό τα άτομα, τουλάχιστον του συμβουλίου του hellug, να κάνουν την προσπάθεια να συμπεριφέρονται ποιοτικά.

(more…)

What to see in OpenOffice.org 3.1 Writer;

At the User Experience mailing list at OpenOffice.org there is a thread to discuss & plan what new things should make it to OpenOffice.org 3.1. Here is the first email,

From: Christian Jansen

Date: Wed, Jun 25, 2008 at 8:35 AM

Hi,
OpenOffice.org 3.1 planning will start soon, thus I’d like to collect some ideas (from an UX-perspective) for improving OpenOffice.org Writer.

What drives you nuts?

What works pretty well?

My most wanted feature is:

Thanks for your feedback!

Regards,
Christian [Jansen]

Source: http://ux.openoffice.org/servlets/ReadMsg?list=discuss&msgNo=1890

Feedback started pouring in. Make your way to the user-experience discuss@ux.openoffice.org mailing list to add your views. When you log in to OpenOffice.org, you click to subscribe to the mailing list. That is, you need to make an account first.

Create flash videos of your desktop with recordmydesktop

John Varouhakis is the author of recordmydesktop and gtk-recordmydesktop (front-end) which is a tool to help you record a session on your Linux desktop and save it to a Flash video (.flv).

To install, click on System/Administration/Synaptic Package Manager, and search for gtk-recordmydesktop. Install it. Then, the application is available from Applications/Sound&Video/gtkRecordMyDesktop.

Screenshot of gtk-recordmydesktop

Before you are ready to capture your Flash video, you need to select the video area. There are several ways to do this; the most common is to click on Select Window, then click on the Window you want to record. A common mistake is that people try to select the window from the preview above. If you do that, when you would have selected the recorder itself to make a video of, which is not really useful. You need to click on the real window in order to select it; then, in the desktop preview you can see the selected window. In the above case, I selected the OpenOffice Writer window.

Assuming that you do not need to do any further customisation, you can simple press Record to start recording. Generally, it is good to check the recording settings using the GNOME Sound recorder beforehand. While recording, you can notice a special icon on the top panel. This is gtk-recordmydesktop. Once you press it, recording stops and the program will do the post-processing of the recording. The resulting file goes into your home folder, and has the extension .ogv.

Some common pitfalls include

  • I did not manage to get audio recording to work well for my system; I had to disable libasound so that the audio recording would not skip. With ALSA, sound skips while with OSS emulation it does not. Weird. Does it work for you?
  •  The post-processing of the recording takes some time. If you have a long recording, it may take some time to show that it makes progress, so you might think it crashed. Have patience.

I had made one such recording, which can be found at the Greek OLPC mailing list. John told me that the audio part of the video was not loud enough, and one can use extra post-processing to make it sound better. For example, one could extract the audio stream of the video, remove the noise, beautify (how?) and then add back to the video.

It’s good to try out gtk-recordmydesktop, even for a small recording. Do you have some cool tips from your Linux desktop that you want to share? Record your desktop!

ert-archives.gr: “Linux/Unix operating systems are not supported”

ERT (Hellenic Broadcasting Corporation) is the national radio/television organisation of Greece.

ERT recently made available online part of its audio and video archive, at the website http://www.ert-archives.gr/

When browsing the website from Linux, you were blocked with a message that Linux/Unix operating systems are not supported. This message was appearing due to User-Agent filtering. Even if you altered your User-Agent, the page would not show the multimedia.

There has been a heated discussion on this on local mailing lists, with many users sending their personal polite comments to the feedback page at the ERT website. Many individual, personal comments have value and are taken into account.

Since today, http://www.ert-archives.gr/ does no do filtering on the User-Agent, and has changed the wording at the support page saying that

Σχετικά με υπολογιστές που χρησιμοποιούν λειτουργικό σύστημα Linux σχετικές οδηγίες θα υπάρξουν στο άμεσο μέλλον.

which means that they will be providing instructions for Linux systems in the immediate future.

Going through the HTML code of http://www.ert-archives.gr/ one can see that the whole system would work well under Linux, out of the box, if they could change

<embed id=”oMP” name=”oMP” width=”800″ height=”430″ type=”application/x-ms-wmp

to

<embed id=”oMP” name=”oMP” width=”800″ height=”430″ type=”video/x-ms-wmp

Firefox, with the mplayerplugin, supports the video/x-ms-wmp streaming format. You can verify if you have it by writing about:plugins in the location bar and pressing Enter. For my system it says

Windows Media Player Plugin

File name: mplayerplug-in-wmp.so
mplayerplug-in 3.40Video Player Plug-in for QuickTime, RealPlayer and Windows Media Player streams using MPlayer
JavaScript Enabled and Using GTK2 Widgets
MIME Type Description Suffixes Enabled
video/x-ms-wmp Windows Media wmp,* Yes

I am not sure if the mplayerplugin package is installed by default in Ubuntu, and I do not know what is the workflow from the message that says that a plugin is missing to the process of getting it installed. If you use the Totem Media Player, it instructs you to download and install the missing packages. I would appreciate your input on this one.

A workaround is to write a Greasemonkey script to replace the string so that Firefox works out of the box. However, the proper solution is to have ERT fix the code.

I must say that I would have preferred to have Totem Movie Player used to view those videos.
ERT Ecology
I just finished watching a documentary from the 80s about ecology and sustainability of the forests on my Linux system. It is amazing to listen again to the voice-over which is sort of a signature voice for such documentaries of the said TV channel. The screenshot shows goats in a forest, and mentioning the devastating effects of said animals on recently-burnt forests.

Update (22Mar08): The problem has not been resolved yet. Dimitris Diamantis offers a work-around at the Ubuntu-gr mailing list.

Important MO file optimisation for en_* locales, and partly others

During GUADEC, Tomas Frydrych gave a talk on exmap-console, a cut-down version of exmap that can work well on mobile devices.

During the presentation, Tomas showed how to use the tool to find the culprits in memory (ab)use on the GNOME desktop. One issue that came up was that the MO files taking up space though the desktop showed English. Why would the MO translation files loaded in memory be so big in size?

gtk20.mo                             : VM   61440  B, M   61440  B, S   61440  B

atk10.mo                      	     : VM    8192  B, M    8192  B, S    8192  B

libgnome-2.0.mo			: VM   28672  B, M   24576  B, S   24576  B

glib20.mo			     : VM   20480  B, M   16384  B, S   16384  B

gtk20-properties.mo           : VM     128 KB, M     116 KB, S     116 KB

launchpad-integration.mo  : VM    4096  B, M    4096  B, S    4096  B

A translation file looks like

msgid “File”

msgstr “”

When translated to Greek it is

msgid “File”

msgstr “Αρχείο”

In the English UK translation it would be

msgid “File”

msgstr “File”

This actually is not necessary because if you leave those messags untranslated, the system will use the original messages that are embedded in the executable file.

However, for the purposes of the English UK, English Canadian, etc teams, it makes sense to copy the same messages in the translated field because it would be an indication that the message was examined by the translation. Any new messages would appear as untranslated and the same process would continue.

Now, the problem is that the gettext tools are not smart enough when they compile such translation files; they replicate without need those messages occupying space in the generated MO file.

Apart from the English variants, this issue is also present in other languages when the message looks like

msgid “GConf”

msgstr “GConf”

Here, it does not make much sense to translate the message in the locale language. However, the generated MO file contains now more than 10 bytes (5+5) , plus some space for the index.

Therefore, what’s the solution for this issue?

One solution is to add to msgattrib the option to preprocess a PO file and remove those unneeded copies. Here is a patch,

— src.ORIGINAL/msgattrib.c 2007-07-18 17:17:08.000000000 +0100
+++ src/msgattrib.c 2007-07-23 01:20:35.000000000 +0100
@@ -61,7 +61,8 @@
REMOVE_FUZZY = 1 << 2,
REMOVE_NONFUZZY = 1 << 3,
REMOVE_OBSOLETE = 1 << 4,
– REMOVE_NONOBSOLETE = 1 << 5
+ REMOVE_NONOBSOLETE = 1 << 5,
+ REMOVE_COPIED = 1 << 6
};
static int to_remove;

@@ -90,6 +91,7 @@
{ “help”, no_argument, NULL, ‘h’ },
{ “ignore-file”, required_argument, NULL, CHAR_MAX + 15 },
{ “indent”, no_argument, NULL, ‘i’ },
+ { “no-copied”, no_argument, NULL, CHAR_MAX + 19 },
{ “no-escape”, no_argument, NULL, ‘e’ },
{ “no-fuzzy”, no_argument, NULL, CHAR_MAX + 3 },
{ “no-location”, no_argument, &line_comment, 0 },
@@ -314,6 +316,10 @@
to_change |= REMOVE_PREV;
break;

+ case CHAR_MAX + 19: /* –no-copied */
+ to_remove |= REMOVE_COPIED;
+ break;
+
default:
usage (EXIT_FAILURE);
/* NOTREACHED */
@@ -436,6 +442,8 @@
–no-obsolete remove obsolete #~ messages\n”));
printf (_(“\
–only-obsolete keep obsolete #~ messages\n”));
+ printf (_(“\
+ –no-copied remove copied messages\n”));
printf (“\n”);
printf (_(“\
Attribute manipulation:\n”));
@@ -536,6 +544,21 @@
: to_remove & REMOVE_NONOBSOLETE))
return false;

+ if (to_remove & REMOVE_COPIED)
+ {
+ if (!strcmp(mp->msgid, mp->msgstr) && strlen(mp->msgstr)+1 >= mp->msgstr_len)
+ {
+ return false;
+ }
+ else if ( strlen(mp->msgstr)+1 < mp->msgstr_len )
+ {
+ if ( !strcmp(mp->msgstr + strlen(mp->msgstr)+1, mp->msgid_plural) )
+ {
+ return false;
+ }
+ }
+ }
+
return true;
}
However, if we only change msgattrib, we would need to adapt the build system for all packages.

Apparently, it would make sense to change the default behaviour of msgfmt, the program that compiles PO files into MO files.

An e-mail was sent to the email address for the development team of gettext regarding the issue. The development team does not appear to have a Bugzilla to record these issues. If you know of an alternative contact point, please notify me.

Update #1 (23Jul07): As an indication of the file size savings, the en_GB locale on Ubuntu in the installation CD occupies about 424KB where in practice it should have been 48KB.

A full installation of Ubuntu with some basic KDE packages (only for the basic libraries, i.e. KBabel – (ls k* | wc -l = 499)) occupies about 26MB of space just for the translation files. When optimising in the MO files, the translation files occupy only 7MB. This is quite important because when someone installs for example the en_CA locale, all en_?? locales are added.

The reason why the reduction is more has to do with the message types that KDE uses. For example,

msgid “”
“_: Unknown State\n”
“Unknown”
msgstr “Unknown”

I cannot see a portable way to code the gettext-tools so that they understand that the above message can be easily omitted. For the above reduction to 7MB, KDE applications (k*) occupy 3.6MB. The non-KDE applications include GNOME, XFCE and GNU traditional tools. The biggest culprits in KDE are kstars (386KB) and kgeography (345KB).

Update #2 (23Jul07): (Thanks Deniz for the comment below on gweather!) The po-locations translations (gnome-applets/gweather) of all languages are combined together to generate a big XML file that can be found at usr/share/gnome-applets/gweather/Locations.xml (~15MB).

This file is not kept in memory while the gweather applet is running.
However, the file is parsed when the user opens the properties dialog to change the location.
I would say that the main problem here is the file size (15.8MB) that can be easily reduced when stripping copied messages. This file is included in any Linux distribution, whatever the locale.

The po-locations directory currently occupies 107MB and when copied messages are eliminated it occupies 78MB (a difference of 30MB). The generated XML file is in any case smaller (15.8MB without optimisation) because it does not include repeatedly the msgid lines for each language.

I regenerated the Locations.xml file with the optimised PO files and the resulting file is 7.6MB. This is a good reduction in file space and also in packaging size.

Update #3 (25Jul07): Posted a patch for gettext-tools/msgattrib.c. Sent an e-mail to the kde-i18n-doc mailing list and got good response and a valid argument for the proposed changes. Specifically, there is a case when one gives custom values to the LANGUAGE variable. This happens when someone uses the LANGUAGE variable with a value such as “es:fr” which means show me messages in Spanish and if something is untranslated show me in French. If a message has msgid==msgstr for Spanish but not for French, then it would show in French if we go along with the proposed optimisation.

Improving DejaVu Serif for Greek

Vangelis Karageorgos  sent an e-mail to the DejaVu Fonts mailing list regarding his work on the Greek glyphs for the DejaVu Serif face.

The original Greek glyphs from DejaVu Serif 2.12 look like

The edition of DejaVu Serif (Greek) by Vangelis  Karageorgos look like

Ben Laenen from the DejaVu project, an  gave the following comments/advice

> as Simos mentioned, Serif already has Greek since a very long
> time now.
>
> however, I've never been really too happy about it [current state of Greek in Serif --simos], and some
> improvements are still pending. I also must say that I like the style
> of Vangelis' glyphs, even though it has some things I've personally
> never been too keen about, like the ita and chi without descender. In
> the glyphs I designed I also removed the serifs on the descenders,
> but they seem to work in Vangelis' style.
>
> Now, before we start thinking about replacing the glyphs in DejaVu: I
> first want to see some feedback from the Greek users to see which
> style they would like more, and what would have to be changed before
> they would accept them.
>
> Also, if these new glyphs get included, the Greek Extended block
> should be altered as well (work I'm not very keen on doing myself
> since I know how boring that work is 🙂 Some other glyphs in the
> main Greek block may need changes as well.

Now, the question is, do you like the Greek edition of DejaVu Serif by Vangelis Karageorgos? If you do like it or you do not, please say so. It would also be good to specify what elements are better in the proposed version.

“Proposal for additional QA and localisation time on Dapper”

Mark Shuttleworth sent an e-mail titled Proposal for additional QA and localisation time on Dapper to request a six-week delay for the release of the next version of Ubuntu Linux.

meeting on Tuesday 14th March – once at 09:00 UTC (for the Aussies and Asian communities) and then again at 18:00 UTC (for Europe and the Americas). The meetings will be in #ubuntu-meeting on irc.freenode.net.

That is at 11:00am and 20:00pm local Greek time respectively. Try to make it on IRC this Tuesday!

If the delay for the release of Ubuntu 6.04 (now 6.05?) passes, it would create a perfect opportunity to make sure that Ubuntu 6.04 will work out of the box for the Greek users.

Therefore, please install Ubuntu Dapper (Flight 5 is currently the latest) and check to see if it works out of the box for tasks that relate to the Greek language. To search for existing bug reports or file new ones, use Launchpad. You can register and setup your account which will help you to follow bug reports for the Greek language. There are groups that you may join to, Ubuntu Greek Testers, Ubuntu Greek Users and Ubuntu Greek Translators. In addition, there is a mailing list with a vibrant community to help fix problems in Ubuntu for the Greek language, Ubuntu Greek mailing list. Join up and see the list archives for the discussions that took place.