08-17-2010 05:25 PM
To set the clipping when you override paint call pushContext()/pushRegion() and it will clip everything inside the region. The only thing is that you may need to adjust the offsets to start at 0,0 or whatever coordinates you need.
08-17-2010 05:33 PM
A simple solution would be to paint most of your own "fields", then call super.paint(), then paint the title thus overriding whatever those RIM fields painted there.
08-17-2010 11:20 PM - edited 08-17-2010 11:21 PM
Thanks. I can't really paint the title on top of the components since in LWUIT this can be "anything", e.g. a user can just add a component in a separate container to the NORTH area of the screen. Layout managers can be completely decoupled as well.
Normally within LWUIT I can do that sort of thing since it supports z-ordering, layers and glasspane overlay. However, because RIM code runs on a separate thread we have a separation between the process of drawing LWUIT components and drawing RIM components. This leads to other side effects such as breaking z-ordering for native components which is something I'm personally willing to live with for this particular use case...
The reason LWUIT must run on a separate thread is rather complex but we need the EDT to allow some cool LWUIT features such as true modal dialogs/invokeAndBlock (foxtrot) and code that has almost no synchronization yet remains very portable.
The porting layer for RIM doesn't synchronize and instead calls invokeLater to perform operations on the RIM thread. Synchronization is just impossible to "get right" in a portable way, it will work for one use case and fail for another especially when device oddities are concerned.
The problem is that when LWUIT wants to trigger changes to a native field and have it painted, LWUIT is on the LWUIT thread... It seems to me impractical to use invokeAndWait during paint code.
I have several thoughts on how this might be changed including using RIM's paint on the LWUIT thread with a synchronized statement but I'm concerned this might not work as I expect for things such as video display which is the main reason for starting the whole native component integration work.
I'll try to get something working so I can commit it and get some feedback, that usually seems to help since feedback is informed by actual issues people are experiencing.