In response to "the libappindicator story"

I generally never weigh in on these things, but I think in this case I understand what some may be missing here.

This is in reference to the following blog post: the libappindicator story

Each side refers to process and how the other side failed to follow it. My question is "can anyone point me to the relevant documentation which shows the process being referred to" and "can both parties review this process to see where they fell down" and "can the process be reviewed to ensure that it is clear and works so as to prevent similar future issues".

I suspect that there is no documented process, nor is it generally understood as to how all this was supposed to work by both parties. It's easy to reject an idea citing some failure to comply with a non-documented process. I'd like to be proven wrong and see that a process actually exists and work from there, but I suspect it's currently vapourware.

It's fine for you to state Canonical did not follow the process, but to not link to a doc or provide a post showing the process as approved by either GNOME or the team within GNOME responsible for this particular area, it's quite frankly irresponsible.

In order to make any such claim, you need tangible documentation. GNOME is big enough and the teams are diverse enough, that you need to document process. How else do you get efficient and allow new development to occur? You cannot exist forever in a vacuum.

So, if there is indeed a well documented process, show us the link. Show Mark that his team failed to follow the documented process. Then, once that's done we can move on. Mark will admit defeat and apologize and we can call it a day.

However, if this is not well documented nor consistent across GNOME projects, then GNOME needs to recognize that the lack of a documented process may have contributed here and let's correct that and move on.

PS: I work in a very process driven area (customer service and delivery) and it requires well documented processes to function. I understand all to well when some process exists virtually and is not well documented what can happen. Orders get missed, revenue drops, productivity suffers. As well, people point fingers. The only way to rectify is document the process and get everyone to acknowledge it. The process doesn't have to be perfect, it just has to be documented so you can at least have a reference point to move forward from.

Peace.

Beryl without emerald...

Ok, so the original ebuild for beryl meta x11-wm/beryl forced the user to require emerald and consequently emerald-themes and libwnck. However, since both Heliodor and Aquamarine are available as alternatives to emerald, I felt it was time to provide a choice to the user.

The ebuild would allow you to choose to add aquamarine (via USE="kde") and/or heliodor (via USE="gnome") but not to drop emerald. This was probably a good thing while aquamarine and heliodor we fairly new and maybe not as stable. Now, they seem pretty stable, so if you want to make the switch to one of those and not have emerald, it should be possible while using the meta ebuild for beyl.

To make this happen, we needed two things:

1) Modify the beryl meta ebuild
2) Patch the beryl-manager to hide the emerald theme manager option (if not installed)

The second item is purely cosmetic, but needed to be done.

Here's the original patch I applied to beryl-manager-0.1.9999.2:

--- beryl-manager-0.1.9999.2/src/main.c 2007-02-13 16:14:41.000000000 -0330
+++ beryl-manager-0.1.9999.2/src/main.c.new     2007-03-05 12:17:29.000000000 -0330
@@ -1149,6 +1149,8 @@
        gtk_widget_show(mitem);
        g_signal_connect(mitem, "activate", G_CALLBACK(startApp),
                                         "beryl-settings");
+       if (detect_app("emerald-theme-manager"))
+       {
        mitem = gtk_image_menu_item_new_with_label(_("Emerald Theme Manager"));
        gtk_image_menu_item_set_image(GTK_IMAGE_MENU_ITEM(mitem),
                make_image(PIXMAPS_DIR "/emerald-theme-manager-icon.png"));
@@ -1156,6 +1158,7 @@
        gtk_widget_show(mitem);
        g_signal_connect(mitem, "activate", G_CALLBACK(startApp),
                                         "emerald-theme-manager");
+       }

        mitem = gtk_separator_menu_item_new();
        gtk_menu_shell_append(GTK_MENU_SHELL(menu), mitem);

I applied this patch to use detect_app from beryl-manager to try and see if emerald is installed. If not, then do not add the menu item. Pretty simple, but effective fix. Nesl247 has since modified this patch and committed to upstream, so it's in berl SVN now and will be available in the next release candidate and/or beryl 0.2.0.

Now that we have a clean beryl-manager, we can modify the beryl meta ebuild to remove the dependancy on emerald. We need to be careful, as the user should choose at least one window decorator to use. So here is the diff showing the changes:

--- beryl-0.1.9999.2.ebuild     2007-03-06 10:42:45.000000000 -0330
+++ /usr/portage/local/layman/xeffects/x11-wm/beryl/beryl-0.1.9999.2.ebuild     2007-03-05 16:54:52.000000000 -0330
@@ -11,16 +11,33 @@
 LICENSE="GPL-2"
 SLOT="0"
 KEYWORDS="~amd64 ~ppc ~ppc64 ~x86"
-IUSE="kde gnome"
+IUSE="kde gnome noemerald"

 RDEPEND="~x11-plugins/beryl-plugins-${PV}
-       ~x11-wm/emerald-${PV}
+       !noemerald? ( ~x11-wm/emerald-${PV} )
        kde? ( ~x11-wm/aquamarine-${PV} )
        gnome? ( ~x11-wm/heliodor-${PV} )
        ~x11-misc/beryl-settings-${PV}
        ~x11-misc/beryl-manager-${PV}
        >=x11-libs/cairo-1.2"

+pkg_setup() {
+       if use noemerald && ! use kde && ! use gnome; then
+               echo
+               ewarn "You have not selected any window decorator. For the meta"
+               ewarn "install, you should choose at least one of either emerald,"
+               ewarn "kde (aquamarine) or gnome (heliodor) decorators. Although"
+               ewarn "you may proceed without, you will have no window decorations"
+               ewarn "unless you enable emerald, kde, or gnome (unless provided"
+               ewarn "externally via another package)."
+               echo
+               ewarn "To enable the default window decorator, please disable the"
+               ewarn "noemerald use flag. Alternatively, set use kde or gnome for"
+               ewarn "aquamarine and/or heliodor, respectively."
+               echo
+       fi
+}
+
 pkg_postinst() {
        ewarn "DO NOT report bugs to Gentoo's bugzilla"
        einfo "Please report all bugs to http://trac.gentoo-xeffects.org"

What did we do here? Well, we added a noemerald use flag. The reason for noemerald is that we still want the default behaviour to be "let's install emerald" and optionally add aquamarine and/or heliodor. If the user sets the use flag noemerald explicitly, then they do not get emerald by default. This should prevent installs without a window decorator.

I also added a check/warning if the user mistakenly chose no window decorator by enabling noemerald and not setting kde or gnome use flags.

Anyway, that's the current update...