Re: [9fans] once more: drawterm osx-x11 on x86-64
While I'd agree there could be improvements I like the resizing behavior. I thought it was a nice add. Ian
Re: [9fans] once more: drawterm osx-x11 on x86-64
Not a solution but this is my hack:
This file is $home/bin/rc/startup, envoked by
'exec rio -s -i startup' in $home/lib/profile
--
#!/bin/rc
rfork e
scr=(`{cat /dev/draw/new [2]/dev/null || status=''})
height=$scr(12)
y1=`{echo 'int(' $height '*' 0.12 ')' | hoc}
y2=`{echo 'int(' $height '*' 0.3 ')' | hoc}
y3=`{echo 'int(' $height '*' 0.7 ')' | hoc}
width=$scr(11)
x1=`{echo 'int(' $width '*' 0.1 ')' | hoc}
x2=`{echo $x1 + 1 | hoc}
x3=`{echo 'int(' $x2 + '(' $width '*' 0.5 '))' | hoc}
x4=`{echo $x3 + 1 | hoc}
x6=`{echo $width - $y1 | hoc}
x5=`{echo $x6 - 1 | hoc}
x7=`{echo $width - 1 | hoc}
if(~ $service terminal)
auth/fgui
if(~ $service terminal ! ~ $#cpu 0)
window -r 0 0 $x1 $y1 stats -lmei $sysname $cpu
if not
window -r 0 0 $x1 $y1 stats -lmei
window -r $x2 0 $x3 $y1 faces -i
if(cat /dev/volume [2] /dev/null)
window -r $x4 0 $x5 $y1 audio/tuner
window -r $x6 0 $x7 $y1 clock
window -r $x2 $y2 $x3 $y3 logwin
--
This is $home/bin/rc
--
#!/bin/rc
fortune
calendar -y
news
echo
exec rc -i
/logwin started by the above
--
-Steve
Re: [9fans] once more: drawterm osx-x11 on x86-64
On Sat Feb 28 00:30:20 PST 2015, ba...@bitblocks.com wrote: On Sat, 28 Feb 2015 09:18:24 +0100 cinap_len...@felloff.net wrote: i ment in the context of rio resize. Presumably he means his carefully laid out rio windows get out of kilter (or alignment) when they all get resized. You need a layout engine to keep them looking nice and proportionate. alignment might not be the best term for it. resizing the screen causes rio to scale each window to fit the new screen. the distances from the edge are also scaled. this has the advantage that screen transitions x-(y-x)* are idempotent. there is no way currently for a program to treat the screen in a more sophisticated manner. On Fri Feb 27 18:15:25 PST 2015, sstall...@gmail.com wrote: I might be alone in this, but the resize drives me up the wall. I've had to go out of the way to patch rio to ignore resize updates. I suspect the reason for this is my riostart creates a few windows by default, which end up getting resized when I fullscreen drawterm, throwing everything out of whack. It would be nice if you could add a command line option for this - I started looking at this, but haven't had much time to make a proper patch. i don't see not dealing with screen resizes at all as fundamentally better. i also have this issue, and on a small drawterm on my impossibly small-screen'd mac, resizing causes the default faces configuration goes right across the screen, but not resizing would cause the stats window to disappear off to the right. a quick hack would be to probe the screen pix dimensions and change behavior based on that. but i don't immediately see what the right approach is. do we force windows to declare hints about how they should be resized and when? how does resizing interact with dpi? - erik
Re: [9fans] once more: drawterm osx-x11 on x86-64
what does out of whack mean? Off the rails, perhaps. I presume that it's one of those English expressions (like doubtedly or all but...) that originally meant (rightly) the exact opposite of what it (wrongly) does now: you whack something into place, so it's out of whack if it's not right any more. Lucio.
Re: [9fans] once more: drawterm osx-x11 on x86-64
On Sat, 28 Feb 2015 09:18:24 +0100 cinap_len...@felloff.net wrote: i ment in the context of rio resize. Presumably he means his carefully laid out rio windows get out of kilter (or alignment) when they all get resized. You need a layout engine to keep them looking nice and proportionate.
Re: [9fans] once more: drawterm osx-x11 on x86-64
i ment in the context of rio resize. -- cinap
Re: [9fans] once more: drawterm osx-x11 on x86-64
what does out of whack mean? -- cinap
Re: [9fans] once more: drawterm osx-x11 on x86-64
On 28 Feb 2015 02:21, Jeff Sickel j...@corpus-callosum.com wrote: The older versions of drawterm just map a large view to fill the whole screen and then clip the view to the window size you’ve selected. [etc.] thanks for the explanation. i hadn't quite realised this, as i usually resize only once, to full screen, and never reduce after that. i should also have taken a look at the code. mark.
Re: [9fans] once more: drawterm osx-x11 on x86-64
On Sat, 28 Feb 2015 13:05:51 EST s...@9front.org wrote: On Sat, 28 Feb 2015 09:18:24 +0100 cinap_len...@felloff.net wrote: i ment in the context of rio resize. Presumably he means his carefully laid out rio windows get out of kilter (or alignment) when they all get resized. You need a layout engine to keep them looking nice and proportionate. I think the idea is it's best if the trouble report includes a coherent description of the problem, so strangers don't have to guess. That idea is out of whack.
Re: [9fans] once more: drawterm osx-x11 on x86-64
On Sat, 28 Feb 2015 09:18:24 +0100 cinap_len...@felloff.net wrote: i ment in the context of rio resize. Presumably he means his carefully laid out rio windows get out of kilter (or alignment) when they all get resized. You need a layout engine to keep them looking nice and proportionate. I think the idea is it's best if the trouble report includes a coherent description of the problem, so strangers don't have to guess. sl
Re: [9fans] once more: drawterm osx-x11 on x86-64
On Fri, Feb 27, 2015 at 7:19 PM, Jeff Sickel j...@corpus-callosum.com wrote: The older versions of drawterm just map a large view to fill the whole screen and then clip the view to the window size you’ve selected. When you drag the view it doesn’t resize the internal rio content. That meant that when taking a 1280x1024 window to 2560x1440 everything would stay the same and you’d just see the extra space already allocated. If you draw to the new areas and then resize the window back to the smaller rect you lose easy access to any rio windows created outside of the current clipping rect. The Cocoa version does proper resizing. It’s just a lot of effort to get the same features back into the X11 code base. I might be alone in this, but the resize drives me up the wall. I've had to go out of the way to patch rio to ignore resize updates. I suspect the reason for this is my riostart creates a few windows by default, which end up getting resized when I fullscreen drawterm, throwing everything out of whack. It would be nice if you could add a command line option for this - I started looking at this, but haven't had much time to make a proper patch. Cheers, Steve
Re: [9fans] once more: drawterm osx-x11 on x86-64
On OSX 10.10, X11.app is XQuartz. That said, the changes are all X11 based and if done right should transfer easily to other X11 implementations. -jas On Feb 27, 2015, at 7:09 PM, Sean Hinchee henesy@gmail.com wrote: Is this pure X11.app or XQuartz?
Re: [9fans] once more: drawterm osx-x11 on x86-64
Some people prefer the X11 version as the refresh speed may be higher. That’s fine, though I prefer having rio resize working so I can full screen the app on a second display with CONF=osx-cocoa. I reduced the flicker in the drawterm-cocoa osx-cocoa version a while back. The flicker and window edges not meeting during a move is still there and more prevalent on slow connections or a slow cpu. There are a slew of X11 related changes to support rio resize that I’ve been meaning to push out at some point. Since migrating to OSX 10.10 the X11.app is mostly broken, and no longer supported/released by Apple, so my motivation to finish the changes has dwindled significantly. In fact, the latest X11 update doesn’t extract and install cleanly on OS X 10.10, so updates might take a while. -jas On Feb 26, 2015, at 6:00 PM, Mark van Atten vanattenm...@gmail.com wrote: A while ago, I reported on a problem I had with flicker and broken window edges in drawterm-cocoa CONF=osx-x11. See the email copied below. It led to a brief exchange. With my present configuration, that problem remains: OSX 10.9.5 drawterm-cocoa 2014-12-02 However, I just tried rsc's drawterm 2013-07-02, and there the problem is absent. I take it there are not many users of drawterm on OSX, either jas' or rsc's distribution, who use the x11 version -- are there? I'd be interested to compare notes. Best wishes, Mark. From: Mark van Atten vanattenmark@gma... Subject: drawterm osx-x11 on x86_64 Date: Thu, 21 Nov 2013 11:40:14 +0100 For the record---to compile drawterm (http://code.google.com/p/drawterm/) with CONF=osx-x11 on x86_64 (in my case running 10.8.5), just add the required substitution to the makefile: Make.osx-x11 20 - arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/'`; \ 20 + arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/;s/x86_64/amd64/'`; \ For the moment, I prefer this to drawterm-cocoa because there is no flicker, and window borders remain intact when reshaping with B1 or B2. Mark.
Re: [9fans] once more: drawterm osx-x11 on x86-64
On 28 February 2015 at 00:10, Jeff Sickel j...@corpus-callosum.com wrote: Some people prefer the X11 version as the refresh speed may be higher. That’s fine, though I prefer having rio resize working so I can full screen the app on a second display with CONF=osx-cocoa. Would it be possible to get working devwsys[1] in OSX with X11? I have no idea how difficult this would be, probably more or less as difficult as getting Inferno. Has anybody tried that? [1] https://bitbucket.org/yiyus/devwsys-prev -- - yiyus || JGL .
Re: [9fans] once more: drawterm osx-x11 on x86-64
Is this pure X11.app or XQuartz? On 2/27/15 5:10 PM, Jeff Sickel wrote: Some people prefer the X11 version as the refresh speed may be higher. That’s fine, though I prefer having rio resize working so I can full screen the app on a second display with CONF=osx-cocoa. I reduced the flicker in the drawterm-cocoa osx-cocoa version a while back. The flicker and window edges not meeting during a move is still there and more prevalent on slow connections or a slow cpu. There are a slew of X11 related changes to support rio resize that I’ve been meaning to push out at some point. Since migrating to OSX 10.10 the X11.app is mostly broken, and no longer supported/released by Apple, so my motivation to finish the changes has dwindled significantly. In fact, the latest X11 update doesn’t extract and install cleanly on OS X 10.10, so updates might take a while. -jas On Feb 26, 2015, at 6:00 PM, Mark van Atten vanattenm...@gmail.com wrote: A while ago, I reported on a problem I had with flicker and broken window edges in drawterm-cocoa CONF=osx-x11. See the email copied below. It led to a brief exchange. With my present configuration, that problem remains: OSX 10.9.5 drawterm-cocoa 2014-12-02 However, I just tried rsc's drawterm 2013-07-02, and there the problem is absent. I take it there are not many users of drawterm on OSX, either jas' or rsc's distribution, who use the x11 version -- are there? I'd be interested to compare notes. Best wishes, Mark. From: Mark van Atten vanattenmark@gma... Subject: drawterm osx-x11 on x86_64 Date: Thu, 21 Nov 2013 11:40:14 +0100 For the record---to compile drawterm (http://code.google.com/p/drawterm/) with CONF=osx-x11 on x86_64 (in my case running 10.8.5), just add the required substitution to the makefile: Make.osx-x11 20 - arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/'`; \ 20 + arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/;s/x86_64/amd64/'`; \ For the moment, I prefer this to drawterm-cocoa because there is no flicker, and window borders remain intact when reshaping with B1 or B2. Mark.
Re: [9fans] once more: drawterm osx-x11 on x86-64
The older versions of drawterm just map a large view to fill the whole screen and then clip the view to the window size you’ve selected. When you drag the view it doesn’t resize the internal rio content. That meant that when taking a 1280x1024 window to 2560x1440 everything would stay the same and you’d just see the extra space already allocated. If you draw to the new areas and then resize the window back to the smaller rect you lose easy access to any rio windows created outside of the current clipping rect. The Cocoa version does proper resizing. It’s just a lot of effort to get the same features back into the X11 code base. -jas On Feb 27, 2015, at 5:27 PM, Mark van Atten vanattenm...@gmail.com wrote: With the X11 version, drawterm can be resized with B1, and with xshove it can be turned full screen. (On X11, I use p9p's rio as my wm.) I look forward to any changes you may come up with; and many thanks for the work you have done so far! Mark.
Re: [9fans] once more: drawterm osx-x11 on x86-64
Sorry, last night it was getting too late and I confused. It is drawterm-cocoa CONF=osx-cocoa that still shows the flickering and the broken window edges. drawterm-cocoa CONF=osx-x11 works fine (but to be able to build it, I had to copy some header files that were not found (although present in the tree) to ./include. Sorry for the noise. Mark.
Re: [9fans] once more: drawterm osx-x11 on x86-64
With the X11 version, drawterm can be resized with B1, and with xshove it can be turned full screen. (On X11, I use p9p's rio as my wm.) I look forward to any changes you may come up with; and many thanks for the work you have done so far! Mark.
[9fans] once more: drawterm osx-x11 on x86-64
A while ago, I reported on a problem I had with flicker and broken window edges in drawterm-cocoa CONF=osx-x11. See the email copied below. It led to a brief exchange. With my present configuration, that problem remains: OSX 10.9.5 drawterm-cocoa 2014-12-02 However, I just tried rsc's drawterm 2013-07-02, and there the problem is absent. I take it there are not many users of drawterm on OSX, either jas' or rsc's distribution, who use the x11 version -- are there? I'd be interested to compare notes. Best wishes, Mark. From: Mark van Atten vanattenmark@gma... Subject: drawterm osx-x11 on x86_64 Date: Thu, 21 Nov 2013 11:40:14 +0100 For the record---to compile drawterm (http://code.google.com/p/drawterm/) with CONF=osx-x11 on x86_64 (in my case running 10.8.5), just add the required substitution to the makefile: Make.osx-x11 20 - arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/'`; \ 20 + arch=`uname -m|sed 's/i.86/386/;s/Power Macintosh/power/;s/x86_64/amd64/'`; \ For the moment, I prefer this to drawterm-cocoa because there is no flicker, and window borders remain intact when reshaping with B1 or B2. Mark.
