Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I want to create a GUI driven application for a micro-controller (Atmel XMEGA) that is connected to a 128x64 dots graphics LCD (EA DOGL128-6) and 4 buttons for navigation.
Controlling the display itself (e.g. drawing pixels and characters) is no problem but in order to prevent me from reinventing the wheel I was googling for a GUI-Library/-Toolkit that is written in c, includes its source code, will run on a 32 MHz 8-bit micro-controller and provides at least the following controls:
panel (to group elements)
menu (scrollable)
icon
label
button
line-graph (optional)
But I didn't find any thing useful. Does anyone know (or better uses) such a library(preferably for free)?
I would consider rolling your own "immediate mode" GUI. Jari Komppa has a good tutorial about them. It's a lot easier than you may think, and you'll probably find most GUI libraries--even those targeting embedded systems--are a bit heavy-weight for your system.
If you insist on using a third-party library, below are a few I found. I've never used any of them and they are probably fairly expensive.
emWin
C/PEG
easyGUI
I personally used PEG (at work), but it is not for free. You just need to write a small layer of adaptation and use it. You can also look at Qt or minigui.
I also wrote a library which supports nearly any display technology: µGUI
http://www.embeddedlightning.com/ugui/
µGUI is a free and open source graphic library for embedded systems. It is platform-independent and can be easily ported to almost every micro-controller system. As long as the display is capable of showing graphics, µGUI is not restricted to a certain display technology. Therefore display technologies such as LCD, TFT, E-Paper, LED or OLED are supported. The whole module consists of two files: ugui.c and ugui.h.
This might be helpful as well
You should take a look at Contiki [wikipedia.org]
Besides being a small and elegant operating system for many 8/16/32-bit microcontrollers, it also features a GUI toolkit. It runs on the Atmel AVR!
For your convenience, here is a direct link to the The Contiki Toolkit (CTK) source code.
In addition to Judge Maygarden's list RAMTEX provide libraries specifically aimed at small graphic LCDs. Again not free, but is this is for commercial use, remember that if you did it yourself, it may take many man hours to achieve a polished product, so consider that before building your own.
At the rates my company accounts for my time (as opposed to my pay rate), if it took more than five hours, I'd be better off buying the Ramtex library (about two days if you only take my pay rate into account). If however you have the time and inclination, it is not a difficult task, and probably fun.
Rich Quinnell mentions
"... I saw a demonstration of Java applications running on an STM32-F3 MCU..."
http://www.microcontrollercentral.com/author.asp?section_id=1741&doc_id=253618
I guess it is what you are looking for?
Atmel (now owned by Microchip) actually makes a GUI library targeted at their microcontrollers.
This is part of the now called Microchip® Advanced Software Framework.
You may want to have a look at the Nano-X framework (formerly known as Microwindows): http://www.microwindows.org/
It claims to support down to a 16-bit DOS system, so I'm not sure if it's suitable for an 8-bit, but maybe the library can be pared down to just what you need.
I haven't used it, but at one point was considering looking into using it for some simple display UI (though on a 32-bit ARM system). Unfortunately, the project shifted gears before I actually did anything with it. I'd be interested in what your take on it is (or how well it works if you decide to try to use it).
We've started using easyGui and it seems good. You design the screens in a PC app then it generates the source code - making the design stage really easy.
It does most of the things on the list. Line graphs are coming soon. You can make up buttons pretty easily as reusable structures.
It comes with template drivers for lots of displays - depending on how closely the template matches your display (colour depth & interface are the biggest issues) you might be able to use the code unmodified or change it to suit.
I have been working on a similar project. Closest thing I could find are in the following links, but I doubt you will find a library with all the features you desire. These will only setup basic drawing functions, but it's a start. There are also some useful tools for bitmap converting and font creators if you dig around.
http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/glcd_dcf77/index.html
http://en.radzio.dxp.pl/
Almost everything else I have seen here is way overkill for what the poster seems to be asking for.
The CodeVisionAVR development environment now has graphical libraries for XMEGA.
The CodeVisionAVR C Compiler features a powerful graphic library for
LCDs with resolutions from 84x48 up to 800x480 pixels.
However, it is not free.
You can use the "Microchip Graphics Library" for free.
This includes GUI tool "Graphics Display Designer X" for designing screens and this outputs the "C" files for your designed screen.
I am using this tool which is very user friendly, but some of the widgets what you are looking you may not find.
Here is the link for GUI tool:
Click here!
NuttX is a real-time operating system for microcontrollers. The author has starting a developing some gui primitives for LCD displays for it.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
After some time coding in c in a simple console, I decided I wanted to try and code an actual Win32 application. However, upon selecting the option, the sheer amount of unknown code that surfaced on my IDE (Visual Studio 2013) just to open a blank window was overwhelming, as I don't understand half of it's meaning or even what to do, since, even simple printf commands yield no result... Can someone point me to a way to understand the differences between console and application? Or at least someway I can insert my current coding knowledge in an application environment?
Working with the Windows API can be quite the experience for a newcomer. The act of opening a window does, certainly, involve a lot of boilerplate code. The good news is a lot of that boilerplate rarely changes, and when it does it'll be for very special circumstances that you can go research. That's why Visual Studio spits the whole mess out for you by default.
There are plenty of resources to learn with, including Microsoft itself: https://msdn.microsoft.com/en-us/library/bb384843.aspx
To help situate you, understand that a lot of what you're looking at that's probably confusing are typedefs used on primitive types. This helps maintain backwards compatibility with programs created for older versions of Windows, and adds semantic meanings to types. A lot of the preprocessor stuff you see in header files is actually conditional compilation - it's checking what environment you're compiling in, what version of Windows, etc. and then providing the correct typedefs so that what actually compiles works on the desired Windows platform. Stuff that's greyed out in VS2013 is stuff that Intellisense sees isn't going to be compiled based on the current #defines and a lot of it may be relatively ancient. A big part of the Windows API for a long time was a strong desire to not break backwards compatibility. This was a huge advantage for Windows, because it means my program you wrote for Windows 3.1 isn't going to be hosed by Windows 95 rolling out. Or XP, 2000, Vista, 7, 8, 10, etc. It does mean a lot of stuff makes it into the API and stays there.
They try to hide a lot of that in the headers, but you'll also see deprecated input variables to functions and the like (this parameter should always be NULL...etc), and you just have to read the documentation. Thank the internet.
For example, an LPCSTR is just a const char*, but the LPCSTR signifies that it's a null-terminated constant string. In fact, you may see that's it's not a const char*, but a CONST CHAR* where CONST and CHAR are #defines themselves to make sure the correct keywords and types are used. In your case it'll probably end up being just normal const char*.
My suggestion, rather than diving into about as complicated a C-API as possible, is to look at something like SDL. SDL is a much simpler C API designed to provide an interface to the operating system's windowing, graphics, and input, while hiding the dirty details of the API, be it Windows, Mac, or Linux. https://www.libsdl.org/
It uses openGL for its graphics. If you're making any kind of game you'll be using some kind of graphics API to talk to the video card. The native Windows graphics API is DirectX, but openGL is the very commonly used cross-platform API. Both APIs allow you to make use of a computer's video hardware to render graphics.
Edit: I'll add, since I went off and voiced an opinion on libraries, which is why these types of questions are probably frowned upon, that I think it's fair to say that SDL is the de facto standard for C third-party multimedia libraries. Also commonly mentioned is SFML, which provides much the same functionality but is more object-oriented and written in C++.
In Visual Studio, when you create a win32 app project, click on next, and click on empty project. This will eliminate all the stuff that Visual Studio creates for a win32 app, but then you start with no files. You'll probably want to start with some simple example C program for windows from a book or web site.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm looking for a reasonably cross-platform way to render windows and widgets and style them the way I want without losing the ability to interface with the OS-preferred ways of doing things like redrawing or text input. I am also keen on knowing how Photoshop did this on Windows, as a concrete example.
I'm writing a program primarily for myself but I want to leave open a possibility to share it with others afterwards if it would be useful for more people. I want to really customize its look-and-feel but would like to keep it using native GUI libraries, such as windows forms or something more specific than just rendering my inerface to X11 windows. As I have to use it both on Windows and X11 the solution would preferably be cross-platform but I'm ready to implement multiple UI front-ends if needed, too, if it would provide reasonably consistent looks on both systems. OSX support is a plus, but really far from mandatory. I don't see myself porting this to OSX quite yet. I have barely started.
The reason I want theming is simple: I like dark themes because they are very relaxing to my eyes. On Windows, Microsoft Visual Studio and Adobe Photoshop (Photoshop as the only one and VS by default) display a dark theme and I find it enjoyable to work with these pieces of software for the sole rest that my eyes get. However, both of these, as it seems, use Windows' native controls (I can get to individual widgets in these using Hawkeye and they seem to have descriptive class names, consistent with what they represent).
I see this done way more on Windows than on X11 systems (GNOME, KDE, XFCE on GNU/Linux), maybe because Windows' theming is as rigid as it can get and on X11 window managers and GUI toolkits (KDE with Qt comes to my mind) are really flexible at that so apps needn't implement their own styles when the user can choose them DE-wide quite freely.
I didn't really do GUI programming at all before so I feel a little lost. I would like to refrain from drawing all GUI in a window with an OpenGL context, because I like the idea of the OS drawing legible, subpixel-level text for me, according to the users' settings, and handling partial window redraws instead of full ones. I would also like to integrate with the operating system with, for example, text input. As I said, I would like to share the software some day, so it'd be nice if I don't have to make fundamental changes beforehand.
I'm using C for core code as I've grown tired of futile OOP (whose most benefits I fail to understand if I'm the only one working on the project) with C++ and just want to write code, but I see that GUI libraries for C are in deficit, so I'm ready to write the GUI front-end in another language and link it against my C object files.
Bottom line, to focus on a multiplatform example, how does Photoshop go about redrawing native Windows widgets? I see it looks very consistent on Windows and Mac. Supporting X11 would be less of a problem, as I wouldn't force my styling in the X11 version, just proxy all through a standard widget library (Gtk+? Qt?) and let the desktop environment/window managers/whatevs style it for me. Though I don't know enough on how window and widget management works on GNU/Linux desktop environments to make assumptions.
Thanks in advance.
NOTE: This is purely anecdotal and based upon my own assumptions.
Due to Photoshop's age, I would assume it uses its own custom, proprietary GUI toolkit. It may use the underlying OS's native toolkit but more than likely it just mimics the look and feel. I know Sublime Text uses a custom toolkit made by the developer.
I have made simple applications with .NET, GTK (PyGTK), and Qt (PySide). If you want to support multiple platforms I'd really recommend using a cross-platform toolkit instead of writing the GUI specific to each OS because of the amount of work involved.
I liked .NET but it's not really cross-platform (I'm not sure what all is supported by Mono).
GTK2 (via PyGTK) was fairly straight forward to us. It looked good on Linux (Ubuntu) but I could not get some custom styles working properly in Windows (unless Windows 95 looks good). I also found PyGTK's documentation lacking. GTK3 is the way forward, but last I knew it was still under heavy development and isn't stable on Windows (yet).
I will say I liked Qt (PySide) the best. I found its documentation and examples better than GTK's. It supports native OS themeing along with custom styles and themes (I don't have personal experience with this though). By default it looks native on both Windows (XP and 7), and Linux (Ubuntu).
I have no experience with wxWidgets so I have no say on it, but it is cross-platform.
I would recommend looking into using Qt, though you would have to use C++ (or a higher-level language with available bindings).
Problem
Having grown tired of writing functions to move sprites and characters diagonally and assigning keys that do not flow with the 4 main directional keys(UP, DOWN, LEFT, RIGHT) such as W,A,S,D is a bit of a drag and a bore. However i recently got this usb controller http://www.logitech.com/en-us/gaming/controllers/devices/288 and i would like to be able to add its usage to my console based games or windows applications. AS it has the analog sticks that support comfortable diagonal movement.
Workaround/Possible Solution
There is a fair amount of documentation on doing this in C# but i am more comfortable in C and know next to nothing about C#.
Question
Is it possible in C without additional libraries and if so how can i could use the usb controller support in my programs(and add the functionality to my future projects). Any resources or tips are much appreciated. Linux or Windows solutions are welcome. thanks in advance.
If you are using Windows you may try Direct Input, or XInput it has excellent support for Joysticks and GamePads. It is also used in XBox development. Many Game Projects use this, here is a complete list
Another good option is SDL, it has adequate support for GamePads (which is built on top of DirectInput on Windows Systems) and is Platform-Independent , so that may be an advantage. Also I think Allegro supports them, but I'm not sure.
NOTE: Sorry, if you don't intend to reinvent the wheel and write a driver and api for every damn GamePad in the market, you'll have to use an additional library.
I have a C# app that I've managed to get working with Mono and running on OS X. The application itself runs just fine, but it doesn't really look all that good when run on OS X. The button fonts look jagged, and many of the default features that are there for the Windows 7 version aren't present. To me it sort of looks like a Win98 application with an OS X top border taped to it.
I'm looking into possibly learning Objective-C so that I can write 'proper' OS X apps, but for the moment I'd like to be able to get my projects working on an Apple without having them look Frankensteined together.
Is it possible to convert a WinForms app over to Cocoa? Is Cocoa the correct interface to use?
If possible, what's the best way to go about it, and do any of you know of a good tutorial/writeup on the process to get me started? It'd be nice to see something that actually shows the process being done. I learn far more from example code along with a short explanation than I do from a generic article.
Thanks again!
If you want to create a native looking OSX application, you are correct that you want to use Cocoa. If you still want to use C#, you can use MonoMac.
MonoMac allows you to build your GUI natively on OSX (in fact, using the Interface Builder shipped by Apple), but allows you to write your app in .Net/C#. This way you can continue to use your existing application logic and only have to change the GUI code.
It's pretty much universally true that a ported app will always look like a ported app. Even large companies with huge budgets can't pull off anything better (I cite Adobe - what a mess).
Slapping a Mac face on a Windows app port will show its seams. If you want the application to behave like a native application (and take advantage of the performance-related goodies the platform offers), the absolute best approach is to use the architectural documentation, specs, and requirements I know you have - conscientious developer that you are - to adapt the design to the native platform. That's the Cocoa Frameworks (the API), which are written in Objective-C (the language).
There's quite simply no other path that doesn't end with a crappy-looking port that's riddled with bugs and behavioral problems born of the porter's insufficient familiarity with the target platform. This isn't just limited to Mono/C#-to-Cocoa/Obj-C. The opposite is just as true. Even Java-for-PlatformA-to-Java-for-PlatformB ports of desktop apps suffer these problems. Start with a solid architecture and build for the platform if you want the best user experience.
That said, you're already a step ahead by realizing this and wanting to do better. Bravo! :-) Though I don't know of any tutorials for this path, I'd suggest even that's not the correct approach since you indicated you're looking for quality. Avail yourself of the many Cocoa books and many more online communities (like this one) and learn the platform before committing to your Cocoa-adapted architecture and code base.
Update based on comment debate
To be clear: I'm not saying there's no way or that there's no tool out there that makes it possible. There're actually plenty I've seen but don't recall and won't bother googling. My point remains: the OP is concerned with quality of native appearance (and I assume behavior and possibly performance) and porting tools / translation layers don't achieve this due to inherent differences in the platform's architecture and user experience idioms. The OP suspects it might be best to learn the platform and build specifically for it and I'm agreeing. Your opinion may vary. Have at it.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I need a simple graphics C library to use on a device where I will be writing directly to the frame.
The frame is located in regular memory.
There is no graphics acceleration hardware.
Nothing fancy. I just want to be able to draw lines, circles, OSD stuff like strings as well.
It would be nice to have functions that use good, lean algorithms (my CPU is an ARM9 running at 400MHz).
What are some recommendations for this?
For very simple needs (lines, circles, polygons, text) I have always just made my own. Check out bresenham's algorithm for lines and circles, Wu's modifications for antialiasing on circles and lines.
Gimp will output C code for images, which is what I do for fonts, and drawing them is pretty easy. I have used anti-aliasing (gimp --> grayscale, use the grayscale value as the alpha), but haven't done proportional fonts. They aren't much harder, and can make the display a bit nicer, but I haven't needed them yet.
Polygons are simply multiple lines, and filled polygons are quite fun to implement.
It's not a lot of work, and you'll grow from the experience.
If, however, you decide you want to render SVG or some other complex vector language, then a library is in order. But for simple things, this isn't complex.
-Adam
I'd like to second OpenGL, especially the OpenGL|ES variant.
Here is a link to a Software based OpenGL-Renderer: http://sourceforge.net/projects/ogl-es
I've spend the last three years writing commercial software rasterization codes on ARM9 and similar processors, so I think I can comment on use of cairo and other high level APIs:
They work very well and are incredible powerfull, but on a target as limited as an ARM9 you will never be happy with the performance. The graphic libs are written with your typical Desktop PC in mind, and they trade precision for performance. This is nice for high quality SVG rendering, but to slow on a humble ARM.
The Vincent OpenGL|ES I've suggested above has a on the fly dynamic code generation engine for ARM-CPUs in place, so you get almost the performance of hand-optimized assembler code.
If you can limit yourself to just one bitmap-format, just two blend-modes and a hand full of rendering primitives you may get better performance by writing a dozen of render-routines yourself. Depending on your experience and requirements that can take anything from two days to a month though..
Cairo is pretty powerful and easy to use. I think Mozilla uses it as the basis for the <canvas> element and the SVG renderer.
From your requirements it appears you need something like an embedded framebuffer library (or whatever it is called). I played around with some of the following a few years back for an embedded browser (which didn't make it to the market). Unfortunately, I can't remember much to give you any analysis. Have a look:
DirectFB
GTK/X (or a port using directFB)
Cairo (as another poster has suggested -- this is very powerful)
Also, this article may be of interest.
Try SDL. From the web page:
Simple DirectMedia Layer is a cross-platform multimedia library designed to provide low level access to audio, keyboard, mouse, joystick, 3D hardware via OpenGL, and 2D video framebuffer. It is used by MPEG playback software, emulators, and many popular games, including the award winning Linux port of "Civilization: Call To Power."
OPenGL has a set of 2d functions, not sure if it is too bloated for you or if it can be trimmed down. It is written in C, at least.
I found the Adafruit GFX library to my liking.
Very very simple and basic:
https://github.com/adafruit/Adafruit-GFX-Library