GtkHTML - looking for a new maintainer
Hello, an Evolution team did maintain the GtkHTML in the past, because it was its main component for a mail composer. This changed with a 3.13.3 release, when Evolution begun to use WebKit based composer. The 3.14.0 will be released together with GNOME 3.16.0, spring 2015 (Evolution currently doesn't follow GNOME release schedule, 3.12.x, which is still using GtkHTML, will be supported until the 3.14.0 is out). The GtkHTML is in a maintenance mode for several years now and as the Evolution is not using it anymore, then I'd like to ask, whether anybody is willing to take the ownership of the GtkHTML. According to Fedora rawhide (to be Fedora 22) the only package which requires it is evolution-rss, and even that might be easily fixable. Due to that I suggest that either a new maintainer will be found or do archive it in time of the GNOME 3.16.0 (Evolution 3.14.0) release. This gives enough time to any willing maintainer to speak up. Thanks and bye, Milan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Panel maintainers
Hi, https://git.gnome.org/browse/gnome-panel/stats/?period=yofs=25 shows the general commit activity per year, in case you want numbers. On Mon, 2014-09-08 at 21:48 +0300, Alberts Muktupāvels wrote: What about maintainers that used to maintain gnome-panel while it was official part? Can not they help? You could try to contact them but no idea if they still care: https://git.gnome.org/browse/gnome-panel/log/gnome-panel.doap Also in any case and wherever this is discussed in the end, it would be good to hear the view of the other party. andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
String freeze break request for evolution-data-server (3.12)
I'd like to backport some fixes from Evolution master to 3.12 which fix GSSAPI HTTP authentication and error reporting¹. Previously, if we were unable to translate an error number into a string we would end up with an untranslated message of the form 'Unknown error code' or 'Unknown code %d' from libcom_err. Now the code is fixed, we end up handling the lookup failure in EDS, and report it slightly more coherently as _((Unknown GSSAPI mechanism code: %x)) So we have a new untranslated string... in place of a string which was previously not only untranslated but untranslatable. In a case that should hopefully never happen now that we're actually looking up the error codes the right way, and where the message text wasn't giving the user much information anyway (only the number might *possibly* be helpful. On the whole, I'm not going to lose sleep over it being untranslated :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ Specifically commits a523ac27, bd843434, f98caca8, 581c32aa. smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Shaun McCance sha...@gnome.org wrote: ... It is worth looking into sharing solutions with other projects. But most projects seem to do what we've done: home-brew a solution that fits exactly their needs. Hard to share that. In that case, I've got some mockups in the works for a new site: https://github.com/gnome-design-team/gnome-web/tree/master/developer.gnome.org/new They're not complete yet, but I'm not sure how much time I'll have to work on them in the next week, so I thought I'd throw them out there. NOTES contains some, well, notes. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: String freeze break request for evolution-data-server (3.12)
On Tue, Sep 9, 2014 at 1:23 PM, David Woodhouse dw...@infradead.org wrote: I'd like to backport some fixes from Evolution master to 3.12 which fix GSSAPI HTTP authentication and error reporting¹. Previously, if we were unable to translate an error number into a string we would end up with an untranslated message of the form 'Unknown error code' or 'Unknown code %d' from libcom_err. Now the code is fixed, we end up handling the lookup failure in EDS, and report it slightly more coherently as _((Unknown GSSAPI mechanism code: %x)) So we have a new untranslated string... in place of a string which was previously not only untranslated but untranslatable. In a case that should hopefully never happen now that we're actually looking up the error codes the right way, and where the message text wasn't giving the user much information anyway (only the number might *possibly* be helpful. On the whole, I'm not going to lose sleep over it being untranslated :) 1/2 from i18n. -- Alexandre Franke ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Tracker] Proposed future for Tracker - Smaller modules
On 08/09/14 17:46, Philip Van Hoof wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/09/2014 17:11, Martyn Russell wrote: Hi Martyn, Without tracker-store, libtracker-sparql can't work. It's more the other way round I had in mind, without libtracker-sparql, tracker-store works. Actually, libtracker-data (the code of tracker-store) is also the direct-access implementation of libtracker-sparql. Yep. The tracker-store itself is a bunch of in Vala written D-Bus service wrappers around the same libtracker-data (that is used for libtracker-sparql-direct's implementation) plus an eventloop and checkpointing plus some initialization code and DBus daemonization. That's it, that's what tracker-store is :) Everything is in libtracker-data, which is used by libtracker-sparql I'm not contesting that, not sure what your point here was here? I wouldn't split the ontologies out, the store is no good without the database and without the schema it's even more useless :) Sure it is. There are already a few companies that are using Tracker with a completely different ontology. The tracker-ivi project comes to mind. Will run on the dashboards of some nice cars. Right, but then if you want that level of granularity with the components, libtracker-sparql should be separate from tracker-store too. Since you can perfectly use tracker-store without it. Besides, all the ontology validation and handling is in the libraries the store depends on. Not correct. All ontology validation rules are in the ontology's own introspection. The libtracker-data's ontology validation rules are Let me elaborate. I meant validating the ontology schema is correct, before tracker-store gets to them, they're just text files, possibly incorrect. Those rules (described by the text files) still need to be evaluated. I also meant reading changes in the ontology and general ontology change coping / upgrade path handling. Meaning that data/ontologies is completely separate from libtracker-data You could install a complete different data/ontologies, and libtracker-data would just happily crunch that and assembly you a different meta.db with different ontology validation rules. Yes you could. But more importantly you could not use the store without an ontology. In fact, several embedded-solution companies do this today w. tracker. Of course. Yea, single point of update. But whether it comes as a implementation detail of libtracker-sparql or is a central process of a Desktop session; shouldn't be of concern to whoever links with and uses libtracker-sparql. I agree, but we're not there yet. - Providing a ontology Not sure I follow you here, the reason for the store is not to provide an ontology - at least libtracker-data does a lot of that stuff - I would have to double check this. libtracker-data doesn't provide the ontology, data/ontologies does. s/ontology/database schema/ The libtracker-data implementation (which is also used 1 on 1 by libtracker-sparql's direct-access implementation) doesn't care for 99% what the ontology's content is. On some level that's not true. Clearly libtracker-data has to interpret the ontology to know what rules to follow for database upgrade paths and also what's allows or not allowed. Either way, we're getting off topic here I feel. The point is more about components / modules that should fit together or not. The libtracker-data library is internal so where it would go is quite irrelevant in some ways because it's supposed to be private anyway. The real question is, should the ontology be separate? When your process links with libtracker-sparql and uses direct-access mode, it effectively has everything it needs to deal with meta.db. Indeed. Voila :) So why is tracker-store a separate central desktop-session daemon? No reason. libtracker-sparql users shouldn't care. Off the top of my head: 1. To provide a DBus interface (may be a legacy reason, but ...) 2. To provide concurrent connections a way to serialise updates 3. To provide a central and singleton authority to the DB schema 4. Because of database locking mechanisms employed by SQLite? 5. To avoid possible race conditions? The last two could be wrong, its been a while since I had to care about this stuff :) I'm sure many of those things can be improved these days, but you're talking about making this decision upon some utopian idea that is not implemented yet. I am talking about doing this for what we have *now*. Consider the application that only wants to query and not update the DB - they don't want to depend on all the crap needed for updating the DB, just the raw libtracker-sparql part. Except that they already and always depend on tracker-store. You can't avoid it (read libtracker-sparql's initialization code: you always and necessarily depend on it). I guess it depends on what level you care about depending on something. -- Regards, Martyn Founder Director @
