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?

29.05.2013 1:25, Flamaros пишет:
> 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?

As for me, a GUI editor is completely unneeded. Currently I'm using GTK+ for my apps so I tried to use Glade a long time ago but finished manually writing all the code as it:

1. It is not complicated and not time-wasted at all.
2. It gives you more control on the application.
3. It saves you time (!) as you can use you own functions for common widgets creation/location patterns.

So if your library isn't that silly one where you have to manually specify widget location/size in parent don't waste your time on GUI editor.

-- 
Денис В. Шеломовский
Denis V. Shelomovskij

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

On Wednesday, 29 May 2013 at 07:56:19 UTC, Denis Shelomovskij wrote:
> 29.05.2013 1:25, Flamaros пишет:
>> 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?
>
> As for me, a GUI editor is completely unneeded. Currently I'm using GTK+ for my apps so I tried to use Glade a long time ago but finished manually writing all the code as it:
>
> 1. It is not complicated and not time-wasted at all.
> 2. It gives you more control on the application.
> 3. It saves you time (!) as you can use you own functions for common widgets creation/location patterns.
>
> So if your library isn't that silly one where you have to manually specify widget location/size in parent don't waste your time on GUI editor.

Our GUI library will be interesting for modern Interfaces with animations. I really think that it's easier to tweak animations and positions of items in real time.
The editor will not hide script code, so manual edition will be possible too.

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?

On 2013-05-28 23:25, 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 would go with the first approach because I would guess it's easier. The editor creates the controls. When saving it will serialize all the controls to some format. This format is then read by the application.

For serialization you could have a look at Orange:

https://github.com/jacob-carlborg/orange

-- 
/Jacob Carlborg

On Wednesday, 29 May 2013 at 09:51:04 UTC, Jacob Carlborg wrote:
> On 2013-05-28 23:25, 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 would go with the first approach because I would guess it's easier. The editor creates the controls. When saving it will serialize all the controls to some format. This format is then read by the application.
>
> For serialization you could have a look at Orange:
>
> https://github.com/jacob-carlborg/orange

You think it's easier to do or to use?


We can't do serialization because our GUI files are lua scripts.

It looks like :
[CODE]
Image {
	id = "image",
	source = "images/pngtest.png",
	x = 50,
	y = 50,
	
	titi = 0,
	toto = function()
		return image.width + image.height
	end,
	onTotoChanged = function()
		image.titi = image.toto
		print("onTotoChanged = "..image.titi)		
	end,
	
	Button {
		width = function()
			return image.width
		end,
		height = function()
			return image.height
		end,
	}
}
[/CODE]

Button isn't a D Object :
[CODE]
function Button(t)
	print(t.width)
	local Buttonimage3 = Image {
		id = "Buttonimage",
		width = 100,	-- property binding, when image change width is automatically updated
		height = 50,
		-- opGet = function(propertyName)
			-- return ButtonmouseArea[propertyName]
		-- end,
		-- opSet = function(propertyName, value)
			-- ButtonmouseArea[propertyName] = value
		-- end,
		

		source = function ()
			if ButtonmouseArea.pressed then	-- property binding, when mouseArea state change this condition is updated directly
				return "images/Alpha-blue-trans.png"
			else
				return "images/pngtest.png"
			end
		end,

		MouseArea {					-- parent/child object encapsulation
			id = "ButtonmouseArea",
			width = function ()
				return Buttonimage.width
			end,
			height = function ()
				return Buttonimage.height
			end,
		},
	}
	for key, value in pairs(t) do
		print(value)
		Buttonimage3[key] = value
	end
	return Buttonimage3
end
[/CODE]

On Wednesday, 29 May 2013 at 10:22:21 UTC, Flamaros wrote:
> We can't do serialization because our GUI files are lua scripts.

Just curious, but, are you using LuaD?

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

On Wednesday, 29 May 2013 at 11:11:36 UTC, Jakob Ovrum wrote:
> On Wednesday, 29 May 2013 at 10:22:21 UTC, Flamaros wrote:
>> We can't do serialization because our GUI files are lua scripts.
>
> Just curious, but, are you using LuaD?

Nop, I use lua directly (but loaded with derelict).

Can LuaD manage metatables and other advanced features?