Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / GUI System using 9 slice scaling

Author
Message
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 11th Apr 2018 17:56 Edited at: 11th Apr 2018 18:06
Hey,

currently I need a good GUI system that i'm capable to extend and is using 9 slice scaling for example that nice one from scraggle's 9 sprite scaling thread.
I have made an attempt some time ago, but before I reinvent the wheel and try to understand what I did there, I want to ask you for your opinion.
It is especially important to me that I can drag the windows around and inherit the parent attributes like position and scale.

My GUI attempt: GUI.zip
I think I left the project at the Gui_GetFocus() function which isn't working as intended

Attachments

Login to view attachments
PartTimeCoder
AGK Tool Maker
9
Years of Service
User Offline
Joined: 9th Mar 2015
Location: London UK
Posted: 12th Apr 2018 10:40
I recently started a GUI system for my own apps but I opted for an image-less colored sprite system so it can be themed by just setting colors and alphas, its not very pretty but its functional, I did try out some user solutions and although some of them are really fantastic I wanted to code my own, my embedded PureBasic UI plugin was causing a IMA somewhere I spent months trying to track it down and gave up in the end which was a real shame because the 3D editor was nearly finished and packed with features and the IMA killed it., I started again with LAG ui system but I ran into a couple of bugs using the 9slice that I could not fix so I thought the best thing to do was start my own system, 3rd party code is all good till it goes wrong! lol

I have only got as far as a menu + popup menu, toolbar, statusbar and scrollbars, I am working on a listbox and when thats done I will add in the easy bits like buttons, inputs and such, I wanted to get the complicated stuff done first, I have not got round to child windows yet but I think I will give each child window a type array of its child objects id and type and when the window is moved or resized it knows what objects it must perform actions on, I might run into issues with depth that I will need to give some thought but overall I am happy with the results so far.



Attachments

Login to view attachments
Scraggle
Moderator
21
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 12th Apr 2018 10:51 Edited at: 12th Apr 2018 10:54
I have a GUI system that works well. See Animation Station for a screenshot.

To answer this:
Quote: "It is especially important to me that I can drag the windows around and inherit the parent attributes like position and scale."

What I have done is given every 'gadget' an array that lists all of its children and also an ID to its parent.
You also need to use two co-ordinates for each gadget. I call them abs.x, abs.y and rel.x, rel.y - Absolute and relative co-ordinates.
You need the absolute co-ordinates so that you can check for mouse-over and mouse-click events.
And the relative co-ordinates are relative to the gadgets parent, so if you move a window (for example) all of its children will also be moved without you needing to worry about re-positioning them. Of course, your move function will need to adjust the childrens absolute co-ordinates but the relative co-ordinates will stay the same.

The parent/child system is also essential if you want to hide/disable any gadget. You can simply apply the attribute to the parent and all children will be affected. Obviously, you will need to write the function to traverse the children and apply the attributes but once its written then its just a simple function call to the gadgets parent to activate it.
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 12th Apr 2018 13:53 Edited at: 12th Apr 2018 13:56
First of thanks for the answers !

PartTimeCoder wrote: " I think I will give each child window a type array of its child objects id and type and when the window is moved or resized it knows what objects it must perform actions on"

I already have what PartTimeCoder describes:

Actually I also prefer writing my own GUI lib if I can manage it

Scraggle wrote: "What I have done is given every 'gadget' an array that lists all of its children and also an ID to its parent"

Why do I need the parent ID ? Can't you run from top to bottom till you find the child in question and then take the current ID as the parent ID ?
Well then you can't get the parent ID of the current 'gadget' (one would need to run the search again)
So I think the actual question is when do I need the parent ID ?

Scraggle wrote: "You also need to use two co-ordinates for each gadget. I call them abs.x, abs.y and rel.x, rel.y - Absolute and relative co-ordinates"

I guess thats the part where I made a mistake.

Just curious did you guys looked over my code
Scraggle
Moderator
21
Years of Service
User Offline
Joined: 10th Jul 2003
Location: Yorkshire
Posted: 12th Apr 2018 14:01
Quote: "So I think the actual question is when do I need the parent ID"

I don't have my code to look over to check but off the top of my head, one obvious answer would be when you change a gadgets relative position or indeed simply draw it. You need to know what position it is relative to - which would be its parents absolute position.

Quote: "Just curious did you guys looked over my code"

No, I'm at work but I'm sure I can find time at the weekend.
PartTimeCoder
AGK Tool Maker
9
Years of Service
User Offline
Joined: 9th Mar 2015
Location: London UK
Posted: 12th Apr 2018 15:45
Quote: "Just curious did you guys looked over my code"


I did yes and while looking at it I realized I was going to have issues with z-order once I introduced child windows, I should have started at that point like you did.
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 12th Apr 2018 16:05 Edited at: 12th Apr 2018 19:25
@Scraggle: You are right in terms that it is handy to have the parent ID but not necessary like i mentioned above we could just run through the child's again (recursive), but the more I think of the parent ID the more I like it.
Quote: "No, I'm at work but I'm sure I can find time at the weekend"

Thanks, I appreciate that.

@PartTimeCoder: We could start from scratch together ?

[Edit]Should I maybe create one array with all gadget ID's and Types so I can iterate through them, instead of one array per gadget type ? [/Edit]
PartTimeCoder
AGK Tool Maker
9
Years of Service
User Offline
Joined: 9th Mar 2015
Location: London UK
Posted: 13th Apr 2018 01:47 Edited at: 13th Apr 2018 01:48
If starting from ground zero I would say go with one nested type array for the whole project, a base gui >> windows >> gadgets that way your inheritance is sorted from the get-go you just need to write a good depth buffer system to handle focus but that should not be to hard, you was heading in the right direction in your gui project the base code is already there.

I, like yourself, went with a separate global for each object which I now see as a mistake and may start again .... << and there's the reason why nothing ever gets finished, to dam pedantic!!

Quote: "We could start from scratch together ?"


I could possibly take you up on that, if we could agree a base system and implement a gadget type switch system I'm sure we could both write code for gadgets and include them like modules

a quick air-code example
janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 13th Apr 2018 15:20 Edited at: 13th Apr 2018 18:31
I'm in. I can adapt to the syntax tGUI=Type gGUI=Global, I like to start every function with GUI_ as the namespace,
Quote: "gadget type switch system"

Is this a thing ?

Hm with the layout you posted above we would need to "hard code" every child gadged into the type, I mean what if we want a button in a window in a groupbox in another window ? we would need to make sure the groupbox can also handle the window and other way around, instead of just writing every gadged type and linking them via another data structure(global array with ID and type in my example).
I don't mind if it takes longer as long as it will be dynamic and highly reusable.

I happily wait for Scraggles and other opinions.

[Edit]
I want variables for the sprite ID to end with SpriteID so you know if it is an ImageID or MemblockID I don't mind to write some more letters (copy pase) as long as you can easily make out what's the Variable for.
Are we using camelCase ?
We could use this sprite sheet for the images: GUISheet.zip

[/Edit]

Attachments

Login to view attachments
PartTimeCoder
AGK Tool Maker
9
Years of Service
User Offline
Joined: 9th Mar 2015
Location: London UK
Posted: 14th Apr 2018 14:38
if we treat things like groupbox, panel, container, scrollarea (anything that can contain child objects) as windows in their own right, embeddable windows, so the main tGUI_Window just needs an extra field for its type (-1= main window, 0 = gui window, 1=groupbox etc etc)

so a button is parented to the group box and the groupbox is parented to the window, I will play with some code later.

I agree though having each object in its own type is probably not the best way to go, a shared generic object type containing all possible attributes would probably be a better solution, just working out the inheritance structure for embeddable windows may require an extra type, not sure till I start typing some code lol.

janbo
16
Years of Service
User Offline
Joined: 10th Nov 2008
Location: Germany
Posted: 14th Apr 2018 16:14 Edited at: 14th Apr 2018 17:00
I know exactly what you mean
Adding a new attribute to the type is not too bad, we can go with it...

Are you in the AGK Slack Group ? And I would like to try Git... never made a Git project myself, and I feel like sharing our progress.
Just playing with Git: https://github.com/jan610/AGK_GUI

Login to post a reply

Server time is: 2024-11-23 21:40:05
Your offset time is: 2024-11-23 21:40:05