Simple tool to manage pic

I’ve taken quite a few photos of Grace (and Kelly, of course). However, I find myself spending some time on rotating the photo, so the viewer don’t need to either twist their heads or using their imagination. I also need to resample the photos, as the original size is too big to be transfered.

So I want a software that have:

1. Thumbnail view, so I can easily see which photos need to be rotate.
2. Rotate functions
3. Mass resample.

Currently, I find gThumb is quite handy at this point, but always looking forward to knowing some application that can do the automatic rotation.

langpack management (yum langpack plugin).

After I discussed with Jens, he said that we should start with langpack first. He is right, let’s solve this piece by piece.

The problem we are trying to address

Currently, langpacks are either:

1. binded with main package, like firefox, thunderbird, and other small-to-medium packages with translation files. So you install main package implies you need all the langpacks.
2. split into numerous langpack sub-packages. Such as KDE, OpenOffice and Eclipse. So you install main package implies you only need the English US version. Langpack are to be installed individually.

1) is not good for resource-limit systems, because you have to install all the language packs, even you won’t be using them in the rest of your life. 2) is another extreme, you need to remember to manually install the langpack, or they won’t work as expected. To sum up, current language policy is either all or none.

We offer an additional choice: langpacks are automatically installed only if you need it.

How do we know which languages to be installed

These languages can be specified in /etc/sysconfig/lang-setting/langpack.

Whenever yum is invoked to install a package, if the package has langpacks, the langpack plugin will check against this file and pull out the required langpacks.
Don’t worry about langpack removal, as langpacks depend on the main package and will be removed as well. Simple, no?

How do we get user’s languages preference?

Notting and others mentioned the user preference should be exclusive stored in they home. Yes, I agree that we also need the per-user setting in their home, so they specify what language they want to see by themselves.

But system wide setting file is also essential, unless you want to scan through thousands of users’ preference files to determine what to install.

Another benefit of system wide/user home combination is that the langpack plugin can quickly detected what need to be installed by doing a set difference calculation, i.e. UserPref – SysPref.

Contingency plan

You can turn of the automatic langpack installation by removing the langpack plugin, and start manually installing langpacks.

Browser comparison.

Today I installed Google chrome on my Windows XP box. It’s a HP compaq nx6120, no extra modification except I change to a 100 GB harddisk.
I opened a few web pages that I often visit and compared the memory consumption among Firefox 3.5.3, Opera 10.0.0, and Chrome using the about:memory. I was quite surprise what I saw:

But after a few minute later, it becomes:

It appears that chrome does some optimizing behind the theme.

Up coming I18n package management

Yesterday, Jens and I was discussing about the yum langpack plugin, and a recent bugzilla bug ([Bug 518395] add @input-methods to Package Selection screen). During the discussion, we find out that there are at least following issues to be considered:

1. Aspect of Language Support:
   1. Language pack
   2. Input Method/Keyboard layouts
   3. Fonts
   4. Spell Checking
   5. ….
2. Type of package i18n support
   1. Translation files, such as .mo
   2. Language packs. This may involve naming pattern detection.
   3. None

At first stage, we postpone the technical details of handling internationalized packages, but concentrate on obtaining and storing the users’ i18n preference.

For example, Caius wants a set of fonts that covers all language, as far as possible, an he understands English, Chinese, and Japanese, thus he needs corresponding input methods and spell checking. He prefers to see menus and items in Japanese, so Japanese langpacks are required. He also need an English spell checker

Storing

His preference can be stored as:
/etc/sysconfig/lang-setting/langpack:

ja

/etc/sysconfig/lang-setting/input_method:

ja@anthy zh_HK@cangjie5

/etc/sysconfig/lang-setting/spell_check:

en_US

/etc/sysconfig/lang-setting/font:

*

Usage

Jens’ langpack plugins gets benefit from this approach. The plugin determines whether to add or remove langpacks according to langpacks.

And for anaconda and system-config-language, this approach provide further knobs to tune. For example, IBus will be pulled in as dependency if there is at least one Asian languages in input_methods. Spell checkers and even voice data can be dealt with the similar way.

Fonts are a bit different. By default, we installed a set of fonts that cover languages as much as possible. But on resource-limited systems, system admin can exclude fonts by adding a “-” in front of the languages to be excluded. Or alternatively, just list the language you want. Say, the OLPC to Uganda can be loaded with:
/etc/sysconfig/lang-setting/font:

en sw

User Interface in setting dialog.

Regarding UI, I suggest something like:

Overview	Language Pack	Input Method	Font
	Language Name
	English (US)
	Chinese (HK)
	Japanese (JP)
Language Group↓	Language↓
Language pack	☐	Input method	☐
Fonts	☑	Spell check	☐
Add	Delete	Ok	Cancel

Please forgive my terrible html table drawing skill. Mmm, may be I should use glade to produce a real dialog. 🙂

On top of the “dialog(?)” are pages of GNotebook. Click on other pages for more advance settings. This page is for overall setting.

In overall setting page, we have an active list for showing current active languages, the degree of support can be either listed here or in individual advance setting.

In the middle of setting page, there is a language group pull-down which lists the geographic division of languages, such as Eastern Asia, Middle East,… etc.

The contents language pull-down is narrow down by the language group. Thus a user do not need to scroll through hundreds of languages.

Below the pull-downs are aspects of support checkboxes. They are self-explaining.

On the bottom there are buttons that add/delete the language from/to the active list.
and Ok/Cancel to confirm the modification.

Chen 2.2 (code Grace) is out!

Greeting,

Chen 2.2 (code Grace) is released on 04/09. Here is some of her snapshots. 🙂

On IBus Xkb intergration (3)

Yesterday Caius Chance, Jens Petersen and me discussed my approach.
Petersen raised an interesting question:

What if a user want to learn, say Zhuyin input method, on a French AZERTY keyboard by seeing the software keyboard layout?

Mmm, I did not think of that, though Zhuyin can still work on AZERTY keyboard by changing the layout to us-QWERTY. Nevertheless, it is always nice to have visualized software keyboard.

This let me back to further consider Hutterer’s approach.

Number pad on telephone and computers are a good analog for westerners to understand why CJK input methods are in current shapes. Number pads on phones look like:

1       2(abc)  3(def)
4(ghi)  5(jkl)  5(mno)
7(pqrs) 8(tuv)  9(wxyz)
*       0       #

While number pad on computer keyboards look like:

7(home)  8(↑)    9(PgUp)
4(←)     5       6(→)
1(End)   2(↓)    3(PgDn)
0(Ins)           .(Del)    

If what you need is number, you only need to switch layout among phone, computer, or system default. However, you need hack (i.e. input methods) to input English on top of them.

There are at least following setting combination to type English on number pad:

1. IM: T9, Layout: Phone
2. IM: T9, Layout: Computer
3. IM: T9, Layout: System default
4. IM: MultiTap, Layout: Phone
5. IM: MultiTap, Layout: Computer
6. IM: MultiTap, Layout: System default
7. …

Where

• Layout phone: 3(def) key is always on top right, regardless the mark on the number pad.
• Layout computer: 3(def) key is always on bottom right, regardless the mark on the number pad.
• Layout system default: Location of 3(def) key depends the mark on the number pad.

Peter Hutterer mentioned in the case of mobile phone, symbol ‘3’ is bind to top right key, while we still need to interpret what symbol ‘3’ really means (should it be ‘d’, ‘e’, ‘f’ or just ‘3’) in input method level.

Thus, the question can be reformed as:

Where should we interpret “d e f” to 3?

Currently, I think this can be done in “im-variant” level.
But in this way, software keyboard visualizer need to aware of this, then it is able to show the sensible key layout.