BUG Community

Welcome! Log In

Forums BUG SDK UI Features

Subscribe to UI Features  4 posts, 3 voices

Log in to reply to this topic
Sep 26, 2007 10:55pm
Medium Bug Labs team finsprings 268 posts

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?

Sep 28, 2007 2:29am
Medium Bug Labs team kgilmer 215 posts

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.

Sep 28, 2007 10:49am
Img_missing_medium koolatron 52 posts

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?

Sep 28, 2007 8:36pm
Medium Bug Labs team kgilmer 215 posts


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.

Log in to reply to this topic
Forums BUG SDK UI Features

Powered by Community Engine