Hi DM,
On Linux, when Synchronet runs a dosemu door, is there a way to have dosemu appear in its own window (when using a GUI environment)? Currently, if user is running a DOS door, dosemu does not show on the screen. But that could be useful for some sysop pager doors (such as IceChat), so that the sysop could select the dosemu window where IceChat is running on the BBS machine and chat with the user.
IceChat), so that the sysop could select the dosemu window where
IceChat is running on the BBS machine and chat with the user.
I don't know. I've never run DOSemu myself and don't much about it's options or abilities.
Re: dosemu doors in a visible window
By: Digital Man to Nightfox on Sat Jun 25 2022 05:41 pm
IceChat), so that the sysop could select the dosemu window where
IceChat is running on the BBS machine and chat with the user.
I don't know. I've never run DOSemu myself and don't much about it's options or abilities.
Ah. Who could I ask about that then? Was it Deuce who added dosemu support to Synchronet?
Hi DM,
On Linux, when Synchronet runs a dosemu door, is there a way to have dosemu appear in its own window (when using a GUI environment)? Currently, if user is running a DOS door, dosemu does not show on the screen. But that could be useful for some sysop pager doors (such as IceChat), so that the sysop could select the dosemu window where IceChat is running on the BBS machine and chat with the user.
Nightfox
---
� Synchronet � Digital Distortion: digitaldistortionbbs.com
maybe you can export DISPLAY=:0 environment var where run specific door (eje some chat) and run dosemu with -X or -S option
the problem I see is that dosemu doesn't fallback to text mode if it doesn't find an X display , so it won't start.
Maybe doing some wrapper script in bash that does this verification
On Linux, when Synchronet runs a dosemu door, is there a way to have
dosemu appear in its own window (when using a GUI environment)?
Currently, if user is running a DOS door, dosemu does not show on the screen. But that could be useful for some sysop pager doors (such as IceChat), so that the sysop could select the dosemu window where
IceChat is running on the BBS machine and chat with the user.
On Linux, when Synchronet runs a dosemu door, is there a way to have
dosemu appear in its own window (when using a GUI environment)?
Doubtful, since the DOSemu runtime may well not know that there's even a GUI environment... and depending on configuration, likely a different user than your desktop user for that matter.
Re: Re: dosemu doors in a visible window
By: Tracker1 to Nightfox on Wed Jul 06 2022 05:30 pm
On Linux, when Synchronet runs a dosemu door, is there a way to have
dosemu appear in its own window (when using a GUI environment)?
Doubtful, since the DOSemu runtime may well not know that there's even a GUI environment... and depending on configuration, likely a different user than your desktop user for that matter.
Makes sense.
One thing that just occured to me though, is that some Linux terminal programs let you run them with a command line as an argument, and when you run a terminal program like that, the terminal will appear in its own window and run the command line you specified. I wonder if that might be doable for DOS doors. But I'm not sure it's worth going through all my door configurations to do that.
You most recently posted messages aren't word-wrapping upon display in Synchronet's internal message reader now (although, it quotes fine as above). You change something?
You most recently posted messages aren't word-wrapping upon display in Synchronet's internal message reader now (although, it quotes fine as above). You change something?
I see what is: you started inserted raw ANSI escape sequences into your message signature:
Synchronet doesn't attempt to word-wrap messages that contain ANSI escape sequences.
I see what is: you started inserted raw ANSI escape sequences into your message signature:
Synchronet doesn't attempt to word-wrap messages that contain ANSI escape sequences.
Re: Re: dosemu doors in a visible window
By: Digital Man to Nightfox on Thu Jul 07 2022 12:17 pm
You most recently posted messages aren't word-wrapping upon display in Synchronet's internal message reader now (although, it quotes fine as above). You change something?
I haven't changed anything for word wrapping. I recently updated SlyEdit to allow text coloring, but I didn't change anything regarding word wrapping.
Some time ago though (a couple years or so), there was some discussion about whether message editors should wrap text at 80 (or 79) columns upon saving. At the time I had updated SlyEdit so that it would not wrap the text (basically, each 'paragraph' would be a long stentence), as my understanding would be that message readers should wrap according to their terminal width.
I hadn't changed that (at least, not intentionally), but I'll look at it again.
Re: Re: dosemu doors in a visible window
By: Digital Man to Nightfox on Thu Jul 07 2022 12:22 pm
I see what is: you started inserted raw ANSI escape sequences into your message signature:
Synchronet doesn't attempt to word-wrap messages that contain ANSIescape
sequences.
I have configured my SlyEdit to not convert color & attribute codes to ANSI upon saving (so they should be saved as Synchronet attribute codes). With this change, hopefully this message will wrap properly, even with the inclusion of the green attribute.
Confirmed: the message displayed nicely (wrapped).
Re: Re: dosemu doors in a visible window
By: Digital Man to Nightfox on Thu Jul 07 2022 03:55 pm
Confirmed: the message displayed nicely (wrapped).
Thanks.
Nightfox
And if you want to use a colors in your message or signature, just save them as Ctrl-A codes. Synchronet's various message networking methods already support stripping or converting Ctrl-A codes (e.g. to ANSI) as necessary to support other (non-Synchronet) systems.
If a non-Synchronet BBS has a networked sub-board (either via QWK or FTN) and a message was posted with Ctrl-A codes, does that mean the Ctrl-A codes will be removed/converted by the time their BBS imports the message?
On Linux, when Synchronet runs a dosemu door, is there a way to
have dosemu appear in its own window (when using a GUI
environment)?
Doubtful, since the DOSemu runtime may well not know that there's
even a GUI environment... and depending on configuration, likely a
different user than your desktop user for that matter.
Makes sense.
One thing that just occured to me though, is that some Linux terminal programs let you run them with a command line as an argument, and when
you run a terminal program like that, the terminal will appear in its
own window and run the command line you specified. I wonder if that
might be doable for DOS doors. But I'm not sure it's worth going
through all my door configurations to do that.
If a non-Synchronet BBS has a networked sub-board (either via QWK or FTN)
and a message was posted with Ctrl-A codes, does that mean the Ctrl-A codes >> will be removed/converted by the time their BBS imports the message?
Normally, yes.
On 7/8/22 13:05, Digital Man wrote:
If a non-Synchronet BBS has a networked sub-board (either via QWK or FTN) >> and a message was posted with Ctrl-A codes, does that mean the Ctrl-A codes >> will be removed/converted by the time their BBS imports the message?
Normally, yes.
Maybe slightly convoluted, how hard would it be to detect if the message *only* has color codes, and convert back to ctrl-a on import/post?
Maybe slightly convoluted, how hard would it be to detect if the
message *only* has color codes, and convert back to ctrl-a on
import/post?
I don't understand the question. Ctrl-A *is* a color code. And a
message that contained *only* color codes would most likely just
display as nothing (blank) unless the author was very creative with non-black background colors and white-space. But why would they?
On 7/11/22 19:23, Digital Man wrote:
Maybe slightly convoluted, how hard would it be to detect if the
message *only* has color codes, and convert back to ctrl-a on
import/post?
I don't understand the question. Ctrl-A *is* a color code. And a
message that contained *only* color codes would most likely just
display as nothing (blank) unless the author was very creative with non-black background colors and white-space. But why would they?
I mean converting ANSI sequences that only contains color changes to
CTRL-A codes.
Maybe slightly convoluted, how hard would it be to detect if the
message *only* has color codes, and convert back to ctrl-a on
import/post?
I don't understand the question. Ctrl-A *is* a color code. And a
message that contained *only* color codes would most likely just
display as nothing (blank) unless the author was very creative with
non-black background colors and white-space. But why would they?
I mean converting ANSI sequences that only contains color changes to
CTRL-A codes.
Oh, I suppose anything's possible. But why?
On 7/17/22 22:22, Digital Man wrote:
Maybe slightly convoluted, how hard would it be to detect if the
message *only* has color codes, and convert back to ctrl-a on
import/post?
I don't understand the question. Ctrl-A *is* a color code. And a
message that contained *only* color codes would most likely just
display as nothing (blank) unless the author was very creative with
non-black background colors and white-space. But why would they?
I mean converting ANSI sequences that only contains color changes to
CTRL-A codes.
Oh, I suppose anything's possible. But why?
So that the "ansi" rules for display can be avoided when it's only color changes... so that the line count can still work.
Also, being able to only send ctrl-a codes to other sync bbses in qwk
nets that don't need the extra ansi as well.
So that the "ansi" rules for display can be avoided when it's
only color changes... so that the line count can still work.
Synchronet doesn't parse ANSI escape sequences out of files for
display. It just sends them to the remote terminal, generally.
Also, being able to only send ctrl-a codes to other sync bbses in
qwk nets that don't need the extra ansi as well.
Yeah, so just store Ctrl-A codes in the message base to begin with.
On 7/25/22 17:02, Digital Man wrote:
So that the "ansi" rules for display can be avoided when it's
only color changes... so that the line count can still work.
Synchronet doesn't parse ANSI escape sequences out of files for
display. It just sends them to the remote terminal, generally.
I know... that's why I asked.
Also, being able to only send ctrl-a codes to other sync bbses in
qwk nets that don't need the extra ansi as well.
Yeah, so just store Ctrl-A codes in the message base to begin with.
That's the idea... as *I* don't control what others post, but
would/could be beneficial to potentially improving the overall user experience.
On 7/25/22 17:02, Digital Man wrote:
So that the "ansi" rules for display can be avoided when it's
only color changes... so that the line count can still work.
Synchronet doesn't parse ANSI escape sequences out of files for
display. It just sends them to the remote terminal, generally.
I know... that's why I asked.
Also, being able to only send ctrl-a codes to other sync bbses in
qwk nets that don't need the extra ansi as well.
Yeah, so just store Ctrl-A codes in the message base to begin with.
That's the idea... as *I* don't control what others post, but
would/could be beneficial to potentially improving the overall user
experience.
Re: Re: dosemu doors in a visible window
By: Digital Man to Tracker1 on Tue Jul 26 2022 05:00 pm
On 7/25/22 17:02, Digital Man wrote:
So that the "ansi" rules for display can be avoided when it's
only color changes... so that the line count can still work.
Synchronet doesn't parse ANSI escape sequences out of files for
display. It just sends them to the remote terminal, generally.
I know... that's why I asked.
Also, being able to only send ctrl-a codes to other sync bbses in
qwk nets that don't need the extra ansi as well.
Yeah, so just store Ctrl-A codes in the message base to begin with.
That's the idea... as *I* don't control what others post, but
would/could be beneficial to potentially improving the overall user
experience.
Rob, sorry to jump in, but I've been somewhat following, but at the same time I'm confused. If I want to send out color in a message, knowing it will be sent to other synchronet systems, plus non synchronet systems, am I better off to send it out using ansi codes, or Ctrl-A codes.
I guess what
I'm asking, when sbbsecho sends the message out, will it convert ctrl-a codes to ansi, or vice versa, or leave it as is.
In fidonet, I just have it
strip out the color, but I'm asking for like dovenet, or other ftn areas that allow color. At the present, I've got Slyedit to use ansi when I want to put color in a message, but the default is to use Ctrl-a codes.
Re: Re: dosemu doors in a visible window
By: DesotoFireflite to Digital Man on Wed Jul 27 2022 07:30 am
On 7/25/22 17:02, Digital Man wrote:
So that the "ansi" rules for display can be avoided when it's
only color changes... so that the line count can still work.
Synchronet doesn't parse ANSI escape sequences out of files for
display. It just sends them to the remote terminal, generally.
I know... that's why I asked.
Also, being able to only send ctrl-a codes to other sync bbses
in qwk nets that don't need the extra ansi as well.
Yeah, so just store Ctrl-A codes in the message base to begin
with.
That's the idea... as *I* don't control what others post, but
would/could be beneficial to potentially improving the overall user
experience.
Rob, sorry to jump in, but I've been somewhat following, but at the
same time I'm confused. If I want to send out color in a message,
knowing it will be sent to other synchronet systems, plus non
synchronet systems, am I better off to send it out using ansi codes,
or Ctrl-A codes.
Better of to send as Ctrl-A codes and "non synchronet systems" will just get plain ASCII (no color).
I guess what
I'm asking, when sbbsecho sends the message out, will it convert
ctrl-a codes to ansi, or vice versa, or leave it as is.
SBBSecho can strip Ctrl-A codes are leave them in place.
In fidonet, I just have it
strip out the color, but I'm asking for like dovenet, or other ftn
areas that allow color. At the present, I've got Slyedit to use ansi
when I want to put color in a message, but the default is to use
Ctrl-a codes.
It's feasiable to add an "expand to ANSI" option for SBBSecho, but nobody has ever asked for that feature.
Okay, I think I understand: you want to have to option to have
SBBSecho or sbbs (e.g. for QWK-packet import) to convert simple
ANSI escape sequences to corresponding Ctrl-A codes. I do have
the logic to do this as we do this for FILE_ID.ANS import already.
Did you file an issue on gitlab for this request?
So you are saying that you could add a feature to expand Ctrl-a codes to ansi for outbound messages. That would be a Win Win for non Synchronet systems
for echos that allow colors. Sounds like a nice idea. Do you want me to put in a formal request on GEtHub, or is this good enough :)
| Sysop: | Nelgin |
|---|---|
| Location: | Plano, TX |
| Users: | 513 |
| Nodes: | 10 (1 / 9) |
| Uptime: | 10:23:14 |
| Calls: | 8,287 |
| Files: | 15,517 |
| Messages: | 928,456 |