This removes a few instances of deleting a scene twice, or accessing
elements of a scene after they've been deleted.
Previously, the application would crash upon exiting if the scene was
empty but had been modified (e.g if an object was placed on the board
then deleted, then the application closed)
Previously, only transforms were saved -- not positions (which are set
if a group is moved by dragging it directly; if dragged by its frame,
its transform is updated instead).
Issue observed was that a group that had been moved would lose its new
position when the document was saved then loaded. (All other transforms
were kept, however).
Now, when duplicating a group before saving a document, position is
included in the group's transform.
This was observed in some cases on low-resolution screens, at least on
Linux and Windows.
The previously hardcoded value for the width of the text items' titlebar
(consisting of the buttons for formatting text) was replaced by a
method calculating its width (which varies based on screen resolution).
... to the nearest 2 decimal places. This fixes a bug where upon loading
a text item, it could be scaled by e.g 0.999999, which would eventually
round down the point size by 1pt. Making the text item shrink by 1pt
every time the document was opened.
Fixed issue that appeared with previous commit, where grouped strokes'
positions were sometimes saved and loaded incorrectly.
Strokes and their transforms should now be saved correctly whether they
are grouped or not
Solves issue where items (other than strokes) that had been grouped then
moved (and/or rotated) lost their new position after saving and loading
the document.
- Selecting multiple media items then grouping them didn't behave as it
should for other items => fixed by adding type tests
- A group containing several media items wasn't saved to SVG with those media
items as children, due to incorrect UUID copying in the mediaItems's
deepCopy() methods
The same font, in the same point size, can be displayed differently
depending on platform (this is a Qt limitation). This can lead to text
items being the wrong size when importing a document created on a
different computer.
As a workaround, when saving a text item to SVG, the size of 1pt in
pixels is calculated and saved. Upon loading, this value is calculated
again and, if it is different from the saved value, the text item is
scaled accordingly.
Thus, any document created from this version onward will have
correctly-scaled text boxes. If an old document (not containing a
pixel-per-point attribute for text items) is loaded, the scene is marked
as modified to make sure that all text items are then saved with the
pixels-per-point value (even if the document is not edited). This allows
old documents to be "fixed" by simply opening them once from a new
version of OpenBoard.
save text item font size in pixels, and scale it on load
fixed loading of text item pixel height
Save and load pixels-per-point rather than text pixel height
Upon loading a text item from SVG, make sure that it will be saved with a pixel-per-point value
This allows users to change the color of the background grid e.g if they
are using a projector or other low-contrast display.
The settings are in the `Board` category and are named `CrossColorDarkBackground`
and `CrossColorLightBackground`. They take strings representing the
color in any of the following formats:
- #RGB (Hexadecimal digits)
- #RRGGBB
- #AARRGGBB
- #RRRGGGBBB
- #RRRRGGGGBBBB
- Any SVG color keyword name (as defined by W3C)
Several issues remain with multi-screen mode on Linux. The behavior is
inconsistent from one desktop evironment to the next, making it hard to
work around these problems. Among the known issues at this stage:
On Ubuntu 14.04, a call to QWidget::setGeometry requires the widget to
be hidden on KDE, but visible on MATE, for the geometry changes to take
effect.
Despite the widget's geometry being updated by this call, the windows
aren't necessarily moved. Meaning that the control and display widgets
will tend to be displayed on the same monitor, even though their
positions are correctly set to different areas on the extended screen.
In the current state, this behavior is observed on MATE. Unity works
fine and KDE only has transient positioning issues (for example,
swapping control and display windows in multi-screen mode leads to both
windows being placed on the same monitor, until multi-screen mode is
turned off then on again).
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch dev
# Your branch is ahead of 'origin/dev' by 29 commits.
# (use "git push" to publish your local commits)
#
# Changes to be committed:
# modified: src/core/UBApplicationController.cpp
# modified: src/core/UBDisplayManager.cpp
# modified: src/core/UBDisplayManager.h
#
# Changes not staged for commit:
# modified: release_scripts/linux/build.sh
# modified: release_scripts/linux/package.sh
#
# Untracked files:
# release_scripts/linux/generateDependencies.sh
#
In the right-hand pane, two folders that were at the same path and whose
names started with the same characters were considered to be nested by
the breadcrumbs trail.
E.g, folders named "abc" and "abcd", both in the "Audio" folder:
clicking on "abcd" made the breadcrumb trail display "[Audio] > [abc] >
[abcd]"
On OS X, making annotations in desktop mode then switching to board
mode and back could cause shadows to be drawn around every stroke, and
these persisted after erasing the strokes (though they did disappear
upon switching to board mode and back again).
The scale of PDF items was sometimes badly calculated when opening a
document made with a previous version of OpenBoard or made on another
computer.
Specifically, this solves the following issues:
- PDF scale calculation in documents that did not specify the pageDPI
used to render the PDF (happened with documents created with some old
versions of OpenBoard)
- PDF scale calculation in multi-page documents (it was set correctly
for the first page, but not the following ones)
In some cases, the PDF background of a document could be scaled badly
when tools such as the ruler, compass etc. were present on the page.
This happened with PDFs of version <= 1.4, and when the tools were
outside of / larger than the page.
Craig Watson
EmPeWe