FreeEMS Issues - OLV |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0000509 | OLV | User Interface | public | 2012-01-20 05:58 | 2012-09-21 22:39 |
|
| Reporter | sim | |
| Assigned To | BenFenner | |
| Priority | low | Severity | trivial | Reproducibility | always |
| Status | closed | Resolution | fixed | |
| Platform | Debian unstable, stumpwm, intel | OS | Linux | OS Version | sid |
| Product Version | 0.0.3-SNAPSHOT | |
| Target Version | 0.0.3 | Fixed in Version | 0.0.3 | |
|
| Summary | 0000509: OLV main window fails to use window size commanded from the window manager. |
| Description | At initial program load, while running stumpwm (a tiling window manager), in fullscreen mode, the application draws a window that does not utilize the entire space available for it. This results in a smaller than necessary program, set within a big grey 'L' representing the unused screen space.
To fix this, the screen can be split, and then the spit can be removed. This results in a OLV main window that has been properly maximized for the space it is allotted.
I suspect that the issue is a combination of the application assuming that it can assert an initial window size, and the application expecting a resize event if changed.
I suspect that firing a resize event after painting the initial window would solve this problem, but I have not tested my theory.
For example: http://puddle.ca/~sim/volvo/FreeEMS/OLV/OLV-small.jpg [^] |
| Steps To Reproduce | Install Debian unstable. Install stumpwm and set as window manager. Invoke OLV (I used MVN for this). Observe window that does not use up the available space. |
| Additional Information | This is likely a problem for a small fraction of users. Most do not use tiling window managers, and those that do, expect this kind of thing. None the less, the window manager follows the X spec, and should work correctly with applications that respect that spec. The fact that 99% of users use a conventional window manager is no excuse to not fully follow the spec.
That said, I may be the only user to notice for years, so don't freak out. In this red-hot moment, on the other hand, I'm a significant percentage of the users.
If you never fix this, I won't be mad.
This could well be a library issue also. If a easy workaround is possible, I'm all for it, but if it is a Swing, or AWT or whatever issue, then don't bother. |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
Notes |
|
|
(0001145)
|
|
Fred
|
|
2012-01-20 14:27
|
|
|
As usual, a 5 star bug report from Sim! Stellar work, Sim :-) |
|
|
|
(0001189)
|
|
Fred
|
|
2012-02-06 15:43
|
|
|
Sim, quite a few things changed in here, it might pay to retest and let us know what the current status is, ie, no change, better and how, worse and how. Pretty please :-) |
|
|
|
|
|
sim are you available to test this? |
|
|
|
|
|
Sim is tough to get a hold of right now. He's trucking all over and rarely pops in. So this is getting deferred from "0.0.3" to "Future". |
|
|
|
(0002208)
|
|
Fred
|
|
2012-09-21 22:39
|
|
|
Installed stump on my eee and fired olv up after some head scratching and switching back to vt2 and setting DISPLAY... and, it comes up small, then resizes itself in the blink of an eye. So I think this is fixed. Sim can reopen if need be |
|
