Jorge,
Thank you for the, as always, detailed and informative reply.
And for the laughs as well

Still haven't had time to get into Windows, but managed to D/L the beta this time. Must have been some sort of fluke that it failed previously.

Couple of things I keep forgetting, since 26.1. First, I start Xtreme after connecting to my VPN. When I do, NextStart loads up just about instantly, but then there's an interval of what feels like about 15+ secs. before Workshelf starts loading.

Second, Proton VPN includes a facility that blocks trackers, and various malware and ads. When Xtreme is up and running, I get a fair lot of ttrackers being blocked, and so I'm wondering whether your server - or perhaps your host? - sends out trackers? I feel it seems unlikely Jorge, but I thought I'd ask.

Hmmm... it only started happening after v26.1? Could be because of the Jumplist initialization, it can be time consuming although it is performed in the background.

Does the same delay happen if you start Xtreme BEFORE connecting to the VPN?



The application itself doesn't track anything, and I am not aware of any trackers (other than Google Analytics on the website itself).

To know what is happening we would need a list of the URLs/trackers that Proton is blocking. Since the weather module, for instance, connects to MSN, and the clock to Internet time servers, it might be related to something like that?

Yes, only since 26.1.

I couldn't say as nothing starts before the VPN is connected. Windows starts with a KillSwitch that doesn't allow any incoming or outgoing connections until a VPN connection is established. It's the safest way to run things without the ISP - or anyone else - getting any data of what connections are made. But I doubt the delay could in any way be related to the VPN as nothing changed there between the previous Xtreme version and 26.1.

Yeah, didn't think the app used any trackers Jorge.

in the normal run of things, don't have the Weather mod running. Only one I could think of that connects to an external service would be the Moon one, which I'm never without. But a single mod like that couldn't possibly account for a whole bunch of trackers.

As Proton doesn't do any logging, there wouldn't be any logs of the URLs/trackers - just a numerical count.

Maybe it's something completely unrelated and mere coincidence that it happens after 26.1 and once Xtreme is running...?

You don't use Jumplists, right? Unfortunately turning that off still doesn't prevent the initial collection of file extensions and associated applications that happens right at startup, which is a bit of an oversight on my part - that is the only major thing that changed at startup, IMO.

I'll fix that on the next beta and then we can know for certain.

However, that retrieval is done in the background, in such a way that startup should not interrupted - just take longer or have a few initial "hiccups".



Nah, the moon does not need the Internet (except to get the initial latitude/longitude coordinates for your location via GeoIP)

By the way, the Moon Calendar "time lapse" animation now updates the calendar past the current month. How is the transition from month to month on your system (each time the month displayed changes the application needs to calculate and draw all the moons that appear in the calendar, which is why I previously did not update the calendar past the current month in the time lapse animation).



Not familiar with Proton, but ChatGPT suggested to use Fiddler or Wireshark: These tools will show you the exact URL that is being "Refused" or "Dropped." You might find it’s a specific API URL that NetShield has mistakenly put on a tracker list.



What does Proton consider a "tracker" and why?

Isn't that version of Xtreme a brand new installation? Could also be the application trying to notify the Winstep server of the registration. I do what could be called a "reverse activation" (i.e. trust, but verify).

If the notification is blocked, the Winstep application will keep trying. Either way, the idea of that is not to track the user, just to make sure he is legit.

Ok, I now skip initial jumplist initialization if jumplists are turned off.

However, after looking at the code again I don't think the startup delay you describe is because of this. When jumplist initialization finally happens the docks, etc, are already being shown on the screen.

If that's not happening there, it must be something else... could be a shortcut pointing to a non-local hard disk, for instance.

Correct, don't use jumplists, ever.

It's odd though that only Workshelf should be delayed - shouldn't NextStart also be affected if it was due to the Jumplists data collection, no?

It's possible it can't do that as all geolocation is blocked in Windows?

Might use the "time lapse" anim maybe once a year or so, so I'll have to check when I get back to Windows. Certainly has always seemed very smooth.

I'll give that a go but doubt there would be any result. NetShield doesn't keep a tracker list - it checks in real time whether a tracker is present.

Only any kind of file/cookie designed to track any kind of new connection being initiated, as I understand it.

No, transferred the installation - inc. Windows Reg'y. keys - from the other laptop, and anyway all issues apply to both systems.

Yeah, I know about your "reverse activation", Jorge, and Winstep is about the only software allowed to make or receive connections - I know you wouldn't mess that way.

Should be able to get into Windows during the coming week.

@Jorge

Looking forward to testing the new GUI theme editor
That's all. Will check in from time to time.

As you were, I do not want to interrupt the more important functional aspects Jorge.

You might actually have to wait a bit longer than the next release...

Heck, I'm sure nobody could reasonably expect to see anything until well after the next release Jorge. It is, after all, a pretty big task.

Added the ability to assign hotkeys to Grid Stacks, Sub-Docks and Launch Pads.

Grid Stacks and Sub-Docks invoked via an hotkey will pop up wherever the mouse cursor currently is. Press the hotkey again and the dock or grid stack closes.

Activating a hotkey associated to a Launch Pad will, as expected, launch all the items in it.

As part of a "quality of life" addition also currently working on adding a sort of "Hotkey Manager", possibly to the Troubleshooting Options dialog. The Hotkey Manager will allow you to see at a glance which what hotkeys are assigned to what and where, if there are any conflicts, as well as allow you to delete or edit active hotkeys.

A Hotkey Manager is a great idea. But isn't it in danger of getting "lost"/ignored in the troubleshooting options? How about adding it to the context menus for Hotkeys, e.g.?

Eh? What context menu for hotkeys?

I've been struggling with where to put that option too, but it seems to me that the Troubleshooting dialog is where it belongs best?

The idea of the Hotkey Manager (perhaps it should be renamed to Hotkey Troubleshooter then?) is not to assign hotkeys (you can't even do it from there), but more to help users - and me, if they write to support about it - figure out mistakes they might have made when assigning hotkeys (e.g. conflicting hotkeys), what assignments they currently have and where, or even why something unexpected happens when they press a specific key combination (e.g. they configured a hotkey long ago and then completely forgot about it).

Oops, sorry, my mind was elsewhere, on hotspots.

Yes, I guess in the end the Troubleshooting dialogue does seem the only sensible option, and definitely best term would be Hotkey Troubleshooter.