... in many places where the function call will later need to be between
modules (or libraries, or the executable) and the annotation will be a necessity
to keep the linkage working on Windows.
That's all that this sweeping commit does.
... This makes it impossible to forget to include the EXPERIMENTAL definitions
(such as when cutting and pasting code) and so get unintended quiet changes of
behavior.
The EXPERIMENTAL flags are now specified instead in new file Experimental.cmake
- Naming (Time Toolbar, not TimerToolBar Toolbar)
- Default time format hhmmss
- Lower dock
- Enabled by default
- Sensible min and max font size
- Sensible min and initial width
- Omit Audio Time from Selection Toolbar
- Update on idle (new idiom from Paul)
- Dock at x1 or x2 size
- Smooth resizing
- Take some account of width when resizing
- Promote Resizable docking code to ToolBar class
... It stopped doing so at 1c1aca5
Because the recreating of the ruler's button now happened earlier than for
the several toolbars, not later, but there was a side-effect on the theme
that the toolbar updates did, that the ruler relied on, namely the updating
of button background images.
Now ruler also invokes that step.
(But wouldn't it be better to do that update in just one place? I am not
sure what that place should be. ThemeBase::LoadPreferredTheme?)
... reduces direct dependencies of ToolManager.cpp.
This frees four files from cycles:
DeviceToolBar
EditToolBar
MeterToolBar
MixerToolBar
Leaving 66 files still in the big s.c.c.
I moved 'Fit()' from ToolBars into MeterToolBar, because it is a workaround for an incorrect size calculation by MeterToolBar. MeterToolBar is sized as if there is no resizer, so when there is one, the toolbar needs to be expanded (using Fit) to accommodate the resizer.
I also set the min size of MeterToolBar to 150, so that some meter will appear, even if Toolbar shrunk to the minimum.
The worst symptoms of this are fully fixed.
1: The device info now uses all the space in the toolbar, no matter how the toolbar is resized.
2: The undocked toolbar can now be moved around repeatedly without changing size at all.
There is a small residual - a much toolbar size change of a few pixels on docking. The contents though still fit nicely. The 'incredible' part of this bug is gone. I'd like us to close this bug as the residual of a few pixels change in the toolbar size on repeated docking and undocking scarcely matters.
Previously hovering over a down button made no difference.
Also tweaked the appearance of hover-over thumbs on dark theme sliders.
Also tweaked hover images and colours generally.
Classic retains the old style.
Hi Contrast does not distinguish between hover-up and hover-down.
Revert "new button images for time ruler"
This reverts commit 26ec0100a2.
Revert "add button"
This reverts commit af5163025a.
Revert "ToolBar::MakeButton is public and static"
This reverts commit 668714942b.
... if the event is not handled and skipped by sub-windows first, such as for
toolbar button clicks.
(But track panel clicks are skipped even after doing something, so they may
also cause seeking besides other responses. So click can seek AND set cursor.)
This is meant to make drag to seek and wheel for change of speed easier,
without needing to keep the mouse in the narrow time ruler.
Also lets you click in the ruler, then move in any direction, and not miss the
motion event that should start the scrub playback.
The event handling is a bit of a hack, using propagation. It does not use
capture.
... for functions in final classes.
override is like const -- it's not necessary, but it helps the compiler to
catch mistakes.
There may be some overriding functions not explicitly declared virtual and I did
not identify such cases, in which I might also add override.
... Should have no effect on generated code, except perhaps some slight faster
virtual function calls. Mostly useful as documentation of design intent.
Tried to mark every one of our classes that inherits from another, or is a
base for others, or has abstract virtual functions, and a few others besides.
It corrects several "multiple project" problems with the
meter toolbars and meters.
In addition, there was a "multiple project" issue where
the transport buttons didn't disable properly in the
non-active project.
1) On startup if the capture meter is vertical and
the playback meter is horizontal, capture meter
would jump to horizontal if you start monitoring.
2) To cut down on meter orientation weirdness, the
orientation is now mirrored in both meters when
it changes.
If this is not a desired behavior then the only
option would be to have separate config file
settings for each meter. That means that the
orientation settings in meter preferences will
correspond to that meter only.
Let me know if this is what is wanted.
I couldn't handle it anymore. The darn pointer would seemingly
switch to left/right arrows whenever it felt like it...and stay
that way.
Actually, it was when it passed over the toolbar resizer when
docked. The problem was that it wouldn't change back to a normal
pointer because it didn't have the events it needed to do that.
So, I moved the resizer logic into it's own window and now the
pointer changes like it should.
As a bonus, we get a tooltip so the user will know what to do
when the pointer changes as it passes over the resizer.
* Loop play-at-speed and cut preview play-at-speed implemented.
* Shift or ctrl down now affect all relevant buttons, loop or cut preview, normal or at speed, and append-record.
