Re: MouseTrap Proposal
El 1 de abril de 2010 00:09, Javier Jardón jjar...@gnome.org escribió:
2010/3/31 Flaper87 flape...@gmail.com:
Hi,
The only package (used by MouseTrap) depending on Orbit2 is libbonobo and
it
is used by at-spi. This wont be a problem (for MouseTrap) on the GNOME3
release/integration.
PyOrbit shouldn't be in the MouseTrap's dependencies list. I removed it.
Just wanted to clarify this point...
Thanks
Great to know ;),
at-spi will be removed for GNOME3, and substituted by pyatspi2 [1]
[1] http://live.gnome.org/Accessibility/GNOME3#pyatspi2_.28D-Bus.29
That's correct, and that's why MouseTrap will work perfectly on GNOME3
because it already works with at-spi2 and pyatspi2 =P
Cheers
--
Flavio Percoco Premoli, A.K.A. [Flaper87]
http://www.flaper87.org
Usuario Linux registrado #436538
Geek by nature, Linux by choice, Archer of course.
Key Fingerprint: CFC0 C67D FF73 463B 7E55 CF43 25D1 E75B E2DB 15C7
The Solution to everything:
python -c from struct import pack; print pack('5b', (41*len('99')),
pow(8,2)+20, 4900**0.5, range(78)[-1], 10)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME SWOT Analysis
On Thu, 2010-04-01 at 01:38 +0200, Juanjo Marin wrote: http://live.gnome.org/SWOT Very interesting and it appears to be thorough, but one things bugs me: Usable GNOME understands that usability is about creating software that is easy for everyone to use, not about piling on features. I think the term usable implies general fitness, that what is refereed to can be used to accomplish what it is meant for without nasty side-effects. It does not necessarily imply a level of quality beyond that. Instead you could write User-centered or User-friendly, perhaps. While there are varying definitions of usability, ease-of-use might be a factor among several, if it appears as such at all. The for everyone is problematic, but I know how hard it is to be more specific. A tight definition of usability could be: The combination of effectiveness, efficiency and user satisfaction of an interface, regarding a specific task, context and user(-group). Where effectiveness refers to the level of fitness for the purpose and efficiency refers to the amount of work or time required. It's a 3 level system: does it work at all, does it work well, is it satisfying? The last level puts some weight on rather emotional factors that can have an impact on performance. It is possible that a user is more satisfied with an interface that is actually less efficient. I guess vagueness in this area is another weakness. -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
On Wed, 2010-03-31 at 09:28 -0400, Willie Walker wrote: 2) In the Appearance section on the WIKI, there is mention of theming. Will this hook into the desktop appearance settings we have available in GNOME today? Remember that most of the Appearance section in the control-center will be going away for GNOME 3.0 (as discussed in the UX hackfest). What's left to figure out is how we can still make it easy to switch to accessible themes for icons and controls though. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME SWOT Analysis
2010/4/1 Thorsten Wilms t...@freenet.de
On Thu, 2010-04-01 at 01:38 +0200, Juanjo Marin wrote:
http://live.gnome.org/SWOT
Very interesting and it appears to be thorough, but one things bugs me:
Usable
GNOME understands that usability is about creating software that is easy
for everyone to use, not about piling on features.
I think the term usable implies general fitness, that what is refereed
to can be used to accomplish what it is meant for without nasty
side-effects. It does not necessarily imply a level of quality beyond
that.
Instead you could write User-centered or User-friendly, perhaps.
While there are varying definitions of usability, ease-of-use might be a
factor among several, if it appears as such at all.
The for everyone is problematic, but I know how hard it is to be more
specific.
A tight definition of usability could be:
The combination of effectiveness, efficiency and user satisfaction of an
interface, regarding a specific task, context and user(-group).
Where effectiveness refers to the level of fitness for the purpose and
efficiency refers to the amount of work or time required. It's a 3 level
system: does it work at all, does it work well, is it satisfying? The
last level puts some weight on rather emotional factors that can have an
impact on performance. It is possible that a user is more satisfied with
an interface that is actually less efficient.
I guess vagueness in this area is another weakness.
I agree with Thorsten Wilms comment about usability...
About Accessibility:
I think this link could be used[0], it has some links to other wiki pages
containing more information about GNOME-A11y.
I wonder if we should give a more detailed description about a11y there or
adding the GNOME Accessibility link is good enough...
About Supported:
Shouldn't Collabora be in the list
[0] http://live.gnome.org/Accessibility
Cheers
P.S: I'll read the page again later and see if I find anything else... (got
to work now =D)
--
Flavio Percoco Premoli, A.K.A. [Flaper87]
http://www.flaper87.org
Usuario Linux registrado #436538
Geek by nature, Linux by choice, Archer of course.
Key Fingerprint: CFC0 C67D FF73 463B 7E55 CF43 25D1 E75B E2DB 15C7
The Solution to everything:
python -c from struct import pack; print pack('5b', (41*len('99')),
pow(8,2)+20, 4900**0.5, range(78)[-1], 10)
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
bumping telepathy-glib's external dependencies for 2.32
Hi, I plan to use in Empathy new API from telepathy-glib so will have to dump the external dependency to 0.11. This will be needed for new features and factor out code from Empathy to tp-glib. Hope that's fine. G. -- Guillaume Desmottes gdesm...@gnome.org Jabber cass...@jabber.belnet.be GPG 1024D/711E31B1 | 1B5A 1BA8 11AA F0F1 2169 E28A AC55 8671 711E 31B1 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
On Thu, 2010-04-01 at 09:48 +0100, Bastien Nocera wrote: On Wed, 2010-03-31 at 09:28 -0400, Willie Walker wrote: 2) In the Appearance section on the WIKI, there is mention of theming. Will this hook into the desktop appearance settings we have available in GNOME today? Remember that most of the Appearance section in the control-center will be going away for GNOME 3.0 (as discussed in the UX hackfest). What's left to figure out is how we can still make it easy to switch to accessible themes for icons and controls though. Is there a writeup of the GNOME 3 appearance section somewhere? - Owen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
On Thu, 2010-04-01 at 08:09 -0400, Owen Taylor wrote: On Thu, 2010-04-01 at 09:48 +0100, Bastien Nocera wrote: On Wed, 2010-03-31 at 09:28 -0400, Willie Walker wrote: 2) In the Appearance section on the WIKI, there is mention of theming. Will this hook into the desktop appearance settings we have available in GNOME today? Remember that most of the Appearance section in the control-center will be going away for GNOME 3.0 (as discussed in the UX hackfest). What's left to figure out is how we can still make it easy to switch to accessible themes for icons and controls though. Is there a writeup of the GNOME 3 appearance section somewhere? Nope, I'm afraid not. 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. Cheers ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module proposal: Mutter
Pat Suwalski wrote: On 30/03/10 07:17 PM, Owen Taylor wrote: Mutter packages exist for most major Linux distributions as part of packaging GNOME Shell. Mutter is also key component of the Moblin 2.0 and 2.1 releases. With the uncertain future of Moblin, is this appropriate? Will Meego continue with Mutter? What is the relation of Meego going forward and GTK; is Meego going to turn into a large multi-toolkit monster? This might be valid concerns for MeeGo, but imho not for GNOME. Please also be aware that qt will be the reference UI for mobile device category. Don't extrapolate :) Stefan Not that my opinion matters, but I think these are all good questions. --Pat ___ 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
ANNOUNCE: tracker 0.8.0 released (stable)
tracker 0.8.0 is now available for download from: http://download.gnome.org/sources/tracker/0.8/ 8504763b9c408c971b9c3273e0c420c3 tracker-0.8.0.tar.gz This is the first stable release based on the 0.7.x series of releases What is it? === All-in-one indexer, search tool and metadata database. Where can I find out more? == You can visit the project web site: http://www.tracker-project.org/ What's New? === Improvements / New: General: * Added data/ontologies/Indicies.list for db index reasoning * Added full content data generator for testing * Fixed ALL license headers using Debian licensecheck.pl script Ontology: * Set tracker:indexed to true for nco:hasIMAccount * Set tracker:indexed to true for nco:hasEmailAddress * Set tracker:indexed to true for nco:hasPostalAddress * Updated documentation for nmo, explain conversations and email * Added diagram to explain email classes * Added upstream link for nmo (semanticdesktop.org) Functional Tests: * Added new test data * Added test cases to verify setting localPhoneNumber * Added test cases for boot up scenarios * Updated writeback test libtracker-client: * Create vapi files with $version in the name, was static 0.7 * Fixed vapi bindings, make Tracker.Client a Glib.Object subclass libtracker-miner: * Create vapi files with $version in the name, was static 0.7 * Don't install tracker-miner-dbus.h, it is internal * Prefixed internal APIs with _ to avoid exporting unwanted symbols * Make sure progress property is set to 0.0 initially * Make sure we have progress = 0.0 when crawling, using 1% for now * Disable monitor test case, requires unavailable internal symbols * Fixed memory leak when loading GKeyFile TrackerPasswordProviders libtracker-db: * Removed GValue abstraction for custom SQLite functions libtracker-data: * Added test cases for update error handling * Added test cases for ASK queries * Added test cases for 2nd 3rd and 4th predicate variables * Added test cases for subquery unions * Added test cases for restoring after journal replay * Refactored code for simpler subgraph contexts * Fixed literal binding in subqueries * Fixed variable binding with subqueries libtracker-fts: * Backport changes from FTS3 upstream. This fixes filtering with both, ID and MATCH constraints, which can happen when joining with unions tracker-store: * Added status notifications during journal replay * Removed mingw-compat.h, completely unused tracker-extract: * Don't use urn:author for nco:Contact as creator for JPEGs * Don't use urn:artist for nco:Contact, use urn:contact * Fixed OGG contact SPARQL generation, use preupdate * Fixed PNG contact SPARQL generation, use preupdate * Fixed TIF contact SPARQL generation, use preupdate * Cleaned up PNG, TIFF, JPEG and XMP source tracker-miner-fs: * Do not check tracker-store for ignored directories * Fixed potential crash when cancelling extraction tracker-miner-rss: * Removed unrequired g_free() tracker-control: * Improve output for --start so it is clearer tracker-status: * Added tracker-store journal replay status * Improve output so it is simpler tracker-search: * Sort results for documents, images, videos, files and folders Bugs: * GB#613819, Indexing Limitations section is confusing * GB#613977, many text mime types are not fully extracted * GB#614449, tracker-extract module directory should be environment configurable * NB#162585, tracker-extract is crashing for mp3s with id3v24 tags * NB#161457, nco:creator for JPEGs has multiple dummy contacts shown in CM * NB#162394, We need signals for nco:IMAddress * NB#162028, writeback not done for nie:contentCreated * GB#613792, tracker-miner-fs critical log messages for jpeg extraction Translations: * Updated lt: Aurimas Černius, Gintautas Miliauskas * Updated de: Mario Blättermann * Updated sl: Andrej Žnidaršič * Updated pl: Piotr Drąg * Updated es: Jorge González * Updated cs: Marek Černocký Notes: The database version up has been incremented, this will force a reindex for any existing Tracker installation. -- 1 April 2010 Tracker team ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
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. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: GNOME Shell
Hi, On Thu, Apr 1, 2010 at 1:24 PM, Diego Escalante Urrelo die...@gnome.org 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
