> The concept involved in volume and brightness gauges is different from
> regular notifications to the point I don't feel confortable in using the
> word "notifications" at all. I can't be "notified" of something I *expect*
> to see. I think "feedback" is a more appropriate world.
Oops, I notice
> Hey, slightly random, but could I suggest putting synchronous bubbles
> a bit above the bottom edge at the horizontal centre? (Where there
> used to be a popup for adjusting volume and brightness). I think there
> may have been some reason behind that approach :)
Jumping late to the discussion,
Scott E. Armitage wrote:
The middle of the screen, or the middle of the screen on the right-hand
side? I maintain that the centre of the screen is still a viable option for
synchronous notifications such as e.g. volume, brightness, etc. -- the user
is actively interfacing with the computer,
On Wed, Nov 11, 2009 at 6:25 PM, Brett Cornwall wrote:
>
> Well, let me save you from some grief: I can promise you, without a doubt,
> that the middle of the screen will not fly for anyone. :).
>
> I know this argument can be said for anything, but I strongly feel that
> this is an item that shoul
Mark Shuttleworth wrote:
Hold on a sec. We are not just aimlessly pushing it around. We have a
clear set of tradeoffs and constraints (see a previous mail on this
list). Theory is useful, but it also helps to have actual time spent
(i.e. a few weeks to get used to it) with various options. T
> Theory is useful, but it also helps to have actual time spent
> (i.e. a few weeks to get used to it) with various options. That's what
> we'll do in Lucid, we'll try the bottom right and get some real
> experience with it. We may try the centerline again (popular as that was
> :-)). And by the en
Scott E. Armitage wrote:
> It sounds like this is putting the horse before the bit -- there is
> still a lot of turmoil out there regarding NotifyOSD's positioning.
> The "Work for Lucid" section /should/ say something more like
>
> " Positioning: Determine the driving requirements for notification
It sounds like this is putting the horse before the bit -- there is still a
lot of turmoil out there regarding NotifyOSD's positioning. The "Work for
Lucid" section *should* say something more like
" Positioning: Determine the driving requirements for notification bubble
positioning and separate t
Hi ,
Recent update in the Lucid specs:
https://wiki.ubuntu.com/NotifyOSD#Work%20for%20Lucid
" Change in position: The top of any notification bubble should be
positioned near the bottom right corner such that if the bubble grows to
its maximum height, it is snug at the bottom right corner. Conf
Hi Tony
I suggest you read the specification in https://wiki.ubuntu.com/NotifyOSD.
>
>
I have read it.
> In short: the notification bubbles are not supposed to be interactive. Not
> even in the
> sense of being interactively closed. The bubble fades away when the mouse
> is over
> it to make it
> Date: Wed, 4 Nov 2009 08:41:46 +0200
> From: djay...@gmail.com
> To: ayatana@lists.launchpad.net
> CC: brettcornw...@gmail.com; dylanmcc...@gmail.com
> Subject: Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala
> I wanted to understand something here, as it
I wanted to understand something here, as it feels that I'm getting
something wrong.
I'm working on 22" monitor with 1680x1050 resolution, and bubble are coming
at the top
of the screen as expected. So I don't have the problems Dylan had.
Here's the thing though: the bubble is usually very visual
Here's an interesting quote from a user from the bug report:
"Having
read this head to tail I see that the discussion is becoming repetitive
and not bringing nothing new, I think we should push it into a more
constructive direction. I will summarize the most important points that
have been sai
On Thu, 2009-10-22 at 09:24 +0100, Luke Benstead wrote:
> Finally, in the notification bubble we can make the text slide
> up, rather than jump up, and also fiddle with the display time and the
> width of the bubble (so more text fits on a single line).
The width of the bubbles is probably not g
> In IM clients the text does not disappear , so you can take your time to
> catch up with the text.
> Try this , try reading text in an irc chat room with heavy traffic,[eg:
> #ubuntu]. You'll notice it is not easy to catch up.
>
Thinking about it, I don't believe comparisons with IM or IRC are f
Another interesting idea would be just to flip what we currently have so
that sync notifications are at the bottom right, and then async grow
vertically above them. This would make the async notifications more like it
IM window itself, where new text appears at the bottom and old text scrolls
up, a
2009/10/21 mac_v :
> What we could do is:
> - Place the Async bubbles in the lower right, at a height keeping in
> mind the max[10 lines] allowed for append. So the bubble is in the lower
> right position but not exactly in the corner. This would make the
> bubbles not have a problem of scrollin
> 2009/10/21 Martin Albisetti :
> > Mark Shuttleworth wrote:
> >>
> >> Johan Euphrosine wrote:
> >>>
> >>> Here is better mockup:
> >>>
> >>> http://bitbucket.org/proppy/clutter-repl/raw/4b8460e1e300/logs/session14.ogv
> >>>
> >>
> >> Let's hear what others think.
> >
> > It feels odd to read from
On Wed, 2009-10-21 at 21:00 +0100, Mark Shuttleworth wrote:
> Can you get rid of the blank line between the lines of text, just to
> tighten it up? And can you make it more real, like put a couple of
> lines in there in one hit, then add a few others with random timing,
> as if it were someone typi
2009/10/21 Martin Albisetti :
> Mark Shuttleworth wrote:
>>
>> Johan Euphrosine wrote:
>>>
>>> Here is better mockup:
>>>
>>> http://bitbucket.org/proppy/clutter-repl/raw/4b8460e1e300/logs/session14.ogv
>>>
>>
>> Let's hear what others think.
>
> It feels odd to read from the bottom to the top. I p
Mark Shuttleworth wrote:
Johan Euphrosine wrote:
Here is better mockup:
http://bitbucket.org/proppy/clutter-repl/raw/4b8460e1e300/logs/session14.ogv
Let's hear what others think.
It feels odd to read from the bottom to the top. I played around with moving
things on the screen upwards and
Johan Euphrosine wrote:
> Here is better mockup:
> http://bitbucket.org/proppy/clutter-repl/raw/4b8460e1e300/logs/session14.ogv
>
Can you get rid of the blank line between the lines of text, just to
tighten it up? And can you make it more real, like put a couple of lines
in there in one hit, the
Cody, this is an excellent post.
It's the best explanation of the project's reasoning, without the hard
edge. You will still get push back, but now you have a concise,
coherent argument that isn't quite so authoritarian. This really needs
to go in a FAQ.
Jim
On Wed, 2009-10-21 at 13:36 -05
On Wed, 2009-10-21 at 20:20 +0100, Matt Wheeler wrote:
> Are you actually suggesting that messages that stay visible for longer
> should bob up and down depending on whether there is a newer message
> beneath it?
> (if that is not the case then perhaps the messages in the video need
> to be number
Johan Euphrosine wrote:
> On Wed, 2009-10-21 at 18:09 +0100, Mark Shuttleworth wrote:
>
>> That would be worth a flash mockup, or code mockup, to see in
>> practice.
>>
>>
>
> Hi,
>
> Here is a tentative clutter mockup:
> http://bitbucket.org/proppy/clutter-repl/raw/2f7b36efb1fe/logs/sessio
2009/10/21 Matt Wheeler :
> 2009/10/21 Luke Benstead :
>> You legend! Yeah, exactly that kind of thing, I think it would look pretty
>> cool.
>>
>> Thanks a lot!
>>
>> So, good idea?
>
> Are you actually suggesting that messages that stay visible for longer
> should bob up and down depending on wh
2009/10/21 Luke Benstead :
> You legend! Yeah, exactly that kind of thing, I think it would look pretty
> cool.
>
> Thanks a lot!
>
> So, good idea?
Are you actually suggesting that messages that stay visible for longer
should bob up and down depending on whether there is a newer message
beneath
2009/10/21 Johan Euphrosine :
> On Wed, 2009-10-21 at 18:09 +0100, Mark Shuttleworth wrote:
>> That would be worth a flash mockup, or code mockup, to see in
>> practice.
>>
>
> Hi,
>
> Here is a tentative clutter mockup:
> http://bitbucket.org/proppy/clutter-repl/raw/2f7b36efb1fe/logs/session13.ogv
On Wed, 2009-10-21 at 18:09 +0100, Mark Shuttleworth wrote:
> That would be worth a flash mockup, or code mockup, to see in
> practice.
>
Hi,
Here is a tentative clutter mockup:
http://bitbucket.org/proppy/clutter-repl/raw/2f7b36efb1fe/logs/session13.ogv
Luke, let me know if it implements prope
On Wed, 2009-10-21 at 13:29 -0400, Jim Rorie wrote:
> I'm not talking about visible checkboxes or customization
> applications.
> Don't go the KDE route. Give power users/admins access to gconf for a
> few variables that could have a big impact on user experience.
As a developer on the DX team do
2009/10/21 Mark Shuttleworth :
> Luke Benstead wrote:
>
> The only thing against that is what Mark said about the async
> notifications growing upwards, but I still don't see why that's a
> problem (it would look pretty cool if the existing text moved up, then
> the new line faded in below).
>
> Th
Jim Rorie wrote:
>>> I notice that you don't insist upon one application per
>>> function available in the repositories or launchpad PPAs.
>>>
>>>
>> Of course not. Nor would I resist there being many branches of
>> notify-osd. But I will resist calls for "this should be an option".
>>
On Wed, 2009-10-21 at 17:31 +0200, Alex Lourie wrote:
>
>
>
> Ok, hold on a second. How come the presence or absence of options in
> some
> quite experimental software DESTROYS moment of Linux Desktop??? I
> can't understand
> how is it that after so many work being put into the opera
Luke Benstead wrote:
> The only thing against that is what Mark said about the async
> notifications growing upwards, but I still don't see why that's a
> problem (it would look pretty cool if the existing text moved up, then
> the new line faded in below).
That would be worth a flash mockup, or co
I just realized that I mistakenly posted the following directly to Mark
Shuttleworth yesterday in error (mistakes abound when you can't see well), and
felt that it should be shared with all:
"I'd like to clarify something and make a possible suggestion that may
or may not even be possible or via
>
>
>
> > > I believe it will drive people away, hurt
> > > upstreams, a number of side streams and limited sections of downstream.
> > >
> > What does that mean exactly? I think you're mouthing off because you
> > don't like the idea of having to go with something you don't
> > personally like occ
On Wed, 2009-10-21 at 13:02 +0100, Mark Shuttleworth wrote:
> Sometimes folks actually want to push their own ideas, and think
> that's collaboration. That's not going to work here, because we have a
> core driver already.
There is a difference between push and contribute. It's typically in
th
>
> So, probably, the solution is rather to find some clever algorithm that
> places them dynamically based on the current desktop conditions, but we
> won't be motivated to search for this algorithm if we resort to creating
> more options as soon as someone complaints.
Heh, OK you've almost won m
On Wed, Oct 21, 2009 at 3:16 PM, Luke Benstead wrote:
> [...] I think the reason that notify-osd's positioning is a particular
> sticking point with many people is that it is something where no
> default location will suit the majority of people. Users with visual
> problems, non-default layouts,
2009/10/21 Paulo J. S. Silva
> In my humble opinion this is one of best ways to end a conversation:
> takes your "opponent" point of view and turn it into a caricature that
> make it sound unreasonable.
>
Well, I thing exposing the weaknesses in other people's argumentation is at
the core of any
> Look at it this way, every decision you make when designing software,
> you weigh up the pros and cons of all the options before you make it.
> When neither option has any concrete benefit over the other, that's
> when it's down to personal preference and that (I would argue) is when
> you make i
> In general, no. If the ideas they express are better, but the metrics we can
> bring to bear (including the view of the people to whom the design
> leadership has been given) then those patches can be included without
> options, the default behaviour will be improved for all. If they just create
Mark Shuttleworth wrote:
A guiding principle in Ayatana is to *reduce* customisation, not
increase it.
Then I am afraid that you are going to lose a lot of interest from lots
of people. I really do understand your intentions, and I think they are
wonderful, but there is a happy medium
>It certainly doesn't sound like "I am because of my community", it
> sounds like "I am because of what Mark likes to see". Scary in a way.
>This can also work the other way around. I could say that your
> my-customized-to-the-last-pixel-way-or-the-highway stance is a pretty selfish
> one,
Martin Owens wrote:
> Hello Mark,
>
> On Wed, 2009-10-21 at 11:09 +0100, Mark Shuttleworth wrote:
>
>> First, we get much better collaboration and communication,
>>
>
> Do we? The first thing I've noticed from this experimental opinionated
> stance is a tendency to alienate and frustrate pe
On Wed, Oct 21, 2009 at 1:13 PM, Martin Owens wrote:
> [...] The first thing I've noticed from this experimental opinionated
> stance is a tendency to alienate and frustrate people who want to
> collaborate. There are people who will give up their personal visions
> for yours without lots of hard
On Wed, 2009-10-21 at 13:37 +0200, Victor wrote:
> I quote Mark from earlier in this list:
> There's always a temptation, when two smart and well-meaning people
> can't agree, to add an option so they can both get what they want. It
> "costs nothing" to add the checkbox, and it creates the illusio
I quote Mark from earlier in this list:
There's always a temptation, when two smart and well-meaning people can't
agree, to add an option so they can both get what they want. It "costs
nothing" to add the checkbox, and it creates the illusion of consensus
because "we can each have what we want" wh
Hello Mark,
On Wed, 2009-10-21 at 11:09 +0100, Mark Shuttleworth wrote:
> First, we get much better collaboration and communication,
Do we? The first thing I've noticed from this experimental opinionated
stance is a tendency to alienate and frustrate people who want to
collaborate. There are peop
Brett Cornwall wrote:
> It all boils down to customization. I really feel that the way to make
> everyone happy is to have reasonable configuration for notify-OSD.
> Being able to choose the position easily and whether the policy is
> fixed or dynamic would allow peace to any that are dissatisfied.
On Tue, Oct 20, 2009 at 5:38 PM, Christian Hudon wrote:
>
> I personally think it'd be really nice (and useful) if something like the
> previous email from Mark was made available for every large UI change that
> Ubuntu makes. (I don't know... I'm thinking of something similar to the
> Python PEPs
Mark Shuttleworth wrote:
The position is final for 9.10 but can certainly be reconsidered for
Lucid.
The factors that need to be considered are:
* fitting things into the corner is most aesthetically pleasing
* the "synchronous" notifications (like brightness and volume) are
fixed in size
Regarding Notify-OSD's Position in Karmic Koala
> That's where we settled for 9.10. For 10.04 I would like to revisit the
> midpoint of the right hand side. I would not want to rehash old territory,
> so please factor in the above in proposing new ideas. I'm of the view that
> That's where we settled for 9.10. For 10.04 I would like to revisit the
> midpoint of the right hand side. I would not want to rehash old territory,
> so please factor in the above in proposing new ideas. I'm of the view that
> this decision involves at least one ugly compromise no matter which w
Brett Cornwall wrote:
> Hello, I'm bringing attention to the mailing list that there's a fair
> amount of displeasure at the newly designated spot for notify-osd. You
> may read the entire bug report/thread here:
>
> https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/438536
>
> In a nutshell
Hello, I'm bringing attention to the mailing list that there's a fair
amount of displeasure at the newly designated spot for notify-osd. You
may read the entire bug report/thread here:
https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/438536
In a nutshell, quite a lot of users found th
56 matches
Mail list logo
