Non-ASCII (two-stroke) characters

• Jun 26, 2017 - 20:20

Well, this might as well be extended to other character sets, for instance the Greek.
I sometimes need the characters ä, ö and ü, and I find it extremely cumbersome to be forced to use an editor to construct them (two keys) and then copy and paste. This is extra time consuming because after pasting, the character is no longer in the clipboard, so it has to be copied again.


Comments

Also, you mention a character not being in the clipbaord after pasting - that is only true for lyrics, and only if you try pasting the character as an entire syllable which not in edit mode, rather than pasting it within an syllable while in edit mode. This is intentional, as it allows you to copy and paste lyrics from a text editor one syllable at a time by simply copying the entire text and then pressing Ctrl+V repeatedly. It's a very useful time-saving feature.

In reply to by ingeva

Works fine for me in 2.1 under Windows. What version, what OS? Can you post a score and precise steps to reproduce the problem?

But I did misspeak about pasting multiple times working if in lyric edit mode. Not sure what I was thinking, but indeed, even when pasting a single character, it gets "eaten" in order to support this special method of copying entire lyrics.

In reply to by Marc Sabatella

I'm using a daily build of 2.1 on Linux Mint 18..2 Beta. It's about a month old. Maybe I should get a newer one. :)
We were both wrong. The method you described IS easier, but I fail to understand why I can't use the regular method that's used with all other programs. For instance, I type "ä" by typing "¨" (the double dots), then "a" - and of course the similar procedure with other accented characters. Selecting from a palette is clumsy whichever way you look at it, and should only be used as a last resort (if you don't know or find the two-click sequence).
If I copy lyrics that I have collected from somewhere else, I would love to be able to just add hyphens and other separators to the text, and copy all of it to the clipboard and paste it into the score with one click.

In reply to by ingeva

The method you describe is known as "dead keys" and needs OS / library support. Apparently some versions of the Qt libraries we depend on has issues with this on Linux specifically - see #104816: AppImage doesn't accept accented characters from keyboard using "dead keys". It might work to try a more recent version of Qt, but probably not *too* recent, as I don't think you can compile 2.1 against anything too new.

Pasting a lyric in one click would certainly be possible. i think it probably isn't because getting everything right is pretty error-prone, so chances are good you'll need to stop and fix something as you go.

In reply to by Marc Sabatella

I see that the two-character operation has been discussed extensively earlier. I didn't find it because of different terminology.
I don't think this has anything to do with missing OS support, since the two-key method I mention works just fine with all other text-editing software in the system. I mostly use Geany for editing, but also nano and xed, and LibreOffice for more elaborate documents. The two-key method works flawlessly in all of them.
The two-key method has not worked for me with any MS version, and I believe I've tried most versions since 1.x. Evidently, according to other comments, when the accented character is on a keyboard key, there's no problem. I'm not sure how the key codes are generated, but I assume they are just numbers that have to be translated into characters by software.

In reply to by Marc Sabatella

So you mean that the libraries only support some programs, or that there are more than one library or function, each with their own APIs, and MuseScore is not using the correct one?
Of course, with many chefs there's bound to be some chaos, but as programmers we should always attempt to follow the roads built by our predecessors, and not feel obligated to build/invent our own - unless, of course, they are much wider and faster, are great contibutors to the world and aspire to become the new standard, like HTML5 succeeds HTML4, and CSS3 succeeds CSS2.
What's peculiar about these two examples though, is that contructs from the older version are still working in the newer! Amazing, isn't it? :)

In reply to by ingeva

Let me step back a moment:

MuseScore uses a handful of such libraries, but the most important of these are those provided by Qt. These libraries handle lots of things for us, including the processing of keyboard input. The Qt libraries are designed to allow MuseScore to work the same on Windows, macOS, and Linux, and they themselves depend on the OS to provide some basic underlying functionality.

What appears to be happening is that the particular version of the Qt library used in MuseScore 2.1 is for whatever reason not giving us the input we might expect on certainly versions of Linux. Whether this is because Qt is not calling the underlying Linux routine correctly, or certain versions of Linux are not returning the correct result given the specific parameters Qt passes in, or what, I cannot say. Other programs are probably not using Qt, or are using a different version, or are using it differently, so you can't really draw specific conclusions just from the fact that other programs do handle this "dead key" input method on the same version of Linux.

So, we *do* folloow the roads built by our predecessors, but in this cases, one of the roads we are using appears to have a pothole on it. Later versions of Qt do appear to have fixed this pothole, but created others such that we cannot necessary just switch out a newer version of Qt and expect everything to be OK. So for now, we have to live with this unless someone finds a way to circumvent this particular pothole, which so far no one has managed to do.

Do you still have an unanswered question? Please log in first to post your question.