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