To phase out this global variable, avoid access of displayed_dive
in the printing code. This is used when printing a plan. Instead,
when in plan-mode, pass the planned dive to the printing code
as a single dive to be printed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Rendering resets the size, which now recalculates the axes.
Therefore, plotDive() must be called. The callers were doing
the opposite: call plotDive() first, then draw().
To make it easier for the callers, present a single interface
that handles these subtleties.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The printFontScale is used to scale up fonts (and icons) when
rendering to high-DPI devices. With absolute scaling, this
will also be used to scale the size of different chart
regions, line thickness, etc. Therefore, give it an more
appropriate name. "Device pixel ratio", which is a well
established term, seems to appropriately describe the
concept.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of using the interactive ProfileWidget2, just
use the ProfileScene to render the profile for printing,
export and mobile. One layer (QWidget) less.
This removes all the kludges for handling DPR on mobile.
Thus, the rendering will now be off and have to be fixed
by redoing the scaling code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Since using separate profile-instances for print/export,
we never exit print mode. Therefore, the mode parameter
can be removed. This is a preparatory commit for passing
the printMode at construction time.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Not having to readjust the scale on-demand will make the
code distinctly simpler. Let's just pass it once.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Very annoyingly, to render the profile for printing / export,
the profile still had to be show()n, thus requiring a parent
window.
Analysis of qmlprofile.c showed that this was due to the
transformation matrix not being properly set up on non-show()n
scenes.
Instead, we can simply render via the QGraphicsScene
(circumventing the QGraphicsView).
The code was factored out into the ProfileWidget2::draw()
function. This will hopefully make it easier to change
the size-code of the profile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When printing the dives were rendered into the visible profile.
This meant setting a number of flags and reverting after printing.
That's obviously quite brittle.
Instead, use a separate profile instance, since we can have
different profiles showing different dives now.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This variable is not used outside a single function, where it
is reset every time the function runs. This can be realized by
a function-local variable just as well.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When printing, the animation speed was set to 0 by the
caller and later reset to the original value. Instead of
modifying global state, set it internally (in the profile-code)
to zero when in print mode.
This is another small step in making the printing independent
from the shown profile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
So far the profile operated on the global displayed_dive. Instead,
take the dive to be displayed as a parameter to the plotDive()
functions.
This is necessary if we want to have multiple concurrent
profile objects. Think for example for printing or for mobile
where multiple dive objects are active at the same time.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The font-size in printed profiles is based on the size of the profile
in the main window. This makes no sense. Why should changing the
window size change the font-size on printouts?
Matter of fact, when making shrinking the height of the window to
its minimum, comical printouts are obtained (font way too big).
Therefore use an arbitrary rule: Say that profiles 600 pixels high
look reasonable and then scale up to the actual size on the printout.
This may need some tweaking for high-DPI mode. But that seems not
to be supported on desktop anyway?
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The TemplateLayout prints different dives depending on
whether the planner is active. Instead of accessing a
global variable, pass the status down from the MainWindow.
That's all quite convoluted, since there are multiple
layers involved.
On the positive side, the in_planner() function has now
no users an can be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In TemplateLayout, there was a progress indication, which reported
the progress - not of the actual rendering - but of adding the
dives to the "to render" list. Which is of course done in less than
a ms, making the whole thing completely pointless.
Instead, emit progress when actually looping over the dives or
statistics.
Nobody ever noticed the problem because even rendering is done in
fractions of a second and indeed is accounted to only one fifth
of the total progress.
The real purpose of this "fix" is to get rid of the getTotalWork()
function, which was just insane. Instead of asking the TemplateLayout
how many dives it rendered, this number was extracted from
global state. Simply store the number of dives in the TemplateLayout
object instead.
Moreover, fix two coding style issues:
- "Page" variable identifier starting with a capital
- The Printer::render() being defined (as opposed to declared) with
a default parameter. This is not how C++'s default parameters work,
sorry.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
QPointer is a strange "smart" pointer class, which resets itself
when the pointed-to QObject is deleted. It does this by listening
to the corresponding signal and therefore is surprisingly heavy
for a plain pointer. A cynic would say that the existence of
QPointer is an expression of Qt's broken ownership model.
In any case, QPointer was only used at two places, were it was
100% useless: As a parameter to a function and as a locally scoped
pointer. It only makes sense if
a) there is a chance that the object disappears during the pointer's
lifetime and
b) it is actually checked for null before use
None of which was the case here. Remove.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
These two structs describe options used during printing.
They are passed through numerous classes as pointer. In this
case, reference semantics are preferred, as references:
- can never be null
- can not change during their lifetime
This not only helps the compiler, as it can optimize away null
checks, but also your fellow coder. Moreover, it prevents
unintentional creation of uninitialized references: one can't
create an instance of a class without initializing a reference
member. It does not prevent references from going dangling.
However, pointers have the same disadvantage.
Contains a few whitespace cleanups.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
ProfileWidget2::plotDive() had this weird interface, where passing
in NULL as dive would mean "show current_dive". However, most callers
would already pass in current_dive. Therefore, unify and always pass
in current_dive if the caller wants to draw the current dive.
This allows us to interpret NULL as "show empty profile". Thus,
passing in current_dive when there is no current_dive simply shows
an empty profile. This makes the calling code in
MainWindow::selectionChanged() simpler.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This way we can view the html generated from a print template, for
debugging, validation or printing via your favorite browser.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
See https://www.kdab.com/goodbye-q_foreach/
This is reduced to the places where the container is const or can be made const
without the need to always introduce an extra variable. Sadly qAsConst (Qt 5.7)
and std::as_const (C++17) are not available in all supported setups.
Also do some minor cleanups along the way.
Signed-off-by: Rolf Eike Beer <eike@sf-mail.de>
Printing never worked, none of this was ever included in test builds. Also, now
that there are official releases of QtWebKit again, this just doesn't seem worth
carrying along anymore.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The keeps track of different sub widgets needed by other parts
of the code, notably:
MainTab
PlannerDetails
PlannerSettingsWidget
ProfileWidget2
DivePlannerWidget
DiveListView
Access to these widgets was provided with accessor functions.
Now these functions were very weird: instead of simply returning
pointers that were stored in the class, they accessed a data
structure which describes the different application states.
But this data structure was "duck-typed", so there was an
implicit agreement at which position the pointers to the
widgets were put inside. The widgets were then down-cast by
the accessor functions. This might make sense if the individual
widgets could for some reason be replaced by other widgets
[dynamic plugins?], but even then it would be strange, as one
would expect to get a pointer to some base class.
Therefore, directly store the properly typed pointers to the
widgets and simply remove the accessor functions. Why bother?
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add class variable tooltip_position to qPrefDisplay
Add class variable lastDir to qPrefDisplay
qPrefDisplay is updated to use new qPrefPrivate functions
Adjust test cases incl. qml tests
qPrefAnimations only has 1 variable, that really is a display variable
Merge the variable into qPrefDisplay, to simplify setup (and avoid loading
extra page in qml).
correct theme to save in correct place, and make it a static
class variable
Signed-off-by: Jan Iversen <jani@apache.org>
remove use of SettingsObjectWrapper::
remove include of SettingsObjectWrapper.h
use qPrefFoo:: for setters and getters
replace prefs.foo with qPrefXYZ::foo() where feasible
(this expands to the same code, but gives us more control
over the variable).
Signed-off-by: Jan Iversen <jani@apache.org>
helpers.h included qthelper.h and all functions declared in helpers.h
were defined in qthelper.h. Therefore fold the former into the latter,
since the split seems completely arbitrary.
While doing so, change the return-type of get_dc_nichname from
"const QString" to "QString".
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In MainWindow::current_dive_changed() first plotDive() is called,
which replots all the pictures by calling plotPictures(). This
is pointess, because it plots the pictures of the previous dive.
Then, updateDiveInfo() is called, which resets the dive pictures
and automatically replots them. Thus, switching between dives
both with hundreds of pictures is way slower than necessary.
Switching the plotDive() and updateDiveInfo() calls doesn't work.
The reason is not 100% clear, but it doesn't make sense to plot
pictures of the new dive as long as the profile still shows the
old dive anyway.
As a quick-fix, add a flag to plotDive(), which tells the function
to clear the pictures list instead of redrawing it.
Ultimately, plotDive() should probably be split in two functions.
One for the callers who update the pictures themselves and one
for the others.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Wfloat-conversion enabled for C++ part of the code
Fix warnings raised by the flag using lrint
Original issue reported on the mailing list:
The ascent/descent rates are sometimes not what is expected.
E.g. setting the ascent rate to 10m/min results in an actual
ascent rate of 9m/min.
This is due to truncating the ascent rate preference,
then effectively rounding up the time to reach each stop to 2s intervals.
The result being that setting the ascent rate to 10m/min
results in 20s to ascend 3m (9m/min), when it should be exactly 18s.
Reported-by: John Smith <noseygit@hotmail.com>
Reported-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Jeremie Guichard <djebrest@gmail.com>
Going to "Template -> Edit" now has a field to enter the
border width (in pixels as only that makes sense in CSS as a flexible
unit, TMK).
This field modifies the template_options.borderwidth Grantlee
property which is part of the bundled templates already
and allows the users to modify the borders of tables.
The C++ implementation was missing, while the HTML (template)
implementation was already in place. Overlooked during GSoC.
Reported-by: Willem Ferguson <willemferguson@zoology.up.ac.za>
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This removes all references to WebKit if cmake option USE_WEBKIT is enabled.
For the user manual it changes it to WebEngine (seems to work for me).
Similar for the Facebook connection (minus a reference to a cookie jar).
This I could not test at the moment, as I wrote this on a train.
Printing does not work, it is a null operation at the moment. Currently,
large parts of of the printing code are commented out as there is no direct
way to access page elements in WebEngine. It seems this needs to be done
via Javascript (with a callback invoked). There is new functionality in
WebEngine to render a view to a PDF file but this needs more work (and
probably some thoughts towards page breaks).
Signed-off-by: Robert C. Helling <helling@atdotde.de>
As expected, commit 7be962bfc2 ("Move subsurface-core to core and qt-mobile
to mobile-widgets") caused some breakage.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The reason for that is, even if profile widget is made with qpainter
and for that reason it should be a desktop widget, it's being used
on the mobile version because of a lack of QML plotting library that
is fast and reliable.
We discovered that it was faster just to encapsulate our Profile in
a QML class and call it directly.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since we have now destkop and mobile versions, 'qt-ui' was a very
poor name choice for a folder that contains only destkop-enabled
widgets.
Also, move the graphicsview-common.h/cpp to subsurface-core because
it doesn't depend on qgraphicsview, it merely implements all the
colors that we use throughout Subsurface, and we will use colors on both
desktop and mobile versions
Same thing applies for metrics.h/cpp
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
