|
|
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 |
|
kohait00
Messages: 939 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
http://www.libsdl.org/faq.php?action=listentries&categor y=7
so seams like SDL supports the Cocoa API already. best for us
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 #29892 is a reply to message #29886] |
Sat, 27 November 2010 19: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++ )
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 |
|
mirek
Messages: 14039 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++ )
|
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 #29899 is a reply to message #29886] |
Sun, 28 November 2010 12:27 |
|
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 #29903 is a reply to message #29900] |
Mon, 29 November 2010 10:11 |
Tom1
Messages: 1242 Registered: March 2007
|
Senior 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 #29908 is a reply to message #29905] |
Mon, 29 November 2010 12:56 |
Tom1
Messages: 1242 Registered: March 2007
|
Senior 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 #30235 is a reply to message #29900] |
Fri, 17 December 2010 12:16 |
zsolt
Messages: 698 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
|
|
|
Goto Forum:
Current Time: Sat Sep 21 02:52:34 CEST 2024
Total time taken to generate the page: 0.03976 seconds
|
|
|