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: gnome-games requires clutter 0.9.x
sø., 03.05.2009 kl. 15.59 -0500, skrev Jason D. Clinton: On Sun, May 3, 2009 at 2:39 PM, Kjartan Maraas kmar...@broadpark.no wrote: gnome-games stopped building in jhbuild for me since we still have clutter-0.8.8 there and the games want to use 0.9.x from what I can see in the logs. The request was made Mar. 17th with no objections. So, it's mandatory now. Time to move forward for everyone? Anyone else using clutter and thus need to port to the new version first? It's up to whoever is using it. 0.8 and 1.0 are co-installable. I got the impression the only other user was gnome-shell. gnome-shell developers are you ok with bumping the requirement to 0.9.2? Cheers Kjartan ___ 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
2009/5/4 Xan Lopez x...@gnome.org: 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. Brilliant work Xan! Thanks for the continued activity on the a11y patches. - 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. Congratulations on the +r bits. The community is really there now. 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? 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. 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? And finally, are there any unported projects remaining? I helped port a few applications and the patches have been integrated, and you've kept things active on the Epiphany side. GIMP, DevHelp, Yelp, Epiphany, Epiphany Extensions, Blam, Conduit and externally various Mono applications, Lifearea. http://trac.webkit.org/wiki/ApplicationsGtk has a more complete list. But with so many projects, are there any we've missed? Any patches still waiting to be merged from a branch? Maintainers, please speak up! -- http://www.nuanti.com the browser experts ___ 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
Hey All: Just a heads up that we're working on getting someone in place on the Orca side. Things are very close to being a done deal for that and we'll end up with a great collaboration between WebKit and GNOME folks for a11y. Will On 05/04/09 11:22, Alp Toker wrote: 2009/5/4 Xan Lopezx...@gnome.org: 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. Brilliant work Xan! Thanks for the continued activity on the a11y patches. - 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. Congratulations on the +r bits. The community is really there now. 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? 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. 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? And finally, are there any unported projects remaining? I helped port a few applications and the patches have been integrated, and you've kept things active on the Epiphany side. GIMP, DevHelp, Yelp, Epiphany, Epiphany Extensions, Blam, Conduit and externally various Mono applications, Lifearea. http://trac.webkit.org/wiki/ApplicationsGtk has a more complete list. But with so many projects, are there any we've missed? Any patches still waiting to be merged from a branch? Maintainers, please speak up! ___ 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 11:22 AM, Alp Toker a...@nuanti.com wrote: And finally, are there any unported projects remaining? I helped port a few applications and the patches have been integrated, and you've kept things active on the Epiphany side. GIMP, DevHelp, Yelp, Epiphany, Epiphany Extensions, Blam, Conduit and externally various Mono applications, Lifearea. http://trac.webkit.org/wiki/ApplicationsGtk has a more complete list. But with so many projects, are there any we've missed? Any patches still waiting to be merged from a branch? Maintainers, please speak up! seahorse-plugins has an epiphany extension that will need to be ported from gtkmozembed to webkit. Cheers, Adam ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
Kjartan Maraas wrote: Time to move forward for everyone? Anyone else using clutter and thus need to port to the new version first? It's up to whoever is using it. 0.8 and 1.0 are co-installable. I got the impression the only other user was gnome-shell. gnome-shell developers are you ok with bumping the requirement to 0.9.2? gnome-shell already depends on 0.9, so yes, we're ok with that. :-) -- Dan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new dependencies in gvfs
On Sun, 2009-05-03 at 07:57 +0200, Frederic Peters wrote: I am all for DeviceKit-disks as an external dependency, but don't we want gnome-disk-utility as part of the desktop set ? It features many things, notifications, Nautilus extension, awesome replacement for gfloppy, and more, things that definitely have their place in the desktop. Just like Emmannuel I'd love to have it in the desktop suite. And being a whole part of the GNOME desktop was what I understood from David announce[1] (but then I could have read too much in this): This will be the default volume monitor in GNOME 2.28 David, would you formally propose gnome-disk-utility for inclusion in the GNOME Desktop Suite ? Sure, that sounds sensible. The long term plan of this work is to have - two libraries, libgdu and libgdu-gtk - a set of applications / utilities - deep integration with GNOME (e.g. Nautilus extensions, panel items / applets, GVfs volume monitor) for dealing with storage devices. The idea is that the bulk of the work is in the libraries (including GTK+ widgets and dialogs) thus allowing people to experiment and iterate over what kind of end-user experience we want. I'm not yet ready to commit to any kind of stable API (yet) but that shouldn't be a problem as we can just update GVfs et. al. along and AFAIK there's no guarantee of any API stability in Desktop, only in Platform. However, one thing is that the (D-Bus) API of the daemon being used, DeviceKit-disks will remain API unstable for a bit longer (long term plan is to provide a stable API) - probably until the GLib/D-Bus story is sorted (see e.g. gtk-devel-list) and we have other backends (I want a backend for unit tests and of course ideally FreeBSD, Solaris and others could write backends too). This Device-disks is API unstable might be a hard pill for some distributors to swallow, e.g. they would need to rev DeviceKit-disks whenever a new GNOME release is out. Which includes revving things using DeviceKit-disks as well (it's not unlikely KDE and others will switch to DeviceKit-disks at some point). Also, the requirements for running DeviceKit-disks is also going to remain bleeding edge - to do integration on the level we want (e.g. do it right, for starters), we really need to depend on kernel and udev features as we add them. These shouldn't be problems for most distros, e.g. Fedora, OpenSUSE, Ubuntu, Mandriva etc. all tend to ship bleeding edge stuff _anyway_. It might be a problem for other OS'es (DeviceKit-disks is Linux only at the moment), jhbuild users and infrequently release distros (such as the enterprise releases or Debian). The only answer I have to this is that I will ensure that things (like GVfs) will build with --disable-gdu and then people can fall back to e.g. the HAL backend or whatever. With the caveat that these things will not be problem (because, no, I will not spend time making things work on ancient kernel or udev releases) for inclusion in the Desktop release set, I'd be more than happy to propose gnome-disk-utility. (Btw, it's not like DeviceKit-disks is in any way special here - these things apply to _many_ bits of an OS too (e.g. graphics, audio) - I'm just trying to be upfront about these things in order to manage expectations.) Finally, minor technical point: it requires libsexy (for SexyUrlLabel). I can ship a local copy if this isn't in GTK+ by the 2.28 release (I believe the plan is to get something like this into GTK+). David ___ 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
Re: gnome-games requires clutter 0.9.x
Kjartan: gnome-games stopped building in jhbuild for me since we still have clutter-0.8.8 there and the games want to use 0.9.x from what I can see in the logs. Time to move forward for everyone? Anyone else using clutter and thus need to port to the new version first? clutter-gtk 0.9 is not yet available. Yet gnome-shell requires clutter-gtk 0.9 to build, so you currently have to build it from git master. Might it be better to wait until clutter-gtk 0.9 is released before jumping to the new version in jhbuild? Brian ___ 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
2009/5/4 Xan Lopez x...@gnome.org: snip I'd like to end the email by requesting feedback from all the module maintainers that are considering a switch to WebKitGTK+ Could be also good have a minimal feedback from distro packagers. I suppose that even though all relevant GNOME Desktop modules will be switched to WebKitGtk, distros will continue to provide Firefox as standard browser. So Fedora or Ubuntu, for example, will have to put both Firefox (default browser) and WebKitGtk (as HTML rendering library for Yelp Help Browser) in their install CD. But they have a constraint on size, 700MB. Due to this, Ubuntu don't provide the GIMP own help browser. ___ 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 8:58 PM, Luca Ferretti elle@libero.it wrote: 2009/5/4 Xan Lopez x...@gnome.org: snip I'd like to end the email by requesting feedback from all the module maintainers that are considering a switch to WebKitGTK+ Could be also good have a minimal feedback from distro packagers. I suppose that even though all relevant GNOME Desktop modules will be switched to WebKitGtk, distros will continue to provide Firefox as standard browser. So Fedora or Ubuntu, for example, will have to put both Firefox (default browser) and WebKitGtk (as HTML rendering library for Yelp Help Browser) in their install CD. But they have a constraint on size, 700MB. Due to this, Ubuntu don't provide the GIMP own help browser. That's so wrong it hurts. We should use technical measures to decide which deps go in. WebKitGtk is not a Firefox alternative. Firefox is a web browser that happens to include Gecko. Gecko (xulrunner) is a web kitchen sink - a set of parsers, a rendering engine, a JS engine and a completely new graphical toolkit - all designed with building web browsers in mind. WebKitGtk is a set of embeddable GTK+ widgets based on WebKit - designed with embedding in mind. It's actually easier to build a web browser with WebKitGtk than to embed Gecko in an application such as a web browser or an instant messaging apps. Of course it's my opinion and you are free to disagree with the above or you can raise valid concerns like a11y not being fully functional in WebKitGtk but please not judge software by their size (especially if Gecko is actually bigger than WebKitGtk even including the webinspector module). PS: 700 MB limit in 2009 is as good as a floppy :) -- Patryk Zawadzki ___ 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 9:15 PM, Patryk Zawadzki pat...@pld-linux.org wrote: mind. It's actually easier to build a web browser with WebKitGtk than to embed Gecko in an application such as a web browser or an instant messaging apps. I obviously meant such as a help browser or an instant messaging app here ;) -- Patryk Zawadzki ___ 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
2009/5/4 Patryk Zawadzki pat...@pld-linux.org: That's so wrong it hurts. We should use technical measures to decide which deps go in. WebKitGtk is not a Firefox alternative. Firefox is a web browser that happens to include Gecko. Patryk, I'm for WebKitGtk in GNOME, I'm testing it from a long time; my previous email was not a -1 for WebKitGtk, but just a note about another point of view to keep in mind. PS: 700 MB limit in 2009 is as good as a floppy :) Live CD creators are crazy: someone proposed to remove Rhythmbox and include Banshee in Ubuntu just to save 6 or 9 MB :D ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new dependencies in gvfs
Le lundi 04 mai 2009 à 11:58 -0400, David Zeuthen a écrit : This Device-disks is API unstable might be a hard pill for some distributors to swallow, e.g. they would need to rev DeviceKit-disks whenever a new GNOME release is out. Which includes revving things using DeviceKit-disks as well (it's not unlikely KDE and others will switch to DeviceKit-disks at some point). There are already several fd.o packages that need to be updated this way, and it turns out to be manageable, since everything using them is either updated frequently or small enough to be trivially patched. One thing that would be much appreciated, however, is proper versioning of the interface. This is not as simple to do over D-Bus as with a regular library, but if you could at least mark prominently in the NEWS file which versions extend the protocol and which versions break it, it would help a lot with managing dependencies and upgrades. Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-games requires clutter 0.9.x
On Mon, May 4, 2009 at 12:43 PM, Brian Cameron brian.came...@sun.com wrote: clutter-gtk 0.9 is not yet available. Yet gnome-shell requires clutter-gtk 0.9 to build, so you currently have to build it from git master. Might it be better to wait until clutter-gtk 0.9 is released before jumping to the new version in jhbuild? 2.27 doesn't build with 0.8.x; the API has changed. ___ 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, 2009-05-04 at 21:15 +0200, Patryk Zawadzki wrote: On Mon, May 4, 2009 at 8:58 PM, Luca Ferretti elle@libero.it wrote: 2009/5/4 Xan Lopez x...@gnome.org: snip I'd like to end the email by requesting feedback from all the module maintainers that are considering a switch to WebKitGTK+ Could be also good have a minimal feedback from distro packagers. I suppose that even though all relevant GNOME Desktop modules will be switched to WebKitGtk, distros will continue to provide Firefox as standard browser. So Fedora or Ubuntu, for example, will have to put both Firefox (default browser) and WebKitGtk (as HTML rendering library for Yelp Help Browser) in their install CD. But they have a constraint on size, 700MB. Due to this, Ubuntu don't provide the GIMP own help browser. That's so wrong it hurts. We should use technical measures to decide which deps go in. WebKitGtk is not a Firefox alternative. Firefox is a web browser that happens to include Gecko. Right. That is Ubuntu's decision for the base install. Most users get extra features after the install, and it happens automatically after upgrades. GNOME needs to choose what is best for itself. Moreover, Epiphany can never be best if it uses Gecko. Ubuntu can reconsider its decision when Epiphany demonstrates that it is better. Gecko (xulrunner) is a web kitchen sink - a set of parsers, a rendering engine, a JS engine and a completely new graphical toolkit - all designed with building web browsers in mind. WebKitGtk is a set of embeddable GTK+ widgets based on WebKit - designed with embedding in mind. It's actually easier to build a web browser with WebKitGtk than to embed Gecko in an application such as a web browser or an instant messaging apps. Agreed. Gecko is hard to work with. Firefox, is slow and unreliable because too much of the UI is going through an adaption layer. [1] Of course it's my opinion and you are free to disagree with the above or you can raise valid concerns like a11y not being fully functional in WebKitGtk but please not judge software by their size (especially if Gecko is actually bigger than WebKitGtk even including the webinspector module). PS: 700 MB limit in 2009 is as good as a floppy :) The CD size is a policy decision, not a logistical decision. If forces the distro to make a clear demarcation about what is required. The driver for change will more likely be USB sticks, not DVDs since that is more relevant for machines with an optical disk reader. [1] And Firefox's adaption layer crashes compiz and or X when I do things like type in the location bar under Ubuntu Jaunty. /me run starry-eyed into the arms or Epiphany-webkit -- __C U R T I S C. H O V E Y___ Guilty of stealing everything I am. 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
fast-forward only policy
Hi, I was one of the happiest person on this planet the day we moved to git and i can't thanks the people involved enough. Although overall i am pretty happy with the migration, I do have one concern: The policy of disallowing non-fastforward pushes to any branch. I understand that this is good for master and other stable branches, but otoh I think it breaks the usual git workflow for feature branches. I had a little chat with Owen regarding this: == IRC LOG BEGIN== zeenix owen: hi, are we sure about this 'only fastforward for all branches' policy? owen zeenix: Well, if we had a way of figuring out that some branches where feature branches not maintenance branches, then we could conceivablly allow rebasing those branches zeenix: But not sure how to do that. I suppose we could say if there are no numbers in the branch name it's a feature branch, but that would make thigns weird if you had a branch 'bonobo-removal-2' or something zeenix owen: or you could make developer put some specific prefix in the name of feature branches? owen would be a bit ugly if all our branches were named feature-* owen zeenix: feel free to mail suggestions for a policy to gnome-infrastructure zeenix ok, will do ==IRC LOG END== I am sending this mail here cause I thought it might be better to have a discussion on this and so that other developers can speak-up if they (dis)agree. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ 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 3:15 PM, Patryk Zawadzki pat...@pld-linux.org wrote: PS: 700 MB limit in 2009 is as good as a floppy :) FWIW, Fedora is also not shipping the gimp help browser on the live cd (even though the savings for not shipping the browser are dwarfed by the savings for not shipping the help content). And whenever we try to move beyond the cd size limit, we get huge pushback from parts of the world where cd burners are still much more common than dvd burners. But that is really a distro concern and should be no means decide the GNOME html renderer question. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
Hi On Mon, May 4, 2009 at 11:38 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: Hi, I was one of the happiest person on this planet the day we moved to git and i can't thanks the people involved enough. Although overall i am pretty happy with the migration, I do have one concern: The policy of disallowing non-fastforward pushes to any branch. I understand that this is good for master and other stable branches, but otoh I think it breaks the usual git workflow for feature branches. I had a little chat with Owen regarding this: == IRC LOG BEGIN== zeenix owen: hi, are we sure about this 'only fastforward for all branches' policy? owen zeenix: Well, if we had a way of figuring out that some branches where feature branches not maintenance branches, then we could conceivablly allow rebasing those branches zeenix: But not sure how to do that. I suppose we could say if there are no numbers in the branch name it's a feature branch, but that would make thigns weird if you had a branch 'bonobo-removal-2' or something zeenix owen: or you could make developer put some specific prefix in the name of feature branches? owen would be a bit ugly if all our branches were named feature-* owen zeenix: feel free to mail suggestions for a policy to gnome-infrastructure zeenix ok, will do ==IRC LOG END== I am sending this mail here cause I thought it might be better to have a discussion on this and so that other developers can speak-up if they (dis)agree. Since we are supposed to have [project]-[MAJOR]-[MINOR] for stable branches (see http://live.gnome.org/Git/Developers), what about limiting policy to those + master ? (also, deleting the feature branches should be possible) regards, -- Marc-André Lureau Sent from Helsinki, Southern Finland, Finland ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 5, 2009 at 12:07 AM, Marc-André Lureau marcandre.lur...@gmail.com wrote: Hi On Mon, May 4, 2009 at 11:38 PM, Zeeshan Ali (Khattak) zee...@gmail.com wrote: Hi, I was one of the happiest person on this planet the day we moved to git and i can't thanks the people involved enough. Although overall i am pretty happy with the migration, I do have one concern: The policy of disallowing non-fastforward pushes to any branch. I understand that this is good for master and other stable branches, but otoh I think it breaks the usual git workflow for feature branches. I had a little chat with Owen regarding this: == IRC LOG BEGIN== zeenix owen: hi, are we sure about this 'only fastforward for all branches' policy? owen zeenix: Well, if we had a way of figuring out that some branches where feature branches not maintenance branches, then we could conceivablly allow rebasing those branches zeenix: But not sure how to do that. I suppose we could say if there are no numbers in the branch name it's a feature branch, but that would make thigns weird if you had a branch 'bonobo-removal-2' or something zeenix owen: or you could make developer put some specific prefix in the name of feature branches? owen would be a bit ugly if all our branches were named feature-* owen zeenix: feel free to mail suggestions for a policy to gnome-infrastructure zeenix ok, will do ==IRC LOG END== I am sending this mail here cause I thought it might be better to have a discussion on this and so that other developers can speak-up if they (dis)agree. Since we are supposed to have [project]-[MAJOR]-[MINOR] for stable branches (see http://live.gnome.org/Git/Developers), what about limiting policy to those + master ? (also, deleting the feature branches should be possible) Yes, a way to differentiate fixed to moving branches like that would be sensible, but what is the point of having 'project' in the branch name? Branches are per-repository, so you would never have a non 'gtk-' branch in the GTK+ repo. In fact, AFAIK at any given time GNOME projects have at most two lines of development. When GTK+ 2.17 is released, work on 2.16 is continued, but not on 2.15, so what is the point of keeping the 'gtk-2-15' branch? (or gtk-2-14) In reality you only have a 'master' and a sometimes a 'devel' branch. I would suggest a few official branch names like 'master' and 'devel', and a special two character prefix for personal branches like 'za-transcoding-rework' (Zeeshan Ali's personal branch), the rest would be up to the project to decide. Remember that in git, branches are just pointers (which usually increment automatically); it's very easy to create, rename, delete, and update the destination. Cheers. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
Hi On Tue, May 5, 2009 at 12:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: [...] what is the point of having 'project' in the branch name? Branches are per-repository, so you would never have a non 'gtk-' branch in the GTK+ repo. Not project but really [project]-[MAJOR]-[MINOR].. In fact, AFAIK at any given time GNOME projects have at most two lines of development. When GTK+ 2.17 is released, work on 2.16 is continued, but not on 2.15, so what is the point of keeping the 'gtk-2-15' branch? (or gtk-2-14) In reality you only have a 'master' and a sometimes a 'devel' branch. You should read http://live.gnome.org/MaintainersCorner#branches Stable branches are useful! Most projects have mostly stable branches, afaik. I would suggest a few official branch names like 'master' and 'devel', and a special two character prefix for personal branches like 'za-transcoding-rework' (Zeeshan Ali's personal branch), the rest would be up to the project to decide. A bit like what Zeeshan proposes then. regards, -- Marc-André Lureau Sent from Helsinki, Southern Finland, Finland ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On 05/04/2009 06:21 PM, Marc-André Lureau wrote: Hi On Tue, May 5, 2009 at 12:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: [...] what is the point of having 'project' in the branch name? Branches are per-repository, so you would never have a non 'gtk-' branch in the GTK+ repo. Not project but really [project]-[MAJOR]-[MINOR].. In fact, AFAIK at any given time GNOME projects have at most two lines of development. When GTK+ 2.17 is released, work on 2.16 is continued, but not on 2.15, so what is the point of keeping the 'gtk-2-15' branch? (or gtk-2-14) In reality you only have a 'master' and a sometimes a 'devel' branch. You should read http://live.gnome.org/MaintainersCorner#branches Stable branches are useful! Most projects have mostly stable branches, afaik. I would suggest a few official branch names like 'master' and 'devel', and a special two character prefix for personal branches like 'za-transcoding-rework' (Zeeshan Ali's personal branch), the rest would be up to the project to decide. A bit like what Zeeshan proposes then. Or the pusher's login name as prefix? That fixes the issue of user repos. The maintainer will have push power to all user branches (including deleting them). Some weird thing like that... behdad regards, ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: fast-forward only policy
On Tue, May 5, 2009 at 1:21 AM, Marc-André Lureau marcandre.lur...@gmail.com wrote: Hi On Tue, May 5, 2009 at 12:57 AM, Felipe Contreras felipe.contre...@gmail.com wrote: [...] what is the point of having 'project' in the branch name? Branches are per-repository, so you would never have a non 'gtk-' branch in the GTK+ repo. Not project but really [project]-[MAJOR]-[MINOR].. Yes, I meant why project-major-minor (gtk-2-17) when you already know 'project'. What information would be lost with a '2-17' branch name? In fact, AFAIK at any given time GNOME projects have at most two lines of development. When GTK+ 2.17 is released, work on 2.16 is continued, but not on 2.15, so what is the point of keeping the 'gtk-2-15' branch? (or gtk-2-14) In reality you only have a 'master' and a sometimes a 'devel' branch. You should read http://live.gnome.org/MaintainersCorner#branches Just read it. I'm not sure exactly what you wanted to highlight. Stable branches are useful! Most projects have mostly stable branches, afaik. Hmm, I'm not sure we are talking about the same thing. My understanding is that in most projects there's only one 'stable' branch, as in the most stable branch we have at the moment. Some projects have 'devel' (we are currently working on it, but it's not that sable) and some have 'next' (this is what you'll get on the next big release, it's probably stable enough). After reading that link (and some email searching), I think you do a branching process where you create a branch for the stable release and keep the development on the master branch. In that case I would suggest instead of creating a gtk-2-16 branch just use a stable branch, which will jump (or merge) from what you now call gtk-2-14 to gtk-2-16 when you do this branching process. The gtk-2-14 commits won't be lost as long as they are tagged. I would suggest a few official branch names like 'master' and 'devel', and a special two character prefix for personal branches like 'za-transcoding-rework' (Zeeshan Ali's personal branch), the rest would be up to the project to decide. A bit like what Zeeshan proposes then. Yeap, exactly, I'm just proposing a specific nomenclature. -- Felipe Contreras ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposing libchamplain as an external dependancy for GNOME 2.28
Hi, I would like to propose libchamplain as an external dependency to GNOME 2.28. If you never heard about this project, it is a Clutter based map widget for your application. It currently uses downloaded image tiles as map data but there is a Google Summer of Code project to render the tiles locally. More information available at: http://projects.gnome.org/libchamplain Libchamplain 0.3 (a development release) has just been released. A 0.4 stable release will be made before or in sync with GNOME 2.28. libchamplain follows Clutter numbering and API/ABI stability plan. Since it is a young project, errors in the API are corrected in the next even release until maturity is achieved and 1.0 is released. Libchamplain would not introduce any new dependencies. It currently depends on Clutter 0.8 but will be ported to Clutter 1.0 as soon as it is announced. Or depandancies include: libsoup(-gnome), cairo, sqlite and Gtk+. It doesn't depend on deprecated libraries for Gnome 3.0. libchamplain already use a lot of the GNOME infrastructure: bugzilla, mailing list, wiki and web hosting. Migrating the git repository from gitorious to git.gnome.org is planned. Releases are stored on libchamplain.pierlux.com for now but it is also planned to move to GNOME. libchamplain is already used by an EOG-plugin to display where an image has been taken. There are pending branches for Empathy (being reviewed, to be optionally available for 2.28) to display a map of where your contacts are. There is also an embryonic plug-in for F-Spot. Other non-GNOME applications are using it too but none have made releases using it so far. libchamplain has bindings for Perl, Python, C# and C++. You can find packages (or work has started) on Debian, Ubuntu, Gentoo, ArchLinux, RedHat and OpenSuse. There is a port to FreeBSD. While libchamplain isn't integrated with any of the GNOME sub-projects, it shouldn't feel alien to them either. There is little i18n to be done, no user documentation needed and I bugtriage myself. There has been some talk about A11y, but these plans will have to wait until the SoC is over. Developer documentation is very important and that's why a full API reference is available: http://libchamplain.pierlux.com/doc/unstable/ libchamplain would contribute to improve the User Experience desired in GNOME 3.0 by bringing blingy map information to the desktop. Teamed with GeoClue you get a geolocation framework to build tomorrow's location aware applications. 7 SoC projects were submitted in regard to geolocation in GNOME this year only (2 were accepted, 5 were releated directly to libchamplain). libchamplain is available under LGPL 2.1. The project started in August 2008 and has enjoyed a nice growth since. There is a good community starting to build on the IRC channel and we can count 16 different contributors to the code. See https://www.ohloh.net/p/libchamplain for more interesting stats. In this email, I hope I made my case that libchamplain could be a nice addition to the GNOME family. Best Regards, Pierre-Luc Beaudoin Maintainer of libchamplain signature.asc Description: Ceci est une partie de message numériquement signée ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
