The Linux engine...

[Richard Gaskin]

Malte Brill wrote:

> Thanks for the feedback so far guys.
...
> I miss Richard a little. He became some sort of a power Linux LC user recently, didn't he? Richard?

I'm here.  I was busy yesterday but flagged your post as one I 
definitely want to respond to, so here goes:

The state of the LiveCode engine on Linux is improved, but not yet on 
par with the performance, robustness, or features available for other 
desktop flavors.

Here are some things you'll notice about using LiveCode on Linux:


- Redraw speed
As Andre noted, under-the-hood operations like parsing text, math, etc. 
seem to perform on par with other platforms, but many things, esp. long 
blocks of text in fields, take noticeably longer to render.


- Menu behavior: opening appearance
Mac is the only platform where menus are implemented as native OS 
objects.  On Win and Linux, menus are implemented as dynamically-created 
stacks, with the engine doing the work we used to have to do in the 
early MetaCard days with creating buttons on stacks for menus.

In most cases this isn't a problem, but if you use any of the dynamic 
window effects settable in Compiz Config that add effects for opening 
windows, you'll see that LiveCode menus open with the same behavior.

I've seen at least one other app that has popup menus which behave this 
way, so LiveCode isn't alone.  But it adds more fuel to the fire for the 
many requests on this list for a re-think on how menus happen in LC.


- Menu behavior: global menu bar (Ubuntu only)
Ubuntu 11.04 introduced the new Unity UI, and with it came a global menu 
bar similar to that on Mac OS.

Menus created using standard routines in Qt or GDK are automatically 
rendered in the global menu bar, but since LC menus are non-standard 
your apps will retain the older appearance, displayed at the top of the 
window.

I've seen a fair number of apps that apparently use their own custom 
menu systems, so on this one LiveCode is definitely not alone, but 
hopefully this can be addressed as part of a menu re-think that could 
benefit Windows as well.


- Video playback
First, as of v4.6.4 (this may have changed with v5.x, I haven't 
checked), the engine's videoClipPlayer default specifies a player that 
hasn't shipped with any major distro in some years (XAnim).  This can be 
set to mplayer or mplayer2, but I've had no luck trying to use VLC 
(anyone else here used that successfully?).

But moreover, videos that play fine in other systems will often render 
with an odd translucence, apparently using black as an alpha channel so 
darker areas become transparent.

Ben tells me the team is aware of both of these issues, and is actively 
working on the transparency for a future release ASAP.


- windowBoundingRect has no effect
Setting the windowBoundingRect on Linux has no effect, which means that 
maximizing a window while you have a toolbar present (such as the one in 
the LC IDE) will cause the window's drag bar to submarine under the toolbar.

With Unity's global menu bar in Ubuntu 11.04 and later this is less of 
an issue, since the window controls for maximized windows are rendered 
in the top panel.  But on all other distros, or even with Ubuntu using 
Gnome Shell or any desktop environment other than Unity, this makes it 
very difficult to manage multi-window layouts.

I've discussed this with one of the Ubuntu engineers at Canonical, and 
he feels it should be possible to set this value as we do for other 
OSes.  But that conversation happened in the middle of a busy 
conference, and I've been unable to track down the necessary APIs to 
make that happen.

For the long term this isn't much of an issue since modern app design is 
increasingly migrating to single-window UIs.  But not every app can be 
implemented as a single window, so some solution will need to be found.



IDE-specific things include:

- Fonts way too small
Peter noted this, and while "set the textSize of stack Home to 14" takes 
care of most of it, oddly enough I've found that the disabled states of 
LC's toolbar buttons are unaffected, even as the enabled states for the 
same controls use the new font size just fine.


- App icon sometimes not displayed
I've found that in most cases the LC app icon is used by the OS, but 
sometimes it isn't, using the generic app icon in instead.  I'll dig 
into the specs at freedesktop.org to try to figure out why this happens, 
but it seems odd that it only happens sometimes but not others.


- App icon behavior in Launcher not normal
In both Ubuntu's Launcher and Gnome Shell's Favorite panel, you can add 
the LC app icon there and it will indeed launch the app, but once 
launched it adds a new icon to the Launcher and the original one doesn't 
reflect that the app is open.

I suspect this has to do with how LC initializes its windows, such that 
they aren't being recognized as associated with that Launcher icon. If I 
can dig up the API to fix this I'll submit it to RunRev.



While the shortcomings noted above are very real issues and should be 
addressed, I should note that the team is aware of most of them, and are 
actively working on some of them right now.

Smaller issues tend to get addressed fairly quickly once they're 
identified.  For example, in the olden days it was common for Linux to 
indicate focus on buttons and list items with a dotted border, but I 
haven't seen that in years and the team recently removed that for v5.5.

While Linux has more than 30 million users, LiveCode engines tend to get 
attention in proportion to interest from LiveCode users.

With Mac, for example, we have a disproportionate amount of effort 
expended for OS-specific features relative to its 10% market share, with 
some glaring holes in Windows support (like still using the MCI 
interface for native media playback) even though that OS has am 87% share.

So I feel the level of effort RunRev puts into their Linux engine is 
admirable in many respects, provided they're able to meet a baseline of 
core competence for deployment on that platform.


The good thing about the Linux engine situation is one of the best 
things about Linux itself:  the community of people who use it.

Until more OEMs come on board with Linux pre-installed (we see new 
machines nearly every quarter but mostly in non-US markets), Linux will 
remain popular only among the subset of the population who would 
consider replacing the OS that came with their computer with something 
they downloaded from the Internet.  It doesn't matter how capable, 
efficient, robust, secure, or simply fun it is; if it's not 
pre-installed its growth potential will remain limited in terms of mass 
markets.

If Microsoft ever gets serious about license enforcement we'll see Linux 
proliferate madly, and in many sectors (EDU in Asia and Latin America, 
governments across the world outside the US, etc.) we're already seeing 
usage far beyond what we see in the US consumer demographic.

But still, overall the Linux audience today is more specialized than the 
gene pool as a whole.

During these middle years in Linux' growth, the audience is largely 
comprised of people who have a true "Can do!" spirit, a desire to learn 
and share what they've learned with their community.

For us LiveCoders, this can mean rolling up our own sleeves to dive in 
and help where we can.

If you find issues with the Linux engine, please log 'em to the RQCC. 
And whenever you open any report there, please vote for it - when a 
report is opened by someone who didn't feel it was worth their own vote, 
it makes the issue look unimportant.

And if you have the time and interest to help track down APIs to solve 
these issues, they'll get resolved that much faster.

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv