jungle gui

Monkey Archive Forums/Monkey Projects/jungle gui

ziggy

(Posted 2012) [#1]

I'm building an open source GUI library for Monkey Mojo. I needed a good GUI system for a contract work, so I started working on "junglegui". While there are other (more complete) guis out there, mine does provide a very different approach, as it is based on event handlers and events. It's very similar to .Net windows.forms in the way it handles events and data structures (mine is several orders of magnitude simpler). I've managed to do it very fast (while this may change as I add additional features) and the most important thing, is that it's ultra easy to code.

I'll be opening the project source code soon on googlecode for people willing to participate, and provide the module for free. meanwhile this is the first runable application that shows a very small amount of components. It's running in HTML5 (and it gives a very good number of FPS).

current system supports:

Base classes:
Gui (this is the main gui handler, it "contains" everything)
Control
ControlContainer (extends Control)
TopLevelControl (extends ControlContainer)
BaseLabel (Extends control and handles text)

Then controls:
Form (extends TopLevelControl)
Panel (extends ControlContainer)
Label (extends BaseLabel)
Button (extends BaseLabel)
ProgressBar (extends Control)
EditField (extends BaseLabel)
Timer (extends Control)
CheckBox (extends BaseLabel)
RadioButton (extends CheckBox)
ListBox (with automatic vertical scrolling support)

Woring in:
AutoScroll panel
Layered system
Renderer to enable high level of customization including vector-based renderer, and programatically adding animations to the Gui.

There's no ETA

This sample is a very minimalistic and "silly" test of what soon will be a "milestone" of this small module. I plan on adding several additional controls soon and menus.

If anyone is curious to see this in action:

http://www.jungleide.com/samples/junglegui01/

It's onlt html5 (nothing very impressive yet).

This is the list of currently supported Events:
MOVED, PARENT_REMOVED, PARENT_SET, BRING_TO_FRONT, SEND_TO_BACK, MOUSE_ENTER, MOUSE_LEAVE, LOST_FOCUS, GOT_FOCUS, MOUSE_DOWN, MOUSE_UP, CLICK, KEY_DOWN, KEY_UP, KEY_PRESS, PADDING_MODIFIED, PARENT_RESIZED, RESIZED, MOUSE_MOVE, INIT_FORM, TIMER_TICK, VISIBLE_CHANGED

But adding events is very easy, I'll be adding TEXT_MODIFIED soon among others.

As instance, this is the source code for the ProgressBar control (so you can see how easy it is to create new components):
[monkeycode]Import junglegui

Class ProgressBar extends Control

Method Render:Void()
Local drawpos := CalculateRenderPosition()
BackgroundColor.Activate
DrawRect(drawpos.X,drawpos.Y,Size.X,Size.Y)

Local width2:Float
if _max>0 then
width2 = Size.X * ( _value / _max)
Else
width2 = 0
endif

BarColor.Activate()
DrawRect(drawpos.X, drawpos.Y,width2,Size.Y)

SetAlpha(.3)
SetColor(255,255,255)
DrawRect(drawpos.X, drawpos.Y,width2,Size.Y/2)

SetAlpha(1)

SystemColors.InactiveFormBorder.Activate()
DrawBox(drawpos,Size)

if GetGui.ActiveControl = Self Then DrawFocusRect(Self,False)
if GetGui.GetMousePointedControl = Self Then
SystemColors.FocusColor.Activate()
DrawBox(drawpos,Size)
EndIf
End

Method Max:Void(value:Float) Property
if _value > value Then _value = value
_max = value
End

Method Max:Float() Property
Return _max
End

Method Value:Float() Property
Return _value
End

Method Value:Void(value:Float) Property
if value>_max Then value = _max
_value = value
End

Method SetValues(max:Float, value:Float)
Max = max
Value = value
End

Method BarColor:GuiColor() Property
Return _barColor
End

Method BarColor:Void(color:GuiColor) Property
if color = null Then
Throw New JungleGuiException("BarColor property can't be set to null!", Self)
return
EndIf
_barColor = color
End

Method New()
BackgroundColor = SystemColors.InactiveFormBorder.Clone()
_barColor = SystemColors.FormBorder.Clone()
Size.SetValues(250,20)
End

Private
Field _max:Float
Field _value:Float
Field _barColor:GuiColor
End[/monkeycode]

Skn3	(Posted 2012) [#2]

Looking very nice so far, do you reckon you'll make drag selection for the editable fields ?

ziggy

(Posted 2012) [#3]

I'll be doing selection of text first, then a "fake" text clipboard, and the very last thing could be drag&drop for text. But there a quite a lot of things to be done first. I hope, if there's interest, there will be people contributing when it goes on googlecode.

EDIT: This is a very small sample application using this Gui system:
[monkeycode]'This is required for the internal Events system, unless you want a HUGE application:
#REFLECTION_FILER="untitled2*|junglegui*"

'Import the gui system: (it also imports mojo, nothing else required):
Import junglegui

Function Main()
New Game
End

Class Game extends App
'This is the gui handler. All Gui elements are handled by a Gui instance.
Field gui:Gui

'This is a form that is shown in this application
Field form:MyForm
Method OnCreate()
SetUpdateRate(60)
gui = New Gui
form = New MyForm
form.InitForm(gui)
End

Method OnUpdate()
gui.Update()
End

Method OnRender()
Cls(255, 255, 255)
gui.Render()
End
End

Class MyForm extends Form
Field button:Button

Method OnInit()

'''
''' MyForm
'''
Events.Add(Self, eEventKinds.MOVED, "MyForm_Moved")

'''
''' button
'''
button = New Button
button.Position.SetValues(10, 10)
button.Text = "Sample button!"
button.Parent = Self
Self.Events.Add(button, eEventKinds.CLICK, "Button_Clicked")
End

Method Button_Clicked(sender:Control, e:EventArgs)
Self.Text = "Button was clicked in millisecond: " + Millisecs()
End

Method MyForm_Moved(sender:Control, e:EventArgs)
Self.Text = "Moved to: " + Self.Position.X + ", " + Self.Position.Y
End
End[/monkeycode]
This sample will create a form with a button, and also creates two event handlers:

1.- when the button is clicked, it modifies the Form caption text with the millisecond where the button was clicked, using the method Button_Clicked.

2.- when the form is moved, it shows its new location in the form caption.

I supose this makes clear how this Gui system is designed to work. People used to .net windows forms (hopefully) will find this very straight-forward. And people not used to it, hopefully will enjoy it, as it is prety much self-hanlded so it should produce a nice productivity gain.

Skn3	(Posted 2012) [#4]

Looks nice and straightforward! Only yesterday someone was asking me if there was a gui module for monkey. I pointed them to the challenger GUI but will pass this on too.

Beaker

(Posted 2012) [#5]

Looks great!

Some but not all of it works on my iPad2, particularly user input.

Good job tho.

ziggy

(Posted 2012) [#6]

I havent added anything like touch user input yet. but it's coming

CodeGit

(Posted 2012) [#7]

Nice, I like the .net approach to event handling so this will definitely be one to watch. If a GUI designer was added to JUNGLE IDE, supporting this module, then this would be perfect. :)

Paul - Taiphoz

(Posted 2012) [#8]

Now that would be really cool. all in one package.

Rone	(Posted 2012) [#9]

That's awesome... I really like winforms

Cant wait to see this on googlecode!

ziggy

(Posted 2012) [#10]

Is there any interest on making a dev team for this thingy? I'll be creating a Mercurial repository during the weekend. I would need help in developing several areas and also documenting everything so it can get to an usable state.

Rone	(Posted 2012) [#11]

I would like to join

Paul - Taiphoz

(Posted 2012) [#12]

I would love to but GUI stuff like this is really not my thing and I doubt I would be able to contribute much in the way of efficient code.

Samah

(Posted 2012) [#13]

What kind of contributions are you hoping for?
Don't say documentation. :)

ziggy

(Posted 2012) [#14]

Ok, I opened it here:
http://code.google.com/p/junglegui/

It uses Mercurial as the repository management tool. It's very easy to use and very reliable I can't recommend any other.

In order to contribute first: Use the library to make some small tests, see how well it works (or not) for you, and when you understand more or less how it works, if you wish, ask me to become a dev member and I'll happily add you.

I've added a couple of small pages about internal design of the GUI system, but the more I write, the more I see there are things that need to be explained, so it'll take time until there's a decent level of documentation. The GUI is very simple to use, but its internal design is very complete (while it needs lots of controls).

Before implementing any new control that introduces new features, please discuss ideas in the project home first. I thinking on a "renderer" approach to allow customization instead of basing it on xml + png or something like this. And there are other ideas that will need to be discussed.

@Samah: Documentation too... but I would love more controls to be implemented such as dropdown combos. Scrolling is another area that needs work and others. A full-frame TopLevelControl (as most in-game uses won't use floatable windows). I would love to have a tabbed document container control too... etc etc etc... If you use it, find it useful and miss something, let's talk (just to be sure we're not duplicating things and we follow the same design) and go for it!

Paul - Taiphoz

(Posted 2012) [#15]

+1 for having this thread moved into the Modules forum, where I think it deserves a thread..

gives the thread more visibility as well.

slenkar

(Posted 2012) [#16]

how about skinning

Nobuyuki

(Posted 2012) [#17]

looks real good. I was also working on an event-based paradigm GUI for my game, but it was only going to have a few widgets to begin with to support the game's system. Something like this looks pretty powerful.

how about skinning

override the Render method.

ziggy

(Posted 2012) [#18]

how about skinning

My idea is that you will be able to attach a "Renderer" instance to your GUi instances, and this renderer should get all drawing requests and conform them. So skining would be hardcoded, instead of being based on images and text documents.
The main reason to do this is:

1.- Doing it this way allows a much higher level of customization, as it could include all kind of animations, tweening, etc.

2.- There's nothing stoping you from creating a Renderer that takes a text file and a png and acts like a traditional static image-based skin.

I have no idea how/when this will come. There are areas that need lots of work first, like getting a decent components list, or implementin an "enabled/disabled" functionality on controls,

Rone	(Posted 2012) [#19]

ziggi,

Can you make me a member of the project?

Since I started exactly the same a while ago, I can easily contribute TrackBar, VerticalScrollBar, ListBox and ComboBox.

ziggy

(Posted 2012) [#20]

@Rone:

Of course! May I use the email in your profile?
Is there any way we could have open discussion?

Rone	(Posted 2012) [#21]

Yes, you can use the email in my profile.

Is there any way we could have open discussion?

Skype..or a project related google group?

ziggy

(Posted 2012) [#22]

@Rone: You have been sent an invitation. Welcome :D
Is google groups open? I was thinking of something more like a forum or the like, so any other possible contribur or user can see what's being discussed. Skipy or a group can be too closed, unless a group can have to form of an open community (haven't used them before)

ziggy

(Posted 2012) [#23]

a project related google group may do it, no? By the way, I'm currently writting a slider, just to be sure we're not duplicating tasks

Rone	(Posted 2012) [#24]

a project related google group may do it, no?

yes...its pretty much like a forum..

I'm currently writting a slider, just to be sure we're not duplicating tasks

ok, I have have just started the TrackBar control...probably the same as slider?

ziggy

(Posted 2012) [#25]

Yes, it's the same! Mine is not finished.
If it's already done, commit and I'll suspend mine,as it's not done 100% yet.

Rone	(Posted 2012) [#26]

ok, mine is also not finished... is up to you .. I can also start another control

btw: I did not received your invitation..?
---------Ok, I was just irritated that I did not get mail.. :)

Samah

(Posted 2012) [#27]

So basically you want an advanced table/grid control, am I right? ;)

ziggy

(Posted 2012) [#28]

@Samah: Yes! But We need to discuss scrolling on control containers first. I think we sould provide a control-less scrollbars that can be then used as part of the updating/rendering of any control that requires scrollbars. I mean, have scrollbar functionality that you can attach to any control or control container. I think we sould sort this first (that's what I would love to have some kind of discussion). Also, a special layer for controls displaying over-gui element. In the same way we have TipText now, we need a superior layer for controls like combo-boxes or menus or even (maybe) context menus. All this has to be rendered over the regular items, so it could be a good idea to design how this special rendering layer should be done, and how it sohuld integrate into current events system etc.
This is core functionality that maybe should come first than very complex components (but not sure).

@Rone: I've added your email to the googlecode page as a project member. Not sure it generates an email or not. Anyway AFAIK you should be able to commit changes.

Rone	(Posted 2012) [#29]

I think we sould provide a control-less scrollbars that can be then used as part of the updating/rendering of any control that requires scrollbars. I mean, have scrollbar functionality that you can attach to any control or control container.

What is the difference in contrast to that.. for example a ListBox control conatins a VScrollBar

Class ListBox extends ListControl

private
     Field _scrollbar:VScrollBar

public

	Method new()
		_scrollbar = new _scrollbar
		_scrollbar.Parent = Self
		Self.Events.Add(_scrollbar, eEventKinds.VALUE_CHANGED, "_scrollbar_ValueChanged")
		'...
	End

End

ziggy

(Posted 2012) [#30]

@Rone: By design, I think (but I could be wrong) that a regular control should not contain other controls unless it is a control container, or a complex control such as a Form or a dialog.In your example, how would you handle focus when the focus is set to the scrollbar? It is not realy leaving the ListBox, but it would cause Get/lost focus events. You can tweak it using the Msg system but this would only work if the ListBox is a control container which IMHO is a bit weird.

I think controls with scrollbars should have their own built-in scrolling capabilities.

That said, a good way to accomplish this is by creating a VScrollBar that is not a Gui control, but something that can used by any control in its internal update and rendering process.
What do you thing?

Have you been able to access the googlecode page?

ziggy

(Posted 2012) [#31]

I'll be adding some wikis about control creation for JungleGui in a while. This might help.

ziggy

(Posted 2012) [#32]

Before creating custom controls, please read this documentation. More docs to come soon: http://code.google.com/p/junglegui/wiki/WelcomePage?tm=6 (see the creating custom controls pages)

Rone	(Posted 2012) [#33]

Have you been able to access the googlecode page?

yes..also joined the group.

By design, I think (but I could be wrong) that a regular control should not contain other controls unless it is a control container, or a complex control such as a Form or a dialog.

I am also uncertain, in winforms, the VScrollbar does not change the focus at all...and it looks like the ListBox is using scrollbar controls, for example

That said, a good way to accomplish this is by creating a VScrollBar that is not a Gui control, but something that can used by any control in its internal update and rendering process.
What do you thing?

sounds good, this way ?

class ScrollBarConatiner
End 

class VScrollBar extends Control
private
   field _scrollBar:ScrollBarConatiner
End

ziggy

(Posted 2012) [#34]

Yes! In my opinion, it looks much better this way, as we will be able to handle scrollbars anywhere this way, without having to make any control a control container. As long as ScrollbarContainer is somethig that can handle and render a scrollbar, but that does not need to be a comple JungleGui control.

Samah

(Posted 2012) [#35]

If you wanted to do it something along the lines of Swing, you could use some kind of glass pane. Swing's JFrame contains a JLayeredPane which is used for exactly the kind of thing you're talking about.
http://docs.oracle.com/javase/6/docs/api/javax/swing/JLayeredPane.html

ziggy

(Posted 2012) [#36]

@Samah: Yes! that's exactly what I was wanting to implement. Not sure yet how to make this fit on the gui system. But I think this would be required in order to work with menus, comboboxes, etc.

Skn3	(Posted 2012) [#37]

What if you gave each control a message handler and it is upto the message handler to translate the events. So in the case of a scrollbar you could translate focus/unfocus events and avoid losing focus from the listbox. That way you wouldn't have to think "scrollbar" and "vscrollbar", you could just create a scrollbar, re-use it but changing the event handler.

Depending on how complex you plan on making your gui its going to start to become a pain to have to recreate "v" versions of gadgets that already exist. An example could be buttons, you may want to make an iconbar and re-use the button class but not lose iconbar focus when a button is clicked. This would mean you have to write a "v" button class from scratch. Another example is a number spinner, unless you abstract out most of your gadget runtime code you will definitely be repeating yourself a lot!

ziggy

(Posted 2012) [#38]

That's exactly what I'm trying to avoid as much as possible. Let me explain:

Having a complete scrollbar control and pretending to embed it on other controls forces you to recode all the internal event handling every time in any scenario you need a control with scrolling. This is very couter-productive and would raise maintenace time costs a lot. Also, it will force control designers to handle "internal" events and then modifythem, handle them and expose according "external" events to the complete Gui system, And this can never be as efficient as having a single event chain for each control.

Also, any new event that is added to the potential control ScrollBar will have to be tweaked again on controls containing scrollbars wich can be very disgusting to maintain in the long run.

My current design idea is provide a simple scrollbar class that is able to draw a scrollbar on screen given a drawing size, ItemsCount and a VisibleItemsCount propperties. This can be done in a way that this class can be used directly on the drawing and updating of any control that requires to expose scrolling. Once this is implemented, it's ultra easy to create a control that simply contains a single reference to this class, and call it ScrollBar control. So you have a scrolling control when you really need a control that is just a scroller, but also you get scrolling functionalities for any control that needs them, without being forced to modify all the eventsystem everytime you use scrolling inside a control, and you will be avoiding clashes between the standalone scroll control and the lower-level scrolling engine, exposed elements, etc.

In my experience this simplifies a lot things, makes code smaller, easier to maintain and better performant.

There's no need to make everything a control when designing a Gui, that's something some Gui designs fall in, and it complicates a lot things on the long run. It's always better to make controls as self-contained as possible when it's possible.

More or less this way:

Skn3	(Posted 2012) [#39]

Well it sounds like a solid plan. I made such a thing last week a "canvas scrollbar" that is managed by various container canvas based gadgets. I guess my point was that with a full GUI system your going to need to make a lot of virtual gadgets and it could get just as messy/limiting, but it sounds like you have a good plan ahead of you!

ziggy

(Posted 2012) [#40]

Well, I supose I have a very precise idea of what I want JungleGui to be. Regarding the scrolling, I had the idea of simplified version of this: http://msdn.microsoft.com/en-us/library/system.windows.forms.scrollbarrenderer.aspx

Skn3	(Posted 2012) [#41]

Oooo thats nifty (.net class). Id love to try some .net gui programming some day, it looks very tasty!

Just for kicks here is my scrolling thing: https://paste.lugons.org/show/klvVQRKDw1EP1mpBqhEh/

chrisc2977

(Posted 2012) [#42]

This looks great :)

John Galt

(Posted 2012) [#43]

Are people still working on this? I'm considering what GUI to use for a current project.

ziggy

(Posted 2012) [#44]

We're still working on it, but I'm on a small vacacions. Anyway, if you like what you see, you can contribute. I'll be back to it very soon.

John Galt

(Posted 2012) [#45]

Cheers ziggy.

Rixarn

(Posted 2012) [#46]

Hello Ziggy,

I'm also very interested in contributing with the GUI. So far it looks great!

ziggy

(Posted 2012) [#47]

Great! Send me your email details to the email in my profile and I'll add you to the project dev team

Rixarn

(Posted 2012) [#48]

Done :)