https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #15 from Maurizio Paolini ---
Opened a qt bug report:
https://bugreports.qt.io/browse/QTBUG-52312
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #14 from Maurizio Paolini ---
A standalone minimal C++ program using Qt5 and drawEllipse shows that the
precision
loss with circles having large radius is actually a Qt problem!
I will try to file a qt bug report about this problem.
However
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #13 from Maurizio Paolini ---
Created attachment 98047
--> https://bugs.kde.org/attachment.cgi?id=98047&action=edit
same as previous, but with unmodified kig
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #12 from Maurizio Paolini ---
Created attachment 98046
--> https://bugs.kde.org/attachment.cgi?id=98046&action=edit
png showing a (different) problem when drawing circles/arcs
--
You are receiving this mail because:
You are watching all
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #11 from Maurizio Paolini ---
Anyway, there are still problems when drawing arcs and circles; apparently of a
different
nature: it becomes apparent when the radius of circle/arc is much larger then
the size
for the displayed canvas. I will
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #10 from Maurizio Paolini ---
An identical problem is present when drawing circular arcs! Since the
correction is minimal and perfectly similar to what was done for circular arcs
I took the liberty of pushing it into
origin/master.
The comm
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #9 from Maurizio Paolini ---
solved via reviewboard:
https://git.reviewboard.kde.org/r/127354/
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=360734
Maurizio Paolini changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://bugs.kde.org/show_bug.cgi?id=360822
Bug ID: 360822
Summary: cmake does not find Boost Python support
Product: kig
Version: unspecified
Platform: Compiled Sources
OS: Linux
Status: UNCONFIRMED
Sever
https://bugs.kde.org/show_bug.cgi?id=360614
Bug ID: 360614
Summary: After a successful "make" from git sources, the "make
install" creates a bogus "share" directory
Product: kig
Version: unspecified
Platform: Compiled Sourc
https://bugs.kde.org/show_bug.cgi?id=360734
Bug ID: 360734
Summary: creation of a bogus share directory with root
ownership in the source location
Product: extra-cmake-modules
Version: unspecified
Platform: Compiled Sources
https://bugs.kde.org/show_bug.cgi?id=360614
Maurizio Paolini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=360734
--- Comment #1 from Maurizio Paolini ---
*** Bug 360614 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=360611
Bug ID: 360611
Summary: compilation target "kigpart_automoc" generates invalid
include paths in moc files
Product: kig
Version: unspecified
Platform: Compiled Sources
https://bugs.kde.org/show_bug.cgi?id=360614
--- Comment #3 from Maurizio Paolini ---
I narrowed the problem a bit:
after creating a bogus empty "share" file in the sources directory I did a
"make VERBOSE=1 install"
as root, to get the error:
[...]
---
https://bugs.kde.org/show_bug.cgi?id=360611
--- Comment #2 from Maurizio Paolini ---
Actually, I am not sure this is a "moc" problem. By using "make VERBOSE=1" I
got the exact
command executed to obtain one of the moc* files:
-
https://bugs.kde.org/show_bug.cgi?id=360614
--- Comment #2 from Maurizio Paolini ---
This is the "cmake" that I use (right after a git clone)
cmake . -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=debugfull \\
-DPLUGIN_INSTALL_DIR:PATH=/usr/lib/qt5/plugins
The strange thing is that what is cr
https://bugs.kde.org/show_bug.cgi?id=360611
--- Comment #3 from Maurizio Paolini ---
It seems that different ways to get the current directory are used. Indeed in
my situation
I get:
$ cd Git/kdeedu/kig
$ pwd -L
/home/matem/paolini/Git/kdeedu/kig
$ pwd -P
/home/misc/euclide/paolini/Git/kdeedu/k
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #8 from Maurizio Paolini ---
(In reply to Rex Dieter from comment #7)
> I'd recommend submitting your patch to reviewboard.kde.org, that's the ideal
> way.
Done... but no comments so far. Now I am not sure what to do. Should I push
my com
https://bugs.kde.org/show_bug.cgi?id=360611
--- Comment #5 from Maurizio Paolini ---
>From Qt I was redirected to cmake developer... Actually I *did* try hard to
find something about "automoc" in the internet before submitting the bug
report, but with very little success. I thought that "moc" wa
https://bugs.kde.org/show_bug.cgi?id=360611
--- Comment #4 from Maurizio Paolini ---
I just opened a bug report for qt on this issue:
https://bugreports.qt.io/browse/QTBUG-51964
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=360611
--- Comment #6 from Maurizio Paolini ---
The following alias solves the problem for me:
alias cmake='PWD=$(pwd -P) cmake'
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=353836
Maurizio Paolini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=359805
Maurizio Paolini changed:
What|Removed |Added
Attachment #97700|0 |1
is obsolete|
https://bugs.kde.org/show_bug.cgi?id=360153
Bug ID: 360153
Summary: select among superposed objects as macro argument
Product: kig
Version: unspecified
Platform: Fedora RPMs
OS: Linux
Status: UNCONFIRMED
S
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #5 from Maurizio Paolini ---
Created attachment 97700
--> https://bugs.kde.org/attachment.cgi?id=97700&action=edit
patch proposal
This patch adds toScreenF methods alongside toScreen and uses it to create a
QRectF instead of a QRect in Ci
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #4 from Maurizio Paolini ---
A simple workaround to the problem consists in commenting the
method "CircleImp::draw" in both objects/circle_imp.cc and
objects/circle_imp.h.
In this way kig falls back to the generic method for drawing conics,
https://bugs.kde.org/show_bug.cgi?id=359805
Maurizio Paolini changed:
What|Removed |Added
Summary|strange loss of drawing |strange loss of drawing
|p
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #3 from Maurizio Paolini ---
Maybe this issue is related to this qt bugreport:
https://bugreports.qt.io/browse/QTBUG-1292
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #2 from Maurizio Paolini ---
Created attachment 97618
--> https://bugs.kde.org/attachment.cgi?id=97618&action=edit
two tangent circles
This is a striking example. The two circles are constructed as tangent,
however their representation i
https://bugs.kde.org/show_bug.cgi?id=359805
--- Comment #1 from Maurizio Paolini ---
One comment that could help debugging:
Once we have the zoomed window after steps 1 and 2 above:
- move the cursor over a point of the displayed thin line (beyond the end-point
of the arc): nothing appears
- mov
https://bugs.kde.org/show_bug.cgi?id=359805
Bug ID: 359805
Summary: strange loss of drawing precision in many
circumstances
Product: kig
Version: unspecified
Platform: Compiled Sources
URL: http://dmf.unicatt
32 matches
Mail list logo
