Messages by Bo

Ho yes it seems there is a mistake in the setCurrentScreen method.

        // Check transition
        if (screen != null) {    // <--- add this condition
            Transition transition = screen.getTransition();
            if (transition != null && this.screen != null) {
                Kuix.getCanvas().setTransition(transition);
            }
        }

Yes, this bug was fixed on the SVN.

You need to switch the encoding of your .properties file into UTF-8. The way to do it depends of your Editor.

Ok, then you use Author style (setAttribute("style", "bg-color: xxx")). Remember that, for authorStyle, you can use directly widget.parseAuthorStyle("bg-color: xxx") method.

Else, for the second screen do you set again the bg-color ? because clearStyleCache do not reset authorStyle ! You use the same Screen object instance, then it's normal that Screen attributes are kept.

Could you post the stack trace of the nullPointerException ?

Ok, but you need to know that a Screen instance without it's content do not use a lot of place in memory. You remove all screen children then free the meomry they occuped, then why not free the screen to.

Else, it's my point of view and in fact behind this there is a real problem of using an existing instance of a screen and have a way to clean it.

But, how do you use a special background to your screen ? do you use style class ? or do you use author style ? od do you apply a style to the screen tag in a css file ?

 

Could you explain a bit more about how you process for Desktop.removeAll() ?

New tracker ticket added.

Ho yes ... community snipets is a realy good idea !

Then, you create both screens through java ? Something like :

 

// First screen

Screen screen = new Screen();

screen.add(...)

screen.setcurrent();

 

// Second screen

screen.cleanUp();

screen.removeAll();

screen.clearCachedStyle(false);

screen.add(...)

 

Is it right ?

 

But why do you prefer to clear all content except the screen itself instead of creating a new Screen instance ?

In a first pass, Kuix try to detect the platform, by searching for specific classes implementations.

In a second pass, Kuix try to detect soft keys.

 

The choice was made to use this way of auto detection, because we wants that a Kuix application is ready to run. After, the range of device increase all the days and with this the number of non detected one. But there isn't real orther way to realy detect the device model and apply a correct mappging.

In the case of Motorola, the specific autodetection was change a litte and it now works for 90% of Motodev emulated devices.

It seems that this problem occure when using more than one jar as library. You can mix kuix.jar and kutil.jar into a single jar, or use NetBeans ;)

If you take a look at last changes, list children are no more converted into listitems.

Here you need to view List widget only as a component designed to managed repetitive content as described in the renderer attribute.

Because the philosophy of Kuix is be flexible while staying simple, I think it woulds be wrong to add a "type" attribute to the list.

In this case a list is not more a checkbox list than a radiobutton list. Because of the special management of radio buttons, the dedicated radioButton list is the RadioGroup which extends List class.

 

That's what the lastest modifications propose :

for checkbox list :

<list>

<_renderer><![CDATA[<checkbox>...</checkbox>]]></_renderer>

<_items>@{items}</_items>

</list>

 

for radiobutton list :

<radiogroup>

<_renderer><![CDATA[<radiobutton>...</radiobutton>]]></_renderer>

<_items>@{items}</_items>

</radiogroup>

 

But you're right that a all in one list would be easier to use and understand, but less flexible.

Checkout the lastest sources of Kaprice and check how it could works in the next release.

@see how products are selectable.

The FileConnection API specified in JSR-75 gives access to the local file systems on devices.

In the past, the choice was made to consider "invisible" widget in layout pass but not in "paint" pass. That's why "invisible" widgets do not free their space.

It's right that there's actualy no way to "remove" a widget from the widget tree with an attribute like "visible". And it could be important to reconcider this question.

But in some case we want to hide widget and in other its appearance only ... then what would be the best solution ?

 

All  dynamic children of a list are automaticaly ListItem, then in your case, you've got a checkbox (focusableWidget) in a listitem (focusablewidget too).

Then you can list listitem has non focusable  like this :

...

<![CDATA[<listitem focusable="false"><checkbox onAction="...">...</checkbox></listitem>]]>

...

 

But I understand that is not a real elegant way to to a list of checkboxes. I think it would be better if we could put any kind of widget as a child of list dynamic and not only listitems ...