Non-ASCII (two-stroke) characters
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
see: https://musescore.org/en/handbook/text-editing#symbols-and-special-char…
https://musescore.org/en/handbook/palette#custom-palettes
In reply to see: by Shoichi
This method is even more cumbersome.
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 Also, you mention a character by Marc Sabatella
Copying lyrics as described here never worked for me. Lyrics can be extracted from a score, but it can't be copied back, even with the correct separators added.
In reply to Copying lyrics as described 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 Works fine for me in 2.1 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 I'm using a daily build of 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 The method you describe is 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 I see that the two-character by ingeva
Not "missing" OS support, just a matter of the libraries apparently not supporting it on some OS's.
In reply to Not "missing" OS support, 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 So you mean that the 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.