FLTK logo

Re: [fltk.coredev] RFC: API for screen sizes on mobile devices

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.coredev  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: RFC: API for screen sizes on mobile devices Albrecht Schlosser Sep 02, 2020  
 
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...

--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/f25e5c05-0272-48a1-56ce-6962fb2c6475%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.