I want it on windows xD [$15] #40

New Issue

2014-07-31T08:20:22+02:00

DmitryOlkhovoi commented

2014-07-31 08:20:22 +02:00

(Migrated from github.com)

--- There is a **[$15 open bounty](https://www.bountysource.com/issues/3417638-i-want-it-on-windows-xd?utm_campaign=plugin&utm_content=tracker%2F479407&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F479407&utm_medium=issues&utm_source=github).

## <bountysource-plugin> --- There is a **[$15 open bounty](https://www.bountysource.com/issues/3417638-i-want-it-on-windows-xd?utm_campaign=plugin&utm_content=tracker%2F479407&utm_medium=issues&utm_source=github)** on this issue. Add to the bounty at [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F479407&utm_medium=issues&utm_source=github). </bountysource-plugin>

👍 10

pavellishin commented

2014-08-01 18:24:37 +02:00

(Migrated from github.com)

I want it in OS X :(

aacalfa commented

2014-08-01 21:49:00 +02:00

(Migrated from github.com)

OS X works and a branch has already been created! Check it out https://github.com/Swordifish90/cool-old-term/tree/osx

pavellishin commented

2014-08-01 23:14:01 +02:00

(Migrated from github.com)

Nice! How different are the build steps? I guess I'll find out.

edit: I did not find out, I am not good with computer. Can someone help me out by updating the docs, or by holding my hand so I can update the docs?

Nice! How different are the build steps? I guess I'll find out. edit: I did not find out, I am not good with computer. Can someone help me out by updating the docs, or by holding my hand so I can update the docs?

Swordfish90 commented

2014-08-03 15:25:05 +02:00

(Migrated from github.com)

I'll leave this thread open if someone in some way manages to build it under windows.

xan2622 commented

2015-02-02 19:52:58 +01:00

(Migrated from github.com)

Ok for a Windows port but for cmd.exe or powershell ?

Swordfish90 commented

2015-02-07 18:59:10 +01:00

(Migrated from github.com)

@x-a-n-a-x This is probably the least of your concerns. The really hard part would be to port qtermwidget under windows.

yurikhan commented

2015-02-08 07:04:22 +01:00

(Migrated from github.com)

Anybody who’d like to implement a similar experience on Windows had better look at ConEmu and/or Console. They do much of the machinery needed to customize the console window; you will only need to augment the renderer.

Anybody who’d like to implement a similar experience on Windows had better look at [ConEmu](https://code.google.com/p/conemu-maximus5/) and/or [Console](http://sourceforge.net/projects/console/). They do much of the machinery needed to customize the console window; you will only need to augment the renderer.

👍 3

majuca commented

2015-11-26 23:39:54 +01:00

(Migrated from github.com)

If somebody is interested, I started a project based on qmltermwidget and libqxt which allows to open an ssh terminal on Windows (https://github.com/majuca/qssh). It is only a first draft but an ssh connection can be establish sucessfully.

neural75 commented

2015-12-20 01:17:53 +01:00

(Migrated from github.com)

Actually I was able to compile both qtermwidget and cool-retro-term under Windows by means of cygwin (with all qt5/qml deps). But sadly the exe didn't run with this error:
$ ./cool-retro-term.exe
QXcbConnection: Could not connect to display
Aborted (core dumped)
So I guess it's the Unix semantic missing :)

Actually I was able to compile both qtermwidget and cool-retro-term under Windows by means of cygwin (with all qt5/qml deps). But sadly the exe didn't run with this error: $ ./cool-retro-term.exe QXcbConnection: Could not connect to display Aborted (core dumped) So I guess it's the Unix semantic missing :)

asdf23 commented

2016-04-01 18:34:17 +02:00

(Migrated from github.com)

@neural75
Do you have any gui based program working through Cygwin? There is a way to send the output of a GUI to a different "screen". I forget exactly how that works... I suspect that is the key to this. See if you can get any gui launched first.

@neural75 Do you have any gui based program working through Cygwin? There is a way to send the output of a GUI to a different "screen". I forget exactly how that works... I suspect that is the key to this. See if you can get any gui launched first.

anne-decusatis commented

2016-04-10 04:28:02 +02:00

(Migrated from github.com)

On Windows 7:

Install Cygwin (I did this a while ago, I have the 64 bit version)
Start setup.exe and install anything remotely like a qt5 package (search for qt5 and libqt5, and mingw64-x86_64-qt).
Also install xorg-server and xinit and make while you're in Cygwin with setup.exe.
Clone the repo recursively as in "compile" section of README. cd qmltermwidget. qmake-qt5 && make, make install, cd ... qmake-qt5 && make. (I had some clock skew errors in make which I'm not sure how to deal with, so I ignored them.)
Open program in X server with startxwin ./cool-retro-term.exe in Cygwin terminal

Results: Program opens a window, but you can't click or type in it. This prints in the terminal that the last startxwin command was ran in: https://gist.github.com/anne-decusatis/d2d4be8b5b01516b29793eb087909ad8

I'm concerned about a couple lines near the end: Can't open a pseudo teletype on line 63 and Unable to set terminal attributes. on line 69.

Most of the way there:

On Windows 7: 1. Install Cygwin (I did this a while ago, I have the 64 bit version) 2. Start setup.exe and install anything remotely like a qt5 package (search for qt5 and libqt5, and mingw64-x86_64-qt). 3. Also install xorg-server and xinit and make while you're in Cygwin with setup.exe. 4. Clone the repo recursively as in "compile" section of README. `cd qmltermwidget`. `qmake-qt5 && make`, `make install`, `cd ..`. `qmake-qt5 && make`. (I had some clock skew errors in make which I'm not sure how to deal with, so I ignored them.) 5. Open program in X server with `startxwin ./cool-retro-term.exe` in Cygwin terminal Results: Program opens a window, but you can't click or type in it. This prints in the terminal that the last startxwin command was ran in: https://gist.github.com/anne-decusatis/d2d4be8b5b01516b29793eb087909ad8 I'm concerned about a couple lines near the end: `Can't open a pseudo teletype` on line 63 and `Unable to set terminal attributes.` on line 69. Most of the way there: ![cool retro term](https://cloud.githubusercontent.com/assets/6568710/14407741/379fbb3a-fea2-11e5-97bb-fafe3f85461a.png)

👍 3 ❤️ 3 🎉 5

zakukai commented

2016-05-17 20:41:03 +02:00

(Migrated from github.com)

Yeah there's a problem compiling qmltermwidget/lib/kpty.cpp on Cygwin.
Basically, kpty provides platform-abstraction for all the various different ways the OS might support creating a TTY device pair on different systems. The module is falling back on the bad, old BSD-style method (opening all the /dev/pty* devices until it finds one it's able to open) which has been removed from most systems for years. That code should come with a great big warning message saying "your build settings are broken!" - because it's almost certainly not the code you want to be running. :)

You can correct that problem with a little change to qmltermwidget/qmltermwidget.pro:
-DEFINES += HAVE_POSIX_OPENPT HAVE_SYS_TIME_H
+DEFINES += _XOPEN_SOURCE=600 HAVE_POSIX_OPENPT HAVE_PTSNAME HAVE_SYS_TIME_H

kpty.cpp won't use posix_openpt() unless either HAVE_PTSNAME or TIOCGPTN are defined (this is what causes the fallback to the BSD-style method that doesn't work), and posix_openpt() won't appear in the Cygwin system headers unless you supply the _XOPEN_SOURCE define.

Unfortunately, after this change, it still doesn't appear to be working. The terminal opens the PTY device, and it runs bash with the PTY device as its controlling TTY, but I still don't get anything on the display (it looks just like Anne's screen shot), menu bars don't work, etc. I know a little QT but not really enough to readily diagnose this.
I'll get back to you guys if I'm able to work out the other issues. It really seems like we're close here...

(EDIT): Also, when I type commands into the terminal, they are executed! I can even close the session by typing "exit". I just don't see anything on the terminal window...

Yeah there's a problem compiling **qmltermwidget/lib/kpty.cpp** on Cygwin. Basically, **kpty** provides platform-abstraction for all the various different ways the OS might support creating a TTY device pair on different systems. The module is falling back on the bad, old BSD-style method (opening all the **/dev/pty**\* devices until it finds one it's able to open) which has been removed from most systems for years. That code should come with a great big warning message saying "your build settings are broken!" - because it's almost certainly not the code you want to be running. :) You can correct that problem with a little change to **qmltermwidget/qmltermwidget.pro**: **-DEFINES += HAVE_POSIX_OPENPT HAVE_SYS_TIME_H +DEFINES += _XOPEN_SOURCE=600 HAVE_POSIX_OPENPT HAVE_PTSNAME HAVE_SYS_TIME_H** **kpty.cpp** won't use **posix_openpt()** unless either **HAVE_PTSNAME** or **TIOCGPTN** are defined (this is what causes the fallback to the BSD-style method that doesn't work), and **posix_openpt()** won't appear in the Cygwin system headers unless you supply the **_XOPEN_SOURCE** define. Unfortunately, after this change, it still doesn't appear to be working. The terminal opens the PTY device, and it runs bash with the PTY device as its controlling TTY, but I still don't get anything on the display (it looks just like Anne's screen shot), menu bars don't work, etc. I know a little QT but not really enough to readily diagnose this. I'll get back to you guys if I'm able to work out the other issues. It really seems like we're close here... **(EDIT)**: Also, when I type commands into the terminal, they are executed! I can even close the session by typing "exit". I just don't see anything on the terminal window...

zakukai commented

2016-05-17 22:53:27 +02:00

(Migrated from github.com)

OK, I figured out the other problem... it's in kptydevice.cpp

There's a function KPtyDevicePrivate::_k_canRead(), which uses an ioctl() to try to determine if there's data available to read from the TTY device (data coming in from the shell process). The problem is, I think, that Cygwin doesn't support this particular ioctl.

At the top of the file the ioctl is defined as PTY_BYTES_AVAILABLE. On FreeBSD and Mac it's defined as TIOCOUTQ, otherwise it's set to TIOCINQ if it's defined, otherwise to FIONREAD.

I did a web search and apparently at one time TIOCINQ was defined in Cygwin but did not work correctly... I don't know if that's really still the case currently. But that's basically what seems to be happening. The ioctl() returns -1, signaling an error, and errno is set to "invalid argument" - which could mean the file descriptor is bad, but that's not the case...

I added code to my build to use poll() instead of the ioctl() - mainly to verify that the file descriptor really was valid - and got it working. The problem with my patch, though, is that the rest of the code in that function assumes that it will know not only that there is data in the input queue, but actually how much data is in the input queue... And poll() doesn't provide that, and I haven't yet rewritten the rest of the function... So I lie, I say I got a kilobyte. The rest of the function still works, it seems, even being lied to in this way. (It allocates a kilobyte, reads what it can, then shrinks the buffer... So wasteful!)

It's possible that there will actually be more than a kilobyte available: in which case the terminal may read the full 1K of data and not immediately be notified that there's more... I'll probably make more improvements to that function but for now I'm just happy that it works.

diff --git a/lib/kptydevice.cpp b/lib/kptydevice.cpp
index 37ecce8..26cf229 100644
--- a/lib/kptydevice.cpp
+++ b/lib/kptydevice.cpp
@@ -33,10 +33,14 @@
 #include "kpty_p.h"

 #include <QSocketNotifier>
+#include <QtDebug>
+
+#include <poll.h>

 #include <unistd.h>
 #include <errno.h>
 #include <signal.h>
+#include <string.h>
 #include <termios.h>
 #include <fcntl.h>
 #include <sys/ioctl.h>
@@ -85,12 +89,31 @@ bool KPtyDevicePrivate::_k_canRead()
     Q_Q(KPtyDevice);
     qint64 readBytes = 0;

+    struct pollfd tty_poll;
+    tty_poll.fd = q->masterFd();
+    tty_poll.events = POLLIN;
+    tty_poll.revents = 0;
+
+    int poll_result = poll(&tty_poll, 1, 0);
+
 #ifdef Q_OS_IRIX // this should use a config define, but how to check it?
     size_t available;
 #else
     int available;
 #endif
-    if (!::ioctl(q->masterFd(), PTY_BYTES_AVAILABLE, (char *) &available)) {
+    int ioctl_result;
+    //ioctl_result = ::ioctl(q->masterFd(), PTY_BYTES_AVAILABLE, (char *) &available);
+    //qDebug() << "_k_canRead(): ioctl(" << q->masterFd() << ", PTY_BYTES_AVAILABLE) -> " << ioctl_result;
+    ioctl_result = 0;
+    available = 0;
+    if (poll_result > 0) {
+       ioctl_result = 0;
+       // We probably didn't really get 1024 bytes, but I believe the code below will work
+       // even if this value is wrong. It's just used to allocate the receive buffer.
+       available = 1024;
+    }
+
+    if (ioctl_result >= 0) {
 #ifdef Q_OS_SOLARIS
         // A Pty is a STREAMS module, and those can be activated
         // with 0 bytes available. This happens either when ^C is
@@ -104,6 +127,7 @@ bool KPtyDevicePrivate::_k_canRead()
             NO_INTR(readBytes, read(q->masterFd(), &c, 0));
             // Should return 0 bytes read; -1 is error
             if (readBytes < 0) {
+                qDebug() << "_k_canRead() disabling readNotifier attempting to read 0-byte STREAMS message: " << strerror(errno);
                 readNotifier->setEnabled(false);
                 emit q->readEof();
                 return false;
@@ -134,9 +158,13 @@ bool KPtyDevicePrivate::_k_canRead()
             return false;
         }
         readBuffer.unreserve(available - readBytes); // *should* be a no-op
+    } else {
+        qDebug() << "KPtyDevicePrivate::_k_canRead(): ioctl() failed:" << strerror(errno);
+        qDebug() << "available =" << available;
     }

     if (!readBytes) {
+        qDebug() << "_k_canRead() disabling readNotifier" << strerror(errno);
         readNotifier->setEnabled(false);
         emit q->readEof();
         return false;
@@ -254,8 +282,10 @@ bool KPtyDevicePrivate::doWait(int msecs, bool reading)
         default:
             if (FD_ISSET(q->masterFd(), &rfds)) {
                 bool canRead = _k_canRead();
-                if (reading && canRead)
+                if (reading && canRead) {
+                    qDebug() << "Can read from TTY";
                     return true;
+                }
             }
             if (FD_ISSET(q->masterFd(), &wfds)) {
                 bool canWrite = _k_canWrite();
@@ -271,6 +301,7 @@ bool KPtyDevicePrivate::doWait(int msecs, bool reading)
 void KPtyDevicePrivate::finishOpen(QIODevice::OpenMode mode)
 {
     Q_Q(KPtyDevice);
+    qDebug() << "KPtyDevicePrivate::finishOpen(): Enabling readNotifier";

     q->QIODevice::open(mode);
     fcntl(q->masterFd(), F_SETFL, O_NONBLOCK);
@@ -387,6 +418,8 @@ bool KPtyDevice::waitForBytesWritten(int msecs)
 void KPtyDevice::setSuspended(bool suspended)
 {
     Q_D(KPtyDevice);
+    qDebug() << "KPtyDevice::setSuspended(" << suspended << ")";
+
     d->readNotifier->setEnabled(!suspended);
 }

diff --git a/qmltermwidget.pro b/qmltermwidget.pro
index d0caad7..6948a50 100644
--- a/qmltermwidget.pro
+++ b/qmltermwidget.pro
@@ -7,7 +7,7 @@ include(lib.pri)

 DESTDIR = $$OUT_PWD/QMLTermWidget

-DEFINES += HAVE_POSIX_OPENPT HAVE_SYS_TIME_H
+DEFINES += _XOPEN_SOURCE=600 HAVE_POSIX_OPENPT HAVE_PTSNAME HAVE_UNLOCKPT HAVE_SYS_TIME_H
 macx:DEFINES += HAVE_UTMPX _UTMPX_COMPAT

 INCLUDEPATH += $$PWD/lib

OK, I figured out the other problem... it's in **kptydevice.cpp** There's a function **KPtyDevicePrivate::_k_canRead()**, which uses an ioctl() to try to determine if there's data available to read from the TTY device (data coming in from the shell process). The problem is, I think, that Cygwin doesn't support this particular ioctl. At the top of the file the ioctl is defined as **PTY_BYTES_AVAILABLE**. On FreeBSD and Mac it's defined as **TIOCOUTQ**, otherwise it's set to **TIOCINQ** if it's defined, otherwise to **FIONREAD**. I did a web search and apparently at one time **TIOCINQ** was defined in Cygwin but did not work correctly... I don't know if that's really still the case currently. But that's basically what seems to be happening. The ioctl() returns -1, signaling an error, and errno is set to "invalid argument" - which could mean the file descriptor is bad, but that's not the case... I added code to my build to use poll() instead of the ioctl() - mainly to verify that the file descriptor really was valid - and got it working. The problem with my patch, though, is that the rest of the code in that function assumes that it will know not only that there is data in the input queue, but actually _how much_ data is in the input queue... And poll() doesn't provide that, and I haven't yet rewritten the rest of the function... So I lie, I say I got a kilobyte. The rest of the function still works, it seems, even being lied to in this way. (It allocates a kilobyte, reads what it can, then shrinks the buffer... So wasteful!) It's possible that there will actually be more than a kilobyte available: in which case the terminal may read the full 1K of data and not immediately be notified that there's more... I'll probably make more improvements to that function but for now I'm just happy that it works. ![i_am_super_awesome](https://cloud.githubusercontent.com/assets/5018690/15338875/c64b0108-1c4f-11e6-80ff-0e7588c22a21.png) ``` diff --git a/lib/kptydevice.cpp b/lib/kptydevice.cpp index 37ecce8..26cf229 100644 --- a/lib/kptydevice.cpp +++ b/lib/kptydevice.cpp @@ -33,10 +33,14 @@ #include "kpty_p.h" #include <QSocketNotifier> +#include <QtDebug> + +#include <poll.h> #include <unistd.h> #include <errno.h> #include <signal.h> +#include <string.h> #include <termios.h> #include <fcntl.h> #include <sys/ioctl.h> @@ -85,12 +89,31 @@ bool KPtyDevicePrivate::_k_canRead() Q_Q(KPtyDevice); qint64 readBytes = 0; + struct pollfd tty_poll; + tty_poll.fd = q->masterFd(); + tty_poll.events = POLLIN; + tty_poll.revents = 0; + + int poll_result = poll(&tty_poll, 1, 0); + #ifdef Q_OS_IRIX // this should use a config define, but how to check it? size_t available; #else int available; #endif - if (!::ioctl(q->masterFd(), PTY_BYTES_AVAILABLE, (char *) &available)) { + int ioctl_result; + //ioctl_result = ::ioctl(q->masterFd(), PTY_BYTES_AVAILABLE, (char *) &available); + //qDebug() << "_k_canRead(): ioctl(" << q->masterFd() << ", PTY_BYTES_AVAILABLE) -> " << ioctl_result; + ioctl_result = 0; + available = 0; + if (poll_result > 0) { + ioctl_result = 0; + // We probably didn't really get 1024 bytes, but I believe the code below will work + // even if this value is wrong. It's just used to allocate the receive buffer. + available = 1024; + } + + if (ioctl_result >= 0) { #ifdef Q_OS_SOLARIS // A Pty is a STREAMS module, and those can be activated // with 0 bytes available. This happens either when ^C is @@ -104,6 +127,7 @@ bool KPtyDevicePrivate::_k_canRead() NO_INTR(readBytes, read(q->masterFd(), &c, 0)); // Should return 0 bytes read; -1 is error if (readBytes < 0) { + qDebug() << "_k_canRead() disabling readNotifier attempting to read 0-byte STREAMS message: " << strerror(errno); readNotifier->setEnabled(false); emit q->readEof(); return false; @@ -134,9 +158,13 @@ bool KPtyDevicePrivate::_k_canRead() return false; } readBuffer.unreserve(available - readBytes); // *should* be a no-op + } else { + qDebug() << "KPtyDevicePrivate::_k_canRead(): ioctl() failed:" << strerror(errno); + qDebug() << "available =" << available; } if (!readBytes) { + qDebug() << "_k_canRead() disabling readNotifier" << strerror(errno); readNotifier->setEnabled(false); emit q->readEof(); return false; @@ -254,8 +282,10 @@ bool KPtyDevicePrivate::doWait(int msecs, bool reading) default: if (FD_ISSET(q->masterFd(), &rfds)) { bool canRead = _k_canRead(); - if (reading && canRead) + if (reading && canRead) { + qDebug() << "Can read from TTY"; return true; + } } if (FD_ISSET(q->masterFd(), &wfds)) { bool canWrite = _k_canWrite(); @@ -271,6 +301,7 @@ bool KPtyDevicePrivate::doWait(int msecs, bool reading) void KPtyDevicePrivate::finishOpen(QIODevice::OpenMode mode) { Q_Q(KPtyDevice); + qDebug() << "KPtyDevicePrivate::finishOpen(): Enabling readNotifier"; q->QIODevice::open(mode); fcntl(q->masterFd(), F_SETFL, O_NONBLOCK); @@ -387,6 +418,8 @@ bool KPtyDevice::waitForBytesWritten(int msecs) void KPtyDevice::setSuspended(bool suspended) { Q_D(KPtyDevice); + qDebug() << "KPtyDevice::setSuspended(" << suspended << ")"; + d->readNotifier->setEnabled(!suspended); } diff --git a/qmltermwidget.pro b/qmltermwidget.pro index d0caad7..6948a50 100644 --- a/qmltermwidget.pro +++ b/qmltermwidget.pro @@ -7,7 +7,7 @@ include(lib.pri) DESTDIR = $$OUT_PWD/QMLTermWidget -DEFINES += HAVE_POSIX_OPENPT HAVE_SYS_TIME_H +DEFINES += _XOPEN_SOURCE=600 HAVE_POSIX_OPENPT HAVE_PTSNAME HAVE_UNLOCKPT HAVE_SYS_TIME_H macx:DEFINES += HAVE_UTMPX _UTMPX_COMPAT INCLUDEPATH += $$PWD/lib ```

👍 9

Swordfish90 commented

2016-05-20 15:23:15 +02:00

(Migrated from github.com)

@zakukai Great! If you are confident with your changes we can create a custom branch on qmltermwidget including windows support and create an experimental CRT branch.

zakukai commented

2016-05-21 05:19:10 +02:00

(Migrated from github.com)

Well it's usable but it's not quite right yet. Among the issues I've noticed with my Windows build:

Still can't use menus
Term will occasionally freeze (animated effects like glow line, etc. stop, new data doesn't appear on the screen) until it gets some input from my end (keystroke, mouse click, etc.)
Term will occasionally freeze irrecoverably
It appears that the term is occasionally dropping some of the data it receives via the PTY (commands in Bash frequently appear to be misaligned by one character cell)

And ultimately I think we'd want my changes integrated a bit better (right now I just kind of gutted the things that were getting in my way) But it's a start. A branch is probably a good idea, make it easier for people to try it out, make it easier to make further changes, etc.

Well it's usable but it's not quite right yet. Among the issues I've noticed with my Windows build: - Still can't use menus - Term will occasionally freeze (animated effects like glow line, etc. stop, new data doesn't appear on the screen) until it gets some input from my end (keystroke, mouse click, etc.) - Term will occasionally freeze irrecoverably - It appears that the term is occasionally dropping some of the data it receives via the PTY (commands in Bash frequently appear to be misaligned by one character cell) And ultimately I think we'd want my changes integrated a bit better (right now I just kind of gutted the things that were getting in my way) But it's a start. A branch is probably a good idea, make it easier for people to try it out, make it easier to make further changes, etc.

👍 2

techtonik commented

2016-06-06 21:41:19 +02:00

(Migrated from github.com)

Is it possible to just port the visual part and attach it to ConEmu or console?

zakukai commented

2016-06-07 02:47:01 +02:00

(Migrated from github.com)

I'm sure it is.
...Let me know how that turns out. :)

I'm sure it is. ...Let me know how that turns out. :)

StakFallT commented

2016-06-22 23:27:12 +02:00

(Migrated from github.com)

Quick update from my end. I performed the necessary changes to the files that Zakukai suggested. I got it to work. But like Zakukai the menu shows up, but the menu under the main menus are not showing. I tried all kinds of different things, amoung those are:
I tried rolling the CRTMainMenuBar into main.qml, rem'ing it out in the resources.qrc file, but then it error'ed inside of PreprocessedTerminal.qml -- naturally because CRTMainMenuBar.qml isn't there. And then rem'ing it out inside of PreprocessedTerminal.qml didn't work. Which makes sense and doesn't. The MenuBar is encased inside of ApplicationWindow in main.qml, so it looks to me that with that being the case, the menubar should just get added.

I started thinking perhaps, the problem is the action is being used inside of CRTMainMenuBar.qml but it's not defined in that file, so rolling one of the actions (don't need all of them to test; just one) into that file and rem'ing out the rest in main.qml produced an error that basically stated that actions have to be encased in an ApplicationWindow tag. So that wasn't going to work.

I started thinking, maybe because it's placed inside of PreprocessedTerminal and the menubar are being overwritten with the graphical effects, which kind've makes sense. Originally if you clicked the menu, there would be a dark rectangle over the terminal portion of the screen where the menu would be. So I rem'ed out the adding of the menu bar in PreprocessedTerminal.qml and added the line:
CRTMainMenuBar{visible: true}
to TerminalContainer.qml line: 36 (inside the Loader figuring I'd have it render out-of-band from the graphical container (which it should and oddly enough it seems to load a bit faster this way for some reason; maybe it's just me), this was also a no-go.

Then I realized that was still under something that had to do with GFX (ShaderTerminal) so I added the line to main.qml instead (line: 241 - under Loader), this still didn't work.

It should be noted during these attempts, the MenuItem's were converted from actions to actual Menuitems. I.e. instead of MenuItem {action: quitAction}
I changed it to something like:
MenuItem
{
//id: quitAction
text: qsTr("Quit")
enabled: true
visible: true
shortcut: "Ctrl+Shift+Q"
onTriggered: Qt.quit();
}

just to make sure there wasn't any funny business with action types not being called-in/injected and I figured function like Qt.quit(); is an easy function, it's something built-in, it's not a dependence on a function defined in another file.

This is starting to look more and more like something screwed up with the QT library pulled down from CygWin64. I mean it wouldn't be the first issue with the QT library (i.e. someone spelling Accessibility as Acccessibility -- an extra "c"; there's a bug report on it even. Don't have the link handy though). I'd be curious to know where to rem out to prevent the graphical portion of the code from loading (even if it does render just an empty black/white window) just to see if the menu shows up and is function. If that's the case then we could probably eliminate the QT library deployed by CygWin64 as the culprit and move further down the line in the CRT qml code.

Quick update from my end. I performed the necessary changes to the files that Zakukai suggested. I got it to work. But like Zakukai the menu shows up, but the menu under the main menus are not showing. I tried all kinds of different things, amoung those are: I tried rolling the CRTMainMenuBar into main.qml, rem'ing it out in the resources.qrc file, but then it error'ed inside of PreprocessedTerminal.qml -- naturally because CRTMainMenuBar.qml isn't there. And then rem'ing it out inside of PreprocessedTerminal.qml didn't work. Which makes sense and doesn't. The MenuBar is encased inside of ApplicationWindow in main.qml, so it looks to me that with that being the case, the menubar should just get added. I started thinking perhaps, the problem is the action is being used inside of CRTMainMenuBar.qml but it's not defined in that file, so rolling one of the actions (don't need all of them to test; just one) into that file and rem'ing out the rest in main.qml produced an error that basically stated that actions have to be encased in an ApplicationWindow tag. So that wasn't going to work. I started thinking, maybe because it's placed inside of PreprocessedTerminal and the menubar are being overwritten with the graphical effects, which kind've makes sense. Originally if you clicked the menu, there would be a dark rectangle over the terminal portion of the screen where the menu would be. So I rem'ed out the adding of the menu bar in PreprocessedTerminal.qml and added the line: CRTMainMenuBar{visible: true} to TerminalContainer.qml line: 36 (inside the Loader figuring I'd have it render out-of-band from the graphical container (which it should and oddly enough it seems to load a bit faster this way for some reason; maybe it's just me), this was also a no-go. Then I realized that was still under something that had to do with GFX (ShaderTerminal) so I added the line to main.qml instead (line: 241 - under Loader), this still didn't work. It should be noted during these attempts, the MenuItem's were converted from actions to actual Menuitems. I.e. instead of MenuItem {action: quitAction} I changed it to something like: MenuItem { //id: quitAction text: qsTr("Quit") enabled: true visible: true shortcut: "Ctrl+Shift+Q" onTriggered: Qt.quit(); } just to make sure there wasn't any funny business with action types not being called-in/injected and I figured function like Qt.quit(); is an easy function, it's something built-in, it's not a dependence on a function defined in another file. This is starting to look more and more like something screwed up with the QT library pulled down from CygWin64. I mean it wouldn't be the first issue with the QT library (i.e. someone spelling Accessibility as Acccessibility -- an extra "c"; there's a bug report on it even. Don't have the link handy though). I'd be curious to know where to rem out to prevent the graphical portion of the code from loading (even if it does render just an empty black/white window) just to see if the menu shows up and is function. If that's the case then we could probably eliminate the QT library deployed by CygWin64 as the culprit and move further down the line in the CRT qml code.

aaronsb commented

2016-07-19 23:22:36 +02:00

(Migrated from github.com)

I know this sort of is a different way of going about this - but I was able to compile without changes in the linux subsystem for windows 10. xming provides the x environment with gl support. It has the same problems other folks are encountering, namely no actual terminal pipe.

I know this sort of is a different way of going about this - but I was able to compile without changes in the linux subsystem for windows 10. xming provides the x environment with gl support. It has the same problems other folks are encountering, namely no actual terminal pipe. ![Console preview](https://i.imgur.com/2IEGZjs.png)

👍 6

dvdmuckle commented

2016-07-30 20:44:36 +02:00

(Migrated from github.com)

Can confirm what @aaronsb has found, except I didn't compile it, but just installed it from the PPA using the subsystem. Same errors.

Plazmaz commented

2016-12-11 00:22:33 +01:00

(Migrated from github.com)

Also confirmed the case @aaronsb and @dvdmuckle experienced when building and running on subsystem using an x11 server.

zakukai commented

2017-07-17 22:46:32 +02:00

(Migrated from github.com)

Regarding my previous diff, the use of poll() and all that:
I noted in a previous post that one of the problems is that a certain ioctl() constant, TIOCINQ is defined in the Cygwin headers but not properly implemented in Cygwin, and that the code would fall back to another ioctl() constant, FIONREAD if TIOCINQ was not defined...
So, in fact, all that stuff I did with poll() was entirely unnecessary. All you really need to fix that bit of code in lib/kptydevice.cpp is to undefine TIOCINQ if it's a Cygwin system, and then go ask the Cygwin team how many years they're going to leave that ioctl broken. :)
I'd really like to know what's causing the program to freeze. It seems to happen when the terminal is left idle (or obscured?) for a certain amount of time. After a little while, the terminal stops animating, and a few minutes after that, it just seizes up. I've been hoping to get in there with a debugger and figure out what's going wrong, but so far the debugger's not giving me any useful answers.
When I have some time I'll try to clean up and simplify my patches and we can create that Windows branch. Hopefully from there we can move on to solving some of the other problems.

Regarding my previous diff, the use of **poll()** and all that: I noted in a previous post that one of the problems is that a certain ioctl() constant, **TIOCINQ** is defined in the Cygwin headers but not properly implemented in Cygwin, and that the code would fall back to another ioctl() constant, **FIONREAD** if **TIOCINQ** was not defined... So, in fact, all that stuff I did with **poll()** was entirely unnecessary. All you really need to fix that bit of code in **lib/kptydevice.cpp** is to undefine **TIOCINQ** if it's a Cygwin system, and then go ask the Cygwin team how many years they're going to leave that ioctl broken. :) I'd really like to know what's causing the program to freeze. It seems to happen when the terminal is left idle (or obscured?) for a certain amount of time. After a little while, the terminal stops animating, and a few minutes after that, it just seizes up. I've been hoping to get in there with a debugger and figure out what's going wrong, but so far the debugger's not giving me any useful answers. When I have some time I'll try to clean up and simplify my patches and we can create that Windows branch. Hopefully from there we can move on to solving some of the other problems.

usuariofalso commented

2017-07-19 19:46:17 +02:00

(Migrated from github.com)

Hope you guys could make a Windows version of this great software! Looking forward to this!

bombcheck commented

2017-08-01 10:07:33 +02:00

(Migrated from github.com)

I'm looking forward to this, too. If I can be of any help, just let me know.

zakukai commented

2017-08-01 18:39:38 +02:00

(Migrated from github.com)

If you want to help, get the source code, apply the patches, build and run the program on your machine... And then if you get that far, try to figure out why the program is locking up. I haven't spent a whole lot of time digging into that problem yet, it is probably the most important issue standing in the way of this being usable on Windows at this point.

YPetremann commented

2017-08-18 01:55:28 +02:00

(Migrated from github.com)

I don't know if this can help, I found out something with tmux, Xming and WSL :
I started two bash in separated console, one to start tmux, the second to start cool-retro-term -e tmux attach. The result are that you can clearly see that the process is correctly attached and you can clearly see that any sent key is correctly received by tmux, only the part of "printing the information back" does not work.

I don't know if this can help, I found out something with tmux, Xming and WSL : I started two bash in separated console, one to start `tmux`, the second to start `cool-retro-term -e tmux attach`. The result are that you can clearly see that the process is correctly attached and you can clearly see that any sent key is correctly received by tmux, only the part of "printing the information back" does not work.

wes-kay commented

2018-07-11 08:59:52 +02:00

(Migrated from github.com)

@zakukai I know this was over 11 months ago, but I'm just trying to convert this project over and I was able to build out the retro term, I was thinking I would just pipe in commands to the console / terminal Gui.

The issue is, I can't seem to build the slots to render text to, is there any repo I can jump off that you guys have pushed to get these changes of yours?

@zakukai I know this was over 11 months ago, but I'm just trying to convert this project over and I was able to build out the retro term, I was thinking I would just pipe in commands to the console / terminal Gui. The issue is, I can't seem to build the slots to render text to, is there any repo I can jump off that you guys have pushed to get these changes of yours?

👍 1

aaronsb commented

2018-07-11 23:20:02 +02:00

(Migrated from github.com)

I have cool-retro-term running mostly correctly on WSL with Xming.

It's not the most performant thing ever. Also occasionally it just up and dies on me. But most of the features work as intended. Running Windows 10 Enterprise 1803, build 17134.1.

I did not execute any additional patches or modifications to the current github source.

I have cool-retro-term running mostly correctly on WSL with Xming. It's not the most performant thing ever. Also occasionally it just up and dies on me. But most of the features work as intended. Running Windows 10 Enterprise 1803, build 17134.1. I did not execute any additional patches or modifications to the current github source. ![image](https://user-images.githubusercontent.com/2738471/42599882-7b012b74-8515-11e8-96ef-accc3724fa72.png)

👍 3

Plazmaz commented

2018-07-11 23:23:53 +02:00

(Migrated from github.com)

@aaronsb I was not able to type or click in the terminal using Xming when I tried it.

aaronsb commented

2018-07-12 02:28:04 +02:00

(Migrated from github.com)

From a completely fresh WSL installation (ubuntu) on the mentioned windows version (10, enterprise, 17134.1)

The following commands seem to get required libraries, git clone, compile, and run a working instance of CRT. Now if windows would add support for running programs without an underlying bash prompt we'd be set.

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install qtchooser qt5-default qml-module-qtquick-controls qml-module-qtquick-dialogs qml-module-qtquick-localstorage libqt5qml-graphicaleffects build-essential qtdeclarative5-dev

git clone --recursive https://github.com/Swordfish90/cool-retro-term.git

cd cool-retro-term
qmake && make
cd ..

sudo mv cool-retro-term /opt/cool-retro-term
sudo ln -s /opt/cool-retro-term/cool-retro-term /usr/sbin/cool-retro-term

export DISPLAY=localhost:0
cool-retro-term &

From a completely fresh WSL installation (ubuntu) on the mentioned windows version (10, enterprise, 17134.1) The following commands seem to get required libraries, git clone, compile, and run a working instance of CRT. Now if windows would add support for running programs without an underlying bash prompt we'd be set. ``` sudo apt-get update sudo apt-get upgrade sudo apt-get install qtchooser qt5-default qml-module-qtquick-controls qml-module-qtquick-dialogs qml-module-qtquick-localstorage libqt5qml-graphicaleffects build-essential qtdeclarative5-dev git clone --recursive https://github.com/Swordfish90/cool-retro-term.git cd cool-retro-term qmake && make cd .. sudo mv cool-retro-term /opt/cool-retro-term sudo ln -s /opt/cool-retro-term/cool-retro-term /usr/sbin/cool-retro-term export DISPLAY=localhost:0 cool-retro-term & ```

🎉 7

sne11ius commented

2018-07-12 11:35:51 +02:00

(Migrated from github.com)

@aaronsb Works for me, thanks.

Lana-chan commented

2018-07-22 23:59:10 +02:00

(Migrated from github.com)

@aaronsb I tried the last method and I got it to compile and load but no matter what i try to pipe to crt or use the -e option, I still can't get anything to show on the terminal, ideas?

fullauto223cal commented

2018-07-25 05:35:07 +02:00

(Migrated from github.com)

@aaronsb I followed your steps to the letter. However at the very end it reports that it cannot output to "localhost:0".

sne11ius commented

2018-07-25 09:49:46 +02:00

(Migrated from github.com)

@fullauto223cal Do you have an X server (like xming) running?

😆 2

stalkeriy2010 commented

2018-08-02 16:25:46 +02:00

(Migrated from github.com)

Thanks tovarish, working for me.

asdf23 commented

2018-12-04 14:47:56 +01:00

(Migrated from github.com)

https://github.com/ArcticaProject/vcxsrv ?

Serentty commented

2019-07-05 18:19:48 +02:00

(Migrated from github.com)

Now that Windows has first-class support for third-party terminal emulators through ConPTY, I wonder if it's worth taking another look at this.

👍 11

changbowen commented

2019-09-18 07:18:39 +02:00

(Migrated from github.com)

Not sure if it is the Intel graphics I'm using but I had to disable "Native opengl" in vcxsrv and export LIBGL_ALWAYS_INDIRECT=0 for it to work. Otherwise it is either a black screen or won't start.
It uses over 20% of the CPU constantly but LOOKS SO COOL!!! Worth every percent!

Not sure if it is the Intel graphics I'm using but I had to disable "Native opengl" in vcxsrv and `export LIBGL_ALWAYS_INDIRECT=0` for it to work. Otherwise it is either a black screen or won't start. It uses over 20% of the CPU constantly but LOOKS SO COOL!!! Worth every percent!

changbowen commented

2019-10-28 07:38:15 +01:00

(Migrated from github.com)

On Windows I think the closest look is hyper-postprocessing, a plugin for hyper terminal.
I also forked it and added an amber style looking for a balance between readability, performance, and "coolness".
Currently there is an issue with "inconsistent sharpness" of the texts on Windows and Linux. Other than that it's perfect...

On Windows I think the closest look is [hyper-postprocessing](https://github.com/slammayjammay/hyper-postprocessing), a plugin for hyper terminal. I also [forked](https://github.com/changbowen/hyper-postprocessing) it and added an amber style looking for a balance between readability, performance, and "coolness". Currently there is an issue with "inconsistent sharpness" of the texts on Windows and Linux. Other than that it's perfect...

👍 1

A9G-Data-Droid commented

2019-11-04 21:45:36 +01:00

(Migrated from github.com)

The new Microsoft Terminal is open source. This lends nicely to extension, like a Cool Retro Term plugin.
https://github.com/microsoft/terminal/releases

The new Microsoft Terminal is open source. This lends nicely to extension, like a Cool Retro Term plugin. https://github.com/microsoft/terminal/releases

CapoFantasma97 commented

2021-01-28 12:41:52 +01:00

(Migrated from github.com)

Is this an unreachable dream?

zakukai commented

2021-01-28 13:55:04 +01:00

(Migrated from github.com)

Is this an unreachable dream?

I don't see why: I made some changes and got it working in Cygwin (see my patches above) - but there are still problems with it (freezes and menu failures, etc.), and I haven't been able to take the time to find solutions to those problems. The problems are definitely solveable...

> Is this an unreachable dream? I don't see why: I made some changes and got it working in Cygwin (see my patches above) - but there are still problems with it (freezes and menu failures, etc.), and I haven't been able to take the time to find solutions to those problems. The problems are definitely solveable...

M4CC commented

2021-04-04 09:59:15 +02:00

(Migrated from github.com)

Looking forward for a proper Windows port.

👍 3

AlexAegis commented

2021-05-14 02:21:32 +02:00

(Migrated from github.com)

WSLg is available on Insider builds of windows, if it works there (It should, but I haven't tried) a windows port is no longer necessary.

A9G-Data-Droid commented

2021-05-14 21:35:01 +02:00

(Migrated from github.com)

@AlexAegis I don't think that installing linux is the answer to running on windows. That's like creating a jungle so you can eat a banana. I just tried doing this and it's a terrible long experience that results in gigs of wasted space to run a 32MB program. In the end I got a blank X window. Didn't even get as far as some others in this thread.

AlexAegis commented

2021-05-14 22:15:00 +02:00

(Migrated from github.com)

I'm not talking about running it through an X server. That's not adequate as you won't get any GPU acceleration which is very much a necessary thing for this program. WSLg does enable GPU acceleration and let's you run grahical Linux programs on Windows like they were native. Yes, you do need to install a minimal distro "just to run a 32mb program" but it's still much easier than to port the whole thing over. At least it's something that you can do today.

AlexAegis commented

2021-05-15 01:20:44 +02:00

(Migrated from github.com)

@A9G-Data-Droid I tried it for you, it works, no surprise.

Join the insider dev channel, update, install the preview drivers (linked in the readme of wslg) then just install cool-retro-term in Ubuntu WSL, and there you go. Oh and you also have to update the mesa drivers inside the WSL distro to get opengl acceleration.

(The squares on the image are because I have rune symbols in my prompt and the default font - terminus I think - doesnt support them)

@A9G-Data-Droid I tried it for you, it works, no surprise. ![image](https://user-images.githubusercontent.com/16900547/118340182-47e70900-b51b-11eb-9fb4-2e7728cf07f1.png) Join the insider dev channel, update, install the preview drivers ([linked in the readme of wslg](https://github.com/microsoft/wslg)) then just install cool-retro-term in Ubuntu WSL, and there you go. Oh and you also have to update the mesa drivers inside the WSL distro to get opengl acceleration. (The squares on the image are because I have rune symbols in my prompt and the default font - terminus I think - doesnt support them)

A9G-Data-Droid commented

2021-05-17 17:23:02 +02:00

(Migrated from github.com)

@AlexAegis That's cool that it shows up in the start menu. I like this tight integration. I was using the old version is would seem. I still want a native Windows program but this is certainly cool and retro and terminal.

Quittime commented

2021-05-28 17:16:32 +02:00

(Migrated from github.com)

I really with something became of this 7 years later. I'd love to use this as a terminal emulator on Windows that functions like the command prompt. But it's probably too much to ask for since it would require too much re-writing of code designed for an operating system that functions in a very different way from Windows. I guess all we can hope for is a different terminal emulator which looks like CRT to come along for Windows. Or just enjoy it on Mac or Linux.

A9G-Data-Droid commented

2021-06-11 17:31:02 +02:00

(Migrated from github.com)

So there is a retro pixel shader in Windows Terminal now. It's not as good but it's a place where maybe the cool retro term style could be applied:

fb597ed304/samples/PixelShaders/Retro.hlsl

So there is a retro pixel shader in Windows Terminal now. It's not as good but it's a place where maybe the cool retro term style could be applied: https://github.com/microsoft/terminal/blob/fb597ed304ec6eef245405c9652e9b8a029b821f/samples/PixelShaders/Retro.hlsl

zoomlogo commented

2021-07-08 07:05:20 +02:00

(Migrated from github.com)

Has anyone tried compiling this with MSYS2 (Mingw)

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: seeseemelk/cool-retro-term#40