gmane.linux.xdg.devel

synaptics touchpad generates clicks whilst disabled

Peter Joanes — 2012-05-24T18:10:21

Hello,

I'm running xserver-xorg-input-synaptics version 1.5.99.902-0ubuntu5.1 on a 
Lenovo X300 (i.e. I recently upgraded to Xubuntu 12.04) and use the TrackPoint 
with the touchpad disabled which otherwise would generate unwanted input as my 
hand brushes it.
I have tried several different ways to disable the touchpad, which I think all 
amount to 'synclient TouchpadOff=1'. Unfortunately none of these has quite 
worked, as although the touchpad seems disabled, it still generates clicks 
when the trackpoint button is held down (i.e. whilst dragging).

Thanks,
-Peter Joanes.
<pjoanes< at >hotmail.com>

Simple thumbnailers?

David Nečas — 2012-05-20T22:15:47

Hello,

does any standard possibility exist to register simple specialised
thumbnailers that just run a program to create the thumbnail?

E.g. something like the

[Thumbnailer Entry]
Exec=...
MimeType=...

files that appear to work in Gnome3 (but that I cannot find actually
specified anywhere)?

I have looked at the only implementation of
org.freedesktop.thumbnails.SpecializedThumbnailer1 I was able to find,
maemo-video-thumbnailer.  IMO if you let people not understanding D-Bus
and thus not knowing what they are doing (such as me) implementing this
kind of stuff it can only lead to disaster...

Thanks,

Yeti

RFC: thumbnail: Modify to skip unreadable files

Dr. Michael J. Chudobiak — 2012-05-11T13:49:35

Hi all,

Another patch to consider for the thumbnail spec, based on a discussion 
4 years ago [1].

Basically, thumbnailers should not generated "failed" thumbnails for 
unreadable files, or they will remain un-thumbnail-able even if their 
permission are changed to make them readable.

[1] http://www.mail-archive.com/xdg< at >lists.freedesktop.org/msg04016.html
[2] https://bugs.freedesktop.org/show_bug.cgi?id=49799

Comments?

- Mike


_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

RFC: thumbnail: Modify to respect orientation tags

Dr. Michael J. Chudobiak — 2012-05-11T13:45:32

Hi all,

Here's another patch to consider for the thumbnail spec, requiring that 
thumbnailers respect the orientation tag in the image metadata, and 
encouraging the use of other image metadata (white balance, etc).

https://bugs.freedesktop.org/show_bug.cgi?id=49798

Comments?

- Mike

_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

RFC: thumbnail: Modify to follow the XDG Basedir Spec

Vincent Untz — 2012-05-11T12:54:26

Hi,

There's a patch in [1] to change the thumbnail spec to use the xdg
basedir spec to determine where to store thumbnails. Concretely, instead
of using ~/.thumbnails, $XDG_CACHE_HOME/thumbnails is used (falling back
to $HOME/.cache/thumbnails if $XDG_CACHE_HOME is not set).

I'm attaching the patch here for easier review.

Opinions?

Cheers,

Vincent

[1] https://bugs.freedesktop.org/show_bug.cgi?id=49607

Introducing realmd

Stef Walter — 2012-05-04T12:34:20

Hi there,

I'm working on making GNOME have an easy to use interface for joining a
realm [1] (or an Active Directory domain) so that you can use domain
logins on a machine. This is already doable on linux nowadays, but I'm
working on making it just take a few clicks and perhaps a password.

realmd (pronounced realm-DEE) is a DBus system service started on demand
which manages domain enrollment of the machine and setup of kerberos
logins and so on. It exposes a simple and extensible DBus interface [2]
which clients (like gnome-control-center) use.

It uses package-kit to install necessary packages, and policy-kit to
check for privileges.

It doesn't support every possible option and incantation for joining a
domain. The goal of realmd is to facilitate a really simple UI. For
example it automatically detects whether a given domain is an Active
Directory (and in the future IPA) realm, without asking the user to make
that choice. realmd tries to use intelligent defaults.

However a goal of realmd is to interoper

suse 11.1 lxde

2012-05-04T10:22:04

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi All,

I'd got fed up with gnome-3 and tried unsuccessfully to go back to gnome-2. I elected to
install opensuse 11.4 with LXDE - that I could install whatever software I wished and to
change the boot splash - the log-on screen and the desktop background to reflect that I
was using LXDE.

Sadly with heavy branding these are quite complex issues to change (I've changed my
desktop). "Boot-splash" and "Splashy" are installed but command line only and there's no
help either at opensuse or in the help system.

What I want is an 100 per cent LXDE desktop not a hard coded opensuse. The question I have
is a simple one: How do I get to a 100 per cent LXDE environment?

David
  .
- -- 
“See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the
kind.Stern, sane,every brain-cell perfect and complete even at the moment of death. No
delusion.” https://linuxcounter.net/user/512854.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linu

Thumbnail spec in git

Vincent Untz — 2012-04-26T08:19:22

Hi,

I had totally forgotten about this, but Jens sent me a while ago the
latest source of the thumbnail spec. I've pushed this to xdg-specs in a
branch for now:

 http://cgit.freedesktop.org/xdg/xdg-specs/log/?h=thumbnail

I'll merge that to master (and export it on the website) later on.

Cheers,

Vincent

Adding to Registered OnlyShowIn Environments

Darrell Anderson — 2012-04-21T14:44:38

Greetings,

I am writing on behalf of the members of the Trinity Desktop Environment (TDE) project.

TDE is a continuation of the KDE 3.5 desktop.

We want to add TDE to the list of Registered OnlyShowIn Environments:

http://standards.freedesktop.org/menu-spec/latest/apb.html

Please let me know how to proceed further.

Thank you!

Darrell Anderson

~/.local/share/pixmaps is not in search list for icons

Rodrigo Silva — 2012-04-19T06:53:56

The subject is a heads up for my issue, and here's the full story:

I'm making a script that will install Eclipse IDE from the binary archives
downloaded from http://www.eclipse.org/downloads/. Eclipse is quite a
standalone, self-contained IDE (provided you have a java vm) that you can
untar the archive to any folder (say ~/eclipse) and run directly from
there. No install required at all.

Still, my install script tries to set appropriate .desktop file entry,
icon, symlink to executable, etc, in a more "proper", XDG-compliant way.
It also allows system-wide and user-only installs. So, the basic steps
regarding locations are:

For system-wide install:
- extract to /opt/eclipse
- symlink /opt/eclipse/eclipse executable to /usr/bin/eclipse
- create a desktop entry in /usr/share/applications/eclipse.desktop
- copy the provided icon in /opt/eclipse/icon.xpm to /usr/share/pixmaps/eclipse.xpm

Works great, while trying its best to conform to standard XDG locations.
(and yes, I'm using the XDG_DATA* vars, not hardco

Support for localized Exec entries, please

Ronny Standtke — 2012-04-18T12:41:46

Hi

I provide desktop files with localized Exec fields to my users, e.g.:
----------------------------------------------
[Desktop Entry]
Categories=Education;Math;
Exec=firefox http://wiki.geogebra.org/en/
Exec[de]=firefox http://wiki.geogebra.org/de/
Exec[es]=firefox http://wiki.geogebra.org/es/
Exec[fr]=firefox http://wiki.geogebra.org/fr/
Exec[it]=firefox http://wiki.geogebra.org/it/
Exec[pt]=firefox http://wiki.geogebra.org/pt/
Icon=firefox
Name=GeoGebraWiki
Type=Application
----------------------------------------------

This works great when using KDE as desktop environment. Unfortunately, GNOME
seems to be missing support for Exec entry localization as it always 
opens the
English URL even when the user works with a different locale.

I reported this as a bug here:
https://bugzilla.gnome.org/show_bug.cgi?id=674204

It turned out that according to the specification, Exec is not supposed 
to be localized. I wonder if the spec could be changed to support 
localized Exec (and URL) entries?

Best regards

[ANN] MPRIS v2.2

Alex Merry — 2012-04-18T11:55:02

I am pleased to announce the release of version 2.2 of the Media Player
Remote Interfacing Specification (MPRIS).

MPRIS is a D-Bus interface which aims to provide a common programmatic
API for controlling media players.

It provides a mechanism for compliant media players discovery, basic
playback and media player state control as well as a tracklist
interface which allows client implementation to manipulate a short
playlist.

This version is backwards-compatible (as far as possible - see below)
with both version 2.1 and version 2.0.

Version 2.2 adds fullscreen control, and fixes shortcomings in earlier
versions where recommended behaviour was in conflict with the D-Bus
specification.

In particular, parts of the TrackList interface in 2.0 and 2.1 were
unimplementable as D-Bus does not allow empty object paths, and the
specification previously suggested using the PID as a bus name
component, even though D-Bus does not allow name components to start
with a digit.

The specification can be found at
   http:/

RFC: make menu implementations tolerant of vendor changes

Bill Nottingham — 2012-04-11T19:32:50

In Fedora, we've had the issue where some desktop files were incorrectly
shipped with a vendor prefix. Due to the fact that the file name often
is used as a key, we then are 'stuck' with either maintaining the bad
vendor prefix indefinitely (potentially incompatibly with other distributors
or upstreams), or changing the vendor prefix (breaking edited menus, user
shortcuts, and so on.).

One solution would be to have implementations be tolerant of vendor changes
in desktop file names - if they don't find a file with the vendor prefix, to
try again without the vendor prefix. Is this something that's worth adding
as a recommendation for implementations via XDG, or are there better
solutions?

Bill

Supporting mime types in desktop actions

Jerome Leclanche — 2012-04-03T17:40:04

Writing the intents spec, I found out that according to the desktop entry
spec:
http://standards.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html
Desktop Actions do not support a MimeType key. Is there a solid reason why?

My use case:
I have an image viewer and editor which supports viewing jpg and png,
however it can only *edit* png files. The "Edit" action would then only
support image/png while the main entry would support image/jpeg and
image/png.

One of the issues raised by supporting it is associating a mime type to an
action (rather than a desktop file altogether).
I propose the following syntax for mimeapps.list

image/jpeg=myapp.desktop;
image/png=myapp.desktop;myapp.desktop[Edit];

In brackets would be the name of the desktop action as specified by the
[Desktop Action Edit]. Possibly going even further, in the name could be
the entire section, eg [Desktop Action Edit], that way it may support
possible extensions to the spec though I find that a little verbose.

Thoughts?

J. Lecl

Proposal: preferred-theme-spec - a spec for getting and settingdefault icon/cursor/sound themes

Jerome Leclanche — 2012-03-25T20:47:59

Hi lists

Followup on my previous post, this is my submission for a spec that stores
default and fallback Icon, Cursor and Sound theme with the possibility of
adding more themes or metadata to it.

https://docs.google.com/document/d/1Slqk1yTFsiTBS0P8EnDcqp5G7sGmJ8SW7iQTdw7NUTs/edit

I'm looking for more comments and would like to eventually get the process
started on submitting it.

xdg / portland / razor lists CC'd.


J. Leclanche
_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

OpenRaster specification: possibly migrate to the fd.o wiki?

Andrew Chadwick — 2012-03-21T22:29:02

Hello, fd.o! My first post here.

I'm a developer working on an OpenRaster[0]-aware painting program
[1], but I've become hampered recently by the loss of the CREATE
project[2]'s wiki, which is where the working human-readable
specification for OpenRaster was kept[3] until recently. I'm seeking
to work on and extend the OpenRaster format in a couple of ways, but
also to make the text of it publicly available to other developers for
editing and improvement, and that's not possible with WayBack machine
copies and a private SQL dump of the previous wiki's blurb!

OpenRaster already exists as a FreeDesktop project, at least in the
bug tracker[4] and has much running code and schemas[5] for the
format's primary layers.xml file, plus support from two of the major
graphics programs out there. However it has very little in the way of
good, editable, public documentation and I'd like to change that, if I
may. It seems to me that the right place to move the specification is
somewhere under http://www.freedesktop.org/w

Needs feedback: Work on new "intents" spec

Jerome Leclanche — 2012-03-15T19:44:54

Good evening list

During the past couple of weeks, I've been working on a spec for intents
(best name I could come up with).

Intents are a way for applications to programatically describe what
functions they are able to fulfill. They go hand-in-hand with MIME types,
which describe on what type of content they are able to fulfill such
functions.
For example, while eog and Gimp may register the same MIME types, Gimp
would have an "Image Editor" intent, while eog would have an "Image Viewer"
intent.

The idea behind this spec is to:
 - Streamline the ways to describe some default applications in desktop
environments (default web browser, terminal emulator, ...)
 - Provide a way for applications to get and set the default application
for an action *without* having to pass it a mime-based argument (eg "Open
the default Web Browser" instead of "Open http://google.com").
 - Make it possible to open different applications on the same file/MIME
type, depending on what the application wants to do (eg: "Open in your

libxdg

DAV — 2012-03-13T16:47:04

Hi all!

I think it is the time for the next release of libxdg (rc-0.1.4), because I
have found (and fixed it)
some bug which leads to inconsistent information from the library. Also, I
have added
a convinient function "xdg_joint_list_contains_app()" which could be used
to ensure
that a given list contains a given ".desktop" file (for example, to check
that a given
".desktop" file is in "Removed Associations" section).

If I won't find any other serious bugs next release will be contain
documentation of
internal parts of the library (including format of the binary cache).


After "documentation release" I will take a look at
"update-desktop-database" and
investigate possibility of merging it with the library.

 --------------------------------
Best regards, Dmitriy.
_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

Suggestion to keep the type of a file or directory in the stat fieldst_rdev.

Stef Bon — 2012-03-13T10:42:18

Hi,

I've posted a suggestion about making the reading of directories
faster when the fileystem is considered to be slow. Recent versions of
the KDE dir listning calls, do not lookup the mimetype and .directory
files when dealing with a remote or FUSE filesystem. Below is the
message about storing information in the st.st_rdev field, which is
not used for "normal" files and directories. I did not get a reply
there, so I better post it here. What about it?


begin message:



I've been looking for a problem of this issue. I aggree that a
backthround thread or other process doing the (slow) reading of
mimetype and .directory files might work and bring the reading a lot
faster.

But the problem here is what causing this. First the determination of
the filetype (mimetype for regular files). It can be slow, and doing
that over and over again is silly. Why not use the field st_rdev part
of the stat struct. It's not used for regular files, and large enough
to hold an unique id to a (standard) database of filetypes.

RFC: New category XFCE for menu-spec

Samuli Suominen — 2012-03-07T17:30:19

I've started seeing these with latest Xfce git:

* /usr/share/applications/example.desktop: value 
"XFCE;GTK;Settings;DesktopSettings;X-XFCE-SettingsDialog;X-XFCE-SystemSettings;" 
for key "Categories" in group "Desktop Entry" contains an unregistered 
value "XFCE"; values extending the format should start with "X-"

And I've discussed it at #xfce-dev on Freenode with 2 developers and the 
response was that this won't be changing and it's correct.

Therefore I'm suggesting XFCE to be included in the

http://standards.freedesktop.org/menu-spec/latest/apa.html

The same way GNOME is there right now:

GNOMEApplication based on GNOME librariesGTK
XFCE    Application based on XFCE libraries     GTK

Jannis Pohlmann (jannis at xfce.org) ACK'd this request.

xdg xembed specs broken?

Mikkel Kamstrup Erlandsen — 2012-03-02T10:03:13

Is it just me or is there no human readable version of the xembed spec
available?

http://standards.freedesktop.org/xembed-spec/ does not contain any
document that can be rendered in the browser.

Cheers,
Mikkel