|
My God!
That bluddy global warming's even making rainbows fall from the sky!
We're all Doomed!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Sadly the pot of gold was at the other end. 
Marc
|
|
|
|
|
Don't wanna know what was in the pot on your side then... 
Anything that is unrelated to elephants is irrelephant
Anonymous
-
The problem with quotes on the internet is that you can never tell if they're genuine
Winston Churchill, 1944
-
I'd just like a chance to prove that money can't make me happy.
Me, all the time
|
|
|
|
|
Recently I have revived my little pet project, a GUI that runs on top of a 3D engine, formerly with XNA and now with MonoGame. You wanted an article and I have finished a small sample program to demonstrate how to set up the whole thing and there is plenty left for follow up articles, like how to design and script (in XAML) a UI theme, how to use the MVP classes or layouting the views in XAML and introducing the controls.
The sample needs a little more commenting, but works fine otherwise. There is just a certain behavior that does not seem right, which ever way I make it.
Usually the 3D engine renders scenes in the background, but this will not be needed for a demo program. So I just put a large Image control with a nice background to fill the entire background and a button to end the program.
Now this is the problem: The UI must constantly figure out which control the user is pointing at and send messages to it. For that purpose there is a 'hit test' that walks through the tree of controls and determines which control is 'hit'.
Things get complicated when one control is placed on top of another, like the image and the button. Logically both have been hit and there are several ways of resolving the problem:
1) The 'hit test' goes through the complete control tree and finds all controls that have been hit. If there is more than one, it would also have to figure out which one is the topmost. This would work for any scenario, but may get a little slow with bigger control trees.
2) If two controls overlap, the topmost one must be a child of the one in the background. This way the hit test must not go through the entire tree. As soon as it found a control that has been hit, only its children must be searched for a better fit, the entire rest of the tree can be ignored. This is much faster because it can stop searching once it has a result and the question which control is in the front and which is in the background is automatically resolved by the parent/child relationship. I would prefer this one, but it has the ugly side effect that any overlapping controls that are not children would be ignored, receive no messages and just be dead.
3) I could do both, but that would not be much better than 1) alone.
So, how would you want a UI to behave? A strict parent/children design rule with dead controls if you don't comply to it? Or better a solution that always works, but may get into performance problems sooner or later?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Quote: Definetely better a solution that always works, but may get into performance problems sooner or later!
FTFY
* CALL APOGEE, SAY AARDWOLF
* GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
* Never pay more than 20 bucks for a computer game.
* I'm a puny punmaker.
|
|
|
|
|
Then it would come down to 3) after all. If you think about it, you may need both: Totally independent controls ans some with a parent/child relationship. The children, for example, move along when the parent is moved.
Modifying the hit test to look through the entire tree is easy. If I don't want to get into lengthy comparisons of portions of the tree in order to find out which control is in the front, I will have to get this aspect into the sorting of the tree structure as well. This way (preferrably) the first result will be the control I'm looking for.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
den2k88 wrote: Definetely Definitely
FTFTFYFY! 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
What if you reversed the problem. Instead of a tree of controls that know where they live, what about a tree of space that knows what controls are in it? Meaning:
- root - the entire surface
- 4 children, each representing 1/4 quadrant of the surface
- Each of those has 4 children, representing their 1/4 of the parent's 1/4 quadrant.
- etc, down to something reasonable.
Now, a hit test traverses the spatial tree very efficiently to identify controls within a quadrant and then you just iterate through the controls in the lowest containing spatial quadrant.
The "con" of that approach is that you need to manage controls in their quadrant as they are placed, moved, and removed, and handle a control spanning up to four quadrants. However, the overhead for that is much lower because you are probably working with just a single control at that point. To make the management easier, you can also have the control know what quadrant it currently belongs to.
Marc
|
|
|
|
|
Kindof similar to the octree of graphics objects in the 3D engine. Ok, that would cover the spatial order.
The real problem is a little more complex. My tree may be unbalanced in several other ways. Simply looking at which layer a control is in does not tell wether it's over or under another control.
It begins very simple: Every control has a collection with 0-n children, which may again have children. When drawn, the controls are drawn in the order they are put into their parent's collection. This way, if two children overlap, the later one always will appear above the earlier one. Also, children are clipped to their parent's bounds, so they have no relevance to possible overlapping issues of the parent.
Sounds ok? I will only have to bring a selected control to the front by moving it to the last position of the collection it is in and everything is well.
Not quite. The root and top levels of the tree are not rendered at all. They are workspaces, used as layout objects and links in the tree. The root workspace fills the entire screen and is opened when the UI is initialized. The program then can go on and nest as many subdivisions of this root workspace until it finally opens views inside those workspaces. To make it even more complicated, there are also separate window workspaces, which are not subdivisions of the main worspace, but also children of the control that opened them. They can be moved freely, like a form and are most likely to overlap, depending on where they are dragged and released.
Their position in the control tree would define the order in which they are drawn, but this order would be unchangable. I could not simply bring it to the front or push it to the back.
My best idea would be to keep those workspaces in a separate list instead of the tree. The hit test and the rendering method would both have to work with both structures then, but then the window workspaces would be treated as peers in a list and their vertical positions would be determined again by their position in the list.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
Well, that just proves the adage "the devil is in the details."  Yes, the real problem is a little more complex (not sure I would use the adjective "little", though!)
However, what you're describing sounds incredibly flexible -- workspaces within workspaces, if I read that post correct. Can't wait to see what you've come up with!
Marc
|
|
|
|
|
Yes, the workspaces are subdivided and different presenters and views are opened in the separate workspaces.
Something like this: When the program starts, there is only the root workspace and a 'controller' object is started, a kind of 'main' object as starting point. this root controller gets the main workspace.
Let's say we want the main controller to oversee three things:
1) Show some 'Hello user' splash screen or animation.
2) Display a view to log in.
3) Close all this stuff when the login was sucessful.
There are different ways to do this, but this would work:
The root controller subdivides the main workspace into two halves, let's say simply two halves of the root workspace.
Then the main controller opens a new controller that is in charge of the splash screen part and gives it one of the divisions as its own workspace. This splash controller will open a splash presenter and a splash view, which will simply do their stuff in a loop until told to stop.
The root controller will also do the same for the second half of the workspace, only that this controller is in charge of the login part. Meanwhile the root controller will sit back and wait until the login controller reports that login was successful. If it fails or is canceled, the root controller will simply terminate the program.
Meanwhile the login controller will open a login presenter and a login view in its assigned workspace, interact with the user and eventually report the results back to the root controller.
Assuming that the login was successful, the root controller will close both controllers it had open, which in turn close all views and presenters they may still have open. It will also delete its two subdivisions of the workspace, which are no longer needed.
Now it's time to open another controller, this time the main application controller. The root controller will give it its whole workspace, any data the login controller may have passed, start it and then sit and wait until the main application controller wants to end.
This already works very well, but the workspaces still are a little too static. How about giving them some visible parts after all, like handles for resizing?
The window workspaces are alternatives to this subdividing method. They are like separate windows or forms that hover over the rest of the UI. The data structures must reflect that and everything will be fine. They just don't belong at some random location within the tree.
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
"Consumed during Easter, a blended meal sickens." (6,5)
Good luck.
Andy B
|
|
|
|
|
Simnel cakes (anagram of meal sickens)
Do I win £5?
Slogans aren't solutions.
|
|
|
|
|
Well done! Your turn tomorrow.
I have put your £5 in an Easter Egg hidden somewhere in the UK, don't spend it all at once! 
Andy B
|
|
|
|
|
I thought that egg I found had a rather chewy centre!
Sorry... 
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
|
|
|
|
|
As long as it has a tiny picture of Jane Austen on it, I'm off to look for it!
Slogans aren't solutions.
|
|
|
|
|
I spent more time than I should have trying to fit "Seminal cakes" in even though the letter count was wrong  - hadn't heard of "Simnel cakes".
Anyway - they say "you learn something new every day" so I have met quota early and can now go back to bed. 
|
|
|
|
|
I rather like the idea of seminal cakes.
Quote: "... the Eccles cakes at Chez Trevor are no mere triumph of culinary delight that work their mysterious magic upon even the most jaded of palettes; they are a veritable game-changer. If ever a fat-laden, sugary confection could be described as being seminal, Chez Trev would be the place for this to occur. Bathos, pathos - these buggers have the lot - most assuredly the finest cakes known to mankind ..."
- Charles Campion (The Sunday Times)
Slogans aren't solutions.
|
|
|
|
|
Much better than Simmental [^] Cakes, which can be found in the open meadows or Ireland (and should not bee eaten)
|
|
|
|
|
Ah, those would be the ones that they sell in Gregg's.
Slogans aren't solutions.
|
|
|
|
|
One of my friends has claimed it, saying mechanical keyboards are only for PC game nerds and do not fit Apple's style.
https://rvhuang.github.io/
|
|
|
|
|
I know a number of people with MACs and they all have mechanical keyboards.
|
|
|
|
|
So it's a matter of the reformed vs. the orthodox church of Apple fanbois?
The language is JavaScript. that of Mordor, which I will not utter here
This is Javascript. If you put big wheels and a racing stripe on a golf cart, it's still a f***ing golf cart.
"I don't know, extraterrestrial?"
"You mean like from space?"
"No, from Canada."
If software development were a circus, we would all be the clowns.
|
|
|
|
|
CDP1802 wrote: deformed
FTFY
* CALL APOGEE, SAY AARDWOLF
* GCS d--- s-/++ a- C++++ U+++ P- L- E-- W++ N++ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t++ 5? X R++ tv-- b+ DI+++ D++ G e++>+++ h--- ++>+++ y+++* Weapons extension: ma- k++ F+2 X
* Never pay more than 20 bucks for a computer game.
* I'm a puny punmaker.
|
|
|
|
|
He is right, but anyone is free to try the keyboard he likes.
I have on my PC a Apple style keyboard, so the feeling is like on my iMac.
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
