Joel Bodenmann
-
Posts
2,620 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Downloads
Blogs
Posts posted by Joel Bodenmann
-
-
-
Hi,
I assume that the frame widget gets the closest to that: https://wiki.ugfx.io/index.php/Frame
-
Well, you gotta give us more than just that. We can't just guess out of nothing. Please include a screenshot (with a reference to what the size of one pixel is) and a text file with your custom drawing function.
-
You are very welcome.
-
I belive GFILE_MAX_GFILES is what you're after.
-
The current GWIN list widget API doesn't provide any means to achieve this. If you want that behavior you either have to add a function to the GWIN list widget which allows you to specify the insertion position (which might require a few rewrites as the list uses a very light-weight internal list, but I don't remember the details) or you simply clear the entire list and add all items again - starting with the new one. Keep in mind that you should disable the list rendering during that period to keep things smooth.
-
There's a big, bright red box with instructions on the downloads page.
-
You can assign a different font to the keyboard widget. You can either use gwinSetFont() to only change that widget's font or you can use gwinSetDefaultFont() to change the default font of the entire application.
-
That is nice to hear!
-
Please read the documentation and have a look at the various examples. Apparently you're trying to compile keyboard stuff without having a keyboard driver (eg. a GINPUT keyboard driver or a virtual on-screen keyboard widget).
-
Those functions belong to the GOS module and are used to interface the underlying system that µGFX is running on. gfxSystemTicks() is supposed to return the current systick value. gfxMillisecondsToTicks() is supposed to convert the number of milliseconds passed as an argument to number of system ticks.
Those functions need to be implemented by the GOS port. All existing ports already have them implemented so if you're using an existing port like FreeRTOS, Linux, eCOS or anything else listed as supported you don't need to do anything. There are only two scenarios where you need to implement them yourself: You write a new port for a system that's not supported yet or you're using the baremetal port (RAW32).
The API docs of those functions can be found here: https://api.ugfx.io/group___g_o_s.html
The documentation for the RAW32 implementation can be found here: https://wiki.ugfx.io/index.php/BareMetal -
v0.23.0 is available for download. Changelog:
- Fixing bug with nested containers
- Fixed bug when resizing widgets inside of containers
- Fixing rendering issue when assigning a smaller image to an imagebox widget
- Show static items as children of the background item in the design model tree
- General code improvements
-
When using the tabset widget you should use the tabset widget high level API. There's gwinTabsetSetTab() for that. There are more goodies that you can find in the API documentation.
-
Hmm... yes, that's correct. There's currently no way to change the widget style of the page container. I just added that to the ToDo list.
-
Well, just call gwinXxxCreate() to create your widget when you receive the button press/release event.
However, this is usually bad practice. When you have enough resources (mainly talking about RAM) you create all the widgets you need during startup/initialization and then you just use gwinShow() and gwinHide() to display the widgets correctly. The handling of touch inputs and so on is all handled through the GWIN visibility and enabled state.
-
Glad to hear that you got it working!
- Yes, that's already implemented. Just assign the toggle(s) to the list widget
- Yes, selecting an item via a toggle is also already implemented. Of course, you'll have to do the "switching to another list" part yourself - just as you'd have to do with a touchscreen implementation.
- I don't think that the default list widget has a toggle input for that as it's not really the list's job. Instead, just assign a toggle to some other event (you can manually fire the event) to get a "BACK" event just as you're getting "UP", "DOWN" and "SELECT" events already from the list itself.
-
Also, regarding the display controller initialization: This is an issue we're aware of. The current display driver interface is an artifact of when I started the library six years ago. Many things changed in that time especially our knowledge of how to handle something like this. Unfortunately, it's not possible to have just one ILI9341 driver that will always work as there are different chip revisions that require different initialization. Furthermore, the initialization depends on the attached display panel and so on.
For this reason, µGFX 3.0 will have a different way of handling initialization. There will be an interface which allows you to overwrite the initialization sequence from the application level. -
From your first screenshot it looks like you added a container on the display page which covers the entire display area. That is not necessary as the µGFX-Studio always generates that container by default (it's called the "display page").
-
I haven't checked your board file but when it comes to testing you can either assign the toggle to a widget (eg. pushbutton widgets accept toggle roles) and see whether the button visibly changes state. Other than that you can just setup a listener for toggle events yourself and check whether you receive anything. Thinking of this... you can also just call ginputGetToggleStatus() in your application to poll the state
-
Thank you for bringing this to our attention. That's a problem that has been on the ToDo list for a while now and we started working on a fix yesterday. The next release will contain a patch for that.
-
We need you to answer my question.
If you use a custom rendering function we need to see the entire function implementation. -
Can you please show us a screenshot illustrating the problem?
I'm confused: Are you using the default rendering function or a custom one?
-
Ah, sorry... I didn't read your post carefully enough (phone in the bus).
As @inmarket said it's not an µGFX-Studio limitation: We need the underlying ICO decoder in the µGFX library itself. Other than that, all that the studio could do is converting any image to BMP/GIF/PNG or JPG and there are tools that do a much better job at that than the µGFX-Studio would
Adding support for that in the µGFX-Studio once the underlying library supports it takes less than an hour of work.
-
Hi,
This is something that's not on the ToDo list.
If you like to implement it yourself we're happy to help wherever we can.
Keypad widget fonts
in Support
Posted
This has nothing to do with this forum topic. Please keep things clean & organized.