www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Need some opinions for a GUI editor

reply "Flamaros" <flamaros.xavier gmail.com> writes:
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?
May 28 2013
next sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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
May 29 2013
parent "Flamaros" <flamaros.xavier gmail.com> writes:
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.
May 29 2013
prev sibling next sibling parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
May 29 2013
parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
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?
May 29 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
May 29 2013
parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
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.
May 29 2013
parent reply "Paulo Pinto" <pjmlp progtools.org> writes:
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
May 29 2013
parent "Flamaros" <flamaros.xavier gmail.com> writes:
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?
May 29 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
May 29 2013
parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
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]
May 29 2013
next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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?
May 29 2013
parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
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?
May 29 2013
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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.
May 29 2013
parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
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.
May 29 2013
parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
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 ;)
May 29 2013
parent reply "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
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.
May 29 2013
parent "Flamaros" <flamaros.xavier gmail.com> writes:
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.
May 29 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-05-29 12:22, Flamaros wrote:


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


I would think it's easier to develop such editor. Probably just as easy 
to use as a built in editor.


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


I assume you will have some kind of objects floating around in memory. 
Serialize those to whatever format you use, in this case Lua.

-- 
/Jacob Carlborg
May 29 2013
parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
On Wednesday, 29 May 2013 at 19:35:31 UTC, Jacob Carlborg wrote:

 On 2013-05-29 12:22, Flamaros wrote:


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


 I would think it's easier to develop such editor. Probably just 
 as easy to use as a built in editor.


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


 I assume you will have some kind of objects floating around in 
 memory. Serialize those to whatever format you use, in this 
 case Lua.


We'll have nothing else than Lua declarations, and Items 
properties aren't simple values because we are using propety 
bindings pattern (you make take a look at 
http://en.wikipedia.org/wiki/QML).

With that their is nothing static, to illustrate if you size the 
window all can be adapted efficiently by user defined behaviors.
May 29 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-05-29 23:43, Flamaros wrote:


 We'll have nothing else than Lua declarations, and Items properties
 aren't simple values because we are using propety bindings pattern (you
 make take a look at http://en.wikipedia.org/wiki/QML).

 With that their is nothing static, to illustrate if you size the window
 all can be adapted efficiently by user defined behaviors.


Ok, I see. That seems to be a bit more tricky.

-- 
/Jacob Carlborg
May 30 2013
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
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
May 29 2013
parent "Flamaros" <flamaros.xavier gmail.com> writes:
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.
May 29 2013
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On 05/28/2013 11:25 PM, 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).


What do you use for rendering?
May 29 2013
parent reply "Flamaros" <flamaros.xavier gmail.com> writes:
On Wednesday, 29 May 2013 at 19:38:57 UTC, Martin Nowak wrote:

 On 05/28/2013 11:25 PM, 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).


 What do you use for rendering?


We use OpenGL 2.1, we target this particular version for intel 
drivers and stay close to OpenGLES.
May 29 2013
parent "Denis Koroskin" <2korden gmail.com> writes:
On Wednesday, 29 May 2013 at 21:45:38 UTC, Flamaros wrote:

 Need some opinions for a GUI editor


You can combine both approaches: make the editor an external app 
that would communicate with your running application (if it's 
compiled in an editor-enabled mode).


 On Wednesday, 29 May 2013 at 19:38:57 UTC, Martin Nowak wrote:

 On 05/28/2013 11:25 PM, 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).


 What do you use for rendering?


 We use OpenGL 2.1, we target this particular version for intel 
 drivers and stay close to OpenGLES.


It's very interesting to see what you guys did so far! :)
May 29 2013