On Mon, May 23, 2016 at 12:54 PM, Bastien Nocera wrote:
> On Mon, 2016-05-23 at 10:58 +0200, Samuel Thibault wrote:
>> Hello,
>>
>> We need a place for people to find accessibility helpers such as
>> screen
>> readers, magnifiers, etc. Hiding them into "Settings", "System", or
>> "Utility" does no
If it's a proprietary format, it should be text/vnd.duxbury.brf or some such.
If it's an open format, text/brf is likely fine.
It's worth noting I'm seeing references to text/plain encoding=brf...
which doesn't seem correct.
https://bz.apache.org/bugzilla/show_bug.cgi?id=41240
J. Leclanche
On M
preciate it. Don't worry, I'm not asking anyone to
> do all the work for me, I'm still going to file the bug and make sure
> everything complies with the mime spec.
> Thanks
> Kendell Clark
>
>
> Jerome Leclanche wrote:
>> Your first step will be figuring out i
Your first step will be figuring out if there is any existing media
type for this type of file.
Looking at http://www.digitalpreservation.gov/formats/fdd/fdd000103.shtml#sign
I see audio/audible
audio/x-pn-audibleaudio, the latter which looks like it could be used in xdg.
After that you'll want t
On 20 November 2015 at 22:54, Thomas Kluyver wrote:
>
> Also, I'm not sure the Linux desktop has much of a future unless the
> situation improves sooner. The number of Linux desktop users I know is
> dwindling as they convert to Mac. Programming conferences, even where
> open source software plays
This is something I tried solving quite a few times. There was an
intents spec (a la android) in the works which was subsequently picked
up by GNOME, I don't know where it's at now but it's the more correct
fix.
On 20 October 2015 at 13:37, Thomas Gläßle wrote:
>
> Thomas Gläßle wrote on 10/20/20
Hi
Would anyone be opposed to adding an optional "Style" key (name tbd)
to index.theme, that would identify whether the icon theme is dark or
light?
The need comes from previewing the icons in a config dialog. The icons
are invisible if the theme is dark, because the config dialog has a
light bac
Hi
Just earlier a user encountered an issue with xdg-settings, which
would complain about an "unknown desktop environment". Looked in the
code and sure enough, it hard-checks for $XDG_CURRENT_DESKTOP and
actually only implements kde, gnome and xfce. All other DEs are
implemented with a "dispatch_g
ly expected to update
> the mime database themselves. And that they know how to do it. Is this
> really reasonable? It may be, like running ldconfig after install, but
> updating mime cache seems to me to be a bit more obscure.
>
> Carnë
>
> On 2 March 2015 at 19:24, Jerome Lec
This is something that is handled by the downstream packagers and you
should not worry about it.
Example:
https://projects.archlinux.org/svntogit/community.git/tree/kdenlive/trunk/PKGBUILD
https://projects.archlinux.org/svntogit/community.git/tree/kdenlive/trunk/kdenlive.install
J. Leclanche
On
Aren't we talking protocol here? UI can be argued elsewhere, to be honest...
Anyway, protocol-wise, why isn't this the job of the notification
client? (Mobile notification clients do it that way fwiw)
J. Leclanche
On 16 February 2015 at 20:52, Thomas Kluyver wrote:
> On 16 February 2015 at 10:
2015-01-20 18:58 GMT+01:00 Carnë Draug :
> Hi
>
> scons [1] is a build system and I was thinking of adding it to
> shared-mime-info. Its files are very simple to identify, they are
> always named SConstruct or SConscript. These files are also valid
> python scripts.
>
> Should shared-mime-info id
2015-01-16 23:46 GMT+01:00 Reuben Thomas :
> On 16 January 2015 at 22:44, Jerome Leclanche wrote:
>>
>> xdg-utils does not depend on perl; all the tools are in shell. You
>> should talk to your distro.
>
>
> If you read back to the beginning of my thread, you'
xdg-utils does not depend on perl; all the tools are in shell. You
should talk to your distro.
J. Leclanche
2015-01-16 22:11 GMT+01:00 Steven Stewart-Gallus
:
> Hello.
>
> I'm just some random guy but anyways.
>
> As a user and administrator, I dislike excess dependencies on my
> system such as P
It looks like there is an instance of patchwork
(http://jk.ozlabs.org/projects/patchwork/) running on port 443 and
that's it, the wiki software is only on port 80. Not sure why Apache
can't simply route both over both ports.
This is an issue for the fd.o sysadmins and I don't think you'll find
the
Agreed on aliases.
As far as inheritance goes... Let's look at it on a case by case basis.
The user opens an HTML file. It opens with Firefox. They set notepad as the
app for HTML -> Notepad can now read HTML files.
Notepad should not implicitly be suddenly interested in all text files.
Let's im
2014-10-29 21:45 GMT+01:00 Ryan Lortie :
> In retrospect, I'd like to modify the specification to require that an
> app is valid for a given type in order to be considered as a default.
+1. If someone wants to make an app default, they would have to add
the association then. Sounds completely reas
Hi guys
I barely remember what was decided last year during the summit, and I
didn't exactly follow what then ensued as for modifications to the
spec... so, currently, which document is correct regarding the opening
order of defaults.list and its many cousins?
This is the current code in LXQt and
d like to patch firefox with it once it’s nailed down, and i think the
> evidence of usage is enough.
>
> Best, phil
>
>
>
>
> 2014-04-07 17:38 GMT+02:00 Philipp A. :
>
>> 2014-04-07 15:15 GMT+02:00 Jerome Leclanche :
>>
>>> All the web browsers alre
On Mon, May 19, 2014 at 1:26 PM, cheater00 . wrote:
> Hi Jerome,
>
> On Mon, May 19, 2014 at 1:23 PM, Jerome Leclanche wrote:
>> I think an x11-related list might get you some better answers. However
>> as it happens I made my own xkb layout a while ago. The bad news is I
&
I think an x11-related list might get you some better answers. However
as it happens I made my own xkb layout a while ago. The bad news is I
never quite figured out how to install it as a separate layout, so
what I do is actually replace symbols/us with my layout.
I don't think you're supposed to
If you're looking for code,
https://github.com/lxde/libqtxdg/blob/master/xdgmenu.cpp is a good
starting point.
J. Leclanche
On Mon, May 12, 2014 at 5:26 PM, José Félix Ontañon
wrote:
> Hi,
>
> I'm trying to build an app that automatizes the excluding of some launchers
> from menu, by tweaking ~/
On Mon, Apr 14, 2014 at 3:19 PM, Côme BERNIGAUD
wrote:
>
>> That's for media types though. According to the spec the fallback for
>> devices is understood as --.
>> Falling back on "headphone" if "headphone-headset" is not present
>> sounds fine, but then needs to be specified as such imho.
>> "dr
of
that icon :)
We could move router to network-router. modem can stay where it's at.
Forgot two in my original email: drive-harddisk-ssd, for SSDs (falls
back to drive-harddisk) and media-sim for SIM cards (need it on phones
and tablets).
>
> Looking forward to reading your patch.
&
Hi list
I'm in need of some extra devices which are not currently specified in
the icon-naming-spec. Namely:
devices:
tablet: A portable large-screen device with touch capabilities (eg
ipad; NOT an input device, different from input-tablet)
laptop: A "computer" device recognized as a laptop.
eboo
On Sun, Apr 13, 2014 at 9:39 PM, Vladimir Kudrya wrote:
> On 14.04.2014 00:32, Jerome Leclanche wrote:
>
> That *is* the rule, downstream always overrides. You calculate the
> list on each step while adding items to the blacklist as you find them
> *from most local to most globa
On Sun, Apr 13, 2014 at 9:29 PM, Vladimir Kudrya wrote:
> On 14.04.2014 00:20, Jerome Leclanche wrote:
>>
>> On Sun, Apr 13, 2014 at 9:15 PM, Vladimir Kudrya
>> wrote:
>>>
>>> On 13.04.2014 21:54, Jerome Leclanche wrote:
>>>
>>> Readin
On Sun, Apr 13, 2014 at 9:15 PM, Vladimir Kudrya wrote:
> On 13.04.2014 21:54, Jerome Leclanche wrote:
>
> Reading local first, you will find the foo.desktop file *before* you
> arrive to the item in the global blacklist.
>
> That is if you just need to find the defaul
On Sun, Apr 13, 2014 at 6:34 PM, Vladimir Kudrya wrote:
> Hello everyone!
> I am translator and tester of SpaceFM file manager.
> There were some heated discussion of the new mime spec
> https://github.com/IgnorantGuru/spacefm/issues/450
>
> As it is still in flux I'd like to share some thoughts.
All the web browsers already use the same convention, don't they? If
so, it should probably be added, yes.
J. Leclanche
On Sun, Apr 6, 2014 at 6:35 PM, Philipp A. wrote:
> hi people,
>
> how about adding zoom-in and zoom-out to the cursor spec? (I’d guess
> “nice-to-have” section)
>
> http://www
2014 at 2:50 AM, Mark Edgington wrote:
> On Sat, Apr 5, 2014 at 6:11 PM, Jerome Leclanche wrote:
>> For what it's worth, I agree. However the use case of browsers asking
>> to be default has to be taken into account, and we are very far from
>> being able to offer th
>
> On Sat, Apr 5, 2014 at 6:11 PM, Jerome Leclanche wrote:
>>
>> For what it's worth, I agree. However the use case of browsers asking
>> to be default has to be taken into account, and we are very far from
>> being able to offer them an api to *properly* become s
For what it's worth, I agree. However the use case of browsers asking
to be default has to be taken into account, and we are very far from
being able to offer them an api to *properly* become so.
J. Leclanche
On Sat, Apr 5, 2014 at 9:04 PM, Jasper St. Pierre wrote:
> No idea how "DPNH" got there
On Thu, Apr 3, 2014 at 12:39 AM, Luc Menut wrote:
> Le 02/04/2014 17:06, David Faure a écrit :
>
>> After so many years, he's finally a proposal for a unified mechanism for
>> selecting the default application for a given mimetype.
>>
>> The mechanism is unified, but note that it supports differen
Pinging this again. There's a patch; if it's no good, a discussion on
it would be nice.
J. Leclanche
On Sun, Apr 28, 2013 at 2:55 PM, Jerome Leclanche wrote:
> Hi
>
> Any update on this?
>
> J. Leclanche
>
>
> On Mon, Oct 22, 2012 at 8:10 AM, Jerome Leclanc
Anyone has any thoughts on this?
J. Leclanche
On Wed, Jan 15, 2014 at 6:03 PM, Jerome Leclanche wrote:
> Hi list
>
> I mentioned in my email about intents that we need to be able to bind
> Desktop Actions to mime types (and potentially intents). I'm going to
> implement s
Hi,
On Wed, Feb 19, 2014 at 1:03 PM, Ryan Lortie wrote:
> hi,
>
> On Wed, Feb 19, 2014, at 7:40, Simon McVittie wrote:
>> I agree that storing state in ~/.config is a bug, but I think that's a
>> misuse of existing categories rather than a need for a new category -
>> why wouldn't ~/.local/share
On Thu, Feb 6, 2014 at 6:10 AM, Samuli Suominen wrote:
>
> On 03/02/14 04:50, Rex Dieter wrote:
>> David Faure wrote:
>>
>>> On Tuesday 21 January 2014 11:01:17 Rex Dieter wrote:
>>>> Jerome Leclanche wrote:
>>>>> I'm findin
The audio/x-riff mime type is causing me trouble currently. Namely, it
is conflicting with image/webp as webp images are based on RIFF
containers (this hasn't come up since only kde ships a webp mime type
for now).
Why is there an audio/x-riff mime type at all? The only riff-based
audio is wav, wh
On Tue, Dec 31, 2013 at 10:23 AM, David Faure wrote:
> On Monday 23 December 2013 09:38:02 Jerome Leclanche wrote:
>> See: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
>>
>> I think I already know the answer to both but I'd like to double-ch
On Tue, Jan 21, 2014 at 5:01 PM, Rex Dieter wrote:
> Jerome Leclanche wrote:
>
>> I'm finding a lot of conflicting information. Which to use? I'm using
>> mimeapps.list currently, I was certain defaults.list was the
>> deprecated one but I need an offic
On Tue, Jan 21, 2014 at 8:48 AM, Bastien Nocera wrote:
> On Sun, 2014-01-19 at 19:03 +0000, Jerome Leclanche wrote:
>> I'm finding a lot of conflicting information. Which to use? I'm using
>> mimeapps.list currently, I was certain defaults.list was the
>> deprec
I'm finding a lot of conflicting information. Which to use? I'm using
mimeapps.list currently, I was certain defaults.list was the
deprecated one but I need an official word on this.
J. Leclanche
___
xdg mailing list
xdg@lists.freedesktop.org
http://list
Hi list
I mentioned python-xdg before:
https://github.com/Adys/python-xdg
Lately I've been updating it and using it as a reference
implementation for the various improvements highlighted in my intents
email from the other day.
The xdg.mime module implements an interface for interacting with mime
On Wed, Jan 15, 2014 at 9:29 PM, Alexandre Franke
wrote:
> On Wed, Jan 15, 2014 at 8:00 PM, Cosimo Cecchi
> wrote:
>> Hi all,
>
> Hey,
>
>> Feedback welcome!
>
> Music player usually get all the content of the Music directory and
> then grab metadata to present the tracks filtered by
> artists/a
Hi list
I mentioned in my email about intents that we need to be able to bind
Desktop Actions to mime types (and potentially intents). I'm going to
implement support for this next in my lib and I wanted to ask opinions
about syntax.
This is an example of a registered mime action:
[Added Associat
ther (nevermind NoDisplay).
J. Leclanche
On Mon, Jan 13, 2014 at 8:50 AM, Bastien Nocera wrote:
> On Sat, 2014-01-11 at 13:36 +0100, Albert Astals Cid wrote:
>> El Dissabte, 11 de gener de 2014, a les 02:28:18, Jerome Leclanche va
>> escriure:
>> > Consider the following use ca
Consider the following use case:
"gimp" supports image/png. "gimp-webp-plugin" makes gimp support image/webp.
How would gimp-webp-plugin declare that it makes another app support
additional mime types? I don't think it's possible currently.
Suggestions?
Mime actions could theoretically do that (
A TerminalEmulator intent could very well support a *standardized* api
that does something similar to -e.
J. Leclanche
On Wed, Jan 8, 2014 at 6:15 PM, Dominique Michel
wrote:
> Le Wed, 08 Jan 2014 14:11:04 +,
> Simon McVittie a écrit :
>
>
>>
>> GNOME in Debian also needed its defaults to b
Core: Important application, core to the desktop such as a file
manager or a help browser
This is very annoyingly worded. I honestly don't like that category at
all, but if it's there I don't know if it can be deleted. Could it be
reworded at least to something that's less.. invitingly broad?
[
On Mon, Jan 6, 2014 at 1:25 AM, Jerome Leclanche
wrote:
> Problem #1
> Apps cannot enumerate other apps of a specific type. A couple of
> common use cases:
> - A system settings app wants to know about every window manager,
> terminal emulator, ... so it can show them in a
hat it makes sense to accept it as a URI.
Furthermore I have no idea what you mean by "gaining support for my
protocol". You are conflating protocols and URIs.
J. Leclanche
>
>
> On Tue, Jan 7, 2014 at 10:34 AM, Jerome Leclanche wrote:
>>
>> On Tue, Jan 7, 2
On Tue, Jan 7, 2014 at 3:24 PM, Dominique Michel
wrote:
> Le Mon, 6 Jan 2014 15:38:34 +,
> Jerome Leclanche a écrit :
>
>> On Mon, Jan 6, 2014 at 1:56 PM, Bastien Nocera
>> wrote:
>> > On Mon, 2014-01-06 at 14:48 +0100, David Faure wrote:
>> >>
On Mon, Jan 6, 2014 at 3:29 PM, Kevin Krammer wrote:
> On Monday, 2014-01-06, 01:25:58, Jerome Leclanche wrote:
>
>> There's a lot TBD still. For example: Do we require apps implementing
>> an intent to support every method of the intent? I don't think it's
>&
On Mon, Jan 6, 2014 at 1:56 PM, Bastien Nocera wrote:
> On Mon, 2014-01-06 at 14:48 +0100, David Faure wrote:
>> On Monday 06 January 2014 14:44:27 Bastien Nocera wrote:
>> > On Mon, 2014-01-06 at 14:35 +0100, David Faure wrote:
>> > > On Monday 06 January 2014 14:28:01 Bastien Nocera wrote:
>> >
On Mon, Jan 6, 2014 at 4:48 AM, Ryan Lortie wrote:
> hi,
>
> On Sun, Jan 5, 2014, at 23:11, Jerome Leclanche wrote:
>> though. My original wish was for an app dev to be able to just say
>> "this app is a TwitterClient".
>
> What does this mean? What makes
On Mon, Jan 6, 2014 at 3:50 AM, Jasper St. Pierre wrote:
> On Sun, Jan 5, 2014 at 9:52 PM, Jerome Leclanche wrote:
>>
>> On Mon, Jan 6, 2014 at 2:42 AM, Ryan Lortie wrote:
>> > hi,
>> >
>> Yes, that was my original idea with intents. I reconsidered afte
On Mon, Jan 6, 2014 at 2:42 AM, Ryan Lortie wrote:
> hi,
>
> On Sun, Jan 5, 2014, at 20:25, Jerome Leclanche wrote:
>> Problem #1
>> Apps cannot enumerate other apps of a specific type. A couple of
>
> It is my "intent" (ha...) to raise for a while that I wan
I recently brought up "intents" on this list and several people didn't
know what they actually were, and I didn't want to talk about them too
much until I had a clear idea of it all.
To be clear: This is about more than just intents, and some of what
I'm going to be talking about can be taken care
On Tue, Dec 31, 2013 at 4:20 PM, Jasper St. Pierre
wrote:
> On Tue, Dec 31, 2013 at 6:12 AM, Jerome Leclanche wrote:
>>
>> So that detail should be in the menu spec, not the desktop file spec.
>> I see no mention of TryExec in
>> http://standards.freedesktop.org/m
On Tue, Dec 31, 2013 at 11:05 AM, David Faure wrote:
> On Tuesday 31 December 2013 11:00:23 Jerome Leclanche wrote:
>> On Tue, Dec 31, 2013 at 10:55 AM, David Faure wrote:
>> > On Tuesday 31 December 2013 05:44:12 Ryan Lortie wrote:
>> >> hi,
>> >>
On Tue, Dec 31, 2013 at 10:55 AM, David Faure wrote:
> On Tuesday 31 December 2013 05:44:12 Ryan Lortie wrote:
>> hi,
>>
>> On Tue, Dec 31, 2013, at 5:39, David Faure wrote:
>> > It is missing in many many
>> > .desktop
>> > files, but this means solving this doesn't require a change in the spec,
Packages ship their mime types in /usr/share/mime/packages. The
default mime types are shipped in
/usr/share/mime/packages/freedesktop.org.xml. These are xml files
containing all the mime types shipped by the application by its name.
update-mime-database "splits" it into the /usr/share/mime
subdire
ensible idea.
J. Leclanche
On Sun, Dec 29, 2013 at 1:05 PM, Thiago Macieira wrote:
> On domingo, 29 de dezembro de 2013 11:15:23, Jerome Leclanche wrote:
>> I remember TryExec now. TryExec partly fits one of my needs, although
>> there remains the issue of starting without a
y to start an app without arguments, and I
haven't been given a reasonable alternative so I am currently bound to
think it does not exist. I haven't looked too closely at dbus
activation so I can't speak to that yet, please do let me know if I'm
missing something here.
J. Leclanche
ps like that, and apps have been built
> this way for 12 years without major troubles, and DBus activation is right
> around the corner, but maybe it's worth speccing in a "BareExec" key.
>
> Keep in mind, this is very, very different from "get the binary name".
>
On Fri, Dec 27, 2013 at 3:01 PM, Kevin Krammer wrote:
> On Thursday, 2013-12-26, 15:34:03, Jerome Leclanche wrote:
>> I'm sorry, you're right. I should have been clearer.
>>
>> I need this functionality for intents, but I was just trying to
>> display that I&#
On Thu, Dec 26, 2013 at 9:26 PM, Liam R E Quin wrote:
> On Thu, 2013-12-26 at 21:15 +0000, Jerome Leclanche wrote:
>> For the exact same reason menus and any kind of application runners
>> do. That is to say, not that much. It's needed for the rarer case
>> where the app
e to the specs. It does seem to
be that changes only happen once kde/gnome needs them.
J. Leclanche
On Thu, Dec 26, 2013 at 8:59 PM, Jasper St. Pierre
wrote:
> On Thu, Dec 26, 2013 at 3:54 PM, Jerome Leclanche wrote:
>>
>> I never implied the spec was wrong...
>>
>> I
e
On Thu, Dec 26, 2013 at 9:06 PM, Dominique Michel
wrote:
> Le Thu, 26 Dec 2013 20:37:56 +0000,
> Jerome Leclanche a écrit :
>
>> On Thu, Dec 26, 2013 at 8:33 PM, Liam R E Quin
>> wrote:
>> > On Thu, 2013-12-26 at 10:56 +, Jerome Leclanche wrote:
>> >&g
On Thu, Dec 26, 2013 at 8:33 PM, Liam R E Quin wrote:
> On Thu, 2013-12-26 at 10:56 +0000, Jerome Leclanche wrote:
>> I'd really like to be able to get the binary name from desktop files
>
> What if there's no binary, e.g. a shell script or a python-based program
>
You're confused. /usr/bin/env is an executable. It sets the
environment. My whole point is this is *not* a bug and it's possible,
albeit hacky.
J. Leclanche
On Thu, Dec 26, 2013 at 8:34 PM, Dominique Michel
wrote:
> Le Thu, 26 Dec 2013 19:43:36 +0000,
> Jerome Leclanche a écri
I don't see what menu categories have to do with this. Nor how this is
a Wine bug.
J. Leclanche
On Thu, Dec 26, 2013 at 8:00 PM, Dominique Michel
wrote:
> Le Thu, 26 Dec 2013 20:19:08 +0100,
> Dominique Michel a écrit :
>
>> Le Thu, 26 Dec 2013 11:56:57 +,
>>
Again: This desktop file was an example. I didn't write it, wine generates them.
J. Leclanche
On Thu, Dec 26, 2013 at 5:52 PM, Dominique Michel
wrote:
> Le Thu, 26 Dec 2013 10:56:11 +,
> Jerome Leclanche a écrit :
>
>> I'd really like to be able to get the binar
should be dictating).
I guess it is too late to fix it, but my backwards-compatible proposal
would do the job for apps that care about it. If it's missing, we just
assume the app starts the same way with and without args.
J. Leclanche
On Thu, Dec 26, 2013 at 3:10 PM, Kevin Krammer wrote:
On Thu, Dec 26, 2013 at 1:41 PM, Kevin Krammer wrote:
> On Thursday, 2013-12-26, 21:18:43, Ma Xiaojun wrote:
>> On Thu, Dec 26, 2013 at 8:09 PM, Kevin Krammer wrote:
>> > If wine cannot accept the prefix as a command line argument, then this
>> > should use a script that adjusts the environment a
On Thu, Dec 26, 2013 at 1:04 PM, Thiago Macieira wrote:
> On quinta-feira, 26 de dezembro de 2013 12:55:28, Jerome Leclanche wrote:
>> On Thu, Dec 26, 2013 at 12:35 PM, Thiago Macieira wrote:
>> > On quinta-feira, 26 de dezembro de 2013 10:56:11, Jerome Leclanche wrote:
>&g
On Thu, Dec 26, 2013 at 12:35 PM, Thiago Macieira wrote:
> On quinta-feira, 26 de dezembro de 2013 10:56:11, Jerome Leclanche wrote:
>> I'd really like to be able to get the binary name from desktop files
>> (eg a way to "start without any argument").
>
> Wh
My point is, "env" is not what you should get for this. Wine is just
using env as a "hacky" way to give wine the WINEPREFIX variable.
J. Leclanche
On Thu, Dec 26, 2013 at 11:51 AM, Kevin Krammer wrote:
> On Thursday, 2013-12-26, 11:33:13, Jerome Leclanche wrote:
>&g
On Thu, Dec 26, 2013 at 11:25 AM, Kevin Krammer wrote:
> On Thursday, 2013-12-26, 10:56:11, Jerome Leclanche wrote:
>> I'd really like to be able to get the binary name from desktop files
>> (eg a way to "start without any argument"). Current implementations
>&g
I'd really like to be able to get the binary name from desktop files
(eg a way to "start without any argument"). Current implementations
rely on getting the first word of the Exec key OR replace %f etc by
nothing, but that fails for things such as these:
Exec=env WINEPREFIX="/home/adys/.local/shar
Windows uses "start".
I honestly still feel the "open" command should be reserved for this.
Maybe we should make a recommendation to distributions, but leave the
choice up to them at least for the time being.
J. Leclanche
On Tue, Dec 24, 2013 at 2:11 PM, Sanel Zukan wrote:
>> Fail to see the co
See: http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
I think I already know the answer to both but I'd like to double-check.
1) When dealing with desktop files that have %u or %U in the name, if
the argument is a relative file path, the file path should be made
absolute wi
plan to have something
> fleshed out and on github in January or Febuary. Maybe a pretentious
> manifesto document.
>
> Robert Qualls.
>
> On Sat, Dec 21, 2013 at 10:46 PM, Jerome Leclanche wrote:
>> I have to agree. Regardless of the decision on xdg's side, the
&g
I have to agree. Regardless of the decision on xdg's side, the
debian-specific "open" binary shouldn't exist.
J. Leclanche
On Sun, Dec 22, 2013 at 4:43 AM, Ma Xiaojun wrote:
> On Sun, Dec 22, 2013 at 4:23 AM, Matthias Klumpp wrote:
>> Btw, I don't find "I like open better" a good justification
If xdg went ahead with the rename, and if debian included that update,
that would create a conflict on that package. I don't know what they
would do, but since the command is pretty much deprecated, I can
assume they would drop /bin/open from kdb and warn users. The reason
it's still there is they'
On Sat, Dec 21, 2013 at 9:10 AM, David Faure wrote:
> On Tuesday 03 December 2013 09:10:55 Jerome Leclanche wrote:
>> This is no different than using the mime db to only match by name and
>> not content because of performance concerns. As we all know, foo.txt
>> may as well
On Fri, Dec 20, 2013 at 5:07 PM, Ingo Ruhnke wrote:
> On Fri, Dec 20, 2013 at 4:10 PM, Rex Dieter wrote:
>>
>> Why should games be treated differently that other applications? Ie, why
>> not just put stuff under $XDG_DATA_HOME ?
>
>
> While I have seen a few games using $XDG_DATA_HOME for savega
27;s developers using the Windows "games" API. If
Wine decided to integrate with the aforementioned xdg variable, those
issues would go away immediately.
To be clear: Wine apps (almost) never touch anything in $HOME, as it's
only accessible as the Z: drive (unless sandboxed). All of the fil
Thoughts on recognizing and managing $XDG_GAMES_DIR, and possibly
translating it in xdg-user-dirs?
(http://www.freedesktop.org/wiki/Software/xdg-user-dirs/)
It's a bit analogous to windows' "My Games" / "Saved Games" folder.
Wine in fact needs it (currently its always using "/my games"), though i
On Tue, Dec 17, 2013 at 3:58 PM, Diggory Hardy wrote:
> Replying because this is a good question and not fully answered...
>
> The problem is not standards but compatibility, as stated.
>
> What was not mentioned is that Debian switched the default /bin/sh
> implementation from bash to a simpler P
y
>> > > KDE
>> > > developers, so additional to the Qt4 port of that code there is also
>> > > "the
>> > > original" Qt4 code available.
>> > >
>> > > But of course if you need a pure C++ implementation without Qt the
have very old versions of
> modified Red Hat with XDG_DATA_DIRS undefined);
> b) Windows support (through reading registry HKCR/.ext keys) is required;
> c) I'm very curious :)
>
> You think i'm should look deeply at the qmimedatabase.cpp however?
>
>
> 2013/1
Have you had a look at the Qt 5 mimetype module?
http://qt-project.org/doc/qt-5.0/qtcore/qmimedatabase.html
J. Leclanche
On Fri, Dec 13, 2013 at 7:35 PM, Alexander Kamyshnikov
wrote:
> Hi all!
> I'm developing the implementation of MIME database in C++/Qt for one
> commercial program (requireme
On Tue, Dec 3, 2013 at 8:32 AM, David Faure wrote:
> On Monday 02 December 2013 09:40:00 Jerome Leclanche wrote:
>> All the client does is, for http:
>> - Parse the url given to it
>> - Identify whether it's potentially a file through its name (get a
>> fil
On Mon, Dec 2, 2013 at 7:57 AM, Bastien Nocera wrote:
> On Mon, 2013-12-02 at 07:49 +0000, Jerome Leclanche wrote:
>> On Mon, Dec 2, 2013 at 7:13 AM, Bastien Nocera wrote:
>> > On Mon, 2013-12-02 at 00:59 +0100, David Faure wrote:
>> >> (very old mail
On Mon, Dec 2, 2013 at 7:13 AM, Bastien Nocera wrote:
> On Mon, 2013-12-02 at 00:59 +0100, David Faure wrote:
>> (very old mail, but this is bugging me again :)
>>
>> Context: I believe that associating a webbrowser with x-scheme-handler/http
>> is
>> wrong.
>>
>> On Wednesday 06 October 2010 00:
On Sun, Dec 1, 2013 at 11:59 PM, David Faure wrote:
> (very old mail, but this is bugging me again :)
>
> Context: I believe that associating a webbrowser with x-scheme-handler/http is
> wrong.
I'm lost on context here but Id like to share some thoughts on that subject.
>
> On Wednesday 06 Octobe
On Fri, Oct 4, 2013 at 12:26 PM, Simon McVittie
wrote:
> On 04/10/13 12:04, Jerome Leclanche wrote:
>> On Fri, Oct 4, 2013 at 11:53 AM, Simon McVittie
>> wrote:
>>> The search path is longer than that:
>>> ~/.local/share/applications by default, and setting X
On Fri, Oct 4, 2013 at 11:53 AM, Simon McVittie
wrote:
>
> That only works for system-wide installations as root
> (/usr/share/applications and perhaps, depending how the spec is worded,
> /usr/local/share/applications). The search path is longer than that:
> ~/.local/share/applications by default
1 - 100 of 168 matches
Mail list logo
