Monday 30 June 2008

Gluing altogether

On last week I started to glue all different parts together. That is: wrap current adapters in my class GUIAdapter until (if ever) AdapterBase API would be changed to be more friendly, binding GUIAdapterBindings to adapters and XML element. Also parser for adapter bindings and entity recipe placeholders were written. With placeholders, I forgot at start that entity recipe is semi-atlas because of placeholders and cannot be stored as Atlas element, so this was need to be changed too.

This week I’ll continue to glue all this pieces to make it do some real work. And also general things like error handling over my code need to be improved.

Wednesday 25 June 2008

Ember RPM package for Fedora

Submitted Ember RPM package for review to Fedora. Also, libwfut package is propagated to mirrors and now available in Rawhide.

Monday 23 June 2008

Improving adapters API

I was ill since middle of last week (cold or something like that). Now it’s better but perfect :(

Anyway, I did something on my project, not much though.
I stopped with improving adapters API—I need a function that would create adapter just by its type name. With previous implementation, EntityEditor used some internal functions/methods to achieve this. Unfortunately, it seems impossible to convert them to some general interface.

So, I’m added this function to API. But there other problem rises: when creating adapter, atlas message object need to be passed to constructor. Value of this message is used then to populate adapter GUI element for first time and seems nothing like that. But, this element value has to be carefully crafted and be valid for this adapter type. For example, if it is number adapter then it should have number type, if it is 2D-position than it must be list with two number sub-elements, etc.
EntityEditor contains functions for creating all these element types. It is good functions and could be useful in some cases. But in overall, I see this approach as non-scalable—it is hard to add new adapter type.
So, my proposal is to let adapters handle elements of type NONE as some kind of default value.

Also, in some small time slices I was looking into packaging ember for fedora. When doing that, I find some license issues with ember and other libs.

Monday 16 June 2008

Tweaking entity creator widget

At this weekend I was tweaking entity creator widget.

I added lists of all recipes to it. When clicking at recipe it creates adapters for it (with static text yet).

I was starting to do it with lua, but find that bindings for some STL classes are not exist and decided to move code that uses it into C++ helper function. I’m going to try to create this bindings eventually as coding this things with lua when proper bindings exist is somewhat easier and faster.

I have also some tasks left: fix lua call context, fix atlas bindings and merge new admin widget into my branch. But I decided to postpone and spend time working on widget. I like it, because of “visial” results available.

So, primary task for this week to do is to populate widget with real (not static) adapters. And on next week, I hope, it’ll be possible to bind values from adapters with entity attributes and create entity :)

Monday 9 June 2008

Lua call context API is usable

During last week I was working on Lua call context API. This work in not finished yet because it still has bugs—some cases are not properly processed for example, when error happens during the call, also, notation that is currently used to convert value to object is not very beautiful:
returnValue.asObject<atlas::message::element>("Atlas::Message::Element")
it needs to be reworked.

Anyway, it’s now quite usable for my task. I’ve made an example code that uses it and gets an Atlas::Element from Lua. But here is new problem appear—tolua bindings are not very well handle overloaded functions, so Atlas bindings should be tuned.

Concerning my future plans, I need to design structure of an application, API of its classes. I also find components/ogre/widgets/adapters and need to change my existing classes according them.

I’m unsure how this structure should be organized, but want to start implementing GUI part and adding necessary functions to API along the way.

Monday 2 June 2008

Working on Lua call interface

At last weekend I started to look at lua scripting part of my application but “suddenly” find that ember scripting support lacks of ability to get return values from lua calls. Then Erik kindly made an scripting call context interface—it’ll be possible to get return value with it. So, my plan for next days is to clean up and bring it to state where it could be used for my task.

And task itself is stays the same—make a draft for lua scripting in my application.