Difference between revisions of "Dev:UI Reloaded"

Latest revision as of 08:02, 22 February 2010

These are images of some re-designed Synfig dialog. None of these dialogs can be considered final. Some lack some final touch (e.g. incorrect spacing) All changes have been made to make Synfig a better experience for the user! :)

Changes to Existing Dialogs

The Waypoint Editor

The old dialog, as we all know it:

A preview for a revamped version:

The “TCB Parameter” section should probably be disabled when none of the interpolation type fields are set to “TCB”. Also, the separator still has to be removed and the button spacing and order is not yet correct.

Render Preview

Old:

Preview:

Another separator bar that still has to be removed. Also, I’m not sure whether disabling the edit fields for start and end time is the right way. I think that functionality should be replaced by simply entering the clip’s start and end time into the fields as default values.

Maybe not: when you change the start/end value here, later change the duration of the animation, then you might want either the old values, or the new maximum values. Maxy 11:10, 14 Mar 2006 (PST)

New Dialogs

Note: These are only my (Bombe’s)) ideas of how things could be done! For most of these dialogs some partially serious coding has to be done so it’s quite unlikely there will be simple patches for these dialogs (unless I start to like C++ which is doubtful :).

Create New Clip

This dialog should appear when the user selects the File->New command (or uses the corresponding toolbar button). Note that creation of a new document can be cancelled by clicking the “Cancel” button (who’d have guessed that).

I’m still not sure about how to handle image aspect ratios or pixel aspect ratios in this dialog. But I am quite sure that I want separated editor and output settings and that I want both to have different aspect ratios, if needed (e.g. work on a clip in 1024x768, PAR 1:1, and for rendering use 720x576, PAR 1.42:1 to create bitmaps that can be used in DVD production without any further rescaling). Though, asking for output settings in the “Create New Clip” dialog might be misplaced, I admit that. :)

The edit fields for the work area and focus point are completely gone — on purpose. The FPS field is also gone (the Synfig of the future uses a notion of FPS only for preview, output, and the snap-keyframe-to-time feature) but the start and end fields should probably be in this dialog as well.

Scale

This dialog lets you scale the work area in the editor.

Width and height values are adjusted automatically, according to the current aspect ratio. “Current aspect ratio” means the aspect ratio for the editor if “Keep aspect ratio” is unchecked, or the aspect ratio given in the dialog if it is chcked.

Resize

The resize dialog changes the size of the working area without changing the size of the objects. Cropping is also possible with this dialog.

The horizontal and vertical offsets work just like the corresponding files in The GIMP’s resize function.

Comments & Remarks

All this thinking about pixels and resizing and aspect ratios made me wonder whether that is all necessary. As Synfig is resolution-independent the only thing needed for the working area is the aspect ratio. The working area will always be scaled from (0.0, 0.0) to (1.0, 1.0). Scaling/Resizing would then only affect the pixel location values in all layers. (Would that actually work? I have to think about that some more.)

AlanHorkan 15:54, 20 Jun 2007 (PDT) writes: Several of the screenshots/mockups make use of an Apply button, the Gnome guidelines recommend developers avoid the Apply button and work to make things instant apply if at all possible (although it might be awkward to make that happen in the shorter term). Also some of the mockups show the OK button on the left most position whereas others show it last on the right more like how Gnome does it. More recent versions of GTK allow (maybe not as easy at it should be) for alternative button orderings to better integrate with other systems so even though a few people might not approve of the Gnome the best thing to do would be to follow the recommended button order and first and see about alternative button orders later. It might be worth considering the docking system used by the Anjuta Integrated Development Enviroment (IDE) which as far as I know they make available through a library called "libgdl". This would help at least make docking behaviour consistent with other applications that use libgdl. Great to see all this being considered.