Re: Feedback from downstreams presentation from DX hackfest 2015
On Mon, 2015-02-02 at 14:47 +0100, Bastien Nocera wrote: On Mon, 2015-02-02 at 08:05 +, Philip Withnall wrote: At the DX hackfest last week[1] I gave an informal presentation about some of the work Collabora has been doing with GLib, GStreamer, Clutter, GTK+ and related technologies on client projects, specifically focusing on the feedback from two client projects, and the problems we encountered downstream which could motivate upstream development in the future. We discussed various issues around those in the presentation, and have some ideas for fixing some of the problems which we did not manage to fix at the time of doing the work downstream. Some of these problems are inherently unfixable, though, and are mentioned purely to motivate future API designs to direct people towards a single, correct, intended usage of the API, as much as that is possible. It was suggested that I send the presentation to DDL, since it might be of general interest. I haven’t modified it from the hackfest version, so please let me know if you have any questions. I think a lot of the problems in this report need bugs created, so that the information trickles down to the appropriate maintainers. It would also greatly help with tracking of the overall goals of improving our stack. Yup, that’s definitely on my to-do list. It will take an hour or two though, so it might take me a few days to get to. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Installing DBus interface files for services
On Sat, 31.01.15 18:29, Philip Withnall (phi...@tecnocode.co.uk) wrote: Since Cosimo’s goal here is using gdbus-codegen to generate code using those interfaces, I don’t think it makes sense to pull the introspection XML from processes which would have to be running at build time. Oh no, that's not what I meant. I was more proposing to pull them once, while you develop your stuff, and then shipping them in your own tarball. So, don't pull them dynamically when you start building, but you keep your own copy of the XML bits of other APIs, frozen and stable in time in your own project. Lennart -- Lennart Poettering, Red Hat ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feedback from downstreams presentation from DX hackfest 2015
On Mon, Feb 02, 2015 at 08:05:00AM +, Philip Withnall wrote: It was suggested that I send the presentation to DDL, since it might be of general interest. I haven’t modified it from the hackfest version, so please let me know if you have any questions. Can we assume that most still needs to be actioned? Also interested what discussions there were during the hackfest to improving this. E.g. Should we maybe reach out to our advisory board? Some things mentioned lack of documentation. So with DX hackfest and documentation at same time I also wonder if there were any possibilities to improve this. Slides: http://people.collabora.com/~pwith/feedback-from-downstreams/presentation.pdf Handout: http://people.collabora.com/~pwith/feedback-from-downstreams/handout.pdf Source: http://cgit.collabora.com/git/user/pwith/feedback-from-downstreams.git/ Tarball: http://people.collabora.com/~pwith/feedback-from-downstreams/source.tar.xz -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feedback from downstreams presentation from DX hackfest 2015
On Mon, Feb 2, 2015 at 6:37 AM, Philip Withnall phi...@tecnocode.co.uk wrote: On Mon, 2015-02-02 at 12:19 +0100, Olav Vitters wrote: On Mon, Feb 02, 2015 at 08:05:00AM +, Philip Withnall wrote: It was suggested that I send the presentation to DDL, since it might be of general interest. I haven’t modified it from the hackfest version, so please let me know if you have any questions. Can we assume that most still needs to be actioned? Also interested what discussions there were during the hackfest to improving this. E.g. Should we maybe reach out to our advisory board? Some things mentioned lack of documentation. So with DX hackfest and documentation at same time I also wonder if there were any possibilities to improve this. Some of the items need actioning via bugs, which I will sort out. Some of them have already been fixed (either as part of the client work by Collabora, or by others in the time since). Some of them are unfixable, and can only be used as general guidelines for trying to avoid such problems in future (e.g. in new API designs). Thanks for sharing! One point from the slides was familiar enough to jump out at me, and it's a bit of a strange one because it's not actionable via a bug report nor a matter of API design: New functionality needs documenting: GtkBuilder templates were blogged about extensively, but are given a single sentence in the manual This actually happens quite a lot, in my experience. For someone just starting out, blogs are not very discoverable, and they won't know the blogger by name as maintainer of X. I wonder if we could take this existing enthusiasm for documenting something in a blog post and channel it into the API docs. For example I really like your own occasional series of posts about GObject stuff (e.g. [1]) but it would probably help more people if something like these code examples existed in the API docs. I do get that blog posts are more fun to write because they are informal, and they also build your reputation online whereas API docs are anonymous. [1] https://tecnocode.co.uk/2014/12/19/use-g_set_object-to-simplify-and-safetyify-gobject-property-setters/ Best, -- Philip ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feedback from downstreams presentation from DX hackfest 2015
On Mon, Feb 02, 2015 at 02:37:32PM +, Philip Withnall wrote: What do you mean by reaching out to the advisory board? Reaching out for further feedback from them as downstreams, or reaching out for resources to fix such issues? I think the former would be interesting. I’m not sure the latter is worth their time, since it’s a very loosely defined goal. I meant for resources. Though we should have a team to continuously reach out, find out issues and act on them. If we don't act/respond (which could be about going back and saying we cannot change it), then no point in asking. 4. Instant gratification: documentation changes should be visible instantly, rather than waiting 6 months for a GNOME release before the docs hit developer.gnome.org. The current infrastructure really requires tarballs. We could reuse continuous integration builds to spit out tarballs to feed to developer.gnome.org. It would not be instant, but you'd cut it down to 15 minutes maybe? It would be a huge improvement. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feedback from downstreams presentation from DX hackfest 2015
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey, 6. Devhelp needs to give you documentation for the version of the library you’re using (e.g. in JHBuild), not the version installed on your system, which is invariably outdated. Last year I started some work to allow kind of 'profiles' in Devhelp. The basic profile would be the current default behavior of looking for books in the default system paths. Then, users could also create their own profiles, e.g. based on a custom --prefix. Following the same idea, a default jhbuild profile could look for books in jhbuild's default install path. There's a branch in devhelp's git with that work started. 5. Documents need to be available offline in Devhelp. We also had some other ideas, like being able to define profiles for different target gnome versions, and then get the books for that version directly from somewhere in gnome.org. 4. Instant gratification: documentation changes should be visible instantly, rather than waiting 6 months for a GNOME release before the docs hit developer.gnome.org. Devhelp could also have a 'next' or 'latest' default profile which could sync the daily? built documentation from gnome.org. Although not sure how useful this could be if we setup the default jhbuild-based profile. I personally think that the profiles idea could be a good one, also as a first step for the next stuff. What do others think? - -- Aleksander -BEGIN PGP SIGNATURE- Version: GnuPG v2 iEUEARECAAYFAlTPnQAACgkQgxIgkKLogl6KnQCY4uAek7ldUMzkXfdHV7g0bMAz iACgpibW66+iRWZ/5UtUmW4HiRLfv9k= =BBOk -END PGP SIGNATURE- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
3.16 Release Notes
Hi all, The wiki page for the 3.16 release notes is now up [1], so please take a minute to add any features or changes you have worked on this cycle. I did add some entries for feature work that I know about, but they are very brief, so feel free to elaborate. Thanks, Allan [1] https://wiki.gnome.org/ThreePointFifteen/ReleaseNotes ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feedback from downstreams presentation from DX hackfest 2015
On Mon, 2015-02-02 at 07:55 -0800, Jasper St. Pierre wrote: On Feb 2, 2015 6:37 AM, Philip Withnall phi...@tecnocode.co.uk wrote: On Mon, 2015-02-02 at 12:19 +0100, Olav Vitters wrote: On Mon, Feb 02, 2015 at 08:05:00AM +, Philip Withnall wrote: It was suggested that I send the presentation to DDL, since it might be of general interest. I haven’t modified it from the hackfest version, so please let me know if you have any questions. Can we assume that most still needs to be actioned? Also interested what discussions there were during the hackfest to improving this. E.g. Should we maybe reach out to our advisory board? Some things mentioned lack of documentation. So with DX hackfest and documentation at same time I also wonder if there were any possibilities to improve this. Some of the items need actioning via bugs, which I will sort out. Some of them have already been fixed (either as part of the client work by Collabora, or by others in the time since). Some of them are unfixable, and can only be used as general guidelines for trying to avoid such problems in future (e.g. in new API designs). What do you mean by reaching out to the advisory board? Reaching out for further feedback from them as downstreams, or reaching out for resources to fix such issues? I think the former would be interesting. I’m not sure the latter is worth their time, since it’s a very loosely defined goal. There were some DX–documentation discussions, although I wasn’t involved in all of them so I can’t report fully. One interesting discussion came up with a set of requirements for any replacement for gtk-doc: 1. Do not want to write XML in documentation comments. Too painful, and a steep learning curve. 2. No version control program (but wikis’ version control is fine). Too much of a barrier for contribution. 3. No waiting for review of documentation changes — post-hoc gives a much lower barrier to contribution instead. 4. Instant gratification: documentation changes should be visible instantly, rather than waiting 6 months for a GNOME release before the docs hit developer.gnome.org. 5. Documents need to be available offline in Devhelp. 6. Devhelp needs to give you documentation for the version of the library you’re using (e.g. in JHBuild), not the version installed on your system, which is invariably outdated. 7. Automatically generate documentation from annotations as much as possible (e.g. eliminate ‘Free return value with g_free()’ in favour of (transfer full)). 8. Topic-based help which can be reorganised dynamically; eliminate in-order Docbook indexes. Basically the Mallard approach for reference documentation. 9. Don’t put big code examples in C comments; move them to separate C files instead, which can be compiled stand-alone. Have a way of limiting what gets rendered in the docs, plus a link to the full source. 10. Don’t parse C with regexps; use documentation from GIR files, and allow g-ir-scanner to do the C parsing legwork. I'm confused. You want both a wiki, and docs embedded in comments? What are you imagining here? Sorry, I should have explained that more clearly. Documentation is generated from C comments as at the moment, reformatted, uploaded to developer.gnome.org, and then some kind of online interface can be used to edit the documentation (and possibly add comments to it) with instant gratification. That’s what the first few points are about. There are no requirements covering how these online edits would be fed back into the C comments, but presumably that would happen somehow. The fact that there are no requirements means nobody in the hackfest discussion had strong feelings about how it should be done. Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feedback from downstreams presentation from DX hackfest 2015
On Mon, Feb 02, 2015 at 04:51:32PM +0100, Aleksander Morgado wrote: Devhelp could also have a 'next' or 'latest' default profile which could sync the daily? built documentation from gnome.org. Although not sure how useful this could be if we setup the default jhbuild-based profile. I personally think that the profiles idea could be a good one, also as a first step for the next stuff. What do others think? Having only the 'latest' profile should be sufficient for most developers, for each major version of a library of course (e.g. the latest gtk 2.x and the latest gtk 3.x). Each symbol has the Since: version information anyway. And by having the latest documentations, developers are aware of new features and don't reinvent the wheel or don't use APIs that are already deprecated since a later version. But 'latest' should have two variants: stable and unstable. Of course, having other profiles for specific versions of GNOME would be nice, but the 'latest' profiles should be the default and recommended in my opinion. Sébastien ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Feedback from downstreams presentation from DX hackfest 2015
At the DX hackfest last week[1] I gave an informal presentation about some of the work Collabora has been doing with GLib, GStreamer, Clutter, GTK+ and related technologies on client projects, specifically focusing on the feedback from two client projects, and the problems we encountered downstream which could motivate upstream development in the future. We discussed various issues around those in the presentation, and have some ideas for fixing some of the problems which we did not manage to fix at the time of doing the work downstream. Some of these problems are inherently unfixable, though, and are mentioned purely to motivate future API designs to direct people towards a single, correct, intended usage of the API, as much as that is possible. It was suggested that I send the presentation to DDL, since it might be of general interest. I haven’t modified it from the hackfest version, so please let me know if you have any questions. Slides: http://people.collabora.com/~pwith/feedback-from-downstreams/presentation.pdf Handout: http://people.collabora.com/~pwith/feedback-from-downstreams/handout.pdf Source: http://cgit.collabora.com/git/user/pwith/feedback-from-downstreams.git/ Tarball: http://people.collabora.com/~pwith/feedback-from-downstreams/source.tar.xz Philip signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
