Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Developing U++ » U++ Developers corner » Rainbow, first iteration  () 1 Vote
Rainbow, first iteration [message #32829] Mon, 13 June 2011 15:03 Go to next message
mirek is currently offline  mirek
Messages: 13975
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 #32832 is a reply to message #32829] Mon, 13 June 2011 21:24 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
I have created 'rainbow' nest in svn for general rainbow development and as a proof of concept I have 'reimplemented' Win32 backend (simply by copying existing Win32 backend).

BTW, interesting stat: Win32 backend is about 6000 lines, chameleon excluded...
Re: Rainbow, first iteration [message #32841 is a reply to message #32829] Tue, 14 June 2011 10:36 Go to previous messageGo to next message
chickenk is currently offline  chickenk
Messages: 169
Registered: May 2007
Location: Grenoble, France
Experienced Member
/home/lionel/upp/uppsrc/CtrlCore/CtrlCore.h:10:2: erreur: #error 


I think the '#error' line is a garbage stuff, isn't it?
Re: Rainbow, first iteration [message #32842 is a reply to message #32829] Tue, 14 June 2011 14:06 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

Excellent news.
Quote:


Perhaps Daniel could now also try to 'port' OpenGL U++ to rainbow too.


Yes, I'm gonna do that.
Re: Rainbow, first iteration [message #32845 is a reply to message #32841] Tue, 14 June 2011 17:59 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
chickenk wrote on Tue, 14 June 2011 04:36

/home/lionel/upp/uppsrc/CtrlCore/CtrlCore.h:10:2: erreur: #error 


I think the '#error' line is a garbage stuff, isn't it?


Yes, sorry about that...

Mirek
Re: Rainbow, first iteration [message #32859 is a reply to message #32845] Wed, 15 June 2011 09:33 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
There is now rainbow/Skeleton package - empty GUI backend, it only compiles and links and does nothing.
Re: Rainbow, first iteration [message #32863 is a reply to message #32829] Wed, 15 June 2011 16:21 Go to previous messageGo to next message
harmac is currently offline  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 Go to previous messageGo to next message
kohait00 is currently offline  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 Smile 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 361 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 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
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 Smile

Mirek
Re: Rainbow, first iteration [message #32942 is a reply to message #32938] Thu, 23 June 2011 00:02 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
looking forward to have it Smile
really havent found the time to actually fully get this stuff done, didnt get past the point of extracting/extending the interface just as you did for rainbow now, in a much cleaner way... but i'm still interested.
Re: Rainbow, first iteration [message #32973 is a reply to message #32942] Mon, 27 June 2011 09:52 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
really nice progress in Frambuffer.

i tried to compile it in suse, making WinFB dependant of WIN32 flag. it depends on a the windows virtual key codes and the stuff from stdids.h.. the virtual key codes are in WinUser.h, how should we tread this stuff? can we pack them together?

fb0 shows first Upp stuff [message #32975 is a reply to message #32973] Mon, 27 June 2011 14:49 Go to previous messageGo to next message
kohait00 is currently offline  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 Smile..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 359 times)

[Updated on: Mon, 27 June 2011 15:25]

Report message to a moderator

Re: fb0 shows first Upp stuff [message #32980 is a reply to message #32975] Mon, 27 June 2011 16:54 Go to previous messageGo to next message
Sgifan is currently offline  Sgifan
Messages: 37
Registered: February 2010
Location: France
Member
Just for the pleasure of the eyes, could you please send a screen shot of this.

thxs
Re: fb0 shows first Upp stuff [message #32981 is a reply to message #32980] Mon, 27 June 2011 17:14 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
this is the quickest option i could find Smile my phone
as mentioned, input handling is not implemented..so the cursor down left is there..
it's from my opensuse enterprise laptop, started from one of the virtual terminals..

index.php?t=getfile&id=3344&private=0

[Updated on: Mon, 04 July 2011 13:59] by Moderator

Report message to a moderator

Re: Rainbow, first iteration [message #32982 is a reply to message #32973] Mon, 27 June 2011 17:43 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Mon, 27 June 2011 03:52

really nice progress in Frambuffer.

i tried to compile it in suse, making WinFB dependant of WIN32 flag. it depends on a the windows virtual key codes and the stuff from stdids.h.. the virtual key codes are in WinUser.h, how should we tread this stuff? can we pack them together?




Well, that is one of ToDo now... My current plan is to make keycodes defined in 'final' framebuffer backend, perhaps through rainbow #define.

Alternative approach would be to define framebuffer specific keycodes and translate (from Win or X11) to them. IMO, much more work...
Re: fb0 shows first Upp stuff [message #32983 is a reply to message #32975] Mon, 27 June 2011 17:50 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Mon, 27 June 2011 08:49

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.




rainbow now has the same rights as bazaar - you are welcome to join the development and apply patches. Please commit linux fb as new backend if you wish so.

Just keep in mind please that the "Framebuffer" is meant to be generic, then there should be some kind of "final" backend, like WinFB.

Mirek
Re: Rainbow, first iteration [message #32984 is a reply to message #32829] Mon, 27 June 2011 17:52 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
P.S.: Give it an hour to rights become active...
Re: Rainbow, first iteration [message #32986 is a reply to message #32984] Mon, 27 June 2011 18:14 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
i'll be checking it.. thanks for welcoming Smile hope to help.

current name was RealFb which should probably be set to LinuxFb or sth. like PosixFB?

you are currently using the windows virtual key codes. why not keep them? stdids.h is lend from win32 as well and is part of CtrlCore (for X11) so why not? save some work actually. i admit i havent spend much on this isue anyhow..i just copied the VK codes from WinUser.h to make it run.

did you think about the GUI_X11 problem and how to solve it?
for best performance , ImageBuffer should be initializable from a given buffer as well. thus we can spare ourselves some copy time..
but it has Buffer<char> pixels inside..maybe to use sth different? maybe it will be difficult because of ref count Image data takeovers.. but think about it.
Re: Rainbow, first iteration [message #32987 is a reply to message #32986] Mon, 27 June 2011 21:05 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
kohait00 wrote on Mon, 27 June 2011 12:14


you are currently using the windows virtual key codes. why not keep them? stdids.h is lend from win32 as well and is part of CtrlCore (for X11) so why not? save some work actually. i admit i havent spend much on this isue anyhow..i just copied the VK codes from WinUser.h to make it run.



I believe it will be easier to define a new set for particular framebuffer backend...

Actual revision moved keys.h to WinFB.

Quote:


ImageBuffer should be initializable from a given buffer as well. thus we can spare ourselves some copy time..



Well, I expect 'backpaint' operation to be default for framebuffer for now. It is easier to develop and perhaps the required mode anyway.

Quote:


but it has Buffer<char> pixels inside..maybe to use sth different? maybe it will be difficult because of ref count Image data takeovers.. but think about it.


Actually, I already did and in the future, I plan to change BufferPainter to use raw binary buffer too (instead of ImageBuffer).

Mirek
Re: Rainbow, first iteration [message #32994 is a reply to message #32987] Tue, 28 June 2011 12:39 Go to previous messageGo to previous message
kohait00 is currently offline  kohait00
Messages: 939
Registered: July 2009
Location: Germany
Experienced Contributor
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'd find it pretty nice to have the backends in seperate packages..
i noticed that WinAlt does not use cham. is this planned?

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).

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.

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.
Previous Topic: Upp Server (SVN, Redmine) down?
Next Topic: Docking package fixed and moved to uppsrc
Goto Forum:
  


Current Time: Thu Mar 28 15:27:56 CET 2024

Total time taken to generate the page: 0.01496 seconds