Can't open multiple files at once

[datsudo]

Steps of what I did:

• Opened new PDF (sample.pdf)
• Tried to open another PDF but outputs the log below
• Exited sample.pdf but the sioyek process remains running, consuming ~250MB memory.

Hence, I had to manually kill that process to open another file.

Here's the log for opening the first file:

default_config_path: /etc/sioyek/prefs.config
default_keys_path: /etc/sioyek/keys.config
user_config_path: [ 0 ] /etc/xdg/sioyek/prefs_user.config
user_config_path: [ 1 ] /home/datsudo/.config/kdedefaults/sioyek/prefs_user.config
user_config_path: [ 2 ] /home/datsudo/.config/sioyek/prefs_user.config
user_keys_path: [ 0 ] /etc/xdg/sioyek/keys_user.config
user_keys_path: [ 1 ] /home/datsudo/.config/kdedefaults/sioyek/keys_user.config
user_keys_path: [ 2 ] /home/datsudo/.config/sioyek/keys_user.config
database_file_path: /home/datsudo/.local/share/sioyek/test.db
local_database_file_path: /home/datsudo/.local/share/sioyek/local.db
global_database_file_path: /home/datsudo/.local/share/Sioyek/shared.db
tutorial_path: /usr/share/sioyek/tutorial.pdf
last_opened_file_address_path: /home/datsudo/.local/share/sioyek/last_document_path.txt
shader_path: /usr/share/sioyek/shaders
Creating shared memory block...
Shared memory created: this is the primary application.
Starting IPC server...
IPC server started.

When opening another file:

default_config_path: /etc/sioyek/prefs.config
default_keys_path: /etc/sioyek/keys.config
user_config_path: [ 0 ] /etc/xdg/sioyek/prefs_user.config
user_config_path: [ 1 ] /home/datsudo/.config/kdedefaults/sioyek/prefs_user.config
user_config_path: [ 2 ] /home/datsudo/.config/sioyek/prefs_user.config
user_keys_path: [ 0 ] /etc/xdg/sioyek/keys_user.config
user_keys_path: [ 1 ] /home/datsudo/.config/kdedefaults/sioyek/keys_user.config
user_keys_path: [ 2 ] /home/datsudo/.config/sioyek/keys_user.config
database_file_path: /home/datsudo/.local/share/sioyek/test.db
local_database_file_path: /home/datsudo/.local/share/sioyek/local.db
global_database_file_path: /home/datsudo/.local/share/Sioyek/shared.db
tutorial_path: /usr/share/sioyek/tutorial.pdf
last_opened_file_address_path: /home/datsudo/.local/share/sioyek/last_document_path.txt
shader_path: /usr/share/sioyek/shaders
Creating shared memory block...
Shared memory already exists: this is a secondary application.
Secondary application attaching to shared memory block...
Secondary application successfully attached to shared memory block.
Secondary application sent message to IPC server.

---

Here's my prefs_user.config:

font_size 15
status_bar_font_size 10
fit_to_page_width_ratio 1.0
should_launch_new_window 1
show_document_name_in_statusbar 1
super_fast_search 1
collapsed_toc 1
sort_bookmarks_by_location 1
create_table_of_contents_if_not_exists 0
shared_database_path /home/datsudo/.local/share/Sioyek/shared.db
dark_mode_background_color 0.15 0.16 0.13
custom_background_color 0.15 0.16 0.13
status_bar_color 0.15 0.16 0.13
startup_commands fit_to_page_width_ratio,toggle_custom_color

More details:

• sioyek version: 2.0.0
• OS: Arch Linux (I installed sioyek-git from AUR)

[HakonHarnes]

Try setting should_launch_new_window 1 in pref_user.config or opening the second document using the --new-window flag.

[datsudo]

Try setting should_launch_new_window 1 in pref_user.config or opening the second document using the --new-window flag.

should_launch_new_window 1 is already in my config.

[r0x57n]

Try setting should_launch_new_window 1 in pref_user.config or opening the second document using the --new-window flag.

should_launch_new_window 1 is already in my config.

Did you get the same issue with the --new-window flag? (if no, have you verified your config file is being parsed?)

I'm on the same setup and don't have the problem you describe (without using the --new-window flag). My config is:

should_launch_new_window 1
sort_bookmarks_by_location 1
highlight_middle_click 1
show_closest_bookmark_in_statusbar 1
show_document_name_in_statusbar 1
toggle_horizontal_scroll_lock 1

custom_color_contrast 0.3
custom_color_mode_empty_background_color #1d2021
page_separator_color #1d2021
page_separator_width 10
custom_background_color #282828
custom_text_color #fbf1c7
search_highlight_color #7ec16e
status_bar_color #427b58
status_bar_text_color #fbf1c7

[BiliBraker]

Maybe related: https://github.com/ahrm/sioyek/issues/735#issue-1737293187

[adigitoleo]

I'm having similar issues with --new-window and --new-instance. A quick peek at the tree reveals that --new-instance is commented out in the opt parser (maybe the CLI help needs fixing there), but I'm not immediately sure why --new-window doesn't work. For me it simply doesn't launch a new window, although I haven't observed the memory issues. Also on v2. If I set should_launch_new_window to 1 in the config file it behaves as expected. However, I usually want to reuse the window except in rare cases, so it would be nice to have the CLI option working as well.

Obviously there is a simple workaround for my case: Open a new window first, then open the new file.

[Bluey26]

Hello. Same issue here, but using the sioyek-appimage from the AUR.

whenever i try to open a new document using sioyek, this makes the 1st document to crash and the second document is not opened either.

Each one of the sioyek packages present in the AUR has its problems, but i have tried also sioyek 2.0.0-5 package (not the appimage or the git one), and that one seems to be able to open 2 windows at same time. (that version has other problems, like the not working 'fit_to_page_width' option, which works in all other sioyek versions in the AUR).

should_launch_new_window 1 is present in my prefs_user.config file, other config options seem to work properly in the appimage version, but this does not.

OS: Arch Linux

The only 'relevant' information that i get when the program crashes, is:

terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
  what():  filesystem error: Cannot convert character sequence: Invalid or incomplete multibyte or wide character
Aborted (core dumped)

So this may be related to: https://github.com/ahrm/sioyek/issues/744 , https://github.com/ahrm/sioyek/issues/638

In the other hand, the sioyek-git from the AUR does have the same problem, but it throws another error:

/usr/include/c++/13.2.1/bits/stl_vector.h:1125: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = int; _Alloc = std::allocator<int>; reference = int&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.
Aborted (core dumped)

I just have compiled and tried this one, a few moments ago.

Thank you very much for this program.

Bluey.

[adigitoleo]

For me the --new-window issue was resolved by a distro upgrade to mupdf: https://github.com/void-linux/void-packages/pull/48724

Which means that #856 was the probable culprit.