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 interoperate well with the current tools
for doing this stuff, so advanced deployments can continue to use distro
or custom tools.

realmd is designed to support more than just Kerberos realms, although
that's all it implements for now. For example in the future it could
help the user setup Google Account based logins [3].

realmd supports setup of different stacks to handle the enrollment and
authentication (eg: Samba+Winbind or SSSD are two different stacks). So
far only support for Samba+Winbind has been implemented.

Since there are some obvious differences between setting this stuff up
on various distros, realmd has a way of doing basic customizations
per-distro. I only have it working on Red Hat distros right now, but
will shortly add Debian and a few others.

Anyone interested in working with me on this? I'm really early on in
this project right now, but it's hackable [4] and usable, and I'll get a
proper project setup shortly.

Cheers,

Stef

[1] Part of this work:
https://live.gnome.org/Design/Proposals/UserIdentities

[2]
http://cgit.freedesktop.org/~stefw/realmd/tree/dbus/org.freedesktop.realmd.xml

[3] http://www.chromium.org/chromium-os/chromiumos-design-docs/login

[4] Lives here for now, but will move to fdo git:
http://git.freedesktop.org/~stefw/realmd

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/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEVAwUBT6OtzOJpqm7flRExAQIP7ggAnx1sA5xbQCvNkcfUOFh3F+hikKWOyDmB
58Vo+5XGRcEA/CoClwE9E1Y69hAefbgeh3yXb8NmANFMV9LyPlFKJdSCCuZc5o7j
oFC7D+HJTiPRJyFDrAcAn9oonPhavlaH6xJbDr6xu0m+jWWxmR1q+GwWXA96MI0I
GCggA/9VcjWEPF+w8W6f30n5CSF6KkqFR3YFPCT9hR2JJRqgnBOHN9YDlNPOEtBB
Fcx2MWShuMdE6pk765N/P/95bS3398MSgRAg8xzbsE1ZN9R41xfgEUgH+xEkX0jZ
YBlaioB0+yvoxabXRXV5jHJIr2zZmXz5oJExrkZ3pFJVImwq2U4P/A==
=cDEC
-----END PGP SIGNATURE-----
_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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 hardcoding paths)

For user install:
- extract to ~/.local/opt/eclipse
- symlink ~/.local/opt/eclipse/eclipse executable to ~/bin/eclipse
- create a desktop entry in ~/.local/share/applications/eclipse.desktop
- copy the provided icon to... ?

See the problem? The obvious place would be ~/.local/share/pixmaps/eclipse.xpm,
but that folder is not in search list for icons. For the user I must use
~/.local/share/icons/hicolor/48x48/apps. So my issues are:

- There's no "symmetry" in system-wide and per-user locations regarding icons,
so I must use /usr/share/icons/.. tree for a xpm icon instead of its "natural"
place at /usr/share/pixmaps

- Or I could hardcode ~/.local/share/pixmaps/eclipse.xpm in it's .desktop file,
which is not a recommended practice

So, what should I do? Why the Icon Spec does not define ~/.local/share/pixmaps
for the user, just /usr/share/pixmaps ? Are pixmaps a legacy dir, and only
present in system path for backward-compability?

if so, is it ok to place xpm icons in the /usr/share/icons... tree? Should I
completely disregard /usr/share/pixmaps? Or should I not care about "symmetry"?

What is the best approach to follow? Any background info is highly appreciated

Thanks,
Rodrigo

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

Ronny

[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://specifications.freedesktop.org/mpris-spec/2.2/

The git repository is at
   git://anongit.freedesktop.org/git/xdg/mpris-spec

For more information, please see
   http://www.freedesktop.org/wiki/Specifications/mpris-spec

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. Leclanche
_______________________________________________
xdg mailing list
xdg< at >lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg

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/wiki/Specifications - would
that be acceptable? I think OpenRaster meets the fd.o Mission
Statement quite nicely.

I'm new to fd.o, but given that all we need right now is a small
amount of wiki space to host some explanations of the fields, what
values they can take, and their meanings, presumably I should just add
it in under http://www.freedesktop.org/wiki/Specifications ?
Suggestions for the right section to use would be welcome.


[0] A layered static raster graphics file format used by Krita, Gimp, and [1]
[1] MyPaint, http://mypaint.intilinux.com/
[2] http://lists.freedesktop.org/mailman/listinfo/create
[3] http://wayback.archive.org/web/*/http://create.freedesktop.org/wiki/OpenRaster
[4] https://bugs.freedesktop.org/describecomponents.cgi?product=OpenRaster
[5] https://gitorious.org/openraster

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
default image editor" from an image viewer)

I originally brought this up on the Razor-Qt mailing list:
https://groups.google.com/forum/?fromgroups#!topic/razor-qt/LV8StxmvDns

The spec is a great occasion to keep consistency up; it would be quite
similar to the MIME type spec. In three major parts:
 - A description of intents in .desktop files
(Intent=Intent1;Intent2;Intent3)
 - A way for users to override intents, like mimeapps.list (intents.list)
 - A front-end application to open and set intents without having to link
to an xdg library (xdg-intent)

I recommend reading the above link for more insight into the idea. One
point I'd like to stress:
Intents free to be chosen by the developer; XDG would recommend specific
intent names for specific actions (eg: ImageEditor for editing images).
However, should a developer want to give an intent to an use case that has
not been specifically listed by XDG (say, a twitter client), they would be
free to choose their own. If more apps appear with the same use case, xdg
would do well to list an official intent.

An unanswered question still remains: the naming scheme for each intent.
Two obvious options stand:
 - A MIME-style naming scheme: intent/image-editor. I am not convinced it's
the best way to go as developers might get confused between the separation
of intents and mime types (intents are *not* mime types)
 - A simple name, maybe with periods. ImageEditor, SystemSettings,
SystemSettings.Audio, xdg.intent.SystemSettings.Audio.

Would love to gather some more feedback from this list before writing a
spec. I also want to write some tools for it, including a python library
and, essentially, xdg-intent.

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

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.

This st_rdev attribute is only used special files as far as I know,
and is zero for regular files and directories. On my machine the type
is or unsigned long int, or better unsigned long long int.

In any case it's big enough.

It's safe to use an id, A mp3 file will not turn in a ogg file
suddenly, a pdf will never become a doc or something else.
Apps creating these files can set this value, and apps using the file
can set it when it's not been set before, or correct it when not set
to the right value.

When using this value, there is no other process required, it comes to
an app like dolphin just like the mode (filetype, owner, group,
permissions, times) does.

Futher when it comes to directories, the reading of the .directory
file is a time consuming task. In my FUSE fs, I'm using the mimetype
for directories like:

mimetype="inode/directory;role=remote.net.smb.network"

for the directory representing the SMB network for example. More examples:

local.map.system.programs
local.dev.cdrom.audio
local.map.documents
local.map.audio

etc.

Because the mimetype gives you a default icon (just like this mimetype
does for regular files) it's not required to use a .directory file for
setting and using the .directory file for an icon.
And it's possible to store this mimetype for directories also in the
st_rdev field.

I'm not saying that .directory files are useless, but using the
mimetype for directories can speed up things. And - as I see it -
directories can have a special meaning within the context of the
computer or the user, and till now there is no way to set this. Using
the role part of the mimetype makes that possible.

Stef

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