On 04.08.2012, at 14:15, Ian MacArthur <[email protected]> wrote:
>
> Oh yes - me too! I'd love that.
> Not sure Apple will go for it though
App Store Review Guidelines from 2010, excerpt. I believe they went more
strict, but I don;t have dev access anymore... .
10. User interface
• 10.1 Apps must comply with all terms and conditions explained in the
Apple iPhone Human Interface Guidelines and the Apple iPad Human Interface
Guidelines
?? For FLTK, this would currently be hard to achieve.
• 10.3 Apps that do not use system provided items, such as buttons and
icons, correctly and as described in the Apple iPhone Human Interface
Guidelines and the Apple iPad Human Interface Guidelines may be rejected
>> "May" be rejected. So if FLTK annoys Apple, they could ban our users.
• 10.6 Apple and our customers place a high value on simple, refined,
creative, well thought through interfaces. They take more work but are worth
it. Apple sets a high bar. If your user interface is complex or less than very
good it may be rejected
>> Of course, all FLTK user interfaces are fantastic... .
I have spent a few sleepless nights on this a while ago. Not sure if I publishd
this before, but here are my thoughts:
FLTK needs almost no OS resources to run! At the minimum, FLTK needs a way to
wait for an event (sleep, timer), some kind of input, like a touch screen or a
bunch of buttons, and some array of pixels. Almost all other functionality is
derived from these four basic functions:
- sleep until event
- timer
- read some keyboard and/or positioner device
- set a single pixel to some color
1: These functions are all available on the simplest graphics devices, even
with NO OS available at all! This is enough to run a single app in a single
window. Find a Microcontroller with one 512k or ROM and 200k of RAM and you can
run a graphical FLTK app already ;-)
2: Assuming we can set up a driver system for Fl_Windows, just as we did for
drawing, we could allow multiple windows, managed by the app, not requiring a
window manager on the host. Think about running FLTK apps on a Raspberry using
only the BIOS - no need to load Linux. Embedded development on very small
devices ;-)
3: Now if we have an OS available, and the ability to fork and to do
interprocess communications. With a setup as above, FLTK could provide a window
manager (Bill wrote one ages ago) *and* the application interface.
So after all this theory: if we write the code needed to reach (1), we can port
FLTK easily to any platform available, as long as we can find those four
minimal interfaces!
My example would be running on Android. Android requires apps to be in Java (up
until Android 4, IIRC), but Java can call native libraries. A minimal Java app
would provide the four interfaces discussed above, and the FLTK app would be
wrapped together with FLTK itself inside a native library, called from Java.
In true FLTK fashion, the app programmer would never touch a single line of
Java code. The same would work for iOS, or PalmOS, or PocketWindows, or
whatever else is out there.
> <OT>
> In other news - I recently acquired a brand new, still in the retail
> packaging, been sitting in a warehouse for over a year, Palm (aka HP) Pre3:
>
> Matt, any chance of an Einstein port, then? ;-)
If you can run FLTK on it, you can run Einstein ;-P .
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
