preview window improvement - wip

Yet another small progress: a magnifier icon added to zoom widget, and two non-UI related bugs fixed.

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 :mrgreen: )

Nice work jcome!
I think fit should be translatable too.

thanks.

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.

Do you like the content has a dark border (26px) always?
preview_window_with_darkborder.png

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 :slight_smile: 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:
preview-window-mini-ui.png

hope it can improve your synfig experiencement on a small size monitor.

:smiley: Looks good!

a screencast,
dl.dropbox.com/u/5055643/preview … r_keys.ogv
in fact, I had intended to keep these keyboard shortcuts as secret :slight_smile:

Double fine!
You’re not very good at keeping secrets… :wink:
Will these shortcuts be exposed to accelrc so we can change them to fit our own workflow?

Yes, but I am afraid I cannot make it happen in the coming release, and this is the reason why I intended to keep these shortcuts as secrete :blush:

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.

Yes. There are some other points:

  • 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 :blush: .

I found a bug in the preview options, filed a report here: https://sourceforge.net/tracker/?func=detail&aid=3524682&group_id=144022&atid=757416.

In short, negative start frames mess up the range.

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 :slight_smile:

Fantastic! Thanks! :slight_smile:

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.

already in my git repo :slight_smile: and the size of preview window now inherits its canvas size too.

What format do you prefer?

  • Previewing : Canvas Name
  • Canvas Name (Preview)

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.

Good point, I added this to the "the problems we want to solve "Before final decision be made, the temp solution I prefer is “Preview - Canvas Name”.