native-dialog-rs
native-dialog-rs copied to clipboard
Dialog box text formatted incorrectly?
So I tried this out on KDE on Wayland and doing a basic message dialog no matter what I put in for the message it's malformed:

message code
MessageDialog::new()
.set_type(MessageType::Error)
.set_title("Fatal Error")
.set_text(msg)
.show_alert()
.unwrap();
I'm having this error too.
I think the issue might be here:
https://github.com/balthild/native-dialog-rs/blob/d2ddd443f8c01e92dc22cc8132159c1b9598eaca/src/dialog_impl/gnu/message.rs#L56
/// See https://github.com/qt/qtbase/blob/2e2f1e2/src/gui/text/qtextdocument.cpp#L166
fn convert_qt_text_document(text: &str) -> String {
text.replace('&', "&")
.replace('<', "<")
.replace('>', ">")
.replace('"', """)
.replace('\n', "<br>")
.replace(' ', " ")
.replace('\t', " ")
}
Perhaps removing that method would do the trick? It doesn't seem to be necessary in Rust.
I think the issue might be here:
https://github.com/balthild/native-dialog-rs/blob/d2ddd443f8c01e92dc22cc8132159c1b9598eaca/src/dialog_impl/gnu/message.rs#L56
/// See https://github.com/qt/qtbase/blob/2e2f1e2/src/gui/text/qtextdocument.cpp#L166 fn convert_qt_text_document(text: &str) -> String { text.replace('&', "&") .replace('<', "<") .replace('>', ">") .replace('"', """) .replace('\n', "<br>") .replace(' ', " ") .replace('\t', " ") }Perhaps removing that method would do the trick? It doesn't seem to be necessary in Rust.
Another person mentioned in a pull request that it seems kdialog does not use this formatting anymore. Upon removing this function call yes I can confirm it solved the issue for me.
Hopefully the author of this library is still actively maintaining it and sees the PR.
I made some changes to include support for customizing the yes/no labels in KDialog.
I'll send a PR later today for that.
Hello! I'm trying to confirm where and when kdialog changed its behavior so that I could escape the text or not for different versions of kdialog. However, I find strangely that the behavior should have not been changed.
The text preprocessing function in kdialog does almost nothing (https://github.com/KDE/kdialog/blame/master/src/utils.cpp#L46), the message box is kdialog is just a KMessageBox under the hood (https://github.com/KDE/kdialog/blame/master/src/kdialog.cpp#L515), and KMessageBox uses QLabel to display the text (https://github.com/KDE/kwidgetsaddons/blame/master/src/kmessagebox.cpp#L219) - all these code remains unchanged in recent years, as git blame shows. It is really strange that the behavior is not consistent.
I'm still trying to figure it out...
Hello! I'm trying to confirm where and when kdialog changed its behavior so that I could escape the text or not for different versions of
kdialog. However, I find strangely that the behavior should have not been changed.The text preprocessing function in
kdialogdoes almost nothing (https://github.com/KDE/kdialog/blame/master/src/utils.cpp#L46), the message box iskdialogis just aKMessageBoxunder the hood (https://github.com/KDE/kdialog/blame/master/src/kdialog.cpp#L515), andKMessageBoxusesQLabelto display the text (https://github.com/KDE/kwidgetsaddons/blame/master/src/kmessagebox.cpp#L219) - all these code remains unchanged in recent years, asgit blameshows. It is really strange that the behavior is not consistent.I'm still trying to figure it out...
Do you remember roughly which version or when kdialog did have that behavior?
Do you remember roughly which version or when kdialog did have that behavior?
Yes. In fact, I have a Ubuntu 20.04 VM now (thankfully I didn't delete it), and the kdialog in it is 19.12.3.
Do you remember roughly which version or when kdialog did have that behavior?
Yes. In fact, I have a Ubuntu 20.04 VM now (thankfully I didn't delete it), and the kdialog in it is
19.12.3.
What version of Qt is it running? and it looks like its KDE no?
Edit: Moreover, do we want to bother supporting older versions or tell users that they'll have to use say version 22.x.x (22 is the major version I'm running). Depending on how old it is it might not be worth the time investment to figure out which version this was changed in.
Yes, it's KDE.
KDE Plasma: 5.18.8 KDE Framework: 5.68.0 Qt: 5.12.8
Edit: Moreover, do we want to bother supporting older versions or tell users that they'll have to use say version 22.x.x (22 is the major version I'm running). Depending on how old it is it might not be worth the time investment to figure out which version this was changed in.
It should be OK to just remove the escape now, and add it back after figuring it out.
Also, I think I'd better ask some KDE devs...
Edit: Moreover, do we want to bother supporting older versions or tell users that they'll have to use say version 22.x.x (22 is the major version I'm running). Depending on how old it is it might not be worth the time investment to figure out which version this was changed in.
It should be OK to just remove the escape now, and add it back after figuring it out.
Also, I think I'd better ask some KDE devs...
I agree, however, it should be noted that some formatting does still work. For example bold still works just fine.
I also find that < and > still work. They should be escaped too, as the API of the crate is designed to display the text as-is and don't expect <> to become HTML tags.
I also find that
<and>still work. They should be escaped too, as the API of the crate is designed to display the text as-is and don't expect<>to become HTML tags.
All this formatting makes me wonder if we should make our own formatting system of some kind and convert it on a per-platform basis.
Edit: Moreover, do we want to bother supporting older versions or tell users that they'll have to use say version 22.x.x (22 is the major version I'm running). Depending on how old it is it might not be worth the time investment to figure out which version this was changed in.
It should be OK to just remove the escape now, and add it back after figuring it out.
Also, I think I'd better ask some KDE devs...
Have you been able to get in contact with KDE devs about which version this might be appearing in?
I fired a post on the KDE fourm just now. Hope there would be devs see and answer it.
I fired a post on the KDE fourm just now. Hope there would be devs see and answer it.
it appears that's the wrong place for the question, as their forums have since moved to https://discuss.kde.org/
edit: hmm, nevermind, it seems that announcement is quite new
I fired a post on the KDE fourm just now. Hope there would be devs see and answer it.
have you been able to get an answer yet? I tried to check the discussion myself but it appears I don't have access to it as of late.
No. Nobody has answered yet.
https://forum.kde.org/viewtopic.php%3Ff=225&t=177742.html
No. Nobody has answered yet.
https://forum.kde.org/viewtopic.php%3Ff=225&t=177742.html
it might be better than to ship it with the patch just for versions <=19 and if users who use 20/21 run into issues they raise a bug report and it gets patched accordingly then.
Fine. I have published 0.6.4 just now.
I posted a question on the new KDE forum, and a KDE dev pointed out that this change might be caused by Qt 5 -> 6 upgrade.
Also, If there's <html><body>...</html></body> surronding, the markups take effect again.
https://discuss.kde.org/t/documentation-about-the-xml-entity-escape-used-by-kdialog/6652/2
I just ran into this. Adding some info in case it helps:
I reproduced it using kdialog 19.12.3 on Ubuntu 20.04.3 with GNOME 3.36.8. I also got a report about this from someone using kdialog 24.02.1 onOpenSUSE Tumbleweed.
To reproduce, I modified the first tour example message to add \n\nAnother line, then run XDG_CURRENT_DESKTOP=KDE cargo run --example tour.
| version | commit | output |
|---|---|---|
| 0.7.0 | 4b0b159 | |
| 0.6.4 | dcb7930 | |
| 0.6.3 | c874958 |

