Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Shaun McCance sha...@gnome.org wrote: ... It is worth looking into sharing solutions with other projects. But most projects seem to do what we've done: home-brew a solution that fits exactly their needs. Hard to share that. In that case, I've got some mockups in the works for a new site: https://github.com/gnome-design-team/gnome-web/tree/master/developer.gnome.org/new They're not complete yet, but I'm not sure how much time I'll have to work on them in the next week, so I thought I'd throw them out there. NOTES contains some, well, notes. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
On Sep 4, 2014 6:47 AM, Allan Day allanp...@gmail.com wrote: None of this is new news of course - we've talked about it a lot in the past, and some work has been done. The problem is that no one has found the (probably significant) time to resolve the issues we're facing. We need a volunteer or many volunteer who can help here. Happily will mentor or find a mentor who is willing to put the time. Anybody interested in getting this reviewed and working? Sri Allan ___ 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: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
I wrote: There are a few outstanding bugs (old development versions are pruned from the index files but not from the server, and are getting indexed by Google), [...] That particular bug has now been fixed, old development versions are now properly removed from the server; however I don't know how it will play out exactly with Google indexing. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Jasper St. Pierre jstpie...@mecheye.net wrote: While I'm sure a dynamic site would be a great idea in the far future, are there any small, actionable goals we can make for this? As Fred already said, this list is probably the critical priority - https://wiki.gnome.org/DocumentationProject/Tasks/DeveloperDocs#developer.gnome.org Also, I think that this bug is quite important: https://bugzilla.gnome.org/show_bug.cgi?id=735458 I'm definitely not against improving the current site, but I would also like a long-term roadmap - even if it is just a contributor fishing exercise. :) Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Frederic Peters fpet...@gnome.org wrote: ... I would tend to put goals before technical details, but library-web as it is nowadays is certainly not the best option; I addressed a few of the issues in my mail to gnome-doc-devel-list@. ... * Hackability ... * User experience ... * Documentation writing workflow ... Thanks for the information here, Fred, and sorry for not replying to your doc-devel-list email (I do remember reading it back before the hackfest). It's definitely enough to get started on a design. One of the reasons why I wanted to have this conversation is to find out if there are any third party solutions that we could use, rather than having to write and maintain our own site from scratch? Is Read the Docs [1] an option? But to be honest, while the workflow can definitely be improved, I don't think it's the main obstacle. I look at user documentation, it gets written, it gets updated, and it's Mallard in git repositories. No, I think the obstacle is that we don't have enough people willing to work on developer documentation over something else, even though many will recognize the importance it has. It's not new. The difference between user and developer documentation is that, to write developer documentation, you need to understand the technologies. This means that we have to rely on existing developers to write the developer docs, and these people are, by definition, already busy with other things. That's why we need to ensure that the barrier to entry is low - if we want to tempt developers into writing documentation, it needs to be really easy. The formula for the HowDoIs is a good start here, and it would be good to build on that. Allan [1] https://github.com/rtfd/readthedocs.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Allan Day wrote: One of the reasons why I wanted to have this conversation is to find out if there are any third party solutions that we could use, rather than having to write and maintain our own site from scratch? Is Read the Docs [1] an option? It's a first look from that perspective, I'll be happy to be corrected if I'm wrong in places. It's tailored for Sphinx (http://sphinx-doc.org/) but it has a doc builder abstraction, and it looks like it wouldn't be too difficult to add more types of documents (gtk-doc, mallard, wiki extracts...). I don't see a way to group multiple modules into bundles (a particular set of versions), this is not something we have at the moment but we talked about it in the context of devhelp; this is somehow back to the what do we want to publish? question. It would need some developments but it would certainly be a useful experiment to at least create some proof of concept with it. Do you think it would also be appropriate for help.gnome.org? (as we share the library-web between developer.gnome.org and help.gnome.org) Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
On Fri, 2014-09-05 at 11:24 +0200, Frederic Peters wrote: Allan Day wrote: One of the reasons why I wanted to have this conversation is to find out if there are any third party solutions that we could use, rather than having to write and maintain our own site from scratch? Is Read the Docs [1] an option? It's a first look from that perspective, I'll be happy to be corrected if I'm wrong in places. It's tailored for Sphinx (http://sphinx-doc.org/) but it has a doc builder abstraction, and it looks like it wouldn't be too difficult to add more types of documents (gtk-doc, mallard, wiki extracts...). I don't see a way to group multiple modules into bundles (a particular set of versions), this is not something we have at the moment but we talked about it in the context of devhelp; this is somehow back to the what do we want to publish? question. It would need some developments but it would certainly be a useful experiment to at least create some proof of concept with it. Do you think it would also be appropriate for help.gnome.org? (as we share the library-web between developer.gnome.org and help.gnome.org) How much maintenance burden is there for the general infrastructure of library-web, versus the burden of the various converters and such that we'd have to deal with anyway if plugging them into another system? RTD has been hugely popular in the Python world, but it's not the only continuous deployment or automated docs build system out there. Red Hat and Fedora use Publican for almost everything. OpenStack has a big pile of Maven code that builds its site. There are plenty of other examples that I could dig up. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Hi Shaun, How much maintenance burden is there for the general infrastructure of library-web, versus the burden of the various converters and such that we'd have to deal with anyway if plugging them into another system? There's not much maintenance required, for example new modules are automatically picked up from the jhbuild modulesets, as well as new versions of known modules published on ftp.gnome.org. There are a few outstanding bugs (old development versions are pruned from the index files but not from the server, and are getting indexed by Google), and nobody to look at them regularly (I have been doing most of library-web work during hackfests), maybe because it's difficult to hack on, but mostly (imho) because there are very few persons working on infrastructure, documentation, or both. RTD has been hugely popular in the Python world, but it's not the only continuous deployment or automated docs build system out there. Red Hat and Fedora use Publican for almost everything. OpenStack has a big pile of Maven code that builds its site. There are plenty of other examples that I could dig up. Indeed; as I wrote earlier I'd prefer to have ideas on the structure we want before we go looking for the appropriate software (or changes to the library-web code base). Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Frederic Peters fpet...@gnome.org wrote: ... RTD has been hugely popular in the Python world, but it's not the only continuous deployment or automated docs build system out there. Red Hat and Fedora use Publican for almost everything. OpenStack has a big pile of Maven code that builds its site. There are plenty of other examples that I could dig up. Indeed; as I wrote earlier I'd prefer to have ideas on the structure we want before we go looking for the appropriate software (or changes to the library-web code base). Yes, agree. (I'm working on it.) Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Frederic Peters fpet...@gnome.org wrote: ... I'd prefer to have ideas on the structure we want before we go looking for the appropriate software (or changes to the library-web code base). ... Thinking about this, if we are going to do something homebrew, then I can I can come up with more detailed plans for a design, but if we want to evaluate pre-existing solutions, my priorities would be: a) ease of setup and maintainence b) overall quality of user experience And by some basic functional requirements: * Navigate groups (and sub-groups) of documents. * Effective search. * An engaging home page, with featured or recently updated content (this could always be custom and bolted on, I suppose...) * Ability to view different versions of documentation (both by release and by programming language). If we can find something that satisfies those criteria, the design could work around whatever we opt for. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Shaun McCance sha...@gnome.org wrote: ... RTD has been hugely popular in the Python world, but it's not the only continuous deployment or automated docs build system out there. Red Hat and Fedora use Publican for almost everything. ... The Red Hat Publican deployment seems fairly custom - it is pretty nice, whereas the other Publican instances I've seen have left me cold. It would be interesting to know how much work is involved in making it nice. :) Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
On Fri, 2014-09-05 at 18:52 +0100, Allan Day wrote: Shaun McCance sha...@gnome.org wrote: ... RTD has been hugely popular in the Python world, but it's not the only continuous deployment or automated docs build system out there. Red Hat and Fedora use Publican for almost everything. ... The Red Hat Publican deployment seems fairly custom - it is pretty nice, whereas the other Publican instances I've seen have left me cold. It would be interesting to know how much work is involved in making it nice. :) Not sure. I tried digging into Publican once, but got lost in the Perl. What I do know is that Publican is very particular about how you set up and organize your documents. I know it took quite a bit of work to get the OpenStack docs even buildable with Publican, for example. And AFAIK Publican is DocBook-only. So, even to get it to handle our docs will likely be a lot of work, let alone whatever customizations you want on top of that. It is worth looking into sharing solutions with other projects. But most projects seem to do what we've done: home-brew a solution that fits exactly their needs. Hard to share that. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
Sriram Ramkrishna sriram.ramkris...@gmail.com wrote: ... We need a volunteer or many volunteer who can help here. Happily will mentor or find a mentor who is willing to put the time. Anybody interested in getting this reviewed and working? I was primarily referring to the documentation website and related infrastructure. This isn't a trivial area to work in, although contributions are extremely welcome. It would be great if we had a roadmap we could point people to... In the mean time, it's fairly easy to hack on gnome-devel-docs, if you want to make sure that everything is up to date. Allan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
Google is particularly shit at pointing people to the correct version. If we choose to have multiple versions still, we should put a giant warning at the stop saying it's not the current version, and perhaps have a version switcher. Also, while we're modifying the version infrastructure, can we make unstable mean the same thing as latest? It's weird to have a stable version come out, and have the unstable link still be outdated. On Sep 4, 2014 7:32 AM, Frederic Peters fpet...@gnome.org wrote: Allan Day wrote: Much of these issues come down to infrastructure, in my opinion. It's hard to get into writing docs, the website doesn't show what's new or updated, and it is slow to get new material online. Fred's done a fantastic job keeping library.gnome.org going, but we probably need something else (or at least major improvements). Since the hackfest in Norwich in January it's possible to get specific modules online (almost) directly after the git commits. It is configured that way for gnome-user-docs and gnome-getting-started-docs (for help. gnome.org) and for gnome-devel-docs (developer.gnome.org). A few months ago I posted some plans and questions to the gnome-doc-devel-l...@gnome.org mailing list, but probably I should have asked people to subscribe there first :) So here they are: Support for multiple programming languages multiple versions: On a structure level, there are at least two important questions: what kind of navigation do we want between programming languages (and perhaps on a more fundamental level, how do we expose them?), and between different versions of the libraries. At the time it was important to have various versions available online, for exemple GTK+ 2.6(?) was available because Nokia(?) used that version in their developments, but today we may want to expose a more unified this is the current GNOME API approach. (and that bundle approach would also benefit devhelp) Covered libraries: This brings the question of the libraries we want on the developer website, it started as just our core libraries, but requests after requests, it got its share of other libraries. (but if we decide to put them away, it's certainly also important to have a place for them). Fred ___ 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: Glade release to include GtkHeaderBar?
On Thu, Sep 4, 2014 at 7:25 AM, Allan Day allanp...@gmail.com wrote: Sriram Ramkrishna sriram.ramkris...@gmail.com wrote: ... We need a volunteer or many volunteer who can help here. Happily will mentor or find a mentor who is willing to put the time. Anybody interested in getting this reviewed and working? I was primarily referring to the documentation website and related infrastructure. This isn't a trivial area to work in, although contributions are extremely welcome. It would be great if we had a roadmap we could point people to... Let's start with the roadmap then. :-) I'll create a wiki page. In the mean time, it's fairly easy to hack on gnome-devel-docs, if you want to make sure that everything is up to date. Yes, that's what I wanted people to do. One hour I think is probably all is required for this task. Takers? sri Allan ___ 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: Glade release to include GtkHeaderBar?
On Thu, 2014-09-04 at 14:46 +0100, Allan Day wrote: Fred's done a fantastic job keeping library.gnome.org going, but we probably need something else (or at least major improvements). I did not know this existed! 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: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Allan Day wrote: However, before we go down that route, it seems like we should at least discuss whether library-web is the best option going forward. It I would tend to put goals before technical details, but library-web as it is nowadays is certainly not the best option; I addressed a few of the issues in my mail to gnome-doc-devel-list@. * Hackability - from what I've seen, it is very difficult for people to hack on developer.gnome.org. The barrier to entry is high, documentation is lacking, and it all seems rather obscure. There's some documentation, and it's even up-to-date up to the point that several persons got it running locally, but it has a long hack/build cycle by default (as it will cover all modules from multiple GNOME releases), and is using XSL transformations, and many persons find this arcane. That structure made sense back in the day (2006) but given the way other tools evolved (gtk-doc, yelp-tools), and better sysadmin infrastructure (it was difficult to get new packages installed on the RHEL version that was used until recently), it should be done differently now. * User experience - we need to decide whether developer.gnome.org should look and feel like a static website, or should be more like a web app. I was looking at Read the Docs [1] a while ago, and that kind of experience seemed like a good fit for API docs especially - search is prominent, you can quickly switch between documentation, etc. I gave my opinion in that previous email, I'd go with a dynamic website, as this would solve the issue of stale files, and offer better ways to integrate important things, like search. (the stale files issue is the problem Jasper talked about, we get Google indexing files way suboptimally) * Documentation writing workflow. Monolithic modules written in Mallard, like gnome-devel-docs, aren't approachable for developer documentation writers. The HowDoI series has been reasonably successful, partly because it is easy to write documentation on the wiki, but finding and navigating that material isn't great [2]. A middle ground might be appropriate (Markdown HowDoIs, perhaps). There are several layers here, most of the documentation still comes from C files, via gtk-doc, then from docbook, gtk-doc again. This is the bulk of what gets published, even for more textual content (migrating from GTK+ 2.x to GTK+ 3 for example); then we have other HTML generators, like Doxygen for the C++ bindings. The other documents, the Mallard pages in the platform overview or developer demos, the few wiki pages, are a really tiny part. But to be honest, while the workflow can definitely be improved, I don't think it's the main obstacle. I look at user documentation, it gets written, it gets updated, and it's Mallard in git repositories. No, I think the obstacle is that we don't have enough people willing to work on developer documentation over something else, even though many will recognize the importance it has. It's not new. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
While I'm sure a dynamic site would be a great idea in the far future, are there any small, actionable goals we can make for this? We all dream of a great docs scenario, but we never properly plan for it. What small wins can we get today, right now, to improve the experience? I have some free time to hack on it. On Thu, Sep 4, 2014 at 10:50 AM, Frederic Peters fpet...@gnome.org wrote: Allan Day wrote: However, before we go down that route, it seems like we should at least discuss whether library-web is the best option going forward. It I would tend to put goals before technical details, but library-web as it is nowadays is certainly not the best option; I addressed a few of the issues in my mail to gnome-doc-devel-list@. * Hackability - from what I've seen, it is very difficult for people to hack on developer.gnome.org. The barrier to entry is high, documentation is lacking, and it all seems rather obscure. There's some documentation, and it's even up-to-date up to the point that several persons got it running locally, but it has a long hack/build cycle by default (as it will cover all modules from multiple GNOME releases), and is using XSL transformations, and many persons find this arcane. That structure made sense back in the day (2006) but given the way other tools evolved (gtk-doc, yelp-tools), and better sysadmin infrastructure (it was difficult to get new packages installed on the RHEL version that was used until recently), it should be done differently now. * User experience - we need to decide whether developer.gnome.org should look and feel like a static website, or should be more like a web app. I was looking at Read the Docs [1] a while ago, and that kind of experience seemed like a good fit for API docs especially - search is prominent, you can quickly switch between documentation, etc. I gave my opinion in that previous email, I'd go with a dynamic website, as this would solve the issue of stale files, and offer better ways to integrate important things, like search. (the stale files issue is the problem Jasper talked about, we get Google indexing files way suboptimally) * Documentation writing workflow. Monolithic modules written in Mallard, like gnome-devel-docs, aren't approachable for developer documentation writers. The HowDoI series has been reasonably successful, partly because it is easy to write documentation on the wiki, but finding and navigating that material isn't great [2]. A middle ground might be appropriate (Markdown HowDoIs, perhaps). There are several layers here, most of the documentation still comes from C files, via gtk-doc, then from docbook, gtk-doc again. This is the bulk of what gets published, even for more textual content (migrating from GTK+ 2.x to GTK+ 3 for example); then we have other HTML generators, like Doxygen for the C++ bindings. The other documents, the Mallard pages in the platform overview or developer demos, the few wiki pages, are a really tiny part. But to be honest, while the workflow can definitely be improved, I don't think it's the main obstacle. I look at user documentation, it gets written, it gets updated, and it's Mallard in git repositories. No, I think the obstacle is that we don't have enough people willing to work on developer documentation over something else, even though many will recognize the importance it has. It's not new. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list -- Jasper ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
On Thu, 2014-09-04 at 19:50 +0200, Frederic Peters wrote: [] No, I think the obstacle is that we don't have enough people willing to work on developer documentation over something else, even though many will recognize the importance it has. It's not new. Touché. -- Germán Poo-Caamaño http://calcifer.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Developer Docs Roadmap [was Re: Glade release to include GtkHeaderBar?]
Jasper St. Pierre wrote: While I'm sure a dynamic site would be a great idea in the far future, are there any small, actionable goals we can make for this? We all dream of a great docs scenario, but we never properly plan for it. What small wins can we get today, right now, to improve the experience? I have some free time to hack on it. There's a bunch of tasks over there: https://wiki.gnome.org/DocumentationProject/Tasks/DeveloperDocs#developer.gnome.org You will also find some in bugzilla, product: website, component: developer.gnome.org. Most items are about classification, it's mostly actioned via a single file in library-web: https://git.gnome.org/browse/library-web/tree/data/overlay.xml.in Add a section for C++ Development (put this at the bottom of the page). Move the links to the programming with gtkmm3, libsigc++ and libxml++ pages to this section. The page is https://developer.gnome.org/guides. That page is defined by this snippet: subindex id=guides weight=1 sectionsoverview gdp-documentation tutorials faqs devel-guides ApplicationsProgramming/sections _titleGuides/_title _abstract A growing selection of development guides on common topics. /_abstract /subindex We want a new section, we add c++-development to the sections tag; then we want to define it, and want it at the bottom, subsection channel=devel id=c++-development weight=0.1/ And we need to give it a proper title, it's in another file, catalog.xml.in so it can be translated, we add a new line: _msgstr msgid=c++-developmentC++ Development/_msgstr Then we want some content in that section, we find the Programming with gtkmm link, document doc_module=gtkmm-tutorial old-channel=users channel=devel categorydevel-guides/category /document and change its category, from devel-guides to c++-development. Then we do the same thing for libsigc++ and libxml++ tutorials, and we're done with that item. Voila, I didn't do it for real, I may have made some typo but that's the general idea; of course there's the hackability problem, it takes time to have an exact mirror of developer.gnome.org running locally but it's probably not needed. Don't hesitate to file bugs with patches, I'll review them quickly. Fred ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
On Thu, 2014-09-04 at 08:11 -0700, Jasper St. Pierre wrote: Google is particularly shit at pointing people to the correct version. If we choose to have multiple versions still, we should put a giant warning at the stop saying it's not the current version, and perhaps have a version switcher. Is there a Bugzilla ticket already about displaying a warning banner? With regard to internet search engine indexing, https://bugzilla.gnome.org/show_bug.cgi?id=509424 was about Only let search engined index stable, unstable versions but I don't see that working for Google results. andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
Am Donnerstag, den 04.09.2014, 20:55 +0200 schrieb Andre Klapper: Is there a Bugzilla ticket already about displaying a warning banner? With regard to internet search engine indexing, https://bugzilla.gnome.org/show_bug.cgi?id=509424 was about Only let search engined index stable, unstable versions but I don't see that working for Google results. I filed https://bugzilla.gnome.org/show_bug.cgi?id=724537 a couple of month ago about both of these. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
On Tue, 2014-09-02 at 14:43 +0200, Gian Mario Tagliaretti wrote: in a previous post you mentioned outdated python examples, can you point it out? I had a quick look (maybe too quick) but it looks to me that the examples use the introspected bindings already. Here: https://developer.gnome.org/gnome-devel-demos/unstable/py.html.en If they're already up to date, then great! Make sure they cover the new widgets, though, and in particular GtkHeaderBar. 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: Glade release to include GtkHeaderBar?
hi; On 2 September 2014 14:02, Michael Catanzaro mcatanz...@gnome.org wrote: On Tue, 2014-09-02 at 14:43 +0200, Gian Mario Tagliaretti wrote: in a previous post you mentioned outdated python examples, can you point it out? I had a quick look (maybe too quick) but it looks to me that the examples use the introspected bindings already. Here: https://developer.gnome.org/gnome-devel-demos/unstable/py.html.en If they're already up to date, then great! Make sure they cover the new widgets, though, and in particular GtkHeaderBar. the Examples of applications section uses examples that were fairly old, dating around 3.0. the Tutorial for beginners and Code samples sections were written in 2012, so they are missing the widgets introduced since then — ListBox, FlowBox, and HeaderBar mostly. GMenu is already covered, but it could do with a refresh to incorporate parts of the HowDoI pages on the wiki. the screenshots would also be up for a refresh, since the default theme has changed. ciao, Emmanuele. -- http://www.bassi.io [@] ebassi [@gmail.com] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
On Tue, 2014-09-02 at 08:57 -0700, Germán Poo-Caamaño wrote: As far as I see, the same applies for every language. None of them has GtkHeaderBar, though it does not mean than everything else is wrong or outdated, it's just incomplete. Of the two pages I checked in platform-overview, both were very outdated (one directed users to Iagno as an example of how to write a Clutter app -- Iagno does not use Clutter and hasn't for at least 2.5 years -- and the other described how to use WebKit1, which has been obsolete for 1.5 years), and one of those had at least four or five broken links. I haven't looked over the platform-demos yet, and certainly at none of the Python ones, besides to note that the screenshots look very outdated. As a developer, this makes me question the relevance of the material. I'm not saying the material is bad, just that if the material is going to live in gnome-devel-docs, then someone needs to be responsible for reviewing and updating it at least once a year. Developers shouldn't have to guess which material is still relevant and which isn't. Michael 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: Glade release to include GtkHeaderBar?
The GTK+ docs have a step-by-step example that does focus on new widgets such as GtkSearchBar, GtkHeaderBar, GtkApplication, etc: https://developer.gnome.org/gtk3/3.13/ch01s05.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
On Sun, Aug 31, 2014 at 12:37 PM, Sriram Ramkrishna s...@ramkrishna.me wrote: If it is a problem with developer resources, perhaps I can try to find someone who is willing to help out provided there is a mentor? I'd be willing to work on this. I tried to get into GNOME development previously, but never got anywhere because I was moving and starting a new job at the time, and the maintainer for the project I was working with was only available about once a week. Mainly, though, I didn't really use the apps I was trying to contribute to and I've been told many times by others to scratch my own itch when it comes to contributing. For example, when trying to write my own GNOME app in Vala recently, I had to resort to reading blog posts and the source code of existing apps to incorporate a header bar with composite templates (which I don't mind, but I think will scare a lot of developers away when other platforms make it much easier). It was also frustrating when I tried to open the .ui file of a GNOME app in glade and was told header bar wasn't supported. While still somewhat limited, I have some free time now, and I would like to use it to help make development easier for other newcomers by working on adding support for new widgets to glade, especially since it's also used by that awesome new GNOME Builder project. I'm also willing to write documentation as I learn stuff to implement my own projects. Joey ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
On Sun, 2014-08-31 at 15:25 -0700, Sriram Ramkrishna wrote: Well it seems that is there. It would be nice to get some support for GtkHeaderBar in glade. Barring that, let's at least see some documentation in developer.gnome.org for javascript and vala. Right now, it doesn't exist. I found one instance of an example in python to do header bars. It might be a no-brainer for thsoe who are used to writing in the platform, but for those who are just starting off having some guide lines would be immeasurably helpful to anybody thinking of tinkering with the platform. I see an awful lot of broken links, empty headings, and obsolete information. This is sad. I'll try to look over the platform-overview and also the C and Vala examples in gnome-devel-demos sometime in the mid-term future. Help wanted for the C++, Python, and JS examples in gnome-devel-demos. If nobody volunteers to review them before 3.16, then I think they should be removed. And to whomever just redesigned the developer.gnome.org landing page: thanks! 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: Glade release to include GtkHeaderBar?
On Sep 1, 2014 6:28 PM, meg ford meg...@gmail.com wrote: Hey, On Mon, Sep 1, 2014 at 8:04 PM, Michael Catanzaro mcatanz...@gnome.org wrote: the C++, Python, and JS examples in gnome-devel-demos. If nobody volunteers to review them before 3.16, then I think they should be removed. I really don't think you should remove them. Having something there is better than nothing, especially given that most application developers aren't using C or Vala. I beg to differ, vala is very popular. More popular than JavaScript. Every thread in Reddit on GTK+ always ends up talking about how awesome Vala is. ElementaryOs uses Vala exclusively. The folks at Yorba use Vala. We spent time talking about Vala at West Coast Hackfest. Like it or not, it is very popular. We never talk about python or JavaScript. Sri Meg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
On Mon, Sep 1, 2014 at 4:50 PM, Joey Hain hain.jos...@gmail.com wrote: On Sun, Aug 31, 2014 at 12:37 PM, Sriram Ramkrishna s...@ramkrishna.me wrote: If it is a problem with developer resources, perhaps I can try to find someone who is willing to help out provided there is a mentor? I'd be willing to work on this. I tried to get into GNOME development previously, but never got anywhere because I was moving and starting a new job at the time, and the maintainer for the project I was working with was only available about once a week. Mainly, though, I didn't really use the apps I was trying to contribute to and I've been told many times by others to scratch my own itch when it comes to contributing. Hats off to you, sir. Much appreciated. Mail me, and I will get you integrated into the fold. :-) Our volunteers are our most precious resource and anybody willing to put their name in the hat to help out GNOME deserves first class support in doing it. For example, when trying to write my own GNOME app in Vala recently, I had to resort to reading blog posts and the source code of existing apps to incorporate a header bar with composite templates (which I don't mind, but I think will scare a lot of developers away when other platforms make it much easier). It was also frustrating when I tried to open the .ui file of a GNOME app in glade and was told header bar wasn't supported. I did that as well. I was trying to write something and I wanted to write it as a GNOME 3 style app in a HIG way. Imagine my surprise when that took a ton of personal time that should not have happen. The tool chain we have is inadequate. This is what we identified in the past couple of Developer Experience hackfests and as well as West Coast Hackfest. We need to build it. So again, thank you, we are grateful for helping us, your work will help move this forward. While still somewhat limited, I have some free time now, and I would like to use it to help make development easier for other newcomers by working on adding support for new widgets to glade, especially since it's also used by that awesome new GNOME Builder project. I'm also willing to write documentation as I learn stuff to implement my own projects. Please email me, I will get you the mentors you need to get yourself going quickly. I will rope in the the glade maintainer, and Christian Hergert and hopefully get this stuff integrated in the next cycle. Thank you! sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Glade release to include GtkHeaderBar?
On Mon, Sep 1, 2014 at 8:43 PM, Sriram Ramkrishna s...@ramkrishna.me wrote: On Sep 1, 2014 6:28 PM, meg ford meg...@gmail.com wrote: Hey, On Mon, Sep 1, 2014 at 8:04 PM, Michael Catanzaro mcatanz...@gnome.org wrote: the C++, Python, and JS examples in gnome-devel-demos. If nobody volunteers to review them before 3.16, then I think they should be removed. I really don't think you should remove them. Having something there is better than nothing, especially given that most application developers aren't using C or Vala. I beg to differ, vala is very popular. More popular than JavaScript. Every thread in Reddit on GTK+ always ends up talking about how awesome Vala is. Within our ecosystem, yes, but outside of GNOME I know one developer who uses Vala. Presumably those developers who are already part of the community are more likely to read the docs for C or source code if there isn't a Vala example or an example for the language they are using. So I suppose it depends on who you are targeting. ElementaryOs uses Vala exclusively. The folks at Yorba use Vala. We spent time talking about Vala at West Coast Hackfest. Like it or not, it is very popular. I don't have any problem with Vala, but I don't think it's as widely used as Python or JS. However, I'm not interested in having a debate here, I was just telling you my opinion as an app developer. As they say, since I'm not volunteering to write the docs, it's ultimately up to the people who put in the time. Meg We never talk about python or JavaScript. Sri Meg ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Glade release to include GtkHeaderBar?
Is this cycle's release of glade/libglade going to include GtkHeaderBar? I looked through the git history and I didn't see anything in there that indicated that anytihng was done. This: https://bugzilla.gnome.org/show_bug.cgi?id=700914 shows some progress. But it seems we have missed the cut off for this. If it is a problem with developer resources, perhaps I can try to find someone who is willing to help out provided there is a mentor? We're a little behind, from what I understand the following widgets from 3.10 onwards have not been implemented. From the TODO: Glib * GMenu/GMenuModel (menu GtkBuilder element) Because GMenu is in Glib library it can not implement GtkBuildable iface which is in GTK+ this lead to implementing GMenu object construction in GtkBuilder using a custom element menu Ideally we should move GtkBuilder and GtkBuildable to Glib and rename them GBuilder and GBuildable so that we can implemet GBuildable in GMenu object A way to avoid this would be to create a new object type in GTK that derives from GMenu say GtkMenuObject (GtkMenu is already taken ;) and make it implement GtkBuildable iface. * GAction, GSimpleAction, GActionGroup GTK+ 3.4 * GtkApplication (add buildable iface to support GMenuModel?¿) GTK+ 3.10 * GtkHeaderBar * GtkSearchBar * GtkStack * GtkStackSwitcher GTK+ 3.12 * GtkActionBar * GtkFlowBox * GtkPopover * centered child in GtkBox I'm a little worried that we have not made any progress on this and we continue to make designing and creating GNOME/GTK 3 apps harder for yet another cycle. sri ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
