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 » Porting Upp to SDL first ? (cause of MacOSX & framebuffer)
Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #27207] Fri, 02 July 2010 10:19 Go to next message
kohait00 is currently offline  kohait00
Messages: 933
Registered: July 2009
Location: Germany
Experienced Contributor
hi folks

i just took a brief look on sdl again, and in some other posts here the idea of porting upp to Mac world has stucked a bit. to push it a bit, here is an idea..

why not porting to sdl first, which would support MacOSX and many other platforms at once as well, and then, little by little...to platforms natively (even framebuffer, as stated in some of my other posts). SDL programs can be compiled in Upp already, but standalone ofcorse..

here is some quote again from libsdl.org

Quote:


SDL supports Linux, Windows, Windows CE, BeOS, MacOS, Mac OS X, FreeBSD, NetBSD, OpenBSD, BSD/OS, Solaris, IRIX, and QNX. The code contains support for AmigaOS, Dreamcast, Atari, AIX, OSF/Tru64, RISC OS, SymbianOS, and OS/2, but these are not officially supported.

SDL is written in C, but works with C++ natively, and has bindings to several other languages, including Ada, C#, D, Eiffel, Erlang, Euphoria, Guile, Haskell, Java, Lisp, Lua, ML, Objective C, Pascal, Perl, PHP, Pike, Pliant, Python, Ruby, Smalltalk, and Tcl.

SDL is distributed under GNU LGPL version 2.



RFC

PS: we at leas could take a look ad SDL in terms of how they bind with Objective C.. but i dont know exactly to *what* SDL bind, to the older Carbon API or the newer Cocoa API from MacOSX.

PSS: it would ne no great deal i think, becasue SDL offers just about same terms of interface, messageque and a blit surface, to which a SystemDraw could paint..

--> like always, RTFFAQ helps Smile

http://www.libsdl.org/faq.php?action=listentries&categor y=7

so seams like SDL supports the Cocoa API already. best for us Smile

will there be a licence issue if we get "inspiration only" from LGPL code related to MacOSX in SDL (LGPL). is that considered derived work?

[Updated on: Fri, 02 July 2010 10:37]

Report message to a moderator

Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #27208 is a reply to message #27207] Fri, 02 July 2010 16:24 Go to previous messageGo to next message
Mindtraveller is currently offline  Mindtraveller
Messages: 916
Registered: August 2007
Location: Russia, Moscow rgn.
Experienced Contributor

I don't think it can be consdidered derived work as long as you don't take original LGPL-ed code as a basement for your code (it means copy-paste and then edit).
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #27209 is a reply to message #27208] Fri, 02 July 2010 16:53 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 933
Registered: July 2009
Location: Germany
Experienced Contributor
no, its basicly to know what kind of functions are to be taken care of, so not to have to start from zero digging in man pages etc.
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29799 is a reply to message #27209] Thu, 18 November 2010 09:15 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 933
Registered: July 2009
Location: Germany
Experienced Contributor
i've seen koldo porting SDL to be a SDLCtrl.
but it seems not to be a 'true' sdl port, heavy relying on windows draw surface handles etc..

what was the intention for that?

btw:
Functions4U_Gui.h:7
needs to read like this to compile it successfully for GCC:
(making Image ref a const one)
inline const RGBA *GetPixel(const Image &img, int x, int y) {
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29802 is a reply to message #29799] Thu, 18 November 2010 11:13 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 2944
Registered: August 2008
Veteran
Hello kohait0
Quote:

i've seen koldo porting SDL to be a SDLCtrl.
but it seems not to be a 'true' sdl port, heavy relying on windows draw surface handles etc..
what was the intention for that?


SDLCtrl is a control to handle SDL. It is designed for Linux and for Windows. It is going to evolve in few time but published code will remain rather stable.

It includes also a SDLCtrl_demo, based in unodgs SDL demo, but inside a Ctrl, so it is in a window, it moves and resizes and the creation and destruction is internally handled so the programmer just have to program the video and audio. SDLCtrl supplies the remaining services.

The first intention is to be a base for a MediaCtrl to come soon. However SDLCtrl will include a C++ interface to many SDL possibilities.
Quote:

Functions4U_Gui.h:7
needs to read like this to compile it successfully for GCC:
(making Image ref a const one)
Sorry, I do not understand. Actually it compiles and runs without problem. However I will add the const to Image, it is more adequate.


Best regards
Iñaki
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29803 is a reply to message #29802] Thu, 18 November 2010 11:19 Go to previous messageGo to next message
kohait00 is currently offline  kohait00
Messages: 933
Registered: July 2009
Location: Germany
Experienced Contributor
ah ok, now i get it..

SDLCtrl is meant to be just as any other Ctrl, beeing able to be included in a usual win/linux application.

so what still remains is to have a native rendering backend for Upp on solely SDL, no matter win or linux, to render SystemDraw on SDLSurface.

i think your example will be a great deal of help in doing just that.
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29804 is a reply to message #29803] Thu, 18 November 2010 11:23 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 2944
Registered: August 2008
Veteran
Smile

Best regards
Iñaki
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29886 is a reply to message #29804] Sat, 27 November 2010 18:21 Go to previous messageGo to next message
mirek is currently online  mirek
Messages: 11814
Registered: November 2005
Ultimate Member
I have came to conclusion that what we need to do first is total separation of host platforms from the code, so that anybody can start developing ports without the need to edit CtrlCore.

So I decided to start soon "project Rainbow", that will do just this. I hope to start in Jan and be done within 2-3 months.

BTW, my motivations is even more ambitious - this will allow me to experiment with "ultra-thin" web apps, where all processing is done by U++ and displayed by Java on the client (alt. Flash or maybe even Javascript) in a way similar to Terminal Services. So basically developing app with web interface should be principally the same as developing normal 'fat' U++ app...
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29892 is a reply to message #29886] Sat, 27 November 2010 19:00 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1757
Registered: August 2008
Location: Czech Republic
Senior Contributor

luzr wrote on Sat, 27 November 2010 18:21

BTW, my motivations is even more ambitious - this will allow me to experiment with "ultra-thin" web apps, where all processing is done by U++ and displayed by Java on the client (alt. Flash or maybe even Javascript) in a way similar to Terminal Services. So basically developing app with web interface should be principally the same as developing normal 'fat' U++ app...

Do you mean something like this: http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/? (Just better, as it will be written in U++ Wink )

Anyway, such separation would be really great... It might also help a lot in (probably near) future when wayland server starts replacing Xorg.

Honza

[Updated on: Sat, 27 November 2010 19:02]

Report message to a moderator

Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29893 is a reply to message #29892] Sat, 27 November 2010 19:51 Go to previous messageGo to next message
mirek is currently online  mirek
Messages: 11814
Registered: November 2005
Ultimate Member
dolik.rce wrote on Sat, 27 November 2010 13:00

luzr wrote on Sat, 27 November 2010 18:21

BTW, my motivations is even more ambitious - this will allow me to experiment with "ultra-thin" web apps, where all processing is done by U++ and displayed by Java on the client (alt. Flash or maybe even Javascript) in a way similar to Terminal Services. So basically developing app with web interface should be principally the same as developing normal 'fat' U++ app...

Do you mean something like this: http://blogs.gnome.org/alexl/2010/11/23/gtk3-vs-html5/? (Just better, as it will be written in U++ Wink )



Yes. The question is at what level to do rendering. Above example simply passes changes in raster graphics. I believe that transfering "Draw stream" is more viable solution. I have done some preliminary experiments and have found that my current bussines application "full rePaint" produces Draw data that can be compressed to something like 5-8KB, maybe even much less (well, Image data are not in this, but after all, Images will be transfered just once...)
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29896 is a reply to message #29893] Sun, 28 November 2010 09:51 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 2944
Registered: August 2008
Veteran
Hello Mirek

So Rainbow package would be like Painter, but to be used in a web server to send Javascript to the client?. Would it include controls too?


Best regards
Iñaki
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29898 is a reply to message #29896] Sun, 28 November 2010 12:21 Go to previous messageGo to next message
mirek is currently online  mirek
Messages: 11814
Registered: November 2005
Ultimate Member
koldo wrote on Sun, 28 November 2010 03:51

Hello Mirek

So Rainbow package would be like Painter, but to be used in a web server to send Javascript to the client?. Would it include controls too?


No.

Actually, anything web related is "to be decided later".

What I want to do as "Project Rainbow" is CtrlCore host platform separation. That is a good prerequisite for framebuffer, SDL, MacOS X, Android and maybe "web terminal".

The important thing is that after the separation, all these technologies could be developed without edits to CtrlCore...

In other words, it will be possible to work on all these projects simultanously.
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29899 is a reply to message #29886] Sun, 28 November 2010 12:27 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1353
Registered: November 2005
Location: Poland
Senior Contributor

luzr wrote on Sat, 27 November 2010 12:21

I have came to conclusion that what we need to do first is total separation of host platforms from the code, so that anybody can start developing ports without the need to edit CtrlCore.

So I decided to start soon "project Rainbow", that will do just this. I hope to start in Jan and be done within 2-3 months.

BTW, my motivations is even more ambitious - this will allow me to experiment with "ultra-thin" web apps, where all processing is done by U++ and displayed by Java on the client (alt. Flash or maybe even Javascript) in a way similar to Terminal Services. So basically developing app with web interface should be principally the same as developing normal 'fat' U++ app...


That's a really really great news. Can't wait to try it in action. That would save me a lot of time. I could simply avoid creating web version of my app. Gtk guys use canvas and javascript - seems to be a good choice.
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29900 is a reply to message #29899] Sun, 28 November 2010 12:51 Go to previous messageGo to next message
mirek is currently online  mirek
Messages: 11814
Registered: November 2005
Ultimate Member
unodgs wrote on Sun, 28 November 2010 06:27


That's a really really great news. Can't wait to try it in action. That would save me a lot of time. I could simply avoid creating web version of my app. Gtk guys use canvas and javascript - seems to be a good choice.


Unfortunately, javascript appears to be to weak for RDP-like stream...

We would need at least Java to get what we want.

Plus, perhaps this technology will help in similar cases where Terminal services is usable, but would have big problem when your web latency is too high (just like with TS).
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29903 is a reply to message #29900] Mon, 29 November 2010 10:11 Go to previous messageGo to next message
Tom1
Messages: 612
Registered: March 2007
Contributor
Hi Mirek,

Should I understand your 'project Rainbow' as 'GUI abstraction layer', a package that exposes the GUI API of each supported platform in a unified manner so that the future CtrlCore always sees this as the same regardless of the platform? (This includes the likes of SystemDraw, message queue handling, window management, etc.. or what?)

The GUI porting efforts to different platforms would then essentially focus on this GUI abstraction layer, right?

Best regards,

Tom
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29904 is a reply to message #27207] Mon, 29 November 2010 10:32 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 793
Registered: November 2005
Location: Czech Republic - Praha
Contributor

yes, I think (actually I'm sure) this is what he meant.

[Updated on: Mon, 29 November 2010 10:32]

Report message to a moderator

Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29905 is a reply to message #29904] Mon, 29 November 2010 10:50 Go to previous messageGo to next message
mirek is currently online  mirek
Messages: 11814
Registered: November 2005
Ultimate Member
Yes. Basically, the goal is to to wipe out most of these #ifdef PLATFOM_ lines from CtrlCore. Except that I guess it still makes sense to have X11/Win32 implementations there...

Also, doing so, I think it even makes sense to make the system flexible so that more GUI modes can be available in single binary. I can imagine e.g. webserver that provides some diagnostics in Win32/X11 GUI...
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29908 is a reply to message #29905] Mon, 29 November 2010 12:56 Go to previous messageGo to next message
Tom1
Messages: 612
Registered: March 2007
Contributor
OK, I see.

Would it be possible to expose the platform graphics capabilities via Painter interface (possibly in addition to the conventional Draw interface) in this new 'GUI abstraction layer'? I mean in such a way that the Painter drawing primitives would be implemented using hardware acceleration if such is supported by the platform.

Best regards,

Tom
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #29912 is a reply to message #29908] Mon, 29 November 2010 19:08 Go to previous messageGo to next message
mirek is currently online  mirek
Messages: 11814
Registered: November 2005
Ultimate Member
Tom1 wrote on Mon, 29 November 2010 06:56

OK, I see.

Would it be possible to expose the platform graphics capabilities via Painter interface (possibly in addition to the conventional Draw interface) in this new 'GUI abstraction layer'?



No need. Painter interface already exists, you can already implement it in HW (other thing is that there is very likely no meaningful way of doing so, at least not with usual OpenGL - like graphics acceleration).

Mirek
Re: Porting Upp to SDL first ? (cause of MacOSX & framebuffer) [message #30235 is a reply to message #29900] Fri, 17 December 2010 12:16 Go to previous messageGo to previous message
zsolt is currently offline  zsolt
Messages: 576
Registered: December 2005
Location: Budapest, Hungary
Contributor
mirek wrote on Sun, 28 November 2010 12:51

unodgs wrote on Sun, 28 November 2010 06:27


That's a really really great news. Can't wait to try it in action. That would save me a lot of time. I could simply avoid creating web version of my app. Gtk guys use canvas and javascript - seems to be a good choice.


Unfortunately, javascript appears to be to weak for RDP-like stream...

We would need at least Java to get what we want.

Plus, perhaps this technology will help in similar cases where Terminal services is usable, but would have big problem when your web latency is too high (just like with TS).



What about HTML5 Canvas and the full duplex WebSocket API in HTML5 Javascript?

See ThinVNC as an example.

[Updated on: Fri, 17 December 2010 12:23]

Report message to a moderator

Previous Topic: U++ video control to come soon
Next Topic: Rainbow Framebuffer - theide running
Goto Forum:
  


Current Time: Thu Apr 18 13:06:27 CEST 2019

Total time taken to generate the page: 0.01104 seconds