refactor/move_gui_from_core

[JarbasAl]

move the gui logic from core to here, this allows gui to have a different release cycle and core to pin older versions

this will also allow us to define an exact version where we migrate from qt5 to qt6

needs a companion PR in core to import from here for backwards compat

benefits:

• no imports from core
• can introduce breaking changes faster than core adopts them (core pins version)
• different release cycle, core will likely have periods with several releases without this getting any PR, the reverse may also be true
• start of removing backwards compat, now properly named ovos-gui-service, mycroft-gui-service is an alias of core for compat and can be dropped in 0.1.0 as roadmaped
• in many senses its like PHAL being extracted from mycroft.client.enclosure
• still a requirement of ovos-core, its like skill class moving from core to workshop
• allows for richer plugin integration, it can be a dependency of plugins and we can easily make extensions plugin based too

[AIIX]

Why is GUI being moved out of core ? It has no different release cycles and API does not depend on Qt5 vs Qt6 changes either, the protocol api has no changes between the versions either.

A user installing OVOS core is going to expect the GUI to work out of the box, making it a separate package will just cause more confusion for users installing OVOS core. Even if this is being thrown out of core for no valid reason, it is then at least should become a requirement to be included in the very minimal dependencies for core not depending on the [ALL] egg, this totally breaks packaging, this meta package was not even a requirement until now.

[JarbasAl]

this PR is WIP and needs other PRs in core, it will make more sense later

benefits:

• no imports from core
• can introduce breaking changes faster than core adopts them (core pins version)
• different release cycle, core will likely have periods with several releases without this getting any PR, the reverse may also be true
• start of removing backwards compat, now properly named ovos-gui-service, mycroft-gui-service is an alias of core for compat and can be dropped in 0.1.0 as roadmaped
• in many senses its like PHAL being extracted from mycroft.client.enclosure
• still a requirement of ovos-core, its like skill class moving from core to workshop
• allows for richer plugin integration, it can be a dependency of plugins and we can easily make extensions plugin based too

[JarbasAl]

note that this module was already naturally independent, it was developed under core but doesn't need any features from core now that things like config loading are independent of mycroft being importable

[AIIX]

I only will agree to this change if it becomes part of the minimal dependency of core which means git installing ovos-core even without an egg will continue to install the GUI service by default, if a platform decides to use it or not like any other systemd service is up to the image/platform and the user, this otherwise needs none of the above benefits to continue fully functioning, because it is very much dependent on core, and the protocol is not changing between any versions.

[AIIX]

The only things that would have made sense to move would have been the extensions, not the whole protocol implementation.

[JarbasAl]

gui will still be part of core, but not minimal requirements, not even workshop or speech client deps are in there why would gui? gui already needs ovos-core[gui] anyways to ensure tornado is available

it will be added to gui requirements, full requirements, and skill requirements. but a minimal install means no GUI (like it means no speech or audio!)

all old imports from core for gui stuff will continue to work as before, this is making the code easier to maintain not removing it

[JarbasAl]

side note, this also means @AIIX you will be the main maintainer of this repo, basically every PR coming to this repo will need to be approved by you

[JarbasAl]

@AIIX this is a bug fix, i added the else clause because the line after would throw error about msg_type and msg_data not being defined, unrelated to the PR just something pycharm flagged, but wanted to bring your attention to it