|
My wife and I were driving home after a nice non-alcoholic lunch a couple of Sundays ago. There was rain in the air and the brightest rainbow I have ever seen arching across the sky. We came through the village of Stoneleigh and drove across the river bridge. Rather than turn sharp right along the main road, we decided to take the road up the hill in front of us. As I glanced right to make sure it was clear and then started to go up the hill, both my wife and I saw a distinct rainbow against the trees that form the wood on the right hand side of the road. It was projecting vertically down the trunks of the trees with a small but distinct gap between them, and I could see where it hit the ground. I have never seen anything like it before.
|
|
|
|
|
So now you are so rich you don't need to work anymore? 
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
|
|
|
|
|
I haven't worked for the last 7 years. I got made redundant when I reached 67, the b's. Now I just try and keep out of the way of Her Indoors and play at developing web-sites. I'm developing one at the moment using Metro UI rather than Bootstrap, and having fun doing it.
|
|
|
|
|
Cut the poetry and tell us wether or not you got the leprechaun and how much gold it had. 
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.
|
|
|
|
|
I couldn't even find a £5 note never mind anything shiny. And certainly no little person dressed in green with a red pointed hat.
|
|
|
|
|
Red pointed hat? Really? I thought everything was green in Ireland.
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.
|
|
|
|
|
Not everything. One of the best things is Ireland is a muddy brown with a nice creamy froth on top.
|
|
|
|
|
CDP1802 wrote: Cut the poetry and tell us wether or not you got the leprechaun and how much gold it had if it tasted like chicken.
FTFY
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Right. He wrote something like having had a clear target lock.
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.
|
|
|
|
|
Yes I saw the same thing a couple of weeks ago, in my case the rainbow was definitely between my viewpoint and a small white cottage.
|
|
|
|
|
That would have made it a bit easier to see the colours. I could only make out 4 or 5 of them. I don't think the outside ones where visible anyway.
|
|
|
|
|
It did, I remember thinking at the time, perhaps that's where the pot of gold thing came from, just the shear amazement of seeing a rainbow up close like that.
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
