|
|
Home » Developing U++ » U++ Developers corner » Rainbow, first iteration
() 1 Vote
Rainbow, first iteration [message #32829] |
Mon, 13 June 2011 15:03 |
|
mirek
Messages: 14038 Registered: November 2005
|
Ultimate Member |
|
|
I took time, especially considering it is mostly preprocessor compile time hack, but I believe that I have reached important milestone in Rainbow development, I believe it should be now possible to develop custom GUI for U++ without the need dir directly changing CtrlCore/CtrlLib (like MacOS or Android or OpenGL).
How is it supposed to work, at least, starting point:
The CtrlCore.h now begins with:
#include <guiplatform.h>
#ifndef GUIPLATFORM_INCLUDE
#ifdef PLATFORM_WIN32
#define GUIPLATFORM_INCLUDE "Win32Gui.h"
#endif
#ifdef PLATFORM_X11
#define GUIPLATFORM_INCLUDE "X11Gui.h"
#endif
#endif
guiplatform.h is in uppsrc root (not in package) and it is empty, so for normal operations "defaults" kick in.
If you are about to develop custom GUI backend, create a new nest, place guiplatform.h into it and using #define GUIPLATFORM_INCLUDE 'redirect' it to your own GUI specification header.
As for development itself, I believe that two 'default' backends give a good hint... I am using quite ugly combination of macros, includes and platform defined functions/methods; for now it seems to be the most cost efficient way. We will say how that works in practice...
Important notice: Whereas in the past we were using PLATFORM_WIN32 and PLATFORM_X11 in CtrlLib and other GUI code for #ifdefs to tell apart the GUI backend, this should be now replaced by 'GUI_WIN' and 'GUI_X11' (those are defined in GUIPLATFORM_INCLUDE), because it is no longer true that Windows backend has to used on Windows platform...
OK, this should work as first introduction. I am now plannig for actually developing generic framebuffer backend to tune this thing.
Perhaps Daniel could now also try to 'port' OpenGL U++ to rainbow too.
Mirek
|
|
|
|
|
|
|
|
Re: Rainbow, first iteration [message #32863 is a reply to message #32829] |
Wed, 15 June 2011 16:21 |
harmac
Messages: 16 Registered: January 2011
|
Promising Member |
|
|
mirek wrote on Mon, 13 June 2011 15:03 | I am now plannig for actually developing generic framebuffer backend to tune this thing.
|
Lacking knowledge about U++ implementation and style and graphics programming in general so far, I don't know if the following resources are helpful in the endeavour, as at present I'm too much of a C/C++ newbie, but still:
There is portable framebuffer library pxCore that seems to have been ported already to Windows, PocketPC (ARM4), Linux(X11), OSX. Maybe you can recycle some code of it for U++ if it fits the need or maybe it suits as a generic backend already.
It may not be directly framebuffer related, but when I read about the Fog-Framework, its Fog-UI component seems to use an abstract interface for GUI descriptions that is later mapped to different native targets. It sounds somewhat like what Rainbow seems to be trying. I haven't looked at the implementation but conceptually it sounds cleaner than the current U++ approach, which you name ugly yourself. Coming from different languages, from what I understand about the C/C++ preprocessor, it is an ugly kludge in the first place, and maybe it is worth to consider not using it at all.
If not for Rainbow, looking at Fog might be worthy in its own right, as some of its explicit design notes (like for instance not using STL) seem to be in accord with U++ philosophy, so that it might possibly be interesting to recycle code from there or maybe even join some efforts, as some purposes of both projects seem to overlap.
I don't know in what state Fog currently is, though, as the author seems to be concerned with another project (AsmJit), part of which he but seems to plan to integrate into Fog in the form of BlitJit, and in a post on a blog about the Fog-Framework (which also has a post with a number of vector geometry resources, which are probably a bit over my mind at the moment but which more involved people or those interested in learning might find interesting) he assures that the project is not dead. One of the goals at least seems to be high performance with maximum compatibility and adaptation to the target.
Speaking of which, when somebody recently posted about jslinux, I also read in an article about Fabrice Bellard that he had implemented with TinyGL a small subset of OpenGL that can be used as a fallback for systems that normally don't have hardwaresupport for it. As it is very old and probably incomplete, I don't know how close it is to OpenGL ES, but maybe it might be interesting for implementers of U++ OpenGL backends to take a look at such a limited subset whose GL instruction implementation for some arbitrary target platform can be done with reasonable effort and use that subset as a portable target for translations from U++ GUI descriptions.
Finally, there is Agar, which I hadn't heard about before. It may not follow any U++ philosophy but also has different raw targets and might therefore be interesting for somebody interested in the topic to see how different folks are doing their implementations.
pxCore, Fog-Framework and Agar are BSD-licensed, TinyGL zlib-like. As also some external links on their respective websites might be interesting for one or another and some of the projects themselves might be interesting for the U++ folks, I thought that pointing to these projects might be worthwhile. Note that I currently lack the knowledge to decide whether or not they actually are useful.
|
|
|
Re: Rainbow, first iteration [message #32934 is a reply to message #32863] |
Wed, 22 June 2011 10:21 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
this is really nice news..
MacOSX wont take long either with this helper. thanks.
as of android, it might be quite difficult to circumvent the whole java stuff. the only possibility will be the NDK.
concerning the 'uglyness' of rainbow:
as a program usually only uses one single graphics/ui backend, the compiled-in option is definitely the fastest way. of corse a clean HAL like GUI abstraction layer would be more clean but this al comes at expenses: complexity and speed. i think the current approach, though a bit 'ugly' and not transparent at first glance, is a moonolite solution. id definitely needs kind of a tutorial on how to start and what is what and what is expected to happen inside some functions. but this managable.
pxCore seems appealing. especially in terms of designing apps on PC framebuffer emulation whilst the still run on bare embedded frambuffer. that'd be a niiiiice advantage in embededded world. believe me one often breaks the neck there. recompiling untouched code is just heaven.
anyways, for the clean fb0 solution, i have found somewhere a test prog once, and tried to use it in u++.
find it attached.
@mirek: the Framebuffer / WinFB is a starter isn't it?
Framebuffer.h:60 lacks a ';'
do you already use the WinFB stuff? when i try to compile rainbow/Paint i get some errors.. have any working environment?
if you could provide a slight description on the files/some crucial functions i could try to make some steps.
-
Attachment: fb0test.rar
(Size: 1.39KB, Downloaded 383 times)
[Updated on: Wed, 22 June 2011 10:25] Report message to a moderator
|
|
|
Re: Rainbow, first iteration [message #32938 is a reply to message #32934] |
Wed, 22 June 2011 20:40 |
|
mirek
Messages: 14038 Registered: November 2005
|
Ultimate Member |
|
|
kohait00 wrote on Wed, 22 June 2011 04:21 | this is really nice news..
MacOSX wont take long either with this helper. thanks.
as of android, it might be quite difficult to circumvent the whole java stuff. the only possibility will be the NDK.
|
AFAIK, it is not longer needed. NDK is good enough now (I believe was ugraded at the end of last year).
Quote: |
concerning the 'uglyness' of rainbow:
|
Well, as I am now working on FB backend, it is perhaps ugly by concept, but in "live" development it does not look so bad...
Quote: |
and of a tutorial on how to start and what is what and what is expected to happen inside some functions. but this managable.
|
Actually, that is one purpose of FB backend...
Quote: |
@mirek: the Framebuffer / WinFB is a starter isn't it?
Framebuffer.h:60 lacks a ';'
do you already use the WinFB stuff? when i try to compile rainbow/Paint i get some errors.. have any working environment?
|
It's under development. Frankly, it barely compiles now. A lot has to be done before it even paints something
Mirek
|
|
|
|
|
fb0 shows first Upp stuff [message #32975 is a reply to message #32973] |
Mon, 27 June 2011 14:49 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
hi mirek
i played around with rainbow a bit.
thanks to your work, i've been able to have fb0 show the fullscreen view of Paint package. attached are the 2 patches.
patch0 has some fixes concerning PLATFORM_X11, which should be GUI_X11 or PLATFORM_POSIX now, please review it. there also arises a slight problem with Image, it still has some code PLATFORM_WIN32 and PLATFORM_X11 dependant. but due to elimination of PLATFORM_X11, which is available from Core level, GUI_X11 is available from CtrlCore level only, Image, which is included by CtrlCore does not know anything from GUI_X11. i dont have any solution for this. maybe the platform dependant stuff should be made a special class, which is implemented platform dependantly.
patch1 has got the changes for the real framebuffer, it is veery basic only, just to make it show sth. what idea did you have concerning ProcessEvent / Eventloop? read /dev/input in another thread? and what about non MT environment? there is no way to make the ImageBuffer directly be based on framebuffer pointer? one could save the copying..
i also attached the sources directly. in case you arent able to aply the diff patch (created under suse 11.3 with git make patch)
i am getting really excited. upp becomes really an option for embedded stuff ..and a good option.
EDIT: for those of you trying it out: make sure to execute the app in a console, where fb is enabled. do not try to execute it in your GNOME or the like environment. it wont show the fb.
-
Attachment: stuff.tar.gz
(Size: 74.13KB, Downloaded 385 times)
[Updated on: Mon, 27 June 2011 15:25] Report message to a moderator
|
|
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri Sep 20 04:57:48 CEST 2024
Total time taken to generate the page: 0.04147 seconds
|
|
|