Screen real estate: reducing the margins between containers #8512
Comments
|
Please use screenshots to justify your reasoning, so that we know what you're talking about. Note that trying to use productivity software on a display of less than 1920×1080 pixels is generally futile. Not much can be done for such displays, but you can try the "VeryLoDPI" scaling mode which can be found in the Editor Settings (in 2.2-legacy and 3.0 Git). |
|
ok, not trying to irritate anyone :)....but any one will tell you the same thing more real estate is better...I just figured since the 3.x update is happening it might be a good time to look into these things. and I updated my post...sorry I did not label it as request...that was my fault. |
|
I don't see how removing those small margins would help with screen real estate or with the feeling that things are cramped. It would actually make things look even more cramped IMO. BTW, this is the upcoming theme for 3.0: #7294 (comment) |
|
I agree they are quite big compared to other software, especially when looking at this script editor border: |
|
it makes a difference. I don't see how anyone would be against a bit more workspace? |
|
Thumbs up. Also think it looks better just from a cosmetic point of view |
|
I took another screen grab and cut out all the unused space for a better representation, the red rectangles are 64x64 pixels. If I were to want any one window larger it would be the main viewport...2D, 3D or scripting. |
|
I'm fine with screen real estate, and users in general do not complain much.
I think in your particular case, creating a custom theme that uses less
margins is desirable..
…On Apr 25, 2017 1:30 PM, "justinbarrett" ***@***.***> wrote:
I took another screen grab and cut out all the unused space for a better
representation, the red rectangles are 64x64 pixels.
[image: window_empty_space]
<https://cloud.githubusercontent.com/assets/27959760/25383191/44794296-29bb-11e7-9f3c-d9aad19d8718.png>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8512 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF-Z298eyPfVeZZ7NZBOVkyqA5LG-ZfOks5rzdlMgaJpZM4NGJoy>
.
|
|
I'm sorry you feel that way. I think a lot of users feel differently...I cannot speak for all of them though. |
akien-mga
changed the title
|
Well it wouldn't hurt to try reducing margins by 2px and see how it looks like. But it's very exaggerated to think you can gain as much space as shown in the above screenshot: this is not "unused" space, having some margins between UI elements is actually necessary for legibility, and in particular to avoid having everything feel cramped together, so removing them altogether is not an option. So if someone can give it a try, would be interesting to have before/after screenshots of various margin settings (could even be made configurable I guess). |
|
well there is the boarder of the window plus the empty pixels in between those boarders, it is not marginal they seem to have 8px boarders with an additional 16 pixels in between and double that for each side etc etc...this is my estimate..I didn't actually calculate it |
|
I agree we should reduce boarders. It would marginally (pun intended) increase screen real estate and make the who interface feel more professional and serious. |
|
I agree, I don't really care about "professional and serious", but the
usability would improve, especially in areas that already feel cramped,
like the animation editor, the inspector, etc
…On 26 April 2017 at 18:54, William W Wold ***@***.***> wrote:
I agree we should reduce boarders. It would marginally (pun intended)
increase screen real estate and make the who interface feel more
professional and serious.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#8512 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AGVmPXlVxPp5Z8OR0XJfxHvC3IrpWTRtks5rz70WgaJpZM4NGJoy>
.
|
|
@akien-mga ...it's not just the padding between workspaces, it is also the workspaces have boarders themselves. They add up if you count 2-3 workspaces side by side. In my second snapshot they clearly add up.. the screen with the 64px boxes is NOT an exaggeration....it was taken at the same resolution as the initial post. I only rescaled the initial post due to a bandwidth limitation at that moment. Besides, why draw extra components if they add not function?...aside from taking some space up. Anyway...I have said my peace. I feel that the owners of this module are not interested at this stage...and that is..well it is what it is... just thought I should bring it up. I'm not going to keep pushing if all the responses I get from the module owners side are underplaying it as opposed to taking un biased consideration...I agree...it is not a show stopper, but a little polish goes a long way. I will leave this as it, I hope it stays open and does not get marked as resolved...I hope further discussion is had, but I will not participate, I think my perspective is clear. |
|
Unfortunately, most is done with containers, so there is little chance of
fixing.
Also, many of the panes are regions you can drag around, so making them
dissapear is not a solution.
This might improve a bit in 3.0, but don't have high hopes of having a
margin-free user interface.
…On Apr 27, 2017 5:31 PM, "justinbarrett" ***@***.***> wrote:
@akien-mga <https://github.com/akien-mga> ...it's not just the padding
between workspaces, it is also the workspaces have boarders themselves.
They add up if you count 2-3 workspaces side by side. In my second snapshot
they clearly add up.. the screen with the 64px boxes is NOT an
exaggeration....it was taken at the same resolution as the initial post. I
only rescaled the initial post due to a bandwidth limitation at that
moment. Besides, why draw extra components if they add not
function?...aside from taking some space up. Anyway...I have said my peace.
I feel that the owners of this module are not interested at this
stage...and that is..well it is what it is... just thought I should bring
it up. I'm not going to keep pushing if all the responses I get from the
module owners side are underplaying it as opposed to taking un biased
consideration...I agree...it is not a show stopper, but a little polish
goes a long way. I will leave this as it, I hope it stays open and does not
get marked as resolved...I hope further discussion is had, but I will not
participate, I think my perspective is clear.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#8512 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AF-Z2wjFLOM6w3cydSc5eYEdQ6YX85xbks5r0LS4gaJpZM4NGJoy>
.
|
|
I have seen some of the more recent builds lately and have noticed the margins are considerably smaller...I'm ok with compromise..it is looking good and I am satisfied that people looked into it for themselves...good job GD team. I will close this so as to knock it off the tracker, if it is being tracked....may be a good idea that any issue that goes without change for over 6 months gets automatically closed...not sure how you all are working it I am not around here too often. |
godot 3.x all OSs'
I would like the huge boarders on the godot windows to go away, they just take a lot of screen realestate and make me feel claustophobic...it is the little handles on the edge of the windows...if you look at blender 3D the individual windows have not boarders, maybe a 1 pixel line separator and it helps with that "oh so cramped" feeling...
the areas marked with red lines are the areas I am referring to..I feel they can just go away.
I hope this is the correct place to post this, as it feels more like a bug tracker....the link on the godot dev forums took me here though...so???
The text was updated successfully, but these errors were encountered: