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
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
