Re: Most compatible AND useful toolkit for use in GNOME
Well if you want to write applications for GNOME, you should use Gtk: https://python-gtk-3-tutorial.readthedocs.org/en/latest/index.html There used to be a wonderfull pygtk all-in-one installer for Windows, but now, with pygi, I failed to find one. I know it's possible to use pygi on Windows without having a dedicated installer for it, but I guess it'd help newcomers greatly if we had one. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
Martin Pitt [2013-02-14 7:36 +0100]: So yesterday evening we were down to 5 failures, but over night we got a swath of new test failures. Yesterday I did a git pull in jhbuild itself, which changed a few components such as pulling in a new ibus version. We'll do this daily from now on, to avoid the errors come in in such large batches. A lot of the new failures are real. I'm filing bugs now, such as cogl: https://bugzilla.gnome.org/show_bug.cgi?id=693767 (bad commit identified) pango: https://bugzilla.gnome.org/show_bug.cgi?id=693766 (bad commit identified) ibus: http://code.google.com/p/ibus/issues/detail?id=1592 (very obvious) gtk: https://bugzilla.gnome.org/show_bug.cgi?id=693769 (unstable test, need help here) gobject-introspection: https://bugzilla.gnome.org/show_bug.cgi?id=693539 (already existed) Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) signature.asc Description: Digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
On Thu, Feb 14, 2013 at 3:12 PM, Martin Pitt martin.p...@ubuntu.com wrote: Hello Tristan, Tristan Van Berkom [2013-02-14 6:42 +0900]: Upon reading this particular part (and I noticed before you are using mostly jhbuild mechanics), it leads me to wonder, how granular exactly are these rebuilds ? Hi ! Thanks for answering in detail (and Colin and Emmanuele too, very interesting stuff). Right now, every 15 minutes. Sometimes longer, when the previous run is still running. I think ideally it would be great if builds could be triggered by commit. In other words, commits are serialized chronologically and each and every commit should trigger an entire rebuild, each rebuild should build everything in the moduleset up to the latest commit... separately, one after the other. That is indeed the long-term plan, but there's still some work to be done before we can do that. The machine we are running this on has 64 2.7 GHz cores and 64 GB of RAM, that really isn't a bottleneck right now. The main two problems right now are that the jhbuild update stage takes some 5 minutes to update all the ~ 160 git trees, and that jhbuild build doesn't parallelize at all, i. e. build modules which don't depend on each other could build in parallel. Once we solve both, and we dramatically reduce the time of one run from several hours (which is currently needed if e. g. a glib change happens, which rebuilds pretty much everything) to 15 minutes. The way I imagine this works now (and this is a big assumption, correct me if I'm wrong), is that a commit in a given module triggers a jhbuild build, which would mean that: a.) Several commits could have been made in a given module by the time jhbuild actually runs... meaning we dont know which of the given commits in that lapse of time actually caused the fault. That's right. It's massively better to know that one commit in these 15 minutes triggered it than something in the past week, but still not perfect as you say. b.) Module foo triggers a rebuild... and while jhbuild builds, it also pulls in new changes from module bar, in this case it's possible that a recent commit in module bar caused another module baz to be effected, but in the end it's module foo who is blamed (since module foo essentially /triggered a rebuild/) That's a trickier thing. For most commits, one should actually be able to build them independently, but sometimes those in between breaks are inevitable. Say, you make an API change in a library and then update your application to the new API, then in between you will get a build failure. The next iteration should fix it again. We have that problem independently of the frequency we build stuff of course, as we can always hit a bad time. As someone mentioned/proposed earlier in this thread, this kind of temporary error could probably be ruled out with a timeout (perhaps not a real timeout, but a measurement in elapsed time between commits). In other words, no need to alert people if a breakage was almost immediately addressed and fixed. I'm sure with some more time and development we'll find the right approach and refine things further (may include some kind of graph theory, trying some builds with different modules' changes applied in different orders and eliminating false breakages this way). Anyway, very exciting work, thank you for doing this :) Cheers, -Tristan PS: One of the fun things this will allow is... to hand out build breaker awards (something we used to do in a company I worked at, was to hand out an award to the committer which introduced the most build breaks this month, mostly just for giggles). ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
On Thu, 2013-02-14 at 07:36 +0100, Martin Pitt wrote: Hi, - gst-plugins-bad: unknown type GStaticRecMutex; this might be due to recent changes in streamer? That smells like a case of broken by change in dependency, needs updating to new API Still outstanding. That issue was fixed ~2 days ago, but it then failed to build the tests, for other reasons, and now there are some test failures on the build bot left to sort out. Probably tests relying on plugins from other modules that aren't available in this case without checking for them. Cheers -Tim ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: steam games
Sriram Ramkrishna s...@ramkrishna.me wrote: ... What do people think about this? If there is agreement what would be a good way to track? Worth having a GNOME Goal to track this? Seems worthwhile to track this. How many bugs and affected modules are we talking about here? Allan -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Gnome Feature Request
Hi, hope this is the correct list for a feature request. For years now I miss a certain feature on desktop systems (not only on the GNOME Desktop). * while copying files from one place to another it should be possible to pause the process (just like the pause button in the Firefox download dialogue) * It should be possible to group copy processes or to put them in a row: - sometimes its a bit inconvenient to mark all files and folders at once(especially when spread over different subfolders) so you start different copy processes. But it would be more efficient to copy one file after another so it makes sense to have a function to merge to one copy process. - when starting different copy processes from one device to another its often slowing down the copy process (especially when the source is a cdrom) so it would be an advantage to copy them one after another. kr th. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: steam games
Am Mittwoch, den 13.02.2013, 15:34 -0800 schrieb Sriram Ramkrishna: So, I've started playing games on Steam and started filing bugs on the limited number of games that I own. Can you point us to the corresponding reports? I found it a surprisingly smooth experience given its early stage. I have however spotted one issue: Adjusting the master volume in-game via the corresponding multimedia keys results in green screen flickering. This is due to the speaker icon fading in and moments later out. Not sure if GNOME can play along nicely here. -- Christian Kirbach christian.kirb...@gmail.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: steam games
On Thu, Feb 14, 2013 at 5:53 AM, Christian Kirbach christian.kirb...@gmail.com wrote: Am Mittwoch, den 13.02.2013, 15:34 -0800 schrieb Sriram Ramkrishna: So, I've started playing games on Steam and started filing bugs on the limited number of games that I own. Can you point us to the corresponding reports? Certainly, the first one I filed is this one: https://bugzilla.gnome.org/show_bug.cgi?id=693551 It's basically a bug report against Trine 2. If you mouse over to the bottom in a number of screens the mouse pointer is grabbed by the desktop, and the game reports that it is paused. I applied a recent patch to mutter, but it hasn't helped. The game is somewhat playable, but it can go at any time. The other one I haven't filed yet, but it relates to a problem with shell/mutter grabbing a screen and minimizing it, forcing you to go to overview to get the next screen. It's mildly annoying, but it doesn't affect game play. I suddenly can't recall the game, but it is a Valve game using the Source engine. But there is a lot of other games out there and it would be helpful for others to test and see what we are up against. I found it a surprisingly smooth experience given its early stage. I have however spotted one issue: Adjusting the master volume in-game via the corresponding multimedia keys results in green screen flickering. This is due to the speaker icon fading in and moments later out. Not sure if GNOME can play along nicely here. You should file a bug for tracking purposes. It's important that we get the games experience right and doing QA'ing is important. This is why I was so excited about the continuous test builds. Because I think we want to get new images out there for people to test so that we can improve the quality. sri -- Christian Kirbach christian.kirb...@gmail.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Most compatible AND useful toolkit for use in GNOME
Qt is an entirely unrelated toolkit, it has nothing to do with Gtk. Yes, that is true. It's not necessarily GTK I intend to use, although that is what I would *like*. Taking into consideration which is the easiest to learn, and which will be able to target the most users, Qt seems like a good toolkit for these purposes. Qt also looks quite native on the new GNOME 3.6, albeit appearing like the old GTK+ theme. I am actually quite biased towards GTK, but the idea of being able to develop for multiple platforms seems quite attractive (in regard to Qt). -- Marco Scannadinari ma...@scannadinari.co.uk ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
About clutter-gtk and his lack of accessibility support
Sorry for the cross-posting, but not sure about the best list to send this. Background: AFAIK, clutter-gtk was always a proof of concept library. It was not really used by any core module, and the plans towards Gtk4 with respect to integrate gtk with clutter [1] basically announced his future death. For that reason, although it was on in my personal TODO, I never allocated too much time to fix the a11y aspects of that library. But, as it is not clear when that gtk-clutter integration will happen, some modules planned to use it towards GNOME 3.8. The poster boy there was gnome-documents, so suddenly that item increased its priority. Taking into account that there are just two weeks till freeze [2], my idea was use any of my spare time on clutter-gtk a11y. But today, talking with Cosimo, he mentioned that he dropped clutter-gtk dependency, and that probably other modules will follow. In case of someone wondering how much work adding a11y support on clutter-gtk is, after some research and IRC chatting with Emmanuele, it is doable but not trivial (anyway 3.8 is really near, so getting it finished during these two weeks would be complex, probably it would be postponed till 3.10). But sincerely, I'm not sure if all this really worth any effort at all. It is basically deprecated, recently dropped by some modules, and probably will be dropped soon by others. I only can think on Boxes as a module that doesn't have plans for that. And sincerely there are other places to put our any kind of a11y developing effort. In that sense, and looking to this problem from a different POV, one could argue that as there are already reasons to not use clutter-gtk, we could just say that not having a11y support is just another reason to not use it, and that the a11y team do not plan to solve that aspect on that support because clutter-gtk it is barely used. Doubts, doubts everywhere. So, I'm writing this mail to ask the opinion of others. Questions like, how relevant do you see clutter-gtk on the GNOME short-medium term? How many maintainers of core-apps plans to use it? Do someone thinks that using any kind of developing time on clutter-gtk really worths? BR [1] https://www.desktopsummit.org/program/sessions/gtk-4-future-your-favorite-toolkit [2] https://mail.gnome.org/archives/desktop-devel-list/2013-February/msg00024.html -- Alejandro Piñeiro Iglesias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Most compatible AND useful toolkit for use in GNOME
hi; On 14 February 2013 16:43, Marco Scannadinari ma...@scannadinari.co.uk wrote: Qt is an entirely unrelated toolkit, it has nothing to do with Gtk. Yes, that is true. It's not necessarily GTK I intend to use, although that is what I would *like*. Taking into consideration which is the easiest to learn, and which will be able to target the most users, Qt seems like a good toolkit for these purposes. Qt also looks quite native on the new GNOME 3.6, albeit appearing like the old GTK+ theme. I am actually quite biased towards GTK, but the idea of being able to develop for multiple platforms seems quite attractive (in regard to Qt). looking like and integrated are two fairly different concepts. there are some integration points, mostly because of the work done at the X11 and freedesktop.org level, between toolkits, but clearly: if you want to integrate with GNOME, GTK is the toolkit you should use. application menus, the various APIs to handle authorization, integration with web services, and remote file systems are in GNOME platform libraries. plus, GTK is moderately portable on different platform — up to a point, at least; the main difference between Qt and GTK approaches at multi-platform portability is that Qt defers to the platform, whereas GTK is providing the platform (and papering over it, where possible). ciao, Emmanuele. -- W: http://www.emmanuelebassi.name B: http://blogs.gnome.org/ebassi/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: About clutter-gtk and his lack of accessibility support
I use Clutter-GTK in gnome-initial-setup, but have been planning to drop it for performance concerns, and Owen's new paint clock and animations work means that it's no longer necessary. Note that gnome-initial-setup is not a core module for 3.8, and is included as a preview of sorts. Much more work, including accessibility testing, would be necessary before it becomes standard. On Thu, Feb 14, 2013 at 12:11 PM, Piñeiro apinhe...@igalia.com wrote: Sorry for the cross-posting, but not sure about the best list to send this. Background: AFAIK, clutter-gtk was always a proof of concept library. It was not really used by any core module, and the plans towards Gtk4 with respect to integrate gtk with clutter [1] basically announced his future death. For that reason, although it was on in my personal TODO, I never allocated too much time to fix the a11y aspects of that library. But, as it is not clear when that gtk-clutter integration will happen, some modules planned to use it towards GNOME 3.8. The poster boy there was gnome-documents, so suddenly that item increased its priority. Taking into account that there are just two weeks till freeze [2], my idea was use any of my spare time on clutter-gtk a11y. But today, talking with Cosimo, he mentioned that he dropped clutter-gtk dependency, and that probably other modules will follow. In case of someone wondering how much work adding a11y support on clutter-gtk is, after some research and IRC chatting with Emmanuele, it is doable but not trivial (anyway 3.8 is really near, so getting it finished during these two weeks would be complex, probably it would be postponed till 3.10). But sincerely, I'm not sure if all this really worth any effort at all. It is basically deprecated, recently dropped by some modules, and probably will be dropped soon by others. I only can think on Boxes as a module that doesn't have plans for that. And sincerely there are other places to put our any kind of a11y developing effort. In that sense, and looking to this problem from a different POV, one could argue that as there are already reasons to not use clutter-gtk, we could just say that not having a11y support is just another reason to not use it, and that the a11y team do not plan to solve that aspect on that support because clutter-gtk it is barely used. Doubts, doubts everywhere. So, I'm writing this mail to ask the opinion of others. Questions like, how relevant do you see clutter-gtk on the GNOME short-medium term? How many maintainers of core-apps plans to use it? Do someone thinks that using any kind of developing time on clutter-gtk really worths? BR [1] https://www.desktopsummit.org/program/sessions/gtk-4-future-your-favorite-toolkit [2] https://mail.gnome.org/archives/desktop-devel-list/2013-February/msg00024.html -- Alejandro Piñeiro Iglesias ___ 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: About clutter-gtk and his lack of accessibility support
On Thu, Feb 14, 2013 at 12:11 PM, Piñeiro apinhe...@igalia.com wrote: Here is what I am seeing on my system right now: [mclasen@golem ~]$ rpm -q --whatrequires libclutter-gtk-1.0.so.0()(64bit) libchamplain-gtk-0.12.3-5.fc19.x86_64 cheese-libs-3.7.4-2.fc19.x86_64 totem-3.6.3-3.fc19.x86_64 cheese-3.7.4-2.fc19.x86_64 gnome-photos-3.7.3-4.fc19.x86_64 gnome-initial-setup-0.6-2.fc19.x86_64 eog-plugins-3.6.1-2.fc19.x86_64 gnome-games-gnibbles-3.6.1-2.fc19.x86_64 gnome-games-quadrapassel-3.6.1-2.fc19.x86_64 gnome-games-swell-foop-3.6.1-2.fc19.x86_64 gnome-games-lightsoff-3.6.1-2.fc19.x86_64 empathy-3.7.5-2.fc19.x86_64 gnome-color-manager-3.7.5-1.fc19.x86_64 gnome-boxes-3.7.5-1.fc19.x86_64 control-center-3.7.5.1-1.fc19.x86_64 sushi-3.7.5-1.fc19.x86_64 gnome-documents-3.7.5-1.fc19.x86_64 A few of these will probably follow the gnome-documents example and shed the clutter-gtk dependency in time for 3.8, and for some others, having the (small) clutter parts inaccessible may not be a big deal (e.g. the photo dialog in the user panel). It might help your decision to evaluate a few of these apps to see how much their accessibility is affected by clutter-gtk use - it might turn out that everything except for documents, boxes and photos is fine... and if those 3 move to pure gtk in time for 3.8, all is good. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
On Wed, 2013-02-13 at 23:08 +, Emmanuele Bassi wrote: hi; On 13 February 2013 22:11, Colin Walters walt...@verbum.org wrote: On Thu, 2013-02-14 at 06:42 +0900, Tristan Van Berkom wrote: I know, it sounds like some CPU will be melting quickly at the rate gnome-wide commits are made... but it would be simply awesome, if we could automatically pull out the exact commit which introduced exactly which failed build report in which module (and then as you mentioned, we probably need to notify both the author of the commit, and the maintainer of the effected module). If basically you want to ensure that each commit is buildable, the best way to do that is to have builders try *queued patches*, not just master. this is what the try server at Mozilla does: https://wiki.mozilla.org/ReleaseEngineering/TryServer the try server is a *great* tool (even if, sadly, is affected by Mercurial being arse) and it makes contributing code much, much safer. the try server can also be told to send the result of a patch set straight to a bug, so that the build status and the test suite result is recorded along with the bug. I think gated commits like this could be a huge benefit to GNOME by automating basic checks (eg, coding style) and build/testing checks before maintainers review the patches and approve them (at which point, they should be automatically pushed to the real master repos). Contributors would get immediate or fairly quick feedback for their code passing or failing these checks and they wouldn't have to worry about breaking the upstream code (which I think would be a non-trivial gain for some new contributors). And maintainers would save some time on (inconsistently) enforcing basic checks, waiting on builds while reviewing, etc. And the whole stack would be more stable in terms of buildability and functionality. -Travis smime.p7s Description: S/MIME cryptographic signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
On Thu, Feb 14, 2013 at 07:12:10AM +0100, Martin Pitt wrote: That is indeed the long-term plan, but there's still some work to be done before we can do that. The machine we are running this on has 64 2.7 GHz cores and 64 GB of RAM, that really isn't a bottleneck right now. The main two problems right now are that the jhbuild update stage takes some 5 minutes to update all the ~ 160 git trees, and that jhbuild build doesn't parallelize at all, i. e. build modules which don't depend on each other could build in parallel. Could you perhaps do a test that does 10 git checkouts at once (real ones, while things are updated and so on)? I think you might eventually run into issues with the bandwidth between Red Hat NOC and Canonical NOC. If you see a bottleneck problem, please say so so that it can be worked on at the same time as parallelizing jhbuild. E.g. there was a plan to mirror git.gnome.org, but there are also a few GNOME servers @ Canonical that could be reused. -- Regards, Olav ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: About clutter-gtk and his lack of accessibility support
On Thu, Feb 14, 2013 at 9:08 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Thu, Feb 14, 2013 at 12:11 PM, Piñeiro apinhe...@igalia.com wrote: Here is what I am seeing on my system right now: [mclasen@golem ~]$ rpm -q --whatrequires libclutter-gtk-1.0.so.0()(64bit) libchamplain-gtk-0.12.3-5.fc19.x86_64 cheese-libs-3.7.4-2.fc19.x86_64 totem-3.6.3-3.fc19.x86_64 cheese-3.7.4-2.fc19.x86_64 gnome-photos-3.7.3-4.fc19.x86_64 gnome-initial-setup-0.6-2.fc19.x86_64 eog-plugins-3.6.1-2.fc19.x86_64 gnome-games-gnibbles-3.6.1-2.fc19.x86_64 gnome-games-quadrapassel-3.6.1-2.fc19.x86_64 gnome-games-swell-foop-3.6.1-2.fc19.x86_64 gnome-games-lightsoff-3.6.1-2.fc19.x86_64 empathy-3.7.5-2.fc19.x86_64 gnome-color-manager-3.7.5-1.fc19.x86_64 gnome-boxes-3.7.5-1.fc19.x86_64 control-center-3.7.5.1-1.fc19.x86_64 sushi-3.7.5-1.fc19.x86_64 gnome-documents-3.7.5-1.fc19.x86_64 A few of these will probably follow the gnome-documents example and shed the clutter-gtk dependency in time for 3.8, and for some others, having the (small) clutter parts inaccessible may not be a big deal (e.g. the photo dialog in the user panel). It might help your decision to evaluate a few of these apps to see how much their accessibility is affected by clutter-gtk use - it might turn out that everything except for documents, boxes and photos is fine... and if those 3 move to pure gtk in time for 3.8, all is good. We're making extensive use of clutter-gtk in Boxes so moving away from it in time for 3.8 does not sound realistic. -- Regards, Zeeshan Ali (Khattak) FSF member#5124 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Announcement/RFC: jhbuild continuous integration testing
On Fri, Feb 15, 2013 at 7:57 AM, Olav Vitters o...@vitters.nl wrote: On Thu, Feb 14, 2013 at 07:12:10AM +0100, Martin Pitt wrote: That is indeed the long-term plan, but there's still some work to be done before we can do that. The machine we are running this on has 64 2.7 GHz cores and 64 GB of RAM, that really isn't a bottleneck right now. The main two problems right now are that the jhbuild update stage takes some 5 minutes to update all the ~ 160 git trees, and that jhbuild build doesn't parallelize at all, i. e. build modules which don't depend on each other could build in parallel. Could you perhaps do a test that does 10 git checkouts at once (real ones, while things are updated and so on)? I think you might eventually run into issues with the bandwidth between Red Hat NOC and Canonical NOC. If you see a bottleneck problem, please say so so that it can be worked on at the same time as parallelizing jhbuild. E.g. there was a plan to mirror git.gnome.org, but there are also a few GNOME servers @ Canonical that could be reused. Fixing that bottleneck also sounds like one of the first steps towards setting up a patch queue approach, i.e. set up a local mirror of all remote git repos which is periodically updated... and fixup jhbuild to optionally update from those local mirror instead of accessing remote ones all the time. Of course, making jhbuild parallelize the actual module builds is a bit more complex (probably just a bit of python scripting ? not sure). Another thought, if this gets integrated in a 'mostly a feature of jhbuild' fashion, this can have some really interesting additional benefits. Many projects that use the gnome platform libs already do create their own modulesets, and can then easily set this up on their own build server for their own project (improving the gnome developer story in a big/real way), first thing that comes to mind is the osx builds of Clutter and GTK+ (which are mostly just customized jhbuild modulesets), not sure about win32... do we use jhbuild inside MSYS I can't remember ? Cheers, -Tristan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
