Gnome-shell-extension-gsconnect: GSConnect and winTile not compatible

[sk0gen]

Problem with winTile extension.

Steps To Reproduce:

1. Go to winTileExtension
2. Click on install
3. Error message: screenshots.

Expected behavior
Extension just works properly.

Screenshots

]
Error after installation of winTile.
]

System Details (please complete the following information):

• GSConnect version: [37]
  
  
  
  • Installed from: [GNOME Extensions Website]
  
  
• GNOME/Shell version: [3.36]
• Distro/Release: [Manjaro 19.02]

Support Log
Not able to generate.

Additional Notes
winTile works fine

[andyholmes]

This is a bug in winTile. Looks like someone's been borrowing my code :wink:

window.gsconnect = {
    extdatadir: imports.misc.extensionUtils.getCurrentExtension().path,
    shell_version: parseInt(Config.PACKAGE_VERSION.split('.')[1], 10)
};
imports.searchPath.unshift(gsconnect.extdatadir);

cc @Fmstrat

[ferdnyc]

This is a bug in winTile. Looks like someone's been borrowing my code

True, though it wasn't actually @Fmstrat, whose commit just adjusted some whitespace. The window.gsconnect block was added by @dan-g an impressive _thirteen months_ ago, in this commit: https://github.com/Fmstrat/wintile/commit/4488d9e97a6b761851f80928ab885f992121c2e0

(Which I guess makes it even more impressive that it's only just been noticed and/or caused a problem _now_.)

[Fmstrat]

Well that's... interesting. I've never actually used GSConnect, and I started WinTile from some sample code in a tutorial. Whoever wrote that tutorial must have been a GSConnect fan 😉. I never thought twice about the naming convention. In any event, thanks for cross-filing the issue. I'll clean that up this week.

[ferdnyc]

(50/50 shot that this is right about the point where @andyholmes realizes that _he_ wrote a tutorial like that, and accidentally left a gsconnect identifier in the example code.) :wink:

On a slightly-related, but hopefully amusing, tangent, I recall that I once discovered there were/are literally _hundreds_ of releases in the Discogs database ­— a crowdsourced index of commercial music releases in all their forms, sort of an IMDb for audio recordings — that were all identified by the exact same "Matrix Number" identifier, despite the fact that it's theoretically supposed to be useful as a unique identifier for each release.

Why were there so many dupes? Because Matrix Numbers are typically presented in barcode form. The mass-duplicated number was _the sample/default identifier_ that libbarcode would produce for that barcode format, if you had it generate a code without any input!

I never did figure out if it was a matter of people _misusing_ the library and not realizing they were printing a sample barcode, or if they knew full well that they had to feed it data to get a non-generic code but just couldn't be arsed.