Skip to main content

test - please ignore

11 replies [Last post]
Anonymous

Please ignore

[att1.html]

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Qunhuan Mei

Current soft menu design appears to be following original MIDP's where
all commands are added to the form and the system decides how they are
distributed across the soft buttons and soft menus.

The issues with this design:

1. Can't dictate what should be the left, right, as well as middle
soft button/key (note that the 3 soft buttons/keys approach appear to be
a very popular design lately).

2. Does not support multi-layered soft menu system. Support of 2
layer (minimum) menu system seems to be desirable.

[att1.html]

Shai Almog

Hi Qunhuan,
thanks for your messages.
I'm unifying most of your messages to ease the correspondence on the
forum since the list is linked to the forum its best to try and reply
to yourself/others when dealing with the same subject.

> There seems to be a problem with bgSelectionColor. The actual
> colour shown is slightly lighter than the colour specified in the
> resource file. However, when setBgTransparency is set to 255, the
> focus colour appears to be normal.
>
Transparency defaults to different values in different components
this should probably be better documented, what you are seeing is not
a bug its the effect of alpha blending.

> Do we have to set BgTransparency to 255 all the time? What is the
> default BgTansparency used if not set? Or Is this a bug?
>

You can define the transparency in the theme as well using decimal
values from 0 to 255 e.g.:
List.transparency=255

> 1. When a drop down comboBox fully exhibits itself, it often
> blocks the view of sofekeys. Would it be better not to let drop
> down comboBox blocking the area of softkey area?
>

By convention we only allow selection with the fire button in the
combo box, we might enable an option to do define that the combo box
doesn't paint on top of the menu bar area. However this is a problem
in small screens and with combo boxes close to the bottom of the screen.

> 2. The drop down comboBox does not have related softkeys.
> Would it be better to allow comboBox or any component as such to
> have softkeys. The reason is when a comboBox is the focus, the user
> might think the current softkeys are related to the “new”
> component” – just a thought.

Right now we don't change softkeys based on focus events, it is
possible to do this manually but we think that overzealous changing
of softkey behavior breeds user confusion.
We are considering changes to the architecture of the combo box which
is a remnant from a much older version of LWUIT, but this will
probably have to wait for the open source stage where I can actually
explain things about the code and architecture.

> I suppose this might be a known problem to the LWUIT team:
>
> Scroll bar is suppose to function when set to true. However, when
> true is set, both horizontal and vertical scrolling is not working
> properly.
>
> The horizontal scroll bar appears to be buggy.
>

Scroll bars appear only when actually filling the screen, there is a
bug in horizontal scrollbars which I fixed in SVN (will be in next
drop).
If you can open an issue with a way to reproduce I will try to
address that.

> Current soft menu design appears to be following original MIDP’s
> where all commands are added to the form and the system decides how
> they are distributed across the soft buttons and soft menus.
>
Not exactly. Unlike MIDP where the system decides we only rely on
order and place everything exactly according to the order in which
you added your commands.

> 1. Can’t dictate what should be the left, right, as well as
> middle soft button/key (note that the 3 soft buttons/keys approach
> appear to be a very popular design lately).
>
You can, the first elements added will grab the softkeys.
SE has moved to 3 softbuttons with JP-9 (or is it 8 already). Nokia
has already moved S40 to 3 buttons and is moving the S60 with the new
FP.

> 2. Does not support multi-layered soft menu system. Support
> of 2 layer (minimum) menu system seems to be desirable.
>

I assume you mean nested commands?
We had that request before, personally Chen and myself aren't crazy
about the idea of nested menus in terms of usability you should
generally try to use buttons and other widgets more which are also
more touch screen friendly.

However we understand people want that feature and we will probably
deliver it in a future release, the current architecture doesn't
block it in any way since a command can be modified/derived to
contain other commands.

We also intend to provide some additional "hooks" to customize the
menu and the commands including their order right before the menu is
actually displayed. These would probably be in the form of protected
methods in form that could be overriden to suite your needs.

Thanks,
Shai.

[att1.html]

Qunhuan Mei

There seems to be a problem with bgSelectionColor. The actual colour
shown is slightly lighter than the colour specified in the resource
file. However, when setBgTransparency is set to 255, the focus colour
appears to be normal.

Do we have to set BgTransparency to 255 all the time? What is the
default BgTansparency used if not set? Or Is this a bug?

Example can be found in the demo attached earlier.

Listed below is the colour specified in the configuration file:

bgColor= f0f0f0

fgColor= 220404

bgSelectionColor= ff0000

fgSelectionColor= f8f8f8

font= System{ FACE_PROPORTIONAL ; STYLE_PLAIN; SIZE_SMALL}

SoftButton.bgColor= 0036b5

SoftButton.fgColor= f8f8f8

Title.bgColor= 000000

Title.bgImage=bar

Title.fgColor= ffffff

Title.font=Bitmap{Arial Black}

[att1.html]

Qunhuan Mei

It seems to be there are two issues related to comboBox.

1. When a drop down comboBox fully exhibits itself, it often
blocks the view of sofekeys. Would it be better not to let drop down
comboBox blocking the area of softkey area?

2. The drop down comboBox does not have related softkeys. Would it
be better to allow comboBox or any component as such to have softkeys.
The reason is when a comboBox is the focus, the user might think the
current softkeys are related to the "new" component" - just a thought.

[att1.html]

Qunhuan Mei

I suppose this might be a known problem to the LWUIT team:

Scroll bar is suppose to function when set to true. However, when true
is set, both horizontal and vertical scrolling is not working properly.

The horizontal scroll bar appears to be buggy.

[att1.html]

Qunhuan Mei

The problem is related to the use of Container.

The test case is fine when traversing horizontally. But when traversing
vertically, the focus change sequence appears to be wrong. It might be a
bug.

Attached please find the demo app and its source.

[att1.html]
[LWTUI_test.jar]
[LWTUI_test.jad]
[uidemo.rar]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@lwuit.dev.java.net
For additional commands, e-mail: users-help@lwuit.dev.java.net

Attachment not added (too many attachments): "uidemo.rar"

vprise
Offline
Joined: 2003-11-07

> The problem is related to the use of Container.
>
> The test case is fine when traversing horizontally.
> But when traversing
> vertically, the focus change sequence appears to be
> wrong. It might be a
> bug.

I missed this issue in the emails, I'm not exactly sure its a bug although focus is a REALLY hard issue in UI toolkits and its technically impossible to get right for all cases.
If you want to control focus manually for this case you can use the setNextFocusDown method to indicate the order you would like.
The reason the algorithm makes that pick is that it looks at the next component downwards and decides that the best pick is the bottom component when traversing down. This makes some sense, especially if you look at column based layouts. That is why we have the setNextFocusDown method.

There are however some issues with the down focus which I am still investigating so it might be related to them and it might not be. Either way using this API will probably still work in the future even if I fix any issues.

Thanks,
Shai.

Qunhuan Mei

Greetings to all!

First of all, Sun has done a great job to release this LWUIT API kit. It
is a great help for us developers, making our life much easier!
Certainly it will also help the mobile data service business, improve
look and feel, and shorten the time to market ... Really appreciated! I
have reviewed the LWUIT based on my experience. I will post some issues
in next a few emails.

Form is the top level component that serves as the root for the UI. It
seems we can't have a image placed above the form title. Having one Form
(with title) within another form (without title but just an image label)
is not working properly during testing. Tried twice along the line and
both failed. (I learnt the latest version will probably throw an
exception if one form inside another!?).

- Just wondered if it is possible to have a floating Title, so
that we can have other components (is one enough?) placed above it.

Thanks,

Qunhuan

[att1.html]

Shai Almog

Hi Quhuan,
thanks for your comments we are looking further for further ideas and
observations!

> Form is the top level component that serves as the root for the UI.
> It seems we can’t have a image placed above the form title. Having
> one Form (with title) within another form (without title but just
> an image label) is not working properly during testing. Tried twice
> along the line and both failed. (I learnt the latest version will
> probably throw an exception if one form inside another!?).

Yes, the upcoming version of LWUIT will disallow nesting forms since
this just doesn't work properly and shouldn't really work properly. A
form contains allot of extra information regarding focus etc. that is
redundant inside the hierarchy and so it should be treated as a
special case top level component (like AWT/Swing Window/Frame/Applet
etc.).

Currently we didn't enable the option to set an icon for the title or
any customization besides the obvious style manipulation.

We had very long discussions about this and I think you guys should
help us decide how to move forward with this.

Technically a title is a Label placed in the NORTH location of the
form, with the softbutton area as a container placed in the south area.

So essentially for now if you want a title with an image you can just
avoid calling setTitle (or alternatively set it to null) and just
place any arbitrary component in the north area.

Our current approach is to expose the title component itself:
public Label getTitleLabel();

It would allow you to set the attributes of the title and roughly
corresponds to getContentPane().
We can couple it with:
public int getSoftkeyCount();
public Button getSoftkey(int);

So to set the label you could do something like:
getTitleLabel().setIcon(icn);
getTitleLabel().setTextPosition(Component.BOTTOM);

Chen and myself still need to agree on the syntax and I doubt this
will make it to the next drop, so if you want to rush us just file an
issue ;-)

>
> - Just wondered if it is possible to have a floating
> Title, so that we can have other components (is one enough?) placed
> above it.
>
Do you mean a title that stays fixed in place while scrolling or a
title whose position changes in runtime?

I can't really picture this, in mind so I have no idea. I think you
can do anything you want technically.
Worst case scenario you can always override paint() and draw whatever
you want but generally I think you can place a component and avoid
defining a title as described above.

Thanks,
Shai.

[att1.html]

Qunhuan Mei

Hello Shai,

Thanks for your reply. Please see my comments below.

Kind regards,

Qunhuan

From: Shai.Almog@Sun.COM [mailto:Shai.Almog@Sun.COM]
Sent: 23 May 2008 13:50
To: users@lwuit.dev.java.net
Subject: Re: No logo/image could be put above the page title in normal
way.

Hi Quhuan,

thanks for your comments we are looking further for further ideas and
observations!

Form is the top level component that serves as the root for the UI. It
seems we can't have a image placed above the form title. Having one Form
(with title) within another form (without title but just an image label)
is not working properly during testing. Tried twice along the line and
both failed. (I learnt the latest version will probably throw an
exception if one form inside another!?).

Yes, the upcoming version of LWUIT will disallow nesting forms since
this just doesn't work properly and shouldn't really work properly. A
form contains allot of extra information regarding focus etc. that is
redundant inside the hierarchy and so it should be treated as a special
case top level component (like AWT/Swing Window/Frame/Applet etc.).

Currently we didn't enable the option to set an icon for the title or
any customization besides the obvious style manipulation.

We had very long discussions about this and I think you guys should help
us decide how to move forward with this.

Technically a title is a Label placed in the NORTH location of the form,
with the softbutton area as a container placed in the south area.

So essentially for now if you want a title with an image you can just
avoid calling setTitle (or alternatively set it to null) and just place
any arbitrary component in the north area.

This is fine. The only problem is that the developer then needs to look
after all the title related graphics, instead of using system's existing
functions.

Our current approach is to expose the title component itself:

public Label getTitleLabel();

Are you exposing the title label before or after the title has been
fully constructed? I suppose developers would like to have
functionalities of both setting title data automatically (you have it
now) and manually (not available except setting title name string). So
exposing a handle for setting title data before it has been fully
constructed would be nice. But a normal query of any specific component
already constructed on the form may not be very useful unless necessary.

The only 2 use cases regarding title I could think of are:

1. Title on top, everything else below it.

2. Title on top but below a label, which could be simply an image,
an animation, or a video logo etc (?)

I could not imagine a case where a container is required to be placed
above the title.

So, I would suggest just adding one more constructor, to allow a label
placed above the title:

Form
g%29> (Label labelAboveTitle, java.lang.String title)

It would allow you to set the attributes of the title and roughly
corresponds to getContentPane().

We can couple it with:

public int getSoftkeyCount();

Could not imagine a use case for this. Is it hardware specific?

public Button getSoftkey(int);

Seems to me currently all softkeys are commands, not buttons.

So to set the label you could do something like:

getTitleLabel().setIcon(icn);

getTitleLabel().setTextPosition(Component.BOTTOM);

As I mentioned above, if there is no other use cases regarding title, we
may not need a "floating" title, since this complicates things.

Chen and myself still need to agree on the syntax and I doubt this will
make it to the next drop, so if you want to rush us just file an issue
;-)

Thanks, will see.

- Just wondered if it is possible to have a floating Title, so
that we can have other components (is one enough?) placed above it.

Do you mean a title that stays fixed in place while scrolling or a title
whose position changes in runtime?

This can be ignored since my intention is expressed clearer above.

I can't really picture this, in mind so I have no idea. I think you can
do anything you want technically.

Worst case scenario you can always override paint() and draw whatever
you want but generally I think you can place a component and avoid
defining a title as described above.

Thanks,

Shai.

[att1.html]

Shai Almog

> This is fine. The only problem is that the developer then needs to
> look after all the title related graphics, instead of using
> system’s existing functions.

Yes, that is assumed with a lightweight approach. We considered the
option of allowing the user to disable full screen support but
decided to avoid that since it will introduce lots of other problems.
You can disable full screen by using the MIDP API to get the current
Displayable and just cast it to game canvas, then disable full screen.

> I could not imagine a case where a container is required to be
> placed above the title.
>
> So, I would suggest just adding one more constructor, to allow a
> label placed above the title:
> Form(Label labelAboveTitle, java.lang.String title)

You would be surprised how many use cases are called for by every
designer, specifically I don't really understand what your use case
you are trying to solve?

If you want to place something above the title you should probably
build your own title:

class MyForm extends Form {
private Component myTitleArea = ...;
private Container contentPaneOverride = new Container();
public MyForm() {
Container c = super.getContentPane();
c.setLayout(new BorderLayout());
c.addComponent(BorderLayout.NORTH, myTitleArea);
c.addComponent(BorderLayout.CENTER, contentPaneOverride);
}

public Container getContentPane() {
return contentPaneOverride;
}

public void setTitle(String title) {
super.setTitle(null);

// ... update the value of your title....
}
}

you will probably need to override
addComponent,removeComponent,setLayout etc... to make sure they go to
the new content pane rather than the "real one".

We got requests for titles with progress bars on one side while
having a logo on the other, not to mention animations etc...

These are all doable with LWUIT and we don't block anything, its just
that we don't want to make the simple most common classes cluttered
and unusable for the most common cases. The guideline for adding a
method to the API is that if you want to be something unique it
shouldn't make the simple things harder by adding more methods to a
central class.

>
> It would allow you to set the attributes of the title and roughly
> corresponds to getContentPane().
> We can couple it with:
> public int getSoftkeyCount();
>
> Could not imagine a use case for this. Is it hardware specific?

Modern phones have 3 softkeys and we support that using the display API.
The center button acts as a softkey which is pretty cool.

>
> public Button getSoftkey(int);
>
> Seems to me currently all softkeys are commands, not buttons.

They are added as commands but this is mapped to the Button component
which is the softkey, just like a title is a string which is
converted to a label.
>
[att1.html]