• Dynamic screen resizing

    From Kirkman@VERT/GUARDIAN to All on Wed Dec 3 10:48:25 2014
    The last few days I've seen a couple oversized ANSI artworks posted onãFacebook: one 160 chars wide, and the other 200 chars wide.ããThat got me thinking. A bigger canvas lets you create more detailed graphics,ãwhich sure would be nice to use in BBS interfaces or games. It's alreadyãpossible to do that, I know, but it requires that users configure theirãterminal prior to connecting to the BBS. Not many would do that.ããSo could there be (or is there) a way for a JS app on the BBS to signal toãSyncTerm to resize itself to larger dimensions? Like when you play a PC game,ãand it changes the screen resolution by itself, and then resets once you quit.ãã--Joshãã////--------------------------------------------------ãBiC -=- http://breakintochat.com -=- bbs wiki and blogãã---ã þ Synchronetã
  • From Nightfox@VERT/DIGDIST to Kirkman on Wed Dec 3 12:51:18 2014
    The last few days I've seen a couple oversized ANSI artworks posted onã > Facebook: one 160 chars wide, and the other 200 chars wide.ã > ã > That got me thinking. A bigger canvas lets you create more detailedã > graphics, which sure would be nice to use in BBS interfaces or games. ãIt'sã > already possible to do that, I know, but it requires that users ãconfigureã > their terminal prior to connecting to the BBS. Not many would do that.ã > ã > So could there be (or is there) a way for a JS app on the BBS to signal ãtoã > SyncTerm to resize itself to larger dimensions? Like when you play a PCã > game, and it changes the screen resolution by itself, and then resets ãonceã > you quit.ããThat's an interesting idea, but the downside is that it would be a proprietaryãthing supported by SyncTerm and Synchronet, and other terminal software mightãnever adopt that standard. At the very least, it shouldn't break otherãterminal programs, but such large ANSIs would look ugly on ãthose terminal programs, as you describe. Also, there are some people whoãlike to configure old DOS terminal programs in an emulator to be used overãtelnet for the nostalgia factor, and those terminals of course are no ãlonger being updated.ããUnfortunately, the best option is probably to stick with the 80x25 canvas sizeãfor ANSI graphics if you intend to display the art over a terminal connectionãand you don't want your users to have to reconfigure their terminal sizeãbefore connecting.ããNightfoxãã---ã þ Synchronet þ Digital Distortion BBS - digitaldistortionbbs.comã
  • From spacesst@VERT/SPACESST to Nightfox on Wed Dec 3 19:52:05 2014
    Re: Dynamic screen resizingã By: Nightfox to Kirkman on Wed Dec 03 2014 12:51:18ãã > Unfortunately, the best option is probably to stick with the 80x25 canvasã > size for ANSI graphics if you intend to display the art over a terminalã > connection and you don't want your users to have to reconfigure theirã > terminal size before connecting.ãã I use Telnet Client on my Windows ,Work ok ansi okã But no Transfersãããã
    ãã---ã þ Synchronet þ SPACESST BBSã
  • From Kirkman@VERT/GUARDIAN to Nightfox on Wed Dec 3 22:31:12 2014
    That's an interesting idea, but the downside is that it would be aã > proprietary thing supported by SyncTerm and Synchronet, and other terminalã > software might never adopt that standard. At the very least, it shouldn'tã > break other terminal programs, but such large ANSIs would look ugly onã > those terminal programs, as you describe. Also, there are some people whoã > like to configure old DOS terminal programs in an emulator to be used overã > telnet for the nostalgia factor, and those terminals of course are noã > longer being updated.ããIf the hooks to make this work existed within SyncTerm and Synchronet, then itãwould be up to the sysop/app developer to handle it gracefully, much the sameãway that good web design should degrade gracefully for people using olderãbrowsers.ããYou could have your app check for the end user's terminal capabilities. Ifãthey were using a SyncTerm that supported the resizing feature, then go aheadãand serve an enlarged, enhanced experience. If not, stick to the standardã80x25.ããAnyway, at this point the user base is so small that this idea probablyãdoesn't matter. But when I saw those oversized ANSIs, I imagined how cool itãcould be to see games like Chicken Delivery or Star Trek on a larger canvasã(with more graphical detail possible). ãã--Joshãã////--------------------------------------------------ãBiC -=- http://breakintochat.com -=- bbs wiki and blogãã---ã þ Synchronetã
  • From Mro@VERT/BBSESINF to spacesst on Wed Dec 3 23:27:20 2014
    Re: Dynamic screen resizingã By: spacesst to Nightfox on Wed Dec 03 2014 07:52 pmãã > > canvas size for ANSI graphics if you intend to display the art over aã > > terminal connection and you don't want your users to have to reconfigureã > > their terminal size before connecting.ãã > I use Telnet Client on my Windows ,Work ok ansi okã > But no Transfersããããthat's because it doesnt have transfer capability built inã---ã þ Synchronet þ ::: BBSES.info - free BBS services :::ã
  • From Nightfox@VERT/DIGDIST to Kirkman on Thu Dec 4 07:57:43 2014
    Re: Re: Dynamic screen resizingã By: Kirkman to Nightfox on Wed Dec 03 2014 22:31:12ãã Ki> If the hooks to make this work existed within SyncTerm and Synchronet,ã Ki> then it would be up to the sysop/app developer to handle it gracefully,ã Ki> much the same way that good web design should degrade gracefully forã Ki> people using older browsers.ãã Ki> You could have your app check for the end user's terminal capabilities. Ifã Ki> they were using a SyncTerm that supported the resizing feature, then goã Ki> ahead and serve an enlarged, enhanced experience. If not, stick to theã Ki> standard 80x25.ããFor that to work best, it would be best to have different versions of an ANSI -ãOne oversized and another 80x25. Most ANSIs are drawn in only one size though.ãPerhaps the alternative would simply be not to show an oversized ANSI forãsomeone with a terminal that's not large enough or can't be expanded.ããMy main point, though, was that dynamic terminal resizing is currently not partãof any BBS client standard (that I know of). Going with your web developmentãanalogy, adding something like that to Synchronet & SyncTerm would be akin toãMicrosoft making their own changes to Internet Explorer that nobody elseãsupports. That isn't necessarily a good idea.ããNightfoxãã---ã þ Synchronet þ Digital Distortion BBS - digitaldistortionbbs.comã
  • From LaRRy LaGoMoRpH@VERT/GRUDGEDU to Kirkman on Fri Dec 5 01:00:05 2014
    Re: Re: Dynamic screen resizingã By: Kirkman to Nightfox on Wed Dec 03 2014 10:31 pmããKirkman, while my board's going through some changes right now, I justãinstalled a new shell I wrote (probably has some kinks) that is designed to runãin a variety of terminal sizes (although some ANSI's get screwed up when youãchange the terminal size, specifically my login matrix screen). ããI used the console.screen_rows and .screen_columns properties to set myãframe_sizes relative to each other so that larger (and smaller) sizes than 80 xã25 are supported. In fact it looks pretty bad at a 80 x 24. I've got itãrunning in 203 x 69 resolution right now, and it can go as high as memoryãallows. ããI don't see any issues launching games or stuff designed for smaller termsãwithin the context of my shell - except maybe an excessive amount of screenãreal estate when the games run off to the sides.ããJust finished this new shell (or finished enough to make it live, more featuresãare coming) yesterday - but if you feel like checking it out, it will adapt toãthe resolution that you use when you connect initially (no live screen resizingãfor now). I still need to fix some ANSI's so they display properly at largerãwidths - so ignore that if you visit.ããcheersãll morph G futureland.grudgemirror.com LaRRy LaGoMoRpH\-/ã Oã =M=ã'not your average board check it out' /-\ããã---ã þ Synchronet þ Futureland.Grudgemirror.Com ** LIVE ** Music andã
  • From Ree@VERT/FTELNET to Kirkman on Fri Dec 5 09:25:21 2014
    You could have your app check for the end user's terminal capabilities. Ifã > they were using a SyncTerm that supported the resizing feature, then goã > ahead and serve an enlarged, enhanced experience. If not, stick to theã > standard 80x25.ããI don't think it even needs to check ahead of time. Just send the "resize"ãcommand followed by the "detect screen size" sequences. (I guess you need toãwait for the cursor position response to come back to know whether the sizeãchanged though.)ããIf Deuce adds a command for this to SyncTerm, I'd likely implement it inãfTelnet as well.ãã---ã þ Synchronet þ R&M Software Support BBSã
  • From Ree@VERT/FTELNET to Nightfox on Fri Dec 5 09:34:45 2014
    My main point, though, was that dynamic terminal resizing is currently notã > part of any BBS client standard (that I know of). Going with your webã > development analogy, adding something like that to Synchronet & SyncTermã > would be akin to Microsoft making their own changes to Internet Explorerã > that nobody else supports. That isn't necessarily a good idea.ããI think it's actually a great idea. That's how some really cool features cameãabout. For example Canvas was first implemented by Apple for WebKit, thenãGecko added it, then Opera, then eventually it became a standard.ããSo Apple creating Canvas wasn't a bad idea. And someone making use of Canvasãto dynamically manipulate an image while still showing the stock image toãbrowsers that don't support Canvas is also not a bad idea. And that isãexactly what is being proposed here. Try to use a larger screen if it isãsupported, but use 80x24 (or whatever) as a fallback if it's not supported.ãã---ã þ Synchronet þ R&M Software Support BBSã
  • From Mindless Automaton@VERT/ELDRITCH to Ree on Fri Dec 5 15:25:56 2014
    On 12/5/2014 9:25 AM, Ree wrote:
    > You could have your app check for the end user's terminal capabilities. If
    > they were using a SyncTerm that supported the resizing feature, then go
    > ahead and serve an enlarged, enhanced experience. If not, stick to the
    > standard 80x25.

    I don't think it even needs to check ahead of time. Just send the "resize" command followed by the "detect screen size" sequences. (I guess you need to wait for the cursor position response to come back to know whether the size changed though.)

    If Deuce adds a command for this to SyncTerm, I'd likely implement it in fTelnet as well.

    Next up, 32 bit color!

    http://doryen.eptalys.net/data/libtcod/doc/1.5.1/html2/color.html?c=false&cpp=false&cs=false&py=false&lua=false

    -Mindless Automaton
    ---
    þ Synchronet þ Eldritch Clockwork BBS - eldritch.darktech.org
  • From Deuce@VERT/SYNCNIX to Kirkman on Mon Dec 8 21:10:38 2014
    Re: Dynamic screen resizingã By: Kirkman to All on Wed Dec 03 2014 10:48 amãã > So could there be (or is there) a way for a JS app on the BBS to signal toã > SyncTerm to resize itself to larger dimensions? Like when you play a PCã > game, and it changes the screen resolution by itself, and then resets onceã > you quit.ããIt's possible (there is no such feature currently), but it would cause a lot of
    usability issues. For example, if you switch to 132 column mode, and the screen isn't wide enough to support it at your current zoom level, what should happen?ããPotential problems like that, and the difficulties that would happen due to how
    the scrollback is managed and such make it "too hard to be worth it".ãã---ãhttp://DuckDuckGo.com/ a better search engine that respects your privacy.ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã
  • From Deuce@VERT/SYNCNIX to Nightfox on Mon Dec 8 21:12:53 2014
    Re: Re: Dynamic screen resizingã By: Nightfox to Kirkman on Thu Dec 04 2014 07:57 amãã > My main point, though, was that dynamic terminal resizing is currently notã > part of any BBS client standard (that I know of).ããANSI.SYS supported screen mode changes, and VT terminals supported switching
    to/from 132 column mode, so there are sequencies and terminals in the wild that
    support the feature.ãããã---ãhttp://DuckDuckGo.com/ a better search engine that respects your privacy.ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã
  • From Deuce@VERT/SYNCNIX to Ree on Mon Dec 8 21:15:15 2014
    Re: Re: Dynamic screen resizingã By: Ree to Kirkman on Fri Dec 05 2014 09:25 amãã > I don't think it even needs to check ahead of time. Just send the "resize"ã > command followed by the "detect screen size" sequences. (I guess you needã > to wait for the cursor position response to come back to know whether theã > size changed though.)ããAnd hope that the terminal doesn't do "something else" when you send the
    sequence.ãã > If Deuce adds a command for this to SyncTerm, I'd likely implement it inã > fTelnet as well.ããI don't plan to, but if the initial problems suggest a solution, I could likelyãbe convinted to look into it further.ãã---ãhttp://DuckDuckGo.com/ a better search engine that respects your privacy.ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã
  • From Deuce@VERT/SYNCNIX to Mindless Automaton on Mon Dec 8 21:18:33 2014
    Re: Re: Dynamic screen resizingã By: Mindless Automaton to Ree on Fri Dec 05 2014 03:25 pmãã > Next up, 32 bit color!ãã24-bit is much more likely... that link seems to describe 24-bit colour, but
    call it 32-bit.ããAnd until I come up with something I like to unscrew the inscrutable problem of
    how to make 24-bit colour to the 8/16 colour palette we have now, I'm unlikely to implement it.ãã---ãhttp://DuckDuckGo.com/ a better search engine that respects your privacy.ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã
  • From Mindless Automaton@VERT/ELDRITCH to Deuce on Tue Dec 9 10:22:24 2014
    On 12/9/2014 12:18 AM, Deuce wrote:
    Re: Re: Dynamic screen resizing
    By: Mindless Automaton to Ree on Fri Dec 05 2014 03:25 pm

    > Next up, 32 bit color!

    24-bit is much more likely... that link seems to describe 24-bit colour, but call it 32-bit.

    And until I come up with something I like to unscrew the inscrutable problem of
    how to make 24-bit colour to the 8/16 colour palette we have now, I'm unlikely
    to implement it.

    Well if you get 24 in there, why not throw in 8 more? ;)

    This sounds like a job for.. someone else!

    -Mindless Automaton
    ---
    þ Synchronet þ Eldritch Clockwork BBS - eldritch.darktech.org
  • From Mindless Automaton@VERT/ELDRITCH to Deuce on Tue Apr 7 23:55:16 2015
    On 12/9/2014 12:18 AM, Deuce wrote:
    Re: Re: Dynamic screen resizing
    By: Mindless Automaton to Ree on Fri Dec 05 2014 03:25 pm

    > Next up, 32 bit color!

    24-bit is much more likely... that link seems to describe 24-bit colour, but call it 32-bit.

    And until I come up with something I like to unscrew the inscrutable problem of
    how to make 24-bit colour to the 8/16 colour palette we have now, I'm unlikely
    to implement it.

    How about 8-bit?

    http://fansi.org/256Colors.aspx

    -Mindless Automaton
    ---
    þ Synchronet þ Eldritch Clockwork BBS - eldritch.darktech.org
  • From Deuce@VERT/SYNCNIX to Mindless Automaton on Wed Apr 8 23:06:32 2015
    Re: Re: Dynamic screen resizingã By: Mindless Automaton to Deuce on Tue Apr 07 2015 11:55 pmãã > > And until I come up with something I like to unscrew the inscrutableã > > problem of how to make 24-bit colour to the 8/16 colour palette we haveã > > now, I'm unlikely to implement it.ã >ã > How about 8-bit?ã >ã > http://fansi.org/256Colors.aspxããThey're both on The List for the console overhaul I'll be doing after the 1.0
    release of SyncTERM.ãã---ãhttp://DuckDuckGo.com/ a better search engine that respects your privacy.ã þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)ã