Richard Hughes [2009-07-02 17:47 +0100]:
> 2009/7/2 Martin Pitt :
> > On a related note, I had always wished g-p-m (and GNOME in general)
> > had a separate mode/policy for "laptop is docked", i. e. this exists:
>
> What would it do differently to the on AC case?
Nothing really. I contradicted my
2009/7/2 Martin Pitt :
> On a related note, I had always wished g-p-m (and GNOME in general)
> had a separate mode/policy for "laptop is docked", i. e. this exists:
What would it do differently to the on AC case?
Richard.
___
devkit-devel mailing list
d
On Thu, 02 Jul 2009 12:15:41 -0400
David Zeuthen wrote:
> On Thu, 2009-07-02 at 11:12 -0500, Robby Workman wrote:
> > > a) use standard configuration systems like e.g. GConf
> >
> >
> > GConf is not "standard" at all.
>
> Hence the term "e.g." - it means "for example".
>
> > If the goal is
Richard Hughes [2009-07-02 17:08 +0100]:
> So, I do need another property regardless to inform the prefs ui if
> the machine has a closable lid or not. We know this as we already
> monitor and export a property about the lid state.
I agree, forming default policies based on "how many batteries"/"l
Richard Hughes [2009-07-02 16:36 +0100]:
> Another thing, is we're exporting this as a property in
> DeviceKit-power, then the dmi data can be one source of information, a
> seed if you like. Other metrics could be if the system has more than 4
> disks it can be a server, but you get the idea. Not
On Thu, 2009-07-02 at 17:08 +0100, Richard Hughes wrote:
> So, I do need another property regardless to inform the prefs ui if
> the machine has a closable lid or not. We know this as we already
> monitor and export a property about the lid state.
>
> Ignoring form factor for a little bit, how abo
2009/7/2 David Zeuthen :
> No, it is not a goal for policy agents like gnome-power-manager to be
> desktop neutral - in fact, it's an anti-goal.
Right, it's called GNOME Power Manager because it depends on all the
GNOME stack.
Richard.
___
devkit-devel
On Thu, 2009-07-02 at 11:12 -0500, Robby Workman wrote:
> > a) use standard configuration systems like e.g. GConf
>
>
> GConf is not "standard" at all.
Hence the term "e.g." - it means "for example".
> If the goal is desktop-neutrality
> (which it should be, IMHO), then GConf should be out o
2009/7/2 David Zeuthen :
> Richard, I know you are just trying to push the envelope here and make
> things work out of the box - however, your assumption that a "form
> factor" value is available and trustworthy is just fundamentally flawed.
Okay, no worries, I'll agree that trying to be clever wi
On Thu, 02 Jul 2009 11:55:54 -0400
David Zeuthen wrote:
> On Thu, 2009-07-02 at 16:43 +0100, Richard Hughes wrote:
> > So, would a "is-laptop" property make more sense?
>
> No, no, no. You are conflating policy with the form-factor here. You
> are trying to be "helpful" but not realizing it's h
On Thu, 2009-07-02 at 16:43 +0100, Richard Hughes wrote:
> So, would a "is-laptop" property make more sense?
No, no, no. You are conflating policy with the form-factor here. You are
trying to be "helpful" but not realizing it's having the opposite
effect. That's what I've been trying to say all a
On Thu, Jul 2, 2009 at 11:43 AM, Richard
> stop talking about "Computer is low" and start talking about "Laptop
> is low" in the UIs.
Neither makes any sense to me...
___
devkit-devel mailing list
[email protected]
http://lists.freedeskt
2009/7/2 Bill Nottingham :
> laptop vs. is a form factor decision.
> Desktop vs. server is a use case decision.
True...
> While you can generally assume a 3U rack box or a blade is a server
> of some sort, it's much less clear for the 'desktop' form factors -
> they can just as easily be a 'serv
Richard Hughes ([email protected]) said:
> 2009/7/2 Kay Sievers :
> > Exactly, there is absolutely no way to tell what is a "server". Maybe
> > the "laptop" classification kind of works (can use better indications
> > for this), but there is no such thing as a "server" and "desktop" you
> > can
2009/7/2 Kay Sievers :
> Exactly, there is absolutely no way to tell what is a "server". Maybe
> the "laptop" classification kind of works (can use better indications
> for this), but there is no such thing as a "server" and "desktop" you
> can ever retrieve reliably from dmi data.
So DMI data is
On Thu, Jul 2, 2009 at 17:21, David Zeuthen wrote:
> On Thu, 2009-07-02 at 16:12 +0100, Richard Hughes wrote:
>> I really don't want to teach
>> gnome-power-manager about the niceties of dmidecode just so it can
>> choose the default policy in a sane way.
>
> No, just make g-p-m read settings from
On Thu, 2009-07-02 at 16:12 +0100, Richard Hughes wrote:
> > Yeah, maybe it dies for good with HAL, and we should not pretend to
> > know anything like this. Sounds like the best road to take from where
> > we are now.
>
> Then that's a regression.
Please don't use the word regression like that,
On Thu, 2009-07-02 at 17:08 +0200, Kay Sievers wrote:
> > Or maybe it turns out that we don't want something like this at all - I
> > mean, you can't really trust DMI data in the first place so it's rather
> > optimistic what Richard is trying to do. E.g. we don't want to give out
> > potentially w
On Thu, Jul 2, 2009 at 17:12, Richard Hughes wrote:
> 2009/7/2 Kay Sievers :
>> Yeah, it's a bit dangerous.
>
> Yes, I think virtual devices are a quick way back to the HAL mess.
> That's why I wanted to merge the data back to where it came from, so
> to speak. All it's doing is providing a mapping
2009/7/2 David Zeuthen :
> Or maybe it turns out that we don't want something like this at all - I
> mean, you can't really trust DMI data in the first place so it's rather
> optimistic what Richard is trying to do. E.g. we don't want to give out
> potentially wrong data.
Then we add quirks for th
2009/7/2 Kay Sievers :
> Yeah, it's a bit dangerous.
Yes, I think virtual devices are a quick way back to the HAL mess.
That's why I wanted to merge the data back to where it came from, so
to speak. All it's doing is providing a mapping for one key value to
another, with a DKP_ prefix.
> Yeah, ma
On Thu, Jul 2, 2009 at 17:09, Scott James Remnant wrote:
> On Thu, 2009-07-02 at 16:32 +0200, Kay Sievers wrote:
>
>> No, better don't stuff things into the dmi device, not all platforms have
>> that.
>>
> If they don't have a dmi device, then they won't have this information
> anyway.
>
> That's
On Thu, 2009-07-02 at 16:32 +0200, Kay Sievers wrote:
> No, better don't stuff things into the dmi device, not all platforms have
> that.
>
If they don't have a dmi device, then they won't have this information
anyway.
That's like saying we shouldn't put ID_FS_TYPE in block devices because
not
On Thu, Jul 2, 2009 at 17:01, David Zeuthen wrote:
> On Thu, 2009-07-02 at 16:46 +0200, Kay Sievers wrote:
>> On Thu, Jul 2, 2009 at 16:35, Richard Hughes wrote:
>> > 2009/7/2 Kay Sievers :
>> >> No, better don't stuff things into the dmi device, not all platforms have
>> >> that.
>> >
>> > Then w
On Thu, 2009-07-02 at 16:46 +0200, Kay Sievers wrote:
> On Thu, Jul 2, 2009 at 16:35, Richard Hughes wrote:
> > 2009/7/2 Kay Sievers :
> >> No, better don't stuff things into the dmi device, not all platforms have
> >> that.
> >
> > Then where in the database should this data go?
>
> There is no
On Thu, Jul 2, 2009 at 16:35, Richard Hughes wrote:
> 2009/7/2 Kay Sievers :
>> No, better don't stuff things into the dmi device, not all platforms have
>> that.
>
> Then where in the database should this data go?
There is no place in udev so far. We can't do that unless we invent
some fake devi
2009/7/2 Kay Sievers :
> No, better don't stuff things into the dmi device, not all platforms have
> that.
Then where in the database should this data go?
> This? http://cgit.freedesktop.org/~david/xdg-hostname/
That's the hostname, not the formfactor... Confused.
Richard.
___
On Thu, Jul 2, 2009 at 16:11, Richard Hughes wrote:
> One of the nice things about DMI data is that it gives you the form
> factor of the device, so you can choose sensible defaults for laptops,
> servers and handhelds. This data is exported in HAL, but not
> DeviceKit-*
>
> What about something li
28 matches
Mail list logo
