Bug 234412 - x11/cool-retro-term starts but does nothing
Summary: x11/cool-retro-term starts but does nothing
Status: Open
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Alexey Dokuchaev
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-26 11:53 UTC by Marko Cupać
Modified: 2020-01-28 13:25 UTC (History)
0 users

See Also:
bugzilla: maintainer-feedback? (danfe)


Attachments
screenshot (210.33 KB, image/png)
2018-12-26 11:53 UTC, Marko Cupać
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marko Cupać 2018-12-26 11:53:42 UTC
Created attachment 200524 [details]
screenshot

Hi,

I am using cool-retro-term-1.0.0_6 on FreeBSD 12.0-RELEASE amd64, built it myself in poudriere.

It starts, but I don't get prompt (screenshot attached).

Here's console output:

default KB_LAYOUT_DIR:  "/usr/local/lib/qt5/qml/QMLTermWidget/kb-layouts"
QObject::connect: No such slot Konsole::TerminalDisplay_QML_148::close()
loadAllColorSchemes
qrc:/AboutDialog.qml:18:9: QML Text: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (8 8 8 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 8 8 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 8 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 8)
qrc:/AboutDialog.qml:69:13: QML Image: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.
qrc:/AboutDialog.qml:77:13: QML Text: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.
qrc:/InsertNameDialog.qml:67:9: QML RowLayout: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.
qrc:/SettingsGeneralTab.qml:36:17: QML TableView: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.
qrc:/SettingsGeneralTab.qml:51:17: QML ColumnLayout: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.
qrc:/SettingsGeneralTab.qml:29:9: QML GroupBox: Detected anchors on an item that is managed by a layout. This is undefined behavior; use Layout.alignment instead.
Session::run() - program: "/bin/tcsh"
Session::run() - arguments: ("")
started!
QSqlDatabase: QSQLITE driver not loaded
QSqlDatabase: available drivers: 
QSqlQuery::prepare: database not open
qrc:/Storage.qml:35: Error: Driver not loaded Driver not loaded
Both point size and pixel size set. Using pixel size.
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (8 8 8 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 8 8 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 8 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 8)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 1 8)
Comment 1 Marko Cupać 2019-02-01 12:16:51 UTC
A month has passed without any reply. Bump.
Comment 2 Alexey Dokuchaev freebsd_committer 2019-06-25 16:50:38 UTC
The port has been updated to the latest version in ports r505098.  Could you test it and see if the problem's still there?
Comment 3 Alexey Dokuchaev freebsd_committer 2019-06-25 16:59:23 UTC
Sorry, forgot to mention: about the missing text (empty display), please see this bug #209280: you might need to start it as "env LC_NUMERIC=C cool-retro-term".

It's probably not too hard to fix, but I didn't play with the code long enough to craft a patch and fix it for real, esp. since there are more serious issues to worry about (like abnormally high CPU usage).
Comment 4 Marko Cupać 2019-06-28 10:42:30 UTC
(In reply to Alexey Dokuchaev from comment #3)

Hi,

thank you for looking into this problem.

I have upgraded to latest version:

pacija@efreet:~ % pkg info -x cool
cool-retro-term-1.1.1

I have set LC_NUMERIC to C:

pacija@efreet:~ % env | grep NUME
LC_NUMERIC=C

...but I still don't get any text.

I'm running this in xfce session, could it be that there's some dependency missing?

Here's output from terminal:

pacija@efreet:~ % cool-retro-term --verbose
default KB_LAYOUT_DIR:  "/usr/local/lib/qt5/qml/QMLTermWidget/kb-layouts"
QObject::connect: No such slot Konsole::TerminalDisplay_QML_48::close()
loadAllColorSchemes
Both point size and pixel size set. Using pixel size.
qml: Loading settings: {
  "fps": 20,
  "x": 537,
  "y": 89,
  "width": 1024,
  "height": 768,
  "windowScaling": 1,
  "showTerminalSize": true,
  "fontScaling": 1,
  "fontNames": [
    "TERMINUS_SCALED",
    "COMMODORE_PET",
    "COMMODORE_PET"
  ],
  "showMenubar": false,
  "bloomQuality": 0.5,
  "burnInQuality": 0.5,
  "useCustomCommand": false,
  "customCommand": "",
  "useFastBurnIn": true
}{
  "backgroundColor": "#000000",
  "fontColor": "#ff8100",
  "flickering": 0.1,
  "horizontalSync": 0.08,
  "staticNoise": 0.12,
  "chromaColor": 0.25,
  "saturationColor": 0.25,
  "screenCurvature": 0.3,
  "glowingLine": 0.2,
  "burnIn": 0.25,
  "bloom": 0.55,
  "rasterization": 0,
  "jitter": 0.2,
  "rbgShift": 0,
  "brightness": 0.5,
  "contrast": 0.8,
  "ambientLight": 0.2,
  "windowOpacity": 1,
  "fontName": "TERMINUS_SCALED",
  "fontWidth": 1,
  "margin": 0.5
}
qml: Storing settings: {
  "fps": 20,
  "x": 537,
  "y": 89,
  "width": 1024,
  "height": 768,
  "windowScaling": 1,
  "showTerminalSize": true,
  "fontScaling": 1,
  "fontNames": [
    "TERMINUS_SCALED",
    "COMMODORE_PET",
    "COMMODORE_PET"
  ],
  "showMenubar": false,
  "bloomQuality": 0.5,
  "burnInQuality": 0.5,
  "useCustomCommand": false,
  "customCommand": "",
  "useFastBurnIn": true
}
qml: Storing profile: {
  "backgroundColor": "#000000",
  "fontColor": "#ff8100",
  "flickering": 0.1,
  "horizontalSync": 0.08,
  "staticNoise": 0.12,
  "chromaColor": 0.25,
  "saturationColor": 0.25,
  "screenCurvature": 0.3,
  "glowingLine": 0.2,
  "burnIn": 0.25,
  "bloom": 0.55,
  "rasterization": 0,
  "jitter": 0.2,
  "rbgShift": 0,
  "brightness": 0.5,
  "contrast": 0.8,
  "ambientLight": 0.2,
  "windowOpacity": 1,
  "fontName": "TERMINUS_SCALED",
  "fontWidth": 1,
  "margin": 0.5
}
Comment 5 Marko Cupać 2019-08-24 16:22:54 UTC
Hi,

I gave a spin to full KDE environment in a VirtualBox VM, and cool-retro-term seem to work in KDE. Still doesn't work in XFCE.

Could it be that some dependency is being missed in XFCE, but is already in KDE?
Comment 6 Alexey Dokuchaev freebsd_committer 2020-01-26 13:09:07 UTC
(In reply to Marko Cupać from comment #5)
> Could it be that some dependency is being missed in XFCE, but
> is already in KDE?
Could be, but I've just built and run it in a pretty basic, pure X.Org+Openbox environment, and it works as expected.

Perhaps the problem occurs when there are some issues with OpenGL and/or hardware gfx acceleration?  What does "glxinfo -B | grep Device" yields on the system where the port does not work?
Comment 7 Marko Cupać 2020-01-28 11:47:18 UTC
(In reply to Alexey Dokuchaev from comment #6)

Hi,

I haven't been starting cool-retro-term for a long time, now when I read your reply I gave it another try and it works.

In the meantime I reverted my graphics driver from modesetting to xf86-video-intel due to XFCE  bug:

https://bugzilla.xfce.org/show_bug.cgi?id=15990

...but that is irrelevant - cool-retro-term works with both drivers now.

Whatever happened in the meantime (upgrading to 12.1-RELEASE, constantly building and installing latest ports from HEAD) appears to have solved the problem.

As far as I am concerned, this issue has been "overcome by events", it can be closed. Should I do it or you?

Thanks,
Comment 8 Alexey Dokuchaev freebsd_committer 2020-01-28 13:25:42 UTC
(In reply to Marko Cupać from comment #7)
> Whatever happened in the meantime [...] appears to have solved
> the problem.
Glad it works for you now as well Marko!

> As far as I am concerned, this issue has been "overcome by
> events", it can be closed. Should I do it or you?
I think I still have one machine somewhere where I've observed a similar problem with the port; let me see if I can make any use of it in the next several days, otherwise I'll close it.