<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    Of course windows get *minimized* to either a task bar, or the
    desktop, and not to the tray. But this is for when you *close* a
    window and the program still stays running with a tray icon, such as
    skype, or qjackctl, and so on, or when a window *opens* itself
    initially, from a program that owns a tray icon.
    <br>
    <br>
    As for wayland, i don't know enough about it, but i would imagine it
    would be trivial to adapt this simple mechanism to wayland.<br>
    <br>
    <div class="moz-cite-prefix">On 09/08/15 04:48, Philipp A. wrote:<br>
    </div>
    <blockquote
cite="mid:CAN8d9g=8Fq-NGYSNi=CafDDGP-Ci4fJ1L_w1qW8fGJYi4sye2Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>i don’t think that X11-only solutions make sense in
              2015, with wayland implemented in the big DEs and just
              waiting for a bit more polish and testing.<br>
              <br>
            </div>
            and the notification area isn’t where stuff gets minimized
            to – that’s the task bar. what are the advantages of
            deviating from this thing that *all* applications can do,
            and do something else instead? are a launcher/taskbar entry
            with quicklist, counter, progressbar, and dynamic
            interaction via MPRIS and a independent notification icon
            not enough for your application?<br>
          </div>
          <div><br>
          </div>
          the only similar thing i can think of is that task icons are
          often able to launch programs (e.g. the printer notification
          icon can launch a printer config dialog, and the update
          notification a system updater), so maybe it would make sense
          to tell WMs where some application launched from, maybe also
          generalized: clicked it in a panel menu? launched from the
          window menu of another application? notification area? task
          bar? “WM, please create this window with a launch animation
          coming from this rectangle”<br>
        </div>
        <div><br>
        </div>
        <div>best, philipp<br>
        </div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr">Éric Tremblay <<a moz-do-not-send="true"
            href="mailto:xdg@deimos.ca">xdg@deimos.ca</a>> schrieb am
          Di., 8. Sep. 2015 um 00:40 Uhr:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
          Hello everyone,<br>
          <br>
          I'm programming little "zoom" animations in XFCE to show the
          user in a<br>
          logical way, for example, where to click to get a window back
          when it<br>
          minimizes, or where a window "comes from" when it appears, if
          that<br>
          applies. The biggest problem with this is that there's no
          standard way<br>
          for the different processes (window manager, tray icon
          manager(s), etc)<br>
          to determine or communicate with each other where the *tray
          icons* are.<br>
          <br>
          Taking example of the _NET_WM_ICON_GEOMETRY window property, i
          think<br>
          i've come up with a clean, simple, and reliable solution.
          Here's a<br>
          description of how i implemented this in XFCE, however i
          attempted to<br>
          make it as portable and non-wm-specific as possible, depending
          only on<br>
          X11/Xlib internals.<br>
          <br>
          I'm simply using an X property on the root window of the
          display called<br>
          _NET_WM_TRAY_ICON_GEOMETRIES which follows a simple format.
          It's an<br>
          array of strings, with each string representing a tray icon,
          and<br>
          following a format like:<br>
          <br>
          "mgr=systray,classname=blueman,pid=4522,x=1332,y=1,w=22,h=22"<br>
          <br>
          In this example, the "mgr" field indcates that this entry was
          added by<br>
          the "systray" pluign. This information lets more than one
          "tray" process<br>
          manage the string array on a given X display (as is the case
          with XFCE's<br>
          "systray" (aka "notify") and "indicator" panel plugins) and
          also avoids<br>
          the problem where different processes would add duplicate
          information,<br>
          whcih would quickly saturate the string array. The "classname"
          field is<br>
          pretty self-explanatory, it's the class name of whatever
          window(s) match<br>
          up with this systray icon. The "pid" field can help in
          matching windows<br>
          that have nonexistent or weird class names. If it's absent or
          equal to<br>
          -1, then that means the PID of the process owning the icon
          couldn't be<br>
          determined. Finally we have the x,y,w,h screen coordinates of
          this tray<br>
          icon. In my implementation the fields may be read in any
          order, but it's<br>
          better to write them in a more consistent format such as the
          above.<br>
          <br>
          (at least for now) If a string contains any semicolon ";" or
          newline<br>
          characters, these should be treated as separating the entry
          into several<br>
          entries.<br>
          <br>
          Upon creating a new systray icon, modifying an existing one,
          or deleting<br>
          a systray icon, a tray manager process such as the "indicator"
          plugin<br>
          would do something like the following:<br>
          <br>
               - choose a name that preferably describes its process
          name, such as<br>
          "indicator", "notify", or "systray" - this would be the "mgr"
          field. It<br>
          should be consistent for the entire lifespan of the tray
          manager process.<br>
          <br>
               - grab the X server to avoid race conditions with other
          tray managers<br>
          <br>
               - fetch the strings from the _NET_WM_TRAY_ICON_GEOMETRIES
          property<br>
          on the X server's root window<br>
          <br>
               - *remove* all entries whose "mgr" field matches its own
          chosen<br>
          process name<br>
          <br>
               - for each tray icon managed by this process: append a
          string to<br>
          the array in the above format, omitting the "pid" field or
          setting it to<br>
          -1 if the PID corresponding to the tray icon can't be
          determined, and<br>
          omitting the "classname" field or setting it to zero-length if
          the class<br>
          name can't be determined. If both can't be determined for a
          specific<br>
          entry, it's pretty useless to add that entry.<br>
          <br>
               - write the string array to the
          _NET_WM_TRAY_ICON_GEOMETRIES<br>
          property on the X server's root window<br>
          <br>
               - ungrab the X server<br>
          <br>
          <br>
          The window manager can then easily determine if it should
          perform an<br>
          animation to/from a tray icon when a window opens or closes,
          and if so,<br>
          what the screen coordinates of this icon are. In case both a<br>
          _NET_WM_ICON_GEOMETRY is present *and* a match in the root
          window's<br>
          _NET_WM_TRAY_ICON_GEOMETRIES array is found, it's up to the
          window<br>
          manager to determine which one should take precedence, based
          on factors<br>
          such as the window's class/role, whether it is itself the
          window's<br>
          owner, and so on. In some cases, it's also desirable to not
          perform the<br>
          animation, for example if there are several open windows
          matching the<br>
          same tray icon - in this case, we'd normally want to animate
          only the<br>
          last one to close.<br>
          <br>
          It's also possible to setup a table of "equivalent names" for
          processes,<br>
          for example we'd want pavucontrol windows (the PulseAudio
          volume<br>
          control) to be considered as belonging to the
          indicator-sound-service<br>
          process if it's running.<br>
          <br>
          Anyway, i've been running my implementation of this on 2 of my
          own<br>
          machines for a while now, and it seems to work very well.<br>
          <br>
          Cheers,<br>
          <br>
             - Éric "delt" Tremblay.<br>
          <br>
          <br>
          _______________________________________________<br>
          xdg mailing list<br>
          <a moz-do-not-send="true"
            href="mailto:xdg@lists.freedesktop.org" target="_blank">xdg@lists.freedesktop.org</a><br>
          <a moz-do-not-send="true"
            href="http://lists.freedesktop.org/mailman/listinfo/xdg"
            rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/xdg</a><br>
        </blockquote>
      </div>
    </blockquote>
    <br>
  </body>
</html>