[lsb-discuss] OSDL DTL Tech board on Portland - Thu, Aug 3
waldo.bastian at intel.com
Thu Aug 10 00:04:25 PDT 2006
DTL Tech Board Minutes Workgroup conf call Aug 3, 2006 - Portland
John Cherry, Jeff Tranter, Tom Whipple, Lubos Lunak,
Mickael Hallendal, Till Kampeter, Martin ... (?),
Marc Miller, Robert Schweikert, Waldo Bastian
* Xdg-utils 1.0
This week 2nd beta has been released.
Major changes: dropped xdg-su tool. Reasons: gnome-version
is not as widespread distributed, problems with consistency (stdout,
Needs to get more attention, maybe part of 1.1, maybe as stand alone
Picassa includes xsu, example of demand for this kind of functionality.
Instead of having ISVs include these su tools along with their
seems to make more sense to ship as part of OS. Attendees have no strong
opinion either way.
Main pushback based on philosophical grounds. Shouldn't invite graphical
apps to runs as root.
Other major change, addition of test suite.
Feedback so far, test reports coming in, feedback on xdg-screensaver.
Should do third beta to address problems with screensaver.
Screensaver currently shuts down gnome-screensaver entirely to suspend.
Which is too crude. Would disable related functionality as well.
xdg-screensaver takes care not to keep screensaver suspended after
application exits/crashes by tying it to X windowid.
xdg-screensaver was lacking xscreensaver support as well.
[Waldo: xdg-screensaver has been fixed in CVS since the conf call]
* Test Suite
Tom Whipple has been working on test suite. Tests most functionality
that tools provide. Test suite generates long test reports. Web
interface available to submit test reports and get collected in
freedesktop bugzilla. Wiki has link to show all test reports submitted
so far. Currently test reports for about 9 different
distribution/desktop versions. To submit test report, just open
xdg-test.log and copy and paste it in web submission form. You do need
to have a freedesktop bugzilla account, but there is a link to request
an account if you don't have one and it will automatically mail a
password back to you. Do make sure to include one test report in a log.
If you do run the test suite multiple times, multiple test logs will be
appended behind each other. Web submission form only accepts the log of
one test run at a time.
Noticed that some test report were run as root. Not needed to do that,
when running as normal user test suite will ask for root password and su
to root in order to run tests both as normal user and as root. That way
it will do more tests.
Test suite documentation should be updated to reflect that better.
Test suite needs to be cleaned up a little bit more. Currently has a few
"soft fails", where there is some small behavior changes between
different desktop implementations. Difficult to fix without changes to
upstream code. Will have to live with differences for now and will be
Example is screensaver which may or may not ask for a password when the
screensaver is "reset".
Few areas where testing needs to be extended a little bit more. For
example we have several tests related to icon installation but no test
that actually checks whether the icon is used on the screen. Requires
some additional tests.
Once test suite is brushed up a bit more, will do more testing of
different distributions. Invite everyone to run tests on as many
distributions as you can find and submit test reports of both successful
and unsuccessful runs.
Test reports so far indicate several problems with Debian based
distributions. Kubuntu (KDE on Ubuntu) is causing problems and needs to
be looked into, to see what exactly is going wrong there. Worrying is
that xsltproc is missing on several dsitributions.
xdg-mime relies on xsltproc for some tasks. If xsltproc is not part of
default install, we will need to find solution to work around that.
Q: has xdg-utils been tested on 64-bit?
A: xdg-utils does not contain any binary code and so is expected to run
just fine on 64-bit, but please run test suite to be sure.
* No one to talk about LSB SDK
Brought up by Ian Murdock, but not looked at since.
* Portland 2.0 / DAPI
Desktop integration based on IPC interfaces. Technology preview is
available at portland website. Preview made use of custom IPC
technology, considered to be a bad idea to invent own IPC, will switch
to DBUS in future.
OSDL is working with Imendio AB. Imendio has made GNOME version of
service daemons. Idea behind DAPI is to use single set of interfaces and
then have services that provide these interfaces that can be different
depending on the kind of desktop. Technology preview already has KDE
daemon, Imendio has now added Gnome daemon as well.
Gnome daemon is available from
Daemon is not in CVS yet. Should daemon go into Portland CVS, or
directly into Gnome CVS?
People agree that Portland CVS is a better place for now since
interfaces are not stable enough yet and overall design may still be
subject to change.
Imendio has been asked to port Gnome side of things to DBUS. Lubos will
look into porting KDE side of DAPI to DBUS.
Q: Once we move to DBUS, should there be special libraries that
applications can use to access functionality?
Sentiment is that generic DBUS bindings should be able to provide good
enough interfaces to portland APIs. For now assumption is that no
special portland cient libraries will be needed (other than DBUS client
Q: What should be delivrables for Portland 2.0?
- Interface definitions (based on DBUS)
- Test suite like xdg-utils has
Q: Can toolkit settings be made accessable via Portland? E.g. colors,
fonts, etc. Abaqus uses custom widget toolkit, not Qt or GTK+.
XSettings would be a good solution for this. Gnome publishes GNOME/GTK+
specific settings through XSettings. Mickael will post update to LSB and
XDG list with settings currently published through XSettings.
What is needed is to look at different toolkits and compare the models
for colors and fonts and abstract a toolkit model that can be used to
map settings from different toolkits to. E.g. color of scrollbar,
background, text, buttons, etc. Toolkits may have a slightly different
set of elements that they can assign different colors to. Requires
somewhat unified model of the different elements and mapping to keys in
the Xsettings space.
First step: Document theming/appearance settings of different toolkits
next to each other and identify commonalities and differences. Has
anyone done something like this already? Currently not aware of such
Would be possible to embrace standardisation of XSettings as part of
Portland initiative. Would be based on XSettings. No need to decide now
whether that would mean development of access library or just a pointer
to XSettings specification.
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/opensource
OSDL DTL Tech Board Chairman
>From: portland-bounces at lists.freedesktop.org [mailto:portland-
>bounces at lists.freedesktop.org] On Behalf Of Bastian, Waldo
>Sent: Thursday, July 27, 2006 11:41 AM
>To: desktop_architects at lists.osdl.org; portland at lists.freedesktop.org
>Subject: [Portland] OSDL DTL Tech board on Portland - Thu, Aug 3
>People interested in the Portland initiative are hereby invited to join
>next weeks DTL Technical Workgroup conference call on Portland. In the
>call we will discuss the upcoming xdg-utils 1.0 release, explain the
>test suite and what you can do to help with testing and look ahead to
>the next steps for the Portland initiative.
>Portland - DTL Technical Workgroup conference call
>Date: Thursday, 03 August 2006
>Time: 07:00am PT, 10:00am ET, 16:00 Paris, 10:00pm PRC
>DTL Technical call on "Portland":
>- xdg-utils 1.0
>- xdg-utils test suite
>- Portland 2.0: DAPI
>Visit http://portland.freedesktop.org for the latest information
>Linux Client Architect - Client Linux Foundation Technology
>Channel Platform Solutions Group
>Intel Corporation - http://www.intel.com/go/linux
>OSDL DTL Tech Board Chairman
>Portland mailing list
>Portland at lists.freedesktop.org
More information about the lsb-discuss