Re: Winners of today's build breakages
On Tue, 2006-07-25 at 20:40 -0600, Elijah Newren wrote: totem: No new release of totem was made, meaning that the fix in head for using dbus_connection_disconnect() isn't in the most recent tarball. So, we just need a new tarball release. I'd gladly accept the blame if it wasn't for the fact that I got no warnings from d-bus that the function was deprecated (GCC can throw nice warnings for things like that), and you're the first person to file a bug about it. I blame your too new D-Bus, works fine on my D-Bus 0.22 (no really, it does). Now I'll stop whinging, and release a tarball. -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Winners of today's build breakages
Nigel Tao wrote: Deskbar uses elementtree to parse a really small XML file. This could be easily re-written to use another XML parser, removing this new dependency. You can also just embed the ElementTree.py file in deskbar's module tree. That's what we've done in gedit (plugins use ElementTree since 2.13.x) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Winners of today's build breakages
On Wed, 2006-07-26 at 08:51 +0100, Bastien Nocera wrote: On Tue, 2006-07-25 at 20:40 -0600, Elijah Newren wrote: totem: No new release of totem was made, meaning that the fix in head for using dbus_connection_disconnect() isn't in the most recent tarball. So, we just need a new tarball release. I'd gladly accept the blame if it wasn't for the fact that I got no warnings from d-bus that the function was deprecated (GCC can throw nice warnings for things like that), and you're the first person to file a bug about it. I blame your too new D-Bus, works fine on my D-Bus 0.22 (no really, it does). Now I'll stop whinging, and release a tarball. Done, 1.5.90 is out. -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
On 26/07/06, Bill Haneman [EMAIL PROTECTED] wrote: On Tue, 2006-07-25 at 19:20, James Henstridge wrote: Havoc's summary at the bottom of his email says why the current gnome_program_init() code is a hack: In summary: - if every libgtk app should do something, get that code in gtk (in the olden days this was not acceptable to the gtk+ team, but I agree that it makes sense to put it there now) - if every libgnome-using app should do something, get that code in libgnome this is what the gnome_program_init code does now (and it was indeed in libgnome) - if only a particular app should do something, get that code in that app yes, that is what happens now for such apps. Assuming that we want accessibility turned on for all GTK programs, then performing that initialisation in a libgnome routine is suboptimal since not every app links to libgnome (e.g. metacity). The fact that the current initialisation code is in gnome_program_init() means that cut-n-paste is necessary. NO: comments like this are why the misunderstanding flared up. The libgnome code is NOT a hack (or at least it clearly was not a hack when it was written!) for several reasons including the one you give below. gnome_program_init() look to be exactly the right place for this code according to Havoc's second category above. Putting the initialisation in gnome_program_init() may have been the best solution at the time it was added, but it was still sub-optimal because it only fixed the problem for a subset of the applications. I think you'll agree that we want a11y enabled for all GTK applications, and the best way to do this is to make the initialisation happen in gtk_init(). The gtk-modules XSETTING makes this possible. The proposed method of getting things loaded is: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. 2. in gtk_init(), GTK sees that the gtk-modules XSETTING is enabled, and loads the listed modules. 3. in the libgnomeui specific gnome_program_init() code, check to see if the accessibility gconf key is set and load libgail-gnome. This setup should make sure that all GTK applications load the GTK accessibility modules, and all libgnomeui applications load the libgnomeui-specific accessibility modules. Cutting and pasting the libgnome a11y code into other modules is that part that's broken. Yes. And the cut-n-paste is necessary because of where the code is. If the initialisation code is put in the right place, it only needs to be done once (the suggested solution being to make gnome-settings-daemon set the gtk-modules XSETTING that libgtk now watches). The initialization code needs access to the xsetting; in the pre-XSETTING days, this meant GTK_MODULES for pure-gtk+ and gconf for 'gnome' progs. It makes sense for gtk+ apps to do this via the xsetting now, instead of the env variable, that would improve the situation. However this will not work for programs in the second category (libgnome using apps). That's why the gnome_program_init code in libgnome has a11y loading logic... libgnome/libgnomeui using programs _are_ GTK programs. The XSETTING should be sufficient to load the basic GTK accessibility modules. The idea is to only do the libgnomeui-specific module loading in gnome_program_init(). Why don't you think this would work? James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
On 7/26/06, James Henstridge [EMAIL PROTECTED] wrote: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. So if we are moving to this solution we could also add a gnome_segvhandler module to this XSETTING in order to get gtk_init load this module installing the segv handler, right? Salu2 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
On 26/07/06, Fernando Herrera [EMAIL PROTECTED] wrote: On 7/26/06, James Henstridge [EMAIL PROTECTED] wrote: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. So if we are moving to this solution we could also add a gnome_segvhandler module to this XSETTING in order to get gtk_init load this module installing the segv handler, right? That would probably also be possible. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: downstream bugs [was Re: GnomeClient replacement?]
Luis Villa wrote: On 7/19/06, Dan Winship [EMAIL PROTECTED] wrote: Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So now that we've got XML-RPC support in bugzilla, it would be insanely cool if someone could write interfaces and code to let you do cross-bugzilla refiling / mark as duplicate / mark as depending on or blocking. (Including cross-bugzilla notifications of relevant changes.) So like, someone files a bug against the panel on SLED, we figure out that it's an upstream bug, but we still want to track it, because it's still a bug against our product too, and it's affecting a customer. So we click a little refile this upstream and mark the local bug as depending on the upstream one button, which does just that. Then if we investigate further, we can add comments upstream, or if someone else fixes it and closes the bug upstream, we'd get a notification of that, and can apply the fix and close our bug. I strongly believe developing and maintaining such tools would be a very worthwhile investment for the various distros- it would reduce the duplication of QA by all parties (which is pretty brutal overhead right now), increase the speed that fixes get to users (again, a win for all parties), so on, so forth. I'd even be willing to argue that this is something a paid bugmaster should do, or at least help the distros' QA teams with. Obviously not going to be me at this point, but something I think the board and advisory board should keep in mind. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list I really like this idea. We (Sun) had a process for upstreaming bugs but when GNOME head moved away from the center of gravity of our user base we didn't find it very useful. Now that we're developing closer to head again, we're encouraging non-distro specific bugs to be manually upstreamed. This isn't an easy sell because most QA and customer support people are familiar with one tool and one process. If GNOME was the only component in our distribution I'd push to drop our internal bug tools entirely and use b.g.o but it isn't. So I'd like to push internally for improving our process for mapping QA bug content to and from bugzilla, tools and a good process for managing bugs generated by users of legacy GNOME releases would certainly help make the case. What, besides bugzilla's XML-RPC support, do we need in order to make this work well? Off the top of my head: A cross-platform automated crash logger: - gathers corefile and symbols when possible - modular so that lsof, dtrace and stacktrace fingerprinting can be enabled. (Would it be useful if, when an infrequent bug happened in a component the logger could automatically load some more detailed tracing modules so that if it happens again we get a better trace?) A crash/bug/rfe GUI which allows opt-in/opt-out to avoid privacy law violations. An I hate this/I love this key which brings up the GUI and passes it information about the currently focused widget (or just a screenshot?) A crash/bug/rfe fingerprinter. - Gathers gnome release version, component versions, distribution and whatever else makes this crash/bug/rfe unique. - When passed a crash/bug/rfe object attempts to match the stack trace or bug description with known b.g.o bugs. A patch-bug mapper - O.K. maybe this is blue-sky stuff, but one of my pet peeves is when bugs are marked as fixed without any indication in the bug as to where the patch is, what version the patch applies to... I'd like to see a two way mapping between every fixed bug and the source patch that fixed it. I understand that this is often impossible when one patch fixes many bugs or several patches fix one bug and some of the patches only apply to patched distribution specific code... but wouldn't it be cool to always tag the bits of code responsible for fixing each bug/rfe with something that can be linked to and viewed from within the bug report? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
Hi Davyd Interesting to see that approach to portraying disk usage. Personally, however, I feel that anyone really wanting this kind of software would probably prefer to use something like Graphical Disk Map http://gdmap.sourceforge.net/. As an outsider to this whole process, though, I'm not sure I totally understand why applications have to be bundled into packages of vaguely related software like this. Can't distributions make their own minds up? On Wed, 2006-07-26 at 13:21 +0800, Davyd Madeley wrote: Perhaps this has been discussed, and I missed it, but... Looking through the change sets, I see gnome-utils has now included the application Baobab. This is quite a handy utility if you wish to analyse your disk space usage, but I am wondering if this application really forms part of what one would consider 'Desktop'. It very much seems like a 3rd party utility at the moment that has simply been included in the core release. This harks back to the discussion about what should be considered 'Desktop', but for the case of Baobab, perhaps we can distill this down to three fundamental questions: - is it mature enough? - is it useful enough to the majority of our users? and - could this idea be integrated more tightly into existing software that the user is familiar with (eg. making it a Nautilus View) --d -- Alex Jones [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
Hi; On Wed, 2006-07-26 at 12:29 +0100, Alex Jones wrote: Hi Davyd Interesting to see that approach to portraying disk usage. Personally, however, I feel that anyone really wanting this kind of software would probably prefer to use something like Graphical Disk Map http://gdmap.sourceforge.net/. Treemap view is supported by Baobab too, but it's not its major feature - which is a nice integration with Nautilus and (now) with the Search tool. As an outsider to this whole process, though, I'm not sure I totally understand why applications have to be bundled into packages of vaguely related software like this. Can't distributions make their own minds up? First, do read the thread about the inclusion of Baobab: http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00112.html The decision to add it to gnome-utils was due to the fact that Baobab is a little utility, with a code base small enough not to require its own package (it did have its own package, though, as it was already shipped by Ubuntu and Debian before the inclusion); it was also actively maintained at the time of inclusion (the latest release of gdmap is dated December 2005). The GNOME Utilities package is a small package that GNOME has kept since the 1.x era (and before); it provides some application other than baobab, like the screenshoter, the file search dialog, the dictionary and the system log viewer, that are not sufficiently big to warrant their own package but at the same time are considered part of the basic offering of GNOME itself. Ciao, Emmanuele (gnome-utils co-maintainer). -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
Humm I'm seeing a problem here. What about GNOME/GTK+ applications launched outside a gnome-session? (for example people using KDE). They won't get the gtk-modules XSETTING and then they won't be accesible at all. I guess that the solution that Kristian pointed (gtk loading auto loading runtime modules provided by the platform) may solve this problem: - gtk_init -- load_init_modules: - gnome a11y module -- Check a11y gconf key -- load gail and friends - bug-buddy module -- install segv handler. the downside of this method is that if we have installed gnome a11y modules then we are adding a little bit of overhead to only-gtk applications (loading gnome-module because it is installed, loading gconf, checking a11y). Salu2 On 7/26/06, James Henstridge [EMAIL PROTECTED] wrote: On 26/07/06, Fernando Herrera [EMAIL PROTECTED] wrote: On 7/26/06, James Henstridge [EMAIL PROTECTED] wrote: 1. gnome-settings-daemon is modified to set the gtk-modules XSETTING, based on the existing gconf key. If accessibility is enabled, it sets it to libgail:libatk-bridge. So if we are moving to this solution we could also add a gnome_segvhandler module to this XSETTING in order to get gtk_init load this module installing the segv handler, right? That would probably also be possible. James. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
2006/7/26, Alex Jones [EMAIL PROTECTED]: As an outsider to this whole process, though, I'm not sure I totally understand why applications have to be bundled into packages of vaguely related software like this. Can't distributions make their own minds up? GNOME software is (supposed to be) guaranteed to have some things like active maintaining, translations, documentation etc. through concentrated effort, something that individual projects (and their maintainers) might never achieve. But it's true that the definition of GNOME as a whole is a bit complex, and does indeed contain more than just vaguely related software :) -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
Hi On Wed, 2006-07-26 at 12:50 +0100, Emmanuele Bassi wrote: Hi; On Wed, 2006-07-26 at 12:29 +0100, Alex Jones wrote: Hi Davyd Interesting to see that approach to portraying disk usage. Personally, however, I feel that anyone really wanting this kind of software would probably prefer to use something like Graphical Disk Map http://gdmap.sourceforge.net/. Treemap view is supported by Baobab too, but it's not its major feature - which is a nice integration with Nautilus and (now) with the Search tool. The treemap in GDMap really is much more usable. Perhaps we should port the logic. I think they call it a cushioned treemap or something, because it manages to make squares (as best it can), not rectangles! As a result, you don't see thick black lines all over the place where a file's representation is of proportions 40:1. Also the colouring is much easier to analyse. Each colour in GDMap represents a file type, so you can see if you have a massive folder of videos somewhere very easily! Just some ideas... As an outsider to this whole process, though, I'm not sure I totally understand why applications have to be bundled into packages of vaguely related software like this. Can't distributions make their own minds up? First, do read the thread about the inclusion of Baobab: http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00112.html The decision to add it to gnome-utils was due to the fact that Baobab is a little utility, with a code base small enough not to require its own package (it did have its own package, though, as it was already shipped by Ubuntu and Debian before the inclusion); it was also actively maintained at the time of inclusion (the latest release of gdmap is dated December 2005). The GNOME Utilities package is a small package that GNOME has kept since the 1.x era (and before); it provides some application other than baobab, like the screenshoter, the file search dialog, the dictionary and the system log viewer, that are not sufficiently big to warrant their own package but at the same time are considered part of the basic offering of GNOME itself. I understand. Thanks Ciao, Emmanuele (gnome-utils co-maintainer). -- Alex Jones [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Winners of today's build breakages
(0) currently running 2.15.90 For what it's worth, I am currently running 2.15.90, built from the source in GARNOME CVS-HEAD (1) dbus API deprecation issues There are some other packages provided by GARNOME that still require updating to handle dbus API deprecation: * avahi * dhcdbd * hal * liboobs * NetworkManager * rhythmbox (2) missing dbus-sharp-0.63 tarball The mono bindings are currently available only through GIT. -Joseph -- joseph_sacco [at] comcast [dot] net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
Hi; On Wed, 2006-07-26 at 13:18 +0100, Alex Jones wrote: Treemap view is supported by Baobab too, but it's not its major feature - which is a nice integration with Nautilus and (now) with the Search tool. The treemap in GDMap really is much more usable. Perhaps we should port the logic. I think they call it a cushioned treemap or something, because it manages to make squares (as best it can), not rectangles! As a result, you don't see thick black lines all over the place where a file's representation is of proportions 40:1. Also the colouring is much easier to analyse. Each colour in GDMap represents a file type, so you can see if you have a massive folder of videos somewhere very easily! Just some ideas... I am sure that if you file RFEs for these features, baobab's maintainer will be glad to look at them and eventually implement them in the next release cycle. Ciao, Emmanuele. -- Emmanuele Bassi, E: [EMAIL PROTECTED] W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Winners of today's build breakages
On Wed, 26.07.06 08:27, Joseph E. Sacco, Ph.D. ([EMAIL PROTECTED]) wrote: (1) dbus API deprecation issues There are some other packages provided by GARNOME that still require updating to handle dbus API deprecation: * avahi I am surprised about this one. We fixed that in our 0.6.12 release. Or at least I thought so, since I have not tested the patch myself on DBUS 0.9x: http://avahi.org/changeset/1238 Could anybody enlighten me if this is still a problem? Lennart -- Lennart Poettering; lennart [at] poettering [dot] net ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.net/lennart/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
On 7/26/06, Fernando Herrera [EMAIL PROTECTED] wrote: Humm I'm seeing a problem here. What about GNOME/GTK+ applications launched outside a gnome-session? (for example people using KDE). They won't get the gtk-modules XSETTING and then they won't be accesible at all. I guess that the solution that Kristian pointed (gtk loading auto loading runtime modules provided by the platform) may solve this problem: - gtk_init -- load_init_modules: - gnome a11y module -- Check a11y gconf key -- load gail and friends - bug-buddy module -- install segv handler. the downside of this method is that if we have installed gnome a11y modules then we are adding a little bit of overhead to only-gtk applications (loading gnome-module because it is installed, loading gconf, checking a11y). GTK+ programs running outside a session can either fall back to the GTK_MODULES envvar or use an xsettings manager even if they are running under, say, KDE. That was the initial idea of xsettings anyway, and I believe there is a xsettings manager for KDE that some distributions use. Matthias ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [g-a-devel] GnomeClient replacement?
Le mercredi 26 juillet 2006 à 09:05 -0400, Matthias Clasen a écrit : On 7/26/06, Fernando Herrera [EMAIL PROTECTED] wrote: Humm I'm seeing a problem here. What about GNOME/GTK+ applications launched outside a gnome-session? (for example people using KDE). They won't get the gtk-modules XSETTING and then they won't be accesible at all. I guess that the solution that Kristian pointed (gtk loading auto loading runtime modules provided by the platform) may solve this problem: - gtk_init -- load_init_modules: - gnome a11y module -- Check a11y gconf key -- load gail and friends - bug-buddy module -- install segv handler. the downside of this method is that if we have installed gnome a11y modules then we are adding a little bit of overhead to only-gtk applications (loading gnome-module because it is installed, loading gconf, checking a11y). GTK+ programs running outside a session can either fall back to the GTK_MODULES envvar or use an xsettings manager even if they are running under, say, KDE. That was the initial idea of xsettings anyway, and I believe there is a xsettings manager for KDE that some distributions use. xsettings-kde : ugly hack but it works not so bad.. I might add accessibility in it too but I need to check if KDE has some accessibility key. http://cvs.mandriva.com/cgi-bin/viewvc.cgi/soft/xsettings-kde/ -- Frederic Crozat [EMAIL PROTECTED] Mandriva ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Winners of today's build breakages
Thanks, Lennart. You are correct. I am currently running 0.6.11 [:-)]. Updating now. -Joseph On Wed, 2006-07-26 at 14:51 +0200, Lennart Poettering wrote: On Wed, 26.07.06 08:27, Joseph E. Sacco, Ph.D. ([EMAIL PROTECTED]) wrote: (1) dbus API deprecation issues There are some other packages provided by GARNOME that still require updating to handle dbus API deprecation: * avahi I am surprised about this one. We fixed that in our 0.6.12 release. Or at least I thought so, since I have not tested the patch myself on DBUS 0.9x: http://avahi.org/changeset/1238 Could anybody enlighten me if this is still a problem? Lennart -- joseph_sacco [at] comcast [dot] net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: downstream bugs [was Re: GnomeClient replacement?]
On 7/26/06, Brian Nitz [EMAIL PROTECTED] wrote: Luis Villa wrote: On 7/19/06, Dan Winship [EMAIL PROTECTED] wrote: Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So now that we've got XML-RPC support in bugzilla, it would be insanely cool if someone could write interfaces and code to let you do cross-bugzilla refiling / mark as duplicate / mark as depending on or blocking. (Including cross-bugzilla notifications of relevant changes.) So like, someone files a bug against the panel on SLED, we figure out that it's an upstream bug, but we still want to track it, because it's still a bug against our product too, and it's affecting a customer. So we click a little refile this upstream and mark the local bug as depending on the upstream one button, which does just that. Then if we investigate further, we can add comments upstream, or if someone else fixes it and closes the bug upstream, we'd get a notification of that, and can apply the fix and close our bug. I strongly believe developing and maintaining such tools would be a very worthwhile investment for the various distros- it would reduce the duplication of QA by all parties (which is pretty brutal overhead right now), increase the speed that fixes get to users (again, a win for all parties), so on, so forth. I'd even be willing to argue that this is something a paid bugmaster should do, or at least help the distros' QA teams with. Obviously not going to be me at this point, but something I think the board and advisory board should keep in mind. I really like this idea. We (Sun) had a process for upstreaming bugs but when GNOME head moved away from the center of gravity of our user base we didn't find it very useful. Now that we're developing closer to head again, we're encouraging non-distro specific bugs to be manually upstreamed. This isn't an easy sell because most QA and customer support people are familiar with one tool and one process. Also because GNOME does not take the time to make the benefits clear. I believe part of the job of a distro-focused bugmaster would be to say 'you filed X bugs upstream this quarter; Y percentage of them were fixed by the community', or other such numbers that would clarify the value to the distro. If GNOME was the only component in our distribution I'd push to drop our internal bug tools entirely and use b.g.o but it isn't. So I'd like to push internally for improving our process for mapping QA bug content to and from bugzilla, tools and a good process for managing bugs generated by users of legacy GNOME releases would certainly help make the case. All distros should be pushing for this :) Would it perhaps be useful to have a QA summit at the Boston Summit, where the various distros could compare notes on upstreaming technique, and see if there are ways they could collaborate? What, besides bugzilla's XML-RPC support, do we need in order to make this work well? Off the top of my head: A cross-platform automated crash logger: - gathers corefile and symbols when possible - modular so that lsof, dtrace and stacktrace fingerprinting can be enabled. (Would it be useful if, when an infrequent bug happened in a component the logger could automatically load some more detailed tracing modules so that if it happens again we get a better trace?) bug-buddy is inching in this direction, but yeah, tied to gdb right now. Would be great to see some investment in this by the distros (who are, after all, the ones directly financially impacted by crashes.) A crash/bug/rfe GUI which allows opt-in/opt-out to avoid privacy law violations. I believe bug-buddy already does this, no? An I hate this/I love this key which brings up the GUI and passes it information about the currently focused widget (or just a screenshot?) I like this idea, but would consider it a secondary priority until we can better handle crashes. Baby steps :) A crash/bug/rfe fingerprinter. - Gathers gnome release version, component versions, distribution and whatever else makes this crash/bug/rfe unique. Latest bug-buddy does this now, I believe. - When passed a crash/bug/rfe object attempts to match the stack trace or bug description with known b.g.o bugs. We're getting there ;) A patch-bug mapper - O.K. maybe this is blue-sky stuff, but one of my pet peeves is when bugs are marked as fixed without any indication in the bug as to where the patch is, what version the patch applies to... I'd like to see a two way mapping between every fixed bug and the source patch that fixed it. I understand that this is often impossible when one patch fixes many bugs or several patches fix one bug and some of the patches only apply to patched distribution specific code... but wouldn't it be cool to always tag the bits of code responsible for fixing
Re: Winners of today's build breakages
On 7/26/06, Bastien Nocera [EMAIL PROTECTED] wrote: On Wed, 2006-07-26 at 08:51 +0100, Bastien Nocera wrote: On Tue, 2006-07-25 at 20:40 -0600, Elijah Newren wrote: totem: No new release of totem was made, meaning that the fix in head for using dbus_connection_disconnect() isn't in the most recent tarball. So, we just need a new tarball release. I'd gladly accept the blame if it wasn't for the fact that I got no warnings from d-bus that the function was deprecated (GCC can throw nice warnings for things like that), and you're the first person to file a bug about it. I blame your too new D-Bus, works fine on my D-Bus 0.22 (no really, it does). Now I'll stop whinging, and release a tarball. I think your complaints are perfectly fair. It caught at least half a dozen modules by complete surprise; it seems no one new that dbus_connection_disconnect() had been deprecated for a year. Done, 1.5.90 is out. Awesome, thanks! ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Call For Help: Roll deskbar-applet 2.15.90.1
As previously mentioned, deskbar-applet doesn't build against e-d-s HEAD - there is a trivial patch to d-a attached to http://bugzilla.gnome.org/show_bug.cgi?id=347988 which looks good to me (and looks good to others). However, I am running GNOME 2.14 on my sole computer at the moment (a laptop with a far-too-small hard disk), and I don't have the bleeding edge jhbuild built (or have otherwise built e-d-s 2.15.x). Consequently, I can't make the patched tarball because I can't, er, make. So, I would muchly appreciate [1] it if somebody with appropriate privileges could check out deskbar-applet HEAD (I don't think it's changed since I rolled 2.15.90 a couple of days ago), apply the trivial patch mentioned above, update configure.ac, NEWS and the ChangeLog, make a 2.15.90.1 tarball, make distcheck, scp the resultant .tar.gz to master.gnome.org and install-module the sucker. Raphael (kikidonk) is on vacation (??) until the 29th, and I don't know if the other deskbar folks have sufficient privileges to make a release, so I might need a hero to step up right now. Otherwise, I can have another go at it in the (Australian) morning, but it would rock if somebody could help out now. There are simply not enough hours in the day :-( Nigel. [1] I'll buy all applicable people a bunch of beers the next time GUADEC is in Australia, for example. :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed Orca Migration
On Wed, 2006-07-26 at 05:26 -0400, Willie Walker wrote: Hi All: In the spirit of keeping the Orca migration decoupled from the accessibility properties dialog redesign, Bill Haneman has created patches for control-center and gnome-session: http://bugzilla.gnome.org/show_bug.cgi?id=348630 (control-center) http://bugzilla.gnome.org/show_bug.cgi?id=348643 (gnome-session) The first patch (control-center) gives preference to using 'orca' for the exec_ats property if screen reading or magnification is desired, but will fallback to 'gnopernicus' if 'orca' is not present on the machine. The second patch (gnome-session) will fallback to 'orca' if the exec_ats prefs has specified 'gnopernicus' but 'gnopernicus' is not present on the machine. These seem to address Shaun's migration concerns as well as Matthias' FC6 concerns. I'll be happy to work with the control-center and gnome-session maintainers to roll these patches in for GNOME 2.16. Comments? I have only one concern with this proposal, and note that none of my previous proposals addressed this issue very well either. If I'm running different versions of Gnome off the same home directory, and I turn on the screen reader in the 2.16 desktop, my 2.14 desktop won't be able to launch the screen reader. Situations like this are why it's nice to categorize the tools. It makes it easier to write forwards-compatible code. Not that we could change past release now anyway. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed Orca Migration
On Wed, 2006-07-26 at 16:14, Shaun McCance wrote: On Wed, 2006-07-26 at 05:26 -0400, Willie Walker wrote: Hi All: In the spirit of keeping the Orca migration decoupled from the accessibility properties dialog redesign, Bill Haneman has created patches for control-center and gnome-session: http://bugzilla.gnome.org/show_bug.cgi?id=348630 (control-center) http://bugzilla.gnome.org/show_bug.cgi?id=348643 (gnome-session) The first patch (control-center) gives preference to using 'orca' for the exec_ats property if screen reading or magnification is desired, but will fallback to 'gnopernicus' if 'orca' is not present on the machine. The second patch (gnome-session) will fallback to 'orca' if the exec_ats prefs has specified 'gnopernicus' but 'gnopernicus' is not present on the machine. These seem to address Shaun's migration concerns as well as Matthias' FC6 concerns. I'll be happy to work with the control-center and gnome-session maintainers to roll these patches in for GNOME 2.16. Comments? I have only one concern with this proposal, and note that none of my previous proposals addressed this issue very well either. If I'm running different versions of Gnome off the same home directory, and I turn on the screen reader in the 2.16 desktop, my 2.14 desktop won't be able to launch the screen reader. Will and I have talked about this case. Our conclusion is that users will not want to switch between gnopernicus and orca. Besides, the case you are referring to is actually a sort of forward compatibility scenario which one can never really support, i.e. a 2.16 dialog enables a feature not available in 2.14. It also begs the question of why an existing Gnome 2.14 would need a screenreader in 2.16 without having enabled it previously, in 2.14. Three solutions are available to the user of 2.14+2.16 shared directories who actually runs the 2.16 dialog and enables automatic orca startup: 1) install orca on the 2.14 desktop, where it should run fine; 2) use gnopernicus on both (with fallback to 'orca' on the 2.16 system, if gnopernicus is not available); 3) ln -s /usr/bin/orca /usr/bin/gnopernicus on the 2.14 system. Situations like this are why it's nice to categorize the tools. It makes it easier to write forwards-compatible code. Not that we could change past release now anyway. Well, we could patch 2.14.X but I don't think that these hypothetical cases will actually have a serious impact on users (and in any case we have straightforward workarounds). Forwards-compatibility is tricky at the best of times. Bill -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Tue, 2006-07-25 at 09:33 -0600, Elijah Newren wrote: We bind six libraries that fall in the desktop set currently. I cannot split out three of them because the APIs are included in gnome-sharp.dll currently, and to split them out would break API compat for my users. Are you saying that parallel installation of libraries is impossible in the mono world? I don't see how this has to break API compatibility for your current users. Parallel-installation is a compatibility break. I think I've come up with a package division that would be acceptable from a stability standpoint for us and still satisfy this no desktop libs requirement people seem to be dogmatically enforcing. We could split gtk-sharp into two packages: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. gnome-sharp-2.16.0 would get gnome-vfs-sharp, gnome-sharp, art-sharp, rsvg-sharp, vte-sharp, gconf-sharp, and gtkhtml-sharp. I would propose this package for inclusion in the Desktop release set. The division should satisfy all the rules. There is no rule against a platform binding living in the Desktop release set. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
On Wed, 26 Jul 2006, Davyd Madeley wrote: Date: Wed, 26 Jul 2006 13:21:50 +0800 From: Davyd Madeley [EMAIL PROTECTED] To: Gnome Desktop Development List desktop-devel-list@gnome.org Subject: Baobab Perhaps this has been discussed, and I missed it, but... Inclusion of baobab in gnome-utils http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00112.html Found using the following google search: site:mail.gnome.org desktop-devel baobab. (easy once I spelt baobab correctly ;) -- Alan H. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
Hi Mike, On Wed, July 26, 2006 17:35, Mike Kestner wrote: I think I've come up with a package division that would be acceptable from a stability standpoint for us and still satisfy this no desktop libs requirement people seem to be dogmatically enforcing. We could split gtk-sharp into two packages: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. (I don't know what's in gtkdotnet, but I suppose it's stuff to make it easier to use gtk+) gnome-sharp-2.16.0 would get gnome-vfs-sharp, gnome-sharp, art-sharp, rsvg-sharp, vte-sharp, gconf-sharp, and gtkhtml-sharp. I would propose this package for inclusion in the Desktop release set. The division should satisfy all the rules. There is no rule against a platform binding living in the Desktop release set. This looks like it would work. gnome-vfs-sharp, gnome-sharp and gconf-sharp could go in the bindings suite too, but this would imply either creating a third package or moving them in gtk-sharp-2.10.0. Thanks for working on this! Vincent -- Les gens heureux ne sont pas pressés. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 17:47 +0200, Vincent Untz wrote: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. (I don't know what's in gtkdotnet, but I suppose it's stuff to make it easier to use gtk+) Stuff to allow drawing on Gdk windows with the .Net System.Drawing API. Any future additions will be of a similar flavor. Helper classes for access to .Net APIs for which we don't want to put an additional dependency on gtk-sharp.dll. The division should satisfy all the rules. There is no rule against a platform binding living in the Desktop release set. This looks like it would work. gnome-vfs-sharp, gnome-sharp and gconf-sharp could go in the bindings suite too, but this would imply either creating a third package or moving them in gtk-sharp-2.10.0. Putting all the gnome stuff in one gnome-sharp package has a certain marketability/sense to it. And gnome-sharp can't go in platform. It's the source of all this angst, because it has the dreaded print and panel APIs. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 18:21 +0200, Murray Cumming wrote: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. That seems a lot nicer. I am, however, slightly concerned that this would force people to depend on libglade even when we have a libglade replacement in GTK+. The C, C ++, Python, Java, and Perl users will be able to rewrite their applications so that they don't need libglade on the system. glade-sharp is an optional build. We're not forcing anyone to put it on their systems. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 11:25 -0500, Mike Kestner wrote: On Wed, 2006-07-26 at 18:21 +0200, Murray Cumming wrote: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. That seems a lot nicer. I am, however, slightly concerned that this would force people to depend on libglade even when we have a libglade replacement in GTK+. The C, C ++, Python, Java, and Perl users will be able to rewrite their applications so that they don't need libglade on the system. glade-sharp is an optional build. We're not forcing anyone to put it on their systems. These optional builds don't help much, unless people are using gentoo (or other source-based distros). If the binary package was built with glade support then distros are unlikely to change their binary package in the future to remove the glade support. That would be an ABI break. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Mit, 2006-07-26 at 18:32 +0200, Murray Cumming wrote: On Wed, 2006-07-26 at 11:25 -0500, Mike Kestner wrote: On Wed, 2006-07-26 at 18:21 +0200, Murray Cumming wrote: gtk-sharp-2.10.0 would keep glib-sharp, pango-sharp, atk-sharp, gdk-sharp, gtk-sharp, glade-sharp, and gtkdotnet. I would propose this altered package for inclusion in the Bindings release set. That seems a lot nicer. I am, however, slightly concerned that this would force people to depend on libglade even when we have a libglade replacement in GTK+. The C, C ++, Python, Java, and Perl users will be able to rewrite their applications so that they don't need libglade on the system. glade-sharp is an optional build. We're not forcing anyone to put it on their systems. These optional builds don't help much, unless people are using gentoo (or other source-based distros). If the binary package was built with glade support then distros are unlikely to change their binary package in the future to remove the glade support. That would be an ABI break. gtk-sharp has a separate glib-sharp-2.0.pc pkg-config file, so it's relatively easy to provide multiple binary packages from one source package or am I missing something? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On 7/26/06, Alex Graveley [EMAIL PROTECTED] wrote: This sounds great, and will help Gtk# t be used by many more people! Sorry to add confusion, but how does this help the Tomboy discussion? I'm using gnome-sharp and gconf-sharp. And hopefully the panel APIs in the future (there is a crasher bug currently, so I'm using a local copy). Would we add gnome-sharp as a soft dependency if Tomboy is included, similar to e.g. libsoup for Evolution? Pending the gtk# discussion elsewhere, the idea would be to treat it the same as python -- stable bindings of platform modules in the bindings release, unstable bindings of desktop (and possibly even some platform) modules in the desktop release, and desktop modules allowed to depend on either of those two sets of bindings. In short, no further work required of you in regards to this particular issue. :-) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 18:40 +0200, Jürg Billeter wrote: These optional builds don't help much, unless people are using gentoo (or other source-based distros). If the binary package was built with glade support then distros are unlikely to change their binary package in the future to remove the glade support. That would be an ABI break. gtk-sharp has a separate glib-sharp-2.0.pc pkg-config file, so it's relatively easy to provide multiple binary packages from one source package or am I missing something? It might be possible, but distros generally don't do that. And once they've released a binary package and called it stable then they can't change that (unless they do a parallel install and deprecate the old binary package). gnome-python-extras is an example of an all-in-one source tarball that's currently causing me problems because it's packaged as an all-in-one binary package on debian/Ubuntu. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Call For Help: Roll deskbar-applet 2.15.90.1
On 7/26/06, Nigel Tao [EMAIL PROTECTED] wrote: As previously mentioned, deskbar-applet doesn't build against e-d-s HEAD - there is a trivial patch to d-a attached to http://bugzilla.gnome.org/show_bug.cgi?id=347988 which looks good to me (and looks good to others). However, I am running GNOME 2.14 on my sole computer at the moment (a laptop with a far-too-small hard disk), and I don't have the bleeding edge jhbuild built (or have otherwise built e-d-s 2.15.x). Consequently, I can't make the patched tarball because I can't, er, make. So, I would muchly appreciate [1] it if somebody with appropriate privileges could check out deskbar-applet HEAD (I don't think it's changed since I rolled 2.15.90 a couple of days ago), apply the trivial patch mentioned above, update configure.ac, NEWS and the ChangeLog, make a 2.15.90.1 tarball, make distcheck, scp the resultant .tar.gz to master.gnome.org and install-module the sucker. Raphael (kikidonk) is on vacation (??) until the 29th, and I don't know if the other deskbar folks have sufficient privileges to make a release, so I might need a hero to step up right now. /me starts some patching and 'make distcheck' action on his machine... Cheers, Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 18:32 +0200, Murray Cumming wrote: These optional builds don't help much, unless people are using gentoo (or other source-based distros). If the binary package was built with glade support then distros are unlikely to change their binary package in the future to remove the glade support. That would be an ABI break. Seems like you're just being argumentative, now. Is the goal here to reinvent Gtk# in Gtkmm's image, or to satisfy the requirements of the release set? Last time I checked, libglade was a platform library. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
On 7/26/06, Alan Horkan [EMAIL PROTECTED] wrote: Inclusion of baobab in gnome-utils http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00112.html Found using the following google search: site:mail.gnome.org desktop-devel baobab. Nice to see that I'm not the only one who thinks google is the only way to search the mail archives. Perhaps we could get the search box at http://mail.gnome.org/mailman/search to just simply use google since it currently doesn't work? ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed Orca Migration
On Wed, 2006-07-26 at 16:34 +0100, Bill Haneman wrote: On Wed, 2006-07-26 at 16:14, Shaun McCance wrote: On Wed, 2006-07-26 at 05:26 -0400, Willie Walker wrote: Hi All: In the spirit of keeping the Orca migration decoupled from the accessibility properties dialog redesign, Bill Haneman has created patches for control-center and gnome-session: http://bugzilla.gnome.org/show_bug.cgi?id=348630 (control-center) http://bugzilla.gnome.org/show_bug.cgi?id=348643 (gnome-session) The first patch (control-center) gives preference to using 'orca' for the exec_ats property if screen reading or magnification is desired, but will fallback to 'gnopernicus' if 'orca' is not present on the machine. The second patch (gnome-session) will fallback to 'orca' if the exec_ats prefs has specified 'gnopernicus' but 'gnopernicus' is not present on the machine. These seem to address Shaun's migration concerns as well as Matthias' FC6 concerns. I'll be happy to work with the control-center and gnome-session maintainers to roll these patches in for GNOME 2.16. Comments? I have only one concern with this proposal, and note that none of my previous proposals addressed this issue very well either. If I'm running different versions of Gnome off the same home directory, and I turn on the screen reader in the 2.16 desktop, my 2.14 desktop won't be able to launch the screen reader. Will and I have talked about this case. Our conclusion is that users will not want to switch between gnopernicus and orca. Besides, the case you are referring to is actually a sort of forward compatibility scenario which one can never really support, i.e. a 2.16 dialog enables a feature not available in 2.14. It also begs the question of why an existing Gnome 2.14 would need a screenreader in 2.16 without having enabled it previously, in 2.14. On the NFS-using network I'm on at work, I do most of my work on my own personal machine, which I keep fairly current. So generally, I change my settings on that machine. Occasionally, I have to use another machine, and most Gnome boxes around the office aren't as current as mine. If a new Gnome user joined the company in about six months or so, that user would probably get a 2.16 desktop and set all of his settings there. Three solutions are available to the user of 2.14+2.16 shared directories who actually runs the 2.16 dialog and enables automatic orca startup: 1) install orca on the 2.14 desktop, where it should run fine; 2) use gnopernicus on both (with fallback to 'orca' on the 2.16 system, if gnopernicus is not available); 3) ln -s /usr/bin/orca /usr/bin/gnopernicus on the 2.14 system. Yeah, all right. I suppose there probably isn't a magical solution that doesn't suck somewhere. So let's just bite the bullet and do this. Situations like this are why it's nice to categorize the tools. It makes it easier to write forwards-compatible code. Not that we could change past release now anyway. Well, we could patch 2.14.X but I don't think that these hypothetical cases will actually have a serious impact on users (and in any case we have straightforward workarounds). Forwards-compatibility is tricky at the best of times. That it is, and I do think we should put some serious effort into addressing it desktop-wide. Probably a lot of smartness could be built into our configuration system to handle most cases. But part of the problem is that developers just need to think about new interfaces they introduce (configuration keys, binary names, command line options, etc.) and how they will hold up to future changes. It's not easy, and we won't always be able to predict the problems of the future. But right now, I don't think we're even trying. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
On 7/26/06, Alex Jones [EMAIL PROTECTED] wrote: The treemap in GDMap really is much more usable. Perhaps we should port the logic. I think they call it a cushioned treemap or something, because it manages to make squares (as best it can), not rectangles! As a result, you don't see thick black lines all over the place where a file's representation is of proportions 40:1. Also the colouring is much easier to analyse. Each colour in GDMap represents a file type, so you can see if you have a massive folder of videos somewhere very easily! We can work on the treemap. But I believe that it will be more useful to have two different graphical representation, the user will select: a treemap (even with rectangles instead of squares) and a ring-chart. We are currently working on this enhancement. Thanks for your suggestions. Fabio ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
On Wed, 26 Jul 2006, Elijah Newren wrote: Date: Wed, 26 Jul 2006 10:59:42 -0600 From: Elijah Newren [EMAIL PROTECTED] To: Alan Horkan [EMAIL PROTECTED] Cc: Gnome Desktop Development List desktop-devel-list@gnome.org Subject: Re: Baobab On 7/26/06, Alan Horkan [EMAIL PROTECTED] wrote: Inclusion of baobab in gnome-utils http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00112.html Found using the following google search: site:mail.gnome.org desktop-devel baobab. In hindsight that was rather terse and may have come across as rude or patronising which wasn't my intention. Often it is only easy to search for things why you already know what you are looking for. Nice to see that I'm not the only one who thinks google is the only way to search the mail archives. Perhaps we could get the search box at http://mail.gnome.org/mailman/search to just simply use google since it currently doesn't work? A trickle of associated Ad revenue certainly going to the foundation wouldn't do any harm I expect. -- Alan ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Winners of today's build breakages
Elijah, That's half of it... Take a look at the GAR Makefile for pwlib. The post-configure target creates a soft link that points to the pwlib source directory. Once in place, the GAR Makefile for opal set and env variable PWLIBDIR=$(prefix)/src/pwlib -Joseph === On Wed, 2006-07-26 at 10:20 -0600, Elijah Newren wrote: On 7/26/06, Joseph E. Sacco, Ph.D. [EMAIL PROTECTED] wrote: (0) currently running 2.15.90 For what it's worth, I am currently running 2.15.90, built from the source in GARNOME CVS-HEAD I have been unable to get pwlib and opal to build; they hardcode /usr and /usr/local into their search paths in configure, ignoring the specified prefix. Did you get around this? I checked out garnome and noticed you had CONFIGURE_ENV = PWLIBDIR=$(prefix)/src/pwlib in your opal Makefile; is that all that's needed to fix the braindamage in these modules? -- joseph_sacco [at] comcast [dot] net ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Proposed Orca Migration
Thanks Shaun! Just to confirm: you are on board with the proposed solution for GNOME 2.16 as outlined in the discussion and implemented by the patches for bug 348630 and bug 348643? For GNOME 2.18, a task will be to to a better job on setting accessibility preferences. The Ubuntu folks have done some related thinking: https://wiki.ubuntu.com/Accessibility/Specs/CommonATConfig. Will On Wed, 2006-07-26 at 12:04 -0500, Shaun McCance wrote: On Wed, 2006-07-26 at 16:34 +0100, Bill Haneman wrote: On Wed, 2006-07-26 at 16:14, Shaun McCance wrote: On Wed, 2006-07-26 at 05:26 -0400, Willie Walker wrote: Hi All: In the spirit of keeping the Orca migration decoupled from the accessibility properties dialog redesign, Bill Haneman has created patches for control-center and gnome-session: http://bugzilla.gnome.org/show_bug.cgi?id=348630 (control-center) http://bugzilla.gnome.org/show_bug.cgi?id=348643 (gnome-session) The first patch (control-center) gives preference to using 'orca' for the exec_ats property if screen reading or magnification is desired, but will fallback to 'gnopernicus' if 'orca' is not present on the machine. The second patch (gnome-session) will fallback to 'orca' if the exec_ats prefs has specified 'gnopernicus' but 'gnopernicus' is not present on the machine. These seem to address Shaun's migration concerns as well as Matthias' FC6 concerns. I'll be happy to work with the control-center and gnome-session maintainers to roll these patches in for GNOME 2.16. Comments? I have only one concern with this proposal, and note that none of my previous proposals addressed this issue very well either. If I'm running different versions of Gnome off the same home directory, and I turn on the screen reader in the 2.16 desktop, my 2.14 desktop won't be able to launch the screen reader. Will and I have talked about this case. Our conclusion is that users will not want to switch between gnopernicus and orca. Besides, the case you are referring to is actually a sort of forward compatibility scenario which one can never really support, i.e. a 2.16 dialog enables a feature not available in 2.14. It also begs the question of why an existing Gnome 2.14 would need a screenreader in 2.16 without having enabled it previously, in 2.14. On the NFS-using network I'm on at work, I do most of my work on my own personal machine, which I keep fairly current. So generally, I change my settings on that machine. Occasionally, I have to use another machine, and most Gnome boxes around the office aren't as current as mine. If a new Gnome user joined the company in about six months or so, that user would probably get a 2.16 desktop and set all of his settings there. Three solutions are available to the user of 2.14+2.16 shared directories who actually runs the 2.16 dialog and enables automatic orca startup: 1) install orca on the 2.14 desktop, where it should run fine; 2) use gnopernicus on both (with fallback to 'orca' on the 2.16 system, if gnopernicus is not available); 3) ln -s /usr/bin/orca /usr/bin/gnopernicus on the 2.14 system. Yeah, all right. I suppose there probably isn't a magical solution that doesn't suck somewhere. So let's just bite the bullet and do this. Situations like this are why it's nice to categorize the tools. It makes it easier to write forwards-compatible code. Not that we could change past release now anyway. Well, we could patch 2.14.X but I don't think that these hypothetical cases will actually have a serious impact on users (and in any case we have straightforward workarounds). Forwards-compatibility is tricky at the best of times. That it is, and I do think we should put some serious effort into addressing it desktop-wide. Probably a lot of smartness could be built into our configuration system to handle most cases. But part of the problem is that developers just need to think about new interfaces they introduce (configuration keys, binary names, command line options, etc.) and how they will hold up to future changes. It's not easy, and we won't always be able to predict the problems of the future. But right now, I don't think we're even trying. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
On Wed, 26 Jul 2006, Alex Jones wrote: Date: Wed, 26 Jul 2006 12:29:11 +0100 From: Alex Jones [EMAIL PROTECTED] To: desktop-devel-list@gnome.org Subject: Re: Baobab Hi Davyd Interesting to see that approach to portraying disk usage. Personally, however, I feel that anyone really wanting this kind of software would probably prefer to use something like Graphical Disk Map http://gdmap.sourceforge.net/. Maybe having an alias for gnome-disk-usage would help users who would like to swap out Boabab for somethinge else? (Also if Gdmap were ever proposed for inclusion I would hope it would use MB by default rather than MiB, as seen in the screenshot.) As an outsider to this whole process, though, I'm not sure I totally understand why applications have to be bundled into packages of vaguely related software like this. Picking something helps focus translators and documentation writers and other contributors. It also gives a fixed point of integration. Ideally it should not prevent other tools being switched out in place of the gnome recommended default. Can't distributions make their own minds up? Past experience would suggest they can all make up their own minds in entirely different ways (gnome system tools are a reasonable example I think). By making a choice gnome encourages standardisation but in some cases distributions will continue to ship their own custom tools. -- Alan H. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 11:52 -0500, Mike Kestner wrote: On Wed, 2006-07-26 at 18:32 +0200, Murray Cumming wrote: These optional builds don't help much, unless people are using gentoo (or other source-based distros). If the binary package was built with glade support then distros are unlikely to change their binary package in the future to remove the glade support. That would be an ABI break. Seems like you're just being argumentative, now. Is the goal here to reinvent Gtk# in Gtkmm's image, or to satisfy the requirements of the release set? Last time I checked, libglade was a platform library. I do not understand you (or your colleagues) always need to be so aggressive and insulting every time this is discussed. What part of my email made you feel that was necessary? -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Putting the 'Mono debate' back on the rails
On Wed, 2006-07-26 at 20:09 +0200, Murray Cumming wrote: Is the goal here to reinvent Gtk# in Gtkmm's image, or to satisfy the requirements of the release set? Last time I checked, libglade was a platform library. I do not understand you (or your colleagues) always need to be so aggressive and insulting every time this is discussed. What part of my email made you feel that was necessary? Sorry you felt insulted. Thank you for your suggestion. I am well acquainted with your opinion on this matter. We have considered and declined the idea of splitting our binding into a set of tarballs for each bound library. We think that we are already providing a very packaging-friendly set of bindings. Pardon my abruptness. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Patches for scrollkeeper...is scrollkeeper maintained?
Hi, Does scrollkeeper have any maintainers? I just found out about a bunch of patches needed for yelp to not choke on scrollkeeper files, listed at http://live.gnome.org/Yelp (all of the patches are part of bug 348013). It appears that the gnome-2.16 jhbuild moduleset has been patched to manually include these, but it'd be better to just get them upstream...if there is still an upstream (last scrollkeeper release was 2003). Anyone know more about this? Elijah ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Patches for scrollkeeper...is scrollkeeper maintained?
Hi, On Wed, 2006-07-26 at 14:17 -0600, Elijah Newren wrote: Hi, Does scrollkeeper have any maintainers? I just found out about a bunch of patches needed for yelp to not choke on scrollkeeper files, listed at http://live.gnome.org/Yelp (all of the patches are part of bug 348013). It appears that the gnome-2.16 jhbuild moduleset has been patched to manually include these, but it'd be better to just get them upstream...if there is still an upstream (last scrollkeeper release was 2003). Anyone know more about this? AFAICT, 'E's passed on! This parrot is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! It is really annoying. There have been at least a few bugs filed against yelp about scrollkeeper problems. The last non-spam message to their mailing list was a couple of years ago, and that appears to have been shaunm, basically asking what was happening (the answer was I don't know of any plans). The patches linked are all from the Ubuntu scrollkeeper package. Hopefully at some point soon, we can remove scrollkeeper entirely and replace it. There are secret plans afoot. Don ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Patches for scrollkeeper...is scrollkeeper maintained?
On Wed, 2006-07-26 at 21:54 +0100, Don Scorgie wrote: Hopefully at some point soon, we can remove scrollkeeper entirely and replace it. Oh? Sounds interesting. What With? [Just out of interest... presumably the time to discuss across-the-platform architectural issues is before people write lots of code, not after] AfC Sydney ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
quote who=Emmanuele Bassi The GNOME Utilities package is a small package that GNOME has kept since the 1.x era (and before); it provides some application other than baobab, like the screenshoter, the file search dialog, the dictionary and the system log viewer, that are not sufficiently big to warrant their own package but at the same time are considered part of the basic offering of GNOME itself. I think Davyd's question was more about whether Baobab (or its function) is suitable to be considered part of the basic offering of GNOME itself. I am not convinced it should be there myself. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ Well, you know us usability folks... We like to believe that the two aren't mutually exclusive. - Calum Benson on power and cleanliness ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Tomboy in Desktop
quote who=Jeff Waugh Here's my point of view, completely independent from the fact that Tomboy is built with Gtk#/Mono. Here it is in point form, because I seem to be doing pretty well with it: I haven't really heard much of a critical response to these ideas, just more ber, Desktop, Desktop, Desktop, get it all in Desktop stuff. Why does it need to be in Desktop? Why do we have to jam everything in Desktop? Can we ship it in Powertools (a suite that has been proposed a couple of times)...? I think this is a really good time to have this discussion. - Jeff -- linux.conf.au 2007: Sydney, Australia http://lca2007.linux.org.au/ It doesn't matter if it is good, it only matters if it rocks. - Tenacious D, Rock Your Socks ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
On Wed, 2006-07-26 at 17:47 -0700, Jeff Waugh wrote: quote who=Emmanuele Bassi The GNOME Utilities package is a small package that GNOME has kept since the 1.x era (and before); it provides some application other than baobab, like the screenshoter, the file search dialog, the dictionary and the system log viewer, that are not sufficiently big to warrant their own package but at the same time are considered part of the basic offering of GNOME itself. I think Davyd's question was more about whether Baobab (or its function) is suitable to be considered part of the basic offering of GNOME itself. I am not convinced it should be there myself. As Jeff said. This smacks of KDE/GNOME 1.2 feature creep. Please don't get me wrong, it seems like a useful application (little rough around the edges, but that can be fixed), but does it belong in core GNOME? --d -- Davyd Madeley http://www.davyd.id.au/ 08B0 341A 0B9B 08BB 2118 C060 2EDD BB4F 5191 6CDA ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Patches for scrollkeeper...is scrollkeeper maintained?
On Thu, 2006-07-27 at 09:49 +1000, Andrew Cowie wrote: On Wed, 2006-07-26 at 21:54 +0100, Don Scorgie wrote: Hopefully at some point soon, we can remove scrollkeeper entirely and replace it. Oh? Sounds interesting. What With? As tired as I am of ScrollKeeper, no amount of effort in replacing it is going to cause it to go away any time soon. I consider our documentation system to be a core part of our platform, warts and all. And I'm taking backwards compatibility on this very seriously. So even post-replacement, I will slap any distros who don't include ScrollKeeper, or a suitable replacement package that provides the same binaries. [Just out of interest... presumably the time to discuss across-the-platform architectural issues is before people write lots of code, not after] Yeah, I'm not so sure about that any more. I'm becoming more and more convinced that specifications should grow out of well-specified and properly-implemented code. I've had numerous talks with Cornelius Schumacher (of KDE documentation fame) about a shared documentation system that would replace both ScrollKeeper and KDE's system. Interoperability would really kick ass here. Basically, I've complained for years that the day-to-day maintainence of Yelp has kept me from effectively working on the future. With Brent and Don picking up my slack on Yelp though, I really have no excuse. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Patches for scrollkeeper...is scrollkeeper maintained?
Don Scorgie wrote: Hi, On Wed, 2006-07-26 at 14:17 -0600, Elijah Newren wrote: Hi, Does scrollkeeper have any maintainers? I just found out about a Funny that you bring this up, I was thinking about this yesterday. bunch of patches needed for yelp to not choke on scrollkeeper files, listed at http://live.gnome.org/Yelp (all of the patches are part of bug 348013). It appears that the gnome-2.16 jhbuild moduleset has been patched to manually include these, but it'd be better to just get them upstream...if there is still an upstream (last scrollkeeper release was 2003). Anyone know more about this? AFAICT, 'E's passed on! This parrot is no more! He has ceased to be! 'E's expired and gone to meet 'is maker! 'E's a stiff! Bereft of life, 'e rests in peace! It is really annoying. There have been at least a few bugs filed against yelp about scrollkeeper problems. The last non-spam message to their mailing list was a couple of years ago, and that appears to have been shaunm, basically asking what was happening (the answer was I don't know of any plans). The patches linked are all from the Ubuntu scrollkeeper package. Hopefully at some point soon, we can remove scrollkeeper entirely and replace it. There are secret plans afoot. Don In the meantime, why don't we just import 0.3.14 (the last released version) into GNOME CVS and apply critical patches there, and point jhbuild to that? Any objections? We may be able to get commit access from the current project admins at sourceforge, but I'm not aware of their policy on overtaking unmaintained projects without the original authors permission. Anyone want to volunteer? License appears to be GLPL so I don't think there are any problems with this right? -- Brent Smith [EMAIL PROTECTED] IRC: smitten / #docs / irc.gnome.org ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Baobab
On Thu, 2006-07-27 at 10:35 +0800, Davyd Madeley wrote: As Jeff said. This smacks of KDE/GNOME 1.2 feature creep. Please don't get me wrong, it seems like a useful application (little rough around the edges, but that can be fixed), but does it belong in core GNOME? Is trying to find where all your disk space has gone a common and useful activity? I say yes[1]. - Callum [1] Although there is a strong argument this should be part of nautilus rather than a stand-alone app. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
