[Portland] In process? Out of process? And more...

Bryce Harrington bryce at osdl.org
Wed Dec 21 08:18:53 EET 2005


On Tue, Dec 20, 2005 at 07:10:56PM -0800, Dan Kegel wrote:
> On 12/20/05, Bryce Harrington <bryce at osdl.org> wrote:
> > On Sun, Dec 11, 2005 at 09:19:21PM -0800, Dan Kegel wrote:
> > > I like the idea of focusing on "installing an application into the menu system"
> > > as a test case.
> >
> > This looks like a great start; I've created a web page for this test
> > suite proposal, hope that's okay...
> >
> >     http://www.freedesktop.org/wiki/PortlandTestSuite
> >
> > So would this test suite simply be an application simulator, that would
> > run through an installation process and then validate that all the
> > various bits got installed to the expected locations and/or configured
> > appropriately?
> 
> Sure, I'm a test-first kind of guy; I like the idea of writing the spec, the
> test suite, and the implementation incrementally together.
> But all I was really trying to say is "let's focus on solving the
> simple problem of installing an app first to make sure we can actually
> get something real done before we jump into designing the
> hard things like print dialogs".

Ah, gotcha.  Well I can certainly see the value of just starting with
the menu system; I've wrestled with getting the Inkscape icon installed
into the menu for various permutations of distro + desktop environment +
packaging system a few years ago, before distros started taking care of
this for us.  My impression is that due to FDO, a lot of the
permutations have gone away, but I imagine a test suite to prove that
would give ISVs that much more confidence in the system.

> > I can definitely imagine how this test suite would be valuable well
> > beyond ISVs - distros and even OSS applications would probably be
> > interested to use this to measure how conformant various distros are to
> > the relevant standards.
> 
> I'd love to see the test of whether a desktop implementation
> actually does the right thing when an app is properly installed.
> You'd probably need to use the accessibility interface to query
> the menu system at runtime.  Hrm, is the interface promised in
> http://accessibility.freestandards.org/a11yweb/forms/soi.php
> ready yet?

I poked a bit at the accessibility documentation but it seemed fairly
sketchy and didn't touch on the menus, so I didn't get the feeling we
could rely on that for this testing, but that was just my first
impression. 

However...  I also fiddled with KDE's kmenuedit and added a "Foobar"
item to a submenu, and found that this caused "Foobar.desktop" to be
created at ~/.local/share/applications/Foobar.desktop, and an entry made
in ~/.config/menus/applications-kmenuedit.menu.  I have to plead guilty
to have only skimmed the FDO menu specification, but the Foobar.desktop
file appears to meet the requirements of Standards/desktop-entry-spec on
fdo, and the .menu file appears to meet the requirements of
Standards/menu-spec.

I imagine for a system-wide install of an application, it'd do something
similar to the above, but in a system location.

Anyway, do you think for the purposes of this test case, we could simply
check these specific locations for entries of the correct format, and
PASS if they're there?  This seems like it'd be fairly easy to write a
test for.

I imagine a complete test would also verify that the desktop environment
is parsing and loading these files accordingly, and maybe Accessibility
would play a role in programmatically checking that the desktop
environment is honoring the menu files and showing the application icon,
but this sort of seems like more of a compliance test for the desktop
environment itself.  So long as the ISV's installation mechanism
conforms to the FDO specs, and writes into the correct space, shouldn't
that be sufficient for passing the test case?  What do you think?

Bryce





More information about the Portland mailing list