Single-Line Text Tool breaks numeric input to the Command Line

[DeliveryFry]

Here's the next most annoying issue I have with LC off my List of Annoying Annoyances. It's an old one. I've been putting up with it since possibly even before the 2.1.x series, and sadly, I can still reproduce it with the latest AppImage. I'm amazed I couldn't find an existing report for it.

Expected behavior

So, say you're using the single-line text tool. You plop down a few labels here and there at various rotation angles and text sizes. Maybe you've even changed your font choice along the way.

Once you've labelled everything to your satisfaction or requirements you would expect to continue on with the next step(s) of your project, except…

Observed behavior

…now the command line has completely stopped accepting numeric input. It still takes alpha characters as commands just fine, but appears to outright ignore their parameters.

Say you need to place a new parallel line 50 units away from another, so you pa for parallel followed by 50 to satisfy the command's request to "Specify Distance", but:

Unknown command? What the…?

Grrr! Fine. Forget that for now. Let's move some entity or block instead.

You mouse click on an entity to select it. Then type mv at the command line. So far so good. You want to shift this entity, say, 10 units to the right. In my own workflow, I'm a big fan of hammering absolute coordinates into the command line, especially for a simple adjustment like this. So all you need to do is input 0,0 followed by 10,0 to bring up the Move/Copy dialog. It's completely straight forward… Instead, this happens:

You can keep entering 0,0 (or any other coordinates) all you want, but LC will never stop asking you to "Specify reference point".

You now notice that whatever tool you try to use or action you try to take, the command line will refuse and/or ignore all numeric input.

Steps to reproduce (much revised and greatly clarified)

This bug is triggered by "nesting" one invocation of the text command inside another previously active one at the command line. I haven't been truly clear about that prior to this edit. Trying to reproduce this bug using only the mouse won't (as far as I can tell) trigger it. I don't know if there's a better or proper term for "nesting" in this context, so I'm metaphorically comparing the action to coding loops within loops within loops…

So here we go: Start a new drawing and run txt;txt in your command line (seriously, after all the hair I've pulled out over this, that's all there is to it).

The text dialog will pop up. Hit OK to dismiss it (no other action is required). Surprise! You're then presented with a second dialog from the other invocation. Dismiss this one with OK as well. You don't even need to place any text. Just [ESC] (twice of course) out of the nested invocations so the prompt no longer reads "Specify insertion point".

And that's my newly patented Insta-Matic Bug Trigger™. I can practically guarantee (100% or your money back) that your command line is now borked in just the way I described above.

To test if this really is the case, just go through the same motions, all at the command line, as I've described above: a bit of pa here and a mv there — or heck, try to place a circle by keying in its center.

Once the bug has kicked in, the only way I've ever found around it is to save my drawing, close it, and reopen it. LC itself does not need to be restarted in between. After the drawing is reopened, the command line will work okay again.

It may be meaningful to add that this bug will also trigger when editing a block from within a parent drawing. If the bug triggers while adding text to that block, the command line of the underlying parent drawing remains unaffected, suggesting the bug is always confined to the window instance (sub-process or whatever you guys call it) the bug was triggered within. Closing the block and then reopening it for editing again provides you with a restored, functioning command line the same way closing and reopening the parent drawing would.

Operating System and LibreCAD version info

My Linux distro is Mageia 8 (x86_64) and I'm using Plasma 5 (KDE Frameworks 5.76.0 with Qt 5.15.2) as my desktop.

This bug report was produced against LibreCAD-2.2.0-rc3-55-g12dc3ea1-x86_64.AppImage

[DeliveryFry]

Drat! I can still reproduce this bug with my distro's shiny new 2.2.0-rc4 build. But triggering it seems to have become harder. That or I'm doing something differently and evading it without realizing.

This bug drives me nuts! I wish I could figure out some way of demonstrating it reliably…

Also, in case this is relevant or makes a difference for some reason, I always keep Keycode mode disabled.

[DeliveryFry]

Oh for crying out loud. I've found the reliable trigger to this bug, and it is as simple as changing the text content, and not the attributes that causes it. I don't know why I thought otherwise.

I'll edit the "Steps to reproduce" in my initial report to reflect this.

[lordofbikes]

I assume that single line text is rarely used, because the tool bar icon, which presumably most users use, triggers MText, which may be better tested and not causing the issue.

Playing around a bit, with your described steps, didn't trigger your issue for me yet. I recognized some strange behavior, some known, some new, but not exactly what you described. What is known, is that at some point the command line isn't focused by keyboard input anymore. Only CTRL-m brings back focus to command line then. This happens randomly for me, but I'm not a power user and I use the mouse or CTRL-m when it happens. And I don't remember if I ever used single line text, so this issue seems not depend on a single tool. New to me and different from your issue was, that entering coordinates for single line text didn't place the text while the mouse was outside the drawing area. Moving the mouse over the drawing area the same coordinates worked and placed the text where expected. This may be related with the preview not showing up when the mouse is outside.

It may be important for your issue which actions are done by keyboard input and which by mouse click. Maybe you can clarify your steps about that. Or try to catch the way to the issue with a screencast?

Anyhow, hunting such randomly appearing bugs can become tedious. But from programmers view, those effects seems somehow related and to find and fix one cause can solve other issues too or lead to places where they are hidden yet.

[DeliveryFry]

Well, I've updated the "Steps" and it's got to be the act of "nesting" one text call inside another that's causing this. (I feel 99% sure about this now.)

I assume that single line text is rarely used…

I seem to recall reading a discussion (here or elsewhere?) a few years back where text was being considered for complete deprication in favor of mtext. But a recent look through the current LC manual seems to suggest otherwise. Am I misremembering or misunderstanding?

Anyway, I prefer the humble text unless I actually need multiple lines, and I recall the manual entry stating that it does posses a few advantages over mtext.

What is known, is that at some point the command line isn't focused by keyboard input anymore. Only CTRL-m brings back focus to command line then.

Yes, THIS! I've been experiencing that for ages and gotten so used to it, I hit ^M habitually. By contrast to your workflow, I'm a "chronic" keyboard user and try to avoid using the mouse as much as possible.

New to me and different from your issue was, that entering coordinates for single line text didn't place the text while the mouse was outside the drawing area. Moving the mouse over the drawing area the same coordinates worked and placed the text where expected. This may be related with the preview not showing up when the mouse is outside.

That's something I've never noticed and will have to try. I do tend to use the mouse to place the text. Plopping it at the midpoint of a temporary line or an intersection where X-marks the spot, for example.

It may be important for your issue which actions are done by keyboard input and which by mouse click. Maybe you can clarify your steps about that. Or try to catch the way to the issue with a screencast?

I've never tried making a screencast before. But anyway, now that I'm confident I've figured out the actual trigger, I've greatly shortened and simplified the "Steps to reproduce". The cause isn't nearly as convoluted as I'd thought. I'm not sure why I was leading myself down the garden path.

Anyhow, hunting such randomly appearing bugs can become tedious. But from programmers view, those effects seems somehow related and to find and fix one cause can solve other issues too or lead to places where they are hidden yet.

If I'm right, and you can reproduce the bug as easily as I now can, then it's not random at all. And as far as related effects go, if I'm also right that this bug is triggered by "nesting" one text invocation inside another, then this bug may bear a relationship with the next bug down on my list — which, thankfully, is super consistent, easy to reproduce, and unlike this one, much simpler to explain.

[DeliveryFry]

Ha. Here's a funny story.

I just tried to confirm your observation about not being able to place text by keying in the coordinates while the mouse was outside the drawing area, but I cannot reproduce that. First I let my mouse cursor sit over the layer panel, then I set it at the top of LC's window frame. I can key in coordinates without problem no matter where my mouse is.

Anyway, with a newly started LC process I was able to trigger the bug within 5 seconds. I'm now 100% sure, it is the command "nesting" that does it.

[DeliveryFry]

After several hours of much needed sleep, I realized I still wasn't being as clear as I could've been in my report. Along the way, I discovered a one-stop, super-direct way of triggering the bug. I've revised and clarified the "Steps…" again. Please take another look at that section.

@fa201 : thanks for adding the "bug" label; now lets have someone add "reproducible". Eventually seeing this one fixed would make me tremendously happy.

[lordofbikes]

I racked my brain about what your lately mentioned nested text is and still couldn't reproduce this issue. Now your latest edit untied the Gordian knot. When I tried to follow your steps I triggered a new text command by menu and it seems that doesn't rise the issue. If I were a doctor and you say doing txt;txt hurts, I'd say then don't do txt;txt :rofl: Sorry, I couldn't resist.

Of course I don't think you are doing txt;txt intentionally. But basically that's exactly what happens. So you do:

1. issue txt by command line
2. fill in the text in the text window and hit ENTER or click OK
3. insert the text into the drawing, doesn't matter if only once or multiple times
4. when you want to change the text you issue again a txt command, while the previous text is still floating with the mouse
5. repeat at 2.

The issue happens at 4. There seems to be a difference in program flow between command line and menu action. Menu action seems to finalize the active txt command before the new is triggered. But command line seems to leave the active txt action unfinished when the new one is started.

With this knowledge the workaround, until this could be fixed, is easy. Before issuing a new txt command hit ESC to finalize the active txt action. This should avoid the issue.

[DeliveryFry]

Yes!!! "reproducible" Whoot! (why is there no :happy_dance: emoji?)

I racked my brain about what your lately mentioned nested text…

Yeah, sorry. That was totally my fault. After I got some sleep, I thought more about what you'd said the day before regarding mouse habits. Duh! Of course I'm conducting my business in an "old-fashioned", oddball, corner-case sort of way and needed to be clear(er) about that.

My defense for the way I operate is that my first introduction to CAD was back in the early '90s using CADKEY (on machines running MS-DOS 5.0). Back then I discovered hammering most everything directly into the command line was the best way to go. Compared to it, LibreCAD (and QCAD before it) feels comfortably familiar — only minus the 3D capabilities (which I rarely used anyway). I have next to zero experience/familiarity with anything AutoCAD.

If I were a doctor and you say doing txt;txt hurts, I'd say then don't do txt;txt rofl Sorry, I couldn't resist.

Doc, I'm tellin' ya, it was hurtin' real bad…

Of course I don't think you are doing txt;txt intentionally. But basically that's exactly what happens. So you do: 1-2-3-4-5…

Yes! Your 5-Step Process of Doom matches my "nested" text loop workflow exactly.

Since I rarely find myself needing to place only a single label in a drawing at a time, I've been falling headlong into this trap regularly. I'd even started pushing labeling everything and filling out my title blocks to the very end of a project in anticipation of this bug. Yeesh!

The issue happens at 4 […] command line seems to leave the active txt action unfinished when the new one is started.

Hmm. :thinking: Weird, because I always thought that was intentional.

With this knowledge the workaround, until this could be fixed, is easy. Before issuing a new txt command hit ESC to finalize the active txt action. This should avoid the issue.

Indeed. The workaround is obvious now that I've finally figured out what triggers it. I can't believe I've been letting this bite me in the a** for so many years. Especially since it bears so much resemblance to the next annoying bug on my list. And I've been working around that one with [ESC] for probably just as long as I've been experiencing this one.

As they both involve command nesting, the two bugs might be related, and the "unfinished action" situation you described is the same thing that leads to both. But at least that one doesn't break the command line, making that bug, by my own reckoning, significantly less annoying than this one.

That next report will land on your doorstep very soon.

[dxli]

This appears to be bad to me. I will try this one.

[lordofbikes]

As mentioned in #1549, there is a general discrepancy between command line interaction and menu (QAction) functionality and this spreads over all tool classes. #1577 is another example. Probably inherited classes have evolved different over time and new behavior has not been applied consistent to involved sub-classes in past.