Home » Developing U++ » U++ Developers corner » Rainbow, first iteration
( ) 1 Vote
| Rainbow, first iteration [message #32829] |
Mon, 13 June 2011 15:03  |
 |
mirek
Messages: 14290
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 482 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: 14290
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 486 times)
[Updated on: Mon, 27 June 2011 15:25] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Rainbow, first iteration [message #32995 is a reply to message #32994] |
Tue, 28 June 2011 13:32 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Tue, 28 June 2011 06:39 |
we actually dont need a common codes set, the backends normally provide them as well. i.e. linux input subsystem...
do you plan to detach the gui backends from CtrlCore completely?
|
I plan to keep Win32/X11 in CtrlCore. Most apps use just this and it would be 2 packages more in the list. In future, when MacOS and Android are available, I consider moving them there too.
| Quote: |
i noticed that WinAlt does not use cham. is this planned?
|
Unlike, WinAlt is only the first "proof of concept", nothing more.
| Quote: |
generally, from where do you plan to have the final GUI backend selection? from the top ackage like it is now or from the CtrlCore package? i mean where the guiplatform.h is finally situated. it could be 'overridden' in case of special specification. but all provided backends could live at some bottom level, to be selected with a compile flag like WINFB, LINUXFB, MACFB (those that are known and already exist).
|
I agree with compile flag and will be moving in that direction.
However, guiplatform.h placement is what it is supposed to be. I mean, first guiplatform.h in nest chain gets used. This is to allow everybody to groom his own backand withou fiddling with uppsrc code..
| Quote: |
this would reliev the user to specify it's own guiplatform, instead he could only take the Framebuffer package and select the backend via compileflag.
|
Actually, I believe we are heading right there.
BTW: i commited the state of yesterday. what is missing, are the patch0 changes.. i found a mean to convert git patches to tortoise patches. so here it comes again. [/quote]
I have found a problem there: In Image.h, GUI_X11 is not yet defined....
|
|
|
|
| Re: Rainbow, first iteration [message #32996 is a reply to message #32995] |
Tue, 28 June 2011 13:37 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
GUI_X11 not defined:
| Quote: |
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.
|
|
|
|
|
| Re: Rainbow, first iteration [message #32997 is a reply to message #32996] |
Tue, 28 June 2011 15:02 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Tue, 28 June 2011 07:37 |
GUI_X11 not defined:
| Quote: |
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.
|
|
OK, sorry. Will deal with this soon...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Rainbow, first iteration [message #33013 is a reply to message #33003] |
Thu, 30 June 2011 11:14 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
| mirek wrote on Wed, 29 June 2011 19:11 |
Hm, I guess that perhaps we should move GUI_APP_MAIN to final backend...
|
i think so too. the APP_MAIN stuff posted above is running well, though. this would leave the user with only one place to think about GUI switching, this beeing the flag.
a project would always compile with or without GUI flag, even if it uses CtrlCore stuff in a console app (might be a case someday), since CtrlCore/CtrlLib don't depend on GUI flag.
BTW: with that, i managed to override APP_MAIN in SDLFb.
so SDL is painting Upp now, too but it's all rudimentary. when it compiles and draws, one can relax and continue. for me to commit the starting point, i'd need to know which final direction this APP_MAIN stuff goes to.
i'd vote for this too, (but this is sort of taste dependant):
to move the specification of the implemented gui's, beeing native, to guiplatform.h
and have the defaulting take effect in CtrlCore.h
thus it uses the same means as upper guiplatform.h
which can #include "../uppsrc/guiplatform.h"
for backwards compatibility
CtrlCore.h:8
#ifndef GUIPLATFORM_INCLUDE
#ifdef PLATFORM_WIN32
#define flagWIN32GUI
#endif
#ifdef PLATFORM_POSIX
#define flagX11
#endif
//include again for defaults to activate
//guiplatform.h may not have ifndef/define protection
#include <guiplatform.h>
#endif
uppsrc/guiplatform.h
#ifdef flagWIN32GUI
#define GUIPLATFORM_INCLUDE <Ctrlcore/Win32Gui.h>
#endif
#ifdef flagX11
#define GUIPLATFORM_INCLUDE <Ctrlcore/X11Gui.h>
#endif
[Updated on: Thu, 30 June 2011 11:30] Report message to a moderator |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Re: Rainbow, first iteration [message #33047 is a reply to message #33046] |
Mon, 04 July 2011 22:57 |
|
mirek
Messages: 14290
Registered: November 2005
|
Ultimate Member |
|
|
| kohait00 wrote on Mon, 04 July 2011 14:58 |
did i understand you right, that key, first expects keydown/keyup events to be send, and then (after respective keyup) the corresponding char event?
|
Nope, characer is issued after keydown of course. For 'a' the sequence is K_A, 'a', K_A|K_KEYUP.
| Quote: |
which windows is already doing natively, WM_KEYDOWN/UP and WM_CHAR.. (do you fake this for X11?)
|
No need to fake, X11 is quite similiar, the only difference is that it only has KeyPress/KeyRelease and you convert to chars using some functions functions...
I guess these two levels naturally have to be on any system.
Mirek
|
|
|
|
| Re: Rainbow, first iteration [message #33048 is a reply to message #33047] |
Mon, 04 July 2011 23:29 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
OK.
i just commited a first shot SDLFb..
as i am not too experienced in SDL actually, there will be a lot to do yet.
we should think about grouping all the real Fb backends under Framebuffer. so the user actually does not need to add each and every backend at top level. Framebuffer could add them all and enable it with the right compile flag..
the speed of the stuff is actually really suboptimal due to full memcopy each repaint, i will try to fix this soon.
didn't watch the source development too carefully: have you added a BufferPainter creatable from an existing buffer yet? (specify the fb0 memmap directly as base, to speed up things).
[Updated on: Mon, 04 July 2011 23:31] Report message to a moderator |
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Apr 25 14:59:10 GMT+2 2026
Total time taken to generate the page: 0.01516 seconds
|
U++ framework
Search
Help
Members
Register
Login
Home
