I'd like to see an official lightweight GUI library for the online compiler. Preferably driver-independant so users can code their own display drivers. That way, all display projects could use a common API for creating GUIs, instead of having separate libraries and APIs for every display like it's done now. I had hoped to build something like this with my NeatGUI project, but I haven't had the time to finish it. I have some experience with other embedded GUI libraries, and I find the lack of standardization to be very frustrating. Each library has it's own font format, and it's own image format, etc. With an official GUI library, the mbed platform would be much more applicable to development boards with onboard displays, since only a display driver would need to be provided.

A good idea, some random stuff:

I don't expect this will be done by mbed staff, so it is something for users to do.

Then afaik most of the current LCD libraries use something like this one does: http://mbed.org/users/star297/code/HY-1_8TFT_ST7735/. They already do use a 'standard' GraphicsLCD class, but that is just two files, a first step could be making that into a proper library and ask the owners of those libraries to use that one, so they are forced to be equal to each other (That isn't too much work for the owners). Then you already got all the basic stuff covered (circles, lines, fonts, etc).

Would then NeatGUI add more than what is in the GraphicsLCD class? I scrolled through it, and saw already some stuff like triangles, but that could also simply be added in GraphicsLCD. I could imagine also stuff like buttons, check boxes, etc. But then an option would be to make a class that takes a pointer to a GraphicsLCD in its constructor, and uses the functions it knows will be there to draw stuff.

So the TL;DR comes down to: Good idea, but wouldn't it be easier to start with GraphicsLCD? And then mainly not because it would be better than NeatGUI, but it is already there in many.

Improving GraphicsDisplay would be a good idea. NeatGUI grew out of a C GUI library I was working on for a project at work, that's why it has all the graphics primitives. However, GraphicsDisplay doesn't seem to be a real library, just a class that's been passed around. There's nothing really encouraging new developers to use it. I didn't even realize it existed when I wrote my library.

I just find embedded GUI development to be very frustrating. For instance, I have access to emWin since I'm using NXP microcontrollers, but since it's precompiled it takes about 40KB of flash to print text on a monochrome OLED display. And to try to find something else that's just as capable, but still free is impossible. I just think if mbed had an officially supported GUI package like the official RTOS and USB packages, it would be a lot easier to develop graphical applications. Heck, it could even integrate with mbed-rtos to do window management.

You are right it isn't a real library, but that is something that can be changed quite easily ;). Especially because quite a bit of them already use it (Nokia-LCD is the big one who doesn't, but that can of course be done). Then it is just a matter of sending a PM to the owners of the libs if they can switch it, and making a nice cookbook/wiki page for it.

I agree it would be nice if it was official (and easy :P), however I doubt realistically it is going to happen anytime soon by the staff. I really like mbed, but one thing I learned is that if you want something to happen, do it yourself :). emWin isn't really a realistic option for this, not only because it is limitted to NXP microcontrollers, but also because manually having to follow a list of actions to import it isn't exactly user friendly.

Current ones should out of the box work with mbed-rtos. Problem is they all block while writing stuff to their screen. But that isn't easily solved.

GraphicsDisplay repository and Team created. Feel free to join.
Please start future questions and discussions at the team and repository pages.

I'm among those that have been developing a "derived" library - mine for the Raio RA8875 display controller. I started out on "same API", but slowly evolved toward "similar, but different". I'd throw in to work toward a common solution for more portability.

Before a few thousand lines of code show up, should we pause a moment to ponder requirements? I have some thoughts based on my own work, and others may have already worked through some of the issues, so for now just helping spur the discussion -

• It would be easy to leverage one of the existing API models and migrate it forward, or is there some other graphics lib to pattern after that would make more sense?
• What is the range of displays to try to support? How low-end and how high-end?
• Graphics "primitives" only, much like the current libs?
• Another pattern to extend with various widgets?
• Performance pinch-points (polled vs. more pins for interrupt handshake)
• Great care in RAM usage is obviously important.
• Optional touch-screen
• Optional keypad
• Power management
• Consistent pattern for API names, parameters, etc.
• Resource locking comes to mind - a SPI port (for example) may be shared between a display and a micro SD.

Tossing in my disclaimer that I'm a little better at reading C++ than writing it:

• A general purpose library may implement Bresenham's line drawing in code, but the RA8875 controller (for example) has many primitives built in to its hardware, so you simply pass the end points and command it to draw the line. I guess the right C++ design pattern will exclude the "dead code" in projects that use the driver for this controller?

And then there is -

• Bare-metal vs. integrated with mbed-rtos?
• Or should it align with what is now lurking not too far in the future - mbed 3.0?