Re: [9fans] once more: drawterm osx-x11 on x86-64

Re: [9fans] once more: drawterm osx-x11 on x86-64

[sl]

> On Sat, 28 Feb 2015 09:18:24 +0100 cinap_lenrek@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

[Bakul Shah]

On Sat, 28 Feb 2015 13:05:51 EST sl@9front.org wrote:
> > On Sat, 28 Feb 2015 09:18:24 +0100 cinap_lenrek@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

[michaelian ennis]

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

[Steve Simon]

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

[erik quanstrom]

On Sat Feb 28 00:30:20 PST 2015, bakul@bitblocks.com wrote:
> On Sat, 28 Feb 2015 09:18:24 +0100 cinap_lenrek@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, sstallion@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

[Mark van Atten]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

On 28 Feb 2015 02:21, "Jeff Sickel" <jas@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.

[-- Attachment #2: Type: text/html, Size: 603 bytes --]

Re: [9fans] once more: drawterm osx-x11 on x86-64

[Bakul Shah]

On Sat, 28 Feb 2015 09:18:24 +0100 cinap_lenrek@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

[cinap_lenrek]

i ment in the context of rio resize.

--
cinap

Re: [9fans] once more: drawterm osx-x11 on x86-64

[lucio]

> 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

[cinap_lenrek]

what does "out of whack" mean?

--
cinap

Re: [9fans] once more: drawterm osx-x11 on x86-64

[Steven Stallion]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On Fri, Feb 27, 2015 at 7:19 PM, Jeff Sickel <jas@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

[-- Attachment #2: Type: text/html, Size: 1628 bytes --]

Re: [9fans] once more: drawterm osx-x11 on x86-64

[Jeff Sickel]

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.dev@gmail.com> wrote:
>
> Is this pure X11.app or XQuartz?

Re: [9fans] once more: drawterm osx-x11 on x86-64

[Jeff Sickel]

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 <vanattenmark@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

[Sean Hinchee]

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 <vanattenmark@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

[yy]

On 28 February 2015 at 00:10, Jeff Sickel <jas@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

[Mark van Atten]

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

[Jeff Sickel]

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 <vanattenmark@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

[Mark van Atten]

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.

[9fans] once more: drawterm osx-x11 on x86-64

[Mark van Atten]

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.