Re: compiler warnings, -Werror, etc.
12345678901234567890123456789012345678901234567890123456789012345678901234567890 Colin Walters walters at verbum.org writes: First, compiler warnings range widely in how important they are. Some of them, like -Wmissing-prototypes, are pretty much always indicative of a serious problem in your code. Others like -Wmaybe-uninitialzed are actually *heuristics* - the GCC manual clearly states that GCC may in fact be wrong, and that one even has maybe in the name. I think the general consensus is that code that triggers these warnings is bad code. The job of source code is not just to ensure that the compiler generates correct output, but also to ensure that somebody who modifies that source code later will still make the compiler generate correct output. Second, I don't think you are the right person to determine which warnings are or are not important. Apparently the GCC developers think otherwise and I frankly trust them more than I trust you. (And the maybe in the name is because the variabe is maybe uninitialized, not because gcc thinks it has maybe found an uninitialized variable - in contrast to -Wuninitialized.) So I think what Dan has is more the Right Thing - make the compiler warnings that you should *never* hit into explicit errors. That establishes a minimum baseline. Maintainers should feel free to make some other things into errors as they wish (-Werror=unused-but-set), but please don't use -Werror=deprecated-declarations or -Werror=mabe-uninitialized. I work in a module where people do not want to use -Werror. This leads to regular commits with warnings and nobody fixes them but me. So I assume that in projects where I am not a member these warnings often go unfixed for a long time. So what essentially happens is that we move QA from compile-time to run-time. We ignore the warnings about brokenness that the compiler gives us for free and instead let users find those bugs the hard way. Isn't that a bad way to do development? Sure, for a packager who just wants to compile stuff and whose work doesn't involve makig sure things are bugfree it's a nuisance that we make him fix it. But wouldn't we rather have them get it fixed than users who just lost their data? what actually ends up happening is your code only compiles on a *particular version* of gcc. That just doesn't work in a distributed project like GNOME, where various bits get reused by different projects and products on different schedules etc. I think what we should do is restrict the list of supported compilers - in particular for git checkouts, but I'd argue we should require gcc = 4.4 for GNOME compilation. We do the same thing with all the other stuff we depend on (autoconf, make, libraries, you name it) so why are we so nice on the compiler front? Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: compiler warnings, -Werror, etc.
On Sat, Jul 28, 2012 at 4:45 PM, Dan Winship d...@gnome.org wrote: By that logic, you should never pass any extra -W options beyond -Wall either, since those warnings apparently aren't important. http://en.wikipedia.org/wiki/Material_implication_%28rule_of_inference%29 is not invertible like that. :p Don't we have build bots somewhere? They could check this stuff... lots of other projects do that. (Having a build-warning-detecting bot would also help for the case where the warning only shows up with -O2, but the developer compiles with -O0 for ease of debugging...) We're GNOME, we don't do QA. ;) This is actually the core of the problem. If we had a buildbot like for example WebKit, we'd have try bots that would compile with -Werror and would flag the commit before it's committed. Just like they would run make check and flock you for that. But instead, we're very laissez-faire. So much in fact, that we don't care about bugs that other people introduce when we're busy doing something else... The problem isn't old gcc releases, it's either older or newer gcc releases. If you want everyone to get the same warnings, you need to require that everyone use a specific version of gcc, and compile with the same optimization level. For random git checkouts, I would definitely favor doing that. Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: IBus/XKB integration
Marguerite Su i at marguerite.su writes: what if after one or two years, a brand-new IM comes. then you guys will remove all ibus codes and start what you do today again? and after another one or two years, again again. then it becomes you guys' life-time career to fix bugs and reinvent the wheels. Yes, that is exactly what I do. In fact, I enjoy it a lot to port to a new and better solution and making sure that solution works really well [1] than trying to be compatible with lots of different options. If one chooses a single target, one has a lot of advantages: - Tight integration is possible. - One can rely on certain behaviors of that target - New features can be used immediately - We have a single point of contact for discussions about the future Of course, this also requires a lot of things working well between that single target and GNOME: - A target that is working well for all use cases - A willingness from both sides to cooperate - A working relationship between the involved people You can find a lot of examples where this works very well [2] and of course I can also come up with some where it didn't work and we needed to change things and start over. [3] So what I think we as the GNOME project want to see happen is that we find a team that is excited to work with us on improving input methods in GNOME applications. [4] If that project is called IBus, fcitx, XIM or is something that is redone from scratch, I don't know. I also don't know if the project of choice will be ready as-is or will need significant improvements. I also don't consider myself the person to decide it. But I am very convinced about two things: We want a single solution. And we want you to be happy with it. Benjamin 1: If you want references, look at the GTK Cairo work I did. And that is now superseded by Clutter. You can also look at the transition from X11 to Wayland for an example of that. I'm pretty sure we will make a rather seamless transition at one point there and not try to support both. 2: Tight coupling of GNOME with X11, NetworkManager, WebKit or Pulseaudio improved things a lot. At least that's my opinion. 3: The big example of a failed relationship is with Mozilla. It failed once already (the Epiphany guys with GtkMozEmbed - they started over with WebKit) and the Javascript situation (gjs is based on Mozilla's SpiderMonkey) isn't very nice either. Another example that never worked out is spell-checking. Enchant was never really integrated into GTK and that is why you can't spell-check normal text entries... 4: As a GTK maintainer, I'm not happy about IM modules as they generally contain very ugly and often just look plain bad when they try to pop up their own little X windows in all the wrong places. I'd also be very happy if I could show more useful information than an underlined pre-edit string. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rotting patches [was: Re: Reviewed-By: and pastebins]
Andre Klapper ak-47 at gmx.net writes: Offtopic, but the obvious first step would be to improve the rate of reviewed patches in general. While peer reviews are great, **in some projects** teams miss manpower already to have reviews at all, without any peer. (And if you are a first-time contributor and you never receive feedback on your first patch you give up and won't know where to escalate. That's where GNOME's contributor base remains small.) I think Bugzilla is a terrible tool if you lack manpower, in particular if the manpower for a project is shrinking relative to the amount of bugs. I don't think Bugzilla was ever designed for the you take over a project, here's 1000 bugs as a head start, it'll increase by 50 every week case. Bugzilla works very well as long as you keep it in check, but once it grows too much and the necessary triage doesn't happen, you lose without a real chance to ever get it under control again. It's a bit like a zombie outbreak in that regard. Another thing is that Bugzilla is essentially a large TO-DO list. Those lists require a certain kind of mindset that is a given for every developer. I think a large part can work well with it, but there are some that just can't [2]. I am one of those people.[4] Because I don't keep a TODO list though, I'm not usually in the need to get anything done.[2] So you can just poke me on IRC and I there's a high chance I'll review patches if I know things about the code you're looking at. I might even fix a bug that you have, just because I know how. * gtk+: 637 unreviewed patches; 480 of them older than 12 months I'm these days the main developer of GTK with Matthias together. GTK has 2500 open bugs[1]. So it has passed the zombie outbreak state by now. So I don't look at bugzilla at all. I want to get things done. This means 2 things: (1) If you file a bug for something I broke, I'm not gonna know - unless Matthias (who's the only one triaging those 2500 bugs sometimes) throws it at me. (2) I'm not gonna care about bugzilla statistics, target milestones, bug severity or anything else people do in there. I have no idea how to improve that situation. The only possible solution I can even come up with is getting more developers to work on GTK - first learning the internals of the toolkit and then working on the bugs. But I have no idea where those people would come from. Benjamin 1: https://bugzilla.gnome.org/page.cgi?id=weekly-bug-summary.html 2: http://slobotski.wordpress.com/the-pmarca-guide-to-personal-productivity/ 3: http://www.paulgraham.com/makersschedule.html 4: A very sincere Thank You for that goes to both Red Hat and GNOME for adjusting themselves to work with me this way. It's not easy to work with someone who's so different than you are.[see also 3] This totally should not be a postscript, but it'd really confuse what I wanted to say above. Again, thanks. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Feature Proposal: Accessibility on by default
Colin Walters walters at verbum.org writes: I'm not talking about the implementation details of the toggling of the switch, but rather the fallout on the rest of the stack. So, here's a simple technical overview of how the a11y stack works for a GTK app (Clutter is similar). Imagine this as layers. 1) GTK 3 compile-time links against (*) 2) ATK may run-time load a plugin that is named 3) atk-bridge compile-time links against 4) libatspi talks over dbus with 5) libatspi compile-time links against 6) Orca You can easily see that there is a very brittle link between step 2 and 3. Toggling the switch to always-on would just mean we always load the plugin. The big advantage in that approach is twofold: A) a11y users don't have to hunt for the on toggle anymore which is one crucial step less in bringing up an accessible desktop. With that, we can also remove a lot of switch-toggling and -querying everywhere in our a11y plumbing. B) We know that the next step of linking everything at compile-time will not cause any fallout once we decide to do it. I suppose your proposed plan of try it and see what happens is about the best we can currently do given the state of our current technology, but I was wondering if you had any idea of what the results might be. As the plugin does not do anything when no AT is loaded, there should be no observable difference. Of course, that's the theory. And while theory and practice are the same in theory, we know they might not be in practice. So the goal is to find the bugs that the people running with a11y on (but no AT running) have not yet discovered and fix them in the next 6 months. Benjamin (*) GTK 2 does this linkage at run-time, too, using the gail plugin. But GTK 3 has integrated gail recently, so this step is already always-on. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gtk+ 3.3.7+ bugfix will BREAK Xorg (before 1.12) unless patch is applied
Here's a heads-up on this patch: We've held up on applying this patch to give developers a chance to get their servers fixed. But we want this patch in 3.4, so it has now landed. So if you are running a GTK = 3.3.19, you need to have an up to date X server or you'll see weird focus behavior. A workaround exists: If you export GDK_CORE_DEVICE_EVENTS=1, GDK will stop using XInput and use old-school X11 events, and that code path in the X server doesn't have that bug. Benjamin On Mon, Jan 9, 2012 at 8:11 PM, Olav Vitters o...@vitters.nl wrote: Company found a bug in the XI2 handling of GTK+. The gtk+ bugfix exposes a very visible bug in Xorg. The Xorg bug will be in Xorg 1.12. If you're responsible for a distribution, please either run 1.12, or ensure the fixes from freedesktop bug 44079 are applied to your Xorg *asap*. Reference: - https://bugzilla.gnome.org/show_bug.cgi?id=657578 - https://bugs.freedesktop.org/show_bug.cgi?id=44079 (not loading atm) In short: - in case gtk+ 3.3.x - ensure you have patch from https://bugs.freedesktop.org/show_bug.cgi?id=44079 - otherwise bad things happen (important focus events do not fire) In care you prefer IRC type announcements: Company seb128! Company seb128: is the next ubuntu gona have X server 1.12? seb128 Company, no seb128 1.11 Company seb128: because we want to push a bugfix for GTK 3.4 that exposes a pretty visible bug in XI2 that they recently fixed Company seb128: lemme link you up with the relevant bugs Company seb128: https://bugzilla.gnome.org/show_bug.cgi?id=657578 and https://bugs.freedesktop.org/show_bug.cgi?id=44079 Company seb128: we have't applied the GTK fix yet, we wanted to wait until GTK devs have a proper X to run on first :) seb128 Company, thanks, I will make sure we get that fix in our xserver Company great Company i should probably poke the relevant people for suse and mageia -- Regards, Olav -- devel-announce-list mailing list devel-announce-l...@gnome.org http://mail.gnome.org/mailman/listinfo/devel-announce-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkTable is deprecated
On Thu, Sep 29, 2011 at 6:30 PM, Johannes Schmid j...@jsschmid.de wrote: This is a massive change to existing GtkBuilder .ui files so I would suggest that somebody able to do xml and/or sed/grep magic would write a script that just replaces GtkTable with GtkGrid in existing .ui files. If that is included in gtk+ it would a lot of peoples lives easier. I am not sure that a simple script - and it'd probably be easy enough to get a simple one going with some XSLT - because you need to fix the expand and align flags of your widgets, and that means setting flags on completely different widgets in the widget tree. That transition is a thing I'd love to have seen tackled more by app authors btw, but so far it wasn't necessary, so nobody bothered. GtkBox and GtkTable didn't lose these flags in the transition to GTK3 after all. Also, keep in mind that UI files won't cause deprecation warnings during compilation. So unless you have code that live-edits tables, your code will still continue to compile and run fine for the time being. Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GtkTable is deprecated
Hey everyone, So now with GNOME 3.2 out, it's time to make GTK break builds again. So I deprecated GtkTable in GTK master[1]. GtkTable is turned more and more problematic as GTK 3 evolves and the implementations of height-for-width improved, which GtkTable does not support. So we were ending up with more and more bugs about tables allocating way too much space for widgets (feel free to ask the Empathy guys about it ;)). GtkGrid should be pretty much a drop-in replacement for GtkTable. Keep in mind that GtkGrid uses the align and expand flags of GtkWidget[2][3][4][5] instead of having expand and fill child properties. As always, should you have any questions, don't hesitate to ask. Happy hacking, Benjamin 1: http://git.gnome.org/browse/gtk+/commit/?id=08d578dfcbbbc4769d8c26de4ea0de4f76e1b2de 2: http://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-set-hexpand 3: http://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-set-vexpand 4: http://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-set-halign 5: http://developer.gnome.org/gtk3/unstable/GtkWidget.html#gtk-widget-set-valign ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v4)
Felipe Contreras felipe.contreras at gmail.com writes: That doesn't change the fact that everyone understands the word happy. http://www.ted.com/talks/daniel_kahneman_the_riddle_of_experience_vs_memory.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
More GTK breakage
Hey everyone, If you read this mail, it's probably because GTK made your compile fail. Again. It might be because the final part of the GTK3 rendering cleanup has landed. This part only touches GDK APIs, so most applications should not be affected at all. If your app has been affected nonetheless, it's often one of these issues: - GdkDrawable has been removed. In that case, just replace all occurences of GdkDrawable with GdkWindow and you should be fine. - The GDK_DRAWABLE() macro is gone. Oftentimes, it can just be omitted. Otherwise, you likely want to use the GDK_WINDOW() macro. - GDK_WINDOW_XWINDOW() is gone. Use the gdk_x11_window_get_xid() to get it. I'm transitioning all code to provide a gdk_x11_foo_get_xid() function exclusively, so futureproof code should use that function. - A few remaining calls (mostly in gdkx.h) that were called gdk_drawable_foo() are now called gdk_window_foo(). Most prominently gdk_x11_drawable_get_xid() is now called gdk_x11_window_get_xid(). As always, if you have any issues, feel free to poke me. Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Please ship changelogs in your tarballs
Dodji Seketeli dodji at seketeli.org writes: I personaly find ChangeLogs quite valuable for situations where people have the source packages (like a distribution DVD) but not necessarily an access to the internet and want to understand when/how something changed. I found myself in such a situation not very long ago and I was very happy to have a proper ChangeLog around. Hrm, in 90% of the cases where I need information about why changes were made, I need git blame/cvs annotate style output, and a ChangeLog cannot give me this information. (Also, the tools to filter ChangeLogs suck, or are there equivalents to git log -- $file?) So I think it would be a lot better if instead of just generating a ChangeLog, we would ship the full git history in the tarball. That way you have a history that is as useful as possible. It would also make GPL purists happy, because we'd ship it in the preferred form of making modifications, which a tarball isn't - even with a ChangeLog. Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
GTK3 breakage
Do you pine for the nice days of GTK 1.3, when men were men and wrote their own widgets? Are you without a nice project and just dying to cut your teeth on a desktop you can try to modify for your needs? Are you finding it frustrating when everything works on GNOME 2? No more all-nighters to get a nifty program working? Then this post might be just for you :-) As I mentioned a month(?) ago, I'm changing how GTK draws widgets. You got the first batch of changes with the deprecation of the GDK drawing routines. The second part of this rework has now landed in GTK3's master branch. With it, a few other changes that touch public APIs have landed or will soon land. This also means that almost all projects are now broken when trying to compile them against GTK3. We're going to look into fixing things next. The ongoing work is tracked on http://live.gnome.org/GnomeGoals/GTKRenderingCleanup - please add yourself there if you work on it. We expect this to be last big change to public APIs leading up to GTK3. Here's a summary of changes that have happened. If you want more details, the GTK API docs have an ever-expanding migration guide. It's a bit rough at the moment because we don't really know what problems people have. So please talk to us so we can expand it to disucss the stuff you don't understand. Matthias Clasen and me will work on updating the GNOME stack for GTK3 in the next weeks, so you know who to poke. - GDK lost GdkColormap and GdkPixmap The replacement for GdkPixmap is cairo_surface_t. Colormaps are an outdated concepts and are pretty much unused these days, so we decided to no longer expose them in the GDK API. - for GtkWidget the draw signal replaces the expose-event signal The new draw signal takes a cairo_t so you no longer have to create the cairo_t manually. All painting functions have been updated to take a cairo_t, too. And best of all, we now have a gtk_widget_draw() function that you can use to draw a widget to any cairo surface you want. - GtkObject is gone With the existance of GObject, GtkObject became unnecessary. The functions it provided are now either part of GObject or GtkWidget. - GtkSizeRequest is gone (GTK3 only) The newly introduced GtkSizeRequest interface has been merged into GtkWidget directly. All code that already took advantage of it, will need some adjustments in names. Happy hacking, Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: rendering-cleanup
Hi, my rendering-cleanup work is pretty much done now. I expect the branch to land in master during the next week while people (read: Matthias) pound on it trying to find issues. I've also deprecated as many APIs as is reasonable inside Gtk 2.22. So if you are compiling with GDK_DISABLE_DEPRECATED and find your module breaks, you need to update your drawing to Cairo (or disable the flag ;)). I'm still in the process of updating the documentation (read: it's missing stuff), so if anything is unclear for you, please poke me on IRC or by mail and I'll try to clarify it. In the meantime you want to read http://blogs.gnome.org/otte/2010/07/27/rendering-cleanup/ That page will become the basis of what will be the porting documentation. Benjamin On Thu, Jul 22, 2010 at 4:54 AM, Benjamin Otte o...@gnome.org wrote: Hi, As many of you have already noticed, I've been frantically hacking away on my Gtk rendering-cleanup branch[1]. The branch is an attempt to move all GTK drawing to Cairo and remove all the outdated APIs that exist for rendering, including, but not limited to: - GdkRGB - GdkImage - gdk_draw_*() - GdkPangoRenderer - GdkGC More things could be removed (GdkColormap and GdkColor.pixel come to mind), but those aren't urgent for 3.0 IMO, so I didn't remove them. I did do this because the task of implementing and maintaining such a complex rendering API as Gdk2.0 provides is a very daunting task and looking at the non-X11 backends also quite complex, while Cairo provides a much smaller API and has fallbacks for almost everything. The work is done and the code runs now. Well, at least testgtk and gtk3-demo do. On X11. I'd be happy if others could take it for a spin and find issues with it or even have a go at Quartz and Win32 code. Even though this is a huge amount of API that is removed - it's close to 30.000 lines of code including docs - there don't seem to be a lot of users inside GNOME. Most of the users are really old parts of the code and in those cases switching to Cairo should be a reasonably easy. In fact, a lot of the functions can be replaced using similar functions from Cairo in a copy/paste style. Also, I'd like to point out that no API was changed. I only removed functions. So a proper transition from Gtk2 using deprecations is easily possible. So what do I intend to do next? 1) Port some applications - the bigger users - to not use these functions anymore. That way I'll both review my branch and get some apps fixed. 2) Cherry-pick the cleanup work into master and gtk-2-22 3) Get an ok to merge the API cleanup to master (or at least partially) and deprecate related functions for 2.22. The work is tracked in bug 624255[2] and further discussions should happen there. This mail is just intended to make everyone aware of the effort and to answer any questions you might have. Also, I'm aware that we are very close to a release. I'd understand if that'd make people not want to merge it. But I think it's worth it and the impact is very small compared to the other changes in Gtk3. And last but not least, some diffstats: Whole patchset: 146 files changed, 2730 insertions(+), 29384 deletions(-) gdk/ subdirectory: 64 files changed, 590 insertions(+), 22215 deletions(-) This should prove that it's pretty much just removing code. gtk/ subdirectory: 37 files changed, 1866 insertions(+), 3373 deletions(-) Half of that is fixing the default style, the other half is updating widgets to use Cairo. Cheers, Benjamin 1: http://git.gnome.org/browse/gtk+/log/?h=rendering-cleanup 2: https://bugzilla.gnome.org/show_bug.cgi?id=624255 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: External dependency bump: Cairo 1.10
Since the Cairo 1.9.10 happened on time and it looks like Cairo 1.10 is well on schedule, I've gone ahead and pushed my changes. So Gtk 3 git master requires the most recent Cairo snapshot now. For more details on the change, see https://bugzilla.gnome.org/show_bug.cgi?id=613284 I'm about to update modulesets and the wiki page. Benjamin On Thu, Jun 17, 2010 at 9:33 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Thu, Jun 17, 2010 at 2:37 PM, Benjamin Otte o...@gnome.org wrote: Hi, I'd like to bump the Cairo dependency for 1.10 for Gtk 3. Cairo 1.10 adds a few features that I want to use in the public GDK API - most notably regions - and this change needs to be done while we can break API. Cairo 1.10 is not released yet, but is scheduled for release on August 16th. [1] Prereleases will appear every other week, the current one is 1.9.8. Can I request that we are a little cautious here and at least wait to see if 1.9.10 appears on schedule before trusting the roadmap ? Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Video Hackfest conclusions
Hi, As you may be aware, we held a video hackfest last week in Barcelona. Developers met to discuss how best to improve GPU support for video applications. See http://gstreamer.freedesktop.org/wiki/VideoHackfest for more details. In particular, you might be interested in the notes some people took while the hackfest was going on. These can be found at http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes What follows is the results we arrived at after the hackfest. They are taken from http://gstreamer.freedesktop.org/wiki/VideoHackfest/Conclusions but certainly deserve wide circulation. We're interested in any comments (or questions) you might have about them, so please don't heistate to reply. If you do reply, please make sure to reduce the recipient list appropriately. Cheers, Benjamin, on behalf of all hackfest paticipants. == YUV in pixman == It has been a goal for a while to make video a first-class citizen in the image stack. A concrete API proposal on how to integrate video into pixman was reached and reviewed. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/YCbCr_Formats * http://gstreamer.freedesktop.org/wiki/VideoHackfest/pixman Actions: * GStreamer developers to provide a specification of important YUV formats * Write implementation == YUV in Cairo == To make it easy for applications to use these different formats, the Cairo API needs to be extended to allow them. A proposal does exist and has been reviewed, details need to be finalized. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Cairo Actions: * Finalize proposal * Write implementation == locking in Cairo == GStreamer takes a lot of freedom in deciding which threads to schedule elements in. Most hardware backends however require proper serialization of commands. The current gst-plugins-cairo and gst-plugins-gl code provide different, but ugly ways to achieve this. Cairo's internal thread safety guarantees match these requirements very well. But the different Cairo backends don't always keep these guarantees. Interaction with these locking mechanisms from outside applications is not possible yet either. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Cairo Actions: * Improve Cairo backend implementations, in particular X11 and GL * Expose Cairo's locking API to allow interaction with it * Write testcases to squash bugs == locking in Mesa == The GLX specification does not allow binding the same GLX context in multiple threads at the same time. This is a requirement for both Cairo's and GStreamer's threading model. An extension was proposed and initial code developed to support this requirement in the same way as Apple's GL does by default. Windows does not support this and would require potentially expensive fallback code. Links: * http://people.freedesktop.org/~anholt/MESA_multithread_makecurrent.spec Actions: * Get review for suggested extension and include it in future Mesa releases * Make Windows developers investigate the situation == switch GStreamer to Cairo as default video transport model == The current approach to handling video in GStreamer is very outdated. It does not allow hw-accelerated buffers nor does it provide a unified API to modify video buffers, which leads to fragmentation and duplication. It was agreed that using Cairo to provide an abstraction as a drawing API and abstraction over different backends was a good idea. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes * http://cgit.freedesktop.org/~company/gst-plugins-cairo Actions: * Rework gst-plugins-cairo to match improvements listed in previous points * Get more review on API and to avoid regressions * Merge into gst-plugins-base * Switch plugins gradually to use new Cairo code == gst-plugins-gl == The general consensus was that gst-plugins-gl is a hack. It was necessary in the past to get things to work, but is not a good way forward. However, the functionality or performance provided by the current elements needs to continue working. Developers shared the opinion that gst-plugins-cairo with cairo-gl surfaces is the best way to achieve this. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes Actions: * Get review of cairo-gl/gst-plugins-cairo code from gst-plugins-gl developers * Port gst-plugins-gl elements to use Cairo early to ensure required features are available == XRenderPutImage == Currently there is no way to upload video data to the X server for later use. The XV extension is not sufficient for anything more complicated than a simple video player. Links: * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Cairo Actions: * Figure out the best way to move YUV data into hw-accelerated Cairo surfaces (GL vs X) * Possibly draft an extension to XRender to handle this in the no-GL case == JIT in Pixman == ORC was investigated as a potential JIT for pixman. A lot of talk has happened, but no clear conclusions were reached. The idea to share a
Re: libproxy as external dependency
pros: - current proxy handling in GNOME is a huge mess, we're all lucky we can live without proxies - the API looks extremely sane - there is nothing else that does proxying - Dan (who is going to be the main - or only? - user of it) likes it - active maintainers - no bugs cons: - I'm (luckily) not too knowledgable about proxy handling - not a lot of users Considering that all cons I can come up with aren't their fault, this has to be a +1 from me. Cheers, Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Swfdec external dependency
Hey, now that we've released Swfdec 0.8.0[1] I updated swfdec-gnome to use it[2] and did a new release of it. I've updated the wiki page[3] already. Due to lack of time I did not update jhbuild etc though. Cheers, Benjamin 1: http://lists.freedesktop.org/archives/swfdec/2008-September/001944.html 2: http://mail.gnome.org/archives/release-team/2008-July/msg00176.html 3: http://live.gnome.org/action/edit/TwoPointTwentythree/ExternalDependencies ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Swfdec version for 2.24
Hey, As Swfdec tracks GNOME development and provides a new major release for every new GNOME release, we will release Swfdec 0.8 to go with it. I hope updating the external dependencies is fine here. Today Swfdec 0.7.4 was released and I updated the swfdec-gnome package to not depend on Swfdec 0.6 anymore but track the 0.7 releases. I've updated the jhbuild moduleset accordingly already. Cheers, Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: minimum cairo dependency
Matthias Clasen matthias.clasen at gmail.com writes: It was pointed out to me that http://live.gnome.org/TwoPointTwentythree/ExternalDependencies still lists cairo 1.2.6 as minimum version. I recently bumped the cairo dependency in GTK+ 2.13 to 1.6 (it already was at 1.5.2 before). I think we should bump the minimum required version of cairo to 1.6.0 for Gnome 2.24. Matthias I'm still hoping or user font support in the next Pango version, which would require Cairo 1.8. I have no idea about the release schedule for future Cairo/Pango releases though. Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Reintroducing critical warnings?
Havoc Pennington hp at pobox.com writes: Wait, that's the whole point is to crash the app The issue is that if it just prints stuff, people don't fix the bug (in part, perhaps, because nothing goes through bug-buddy). Maybe the fix is to bug-buddy the warning, but don't crash the app. Not sure how hard that would be to code. I guess this is the age-old question of How should we treat a non-critical bug during development? And I guess it is equivalent to Should we enable gcc's -Werror switch for svn builds? which is the question I regularly clash about with Behdad. In the end it's a tradeoff. A tradeoff between forcing users to make you care about potentially harmless stuff that's not a real bug (to quote Behdad) and missing real bugs because users don't care about bugs that don't bite them. It's also a tradeoff between allowing you to be lazy and not fix warnings immediately - or at least until the next gcc comes around that makes them real bugs - and having to fix obscure warnings on weird platforms immediately because they break the build or prevent the application from running. I'm all for making warnings fatal and compiling with -Werror in svn builds. But you'll have a hard time convincing other people. Cheers, Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Swfdec: required external packages
On Jan 29, 2008 6:16 PM, Luca Ferretti [EMAIL PROTECTED] wrote: Il giorno mar, 29/01/2008 alle 01.10 +0100, Benjamin Otte ha scritto: Additionally, we want to track Swfdec git master from swfdec-gnome until 0.6 is released. Is that ok - in particular with the jhbuild people? ??? I looked into jhbuild and external deps are always tarballs. So I was wondering if there was a policy against depending on development versions for external deps. It's a bit more work for jhbuilders after all. Otherwise I'd update the modules to depend on Swfdec git until 0.6.0 is out. Cheers, Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Swfdec: required external packages
I've just parsed the external dependencies for 2.22 [1] and noticed some issues relating to swfdec-gnome. 1) Swfdec version The Swfdec version has been set to 0.5.5. However, we plan to do a 0.6.0 release for Gnome 2.22 (see [2] for details). Additionally, we want to track Swfdec git master from swfdec-gnome until 0.6 is released. Is that ok - in particular with the jhbuild people? 2) shared-mime-info version Listed is version 0.22, however version 0.23 contains an important fix for Flash file detection that's necessary for roughly 95% of Flash files. So it'd be nice if that version would be bumped, too. Cheers, Benjamin [1]: http://live.gnome.org/TwoPointTwentyone/ExternalDependencies [2]: http://lists.freedesktop.org/archives/swfdec/2008-January/001131.html ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module decisions for 2.22
Brian Cameron Brian.Cameron at Sun.COM writes: Section 3a seems of the Adobe SWF and FLV File Format Specification License Agreement seems to be pretty clear that the specification does not allow additional client programs, players, etc. to use the format. Even if this has been implemented by reverse-engineering or clean-room techniques, then this may require some legal review to ensure that this was done appropriately to avoid legal issue down the road for GNOME. Has this been done? I'm aware that this specification exists and that the Swfdec developers are not allowed to use it. Which is what we have done. However, I am not a lawyer, so I cannot say if that restriction is legal, nor if not reading that document is enough to not cause problems. So in short: Nothing has been done. If you think this is necessary and want to do that, feel free to contact [EMAIL PROTECTED] or me. I'd be very happy if I could answer this question with a lawyer has told me ... the next time it comes up. Cheers, Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: swfdec-gnome
On Dec 27, 2007 8:34 PM, Andre Klapper [EMAIL PROTECTED] wrote: so i assume that using the gstreamer backend has been fixed in the latest swfdec release? Yes. Swfdec is using GStreamer by default for video and audio decoding now (and has been for the last 2 releases). Cheers, Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: swfdec-gnome
Bastien Nocera hadess at hadess.net writes: Hey Benjamin. I think that using GStreamer for playback would be a must for swfdec to be accepted as a blessed dependency (and thus swfdec-gnome added to the desktop). We've been through not allowing other playback engines in the past, so I don't think we can let swfdec change that position. I hope you can work with the GStreamer guys to get the technical problems sorted out. Having bugs filed or discussions started on mailing-lists about the problems you've seen would also help the community see that efforts are being made in that direction. To keep you guys updated: After some discussion with Wim it seems there is a completely different solution for the GStreamer backend that works fine with current releases. I'm pretty confident that the GStreamer backend will work perfectly in the next Swfdec release. Cheers, Benjamin PS: Bastien, Fedora is still the only distro not shipping Swfdec... ;) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: swfdec-gnome
Peter Gordon peter at thecodergeek.com writes: Unfortunately, swfdec's dependency on ffmpeg/libmad for multimedia decoding means that it cannot intrinsically be part of some distributions such as Fedora without being hosted in a third-party repository of some sort; and the current Gstreamer stack in swfdec does not work nearly as well as does ffpmeg/libmad. For one, YouTube videos (from my very brief testing with 0.5.3) play without sound and often freeze the X session entirely. :( Would this mean that its Gstreamer support would be heavily improved or perhaps even become the main playback focus for videos? That would be *awesome*. :) The current GStreamer has some serious issues with the way Swfdec wants to use it. I'll gladly go into details about why, but I guess this is the wrong place to discuss this. The solution the GStreamer guys did for this was appsrc/appsink, however there's no release yet which uses it, and it looks like the next release will not have it either. So in short: Yes, we'd like to improve GStreamer decoding options, but it's just not possible. Benjamin ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposal: swfdec-gnome
Hi, I'd like to propose swfdec-gnome for inclusion into the GNOME 2.22 desktop. Swfdec-gnome is a recent addition to the Swfdec project [1]. Its purpose is integration of Flash files into the Gnome desktop. It currently provides a thumbnailer and a playback application for local files similar to the stand-alone application Adobe ships on Windows. It is supposed to replace the support that is currently provided via the Swfdec 0.3 GStreamer plugin/Totem. This would of course add an external dependency on the Swfdec library. The Swfdec library itself does not depend on anything that is not already part of Gnome. In fact, it uses Glib, Cairo, Pango and Gtk plus optional dependencies on GStreamer/FFmpeg/Mad for video/audio decoding and ALSA/OSS for audio playback. Currently swfdec-gnome is hosted in our git repo on Freedesktop and uses its bugtracker, but I would prefer moving it to Gnome SVN and using its bugtracker for ease of integration with the Gnome project. This should also not be a problem because almost all developers of Swfdec are already Gnome developers. On to some Q/A for questions I imagine you people asking: Do you really think Swfdec is mature enough to be used as an Adobe Flash substitute? I would be very (some say overly) careful about making that statement. However, this proposal is not about a substitute for the Flash player in your browser. It is about better support for the Flash files on your desktop. Currently there is almost no integration for these. They are played back and thumbnailed with an older version of Swfdec through Totem and this solution is definitely far superior than that. Isn't swfdec-gnome a bit young? Its git log looks like it's only a week old? In fact, all these applications already existed as part of the Swfdec source tree for over a year, they just weren't installed. We only recently took the work to split them off to be able to make them really GNOMEy without having loads of GNOME dependencies in the core library. Cheers, Benjamin [1] http://swfdec.freedesktop.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
