[Ayatana] Getting rolling for 9.10

Hi folks This is the right spot for proposals and discussions for the next round of evolution of the notification guidelines behind Notify-OSD and the Messaging Menu. The best format for proposals is probably mockups and specs on the Ubuntu wiki, combined with mention of existing / new bugs. Look

[Ayatana] Debugging / aligning notification priorities with Notify OSD

Matthew Paul Thomas wrote:     -   Early in the Karmic cycle we should, as a test, make bubbles of     different priorities visually distinct. This will help us tell     whether we can use priority for anything tangible (e.g. dropping     lower-priority bubbles first from a backlog)

Re: [Ayatana] Debugging / aligning notification priorities with Notify OSD

Mirco Müller wrote: > So that's just a colored (green, orange, red) bar at the top with a bit > of debug-test?! If it's not more than that, it should be doable in a > half a day. > Yes, so during the cycle we can identify badly-prioritised notifications, and fix those. Mark signature.a

Re: [Ayatana] Debugging / aligning notification priorities with Notify OSD

Ted Gould wrote: > We should probably provide a way to turn this off in case an app > developer wants to run Karmic and make a screen cast of their hip new > application using notifications, we want that to look good. > +1 signature.asc Description: OpenPGP digital signature _

Re: [Ayatana] notify-osd feedback

Martin Pitt wrote: > Hello, > > just received an interesting comment about notify-osd, and some > deficiencies which come up a lot: > > > http://martinpitt.wordpress.com/2009/02/23/the-stracciatella-gnome-session/#comment-364 > > The comment right after is interesting, too :-) signature.as

Re: [Ayatana] Message Indicator message weighting

alex.la...@gmail.com wrote: > My suggested fix for this was to assign weights to the different > message types in the spec, and based on the most weighty indicator, > show a different colored dot. Currently we show green no matter what, > for the sake of argument let's assign some colors the indica

Re: [Ayatana] Message Indicator message weighting

Alex Launi wrote: > > For apps in main, specifically IM and email, we would probably > take a fairly tight view of "what should create the dot". > > > This is great for apps in main, but we can't forget about universe > just because it's not main. If apps in universe are abusing the > indic

Re: [Ayatana] Things I have noticed

Natan Yellin wrote: > How about, for starters, adding a gconf option to show an X icon on > notifications. I personally think it makes sense not to have one, but > if people want one then you should let them have it. (And normal > users, who you're trying to train to use notifications in a specific

Re: [Ayatana] Things I have noticed

Jacob Peddicord wrote: > A close button I personally don't see being useful, in the current > state of how notifications are displayed. They come and go relatively > quickly, and by the time you notice a notification to click the X it > may have already disappeared. I agree. > Actions would be the

Re: [Ayatana] Things I have noticed

Jordan Mantha wrote: > I agree with these for sure. I'm having issues with positioning > because I use the top-right of my screen a lot and I keep having > notifications "flashing" because I'm using my mouse in the area of the > notification. Bottom-right would work a lot better for me I think. >

Re: [Ayatana] Fwd: Things I have noticed

Natan Yellin wrote: > > Natan > > > -- Forwarded message -- > From: *Ryan Prior* mailto:ryanpr...@gmail.com>> > Date: Sun, May 10, 2009 at 12:58 AM > Subject: Re: [Ayatana] Things I have noticed > To: Natan Yellin mailto:aan...@gmail.com>> > > > On Sat, May 9, 2009 at 2:55 PM, Natan

Re: [Ayatana] Fwd: Things I have noticed

Nate wrote: > What if the notification bubbles started neatly in the corner, but > after a moment slid down the screen and slowly faded while it moved > down a few inches, where it would disappear? New bubbles would pop up > in the corner, but would slide down while their duration ran out. > More

Re: [Ayatana] Questions

Celeste Lyn Paul wrote: > 1) are features such as display position and display timeout part of the > notification spec, and are they handled by the notification daemon or display? > I would consider both of those to be implementation decisions, and outside the scope of the "standard". If, howev

Re: [Ayatana] Fwd: Things I have noticed

Steve Dodier wrote: Mark, do you mind explaining what you mean with an "halfway line" ? Does it mean the notifications wouldn't go in the top of the screen if there's no sync notification ? That'd be space eating in netbooks and laptops, imho. Sure, here's a picture of what I'd like us to try:

Re: [Ayatana] Notifications and user presence

Regarding click-through's: Jim Putt wrote: > (Serious question,) does anything else in the desktop behave like that? > Not yet ;-) signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : a

Re: [Ayatana] Fwd: Things I have noticed

Matt Wheeler wrote: > Do async. notifications have a maximum height? > If they do, I think a more sensible position would be max_height away > from the bottom of the screen, and then place the synchronous > notifications just above that. They do, it's 12 lines of text, and on netbooks, that would p

Re: [Ayatana] Notifications are annoying when typing in the upper right corner of a window

Scott Ritchie wrote: > That still presents the same problem if the user is typing there for > some reason. Isn't there some way the system could detect if the user > is putting text into an active edit field that the notifications would > overlap? > It's a good idea, but that's outside the cap

Re: [Ayatana] Notifications are annoying when typing in the upper right corner of a window

Celeste Lyn Paul wrote: > kwin can also know when a dropdown or context menu is open. i've been looking > into the possibility of delaying notifications which occur during these types > of interactions for n seconds. several researcher groups have found > significant > benefits for these types

Re: [Ayatana] Pidgin notifications flood on slow internet connections

Agreed - Pidgin should be smarter at telling the difference between "me logging on" and "buddy logging on". Mark signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpa

Re: [Ayatana] "Power information" notifications

Steve Dodier wrote: > I attached to this email the icons I've made for the purpose, > alongside a script that you can run and that will popup the current > and the proposed notifications. (Just extract the file to your ~ and > chmod+x the script, then run it, it'll use notify-send). Steve, you ROCK

Re: [Ayatana] "Power information" notifications

Martín Soto wrote: > Just a little comment: 15.67% doesn't say a lot more than just 15%, > which is arguably easier to read. I would round this value to the next > multiple of 5 or something. Extra points if the icon also reflects the > value, at least to some extent. +1 ! signature.asc Descripti

Re: [Ayatana] "Power information" notifications

I don't think we want the user to be able to choose. Every choice is a bug waiting to happen, and a 1,000 confused users. We should hammer at this to get it perfect, and ship it. Could you re-orient the batteries to be vertical? That would make it easier to view. You still have "*Power informati

Re: [Ayatana] [Bug 372789] Re: NotifyOSD notifications shouldn't appear when using fullscreen applications

I'd like to draw the Ayatana group's attention to bug #372789, a question about the interaction between fullscreen apps on multiple monitors and notifications. At the moment, our guidance to the developers is that fullscreen apps should block non-critical notifications. Aurelien has implemented t

Re: [Ayatana] "Power information" notifications

Charlie Kravetz wrote: >> Hey people, >> >> I attached an updated script to this email, but dailymotion doesn't >> seem to be like uploading vids today, so I had to use YouTube instead. >> >> YouTube link here : http://www.youtube.com/watch?v=fkdaiXXcv8w >> >> Cordially, SD. >> > > hmmm, How d

Re: [Ayatana] "Power information" notifications

David Siegel wrote: > This seems exactly right to me, except for one details: we should show > a different icon when you plug in your AC power, rather than the same > percentage full battery icon we would show if you were to unplug at > the same moment. When AC power is connected, the user is prima

Re: [Ayatana] "Power information" notifications

David Siegel wrote: > 1. Confirmation that the AC adapter was plugged in and the computer > is now charging (some laptops have finicky plugs). The charging emblem on the icon should show that, as should the title "*AC power*". > 2. (Maybe) how much time remains until the battery is fully charged.

Re: [Ayatana] "Power information" notifications

Steve Dodier wrote: > Alright, I'll begin cutting the icons into 10% parts. Mat, if you can > make the AC adaptator icon, it'd be great. It will take me a lot of > time to get something looking decent. Just put a zigzag emblem on top of the battery, not a separate "plug" icon please! signature.a

Re: [Ayatana] Notifications are annoying when typing in the upper right corner of a window

Steve Dodier wrote: > I dont think we'd gain much by trying to guess the behaviour of the > user, because it requires being able to imagine absolutely any > activity / behaviour (s)he can have. My HMI courses were poor but i've > been warned that it wasnt an feasible task, back then. We would alway

Re: [Ayatana] Notifications are annoying when typing in the upper right corner of a window

David Barth wrote: > Looking at the window types defined in libwnck: > > [...] > WNCK_WINDOW_SPLASHSCREEN /* splash screen */ > } WnckWindowType; > > It seems that the presence of a MENU or SPLASHSCREEN could delay > notifications a bit. I would think SPLASHSCREEN is a *perfect* time for a n

Re: [Ayatana] notify-osd + fullscreen + multiple monitors

Aurélien Gâteau wrote: > I created a patch which detects fullscreen windows and disables > notifications in this case, but it does not take the multiple monitors > case into account: it just stops notifications if there is a fullscreen > window on one of the monitors. I have two solutions: > > 1. L

Re: [Ayatana] Things I have noticed

Yes, we do intend to have a presence setting which influences the display of notification bubbles with notify-osd. Mark signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.l

Re: [Ayatana] notify-osd + fullscreen + multiple monitors

Rick Spencer wrote: > Using full screen for "the user doesn't want notifications" seems a bit > blunt to me, though perhaps would work fine in practice. Moving > notifications to a different screen seems like a lot of unpredictability > to me. > > Here are some more ideas ... I'm sure you've consid

Re: [Ayatana] notify-osd + fullscreen + multiple monitors

Steve Dodier wrote: > A last word, about indicator applet, a bit off-topic thought. Please > make sure to give each app a max amount of items to display in the > applet. It would be bad if it had to turn into those IE pop-up > blockers that end up with 400 craps that the user will not even try to >

Re: [Ayatana] Things I have noticed

ajmctaggart wrote: > Coming from Mac OS X, this was always a major gripe for me. There > would be some means to change a default behavior in the OS, but I > would have to search out forums or wait for an advance user to blog > about it. It would always be a terminal command or editing an xml > fi

Re: [Ayatana] Yip: An Unified Notification System for the Web

Jorge O. Castro wrote: > Thought it might be of interest to this list: > http://abcdefu.wordpress.com/2009/06/09/introducing-yip-an-unified-notification-system-for-the-web/ > Looks interesting. Anyone interested in giving it a libnotify backend? signature.asc Description: OpenPGP digital sign

Re: [Ayatana] Yip: An Unified Notification System for the Web

Steve Dodier wrote: > What would be the practical use of it using libnotify when we're > actually trying to get notifications to be used for system-to-user > notifications and indicator-applet used for chat/im-apps-to-user > communication ? Wouldn't it be even better to try to make this work > with

Re: [Ayatana] Yip: An Unified Notification System for the Web

Vincenzo Ciancia wrote: > Il giorno mer, 10/06/2009 alle 12.16 +0100, Mark Shuttleworth ha > scritto: > >> Jorge O. Castro wrote: >> >>> Thought it might be of interest to this list: >>> http://abcdefu.wordpress.com/2009/06/09/introducing-yip-an-

Re: [Ayatana] Plans for thunderbird and its mail notifications?

mac_v wrote: > As a user of thunderbird, i would like to know: > > 1) Does Ubuntu plan to have the thunderbird mail notifications display > via notify-osd? I would like this too, but I don't know that there's a concrete effort in place. We would consider sponsoring the Ubuntu Notify addon work if

Re: [Ayatana] [Bug 363223] Re: Notify-osd should know about lirc

I think this is referring to apport, not notify-osd. Notifications are always temporary, I think the reporter is referring to a dialog that is displayed by apport when a crash is detected on the system. If that's the case, then the title of the bug should be amended to something like "apport dial

Re: [Ayatana] [Bug 28835] Re: "Unmount" in volume right-click menu, is tech-speak and undiscoverable

Ajay wrote: > Perhaps we need "Advanced..." entry / sub-menu in the right click menu. "Advanced" menu's are sign of conceptual problems and limitations, like "Other..." menu options. They are *very* difficult for users because they say "this is hard" which is a disincentive for users to explore the

Re: [Ayatana] Interactive notifications idea

We're very interested in morphing windows, so thank you for exploring the idea! In general, morphing windows should let us deliver "simpler, clearer" user experiences, because people are confronted with just the specific information they need at any given time, and don't get lots of popup windows

Re: [Ayatana] [Bug 357150] Re: Regression vs notification-daemon: Notify-osd doesn't deal with a large number of notifications well

Given that there is another dup of the "long queue" issue, I'm cc'ing the Ayatana list. Ayatana team, for reference: https://bugs.launchpad.net/bugs/357150 https://bugs.launchpad.net/bugs/334809 MPT, can you point to a spec for the 9.10 queue throttling behaviour, that captures the ideas

[Ayatana] System / hardware indicator

Ted Gould has been a proponent of a system / hardware indicator, and I've been working on how to handle things like USB-unmount and Bluetooth-connect and am coming round to the idea. What do you guys think? If there's support for the idea, we could do a round of design work and present it here for

Re: [Ayatana] Mumbles Brings (More) Growl-Like Notifications to Linux

Vincent Arnoux wrote: > On Wed, Jun 17, 2009 at 20:50, Vincenzo Ciancia wrote: > >> Now it's hard for me to explain this in written english but, do you >> remember the time when linux users told osx users that the mac was >> featureless? And they responded it's because of usability? The student

Re: [Ayatana] One Hundred Paper Cuts -- the first ten (as sent to ubuntu-devel)

Thanks David for organizing the project like this (or at least making the organization visible to the list :-)). signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad

Re: [Ayatana] Getting users to care (was Re: [Fwd: Re: Update manager])

Vincenzo Ciancia wrote: > Are you saying that you really NEVER experienced an upgrade that creates > a problem? I use my computer to work. Sometimes I just can't afford the > risk that the thing breaks, even in minor aspects. E.g. when I am > preparing a presentation or I am under a deadline. For t

Re: [Ayatana] Getting users to care (was Re: [Fwd: Re: Update manager])

Vincenzo Ciancia wrote: > Mark Shuttleworth ha scritto: >> Vincenzo Ciancia wrote: >>> Are you saying that you really NEVER experienced an upgrade that >>> creates >>> a problem? I use my computer to work. Sometimes I just can't afford the >>> risk

Re: [Ayatana] Updates on Login

I'm just catching up on this thread, and want to help draw it to a conclusion. Updates-on-login are interesting, but I think fatally flawed because of the common requirement to reboot after updates. Updates are an irritation and interruption at any time, we must accept that. I've seen people say

Re: [Ayatana] System / hardware indicator

Scott Kitterman wrote: >> Ted Gould has been a proponent of a system / hardware indicator, and >> I've been working on how to handle things like USB-unmount and >> Bluetooth-connect and am coming round to the idea. What do you guys >> think? If there's support for the idea, we could do a round of d

Re: [Ayatana] notify-osd + fullscreen + multiple monitors

Steve Dodier wrote: > What about console-presenter and evince / other PDF viewers ? They're > used too for presentations. I don't think we can maintain an > exhaustive list of applications, so maybe we should provide the user > with a GUI to tell which apps shouldnt be overriden and in which > circ

Re: [Ayatana] Updates on Login

Alex Launi wrote: > On Sat, Jul 4, 2009 at 4:03 AM, Mark Shuttleworth <mailto:m...@ubuntu.com>> wrote: > > Updates-on-login are interesting, but I think fatally flawed > because of the common requirement to reboot after updates. > > > This is actually the ca

Re: [Ayatana] notify-osd + fullscreen + multiple monitors

Scott Kitterman wrote: > On Mon, 06 Jul 2009 05:49:16 +0100 Mark Shuttleworth > wrote: > ... > >> In this initiative, I want us to take a different approach. We will strip >> > away non-essential decisions from the user experience, at the cost of > flexibi

Re: [Ayatana] notify-osd + fullscreen + multiple monitors

What about putting up a notification when someone goes into fullscreen mode that notifications are enabled and will be displayed, as a reminder that they might want to disable them? Mark signature.asc Description: OpenPGP digital signature ___ Mailing

Re: [Ayatana] notify-osd + fullscreen + multiple monitors

Martin Owens wrote: > Hopefully you didn't mean that we'd gladdy sacrifice elegance of code > and flexibility of programming structure in order to artificially > restrict the expressed options. Which is how I read your reply at first. > Elegance? No. Options? Perhaps. Every code path needs tes

Re: [Ayatana] Recent discussions about updates : proposal to retarget the discussion

Steve Dodier wrote: > I formalized and explained them in a Wiki page [ > https://wiki.ubuntu.com/Ayatana/UpdateIssues ], that I hope to see > grow with more issues, and proposals for each of them, till we get a > complete draft of what we think should be done. I hope this attempt > will help us to

Re: [Ayatana] Question about Default Bluetooth in Ubuntu

ajmctaggart wrote: > I recently have found that using blueman instead of gnome-bluetooth > package is a MUCH better experience overall. What group or process > would have to occur to make Ubuntu's default bluetooth client switch > to blueman? Does Ubuntu or Canonical have to fork the blueman proj

Re: [Ayatana] [Bug 410220] Re: Indicator applet Always shows icon

Noel J. Bergman wrote: > Aha! And this is the nature of the bug as I see it. I do not HAVE a > message of any kind, but I still have the e-mail icon. Please switch to > some other icon when there ARE NO MESSAGES, and I'll be satisfied. > I agree, there should be no icon if it serves no use.

Re: [Ayatana] [Bug 410220] Re: Indicator applet Always shows icon

David Barth wrote: > Ted Gould wrote: >> On Mon, 2009-08-24 at 20:07 +0100, Mark Shuttleworth wrote: >> >>> Noel J. Bergman wrote: >>> >>>> Aha! And this is the nature of the bug as I see it. I do not HAVE a >>>> message of any

Re: [Ayatana] [Bug 410220] Re: Indicator applet Always shows icon

We won't ever ask anyone to right click on a menu. Ever. signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More h

Re: [Ayatana] [Bug 410220] Re: Indicator applet Always shows icon

mac_v wrote: > Context menus on menus make sense in certain locations. > For example: the Applications menu , Even though the "Add this launcher > to... " context menu is less frequent , its presence makes things more > easier. > No, this is a good example of why having the Applications menu as

Re: [Ayatana] [Bug 410220] Re: Indicator applet Always shows icon

Ted Gould wrote: > We have specified a preference dialog for the messaging menu. The > reason is for blacklisting applications. > Please unspecify said preference dialog ;-) Relevant apps installed by the user should put themselves in this menu. For default apps which are not desired by the u

Re: [Ayatana] [Bug 410220] Re: Indicator applet Always shows icon

mac_v wrote: > If drag-and-drop to start apps/drag-and-rearrange is available for all > the menu items , then and only then will it be easier . > I agree - drag and drop are also not standard experiences for menus, so using them in the launcher menu is a terrible idea. Mark signature.asc Des

Re: [Ayatana] [Bug 410220] Re: Indicator applet Always shows icon

Scott Kitterman wrote: > And also best that these apps not require configuration prior to gaining > access to the preference (e.g. the Evolution example given earlier). > Requiring users to set up applications in order to not be bothered by them > in the menu is not a usability win. > +1 and

Re: [Ayatana] New notification placement

Thanks all for comments, bouquets and brickbats. We're experimenting with different layouts and positions, and the feedback helps. It helps more if it doesn't come dripping with sarcasm ;-). We'll let the no-fade-when-mouse-is-there behaviour bake for a while before making any further changes. M

Re: [Ayatana] New notification placement

Mirco Müller wrote: > Am Freitag, den 28.08.2009, 09:30 +0100 schrieb Mark Shuttleworth: > > >> ... >> Mirco, is there any way to know, when the notification appears, how >> long the mouse has been stationary? >> > > Yes, that should be doable.

Re: [Ayatana] New notification placement

David Barth wrote: > However, using the XScreenSaver extension, the X server is maintaining > this information for us, so that we can track the idle time, without > doing any polling, in particular when no notification is on display. Yes, this gives us a binary "it has moved" or "it has been idle"

Re: [Ayatana] Notify OSD: Talk about giving the user preferences

Luke Benstead wrote: > I've just seen this: > > "notify-osd (0.9.20-0ubuntu1) karmic; urgency=low > > * New upstream version: > - added support for integer gconf-key "/apps/notify-osd/gravity" > - supported values are 1 (NorthEast, top-right) and 2 (East, > vertically centered at right of

Re: [Ayatana] Minor Indicator-Applet detail which can be addressed by Karmic?

mac_v wrote: > So, if i-a recognizes the unread mail remaining in the folders and > displays the "new" count , *only* in the drop-down menu, > users would know that they still have N unread mail in folder X by just > viewing the drop-down menu. > It's an interesting idea to have a "new" visual

Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on

Juha Siltala wrote: > -original message- > Subject: Re: [Ayatana] Message Indicator: Listing apps in menu even if they > are not on > From: Ted Gould > Date: 03.09.2009 17:24 > > as it's nearly impossible to determine "the mail application I use" > except by what's installed. > --- > Is this true

Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on

Celeste Lyn Paul wrote: > Hello all, > > According to the MessagingMenu spec, registered message applications > will always be listed in the menu regardless if it is running or not > [1]; however, there is no explanation or justification for doing this. > > My question is: Why? To what purpose are

Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on

Stuart Langridge wrote: > Am I missing something here? If Pidgin's not running then by definition > I can't have any messages in it. Is the messaging menu just another > applications menu but only containing apps which are capable of > generating messages? That seems not all that useful to me, unle

Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on

Roderick B. Greening wrote: > Not in my opinion... if it's for "indications/messages" then it has no right > to pretend to be anything other than that (i.e. a menu). Trying to be a menu, > seems counterintuitive to me. We already have a menu, and presenting the user > with two places to look...

Re: [Ayatana] Fwd: Message Indicator: Listing apps in menu even if they are not on

Celeste Lyn Paul wrote: > Is that the purpose of the MI though? To be the one-stop-shop for > *all* messaging issues? I'm under the impression that it is only > supposed to handle incoming and missed messages, *not* be a messaging > dashboard. If it *is* a messaging "dashboard" then the documentati

Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on

Taking this thread up again after two weeks vacation, sorry if there's been a resolution in another thread already. Celeste Lyn Paul wrote: > Currently this how I would expect it to work: The message indicator > will indicate if there is a message there. If there are no messages, > there is no in

Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on

mac_v wrote: > But rather wanted to say, the product is still in development cycle. > When a product is in *development cycle* it is reasonable to find > several changes in the apps almost every day. > > We cant keep constantly banding the doors for an answer which might > change at anytime during

Re: [Ayatana] [Bug 428509] [NEW] Do not suppress async notifications when using fullscreen apps

Mirco Müller wrote: > DEBUG=1 /usr/lib/notify-osd/notify-osd > Didn't we agree to run it in this mode during the Karmic dev cycle? So that we could be sure notifications weren't being sent with spuriously high urgency? I think it's too late to do it now, we are post-beta. Did we do any

Re: [Ayatana] Question about Bug Reporting Tools in Ubuntu, from a design perspective...

ajmctaggart wrote: > My question is this, why do we need to login to Launchpad through our > web browser to report these bugs? I feel it is extremely disruptive, > especially when something non-essential crashes and Ubuntu asks if I'd > like to file a bug. Of course I'd like to file a bug! That'

Re: [Ayatana] Question about Bug Reporting Tools in Ubuntu, from a design perspective...

These are *awesome* ideas, Alex. Alex Lourie wrote: > I think that I am going different route than intended, but should such > integration end with bug submissions? What about asking questions with > sort of a GUI interface to Launchpad Answers directly without a browser? Ideally, LP would be int

Re: [Ayatana] Question about Bug Reporting Tools in Ubuntu, from a design perspective...

ajmctaggart wrote: > So, right now we have the "crash report detected" in Notifications > area user clicks, > Moves to Kernel Problem Window (In my case) > User decides to report > Moves to Apport to collect data > User Can now either have already input Launchpad credentials into > System>Preferenc

Re: [Ayatana] Question about Bug Reporting Tools in Ubuntu, from a design perspective...

ajmctaggart wrote: > Poking around at leonov.tv I believe what we would > require from Leonov would be very small in terms of the scope of his > original project. > > The other point is that Mark did say an API would be coming out. > Leonov was around even before Launchpad's op

Re: [Ayatana] Question about Bug Reporting Tools in Ubuntu, from a design perspective...

Alex Lourie wrote: > While this would be a sort of heaven on Earth to see this in an IDE, I > think that Answers are still much more user-oriented, than developers > oriented. Good point. > I imagine this as something in lines of: > I click on some sort of "Ask a question" icon/button/link, and ge

Re: [Ayatana] Question about Bug Reporting Tools in Ubuntu, from a design perspective...

Natan Yellin wrote: > What about making Launchpad an OpenID consumer > (https://bugs.launchpad.net/canonical-identity-provider/+bug/210943) > and providing a "Login using a Gmail account" button. (Because many > people don't realize that Gmail is an OpenID provider.) Yes, that will happen too. It'

Re: [Ayatana] Notification consistency

Sorry for taking ages to catch up on this thread. I've snipped a long piece where Jim describes the MI as a generic "respond to notifications" mechanism. Jim Rorie wrote: > Pros: This would provide interactivity through lib notify and quiet a chief > complaint. Users would not be challenged to r

Re: [Ayatana] Notification consistency

Jim Rorie wrote: > On Fri, 2009-10-09 at 18:39 +0100, Mark Shuttleworth wrote: > >> To the extent that the things which need responding to really are >> messages, this is appropriate. >> > > What do you feel would be an example of something that wasn't

[Ayatana] Collaborative design dilemma

This will be a controversial mail, so I'll ask in advance that we not let it get heated. I don't think we can succeed if we work on a list that is free for everyone to throw their ideas onto. I'm thinking that we need to create an invitation-only list (which is publicly archived) alongside this o

Re: [Ayatana] Collaborative design dilemma

Fabian A. Scherschel wrote: > - Still provide a means for people not on the "inner circle" invite > list to give input Of course, that would happen through a list in which anyone who wanted to join was welcome (this would also be a good place to find additional people to invite to the core list). >

Re: [Ayatana] MI idea suggestion

Andrew SB wrote: > One issue I've had with the MI applet is that in its current state it > misses one of the largest messaging use cases, webmail. > I know there's a gmail-notifier around, does it talk MI? If not, who's up for helping it do that in Lucid? signature.asc Description: OpenPGP di

Re: [Ayatana] MI idea suggestion

Nice, both. Looking forward to seeing that land in Lucid. Are either of you in position to drive it all the way through (to universe at least, preferably main)? signature.asc Description: OpenPGP digital signature ___ Mailing list: https://launchpad.ne

Re: [Ayatana] Collaborative design dilemma

I think it's a great idea to integrate this into the existing Ubuntu structure. I like the idea of having a structure that mimics what we have in place in other areas of participation in the project - with a leadership team, and members who have "crossed the threshold", and others free to contribu

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

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

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

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.

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

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 i

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

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

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

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". >>

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

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.

Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala

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

Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on

Jeremy Nickurak wrote: > So, what is the indication that "the thing is not running"? It took me > months to find out that, just because Evolution showed up in the > messaging menu, it didn't mean that part of evolution was running and > checking for new messages. That I had to open the evolution UI

Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on

Alex Launi wrote: > On Thu, Nov 5, 2009 at 1:42 PM, Mark Shuttleworth <mailto:m...@ubuntu.com>> wrote: > > In the design discussions, there was supposed to be a difference > between the menu entries when the application is running, and when > it is not

Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on

Scott E. Armitage wrote: > > I disagree. If the menu options clearly invite you to DTRT, then > you shouldn't have to worry about things like "the process is > running". You click on the menu, you start watching email, you get > notifications, you jump to your relevant email folder.

Re: [Ayatana] Message Indicator: Listing apps in menu even if they are not on

Martin Albisetti wrote: > Yes, this may be a good idea so we can guarantee a certain level of > sanity with our default applications (or the ones we have in our repos). The current discussions I had with MPT about a related matter panned out roughly like this: - the main, default apps should be h

  1   2   3   4   >