Label text editor doesn't respect Justification

Create a Label, use setJustificationType( Justification::centred ), and allow editing.

Result: The label text is centered, but when the user clicks to edit the label, the resulting text editor is left justified, causing the text to jump to the left.

It would be desirable if, when entering edit mode, the text editor activated in such a way that the text did not visibly shift at all, to create the appearance that it is being changed in-place (i.e. displaying using the Label’s Justification).

In addition, if a Label is editable, but the editor is not active, the cursor should probably change to an I-beam to indicate that the text can be edited. And if you want to provide the option to pass the click that activated edit mode, on to the text editor, so that the insertion point can be set to the place where the user clicked to get into edit mode, hey I’m not going to hold that against you (but if you don’t do it, I won’t complain either).

1 Like

Yes, I know. But the TextEditor doesn’t handle justification yet, so I can’t change that at the moment (it’s on my to-do-list…)

Jules - I Imagine your to-do list is horrible. But I'm working on an app with someone where this would be nice.  Is it anywhere near the top of the to-do list yet? :) 

It's only the one-line case this is normally annoying for.

cheers!! Jim. 

Sorry, it's not an urgent one for me right now.. Obviously if you want to offer a suggested change that'd get things moving!

No worries.  

I may have a look later when I've lit the fire and have a glass of wine in my hand :) 

I see why this isn't simple. The way the Iterator object builds it up from the left isn't really encouraging justification.

It'd be easier to add SimpleTextEditor which ditched with most of the font/colour/multi-line code but offered Justification.  But I'm not sure that the easy path is the right solution. 

Going to have a look at how that Iterator is used and see if there's not another level of abstraction that'll sort it out. [... moderately long pause ...].

I think it'd be possible to add something like JustifyingIterator in as a wrapper over Iterator. It can deal with offsetting the horizontal axis and deal with adjusting indexToX type function calls.

Adding in an Iterator::getGlyphArrangement to replace Iterator::draw() gets me half of the way there.  I can then join the Glyphs on one line to a single GlyphArrangement and draw them so they look justified.  

I'm not sure how to handle vertical justification yet mind you ...

I'm leaning towards SimpleTextEditor :) 

Hey there @jimc
I understand this is a pretty old thread but I was just wondering if you found a solution that worked well for you? I am hitting a similar thing right now.

Many thanks! J

It got moved to a pile of ‘one day’ and since then our product roadmap grew and one day never happened.

If I understand the issue, I got rid of this problem a long time ago. It seems my “fix” was to add a line to Label::showEditor():

void Label::showEditor()
    if (editor == nullptr)
        editor.reset (createEditorComponent());
        editor->setSize (10, 10);
        addAndMakeVisible (editor.get());
        editor->setText (getText(), false);
        editor->setKeyboardType (keyboardType);
        editor->addListener (this);

        // makes the editor have the same justification as the label

        if (editor == nullptr) // may be deleted by a callback

        editor->setHighlightedRegion (Range<int> (0, textValue.toString().length()));


        editorShown (editor.get());

        enterModalState (false);

This keeps the Editor centered when the label is. The text may still shift slightly left, right, up or down depending on the font you are using. I then tweak its positioning in LookAndFeel::fillTextEditorBackground() by shifting the textArea with either textEditor.setIndents() or textArea.translate() (on the rectangle of the text area).

1 Like

Thanks for sharing this @stephenk I’ll give it a try!
@jimc Totally understand! Thanks for responding though :slight_smile:

Thanks. Would be great to get this officially fixed in JUCE. It just looks really unprofessional and subclassing every label or forking JUCE for this one little thing is hard to swallow.