#907 closed task (fixed)
refactor the window attributes and signal code
Reported by: | Antoine Martin | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 0.16 |
Component: | server | Version: | 0.15.x |
Keywords: | Cc: |
Description (last modified by )
As it's a bit of a mess...
In particular:
- keep in mind #41..
- try to reduce the duplication between the window models, WM and the server's view
- cleaner abstraction of the "window model" interface
- remove redundant attributes (
is_OR
vs "override-redirect" property,is_shadow
, etc..) - move some wm-state attributes so OR windows can use them (at least focus?)
- more consistent property change code
- fixup geometry issues (and try to get rid of the ownership election stuff)
- make it less dependent on gtk2 whilst we're at it
- maybe move all
_handle_XXXX
methods to a util class? - generalize
NET_WM_ALLOWED_ACTIONS
? - maybe consider the eventual move to GTK3? meh, if so we will need to replace
add_event_receiver
/remove_event_receiver
with aWeakKeyDictionary
- maybe a new form of
_internal_set_property
can check if the value has actually changed? (no need to send anotify()
if it hasn't)
List of API calls to deal with:
get_default_window_icon
_guess_window_type
do_get_property_can_focus
just update the "can-focus" property insteadx11_get_server_time
- rewrite in Cythonread_initial_properties
and X11 properties, it's a messcall_setup()
is inconsistent, it's called for OR and tray, but we call it for "normal" windowsWM_PROTOCOLS
->XGetWMProtocols
WM_CLIENT_MACHINE
->XGetWMClientMachine
attention-requested
: shouldn't we clear this when "urgency" is not in the wm_hints?set_active
- maybe this should be a method on WM instead?
Attachments (4)
Change History (11)
comment:1 Changed 7 years ago by
Description: | modified (diff) |
---|---|
Status: | new → assigned |
comment:2 Changed 7 years ago by
Description: | modified (diff) |
---|
Changed 7 years ago by
Attachment: | split-windowmodel.patch added |
---|
comment:3 Changed 7 years ago by
Huge changeset in r9822 - see commit message.
If needed, it should be possible to revert those changes easily enough for testing.. so far.
Still TODO:
WM_STATE
and withdrawn windows - we only handle "iconic" (should we forward "withdrawn" to client? and emulate it as a destroy + new for older clients?)- geometry (big!) - see also #846, #988 and many others
- "attention-request"
- maybe too many messages are now handled in the window base class (not relevant to OR windows?)
- should use "managed_connect" more
- seem to be getting double notifications for a single notify() call!?
- "can-focus" is not used?
- #846
- #881?
comment:4 Changed 7 years ago by
Moving the geometry bits to #990 (the rest is in pretty good shape already)
comment:5 Changed 7 years ago by
Note: on centos 7.x, we get tons of warnings like these:
/usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property xpra+x11+gtk2+models+or_window+OverrideRedirectWindowModel::size-hints after class was initialised type_register(cls, namespace.get('__gtype_name__')) /usr/lib64/python2.7/site-packages/gobject/__init__.py:115: Warning: Attempt to add property xpra+x11+gtk2+models+or_window+OverrideRedirectWindowModel::frame after class was initialised type_register(cls, namespace.get('__gtype_name__'))
Which is caused by this bug: https://bugzilla.gnome.org/show_bug.cgi?id=698614 (hopefully will be backported to centos 7.x soon).
AFAICT, it is not possible to workaround this warning with pygobject (see the two attempts at subclassing attached below).
Changed 7 years ago by
Attachment: | gobject_subclassing.py added |
---|
example triggering the centos 7 warning
Changed 7 years ago by
Attachment: | gobject_subclassing2.py added |
---|
another example triggering the centos 7 warning
comment:6 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:7 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/907
better patch