Having subsurface-core as a directory name really messes with
autocomplete and is obviously redundant. Simmilarly, qt-mobile caused an
autocomplete conflict and also was inconsistent with the desktop-widget
name for the directory containing the "other" UI.
And while cleaning up the resulting change in the path name for include
files, I decided to clean up those even more to make them consistent
overall.
This could have been handled in more commits, but since this requires a
make clean before the build, it seemed more sensible to do it all in one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way warning icons and tank change icons and other event markers are no
longer ridiculously tiny on retina screens. Oddly this doesn't appear to be
needed on Android, only on iOS.
Fixes#1033
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is turning into the never ending story. The documentation is not helpful,
so this is the result of a ton of trial and error - and I worry that the next
device I try this on will once again break things.
I think the scaling may finally be correct. Take the viewport rectangles
of the profile and the painter, create their ratio, multiply in the device
pixel ratio and the scene size with a little margin added around it.
But the other magic (especially the shifting of the profile on the
painter) makes absolutely no sense to me.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Normally this is triggered when the DiveDetailsView component is
completed, but since QML isn't recreating this component unless we switch
to a dive a couple of spots in the dive list away from this one, we
wouldn't get any changes in the data reflected in the profile.
But since this now redraws the same dive that potentially was drawn last,
we need to make sure we call plotDive() with force=true.
I also suspect that this could help with the strange bug that sometimes we
show a blank profile after certain edits.
See #1013
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This one appears to work in my testing so far. And reading the code it
seems to make sense. We look at the size that the widget thinks it is. And
we scale the scene to fill that size (including a margin). And then let Qt
and QML deal with the rest of it. Assuming this works it shows that we
have been trying too hard all this time.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Different approach here:
- profile gets a bit higher, this was requested on the mailinglist, and
seems to behave much better with the painted profile, we'd otherwise
get it magically clipped on the right hand side.
- Make the scaling dpi aware, this fixes scaling for me on the Nexus7, I
haven't been able to test it properly on other devices, so this needs
some more testing. The result is visually quite close to what we can
do, although I'm still getting a somewhat larger margin on the right.
To get at the devicePixelRatio without too much custom code, I've
added a property to the QMLProfile to retrieve it from the theme engine.
Signed-off-by: Sebastian Kügler <sebas@kde.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The QMLProfile height is specified as ~2/3 (actually 0.66) width in
DiveDetailsView.qml. In order to produce an even margin around the profile,
the scaling factor reduction for height needs to be 3/2 times that for width.
MarginFactor is specified as 0.013 to approximate the margin calculated by
commits ef653b4 and 7e2898d for my Galaxy S6.
MarginFactor = margin / width
= 18 / 1365
= 0.132
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Scale the QML profile in two stages. Firstly, scale to fit. Secondly, scale
again to 95% to create a margin around the profile.
The previous method scales to fit a create a margin in one step. It appears
more elegant, and the margin is calculated more rationally. Unfortunately on
some devices, including mine, the resulting profile is cropped for no obvious
reason.
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We don't need any of the interactive features. Additionally this allows us to
easily ask for slightly smaller fonts.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This still doesn't address all the issues, but appears to be a step
forward. It also contains some debug output to better understand what's
going on.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The scaling needs to happen before we draw the profile on the viewport, not
before we render that viewport into the pixmap. This is why prior to this patch
the first time the profile was rendered it was way off, but then if it got
re-rendered things worked better. I'm still not 100% happy with the size and
position of the profile, but this is a huge improvement.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The asynchronous nature of the profile bites us here. plotDive() signals
that it changes model data and expects the rest of the data structures to
respond to that. Very neat and it seems to work perfectly well on the
desktop, but on Android calling render() right after plotDive() resulted
in paint() functions being called before all the elements had been
calculated as a result of the signals being emitted in the model change.
That's why so often the profile was missing parts.
Now admittedly this makes me nervous. Do we now know that all calculations
have finished by the time render() gets called? Not really. It just seems
that in my testing we tend to get lucky and things work out. But that does
not feel like a sane architecture to me.
Messing around with the animation speed is silly as we render the profile
into a pixmap, so let's turn this off globally.
Also, the scaling of the pixmap is still completely bogus.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- paint() can become a hot path, especially when we think about
repainting the item on size changes. In general, it's a really good
idea to keep this function as fast as possible, as we want to be able to
repaint the item when needed. Also, ProfileWidget is pretty heavy to
set up, so rather spend a bit of memory there.
- Rename profile to m_profileWidget, it already was member var.
- Sizing ... I have to admit I don't understand the rendering of the
ProfileWidget. I'd like it to do the following things:
- render at native resolution, we don't want to resize it
- react to item changes - we want to reset the size and
re-render the widget into the item in those cases
- perhaps be able to use a couple more of the profilewidget's
features
Signed-off-by: Sebastian Kügler <sebas@kde.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This resizes the dive profile to always maintain an equal width and
height, so that the sizing is the same in all devices.
Signed-off-by: Grace Karanja <gracie.karanja89@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a better way for showing the profile. The show() and hide()
statements are replaced by a QTransform statement.
Signed-off-by: Grace Karanja <gracie.karanja89@gmail.com>
Add a C++ class to render the dive profile. The rendered image is then
passed on to QML.
Signed-off-by: Grace Karanja <gracie.karanja89@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
