Window size+position recall on startup 1px smaller

[Tachyon]

Hi all,

I’m trying to track down a curious, annoying little problem. Each time I start synfigstudio the size of all the windows seems to be 1px less in each direction, and the windows have moved 1px up and to the left, compared to when I last closed the app. Has anyone else noticed this? I’m using KDE 4.3.4, FWIW.

The values are being stored in .synfig/settings, although they don’t seem to correspond to pixel positions. Maybe they’re being stored in terms of DPI or something. If that’s true, given the fact that those numbers are being stored as integers, rounding could be causing what I’m seeing.

So I was trying to track down the code that actually does get/store and read/set the window dimensions. But I’m having a tough time figuring out exactly how that happens. I can see the Settings class, but where it actually gets used to set window dimensions is eluding me. Can anyone point in the right direction?

[Genete]

Hi Tachyon,
It is not only the “one pixel” off set each time you restart synfigstudio. If you use a Gtk 2.18 system you end with a worse problem: viewtopic.php?f=15&t=1062

The reason of the 1 pixel problem and I think that the other I describe in that post is that the panels position (and its dividers) are scaled to a relative screen of 1280 pixels using a hack define SCALE_FACTOR.
See:
synfig-studio/src/gtkmm/dockmanager.cpp
synfig-studio/src/gtkmm/app.cpp

I would like to remove that scale factor and save/load the positions of the docks in absolute values and using the Gtkmm methods peoperly (i.e. discover how many screens does the user have, its resolution, etc.). Unfortunately I haven’t found enough free time to fix it. It is important to do not loose the toolbox in a windows positioning because then the user cannot access to the settings menu. In some circumstances the user could change the screen resolution and the number of virtual screens and synfig studio should act properly to do not place windows outside the visibility.

Maybe you can take a look and I’ll be so grateful with you.

Good luck
-G

[Tachyon]

I see. Yes, that SCALE_FACTOR in the code does look very suspicious. I’ll have a closer look when I get some time. I’m not sure if I could figure out the problems in the other thread, though. FWIW, I have noticed that occasionally the windows will rearrange on startup. I don’t recall if that might be because I had quite the last session with overlapping windows. I wonder if the window manager is doing some “smart” (i.e. dumb) rearranging of the windows to try to make them not overlap.

[Tachyon]

It’s pretty simple to remove the SCALE_FACTOR hack, and just use actual pixel values instead. See patch. I don’t understand why this hack was put in at all in the first place at all, and that makes me uneasy. What would the benefit be? In case someone adjusts their screen size? Perhaps, but if that’s the case (1) why is the scale factor only a common screen width (no height taken into consideration), and (2) why were the parameters not changed to work with (i.e. read/write) real values rather than integers? It’s really curious.

Obviously, existing .synfig/settings will result in shifted windows the first time you run this. There’s no way around that.

I don’t know what, if any, other issues this may solve (or may raise). I know it fixes my problem. I’m really unfamiliar with Gtk programming, so I’m not confident to tackle anything else, here.
scale_factor_rm.patch.zip (1.64 KB)

[Genete]

Tachyon,
thank you very much for the patch. At this moment I’m in the middle of moving the computer (and everything) to a new flat so it would take a bit to me to test the patch and to verify how it works. Anyway the patch looks fine and should work as well.
I hope I can return soon to coding
-G

[Tachyon]

Okay, good luck with that, Genete.

The patch is actually embarrassingly simple - all it does is remove SCALE_FACTOR, and just use pixel values for positions and sizes. It’s not as rich as what you were saying you’d like to see done.