[Kde-accessibility] Full Screen Magnification
Charles Ross
ctsgroup at shentel.net
Sun Apr 12 02:30:07 CEST 2009
Shall screen magnifiers offer the option for full screen magnification along
with the lens options?
I for one prefer and need the full screen magnification with center
tracking..... It makes all the difference in the world.
----- Original Message -----
From: <kde-accessibility-request at kde.org>
To: <kde-accessibility at kde.org>
Sent: Thursday, April 09, 2009 4:30 PM
Subject: kde-accessibility Digest, Vol 66, Issue 1
> Send kde-accessibility mailing list submissions to
> kde-accessibility at kde.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.kde.org/mailman/listinfo/kde-accessibility
> or, via email, send a message with subject or body 'help' to
> kde-accessibility-request at kde.org
>
> You can reach the person managing the list at
> kde-accessibility-owner at kde.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of kde-accessibility digest..."
>
>
> Today's Topics:
>
> 1. Potential GUADEC/Akademy a11y BOF? (was Re: Planning for
> GNOME 3.0) (Willie Walker)
> 2. Re: Potential GUADEC/Akademy a11y BOF? (was Re: Planning for
> GNOME 3.0) (Brian Cameron)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 09 Apr 2009 13:06:52 -0400
> From: Willie Walker <William.Walker at Sun.COM>
> Subject: [Kde-accessibility] Potential GUADEC/Akademy a11y BOF? (was
> Re: Planning for GNOME 3.0)
> To: desktop-devel-list at gnome.org, gnome-accessibility-list at gnome.org,
> ojschmidt at kde.org, kde-accessibility at kde.org
> Message-ID: <49DE2B2C.70005 at sun.com>
> Content-Type: text/plain; format=flowed; charset=ISO-8859-1
>
> Hi All:
>
> Tomorrow (Friday) is the deadline for GUADEC/Akademy submissions. I'm
> curious if there would be interest in setting up a GUADEC BOF around
> accessibility? My personal goals would be to focus on three main areas:
>
> 1) Bonobo/CORBA deprecation, including AT-SPI/D-Bus, magnification, and
> speech
>
> 2) Alignment with KDE a11y
>
> 3) WebKit a11y
>
> I think we agree these are all important. But, I'm curious if people
> who will be attending GUADEC/Akademy would be willing to attend and
> participate in such a BOF and if we can get critical mass to make them
> worthwhile. In addition, if the response is overwhelming, should we
> consider making separate BOFs?
>
> Will
>
> Willie Walker wrote:
>> I'm really excited about GNOME 3.0. There are a lot of great ideas that
>> people have come up with.
>>
>> As people work on new GUI designs, I request that people engage the
>> GNOME accessibility team on their designs. Accessibility is a big
>> selling point for GNOME and I'd really hate to see it take a step back.
>>
>> Too often, GUI designers and developers forget about important details
>> such as keyboard access, theming, and support for the AT-SPI. It's a
>> lot easier to develop for accessibility from the beginning than to
>> retrofit later. Engaging earlier than later also helps us act more like
>> a team than adversaries.
>>
>> For developers local to the Boston area, I'm happy to take a visit to
>> your sight to go over accessibility considerations and to discuss your
>> new UI's with you from an accessibility standpoint. I promise to focus
>> solely on accessibility considerations and will avoid general armchair
>> HCI quarterbacking. For those outside the Boston area, we can try to
>> find someone to visit you for a face-to-face and/or we could do
>> conference calls with screenshots or just shared desktops via VNC.
>>
>> Thanks!
>>
>> Will
>> (your friendly GNOME a11y guy)
>>
>> On Apr 2, 2009, at 7:17 AM, Vincent Untz wrote:
>>
>>> During the first few months of 2008, a few Release Team members
>>> discussed here and there about the state of GNOME. This was nothing
>>> official, and it could actually have been considered as some friends
>>> talking together about things they deeply care about. There were
>>> thoughts that GNOME could stay with the 2.x branch for a very long time
>>> given our solid development methods, but that it was not the future that
>>> our community wants to see happening. Because of lack of excitement.
>>> Because of lack of vision. Slowly, a plan started to emerge. It evolved,
>>> changed, was trimmed a bit, made more solid. We started discussing with
>>> a few more people, got more feedback. And then, at GUADEC, the Release
>>> Team proposed an initial plan to the community that would lead the
>>> project to GNOME 3.0. Quite some time passed; actually, too much time
>>> passed because too many people were busy with other things. But it's
>>> never too late to do the right thing, so let's really be serious about
>>> GNOME 3.0 now!
>>>
>>> Let's first diverge a bit and discuss the general impression that GNOME
>>> is lacking a vision. If you look closely at our community, it'd be wrong
>>> to say that people are lacking a vision; but the project as a whole does
>>> indeed have this issue. What we are missing is people blessing one
>>> specific vision and making it official, giving goals to the community so
>>> we can all work together in the same direction. In the pre-2.x days, the
>>> community accepted as a whole one specific vision, and such an explicit
>>> blessing wasn't needed. But during the 2.x cycle, with our six months
>>> schedules, it appeared that everything (community, development process,
>>> etc.) was just working very well, and as the vision got more and more
>>> fulfilled, the long-term plans became less important as we focused on
>>> polishing our desktop. But we've now reached a point where our next
>>> steps should be moving to another level, and those next steps require
>>> important decisions. This is part of what the Release Team should do.
>>> Please note that Release Team members don't have to be the ones who have
>>> the vision; we "just" have to be the voice of the community.
>>>
>>> (As a sidenote, the roadmap process [1] that we tried to re-establish
>>> two years ago was a first attempt to fix this. Unfortunately, it turned
>>> out that we were missing the most important side of things: a
>>> project-wide roadmap. This is because a collection of individual
>>> roadmaps isn't enough to create a project-wide roadmap.)
>>>
>>> So let's go to the core topic and discuss what the GNOME 3.0 effort
>>> should be. We propose the following list of areas to focus our efforts
>>> on:
>>>
>>> - Revamp our User Experience
>>> - Streamlining of the Platform
>>> - Promotion of GNOME
>>>
>>> There are also other potential areas that are worth exploring if there
>>> is enough interest from the community.
>>>
>>> From a release management perspective, there are various questions that
>>> are raised in the GNOME 3.0 context. We definitely need a plan to
>>> organize the development (see below for details on it), but we might
>>> also want to take this opportunity to rethink how we ship GNOME: are the
>>> module sets still the best way to deliver GNOME? There is no obvious
>>> answer to this, but the way we will present GNOME in the future will
>>> certainly have an impact on this.
>>>
>>>
>>> Revamp our User Experience
>>> ============================
>>>
>>> When talking with some great people at GUADEC about GNOME 3.0, one
>>> concern that came more than once was that it would be an error to do
>>> GNOME 3.0 without any big user-visible change. While some of us didn't
>>> necessarily agree with this concern, it was still a fairly valid one.
>>> But it turns out that if you tell the community that there's something
>>> after 2.x, then the community will stop vaguely thinking about future
>>> ideas and start working on concrete plans.
>>>
>>> It seems pretty clear now that there are two important ideas that can
>>> have a real positive impact on the user experience:
>>>
>>> - GNOME Shell [2]: the shell idea is not just about changing the panel
>>> and the window manager. It's about changing the way you start an
>>> activity and how you switch between two different activities. Or more
>>> generally, how you manage your different activities on the desktop.
>>>
>>> - Changing the way we access documents (via a journal, like GNOME
>>> Zeitgeist [3]): having to deal with a filesystem in their daily work
>>> is not what makes users happy -- on the contrary, they generally just
>>> want to access their documents and not to browse their hard disk.
>>> Providing new solutions to this problem (using timelines, tags,
>>> bookmarks, etc.) is something that has been of interest in our
>>> community for a long time, but we never completely jumped in. We
>>> simply should.
>>>
>>> These two ideas can form the basis of an overhauled GNOME user
>>> experience; they are not the only changes that we can and will do, but
>>> they definitely are the most advanced projects to help us move forward
>>> in terms of user experience. The GNOME Shell and the GNOME Zeitgeist
>>> projects are indeed already well underway, with working code and strong
>>> development going on for nearly six months. This means the effort is not
>>> about starting those projects, but about first completing them so that
>>> people can work daily with them, and then polishing them.
>>>
>>> There's one obvious question related to those potential changes: what
>>> will happen to the old way of doing things? For example, will we still
>>> make the GNOME Panel available if, for some reason, people are not
>>> immediately happy with GNOME Shell? There's no obvious answer to this,
>>> and this will have to be discussed. Some of us believe that it would be
>>> a good thing to keep providing the old elements for a limited time, to
>>> ease the migration. That being said, doing that would obviously take
>>> some development resources and slow down work on what should be the
>>> future. Not an easy choice, of course. However, it's worth noting that
>>> distributors and other community members using GNOME to build enterprise
>>> products will most certainly help maintain the GNOME 2.x shell for quite
>>> some time, and the project will support that to the greatest reasonable
>>> extent.
>>>
>>>
>>> Streamlining of the Platform
>>> ============================
>>>
>>> Since GNOME 2.0 was released in 2002, there have been quite some changes
>>> in our developer platform: new APIs have landed and some other APIs have
>>> been deprecated. There are even some platform libraries that are now
>>> nearly unused. This just creates some confusion and does not make the
>>> life of developers easy. Since we want applications to be developed for
>>> GNOME, this is an issue that we should fix.
>>>
>>> Hence, it makes perfect sense to rework our platform and try to clarify
>>> it for newcomers. Here are some steps that should be considered:
>>>
>>> - move all of the deprecated libraries out of the platform, so people
>>> stop using them in new code;
>>>
>>> - create a staging area in the platform for libraries that aim to be in
>>> our platform but do not offer enough guarantees at the moment (like
>>> GStreamer): this will send a clear message on what should be used;
>>>
>>> - include new exciting technologies that we're starting to see used in
>>> our desktop. Some obvious examples are 3D effects (with Clutter) and
>>> geolocalization (with GeoClue and libchamplain).
>>>
>>> - rework the way we present the platform to also integrate some of the
>>> external dependencies: while, say, D-Bus or Avahi are external
>>> dependencies, they are definitely what we want developers to use. And
>>> it's easy to be more explicit about this.
>>>
>>> - move the bindings closer to the platform when we talk about bindings,
>>> to make them even more visible and attract developers from all
>>> languages.
>>>
>>> The work that has been done on GObject introspection [4] will also
>>> deeply change the way GNOME development can be done; we've already
>>> started to see how it can be leveraged in GNOME Shell, and the fact that
>>> it can bring new popular languages like Javascript to GNOME is a huge
>>> benefit.
>>>
>>> All this has of course an impact on our applications: we will have to
>>> port the code away from all deprecated APIs, but also prepare our
>>> applications to be ready for forthcoming changes, like GTK+ 3.0. This is
>>> luckily a task that we can easily quantify and the progress can be
>>> tracked on a simple web page.
>>>
>>>
>>> Promotion of GNOME
>>> ==================
>>>
>>> Our community has historically been strong on the development side, but
>>> we have always struggled to promote GNOME. That's because this is
>>> certainly no easy task. Our user base has however grown significantly
>>> since our project started, and we failed to recruit people that could
>>> have helped here. GNOME 3.0 is an opportunity to change this and attract
>>> contributors that can help forge the communication around the GNOME
>>> project. The promotion of the project is definitely part of what makes a
>>> good release, and the Marketing Team can contribute a lot to the success
>>> of 3.0.
>>>
>>> Of course, an obvious goal for the promotion of GNOME in this context
>>> would be preparing the 3.0 release and the messaging around this
>>> release. After highlighting the changes done specifically for 3.0, one
>>> other immediate idea is to simply show the progress the GNOME project
>>> has made since GNOME 2.0: GNOME 2.10 could arguably have been named 3.0
>>> when compared to 2.0, and the same goes for 2.20. This could serve as a
>>> basis for work on explaining why our evolutionary approach in
>>> development works well.
>>>
>>> One common issue that often came up when discussing how to promote GNOME
>>> was that promoting the desktop as a whole is difficult. But there's no
>>> need to do that. We can instead focus our messaging around the GNOME
>>> experience: the basic GNOME experience simply is the GNOME Shell; but
>>> users actually do not use just the basic desktop, and they use
>>> applications. We've never explained why the applications developed for
>>> GNOME are good; we've never really put those applications under the
>>> spotlight. For instance, why shouldn't we put on the front page of the
>>> GNOME website a clearly labeled message about a good music manager? We
>>> wouldn't have to choose between Rhythmbox or Banshee: we can promote
>>> both, since both are good in different ways, and both are good examples
>>> of the GNOME experience.
>>>
>>> This leads us to a third item: relaunch our website. While our current
>>> website is known for being broken in various different ways from a
>>> communication point of view, we've not been able to deliver the new
>>> version that would fix things. Fixing the website is a large task, but
>>> we should not give up on this: the GNOME website is a core part of the
>>> GNOME identity, and we cannot ignore the current issues. This happened
>>> because of lack of manpower, but the good news is that there are web
>>> developers that are fond of GNOME and just don't know they can help the
>>> project.
>>>
>>> And the fact that web developers can play an important role is also
>>> valid for all of our users. As of now, we are not really empowering
>>> users to promote GNOME: what should a user do if he wanted to do so? We
>>> all know how some viral communication can benefit a project like ours,
>>> so the solution is simple: let's give ourselves a chance to make this
>>> happen!
>>>
>>>
>>> Other Potential Areas
>>> =====================
>>>
>>> The areas presented above are actually not a big surprise to anybody
>>> following the GNOME development and are fairly obvious choices. However
>>> there are other candidates that would help make GNOME 3.0 a success.
>>> Those potential focus areas simply need people to step up so we can be
>>> sure expectations can be met.
>>>
>>> - Desktop Testing [5]: with the recent creation of the Desktop Testing
>>> Team, this topic becomes more and more visible. We can innovate
>>> there, and we actually should: we helped show the way in the free
>>> software world when it comes to usability and accessibility, and
>>> there is no reason for us not aiming at a similar experience for
>>> desktop testing.
>>>
>>> - Art: a GTK+ Theming API hackfest was held in February, where some
>>> good consensus was reached on how theming should be done in the
>>> future. This gives us a new opportunity for an updated look and feel.
>>> This can happen with the help from artists: if we have artists and
>>> coders working together, with the coders knowing the needs from
>>> artists, then there is no doubt that the result will simply rock.
>>>
>>> - People: the telepathy framework has nicely progressed over the last
>>> few years and it's offering great perspectives to integrate instant
>>> messaging, and more generally, interaction with people in other
>>> applications. With some focus, it could contribute to make GNOME a
>>> social desktop where you do not only work on documents, but where you
>>> also really interact with your friends.
>>>
>>> - Mobile: the GNOME Mobile platform was first introduced in GNOME 2.24,
>>> and it helped make our presence in the mobile world visible. A lot of
>>> the changes that are planned around the platform are of direct
>>> interest to the Mobile Team.
>>>
>>>
>>> Organizing the Development
>>> ==========================
>>>
>>> We need to define a clear timeline for the development, with a schedule
>>> that will let us check that the development is on the right path. The
>>> end goal is simple: we want to deliver GNOME 3.0 by the time of 2.30
>>> release. This makes sense for various reasons: from a technical
>>> perspective, the timing is good for the integration of new technologies
>>> or projects (GNOME Shell, for example); from a messaging point of view,
>>> the evolution from 2.30 to 3.0 is logical and easy to understand. It's
>>> worth pointing out that if you compare GNOME 2.26 with GNOME 2.0, it's
>>> actually quite surprising to see that we have still kept a 2.x version
>>> numbering while we could be at 3.x, or even 4.x. Making GNOME 2.30 a 3.0
>>> version is of course still an ambitious goal, but we can achieve it
>>> thanks to what we learnt in the past.
>>>
>>> The development methods we have adopted during GNOME 2.x are overall
>>> good methods and the community has become used to them. For example,
>>> contributors understand the reasons behind the freezes we have and try
>>> their best to respect those freezes. This is not something that should
>>> be changed because we now have an opportunity to try something else; on
>>> the contrary, those methods will make our path to 3.0 easier. Some
>>> regressions were pointed out during the past few cycles: those should
>>> not be ignored and we believe part of the reasons why they happened is
>>> that only a subpart of our community was trying to move forward, which
>>> created some controversy; having a community-wide focus should limit
>>> those controversies, and hence the regressions as felt by the community.
>>>
>>> The six months cycle is now part of our culture and has an impact on the
>>> free software ecosystem, with distributions basing their schedule on our
>>> schedule. Trying to change this crucial element of our release
>>> management, which works quite well, would certainly not help us in any
>>> way. Therefore, we will keep six months-based schedules. But having
>>> project-wide and long-term goals require some adaptation. GNOME 2.28
>>> will not be an independent release or a destination in itself, but it
>>> will be a logical step towards GNOME 2.30, and therefore GNOME 3.0.
>>>
>>> Of course, we should be prepared to consider the fact that GNOME 2.30
>>> might not be good enough for us to call it 3.0. All of our time-based
>>> releases are also quality-based releases: if the QA Team feels a release
>>> should be delayed, then it will be delayed. In the context of 3.0, this
>>> is something that we should be ready to diagnose early on during the
>>> 2.29 development cycle and we should not be afraid of keeping GNOME 2.30
>>> as 2.30 and waiting for GNOME 2.32 for the 3.0 release, for example.
>>> That being said, we want the community to try as hard as possible to
>>> make "GNOME 2.30 = GNOME 3.0" a success.
>>>
>>> On a more general note, overlaying a long-term development cycle (3
>>> years for example) with project-wide goals, on top of our six months
>>> development schedules is something we want to keep after GNOME 3.0.
>>>
>>>
>>> Conclusion
>>> ==========
>>>
>>> You can already check out the schedule for the 2.27 and 2.29 development
>>> cycles [6]: it contains some concrete steps and deadlines that will help
>>> keep our work focused to make GNOME 3.0 a reality.
>>>
>>> As already mentioned, this is an ambitious plan and it will only be
>>> realized if everybody comes out and helps. Companies can contribute a
>>> lot -- for instance, the GNOME Shell effort is doing great thanks to Red
>>> Hat's involvement. But GNOME wouldn't even exist without all of the
>>> volunteers who are passionate about the project. It's because this
>>> passion is so strong that we can build such a plan!
>>>
>>> We're getting there. We strongly believe that all this can make a good
>>> plan for GNOME. Sure, it's not perfect. And there will be disagreements
>>> and issues along the road. But it is the way forward.
>>>
>>>
>>> The GNOME Release Team,
>>>
>>>
>>> [1] http://live.gnome.org/RoadMap/Process
>>> [2] http://live.gnome.org/GnomeShell
>>> [3] http://live.gnome.org/GnomeZeitgeist
>>> [4] http://live.gnome.org/GObjectIntrospection
>>> [5] http://live.gnome.org/DesktopTesting
>>> [6] http://live.gnome.org/TwoPointTwentyseven
>>>
>>> --
>>> Les gens heureux ne sont pas press?s.
>>> _______________________________________________
>>> desktop-devel-list mailing list
>>> desktop-devel-list at gnome.org
>>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>> _______________________________________________
>> desktop-devel-list mailing list
>> desktop-devel-list at gnome.org
>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 09 Apr 2009 15:29:04 -0500
> From: Brian Cameron <Brian.Cameron at Sun.COM>
> Subject: Re: [Kde-accessibility] Potential GUADEC/Akademy a11y BOF?
> (was Re: Planning for GNOME 3.0)
> To: Willie Walker <William.Walker at Sun.COM>
> Cc: kde-accessibility at kde.org, ojschmidt at kde.org,
> gnome-accessibility-list at gnome.org, desktop-devel-list at gnome.org
> Message-ID: <49DE5A90.1000602 at sun.com>
> Content-Type: text/plain; format=flowed; charset=ISO-8859-1
>
>
> Willie:
>
> I would be interested to attend such a BoF. I think that all three
> topics you mention are important. Perhaps another agenda item to
> discuss how GNOME 3.0 will impact a11y would also be appropriate.
> I think the Bonobo/CORBA deprecation falls into this category, but
> I think there are other issues. How, for example, will clutter-based
> metacity and gnome-shell work with a11y?
>
> Brian
>
>
>> Tomorrow (Friday) is the deadline for GUADEC/Akademy submissions. I'm
>> curious if there would be interest in setting up a GUADEC BOF around
>> accessibility? My personal goals would be to focus on three main areas:
>>
>> 1) Bonobo/CORBA deprecation, including AT-SPI/D-Bus, magnification, and
>> speech
>>
>> 2) Alignment with KDE a11y
>>
>> 3) WebKit a11y
>>
>> I think we agree these are all important. But, I'm curious if people
>> who will be attending GUADEC/Akademy would be willing to attend and
>> participate in such a BOF and if we can get critical mass to make them
>> worthwhile. In addition, if the response is overwhelming, should we
>> consider making separate BOFs?
>>
>> Will
>>
>> Willie Walker wrote:
>>> I'm really excited about GNOME 3.0. There are a lot of great ideas that
>>> people have come up with.
>>>
>>> As people work on new GUI designs, I request that people engage the
>>> GNOME accessibility team on their designs. Accessibility is a big
>>> selling point for GNOME and I'd really hate to see it take a step back.
>>>
>>> Too often, GUI designers and developers forget about important details
>>> such as keyboard access, theming, and support for the AT-SPI. It's a
>>> lot easier to develop for accessibility from the beginning than to
>>> retrofit later. Engaging earlier than later also helps us act more like
>>> a team than adversaries.
>>>
>>> For developers local to the Boston area, I'm happy to take a visit to
>>> your sight to go over accessibility considerations and to discuss your
>>> new UI's with you from an accessibility standpoint. I promise to focus
>>> solely on accessibility considerations and will avoid general armchair
>>> HCI quarterbacking. For those outside the Boston area, we can try to
>>> find someone to visit you for a face-to-face and/or we could do
>>> conference calls with screenshots or just shared desktops via VNC.
>>>
>>> Thanks!
>>>
>>> Will
>>> (your friendly GNOME a11y guy)
>>>
>>> On Apr 2, 2009, at 7:17 AM, Vincent Untz wrote:
>>>
>>>> During the first few months of 2008, a few Release Team members
>>>> discussed here and there about the state of GNOME. This was nothing
>>>> official, and it could actually have been considered as some friends
>>>> talking together about things they deeply care about. There were
>>>> thoughts that GNOME could stay with the 2.x branch for a very long time
>>>> given our solid development methods, but that it was not the future
>>>> that
>>>> our community wants to see happening. Because of lack of excitement.
>>>> Because of lack of vision. Slowly, a plan started to emerge. It
>>>> evolved,
>>>> changed, was trimmed a bit, made more solid. We started discussing with
>>>> a few more people, got more feedback. And then, at GUADEC, the Release
>>>> Team proposed an initial plan to the community that would lead the
>>>> project to GNOME 3.0. Quite some time passed; actually, too much time
>>>> passed because too many people were busy with other things. But it's
>>>> never too late to do the right thing, so let's really be serious about
>>>> GNOME 3.0 now!
>>>>
>>>> Let's first diverge a bit and discuss the general impression that GNOME
>>>> is lacking a vision. If you look closely at our community, it'd be
>>>> wrong
>>>> to say that people are lacking a vision; but the project as a whole
>>>> does
>>>> indeed have this issue. What we are missing is people blessing one
>>>> specific vision and making it official, giving goals to the community
>>>> so
>>>> we can all work together in the same direction. In the pre-2.x days,
>>>> the
>>>> community accepted as a whole one specific vision, and such an explicit
>>>> blessing wasn't needed. But during the 2.x cycle, with our six months
>>>> schedules, it appeared that everything (community, development process,
>>>> etc.) was just working very well, and as the vision got more and more
>>>> fulfilled, the long-term plans became less important as we focused on
>>>> polishing our desktop. But we've now reached a point where our next
>>>> steps should be moving to another level, and those next steps require
>>>> important decisions. This is part of what the Release Team should do.
>>>> Please note that Release Team members don't have to be the ones who
>>>> have
>>>> the vision; we "just" have to be the voice of the community.
>>>>
>>>> (As a sidenote, the roadmap process [1] that we tried to re-establish
>>>> two years ago was a first attempt to fix this. Unfortunately, it turned
>>>> out that we were missing the most important side of things: a
>>>> project-wide roadmap. This is because a collection of individual
>>>> roadmaps isn't enough to create a project-wide roadmap.)
>>>>
>>>> So let's go to the core topic and discuss what the GNOME 3.0 effort
>>>> should be. We propose the following list of areas to focus our efforts
>>>> on:
>>>>
>>>> - Revamp our User Experience
>>>> - Streamlining of the Platform
>>>> - Promotion of GNOME
>>>>
>>>> There are also other potential areas that are worth exploring if there
>>>> is enough interest from the community.
>>>>
>>>> From a release management perspective, there are various questions
>>>> that
>>>> are raised in the GNOME 3.0 context. We definitely need a plan to
>>>> organize the development (see below for details on it), but we might
>>>> also want to take this opportunity to rethink how we ship GNOME: are
>>>> the
>>>> module sets still the best way to deliver GNOME? There is no obvious
>>>> answer to this, but the way we will present GNOME in the future will
>>>> certainly have an impact on this.
>>>>
>>>>
>>>> Revamp our User Experience
>>>> ============================
>>>>
>>>> When talking with some great people at GUADEC about GNOME 3.0, one
>>>> concern that came more than once was that it would be an error to do
>>>> GNOME 3.0 without any big user-visible change. While some of us didn't
>>>> necessarily agree with this concern, it was still a fairly valid one.
>>>> But it turns out that if you tell the community that there's something
>>>> after 2.x, then the community will stop vaguely thinking about future
>>>> ideas and start working on concrete plans.
>>>>
>>>> It seems pretty clear now that there are two important ideas that can
>>>> have a real positive impact on the user experience:
>>>>
>>>> - GNOME Shell [2]: the shell idea is not just about changing the
>>>> panel
>>>> and the window manager. It's about changing the way you start an
>>>> activity and how you switch between two different activities. Or
>>>> more
>>>> generally, how you manage your different activities on the desktop.
>>>>
>>>> - Changing the way we access documents (via a journal, like GNOME
>>>> Zeitgeist [3]): having to deal with a filesystem in their daily
>>>> work
>>>> is not what makes users happy -- on the contrary, they generally
>>>> just
>>>> want to access their documents and not to browse their hard disk.
>>>> Providing new solutions to this problem (using timelines, tags,
>>>> bookmarks, etc.) is something that has been of interest in our
>>>> community for a long time, but we never completely jumped in. We
>>>> simply should.
>>>>
>>>> These two ideas can form the basis of an overhauled GNOME user
>>>> experience; they are not the only changes that we can and will do, but
>>>> they definitely are the most advanced projects to help us move forward
>>>> in terms of user experience. The GNOME Shell and the GNOME Zeitgeist
>>>> projects are indeed already well underway, with working code and strong
>>>> development going on for nearly six months. This means the effort is
>>>> not
>>>> about starting those projects, but about first completing them so that
>>>> people can work daily with them, and then polishing them.
>>>>
>>>> There's one obvious question related to those potential changes: what
>>>> will happen to the old way of doing things? For example, will we still
>>>> make the GNOME Panel available if, for some reason, people are not
>>>> immediately happy with GNOME Shell? There's no obvious answer to this,
>>>> and this will have to be discussed. Some of us believe that it would be
>>>> a good thing to keep providing the old elements for a limited time, to
>>>> ease the migration. That being said, doing that would obviously take
>>>> some development resources and slow down work on what should be the
>>>> future. Not an easy choice, of course. However, it's worth noting that
>>>> distributors and other community members using GNOME to build
>>>> enterprise
>>>> products will most certainly help maintain the GNOME 2.x shell for
>>>> quite
>>>> some time, and the project will support that to the greatest reasonable
>>>> extent.
>>>>
>>>>
>>>> Streamlining of the Platform
>>>> ============================
>>>>
>>>> Since GNOME 2.0 was released in 2002, there have been quite some
>>>> changes
>>>> in our developer platform: new APIs have landed and some other APIs
>>>> have
>>>> been deprecated. There are even some platform libraries that are now
>>>> nearly unused. This just creates some confusion and does not make the
>>>> life of developers easy. Since we want applications to be developed for
>>>> GNOME, this is an issue that we should fix.
>>>>
>>>> Hence, it makes perfect sense to rework our platform and try to clarify
>>>> it for newcomers. Here are some steps that should be considered:
>>>>
>>>> - move all of the deprecated libraries out of the platform, so people
>>>> stop using them in new code;
>>>>
>>>> - create a staging area in the platform for libraries that aim to be
>>>> in
>>>> our platform but do not offer enough guarantees at the moment (like
>>>> GStreamer): this will send a clear message on what should be used;
>>>>
>>>> - include new exciting technologies that we're starting to see used
>>>> in
>>>> our desktop. Some obvious examples are 3D effects (with Clutter)
>>>> and
>>>> geolocalization (with GeoClue and libchamplain).
>>>>
>>>> - rework the way we present the platform to also integrate some of
>>>> the
>>>> external dependencies: while, say, D-Bus or Avahi are external
>>>> dependencies, they are definitely what we want developers to use.
>>>> And
>>>> it's easy to be more explicit about this.
>>>>
>>>> - move the bindings closer to the platform when we talk about
>>>> bindings,
>>>> to make them even more visible and attract developers from all
>>>> languages.
>>>>
>>>> The work that has been done on GObject introspection [4] will also
>>>> deeply change the way GNOME development can be done; we've already
>>>> started to see how it can be leveraged in GNOME Shell, and the fact
>>>> that
>>>> it can bring new popular languages like Javascript to GNOME is a huge
>>>> benefit.
>>>>
>>>> All this has of course an impact on our applications: we will have to
>>>> port the code away from all deprecated APIs, but also prepare our
>>>> applications to be ready for forthcoming changes, like GTK+ 3.0. This
>>>> is
>>>> luckily a task that we can easily quantify and the progress can be
>>>> tracked on a simple web page.
>>>>
>>>>
>>>> Promotion of GNOME
>>>> ==================
>>>>
>>>> Our community has historically been strong on the development side, but
>>>> we have always struggled to promote GNOME. That's because this is
>>>> certainly no easy task. Our user base has however grown significantly
>>>> since our project started, and we failed to recruit people that could
>>>> have helped here. GNOME 3.0 is an opportunity to change this and
>>>> attract
>>>> contributors that can help forge the communication around the GNOME
>>>> project. The promotion of the project is definitely part of what makes
>>>> a
>>>> good release, and the Marketing Team can contribute a lot to the
>>>> success
>>>> of 3.0.
>>>>
>>>> Of course, an obvious goal for the promotion of GNOME in this context
>>>> would be preparing the 3.0 release and the messaging around this
>>>> release. After highlighting the changes done specifically for 3.0, one
>>>> other immediate idea is to simply show the progress the GNOME project
>>>> has made since GNOME 2.0: GNOME 2.10 could arguably have been named 3.0
>>>> when compared to 2.0, and the same goes for 2.20. This could serve as a
>>>> basis for work on explaining why our evolutionary approach in
>>>> development works well.
>>>>
>>>> One common issue that often came up when discussing how to promote
>>>> GNOME
>>>> was that promoting the desktop as a whole is difficult. But there's no
>>>> need to do that. We can instead focus our messaging around the GNOME
>>>> experience: the basic GNOME experience simply is the GNOME Shell; but
>>>> users actually do not use just the basic desktop, and they use
>>>> applications. We've never explained why the applications developed for
>>>> GNOME are good; we've never really put those applications under the
>>>> spotlight. For instance, why shouldn't we put on the front page of the
>>>> GNOME website a clearly labeled message about a good music manager? We
>>>> wouldn't have to choose between Rhythmbox or Banshee: we can promote
>>>> both, since both are good in different ways, and both are good examples
>>>> of the GNOME experience.
>>>>
>>>> This leads us to a third item: relaunch our website. While our current
>>>> website is known for being broken in various different ways from a
>>>> communication point of view, we've not been able to deliver the new
>>>> version that would fix things. Fixing the website is a large task, but
>>>> we should not give up on this: the GNOME website is a core part of the
>>>> GNOME identity, and we cannot ignore the current issues. This happened
>>>> because of lack of manpower, but the good news is that there are web
>>>> developers that are fond of GNOME and just don't know they can help the
>>>> project.
>>>>
>>>> And the fact that web developers can play an important role is also
>>>> valid for all of our users. As of now, we are not really empowering
>>>> users to promote GNOME: what should a user do if he wanted to do so? We
>>>> all know how some viral communication can benefit a project like ours,
>>>> so the solution is simple: let's give ourselves a chance to make this
>>>> happen!
>>>>
>>>>
>>>> Other Potential Areas
>>>> =====================
>>>>
>>>> The areas presented above are actually not a big surprise to anybody
>>>> following the GNOME development and are fairly obvious choices. However
>>>> there are other candidates that would help make GNOME 3.0 a success.
>>>> Those potential focus areas simply need people to step up so we can be
>>>> sure expectations can be met.
>>>>
>>>> - Desktop Testing [5]: with the recent creation of the Desktop
>>>> Testing
>>>> Team, this topic becomes more and more visible. We can innovate
>>>> there, and we actually should: we helped show the way in the free
>>>> software world when it comes to usability and accessibility, and
>>>> there is no reason for us not aiming at a similar experience for
>>>> desktop testing.
>>>>
>>>> - Art: a GTK+ Theming API hackfest was held in February, where some
>>>> good consensus was reached on how theming should be done in the
>>>> future. This gives us a new opportunity for an updated look and
>>>> feel.
>>>> This can happen with the help from artists: if we have artists and
>>>> coders working together, with the coders knowing the needs from
>>>> artists, then there is no doubt that the result will simply rock.
>>>>
>>>> - People: the telepathy framework has nicely progressed over the last
>>>> few years and it's offering great perspectives to integrate instant
>>>> messaging, and more generally, interaction with people in other
>>>> applications. With some focus, it could contribute to make GNOME a
>>>> social desktop where you do not only work on documents, but where
>>>> you
>>>> also really interact with your friends.
>>>>
>>>> - Mobile: the GNOME Mobile platform was first introduced in GNOME
>>>> 2.24,
>>>> and it helped make our presence in the mobile world visible. A lot
>>>> of
>>>> the changes that are planned around the platform are of direct
>>>> interest to the Mobile Team.
>>>>
>>>>
>>>> Organizing the Development
>>>> ==========================
>>>>
>>>> We need to define a clear timeline for the development, with a schedule
>>>> that will let us check that the development is on the right path. The
>>>> end goal is simple: we want to deliver GNOME 3.0 by the time of 2.30
>>>> release. This makes sense for various reasons: from a technical
>>>> perspective, the timing is good for the integration of new technologies
>>>> or projects (GNOME Shell, for example); from a messaging point of view,
>>>> the evolution from 2.30 to 3.0 is logical and easy to understand. It's
>>>> worth pointing out that if you compare GNOME 2.26 with GNOME 2.0, it's
>>>> actually quite surprising to see that we have still kept a 2.x version
>>>> numbering while we could be at 3.x, or even 4.x. Making GNOME 2.30 a
>>>> 3.0
>>>> version is of course still an ambitious goal, but we can achieve it
>>>> thanks to what we learnt in the past.
>>>>
>>>> The development methods we have adopted during GNOME 2.x are overall
>>>> good methods and the community has become used to them. For example,
>>>> contributors understand the reasons behind the freezes we have and try
>>>> their best to respect those freezes. This is not something that should
>>>> be changed because we now have an opportunity to try something else; on
>>>> the contrary, those methods will make our path to 3.0 easier. Some
>>>> regressions were pointed out during the past few cycles: those should
>>>> not be ignored and we believe part of the reasons why they happened is
>>>> that only a subpart of our community was trying to move forward, which
>>>> created some controversy; having a community-wide focus should limit
>>>> those controversies, and hence the regressions as felt by the
>>>> community.
>>>>
>>>> The six months cycle is now part of our culture and has an impact on
>>>> the
>>>> free software ecosystem, with distributions basing their schedule on
>>>> our
>>>> schedule. Trying to change this crucial element of our release
>>>> management, which works quite well, would certainly not help us in any
>>>> way. Therefore, we will keep six months-based schedules. But having
>>>> project-wide and long-term goals require some adaptation. GNOME 2.28
>>>> will not be an independent release or a destination in itself, but it
>>>> will be a logical step towards GNOME 2.30, and therefore GNOME 3.0.
>>>>
>>>> Of course, we should be prepared to consider the fact that GNOME 2.30
>>>> might not be good enough for us to call it 3.0. All of our time-based
>>>> releases are also quality-based releases: if the QA Team feels a
>>>> release
>>>> should be delayed, then it will be delayed. In the context of 3.0, this
>>>> is something that we should be ready to diagnose early on during the
>>>> 2.29 development cycle and we should not be afraid of keeping GNOME
>>>> 2.30
>>>> as 2.30 and waiting for GNOME 2.32 for the 3.0 release, for example.
>>>> That being said, we want the community to try as hard as possible to
>>>> make "GNOME 2.30 = GNOME 3.0" a success.
>>>>
>>>> On a more general note, overlaying a long-term development cycle (3
>>>> years for example) with project-wide goals, on top of our six months
>>>> development schedules is something we want to keep after GNOME 3.0.
>>>>
>>>>
>>>> Conclusion
>>>> ==========
>>>>
>>>> You can already check out the schedule for the 2.27 and 2.29
>>>> development
>>>> cycles [6]: it contains some concrete steps and deadlines that will
>>>> help
>>>> keep our work focused to make GNOME 3.0 a reality.
>>>>
>>>> As already mentioned, this is an ambitious plan and it will only be
>>>> realized if everybody comes out and helps. Companies can contribute a
>>>> lot -- for instance, the GNOME Shell effort is doing great thanks to
>>>> Red
>>>> Hat's involvement. But GNOME wouldn't even exist without all of the
>>>> volunteers who are passionate about the project. It's because this
>>>> passion is so strong that we can build such a plan!
>>>>
>>>> We're getting there. We strongly believe that all this can make a good
>>>> plan for GNOME. Sure, it's not perfect. And there will be disagreements
>>>> and issues along the road. But it is the way forward.
>>>>
>>>>
>>>> The GNOME Release Team,
>>>>
>>>>
>>>> [1] http://live.gnome.org/RoadMap/Process
>>>> [2] http://live.gnome.org/GnomeShell
>>>> [3] http://live.gnome.org/GnomeZeitgeist
>>>> [4] http://live.gnome.org/GObjectIntrospection
>>>> [5] http://live.gnome.org/DesktopTesting
>>>> [6] http://live.gnome.org/TwoPointTwentyseven
>>>>
>>>> --
>>>> Les gens heureux ne sont pas press?s.
>>>> _______________________________________________
>>>> desktop-devel-list mailing list
>>>> desktop-devel-list at gnome.org
>>>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>> _______________________________________________
>>> desktop-devel-list mailing list
>>> desktop-devel-list at gnome.org
>>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
>> _______________________________________________
>> kde-accessibility mailing list
>> kde-accessibility at kde.org
>> https://mail.kde.org/mailman/listinfo/kde-accessibility
>
>
>
> ------------------------------
>
> _______________________________________________
> kde-accessibility mailing list
> kde-accessibility at kde.org
> https://mail.kde.org/mailman/listinfo/kde-accessibility
>
>
> End of kde-accessibility Digest, Vol 66, Issue 1
> ************************************************
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
More information about the kde-accessibility
mailing list