|
|
I see that com.buglabs.bug.module.lcd.pub.IModuleDisplay.getFrame() returns an AWT Frame, and that FlickrUppr is using standard AWT components to create its display. I can see how that can work in the emulator, but for real hardware I would expect that there would need to be restrictions based on what the LCD component you go with can support (or components if you’re planning of having different kinds of LCD). Will there be guidelines as to pixel height/width of the display, colour support, font support, etc? |
|
|
Finsprings, great question. The way we see it working, each physical display will be represented as a service and will expose various aspects, such as resolution and bit depth. We currently are not exposing that information but plan to shortly. Specifically each display attached to a BUG will be represented as a framebuffer and an OSGi service. At the OSGi level, applications will be notified of the display service and it’s characteristics. |
|
|
I was mulling just this topic earlier today – it may be a little soon to be asking questions like this, but how will the BUG handle two applications that are not necessarily aware of each other, both requesting the same display service? |
|
|
Koolatron, Well, currently we expect to be running a window manager. Each application that requests a Frame from the display service will receive a full screen frame. The window manager will be responsible for dealing with which application is visible. |