v1.3.1 and dbus use

[0323pin]

Hi,

NetBSD package maintainer here and long time (3 years) featherpad user.

As I understand from the ChangeLog, the application now uses dbus but, does not actually require it to function.

So, I'm guessing it will detect it's presence and use it when available. Will this always be the case or, should I consider making it a requirement at build time already now?

Thanks for any hints.

[tsujan]

Will this always be the case?

Yes. It was tested under macOS without D-Bus (Thanks to @shlyakpavel), and it shouldn't be different under NetBSD: If D-Bus exists, FeatherPad will have a single process; otherwise, each FeatherPad window will have its own process — nothing essential will be lost.

should I consider making it a requirement at build time already now?

You probably mean a runtime dependency. It isn't necessary (for the above-mentioned reason) but possible.

[0323pin]

Thanks!
I do have dbus on my system because it's a firefox dependency and I'm using LeftWM as my WM which requires a dbus session.
Yes, I meant a runtime dependency but, I won't do it if it's not needed.
Btw, I've already merged the update anyway :)
https://mail-index.netbsd.org/pkgsrc-changes/2022/08/04/msg257968.html

[tsujan]

Btw, I've already merged the update anyway

Thanks!

but, I won't do it if it's not needed.

No, it isn't essential.

In all my apps, I avoid backward-incompatible changes as far as possible. I don't remember a case, where backward incompatibility was needed. But I don't deny that it might be required in other apps — or even in my apps at some point.

[0323pin]

@tsujan keep-up the good work, thanks!

[tsujan]

Thanks for the kind words!

[0323pin]

@tsujan Out-of-topic here but, I thought I'd ask. Would you mind having a look at https://www.unitedbsd.com/d/888-qt-applications-cant-open-files-which-have-special-characters-in-their-name and linked question https://www.unitedbsd.com/d/606-keyboard-dead-keys-dont-work-in-qt-applications

Anyway to get featherpad to recognize special characters when used standalone?
Thought, I'd ask just in case I'm missing something obvious.

Thanks!

[tsujan]

That can't be related to FeatherPad, its standalone mode, or LXQt file dialog. It should be about something much more basic.

I don't know about *BSD, but in Linux, all file names are in UTF-8, which supports all possible characters in the world.

Of course, the font you use may not support all characters. For Korean, Japanese, Chinese and some other languages, you need appropriate fonts. Since I installed them a long time ago, I don't remember their names; sorry!

However, something fundamental may be missing or wrong in that system, because a simple text like "caffè" shouldn't make any trouble with any well-known font like DejaVu Sans. Actually, if the name was in Korean, Chinese, Japanese,..., it shouldn't make any trouble in file opening either; at most, in the absence of appropriate fonts, file names wouldn't be human-readable.

[0323pin]

Thank you!

[tsujan]

https://www.unitedbsd.com/d/606-keyboard-dead-keys-dont-work-in-qt-applications/ suggests that there's a general problem with Qt. Perhaps it's related to how Qt is compiled there (just a wild guess). Ping me if you find the cause; I got curious.

[0323pin]

Yes, I know. This is what I'm trying to understand since, Gtk-apps don't have this issue and recognize the characters.

[0323pin]

Btw, I've quoted your answers here on the forum.
Let me know if you don't want that and I'll remove it.

I have a feeling I need to dig deep to find out why, if I manage to find it 😞

[tsujan]

Because Qt has never had that problem here, and supposing that it happens anywhere Qt apps are used, logically, I think there are three possibilities: (1) Something may be wrong in Qt for BSD (if it exits at all); (2) It may be related to how Qt is compiled/used; or (3) The cause may be outside Qt but related to it.

If it doesn't happen everywhere Qt apps are used, then the problem is definitely outside Qt.

But my knowledge of BSD is next to zero; so, please don't be misled by my words!

Let me know if you don't want that and I'll remove it.

I have no problem with quotations at all.

[0323pin]

(2) It may be related to how Qt is compiled/used

Yes, it happens with all Qt apps, OP mentioned the same issue with strawberry, and your (2) is what I suspect. I did ask another NetBSD dev on that thread but, got nothing back. Quoting myself,

I've just added inputmethod/uim to the lxqt meta-package for now. I didn't look at it anyfurther but, one thing pops-up. Why is this not the case with Gtk?

I'll go through the Qt packages to see if I find something obvious in the compile options.

[0323pin]

@tsujan OP on the thread came back with the following observation,

It can't be a bug in FeatherPad specifically because I get the same with Strawberry. However it isn't a general issue with Qt programs either: PCManFM-Qt and qpdfview aren't affected.

Indeed, it's true 😕

pcmanfm-qt and featherpad file-chooser,

If I add the .pdf file extension is also recognized by xpdf file-chooser,

So, now I'm going with your option (3)

(3) The cause may be outside Qt but related to it.

But, this will make it harder to find the cause for it 😞
Now, I remember why I've just added uim input method to the LXQt meta-package.

EDIT: I'm only getting more confused, see the new posts on the thread, https://www.unitedbsd.com/d/888-qt-applications-cant-open-files-which-have-special-characters-in-their-name/11

[tsujan]

As you can see in the screenshots, both pcmanfm-qt and xpdf using the simple Qt file-dialog show the file with the special characters.
featherpad does not...

It's Qt's default file dialog, which is called by FeatherPad.

Yes, that's a mystery to me too: why doesn't Qt's default file dialog show "caffè" there? Of course, it does here.

[tsujan]

A screenshot:

[0323pin]

Yes, as mentioned it works on Void Linux also, both with xpdf and featherpad. On my machine it works with xpdf but not with featherpad 😩

It should be no difference, as it's the same file-dialog which is being used by both applications.

Just to be on the safe side here is the list of runtime dependencies I've specified for the build of the binary package,

.include "../../x11/qt5-qtbase/buildlink3.mk"
.include "../../x11/qt5-qtx11extras/buildlink3.mk"
.include "../../x11/qt5-qtsvg/buildlink3.mk"
.include "../../textproc/hunspell/buildlink3.mk"
.include "../../x11/libX11/buildlink3.mk"
.include "../../x11/libXext/buildlink3.mk"
.include "../../graphics/hicolor-icon-theme/buildlink3.mk"

Besides these, it has buildtime dependencies on pkg-config, qt5-qttools and cmake

[pengxingwei]

A screenshot:

Can you please tell me the name of lxqt theme and icon theme as shown in picture?

[tsujan]

...the name of lxqt theme and icon theme as shown in picture?

There's nothing specific to LXQt in the screenshot. The Qt style is a Kvantum theme (Kvantum Manager → Change/Delete Theme → Select a theme: → KvMojaveMixed1). The Icon set is Plataro. Both are DE-independent. The window decoration is BreezeEnhanced (for KWin, here used under LXQt).

[tsujan]

A very wild guess. Please ignore it if you feel it's misleading; I don't want to create more confusion, especially when I don't know anything about BSD.

In Linux, all file names are in UTF-8. Maybe, in BSD, they aren't. Maybe, when you name a file as "caffè" in BSD, it isn't in UTF-8 (unless you somehow tell BSD to make it so).

pcmanfm-qt and LXQt file dialog can deal with non-UTF-8 file names because they use GLib for file managemnet; Qt's default file dialog can't.

[rajeevvp]

EDIT: change define from 1 to -1 to match FreeBSD.

Pin, can you apply this patch and rebuild Qt5?

--- pkgsrc.orig/x11/qt5-qtbase/Makefile.common	2022-04-19 01:01:12.000000000 +0000
+++ pkgsrc/x11/qt5-qtbase/Makefile.common	2022-08-20 07:56:01.481446492 +0000
@@ -48,7 +48,7 @@
 CFLAGS+=		-Wno-register
 
 # wcstof(3) etc. is used in C++ code.
-CFLAGS.NetBSD+=		-D_NETBSD_SOURCE
+CFLAGS.NetBSD+=		-D_NETBSD_SOURCE -D_XOPEN_UNIX=-1
 
 # include/openssl/e_os2.h:283:25: error: '_Noreturn' does not name a type
 CXXFLAGS.SunOS+=	-D_Noreturn=""

NetBSD doesn't define _XOPEN_UNIX in its header (FreeBSD defines it as -1) and that definition is used in various places in the Qt5 source, including:

qtbase-everywhere-src-5.15.5/src/corelib/codecs/qtextcodec.cpp
qtbase-everywhere-src-5.15.5/src/corelib/codecs/qiconvcodec.cpp

where it is used to determine the currently active locale. Since that isn't defined, the code then plays guessing games with the opaque string returned by setlocale()--which is is highly system-dependent (even on Linux the results can vary wildly depending on which env. vars. are set)--and then falls back to using ISO 8859-1 as the default codeset.

As to whether NetBSD should define these _XOPEN_XXX constants in unistd.h like Linux and FreeBSD do, or whether the Qt code should be changed to check directly for the functions which it needs (eg. #ifdef HAVE_NL_LANGINFO after probing it via cmake etc.) instead of relying on proxies like _XOPEN_UNIX, I don't know. That's something you NetBSD folks can decide; my preference is for the latter.

[0323pin]

@rajeevvp yes, I can patch qtbase but not before Monday.

As to whether NetBSD should define these _XOPEN_XXX constants in unistd.h like Linux and FreeBSD do, ... I don't know. That's something you NetBSD folks can decide

Can you please open the discussion on the mailing lists? Probably in tech-pkg after I test the patch.

[0323pin]

@rajeevvp have you tested the patch yourself?

[0323pin]

@rajeevvp Ops, life came in between ... I won't have time before midweek, earliest. Sorry 😞

[rajeevvp]

have you tested the patch yourself?

Sorry, no, mate. Had stuff to do on the weekend myself. Will test in the next few days.

As https://wiki.qt.io/Strings_and_encodings_in_Qt recommends: "In your code use QStringLiteral / QString::fromUtf8() for all string literals...". That includes file paths.

That's part of the problem here. Converting filenames from UTF-8 is fine when displaying them in dialog boxes and error messages, etc., but, when passing to system calls filenames should be the original stuff got from the system. Otherwise, you get the program trying to open files literally named ???.ext depending on locale (this can be seen in the ktrace output above). Contrast with, say, vi (which ever flavour you prefer), which should open arbitrarily-encoded filenames and no matter what the user's own locale is set to.

Also note that all POSIX programs start in the C locale and stay in that locale until the program (or a library it calls) changes the settings with something like setlocale(LC_ALL, ""); (This sets up the program to use whatever locale stuff the user set it to via the LC_* env. vars, and is typically the first function call made by a locale-aware C program. I've tried to do this the C++/Qt way in the test patch in my previous post but the other bug seems to have got in the way of it working.)

[0323pin]

@tsujan Sometimes it takes longer than it should and in the meantime FeatherPad is Qt6 based but, @rajeevvp has found the issue,
https://www.unitedbsd.com/d/606-keyboard-dead-keys-dont-work-in-qt-applications/37

It turns out there's a path missing in our libxkbcommon package.

[tsujan]

It turns out there's a path missing in our libxkbcommon package.

Please also note that FeatherPad isn't limited to X11, although it has extra features under X11, which can't exist under Wayland (for now).

[0323pin]

It's fixed now.

As for Wayland, we have a very long way to go. There are simply too many Linux only things that need to be addressed.
I've tested Wayland on NetBSD a few years ago and it was far from daily drive ready.

[tsujan]

Although it makes no difference for FeatherPad which Wayland compositor is used, Wayland isn't a unified concept; your experience of it depends on which Wayland compositor you try. Also, during last years, many things have changed in those compositors that are based on wlroots. I recommend LabWC.

[0323pin]

Also, during last years, many things have changed in those compositors that are based on wlroots. I recommend LabWC.

Nothing based on wlroots will currently run on NetBSD. Only swc based compositors are supported.

[tsujan]

Nothing based on wlroots will currently run on NetBSD.

That's OK as far as FeatherPad is concerned; its X11 support will be continued indefinitely. I just wanted to share a part of my experience about Wayland.

[0323pin]

Appreciated. Even on Linux, I'm still running X11 only, so any insights into Wayland are welcome.

[tsujan]

Even on Linux, I'm still running X11 only

A wise choice, IMO.

I use Wayland because I need to do coding for and under it. I also test others' works on some Wayland compositors (mainly, LabWC, Wayfire and kwin_wayland).