On 9/2/20 10:21 AM 'melcher...' via fltk.coredev wrote:
> I am hoping for a good idea to manage screen size on Android. The
> physical resolution and density can be pretty much anything (for
> example, the Galaxy Note 10 Plus has 6.8-inch at 3040x1440 pixel), but
> apps are often written for a fixed scale and can request a different
> pixel buffer resolution that is then scaled up by hardware at screen
> refresh time.
>
> Also, there should be an API to limit apps to landscape or portrait mode.
>
> I was thinking about something like:
> Fl::hint(FL_MOBILE_DEVICES, FL_SCREEN_LANDSCAPE_ONLY);
> Fl::hint(FL_MOBILE_DEVICES, FL_SCREEN_LANDSCAPE_WIDTH, 1024);
>
> Device: MOBILE, DESKTOP, ...
> Screen: LANDSCAPE_ONLY, PORTRAIT_ONLY, LANDSCAPE_WIDTH/HEIGHT,
> PORTRAIT_WIDTH/HEIGHT, ...
>
> This API avoids #ifdef __ANDROID__ and can be extended later without
> braking the ABI. Unsupported hints are simply ignored.
I'm -1 on such API's as Fl::hint(int, int, int...). They are confusing
and hard to implement (need switch(..) etc.). Also, extension of the API
using other datatypes would be possible but less obvious.
I'd propose to introduce a new (static?) object type like Fl_Screen or
similar with virtual methods that can easily be extended (one method per
logical function). The methods above could then be:
Fl_Screen::format(FL_SCREEN::LANDSCAPE_ONLY);
Fl_Screen::landscape_width(1024);
or (the latter):
Fl_Screen::width(FL_SCREEN::LANDSCAPE, 1024);
Fl_Screen::width(FL_SCREEN::PORTRAIT, 600);
The device type would not be necessary because it would be "known" by
the (virtual) method implementation.
As proposed by you, such virtual methods would be ignored (i.e. not
implemented at all) on devices that don't support them. The base class
would implement a sensible default.
This is consistent with the current driver model and getter methods
would be very simple to call, supposedly only in driver related code parts.
Just a thought...