Rather than everything having to separately commit changes to the ass
and then tell the subs grid to notify various parts of Aegisub about the
changes, committing the AssFile now triggers an event which objects
listen for.
AssFile::Commit now also has an argument to indicate what sorts of
changes were made to the file. For now these types are very broad.
Originally committed to SVN as r4901.
Don't display error messages and try other providers when the user
cancels loading a file.
Remove files from the MRU lists if they can't be found.
Closes#717.
Originally committed to SVN as r4717.
This happens to fix most of the undo issues, as it's now much harder to
have uncommitted changes to the file.
Closes#355 and #586.
Originally committed to SVN as r4699.
Make the undo and redo stacks non-static members of AssFile, making it
theoretically possible to have multiple open AssFiles with working undo.
Slightly improve tracking of whether the file is modified: saving,
making a change, then undoing the change now results in the file being
shown as unmodified as with most programs with undo.
Add basic undo coalescing support.
Originally committed to SVN as r4667.
Kill vfr.h and vfr.cpp and use the libaegisub versions of them instead.
Rather than the globals VFR_Input and VFR_Output, everything related to
frame rate is now part of the video context. Most things which used to
use VFR_Output now call VideoContext::TimeAtFrame etc.; video providers,
rather than modifying VFR_Input directly, now have getters for their
frame rates which VideoContext calls. Read-only public access to
VFR_Input and VFR_Output are still provided (hopefully temporarily) for
a few things which were awkward to do through VideoContext.
The Avisynth provider now might correctly handle VFR MKVs which can be
opened with DirectShowSource but not DSS2.
Rework keyframe handling as well, so that it continues to match the vfr
handling in design and implementation.
Originally committed to SVN as r4662.
Rather than just have a single Refresh method that gets called whenever
something happens that could possibly be of interest to the visual
tools, add seperate methods for signaling frame number changes and
changes to the file, and use the new SelectionController stuff for other
things that used to merit a Refresh. This eliminates a large amount of
redundant reparsing of lines which happened on paint, as well as a large
number of redundant repaints.
Frame data is now only uploaded to the video card when the frame number changes
rather than when anything at all changes, slightly improving performance when
using mesa's software opengl implementation.
Vector clip and drag tools now do a slightly better job of not
discarding the user's selection for no apparent reason, and strange
selection behavior from clicking on visual features should now be
entirely fixed.
Everything but the constructor and toolbar event handler in the visual
tool implementations are now private.
Originally committed to SVN as r4631.
Change SelectionListener interface so it receives the set of lines added and removed from selection, instead of just the complete new selection.
Update VisualTool<> to use SelectionListener to receive selection change notifications.
This change (temporarily, I hope) breaks feature selection in visual drag mode, when changing selection via the grid. This is caused by the grid selection change first clearing the entire selection, which sends a separate notification about selection clear. This causes the last visual feature to be deselected, and then the visual tool base reselects the active line, causing a new notification for selection to be sent. The active line happens to be the newly clicked line, and the selection notification enters during the externalChange guard being set, and is then ignored for feature update purposes. When control returns to the original SelectRow call in the grid, the line to be selected has already been selected and then nothing happens.
The best fix is to avoid two notifications being required to deselect all then reselect one line in the first place, so making the grid selection handling saner is the best fix.
Originally committed to SVN as r4602.
Selections in drag mode now follow the following rules:
* If a line is selected in the grid, at least one visual feature
corresponding to the line is selected.
* If a line has any features selected, that line is selected in the
grid.
In addition, all control points now start out selected in the vector
clip tool, and all tools should no longer discard the current selection
at unpredictable or unintended times.
Updates #513.
Originally committed to SVN as r4363.
Sets the last clicked-on feature to the double-clicked spot and applies
the same relative movement to all other selected lines (including ones
not visible on the current frame).
Updates #513.
Originally committed to SVN as r4350.
Make all visual tools support selecting and manipulating multiple visual
features at once, allowing multiple lines to be moved at once, entire
vector clips to be translated, etc. Controls:
- Left click: Select control clicked control only
- Ctrl-left click: Add/remove control to selection
- Drag control (with or without ctrl): Move all selected controls,
after setting/adding to selection if target is not in the selection
- Click on no control: Clear selection
Lots of little stuff to fix still.
Updates #513.
Originally committed to SVN as r4322.
Make all visual tools only update the most-changed axis whenever shift
is held down. Previously the rotate and scale tools used ctrl for this
and shift for snapping to round values; these have been swapped for
consistency.
Closes#993.
Originally committed to SVN as r4310.
Previously the visual typesetting tools and the overlay mask used
several coordinate frames, converting between them in many places in
inconsistent ways. This elimiates all uses of coordinate frames other
than screen and script, and makes the conversion done in one place, and
only when parsing or serializing ASS.
This fixes:
- A few minor rounding errors
- Horrible brokeness when only part of the video frame is being
displayed, due to higher levels of zoom than fit onscreen or panning
the video
- Distortion of the visual typesetting tools when the combination of
overridden aspect ratio, script resolution, and video resolution did
not result in square pixels.
- Resolution-dependence of the visual typesetting tools, which resulted
in some tools becoming hard to use at zooms outside the range of
100-200%.
- Some draggable controls used the mouse's script coordinates,
resulting in noticable jerky movement at high zoom levels or when
using strange script resolutions.
Closes#966.
Originally committed to SVN as r4289.
