There was code to create a fake dc in the profile widget in
the case that there are no samples. To my understanding, this
is obsolete, as such fake data is now generated automatically
when adding dives.
If for some reason there really are no samples, quit early
and go into the empty state.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Adds fields to the advanced preferences page to modify GFLow and GFHigh for
the Buhlmann decompression model for calculating ceilings. Updated preferences
code to set the Buhlmann parameters in core/deco.c when the GF prefs are
updated.
Signed-off-by: Doug Junkins <douglas.junkins@gmail.com>
This now actually displays the calculated ceiling in the profile. There is
still an issue where if the user toggles the setting the already cached profiles
aren't recalculated - that's part of a bigger profile cleanup effort.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The profile had a static variable which prevented animation
when first showing the profile. It appears more logical to
don't show the animation when switching from the empty state.
This removes global state, as a function static variable
exists only once, even if there are multiple objects.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The DiveHandler shows a context menu where a cylinder can be
chosen. This indirectly accesses the global displayed_dive
variable.
Remove this in a step to make the profile reentrant.
The code was quite ominous: instead of simply generating the
list of cylinders, a global model was reset and then accessed
with Qt's cumbersome model/view API. All this trampling over
global state can be removed by simply making the function
that generates the list globally accessible.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of accessing the global displayed_dive variable
in RulerItem, pass the dive. This is a step in making the
profile reentrant.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of accessing the global displayed_dive variable,
pass the dive to the various profile items. This is a
step in making the profile code reentrant.
This removes the last user of the displayed_dc macro,
which can now be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Don't access the global displayed_dive variable in an effort
to make the profile reentrant.
Note that this still accesses the global dc_number variable,
which will likely have to be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The profile item that shows the ceilings adds a warning event
if the ceiling is violated. This is very unfortunate.
Improve this situation by adding the event up to the function
that calculates the ceiling. This is still not how it should
be - the display layer should not modify the dive that it
displays.
To make this clear, add a comment that details that this
is a contract between planner and display layer: The planner
uses a dive that can be trampled upon by the profile.
Still, this should be solved differently.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The in_planner() function is incompatible with a reentrant
profile, since it accesses a global variable. In
create_plot_info_new() it is essentially redundant, because
there is a planner_ds (ds = deco_state) parameter that
is used only when in the planner. Therefore use that as
the in_planner indicator: when non-null, the profile is
showing a planned dive.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was used to force a replot on preferences changes.
However, the profile now does a replot in such a case
by itself. This can be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
With the same argument as for DivePercentageItem, move access
to live data out of the paint() function. Instead, calculate
colors in replot(), where the other data are calculated.
This is slightly more complicated than in DivePercentageItem,
since there are multiple polygons. Therefore, replace QPolygonF
by a vector of structures contained the position and color
of the data point.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The DivePercentageItem is a polygon-item with a custom paint()
method. Calculation of the polygon is done once in replot(),
but calculation of the corresponding colors is done in every
paint() call. The problem is, we have no control over paint().
It is called whenever Qt feels like. Therefore using live
dive data is a dangerous proposition if we ever want to get
rid of the global displayed_dive.
Do all the calculations in replot(). Store the colors in an
additional array of the same size as the polygon.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The only time the TankItem is replot is when new data is set.
Therefore, replot() can be folded into setData().
The good thing is that setData() is passed the dive to be
plot. So the data can be extracted from there instead of
the global displayed_dive variable.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The code tried to only replot the profile if necessary, notably
when in edit mode or the ceilings are shown.
That seems like pointless premature optimization, which only
complicates things: The profile is replot every time a
"dive handle" is moved, which means that we depend on the
replotting being reasonably fast. Why should it then not
be redrawn if the settings change?
Let's remove this, as it makes control flow easier to reason
about.
This makes the isPlotZoomed member variable redundant. Remove it.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The old mechanism to replot the profile items was to listen
to model-change signals. Then the code checked whether it
actually had to update anything by looking at the changed
model-indices.
However, the crucial replot was always initialized with
emitDataChanged(), which simple invalidated the full model
and therefore shouldCalculateStuff() always returned true.
Since now the replot() is called explicitly, remove the whole
logic and simply rename modelDataChanged() to replot().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of listening to the dive-data-model changed and
axis changed signals, update the profile items explicitly
once per plot() call. This avoids double replotting of the
dive items.
The old code had at least two replots per plot() call:
one after profileYAxis()->setMaximum() and one after
dataModel->emitDataChanged().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
On each profile replot, the gas axis was implicitly reset
by calling "dataModel->emitDataChanged()", which would send
a signal recieved by the axis. To make the code less confusing
and, more importantly, make order of execution deterministic,
explicitly reset the axis.
Rename the function that resets the axis from "settingsChanged"
to "update" to reflect its usage.
Moreover, remove the "setModel()" function and pass the model
to the constructore. Make it a const reference to make clear
that it can't change during the life time of the axis.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This virtual function is not used as the target of a signal
anywhere, which means that it shouldn't be a slot.
Moreover, mark the one place it is overriden as override.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In contrast to most other items, which are cleared in the
setEmptyState() function, the profile items are cleared
indirectly via a signal from the model. Very hard to follow
and indeed, I thought I could just remove the slot.
Do this explicitly instead for deterministic code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When the settings change, the depth axis is redrawn
to reflect metric/imperial units. To check whether the
units changed, the old length unit is saved in a static
variable. This makes no sense and allows for only one
depth axis. Make this a normal member variable that is
initialized in the constructor.
Also remove the settingsChanged() call in the constructor,
since this is a no-op (the depth unit is unchanged).
Contains a whitespace fix.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There is no point in a separate set-axis function if we never
change the axis anyway. Make the axis a const-reference to
show that it can never be changed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Since the initial commit introducing TankItem, there was
a connection that replotted the item if the horizontal axis
sent the sizeChanged() signal. I never managed to create
this signal for the horizontal axis, only for the vertical
axes. Therefore remove this thing. If it turns out that
we need it after all, readd it in a more deterministic
way (i.e. call where it is needed).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This one is extremely obscure: TankItem::setData(), which is
called on every replot, was passed the DivePlotDataModel,
even though it doesn't access that model at all.
Instead, it connect()s to the model to stay informed of changes
to the data. First of all, this should obviously be done
once in the constructor, not on every replot.
But also, the setData() function is called on every replot
one lines before sending the model-changed signal.
Thus, the tankitem was always repainted twice.
Just remove the whole connect() thing and go for a more
deterministic model. Should the tankbar not be repainted
anywhere, add the appropriate calls there.
Accordingly rename the "modelDataChanged" slot to "replot".
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
settingsChanged() is a virtual function, which is called
when the preferences dialog signals changes. In most derived
classes, the function does nothing.
In two classes, DiveProfileItem and DiveCalculatedTissue, it
replots the item respectively changes its visibility.
However, these two flags are *not* controlled by the preferences
dialog. Indeed, the functions are also connected to finer-grained
qPref signals. Therefore, settingsChanged() can be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Collect all the created profile items in a dynamic vector.
This allows us to loop over them when adding them to the
scene, instead of addressing each item individually.
Hopefully, this will also allow for a more deterministic
repaint logic, without relying on signals.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The only thing left that this function did, was setting the Z-value
of the item. This can be done directly on construction.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This function was called after creating the items. It can be
called directly to create the items. Less chance of mixups.
For this to work, the initialization of isGrayscale has to
be moved to the front, because createPPGas sets the color
according to this flag.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of typing out the same arguments again and again,
do the allocation of DiveProfileItems in a templated function.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
A few DiveCartesianAxis functions that were pure accessors
were not const. Make them so. Moreover, mark a few overridden
virtual functions as such.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The profile items had a "setModel()" function to set
the DivePlotDataModel post creation. The model is never
changed. It does however mean that the model might be
null in a short period between construction and setting
the model.
To simplify reasoning about this code, set the model
in the constructor. To drive the point home that the
can never change and cannot be null, turn it into a
reference.
Yes, this is gratuitous bike-shedding, but it helps
me analysis the code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The DiveCalculatedCeiling profile-item has a recalc()
function, which calls "dataModel->calculateDecompression()".
This is a questionable reversal of control-flow: The
profile-item should paint the model-data not change it.
The code was supposed to be called under two conditions:
1) The value of the calcceiling3m preferences flag changed.
This code was buggy for two reasons: Firstly, the cached
value was always initialized to false, which means that
sometimes the first call was missed. Secondly, the
settingsChanged() functions was only called when closing
the preferences window, not when changing the flag in the
profile widgets.
2) The datetime of the dive changed. The whole control-flow is
pretty absurd (due to "bit rot"):
- The replan-dive command sends a date-time changed signal.
- The main tab changes the date-time and informs the profile.
- The profile sends a signal to the item.
- The item instructs the model to recalculate the
decompression.
- The model causes the profile to be redrawn.
In any case, the whole thing is moot, because the decompression
is recalculated for *every* profile plot in create_plot_info_new().
Let's remove the code from the DiveCalculatedCeiling profile-item
and the calculateDecompression() function, which is now not
used anymore.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Dirk says rounded corners look better. This now looks a bit
extreme to me and probably the border size should be increased.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Factor out code from ProfileWidget's ToolTipItem, but make
the radius of the corners dynamic. Move into backend-shared,
though a new ui-shared might be preferred.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
If a dive changes, we should simply redraw the profile. This could be
improved by checking for the fields that might impact the profile at
all, but this is definitely a step in the right direction.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Recently (674c20227b), the call to ProfileWidget::clearHandlers()
was moved from PlannerWidgets::replanDive() to ProfileWidget2.
This cause a crash, because the code assumes that the number
of elements in the handles-vector the divepointplanner model
is the same.
Clearing the handles violates this assumption. It turns out
that the clearHandlers() function is broken anyway: it clear
the handles-vector, but not the gases-vector, which should
likewise have the same number of elements. It appears that
the clearHandlers() function is an artifact and it is
mysterious how this has worked so far. Remove.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
On clicking the DivePictureItem "trash" icon, the item would delete
the picture it represents in the currently displayed dive. This needed
an access to the global "displayed_dive" variable, which we want
to get rid of to make the profile more flexible. For example, we
want to render the profile for printing without messing with global
state.
One solution would be to save the dive with every DivePictureItem.
This commit follows a more Qt-ish strategy by handling this via
signals: The close button emits a signal that is recast by the
DivePictureItem and ultimately handled by the ProfileWidget2,
which knows which dive it represents.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
These were only calling the corresponding functions in the
base class. So just don't override them..?
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The mainwindow was connecting preferences changes to the profile.
Do this directly in the profile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
These are the small dots that describe dragable points on
the profile when in the planner. It makes no sense to have
them in desktop's planner-widget code. They belong to the
profile.
Therefore, move the code there and compile on mobile.
Not everything can be compiled on mobile for now, but it
is a start.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This function, which removes the handlers from the profile, was called
in setAddState() but not in setPlanState(). In the latter case it was
called explicitly by the caller.
Move the call from the caller into the function. This allows us to
make clearHandlers() private in to the profile widget.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
So far, the PreferencesDialog emitted a settingsChanged signal.
This meant that models that listened to that signal had to
conditionally compile out the code for mobile or the connection
had to be made in MainWindow.
Instead, introduce a global signal that does this and move
the connects to the listeners to remove inter-dependencies.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Instead of using the two different ways Qt supports swap, depending on the Qt
version in use, let's simply use std::swap()
Suggested-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This has been deprecated for years.
The delta() member dealt with the old style mouse wheel that is associated with
a vertical scroll - so we need the y-component.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since dive.c is so huge, split out divecomputer-related functions
into divecomputer.[c|h], sample.[c|h] and extradata.[c|h].
This does not give huge compile time improvements, since
struct dive contains a struct divecomputer and therefore
dive.h has to include divecomputer.h. However, it make things
distinctly more clear.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In an effort to reduce the size of dive.h and dive.c, break out
the event related functions. Moreover event-names were handled
by the profile-code, collect that also in the new source files.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Now, that we have this helper function that should have been
introduced long ago, we can make some more expressions
more idiomatic.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
core/device.h was declaring a number of functions that were related
to divecomputers (dcs): creating a fake dc for manually entered dives
and registering / accessing dc nicknames. On could argue whether
these should be lumped together, but it is what it is.
However, part of that was implemented in C++/Qt code in a separate
core/divecomputer.cpp file. Some function therein where only
accessible to C++ and declared in core/divecomputer.h.
All in all, a big mess. Let's simply combine the files and
conditionally compile the C++-only functions depending on
the __cplusplus define.
Yes, that means turning device.c into device.cpp. A brave soul
might turn the C++/Qt code into C code if they whish later on.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There is a number_of_computers() function which does
the same thing with two exceptions:
1) checks for null-dive
2) returns an unsigned int
Replace calls to count_divecomputers() by calls to number_of_computers().
In one case, the return type makes a different - add a cast to int there.
Ultimately, we should probably change the dc_number to signed int
throughout the code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When plotting the profile in higher resolution for export,
increase the icon size in the same way.
This is commented out for the mobile version as that
uses printMode for profile display.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This new option allows a user to select a new destination tank for an
existing "Gas Change" event. This is useful when Subsurface's heuristics
get tanks wrong after an import from a divecomputer. The use-case arose
from sidemount divers with air-integrated transmitters as well as carrying
a deco tank.
Signed-off-by: Michael Werle <micha@michaelwerle.com>
Since the profile does not listen to DivePictureModel resets anymore,
the pictures weren't cleared when clearing the canvas. Do this
explicitly.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The code is rather complex. Firstly, we have different representations
of pictures throughout the code. Secondly, this tries to do add the
pictures in batches to the divepicture model and that is always rather
tricky.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Even though the functionality is seemingly trivial, this is a bit
invasive, as the code has to be split into two distinct parts:
1) Post undo command
2) React to changes to the divelist
Don't compile that code on mobile.
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>
Firstly, the parameter appears conceptually wrong, as replot suggests
that the currently shown dive is replot. Secondly, the only caller that
passed a parameter was passing in current_dive, which is just what happens
if one doesn't pass a parameter. Therefore, change that caller (call
plotDive directly) and remove the parameter.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When populating the events of a profile, a pointer to the current
gasmix was passed around to properly calculate isobaric_counterdiffusion.
The DiveEventItem::setupToolTipString() function updated this gasmix
when processing gas change events.
I inadvertently broke the code when replacing gasmix-pointers by
values. We could of course simply revert this part of the commit.
However, the data flow was horrible anyway: for example is supposed
that the setup functions were called in the correct order (i.e.
DiveEventItem::setupToolTipString() is called after all other
functions using the gasmix). Not exactly easy to follow.
Therefore, keep passing around the gasmix as value to make it clear
that the functions don't modify it. Keep the gasmix up-to-date at
the caller's site in ProfileWidget2::plotDive().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
These two Q_ASSERTs made no sense - their expression (a string
literal) always evaluated to true. A qWarning() was intended here.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The profile data was not properly cleared when not showing a
dive.
Fixes#2787
Reported-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Some profilewidget classes hat protected members which can
be made private as there is no subclassing.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There were a number of protected member functions in ProfileWidget2.
However no class subclassed ProfileWidget2, so this appears to have
been an artifact. Therefore, make these functions private.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This is a bit hairy as - in theory - one gas switch can remove
other gas switch(es) at the same timestamp. However, I did not
find a way to test it. Moreover, it is not clear whether the
dive-tabs are properly updated on undo/redo.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was a trivial copy & past of the event-adding undo command
with a switch of the undo() and redo() actions.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There is a slight complexity here owing to the fact that the profile
works on a copy of the current dive: We get a copy of the event and
have to search for the original event in the current dive. This
could be done in the undo command. Nevertheless, here we do it in
the profile so that when in the future the profile can work on a
non-copied dive we can simply remove this function.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Since pointers to divecomputers may not be stable, the undo
commands take a dive + a divecomputer number. Update the
SetpointDialog accordingly.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
We have too many global objects. There is no reason why this dialog
should be a persistent global object.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This basically copies the bookmark code, with the addition that
the dive mode is recorded in the text of the undo command.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a DiveListNotifer::eventsChanged signal, which is emitted when
the events changed. This is very coarse, at it doesn't differentiate
between signal addition / editing / deletion. We might want to
be finer in the future.
Catch the signal in the profile-widget to replot the dive if this
is the currently displayed dive. Reuse the cylindersChanged() slot,
but rename it to the now more appropriate profileChanged().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Create a new translation unit for event-related undo commands.
Create a base class of commands that add events and one subclass
that adds a bookmark event.
Use this command in the profile-widget.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Since we removed the setData() calls of the QActions in
ProfileWidget2::contextMenuEvent(), we don't have to manually
generate the QActions. We can simply use the convenience
overload of addAction() that takes a string and a functional.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The removeEvent(), hideEvents() and editName() actions need
the DiveEventItem they are applied to. This was transported
via QAction's user-data, which means casting to void and
back.
By using lambdas instead, this can be made perfectly type-safe:
First we are 100% sure that we have a DiveEventItem because
we check the result of a dynamic_cast<>. Then we can pass
it to the even using its proper type.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This is not such a big gain as for addDivemodeSwitch(), but still
simpler. Therefore, let's do it for consistency.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The unhideEvents context menu action was fed with the click-position.
However, that was not used. Therefore, remove it.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The data was transported via the action in a most complicated way:
The text was backtranslated. Simply use a lambda - perhaps hard to
read, but much simpler to follow and less brittle.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In two cases we were passing the magic value 8 instead of the
symbolic SAMPLE_EVENT_BOOKMARK. Use the symbolic version instead.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In the profile, catch cylinder-editing signals and redraw the
profile if the currently displayed dive has changed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The compiler complains that members were initialized out-of-order.
Even though this is not an issue here it is correct to emit a
warning, since only then it is guaranteed that the objects are
destructed in reverse-order with respect to construction.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
If the user is scaling out again we need to make sure that our offsets
are adjusted so that we always show a subset of the profile and not
'empty space' outside of it. Instead of reimplementing the offset logic,
let's just trigger another paint() call.
This requires a trampoline function because of different signal and slot
signatures.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When zooming and panning the profile, make sure we always show a subset
of the profile and don't end up showing the empty space outside of the
profile.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Grammar-nazi ran
git grep -l 'indexes' | xargs sed -i '' -e 's/indexes/indices/g'
to prevent future wincing when reading the source code.
Unfortunatly, Qt itself is infected as in
QModelIndexList QItemSelection::indexes() const
Signed-off-by: Robert C. Helling <helling@atdotde.de>
This will seem too small to many - it's pushing it, but it leads to a
significantly less cluttered profile, and we now have the zoom capability for
readability.
I think this is a nice improvement.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
