On Wednesday, 29 May 2013 at 12:31:51 UTC, Flamaros wrote:
> Nop, I use lua directly (but loaded with derelict).
>
> Can LuaD manage metatables and other advanced features?

Yes! :)

it's intended as a no-compromise wrapper of the C API.

On Wednesday, 29 May 2013 at 11:36:54 UTC, Paulo Pinto wrote:
> On Wednesday, 29 May 2013 at 09:40:33 UTC, Flamaros wrote:
>> On Wednesday, 29 May 2013 at 08:49:24 UTC, Paulo Pinto wrote:
>>> On Tuesday, 28 May 2013 at 21:25:05 UTC, Flamaros wrote:
>>>> Hi,
>>>>
>>>> I and a friend are developing a GUI library, and now our script engine is ready to start a prototype (but far to be finished). We think to try to create a GUI editor based on our library.
>>>> In this way, we'll see which features are need.
>>>>
>>>> My concern is about how the editor have to works, we see two different ways to do it :
>>>> 1) Classic editor external to the user applications
>>>> a) Good :
>>>>  - Lightweight (easy to deploy and test)
>>>>  - No need to modify application code
>>>>  - Stable due to isolation of application
>>>>  - Real-time edition but limited on one view (bad to preview menus transitions)
>>>> b) Bad :
>>>>  - Limited, plugins needed to extend editor components and his knowledge of application (can't predict size of unknown application specific items)
>>>>
>>>> 2) Integrated editor (launch with the user application in a second Window)
>>>> a) Good :
>>>>  - Preview is the final result with real data
>>>>  - All application components accessible to the editor without complex plugin system (in this way all editors components will be well placed in the preview)
>>>>  - Full real-time edition (can preview menus transitions,...)
>>>>  - User can customize the editor
>>>> b) Bad :
>>>>  - Intrusive in the application code
>>>>  - Force the user to port application on a desktop OS (Linux, Mac or Windows), not friendly if he target only embedded devices (can be bypassed with a remote system)
>>>>  - Less stable editor?
>>>>
>>>> The second solution is commonly used in the video game industry, but is the best choice for a larger usage?
>>>>
>>>> What do you think about?
>>>
>>> I always hold Delphi and C++ Builder as examples of a what a good UI editor should offer.
>>>
>>> Currently Blend + VS are also another good examples for proper tooling for making good UIs.
>>>
>>> --
>>> Paulo
>>
>> It seems Blend can directly run on top of the application. Are you using this feature?
>
> What you mean by "run on top" ?
>
> I use it to have a look if everything looks like and for some stuff I need to execute the application but it requires runtime information.
>
> Blend can work with VS solutions and also invoke MSBuild, but if you are doing custom controls and stuff it is better to do certain parts from VS side, hence using both.
>
> --
> Paulo

Do blend works with C++?
I don't know how it "run on top" but on the documentation page tell that it can be aware of states that are normally only on run-time. Maybe with a static introspection or like we propose with the intrusive way.

On Wednesday, 29 May 2013 at 12:37:51 UTC, Jakob Ovrum wrote:
> On Wednesday, 29 May 2013 at 12:31:51 UTC, Flamaros wrote:
>> Nop, I use lua directly (but loaded with derelict).
>>
>> Can LuaD manage metatables and other advanced features?
>
> Yes! :)
>
> it's intended as a no-compromise wrapper of the C API.

Maybe you'll do a pull request to migrate to luaD when we'll open the repository.

For the moment, we prefer to restrict such modifications because we have some features to add the declaration engine. We also think to create a converter from a simplified syntax to the full lua syntax.

On Wednesday, 29 May 2013 at 12:48:15 UTC, Flamaros wrote:
> Maybe you'll do a pull request to migrate to luaD when we'll open the repository.

I will, I imagine it would be a pleasure. Deleting all that tedious, bug-prone stack-based code and replacing it with spurious, declarative one-liners sounds like a lot of fun ;)

On Wednesday, 29 May 2013 at 12:41:44 UTC, Flamaros wrote:
> On Wednesday, 29 May 2013 at 11:36:54 UTC, Paulo Pinto wrote:
>> On Wednesday, 29 May 2013 at 09:40:33 UTC, Flamaros wrote:
>>> On Wednesday, 29 May 2013 at 08:49:24 UTC, Paulo Pinto wrote:
>>>> On Tuesday, 28 May 2013 at 21:25:05 UTC, Flamaros wrote:
>>>>> Hi,
>>>>>
>>>>> I and a friend are developing a GUI library, and now our script engine is ready to start a prototype (but far to be finished). We think to try to create a GUI editor based on our library.
>>>>> In this way, we'll see which features are need.
>>>>>
>>>>> My concern is about how the editor have to works, we see two different ways to do it :
>>>>> 1) Classic editor external to the user applications
>>>>> a) Good :
>>>>> - Lightweight (easy to deploy and test)
>>>>> - No need to modify application code
>>>>> - Stable due to isolation of application
>>>>> - Real-time edition but limited on one view (bad to preview menus transitions)
>>>>> b) Bad :
>>>>> - Limited, plugins needed to extend editor components and his knowledge of application (can't predict size of unknown application specific items)
>>>>>
>>>>> 2) Integrated editor (launch with the user application in a second Window)
>>>>> a) Good :
>>>>> - Preview is the final result with real data
>>>>> - All application components accessible to the editor without complex plugin system (in this way all editors components will be well placed in the preview)
>>>>> - Full real-time edition (can preview menus transitions,...)
>>>>> - User can customize the editor
>>>>> b) Bad :
>>>>> - Intrusive in the application code
>>>>> - Force the user to port application on a desktop OS (Linux, Mac or Windows), not friendly if he target only embedded devices (can be bypassed with a remote system)
>>>>> - Less stable editor?
>>>>>
>>>>> The second solution is commonly used in the video game industry, but is the best choice for a larger usage?
>>>>>
>>>>> What do you think about?
>>>>
>>>> I always hold Delphi and C++ Builder as examples of a what a good UI editor should offer.
>>>>
>>>> Currently Blend + VS are also another good examples for proper tooling for making good UIs.
>>>>
>>>> --
>>>> Paulo
>>>
>>> It seems Blend can directly run on top of the application. Are you using this feature?
>>
>> What you mean by "run on top" ?
>>
>> I use it to have a look if everything looks like and for some stuff I need to execute the application but it requires runtime information.
>>
>> Blend can work with VS solutions and also invoke MSBuild, but if you are doing custom controls and stuff it is better to do certain parts from VS side, hence using both.
>>
>> --
>> Paulo
>
> Do blend works with C++?

Yes, in Windows 8 Apps when doing XAML with C++/CX.

After 16 years, Microsoft finally catches up with Borland's C++ Builder.

> I don't know how it "run on top" but on the documentation page tell that it can be aware of states that are normally only on run-time. Maybe with a static introspection or like we propose with the intrusive way.

Yes, that is possible, but not for everything. Like in most UI toolkits, your components need to be aware of a design mode.

--
Paulo

On Wednesday, 29 May 2013 at 13:52:31 UTC, Paulo Pinto wrote:

>>
>> Do blend works with C++?
>
> Yes, in Windows 8 Apps when doing XAML with C++/CX.
>
> After 16 years, Microsoft finally catches up with Borland's C++ Builder.
>
>> I don't know how it "run on top" but on the documentation page tell that it can be aware of states that are normally only on run-time. Maybe with a static introspection or like we propose with the intrusive way.
>
> Yes, that is possible, but not for everything. Like in most UI toolkits, your components need to be aware of a design mode.
>
> --
> Paulo

The intrusive method we think about, will allow use to get a full control of all items derived from our basics objects. So I imagine your prefer this solution?

On 05/28/2013 11:25 PM, Flamaros wrote:
> 2) Integrated editor (launch with the user application in a second Window)
>   a) Good :
>      - Preview is the final result with real data
>      - All application components accessible to the editor without
> complex plugin system (in this way all editors components will be well
> placed in the preview)
>      - Full real-time edition (can preview menus transitions,...)
>      - User can customize the editor
>   b) Bad :
>      - Intrusive in the application code
>      - Force the user to port application on a desktop OS (Linux, Mac or
> Windows), not friendly if he target only embedded devices (can be
> bypassed with a remote system)
>      - Less stable editor?

I think an integrated editor has a huge benefit because of the instant feedback.
You could use IPC and have the editor in a separate application. That is probably more difficult to implement but it mitigates your negative points.

https://developers.google.com/chrome-developer-tools/docs/remote-debugging

On Wednesday, 29 May 2013 at 17:28:52 UTC, Martin Nowak wrote:
> On 05/28/2013 11:25 PM, Flamaros wrote:
>> 2) Integrated editor (launch with the user application in a second Window)
>>  a) Good :
>>     - Preview is the final result with real data
>>     - All application components accessible to the editor without
>> complex plugin system (in this way all editors components will be well
>> placed in the preview)
>>     - Full real-time edition (can preview menus transitions,...)
>>     - User can customize the editor
>>  b) Bad :
>>     - Intrusive in the application code
>>     - Force the user to port application on a desktop OS (Linux, Mac or
>> Windows), not friendly if he target only embedded devices (can be
>> bypassed with a remote system)
>>     - Less stable editor?
>
> I think an integrated editor has a huge benefit because of the instant feedback.
> You could use IPC and have the editor in a separate application. That is probably more difficult to implement but it mitigates your negative points.
>
> https://developers.google.com/chrome-developer-tools/docs/remote-debugging

Yes that just what I think about this evening, developing the editor with an Object reflection trough a network API. If the API of the protocol is enough good it will certainly possible to implement something trough USB too.

I think we'll need use more __traits :-).

It will like remote debugging on JVM too.

On Wednesday, 29 May 2013 at 12:51:24 UTC, Jakob Ovrum wrote:
> On Wednesday, 29 May 2013 at 12:48:15 UTC, Flamaros wrote:
>> Maybe you'll do a pull request to migrate to luaD when we'll open the repository.
>
> I will, I imagine it would be a pleasure. Deleting all that tedious, bug-prone stack-based code and replacing it with spurious, declarative one-liners sounds like a lot of fun ;)

I concur, LuaD makes Lua an excellent extension to D.

On Wednesday, 29 May 2013 at 17:58:19 UTC, Jesse Phillips wrote:
> On Wednesday, 29 May 2013 at 12:51:24 UTC, Jakob Ovrum wrote:
>> On Wednesday, 29 May 2013 at 12:48:15 UTC, Flamaros wrote:
>>> Maybe you'll do a pull request to migrate to luaD when we'll open the repository.
>>
>> I will, I imagine it would be a pleasure. Deleting all that tedious, bug-prone stack-based code and replacing it with spurious, declarative one-liners sounds like a lot of fun ;)
>
> I concur, LuaD makes Lua an excellent extension to D.

At the beginning of the project we tough of using a javascript engine like QML, but all are in c++ and we already know well Lua. D would be nice too, but maybe not really good for declarations language and not ready for our use.