What I find to be really irritating is there is no true sizer support in BYOND. Like while using wxwidgets you can use sizers to basically give controls a certain portion of the window or frame depending on the options you have set(expand, etc.). A feature like this would make building windows or frames for things such as options listing quite a lot easier to deal with.
It really sucks having to go through 30+ controls checking the anchors to make sure something sizes just how you want it to. A sizer could take care of a large portion of this and position the control on resize without all the extra effort.
Moral to the story = really useful for larger window creation.
Hope it's considered. :)
ID:132736
 Nov 23 2009, 5:48 pm
|
|
Sizers are a layout mechanism that has the ability to layout horizontally and vertically. From the wxWidgets documentation site: "They are used for laying out sub-windows inside a window". When placed, they should expand the entire window size and act like a container. The catch is all controls placed in here are justified to the top-left (this could be adjustable probably).
If the sizer was set to use a vertical orientation, it would place all proceeding controls below the first one. If horizontal, to the right. The sizer can have a "minimum size" and "maximum size" to keep the controls from shrinking or expanding after a certain X,Y size is met. Also, it has the ability to place sizers inside other sizers. It has the ability to really do quite a few things that I can't really sit here and ramble on about for hours. Since I have trouble clarifying on certain subjects, I found a decent demo(with pictures to give an idea of how they work) for you. Hope this helps: http://neume.sourceforge.net/sizerdemo/ Edit: Here is a more in-depth look at it: http://zetcode.com/tutorials/wxwidgetstutorial/ layoutmanagement/ | |
In both those cases the "sizer" is being created in backend code instead of in an editor. I still don't quite grok what they're using the term to mean but my best guess is that it's something like the layout interfaces in Java.
What I mostly don't get is why there's a need for something like this. Individual anchors might be difficult to manage if you have a lot of controls, but I'm sure we can come up with better ways to handle that. This sizer concept, to the extent I understand it at all, seems to be built for cases where anchoring like what we do isn't available. Lummox JR | |
The sizer concept in general would probably end up replacing BYOND's "anchor" concept if it were to be built in to the program(s). wxFormBuilder is a GUI Editor for wxWidgets that creates an xml-ish formatted file that holds all the data required for editing.
A more-or-less comparative terminology to a sizer would be BYOND's grids allowing controls, maps, etc. inside the cells using variable row height to allow different sized elements. In any case, if you have a better(more convenient for you and everyone else) solution to making anchors less of an arse pain(Or maybe a flexible new container that you can add controls to its "list" during runtime, maybe each row in the container could have its own set of variables to control the elements within it) I'm really curious as to what it is. I just feel having just anchors as the primary(and almost only) means of layout is somewhat inconvenient at times. | |
Tekken wrote:
The sizer concept in general would probably end up replacing BYOND's "anchor" concept if it were to be built in to the program(s). wxFormBuilder is a GUI Editor for wxWidgets that creates an xml-ish formatted file that holds all the data required for editing. Replacing the anchor concept with something similar is not really a viable option at this point. Enhancing the anchor concept is a different matter. In any case, if you have a better(more convenient for you and everyone else) solution to making anchors less of an arse pain(Or maybe a flexible new container that you can add controls to its "list" during runtime, maybe each row in the container could have its own set of variables to control the elements within it) I'm really curious as to what it is. We may at some point be able to refine our editor to handle editing multiple controls at once, which would greatly simplify the problem of setting anchors for multiple elements. There are probably other ways to handle this too, like having a short list of anchors in use and applying them to the currently selected object with the click of a button. Lummox JR | |
i don't see how you can think anchors are a pain in the ass but sizers are godsent. anchors are much easier to work with for simple uis, and are much better suited for byond.
skins on byond are rather flat and don't change drastically at runtime, the only nested controls we ever see are from child controls. because of that i don't see the advantage of using sizers, a little thinking and anchors is all you'd need. i've used all kinds of layout management in wx (without a gui builder), wxpython's anchors was by far the easiest to use. | |
I should have suggested this during the 3.5 to 4.0 transition before the custom interface engine was applied to BYOND, but I wasn't around and now I can see how that can be regretted.
I really hope in the future some goodies can be added to give the interface editor some nice features(Putting controls into categorized tabs would be nice, because that thing will eventually get B.I.G. and clunky sitting right beside the window you are editing.) ---------- On a slightly similar subject, however, I notice when I join a game that has a large number of interface objects(buttons, windows, panes, etc.), it can sometimes take anywhere from 2 to 10 seconds to load it. Does this have something to do with the way they are currently being parsed as txt files? | |
I never said I used the wxFormBuilder, Crashed. I find wxWidgets to be one of the easiest frameworks I've ever used in C++ and Python alike. It is filled with quite a few nice features that I couldn't live without.
| |
Tekken wrote:
I should have suggested this during the 3.5 to 4.0 transition before the custom interface engine was applied to BYOND, but I wasn't around and now I can see how that can be regretted. Well it's unlikely a Java-like layout manager method would have been chosen anyway, really. I find that approach has too many drawbacks to be suited for an environment like this. But I see significant value in making anchors easier to edit than they currently are. I guess the big question is, what options do you think the interface could have that would improve on this? I can think of a couple off the bat myself, but I'd really like to poll the room. On a slightly similar subject, however, I notice when I join a game that has a large number of interface objects(buttons, windows, panes, etc.), it can sometimes take anywhere from 2 to 10 seconds to load it. No; parsing text files is not computationally that expensive. Creating the individual controls shouldn't really be taking that long either. I'm more inclined to think it's either something in our sizing code acting prematurely and doing more work early on than it's supposed to do, or else it's just a natural consequence of the types of projects involved. A 2-10 second load time is usually more indicative of the world itself taking a bit to come up, which is often caused by large maps. Lummox JR | |
Crashed wrote:
i've used all kinds of layout management in wx (without a gui builder), wxpython's anchors was by far the easiest to use. I suspect the main issue Tekken has is that with a GUI builder, anchoring is inconvenient. And I do agreee on that--after building some interface windows into SotS II and having to wrestle with anchors in it, I think there's plenty of room for improvement. What might be nice would be having more buttons on the layout bar that would give users more choices besides our current auto-anchor method. Often for instance in a project I only want to anchor things to the nearest edges/corners, so one simple anchoring option might automatically do that. There are probably other good ways to quickly set anchors as well, so having some suggestions for that would help. Lummox JR | |
Well it's unlikely a Java-like layout manager method would have been chosen anyway, really. I find that approach has too many drawbacks to be suited for an environment like this. But I see significant value in making anchors easier to edit than they currently are. First off, to keep things organized, I would definitely have to propose a tabbed interface to keep things tidy(You could put the layout options in one of the tabs and get some more screen space going on). Anyhow, having to nest child windows within each other IS NOT fun at all, and just clutters up the current interface editor with 10 different child windows in the window/pane listings. A control that could handle more than two children would probably be pretty useful. Also, a minimum size for the window would be great to keep controls from overlapping during resize(Not sure if this is already available.) Minimum and maximum sizes for controls is a must. Some border resistance! This would allow you to set the border boundary size so controls wouldn't overlap if set to 1 or higher(0 disables of course). Options to make a control that are initially small expand the whole width or height of the window automatically and resize accordingly with the window would also be nice(but not required). I can't currently think of anymore off the top of my head, but I'm sure there's tons more that could make the current anchoring system more convenient for everyone. No; parsing text files is not computationally that expensive. Creating the individual controls shouldn't really be taking that long either. I'm more inclined to think it's either something in our sizing code acting prematurely and doing more work early on than it's supposed to do, or else it's just a natural consequence of the types of projects involved. A 2-10 second load time is usually more indicative of the world itself taking a bit to come up, which is often caused by large maps. This happens in BYOND-built programs like Chatters, which I don't recall having an extremely large map, though I do notice the window and controls resize anywhere from 5 to 6 times before being very usable at all. You should really take a look into sqlite as an alternative for the large maps loading slow, however. | |
Tekken wrote:
First off, to keep things organized, I would definitely have to propose a tabbed interface to keep things tidy(You could put the layout options in one of the tabs and get some more screen space going on). Not a bad idea, although it doesn't address how to make anchors easier to deal with. Anyhow, having to nest child windows within each other IS NOT fun at all, and just clutters up the current interface editor with 10 different child windows in the window/pane listings. A control that could handle more than two children would probably be pretty useful. I wouldn't mind a variant of the child control that could handle multiple panes. I had an idea in mind quite a while back for a four-square that had two splitters, one horizontal and one vertical, though I have doubts as to its usefulness in general. Maybe what you'd prefer would simply be a way of handling the child controls in situ in the editor, that's a thorny problem but I think not insurmountable. Also, a minimum size for the window would be great to keep controls from overlapping during resize(Not sure if this is already available.) Minimum window size has been requested before and may be doable. There are certain limitations of course, like it has to at least be small enough to fit on the screen, but otherwise I think this is probably quite feasible. For panes it's a bit hairier. As an example of why, consider what would happen if the pane was selected into a tab control that was already too small for it. Would the tab control try to extend outward pressure on any controls or the window holding it? I actually have some ideas along the lines of "pressure" being used to auto-size interfaces, but none of them have really congealed yet. Minimum and maximum sizes for controls is a must. I believe both of those would be incompatible with the anchor system, unless they were implemented in a way that set a de facto minimum size for the window (per the idea above). But this would probably also have to impact panes, which is an iportant consideration, so that brings us back to the pressure thing. Options to make a control that are initially small expand the whole width or height of the window automatically and resize accordingly with the window would also be nice(but not required). We have those options already, although it's just a simple "fill window" and doesn't account for width and height separately. If you do fill a window with a control though you can use the existing auto-anchor option to keep it filling the window. I can't currently think of anymore off the top of my head, but I'm sure there's tons more that could make the current anchoring system more convenient for everyone. Most of the above ideas don't actually relate to making the current anchoring system more convenient to work with in the editor; you're talking more about ways of changing the system itself. Those sorts of ideas are by nature much harder to implement. I'm really referring to just editor stuff. This happens in BYOND-built programs like Chatters, which I don't recall having an extremely large map, though I do notice the window and controls resize anywhere from 5 to 6 times before being very usable at all. You should really take a look into sqlite as an alternative for the large maps loading slow, however. Chatters does a lot of stuff to try to self-size its interface, so what you're probably seeing is the result of winget() being called a bunch of times. It's slow-starting by virtue of the way it was built. I don't really see how sqlite factors into this, since the map format is completely unrelated to database issues at all. The only reason it takes a big map a while to load (and it's not actually all that long, I find) is because the server has to do initial setup on all the vars and types and such that are included. The mechanism by which maps are loaded is actually quite efficient. Lummox JR | |
Oh, you meant for the editor layout options(literally).
A good one would be to anchor the selected controls nice and snug against one another. Another somewhat nice one might be lets say you have an input and an output above it, you want the Y size to scale up and down for the output, but not the output... an anchor to make one control scale x and y and another just x would be nice.(This could be inversed for another anchor.) An nice button to anchor a control to it's current y position and to the left edge of the window could be useful.(Also able to inverse for a variety of anchorage here.) That would cover some of the more annoying areas where anchoring can get quite irritating.(Opening that properties window gets old fast) If you got anymore, add them... The more the merrier(To an extent, of course) | |
Lummox JR