While I'd agree there could be improvements I like the resizing behavior. I
thought it was a nice add.
Ian
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 '
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 nee
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. Yo
> 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 proportiona
On 28 Feb 2015 02:21, "Jeff Sickel" 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 scree
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 ment in the context of rio resize.
--
cinap
> 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
what does "out of whack" mean?
--
cinap
On Fri, Feb 27, 2015 at 7:19 PM, Jeff Sickel
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 1
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 wrote:
>
> Is this pure X11.app or XQuartz?
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 an
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 t
On 28 February 2015 at 00:10, 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.
Would it be possible to get working devwsys[1
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.
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 ed
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
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 20
19 matches
Mail list logo
