Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala
> 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 fair (I know, it was I who first compared to IM :p ) Both IM and IRC have a major difference in that the scrolling text is from multiple sources (users) whereas notification bubbles come from one source. Context switching like this will obviously take longer to read than text from a single source. Also, the sheer quantity of text to read in both IM and IRC is far more than your typical notification bubble. 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). I'm not convinced that text scrolling up in the notification bubbles will actually cause a problem. > 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 scrolling text. > - Place the sync bubbles to be in the lower center. At the same height > as the async bubbles but centered. [Similar to where the upstream > volume/brightness notifications are placed] > > -OR- > > - Revert back to the dynamic positioning of the bubbles and place the > bubbles in the lower right at the height assuming for 10 lines of text. > > > > Then again we might get complaints that the bubbles are not exactly in > the corner... ;) > I think either of those solutions could work. The point of my original suggestion was that positioning at the bottom of the screen (where there are usually fewer screen elements) should not be ruled out just because the async bubbles will extend. I actually think Johan's mockups look pretty nice :) Luke. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding Flash like demonstrations
2009/10/21 Martin Owens : > On Wed, 2009-10-21 at 18:46 +0100, Luke Benstead wrote: >> >> Err.. ok... anyone any good with Flash? Or could someone point me at >> an OSS app that makes Flash animations? > > The only thing close enough would be to hack some SVG using Inkscape and > a text editor, add on the FakeSmile javascript library for firefox > compatibility and you might be able to do a demo. > > http://doctormo.wordpress.com/2009/06/22/svg-animations-just-like-flash/ > > http://doctormo.wordpress.com/2009/05/20/who-needs-flash-i-dont-svg-for-me/ > > At least with a bit of practice you could pull off something interesting > which can be viewed in a browser. Although we don't as of yet have a > library to export frames for compilation into videos. > > Regards, Martin > > Thanks, those links are really useful! Luke. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding Notify-OSD's Position in Karmic Koala
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 going to increase > https://bugs.launchpad.net/notify-osd/+bug/336110 The ideal width has been identified and is being used atm. With scrolling what we also need to consider are , the accessibility issues. Not everyone can read at the same speed nor does everyone have good eye co-ordination.[younger individuals can accommodate easier when the lines jump, but with age this becomes difficult... similarly with folks not fluent with the language , they would find it hard to find the words they were reading once the lines jump.] So the smooth scrolling , needs to be slow enough to not allow the lines to jump and fast enough to not cause the bubbles to stay too long. This would again need a lot more work/fiddling/testing to identify the ideal scrolling speed. As mentioned earlier ,its easy to throw in an idea ;) > > 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 scrolling text. > > - Place the sync bubbles to be in the lower center. At the same height > > as the async bubbles but centered. [Similar to where the upstream > > volume/brightness notifications are placed] > > > > -OR- > > > > - Revert back to the dynamic positioning of the bubbles and place the > > bubbles in the lower right at the height assuming for 10 lines of text. > > > > > > > > Then again we might get complaints that the bubbles are not exactly in > > the corner... ;) > > > > I think either of those solutions could work. What i had suggested was with minimal tweak to the notify-osd, by just adjusting the position of the notifications. > The point of my original > suggestion was that positioning at the bottom of the screen (where > there are usually fewer screen elements) should not be ruled out just > because the async bubbles will extend. I actually think Johan's > mockups look pretty nice :) > > Luke. The lower position has been suggested earlier too, but it was not used. *iirc* it was due to the async bubbles, the append feature being tough to implement when positioned below and making them grow upwards. I too would like to have such a bubble, if the text scrolls smoothly without jerks and is readable by all. [it really does sound great, if done right] :) -- Cheers, mac_v ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana] Regarding indicator-applet's behavior of running programs.
Hello, this bug report describes what I am trying to bring to attention: (https://bugs.launchpad.net/indicator-applet/+bug/438534) I don't see any point in discussing how to close the programs at this point, I only feel that it would be of benefit to point out that the behavior should be constant. Currently, Evolution cannot 'minimize' to the applet. Closing it quits the program. Everything else is impossible to quit without "File>Quit"-ting. It's all a little confusing at the moment. Thanks for your time. -- -Brett Cornwall ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding indicator-applet's behavior of running programs.
Currently, in Karmic I have three applications in the indicator-applet: empathy, evolution and gwibber. The close button behavior is different for each one: 1) In empathy, the close button only hides the window. 2) In gwibber, the close button closes the gui, but the daemon stays open. 3) In evolution, the program is completely closed. The solution I personally use to keep things acceptably consistent is to minimize instead of closing. However, this doesn't bother me because I use a dock and therefore the apps are minimized to its launchers. I can imagine that someone who uses the regular Gnome window list would be very annoyed by three non-used apps in the taskbar all the time. In fact, even for me the current situation is sub-optimal because it's redundant: I'd prefer launch the three apps only through the indicator-applet and remove their launchers from my dock. In my opinion, the best option would be to implement close-to-tray in all three, but as far as I know evolution devs are against it and patching things directly against the upstream direction is not a good idea in the long run. Nevertheless, despite which behavior is the correct one, I firmly believe that it should be consistent among all three. _ Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail®. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Regarding indicator-applet's behavior of running programs.
On Thu, 2009-10-22 at 19:08 +0200, Tony Knott wrote: > Currently, in Karmic I have three applications in the > indicator-applet: empathy, > evolution and gwibber. The close button behavior is different for each > one: > > 1) In empathy, the close button only hides the window. > > 2) In gwibber, the close button closes the gui, but the daemon stays > open. > > 3) In evolution, the program is completely closed. > > The solution I personally use to keep things acceptably consistent is > to minimize > instead of closing. However, this doesn't bother me because I use a > dock and > therefore the apps are minimized to its launchers. I can imagine that > someone > who uses the regular Gnome window list would be very annoyed by three > non-used > apps in the taskbar all the time. > > In fact, even for me the current situation is sub-optimal because it's > redundant: > I'd prefer launch the three apps only through the indicator-applet and > remove their > launchers from my dock. > > In my opinion, the best option would be to implement close-to-tray in > all three, > but as far as I know evolution devs are against it and patching things > directly > against the upstream direction is not a good idea in the long run. > > Nevertheless, despite which behavior is the correct one, I firmly > believe that > it should be consistent among all three. This is one of the unresolved issues > https://wiki.ubuntu.com/MessagingMenu#Unresolved%20issues The minimize to the messaging menu is something which hasnt been done yet , for all the apps. I believe we might get it for evolution too , for Lucid :) Not sure if there is already a bug filed in the evolution-indicator , for this though. -- Cheers, mac_v ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
