I do it as well (sometimes). But I doubt that anybody from distro
maintainers read each line of config.log for each update of each
package
to verify, that all features were included.
Which is funny in a really sad kind of way, because you would think that
any company whose main business it is
The point of that formulation was to make clear that you can parse a .desktop
fils into individual lines, keys and value-blobs without concern for the actual
encoding used. Back in the days .desktop files could use different encodings
for different lines of the file, there was no single
Thanks to a rainy Sunday afternoon, xdg-utils 1.0.2 is now available
from http://portland.freedesktop.org/download/
Changes in xdg-utils 1.0.2:
* SVG icons are not supported but documentation still mentioned SVG
* xdg-email can now be used without any e-mail address
* Do not use mktemp
odd to me to have a specification in which no adjustments
can be made.
Thoughts?
-Jordan Mantha
Bastian, Waldo wrote:
The general problem with adding a main category is that on many older
distributions that do not support such new main category yet, desktop
files that use this new main
it to the list for more
discussion, thanks.
-Jordan Mantha
[0] http://bugzilla.gnome.org/show_bug.cgi?id=331142
Bastian, Waldo wrote:
If the .desktop is installed on an older Gnome system that didn't
support Science as a main category it would get dumped into Other
Yes, that was the intention
The general problem with adding a main category is that on many older
distributions that do not support such new main category yet, desktop
files that use this new main category will not be shown at all.
There is not really a good upgrade path.
Cheers,
Waldo
Intel Corporation - Platform
There was no special intention behind the trailing slash and I agree
that it could be removed to be more consistent with common ways to
specify paths. Implementations should behave properly either way.
Cheers,
Waldo
Intel Corporation - Platform Software Engineering, UMG - Hillsboro,
Oregon
It's a feature. SUSE added it to its menu at some point and later the
feature has been added to the menu spec in the form of the inline
attribute.
Cheers,
Waldo
Intel Corporation - Platform Software Engineering, UMG - Hillsboro,
Oregon
-Original Message-
From: [EMAIL PROTECTED]
, April 17, 2007 1:17 PM
To: Bastian, Waldo
Cc: xdg@lists.freedesktop.org
Subject: RE: KMenu fails when submenu has single item.
Waldo, Thank you for your quick response!
I think I can see what the feature is *supposed* to do: bump up a menu
item that has no siblings.
The problem is that it only
It's not required, but you can chose to do so.
Cheers,
Waldo
Intel Corporation - Platform Software Engineering, UMG - Hillsboro,
Oregon
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Sanel Zukan
Sent: Monday, March 26, 2007 8:12 AM
To: [EMAIL
Wrt 4) and 5), this is intentional. I'll fix 3).
See e.g.
http://standards.freedesktop.org/menu-spec/menu-spec-1.0.html#query-algo
rithm :
Note that an entry that is included in a menu but excluded again by a
later Exclude is still considered allocated (for the purposes of
OnlyUnallocated) even
Thanks, looks ok with me.
I will include these changes in the menu spec by the end of next week,
please raise any concerns, comments or objections well before that time.
Cheers,
Waldo
Intel Corporation - Platform Software Engineering, UMG - Hillsboro,
Oregon
-Original Message-
From:
On Wednesday 27 December 2006 13:14, Thiago Macieira wrote:
If a service is desktop-dependent, the desktop should acquire the
service
when it starts up. It makes more sense to me than creating a program
or
script that detects the desktop and spawns the correct
desktop-dependent
service.
John,
See the reference below to DBUS sessions. Doesn't DBUS have the ability
to inform any client about connects and disconnects of other clients to
the bus?
Cheers,
Waldo
Intel Corporation - Channel Platform Solutions Group - Hillsboro, Oregon
-Original Message-
From: [EMAIL
On Tue, 2006-11-21 at 16:12 -0500, Bastian, Waldo wrote:
KDE ignores trailing spaces. I'm ok to mandate that in the spec if
someone can provide a patch for Gnome/Gtk to do the same.
Just make sure there is a way to NOT ignore leading and trailing
whitespace. Using double-quotes for example
Le dimanche 19 novembre 2006, à 12:57, Christian Kellner a écrit :
On Sun, 2006-11-19 at 12:50 +0100, Vincent Untz wrote:
Thanks for the patch. I updated it to fix one or two things. I don't
think Path is required, so we shouldn't fail if it's not there.
cc'ing gnome-vfs-list to have it
I was not talking about the Standards page, but about this one:
http://freedesktop.org/wiki/Standards_2fmenu_2dspec
Ah. Sorry, I didn't realize that.
I suppose you're right - there could be a 'See Also' section there
that pointed to xdg-utils.
Anyone object?
Works for me.
Cheers,
Waldo
The landing page for XdgUtils is
http://portland.freedesktop.org/wiki/XdgUtils
Some additional links from www.freedesktop.org would be a good idea,
yes. I'm happy to hear that you volunteered for that task :-)
Some notes about how XdgUtils can be used in Appendix C of the menu spec
seems
The Exec line spec isn't a reflection of (everything) what GNOME and
KDE
do, it is a recipe for how to create an Exec line that is supported by
GNOME and KDE and other conforming implementations and it provides
conforming implementations with a limited set of syntactical
constructions that they
* It says that backslashes only escape text within double
quotes,
but GNOME and KDE both parse
one\ word
as one word and
\two words\
as two.
Yes, so although these constructions are supported by GNOME and KDE,
the
spec doesn't allow them
What I would really like to see is that the autostart stuff can be
merged into the normal desktop files that show up in the menus. In
this case, Hidden should be used to state that it shouldn't appear
in the menus.
NoDisplay means it shouldn't appear.
Hidden means to pretend it doesn't exist.
We
Desktops already configure a terminal to use for desktop entries that
have the run in terminal flag set. It shouldn't be too hard for a tool
like xdg-term to access this information and start such terminal.
Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform
Le mercredi 18 octobre 2006, à 14:49, Dan Winship a écrit :
- If a file contains the string [$i] on a line by itself
before the [Desktop Entry] group, then its contents are
considered immutable, and the startup system will not merge
in the contents of any
But it does have to be before the [Desktop Entry] group, to be
compatible with how lockdown works in KDE.
I feel this is unnecessary, but I won't fight for this, especially if
it's needed for compatibility reasons. I'm not sure GKeyFile makes it
easy to know the order of the groups, though.
If
Hi Waldo,
Le mercredi 11 octobre 2006, à 11:21, Bastian, Waldo a écrit :
Note that Gnome isn't complying very strictly with the FDO desktop file
spec anyway, so I wouldn't worry too much about that aspect.
Do you have specific bugs we can work on? :-)
I was about to mail you a test suite
A much simpler way to solve this problem is to have the default file
manager as the default
program to open the inode/directory (or anything like that). By doing
so,
opening a directory
would be as simple as opening any file, and any program would be able
to
use such feature, just by
using the
Back to the XGDUtils.
Everything works fine as long as I'm installing (with XDG script) them
with
'--mode user' but not '--mode system', also if I sudo them, then the
*.desktop file does not carry the proper icon and the assocations do
not
work. I've tried this on Ubuntu only. Is this correct
7. XSMP
Given that XSMP and autostart are closely tied together, and given
that XSMP is annoyingly underspecified, it seems to me like it
might
be nice to put some XSMP clarifications into the autostart spec
(though maybe others would feel that this is just as out of place
as
the
Aaron J. Seigo wrote:
we support $i as we do consistently across all configuration files.
this
avoids special rules in specific places and avoids us having to
prognosticate
what the admins/users of the world wish to do. they can simply do
what
they
want, our code remains simple and consistent,
Hi List,
new here, so excuse me if this is wrong place to ask this question.
I've tried to do my home work, spent some ten hours in the web but I
still
do
not know the answer.
How do I do file/mime/application associations in the freedesktop.org
style?
I understand that I create a myapp.xml
* regexp.diff
Since the only user of regexp was FilePattern, which is now
deprecated,
I suggest to remove regexp as type altogether. I propose
regexp-2.diff
which removes regexp as type.
I can't remember regexp-2.diff right now. If we specify in the part
where we describe FilePattern that
Hi Waldo,
Le mercredi 11 octobre 2006, à 11:21, Bastian, Waldo a écrit :
Note that Gnome isn't complying very strictly with the FDO desktop file
spec anyway, so I wouldn't worry too much about that aspect.
Do you have specific bugs we can work on? :-)
I was about to mail you a test suite
Le jeudi 07 septembre 2006 à 18:30 -0700, Bastian, Waldo a écrit :
The menu spec currently makes some weak recommendations with regard to
how categories are to be used. The reality however is that for an
application to show up in the application menu it must either define its
own submenu
://www.intel.com/opensource
OSDL DTL Tech Board Chairman
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of William Jon McCann
Sent: Thursday, September 07, 2006
8:50 PM
To: Bastian, Waldo
Cc: [EMAIL PROTECTED]
Subject: Re: PATCH: Menu Spec -
Categories
Hi Waldo,
On 9/7/06
I am happy to announce that at October 7 and 8 a free desktop Text
Layout and Font Handling workshop / BOF / summit will be held as part of
the Boston Gnome Summit.
Although the event is scheduled to coincide with the Gnome Summit for
logistical reasons, everyone with interest and experience in
Updated HTML version of the Appendix.
Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/opensource
OSDL DTL Tech Board Chairman
-Original Message-
From: Bastian, Waldo
Sent: Thursday
DTL Tech Board Minutes Workgroup conf call Aug 31, 2006 - Fonts
Executive Summary
=
The conference call on fonts was reasonable well attended with 12
participants. A new license for fonts, the Open Font License (OFL) was
explained. The OFL should speed up font development for
Im trying to formulate a few student projects to
improve freedesktop.org Over the last year I have heared several suggestions
that would be helpful to make freedesktop.org more successful. If people have specific
ideas with regard to things they would like to see improved (website / wiki /
Christian Neumair wrote:
Am Donnerstag, den 31.08.2006, 12:29 -0700 schrieb Bastian, Waldo:
My list so far includes:
* Improve website to allow easier tracking of implementation
status of specs.
* Add/expand test suites to specs (which specs in particular?)
A somewhat
I have commited icon-theme-spec.diff and fsdevice-kde.diff. Would be nice if
there was some more feedback on the other points mentioned so that we can move
that forward as well, one way or the other.
Cheers,
Waldo
Le mardi 22 août 2006, à 17:22, Bastian, Waldo a écrit :
Below I will propose
The OSDL DTL Technical Board is organizing a number of conference calls
on topics that, the tech board believes, are affecting Desktop Linux
adoption. This week's agenda topic is dedicated to Font support on
Linux.
OSDL DTL organized the second OSDL Desktop Architects Meeting (DAM)
earlier this
.
Shouldn't this behaviour (relative filenames in the Icon= field) be
described in the Desktop Entry Specification ? e.g. for the kind of usage I
was describing previously.
Best regards,
Rémi
On Wednesday 23 August 2006 00:55, Bastian, Waldo wrote:
The spec doesn't explicitly support
://www.intel.com/opensource
OSDL DTL Tech Board Chairman
-Original Message-
From: Benedikt Meurer [mailto:[EMAIL PROTECTED]
Sent: Monday, August 28, 2006 9:41 AM
To: Bastian, Waldo
Cc: Rémi; xdg@lists.freedesktop.org
Subject: Re: .desktop files with relative icons ?
Bastian, Waldo wrote
As many of you know freedesktop.org is a collaboration zone for open
software projects working on interoperability and shared technology for
X Window System desktops. Among others, freedesktop.org provides hosting
for X.org, Mesa GL, DBUS, HAL, Portland and a large number of other
software
Xdg-utils 1.0 beta3 is now available from
http://portland.freedesktop.org/download/xdg-utils-1.0beta3.tgz
Main changes:
* Test suite has been updated, test coverage has been extended and it is
a bit smarter in pointing out the real issues. (Instead of complaining
about too much stdout output)
*
-
[EMAIL PROTECTED] On Behalf Of Bastian, Waldo
Sent: Thursday, July 27, 2006 11:41 AM
To: desktop_architects@lists.osdl.org; [EMAIL PROTECTED]
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
On Wednesday 09 August 2006 00:26, Bastian, Waldo wrote:
Patch looks fine with me. Is there a specific meaning associated with
is KNOWN ?
I don't think so, besides is known. I guess it was done that way
just to
stress it and was copypasted to the desktop entry spec that way, but I
don't think
The Exec key must contain a command line. A command line consists of
an
executable program optionally followed by one or more arguments. The
executable program can either be specified with its full path or with
the name of the executable only. If no full path is provided the
executable is
What is your intention of the spec after it reaches 1.0? How is it
going to
be blessed anymore than any of the other specs on freedesktop.org?
Is there an intention to bring these to the FSG?
Yes, the intention is to include it in LSB 3.2
or come up with some semi-formal process for requesting
-
From: [EMAIL PROTECTED] [mailto:xdg-
[EMAIL PROTECTED] On Behalf Of Lubos Lunak
Sent: Tuesday, August 08, 2006 8:07 AM
To: xdg@lists.freedesktop.org
Subject: Re: Desktop Entry Spec 1.0
On Tuesday 08 August 2006 04:35, Bastian, Waldo wrote:
I will propose patches to the spec for review
I would like to declare the Desktop Entry Spec to be 1.0 after
proposing and including changes related to the following issues that
have been brought up on this list:
http://lists.freedesktop.org/archives/xdg/2006-April/008012.html
http://lists.freedesktop.org/archives/xdg/2006-June/008248.html
People interested in freedesktop.org specifications are hereby invited
to join next week's DTL Technical Workgroup conference call on this
topic. I have attached the preliminary agenda below. If you have
suggestions for additional agenda items, please let me know and I will
update the agenda
-discuss-
[EMAIL PROTECTED] On Behalf Of Aaron J. Seigo
Sent: Wednesday, August 02, 2006 12:52 PM
To: [EMAIL PROTECTED]
Subject: Re: [lsb-discuss] Desktop APIs
On Wednesday 02 August 2006 13:39, Bastian, Waldo wrote:
Also, KDE/Qt still doesn't support it last I checked. (But without
concenus it wouldn't
Hi Waldo,
Bastian, Waldo wrote:
Yippie, Xdg-utils 1.0 beta2 is released!
Head over to
http://portland.freedesktop.org/download/xdg-utils-1.0beta2.tgz to
play
with this puppie.
I'm happy to see that some of the problems I had with the
xdg-screensaver script [1] have been addressed. However
Welcome to the list :-)
I have added http://standards.freedesktop.org/menu-spec/1.0/menu.dtd now as
well. Thanks for pointing this out.
Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/go/linux
The spec currently doesn't support that. Having different
applications.menu files seems to me the easiest way to achieve this. I
suggest to change the spec a little and introduce an environment
variable that contains the name of the applications.menu file. Something
like
That's http://bugs.kde.org/show_bug.cgi?id=97776 It doesn't hurt to file
a bugreport against SLES10RC3 me thinks, maybe someone from suse fixes
it in KDE then.
Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation -
Next week Monday/Tuesday the 2006 Deskstop Developers' Conference will
be held in Ottawa. On monday morning I will be giving a presentation on
Portland and the afternoon of Tuesday will have a discussion track
dedicated to cross-desktop application development:
15h30 Discussion Group (Intro)
Hi Waldo and list,
On Sat, 2006-06-24 at 00:41 -0700, Bastian, Waldo wrote:
The curious that don't want to bother with unpacking tarballs can
read
the documentation here:
http://portland.freedesktop.org/xdg-utils-1.0beta1/
xdg-su really needs to go.
Thanks for your feedback I will look
OSDL DTL Tech Board Chairman
-Original Message-
From: David Zeuthen [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 06, 2006 3:45 PM
To: Dan Kegel
Cc: Bastian, Waldo; xdg@lists.freedesktop.org;
[EMAIL PROTECTED]
Subject: Re: [Portland] Doubts about xdg-su and xdg-screensaver (Was
Re:First xdg
This probably doesn't make much difference (at least for now) for KDE
apps and GNOME apps because they will continue to use their respective
icon loaders to load the icons. But, what about third party apps?
There needs to be standard so that they can have the DeskTop (probably
through Portland)
http://portland.freedesktop.org/wiki/
Portland is a new Free Desktop initiative coming out of the OSDL
Desktop
Architects' Meeting (hosted in Portland, Oregon in December 2005).
Portland intends to generate a common set of Linux Desktop Interfaces
and Tools to allow all applications to easily
On Thursday 29 June 2006 01:22, Bastian, Waldo wrote:
icons into a $XDG_DATA_DIRS location. It's ok to add these locations
to
the search path
... aside from the performance penalty of having yet more paths to look
at?
we
already look at a rather large number of directories in the icon spec
Then why do we have a specification that says where to put icons at
all?
Why isn't this all just part of the loader documentation?
For _some_ icons we care because they are relevant for multiple
different parties: menu icons, desktop icons, mimetype icons. Note that
application private icons
Not per se. If Portland can't find a themed version of the icon, the
app
can use any other method it seems fit to get to an icon. And as I
mentioned already before (Did you see that mail? It's hard to tell
from
your other mails) it is undesirable for applications to install icons
into
Wouldn't you want to provide compatibility with older versions too?
Older versions of itself? Dunno. Most applications include all the icons
they need and don't depend on icons from previous versions.
Of
course, if the goal for KDE4 is to just drop the old stuff without
compatibility, I don't
On Fri, 2006-06-30 at 08:34 -0700, Bastian, Waldo wrote:
I don't see this as a large problem. Apps that are installed in
private
locations -- /opt/app_name or /usr/share/app_name -- have to
start with a shell (e.g. Firefox OpenOffice) that sets environment
variables. So, it is going to add
James and I agreed that app-specific icons should be installed to the
$XDG_DATA_DIRS/$appname/icons/$theme/... path structure, and that these
such paths should be added automatically to the search list by the icon
theme implementation.
I don't think that applications should be required to install
On Mon, 2006-06-26 at 21:57 +0200, nf2 wrote:
The problem is, that this will only work for standard file-open/save
dialogs, but a lot of applications want to customize file-dialogs
with
their own widgets (previews, filter options, checkboxes etc...). In
this
case the coupling between the
I don't know why KDE chose: apps for the subdirectory when: kde
would have been a better choice.
KDE's file hierarchy is explained here:
http://www.kde.org/areas/sysadmin/fsh.php
Cheers,
Waldo
___
xdg mailing list
xdg@lists.freedesktop.org
Yes, sounds very useful.
Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform Solutions Group
Intel Corporation - http://www.intel.com/go/linux
OSDL DTL Tech Board Chairman
-Original Message-
From: [EMAIL PROTECTED] [mailto:xdg-
[EMAIL PROTECTED] On
Intel Corporation - http://www.intel.com/go/linux
OSDL DTL Tech Board Chairman
-Original Message-
From: James Richard Tyrer [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 28, 2006 8:14 PM
To: Bastian, Waldo
Cc: Rodney Dawes; Shaun McCance; xdg@lists.freedesktop.org
Subject: Re: Multiple
]
Sent: Wednesday, June 28, 2006 8:34 PM
To: Bastian, Waldo
Cc: James Richard Tyrer; Shaun McCance; xdg@lists.freedesktop.org
Subject: RE: Multiple DeskTops, HiColor theme, standardized icon names,
menu icons
On Wed, 2006-06-28 at 10:59 -0700, Bastian, Waldo wrote:
I don't know why KDE chose: apps
Hi Rich,
Thanks for your feedback. I'll try to incorporate it where feasible.
It would be nice if you had the option of passing the body via stdin.
The attach file method should let you specify the name of the
attachment. This could be useful (for example) if the user has asked
to attach a file
/go/linux
OSDL DTL Tech Board Chairman
-Original Message-
From: James Richard Tyrer [mailto:[EMAIL PROTECTED]
Sent: Friday, June 23, 2006 11:45 PM
To: Bastian, Waldo
Cc: Shaun McCance; xdg@lists.freedesktop.org
Subject: Re: Multiple DeskTops, HiColor theme, standardized icon names,
menu
This is to share the happy news that since a few days already the first
xdg-utils beta is available from:
http://portland.freedesktop.org/download/xdg-utils-1.0beta1.tgz
The curious that don't want to bother with unpacking tarballs can read
the documentation here:
KDE uses
$KDE_PREFIX/share/apps/app_name/icons/theme/size/type
for application specific icons.
It doesn't use XDG_PREFIX and neither should it as long as
$XDG_DATA_DIR/apps is not part of any XDG specification.
Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel
David and Alexander - could you perhaps send me the particular source
files
that deal with moving a file to the trash in KDE and Gnome? I'll try to
understand how things work. Or even better - if you have the time -
could
you
please compare the implementation to the specs, so that the specs could
The screensaver interface looks good. What is the use case for the
Poke method?
Power manager stuff looks nice as well, but maybe the KDE HW ppl can
comment on that a little bit better.
I think this fits in really nice with the long-term vision that Portland
has with DAPI (Deskop API). I would
Looks ok, unless objections are raised I will commit these changes by the end
of this week. Some additional comments:
Re: encoding.diff
In the chunk at line 148, I would mention that use of ENCODING is deprecated.
Re: multiple-groups
What about stating that multiple groups with the same name
Have you talked to the folks at freedesktop.org? They are doing good
work
I have but never have gotten an answer from freedesktop.org.
There are currently the GNOME and KDE user interface guidelines that
seem to cover pretty much the same set of topics. I agree that it would
be useful to have a
It's not entirely clear to me what you try to achieve here. That said...
Directory type .desktop files are used by the application menu to
provide a title and icon for sub-menus. KDE also uses them to provide a
title and icon for sub-directories when used in the file system. In
these cases the
The Portland project has proposed a xdg-su command that could be used
to prompt the user for elevated privileges. There seems to be some
objection to that approach though so it's probably a good idea if you
subscribe to the portland mailinglist and join the discussion there, in
particular it would
The point is that it does the lookup, how it does the lookup is up to
whoever makes this new desktop. That person just has to make sure to
provide a version of xdg-mime that works on this new desktop.
Waldo Bastian
Linux Client Architect - Client Linux Foundation Technology
Channel Platform
Better yet, let's not encourage people to turn .desktop files into
scripts. As has been expressed MANY times in this thread, requiring +x
and a special tool that doesn't evaluate Exec any differently thatn we
are currently evaluating Exec, doesn't solve the problem. It is very
easy to ship a
A viable strategy would be to start creating .desktop files with +x set
and a #!/usr/bin/xdg-open line now and then to wait a while before
environments actually start requiring it. In the meantime there could be
some config setting that people/distributions can use to enable it
before that time.
[Johnathan: This is a great example that highlights why I think we
should be defining interfaces for integration tasks (Like Portland does)
instead of writing a specification that is more proscribing how a
desktop environment should implement certain functionality (e.g. where
files should be
87 matches
Mail list logo
