I'm working on a Perl/Tk GUI. It will have three main areas. Two of them side by side on top and then another one below the two.
I could just use grid geometry management. The upper two would have a row weight of 2. The lower one would have a weight of 1.
This would be good for the starting position, but the user needs the ability to adjust the sizes.
Looking at the Tk documentation, PanedWindows can also have a weight, but I can't figure out how to access it.
As I have it now, with my Paned frames, the upper and left children are minimum size, everthing else fills the area below and to the right. If I adjust the main window. only the lower and right windows are resize. Worst of all, I can resize the window and make some of the children disappear.
I want to maintain the current relative sizes.
How do I do this? I'm not tied to paned, grid, pack. Whatever works.
Sounds like you are using frames in Tk. While I have never used Perl/Tk, I am kind of savy html which Tk is probably based on html. So, you might want to look into frames and framesets at Frames in HTML documents on the W3C site.
It sounds like you need 1 frameset with 2 frames for the top and another frame for the bottom.
I hope that this helps.
Related
My problem is very difficult to describe, so hopefully (with the pictures I provide) someone can help me figure this out. If you are confident you can fix it, I'm willing to pay if I have to. I need this fixed.
I cannot for the life of me figure out how to work with the Unity canvas/layout groups. I have a series of canvases that only show one at a time (think of them as screens). Inside each canvas are components (the first one is a graph and timer, and then a data panel and some buttons.
Here is an image of what I'd like each of the panels to look like (only one of these will be open at a time):
Essentially, I just want each sub-canvas (the dark gray boxes) to inhabit ~50% x 50% of the screen, and when the orientation is horizontal/vertical, tile them accordingly.
Each Child panel (the dark gray) only needs to change. The children inside of the panel can stay and scale relative to the parent canvas.
I have tried EVERYTHING, dug through the documentation, and have run out of options.
Have you tried adding a Layout Element to all of those gray panels with a Flexible Width or Height setting? The screenshot below shows how to have two panels that are side by side, both occupying half the width of their container. (Both have a Flexible Width setting of 1.)
The two Panels are children of the Canvas that has a Horizontal Layout group like this:
I need to move an image down through canvas so that its central point would be where is now its top edge. It makes some 50 points, but if I decrease y by 50, it moves to different part of the screen on devices with different screen size. I guess, it's because my main canvas is set to scale with the screen size. So I suppose I need to manually divide the number 50 by my screen height and then code to multiply by Screen.height? Isn't there a more convenient way to move UI objects?
Allow me a second question: Do you think it is even wise to make a game purely on canvas? My game is simple 2D, only slightly animated and contains many layout elements, so I decided to go for it, but I have hard time to grasp the UI position rules.
you may have the problem of the anchoring.
Unity UI totally depends on the Anchoring, if you have got right anchoring there is no issue.
For example. if you anchored something at the Center than changing left and right value moves them according to the center anchor.
for clear visualization, you can paste a screenshot of the behavior.
I'm new to cocoa development and wondering what the right approach would be to the following:
I have a window with controls who's size is dynamic. In other words, I don't know the width of the window in advance. I also want to give the window a padding of 15px. In the CSS world I would simply pad a div and make it inline to accomplish this. I can't seem to figure out how to do this with NSWindow/NSView.
Question is too vague to be sure, but IFF I'm understanding you, you want a subview of the window to resize itself to always be 15pixels from the left and right sides of the enclosing window (for example).
here are the two constraints (as set up in Interface Builder, but you can do the same thing from code):
That's one view whose width is set to adjust while keeping the left and right padding to the window frame at 15 pixels (points actually, but don't worry about that).
As your view hierarchy gets more complicated you'll use different techniques for different pieces of the layout. Which is why matt was suggesting that you haven't been specific enough to actually answer a question. (What specific part of what you are you trying to do isn't working and what did you try that didn't work?). I've shown you the first step of the simplest outer layer above and it reflects a principle that carries down through your view hierarchy, but there are other cases - two items with the same width, three items with the same horizontal space between them, and so on - that require different techniques.
It sounds reading the auto layout documentation all the way through would be helpful for you. It talks about different types of relations (Equal is what I used below) and some on techniques. Unfortunately Apple's documentation situation is a bit of a mess at the moment which makes this more difficult than it should be (sigh).
What used to be the definitive auto layout guide is "unmaintained" and the place that documentation seems to be heading is incomplete and certainly less accessible. The most useful part for this context is the NSLayoutContraint documentation, though that links to the "Unmaintained" document noted above (sigh).
I'm investigating the feasibility of using Raphael for a user-research project. One of the features allows for users to drag images onto a canvas and we record where they placed it. The pool of images is potentially quite large and we'll have them in a scrollable box in the tool.
I put together a quick wireframe of the issue I'm looking into since it'll probably be clearer than my explanation.
Please see the wireframe:
I'd stick with straight HTML/CSS and use jQueryUI draggables, as you mention in your comment.
You don't appear to need any of the drawing/display features SVG offers, yet if you went that route, you'd have to build your own custom scrolling behavior (instead of setting a CSS overflow-y rule) and picture layout algorithms (again instead of using CSS floats or something).
You can create a scrollable region using Raphael.
Create the viewport with fixed
dimensions (say 800x600)
Draw the images with increasing y value. After few images, the y value will go beyond 600. It will be drawn but will not be visible in the viewport.
Create a scrollbar using raphael rects. Attach drag events to the scrollbar handle rect.
When the handle is moved, translate all the images accordingly.
For e.g. lets assume in step 2, you had drawn all the images and the bottom most point of the end image is having y value 2000. Assuming the scrollbar has length 500, each dx movement of the handle will have to translate 2000/500 = 4dx. You can calculate the handle length similarly using ratios.
Since everything inside a single Raphael paper the dragging of images will work seamlessly. You will have to maintain the positions of each images.
You might find this demo similar
Remember you can always use getBBox when you drop. In this case it's rects but images would be the same..
http://irunmywebsite.com/raphael/additionalhelp.php?q=bearbones
In IB, there is a dropdown in Size Inspector showing "Layout" and "Frame". I know what a frame is, but I don't know what the layout is in this case. What is the difference?
When lining controls up and measuring their distances from each other it's often desirable to think about the controls' locations in terms of the visual space they occupy on the screen, rather than simply their raw frames. In many cases, the visual rectangle a control occupies, and its frame are vastly different. For example, a regular size push button looks to be about 20 points tall on the screen, with a 2 or 3 point drop shadow. In reality, the frame of a properly configured push button is 32 points tall, not ~23. This extra 9 points points of padding isn't visually apparent.
"Layout Rectangle" is the name Interface Builder uses for this concept.
The layout rectangle is useful to look at for applications of measuring and sizing. The Apple Human Interface Guidelines might make the statement that "Two push buttons aligned vertically, and horizontally next to each other should have 12 points of space separating them horizontally." This 12 points of space separating the buttons should be measured from the button's layout frames, not their raw frames.
Many built-in IB elements have a separate "layout" versus "bounds" rectangle. You can see the difference by showing them using the "Layout>Show XXX Rectangles". The drop-down indicates which rectangle the coordinates refer to.
On Mac, this impacts UITextFields that are labels for example. If you switch between Layout and Frame, the X coordinate will change by 3 pixels. I haven't played with iPhone controls to see if it impacts any of them. It doesn't come up a lot.