On Wed, 2013-04-24 at 23:24 -0700, Sriram Ramkrishna wrote:
> So it's important that we get it right the first time.
No, it's not.
It's important that we make the changes when we get details wrong, as is
the case in any software.
If we had to get things right the first time, we wouldn't be writi
On Wed, Apr 24, 2013 at 8:14 AM, Colin Walters wrote:
> On Wed, 2013-04-24 at 12:22 +0200, Florian Müllner wrote:
>
> > First: If we are actually ready to roll out ostree images, that's
> > awesome news!
>
> Depends who the audience is...no security updates and you need to build
> applications fr
On Wed, 2013-04-24 at 12:22 +0200, Florian Müllner wrote:
> First: If we are actually ready to roll out ostree images, that's
> awesome news!
Depends who the audience is...no security updates and you need to build
applications from source. But if you want to see GNOME as it is a few
minutes or l
On Wed, Apr 24, 2013 at 3:51 AM, Sriram Ramkrishna wrote:
>> At least until we get a better testing infrastructure in place, the
>> only way to get at least *some* user testing is [...] to get some minimal
>> exposure to adventurous users of unstable/experimental distributions
>
> Again treating y
Planning an ostree hackfest would be more useful I would say, instead of
arguing over (another) new way of shipping code to
users/developers/testers...
Once ostree is usable all this will be moot: let developers code the thing
and once finished let everyone know that feature X can be tested with
o
On 24 April 2013 11:57, Florian Müllner wrote:
> On Wed, Apr 24, 2013 at 9:53 AM, Luc Pionchon
> wrote:
> > The main point is that so-called "controversial" features does not have
> to
> > be either a hard default, either rotting in a branch. They can be
> shipped as
> > default, but with a way
On Wed, Apr 24, 2013 at 9:53 AM, Luc Pionchon wrote:
> The main point is that so-called "controversial" features does not have to
> be either a hard default, either rotting in a branch. They can be shipped as
> default, but with a way to revert them in the case they block the user.
Wait - are you
On Wed, Apr 24, 2013 at 1:14 AM, Florian Müllner wrote:
> On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari
> wrote:
>> In fact, I think that these sorts of subtle
>> design-based decisions should be held in something like loomio (see
>> recent loomio post in desktop-devel), to be later implem
On 24 April 2013 04:54, Mathieu Bridon wrote:
> On Wed, 2013-04-24 at 04:00 +0300, Luc Pionchon wrote:
> > On 24 April 2013 02:14, Florian Müllner wrote:
> > > On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari
> > > wrote:
> > > > I think your suggestion of a "feature" branch can be a worth
On Wed, 2013-04-24 at 04:00 +0300, Luc Pionchon wrote:
> On 24 April 2013 02:14, Florian Müllner wrote:
> > On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari
> > wrote:
> > > I think your suggestion of a "feature" branch can be a worthy
> > compromise, though.
> >
> > Except that Bastien is r
On Tue, Apr 23, 2013 at 4:14 PM, Florian Müllner wrote:
>
> > I think your suggestion of a "feature" branch can be a worthy
> compromise, though.
>
> Except that Bastien is right - while on a branch, a feature will
> hardly be tested by anyone than other core developers of the same
> module. It's
On 24 April 2013 02:14, Florian Müllner wrote:
> On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari
> wrote:
>
> > I think your suggestion of a "feature" branch can be a worthy
> compromise, though.
>
> Except that Bastien is right - while on a branch, a feature will
> hardly be tested by
On Tue, Apr 23, 2013 at 11:09 PM, Marco Scannadinari
wrote:
> In fact, I think that these sorts of subtle
> design-based decisions should be held in something like loomio (see
> recent loomio post in desktop-devel), to be later implemented if the
> response is positive.
And as has been mentioned
Unfortunately, we don't have the benefit of two years of betas,
so if we implement and deliver this 3.10, there is a risk of an
impendance mismatch between what's expected from the designs and
theory behind them, and how the user effectively react. Which
woul
On Tue, Apr 23, 2013 at 11:25 AM, Bill Nottingham wrote:
> To echo Federico, I think it's a problem with any of the icons that use the
> two-tone scheme, or a problem with the tone itself rather than the icon.
>
> The 'inactive/background' dark gray used in the status indicators
> essentially fad
> Le lundi 22 avril 2013 à 14:36 +0100, Allan Day a écrit :
>> Hi all,
>>
>> This is something that me, Jon and Jakub have been thinking about for
>> some time, and is now at the stage where we can start to think about
>> implementation. I'm proposing it as a feature for 3.10 [1].
>>
>> The main el
Hello,
Any plan to add a suspend menu entry, or should we still use the
undiscoverable 'alt' trick? Newer GNOME version (3.6 ?) fixed the
problem of not being able to shutdown with another problem of not being
able to suspend, that's not an improvement... Or did I miss something?
Sorry if that wa
Allan Day (allanp...@gmail.com) said:
> > The other day she called me as she couldn't
> > figure out how to increase the volume. It turns out that audio was
> > muted, and what gnome-shell shows in that case is a dark gray audio icon
> > with a tiny little "X" on its corner.
> >
> > The dark gray
On Mon, 2013-04-22 at 11:28 -0400, Jasper St. Pierre wrote:
> On Mon, Apr 22, 2013 at 11:25 AM, Bastien Nocera
> wrote:
> On Mon, 2013-04-22 at 11:18 -0400, Jasper St. Pierre wrote:
> > I'm concerned about the "automatically opening dialog" thing
> because
> > I'm
On Mon, 2013-04-22 at 20:56 -0700, Andrew Potter wrote:
> On Mon, Apr 22, 2013 at 6:36 AM, Allan Day
> wrote:
> It should be said that, as with any design, there are
> tradeoffs here.
> There are lots of advantages to this approach (see the design
> page),
>
On Mon, 2013-04-22 at 19:55 +0200, Giovanni Campagna wrote:
> To me, a reasonable compromise (yet to decide if technically possible)
> would be to have a "feature branch", that is not merged in master
> until after it's thoroughly user tested. And that possibly gets punted
> to 3.12 or never, if it
El 22/04/13 18:57, Allan Day escribió:
> Federico Mena Quintero wrote:
>> On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote:
>> * Unsuitability of 16x16px icons on touch screens
>>
>> "So make them larger" :)
>
> And make the bar taller in the process? I don't think that people
> would thank us
On Mon, Apr 22, 2013 at 6:36 AM, Allan Day wrote:
> It should be said that, as with any design, there are tradeoffs here.
> There are lots of advantages to this approach (see the design page),
> but there are one or two actions that might require an extra click
> with the new design.
One click
On Mon, Apr 22, 2013 at 2:24 PM, Matthias Clasen
wrote:
> On Mon, Apr 22, 2013 at 1:55 PM, Giovanni Campagna
> wrote:
>
>
> > Rather, what I'd like to point out is that, in my opinion, this needs
> more
> > thinking through before going straight to shipping.
> > I mean, I trust the design team an
Matthias Clasen wrote:
>> Rather, what I'd like to point out is that, in my opinion, this needs more
>> thinking through before going straight to shipping.
>> I mean, I trust the design team and I value your experience in the field,
>> but this is another radical change, and it's quite different f
On Mon, Apr 22, 2013 at 1:55 PM, Giovanni Campagna
wrote:
> Rather, what I'd like to point out is that, in my opinion, this needs more
> thinking through before going straight to shipping.
> I mean, I trust the design team and I value your experience in the field,
> but this is another radical c
Lennart Poettering wrote:
> This all looks so ... crowded in the wireframes. So very very
> crowded. That can't be good?
First of all, did you look at the example scenarios?
On my current machine, the user menu has 6 items, with the avatar,
user name and chat status on top. With the new design,
On 04/22/2013 11:29 AM, Allan Day wrote:
> Part two of my reply. :)
>
> Alberto Ruiz wrote:
> ...
>>> More details are outlined on the wiki [2]. If you do look at the
>>> designs, please pay particular attention to the example scenarios -
>>> these give a clearer idea of what the menu will actual
On Mon, 22.04.13 14:36, Allan Day (allanp...@gmail.com) wrote:
> Hi all,
>
> This is something that me, Jon and Jakub have been thinking about for
> some time, and is now at the stage where we can start to think about
> implementation. I'm proposing it as a feature for 3.10 [1].
>
> The main ele
On Mon, 22.04.13 15:58, Bastien Nocera (had...@hadess.net) wrote:
>
> On Mon, 2013-04-22 at 15:50 +0200, Frederic Crozat wrote:
> > 2013/4/22 Allan Day :
>
> > > However, while switching wi-fi networks will require an extra step, I
> > > actually think that the the experience will be better with
, 4/22/13, Allan Day wrote:
From: Allan Day
Subject: Re: Feature proposal: combined system status menu
To: "Giovanni Campagna"
Cc: "desktop-devel-list"
Date: Monday, April 22, 2013, 2:18 PM
Hey Giovanni!
Giovanni Campagna wrote:
> As one of the implementors of the cu
Sriram Ramkrishna wrote:
> Thanks, I must have missed it. I did peruse it and it's still an extra
> click and misses the convenience of going to the network menu and hitting
> vpn on. If you're doing a lot of it I can see it getting a little
> irritating.
Yep, that's a downside of the plan. As
On Mon, Apr 22, 2013 at 11:17 AM, Florian Müllner wrote:
> On Mon, Apr 22, 2013 at 8:10 PM, Sriram Ramkrishna
> wrote:
> > This is problematic is for those of us who use VPN
>
> The mockup[0] linked from the proposal shows VPN(s) directly in the
> menu "when a VPN has been set up". Non-issue?
>
>
Hey Giovanni!
Giovanni Campagna wrote:
> As one of the implementors of the current status icons, and current
> developer of gnome-shell, I can tell it's a small can of worms, but that's
> not what this is about.
> Rather, what I'd like to point out is that, in my opinion, this needs more
> thinki
On Mon, Apr 22, 2013 at 8:10 PM, Sriram Ramkrishna wrote:
> This is problematic is for those of us who use VPN
The mockup[0] linked from the proposal shows VPN(s) directly in the
menu "when a VPN has been set up". Non-issue?
[0]
https://raw.github.com/gnome-design-team/gnome-mockups/master/she
On Mon, Apr 22, 2013 at 8:29 AM, Allan Day wrote:
> Part two of my reply. :)
>
> Alberto Ruiz wrote:
> ...
> >> More details are outlined on the wiki [2]. If you do look at the
> >> designs, please pay particular attention to the example scenarios -
> >> these give a clearer idea of what the men
Hi Allen, I appreciate the opportunity to give feeedback on this. Thank
you.
On Mon, Apr 22, 2013 at 6:36 AM, Allan Day wrote:
> It should be said that, as with any design, there are tradeoffs here.
> There are lots of advantages to this approach (see the design page),
> but there are one or t
2013/4/22 Allan Day
> Hi all,
>
> This is something that me, Jon and Jakub have been thinking about for
> some time, and is now at the stage where we can start to think about
> implementation. I'm proposing it as a feature for 3.10 [1].
>
> The main element of the design is to combine the sound,
On Mon, Apr 22, 2013 at 11:57 AM, Allan Day wrote:
> > But on non-touch screens, some people like my mom (whose eyesight is not
> > so great these days) could also benefit from bigger icons, or at least
> > *more contrasty* icons.
>
> Dude, they couldn't have any more contrast.
>
Well, they coul
On 22 April 2013 19:57, Allan Day wrote:
> Federico Mena Quintero wrote:
> > On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote:
> >
> > But on non-touch screens, some people like my mom (whose eyesight is not
> > so great these days) could also benefit from bigger icons, or at least
> > *more c
Federico Mena Quintero wrote:
> On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote:
>
>> The main element of the design is to combine the sound, network,
>> bluetooth, power and user menus into a single menu.
>
> The update proposal [1] lists the following items as problems, but it
> doesn't say *
On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote:
> The main element of the design is to combine the sound, network,
> bluetooth, power and user menus into a single menu.
The update proposal [1] lists the following items as problems, but it
doesn't say *why* they are problems. I'll comment:
*
Jasper St. Pierre wrote:
>> > Otherwise, the UX of the giant dialog looks good to me, and I'm
>> > already starting to implement it. (But where's the avatar?)
Avatar?
>> Excellent. Is there a bug to track it?
>
> Not yet. It's in a local branch on my system, as it's nowhere near
> publishable qu
Part two of my reply. :)
Alberto Ruiz wrote:
...
>> More details are outlined on the wiki [2]. If you do look at the
>> designs, please pay particular attention to the example scenarios -
>> these give a clearer idea of what the menu will actually look like.
>> The designs aren't finalised yet, s
On Mon, Apr 22, 2013 at 11:25 AM, Bastien Nocera wrote:
> On Mon, 2013-04-22 at 11:18 -0400, Jasper St. Pierre wrote:
> > I'm concerned about the "automatically opening dialog" thing because
> > I'm not sure we can tell when something automatically requests network
> > or requests network on acco
On Mon, 2013-04-22 at 11:18 -0400, Jasper St. Pierre wrote:
> I'm concerned about the "automatically opening dialog" thing because
> I'm not sure we can tell when something automatically requests network
> or requests network on account of the user.
>
>
> For instance, is an AJAX request to a web
On Mon, Apr 22, 2013 at 9:59 AM, Alberto Ruiz wrote:
> Hey Allan,
>
> first of all thanks a lot for taking the time to look into these issues
>
> 2013/4/22 Allan Day :
> > Hi all,
> >
> > This is something that me, Jon and Jakub have been thinking about for
> > some time, and is now at the stage
I'm concerned about the "automatically opening dialog" thing because I'm
not sure we can tell when something automatically requests network or
requests network on account of the user.
For instance, is an AJAX request to a website a user request or not? We
don't know. It could be clicking a button
On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote:
> Hi all,
>
> This is something that me, Jon and Jakub have been thinking about for
> some time, and is now at the stage where we can start to think about
> implementation. I'm proposing it as a feature for 3.10 [1].
>
> The main element of the
On Mon, 2013-04-22 at 16:01 +0200, Frederic Crozat wrote:
> 2013/4/22 Bastien Nocera :
> > I also think that we'll need to have more applications, and "desktop
> > daemons" making use of GNetworkMonitor to check whether they have access
> > to the Internet before trying to access resources.
>
> Y
2013/4/22 Bastien Nocera :
> On Mon, 2013-04-22 at 15:50 +0200, Frederic Crozat wrote:
>> 2013/4/22 Allan Day :
>
>> > However, while switching wi-fi networks will require an extra step, I
>> > actually think that the the experience will be better with the new
>> > design. The current network menu
On Mon, 2013-04-22 at 14:36 +0100, Allan Day wrote:
> However, while switching wi-fi networks will require an extra step, I
> actually think that the the experience will be better with the new
> design.
I would make it clear that Wi-Fi networks that connect automatically
(known networks) wouldn't
Hey Allan,
first of all thanks a lot for taking the time to look into these issues
2013/4/22 Allan Day :
> Hi all,
>
> This is something that me, Jon and Jakub have been thinking about for
> some time, and is now at the stage where we can start to think about
> implementation. I'm proposing it as
On Mon, 2013-04-22 at 15:50 +0200, Frederic Crozat wrote:
> 2013/4/22 Allan Day :
> > However, while switching wi-fi networks will require an extra step, I
> > actually think that the the experience will be better with the new
> > design. The current network menu contains a lot of information that
2013/4/22 Allan Day :
> Hi all,
>
> This is something that me, Jon and Jakub have been thinking about for
> some time, and is now at the stage where we can start to think about
> implementation. I'm proposing it as a feature for 3.10 [1].
It looks like all the pictures from the Research on this to
55 matches
Mail list logo
