- Pervasive change to automatically connect to known board types
- Lots of additional changes along with this:
- More exposure of objects/properties to Qml
- Much restructuring in LinkManager and LinkManager clients

- Pervasive change to automatically connect to known board types
- Lots of additional changes along with this:
- More exposure of objects/properties to Qml
- Much restructuring in LinkManager and LinkManager clients

- Pervasive change to automatically connect to known board types
- Lots of additional changes along with this:
- More exposure of objects/properties to Qml
- Much restructuring in LinkManager and LinkManager clients

Instead us a Toolbox concept which hangs off of QGCApplication

When you selected via the Menu to go to Fly Mode, the QML
toolbar didn't followed the option, and if you selected
via the menu to go to all the three possible views (setup,
fly and plan) the menu would be all-selected.

This tries to keep consistency of things.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

Too used to Kernel Formatting Style.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

The dock widget opening system had several issues,
1 - it didn't deal with translations
2 - it didn't deal with accelerator keys
3 - it crashed if passed a invalid string (like when using KDE, happened
for all options)

This new way of using the views are slightly different:
1 - no more string comparissons, use integer comparissons (much faster)
2 - do not use a convoluted if/else - switch simplify.
3 - do not create two different static variable strings for the same stuff
4 - create an enum / an vector of strings (the enums bein an index of it)
to acess the correct view.

The overall code is clear than the old one, and faster.
the only point where the code isn't as clear is on the call to
showDockWidgetAction, since we passed a string that had the
name of the Widget, but now the action only holds the index
for the name in the string vector, I first need to get the
correct string and send it.

Tested here closing and reopening the app and verifying that
the dock widgets that where left open are still open when
reopening the application.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

The text can be translated, the text can have accelerator-special
key, so the text is unrealiable. the only thing reliable is the data,
wich stores a pointer to a fixed , unmutable, string.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

We where passing the QActions untranslated.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

Since the Static const char * items are private and nothing
should access them besides the MainWindow class, declare
them inside of the .cpp file with static linkage, this way
a few good things happen: they are not exported as symbols
to any other class (not even with private linkage) and also
if we need to add a new one, on the .cpp, the only compiled
file will be the cpp, instead of the tons of files that include
mainwindow.h
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

If you choosed View->Fullscreen, the app would go to fullscreen,
but if you then go again to View->Fullscreen, the app would still
be fullscreen but the menu item would be unselected - leaving
UI and settings inconsistent.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

qobject_cast doesn't use RTTI to figure out the type, it uses
an internally stored relationship, wich is much faster than
RTTI. I grepped the code for dynamic_cast and there are lots
besides this one, so I'll later try to figure out wich ones
are QObject inheritances and change acordingly.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

The QString behaves faster if used with const - reference on
a QForeach.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

if an unknown string was passed to createInnerDockidget,
the widget would not be created but a reference to the null
pointer would still be saved on the avaliable dock widgets,
and thus any code that foreached the list accessing methods
could led to a crash.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>

Since it's just a state-toogler, use the return value of the
method to set the values directly.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>