We are implementing different skins and we originally hard coded position and size based on our original skin (I know, I know. Don't get me started). Now that we have added additional skins some of the title bars and window borders are either narrower or wider than our original skin theme. So, the question is, how can we dynamically get the unclipped area of a parent window so we can set the proper position and size of the child window?
For example, if we create a FrameWindow and then add a child text window, the child window is bleeding into the frame window title. This result is undesirable. We want to offset the child window so it's not stepping onto the title bar or window frame.
We did find the CEGUI::Window::getUnclippedPixelRect() but we are not sure what we need to do with this data to derive a CEGUI::UVector2 for size and position. If someone could point us to an example we would greatly appreciate it.
Q: Setting window position so its not clipped by parent
Moderators: CEGUI MVP, CEGUI Team
-
CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Hi,
Some of that you describe - especially when talking about FrameWindow - are inherent weaknesses in the system as it stands at the moment. No doubt you'll have seen posts going back a couple of years or so where we state that a rewritten FrameWindow is our intention, this was and is the case, though the project is so far behind on such things that we couldn't honestly expect anyone to wait for this to get done.
With regards to your question about getUnclippedPixelRect, this function returns the unclipped screen pixel area of a window and is probably not so useful for positioning child content (if only because it also does not take any consideration of the skin assigned to the window, so you end up with the same type of issues).
As for work-arounds for this issue, my preferred work-around is pretty much worked through and described in the Wiki article An Introduction to Auto Windows, basically you add a 'client' window as part of the skin and add child content to that as opposed to the FrameWindow directly, the article discusses how to target your content into that automatically created client window from within xml layouts and also from code. I am under no illusions that this work-around is not a solution to all the issues, indeed it was never intended to be such, but it does offer a fairly simple means to achieve results that many people needed.
Another - more complicated - alternative work-around to this is to access the LookNFeel assigned to a window, and use it to access named areas that describe the inner rectangle / client area. You'd then use the size and position of the named area to offset and manage your child window content. I'm not going to give a concrete example of this at this stage; I don't have an existing example of this specifically, and it's something I'd rather not encourage to be honest. Having said this, if you want to see an example of how to access the LookNFeel and named areas, there is an example of this in this post that shows how to manipulate the size of a combo-box.
I know this post deals mainly with frameWindow and that you might be having similar issues with other window types, for this I'll just say that the basic theories can be applied to any window. So any window type can have a 'client' window added to it's skin if you go the auto-window route. If you go the other route, again any skin that does not already have an appropriate named area can have one defined for your use as you see fit.
HTH
CE.
Some of that you describe - especially when talking about FrameWindow - are inherent weaknesses in the system as it stands at the moment. No doubt you'll have seen posts going back a couple of years or so where we state that a rewritten FrameWindow is our intention, this was and is the case, though the project is so far behind on such things that we couldn't honestly expect anyone to wait for this to get done.
With regards to your question about getUnclippedPixelRect, this function returns the unclipped screen pixel area of a window and is probably not so useful for positioning child content (if only because it also does not take any consideration of the skin assigned to the window, so you end up with the same type of issues).
As for work-arounds for this issue, my preferred work-around is pretty much worked through and described in the Wiki article An Introduction to Auto Windows, basically you add a 'client' window as part of the skin and add child content to that as opposed to the FrameWindow directly, the article discusses how to target your content into that automatically created client window from within xml layouts and also from code. I am under no illusions that this work-around is not a solution to all the issues, indeed it was never intended to be such, but it does offer a fairly simple means to achieve results that many people needed.
Another - more complicated - alternative work-around to this is to access the LookNFeel assigned to a window, and use it to access named areas that describe the inner rectangle / client area. You'd then use the size and position of the named area to offset and manage your child window content. I'm not going to give a concrete example of this at this stage; I don't have an existing example of this specifically, and it's something I'd rather not encourage to be honest. Having said this, if you want to see an example of how to access the LookNFeel and named areas, there is an example of this in this post that shows how to manipulate the size of a combo-box.
I know this post deals mainly with frameWindow and that you might be having similar issues with other window types, for this I'll just say that the basic theories can be applied to any window. So any window type can have a 'client' window added to it's skin if you go the auto-window route. If you go the other route, again any skin that does not already have an appropriate named area can have one defined for your use as you see fit.
HTH
CE.
Thank you! That was very helpful. We don't feel so dumb now. We were concerned that the solution was staring us in the face and we couldn't see it. What you described above is exactly what we are seeing.
And now for the prod....
Is this being addressed in 0.7 or is this low priority at the moment? I ask because if a solution is forth coming soon (six months or so) then we can hold off. If it's longer than that then we will look into developing our own solution.
And now for the prod....
Is this being addressed in 0.7 or is this low priority at the moment? I ask because if a solution is forth coming soon (six months or so) then we can hold off. If it's longer than that then we will look into developing our own solution.
-
CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
I think a solution that does the right thing as far as what we term the 'inner rect' area is the way to go here. It's a reasonably simple modification for us to make and has potential to fix a majority - if not all - of these type of issues, while largely eliminating the need for full widget rewrites elsewhere (whether FrameWindow would subsequently get rewritten would then need to be re-evaluated).
I can easily add this inner-rect / client area fix as an item for 0.7 (it would be one of the smaller, easier to implement items on the TODO list), the real issue is when can 0.7 realistically expect to get a release?
I would like to be able to say that we'll definitely have a release within six months, though the fact that 0.7 is already delayed almost five months from my original target release window, combined with the fact that the real work for this release is only just getting underway, means that I really must refrain from giving estimates as to when a release might be made (experience shows that this always ends badly).
I understand your point of view as far as not wanting to expend effort on a solution if we are supplying effectively the same thing within the same timeframe; the issue I have to wrestle with is that if I say "yes, this will be released within six months" and then it isn't, I let people down, delay other people's projects and generally look like a bigger dick than usual On the other hand, if I say, as I am, that it may or may not be done within that period, and then it happens that a release is, in fact made (which would be the ideal scenario for us), I still look like a dick because then other people have needlessly wasted their resources. So effectively by asking what you did I am put in a situation where I can't win no matter how I respond
From the above, people might be thinking, that's a poor way to run a project and why not manage the project better? I think that would be fine for a project that employs guys on >50K salaries or what have you. For CEGUI which is two guys working on it when we might have time and motivation, the best laid project management plans fall flat on their face pretty quick (I've been doing this for a while now
).
CE.
Van wrote:Is this being addressed in 0.7 or is this low priority at the moment? I ask because if a solution is forth coming soon (six months or so) then we can hold off. If it's longer than that then we will look into developing our own solution.
I can easily add this inner-rect / client area fix as an item for 0.7 (it would be one of the smaller, easier to implement items on the TODO list), the real issue is when can 0.7 realistically expect to get a release?
I would like to be able to say that we'll definitely have a release within six months, though the fact that 0.7 is already delayed almost five months from my original target release window, combined with the fact that the real work for this release is only just getting underway, means that I really must refrain from giving estimates as to when a release might be made (experience shows that this always ends badly).
I understand your point of view as far as not wanting to expend effort on a solution if we are supplying effectively the same thing within the same timeframe; the issue I have to wrestle with is that if I say "yes, this will be released within six months" and then it isn't, I let people down, delay other people's projects and generally look like a bigger dick than usual
On the other hand, if I say, as I am, that it may or may not be done within that period, and then it happens that a release is, in fact made (which would be the ideal scenario for us), I still look like a dick because then other people have needlessly wasted their resources. So effectively by asking what you did I am put in a situation where I can't win no matter how I respond
From the above, people might be thinking, that's a poor way to run a project and why not manage the project better? I think that would be fine for a project that employs guys on >50K salaries or what have you. For CEGUI which is two guys working on it when we might have time and motivation, the best laid project management plans fall flat on their face pretty quick (I've been doing this for a while now
).
CE.
CrazyEddie wrote:I think a solution that does the right thing as far as what we term the 'inner rect' area is the way to go here. It's a reasonably simple modification for us to make and has potential to fix a majority - if not all - of these type of issues, while largely eliminating the need for full widget rewrites elsewhere (whether FrameWindow would subsequently get rewritten would then need to be re-evaluated).
...
I can easily add this inner-rect / client area fix as an item for 0.7 (it would be one of the smaller, easier to implement items on the TODO list), the real issue is when can 0.7 realistically expect to get a release?
If the modification is as simple to implement as you say (for your team, not for us), could the modification be incorporated into the current release 0.6.x (i.e. current trunk)? We update from SVN anyways so you wouldn't have to commit to a "full library release" to the public. I'm sure that there are many others in the CEGUI community who would benefit from this feature. Besides, we would be more than happy to test it for you.
If you would please look into the feasibility of implementing this ASAP we would greatly appreciate it. Like you, I sometimes say "oh, that's a simple thing" and then dive in to the meat of it to find out that the implementation wasn't so simple. I hate it when that happens.
BTW, I'll just through out some ideas we are tossing about and you can take it for what it's worth. Our current "idea" was to rename the current "setPosition" and "setSize" functions to "setPositionABS" and "setSizeABS" (ABS = Absolute, ignores clipping rect, that is, it works just as they do now). Refactor new "setPosition" and "setSize" to always work within the NON-CLIPPED rect. But, we are NOT familiar with the inner workings of CEGUI and have no idea what the real impact would be to implement this. Your obvious expert familiarity may have a far simpler or easier solution.
-
CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
The task I absolutely have to complete next is the renderer rewrites, so that's my priority for the foreseeable future (though I don't mean "foreseeable future" to necessarily mean many months or anything, just that it needs to be my primary focus). This is mainly because we see this particular job as being pretty much the saviour of the project; the somewhat 'old' style of current CEGUI combined with some performance bottlenecks is harming take up of CEGUI due to what people now expect from a modern GUI.
For my solution to the issue, what I am currently thinking (without having looked at much code or anything) is that the situation is currently as follows:
So basically to address the issue in a way that's flexible enough to be useful, we're looking at the following changes (and you will note that the heart of this is not a million miles from what you've come up with):
So anyway, the theory of this is that it's a set of pretty simple changes - not a 10 minute fix by any means - but, at least from my perspective, something that's easily doable over a weekend or so (unless, as you say, there are unforeseen issues).
I'm slightly confused here since you mention current trunk and 0.6.x
When you say current trunk do you mean trunk as in 'cegui_mk2/trunk' or actually 'cegui_mk2/branches/v0-6'? The changes can't be put into 'cegui_mk2/branches/v0-6' for binary compatibility reasons. It should be possible to commit the changes to 'cegui_mk2/trunk' within a reasonable time frame, if actual trunk code is no good, you'd need to patch v0-6 code (we'd be willing to provide such a patch based off of the mods in trunk proper once they're done).
So, in conclusion, yeah I'm willing to do it in the short-ish term, though the changes will have to be in the unstable trunk (cegui_mk2/trunk).
CE.
For my solution to the issue, what I am currently thinking (without having looked at much code or anything) is that the situation is currently as follows:
- - CEGUI has the concept of the main window area and an 'inner rect' area, for most cases these currently describe the same thing.
- The intention was that the inner rect describe an area within any window decorations - so this would be the client area on a frame window, or the area within the frame on a static image, and so on.
- Currently, the positioning and relative sizing are done based off of the main window area - I think this is incorrect, and it should be changed to use the inner rect, perhaps with an option to override where appropriate. This change would eliminate all of the positioning issues and stop content disappearing under the title bar of a frame window and so on.
- Imagery clipping should, believe it or not, already done according to the inner rect, but...
- Pretty much all the widgets do not provide an appropriate inner rect to be used - which is obviously also incorrect.
So basically to address the issue in a way that's flexible enough to be useful, we're looking at the following changes (and you will note that the heart of this is not a million miles from what you've come up with):
- - Add an option to specify whether child positioning / sizing use the main window area or the inner rect area. (as opposed to separate interfaces)
- Modify the child positioning / sizing calculations to use the inner rect area and reverting to the main window area where specified by the above option.
- Create a default means of accessing an inner rect from within a LookNFeel where one is assigned. This should defer to an assigned WindowRenderer where appropriate. The default implementation could basically be looking for a named area "inner_rect" to use, reverting to the current behaviour if no such area is defined or if no LookNFeel is assigned.
- Update the Falagard window renderers, where appropriate, to provide custom inner rect areas. These would generally use existing areas required within the assigned LookNFeel. The idea of this is to be used for example where some widgets' inner rect is not fixed and so a single named area is not appropriate - things like widgets with scroll bars, and also frame window, where the actual inner rect area depends upon the configuration of the widget.
So anyway, the theory of this is that it's a set of pretty simple changes - not a 10 minute fix by any means - but, at least from my perspective, something that's easily doable over a weekend or so (unless, as you say, there are unforeseen issues).
could the modification be incorporated into the current release 0.6.x (i.e. current trunk)? We update from SVN anyways so you wouldn't have to commit to a "full library release" to the public. I'm sure that there are many others in the CEGUI community who would benefit from this feature. Besides, we would be more than happy to test it for you.
I'm slightly confused here since you mention current trunk and 0.6.x
When you say current trunk do you mean trunk as in 'cegui_mk2/trunk' or actually 'cegui_mk2/branches/v0-6'? The changes can't be put into 'cegui_mk2/branches/v0-6' for binary compatibility reasons. It should be possible to commit the changes to 'cegui_mk2/trunk' within a reasonable time frame, if actual trunk code is no good, you'd need to patch v0-6 code (we'd be willing to provide such a patch based off of the mods in trunk proper once they're done).
So, in conclusion, yeah I'm willing to do it in the short-ish term, though the changes will have to be in the unstable trunk (cegui_mk2/trunk).
CE.
CrazyEddie wrote:So, in conclusion, yeah I'm willing to do it in the short-ish term, though the changes will have to be in the unstable trunk (cegui_mk2/trunk).
WOOT! That's great. But, if you get into it and find it more problematic and it ends up pulling you away from something more important (I.e. Rendering) then stick to what's a priority.
I believe we are pulling from the trunk. I was still under the impression the trunk was still a derivative of 0.6.x +enhancements/fixes code. I wouldn't recommend adding it to branches. I have a sneaky suspicion you think this might be interface breaking. I thought it might be too.
Stability is a relative concept.
-
CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Van wrote:I believe we are pulling from the trunk. I was still under the impression the trunk was still a derivative of 0.6.x +enhancements/fixes code.
trunk is currently reporting it's version as 0.7.0 - if you're not seeing that in the the log, you're not using trunk
Van wrote:I have a sneaky suspicion you think this might be interface breaking. I thought it might be too.
So long as there are none of those unforeseen issues spoken about earlier, I think it should not be API breaking, but it will be ABI breaking for sure. It's also a fairly large change in default behaviour.
Van wrote:Stability is a relative concept.
Absolutely!
CE.
-
CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Ok, I have done much of the work on this client-area / inner rect fix.
A quite amusing tale is that I had to actually start the initial work on this for my work on the renderer rewrite. So that gave me a head start, and now having done 90% of the rest of the work on the fix, that will assist me in my renderer work
Anyway, there is a patch on the mantis ticket for this issue, here: http://www.cegui.org.uk/mantis/view.php?id=260
This patch is against v0-6 branch, although there is no intention to commit the code there It's mainly done this way since, as mentioned above, I want to use it in my renderer rewrite branch, which is also v0-6 based at the moment. If the patch does not work straight off, you might need to change the line endings in the file. If you're using a trunk based version of the code after all, the patch will not work as-is and will require some adjustments to filenames and such.
Also be aware, if you did not read it on the ticket, that your layouts will obviously need to be re-adjusted to take into account the fact the origin of the windows for child content has moved in some cases (read FrameWindow).
I'm quite happy with these fixes - that were reasonably painless to do - since it fixes a handful of long standing issues, especially the FrameWindow one (and successfully saves me from having to rewrite the FrameWindow).
HTH
CE.
A quite amusing tale is that I had to actually start the initial work on this for my work on the renderer rewrite. So that gave me a head start, and now having done 90% of the rest of the work on the fix, that will assist me in my renderer work
Anyway, there is a patch on the mantis ticket for this issue, here: http://www.cegui.org.uk/mantis/view.php?id=260
This patch is against v0-6 branch, although there is no intention to commit the code there
It's mainly done this way since, as mentioned above, I want to use it in my renderer rewrite branch, which is also v0-6 based at the moment. If the patch does not work straight off, you might need to change the line endings in the file. If you're using a trunk based version of the code after all, the patch will not work as-is and will require some adjustments to filenames and such.
Also be aware, if you did not read it on the ticket, that your layouts will obviously need to be re-adjusted to take into account the fact the origin of the windows for child content has moved in some cases (read FrameWindow).
I'm quite happy with these fixes - that were reasonably painless to do - since it fixes a handful of long standing issues, especially the FrameWindow one (and successfully saves me from having to rewrite the FrameWindow).
HTH
CE.
-
CrazyEddie
- CEGUI Project Lead
- Posts: 6760
- Joined: Wed Jan 12, 2005 12:06
- Location: England
- Contact:
Van wrote:all we need to do is merge the patch and recompile, correct?
Yeah, that should be all, though if you're on windows you may need to convert the line endings on the file first.
CE
Useful Links: Forum Guidelines | Documentation | Tutorials | HOWTO | Videos | Donate to CEGUI | CEGUI Twitter
Return to “Modifications / Integrations / Customisations”
Who is online
Users browsing this forum: No registered users and 14 guests