Re: GNOME 3.14 Blocker Report (week 36)
On Thu, 2014-09-04 at 10:38 +0800, 藍挺瑋 wrote: It still doesn't work ... gmake[4]: Entering directory `/home/lantw44/gnome/source/mutter/src' CC x11/events.lo In file included from x11/events.c:39: ./wayland/meta-wayland-private.h:23:10: fatal error: 'wayland-server.h' file not found #include wayland-server.h ^ I am not sure if build issues of one specific software module are of interest to the GNOME developer community on this mailing list. :) libwayland-server-devel package installed? If yes: bug report? 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: GNOME HIG: Feedback Wanted
Lasse Schuirmann lasse.schuirm...@gmail.com wrote: ... Some feedback from me: Typography One thing that is missing IMO in the font size discussion is the uglieness of absolute font sizes. In the Universal Access menu you have the Large Text option: if you use absolute font sizes these wont scale to that making this an accessibility issue. So using something like font-size: 80% should be recommended IMO. ... Isn't this more of a coding standard than a design guideline? On long term it would be nice if the theme would provide some css classes small-text, large-text. Then we could recommend using those instead of having our application developers dealing with those issues which should IMO be solved by the theme. I have to admit that I haven't looked into the predefined text styles that GTK+ does provide, but that is something to mention here. I know there's a dim style... anything else? In the future it would be fantastic to have a wider range of text styles (heading, body, emphasis, etc) like on the web, so the theme can specify weights and font variants. Visual Layour - Margins -- I'd like to avoid numbers on long term here. Spacing could be done by the theme by providing spacing related classes IMO. I fully agree. The numbers are mostly a reflection of how GTK+ works today, but it would be great to move to pure CSS for spacing. Hardcoded Colors - Note that I didnt read the whole thing yet, but: I didnt find anything like dont use hardcoded colors they are evil and screw up your design if someone uses e.g. the accessibility theme. And I searched. So IMO it is either too well hidden or it should come in. I have a stub for a page on color [1], which I haven't managed to finish. I'll try to get around to it. Accessibility -- Although blind users are probably not the main target group I think GNOME is proud to provide one of the most accessible linux desktops. I think it would be nice to have an accessibility page somewhere. Some advise how to make the application accessible to everyone without throwing away the mouse screen one day, because noone really does the latter. The keyboard input page contains guidance on this. There's also the accessibility guide [2]. One thing I would really like to add to the docs is a page on getting your app ready to be distributed. This would be a checklist on things like documentation, translations and accessibility. I'm not sure whether this should belong to the HIG or should be a standalone document, though. Allan [1] https://wiki.gnome.org/Design/HIG/Color [2] https://developer.gnome.org/accessibility-devel-guide/stable/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME HIG: Feedback Wanted
Michael Catanzaro mcatanz...@gnome.org wrote: Another question. On the header bar menus page: Header bar menus are not a good choice for performing actions on selected content: when content hasn't been selected, the menu will contain unhelpful insensitive menu items, when it has been selected, possible actions will not be advertised. This makes me think that it would be good to remove the Undo/Redo/Cut/Copy/Paste items from the header bar menu in Epiphany, since they'll usually be disabled, and they're more accessible through a context menu or a keyboard shortcut. You then say: Selection mode or popovers are a better choice for this situation. Which makes me think, oops, maybe you weren't talking about selecting text in a text field after all. ... The ambition was to provide a popover that's shown when text is selected, as a generic part of how text selections are handled [1]. That's definitely a gap in the existing application designs. That said, that page should provide clearer guidance in this regard - I'll look into it. Thanks, Allan [1] https://wiki.gnome.org/Design/OS/Selections#Tentative_Design ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.14 Blocker Report (week 36)
On 09/03/2014 11:42 PM, Andre Klapper wrote: == at-spi == Using AtspiCollection to match via interfaces seems broken and causes crashes https://bugzilla.gnome.org/show_bug.cgi?id=734805 Crash should be fixed (commit bb89b1), but more cleanup work listed in last comment We talked about this bug on today accessibility team meeting. The main reason it was included on the blocker list was the crash. So as it was solved, we agreed to remove it from the blocker list. I just updated the target on the bug. BR -- Alejandro Piñeiro ___ 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
