dragging a widget

[inmarket]

Great that you found a solution. I will put that back into the repository for the arduino port of gos.

Just another thought for you...

In your main loop you are doing a timer comparison to run update every 100ms. Let me suggest to you to use gtimer to run your update every 100ms. The geventEventWait can then use INFINITE for the timeout period and that loop does nothing but handle events.

The multi threading is not going to be an issue for two reasons, 1) gwin is designed for that, and 2) your class should be safe as the threading on your platform is cooperative.

[inmarket]

One more note...

I notice you are doing some inverse square root operations. You might want to try the routine in GMISC for this as it is a LOT faster than any standard maths library.

It is code that I picked up from the gaming industry and is used in the bouncing ball gdisp streaming demo.

[crteensy]

Great that you found a solution. I will put that back into the repository for the arduino port of gos.

Keep in mind that arduino is not a single piece of hardware. There are *many* different boards, architectures and compilers and the malloc problems I'm apparently facing might be a non-issue for different hardware.

Just another thought for you...

In your main loop you are doing a timer comparison to run update every 100ms. Let me suggest to you to use gtimer to run your update every 100ms. The geventEventWait can then use INFINITE for the timeout period and that loop does nothing but handle events.

The multi threading is not going to be an issue for two reasons, 1) gwin is designed for that, and 2) your class should be safe as the threading on your platform is cooperative.

I might try that, but to be honest I don't like the fact that gwin forces me to use a multi-threading environment in the first place. gdisp was fine without multiple threads, but having widgets doesn't work without them. That adds a lot of potential problems and given that I've already faced many problems with this project I think that there are many many more for others who are doing different things.

[crteensy]

The items were a bit hard to delete because any movement while pressed would be treated as a drag operation. I've added a 5 pixel threshold to that and now they're much easier to remove. New video, now running on target hardware:

http://youtu.be/nasV63EVM2I

Surprisingly smooth!

[inmarket]

Multi-threading was pretty much required not so much by the widgets but by the input subsystem. It is surprisingly difficult to do input particularly touch without timers and multiple threads.

I have some ideas for removing that current dependancy but there are always compromises and it will certainly raise complexity of some components to do so.

[inmarket]

Very nice video!

[crteensy]

btw sorry for the background flicker!

So why do the labels leave a trace when moving from left to right, but not when moving in any other direction? Those traces force me to do a full redraw of the parent container as soon as all labels have settled in their final position.

[inmarket]

I don't know. Some debugging of the move redrawing would probably be required to find out.

[inmarket]

Just a thought...

If you put a space at the beginning of the label it may remove this problem.

It could be caused by the font being hard up against the left edge of the label but the right edge may have a single pixel space due to inter - character gaps as defined by the font.

[crteensy]

I though it might be something like that. OTOH, getwidth() in gwin_label.c adds 2 pixels of extra width to the returned width, for the label to use for padding. I think this padding should be enough, but gdispFillStringBox doesn't shift the text right by one pixel, or does it?

[inmarket]

Depending on the justification specified. Left will put it hard left, center will put it in the middle (plus or minus a pixel because of rounding) and right puts it hard right subject to inter - character spacing.

[inmarket]

Compare the label padding to the number of pixels you are moving the label.

[crteensy]

That sounds a bit complicated and somewhat makes the whole point of encapsulation moot, doesn't it?

[crteensy]

Regarding the memory allocation problem I faced:

The widget constructor functions provide an optional pointer to a pre-allocated widget structure. Shouldn't I be able to get around using ugfx's own memory management by simple passing a poitner to pre-allocated memory there? What happens to dynamically allocated strings in that case?

[inmarket]

Yes a pointer to a pre allocated object can be passed to the widget constructor. It is indeed designed for smaller memory systems that need to very carefully control memory allocation. It also saves the memory allocator overhead.

Similarly widget strings can be passed in as static strings or copied to dynamic memory. There are however some strings that are always dynamic for example list box strings. Widgets such as the image widget also use dynamic memory for things like image decoding.

Thus most widgets can avoid dynamic memory allocation with careful programming - but not everything.

Whenever dynamic memory is required the system always uses gfxAlloc and gfxFree. These are implemented by the gos layer and should be able to be called safely anywhere in the gfx code. In your case however the arduino malloc and free do not operate correctly unless the code is running on the native stack. This is a bug in that implementation but is not infrequent in embedded libraries. One bad implementation gets replicated into lots of platforms. It is for the lack of good memory allocation routines that the alternative raw32 memory allocator was written. It solves that problem nicely fixing those platforms that have no suitable routines and those that are buggy (such as the arduino library version).

I can't complain too much about their implementation however as changing the stack is not a common operation and so it is highly unlikely that situation has been tested well by the arduino library writers.