[3.3.0.dev6] Developer Discussion

[slook]

Matters regarding the nicotine-plus code that are relevant for the imminent version of Nicotine+ 3.3.0

**This is not a conversation thread, and as such, please keep replies in-line and on-topic.**

[slook]

Unresolved and outstanding topics from previous Developer Discussion threads:
#2766 (comment)

[slook]

Fixed in Nicotine+ 3.2.5 - Mentions in the Public room could specify the actual originating chat room instead of "Public"

Also the notification is not required if the actual room chat tab is open, so would ideally be suppressed to prevent duplicate double popup.

[slook]

See PR #2161

[slook]

RESOLVED in Nicotine+ 3.3.0.dev4 - Certain fonts seem to perform worse on Windows with Cairo 1.17.6

Looks like a regression in Cairo 1.17.6. I'll downgrade it to 1.17.4 until I've investigated the issue.
the colored emoji are too stretched with this Cairo version

nicotine-plus/packaging/windows/dependencies_core.py

Lines 49 to 50 in 80e3a29

	# Downgrade Cairo for now due to text rendering performance issues
	downgrade_packages = [prefix + "cairo-1.17.4-4-any.pkg.tar.zst"]

[slook]

Added in Nicotine+ 3.2.5 - Browse Shares indeterminate progress during initial connection phase

Currently there is not any visual indication that a connection attempt is in progress, and the timeout is long.

The ProgressBar could be indeterminate until the list of shared files starts loading, or some other widget to indicate status of the browse attempt.

[slook]

Edit: superseeded by 5a8425f -- see PR #2160 Indeterminate progress bar pulsing initially

It seemed that it was intended but not implemented. There doesn't seem to be any scenario or reason why a pulsing bar would not be desirable.

[mathiascode]

It's something I wanted to do in the past, but never got around to until now.

[slook]

DONE in Nicotine+ 3.3.0.dev5 - Closing a Browse Shares tab would ideally abort getting the list of shared files

If it is going to take a very long time to get the list, the tab might get closed early instead of waiting for it, but the file list continues to be received as shown in the Msg log:

...
2022-09-06 00:07:05 [Msg] <class 'pynicotine.slskmessages.MessageProgress'> {'position': 1564200, 'user': '<username>', 'total': 7240390, 'msg_type': <class 'pynicotine.slskmessages.SharedFileList'>}
...

In order to prevent wasted data consumption, perhaps there is a way of closing the connection or otherwise abandoning the request when the in-progress Browse Shares tab is closed by the user?

[mathiascode]

The only way would be to close the connection, but I have to verify if queued peer messages are lost when doing this.

[slook]

If the associated connection cannot be referenced directly, then it is not worth making large changes for this minor optimization.

[slook]

Done in 64340d6

[slook]

RESOLVED - In progress Uploads don't automatically resume upon application restart

Their status is "Cancelled", whereas it would be expected to see "Transferring" as they were in the previous session. The stuck uploads can be manually resumed. Regardless of mathiascode@b676632

(only tested in the 3.2.x branch).

[mathiascode]

Rescan on startup enabled? Debug logs would be helpful.

[slook]

Yes rescan on startup enabled. Only Transfers logging was captured:

2022-09-07 20:28:50 Rescanning shares…
2022-09-07 20:28:50 316 folders found before rescan, rebuilding…
2022-09-07 20:28:50 Loading plugin system
...
2022-09-07 20:28:50 Connecting to server.slsknet.org:2242
2022-09-07 20:28:50 Connected to server server.slsknet.org:2242, logging in…
2022-09-07 20:28:50 Rescan complete: 316 folders found
2022-09-07 20:28:50 1818 privileged users
2022-09-07 20:28:50 You have no privileges. Privileges are not required, but allow your downloads to be queued ahead of non-privileged users.
2022-09-07 20:28:51 [Transfer] Received upload request for file play\folder\name\filename.mp3 from user username
2022-09-07 20:28:51 [Transfer] Checking if file is shared: play\folder\name\filename.mp3 with real path /media/user/USER/UserDIR/folder/name/filename.mp3
2022-09-07 20:28:51 [Transfer] Upload request for file play\folder\name\filename.mp3 from user username: allowed: True, reason: None
2022-09-07 20:28:51 [Transfer] Checked upload queue, attempting to upload file play\folder\name\filename.mp3 to user username
2022-09-07 20:28:51 [Transfer] Initializing upload request for file play\folder\name\filename.mp3 to user username

It stuck here, then 10 seconds later it was manually resumed...

2022-09-07 20:29:01 [Transfer] Initializing upload request for file play\folder\name\filename.mp3 to user username
2022-09-07 20:29:01 [Transfer] Requesting to upload file play\folder\name\filename.mp3 with token 1 to user username
2022-09-07 20:29:01 [Transfer] Received response for upload request 1: allowed: True, reason: None, file size: None
2022-09-07 20:29:02 [Transfer] Initializing upload with token 1 for file play\folder\name\filename.mp3 to user username
2022-09-07 20:29:02 [Transfer] Checking if file is shared: play\folder\name\filename.mp3 with real path /media/user/USER/UserDIR/folder/name/filename.mp3
2022-09-07 20:29:02 [Upload] Upload started: user username, IP address ('1.2.3.4', 12345), file play\folder\name\filename.mp3

Unfortunately Connections log was not enabled, I try to notice next time there is an upload to capture it.

[slook]

This seems to be resolved now in master at least. Edit: and also 3.2.x does resume upon restart also.

[slook]

RESOLVED in Nicotine+ 3.2.6 - Preferences Downloads 'Incomplete file folder chooser' button does not open at default location

Even when hidden files are shown, the user's home parent is opened instead of the default "incomplete" folder (/home/user/.local/share/nicotine/incomplete).

When a custom incomplete folder is set, then the chooser button opens at the correct location.

GTK 3.24.24

[mathiascode]

That usually means the folder doesn't exist (yet).

[mathiascode]

I let the file chooser handle the fallback location in 943e622

[slook]

Correct it was first run so the folder didn't exist yet.

Falling back to nearest parent is very helpful, since hidden files are not usually shown discovery of the default user data location was a complete mystery before.

[slook]

REMOVED in Nicotine+ 3.3.0.dev5 - Chat room Auto-join Room toggle button misaligned on certain standard theme(s)

MX Linux 21 (Xfce) default theme "mx-comfort-dark" 3.3.0.dev3 • GTK 3.24.24

[mathiascode]

What's increasing the height on the left side? Is it the text entry or the help button?

[mathiascode]

This is a theme issue. I don't know if it's an intentional design decision, but changing the padding of GtkEntry from 5px to 3px fixes the issue.

entry {
    padding-top: 3px;
    padding-bottom: 3px;
}

I suppose you could try reporting it here: https://github.com/MX-Linux/mx-comfort-themes

[slook]

I thought as much thank you for padding fix. I won't be reporting the theming issue to the author because I don't see any visual discrepancies in other apps, and in any case I'm not particularly attached to the theme in question given as default on a modern distro.

Mearly it is just an observation that a margin for error exists which has a chance of affecting other themes.

[slook]

Keyboard accelerators should not respond to key-repeat events

FIXED in Nicotine+ 3.2.6 - For example, holding Ctrl+H results in a temporary ban. Ideally such erroneous behaviours should be avoided.

[slook]

2022-10-08 02:47:59 [l_] perhaps Away/Home need to be on seperate keys
2022-10-08 02:48:35 [l_] Home = Ctrl+H
2022-10-08 02:48:48 [l_] Away = Shift+Ctrl+H
2022-10-08 03:15:21 [_4] i do support moving the away shortcut behind shift+ctrl at least

[mathiascode]

Add type hints to the codebase

Almost all recent critical errors have been caused by silly mistakes such as forgetting to rename attributes in certain files. Adding type hints would allow us to catch these errors during CI, make the codebase easier to work with for people not familiar with it, and reduce stress from code refactors.

This should be applied to the core first. When it comes to the GUI, I'm not sure what the state of type hints in PyGObject is right now. This should be looked into.

https://docs.python.org/3/library/typing.html

[mathiascode]

I want to explore all possibilities before committing to this change though. In my opinion, type hints can quickly become hairy and make the code difficult to read, and it's a lot of work to add hints to every file.

[slook]

In my opinion, type hints can quickly become hairy and make the code difficult to read, and it's a lot of work...

I agree. Is there some external way to check for things like non-existent attributes, perhaps can run a script in Actions or suchlike?

Perhaps there are some stratigy to check membership similar to self.widgets that can be applied on a module level?

[mathiascode]

I had some hands-on experience with type hints recently when adding them to tinytag, and I think they would be a good fit for Nicotine+. The syntax became a lot more readable in recent years, and the newer syntax can be used in Python 3.7+.

Type hinting would eliminate all the silly mistakes when refactoring code, like forgetting to update references to attributes. It would also encourage us to keep function/method parameters simple. In tinytag, I only had to add type hints to function parameters and init(), mypy could infer the rest. In other words, it's not like some other programming languages where explicit types are required for every variable.

It's something I want to explore for Nicotine+ once we drop support for Python 3.6.

[slook]

FIXED in Nicotine+ 3.3.0 -Very long user note in Buddies need ellipisizing and a tooltip

If the string is long then it cannot be easily read, because the last column cannot be expanded in width.

[mathiascode]

Fixed in 3ea3b9b

[slook]

DONE in Nicotine+ 3.3.0 - User request: Preset Filetype filter specific to video files

There is a valid use case for filtering videos in or out of the search results.

[slook]

DONE in Nicotine+ 3.3.0.dev5 - Sample Rate data is not displayed anywhere

For lossless files if it is listed could probably add it to the file properties dialog

[slook]

FIXED in Nicotine+ 3.2.7 - We should probably verify if UPnP devices sent to us are duplicates or not

"I suppose you could still have multiple routers" see #2200 (comment)

[mathiascode]

This was fixed recently.

[slook]

WONTFIX - Incorrectly formatted status bar error message for Download folder error

OS error: [Errno 13] Permission denied: b'/mount/user/downloads/completed'

nicotine-plus/pynicotine/transfers.py

Lines 1953 to 1954 in e86828d

	self.core.notifications.new_text_notification(
	_("OS error: %s") % error, title=_("Download folder error"))

and when scanning shares there is b'':

Error while scanning folder /media/user/share: [Errno 2] No such file or directory: b'/media/user/share'

[mathiascode]

That error is provided by the OS, not much we can do about the byte string (you can probably do some ugly string manipulation, but I don't think it's worth the effort).

[slook]

FIXED [dev5] - AttributeError on open Preferences after it was previously open on another page

On Open Preferences (with cog icon button) -> User Interface page -> Close -> Open Preferences...

Nicotine+ Version: 3.3.0.dev5
GTK Version: 3.24.24
Python Version: 3.9.2 (linux)

Type: <class 'AttributeError'>
Value: 'gi.repository.Gtk' object has no attribute 'FontDialogButton'
Traceback:   File "/home/user/Git/nicotine-plus/pynicotine/gtkgui/application.py", line 550, in on_configure_chats
    self.on_preferences(page_id="chats")
  File "/home/user/Git/nicotine-plus/pynicotine/gtkgui/application.py", line 372, in on_preferences
    self.preferences.set_settings()
  File "/home/user/Git/nicotine-plus/pynicotine/gtkgui/dialogs/preferences.py", line 2855, in set_settings
    page.set_settings()
  File "/home/user/Git/nicotine-plus/pynicotine/gtkgui/dialogs/preferences.py", line 1810, in set_settings
    self.application.preferences.set_widgets_data(self.options)
  File "/home/user/Git/nicotine-plus/pynicotine/gtkgui/dialogs/preferences.py", line 2762, in set_widgets_data
    self.clear_widget(widget)
  File "/home/user/Git/nicotine-plus/pynicotine/gtkgui/dialogs/preferences.py", line 2787, in clear_widget
    elif isinstance(widget, Gtk.FontDialogButton):
  File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 32, in __getattr__
    return getattr(self._introspection_module, name)
  File "/usr/lib/python3/dist-packages/gi/module.py", line 123, in __getattr__
    raise AttributeError("%r object has no attribute %r" % (

See PR #2545 ... edit: fixed by 2239958

[slook]

DONE in Nicotine+ 3.3.0 - Migrate legacy setting ["ui"]["urgencyhint"] to ["notifications"]["notification_window_title"]

["ui"]["urgencyhint"] is not configurable from the Preferences dialog (it must be a removed setting?):

nicotine-plus/pynicotine/config.py

Line 404 in 51cc100

"urgencyhint": True,

The label for the user setting could be changed to "Show important notifications in the window title":

nicotine-plus/pynicotine/gtkgui/ui/settings/userinterface.ui

Lines 137 to 138 in 51cc100

	<object class="GtkCheckButton" id="notification_window_title_toggle">
	<property name="label" translatable="yes">Show notification for private chats and mentions in the window title</property>

We could trigger show_urgency_hint() from update_title() for any notification that is_important or high_priority. Doing so would add title bar urgency hints for Found wishlist results (to close #2551)

See #2567

[slook]

DONE in 3.3.0.dev5 -Remove old setting ["ui"]["tab_status_icons"]

Should be commented for moving into removed_options

[slook]

FIXED dev5 - Crash on Quit using Ctrl+C in linux terminal or close window button or Quit menu item:

^C[2023-07-27 00:46:26] Quitting Nicotine+ 3.3.0.dev5, application closing…
[2023-07-27 00:46:26] [Transfer] Aborting download, user "username", filename "path\file", token "None", status "User logged off"
[2023-07-27 00:46:26] [Transfer] Aborting download, user "username", filename "path\file", token "None", status "User logged off"
[2023-07-27 00:46:26] [Transfer] Aborting download, user "username", filename "path\file", token "None", status "User logged off"
...
Traceback (most recent call last):
  File "/home/user/Git/slook/nicotine-plus/pynicotine/pluginsystem.py", line 612, in disable_plugin
    self.update_completions(plugin)
  File "/home/user/Git/slook/nicotine-plus/pynicotine/pluginsystem.py", line 425, in update_completions
    core.chatrooms.update_completions()
  File "/home/user/Git/slook/nicotine-plus/pynicotine/chatrooms.py", line 464, in update_completions
    events.emit("room-completions", self.completions.copy())
  File "/home/user/Git/slook/nicotine-plus/pynicotine/events.py", line 226, in emit
    function(*args, **kwargs)
  File "/home/user/Git/slook/nicotine-plus/pynicotine/gtkgui/chatrooms.py", line 348, in update_completions
    tab.update_completions(completions)
  File "/home/user/Git/slook/nicotine-plus/pynicotine/gtkgui/chatrooms.py", line 1045, in update_completions
    room_users = core.chatrooms.joined_rooms[self.room]
KeyError: 'nicotine'

[2023-07-27 00:46:30] Quit Nicotine+ 3.3.0.dev5, done!
[2023-07-27 00:46:30] [Misc] Saved configuration: /home/user/.config/nicotine/config

No Critical Error dialog is shown, so the crash would not be known about unless running from the terminal.

The crash may occur whether or not the Chat Rooms tab was interacted with or not. Various room names appear in the KeyError traceback including 'Public ' or whichever room tab was active.

[mathiascode]

Does a4ac73c fix the issue?

[slook]

yes

[slook]

FIXED dev5 - Crash on Quit if custom icon theme is set to None

see #2629 (comment)

[mathiascode]

Fixed in 1c620c5

[mathiascode]

Review check_digit() method

It seems needlessly complex, and I'm not sure it works as intended. The TODO comment should also be taken care of.

nicotine-plus/pynicotine/gtkgui/search.py

Lines 1087 to 1136 in 48289eb

	def check_digit(self, result_filter, value, file_size=False):
	"""Check if any conditions in result_filter match value."""
	allowed = blocked = False
	for condition in result_filter:
	operation, digit = self._split_operator(condition)
	if file_size:
	digit, factor = factorize(digit)
	if digit is None:
	# Invalid Size unit
	continue
	# Exact match unlikely, approximate to within +/- 0.1 MiB (or 1 MiB if over 100 MiB)
	adjust = factor / 8 if factor > 1024 and digit < 104857600 else factor # TODO: GiB
	else:
	adjust = 0
	try:
	# Bitrate in Kb/s or Duration in seconds
	digit = int(digit)
	except ValueError:
	if ":" not in digit:
	# Invalid syntax
	continue
	try:
	# Duration: Convert string from HH:MM:SS or MM:SS into Seconds as integer
	digit = sum(x * int(t) for x, t in zip([1, 60, 3600], reversed(digit.split(":"))))
	except ValueError:
	# Invalid Duration unit
	continue
	if (digit - adjust) <= value <= (digit + adjust):
	if operation is operator.eq:
	return True
	if operation is operator.ne:
	return False
	if value and operation(value, digit) and not blocked:
	allowed = True
	continue
	blocked = True
	return False if blocked else allowed

[slook]

I agree, it would perhaps make sense to separate file_size, file_length and file_bitrate into separate discrete functions, rather than vaguely falling back on Exception to select the relevant chain of operations.

I'm not sure it works as intended

Why, what doesn't work?

However, if the functionality of the search result filters seems to be satisfactory at this time, I don't think any more development on the search filters should be undertaken until after 3.3.0 is released.

[slook]

Review on_change_password() method

It doesn't work as intended in all cases...

• If the username is altered in the Preferences dialog but not yet Applied, then it is possible for the password to be changed for the wrong account. Afterwards, it would appear the change didn't stick, but then the previous account was instead changed by mistake.

• The wording during offline edit is confusing between "change" and "enter". The intent of the dialog needs to be made clearer.

• On Invalid Password dialog prompt during firstrun after setup assistant, it is not helpful for the user to be dumped into the main Preferences dialog, because the new user doesn't necessarily know what to do next.

• If the user changes their username via Preferences, then the connection remains to the previous account until reconnect or restart.

• If the user changes their username via Preferences, then password for the prior account is wrongly acquired. Whereas, a prompt to choose a new password should be expected instead upon intent to create a new account, or login to a different one. The username entry could be greyed out to avoid this unless status is Offline. A tooltip over the greyed-out text entry would be appropriate to explain why the value is not editable whilst the status is Online.

• The passw is stored as plain-text within config, whereas it should ideally be the hashed against the user value which is locally stored in the file, or if not then an option to not remember it i.e. throw a prompt for entry upon every startup. Suggest consider implementing a migration to new encrypted password or pass key in config, that would use the hashed value same as is sent on the protocol.

nicotine-plus/pynicotine/gtkgui/dialogs/preferences.py

Lines 187 to 229 in 40eb00a

	def on_change_password_response(self, dialog, _response_id, user_status):
	password = dialog.get_entry_value()
	if user_status != core.user_status:
	MessageDialog(
	parent=self.application.preferences,
	title=_("Password Change Rejected"),
	message=("Since your login status changed, your password has not been changed. Please try again.")
	).show()
	return
	if not password:
	self.on_change_password()
	return
	if core.user_status == slskmessages.UserStatus.OFFLINE:
	config.sections["server"]["passw"] = password
	config.write_configuration()
	return
	core.request_change_password(password)
	def on_change_password(self, *_args):
	if core.user_status != slskmessages.UserStatus.OFFLINE:
	message = _("Enter a new password for your Soulseek account:")
	else:
	message = (_("You are currently logged out of the Soulseek network. If you want to change "
	"the password of an existing Soulseek account, you need to be logged into that account.")
	+ "\n\n"
	+ _("Enter password to use when logging in:"))
	EntryDialog(
	parent=self.application.preferences,
	title=_("Change Password"),
	message=message,
	visibility=False,
	action_button_label=_("_Change"),
	callback=self.on_change_password_response,
	callback_data=core.user_status
	).show()

Ideally. the password mechanism should be handled by the core application module, such that a prompt based dialog can be invoked from within the headless cli. Then, it would be possible for headless user to get on the network without having to first find and edit the config file.

The wording during offline edit is confusing between "change" and "enter". The intent of the dialog needs to be made clearer. Suggest:

slook@fe74af7

        if core.user_status != slskmessages.UserStatus.OFFLINE:
            action = _("_Change")
            title = _("Change Soulseek Password")
            message = _("Choose a new password for your Soulseek account:")
        else:
            action = _("_Enter")
            title = _("Enter Soulseek Password")
            message = (_("You are currently logged out of the Soulseek network. If you want to change "
                         "the password of an existing Soulseek account, you need to be logged into that account.")
                       + "\n\n"
                       + _("Enter the Soulseek account password for user %s:") % self.username_entry.get_text())  # config.sections["server"]["login"])

The preferences dialog should not own the methods, it needs refactoring into the core.

[mathiascode]

Is there anything that requires an urgent fix for 3.3.0? I won't do all of this for 3.3.0, but if something is obviously broken, we can look into it.

[slook]

It's not so bad anymore now that the duplicated stacked dialog issue is fixed.

My primary motivation was implementation of a headless prompt version of the Setup Assistant (i.e. asking for entry of login and passw config values), since need_config() is the only thing which prevents N+ from working out-of-the-box over SSH, or other low-resource runtime evironments like Termux, where X11/Wayland is unavailable.

anything that requires an urgent fix for 3.3.0?

It is not urgent, just unfortunate that implementing headless firstrun ability it is currently non-trivial because of the outdated placement of the aforementioned code. While for folks like us in the know it only a case of editing config with nano or such, but this would not be obvious to a new user.

if something is obviously broken

user@machine:~/Git/nicotine-plus/master$ ./nicotine --headless --config new
[10/18/23 15:47:28] Loading Python 3.9.2
[10/18/23 15:47:28] Loading Nicotine+ 3.3.0.dev6
[10/18/23 15:47:28] Translation files (.mo) are unavailable, using default English strings
[10/18/23 15:47:28] Loading plugin system
[10/18/23 15:47:28] Loaded plugin Nicotine+ Commands
[10/18/23 15:47:28] You need to specify a username and password before connecting…
_

It is obviously broken, because it appears to be prompt, yet it is not possible "to specify a username and password" from here ^.

It cannot be left the way it is. Either the message needs to be changed, or a dialog of input prompts need to be implemented.

[mathiascode]

Shouldn't be too hard to react to the "setup" and "invalid-password" events, and ask for a username and password using https://docs.python.org/3/library/getpass.html.

This can be done in headless/application.py.

[slook]

Yes, that was along the lines of what I had set out to do. Unfortunately I got distracted with reviewing the gtkgui module instead, so nothing got accomplished in what limited time I had to work on this.

---

DONE in 3.3.0.dev6: CLI: prompt for username and password when necessary (#2698) ...

These changes are enough to get you up and running in headless mode, but avoids adding commands for logging in as another user or changing your password.

We should add these eventually, but it will require more discussion and work to get them right. For now, I'm simply adding the bare minimum to get Nicotine+ 3.3.0 out the door.

[slook]

FIXED dev5 - Multiple modal dialogs created without the prior one being destroyed on Retry

They are invisible unless moved or cancelled. Only the most recent one is movable.

The Unavailable Shares dialog and the Invalid Password dialogs are both affected. 3.3.0.dev5 • Python 3.9.2 • GTK 3.24.24

[mathiascode]

I thought I had fixed this a few times already...

[mathiascode]

Should be fixed in 4d17387.

[slook]

RESOLVED dev5 - Cannot set Online status using the status bar button after being auto-away

For some reason pressing the status bar button widget flips the status to Online for a second, then it goes back to Away by itself. It's impossible to set Online.

The /away command works normally.

[mathiascode]

Does the button not work for you at all? The initial click after auto-away was enabled doesn't work, but after that it works as usual on my end.

[slook]

No it's completely broken no matter how many times or waiting for the auto-away to change it, when the problem only becomes reversed. The only way is by using keyboard shortcut or /away command, which works normally. I think it has to do with the state at which is set on startup.

[mathiascode]

I tried the GTK 3 version now, it's indeed broken there for some reason.

[slook]

Maybe it has something to do with an action signal event.

I suspect something is erroneously activated upon being enabled or suchlike.

[slook]

In #2681 I thought the problem was that the timer didn't get cancelled because away_timer_id was set to None too early such that the scheduled event couldn't be cancelled, but it turned out not to be that.

Another possibility is that the event timer triggers itself immediately upon init create.

---

Resolved in d345635

There's still the issue where the status initially reverts if you press the button while being auto-away, but it isn't as easy to solve.

[slook]

ADDED in 3.3.0.dev6 - Use monotonic time for certain timers

For repeated operations unrelated to the date and time of day, we should not be using the local time since the epoch as a start reference, see: https://docs.python.org/3/library/time.html?highlight=time#time.monotonic ...

time.monotonic()

Return the value (in fractional seconds) of a monotonic clock, i.e. a clock that cannot go backwards. The clock is not affected by system clock updates. The reference point of the returned value is undefined, so that only the difference between the results of two calls is valid.

In some current implementations of time.time() within the program, there might in theroey be a risk of bugs occuring when the clocks go forward or back due to daylight saving, when there is a leap year, etc, and whenever the machine clock gets synced by a remote NTP server.

[mathiascode]

Nice, good we're no longer stuck on Python 2. Should be a drop-in replacement for time.time(), which is convenient.

[slook]

Should be a drop-in replacement for time.time()

Not sure about that, remember that the reference point is undefined, so it might be needed to create individual timer objects for each implementation, since they can't be mixed because there is no shared epoch in a monotonic timer.

[mathiascode]

Python docs claim the following, though:

• "The function is now always available and always system-wide"
• "The reference point of the returned value is undefined, so that only the difference between the results of two calls is valid."

And we only care about the difference.

[slook]

But if it's system wide and called from multiple locations/methods/threads, then the difference will be all over the place.

I'd suggest using it for only the main networking thread, until we understand it better.

https://peps.python.org/pep-0418/#time-monotonic

Consider also time.process_time()

[mathiascode]

The only difference I see between time.time() and time.monotonic(), is that the latter keeps incrementing regardless of the system time, and its value (at least on Windows, number of seconds since the system started) is pointless for anything else than checking elapsed time between two points (which we do). We have no cross-thread comparisons that could screw things up.

If you spot any regressions since 265c6d8, let me know. I'll keep an eye on it.

time.process_time() stops during time.sleep(), so we shouldn't use it in this case.

[slook]

RESOLVED in Nicotine+ 3.3.0.dev6 - Default text entry background color chooser preview incorrect on dark theme preference

If the default option were displayed according to the color chooser preview then texts would be invisible, yet the actual setting works fine in the actual entry widgets everywhere. The color chooser preview should be dark grey or whatever, like the actual widget background is.

This is the only color chooser preview widget that is wrong.

GTK 3.24.24 on MX Linux 21.3 with "Adwaita-dark" or "Greybird-dark-mx" themes.

[mathiascode]

2a42396 is the best we can do.

[slook]

black should not be ticked for unset items..

[mathiascode]

We can work around that by enabling translucency in the color chooser, but then you have a useless translucency slider.

[slook]

Are there not any functions provided to get the default color of unset widget elements?

[mathiascode]

Not really. That wouldn't help much anyway, since you'd just have another color than black ticked by default.

I'll push the translucency workaround, it seems like the best approach so far.

[slook]

DONE in Nicotine+ 3.3.0.dev6 - delay download queue requests on startup until the compressed share messages are ready

This should fix any remaining "no files shared" false positives Nicotine+ users with large shares might be experiencing.

[mathiascode]

How do you feel about bumping the version to 3.3.0rc1 after this is implemented?

[slook]

There's no rush, I suggest leave it where it is until you're certain that the recent refactorings are finalized.

[mathiascode]

Could probably do it early December if I manage to fix #2745 until then. I'd prefer to release 3.3.0 before 2024.

[slook]

Testing of RC needs to be at least a few weeks, since there are big changes on this one. There isn't really any benefit to setting an arbitrary target date, and there is no harm in letting the repo go at its own pace, depending on what bugs get reported in the meantime.

Having said that, in principle I do feel your planned target seems realistic.

[mathiascode]

There isn't really any benefit to setting an arbitrary target date

It's good for me to at least try to set deadlines/target dates, otherwise I would happily delay releases indefinitely.

[slook]

FIXED regression only in 3.3.0.dev6 - <class 'socket.gaierror'> [Errno -2] Name or service not known

Crash on idle after on roaming machine internet was previously had been blocked by a firewall:

Nicotine+ Version: 3.3.0.dev6
GTK Version: 3.24.24
Python Version: 3.9.2 (linux)

Type: <class 'socket.gaierror'>
Value: [Errno -2] Name or service not known
Traceback:   File "/home/user/Git/nicotine-plus/master/pynicotine/gtkgui/application.py", line 614, in _raise_exception
    raise exc_value
  File "/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
    self.run()
  File "/home/user/Git/nicotine-plus/master/pynicotine/slskproto.py", line 2619, in run
    self._process_queue_messages()
  File "/home/user/Git/nicotine-plus/master/pynicotine/slskproto.py", line 2498, in _process_queue_messages
    process_func(msg_obj)
  File "/home/user/Git/nicotine-plus/master/pynicotine/slskproto.py", line 2257, in _process_internal_messages
    self._server_connect(msg_obj)
  File "/home/user/Git/nicotine-plus/master/pynicotine/slskproto.py", line 1197, in _server_connect
    self._init_server_conn(msg_obj)
  File "/home/user/Git/nicotine-plus/master/pynicotine/slskproto.py", line 1214, in _init_server_conn
    server_socket.connect_ex(msg_obj.addr)

[slook]

RESOLVED - Self user actions context menu Ignore/Ban menu items incorrectly ticked

The items are rightfully disabled for ourselves, but the four menu items appear as if they are checked although we have not ignored/banned ourselves...

[mathiascode]

• Which GTK version?
• Does this happen with other GTK themes?
• If you uncomment this line, do the items appear correctly? Is the state on the following line correct?

[slook]

• GTK 3.24.24
• No, the bug belongs to a specific theme, mx-comfort-dark
• Resolved.

Warning seen in console on context click menu show with buggy theme:

(org.nicotine_plus.Nicotine:8604): Gtk-WARNING **: 23:56:06.595: Negative content height -1 (allocation 1, extents 1x1) while allocating gadget (node separator, owner GtkSeparatorMenuItem)

[mathiascode]

I've confirmed it's an issue with the mx-comfort theme. Nothing we can do in Nicotine+.

[mathiascode]

I submitted a fix to the mx-comfort-themes repo: MX-Linux/mx-comfort-themes#5

[slook]

The fix was pushed to stable MX users the other day.

[slook]

RESOLVED - Unreadable widget background color in Chat History popover on mx-comfort-dark theme

The similes popover is also affected:

No doubt, it is a problem with this theme rather than an issue in N+. However, no other apps seem to be affected (with the possible exception of the current row line highlight in Gedit).

This is the default dark theme on:

• GTK 3.24.24 on MX21 "Wildflower" (Debian 11 bullseye)
• GTK 3.24.38 on MX23 "Libretto" (Debian 12 bookworm)

https://mxlinux.org/download-links/

[slook]

The Emoji picker in Gedit is the same problem:

When the window is inactive, the text becomes slightly less unreadable:

[mathiascode]

My guess is that there's a typo on this line: https://github.com/MX-Linux/mx-comfort-themes/blob/b8855ac3e70a8c5a86ab504bba9b6a9e6e709777/mx-comfort/gtk-3.0/dist/gtk.css#L4197

Changing 1.3 to 0.3 gives the following result:

I'm not sure if that's the original intention though. It would be best to open an issue and let someone maintaining the theme take care of it.

[slook]

I looks good to me. You might as well submit a PR with your proposed fix/workaround, since that would seem to help the dev at least identify where the problem is.

[mathiascode]

Fixed: MX-Linux/mx-comfort-themes#6

[slook]

The fix was pushed to stable users today in mx-comfort-themes 23.12.02 :)