typesettingtools / aegisub Goto Github PK
View Code? Open in Web Editor NEWCross-platform advanced subtitle editor
Home Page: http://www.aegisub.org
License: Other
Cross-platform advanced subtitle editor
Home Page: http://www.aegisub.org
License: Other
Title.
Things blocking that:
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.
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.
Original issue: Adding support for italics in the config
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
Aegisub/src/dialog_video_properties.cpp
Lines 128 to 131 in 26ccf0b
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.
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:
Match video resolution on open
set to Ask
under Preferences > General > Video)Set to video resolution
Resample script
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.
Apparently ctrl+scroll wheel being horizontal zoom in particular is an issue for some workflows.
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:
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.
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.
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.
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:
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.
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.
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.
Title. May be worth making them emit a deprecation warning on use for future removal, but I need to see how much use they see in both internal and external scripts.
Somehow this started happening today on my machine.
To reproduce:
Line 87 in 75fc5f3
Steps to reproduce:
The feature will work as expected after undoing the action and manually adjusting the line start/end time.
Drag Subtitles
modeI tap the arrow keys (or other assigned hotkeys)
I want the sign to adjust it's position by 1 pixel
Shift +
means "move by 10 pixels"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
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.
Ideally this would just be another setting in the "Colors" options page.
CoffeeFlux asked me to file an issue here instead so here it is.
Line 128 in 26ccf0b
The "Move Down" button on the "Export Subtitles..." window has the same behavior as the "Move Up" button for the filter list. Think the line should be a +
not -
.
Is it possible to reinsert AssDraw3 link directly in aegisub toolbar?
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()
.
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.
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
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.
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.
Aegisub should expose some way of parsing MoonScript from an automation, e.g. by providing a function similar to Lua's loadstring, but for a string of MoonScript code.
To repro, load a video, load the embedded subs, and then print aegisub.project_properties().video_file
, which will be a zero-length string.
Aegisub/packages/win_installer/fragment_associations.iss
Lines 38 to 40 in 75fc5f3
[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?
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."
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 ;)
(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,
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.
Two separate files were provided to me privately in which this occurs. Putting the issue here so I can keep track of it.
File provided privately. Putting this here for tracking purposes.
Title.
Putting {\t(}}
on a line, your marker between the parenthesis, and then hitting ctrl+1 will actually put the color outside of the tag. This is probably not ideal behavior.
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.
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)
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.
Attempting the load the following file will error with invalid characters, despite that it appears to be proper UTF-8: https://sharex.thevacuumof.space/2019/03/test02.ass
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.
Title. Reported by herkz.
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)
Issue: Title
Recreation: In mkvmerge, mux video with zlib compression enabled for the subtitle track. Open video in Aegisub and "Open subtitles from video" will be grayed out.
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?
This is the expected behavior, one find and the proper location.
.
.
.
Same situation here, works as expected.
.
.
.
But, with Skip Override Tags
ticked and an override tag in the line, it does this:
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.
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:
(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.
Steps to reproduce:
Find
"word", "of" and "out" to see all different examplesFind and Replace
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:
Here is the drag box in same color on 8975
And here is how it works on 8903, unselected line being different color.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.