ssible on any x86 hardware.
--
Matthew Garrett | mj...@srcf.ucam.org
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
blue
balls. If you're subconsciously preferring to pick up red balls then it
tells you nothing. So we need to avoid subconsciously picking red balls,
which means we need to pick users randomly which is something we can't
do with a voluntary survey. Cochran's formulas don't ap
onal-quality survey
> > team, and the first few attempts would be pretty buggy. We'd get there
> > in time, but until then...
>
> Until then it's better to have nothing?
It's better to have no data than to have misleading data.
--
Matthew Garrett | mj...@srcf.uca
o it for you no doubt.
If you went back to 1991 and wanted a production-quality kernel within a
year, Linux probably wouldn't be your starting point. There'd be a
learning process involved with setting up a professional-quality survey
team, and the first few attempts would be pretty buggy.
On Fri, Aug 19, 2011 at 08:14:25PM +0300, Felipe Contreras wrote:
> On Fri, Aug 19, 2011 at 7:24 PM, Matthew Garrett wrote:
> > Any survey that isn't a carefully controlled randomly selected sample of
> > users doesn't result in learning.
>
> Unless the biases are
ously free to do whatever he wants,
but there's no benefit in Gnome itself participating in any way. If we
want to find out what our users think then the only way to do that is to
have professional involvement and a random sample set.
--
Matthew Garrett | mj...@srcf.ucam.org
__
e and
developers really should be able to expect that it exists, but I
appreciate that real world concerns may make this more of a constraint.
--
Matthew Garrett | mj...@srcf.ucam.org
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
On Fri, May 13, 2011 at 04:44:49PM +0200, Robert Ancell wrote:
> On 13 May 2011 16:01, Matthew Garrett wrote:
> > On Fri, May 13, 2011 at 02:59:06PM +0200, Robert Ancell wrote:
> >
> >> - I am confident that the LightDM architecture is simpler than GDM.
>
lay management works. This is useful as the skillset and
> motivations of these two sets of developers are different.
This is a benefit, but I'm not sure it's a huge one. The platform in
general hasn't been designed with "Make it easy for users to write new
UI for existing
On Tue, Aug 18, 2009 at 05:02:56PM +0100, Rob Taylor wrote:
> So we discussed this at the kernel-fixing-bof at GCDS. IIRC we basically
> decided that being able to have a recursive inotify with a new flag was
> the best option. Matthew Garrett was planning on taking the issues that
>
ucture work.
>
> Or do you have plans to do the right thing here in the long term, Scott ?
The Ubuntu patches use XInput, not SHMConfig. However, right now they're
overloading DEVICE_RESOLUTION rather than using a well-specified device
control. I'm working with X ups
> kdialog
> - No client running but GNOME installed: Daemon notifies user
> through zenityugly
And I'm really not sure that the "No client" case is one that needs to
be concentrated on - if people disable chunks of their desktop, then
they're go
On Mon, Apr 10, 2006 at 12:21:58PM -0400, Rodney Dawes wrote:
> We should make it smart and allow expansion, and hide inactive and low
> priority icons, like on Windows.
If we can hide icons without losing important information, why are we
showing them in the first place?
--
Matthew G
s your target application.
Use of click to focus is recommended for basic sanity reasons.
--
Matthew Garrett | [EMAIL PROTECTED]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
tionality because Hal hasn't been ported to some
OSs yet is unreasonable. The alternative would be to provide a myriad of
small daemons that need to be individually ported, and that time could
be better spent on providing hal and giving us some consistency between
hardware access on differe
I'd argue that one well-audited mechanism for hal to execute
privileged code is preferable to half a dozen small system daemons
running as root and managing to duplicate each others bugs.
--
Matthew Garrett | [EMAIL PROTECTED]
___
desktop-devel
nking more in terms
of the exposed user interaction options.
--
Matthew Garrett | [EMAIL PROTECTED]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
lly provide any functionality that isn't already present in battstat.
--
Matthew Garrett | [EMAIL PROTECTED]
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
On Sun, Oct 30, 2005 at 09:20:34PM +, Richard Hughes wrote:
> On Sun, 2005-10-30 at 20:12 +0000, Matthew Garrett wrote:
> > I don't think this should be seen as a blocker to including
> > gnome-power-manager right now.
>
> That's my opinion too.
Cool. In th
thing
practical.
My only concern is whether there's adequate HAL support for other
platforms for gnome-power-manager to work properly there. It would be
unfortunate for things like DPMS settings to end up Linux-only.
--
Matthew Garrett | [EMAIL PROTECTED]
__
20 matches
Mail list logo
