index

sawfish-window-life

what events & where do we have to listen for?

add_window:

user> before-add-window-hook

(#

_NET_WM_DESKTOP -> sticky, or .... _NET_WM_WINDOW_TYPE functions!!! see define-wm-spec-window-type:

(define-wm-spec-window-type '_NET_WM_WINDOW_TYPE_DESKTOP (lambda (w) (mark-window-as-desktop w)))

(define-wm-spec-window-type '_NET_WM_WINDOW_TYPE_DOCK (lambda (w) (mark-window-as-dock w)))

(define-wm-spec-window-type '_NET_WM_WINDOW_TYPE_DIALOG (lambda (w) (mark-window-as-transient w)))

(define-wm-spec-window-type '_NET_WM_WINDOW_TYPE_UTILITY (lambda (w) (require 'sawfish.wm.frames) (set-window-type w 'utility)))

(define-wm-spec-window-type '_NET_WM_WINDOW_TYPE_TOOLBAR (lambda (w) (require 'sawfish.wm.frames) (set-window-type w 'toolbar)))

(define-wm-spec-window-type '_NET_WM_WINDOW_TYPE_MENU (lambda (w) (require 'sawfish.wm.frames) (set-window-type w 'menu)))

(define-wm-spec-window-type '_NET_WM_WINDOW_TYPE_SPLASH (lambda (w) (require 'sawfish.wm.frames) (set-window-type w 'splash) (window-put w 'place-mode 'centered)))

ol-add-window> Open Look

mwm-add-window>

ws-honour-client-state> iconify! fixme! double code in C and lisp!

match-window>) ... ???????

add-window-hook

(# removes buttons from the frame?

update-client-state define-wm-spec-window-state publishes (to X) the state? update-client-list-hints>

keymap-add-window put window-keymap unless custom ..... when do the monitors work? ws-add-window adds to WSs even the current one! reframe-window> stacking-add-window> (window-put w 'depth ...)

shading-add-window>)

all in all no X requests? but looks at the maybe the key grabs!

after this C grabs keys and makes the frame?

all during a server-grab.

place-window

after-add-window-hook

(# mmc.xterm! add-wid-to-new-window>

after-add-window maximize? what if it should be iconified? grab-window-events> !!!!

restack-window "Assuming that the current stacking order is in a consistent state except, possibly, for the position of window W, restore the consistent state including window W. This is achieved by raising or lowering window W as appropriate."

---> ends with either x-raise-window or relative to 1 window!

;; sawfish.wm.theming.make-theme-preview

map-notify-hook

we once again check the override .... our obsession. why isn't there an event to wake us?

update-client-list-hints> wm-spec: _NET_CLIENT_LIST _NET_CLIENT_LIST_STACKING audio-mapped-fun> focus-add-window> ... !! transient-map-window> ? sets input focus...? ws-window-mapped> place window w/o any workspace: ws-add-window restack-window> restack-window fixme: this should have been done! ws-set-client-state>) iconified ? (maximized?) 'WM_STATE property

reparent-notify-hook

not used!

visibility-notify-hook

not use

unmap-notify-hook

(# audio-unmapped-fun> lost-window> .... move/resize on-unmap> transient-unmap-window> ws-window-unmapped>)

destroy-notify-hook

( update-client-list-hints lost-window> ws-remove-window

>)

termination:

old problems:

losing Focus:

  • 2 windows disappearing together.

ConfigureNotify arrives b/c the window wants to deregister focus-in or other WM_PROTOCOL

  • -> we enquire -> invoke Error handler removes the ->id w->id = 0; pending_destroys++;
  • inner ...invokes emit_pending_destroys on the next loop
  • Unmap
  • Destroy

remove-window

is called from 4 places/situations:

  • error
  • unmap
  • destroy
  • GC

Only the last 2 can destroy the lisp data. the ID ..... destroy should be ok. unless we process the events in a different order. (note that window IDs are recycled by X).

who removes from stacking-order ?

my new approach

errored window_is_gone_p

we don't send any X request

remove_window

we remove the Frame, ungrab etc.

we still can receive events, and redirect to the Lisp Window.

on Unmap, we could run focus_out, though.

destroy_window

from this moment, we don't need the lisp object. we won't receive X events (or just discard them?).

Q: could we recycle it here? if the same window is recycled? A: to do it, we would have to be sure, that it's the same window. I.e. follow reparentNotify and destroyNotify ->

what we save: the frame is destroyed anyway. we could keep the grabs?

GC disallocation

event trick:

could we implement it for the focus handling ?

life-time of a frame part:

fp_new

called from `list_frame_generator'

running build_frame_part, if fails -> ???

build_frame_part can allocate images!

Updated: 2005-02-24 Home / Index Agenzia matrimoniale Maruska google rev