search

godotengine / godot

Godot Engine – Multi-platform 2D and 3D game engine
https://godotengine.org
MIT License
90.54k stars 21.08k forks source link

TextEdit/LineEdit inconsistency when non-editable #97099

Open EmilyV99 opened 1 month ago

EmilyV99 commented 1 month ago

Tested versions

System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Mobile) - dedicated AMD Radeon RX 6600 (Advanced Micro Devices, Inc.; 32.0.11029.1008) - AMD Ryzen 5 3600 6-Core Processor (12 Threads)

Issue description

A TextEdit and LineEdit do not draw their StyleBoxes in the same way when editable = false. I would expect these to look visually more similar than they do. image

Steps to reproduce

  1. Create a TextEdit and a LineEdit next to each other.
  2. Uncheck editable for both
  3. Notice that the TextEdit is notably more solid-looking than the LineEdit

Minimal reproduction project (MRP)

mrp_textedit.zip

AThousandShips commented 1 month ago

This is because TextEdit draws both its normal and read-only styles when non-editable, but LineEdit draws only its read-only one, changing this would potentially break existing use though so it's something to discuss how to navigate and either fix or document

EmilyV99 commented 1 month ago

This is because TextEdit draws both its normal and read-only styles when non-editable, but LineEdit draws only its read-only one, changing this would potentially break existing use though so it's something to discuss how to navigate and either fix or document

Certianly something to be fixed. Could always offer a checkbox for the old behavior to keep existing uses working.

AThousandShips commented 1 month ago

That's what should be discussed, it's been this way since before 4.0 was released so it's very well established, it's not as trivial to just change IMO, or something that's necessarily broken

These are still pretty different classes and exact equivalence isn't necessarily guaranteed or expected

EmilyV99 commented 1 month ago

These are still pretty different classes and exact equivalence isn't necessarily guaranteed or expected

At the very least OptionButton works the same way as LineEdit, and offhand I would bet most other controls do as well. TextEdit acting this way is an outlier, and completely prevents the use case of wanting something to be more transparent when disabled; a use case I very much want to use, and therefore something that seems broken to me.

AThousandShips commented 1 month ago

But it doesn't have to be critical either way, but I'd say this is more proposal territory as this is by design and would break existing code unless done carefully and correctly, ~the standard theme uses the exact same style box for both and it's opaque~

But important to discuss and come to a solution that works for everyone

EmilyV99 commented 1 month ago

the standard theme uses the exact same style box for both and it's opaque

err, what? Is what I'm using not the standard theme somehow then, because it is definitely not opaque by default; thus how I even noticed this issue... (It is hard to notice without changing the color behind it, as it is a transparent color that is very similar to the default panel color, but it is still transparent; see the MRP / the screenshot I posted- that is default, except for a light-colored panel added behind the widgets)

AThousandShips commented 1 month ago

My bad it is in fact transparent, it was just declared elsewhere, I'd say the read-only style for LineEdit should be made opaque then

But for the specific side of how to draw this I'd say a proposal is the way to go

WhalesState commented 1 month ago

We don't have just this issue, we have a lot of issues since the c++ file has 8500 lines written by many contributers.

I will try to fix and clean the code as much as i can.