Having multiple views not only is bad for performance but also creates
difficult to debug problems on some hardware configurations and is
fairly confusing.
Task-number: QTBUG-38222
Change-Id: I885e800b1ededab9137874105e3b2f9ec88a06e8
Reviewed-by: Jocelyn Turcotte <jocelyn.turcotte@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
By passing signals with identification information of varying accurary
between the different views the event being selected could be changed
while it was selected. By checking the current selection against the
information given in the signal and not reselecting when it matches the
situation is improved.
Also, the selection methods are given more appropriate names. We hardly
ever want to select the "next" event, but rather the "best fitting" one.
Task-number: QTCREATORBUG-11945
Change-Id: I659b4929cb88f4c931a0893aa95a3bc92da5a23b
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Using the extra window the ZoomControl keeps makes it impossible to
increase contentWidth to a point where it overflows. The drawback is that
the position on the scrollbar doesn't reflect the real position of the
visible part of the trace anymore if you zoom in to such a depth.
Task-number: QTCREATORBUG-11879
Change-Id: I6649f3c139f76c242a91d60364a28a4a00c9acee
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Previously, if you selected an event with the same ID from a different
model the rangeDetails wouldn't be updated. Now modelId and itemId can only
be updated together and a single signal is emitted for that. This signal is
then used to update the details.
Change-Id: Ie1e971f5ac8c041b49df347fa0fbb401d5422766
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
The selectedEventChanged signal was never emitted and aliasing the
selectedItem property was unnecessary.
Change-Id: I2a15ad82bbf20a7ae9a42e17935242fbac7b5129
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Several QML properties need extra treatment to avoid stale data
after clearing. Toggling the visibility of the timeline renderer
doesn't really help there.
Task-number: QTCREATORBUG-11833
Change-Id: I1903d7bd69d6fe31ecc4cadca8e30fa2104fa09a
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
No need to keep properties around that aren't read anywhere.
Change-Id: Ie9300ad646466a6a2368f644a420d8654891805f
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
contentWidth has to be updated before contentX as the WheelArea
underneath will clamp its horizontal value to its bounds on change and
thus break the update to contentX if contentWidth is growing.
As contentX is automatically updated by changes to contentWidth it's
generally a good idea to prevent any reactions to that with a recursion
guard. When updating contentWidth before contentX this becomes necessary
for correct operation.
Task-number: QTCREATORBUG-11699
Change-Id: I34fff7a55e93745d658e8cbb5ac3d430a42770e8
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
If the timeline is being flicked and we manually set contentX from the
zoomControl callback it will stop. That's unnecessary as the flicking
itself will trigger further updates to zoomControl.
Change-Id: Id14bde1bb33d6b1f6d719a41df23074981e474da
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
This requires the consolidation of the nested Flickable elements into
one, which is probably a good idea anyway. The horizontal scroll bar is
important because people might not understand that they can use the
overview for scrolling.
Change-Id: Ie1555265fc3edafaf6e6e4f34d77b0d034d45639
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
MainView.eventCount is always 0 since the last cleanup. It doesn't do
anything useful and can be removed.
Task-number: QTCREATORBUG-11515
Change-Id: I367a11e41c34e691550b6d6e5943fc372f0f04ca
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
We don't want to emit a signal for each event being added. That's
expensive and doesn't serve any purpose. We also don't have to save
the availability of data in QML as it isn't used anywhere.
Change-Id: I32db06a1955a7cfd6b569f50b81bf5278333b622
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Anchors are supposed to reduce graphical glitches such as the gradient
borders getting detached from the edges of the timeline while resizing.
I'm not sure if it's actually better like this, but the code certainly
looks nicer.
Change-Id: I9eb6a6a50780ce642ad7cb551d2895a80b00690e
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Those functions aren't called from anywhere. Wheel zooming has been
removed a long time ago and centering is handled in a different way.
Change-Id: Ib55fdfdd3cf794563eaa50ff9b5f1a1dfe94a17a
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
As the contentWidth depends on both the width of the flickable and the
currently selected time range it should be updated if either of them
change. Otherwise we can miss changes and show stale data.
Change-Id: Iab9e17eef3490531175a2374fb3da0e0071f3bd1
Reviewed-by: Christian Stenger <christian.stenger@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
As it's hard to pass arguments for signals from non-QML-mapped objects
to QML objects handle the signal in C++ instead and just directly set
the properties.
Task-number: QTCREATORBUG-10943
Change-Id: I039f6938db3d7e64ca1a4bcff2f0f6aa79c65219
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
When selecting ranges in the timeline the selector would sometimes hang
or behave weirdly when moving back. This was due to incorrect logic in
the selection bounds calculation and because the vertical flicking would
steal mouse events.
Change-Id: I14074463422d1d9a0aa8ecd1f88847e7330c9b6b
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Reviewed-by: Ulf Hermann <ulf.hermann@digia.com>
Reviewed-by: Eike Ziller <eike.ziller@digia.com>
Due to QTBUG-34962 we can't rely on the width properties of Flickables
so we use some other elements to size the background bars.
Task-number: QTCREATORBUG-10882
Change-Id: Iee427022111b6092486adaebfd33f8e2e6a91190
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
By overflicking you could reduce the selected range and implicitly zoom
in. That seemed wrong. The rubber effect doesn't serve a real purpose
on desktop applications anyway.
Task-number: QTCREATORBUG-10864
Change-Id: Id4d6107e23c184621c5fcce21bf042e6ed4bd8e6
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
For some reason, when the timeline width is 0, the background width can
get negative, if using bindings; it works fine when using anchors.
Change-Id: I5eb76f83b9c41c1a71a135082770079cedc7f16c
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Deduplicate the code and fix the "jaggy" behavior.
Task-number: QTCREATORBUG-10762
Change-Id: Iaca3bc5b77cb8d92f082232e6fd3c2d9e0935300
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
The timeline can be vertically navigated by flicking, which is not very
appropriate for desktop applications. This change provides a scroll bar
and mouse wheel scrolling in addition to that. Also it makes the
vertical movement stop at the boundaries. The mouse wheel would exhibit
unintuitive behavior without it.
Change-Id: I5ef126525e452f46aa0a483a544345b8f618d829
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
The content of the horizontal Flickable element could remain at negative
positions after flicking and generally showed inconsistent behavior.
This was due to the redundant storage of the horizontal offset in
view.startX and flick.contentX. Explicitly assigning contentX from JS
code disables the automatic "rubber" effect which pulls the content back
into the allowed area.
Change-Id: I69e827854e2be3d8f6f4e2537e7105f80a8f2a89
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
The zoom level calculations were much too complex and introduced
rounding errors in various places. By moving them all into one
place and avoiding circular recalculations of the same thing those
problems are mitigated.
Task-number: QTCREATORBUG-10635
Change-Id: I7316caad1a590964402056a2e6430c8d059ae097
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
This restores the functionality of the old zoom slider. It probably
looks a bit different, but it does the same thing.
Task-number: QTCREATORBUG-10635
Change-Id: Idcb19187df066e4b1336df73b122aa567a732dee
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
The timeline can cover a large vertical space. The introduction of
the Flickable element to navigate that space has reverted the effect
of commit 5eb057c7e. This change restores the performance
improvements and avoids overflows in the underlying buffers.
Change-Id: I86ddd66652ee0a26c81619682a883622072b0f87
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
The vertical Flickable element can get very large if certain
categories are expanded. If the time marks have to fill the whole
element the underlying buffers holding the pixmaps and/or OpenGL
data may overflow.
Task-number: QTCREATORBUG-10420
Change-Id: I45952e8237bb827a963e0e4e8deb060646c0c8f4
Reviewed-by: Ulf Hermann <ulf.hermann@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Introduce a second flickable element to encapsulate the timeline as
well as the labels and move SelectionRangeDetails and SelectionRange
out of that to make them float on top.
Task-number: QTCREATORBUG-10420
Change-Id: Ib4af7dc4b0155b9371c582938f1b4abb3e40cf06
Reviewed-by: Ulf Hermann <ulf.hermann@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Vertical scrolling doesn't work at the moment and has to be implemented
in a different way. Besides, the code tracking the root's vertical
scroll hasn't done anything useful in a long time.
Change-Id: If2add3874cba971bbaace2c22fbf1b2bf0b463b7
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Reviewed-by: Ulf Hermann <ulf.hermann@digia.com>
Previously the timeline was only repainted if the selected start time
changed. If the start time is != 0 changes of endTime unfortunately
imply changes of startTime most of the time. This is why the
effect was mostly invisible.
Task-number: QTCREATORBUG-10707
Change-Id: I21a86a4248c949f5ad630e6c5a30f8caedcbfe7e
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
The flick range should always be bounded by finite numbers.
Task-number: QTCREATORBUG-10623
Change-Id: I27290eca531a1f36293dc0dea3dbdf0d2181e822
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
This is to avoid confusion with generic Label
Quick component.
Change-Id: I6a72266c394862706215b6db40bcd3592f9d24b3
Reviewed-by: Ulf Hermann <ulf.hermann@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Avoid rendering outside of the canvas by forcing the windows
size onto the scene, and also removing the related candidateSize
logic.
In the QtQUick1 based profiler one could scroll the canvas also
vertically, but that doesn't work any more. This is a hot fix
to work around the problem, we can hopefully bring back the
full solution later ...
Change-Id: Ibd3d54f6b98c3764e104116d395a77b880d88bcb
Reviewed-by: Ulf Hermann <ulf.hermann@digia.com>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
In the case that the application did not generate any event
after running the profiler, still show an empty trace.
Otherwise the user will think that the profiler didn't work.
Change-Id: Idd15225270d55d834719f66387864433fcb9026d
Reviewed-by: Kai Koehne <kai.koehne@nokia.com>
