| [ Return to Bugs & Features | Roadmap 2.0 | Post Text | Post File ]
STR #2424
Application: | FLTK Library |
Status: | 5 - New |
Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Unassigned |
Summary: | Google Native Client Support |
Version: | 2.0-feature |
Created By: | spoony |
Assigned To: | Unassigned |
Fix Version: | Unassigned |
Update Notification: | |
Trouble Report Files:
[ Post File ]No files
Trouble Report Comments:
[ Post Text ]
|
#1 | spoony 18:45 Oct 04, 2010 |
| fltk is very lightweight and it does widget rendering itself, it should be much easier to make fltk work as google native client library than other GUI toolkits like QT. If we can make fltk workable as google native client, any fltk application can also work under chrome OS and browsers. So fltk can play a critical role to migrate desktop applications to offline web applications, which could be the next big thing in IT. this FLTK's unique advantage could never be matched by QT or any other toolkit. Thanks a lot. Jim | |
|
#2 | spoony 08:28 Oct 07, 2010 |
| Google Native Client (from wikipedia)
Google Native Client (abbreviated as NaCl as allusion to Sodium chloride or common salt) is a sandboxing technology for running a subset of Intel x86 native code using software-based fault isolation.[1] Currently in an early development stage, it is proposed for safely running native code from a web browser, allowing web-based applications to run at near-native speeds.[2] Native Client is an open source project being developed by Google.[3] To date, Quake and XaoS have been ported to Google Native Client Platform. Native Client is supported on Firefox, Safari, Opera, and Google Chrome running on Windows, Mac, or Linux on x86 hardware.[2] An ARM implementation is now also available.[4] The x86 implementation of Native Client is notable for its novel sandboxing technique which makes use of the x86 architecture's rarely-used segmentation facility. Native Client sets up x86 segments to restrict the memory range that the sandboxed code can access. It uses a code verifier to prevent use of unsafe instructions such as instructions that perform system calls. In order to prevent the code from jumping to an unsafe instruction hidden in the middle of a safe instruction, Native Client requires that all indirect jumps be jumps to the start of 32-byte-aligned blocks, and instructions are not allowed to straddle these blocks.[5] Because of these constraints, C code must be recompiled to run under Native Client, which provides customised versions of the GNU toolchain (specifically, gcc and binutils). Native Client is licensed under a BSD-style license. Native Client uses Newlib as its C library, but a port of GNU libc is also available.[6] | |
|
#3 | spoony 14:51 Oct 19, 2010 |
| QT has a project for google native client too, it is called lighthouse. Maybe, we can port QT support to fltk. Here is the url: http://labs.qt.nokia.com/category/labs/lighthouse/ | |
|
#4 | spoony 14:59 Oct 19, 2010 |
| Here is an example that a QT application running in chrome/chromium. http://labs.qt.nokia.com/2010/06/25/qt-for-google-native-client-preview/ | |
|
#5 | spoony 15:17 Oct 19, 2010 |
| I did some research on FLTK2 and QT lighthouse, a QImage backend for QT lighthouse is about 147 lines of code. Google native client(pepper 2) may be more complicated. FLTK2 has a very good architecture for porting, we may only need to port messaging system, addline, addcurve etc. Could anyone familiar with FLTK2 internal shed some light on how complex to port? Thanks | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |