On 05/07/2010 10:53 AM, Lennart Poettering wrote:
> If this is added to the .desktop files too, then I'd however suggest to
> follow the oom_adj semantics closely, and make the field a nice-like
> value instead of a boolean. And it might be an idea to prefix this with
> X- or so, because then it be
On 10/28/2009 05:16 AM, Fabien Meghazi wrote:
> Hi all,
>
> It seems that at least one atom should be added to the list of _NET_WM_STATE
>
> Namely : _NET_WM_STATE_MINIMIZED
>
> See https://bugs.launchpad.net/ubuntu/+source/wmctrl/+bug/260875
>
> I guess a _NET_WM_STATE_ICONIFIED would be welc
On 08/27/2009 06:12 AM, André Gillibert wrote:
> "Brian J. Tarricone" wrote:
>
>> If Foo-app looks for its plugins in $XDG_PLUGIN_DIRS/foo-app, and
>> Bar-app looks for its plugins in $XDG_PLUGIN_DIRS/bar-app, then there
>> can never be any conflict, even if
On 08/27/2009 02:19 AM, André Gillibert wrote:
> "Brian J. Tarricone" wrote:
>
>> LD_LIBRARY_PATH isn't so useful since it rarely contains the entire
>> library search path, and is often empty. On my system, /etc/ld.so.conf
>> contains 10 paths in i
On 08/26/2009 05:30 PM, Stephen Paul Weber wrote:
though I guess
>> it's already incompatible since Mac app bundles use the .icns format,
>> which I doubt gtk or qt support natively.
>
> MacOS actually supports formats besides icns for the app icon.
Ah, nice, didn't know that. Do they support S
On 08/26/2009 03:25 PM, Stephen Paul Weber wrote:
> In some contexts, app bundles (where all files for an application live in
> some folder, like on MacOS) are useful. I've been thinking recently about
> an app bundle layout that is based on freedesktop specs and also not
> gratutitously different
On 08/23/2009 12:54 PM, Aleksey Shaferov wrote:
> I propose to add a new key to .desktop-files.
> Please add WM_CLASS key!
You mean like StartupWMClass? See
http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s05.html
Unfortunately most apps don't fill this in since it's usually not
On 08/09/2009 11:46 AM, Francois Gouget wrote:
> William Jon McCann a écrit :
> [...]
>> Also, if we were to use parenthesis in English (and I don't think we
>> should) we would want it to read "Ephiphany (Web Browser)".
>
> So, stepping back just a bit, wouldn't it be pretty ugly if the Start
>
On 08/05/2009 03:25 PM, David Faure wrote:
> On Sunday 12 July 2009, Brian J. Tarricone wrote:
>> On 2009/05/11 06:00, Travis Watkins wrote:
>>> On Mon, May 11, 2009 at 5:50 AM, David Faure wrote:
>>>> On Monday 04 May 2009, Travis Watkins wrote:
>>>>>
On 07/21/2009 08:20 AM, Frederic Peters wrote:
[...]
> It would already be possible if Name and GenericName were used in a
> consistent way, but as we put whatever we wanted to be displayed in
> the menu in Name, we find ourselves with the Name embedding the
> GenericName, such as:
>Name=Brase
On 07/17/2009 05:14 AM, Oswald Buddenhagen wrote:
> hi,
>
> On Fri, Jul 17, 2009 at 01:20:15AM -0700, Brian J. Tarricone wrote:
>> Is there a recommended best practice for how the power manager and
>> session manager should interact during session end? Are there ot
Hi all,
Not sure if this is the best place for a discussion about this, but it
relates to cross-desktop standards, so... here goes.
Currently xfce4-session is capable of (upon request) shutting down,
rebooting, suspending, and hibernating the system (the first two through
HAL or a sudo-based h
On 07/15/2009 04:52 AM, stefan.k...@nokia.com wrote:
>
> I like
> "XDG_LIB_HOME will default to $HOME/.local/lib/$ARCH_OS_ABI_STRING/
> more as this allows the distro/admin to set it up and developers can just put
> a binary there.
>
> If we go for XDG_LIBROOT_HOME, we'll have to define $ARCH_OS_A
On 2009/05/11 06:00, Travis Watkins wrote:
> On Mon, May 11, 2009 at 5:50 AM, David Faure wrote:
>> On Monday 04 May 2009, Travis Watkins wrote:
>>> Personally I'd rather go with the change to the meaning of
>>> Hidden as it makes the most sense to me (Hidden means it is hidden in the
>>> menu)
>
On 2009/07/10 00:42, Cornelius Schumacher wrote:
> On Friday 10 July 2009 01:38:45 Jannis Pohlmann wrote:
>> Release teams ... I still don't agree with that ;)
>
> The rationale for having the release teams as the point of contact is that
> they already decide about dependencies of their software,
On 2009/07/10 03:29, Daniel Stone wrote:
> On Fri, Jul 10, 2009 at 01:13:59AM +0200, Jannis Pohlmann wrote:
>> Hopefully, the degree of participation in fd.o discussions will
>> increase (I think it already has improved a lot over the past weeks),
>> but I fear that with only two projects having th
On 2009/07/08 17:20, Daniel Bo wrote:
>
> Making KDE and Gnome the gatekeepers for specs will bring the same
> problems to the table that having the Security Council in the U.N.
> does. Giving voting rights to only two projects (and codifying that)
> seems like a death sentence to FD.o. It immediat
On 2009/06/30 14:11, Thiago Macieira wrote:
> Simon McVittie wrote:
>> On Tue, 30 Jun 2009 at 04:08:26 -0300, Thiago Macieira wrote:
>>> We'll need an architecture key, which is composed by the host OS plus
>>> at least the processor main type.
>> Multiarch http://lackof.org/taggart/hacking/multiar
On 2009/06/30 14:22, Thiago Macieira wrote:
> Brian J. Tarricone wrote:
>> On 2009/06/30 00:08, Thiago Macieira wrote:
>>> What's more, to be suitable for C++, we may need to encode the C++ ABI
>>> for architectures where more than one C++ compiler are commo
On 2009/06/30 00:08, Thiago Macieira wrote:
> What's more, to be suitable for C++, we may need to encode the C++ ABI for
> architectures where more than one C++ compiler are common (which is just
> about every platform except the free ones). But we can have that as a
> subtype.
Is this necessary?
On 2009/06/26 18:05, Aaron J. Seigo wrote:
> On Friday 26 June 2009, Brian J. Tarricone wrote:
>> I'm honestly not trying to be inflammatory here; I'm just trying to
>> understand *specifically* what it is that you can't do with the existing
>
> in a nutshell:
On 2009/06/26 07:19, Olivier Goffart wrote:
> Le Thursday 25 June 2009, Brian J. Tarricone a écrit :
>> On 06/25/2009 06:35 AM, Lubos Lunak wrote:
>>>I do. I see it as wrong that I would not be able to tell the KDE
>>> implementation that I'm not interested
On 06/25/2009 01:49 PM, Brian J. Tarricone wrote:
> But I don't really know how to fix that. You mentioned elsewhere about
> being able to track and record consensus -- I think that's important.
> What tools exist to do that? Is it necessary that it be a very formal
> p
On 06/25/2009 02:18 PM, Jeff Mitchell wrote:
> Well, from various existing software examples:
>
> Visual
Obviously the current spec handles this. Canonical's extensions to
display things like volume levels is useful, but still works within the
confines of the current spec, with extensions.
> A
On 06/25/2009 12:52 PM, Aaron J. Seigo wrote:
> c) this particular request actually has a very real purpose behind it: it's
> confusing naming, and some of us would like to see a full notifications
> specification landed at some point that includes not just visual notifications
Could you explain
On 06/25/2009 01:53 PM, Aaron J. Seigo wrote:
> fd.o has control put into place in all the wrong places.
>
> people should be free and encouraged to host drafts and experimental work
> somewhere we can all get to them.
>
> it should be an additional set of steps to go from that to being an agreed
On 06/25/2009 01:27 PM, Aaron J. Seigo wrote:
> On Thursday 25 June 2009, Brian J. Tarricone wrote:
>> Thank you -- that's exactly how I feel like this conversation is going.
>>As a notifications daemon implementer, I *really* don't appreciate
>> being told &quo
On 06/25/2009 12:46 PM, Jeff Mitchell wrote:
> Brian J. Tarricone wrote:
>>>"Breaking five years' worth of software" is not really an honest
>>> statement either, unless you're talking about five years of unmaintained
>>> software (consideri
On 06/25/2009 12:11 PM, Jeff Mitchell wrote:
> Brian J. Tarricone wrote:
>>> The question is what's more important to you: is it backwards compatibility,
>>> or is it equal treatment for all parties with all the community
>>> implications?
>> Backwards-co
On 06/25/2009 12:00 PM, Jeff Mitchell wrote:
> Brian J. Tarricone wrote:
>> Thank you -- that's exactly how I feel like this conversation is going.
>>As a notifications daemon implementer, I *really* don't appreciate
>> being told "hey, just becau
On 06/25/2009 06:35 AM, Lubos Lunak wrote:
> I do. I see it as wrong that I would not be able to tell the KDE
> implementation that I'm not interested in any bubbles from FooApp that
> happens to annoy me with them all the time.
Why can't you do this today? The org.freedesktop.Notifications.No
On 06/25/2009 05:08 AM, Jakob Petsovits wrote:
> I don't see a push for "punishment", rather the push for not using the
> org.freedesktop namespace for stuff where no consensus has been reached.
Sorry, but any time someone makes more work for me for no good
*practical* reason, it sure feels like
On 06/25/2009 03:22 AM, Patryk Zawadzki wrote:
> On Wed, Jun 24, 2009 at 10:23 PM, Aaron J. Seigo wrote:
>> On Wednesday 24 June 2009, you wrote:
>>> What's wrong with keeping the current fd.o prefix if implementations
>>> are compatile?
>> what "wrong" is that fd.o is a shared namespace. you can
On 06/25/2009 08:33 AM, Aurélien Gâteau wrote:
> Lubos Lunak wrote:
>
>> To save us from more work, of course. If this was done properly in the
>> first
>> place, we wouldn't need this discussion now. If you want to know some of the
>> reasons in more detail, please just see this thread.
>
> Don
William Jon McCann wrote:
> Hey,
>
> On Mon, Jun 15, 2009 at 1:45 PM, Brian J. Tarricone wrote:
>> On 06/15/2009 08:10 AM, William Jon McCann wrote:
>>
>>> Do you have a specific response to the problems that they describe at
>>> the
On 06/15/2009 08:10 AM, William Jon McCann wrote:
> Do you have a specific response to the problems that they describe at
> the following?
> https://wiki.ubuntu.com/NotificationDevelopmentGuidelines#Avoiding%20actions
>
> I'd be very interested to see it. I think that rationale is fairly
> compel
On 06/13/2009 05:12 PM, Aaron J. Seigo wrote:
> On Saturday 13 June 2009, Brian J. Tarricone wrote:
>> I'd say might as well throw in the image format as well. It's a tiny
>> extra bit of information, and it's not a big burden to require it from
>> the
On 06/13/2009 02:56 PM, Aurélien Gâteau wrote:
> A. Walton wrote:
>> The problem with this is that it destroys the backward compatibility
>> of the spec. Hints are better for a change like this; they're Hints.
>
> Actually that's a question we should ask ourself: should we work at
> defining a new
On 06/13/2009 03:11 PM, Christian Hammond wrote:
> On Sat, Jun 13, 2009 at 3:08 PM, Brian J. Tarriconewrote:
>
>> Might be a little OT for xdg-list, but: would you be interested in
>> adding support to libnotify (or accepting a patch) to query for the
>> 'actions' capability, and if the daemon does
On 06/13/2009 03:04 PM, Aurélien Gâteau wrote:
> What I wanted to say is that I read a lot of discussions on that issue
> and I learned nothing positive ever come out of those, so I'd rather
> talk about icons, markup and other things instead.
I suppose that's fair.
> The spec says actions are o
On 06/13/2009 02:26 PM, Christian Hammond wrote:
> They know my stance on this one. Upstream libnotify and notification-daemon
> will always support actions.
Might be a little OT for xdg-list, but: would you be interested in
adding support to libnotify (or accepting a patch) to query for the
'ac
On 06/13/2009 02:18 PM, Aurélien Gâteau wrote:
> Brian J. Tarricone wrote:
>> 1. Passive vs. active notifications. I recall that notify-osd
>> unilaterally decided that the 'actions' bit of the spec was Bad[tm] and
>> that notifications should be entirely pass
Aurélien Gâteau wrote:
> We want to work with upstream developers to find
> an agreement so that applications can display notifications in a
> consistent way, regardless of which toolkit has been used.
Sounds great! FYI, I work on Xfce, and I'm the author/maintainer of
xfce4-notifyd.
> # Other
On 06/06/2009 10:52 PM, PCMan wrote:
[...]
> Here is the full specification.
> http://wiki.lxde.org/en/Desktop_Preferred_Applications_Specification
Aside from other objections raised, I see a problem with your terminal
handling. You suggest specifying something like this in the .desktop file:
E
A. Walton wrote:
> Just as a note, this is precisely the rationale behind "Uniform Type
> Identifiers", which support multiple inheritance and uses the
> currently-in-vogue reverse DNS naming scheme (e.g. you can have types
> like "com.my-media-encoder-company.complex-video-type" conform to
> org.
Philip Van Hoof wrote:
> In fact is it even worse for video thumbnailers, as the great guys of
> the many multimedia frameworks and codecs decided to have types inside
> of container MIME types. Making MIME mostly irrelevant for videos.
>
> Thanks guys. For majorly messing things up once more in
Patryk Zawadzki wrote:
> On Fri, May 15, 2009 at 9:59 AM, Brian J. Tarricone wrote:
>> Further... you *don't* want a media player (etc.) calling Inhibit on the
>> power manager. You want to tell the screen saver to stay out of the way
>> for a while, but if th
On 05/15/2009 12:33 AM, Ali Abdallah wrote:
> Patryk Zawadzki wrote:
>> On Thu, May 14, 2009 at 1:36 PM, Ali Abdallah wrote:
>>
>>> Hi,
>>>
>>> It seems that the screen saver interfaces and bus name are not standard
>>> yet! however i see this very important, since a media player shouldn't
>>> gue
Jannis Pohlmann wrote:
> This is exactly what e.g. file managers need though. Just imagine a
> file manager enters a directory, queues all its files for thumbnailing
> and then switches the directory before all files are processed by the
> thumbnailer. So IMHO it should be pointed out more clear
Rodney Dawes wrote:
> On Thu, 2009-05-14 at 11:55 -0700, Brian J. Tarricone wrote:
> No. I never actually denied these icons, or specifically stated they
> were a bad idea. I asked questions about how they would be used, and
> what they are, and how to organize them, and to get oth
Rodney Dawes wrote:
> On Thu, 2009-05-14 at 11:25 +0300, Marius Vollmer wrote:
>> True, but what might work is to have a second "Extra Icons" spec that
>> works together with the base icon spec.
>>
>> This "Extra Icon" spec would, by design, have the same goals as the base
>> spec, but would be mai
Lubos Lunak wrote:
> On Monday 20 of April 2009, Aaron J. Seigo wrote:
>> hi :)
>>
>> there are several limitations inherent to the current xembed based system
>> tray protocol, including:
>
> There are more problems with the systray than just technical problems, as
> the
> systray is rather br
On Wed, 12 Nov 2008 11:10:33 -0500 Liam R E Quin wrote:
> On Tue, 2008-11-11 at 12:01 -0800, Brian J. Tarricone wrote:
> > Liam R E Quin wrote:
>
> > > You don't want lib or bin in there either -- my login directory
> > > is on a network drive and can b
Liam R E Quin wrote:
> On Mon, 2008-11-10 at 11:16 -0800, Brian J. Tarricone wrote:
> [...]
>
>> That was actually my first thought after reading this thread, but then I
>> realised that, if it's somewhat intended for ~/.local to be a place
>> where users can i
Thiago Macieira wrote:
> Brian J. Tarricone wrote:
>> Thiago Macieira wrote:
>>> As for a lib, I very much agree that there should be a directory. In
>>> fact, I've recently started using ~/.local/bin for my own executables
>>> instead of ~/bin. That allo
Rodney Dawes wrote:
> On Mon, 2008-11-10 at 11:30 +0100, Thiago Macieira wrote:
>> Orion White wrote:
>>> Hi--
>>>
>>> I've begun to use the XDG base directory standard for my projects, and I
>>> am very happy with it.
>>>
>>> However, I do not understand the rational behind .local/share. I have
>>
Thiago Macieira wrote:
> As for a lib, I very much agree that there should be a directory. In fact,
> I've recently started using ~/.local/bin for my own executables instead of
> ~/bin. That allows me to keep my $HOME clean. But I don't think an
> environment
> variable will be of much use unl
On Tue, 02 Sep 2008 00:09:53 +0200 Philip Van Hoof wrote:
> On Mon, 2008-09-01 at 09:53 -0700, Brian J. Tarricone wrote:
> > On Mon, 01 Sep 2008 10:49:31 +0200 Philip Van Hoof wrote:
>
> > > I think canceling is overkill. Making a thumbnail doesn't take
> > >
On Mon, 01 Sep 2008 10:49:31 +0200 Philip Van Hoof wrote:
> I think canceling is overkill. Making a thumbnail doesn't take longer
> than a minute (and a minute is an extreme case). Users don't cancel
> that.
Strongly disagree. I have a laptop, and say I'm on battery power. If
I'm scrolling thro
Philip Van Hoof wrote:
> On Fri, 2008-08-29 at 11:22 +0100, Rob Taylor wrote:
>
>> I wonder if it'd make sense to allow multiple services to provide
>> thumbnailing for different mime types. This could be done by having the
>> thumbnailing service(s) register bus names of the form
>> org.freede
On Tue, 26 Aug 2008 01:07:48 +0200 Tomas Carnecky wrote:
> ben chang wrote:
> > Hi,
> >
> > I'm pretty sure the answer is "No", but I thought I'd ask
> > anyway :) Two reasons why I'm interested :
> >
> > one, naturally it's always pleasant when you can reconfigure as
> > much as possible witho
Andrea Francia wrote:
> The "cifs" filesystem is marked "nodev" in /proc/filesystems, I think
> the TrashCan should works also on this filesystem. I wonder if also the
> 'nfs' has the nodev attribute
>
> I think that there's no correlation with 'nodev' attribute and the
> suitability of have the
João Valverde wrote:
> I think another approach is needed. This information needs to be
> centralized somewhere. My suggestion is (following the spirit of the
> current spec) to create some metadata *.trashcan files in
> $XDG_DATA_HOME/Trash that would describe every other partition's
> trashc
On Wed, 13 Aug 2008 08:02:43 +0200 Damjan Jovanovic wrote:
>
> The workaround seems to be to make a Type=Application entry that
> launches firefox, and make the URL an argument to firefox - but that
> introduces a dependency on firefox, ignores the desktop's default
> browser setting, and generall
On Wed, 2 Jul 2008 22:34:45 +0200 Kees Scherpenhuijzen wrote:
> Just to make sure;
> >> And a common question: when i try to echo some of these variables
> >> it returns a empty line. Does this mean it will take the default?
> >
> >No. If you're using libxfce4util (I think Thunar may link to it
>
Kees Scherpenhuijzen wrote:
> Hey,
>
> I'm working on a project to add actions to an
> plugin(http://thunar.xfce.org/pwiki/projects/thunar-actions-plugin).
> Now i'm trying to make an feature which can read/parse the .desktop
> files(which contains the actions).
> But i'm stuck at the question whe
On Mon, 30 Jun 2008 09:44:43 +0200 Vincent Untz wrote:
> Le jeudi 26 juin 2008, à 10:53 -0700, Brian J. Tarricone a écrit :
> > David Faure wrote:
> > > http://bugs.kde.org/show_bug.cgi?id=164068 brings me to posting
> > > this mail here.
> > >
> > >
David Faure wrote:
> http://bugs.kde.org/show_bug.cgi?id=164068 brings me to posting this mail
> here.
>
> As far as I can see there is no support for expanding environment variables
> in the desktop entry standard?
> This is a problem for the "roaming user" feature: a user should be able to
>
Rodrigo Moya wrote:
> On Wed, 2008-04-30 at 10:48 -0700, Brian J. Tarricone wrote:
>> Emmanuele Bassi wrote:
>>
>>> at one point we must realize the fact that GNOME and KDE are built on
>>> two very different platforms; sharing specifications is possible - even
Emmanuele Bassi wrote:
> at one point we must realize the fact that GNOME and KDE are built on
> two very different platforms; sharing specifications is possible - even
> welcomed, but sharing API is only possible at a very low level.
Thank you! Hearing someone actually say this is like a breath
On Thu, 24 Apr 2008 17:05:14 +0800 洪任諭 wrote:
> Besides, some standard names of config values should be defined.
> GTK+ currently use something like Gtk/FontName to specify its font.
> So, it's impossible that KDE will use this.
True.
> Besides, Net/Theme is also problematic since there aren't m
On Wed, 23 Apr 2008 11:03:54 -0400 Rodney Dawes wrote:
> Sure we can. The only issue is that we need a cross-desktop
> configuration solution also. Otherwise, you're going to need to
> have the cross-desktop xsettings daemon read config values from
> various places, and magically try to merge them
On Thu, 24 Apr 2008 09:50:13 +0200 Patrice Dumas wrote:
> On Thu, Apr 24, 2008 at 12:21:39AM -0700, Brian J. Tarricone wrote:
> >
> > Well, actually it currently depends on libxfce4util as well, but
> > just for a couple convenience functions that could be easily
> &
On Thu, 24 Apr 2008 08:59:25 +0200 Stephan Arts wrote:
> 2008/4/23 洪任諭 <[EMAIL PROTECTED]>:
> > 2008/4/23 Rodney Dawes <[EMAIL PROTECTED]>:
> >
> > >
> > > On Wed, 2008-04-23 at 22:49 +0800, 洪任諭 wrote:
> > > > No, lxsession and lxsession-lite don't do that.
> > > > lxde-settings, however, ma
Vincent Untz wrote:
> Le jeudi 17 avril 2008, à 12:11 -0700, Brian J. Tarricone a écrit :
>>
>> Maybe some sort of XDG DBus service that can handle much of the
>> functionality that xdg-utils handles. Like xdg-open could be replaced
>> by a dbus method, and I imagine
洪任諭 wrote:
> Brian J Tarricone wrote:
>
>> 洪任諭 wrote:
>>
>>> However, the xdg-utils way has a serious drawback:
>>> Currently xdg-utils only recognize gnome/kde/xfce.
>>> There are much more different environments then these three, and the
&g
洪任諭 wrote:
> However, the xdg-utils way has a serious drawback:
> Currently xdg-utils only recognize gnome/kde/xfce.
> There are much more different environments then these three, and the
> number is still growing...
Then those desktop environments should add support to xdg-utils for
their envir
Dan Winship wrote:
> Vincent Untz wrote:
>> Yeah, I've been hit by this in the past too. I believe it was already
>> (at least partly) discussed, when talking about the autostart
>> specification. Can't find the thread, though.
>
> See the autostart-related threads in
> http://lists.freedesktop.or
Stanislav Brabec wrote:
> Off topic: Why ROX and XFCE are registered only for OnlyShowIn and not
> for Categories? Is it a mistake or intention?
No idea about intentions, but we usually just put 'X-XFCE' in our
.desktop files... to my knowledge our menu system is the only one
matching off that k
Havoc Pennington wrote:
> Hi,
>
> On Fri, Feb 15, 2008 at 9:48 PM, Brian J. Tarricone <[EMAIL PROTECTED]> wrote:
>> This somewhat highlights what IMHO is one of the worst things about
>> dbus: its reliance on environment variables to tell clients how to
>> con
Patryk Zawadzki wrote:
> On Feb 16, 2008 3:48 AM, Brian J. Tarricone <[EMAIL PROTECTED]> wrote:
>> Patryk Zawadzki wrote:
>> See 'man dbus-launch', specifically the --exit-with-session option.
>> That should cause the session daemon to quit if X exits.
>
&g
Patryk Zawadzki wrote:
> On Feb 16, 2008 2:28 AM, Brian J. Tarricone <[EMAIL PROTECTED]> wrote:
>> Patryk Zawadzki wrote:
>>> Would it make sense to have a per-user bus aside from the session bus?
>> The session bus *is* per-user. Well, assuming the user is on
Patryk Zawadzki wrote:
> Would it make sense to have a per-user bus aside from the session bus?
The session bus *is* per-user. Well, assuming the user is only logged
in once, which is probably a safe assumption, no? The desktop
environment/X init script/whatever is responsible for starting it
Alexander Larsson wrote:
> On Wed, 2008-02-06 at 10:29 -0800, Brian J. Tarricone wrote:
>
>>> This is all pretty bad, and the current solution to this in both KDE4
>>> and gnome (gio) is that trash to FAT/NTFS partitions is not allowed.
>> Why is this a big deal?
Alexander Larsson wrote:
> There are some issues with using the trash spec on FAT and NTFS systems.
> These filesystems don't support storing UIDs, nor does it support the
> sticky bit. Instead, the way they are generally mounted in a writable
> way under unix is:
>
> a) All files are owned by the
Takao Fujiwara - Tokyo S/W Center wrote:
> You're right. I think I can provide the tentative patch in the shor term
> however actually I expect it takes much time for the modification to be
> applied in Desktop Entry.
> I cannot break the specification but need to resolve this issue.
There's no
Alp Toker wrote:
>
> I think you might have joined this discussion from the wrong angle.
> There is no real debate that using D-Bus makes sense for traditional
> desktop environments. NDesk, another GTK+ desktop environment,
> implements dozens of Freedestkop standards, including several fdo D-
On Thu, 18 Oct 2007 17:55:11 +0900 Takao Fujiwara - Tokyo S/W Center
wrote:
>
> Brian J. Tarricone wrote:
> > I guess I still don't understand why this is necessary. If a user
> > installs a piece of software that installs a .desktop file, my
> > feeling here is tha
Takao Fujiwara - Tokyo S/W Center wrote:
> How about a new "%l" since Exec line supports some field codes?
Why? If the application launching the app in the Exec line knows what
$LANG is, then the application that gets launched knows too, and can
figure out what to do based on $LANG; there's no
Dominic Lachowicz wrote:
> 2) Install a "hunspell" program in $PATH that returns a path when
> something like "--dictionary-directory" is specified. Aspell does
> something similar.
Or, preferably, a pkg-config file, e.g., 'pkg-config --variable=dictdir
hunspell'.
-brian
___
James Richard Tyrer wrote:
> Brian J. Tarricone wrote:
>
>> Not to sound flippant or dismissive, but... who cares?
>
> You do sound flippant and dismissive. :-D
Being flippant and dismissive would have been saying "who cares" and
leaving it at that ^_~.
>> I
Jakob Petsovits wrote:
> On Monday, 16. July 2007, Brian J. Tarricone wrote:
>> James Richard Tyrer wrote:
>>> This: "emblem-symbolic-link" appears to be another issue.
>>>
>>> I think that this should be:
>>>
>>> emblem-link-s
James Richard Tyrer wrote:
> This: "emblem-symbolic-link" appears to be another issue.
>
> I think that this should be:
>
> emblem-link-symbolic
>
> or it could be:
>
> emblem-symbolic_link
>
> but there is no way that "link" is a member of "symbolic". OTOH, there
> are multiple
On Mon, 18 Jun 2007 23:27:57 +0200 Oswald Buddenhagen wrote:
>On Mon, Jun 18, 2007 at 12:15:11PM -0500, Shaun McCance wrote:
>> On Mon, 2007-06-18 at 17:35 +0200, Oswald Buddenhagen wrote:
>> > - private application icons
>> > - to be able to theme the app's private icons, the app needs to
>> >
On Mon, 18 Jun 2007 12:15:11 -0500 Shaun McCance wrote:
>On Mon, 2007-06-18 at 17:35 +0200, Oswald Buddenhagen wrote:
>> - application menu icons
>> - consensus seems to be that every application *has* to ship a
>> hicolor icon. yes, even if it is part of a desktop's core module. an
>> appli
On Sat, 31 Mar 2007 00:34:32 +0200 Lubos Lunak wrote:
>On pá 30. března 2007, Brian J. Tarricone wrote:
>> On Fri, 30 Mar 2007 23:19:26 +0200 Lubos Lunak wrote:
>> > I thought supporting an opinion did not require one to repeat it,
>> > but if you
>> >want: Shu
On Fri, 30 Mar 2007 23:19:26 +0200 Lubos Lunak wrote:
> I thought supporting an opinion did not require one to repeat it, but
> if you
>want: Shutdown/Reboot are basic functionality but power management
>features are an add-on that not everybody may be interested in having
>(see above for my feed
On Mon, 26 Mar 2007 17:12:12 +0200 Sanel Zukan wrote:
>Hi to all,
>
>I am currently implementing Base directory specification for EDE,
>according to documentation located at:
>http://standards.freedesktop.org/basedir-spec/basedir-spec-0.6.html
>
>There is stated: "If $XDG_DATA_HOME is either not s
On Sat, 24 Mar 2007 19:48:47 +0100, Vincent Untz wrote:
> Le samedi 24 mars 2007, à 10:21, Brian J. Tarricone a écrit :
> > On Sat, 24 Mar 2007 12:18:21 +0100, Vincent Untz wrote:
> > >
> > > Would this definition fix all the issues?
> > >
> > >
On Sat, 24 Mar 2007 12:18:21 +0100, Vincent Untz wrote:
>
> Would this definition fix all the issues?
>
> "Path to an executable file on disk used to determine if the program
> is actually installed. If the path is not an absolute path, the file
> is looked up in the $PATH environment variable. I
1 - 100 of 113 matches
Mail list logo
