Opera Nalakuvara, a customized browser for the Taiwanese community — Part 1: planning

By Jedi Lin

Introduction

Nalakuvara is probably the most famous customized Opera package in Taiwan. It is cross-platform, open-sourced, unobtrusive, multi-lingual and fully localized for Taiwanese users. This article focuses on the technical details of planning and managing an Opera customization project, including Opera’s suitability for customization, background analysis and target audience research, naming, guidelines, the toolset I used during the project, initial installation, and working out which files to customize. Future articles in this series will focus in-depth on adding the localization code for the Taiwanese language, and other customizations made to the browser.

screenshot of the Opera Nalakuvara - a web browser for the Taiwanese web community

I am hoping that with this series as a reference, you could easily start-up a brand new customized Opera project, localised to your geograohical area.

The outline of this article is as follows:

Opera: perfect for customization

The Opera desktop browser is an elegant web browser. It supports open web standards strictly, ships with many functions built-in, and still runs fast, even on older computers. Although Opera’s core remains closed-source, it has an open mind: Opera encourages user communities to build their own customized Opera to suit their own needs, as long as people do not break Opera’s End-User License Agreement, ie you can’t modify, translate, reverse engineer, decompile or disassemble Opera’s source code.

As a result, there are many customized Opera versions around the world. Some are semi-officially supported, and some are even becoming official. Opera Ibis, once a community-based customized Opera from China, is now listed as a download on Opera’s official website. Ibis is identical to the international version of Opera, but available only in Simplified Chinese and English interfaces, with some of the default settings modified. The 9.6x-based version of Ibis also ships with a special skin, and has a slightly different rendering system for Simplified Chinese characters. (The rendering system in Ibis 9.6x later merged into Opera’s 10.00 trunk.)

Ibis highlights some special requirements of the Chinese Opera community, such as the ability to render Simplified Chinese characters better, and alternative default searches. Not too surprisingly, users from Taiwan have similar yet different needs (which will be discussed later, in Background Analysis section), hence I created the Opera Nalakuvara project, a customized Opera for Taiwanese users.

Nalakuvara is still young, but it has already attracted more than 5,000 downloads in the first two weeks of its Beta 1 release, with web media sites such as Chinese Engadget and Plurk helping to spread buzz about it. Some local web service providers have also promised to improve their products to be compatible with Nalakuvara.

Nalakuvara has many notable features:

  • Nalakuvara is very open — the whole project is well-documented and reveals almost everything, so you could easily adapt Nalakuvara and fork to create your own project.
  • Nalakuvara is extremely flexible and cross-platform. There are currently nine packages available for various systems including Windows, Linux (Ubuntu, Fedora, and generic Linux), and FreeBSD; there is a package for Mac OS X on the way too.
  • Nalakuvara is exceedingly user-friendly; users can choose if they want to install any of the 3rd party components in Nalakuvara. Nalakuvara also asks for confirmation before deleting existing user profiles (or makes backups on some platforms).
  • It also enables UserJS-related options, only if users choose to install them.
  • Even if Nalakuvara is installed on a non-Traditional Chinese Windows encironment, it still displays and works mostly correctly.

Planning

You should always plan first for any project — think carefully before action! Without planning, a project will lose focus and quickly be forgotten. Make sure your project is well planned, released in a timely manner, well promoted, and therefore noticed and remembered.

Background analysis

To start with, I researched the potential target audience community that Nalakuvara could have. First of all I did some hallway tests, and read some local forums.

A hallway test is a common usability test: you invite a varied selection of people to use your product, and watch their actions and response. I asked several random people using Opera 10.00 to do their daily browsing, and made a record of features they complained about or praised.

A hallway test allows you to observe a wide variety of “average” users, but I also wanted to better understand experienced users and newbies too, therefore, I visited a forum focusing on “Browser” in Ptt BBS, the largest local telnet-based BBS in Taiwan. There are over 100,000 unique users logged in to PTT at any one time, with experienced users and newbies exchanging their knowledge. Just listening in on conversations allowed me to check up on the most frequently requested browser features.

From my research, I learned that users from Taiwan would like to:

  • Change Opera’s UI font to MingLiU (the default Traditional Chinese font from the Traditional Chinese version of Windows) rather than SimSun (the default Simplified Chinese font from the Simplified Chinese version of Windows)
  • Use mouse gestures
  • Use drag and drop
  • Open new tabs in the background by default
  • Avoid using Chinese URLs
  • Search strings directly in the location (URL) bar
  • Use Gmail, Ymail and Hotmail
  • Search with Google Taiwan and Yahoo! Taiwan, and a handful of other popular search engines
  • Use dictionaries
  • Block pop-up advertisements
  • Convert Simplified Chinese characters within a web page to Traditional Chinese characters
  • Render web pages with IE’s rendering engine (Trident), so they can use ActiveX or view IE-only web pages. This is to be done in a special Opera tab (called the “IE Tab”), without opening IE
  • Connect to BBS sites via the telnet:// protocol, within the browser
  • Use popular Firefox Extensions or have equivalents provided

Luckily, most of these requested functions are built in to Opera and you just need to enable them; others are doable using UserJS. It didn’t seem too bad at this point.

After doing the research, I prepared for the first test run. I grabbed a portable Opera@USB 10.00 build, enabled and tweaked some settings (see the Dive Into Opera section), and repeated the hallway test! People liked this browser version more than the default presented to them in the first hallway tests. With this result, I knew this project would be worthwhile, so I continued.

Naming the project

The next step was to pack up a beta version and make it available to the public. But wait! I bumped into another hurdle — I needed a name for my project. A good name makes invisible things visible, abstract ideas concrete and memorable, communication focused. With a good name, people know what others are talking about.

Before I named Nalakuvara, I started thinking of Ibis, the Vermillion Bird of the South, one of the Four Symbols of the Chinese constellations an elegant and noble red bird both in appearance and behavior. Ibis is therefore a great name for a Chinese customized Opera project. “So what would be a good name for a Taiwanese customized Opera project?” I asked myself.

One night I talked to one of my friends, and he suggested that I choose from some Deity names out of Taiwanese traditional religion. Soon, Nalakuvara jumped into my mind. Nalakuvara, or Nezha, is a deity in sanskrit sutra. Taiwanese people adapted this deity into our own religion system, just like we adopted numerous different cultures and technologies. In Taiwanese folklore, Nalakuvara is a vigorous and dexterous deity. He has many talismans, including Wind-Fire-Wheel, and he runs faster than others. The base color of Nalakuvara is also red. So the choice was made.

When naming your project, please remember that it is impossible to satisfy all users. No matter how much the majority likes your name, there will always be someone who doesn’t like it. Don’t agonise over it too much — as long as it works and most people like it, carry on, and let the project itself do the talking.

Nalakuvara beta 1 was well received, but there were definitely improvements to make — overall usability, bug fixes, adding features. I needed to come up with some guidelines to keep me on track.

Guidelines

Despite involving a lot of work on my part, Nalakuvara is still a comparitively tiny project, so I haven’t developed full specs, release roadmaps and product release cycles. However, to keep Nalakuvara moving in the right direction, I needed to create some simple guidelines to follow to keep things consistent:

  • Do no harm first, do something useful second
  • Conserve the Opera look and feel
  • Make it as cross-platform as possible
  • Use as few third party components as possible
  • In case a 3rd party component is unavoidable, at least let users to make the final decision.

It is critical to write down guidelines early on in a project. Anytime a dispute occurs — either between members of the development team, or later on between you and your community — it is easy to work out what the answer is by consulting the guidelines.

I used Nalakuvara’s guidelines to answer several common queries about how it fits into various communities:

  • Nalakuvara may not modify the official Opera installation package
  • Nalakuvara may not introduce security flaws
  • Nalakuvara may not use Add-On applications such as eDown (URL no longer active) and oGet
  • Nalakuvara may alter default menus and toolbars to provide additional features
  • Nalakuvara may use UserJS to provide additional features
  • Nalakuvara may not use UserJS to alters web page rendering too much (it must still behave like Opera)
  • Nalakuvara should enable UserJS options only if the relevant scripts are installed
  • Nalakuvara should allow users to select their install location on the hard drive when possible
  • Nalakuvara should allow users to choose what third party components to install
  • Nalakuvara should allow users to override default setting

So far Nalakuvara almost meets all these goals, with the “IE Tab” feature being the only exception; it works only on the Windows platform, and a 3rd party Plug-In is required.

Tools

This section details the tools I used when developing Nalakuvara.

Version control

Version control is obviously very important when developing any sizeable software project — everyone makes mistakes. The most popular version control systems currently seem to be Subversion/svk, Perforce and git. For this project I choose Perforce, because:

  • I have a number of years of experience with it already
  • Perforce provides free licensing for Open Source development, and two-users with five-client-workspaces without a license for non-commercial usage
  • Perforce is suitable for wide range of situations, from simple single developer projects to huge companies like Google (that’s right, Google uses customized Perforce);
  • It is cross-platform, with native binaries on several operating systems
  • It works great with both command-line and GUI
  • Perforce does not leave .svn directories everywhere (which Subversion does).

Of course, you do not have to use Perforce. But any version control system is at least 1,000 times better than none! In my case, all my work — including writing these articles — gets committed to my Perforce server.

When working with version control systems, you should always check out files before editing and check in files after daily work or bug fixes, and write logs when committing. I made hundreds of commits in the first two weeks of developing Nalakuvara. Without commit logs, it is impossible to target the right version to work with.

scripting

In Nalakuvara, I have not altered the original Opera installer. All changes are applied via script. I had several considerations when choosing a scripting language to work with:

  • It should be natively supported by operating systems, or compilable to a native binary so that users will not have to install additional runtime environments
  • It should be consistent with the original Opera installers on different operating systems so that users will have a better experience during installation or patching
  • It should have GUI or command-line interfaces available on different operating systems
  • It should be able to do specific tasks, such as reading/writing .ini files or Windows registry tasks

Opera supports many different operating systems. On Windows, the Opera installer is GUI-based, and allows users to choose install paths and other options. On Linux, Opera packages work with different package management systems like RPM, and are also available as a tarball, with minimal or no install options. On FreeBSD, most users install Opera via ports. Mac OS X is a totally different story again (I won’t mention Mac in these articles much as I don't have much experience with that environment.)

I choose AutoHotKey for Windows tasks because:

  • AutoHotKey is a free and open-source
  • The syntax is simple and easy, including GUI creation
  • It can do Windows-specific tasks
  • It can be compiled to Windows standalone executables .exe, and de-compiled back to .ahk source scripts

I used BASH shell scripts for Linux/FreeBSD tasks because:

  • BASH is free and open-source
  • It is available across all Linux/BSD distributions, and is the default shell in some
  • It can do Linux/FreeBSD-specific taskss.

For the planned Nalakuvara Mac OS X version, I am considering Automator for scripting tasks because:

  • Automator is part of Mac OS X
  • It deals well with GUIs
  • It can do Mac-specific tasks

You could also do jobs from scratch using lower level languages, but using higher-level tailored languages keeps release sizes smaller, and will prove easier, both for you in the first place, and for others that want to make modifications at a later date.

Virtual machines

Virtual machines can save you a lot of time setting up test environments. You can have many “guest” systems on a single “host” system, and many virtual machines give you the ability to take snapshots of current system states so you can easily revert to a clean state, If something goes wrong.

I used VMware Workstation, but if you are looking for some free alternatives, try these:

For testing I am running Windows XP Professional with SP3, Ubuntu 9.04 Desktop, and Fedora 11 Desktop, all in my VMware Workstation on a tiny laptop. Too bad it is impossible to run Snow Leopard guest in the same fashion (I am using the x86 version of Windows XP as host, and Mac OSX is a x64 OS, so is incompatible)

Diving into Opera

The playground is ready. This is where the fun begins.

Installation and initial phase

Let us take a closer look at what happens during Opera’s installation and initial phase. On Windows, the Opera installer extracts and runs an MSI installer. During the installation, users can choose where to install Opera, and whether to create shortcut icons on Desktop, Quick Launch Bar, or Start Menu. The MSI Installer language is based on the Windows system environment. By default, Opera will be installed at %PROGRAMFILES%\Opera\ and the multiple users support is enabled.

If you are looking to customize the Opera 10.50 Labs pre-alpha snapshot, the default installation location is %PROGRAMFILES%\Opera 10.50 Labs\.

If this is the first installation of Opera, for now, all Opera-related files are in the Opera install path. The first time Opera is launched, several files are copied from Opera’s install path to %APPDATA%\Opera\ and %USERPROFILE%\Local Settings\Application Data\Opera\. I refer to this as Opera’s “initial phase.” If another Opera has already been installed on this system before, user settings and files usually remain at %APPDATA% and %USERPROFILE%, and Opera does not overwrite those files. The initial phase might happen again, at anytime you launch Opera with user files missing (in the event of crash, or if someone has deleted them for whatever reason).

The best time to interfere with Opera is after its (whole new) installation and before its first run. Just touch files in Opera’s install path and everything should work just as you imagine. This also works with a multiple user instll — all users get the same improved setting, and are free to tweak it themselves too. If you interfere after Opera’s initial phase, you might have to delete all user profiles and settings so that Opera will run its initial phase again, or carefully alter files in Opera’s install path, ie %APPDATA%, and %USERPROFILE% (if you are not careful, altering these files can cause problems with other applications or even the whole system, so it is not recommended).

On Linux, things are different. There are three types of Opera package on Linux:

  • Deb package (.deb) for Ubuntu and Debian
  • RPM package (.rpm) for Fedora, Mandriva, RedHat and SuSE
  • Tarball (.tar.gz) for generic Linux.

The RPM and Deb packages require almost no user interaction to install Opera. They put application binaries into /usr/share/opera, libraries into /usr/lib/opera, and two default preference setting files — operaprefs_default.ini and operaprefs_fixed.ini — into /etc. Tarball does the same, except that it will prompt users for every path to install files, with the same default paths as RPM and Deb packages. Later during the initial phase, Opera puts (copies or creates) user files and settings in ~/.opera.

Again, the best opportunity to interfere is just after the first fresh install. If you miss this point you will have to deal with files in /usr/share/opera, /etc, and ~/.opera.

On FreeBSD, things are almost the same as with Linux, except the application binary is in /usr/local/share/opera rather than /usr/share/opera, and /usr/local/lib/opera rather than /usr/lib/opera.

Silent installation

You don’t want to force users to go through all this scary config stuff, therefore I made the Nalakuvara package automatically install Opera for users.

Windows installation process

On Windows, this is done by appending a /s variable to Opera’s original installer on the command-line, to specify a silent install. Furthermore, we can also append a /V"/passive FOO=BAR" variable to pass the variable to the extracted MSI installer. Multiple variables are allowed, delimited by a single space. The variables that can be passed include:

  • CREATE_DESKTOP_ICON: Create shortcut icon on Desktop if value is 1, not if 0
  • CREATE_QUICKLAUNCH_ICON: Create shortcut icon on Quick Launch Bar if value is 1, not if 0
  • CREATE_STARTMENU_ICONS: Create shortcut icon on Start Menu if value is 1, not if 0
  • LAUNCH_OPERA_ON_FINISH: Launch Opera on installation finish if value is 1, not if 0
  • SET_DEFAULT_BROWSER: Register Opera as system's default web browser if value is 1, not if 0
  • MULTI_USER_SETTING: Enable multiple user setting support if value is 1, not if 0
  • INSTALLER_LANGUAGE: specify UI language of MSI installer with language code (ie zh-tw means Traditional Chinese, and so on);
  • INSTALLDIR: Specify where to install Opera.

Please note that since multiple variables are delimited by a single space, you have to avoid using space in the value of the INSTALLDIR variable, so you can’t use path names such as C:\Program Files\Opera here. The solution is to use 8.3 format short path names, such as C:\PROGRA~1\Opera. By default, the Opera installer will create those three shortcut icons (on Desktop, Quick Launch Bar, and Start menu), enable multiple user setting support, install Opera at %PROGRAMFILES%\Opera, and launch Opera on finish. After this you can perform a default install without user interaction by executing:

Opera_1000_int_Setup.exe /s /V"/passive CREATE_DESKTOP_ICON=1 CREATE_QUICKLAUNCH_ICON=1 CREATE_STARTMENU_ICONS=1 LAUNCH_OPERA_ON_FINISH=1 MULTI_USER_SETTING=1"

But we do not want Opera launched on finish. So let us change LAUNCH_OPERA_ON_FINISH to 0:

Opera_1000_int_Setup.exe /s /V"/passive CREATE_DESKTOP_ICON=1 CREATE_QUICKLAUNCH_ICON=1 CREATE_STARTMENU_ICONS=1 LAUNCH_OPERA_ON_FINISH=0 MULTI_USER_SETTING=1"

What if users want to specify Opera’s install path? In that case, we need to know the 8.3 version of the path name, which is almost impossible to predict. The solution is quite simple: just create the target directory first then query its 8.3 short path name. Here are some sample codes in Nalakuvara’s AutoHotKey script to do so:

FileSelectFolder, OperaInstallPath, ::{20d04fe0-3aea-1069-a2d8-08002b30309d}, 1, Please choose the location you would like to install Opera. Press `"Cancel`" to apply default vaule %ProgramFiles%\Opera
Loop, %OperaInstallPath%, 2, 0
OperaInstallPathShort = %A_LoopFileShortPath%
RunWait, Opera_1000_int_Setup.exe /s /V"/passive CREATE_DESKTOP_ICON=1 CREATE_QUICKLAUNCH_ICON=1 CREATE_STARTMENU_ICONS=1 LAUNCH_OPERA_ON_FINISH=0 MULTI_USER_SETTING=1 INSTALLDIR=%OperaInstallPathShort%"

First I use FileSelectFolder to ask users to specify a folder to install Opera into. The 2nd option value, ::{20d04fe0-3aea-1069-a2d8-08002b30309d}, is a CLSID (Windows Class Identifiers, a list is available in AutoHotKey's documentation) folder name for My Computer, which is the file chooser starting location. The 3rd option value, 1, turns on a folder creation button. Users have to either select an already-existing folder or create a new folder before selecting it. Either way, the folder will now exist, and its long path name is stored in the %OperaInstallPath% variable.

Next I use Loop to get the 8.3 short path name via the %A_LoopFileShortPath% variable, stored in this context as %OperaInstallPathShort%. It is possible to invoke Opera’s silent installation with this variable; also note that the 2nd option value — 2 — limits Loop to retrieving only folders, and not files. The 3rd option value — 0 — disables recursive searching.

What if users have already installed Opera, previous to installing Nalakuvara? It is a little complicated to determine whether Opera is installed, if so, and where it is located, but I worked out a way. First I check the Windows registry — if Opera is installed, there should be something at HKLM\SOFTWARE\Classes\Opera.HTML\shell\open\command. We can use AutoHotKey’s RegRead to read its default value and store it as a variable, like so:

RegRead, OperaInstallPathReg, HKLM, SOFTWARE\Classes\Opera.HTML\shell\open\command

If Opera is installed, the %OperaInstallPathReg% should look something like this:

"C:\Program Files\Opera\opera.exe" "%1"

We only need the path part of this variable, so it is extracted using a simple regular expression, and a check performed with AutoHotKey’s IfExist function:

OperaInstallPath := RegExReplace(OperaInstallPathReg, ".(.:.+)\\[Oo]pera\.exe.+$", "$1")
IfExist, %OperaInstallPath%

However, it’s not that simple. Even if %OperaInstallPathReg% is null, which means there is nothing at HKLM\SOFTWARE\Classes\Opera.HTML\shell\open\command, users might still have installed Opera but then later uninstalled it, which may leave something behind in the user profile. We therefore need to check the following paths as well:

IfExist, %APPDATA%\Opera

and

IfExist, %USERPROFILE%\Local Settings\Application Data\Opera

If any of the three paths mentioned above exist on the system, it means that Opera has been installed at some point. It is a good idea at this point to remove the already-existing legacy files before you continue with the installation process, or patch them — Nalakuvara does this, but it gives the user a warning in case they don’t want to carry on with this.

What if users have previously installed Opera, and it is currently running? Don’t forget to close all existing Opera processes before continuing — this can be done in an AutoHotKey script like so:

Process, Close, opera.exe

The actual code used in Nalakuvara’s script is much complicated, and there are other details to care about. What if users press “Cancel” while selecting Opera install path? What if users select a file rather than a folder? Check and re-check, prepare defaults and fallbacks, and make your scripts bullet proof.

Linux installation procedure

So that covers Windows, but what about Linux?

Debian packages (.deb) invoke the gdebi-gtk package manager on Ubuntu’s GUI; alterntively you can also install .deb packages using dpkg on the command-line:

dpkg -i opera_10.00.deb

However, dpkg does not install all the necessary dependencies for you. In order to do so, you have to use the APT package manager’s apt-get command:

apt-get -f -y install

RPM packages invoke the gnome-packagekit package manager on Fedora’s GUI. Again, you could install RPM packages using rpm on the command-line:

rpm -i --force opera-10.00.rpm

Luckily rpm deals with dependencies, so you do not have to do it manually.

If you fetch a tarball for generic Linux, just install it in the usual way:

tar -xzf opera-10.00.tar.gz
cd opera-10.00
./install.sh

This sounds great, but is it really that simple? No. Let’s work through the fiddly bits.

The main problem here is that your installer needs to have root permission to install packages. One way to achieve this is to ask users to enter the su command as root to run the script; another is to ask users to install and setup sudo before the installation starts. I prefer using sudo rather than su for its security.

Ubuntu rather conveniently has sudo installed by default, and you can install and setup sudo on Linux destributions using the APT package manager (such as Fedora) with these commands:

su root
apt-get install sudo
visudo

You can add sudo to distros using the Easy Urpmi package manager (for example Mandriva) with these commands:

su root
urpmi sudo
visudo

The manual way to do install sudo is to fetch the source from http://www.sudo.ws/ and then compile it (although to do this, you have to visudo into sudoers.

FreeBSD installation procedure

The FreeBSD way to do all this is to work with ports:

cd /usr/ports/www/opera
sudo make clean install

If sudo is not usable yet on your FreeBSD installation, do this first:

su root
cd /usr/ports/security/sudo
make clean install
visudo

On Linux or FreeBSD, you also need to remember to close all current Opera process before doing anything else:

killall opera

File location and priority

Once we have got to the stage where Opera is installed but the initial phase is not yet triggered, what files should we touch then? You might find the Files Used by Opera for Windows and the Files Used by Opera for Linux, FreeBSD and Solaris documents quite useful but a little outdated. To cut a long story short, here are our primary targets:

  • operaprefs.ini: Stored program settings
  • search.ini: Default settings for the search engines available in Opera
  • bookmarks.adr: Default bookmarks file
  • webmailproviders.ini: Default settings for the web mail providers available in Opera
  • fastforward.ini: Defines what activates the Fast Forward button
  • standard_menu.ini: Opera standard menu configuration
  • standard_toolbar.ini: Opera standard toolbar configuration

You might have already noticed that some files that have multiple instances on your system. Which one should you use, in these situations? The Configuration Priority Scheme section from Opera’s System Administrator’s Handbook gives us a clue, but this document is not very detailed. After studying Ibis and doing some experiments, I finally figured out the actual priority order:

  • operaprefs.ini:
    1. %SYSTEMROOT%\SYSTEM32\operaprefs_fixed.ini
    2. %APPDATA%\Opera\OPERA_DIR_NAME\operaprefs.ini
    3. %USERPROFILE%\Local Settings\Application Data\Opera\OPERA_DIR_NAME\custom\defaults\operaprefs.ini
    4. OPERA_INSTALL_PATH\custom\defaults\operaprefs.ini
    5. OPERA_INSTALL_PATH\defaults\operaprefs.ini
    6. OPERA_INSTALL_PATH\operaprefs_default.ini
  • search.ini:
    1. %APPDATA%\Opera\OPERA_DIR_NAME\search.ini
    2. OPERA_INSTALL_PATH\locale\LANGUAGE_CODE\search.ini
    3. OPERA_INSTALL_PATH\defaults\search.ini
  • bookmarks.adr:
    1. %APPDATA%\Opera\OPERA_DIR_NAME\bookmarks.adr
    2. OPERA_INSTALL_PATH\locale\LANGUAGE_CODE\bookmarks.adr
    3. OPERA_INSTALL_PATH\defaults\bookmarks.adr
  • webmailproviders.ini:
    1. OPERA_INSTALL_PATH\defaults\webmailproviders.ini
  • fastforward.ini:
    1. %USERPROFILE%\Local Settings\Application Data\Opera\OPERA_DIR_NAME\custom\defaults\fastforward.ini
    2. OPERA_INSTALL_PATH\custom\defaults\fastforward.ini
    3. OPERA_INSTALL_PATH\defaults\fastforward.ini
  • standard_menu.ini:
    1. %APPDATA%\Opera\OPERA_DIR_NAME\menu\standard_menu.ini
    2. OPERA_INSTALL_PATH\ui\standard_menu.ini
  • standard_toolbar.ini:
    1. %APPDATA%\Opera\OPERA_DIR_NAME\toolbar\standard_toolbar.ini
    2. OPERA_INSTALL_PATH\ui\standard_toolbar.ini

Allow me to explain some details:

  • OPERA_INSTALL_PATH: This is where you install Opera, %PROGRAMFILES%\Opera by default
  • OPERA_DIR_NAME: The final part of OPERA_INSTALL_PATH, Opera by default
  • LANGUAGE_CODE: The UI language that Opera is currently running with; zh-tw for Traditional Chinese, zh-cn for Simplified Chinese, en for English, etc.
  • %USERPROFILE%\Local Settings\Application Data\Opera\OPERA_DIR_NAME\custom\defaults\*: This is copied from OPERA_INSTALL_PATH\custom\defaults\* during the initial phase
  • %PROGRAMFILES%: A Windows environment variable, usually C:\Program Files
  • %APPDATA%: A Windows environment variable, usually %USERPROFILE%\Application Data
  • %USERPROFILE%: A Windows environment variable, usually C:\Documents and Settings\USER_NAME, where USER_NAME is the Windows user name of the current user
  • %SYSTEMROOT%: A Windows environment variable, usually C:\WINDOWS

standard_menu.ini and standard_toolbar.ini will not be overthrown by higher priority files. They will appear together and allow users to switch between them.

Any setting specific in higher priority files overthrows that in lower priority files. For example, if one specify not to use Mouse Gesture in %SYSTEMROOT%\SYSTEM32\operaprefs_fixed.ini, average users who have no privilege to modify system files have no way to enable Mouse Gesture; on the other hand, if one specify not to use Mouse Gesture in OPERA_INSTALL_PATH\operaprefs_default.ini, any average user can still enable it. This kind of priority scheme is quite handy for system administrators to make sure that users will not run into troubles or make security flaw.

If you are looking to customize the Opera 10.50 Labs pre-alpha snapshot, there will be an operaprefs_default.ini file, as described above, which specifies the UI language to English. You may need to edit or delete this file before Opera’s initial phase to get customization to work.

It is quite tricky and complicated to decide which priority level of files to make the customizations to. Customizing files with a high priority will cause users to be unable to change their own preferences, which would be really frustrating. Customizing files with a low priority might result in things not working properly, as your changes could be easily overthrown by other files with higher priority. In the end I decided to make changes to the locale-based files if possible, as it makes a lot of sense to deliver different tweaks to users in different locales. For files that are not locale-based, the best choice will be OPERA_INSTALL_PATH\custom\defaults\*, because this keeps installed files as intact as possible. I do not touch system files (ie, those in %SYSTEMROOT%) so that system administrators can do their job without unexpected troubles.

The files I customized on Windows are as follows:

  • OPERA_INSTALL_PATH\custom\defaults\operaprefs.ini
  • OPERA_INSTALL_PATH\locale\zh-tw\search.ini
  • OPERA_INSTALL_PATH\locale\zh-cn\search.ini
  • OPERA_INSTALL_PATH\locale\en\search.ini
  • OPERA_INSTALL_PATH\locale\zh-tw\bookmarks.adr
  • OPERA_INSTALL_PATH\locale\zh-cn\bookmarks.adr
  • OPERA_INSTALL_PATH\locale\en\bookmarks.adr
  • OPERA_INSTALL_PATH\defaults\webmailproviders.ini
  • OPERA_INSTALL_PATH\custom\defaults\fastforward.ini
  • OPERA_INSTALL_PATH\ui\standard_menu.ini
  • OPERA_INSTALL_PATH\ui\standard_toolbar.ini

Opera on Linux is basically the same, except operaprefs_fixed.ini and operaprefs_default.ini are both located at /etc (on FreeBSD, /usr/local/etc).

Summary

So concludes the first part of my explanation of how I created the Nalakuvara Opera browser for the Taiwanese community. I have covered Opera’s suitability for customization, background analysis and target audience research, naming, guidelines, the toolset I used during the project, initial installation, and working out which files to customize. In the next article I will start to discuss making the customizations in depth.

This article is licensed under a Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.

Comments

The forum archive of this article is still available on My Opera.

No new comments accepted.