Joel Bodenmann

You misread the code that I posted (and probably the explanation/legend I posted below the code snipped). Just translate it to pure C code: void widgetSetParent(GHandle widget, GHandle newParent) { gwinHide(widget); gdispFlush(); // This is optional and only required in certain driver scenarios to prevent artifacts from showing up. widget->parent = newParent; gwinShow(widget); }

Yep, that seems correct. I remember that I left of pretty much at that point. I still wish to finish it at some point. If I remember correctly it's like 95% done. The segfault should be easy to track down as it will be either a buffer allocation or an array index overflow.

The spinbox in that branch is made for nummeric values, not texts

Glad to hear that! The online font converter tends to be down quite a lot (we currently have about 80% availability on the statistics). The reason for that is because we're hosting quite a lot of servers (µGFX is a spin-off of an already existing engineering company. We're running a lot of stuff for different projects and also customers. Whenever we do any kind of migrations, changing environment or doing any other kind of modifications we test everything in a test setup. Once we feel comfortable we always move the µGFX online font converter first as it's a pretty good reference server (it uses a few different technologies) which allows us to test everything from simple backups to load balancing and high availability systems. It's just that the online font converter is the perfect balance between "not critical infrastructure" and "people actually use it" which is just awesome for testing everything before touching real production environments.

Hi, We are manually moderating all git server registrations. This process will change with the release of µGFX 3.0. For now, just let us know your registration username or e-mail and we'll manually validate your account (feel free to PM so you don't have to share any info on this public forum).

I'm standing between doors right now so I haven't checked your actual code yet, but let's work our way through the basics: Did you use the debugger to check whether the system is halting somewhere? Are you getting the µGFX logo to show up but you simply don't get your own stuff to show on the display (make sure that the startup logo option in the configuration file is enabled)? Did you check that the integration is actually working? You might want to run one of the GOS demos to confirm that stuff like software timers and threading is working correctly

That doesn't matter. As I said it's code from a wrapper around the normal uGFX window.

That sounds great! I'm looking forward seeing that widget You simply add the function to the widget's VMT which handles incoming dial events - simple as that! --> https://wiki.ugfx.io/index.php/Creating_a_widget#VMT

If you need information on multiple display pages the recommended way of doing things is making the page container smaller and adding the widgets that display the required information within the area not covered by that display page. There's an example of a statusbar widget in the download section. If that is not possible (eg. due to how the UI is designed) you can actually change a widgets parent container. Here's a code snipped of a C++ wrapper class that is used inside the µGFX-Studio to accomplish this: void UGfxWindow::setParent(const UGfxContainer* parent) { // Sanity check if (!_ghandle) { return; } // Sanity check if (!parent || !parent->handle()) { return; } // Change parent container gwinHide(_ghandle); gdispGFlush(_ghandle->display); _ghandle->parent = parent->handle(); gwinShow(_ghandle); } _ghandle is an attribute that is simply the GHandle of the µGFX window. Similary, parent->handle() is the GHandle of the new container.

The board file is completely specific to each application. The existing ones are more of templates and examples that anything else. You're supposed to copy them to your application folder and modify them to fit your needs. If you have an updated/improved board file for a supported board file we'd appreciate it if you could share it. Most of them were not created by ourselves so it's likely that there's a lot of room for improvement. No need to feel bad at all Thank you for the feedback - glad to hear that!

Also check out the documentation (wiki) on how you can store calibration data which is loaded automatically so you don't have to perform calibration every time you launch the application.

Hello Tobias and welcome to the µGFX community! There's no technical problem here. Most likely that example uses the touchscreen in Pen mode. There are two modes that a touchscreen driver can run in: Finger mode and Pen mode. There's no functional difference. The only difference there is is that the Finger mode is a lot less strict when it comes to moves and calibration error. Basically you need to press the calibration crosshairs a lot more precise in the Pen mode. I'm currently on the road so I can't easily check but there's some API call which allows you to switch the mode. However, calibration takes place in gfxInit() and you cannot change the mode before that, only after the µGFX library has been initialized. Therefore, you need to change the default mode. That's a driver configuration so you need to look at /drivers/ginput/touch/<driver_name> and check whether you can do it in the drivers configuration file. If not, have a look at the VMT (struct) in the drivers implementation.

We cannot help you while you keep ignoring our posts. You can always come back once you have specific questions that we can answer.

Hi, You can use any font you want with µGFX. Therefore, you can just use a font of a different size. The font converter allows you to use any TTF and BDF font you can find which you can render to any size. Here's the corresponding documentation: https://wiki.ugfx.io/index.php/Font_rendering#Adding_fonts There are four ways to encode a font: Use the online font converter (currently unavailable) Use the font converter inside GFX-Studio Use the pre-compiled font converter that comes with the library Compile the font converter yourself from the source that comes with the library

Yep that's often done in applications. That's definitely a proper way to handle things. In fact, the µGFX-Studio does that internally as well.

What do you mean by overlapping? The statusbar is a widget and can therefore either be in a container or not. It cannot be half way in one. Can you please show screenshots/mockups of what you're trying to achieve? A statusbar is usually not part of a page container as it's always visible.

Hello & welcome to the µGFX community! The reason that you're not finding any information like this is because it's very difficult to provide them. The µGFX library has been designed to be lightweight as possible. Keeping resources down to a minimum is one of the main goals (like having a completely cross platform (agnostic) library)). Therefore, everything in µGFX is highly modular. At the highest level you will find that you can enable/disable entire modules. For example, if you don't have a touchscreen you can completely disable the GINPUT module. When you keep going further you'll see that you can individually enable/disable features, sub-features, sub-sub-features and so on. There's A LOT that is being done prior to compilation by the preprocessor to throw out anything uneeded. Those optimizations don't only take the individual modules & features that have been enable/disable into account but also the used processor, used drivers and even the used compiler. Therefore, every build is completely unique and comparing resource usage across different platforms is extremely difficult and misleading. We do have an internal spreadsheet which lists RAM usage of the individual objects of the µGFX library. However, we only provide that to customers which we are sure know how to everything works as misinterpreting these numbers is very easy. We have several dozen customers & users that run µGFX on a Cortex-M0 CPU - some with a much higher resolution that what you're targeting. µGFX will definitely be able to run on you platform without any problems at all. We even provide Cortex-M0 specific optimization (see GFX_CPU macro in the configuration file). The chosen display controller usually has a much bigger impact on performance than anything else. µGFX will always run at full throttle. Choosing the correct display controller and the correct interface is therefore crucial. However, which one the "correct one" is depends on the rest of the hardware and especially the application that will run on it.

Well that should work just out of the box. Nothing special required. The basic GUI functionality should not change depending on the GWIN redrawing mode. If you encountered some bug we'll need a minimal test case that allows us to reproduce the problem.

Hello and welcome to the µGFX community! Please contact us via e-mail to get a quotation for a new driver implementation. Alternatively, you can always do it yourself. You'll find plenty of documentation, examples and other resources in the documentation and on this forum.

It seems that you didn't enable all the features in the configuration file that you're using in your application. Please read through the introduction page(s) in the wiki to learn how things are supposed to work.

That's why the board file tried to change the video mode of the Linux framebuffer (which is what you just disabled). The proper solution is to figure out why it doesn't work on your platform and modifying the board file accordingly (that file is ALWAYS project/application/platform specific anyway). Otherwise, you'll have to change the pixel format that your GDISP driver is using to match the default one of your Linux framebuffer. But then you'll never be able to change it to anything else.

Please have a look at the board file. If you're using the default one it will most likely be /boards/base/Linux-Framebuffer/board_framebuffer.h. As you'll see that message is printed when board_init() couldn't set the video mode. This can have various reasons such as every Linux distribution using slightly different framebuffer compilation flags and so on. To get things sorted out, you can simply start by commenting out this line at the top of the board file: #define USE_SET_MODE // Optional - comment this out to not to try to set the color mode we want

Hello Austin! The first thing you need to do is figuring out whether you really want to run µGFX as an SDL2 application on your target. In most cases, people running µGFX on Linux on embedded devices use the framebuffer driver. SDL2 requires you to have a desktop environment which is horribly slow & heavy and that's usually not something you're after if you're actually using µGFX. µGFX has been designed to be extremely lighweight and fast. Running it inside a desktop environment brings very little benefits. Whenever you have a desktop environment that allows to run SDL2 application you already have some sort of GUI toolkit such as GTK or KDE. Usually the SDL port for µGFX is only used for development as it allows you to compile & run µGFX as a native application of your host machine. The same exists for Windows and other Unix systems. So if you're using µGFX on your target because you need something that's extremely fast & lightweight you usally want to use the Linux Framebuffer driver. That driver allows µGFX to directly render into the framebuffer which the Linux kernel will display over some video interface. In that case you don't need any desktop environment, SDL or other package. µGFX compiles without any dependencies! We don't have a guide specific for the beaglebone black wireless. However, these things always tend to be very similar. You can have a look at the RaspberryPi example as it will be very similar (that example uses the framebuffer driver as well): https://wiki.ugfx.io/index.php/Raspberry_Pi I hope that helps. Please don't hesitate to ask if you have any further questions.

Hi & welcome to the µGFX community! Your use-case & environment is definitely fully supported. µGFX has been designed to run on literally any platform. Your platform is very common among µGFX users. I don't exactly understand what's keeping you from just using the 32-bit SDL2 package? It is not a "hack" or "workaround".

You'll handle the I2C stuff in the driver's board file just like with GDISP or any other driver stuff in µGFX.