|
Roadmap for upcoming Ecere development The Ecere SDK is continuously under active development. We are currently working on the pre-release 2 of version 0.44. We're hoping to get it ready by November 2010. You can see in more details what we're working on and track our progress at http://www.ecere.com/mantis/roadmap_page.php. This pre-release is mostly about fixing critical problems (mostly in the IDE) and small things that won't take us too long to fix. We'll probably have one more pre-release before 0.44. Pre-release 3 will be mostly about fixing some more problems in the IDE and adding badly missing features or functionality. Help is needed to achieve these goals, therefore contributors are most welcome. Please come visit us on IRC in #ecere on irc.libera.chat, visit our online forums or contact Jerome at jerstlouis@gmail.com if you're interested in contributing to Ecere. Going forward into the future we have some ideas for major improvements and new features. We hope to introduce some of these in version 0.45: The eC language and Compiler The eC language has come to be what the Ecere SDK most prides itself on, with great C compatibility, powerful dynamic features, native performance and an important elegance factor. The language is still young, and there are still new features planned to be integrated, such as string objects and operator overloading support. Take an important part in their design and the implementation of their support in the compiler. The compiler is still at its first version, initially developed as a proof of concept and prototype for the eC language. The current approach is to use C as an intermediate language. This might be changed in favor of implementing a GCC frontend for the code generation, or using a third party library to avoid some of the constraints of going through an intermediate language. One particular serious performance issue involves reordering declarations in the process of generating C code which can be painfully slow in some situations. Overall the compiler could benefit from a good review, some re-engineering and optimizations. The backlog of issues and missing features which were assigned a lower priority up to now in the eC compiler is rapidly piling up, and addressing these would bring eC to far higher quality standards. Templates and a container template library were recently introduced in the last official release, and there is still some unfinished work pertaining to completing the transition to these new options. Support for 64 bit architectures is to be implemented, some important adjustments in the compiler must be done to successfully support these. Mac OS X Native Interface Support Ecere currently runs on Mac OS X through the X11 application (Unix compatibility mode). This isn't so great, and also has many usability issues. Furthermore it's far from what Mac users would expect of cross-platform applications. This project is of a great importance as many developers have demonstrated a keen interest on Ecere running properly on the Apple platform. Support for a Cocoa interface and graphics output drivers should be implemented. Ecere is built in a very modular manner, support for OS interface and graphics output being achieved entirely through driver plugins. Properly supporting Cocoa is likely to require delving into implementing interoperability of eC classes and objects with the Objective-C language. Cocoa support will also pave the way for Ecere/eC to be available as an iPhone development platform and bring Ecere to the mobile world. Interoperability with other Languages eC currently plays very well with C. But we want to take this further and want eC to be friendly to all other languages. eC uses a very powerful component object model architecture which will allow automatic bidirectional binding to other popular object oriented languages such as: ObjC (as required for Mac OS), C++, Python, CLI (for the .NET platform and languages), JNI for Java. It would also be nice to give access to eC objects directly to C programs. Improving the GUI Toolkit The Ecere GUI toolkit is a light, but very powerful and complete set of widgets to build responsive and user friendly applications. However there are a few issues we would like to get out of the way. One of the complaints is the lack of support for the "Native" operating system look. Ecere takes the uniformity across all platforms for the same application side on this great debate. But we still want everyone to be happy, and certainly the support of a "Native Skin" would be very valuable. This has some important implications, since Ecere currently renders all the internal contents of a top level window using its own rendering system (Which would make it difficult to use native controls) and uses its own system to handle window positioning and resizing by the user. Additionally, the current default skin resembles Windows 2000, which multiple users have reported looks awkward on modern-looking OSes such as Vista. Ecere currently supports the use of skin plugins which a developer can include in their applications. The creation of a higher level skin customization system (which skin artists could manipulate without coding required) as well as some elegant skins with a more modern and distinct look would give Ecere a much better image. The GUI toolkit API is in great need of a review and reorganization of its hierarchy/API. The addition of some higher level controls or the addition of features to the existing controls would also be very valuable. Usability on the X Window System There is still a bit of work to do to complete the usability of Ecere on the X Window System. An important performance improvement would be to use the glyphs API of XRender to attempt speeding up text rendering. Various functionalities are also still left not implemented on X. OpenGL support has been difficult to get working on some video cards, particularly non-GeForce cards (There are also some issues about 3D support on Windows as well) Internationalization System There are plans for the Ecere SDK to support a very powerful internationalization system. The basic idea (of which the feasibility has not been analyzed yet) will be that the applications are initially coded in a single language, without any attention paid to what is to be internationalized... An external tool (Let's call it the Ecere Application Translator) could then be used on the built executables by a translator (which does not have to be a programmer, and hopefully will not need the source code either) to do the translation. The tool would point out everything that might need to be translated, saving the translation files specific to each language. These could then be reintegrated into the binaries by anyone with that same tool. When a new version of an application is reopened through that translation tool, a comparison algorithm will match the previously translated strings to the current ones, and will identify removed or added strings in order to facilitate updating the translations. Bringing the IDE up to par The Ecere IDE, although it is full of potential, currently lacks a certain quality standard which might discourage some to chose the Ecere SDK as a development solution. It would be great to bring it up to par with the most popular IDEs out there. One of the first thing to do might be to add docking support in the IDE (as well as the GUI toolkit at the same time) and tabbed documents instead of the current MDI model patched with annoying auto-resizes. Some additional tweaking and improvements such as polising the project management support and resolving some issues with the code editor might just make it one of the best development environments available. The Integrated Debugger The Ecere IDE features an integrated debugger, running GDB as a backend. Although the debugger generally works, there are many problems/unfinished business with it which we'll admit to be great impediments to developing with the Ecere SDK. In-depth testing to reveal all problems and resolving all issues would be of a great help to the Ecere project. The watch support particularly would greatly benefit from being completed as it has been left unfinished. The Form Designer The Ecere IDE supports the integration custom designers for any kind of objects in dynamic libraries. This feature has been used mainly for the Form Designer so far. The current version of the form designer is very basic and lacks features such as multi-selection, cutting and copying, aligning, etc. There are also some more complex situations in which the form designer is currently rendered useless and one must resort to hand editing GUI definitions (which luckily is very elegant and easy to do in eC), to which it would be great to find an easier alternative. It would also be nice to further improve GUI design in eC in various ways. CodeGuard - Ecere's Source Code Configuration Management All of Ecere source code has been kept track of on our own source code configuration management system called CodeGuard. CodeGuard is extremely simple and easy to set up, relying entirely on Ecere technologies, and provides some very powerful features (on which we insist) which alternatives like cvs and svn lack. The only sad thing is it has been left unfinished for a very long time. Some things which need to be implemented in it are: user authorization, support for private projects, update command implementation, support for tagging releases, finishing branching support, a GUI interface, a comparison tool, conflicts resolution. Improving the Documentation Editor Ecere currently comes with an API Reference tool listing all the available contents of an eC library along with its saved documentation. The tool currently also allows to edit the documentation directly (although it has yet to be used to document the Ecere API). This documentation editor is meant to become a powerful tool to ease the documentation of APIs, with the documentation being kept separate from the actual source code (unlike Doxygen and the like). It will feature functionality to point out new and obsolete APIs when used upon new releases of APIs, in a way similar to the description of the Internationalization System above. It should also be able to automatically generate release notes. There are many improvements to be brought to the current documentation tool, which will in fact become two tools: a reference tool and an editor. The reference tool will also require among other things a new search system and better integration with the IDE's code editor (lookup with F1...). The Ecere/eC Web Revolution Ecere's vision of the web does not have a browser as a middleman. Applications run at native speed. Applications benefiting from Internet connectivity are not confined within a browser: not only do they look and feel like regular applications but they really are standard applications. Endless possibilities come up when web applications now run in full speed: one can run a graphical shell directly from the web, one can take full advantage of 3D graphics capabilities for a complete new level of entertainment. Web applications can be built just like any regular application by using the same development tools, and the web simply become an additional platforms that Ecere applications can be deployed on. Developers can use eC on both the client and server ends of their applications, and thus do not need to learn additional toolkits/languages, or use complicated mix of various technologies patched up together. A clean, lightning fast, uniform web deployment solution. This is the Ecere/eC web revolution and you can take an important part in it by working on this project. A basic proof of concept has already been built, based on the distributed component object model builtin Ecere. We are contemplating using just in time compiling through a library such as libtcc to build the applications, along with a caching system. Of course there is a lot of consideration to be brought to security issues. But the basic idea is that both client and server code are written in eC, without the need for a browser in the middle. The web was initially meant for pages, not applications. A "web page browser" in this new system can simply be one of the many web applications available (which can be launched by your graphical shell, which can itself be an online application), but the entire web framework would support URLs and such. Client plugins for existing web browsers could be used to integrate the technology into existing browsers. The Ecere Desktop Environment One of the goals of the Ecere project is to provide a complete Desktop Environment platform. Recognizing Linux as a promising operating system for this purpose, the first part of the project consists in developing a lighter alternative to GNOME / KDE environments which rely on toolkits such as Qt and GTK and many other dependencies. The first step towards this would be to build a window manager based on Ecere, along with some customizable panels sytsems giving the user a friendly graphical shell to launch his applications. Another important tool would be a file browser to perform basic file management operations and interaction with running aplications (a very basic file browser has already been implemented). Copyright © 2009-2010 Ecere Corporation |
