Messages by WebSeed

This will also become an issue for me if when we submit to Ovi Store. A fix would be much appreciated.

Hi,

There seems to be a bug in the Base64 decoder. For example, passing the following string into the decoder:

AAAATgAAAAUAAAAZAAAABQAAAE4AAAAhAAAA//////////8AGQAAAAAAB1BhdHJpY2sAAAAAAAAAAAAAAAA=

Produces (byte values separated by comma):

0,0,0,78,0,0,0,5,0,0,0,25,0,0,0,5,0,0,0,78,0,0,0,33,0,0,0,-1,-1,-1,-1,-1,-1,-1,-1,0,

25,0,0,0,0,0,7,80,97,116,114,105,99,107,0,0,0,0,0,0,0,0,0,0,-1,-1,16

But the correct bytes are:

0,0,0,78,0,0,0,5,0,0,0,25,0,0,0,5,0,0,0,78,0,0,0,33,0,0,0,-1,-1,-1,-1,-1,-1,-1,-1,0,

25,0,0,0,0,0,7,80,97,116,114,105,99,107,0,0,0,0,0,0,0,0,0,0,0,0

(Note the -1, -1, 16 sequence at the end)

In addition, shouldn't the minus character (last character) in the hash be a forward slash '/'?

Will.

Yes, I'd agree. BTW just to avoid confusion, I assume pandora meant "final PopupBox pop ...".

Try:

Kuix.alert("...");

Kuix.getCanvas().revalidateAsSoonAsPossible();

...

Kuix is a User Interface framework. Use whatever other Java code/library you need to perform RMI etc.

I get "page not found" for:

http://www.kalmeo.org/projects/kutil/docs/svn

This isn't possible with J2ME. All canvas or screen-based user interface components are designed to fill the screen (excluding possibly the native time, battery level, signal strength etc. indicators).

Hmn, I see the change has been introduced already. I can't really see why a disabled widget should receive focus? It means I now have to add extra XML:

<button onaction="doAdd">
   %ADD%
   <_enabled>@{active}</_enabled>
   <_focusable>@{active}</_focusable>
</button>

This is not a huge problem, but why the change?

On an unrelated note, it would be great if it were possible to negate values in XML e.g. @{!active}, otherwise I'm forced to define an additional property in my data provider.

Yes, it's possible:

<textfield>
    <_tooltip>%MESSAGE%</_tooltip>
</textfield>

You're probably compiling for CLDC-1.0 devices (support for floats was introduced in CLDC-1.1). In NetBeans go to "File" > "Project Properties" > "Platform" and then ensure "Device Configuration" is set to "CLDC-1.1".

Sorry, this isn't a solution. I'm also facing the same issue - my code it littered with Worker.pushTask(...) requests for interacting with Kuix from non-UI threads. This works, and I'll use this method if necessary, but it doesn't seem ideal.

Ah right, I see how this works now thanks. I was just applying it as a global property on the desktop style ("desktop { grayed-color: black; }") and hadn't realised it should be used in the way you just outlined.

Why defining this style attribute and after add a line into Desktop to ignore it?

Well, it means that the grayed-color will at least be displayed for a "normal" PopupBox but will be ignored for the MenuPopups (that are displaying the problem) - as mentioned it's not ideal.

When I use the "grayed-color" property for screen menus, the screenbottombar is also covered by the grayed-color. However, I think this is the wrong behaviour. PopupBox widgets seem to display okay because they have their own dedicated "bottombar" Widget, but MenuPopups seem to just change the Screen bottombar (which is covered by the grayed-color overlay). If this doesn't make much sense, I can provide an image.

A simple workaround for this is to not display the grayed-color property on MenuPopups by adding a condition to the Desktop.java file such as:

if (grayedColor != null && !KuixConstants.MENU_POPUP_WIDGET_TAG.equals(popupContainer.getLastChild().getTag())) {

...

But this isn't a nice solution.

Yes, Kuix automatically rescales the screen, layouts and widgets when the screen's orientation changes. Try downloading one of the latest Nokia emulators and you can try this out: http://www.forum.nokia.com/Resources_and_Information/Tools/Platforms/S60_Platform_SDKs/