mirror of https://github.com/fltk/fltk
Update README.Pico.txt
- fix typos and minor, obvious errors - reformat small parts - remove trailing whitespace
This commit is contained in:
parent
c12408b53f
commit
4c9b44f01e
|
@ -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
|
||||
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue