Managed GUI access

[Mathias Brodala]

The current mess of any piece of code accessing GUI controls in various ways desperately needs to be cleaned up.

Thus we are in need of a proper API of some kind. On suggestion would be to add some kind of GUI/Control manager which lets any piece of code in Exaile’s codebase register named GUI objects which should then be accessed only using this manager.

It should also be considered to make use of the existing providers framework for this. How exactly this could work out needs to be checked and verified.

Pseudo code:

GUIMANAGER.register_object('main/playlist_notebook', self.playlist_notebook)
# …
GUIMANAGER.get_object('main/playlist_notebook').get_n_pages()

[reacocard (reacocard)]

Not a bad idea, though we'll want to take care to keep this as ui-neutral as possible (ie. no gtk-isms). I'd also still like to have some form of non-ui-toolkit-specific api for things like menus and settings (and simple dialogs? progress indicators?) that generally don't need custom widgets.

[Mathias Brodala (mathbr)]

It should also be considered to introduce signals/events wherever possible. This way the non-UI code can do its work and the GUI can react to that. So we effectively turn around the way of action.

[reacocard (reacocard)]

lp:~exaile-devel/exaile/playlistmodel is bringing basic provider-based menus with it, which while not completely toolkit-independent are a step in the right direction. I think we shouldn't be overly concerned with trying to make it able to work cleanly outside of GTK, and instead should concentrate on making it as simple as possible to adjust the current UI. We can revisit making toolkit-independent frameworks if and when development on a non-GTK frontend actually starts.

[Mathias Brodala (mathbr)]

As for the pseudo code: this is exactly how it could look like using our providers framework. Controls could be registered for a service named "controls" or the like and be accessed anywhere without reaching deep into the GUI code.

Some sort of base class should always be used for each control to ensure that there’s at least something users of these providers can rely on. (That’s what interfaces would be good for but we don’t have that luxury in Python.)