Negative positions in frame parameters

Negative positions in frame parameters

[Stefan Monnier]

Recently

  (make-frame '((left . -10) (top . -10)))

stopped placing the frame in the bottom-right corner of the screen (at
least in the Gtk build).

Could someone fix it?


        Stefan

Re: Negative positions in frame parameters

[Lennart Borgman]

On Tue, Apr 13, 2010 at 3:24 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> Recently
>
>  (make-frame '((left . -10) (top . -10)))
>
> stopped placing the frame in the bottom-right corner of the screen (at
> least in the Gtk build).
>
> Could someone fix it?

Why should it go to the bottom-right corner? At least on w32 you can
have the upper left corner outside of the screen.

Re: Negative positions in frame parameters

[Stephen J. Turnbull]

Lennart Borgman writes:
 > On Tue, Apr 13, 2010 at 3:24 PM, Stefan Monnier
 > <monnier@iro.umontreal.ca> wrote:
 > > Recently
 > >
 > >  (make-frame '((left . -10) (top . -10)))
 > >
 > > stopped placing the frame in the bottom-right corner of the screen (at
 > > least in the Gtk build).
 > >
 > > Could someone fix it?
 > 
 > Why should it go to the bottom-right corner?

This is just the traditional behavior on X11 displays.  Negative
position coordinates are relative to the bottom-right corner, positive
ones to the top-left.

 > At least on w32 you can have the upper left corner outside of the
 > screen.

You can in X, too, but it's rarely useful for top-level windows.  The
ability to place the window on the right or bottom of the screen is
often useful.  IME YMMV, of course; I'm just explaining where the
tradition comes from, not advocating it.

Re: Negative positions in frame parameters

[Jason Rumney]

"Stephen J. Turnbull" <stephen@xemacs.org> writes:

>  > At least on w32 you can have the upper left corner outside of the
>  > screen.
>
> You can in X, too, but it's rarely useful for top-level windows.

I'm not sure if Xinerama or RandR works like this, but with multiple monitor
setups on Windows, you can choose to put the secondary montitor to the
left and/or above the primary monitor, in which case all coordinates on
that monitor become negative.  So its not as useless as it might
initially seem.

Re: Negative positions in frame parameters

[Jan Djärv]

Jason Rumney skrev:
> "Stephen J. Turnbull" <stephen@xemacs.org> writes:
> 
>>  > At least on w32 you can have the upper left corner outside of the
>>  > screen.
>>
>> You can in X, too, but it's rarely useful for top-level windows.
> 
> I'm not sure if Xinerama or RandR works like this, but with multiple monitor
> setups on Windows, you can choose to put the secondary montitor to the
> left and/or above the primary monitor, in which case all coordinates on
> that monitor become negative.  So its not as useless as it might
> initially seem.
> 

AFAIK, in X the top left corner is always at 0, 0.  There is no concept of 
primary or secondary monitor, there are just monitors.  There is a primary 
screen though.

	Jan D.

RE: Negative positions in frame parameters

[Drew Adams]

BTW, apparently the `invisible' `display' property affects frame positioning.

I use dired-details.el, which puts an overlay on all of the Dired fields except
the file name. The overlay has `evaporate' = t, `invisible' = t, and
`before-string' = "".

As a result, if I do (make-frame '((left . -10) (top . -10))) with such a Dired
frame current, it positions the new frame as if its right edge were the same as
the original frame before hiding the details.

That is, the narrow frame (because no permissions, time etc. are shown) appears
in the middle of the screen - it does not have its right edge 10 pixels past the
screen right edge. It is not the right edge of the actual frame that is
positioned correctly, but the right edge of the frame as it would have appeared
without hiding anything.

Dunno if this should be considered a bug or not, but it's interesting. ;-)

Re: Negative positions in frame parameters

[Jan Djärv]

Lennart Borgman skrev 2010-04-13 15.33:
> On Tue, Apr 13, 2010 at 3:24 PM, Stefan Monnier
> <monnier@iro.umontreal.ca>  wrote:
>> Recently
>>
>>   (make-frame '((left . -10) (top . -10)))
>>
>> stopped placing the frame in the bottom-right corner of the screen (at
>> least in the Gtk build).
>>
>> Could someone fix it?
>
> Why should it go to the bottom-right corner? At least on w32 you can
> have the upper left corner outside of the screen.
>

http://www.xfree86.org/current/X.7.html#sect6

The problem in Emacs is how do you say the equivalent to

   -geometry --10--10, -geometry +-10+-10

in frame parameters?

	Jan D.

Re: Negative positions in frame parameters

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Lennart Borgman skrev 2010-04-13 15.33:
>> On Tue, Apr 13, 2010 at 3:24 PM, Stefan Monnier
>> <monnier@iro.umontreal.ca>  wrote:
>>> Recently
>>>
>>>   (make-frame '((left . -10) (top . -10)))
>>>
>>> stopped placing the frame in the bottom-right corner of the screen (at
>>> least in the Gtk build).
>>>
>>> Could someone fix it?
>>
>> Why should it go to the bottom-right corner? At least on w32 you can
>> have the upper left corner outside of the screen.
>>
>
> http://www.xfree86.org/current/X.7.html#sect6
>
> The problem in Emacs is how do you say the equivalent to
>
>   -geometry --10--10, -geometry +-10+-10
>
> in frame parameters?

(make-frame '((right . -10) (bottom . -10)))

(make-frame '((left . -10) (top . -10)))

would seem like a reasonably obvious way.

-- 
David Kastrup

Re: Negative positions in frame parameters

[Jan Djärv]

David Kastrup skrev 2010-04-13 17.26:
 > Jan Djärv<jan.h.d@swipnet.se>  writes:
 >
 >> The problem in Emacs is how do you say the equivalent to
 >>
 >>    -geometry --10--10, -geometry +-10+-10
 >>
 >> in frame parameters?
 >
 > (make-frame '((right . -10) (bottom . -10)))
 >
 > (make-frame '((left . -10) (top . -10)))
 >
 > would seem like a reasonably obvious way.
 >

You would think that, but I found out that is actually:

(make-frame '((right . (- -10)) (left . (- -10)))
and
(make-frame '((right . (+ -10)) (left . (+ -10)))

	Jan D.

RE: Negative positions in frame parameters

[Drew Adams]

FWIW, I've been using the following functions forever, to make life simpler when
trying to deal with the different possible representations that Emacs functions
might return.

I use this, for example, to move frames around incrementally. (To increment a
value it needs to be in numeric form.)

The functions are also here, in case mail wraparound makes them difficult to
read:
http://www.emacswiki.org/emacs/frame-fns.el

----

(defun frame-geom-value-numeric (type value &optional frame)
  "Return equivalent geometry value for FRAME in numeric terms.
A geometry value equivalent to VALUE for FRAME is returned,
where the value is numeric, not a consp.
TYPE is the car of the original geometry spec (TYPE . VALUE).
   It is `top' or `left', depending on which edge VALUE is related to.
VALUE is the cdr of a frame geometry spec: (left/top . VALUE).
If VALUE is a consp, then it is converted to a numeric value, perhaps
   relative to the opposite frame edge from that in the original spec.
FRAME defaults to the selected frame.

Examples (measures in pixels) -
 Assuming display height/width=1024, frame height/width=600:
 300 inside display edge:                   300  =>  300
                                        (+  300) =>  300
 300 inside opposite display edge:      (-  300) => -300
                                           -300  => -300
 300 beyond display edge
  (= 724 inside opposite display edge): (+ -300) => -724
 300 beyond display edge
  (= 724 inside opposite display edge): (- -300) =>  724

In the last two examples, the returned value is relative to the
opposite frame edge from the edge indicated in the input spec."
  (if (consp value)
      (if (natnump (cadr value))
          ;; e.g. (+ 300) or (- 300) => 300 or -300
          (funcall (car value) (cadr value))
        ;; e.g. (+ -300) or (- -300)
        (let ((oppval (- (if (eq 'left type)
                             (x-display-pixel-width)
                           (x-display-pixel-height))
                         (cadr value)
                         (if (eq 'left type)
                             (frame-pixel-width frame)
                           (frame-pixel-height frame)))))
          (if (eq '+ (car value))
              (- oppval)                ; e.g. (+ -300) => -724
            oppval)))                   ; e.g. (- -300) =>  724
    ;; e.g. 300 or -300
    value))

(defun frame-geom-spec-numeric (spec &optional frame)
  "Return equivalent geometry specification for FRAME in numeric terms.
A geometry specification equivalent to SPEC for FRAME is returned,
where the value is numeric, not a consp.
SPEC is a frame geometry spec: (left . VALUE) or (top . VALUE).
If VALUE is a consp, then it is converted to a numeric value, perhaps
   relative to the opposite frame edge from that in the original SPEC.
FRAME defaults to the selected frame.

Examples (measures in pixels) -
 Assuming display height=1024, frame height=600:
 top 300 below display top:               (top .  300) => (top .  300)
                                          (top +  300) => (top .  300)
 bottom 300 above display bottom:         (top -  300) => (top . -300)
                                          (top . -300) => (top . -300)
 top 300 above display top
  (= bottom 724 above display bottom):    (top + -300) => (top . -724)
 bottom 300 below display bottom
  (= top 724 below display top):          (top - -300) => (top .  724)

In the last two examples, the returned value is relative to the
opposite frame edge from the edge indicated in the input SPEC."
  (cons (car spec) (frame-geom-value-numeric (car spec) (cdr spec))))

(defun frame-geom-value-cons (type value &optional frame)
  "Return equivalent geometry value for FRAME as a cons with car `+'.
A geometry value equivalent to VALUE for FRAME is returned,
where the value is a cons with car `+', not numeric.
TYPE is the car of the original geometry spec (TYPE . VALUE).
   It is `top' or `left', depending on which edge VALUE is related to.
VALUE is the cdr of a frame geometry spec: (left/top . VALUE).
If VALUE is a number, then it is converted to a cons value, perhaps
   relative to the opposite frame edge from that in the original spec.
FRAME defaults to the selected frame.

Examples (measures in pixels) -
 Assuming display height/width=1024, frame height/width=600:
 300 inside display edge:                   300  => (+  300)
                                        (+  300) => (+  300)
 300 inside opposite display edge:      (-  300) => (+  124)
                                           -300  => (+  124)
 300 beyond display edge
  (= 724 inside opposite display edge): (+ -300) => (+ -300)
 300 beyond display edge
  (= 724 inside opposite display edge): (- -300) => (+  724)

In the 3rd, 4th, and 6th examples, the returned value is relative to
the opposite frame edge from the edge indicated in the input spec."
  (cond ((and (consp value) (eq '+ (car value))) ; e.g. (+ 300), (+ -300)
         value)
        ((natnump value) (list '+ value)) ; e.g. 300 => (+ 300)
        (t                              ; e.g. -300, (- 300), (- -300)
         (list '+ (- (if (eq 'left type) ; => (+ 124), (+ 124), (+ 724)
                         (x-display-pixel-width)
                       (x-display-pixel-height))
                     (if (integerp value) (- value) (cadr value))
                     (if (eq 'left type)
                         (frame-pixel-width frame)
                       (frame-pixel-height frame)))))))

(defun frame-geom-spec-cons (spec &optional frame)
  "Return equivalent geometry spec for FRAME as a cons with car `+'.
A geometry specification equivalent to SPEC for FRAME is returned,
where the value is a cons with car `+', not numeric.
SPEC is a frame geometry spec: (left . VALUE) or (top . VALUE).
If VALUE is a number, then it is converted to a cons value, perhaps
   relative to the opposite frame edge from that in the original spec.
FRAME defaults to the selected frame.

Examples (measures in pixels) -
 Assuming display height=1024, frame height=600:
 top 300 below display top:               (top .  300) => (top +  300)
                                          (top +  300) => (top +  300)
 bottom 300 above display bottom:         (top -  300) => (top +  124)
                                          (top . -300) => (top +  124)
 top 300 above display top
  (= bottom 724 above display bottom):    (top + -300) => (top + -300)
 bottom 300 below display bottom
  (= top 724 below display top):          (top - -300) => (top +  724)

In the 3rd, 4th, and 6th examples, the returned value is relative to
the opposite frame edge from the edge indicated in the input spec."
  (cons (car spec) (frame-geom-value-cons (car spec) (cdr spec))))

Re: Negative positions in frame parameters

[YAMAMOTO Mitsuharu]

>>>>> On Tue, 13 Apr 2010 18:31:20 +0200, Jan Djärv <jan.h.d@swipnet.se> said:

> David Kastrup skrev 2010-04-13 17.26:
>> Jan Djärv<jan.h.d@swipnet.se>  writes:
>> 
>>> The problem in Emacs is how do you say the equivalent to
>>> 
>>> -geometry --10--10, -geometry +-10+-10
>>> 
>>> in frame parameters?
>> 
>> (make-frame '((right . -10) (bottom . -10)))
>> 
>> (make-frame '((left . -10) (top . -10)))
>> 
>> would seem like a reasonably obvious way.
>> 

> You would think that, but I found out that is actually:

> (make-frame '((right . (- -10)) (left . (- -10)))
> and
> (make-frame '((right . (+ -10)) (left . (+ -10)))

Apparently you meant

(make-frame '((top . (- -10)) (left . (- -10))))
and
(make-frame '((top . (+ -10)) (left . (+ -10))))

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Negative positions in frame parameters

[Jan Djärv]

14 apr 2010 kl. 01.41 skrev YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp 
 >:

>>>>>> On Tue, 13 Apr 2010 18:31:20 +0200, Jan Djärv <jan.h.d@swi 
>>>>>> pnet.se> said:
>
>> You would think that, but I found out that is actually:
>
>> (make-frame '((right . (- -10)) (left . (- -10)))
>> and
>> (make-frame '((right . (+ -10)) (left . (+ -10)))
>
> Apparently you meant
>
> (make-frame '((top . (- -10)) (left . (- -10))))
> and
> (make-frame '((top . (+ -10)) (left . (+ -10))))
>

Apparently :-)

      Jan D.

Re: Negative positions in frame parameters

[Stefan Monnier]

>>> Recently
>>> (make-frame '((left . -10) (top . -10)))
>>> stopped placing the frame in the bottom-right corner of the screen (at
>>> least in the Gtk build).
>>> Could someone fix it?
>> Why should it go to the bottom-right corner? At least on w32 you can
>> have the upper left corner outside of the screen.

> http://www.xfree86.org/current/X.7.html#sect6

So where was the change made that caused this new behavior?
In Emacs's code or in some external library?

> The problem in Emacs is how do you say the equivalent to
>   -geometry --10--10, -geometry +-10+-10
> in frame parameters?

David was quicker than I, so I'll just +1 on his suggestion, except that
it's incompatible with previous behavior.


        Stefan

Re: Negative positions in frame parameters

[Jan Djärv]

Stefan Monnier skrev:
>>>> Recently
>>>> (make-frame '((left . -10) (top . -10)))
>>>> stopped placing the frame in the bottom-right corner of the screen (at
>>>> least in the Gtk build).
>>>> Could someone fix it?
>>> Why should it go to the bottom-right corner? At least on w32 you can
>>> have the upper left corner outside of the screen.
> 
>> http://www.xfree86.org/current/X.7.html#sect6
> 
> So where was the change made that caused this new behavior?
> In Emacs's code or in some external library?

What new behaviour?  The bug was in Emacs code.

> 
>> The problem in Emacs is how do you say the equivalent to
>>   -geometry --10--10, -geometry +-10+-10
>> in frame parameters?
> 
> David was quicker than I, so I'll just +1 on his suggestion, except that
> it's incompatible with previous behavior.
> 

And there already is a way.

	Jan D.

Re: Negative positions in frame parameters

[Jan Djärv]

Stefan Monnier skrev:
> Recently
> 
>   (make-frame '((left . -10) (top . -10)))
> 
> stopped placing the frame in the bottom-right corner of the screen (at
> least in the Gtk build).
> 
> Could someone fix it?
> 

Done.  AFAIK, the Gtk-port has never handled negative positions in frame 
parameters correctly.

	Jan D.

Re: Negative positions in frame parameters

[Stefan Monnier]

> Done.  AFAIK, the Gtk-port has never handled negative positions in frame
> parameters correctly.

I've been using them forever on several of my special-display frames, so
at least it made a good enough impression to fool me,


        Stefan

Re: Negative positions in frame parameters

[Jan Djärv]

Stefan Monnier skrev:
>> Done.  AFAIK, the Gtk-port has never handled negative positions in frame
>> parameters correctly.
> 
> I've been using them forever on several of my special-display frames, so
> at least it made a good enough impression to fool me,
> 

If you also set user-position, then it worked as it should.

	Jan D.