After over two months of work since 0.5.0 by a handful of developers, there's finally a new release of Lightspark, the (other) open source Flash player. Unlike Gnash, Lightspark supports the AVM2 virtual machine and the newest versions of SWF files, while falling back to Gnash when it encounters SWF8 or earlier content.

News for users

For users, the most visible change is that YouTube is working again - their player keeps getting updated and sometimes it introduces Flash APIs or VM opcodes which are not fully implemented in Lightspark, resulting in breakage.

Flowplayer had been made to work in this cycle.

EGL/GLES2 based rendering has been added so it can run at reasonable speeds on ARM hardware where there is generally no support for hardware accelerated desktop OpenGL.

Less crashes due to the many small and large fixes added.

Changelog for 0.5.1

* Misc fixes to better support YouTube, Vimeo, Flowplayer
* VM correctness improvements
* Support for AS templates
* Dropped half-finished AVM1 support
* Support for EGL/GLES2 rendering
* Support for loading external JPEGs
* Better text handling(e.g. coloring)
* Improved test runner, support for the Tamarin testsuite
* Various API fixes for bugs uncovered by the testsuite
* Dropped mozilla dependency, use internal NPAPI headers
* Added LIGHTSPARK_PLUGIN_LOGLEVEL environment variable to control the log level of the browser

News for the project

Alessandro, the main author and original maintainer of the project is taking a break for a few months, so most development and project management in this cycle has been done by the existing contributors.

The Lightspark team is planning to release new versions monthly from now on, to get the fixes out sooner.

We also plan to move away from the sourceforge.net homepage and wiki, and manage the project using only two instead of three hosting services :)

* github for code, wiki and developer related issues

* launchpad for user bugtracker, mailing list, release tarballs and Ubuntu PPAs

Download

The release is already available in Debian Sid and Ubuntu Oneiric and there are daily builds available in the team's PPA for Ubuntu Natty and Oneiric. The upstream code is progressing rapidly and does not really add regressions so using these daily packages is pretty safe and also helps a lot with testing.

The release tarball is on Launchpad for other distro packagers or people building from source...

https://launchpad.net/lightspark/0.5.1

...although for the latter category I'd suggest to follow the project on github :)

https://github.com/lightspark/lightspark
Posted by
Labels: en lightspark ubuntu
4

View comments

  1. What percentages of the Flash API and VM opcodes does Lightspark cover?

    ReplyDelete

  2. There's a script in the source tree that produces such an output from the sources and Adobe's offline version of the API reference docs.

    Looks like about 5% of the API. Not a good metric probably, as many of those are rarely needed, but there is still a lot to cover until major sites work.
    http://startx.ro/~jani/lightspark_coverage.txt

    We should probably have such an output linked from the main website - once it is decided which the main website is :)

    AVM2 Opcodes are mostly implemented with a few exceptions which too are rarely used - I only saw instanceof missing today.

    ReplyDelete

  3. Year ago someone asked about vdpau support and it has been said that this isn't difficult to achieve so maybe in future. Now I'm asking about vdpau one more time ;) Is there going to be a vdpau support in lightspark in near future?
    Adobe Flash support it, but it is so unstable that it sometimes crashes even Xorg

    ReplyDelete

  4. @skoruppa, good sir, please file a bug on the project in Launchpad as it seems something to at least look into in the future. Thanks

    ReplyDelete

  1. If most cryptographers and one prominent NSA whistle-blower are to be believed, Signal by Open Whisper Systems - branded TextSecure on Android before it recently got merged with RedPhone  - is the most secure traditional messaging app in use today - that is, not counting those that require Tor, the Bitcoin blockchain or other tech out of the reach of regular users.

    I am pleased to say that a TextSecure compatible client for the Ubuntu phone has been in the store for a while, and today it is stable enough to be used regularly. The basics are all working - end-to-end encrypted texts and group chats, photo, audio, video and contact attachments.

    Note that this is not a replacement for the standard messaging app as it does not send or handle SMS.

    On first run you will be prompted for your phone number, will need to manually confirm the received SMS verification code, then asked to import your address book contacts to see which of them is already using Signal.

    There are still enough bugs lurking and major features missing - encrypted message store, push notifications that require server side work, support for multiple devices synced with the same phone, even encrypted phone calls, which aside from the large amount of work involved may or may not be possible depending on what the Ubuntu phone SDK exposes.

    While new features are being added it is very likely that backwards incompatible changes will be introduced to the way message storage is handled, and while attempts will be made to make migration painless, do not yet store any important information solely in the application's database.
    Both the conversation SQLite database and the attachments are under /home/phablet/.local/share/textsecure.jani in case you need to access them independently of the app.

    The project is written entirely in Go. Working with Go for the backend library and with go-qml for the UI has been a mainly positive experience, although I wish go-qml were more actively maintained and had a more complete coverage of the common APIs and use cases that C++ Qt/QML developers are used to.

    If you try it out, file issues on github. If you know QML and feel like contributing, check out the project at github.com/janimo/textsecure-qml and get it touch on the mailing list

    Posted by
    Labels: en signal ubuntu
    0

    Add a comment

  2. Cross compiling Go packages to ARM is easy unless they rely on C libraries via cgo, in which case C cross-compilers and libraries built for the target are required on the host, and the invocation is not straightforward at all.

    Dimitri's post shows a way to do it using armhf chroots, and inspired by it I put together a docker image that does slightly more and can be used as if it were a simple command. The image uses a Go
    package built from a PPA , since the one in the archive does not have a CGO enabled ARM cross compiler.

    Install the image

        $ docker pull janimo/goqml-cross

    Set up an alias for convenience

       alias goqml-cross='docker run --rm -it -v $(pwd):/home/developer -v $GOPATH:/home/developer/gopath -w $(pwd|sed "s,$GOPATH,/home/developer/gopath,") janimo/goqml-cross'

    Go to the source tree

      $ cd $GOPATH/src/your/package

    Run the container as if it were the go tool (which in fact it is, /usr/bin/go being the docker container's default entry point)

     $ goqml-cross version
     $ goqml-cross build -i

    This will reuse your host environment's GOPATH and place the resulting Go packages under $GOPATH/pkg/linux_arm/ to be available in subsequent fast incremental builds.

    Check the docker registry for details on how to use it and the project on github if you want to build your image from source.

    Posted by
    Labels: en qml ubuntu
    0

    Add a comment

  3. I have been meaning to try QML for a while, and a couple of weeks ago I managed to finally do it, the result being a simple memory game for small children, a clone of the GCompris railway activity. In this post I'll summarize my short experience with Ubuntu click app development.

    TL;DR
    QML + Javascript is the easiest way I have seen so far to program a small interactive app. The extra tooling I did not test, I used vim and click from the command line. Documentation is so and so. App deployment and installation on Ubuntu for Phones is working well enough, even if is has rough edges.

    The game itself

    The game is about watching cartoon trains composed of a locomotive and a small number of different wagons scroll on the screen and then trying to reconstruct them from memory. There are no written or spoken instructions given. Let figuring out the rules be part of the game :)

    Unlike GCompris, this clone works with touch input, the lack of availability of a touch-based railway game being the secondary motivation behind the exercise :) All sounds and most images, much like the game idea are lifted from GCompris and credited accordingly.

    If you're impatient and happen to have Ubuntu running on a phone but preferably on a tablet you can install it by searching for 'railroad' in the application screen. If not, apt-get install gcompris :)

    The source code with full non-rebased git history is here, GPLv3 licensed
    https://github.com/janimo/railroad

    File issues there if you find a bug or want a feature.

    QML and QtQuick

    I finally found out that QML stands for only the Javascriptish language and runtime, while QtQuick is the core of the 'stdlib' that comes with Qt/QML, itself mostly written in QML.

    This combo is surprisingly pleasant to work with, yielding quick results from a comparatively small effort and few lines of code. The built in support for animations and multimedia in QtQuick and the reactive programming feature of property binding in QML were all very welcome. As things evolved though, I often found myself having to and even wanting to move most of the logic into a separate JavaScript file and give up on some the nice declarative features given by QML. For example it turned out that while a Grid that would automatically lay out train images given the number of rows and columns to use was very convenient and concise, I eventually used a dumb Rectangle as the container and calculated x and y explicitly for each train as they did in the 70's in order to have more control over where they end up to match the SVG background image.

    This is not unusual, I understand that the idea of using QML only for the graphics and doing the rest in C++ is a popular view among developers with experience. IMHO that is very bad idea to hold onto though if you want to encourage quick prototyping and having a chance to compete with Android or FirefoxOS for developer's attention. There will always be a need for code that cannot or should not be done in QML, but that should be the exception, and even then I'd rather see Go-QML be the glue between QML and the OS. That too relies on C++ but mostly hides it along with the build system from the developer.

    Tooling

    In order not to learn too many new things at once, and to avoid pitfalls unrelated to actual programming I decided to just use vim to edit and qmlscene to test and run the app.
    The only change in vim's configuration was adding syntax highlighting for QML via this snippet in ~/.vimrc

    Bundle 'peterhoeg/vim-qml'

    and then running the BundleInstall vim command.

    It's that easy since I started using  Vundle :)

    I find the Click packaging format refreshingly simple and to the point.

    Documentation

    I used the official Qt documentation site mostly. It is comprehensive but not easy to navigate, it is a collection of rather disconnected islands covering QML, QtQuick, etc, but with quite some overlapping content. I used the in-site search functionality often, and even global googling to find me something on the site I was already on :) Regarding the Ubuntu documentation I agree with all that Stuart had already said

    App building and deployment

     I used the click command line tool on the development computer to build the click package.
    I may have missed out on important packaging scaffolding and validation tools since I did not use the SDK. I wished I could do click newpackage and later click check (or using equivalent tools if not click itself) to get a basic skeleton working and to catch errors such as malformed developer email address, before uploading.  I found out about reviewer-tools only recently.

    The link I followed on the Ubuntu app developer site to publish the already built click package turned out to be the wrong one and non-working, but only after going through the 5 page wizard. I _think_ this is fixed now.
    The app was let into the appstore no more than 30 minutes after it being uploaded the first time. There was a need for a second time and for the obligatory version bump in order to correct the email address typo mentioned above.

    So while these steps seemed confusing it can be partly ascribed to me being new to it all.

    App install and update

     Since I still find the Ubuntu phone interface and navigation confusing and since there are still bugs in the implementation I spent too much time trying to get the app installed by it not showing up in search, or a stubborn on screen keyboard hiding the Install button from view when I found it.
    I made a minor bugfix release of the game yesterday (0.1.2) but I am not sure how to upgrade to it on the device. Still lots of things to learn about and fix on Ubuntu for phones :)
    Posted by
    Labels: en qml ubuntu
    0

    Add a comment

  5. After exactly two years of neglect which I will henceforth market as 'LTS cadence' last week I released a new version of the Ubuntu remix with Romanian, Hungarian, German and English languages included by default.

    http://kiwilinux.org/en/

    It is based on Ubuntu 12.04.1, and keeping in line with the traditional and largely unwritten goals of the project, it targets Linux newbies who find some of the standard Ubuntu apps lacking or who are taken aback by anything too unfamiliar. Windows XP users for example. It also targets lazy people who would otherwise change about the same things on a vanilla Ubuntu install.

    So it features the Classic Gnome 2 desktop, Chromium, VLC, Pidgin, Flash, multimedia codecs and the rar and p7zip archive format handlers popular in Windows. Small changes compared to plain Ubuntu for someone who knows where to find these packages or change the defaults but for new users such small changes can save a lot of googling and digging in forums. I do not think there needs to be any rite of passage for someone to qualify to simply use a free OS.

    Besides the usplash theme and some changes to the installer slideshow the appearance is 100% Ubuntu. No point in spending time on custom wallpapers let alone entire themes and invalidating the hard work that went into the Ubuntu looks in the past few years just to gain some gratuitous differentiation. Besides, users tend to change their wallpapers.

    Also no separate community is encouraged, it is more or less Ubuntu, people should use the regular forums.

    I also switched the website to use the nice Jekyll tool and to host it on Github Pages while updating and deleting a lot of text from it. Still there is much to trim before perfection is achieved.

    The plan, which was tentative two years ago, to no longer release non-LTS based releases is settled on now. If there's still a market for Linux desktops in two years,  you may see a Kiwi 14.XX then :)

    Next step: upgrade my mom's old Kiwi 8.04 or whatever old version is on her computer :)

    Posted by
    Labels: en kiwi ro ubuntu
    8

    View comments

  6. With the latest upload into the Ubuntu 12.04 archives MongoDB 2.0.4 builds and passes its smoketests on ARM.
    Upstream's git master - the 2.1 branch - also supports at least ARMv7 and Ubuntu.
    Posted by
    Labels: en ubuntu
    0

    Add a comment

  7. Even though some of these tools have been around for years, I have only recently started using them.

    * byobu - nicer than plain screen with good defaults, for example key binding for scrolling is like in a regular terminal.
    * sbuild - nicer than pbuilder, defaults to overlay directory instead of tarball, hence fast by default, nice colors, build summary. I have heard about it for a long time, but the recent mention during Ubuntu devel week made me curious. It is friendlier now - no need for LVM snapshots. http://wiki.debian.org/mk-sbuild
    * syncpackage - which now allows syncing from Debian if you have Ubuntu upload rights. No need to burden the archive team members anymore for every sync or go the roundabout way of getting from Debian and then uploading manually without changes.
    * Modern Debian packaging in the form of the 3.0(quilt) source format and the new dh tools. The former allows a cleaner separation between the upstream and distro bits while the latter makes the debian/rules file much shorter and cleaner even than with CDBS, let alone with the classic debhelper way.
    * Twitter Bootstrap - mostly unrelated to packaging or command line stuff, but very nice regardless. CSS+Javascript UI elements that for me at least make jQueryUI superfluous, while being promoted as 'oh, just a CSS framework and style guide, not much else'.
    Posted by
    Labels: en ubuntu
    1

    View comments

  8. There's a fresh release for the Lightspark Flash player, the third one on an approximately monthly schedule.
    Most new changes in 0.5.3 are robustness and portability fixes and a working Windows port, the vast majority of it being done by Matthias Gehre.

    Coverage of the testsuite from the Tamarin VM is also progressing well.

    The source tarball and .exe installer are found on Launchpad

    Ubuntu user can get updated packages from the daily PPA for Natty and Oneiric.

    You can follow the development version and contribute on github.
    Posted by
    Labels: en lightspark ubuntu
    0

    Add a comment

  9. After over two months of work since 0.5.0 by a handful of developers, there's finally a new release of Lightspark, the (other) open source Flash player. Unlike Gnash, Lightspark supports the AVM2 virtual machine and the newest versions of SWF files, while falling back to Gnash when it encounters SWF8 or earlier content.

    News for users

    For users, the most visible change is that YouTube is working again - their player keeps getting updated and sometimes it introduces Flash APIs or VM opcodes which are not fully implemented in Lightspark, resulting in breakage.

    Flowplayer had been made to work in this cycle.

    EGL/GLES2 based rendering has been added so it can run at reasonable speeds on ARM hardware where there is generally no support for hardware accelerated desktop OpenGL.

    Less crashes due to the many small and large fixes added.

    Changelog for 0.5.1

    * Misc fixes to better support YouTube, Vimeo, Flowplayer
    * VM correctness improvements
    * Support for AS templates
    * Dropped half-finished AVM1 support
    * Support for EGL/GLES2 rendering
    * Support for loading external JPEGs
    * Better text handling(e.g. coloring)
    * Improved test runner, support for the Tamarin testsuite
    * Various API fixes for bugs uncovered by the testsuite
    * Dropped mozilla dependency, use internal NPAPI headers
    * Added LIGHTSPARK_PLUGIN_LOGLEVEL environment variable to control the log level of the browser

    News for the project

    Alessandro, the main author and original maintainer of the project is taking a break for a few months, so most development and project management in this cycle has been done by the existing contributors.

    The Lightspark team is planning to release new versions monthly from now on, to get the fixes out sooner.

    We also plan to move away from the sourceforge.net homepage and wiki, and manage the project using only two instead of three hosting services :)

    * github for code, wiki and developer related issues

    * launchpad for user bugtracker, mailing list, release tarballs and Ubuntu PPAs

    Download

    The release is already available in Debian Sid and Ubuntu Oneiric and there are daily builds available in the team's PPA for Ubuntu Natty and Oneiric. The upstream code is progressing rapidly and does not really add regressions so using these daily packages is pretty safe and also helps a lot with testing.

    The release tarball is on Launchpad for other distro packagers or people building from source...

    https://launchpad.net/lightspark/0.5.1

    ...although for the latter category I'd suggest to follow the project on github :)

    https://github.com/lightspark/lightspark
    Posted by
    Labels: en lightspark ubuntu
    4

    View comments

    1. What percentages of the Flash API and VM opcodes does Lightspark cover?

      ReplyDelete

    2. There's a script in the source tree that produces such an output from the sources and Adobe's offline version of the API reference docs.

      Looks like about 5% of the API. Not a good metric probably, as many of those are rarely needed, but there is still a lot to cover until major sites work.
      http://startx.ro/~jani/lightspark_coverage.txt

      We should probably have such an output linked from the main website - once it is decided which the main website is :)

      AVM2 Opcodes are mostly implemented with a few exceptions which too are rarely used - I only saw instanceof missing today.

      ReplyDelete

    3. Year ago someone asked about vdpau support and it has been said that this isn't difficult to achieve so maybe in future. Now I'm asking about vdpau one more time ;) Is there going to be a vdpau support in lightspark in near future?
      Adobe Flash support it, but it is so unstable that it sometimes crashes even Xorg

      ReplyDelete

    4. @skoruppa, good sir, please file a bug on the project in Launchpad as it seems something to at least look into in the future. Thanks

      ReplyDelete
Blog Archive
Blog Archive
About Me
About Me
Loading