** Changed in: bamf
Status: Fix Released => Fix Committed
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to unity in Ubuntu.
Matching subscriptions: dp-unity, dp-unity2d
https://bugs.launchpad.net/bugs/692462
Title:
unity confused with chrome/chromium web apps
Status in BAMF Application Matching Framework:
Fix Committed
Status in Chromium:
Unknown
Status in The Window Navigator Construction Kit: libwnck:
Fix Released
Status in Unity:
Fix Released
Status in Unity 2D:
Invalid
Status in Unity Distro Priority:
Fix Committed
Status in “bamf” package in Ubuntu:
Confirmed
Status in “chromium-browser” package in Ubuntu:
Fix Released
Status in “unity” package in Ubuntu:
Fix Released
Status in “unity-2d” package in Ubuntu:
Invalid
Status in “bamf” source package in Precise:
Confirmed
Status in “chromium-browser” source package in Precise:
Fix Released
Status in “unity” source package in Precise:
Fix Released
Status in “unity-2d” source package in Precise:
Invalid
Bug description:
SRU testcase
1. start chromium-browser
2. create a webapp for twitter.com
3. drag it to launcher while chromium is already running
4. click its icon you will see twitter.com is opened in a new window but is
still associated with chromium icon
5. now install Bamf from precise-proposed
6. note that twitter window is associated to the newly dropped icon in the
launcher.
On my classic desktop panel, i have 2 webapps launchers in the gnome-panel.
Basically, they are just "chromium-browser --app=http://some.web.site
--some-other-flags ..." + a nice icon
Chromium is my default browser.
In the new unity based desktop mode, those webapps now appear nicely.
The problem is that when i start my default web browser, unity
highlights on the left one of my webapp launchers, instead of creating
one for the browser itself.
And worse.. once the browser is running, i can't start this webapp anymore as
unity keeps raising the main browser instead.
For the other webapp, it works as expected.
ii libunity-misc0 0.1.1-0ubuntu3 Miscellaneous functions
for Unity - shared library
ii libunity0 0.2.46-0ubuntu5 binding to get places
into the launcher - shared library
ii libunity3 3.2.8-0ubuntu1 binding to get places
into the launcher - shared library
ii unity 3.2.8-0ubuntu1 Interface for Ubuntu
Desktop Edition
ii unity-asset-pool 0.8.18-0ubuntu2 Unity Assets Pool
ii unity-common 3.2.8-0ubuntu1 Common files for the
interface for Ubuntu Desktop Edition
ii unity-place-applications 0.2.26-0ubuntu2 Application place for
unity
ii unity-place-files 0.5.32-0ubuntu1 File place for unity
=========================================================================
This bug would be an ideal bug for someone to get started hacking on
Unity, here's some information:
* Time to fix: unknown but large
* Difficulty: brutal
* Implementation:
This is a complex issue to solve correctly. The most correct
implementation associates URI's with windows inside of bamf. Such that
bamf's exported tree becomes BamfApplication -> BamfWindow ->BamfUri
(currently called BamfTab and incomplete in source).
To achieve this goal there are three primary components. The first is
a BamfUriSource. This source is a class used by an application to
export its known URI's over dbus to BAMF. The implementation details
are not that important, however it is important that it be trackable
(so if it crashes we can eliminate references to it) and that it
provide two way communication. In short, it needs to tell the bamf
daemon about all the uri's it has, and the bamf daemon needs to in
turn be able to ask a bamf uri source to "show" a specific uri in its
window.
Bamf Daemon will then convert the BamfUriSource into many BamfUri's
for exporting over the bus. A bamf uri should look something like and
inherit from BamfView:
char * bamf_uri_get_uri (BamfUri *self)
char * bamf_uri_get_icon (BamfUri *self)
char * bamf_uri_get_title (BamfUri *self)
void bamf_uri_show (BamfUri *self)
In short: that part sucks
The second part is making web browsers export tab uri information over
dbus using BamfUriSource. This should be somewhat simple if you know
the browser plugin API's using a standard NPAPI plugin. The C potion
of the plugin can consume bamf and pass data along, while the
javascript can communicate with the browser to get relevant
information about the state of the system.
The third and final task is to hook this all into unity. This is
relatively straightforward to do. By making a launcher shortcut that
points to a uri rather than an application, unity can associate an
BamfUri with it, watching when it opens and closes. When clicked,
unity can call bamf_uri_show () on the proper uri, which will result
in the window raising itself and flipping to the appropriate tab.
Excellent.
The most clarifying thing I can think to say here is that when you
call bamf_uri_show, what should happen is libbamf will call Show on
the correct dbus object that was exported by bamfdaemon. Bamfdaemon
will then find the associated BamfUriSource for that BamfUri object,
can call show back on it, passing along the id of the uri it wishes to
have shown. The NPAPI plugin will receive this call, and pass the
information up to the javascript layer, which should then raise the
window and switch tabs. Like a boss.
* Where to look: lp:bamf and lp:unity are the primary consumers.
-lp:bamf requires the most work. BamfTabSource and BamfTab need to be
converted, exported, and consumed in libbamf
-lp:unity would simply consume the newly exported information
* Workflow information: http://unity.ubuntu.com/getinvolved/
To manage notifications about this bug go to:
https://bugs.launchpad.net/bamf/+bug/692462/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
