openmeetings-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: some issue with the chat panel and the fontsize
Date Wed, 26 Dec 2012 23:36:25 GMT
Maybe this explanation of the initialization problems in the (OpenLaszlo)
UI is useful:

The root issue is often that you add an "oninit" handler in some view.
The issue with that is that you true to access variables of the parent
The sequence the oninit handlers are called is: From the inside to the way
UP ! So if you compare that to the famous Russian every OpenLaszlo "view" or
"class" is one cascade of the doll. The sequence of "oninit" handlers is
from the smallest to the biggest. So if you add an oninit handler to the
smallest view, you can't add "parent.attributeXYZ", cause parent is not
initialized yet.
That is why only the major components have an "oninit" handler. For example
the class "flexibleConferenceRoom.lzx". Cause this class/view is the upmost
view of the whole conference room, it makes sense to add the "oninit"
handler to it. But it actually makes no big sense to add "oninit" handlers
to subviews, in case there is interaction of the component with other views.

The second source of pain in OpenMeetings and initialization is the room
entering itself. We need to pass some variables to the server and between
the SWFs. For example when we reconnect the RTMP connection in
We need to trigger some methods after it (but actually the UI is already
BUT: We can't actually know what is taken place faster: The RTMP call or
the "oninit" method.

The third source of initialization problem is an OpenLaszlo specific: The
"onxyz" handler is called on initialization:
<view name="xyz">
  <attribute name="isopen" value="true" type="boolean" />
  <handler name="onisopen" args="b">
     if ($debug) Debug.write("onisopen",o);

The handler onisopen is called everytime somebody invokes:
But OpenLaszlo does also a call to onisopen "initially". And this happens
_before_ the roomObject is set. So the call
content._content1._chattabbottom.updatefontbuttonvisible(); fails cause the
roomObject is not available.
This is somehow a flaw of OpenLaszlo itself. A possible fix might be to
check if the roomObject is set or not.

Hope this makes the issues a bit more clear.


2012/12/27 <>

> And there are several runtime errors connected to the new chat font
> options:
> WARNING @modules/conference/tabcontent/chat/chatTabBottom.lzx≈123:
> reference to undefined property 'allowFontStyles'
> chatTabBottom updatefontbuttonvisible allowFontStyles undefined
> WARNING @modules/conference/tabcontent/chat/chatTabBottom.lzx≈124:
> reference to undefined property 'allowFontStyles'
> WARNING @modules/conference/tabcontent/chat/chatTabBottom.lzx≈125:
> reference to undefined property 'allowFontStyles'
> WARNING @modules/chat/fontOptions.lzx≈128: reference to undefined property
> 'length'
> WARNING @modules/conference/tabcontent/chat/chatOutput.lzx≈110: reference
> to undefined property 'length'
> Please make sure you fix those. Remember: In the SWF8 app those
> NullPointerException seem to have little effect. In the SWF10 app it would
> have the consequence that the entire app might freeze. Also it makes the
> client almost unmaintainable if you have so many warnings.
> A last resort that (at least I think is sometimes acceptable) is a
> if-clause like:
> if (blabla["myvar"]) {
>   blabla.myvar = xyz
>   (or blabla.setAttribute("myvar",xyz); //if you want to invoke the
> onmyvar listener on that blabla view)
> }
> blabla["myvar"] will be true if the variable exists. But at least blabla
> must exist of course.
> For the method: "updatefontbuttonvisible" I think the issue is that you
> call this method when currentRoomObject is not yet initialized.
> This happens because the onisopen handler is initialized before the client
> actually is really in the room.
> For the other warnings you might have to debug the variables that you are
> using in detail.
> Sebastian
> 2012/12/27 <>
> Hi Alexei,
>> Happy Christmas :) I hope you had some nice holidays!
>> I have some questions regarding the code for the font sizes.
>> The icon that you are using, we should not include the icons and compile
>> it into the application. We have a theme XML file.
>> Have a look in chatTabBottom.lzx Line 173:
>> <miniIconsImage src="$once{ canvas.getThemeImage('button_cancel_rsc') }"
>> button_cancel_rsc is the name of the ressource configured in the
>> default-theme.xml file.
>> Also we need to make sure that all our icons are compatible with the APL.
>> Where did you copy the font.png from, what License is it?
>> I see that there are some other icons in the file:
>> WebContent/src/modules/conference/tabcontent/chat/library.lzx that have
>> no License.
>> I guess some of them are not even in use and can be deleted.
>> However every icon that we include needs a proper documentation where it
>> has been copied from.
>> See for example:
>> WebContent/src/modules/conference/tabcontent/library.lzx:
>>     <!-- FamFam Icon Set -->
>>     <resource name="messagebox_info_rsc" src="resources/information.png"
>> />
>> The comment tells anybody that we have taken that icon from the FamFam
>> Icon set. And in our NOTICE file we have this comment:
>> This product includes icons from FamFamFam Icon Set Silk.
>> The comment links to the NOTICE, and in that sense we have the correct
>> attribution of the Icon done.
>> However for those font size icons there is no attribution at all. We
>> can't release that.
>> Also the icons itself look not sharp, the reason is that you are
>> stretching them. Is there a reason for stretching the icons? If there is no
>> real need for a stretch then it would look much better if you would use the
>> icons in its original size and modify the surrounding box to match the
>> icons, instead of stretching every icon to fit into your box (or you look
>> for icons that have the needed 24x24 size). The icons you are using are
>> 16x16 so you should actually use that for the UI also.
>> Sebastian
>> --
>> Sebastian Wagner
> --
> Sebastian Wagner

Sebastian Wagner!/dead_lock

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message