Add linux support

[berarma]

Requires s-victor/pyRfactor2SharedMemory#1

This PR fixes basic issues to allow TinyPedal to run on Linux.

It mostly works, pending issues are:

• Background transparency of widgets doesn't work.
• Widget decorations appearing after disabling/enabling widgets from the menu.
• Locking widgets doesn't work.
• Detection of an already running instance doesn't work.
• Settings file should be written to the default user configurations directory.
• Update the README with Linux specific instructions.

The widget decorations issue could be fixed by hiding widget windows instead of destroying them. For that I'd refactorize some code first so that the generic handling of the widget is in one place: showing/hiding/updating. It could be useful for the other widget related issues too.

[s-victor]

Hi, I have just tested code and all is good on windows side, a little changes needed for the pyRfactor2SharedMemory PR, and once done I can merge your changes.

---

Also on the widget decorations issue and possible solutions that you have mentioned. By changing widget windows from destroying to hiding (for toggle-able) however would causing a few other issues:

• Currently switching preset in preset manager requires to destroy all widget windows and recreate them with new settings loaded. Making widgets hiding would break preset loading functionality.
• Not destroying Widget when they are not required would result more resources(ram, cpu, etc) consumed, which is not efficient.

As for the setting file location, I understand that on unix there is standard dafault user folder for storing user setting file (and other related file). But on windows the usual habits is having them inside APP folder for better portable abilities. Maybe a good idea to have user files saved in standard user folder for unix system only, and keep how it is currently work under windows.

[s-victor]

A little more about decoration issue: overrideredirect controls whether window frame appears. From the manual here and as well as a bit search results, it seems for X11 a wm_ prefix maybe required. It would look like following after changes: self.wm_resizable(False, False) self.wm_overrideredirect(True) (also for wm_attributes, etc) I have tested and this prefix works on windows, so if they also work on linux, then no extra code needed.

[berarma]

I've tried the wm_ prefixed functions and they seem to do exactly the same.

My idea is to never update widgets that are hidden. It's pretty common in UIs to work this way, hiding windows instead of destroying them since it's more work to allocate/deallocate resources than changing the window state. Keeping a window open and hidden that doesn't require any code running would take only a few kilobytes of memory on Linux and no CPU.

I'm thinking it could be useful to have an auto-hide feature that make widgets visible only when they're needed without performance issues. Just an idea, not something that I'm pursuing.

Anyway, the refactorization would allow to use different methods on Windows and Linux more easily. That way widgets could still be destroyed/created on Windows while they're hidden on Linux. Effectively using the best method for each system.

Loading a preset could still destroy and create the widgets on Windows. Although loading of presets would be almost immediate if it could be done without recreating the widgets.

I'm always thinking on doing what's best for each platform.

[s-victor]

Thanks for testing feedback, I understand you points.

There is scenery where some users may only use a few widgets, and in this case those unused widgets will never be created in the first place, hence no extra resource usage. But those are minor concerns, adding extra hiding check should not be an issue.

However, main issue is that, in order to reload config setting for widget (and background stuff such as realtime module also need reload), there are large amount GUI element config needs to be re-draw. And some of widgets' feature are only initialized during initial creation time, which if not recreating, would need to have them always be available or add more additional codes. So while it may be possible to add code to support reloading on fly, it would significantly complicate the whole thing.

If the decoration can't work probably after destroying and recreating, then I think maybe we should try find and fix why this is happening as that is the root issue.

In the meantime, I'll try install a linux in virtualbox and hopefully to do some testing there and see how the issue is like.

Thanks again, I'll merge this PR now, and then add your name to contributor list, and if you'd like to also write some linux info in README as you mentioned earlier that would be great. Lemme know for more progress or update.