Decouple data from widgets and config driven screen builder

[e100]

This is related to #91

I wanted to see what it would take to decouple the the FIX code from the widgets like you mentioned. Then I got carried away and built a screen builder that allows you to place instruments on the screen purely with configuration files.

The configuration in this pull request has two sixpack screens, the screenbuilder one ( default ) and if you press back you will get the original. This was done to also prove that the changes made to the widgets allow them to work with the old way of making screens and with the screen builder way. So far all the gauges used in sixpack have been updated to work with screenbuilder, still have work to do on many other gauges.

Within the screen builder it handles the data events more efficiently too. Each data item only has a single signal and the screenbuilder then calls the update functions of the widgets that use that data item. Longer term I want to move the data up yet another layer so we only have one signal for each data item and only update the items on the active screen that use that piece of data.

If you will be willing to merge this and like the direction I will keep working on this. If you have some suggestions or things I should change let me know.

[birkelbach]

I have been out of town for the last week so I have not had much of a chance to look at all of this. I like what you are doing at a cursory glance but give me a couple of days to take a closer look.

[e100]

I've made more progress on this, expect to see me pushing more changes later today

[e100]

@birkelbach

With the changes I just pushed here, if you do not have an 1920x1080 monitor edit the config before running anything. I think you will like how well the screenbuilder screens scale when resolutions are changed.

[e100]

@birkelbach

So as I've been learning QT and python I've come to the conclusion that trying to make the widgets not tied directly to the fix data just greatly complicates things and has little benefit.

At first glance it seems inefficient that each widget gets data from FIX individually. But if each widget does not get the data, even when not shown, then when switching to that screen it will be displaying the wrong data until a value changes. I've ran across this bug more than once where isVisible() was used to not re-render but was used in a way that the data was also not saved in that widget. When changing to the screen with that widget it would show the wrong data if the data had changed while that widget was not visible.

With that I think I'll start over with this and focus mostly on making a screen where one can place widgets using only the yaml configuration. I think making it easier for one to setup their screens would go a long way to making this an easier to use application.

[birkelbach]

I will leave this PR alone until you tell me that you are ready.

[e100]

I'm going to close this one, this was a path down the wrong road. Just sent another pull with just config driven screens