On Sun, 2014-08-24 at 11:29 -0500, Michael Catanzaro wrote:
I think we should add https://bugzilla.gnome.org/show_bug.cgi?id=734298
Google has recently imposed some new restriction, apparently.
I think the E-D-S CalDAV backend will need tweaked to work around it.
OPTIONS
it with
-DGTK_DISABLE_DEPRECATED. If it's disabled it won't build.
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
to be simple enough that Debarshi and I decided to backport
it for GNOME 3.10.1.
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
to easily tack mail support on to existing Windows Live
accounts in GOA.
If at some point Outlook.com does grow EWS + OAuth 2.0 support, E-D-S
could easily switch over. But as far as I know it does not currently
support either.
Matthew Barnes
could easily create alternative email clients or
calendars on top of e-d-s.
Here's the last known status on that:
https://mail.gnome.org/archives/evolution-hackers/2013-January/msg9.html
Matthew Barnes
___
desktop-devel-list mailing list
desktop
through Evolution
directly. That's not going away. GOA just streamlines the process.
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
for some old bug report or feature request to be moved
off UNCONFIRMED to NEW, as if that's gonna magically do something.
I'd like to see UNCONFIRMED removed but maybe as a compromise add a confirmed
Bugzilla keyword for projects to use or not use as they please.
Matthew Barnes
- Original
On Fri, 2011-10-07 at 10:21 -0400, Matthias Clasen wrote:
But GOA is not a 'generic account setup' dialog to allow all the
worlds apps to drop their own account setup dialogs. If that is what
you are looking for, you will be disappointed. It is the central place
to set up accounts that are
On Mon, 2011-05-02 at 09:14 -0400, David Zeuthen wrote:
Right - I think it's fine to have GOA as an optional dependency of
Evolution. Realistically, I think most distros are going to build it
with GOA support so it will probably pull in libgoa-1.0.so - but the
dependency on the packages
On Mon, 2011-05-02 at 11:16 -0400, David Zeuthen wrote:
One thing you can do here, is that if you can't use the OAuth token
(because of the infrastructure issues you mention), you can just ask
the user for the password yourself and maintain it yourself (e.g.
store it in gnome-keyring and
On Mon, 2011-05-02 at 11:37 -0400, David Zeuthen wrote:
Yup. Note that GOA has a well-defined format (I need to add this
information to some man page soon) for defining accounts - basically
key-value files in
/etc/goa-1.0/accounts.conf.d/*.conf
~/.config/goa-1.0/accounts.conf.d/*.conf
On Mon, 2011-05-02 at 14:46 -0400, David Zeuthen wrote:
Right. The way I'd like to think of it, is that the GOA stuff is the
authoritative source - the extra account that you are creating is
something that should be keyed off the GOA unique id. So if GOA
suddenly no longer lists an account
service)? What kind of meta-data schema will
the keyring entries use, so that E-D-S might find and reuse them?
Otherwise, the D-Bus API you proposed sounds pretty easy to wire up to
what we have (or will have), if I'm understanding all this correctly.
I'm happy with what I've seen so far.
Matthew
On Thu, 2011-04-28 at 16:20 -0400, Matthias Clasen wrote:
One more addition for your 'tasks involving contacts' list:
* Schedule a meeting and invite participants
Speaking of corporatey use cases, the traditional address book is still
used as a view of directory services like a company roster
piece in my project.
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
On Fri, 2011-03-18 at 11:06 -0400, Colin Walters wrote:
* Should we be translating g_warning / g_error ?
g_log: no, GError: yes is my rule of thumb.
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
On Wed, 2011-03-09 at 14:12 +, Bastien Nocera wrote:
The setting to change the background picture has changed names:
https://bugzilla.gnome.org/show_bug.cgi?id=633983
So if you were using picture-filename before, you'd need to use
picture-uri now. Note that gnome-desktop, which is the
On Fri, 2011-01-28 at 13:48 +0100, Javier Hernandez Antúnez wrote:
With gconf, we can create, in an arbitrary way, store configuration
key/values without a pre-defined schema. In gsettings, we assume that
application knows his own schema and will only work with such schema
definition.
At
On Fri, 2011-01-28 at 10:04 -0500, Shaun McCance wrote:
What GSettingsList allows you to do, if I understand correctly,
is retrieve a list of those paths you created. Yelp doesn't
need to do this, but I see where Evolution would. (Getting all
accounts is just getting all paths that conform to
it done and tested by April.
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
On Sat, 2010-11-13 at 13:55 +0100, Felix Riemann wrote:
*raiseshand*
Eye of GNOME uses the thumbnailer as well (we need to be able to
thumbnail without nautilus). But it should be no problem to CP this bit
(just 2 files I think) between nautilus and eog. One could also think
about
On Thu, 2010-06-10 at 10:33 +0530, chen wrote:
I just tested compiling the 2.31.3 eds tarball and the sources from
master as well. Both are building fine. Will cross-check with someone
and come back..
It builds fine against GTK+ git master, but not against 2.21.1. Just
remove the
the GNOME_MAINTAINER_MODE_DEFINES macro is our preferred means
of addressing this since it exists in gnome-common? It uses maintainer
mode to determine whether to enable deprecation flags.
Matthew Barnes
___
desktop-devel-list mailing list
desktop
and/or gThumb move to and possibly help maintain or improve
GtkImageView would be a good first step in that direction.
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
appealing to the gThumb and Eye of GNOME developers.
Matthew Barnes
[1] http://trac.bjourne.webfactional.com/
[2]
http://trac.bjourne.webfactional.com/chrome/common/gtkimageview-docs/
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http
) as the
minimum requirement, as that's as far back as I can vouch for the file
format being stable. We can bump it forward as needed.
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel
[1].
Not sure what exact version of Berkely DB to recommend. Any reasonably
up-to-date version should be sufficient.
Matthew Barnes
[1] http://burtonini.com/blog/computers/eds-libdb-2006-07-18-10-40
___
desktop-devel-list mailing list
desktop-devel
believe there's a desire to move everything over to SQLite, but that
code has not been written and we're badly understaffed right now. So
unfortunately we'll be on two different databases for a while longer.
Matthew Barnes
___
desktop-devel-list mailing list
/TwoPointTwentyseven/ExternalDependencies
but it's really for 2.29. Let me know if I need to correct that.
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
up to required version on the wiki. 1.1 is API and
ABI compatible with 1.0, so it would just be the recommended version.
A libunique 1.1.2 release is out now, so proposing that become the
minimum requirement so that modules using libunique can build with
GTK_DISABLE_SINGLE_INCLUDES.
Matthew
On Tue, 2009-07-14 at 21:59 +0200, Andre Klapper wrote:
As there was no feedback: Go ahead.
Feel encouraged to also update the wikipage and the jhbuild moduleset.
Done. jhbuild was already using the correct version.
Matthew Barnes
signature.asc
Description: This is a digitally signed
? ~/.config/accels
maybe? Should this policy be encoded in GTK+ itself?
Matthew Barnes
signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman
xmlPreviousElementSibling
Version 2.7.3 was released in January.
Matthew Barnes
signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo
On Sat, 2009-06-20 at 10:30 -0400, Matthias Clasen wrote:
What is not covered is creation of thumbnails, for which we probably
have to wait for the outcome of the 'thumbnailing service' ideas that
are being floated...
Is GnomeDesktopThumbnailFactory recommended for the interim?
Matthew Barnes
modules missing files?
Matthew Barnes
signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
for release team approval before
proceeding.
Thanks,
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
. I'm
hesitant to ship a release with both WebKit and GtkHtml dependencies
(the former for rendering, the latter for editing).
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop
of GConfBridge.
I think I'm correct in saying the GConf approach is preferred, but are
there use cases for supporting a --geometry option as well? Perhaps
just for consistency across apps?
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list
On Wed, 2008-06-18 at 18:23 +0200, Wouter Bolsterlee wrote:
Fyi, there was a talk by Sven Herzberg at Guadec 2007 (partly) about this
topic: http://2007.guadec.org/node/638
Are there slides for that talk? The description only mentions what not
to do.
Matthew Barnes
.
import bugbuddy
bugbuddy.install(appname)
Matthew Barnes
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
40 matches
Mail list logo
