Impossible to write some special characters (Linux only)

[adrapereira]

The input doesn't allow some special characters to be written, like:

• à [ ` + a]
• é [ ' + e ]
• á [ ' + a ]
• ã [ ~ + a ]
• ó [ ' + o ]

But allows others like "ç".

The characters that can't be added are all combinations of two keys and can be added to the text area by other means (using Ctrl+V or setting the text content in the source code).

[JordanMartinez]

I don't know what keys (and their order) one has to press to get those characters to be inserted into a TextArea/TextField, but one way you could solve this is by customizing the behavior to account for this. If you're not familiar with how to do that, see the links in my second comment in #257 for such an example.

Just a heads up: the way to customize the behavior will change as Tomas wants to change the implementation to his experimental package in WellBehavedFX, but that still needs to be implemented.

This would also be worthy of a pull request.

[TomasMikula]

@adrapereira Can you confirm that what you are trying to do works with JavaFX's TextArea?

[adrapereira]

@JordanMartinez The way to insert those characters is in the issue description. For example, to input "ã" you first press the "~" key (and release) and then press the "a" key.

@TomasMikula Yes, I confirm that this works in JavaFX's TextArea.

[TomasMikula]

@adrapereira what keyboard layout are we talking about?

[adrapereira]

@TomasMikula The Portuguese keyboard layout (Portugal)

[TomasMikula]

Thanks. Just tried it on Mac with the RichText demo and it works for me.

[adrapereira]

I just tried in Windows and it worked, but it doesn't work in two different Ubuntu systems.

[njourdane]

Up, please. :-)

This issue is very inconvenient for our project since we are developping a text editor.

[njourdane]

It seems this is a JavaFX issue. When I run this application:

package sample;

import javafx.application.Application;
import javafx.scene.Scene;
import javafx.scene.control.Label;
import javafx.scene.layout.BorderPane;
import javafx.stage.Stage;

public class Main extends Application {

    @Override
    public void start(Stage primaryStage) throws Exception {
        BorderPane pane = new BorderPane();
        Label label = new Label("Type some text...");
        pane.setLeft(label);
        Scene scene = new Scene(pane, 200, 40);
        primaryStage.setScene(scene);
        primaryStage.show();
        scene.setOnKeyPressed(e -> label.setText("name: " + e.getCode().getName() + "\ntext: " + e.getText()));
    }

    public static void main(String[] args) {
        launch(args);
    }
}

... with a Linux (Ubuntu 16.04) and a french AZERTY keyboard, it display name = "UNDEFINED" and text = "" when I hit ^, and it is not possible to print letters like ë or ô.

fyi I reported this issue here.

[alesp]

This bug still exists in 0.7-M5. I tried with Slovenian and French keyboard layout.

Combinations with dead keys work well on Windows.

In Ubuntu, combinations work in JavaFX's TextArea, but don't work in RichTextFX's StyleClassedTextArea / CodeArea.

[JordanMartinez]

@alesp I tried this out on my machine (Linux Mint) where my Compose key is the right Alt key.

import javafx.application.Application;
import javafx.event.EventHandler;
import javafx.scene.Scene;
import javafx.scene.control.TextArea;
import javafx.scene.input.KeyCode;
import javafx.scene.input.KeyEvent;
import javafx.scene.layout.VBox;
import javafx.stage.Stage;
import org.fxmisc.richtext.InlineCssTextArea;

public class SpecialArea extends Application {

    @Override
    public void start(Stage primaryStage) throws Exception {
        InlineCssTextArea rtfxArea = new InlineCssTextArea();
        TextArea jfxArea = new TextArea();

        // output the column headers
        outputColumnHeaders();

        // setup listener
        EventHandler<KeyEvent> output = e -> {

            StringBuilder sb = new StringBuilder();
            String type = e.getEventType().toString();
            sb
                    .append(type.substring(4, type.length()))
                    .append("\t").append(e.getCharacter())
                    .append("\t").append(e.getCode())
                    .append("\t").append(e.getText())
                    .append("\t").append(e.isControlDown())
                    .append("\t").append(e.isShiftDown())
                    .append("\t").append(e.isAltDown())
                    .append("\t").append(e.isMetaDown())
                    .append("\t").append(e.isShortcutDown());
            System.out.println(sb.toString());
        };

        // add event filter
        rtfxArea.addEventFilter(KeyEvent.ANY, output);
        jfxArea.addEventFilter(KeyEvent.ANY, output);

        Scene scene = new Scene(new VBox(rtfxArea, jfxArea), 500, 500);
        // re-output headers on S and switch to other area
        scene.addEventHandler(KeyEvent.KEY_RELEASED, e -> {
            if (e.getCode() == KeyCode.S) {
                System.out.println("\n--- Switching to next area ---\n");
                outputColumnHeaders();
                if (rtfxArea.isFocused()) {
                    jfxArea.requestFocus();
                } else {
                    rtfxArea.requestFocus();
                }
                e.consume();
            }
        });
        primaryStage.setScene(scene);
        primaryStage.show();
    }

    private void outputColumnHeaders() {
        StringBuilder sb = new StringBuilder();
        sb.append("Event Type")
                .append("\tChar")
                .append("\tCode")
                .append("\tText")
                .append("\tCTRL")
                .append("\tSHIFT")
                .append("\tALT")
                .append("\tMETA")
                .append("\tSHORT");
        System.out.println(sb.toString());
    }
}

I pressed the Compose+`+A to output à, here's the output:

Type=KEY_PRESSED	Char= 	Code=UNDEFINED	Text=	CTRLDown=false	SHIFTDown=false	AltDown=false	METADown=false	SHORTDown=false
Type=KEY_PRESSED	Char= 	Code=BACK_QUOTE	Text=`	CTRLDown=false	SHIFTDown=false	AltDown=false	METADown=false	SHORTDown=false
Type=KEY_TYPED	        Char=`	Code=UNDEFINED	Text=	CTRLDown=false	SHIFTDown=false	AltDown=false	METADown=false	SHORTDown=false
Type=KEY_RELEASED	Char= 	Code=BACK_QUOTE	Text=`	CTRLDown=false	SHIFTDown=false	AltDown=false	METADown=false	SHORTDown=false
Type=KEY_PRESSED	Char= 	Code=A	        Text=a	CTRLDown=false	SHIFTDown=false	AltDown=false	METADown=false	SHORTDown=false
Type=KEY_TYPED	        Char=a	Code=UNDEFINED	Text=	CTRLDown=false	SHIFTDown=false	AltDown=false	METADown=false	SHORTDown=false
Type=KEY_RELEASED	Char= 	Code=A	        Text=a	CTRLDown=false	SHIFTDown=false	AltDown=false	METADown=false	SHORTDown=false
Type=KEY_RELEASED	Char= 	Code=UNDEFINED	Text=	CTRLDown=false	SHIFTDown=false	AltDown=false	METADown=false	SHORTDown=false

However, adding the same listeners to the TextArea produces this output:

Event Type	Char	    Code    	Text	CTRL	SHIFT	ALT	META	SHORT
RELEASED	BACK_QUOTE	    `	false	false	false	false	false
RELEASED	A	    a    	false	false	false	false	false
RELEASED	UNDEFINED		false	false	false	false	false

I can only assume that something is occurring in TextInputControl because of com.sun-package related items to which RTFX does not have access.

[JordanMartinez]

Also the person who responded to @roipoussiere's report said it should be submitted on the JavaFX bug system. I've reported a bug via http://bugs.java.com/ and am waiting for it to be screened.

[njourdane]

Oh, I have already reported it here - JDK-8172104. ;)

[JordanMartinez]

Oh...

Well, it's also reported in JDK-8179526

[JordanMartinez]

The bug report that @roipoussiere opened was closed as a "non-issue." It seems this is a bug in glass. To resolve it, one will need to override the default behavior of RichTextFX to detect and handle these key sequences when it runs on Linux.

[Silveriomrs]

It still happens in Linux Mint 18.2 + BlueJ + Open JDK 8 or Oracle JDK 8
Very problematic to work with it in our university

[JordanMartinez]

What's the steps one goes through to type in such a character? Is it not the following?

• Press and release ~
• Press a vowel (e.g. a)
• Area inputs something like à

In other cases, one presses a compose key and then types in the sequences of characters, right?

• Press and release compose key
• Press and release a special key (e.g. ~)
• Press and release a
• Area inputs something like à

So, breaking this down into code, we have

• detect when the key sequence starts (e.g. user presses a special key / compose key)
• detect when the next letter is pressed
  • if nothing else is inserted for some amount of time (e.g. 500 ms), then cancel the sequence code
• convert the sequence into a single character (e.g. ~ + a = à)
• insert that letter into the area

I don't think this should be supported by default in the main area as not every user will require these things and they may actually want the ~ character to appear. Rather, it should be implemented in the end-product (say an application) that either determines how this works or allows the user to specify what is the compose key that must be pressed before the key sequence detection code starts to run.

However, if someone wants to write the code for this as a PR, it could be stored in the utils package, allowing a developer who did need such a thing to quickly add it to their code. This should satisfy both parties: the one that wants easy support for this feature and the one that might see this as a bug.

[Silveriomrs]

It happens also in Spanish layout,
What is actually a big problem, into some IDE editor for coding, comments, etc.

Not possible at all to type á,é,í,ó or ú for example.

Already some the team of BlueJ know this issue, nothing they could do nowadays cause it doesn't depend on them.

[JordanMartinez]

I'm sure it's a big problem for a code editor. However, I am not using this code for that purpose and currently have no reason to invest my time and energy into adding that support.

I have shown what I think could be done to resolve the issue. If the BlueJ team really does need it, they can work with me to contribute that code to this project or add support for that themselves by overriding the default behavior via WellBehavedFX. In my mind, it seems that there is something they can do. However, I don't know whether the issue is a high enough priority to them to invest their time and energy into resolving it, whether in their own code or in collaboration with RichTextFX.

[davmac314]

I'm one of the BlueJ developers. It looks like JDK-8172867 is responsible for the problem ultimately, if I understand correctly. I don't think we'd want to try and manually convert multiple keys to individual accented characters ourselves, since it is complex and difficult to do so and would probably need to be done differently for different keyboard layouts and languages.

I think ultimately that the JDK bug needs to be fixed and then, hopefully, the problem just goes away.

[JordanMartinez]

Agreed. And I apologize for my earlier comment. Rereading it now, it sounds like I could have responded in a better way. I don't think I realized the full implications of what my approach would entail.

[davmac314]

Agreed. And I apologize for my earlier comment.

No offence was taken. Thanks.