Hi,
On Wed, Nov 17, 2010 at 9:26 AM, David Faure fa...@kde.org wrote:
OK. Good for you :-)
Can I still request that we add the key to the .desktop files?
It is very much needed, for any implementation that doesn't use the FUSE
trick. Surely you're not saying that implementors of the desktop
Hey,
On Sat, Nov 6, 2010 at 6:03 PM, Lennart Poettering mz...@0pointer.de wrote:
- It is owned by the user and the user is the only one having write
access to it
Your current proposal allows an implementation where other users can
read or enumerate the directory. This is bad. Please require
Hi,
The GIO/GVfs behavior is described here:
http://library.gnome.org/devel/gio/unstable/GAppInfo.html#GAppInfo.description
As you can see, GIO apps never ever pass URIs to apps if the URI is
available via a FUSE mount (virtually all interesting protocols such
as smb, sftp, ftp and so forth).
On Thu, 2008-09-25 at 16:01 -0400, Rodney Dawes wrote:
Also, it has always been the intent to create addendum specifications
which list standardized icon names for other specific genres of
applications. For example, I have already started on a standardized
list of device icon names[1], though
On Fri, 2008-08-29 at 14:34 +0200, Philip Van Hoof wrote:
interface name=org.freedesktop.Thumbnailer.[mime-part]
It seems odd to include the mime type in the _interface_ name; shouldn't
this be generic instead?
(Also keep in mind that both object paths and interface names in D-Bus
are
On Thu, 2008-07-03 at 20:06 +0200, David Faure wrote:
* will this create files like /usr/share/mime/x-content/image-dcf.xml, i.e. a
mimetype
definition like for every other mimetype?
That would be fine; otherwise the MimeType field would be pointing to things
that are not known as mimetypes,
On Fri, 2008-03-28 at 12:03 +0100, Thiago Macieira wrote:
- it would throw away a valid thumbnail if the file became unreadable
Maybe, uh, that's a feature. Or to put it stronger: a bug fix for a
security vulnerability in the spec. Someone took away your read
privileges, why should you still be
Hey,
Two things, one simple.. the link from
http://www.freedesktop.org/wiki/Specifications?action=showredirect=Standards
pointing to the thumbnail spec
http://jens.triq.net/thumbnail-spec/index.html
doesn't work. Probably we should host this spec in fd.o SCM and also
host the latest
On Tue, 2007-04-03 at 12:04 +0200, Patryk Zawadzki wrote:
What about system-level apps that need to inhibit (think daemons)?
They have no session daemon to register to.
System-level locking is still needed and it's more suited as it does
not require you to register any foobar callbacks that
On Tue, 2007-04-03 at 00:05 +0200, Holger Macht wrote:
I somehow had the impression that we slightly agreed on having the
following:
org.freedesktop.SessionManagement.Shudown()/Reboot()/Logout()
and
org.freedesktop.PowerManagement.Hibernate()/Suspsned()/...
And gnome-power-manager will
On Mon, 2007-04-02 at 23:17 +0100, Richard Hughes wrote:
On Mon, 2007-04-02 at 18:10 -0400, David Zeuthen wrote:
I agree, and I'd even say that gpm and others shouldn't
Shouldn't or should?
Shouldn't
start providing the SM interface as it may be a bit more complicated
than
On Mon, 2007-04-02 at 23:52 +0100, Richard Hughes wrote:
On Mon, 2007-04-02 at 18:39 -0400, William Jon McCann wrote:
Nada. I just wanted to point out that I've been working hard toward
the goal of providing some LoginManager/DisplayManager D-Bus
interface. Lots of rather unpleasant
On Sat, 2007-03-31 at 10:07 +0200, Lubos Lunak wrote:
I'm still not quite sure Inhibit() even belongs to PM interface, I
cannot think of a single case when an app would want to block suspend
but would not want to block logout, so it'd always have to block both
of them. However the SM semantics
On Fri, 2007-03-30 at 14:52 +0100, Richard Hughes wrote:
1. Other desktop
- Desktop User A runs a software update tool or similar
- Tool does Desktop Session A.pm.InhibitManual()
- Desktop User A goes away while it runs
- Desktop User B logs in
- Desktop User B selects Power Off
On Fri, 2007-03-30 at 09:23 -0400, William Jon McCann wrote:
So, instead of ManualInhibit perhaps the application can set a lock on
the Computer device or similiar. The advantage of doing this directly
to HAL instead of proxying it though desktop.PM is that it should be
simpler to get signals
On Fri, 2007-03-30 at 23:19 +0200, Lubos Lunak wrote:
On pá 30. března 2007, David Zeuthen wrote:
On Fri, 2007-03-30 at 17:47 +0200, Lubos Lunak wrote:
Well, you could contribute to the discussion, or bash GNOME
applications. g-p-m uses a lot of libraries, and loads only
On Sat, 2007-03-31 at 00:08 +0200, Lubos Lunak wrote:
The problem here is that Inhibit() on org.fd.PM affects the
implementation on of Shutdown() and Reboot() - e.g. if I want to be able
to make sure that the user gets this dialog
Some app $APP is preventing shut down because: $REASON.
On Fri, 2007-03-30 at 18:58 -0400, David Zeuthen wrote:
The way this could work is then that org.fd.PM.Inhibit() would also call
Inhibit() on org.fd.SM. Specifically, as you mention, existing PM
daemons like gnome-power-manager, kpowersave etc. would just provide
both interfaces until
On Sat, 2007-03-31 at 01:04 +0200, Holger Macht wrote:
Would this work for everyone? Personally I think this is a lot nicer.
Me too, because...
Great!
It's exactly what I have already proposed in another mail. Except that
org.freedesktop.SessionManagement was called
On Thu, 2007-03-29 at 16:08 +0100, Richard Hughes wrote:
On 29/03/07, Holger Macht [EMAIL PROTECTED] wrote:
1. Shouldn't we add a time until wakeup argument to the suspend call? I
imagine a vcr application calling suspend with this argument to wakeup
and start recording. Yes,
On Thu, 2007-03-29 at 15:22 -0400, David Zeuthen wrote:
Please at least _try_ to keep the interface simple and come up with use
cases before adding useless API like time to wake up after suspend:
(I of course meant time to wake up after hibernate)
David
On Thu, 2007-03-29 at 22:10 +0200, Danny Kukawka wrote:
Danny, I think if there are systems where standby is actually working and
suspend to ram is not, Suspend() should do S1 behind the back of all
applications. And if there are systems where both S1 and S3 are working,
S3 should be
On Thu, 2007-03-29 at 23:02 +0200, Holger Macht wrote:
But keep in mind that many hard code users will never use it anyway and
few distros will ship it for their twm / failsafe session. They would
probably just use kpowersave, g-p-m or whatever the distro wants.
That's not the point.
On Thu, 2007-03-29 at 23:07 +0200, Holger Macht wrote:
And as a conclusion, if no one else has any comments on this, I think we
should let it up to Richard to decide whether to take the Standby()
methods or not.
Well, as this spec is a) intended to be stable soon; b) have a life-span
of many
On Fri, 2007-03-30 at 00:03 +0200, Holger Macht wrote:
On Thu 29. Mar - 22:58:10, Richard Hughes wrote:
On Thu, 2007-03-29 at 23:52 +0200, Holger Macht wrote:
I don't why it's only me seeing the problem here? You want to have
Shutdown() and Reboot() on _every_ system, but not
On Fri, 2007-03-30 at 00:25 +0200, Holger Macht wrote:
Am not really sure where we disagree. I mean, GNOME ships with
gnome-power-manager in the release set, so GNOME is good out of the box.
People want to disable gnome power manager on usual desktop systems.
Well, perhaps a few of them do
On Thu, 2007-03-29 at 23:38 +0100, Richard Hughes wrote:
On Thu, 2007-03-29 at 18:31 -0400, David Zeuthen wrote:
Perhaps it's just easier to remove these from the org.fd.PM interface
then and tell ISV's to do... something else. I don't know. What's the
freedesktop.org story
On Thu, 2007-03-22 at 13:37 +, Richard Hughes wrote:
boolean GetLowPowerMode (void)
This method, is it the same as the one exported by HAL? I mean, the one
that comes from pm-utils?
No, it's a user preference version of it. Imagine this method
returning false when we are on AC, or
On Thu, 2007-03-22 at 19:36 +, Richard Hughes wrote:
Sure, GetLowPowerMode sucks as a name. GetPreferPowerSavings isn't much
better tho :-)
What about:
GetPowersaveStatus
GetPowerModePreference
GetUseLowPower
GetSavePowerPreference
Don't ask me; I totally suck at naming! Though I
On Wed, 2007-03-21 at 18:27 +0100, Oswald Buddenhagen wrote:
On Tue, Mar 20, 2007 at 09:50:20PM +, Richard Hughes wrote:
I want to restart discussion on the previously discussed session power
management interface: org.freedesktop.PowerManagement
instead of restarting it you might want
On Wed, 2007-03-21 at 21:19 +0100, Oswald Buddenhagen wrote:
= Suspend ==
You have not got the permissions to suspend
Enter root password: [___]
actually, i *am* going to. the login managers (can) do the same for
complete shutdown, so there is no reason not to do so
On Tue, 2007-01-09 at 09:11 +0100, Alexander Larsson wrote:
that makes it very easy to use encrypted volumes on e.g. USB drives. The
right thing to do is probably to store the thumbnails per mount as we do
with trash-spec. Something to keep in mind.
Its very easy to say per volume, but
Hi,
Speaking about thumbnails, I was thinking the other day that the
thumbnail spec probably needs revision before it's ready for 1.0.
The problem is with encrypted volumes; we really don't want to store
plain-text thumbnails originating from files on encrypted thumb drives.
We should probably
Hi Waldo and list,
On Sat, 2006-06-24 at 00:41 -0700, Bastian, Waldo wrote:
The curious that don't want to bother with unpacking tarballs can read
the documentation here:
http://portland.freedesktop.org/xdg-utils-1.0beta1/
xdg-su really needs to go. Here are just two reasons
1. I
On Thu, 2006-07-06 at 15:38 -0700, Dan Kegel wrote:
On 7/6/06, David Zeuthen [EMAIL PROTECTED] wrote:
xdg-su really needs to go. Here are just two reasons
1. I don't think we should be encouraging ISV's to use insecure
methods to do privileged operations. It's a get-out-of-jail-card
On Fri, 2006-06-02 at 15:30 +0200, Rodrigo Moya wrote:
for the same reason I think we should add the Reboot and keep Shutdown
methods, I think it's better if apps use only a standard interface for
all power management-related tasks than having to use dbus for some
operations, X libs for
On Fri, 2006-06-02 at 11:02 +0200, Alexander Larsson wrote:
Some systems also have a mode where they both save to disk and memory
at the same time, then they suspend, but if power goes low they power
down (and un-hibernate on startup).
You may be referring to Windows Vista, that's the only
On Thu, 2006-06-01 at 10:07 -0400, William Jon McCann wrote:
Hi Waldo,
Bastian, Waldo wrote:
The screensaver interface looks good. What is the use case for the
Poke method?
The Poke method is a way to simulate user input. It is the programmatic
equivalent to moving the mouse back
Hi Kevin!
On Thu, 2006-06-01 at 20:10 +0200, Kevin Ottens wrote:
Le jeudi 1 juin 2006 00:01, Richard Hughes a écrit :
Okay, my first post to this list, so I hope I'm aiming in the right
direction.
gnome power manager : org.gnome.PowerManager
gnome screensaver :
On Thu, 2006-06-01 at 11:03 -0700, Bastian, Waldo wrote:
Does the current dbuslib implementation allow you to specify what to do
when the dbus connection gets dropped? If not, then I think that should
be added.
Yes. Use dbus_connection_set_exit_on_disconnect (DBusConnection*).
David
On Thu, 2006-06-01 at 20:44 +0200, Holger Macht wrote:
To interact with the session we need this to be session context rather
than system context. Plus with David's work, the distinction between
session and system will be a lot smaller. For powersaved, any session
program can just process
On Thu, 2006-06-01 at 15:05 -0400, David Zeuthen wrote:
On Thu, 2006-06-01 at 20:44 +0200, Holger Macht wrote:
To interact with the session we need this to be session context rather
than system context. Plus with David's work, the distinction between
session and system will be a lot
On Thu, 2006-06-01 at 21:21 +0200, Holger Macht wrote:
The problem, Holger, is that if the org.freedesktop.PowerManager service
is on the system bus, it's awkward and backwards to interact with the
desktop session using notifications and dialogs. It's not impossible,
just pretty awkward.
On Thu, 2005-07-07 at 12:33 +0100, Mike Hearn wrote:
3) For the case of auto-starting on external media eg CD-ROMs and USB
Keys, they may be formatted with a filing system that does not
understand the concept of the UNIX +x bit. What do people who want
auto-start files in this
44 matches
Mail list logo
