from:"David"

Steve, please use a bzr branch on launchpad instead of sending tarball 
iterations to the list.


David

Steve Dodier wrote:

Hello,

I tweaked the icons a little with the help of macvr. Attached the new 
(and, I hope, final) icons.



___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp



___
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] notify-osd + fullscreen + multiple monitors


Aurélien Gâteau wrote:

Hi list,

I am working on bug 372789 "NotifyOSD notifications shouldn't appear
when using fullscreen applications".
https://bugs.launchpad.net/bugs/372789

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. Leave it as it is
2. Try to find a monitor without fullscreen windows and show the
notification there

What do you think is the best solution for this?

Aurélien

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp
  
Aurélien, can you provide or link to a list of applications that have a 
fullscreen mode? This will help us reason about user scenarios.


Let's put full screen apps here:
https://wiki.ubuntu.com/FullScreenApplications

David

___
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] notify-osd + fullscreen + multiple monitors


Vadim Peretokin wrote:
Any application can be made fullscreen via the "Toggle fullscreen 
mode" in Gnome. I'm guessing you'd like a list of the practical ones.

Good guess.

David

PS: Can I fullscreen Nautilus?

___
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] Things I have noticed


Brian Curtis wrote:

On Thu, Jun 4, 2009 at 12:41 PM, mac_v  wrote:
  

Mark

+1 ,
hate to click the x to dismiss!

but there needs to be a way to dismiss the notify-osd , in case the bubbles
are a disturbance to workflow.



What about just clicking the bubble?  Or is this too close to a "click
the x" approach?

~Brian

  
You cannot click on the bubbles, there is no concept of bubble clicking. 
Clicks go through them.


David

___
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] notify-osd + fullscreen + multiple monitors


Aurélien Gâteau wrote:

Hi list,

I am working on bug 372789 "NotifyOSD notifications shouldn't appear
when using fullscreen applications".
https://bugs.launchpad.net/bugs/372789

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. Leave it as it is
2. Try to find a monitor without fullscreen windows and show the
notification there

What do you think is the best solution for this?

Aurélien

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp
  


Here is the list of fullscreen applications we've come up with on the 
wiki so far:


   * Games
   * Firefox + firefox flash videos
   *

 OpenOffice <https://wiki.ubuntu.com/OpenOffice> Impress

   * Totem, VLC, and other movie players
   *

 MonoDevelop <https://wiki.ubuntu.com/MonoDevelop> and other IDEs

   *

 OpenOffice <https://wiki.ubuntu.com/OpenOffice> Writer (has a nice
 fullscreen mode!)

   * GIMP
   * Image viewer , picasa slideshows
   * Remote Desktop Clients
   * Skype Video Chat, and other video chat applications

Personally, I would want notifications more often than not when 
fullscreen-ed in games, while browsing in Firefox, while watching any 
movie shorter than an hour in length, while programming in an IDE like 
MonoDevelop, while working in OpenOffice writer on my netbook, while 
editing photos in GIMP, while viewing a remote desktop, and while 
conducting personal skype video calls.


Whether my preferences match yours perfectly is not the point, so lets 
not argue each case individually. I hope we can agree that fullscreen 
mode does not imply that the user wishes notifications to be blocked; it 
does not even imply that "low-priority" notifications should not be shown.


On the other hand, we can agree that OpenOffice Impress in presentation 
mode is a very special case, and that if we had to pick a default 
behavior for notify-osd during a presentation, it would be more 
reasonable to turn notifications off than to leave them on.


So, can applications be given a say in this? Or can we create a 
blacklist? Would a default blacklist, with per-application notify-osd 
control for the user be a good option?


David

___
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] Things I have noticed




mac_v wrote:

Jacob Peddicord wrote:

Wouldn't the proper way to remedy this would be to close communication
applications during a presentation? I won't disagree that disabling
notifications for a time would be useful, but if you don't want Pidgin
triggering notifications for a presentation, then close Pidgin.


so the user has to compromise? ! this is not a solution!

the user might be online with an important work user during the meeting
giving updates , but since he might be disturbed by personal buddy
message he has to triage his work/friends and create separate accounts
just because the system wont allow easy ways to close the notifications?

or a simpler way might be disable all messages? as someone said not all
the presentations are fullscreen presentations.

this is a problem not necessarily disturbance during a presentation, but
during any system usage, imagine the a *co-worker popping by* and is
checking ur work , does he need to be notified too of ur personal mails?!

*this system is just an embarrassment waiting to happen for the user* !


We definitely want two things:

1. Provide a reasonable default configuration that will make most people happy 
most of the time.


2. Provide a way for the user to explicitly block and unblock most if not all 
notifications to prevent embarrassment. Even if we are perfectly prescient and 
block all embarrassing notifications at just the right times, the user will 
still have an uneasy feeling if the blocking is not somehow made explicit, 
either by requiring user interaction, or displaying some sort of persistent 
"notifications are blocked" icon.


David



so now ,is the solution never to have an im/email client open?

i would say the presence of a easy close, would be a welcome solution.

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


___
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] notify-osd shows as one of Ubuntu's "papercuts"

2009-06-11 Thread David Siegel


ajmctaggart wrote:

I think this has been solved...

http://blog.davebsd.com/2009/06/10/one-hundred-paper-cuts/comment-page-1/#comment-31385


Width of notifications seem arbitrarily small
<https://bugs.edge.launchpad.net/hundredpapercuts/+bug/336110>
notify-osd bubbles can display about three words before line
wrapping occurs. Making these bubbles slightly wider will
decrease strain on your eyes when reading them, and will allow
you to read short messages more quickly.


I believe David Siegel is a member of this team, correct?  David, does 
the "papercut," indeed still exist? Or can we chalk this one up as fixed?


Thanks,
Anthony
  


The  bug is reported and confirmed, but it is still a paper cut that we 
plan to fix for Karmic. It is very visible and we have committed to fix 
it, but that doesn't make it not a paper cut. What is your concern?


David




___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp
  



___
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] notify-osd shows as one of Ubuntu's "papercuts"

2009-06-11 Thread David Siegel

The bug is definitely not fixed yet! I mostly picked it as an example paper cut, 
because it's so simple to fix (I've patched it in my own branch) and we're sure 
to fix it for Karmic.


If you do find a paper cut that you are able to verify as fixed, please update 
the bug report.


Thank you,
David

ajmctaggart wrote:
No concern, just happened to see it on the Planet.  I really like the 
idea of the "paper cuts," and was simply reading your most recent post 
on it.  When I went to look at the bug, perhaps I don't read the bugs 
correctly, but it looked to me as if the bug were fixed.  Sorry for any 
confusion if it is still a papercut.

-Anthony

On Thu, Jun 11, 2009 at 8:06 AM, David Siegel 
mailto:david.sie...@canonical.com>> wrote:


ajmctaggart wrote:

I think this has been solved...


http://blog.davebsd.com/2009/06/10/one-hundred-paper-cuts/comment-page-1/#comment-31385


   Width of notifications seem arbitrarily small
   <https://bugs.edge.launchpad.net/hundredpapercuts/+bug/336110>

   notify-osd bubbles can display about three words before line
   wrapping occurs. Making these bubbles slightly wider will
   decrease strain on your eyes when reading them, and will
allow
   you to read short messages more quickly.


I believe David Siegel is a member of this team, correct?
 David, does the "papercut," indeed still exist? Or can we chalk
this one up as fixed?

Thanks,
Anthony
 



The  bug is reported and confirmed, but it is still a paper cut that
we plan to fix for Karmic. It is very visible and we have committed
to fix it, but that doesn't make it not a paper cut. What is your
concern?

David



___
Mailing list: https://launchpad.net/~ayatana
<https://launchpad.net/%7Eayatana>
Post to : ayatana@lists.launchpad.net
<mailto:ayatana@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~ayatana
<https://launchpad.net/%7Eayatana>
More help   : https://help.launchpad.net/ListHelp
 






___
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] Updates on Login (was: Re: [Fwd: Update manager])

2009-06-16 Thread David Siegel


Alex Launi wrote:
I figured I should start a new thread for this, so that you can all 
continue your icon vs. pop-under debate, which is still relevant for 
the auto-login case, although it becomes much less important. I've 
copied and pasted the relevant posts from the previous thread into 
this one. Have at it.


===

On Tue, Jun 16, 2009 at 3:45 PM, Alex Launi <mailto:alex.la...@gmail.com>> wrote:
I had meant to chat with Martin Pitt after his plenary, but never 
managed to catch up with him. I forgot about it until I was going 
through my notebook the other day. It would be really great if when 
update-manager presented itself, some bugs (ones that you 
reported/subscribed to on LP) had a nice messsage that made you really 
excited to update because your bug was fixed! Make updates fun!


David Siegel also had a really great idea for making updates fun (and 
it also solves the issue of how to handle updates- notification icon 
or pop-under window) at the "install updates on shutdown" discussion. 
Let me preface this with these are his ideas and not mine, I think 
they're great and he deserves the credit. His idea was to do updates 
at login. We could do the checking while you're using, and then if we 
find them on reboot show them in gdm with a nice present icon, like 
we're giving you a gift. This way if an update requires a restart, you 
don't have to save your state, restart, blah blah blah and interrupt 
your entire workflow, you haven't started yet. It might not be 
possible now, but when the clutter gdm finally lands we could do it 
really beautifully.


--
-- Alex Launi

On Tue, Jun 16, 2009 at 5:06 PM, tacone <mailto:tac...@gmail.com>> wrote:

Good intent, bad idea.
When you turn on the pc it's because you needed. Windows shows the
update notification on shutdown, which makes much more sense (and if
you just installed some reboot requiring update, even more).

I wouldn't oppose to a well done, good designed entry on shutdown:


Updates available !  Keeping your system up to date is important.
[x] Install the updates before logging out. [ Open the update manager ]
-

Stefano

On Tue, Jun 16, 2009 at 6:09 PM, Alex Launi <mailto:alex.la...@gmail.com>> wrote:
On Tue, Jun 16, 2009 at 5:06 PM, tacone <mailto:tac...@gmail.com>> wrote:


Good intent, bad idea.


I disagree, let's imagine this scenario, together...


It's Tuesday morning, you get up and turn on your computer. Whilst you 
were fast asleep dreaming of sugar plums and sexy librarians Ubuntu 
packagers were hard at work packaging updates for your favourite 
operating system. Now that it's morning, these updates are available, 
for you! You boot up and arrive at the slick new GDM. But what's this 
message?


"New updates available! Click here to install"

Some days you're very busy, and need your computer right away so you 
chose to ignore them and log right in. That's ok, they'll be available 
when you're ready. Update Manager shouldn't go away, you should be 
able to launch it yourself manually if you want to update once you've 
logged in and found out that DST was this weekend and you've got some 
extra time.


But today you decide to click. The interface changes nicely into a 
screen displaying what updates are available, and asking for your 
username and password to authorize install / log in. If you're not an 
administrator we will politely tell you that you can't perform an 
upgrade, and that you should let your administrator know that your 
system needs some updates. At this point we just finish the login, 
since you just gave us your info. Awesome.


Now let's say you are an admin, this update requires no reboot so we 
log you right in, and when the desktop is loaded there is already a 
dialog waiting giving you the progress of your update. You may 
continue working, you weren't cost much time, and your system is fully 
secure because you're up to date.


But next time there might be a kernel upgrade, which will require a 
restart. In this case we should ask the user what they'd like to do. 
In some cases the estimated time to finish (which we will show) may 
only be 2 minutes, and we can afford that so we just halt the login 
and modally install the upgrades, or we allow them to say "ok i 
recognize that this update will need a restart to apply, but I need my 
computer- so lets continue like there are no updates that require a 
reboot, and I will reboot when I'm ready.




Awesome, right?

--
--Alex Launi

On Tue, Jun 16, 2009 at 6:14 PM, Charlie Kravetz 
mailto:c...@teamcharliesangels.com>> wrote:

What about those who use an autologin? They will never see those gdm
screens.

--
Charlie Kravetz
Linux Registered User Number 425914

Re: [Ayatana] Updates on Login

I think it would be interesting if the user must wait at GDM for updates 
to finish (assuming they were downloaded previously), and is only 
allowed to log in when updates have finished. This process only takes a 
minute or two, and the user can choose to not initiate the updates or 
cancel them and log in at any point.

David

Alex Launi wrote:
On Wed, Jun 17, 2009 at 12:51 AM, mac_v <mailto:drkv...@yahoo.com>> wrote:

First of all you painted a story saying:
devs had update ready in the night and the user got the update in the
morning! That is misleading !

It was supposed to be an allusion to some kind magic entity like god, 
Santa Claus, or the easter bunny. I'm sorry if you're a non-native 
speaker and read that literally. I didn't consider that some people 
wouldn't get humour, and mistake my jokes for proposals. The story was 
supposed to be playful.

BUT assuming that the update state was checked before:
1: Why wait? What is the advantage in deferring the update?

Because we have a problem with how updates are presented. We need to 
find a way that makes updates not a chore but a fun task and makes 
sure the user ACTUALLY installs them, rather than just ignoring a 
notification icon.

2: Why defer a security update to the next boot?

Why defer it for 2 weeks while the icon sits idle. For high priority 
updates we may want a mechanism to update the user, this is ok in this 
case because it's not a normal update, it's high priority and must be 
addressed now. This is similar to the actionable notification debate.

3: What about users who do not shutdown the systems? no updates
for them?

Theyre essentially the same as the autologin people, we say "have 
updates been here for  days, now we need to show a window because 
they havent been to a login screen

4: What if the [non-security]update to a program is deferred to
the next
boot and the program crashes, causing work loss?

What? This isn't a real case. The bug causing the crash existed before 
the update was available, the user already know this app is buggy. Or, 
the user hasn't ever experience the bug before and may not suffer from 
it at all. It's possible the bug might strike in the day before 
installing the patch, but it more likely would have already happened 
or isn't going to happen. So basically this potentially /prevents/ 
issues. Currently if you update firefox, a lot of stuff in XUL breaks 
due to its lazy loadig

If the propsal for the above is that the system waits [x hrs/days]
before reminding the user of the update.

Do you mean notifiying updates havent been installed or something? Or 
Is this a follow up to 4. If it's a follow up to for you can skip the 
follow ups with a "im not going to answer because 4 made no sense".

5: what is the use of having updates scheduled for boot?

To help ensure they actually install updates.

6: what is the acceptable time limit to defer an update?[the
update may
be critical to the program the user needs, which has been crashing,
would the user want this update immediately?]

This is irrelevant to the discussion and is an implementation detail.

>
> You DO get on with your work, you just start the update process
first,
> and then move on.
>

What you need to remember is that work may involve net browsing, so
speeds are hampered during the work. The user might mot have
planned on
using the net , but needs to browse for research , so his only
option is
to cancel the on going update?

 also if the user is allowed to work and it prompts for reboot, isnt
that a break in work flow? he may choose to do it later , but the main
purpose of the proposal does not achieve its goal .

This is what we do now so this isn't actually a regression. If you 
read story (for what, the 3rd time?) you'll see that the user is 
NOTIFIED that this update will require a reboot. So the user is 
already aware that in a short time theyll be aksed to reboot, they can 
chose to wait and go make some tea or proceed with the knowledge that 
a reboot will be necessary soon.

--
--Alex Launi

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp

___
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] Updates on Login (was: Re: [Fwd: Update manager])


tacone wrote:

We should definitely consider as many update scenarios as possible in order
to find the one that users will prefer. We are very quick to start
implementing updates and shut down without considering something radically
different because many of us have experiences updates at shutdown when using
Windows. Neither solution is perfect, both have their merits, and this is
the perfect place to discuss them.



May I ask which merits may the Updates-at-login-time have ?

It's not that Windows is perfect, but some times there's a rationale
behind the choices done by it. (and, btw, I hated the way Windows
tried to trick you into upgrading at shutdown)

The drawbacks of updates in GDM are many:
- some people auto login, they won't see anything (not big issue, but
also not nice)
- perceived bigger lag between power on  and operability (due to the
need to perform a choice)
- being reminded to reboot right after having just powered on is not nice.
- increased delta with Gnome and possible loss of compatibility with
existing GDM themes
- increases the workload startup (while the updates are being
performed), in a timeframe when there's already load (as the gnome
desktop is loading, and the first applications you'll launch will
load).

I don't think we really need to "think different" at all costs.

Stefano
  

Tacone,

People who auto-login or never restart can be handled differently. 
Personally, I auto-login, so I would not use this feature, but let's not 
think of gurus like us, who participate on Linux mailing lists, and 
let's think instead about the average user, who might be made 
uncomfortable by computers in general, and may be nervous about their 
first venture into Linux.


The core of the idea is, at the face browser, there is a present icon 
when you have updates already downloaded and ready to install. They 
might even be unpacked already. Beside the present is a simple 
description like "13 updates available, requires restart. Click to 
update." The user either logs in as usual, ignoring the icon (maybe it's 
at the bottom/corner of GDM), or clicks the present. Clicking the 
present prompts for a password, and then shows an elegant progress bar, 
installing the updates. If the updates required a restart, the machine 
simply restarts, and our new 10 second boot time brings the machine back 
up before the user even notices it's restarting. We don't have to 
confirm shutdown, because nobody is logged in. Then, the user logs in to 
her newly updated desktop.


There are drawbacks to this approach, sure, but do you honestly not see 
any merit? I think it delivers a much more pleasant experience than 
asking the user at shutdown. At GDM, the user is not in a hurry, and 
they can take a moment to decide if they would like to update or not. 
Asking the user to update at shutdown feels like a rushed decision; the 
machine is shutting down, and you have a brief moment to either opt-in 
or opt-out of updates.


David

___
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] Updates on Login


Paulo J. S. Silva wrote:
2009/6/17 David Siegel <mailto:david.sie...@canonical.com>>


I think it would be interesting if the user must wait at GDM for
updates to finish (assuming they were downloaded previously), and
is only allowed to log in when updates have finished. This process
only takes a minute or two, and the user can choose to not
initiate the updates or cancel them and log in at any point.

David


Are you kidding?

Wouldn't it be much more reasonable to do this at shutdown (or logout 
for users that don't shutdown). When I login, I want to my stuff. When 
I logout I am saying: "I'm done for know". Imagine that you are 
leaving home, a little late, and decide to look for a map in google 
maps. Wife and kids are already in the car. The you scream from the 
office "Dear, will have to wait for five minutes more because Ubuntu 
is forcing me to update now!"


The updates are complete opt-in. You just don't click to begin them if 
you don't have time for them. They don't begin automatically, they don't 
even ask you to initiate them. They just sit in the corner, and you 
click on them, or you don't. If the wife and kids are waiting, don't 
click on them.




Actually the whole concept of updates at login sounds very weird to 
me, for exact the same reason I described above. I can leave home 
while the computer is udpating itself (and shutting down)...


Paulo


___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp
  



___
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] Updates on Login


Vadim Peretokin wrote:
I'll second this. In my use-case, my mother /really/ hates doing 
updates (only does them after a while, and hates the orange icon - I 
suppose that'll improve with an upgrade to jaunty). Forcing her to 
wait for updates after she turns on the computer for something would 
really be backwards.


Nevermind that it takes away control from the user and instead of 
spoon-feeding, it force-feeds them.


Vadim, check out my last email. When we discuss these things, it's best 
to give each suggestion the benefit of the doubt so we don't 
accidentally attribute invented flaws to good ideas.


When you turn on your computer, you are engaging with it, signaling that 
you have time and attention to give to the machine.


When you turn off your computer, are are disengaging with it, signaling 
that you need to go do something else and not use the machine any more. 
The "Set it and forget it" mentality of updates at shutdown is actually 
a very advanced user behavior, and does not work well for anyone, even 
advanced users, on portable computers.


David




___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp
  



___
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] Updates on Login (was: Re: [Fwd: Update manager])

My roll on the Canonical Design and User Experience team is to make Ubuntu the 
most enjoyable to use operating system in the world, so I hope you can forgive 
me for making "[it offers a] more pleasant experience" the main thrust of my 
argument.


I am not decidedly in favor of updates at GDM over updates at any other point in 
time. I am just trying to get us to think more broadly about solutions to the 
update problem, and not to jump to premature conclusions.


I can offer other arguable points of merit for updates at GDM:

(1) (This is completely subjective, but my personal experience does include the 
experiences of others, and is valid in itself) I often feel less rushed and 
stressed when booting my computer as opposed to shutting it down. When I log in, 
I wait for applications to load, my mail to download, my music player to start, 
etc. When I shutdown, I currently enjoy the luxury that my computer turns off 
immediately with no fuss; currently, shutdown does not involve waiting.


(2) Think of portable computer users (laptops and netbooks). They nearly always 
have more battery available at boot than at shutdown. In fact, many users shut 
their laptops down *only* when they are forced to due so due to an empty 
battery. We never want to initiate updates on insufficient power.


(3) Smaller cognitive burden. Think about the worker. At the start of the day, 
you boot your machine, grab some coffee, and return to your machine. At the end 
of the day, you just want to leave the office! Even if you knew you could leave 
something running on your machine and go home, it still might cause a lingering 
uncertainty (did it ask me for confirmation? Was there an error? Is my computer 
still on right now? Is it logged in?!)


Most of us would be perfectly comfortable initiating an update on shutdown, and 
walking away from our machine, but I'm not sure if less sophisticated users are 
similarly comfortable behaving this way.


Also, more and more devices running Ubuntu will be laptops and netbooks. We may 
want to focus more on those use cases, and less on the use case of a sedentary 
desktop.



David

tacone wrote:

People who auto-login or never restart can be handled differently.
Personally, I auto-login, so I would not use this feature, but let's not
think of gurus like us, who participate on Linux mailing lists, and let's
think instead about the average user, who might be made uncomfortable by
computers in general, and may be nervous about their first venture into
Linux.




The core of the idea is, at the face browser, there is a present icon when
you have updates already downloaded and ready to install. They might even be
unpacked already. Beside the present is a simple description like "13
updates available, requires restart. Click to update." The user either logs
in as usual, ignoring the icon (maybe it's at the bottom/corner of GDM), or
clicks the present. Clicking the present prompts for a password, and then
shows an elegant progress bar, installing the updates. If the updates
required a restart, the machine simply restarts, and our new 10 second boot
time brings the machine back up before the user even notices it's
restarting. We don't have to confirm shutdown, because nobody is logged in.
Then, the user logs in to her newly updated desktop.

There are drawbacks to this approach, sure, but do you honestly not see any
merit? I think it delivers a much more pleasant experience than asking the
user at shutdown. At GDM, the user is not in a hurry, and they can take a
moment to decide if they would like to update or not. Asking the user to
update at shutdown feels like a rushed decision; the machine is shutting
down, and you have a brief moment to either opt-in or opt-out of updates.


David, don't think I want to discourage you in any way. I'm pretty
happy with initiatives like yours.
But, of course, one has to see which advantages those effectively bring.

Frankly, seems to me that the only merit you cite ('more pleasant
experience') is highly subjective as it is the consideration that at
login the user is less in hurry than on shutdown. The hurry factor, by
the way, varies depending on the platform (desktop/notebook/netbook).
I'd frankly consider a netbook/notebook user always in hurry, and that
brings down both the login/logout alternatives. For a desktop, though,
the shutdown is nicer.

Sure everything can be ignored, but that also means that such feature
would affect a lower percentage of users, making it less compelling.
I also think that doing things at start up will require much more code
respect of the shutdown option and increased complexity in the
configuration panels (see for example the proposed configuration panel
that will be needed for handling the pop-under intrusiveness
http://tinyurl.com/koommq . are we sure we need that?)

A few more points:
- auto-downloading the updates is already there, but it&#x

Re: [Ayatana] Updates on Login (was: Re: [Fwd: Update manager])


My role! :)

David

David Siegel wrote:
My roll on the Canonical Design and User Experience team is to make 
Ubuntu the most enjoyable to use operating system in the world, so I 
hope you can forgive me for making "[it offers a] more pleasant 
experience" the main thrust of my argument.


I am not decidedly in favor of updates at GDM over updates at any other 
point in time. I am just trying to get us to think more broadly about 
solutions to the update problem, and not to jump to premature conclusions.


I can offer other arguable points of merit for updates at GDM:

(1) (This is completely subjective, but my personal experience does 
include the experiences of others, and is valid in itself) I often feel 
less rushed and stressed when booting my computer as opposed to shutting 
it down. When I log in, I wait for applications to load, my mail to 
download, my music player to start, etc. When I shutdown, I currently 
enjoy the luxury that my computer turns off immediately with no fuss; 
currently, shutdown does not involve waiting.


(2) Think of portable computer users (laptops and netbooks). They nearly 
always have more battery available at boot than at shutdown. In fact, 
many users shut their laptops down *only* when they are forced to due so 
due to an empty battery. We never want to initiate updates on 
insufficient power.


(3) Smaller cognitive burden. Think about the worker. At the start of 
the day, you boot your machine, grab some coffee, and return to your 
machine. At the end of the day, you just want to leave the office! Even 
if you knew you could leave something running on your machine and go 
home, it still might cause a lingering uncertainty (did it ask me for 
confirmation? Was there an error? Is my computer still on right now? Is 
it logged in?!)


Most of us would be perfectly comfortable initiating an update on 
shutdown, and walking away from our machine, but I'm not sure if less 
sophisticated users are similarly comfortable behaving this way.


Also, more and more devices running Ubuntu will be laptops and netbooks. 
We may want to focus more on those use cases, and less on the use case 
of a sedentary desktop.



David

tacone wrote:

People who auto-login or never restart can be handled differently.
Personally, I auto-login, so I would not use this feature, but let's not
think of gurus like us, who participate on Linux mailing lists, and 
let's

think instead about the average user, who might be made uncomfortable by
computers in general, and may be nervous about their first venture into
Linux.



The core of the idea is, at the face browser, there is a present icon 
when
you have updates already downloaded and ready to install. They might 
even be

unpacked already. Beside the present is a simple description like "13
updates available, requires restart. Click to update." The user 
either logs
in as usual, ignoring the icon (maybe it's at the bottom/corner of 
GDM), or
clicks the present. Clicking the present prompts for a password, and 
then

shows an elegant progress bar, installing the updates. If the updates
required a restart, the machine simply restarts, and our new 10 
second boot

time brings the machine back up before the user even notices it's
restarting. We don't have to confirm shutdown, because nobody is 
logged in.

Then, the user logs in to her newly updated desktop.

There are drawbacks to this approach, sure, but do you honestly not 
see any
merit? I think it delivers a much more pleasant experience than 
asking the
user at shutdown. At GDM, the user is not in a hurry, and they can 
take a

moment to decide if they would like to update or not. Asking the user to
update at shutdown feels like a rushed decision; the machine is shutting
down, and you have a brief moment to either opt-in or opt-out of 
updates.


David, don't think I want to discourage you in any way. I'm pretty
happy with initiatives like yours.
But, of course, one has to see which advantages those effectively bring.

Frankly, seems to me that the only merit you cite ('more pleasant
experience') is highly subjective as it is the consideration that at
login the user is less in hurry than on shutdown. The hurry factor, by
the way, varies depending on the platform (desktop/notebook/netbook).
I'd frankly consider a netbook/notebook user always in hurry, and that
brings down both the login/logout alternatives. For a desktop, though,
the shutdown is nicer.

Sure everything can be ignored, but that also means that such feature
would affect a lower percentage of users, making it less compelling.
I also think that doing things at start up will require much more code
respect of the shutdown option and increased complexity in the
configuration panels (see for example the proposed configuration panel
that will be needed for handling the pop-under intrusiveness
http://tinyurl.com/koommq . are we sure we need that?)

A few more points:

Re: [Ayatana] Updates on Login (was: Re: [Fwd: Update manager])

I think this is the ideal, but every time I start to bring up implicit updates, 
I get smacked :)


David

Wouter Stomp wrote:

On Wed, Jun 17, 2009 at 8:38 PM, David Siegel wrote:

Most of us would be perfectly comfortable initiating an update on shutdown,
and walking away from our machine, but I'm not sure if less sophisticated
users are similarly comfortable behaving this way.



Most users don't care about updates and don't want to care about them.
Ideally all updates should be installed automatically in the
background without the user noticing anything. There is a strong study
by google favoring silenty updating the browser, as google chrome
does: http://www.techzoom.net/publications/silent-updates/index.en
Quote from the conclusion: "With silent updates, the user does not
have to care about updates and system maintenance and the system stays
most secure at any time. We think this is a reasonable default for
most Internet users. Furthermore, silent updates are already well
accepted for Internet Web applications." Of course this has some
downsides, but in the end, I think this is the way to go, not
bothering the end user with any computer maintainance tasks.

Cheers,

Wouter


___
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] New discussion suggested: Features needed, but absent in Ubuntu

2009-06-19 Thread David Siegel

Here are many bugs that have been marked invalid in hundredpapercuts 
just in the last week:


https://bugs.edge.launchpad.net/hundredpapercuts/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=INVALID&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=&field.tags_combinator=ANY

Many of these are great usability enhancements, but they are also 
feature requests so they do not qualify as paper cuts. If you see a 
great feature request in here that you believe would improve usability 
in Ubuntu, tag the bug "feature-request" and we can continue to track 
these suggestions.


David

Joseph A. Feinstein wrote:
There are (usability) features that are absent in Ubuntu, but are 
present in other operating systems.


I suggest to identify and assess these features, then decide whether 
it makes sense to implement them in Ubuntu. The similar discussion can 
be considered for applications as well.


To start, I suggest to take a look at a feature called "System Restore"
(in some other OS) or "Falling back to the known working state" (my 
term).


If something gets corrupted in your system (on its own or as a result of
the installation of some "not so good" software), it's nice to be able
to quickly fall back to the known "working state" of the system, without
a need to restore it from an existing (or, often, non-existing) backup.

This is achieved by periodically creating (automatically as well as
manually) "checkpoints" with snapshots of the working states of the 
system.


Does it make sense to implement the similar feature in Ubuntu?

Regards,

Joe

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp



___
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] One Hundred Paper Cuts -- the first ten (as sent to ubuntu-devel)

2009-06-19 Thread David Siegel

We've identified the first ten of one hundred paper cuts* that we plan
to fix for Karmic:

https://bugs.edge.launchpad.net/hundredpapercuts/+bugs?orderby=-importance&field.status%3Alist=TRIAGED

The goal is to have all ten fixed by next Friday, at which point we will
announce 10% progress on the project and celebrate. If next week goes
well and we can get enough developers involved, we will continue at a
pace of ten paper cuts healed per week. With a pace like that, this
project is going to get a lot of attention and get everyone super
excited for Karmic.

If you are interested in getting involved with the project, there is no
better time to start. Pick one of these ten bugs and get busy: identify
affected projects, make contact upstream, look for patches floating
around, begin crafting a fix, or provide any other feedback. Also, if
any of these don't appear to be fixable by next Friday, please comment
that the bug may not be a paper cut. Some of them appear to be
nontrivial, but someone with more expertise might discover a trivial way
to make progress on the issue if not solve it completely. Canonical's
Design and User Experience team aims to get involved with these first
ten before early next week, but if a paper cut is not blocking on their
involvement (many are not) and you can make progress, by all means
please do so.

Thank you,
David

PS: For the curious, here are the potential remaining paper cuts:
https://bugs.edge.launchpad.net/hundredpapercuts/+bugs?orderby=-importance&field.status%3Alist=CONFIRMED

Many people have already started working on confirmed paper cuts, and a
few fixes have already landed.

*Paper cuts are trivially fixable usability bugs that the average user
would encounter during his/her first day of using vanilla Ubuntu 9.10.

___
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] One Hundred Paper Cuts -- the first ten (as sent to ubuntu-devel)

2009-06-19 Thread David Siegel

I've created a project milestone with a more stable set of ten paper 
cuts to fix by next Friday:


https://bugs.edge.launchpad.net/hundredpapercuts/+milestone/round-1

David

David Siegel wrote:
We've identified the first ten of one hundred paper cuts* that we plan 
to fix for Karmic:


https://bugs.edge.launchpad.net/hundredpapercuts/+bugs?orderby=-importance&field.status%3Alist=TRIAGED 



The goal is to have all ten fixed by next Friday, at which point we 
will announce 10% progress on the project and celebrate. If next week 
goes well and we can get enough developers involved, we will continue 
at a pace of ten paper cuts healed per week. With a pace like that, 
this project is going to get a lot of attention and get everyone super 
excited for Karmic.


If you are interested in getting involved with the project, there is 
no better time to start. Pick one of these ten bugs and get busy: 
identify affected projects, make contact upstream, look for patches 
floating around, begin crafting a fix, or provide any other feedback. 
Also, if any of these don't appear to be fixable by next Friday, 
please comment that the bug may not be a paper cut. Some of them 
appear to be nontrivial, but someone with more expertise might 
discover a trivial way to make progress on the issue if not solve it 
completely. Canonical's Design and User Experience team aims to get 
involved with these first ten before early next week, but if a paper 
cut is not blocking on their involvement (many are not) and you can 
make progress, by all means please do so.


Thank you,
David

PS: For the curious, here are the potential remaining paper cuts:
https://bugs.edge.launchpad.net/hundredpapercuts/+bugs?orderby=-importance&field.status%3Alist=CONFIRMED 

Many people have already started working on confirmed paper cuts, and 
a few fixes have already landed.


*Paper cuts are trivially fixable usability bugs that the average user 
would encounter during his/her first day of using vanilla Ubuntu 9.10.






___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp



___
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] Idea: for Ayatana to have oversight of highly visible projects.

2009-06-22 Thread David Siegel

There are many different projects that Ayatana members can help drive, 
but I will just mention one quickly before heading to bed. 
hundredpapercuts could really use some "oversight" from Ayatana members.


Here are one hundred usability bugs we've planned to get fixed for 
Karmic: https://edge.launchpad.net/hundredpapercuts/karmic


If you're interested in putting your design and communication skills to 
use, please take a look at these. Many of them could use user testing 
data to determine appropriate solutions. A lot of them could use some 
design exploration in the form of mockups. Most of them having confusing 
or incomplete titles and descriptions, and need to have contact 
established with upstream stakeholders in the form of bug reports, and 
contact with developers on IRC and email to stir up motivation to 
address some of the longstanding usability issues.


David

H S wrote:
https://wiki.ubuntu.com/Ayatana:  "Ayatana's goal is to build a set 
of well researched and defined technologies to help extend, improve 
and refine the Open Source desktop"


Shouldn't that mean that Ayatana should have some oversight, or at 
least, be made aware of, certain highly visible projects?


For example, the slideshow that will show during the Ubiquity install 
for Karmic 
(https://launchpad.net/distros/ubuntu/+spec/ubiquity-slideshow) will 
be the first impression that many new users will have of Ubuntu.  
Shouldn't the Ayatana Team at least keep an eye on - and at most, lend 
some design and communication skills and polish to - this project?  If 
left to their own devices, I'm afraid the project will only produce a 
very 'rinky-dink', amateurish outcome that will not leave a good first 
impression.


I've already tried to lend my design opinions at 
https://lists.launchpad.net/ubiquity-slideshow/maillist.html, but to 
little or no avail. :-(


I could suggest other projects as well, but I'm curious what people 
think.  Is Ayatana just about starting new projects, or is it also 
about participating in highly visible (to the end-user) projects, so 
that good, consistent, well-designed 'look and feel' is persistent 
throughout the Ubuntu experience?





___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp
  



___
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] (A tentative list of) One Hundred Paper Cuts

2009-06-23 Thread David Siegel

Here is a tentative list of 100 paper cuts for Karmic, divided into 10 
weekly milestones of 10 paper cuts each (some milestones contain an 
additional Kubuntu paper cut):


   https://edge.launchpad.net/hundredpapercuts/karmic

Many of these paper cuts call for trivial patches, requiring little 
design consideration or user testing. Some of the paper cuts would 
benefit from the involvement of the Design and User Experience team, so 
the milestones outline a schedule for Design team participation.


Guide to paper cut statuses:

 Confirmed:  the bug has been reported as a paper cut and was checked 
at least once against paper cut criteria.
 Triage:the bug has design feedback on it, and is ready to be 
worked on.
 Incomplete: please mark a bug incomplete (with a comment) if you think 
it is not a paper cut, or something else is wrong.
 Invalid:   the bug is not a paper cut, and should be replaced 
within its milestone. Please mark incomplete and discuss before marking 
invalid.


In progress, fix committed, etc. mean what they usually mean.

If you feel like fixing a paper cut, please assign it to yourself. If 
you can conduct user testing or other research, that would really help 
make progress on the trickier paper cuts. Some people have been blogging 
about paper cuts and conducting user testing via their readers or 
informal surveys in the comments (http://www.ivankamajic.com/?p=143). 
Others are busy writing patches.


We are trying to fix 
https://edge.launchpad.net/hundredpapercuts/+milestone/round-1 for 
Friday and we're making great progress!


David

___
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] Upgrading without need for Reboot

2009-07-01 Thread David Barth

Jonathan Marsden wrote:

> > So (assuming it works as advertised, which I have not tested at all!)
> > Ubuntu/Canonical could use this to run its own equivalent update
> > service(s), or incorporate it into apt, or into postinst scripts in
> > kernel update .debs, or whatever is actually appropriate.
>   
I think the Platform Foundation guys have been taking a look. For the
desktop however, there are quite a few other elements that do not
currently support hot code swapping, like D-Bus that brings down the
whole session if you want to restart it.

David


___
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] notification for multimedia keys?

2009-07-01 Thread David Barth

Praveen wrote:

> >  i wanted to discuss about this blueprint
> > https://blueprints.edge.launchpad.net/ubuntu/+spec/dx-karmic-notify-osd/specifically
> > the section about consistent feedback for multimedia keys does
> > this mean that each time i press play, forward, etc a notification saying
> > play, forward will appear?
> >
> > if so then it will be useless and the correct way would be that banshee upon
> > clicking play puts a notification of the song being played <--- and this is
> > a bug on banshee bugzilla which is being/has been fixed and now if we give
> > notification for play key, then each time i hit play there will be two
> > notifications one for play key and one from banshee
> >
> >  am i wrong in interpreting this blueprint?
> >   
>   
We've considered different approaches. The mention on the blueprint is
mostly to track the concern that notifications related to multimedia
keys require more attention.

We first tried to provide notifications centrally, to avoid patching too
many applications, and also because the notification type (so called
"synchronous") is meant to express immediate feedback. This approach
proved to be problematic, with duplicates and corner cases where we
don't know what to display (play or pause?)

Requiring remote control support in the multimedia applications would
solve most of the issues I think, but that represent a change of a
different scale where not all application developers agree on the
proposed standard.

So in the meantime, I think we're going to patch more applications to
have them provide feedback directly, but may be revert to using normal
notifications, because we have fewer guarantees on the responsiveness.

David

___
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] Updates on Login

2009-07-06 Thread David Siegel




Mark Shuttleworth wrote:

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 case where update on login works best. Any other 
time rebooting is totally interruption. You're working, you need to 
decide whether or not rebooting is important enough, and then if you 
do decide to reboot, you need to save all of your state, and actually 
do the deed. Immediately after boot you don't have this problem. 
Instead of starting to work and then being disturbed, you delay 
starting until you can really start, without interruption.


's a fair point.


Also, as there is no user state before login, we can reboot the machine without 
user confirmation. With fast-boot and KMS, we completely remove the pain from 
rebooting after updates -- in fact, the user probably won't even notice the 
reboot (we should suppress startup sounds on the reboot).


David

___
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] One Hundred Paper Cuts Round 2 Progress Report

2009-07-13 Thread David Siegel


(From http://davidsiegel.org/100papercuts-round-2/)

With many developers attending Gran Canaria Desktop Summit 
 last week, the second 
milestone 
 in the 
One Hundred Paper Cuts project 
 was moved back one 
week. We did not heal all ten paper cuts in Round 2 
, but we 
made excellent progress on seven of them, while three paper cuts (and 
one Kubuntu paper cut) need some more attention before they can be healed.


Paper cuts fixed in this milestone:

   * Scrolling over your desktop no longer causes seasickness
 
   * Warn users who attempt to run updates on battery power
 
   * Don't show esoteric "Sign" and "Encrypt" entries in file context
 menus 
   * Remove "Open with" and quotation marks from entries in "Open with"
 sub-menu
 
   * Show application icons in the "Open with" sub-menu
 

The following paper cuts are still in progress. Many of them have 
patches available, but something small is preventing the patches from 
landing:


   * Nautilus's search button tooltip is misleading
 .
 The fix for this bug was included in a broader patch; a patch that
 directly addresses this bug needs to be created.
   * Network Manager's wireless network password field should be
 focused by default for quick authentication
 .
 Patch is awaiting review and integration upstream and in Ubuntu.

These paper cuts appear to be stuck and may need *your* attention:

   * "Create Document" Templates difficult to use
 .
 Needs a fundamental decision about which templates to include.
   * Ambiguous wording in Computer Janitor confirmation dialog
 
.
 Patch needs attention from someone with PyGtk expertise.
   * Fix avatar in KDE menu to be next to username
 .
 Plasma Review Board seems to have rejected the patch outright for
 breaking visual consistency.
   * Poor descriptions for some applications in Startup Programs window
 .
 This bug needs attention from a native english speaker with
 excellent writing skills.

Overall, I am pleased with the great work completed for this milestone, 
especially the amazing Nautilus work by Marcus Carlson 
 with the 
upstream care and cooperation of Cossimo Cecchi 
. I expect the lingering paper cuts in 
this round to be fixed for Karmic even as we move our focus to Round 3 
 this week.


___
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] One Hundred Paper Cuts Round 3

2009-07-14 Thread David Siegel


We have ten new paper cuts to heal for Saturday!

   https://edge.launchpad.net/hundredpapercuts/+milestone/round-3

How you can help:

  * Write patches.
  * Read bug history to understand the bug, ask around (try #ubuntu-desktop, 
#ayatana) to find a developer to mentor you while you write a patch, or to make 
the fix themselves.
  * Collect user data via informal (or formal!) user testing and report it on 
the bug.

  * Blog about this week's milestone, or individual bugs.

Happy healing,
David

___
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] [Bug 410220] Re: Indicator applet Always shows icon

2009-08-25 Thread David Barth

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 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.
>>
>> In 9.10, it will be possible to launch messaging applications from the
>> menu. It should also be possible to configure the apps NOT to be there
>> (so, for example, if you don't use evolution then it needn't be
>> possible to launch it from there). If there is NOTHING in the menu,
>> then it should disappear.
>> 
>
> Yes, we spec'd it as such.  Someone will have to disable the launchers
> that they've installed via the preference dialog, but after that it will
> disappear.  (sorry, I hadn't updated the bug since we discussed this)
>   
The current proposal to remove the icon, but only if:
  1. there are no messages waiting
  2. each of the application launchers have been manually disabled by
the user

seems a bit difficult to discover.

I think we need an option in the Preferences to hide the icon.

Proposed change:
 - if no app launchers are registered, or all of them have been
blacklisted, then the option should automatically check itself ("Hide
the icon when there are no new messages")
 - when the option is set, the UI to arrange app. launchers should be
grayed out (indicating that none of the launchers will be shown anyway),
whereas when it's not set, the user can then fine tune the list of
displayed launchers.

David
___
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] [Bug 410220] Re: Indicator applet Always shows icon



On Aug 25, 2009, at 8:44AM , Ted Gould wrote:


On Tue, 2009-08-25 at 11:15 +0100, Mark Shuttleworth wrote:

There is no need for a Preferences for the Messaging Menu, and this
use case does not justify the creation of one.


We have specified a preference dialog for the messaging menu.  The
reason is for blacklisting applications.

Originally the control of whether the launcher is in the messaging  
menu

was in the application preferences.  Which is nice.  But in the case
where someone gets an application that they know they don't use, they
have to open that application and find the setting to remove it.   
Which

is a pain.  But, it is then also compounded by the fact that most
messaging applications prompt to set up an account on first run before
they'd even give you the choice to set preferences.  So, to remove an
application you know you're not going to use you'd have to start it,
configure it, and then set the preference to remove it.

On Tue, 2009-08-25 at 10:24 +0100, David Barth wrote:

seems a bit difficult to discover.

I think we need an option in the Preferences to hide the icon.


I disagree with this.  I think that it is hard to discover if your  
goal

is to hide the icon.  But I think in that case people will remove the
applet.  I think that we can let people make a choice to remove
applications application by application.  We don't need an override  
for

that.


I wouldn't think of it as an override, but more as an explicit  
mentioning of the effect of disabling all launchers. Think of the user  
who has just disabled all launchers - hopefully he will notice that  
the "hide icon" checkbox was just checked, and he will realize (1)  
that the icon will be hidden and (2) why. He also has the option to  
make sure the icon isn't hidden.


David



--Ted

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp



___
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] [Bug 410220] Re: Indicator applet Always shows icon



On Aug 25, 2009, at 8:44AM , Ted Gould wrote:


On Tue, 2009-08-25 at 11:15 +0100, Mark Shuttleworth wrote:

There is no need for a Preferences for the Messaging Menu, and this
use case does not justify the creation of one.


We have specified a preference dialog for the messaging menu.  The
reason is for blacklisting applications.

Originally the control of whether the launcher is in the messaging  
menu

was in the application preferences.  Which is nice.  But in the case
where someone gets an application that they know they don't use, they
have to open that application and find the setting to remove it.   
Which

is a pain.  But, it is then also compounded by the fact that most
messaging applications prompt to set up an account on first run before
they'd even give you the choice to set preferences.  So, to remove an
application you know you're not going to use you'd have to start it,
configure it, and then set the preference to remove it.


For a concrete example, consider Evolution. To remove the Evolution  
launcher from the messaging menu, you'd have to launch Evolution and  
set up your email account before you can access Evolution's  
preferences and disable the launcher. If the messaging menu lets you  
access a simple blacklist, you can just go there and uncheck Evolution  
and be done with it.


David




On Tue, 2009-08-25 at 10:24 +0100, David Barth wrote:

seems a bit difficult to discover.

I think we need an option in the Preferences to hide the icon.


I disagree with this.  I think that it is hard to discover if your  
goal

is to hide the icon.  But I think in that case people will remove the
applet.  I think that we can let people make a choice to remove
applications application by application.  We don't need an override  
for

that.

--Ted

___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp



___
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] [Bug 410220] Re: Indicator applet Always shows icon



On Aug 25, 2009, at 9:14AM , Rick Spencer wrote:


On Tue, 2009-08-25 at 09:06 -0500, David Siegel wrote:


For a concrete example, consider Evolution. To remove the Evolution
launcher from the messaging menu, you'd have to launch Evolution and
set up your email account before you can access Evolution's
preferences and disable the launcher. If the messaging menu lets you
access a simple blacklist, you can just go there and uncheck  
Evolution

and be done with it.

David

Assuming that users prefer to act directly on objects, would it not be
more direct to allow them to right click on the menu item to remove  
it?
This would be consistent with how users remove the Evo launcher from  
the

panel.

Cheers, Rick


Context menus on menus themselves is something generally avoided. I'm  
pretty sure it's a big no-no in the GNOME HIG as well, but I'd have to  
check.


David




___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp



___
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] [Bug 410220] Re: Indicator applet Always shows icon



On Aug 25, 2009, at 9:29AM , Rick Spencer wrote:



On Tue, 2009-08-25 at 09:20 -0500, David Siegel wrote:

On Aug 25, 2009, at 9:14AM , Rick Spencer wrote:


On Tue, 2009-08-25 at 09:06 -0500, David Siegel wrote:


For a concrete example, consider Evolution. To remove the Evolution
launcher from the messaging menu, you'd have to launch Evolution  
and

set up your email account before you can access Evolution's
preferences and disable the launcher. If the messaging menu lets  
you

access a simple blacklist, you can just go there and uncheck
Evolution
and be done with it.

David
Assuming that users prefer to act directly on objects, would it  
not be

more direct to allow them to right click on the menu item to remove
it?
This would be consistent with how users remove the Evo launcher from
the
panel.

Cheers, Rick


Context menus on menus themselves is something generally avoided. I'm
pretty sure it's a big no-no in the GNOME HIG as well, but I'd have  
to

check.

David


True, but personally, I'd rather make the system work the way users  
want

and expect it to, even if it requires deviating from the HIG.

Cheers, Rick


"If I'd asked my customers what they wanted, they'd have said a faster  
horse."

  -- Henry Ford

David




___
Mailing list: https://launchpad.net/~ayatana
Post to : ayatana@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana
More help   : https://help.launchpad.net/ListHelp



___
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] New notification placement

2009-08-28 Thread David Barth

Mark Shuttleworth wrote:
> 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. I'll give that a try today and let you
>> folks know about the outcome.
>>   
>> 
> OK, just let us know if it's *possible*. I'm thinking that we might
> leave the fade if the mouse has moved in the past 5 seconds on the basis
> that your eye is likely to be tracking the mouse. But if the mouse has
> been still, we wouldn't fade because you just left the mouse there from
> previous work.
>
> This would be pretty fragile to small accidental nudges of the mouse, so
> I don't think we should implement it yet, but I'd like to know how much
> we can cheaply determine about the mouse's behaviour in the past few
> seconds. I do *not* want notify-osd to be eating CPU cycles watching the
> mouse all the time, though :-)
>   
Currently, we're adding a cursor monitoring callback once a notification
is on display, but that's polling. It's acceptable to finely track what
the user is doing for fading, blurring, etc. But not as general mechanism.

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.

>From xscreensaverqueryinfo(3):

#include 

typedef struct {
Window window;/* screen saver window */
int state;/* ScreenSaver{Off,On,Disabled} */
int kind; /* ScreenSaver{Blanked,Internal,External}
*/
unsigned long til_or_since;   /* milliseconds */
unsigned long idle;   /* milliseconds */
unsigned long event_mask; /* events */

} XScreenSaverInfo;

accessible with XScreenSaverQueryInfo*

*We should need to do the query only before displaying a new
notification, to know whether to apply the "no-fade-when-mouse-is-there"
feature or not.

David
___
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] New notification placement

2009-08-28 Thread David Barth

Mark Shuttleworth wrote:
> 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", which
> is fine for the screensaver because the screensaver only cares if you
> have been COMPLETELY idle. We might care about a little more detail,
> like, "is your attention in this part of the screen", which is not the same.
>
> For example, if I left the cursor in the top right of the screen after
> closing a window and my attention is now somewhere else, but I just
> nudge the touchpad a *little*, the XScreenSaver API will say "not idle",
> while we probably want to infer that the users attention is not there.
> Attention is a factor of amount of movement and other activity like
> clicking.
>
> Finally, does the XScreenSaver API separate out mouse movement from
> keyboard movement? If I leave a mouse pointer in the top right of the
> screen, but am typing into a window in the bottom left, we want to treat
> that mouse pointer as idle even though I am busy typing precisely
> because we are interested in a different region to where the typing is
> happening.
>   
Right, the XScreenSaver API doesn't provide that level of detail, and
doesn't distinguish between mouse or keyboard. Every new input event
resets the idle timer, key presses or inadvertent mouse movements.

For that precision monitoring we need either to track mouse/keyb every
few seconds (but would significantly impact the energy efficiency of the
desktop). Or set an eventmask on the root window and see if we can still
get the right level of events to infer the user activity.

David
___
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] Notify OSD: Talk about giving the user preferences

2009-08-29 Thread David Bensimon

Reading the entire "[Ayatana] New notification placement" thread, while
at the same time testing karmic, got me thinking about notifications. I
find that a lot of attention is being given to the positioning and
behaviour, but little consideration is being given to a users
preference. Notification have many attributes (position, timing,
effects) that could be user editable.

I have to agree with both Angel and Luke that although a default
positioning and behaviour needs to be chosen, ultimately the power of
choice should be given to the end user.

Where the notification configuration would reside could be a tough
choice. My preference from most to least favourite would be:
1) "Appearance" preferences
2) A new "Notifications" preference option (seen in Jaunty Alpha/Beta)
3) gconf database

Regards,

David

___
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] Notify OSD: Talk about giving the user preferences

2009-08-31 Thread David Bensimon

Dr. David Alan Gilbert wrote:
> I wonder if the easiest form of preference would be for the user to
> be able to drag the notification somewhere and for it to remember
> where you left it (with a check that it's still on the screen given
> your current monitor setup).  This lets the user put it anywhere they
> like - I think the trick though is the semantics of when you can get
> the mouse over it to drag it.

The only issues with this is that it conflicts with the behaviour that
mouse over notification makes the notification disappear. Secondly, I
can see people moving the notification by accident, so it should require
more than just click + drag. Perhaps if you mouse over with Alt, it
could not disappear and it would be movable. This idea is not bad, but
only deals with the placement (very simply, which is good), but ignores
timing and effect preferences.

Toni Ruottu wrote:
> In the old days Ubuntu had those funny comic book bubbles used for
> notification. Afaik there was no way to configure them. If users
> didn't find the default placement awkward then, why would they now.

AFAIK you could configure the placement of the bubbles by moving the
applet that controlled those bubbles to another location on the panel
(or to another panel). You are correct that the bubble notification
never gave the use control over timing and effects.

Regards,

David

___
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] Notification consistency

2009-09-09 Thread David Barth

Steve Dodier wrote:
> +1 too, but it'll require Mozilla to natively support libnotify for their
> Linux client. I'm actually surprised it's still not the case...
>   
Mozilla has support for libnotify in their trunk branch, but they don't
enable that build option by default. Now that the protocol has been
standardized and approved by both Gnome and KDE, it would make sense for
them to reconsider using that feature by default.

David

___
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] Notification consistency

2009-09-11 Thread David Barth

mac_v wrote:
> From: David Barth 
> To: Steve Dodier 
> Cc: ayatana@lists.launchpad.net
> Sent: Wednesday, 9 September, 2009 1:59:44 PM
> Subject: Re: [Ayatana] Notification consistency
>
> Steve Dodier wrote:
>   
>> +1 too, but it'll require Mozilla to natively support libnotify for their
>> Linux client. I'm actually surprised it's still not the case...
>>  
>> 
> Mozilla has support for libnotify in their trunk branch, but they don't
> enable that build option by default. Now that the protocol has been
> standardized and approved by both Gnome and KDE, it would make sense for
> them to reconsider using that feature by default.
>
> David
>
>
> ^ This seems to have changed , 
> Quoting Alexander Sack :   notify-osd in particular was explicitly kept 
> broken upstream because they see our way as a regression...
>
> I'v also tried to get a patch into the ubufox for this , but we are past 
> feature freeze.
>  asac's  reply : too late for this cycle. features need to be carefully 
> selected and after UDS discussion. we also need to talk to mozilla etc.
>
> So i guess we missed the chance for karmic :(
>   
It is was not on the table for Karmic, that is, Mozilla had reservations
last year about the non-interactivity of n-osd notifications and I think
they prefer to see how the rest of the community reacts to our change
before reconsidering a switch.

I think what we've shown for now 2 releases, is that the
non-interactivity of that kind of notification is well received, and
actually becomes a desirable feature for users.

The standardization work that we did with other projects (on the xdg
list) should also help, along with the fact that now third-parties can
really rely on a server capability to adapt their behavior.

Last Mozilla not only uses Growl on the Mac but they also research
similar notification mechanisms (http://www.toolness.com/wp/?p=463) so I
hope they will reconsider libnotify support in the future.

David
___
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] Ubuntu User Experience Guidelines

2009-09-28 Thread David Siegel

Allan, I think you're on to something really great here, and I would  
like to work on it with you. Just a few quick thoughts for now:


Building upon Tango and the GNOME HIG as a foundation, though, looks  
like an easy way to start but doesn't strike me as the best way. While  
I really admire the Tango Project and think that the GNOME HIG has  
been tremendously beneficial, I think we need something more  
ambitious, quintessentially Ubuntu, and probably tangential because,  
after all, Ubuntu is not like GNOME.


Also, the notion that Ubuntu should be "consistent" has always  
slightly irked me. We need to be careful to choose the domain in which  
we exhibit consistency -- do we want buttons, menus, and scrollbars to  
behave consistently within Ubuntu? Do we want Ubuntu to be consistent  
with other free desktops? Do we want to Ubuntu to be consistent with  
popular proprietary alternatives? You can see how consistency quickly  
becomes uniformity. In some ways Ubuntu is inconsistent to a fault; in  
other ways, Ubuntu's inconsistencies make it great. I guess what I am  
rambling on and on trying to say is that we should only be consistent  
when it's good for us, and never when it does more harm than good :) lol


David


On Sep 28, 2009, at 4:02 AM, Allan Caeg wrote:


Ayatana Listers,

It is a good thing that Ubuntu has been paying much attention to UX  
through this project. This is what open source (and technology in  
general) needs very much.


I am aware that Ubuntu clearly defined what it is about. It is great  
that the members of the community knows what the organization stands  
for. The Ubuntu Code of Conduct ( http://www.ubuntu.com/community/conduct 
 ) managed to put the community together for a common goal. This is  
a rare thing even for profitable organizations.


For sure, Canonical's hired Ayatana team has clear goals. However, I  
have not seen a list of Ubuntu's User Interface guidelines. The Code  
of Conduct tells the user what the Ubuntu community is all about,  
but not the product. I am here to propose the construction of the  
Ubuntu User Experience Guidelines if it doesn't exist yet. If it  
already exists, pardon me and please consider my suggestions if I am  
to state anything new.



I propose to include the following to the User Experience  
Guidelienes: consistency, simplicity, beauty, and the Ubuntu Spirit.  
By consistency, I am referring to compliance to the Tango desktop  
project and GNOME's HIG ( http://library.gnome.org/devel/hig-book/stable/ 
 ). Ubuntu always followed GNOME's HIG by including applications  
that will make the desktop experience consistent. An action that  
would prove this intention would be the inclusion of Empathy to  
Karmic. I know that there are many arguments against this move but  
let's leave the discussion to other threads. As for compliance to  
Tango, I always felt that this could use some development because  
the Human icons always seemed to me to be too glossy to be Tango.  
The community is developing the Breathe Icon Set, one that doesn't  
comply with Tango and follows KDE's Oxygen look and feel instead.  
This is a great project as it adds to the beauty/aesthetics of  
Ubuntu, an important part of the UX, but it makes the desktop  
experience inconsistent. Other artists stick to Tango because of all  
the work that has been done. It is the most complete icon set so  
developing on its guidelines would be much less painful for the  
artist. However, the Breathe icon set is slowly achieving completion  
with the help of the Oxygen project. This is going to be a long  
discussion so I am leaving this to other threads, but I am just  
suggesting now that sticking to Tango for official releases may be  
the best path at the moment.



As for simplicity, this is achieved by the distro by putting only  
what is needed. I do not have too much to say about this issue  
because I am personally contented with the state of Ubuntu in this  
area.



Beauty clearly is one of the focuses of the Ayatana project. This  
seems to be most evident through the Notify-OSD. I do not think that  
I have to justify the inclusion of this because Mark has been  
talking saying that "pretty is a feature."



Lastly, I suggest the inclusion of the "Ubuntu Spirit," which is  
best defined by the Code of Conduct. The biggest reason why I am  
sticking to Ubuntu, even if using a commercial OS could be easier  
for me, is my perception of it. UX consists of how the user  
perceives the tool. I may be using Shiki, Sonar or Clearlooks; but I  
feel that Ubuntu is warm. There was a thread in the forums where the  
OP was asking if Ubuntu is worth all the hassle, my answer was yes  
because I know that it is a product out of the love of the  
volunteers that build it. I stick to Ubuntu because of the integrity  
behind it and its community. By using the OS, the user wou

Re: [Ayatana] Call for Ayatana input for Kubuntu Release Announcement

2009-10-21 Thread David Barth


Scott Kitterman wrote:
I'd like to extend an offer to Ayatana to have a section in the Kubuntu 
release announcement descrbing what you have brought to Kubuntu in this 
cycle.  It would also be a good venue for exposing users to the 
experimental functions that were included.


It will be on the Kubuntu web site, so we can use both text and screen 
shots.  

Whatever you can get us before the RC is out can go in the RC announcement 
and the we can add/polish for the final.
  

Thanks Scott.

Looking at http://www.kubuntu.org/news/8.10-release I assume the format 
you're expecting is a short paragraph with some screenshot.


Let us prepare that tomorrow morning.

David

___
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] Message Indicator: Listing apps in menu even if they are not on

2009-11-16 Thread David Bensimon

Paulo J. S. Silva wrote:
>> How does a user go from "Here's a list of apps you can launch" to "Here are
>> some apps that should always start when you log in"? Should there be a
>> dialog asking if you want those apps to auto-start the next time we log in?
>>
> 
> I just tried what I thought was the most obvious path: I opened
> sytem->preferences->session manager (the specific names may be
> incorrect, I am translating back from my locale to English). It opens
> the session manager window.
> 
> Then I went to the "Applications" menu and drag and dropped Epyphany
> onto the session manager window. That's it, epiphany will open next
> time I login.
> 
> I am afraid that most users may not know that they can control the
> programs that start at each session using that window. But if they do,
> it looks quite intuitive to me.
> 
>> I think the only correct path for this is to load all the apps, and then
>> logout, saving the session... but I know that broke in gnome-session a long
>> time ago by design, and I'm not sure if it ever came back properly.
>>
> 
> Unfortunately the auto-save feature does not seem to work with empathy
> for me. I had to explicitly add it to my session as described above.
> It works for other applications though (for example for
> gnome-terminal), and partially for some more (firefox opens up but not
> in the same virtual desktop and position). I looks like empathy
> gnome-session report is broken.

Yes, you may want to look at Chris Coulson's comment on this bug (even
though it is marked invalid):
https://bugs.edge.launchpad.net/ubuntu/+source/gnome-session/+bug/444165

It seems that every application has the responsibility of making sure it
works with gnome-session-properties (Session Manager/Startup
Applications or whatever other name it has been given).

"gnome-session can only restore applications that connect to the session
manager, save it's own state file and tell the session manager how to
restore it. If some applications don't work, then that's an application
bug, and you should open a bug report for that application"

If you report a bug for this against the empathy package, please
subscribe me to it.

David

> 
>> This would seem like another great justification for the indicator-applet to
>> have a preferences dialog. Users will want to configure what shows up and
>> what doesn't (Just because evolution is installed doesn't mean I want it
>> there. Likewise, just because I ran an application once to try it doesn't
>> mean it should live ind the messaging menu for eternity) users ALSO
>> should be able to configure which indicator-apps start up automatically.
>>
>> Maybe this indicates that the indicator-applet and session properties should
>> be somehow more integrated?
> 
> That may be a nice idea. Another possibility would be for the applet
> use the preferred application information. In this case if the
> computer has many mail programs installed. Only the default one for
> each user would appear in indicator applet (at least if is not
> running).
> 
> Paulo
> 
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp


___
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] why doesn't indicator-applet-session's status menu show icons?

2010-01-12 Thread David Siegel

On Mon, 2009-12-21 at 15:39 +0530, mac_v wrote:
> On Mon, 2009-12-21 at 04:18 +0100, Jan Claeys wrote:
> > Currently the indicator-applet-session's status menu (where you set
> > availability status) doesn't show icons.  This makes it really difficult
> > to understand what the status icons shown in the main applet actually
> > mean.
> > 
> > I think the status submenu should show the associated icons, so that
> > people have an easy to find reference for those "status icons".
> > 
> > What do other people think about that?
> > 
> > 
> 
> Hi , 
> I recall mpt mentioned it was supposed to have an icon:
> https://bugs.launchpad.net/ubuntu/+source/libgnome/+bug/407621/comments/17
> 
> It would be a bug , i guess.  

It would alse be a paper cut :)

David


___
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] Hiding shortcut keys in menus

2010-01-12 Thread David Siegel

Drawing upon the discussion surrounding the bug "Underline under
accelerator characters in buttons and menu bar should only show when Alt
is pressed"*, Rich Jones suggested curbing the display of all keyboard
shortcuts in menus. At first, I thought this was a ludicrous suggestion,
but then I took a look at the mockups Rich attached to his bug report
(https://bugs.edge.launchpad.net/hundredpapercuts/+bug/493762) and I
found that the menus seemed significantly easier to use! Rich's mockup
opened my eyes to how cluttered and complex menus are when so many
esoteric keyboard shortcuts are listed--most which are seldom used. I
thought this wild suggestion deserved at least some discussion (and
maybe some user testing).

  * Does anyone know how to configure Gtk to hide keyboard shortcuts in
menus?
  * How would you feel if only the keyboard shortcut for the highlighted
menu entry (e.g. the menu entry under the cursor) were shown?

David


* https://bugs.edge.launchpad.net/hundredpapercuts/+bug/403691



___
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] Hiding shortcut keys in menus

2010-01-12 Thread David Siegel

On Tue, 2010-01-12 at 15:37 -0500, Barry Warsaw wrote:
> On Jan 12, 2010, at 01:53 PM, David Siegel wrote:
> 
> >Drawing upon the discussion surrounding the bug "Underline under
> >accelerator characters in buttons and menu bar should only show when Alt
> >is pressed"*, Rich Jones suggested curbing the display of all keyboard
> >shortcuts in menus. At first, I thought this was a ludicrous suggestion,
> >but then I took a look at the mockups Rich attached to his bug report
> >(https://bugs.edge.launchpad.net/hundredpapercuts/+bug/493762) and I
> >found that the menus seemed significantly easier to use!
> 
> The menus do look nice with much less clutter, though I also worry about
> discoverability.  There's a bug comment about keyboard-only users, which I
> definitely am (when the app will let me!).

Barry, as a keyboard-heavy user, clearly removing keyboard shortcuts
categorically would be devastating, but how do you think the change to
only showing keyboard shortcuts for the highlighted menu entry would
affect you?

> 
> The shortcut display is all about discoverability.  When I know the bindings,
> I'm never even going to look at the menu usually.  When I don't know the
> binding, having them in the menu is great, and the clutter doesn't bother me
> at all, because it contains exactly the information I'm looking for.
> 
> Note too that Gnome supports changing the shortcuts by hovering over the menu
> item and hitting the key chord you want.  So if you get rid of the shortcuts
> you still have to support this use case.

Very interesting. I just tried to assign a shortcut to Crop (which oddly
has no keyboard shortcut by default) and it did not work.

David

> 
> I'll also note that a large part of the problem is that the words "Shift" and
> "Ctrl" are spelled out, with pluses in between.  Perhaps a cue can be taken
> from OS X where there are easy to recognize icons for each modifier key.  On
> OS X they shortcuts don't seem nearly as cluttering.  I guess it helps that
> there typically are fewer of them (though changing them is the job of a
> separate application, making it much less convenient).
> 
> -Barry
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp



___
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] Sketching and Prototyping with a Firefox Addon

2010-01-15 Thread David Siegel

I've tried Pencil and had very little luck.

While it's not open source, I recommend Balsamiq Mockups (an AIR app).
We should build a native, free clone of it :)

David

On Fri, 2010-01-15 at 10:11 +0800, Allan Caeg wrote:
> Hello All,
> 
> I just discovered the Pencil project http://evolus.vn/Pencil/ . It's a 
> Sketching and Prototyping on Firefox. It can be a stand-alone app (based 
> on XUL) too. I'm surprised that it's not getting a lot of attention from 
> the open source community considering that they are into Linux and GNOME 
> judging by the screenshot on their website and their pre-compiled 
> packages for distros.
> 
> Download it from http://evolus.vn/Pencil/Downloads.html
> 
> Let's support projects like this =)
> 
> Allan
> 
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp



___
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] Lucid theme - window controls location

2010-03-12 Thread David Balch

Hi,

I've looked in the list archive but (to my surprise) didn't see any
discussion relating to the position of the window (minimise, maximise,
close) controls in the Lucid theme - my apologies if it's there and
I've missed it.

I imagine most people here are aware that the decision to move the
controls from the right side of the window to the left has sparked
some dissent [0], with the timing and lack of communication not
helping to soothe the issue.

Please could the design team explain the rationale for moving the
window control buttons from the right to the left, and the benefits
expected to result.

[0] e.g. http://yokozar.org/blog/archives/194 ,
http://ubuntuforums.org/showthread.php?t=1422422

Cheers,
Dave B.

PS: Window control location notwithstanding, I think the new theme
looks really good :-)

-- 
http://www.witchesband.com/

___
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] Lucid theme - window controls location

2010-03-13 Thread David Balch

On 12 March 2010 18:58, Dr. David Alan Gilbert  wrote:

> If it was part of the new theme and it was just a matter of going to
> appearance and flipping to another theme or customising to the way
> you like them then I haven't got a big problem with it

Same here, but that would go against SABDFL's plans, in that "A
guiding principle in Ayatana is to *reduce* customisation, not
increase it." - which I agree with, when the reductions/other changes
are shown to provide benefits beyond their cost.

At the moment, the window control placement and order seem to be
costing a lot of time and goodwill, without any clear benefits :-(

Cheers,
Dave B

-- 
http://www.witchesband.com/

___
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] Fwd: Proposal of new UI element for windows in Ubuntu: Esfera

2010-03-26 Thread David Siegel

Pablo, awesome! I was just sketching something almost exactly like this...
My concept was a bit simpler but still very sophisticated:

  * Replace Close, Min, Max buttons with just Close and "other"
  * Dragging the "other" button slightly to the right and releasing
maximizes the window to full the right half of the screen ("maximize
right").
 * Dragging the "other" button slightly to the left and releasing maximizes
the window to full the left half of the screen ("maximize left").
  * Dragging down minimizes.
  * Dragging up maximizes.
  * Dragging and shaking minimizes all other windows.
  * Shift-clicking on the "other" button on multiple windows groups them,
tiling the group and minimizes all other windows when shift is released.
  * Clicking the "other" button shows a menu with all of the actions above,
with shapes that demonstrate the associated gestures.

As you can see, featuritis immediately sets in when we have an "other"
button, but I think we're on to something! Let's continue the discussion and
see if anyone can help us prototype :)

David

2010/3/26 Mark Shuttleworth 

>  Hi folks
>
> Got this interesting proposal from Pablo, and thought it should be sent to
> the list rather than handled in private correspondence. It reminds me of
> something David Siegel was sketching out, also inspired by the challenge of
> "how we can make the most of the new space".
>
> Pablo, if you're not subscribed to Ayatana, it's the best place to sketch
> out a proposal like this.
>
> I appreciate both the detail in the proposal and the relaxed way it's
> pitched!
>
> Mark
>
>  Original Message   Subject: Proposal of new UI element
> for windows in Ubuntu: Esfera  Date: Fri, 26 Mar 2010 00:42:45 +0100  From:
> Pablo QuirósTo:
> m...@ubuntu.com
>
>
>  Hello Mark, I've got a proposal on the buttons' subject. It is a new
> element to be placed in the free space on the top-right of the windows.
>
>  At first I wasn't very convinced on the UI change, and we exchanged a
> couple of messages on the matter in the related bug report, but I've thought
> about it and I agree with you that this could bring interesting
> possibilities.
>
>  I've designed a concept called Esfera, which I think could be a huge step
> forward to the user experience, while bringing innovation to the Ubuntu
> desktop. The idea is explained in the attached PDF; I hope you can take the
> time to read it or at least send it to the Canonical Design team. Sorry for
> the mockup; I'm a disaster using GIMP, but I hope it illustrates the idea.
>
>  I'd be very pleased to answer any question you may have about it. I'd
> just request that if you implement the idea, I appear somewhere as the
> author of the concept, and I've be glad if you kept the name I've chosen.
>
>  Of course, there are lots of ideas that go nowhere, so I'd perfectly
> understand if you consider it useless -- just thought it was good and wanted
> to share it with you.
>
>  Regards,
>
>  Pablo Quirós
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana<https://launchpad.net/%7Eayatana>
> Post to : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana<https://launchpad.net/%7Eayatana>
> More help   : https://help.launchpad.net/ListHelp
>
>
___
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] Fwd: Proposal of new UI element for windows in Ubuntu: Esfera

2010-03-26 Thread David Siegel

I think maximize, minimize, and close are taken for granted -- they're
unquestioned assumptions carried over from a dusty desktop computing past.
Frankly, I'm not convinced that any of these buttons are worth the price
paid by users in time spent thinking about how to arrange their windows.

Anyway, that's a separate discussion. I don't think replacing a single-click
to minimize, for example, with a single-click with a pull-and-release is
replacing "direct access" with "indirect access."

When manipulating the other button, hints could be drawn on the screen --
for example, pull to the right and see a nice overlay/silhouette of the
right-maximized state of the window.\

David



On Fri, Mar 26, 2010 at 10:20 AM, Allan Caeg  wrote:

>  Cool. That "other" button can be rendered like a joystick. The idea would
> be disorienting to a lot of people haven't read the manual, though. Perhaps,
> there has to be instructions like a fresh iPhones "hold an icon to drag it
> or remove the application" thing
>
> Allan
>
>
> On Friday, 26 March, 2010 05:46 PM, David Siegel wrote:
>
> Pablo, awesome! I was just sketching something almost exactly like this...
> My concept was a bit simpler but still very sophisticated:
>
>   * Replace Close, Min, Max buttons with just Close and "other"
>   * Dragging the "other" button slightly to the right and releasing
> maximizes the window to full the right half of the screen ("maximize
> right").
>  * Dragging the "other" button slightly to the left and releasing maximizes
> the window to full the left half of the screen ("maximize left").
>   * Dragging down minimizes.
>   * Dragging up maximizes.
>   * Dragging and shaking minimizes all other windows.
>   * Shift-clicking on the "other" button on multiple windows groups them,
> tiling the group and minimizes all other windows when shift is released.
>   * Clicking the "other" button shows a menu with all of the actions above,
> with shapes that demonstrate the associated gestures.
>
> As you can see, featuritis immediately sets in when we have an "other"
> button, but I think we're on to something! Let's continue the discussion and
> see if anyone can help us prototype :)
>
> David
>
> 2010/3/26 Mark Shuttleworth 
>
>> Hi folks
>>
>> Got this interesting proposal from Pablo, and thought it should be sent to
>> the list rather than handled in private correspondence. It reminds me of
>> something David Siegel was sketching out, also inspired by the challenge of
>> "how we can make the most of the new space".
>>
>> Pablo, if you're not subscribed to Ayatana, it's the best place to sketch
>> out a proposal like this.
>>
>> I appreciate both the detail in the proposal and the relaxed way it's
>> pitched!
>>
>> Mark
>>
>>  Original Message   Subject: Proposal of new UI element
>> for windows in Ubuntu: Esfera  Date: Fri, 26 Mar 2010 00:42:45 +0100  From:
>> Pablo QuirósTo:
>> m...@ubuntu.com
>>
>>
>>  Hello Mark, I've got a proposal on the buttons' subject. It is a new
>> element to be placed in the free space on the top-right of the windows.
>>
>>  At first I wasn't very convinced on the UI change, and we exchanged a
>> couple of messages on the matter in the related bug report, but I've thought
>> about it and I agree with you that this could bring interesting
>> possibilities.
>>
>>  I've designed a concept called Esfera, which I think could be a huge
>> step forward to the user experience, while bringing innovation to the Ubuntu
>> desktop. The idea is explained in the attached PDF; I hope you can take the
>> time to read it or at least send it to the Canonical Design team. Sorry for
>> the mockup; I'm a disaster using GIMP, but I hope it illustrates the idea.
>>
>>  I'd be very pleased to answer any question you may have about it. I'd
>> just request that if you implement the idea, I appear somewhere as the
>> author of the concept, and I've be glad if you kept the name I've chosen.
>>
>>  Of course, there are lots of ideas that go nowhere, so I'd perfectly
>> understand if you consider it useless -- just thought it was good and wanted
>> to share it with you.
>>
>>  Regards,
>>
>>  Pablo Quirós
>>
>>
>> ___
>> Mailing list: 
>> https://launchpad.net/~ayatana<https://launchpad.net/%7Eayatana>
>> Post to : ayatana@lists

Re: [Ayatana] Fwd: Proposal of new UI element for windows in Ubuntu: Esfera

2010-03-26 Thread David Callé

Le vendredi 26 mars 2010 à 06:18 +, Mark Shuttleworth a écrit :
> Hi folks
> 
> Got this interesting proposal from Pablo, and thought it should be
> sent to the list rather than handled in private correspondence. It
> reminds me of something David Siegel was sketching out, also inspired
> by the challenge of "how we can make the most of the new space".

Hi all

I'm fairly new to he list, but about "making the most of the new space"
I would suggest to have a look at this mockup :

http://seilo.geekyogre.com/2010/03/zeitbutton-more-realistic-than-the-nautilus-stuff/

David


___
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] Fwd: Proposal of new UI element for windows in Ubuntu: Esfera

2010-03-26 Thread David Siegel

"Holistic" is a good word -- we should definitely have a broader
discussion about user's window management needs and the UI that would
address those needs, driven by use cases (e.g. "User wants a
spreadsheet, a calculator, and a web page all on the screen at once"
or "User wants two File Manager windows side-by-side to drag files
between them").

David

2010/3/26 Pablo Quirós :
>
>>
>> I hadn't thought about this until now, but I can't remember the last
>> time I've hit maximize.  Double clicking the title bar toggles the
>> maximized, unmax states quite conveniently and is a much bigger target.
>> While the close button in the corner makes a good consistent target, the
>> other two buttons are a little fiddly, both in size and location.
>>
>> The problem that I see it that people that are rearranging windows for a
>> particular purpose are typically moving the mouse cursor in long
>> swooping motions.  (At least in my use case)  Trying to hit a small
>> button tends to break that type flow.  The double clicking of the title
>> bar works in my flow because it doesn't slow me down and is doable in
>> long swooping gestures.
>>
>> Perhaps we should examine dropping the min,max buttons in favor of a
>> more "holistic" active windows approach?  Food for thought.
>>
>
> This is what David and I are proposing - replacing this buttons for a single
> button which does the duty, using gestures to make one action or another. In
> David's proposal, closing button would still exist, but in mine, there would
> be only one button in the future.
> If there is a single, big button, it can be reached easily and fast. And
> this button represents the window - every action made with this button would
> be an action made to the window.
> Of course, we could use no buttons at all, and make the gesture directly to
> the window, but I think it would confuse new users. It might be worth
> discussing, though.
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

___
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] Restart required indicator

2010-03-29 Thread David Balch

Hi,

I really like that the power icon goes red when a restart is required
- good job!

A further refinement would be to make the "Restart required..." text
in the menu red as well, to tie the meaning of the icon colour to the
menu action...

Cheers,
Dave.

-- 
http://www.witchesband.com/

___
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] [Concept suggestion] About the new possibilities for the top right window buttons on the new Ubuntu visual

2010-04-01 Thread David Siegel

Interesting ideas. Something similar I've seen is in Mac OS X where
document-based application windows have little icon in the window titlebar
that represents the underlying file. You can drag this icon and drop it on
an application icon in the Dock to open that file in another application,
for example. Food for thought.
<>___
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] [Concept suggestion] About the new possibilities for the top right window buttons on the new Ubuntu visual

2010-04-01 Thread David Regev

On Thu, Apr 1, 2010 at 6:30 AM, David Siegel wrote:

> Interesting ideas. Something similar I've seen is in Mac OS X where
> document-based application windows have little icon in the window titlebar
> that represents the underlying file. You can drag this icon and drop it on
> an application icon in the Dock to open that file in another application,
> for example. Food for thought.
>

Food for thought indeed!

I’ve been thinking that some of the most crucial ideas behind Izo’s proposal
and the Esfera proposal can be had in a more coherent way by implementing
something akin to the Mac’s *Proxy Icon* (see this
video<http://www.youtube.com/watch?v=qiHQv_DG5sc>for reference). I
don’t know all the details about the Mac implementation,
as I have never used it, but I can think of many way in which a GNOME
version of a proxy icon could significantly improve the Desktop. In fact, if
done right, it could allow Ubuntu to surpass the Mac in this aspect.
Consider the following possibilities:

   1. The icon may be dragged and dropped anywhere. However, not only does
   this allow you to copy the file or its shortcut somewhere, but it also
   allows you *move* the file—all while still opened by an application. *So,
   for example:* I start a new document in gedit. gedit automatically
   creates a new file in my home directory. I decide that I want the file to be
   in my Documents folder, so I simply drag the proxy icon there—all without
   ever needing to open Nautilus in order to find the new file. gedit continues
   to show the same document, virtually oblivious to the fact that it’s now in
   a different location.
   2. The icon is accompanied by a contextual menu similar to the one shown
   for file icons in Nautilus. All operations continue to be active in this
   menu. Thus, using that menu to delete a file actually deletes that file,
   while the window displaying the file simply closes (or perhaps animates into
   the Trash). Similarly, using that menu to rename a file focuses the filename
   in the title bar as an editable text field, allowing the user to rename the
   file straight from there. *So, for example, like before:* I start a new
   document in gedit. gedit automatically creates a new file. I open the menu
   for the proxy icon, choose ‘Rename’, and rename my file—all while it is
   still open.
   3. Combining the previous two scenarios, the proxy icon makes the Save
   dialogue nearly obsolete, replacing it by (more) direct manipulation. This
   is accompanied by other system-wide changes: new files are automatically
   created and named by applications (perhaps the name could be chosen based on
   the first line of the document). If a user wishes to rename the file, that
   may be done the way I described, but it is not mandatory. Thus, the Save
   dialogue no longer disturbs the user’s sacred train of thought, and no one
   who doesn’t care is forced to choose an almost arbitrary name for a file.
   Combine this with auto-saving everywhere, and the Save button become
   history. (Apparently, ROX Desktop has something somewhat
similar<http://roscidus.com/desktop/node/148>
   .)
   4. Expanding on the standard context menu for file icons, other items may
   be added there. A ‘Switch application ›’ item would allow one to open the
   current file in a different application—just like Izo’s proposal, but more
   integrated (and less cluttered). *For example:* I’m viewing a photograph
   in my favourite image viewer. I decide I want to edit it in GIMP, so I
   choose GIMP from the aforementioned menu. The image viewer shut down while
   GIMP starts up, opening the photograph in a window of identical size and
   placement as previously, thus seamlessly switching applications while the
   document window hasn’t moved. This allows the user to focus on the
   document—on *content*—while the applications being used fade into the
   background.
   5. Similarly, a window’s application may also add items to the proxy
   icon’s menu. (Because the menu could get crowded, it might be better to
   place the extra menu items in a separate menu connected to the proxy icon,
   but this issue is incidental to the basic concept here.) This would provide
   a nice balance to the Application menu that GNOME Shell is supposed to have
   in the near future. Actions relating to the application as a whole go in the
   Application menu, while actions relating to the document as a whole go in
   the proxy icon menu—the Document menu. This effectively replaces the File
   menu, and possibly the entire menu bar for a whole class of applications,
   thus freeing up valuable vertical space.
   6. The distinction between the two menus enforces the conceptual
   distinction between applications and documents. Applications are now agents
   that run in the background, accessible via the shell. Documents (and others
   types of objects), on the other hand, are represented not via the shell but

Re: [Ayatana] Indicators for showing progress

2010-04-17 Thread David Nielsen

2010/4/14 Mark Shuttleworth 

>
> I think the idea of an aggregated "downloads" indicator has merit.
>
> I'm not sure about other long-running processes, like a copy-to-network
> or burn-cd action.


I've been giving this a lot of thought lately and I've come to the
conclusion that one of the things I really dislike about Application
Indicators is that most of the applications that come with support don't
belong in the notification area. Banshee/Rhythmbox could be reasoned with
providing a media service, but looking at downloads, I really just care
about getting the file from A to B. Just like when I click a media file, I
don't want 4 different players based on format. Yet this is the very
situation we have for downloads, one client for Bittorrent, HTTP/FTP
downloads are typically in every browser. It really should be a service.
Another annoying problem with downloads is that the different clients aren't
aware of each other so e.g. if I run Bittorrent uploading it isn't aware
that it should throttle itself to not slow down require http downloads.
Currently just leaving it in the default settings which one guesses is what
most people will do, it can seriously hamper the delight of using the
desktop. The only alternative, in Transmission at least, is to define a low
impact slow mode to kick in at set times or as needed.

Download as a service is also a model that while it would require some
rewiring of the desktop would move code to a common place and move such
handling out of applications. At part of that trade off we'd get support for
any protocol handled in any application which was "DownloadKit" enabled.

I know that MonoTorrent already has a dbus interface, so I guess we could
probably get a demo up and running using that.

Thoughts?
___
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] MeMenu status message

2010-04-19 Thread David Siegel

I think you're on to something...

It would be very interesting to combine custom status with standard
status options (e.g. Available, Away) in a control that acts a bit
more intelligently. It might do the following:

  * Appear as a text field, showing your most recent status + status icon.
  * When you click to explicitly focus the text field, the text entry
expands to show the standard status options, and also displays a
blinking cursor so you know you can begin typing.
  * At this point, you can begin to type "Available" and autocomplete
it, or you can type a broadcast message.

To express this idea in terms of other familiar ideas, we'd basically
show a text entry that turns into a text entry + combo box when you
click it to set your status, and also has auto-completion for standard
status options.

This could be cool! Thoughts?

David

On Mon, Apr 19, 2010 at 5:56 PM, Frederik Nnaji
 wrote:
> hello everyone ;)
>
> would it be blasphemy to suggest, the text input field in the MeMenu may
> serve to enter my away/availability message as one would naturally expect it
> to do since it's positioned right above the availability settings with no
> further field-description visible..
>
> !?
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

___
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] MeMenu status message

2010-04-19 Thread David Siegel

Yes, something like that with some nice animations.

___
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] Indicators for showing progress

2010-04-20 Thread David Nielsen

>
> This seems like a really cool idea.
>

Thank you


> The throttling issue applies not just to network connections, but to
> writing to the same disk where skipping from one area of the disk to
> another is slow; it's quicker to finish one task completely before
> starting the next. There could be some sort of priority system so that
> more interactive tasks could jump the queue: "just hold on for a moment,
> Transmission -- Gimp wants to save a 140-MB file to the same disk right
> now".
>

You could probably do something like forcing transmission to run in the
ionice idle class and set similar classes for the other desktop apps
accordingly. At least to test if the approach would make any difference.

David
___
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] Farewell to the notification area

2010-04-22 Thread David Balch

On 22 April 2010 08:49, Mark Shuttleworth  wrote:

> The workspaces experience has languished, and I'd
> like for us to climb in and improve it substantially. At the moment, we
> do a half-hearted job - we ship what's there but as you say, only
> configure two workspaces. I'd be inclined to say "ship without
> workspaces" so that we are at least definitive about the position for
> the moment.

Presumably you mean shipping with only one workspace enabled by
default, rather than removing the feature altogether.

I think that - even if it isn't in the best possible state - hiding
this excellent feature would be a mistake.
It's a significant feature that Mac users new to Ubuntu would miss,
and Windows users new to Ubuntu would benefit from (if they can
discover it).

Cheers,
Dave.

-- 
http://www.witchesband.com/

___
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] Making workspaces great (branched from "Farewell to the notification area")

2010-04-22 Thread David Siegel

On Thu, Apr 22, 2010 at 9:27 AM, Conscious User  wrote:
>
>> It's a good point. The workspaces experience has languished, and I'd
>> like for us to climb in and improve it substantially. At the moment, we
>> do a half-hearted job - we ship what's there but as you say, only
>> configure two workspaces. I'd be inclined to say "ship without
>> workspaces" so that we are at least definitive about the position for
>> the moment.
>>
>> I'd welcome a discussion about how we could make workspaces *great*. If
>> we can do that, then we would make more of them. And your contribution
>> above is a useful start: great workspaces give you easy access to some
>> apps regardless of the workspace you happen to be in.
>
> I'd love that discussion too. :)
>
> A tabbed system like Robin mentioned sounds very nice to me for two
> reasons: first, it's very familiar as tabbed browsers are nearly
> ubiquitous now. Second, am I the only one here annoyed at the fact that
> there is a *huge* waste of space in the middle of the top panel? This
> would be a very good and use of it.
>
> Brainstorming a little bit, I think a very nice way to visually show
> workspaces this way would be extending the wallpaper to the tabs.
> See the (ugly) mockup I'm attaching here, what you guys think?
>
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

That's interesting.

David

___
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] Making workspaces great (branched from "Farewell to the notification area")

2010-04-23 Thread David Siegel

Guys, this is an excellent discussion. Will someone please volunteer
to organize some of what's been said on a wiki page, or Google
Doc/Wave, or something? Otherwise these ideas will likely never escape
this thread.

David

On Fri, Apr 23, 2010 at 6:41 AM, Robin Anderson  wrote:
> Here's an idea for a kind of Mac OS X Expose fullscreen (in the way Apple's
> Front Row fullscreens) way to move either windows or all windows of an
> application from workspaces. Also is probably touch-friendly. I want to get
> the general idea of moving windows/applications between workspaces by
> dragging *icons* between workspaces out there. Hopefully people get
> inspiration from this.
> Two workspaces, Firefox selected
> http://imgur.com/vZzve.png
> Four workspaces, all of them shown and set to be shown
> http://imgur.com/HBmkx.png
> Four workspaces, two shown and set to be shown, on page one, and Firefox is
> selected
> http://imgur.com/4pMsK.png
> Firefox being dragged to another workspace
> http://imgur.com/pRhzZ.png
> Notes:
> Definitely needs spacing fixed up
> I just used the most basic colors
> Dots are page markers, black dot is the current page
> Brightness up or colored at all basically means selected
> Workspace numbers or names might be good
> I hope:
> A good hotkey system would be included to bring it up and navigate.
> The placement of the close buttons at the top could be customized.
> The color of the boxes around the icons are similar to the panel colors, so
> the way icons for applications are viewed across the system are similar
> I take inspiration from these:
> http://iphonehelp.in/content/uploads/2009/04/safari-30-windows.png (mirror: http://imgur.com/3ZjhY.png
> )
> http://www.flickr.com/photos/totalaldo/4505453992/sizes/o/ (mirror: http://imgur.com/KMvwm.png
> )
> http://davidhayden.com/photos/AppleSpaces.jpg (mirror: http://imgur.com/dYYMz.jpg
> )
> Videos of Apple Spaces on YouTube
> Apple Spaces really looks pretty nice, I've never used them though. There
> are a lot of videos on YouTube showing ways to interact with them. I'm just
> not sure how to get people to start using them unless they're automatically
> activated or used somehow. But what kind of initial setup would be good for
> what applications to open in certain workspaces? What names should default
> workspace have?
> On Thu, Apr 22, 2010 at 6:00 PM, Robin Anderson  wrote:
>>
>> I think a distinction should be made between what would work well on
>> desktops and what would work well on netbooks. Using only maximized windows
>> on a 24in screen for example doesn't sound like something people would be
>> into.
>> As screen size gets bigger I see window management going more towards easy
>> window placement, the way something like Bluetile does perhaps. I think
>> users would want to easily 'dock' windows to take up something like a corner
>> of the screen rather than going between workspaces to interact with multiple
>> windows.
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>
>

___
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] Integrating Application Search & Install

Have you tried GNOME Do? ;)

But seriously, FAYT ("Find as you type") is a simple and powerful user
interface idea that we've been slow to adopt, and I would love to
explore these ideas further and find ways to improve Ubuntu with
find-as-you-type features.

Frederik, I don't see Application Search in my accessories menu, but
if you've found in there it should be very easy to place it in the
top-level applications menu. It would be a great project to improve
this dialog and merge it with the many different Open With... dialog
implementations to introduce FAYT to users.

David

On Sun, Apr 25, 2010 at 2:05 AM, Frederik Nnaji
 wrote:
> Is anybody currently working on integrating a FAYT aka FAST text
> search button/field featuring the incremental search algorithm used in
> the Run Application dialog into the Applications menu already??
>
> right now, Application Search is hidden under Applications > Accessories .
> i would like to see it above the 8 categories.
>
> One could also argue, Ubuntu Software Center should be merged with it.
>
> in that FAYT text search button / field one could integrate
> application and file search in one.
> i think with the right hierarchy and inheritance of topic in an
> interactive dialog resulting from a query in that field, one could
> already access tagged files, folders and such information.
>
> this would help with integrating Ubuntu's current status with the
> backend power and comfort of use GNOME Activity Journal offers.
> is there a simple way of modifying some script or .desktop files to
> achieve this on my own here?
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>

___
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] Integrating Application Search & Install

Keep it simple, focused, elegant. This should feel light, incisive,
precise, fast.

Search is really powerful, and your data set--installed
applications--is small. Adding category filters belies the search
experience.

Frederik, try listing a small set of use cases describing exactly what
you're proposing. It will help keep this discussion focused and
minimize entropy.

David

On Mon, Apr 26, 2010 at 3:59 PM, Frederik Nnaji
 wrote:
> On Mon, Apr 26, 2010 at 16:27, Luke Benstead  wrote:
>> I like the mockup, but I think something similar to the attached would
>> be nicer. I visualize the window only appearing when someone starts
>> typing into the box and the results would filter down. When the user
>> clears the box (or presses enter to execute the top entry) the window
>> would disappear.
>>
>> Luke.
>>
> please, stop saying you like the mockup.. it's just a screenshot ;)
> your mockup is what i'm talking about, i think step by step we're
> getting into business with this idea..
>
> now remove the categories, as suggested above in the thread.
> make the dialog, that pops up as you type, smart, i.e:
> it learns what types of things the user tends to search for.
>
> instead of the existing categories, offer "photos", "music", "videos"
> and "applications", if the user continues the dialog. i think we
> should use the word dialog in its literal meaning here, the depth of
> detail in which options and filters are displayed should grow with the
> depth of steps the user is ready to make (all of them of course
> augmented with the principles of incremental search)
>
> ___
> Mailing list: https://launchpad.net/~ayatana
> Post to     : ayatana@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~ayatana
> More help   : https://help.launchpad.net/ListHelp
>

___
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] Integrating Application Search & Install

Frederik, can you please clean it up a bit? Use correct spelling,
grammar, concise sentences, and normal human names ;) I would expect
that any user implicated by a use case could also read and understand
its specification.

You may also find this Google Docs template helpful for structuring
your use cases: https://docs.google.com/templates?hl=en&q=canonical

David

On Mon, Apr 26, 2010 at 5:43 PM, Frederik Nnaji
 wrote:
> On Mon, Apr 26, 2010 at 18:39, Frederik Nnaji  
> wrote:
>> FAYT METHOD
>> Netbookuser47 presses ALT+F1 [1], is instantly offered "find
>> something.." and begins typing "Zapp" letter by letter.
>
> add:
> [1] ALT+F1 is Superkey in Microsoft Windows.. i never disagreed with
> that mapping on XP.
>

___
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] Integrating Application Search & Install

Seif, that's off-topic. These threads are easy enough to derail!

David

On Mon, Apr 26, 2010 at 5:50 PM, Seif Lotfy  wrote:
> What do you think of http://yfrog.com/g4wacp
> It has been something I have been working on and that also supports live
> searching :)
>
> On Mon, Apr 26, 2010 at 6:43 PM, Frederik Nnaji 
> wrote:
>>
>> On Mon, Apr 26, 2010 at 18:39, Frederik Nnaji 
>> wrote:
>> > FAYT METHOD
>> > Netbookuser47 presses ALT+F1 [1], is instantly offered "find
>> > something.." and begins typing "Zapp" letter by letter.
>>
>> add:
>> [1] ALT+F1 is Superkey in Microsoft Windows.. i never disagreed with
>> that mapping on XP.
>>
>> ___
>> Mailing list: https://launchpad.net/~ayatana
>> Post to     : ayatana@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~ayatana
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>

___
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] Farewell to the notification area