Messages by Bo

Do you extends the KuixMIDlet to create the application ?

JavaME and then Kuix include native mapping only on numeric keys and direction keys. Then if you use a Querty BlackBerry, you won't be able to use all alpha keys as shortcuts for example.

But BB querty keyboard is a real problem because the Canvas.getGameAction(keyCode) could returns direction key for some alpha keys ...

Else on a BB, the Enter key do no return the same code as Fire (press on the trackball), and the focus request is don on the Fire keyPressed event.

Kuix 1.0 actualy use a GameCanvas and flushGraphics() method to refresh the screen and it's not realy compatible with the VideoControl display. We are working on.

It can support as items as the phone memory can support. Each item will be represented by a widget instance (here a RadioButton).

Yes. The visible attribute only hide or show the widget (and its children). it doesn't remove it from its parent.

Kuix Choice open a separate screen for several reasons :

- because of the small size of some screen it would be better to use full screen to list choices

- because popup aren't as simple to place correctly as it coulds appear on first relflexion

- because of its internal way to render the selected value. The first goal of a choice is to be usable of text value as any widget values (pictures, text and picture, custom widgets, ...) To optimize object creation, the choice was made to display the selected value without and clonage or duplication. Then in this case it isn't possible to display choice list and selected value in the same time.

But if you realy want a dropdown choice, you can take a look on Menu and it's MenuPopup. it dosn't include all basic mecanism of a combobox, but it would be possible to derived it.

I'm surprised of your screen adjusment problem, because the Kuix Layout concepts guaranty by definition the screen adjustment.

Could you give us snippet, screenShot or photos of your problem ?

Else, Kuix is a framework at Java level, then it doesn't include any concept of specific building. You need to do this at IDE level and for this NetBeans is a response to your problem.

Drop down component, Combobox are named Choice in Kuix. Take a look at this compoment.

Its concept is particular because it is split into a Choice widget (visible on the screen and which display the selected value) and a ChoiceRadioGroup (visible only when you want to change the selected value). You can find an example of this component in the KuixDemo.

What does multi device build means for you ?

Because Kuix is made to run on a large compatible device set without any special build. Platform autodetection is made at runt time on the device. In this case build once and rune on any compatible device (commonly MIDP 2.0 / CLDC 2.0)

If you check the lastest sources from SVN the visible=false widget are now completly removed from the screen

Yes, but if you use the pointer (finger), nothing is borring, first in general case, you doesn't use any key, second with the pointer (finger) you have access to the scrollbar thumb and you can go from last to first in a second.

The main problem reside in the key navigation. In my opinion, it isn't a good way to ask to the UI developper to code itself the jump out.

Else, at present focus navigation is made a FocusManager level, not at widget level. In this case the focus navigation process search for the next focusable widget in the widget tree with one parameters : the desired direction (left, right, top , bottom). From this the system determine the nearest widget in the desired direction. By this system, you can navigate in the same way between widget from the same parent as from diffrent parent. Then the container desn't have any importance.

In the Desktop class (near line 257). You can see this fix on the SVN sources.

The worker is responsible of all Kuix engine tasks (revalidate, repaint, keyEvents), then if you stop it, you stop Kuix.

Else key and pointer events are first intercepted by the current focusManager. When a Screen is displayez, those events come into its focusManager. But if you add a popup (via showPopupBox method) the current cofusManager will be the popup focusManagerr which could do nothing for each event. Take a look at the Desktop.getCurrentFocusManager() function to understand the process.

Else again, if you only want to hide onAction, onFocus, .... events, you can push into the FrameHandler a newer frame that do nothing in the onMessage method and remove it after to restaure the previous state.

Add and remove your popup by pushing a new task to the Worker from your thread.

Hmmm ... but if you have several scrollbars and if when you go to next focus you loop on scrollbar relative widget, the focus can't get out of this cycle. That why the loop parameter is at screen level.