Scout Eclipse Outline tree width - width

When I start my application the online tree take all the space available.
I know I can resize manual, but it is annoying and bad user experience.
it looks like this :
I can't find where width of outline is set.
Marko

I think it is feature:
If you change the window size of your Swing client or change the width of the outline tree view and then close my client, these values are retained: When I next start the Swing client, the window and the views have the same size as when the client was last closed.
I have explained where the preference file is located here:
Re: Table columns order hidden cache??
I think you should confirm that the size you see is due to this pref file.
In my opinion this feature is good for the user experience. If the user changes the dimensions of the parts in the application, next time he opens the application, its settings will be restored.

Related

Weird results when trying to get UI elements to fit a dynamic size in Unity

I have a system where if you walk by a sign it will create a popup dialogue which is fine (just the popup part) but when I try to make it to where it can be adjusted based on how much text is displayed (Content Size Fitter) then I get something that literally does not make any sense to me whatsoever. When using World Space my font on Text components has to be 0 (also makes no sense) so that 1 letter isn't the size of 100 units and the combination of these 2 issues has almost made me go mad but that is the reason why I am here so you all can save me!
My setup for my sign :
Now this is the dialogue that is spawned viewed from the inspector (Not shown in the scene/game view yet) :
Now this is when the player walks near the sign with all the components you see in the screenshots :
As you can see the height of my dialoguePanel for some reason keeps going to 321 and New Years isn't close so this countdown I am not happy with. It should be adjusting to how much text is in it. I mean I just did a tooltip almost 100% identical except that the Canvas isn't World Space but Screen Space - Overlay. On top of all this it seems any text I use in World Space HAS to be font 0. Please help I am about to lose my mind.
World space canvas is a bit tricky. And guess what is even more tricky: content size fitter. One of solutions is that you add your dialog UI element manually in the scene at desired location and tweak its RectTransform values in inspector to get what you want to see in scene view and then save it as prefab.
Read more about How Content Size Fitter works and there is one more thing about UI when working with world space canvas. UI is way too bigger than your other scene elements. To solve this problem you have to scale it down as instructed in section Specify the size of the Canvas in the world.
Hope it helps :)

Is it possible to float the GLIMPSE Heads Up Display (HUD) bar top left, instead of bottom right of the browser window?

I am using MVC3, ASP.NET4.5
Love Glimpse, but finding the bottom right location frustrating, as it can disappear, and only by resizing the browser window, does it reappear again. May be to do with my master page and layers, not sure
So can one have the HUD appear top left.
Probably a simple html/ config issue.
Many thanks,
EDIT
Perhaps, on reflection this is not possible, as the detailed panes pop upwards, so no room. Would have to be a Heads Down Display :)
Currently its not really possible because of the design (as per your edit). But v2 of Glimpse should allow for such changes to occur as the design is different and should allow for this flexibility.

Xlib center window

I am writing a Xlib app where I want the window to be centered. I have used XMoveWindow with (desktopWidth - width) / 2, (desktopHeight - height) / 2 and it is roughly in the right place.
However the problem is that width and height are the client area, not the total area. Is there any way for me to get the total area of the window?
I need to use Xlib because I am using Glx and OpenGL. I don't want to use SDL, nor have a bulky graphics library.
There are various ways to go about this, depending on why you are doing it. The first two are "officially supported" by most window managers and described in specs, and then it descends into fragile hacks.
Semantic
The specs encourage you to use _NET_WM_WINDOW_TYPE rather than setting the position, if it makes sense to do so. See http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507144
For example, a DIALOG type (or a window with the WM_TRANSIENT_FOR hint set) will usually be centered on its parent window or on the screen, and the _NET_WM_WINDOW_TYPE_SPLASH (splashscreen) type will usually be centered on the screen. "Usually" here means "sensible window managers probably center it, and people using weird window managers are not your problem, let them suffer."
(Another hint along the same lines, though not what you want here, is _NET_WM_STATE_FULLSCREEN, which avoids manually sizing/positioning in order to be fullscreen.)
If semantic hints work, the window manager code to handle the positioning is hopefully smarter than anything one can easily code by hand, for example it might deal with multihead setups. Setting the proper semantic type may also allow the WM to be smart in other ways, beyond positioning.
Gravity
If there's no semantic hint in the specs that helps you, then you can center by hand. It's important to note that window managers are allowed to ignore a manual position request and some of them will. Some may only honor the request if you set the USPosition flag in WM_NORMAL_HINTS (this flag is supposed to be set only if the user explicitly requested the position, for example with a -geometry command line option). Others may ignore the request always. But, you can probably ignore WMs that do this; the user chose to use that WM.
The way you compensate for the window decorations (the titlebar, etc.) is to use the win_gravity field of WM_NORMAL_HINTS, which is originally in the ICCCM (see http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.2.3) but better-specified in an implementation note in the EWMH: http://standards.freedesktop.org/wm-spec/latest/ar01s09.html#id2570420
For WM_NORMAL_HINTS see http://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-normal-hints.html#XSizeHints (note: the type of the property is WM_SIZE_HINTS and the name of the property is WM_NORMAL_HINTS, so there are two different atom names involved).
To center, you would set the win_gravity to Center, which allows you to position the center of the window (including its decorations) instead of the top-left corner.
win_gravity is not often used and is likely to be buggy in some window managers because nobody bothered to code/test it, but it should work in the more mainstream ones.
Update, possible confusion point: There are other "gravities" in the X protocol, specifically the CreateWindow request lets you set a "bit_gravity" and "win_gravity"; these are different from the XSizeHints.win_gravity. The CreateWindow gravities describe how the contents (pixels/subwindows) of a window are handled when the window is resized.
Hacks based on guessing decoration size
It's a fragile hack, but... you can try to figure out the decoration size and then incorporate that into your positioning.
To get the size of the window decorations, one way is the _NET_FRAME_EXTENTS hint, see http://standards.freedesktop.org/wm-spec/latest/ar01s05.html#id2569862
For older-school window managers (but not the fancy new compositing ones, though those hopefully support _NET_FRAME_EXTENTS) the window decorations are an X window, so you can get your parent window and look at its size.
The problem with both of these approaches is that you have to map the window before the decorations are added, so you have to map; wait to get the MapNotify event; then get the decoration size; then move the window. This will unfortunately cause user-visible flicker (the window will initially appear and then move). I don't think there's a way to get the window decoration size without mapping first.
Descending further into the realm of awful hacks, you could assume that for windows after the first one you map, the decorations will match previously-mapped windows. (Not that this is a sound assumption: different kinds of windows may have different decorations.)
Implementation note: keep in mind that the decoration window can be destroyed at any time, which would cause an X error in any outstanding Xlib requests you have that mention that window and by default exit your program. To avoid this, set the X error handler when touching windows that don't belong to your client.
Override redirect
Using override redirect is a kind of bazooka with bad side effects, and not at all a good idea if your goal is just to center a window.
If you set the override redirect flag when creating a window, then the window manager won't manage its size, position, stacking order, decorations, or map state (the window manager's redirection of ConfigureRequest and MapRequest is overridden).
This is a really bad idea for anything the user would think of as a window. It's usually used for tooltips and popup menus. If you set override redirect on a window, then all the normal window management UI will be broken, the stacking order will end up basically random (the window will tend to get stuck on top or on bottom, or worse get in an infinite-loop restack fight with another client).
But, the override-redirected window won't have decorations or be touched by the WM, so you can surefire center it with no interference.
(If you just want no decorations, use a semantic type like SPLASH or use the "MWM" hints, don't use override redirect.)
Summary
The short answer is set the semantic hint if any is applicable, and otherwise use XSizeHints.win_gravity=Center.
You can kind of see why people use toolkits and SDL ;-) lots of weird historical baggage and corner cases in the client-to-window-manager interaction generally, setting window positions is just the beginning of the excitement!
win_gravity is not often used and is likely to be buggy in some window managers because nobody bothered to code/test it, but it should work in the more mainstream ones.
Apparently Unity haven't implemented this. Testing shows that XCB_GRAVITY_STATIC is not respected and by taking a quick look at Unity source code I could not find code implementing this part of the specification.

iOS view size and position hard-coded only?

I'm new to Macs and iOS, I got my app running on webOS, Android, and WPF/Windows. In all cases the size of, say, a 'widget' to display a bunch of text, can change depending on the dimension of the text to be displayed, as well as the position can be up against another widget. As the text size changes, the position will change so that all the widgets are crammed together nicely.
I've been searching for this capability in IOS4 in books and on-line, and it's starting to look like in iOS, you have to actually calculate the size of the text to be displayed in ViewText and then change the dimensions of ViewText, which of course then bumps other Views around to accommodate this size change. It sounds like a nightmare. Isn't there some other way to do this (like all the other GUIs can do) to size based on content, and to position relative to other Views like stacking them all together whatever size they are?
Same with ScrollView, it looks like the size of the window you actually see has to be manually specified as well, instead of, say, taking up the entire viewable window and then you can populate the ScrollView with a bunch of sub-views, some of which are below the initially viewable area? I tried this in Xcode4, but so far, haven't gotten it to work.
Similarly with creating an object with a NIB and instantiating that NIB onto an existing View, how does it determine where to position this NIB onto the existing screen?
Thanks!
Paul,
For the scrollview you need to set the bounds so it fills the screen or the area you wish it to occupy, it will then automatically generate scrollbars based on the layout within it. In the land of iOS you do have to do extensive layout work such as positioning and sizing your controls but you can also use the UIAutoResize (if I remember correctly) masks such as if they are anchored to a size, fill the area, etc. It's a little complicated to learn initially but you'll get the hang of it.
As for text you just need to use the right control, I believe what you want is a UITextView and set the options on it as needed.
When you view a XIB it's going to layout initially as you have it, again, you need to position your controls AND set their anchors (autoresize masks) so they adjust based on the screen size (phone vs. pad) and orientation: landscape vs. portrait.
HTH

Opening a new browser page on the second monitor

Well, simple situation. Is it possible to detect if a user has a dual monitor setup from a web application?
If this is possible, is it possible to open a child browser page on this second monitor, so the new window doesn't overlap the old one?
Reason why I ask: I'm working on a web application and at home I have a dual-monitor system. When I go to the administration part of this site, I want it to open in a new browser, preferably on the other desktop. Of course, I could just click, then drag the new window, but doing this automatically seems more fun. :-)
Don't think JavaScript has the proper functions for this. How about Java itself?
I don't think you'll be able to directly detect a dual monitor setup, but you can probably make a good guess by looking at their screen resolution, using javascript's screen.width and screen.height. If the ratio of the width to the height is 8:3, its a good chance they have 2 standard 4:3 monitors side by side. You can do a similar calculation for 16:9 or 16:10.
Using maxpower47's suggestion about resolution, the only way to display the page on the other monitor would be to open a popup, and use the options to set the top, right, width and height properties so the window will appear on the second monitor in a decent size.
Here is a link that describes how to do this: http://www.netmechanic.com/news/vol4/javascript_no7.htm

Resources