GUI

A place for developers to promote games they have created with Moai.

Moderator: naturally

Re: GUI

Postby derickdong » Sun Apr 22, 2012 10:47 am

I certainly wouldn't turn down any help. I've got a lot of it working; mostly I'm trying to clean up some of the internal stuff. When I originally wrote this, I have to admit I'd really only had about a week or two of experience with MOAI and Lua. Plus, at the time, there were a few quirks with MOAI that I had to work around, so a few hacks were necessary. Hopefully, most, if not all, of that sort of thing has been ironed out. I'm trying to make as few changes to the public interface as possible. There's been a few things that needed to be changed, but its primarily been in the initial system setup, so it shouldn't break too much existing code for anyone.

I should be able to get something out in the next day or two. I'll keep you posted.
derickdong
 
Posts: 63
Joined: Wed Nov 09, 2011 2:54 pm

Re: GUI

Postby ibisum » Mon Apr 23, 2012 4:38 am

Well I have definitely been given an advantage through the use of your toolkit so far, as it has been the basis for the GUI elements for most of my MOAI apps, and in that sense has been a very valuable asset. So valuable, in fact, that I'm working on moaigui as a priority this week - so I'd really very much like to synchronize with you through a repo and start feeding back some of my contributions as well. I look forward to hearing what you do vis-a-vis a repo for us to use as soon as you are ready ..
;
--
ibisum@gmail.com
Got a MOAI snippet? Please consider adding it to http://moaisnippets.info/
User avatar
ibisum
 
Posts: 1250
Joined: Mon Oct 17, 2011 1:11 am
Location: Vienna, Austria

Re: GUI

Postby derickdong » Fri Apr 27, 2012 1:18 pm

Sorry its taken me so long to respond. I've been busy with some unexpected stuff. I've managed to get just about everything working with v1.0, except for the widget list. Its been giving me some problems, particularly with the selection of elements. Hopefully, I should get it figured out today, and will at least try to upload a .zip file with the files. I'll also try to get the source loaded up into the repo as well.

As far as changes go, here's a bit of a rundown:
- Refactored internal code. In particular, using MOAIProp's attribute linking to handle parent-child transforms and visibility, and trying to remove the use of 'module(..., package.seeall)'
- Resource managers - textures, fonts, and text styles
- Better consistency in function naming and parameters. Image handling was especially bad
- Some minor bug fixes

Its not really part of the gui, but there's also an included layer manager. Primarily, its used to auto-handle the depth sorting of layers - when a layer is added to the manager, the user assigns a priority to it, and works similar to how MOAIProp:setPriority works for props. The gui layer, which will usually need to be above all the other layers, would be assigned a very high priority. I also use a sky box in my project, and its layer is given a very low priority. Everything else is somewhere between. Maybe somebody will find it useful.
derickdong
 
Posts: 63
Joined: Wed Nov 09, 2011 2:54 pm

Re: GUI

Postby derickdong » Sat Apr 28, 2012 2:18 pm

I've uploaded a new version of the GUI, which should work with the latest version of MOAI (v1.0 r3). Unfortunately, I can't edit the original post, but the link there will still take you to a page with the download. I'll repeat it here for convenience.

http://code.google.com/p/moaigui/downloads/list
derickdong
 
Posts: 63
Joined: Wed Nov 09, 2011 2:54 pm

Re: GUI

Postby ibisum » Mon Apr 30, 2012 11:26 am

Thanks for this! I will catch up with you this week and feedback what I can .. I really appreciate you making this work available and I hope I can contribute something in the coming weeks. Will let you know!
;
--
ibisum@gmail.com
Got a MOAI snippet? Please consider adding it to http://moaisnippets.info/
User avatar
ibisum
 
Posts: 1250
Joined: Mon Oct 17, 2011 1:11 am
Location: Vienna, Austria

Re: GUI

Postby ibisum » Tue May 08, 2012 7:17 am

Hi - just wanted to follow up with you on this .. I'm attempting to use these GUI controls in a small game which has a number of 'screens' requiring input. Your GUI controls are perfect for this - I can define the full GUI in a layout fine, and this works just fine.

But the question is how to handle multiple layouts in the application? Here is some sample code:

Code: Select all
  1.  

  2. ----------------------------------------------------------------

  3. -- GUI Demo

  4. ----------------------------------------------------------------

  5.  

  6. require "gui/support/class"

  7. --require "xmlutils"

  8.  

  9. local gui = require "gui/gui"

  10. local resources = require "gui/support/resources"

  11. local filesystem = require "gui/support/filesystem"

  12. local inputconstants = require "gui/support/inputconstants"

  13. local layermgr = require "layermgr"

  14.  

  15. require  "button_handler"

  16.  

  17. APP_NAME = "GUI DEMO"

  18.  

  19. MOAILogMgr:setLogLevel()

  20.  

  21. gameOver = false

  22. screen_width = 320

  23. screen_height = 480

  24.  

  25. MOAISim.openWindow ( APP_NAME, screen_width, screen_height )

  26.  

  27. viewport = MOAIViewport.new ()

  28. viewport:setSize ( screen_width, screen_height )

  29. viewport:setScale ( screen_width / 10, screen_height / 10)

  30.  

  31. world_layer = MOAILayer2D.new ()

  32. world_layer:setViewport ( viewport )

  33. MOAISim.pushRenderPass ( world_layer )

  34.  

  35. local g = gui.GUI(screen_width, screen_height)

  36.  

  37. g:addToResourcePath(filesystem.pathJoin("resources", "fonts"))

  38. g:addToResourcePath(filesystem.pathJoin("resources", "gui"))

  39. g:addToResourcePath(filesystem.pathJoin("resources", "media"))

  40. g:addToResourcePath(filesystem.pathJoin("resources", "themes"))

  41. g:addToResourcePath(filesystem.pathJoin("resources", "layouts"))

  42.  

  43. layermgr.addLayer("viewport", 1, layer)

  44.  

  45. g:setTheme("basetheme.lua")

  46.  

  47. g:setCurrTextStyle("default")

  48.  

  49. function onKeyboardEvent(key, down)

  50.   if (down == true) then

  51.     g:injectKeyDown(key)

  52.   else

  53.     g:injectKeyUp(key)

  54.     screen_index = screen_index + 1    

  55.     screen_changing = true    

  56.   end

  57. end

  58.  

  59. function onPointerEvent(x, y)

  60.   g:injectMouseMove(x, y)

  61. end

  62.  

  63. function onMouseLeftEvent(down)

  64.   if (down) then

  65.     g:injectMouseButtonDown(inputconstants.LEFT_MOUSE_BUTTON)

  66.   else

  67.     g:injectMouseButtonUp(inputconstants.LEFT_MOUSE_BUTTON)

  68.   end

  69. end

  70.  

  71. function onMouseMiddleEvent(down)

  72.   if (down) then

  73.     g:injectMouseButtonDown(inputconstants.MIDDLE_MOUSE_BUTTON)

  74.   else

  75.     g:injectMouseButtonUp(inputconstants.MIDDLE_MOUSE_BUTTON)

  76.   end

  77. end

  78.  

  79. function onMouseRightEvent(down)

  80.   if (down) then

  81.     g:injectMouseButtonDown(inputconstants.RIGHT_MOUSE_BUTTON)

  82.   else

  83.     g:injectMouseButtonUp(inputconstants.RIGHT_MOUSE_BUTTON)

  84.   end

  85. end

  86.  

  87. -- Register the callbacks for input

  88. MOAIInputMgr.device.keyboard:setCallback ( onKeyboardEvent )

  89. MOAIInputMgr.device.pointer:setCallback(onPointerEvent)

  90. MOAIInputMgr.device.mouseLeft:setCallback(onMouseLeftEvent)

  91. MOAIInputMgr.device.mouseMiddle:setCallback(onMouseMiddleEvent)

  92. MOAIInputMgr.device.mouseRight:setCallback(onMouseRightEvent)

  93.  

  94. local buttonHandler = ButtonHandler()

  95.  

  96. app_screens = {}

  97. -- variouslayout2.lua is just a copy of variouslayout with some controls removed...

  98. app_screens = {

  99.                 { layout_path = "variouslayout.lua",   layername = "various1" },

  100.                 { layout_path = "variouslayout2.lua",  layername = "various2" },

  101.               }

  102.  

  103. screen_index = 1

  104. screen_changing = true

  105.  

  106. mainThread = MOAIThread.new()

  107.  

  108. local roots, widgets, groups = {}

  109.  

  110. mainThread:run(

  111.   function()

  112.  

  113.     while not gameOver do

  114.       coroutine.yield()

  115.  

  116.       if (screen_changing == true) then

  117.  

  118.         if (screen_index > #app_screens) then

  119.           screen_index  = 1

  120.         end

  121.  

  122.         if (nil ~= g) then

  123.           if (nil ~= widgets) then

  124.             g:destroy()

  125.  

  126.             if (nil ~= widgets.variousbutton2) then

  127.               local button = widgets.variousbutton2.window

  128.               button:unregisterEventHandler(button.EVENT_BUTTON_CLICK)

  129.             end

  130.  

  131.             if (nil ~= widgets.variousbutton1) then

  132.               local button = widgets.variousbutton1.window

  133.               button:unregisterEventHandler(button.EVENT_BUTTON_CLICK)

  134.             end

  135.  

  136.           end

  137.  

  138.           --layermgr.hideLayer(app_screens[screen_index].layername)

  139.           t_layer = {}

  140.           t_layer = layermgr.getLayer(app_screens[screen_index].layername)

  141.  

  142.           g:shutdown()

  143.           roots = nil

  144.           widgets = nil

  145.           groups = nil

  146.         end

  147.  

  148.         local roots, widgets, groups = g:loadLayout(resources.getPath(app_screens[screen_index].layout_path),

  149.                                                                       app_screens[screen_index].layername)

  150.         layermgr.addLayer(app_screens[screen_index].layername, 99999, g:layer())

  151.  

  152.         if (nil ~= widgets.variousbutton2) then

  153.           local button = widgets.variousbutton2.window

  154.           button:registerEventHandler(button.EVENT_BUTTON_CLICK, buttonHandler, "handleButtonClick")

  155.         end

  156.  

  157.         if (nil ~= widgets.variousbutton1) then

  158.           local button = widgets.variousbutton1.window

  159.           button:registerEventHandler(button.EVENT_BUTTON_CLICK, buttonHandler, "handleButtonClick")

  160.         end

  161.  

  162.         screen_changing = false

  163.       end

  164.  

  165.     end

  166.  

  167.   end

  168.   )

  169.  

  170.  




The switching (when you press a key on the keyboard) seems to work fine - the layout is loaded and displayed. But the problem is, the previous layout seems to 'stick around'. I had thought that g:shutdown() would clear out the currently-loaded layout, and it seems to do 'something' .. but elements are still showing up in the second layout.

Am I missing something obvious for how to switch out the previous GUI layer and let the new one have focus? I've tried a few things - as you can see, trying to use the layermgr to hide/show layers (doesn't seem to work), and so on .. so any guidance you can provide is definitely appreciated ..
;
--
ibisum@gmail.com
Got a MOAI snippet? Please consider adding it to http://moaisnippets.info/
User avatar
ibisum
 
Posts: 1250
Joined: Mon Oct 17, 2011 1:11 am
Location: Vienna, Austria

Re: GUI

Postby derickdong » Tue May 08, 2012 9:33 am

Sorry about that; I thought I had fixed that problem already. I've uploaded a new version that should solve this issue, which you can get from the link in the original post.

The problem was that I used MOAIPartition:propForPoint to determine which window the input was currently over. In previous versions of MOAI, I couldn't get MOAIPartition:propListForPoint to work properly, so when a window was set to be hidden, it was actually moved out of the view area. This new version uses MOAIPartition:propListForPoint, and runs through the list of returned props to find the topmost visible window.
derickdong
 
Posts: 63
Joined: Wed Nov 09, 2011 2:54 pm

Re: GUI

Postby ibisum » Tue May 08, 2012 11:56 am

Great, thanks for the quick update! I will check out the latest version and get it integrated with our branch.

By the way, have you considered firing up a repository for this project so we can contribute back? We've added a control (linegraph) to the GUI for our own purposes, it works both as a layout and programmatically and I believe this might be something we could contribute if only we had a way to do that ..
;
--
ibisum@gmail.com
Got a MOAI snippet? Please consider adding it to http://moaisnippets.info/
User avatar
ibisum
 
Posts: 1250
Joined: Mon Oct 17, 2011 1:11 am
Location: Vienna, Austria

Re: GUI

Postby derickdong » Tue May 08, 2012 1:38 pm

I managed to get a repository set up. If you go to the download link, and then click on the 'Source' link near the top, you should be able to see it. I rarely do this, so I'm not entirely sure I've got all the settings correct.
derickdong
 
Posts: 63
Joined: Wed Nov 09, 2011 2:54 pm

Re: GUI

Postby ibisum » Wed May 09, 2012 1:40 am

Just wanted to let you know, I still have the problem with the new version - I don't know if its because I'm doing something wrong with the layermgr, or if its just a bug .. but after doing g:shutdown(), I expect that the GUI elements get removed from the screen so that I can then paint a new GUI, but alas -- the old elements persist, somehow.

Is there something I should do to break down an existing GUI and start a new one besides g:shutdown()? Perhaps I should be using the layermgr to insert each GUI 'screen' in its own layer, then hide and show the layers as necessary? Sorry to be asking a stupid question, but its the intention behind the API that I do not quite understand - if you could explain it in a little post, it would be most helpful ..


EDIT: The version in the GIT repo does not contain your fixes to _calcInputOver() .. thought you should know.
;
--
ibisum@gmail.com
Got a MOAI snippet? Please consider adding it to http://moaisnippets.info/
User avatar
ibisum
 
Posts: 1250
Joined: Mon Oct 17, 2011 1:11 am
Location: Vienna, Austria

Re: GUI

Postby ibisum » Wed May 09, 2012 4:50 am

Another bug to report: window GUI elements with a "background=" field set (to some .png) appear to always be rendering *on top* of other GUI controls - for example, if I have a layout defined thus:

Code: Select all
  1.  

  2. local data = {

  3.         window1 = {

  4.                 widget = "window",

  5.                 name = "window1",

  6.                 background = "grids.png",

  7.                 --backgroundColor = { 0, 0, 0, 1 },

  8.                 pos = {0, 0},

  9.                 dim = {60, 50},

  10.         },

  11. button2 = {

  12.                 widget = "button",

  13.                 pos = {30, 78},

  14.                 dim = {30, 20},

  15.                 text = "button 2",

  16.                 images = {

  17.                         normal = {

  18.                                 {

  19.                                         fileName = "cathead.png",

  20.                                         color = {1, 1, 1, 1},

  21.                                 },

  22.                         },

  23.                         hover = {

  24.                                 {

  25.                                         fileName = "cathead.png",

  26.                                         color = {1, 0, 0, 1},

  27.                                 },

  28.                         },

  29.                         pushed = {

  30.                                 {

  31.                                         fileName = "cathead.png",

  32.                                         color = {0, 1, 0, 1},

  33.                                 },

  34.                         },

  35.                         disabled = {

  36.                                 {

  37.                                         fileName = "cathead.png",

  38.                                         color = {0, 0, 0, 1},

  39.                                 },

  40.                         },

  41.                 },

  42.         },

  43. }

  44.  

  45.  




.. the background image "grids.png" *always* appears on top of the button. Is there some priority setting missing here?
;
--
ibisum@gmail.com
Got a MOAI snippet? Please consider adding it to http://moaisnippets.info/
User avatar
ibisum
 
Posts: 1250
Joined: Mon Oct 17, 2011 1:11 am
Location: Vienna, Austria

Re: GUI

Postby derickdong » Thu May 10, 2012 2:22 pm

I think there's some confusion about how certain things work in and with the gui. This is my fault, as I haven't provided much documentation.

layermgr doesn't have any direct interaction with the gui system; its not really a part of the gui at all. The layermgr is more of an auxiliary class, which can be used to order the layers in your game. It doesn't know anything about any gui layer until the layer is explicitly added.

The gui system only ever creates one layer. This is the layer that would be added to the layermgr, and can be retrieved with the GUI:layer() function. When you're loading a layout, the second parameter is simply a prefix for the name of the gui elements, and not a name for a layer. I have found this useful, as I often use the same layout file in multiple places. For instance, I'm working on an old-school RPG, and on several screens, there is a party display. Rather than recreating this party display in several layouts (and creating a maintenance nightmare), I have a single layout file for it, which is included in the layout files for each of those screens. The prefix prevents name collisions between these various layouts.

The way I handle switching between different layouts is to have a parent window for each. When I don't want a layout visible, I just hide this parent window, and show the parent window of the layout I want to see. The shutdown function is intended for when the application is exiting. I'll look into why its not properly cleaning everything up.

Looking back at the demo code, I realize now that I'm not really illustrating how to create parent-child relationships between elements. Based on your last post, this sounds like what you're trying to do. The following code would create a window, and button which is a child of the window.

Code: Select all
  1.  

  2. local data = {

  3.         window = {

  4.                 widget = "window",

  5.                 pos = {0, 0},

  6.                 dim = {100, 100},

  7.                 backgrounds = "grids.png",

  8.  

  9.                 children = {

  10.                         button = {

  11.                                 widget = "button",

  12.                                 pos = {40, 45},

  13.                                 dim = {20, 10},

  14.                                 text = "Button"

  15.                         },

  16.                 },

  17.         },

  18. }

  19.  

  20. return data

  21.  



The button should appear on top of the window. These parent-child relationships can be nested as deep as you want.

If that's not what you intended, then you can use the moveToFront function. This is available in the gui object, and in any widget.

The reason the window is probably always in front is because the data variable is a table in the dictionary form (which is as it should be). The gui simply loops through the passed values, and creates the elements as it receives them. The initial priority of widgets is based on when they are created, with widgets created later appearing above the others. The internal ordering of the elements in a table dictionary is not necessarily the same as you see them in the code. So, when looping through these values, button2 is probably being created before window1, and so it appears below it.
derickdong
 
Posts: 63
Joined: Wed Nov 09, 2011 2:54 pm

Re: GUI

Postby ibisum » Fri May 11, 2012 1:23 am

Thanks for the great explanation derickdong - I'm sure it will help others to read your explanations in the future.

You're right that I didn't quite grok how to use windows to encapsulate the UI - now its pretty clear. At the moment I have multiple layouts in my app, each describing a separate 'screen', and right now my main GUI thread is hiding the GUI, then tear'ing down the GUI (g:shutdown()) and then re-creating the GUI with the 'next' layout. This actually works right now, and is functionally giving me the ability to change 'GUI screens' .. but if the intended use is to instantiate the entire GUI, arranged in windows, and then just hide()/show() windows as needed, then I will look at switching to that method. It would probably also make it much easier to apply transitions (sliding forms and so on) to the Windows as a group.

I understand the layermgr() is an 'outer class' intended for generalize Layer management. I currently treat the layermgr as more of a 'gui-layermgr' so that GUI's can be pushed into the layer stack and manipulated as a standard MOAI layer.

Anyway, thanks for the support derickdong - I'm a very happy moaigui user and I look forward to future use of it .. one thing I think you should do is fix the repository issue and then we can contribute our linegraph GUI control to it - we got it working and integrated well, even from a layout, and so on. It would be nice to be able to share this with you.
;
--
ibisum@gmail.com
Got a MOAI snippet? Please consider adding it to http://moaisnippets.info/
User avatar
ibisum
 
Posts: 1250
Joined: Mon Oct 17, 2011 1:11 am
Location: Vienna, Austria

Re: GUI

Postby derickdong » Mon May 14, 2012 9:44 am

ibisum wrote: one thing I think you should do is fix the repository issue and then we can contribute our linegraph GUI control to it - we got it working and integrated well, even from a layout, and so on. It would be nice to be able to share this with you.

I've update the repository to reflect the change to GUI:_calcInputOver.
derickdong
 
Posts: 63
Joined: Wed Nov 09, 2011 2:54 pm

Re: GUI

Postby ibisum » Mon May 14, 2012 11:11 am

Great - we are in crunch mode, but I have put in my TODO to send a pull request with our contributions- a linegraph control and a Path-like navigation control .. and I must comment that its become quite easy to implement nice GUI's once the paradigm you've set in moaigui sinks in.
;
--
ibisum@gmail.com
Got a MOAI snippet? Please consider adding it to http://moaisnippets.info/
User avatar
ibisum
 
Posts: 1250
Joined: Mon Oct 17, 2011 1:11 am
Location: Vienna, Austria

Re: GUI

Postby makotok1123 » Wed May 16, 2012 10:56 am

Hello.
Thank you for the wonderful GUI.

(1)
When you extract the "gui.rar" in mac, are extracted under the name, including the "¥" in the file name.
If possible, we would like you to compressed zip.

(2)
Contains a "¥" to the path of "require".
I think that would be better to change to "/" because it depends on Windows.
Attachments
mac-screen.png
mac-screen.png (161.57 KiB) Viewed 2659 times
makotok1123
 
Posts: 234
Joined: Fri Jan 06, 2012 11:31 am

Re: GUI

Postby derickdong » Sun May 20, 2012 12:17 pm

makotok1123 wrote:(1)
When you extract the "gui.rar" in mac, are extracted under the name, including the "¥" in the file name.
If possible, we would like you to compressed zip.

I've uploaded a zip version of the archive. Does compressing it with the zip format automatically handle the path separator? I didn't see any option for it, and I don't have any way to test it.

makotok1123 wrote:(2)
Contains a "¥" to the path of "require".
I think that would be better to change to "/" because it depends on Windows.

I've changed the require statements to use the forward slash.
derickdong
 
Posts: 63
Joined: Wed Nov 09, 2011 2:54 pm

Re: GUI

Postby derickdong » Mon May 21, 2012 12:40 pm

I've moved the gui repository to github, as this is where MOAI is currently located. Here is a link to the new download location:
https://github.com/derickd/moaigui/downloads

Unfortunately, I can't seem to edit the original post, so I've left the original repository up for now. However, I probably won't be updating the original googlecode version in the future. I may just end up creating an entirely new thread, if this becomes problematic.
derickdong
 
Posts: 63
Joined: Wed Nov 09, 2011 2:54 pm

Re: GUI

Postby ibisum » Mon May 21, 2012 1:54 pm

Great Derick -- I will submit a pull request for our changes to the framework in the next few days.
;
--
ibisum@gmail.com
Got a MOAI snippet? Please consider adding it to http://moaisnippets.info/
User avatar
ibisum
 
Posts: 1250
Joined: Mon Oct 17, 2011 1:11 am
Location: Vienna, Austria

Re: GUI

Postby makotok1123 » Mon May 21, 2012 4:00 pm

Hi, derickdong.

worked in the zip version.
Thank you for fix.
makotok1123
 
Posts: 234
Joined: Fri Jan 06, 2012 11:31 am

PreviousNext

Return to Made With Moai

Who is online

Users browsing this forum: No registered users and 0 guests

x