Closed ChristianGalla closed 6 years ago
What I was hoping to do also, was to include the PID of the running exe into the AppID so that it was possible to run multiple copies of Pidgin, each with their own taskbar icon
What is your use case to run multiple copies of Pidgin? Isn't the purpose of Pidgin to run only one client to use multiple message services?
If you want to use multiple versions of Pidgin with different version numbers (for example stable and development), you can encode this in the app id. According to Microsoft's documentation the app id should be in the format "CompanyName.ProductName.SubProduct.VersionInformation".
The only issue I am seeing is that on every update the shortcuts in the taskbar must be updated as well, because the shortcut contains the app id, too. I think most users are only using one instance of Pidgin at once, so this would decrease the usability on updates...
One copy of pidgin for my work accounts, and one for my personal accounts - the personal ones as a Portable install on a flash drive
Is there an easy way for a plugin to determine if it is running in a portable or installed version of Pidgin? Do you think that multiple portable copies need to be supported? Maybe it is enough to include the type of Pidgin in the app id?
Something like "Pidgin.Pidgin" and "Pidgin.PidginPortable"?
I am against including the PID in the AppID because it changes when the program is restarted.
Therefore, if you pin a shortcut to the taskbar while running a program with PID X and restart the program with PID Y, the shortcut will not be grouped together with the windows of the running program.
See https://github.com/ChristianGalla/PidginWinToastNotifications/issues/4
Unfortunately, I have not tested if this change works because I am unable to compile the plugin. I am getting redefinition errors and undefined references. I think this is because the plugin redefines some win32 api functions that are available in newer versions of mingw and calls other functions that mingw does not provide.
I think you once mentioned that you patched some mingw libraries? How about switching to dynamic linking and load the windows dlls at runtime, so the plugin can be compiled even if mingw's libraries are outdated or incomplete?