Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Trying to make Pico work after Surface driver addition.
git-svn-id: file:///fltk/svn/fltk/branches/branch-1.3-porting@11302 ea41ed52-d2ee-0310-a9c1-e6b18d33e121
- Loading branch information
Matthias Melcher
committed
Mar 6, 2016
1 parent
a22cc41
commit 7e2dc9d
Showing
2 changed files
with
84 additions
and
12 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,72 @@ | ||
|
||
This documentation will explain how to quickly port FLTK to a new | ||
platform using the Pico driver system. For now, only the sample | ||
SDL Pico driver on OS X compiles and barely runs. | ||
|
||
cmake -G Xcode -d OPTION_APPLE_SDL=ON ... | ||
|
||
tl;dr - the recent commit should be transparent to all developers | ||
on other platforms. On OS X, the CMake setup add the option OPTION_APPLE_SDL=ON | ||
that will run FLTK on top of SDL, which in turn runs on top of the | ||
new "Pico" driver set. | ||
|
||
The greatest help I can get form the core developers is to continue | ||
to refactor the platform specific functionalities into the drivers. | ||
|
||
--- | ||
|
||
OK, long version. I know that I am repeating myself and I don't expect | ||
those of you who "got it" weeks ago to read this again. Writing this | ||
down is also for me to avoid losing track ;-) | ||
|
||
Goal 1: find all the stuff that must still go into drivers | ||
Goal 2: have a base driver for all future porting efforts | ||
Goal 3: make porting fun with early gratification to the coder | ||
Goal 4: extensively document a sample port (SDL), and how to improve it | ||
Goal 5: use SDL as a base library, thereby porting FLTK to iOS and Android | ||
|
||
|
||
This is the start of a new driver, named "Pico". "Pico" is here to | ||
implement what I called the minimal driver. | ||
|
||
"Pico" implements (eventually) a complete set of drivers. The drivers | ||
will be limited in functionality, but they will be good enough to | ||
allow basic UI's with most FLTK widget types. | ||
|
||
If "Pico" compiles without any "USE_PICO" or similar defines, we | ||
have reached goal 1. | ||
|
||
"Pico" will implement all driver functionalities "in good faith", | ||
meaning, in a way that FLTK runs without crashing. Only very very | ||
basic functions are not implemented. A driver that derives form "Pico" | ||
needs only to implement those missing functions, thereby reaching goals | ||
2 and 3. As far as I can tell, those will be: | ||
|
||
- open a single fixed size window | ||
- setting a pixel in a color inside that window | ||
- polling and waiting for PUSH and RELEASE events an their position | ||
|
||
By implementing these three simple functions in the SDL driver, | ||
"test/hello" and quite a bunch of other tests will run (yes, they | ||
will be slow, but the will work). | ||
|
||
This will give the person who is porting FLTK to their platform a | ||
very early confirmation that their build setup is working and a | ||
very early gratification, reaching goal 3. | ||
|
||
Obviously, SDL is much more powerful, and by the nature of the | ||
virtual functions in the driver system, we can incrementally add | ||
functionality to the SDL driver, and document this incremental | ||
nature, reaching goal 4. | ||
|
||
If we do all this right, we have goal 5. | ||
|
||
If SDL is too big or complex for, say, Android, we can simply start | ||
a new native Android driver set by implementing the three functions | ||
mentioned above, and then go from there. | ||
|
||
|
||
- Matthias | ||
|
||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters