inmarket
-
Posts
1,296 -
Joined
-
Last visited
-
Days Won
4
Content Type
Forums
Store
Downloads
Blogs
Posts posted by inmarket
-
-
Yes that is exactly what will happen when I get round to creating those functions. The vmt routines will be exported to proper api calls.
In the mean time the method described in the above post will always allow the border sizes to be determined.
-
Some of the better known development boards have sets of board files predefined for them. You can find those in the boards/base directory.
Some extra board files for various situations have also been put in the boards/addons directory.
If you are lucky you will find exactly what you are looking for in one of those two places.
-
I thought creating the window you specify the internal size already but I might be wrong about that.
If not, in the interim you can create the window invisible, get its internal size and then resize the window (now supported but not well tested) before making it visible.
Later I will look at what is required to return border sizes etc.
Note the above method is the defined/preferred way of doing it under win32
-
I think you are both missing the point. The driver is either calibrated and clipped or non - calibrated with raw readings. The touch driver test code uses this to enable testing of the touch parameters.
If however you disable all calibration code this is NOT the same as running in the special raw mode used by the touch driver test tool. In this situation you will be getting raw readings but they will be clipped to the screen dimensions. As the touch scale is not likely to match one to one with pixel display scale this means the readings will not scale over the display and of course widgets will not work.
In other words this touch controller cannot operate without calibration or atleast scaling of its readings. One that does is the Win32 touch driver as windows performs the scaling and clipping for you before passing them to the ugfx driver. Effectively mouse/touch scaling as seen at the driver level corresponds one to one with the display scaling.
If you want to manually control the calibration and scaling then you need to use Tectu's method with calibration turned on but replace the 1's with the hardwired scaling factor. This will prevent the user being prompted for the calibration.
Note also many touch panels are oriented transverse the the display orientation. If your panel is one of these calibration is the only reliable way to get a working translation and scaling matrix. The maths involved in doing it by hand are nasty.
-
If you want after 500ms the 2nd parameter should 500 not MS2ST(500) as geventEventWait takes milliseconds as the 2nd parameter.
Try that change first and let us know if that works.
I know there were bugs around that area in the old code. If the new code does not work after the above change let us know and I will do some tests.
-
Check your make script and your linker script. gfxInit is a public function so if it is undefined it must be a linking problem.
-
Internally we do something like this already. It should be simple to export this in some form.
I think when you specify a size on creation of the frame you
are specifying the internal size. I will need to double check this.
-
True - For list pointers, menu scrolling and that sort of thing the toggle model is best.
-
Just "on" toggles - that makes sense. It would also be easier to implement than on with intermediate off's.
I can't remember the exact context of "role". I will examine the source and get back to you on that one. I think it might refer to when a slider for example can have two toggle inputs attached to it. One has the role of an up button and one has the role of a down button.
If you are talking about a rotary encoder incrementing or decrement in a counter - that is exactly what the dial interface is. An analogue dial is only one way to do that. In this case the rotary encoder is used to increment and decrement the counter "dial" value. The application gets notifications as the counter/dial value changes.
The current slider widget can be connected to a dial input now and it will do what you are suggesting. I don't think a progressbar has that dial input hook yet. A rotary equivalent to a slider widget would also make a great widget.
what defines a "dial" is something that can move in value between a minimum value (usually 0) and some maximum value. How that value is physically changed just depends on the driver eg analogue dial, rotary encoder, temperature sensor, possibly one axis of an accelerometer, a light sensor etc.
Digital or analogue doesn't matter.
-
One more thought...
As a dial device it would be useful to be able to set the range of the dial. Changing the range would have the effect of changing the sensitivity. Eg a dial with a range of 0 to 30 would appear to reach full scale much faster than a dial of range 0 to 300.
Alternatively the increment could be changed to change the sensitvity rather than the range.
-
Rotary encoders was one of things I was thinking about when designing dial.
In practice there are two models of use for rotary encoders
1. Like an analogue control eg a volume control. For this model a dial works perfectly.
2. As a direction encoder. For this the toggle interface is the best model with up and down toggles.
There is no reason that the driver for the rotary encoder cannot implement both driver interfaces at the same time allowing the user interface to pick which model it wants depending on the context of use. It may even use one model in one location and the other model somewhere else with the one rotary dial.
For the centre press a toggle is definitely the correct control.
-
It was one of those to - do things. The problems you were having just made now the time to do it.
I am much happier with the code now.
Thanks for your diagnostics and help in identifying problems.
-
I have largely rewritten gevent.
As you surmised the problem was the re-entrancy within the event callback handler that the frame window was doing.
Looking at the code it should have never been allowed with the existing implementation.
The updated implementation should have none of those issues.
It also now completely avoids the use of gfxSemCounter() which is algorithmically nasty anyway (it is also hard to implement on some o/s's eg Win32).
I have done basic testing using the frame and widgets demo however I would appreciate you testing the new implementation with your code which appears to test this far more thoroughly than our simple tests.
-
That is great debugging! Multi-threading issues can be such a pain. I will look very closely at it in the next few hours (just got to time it around real paying work).
Thank you for your work in this area.
I think the reason this has gone undetected for so long is because in the past listeners have never been created and destroyed continually. They were typically set up once and never destroyed (like the main application listener). I will make sure we get this fixed asap.
-
Thanks. I will look in detail at that in the morning.
-
This has been integrated into the repository.
I have changed the names a little to be more consistent with other uGFX names and added support for returning the tag in each widget that create events.
Thanks for this, it has been a good addition.
-
Thank-you for this fantastic work. It has been added to the repository.
-
I have uploaded into the repository a couple of fixes to raw32.h which should help prevent type definition conflicts with standard headers.
Hope this helps.
-
I have looked at the code in question. Your fix in frame.c is definitely required when there are no buttons on the frame window. Thanks for finding it.
The change to event.c is NOT required (only the psl->listener field is checked to test for slot availability) and may have other side effects.
I have updated the repository with this change.
Can you please test if this solves your problem?
-
There is a test program specifically designed to test mouse drivers.
Try starting with that.
It is in the tools/touch_driver_test directory.
-
You are certainly right about window objects taking memory. Unfortunately that is the cost of adding that level of abstraction.
uGFX is a LOT better than most other embedded window systems but we are working to make it better yet.
We have an internal spreadsheet that we use for tracking memory usage of widgets etc for the purpose of driving our optimisation efforts. We are not ready to release that publicly yet however if you send me a private email I will send it to you.
The frame window is particularly bad because it contains a number of "sub-widgets" for the close buttons etc plus special listening code to handle that.
Listeners in particular are expensive as under the current model every listener contains a maximum sized event buffer.
The way to optimise the frame window is to remove the sub-widgets and have the frame window code do the drawing itself for those objects. This has a number of advantages...
- It removes the memory requirements for each of the sub-widgets
- It removes the memory requirements for the special listening code
- Window move and resize should work correctly as there are no children outside the client area
- Simplifies object destruction and other code
There is however more complexity in the frame window drawing code and it will take time to code. Hopefully soon I will fix it.
- It removes the memory requirements for each of the sub-widgets
-
The other way (and probably the best way) is to create a generic GWindow object and use the gwin drawing calls to draw on that window rather than the gdisp drawing calls.
THe gwin drawing calls ensure that the redraw state is up to date before they perform the actual draw.
eg gdispDrawPixel() gets replaced with gwinDrawPixel().
Sorry for the delay in this comment - I wanted to check the code first.
-
The other thing that will be nice to add is support for a "model" window.
It would make your popup window code so much easier.
Ahh, so much to do
-
Redraw in most cases occurs on a timer thread which is why you are seeing the behaviour you mention. This by design to keep certain actions particularly quick.
There are some defines which control that behaviour one of which I am sure does all the redraw in a synchronous manner. There are other side effects of using those defines so read the doc on them carefully (or just try them and see what happens).
The solution you have used is actually a good solution and shouldn't create any additional redrawing - just change when they happen.
Last commit made geventEventWait returning immediately
in Development and Feedback
Posted
All timing functions in ugfx use real time milliseconds or microseconds. This is because ugfx is designed to be operating system neutral. MS2ST is a chibios specific call.
Some operating systems don't even have the concept of a "tick". Even chibios V3 is "tickless" with ticks only being maintained as a optional scheduler quantum and for V2 compatibility.
I will run some tests over the next few days to see why geventEventWait might be returning early.