I have one question regarding to the “Fit” in zoom widget entry: Should we make it translatable (for localization propose)?
My ideal here is just to make it translatable, and even in non-english environment, if user keyin “fit” or “Fit” or “FIT”, and then hit enter key, the string will automatically change to the localized word of “fit”. It will help speed up zoom level switching in some cases, and the app will be more user friendly I think.
And of cause, if there is a shortcut without modifier key ( “0” to switch zoom level to “Fit”, for example) available. advanced users will gain more time on their animation creation job and they will enjoy spending more and more time on previewing only (I mean wasting time )
Now “fit” is translatable, in a non-english env, user can also type “fit”, the zoom level will switch to fit, and the word in zoom widget will be converted to translated string.
Accelerated keys without modifier are implemented as well.
I’m not sure about that one. I can see your intention, to get less distraction from surrounding objects but I think the border itself can be a distraction in some cases.
On my tablet pc I have a very small screen, I’ve got rid of window decoration for Synfig to get more space. Having a fixed border then would take away too much of my available area.
You are right. I will revert this change untill the code is smart to detecte the size of the monitor in the feature.
I think no only for the users who have a small size monitor, but also those who have big size monitor would prefer displaying more artwork content, for the monitor usage of UI widgets, the less the better And for the next release I prepared a nice improvement for preview window (I hope my code can be ready to push into master before the code freezing for the coming release).
This feature is for experienced user:
hope it can improve your synfig experiencement on a small size monitor.
I’m wondering whether it would be possible to make the middle mouse button (i.e. pressing down the mouse wheel) move the Preview image around in the same way the middle mouse button moves around the canvas window?
I would find it very helpful, and it would also make the UI consitent between the Canvas and Preview windows.
instead of top-left conner, zoom should be from the center of the current view of preview, or the position of the mouse pointer placed
preview window should also be able to grab the canvas size for the first time user calls it
I am going to cleanup the current code, merge the Preview Options Window into preview window itself before start to implement above things. Not sure if I can start it quickly, sorry .
thanks for report it, and after more than 0.5 hours code reading, it is fixed in my local repo. As additional bonus, now I know more about the code of Preview Option, it seems I am ready to merge Preview Option dialog to the preview window
Another thing that would make preview window yet a little better is to keep it above all other panels.
At least in my systems it has the same stack order as the canvas (or just above it) so it goes on top of the toolbox but behind every other panel. Thus making it impossible to make it larger or fullscreen without it beeing obfuscated by other windows.
To be honest, window and dialog titles that identify particular canvases need to be thought about across the whole program. We need a uniform way to identify them.
If you look at the Properties Window for a canvas the hyphen-minus signs are used. In the canvas window colons and brackets are used. In the Properties Window the Canvas name is used, in the canvas window the Canvas name and the file name is used. The Properties Window never uses the word “Root” but the canvas window does - so it gets a bit complicated!
So as you’re working on the UI for the whole program it would be better to leave that choice up to you.