QCAD Bugtracker

Hello, I recently bought QCAD Pro and this is my first Bugtracker report!

First, I want to say a big thank you for creating and maintaining such a wonderful software package!

I’ve never encountered a system for expressing constraints in 2D (or even 3D) that feels as natural, intuitive, and expressive as QCAD feels!

I am very grateful to have randomly found it somehow. I wish all user interfaces were designed this way and especially that vector art programs adopted similar constraint-based tools.

Anyway though, here’s the actual feature suggestion:

I noticed that QCAD is missing one especially convenient and naturally occuring angular unit: cycles (a.k.a. turns or revolutions).

I personally find cycles to be my favorite unit overall and to be the most intuitive to work with (when not needing to use physical protractors). I actually mostly work digitally and most of my uses for QCAD will be digital. QCAD is the only software I’ve found that really expresses 2D constraints the way I want to be able to work and lay things out.

Rather than redundantly belabor the many reasons why I think cycles should added to the available displayed angle units in the Preferences → Dimension Settings → Angular Dimensions dropdown list, I will simply link to the rather large discussion I’ve already had with Husky and CVH arguing my case about why I want it added and why many other users could benefit from it.

Here’s the link to the relevant forum discussion.

Similarly as for my previous suggestion submission, I also had a related idea for making it easier to work with complex numbers when using QCAD by adding normalized unit circle coordinates as another option in the Angular Dimensions display units options dropdown.

Here’s the corresponding forum thread I started.

I noticed that every time I move my mouse from the main working canvas (schematic area) to the tool buttons on the left sidebar there is a delay before the first hover tooltip (which displays the tool names and hotkeys corresponding to each tool button) displays.

The tooltips remain fast (near instant) after that initial hover, but it it would be nice if there was an option field for controlling how long the tooltip delay is for that initial display delay.

Currently, on my Windows 10 machine, it takes about 1 full second for the tooltip to show, which may not sound like much but feels like a lot when trying to work faster.

Here is a link to the related forum discussion, which also discussed a different (and I’d say more useful/effective) idea as well.

I’m creating two separate Bugtracker submissions for that one thread though, to keep things clean.

Perhaps I should have created two separate forum thread for that to begin with.

Hello! This is perhaps the most useful and valuable of the suggestion ideas I’ve had for QCAD so far!

I think it would be extremely useful if there was an option within the QCAD preferences for making it so that the hotkeys currently bound to each tool button in the UI (if existent) are always displayed such that they are overlaid on top of each of the buttons. There are two main approaches I can think of for doing that (both intended to avoid disturbing the existing layout of the UI):

1. Display the current hotkey binding associated by drawing it (probably in a distinct color) on one of the edges or corners of each of the buttons (such as the bottom middle side, the lower left corner, or the lower right corner). Even at a small font size I think this would be very effective and useful.
2. Instead of making the overlaid hotkey display in a small font at a side or corner of each button, you could have the hotkey text be in a large font and overlaid on top of the entire button, using things such as transparency and a distinctive (never used in the other parts of the UI) color to ensure that the button icons is still readable. A broader width of the font stroke may also help if transparency is used, so that the underlying icon lines remain more readable.

Both approaches have pros and cons. I personally lean towards the former, but Husky and CVH seemed to take issue with the readability of small fonts and so I later suggested the later option too.

They seemed opposed to both (at least during the forum discussion). However, I think this UI feature could be one of the best workflow speed improvements for the average user (many/most of whom probably don’t have time to memorize the hotkeys or just don’t end up doing so) of QCAD!

The gains in efficiency and pleasantness could be enormous potentially, even despite it QCAD already being among the most pleasant and well-designed programs I’ve ever used!

It is far faster to be able to instantly read a hotkey from the UI than to have to wait for a tooltip or to look the keystrokes up in the documentation.

Memorization is the fastest of course, but as someone who finds themselves constantly spread thin over many different programs (often half a dozen or more) for long spans of time I often find it difficult to remember all of the hotkeys for each program I use. Having such hotkeys always visible is useful for users who are spread thin, as many people increasingly in the world of software.

CVH suggested that I make custom icons myself, but doing so seems far worse than simply having QCAD automatically read and then print out the corresponding hotkeys over every tool in a programmatic and properly automated way.

I seriously think this would be one of the most awesome improvement you could ever add to QCAD!

Indeed, there is no missing feature I want more than this one!

Few programs do this but the few cases I’ve seen it the feature was extremely useful for speed without having to take weeks/months/years to fully memorize hotkeys only then forget them later. This idea eliminates that problem!

It would be glorious from a usability and accessibility standpoint! Please implement it!

Hopefully Qt’s GUI system is flexible enough to draw overlaid text over the buttons like this without to much hassle. That is the main potential impediment as I see it.

Anyway though, here is the associated forum discussion where I mentioned this idea. It was the same thread as the one where I also suggested adding a way to control tooltip delays.

Hey, this is the first of my feature suggestion submissions that isn’t tied to a corresponding suggestion thread on the QCAD forum.

Should I always create corresponding feature suggestion threads or is it ok (or better?) to just post ideas here?

Anyway though, here’s the idea:

I noticed that it is relatively easy to use things like the QCAD Split Entities and/or Paste Along Entity tool(s) to create an even set of divisions along a curve or line.

There’s also the Misc → Draw → Counter available too, for automated counting.

These together are useful for creating a “scale ruler” to be printed on a schematic for ease of reference or for use in cases where someone forgets to bring along a physical measuring device or when someone else is using that measuring device.

For example, one could print a to-scale 1 foot long ruler (or whatever other scale is relevant, e.g. 1 inch for small objects or just as a nice scale reference/legend/key) on the schematic page for convenience.

However, it would be nice if there was a convenient tool added to the Dimensions tool category that automated this entire process and was able to create arbitrary ruler-like numbered reference scales along lines (and even better if it also worked on arcs, though less important).

Even better would be if this “auto tick” or “auto ruler” tool supported multiple levels of tick scaling (e.g. 2 or 3) such as what one sees on actual rulers.

For example, an imperial ruler for a foot (I’m in the US currently) will typically having increasingly smaller tick marks added at halfway points between each of the numbered points along the ruler’s scale, which makes using it quickly much easier. For example, it’ll have a half-length tick for half an inch and then a quarter-length tick for each quarter of an inch within an inch (with the inch’s ticks being full length).

It seems like it could be relatively easy to implement that kind of nested tick marking system, which would make it super convenient and pleasant for the user of QCAD to create usable to-scale ruler-like objects wherever they desire them with hardly any effort!

I think this idea would also fit extremely well with existing tools in the Dimensions category and would be useful for many/most QCAD users!

It’s yet another good QCAD feature that could attract more people to buy upgraded copies of QCAD in the future I think!

I hope you implement it. Small conveniences still make a big difference.

Anyway, thanks a bunch again for creating this awesome program!

That’s all the suggestions I have for today.

I hope you have a wonderful weekend and upcoming week, etc!

I've tried several times to try to see what the "surveyor's units" option of the Angular Dimensions format in the UI preferences will display as, but all it ever seems to do is cause the angle measurement to become blank. No angles are displayed whenever this mode is selected.

Indeed, I cannot figure out what the setting actually does besides causing angles to never be displayed.

Is there a way to make this setting do something meaningful or is it just broken?

I found an old forum thread from 2016 about this same issue and it sounds like the same things is still happening since then.

I'm not a surveyor so I have no actual practical use for these units that I can yet see, but I just figured I'd add an report to the bug tracker here in case any developers aren't aware that the bug still seems to exist.

Does the setting do anything besides changing the displayed units in the status bar?

In my current QCAD file I’m working on, I have a circular hub with a hole in it which I am also trying to place an alternating sequence of rectangular spokes of a certain relative size around.

I had 4 spokes that I had copied and rotated 45 degrees to create 8 spokes in total around the circle. I tried scaling the the non-cardinal spokes relative to the center of the circular ring, but that causes them to also move towards the center of the ring as they shrink, thereby putting them out of place as they scale.

I therefore had to activate the scale tool once per each object and set an origin (focus) point around the area where each spoke is “attached” to the ring in order to stop each from shifting inward to the circle as it scales.

It occurred to me though that there could be a simple tool or option to do this without that.

Each of my rectangles are polyline objects and thus are coherent continuous objects.

A new scaling tool could be designed such that it is based on simply clicking on each scaling origin on each object (using snapping tools if needed) and then clicking a check button (or enter) when done and then causing the scaling GUI to appear so the user can specify the desired scaling. Each scaling would then be applied to where the polylines were clicked instead of to all the objects as one.

This would be a much faster way to rescale a bunch of objects around individually varying relative scaling origins!

I was having some problems getting some shapes to fill with a solid fill and was frustrated by the awkward numeric coordinate it was giving me for where the error (the disconnected shape points) were, until I fortunately noticed that a tiny pale circle appears around the point where the error is for about just 1 second.

This is a very helpful error indicator circle but is far too easy to miss.

Perhaps making it last longer (or letting the user control that) would be beneficial.

I also wonder if showing multiple such circles (when they exist, as they did in the piece I was working on) at the same time or having that as a UI option would be good.

Anyway, goodnight all!

I don’t actually have any use for this idea currently, but am just posting it here to document it for consideration.

Basically, it occurred to me at least a few more useful conversions between shapes besides the existing ones could be useful.

For example:

• Converting lines into axially aligned rectangles of a specified “radius” or “diameter” (with an option to delete or keep the original line geometry).
• An option for the above (lines –> rectangles) that causes the intersections between the resulting rectangles to be automatically removed, like a kind of “automatic/magic wall creation tool” based on laying down lines instead of rectangles and then converting via this tool.
• Converting circles/ellipses and rectangles back and forth between each other via their bounding volumes. It seems reasonably likely that people will sometimes want to convert circular design elements into rectangular ones and vice versa (e.g. deciding a rectangular column makes more sense than a cylindrical one and vice versa).
• Converting any arbitrary selection into a corresponding bounding circle (not rectangle, which already exists) of sufficient size to enclose all points in the selection.

Basically, QCAD already has tools for converting shapes with operations that are a natural fit for the existing geometry, but has less tools for converting to entirely different geometry, but such uses could actually still be very useful potentially!

It seems likely to be common enough as a use case to merit inclusion, rather than just using scripting.

I don’t have any pressing need for these and I know that I could script them to create them if I really wanted to.

These are relatively minor ideas. I’m just putting this out here as more ideas for making this already wonderful software even better. :)

Reason: Same underlined keys are used for different menus

Select and Snap = S,
Dimension and Info = I,
Modify and Misc = M,

Andrew,

Related topic: https://www.qcad.org/rsforum/viewtopic.php?f=33&t=10649

Already two different users report that Landscape is printed cropped in portrait format, both Win11. The behavior change occurred recently.
Although the second user (rdtsc) reports the same behavior for latest Mabox Linux (Manjaro, Arch.)

Can not replicate that on Win7 32 bit nor on Win10 64 bit, both are no longer or not updated OS. For one, I have no orientation setting displayed in my printer dialog.

It seems not to be related to the QCAD version:
Reported for:
- Win11 QCAD Pro 3.29
- Win11 QCAD-CAM 3.27.8.0

Regards,
CVH

Building with the bundled version, 1.8.5, works fine.

When I try to build using the system version, which for Mageia Cauldron is 1.9.3, the build fails.

https://raw.githubusercontent.com/kekePower/mmbl/master/qcad/2019/12/11/20%3A13%3A48/log.qcad

Here is the current spec file for version 3.23.0.4.
https://svnweb.mageia.org/packages/cauldron/qcad/current/SPECS/qcad.spec?revision=1465894&view=markup

It looks like qcad is incompatible with versions above 1.8.5.

Are there plans to port to the new version?

Thanks in advance.

How to reproduce.

1. Create a text field with some non-english words in the upper index. (see attached pic1.png)
2. Save the project and close QCAD.
3. Run QCAD and open same project.
4. Now upper/lower indexed text becomes not human readable UTF codes. (see attached pic2.png)

Tried different fonts - doesn’t help.

Linux ntb-kirill 3.10.0-1062.12.1.el7.x86_64 #1 SMP Tue Feb 4 23:02:59 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
CentOS Linux release 7.7.1908 (Core)

1. Create spline
2. Move spline nodes. After ~10 times move qcad is crashed with backtrace:
Thread 9 “Thread (pooled)” received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff56dc9640 (LWP 8224)]
0x00007ffff66fabf2 in QList<QSharedPointer<RShape> >::node_copy (this=<optimized out>, src=0x55537c59e758, to=0x555557f66408, from=0x55537cfdc848) at /usr/include/qt5/QtCore/qlist.h:492
492 current→v = new T(*reinterpret_cast<T*>(src→v));
(gdb) bt
#0 0x00007ffff66fabf2 in QList<QSharedPointer<RShape> >::node_copy (this=<optimized out>, src=0x55537c59e758, to=0x555557f66408, from=0x55537cfdc848)

  at /usr/include/qt5/QtCore/qlist.h:492

#1 QList<QSharedPointer<RShape> >::detach_helper (alloc=<optimized out>, this=0×555557311620) at /usr/include/qt5/QtCore/qlist.h:835
#2 QList<QSharedPointer<RShape> >::detach_helper (this=0×555557311620) at /usr/include/qt5/QtCore/qlist.h:849
#3 QList<QSharedPointer<RShape> >::detach (this=0×555557311620) at /usr/include/qt5/QtCore/qlist.h:178
#4 QList<QSharedPointer<RShape> >::detach (this=0×555557311620) at /usr/include/qt5/QtCore/qlist.h:178
#5 0x00007ffff686182a in QList<QSharedPointer<RShape> >::end (this=<optimized out>, this=<optimized out>) at /usr/include/qt5/QtCore/qlist.h:342
#6 QList<QSharedPointer<RShape> >::last (this=0×555557311620) at /usr/include/qt5/QtCore/qlist.h:364
#7 RSpline::appendToExploded (this=0×555557311510, line=...) at math/RSpline.cpp:964
#8 0x00007ffff6867059 in RSpline::getExploded (this=0×555557311510, segments=1457293328) at math/RSpline.cpp:919
#9 0x00007ffff686682a in RSpline::getLength (this=this@entry=0×555557311510) at math/RSpline.cpp:1026
#10 0x00007ffff6c11490 in RSplineData::getLength (this=<optimized out>, this=<optimized out>) at /usr/src/debug/qcad-3.27.0.0/src/entity/RSplineData.h:178
#11 RSplineEntity::getProperty (this=0x5555573114a0, propertyTypeId=..., humanReadable=<optimized out>, noAttributes=<optimized out>,

  showOnRequest=<optimized out>) at /usr/src/debug/qcad-3.27.0.0/src/entity/RSplineEntity.cpp:253

#12 0x00007ffff67cc214 in RPropertyEditor::computePropertyValue (ccProp=...) at /usr/src/debug/qcad-3.27.0.0/src/core/RPropertyEditor.cpp:574
#13 0x00007ffff67d298f in QtConcurrent::FunctionWrapper1<void, RProperty&>::operator() (u=..., this=0x555557757f18)

  at /usr/include/qt5/QtConcurrent/qtconcurrentfunctionwrappers.h:80

#14 QtConcurrent::MapKernel<QList<RProperty>::iterator, QtConcurrent::FunctionWrapper1<void, RProperty&> >::runIteration (it=..., this=0x555557757ee0)

  at /usr/include/qt5/QtConcurrent/qtconcurrentmapkernel.h:68

#15 QtConcurrent::MapKernel<QList<RProperty>::iterator, QtConcurrent::FunctionWrapper1<void, RProperty&> >::runIterations (this=0x555557757ee0,

  sequenceBeginIterator=..., beginIndex=<optimized out>, endIndex=15) at /usr/include/qt5/QtConcurrent/qtconcurrentmapkernel.h:77

#16 0x00007ffff67d2c9d in QtConcurrent::IterateKernel<QList<RProperty>::iterator, void>::forThreadFunction (this=0x555557757ee0)

  at /usr/include/qt5/QtConcurrent/qtconcurrentiteratekernel.h:255

#17 0x00007ffff44b5b2d in QtConcurrent::ThreadEngineBase::run (this=0x555557757f20) at qtconcurrentthreadengine.cpp:302
#18 0x00007ffff59c8d52 in QThreadPoolThread::run (this=0x555556198b10) at thread/qthreadpool.cpp:100
#19 0x00007ffff59c5a61 in QThreadPrivate::start (arg=0x555556198b10) at thread/qthread_unix.cpp:329
#20 0x00007ffff546c717 in start_thread (arg=<optimized out>) at pthread_create.c:435
#21 0x00007ffff54f018c in clone3 () from /lib64/libc.so.6
(

no task description

The dark theme for Linux is broken:

- Some icons have dark background (expected) and black foreground color (that should be replaced by white of very light gray)
- Some icons have light background (not cohesive with the theme).
- The command history shows dark blue font on dark gray background.
- The grid’s ruler shows black font over dark background for the numbers.
- The icons folder is missing in the GitHub repository, but other themes have that folder.
- The general icons (open, save, and so on) are not dark theme friendly. A better approach for maybe all the themes would be to use something like the breeze icons pack for LibreOffice, and it will have the added benefit of making the app look more modern.

The icons issue is the biggest problem. They should probably replace the black color for white or very light gray. Even the red accent color is not ideal for dark themes, is not the main issue.

Attached is an image that show the problems and another that shows LibreOffice with the Dark Breeze theme for reference.

I’m using QCAD Community Edition 3.27.7 on Windows 11.

When I started my drawing, I was able to change the size scale factor of (existing) dimensions using “Edit/Drawing Preferences/Dimension/Dimension Settings/Size scale factor”. However, suddenly this feature stopped working and now I cannot switch the dimension scale factor any longer.

I used this feature to be able to adapt the scale factor of the dimensions when printing in different scales.
I.e. all my drawings are in “original” size but when it comes to printing, I print some parts in scale 1:2 (in which case I used to set the size scale factor of the dimensions to 2) and some parts in scale 1:10 (in which case I used to set the scale factor of the dimensions to 10). Using this procedure, the dimensions have the same size (font size, arrow size, gaps etc.) on both drawings.

I have attached the drawing, that shows the described issues.

Hi Andrew,

Creating G-code for cnc-laser, the laser-tool can not be correctly set at all.

Attached a laser tool proposal

Add SPx; with x being pen number from 1-8.

TODO:
- Which color corresponds to which pen number?
- What if there are more than 8 colors in a DXF files?

Hi Andrew,

Still working with and on CAM HPGL for the HP7580 pen plotter.

I have added a penplotter test drawing, that might be used for testing en callibrating plotter and pens. You may add it to the Examples-directory.

QCAD has a lot of trouble creating toolpaths and exports. Much too often it shuts itself down, or gets stalled. Why? I am not sure.

Hi Andrew

QCAD/CAM misses a hpgl.plt import. If gerber and G-code can, so should plt.

Hi Andrew

A request for adding some fields to the toolpath

Hi Andrew,

Still working on creating HPGL.PLT toolpaths for the HP7580 pen plotter. QCAD has some trouble creating toolpaths. Too often it shuts itself down, or the PC gets stalled.

Recreating the same error however is possible

Hallo Andrew,

I am still busy on the never ending G-code story. Doing so I wrote a small Post Processor Tutorial for all those nerds who wants to write their own. If you like it you might add it to QCAD. However, since English is not my native tongue I suggest checking it would be wise.

Meanwhile I have downloaded the source code, and could not find the CAM’s Drill-path-script. I am now using a negative Drill Cut Depth to set a Laser Dwell time, were as a field “Dwell Time (in seconds)” in the Drill-path would be more appropiate. Is this script open source available or is it part of ‘closed part’ of QCAD?

Hallo Andrew,

Still busy on the never ending G-code story. Urgently needed the very common Traverse Toolpath.

Example added as pdf.

Greetings

Hallo Andrew,

Still busy on the never ending G-code story. Urgently needed the very handy G-code Block Toolpath. This ‘toolpath’ also solves a lot of “editing requests”.

Hallo Andrew

It would be more than conveniant, defining the drilling locations of the drill toolpath, by selecting a circle’s center point.

Hallo Andrew,

testing the drill toolpath I used single point markers.

In 3D simulation the tool drills the toolpath AND uses the drill as a mill.

Cam Export and generated G-code is not effected.

Hallo Andrew,

I have revised the PWM Post Processor to Revision D.

Hallo Andrew,

Found a bug in the 3D Simulator execution

I’m often in the situation that I have to select for nesting 50+ sheets. Currently is only a Shift + left mouse click selection possible. It would be nice if QCAD/CAM could get for the nesting / sheet selection additional a mouse rectangle area selection.

Currently if I position one Tab (KT) to stacked profiles QCADCAM will use it on ALL in Z matching profiles. Practically in most cases would be to use tabs only on the lowest profile.

It would be nice to have some kind of control on which profile a tab has to be used.

Andrew,

At present QCAD/CAM the tool drop-down box displays tool number and diameter between brackets.

It would be more appropriate to display if it is a mill or a drill and/or the description of such.
In a further stage of development ball-nose ... Conical ... And so on.

I have several specialized mills with the same diameter.
End-mills, roughing mills, routing mills, face mills ....

Tools 1(ø6mm) or 2(ø6mm) don’t say much if tool 1 is a side-mill and tool 2 is a high speed drill for metal.

Related forum topic:
https://www.qcad.org/rsforum/viewtopic.php?f=31&t=10722

Regards,
CVH

Andrew,

I know that GCodeMM.js and GCodeIN.js are generic postprocessors.
Mostly used as base for other or custom postprocessor.

The distinct nature is pretty clear from the filename and the suffix in the display name.
Another distinct nature is that they include this.unit = RS.Millimeter / RS.Inch intended for the CAM side.

Why don’t they include at least a G20/21 in a generic header?

There are several more specific postprocessors where I miss these G-codes for the measurement system.

True, if they are not supported, no error messages would occur when omitted.
The danger is that users rely on build in postprocessors hoping that it matches with the default measurement system of their setup.

IMHO it is safer to trigger an instruction fault before attempting to execute a wrong motion.
As fail-save as possible should always be the goal.

Regards,
CVH

Andrew,

Please refer to related forum topic:
https://www.qcad.org/rsforum/viewtopic.php?f=74&t=10724#p44206

An eighth circle with radius 8 Lead In/Out relates to nothing in the actual exported cutter trajectory.
Nor does it with the edge being cut.

Proper examples and a comparison with ‘Extension’ type Lead In/Out included.
Conclusion: IMHO connecting the cutter trajectory and edge being cut is wrong.

It looks a lot like turning on Cutter Compensation (G41/42) while the motion is circular.
But that is uncommon because most controllers can not cope with this motion.
One can increase the offset gradually along a straight pre-entry segment for turning on G41/42 but not along a circular path.
Also see snippet:
- Pre-entry C→B turning on G41
- Circular Lead In B→A

Regards,
CVH

If you spot an error in the translated user interface of QCAD, please add a comment to this task or submit your translation at http://translate.qcad.org.
Thank you for your help!

Wenn Sie einen Fehler in der übersetzten Benutzeroberfläche von QCAD erkennen, fügen Sie bitte einen Kommentar zu diesem Report hinzu oder geben Sie Ihre Übersetzung ein unter http://translate.qcad.org.
Vielen Dank für Ihre Hilfe!

Si vous remarquez une erreur dans l’interface utilisateur traduite de QCAD, veuillez ajouter un commentaire à cette tâche ou soumettre votre traduction à http://translate.qcad.org.
Merci pour votre aide!

Si detecta un error en la interfaz de usuario traducida de QCAD, añada un comentario a esta tarea o envíe su traducción a http://translate.qcad.org.
Gracias por tu ayuda!

Se si rileva un errore nell’interfaccia utente tradotta di QCAD, si prega di aggiungere un commento a questo compito o di inviare la traduzione a http://translate.qcad.org.
Obrigado por sua ajuda!

Se você detectar um erro na interface de usuário traduzida do QCAD, adicione um comentário a esta tarefa ou envie sua tradução para http://translate.qcad.org.
Obrigado pela sua ajuda!

Als u een fout ziet in de vertaalde gebruikersinterface van QCAD, voeg dan een opmerking toe aan deze taak of stuur uw vertaling naar http://translate.qcad.org.
Bedankt voor uw hulp!

Include RPolyline.getLeftRightOutline() method in class_r_polyline.html

In use since 11 Sept 2020

CVH

Hi!

A friendly request to add an option to disable hatch rendering on “dwg2bmp” conversions.

Depending on the nature of the conversion and the density of the hatch, this may render unintelligible images (see attachments). The option could look like “-t, -nohatch” to indicate hatches should be hidden before rendering. This could potentially become an option too for “dwg2svg” or “dwg2pdf.”

Amazing product, thank you so much!

Andrew,

It took me a while to find the source of a certain freak bug I encountered.
I used the RLine.isParallel(RLine) as a test for knowing if line segments were parallel or not.

Included below is script code that mimics the functionally of isParallel().

As far as I know isParallel() is nowhere used in the QCAD open source.
Textual only found in RLine.cpp & .h or under: opennurbs, ecmaapi\generated and ecmagenerator\src.

// Example:
// RShape1: RLine(RShape(address: "0xcd70e28"), startPoint: "RVector(969.219858, -171.914894, 0.000000, 1)", endPoint: "RVector(1010.000000, -140.000000, 0.000000, 1)")
// RShape2: RLine(RShape(address: "0x7659770"), startPoint: "RVector(969.219858, -171.914894, 0.000000, 1)", endPoint: "RVector(930.000000, -340.000000, 0.000000, 1)")
----
var aShape1Angle = shape1.getAngle();    // =0.6640461628266838 rad
var aShape2Angle = shape2.getAngle();    // =4.483157047107694 rad
----
// RLine::isParallel(RLine) -> aTest1 || aTest2
var aTest1 = RMath.isSameDirection(aShape1Angle, aShape2Angle);              // =false
var aTest2 = RMath.isSameDirection(aShape1Angle, aShape2Angle + Math.PI);    // =true
var aTestOr = aTest1 || aTest2;                                              // =>TRUE !?
----
// # BUG # RShape1 is considered as parallel with RShape2
----
// RMath::isSameDirection(dir1, dir2, tol) ... tol = RS.AngleTolerance = 1e-9
// for aTest1 -> ax1Test1 || ax1Test2
var ax1Dif = Math.abs(aShape1Angle - aShape2Angle);    // =3.8191108842810104 rad
var ax1Test1 = ax1Dif < 1e-9;                          // =false
var ax1Test2 = ax1Dif > 2*Math.PI - 1e-9;              // =false
var ax1TestOr = ax1Test1 || ax1Test2;                  // =>FALSE
----
// for aTest2 -> ax2Test1 || ax2Test2
var ax2Dif = Math.abs(aShape1Angle - (aShape2Angle + Math.PI));    // =6.9607035378708035 rad
var ax2Test1 = ax2Dif < 1e-9;                                      // =false
var ax2Test2 = ax2Dif > 2*Math.PI - 1e-9;                          // =true
var ax1TestOr = ax1Test1 || ax1Test2;                              // =>TRUE
----
// # BUG # The second test of the second isSameDirection() test returns true because ax2Dif is over 2pi

Regards,
CVH

implement

it would be ideal to be able to have the option to autohide the side panel to increase the visible drawing space when working on a small screen.

The modify stretch tool wants first and second corner, start and end point, then starts afresh. When I turn on restrict horizontally eg to align two points between start and end, the restriction sticks and I have to call restrict none, to be able to perform the next iteration, set the first corner then.

So, in the quest for a comfortable user interface, it was nice, if the modify stretch first/second corners parameter setting was not affected by current restrict/ortho etc. settings. Actually, that does not make any sense at all anyways, does it, a rectangle is defined by two degrees of freedom, isnt it?

See:
http://www.ribbonsoft.com/rsforum/viewtopic.php?t=1867

Apparently this was possible in QCAD 2 due to the default behavior of Qt.

Hi,

in QCAD3 RC2 points were printed as crosses, in QCAD3 RC4 they are printed as (very little) points. I think this isn’t a bug but a feature.

It would be nice if one could change this behaviour / select the symbol of points.

Best regards - Stefan

This is a double post of http://www.ribbonsoft.com/rsforum/viewtopic.php?p=5870#5870 as suggested there.

I would like to get a shortkey like ‘+’ to rotate text at 90° clockwise.

Nach einigen Überraschungen ....

Es ist möglich Layer in nicht eingefügten oder unsichtbar geschalteten Library Items unbemerkt zu löschen ....

Fallbeispiel 1:
Ich arbeite an einer Zeichnung die u.a. den Layer “Gelbe Linie” benutzt.
Ich füge ein Library Item ein was auch einen Layer “Gelbe Linie” hat.
Ich lösche - aus welchen Gründen auch immer - in der Zeichnung das Library Item weil ich es erst später wieder verwenden will.
In der Blocklist ist es natürlich immer noch verfügbar.
In der Zeichnung lösche ich den Layer “Gelbe Linie” da ich diesen nicht brauche brauche - habe aber natürlich nicht im Kopf welche Layer in meinen Blocks verwendet wurden.
Nach einiger Zeit will ich den Block (den aus der Library) wieder einfügen - dieser ist nun aber unbrauchbar da der Inhalt welcher auf dem Layer “gelbe Linie” war fehlt.
Das Library Item neu aus Library laden um das bereits existierende zu reparieren scheitert da das erste nicht überschrieben werden kann. Ich muss den ersten Block löschen um den neuen benutzen zu können.

Fallbeispiel 2:
Da das selbe (löschen der Layer) auch passieren kann bei unsichtbar geschalteten Blöcken kann es dazu führen das ich zig bereits positionierte Blöcke zerstöre und neu platzieren muss um meine Zeichnung zu reparieren.

Fallbeispiel 3:
Ich sehe in meiner Zeichnung einen Layer “Gelbe Linie”. Weiß nicht was das ist - schalte alle Layer unsichtbar außer “Gelbe Linie”. Klicke auf “Auto Zoom” um zu sehen was den auf “Gelbe Linie” ist. Finde nichts = also leer! Lösche Layer “Gelbe Linie”. Der Layer wurde aber von einem im Moment nicht verwendeten Library Block verwendet. Es gibt keinen Hinweis das ich damit ein Library Item zerstören könnte ....

Lange Rede kurzer Sinn: Wäre es machbar/sinnvoll Layer in Blöcken nur löschen zu können wenn ich mich im Edit Modus der Blöcke befinde?

Since this is not supported by Qt anymore, this would likely have to be implemented from scratch.

Eine oft Hilfreiche Zeit/Klick sparende Erweiterung wäre eine “Total” Option bei dem “Lengthen” Tool.

Aktuell ist es mit dieser Funktion möglich ein Element zu verlängern oder zu verkürzen um den Amount X. Der Referenzpunkt (von welchem Ende) kann bestimmt werden.

Die Erweiterung die ich mir wünschen würde wäre auch ein “Total” um ein Element auf eine bestimmte Länge zu bringen ohne einen Taschenrechner benutzen zu müssen. Referenz (welches Ende oder Mitte) sollte (muss) dafür wählbar sein.

Die Funktion “Property editor” stellt bereits über die Geometry Eigenschaften die Möglichkeit zur Verfügung einen “Total” Wert zu manipulieren. Leider bin ich aber hierbei nicht in der Lage zu bestimmen welcher Element Referenzpunkt dafür benutzt werden soll. Könnte ich die Referenz wählen (welches Ende oder Mitte) wäre auch dies dann durchaus akzeptabel

To have a ‘clean up ' tool to:

- eradicate duplicate lines
- eradicate stray points
- remove empty layers
- remove unused blocks

Perhaps with an initial dialog which allows the user to choose what they want to clean up.

Input:

1. X axis min/max or choose line (?) or center (for polar functions)
2. function: y = f(x) / polar function: r = f(a)

Output:

1. function plot