Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#3248 closed defect (invalid)

OMEdit enlarges vertically when switching into Modeling mode

Reported by: massimo ceraolo Owned by: Adeel Asghar
Priority: normal Milestone: 1.9.4
Component: OMEdit Version: trunk
Keywords: Cc:

Description

The issue was tested on a win8 laptop, with the very common 1366x768 resolution, and OM r25117.

Steps to reproduce the issue:
1) go into plotting perspective
2) resize OMEdit so that it occupies vertically roughly 80% of the available vertical space (screen1.png)
3) click on "modeling" to change perspective
=> OMEdit has resized so that it vertically falls below the taskbar and more! (screen2.png)

This is especially annoying since it occurs many times, in normal usage.
In fact, when OMEdit is kept in a window, in normal usage one switches continuously between modeling and plotting perspectives, and therefore he has to continuously move and resize the OMEdit window to switch into plotting perspective. Unless he gives up the lowest part of OMEdit window.

Attachments (2)

screen1.png (154.1 KB ) - added by massimo ceraolo 10 years ago.
screen2.png (150.2 KB ) - added by massimo ceraolo 10 years ago.

Download all attachments as: .zip

Change History (15)

by massimo ceraolo, 10 years ago

Attachment: screen1.png added

by massimo ceraolo, 10 years ago

Attachment: screen2.png added

comment:1 by Adeel Asghar, 10 years ago

I tried like almost 100 times but was unable to reproduce the issue.
Does this happen always or just in some cases?
Does this happen when a particular model is opened?

comment:2 by massimo ceraolo, 10 years ago

When it starts to happen, it happens continuously.
Yesterday I had that behaviour on a new computer with a new resolution, and I thought that there was a connection with the resolution, but today on that PC initially I was not able to reproduce the issue. Then it happened again, but I could not find a repeatable procedure to reproduce it.

I will make additional tests and in case I find something that can be reproduced, I will add an additional comment to this ticket.

If I were in our position, I would also have a look at possible places in which the code changes the windows size without any user resizing action is made.

Version 1, edited 10 years ago by massimo ceraolo (previous) (next) (diff)

in reply to:  2 ; comment:3 by Adeel Asghar, 10 years ago

Replying to ceraolo:

When it starts to happen, it happens continuously.
Yesterday I had that behaviour on a new computer with a new resolution, and I thought that there was a connection with the resolution, but today on that PC initially I was not able to reproduce the issue. Then it happened again, but I could not find a repeatable procedure to reproduce it.

I will make additional tests and in case I find something that can be reproduced, I will add an additional comment to this ticket.

If I were in our position, I would also have a look at possible places in which the code changes the windows size and no user resizing action is made.

There is no code where window size is changed. The size of MainWindow is only set in MainWindow constructor i.e before even OMEdit is made visible to user for the first time.

in reply to:  3 comment:4 by massimo ceraolo, 10 years ago

There is no code where window size is changed. The size of MainWindow is only set in MainWindow constructor i.e before even OMEdit is made visible to user for the first time.

This means that this issue is very difficult to identify and solve since it may be caused by everything and happen only on some computers or some computer configurations.

I think that the only thing to do is to wait.
After all it may dissolve naturally, in case it depends on writing in other parts of code to an unallocated memory cell (and that part of code is independently modified). Or it could become clearer in case a combination of events that triggers it is found.
Fortunately it is a minor issue. We can live with it.
Thank you for spending time on it.

comment:5 by Adrian Pop, 10 years ago

It could be some Qt bug.

comment:6 by Adeel Asghar, 10 years ago

I was just thinking about this issue and I think it might be related to Windows Aero Snap. So it might be a feature instead of a bug. Could you try disabling it?
Go to Control Panel->Ease of Access->Ease of Access Center->Make the mouse easier to use and check Prevent windows from being automatically arranged when moved to the edge of the screen.

comment:7 by massimo ceraolo, 10 years ago

there's a special PC on which the issue is very frequent.
It is in the classroom in which I give lessons on Fridays.
So I will let you know on Friday evening.

comment:8 by Martin Sjölund, 9 years ago

Milestone: 1.9.31.9.4

Moved to new milestone 1.9.4

comment:9 by Adeel Asghar, 9 years ago

What is the status of this issue now?

comment:10 by massimo ceraolo, 9 years ago

It's not easy to check now since it appeared frequently on a classroom pc, last year.
I will held classes again with OM in that room next semester, but in the meanwhile PC has been changed.

I propose to close this ticket by now. In case I see again something similar, I can open an new one.

comment:11 by Adeel Asghar, 9 years ago

Resolution: invalid
Status: newclosed

comment:12 by Martin Sjölund, 9 years ago

Milestone: 1.9.41.9.4-1.9.x

Milestone renamed

comment:13 by Martin Sjölund, 9 years ago

Milestone: 1.9.4-1.9.x1.9.4

Milestone renamed

Note: See TracTickets for help on using tickets.