** Description changed:
+ 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:
+ * 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.
+ * 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
+ -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/
+ * Workflow information: http://unity.ubuntu.com/getinvolved/
** No longer affects: unity (Ubuntu)
** Changed in: bamf (Ubuntu)
Status: Fix Committed => Confirmed
** Also affects: bamf (Ubuntu Precise)
Importance: Undecided
Assignee: Marco Trevisan (Treviño) (3v1n0)
Status: Confirmed
** Also affects: chromium-browser (Ubuntu Precise)
Importance: Medium
Assignee: Fabien Tassin (fta)
Status: Fix Released
** Also affects: unity-2d (Ubuntu Precise)
Importance: Undecided
Status: Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/692462
Title:
unity confused with chrome/chromium web apps
To manage notifications about this bug go to:
https://bugs.launchpad.net/bamf/+bug/692462/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
