Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000565TunixGeneral Featurespublic2012-04-06 06:392012-04-16 23:44
ReporterToxicGumbo 
Assigned ToToxicGumbo 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusclosedResolutionfixed 
PlatformAllOSAllOS VersionAll
Product Version0.9.24-SNAPSHOT 
Target Version0.9.24Fixed in Version0.9.24-SNAPSHOT 
Summary0000565: Store relative window placement on exit for next launch
DescriptionSince MegaTunix is designed around floating windows rather than a single, fixed, interface, it would be helpful if the primary windows remember--or have the ability to remember--their placement between runs (and perhaps relative to the main window to avoid window scatter when screen size or resolution changes).

These windows are typically stacked at launch. This is generally only frustrating during lengthy debugging sessions where MTX might need to be reopened frequently, but it would also cater to those of us who prefer the windows grouped to simulate a single window (for quicker analysis on large or cluttered desktops). For that matter, having a "locked" mode where all windows are equally above or below other applications would be useful to avoid losing a window or two while clicking between open applications or other windows. This might not be practical or even possible under OS UI norms.
TagsNo tags attached.
FirmwareVersion3f59fde
Attached Files

- Relationships

-  Notes
User avatar (0001397)
Fred (administrator)
2012-04-06 10:49

Great ideas there! I think you meant this implicitly, but I'd like to make it explicit: Remember sizes too, and perhaps also which were closed. I also feel like it used to do this and recently stopped, but the memory is foggy on that.
(0001398)
dandruczyk (viewer)
2012-04-06 12:28

stacking as a group is not cross-platform or even cross-display manager able without inconsistency. All windows should already remember their previous size and placement and return there as long as megatunix is closed CLEANLY, if it crashes before it's able to save the settings, then of course those don't save.

For me I can start mtx, place/resize the windows where I want, then close, and from that point on when I reopen they return to the same places. If they are not doing that it is likely due to YOUR window manager OVERRIDING megatunix's size and placement requests and there's little I can do about that.
(0001399)
dandruczyk (viewer)
2012-04-06 12:29

This already works by design, if it doesn't you need to provide more details, Odds are it's your OS or window manager overriding megatunix which is nothing I can control, but you might be able to adjust your WM settings to not override mtx.
User avatar (0001402)
Fred (administrator)
2012-04-06 12:45

That's it then. I expected that the settings would get saved when I moved/resized, immediately, not deferred till some later time. I ALWAYS ctrl C it from the terminal to avoid dealing with the obnoxious "are you fucking sure you fucking want to quit this awesome app?" dialogues. Which, if you think about it, shouldn't be necessary, as all data is going to still be in the ECU (because you're 100% certain that you're synced with the ECU) and all the settings already saved, or even, about to be saved, why even ask? What is there to lose? Datalogs in memory? Those should be on disk anyway, as described in 0000561, really. Interestingly, Sean was doing the same deferred write thing in the loader and losing his load stats. He fixed that, though.
(0001403)
dandruczyk (viewer)
2012-04-06 21:24

I can't help it if you use the application incorrectly, by interrupting it's flow with a hard close. If you don't like the prompt use "-q", or setup an alias on your local system 'alias mtx="/usr/local/bin/megatunix -q"'
User avatar (0001404)
Fred (administrator)
2012-04-06 22:04

This hasn't been confirmed to not be a problem by the reporter, so I'm reopening it until he can confirm the situation. I will also try to verify here. In the mean time, I created 0000566 re the nag screens to get that resolved in a professional manner, eventually. Assigned to me, due to the title of it.
User avatar (0001405)
Fred (administrator)
2012-04-06 22:05

Please, at your leisure, confirm/deny that this functionality works as desired/expected/described.
User avatar (0001407)
Fred (administrator)
2012-04-06 22:37

Confirmed fucked in window maker (a very minimalist wm) with all possible window placement algorithms (smart, auto, manual, etc.). Previously I was using lxde and it appeared to do the same thing there. I may verify if I exit this wm briefly.
(0001413)
dandruczyk (viewer)
2012-04-07 12:26

On gnome 2 on Ubuntu 10.04 it works perfectly as designed, likewise on 11.04 as well.
User avatar (0001418)
ToxicGumbo (reporter)
2012-04-07 16:41

Thanks for the info. I'm now only having "window location" trouble in Windows 7. Is that expected?
(0001422)
dandruczyk (viewer)
2012-04-15 17:58

This issue is fixed in hash b36e2e
(0001423)
dandruczyk (viewer)
2012-04-15 17:58

fixed in b36e2e
User avatar (0001424)
Fred (administrator)
2012-04-15 18:18

Is there any further info on what was wrong, the reach of the issue, and the extent and coverage of the fix?
(0001427)
dandruczyk (viewer)
2012-04-15 19:28

no, if it doesn't work on your system, you either have permissions set so megatunix cannot save it's state properly, or a window manager which overrides application wishes.
User avatar (0001445)
Fred (administrator)
2012-04-15 19:43

How can the answer be no? You provided a specific hash with the words "Fixed in" next to it. What was the issue, what changed, what does this commit and any preceding ones that are related resolve exactly? What WAS broken vs what wasn't? Please provide more info.
(0001447)
dandruczyk (viewer)
2012-04-15 19:45

Feel free to read the code.
User avatar (0001448)
Fred (administrator)
2012-04-15 19:49

The code can't answer my question, only a developer with an intimate knowledge of the code, and one who made the changes that are purported to have fixed it, can. That's you. I was asking on behalf of Jeff as well as info about the reason why it wasn't working is useful in retesting it. Please advise for his sake, not mine, I couldn't give a flying fuck <3
(0001449)
dandruczyk (viewer)
2012-04-15 19:51

I already explained it to him, I don't need to re-explain it all over again to you. Test it, if it doesn't work on windows as expected, re-open, otherwise close the issue, or reassign to toxic for double verification.
User avatar (0001454)
Fred (administrator)
2012-04-15 19:54

Please link to the explanation that you gave Jeff. I'm interested to read it.
(0001456)
dandruczyk (viewer)
2012-04-15 19:58

I don't keep IRC logs to throw in other people's faces. Feel free to ask him. The gist being that windows 7 messes with permissions to allow an install, but not allow modfying of files later in that same dir. Mtx was adjusted to install "user" files in the users homedir which varies per windows release (use google). This wasn't done originally because the g_get_home_dir() call in GTK+ was notoriously broken on windows. If you scanned the code you'd have noticed the changes in the code with regards to file paths.
User avatar (0001458)
Fred (administrator)
2012-04-15 20:01

Ahh, good stuff, thanks! :-)
User avatar (0001467)
Fred (administrator)
2012-04-16 22:01

Works for me in wmaker now! :-)
User avatar (0001468)
ToxicGumbo (reporter)
2012-04-16 23:44

Fixed in b36e2e.


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker