Need some opinions for a GUI editor

[Flamaros]

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]