Coder Social home page Coder Social logo

typesettingtools / aegisub Goto Github PK

View Code? Open in Web Editor NEW
268.0 268.0 470.0 39.14 MB

Cross-platform advanced subtitle editor

Home Page: http://www.aegisub.org

License: Other

Makefile 0.02% M4 0.05% Shell 0.16% Lua 3.49% MoonScript 0.50% C++ 29.10% C 64.49% Objective-C++ 0.23% AppleScript 0.01% Inno Setup 0.79% Batchfile 0.02% Objective-C 0.03% Python 0.19% Meson 0.77% PowerShell 0.11% SourcePawn 0.03%

aegisub's People

Contributors

alucryd avatar alysson-souza avatar arch1t3cht avatar astiob avatar azpidatziak avatar bkbkb avatar coffeeflux avatar computerfan avatar darealshinji avatar dwbuiten avatar eqvinox avatar ereza avatar fichtefoll avatar grigorig avatar inkydragon avatar kblomster avatar line0 avatar lliehu avatar myaamori avatar myrsloik avatar nielsmh avatar p-static avatar rr- avatar safaalfulaij avatar scx avatar sidneys avatar tgoyne avatar theoneric avatar torque avatar wangqr avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

aegisub's Issues

Rebrand and make a stable

Things blocking that:

  • Squash and push commits from my personal branch
  • Fix a/v desync errors, see #14
  • Update VSFilter binary included in my builds
  • Host builds on Github and modify updater and installer accordingly
  • Rebrand and host infrastructure under new branding

Feature Request: Add support for more customisation to syntax highlighting (e.g bold/italics)

Currently, via editing config.json you can change whether certain elements appear bold or not in the edit box. I don't believe this can be altered in the UI.

"Bold" : {
					"Brackets" : false,
					"Comment" : true,
					"Drawing" : false,
					"Error" : true,
					"Karaoke Template" : false,
					"Karaoke Variable" : false,
					"Line Break" : false,
					"Normal" : false,
					"Parameters" : false,
					"Slashes" : false,
					"Tags" : false
				},

Having the option to toggle bold/italic (through the UI or config) as well as picking colors for a given element would help to keep things a bit clearer. Particularly with things like comments and karaoke template variable etc, I think the option to further customize highlighting would be useful.

After looking further it seems when selecting different font styles for the edit box font (e.g bold/italic) it will revert to the regular variant in most cases. I think this may relate to font naming as the fonts that work have "bold" or "italic" at the end of the name. Whereas other fonts that do have proper italic and bold variants that don't have different naming seem to revert to regular. e.g after changing the font in the UI to have the itallic style the changes have no effect.

aegisub64_2018-11-11_17-09-46

Should note nothing was changed in the config either.

"Edit Box" : {
			"Font Face" : "Roboto Mono",
			"Font Size" : 12
		},

Adding "Font Style" in here and trying to set it that way proved unsucessful as well.

Customizable variants/styling for each separate element in the edit box would be great or even the ability to set the weight of the "Bold" variant to avoid differences like this would be useful espeically when intermediate weights exist.

aegisub64_2018-11-11_17-22-29

Original issue: Adding support for italics in the config

Frequent crashes due to wxEVT_MOUSE_CAPTURE_LOST

For a couple months I've been getting random crashes when clicking on entries in the subtitle grid. According to discord logs, I first complained about this on 2019-05-01. I haven't used an automation script and I usually don't have video (or audio) playing in these situations.

Traceback below:

ASSERT INFO:
./src/common/wincmn.cpp(3346): assert "Assert failure" failed in DoNotifyWindowAboutCaptureLost(): window that captured the mouse didn't process wxEVT_MOUSE_CAPTURE_LOST

BACKTRACE:
[1] wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)
[2] wxWindowBase::NotifyCaptureLost()
[3] wxMessageDialog::ShowModal()
[4] wxMessageBox(wxString const&, wxString const&, long, wxWindow*, int, int)
[5] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&)
[6] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[7] wxEvtHandler::TryHereOnly(wxEvent&)
[8] wxEvtHandler::ProcessEventLocally(wxEvent&)
[9] wxEvtHandler::ProcessEvent(wxEvent&)
[10] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[11] wxWindow::GTKSendPaintEvents(_cairo*)
[12] g_closure_invoke
[13] g_signal_emit_valist
[14] g_signal_emit
[15] gtk_container_propagate_draw
[16] g_closure_invoke
[17] g_signal_emit_valist
[18] g_signal_emit
[19] gtk_container_propagate_draw
[20] g_closure_invoke
[21] g_signal_emit_valist
[22] g_signal_emit
[23] gtk_container_propagate_draw
[24] g_closure_invoke
[25] g_signal_emit_valist
[26] g_signal_emit
[27] gtk_container_propagate_draw
[28] g_closure_invoke
[29] g_signal_emit_valist
[30] g_signal_emit
[31] gtk_container_propagate_draw
[32] gtk_container_propagate_draw
[33] gtk_main_do_event
[34] g_signal_emit_valist
[35] g_signal_emit
[36] g_main_context_dispatch
[37] g_main_loop_run
[38] gtk_main
[39] wxGUIEventLoop::DoRun()
[40] wxEventLoopBase::Run()
[41] wxAppConsoleBase::MainLoop()
[42] wxEntry(int&, wchar_t**)
[43] main
[44] __libc_start_main

Script Resolution Mismatch dialogue box not working as intended

case MISMATCH_SET:
file->SetScriptInfo("PlayResX", std::to_string(vx));
file->SetScriptInfo("PlayResY", std::to_string(vy));
return true;

image
As @Myaamori pointed out, the above dialogue box has the same behavior for both options. It will rescale all override tags to the video resolution for either option, even though the Set to video resolution option should only be editing the script properties (like in the window below) according to src/dialog_video_properties.ccp.

image

The only way to set to video resolution correctly as of now, is hitting Cancel on the mismatch dialogue, and then hitting From video in the Script Properties window.


Steps to reproduce:

  • (Assuming the user has Match video resolution on open set to Ask under Preferences > General > Video)
  1. Create a script at 1280x720 using at least one non-interger override tag (\pos for example)
  2. Open a video at a different resolution
  3. Test Set to video resolution
  4. Repeat steps 1-2 for Resample script
  5. Repeat steps 1-2 and click Cancel
  6. Now, go to File > Properties... and set script resolution from video, and observe that no tags are scaled

Feature request: proper automation script GUI window support beyond current limited config dialogs

There's already a clear need for this, if you look at any of unanimated's multifunction scripts or the like. The usability is terrible because the window has to operate as a dialog window, with no interactivity - the script can't do anything until the user clicks one of the buttons at the bottom, at which point the window closes. You can have several dialogs in a row or reopen the same one with changes, sure, but it's still not good.

A related but smaller issue is that all the buttons need to be at the bottom of the window, leading to confusing UI designs in multifunction scripts, with no way to do them better.

I would be willing to help with the implementation here, wherever my skillset might be applicable. I'm familiar with the relevant languages and UI programming in Qt and WinForms, and I can't imagine wxWidgets being that different.

Option to store Aegisub's project garbage separately from the script file

Currently Aegisub injects a header into the .ass files containing information such as associated audio and video files, the last edited line, and the video position. This leads to difficulties when collaborating using version control systems such as git: As this information will be inevitably be changed every time anyone touches the script, this results in more or less guaranteed conflicts any time you need to merge your changes with someone else's.

While there are ways to alleviate the issues to some extent, such as using git filters to automatically remove the header, these come with their own caveats, such as difficulty to define them easily in a cross-platform manner, sub-par client support, and other subtleties.

To some extent, there is also the question of privacy, as if the user is not careful, their computer username might end up in the script file without their knowing, if absolute paths are used for the audio file and video file locations.

It would be good if it was instead possible to store this information externally, somewhere separately from the main .ass file. This does beg a number of questions:

  • How should the settings be stored?
  • Should all files be remembered?
  • How should file renames be handled?

For the first one, one might consider a simple human readable ini-like; more or less simply a centralized collection of project garbage headers. Note that synchronization may be an issue if multiple Aegisub instances are running simultaneously.

For the second issue, perhaps a LIFO system could be considered, where a user-defined amount of files are remembered at most by Aegisub. When the limit is exceeded, the file that hasn't been opened for the longest amount of time is purged. Though on the other hand, this may not be an issue in practice, as even thousands of headers will not require a considerable amount of space on disk.

The third issue comes up when collaborating e.g. via FTP, and the file is renamed after each new iteration. In this case it is still desirable to remember settings from the previous iteration of the file, especially the associated audio and video files. One idea is to have Aegisub generate a script ID once which is added to the file header, and then used to track the script across renames.

meson build system

A while ago, @lachs0r ported the current autotools build system to use meson and I adapted that to work on my machine as well. The current progress is available at https://github.com/lachs0r/Aegisub/tree/meson/ (+2 unmerged PRs). I do not know if this works at the moment since I stopped using my meson fork when I noticed frequent crashes with automation that didn't occur on origin/master.

Ideally, this should ease the build process for Windows a lot and might even enable cross-compilation, though last I remember that was stuck on a bug in boost. I am most certainly not an expert in this area.

Just putting this up here so it isn't forgotten. And to gather interest.

Support other Keyframe formats

Currently aegisub only seems to support ffms2 generated keyframes or those created by scxvid+AVS which is an aging software/library/technology.

Example of scxvid:

# XviD 2pass stat file (core version 1.4.-127)
# Please do not modify this file

i 2 8160 0 0 22890 22594
p 2 0 0 8160 1102 1102
p 2 0 34 8126 1136 1136
p 2 0 0 8160 1102 1102
p 2 0 0 8160 1102 1102
p 2 0 0 8160 1102 1102
p 2 0 0 8160 1102 1102
p 2 0 0 8160 1102 1102
p 2 0 0 8160 1102 1102
p 2 9 110 8041 3794 1242
p 2 7171 986 3 37443 26575
p 2 5303 2852 5 52769 27249
p 2 2988 5170 2 72779 26249
p 2 2503 5657 0 84756 27368
p 2 1909 6251 0 90766 25363
p 2 1730 6430 0 101239 25896

Could other keyframe formats be supported as well? For example ones created with VapourSynth and WWXD (https://github.com/Irrational-Encoding-Wizardry/kagefunc/blob/master/kagefunc.py#L112):

Example of WWXD keyframes:

0 I -1
75 I -1
127 I -1
224 I -1
412 I -1
572 I -1
653 I -1
728 I -1
796 I -1
930 I -1
979 I -1

The major difference is that scxvid keyframes seem to rely on the line number to indicate the i-frames (line# - 4 actually) whereas the wwxd ones actually output the frame number to the file.

Attaching full file examples
SCXvid
WWXD+VS

While not exactly core to Aegisub's functionality, it would certainly help users who also want to stop using Avisynth and scxvid.

It's worth nothing that the format used in the VS get_keyframes function linked above are in the format of x264 and x265's qpfile, so they aren't just in an arbitrary format: http://www.chaneru.com/Roku/HLS/X264_Settings.htm#qpfile http://x265.readthedocs.io/en/default/cli.html#cmdoption-qpfile

Additionally, basing it on x264/x265's qpfile format allows for other scene detection filters to be used in the future and use x264/x265's much more readable format.

Weird spacing for numeric inputs

Since some update of wx, iirc, numeric inputs that have the up and down buttons attached have really odd spacing. I suspect their layout was changed in some wx update.

This is a recent master build on Arch (both this fork and original), but has been present for a longer time. Something between 0.5 and 1 year, probably?

Screenshots below:

2019-01-07_05-00-38

2019-01-07_05-04-36

Also results in a lot of

(aegisub:12152): Gtk-CRITICAL **: 05:02:20.204: gtk_box_gadget_distribute: assertion 'size >= 0' failed in GtkSpinButton

messages on the console.

Feature Request: Subtitle renderer refresh

When launching a script + accompanying video with a font not currently "active" through my font manager, the video will not display any subtitles, as expected. However, after activating the font(s), the only way to refresh to make it start displaying the subtitles is to close the video and re-open it. Would be neat if there was an option under Subtitle > to refresh the display without having to re-load the video.

Linux: DPI scaling on GNOME is handled incorrectly by the video element

screenshot from 2019-02-02 09-07-19
screenshot from 2019-02-02 09-02-57

With display scaling set to 200% on GNOME 3.30.2 (resolution 3840x2160, up-to-date Arch Linux), the video is not scaled by 200% along with the rest of the UI.

There might be a workaround to this, but the fix could be simple to implement so I decided to report this before looking for one. I can try other desktop environments if needed.

Adding lead-in/lead-out is broken on first use

Steps to reproduce:

  1. Start Aegisub
  2. Load audio track
  3. Push lead-out button
  4. Observe random amount of lead-out getting added instead of the configured duration

The feature will work as expected after undoing the action and manually adjusting the line start/end time.

Feature Request: Sign Nudging with arrow keys

Given:

  • I have a script open
  • I have selected some lines of dialogue
  • I have a video loaded, displaying the lines
  • I am in Drag Subtitles mode
  • I am hovering over the video area (it is my active area, not the lines, not the dialogue)

When:

I tap the arrow keys (or other assigned hotkeys)

Then:

I want the sign to adjust it's position by 1 pixel

  • This could be adjustable with an option, or with modifiers, like Shift + means "move by 10 pixels"

Why?

There's a number of times when I'd like to be able to select a line and adjust it by perhaps a few pixels in a direction, particularly if I'm doing multi-layer signs and want to add a custom shadow.
It's also useful for some manual fbf transforms

Change opacity & color of clip selection tools

It would be really nice to be able to change the opacity and color of the clip selection lines and masked-area. Especially for anyone with any form of colorblindness, this can make the difference between usable and not.

For example, being partially colorblind myself, these clip colors are nearly impossible for me to see which made it take infinitely longer.

aegisub64_2018-02-09_18-36-09

Ideally this would just be another setting in the "Colors" options page.

AssDraw

Is it possible to reinsert AssDraw3 link directly in aegisub toolbar?

Font collector hangs with lots of faux bold lines

Pasting {\fnAcme\b1}The quick brown fox jumps over the lazy dog a few thousand times and running the font collector will cause Aegisub to hang for a long time. The root cause appears to be in FontCollector::PrintUsage().

Document aegisub.project_properties()

Popular scripts are making use of this, and so it's worth having it stabilized and documented. Some other API functionality may also be missing from the docs and should be investigated.

Bug: Issues with re.moon module

When trying to use the Gradient by Character script from DepCtrl with version 8962-master-5c15667.

Karaskel: Video X correction factor = 1.000000

No furigana style defined for style 'Signs-b'


Lua reported a runtime error:
    File "C:/Users\begna112\AppData\Roaming\Aegisub\automation\autoload\lyger.GradientByChar.lua", line 141
<anonymous function at lines 36-212>
    File "C:/Program Files\Aegisub\automation\include\aegisub\re.moon", line 196
find
    File "C:/Program Files\Aegisub\automation\include\aegisub\re.moon", line 189
(for generator)
    File "C:/Program Files\Aegisub\automation\include\aegisub\re.moon", line 42
search
    File "<C function>", line -1
?
cannot resolve symbol 'free': The specified procedure could not be `found.

looks to be the same or similar to the issue reported here: unanimated/luaegisub#6

Optimization of audio view

Current concerns include large numbers of lines as well as constant video seeks at high poll rates.

Fix up local patch and then bounce it by both lachs0r and Myaamori to see if their concerns are abated.

Importing Text files into Aegisub with special characters has inconsistent results depending on file encoding

I talked about this on GJM's Discord a bit and finally remembered to post an issue.

I extended my testing out to the 4 formats that, in this case, notepad uses to save .txt files.

The results were as follows:
ANSI, UTF16 little-endian, UTF16 big-endian and UTF8

The files used for import testing can be found HERE.

It's a largely unimportant thing in the grand scheme of things I guess, but you said it was worth positing about, so here it is.

Feature request: toggle-able file associations on installer

[Registry]
; File type registration
; Application registration for Open With dialogue

[1:43 AM] Ryan: there is significant benefit to being able to compile without lgpl so no, i would not say ffms2 should be assumed to be the only a/v provider
[1:43 AM] Ryan: even if it's the default for most people
[2:45 AM] Ryan: there are various providers you can build with
[2:45 AM] Ryan: and it's not hard to add another if there was some reason you'd want to
[2:46 AM] Ryan: it's probably worth going and making the extensions registered based on the providers available to people
[2:46 AM] Ryan: the configuration flags should be imported into the installer
[2:46 AM] Ryan: the avisynth one is iirc just calling directshowsource?

Multiple audio track crash

Not tested myself, reporting for herkz.

"Having a secondary audio track from the video or external audio loaded, playing a line, and then trying to load the (first) audio from the video crashes. This only happens when you play the audio with the space bar, not play the video+audio at the same time."

Feature Request: Separate Default Lead-Out from TPP Lead-Out

Current behavior: changing the value for lead-out in TPP also changes the default lead-out used for the lead-out hotkey.

Requested behavior: Changing the lead-out value in tpp does not change the default lead-out.

Use case: I like using a 380ms for my default lead-out. Let's say I get a pre-timed script that I want to make minor adjustments to. If I add 100ms lead-out with tpp, I now need to go to options to revert my default lead-out to 380ms. Separating the variables will fix this issue. Keeping them tied together has no upside I can think of.

Also, as I type this out, I realize this should also be applied to lead-in, but I'm too lazy to change what I've typed, so pretend I did ;)

Available file types for A/V should be dynamic based on what provider Aegisub is built with or is currently using

(An extension of #46)

I created #43 because ffmpeg supports opening the files, but Aegisub does not have them in the list of accepted extensions on the open video or open audio pop-up.

[2:46 AM] Ryan: it's probably worth going and making the extensions registered based on the providers available to people
[2:46 AM] Ryan: the configuration flags should be imported into the installer

Basically,

  • Aegisub/src/command/audio.cpp
  • Aegisub/src/command/video.cpp
  • Aegisub/src/project.cpp

Should be dynamic based on the provider Aegisub is built with, or even possibly the active provider chosen by the user in the Preferences > Advanced window.

A/V Desync

Two separate files were provided to me privately in which this occurs. Putting the issue here so I can keep track of it.

"Split after current frame" does not work as expected.

When right clicking on a subtitle-grid line, you have the option to split line before or after the current frame.

Splitting before it works as expected: the line is split at the beginning of the current frame and the order of the lines matches the audio order.

Splitting after does not work as expected: it does split the timing at the next frame after the current one, but it reverses the order of the lines in the grid.

For example, the original line:
Dialogue: 99,0:00:07.96,0:00:12.11,Default,,0,0,0,,{This is a global phenomenon.\NIt isn't just our own satellites.}This is a global phenomenon. \NThis isn't just limited to our satellites.

Current "split after":
Dialogue: 99,0:00:09.61,0:00:12.11,Default,,0,0,0,,{This is a global phenomenon.\NIt isn't just our own satellites.}This is a global phenomenon. \NThis isn't just limited to our satellites.
Dialogue: 99,0:00:07.96,0:00:09.61,Default,,0,0,0,,{This is a global phenomenon.\NIt isn't just our own satellites.}This is a global phenomenon. \NThis isn't just limited to our satellites.

Expected result:
Dialogue: 99,0:00:07.96,0:00:09.61,Default,,0,0,0,,{This is a global phenomenon.\NIt isn't just our own satellites.}This is a global phenomenon. \NThis isn't just limited to our satellites.
Dialogue: 99,0:00:09.61,0:00:12.11,Default,,0,0,0,,{This is a global phenomenon.\NIt isn't just our own satellites.}This is a global phenomenon. \NThis isn't just limited to our satellites.

Note the timings. The lines are in reverse order, essentially.

Crash when pressing page up

Here's another type of crash that occures frequently (also roughly since 2019-05-01). This one happened as I pressed page up on the subtitle grid. Note that it only crashed on the third time (consecutively).

           PID: 5433 (aegisub)
           UID: 1000 (fichte)
           GID: 100 (users)
        Signal: 6 (ABRT)
     Timestamp: Thu 2019-07-04 13:58:26 CEST (36s ago)
  Command Line: aegisub
    Executable: /usr/bin/aegisub
 Control Group: /user.slice/user-1000.slice/session-1.scope
          Unit: session-1.scope
         Slice: user-1000.slice
       Session: 1
     Owner UID: 1000 (fichte)
       Boot ID: fd239d6893094baeb6b1e8b4d99e32d8
    Machine ID: ea59db7cbffc44b4858a3f3ba6277e6f
      Hostname: pinaceae
       Storage: /var/lib/systemd/coredump/core.aegisub.1000.fd239d6893094baeb6b1e8b4d99e32d8.5433.1562241506000000.lz4
       Message: Process 5433 (aegisub) of user 1000 dumped core.
                
                Stack trace of thread 5433:
                #0  0x00007fa294078755 raise (libc.so.6)
                #1  0x00007fa294063851 abort (libc.so.6)
                #2  0x00007fa295680408 n/a (libwx_baseu-3.0.so.0)
                #3  0x00007fa294b3ad00 __restore_rt (libpthread.so.0)
                #4  0x000056055b8f1fe2 n/a (aegisub)
                #5  0x000056055b8f02f2 n/a (aegisub)
                #6  0x000056055b8daf5d n/a (aegisub)
                #7  0x000056055b8dfc14 n/a (aegisub)
                #8  0x00007fa2957f889e _ZN12wxEvtHandler23ProcessEventIfMatchesIdERK21wxEventTableEntryBasePS_R7wxEvent (libwx_baseu-3.0.so.0)
                #9  0x00007fa2957f8c1b _ZN12wxEvtHandler23SearchDynamicEventTableER7wxEvent (libwx_baseu-3.0.so.0)
                #10 0x00007fa2957f8cb1 _ZN12wxEvtHandler11TryHereOnlyER7wxEvent (libwx_baseu-3.0.so.0)
                #11 0x00007fa2957f8d64 _ZN12wxEvtHandler19ProcessEventLocallyER7wxEvent (libwx_baseu-3.0.so.0)
                #12 0x00007fa2957f8e02 _ZN12wxEvtHandler12ProcessEventER7wxEvent (libwx_baseu-3.0.so.0)
                #13 0x00007fa2957f8ba7 _ZN12wxEvtHandler18SafelyProcessEventER7wxEvent (libwx_baseu-3.0.so.0)
                #14 0x00007fa295b6aa6b _ZN8wxWindow18GTKSendPaintEventsEP6_cairo (libwx_gtk3u_core-3.0.so.0)
                #15 0x00007fa295b6af6c n/a (libwx_gtk3u_core-3.0.so.0)
                #16 0x00007fa293aeda9f n/a (libgtk-3.so.0)
                #17 0x00007fa293856e81 n/a (libgtk-3.so.0)
                #18 0x00007fa2934cde55 g_closure_invoke (libgobject-2.0.so.0)
                #19 0x00007fa2934baec7 n/a (libgobject-2.0.so.0)
                #20 0x00007fa2934be67d g_signal_emit_valist (libgobject-2.0.so.0)
                #21 0x00007fa2934bffb0 g_signal_emit (libgobject-2.0.so.0)
                #22 0x00007fa29385b1f3 n/a (libgtk-3.so.0)
                #23 0x00007fa293a7101f gtk_container_propagate_draw (libgtk-3.so.0)
                #24 0x00007fa293a00dd2 n/a (libgtk-3.so.0)
                #25 0x00007fa293aeda9f n/a (libgtk-3.so.0)
                #26 0x00007fa293856e81 n/a (libgtk-3.so.0)
                #27 0x00007fa2934cdd52 g_closure_invoke (libgobject-2.0.so.0)
                #28 0x00007fa2934ba6f0 n/a (libgobject-2.0.so.0)
                #29 0x00007fa2934be67d g_signal_emit_valist (libgobject-2.0.so.0)
                #30 0x00007fa2934bffb0 g_signal_emit (libgobject-2.0.so.0)
                #31 0x00007fa29385b1f3 n/a (libgtk-3.so.0)
                #32 0x00007fa293a7101f gtk_container_propagate_draw (libgtk-3.so.0)
                #33 0x00007fa293a00dd2 n/a (libgtk-3.so.0)
                #34 0x00007fa293aeda9f n/a (libgtk-3.so.0)
                #35 0x00007fa293856e81 n/a (libgtk-3.so.0)
                #36 0x00007fa2934cdd52 g_closure_invoke (libgobject-2.0.so.0)
                #37 0x00007fa2934ba6f0 n/a (libgobject-2.0.so.0)
                #38 0x00007fa2934be67d g_signal_emit_valist (libgobject-2.0.so.0)
                #39 0x00007fa2934bffb0 g_signal_emit (libgobject-2.0.so.0)
                #40 0x00007fa29385b1f3 n/a (libgtk-3.so.0)
                #41 0x00007fa293a7101f gtk_container_propagate_draw (libgtk-3.so.0)
                #42 0x00007fa293a00dd2 n/a (libgtk-3.so.0)
                #43 0x00007fa293aeda9f n/a (libgtk-3.so.0)
                #44 0x00007fa293856e81 n/a (libgtk-3.so.0)
                #45 0x00007fa2934cdd52 g_closure_invoke (libgobject-2.0.so.0)
                #46 0x00007fa2934ba6f0 n/a (libgobject-2.0.so.0)
                #47 0x00007fa2934be67d g_signal_emit_valist (libgobject-2.0.so.0)
                #48 0x00007fa2934bffb0 g_signal_emit (libgobject-2.0.so.0)
                #49 0x00007fa29385b1f3 n/a (libgtk-3.so.0)
                #50 0x00007fa293a7101f gtk_container_propagate_draw (libgtk-3.so.0)
                #51 0x00007fa293a00dd2 n/a (libgtk-3.so.0)
                #52 0x00007fa293aeda9f n/a (libgtk-3.so.0)
                #53 0x00007fa293856e81 n/a (libgtk-3.so.0)
                #54 0x00007fa2934cde55 g_closure_invoke (libgobject-2.0.so.0)
                #55 0x00007fa2934ba6f0 n/a (libgobject-2.0.so.0)
                #56 0x00007fa2934be67d g_signal_emit_valist (libgobject-2.0.so.0)
                #57 0x00007fa2934bffb0 g_signal_emit (libgobject-2.0.so.0)
                #58 0x00007fa29385b1f3 n/a (libgtk-3.so.0)
                #59 0x00007fa293a7101f gtk_container_propagate_draw (libgtk-3.so.0)
                #60 0x00007fa293a723ee n/a (libgtk-3.so.0)
                #61 0x00007fa293ab3e6d n/a (libgtk-3.so.0)
                #62 0x00007fa293a6167d n/a (libgtk-3.so.0)
                #63 0x00007fa293a6b9f1 n/a (libgtk-3.so.0)
                
                Stack trace of thread 5536:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5440:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000056055bb16475 n/a (aegisub)
                #2  0x00007fa29442fcd4 execute_native_thread_routine (libstdc++.so.6)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5436:
                #0  0x00007fa29412f667 __poll (libc.so.6)
                #1  0x00007fa29336e7c0 n/a (libglib-2.0.so.0)
                #2  0x00007fa29336e8ae g_main_context_iteration (libglib-2.0.so.0)
                #3  0x00007fa29336e902 n/a (libglib-2.0.so.0)
                #4  0x00007fa293349f21 n/a (libglib-2.0.so.0)
                #5  0x00007fa294b3057f start_thread (libpthread.so.0)
                #6  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5437:
                #0  0x00007fa29412f667 __poll (libc.so.6)
                #1  0x00007fa29336e7c0 n/a (libglib-2.0.so.0)
                #2  0x00007fa29336f7f2 g_main_loop_run (libglib-2.0.so.0)
                #3  0x00007fa28f0d1508 n/a (libgio-2.0.so.0)
                #4  0x00007fa293349f21 n/a (libglib-2.0.so.0)
                #5  0x00007fa294b3057f start_thread (libpthread.so.0)
                #6  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5575:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa28f9b798f n/a (libavcodec.so.58)
                #2  0x00007fa294b3057f start_thread (libpthread.so.0)
                #3  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5535:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5442:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000056055bb16475 n/a (aegisub)
                #2  0x00007fa29442fcd4 execute_native_thread_routine (libstdc++.so.6)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5546:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5447:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000056055bb16475 n/a (aegisub)
                #2  0x00007fa29442fcd4 execute_native_thread_routine (libstdc++.so.6)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5441:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000056055bb16475 n/a (aegisub)
                #2  0x00007fa29442fcd4 execute_native_thread_routine (libstdc++.so.6)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5545:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5538:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5444:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000056055bb16475 n/a (aegisub)
                #2  0x00007fa29442fcd4 execute_native_thread_routine (libstdc++.so.6)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5572:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa28f9b798f n/a (libavcodec.so.58)
                #2  0x00007fa294b3057f start_thread (libpthread.so.0)
                #3  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5574:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa28f9b798f n/a (libavcodec.so.58)
                #2  0x00007fa294b3057f start_thread (libpthread.so.0)
                #3  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5540:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5537:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5445:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000056055bb16475 n/a (aegisub)
                #2  0x00007fa29442fcd4 execute_native_thread_routine (libstdc++.so.6)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5544:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5539:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5543:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5446:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000056055bb16475 n/a (aegisub)
                #2  0x00007fa29442fcd4 execute_native_thread_routine (libstdc++.so.6)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5571:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa28f9b798f n/a (libavcodec.so.58)
                #2  0x00007fa294b3057f start_thread (libpthread.so.0)
                #3  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5569:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa28f9b798f n/a (libavcodec.so.58)
                #2  0x00007fa294b3057f start_thread (libpthread.so.0)
                #3  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5541:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5542:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5573:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa28f9b798f n/a (libavcodec.so.58)
                #2  0x00007fa294b3057f start_thread (libpthread.so.0)
                #3  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5568:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa28f9b798f n/a (libavcodec.so.58)
                #2  0x00007fa294b3057f start_thread (libpthread.so.0)
                #3  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5570:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa28f9b798f n/a (libavcodec.so.58)
                #2  0x00007fa294b3057f start_thread (libpthread.so.0)
                #3  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5580:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa294429fb1 __gthread_cond_wait (libstdc++.so.6)
                #2  0x000056055bb3b4a4 n/a (aegisub)
                #3  0x00007fa29442fcd4 execute_native_thread_routine (libstdc++.so.6)
                #4  0x00007fa294b3057f start_thread (libpthread.so.0)
                #5  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5578:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x00007fa27a6477bc n/a (radeonsi_dri.so)
                #2  0x00007fa27a6473b8 n/a (radeonsi_dri.so)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5581:
                #0  0x00007fa29412f667 __poll (libc.so.6)
                #1  0x00007fa29463f673 n/a (libpulse.so.0)
                #2  0x00007fa294630990 pa_mainloop_poll (libpulse.so.0)
                #3  0x00007fa294630fe0 pa_mainloop_iterate (libpulse.so.0)
                #4  0x00007fa294631091 pa_mainloop_run (libpulse.so.0)
                #5  0x00007fa29463f5ae n/a (libpulse.so.0)
                #6  0x00007fa290bf39fc n/a (libpulsecommon-12.2.so)
                #7  0x00007fa294b3057f start_thread (libpthread.so.0)
                #8  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5547:
                #0  0x00007fa29412f667 __poll (libc.so.6)
                #1  0x00007fa29463f673 n/a (libpulse.so.0)
                #2  0x00007fa294630990 pa_mainloop_poll (libpulse.so.0)
                #3  0x00007fa294630fe0 pa_mainloop_iterate (libpulse.so.0)
                #4  0x00007fa294631091 pa_mainloop_run (libpulse.so.0)
                #5  0x00007fa29463f5ae n/a (libpulse.so.0)
                #6  0x00007fa290bf39fc n/a (libpulsecommon-12.2.so)
                #7  0x00007fa294b3057f start_thread (libpthread.so.0)
                #8  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 5443:
                #0  0x00007fa294b36415 pthread_cond_wait@@GLIBC_2.3.2 (libpthread.so.0)
                #1  0x000056055bb16475 n/a (aegisub)
                #2  0x00007fa29442fcd4 execute_native_thread_routine (libstdc++.so.6)
                #3  0x00007fa294b3057f start_thread (libpthread.so.0)
                #4  0x00007fa29413a0e3 __clone (libc.so.6)
                
                Stack trace of thread 6600:
                #0  0x00007fa29412f667 __poll (libc.so.6)
                #1  0x00007fa29336e7c0 n/a (libglib-2.0.so.0)
                #2  0x00007fa29336e8ae g_main_context_iteration (libglib-2.0.so.0)
                #3  0x00007fa278050bde n/a (libdconfsettings.so)
                #4  0x00007fa293349f21 n/a (libglib-2.0.so.0)
                #5  0x00007fa294b3057f start_thread (libpthread.so.0)
                #6  0x00007fa29413a0e3 __clone (libc.so.6)

Preset storage for TPP/shift dialogs

The TPP needs presets. Likewise, the shift dialog doesn’t need a history (I don’t care what my parameters were 200 episodes ago) but explicit saving.

Minimizing Aegisub with the video detached makes the desktop grind to a halt

If I minimize Aegisub while the video is detached to its own window, I experience major desktop slowdown. This is particularly noticable with compositing enabled, where it takes up to a minute for events to go through (moving windows, showing hidden panels). Not sure if it's just the rendering that gets slowed down or the actual processing of events.

Running on KWin 5.14.5 for Xorg on Arch Linux with kernel version 4.20.7, KDE version 18.12.2, using official NVidia drivers (version 415.27) on a GT 640.

Minor cosmetic bug: Using the dialogue box followed by undoing (ctrl+z) after a certain zoom level causes the style select box to freak out

Screenshot 1 and 2 show what the bug actually is.
You get the bug by using the dialogue box when the style selector is fully hidden (screenshot 3) by either typing in it or using the visual TS tools while zoomed in (even at 300% zoom level) and undoing (ctrl+z) right after. (Screenshot 4-5) If you're at zoom 300% and use the visual ts tools e.g. drag tool followed by zooming out till the dialogue box is visible, the bug still shows up.
Only occurs when the style selector is fully hidden. Bug doesn't show up with the style selector is fully/partially visible.
More or less a cosmetic bug since it doesn't actually prevent you from selecting a style (screenshot 6). It just obstructs the dialogue box.
The style select menu stays on screen (screenshot 5+7) til you zoom out enough so the style select box is fully visible again (screenshot 8).

Screenshot 1: https://i.imgur.com/1RZ64yp.png (Script bug)
Screenshot 2: https://i.imgur.com/qAejBVG.png (Same bug just hovering your mouse over highlight it more)
Screenshot 3: https://i.imgur.com/Sc6HyWD.jpg (Actual view of the script)
Screenshot 4: https://i.imgur.com/ygy4PdG.jpg (e.g using the drag tool before undoing)
Screenshot 5: https://i.imgur.com/UDpW3jq.jpg (Actual view of the script with the bug)
Screenshot 6: https://i.imgur.com/2fdYsm0.jpg (Functional style selector with bug)
Screenshot 7: https://i.imgur.com/iySSgxl.jpg (Different zoom with bug present)
Screenshot 8: https://i.imgur.com/l5HxOrq.jpg (Lowest zoom with bug disappears)

Occasional crashes when opening file dialogs

Sometimes when opening a file dialog, e.g. through an automation using aegisub.dialog.open, Aegisub will crash. Running Aegisub in a debugger, I get the following backtrace:

Thread 6 "aegisub" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe8551700 (LWP 14134)]
0x00007ffff5c21d7f in raise () from /usr/lib/libc.so.6
(gdb) bt
#0  0x00007ffff5c21d7f in raise () at /usr/lib/libc.so.6
#1  0x00007ffff5c0c672 in abort () at /usr/lib/libc.so.6
#2  0x00007ffff5c64878 in __libc_message () at /usr/lib/libc.so.6
#3  0x00007ffff5c6b18a in  () at /usr/lib/libc.so.6
#4  0x00007ffff5c6b6e4 in  () at /usr/lib/libc.so.6
#5  0x00007ffff542a8fd in  () at /usr/lib/libgtk-3.so.0
#6  0x00007ffff505c440 in g_object_unref () at /usr/lib/libgobject-2.0.so.0
#7  0x00007ffff558fdfb in  () at /usr/lib/libgtk-3.so.0
#8  0x00007ffff505c440 in g_object_unref () at /usr/lib/libgobject-2.0.so.0
#9  0x00007ffff563eeeb in  () at /usr/lib/libgtk-3.so.0
#10 0x00007ffff505c440 in g_object_unref () at /usr/lib/libgobject-2.0.so.0
#11 0x00007ffff4f0af05 in  () at /usr/lib/libglib-2.0.so.0
#12 0x00007ffff4f0dbe0 in g_hash_table_remove_all () at /usr/lib/libglib-2.0.so.0
#13 0x00007ffff4f0dc2f in g_hash_table_destroy () at /usr/lib/libglib-2.0.so.0
#14 0x00007ffff4f0af05 in  () at /usr/lib/libglib-2.0.so.0
#15 0x00007ffff4f0dbe0 in g_hash_table_remove_all () at /usr/lib/libglib-2.0.so.0
#16 0x00007ffff4f0dc2f in g_hash_table_destroy () at /usr/lib/libglib-2.0.so.0
#17 0x00007ffff562de17 in  () at /usr/lib/libgtk-3.so.0
#18 0x00007ffff5059e75 in g_closure_invoke () at /usr/lib/libgobject-2.0.so.0
#19 0x00007ffff504736b in  () at /usr/lib/libgobject-2.0.so.0
#20 0x00007ffff504b1ae in g_signal_emit_valist () at /usr/lib/libgobject-2.0.so.0
--Type <RET> for more, q to quit, c to continue without paging--
#21 0x00007ffff504c080 in g_signal_emit () at /usr/lib/libgobject-2.0.so.0
#22 0x00007ffff56362fe in  () at /usr/lib/libgtk-3.so.0
#23 0x00007ffff505c8e9 in g_object_run_dispose () at /usr/lib/libgobject-2.0.so.0
#24 0x00007ffff54d986d in  () at /usr/lib/libgtk-3.so.0
#25 0x00007ffff5528554 in  () at /usr/lib/libgtk-3.so.0
#26 0x00007ffff552a9de in gtk_places_sidebar_set_local_only () at /usr/lib/libgtk-3.so.0
#27 0x00007ffff505e911 in g_object_setv () at /usr/lib/libgobject-2.0.so.0
#28 0x00007ffff505eacf in g_object_set_property () at /usr/lib/libgobject-2.0.so.0
#29 0x00007ffff53cd38d in  () at /usr/lib/libgtk-3.so.0
#30 0x00007ffff53d0027 in  () at /usr/lib/libgtk-3.so.0
#31 0x00007ffff4ef5ec4 in  () at /usr/lib/libglib-2.0.so.0
#32 0x00007ffff4ef6e1a in g_markup_parse_context_parse () at /usr/lib/libglib-2.0.so.0
#33 0x00007ffff53d0a82 in  () at /usr/lib/libgtk-3.so.0
#34 0x00007ffff53cb6fa in gtk_builder_extend_with_template () at /usr/lib/libgtk-3.so.0
#35 0x00007ffff563e153 in gtk_widget_init_template () at /usr/lib/libgtk-3.so.0
#36 0x00007ffff5478be1 in  () at /usr/lib/libgtk-3.so.0
#37 0x00007ffff5041722 in g_type_create_instance () at /usr/lib/libgobject-2.0.so.0
#38 0x00007ffff505f509 in  () at /usr/lib/libgobject-2.0.so.0
#39 0x00007ffff50606cd in g_object_newv () at /usr/lib/libgobject-2.0.so.0
#40 0x00007ffff53cd46b in  () at /usr/lib/libgtk-3.so.0
#41 0x00007ffff53cead6 in  () at /usr/lib/libgtk-3.so.0
--Type <RET> for more, q to quit, c to continue without paging--
#42 0x00007ffff53d062d in  () at /usr/lib/libgtk-3.so.0
#43 0x00007ffff4ef4b72 in  () at /usr/lib/libglib-2.0.so.0
#44 0x00007ffff4ef6fe7 in g_markup_parse_context_parse () at /usr/lib/libglib-2.0.so.0
#45 0x00007ffff53d0a82 in  () at /usr/lib/libgtk-3.so.0
#46 0x00007ffff53cb6fa in gtk_builder_extend_with_template () at /usr/lib/libgtk-3.so.0
#47 0x00007ffff563e153 in gtk_widget_init_template () at /usr/lib/libgtk-3.so.0
#48 0x00007ffff546feaf in  () at /usr/lib/libgtk-3.so.0
#49 0x00007ffff5041722 in g_type_create_instance () at /usr/lib/libgobject-2.0.so.0
#50 0x00007ffff505f509 in  () at /usr/lib/libgobject-2.0.so.0
#51 0x00007ffff5060154 in g_object_new_valist () at /usr/lib/libgobject-2.0.so.0
#52 0x00007ffff5060aea in g_object_new () at /usr/lib/libgobject-2.0.so.0
#53 0x00007ffff54709d6 in gtk_file_chooser_dialog_new () at /usr/lib/libgtk-3.so.0
#54 0x00007ffff773ce72 in wxFileDialog::Create(wxWindow*, wxString const&, wxString const&, wxString const&, wxString const&, long, wxPoint const&, wxSize const&, wxString const&) ()
    at /usr/lib/libwx_gtk3u_core-3.0.so.0
#55 0x00007ffff773e22c in wxFileDialog::wxFileDialog(wxWindow*, wxString const&, wxString const&, wxString const&, wxString const&, long, wxPoint const&, wxSize const&, wxString const&) ()
    at /usr/lib/libwx_gtk3u_core-3.0.so.0
#56 0x0000555555880fc9 in Automation4::LuaProgressSink::LuaDisplayOpenDialog(lua_State*) (L=0x40000378, L@entry=<error reading variable: value has been optimized out>) at /usr/include/wx-3.0/wx/string.h:3488
#57 0x0000555555a1b76a in agi::lua::exception_wrapper(lua_State*, int (*)(lua_State*)) (L=0x40000378, func=<optimized out>) at /usr/src/debug/aegisub/libaegisub/lua/utils.cpp:218
#58 0x00005555559dd619 in lj_BC_FUNCC () at /usr/src/debug/aegisub/libaegisub/include/libaegisub/format.h:47
#59 0x00005555559cc9dc in lua_pcall (L=<optimized out>, nargs=<optimized out>, nresults=<optimized out>, errfunc=<optimized out>) at lj_api.c:1052
#60 0x000055555586a2d7 in (anonymous namespace)::<lambda(Automation4::ProgressSink*)>::operator() (ps=0x7fffe8550690, __closure=0x55555613eef0) at /usr/src/debug/aegisub/src/auto4_lua.cpp:634
--Type <RET> for more, q to quit, c to continue without paging--
#61 0x000055555586a2d7 in std::_Function_handler<void(Automation4::ProgressSink*), (anonymous namespace)::LuaThreadedCall(lua_State*, int, int, const string&, wxWindow*, bool)::<lambda(Automation4::ProgressSink*)> >::_M_invoke(const std::_Any_data &, Automation4::ProgressSink *&&) (__functor=..., __args#0=<optimized out>) at /usr/include/c++/8.2.1/bits/std_function.h:297
#62 0x000055555585fbf1 in std::function<void (Automation4::ProgressSink*)>::operator()(Automation4::ProgressSink*) const (__args#0=<optimized out>, this=<optimized out>)
    at /usr/include/c++/8.2.1/bits/std_function.h:682
#63 0x000055555585fbf1 in Automation4::BackgroundScriptRunner::<lambda(agi::ProgressSink*)>::operator() (__closure=0x55555a4cd680, __closure=0x55555a4cd680, ps=<optimized out>)
    at /usr/src/debug/aegisub/src/auto4_base.cpp:244
#64 0x000055555585fbf1 in std::_Function_handler<void(agi::ProgressSink*), Automation4::BackgroundScriptRunner::Run(std::function<void(Automation4::ProgressSink*)>)::<lambda(agi::ProgressSink*)> >::_M_invoke(const std::_Any_data &, agi::ProgressSink *&&) (__functor=..., __args#0=<optimized out>) at /usr/include/c++/8.2.1/bits/std_function.h:297
#65 0x00005555557327bf in std::function<void (agi::ProgressSink*)>::operator()(agi::ProgressSink*) const (__args#0=<optimized out>, this=0x55555a4cd680) at /usr/include/c++/8.2.1/bits/std_function.h:682
#66 0x00005555557327bf in DialogProgress::<lambda()>::operator() (__closure=0x55555a4cd660) at /usr/src/debug/aegisub/src/dialog_progress.cpp:154
#67 0x00005555557327bf in std::_Function_handler<void(), DialogProgress::Run(std::function<void(agi::ProgressSink*)>)::<lambda()> >::_M_invoke(const std::_Any_data &) (__functor=...)
    at /usr/include/c++/8.2.1/bits/std_function.h:297
#68 0x0000555555a63e38 in std::function<void ()>::operator()() const (this=<optimized out>) at /usr/include/c++/8.2.1/bits/std_function.h:682
#69 0x0000555555a63e38 in agi::dispatch::Queue::<lambda()>::operator() (__closure=<optimized out>) at /usr/src/debug/aegisub/libaegisub/common/dispatch.cpp:96
#70 0x0000555555a63e38 in std::_Function_handler<void(), agi::dispatch::Queue::Async(agi::dispatch::Thunk)::<lambda()> >::_M_invoke(const std::_Any_data &) (__functor=...)
    at /usr/include/c++/8.2.1/bits/std_function.h:297
#71 0x0000555555a67a1e in std::function<void ()>::operator()() const (this=0x7fffe85507c0) at /usr/include/c++/8.2.1/bits/std_function.h:682
#72 0x0000555555a67a1e in boost::asio::asio_handler_invoke<std::function<void ()> >(std::function<void ()>&, ...) (function=...) at /usr/include/boost/asio/handler_invoke_hook.hpp:69
#73 0x0000555555a67a1e in boost_asio_handler_invoke_helpers::invoke<std::function<void ()>, std::function<void ()> >(std::function<void ()>&, std::function<void ()>&) (context=..., function=...)
    at /usr/include/boost/asio/detail/handler_invoke_helpers.hpp:37
#74 0x0000555555a67a1e in boost::asio::detail::handler_work<std::function<void ()>, boost::asio::system_executor>::complete<std::function<void ()> >(std::function<void ()>&, std::function<void ()>&)
--Type <RET> for more, q to quit, c to continue without paging--
    (this=<synthetic pointer>, handler=..., function=...) at /usr/include/boost/asio/detail/handler_work.hpp:82
#75 0x0000555555a67a1e in boost::asio::detail::completion_handler<std::function<void ()> >::do_complete(void*, boost::asio::detail::scheduler_operation*, boost::system::error_code const&, unsigned long)
    (owner=0x555555de9f00, base=<optimized out>) at /usr/include/boost/asio/detail/completion_handler.hpp:70
#76 0x0000555555a65577 in boost::asio::detail::scheduler_operation::complete(void*, boost::system::error_code const&, unsigned long) (bytes_transferred=0, ec=..., owner=0x555555de9f00, this=<optimized out>)
    at /usr/include/boost/asio/detail/scheduler_operation.hpp:40
#77 0x0000555555a65577 in boost::asio::detail::scheduler::do_run_one(boost::asio::detail::conditionally_enabled_mutex::scoped_lock&, boost::asio::detail::scheduler_thread_info&, boost::system::error_code const&)
    (ec=..., this_thread=..., lock=..., this=0x555555de9f00) at /usr/include/boost/asio/detail/impl/scheduler.ipp:401
#78 0x0000555555a65577 in boost::asio::detail::scheduler::run(boost::system::error_code&) (ec=..., this=0x555555de9f00) at /usr/include/boost/asio/detail/impl/scheduler.ipp:154
#79 0x0000555555a65577 in boost::asio::io_context::run() (this=<optimized out>) at /usr/include/boost/asio/impl/io_context.ipp:62
#80 0x0000555555a65577 in agi::dispatch::<lambda()>::operator() (__closure=<optimized out>) at /usr/src/debug/aegisub/libaegisub/common/dispatch.cpp:87
#81 0x0000555555a65577 in std::__invoke_impl<void, agi::dispatch::Init(std::function<void(std::function<void()>)>)::<lambda()> > (__f=...) at /usr/include/c++/8.2.1/bits/invoke.h:60
#82 0x0000555555a65577 in std::__invoke<agi::dispatch::Init(std::function<void(std::function<void()>)>)::<lambda()> > (__fn=...) at /usr/include/c++/8.2.1/bits/invoke.h:95
#83 0x0000555555a65577 in std::thread::_Invoker<std::tuple<agi::dispatch::Init(std::function<void(std::function<void()>)>)::<lambda()> > >::_M_invoke<0> (this=<optimized out>)
    at /usr/include/c++/8.2.1/thread:244
#84 0x0000555555a65577 in std::thread::_Invoker<std::tuple<agi::dispatch::Init(std::function<void(std::function<void()>)>)::<lambda()> > >::operator() (this=<optimized out>) at /usr/include/c++/8.2.1/thread:253
#85 0x0000555555a65577 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<agi::dispatch::Init(std::function<void(std::function<void()>)>)::<lambda()> > > >::_M_run(void) (this=<optimized out>)
    at /usr/include/c++/8.2.1/thread:196
#86 0x00007ffff6009063 in std::execute_native_thread_routine(void*) (__p=0x555555f9baf0) at /build/gcc/src/gcc/libstdc++-v3/src/c++11/thread.cc:80
#87 0x00007ffff66c0a9d in start_thread () at /usr/lib/libpthread.so.0
#88 0x00007ffff5ce5b23 in clone () at /usr/lib/libc.so.6

Considering the g_object_unref calls, perhaps it is an issue with reference counting?

Find / Find and Replace duplication behavior with Skip Override Tags

correct-behavior-noskip
This is the expected behavior, one find and the proper location.
.
.
.
correct-replace-all
Same situation here, works as expected.
.
.
.
But, with Skip Override Tags ticked and an override tag in the line, it does this:
bug-skip
bug-skip-second-find
It finds two locations, which isn't necesarily bad if it was just a visual bug. But this affects Find and Replace which is a larger issue.
incorrect-replace-all


Interestingly, if the tag length is longer than the text before the Find word, it doesn't result in this bug. This can be seen here:
too-short-maybe
(it only finds one "of")
But, it's not the tag length itself bugging it out, it can work with any tag length, as long as the search word is after some text longer than the tag.
long-tags-too


Steps to reproduce:

"Drag subtitle" box being same color after build 8903

I have been on build 8903 for a long time, but decided to update yesterday to latest available one (8975). After a day, I noticed that the drag tool box is same color no matter which line is selected (which means, the color is if the all lines were selected at the same time). For more clarity see screenshots:
bugged
Here is the drag box in same color on 8975
working
And here is how it works on 8903, unselected line being different color.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.