Showing posts with label SWT. Show all posts
Showing posts with label SWT. Show all posts

Tuesday, January 23, 2007

Mozilla Arabic Text Rendering with IceApe

Debian testing package now upgrades mozilla-browser to IceApe (renamed version of SeaMonkey due to branding reasons). IceApe seems not to have the traditional problem of Mozilla Arabic+diacritics text rendering. Zekr just looks fine on this Mozilla. See a screenshot.


After installation of IceApe, your MOZILLA_FIVE_HOME shoud be updated to usr/lib/iceape.

Special thanks to Johan.

Saturday, December 23, 2006

Zekr 0.5.0 beta 1 released

Zekr 0.5.0 beta 1 is out.
This release brings a very useful feature: Bookmarking.
There is a new bookmarks menu, plus a bookmark manager (with drag and drop feature ;)).

More features:
  • Printing is enhanced for this release, and Zekr uses different style sheet for printing. Just try printing from Quran/translation view or search view.
  • Current page search also is now much better. You can navigate through the current page search using buttons on search bar.
  • Goto random aya menu item added under view menu.
Download it from here.

Here are some screen shots from the new release.

A sample screenshot of bookmarks configuration form

A sample Zekr printed document

Sunday, December 17, 2006

SWT Class Hierarchy: A Criticism

From time to time, I find something odd with SWT class hierarchy, which causes me to code more. The only explanation I could tell to myself is that SWT is trying to have its API as easy as possible. But this easy-thinking could be sometimes really frustrating.

I express here 4 examples:
  1. Combo and CCombo are two classes with rather same interface (say ICombo), but in fact there is no common interface defined in SWT. Here is a case that happened to me; I had a number of (big) combo boxes in a SWT application, which worked fine in Windows. When I wanted to run the application on Linux, since setVisibleItemCount(int) is not implemented on GTK (actually not possible due to the way GTK combos are implemented: either a list+button or menu+button), combos covered the whole screen. If there was a common ICombo interface, I could easily change all the Linux combos to CCombo (which supports that method).
  2. setText()/getText() is a very common method among widgets, which is not forced by any interface. Suppose a case that you want to implement a number of different table editors (a CCombo and a Text as an example), with a common listener. If there was an interface for widgets (like IWidget), you could then use that to handle all the table columns regardless of column number.
  3. Button is another example. Why should checkbox, radio button, and normal button use the same class, and for example getSelection doesn't work for button? Neither SRP, nor LSP are held here.
  4. There would be fine to have a simple (either without any method) interface for layout data classes. setLayoutData(Object) would better to accept a special interface, rathe bare Object :).