Skip to content
  • Eike Hein's avatar
    Handle clients which change window metadata during early startup · b15eaf38
    Eike Hein authored
    Summary:
    Some apps initially show their window with bogus/useless window
    metadata and then update to useful metadata during early startup.
    For example, LibreOffice sets WM_CLASS to soffice/Soffice and
    then updates to libreoffice-writer/libreoffice. This leads to
    a poor user experience on particular the Icons-only Task Manager,
    but also the regular Task Manager depending on settings.
    
    Depending on its configuration (and Icons-only Task Manager is
    a particular set of configuration options, as far as the model
    is concerned), TasksModel will try to sort a new window task
    adjacent to its launcher task. The appearance of a new window
    task also causes matching (in terms of identification) launcher
    or startup tasks to be filtered out. To the user, this forms a
    lifecycle of the launcher being replaced by the window in-place
    (and a startup state inbetween, optionally but by default).
    
    Prior to this patch, this sorting decision was only done once,
    when a new window enters the source model stack. This meant the
    LibreOffice window would initially be sorted into the "wrong"
    spot (the bogus metadata doesn't allow us to relate it to its
    launcher) and then, following the metadata change, stick to the
    wrong position.
    
    Simply changing the code to sort things again on any metadata
    change would not have been good enough: Metadata changes can
    occur at any time, and things should not just move around on
    the user - this sort mode is called "Manual" for a reason. Also,
    the visual result would still be poor: The window would initially
    appear at the wrong position, then move to the right one a bit
    later.
    
    This patch takes the following approach:
    * It adds a new config key to taskmanagerrulesrc for listing
      ids of matching tasks to completely hide, and of course the
      code needed to implement this.
    * It adds LibreOffice' bogus initial metadata to this key, so
      the tasks is initially hidden.
    * The sort code skips over hidden window tasks in the sort
      insert queue instead of moving them. The queue is marked as
      stale then, and cleared on unrelated windowing system changes.
    * It resorts when tasks are unhidden (i.e. once the metadata
      update has occured and the task no longer matches the above
      config key).
    
    The visual result is that the startup notification on the
    launcher spins a little bit longer than before, even though the
    window has already appeared (although LO lags in filling in its
    contents anyway), and then morphs into the window task
    representation once the client has completed the window metadata
    change. This happens in such a short order as to be more or less
    imperceptible.
    
    If startup notifications are turned off it's broadly the same,
    minus the spinning.
    
    BUG:396871
    
    Reviewers: davidedmundson, broulik, ngraham
    
    Subscribers: plasma-devel
    
    Tags: #plasma
    
    Differential Revision: https://phabricator.kde.org/D15410
    b15eaf38