Re: [File Roller] Supporting Unicode Enabled ZIP Archive When Using Info-ZIP Stack

[Simos Xenitellis]

On Mon, Nov 12, 2012 at 9:44 AM, Ma Xiaojun  wrote:
> Bug Hint (not reported by me):
> https://bugzilla.gnome.org/show_bug.cgi?id=648673
>
> There are basically two kinds of ZIP archive. Those with random file
> name encoding (not Unicode enabled) and those with UTF-8 file name
> encoding and proper meta data set (Unicode enabled).
>

Also see
https://bugzilla.gnome.org/show_bug.cgi?id=306403
https://bugzilla.redhat.com/show_bug.cgi?id=225576

> UnZip 6.0 (the current latest released version) from Info-ZIP can
> extract Unicode enabled archive correctly. However, it's listing
> feature would treat any non-ASCII character in file name as '?', even
> for Unicode enabled archives. This affects File Roller also so we have
> above mentioned bug.
>
> Fortunately, UnZip has a -U option. When dealing with Unicode enabled
> archives, it will escape non-ASCII character to #U or #LYY. I
> already made a working patch for File Roller to utilize this.
> https://gist.github.com/4057999
>
> Unfortunately, #U or #LYY are also legitimate file names in
> ZIP archives and UnZip's -U option doesn't escape literal # currently.
> I'm trying to contact the upstream already.
> http://www.info-zip.org/phpBB3/viewtopic.php?f=4&t=405
>
> In the File Roller side, we may list the archive twice, one without -U
> and one with -U. Then we can determine which # is literal and which #
> is for escaping. There is another annoying detail worth noting here,
> Vanilla UnZip show exactly one ? for one Unicode character while
> patched UnZip (found in at least Arch and Ubuntu) show several ? for
> one Unicode character (the number of ? equals to number of UTF-8
> bytes).
>
> What do you think?

I think that the wider issue is about how to deal with legacy
(=non-UTF8) encodings.
Not only with filenames from within ZIP archives, but also text files
in legacy encoding (such as subtitles),
IDv3 tags and so on.

There have been some proposals to guess the legacy encoding (using
frequencies of letters, etc), however they add to the complexity.

AFAIK, if gtk/glib finds an invalid UTF-8 encoding in text, it tries
to convert from iso-8859-1 to UTF-8.
What I believe should happen is for gtk/glib to get a hint from the
operating system locale (i.e. a variable GTK_LEGACY_ENCODING), and
autoconvert any invalid text from GTK_LEGACY_ENCODING to UTF-8.

For your case with ZIP archives, you deal with archives that may have
been created with a localised version of Windows, thus the filenames
may have a legacy encoding.

Thus, my easy recommendation:

   File-roller considers all ZIP files to contain UTF-8 encoded
filenames. When it detects that the encoding is not UTF-8, then it
tries to convert from a legacy encoding to UTF-8. File-roller can
guess based on the system locale, or it can show to the user a dialog
box with the best guess, and allow to change encoding on the fly until
the filenames in the textbox make sense.

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[Simos Xenitellis]

On Sat, May 14, 2011 at 1:36 AM, Andre Klapper  wrote:
> On Fri, 2011-05-13 at 18:19 -0400, Matthias Clasen wrote:
>> On Fri, May 13, 2011 at 12:55 PM, Robert Ancell  
>> wrote:
>> > I was not going to propose this project because I am sick of this sort
>> > of unprofessional response, especially from leaders in the community.
>
>> So, you consider it an unprofessional response if we are not falling
>> over our feet in adopting a from-scratch rewrite of a core component
>> that has not even been field-tested in any release yet ?
>
> I think Robert's point was rather the disrespect shown by some wordings
> in responses ("architecture astronaut", anyone?) which is demotivating
> and makes the GNOME community look hostile.
>

I believe this is a situation which makes or breaks the feeling of
community within GNOME.
That is, this is a big deal.
There is a GNOME Code of Conduct at https://live.gnome.org/CodeOfConduct
though the thread participants did not sign it.
I think the GNOME Foundation should step in, if the attitude issues
are not resolved completely within this thread.

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Git: Do not use http to access Git!

[Simos Xenitellis]

On Thu, Feb 17, 2011 at 3:06 PM, Nicolas Trangez  wrote:
> On Thu, 2011-02-17 at 23:25 +1100, Danielle Madeley wrote:
>> On Thu, 2011-02-17 at 10:48 +0100, Olav Vitters wrote:
>>
>> > Some people have been using the cgit interface to checkout a lot of git
>> > modules. This cause a very high load on our server. Please use the git
>> > protocol instead. For now I've blocked git from accessing cgit as too
>> > many people have been using the http interface and it negatively impacts
>> > performance (very high loads over long periods).
>>
>> Is it possible these people are on ridiculous corporate networks that
>> only permit HTTP traffic (via a proxy) and allow no other outgoing
>> connections beyond their network?
>>
>> I have been on one of these before, http was the only way I could
>> checkout sources (from Subversion at the time).
>>
>> If this is the case, git being awesome as it is, perhaps someone could
>> set up a remote that offers http cloning that updates once a day or so.
>> This would let people clone a repo, and still submit their work via
>> format-patch etc.
>
> If this load issue concerns initial 'git clone' calls over HTTP, and not
> further updates ('git fetch'), a solution might be to create baseline
> tarballs (e.g. weekly) containing a packed HTTP clone, and put these
> available for download. HTTP users can download and unpack these, then
> use the repository as usual. This should reduce load on the server, as
> well as reduce the time a developer needs to get his repository clone up
> and running.
>
> This method was/is used by several other projects using
> CVS/SVN/Monotone/...
>

This would be amazing to have. It has been mentioned before.
I understand though it might be difficult to set it up and get it working.

It would also benefit those without reliable Internet connections.
When you 'git clone' and the Internet connection drops, you need to
start over.

Some could also use a download manager in order to get those tarballs
of repositories.

With these 'baseline tarballs', tools like jhbuild could grab the
tarballs of the repositories through HTTP, then 'git pull --rebase' to
get them in sync.

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: List translators script

[Simos Xenitellis]

On Wed, May 20, 2009 at 8:29 PM, daniel g. siegel wrote:

> On Mi, 2009-05-20 at 14:59 +0200, Vincent Untz wrote:
> > Le lundi 18 mai 2009, à 23:01 +0200, daniel g. siegel a écrit :
> > > i have also working list_translators.sh here, which i enhanced to my
> > > needs. please find it attached.
> >
> > You're missing " -- $1" in diff_files.
>
> and youre right ;)
>
> fixed version is attached


A final touch is to change

function diff_files() {
  git diff $TAG..HEAD --name-only -- $1 | grep "\.po$"
}

to

diff_files() {
  git diff $TAG..HEAD --name-only -- $1 | grep "\.po$"
}

The 'function' build-in is a bash-ism, which does not work with 'dash', the
default shell in Ubuntu (and probably elsewhere).
Bash is still OK when you don't specify the 'function' built-in.

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: R: git migration - svn:externals

[Simos Xenitellis]

On Sat, Apr 25, 2009 at 1:17 PM, Felipe Contreras
 wrote:
> On Thu, Apr 23, 2009 at 2:27 PM, Zeeshan Ali (Khattak)  
> wrote:
>> On Thu, Apr 23, 2009 at 1:24 PM, Tim-Philipp Müller  wrote:
>>> On Thu, 2009-04-23 at 12:09 +0200, Jaap A. Haitsma wrote:
>>>
 I think gst-ffmpeg uses this feature. gst-ffmpeg is in git while it
 uses ffmpeg which is in svn.
>>>
>>> Not really - gst-ffmpeg just runs svn checkout in autogen.sh, and that's
>>> it.
>>>
>>> We use git submodules in GStreamer though (we have a 'common' submodule
>>> for all other modules), but git submodules are still fairly cumbersome
>>> to use and I wouldn't recommend them until the git people make them less
>>> painful to use, at least not for projects where the submodule reference
>>> needs to be updated frequently.
>>
>>   This whole idea of sub-modules is just brain-dead so I wouldn't
>> count on git developers fixing that instead of concentrating on
>> features of real importance. If you have some code (or even data) that
>> is needed by more than one of your modules/packages, you either put
>> that common stuff in another module/package and make other packages
>> depend on this or you just bite the bullet and don't mind the
>> redundancy. In some cases you just have to wisely use the combination
>> of both.
>
> I'm involved a bit in git development and I have to say that view is
> pretty much accurate.
>
> 'git submodule' is essentially a big hack and nobody from the main
> developers is actively working on it. Of course patches are accepted
> and support is improving, but I wouldn't recommend any major projects
> to depend on it.

There was a suggestion at gnome-i18n to have all translation material in
a single repository (such as 'lang-LL', where LL is the a lanugage code),
and then have a super-lang module with all those individual submodules.
Then, any GNOME module would simply need to have the super-lang module as
its submodule, to cater for the l10n needs.
http://mail.gnome.org/archives/gnome-i18n/2009-January/msg00201.html

In theory it looked good; in practice it was quite error-prone due to
the sequence
of commands that one currently needs to run with git, in order to activate the
submodules. And other usability and maintenance issues.

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: git commit messages

[Simos Xenitellis]

On Wed, Apr 22, 2009 at 4:09 PM, Christophe Fergeau  wrote:
> Hi Vincent,
>
> 2009/4/22 Vincent Untz 
>>
>> - When committing code on behalf of others use the --author option, e.g.
>>    git commit -a --author "Joe Coder " and --signoff.
>>
>> 
>>
>>
>> Opinions?
>
> Not sure about the --signoff part. The committer email/name is already
> silently added to the commit by git even when using --author. Moreover, When
> reading the "12) Sign your work " section of SubmittingPatches from the
> linux kernel source (
> http://lxr.linux.no/linux/Documentation/SubmttingPatches ), it seems to me
> that using SignedOffBy is useless if the initial author of the patch didn't
> use it :
>
> "The sign-off is a simple line at the end of the explanation for the patch,
> which certifies that you wrote it or otherwise have the right to pass it on
> as a open-source patch." (snipped a lot of explanations after this sentence)

There was a recent discussion on this,
http://mail.gnome.org/archives/gnome-infrastructure/2009-April/msg00011.html

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Git documentation reorganization and cleanup

[Simos Xenitellis]

On Sat, Apr 18, 2009 at 5:14 PM, Santi Béjar  wrote:
> 2009/4/18 Owen Taylor :
>> ===
>> In Git, branches and tags are simply references to a commit. You can
>> check out a branch using the following command, once you have cloned the
>> project:
>>
>> git checkout [branch name]
>>
>> For a list of the available branches for a given project:
>>
>> git branch -r
>>
>> The following example will check out gnome-utils master and then check
>> out the 'gnome-2-0' branch:
>>
>> git clone git://git.gnome.org/gnome-utils
>> cd gnome-utils
>> git checkout gnome-2-0
>> ===
>>
>> That obviously doesn't work - it needs to show:
>>
>>  git checkout -b [branch name] origin/[branch name]
>>
>> For initially creating the local branch, and have some explanation of
>> what is going on.
>>
>> (It's a little confusing here to use git checkout -b to create the
>> branch... multiple things going on at once; but 'git checkout -b' has
>> the important side-effect of setting up the new branch to pull from the
>> origin, which you would have to do manually if you used 'git branch' to
>> create the branch.)
>
> git branch [branch name] origin/[branch name]
>
> also does the setup the same way as ´git checkout -b´.

In Git 1.6.1 or newer, one can do

git checkout --track origin/[branch name]

and this creates the [branch name] branch. The usability benefit is not having
to write the branch name twice.

It appears a common error with 'git checkout -b [branch name]
origin/[branch name]'
is that when you write by accident as 'git checkout -b origin/[branch name]'
the command succeeds, but it creates a local branch which is a copy of 'master',
and has the name 'origin/[branch name]'.
'git checkout' does not warn if you create a branch name with a '/' in the name.

In older versions of Git, the "git checkout --track origin/[branch
name]" syntax
does not work due to a bug, http://lkml.org/lkml/2008/12/25/8

«* "git checkout --track origin/hack" used to be a syntax error.  It now
 DWIMs to create a corresponding local branch "hack", i.e. acts as if you
 said "git checkout --track -b hack origin/hack".»

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: enable accessibility by default for GNOME

[Simos Xenitellis]

From the Bugsquad mailing list,
an issue about openoffice.org (java-related?) misbehaving when
accessibility is on,
http://mail.gnome.org/archives/gnome-bugsquad/2008-February/msg00031.html
http://mail.gnome.org/archives/gnome-bugsquad/2008-September/msg00018.html

Another issue is Eclipse (java) does not exit cleanly when accessibility is on,
http://bugzilla.gnome.org/show_bug.cgi?id=546542

Simos

On Sat, Sep 13, 2008 at 12:40 PM, Kjartan Maraas <[EMAIL PROTECTED]> wrote:
> ma., 08.09.2008 kl. 21.39 +0300, skrev Claudio Saavedra:
>> El mié, 30-07-2008 a las 15:56 -0500, Diego Escalante Urrelo escribió:
>> > On 7/30/08, Bastien Nocera <[EMAIL PROTECTED]> wrote:
>> > > On Wed, 2008-07-30 at 12:00 -0400, Willie Walker wrote:
>> > >  > Hi All:
>> > >  >
>> > >  > I recently had a nice discussion with the release team about the
>> > >  > viability of enabling accessibility (i.e., the AT-SPI infrastructure)
>> > >  > by
>> > >  > default for GNOME.  As a result of that discussion, I'm approaching
>> > >  > the
>> > >  > broader GNOME community with a proposal to do this.  :-)
>> > >
>> > >
>> > > I'd agree if you can show that there's little to no performance hit from
>> > >  enabling it. I'd go even further and say that we should not make it
>> > >  possible to disable it within the UI if you can show that it won't have
>> > >  adverse effects on most users (that don't need a11y...).
>> > >
>> >
>> > I have froze my whole session by getting the at-spi stuff to crash.
>> > More concrete examples include eog not loading images anymore after
>> > crashing at.
>> > And I gotta say my crashes were random, happened in 2.20, 2.22.
>>
>> That's  http://bugzilla.gnome.org/show_bug.cgi?id=547373
>>
>> There's also this ugly emacs+metacity+a11y lock, that makes my computer
>> unusable. I think I hadn't noticed this before because I was using some
>> emacs snapshot, but now I switched laptops and haven't got the time to
>> compile it...
>>
>>   http://bugzilla.gnome.org/show_bug.cgi?id=392889
>>
>>
>> I haven't experienced more issues so far, but that's enough for me. I'm
>> disabling it.
>>
> I was forced to do the same last time I tried it, and that was a good
> while ago. We should definitely spend some time figuring that one out.
>
> Cheers
> Kjartan
>
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: enable accessibility by default for GNOME

[Simos Xenitellis]

On Thu, Jul 31, 2008 at 4:52 PM, Fernando Herrera <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Thu, Jul 31, 2008 at 5:32 PM, Willie Walker <[EMAIL PROTECTED]> wrote:
>
>> PRIMARY ARGUMENTS FOR ENABLING A11Y BY DEFAULT:
> [...]
>> 2) The a11y infrastructure can be used for more things than just a11y.
>> Consider, for example, an on screen keyboard for devices w/o physical
>> keyboards.
>
> I'd add scripting features here.
>
> With python dogtail bindings is quick and easy to write powerful
> scripts for your desktop. This is not an end-user feature at all, but
> is not an advanced-hacker-only one. So not having a11y enabled by
> default limits scripts creating/deployment to those users that enable
> a11y themselves and write their own scripts.
>
> Having a11y enabled by default would allow people to write and
> distribute those scripts for normal users.

An issue would be that with this facility it is possible for user apps
to capture keys, including passwords.

a. Enable Assistive Technologies
b. Install python-dogtail
c. Run dogtail-recorder, and keep it running
d. Start System/Administration/Synaptic
In Ubuntu it will ask you for your password. In other distros, select
an appropriate program that asks a password.
e. dogtail-recorder manages to capture the password entered.

Is it possible to disable the capturing of keys when a textbox is set
to show ●●● (instead of the actual characters)?

Is there a way to disable the capturing of keys in a textbox in a
non-reversible way once you requested it to show ●●●?
In Windows, you can change back and forth by sending events, which
allows to capture passwords.

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Quotation marks: Using “” instead of ""

[Simos Xenitellis]

O/H Shaun McCance έγραψε:
> On Tue, 2008-05-13 at 17:36 +0100, Alan Cox wrote:
>   
>>> Honestly, other than being pedantic, I don't see the
>>> problem with UTF-8 in the C locale.  Does it cause
>>> any *actual* problems?  I've never once gotten a bug
>>> report against g-d-u about this.
>>>   
>> Sort order, comparisons, printing, string lengths when using locale aware
>> functions, and no doubt a few more that for the moment have escaped me.
>>
>> Use the tools to spec and you get reliable predictable results, do
>> otherwise and it all gets sloppy and buggy. Would you rely on undefined C
>> behaviour in Gnome code ?
>>
>> The discussions about it being work are also bollocks (to use a fine bit
>> of en_GB). Make was invented to handle such trivial tasks for you.
>> 
>
> OK, time for a concrete example.  I'm writing a dialog
> with the following message:
>
>   The file “%s” could not be found.
>
> This is a message that gets put onto a gray box on the
> screen.  It's not put into any sort of list that gets
> sorted.  I'm not comparing it to anything or taking its
> length (and if I were, I'd use the GLib functions which
> Do The Right Thing).
>
> If I have to use the en translation, then I have to put
> this string in the source code:
>
>   The file "%s" could not be found.
>
> Then I have to run 'intltool-update en', open en.po,
> and add the translation.  That's more steps, none of
> which involve make.  How does make help me?
>   
I suppose make would invoke the script that would do the menial task for 
the en translations.
You normally would not edit by hand the en/en_US translations.

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Quotation marks: Using “” instead of ""

[Simos Xenitellis]

O/H Thomas Thurman έγραψε:
> Ysgrifennodd Alan Cox <[EMAIL PROTECTED]>:
>   
>> Sort order, comparisons, printing, string lengths when using locale aware
>> functions, and no doubt a few more that for the moment have escaped me.
>>
>> Use the tools to spec and you get reliable predictable results, do
>> otherwise and it all gets sloppy and buggy. Would you rely on undefined C
>> behaviour in Gnome code ?
>> 
>
> I'm surprised that it's been a whole day and nobody's jumped out
> saying "Non-ASCII encodings for source strings in gettext files are
> broken?  Why, what a perfect opportunity to switch to xliff!"
>   
xliff support to the gettext level could require a gyoc program (google 
year of code).

I made a blog post on the non-ascii issue which received a few comments,
http://blogs.gnome.org/simos/2008/05/14/should-ui-strings-in-source-code-have-non-ascii-characters/

My view from all comments goes like this,

a. The canonical way to deal with UI messages in the source code is to 
keep them simple (ASCII), and put any variations in the appropriate 
locale. For en_US, use the translation files for en_US.

In localisation terms, a single change in a message in the source code 
affects over 60 languages, so UI messages in the source code should stay 
simple and not change.

b. Going for (a) would entail quite some work that we do not appear to 
have people to do. Any en_US translators? Probably not.

c. It appears that the GNOME apps do not fail miserably if there are 
UTF-8 strings in the source files. Such strings have been there since 
GNOME 2.20, and possibly earlier. However, these were high level 
applications (evince, epiphany, etc), which means that we do not know 
for sure yet if someone who works directly with glib, gtk+ user would be 
affected (for example, in embedded systems).
The easy way to figure out if they are affected is to add a UTF-8 
character in some message in glib, then wait and see ;-).

Simos

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Quotation marks: Using “” instead of ""

[Simos Xenitellis]

O/H BJörn Lindqvist έγραψε:
> On Tue, May 13, 2008 at 2:19 PM, Christian Neumair <[EMAIL PROTECTED]> wrote:
>   
>> Alex Jones proposed [1] to change the quotation marks in Nautilus
>>  strings from the ASCII representation "..." to the unicode variant
>>  "...".
>>
>>  I think the proposed quotation marks are aesthetically more pleasing,
>>  but I don't want to change this unless there is a GNOME-wide policy.
>>
>>  I hereby propose to establish a GNOME policy of using "..." for
>>  quotations. Comments, objections?
>> 
>
> Great idea!
>   
I blogged about it at
http://blogs.gnome.org/simos/2008/05/14/should-ui-strings-in-source-code-have-non-ascii-characters/
There might be some further input.

My main concern is how systems such as FreeBSD with GNOME behave 
(apparently they use non-UTF8 encodings). I did not manage to duplicate 
the behaviour on Ubuntu, so if someone has a system with legacy 8-bit 
encoding, could you please check?

Simos

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Quotation marks: Using “” instead of ""

[Simos Xenitellis]

O/H Shaun McCance έγραψε:
> On Tue, 2008-05-13 at 16:22 +0100, Simos Xenitellis wrote:
>   
>> I think the most important question to answer is whether we want to make 
>> POT files non-ASCII. That is, once messages have “”‘’, etc, then GNOME 
>> will be available for Unicode locales only.
>> If one starts GNOME with a C or a legacy 8-bit locale, it will not work.
>> 
>
> Don't we already have plenty of non-ASCII POT files?
> I know gnome-doc-utils is non-ASCII.
>> Personally I would say no to “” at this stage.
>> 
>
> I'm just wondering, if not now, when?  What do we have yet
> to accomplish that's blocking the use of proper typographic
> quotes?  I'm not trying to troll here.  It just seems to me
> that we've had all this functionality for quite a while, but
> we're still typing as if we're on old typewriters.  What do
> we need to do, as programmers, to get the world out of its
> ASCII rut?
Here is a link to the recent discussion about non-ASCII in translation 
files (=POT or source files),
http://www.mail-archive.com/[EMAIL PROTECTED]/msg05803.html

As a summary of that discussion, the general view was that it's ok to 
use UTF-8 in source files.
Karl Eichwalder then mentioned
“You'd better avoid such eye-candy stuff in source code. Instead do 
proper English translations and add en_US and en_GB files.”
Abel added that he remembered a previous discussion of a GNOME policy 
for "source code == en_US" (I presume he meant ASCII).
There was interest for a reference to that discussion but none  was 
provided and the thread ended there.

What I see here is that it would be good to rekindle that discussion 
"use of non-ascii characters in source translation messages", and get 
whatever the outcome as a GNOME policy.

Simos

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Quotation marks: Using “” instead of ""

[Simos Xenitellis]

O/H Pat Suwalski έγραψε:
> My objection may seem silly, but since there is no way to type it on any 
> keyboard out there, that's a bit of a hindrance. Short of using the 
> character map and searching, one has to resolve to using "smart 
> substitution" editors like OpenOffice to get the characters.
>   
The following keyboard layouts allow you to type those double quote marks:

al ba be br by ca ch cz de dk ee epo es fi fo fr gb hr hu ie is it latam 
lt lv mao me mk mn mt nl no pl pt ro rs se si sk tr ua us za

Layouts that are missing from above may not need them (for example, gr, 
which uses «»).

An issue is with some default layouts that may not enable those double 
quotes (you have to pick the appropriate layout variant). That is the 
case with “us”, where the default layout does not include the said 
characters.

In most layouts (such as the default for GB), “” are found when you 
press AltGr+v, AltGr+b.
For US, you need to pick the “intl” variant, and here it follows its 
own, with AltGr+[, AltGr+] respectively.
> They also tend to fail horribly when pasting into a non-Unicode 
> terminal, which is still often the case over SSH. Probably not a huge 
> desktop consideration, though. Every distribution I know of uses Unicode 
> by default on the local terminal at this point.
>   
This situation (whether to put “” or not) is similar to whether to 
include ellipsis in translation messages instead of “...”. I am not sure 
what was the resolution for that issue.

The two issues have similarities and an important difference; the text 
of the menu items cannot be copied by default (unless an accessibility 
application is active), which means that the text will probably not make 
it out of the application.

I think the most important question to answer is whether we want to make 
POT files non-ASCII. That is, once messages have “”‘’, etc, then GNOME 
will be available for Unicode locales only.
If one starts GNOME with a C or a legacy 8-bit locale, it will not work.

Personally I would say no to “” at this stage.

Simos
> --Pat
>
> Christian Neumair wrote:
>   
>> Alex Jones proposed [1] to change the quotation marks in Nautilus
>> strings from the ASCII representation "..." to the unicode variant
>> “...”.
>>
>> I think the proposed quotation marks are aesthetically more pleasing,
>> but I don't want to change this unless there is a GNOME-wide policy.
>>
>> I hereby propose to establish a GNOME policy of using “...” for
>> quotations. Comments, objections?
>>
>> best regards,
>>  Christian Neumair
>>
>> [1] http://bugzilla.gnome.org/show_bug.cgi?id=532777
>>
>> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Low memory hacks

[Simos Xenitellis]

Danilo Šegan wrote:
> Hi Simos,
>
> Yesterday at 15:02, Simos Xenitellis wrote:
>
>   
>>> I'll like to see some real numbers on the memory usage instead of
>>> numbers being thrown around.
>>>   
>> In Ubuntu 7.10, the PO files for en_GB are
>> $ du
>> -h /usr/share/locale/en_GB/LC_MESSAGES 
>> /usr/share/locale-langpack/en_GB/LC_MESSAGES/
>> 2.3M/usr/share/locale/en_GB/LC_MESSAGES
>> 17M /usr/share/locale-langpack/en_GB/LC_MESSAGES/
>> $_ 
>>
>> In Ubuntu 8.04 (alpha 6), the PO files for en_GB are
>> $ du
>> -h /usr/share/locale/en_GB/LC_MESSAGES 
>> /usr/share/locale-langpack/en_GB/LC_MESSAGES/
>> 84K/usr/share/locale/en_GB/LC_MESSAGES
>> 2.2M /usr/share/locale-langpack/en_GB/LC_MESSAGES/
>> $_ 
>>
>> What I am missing here is that I do not know when/how Ubuntu adds this
>> functionality. It would benefit other distros as well. Did Debian
>> introduce with feature? Danilo, any links?
>> 
>
> I am not handling Ubuntu packaging stuff—it'd be worth checking with
> Ubuntu guys instead.  Martin Pitt is probably the right person to ask
> about it, but looking at the language pack sourcepackage should give a
> clue as well.
>
> However, I'd note that en_GB is not really the right locale to do
> the metrics on.
>   
Hi Danilo,
Why would en_GB not be the right locale to do metrics on?
>   
>>> >From the 2.3M + 17M MO files in Ubuntu 7.10, a typical GNOME session
>>>   
>> loads up a subset of the MO files,
>>
>> # lsof | grep \.mo\$ | awk '{print $7,$9}' | sort -n | uniq
>>
>> At this moment, my 7.10 is a bit messed up (I have en_GB.UTF-8 but most
>> apps have en_US?!?). The figures for 8.04 with el_GR should be
>> comparative of what you get now with 7.10 and en_GB:
>> 
>
> They wouldn't be. A majority of el_GR probably uses two-byte UTF-8
> sequences, while en_GB would use a majority of single byte UTF-8
> sequences (i.e. ASCII).
>   
Good point. I provided in the other email figures from the same locale.
Halving the figures from "el" should give a very rough estimate.
>   
>> # lsof | grep \.mo\$ | awk '{print $7,$9}' | sort -n | uniq | awk
>> '{printf "%d+",$1}' > /tmp/bc_sums
>>
>> Using "bc" with /tmp/bc_sums gives the figure
>> 3.6M (3624412) for a standard session. This figure is a bit
>> conservative, because en_GB probably did more work than el.
>>
>> With Ubuntu 8.04 (alpha6) and en_GB, the figure for the MO files is
>> less than 600K (585375).
>> Bastien, could you provide the proper figure for your system?
>>
>> That is a saving of at least 3M in memory.
>> 
>
> As Bastien explained, mmap() doesn't read the entire file into memory,
> but only reads it as needed.
>
>   
>> The stripping of "unneeded" messages is good, and should happen at the
>> package generation level (not in GNOME, or when creating tarballs). 
>> 
>
> Technically, I've opposed introducing this in intltool because of a
> one incompatible difference:
>
>   current gettext("Something") != such gettext("Something")
>
> i.e. if "Something" was (un)translated as "Something" in the MO file,
> gettext would return a static pointer with the string "Something".  If
> it was untranslated, it would return the passed pointer.
>
> That can and was used to detect whether there is a translation in some
> programs (I've seen it done), so, until gains are proven to be big
> enough to warrant breaking a few programs in strange ways, I wouldn't
> do it on the packaging/build time.
>   
I do not know whether GNOME applications do (or have the need to do) 
such a check.
Can you give one example, in order to see why they need to find if there 
is a translation file?

A valid concern I have seen (and this has to do with correctness) is 
when people manually configure the LANGUAGE variable, with something 
like "es:fr:en". That is, pick the Spanish translation, if not available 
for a message pick French, else pick English. If the Spanish translation 
for a specific message is the same with English, but not in French, then 
the user will see the French translation (she should have seen the 
Spanish-English translation instead).

Danilo also gave an example with Serbian, if a user chooses something 
like "serbian_cyrillic:serbian_latin:en".

As far as I know, there is no UI tool (at least in GNOME) to set a 
triple LANGUAGE option.

For a general purpose system one may make the assumption that a single 
language is expected.
> Of course, providing numbers to show what the gains are would help
> make the decision.
>   
Assuming my memory figures are correct (previous e-mail), I have 
provided file size and memory figures.

Simos

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Low memory hacks

[Simos Xenitellis]

Rodney Lorrimar wrote:
> On Mon, Mar 17, 2008 at 02:22:44AM +0000, Simos Xenitellis wrote:
>   
>> Bastien Nocera wrote:
>> 
>>> On Mon, 2008-03-17 at 00:56 +, Simos Xenitellis wrote:
>>>   
>>>   
>>>> On Sun, Mar 16, 2008 at 11:25 PM, Bastien Nocera <[EMAIL PROTECTED]> wrote:
>>>>     
>>>> 
>>>>>  On Sun, 2008-03-16 at 14:02 +, Simos Xenitellis wrote:
>>>>>  
>>>>>
>>>>>   
>>>>>   
>>>>>> That is a saving of at least 3M in memory.
>>>>>> 
>>>>>> 
>>>>>  >
>>>>>  > The stripping of "unneeded" messages is good, and should happen at the
>>>>>  > package generation level (not in GNOME, or when creating tarballs).
>>>>>
>>>>>  You talk about memory savings, but do calculations based on file sizes.
>>>>>  That's doesn't work.
>>>>>   
>>>>>   
>>>> Aren't mo files mapped to memory?
>>>> 
>>>> 
>>> Yes, they're mapped. That doesn't result in actual memory usage. The
>>> kernel will make sure they're only read into memory as needed.
>>>   
>>>   
>> Is there a tool that shows which pages are in memory and which are in swap?
>> I do not know of such a tool, so I would expect the worst case scenario 
>> of all pages being in memory.
>> 
>
> On Linux, exmap can tell you this. It gives two figures, "effective
> resident" and "effective mapped". It counts each 4k page which is
> loaded. You can see the .mo files which are mapped into memory, how
> many pages are mapped, and which processes map the file. Unfortunately
> the website has gone offline, and that is the only place I know which
> has the documentation (have e-mailed the author about it). There are 2
> user interfaces:
>
> http://www.berthels.co.uk/exmap
> http://projects.o-hand.com/exmap-console
>
> For example, I have an Ubuntu 7.10 desktop with a few programs running
> (a couple standard applets, nautilus, gimp, epiphany, gcalctool) and
> LANG=pl_PL.UTF-8. exmap-console and gnumeric tell me the mapped memory
> usage of all .mo files is 1584kb.
>   
I tried out exmap-console. There are there columns with numbers for the 
MO files, labeled "sole", "file" and "file-VM".
"sole" is apparently the memory in multiples of page size, that can fit 
the file.
I do not know what is the difference between "file" and "file-VM".
If "file" is the amount of memory that is being used currently, then,

* in Ubuntu 7.10
* with en_GB.UTF-8 (fixed)
* with gimp, iagno, nautilus open (Firefox, Thunderbird, OOCalc do not 
appear as .mo files)
* installation deviates from typical (for example, no accessibility 
enabled).

the number that OOCalc gives is 2,420,736 bytes.

While,
* in Ubuntu 8.04 (alpha6), i.e. stripped MO files,
* with en_GB.UTF-8
* with gimp, iagno, nautilus open
* standard installation, (=accessibility enabled)

the number that OOCalc gives is 1,646,592.

The difference is over 700KB of memory.

For reference, for Greek, the memory use is about 5.8MB (Ubuntu 8.04Alpha).
>   
>> The messages in a .mo file are in no specific order, so I would expect 
>> that within a page there should be at least a message an application 
>> requires at any time.
>>
>> The important part, however, is that when a translation is exactly the 
>> same with the original message, then this entry is not required to exist 
>> in the MO file; the running application can find the original message 
>> withing the application itself. By stripping the MO file of such 
>> messages, the file size reduces and most probably there is reduction in 
>> memory use (between 0 to .mo file size).
>>
>> Is this description clear? Do you think that the savings would be so 
>> minimal that one would not need to bother working on this?
>> 
>
> Could be... what percentage of translations in en_GB do you think are
> duplicates? Was it 86% (100% - 2MB/14MB) ?
>   
This amount of translation strings are not required for the correct 
representation of en_GB (pending the issue that Danilo raised).

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Low memory hacks

[Simos Xenitellis]

Bastien Nocera wrote:
> On Mon, 2008-03-17 at 00:56 +0000, Simos Xenitellis wrote:
>   
>> On Sun, Mar 16, 2008 at 11:25 PM, Bastien Nocera <[EMAIL PROTECTED]> wrote:
>> 
>>>  On Sun, 2008-03-16 at 14:02 +, Simos Xenitellis wrote:
>>>  
>>>
>>>   
>>>> That is a saving of at least 3M in memory.
>>>> 
>>>  >
>>>  > The stripping of "unneeded" messages is good, and should happen at the
>>>  > package generation level (not in GNOME, or when creating tarballs).
>>>
>>>  You talk about memory savings, but do calculations based on file sizes.
>>>  That's doesn't work.
>>>   
>> Aren't mo files mapped to memory?
>> 
>
> Yes, they're mapped. That doesn't result in actual memory usage. The
> kernel will make sure they're only read into memory as needed.
>   
Is there a tool that shows which pages are in memory and which are in swap?
I do not know of such a tool, so I would expect the worst case scenario 
of all pages being in memory.

The messages in a .mo file are in no specific order, so I would expect 
that within a page there should be at least a message an application 
requires at any time.

The important part, however, is that when a translation is exactly the 
same with the original message, then this entry is not required to exist 
in the MO file; the running application can find the original message 
withing the application itself. By stripping the MO file of such 
messages, the file size reduces and most probably there is reduction in 
memory use (between 0 to .mo file size).

Is this description clear? Do you think that the savings would be so 
minimal that one would not need to bother working on this?

Simos

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Low memory hacks

[Simos Xenitellis]

On Sun, Mar 16, 2008 at 11:25 PM, Bastien Nocera <[EMAIL PROTECTED]> wrote:
>
>  On Sun, 2008-03-16 at 14:02 +, Simos Xenitellis wrote:
>  
>
> > That is a saving of at least 3M in memory.
>  >
>  > The stripping of "unneeded" messages is good, and should happen at the
>  > package generation level (not in GNOME, or when creating tarballs).
>
>  You talk about memory savings, but do calculations based on file sizes.
>  That's doesn't work.

Aren't mo files mapped to memory?

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Low memory hacks

[Simos Xenitellis]

On Thu, 2008-03-13 at 18:38 +, Bastien Nocera wrote:
> On Thu, 2008-03-13 at 18:26 +0000, Simos Xenitellis wrote:
> 
> > Some messages do not get translated, so you see in the translations
> > files things like
> > 
> > msgid "DEFAULT"
> > msgstr "DEFAULT"
> > 
> > This is convenient, because in the statistics you can see the app
> > fully translated.
> > 
> > This also means that the MO file will still have an entry for these
> > two. Going through the MO files and removing these few occurrences
> > will free a bit of disk space, but also memory.
> > For some locales such as en_GB, this can account to about 14MB of MO
> > files while the real space should be close to 2MB.
> 
> We do this to look good in the translation stats (and know when to
> update the translations, which is a pretty big point).

That is good, and many other teams (non-English) do the same thing. The
PO format does not have a facility to tag messages as "I reviewed this
translation, and it should appear as the original". A move to XILFF may
help here.

But the end-result is that one can optimise by stripping off identical
messages, when creating the distribution packages.

> I'll like to see some real numbers on the memory usage instead of
> numbers being thrown around.

In Ubuntu 7.10, the PO files for en_GB are
$ du
-h /usr/share/locale/en_GB/LC_MESSAGES 
/usr/share/locale-langpack/en_GB/LC_MESSAGES/
2.3M/usr/share/locale/en_GB/LC_MESSAGES
17M /usr/share/locale-langpack/en_GB/LC_MESSAGES/
$_ 

In Ubuntu 8.04 (alpha 6), the PO files for en_GB are
$ du
-h /usr/share/locale/en_GB/LC_MESSAGES 
/usr/share/locale-langpack/en_GB/LC_MESSAGES/
84K/usr/share/locale/en_GB/LC_MESSAGES
2.2M /usr/share/locale-langpack/en_GB/LC_MESSAGES/
$_ 

What I am missing here is that I do not know when/how Ubuntu adds this
functionality. It would benefit other distros as well. Did Debian
introduce with feature? Danilo, any links?

>From the 2.3M + 17M MO files in Ubuntu 7.10, a typical GNOME session
loads up a subset of the MO files,

# lsof | grep \.mo\$ | awk '{print $7,$9}' | sort -n | uniq

At this moment, my 7.10 is a bit messed up (I have en_GB.UTF-8 but most
apps have en_US?!?). The figures for 8.04 with el_GR should be
comparative of what you get now with 7.10 and en_GB:

# lsof | grep \.mo\$ | awk '{print $7,$9}' | sort -n | uniq | awk
'{printf "%d+",$1}' > /tmp/bc_sums

Using "bc" with /tmp/bc_sums gives the figure
3.6M (3624412) for a standard session. This figure is a bit
conservative, because en_GB probably did more work than el.

With Ubuntu 8.04 (alpha6) and en_GB, the figure for the MO files is
less than 600K (585375).
Bastien, could you provide the proper figure for your system?

That is a saving of at least 3M in memory.

The stripping of "unneeded" messages is good, and should happen at the
package generation level (not in GNOME, or when creating tarballs). 

Simos


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Low memory hacks

[Simos Xenitellis]

On Fri, Feb 29, 2008 at 2:37 PM, Nikolay V. Shmyrev <[EMAIL PROTECTED]> wrote:
> В Птн, 29/02/2008 в 13:32 +, Brian Nitz пишет:
>
> > Kalle Vahlman wrote:
>  > > 2008/2/29, Nickolay V. Shmyrev <[EMAIL PROTECTED]>:
>  > >
>  > >>  Heh, I also would like to delete all .po files if only I knew how to
>  > >>  keep translations :)
>  > >>
>  > >
>  > > Deleting .po:s would be futile as those are just the sources from
>  > > which the actual (binary) files loaded are compiled ;)
>  > >
>  > I agree that deleting the .po files probably won't impact your physical
>  > memory footpring.
>  > > Even so, you only have the translations of your current locale loaded
>  > > into RAM so by deleting all the others you only save disk space. AFAIK
>  > > that should be safe to do though.
>  > >
>
>  Ups, sorry, of course I meant .mo files here. Unlocalized application
>  should be a bit faster for sure, the problem is to keep the balance
>  between localization and memory/speed. For example I don't need gconf
>  translations at all.


Some messages do not get translated, so you see in the translations
files things like

msgid "DEFAULT"
msgstr "DEFAULT"

This is convenient, because in the statistics you can see the app
fully translated.

This also means that the MO file will still have an entry for these
two. Going through the MO files and removing these few occurrences
will free a bit of disk space, but also memory.
For some locales such as en_GB, this can account to about 14MB of MO
files while the real space should be close to 2MB.
This issue has been fixed in Ubuntu 8.04, though I believe each distro
has to reinvent the wheel.

Simos
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

RE: Nautilus unmount volume, also power-off?

[Simos Xenitellis]

On Mon, 2008-02-04 at 13:55 +0100, Jan de Groot wrote:
> > -Oorspronkelijk bericht-
> > Van: [EMAIL PROTECTED] [mailto:desktop-devel-list-
> > [EMAIL PROTECTED] Namens Simos Xenitellis
> > Verzonden: maandag 4 februari 2008 12:58
> > Aan: GNOME Desktop Devel
> > Onderwerp: Nautilus unmount volume, also power-off?
> > 
> > Hi All,
> > 
> > Currently Nautilus offers the option to either unmount or eject (if
> > suitable) a volume, such as an external USB harddisk or flash drive.
> > 
> > There has been discussion in user forums if it is possible to power off
> > those external storage devices as well,
> > http://ubuntuforums.org/showthread.php?mode=hybrid&t=451344
> > http://www.techteam.gr/index.php?showtopic=118719
> > 
> > A way to implement the "unmount+poweroff" in Nautilus is to create a
> > Nautilus action that calls "umount", then "sdparm --command=stop", and
> > there is such a script circulating the forums.
> > 
> > ...
> > 
> > I am wondering if there are any gotchas to this approach.
> 
> Nice proposal, though I think this shouldn't be done by nautilus, but should
> be exported by hal as command so any program can call the specific command
> without adding extra code. Hal knows what volumes on a device are mounted
> and which are not. And hal is the place where we should put these
> platform-specific things (I can imagine that sdparm won't work on FreeBSD or
> Solaris for example).

The way I see it implemented at the moment, I think that it would
require changes in 
http://svn.gnome.org/viewvc/glib/trunk/gio/gunixmount.c?view=annotate
(see around line 350).
That's by following how "umount" and "eject" are implemented.
I think the code uses already HAL to figure out which devices are
mounted.

The changes in Nautilus should be just to figure out which "unmount" to
call, either plain umount or umount+poweroff.

Apparently, both sg3_utils and sdparm have been ported to Solaris,
FreeBSD, etc,
http://kerneltrap.org/Linux/SCSI_Utility_sdparm_1.02
http://sg.torque.net/sg/sg3_utils.html
What I do not know is if they are part of the standard installation.

Simos


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Nautilus unmount volume, also power-off?

[Simos Xenitellis]

Hi All,

Currently Nautilus offers the option to either unmount or eject (if
suitable) a volume, such as an external USB harddisk or flash drive.

There has been discussion in user forums if it is possible to power off
those external storage devices as well,
http://ubuntuforums.org/showthread.php?mode=hybrid&t=451344
http://www.techteam.gr/index.php?showtopic=118719

A way to implement the "unmount+poweroff" in Nautilus is to create a
Nautilus action that calls "umount", then "sdparm --command=stop", and
there is such a script circulating the forums.

Here is what I have in mind in implementing this
a. An external device can have several partitions. A power-off must be
attempted only when all partitions have been unmounted. Currently, the
UI does not offer yet an option of the sort "You have 4 partitions
mounted, shall I unmount them all?" but this can be done latter.
b. The user should not be confronted with information on "power-off"; a
power-off should be attempted when the last partition of a device has
been unmounted. That appears to be the case in Win/OSX.
c. Sending the STOP command appears not to work for some external USB
devices. I think it should be ok to try it anyway after the last umount
of a partition.
An alternative to sdparm is "sg_start --stop /dev/sdX".
d. Sending STOP to a flash drive can switch off the indicator light,
which is nice feedback to the user that they can unplug. 
d. This requires distributions to include "sdparm" or "sg3_utils" by
default.

I am wondering if there are any gotchas to this approach.

Simos


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Input devices capplets

[Simos Xenitellis]

On Mon, 2007-11-05 at 17:57 +0100, Rodrigo Moya wrote:
> On Wed, 2007-10-31 at 18:59 +0100, Denis Washington wrote:
> > Hi,
> > 
> > I created two mockups for possible keyboard and mouse capplets in GNOME
> > 2.20. Their aim is to incorporate accessibility features in both; the
> > existing keyboard a11y features into Keyboard and the already discussed
> > Mousetweaks settings into Mouse. The mockups can be found here:
> > 
> > Keyboard: http://ultimum-projekt.de/mockups/keyboard.html
> > Mouse:http://ultimum-projekt.de/mockups/mouse.html
> > 
> > What do you think?
> > 
> I think they look good, given we can't really merge them on a single
> capplet. The keyboard capplet has many tabs, but this is much better
> than having separate a11y capplets, so, unless something better is
> proposed, you've got my vote :)

In the keyboard capplet it would be good to add on the Layouts tab the
option to configure the keyboard shortcut used to switch between
layouts. Currently this option is located in the Layout Options tab,
inside Group Shift/Lock behaviour, towards the end of the list.

I propose to use the real estate under the Remove, Add buttons shown at
http://ultimum-projekt.de/mockups/keyboard-2.png

It should show something like

Switch layout with [ Alt-Shift ]   [Change...]  

where [Change] is a button to a new dialog box showing potential
keyboard shortcuts to switch language.

The new dialog box should have the content of the Group shift/Lock
behaviour.

Simos


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: i18n of Turtle files for xesam project?

[Simos Xenitellis]

Στις 26-05-2007, ημέρα Σαβ, και ώρα 14:57 +0200, ο/η Mikkel Kamstrup
Erlandsen έγραψε:
> 2007/5/26, Simos Xenitellis <[EMAIL PROTECTED]>:
> Στις 26-05-2007, ημέρα Σαβ, και ώρα 10:19 +0200, ο/η Mikkel
> Kamstrup
> Erlandsen έγραψε:
> > Hi Gnomers,
> >
> > I also sent this mail to gnome-i18n a few days ago without
> any replies
> > and the xesam project[1] badly needs feedback from
> enlightened people. 
> >
> > Here's the case. We need a way for describing our ontology
> and one of
> > the runner up candidates is a subset of the Turtle
> syntax[2]. The
> > files describing the ontology would then resemble: 
> >
> > START_FILE
> >
> > @prefix DC:   <http://freedesktop.org/standards/DC#>
> > @prefix xesam:<
> > http://freedesktop.org/standards/xesam#>
> > @prefix : <
> > http://freedesktop.org/standards/xesam_base#>
> >
> > xesam:Audio.Composer 
> >   a   :field;
> >   :of_type:string;
> >   :has_parent DC:Creator;
> >   :name   "Composer"@EN;
> >   :name   "Komponist"@DA; 
> >
> >   :description"Audio composer".
> >
> > xesam:Audio.Artist
> >   a   :field;
> >   :of_type:string;
> >   :has_parent DC:Creator;
> >   :name   "Artist"@EN;
> >   :name   "Kunstner"@DA;
> >   :description"Performer featuring in the
> recording"@EN;
> >
> >   :description"Kunster der optræder på
> optagelsen"@DA. 
> >
> > 
> > END_FILE
> >
> > As you can guess the translations are marked with @ after
> the strings.
> >
> > My question is : Will this cause problems or be a major
> hassle? How 
> > will it fit into the current translation workflow?
> 
> Currently, the gnome i18n workflow can easily use .xml and .po
> files.
> For other file formats there will be need for quite some extra
> work.
> Thus, if you would like to use your proposed file format, you
> would need 
> to update http://svn.gnome.org/viewcvs/intltool/ Of course,
> contact the
> maintainer of intltool first.
> 
> AFAIK, if intltool can parse your files, they will fit with
> the workflow 
> of GNOME.
> 
> Ok thanks for the tip :-)
> 
> How about the way fx .desktop files are handled? The translations are
> inlined in the .desktop files and that's also the way Turtle does it
> (see above example). So my concerns where about: 
> 
>  - I'm not keen on requiring the translators to understand
> yet-another-format, so I'm not keen on the translators having to
> resort to raw file editing
> 
>  - How hard would it be to make intltool extract the Turtle
> translation templates? Is there no way to tell intltool "use this
> external program to extract translation templates"? I've been browsing
> around the source and I can't find any clean way to extend it... 

Oh, intltool also understands .desktop files. From the README file
(http://svn.gnome.org/svn/intltool/trunk/README)

The intltool collection can be used to do these things:
 o Extract translatable strings from various source files (.xml.in,
   .glade, .desktop.in, .server.in, .oaf.in).
 o Collect the extracted strings together with messages from traditional
   source files (.c, .h) in po/$(PACKAGE).pot.
 o Merge back the translations from .po files into .xml, .desktop and
   .oaf files.  This merge step will happen at build resp. installation
   time.

I do not think it would be hard to extract the text from Turtle
translation templates. Just follow the example of the .desktop files
which should be very similar. You would need to code in Python a few
functions to extract/put back the translation messages. Is there some
Python module/code that understands the Turtle format (or the general
format that Turtle uses)?

Simos

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: i18n of Turtle files for xesam project?

[Simos Xenitellis]

Στις 26-05-2007, ημέρα Σαβ, και ώρα 10:19 +0200, ο/η Mikkel Kamstrup
Erlandsen έγραψε:
> Hi Gnomers,
> 
> I also sent this mail to gnome-i18n a few days ago without any replies
> and the xesam project[1] badly needs feedback from enlightened people.
> 
> Here's the case. We need a way for describing our ontology and one of
> the runner up candidates is a subset of the Turtle syntax[2]. The
> files describing the ontology would then resemble: 
> 
> START_FILE
> 
> @prefix DC:   
> @prefix xesam:<
> http://freedesktop.org/standards/xesam#>
> @prefix : <
> http://freedesktop.org/standards/xesam_base#>
> 
> xesam:Audio.Composer
>   a   :field;
>   :of_type:string;
>   :has_parent DC:Creator;
>   :name   "Composer"@EN;
>   :name   "Komponist"@DA;
> 
>   :description"Audio composer".
> 
> xesam:Audio.Artist
>   a   :field;
>   :of_type:string;
>   :has_parent DC:Creator;
>   :name   "Artist"@EN;
>   :name   "Kunstner"@DA;
>   :description"Performer featuring in the recording"@EN;
> 
>   :description"Kunster der optræder på optagelsen"@DA.
> 
> 
> END_FILE
> 
> As you can guess the translations are marked with @ after the strings.
> 
> My question is : Will this cause problems or be a major hassle? How
> will it fit into the current translation workflow? 

Currently, the gnome i18n workflow can easily use .xml and .po files.
For other file formats there will be need for quite some extra work.
Thus, if you would like to use your proposed file format, you would need
to update http://svn.gnome.org/viewcvs/intltool/ Of course, contact the
maintainer of intltool first.

AFAIK, if intltool can parse your files, they will fit with the workflow
of GNOME.

Cheers,
Simos

> Cheers,
> Mikkel
> 
> PS: Please don't question the reasons for using Turtle, we already
> went through weeks of flame wars over this :-) Just the opinions or
> comments from an i18n point of view. Besides the choice is not final
> yet.
> 
> [1]: http://wiki.freedesktop.org/wiki/XesamAbout
> [2]: http://www.dajobe.org/2004/01/turtle/ 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

IRC Meeting #2 ([EMAIL PROTECTED]) on Tuesday, 1/Aug/06, 12:00 UTC-GMT/Zulu: Font availability; font licensing; selecting fonts

[Simos Xenitellis]

Dear All,
I would like to announce that there will be an IRC meeting on Tuesday, 1st 
August 2006, to
discuss issues about fonts for free and open-source software.

The agenda includes
1. discussion on availability of free & open-source fonts for different 
scripts/languages. 
2. discussion on free & open-source font licenses; importance to converge to a 
common license.
3. consult users from Asia for the local preference of fonts. 

The meeting takes place on Tuesday, 1st August 2006, at 12:00 UTC (GMT/Zulu).
This is morning for the US, early in the afternoon for Europe and 
afternoon/evening for Asia/Australia.
Visit 
http://www.timeanddate.com/worldclock/fixedtime.html?year=2006&month=8&day=1&hour=12&min=0&sec=0
to view the exact time for your area.

The meeting takes place on IRC, at the Freenode network, on channel ##fonts.
Notice the channel name, it is "##fonts", with two pound signs. Unfortunatelly, 
the channel with one pound sign has already been registered for non-free font 
discussions.

If you have not used IRC before, you can use the IRC client "XChat" 
that is provided with your Linux distribution. You can also install XChat for 
Windows.
XChat is also available from http://www.xchat.org/

For more, please see
http://wiki.freedesktop.org/wiki/Software_2fFonts_2fConfiguration

The discussion logs will be made available after the meeting, at
http://wiki.freedesktop.org/wiki/Software_2fFonts_2fConfiguration

Fonts are very important to distributions, desktop environments (GNOME, KDE, 
etc), 
as well as to individual cross-platform applications. The end-user
would typically blame the application if the fonts do not appear well. 
At the same time, the process of choosing suitable fonts for different 
languages and scripts is complex enough for a single project to handle.

At the same time I would like to announce that there is interest 
to have more regular discussions on IRC on issues pertaining to fonts.
Therefore, if you would like to discuss free and open-source fonts, 
feel free to pop by ##fonts on Freenode.

Feel free to forward this announcement to other relevant lists.

Thanks,
Simos


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

IRC Log (Was: Re: IRC Meeting ([EMAIL PROTECTED]) tomorrow Friday, 14Jul06, 20:00 GMT: Fonts; choosing fonts; fonts.conf; fontconfig)

[Simos Xenitellis]

Dear All,

The IRC session took place yesterday and the IRC log is available at
http://wiki.freedesktop.org/wiki/Software_2fFonts_2fConfiguration

At the end of the page there is a summary that is being built; feel free
to help out summarising the session and extracting actions to do.

There was interest to have more regular font meetings, such as an IRC
channel dedicated to issues related to fonts. We are looking into
getting #fonts on Freenode. If you can help out with this (it's already
registered), it will be appreciated.

Thanks to everyone for taking part,
Simos

Στις 13-07-2006, ημέρα Πεμ, και ώρα 20:49 +0100, ο/η Simos Xenitellis
έγραψε:
> Dear All,
> 
> I would like to announce an IRC meeting that will take place tomorrow
> Friday, 14th July 2006, at 20:00 GMT, at #freedesktop on Freenode (IRC).
> 
> To find the exact local time for your country, see
> http://www.timeanddate.com/worldclock/fixedtime.html?year=2006&month=7&day=14&hour=20&min=0&sec=0
> For example, if you are in Paris, the meeting is on Friday at 10:00pm.
> If you are in Asia/Australia, it will probably be inconvenient. Please
> mail me about it. If there is enough interest (>5 e-mails), we can
> arrange a repeat meeting. Tell me what time is suitable for you. This is
> particularly important for Indic/CJK/etc font issues.
> 
> The expected duration is 1 hour. Based on interest and support, we may
> arrange extra sessions. 
> 
> The agenda includes:
> 1. discussion on basic issues on fonts; font licenses; 
> 2. building a list of 'desirable' FLOSS fonts for each language/script;
> tell us your preference; promote your preference
> 3. build an 'optimal' fonts.conf file (+ suggest
> snippets for fonts.d/); LSB common font repository
> 4. discuss the proposed fontconfig patch for granular font selection,
> http://lists.freedesktop.org/archives/fontconfig/2006-June/002332.html
> 5. discuss on writing a patch for fontconfig to disregard glyphs from
> fonts in a very low level (as if the font did not have those glyphs in
> the first place)
> 
> The webpage of this discussion is at
> http://wiki.freedesktop.org/wiki/Software_2fFonts_2fConfiguration
> 
> The discussion (irclog) will be saved at the above URL as well.
> 
> Extra reading
> 1. Call to test the DejaVu fonts
> http://fedoraproject.org/wiki/Fonts/DejavuFeedbackCall
> 2. The Open Font License (OFL) by SIL International
> http://scripts.sil.org/OFL
> 3. Fonts page on the Freedesktop Wiki
> http://wiki.freedesktop.org/wiki/Software_2fFonts
> 4. OpenFonts page on the Ubuntu Wiki
> https://wiki.ubuntu.com/OpenFonts
> 5. Fonts management
> https://wiki.ubuntu.com/FontManagement
> 6. Font issues across distros
> http://fedoraproject.org/wiki/Fonts/FontMusings
> 7. Enhancing pango/fontconfig to help solve font issues
> http://sourceforge.net/mailarchive/message.php?msg_id=18518811
> 8. re: fontconfig support to exclude glyphs from fonts
> http://lists.freedesktop.org/archives/fontconfig/2006-June/002332.html
> 9. Open source casts new mold for type design (recent font article)
> http://news.com.com/2102-7344_3-6092398.html?tag=st.util.print
> 
> A similar IRC meeting took place last week, on input methods and
> multilingual writing support in Xorg; the discussion is available at
> http://wiki.freedesktop.org/wiki/KeyboardInputDiscussion
> 
> Please forward this announcement where you feel appropriate.
> 
> Hope to see you tomorrow,
> Simos
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

IRC Meeting ([EMAIL PROTECTED]) tomorrow Friday, 14Jul06, 20:00 GMT: Fonts; choosing fonts; fonts.conf; fontconfig

[Simos Xenitellis]

Dear All,

I would like to announce an IRC meeting that will take place tomorrow
Friday, 14th July 2006, at 20:00 GMT, at #freedesktop on Freenode (IRC).

To find the exact local time for your country, see
http://www.timeanddate.com/worldclock/fixedtime.html?year=2006&month=7&day=14&hour=20&min=0&sec=0
For example, if you are in Paris, the meeting is on Friday at 10:00pm.
If you are in Asia/Australia, it will probably be inconvenient. Please
mail me about it. If there is enough interest (>5 e-mails), we can
arrange a repeat meeting. Tell me what time is suitable for you. This is
particularly important for Indic/CJK/etc font issues.

The expected duration is 1 hour. Based on interest and support, we may
arrange extra sessions. 

The agenda includes:
1. discussion on basic issues on fonts; font licenses; 
2. building a list of 'desirable' FLOSS fonts for each language/script;
tell us your preference; promote your preference
3. build an 'optimal' fonts.conf file (+ suggest
snippets for fonts.d/); LSB common font repository
4. discuss the proposed fontconfig patch for granular font selection,
http://lists.freedesktop.org/archives/fontconfig/2006-June/002332.html
5. discuss on writing a patch for fontconfig to disregard glyphs from
fonts in a very low level (as if the font did not have those glyphs in
the first place)

The webpage of this discussion is at
http://wiki.freedesktop.org/wiki/Software_2fFonts_2fConfiguration

The discussion (irclog) will be saved at the above URL as well.

Extra reading
1. Call to test the DejaVu fonts
http://fedoraproject.org/wiki/Fonts/DejavuFeedbackCall
2. The Open Font License (OFL) by SIL International
http://scripts.sil.org/OFL
3. Fonts page on the Freedesktop Wiki
http://wiki.freedesktop.org/wiki/Software_2fFonts
4. OpenFonts page on the Ubuntu Wiki
https://wiki.ubuntu.com/OpenFonts
5. Fonts management
https://wiki.ubuntu.com/FontManagement
6. Font issues across distros
http://fedoraproject.org/wiki/Fonts/FontMusings
7. Enhancing pango/fontconfig to help solve font issues
http://sourceforge.net/mailarchive/message.php?msg_id=18518811
8. re: fontconfig support to exclude glyphs from fonts
http://lists.freedesktop.org/archives/fontconfig/2006-June/002332.html
9. Open source casts new mold for type design (recent font article)
http://news.com.com/2102-7344_3-6092398.html?tag=st.util.print

A similar IRC meeting took place last week, on input methods and
multilingual writing support in Xorg; the discussion is available at
http://wiki.freedesktop.org/wiki/KeyboardInputDiscussion

Please forward this announcement where you feel appropriate.

Hope to see you tomorrow,
Simos


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Flags or not? (Was: Re: Noticed in passing)

[Simos Xenitellis]

Στις 10-07-2006, ημέρα Δευ, και ώρα 11:17 +0100, ο/η Sergey Udaltsov
έγραψε:
> > > Flags !!!   I knew it.
> There will always be a way to allow users to indicate layouts using
> flags (as long as I maintain GNOME xkb indicator at least). It can be
> hidden, non-documented, whatever (so GNOME would not take political
> responsibility) - but I will keep that code. Most of the users have no
> political troubles with flags - while usability-wise, flags still
> remain the best way to distinguish between layouts. The code is
> actually in the core applet - the plugin just provides nice UI for
> downloading flags from sf.net and setting proper gconf flag.
> 
> > Perhaps we should look at how the plugins UI is exposed in the applet.
> To make the situation a bit better I did the following thing:
> - Removed the item from the applet popup menu
> - Created .desktop file for the plugin manager which puts it into
> AdvancedSettings
> I am open to other suggestions. All I am kindly asking is to keep (in
> the darkest UI corner, whatever) this executable accessible for the
> user.

Personally I am against flags being used to indicate the language your
keyboard is set to write.
You can easily get obscure cases, such as which flag to show to type
Spanish in the US or Latin America?
There is the issue of maintainance and creation of new flags. Some flags
are difficult to get right on 16x16 (they are single colour with a tiny
ornament in the middle). Ideally, one would use SVG flags which you
would resize to fit to 16x16. Those who like their panel to be extra big
will get a nice view of the flag.
And there is this issue with the default keyboard layout which is US
English. Currently, the GNOME i18n desktop shows the letters "USA" which
make some people inconvenient. Let alone having the US flag in the new
default GNOME desktop :) That would be fun.

>From the usability point of view, the keyboard indicator should show
what language you can write (not the main country this language is
used). Whether it is US English, British English, International English,
it is English, so it should show "EN", which is the ISO 639 language
code for the language. For other languages, "FR", "ES", "DE", "RU",
"IT", etc.

>From the usability point of view, if the user wants to figure out which
English layout it is, she can put the mouse over the "EN" and get the
full name of the layout (functionality available already).

There are cases where users have two English (or other language) layouts
enabled in the same configuration. You have the issue, *which* "EN" is
active at the moment. The way this is solved currently is by adding an
asterisk, so "USA", "USA*", "USA**", etc. This gives issues with the
width of the real estate of the applet. When you switch between layouts,
the small icons on the panel dance left and right because the width of
one of the applets changes. Also happens when you have "USA" and "GB".
Annoying. What we do? We set a fixed width.
My proposition would be to use the Unicode superscript numbers, ¹²³
instead of asterisks.
Therefore, "EN" if there is only one English active.
If there are more English layouts, "EN¹", "EN²", "EN³".

For those who want, it looks natural to translate the language codes. 

How do we change from country codes to language codes? That is actually
a bit tough. The layout codes come transparently from upstream, Xorg
(xkeyboard-config). This would add some extra work to Sergey and would
rekindle the discussion in the XKB list on whether to use country codes
or language codes. For this to work, there should be a layer (=list)
that translates keyboard layout codes to language codes.

Simos


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: SCIM in GNOME [Was: Noticed in passing]

[Simos Xenitellis]

Hi All,

Just to let you know that the IRC meeting took place as planned.

I would like to thank everyone that took place at the meeting, and
especially Sergey for leading the discussion.

The IRC logs are available at
http://wiki.freedesktop.org/wiki/KeyboardInputDiscussion

At the end of the page there are some comments by Sergey. If you would
like to pass some points (such as issues on the point of view of SCIM),
please add a similar summary.

I think it's useful to go through the log.

There will not be another session for this weekend; sorry for this. 

There will be more work on Keyboard Inputs in a subsequent weekend and
it will be announced here as well.

Cheers,
Simos


On Fri, 2006-07-07 at 17:58 +0200, Christian Rose wrote:
> On 7/7/06, Jeff Waugh <[EMAIL PROTECTED]> wrote:
> > 
> > > I am not sure what Fedora uses for complex input methods. Does it use SCIM
> > > or IIIMF or something else?
> >
> > This appears to be a good opportunity to raise something I spoke to a few
> > people at GUADEC about - integrating more internationalisation features into
> > the GNOME desktop suite, and SCIM in particular. The current SCIM GUI is a
> > HIG-defying mess, and we should be able to get a bigger bang for our i18n
> > buck by doing some sassy integration in the desktop suite, making more i18n
> > users (especially CJK users) kick arse.
> 
> Simos sent this notice to the gnome-i18n list:
> "Hi All,
> There is a meeting scheduled for tomorrow Friday, 07.07.2006, at 19:00
> GMT, on Freenode, channel #xkbconfig.
> 
> Sergey (svu) is organising the meeting to discuss rather technical
> issues about keyboard layout support in GNOME.
> 
> The agenda includes:
>  1. GSwitchit API as GNOME-oriented keyboard services. Including GTK
> widget, gconf configuration, DBUS server etc
> 2. Whether gswitchit should go to separate project or become a real
> (non-virtual) part of some existing one.
> 3. Does it make sense to integrate SCIM with gswitchit?
> 
> Especially if you know anything about SCIM, please join up. The current
> situation is a bit messy with two independent keyboard layout
> subsystems. It appears it would be good to expose our users to a single
> interface by integrating the two.
> 
> Thanks,
> Simos
> Press Relations Assistant
> of Sergey (the #xkbconfig guru)."
> 
> 
> So if you have any input (or suggestions for further discussion),
> please join the discussions.
> 
> 
> Christian
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Noticed in passing

[Simos Xenitellis]

On Fri, 2006-07-07 at 16:43 +0200, Murray Cumming wrote:
> On Fri, 2006-07-07 at 09:43 -0400, Matthias Clasen wrote:
> > While testing FC6 test1 I noticed that the
> > keyboard layout indicator applet has several
> > "interesting" menu items. 
> > 
> > The first one is "Layout view", which seems to
> > be intended to bring up an image of the keyboard
> > that is right in front of me, which would be of
> > somewhat dubious value even if it worked. Unfortunately,
> > it just shows an empty window with Help and Close
> > buttons for me (may just be rawhide breakage, though...)
> 
> I requested this:
> http://bugzilla.gnome.org/show_bug.cgi?id=309717
> 
> People need it because their layout is often _not_ what's right in front
> of them. If it was then we wouldn't need a keyboard layout switcher.

I added a comment to the above report that when you right-click on the
Keyboard Indicator applet, then click on Layout View, you can see the
current layout settings.
This is available in at least GNOME 2.14.

Simos

> > The second one is "Plugins". WTF ? How in the world
> > does a keyboard layout indicator need a plugin system ?!
> > And why go to all the length of adding a plugin framework
> > when there are no plugins after all ? This looks
> > like first-grade overengineering to me.
> > 
> > Matthias
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Noticed in passing

[Simos Xenitellis]

On Fri, 2006-07-07 at 09:56 -0400, JP Rosevear wrote:
> On Fri, 2006-07-07 at 09:43 -0400, Matthias Clasen wrote:
> > While testing FC6 test1 I noticed that the
> > keyboard layout indicator applet has several
> > "interesting" menu items. 
> > 
> > The first one is "Layout view", which seems to
> > be intended to bring up an image of the keyboard
> > that is right in front of me, which would be of
> > somewhat dubious value even if it worked. Unfortunately,
> > it just shows an empty window with Help and Close
> > buttons for me (may just be rawhide breakage, though...)
> 
> We've seen this problem in suse with xgl too:
> https://bugs.freedesktop.org/show_bug.cgi?id=7137
> 
> Not sure if its the same or not.

I think it is a situation of not upgrading to xkeyboard-config,
http://www.freedesktop.org/wiki/Software_2fXKeyboardConfig

AFAIK, xkeyboard-config is not part of the default Xorg yet, so you have
to install separately. There have been discussions for this last year
(during Xorg pre-7.0 but it did not make it).

Simos


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Noticed in passing

[Simos Xenitellis]

On Fri, 2006-07-07 at 09:43 -0400, Matthias Clasen wrote:
> While testing FC6 test1 I noticed that the
> keyboard layout indicator applet has several
> "interesting" menu items. 

Normally you would expect the installer to setup the "proper" menu items
on installation, depending on the locale.
If an end-user wants to setup a new keyboard layout, she would try
something like

> The first one is "Layout view", which seems to
> be intended to bring up an image of the keyboard
> that is right in front of me, which would be of
> somewhat dubious value even if it worked. Unfortunately,
> it just shows an empty window with Help and Close
> buttons for me (may just be rawhide breakage, though...)

The Layout View shows a keyboard where you can press keys and have the
corresponding key on the image highlighted. Helpful if you want to
figure out what keys are available.
You can also view what characters are printed for the current keyboard
layout.
The layout view looks like
http://bugzilla.gnome.org/attachment.cgi?id=68424&action=view

It appears that there is some issue with rawhide.

> The second one is "Plugins". WTF ? How in the world
> does a keyboard layout indicator need a plugin system ?!
> And why go to all the length of adding a plugin framework
> when there are no plugins after all ? This looks
> like first-grade overengineering to me.

I am not sure what functionality the plugins are intended for.

There is a scheduled IRC session on #xkbconfig, today Friday at 19:00
GMT.
See the agenda at
https://sourceforge.net/mailarchive/forum.php?thread_id=19873264&forum_id=43694
Probably the discussion will be repeated during this weekend at a
reasonable time for Asia/Australia.

Apart from the technical details of gswitchit there will be a discussion
about possible integration of the SCIM functionality. The plan is that
if all of these make sense, there will be a need for the usability
people to help out design better the interface of the keyboard indicator
(and Keyboard applet in Control center).

I am not sure what Fedora uses for complex input methods. Does it use
SCIM or IIIMF or something else?


The intended way to use the keyboard indicator is along the lines of
http://www.gnome.gr/writing/

See also 
http://ubuntuguide.org/wiki/Dapper#How_to_add_keyboard_layouts_for_other_languages
and the following 4 answers for more details.

Simos


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: libgswitchit: from virtual module to separate library

[Simos Xenitellis]

On Thu, 2006-07-06 at 20:57 +0100, Sergey Udaltsov wrote:
> I think it would make sense to discuss these things on IRC. So - what
> about tommorrow, 1900GMT on #xkbconfig @ Freenode? Sure everyone is
> invited.

The time should be ok for me (18:00 BST)

Regards,
Simos

> 
> Regards,
> 
> Sergey
> 
> On 7/6/06, Simos Xenitellis <[EMAIL PROTECTED]> wrote:
> > On Wed, 2006-07-05 at 21:42 +0100, Sergey Udaltsov wrote:
> > > Davyd,
> > >
> > > This is a very good question. Since API was always considered as
> > > "internal" (and all its usage was controlled by me) - I never actually
> > > looked at it from the quality side. I slighly improved it for 2.15 -
> > > but I realize it is very far from being nice. So as a part of the
> > > separation process, I would try to do the API cleanup (and I would
> > > appreciate any help/advice/review).
> >
> > On this issue, I am wondering whether it would make sense to bring
> > in the SCIM configuration applet. SCIM allows you to write in
> > a bit more complex scripts (Indic, CJK, etc) and the user experience
> > in distributions (for example, Ubuntu) is not good. You use Alt-Alt to
> > switch between XKB keymaps and Ctrl-Space to switch between SCIM
> > keymaps. There are cases that both can cater the same keyboard layouts.
> > It's a bit messy.
> >
> > The SCIM configuration applet also diverges a lot from the GNOME HIG
> > guidelines.
> >
> > If an API change is to take place, it might be good to capture the
> > requirements of SCIM.
> >
> > I am not sure where the proper place is to discuss this. I would would
> > be happy if you can direct me to the proper place.
> >
> > Cheers,
> > Simos
> >
> > > Thanks,
> > >
> > > Sergey
> > >
> > > On 7/5/06, Davyd Madeley <[EMAIL PROTECTED]> wrote:
> > > > On Wed, 2006-07-05 at 15:53 +0100, Sergey Udaltsov wrote:
> > > >
> > > > > Currently, libgswitchit (not same as libxklavier!) is used as a
> > > > > virtual module in the gnome-control-center and gnome-applets. There is
> > > > > a plot to use it in the gnome-screensaver as well. There are 2
> > > > > options:
> > > > > - Again, use it a virtual module
> > > > > - Finally, create separate module with its own build system, headers
> > > > > and (shared) library (as if GNOME does not have enough libraries).
> > > > >
> > > > > I am considering the second option. Any comments?
> > > >
> > > > The second option makes sense, but what can we do to decrease the amount
> > > > of API churn that is seen throughout the keyboard switching code? It
> > > > always seems to be breaking compatibility. Especially if the number of
> > > > users is getting up to three+ (maybe gdm would like it too?).
> > > >
> > > > --d
> > > >
> > > > --
> > > > Davyd Madeley
> > > >
> > > > http://www.davyd.id.au/
> > > > 08B0 341A 0B9B 08BB 2118  C060 2EDD BB4F 5191 6CDA
> > > >
> > > >
> > > ___
> > > desktop-devel-list mailing list
> > > desktop-devel-list@gnome.org
> > > http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> > >
> >
> >
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: libgswitchit: from virtual module to separate library

[Simos Xenitellis]

On Wed, 2006-07-05 at 21:42 +0100, Sergey Udaltsov wrote:
> Davyd,
> 
> This is a very good question. Since API was always considered as
> "internal" (and all its usage was controlled by me) - I never actually
> looked at it from the quality side. I slighly improved it for 2.15 -
> but I realize it is very far from being nice. So as a part of the
> separation process, I would try to do the API cleanup (and I would
> appreciate any help/advice/review).

On this issue, I am wondering whether it would make sense to bring 
in the SCIM configuration applet. SCIM allows you to write in 
a bit more complex scripts (Indic, CJK, etc) and the user experience
in distributions (for example, Ubuntu) is not good. You use Alt-Alt to
switch between XKB keymaps and Ctrl-Space to switch between SCIM
keymaps. There are cases that both can cater the same keyboard layouts.
It's a bit messy.

The SCIM configuration applet also diverges a lot from the GNOME HIG
guidelines.

If an API change is to take place, it might be good to capture the
requirements of SCIM.

I am not sure where the proper place is to discuss this. I would would
be happy if you can direct me to the proper place.

Cheers,
Simos

> Thanks,
> 
> Sergey
> 
> On 7/5/06, Davyd Madeley <[EMAIL PROTECTED]> wrote:
> > On Wed, 2006-07-05 at 15:53 +0100, Sergey Udaltsov wrote:
> >
> > > Currently, libgswitchit (not same as libxklavier!) is used as a
> > > virtual module in the gnome-control-center and gnome-applets. There is
> > > a plot to use it in the gnome-screensaver as well. There are 2
> > > options:
> > > - Again, use it a virtual module
> > > - Finally, create separate module with its own build system, headers
> > > and (shared) library (as if GNOME does not have enough libraries).
> > >
> > > I am considering the second option. Any comments?
> >
> > The second option makes sense, but what can we do to decrease the amount
> > of API churn that is seen throughout the keyboard switching code? It
> > always seems to be breaking compatibility. Especially if the number of
> > users is getting up to three+ (maybe gdm would like it too?).
> >
> > --d
> >
> > --
> > Davyd Madeley
> >
> > http://www.davyd.id.au/
> > 08B0 341A 0B9B 08BB 2118  C060 2EDD BB4F 5191 6CDA
> >
> >
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
> 

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New external dependency: iso-codes ?

[Simos Xenitellis]

ÎÏÎÏ 07/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÏÎÏÎ ÎÎÎ ÏÏÎ 21:54, Î/Î 
Danilo Åegan ÎÎÏÎÏÎ:
> Hi Simos,
> 
> Today at 22:01, Simos Xenitellis wrote:
> 
> > It looks more canonical to me to make the dependancy to the Translation
> > Project.
> 
> You got it a bit mixed up :)
> 
> Translation Project (TP) is basically for other programs what GTP is
> for Gnome: a translation project.  You cannot "add a dependency" on
> GTP for any software module, because it's not software, it's a group
> of people and some infrastructure :)
> 
> The discussion here was whether to make iso-codes build- and run-time
> dependencies of Gnome software.  That can be done several ways, and
> one is to make it a "soft" dependency (everything would work fine even
> if it's not there, except there might be no translations), or "hard"
> dependency (package won't install if a hard dependency is not
> installed).
> 
> For example, xkeyboard-config translations are a soft dependency of
> Gnome keyboard preferences: you get untranslated layout names if
> xkb-config is not included.

Thanks for the clarification and the part on soft/hard dependencies.

The translators indeed send their work to the Translation Project, so
for the latest Greek version for the iso_639 translation domain, one
would have to look in
http://www.iro.umontreal.ca/translation/teams/PO/el/

However, it's simple to delegate the collection of the latest PO files
to the iso-codes maintainer and interact with him, rather than scanning
ourselves (as GTP) for any latest version.

The iso-codes maintainer is not the highest upstream, but's he is high
enough for the purposes of GNOME.

Simos


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New external dependency: iso-codes ?

[Simos Xenitellis]

ÎÏÎÏ 07/ÎÎÏ/2005, ÎÎÎÏÎ ÎÎÏÏÎÏÎ ÎÎÎ ÏÏÎ 20:15, Î/Î 
Christian Persch
ÎÎÏÎÏÎ:
> Hi,
> 
> I'd like to add a new external dependency to GNOME Desktop: the
> "iso-codes" package. It's available from cvs
> [http://alioth.debian.org/projects/pkg-isocodes/] and tarball
> [http://people.debian.org/~mckinstry/iso-codes-0.45.tar.gz].
> 
> Using this package will remove the duplicated translations of language
> and country names from GNOME programs. Epiphany and Galeon already have
> support for iso-codes (optional dependency atm), and there's a bug with
> patch to make gedit's spell-check using it too
> [http://bugzilla.gnome.org/show_bug.cgi?id=150535].
> 
> If nobody objects, I'm going to go ahead and make it a hard dependency
> for Epiphany, and add the module to the gnome-2.12 jhbuild moduleset.

The ISO codes package is being translated under the Translation Project
(http://www.iro.umontreal.ca/translation/HTML/index.html)
and listed at 
http://www.iro.umontreal.ca/translation/registry.cgi?domain=index
See the iso translation domains in the middle of the page.

The relation between the two (Translation Project and iso-codes) is that
the former is higher upstream. Translators deal with the Translation
Project and regularly the guy from Debian makes a release of the
translations. Is that correct?

Another package from the Translation Project, xkeyboard-config is used
by gswitchit, the keyboard switching tool in GNOME, to provide the names
of the keyboards in the local language. I am not sure if such a
dependancy exists already. 
Sergey (author of gswitchit)?

It looks more canonical to me to make the dependancy to the Translation
Project.

Simos


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list