Latest messages

Thanks reporting this bug. It would be fixed in the next release.

Hi,

I'm not sure to understand but, if the attribute title is not define for the screen, the topbar isn't displayed. so it will be an equivalent to topbar="false". As the bottombar isn't displayed when firstmenu or secondmenu widget are not set. However you cannot switch them displayable or not like you could do with a boolean attribute.

Some of the lists in my application were growing somewhat big and I wanted to test out the programmatic way of creating the UI so I could try if I could get better performance from my application.

But creating the lists seems to be a bit difficult. How am I supposed to create it programmatically ? There seems to be no reasonable way of using a data provider and providing the renderer for the list widget. Or am I supposed to add the child listitem widgets by hand, and if so then it seems that I will be unable to use the data provider to automatically update the list and/or values..

I'll just post this here as an "official" bug report also. When focusloop - attribute is set as true on a screen with a list (or with no focusable components), Kuix ends up in an endless loop looking for the focusable widget.

This can be easily reproduced by adding focusloop="true" - attribute to Kaprice's sl_s.xml - file and then creating a new list and opening that empty list in Kaprice. Will throw OutOfMemoryError

Nevermind. Just found out what was wrong. I had copied the xml file from another screen that I had done. I forgot that in screen tag there was the focusloop="true" attribute. When there are no focusable components on the screen, it seems that Kuix ends up in an endless loop looking for the next focusable widget. I removed the focusloop="true" and everything started working again.

I guess you could call this a bug.. Because in the end I want to have that focusloop true, as I want the list that is on the screen to loop from bottom to top and vice versa. Now if the list is empty, Kuix will end up in endless loop. If there is stuff in that list, it works ok.

In another thread I just said that it would be nice to be able to modify the top and/or bottom bar of the screen widget. But just realised that it would actually be enough that I could turn the top and bottom bars off completely.. I know I can set their styles so that they are in essence invisible, but just a simple way to turn them off would be nice so that they aren't created etc. Maybe have like topbar="false|true" bottombar="false|true" in the xml definition of the screen.. That way I could turn them off and just create my own bars in the xml. Like this:

<screen topbar="false" style="layout:borderlayout">
    <container id="topbar" style="layout-data:bld(north)">
    </container>
    <container id="desktop">
    </container>
</screen>

Okay. Thanks. I see your point about shielding the Screen class from changes. I myself just belong to the group of people that think that everything should be overriddable and replaceable by the developer. But then again, I don't have to provide support for Kuix :) So I guess it's easier if you limit the possibilities. How about providing a way to customise top bar and bottom bar :) That's what I really was after at first by wanting to provide my own implementation of Screen. I wanted to add some controls to the top bar of the screen.

Oh.. Sorry, by active I meant visible :) But just realised that that really isn't frame's problem as it in essence isn't even part of kuix but kutil. But anyway. It would be nice if the frame could be notified when it is moved on top of the stack. That way it could show it's screen etc. I was thinking all the time that moving the frame on top of the stack would make it visible, but it's me who is making it visible in onAdded method. And I guess that method is called only once when the frame is added to the stack. So on(Something) method would be nice so it would be possible to make the screen visible when the frame is pushed on top.

Maybe there should be the notion of an "active" frame. And the frame on top of the stack is always the active one. That way there could be onActivated, onDeactivated methods or something along that line.

Be sure I will try to improve the possibility to add shortcuts on Screen !

In the past I decided to make Screen an AbstractActionWidget to be able to use the 'onAction' and 'shortcuts' attributes, but it's right that even if this representation of shortcuts could be suffisant on a button or all other action widget the case o Screen is different. Ant in this case why not threat it in this context.

Else, I'm not very sure that give the possibility to define user class for screen is a realy good thing. A big part of Kuix logic is based on Screen and it could become very instable if we add the possibility to override the default Screen class.

Yes, or have two method : pushFrame(frame) and pushFrame(frame, putOnTop).

Else all frames are already active. A message can pass through all frames of a stack if each one return true in the 'onMessage' method.

Then in this case a frame isn't more active if it's in top or not.

Yeah, I guess it would. Or maybe give a boolean parameter to the pushFrame - method that defaults to false. If it's true, the frame is pushed on top. It would also be nice if I remove a frame from the stack that the next frame on top of the stack would become active.. That way I could just push a frame on top of the stack and once I'm done with it, remove it and the previous frame (whichever it was) would become active.

I'm not really overriding it. I'm just overriding the setAttribute - method of the Screen widget. And then first I parse the action names from the raw data that is given and the strip them and pass that raw data back to setShortKeyCodes just as before. So basically this modification only requires changes to the Screen widget. Which is not really that bad, but currently there is no way of providing your own implementation of the Screen widget unless you modify Kuix - class as I described in the first post.

But I think I'm moving on to different things for now. This is really not that big of a deal. And besides I ran into some trouble with the action handling using my modifications.

Yes, push frame do not put it on top. In some case it is preferable to assume the presence of a frame by repuching it without change its position if it was already present. It's right that at present there's no way to put a frame on top. But we can imagine adding de putFrameOnTop(frame) method on FrameHandler.

Ok, I understand the remove problem. I think the putFrameOnTop method could solve it no ?

Yes, but in you case you have to override the Widget.setShortcutKeyCodes() method and I'd prefer this one stay as simple as possible.