Display external address

[OdinVex]

This adds an external address display label to the GUI and WebUI. Both work showing the last detected address. Systems with multiple addresses will need to be addressed at a later date. This will help an absolute ton of people using qBittorrent via Docker or with single-address setups.

It would be nice to keep track of IPv4 vs IPv6 and to show both. This is just to get it in there and it works.

This a re-submit for closed Pull Request #20096 (unable to re-open).

[OdinVex]

I'll adjust in time, I think this was older tinkering.

Edit: Hm, git clone built fine and ran fine, no adjustments. (cmake .; make)
Edit: Added override, must've forgot. This too compiles, should address the macOS fail. Could someone else peek at it, I shouldn't code so early.

[stalkerok]

Screenshots:
GUI:
WebUI:
Didn't find any problems. But it's still better to use "IP" instead of "Address" to save space, in case in the future someone (maybe you) wants to add a display of both ipv4 and ipv6 address at the same time, or even all possible addresses. Or any other information. IMHO

[OdinVex]

Didn't find any problems. But it's still better to use "IP" instead of "Address" to save space, in case in the future someone (maybe you) wants to add a display of both ipv4 and ipv6 address at the same time, or even all possible addresses. Or any other information.

I mentioned in the original PR that you (the general you, as in qBittorrent team/developers/whoever it may concern) can decide what language to use. When I see IP I see Internet Protocol, not Address, but I've been developing since 2004 in areas that include developing protocols and it just looks weird to my mind seeing "External Internet Protocol" when I'd need to refer to an address. Again though, I don't care which way it goes in your (general your) project, anyone pick. I'm running around on 28" 4K high-DPI setups, so I don't have space to worry about. *shrug* Personally I'd rather the backend kept track of the last externally-detected addresses via type so it could end up "External Address(es): IPv4, IPv6*" where an asterisk denotes which was detected most recently, somewhat adapting and opportunistic in displaying more, maybe even a popup menu showing a small 'mini-exec' log of addresses detected with timestamp (or enabling the View for the log and simply preset the filter to detected IPs...easiest and most 'integrated' in my opinion, less UI to manage or clutter and easily implemented).

Edit: I might take some time later today to implement separate IPv4/IPv6 addressing and displaying both using 'Addresses' (or only one if only one exists and using 'Address' or whatever the project ends up deciding).

Edit: Cleanly refactoring to support both IP address types is problematic because other functions rely on not making a difference between them, such as isReannounceWhenAddressChangedEnabled (see handleExternalIPAlert for more info). I haven't had any time to grasp the code, would that function matter or care about which type or is it safe to just go ahead and let it through regardless of IP address because it's still an externally detected change?

[OdinVex]

I've implemented it all but I've come across a formatting situation. Do you want a space between IPv4 and IPv6 addresses or a comma and space or what? Edit: Went with a single space. Tested GUI and WebUI, currently working on my end.

[stalkerok]

comma and space

would be a good option.

[OdinVex]

comma and space

would be a good option.

I didn't see the message until after commit, my bad. Comma and space would require keeping track of whether both are being shown or just one and adjusting so, was easier to use trim at the time.

[stalkerok]

maybe even a popup menu showing a small 'mini-exec' log of addresses detected with timestamp

A small information window when hovering over an address with all available IP addresses would be a good option (the same as when hovering over "connection status", for example).

[OdinVex]

maybe even a popup menu showing a small 'mini-exec' log of addresses detected with timestamp

A small information window when hovering over an address with all available IP addresses would be a good option (the same as when hovering over "connection status", for example).

qBittorrent currently doesn't keep track of addresses, merely the last detected of each type. The backend would need some further tinkering to do that. I don't do enough web development with JavaScript (I personally despite JS) to add a popup, but I can look at it. Edit: Perhaps that popup should just show the log filtered for detected IP Addresses?

[stalkerok]

Perhaps that popup should just show the log filtered for detected IP Addresses?

Perhaps I just don't really understand how good or bad it would look.

[OdinVex]

Perhaps that popup should just show the log filtered for detected IP Addresses?

Perhaps I just don't really understand how good or bad it would look.

Edit: I haven't pushed it yet but I've refactored the code to show (and send for WebUI) both IPv4 addresses and IPv6 addresses such as 'External Address(es): Detecting' -> 'External Address: 0.0.0.0' -> 'External Address: f:f:f:f' ->'External Addresses: 0.0.0.0, f:f:f:f'. The addresses past detected are available for someone to write a popup (or something) if desired. All strings allow for translation, of course. I wonder, should we mark the last detected one via asterisk in cases with multiple addresses? (Ex: 'External Addresses: 0.0.0.0, f:f:f:f*') It might be helpful for someone and is easily done.

Edit: Instead of a popup, I'd say just call the View->Log.onclick, call the Execution Log->onclick, set the filterTextInput text to 'Detected external IP.' and set 'Information Messages' to ticked in the drop-down. It'd show IP as well as when they were last used, less UI to develop. That'd work for the GUI and WebUI, too.

[OdinVex]

I decided to reuse elements of the UI. The label at the bottom was converted into a button similar to setting download/uploads speeds. When it's clicked it'll open up the Execution Log and add Information Messages to the filter list to show messages as appropriate. The GUI doesn't currently have a text input means of filtering the log, but at least they'll be shown (Informational type). The WebUI is pre-set with the translatable text and works as well. Try it out, see if it needs tweaking. If you want to call things 'Internet Protocol(s)' instead of addresses be my guest.

Edit: I felt this approach to reuse and reinforce use of the Execution Log as a means of information conveyance was best. It beats adding more UI that would need maintenance and simply works. Every user-facing string is translatable via TR and QBT_TR, I paid attention to make sure I used that 7 strings total including the transitory-state strings.

[OdinVex]

Except one string, forgot that one, added. 😅

[glassez]

How about changing "Detecting" to "N/A"?
Not all users have such large monitors as you, and among those who do, not all have the desire to stretch the qBittorrent window to the full screen and shake their heads left and right to view it.

[glassez]

Of course, the IP address will still be longer. But in any case, all we can say about this is that the information about external address is currently "not available". IMO, "Detecting" looks speculative.

[OdinVex]

I don't know how that would differentiate between "Not available...yet" and other states such as failed, but I do agree about 'Detecting' sounding speculative. Perhaps more information should be communicated to the frontend from the means that qBittorrent uses to detect. "Detecting/Detection failed" etc? As for how much space is used...at this rate it's looking like you want just external addresses printed and nothing else which, quite frankly, leaves me baffled as to what the information would be.

[OdinVex]

Then again, some people use torrent clients on closed networks (so local IP address(es)), so maybe it can make sense.

[glassez]

If you want to call things 'Internet Protocol(s)' instead of addresses be my guest.

We don't want to call things 'Internet Protocol(s)' instead of addresses. We do want to write IP as a shortcut of IP address. I can't figure out what the problem is. A similar thing (called "metonymy") is used everywhere (just look around, it's strange that you haven't come across it). We say "IP" instead of "IP address", "E-mail" instead of "E-mail address" whenever the context allows us to do it unambiguously.

[glassez]

When it's clicked it'll open up the Execution Log and add Information Messages to the filter list to show messages as appropriate.

Is it a really good idea to do it this way?
Firstly, it is doubtful to implicitly enable something that was previously explicitly disabled by the user.
Secondly, the log can be filled with a lot of messages, so it obviously won't seem intuitive to the user to see it.

[glassez]

Personally, I would limit myself (at least to begin with) to something minimalistic like Deluge does. Just IP: 123.456.7.8 or maybe IPv4: 123.456.7.8 | IPv6: 2001:0DB8:3C4D:7777:0260:3EFF:FE15:9501. Details can be shown in tooltip. Or, if it is really necessary to see more details/statistics, we can later add "External address info" dialog that is displayed when you click on appropriate button on status bar.

[stalkerok]

or maybe IPv4: 123.456.7.8 | IPv6: 2001:0DB8:3C4D:7777:0260:3EFF:FE15:9501

I don't think that's a good idea, a , separator like that would save some space.
IP: 123.456.7.8, 2001:0DB8:3C4D:7777:0260:3EFF:FE15:9501
and
IPv4: 123.456.7.8 | IPv6: 2001:0DB8:3C4D:7777:0260:3EFF:FE15:9501

Details can be shown in tooltip.

👍

[glassez]

or maybe IPv4: 123.456.7.8 | IPv6: 2001:0DB8:3C4D:7777:0260:3EFF:FE15:9501

I don't think that's a good idea, a , separator like that would save some space. IP: 123.456.7.8, 2001:0DB8:3C4D:7777:0260:3EFF:FE15:9501 and IPv4: 123.456.7.8 | IPv6: 2001:0DB8:3C4D:7777:0260:3EFF:FE15:9501

To clarify. I meant two separate items of status bar.
Personally I would keep only addresses w/o IP etc. That would be enough. If not, then someone could look (once) at the details in the tooltip.

[OdinVex]

We don't want to call things 'Internet Protocol(s)' instead of addresses. We do want to write IP as a shortcut of IP address. I can't figure out what the problem is. A similar thing (called "metonymy") is used everywhere (just look around, it's strange that you haven't come across it). We say "IP" instead of "IP address", "E-mail" instead of "E-mail address" whenever the context allows us to do it unambiguously.

I say e-mail address and IP address. *shrug*

Is it a really good idea to do it this way? Firstly, it is doubtful to implicitly enable something that was previously explicitly disabled by the user. Secondly, the log can be filled with a lot of messages, so it obviously won't seem intuitive to the user to see it.
...
Personally, I would limit myself (at least to begin with) to something minimalistic like Deluge does. Just IP: 123.456.7.8 or maybe IPv4: 123.456.7.8 | IPv6: 2001:0DB8:3C4D:7777:0260:3EFF:FE15:9501. Details can be shown in tooltip. Or, if it is really necessary to see more details/statistics, we can later add "External address info" dialog that is displayed when you click on appropriate button on status bar.

That's what showing the Execution Log was to do. It simply re-used the pre-existing UI and filters to just the relevant messages (WebUI can filter by text which makes it much more useful, GUI can only filter by message type and is less useful).

Not sure if this is known, but this doesn't have to be perfect to get such a useful feature implemented. It doesn't harm anything except at most screen-space. On a side note, I disable the Search and RSS but they re-enable themselves and are useless to me. If they intentionally click on the addresses then they intentionally want more information, I don't see any harm in showing the Execution Log tab when they specifically asked for information/details. Fancy conveyance was 'immediately' irrelevant development to simply getting the functionality out there.

[OdinVex]

Herpderp unstale.

[github-actions]

This PR is stale because it has been 60 days with no activity. This PR will be automatically closed within 7 days if there is no further activity.

[OdinVex]

Herpderp unstale.

[bacon-cheeseburger]

I use -nox/cli + webui only and would like this feature. I couldn't care less about debating the labeling and whether an extra single character is wasting space (", " vs " | "). If that's a concern, this is 2024 and people know what ipv4 and ipv6 addresses look like. "x.x.x.x" and "x:x:x:x:x:x:x:x" is more than suitable. If someone doesn't know what those are, they wouldn't be looking for it in the first place. Don't over-think it.

Anyways, is this PR in current form the one to use? If not, where should I be looking? Thanks.

[OdinVex]

this is 2024 and people know what ipv4 and ipv6 addresses look like
If someone doesn't know what those are, they wouldn't be looking for it in the first place. Don't over-think it.

Not everyone knows what IP addresses are, even. Just because they don't know what something is doesn't mean they won't see it. It's not over-thinking, it's preventing software from becoming dumb as fuck like Windows became. This PR is just here for whoever wants a head start on maintaining their own patches. I simply use a ViolentMonkey script to do exactly what I wanted and it works well for all of us regardless of this entire thread+PR. If people want it they can use it or tweak it however they like.

Edit: The space-saving bit I didn't care about either considering the purpose of it all but one person appeared to be bothered by the space an IPv6 address might take up on screens too tiny to be usable... I think they're confused about the entire UI needing to use CSS to style things appropriate for DPI-related issues such as tiny screens or 4K monitors+ by using a singular root base font size and relative (em, etc) changes and SVGs so everything renders correctly at any size and designed for the screen size, and so-on.

[bacon-cheeseburger]

this is 2024 and people know what ipv4 and ipv6 addresses look like
If someone doesn't know what those are, they wouldn't be looking for it in the first place. Don't over-think it.

Not everyone knows what IP addresses are, even. Just because they don't know what something is doesn't mean they won't see it. It's not over-thinking, it's preventing software from becoming dumb as fuck like Windows became. This PR is just here for whoever wants a head start on maintaining their own patches. I simply use a ViolentMonkey script to do exactly what I wanted and it works well for all of us regardless of this entire thread+PR. If people want it they can use it or tweak it however they like.

I don't believe the average GenX-GenZ person, which makes up probably 99.9% of the qbittorrent user base, doesn't know what an ip is. If they don't, seeing "x.x.x.x" vs. "ipv4 x.x.x.x" isn't going to change anything for them. We can agree to disagree, no prob.

I do believe providing the external ip to the user can be useful be it via internally in qbittorrent (preferable imo) or the ViolentMonkey script you mentioned.

[glassez]

Not everyone knows what IP addresses are, even. Just because they don't know what something is doesn't mean they won't see it. It's not over-thinking, it's preventing software from becoming dumb as fuck like Windows became.

It's not very clear what exactly you mean.

If I see, for example, 93.184.216.34 in status bar, and I know that this is an IP, then I don't need any labels (especially something too detailed, like IP Address instead of a short IP). The only thing I might be interested in is what kind of IP address is displayed here (i.e. an external address in this case). But this is the kind of information that is required only once upon first time you use the application (and only provided that you have not dealt with other similar applications), so it is not only wasteful, but also pointless to occupy a workplace with it, it is enough that it is displayed in the tooltip (along with other external addresses, if there are several of them).
If someone does not know what an IP address is, then a constantly visible label will not help them either.

[OdinVex]

I don't believe the average GenX-GenZ person, which makes up probably 99.9% of the qbittorrent user base, doesn't know what an ip is. If they don't, seeing "x.x.x.x" vs. "ipv4 x.x.x.x" isn't going to change anything for them. We can agree to disagree, no prob.

If someone does not know what an IP address is, then a constantly visible label will not help them either.

I won't assume 99.9% are but I would lend they would most likely make up the majority, uncontested. Usually seeing unfamiliar terms leads intelligent people to query their definition and a quick query of 'IPv4/v6' might be enough for people to get the gist of what they are.

If someone does not know what an IP address is, then a constantly visible label will not help them either.

I don't know how many torrenters know what DHT is but it's labeled and there. I looked into what DHT was when I saw it. People might take a moment to learn, might not.

It's not very clear what exactly you mean.

It may not be clear to you but it's clear to a few people without GitHub accounts that I develop with that use qB, I keep them abreast of this thread in particular because they wanted this feature and just use my ViolentMonkey script meanwhile. Some have been around since the early phreaking days, though myself a little after. We've noticed the mass dumbing down of software hiding away information or control, usually in the name of making things better...and the horrible side-effect (hopefully not intention) of people not being able to gleam or understand the underlying workings of things. Over "helpfulness". It ends up with people on forums asking derp-simple questions or reinventing software and scripts to bring back control or functionality.

especially something too detailed, like IP Address instead of a short IP)

This was already discussed. IP does not mean IP address, it means Internet Protocol. Short-hand has led to people saying 'IP' but it's still incorrect, but I specifically mentioned I didn't care if qB changed the strings.

But this is the kind of information that is required only once upon first time you use the application

I'd like to offer the thought: that would be an assumption for some. I'd like to know if my ISP went down even for a few seconds and issued a DOCSIS devreset rebooting all modems and giving me a different IP...or to know if my VPN is still functional, let alone if my private IP leaked due for any reason. I'm not the only one that specifically feels this way, a quick search engine (Bing, Google, fill in) about kill-switching qB outgoing connections due to a VPN loss and such reveals a lot of people wish they could monitor the external address of the qB host. My ViolentMonkey script specifically changes an icon to flash a critical one while alerting to any address changes.

In the end, I don't think it hurts to let people know the external address(es) detected and I know of some obvious helpfulness of it. The RSS tab is 100% useless to me but I'm not fussing about screen space or the fact I had to keep turning it off every session until my ViolentMonkey script. The fact the execution log isn't shown by default bugs me but I turned it on with my ViolentMonkey as well. Others using it liked it this way too.

Edit: Entire point is for this to be helpful to those that might need it.
Edit: I'd also like to again point out Deluge has had it for years and it's been requested for qB a number of times as well. Seems it's all quibbling about how to display or communicate it in the status bar. IPv6 addresses being as long as they are with screen space being an issue with screens that can't even display the UI to begin with has thrown a wrench into it by bringing up the 'px' implementation of measuring rather than relative sizes to easily layout the UI but eh...feature or none, the other script users are happy and not one has complained of anything so far.

[glassez]

But this is the kind of information that is required only once upon first time you use the application

@OdinVex
You took that phrase out of context and wrote a lot of unrelated information underneath it in response.

[OdinVex]

@OdinVex You took that phrase out of context and wrote a lot of unrelated information underneath it in response.

If I see, for example, 93.184.216.34 in status bar, and I know that this is an IP, then I don't need any labels (especially something too detailed, like IP Address instead of a short IP). The only thing I might be interested in is what kind of IP address is displayed here (i.e. an external address in this case). But this is the kind of information that is required only once upon first time you use the application (and only provided that you have not dealt with other similar applications), so it is not only wasteful, but also pointless to occupy a workplace with it, it is enough that it is displayed in the tooltip (along with other external addresses, if there are several of them). If someone does not know what an IP address is, then a constantly visible label will not help them either.

I don't think I did at all. It was all related. Edit: To clarify in case it wasn't obvious, I may want to see that information at any time, that was the whole point of the reply by showing scenarios very practical and real versus your "only required once upon first time" posit.

[glassez]

To clarify in case it wasn't obvious, I may want to see that information at any time, that was the whole point of the reply by showing scenarios very practical and real versus your "only required once upon first time" posit.

OK, please explain what you mean by "that information".

"only required once upon first time"

This phrase in the context of my comment means a label near the displayed IP address value.
I was saying that you don't need to see External IP Address: 93.184.216.34 in the status bar all the time, but 93.184.216.34 is enough. A description of what kind of IP address is displayed there can be placed in the corresponding tooltip.

[OdinVex]

OK, please explain what you mean by "that information".

The externally detected IP addresses. ...? That was the entire purpose of the initial filing and the initial PR and then this PR?

This phrase in the context of my comment means a label near the displayed IP address value.
I was saying that you don't need to see External IP Address: 93.184.216.34 in the status bar all the time, but 93.184.216.34 is enough. A description of what kind of IP address is displayed there can be placed in the corresponding tooltip.

That isn't what was said but I understand what you're saying in this reply. This was already resolved though, I mentioned that the qB project can do whatever they want with the strings. If you want it to say "Hamburgers:" go head, or nothing at all, fine, I don't care what qB does with it. I've only ever pointed out that it's weird and unintuitive UI development to just display an address with no context (eg., "External IPv4/IPv6 detected:" (or whatever the case may be)). I've never cared what qB does with it, I simply wanted to lay the ground work since no one had done it. People can edit their translations file(s) to correct/adjust/prefer whatever they want.

I'd like to note a feature idea as well. The option to use an interface's IP address(es) over remotely fetched addresses. It's purely to eliminate traffic and reliance upon a third party for users that know they'll only ever have public addresses and such.

[OdinVex]

@hackerz-hub Some of my script users have rotating VPNs too, yeah. This was part of their desire to see the externally-detected addresses. I think the only thing mostly being argued here is how to convey the information.

[OdinVex]

@hackerz-hub, An image of what?

[xavier2k6]

@OdinVex I suggest you rebase & take care of current conflicts which need to be resolved, this will also allow others to use CI builds for testing purposes.

[OdinVex]

But this is the kind of information that is required only once upon first time you use the application (and only provided that you have not dealt with other similar applications), so it is not only wasteful, but also pointless to occupy a workplace with it

OK, please explain what you mean by "that information".

I just read this entire knowledge thread, I dont know if it is just me, But it looks like the admin @glassez is perhaps completely unaware (based on the replies!) of why this feature (this feature = displaying like 93.184.216.34) is a needed one in the status bar.

Unless the admin gets a full understanding of the need for this feature - he/she might not want to merge this into qB and hence this lack of understanding becomes a reason for forks and dilution.

Perhaps other admins (@Chocobo1, @FranciscoPombal, @jagannatharjun, @ngosang, @Piccirello, @sledgehammer999, @xavier2k6 ) should try to understand the need for this feature

or may be, @OdinVex - Can you please try to create a PR with a detailed summary for helping the admins to understand this PR ? - Because there is too much discussion around cosmetics rather than getting in the fundamental ground work

The cosmetics is the only issue here.

@hackerz-hub, An image of what?

@OdinVex - A Docker image of qBittorrent with your proposed modification of showing the IP address in the status bar of Web UI

I thought I embedded a screenshot in the first PR. Maybe I forgot.

@OdinVex I suggest you rebase & take care of current conflicts which need to be resolved, this will also allow others to use CI builds for testing purposes.

I mentioned through this PR that I'm not doing anything anymore, I only bump it to keep it alive for anyone else who wants to deal with disagreements around cosmetics.

[OdinVex]

@hackerz-hub, An image of what?

@OdinVex - A Docker image of qBittorrent with your proposed modification of showing the IP address in the status bar of Web UI

I thought I embedded a screenshot in the first PR. Maybe I forgot.

I am surprised you didn't know what is a Docker image and instead attached a png image ! Can you let me know how you tested your original implementation in WebUI?

I know what a Docker image is. You asked for an image but never specified of what (I knew you were talking about a Docker image, but it made no sense to ask for the only thing I have: a ViolentMonkey Script). The images I instead gave were of the implementation in the WebUI, that's why I posted it. It's relevant to the only issue relating to this PR: Cosmetics. Keep up bud.

[stalkerok]

Time to force close this PR, maybe someone from the team will have the desire to implement this later. Or make changes and finalize this PR.

[OdinVex]

Time to force close this PR, maybe someone from the team will have the desire to implement this later. Or make changes and finalize this PR.

They have no desire, despite there periodically being new Issues asking for it. It's been in Deluge for years, qBittorrent developers didn't seem to give a fuck when I read all the Issues asking for it. "Lay the groundwork" was what it ended up being. I did but the developers don't like it. I told them they could change whatever but all they did was rehash. Oh well, that's all there is to it.

[skomerko]

Hey @Piccirello, could you look into it maybe? I read through this thread and it looks like remaining problems are mostly cosmetics. It would help a ton of people. I don't have much experience and at most could bring parts to make it work in the WebUI but I guess not everybody would be satisfied :P