[sldev] New Viewer Shell Proposal

Alissa Sabre alissa_sabre at yahoo.co.jp
Tue Aug 21 19:34:01 PDT 2007


> 2. Use Qt instead of your own system. Will look a lot closer to native,
> and those people work full time on this stuff, so it'll be more
> polished.

More polished than what?

It can't be more polished than Windows native UI, since in Microsoft,
there are thousands of full-time employee are woking on it, and Qt
can't have more engineers than that.  (If you count *skills*, Qt
could...  just joking.  :-)

Seriously, I don't understand why you want Qt.  SL viewer doesn't use
so-called UI compatibility layer.  It interracts through OS's native
APIs.  Qt (or any other compatibility layers) can't be better than
direct use of native APIs.  (Ah, except for Linux; it uses GTK for
framing and SDL for surface grabbing and input events on Linux (and
only on Linux.))

On the other hand, I don't prefer Qt because of the following
I18N-unfriendly features: (My experiences on Qt is limited and may be
outdated, so please correct me if I'm wrong.  Actually, I even didn't
know Qt can coexist with OpenGL!)

* Qt has its own _translation_framework_.  It sounds good, but it
  assumes that an English sentence (or just a short label) is always
  translates to one same stentence in all languages, and it is wrong.
  (See discussions in
  https://lists.secondlife.com/pipermail/sldev/2007-July/003714.html
  and related messages for this point.)  Because it has its own
  mechanism built in, replacing it with other method is not easy.

* Qt sticks on the two-byte Unicode.  It doesn't support surrogate
  pairs.  The developers say its intentional, because they believe
  nobody needs more than two bytes.

* Qt's input method interface is heavily biased with X11/Linux manner.
  It works on Windows and MacOS, but its based on the simulation of
  the X11-style interface on top of Windows/MacOS native APIs, and we
  can only use minimum input method features on non-Linux.

  (This point can be considered as a trade-off, not a problem, since
  at this moment, SL viewer uses SDL on Linux, and SDL provides
  *less*than*minimum* support for input methods.  As a result, SL
  viewer has no possibility to provide reasonable input method support
  as long as it uses SDL.  Switching to Qt will be a good news for
  Chinese/Japanese/Korean-speaking residents on Linux...)

Bottom line: I don't like any framework that is not friendly to
non-English speakers.  SL viewer is poor on handling non-English at
this moment, but it has possibilities in a future because it does all
by itself.  If we choose poor framework, we would be bound with it.

Hope this help constructive discussion.

    Alissa Sabre
--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/



More information about the SLDev mailing list