List view
- No due date•21/25 issues closed
The goal is to be able to automatically detect that a user has saved changes to their code, recompile then refresh their application which is already running. This is also a larger subject that includes live asset reloading.
No due date•1/5 issues closedThe patents for MP3 have expired, making it possible now to decode (or if we want to, encode) without obligating users to $$$$ in licensing fees. Even though other formats are arguably better, this would be a good one to support because it is so popular.
No due date•0/4 issues closedWe need to go back to the drawing board on the current `lime.text.TextLayout` API, expanding on native exposed bindings for Harfbuzz and/or Freetype, and building in more of the calculations we need on HTML5 to try and accurately measure and layout text
No due date•4/5 issues closedMany Lime APIs function based on events dispatched as input occurs, but for applications that desire to poll the current status of the mouse, keyboard and other devices, it would be nice to provide this. We may not be able to know with full certainty (especially if we lose window focus) whether our values are completely accurate, but providing state tracking with as good of accuracy as we have would be ideal to help reduce code for developers
No due date•1/3 issues closedHashLink (HL) is created by Nicolas Cannasse, who also was the original author of Haxe, and is the author of Neko. HL might be an ideal target for quick compilation, but also reasonable runtime performance, so there are a lot of possible benefits.
No due date•5/5 issues closedAlthough Lime largely supports Flash as a backend, there are a number of minor issues affecting parity with native and HTML5 backends which are used more often. Let's polish off any of these remaining issues so we can have greater consistency between target implementations
No due date•0/6 issues closedThe older `lime setup` command is becoming out-dated, increasingly the tools required to setup each platform are either A.) something we cannot install automatically, or B.) are becoming out-of-date, and as each release can vary, it is difficult to maintain our setup scripts over time.
No due date•4/4 issues closedIn addition to OpenGL ES 2.0 bindings, and relating to support for WebGL 2 bindings, we should add support for OpenGL ES 3.0 bindings on native, and ideally, add compatibility for WebGL 2 compatible browsers where possible
No due date•5/8 issues closedAdd support for WebGL 2 bindings (which are similar to OpenGL ES 3.0 bindings, but made compatible for JavaScript). The goal is to work primarily on HTML5, but also to be accessible from mobile and desktop devices that can support the same APIs using OpenGL ES 3.0 or OpenGL 4 and 5
No due date•2/3 issues closedLime was created with WebGL bindings on native mobile, native desktop and HTML5, but broader support for desktop and mobile should allow support for APIs not supported in WebGL, or supported in WebGL, but with additional abstraction that makes use on native somewhat more expensive.
No due date•3/3 issues closedIn the future, Adobe Flash will reach end-of-life, but it is possible that Adobe AIR will continue to be supported beyond the EOL date for Flash Player. In the meantime, we would like to extend our support for Flash Player to use the Adobe AIR SDK and package for AIR, so long as it does not become a drain on our focus on other issues. Initially, AIR support means standard Flash or `#if air` API support for AIR, but long-term this would mean AIR backend support so that standard Lime APIs are also supported on AIR (such as threading, windowing and other APIs support by AIR that are not possible in Flash to form a complete Lime backend)
No due date•7/7 issues closedCurrent Windows support uses Win32 subsystem, which limits support for publishing in the Microsoft Windows Store, as well support for Xbox One or Windows Phone. Adding Universal Windows Platform (UWP) support would modernize our support for Windows, and broaden possibilities for publishing.
No due date•3/5 issues closedLime already supports the ability to plug in external code for native extensions, but there are additional steps we can take to further the goals of making native extensions simple or logical to write, and to make them pluggable so developers can add and remove extensions using haxelib, rather than making more complex template override changes
No due date•1/2 issues closedHTML5 and Flash support video, similar to `lime.graphics.Image` or `lime.media.AudioSource`, we should draft up an API that combines these APIs under one roof for standard use.
No due date•0/4 issues closedThere are some areas where we should improve our support of cURL, and the TLS library underlying our version of cURL used for native platforms.
No due date•2/3 issues closedWe should have an `AudioSource` API that integrates support for standard audio playback. Accessing OpenAL, Web Audio or Flash audio directly will still allow more nuanced control over audio, but `AudioSource` should provide the simple "play this song, advance 20 seconds" type of functionality that cover the majority of uses.
No due date•6/9 issues closedCreate a new API that unifies cURL, XMLHTTPRequest and other HTTP network APIs under one roof. Ideally, it should combine simplicity (for "fetch this remotely, please" behavior) but also provide enough depth that users are not forced to go to lower-level APIs for most behavior
No due date•4/5 issues closed