Re: Marco
This is terrible news. I remember fondly working with him on Epiphany many years ago. His patience and good character were instrumental in getting me started on this whole crazy business, as I'm sure it was the case for many others. He will be missed, and I'd humbly suggest the Foundation to dedicate the next stable release of GNOME to his memory. Xan On Tue, May 26, 2015 at 5:53 PM, Johan Bilien j...@via.ecp.fr wrote: I unfortunately have some terrible news, Marco Pesenti Gritti passed away last Saturday in London, after a long fight against cancer. He was with his family and in good medical hands. He leaves behind his girlfriend Daniela and 4 year old daughter Daniela. I had the chance to say goodbye last week, and convey thoughts and support for his coworkers, current and passed. I was lucky to have worked with Marco for many years at litl, on a very broad range of projects, and had the chance to count him as a good friend. He was the most passionate and dedicated hacker I knew, and I know he was extremely respected in the GNOME community, for his work on Epiphany, Evince and Sugar among many others, just like he was at litl. Those who knew him personally know he was also an awesome human being. We will try to help his family as much as we can. He will be sorely missed. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Privacy/Security Friends of GNOME campaign?
On Tue, Dec 18, 2012 at 4:35 PM, Federico Mena Quintero feder...@gnome.org wrote: * Do we have something like HTTPS everywhere? This is also known as HSTS[1] (HTTP Strict Transport Security), and I would indeed love to have some time to implement it in Web. Some other things that would be nice to have: - EV-SSL support[2]. This could be somewhat complex to do it we properly patch gnutls, but using something like 'gcr' it should be relatively easy to add support for it in libsoup. - Add support for Mozilla's Persona[3], or some other mechanism to auto-generate and store passwords for pages. - Make our already built-in adblock support better. Xan 1: http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security 2: http://en.wikipedia.org/wiki/Extended_Validation_Certificate 3: http://www.mozilla.org/en-US/persona/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
A brief note about recent API breaks in WebKitGTK+
Hi, just a few comments about recent API breaks that have bothered some people. - WebKitGTK+ (in its original form, *not* the WebKit2 stuff) is API stable. This means we won't willingly break its API. This means if the API breaks in a release it's not intentional, so asking us to notify in advance d-d-l or whatever does not make much sense. - All the recent breakage happened in the DOM bindings API. This API is auto-generated from the DOM IDL files. This means we don't change it directly, so if someone for whatever reason changes the IDL files it could lead to some API break. - Most of the DOM API is sort of stable, but some bits aren't. Unfortunately it's hard to only ship the stable bits without going through a lot of hoops, so in the end we ship in our bindings APIs that could change. This does not happen often, but for some reason there were 3 or 4 changes of this nature very recently. - Ideally in the future we'll have some script that checks our API against the last version and warns us about this kind of thing. This is not done yet, so if someone wants to help us out this would be a great task to get started. - Finally, development releases exist in part to test things and catch bugs like these. If you are going to get super angry when there's some bug/mistake in one of those releases you might want to re-think your involvement in free software development... So: - API breakage should not happen. For a series of reasons it's possible that it could happen by mistake in our DOM bindings. If that's the case remain calm and notify us, we'll fix it as soon as we can. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Videos from GUADEC/clarification about GNOME on tablets
On Fri, Aug 10, 2012 at 7:57 AM, Maciej Piechotka uzytkown...@gmail.com wrote: 2. While I understand that mobile is new 'shiny' so far I am sceptical of unified interfaces (and several other things from presentation like pre-installed GNOME on tablet). I will stop here as it would be pointless to complain a lot while admitting that one did not understood presentation. What would be GNOME approach to it[1]? First of all, unless you are complaining about our talk precisely, there is really nothing to complain about. The slides represent Juanjo and mine's opinion about several issues, not GNOME's official stand on anything. Hopefully we won't have to get to the point where we need to prefix everything we say or write with My views are mine only As far as your specific question: yes, having a single interface that works well for mobile/touch and traditional form factors is challenging. That was one of the problems we talked about during the talk and the GNOME OS BoF. I think we can still have a debate about how important mobile is for GNOME and how much (if at all) we want to go there, which was basically the point. Cheers, Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Goal Proposal: Port to GMenu
On Mon, May 7, 2012 at 8:15 AM, Andrew Cowie and...@operationaldynamics.com wrote: Is there a reference application doing this right? I ask this because Epiphany¹ has no menu, but does and a funky button over on the right that, upon investigation, turns out to be a menu has useful things like add bookmark ... but not preferences! Which, eventually and quite by accident, I discovered was in the global GMenu thing up top. Oh. The way it was designed is that things related to the application as a whole go in the application menu, things related to the particular window you are in go in the gear thing. I'm not sure about what you mean exactly with Epiphany has no menu in any case. Presumably that's not quite what you're aiming for. Perhaps you can suggest a current GNOME app that *is* doing precisely what it is you want us all to do? The design we have is not exactly like what it's implemented, since there's a few things in the gear menu that should not be there. The fact that there's a global app menu and a window specific menu is implemented as designed, though. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
On Wed, Apr 25, 2012 at 3:38 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: That's the part of the user base that answers to polls in Google+. Right. That is why noone says use those answers from Google+ literally. It would be nice to find the way that would protect the results from the anti-geekness argument. But not having any survey results, making arbitrary decisions is even worse than making decisions based on Google+ surveys. I cannot speak for the Design Team, but I'm pretty sure their decisions are not arbitrary. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rules for design in Gnome
On Tue, Apr 24, 2012 at 3:58 AM, Federico Mena Quintero feder...@gnome.org wrote: The design team IS NOT welcome to: * Second-guess maintainers or well-intentioned contributors. Surely the Design Team is also composed of well intentioned contributors that only want the best for Gnome and do not deserve this kind of attack? Basically: * We don't have a hierarchy in Gnome. You don't get to say what other people may develop. The release team is our final sanity check so that we don't ship non-working garbage. If you are a module maintainer you get to set the rules within that module, and nowhere else, and other people can fork you as they please. This does not seem compatible with an email that says Rules for design in Gnome, followed by a list of things people CAN and CANNOT do. Unless the whole thing is one long joke, and not a very funny one. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Initial setup
On Tue, Apr 24, 2012 at 12:52 PM, Patryk Zawadzki pat...@pld-linux.org wrote: W dniu 24 kwietnia 2012 02:32 użytkownik Danielle Madeley danielle.made...@collabora.co.uk napisał: I sort of like the idea of a totally fresh GNOME session starting up with a Web and www.gnome.org/welcome/ in the browser, with lots of little YouTube videos. That could be useful and unobtrusive. I hope the first video is how to install Flash so I can watch the rest of the videos ;) Flash might still be needed for some things, but youtube is not one of them. Its HTML5 version works just fine, so I see no reason to design that page with that option as default. Xan -- Patryk Zawadzki I solve problems. ___ 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: 3.6 Feature: Initial setup
On Tue, Apr 24, 2012 at 6:11 PM, Shaun McCance sha...@gnome.org wrote: Flash might still be needed for some things, but youtube is not one of them. Its HTML5 version works just fine, so I see no reason to design that page with that option as default. Can't we self-host the videos? I'm not saying we can't also put them on YouTube/Vimeo/etc for the social media buzz. But if we're going to direct people somewhere (especially automatically), I'd prefer it to be something we control, running free software. That would be my first idea too. I just wanted to point out that in case the people doing it thought youtube would be better (I guess it has some advantages) it would be totally doable without having to install Flash. Xan -- Shaun ___ 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: Last GNOME 3.4 Blocker Report
On Mon, Mar 19, 2012 at 9:51 AM, Andre Klapper ak...@gmx.net wrote: === EPIPHANY === There are still references to the GNOME web browser on translations https://bugzilla.gnome.org/show_bug.cgi?id=671424 Would require string freeze breaks. After grepping this seems to happen in: - A couple of places in the License section in About: - the .pc file. I don't think this is a 3.4 blocker, unless it's somewhat critical that the license says GNOME Web Browser. I don't think it is since already before our name was Epiphany and we didn't use that there, so we have been inconsistent for a while. Someone also complained that saying The Web developers in our About copyright section is potentially confusing, which I think is a fair point (see https://bugzilla.gnome.org/show_bug.cgi?id=671831). I think changing that to say The GNOME Web developers might be worth of the string break, but not for the rest. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Epiphany now Linux-only (was: [epiphany] Require NetworkManager)
On Fri, Jun 24, 2011 at 3:51 PM, Claudio Saavedra csaave...@gnome.org wrote: Actually the dependence on NM is quite soft. We could just depend on the NM service being there and if it's not just not use it. For a bunch of macros that we use and theoretically shouldn't change often we don't need to have a compile-time dependency on NM. Since in this case it was pretty easy to get rid of the compile-time dependency I just did that (by judiciously re-defining two #defines and one enum in Epiphany). We still assume NM is on the other side of DBus though. If it's not things won't work, but I guess that's not much worse than it used to be. Xan ___ 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
On Mon, Jun 6, 2011 at 10:59 AM, Dave Neary dne...@gnome.org wrote: To sum it all up, I believe the current dynamic of the design team is doing damage to GNOME as a community. I think what is really doing damage to the community is this kind of hyperbolic accusation around the design team that seems to be in vogue lately, to be honest. Not burning bridges with existing or potential contributors is surely a noble goal, but not alienating your core developers telling them that the fruit of their passion is damaging the community certainly should be a no-brainer? And my 2 cents: if GNOME 3.0 is the kind of result we get from this damage I want more of it, not less. While the design team shouldn't have to involved everyone (and that's not what I'm asking for), they *should* involved everyone affected by design team decisions - and not to communicate the decisions, but to be sure that they've got the right question. And in the same way as a module maintainer can ask the release team to make decisions about the module, I'd like to see maintainers be able to approach the design team for help with their module. I maintain a module and I haven't had any particular problem in approaching the design team in the past when I felt the need to do so. There's a difficult debate to be had about what powers a design team can have in an environment like GNOME where nobody can force anybody to do anything, and I'm sure having people concerned with transparency and accountability will prove to be useful. What I don't think is useful is to wildly exaggerate the current situation as some kind of nightmare-ish design-driven gulag and blame all real and perceived problems on a bunch of people meeting on an IRC channel who in the end have no more power than the suggestions they can make to the module developers. It's fine to feel that the those who show up and do the work get to decide cavalier attitude some gnome people have is not very fair, but I think this problem is neither new nor constrained to design. We have worked like this for decades, we have shipped our best and worst working like that. If you want to improve things be my guest, but let's start by not alienating the people that show up and do the work because we need them the most. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: ctr-del to delete a file
On Thu, May 19, 2011 at 8:07 AM, Xavier Claessens xclae...@gmail.com wrote: Hello ddl, Looks like it is time to start flames on ddl, so let's start a new one: No, it's not. Please do not spam the list with your pet peeve bugs. Especially when there's already a bug filed in bugzilla, which is the right forum to discuss these issues. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
On Thu, Apr 21, 2011 at 11:49 AM, Colin Walters walt...@verbum.org wrote: Hi, On Thu, Apr 21, 2011 at 3:26 AM, Xan Lopez x...@gnome.org wrote: There's no particular reason for this, we just never got around to untangle them. If there's increased interest in having them as separate libraries we can have it as one of the goals for WebKitGTK+ 1.6, which should be released in time for GNOME 3.2 (of course the actual separation would likely happen a lot earlier in some 1.5.x release). Cool. It'd be nice to have this happen soon so we can evaluate things higher up the stack. I pushed this today to WebKit trunk, so it will be available in the first unstable release of the 1.5.x series in the near future. Cheers, Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.2: gjs/seed
On Wed, Apr 20, 2011 at 4:12 PM, Colin Walters walt...@verbum.org wrote: There are, however, nontrivial issues. First is that actually in good news on the gjs front, a standalone Spidermonkey release was just made recently, and I have a patch ready to use it in gjs: https://bugzilla.gnome.org/show_bug.cgi?id=646369 In contrast though, /usr/bin/seed appears to actually link to WebKit, which would be a painful dependency to have for gnome-shell, since it'd be insane to try using it inside the compositor process. This may (hopefully) be fixable. There's no particular reason for this, we just never got around to untangle them. If there's increased interest in having them as separate libraries we can have it as one of the goals for WebKitGTK+ 1.6, which should be released in time for GNOME 3.2 (of course the actual separation would likely happen a lot earlier in some 1.5.x release). Cheers, Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Fix gsettings path to use /org/gnome instead /apps
On Thu, Mar 24, 2011 at 11:41 PM, Luca Ferretti lferr...@gnome.org wrote: If you have no time to commit, I'll be glad to help you, just ask on irc (elle.uca) or reply here. Looks good for epiphany too, thank you! Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.2 ideas and plans
On Tue, Mar 22, 2011 at 3:02 PM, Matthias Clasen matthias.cla...@gmail.com wrote: - There was a proposal by the epiphany team to look at epiphany / shell integration. We are working on defining a roadmap for 3.2 and beyond these days, but it seems clear to me that for 3.2 we'll at least try to do: - Some (probably conservative to begin with) UI and behavior changes to fit better in 3.x. - Web app mode in Epiphany, well integrated with the Shell. This will likely be proposed as a GSoC project. We have some other interesting ideas, we'll announce them with a blog post Real Soon Now. Cheers, Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.0 Blocker Report for week 03
On Mon, Jan 17, 2011 at 10:09 PM, Andre Klapper ak...@gmx.net wrote: epiphany: Port Epiphany to GtkApplication https://bugzilla.gnome.org/show_bug.cgi?id=637334 Hmm, how is this a blocker? epiphany: Port EphyNetMonitor to GDBus https://bugzilla.gnome.org/show_bug.cgi?id=624421 Or this one? Certainly things work fine without doing either them and there aren't any missing features whatsoever because of them, AFAIK. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 2.91.5 status
On Tue, Jan 11, 2011 at 7:18 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Tue, Jan 11, 2011 at 12:58 PM, Vincent Untz vu...@gnome.org wrote: I haven't tested anything at runtime, though, so maybe it's a complete disaster ;-) We'll see tomorrow. Issues I have noticed so far: - all webkit apps crash for me at start Seems to work fine here. Are you using 1.3.10? If you are please open a bug. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re: gnome-panel gnome-applets?
On Tue, Dec 28, 2010 at 11:07 PM, Luca Ferretti lferr...@gnome.org wrote: Sergey, who sometimes prefers to look backwards rather than forward no problem with that. you can maintain the old user experience for yourself and never upgrade. and snarkyness is never going to get you anything, mmkay? (cit.) I believe it was a pretty reasonable answer considering the persistent angry tone of all the previous emails. You reap what you sow, and all that. Xan :P ___ 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: GNOME 2.91.4 build issues
On Wed, Dec 22, 2010 at 4:24 PM, Vincent Untz vu...@gnome.org wrote: Hi, I've been trying to build GNMOE 2.91.4 from tarballs, and it's not looking good at all :-) Matthias already mentioned some breakages caused by GTK+ 2.91.7, but it's not just that. Here are the tarballs that I have and that don't build: brasero 2.91.3 evolution-data-server 2.91.4 empathy 2.91.4 eog 2.91.4 evince 2.91.3 gnome-control-center 2.91.3.1 gnome-packagekit 2.91.3 gnome-power-manager 2.91.3 gnome-screensaver 2.91.1 gnome-session 2.91.0 gnome-shell 2.91.3 gnome-terminal 2.33.3 gnome-user-share 2.30.1 gnome-utils 2.91.1 gnome-settings-daemon 2.91.5.1 gucharmap 2.33.1 libgnomekbd 2.91.3.1 mutter 2.91.3 nautilus 2.91.5 notification-daemon 0.5.0 totem 2.91.0 vino 2.32.0 vte 0.27.2 zenity 2.91.1 WebKitGTK+ and ephy are not in the list (I guess you gave up on them!), but they don't actually work with GTK+ 2.91.7 either (they worked with what was on master the day I released). I'll try to make new releases ASAP of both. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libpeas, multiple languages, toggle references
On Sat, Aug 7, 2010 at 12:06 AM, Owen Taylor otay...@redhat.com wrote: So, do we really want to promote this as the way we do plugins in GNOME? Language neutrality for plugins seems nice, but is a bit of a trap. This is precisely the reason why we removed Python support when we added the Javascript support for extensions in Epiphany , FWIW. Xan - Owen ___ 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: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Tue, Aug 3, 2010 at 2:19 PM, Josselin Mouette j...@debian.org wrote: We talked about it today on #debian-devel, and it turns out there is a very serious problem that is fixed by symbol versioning in GTK+. $ objdump -p /usr/lib/mozilla/plugins/libflashplayer.so [snip] NEEDED libgtk-x11-2.0.so.0 Now load this plugin in an epiphany or firefox process built against GTK3, and have fun. The problem doesn’t happen with versioned symbols, since the plugin and the browser don’t exchange widgets. The Qt maintainer raised similar concerns with konqueror using QGtkStyle, which uses GTK2 to draw widgets, with the totem browser plugin built against GTK+ 3. I think latest Firefox should work fine, since they run the plugins in a different process. We are checking the feasibility of doing the same for WebKitGTK+ before GNOME 3.0, which would also solve the issue. Which is to say, it would be nice if we didn't have the problem in the first place, but a solution for it is definitely in our plans. Xan -- .''`. : :' : “Fuck you sir, don’t be suprised when you die if `. `' you burn in Hell, because I am a solid Christian `- and I am praying for you.” -- Mike ___ 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: Modulesets Reorganization
On Sun, Jun 6, 2010 at 8:55 PM, Johannes Schmid j...@jsschmid.de wrote: Hi! (...) Hey, before addressing any specific point I just want to say that I pretty much agree with the spirit of the Release Team's proposal, if not with all its details, and that I'd rather see us engage in a bit of too much destructive force on our desktop in order to sharpen our vision than die of the infamous one thousand cuts of a directionless moduleset that has, probably, grown a bit more than it should have. With that being said... P.S: Background of my proposal for specific things that may look strage at first sight (some examples): * evolution: Many people just use webmail * epiphany: unsure. Most distros ship firefox. A webbrowser is definitly a requirement so. It's very much true that for a long time pretty much every distribution has shipped browsers other than epiphany as default, even when they picked gnome as their default desktop environment. Historically firefox has been this browser, and seeing recent trends I wouldn't be surprised with chromium taking its place in the future. This has made epiphany the odd duck in the eyes of many, and given that, it's not surprising at all to see proposals like the one Johannes makes. I only want to answer with two ideas, one which should be obvious but perhaps isn't, and other than hopefully looks towards a different future for epiphany. The obvious idea is that basing our decisions on what distributions do is absolutely the wrong way of doing things. There's many distributions around, and no matter what we do there will be always some that will ignore decisions that the upstream community considers core foundations of the software we work on. This is one of the bittersweet facets of free software, and there's not really a lot to be done about it. What we *can* do, though, is work as hard as we can in shaping a coherent idea that the combination of our modules form, and make it compelling enough that most people wouldn't dream of taking it apart to build something else because they would be giving their users an impoverished experience. I don't think we should be satisfied with anything less than that. The idea for the future is that we would like to change the vision people have of epiphany. Some time ago we decided to switch our engine and work on replacing gecko with a native port of webkit for our platform. Saying that this is hard work would be an understatement, but thanks to the work of many people and companies, including a tremendous effort by the one I work for, I think we are doing great progress in bringing this new crazy thing we call the web to our platform in a way that does not feel alien to it. The problem, of course, is that users don't use APIs directly, and we still have much to do in making things usable for them. If we all agree that the web is a vital part of any modern environment we must use the opportunity we have and blend epiphany with the shell and all the other parts of gnome in one indivisible unit. Let's integrate it deep into the core experience, going where no other browser can, or would dare to, go because no other browser can break the compromises needed to sort-of-work in every possible linux environment. I've always seen this as the role epiphany should play, and at least for myself I'm more than willing to go there as long as we can figure out something that we feel makes sense for us now and in the future. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Updated webkit version to 1.1.21
On Wed, Feb 10, 2010 at 1:56 PM, Vincent Untz vu...@gnome.org wrote: Le mercredi 10 février 2010, à 11:56 +0100, Luca Ferretti a écrit : I've just updated WebKitGtk required version here [1] and in jhbuild moduleset for 2.30. Version 1.1.21 is required by Epiphany. Thanks. Btw, I guess it's fine to assume there'll be a version of WebKitGtk that will be maintained for the 2.30 development cycle (like 1.1.15 was/is for 2.28, iirc)? Yep, there will be. Xan Vincent -- Les gens heureux ne sont pas pressés. ___ 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: gconf key for the equivalent of F7?
On Thu, Oct 22, 2009 at 7:02 PM, Shaun McCance sha...@gnome.org wrote: On Thu, 2009-10-22 at 09:25 -0400, Willie Walker wrote: Hi All: There is a convention of having the user press F7 to enable caret browsing. For example, when running Firefox, one can press F7 to enable the caret in the document content and you can then arrow around the content and select/copy text. yelp has something similar, which I believe is controlled by its use_caret gconf key. I'm curious if there would be any interest/desire in a general caret_navigation key? Perhaps /desktop/interface/gnome/caret_navigation? The general assumption I'm making is that if you need caret navigation in one place, you're likely to need everywhere. Setting this key can then be managed in one spot and not require the user to have to remember to press F7 in each application where they need caret navigation. Epiphany and Evolution also both respond to F7 to enable caret navigation. (And, by the way, though Yelp stores this in GConf, it also responds to F7.) We're seeing more and more applications use an HTML renderer for core parts of their interfaces, such as Gwibber, and Empathy with the Adium theme. I also wonder if non-editable GtkTextView widgets should be doing something here. If we had a desktop-wide setting (possibly propagated by an xsetting), then GTK+/Gecko/WebKit/etc could just pick it up and do the right thing, without any extra work from application developers. This makes sense, but at least for WebKit depending on gconf would be problematic. I guess things will be much easier when we finally start using GSettings. Xan -- Shaun ___ 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: gconf key for the equivalent of F7?
On Thu, Oct 22, 2009 at 7:31 PM, Shaun McCance sha...@gnome.org wrote: Well, right. That's why I mentioned XSettings, which can then be accessed with the GtkSettings API. In fact, even after GSettings/dconf, I think it would make sense to have an XSetting, since it can be picked up by other toolkits as well. Oh, right, missed that. Yeah, sounds like a good plan to me. Xan -- Shaun ___ 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: Packages with no changelogs
2009/9/26 Josselin Mouette j...@debian.org: Le samedi 26 septembre 2009 à 12:27 +0100, Emmanuele Bassi a écrit : on the serious side: auto-generation of ChangeLogs is all fine and dandy, but distribution packagers should care about the NEWS files being correct[0]; a NEWS file is usually much more readable than an old style ChangeLog[1]. And generally I read the NEWS, but often I need more than that, and an appropriate ChangeLog is required. Furthermore, NEWS doesn’t comply with the GPL, which requires at least the modification dates. If I read GPL 2 correctly it says the files themselves should have prominent notices stating that you changed the files and the dates of any change, so it would be interesting to know if you think we should do that too. Or maybe that's going too far, a waste of time for the developers and a duplication of information that is readily available elsewhere. Like ChangeLogs. Xan Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling ___ 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: Packages with no changelogs
On Sat, Sep 26, 2009 at 9:51 PM, Emilio Pozuelo Monfort po...@ubuntu.com wrote: Xan Lopez wrote: 2009/9/26 Josselin Mouette j...@debian.org: Le samedi 26 septembre 2009 à 12:27 +0100, Emmanuele Bassi a écrit : on the serious side: auto-generation of ChangeLogs is all fine and dandy, but distribution packagers should care about the NEWS files being correct[0]; a NEWS file is usually much more readable than an old style ChangeLog[1]. And generally I read the NEWS, but often I need more than that, and an appropriate ChangeLog is required. Furthermore, NEWS doesn’t comply with the GPL, which requires at least the modification dates. If I read GPL 2 correctly it says the files themselves should have prominent notices stating that you changed the files and the dates of any change, so it would be interesting to know if you think we should do that too. Or maybe that's going too far, a waste of time for the developers and a duplication of information that is readily available elsewhere. Like ChangeLogs. That's precisely the point, ChangeLogs are not readily available anymore in many tarballs since the migration to git. All we want is for them to be generated in the tarballs again. Sure, as ebassi said that's reasonable, an I do that for my modules. My only point was that being anal in quoting the GPL to get the point across is a bit silly IMHO, since we are not even following it strictly in the first place. Xan Cheers, Emilio ___ 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
Epiphany branched for 2.28
Epiphany is branched for 2.28, the branch name is gnome-2-28. Cheers, Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, Aug 18, 2009 at 6:21 PM, Lennart Poetteringmzta...@0pointer.de wrote: On Tue, 18.08.09 11:18, Jamie McCracken (jamie.mccr...@googlemail.com) wrote: The indexer part is optional The main part tracker-store is just a database with querying and is to be used by zeitgeist If the consensus is that indexer is not suitable for inclusion then the separate tracker-store should be considered for inclusion separately the store does not do any indexing or file monitoring nor does it cosume significant resources I have no idea what tracker-store is. Please elaborate. It sounds as it was the database that is normally filled by the indexing data, but what could it be good for if you rip out the indexer? It can be used directly by applications that feed it data through an API. Zeitgeist is an example, another could be bookmarks/history storage in Epiphany. Xan Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ 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: New module proposal: tracker
On Tue, Aug 18, 2009 at 6:36 PM, Maciej Piechotkauzytkown...@gmail.com wrote: It can be used directly by applications that feed it data through an API. Zeitgeist is an example, another could be bookmarks/history storage in Epiphany. Xan Hmm. Is it one-in-all database? Then: - How you keep it out of corruption. Hardware and software errors happens and sometimes one lost files. If it is one file - ok I can live with it. If it is one-in-all file - ops (and please note that average user does not make backup). - Some fs makes operations with small files much more efficient then bigger (reiser* for example). It may have performance impact. - What with concurrent access? I have no idea if Tracker uses just one huge file for everything or if it can use one file per application/domain/whatever (and in any case that's an implementation detail not terribly important for this debate IMHO). My only point is that something like tracker-store is already useful even if you don't ship a single filesystem miner with it. You could even argue that in many cases it's better for the apps to feed the data directly to tracker and cut the middleman of writing it into the filesystem for miners to find it at a later point. Xan Regards ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, Aug 18, 2009 at 7:44 PM, Lennart Poetteringmzta...@0pointer.de wrote: On Tue, 18.08.09 18:55, Xan Lopez (x...@gnome.org) wrote: If tracker-store is not useful on its own and currently not used by anything else in GNOME, does it really make sense to push it into GNOME? Also, even if the store has uses besides the indexer, just be honest: does it *really* add any measurable benefit to GNOME if this is in GNOME if the most important user (which is the indexer) is not? Does it really make sense to push the store independantly of the indexer? Well, on one side this is the classical chicken-egg problem, isn't it? No, it's not. Many libraries have been made nothing more than maybe blessed dependencies and are nonetheless being used everywhere. And that's one way of solving the chicken-egg problem. The other is accepting the dependency before it's used, assuming the developers want it in. I think it's OK to prefer solving things in the first way, but I think it's clear adding new libraries to the platform requires some way or the other of breaking the status quo... I don't think it would be a good idea to use GNOME solely as a vehicle to make things more popular with other developers... With that I can totally agree. Xan Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 ___ 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: New module proposal: tracker
On Tue, Aug 18, 2009 at 10:43 PM, Maciej Piechotkauzytkown...@gmail.com wrote: Epiphany does not share its metadata with anyone else nor can you cross query it I believe that gnome do and/or deskbar do it quite well w/out tracker. No, they have to go and manually parse the private file epiphany uses internally, reparsing it from scratch every time it changes. It's as far from quite well as you can get. With or without tracker (the good thing about tracker is that it provides a complete solution, which you may like or dislike) what needs to happen is a sane way of exporting that data to all applications in the system. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WebKitGTK+ as an external dependency
Hi all, On Tue, Jul 14, 2009 at 5:05 PM, Joanmarie Diggsjoanmarie.di...@gmail.com wrote: Hey Will. In my opinion, having more people from the WebKit internals side certainly couldn't hurt. :-) But I'll leave your question to Xan. First of all, sorry for the late reply, I was away on Paris last week. Certainly having more people hacking on WebKitGTK+ wouldn't hurt us, but since this tends to be true for most free software projects I don't think this will be shocking news for anyone. About the question of whether we are on track to have stuff working for 2.28: My understanding from conversations with Joannie was that having a complete fix for https://bugs.webkit.org/show_bug.cgi?id=25415 would give us a reasonable basic experience with Orca, and hopefully give us confindence that with a couple more months of bug fixing we could make it for 2.28. It seems from the last mails that this might not be the case, so before answering the question I think I should ask: do we have clear cut goal for 2.28? Clearly fixing all a11y bugs in the tracker won't happen (anytime soon probably), since we'll find new issues as we fix the existing bugs, because we are able to use more functionality. My understanding is that we all realize there will be a11y regressions compared to Gecko in the near future, and that at least for 2.28 all we can aim for is to give a substantial bump to our support (which I think we are doing), enough to get the tools in a working state, so that the Release Team feels confident in having WebKitGTK+ as as external dependency. Given that the gecko branch for epiphany is unmaintained and that other modules are waiting and willing to use WebKitGTK+ I think this is pretty reasonable. That being said in the end I just trust Joanmarie's judgment, she being the professional here ;), and if she doesn't feel comfortable with the current or expected a11y support in 2.28 I'll totally abide her decission. Cheers, Xan On the Orca side of things, I'm confident that when that list of bugs has been addressed I'll be able to implement support. My concern (again) is discovering additional issues at that point and it being too close to the 2.28 release to do anything about them. --joanie On Tue, 2009-07-14 at 09:43 -0400, Willie Walker wrote: Just to chime in here - based upon our experiences with Gecko, accessibility support for browsers is no trivial task. Xan and Joanie have been hammering away at an impressive pace so far. Joanie, Xan - what do you think it would take to hit 2.28? Would more people from the WebKit internals side help? Will Joanmarie Diggs wrote: Hi all. I think it's safe to say that implementing accessibility for something as complex as WebKit is not a trivial task. :-) When I originally looked at WebKit's accessibility a year or so ago, I was really concerned; now I'm excited about it. Already there are things in WebKit which JustWork(tm) and do so with little-to-no change in Orca -- things which have taken (and in some cases continue to take) us much effort to accomplish within Orca's support for Gecko. The work that Xan and others have done has been awesome! That said Below is a list of the currently open bugs and their impact on users. In order for WebKit to be reasonably accessible for users of assistive technologies, I believe that the majority of these bugs need to be addressed. My concern first and foremost is can that be accomplished in time for the GNOME 2.28 release? Beyond that, we don't know if anything else of significance will be discovered while implementing support for WebKit in Orca and other ATs, once these bugs have been addressed. Therefore, as much as I hate to say this, my recommendation is that we keep working at the pace we are to address all of these issues, but that GNOME 3.0 be the release in which WebKit is included as an external dependency. --Joanie 25531: Metabug: Bugs blocking Orca support https://bugs.webkit.org/show_bug.cgi?id=25531 Bugs fixed: 15 Current bugs: 29 Critical 27097: Segfault when examining an object of ROLE_TABLE via at-spi Status: Unconfirmed Impact: If a user is reading the text of a page and encounters an object of ROLE_TABLE, the browser will crash. Problems Navigating Through Text 25415: Please implement support for get_text_at_offset Status: TONS of work has been done on this. Support for characters, words, and sentences seems to work quite nicely. Support for the current line sometimes works and sometimes does not. Impact: If a user is arrowing through content by line, assistive technologies cannot present the current line reliably. 25677: Implement support for get_character_extents and get_range_extents Status: Unconfirmed Impact: 1) Because WebKit exposes the text from links and formatted text as separate accessibles, a screen
Re: New Module Proposal. libseed
On Wed, May 13, 2009 at 9:38 PM, Owen Taylor otay...@redhat.com wrote: Spidermonkey: Mature, good API for extensibility. Nice language extensions. (JS 1.7.) Mostly packaged as part of xulrunner, which is a problem. Maintained by an organization that has a thorough commitment to open source. (That doesn't mean that we have more influence over the direction, necessarily, but is worth noting.) (...) P.S. - Is compatibility with Javascript standards a concern? No. Not at all. Javascript standardization is highly politicized and affected by concerns like what Microsoft can implement in IE and in general by considerations of cross-browser compatibility. We should use whatever dialect of Javascript is supported by our engine that makes our life better. So, Robert and myself just had a discussion with the JSC people. They are apparently very reluctant to add non-standard extensions to their JS implementation, and I think a few good points were raised during the discussion: - They claim not all the extensions are well thought out, and that some of them make the language more complex and harder to implement in an efficient and high-performing way (the specific example for this was 'let'). I have no opinion on this matter, but I think it's worth to know what they think. - Using non-standard extensions makes your life harder if the moment ever comes when you'd like to switch to another JS engine (which is what is happening right now, fwiw). - Using non-standard extensions makes it harder to transfer code from the Web to GNOME (and viceversa), which is IHMO one of the biggest points in favor of using JS. So perhaps it would be a good idea to just stick to a JS defined in some standard widely used for all GNOME code, in order to avoid future headaches, and consider other languages with real self-extension capabilities if we are really serious about using whatever dialects make our life easier (mandatory plug for the Lisp family of languages). Cheers, Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal. libseed
On Thu, May 14, 2009 at 4:05 PM, Havoc Pennington havoc.penning...@gmail.com wrote: So perhaps it would be a good idea to just stick to a JS defined in some standard widely used for all GNOME code, in order to avoid future headaches, and consider other languages with real self-extension capabilities if we are really serious about using whatever dialects make our life easier (mandatory plug for the Lisp family of languages). The problem is that JS-with-a-few-basic-enhancements is just _so_ much better than least-common-denominator-web-JS. There's no need to go down a slippery slope of a million enhancements, just to fix some basic stuff... like variable scoping. Web JS is why people think ugh, JavaScript While this might be true (although personally I remember 'let' more like that's a nice improvement more than OMG that makes the language usable) I think that as long as these are vendor-specific extensions it's risky to go that path unless the benefits *really* make a difference. Today it's JSC vs SpiderMonkey, but in 3 years there might be two more good engines, and perhaps we'd like to move to one of them. I guess in the end it's just a matter of deciding if those extensions are worth locking yourself in a particular implementation of the language or not. Owen has said that he'd only really miss destructuring assignment I think, your opinion is that 'let' is a deal breaker? Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal. libseed
On Thu, May 14, 2009 at 4:34 PM, Havoc Pennington h...@pobox.com wrote: If we say we have to not only support spidermonkey and JSC, but any future hypothetical JS implementation, then we're really committing to not only not using language extensions, but _never_ using or creating extensions. Basically have to wait for Microsoft to agree with changes at ECMA before using them. So, I just don't agree with the argument, for GNOME. It may well make sense from a perspective just of WebKit. Well, pragmatically speaking, what this means today (and in the foreseeable future unless you manage to convince JSC devels) is that you basically can't use any implementation that is not spidermonkey. I'm not saying that's wrong, but I think it's a clear choice GNOME has to make. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal. libseed
On Wed, May 13, 2009 at 9:47 AM, Robert Carr ca...@rpi.edu wrote: Can you commit to put in the few days work to make a patch for gnome-shell to use libseed? I think that makes it easy for the gnome-shell developers to go to libseed Yes I can do this (and have been planning to) and put it in a branch, but probably not for another week or so. The actual C patches are very small...the biggest part is reviewing all the use of let statements, and changing them...there should be no non-trivial changes though. Do you have any idea of how big a task adding 'let' support to JSC would be? Seems like that would be the real end of another contention point between gjs/seed. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal. libseed
On Wed, May 13, 2009 at 5:59 PM, Jason D. Clinton m...@jasonclinton.com wrote: +1 from me. Robert has been very responsive and his team of minions have made changes whenever I've asked. I think we must have both engines. The JS optimization battle between Mozilla and Apple is just now heating up; we cannot wait until the battle is over to pick a winner and start working with JavaScript. Having JS with which we can: A) attract web developers to our platform with little relearning B) interface with myriad JS-driven web-apps-to-desktop-apps; think Mozilla Prism, Adobe AIR, HTML5, Google Gears is critical to our ability to adapt to the web-oriented marketplace. In summary: we need both engines and we need them in our platform sooner rather than later. I just want to point out that if the gnome-shell developers have any intention or desire of using Seed in the future this whole we need both engines debate is a bit pointless, since in theory there wouldn't be any module using gjs in GNOME, and thus moving forward with Seed would be the only sane choice IMHO. So I think their input would be quite valuable here. Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New Module Proposal. libseed
On Wed, May 13, 2009 at 7:07 PM, Murray Cumming murr...@murrayc.com wrote: Quite apart from choosing which 1 of 2 candidate engines we should choose, something seems very wrong if we have to maintain a runtime engine for a programming language that we want to use. It's not something we do for any other programming languages. This strongly suggests that this is not a programming language that we should be using much. We don't maintain the runtimes, we maintain the integration between those runtimes and the platform. AFAIK we do this for a lot of other languages, like Python, Perl, Scheme, Java... Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WebKitGTK+ as an external dependency
On Wed, May 6, 2009 at 7:58 PM, Joanmarie Diggs joanmarie.di...@gmail.com wrote: Right now, my answer is gosh, I sure hope so. :-) Admittedly, not as good as a heck yes!, but better than no. Where things stand as of today is that WebKit needs quite a bit of work to ready as far as a11y is concerned. HOWEVER, I've arranged my DayJob schedule in such a way as to be able to devote around 3 days per week on the GNOME side of WebKit a11y, and Xan is already providing patches for the critical issues I've identified thus far. So if we can keep this up, and if we do not run across any really complicated issues, I believe that things will at least be good enough -- and ideally good -- in time for 2.28. But it is hard to predict the future, especially this early on in my (active) involvement, hence my optimistic maybe. Xan, what are your thoughts? Vincent and others, when do you need a definite yea or nay by? I think that's a pretty good summary. Things are already much better than they were a few weeks ago, and I think we have a promising set up to improve them much more in the coming months. It's difficult to predict how things will work out, and as usual I'm sure we'll find problems we didn't expect and so on, but that shouldn't make us deny the fact that things WILL get much better by 2.28. In any case let's try to do our best here, and in a few more weeks I'm sure we'll have a clearer picture of where we'll stand by 2.28. Cheers, Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
WebKitGTK+ as an external dependency
Hello, the aim of the Epiphany team is to make 2.28 our first WebKit release. For this to happen we need to replace our external dependency on Gecko with WebKitGTK+, so consider this a request to do so. In the post 2.26 module decision discussion (see http://mail.gnome.org/archives/desktop-devel-list/2008-November/msg00115.html), where WebKitGTK+ was rejected, the two major perceived problems that I could see were accessibility support and the lack of releases or other means of communicating the progress of the project. Let me give you an update on those issues. On the accessibility camp, I am sponsored by Igalia to spend as much time as needed in the 2.28 scope (or beyond) to make WebKitGTK+ meet all the specified requirements. I've finished and merged most of Alp's pending patches mentioned in the November 2.26 thread, and thanks to the help and support of Joanmarie and Willie Walker we have identified many new issues that we have either already fixed or that we'll continue working on. You can see the meta-bug recently opened by Joanmarie to track all the forthcoming a11y progress here: https://bugs.webkit.org/show_bug.cgi?id=25531. As Niels Bohr used to say prediction is very difficult, especially about the future, but I'm confident that the a11y situation by 2.28 will be satisfactory for everyone. On the topic of releases and project visibility: - We have created www.webkitgtk.org, where we put our tarball releases and documentation. - We have been releasing snapshots of the development branch twice per month since March, starting with 1.1.1 and up to 1.1.6 last week. They are all available in the project page. We also have a NEWS file (http://svn.webkit.org/repository/webkit/trunk/WebKit/gtk/NEWS) where you can see a summary of the changes for each release, plus regular blog posts by Gustavo and myself. - We'll keep releasing bi-weekly snapshots until 2.28, when we'll release a (probably numbered 1.2.0) stable version. In the future, we aim to keep making one stable release every 6 months, in sync with GNOME. - We have quite a few regular contributors now, plus two more WebKit reviewers in the team (Gustavo and myself again), so I think the community has grown both in size and health in the past months. I'd like to end the email by requesting feedback from all the module maintainers that are considering a switch to WebKitGTK+, in light of the idea proposed by the Release Team of making a general switch from gecko to webkit in all modules at the same time: have you tried the latest releases? Are your needs covered by now? Please reply to the list with any issues you might have or features you might need (or even to say that all is fine), so that we can address any problem earlier rather than later in the cycle. Cheers, Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WebKitGTK+ as an external dependency
On Mon, May 4, 2009 at 6:22 PM, Alp Toker a...@nuanti.com wrote: I'd like to end the email by requesting feedback from all the module maintainers that are considering a switch to WebKitGTK+, in light of the idea proposed by the Release Team of making a general switch from gecko to webkit in all modules at the same time: have you tried the latest releases? Are your needs covered by now? Please reply to the list with any issues you might have or features you might need (or even to say that all is fine), so that we can address any problem earlier rather than later in the cycle. With my user / developer hat on, I'd like to give a thumbs up here. Can you give a brief view of the state of the API (soup is an API dependency now, what else?), particularly with regard to stability. What are the areas we can expect to see development in? - Libsoup is a hard dependency and the only supported HTTP backend. We are contributing closely with upstream (hi Dan!), and lots of new features and bugfixes are coming from that. - We are also using Enchant for spellchecking support. This is a dependency right now, but we can make it optional pretty easily if there's a need for that. - The freetype backend is still the best supported. We'd like to move to the Pango one as default and only backend (like we did from curl to soup), but I'm not sure if this will happen for 2.28. The main reason for this is pango's cross platform support and it being already an integral part of our platform. - GNOME Keyring can be used, optionally, to store authentication data. - GStreamer can be used, optionally, for the HTML5 media functionality. The main drivers for this cycle have been the needs of Epiphany and Midori I'd say, with some other requests from other applications. I believe most of our needs API-wise are now covered (see for example http://live.gnome.org/Epiphany/WebKit228), and I expect to spend most of the remaining time working on a11y, libsoup (see http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg00148.html) and general WebKit bugfixing. One big thing that might happen before 2.28 is the GObject DOM API, but it might be punted if we are short on time. About API/ABI stability: - 1.2.0 will be ABI incompatible with 1.0 (this already happened in 1.1.1, our first unstable release). This was needed to add padding to all classes and guarantee hassle-free improvements in the future. - Quite a few APIs from 1.0 will be marked as deprecated, but will be still available in 1.2.0, meaning that 1.2.0 is API compatible with 1.0. - We are considering having as a rule that we'll drop APIs marked as deprecated for a whole cycle or two, similar to what GTK+ is planning for 3.0 AFAIK. We believe this is a good compromise between stability and the need to keep improving the code in an effective way. In any case the rules will be made explicit and clear in the 1.2.0 announcement. - Also like GTK+, we can break newly introduced APIs during development cycles if needed, they are only stable when released as part of a stable release. Binding authors will need to adapt to some of those changes and it might be a good idea to coordinate the language binding set with this ongoing work. External dependency will probably help here too. As mentioned, 1.2.0 will be API compatible with 1.0, so they'll only need to wrap the new API if they wish to do so (they are of course very welcome to do that). In terms of accessibility, Orca has quite a bit of hard-coded Firefox / Gecko specific logic. My review of that was that it wouldn't work well as is, but that WebKit has the opportunity to handle more of that logic internally to thin down the code needed in tools like Orca. Does that match up with what you've been seeing? Is anyone willing to put in the time on the Orca side? Yes, Joanmarie has explained to me that the a11y tools have quite a bit of code to workaround gecko issues, but she and me agree that we can and should do better, and we are already cooperating closely to do so (see my first email and Willie's email). Cheers, Xan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
