Re: GitLab mirror considered harmful

[William Jon McCann via desktop-devel-list]

On Sun, Feb 3, 2019 at 9:55 PM Jan Tojnar via desktop-devel-list
 wrote:
> 3. GitLab does not support any references from gitrevisions(7) other
> than commit hash, compare
> https://github.com/GNOME/gnome-shell/commit/af34b7c25e39e727f7dbd6e3dae0e7c5fe60f141%5E
> and
> https://gitlab.gnome.org/GNOME/gnome-shell/commit/af34b7c25e39e727f7dbd6e3dae0e7c5fe60f141%5E

I was curious how they compared. This is what I see:
https://imgur.com/a/8K4kGKb
https://imgur.com/a/xbinw1R

Did I do it wrong?

Jon

ps. I tried to send this twice with attachments and I guess it
requires moderation
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Portals and Sandboxing

[William Jon McCann]

Hi,

On Thu, Jan 2, 2014 at 1:45 PM, Michael Ikey Doherty <
michael.i.dohe...@intel.com> wrote:

> Thank you for the clarification. I do believe the GNOME wiki and various
> sites could do with updating and being more informative. I lose count of
> how many times I'm sent to broken/dead/deleted links.
>

 Which pages in particular? I'll try to improve them.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Requiring systemd for the gnome-settings-daemon power plugin

[William Jon McCann]

On Wed, Oct 24, 2012 at 8:47 AM, Colin Walters  wrote:
> On Wed, 2012-10-24 at 10:11 +0200, Bastien Nocera wrote:
...
>> You still haven't answered why it's important to keep ConsoleKit.
>
> Because I'm opposing your methods here on *general principle*.   I don't
> care about ConsoleKit (the codebase) much at all.  What I do care about
> is when I go to GUADEC and hang out with some of the Debian or Ubuntu
> people who rely on CK, we have a sense that we're part of a shared
> project.
>
> I'm all for making GNOME+systemd kick ass.  But not at the cost of
> giving up the "rough consensus and working code" aspect that forms GNOME
> and other FOSS projects.

What this should mean, to me, is that we are all working toward the
same goals. What are those goals? They are perhaps best found by
considering "what does the user see?"

http://blog.fishsoup.net/2011/03/11/what-does-the-user-see/

The code serves that purpose and that purpose alone.

I wrote ConsoleKit. I wrote it for GNOME. I wrote it because we needed
it to get fast user switching working in gnome-screensaver, we needed
it for sane device support I was working on for Rhythmbox, I worked
with David to make sure it fit the needs of HAL, which was needed to
get the device support right for Nautilus. In my first analysis of the
problem I concluded it was something the OS should have been doing all
along and really ought to have been part of the kernel or very low
level userspace. I had started to investigate creating a new init
system that would have a more modern process group / session leader
concept included. At about the same time, Upstart started. The project
seemed promising and I changed my strategy. ConsoleKit was a stop-gap
measure. Just enough working code to do the job we needed, and only
the job we needed, at the time.

But now we have different needs. And something entirely better has
come along. So, I no longer maintain or support the use of ConsoleKit.
I handed ConsoleKit off to Lennart. To do as he saw fit.

I agree with you that it is wrong to arbitrarily remove code from our
core system. That kind of churn is disruptive. It must be motivated by
a need. It should be motivated by what the user will see. And what
experiences we want to provide.

It is. We have designs on the table that motivate the use of systemd.
There are a number of them (some more subtle) but I'll just mention
just two:
https://live.gnome.org/Design/Apps/SystemLog
https://live.gnome.org/GnomeOS/Design/Whiteboards/ProblemReporting

The first one mostly uses the journal directly but the second uses the
journal and probably systemd core to handle some of the response to
application misbehavior.

In addition, we also have had long standing plans to improve the way
we start and manage the session services. I was one of the main
contributors to the current gnome-session. I was clear during that
rewrite that it too was a stop-gap solution. The difficulties there
were quite similar to the start and management of system services. I
investigated logind at the time and decided we should just do
something that solved the immediate need and wait for a more complete
solution. We have one. Systemd can already do this I'm told.

It is motivated by the user experience. Faster start up, more robust
failure detection, better diagnostic information during failures,
consistent tools, etc.

I agree with you that we need to have a motive to change and that
costs should be weighed carefully. We can make the case.

What is unwise, in my opinion, is ifdef'ing or branching the user
experience to suit the code.

I don't think it is useful to even discuss whether we should remove
ConsoleKit or not. We must. It is on life support. If we are still
able to move forward with the user experience changes we need to make
while maintaining some compatibility - fine. But we need to have an
end game. This is a lesson we have learned over and over. Let's not
make the same mistakes again.

I think it would be in the interest of all parties to have the
conversation about why some are unwilling to use the best components
available today to allow us to go forward and make the user experience
as good as it can be. That is the best kind of rough consensus and
working code. The one that matters for what the user sees.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Introducing Photos

[William Jon McCann]

Hi,

On Thu, May 10, 2012 at 12:50 PM, Alberto Ruiz  wrote:
...
> That's not a reason at all, Yorba seems open to work on making Shotwell more
> GNOME 3 friendly... so those widgets can be shared anyway
>
>>
>> Therefore, for these reasons, if you look at the gnome-photos tree, it
>> is almost a clone of the gnome-documents application.
>>
>> So from Shotwell's point of view, would it make sense to replace its
>> existing SQLite store and UI? Would it not be as good as writing from
>> scratch?
>
>
> No.
>
> That makes as much sense as saying that Epiphany should have been written
> from scratch when the "Web" designs were proposed. We had a browser, a new
> design, and developers happy to follow those deisgns.

Sorry, that is totally irrelevant. The real story is that we had folks
show up, say they were excited about the design, have the chops to
pull it off, and want to work closely with us in the open to make it
real. How they went about coding it was entirely up to them. They
chose the most effective way for themselves. That happened to be
reusing code - as it often does.

> Writing software from scratch is almost always a bad idea:
> http://www.joelonsoftware.com/articles/fog69.html

Which is why it was pointed out that Photos has/can/will reuse a lot
of existing code (from Documents, eog, etc). This is particularly
important for allowing us to experiment with our design patterns.
Despite what you may have heard from some folks not involved in GNOME
design, we have been working very hard on this for quite some time
now. The patterns emerge as we explore solving new design problems.
This is why it is important to explore a variety of different
application types. And to have a high bandwidth, trusting, fluid, and
reactive relationship with the developers. See
https://live.gnome.org/Design/Apps/ for more examples of these apps we
want to experiment with.

> Shotwell is widely deployed and used, it has a team of people working on it,
> and a commercial backer. These are VERY important things, prolly the most
> important things to take into account, you worry too much about the data
> store technologies, Tracker is great, but it is by no means the only
> accepted data store in the desktop.

Sure, Shotwell is great. No denying that. I recommend you use it.

What we should not be doing, however, is discouraging new work by
highly motivated and talented community members like Debarshi just
because there is another app out there in the world. He's excited
about the designs, wants to work in the open, understands the GNOME
way, and is really excellent to work with. No one else has stepped up
to make Photos yet.

Regarding the data formats and such. In some cases it doesn't make a
bit of difference. But there are design implications. For example, we
need the core apps in the finding and reminding set to work very
closely together.

  * The Web view must be able to save photos in the Photos
storage/library
(https://live.gnome.org/Design/Apps/Web#Tentative_Design).
  * Content selection must be able to access the Photos
storage/library
(https://live.gnome.org/GnomeOS/Design/Whiteboards/ContentSelection#Tentative_Design)

> If Yorba is open to follow the designs from the GNOME design team, I can't
> see any reason why we shouldn't go that way. IMHO is the quickest and more
> sustainable path to have a great photo browsing experience for GNOME 3.

I have been talking to the Yorba folks for a few years now. In fact,
Matthias and I were very early adopters of Shotwell and provided some
of the earliest patches and shipped it (in Fedora) before anyone else.
I think it is an open question whether the Shotwell team is even
interested in making Shotwell into Photos, making a core GNOME app,
doing design in the open, allowing our translation and bug teams to do
their thing. I would love to see that happen. However, I can certainly
see why it would be very challenging to try to change the direction,
design, and architecture of a stable and widely deployed app. I have
been involved in way too many of those kind of direction changes to
recommend it to anyone. It is much better in my opinion to reuse the
code where it makes sense and start off on a new direction without the
fetters of past expectations. And most importantly be free to fail.
With Photos we can be free to fail, faster.

That said, I love the work the Yorba team has been doing and I applaud
them for targeting the GNOME user experience. That's good for
everyone. I would love to work more closely with them. But, obviously,
that is really up to them. Regardless of what decisions they make
regarding Shotwell I hope to work more closely with this awesome team.
In the open :) But either way I'm happy to just have them making great
apps for GNOME.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes and 3.4

[William Jon McCann]

On Wed, Nov 30, 2011 at 12:26 PM, Vincent Untz  wrote:
> Le mercredi 30 novembre 2011, à 10:31 +0100, William Jon McCann a écrit :
>> Hi,
>>
>> On Wed, Nov 30, 2011 at 8:08 AM, Vincent Untz  wrote:
>> > Le mercredi 30 novembre 2011, à 00:37 +0200, Zeeshan Ali (Khattak) a écrit 
>> > :
>> >> Hi everyone,
>> >>    As most of you know, we proposed Boxes for 3.4 and from what I can
>> >> tell, there were no big objections in the end. There was then the
>> >> question of us actually delivering in time. As seen on planet GNOME
>> >> not long after that, we delivered the first release which was included
>> >> in 3.3.2. There is still a long way ahead to make Boxes the awesome
>> >> app that we all would like it to be but to ensure that Boxes is in
>> >> good enough shape for 3.4 inclusion in time, we would like to know a
>> >> few things:
>> >>
>> >> * which features exactly are must?
>> >> * is the plan to keep vinagre in 3.4 alongside boxes?
>> >> * is Boxes going to be a 'preview' feature in 3.4 like Documents was in 
>> >> 3.2?
>> >>
>> >>  Release team? everyone?
>> >
>> > I'm sorry, but I still have the same objection :-) And talking to a few
>> > people, I understood that I'm not alone in feeling that Boxes might not
>> > fit core GNOME (even as a core app [1]).
>>
>> Can you be more specific about the reasons for your objection?
>
> As mentioned in the previous thread: I don't think Boxes is needed for
> what is our main target audience. And let me state again that it is a
> nice tool for a small part of our users (including our own community).

The only thing you mentioned in the other thread that I saw was a
feeling that it wasn't right. Can you explain why you don't think it
is useful and for what audience?

>> Do you feel the same way about Vinagre?
>
> To me, the main use case of Vinagre is remote desktop administration,
> when coupled with Vino. And that's actually why we added vino in 2.8 (to
> help sysadmins help users), and then vinagre in 2.22 (nice complement to
> vino).
>
> The vino/vinagre duo is/was oriented towards sysadmins (although it
> could be used for other use cases).

Do you think these should not be part of the GNOME core?

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes and 3.4

[William Jon McCann]

Hi,

On Wed, Nov 30, 2011 at 8:08 AM, Vincent Untz  wrote:
> Le mercredi 30 novembre 2011, à 00:37 +0200, Zeeshan Ali (Khattak) a écrit :
>> Hi everyone,
>>    As most of you know, we proposed Boxes for 3.4 and from what I can
>> tell, there were no big objections in the end. There was then the
>> question of us actually delivering in time. As seen on planet GNOME
>> not long after that, we delivered the first release which was included
>> in 3.3.2. There is still a long way ahead to make Boxes the awesome
>> app that we all would like it to be but to ensure that Boxes is in
>> good enough shape for 3.4 inclusion in time, we would like to know a
>> few things:
>>
>> * which features exactly are must?
>> * is the plan to keep vinagre in 3.4 alongside boxes?
>> * is Boxes going to be a 'preview' feature in 3.4 like Documents was in 3.2?
>>
>>  Release team? everyone?
>
> I'm sorry, but I still have the same objection :-) And talking to a few
> people, I understood that I'm not alone in feeling that Boxes might not
> fit core GNOME (even as a core app [1]).

Can you be more specific about the reasons for your objection?

Do you feel the same way about Vinagre?

> [1] http://live.gnome.org/Design/Apps -- just to give an example: I feel
> that a backup tool makes more sense than boxes as a core app, imho. And
> the wiki says that such a tool is very likely not a core app but would
> make a great regular app.

Really, this shouldn't be a competition between Backup and Boxes.
There are a number of reasons why Backup is in (for now) in the
prospective section. None of which are really on topic for this
thread.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Boxes (was Re: 3.4 Features, final round)

[William Jon McCann]

Hey Vincent,

On Mon, Nov 7, 2011 at 3:00 AM, Vincent Untz  wrote:
> Le dimanche 06 novembre 2011, à 17:06 +0100, Frederic Peters a écrit :
>> + Boxes
>>   https://live.gnome.org/ThreePointThree/Features/Boxes
>>   → many commits, mclasen will push the developers to blog a progress report
>>     once they have something to show
>
> While Boxes look interesting, to me, it feels like it's "just" an
> application, and not a feature per se. And I'm not saying that in a
> negative way :-)

Whether Boxes should be part of the feature process is a good
question. To be honest, I'm not sure I totally understand the feature
process as it stands. I think it is good that we have some reigns on
the things that we consider part of the core though and I expect the
process will be refined as we go ahead.

Boxes is indeed an app. However, it is not just any app. It is one of
the special apps that we consider part of the core experience. These
are different from third party apps in a number of important ways. Not
limited to being: designed by the GNOME design team, designed to work
cooperatively with the other core apps, behaviorally and visually
consistent with other core apps, generically named, exclusive to the
GNOME core (not having an external identity or appearing in any app
store or other OS), totally amazing.

They are all listed here:
https://live.gnome.org/Design/Apps/

These are by no means the only apps that we'll see appearing for GNOME
3 but they are a special class. We want to take great care in how they
are designed and built. They are part of the core GNOME experience.

For many of those apps the utility is fairly self evident. I don't
suppose we need to make the case very strongly for Calendar being an
important core functionality. However, I do agree that Boxes may be a
bit more on the edge. There are a few things to keep in mind though.

First is that Boxes isn't just about virtualization. It is useful to
anyone that has ever needed to use a computer that isn't in front of
them physically. That includes virtualized machines both local and
remote as well as remote systems in general. If you are on your laptop
at home and forgot something on your machine at work - theoretically
Boxes can help you out.

Another thing to consider is that Boxes being built-in helps people
test out new releases of our own systems. If you want to try out or
review the latest release of GNOME 3 you don't need to install
additional tools to do so. Just click on the link in the release
announcement and without much delay you have a Box with ready to try.
(sidebar: Windows 8 includes a remote desktop "core app" by default it
seems.)

I think there is a lot of value in embracing virtualization and remote
computing and building it into the core of GNOME in a way that doesn't
make the user think about virtualization or remote computing :)

> So unless I'm missing something, I wouldn't track that as a 3.4 feature.
> We can of course talk about the app when promoting 3.4, though.

To be honest, if you leave out core apps from this process I'm not
sure what is left is all that interesting. Core apps are the
"interesting" parts of the OS.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME user survey 2011 (v4)

[William Jon McCann]

Really ought to stay out of this thread but there is one point that is
important to address below.

On Fri, Aug 19, 2011 at 7:17 AM, Felipe Contreras
 wrote:
> But again, as I said, if there's no survey on Earth you could trust,
> just ignore the results. Results by themselves cannot hurt you.

This isn't right. Poorly understood results lead you draw incorrect
conclusions which lead you astray. Or  at minimum cause the marketing
team undue stress trying to explain that the results don't make any
sense.

Really, I don't understand why anyone would want to go through the
trouble if the results aren't *useful*. Now, if you want to do
something productive I encourage you to work with the guidance of
Allan and others.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On the Interaction with the design team

[William Jon McCann]

Hi,

On Wed, Jun 1, 2011 at 11:06 AM, Johannes Schmid  wrote:
> Hi Jon!
>
>> Are they listening or participating? Transparency and reporting is
>> pretty simple to solve. Publish logs, document (wiki), and blog and
>> you're pretty much there.  Participation and engagement is much
>> harder. Basically you need to find a way to build a relationship with
>> a designer.  It doesn't have to be on IRC. IRC is just one of the ways
>> people actively working on the design of the GNOME core are
>> communicating. Google docs, git, sparkleshare, and IM are others.
>
> Well, currently many people are just listening (logs, wiki blog) because
> they cannot participate. And it is pretty hard to raise a point once the
> "closed group" came to an agreement.
> What happens is that bugs are filed against certain products which stall
> after some amount of discussion. Sometimes even ending in something that
> *can* be interpreted as "Sorry, you are not a designer, your argument
> doesn't count".

This is completely untrue. First of all, we are an open group - with a
very low bar for entry (show up and do good work), that works entirely
in the open. Secondly, no decision is ever made based on authority due
to some silly label. Many/most of the best designers I know are not
*only* designers.

Agreement is reached in various ways. I think it may be useful to
think about decision making using the terminology in something like:
http://en.wikipedia.org/wiki/Responsibility_assignment_matrix

Basically:
 * someone must be responsible
 * someone must be accountable
 * many should be consulted
 * and everyone may be informed

Everyone may have an opinion and they are free to express it. However,
not everyone can be consulted before the fact - it is just practically
impossible. Those opinions, however, should be carefully gathered and
analyzed. There are careers for this.

> I think by seperating developers (and other stakeholders) from designers
> we make a big mistake. Design isn't right just because it is done by
> designers especially when we don't talk about classical design art but
> about user-interface design and usability.

This is simply not true. We do not separate developers and designers at all.

Obvious examples of very close relationships between design and
development: GNOME Shell, System Settings, Nautilus, and everything
that will be in 3.2. :)

> Don't get me wrong, I think the overall design of GNOME 3 is pretty good
> but there are certain corners where it would be good if input from
> non-designers and users would have been considered.

I can't claim that we've heard everything but we've heard a lot - more
than we can handle or process in some cases :)  All of it was
carefully considered. Anyone who knows me at all will understand that.
That doesn't mean it is good for my health :)

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On the Interaction with the design team

[William Jon McCann]

Hi,

On Wed, Jun 1, 2011 at 10:05 AM, Johannes Schmid  wrote:
> Hi!
>
>> On 1 June 2011 12:57, Matthias Clasen  wrote:
>>> Basically, mailing lists don't work for many kinds of productive
>>> discussion.
>>
>> Agreed. In my recent discussions with the dudes in #gnome-design there
>> was a flurry of messages, perhaps as many as 200 back-and-forth
>> discussions per hour. In that same hour, we iterated about 20
>> screenshots and quite a few designers piled in with suggestions.
>>
>> You just can't get that kind of latency and interest level with a mailing
>> list.
>
> So what about those people who simply don't have the time to hang around
> on IRC because of various reasons. Many volunteers have only time to work
> on weekends or in the afternoon and are spread over various timezones. IRC
> is an anti-pattern there as you are excluding all these people.

Are they listening or participating? Transparency and reporting is
pretty simple to solve. Publish logs, document (wiki), and blog and
you're pretty much there.  Participation and engagement is much
harder. Basically you need to find a way to build a relationship with
a designer.  It doesn't have to be on IRC. IRC is just one of the ways
people actively working on the design of the GNOME core are
communicating. Google docs, git, sparkleshare, and IM are others.

Dealing with timezones and distance is a challenge. No doubt about
that. It is a problem even in our own team. However, once a
relationship has been established (trust, respect, and understanding)
it is much easier to surmount. It is most problematic when building
new relationships. My advice to people who want to become involved is
to be clever and find another way to build those relationships. Many
have.

This could mean picking something that is close at hand and making it
awesome and telling the world about it. Or even making something
yourself. It often turns out to be much more effective than just
showing up on IRC and saying - "hi, what can I do?"

No one is excluding you. Don't ask for permission - go ahead, do
something great and let the world know about it.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: On the Interaction with the design team

[William Jon McCann]

Hi,

On Wed, Jun 1, 2011 at 5:31 AM, Dave Neary  wrote:
> Hi,
>
> Allan Day wrote:
>> Dave Neary wrote:
>>> Presumably you & others are still not interested in drawing a few
>>> developers and designers into a gnome-design mailing list, separate from
>>> the usability list
>>
>> I think it's important that we work on being more accessible, and we
>> need to make it easier for people to stay informed about what we're up
>> to in GNOME design, but I don't think a mailing list is a good way for
>> us to do that, and I'm pretty sure the others who are involved in
>> design work feel the same way.
>>
>> So yes, you presume correctly. I'm open to other suggestions though. ;)
>
> That's disappointing. Using IRC really is an anti-pattern which the
> design team should avoid - it's only one step removed from doing
> everything in person or on conference calls.

I think you need to be more clear about what your goals are.

Doing everything in person would be great for design work. This is one
reason why we've been meaning to ask the Foundation to support more
regular design team "hackfests". Using the occasional (video)
conference call has been discussed many times as well.

Design work requires conversation, closeness, and contact. You need to
build a relationship with the problem, the users, the stakeholders,
the developers, and ultimately with the product. These relationships
must be durable. But relationships are hard to do online. Hard to do
long distance - more difficult the farther you are from that
reassuring touch.

Is IRC perfect for this? Certainly not. I didn't use IRC at all until
just 4 years ago - and I still curse at it.  However, it is still much
closer to a conversation than is email. The architecture of email
encourages argument not agreement. Exchanges are volleys. Too much
tactics and too little strategy. It still has a place in the world,
obviously, but not in the tender stages of a design process.

We don't have the perfect solution but I think there is now sufficient
proof that GNOME design is flourishing despite it.  At some point, I'm
sure, this want will motivate an inventor and we'll be even better off
for it.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: systemd as external dependency

[William Jon McCann]

Hi,

On Wed, May 18, 2011 at 9:49 AM, Josselin Mouette  wrote:
> Le mercredi 18 mai 2011 à 14:09 +0200, Lennart Poettering a écrit :
>> systemd itself has very minimal external dependencies. You need Linux,
>> udev, D-Bus, and that's it. (there are a couple of additional optional
>> deps however).
>
> I don’t have anything against requiring systemd, since it is definitely
> the best init system out there currently, but the Linux dependency is an
> absolute no-no for us. Having optional Linux-only functionalities is OK;
> requiring Linux is not.

For Debian perhaps.  However, I don't think this is true for GNOME.
The future of GNOME is as a Linux based OS.  It is harmful to pretend
that you are writing the OS core to work on any number of different
kernels, user space subsystem combinations, and core libraries.  That
said, there may be value in defining an application development
platform or SDK that exposes higher level, more consistent, and
coherent API.  But that is a separate issue from how we write core
GNOME components like the System Settings.

It is free software and people are free to port GNOME to any other
architecture or try to exchange kernels or whatever.  But that is
silly for us to worry about.

Kernels just aren't that interesting.  Linux isn't an OS.  Now it is
our job to try to build one - finally.  Let's do it.

I think the time has come for GNOME to embrace Linux a bit more boldly.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[William Jon McCann]

Hi,

On Fri, May 13, 2011 at 12:55 PM, Robert Ancell  wrote:
>>> - LightDM is a cross-platform solution.  Ubuntu is planning to switch
>>> to it this cycle, and other distributions have expressed interest in
>>> the project.  By sharing this piece of infrastructure GNOME can spend
>>> more time working on important GNOME components.  LightDM is aligned
>>> with freedesktop.org.
>>
>> There isn't a lot of value in having a core GNOME component be cross
>> platform or cross desktop.  There certainly isn't any value in that
>> for a user.  There are, however, a number of reasons why this isn't a
>> good thing.  GDM was explicitly designed to be a core GNOME component.
>>  The primary goal is to have a consistent and unified experience from
>> power on to power off.  Having a cross desktop component in there
>> doesn't really make any sense to the end user.  It doesn't match the
>> look and feel, the interactions are different, the default settings
>> and behaviors are different.  That is what GDM circa 2005 was like.
>> And it wasn't good.
>
> There is a huge amount of value in having shared components where
> appropriate.  And this does have a direct value for users - if we
> spend time duplicating common elements then that is time not spent
> working on the the part the users do see.  LightDM makes a very
> explicit boundary between the core aspects and the UI, I really fail
> to see how using a shared component for the lower level has any
> negative effect on users.

In your proposal you did not mention one thing that would
significantly or directly improve the user experience.

...
>>  * I don't see any compelling reason to architecture astronaut a new
>> display manager
>
> I am completely sick of the lack of respect shown by some in the GNOME
> community to alternate viewpoints.  I'm tired of being compared to an
> attention-deficit teenager, told I have not-invented-here syndrome,
> told that the team I work on only chose this project because we want
> to be different to GNOME, told that by not continuing on existing
> codebases (regardless of how much time and effort I have spent on
> that) I am betraying GNOME.  It's just beyond acceptable.
>
> I was not going to propose this project because I am sick of this sort
> of unprofessional response, especially from leaders in the community.
> It was the insistence of other leaders in the GNOME community that I
> did end up proposing and the continual complaints from users,
> sysadmins, customers, designers, and programmers about the login
> experience.

I have no idea where this is coming from.  Is this directed at me?  It
is certainly a serious overreaction to my statement that a proposal
that is based on an internal architecture change, that uses lines of
code as a metric, and didn't include a single thing that would improve
the user experience seems to me like architecture astronauting.

>>  * None of the stated reasons have a significant user visible benefit to 
>> GNOME
>
> You really need to really consider that this model of what benefits
> users is an over-simplification.

No it isn't.  It is what matters most.

My recommendation would be to first focus on improving things for
users (like some of the things listed in my previous message) and then
think about what internal architecture you require in order to get
that done.  That's how we normally do things in GNOME.  This proposal
appears as a bit of a departure from that.  I would also recommend
that you listen to the folks giving you advice on these matters rather
than think of it as a fight of some kind.  Don't take it so
personally.  Many of us have been down these roads many many times.
It isn't about you - people are naturally concerned when it appears
(rightly or wrongly) that lessons of the past are being ignored.  I
also caution you and others from thinking of freedesktop as some kind
of cross platform sanctuary.  It isn't.

I think the reactions you are getting here are entirely due to the way
you are pitching the project.  And nothing at all to do with you, the
quality of your work, or the leadership of GNOME.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New module proposal: LightDM

[William Jon McCann]

Hi,

On Fri, May 13, 2011 at 8:59 AM, Robert Ancell  wrote:
> I'm proposing LightDM [1] as a replacement for GDM.  I started the
> proposal for this in GNOME 3.0 [2] but due to the young age of the
> project I thought it better to wait until 3.2 before making a full
> proposal.  This is it.  I apologise this has been done after the
> proposal period.

There actually isn't a module proposal period anymore.  We are using
feature or design proposals now.

> Why replace GDM?
>
> - LightDM is a cross-platform solution.  Ubuntu is planning to switch
> to it this cycle, and other distributions have expressed interest in
> the project.  By sharing this piece of infrastructure GNOME can spend
> more time working on important GNOME components.  LightDM is aligned
> with freedesktop.org.

There isn't a lot of value in having a core GNOME component be cross
platform or cross desktop.  There certainly isn't any value in that
for a user.  There are, however, a number of reasons why this isn't a
good thing.  GDM was explicitly designed to be a core GNOME component.
 The primary goal is to have a consistent and unified experience from
power on to power off.  Having a cross desktop component in there
doesn't really make any sense to the end user.  It doesn't match the
look and feel, the interactions are different, the default settings
and behaviors are different.  That is what GDM circa 2005 was like.
And it wasn't good.

> - I am confident that the LightDM architecture is simpler than GDM.
> Some indicators of this:
>  - Smaller code size
>  - Well defined interface between greeter and session
>  - Less dependencies
>  - Less internal interfaces
>  Architecture can be a personal opinion, and I encourage those with
> programming experience to look at the code and decide for themselves.
> Note that LightDM is not lighter in features, but in architecture.

There is no value to the user in a different internal architecture.
The complexity of GDM is not due to our love of complexity.  It was
out of necessity.  Dealing with PAM correctly and securely is a pain
in the ass.  Dealing with secure separation of the greeter is a pain
in the ass.  Designing with a goal of integrating screen lock
functionality into GDM resulted in some technical decisions that made
things more of a pain in the ass.

Now there are certainly things we can improve there.  There is a fair
amount of unused capability.  The reason why it hasn't been removed is
simple.  It is not a good idea to redesign the internal architecture
of the login manager until:

 a) we merge the multi-stack authentication technology - this stuff is
neat and lets you run multiple pam stacks simultaneously - user
benefit being that you can authenticate with a fingerprint or
smartcard while another pam stack like normal password is blocked
waiting for input
 b) we figure out the best way to implement our designs for
https://live.gnome.org/GnomeShell/Design/Whiteboards/LoginScreen
 c) we figure out the best way to finally have good screen unlock
functionality that supports touch and a11y
 d) we figure out what the story will be with systemd multi-seat and
how it impacts a login manager

Those are important goals.  Things that will matter to the end user.
Changing code bases will not help solve them.

> - By having a well defined interface between the greeter and daemon,
> it is significantly easier to develop a greeter without knowledge of
> how display management works.  This is useful as the skillset and
> motivations of these two sets of developers are different.

Having lots of different greeters isn't an important goal.  Having one
that works really well, and integrates well with the rest of the OS
is.  That is the goal of the GDM interface.  Standardization of that
interface is not a good idea.  It just needs to get the job done.

> - LightDM is a platform for future work and is investigating the use
> of new technologies like Wayland.

Yes Wayland is very awesome.  I fail to see how this is a good reason
to switch to a new login manager.


Anyway, I don't really maintain GDM anymore so hopefully Ray will
respond with some more details but basically:

 * I don't see any compelling reason to architecture astronaut a new
display manager
 * None of the stated reasons have a significant user visible benefit to GNOME
 * We really ought to be spending our time on higher level, bigger
picture integration issues
 * If there are problems with GDM we should just fix them
 * This is just not the right time to consider this (see list above of
important issues to consider first)

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

[William Jon McCann]

Hi,

This thread has clearly jumped the shark but there is one point worth
responding to here.  (which is a shame because deja dup is really
pretty cool.  It is too bad the thread was turned on a tangent)

On Thu, May 12, 2011 at 9:28 PM, Luca Ferretti  wrote:
...
> And note, while this is just an example, similar customizations are not
> rare in the real world. Preventing people "a priori" (professionals, not
> "kids in the basement") to use GNOME as a base to build something
> different IMHO means to fail as open source project.

As long as we're throwing around Latin phrases to sound fancy we may
as well use some French as well.

How about: raison d'être.  What is our mission, what is our reason for
existing?  Is it to provide a gummy base for others to adapt, modify,
and differentiate?

No.

It is to create the most beautiful computing experience we can
imagine, using free software, that helps provide access to a web of
enlightenment, freedom of expression, and connections to people you
would ordinarily never have in the physical/political world.
Something that, because it is free software, allows anyone to actively
participate in the future - rather than simply passively consume.
Feel free to call that what you like.  I call it an operating system.
It is what we've been working to create for a decade now.  We (GNOME)
have built nearly all of the modern Linux user-space subsystems to
facilitate this goal.  It is not new or novel.  It is why we are here.
 There is no point in being timid about this.  It is brave and it is
meritorious.

Does our work, by its nature, allow or encourage modification,
adaptation, and reinvention?  Absolutely.  Is that enough?  No.  We
expect more of ourselves and the world expects more from us.

Very pointedly, GNOME does not exist exclusively for the benefit of
derivatives.  The reason people react strongly to that suggestion is
that it is profoundly disrespectful to the hundreds or thousands of
people working passionately to craft a intentional and exceptional
user experience with GNOME.  We are building a thing and we've been
doing it for a long time and will continue to do so.

The fact that you can modify it is an artifact of the methodology and
is not our core purpose.  We care about what the user sees.  We care
about user experience and we take design seriously.  And to be
successful that is exactly what we must do.

> Well, of course I've another option. Switch to KDE as base system :)

If these goals do not align well with yours, you are free, of course,
to do as you wish.  But as you know such an exclamation is typically
considered, as with Godwin's law, to signal the end of a conversation.
 And I hope it is.

Love,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: no external panels for gnome-control-center [was GNOME Feature Proposal: Backup]

[William Jon McCann]

Hi,

On Thu, May 12, 2011 at 6:13 PM, Robert Ancell  wrote:
> On 12 May 2011 23:42, Luca Ferretti  wrote:
>> Il giorno gio, 12/05/2011 alle 20.45 +0100, Sergey Udaltsov ha scritto:
>>
>>> GNOME is not an OS. GNOME is not a distribution. GNOME is a core
>>> desktop ("desktop building toolkit", if you like) that is used by
>>> distributions - it is them who define the _final_ user experience. Do
>>> we all agree that GNOME should be distribution-friendly, that GNOME
>>> should trust distributions, make their life reasonably comfortable?
>>
>> I totally agree, IMHO GNOME is a base to allow distributors, vendors and
>> third parts to build up and extend their own user experience and
>> services and "fight" on free market. No competition means stagnation.
>>
>> But it seems by now we are a small minority :-|
>>
> Or are we a silent majority?  It seems we don't have enough
> information to say either way.

Either way, it isn't what GNOME is about or really has ever been
about.  Please read:
http://blog.fishsoup.net/2011/03/11/what-does-the-user-see/

There isn't any point in spending time to design, plan, craft a user
experience for it to be just bits of putty in another's hands.  That's
an absurd premise.

Very simply, we aim for external competition, internal cooperation.
Not the other way around.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Musings on the contacts user experience

[William Jon McCann]

Hi,

Some very brief thoughts.

On Fri, Apr 29, 2011 at 10:13 AM, Alexander Larsson  wrote:
> On Fri, 2011-04-29 at 13:19 +0100, Allan Day wrote:
>
>> In general, then, my current position is that, despite it not being the
>> primary way in which people will access messaging, we do still need a
>> dedicated contacts app. I am open to being convinced that an integrated
>> IM/contacts app would work, but I would want to see the 3 issues I've
>> identified above resolved.
>
> Yeah, this, and the fact that Gnome 3.0, with gnome-shell and the
> non-spatial nautilus is very much going in the app-centric direction
> convinces me that you are right. That means we should probably not have
> the people tab, which is a good thing too as i kinda agree with matthias
> fear of piling all sorts of cruft into overview tabs. Also, we should
> probably not allow contacts on the dash.

Another thing is that using Overview views for information types that
are nearly unbounded like "people" is really difficult.  Browsing
isn't really a good interface for things like this.  More on this
below.

>> Until I'm convinced otherwise, this is my vision for how the different
>> GUI parts of our contacts framework, then:
>>
>>  * An add contacts dialog that can be used by different applications.
>> This would, for instance, provide a graphical means to easily add recent
>> or favourite contacts to an email. This GUI would probably be similar to
>> the contacts app, and would probably share the same code base.
>>
>>  * A dedicated contacts app for when you need it.
>>
>>  * Contacts search (but no contacts tab) in the shell overview, which
>> will provide a quick way to initiate conversations.
>>
>>  * In the future - a conversation focused IM app, and possibly even a
>> conversation focused email app
>
> Yes, I like this. The conversation focused IM app is especially nice, as
> it makes the difference between the contacts app and the chat app much
> more obvious.
>
> It also means that some of the concept design on the contacts app needs
> a bit of rethinking, as they focus quite a bit on initiating IM
> communication (via shortcuts on the main window, etc).
>
> Additionally I'd like to have an easy-to-integrate widget that lets apps
> pop up contact information on hover/click on any "address" shown in the
> ui (like all visible email addresses in evo). That would show contact
> info, current im status, last tweet, etc.

I agree we need both a people app (Contacts) and a messages app (Chat).

There are key differences between people and messages:

1. People
  * Frequency and recency are basically meaningless (recent what?)
  * Browsing based interfaces aren't practical without heavy use of
pages, indexes, tags, groups, etc
  * Search (or search assisted direct entry) is the primary mode of access

2. Messages
  * Recency is most important because it indicates currency
  * Frequency (with windowing) is important because it indicates
durable relationships
  * Browsing history is relevant for finding and reminding
  * Resuming from a history is the primary mode of access

Those are the big differences I think.  There are lots of other more
subtle distinctions of course.  For example, in how starring, or
bookmarking works.  Different enough to deserve treatment in separate
apps.

So, my quick recommendations:

1. Contacts
  * A new application exclusive to and designed for GNOME
  * Searchable through the OS overview
 - Activating search results opens contact in Contacts app
  * App is primarily search based as well
  * Browsing is assisted through index paging
  * Primary way to initiate new conversations regardless of method
  * Should seamlessly integrate contacts from various Online Account providers

2. Chat
  * We initiate a new design exclusive to and designed for GNOME
  * Serves as the app backing the integrated GNOME chat functionality
  * Message based - a historical log of "conversations"
  * This serves as a record of what chats were performed / missed

> My main fears in a setup like this is:
>
> * Conceptually a "chat" app needs to be running all the time when you're
> online (as you might get a message), but generally you don't want to see
> it all the time. With us not having a "good" solution to minimize, and
> not liking minimize-to-systray-icon we don't have a good way to
> represent this "running in background" state. The one way to fit this
> into the shell design is to just put the IM window on some other
> desktop, but I think that might still be a bit too visible.

The chat app doesn't have to be running, really.  The OS shell itself
will happily receive that new message for you.  The issue is really
more about sign in and sign out.

> * I fear as we add more kinds of hits into the overview search it will
> eventually become useless (giving too many hits). We need to be consious
> about this and limit the number for items we search. For instance, if we
> search in all files on your system its likely that almost 

Re: [gnome-session] rename gnome-session-save to gnome-session-quit

[William Jon McCann]

Hi Vincent,

I wrote most of gnome-session and am still listed as a maintainer.
So, I'm not sure what the problem is.  I agree in principle with using
code review which is why I asked a few people to look the patch over
for me.

This is crunch time man.  It is all about getting it done.

Thanks,
Jon

On Mon, Feb 28, 2011 at 7:56 AM, Vincent Untz  wrote:
> Hi,
>
> (I don't want to pick on Jon here; that's just the latest commit like
> this one)
>
> I would appreciate if patches could get posted on bugzilla for review,
> instead of being committed directly without asking maintainers. I know
> I'm not the fastest reviewer out there, but as I've told several times
> before, if you think the patch is important and doesn't get a review
> before the next release, then it's welcome to push the patch.
>
> In this case, the patch is mostly good, but the man page is wrong
> (--logout is the default behavior, but it's not mentioned and it's
> unclear what happens by default; --no-prompt doesn't do anything with
> --power-off).
>
> Vincent
>
> Le jeudi 24 février 2011, à 22:56 +0000, William Jon McCann a écrit :
>> commit 8663860ff44b9a5e441e4909a49eee4cfa08378d
>> Author: William Jon McCann 
>> Date:   Thu Feb 24 17:38:13 2011 -0500
>>
>>     rename gnome-session-save to gnome-session-quit
>>
>>     Is much less misleading since it doesn't save anything.
>>
>>  doc/man/Makefile.am                                |    2 +-
>>  doc/man/gnome-session-quit.1                       |   25 
>>  doc/man/gnome-session-save.1                       |   40 ---
>>  po/POTFILES.in                                     |    2 +-
>>  tools/Makefile.am                                  |   10 +-
>>  .../{gnome-session-save.c => gnome-session-quit.c} |  116 
>> +++
>>  6 files changed, 51 insertions(+), 144 deletions(-)
>> ---
>> diff --git a/doc/man/Makefile.am b/doc/man/Makefile.am
>> index 72f9a93..e42430a 100644
>> --- a/doc/man/Makefile.am
>> +++ b/doc/man/Makefile.am
>> @@ -1,7 +1,7 @@
>>  man_MANS =                           \
>>       gnome-session.1                 \
>>       gnome-session-properties.1      \
>> -     gnome-session-save.1
>> +     gnome-session-quit.1
>>
>>  EXTRA_DIST =                 \
>>       $(man_MANS)
>> diff --git a/doc/man/gnome-session-quit.1 b/doc/man/gnome-session-quit.1
>> new file mode 100644
>> index 000..2f6df84
>> --- /dev/null
>> +++ b/doc/man/gnome-session-quit.1
>> @@ -0,0 +1,25 @@
>> +.\"
>> +.\" gnome-session-quit manual page.
>> +.\" (C) 2000 Miguel de Icaza (mig...@helixcode.com)
>> +.\" (C) 2009-2010 Vincent Untz (vu...@gnome.org)
>> +.\"
>> +.TH GNOME-SESSION-QUIT 1 "GNOME"
>> +.SH NAME
>> +gnome-session-quit \- End the current GNOME session
>> +.SH SYNOPSIS
>> +.B gnome-session-quit [\-\-logout] [\-\-power-off] [\-\-no-prompt]
>> +.SH DESCRIPTION
>> +The \fIgnome-session-quit\fP program can be used to end a GNOME session.
>> +.PP
>> +If called with the \fB\-\-logout\fP option the user will be prompted
>> +to confirm logout.  The \fB\-\-no\-prompt\fP option can be used to end
>> +the session without user interaction.
>> +.PP
>> +When the \fB\-\-power\-off\fP option is given the user will be
>> +prompted to confirm system power off.  The \fB\-\-no\-prompt\fP option
>> +can be used to power off without user interaction.
>> +.SH BUGS
>> +If you find bugs in the \fIgnome-session-quit\fP program, please report
>> +these on https://bugzilla.gnome.org.
>> +.SH SEE ALSO
>> +.BR gnome-session(1)
>> diff --git a/po/POTFILES.in b/po/POTFILES.in
>> index 4b3a1a1..1e7491d 100644
>> --- a/po/POTFILES.in
>> +++ b/po/POTFILES.in
>> @@ -20,4 +20,4 @@ gnome-session/gsm-xsmp-client.c
>>  gnome-session/gsm-xsmp-server.c
>>  gnome-session/gsm-util.c
>>  gnome-session/main.c
>> -tools/gnome-session-save.c
>> +tools/gnome-session-quit.c
>> diff --git a/tools/Makefile.am b/tools/Makefile.am
>> index fbc41b5..f53a012 100644
>> --- a/tools/Makefile.am
>> +++ b/tools/Makefile.am
>> @@ -1,14 +1,14 @@
>> -bin_PROGRAMS = gnome-session-save
>> +bin_PROGRAMS = gnome-session-quit
>>  libexec_PROGRAMS = gnome-session-is-accelerated
>>
>>  AM_CPPFLAGS =
>>
>>  AM_CFLAGS = $(WARN_CFLAGS)
>>
>> -gnome_session_save_SOURCES =                 \
>> -     gnome-session-save.c
>> +gnome_session_quit

Re: IRC channels in gnome development

[William Jon McCann]

Hi,

On Mon, Feb 7, 2011 at 5:58 PM, C.J. Adams-Collier  wrote:
> On Tue, 2011-02-08 at 01:04 +0530, Nirbheek Chauhan wrote:
>> On Tue, Feb 8, 2011 at 12:22 AM, Andre Klapper  wrote:
>> > On Sun, 2011-02-06 at 19:19 +0530, Nirbheek Chauhan wrote:
>> >> Is there a place where IRC logs of discussions from the various
>> >> channels can be found?
>> >
>> > I am not aware of any automated GimpNet IRC channel logging and
>> > publishing.
>> >
>>
>> It would be very useful to have a bot around which logs conversations
>> on #gnome-{shell,design,os}
>
> done, done and done.
>
>> et al
>
> You'll have to be more specific.
>
>> and puts it up somewhere.
>
> http://ilbot.colliertech.org/gnome-shell/today
> http://ilbot.colliertech.org/gnome-design/today
> http://ilbot.colliertech.org/gnome-os/today
>
>
>> A number
>> of GNOME channels already have bots to manage chanops, those could
>> probably be put to this use as well, if possible.
>
> Poke me if things go offline.  My web server isn't the most stable thing
> in the world.
>
>> To cover the conversations that have already happened; maybe people
>> can put up their logs of these channels of the past year (or whatever
>> they have). We can then patch up the various logs to make a full log.
>
> Let me know when you've got them and I'll post them in the same place.

bebot has been logging for some time.  I'd prefer it if we have only
one mechanism in place.  We haven't had a chance to figure out what to
do with the logs (including where to post them, how to present them,
and how to search them).  Another issue is that I want to ensure that
it is well known that the channels are logged (I consider it impolite
to post logs from folks that don't know they are being logged) and
that we make some assurance that sensitive information doesn't
accidentally get published (at least until you can change that
password you accidentally typed into IRC).

Would you mind disabling your bot until we do that?

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: My thoughts on fallback mode

[William Jon McCann]

Hi,

On Tue, Jan 4, 2011 at 2:34 PM, Olav Vitters  wrote:
> On Tue, Jan 04, 2011 at 06:37:33PM +0100, Gendre Sebastien wrote:
>> Le mardi 04 janvier 2011 à 10:54 +0100, Christopher Roy Bratusek a
>> écrit :
> [..]
>> > GNOME3 + Compiz = Fail ... or: GNOME3 + Sawfish = Fail
> [..]
>> I agree with you Chris. The non-modularity of GnomeShell and the
>> non-mind-open of her dev team is problematic.
>>
>> I tried to give my opinion about Gnome Shell on its mailing list and I
>> was ignored. I tried the IRC chat and I was insulted (some people say
>> that I'm contitioning, unable to think by myself). This is intolerable
>> in a community project.
>
> Being ignored is not the same as being insulted. With being ignored, it
> is unfortunate, but there can be multiple reasons why this happens. Just
> as simple as holidays or overlooking an email. Though could even be that
> you've asked something which was explained various times before.

Let's be very clear about this.  No one on the shell list is ignored.
Every message is read and considered.  However, it is unreasonable to
expect that every thought, suggestion, flame will get a response or
change the direction of the project.  Not if we ever want to get
anything done.  A thoughtful response that doesn't come off as
extremely curt or rude takes a considerable amount of time.

We're all working pretty tirelessly to make something wonderful for
ourselves, for you, and for the world.  With any luck that will be
evident in time.

An open creative process is a serious challenge.  Imagine trying to
plan and prepare a meal in a commercial kitchen with a hundred
self-described foodies hovering about you.  Whether or not any of the
advice and criticism is valid is almost beside the point - it is just
not helpful in that form or forum.  There is no sense getting all
peeved that your advice was unheeded or that the frantic, sweat-tinged
labor did not take a moment to address your concerns.  Your challenge,
if you really do want to be influential, is to find a place for
yourself in the process.  Learn how to become a valuable and trusted
collaborator.  To be sought out for consultation, to be trusted to
work independently toward a shared goal, to take a personal stake in
the outcome.

Are you ready?  Go grab an apron, wash your hands, tie your hippy hair
back.  We've got mouths to feed.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-panel & gnome-applets?

[William Jon McCann]

Hi Vincent,

On Wed, Dec 29, 2010 at 2:05 PM, Vincent Untz  wrote:
> Le mardi 28 décembre 2010, à 15:20 +0100, Olav Vitters a écrit :
>> However, the fallback is meant as a fallback, not as providing
>> gnome-panel and its applets. So I don't see anything wrong with not
>> providing the applets. While at the same time, I don't see anything
>> wrong with releasing a new gnome-applets tarball.
>>
>> Meaning: GNOME 3 is not gnome-panel and never will be. But if someone
>> still hacks on gnome-applets nobody will work against them.
>
> FWIW, I personally don't like calling this "fallback" and that's why I
> named it "Classic GNOME" in gnome-session.

Ah, so that may be the source of this particular confusion.  I think
we should fix that.

> Sure, it's not our priority nor target, in terms of development (and it
> shouldn't be). But to a lot of people, "fallback" means "you'll get some
> ugly stuff that barely works", and while I do think we want to push
> people to use GNOME Shell, there's no reason to make users who can't
> use it feel second-class GNOME users.

It is second class I don't think there is any point in whitewashing
it.  Whether or not you get something that barely works has everything
to do with how much attention it gets in design, development, and
testing.  If you want to use something for a fallback that won't
really get any of those three it had better be simple as hell.  And
ban any complexity that does not provide essential functionality.

It is also important to indicate to the user that the fallback is not
normal.  Due to some kind of failure they are receiving a sub-optimal
experience.  That is incompatible with the design goals of something
that would have equivalence to the default.

Again, our message should be simple: if you don't have hardware that
will work - don't upgrade.  Ideally, OS installers should be able to
provide a crystal clear indication to the user (probably by actually
trying to run a similar shell).  Or rather, ideally we'd design or
certify hardware.

> Using gnome-panel+metacity as a fallback is not incompatible with having
> gnome-panel+metacity offer a usable desktop. There are people who care
> about this mode, and it's up to those people to step up to make sure it
> will be usable.

I don't think that is right.  I don't think we can simultaneously
design the fallback experience to be consistent with and minimize the
differences from the default and keep it an entirely distinct and
"classic/traditional" mode.

If someone wants to fork off and continue to maintain a GNOME 2-like
experience they are certainly free to do that but I am strongly
against calling it GNOME.  As we can see in this thread we already
have enough confusion about what GNOME 3 is and will be.  Adding to it
seems like a really bad idea to me.

That simple JS based fallback panel/menubar idea is sounding better
and better... anyone want to give it a shot?

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-panel & gnome-applets?

[William Jon McCann]

Hi Carlos,

On Thu, Dec 23, 2010 at 1:54 PM, Carlos Garcia Campos
 wrote:
> Excerpts from Frederic Peters's message of jue dic 23 10:22:40 +0100 2010:
>> Hi,
>>
>> Sergey Udaltsov wrote:
>> > I am confused, what's the story with gnome-panel and gnome-applets in
>> > 3.0? Are they in, are they out? If gnome 3 is to support gnome2 compat
>> > mode, both of these components should stay in for some while, right?
>> > Currently, the situation in in jhbuild is very strange: gnome-panel is
>> > still there, gnome-applets are gone. Is this planned? Who'd need the
>> > panel without the applets?
>>
>> I pointed this after the new modulesets were pushed, you can read the
>> answer Jon gave here:
>>  http://mail.gnome.org/archives/release-team/2010-December/msg4.html
>>
>> The relevant part:
>>
>> | >>  - gnome-applets (even if we still have gnome-panel)
>> |
>> | RIP.  Essential applets should be part of gnome-panel itself.  It
>> | doesn't make sense to have applets only in the gnome 2 fallback
>> | experience.
>
> I disagree. If I run gnome-session with the classic mode I expect to
> see exactly what I have right now, with all the applets. The
> definition of essential applet is probably different for every user.
> GNOME 2 fallback experience should be gnome-panel, metacity and
> gnome-applets.

It is important to note that there is no such "classic mode".  There
is a fallback mode for when 3D support is not available.  The fact
that it will use some of the GNOME 2 components is mostly an
implementation detail - it is way more efficient than building
something else.  (That said, I think someone could hack up a simple
panel + system status equivalent in javascript in no more than a few
weeks if they wanted to.  And I think that would actually be
preferable for a number of reasons.)

There is no "I want a new GNOME but not GNOME 3 mode."  There aren't
two GNOMEs - only the one we barely have enough help designing,
building, and testing already.  If you want your system to be exactly
as it is now my recommendation would be to leave it just as it is now.

It doesn't make any sense for the user to have an entirely different
concept in the fallback that isn't available in the default.  Nor does
it make any sense for us to provide a developer API and add-on system
that only works in the fallback mode.

GNOME 3 is a change.  Both the default and the fallback modes will be
different from GNOME 2.  We can't and shouldn't shy away from that.
People who don't desire such changes are not obligated to make them.

Cheers,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 2.91.1 status

[William Jon McCann]

Hi,

On Wed, Oct 20, 2010 at 6:36 PM, Stef Walter  wrote:
> On 2010-10-20 11:39, Lucas Rocha wrote:
>> seahorse doesn't build with libnotify 0.7
>> https://bugzilla.gnome.org/show_bug.cgi?id=632712
>
> What's the replacement in libnotify for attaching a notification to a
> widget? The following commit doesn't say much:
>
> http://git.gnome.org/browse/libnotify/commit/?id=27e05d0f9562a26163493d6cc1d5924b9a4ebf68

There isn't a replacement.  You can still pass in the hint but the
notification servers will ignore it.

> Is there a mailing list where libnotify is discussed or some more
> information would have been posted? Sorry if I missed something obvious.

There are some additional notes here:
http://live.gnome.org/GnomeShell/Design/Guidelines/MessageTray/Compatibility

Will add more there as time allows.  But, if you have any additional,
specific questions I can try to answer them for you.

As far as a mailing list, discussing here is fine.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: splitting up gnome-games

[William Jon McCann]

Hi,

On Mon, Oct 4, 2010 at 11:30 AM, Colin Walters  wrote:
> Hi,
>
> I'd like to float the idea of splitting up gnome-games upstream into
> separate git modules.  The main rationale is that downstream, we want
> separate binary packages; this is most convenient to do if upstream is
> separate modules.
>
> Having separate binaries would make application installation/removal
> saner, and avoid pulling in the large dependency set of the games as
> one unit.
>
> Also, if there are any other git modules that ship multiple
> applications (i.e. .desktop files and executables), I'd like to see
> that split up too.

I think this makes a lot of sense.  You've already mentioned a few
reasons for why these meta-module constructions are problematic - but
they aren't the only ones.  Meta-modules like gnome-network,
gnome-media, gnome-utils, and even gnome-control-center for a long
time (though for GNOME 3 we've given it a new focus) were very
difficult to maintain and hence very poorly maintained.  There are a
number of reasons for this but one big part of it is that
maintainership was essentially per-submodule.  That really breaks the
maintainer model that we use and there was a bit of tragedy in that
unowned commons space.  Just promote them to full modules and break
out the shared bits into libraries.  It simplifies things a great
deal.  Code responsibilities/duties/blame, git history/branches/tags,
and bug-tracking/patch-review will all be much more straightforward
and clear.

In GNOME 3 we will be bringing app identity into more focus too.
Basically if you are creating a user facing interface you are either
an application or part of the core UX.  That doesn't really match up
very well with the meta-module approach of a loose grouping of
windows/dialogs that (incompletely and loosely) match a certain
category.  We're better off with a one-to-one mapping of module to
application and a type of tagging system to identify the app as a
game, sound or network utility, etc - either in an app store, distro,
or jhbuild.

There may have been valid reasons why meta-modules were convenient in
pre-git days but those reasons no longer apply.

If we find that we don't have a maintainer for a certain submodule
that isn't a reason not to break it out of a meta-module.  That is a
reason to break it out and mark it as unmaintained - or drop it.  As
well as an opportunity for new contributors.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: (L)GPLv3

[William Jon McCann]

Hey Ryan,

On Tue, Jul 6, 2010 at 9:00 AM, Ryan Lortie  wrote:
> hi Vincent,
>
> On Tue, 2010-07-06 at 09:26 +0200, Vincent Untz wrote:
>> Do you feel okay with the idea of allowing proprietary apps to use our
>> platform but not GPLv2 apps?
>
> In short, yes.
>
> Anybody who has an application that is GPLv2-only and has accepted
> enough contributions that it has become an unreasonable proposition to
> relicense has made a significant mistake.  I don't want to punish them
> or anything, but they are the ones who picked a licence that prevents
> them from linking against just about anything.

At least one company in our ecosystem has been, at least in some
cases, writing GPLv3-only code.  Which seems like an odd choice to me
that probably needs some justification.

There have been a couple emails back and forth from the FSF to attempt
to clarify how GPLv3-only interacts with GPLv2+ etc code.  The FSF
compatibility matrix doesn't really address that.

I would suggest that the people who want to use GPLv3 make their own
case for it, publicly.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Modulesets Reorganization

[William Jon McCann]

Hey Lucas,

Overall this sounds good to me.  Definitely a step in the right direction.

...
> In summary, this means that the GNOME releases would be composed by the
> following modulesets:
>  - Desktop
>  - Platform
>  - Extended Platform
>  - Mobile

A few questions about this list.  Is Platform a platform for creating
an OS core or a platform for creating applications?  There is a
difference.  Today, our story there is muddy.  We don't really have a
strong application development platform.  Certainly, for example,
nothing like:
http://developer.palm.com/index.php?option=com_content&view=article&id=1654

If Platform really means OS Platform then I'm not sure it makes sense
to identify this separately from the product release (that which we
call Desktop now).

Why is Mobile separate?  I suppose this really means Mobile OS
Platform since we don't yet have a GNOME user experience for mobile
devices.  However, since GNOME 3 is already targeting netbooks and
tablets we will soon.  I would say that we shouldn't dilute the GNOME
brand and resources on a Mobile module set until we have a GNOME user
experience for handhelds.

GNOME 3 is not a grab bag.  It is a set of experiences around an OS.
This OS is defined by the user experience of the core (or shell) and
the vibrancy of the marketplace of add-ons (applications).  The
vibrancy of the marketplace is at least partially related to the
simplicity, coherency, and suitability of the application development
platform.

To me, GNOME offers three things:
 1. Core OS user experience
 2. Application developer experience
 3. Application ecosystem

With GNOME 3, so far, we have been focused on addressing 1.  And this
proposal partly reflects that.  But I think we'll need to eventually
shift our focus to the other two.  We haven't really tried to design 2
much yet - not from an experience design perspective anyway.

So, what is part of 1 and what is part of 3?  One way would be to
start by ask the following questions:

 * Does the overall design of the system call for it?
 * Is it compatible with the core system design?
 * Does it integrate tightly with the core system?
 * Does it meet all of the minimum requirements for the core system?
 * Are you willing for it to have a generic identify or lack a
distinct identity and be only part of the system core?  (See
http://blogs.gnome.org/mccann/2009/08/08/whatchamacallit/)
 * etc.

If the answer to any of those is no then it should not be a part of
the core user experience I think.

Here are three examples.  (to be more concrete but please don't get
sidetracked by them)

Example 1: Empathy

The overall system design calls for including chat and contacts
functionality.  It meets most or all of the requirements.  It is a
great app made by folks committed to the success of GNOME.  However,
with such a rubric we'd want to rename the tool to "Chat" or similar
and ensure that it continues to be more integrated with the core.  The
good news is that it sounds like this is ongoing or under
consideration already.

Example 2: Caribou

The core system design calls for an on screen keyboard:
http://live.gnome.org/GnomeShell/Design/Whiteboards/ScreenKeyboard .
However, we haven't yet determined the details of the design or how it
would integrate or cooperate with the Shell or a11y or i18n input
methods etc. (help appreciated there btw)  So, unfortunately until we
do that it shouldn't be in the core.  Not due to any failings of the
tool authors at all.  But the default should be out, not in.

And there are many other examples of quality applications that (it
seems) would very much prefer to remain separate and have a separate
brand identity: gedit, inkscape, shotwell, etc.  So, they should not
be part of the core either.

That said, we aren't doing anyone a service by just turning our backs
on great software.  On the contrary, we need to foster and encourage
it (this is number 3 above).  Communities and ideas like this need a
place to make them seem real.  Even if that place isn't the only one
and even if it is only symbolic.  I propose that we create a GNOME
Marketplace for applications, games, and utilities that aren't part of
the GNOME core.  If we do it well then this will actually provide a
lot more value to the application authors than we ever could by simply
accepting it into a list of desktop modules.  Think of it as a living
module set.

Once we decouple application development from the core OS development
we'll quickly find that our application developer experience is less
than ideal (number 2 above).  So, ideally, it would be better if we
work on them in concert.

So, what does this mean with respect to your proposal?  Maybe:
 * Rename Desktop to Desktop Core (or similar)
 * Drop Mobile for now until we start to design a Mobile user experience
 * Drop Platform for now until we start to design an Application Platform
 * Create a GNOME Marketplace website and service with client support
built into the Desktop Core

Things not directl

Re: Module Proposal: GNOME Shell

[William Jon McCann]

Hi Ross,

On Sat, Apr 3, 2010 at 3:13 AM, Ross Burton  wrote:
> On Fri, 2010-04-02 at 23:57 +0100, Alan Cox wrote:
>> > maintained for people without the correct hardware support. As of now,
>> > all intel, amd/ati and nvidia cards sold in the last five years should
>>
>>
>> I don't believe that is correct for any of the listed vendors even on
>> Linux. On BSD the situation is even more patchy.
>>
>> Is Gnome dropping support for these operating systems ?
>
> "The gnome-panel will still be available in GNOME 3.0 and will still be
> maintained for people without the correct hardware support"

I think it is better to say: GNOME 2 will still be available after
GNOME 3 is released.  Perhaps in long term stable maintenance mode.

http://live.gnome.org/GnomeShell/FAQ#What_led_to_the_decision_to_make_3D_acceleration_a_requirement_for_GNOME_Shell.3F


Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Module Proposal: GNOME Shell

[William Jon McCann]

Hi,

On Thu, Apr 1, 2010 at 1:24 PM, Diego Escalante Urrelo  wrote:
> El jue, 01-04-2010 a las 13:31 +0100, Bastien Nocera escribió:
>>
>> The idea would be to have the "appearance" cut down to only
>> "personalisation" (background and screensaver), and leave the icon and
>> control themes handling to the gnome plumbing app.
>>
>
> Isn't that a bit too much? I'd fear that GNOME plumbing becomes "KDE
> control center" because it will host too many stuff.

This is all pretty speculative since we haven't actually done any
mockups of this that I know of.  So let's not get all worked up about
it :)

Anyway, a bit off-topic for the thread I think.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Window titles

[William Jon McCann]

Hi Calum,

On Tue, Nov 17, 2009 at 1:27 PM, Calum Benson  wrote:
>
> On 14 Nov 2009, at 09:58, Andrew Cowie wrote:
>
>> So anyone care to put a stake in the ground about what is correct?
>
> Well, the HIG advice hasn't really changed over the years:
> 
>
> However, just when it's all looking fairly straightforward, it wimps out at 
> the end by saying "If you plan to include your application's name in the 
> title of a primary window...", without saying when/why that might be an 
> acceptable practice.  This, IIRC, was one of the concessions we made to some 
> maintainers who weren't happy that their pet project name might not be 
> appearing on the screen any more, whether or not it was of any use to anyone.


In my view it seems like the only part of those recommendations that
should change for the shell is to remove this:
"While document names are most pertinent to users, we understand that
application developers may want to increase recognition of their
application. If you plan to include your application's name in the
title of a primary window, use the following format: Document Name -
Application Name. This will ensure that the document name appears in
limited space situations such as the system window list."

We will have an application menu at the top of the screen that will
serve the purpose of identifying the application.

> Like most things in the HIG, all of this will most likely be up for review 
> once we start to properly shape the user experience for 3.0.

Well, really now is the time.  We are in the process of shaping the
user experience for 3.0.  I encourage designers from Sun, Novell,
Canonical etc to get involved now - while there is still time.  I've
literally been begging for involvement from these companies for a year
now.  And unfortunately, we haven't gotten much if any help yet.  I
don't know why.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: A different point of vision (was: Appearance capplet)

[William Jon McCann]

One small clarification...

On Wed, Nov 11, 2009 at 5:02 PM, William Jon McCann
 wrote:
> Hi Luca,
>
> I'm not sure your evidence supports your conclusion.
>
> I agree that changing the font size (basically the scale of the
> screen) is an important thing.  I've written up some thoughts on this
> here:
> http://live.gnome.org/Design/DesktopFontPreferences
>
> Also, in some cases using a text-only toolbar items makes sense too.
> See gmail for example.  However, this is something that really doesn't
> fall into the same category of user preferences that desktop
> background and font size do.  We should try to figure out the
> appropriate design for these sort of things.
>
> The appearance panel is pretty conflicted today.  We should probably
> have a panel that is specifically about personalization and not
> customization.  Maybe a rule of thumb is - things that are likely to
> change based on external conditions, whims, fancies.  Of course,
> personal computer accessibility is a closely related concept.  So, the
> needs-to-be-written Universal Access panel would likely have some
> overlap here.

Another rule of thumb... these should be things that are not only
likely to change but that we want to *encourage* people to change.

> In my opinion, things like background art, screensavers, and font size
> are in scope.  Things like the choice of icons in menus or editable
> menu shortcut keys are clearly not.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: A different point of vision (was: Appearance capplet)

[William Jon McCann]

Hi Luca,

I'm not sure your evidence supports your conclusion.

I agree that changing the font size (basically the scale of the
screen) is an important thing.  I've written up some thoughts on this
here:
http://live.gnome.org/Design/DesktopFontPreferences

Also, in some cases using a text-only toolbar items makes sense too.
See gmail for example.  However, this is something that really doesn't
fall into the same category of user preferences that desktop
background and font size do.  We should try to figure out the
appropriate design for these sort of things.

The appearance panel is pretty conflicted today.  We should probably
have a panel that is specifically about personalization and not
customization.  Maybe a rule of thumb is - things that are likely to
change based on external conditions, whims, fancies.  Of course,
personal computer accessibility is a closely related concept.  So, the
needs-to-be-written Universal Access panel would likely have some
overlap here.

In my opinion, things like background art, screensavers, and font size
are in scope.  Things like the choice of icons in menus or editable
menu shortcut keys are clearly not.

Jon

On Wed, Nov 11, 2009 at 4:25 PM, Luca Ferretti  wrote:
> Hi everyone,
>
> sorry to start a new thread, but I strongly desire this email will not
> missed in previous *cough*flame*cough* discussion.
>
> I've recently started helping a man to use and maintain his computer. He
> was a professor of engineering at university, but he had an ictus some
> years ago and now he's able to move only his right arm and head. He
> recently started to use Linux, and we switched from KDE to GNOME 4 weeks
> ago. We could say he's a "virgin of GNOME"[1]. No bias, no strong
> interest in GNOME vs KDE vs MacOS vs Win. Just "I want to use this
> fuc***ng computer".
>
> Some days ago he asked me how to enlarge the text on screen, so I showed
> him the Fonts tab in Appearance preference tool[2]. Then we explored the
> other options available in this tool.
>
> In the (infamous and so hated) Interface tab he found really useful the
> ability to change the setting for toolbar items, and he chosen to stay
> with "text only", saying he prefers to read a label then try to figure
> what an icon means.
>
> What's the point of this? Well, firstly report that some people actually
> use some "weird" setting, secondly that even if unused, some preferences
> are better to stay in a "visible" place then in a not-yet-available
> tweak UI or gconf-editor[3]. Someone could need them or, at least, will
> appreciate their availability and discoverability.
>
> When that man used the Interface tab to adjust the setting for himself I
> was really proud that "my" GNOME Desktop was able to provide something
> that was useful. I really hope GNOME we'll be able to keep this level of
> user-friendship.
>
> Cheers, Luca.
>
> [1] insert a sexist joke here :P
> [2] OT: this should also tell us that font settings are not immediately
> discoverable :|
> [3] another OT: honestly I've a bad feeling with any sort of tweak tool
> in GNOME. We already have gconf-editor for "real" tweaks, adding a GUI
> tool to pack options makes me feel we was unable to choose the proper
> ones and put them in the proper place :(
>
> ___
> desktop-devel-list mailing list
> desktop-devel-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Signalling when the desktop is loaded

[William Jon McCann]

Hey,

On Wed, Aug 12, 2009 at 9:57 AM, Emmanuele Bassi wrote:
> On Wed, 2009-08-12 at 14:54 +0100, Neil J Patel wrote:
>
>> I would love to have Nautilus running in UNR as it handles
>> auto-mounting much better than the launcher can, however it does not
>> have a 'daemon-mode' so it doesn't run until the user needs to browse
>> a file[2].
>>
>
>> [1] I believe I filed a bug for this, but can't find the number right now.
>> [2] http://bugzilla.gnome.org/show_bug.cgi?id=541262
>> [*] I've got half-patches for both these bugs, just need time to complete 
>> them.
>
> Neil, have you seen bug 579574? I left a comment on bug 541262 but I
> wanted to mention it here as well: Moblin uses Nautilus to handle
> automounting but we don't use it to draw the desktop as well, since...
> well, we don't have a "desktop" but a neutral background.

I think I would prefer to see
http://bugzilla.gnome.org/show_bug.cgi?id=585545 fixed.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Application names

[William Jon McCann]

Hi,

On Mon, Aug 10, 2009 at 9:59 AM, Vincent Untz wrote:
> Le lundi 10 août 2009, à 09:03 -0400, William Jon McCann a écrit :
>> On Mon, Aug 10, 2009 at 5:12 AM, Vincent Untz wrote:
>
> [need to think about your answer to the first question]
>
>> >  + translators have stated that it's wrong to do "Name - GenericName"
>> >   programmatically. So, hrm, why would we not listen to them?
>>
>> That hasn't been established.  In the xdg-list thread one of the last
>> comments from Christian Rose said this:
>> "Webbläsare - Epiphany" or "Webbläsare (Epiphany)" is not wrong per
>> se, it's just bad language style."
>
> See http://mail.gnome.org/archives/gnome-i18n/2009-August/msg00072.html
> from which I will quote only one expression (please do not trust me and
> read the full mail :-)): "orthographically incorrect".

Actually that mail seems to support my point.  It makes the same
critical error that I was pointing out.  GenericName is not a fragment
here.  That mail describes GenericName as "fragment [that] is
conceived as a description, not as a (generic) name with capital
letter(s)..."  That is incorrect.  A GenericName is always a name and
should not use sentence capitalization.  Again, Name and GenericName
are not fragments of a fuller-name.  They are substitutes for one
another.  They cannot be joined together to make a fuller name.  What
we are trying to do here is to simply display both at the same time -
not join them.

Part of the confusion here is that GenericName has been abused in the
past to afford description.  Another problem is that people are
assuming the dash or (as I prefer, and the patch actually uses) the
hyphenation point is being used grammatically here.  It is not.
Semantically it is the equivalent of an "or" or "also".  It would
probably be more correct to use "/" here but we are making an artistic
compromise by suggesting '‧'.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Application names

[William Jon McCann]

Hi,

On Mon, Aug 10, 2009 at 5:12 AM, Vincent Untz wrote:
> Le samedi 08 août 2009, à 17:51 -0400, William Jon McCann a écrit :
>> On Sat, Aug 8, 2009 at 5:34 PM, Frederic Peters wrote:
>> > However for compatibility reasons, I have been interested by Colin
>> > Walters comments:
>> >
>> >  | If we change the Name field now, concretely it will be a huge pain for
>> >  | application writers because if their app is used on older GNOME
>> >  | releases it will fail.
>>
>> Last I talked to Colin he was satisfied after he updated my patch in
>> bugzilla for the panel.  I think he was overstating the problem a bit
>> though.  The point is we have to fix the names for the shell, for KDE
>> compatibility, and to honor the spec.  Any apps that honored the spec
>> will be fine, and any apps that followed our unwise advice to make
>> Name use Name+GenericName are fixed by Colin's latest patch.
>
> Two questions:
>
>  + unless I missed something, Colin's patch is for gnome-panel only.
>   What about "Open With", and all the other places where we display the
>   applications?

An excellent point.  And we should probably consider each of these
individually.  It is a little strange that we are designing FullName
proposal around the implementation details of gnome-panel.  There are
at least two cases for open with.  We have menu entries in context
menus on files and we have the full "Open With" dialog.  My thinking
currently is that "open with" menu should simply use the Name.  Since:
  * The default handler is already set and doesn't need to be discovered
  * If you are looking for a specific app you know the name
  * We don't show the comment either (which is really essential for
discovery) since we assume you recognize the name already
  * If you don't find it there you can go into the dialog for for discovery

The "Open With" dialog is another story and has a number of design
problems.  Won't go into those here.

Technically, if we follow the logic of FullName (which is really just
the gnome-panel name) we should also add a OpenWithLabel to the
desktop file or have translatable "actions" since the following is
also wrong:
g_strdup_printf (_("Open with %s"), g_app_info_get_name (application));

Right?  Unless we don't consider names to be translated or require
articles or the resulting string to be a proper sentence.

>  + translators have stated that it's wrong to do "Name - GenericName"
>   programmatically. So, hrm, why would we not listen to them?

That hasn't been established.  In the xdg-list thread one of the last
comments from Christian Rose said this:
"Webbläsare - Epiphany" or "Webbläsare (Epiphany)" is not wrong per
se, it's just bad language style."

And I'm not convinced that it is bad style either.  At least, it isn't
in English.  Here's my reasoning.  We aren't trying to combine two
strings into a single grammatical unit.  That would be wrong.  What we
are trying to do is use a one line equivalent of "%s\n%s" by using
punctuation.   Where punctuation and the order would be decided by the
translator.  The reason for this is that we aren't trying to make a
name, we are trying to display *both names* at the same time.  It is
only for simultaneous display.  GenericName is not a category or a
description - it is a substitute for the Name.  However, in some cases
it had been used as a descriptive crutch in order to work around
really bad application names.

The specific implementation choices of gnome-panel do require us to
display more than just the Name for many apps.  This is primarily
because menus are not a good interface for discovery.  We are solving
this with GNOME Shell.  And we need to fix the Name field for 2.28 in
order to do so.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Application names

[William Jon McCann]

Hi,

On Sat, Aug 8, 2009 at 5:34 PM, Frederic Peters wrote:
> William Jon McCann wrote:
>
>> My proposal for 2.28 is:
>
> UI Freeze for 2.28 is set to Monday; sure we could grant an exception
> and rush things, but I'd prefer to wait for the beginning of 2.29,
> especially as we may want a new translatable key in the desktop files
> and that would give enough time to translators.

We're are not in string freeze yet.  We are free to change any strings
we wish.  Especially since this is mostly removing extra text from
Names - and could even be done by a script in some cases.  So I'm not
sure this alone is a good reason to delay.  We will also have lots of
other things to do in the 2.29 cycle - trust me.  And really 2.28 is
supposed to be a baseline for GNOME Shell testing and we absolutely
need these fixes for that.

> Quoting Vincent Untz and Christian Rose:
>
>  | >  And do you think the burden of adding a new translatable key to all
>  | >  desktop files would be okay for translator teams?
>  | Yes, if the changes/patches are done in time in the beginning of a new
>  | release cycle, I think it will be acceptable by most translators.
>
>  -- http://mail.gnome.org/archives/gnome-i18n/2009-August/msg00063.html
>
> David Faure (of KDE fame) was away until August 4th, and didn't speak
> since he's been back, but wrote before going on vacations:
>
>  | But if the one who adds FullName to every desktop file also fixes up the
>  | Name and GenericName keys of the file in order to stop the duplication
>  | nonsense there and actually follow the spec then I guess I withdraw my
>  | objection against FullName.
>
>  -- http://lists.freedesktop.org/archives/xdg/2009-July/010816.html
>
> Let's engage him back into the discussion, which has now been
> clarified with regards to two important points:
>
>  * it's not a matter of avoiding fixing GNOME desktop files
>  * a new key is required for pleasant translations

Feel free to do that.  However, it should not hold up fixing the panel
and desktop files.  As I pointed out in the blog, we have to do this
even if we add FullName to the spec.  FullName would be yet another
way applications could be shown - and why I don't think it is a good
idea anymore.

> And I hope we can then reach an agreement.  (yes I read your blog
> post, and you may not believe an agreement is possible, I think
> it is too early to give up).
>
> However for compatibility reasons, I have been interested by Colin
> Walters comments:
>
>  | If we change the Name field now, concretely it will be a huge pain for
>  | application writers because if their app is used on older GNOME
>  | releases it will fail.

Last I talked to Colin he was satisfied after he updated my patch in
bugzilla for the panel.  I think he was overstating the problem a bit
though.  The point is we have to fix the names for the shell, for KDE
compatibility, and to honor the spec.  Any apps that honored the spec
will be fine, and any apps that followed our unwise advice to make
Name use Name+GenericName are fixed by Colin's latest patch.

...
> Going back to your proposed guidelines:
>
>  | When Name is the same as GenericName, the GenericName should be removed
>
> Definitely agree.
>
>  | The desktop entry Name value, application menu (for GNOME shell),
>  | window titlebar (for GNOME 2.x), documentation, and about dialog
>  | should all use the same name
>
> Mmmm. See below.
>
>  | The desktop entry Name value should be the brand name unless the
>  | application is a simple (single purpose), core GNOME built-in and does
>  | not have an established external brand identity (web site, online help,
>  | etc)
>  |
>  | Brand names should be considered carefully but can’t be relied on to
>  | indicate functionality in many languages
>
> As noted by mpt during GCDS, we have a lot of sucky brandnames; as the
> Name key will be exposed in many places that are not out of GNOME realm,
> I believe it is nice to keep it somehow understandable (Agave Color
> Picker instead of Agave).

One of the reasons why we are seeing crappy names is that we are
masking the problem.  We should provide aliases for bad names.
Application authors pick bad names they get what they get.  If we
picked bad names - we should change them.

>
> Anyway my summary would be to have the discussion now, but the changes
> in 2.29, with an enhancement to the spec if possible.

We still have time before string freeze, we'll have our hands full
with other issues during 2.29, and we want 2.28 to be a viable testing
platform for the Shell.  Let's do it now.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Application names

[William Jon McCann]

Hey,

So, in preparation for GNOME Shell and 3.0 a number of us have been
trying to address various inconsistencies in how we name applications.

I've just posted a blog about this:
http://blogs.gnome.org/mccann/2009/08/08/whatchamacallit/

My proposal for 2.28 is:

   1. We need to patch the panel to support showing both Name and
Generic Name to workaround the fact that menus are very poor ways to
discover new things.
   - http://bugzilla.gnome.org/show_bug.cgi?id=501087

   2. We need to fix a lot of our desktop files to use Name and
GenericName correctly:  GNOME Goal,  tracker bug, Fedora wiki page.
   - http://live.gnome.org/GnomeGoals/CorrectGenericName
   - http://bugzilla.gnome.org/show_bug.cgi?id=588975
   - https://fedoraproject.org/wiki/Desktop/Whiteboards/ApplicationNames

   3. Consider renaming applications that have really poor names.

   4. Ensure that application names perform well in GNOME Shell

What do you think? (please read the blog post before answering)

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME and non-linux platforms (release team please stand up)

[William Jon McCann]

Hey Jason,

On Fri, Jul 24, 2009 at 1:29 PM, Jason D. Clinton wrote:
> On Fri, Jul 24, 2009 at 11:16 AM, Calum Benson  wrote:
>>
>> So if it turns out that the GNOME community like the general direction
>> we've suggested for the control center, then sure, I'd certainly like to see
>> us widen out the discussion to visual panels as well.
>
> Has there been any movement with regard to the mouse-over pop-up menu
> criticism that I pointed out--that it breaks the metaphor and there's no
> precedent for it? There wasn't any response on the blog post[1] from the
> parties involved with creating the mock-up. Another criticism--not mine--was
> the 90 degree rotated text for category naming. I didn't see a response to
> that either. Communication needs to be two-way.
>
> [1] http://blogs.gnome.org/calum/2009/07/14/control-center-refresh/

This is pretty far off topic.  I think discussing a control center
design is really important.  But it should probably happen here:
http://mail.gnome.org/archives/gnomecc-list/2009-July/msg7.html

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 3.0 - shell and applets

[William Jon McCann]

Hi Luca,

On Fri, May 15, 2009 at 1:29 PM, Luca Ferretti  wrote:
> 2009/5/15 William Jon McCann :
>> On Thu, May 14, 2009 at 7:58 PM, Luis Menina  wrote:
>>>
>>> Please, don't try to abuse the system tray for things that should be
>>> applets. System tray has been made to notify events. One should be able to
>>> use GNOME without requiring a notification applet. A recent example of
>>> things gone wrong is the volume controler : it should be an applet an not a
>>> system tray item, as it presents a permanent state and not an event nor a
>>> response to an event.
>>
>> Seems to me you have this almost entirely backwards - you should be
>> able to use GNOME without applets (though we need GNOME Shell to make
>> this a reality).  The volume status icon was wrong as an applet.
>> There are a number of reasons for this that I won't go into here.  The
>> volume status icon shows you the current status of the system volume.
>> This is very similar to the power and network status icons.
>
> William, please note that *currently* we have a Notification Area and
> GNOME HIG speaks about notification icons, so IMHO Luis is right: by
> now the volume icon (while it calls itself applet) in Notification
> Area is, strictly speking, wrong because, as you say, it represents a
> *status*, not a *notification*.

Firstly, the HIG does not call it a Notification Area it calls it a
Status Notification Area (as does Windows).  Secondly, the HIG does
not say that system status indicators are wrong for this area.
Lastly, the HIG is a set of guidelines and it is entirely possible
that it is wrong or that we want to change the way we're using the
area.

Matthew (mpt) and I discussed this on IRC the other day and I think we
agree that:
* this area is not an effective way to display notifications
* we may want to rename it the System Status Area
* we need to improve our notification story (Ubuntu is already
experimenting with this)
* we need to change and improve the HIG
* we should make these icons behave more like menus
* we may need to change or improve GtkStatusIcon

I'd like to go a few steps farther and try to use a rule of thumb that
status icons should serve primarily as visible indicators and not as
primary interaction points - only optional ones.  This is especially
important on small form factor devices where we may not want to make
the panel, that holds the status area, large enough to enable
interaction.  Look at basically all embedded devices (especially
phones like iPhone or Android) for examples of this.  For example, the
volume indicator displays the volume status but the primary
interaction would be with hardware controls or a control center
action.  Trying to do this makes it very obvious how broken our
control center story is...

Some people are concerned that if we have an interface that looks,
feels, and is named similarly to the Windows Status Notification Area
that it will be difficult to change application developers
expectations and behaviors.  Hard to say.  Perhaps if there was some
architecture in addition to the norms imposed by the HIG and a
developer community that agrees on the correct usage we could regulate
the proper usage.  I'm not sure that even if we came up with an
entirely different API that, over time, we wouldn't face the same
problems.  Look at menu extras on OS X as an example.  Application
developers have already started adding lots of non-default somewhat
oddball stuff there too.  An example of this is Norton Antivirus for
Mac (yes it exists - I think partly for companies that have an
unwavering policy that all computers must have anti-virus software)...

Architecturally, I think the system status area is actually pretty
solid.  Owen seemed pretty happy with it too when I asked his opinion
the other day.  So, I think we're better off just fixing up the few
issues with the current system rather than scrapping it and starting
over.  Particularly since this is one of the better examples of a
successful XDG spec.

In addition to requiring that all status icons to behave like menus, I
think we need to fix at least:
http://bugzilla.gnome.org/show_bug.cgi?id=558628
http://bugzilla.gnome.org/show_bug.cgi?id=565697
http://bugzilla.gnome.org/show_bug.cgi?id=583115
http://bugzilla.gnome.org/show_bug.cgi?id=583272
http://bugzilla.gnome.org/show_bug.cgi?id=583273

> So the interesting question now is: what for GNOME 3.0? do we want to
> keep the "Notification Area" (then we need another solution to show
> current status of some stuff, like battery, network, audio input and
> output volume...) or we want to use this area for as "Status Ares"
> (then we need another solution to show notifications like new email,
> new IM message, new updates[1]...)?
> A different approach for notifications was pro

Re: GNOME 3.0 - shell and applets

[William Jon McCann]

Hey Luis,

On Thu, May 14, 2009 at 7:58 PM, Luis Menina  wrote:
> Toms a écrit :
>
>> 1) System tray - applets that could end up in system tray, most
>> probably contextually - like, when they are needed or make sense. Or,
>> sometimes per user request in preferences (something like a "show in
>> system tray" checkbox for those marginal "nobody knows" cases). As
>> pointed out[2], KDE has some specs worth considering on the case.
>
> Please, don't try to abuse the system tray for things that should be
> applets. System tray has been made to notify events. One should be able to
> use GNOME without requiring a notification applet. A recent example of
> things gone wrong is the volume controler : it should be an applet an not a
> system tray item, as it presents a permanent state and not an event nor a
> response to an event.

Seems to me you have this almost entirely backwards - you should be
able to use GNOME without applets (though we need GNOME Shell to make
this a reality).  The volume status icon was wrong as an applet.
There are a number of reasons for this that I won't go into here.  The
volume status icon shows you the current status of the system volume.
This is very similar to the power and network status icons.

You seem to be speaking very positively about what does and does not
belong here.  However, it seems to me that while you may be right
about it being useful for notifications you are not recognizing that
it may also be used for status (particularly types of status that
change - where recognizing the change is a form of ... notification).
MSDN has a pretty good reference for how the area is used in Windows:
http://msdn.microsoft.com/en-us/library/aa511448.aspx#rightui

If you follow those rules the volume icon does belong there - and just
to pick an example - the brasero icon does not.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Applets? [was Re: Planning for GNOME 3.0]

[William Jon McCann]

Hi Calum,

On Thu, Apr 30, 2009 at 6:53 PM, Calum Benson  wrote:
>
> On 21 Apr 2009, at 04:34, Travis Watkins wrote:
>
>> This one at least has been solved in Windows 7 by merging the
>> QuickLaunch area with running applications. A dock would also solve
>> this problem nicely. You'll notice OS X doesn't have a lot of
>> "applets" on the menu bar. The only one I've seen a lot of people have
>> is smcFanControl.
>
> You'd be surprised.  I currently have 15, 11 of which are standard OS X
> "applets" (but not all of which are turned on by default, admittedly).
>
> On the plus side, the good thing about OS X menu extras (as they're properly
> called) is that they're all generally of a uniform size and appearance (they
> fit into a square, and they're monochrome)-- the 15 I have still take up
> less than half the width of my menu bar.

Out of curiousity, do they all act like menus?  Also guessing that you
don't have the google notifier since that one isn't monochrome (I wish
it was)...

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Applets? [was Re: Planning for GNOME 3.0]

[William Jon McCann]

Hey Owen,

> The main open question for gnome-shell is not how to implement them.
> It's the user interface question. And when we look at the user interface
> question I think the label "applet" is a bit deceptive. We have all sort
> of different things that are applets, and their only commonality is that
> they go on the panel. The better approach is to start from the tasks and
> functionality

Not really responding to this directly since, as usual, your analysis
is very good.

I think one of the most important cases against applets (as they are
currently defined in GNOME) is that they are extremely detrimental to
the Identity of the product or platform.  Today, our entire desktop
identity is defined by a configurable number of horizontal or vertical
bars filled with any number (even duplicates) of random Things that
may launch stuff, open menus, open dialogs, operate on windows, switch
workspaces, and more!  Boxes-o-crap as I lovingly (in the eulogistic
sense) refer to them.  Each time I see "Remove from panel" when I
right click on the notification area or the menu system I weep and my
mascara runs and god is it awful.

Let's say that we are trying to define either a product or a product
platform.  I don't think it is possible to do this without some
"brand" coherence.  And it is arguably impossible to do this
effectively with such an ad-hoc/individually-customized design
identity.

Even those of us in the developer community would have a difficult
time identifying a GNOME desktop in 3-5 steps.  Let's try this with
Windows: "Start" or  menu, (usually) bar at the
bottom.  This works from Windows Server products all the way to
embedded Windows on smartphones.
With OS X: Apple logo menu, menu bar at the top, (usually) a dock.
Even though the iPhone doesn't have the same software identification
experience it retains the platform design branding on the hardware and
uses familiar themes in the software visual design.  There is usually
no doubt that it is an Apple platform.
With Android: who knows...

So, one of the many very exciting things about GNOME Shell is that for
the first time we may have ability to really shape the user experience
and form an identity for the GNOME platform.

That said, I agree that it is very important to have a number of
extension points.

  * At the platform level to shape a different user experience
(usually for devices with different form-factors and goals).  I would
expect this to probably be only at build/integration time.
  * Something like a new status area where extensions behave in a very
consistent and well-defined manner - the current notification area
"applets" are neither
  * A "place" where the rules are more relaxed and fun things can
happen - maybe a sidebar - maybe Vegas...

As you mentioned the current applet design conflates these things.  I
think we can do a lot better.

Better default experience, more consistency, more fun!  Unity!  We're
doing something together here and it is about time we started looking
like it.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Running GNOME in jhbuild session eat all CPU

[William Jon McCann]

Hi,

On Sat, Jan 24, 2009 at 10:58 AM, Luca Ferretti  wrote:
> Il giorno sab, 24/01/2009 alle 14.22 +0100, Wouter Bolsterlee ha
> scritto:
>> 2009-01-24 klockan 14:06 skrev Luca Ferretti:
>> > Now, someone has the same issue? And how can I try to investigate it?
>> > The only evidence that something is going wrong is the X process CPU
>> > usage :-|
>>
>> You could try looking (with ps) which Gnome-related processes are running.
>> Then you can try to kill those processes one after another to see if there
>> is a single process causing the excessive CPU usage in the X server.
>
> Thanks, I tried to kill some processes, one by one, with no results. But
> fortunately I started a compilation while `top` was running. The CPU
> usage decreased 40~50%.
>
> That's strange: a CPU consuming task that decrease the CPU usage.
>
> So, a with a little shining
>
>> Good luck, and let us know how it goes :)
>
> It seems the high CPU usage come from, or at least is related with new
> presence/idle stuff in gnome-session.
>
> Reverting it to revision 5188 fix the issue.
>
> Filed as bug 568989
>
> Thanks everyone :)

As Olav mentioned, this is due to a bug in xorg.

http://cgit.freedesktop.org/xorg/xserver/commit/?id=1f4fb0225b278d1cf4145aebeb0bdd23dc8f62d5

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: GNOME 2.26 module inclusion discussion heats up

[William Jon McCann]

2009/1/11 Josselin Mouette :
> Le dimanche 11 janvier 2009 à 12:21 +0100, Luca Ferretti a écrit :
>> Please also note that on current trunk the Audio capplet from
>> gnome-control-center and the Volume Control applet from gnome-applets
>> was replaced in favour of new gnome-volume-control and
>> gnome-volume-control-applet[1] in gnome-media[2].
>>
>> This new volume control stuff requires pulseaudio.
>
> So, there is no more GStreamer mixer? It is not possible to use any
> other backend than PulseAudio? It looks like an important regression to
> me.

It is interesting to me how, for the last few years, the GNOME
community has taken to using the term regression where the term
progression should be used.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-screensaver branched for 2.24

[William Jon McCann]

gnome-screensaver branched for 2.24.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: new module proposal: notification-daemon+libnotify

[William Jon McCann]

Hey Christian,

2008/11/10 Christian Hammond <[EMAIL PROTECTED]>:
> Very critical notifications can be set to have a non-expiring timeout. This
> would ensure that they stay visible until the user acknowledges them.
>
> Some people have also talked about writing a notification backlog for
> important notifications, where an icon in the tray blinks when there's
> certain notifications you missed. The problem with this is that you really
> need to have a fine-grained concept of what's important and should trigger
> the blinking. You could leave it at critical notifications and you might be
> fine, but these may as well just be set to not disappear by the calling
> program if it's really important (your battery is going to explode).

Yes, I'd like to see this too.  There are a number of reasons why it
would be useful to have an obvious way to view a record of
notifications.

 * Queue all messages while away
 * Queue messages (except critical) while busy
 * Queue messages (except critical) while in fullscreen
 * Hide all but important (but user configurable) messages by default
 * Access messages later that were dismissed by mistake (ie. be forgiving)
 * Provide a way to see missed messages or messages that timed out
before I could read them
 * Provide an API to screensaver/display-manager to get number of
unread messages
 * Minimize distraction for less than important messages
 * Remind me of when a message arrived (eg. oh man has it been an hour
already since that appointment reminder)
 * Provide a way to discriminate what is important enough to disrupt
me (blinking is pretty severe, colors/boldness may work)
 * Allow the user to configure what is important to them or what they
never want to see (ie. put the user in control)
 * Allow the user to use the bubble to quickly decide whether the item
needs immediate attention but have the freedom to access it later
(after the bubble times out). [1]

Jon

[1] A good use case here is an instant message conversation.  I
probably want to see a bubble for the first message from a friend.
But I don't necessarily want to respond immediately.  And if I choose
not to respond immediately I still want to have an easy access to that
message.  Also, I probably don't want to see another bubble message
from that friend until I respond once.  However, it may be useful to
increment a counter on the status icon that represents the message
history (aka. the notification center).  Facebook and Adium have good
examples of this type of status icon.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-media branched for 2.24

[William Jon McCann]

gnome-media branched for 2.24.

New volume control going into trunk.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Prototyping the next generation panel?

[William Jon McCann]

Hey Calum,

On Fri, Oct 31, 2008 at 11:23 AM, Calum Benson <[EMAIL PROTECTED]> wrote:
>
> On 28 Oct 2008, at 18:36, Karl Lattimer wrote:
>>
>> Gather up data from humble users, performing a specific set of tasks
>> which are challenging enough and enough like real life to build up
>> decent data sets so we can tell what's wrong with it before we write
>> _real_ code.
>
>
> On a related note, saw this article about Windows 7 today, which includes
> some info on their new taskbar:
> 
>
> "Through the Customer Experience Improvement Program (CEIP), an optional,
> off-by-default feature of many Microsoft programs, the company has learned a
> great deal about the things that users do. For example, from CEIP data
> Microsoft knows that 70% of users have between 5 and 15 windows open at any
> one time, and that most of the time they only actively use one or two of
> those windows."
>
> Although you certainly wouldn't use data like that as your only source of
> design input, it's the sort of concrete information about our users that we
> still seem to be rather lacking.

Very much agree with you.  However, one of the things that strongly
influenced the discussions at the GNOME UX Hackfest was the data
released on the Windows 7 Shell blog:
http://blogs.msdn.com/e7/archive/tags/Shell/default.aspx

While it certainly isn't a substitute for first hand data, I think it
is extremely interesting.  What do you make of it?

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

GDM branched for 2.24

[William Jon McCann]

2.24 is stable.   Development continues on trunk.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New svn module: gnome-sound-theme

[William Jon McCann]

On Tue, Aug 12, 2008 at 3:48 PM, Emmanuele Bassi <[EMAIL PROTECTED]> wrote:
> On Tue, 2008-08-12 at 14:36 -0500, Brian Cameron wrote:
...
>> If people think an uncompressed lossless format has any value, then it
>> we should consider a better format than WAV, which has a 4 GB filesize
>> limitation, while Sony Media WAV 64 (W64) allows for longer recording
>> times.
>
> erm... for the sound theme spec? you really think you'll hit the 4GB
> file size limit for a sound effect to be used when logging in/out (which
> are the longest running effects on my laptop)?

http://www.youtube.com/watch?v=Mt1bgsvsWms
Well, still not quite 4GB...

(Thanks to Mike Langlie for that link)

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-session proposal

[William Jon McCann]

Hey Lennart,

On Wed, Jun 25, 2008 at 7:45 PM, Lennart Poettering <[EMAIL PROTECTED]> wrote:
> On Wed, 25.06.08 19:07, William Jon McCann ([EMAIL PROTECTED]) wrote:
>
>> We can still support applications that only know if they should
>> inhibit "just in time" by emitting a signal when a logout is
>> requested.  The applications can then take an inhibit in response to
>> that signal.
>
> This part sounds racy. Is it?

It is.  Logout is a racy proposition.  We should strongly recommend
that people use the Inhibit API.

> Apropos, since we are talking about session management here: have you
> guys ever thought of reuseíng upstart for managing session processes? The
> problem that an init system and a session manager have is the same:
> doing lifecycle management of processes and all kinds of fancy
> monitoring of them.

Right, the launchd approach.  While launchd was designed for this I'm
not sure upstart was.  Not sure though.  In any case, we'll still need
to come up with a reasonable API for applications to use.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-session proposal

[William Jon McCann]

Hi,

Dan Winship and Lucas Rocha have done a nice job revamping the
gnome-session codebase.  It was a meritorious task.  You can read
about the design here:
http://live.gnome.org/SessionManagement/NewGnomeSession

The new code is much cleaner.  Parts of the new design are very good.
In particular, using autostart as the database of
registered/automatically started applications, allowing use of a gconf
key to turn programs on and off, and starting up the desktop in phases
all make a lot of sense.

However, the core mechanism still relies on and is built around XSMP.
In my opinion, that is a mistake.  XSMP is broken is a variety of
ways.  Havoc argued rather convincingly that the state saving parts of
XSMP are broken (as well as the underlying protocol):
http://mail.gnome.org/archives/desktop-devel-list/2006-September/msg00088.html

I agree with that.  Logout handling is broken too.  The XSMP protocol
not only allows applications to be notified on logout (aka shutdown)
but also allows any registered application to block logout altogether.
 Windows XP used a similar approach.  However, in Windows Vista they
rejected that model and proposed a much better one:
http://msdn.microsoft.com/en-us/library/ms700677(VS.85).aspx

Vista's use of ShutdownBlockReasonCreate etc is analogous to the
various Inhibit APIs that we already use in GnomePowerManager and
GnomeScreensaver.  When a logout/reboot/shutdown are requested, Vista
is able to show a dialog warning the user if any applications are
running that would be interrupted by the action.  It informs the user
but still allows her to remain in control and continue the requested
action.  I think this is the right approach.  XSMP does not allow for
this.

Blocking shutdown is not only the wrong solution but it is also an
incomplete one.  One of the primary use cases here is burning a CD.
In the near future, switching users will also cause a CD burn to fail.
 XSMP does nothing to help with this.  On the other hand, using an
inhibit type API could.  The burning application could provide
information that the inhibit request should inform user switching as
well as logging out.  Nautilus transferring files to a USB disk could
do something similar.  But perhaps, a word processor would only inform
(ie. inhibit) logout and not user switching.

In addition to all that, I think that blocking logout and requiring
the user to find and unblock all necessary applications is not a good
user experience.  The user should be in control.  If I am running for
a plane and I want to lose the CD I'm burning rather than melt my
laptop in my bag that is my right.  (The above Microsoft document
about Vista changes talks about this scenario too.)  If the list of
"blocked" applications is right in front of me, making this decision
is much easier.  Another subtle problem with this type of prompting at
logout is that it is a great time to present a trojan prompt - I'm in
a hurry and I'll click or do just about anything to log out.

We can still support applications that only know if they should
inhibit "just in time" by emitting a signal when a logout is
requested.  The applications can then take an inhibit in response to
that signal.

So, if state saving and logout handling is broken, what is left of
XSMP.  Primarily two things: lifecycle tracking, and restart handling.

I don't think these are sufficient reasons to continue to solely rely
on XSMP.  We can do these very well using D-Bus.

In XSMP, the client notifies the manager if and how it should be
restarted.  This may be ok, and we can simply have the manager expose
a D-Bus API for this.  However, it may make more sense to simply store
this in the .desktop autostart file.

Lifecycle tracking is basically just start and stop/exit
notifications.  We can support this by having the manager export a
RegisterClient method and then watching for bus name changes for the
caller.


I think we have an opportunity to improve the user experience, improve
the application developer experience, and have a better chance of
making something that can be wrapped with a cross platform API that
lives in GTK+.

On top of this we could layer things like a more sophisticated session
saving and detection of favorite/recently used apps.  Maybe something
like:
http://live.gnome.org/SessionManagement/AutoSession


So, that is the idea in a nutshell.  I have a working version of all
this in (please give it a try):
http://svn.gnome.org/viewvc/gnome-session/branches/dbus_based/

The D-Bus API:
http://svn.gnome.org/viewvc/gnome-session/branches/dbus_based/gnome-session/gsm-manager.xml?view=markup

And the inhibit dialog looks something like:
http://www.gnome.org/~mccann/gnome-session/Screenshot-gnome-session.png

There is also a bug that contains some outdated information:
http://bugzilla.gnome.org/show_bug.cgi?id=535829

What do you think?

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome

gnome-screensaver branched

[William Jon McCann]

Hi,

I have branched gnome-screensaver. The stable branch is gnome-2-22 and
development continues on trunk.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Where's the gnome wallpaper gone in E17 with the latest gnome?

[William Jon McCann]

Hi,

2008/4/26 The DarkMaster <[EMAIL PROTECTED]>:
...
> Update: I found that after launching nautilus in E17, the gnome wallpaper is
> setted in background.
>  Nautilus opens a fake desktop window when you opn it (to avoid this you
> should launch it with nautilus --no-desktop) and a normal browser window.
> When it crates the fake desktop window, it also settes the gnome wallpaper
> in background, so, if I killall nautilus, he gnome background remains there
> in background and the gnome-terminal displays transparency...
>
>  why does this happen? What's different from the previous Ubuntu version?
> Why is nautilus the one who handles this? And why in the previous version it
> was gnome-settings-daemon who took care of this? Does anyone know how can I
> find another way, maybe a command / script to be able to handle this
> background property of gnome without having to run nautilus at all?

Sounds like this:
http://bugzilla.gnome.org/show_bug.cgi?id=518750

Does it work if you set /apps/nautilus/preferences/show_desktop=false ?

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Dependency Proposal: Clutter 0.6.2, ClutterMM 0.6

[William Jon McCann]

2008/4/21 Luca Ferretti <[EMAIL PROTECTED]>:
...
>  Emmanuele, IMHO the better and faster way to show everyone the Clutter
>  goodnees is provide a Coverflow[1] like[2] plugin for Rhythmbox whitin 4
>  weeks ;-)

That would be awesome.

Here's the bug:
http://bugzilla.gnome.org/show_bug.cgi?id=415816

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Status of GDM for GNOME 2.22

[William Jon McCann]

Hi Joe,

2008/2/3 Joe Marcus Clarke <[EMAIL PROTECTED]>:
> The status of gvfs for GNOME 2.22 was recently discussed, and it seems
> good progress is being made on this to reduce regressions, but I have
> seen no mention of the regressions introduced in GDM 2.21.  The move of
> GDM to D-BUS has completely broken fast-user-switch-applet, and
> gnome-panel no longer shows the shutdown/restart options in its menu.
> Given that development is winding down on GNOME 2.22, what is going to
> happen with these components and GDM?

We have been giving weekly updates to the release team and the gdm list:
http://mail.gnome.org/archives/release-team/2008-January/msg00117.html
http://mail.gnome.org/archives/release-team/2008-January/msg00131.html

If you're interested you may join us on the gdm mailing list or #gdm on irc.

All regressions in fast user switching should be fixed this week.
First, we're making sure that the GDM greeter user selection works the
way we want it to.  Then we'll reuse much if not all of this code to
make the fast-user-switch-applet work again.  Some changes include
only showing the most frequent users in the user list instead of all
available users.

There is a patch for gnome-panel in bugzilla:
http://bugzilla.gnome.org/show_bug.cgi?id=511881

Three of us are working full time to make sure GDM is in decent shape
for 2.22.  Still, we'd appreciate help.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-screensaver and nautilus-cd-burner branched

[William Jon McCann]

Hi,

I have branched nautilus-cd-burner and gnome-screensaver. The stable branch is
gnome-2-20 and "development" continues on trunk.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Don't forget the some folks use network access to Gnome

[William Jon McCann]

Hi Seb,

On Dec 7, 2007 7:13 AM, Seb James <[EMAIL PROTECTED]> wrote:
...
> 2) I think this is one for the gdm developers or specifically for the
> gdm theme developers. The window that shows up when you choose "Log Out
> $user" or "Shut Down" always has slightly the wrong options when you are
> in an XDMCP environment. For example, the "Switch User" option is often
> available, which only works when you are at the real console of the
> machine. A little tidying up here and testing with XDMCP would add some
> nice polish to our favourite desktop environment.

And the user switcher applet should not be shown in this case either.
These and other things were included in the "What did we get wrong"
section of my GUADEC talk [1].  We aim to fix these with the new GDM
[2].

Jon

[1] http://people.freedesktop.org/~mccann/talks/guadec-multiuser.pdf
[2] http://live.gnome.org/GDM/NewDesign
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Timelapsed backgrounds

[William Jon McCann]

Hi Owen,

On 9/27/07, Owen Taylor <[EMAIL PROTECTED]> wrote:
...
> My first reaction to this is "cool!" But then, I think how much of
> the time is the desktop actually visible? It seems a bit of a wasteful
> thing to spend CPU cycles animating something that's entirely obscured
> by my full-screen web-browser/evolution/eclipse/etc.
>
> Maybe it makes sense to actually monitor desktop visibility in some
> fashion so that you could still get the "cool, my desktop is matching
> my time of day" effect without doing a full frame blend every 14
> seconds when nobody is looking at it. (This would probably require  a
> property exported by the CM, since only the CM really knows if the
> desktop is currently visible)

That would be useful for other things too.  Maybe:
http://bugzilla.gnome.org/show_bug.cgi?id=481073

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: High CPU load from image slideshow screensaver

[William Jon McCann]

On 5/29/07, Adam Rosi-Kessel <[EMAIL PROTECTED]> wrote:
> The image slideshow screensaver in gnome-screensaver puts such a load on
> my laptop's CPU that the fan runs constantly and tasks such as music
> playing with totem become very choppy. Although it's an older laptop, I
> would hope it wouldn't be viewed as totally obsolete: it's a Pentium III
> 700 MHz with 512M RAM.

I've replied to your original post [1].

Hope it helps,
Jon

[1] http://mail.gnome.org/archives/screensaver-list/2007-May/msg1.html
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

nautilus-cd-burner and gnome-screensaver branched

[William Jon McCann]

Hello,

I have branched nautilus-cd-burner and gnome-screensaver. The stable branch is
gnome-2-18 and development continues on HEAD.

No specific plans at the moment.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: ubuntu's shutdown screen

[William Jon McCann]

Hey Brian,

On 4/4/07, Brian Cameron <[EMAIL PROTECTED]> wrote:
...
> Obviously root needs to actually run these commands and I guess the
> display-manager daemon has been a convenient place for this logic.
> It might be better to move this functionality into a separate daemon
> that works with KDE and GNOME without depending on a specific display
> manager being used.

Another way to achieve this goal is to create a D-Bus interface for
this functionality (to replace the SUP) that can be implemented by any
DM.  This is one of my goals for the gobject refactoring. [1]

> It would probably be better if GDM supported the following:
...
> - GDM should be nicer about warning you that other users are logged
>in (say via XDMCP or virtual-terminals) before going ahead and
>shutting down the system.

Or possibly even remotely... we should be able to do this with more
ConsoleKit integration.


Jon

[1] http://bugzilla.gnome.org/show_bug.cgi?id=376010
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Fast User Switch Applet development

[William Jon McCann]

Hi Calvin,

On 2/13/07, Calvin Gaisford <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-02-12 at 14:15 -0500, Thomas Thurman wrote:
> > On 12/02/07, Calvin Gaisford <[EMAIL PROTECTED]> wrote:
> > > Has there been any discussion on making the Fusa functionality available
> > > in other components?  I've been playing around with the code and have
> > > created a library and dialog that borrows heavily from the fusa code
> > > base.  I'd hate to duplicate this code all over the place and would like
> > > to propose an addition that would allow other desktop components to
> > > display a switch user UI.
> > >
> > > There are a bunch of ways this could be done (small application,
> > > library, dbus interfaces into fusa, maybe all three?) but I'd like to
> > > start a discussion about it.
> >
> > What would a dbus interface to fusa do that an interface to gdm
> > wouldn't? After all, fusa is nothing but a bunch of code to do applet
> > stuff and a bunch of code to talk to gdm. Very recently, gdm itself
> > has added a dbus interface, and I'm working on making fusa use that.
> > So what you want is probably to talk to gdm directly.
>
> The dbus interface was just an idea to get the applet to popup a
> switching UI... perhaps not that useful if a library is created.  Beyond
> the applet and gdm code, fusa has some nice code to retrieve switchable
> users with their icons, names, and active logins.  It would be nice to
> share that code through a library so other components don't have to copy
> or reproduce it.

One problem is that the way FUSA works at the moment is not very
efficient.  It does things like periodically polling gdm for updates,
watching /etc/passwd, /etc/shells, and the gdm.conf files for changes,
storing information on all users and user images, etc.  Basically
every copy is a little polling database daemon.  So, it doesn't really
lend itself to making into a library in its current form.

This is not the fault of FUSA, by the way.  We just don't have the
necessary framework to do this right.  I think that is really where we
need to direct our energy.

I think we need:
  1. A framework for defining and tracking login sessions
- what sessions are available
- which session is active
- can we switch to that session (ie. is it on the same seat)
- session add/remove events

 2. A framework for user directory services
- what users are available
- get/set metadata for user (user images, default timezone,
anything in about-me, etc)
- user add/remove events

David and I have been trying to solve at least the first problem with
ConsoleKit.  The second problem I've only started to think about.  For
the purposes of FUSA I think the things we still need better answers
to are:

  * How can we sanely detect new users and removed users when not
using /etc/passwd?
  * What is a reasonable way (ie. not the way we do it now) to manage
and retrieve face images?

And before anyone asks if we should support FUS for arbitrary name
service providers.. yes we should. :)

So, what do you want to add a user-switching interface to?

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: slab menu

[William Jon McCann]

Hey Rodrigo,

On 2/6/07, Rodrigo Moya <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-02-05 at 14:42 -0500, William Jon McCann wrote:
> > Regarding configuration, I think the slab is in a better position to
> > provide an interface that doesn't require configuration of quick
> > access to the most used tools.  It apparently has something called
> > "Recently Used Applications" (which is empty for me but I can imagine
> > what it is supposed to do).  Even though I think "Recently" isn't
> > really as interesting as "Most Frequently".
> >
> it says 'Recent' because it just lists the apps you just used.

Right.  But I think that is less useful than showing the apps that I
use most frequently.  This would save me a trip to the app browser
more often than the current approach, right?  For example, just
because I used "Take screenshot" last doesn't mean that I'm most
likely to use it next.  Or just because I played 6 games doesn't mean
that Web Browser should be bumped off the list.

> > [1] When the maintainers start reviewing patches in bugzilla ;)
> >
> there are so many CC bugs that even though we are reviewing all, we are
> very slow, so please be patient :-)

I was referring to the gnome-main-menu bugzilla component.  :)

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: slab menu

[William Jon McCann]

On 2/5/07, Wouter Bolsterlee <[EMAIL PROTECTED]> wrote:
> 2007-02-05 klockan 20:42 skrev William Jon McCann:
> >  * when you don't know the appropriate category for an application
> > (Evolution is in Internet, right?)
>
> Yeah, why don't we put Evolution in both the Office and Internet categories?
> It would make the lives of many people a lot better and the patch is
> trivial:
>
>   Index: evolution.desktop.in.in

OK, well as long as you brought it up :)

Or maybe something like this:
http://mail.gnome.org/archives/evolution-patches/2004-April/msg00031.html

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: slab menu

[William Jon McCann]

Hi Calum,

On 2/5/07, Calum Benson <[EMAIL PROTECTED]> wrote:
> On Mon, 2007-02-05 at 13:02 -0500, JP Rosevear wrote:
>
> > How is it slow to get to things vs a traditional hierarchal menu? My
> > important apps are two clicks away -> open menu -> click.  Hierarachal
> > menus more clicks than that.  Don't like the default list?  Drag from
> > the app browser and drop them on the menu.
>
> Much as we'd all like it to be untrue, that's still more customisation
> than many (most?) "average" users are either willing to do, or have the
> knowledge to do, or (in some cases) are allowed to do by their sysadmin.
>
> You should see the state of the Start menu on my wife's Windows laptop,
> it takes up almost the whole screen, and it's not even in alphabetical
> order :)  But she says she has no interest in streamlining it, and
> wouldn't know how to anyway.

One thing that I think bears mentioning is that really no one uses the
menus as the sole interface to their applications.  They use the menus
supplemented by launchers on the panel.  Menus themselves are a pretty
poor interface for a least a few cases (in my experience):

 * accessing common tools quickly (who goes to the menu for a web browser?)
 * when you don't know the appropriate category for an application
(Evolution is in Internet, right?)
  * when you don't already know what's in a submenu
  * when you don't have a high precision pointing device (eg. a
trackpad, nipple pointer, your fingers) - even though the panel menus
are way better than firefox's in this regard
 * when the menu list is longer than the screen is high
 * when you don't know what you are looking for (something that does
something with photos)

I'm sure there are others but these are the ones that bother me.

Also, having a menu based UI essentially dictates that we must use
launchers for common tools.  Which requires the kind of configuration
that you argue against above.  It also implies that we use two or more
panels in order to support all of our recommended UI (menu, launchers,
clock, volume applet, window list, notification area, etc).  Unless of
course you go the Windows route of putting launchers on the desktop
itself which I think most agree isn't that good.

Regarding configuration, I think the slab is in a better position to
provide an interface that doesn't require configuration of quick
access to the most used tools.  It apparently has something called
"Recently Used Applications" (which is empty for me but I can imagine
what it is supposed to do).  Even though I think "Recently" isn't
really as interesting as "Most Frequently".

In other mails I think you make a good case for why the 2D tile layout
isn't always best.  But maybe there are other ways to fix this than
resorting to a menu like interface.  Not sure.

I don't think that menus are immune from hunt and peck hell either.
Part of the problem that you describe about the Windows start menu is
that it is still a menu (be it an analphabetical and deeply nested
one).  And yeah, it sucks.

So, I've been pretty happy with my switch to using the slab (and going
from two panels to one) for the last month or so.  Still, I'm sure it
can be improved [1].  I'm not sure I've ever intentionally clicked on
the hard drive status for example.

Jon

[1] When the maintainers start reviewing patches in bugzilla ;)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposed module: gnome-main-menu

[William Jon McCann]

Hi Rodney,

On 1/9/07, Rodney Dawes <[EMAIL PROTECTED]> wrote:


On Tue, 2007-01-09 at 17:44 +, Bill Haneman wrote:
> Since there was a lot of a11y work in the existing menu code, I doubt
> that g-m-m would "just work" for all of our a11y scenarios without
> bugfixes/tweaks.

Can you explain those scenarios? As I said in a previous reply, I spent
a lot of time making a11y in the main-menu work. If there are specific
scenarios that we need to check for, then we should get those formalized
into a test suite somewhere, and get the tests run on all our apps.



One scenario where it fails pretty badly is for low sighted folks (or people
like me who prefer large fonts).  The slab's "Show:" pane isn't really
usable at a font size greater than 16 pt on my computer.  This is due to
overaggressive use of ellipsis and using two columns even when there isn't
enough space.  I've filed some bugs related to this and am willing to help
out.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Playing a sound in GNOME

[William Jon McCann]

Hi,On 10/31/06, Étienne Bersac <[EMAIL PROTECTED]> wrote:
Hi,I fully agree with you. I must point the GSmartMix project which isbased on gstreamer and allow fine mix between app. If nautilus-cd-burnerwas able to simply play a sound at the end to the burn process, it must
do that in a consistent fashion that allow a desktop mixer todynamically mix the sound, i.e. if the sound level is different if theburner has the focus or not, etc.The incredibly detailed bug report is here:
http://bugzilla.gnome.org/show_bug.cgi?id=339638 It seems to me that the various solutions that have been mentioned so far aren't super.  I would expect to be able to do something like:
gtk_sound_play_stock ("gtk-done");gtk_sound_play_stock ("gtk-warning");etc.I filed http://bugzilla.gnome.org/show_bug.cgi?id=368304
One advantage of having something in gtk is that message dialogs can have their own sounds (one per GtkMessageType) without the application having to do anything.And then we'll probably need some guidelines in the HIG so that we don't go overboard.
So, if GStreamer is used for this on unixy systems how do we avoid the problem where shipping certain plugins makes the entire stack GPL incompatible?  And hence: 
http://doctau.blogspot.com/2006/10/rhythmbox-re-licencing.htmlUnless the sounds are played out of process.Jon 
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal: gnome-main-menu for inclusion in GNOME 2.18

[William Jon McCann]

Hi Jim,Where should bugs be filed?  I don't see a component in gnome bugzilla.  I suppose one should be created.Some initial thoughts from just a first look so they may be ignorant and superficial:* Ellipsis is used for items that require input (eg. "Log Out...") and for those with not enough space.  This is a bit confusing.
* Lock Screen doesn't require input so shouldn't have ellipsis I guess.* With a largish font size (that I use - getting old I guess) pretty much everything in the "Show:" pane has an ellipsis and doesn't show enough chars to be useful.
* The dialog seems to be shown before it is move-resized so it jumps when the Computer button is clicked.* The recent documents list doesn't get cleared correctly.  For example: use the standard GNOME places menu to clear the recent documents and the slab list doesn't clear.  Is there a way to clear the list in slab or do you not look at "inappropriate content"?
* If there aren't enough items to fill one column of the "Show:" pane then there is probably no point in showing the second column - use all the space for the first.* Nothing except "Home F..." shows up in my Favorite Applications list.
* Nothing shows up in my Recently Used Applications list.* When I drag a launcher from the panel onto the Computer button I expected it to open so I could drop into my favorites list.* Might be nice to have Sleep/Hibernate on the System action list (using 
org.gnome.PowerManager).* The Control Center shell thingy uses ellipsis on names even when it has enough space to show them (uses a fixed with for the item?).* Control Center only shows Assistive T... and Keyboard for some reason.
* Is there a way to include Places?Looks really nice though.  And congratulations and thank you for not using submenus.Thanks,JonOn 10/20/06, 
Jim Krehl <[EMAIL PROTECTED]> wrote:
On Thu, 2006-10-19 at 21:09 -0700, Corey Burger wrote:> I have a few questions:> How do you see this menu structure interacting with the existing two> menu options?> Are you proposing that we replace our currently three menu structure
> with the single one of the gnome-main-menu?No, that's not my proposal.  A hierarchal, static menu, such as thetraditional main-menu is suited to those who are more organized thanothers.  Whereas a flat, responsive menu, such as is proposed, is more
suited to people new to the GNOME desktop or people whose idea ofapplication organization differs from those who designed the traditionalmain-menu's menus.  I see room for both approaches in GNOME and distros
can make their own decision about which menu to use by default.> For the non-hackers in the crowd, what langague is it written in?C.Thanks!jimmyk___
desktop-devel-list mailing listdesktop-devel-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/desktop-devel-list

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

nautilus-cd-burner branched for 2.16

[William Jon McCann]

Hello,I have branched nautilus-cd-burner. The stable branch isgnome-2-16 and development continues on HEAD.Plans include:  * Better error reportingJon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-screensaver branched for 2.16

[William Jon McCann]

Hello,I have branched gnome-screensaver. The stable branch isgnome-2-16 and development continues on HEAD.Plans include:* Adding a power management baseline timeout
* Doing less polling* Try to standardize theme format (bug #354811)* Interacting with ConsoleKit* Adding a keyboard layout indicator to dialogJon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-screensaver branched for 2.14

[William Jon McCann]

Hello,

I have branched gnome-screensaver. The stable branch is
gnome-2-14 and development continues on HEAD.

Plans include:

* Add refcounting to Inhibit DBUS API (bug #334907)
* Removing themes from the list (bug #316462)
* Add XEVIE support (bug #337203)
* Full-screen preview (bug #329246)
* Respect /apps/panel/global/disable_lock_screen (bug #317609)
* Theme unlock dialog (bug #324086)
* More integration with gnome-power-manager

Jon



___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

nautilus-cd-burner branched for 2.14

[William Jon McCann]

Hello,

I have branched nautilus-cd-burner. The stable branch is
gnome-2-14 and development continues on HEAD.

Plans include:

* Verify CD feature (bug #125470)
* Write DVDs without using a temporary image (bug #113480)

Jon


___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-screensaver

[William Jon McCann]

Hi Vincent,

Vincent Untz wrote:

Le mercredi 15 février 2006 à 11:45 -0600, Shaun McCance a écrit :


On Wed, 2006-02-15 at 12:54 +0800, Davyd Madeley wrote:


Quoting David Zeuthen <[EMAIL PROTECTED]>:



This was moved to gnome-power-manager by Jon, as monitor DPMS control
was considered more of a "power" thing than "screensaver" thing. You can
configure monitor power down settings using gnome-power-preferences.


[...]


I see two solutions to this:
(1) solve the regression; or
(2) punt gnome-screensaver until gnome-power-manager can also be included

I personally think that (1) is the correct solution here, mostly 
because I think

that monitor sleep time should be in the same dialog as screensaver settings.



Jon, do you have any opinion on this/plans for this?


Moving DPMS to gnome-power-manager was a decision that was discussed on 
both the screensaver and power-manager lists over a month ago and was 
decided based on its merit by a consensus.


In the past month or so there have been a number of long threads on this 
list discussing issues with gnome-power-manager and gnome-screensaver. 
These discussions have included ideas of widely varied validity.  We've 
kindly asked that people submit bugs for these ideas.  Some have done so 
and these have essentially all been dealt with.


It was then decided by the release-team that gnome-power-manager would 
not be included in GNOME 2.14.  Here was the stated reason:


  + gnome-power-manager: people like it, but some mor work is needed,
and more integration should be done. It won't go in for 2.14, but
we'd like to see a good integration work starting soon for 2.16.

I submit that unless such a decision points to specific feature, 
robustness, or integration bugs it lacks validity.  Think of it this 
way: how is Richard supposed to know what to work on - or what if these 
can all be fixed within the day?  This is one reason why we have the 
same discussions every release cycle.


Let me address the primary concern that was given - lack of integration. 
 It is precisely because gnome-power-manager is well integrated that we 
are now having a discussion about whether gnome-screensaver should be 
excluded from GNOME 2.14 simply because it is well integrated with 
gnome-power-manager.



Allow me to point out that one of the most vocal opponents of both 
gnome-power-manager and gnome-screensaver has never contributed so much 
as a bug report to either project.



So, to address the question more directly, I will not redesign 
gnome-screensaver to fit more nicely with GNOME release process if it 
results in an inferior product and destabilizes the code. 
gnome-screensaver works very closely with gnome-power-manager and that 
is the way we all want it.  For example, I would love to add the button 
link to gnome-power-manager that David has suggested.


I urge you to review your decision not to include gnome-power-manager in 
GNOME 2.14.


Thank you,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: requesting official list of modules and versions for GNOME 2.14

[William Jon McCann]

Hi Davyd,

Davyd Madeley wrote:

On Fri, Feb 10, 2006 at 12:27:34PM +, Richard Hughes wrote:


A comment about the "notification spam": the user only gets 4
notifications for "low battery", "very low battery" and "critical
battery" and one saying "I'm doing the low-power action in 10 seconds"
-- and then there are a 2 optional notifications (i.e. that you can turn
off in gconf) for things like notification when you remove the
ac_adapter, or when the battery reaches 100%.


This is exactly what I mean by notification spam. I hope to get some
clarification on what is good notification and bad notification that
is suitable for the HIG shortly.


In my opinion this is possibly the most clear cut and legitimate case 
for using notifications.  I think a message that essentially says that 
your computer will run out of gas in 2 minutes is hardly "notification 
spam".


Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-screensaver

[William Jon McCann]

Hello Davyd,

Davyd Madeley wrote:

I see that both Ubuntu Dapper and Fedora Core 5 test 2 are shipping
with gnome-screensaver now.

Having now used both of them, does it seem slow for anyone else? It
seems that something has gone astray once or twice and forced me to
have to change vt and kill the process to get my session back.


I suspect that you may be running into:
http://bugzilla.gnome.org/show_bug.cgi?id=328441

If you think it is something else feel free to open a new bug and we can 
try to track it down.


Also, if you are on a system with a large number of users (>500) you may 
experience problems when running with user switching enabled.  This is 
one reason why it is off by default.  It can be enabled or disabled 
using gconf.



I didn't manage to get anything useful debugging-wise from it, does
anyone know the story here?


You can get debugging information from g-s by running it like so:
gnome-screensaver --no-daemon --debug


If we have a screensaver that you can't get away from, we should
consider not including this module during this release cycle.


I haven't experienced anything like this but that would indeed be a 
serious problem.  I strongly encourage anyone experiencing such a thing 
to create a bug for it and work with me to solve the problem.


Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: New modules in 2.14

[William Jon McCann]

Hi Ryan,

I should point out that I can't speak for Richard, or David and these 
are merely my interpretations of their work.


Ryan Lortie wrote:

On Wed, 2006-18-01 at 10:32 -0500, William Jon McCann wrote:


How is a system daemon more secure than a user session daemon?


A system daemon runs as root (or some other 'special' user) and can be
given special abilities without giving them to the user.  A system
daemon is also immune to user tampering.


User tampering?  You mean like pulling the power cord?  This is pretty 
silly.  Clearly, in a system that requires strict lockdown you won't be 
using user controlled power management.


Using an out-of-session daemon has a number of disadvantages:

 * I think it is harder to write securely.
 * Policy would still have to be defined in the session.
 * You also need to provide a mechanism for the user session to 
communicate policy.
 * You still have to figure out which session is on console in order to 
arbitrate policy choices.

 * You have to determine which session is allowed to invoke actions.
 * Something in the user session still has to trigger a shutdown, 
suspend, or hibernate.

 * Need a way to communicate feedback, notifications, etc to the user.

So, in the end, the session still has the ability to perform power 
management actions and the "who's on console" issue is not solved.


I think the who's in control of the console issue is larger than g-p-m.

g-p-m doesn't require any additional privileges.  HAL is doing most of 
the work.


This is exactly the problem.  In order for g-p-m to do its stuff we have
to add to HAL the ability for any user to say "suspend the system
now" (since g-p-m needs to do this and it's just running as a normal
user).  If any user can say "suspend now" then I can be logged in as a
background user and play nasty tricks on the console user.  HAL
currently has no mechanism for making a distinction between background
users and the user that currently 'controls' the machine.

When you add additional privileges to HAL you also increase the chance
that someone is able to exploit a security hole in HAL itself.  Martin
Pitt, for example, has ranted about this at length because it's not a
good idea (and even found some security problems to validate his
concerns).


This seems like a general argument against HAL and not g-p-m in particular.

Can you please provide some reasons why g-p-m is "very Gnome-centric"? 
It uses the system tray standard and provides a DBUS interface that any 
application can use.  This DBUS interface could be standardized with 
freedesktop.org once we figure out what works for us.  Yes, it has GNOME 
in its name and uses Gconf and GTK+.


You provided my reasons for me.  You could say that all Gnome
applications are sufficiently cross-desktop because they connect to the
X server through the standard protocol.  They do not, however, have the
Qt look and feel so they stick out like a sore thumb.  KDE users are
also not interested in having Gconf and GTK+ installed.  For this
reason, you can't honestly expect KDE to use g-p-m.


Oh, come on.  So, you're referring to the preferences dialog only?  I 
think there are two equally simple ways to solve this (if you care). 
Write a policy abstraction that can get from either GConf or the KDE 
equivalent and make a preferences dialog in Qt, or write a 
kde-power-manager that uses the same DBUS interface.


Adding an application to the Desktop release doesn't make too many 
guarantees about its API availability.


We talked about this in #gnome-hackers a bit before I wrote my mail
listing my concerns.  Jeff (I think!) brought up the example of esd and
said that it's very hard to remove something once it's included.  Once
apps start to depend on it it -does- become difficult to remove.


That doesn't mean it must always be the case.  Again, the application is 
not nearly as important as the DBUS API.



Another issue is that right now some distributions are using power
management systems that are vastly different from how g-p-m works.  If
we include g-p-m we are encouraging people to depend on it and making
life difficult for those distributions that do not want to ship it.


I think it is the interface that counts.  As long as the DBUS interface 
is sane then you should be able to plug whatever you want in to provide 
that service.


g-p-m is a session daemon.  It uses the D-BUS session bus and does not
listen on the system bus.  Most distributions have power management
systems that run at the system level.  It's difficult for things not
running as part of the user's session to connect to the user's session
bus (in fact, the default policy is to reject non-user connections -
even those from root).  You also have to somehow 'snoop' the bus
location out of the environment of another process.  You also assume
they use D-

Re: New modules in 2.14

[William Jon McCann]

Hello Ryan,

You have some interesting comments about power management.  I too have 
been thinking about this recently and I have a few questions and comments.


Ryan Lortie wrote:
[snip]

Certainly, at the current time, it appears to be the best offering.
However, after discussing this at length at Ubuntu Below Zero, I
believe, that we'd be better served by a system with the two following
key properties:

1. Based on system daemon.
  This would make the system more secure as a normal user process
  wouldn't be given the ability to 'suspend now' as g-p-m (and 
  any system which makes policy decisions at user privilege) currently

  requires we provide it with.  This (and other privileges that g-p-m
  need to be provided with) have serious security implications.
  Having a system daemon would also mean that the policy system runs
  when the user is not logged in without resorting to hacks like gdm
  invoking a private copy of g-p-m.


Can you provide some reasons why you think g-p-m has "serious security 
implications"?


How is a system daemon more secure than a user session daemon?

g-p-m doesn't require any additional privileges.  HAL is doing most of 
the work.


I think the whole on-console issue is a complicated one and one that 
certainly isn't limited to power management.  It seems to me that most 
of your arguments apply equally to gnome-volume-manager or any of the 
other session daemons.



2. More platform-neutral approach.
  The technologies on which g-p-m is based have seen wide acceptance
  from other desktops.  We should try and create a power management
  system that has the same acceptance.  g-p-m is very Gnome-centric.
  With a faceless system daemon doing all the real hard work we could
  have multiple configuration front-ends (Gnome, Qt, etc).


Can you please provide some reasons why g-p-m is "very Gnome-centric"? 
It uses the system tray standard and provides a DBUS interface that any 
application can use.  This DBUS interface could be standardized with 
freedesktop.org once we figure out what works for us.  Yes, it has GNOME 
in its name and uses Gconf and GTK+.



Of course, this wonderful system does not exist.  Again,
gnome-power-manager is the best offering we have at this time.


Great.


This does not mean, however, that we should put include it in Gnome
proper.  Once things are in, they have a tendency to stay around
forever.  Applications form hard dependencies on them.  If we are going
to standardise on a solution it should be the best possible solution --
not just the best thing that we have right now.  If we aren't sure that
the thing we have now is the best possible solution then it's
appropriate to wait.


Adding an application to the Desktop release doesn't make too many 
guarantees about its API availability.



Another issue is that right now some distributions are using power
management systems that are vastly different from how g-p-m works.  If
we include g-p-m we are encouraging people to depend on it and making
life difficult for those distributions that do not want to ship it.


I think it is the interface that counts.  As long as the DBUS interface 
is sane then you should be able to plug whatever you want in to provide 
that service.



Essentially, I think that (a) we should not rush into this and (b) we
should, at the current time, leave this up to distributions to decide.
We do them no harm by not including it since they can include it anyway.



Historically, distributions have always been able to make their own 
choices regardless of what was in the Desktop and I think this can still 
be true.


The question comes down to: is there sufficient reason not to use the 
best solution we have in favor of one that hasn't been spec'd, reviewed, 
or developed in the community or at all?


Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Browser Mode by Default [Was: Nautilus]

[William Jon McCann]

Hi Jeff,

Jeff Waugh wrote:

... and yet users will still ask: "What are all these windows doing all over
my screen?" -> *that* is the big scary thing staring them right in the face.


So, this gets to the heart of the question.  In spatial mode this 
situation can only occur if the user commonly uses lots of directories, 
or deeply nested ones.


Is this the most common scenario for our target user?

I think it is not.  I observe people saving files to the default save 
location for the application (web browsers, office tools, etc).  And 
leaving them there.


I think we should have standard locations for these defaults [1].  With 
that there won't be lots of scary windows on the screen - only say 3: 
Documents, Pictures, Music.


Happy Holidays,
Jon

[1] 
http://mail.gnome.org/archives/desktop-devel-list/2004-October/msg00016.html

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[William Jon McCann]

Rob Adams wrote:

The moral of the story is you're screwed on multi-user terminals.


That is, if you rely on prompting the user for passwords alone.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[William Jon McCann]

Hi Pat,

Pat Suwalski wrote:

I was thinking that the root password could unlock the screensaver
regardless of whose screensaver it is. So, in order:

 - User password
   - Success: close screensaver
   - Failure:
 - Root password
   - Success: close screensaver
   - Failure: continue


You weren't cheating and reading the code [1] were you?  ;)

That is how it works now.  However, you'll most likely need to setuid to 
root for this to actually work.


Jon

[1] 
http://cvs.gnome.org/viewcvs/gnome-screensaver/src/passwd-pam.c?view=markup

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[William Jon McCann]

Hi Shaun,

Good comments.  I'll reply inline.

Shaun McCance wrote:

* On https://wiki.ubuntu.com/ScreenSaver there's the suggestion:

...an OS-X-like dialog shake would save having to print ugly
"That password was incorrect" text.

I notice that you have the shake effect, but that you still have
the "ugly" text.  Please keep it that way.  I very much doubt
that our accessibility tools can say "the dialog is shaking its
head 'NO' at you."


I plan to keep the text.  I've found that some people don't intuit that 
the shake means no.



* The timeout when you type an incorrect password is very long.


Yes it is.  I found that some novice and show users weren't able to 
notice, read, and understand the error message text before the dialog 
disappeared.  It used to be quite a short timeout but I extended it 
recently.  Perhaps, I've extended it too much.



* Same wiki page:

Use the gdm login screen for switching accounts, and tidy it up.

I've long held that XP got the interaction right.  There's just one
login screen.  Unlocking your screen is just logging back in again.
Switching users is just logging in.

Right now, we have the OS X interaction: We have a login screen
and a separate unlock dialog.  The unlock dialog has a button to
switch users, which takes you to another login dialog.  Ideally,
I'd like to see an effort to make gdm the One True Login Screen,
regardless of whether you're logging in for the first time or
unlocking a running session.


I agree in part.  Unfortunately, it gets a bit complicated both 
technically and politically.


If user switching is not enabled then using a display manager as an 
unlock dialog doesn't make much sense.  It will involve more time and 
more user interaction to unlock the screen.  In the short term I expect 
that many vendors will ship with user switching off by default until we 
can solve all the problems with device ownership.


At the moment we can't require GDM to be present and running in order to 
lock the screen.  The vendor may use another DM or no DM at all.


We must also take care that the locked screen is never a dead end for 
the user.  This is important.  Consider what happens if the user does a 
VT switch either by using FUSA, GDM, manually by keyboard, or by 
accident.  The user will end up at someone's locked screen.  There must 
be a way for the user to get back home to their VT.


I think in the long run we can integrate FUSA, GDM, and 
gnome-screensaver better but we have some more work to do.



* As long as we have the model we have now, the user-switching
dialog needs love.  Right now, it displays a list of all the
users.  The list is tall enough to accommodate about 1.2 users.
I regularly use a machine that has hundreds of users.  That's
not a fun list to scroll through.


Most of the time if you have a face image showing on the other page then 
you will be able to see more users at a time.


I am also in a system with hundreds of users so I understand.  You can 
use gtktreeview type-ahead find to speed up your searches.  On my system 
I can find my user name in two keypresses and one mouse click.  This is 
much faster than typing my entire username.



* And on that note, I'm a keyboard-happy kind of person.  I'm
a big fan of just typing my username.  I think face browsers
are great for small home installations.  But there needs to
be a way to type.


You are probably right.  I'll think about how to add this.


* And on that note, there needs to be a way to disable the
face browser entirely.  In a lot of settings, sysadmins don't
want to show a list of all users to people who might not even
have accounts on the machines.


The user switching is off by default.  It must be enabled by setting the 
GConf key /apps/gnome-screensaver/user_switch_enabled to TRUE.



* You've hidden quite a lot of options.  All well and good.
But we can't just hide things that people use, unless we've
really provided a better system.  Case in point, I actually
use the setting for when to lock the screen after it's blanked.
Removing that setting annoys me, unless you make it Just Work
so I don't need the setting anymore.


I've heard this complaint before.  I think there is another possibility 
besides adding such an option.


http://bugzilla.gnome.org/show_bug.cgi?id=309142


Anyway, just my 2¢.  I'm glad somebody is finally tackling
this issue.  Keep up the good work.


Thanks for the excellent questions.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[William Jon McCann]

Hi Rodney,

Rodney Dawes wrote:

How about...

3. Unlocking the screen with the root password should do the same as
choosing switch users, and logging in as root. Not doing so is a privacy
and security issue, as it may allow root access to remote hosts, that
root normally does not have access to.


Surely you aren't suggesting that people log in to GNOME as root?  I'm 
not sure I understand the use case here.


Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[William Jon McCann]

Hi Rodney,

Rodney Dawes wrote:

On my machine, it seems to use a horrendously scaled up version of the
image not found icon, albeit, not the one in my icon theme. This is also
an ugly thing to show, and is going to show up the majority of the time,
as most people do not set faces. It's also centered, which looks a bit
weird, given the dialog's contents. Perhaps it should be left aligned,
with the text to the right of it, and left aligned as well.


You may not be using the latest version (0.0.17).

I tried using a horizontal layout.  It just didn't feel balanced.  Look 
at it as the user's name is the caption for the face image.


Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[William Jon McCann]

Christopher James Lahey wrote:

What does it have if the person doesn't have a face?
  Chris


A bag?  No, in fact, the latest version doesn't use an image if the face 
image is not available.


Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[William Jon McCann]

Christopher James Lahey wrote:

On Wed, 2005-10-26 at 09:11 -0400, JP Rosevear wrote:
On Tue, 2005-10-25 at 15:06 -0400, William Jon McCann wrote: 


 * Don't display the "Unlock" button when show the switch users options


This makes sense.


Deleted the original email, sorry.

I don't understand this.  When don't we display Unlock?  Isn't it
usually the case that you want to either Unlock or Switch Users?  I
can't think of a time that they both shouldn't be displayed.


Sorry, I should have been clearer in my explanation.  I meant that now 
it doesn't show the unlock button on the switch users option "page" that 
is visible after she has already clicked "Switch user" on the unlock 
"page".  See the images in Design/Switching Accounts on 
https://wiki.ubuntu.com/ScreenSaver for a comparison.


Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[William Jon McCann]

Hi JP,

JP Rosevear wrote:

I think its wrong to assume the face stuff will be used everywhere and
then to feature it prominently, essentially forcing it to be used or to
get a meaningless (large) abstract person all the time


The large, and fuzzy abstract person is not used in the latest (0.0.17) 
version.  I have been surprised at how many people dislike goatees.


So, the face images will only be used if available.  This is consistent 
with the GDM face browser.


It might also be nice to have a mechanism for vendors and sysadmins to 
brand the unlock dialog.


 * Center user's name instead of using a tabular layout for 
username/password fields
 * Don't show the stock lock icon 


We use tabular in lots of other places.


Which is partly why I had it that way initially.  I'll try to explain 
why I changed my mind after considering Matthew's proposal.


We don't use use a tabular layout in GDM which is what we should be 
consistent with.  We don't use it in GDM in part because PAM drives the 
UI and there won't necessarily be a password prompt.  I have heard from 
a few Sun developers who would like to make PAM drive the unlock dialog 
in a similar way.  For example, in a smart card enabled environment 
there might not be a password prompt at all.  That would be really 
sweet.  As an aside: I despise passwords - my screen should know I'm me.


If we don't have a password prompt the tabular layout doesn't make as 
much sense.


The tabular layout is clean but perhaps too clinical or technical. 
Whenever I see a tabular layout with colon delimiters I read it as if it 
were spoken in a robot voice.  I call this the robot voice heuristic.


Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[William Jon McCann]

Hi JP,

JP Rosevear wrote:

I'm in favour with a couple of notes:

1. I liked the UI for unlocking circa 0.13 much better than the current


I made some changes in response to Matthew Paul Thomas' analysis [1].  I 
don't agree with all of his conclusions but overall it seemed to be 
"less" which as we all know is "more" - so it won me over.  Also worth 
noting is that as a result of less complexity and fewer images the 
startup time improved significantly.


The changes were basically:

 * Show a "face image" if available
 * Center user's name instead of using a tabular layout for 
username/password fields

 * Don't show the stock lock icon
 * Don't display the "Unlock" button when show the switch users options
 * Remove the progress bar

We have some other bona fide user interface experts on this list so 
maybe they can help out here.



2. The extra settings like DPMS need to be exposed like in xscreensaver
or move somewhere appropriate


I'm hoping that there will soon be one place for all power management UI 
and policy.


Jon

[1] https://wiki.ubuntu.com/ScreenSaver
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Proposal for inclusion in desktop: gnome-screensaver

[William Jon McCann]

Hi,

Xavier Bestel wrote:

Just for the record, does it run xscreensaver hacks ? Especially OpenGL
ones ?


Sure does.  More details are in the FAQ:

http://live.gnome.org/GnomeScreensaver_2fFrequentlyAskedQuestions

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Proposal for inclusion in desktop: gnome-screensaver

[William Jon McCann]

Hello,

I am pleased to propose gnome-screensaver for inclusion in the GNOME 
2.14 Desktop release.


gnome-screensaver is a new screensaver that can replace xscreensaver. It 
is designed to integrate well with the desktop and provide an control 
interface that is desktop neutral. It simplifies and streamlines the 
experience for the user and provides more capability for the system 
administrator and vendor.


It is designed to support:

* a desktop neutral control interface via DBus
* a desktop neutral and standard way to install
  and manage screensaver themes
* switching users directly from the unlock dialog
* allowing a system administrator to set a mandatory policy
  for any setting
* a secure separation of user input processing and authentication
  from the screen locking window
* a separation between the screensaver theme engine
  and the theme settings
* integration with the desktop (themes, fonts, toolkit)
* translation into many languages by the GNOME Translation Project
* instantly applying settings changes

More information can be found on the Wiki page:
http://live.gnome.org/GnomeScreensaver

Thank you,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Moving Applets

[William Jon McCann]

Hi Davyd,

Davyd Madeley wrote:

Applet  Current ProposedNotes
--  --  -
clock   panel   applets remove e-d-s dep in panel


This has come up a few times now and I still don't really understand it.

I think e-d-s is destined to become part of the GNOME platform.  So, I 
don't think that the panel depending on the platform is a bad thing.


Also, given that every panel by default will include the clock applet, 
by moving the clock to gnome-applets you will implicitly make 
gnome-panel depend on gnome-applets.


Would this change solve any problems?

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

nautilus-cd-burner branched for 2.12

[William Jon McCann]

Hello,

I have branched nautilus-cd-burner. The stable branch is
gnome-2-12 and development continues on HEAD.

No big plans for GNOME 2.14 - just fixing bugs.

Jon

___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-power-manager in 2.14, was: new modules for 2.12

[William Jon McCann]

Luis Villa wrote:

I'm guessing gnome-power-manager[1] and gnome-screensaver fall into the
2.14 time-frame.


And fast-user-switcher. I'd personally *love* to see that whole pile
land in 2.14.


My hope is that we can get a nice DBus interface to GDM going by then.
http://bugzilla.gnome.org/show_bug.cgi?id=311623

Then comes bliss.

In the meantime, cool kids can:
  * run GDM, fast-user-switch-applet, gnome-screensaver from CVS HEAD
  * use a GDM theme with a face browser enabled
  * enabled face browsing for all users in gdmsetup
  * select a face with gdmphotosetup
  * set the AlwaysLoginCurrentSession=true in gdm.conf

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: xscreensaver, any plan do drop it !!

[William Jon McCann]

Hi David,

David Zeuthen wrote:

1. How do see this being integrated with power management solutions like
e.g. the existing gnome-power project and some of the ideas that were
discussed at GUADEC [1]? 


This is certainly the next step.  Up until now I have been concentrating 
mostly on feature parity with xscreensaver.


There is some overlap between gnome-power, gnome-screensaver, gdm, and 
the fast-user-switch applet.  We need to make sure they are all in 
concert.  Perhaps a new gnome.org mail list is in order on which to 
discuss these issues (gnome-power-list)?


A few initial thoughts.  We need to make a distinction between system 
idle and session idle.  We need to make screen power management work 
sensibly with user switching where the session doesn't own the physical 
monitor.  In that sense, gnome-screensaver and xscreensaver get it wrong 
I think.  How do HAL and power-manager handle the situation where more 
than one user is logged in to the console via gdmflexiserver?


We also need to turn off screensaver themes when the system is running 
on battery power.


> 2. How does this integrate with fast-user switching?

I have a copy of the fast-user-switch-applet code in gnome-screensaver. 
 Currently, it isn't being used up to it's potential.  It could be used 
to create a list of current users right in the unlock dialog.


At the moment, if you don't have the fast-user-switch-applet on your 
panel then gnome-screensaver's user switching isn't very useful.  There 
shouldn't be any "dead-ends".


There is a lot to discuss :)

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: xscreensaver, any plan do drop it !!

[William Jon McCann]

Jeff Waugh wrote:

Well, that we can definitely help with. :-) Is there a recent tarball
release? Do you want me to upload a release to ftp.gnome.org for you?
Would you consider proposing it for 2.12?


Just made one the other day actually.  :)
http://mail.gnome.org/archives/ftp-release-list/2005-July/msg00015.html

What results from widespread testing is such a big unknown that I really 
can't say at this point if it is ready for 2.12.


These will help:
http://bugzilla.gnome.org/show_bug.cgi?id=302344

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: xscreensaver, any plan do drop it !!

[William Jon McCann]

Hi Jeff,

Jeff Waugh wrote:

So, do you think there are any issues remaining with gnome-screensaver
before it can start being pushed towards inclusion in the Desktop release
(and thus, inclusion in distributions)? What do you think of using a common
user interface between GDM and the lock dialogue?


Lack of testing and feedback are the biggest problems right now.  They 
will inevitably reveal new problems.  Lack of support for assistive 
technologies is a potential problem, though not a regression from 
xscreensaver.


Since the dialog is running in a separate process one has quite a bit of 
flexibility.  I think you could write a Qt dialog if you wanted to. 
Other than that I haven't had a chance to give it much thought.


Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: xscreensaver, any plan do drop it !!

[William Jon McCann]

Hello John,

John (J5) Palmieri wrote:

Some people had some problems with it becoming a replacement.  Not sure
what they were and I haven't investigated it myself.


I encourage you and others to actually look at how I've been trying to 
design gnome-screensaver.  I am eager to receive specific feedback.


> Has it been vetted

yet for security issues?  The biggest problem with xscreensaver type
locking is that if xscreensaver crashes your session is unlocked.  This
is why the author didn't want to link against external libraries if it
could be avoided (and why we get ugly dialog).  Replacing it with
something else doesn't really solve any problems other than making it
look better.  I think we need to get GDM to start doing the locking.
That way if it crashes the session exits.  If we do that then we can use
anything for a screensaver app.


I'll agree with you in principle that failing closed is better than 
failing open.  However, failing closed with data-loss and disruption not 
an ideal solution (except for security experts and TSA employees).  Talk 
to angry users who have been logged out and lost work.  Of course, this 
argument applies equally to xscreensaver and gnome-screensaver.


It is not true that using a toolkit for the lock dialog requires linking 
to toolkit libraries.  I think I've solved this problem adequately by 
running the authentication checking and lock dialog code in a separate 
process that is embedded in the window using XEMBED.  I decided to use 
GtkSocket for this, on the daemon side.  It should be possible to do 
exactly the same thing using only Xlib.  I have chosen not to duplicate 
code and also acknowledge that most likely I could not do it better than 
GTK+ does.  Obviously, a trade-off.


Using a separate process for the input processing, authentication, and 
non-trivial widgetry is a big win in terms of security.


Replacing the input dialog is only one of the many goals of 
gnome-screensaver and not one of the most important ones.  It is more 
important that gnome-screensaver allows a system administrator to set 
mandatory policy for screensaver themes and locking.  It is difficult to 
talk about system security when any any user can disable the screensaver 
altogether or use a theme that displays porn and the system 
administrator can't do anything about it.  On the other hand, some 
systems require that the screen never be locked.  Setting this kind of 
policy is impossible to do with xscreensaver.


Currently, gnome-screensaver uses GConf for settings and policy.  At the 
moment this requires it to link to the GConf libraries.  The use of 
GConf is an implementation detail to gnome-screensaver.  It is hidden 
within the GSPrefs object.  I think it should be possible to use some 
kind of proxy object via DBus to get these settings and changes.  I am 
not familiar enough with DBus to know how one can up a trust 
relationship between two objects.  Since it is important that the 
settings come unaltered from GConf I have decided (for now) to link 
directly to the GConf libraries.


gnome-screensaver is about a lot more than "making it look better." 
Let's try to move the conversation past that point.


I've tried to put some information in the Wiki:
http://live.gnome.org/GnomeScreensaver

I'll be happy to try to answer any specific questions and criticism.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: Three Point Zero - Idea Mockups

[William Jon McCann]

Hi Nat,

I am very glad to hear about this.  The video sounds really interesting. 
 Perhaps we should start compiling all the usability study data on the 
web site someplace.


Nat Friedman wrote:

For example, we asked a lady to send mail to a friend.  Against all
odds, she started Evolution (nothing in the menus indicates that it's a
mail program; something we hadn't realized before but which was
immediately obvious after watching her stalk one-by-one through the menu
items muttering to herself along the way).  


http://lists.ximian.com/pipermail/evolution-patches/2004-April/005011.html
http://lists.ximian.com/pipermail/evolution-hackers/2004-July/004079.html


This is easy to fix; we just need to change the labels to be more
sensible (and then test again on 5-6 people to make sure we changed them
appropriately).  It was interesting to watch this video and instantly
realize that the "Send / Receive" button is all about *how Evolution
works* and not about *what the user wants to do*.  I've been staring at
that button for five years, and never realized it was wrong until I saw
that video.


http://lists.ximian.com/archives/public/evolution-hackers/2004-December/004876.html


Anna Dirks will be airing much of this video at GUADEC on Monday, before
Lunch, and we will also be publishing a lot of it online as soon as we
get all the participants to finish signing release waivers.  We're also
thinking about providing funding for more of these usability labs so
that other people can do this testing themselves.  The video talk will
be followed by a hackfest, so people who want to work on improving the
desktop we have, instead of engaging in an open-ended "GNOME 3"
discussion, have a place to go.


Can you put a document on the web site that describes how to create such 
a usability lab and guidelines for its effective use?



My point is just that there's plenty of cool and productive work for us
to do that doesn't involve rethinking everything, breaking ABI, or doing
something totally and fundamentally original in computing.  We are
already doing something totally and fundamentally original in computer
software -- we're building a completely free desktop environment upon
which anyone can try out their craziest ideas, and we're trying to make
it useful and exciting to regular people.  


Word.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-screensaver in CVS

[William Jon McCann]

Hi Mike,
Mike Hearn wrote:
Will there be a random screensaver mode? I quite liked that feature of
the current xscreensaver.
It is an interesting problem.  The daemon supports it.  You can turn it 
on via gconf for now.  However, I'm not really convinced it is necessary 
to expose this in the capplet.  I think the option really says more 
about the quality of most screensaver themes than it does to solve any 
real world problems.  We have all become used to it being there.

Here's another way I've thought about it.  As far as I know, we don't 
offer an option to randomize the desktop backgrounds while we are 
sitting at the screen.  So, why do we care if the screensaver theme 
cycles randomly while we aren't?

I'm not set against it.  I would just like to have a good reason for it.
Also, including the option implies that the screensaver theme list 
should be long.  Which may not be a good thing.

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

Re: gnome-screensaver in CVS

[William Jon McCann]

Hi Luis,
Luis Villa wrote:
On 4/23/05, William Jon McCann <[EMAIL PROTECTED]> wrote: 
   * include a version/equivalent of flurry screensaver
   * include a version/equivalent of glslideshow screensaver 
Are you not just wrapping the xscreensaver hacks? I thought that was
what KDE had done?
"Hacks" from recent xscreensaver versions should work fine in 
gnome-screensaver.  For now, you will have to use gconf directly to 
select them.  There are many reasons for this.  I will just include a 
few reasonable ones.  For now, the only one is a rewritten Popsquares 
that matches the user's theme colors.

I would very much like to avoid a noisy discussion about which hacks are 
best.  ;)

Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list

gnome-screensaver in CVS

[William Jon McCann]

Hi,
gnome-screensaver is now being maintained in GNOME CVS.
There is a preferences tool included:


To do:
* include a version/equivalent of flurry screensaver
* include a version/equivalent of glslideshow screensaver
* a11y
* support xscreensaver xml config
Please give it a try and file bugs in bugzilla.

Thanks,
Jon
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list