Re: Gjs Lang.Class uses __proto__ to change function prototypes?
On Thu 18 Apr 2013 20:16, Nikita Churaev lamefun@gmail.com writes: newClass.__proto__ = this.constructor.prototype; where newClass is a function. Why does Gjs do this? Isn't this non-standard? ES6 will standardize __proto__. Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
kind note on quoting
Hi, There has been a lot of traffic on d-d-l recently. That's great. It's a bit difficult to follow though, at times. It would be really helpful to a casual reader if, when replying, people would trim the parts of the mails that they are quoting. Cheers, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Attention anyone uploading binaries to ftp.gnome.org/pub/binaries - understand the GPL
On Thu 22 Sep 2011 16:17, Colin Walters walt...@verbum.org writes: Ige-mac-bundler copies all of the files you indicated in your bundle file, and also pulls in the dependencies it can find, and it adjusts the install paths to reflect the new locations. [...] You need to list the corresponding source code for *every one* of these libraries. Otherwise we have no idea - it's whatever version of gtk+ etc. happened to be installed on your workstation. You should be able to take a jhbuild checkout and run jhbuild snapshot to generate a jhbuildrc for the exact sources you have checked out. You can use that to tar up the corresponding source. It might have bitrotten, but I wrote it for this purpose. Cheers, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Launching an application requires too many mouse clicks in Gnome 3
On Sun 04 Sep 2011 08:31, Xavier Cho fender_ru...@yahoo.co.kr writes: On a side note, I really like to see kind of a 'switchable' dock so I could change set of applications on it according to task currently I'm on. For example, when I do some music related work, I often use jackd related applications like ardour, hydrogen, lv2rack and etc. Though other times, I don't want those icons to clutter my dock, as I rather want to have more general set of applications at hand, like a web browser and a terminal, and so on. That does sounds like a workflow that gnome-shell doesn't serve well right now. Probably the best way to support it is via an extension, though. Andy -- http://wingolog.org/ ___ 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)
On Fri 19 Aug 2011 13:33, Felipe Contreras felipe.contre...@gmail.com writes: That's a reasonable alternative. How about pleased? Any other people have an opinion? You present yourself as reasonable by adjusting on the small points, but you ignore the feedback of greater importance. My opinion is that you are not the right person to lead an effort to gather feedback on GNOME. The Git survey, AFAIU, was done _with_ the git developers. This one, if you manage to bully it through, will be _in spite of_ the GNOME developers. It will not have the effect you desire. Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: IRC channels in gnome development
Hi Alan, FWIW I mostly like GNOME 3, so I don't want to pile on the flamefest. But this bothered me: On Sun 06 Feb 2011 15:27, Allan Day allanp...@gmail.com writes: Even if you had records of every discussion, you wouldn't get the information you're looking for. Design decisions don't get made committee meeting style, and design involves a lot of specialist background knowledge which doesn't get explicitly referenced. Fact is, we'll probably never be able to give 100% of the rationale behind design decisions. The thing is, we've done mostly well in the programming department. If the subtext is this is the case for design in contrast to programming, I would like to disagree; that would be unjust both to programming and to design. Often programming is just as solitary an affair, yet we manage to communicate in such a way that enables collaboration; and surely programmers are not more socially competent than designers ;-) Likewise designers don't work alone. I'm sure you have been one of two or three or six designers sitting at a table hashing things out. In neither profession do things happen committee meeting style -- when things go well, of course! -- but there is collaboration. This characterization of design also neglects the great community design work that has been done recently by Máirín, for example, and done to an extent within GNOME. Finally, it's rare that a programmer never does design work, or for a designer never to code at all. We all need pointers and records to figure out how things are done. Of course it's not always possible! But it would be an error not to hold transparency up as a goal, IMO. It simply isn't true to say that we haven't made an effort to explain what we're doing. I explained many of the design considerations in my blog post [1] on this subject, and I did that precisely because I wanted to help people to be informed. For this, and all your awesome work, thank you! Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Mon 31 Jan 2011 14:59, Murray Cumming murr...@murrayc.com writes: - there is no stronger API/ABI rules, but it's true we'd like to have gtkmm follow the schedule. I am also surprised at the lack of rules here, and additionally, the lack of discussion. Without the rules, it's just languages that people like or see as strategic for some reason, and is disrespectful of those bindings that chose to follow the 2.x bindings moduleset. (Guile was not one of them, FWIW.) GNOME has done really well with libraries. It would be good to continue to extend this rigor to language bindings. Regardless of the ultimate decision -- NB, not being discussed at language-bindi...@gnome.org -- the lack of communication from the release team is lamentable. Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Moduleset Reorganization -- Take two
On Mon 31 Jan 2011 22:03, Frederic Crozat f...@crozat.net writes: 2011/1/31 Andy Wingo wi...@pobox.com: Regardless of the ultimate decision -- NB, not being discussed at language-bindi...@gnome.org -- the lack of communication from the release team is lamentable. And this kind of attitude is the best way to ensure people will leave release-team.. I'm sorry, that was not my intention at all. You all are doing a lot of great work. As for myself, I'm doing none; so apologies there, and kudos to you. However, there was a procedure in place before. Murray headed it up. It seemed mostly sensible, though a bit strict. Change is fine, but it seems like we're just slipping into it instead of choosing it; at least that's my perspective, as a bindings author. Best regards, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: libpeas
Hi Steve, On Mon 04 Oct 2010 13:10, Steve Frécinaux nudr...@gmail.com writes: I'd like to propose libpeas as part of the desktop release set, or whatever the release team cooked to replace it in Gnome 3.0. Libpeas sounds really neat :) Did you solve the toggle refs issue that Owen brought up? Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Update of libchamplain version in external dependencies
On Thu 19 Aug 2010 13:09, Jiří Techet tec...@gmail.com writes: right now libchamplain has the version number as a part of its name, e.g. libchamplain-0.7.so. If you encode a version into the name, use the stable version. If 0.7 is a stable series, use -0.7 in the name. Otherwise if it is a development series, use 0.8 or whatever the next stable series will be -- as GTK+ does. A -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
Greets :) A couple points of clarification: On Wed 14 Jul 2010 21:45, Christian Persch c...@gnome.org writes: [In] copyright assignment, you don't have *any* guarantees about the terms the new 'owner' may choose to distribute your work under. Not true! For example, when you assign to the FSF, the papers you sign contain a number of guarantees. From an old version of the assignment papers (you should contact the FSF if you are considering using this language, as it might have been updated): 4. FSF agrees that all distribution of the Works, or of any work based on the Works, or the Program as enhanced by the Works, that takes place under the control of FSF or its agents or successors, shall be on terms that explicitly and perpetually permit anyone possessing a copy of the work to which the terms apply, and possessing accurate notice of these terms, to redistribute copies of the work to anyone on the same terms. These terms shall not restrict which members of the public copies may be distributed to. These terms shall not require a member of the public to pay any royalty to FSF or to anyone else for any permitted use of the work they apply to, or to communicate with FSF or its agents or assignees in any way either when redistribution is performed or on any other occasion. Also, even if you do consider or later versions a significant risk, you should note that you've *already taken* this risk by using LGPL2.1-only, since LGPL2.1 allows using the work under GPL2 or any later version of the GPL. Interesting, I was not aware of this. From the LGPLv2.1: 3. You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library. To do this, you must alter all the notices that refer to this License, so that they refer to the ordinary GNU General Public License, version 2, instead of to this License. (If a newer version than version 2 of the ordinary GNU General Public License has appeared, then you can specify that version instead if you wish.) Do not make any other change in these notices. The LGPLv3 does not have that parenthetical statement. I don't know if that changes things. Josselin mentions the risks that might arise in specifying an or later license. They are real, but can be mitigated via the proxy clause in the (L)GPLv3. If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program. Happy hacking, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (L)GPLv3
Hello, On Tue 06 Jul 2010 14:54, Holger Berndt bern...@gmx.de writes: On Tue, 06 Jul 2010 09:00:09 -0400 Ryan Lortie wrote: On Tue, 2010-07-06 at 09:26 +0200, Vincent Untz wrote: Do you feel okay with the idea of allowing proprietary apps to use our platform but not GPLv2 apps? In short, yes. Anybody who has an application that is GPLv2-only and has accepted enough contributions that it has become an unreasonable proposition to relicense has made a significant mistake. With my GNU maintainer hat on, I agree with Ryan here. The problem is not only with third-party apps that use the platform. There are also some significant GPLv2 only libraries that GNOME apps may want to use. As examples, Poppler and ClamAV come to my mind. Incidentally, this is one of the major reasons that GNU PDF was made a high priority project by the FSF: besides implementing a broader subset of PDF, but to have it be LGPLvN+. Currently N is 3 for GNU PDF, but also currently I hear poppler does a better job at what it does. A number of GNU libraries are now LGPLv3+, FWIW. So basically, if Evince wants to use Poppler, it could not legally use a library (be it directly or indirectly) that is LGPLv3 (or later). Using LGPLv3 or later for platform stuff sounds like an explosive situation to me. Agreed that it would cause some inconvenience, but there are fewer of these cases than there were. Still, given that GLib is not breaking ABI, it doesn't seem that LGPLv3+ is an option for it. We should however (IMO) promote GPLv3+ for applications, where possible. Regards, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call to maintainers: GNOME 2.31 to ship GTK 2.90
On Mon 14 Jun 2010 12:57, Sebastien Bacher seb...@ubuntu.com writes: Le lundi 14 juin 2010 à 11:38 +0100, Bastien Nocera a écrit : That's not a decision for the software writers to make when their code is in the GNOME release. Why would GNOME tell software writers that their code can't have build time options to use either gtk2 or gtk3? People can do what they like of course, and I recall back when GStreamer used to compile against GTK+ 1.2 or the GObject in 2.0. But from a bug management perspective, having to always ask what GTK+ a user has compiled against is complicated, and they might not always know if the dependency tree is deep -- and in just such a case, a maintainer will sometimes find that the user inadvertantly linked against 2.x /and/ 3.x (due to transitive dependencies). It's not the last word, but there's definitely something to be said for reducing the configuration and bug space by requiring a specific ABI. Cheers, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module decisions for 3.0
Hi Vincent, On Wed 02 Jun 2010 01:38, Vincent Untz vu...@gnome.org writes: + gjs (desktop) = approved, but with other bindings (not desktop) Does this mean that gjs will follow API/ABI stability guarantees of other parts of the GNOME platform, or of the old Bindings releases? Cheers, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
Hi Mikkel, On Thu 22 Apr 2010 21:40, Mikkel Kamstrup Erlandsen mikkel.kamst...@gmail.com writes: Here's what we do. We set a series of milestones and target bugs and blueprints to these milestones. We also attach branches (not patches) to bugs and blueprints. When a linked branch is ready to merge into another branch (trunk or other) we add a merge request, which enables the review system. It's not as slick as launchpad, but have you tried bgo's splinter? One can push git branches to bugzilla, and review the patches on the web, with a quite acceptable interface. Just a data point :) We create sub teams and sub projects that all have different rights and responsibilities. So basically we use pretty much all aspects of a modern project hosting solution. Bugzilla is just a bug tracker. Obviously you have to do what's best for you, but I have found it best to rely on a more flat technical rights division -- for example, either you're in the project or you're out, and most people that want to should be in. Rights and responsibilities can in many cases be managed better on the social level, with trust. This also allows people to migrate to different areas of resposibility over time. YMMV, of course. Happy hacking, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3 cleanup status update
Hi Tomeu, On Thu 14 Jan 2010 16:29, Tomeu Vizoso to...@sugarlabs.org writes: Pygi is still far away from being an usable replacement of static bindings, at the current development rate. Why is that? Is the gobject-inspection metadata not expressive enough, or does pygi not implement all that gobject-introspection can express? Just curious, Andy -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Rise of the Plugins
Hi, On Thu, 2007-05-17 at 18:26 +0200, Vincent Untz wrote: Plugin vs extension? [...] My €0.02: I think that people are getting used to the Extension term, and it sounds less geeky. Extension has the advantage that there's only one way to spell it (as opposed to plugin vs plug-in). A minor point, Andy. -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Keyboard quagmire
Hey Calum, On Thu, 2006-08-17 at 16:41 +0100, Calum Benson wrote: I'd appreciate it if you read through the parts of the a11y guide [3] that apply Wow, nice link. I wasn't aware of this document. Thanks! Andy. -- http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hi, On Mon, 2006-07-24 at 16:11 +0100, [EMAIL PROTECTED] wrote: parallel-instabllable is the worst idea of software development. See http://ometer.com/parallel.html for the reasons why GNOME does it this way. Regards, -- Andy Wingo http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Memory consumption and virtual machines
Hi, On Mon, 2006-07-17 at 10:57 +0200, Philip Van Hoof wrote: Please do not reply to this message on the mailing list. Please don't pontificate. Your holier-than-thou tone is tiring. -- Andy Wingo http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Gnome 2.15.4 is broken
On Wed, 2006-07-12 at 22:36 -0400, Joseph E. Sacco, Ph.D. wrote: [gtkmm breakage with new gnome-vfs] Turns out to be caused by the bonobo changes in gnome-vfs-2.15.3 This happened to the python bindings as well, and likely will happen for other bindings... -- Andy Wingo http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Re:Mono bindings a blessed dependency? [Was: Tomboy in 2.16]
Hi Federico, On Thu, 2006-04-20 at 16:17 -0500, Federico Mena Quintero wrote: I mean, nobody can live without solitaire card games, and so we pull in Guile [if not the GTK+ bindings [are they still alive?]]. Not the gtk bindings, no. The gtk bindings are on life support anyways (http://gnu.org/software/guile-gnome/) Cheers, -- Andy Wingo http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: requesting official list of modules and versions for GNOME 2.14
Hi, On Sat, 2006-02-11 at 14:29 +0800, James Henstridge wrote: Christian Fredrik Kalager Schaller wrote: It is possible to run for instance 'gst-inspect-0.10' in the postinst script to force the registry rebuild. Will that remove the overhead for all users, or just the user who runs gst-inspect-0.10? Just that user -- so that's probably not a good idea (ie when does root run media apps?). Multi-user systems will have a startup penalty for each user. Regards, -- Andy Wingo http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: requesting official list of modules and versions for GNOME 2.14
Hi, On Fri, 2006-02-10 at 16:18 +0800, James Henstridge wrote: Ronald S. Bultje wrote: - for every cvs up of gstreamer, my totem (or any app) still takes 10s to startup with no visual feedback This is plugin registration, right? Is it possible for distributors to trigger plugin registration as part of their package post-install scripts, or is every user of a system required to go through this after installing updates? When GStreamer 0.10 starts, it recursively scans the directories in your plugins path for changes. Normally this is just $prefix/lib/gstreamer-0.10, so just one directory, they're all plugins, the disk activity isn't too bad. Depending on your machine it might take a couple seconds to get everything registered. I'd be very surprised if it took 10 seconds to register an installed GStreamer. Running from CVS is another question, because then it has to scan a very deep directory structure. This takes considerably more time. Maybe 4 seconds on my box. This price is only paid by developers working from their uninstalled copies, though. There is no way to manually rebuild the registry in 0.10, so no more post-installation hooks are needed in distro packages. Regards, -- Andy Wingo http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: requesting official list of modules and versions for GNOME 2.14
Hi me, On Fri, 2006-02-10 at 10:04 +0100, Andy Wingo wrote: Depending on your machine it might take a couple seconds to get everything registered. Hm, I should clarify before the flames arrive: in the normal case, when the mtimes of the plugins haven't changed, and the set of plugins didn't change, then the registry is not rebuilt. So the normal case is that the user perceives no delay when starting their program. Ciao, -- Andy Wingo http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GStreamer version for 2.14
Hi Vincent, On Mon, 2006-01-16 at 22:42 +0100, Vincent Untz wrote: Well, the question is: is GStreamer 0.8 totally unmaintained? Yup. I had understood that Ronald was planning to make a new release with some fixes, so that's why I proposed to not close the bugs. I don't know what Ronald's plans are. Regards, -- Andy Wingo http://wingolog.org/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
