← Back to team overview

linux-traipu team mailing list archive

[Bug 425938] Re: Web apps (Chrome/Prism) should have individual icons in Docky

 

*** This bug is a duplicate of bug 488958 ***
    https://bugs.launchpad.net/bugs/488958

So the downside to this workaround is that if I use Ctrl+N or Ctrl+T to
open a new window, it doesn't know to use my regular Google Chrome
settings to do that -- it becomes part of the Gmail app as far as Unity
is concerned.

This is not an optimal solution.

-- 
You received this bug notification because you are a member of UBUNTU -
AL - BR, which is subscribed to Do.
https://bugs.launchpad.net/bugs/425938

Title:
  Web apps (Chrome/Prism) should have individual icons in Docky

Status in Do:
  Won't Fix
Status in Docky:
  New

Bug description:
  It should be possible to have web apps treated as seperate
  applications with their own icon in Docky.  If I'm not mistaken, this
  could be done by taking the windows WM_CLASS into account when
  grouping and fetching icons.    For example, I can have a desktop file
  with the following:

  [Desktop Entry]
  Name=Gmail
  Exec=chromium-browser --user-data-dir=~/.gmail --app=http://www.gmail.com --class=Gmail $*
  Type=Application
  StartupWMClass=Gmail

  * the --user-data option is required to start a NEW instance of
  chrome, otherwise it will hijack any current chrome instance and the
  --class argument will be ignored

  This would launch an instance of Chromium/Chrome running gmail in app mode.  It's window class would appear as follows in xprop:
  WM_CLASS(STRING) = "chromium-browser", "Gmail"

  As opposed to a regular instance which is just: 
  WM_CLASS(STRING) = "chromium-browser", "Chromium-browser"

  Is it possible to group windows like this, based on their class?  It
  would provide some great web app integration.  I filed a similar bug
  on the chromium tracker about properly identifying individual app
  instances, through their class/role or otherwise.

To manage notifications about this bug go to:
https://bugs.launchpad.net/do/+bug/425938/+subscriptions