mirrors/fltk
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Update README.Pico.txt

Browse Source 
- fix typos and minor, obvious errors
- reformat small parts
- remove trailing whitespace
This commit is contained in:
Albrecht Schlosser 2020-06-02 14:47:14 +02:00
parent c12408b53f
commit 4c9b44f01e
1 changed files with 29 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

60
README.Pico.txt
View File

@ -1,24 +1,25 @@
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.
platform using the Pico driver system. For now, only the sample
SDL Pico driver on macOS compiles and barely runs.
> mkdir build
> cd build
> mkdir XcodeSDL
> cd XcodeSDL
> 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
tl;dr - the recent commit should be transparent to all developers on
other platforms. On macOS, the CMake setup adds '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
The greatest help I can get from 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
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
@ -28,47 +29,44 @@ 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
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.
"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
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
"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 from "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
- polling and waiting for PUSH and RELEASE events and their positions
By implementing these three simple functions in the SDL driver,
"test/hello" and quite a bunch of other tests will run (yes, they
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
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
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
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