Relation with Konsole?

[yan12125]

QTerminal is forked almost 7 years ago. There are quite a few bugs implemented/new features added in Konsole in the 7 years. It's annoying to backport patches. Here I have some ideas:

1. Backport necessary fixes and bring features from Konsole.
2. Re-fork Konsole
3. Upstream changes in QTerminal

The current approach is 1, yet personally I prefer 3. I don't like 1 as it sounds reinventing wheels. 2 will lead to the same situation after some time.

3 takes the most time I guess, but it's the real long-term solution in my opinion. It can be divided into several steps:

• Implement https://github.com/lxde/lxqt/wiki/KF5-usage-in-LXQt#qterminal
• Add an option in Konsole to build without KF5
• Really upstream changes in QTerminal

Any ideas?

[agaida]

i would prefer 3 to be true

[jleclanche]

I truly wish qterminal could use the konsole widget. qtermwidget is pretty awful at this point :( Lots and lots of issues with text rendering (especially cjk), bugs, memory leaks etc.

[yan12125]

Thanks. Many developers are thinking about the same thing :)

The first issue is that konsole uses KPty, which is a Tier 2 framework.

$ pactree -d 2 kpty
kpty
├─kcoreaddons
│ ├─qt5-base
│ └─shared-mime-info
├─ki18n
│ └─qt5-script
└─libutempter
  └─glibc

I remember that LXQt doesn't like KF5 components beyond Tier 1?

[jleclanche]

Yeah it's a bit much to ask to pull ki18n just for a terminal component. kcoreaddons I think we can live with if it's seriously used in kpty.

[yan12125]

Turns out that kcoreaddons is easier to drop. KUser is used for updating login records, and KProcess is necessary for functional tests only. On the other hand, KI18N uses gettext formats (*.po), which is quite different than Qt translations. (*.ts) I'm afraid that KDE won't accept patches that change from *.po to *.ts.

By the way, KDE translations are pulled from a server (?) whenever a new version is tagged. For example KDE/kpty@216c920

[jleclanche]

Why does the terminal widget need translations?

[yan12125]

It's used in error messages:

$ grep -r 'i18n('
src/kptydevice.cpp:            q->setErrorString(i18n("Error reading from PTY"));
src/kptydevice.cpp:        q->setErrorString(i18n("Error writing to PTY"));
src/kptydevice.cpp:            q->setErrorString(i18n("PTY operation timed out"));
src/kptydevice.cpp:        setErrorString(i18n("Error opening PTY"));
src/kptydevice.cpp:        setErrorString(i18n("Error opening PTY"));

[pvanek]

My original idea was to make terminal part of konsole a standalone lib (like eg. vte for gtpk/gnome world) to be shared between konsole and qterminal. Unfortunately I had never found a time to do it.

[jleclanche]

Yeah that'd be super nice. But we need the help of the kde devs for this, otherwise it's futile imo :\

[jleclanche]

If there's only 5 error strings we can dispense with ki18n and replace them with ts...

[pvanek]

well, we need common agreement with konsole guys. Then it can be done (quite) easily

[ibrokemypie]

Any update on this?

[yan12125]

I've tried it yet got not much progress. A big problem is KConfig. I don't think upstream will accept a patch full of LXQtSettings. A proxy is necessary.

…

On Oct 9, 2017 13:05, "Conor Randall" ***@***.***> wrote: Any update on this? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#320 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB2RGX_wDhQMeKQ2ZmXDjN0Pb2qvYwi_ks5sqamqgaJpZM4M4Arz> .

[simoniz0r]

In my opinion, qterminal should just be abandoned at this point. It's only a couple of extra packages to install konsole from the base LXQt install, and qterminal is not usable at all IMO. qterminal has a pretty terrible memory leak going on; if I leave it open for a day or so, it's easily using a GB or two of RAM.

It really doesn't make much sense to do the extra work to maintain a fork of konsole that adds a minimal amount of features. The features added by qterminal aren't really great either, IMO. For example, the tiling it adds is much better handled by something like tmux.

[jleclanche]

It's not "only a couple of extra packages", it's the whole kde suite, trickling all the way down to things like phonon and a bunch of services. That is not acceptable.

I would 100% love for Konsole to adapt a lighter mode like kwin has been working on, so that it may not depend on all this... I would especially love if we could get the terminal widget as a pure qt library (like qtermwidget), because that's 95% of it. But that needs someone driving it, and I don't have the time to spend on lxqt anymore so it has to be someone else. If you're volunteering, I can guide you.

[simoniz0r]

For me, installing konsole has 2 packages to be installed. Unless something has changed with the amount of KDE libs included between the LXQt release on 16.04 and the latest LXQt release, or some other package I have installed requires KDE's libs, it seems like LXQt is already including all of the libs that konsole needs to install.

AFAIK, the only thing that I've installed that requires KDE libs is the kde-style-breeze package, and if I remove that, it only sets one KDE lib for autoremove. Installing both konsole and konsole-kpart required me to install no additional packages.

I'm currently using xfce4-terminal on this VM because of some weird font rendering issues I have in konsole, but that's another story lol

:EDIT: This is on a bare install from Ubuntu Server 16.04 for what it's worth. LXQt is the only DE on there, and I've got 1314 packages installed. The packages listed in the picture above are packages that have been marked as manually installed, so I'm kinda confused as to what exactly you're talking about when you say it's the whole kde suite. For me, from a very minimal install, it's 2 packages, neither of which seem to be bringing in any extra services. If I install something like Dolphin, on the other hand, I'm getting stuff like KDE's baloo file service, etc, but I saw none of that with konsole.

[kghost]

@simoniz0r follow list is the list of packages where konsole requires but qterminal doesn't. I already stripped the common dependencies. Why are you telling that konsole only need 2 more packages ?

adwaita-icon-theme
aspell
aspell-en
at-spi2-core
dconf-gsettings-backend
dconf-service
dictionaries-common
emacsen-common
glib-networking
glib-networking-common
glib-networking-services
gsettings-desktop-schemas
gtk-update-icon-cache
hicolor-icon-theme
humanity-icon-theme
hunspell-en-us
kinit
kio
konsole-kpart
kwayland-data
kwayland-integration
libaspell15
libasyncns0
libatk1.0-0
libatk1.0-data
libatk-bridge2.0-0
libatspi2.0-0
libavahi-client3
libavahi-common3
libavahi-common-data
libcairo2
libcairo-gobject2
libcolord2
libcontent-hub-glib0
libcroco3
libcups2
libdatrie1
libdbusmenu-qt5
libdconf1
libepoxy0
libfam0
libflac8
libgdk-pixbuf2.0-0
libgdk-pixbuf2.0-bin
libgdk-pixbuf2.0-common
libgpgme11
libgpgmepp6
libgtk-3-0
libgtk-3-bin
libgtk-3-common
libhunspell-1.4-0
libjbig0
libjson-glib-1.0-0
libjson-glib-1.0-common
libkf5archive5
libkf5attica5
libkf5auth5
libkf5auth-data
libkf5bookmarks5
libkf5bookmarks-data
libkf5codecs5
libkf5codecs-data
libkf5completion5
libkf5completion-data
libkf5config-bin
libkf5configcore5
libkf5config-data
libkf5configgui5
libkf5configwidgets5
libkf5configwidgets-data
libkf5coreaddons5
libkf5coreaddons-data
libkf5crash5
libkf5dbusaddons5
libkf5dbusaddons-bin
libkf5dbusaddons-data
libkf5globalaccel5
libkf5globalaccel-bin
libkf5globalaccel-data
libkf5globalaccelprivate5
libkf5guiaddons5
libkf5i18n5
libkf5i18n-data
libkf5iconthemes5
libkf5iconthemes-bin
libkf5iconthemes-data
libkf5idletime5
libkf5itemviews5
libkf5itemviews-data
libkf5jobwidgets5
libkf5jobwidgets-data
libkf5kiocore5
libkf5kiontlm5
libkf5kiowidgets5
libkf5notifications5
libkf5notifications-data
libkf5notifyconfig5
libkf5notifyconfig-data
libkf5parts5
libkf5parts-data
libkf5parts-plugins
libkf5pty5
libkf5pty-data
libkf5service5
libkf5service-bin
libkf5service-data
libkf5solid5
libkf5solid5-data
libkf5sonnet5-data
libkf5sonnetcore5
libkf5sonnetui5
libkf5textwidgets5
libkf5textwidgets-data
libkf5wallet5
libkf5wallet-bin
libkf5wallet-data
libkf5waylandclient5
libkf5widgetsaddons5
libkf5widgetsaddons-data
libkf5windowsystem5
libkf5windowsystem-data
libkf5xmlgui5
libkf5xmlgui-bin
libkf5xmlgui-data
libkwalletbackend5-5
liblcms2-2
libogg0
libpango-1.0-0
libpangocairo-1.0-0
libpangoft2-1.0-0
libphonon4qt5-4
libpixman-1-0
libpolkit-qt5-1-1
libpulse0
libpulse-mainloop-glib0
libqt5printsupport5
libqt5qml5
libqt5quick5
libqt5script5
libqt5svg5
libqt5test5
libqt5waylandclient5
libqt5waylandcompositor5
libqt5xml5
librest-0.7-0
librsvg2-2
librsvg2-common
libsndfile1
libsoup2.4-1
libsoup-gnome2.4-1
libthai0
libthai-data
libtiff5
libtxc-dxtn-s2tc
libvoikko1
libvorbis0a
libvorbisenc2
libwacom-bin
libwayland-cursor0
libwayland-egl1-mesa
libxcomposite1
libxcursor1
libxinerama1
libxrandr2
libxrender1
libxss1
libxtst6
mesa-utils
qt5-gtk-platformtheme
qttranslations5-l10n
qtwayland5
sonnet-plugins
ubuntu-mono

[simoniz0r]

Because for me, that's all it needed after a base LXQt install.

[yan12125]

Someone "backported" a qtermwidget enhancement to Konsole: KDE/konsole@b8a2f0c

Now I think it's good to keep qterminal and qtermwidget standalone. Konsole is really slow for some feature requests.

[Thaodan]

@kghost: maybe because of your distro?
I think most issues come down to packaging.

[agaida]

@kghost - your list isn't right - maybe reading the apt manual will help a lot.
and @simoniz0r is right - in a current lubuntu cosmic a konsole installation will need only two packages.

[agaida]

@Thaodan - much issues are not pure packaging issues - most of the annoyances are "issues" with the understanding the package manager of choice and the intentions of the maintainers.

[agaida]

@yan12125 - bare with me, but if it is possible we should only use certain parts of the konsole dependencies without modify them as far as possible - things like kpty and others come to mind - dunno if this is possible, but we should re-use as much as we can unchanged from the KDE-Project

Edit: if they use code from us - fine, but there are several places where we should rebase against them - *bsd support comes to mind, it was not possible for me to run qterminal without root on a debian kfreebsd system - konsole works fine. So we should keep the diff in plumbing components as little as possible.

[yan12125]

it was not possible for me to run qterminal without root on a debian kfreebsd system

Mind open an issue for that? I would call it a serious bug.

[agaida]

na - is not that serious and would only make sense if the kfreebsd-things catch up (the builder was broken and now i don't have the needed things to even compile a current LXQt - but i will file a bug once i can play with it again)

[yan12125]

if it is possible we should only use certain parts of the konsole dependencies without modify them as far as possible - things like kpty and others come to mind

A bad news is that kpty is currently not applicable for LXQt: #320 (comment)

[Thaodan]

@agaida: thats exactly what you describe.
The packaging of the distro/pkg maintainer.

[tsujan]

@yan12125 I wasn't aware of this open issue. Does it mean that I'm not the only one who doesn't know the deep codes of qtermwidget? Because if we know it, why should we rely on Konsole for bug fixes?

[tsujan]

Oh, I found this: "qtermwidget has a lot of issues which are not getting fixed because nobody really knows how it works..."

At least, one of us should dedicate some time to it. Its just a code after all ;)

[agaida]

My point is only: if i look into our files - would it be possible to use nearly unmodified copies from KDE?
And maybe wrab around outside of the origs?

[tsujan]

@agaida I didn't know about this situation before. A piece of code can't remain a mystery forever.

[sskras]

What pros would the KDE/kpty code bring up?

[tsujan]

If you use Konsole now, you'll be happy that we didn't do 3. Konsole has weird issues that qterminal doesn't.

The codes of qtermwidget and especially qterminal has become very different from those of Konsole. Like any other fork, the paths are different, although the good changes of Konsole may be adapted for qterminal/qtermwidget.

[Thaodan]

Totally unrelated but how does libvterm compare to QTerminal?

[tsujan]

Sorry, no idea.