Re: Mirroring GNOME on github
2012/8/7 Jasper St. Pierre jstpie...@mecheye.net: The other alternative is telling everyone that files a pull request this is not the appropriate mechanism for contributing back upstream, even politely, is a turn-off. Are they going to make the effort to register at Bugzilla and learn how to use git-bz? I don't think so. Or you could make GitHub the preferred way to contact devs of some modules and keep the GNOME git as an auto-sync'd mirror. The question is whether the freedom is more important than productivity of course. -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome goals for 3.6
2012/5/16 Matthias Clasen matthias.cla...@gmail.com: Sometimes you can eliminate the markup by doing something like s = g_strdup_printf (i%s/i, _(fallback mode)); /* Translators, %s stands for 'fallback mode' here */ msg = g_strdup_printf _(Unfortunately GNOME 3 failed to start properly and started in the %s), s); Please don't as fallback mode then has 90% probability of using a wrong grammatical case (ie. nominative). -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: 3.6 Feature: Initial setup
W dniu 24 kwietnia 2012 02:32 użytkownik Danielle Madeley danielle.made...@collabora.co.uk napisał: I sort of like the idea of a totally fresh GNOME session starting up with a Web and www.gnome.org/welcome/ in the browser, with lots of little YouTube videos. That could be useful and unobtrusive. I hope the first video is how to install Flash so I can watch the rest of the videos ;) -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Dealing with GTK 3.3.18 scrolling handling changes for GNOME 3.4
W dniu 16 marca 2012 13:33 użytkownik Sebastien Bacher seb...@ubuntu.com napisał: Le 16/03/2012 12:56, Bastien Nocera a écrit : So gtk_widget_add_events (widget, GDK_SCROLL_MASK); for every widget for which we want the old behaviour back, correct? Sounds doable by 3.4. Well old behaviour back, you will still not get GDK_SCROLL_UP,DOWN events so any code checking for those will need updating. Shouldn't that be the case unless you explicitly ask for GDK_SMOOTH_SCROLL_MASK? -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 3.4 Blocker Report
W dniu 9 marca 2012 19:15 użytkownik Matthias Clasen matthias.cla...@gmail.com napisał: http://mclasen.fedorapeople.org/fail-whale-fail.png Haha, last time I got that I assumed it was an artifact caused by a bug in nouveau. -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME user survey 2011 (v6)
On Tue, Oct 18, 2011 at 6:34 PM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: Iirc the fallback mode is using new gtk and stuff... why is it obsolete? AFAIK the goal was to only maintain it until the very last graphics chip in use was able to run shell. It's not there as a preference, it's a fallback mode for unsupported hardware. I was asking looking at the anger and nostalgie expressed on phoronix. Phoronix is a tabloid seeking sensation. They feed on flames, FUD and “scandals” so their readership is far from being average end users. It's not the crowd you can cater to as whenever you “fix” one “problem” they will quickly find a new thing to hate. -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Features !
On Thu, Oct 6, 2011 at 11:30 AM, Siegfried-Angel Gevatter Pujals siegfr...@gevatter.com wrote: 2011/10/6 Martyn Russell mar...@lanedo.com: Or, similarly to how mac did it? does it? using a jumping icon or changing the colour or some notification which is subtle. With an icon appearing in the top (like the battery icon) which allows you to use your contacts (favourite or recently communicated with and have access to the contacts app/dialog), that would be a nice way to avoid needing the roster entirely generally. You could see notifications grouped there. You mean something like this? https://wiki.ubuntu.com/MessagingMenu?action=AttachFiledo=gettarget=messaging-menu.png Please, no catch-all menus in GNOME 3. This is systray all over again except that it's vertical now. -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Online Accounts extensibility
On Thu, Oct 6, 2011 at 7:40 PM, David Zeuthen zeut...@gmail.com wrote: I. Adding support for a provider P, currently means making code-changes to all of the GNOME apps using its services.. because most of the time standard standardized protocols are not in use. For the few cases where it uses a standard protocol (such as XMPP and IMAP/SMTP) we could support pluggable providers. For example, we could, presumably, read plug-in files from some directory so we could list 200 different XMPP chat services or 200 different IMAP servers. That that no-one ever heard about. But would we want the user to see this? The answer is: not in GOA. Can't we just have an option that says Other Jabber/XMPP provider and allows me to enter my JID, the server name, password, port etc.? It would cover most of people's needs even if they need to ask the provider for details (that they have to provide anyway). Most importantly it would mean not using two configuration windows, one of which not showing anything other than Google and the other saying that some accounts could not be configured here. The current state of affairs leads to confusion (I had to explain that to a live person, I failed because I did not have any sensible arguments). Same could probably be done for IMAP/POP3/SMTP. -- Patryk Zawadzki I solve problems. ___ 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, Aug 19, 2011 at 1:17 PM, Felipe Contreras felipe.contre...@gmail.com wrote: Are you serious? That totally and completely speculative and unrealistic. Have you ever participated in making a survey? I have, as I have explained, for the Git survey. In my experience, only the people that want to help in some way do spend the amount of time required to fill the survey. Could you at least make the answer options less emotional? Like exchange happy for satisfied etc. I don't remember answering ecstatic in the Git survey but that could be my bad memory. -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Feature Proposal: Backup
On Wed, May 11, 2011 at 1:57 PM, Milan Bouchet-Valat nalimi...@club.fr wrote: Why not just ask the user when performing a new backup in case there's not enough space left? Since DéjàDup already does full backups from time to time, it could notice the user that in order to backup new data, s/he needs to get rid of older versions until the date of a full backup (chosen so that just enough data can be freed to make the new one). That way, we can get rid of the somewhat scary setting How long too keep backups. And if you're not there it will passively let you lose data :) How long to keep backups should really be named something like how many copies to keep with possible options such as just the last one, entire last month or eleven most recent ones. -- Patryk Zawadzki I solve problems. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
On Tue, Jan 4, 2011 at 9:14 AM, Christopher Roy Bratusek zang...@freenet.de wrote: On Tuesday 04 January 2011 04:56:32 you wrote: On 01/03/11 19:33, Christopher Roy Bratusek wrote: ... above you said GNOME is about freedom, so now you differ between *this* and *that* freedom, that's not a very straight-line king to argue, if you ask me. You're talking about your denied freedom for you as a user to enslave the GNOME developers, aren't you? No, about that no user can see the reason why you are taking *their* freedom (or in your words: you first took our freedom, period). GNOME was always modular, so there's no point in demodularizing it, just because you want the user to be forced to use something. Tell you what: I'm not thrilled about Shell either. I don't like some of the technology choices, I don't like some of the design concepts. But unless you're going to provide code patches, better designs and other resources, please stop complaining. It's like standing in the middle of the street and yelling we should all be rich. Saying so won't make it happen. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
On Tue, Jan 4, 2011 at 11:59 AM, Sergey Udaltsov sergey.udalt...@gmail.com wrote: This modularity prevents to create a solid user experience in various ways because everything needs to be compatible with random components that cannot even be tested properly. I cannot believe I am reading this on GNOME central mail list! Is this the same GNOME that helped to improve WM standards (to NETWM and beyond) so that people could use different WMs? Is it the same GNOME that helped to establish freedesktop.org with all those cross-DE standards? Are you implicitly saying that GNOME does not believe in cross-DE standards anymore? GNOME already effectively dropped cross-DE systray, right? Now, WM mobility is gone. What's next, dare I ask? These standards are there to make sure GNOME *apps* are first-class citizens in other DEs ( vice versa). It has little to do with being able to play mix-and-match with core desktop components. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: My thoughts on fallback mode
On Tue, Jan 4, 2011 at 7:25 PM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: It would be like releasing a new car and then telling the buyer that the tires that are included aren't good enough but that's okay because they are free to go through the trouble of replacing them right after they take ownership. Modularity is not a feature; a good feature is a feature. You wouldn't be a very good car salesman then would you ? In fact people loathe and hate the lock-ins wired into cars. Plus of course the first thing anyone does when they get into a car is umm Adjust the mirros Adjust the seats Adjust the music Adjust the airconditioning Adjust the satnav Fit random personal objects (modularity) ... I'd like to use a random bluetooth hands free, sorry our car is only available with our official hands free option radio, ours only satnav, ours only engine management, ours only, DRM protected and we sued the other guys I need snow tyres, sorry we don't support snow tyres, you don't need them. To be fair, current GNOME situation is more like I previously owned a large Ford van and I demand you make this piano fit into my new Lamborghini. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-panel gnome-applets?
On Mon, Dec 27, 2010 at 3:42 PM, Sandy Armstrong sanfordarmstr...@gmail.com wrote: On Sat, Dec 25, 2010 at 1:34 AM, Frederic Crozat f...@crozat.net wrote: for nvidia, gnome-shell is not usable with proprietary driver What do you mean by this? Every time I've tested on nvidia hardware with the proprietary driver, shell performance has been totally usable. It's not lightning fast, but I don't think any hardware change would fix that. Here both nvidia binary and nouveau are usable to the point where you have 2-3 full-screen windows open. Then it starts to slow down exponentially with each window you keep open. I've tested this on GeForce 8600M GS and an older Quadro (can't give exact model as this computer is in my office). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: gnome-spidermonkey?
On Fri, Dec 10, 2010 at 7:01 PM, Colin Walters walt...@verbum.org wrote: Hey, Comments from people creating operating systems derived from GNOME would be appreciated here: https://bugzilla.gnome.org/show_bug.cgi?id=636977 Basically, I'd like a gnome-spidermonkey package which uses *exactly* the same sources as upstream, just with a renamed .pc file etc., for the reasons listed in the bug. If you object or have comments, let me know. Maybe we could re-evaluate using libv8? *hides* -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bump gnutls requirement
On Fri, Aug 20, 2010 at 5:42 AM, Brian Cameron brian.came...@oracle.com wrote: If you are going to update it, why not to the latest 2.8.6? I think he means minimum version with proper support for TLS certs. Latest would be 2.10.1. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 10:08 AM, Patryk Zawadzki pat...@pld-linux.org wrote: The long term plan for the GNOME applications that were removed from the Desktop, Admin and Dev Tools modulesets is to simply highlight the high-quality applications using the GNOME platform through our communication channels (release notes, website, etc). There will be no official apps anymore and no 'Applications' moduleset in the GNOME releases. The goal here is be more open with the app developer community around GNOME and to highlight all the nice things that can be created using our platform. And this might do the exact opposite of what we all want it to do. Instead of sending a you are now all equal message it might communicate that you are now equally not worthy. Or just you are now on the same level even if the level of integration and sheer polish is nowhere to be compared. It will also kill the magic moment I experienced twice - once when I helped Daniel with Cheese and a second time when hacking on Hasmter with Toms. The moment that comes after weeks of mad hacking when you decide your work is finally good enough to become part of GNOME. Forgot to mention: not having a single release schedule will also make it very hard for app authors to propose, track and depend on features of the underlying platform or - even worse - features introduced in other apps. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 7:54 PM, Jason D. Clinton m...@jasonclinton.com wrote: We are all active members of the GNOME Community and we know which apps are popular and are included by default in different distributions. We all use different distributions which choose different defaults; each distribution was well-represented by members of the Committee at the Zaragoza hackfest a few weeks ago. In short, the Marketing Committee is well-positioned to understand which apps to highlight in release notes, videos and brocures, for example. It should be the other way around. Applications that are already popular don't need showcasing and embracing. It's those unknown little gems that need the marketing polish to really shine. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Modulesets Reorganization
On Wed, Jun 2, 2010 at 8:32 PM, Stormy Peters sto...@gnome.org wrote: On Wed, Jun 2, 2010 at 12:26 PM, Patryk Zawadzki pat...@pld-linux.org wrote: It should be the other way around. Applications that are already popular don't need showcasing and embracing. It's those unknown little gems that need the marketing polish to really shine. Well known in our community and well known in general are two very different things. I have yet to meet anyone without a computer related job or interest in free software that knows what GNOME is. If we want them to use GNOME, it's even more important that they know our applications and those brands are even less recognized. (I did run into a GIMP fan the other day. Someone not in the free software world. He converted his whole work place from Photoshop to GIMP.) Decoupling the apps from the desktop could very well end in some of them pursuing their own communities. On the other hand GNOME brand will become even less relevant to an end user — to average Jane in the street GNOME Desktop would constitute nothing more than a wallpaper as only developers know the complexity of the underlying machinery. I hope we won't end up with just a clone of http://gnomefiles.org/ (which I assume could use some help from the Foundation and could then serve as GNOME's official showcase). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versioned symbols for 3.0?
On Sat, May 22, 2010 at 6:11 PM, Josselin Mouette j...@debian.org wrote: Le mardi 18 mai 2010 à 12:32 -0400, Behdad Esfahbod a écrit : As for not wanting to use versioned symbols, could you provide more information why such a decision was made? I can't speak for Matthias, but I guess it's because no one pointed out what currently-existing problem exactly it's trying to solve. The use case that Patryk mentioned is a bit RPM-specific. As Emilio explained, DEB-based distros have other mechanisms to cope with this, and AFAIK Gentoo isn’t really affected by versioning issues. What deb-based distros do now is a workaround, basically doing the same thing from the other end. Having symbol versions upstream would remove the necessity of doing the mapping manually. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versioned symbols for 3.0?
On Wed, May 19, 2010 at 11:05 AM, Alexander Larsson al...@redhat.com wrote: On Tue, 2010-05-18 at 20:30 +0200, Patryk Zawadzki wrote: - It can only version functions, we still have have unversioned types, properties, signals, etc, etc. It's only able to version exported symbols and I wouldn't ask for anything more than that. I didn't mean to propose dropping the API documentation, just making our lives a little easier. That makes it useless though. If an app uses a new signal but not a new symbol then symbol versioning won't detect that a new glib is needed, so you can't trust it anyway. Also, many times apps rely on e.g. a newer version of glib fixing an issue with a function. That doesn't make the function new so it won't get a new version (typically), so again the symbol versioning isn't enough. The problem we encountered recently is that glib itself introduces new symbols to binaries compiled with 2.24. That is compiling an older application with 2.24 causes it to depend on new symbols introduced in 2.24. For example the g_malloc_n. Also, IMHO stating that introducing an _additional_ safeguard does not solve 100% cases does not render the safeguard useless. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Versioned symbols for 3.0?
Today Elan Ruusamäe and me spent some time making glibc compile with
versioned interfaces for exported symbols.
The ultimate goal is being able to automatically detect at link time
that program A requires library B implementing at least version X of
the interface and embedding such information in packages
automatically. Just like we do for glibc with its GLIBC_x_y
interfaces.
The changes required for glibc was:
1) removing the -export-symbols-regex ^g.* passed to libtool
2) adding -Wl,-version-script=libglib-2.0.ver to libglib_2_0_la_LDFLAGS
3) creating the .ver file
A sample file (marking just one symbol as GLIB_2_24 for demonstration
purposes) looks like that:
- 8 - - - - - - - - -
GLIB_2 {
global:
g_*;
local:
*;
};
GLIB_2_24 {
global:
g_malloc_n;
} GLIB_2;
- 8 - - - - - - - - -
The resulting objdump:
- 8 - - - - - - - - -
...
00049770 gDF .text 0039 GLIB_2
g_option_context_get_help_enabled
000508c0 gDF .text 0180 GLIB_2
g_random_double_range
000377b0 gDF .text 0184 GLIB_2
g_key_file_get_boolean
00016820 gDF .text 0005 GLIB_2 g_byte_array_unref
000398c0 gDF .text 0032 GLIB_2 g_list_position
00030330 gDF .text 003f GLIB_2 g_io_channel_ref
00044810 gDF .text 006d GLIB_2_24 g_malloc_n
...
- 8 - - - - - - - - -
And in turn we can track the required interface versions while
maintaining an ABI-stable library. Another useful feature of
introducing versioned interfaces is being able to become
ABI-complatible while breaking API compatibility (you .symver g_foo at
GLIB_2_24 to call g_deprecated_foo and remove the g_foo symbol from
GLIB_2_26).
I'd like to propose adapting versioned symbols across the stack as
soon as possible. Keep in mind it'll probably break the existing ABI -
didn't test that yet - so as soon as possible might mean during the
nearest ABI break.
--
Patryk Zawadzki
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versioned symbols for 3.0?
On Tue, May 18, 2010 at 5:33 PM, Johannes Schmid j...@jsschmid.de wrote: Hi! The ultimate goal is being able to automatically detect at link time that program A requires library B implementing at least version X of the interface and embedding such information in packages automatically. Just like we do for glibc with its GLIBC_x_y interfaces. The changes required for glibc was: 1) removing the -export-symbols-regex ^g.* passed to libtool 2) adding -Wl,-version-script=libglib-2.0.ver to libglib_2_0_la_LDFLAGS 3) creating the .ver file A sample file (marking just one symbol as GLIB_2_24 for demonstration purposes) looks like that: Are you talking about glibc or glib? It's a bit confusing to me... glibc already provides versioning info for its symbols. I used glib-2.0 as an example but I'd love to see these in all the platform libs as they tend to have long cycles of ABI compatibility while introducing new symbols with each version. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versioned symbols for 3.0?
On Tue, May 18, 2010 at 5:31 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Tue, May 18, 2010 at 11:28 AM, Colin Walters walt...@verbum.org wrote: On Tue, May 18, 2010 at 11:24 AM, Patryk Zawadzki pat...@pld-linux.org wrote: I'd like to propose adapting versioned symbols across the stack as soon as possible. Keep in mind it'll probably break the existing ABI - didn't test that yet - so as soon as possible might mean during the nearest ABI break. There are no plans to break ABI for glib. And neither are there plans to start using versioned symbols. Good news then. The command: LD_PRELOAD=./.libs/libglib-2.0.so.0 gcalctool ...seems to suggest that ABI is maintained (that is apps compiled before continue to work after the change). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versioned symbols for 3.0?
On Tue, May 18, 2010 at 6:25 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 05/18/2010 12:12 PM, Patryk Zawadzki wrote: And neither are there plans to start using versioned symbols. Good news then. Did you misread what Matthias said maybe? I assumed it was because of the possible ABI break so I pointed that was not the case. As for not wanting to use versioned symbols, could you provide more information why such a decision was made? -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versioned symbols for 3.0?
On Tue, May 18, 2010 at 6:32 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 05/18/2010 12:30 PM, Patryk Zawadzki wrote: As for not wanting to use versioned symbols, could you provide more information why such a decision was made? I can't speak for Matthias, but I guess it's because no one pointed out what currently-existing problem exactly it's trying to solve. The most important to us as a distribution is being able to automatically maintain dependencies for libraries that add symbols without changing their soname. For example g_malloc_n was introduced in glib 2.24. We currently need to manually test each app linked to glib to find the minimal glib version needed because just depending on the soname is not enough. We could rely on application maintainers providin correct versions in the configure files but 1) that's not always the case and 2) glib's very own macros can introduce new dependencies at the compilation time (for example after we upgraded to glib 2.24 g_malloc_n was introduced to a number of applications that compiled and worked with older glib releases). On the other hand we don't have to do this for glibc as rpm automatically extract interface versions and glibc automatically gets these provides: libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) ... libc.so.6(GLIBC_2.12) Now if a package uses a symbol from a versioned interface, rpm will automatically add Requires: libc.so.6(GLIBC_2.6) without us having to search through the history of API changes. I imagine the same thing can be done (or already is done) for other packaging solutions (deb, autopackage, zeroinstall etc.). The not so important feature is being able to deprecate symbols and _remove them from the public API_ without breaking ABI. This can be achieved using the __asm__(.symver ...); call and aliasing a symbol under the old name in the old interface version (you still need to keep the code but you get to keep the ABI). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versioned symbols for 3.0?
On Tue, May 18, 2010 at 6:49 PM, Tristan Van Berkom t...@gnome.org wrote: It looks to me like your script is going to need somebody to maintain it in the long term (like one of those annoying extra files you want to shoot the GTK+ build system for, i.e. gtk.symbols or such). Do you have a full proposal of how the script's generation will be automated ? It can be generated using the same means the documentation uses to list symbols introduced with each release. In fact it would be perfect to keep those in sync so you don't have to update it in two places. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versioned symbols for 3.0?
On Tue, May 18, 2010 at 7:43 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Tue, May 18, 2010 at 12:58 PM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: If we autogenerate the version script, I think Matthias can be bribed into accepting it Well, the arguments against symbol versioning have not really changed since ca 2005, so we do we need to discuss this again ? Please kindly point me to a list of arguments as I was not a participant in that discussion. - It doesn't really work the same way on any other platform AFAIK it works on Linux, (Open)Solaris, and various BSDs. It's not supported on Windows but that doesn't stop it from being useful to distributions. - It can only version functions, we still have have unversioned types, properties, signals, etc, etc. It's only able to version exported symbols and I wouldn't ask for anything more than that. I didn't mean to propose dropping the API documentation, just making our lives a little easier. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Versioned symbols for 3.0?
On Tue, May 18, 2010 at 9:33 PM, Matthias Clasen matthias.cla...@gmail.com wrote: On Tue, May 18, 2010 at 2:30 PM, Patryk Zawadzki pat...@pld-linux.org wrote: Well, the arguments against symbol versioning have not really changed since ca 2005, so we do we need to discuss this again ? Please kindly point me to a list of arguments as I was not a participant in that discussion. I don't really feel like doing too much of the googling work for you, but here are some pointers: http://www.airs.com/blog/archives/300 http://www106.pair.com/rhp/parallel.html http://markmail.org/message/cycj43j6wciyzjj5 I've seen the first and the third but I still don't see the cons. Again, I don't propose dropping the current best practices (padded structs, ABI versions in soname and whatnot), just adding something that would make packaging easier for us distros. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Mon, Apr 26, 2010 at 2:01 AM, Cody Russell brats...@gnome.org wrote: Eh, github's pull requests are not really the same as a code review system. At least last time I looked at it. You do a pull request and the person you're requesting basically just gets a message that says, Hey dude, check out my awesome code! There isn't a nice UI for doing the code review, with diffs that can be commented on and whatever. Uhm, you're supposed to review commits. You get a pull request (or just stumble upon a fork of particular interest) and go to view related commits. Each commit allows you to review each and every line of code. It even seems that's where gitorious got their UI from. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module Proposal: Zeitgeist
On Sun, Apr 25, 2010 at 7:59 PM, Curtis Hovey sinzui...@verizon.net wrote: My suggestion is to support the Zeitgeist's community's culture of code reviews. GNOME does not have an official code review tool. Neither does GitHub, which is why projects that host in GitHub also use Launchpad for code reviews. Actually this is not true. GitHub lets you review any commit and the usual workflow is fork → commit → request pull → get review. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GtkNotebook scrolling usability
On Thu, Mar 11, 2010 at 2:01 PM, Carlos Garnacho carl...@gnome.org wrote: Hi! :), On mié, 2010-03-10 at 16:50 -0600, Cody Russell wrote: So, right now GtkNotebook allows you to change tabs by using the mouse wheel. Once I noticed this and the more I thought about it, it really seems like a terrible feature and one that may be detrimental to usability. I may understand not all notebooks need this feature. Perhaps we could have a MDI mode in GtkNotebook, so features such as mouse wheel scrolling and tab switching on alt+number are effective on these? (The latter isn't done in GTK+ itself yet, but is featured by most multitabbed apps) Good idea. Maybe add the option to disable tab scrolling to the input configuration applet? I've witnessed people use the scroll wheel by accident. I've also done this myself while I was forced to work with a clickless wheel mouse. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On Ctrl+tab
On Fri, Jan 15, 2010 at 12:00 AM, Reinout van Schouwen reino...@gnome.org wrote: Op dinsdag 12-01-2010 om 20:01 uur [tijdzone -0500], schreef Jud Craft: Due to its ubiquity, the conflict is very evident in GNOME programs, where the behavior is completely different, even on the same Linux operating system - between Epiphany and Firefox, Empathy and Pidgin, Anjuta and MonoDevelop as examples. I'd like to point out that it's up to Firefox, Pidgin and co. to behave like good citizens on the Gnome desktop. Not the other way around! Yes, be good citizens and behave like gedit. No, wait... ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Proposal: What's new
Hi guys, girls, men and women ;) I've already briefly mentioned the idea in the past but never really proposed it here. The idea is to add another option called What's new to the Help menu in all GNOME applications. As the name suggest it would contain a Grandma-Readable™ changelog. This means something closer to the release notes than to Fixed #123, foo shouldn't dereference NULLs in foo::frobnicate(). Goals? Two really. One - to make it easier for users to discover newly introduced features. Two - to make it easier to write GNOME release notes. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: What's new
On Wed, Nov 18, 2009 at 10:34 AM, Sven Herzberg he...@gnome-de.org wrote: Am Mittwoch, den 18.11.2009, 10:12 +0100 schrieb Patryk Zawadzki: The idea is to add another option called What's new to the Help menu in all GNOME applications. As the name suggest it would contain a Grandma-Readable™ changelog. This means something closer to the release notes than to Fixed #123, foo shouldn't dereference NULLs in foo::frobnicate(). Goals? Two really. One - to make it easier for users to discover newly introduced features. Two - to make it easier to write GNOME release notes. Sounds like a nice idea, really. But then I'm facing this question: How do I specify version numbers in a grandma-friendly way? Do we expect granny to know about version numbers? Do we write those only for major and minor version changes (like six-monthly releases)? Do we call the single sections Changes since Spring 2009 (to avoid version numbers)? Yes, I was thinking about using GNOME release dates instead of version numbers. My father might know what Ubuntu 10.1 is but he'd certainly have no idea what GNOME version it ran (or even what GNOME is). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposal: What's new
On Wed, Nov 18, 2009 at 10:47 AM, Murray Cumming murr...@murrayc.com wrote: On Wed, 2009-11-18 at 10:12 +0100, Patryk Zawadzki wrote: Goals? Two really. One - to make it easier for users to discover newly introduced features. I don't believe that most people care much, partly because they don't upgrade that often. This would be clearer if we had real personas to talk about. People who do care generally find the release notes online already. Not really. A lot of people have no idea what GNOME is. They just launch the application (or rather click on a document and the app launches itself), see that it looks slightly different and sometimes get curious as to why it looks different. Several times in the past I've read through NEWS and ChangeLog files just to tell someone what the exact changes were. Two - to make it easier to write GNOME release notes. The UI clutter seems like a high price to pay for the slight possibility that this would help with writing release notes. I wouldn't call adding a _third_ option to the menu that usually contains Contents and About... clutter. Even if it is clutter, we can still add it as a section in the manual. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Window titles
On Sat, Nov 14, 2009 at 10:58 AM, Andrew Cowie and...@operationaldynamics.com wrote: What is the current correct behaviour for window titles? I'm working in something right now that manipulates documents; I could do: blah.xml blah.xml - Program Chapter Title Chapter Title - Program When I researched the HIG on this (some years ago, admittedly), the advice boiled down to what I wrote in our API documentation for Window's setTitle(), http://java-gnome.sourceforge.net/4.0/doc/api/org/gnome/gtk/Window.html#setTitle(java.lang.String) However, Judging by this screenshot I took of the window selector applet's popup list, we're all over the map at the moment (which is to say people are still doing their own thing, and whatever GNOME's policy is, it's not being enforced very well), http://research.operationaldynamics.com/files/andrew/WindowTitles_Screenshot.png It's never really been standardized, even the API docs above seem more like a hint than a requirement. It's also obvious that we're still getting dealing with the hangover from when someone thought it would be cool to have programs called Web Browser instead of Epiphany, etc — so we see some programs calling themselves Sound Reorder, some saying a document title / email subject (only), some saying path/to/filename.ext - Application, Inbox (1849 total) - Evolution, and permutations thereon. I think it makes most sense if document-driven apps (abiword, gnumeric, file-roller etc.) just show the document name while task-centric apps (evolution, transmission) show their purpose followed by a short summary (e-mail - 25 unread). Evolution's current behavior makes it a moving target. The window constantly renames itself each time you switch folders. IMHO it should only change the first part of the title when you switch from e-mail to calendar or address book. I must admit I'm worryingly tempted to do Document Title - Application. But I also know there was once a push to have only the shorter form along with the icons to identify application. But given the kill-the-icons meme that's suddenly turned up around here, it no longer seems a good idea to be de-emphasizing one's application's name. Only purely decorative icons were dropped, app icons and document icons are here to stay. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Appearance properties
On Tue, Nov 10, 2009 at 3:39 PM, Xavier Claessens xclae...@gmail.com wrote: What I find totally insane is to not leave the UI to change that. New settings is clearly not accepted by a large (majority?) part of users. Except ~5 devs, I see nobody happy with it. Um, it doesn't work that way. I'm happy with it but I'm not compelled to post about it. My girlfriend is either happy about it or she doesn't give a damn, she didn't post about it either. It always seems as if the majority was unhappy as the unhappy ones are generally the only people who write. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Appearance properties
On Tue, Nov 10, 2009 at 4:00 PM, Peteris Krisjanis pec...@gmail.com wrote: 2009/11/10 Patryk Zawadzki pat...@pld-linux.org: On Tue, Nov 10, 2009 at 3:39 PM, Xavier Claessens xclae...@gmail.com wrote: What I find totally insane is to not leave the UI to change that. New settings is clearly not accepted by a large (majority?) part of users. Except ~5 devs, I see nobody happy with it. Um, it doesn't work that way. I'm happy with it but I'm not compelled to post about it. My girlfriend is either happy about it or she doesn't give a damn, she didn't post about it either. It always seems as if the majority was unhappy as the unhappy ones are generally the only people who write. So because there are maybe majority of happy (and ignorant) users, we will ignore rather loud opposition to this change? Really nice way to deal with community. And you are attacking me because..? The only thing I did is point out a logic flow in the above statement (loudest == majority). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Module semi-proposal: gnome-shell
On Wed, Nov 4, 2009 at 6:49 PM, Sriram Ramkrishna sriram.ramkris...@gmail.com wrote: So I was checking to see how popular javascript is compared to the others. Javascript is much more popular than our other bindings except for C and Java according to this website: (and Python) http://langpop.com/ Yes, that's a great argument. Also, Mandarin is much more popular than English. What these pretty graphs don't show is the context. Me, being a webdev for living am exposed to JS on a daily basis. Not because it's a great language (it is nice indeed) but because it's the _only_ common denominator when it comes to front-end scripting. Now I'm not against embedding JS, just against silly popularity contests ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, Oct 27, 2009 at 4:56 PM, Shaun McCance sha...@gnome.org wrote: I get the impression that the focus is more on data storage than indexing these days. I respect what the Tracker folks are trying to do, but I just need a good indexer to enable full-text search in Yelp. Wouldn't it make more sense to have a system service available for such resources? Reindexing system help for each and every user seems a bit of an overkill. Back then, during my university years Visual Studio used to do this and often resulted in people locking themselves out of the network due to automatic quota policies ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Freeze break request] Nautilus: do not put a frame around images that have an alpha plane
On Tue, Sep 15, 2009 at 9:06 PM, Frederic Peters fpet...@gnome.org wrote: Jaap A. Haitsma wrote: Attached a patch that makes sure that images don't get a frame. Currently larger images than 128 pixels will always get framed, but this can look ugly (see attached screenshot) I know this is not a request for comments but wouldn't this give the (false?) idea to the user that it is mandatory to click on an opaque pixel, while the frame indicated it was ok to click anywhere? 1) We prelight icons on hover. 2) It doesn't seem to be an issue for images below 128x128 and they currently have no frame. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GlobalMenu Application for inclusion as a GNOME module
On Thu, Sep 3, 2009 at 12:44 PM, John Stowersjohn.stowers.li...@gmail.com wrote: On Thu, 2009-09-03 at 00:40 +0200, Pierre Slamich wrote: Dear GNOME maintainers, This is a proposal on behalf of the GlobalMenu developers for its inclusion either in gnome-applets or as a dependency of GNOME. +1 from me, I use this daily, and it works wonderfully. While some might argue that the GTK_MODULES implementation is hacky it works well in practice. Unless you ever want to use an MPX-enabled X server of course ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GlobalMenu Application for inclusion as a GNOME module
On Thu, Sep 3, 2009 at 3:39 PM, Ted Gouldt...@gould.cx wrote: On Thu, 2009-09-03 at 12:58 +0200, Patryk Zawadzki wrote: Unless you ever want to use an MPX-enabled X server of course ;) I don't understand. Why is MPX incompatible with Global Menu? As Xi2/MPX allows you to have one focus per input including being able to focus two windows at a time (each with its own menu bar). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, Aug 18, 2009 at 2:57 PM, Luis Medinaslmedi...@gnome.org wrote: On Tue, 2009-08-18 at 13:05 +0100, Martyn Russell wrote: hal = 0.5 Is there plans to replace HAL by GIO or devicekit ? Hal will be deprecated soon afaik. ...or rather by libgudev, there is no such thing as DeviceKit :) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, Aug 18, 2009 at 5:18 PM, Jamie McCrackenjamie.mccr...@googlemail.com wrote: The indexer part is optional The main part tracker-store is just a database with querying and is to be used by zeitgeist If the consensus is that indexer is not suitable for inclusion then the separate tracker-store should be considered for inclusion separately the store does not do any indexing or file monitoring nor does it cosume significant resources Couldn't you just make gio (or gedit or OpenOffice) notify you every time it closes a file instead of monitoring bazillions of files? I'm not very likely to search for files I've never opened anyway. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, Aug 18, 2009 at 5:23 PM, Lennart Poetteringmzta...@0pointer.de wrote: Uh, generally bugs should be fixed, not worked around. Especially if they are as crucial as this one. Sure but getting a recursive inotify will likely take years as with most kernel features (= development time + significant adoption time). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: tracker
On Tue, Aug 18, 2009 at 9:21 PM, Lennart Poetteringmzta...@0pointer.de wrote: More real life examples: - show me all the party pics - give me files and data related to gnome bug #123 - list all the files I received from Lennart during the last week (over Jabber, e-mail etc.) Nice idea, but is this even realistic? How's a UI for this supposed to look like? I mean, Google is so awesome because you type stuff in a text field with only a minimal syntax requirements and will spit out useful stuff. But how would you expose in the UI a search mask that allows you to formulate queries like give me files and data related to gnome bug #123? Are you planning to duplicate the bugzilla search form in the GNOME Search interface? If that's the case, then www, stop right there! Of course these are realistic. Just let people dig for data *in context*. Instead of providing one interface to rule them all let eog show me the contact I got the picture from. Clicking the contact could open the contact properties from the address book with a list of recent conversations and recent files received. We've already improved a desktop experience. But wait. Did any other people take part in these recent converstions? Show these as well, let me click them too. Perhaps one of the conversations was tagged, show me the tag. *Click* - here's a window containing a list of stuff tagged as foo. Oh, one of them is a song. Clickety click and it's now playing in Banshee (Rhythmbox) where I can see Never gonna give you up was tagged as foo and bar and performed by Rick Astley. Click, here are other songs by this dude. I think the key is here is displaying all this data in the correct context, not taping some search box on top of GNOME. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tracker, Zeitgeist, Couchdb...where is the problem ?
On Tue, Aug 18, 2009 at 10:48 PM, Matthias Clasenmatthias.cla...@gmail.com wrote: I think this recent discussion about tracker as a gnome module is somewhat backwards. I don't think it is leading us anywhere to talk about ontologies and rdf and events and timelines and metadata stores and kernel apis before we answer the first question: What is the user problem that we are solving here ? Can that be described in a paragraph ? And if it can, is it something that a 'regular' user would recognize as a problem he has on his computer ? How about: Zeitgeist - provide means to find previously accessed data. Tracker - provide a well-defined (not just name=value strings but something close to an actual RDBMS) schema and service so desktop apps can provide context for the data they present (where did I get that file from?, is it related to any other files?, what other John Doe tracks do I have?). CouchDB - I have no idea why a desktop might need that. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Request for removing clutter in current form
On Mon, Aug 17, 2009 at 8:43 AM, Emmanuele Bassieba...@gmail.com wrote: it would be interesting to have a single place where the hardware support matrix was stored -- maybe on live.gnome.org or on freedesktop.org's wiki -- and updated. So let's do it then :) I own 3 laptops: an 4-y-o one that is both too slow and not supported (NV30 or NV40), a new one that is up to speed but not supported (NV50) and a netbook which is not supported (Intel Poulsbo) :) Although I don't complain as I hope nouveau will progress enough to support basic 3D operations in hardware (alpha-quality Gallium drivers are already there to play with but usually result in an X lockup). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [packagekit] Not proposing gnome-packagekit for 2.28
On Thu, Aug 13, 2009 at 10:25 AM, Richard Hugheshughsi...@gmail.com wrote: Quite a few people have asked me the same question... I do not want to propose gnome-packagekit for 2.28, but instead am intending to propose it during the 2.29 cycle. At this stage translated strings are still changing quite a bit, and lot of the UIs I'm unhappy with as they need quite a bit of redesign/polish. Also, quite a few distros have yet to write backends for PackageKit. Most of the few remaining distros are mostly in the process of writing, or discussing how to write, a backend. Well, now would be the time to propose it for 2.29, 2.28 is already in beta. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Signalling when the desktop is loaded
2009/8/11 Alexey Rusakov kt...@altlinux.org: В Втр, 11/08/2009 в 11:55 -0500, Cody Russell пишет: So I was talking briefly to vuntz in irc yesterday about wanting to have some kind of mechanism to find out when the desktop session is ready (ie, not once Nautilus and panel are launched, but when they are actually pretty usable and done loading stuff). In terms of the panel, vuntz suggested maybe adding a signal in panel_applet_queue_initial_unhide_toplevels() under org.gnome.Panel. In Nautilus there is FMDesktopIconView end_loading signal that seems to work well. What if I don't run Nautilus at the start of the session (don't use it to draw the desktop)? I mean /apps/nautilus/preferences/show_desktop GConf key. See below... It would be nice to have a single signal that could be emitted once both of these are finished, so I wanted to post here and see what others think and get suggestions on where this might be done. Maybe add a startup inhibit-like semaphore on the session interface so apps like panel and nautilus can get a lock on start and release it when they are done. Other apps would just wait for the no more lockers signal on the session interface. Bonus: we could share this interface with other freedesktop members. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: How to pause Vino?
On Sat, Aug 8, 2009 at 3:50 AM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: My goal (for my particular use case) is to make it possible for users to pause the server, take a private action not seen by the clients, and then resume public visibility. What would happen to input events during that time? -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: PyGTK global keybinding module
On Thu, Jul 16, 2009 at 3:43 PM, Matthias Clasenmatthias.cla...@gmail.com wrote: Global keybindings are a scarce resource, and need to a) be used sparingly (I strongly doubt that most of the apps that currently copy those libtomboy parts deserve a global keybinding...) and Sure, for example in hamster-applet we integrate with g-c-c keyboard shortcuts capplet... b) be centrally managed. We have a relatively nice infrastructure for that, with the keybinding capplet. Unfortunately, all the code that is copied around totally ignores that, leading to ugly conflicts and races when several apps try to use the same key combination. ...yet we still need to actually *bind* to the key the user chose for the action. For this we need the tomboy code. Binding and configuration are two separate problems. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: (Partial) GNOME 3 status update
On Wed, Jul 15, 2009 at 11:46 AM, Brian Cameronbrian.came...@sun.com wrote: Solaris continues to use gst-mixer since Solaris does not yet provide PulseAudio. PulseAudio doesn't provide as much value on Solaris since OSSv4 provides mixing functionalities directly in the OSS layer. Would introducing PA have any downsides? Having a common abstraction layer for sound would likely make it easier to develop portable apps. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME Showstopper Review
2009/6/19 Josselin Mouette j...@debian.org: Le jeudi 18 juin 2009 à 17:08 -0400, Matthias Clasen a écrit : GNOME-SESSION Exits when the system D-Bus daemon restarts http://bugzilla.gnome.org/show_bug.cgi?id=583345 Patch available. How is this a blocker ? I know that debian thinks it is a good idea to restart the bus, but everybody else pretty much agrees it is crazy to support that... I have yet to see a good reason to treat D-Bus differently from other daemons. It’s not as if it was complicated to reconnect to the daemon when it is restarted. The moment the bus disappears you lose all the clients. It's easy to get into an inconsistent state or lock yourself to a defunct desktop where nothing works and you are not able to log out. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Platform
On Mon, May 18, 2009 at 9:39 PM, Stefan Kost enso...@hora-obscura.de wrote: Now that apple has closed the whole bonjour stack, I would prefer to build on upnp. We have gupnp, which is actively developed and fitting nicely here. Now I don't want to make political statements, it's pure software engineering. Be it closed or open, we have a working Avahi implementation of the Bonjour stack. Also if you don't want streaming but only care about service announcing and discovery, Avahi is massively easier to use (and for example comes with nice python bindings). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libgdata as a new desktop module
On Fri, May 8, 2009 at 1:22 AM, Luis Villa l...@tieguy.org wrote: Lets not fall into the lazy trap of pretending that because something is no-cost that it is effectively the same as being libre-free (or even the same as being pragmatically open.) Or to put it a different way: feel free to argue for it as a necessary evil; that has been and will continue to be the kind of compromise that GNOME has to make sometimes. But please don't pretend that because it is no-cost that that somehow makes it OK. Please don't take it as rude but while we sure want to provide a fully open desktop, our users have to store their data *somewhere*. Be it Google (Docs, Contacts, Calendar, Picasa), Yahoo (Flickr) or DropBox. It's not like suddenly gnome.org will start providing all of these services. To me this case is not much different from allowing Rhythmbox to talk to iPods - they are proprietary, they require special handling, they cost you money but a whole lot of people own one. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposing libgdata as a new desktop module
2009/5/8 Josselin Mouette j...@debian.org: Le vendredi 08 mai 2009 à 10:32 +0200, Patryk Zawadzki a écrit : Please don't take it as rude but while we sure want to provide a fully open desktop, our users have to store their data *somewhere*. Be it Google (Docs, Contacts, Calendar, Picasa), Yahoo (Flickr) or DropBox. Please don’t take it as paranoid, but I think we should try to protect our users’ data instead of inciting them to outsource it to a handful of companies with no interest in protecting it. I am not sure what you are trying to say, I actually pay Flickr with real cash money to store my data there. We shouldn't go as far as to force or even encourage users to store their data with third parties but we certainly shouldn't forbid it either. I, for one, *do* want to use all of these services and can't see why GNOME should make it any harder :) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WebKitGTK+ as an external dependency
On Mon, May 4, 2009 at 8:58 PM, Luca Ferretti elle@libero.it wrote: 2009/5/4 Xan Lopez x...@gnome.org: snip I'd like to end the email by requesting feedback from all the module maintainers that are considering a switch to WebKitGTK+ Could be also good have a minimal feedback from distro packagers. I suppose that even though all relevant GNOME Desktop modules will be switched to WebKitGtk, distros will continue to provide Firefox as standard browser. So Fedora or Ubuntu, for example, will have to put both Firefox (default browser) and WebKitGtk (as HTML rendering library for Yelp Help Browser) in their install CD. But they have a constraint on size, 700MB. Due to this, Ubuntu don't provide the GIMP own help browser. That's so wrong it hurts. We should use technical measures to decide which deps go in. WebKitGtk is not a Firefox alternative. Firefox is a web browser that happens to include Gecko. Gecko (xulrunner) is a web kitchen sink - a set of parsers, a rendering engine, a JS engine and a completely new graphical toolkit - all designed with building web browsers in mind. WebKitGtk is a set of embeddable GTK+ widgets based on WebKit - designed with embedding in mind. It's actually easier to build a web browser with WebKitGtk than to embed Gecko in an application such as a web browser or an instant messaging apps. Of course it's my opinion and you are free to disagree with the above or you can raise valid concerns like a11y not being fully functional in WebKitGtk but please not judge software by their size (especially if Gecko is actually bigger than WebKitGtk even including the webinspector module). PS: 700 MB limit in 2009 is as good as a floppy :) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: WebKitGTK+ as an external dependency
On Mon, May 4, 2009 at 9:15 PM, Patryk Zawadzki pat...@pld-linux.org wrote: mind. It's actually easier to build a web browser with WebKitGtk than to embed Gecko in an application such as a web browser or an instant messaging apps. I obviously meant such as a help browser or an instant messaging app here ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: mailto: now all of a sudden necessary in DOAP file
On Sun, Apr 26, 2009 at 3:45 PM, Owen Taylor otay...@redhat.com wrote: Appended is a list of all modules with doap files failing validation as of this morning. [...] Invalid foaf:mbox property should be a mailto: URL == hamster-applet Fixed in http://git.gnome.org/cgit/hamster-applet/commit/?id=35a228da421606fb10377a992c8fa86fc8b9bf09 -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: mailto: now all of a sudden necessary in DOAP file
On Sun, Apr 26, 2009 at 3:45 PM, Owen Taylor otay...@redhat.com wrote: Invalid foaf:mbox property should be a mailto: URL == cheese Fixed in http://git.gnome.org/cgit/cheese/commit/?id=69e72603916b8873ec12a775fdc5f1cdf36d5a13 -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Planning for GNOME 3.0
On Mon, Apr 20, 2009 at 6:42 PM, Behdad Esfahbod beh...@behdad.org wrote: On 04/20/2009 12:37 PM, Tomasz Torcz wrote: Not the same. Fitts' law. Having Tomboy applet in border of screen makes it crazy big target to hit with mouse, which is good. Notification icon is many times harder to hit. The same story is now with Volume Applet. +10 to the concept. I lost my infinitely large volume control applet with the recent rewriting These days it takes me some five seconds to find it. To anyone who thinks I'm exaggerating, put the same set of icons on your screen for years and stare at the display 12 hours a day and they fade into the backgrounds. Takes lots of brain power to see them again... Whereas my hand knew how to find the volume applet by just throwing the mouse outward to reach the top-right corner and clicking. Also I'd argue that notification area should sort the notifications by app name or some similar parameter that does not vary between two logons. Currently these are in a completely random order (due to multitasking and ordering notifications by start time). It wouldn't be a problem if they behaved the way I believe notification area was originally designed to work (no permanent icons, dismissable notifications) but now I get between 4 and 7 fixed icons there so finding for example volume control takes some time. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: On autogenerated ChangeLog
On Mon, Apr 20, 2009 at 7:10 PM, Sebastien Bacher seb...@ubuntu.com wrote: Le lundi 20 avril 2009 à 12:17 -0400, Dan Winship a écrit : Who are these people who read ChangeLog Hi, The ChangeLog are quite handy for distribution packages, they have a list of the changes you can look at quickly and the closed bug numbers. Usually NEWS summary are either not there or listing only main changes in the new version and not enough to know what bugs you can close while doing the upgrade for example Exactly, very useful when adapting downstream patches (and before you go to kick my ass, there are various kinds of patches that can't and won't go upstream including various distro-specific path customizations at build time). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Adding module descriptions
On Fri, Apr 17, 2009 at 4:18 PM, Dan Winship d...@gnome.org wrote: Owen Taylor wrote: Thanks to Shaun McCance there's no need to worry about how to create a DOAP file, just find your module in: http://www.gnome.org/~shaunm/pulse/web/ And select the Download DOAP template file link to get a DOAP file for your module that you can then edit as necessary. It might even already have a good shortdesc if Pulse could find one from your .desktop file. Some examples of additional useful DOAP tags that pulse isn't (currently) generating but which people might want to add: download-page rdf:resource=ftp://ftp.gnome.org/pub/GNOME/sources/libsoup// bug-database rdf:resource=http://bugzilla.gnome.org/browse.cgi?product=libsoup/ mailing-list rdf:resource=http://mail.gnome.org/mailman/listinfo/libsoup-list/ DOAP has tags for describing source code repos too, but it doesn't seem to support git. Oops. I'd love to see an extension that lets you also list build- and runtime dependencies per release so I don't have to constantly re-read configure.am in vim every time a package is updated ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Adding module descriptions
On Fri, Apr 17, 2009 at 4:57 PM, Ross Burton r...@burtonini.com wrote: On Fri, 2009-04-17 at 16:38 +0200, Patryk Zawadzki wrote: I'd love to see an extension that lets you also list build- and runtime dependencies per release so I don't have to constantly re-read configure.am in vim every time a package is updated ;) No, you'd have to re-read the DOAP file instead... I don't really see what the gain here is considering the extra effort the maintainers would have to put into keeping the DOAP in sync with configure.ac. There's that small difference between searching for deps in: dependency context=build strictness=suggest package=libnotify version=0.1 / and: aclocal -I barbeque BARBEQUE_OMG([ponies = 1], [rainbows = 0]) ICANHAS(kthxbye) :) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Adding module descriptions
On Fri, Apr 17, 2009 at 8:38 PM, Pat Suwalski p...@suwalski.net wrote: Patryk Zawadzki wrote: aclocal -I barbeque BARBEQUE_OMG([ponies = 1], [rainbows = 0]) ICANHAS(kthxbye) WTF. Śmieszne. Been exploring the Mary Jane? At least some of the m4 macros look just like that: callouts to macros imported from aclocal customizations that affect the list of needed packages. You need to either remember which macros in what packages to check (aside from the obvious library and pkgconfig checks) or re-read the whole config.log every time a build breaks. The point is deps are not changed at random, the person merging code changes is the best person to update build deps. This is unfortunately not something you can always find in ChangeLog/NEWS. It makes little sense for me as a GNOME developer (inside jhbuild or garnome) but would be pretty useful for me as a downstream packager (with tons of .spec files to edit with every GNOME release). I agree this is slightly off topic and parallel to the git migration effort. I'll let the topic die here. But please: 1) don't top-post 2) avoid silly personal arguments :) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
top-post don't Please On Fri, Mar 20, 2009 at 5:55 PM, Matt Keenan matt.kee...@sun.com wrote: Ahhh... merci beaucoup :) On 20/03/2009 16:33, Vincent Untz wrote: [...] ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: bug-buddy integration
On Thu, Mar 12, 2009 at 12:28 AM, Brian Nitz brian.n...@sun.com wrote: Do we have a list of features missing from bug buddy so maybe we could direct some of this energy towards making it (or some standard community crash logger) meet community need and distro specific needs so we don't have every distro reinventing this wheel? I strongly believe we need two applications. A kernel-level crash logger (like apport) and a bug submitting tool like bug-buddy. The easiest way would be to make bug-buddy read apport's (or any other kernel crash logger's) format. Please note that since apport is system-wide (not user-specific and not limited to GNOME or even X11 apps) it cannot interact with bag-buddy directly. It also can't be adapted to use GNOME's format as KDE guys and (more importantly) system admins still need to be able to access the data. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: BugBuddy uselessness
2009/2/11 Tobias Mueller mue...@auftrags-killer.org: I'd say it'd be the best to remove that whole crash.gnome.org thing from bugbuddy as there is obviously nobody who is able to manage that platform. I assume that bugbuddy would then send to b.g.o only. I agree with dropping crash.g.o but I'd rather see app like apport replacing bug-buddy. If there are no debug symbols, let the downstream handle it (in case of PLD that would mean report a bug on Launchpad, some other distro might prefer to use Bugzilla or even send an email to some list). There are so many ways of configuring and compiling the same piece of code that a random core file without distro-specific data is next to useless. Also pushing stuff to downstream allows us to handle crashes in just any application, be it part of GNOME or not (many apps don't have an RPC-capable bug tracker). I think what we really need is not a GNOME-specific crash data collector (it's easy to do that using the kernel core_pattern pipe and we should steal that code from apport) but a gnome-packagekit-like architecture that integrates the bug reporting experience with the rest of GNOME (from saying oops, Nautilus crashed, report? to request a feature in Gnumeric). In other words: all crashes go downstream (if not resulting from local customizations, they can be easily forwarded upstream by the devs), all feature requests go upstream. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: devel-announce-list messages now appear on http://news.gnome.org/
On Mon, Jan 26, 2009 at 11:09 PM, Olav Vitters o...@bkor.dhs.org wrote: In an effort to make it easier to follow the GNOME release process, I've added the feed of devel-announce-list to http://news.gnome.org/. Could someone fix the news.g.o RSS link? It points to planet :) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.26 module inclusion discussion heats up
On Mon, Jan 19, 2009 at 11:21 AM, Rodrigo Moya rodr...@gnome-db.org wrote: On Fri, 2009-01-16 at 10:55 -0500, Matthias Clasen wrote: On Fri, Jan 16, 2009 at 8:27 AM, Rodrigo Moya rodr...@gnome-db.org wrote: yeah, I agree with you, I think both should be the same (an applet or an icon), so since we already have the applet, I guess it would make sense to add code to the applet to hide itself and start the notification icon if PA is running, or something like that But this is not a runtime decision. Either your distro is using pulseaudio (and it should), then you always want the new icon, or it isn't, and then you need something else. If you are using pulseaudio, you don't want to have an invisible mixer applet on your panel, eating resources and possibly causing other unwanted side effects. you're right about the resources taken by the hidden applet, but as you see, Debian, openSUSE and Mandriva need ways to offer users a fallback, so we really need it. If there's a better solution than hiding the applet, let's use that, but can't think of a better (and quicker) way right now Wouldn't it be easier to convert the old applet to also use a tray icon? This way no useless applet needs to stay in the memory (due to the fact applets have no programmatical way to add or remove themselves at run time). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME 2.25.4 released!
2009/1/8 Johannes Schmid j...@jsschmid.de: Hi Lucas! http://ftp.gnome.org/pub/GNOME/devtools/2.25/2.25.4/NEWS states that anjuta was updated without a NEWS entry. That's not true: http://svn.gnome.org/viewvc/anjuta/trunk/NEWS?revision=4535view=markup Is there anything wrong with the NEWS entry? I guess it's somehow parsed with a script. Once again: the NEWS script only looks for diffs from the previous release of *the same MAJOR.MINOR line*. As there was no previous 2.25.* anjuta release, there is nothing to diff against. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME DVCS Survey Results
On Mon, Jan 5, 2009 at 5:22 PM, Olav Vitters o...@bkor.dhs.org wrote: On Sun, Jan 04, 2009 at 06:34:47PM -0500, David Zeuthen wrote: On Mon, 2009-01-05 at 00:18 +0100, Olav Vitters wrote: I am not evading. Stop trying to make this personal. I don't care about CoC, I don't like you're talking to me. Please. Stop trying to make this look like it's personal and like I'm assaulting you. Because I didn't. And I resent the accusation. You ask Is it *really* so hard to understand that this whole git-serve is a terrible idea. As I don't find it terrible, the statement makes me feel like I'm considered an idiot for disagreeing. Then when I try to point that out, I get Oh, you chose not to quote that... anyway, I'm dropping this. Guys please both exchange a series of yo mama jokes in private then have a beer and shake your hands. It's obvious some of us get excited as it *is* a beauty contest we're participating in even if we paint it as a survey. It's normal and it's fine, just don't let personal taste win over GNOME. We're mostly engineers and we're here to build bike sheds, not to paint them. :) I really really like git but I couldn't care less if we switched to any of the things I picked over svn ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound effects
On Fri, Dec 12, 2008 at 3:00 AM, Iain i...@gnome.org wrote: Some thoughts on sounds. People don't use sound effects on the desktop. One of the first things many people do is turn them off. The only device I know where people don't turn them off is the iPod. We have a sound naming spec[1], yet no-one seems to care to design sound schemes for them [2] I think the reason for this is twofold: a) The sound naming spec specifies too many arbitrary sounds b) The sound naming spec defines so many sounds that it is nearly impossible to a sound designer to create meaningful sounds that differentiate between the actions The sound naming spec defines 125 sounds. That is 125 sounds for the user to learn the meaning of. Because the sounds defined are incredibly arbitrary the sounds run the risk of having their meaning overloaded. For example, We have complete-media-rip, complete-copy, complete-scan, but no complete-print, no complete-fax. What sounds should be used for those? Each time the sound is overloaded, it is a new meaning for the user to learn. With sounds like window-new, window-move-start, window-move-end, window-minimized, window-unminimized will the computer ever be silent? No wonder people turn the sounds off if they're going to make it sound like there's a hyperactive child in the room screaming for attention constantly. 8 Please remember that sounds are also a means of providing feedback to impaired users. It's true that 90% of sounds will not be used in a typical theme but it's also true that 95% of users don't need the High Contrast theme yet it's uber-useful for the remaining 5%. (Not exact numbers, statistics generated by rolling D100) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound effects
On Fri, Dec 12, 2008 at 11:20 AM, Iain * iaingn...@gmail.com wrote: This brings up another point that I forgot. The actual difficulty of initially working out what a sound means. Because the sounds are arbitrary there is no expectation[1] on the part of the user that a certain action should create a sound Which means that whenever a user hears a sound they need to try to work out what it means. Was that swish new email or CD burning finished? The user closes the laptop lid and hears lid-close sound, thinks what was that sound? and opens the laptop to check. Actually all the sounds have (almost) complete context including full text alternative for assistive technologies so you could either opt for the screen reader to read the description aloud or just ask it what was that from time to time. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound effects
On Fri, Dec 12, 2008 at 12:27 PM, Iain * iaingn...@gmail.com wrote: On Fri, Dec 12, 2008 at 10:41 AM, Behdad Esfahbod beh...@behdad.org wrote: So far we agree. But one sound can't rule them all. If I'm cooking in the kitchen, I like hearing a small beep when I get mail. I also like to hear a sound when someone sends me private message on IM. BUT, I want to be able to differentiate those. I don't run to check for every email, but there's a sense of urgency to IM. Or if my harddisk is just to die, that should really shout Your base is under attack!. Arguably, these sounds are application specific. The application should provide what sounds it needs. Isn't that exactly the opposite of the whole theme concept? I mean if user chooses a Space Odyssey she expects to have HAL all over the place, not just for error dialogs. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound effects
On Fri, Dec 12, 2008 at 12:09 PM, Iain * iaingn...@gmail.com wrote: On Fri, Dec 12, 2008 at 10:38 AM, Patryk Zawadzki pat...@pld-linux.org wrote: Actually all the sounds have (almost) complete context including full text alternative for assistive technologies so you could either opt for the screen reader to read the description aloud or just ask it what was that from time to time. They have (almost) complete context for their original arbitrary purpose. Actually no, each libcanberra call includes a full text description of the _current_ event. It can be as specific as a new email from John regarding whatchamacallit. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound effects
On Fri, Dec 12, 2008 at 12:44 PM, Iain * iaingn...@gmail.com wrote: On Fri, Dec 12, 2008 at 11:37 AM, Bastien Nocera had...@hadess.net wrote: Arguably, these sounds are application specific. The application should provide what sounds it needs. Which is why after more than 10 years of GNOME, I have 2 packages providing custom sounds, libgnome, and gossip (check your /etc/sound/events/ and prove me wrong). And this is proof that the sound theme works, or that people don't use the sounds? This is the proof that programmers are not skilled enough to record sounds (or draw icons or even knit for that matter). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound effects
On Fri, Dec 12, 2008 at 12:55 PM, Iain * iaingn...@gmail.com wrote: I want sound emitting to mean something predictable. Currently it means multiple different things. It can mean you did something, something succeeded, something failed, something unexpected happened, you're required to do something, something expected happened...and the occurances of these sounds is arbitrary and at the whim of the people who came up with the naming spec. The whole point of having different sounds is to be able to differentiate between them... I want a single meaning for when sound is emitted. To be honest, I don't really care what that sound sounds like it could be a duck or frog (like the mac has) for all I care[1]. ...yet you are arguing against your previous paragraph by claiming one sound is enough. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Sound effects
2008/12/12 Philip Withnall philip.withn...@gmail.com: On Fri, 2008-12-12 at 14:42 +0100, Lennart Poettering wrote: I think it would be immensly useful to have speech sounds for some notification-related sounds. Heck, I even thought of doing a very special sound theme, particularly for you called Lennart where I record each and every single sound of the 125 defined in my voice. And I'll add a very special gimmick for you: each time when you click your mouse button you'll hear me saying Mouse click!. And if you press them twice I will say Double Click!. And if you press them thrice I will say Mumumumumulticlick! And then -- I guess you are already expecting it -- after the fourth time I will say Rrrrampage!. I'd install that sound theme in an instant. Where can I get it? :D I second that call, it would be Godlike! to hear such a Clicking Spree! -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pleasantness [was: Re: Sound effects]
On Fri, Dec 12, 2008 at 5:43 PM, Dave Neary dne...@gnome.org wrote: Hello, Behdad Esfahbod wrote: Iain * wrote: But I see that no-one else cares Or, you are not effectively communicating what you mean. Actually, I understand Iain getting annoyed here. He makes a proposal which has its merits, and likely has counter-points that have merit. Actually as it was pointed out his proposal is perfectly achievable as a theme with oen sound and 3-4 symlinks for the main notification categories (and no sounds for the rest of them). Let me summarise what's happening here: Iain wonders why there are 125 user-configurable system sounds in GNOME. He sees that most of the sounds are application-specific, not system-general, and suggests doing away with most of them, and letting applications handle application-specific sounds, and having the system configuration only be used for system-level sounds. [...] This is an admirable goal, and doesn't necessarily go counter to Iain's goal, which is to symplify configuration of system sounds and make them really useful to people who don't have the time to decide which of the 125 available sounds they want turned on and which they want turned off. There are only 16 options in the GNOME sound preferences capplet. They handle all these 125 sounds. Futhermore it's really much easier to open one capplet and be able to mute half of the system sounds in just one click when preparing to give a presentation (before someone proposes pressing mute please think about the concept of watching videos without sound). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Pleasantness [was: Re: Sound effects]
On Fri, Dec 12, 2008 at 6:34 PM, Lennart Poettering mzta...@0pointer.de wrote: On Fri, 12.12.08 12:19, Ronald S. Bultje (rsbul...@gmail.com) wrote: On Fri, Dec 12, 2008 at 12:06 PM, Patryk Zawadzki pat...@pld-linux.org wrote: Futhermore it's really much easier to open one capplet and be able to mute half of the system sounds in just one click when preparing to give a presentation Like for power-management, this should be automated. There's not much to automate. All a presentation program needs to do is to toggle the GConf key /desktop/gnome/sound/event_sounds or the XSETTING gtk-enable-event-sounds. I don't think we need a daemon for managing that key, do we? I actually don't agree here. We need something like system usage profiles (normal use, stealth mode for public areas, presentation etc.) so we don't run into a heap of race conditions where multiple applications try to change and restore the same bunch of GConf keys. Ideally there would just be an fd.o standard with a corresponding GConf key and XSETTING so applications can monitor the changes and act along (in this case canberra-gtk might decide to mute all sounds for some of the profiles). Then we can build on top of that to provide locations so you can switch the usage profile, the proxy configuration, VPN settings and other stuff basing on where you sit (and get bonus points for detecting locations basing on stuff like current wireless network). Anyway that's a whole different story and does not belong in this thread. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DVCS
On Thu, Dec 4, 2008 at 11:25 PM, Behdad Esfahbod [EMAIL PROTECTED] wrote: Good timing. I'm working on it. Have a draft of the survey itself. I'm installing a PHP-based survey software now. Then will pass the survey by board, r-t, and sysadmin team, then go about asking people to fill in. Have not looked into getting the list of SVN users yet. Will get to that later. Should you need any help (now or in the future), I'm a webdev for living. My main interest is Python/Django but I've spent 9 years working with PHP. Feel free to yell if in need (my company donates some of my office time to GNOME hacking anyway). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Update Python version to = 2.5
On Fri, Nov 7, 2008 at 2:45 PM, Luca Ferretti [EMAIL PROTECTED] wrote: Current version is 2.4.3[1] and I know a Python update was yet discussed in past, but please also consider: * libproxy (suggested for 2.26) ask for python = 2.5 * gobject-introspection (needed by gnome-shell) ask for python = 2.5 * other modules I'm missing? I think this is the right time to update from 2.4 to 2.5 (or 2.6 directly), or at least do it in `jhbuild bootstrap`. I think 2.6 might be too fast for some distros but 2.5 should be fine for everyone wanting to ship 2.26. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: libproxy as external dependency
On Thu, Nov 6, 2008 at 2:23 PM, Vincent Untz [EMAIL PROTECTED] wrote: What if the connection works in both cases, but the results are different? I would guess it's up to the application to know if the connection should be restarted. An example for this (although this is a short-life connection) is that you can directly access PDF of the ACM library via a proxy while you end up on a webpage asking you to login if you don't use the proxy. I guess there could be similar examples -- but maybe it's not that important, don't know. But is it likely that the user remembers and manages to switch the proxy *during* the download to save one click? What if while trying to read that PDF you were 90% done downloading another large file (say a DVD iso) that is equally accessible with or without a proxy? Should it be restarted from scratch as there is no guarantee as to data integrity in case of (range GET) resuming with another proxy (a different cached copy comes to mind as a trivial example)? -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed external dependency: WebKit/GTK+
On Thu, Nov 6, 2008 at 6:10 PM, David Bolter [EMAIL PROTECTED] wrote:
Can someone remind me of the specific reasons to switch?
Better (GObject- and signal-oriented) API, smaller memory footprint,
easily embeddable in other apps, does not come with its own graphical
toolkit and a kitchen sink ;)
Would also be a welcomed replacement for gtkhtml{2,3}
--
Patryk Zawadzki
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
2008/11/5 Josselin Mouette [EMAIL PROTECTED]: Case #5: create a dual data/sound CD = Here you need to be able to specify two sets of files: the ones going to the data track, and the ones going to audio tracks. A standalone application might do the trick, but it may still be possible to do it from the file manager. See my mockup later. What about Video CDs and DVDs? I somehow feel these are more useful than audio discs in 2008 where every cell phone, car and inflatable sheep sex doll has a built-in mp3 player ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
On Mon, Nov 3, 2008 at 9:03 AM, Pacho Ramos [EMAIL PROTECTED] wrote: El sáb, 01-11-2008 a las 19:27 +0100, Philippe Rouquier escribió: Hi, We'd be interested in having brasero integrated into the GNOME desktop. +1 It is a great app and I am using it as a replacement of k3b since a lot of time. Sometimes I suffer some bugs (well, what app doesn't have bugs? ;-)), but upstream try to solve them quickly and they are very kind +1 for me as well. Especially if we can push libburn as the default backend and get rid of the multitude of cdrecord versions (cdrtools, cdrecord, cdrkit, dvdrtools...). The only problem with integration I see is that n-c-b is hardcoded all over the place :) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: new module proposal: brasero
2008/11/3 Philippe Rouquier [EMAIL PROTECTED]: So in the above example when a user inserts a blank disc, the nautilus dialog box What should we do with this? pops up and offers the possibility to Burn the disc with brasero. If that option is chosen, then brasero opens a new data project and the user can add files as he does in nautilus. Agreed but I'd vote for dropping the branding (with Brasero). If we aim for integration, the application names are only relevant for packagers and developers. One advantage I see with brasero is that the user can have a GtkFileChooser next to his project or and Add button which is a lot handier than in nautilus when he wants to pick files. With NCB, once the CD creator window is open, it's probably empty which means that the user will have to go somewhere else to pick files and go back afterwards to the CD creator. It means going back and forth between the source folder and the CD creator window. A new user can get confused to be presented an empty selection without any clue to tell him how to fill it. IMO I don't think this is really straightforward. Sure but keep the file browser pane hidden by default (unless the user enabled it earlier). I can imagine most of the users want to drag the files they just downloaded from the desktop. If the disc has data on it the copy medium desktop file will be used with the string (not exactly this one since I don't have it in mind) Copy the disc with Brasero, and so on. I've just realized, that two other desktop files are missing for the latter case, which is Blank with Brasero and Verify integrity with Brasero. But that can be done. Same comment about with Brasero applies. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GNOME-panel, more precisely GNOME-clock issues
On Thu, Oct 30, 2008 at 3:51 PM, Dylan McCall [EMAIL PROTECTED] wrote: As for weather, that could (And SHOULD) be done completely automatically. For example, the OMWeather applet for Maemo finds the nearest weather station via GPS location data. Is there a weather service yet that can give forecasts based on coordinates, or weather maps, or is the limit of only getting weather for specific locations still deeper than the applet itself? The XML has a code entry that is sent to the weather service to identify a location. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Prototyping the next generation panel?
On Tue, Oct 28, 2008 at 3:54 PM, Bastien Nocera [EMAIL PROTECTED] wrote: On Tue, 2008-10-28 at 10:45 -0400, Thomas Thurman wrote: Ysgrifennodd Sandy Armstrong: Thomas Thurman wrote: Bikeshed: are we calling this gnome-shell after all? Maybe we could call it nemo after the captain of the Nautilus. Let's avoid that one, unless we absorb that project (Federico has talked about looking at some of their code for timeline stuff, at least): http://www.iola.dk/nemo/ Oh well, I didn't know of that project. verne? submarine? :) Bathyscaphe :) Red October seems appropriate as the project will eventually surrender itself for reimplementation ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: DVCS
On Tue, Oct 28, 2008 at 5:52 PM, Karl Lattimer [EMAIL PROTECTED] wrote: They both suck, lets use wizbit for a communally continuously syncing DVCS-file-system where everyone can edit and never need to care about pushing or pulling... Lies! We should totally be using a shared DropBox account with all the GNOME inside! ;) -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Fri, Oct 24, 2008 at 8:58 PM, Lennart Poettering [EMAIL PROTECTED] wrote: On Fri, 24.10.08 20:14, Josselin Mouette ([EMAIL PROTECTED]) wrote: Contrary to what the name suggest, lighttpd is not just a lightweight web server, it is a powerful and complete implementation used by some of the biggest websites. I don't think that this kind of FUD about Apache is very constructive. Just because lighttpd has a light in its name it doesn't mean that Apache is a slow huge beast. That is nonsense. Guys, I'm very sorry for starting this thread. I didn't mean to provoke any flame wars. I use both Apache httpd and lighttpd on production and can assure you there is no absolute winner here. Both daemons have their strengths and I pick one over the other depending on the requirements of a project. I was only wondering if there was no simpler DAV daemon we could use here (be it a small python program as python is already used by various parts of GNOME or ideally a C library). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Thu, Oct 23, 2008 at 3:53 PM, Bastien Nocera [EMAIL PROTECTED] wrote: Heya, I'd be interested in getting gnome-user-share into GNOME 2.26. Currently, gnome-user-share is a simple capplet and daemon combination that, through obex-data-server and apache, provides users with simple file sharing. Currently it supports: - ObexFTP and ObexPush (through obex-data-server) - DAV file sharing (through Apache's httpd) Future plans include: - Sharing optical media drives: http://bugzilla.gnome.org/show_bug.cgi?id=530744 - Sharing selected drives: http://bugzilla.gnome.org/show_bug.cgi?id=355382 We're also looking into integrating Frank Scholz' UPNP sharing work (see http://coherence.beebits.net/wiki/Nautilus). But one of the main shorter term goals is to get the desktop sharing feature of vino integrated into gnome-user-share. http://bugzilla.gnome.org/show_bug.cgi?id=471366 Questions? Any plans on making it work without pushing Apache HTTPd onto desktops? A small embedded HTTP server should be enough. Not only is Apache quite a huge dependency to have, it is also very hard to package this into a generic distro where Apache comes preconfigured for heavy server use (and the same is true for most big httpds). -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Thu, Oct 23, 2008 at 5:08 PM, Bastien Nocera [EMAIL PROTECTED] wrote: On Thu, 2008-10-23 at 17:02 +0200, Frederic Peters wrote: A point Patryk touched is that generic distributions will provide Apache packages configured to run at startup, so it is not just a matter of binary size. That's exactly the problem. As a data point, Fedora's httpd is disabled by default for exactly this sort of reason (having it installed doesn't mean we want it running by default). I doubt our server guys will get overly happy over the idea of disabling a typical server daemon just so you can integrate it with GNOME. I don't really think I want the server team to hate the GNOME team any more. Also there seem to be lighter alternatives: http://www.perlmonks.org/?node_id=658773 -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: New module proposal: gnome-user-share
On Thu, Oct 23, 2008 at 5:15 PM, Patryk Zawadzki [EMAIL PROTECTED] wrote: Also there seem to be lighter alternatives: http://www.perlmonks.org/?node_id=658773 Also a Python GPL2 project: http://pywebdav.sourceforge.net/ -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Silly wallpaper hack (or get yourself a PlayStation 3)
I've grown to love the PS3's background fading feature so I've decided to give it a go for GNOME. What PS3 does is pick a color depending on the time of the year then slowly fade that color to black over the day. See the attachment for a proof of concept implementation (just run it and let it continue through your day). Sorry for bugging you guys here but I don't have the time to create a proper patch for Nautilus (and the Appearance capplet to let you pick adjust over time instead of the solid color / gradient) and I'm not on teh planets to spread the love. Hope you like it and someone finds time for a proper implementation. The colors are taken verbatim from the PS3 but I think we could do better with some Tango palette love. Making it part of Nautilus shouldn't be a problem as it only wakes up once every 5 minutes. Cheers ;) -- Patryk Zawadzki rotate.py Description: Binary data ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Silly wallpaper hack (or get yourself a PlayStation 3)
On Wed, Oct 22, 2008 at 4:48 PM, Bastien Nocera [EMAIL PROTECTED] wrote: On Wed, 2008-10-22 at 16:04 +0200, Patryk Zawadzki wrote: I've grown to love the PS3's background fading feature so I've decided to give it a go for GNOME. What PS3 does is pick a color depending on the time of the year then slowly fade that color to black over the day. Did you look at Soeren's code for fading backgrounds in 2.24? I remember the discussion but 2.24 does not seem to ship that feature (or at least it is not discoverable here). Will look into it. -- Patryk Zawadzki ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
