Messages by tsyvanpe

Yeah, I guess it wouldn't hurt. If using string identifiers only on more cast is needes so sit should work with only minor changes to existing code. If I may enquire as to what is the reason for this change ? Or what can be done with the added flexibility ?

I was trying to make a custom textarea widget which would handle html - styling a bit differently. Mainly the problem is that the default textarea chokes on html which is not well formed. I just ran into problems with paintImpl method that was called from paintChildrenImpl, I guess it had something to do with scrollcontainer optimization or something like that. I guess I can go around this problem. I just copied the default textarea and made my own version of it.

The isNone - method is currently private in KuixConverter, if I wish to override KuixConverter with my own implementation, that method should be made protected or public so I don't have to make my own checks in my converter

Seems that the latest svn - version has removed Screen.setTransition - method. I need it to set the transition dynamically in my code. In my application the user can change the displayed screen by pressing left/right and I need to set the transition depending on whihch button was pressed. So the slide animation slides in the correct direction. The shortcuts - attribute for my screens is defined as "left=showScreen1(left)" where the argument tells which direction the screen should slide when doing the transition..

And also, I've been creating some new widgets by copying for example TextArea - widget as a base for my own. Problem is, that some methods which TextArea calls for it's child widgets are protected and therefore I cannot call them as I use different package. For example paintImpl - method is one such method which causes problems in TextArea.paintChildrenImpl. I know I could have just extended the TextArea - widget and use it as a base, but there are so many private methods which I cannot override that I can't get the features I want in them. I guess most private - methods in widgets should be changed to at least protected, if not public.

Doesn't really affect the way the transition works, but the SlideTransitions init method has yOffset = 0 twice, should propably be yOffset = 0 and xOffset = 0

Cool, excellent! You really have first class support, and you seem to really listen to feature requests and wishes. Hopefully more people would find your framework, as currently it seems that I'm almost the only one on these forums :)

It's a gps navigation application mainly for use with geocaching. There is already such an application called Geocache Navigator, (http://www.geocachenavigator.com), but as always, it's lacking in features I would like to see so I decided to make my own. It's come pretty far already, thanks to your excellent UI framework. Haven't released anything yet, as I can't decide whether I wish to release the source code or not. The idea was to make it free, but I'm not sure whether I would wan't to release the source code. On the other hand, I currently cannot afford to license your framework, so therefore it will propably be open source.

Or a shorter form of the above:

                            Menu firstmenu = screen.getFirstMenu();
                            Menu secondmenu = screen.getSecondMenu();
                            if (firstmenu != null && firstmenu.getPopup() != null && firstmenu.getPopup().isInWidgetTree()) {
                                firstmenu.hidePopup();
                            } else if (secondmenu != null) {
                                secondmenu.processActionEvent();
                            }
                            return true;

Currently Kuix works so that regardless whether another system menu is showing, it will show/execute the other menu when that soft key is pressed. I'd prefer a way to hide the other menu when the soft key is first pressed and then execute the action when it is pressed again..

What I mean by this is that (at least on Nokia phones) the normal way of operation is that the right soft key always cancels the current action. So if a left system menu is showing and I push the right soft key, the left menu closes. And only after I press it a second time, the action associated with the right menu is executed.

It's very distracting in my application, because the right soft key is bound to quit on the main screen and when I'm showing the left system menu I automatically press right soft key to get rid of it. But instead now it executes the quit - action.

I managed to get the behavior I wanted by making the following modifications to FocusManager:

                    // Soft key right
                    case KuixConstants.KUIX_KEY_SOFT_RIGHT: {
                        Screen screen = rootWidget.getDesktop().getCurrentScreen();
                        if (screen != null) {
                            Menu firstmenu = screen.getFirstMenu();
                            boolean process = true;
                            if (firstmenu.getPopup() != null && firstmenu.getPopup().isInWidgetTree()) {
                                firstmenu.hidePopup();
                                process = false;
                            }
                            if (process) {
                                Menu secondmenu = screen.getSecondMenu();
                                if (secondmenu != null) {
                                    secondmenu.processActionEvent();
                                }
                            }
                            return true;
                        }
                        break;
                    }

But I guess it would be prefereable to make this behavior optional.. So any chance of getting this feature to Kuix ?

When using a list inside a scrollcontainer and using focusloop = true with the screen, the scrolling doesn't quite work correctly. When reaching the end/start of the list and focusloop makes the focus wrap around, the scrollcontainer doesn't scroll to correct position. You have to click up/down a few times before the container catches up with the list.

In my application the number of different frames/screens is rapidly growing. I noticed that if I made the frame switch so that each time the frame was removed it would destroy the screen and recreate it next time it was shown, the speed at which the screen was displayed could have been a bit better (not that it was slow even with that technique). So I replaced it so that the screen is kept in memory and the screen is just displayed according to which frame we are viewing. Everything works just fine and now the UI is noticeably faster. But one thing that I noticed was that even though the screen is not currently displayed, it still gets the updates from the data provider.. Is this by design ? Wouldn't it be more resource effective to seize fetching the data from the provider while the screen is not being displayed ? And also, should widget.isVisible() really return true even though the screen it is in is not currently visible ? I was trying to make a modification to the data provider where it only dispatches the update events when widget.isVisible() == true, but it seems that it is always true, unless I explicitly set it to false..

The new scrolling text feature of the textfield doesn't take into account possible margins defined for the textfield. The text overflows the box the amount of the margins.

Aah.. Yes.. It was the markers.. I set usemarkers="true" and it started working.. Thanks.

I can't seem to get a textarea working inside a scrollcontainer.. Or actually the textarea works fine, but the scrollcontainer won't scroll.. I have a screen with borderlayout and in it one container with layout-data north and then another scrollcontainer with default layout-data (ie. center). The screen is displayed correctly, but the scrollcontainer won't scroll the contents of the textarea which is longer than the screen.. The scrollbars are displayed correctly..

Excellent. I see that you have implemented this also in 1.0.0RC2.. Thank you very much. You seem to have forgotten this change from the Changelog though.