On Fri, 7 May 2021, at 07:14, Thayne McCombs wrote:
> 1. Where is the DBus interface for launching the terminal defined? It
> isn't in this spec, is it part of a different spec?
I think KDE & Gnome developers are planning to make a spec for that, but there
isn't one yet. There's a lot of discuss
On Thu, 6 May 2021, at 13:25, David Faure wrote:
> OK, I'll use that, I'll just replace "But" with "Remember however that",
> since
> IMHO "But" sounds a bit too much like there's a flaw in the spec, while this
> is perfectly normal and expected.
That makes sense, thanks!
Thomas
__
On Thu, 6 May 2021, at 10:36, David Faure wrote:
> OK, I added "In any case it should be consistent across runs rather than
> random (e.g. based on the order of an unsorted list of files from a
> directory)".
Sounds good, thanks!
> > I'm not sure about the last sentence you've now added:
> >
>
Hi David,
On Thu, 6 May 2021, at 09:35, David Faure wrote:
> > Of course, a launcher may
> > have a hardcoded default for specific interfaces it recognises - e.g. KDE
> > might pick Konsole for org.freedesktop.Terminal1 - but it should be
> > prepared to handle interfaces it doesn't know.
>
> Not
On Mon, 3 May 2021, at 20:36, Eli Schwartz wrote:
> Once all levels have been checked, if no entry could be found, the
> implementations MUST query the user to pick one of the .desktop files
> associated with the mimetype, taking into account added and removed
> associations as per the next section
On Mon, 3 May 2021, at 10:58, David Faure wrote:
> I'd like to understand why
> https://specifications.freedesktop.org/mime-apps-spec/latest/
> doesn't solve the issue. If the distro's mimeapps.lst says
> image/jpeg=gwenview.desktop;gimp.desktop;
> then JPEG files will be opened in gwenview (if in
There was a discussion recently about how a default application for a mime-type
was chosen when no mimeapps.lst specified a preference - some launchers were
giving semi-random results that changed unexpectedly.
As you said, the new spec closely follows mime-apps. I think it would be a good
idea
On Mon, 22 Feb 2021, at 13:21, Mark Watts wrote:
> If I
> understand correctly, based on the excerpt of the desktop entry spec
> below, there's no prohibition on adding entries outside of those
> explicitly listed in the standard, so we're good there.
The spec says that additional non-standard fie
On Wed, 17 Feb 2021, at 22:46, Bastien Nocera wrote:
> I split it off anyway so that I could stop maintaining the shared-mime-
> info package and not have anyone who might come in's decisions about
> what the best default image viewer is impact GNOME. Here's the GNOME
> configuration:
> https://src
On Wed, 17 Feb 2021, at 18:22, Jehan Pagès wrote:
> I do agree it's not so much to start with. Anyway here is the recent report:
> https://gitlab.gnome.org/GNOME/gimp/-/issues/6449
Thanks!
This particular user reports that *updating* GIMP causes the file association
to change. That definitely
On Wed, 17 Feb 2021, at 16:42, Jehan Pagès wrote:
> Yes! Finally someone who reads emails before answering. :-)
I'll just note that this isn't a particularly useful tone in a discussion that
already feels heated. I actually haven't read your emails particularly closely,
I just think I've happene
On Wed, 17 Feb 2021, at 15:06, Bollinger, John C wrote:
> Ok, on re-reading I can see that, but it is even less the GIMP's role to say
> "you should prefer other applications for opening JPEGs" than it is to say
> "you should prefer me for opening XCFs". Desktop files still are not the
> right
On Tue, 16 Feb 2021, at 23:04, Bollinger, John C wrote:
> But that does not imply that some applications should be able to claim to be
> more equal than others with respect to particular file types.
I think Jehan's idea is that applications should be able to claim to be *less*
equal than others
It's not clear to me that using file descriptors fulfils the same goal as the
encryption mechanism. The secret service spec [1] suggests that the goal is for
swappable memory to contain encrypted (rather than plaintext) secrets. Passing
the secret over a separate channel wouldn't seem to do that
On Fri, Mar 6, 2020, at 11:26 AM, Johannes Thrän wrote:
> I'd like the middle mouse click to also be able to do that, i.e:
>
> 1. select text (not drag)
>
> 2. in another window select some other text, hold click
>
> 2a, middle mouse click.
>
> ... release.
I think that's what I was trying to
On Fri, Mar 6, 2020, at 1:43 AM, Thiago Macieira wrote:
> You mean middle click while the left button is still held down? That
> effectively means dragging the text from source to destination.
If I've understood Johannes correctly, what he's proposing is slightly
different from drag & drop:
1.
On Wed, Feb 26, 2020, at 1:30 PM, Benjamin Berg wrote:
> I am *not* proposing to nuke these directories. I am proposing to nuke
> them by default, and ask applications like evolution, jhbuild and
> others to ship their own configuration.
I suspect that the practical upshot of this would be that ~a
I'd agree with Will: keep things simple unless there's real pressure from
people who want to use localised icons, not just hypothetical cases.
Best wishes,
Thomas
On Tue, Jun 25, 2019, at 3:23 PM, Bollinger, John C wrote:
> Hi,
>
> The problem seems to be that Icon is unique among the curren
On Fri, Jun 7, 2019, at 8:48 PM, Jonas DOREL wrote:
> To me, secrets are fundamentally different from data (even confidential
> data) because they serve as a mean to authenticate you or authorize your
> utilisation of some services.
>
> I guess the question is: should there be a dedicated folder f
Hi Simon,
On Thu, Feb 28, 2019, at 12:08 AM, Simon Lees wrote:
> Where ever possible i'm currently planning to use as much of the
> existing pyxdg libraries especially for handling all the mime / .desktop
> file handling.
As the not very active maintainer of PyXDG: much of the package is writte
Hi Egmont,
I don't think it's important to use licensing to prevent incompatible
versions of the specification. Compatibility is important, but it's
ensured by having a single place which everyone agrees is the canonical
version of the specification. Many specifications are also usefully
amended a
Hi Jérôme,
On Wed, Jun 27, 2018, at 10:11 PM, Jérôme Bardot wrote:
> Like it’s done with ~/.config why not do the same for
>
> ~/.contacts/*.vcf
> ~/.calendars/*ics
> ~/.password-store
> ~/.email
> ~/.rss
> ~/.bookmark
> ~/.torrent
> ~/.xmpp-message (maybe should it be merge with email)
I think
Me again :-)
XDG_RUNTIME_DIR has a number of useful guarantees, and I want to use it, but
I'm finding it tricky to do so in a reliable way.
I've complained before about the fact that processes running in screen/nohup
can have the directory deleted from underneath them when the user disconnects.
On Sat, Jun 9, 2018, at 8:01 PM, kendell clark wrote:
> OK, I feel stupid. Apparently linux doesn't identify everything with a
> .bin extension as sega disk image, it also detects sega saturn rom
> images. However, it does still identify everything else with a .bin
> extension as sega cd disk image
Thanks Simon; I've added some notes on the wiki pages of the relevant specs.
Does anyone know about their adoption in other desktops?
Thomas
On Thu, May 31, 2018, at 2:31 PM, Simon Lees wrote:
> Here is the status from Enlightenment as far as i'm aware
>
> On 31/05/18 05
I'm working on updating the list of specifications here:
https://wiki.freedesktop.org/www/Specifications/
I think several of the specs listed as "not yet widely used" are now well
accepted, and could be upgraded to "pretty good adoption". In particular, these
specs describe files which are on my
Is there something else we can do to ask the system to keep XDG_RUNTIME_DIR
around? Or should any application which might be run in nohup/screen just not
rely on XDG_RUNTIME_DIR?
Thomas
On Thu, May 10, 2018, at 4:08 PM, Lennart Poettering wrote:
> On Do, 10.05.18 15:27, Thomas Kluyver (
:38, Thomas Kluyver (tho...@kluyver.me.uk) wrote:
>
> > The basedir spec says of XDG_RUNTIME_DIR:
> >
> > > ...if the user fully logs out the directory MUST be removed.
> >
> > What counts as logging out? For some application code, I assumed that if
> > the
The basedir spec says of XDG_RUNTIME_DIR:
> ...if the user fully logs out the directory MUST be removed.
What counts as logging out? For some application code, I assumed that if the
application was running as user X, that meant user X was still logged in, and
the application could rely on XDG_R
other contributions he has made
to the wiki. While we didn't yet agree that that's the licensing we want to aim
to use sitewide, they're both very permissive licenses, so it's a good starting
point.
Thomas
- Original message -
From: Thomas Kluyver
To: Federico Mena Quinter
On Sun, May 6, 2018, at 3:36 PM, Daniel Stone wrote:
> OK, done now.
Thanks! By digging into that, I confirmed that Federico is the sole author of
the file manager interface spec that kicked off this discussion. A couple of
people, myself included, have adjusted formatting since the transition t
And I apologise for sniping. It doesn't excuse my words, but I'm frustrated
because discussions about the wiki seem to get radio silence until I irritated
people.
On Sun, May 6, 2018, at 2:56 PM, Thomas Kluyver wrote:
>
>
> On Sun, May 6, 2018, at 1:56 PM, Daniel Stone
On Sun, May 6, 2018, at 1:56 PM, Daniel Stone wrote:
> The wiki doesn't run on MoinMoin anymore. All the wiki content is
I'm trying to get the history - a lot of the wiki pages in the current system
were converted from moin, so that old data is needed to try to work out who
wrote them. Sorry f
On Sun, May 6, 2018, at 10:49 AM, Simon Lees wrote:
> The only way that I think we can realistically make the wiki situation
> better is by changing it now to say new changes are under the following
> license, then in 10 years hope that enough of the content has been
> changed that someone can dele
On Sun, May 6, 2018, at 8:40 AM, Simon Lees wrote:
> Anyone
> who goes to the effort of editing a wiki knows and acknowledges that the
> content they have produced will be displayed on the wiki in its current
> form and are therefore giving permission for the content they have
> created to be redis
Very Seriously, you
> were just picking an argument with me for trying to suggest a solution.
>
> Thomas
>
> On Sat, May 5, 2018, at 3:29 PM, Thomas U. Grüttmüller wrote:
> > On 13.04.2018 13:11, Thomas Kluyver wrote:
> > > On Fri, Apr 13, 2018, at 11:48 AM, Bastien Noc
5, 2018, at 3:29 PM, Thomas U. Grüttmüller wrote:
> On 13.04.2018 13:11, Thomas Kluyver wrote:
> > On Fri, Apr 13, 2018, at 11:48 AM, Bastien Nocera wrote:>
> >> This isn't how copyright works, sorry.
> >
> > Thanks, I was aware of this. No, it doesn't str
I came across this page, linked from the homepage:
https://www.freedesktop.org/wiki/Specifications/
There seem to be a number of discrepancies, if my understanding of various
standards is correct:
- The desktop notifications spec isn't mentioned at all. Gnome hosts a copy of
it (https://develo
On Fri, Apr 13, 2018, at 11:48 AM, Bastien Nocera wrote:>
> This isn't how copyright works, sorry.
Thanks, I was aware of this. No, it doesn't strictly adhere to 'how copyright
works', but realistically, people who contribute to a freely available wiki
about open source software are not going t
On Fri, Apr 13, 2018, at 10:11 AM, Daniel Stone wrote:
> Sorry for the lack of reply, I've been quite busy lately. I also don't
> have a great answer for you. We cannot post-hoc enforce a licence on
> content: anything that is there is copyright to the actual author. We
> can enforce a licence on n
On Fri, Apr 13, 2018, at 2:03 AM, Boyuan Yang wrote:
> Several weeks have passed and seems that there's no progress here; the mail
> copy sent to original discussion participants got no replies and one of the
> email address also bounces.
I get the impression that no-one really feels ownership o
+1 to having a default license for the wiki contents.
Code samples in a wiki are often meant to be copied and pasted, so it seems
appropriate to license them permissively, like an MIT license, or even public
domain. I don't feel strongly about the non-code content, but CC-BY would be an
easy de
On Sun, Mar 26, 2017, at 07:18 PM, Roman Hargrave wrote:
> even though dbus and friends are omnipresent (I even
> found
> it on an old embedded ebook reader, in some form).
Was that a Kobo device, by any chance? I've got one of those to
experiment with, and also noticed that it starts dbus.
__
On Thu, Mar 23, 2017, at 10:30 PM, Roman Hargrave wrote:
> Now, if there were a toolkit-agnostic set of interfaces for applications
> to call in to in order to prompt the user with the native file picker
> instead of that which the toolkits use would have the advantage of insuring
> that any settin
On Mon, Jan 9, 2017, at 11:35 AM, Lennart Poettering wrote:
> That said, people do weird stuff with su/sudo. It might or might not
> make sense for apps to superficially check ownership of the dir before
> using it. However I am very sure apps should never try to "fix" it it
> doesn't match their e
Hi Kendell,
On Thu, Mar 17, 2016, at 12:26 PM, kendell clark wrote:
> I'm completely new to all of this, so how would this be
> done? Hex editor?
The XDG Mime data is written in an XML format in the shared-mime-info
repository:
https://cgit.freedesktop.org/xdg/shared-mime-info/
That is then used
On Thu, Mar 17, 2016, at 01:29 PM, kendell clark wrote:
> Thanks for your help. How would I go about getting a unique string of
> data, integer, text string, whatever to add to the mime type to make it
> unique? Most of the mime types I want to add are binary so can't be
> opened in a traditional t
Hi Matthias,
Thanks for your thoughtful reply.
On Sat, Nov 21, 2015, at 09:02 PM, Matthias Klumpp wrote:
> I suppose you have looked at existing solutions to the problem, like
> 0install, Limba and XdgApp. What is the thing which makes your project
> special compared to those (there must be some
On Sat, Nov 21, 2015, at 03:58 PM, Shaun McCance wrote:
> I think you're confusing understanding how a system works underneath
> with understanding how to use it. GitHub is a testament to the massive
> number of people who use git. A very small handful of those people
> really truly grok how git wo
On Fri, Nov 20, 2015, at 09:01 PM, Jasper St. Pierre wrote:
> Currently, the security model of Linux systems is "distro verifies
> security and adds to their own repo", with, of course, the step of
> "user trusts distro".
>
> The security model of Batis seems to be "user trusts application
> devel
On Fri, Nov 20, 2015, at 08:09 PM, Jasper St. Pierre wrote:
> I'm worried. We have xdg-app, we have batis, and I learned that the
> KDE people are working on their own thing as well.
I haven't heard about the KDE project in this space - is there any
website for that?
I have looked at xdg-app befo
Nearly a year ago, I posted to this list about the need for a better way
to distribute and install desktop applications [1]. There was some
interesting discussion, and people pointed out some existing
alternatives. But I remained convinced that something else was needed.
I've been thinking about t
Thanks Alex,
On Wed, Jun 24, 2015, at 12:20 PM, Alexander Larsson wrote:
> A runtime is very specific. It defines an exact ABI and is then
> supposed to continue to support exactly that ABI. If anything that you
> need is not shipped in the runtime you chose to use, you need to bundle
> those with
Hi Jasper,
On Wed, Jun 24, 2015, at 10:23 AM, Jasper St. Pierre wrote:
> Both of these are really cool and convenient for system updates.
> xdg-app is simply using OSTree for its first bit, the repo bit.
> xdg-app has its own deploy stage.
So it sounds like an application publisher would use OSTr
Hi Alex,
On Wed, Jun 24, 2015, at 01:15 AM, Alexander Larsson wrote:
> More details on how xdg-app works can be found here:
> https://wiki.gnome.org/Projects/SandboxedApps
Thanks, this looks interesting. A couple of questions:
How specific is a 'runtime'? If I've written an application based on
I looked into this before, and came to the conclusion that there is no
fallback directory that meets the guarantees $XDG_RUNTIME_DIR provides. If
you want your application to run on older systems that don't provide
$XDG_RUNTIME_DIR, you'll need to think about what properties are important
for your
On 16 February 2015 at 10:18, Bastien Nocera wrote:
> About the? It's also very low for a number of people. I can also be
> there to notify about the number of new podcasts episodes to read, the
> number of unread articles in my offline reader app, the number of unread
> messages in my chat appli
On 6 January 2015 at 16:58, Rex Dieter wrote:
>
> > categories of programs
>
> ^^ that. :)
To expand a bit: such categories do not really exist for mimetypes (someone
correct me if I'm wrong). You may be able to make use of:
- The media types, the part of the mimetype before the slash, e.g. 'i
On 16 December 2014 at 13:06, Matthias Klumpp wrote:
> so you would force the app
> author to write a huge metadata file
>
As I see it, many app authors are already figuring out the necessary
metadata for different distros, whether they scatter it around in packaging
files for different systems,
On 16 December 2014 at 12:52, Alexander Larsson wrote:
> Well, there are two parts. One is the actual "runtime" that makes the
> whole thing tick. This part is desktop independent.
>
> The second part is to have an actual base runtime with dependencies that
> you can use to write an application.
On 16 December 2014 at 02:40, Alexander Larsson wrote:
> I agree, and I'm currently working on one (as are others obviously as
> seen in this thread) within Gnome (although the base code is desktop
> independent)
>
Thanks - I think the more people there are trying to address this, the more
likel
Hi Matthias,
On 8 December 2014 at 19:01, Matthias Klumpp wrote:
> his means without installation those tarballs are of no value to the
> user, OR they contain a lot of bundled dependencies, which defeats
> your point of pulling stuff from the distribution repositories.
>
My intention is that w
On 8 December 2014 at 18:09, Mattias Andrée wrote:
> The goal was to make it as simple as possible, but
> perhaps there is a simpler way than UUID:s.
>
My idea is that the new system leaves all the dependency management to
distros: an end user application can depend on distro packages, but can't
Thanks Matthias & Mattias for your comments,
I will certainly look into Limba some more - I don't want to proliferate
too many solutions if other people are working on this. From reading your
blog post, my initial concern is that having a duplicate dependency system
is too complex. My idea is that
This may be a pipe dream, but XDG is the best place I know to propose
something like this:
We need a new mechanism for distributing end-user applications on free
desktop platforms.
Traditionally, distro packaging is considered the right way to distribute
applications. However, I believe that dist
On 26 December 2013 20:33, Liam R E Quin wrote:
> On Thu, 2013-12-26 at 10:56 +, 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
> with a UI?
I think this is a key i
On 24 December 2013 16:37, Kevin Krammer wrote:
> Well, a quick check would have revealed that it is.
> Cross platform development always requires testing on the targetted
> platforms,
> one can not simply assume things.
>
But I don't go and check that simple commands like cp or grep will work o
On 24 December 2013 15:06, Kevin Krammer wrote:
> > BTW, I happen to know one breakage caused by Linux not having open(1)
> like
> > OS X. https://github.com/swaroopch/byte_of_python/issues/8
>
> Looks like the implementors either had not thought about cross platform
> integration or had no infor
On 21 December 2013 08:37, Ma Xiaojun wrote:
> The good news is now that, console-tools, the package provides open(1)
> in Debian, is being removed recently, if I understand correctly:
> http://packages.qa.debian.org/c/console-tools.html
>
I think it's still provided in the kbd package:
http://p
On 18 March 2013 07:47, Thomas Kluyver wrote:
>
> I've also realised I copied the wrong URL for the bug. The correct one is:
> https://bugs.freedesktop.org/show_bug.cgi?id=62473
>
Any more thoughts about this (the case of MEDIA/SUBTYPE.xml filename)? I
had a go at a simple p
On 2 May 2013 21:03, Felix Natter wrote:
> The only problem with this (and probably the reason why the previous
> packager used the full path to freeplane.svg) is that konqueror displays
> a (small) bitmap instead of the svg which is pixelated.
>
I think the idea is that it's up to the file mana
On 1 May 2013 18:22, Felix Natter wrote:
> and put freeplane.png here:
> /usr/share/icons/hicolor/32x32/mimetypes/freeplane.png
> (I also tried to put the svg in hicolor/scalable/mimetypes/)
>
> => probably a (local?) problem with my nautilus? It seems to work in
> konqueror (and on another compu
On 1 May 2013 12:41, Felix Natter wrote:
> />
>
The spec isn't entirely clear on what the name attribute should be, but in
the one example I've got on my system, it's a simple filename, not a full
path:
> I also tried , and
> (by changing
> /usr/share/mime/packages/freeplane.xml a
On 25 April 2013 20:45, Alice Wonder wrote:
> e.g. a page called Udev that maybe has a very brief description and then
> hyperlinks to the actual documentation. That would also work.
>
That would fix this specific case, but what if you want to search for
something like a specific function from u
I think the issue is that the search box on the freedesktop.org home page
is part of the Moin wiki, so it only searches documents that are part of
that. Things like the udev reference manual (
http://www.freedesktop.org/software/systemd/libudev/ ) are generated
separately, but hosted on the same do
13:57:04 Thomas Kluyver wrote:
> > On 19 March 2013 13:28, David Faure wrote:
> > > The other would be to write code that detects the cases where the
> database
> > > has
> > > values such that (value & mask) != value, and fixing the database to
> > >
On 17 April 2013 15:24, Jan Kundrát wrote:
> This is not meant to say that your proposal is wrong -- it might actually
> be the best option which is available *right now*. It's just that I would
> like to have a solution which somehow elliminates all of the problems I
> described. If only the "D-
On 3 April 2013 15:42, Rémi Denis-Courmont wrote:
> You definitely should not save it in /tmp as it might be mounted as
> tmpfs.
>
I'm curious as to why this is such a bad idea - I'm used to browsers and
e-mail clients putting things in /tmp if I select 'Open' rather than
'Save'. For instance, I
On 25 March 2013 10:54, jupiter wrote:
> Thanks for the suggestion, the only problem I can think of is that we
> cannot use environmental variables such as $HOME or $XDG_DATA_HOME or
> $XDG_CONFIG_HOME in the Desktop Entry. How can I specify Exec or Path
> for each user? Is the hard coded path th
On 21 March 2013 15:13, Thiago Macieira wrote:
> The specification has no access control for users or groups. If you want
> settings to apply to specific users or specific groups, make them see
> those files
> and make other users not see those files.
You may also want to have a look at the me
On 19 March 2013 13:28, David Faure wrote:
> The other would be to write code that detects the cases where the database
> has
> values such that (value & mask) != value, and fixing the database to
> specify
> (value & mask) as value from now on. This would allow implementations to
> avoid
> havi
On 18 March 2013 14:32, Bastien Nocera wrote:
> shared-mime-info -> specification (or whatever) component
>
Rats, sorry. I was looking under the 'Specifications' product.
I've also realised I copied the wrong URL for the bug. The correct one is:
https://bugs.freedesktop.org/show_bug.cgi?id=6247
eclanche wrote:
> Agreed. If the files are not lowercase, we could have conflicts (which we
> actually do as you mentioned).
>
>
> J. Leclanche
>
>
> On Fri, Mar 15, 2013 at 10:11 PM, Thomas Kluyver wrote:
>
>> Almost all Mime types are named in lower case, e.g. image/p
Almost all Mime types are named in lower case, e.g. image/png. However,
there are a handful of MS office file formats that the
freedesktop.orgdatabase uses the word 'macroEnabled', e.g.
application/vnd.ms-excel.sheet.macroEnabled.12
The same type is also defined by LibreOffice, but in lowercase,
The spec [1] says that the mask is applied to the value from the file
before comparing it with the value from the magic database.
However, looking for examples, I find image/vnd.adobe.photoshop [2], where
bytes 5-6 of the mask are \x00\x00, while bytes 5-6 of the value are
\x20\x20 (two spaces). B
On 5 March 2013 12:41, Jerome Leclanche wrote:
> - PNG is a massively popular file format, who the hell thought this was a
> good idea?
Seconded ;-)
Bastien:
> Your implementation returns results differently from the one we use in
> shared-mime-info itself.
Looking at the implementation in P
On 5 March 2013 11:58, Jerome Leclanche wrote:
> Are they valid PNGs? If so, it sounds like the mime type should just be a
> child of image/png and drop the glob here.
It's not clear, and I don't have one to examine. I would guess that they're
not valid:
- The commit message where the mimetype
I've just had a bug reported against PyXDG that a Mimetype test is
returning image/x-apple-ios-png instead of image/png.
Looking at the XML mime type definitions [0], this new mime type ('Apple
broken PNGs') has the same glob as regular pngs: *.png. They can be
distinguished by magic sniffing, but
On 19 February 2013 13:45, Sanel Zukan wrote:
> Vincent asked me to ping the list first; anyone have objection for
> adding EDE desktop (http://edeproject.org) as registered environment
> for OnlyShowIn variable inside menu specification?
>
I wonder if the spec should make this list descriptive,
On 18 January 2013 23:51, westlake wrote:
> So if I had these problematic filetypes (.msi/.msu) in ~ , I get no
> long-long long delay..
>
> ^ I tested it.. thumbnails off. A long list of files.. I then add just
> "one" problematic .msi file and it nearly stalls the listing completely (2+
> minu
On 17 January 2013 20:37, westlake wrote:
> It is because of values that there's a 2+ minute delay when
> listing filetypes(Nautilus/Dolphin, but not cli tools like mc and lynx) on
> an ssl+webdav mountpoint
I'm guessing that the delay occurs because the file manager is attempting
to open ea
On 15 January 2013 18:56, westlake wrote:
> Hi guys, I'm new to this list.. I would like to post an issue about a very
> serious problem I'm having it concerns
>
> It's about file /usr/share/mime/packages/**freedesktop.org.xml,
>
It could be - why don't you describe the problem in more detail. I
On 6 December 2012 00:21, Thomas Kluyver wrote:
> I still think the basic way to get the runtime directory should raise an
> error if the environment variable isn't set - after all, PyXDG is an
> implementation of the spec. I might offer a wrapper function with a
> strict=Tru
On 5 December 2012 22:57, David Faure wrote:
> Using /tmp for user-specific session sockets is what we've been doing for
> decades, I don't think we should break apps just because the user's OS
> doesn't
> have yet the fancy new /run/user directory.
>
PyXDG doesn't currently have any reference t
On 5 December 2012 22:14, David Faure wrote:
> OK, so /run/user/ is a better default, when available, than /tmp, I'll
> adjust
> my code. Thanks for pointing this out, it looks like I didn't take this
> into
> account.
>
/run/user was created for this use, though, so systems that don't have
$XDG
On 5 December 2012 15:21, David Faure wrote:
> Not very convenient, to expect apps to implement themselves a fallback.
>
> In Qt, I implemented this:
>
> if XDG_RUNTIME_DIR isn't set, mkdir /tmp/runtime-$USER,
> then ensure that it's owned by the user (otherwise bail out),
> then chmod to 0700 (a
On 4 December 2012 15:35, Thomas Koch wrote:
> Some applications store "volatile" config data or "convenience data" like:
>
> - last window position
> - recently opened file
> - last time application was run
> - ... you name it
>
> Most annoyingly these applications create config files on first r
On 4 December 2012 00:41, Jerome Leclanche wrote:
> My tests are here:
> https://github.com/Adys/python-xdg/blob/master/tests/mime.py
>
> I strongly recommend you test for foo.c, foo.C, aliases, non-existant mime
> types, and mimetype parenting (text/x-python <- text/plain)
>
Thanks Jerome,
I'v
On 3 December 2012 22:31, Jerome Leclanche wrote:
> No worries Thomas. I'll keep python-xdg as a separate project, it's not
> bad to have an alternative. I mostly enjoy the mimetype api, for which I
> have pretty extensive tests. Feel free to look around.
Great. I haven't looked in great detail
On 3 December 2012 21:08, Jerome Leclanche wrote:
> However I'd be more inclined to figure out if the *spec* not providing a
> fallback is a good idea. What's wrong with assuming .local/run or something?
I think there are some security issues, although I'm not quite clear about
the details. The
1 - 100 of 121 matches
Mail list logo
