Re: Bring a conlusion please
And regarding what Gnome is and to whom it caters discussion, after 14 releases I think it's too late to start such a topic. It's never too late to reevaluate where you are, what you want to do, and how to do it. The computing environment that GNOME 1.0 fit into is different than the one 2.0 did, different from the one 2.14 did, and it will be different in 2.30 (maybe we'll hit 3.0 by then ;). Every so often, someone will propose *something* that won't fit into the current vision for what is GNOME and if it's compelling enough, that vision may have to be redefined. We've seen this debate come from mono-based applications for a while (vis-a-vis desktop environment vs. platform), and we're starting to see it with the software surrounding mobile platforms such as the N770 and OLPC. To say that we're going to keep GNOME focused on the same vision of a desktop that fueled 2.0 will only serve to limit possibilities and frustrate the developers who are working so hard on cool things. Lastly, Gnome needs a new next-gen language. Please elect/find a product manager that most Gnome devs and the Board agree that is good for the job (could even be someone inside the Board too, or the Board itself), let him read the lists, research and let him decide if the next-gen language of Gnome is Python, C# or Java. Point of the matter is that fewer and fewer graduates learn C++ and even fewer learn C. For Gnome to appeal to new programmers, a new, fully supported by Gnome, environment must be found. This is being stated over and over again for 3 years now, but no one does anything about it because people can't agree. This is why a product manager (or a Board that takes technical decisions) is much needed to give an end to these disagreements after they have studied all opinions and pros and cons. One of the strengths of the GNOME platform is that you're not limited to any one language. Blessing a single language as the next-gen language of GNOME will cause nothing but flamewars and animosity between people who are really working towards the same thing. We have excellent environments for both python and CLI languages, and a lot of the other bindings (such as Java and ruby) are improving rapidly. Surely a platform with robust bindings into many languages is a better option than just catering to the university-taught-platform du jour. -David ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
Alvaro Lopez Ortega wrote: Dan Winship wrote: [snip] And if your argument is really languages that come with their own frameworks are bad,and not just I hate mono, then why didn't you argue against allowing python-based apps in the platform when that came up a year and a half ago? I missed it. :-/ Actually, what is puzzling me is that nobody else did it. You cannot even imagine how many people think like this.. I guess there are too many interests around these adoptions, I don't know. In any case, IMHO using Python to develop basic desktops applications is as wrong as using Mono or any other framework. And, don't take me wrong. I said *basic* desktop applications. Projects like Alacarte are okay; those are applications that you may use once a week/month. However, when we speak about an applet that will be loaded each single time you boot for PC things change. We ought to be extra careful with those. I'm going to go ahead and pipe up here because I feel like I need to voice my opinion that Mono should _not_ be part of the core set of modules for the GNOME Desktop. This is for a number of concerns which have already been stated, but it boils down to 1) this is still too controversial of a topic to make a decision in a single six month release cycle (with only 3 or so months left) and 2) I think is a topic that should be left to ISVs to decide. That being said, I use tomboy/f-spot and I'm glad that a certain ISV packages Mono and applications based on it, but I don't see how adding it lends any coherence or consistency to the GNOME framework. -- Brent Smith [EMAIL PROTECTED] IRC: smitten / #docs ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bring a conlusion please
So, after 7 days of deliberations, what are the results? Is Mono/GTK# going to be included as part of the desktop OR binding 2.16.x platform, or not? A clear 'yes' or 'no' please. Is there a person or persons that can take this decision after having read the public opinion on this matter? [snip] Yes. The release team does this. It has done this every 6 months or so since 2.0, I believe: http://live.gnome.org/ReleasePlanning/Tasks 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
GnomeClient replacement?
Hello, the GnomeClient API is for some apps the single Gnome dependency that has no GTK equivalent and that keeps said apps tied to the 25 or so platform libraries. Other libgnome(ui) uses are gnome_program_init() and gnome_help_display() which can be replaced by gtk_init variants and directly spawning gnome-open or yelp. Could there be a per application analysis of whether GnomeClient is really needed and whether it can be discarded or replaced by using the simple X API directly? I see it's on the Ridley TODO list but with no alternative proposed. thank you Jani ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Memory consumption and virtual machines
On Tue, 2006-07-18 at 18:32 +, Federico Mena Quintero wrote: Novell already has a bunch of LDTP stuff to test the Evo mailer from the user's viewpooint - run those tests on the patched version to see how well they work. [Varadhan, those tests are already part of our QA process, aren't they?] Yes and Yes, they are part of our QA process and with the SoC thing, we are getting quite a good number of automation scripts that are compatible with Evolution 2.6. V. Varadhan Novell, Inc. Software for the Open Enterprise™ http://www.novell.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Memory consumption and virtual machines
On Tue, 2006-07-18 at 23:05 +, Philip Van Hoof wrote: If Novell wants me to implement unit tests (or other tests) for this, I will ask for payment. I am afraid that you won't get paid as Camel already has a neat-test-suite and can be used/extended, IMO. ;-) V. Varadhan Novell, Inc. Software for the Open Enterprise™ http://www.novell.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
Hey, On Wed, 19 Jul 2006, Jani Monoses wrote: the GnomeClient API is for some apps the single Gnome dependency that has no GTK equivalent and that keeps said apps tied to the 25 or so platform libraries. Other libgnome(ui) uses are gnome_program_init() and Yes! Fixing this will be very good for GNOME, and greatly reduce the cost of some our daemons. gnome_help_display() which can be replaced by gtk_init variants and directly spawning gnome-open or yelp. Well, the other thing that the gnome_program_init provides (as I understand it) is the bug-buddy hooks. However, IMHO, this is more of a distro thing. Ubuntu's solution (https://wiki.ubuntu.com/AutomatedProblemReports) seems to be better here, as distro specific stuff can make great efforts to get symbols, etc. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On 7/19/06, Ben Maurer [EMAIL PROTECTED] wrote: Well, the other thing that the gnome_program_init provides (as I understand it) is the bug-buddy hooks. However, IMHO, this is more of a distro thing. Ubuntu's solution (https://wiki.ubuntu.com/AutomatedProblemReports) seems to be better here, as distro specific stuff can make great efforts to get symbols, etc. Bt. Wrong. A couple things we know right now: * without what bug-buddy gives us currently, GNOME would be nigh-unusable. * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) So... stack traces going to distros instead of bugzilla ~= nigh-unusable GNOME. Now, many things could be done to improve this, of course- most concretely, I firmly believe the payoff on investment would be multiplied many times for the distros if they invested in a full-time bugmaster whose responsibility was coordination for getting bug information upstream and downstream. *If* they did that, or otherwise committed more thoroughly to getting their data upstream in a manner that was timely and useful, it might make sense for stack traces to go to the distros- as you point out it, it is easier for them to provide complete stack trace data. But in the current situation (distros don't have the tools to create the better stack traces, and don't have the tools to get bugs upstream, even if they did get better stack traces) this feature should be taken away over the dead bodies of the QA team. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On mer, 2006-07-19 at 03:28 -0400, Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) I though we were doing a pretty good job at forwarding Ubuntu bugs upstream, but apparently it looks like you don't appreciate the efforts, makes me wonder if we should bother keeping doing that then So... stack traces going to distros instead of bugzilla ~= nigh-unusable GNOME. There you assume than distros don't send back useful informations upstream and than distros are doing no QA. What we are trying to do with bugs about the Ubuntu desktop is to get something useful before forwarding them upstream. I would have no issue to just dump hundred of useless bugs and non-debug backtraces upstream and stop trying getting details for them if you think that would be better complete stack trace data. But in the current situation (distros don't have the tools to create the better stack traces, and don't have the Luis, have you read the Ubuntu spec pointed by Ben? A part of it is about getting better backtraces, Martin Pitt already did some good work on it and it's likely we will get automatic debug backtraces when something crash for Ubuntu edgy Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On Wed, 2006-07-19 at 10:21 +0200, Sebastien Bacher wrote: On mer, 2006-07-19 at 03:28 -0400, Luis Villa wrote: * distros are all crap at getting their bugs upstream, pretty much. (Some are slightly better than others, at various times.) I though we were doing a pretty good job at forwarding Ubuntu bugs upstream, but apparently it looks like you don't appreciate the efforts, makes me wonder if we should bother keeping doing that then I was in discussions with another maintainer of core GNOME modules (that shall remained anonymous), and we were not very impressed at the way Ubuntu forwarded bugs. Bugs caused by Ubuntu specific patches should not be able to make their way to the GNOME bugzilla, and patches that aren't brand or slight preferences fixing should have an upstream bugzilla. I have seen some patches showing up in b.g.o after having been in Ubuntu for months. Gathering backtraces should be done in launchpad before a bug is opened upstream, and it's not the case sometimes. So it's not perfect, but I'm sure you'll get there. Cheers -- Bastien Nocera [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus!
Federico said: Big tangent: the GNOME Certification plan will help in defining what is a good GNOME application and what isn't. That certification will include things like consistent lookfeel [insert a lot of handwaving about how to quantify this...] /me points to Gnome Accessibility Guide For Developers, http://developer.gnome.org/projects/gap/guide/gad , and Testing Gnome Applications for Accessibility: http://developer.gnome.org/projects/gap/testing/index.html Bill Federico -- Message: 5 Date: Wed, 19 Jul 2006 01:07:57 +0200 From: Philip Van Hoof [EMAIL PROTECTED] Subject: Re: [Evolution-hackers] Memory consumption and virtual machines To: desktop-devel-list@gnome.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On Tue, 2006-07-18 at 16:05 -0500, Federico Mena Quintero wrote: On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote: I've been talking to Philip on IRC, and gave him these requirements for his patch: 1. Don't change the external ABI of Camel, so that Evo needs no changes, *OR* also submit a patch to update Evo for the changed API. Achieved 2. Make sure the summary format on disk works with older Evos without making *them* rewrite the summaries. This is for deployments which have machines with old and new versions of GNOME, but NFS homedirs accessible from any machine. Achieved my renaming all the summary filenames 3. Keep the coding style, variable naming convention, indentation, etc. Done For you, attached and on a plate: o. The patch for evolution-data-server o. The patch for evolution-exchange Trying to get this upstream is, for me, saying thank you. Looking at the patch technically AND testing it (and if it doesn't perform, giving me numbers that compare it with the original implement- ation) is all I'm asking for. If Novell wants me to implement unit tests (or other tests) for this, I will ask for payment. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be -- next part -- A non-text attachment was scrubbed... Name: evolution_data_server__mmap_summary.diff.gz Type: application/x-gzip Size: 14012 bytes Desc: not available Url : /archives/desktop-devel-list/attachments/20060719/9407295b/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: evolution_exchange__mmap_summary.diff.gz Type: application/x-gzip Size: 871 bytes Desc: not available Url : /archives/desktop-devel-list/attachments/20060719/9407295b/attachment-0001.bin -- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list End of desktop-devel-list Digest, Vol 27, Issue 65 ** ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
the GnomeClient API is for some apps the single Gnome dependency that has no GTK equivalent and that keeps said apps tied to the 25 or so platform libraries. Other libgnome(ui) uses are gnome_program_init() and gnome_help_display() which can be replaced by gtk_init variants and directly spawning gnome-open or yelp Well, the other thing that the gnome_program_init provides (as I understand it) is the bug-buddy hooks. However, IMHO, this is more of a distro thing. Ubuntu's solution (https://wiki.ubuntu.com/AutomatedProblemReports) seems to be better here, as distro specific stuff can make great efforts to get symbols, etc. -- Ben gnome_program_init also loads the accessibility support, calling gconf in the process. It's not clear to me that this could conveniently be put elsewhere without complicating the dependencies of other modules... Bill ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus!
Do we know what level of accessibility is possible within the current mono framework? Do we know what level of accessibility is likely (e.g. with C# apps ported from other platforms?) Bill Haneman wrote: Federico said: Big tangent: the GNOME Certification plan will help in defining what is a good GNOME application and what isn't. That certification will include things like consistent lookfeel [insert a lot of handwaving about how to quantify this...] /me points to Gnome Accessibility Guide For Developers, http://developer.gnome.org/projects/gap/guide/gad , and Testing Gnome Applications for Accessibility: http://developer.gnome.org/projects/gap/testing/index.html Bill Federico -- Message: 5 Date: Wed, 19 Jul 2006 01:07:57 +0200 From: Philip Van Hoof [EMAIL PROTECTED] Subject: Re: [Evolution-hackers] Memory consumption and virtual machines To: desktop-devel-list@gnome.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On Tue, 2006-07-18 at 16:05 -0500, Federico Mena Quintero wrote: On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote: I've been talking to Philip on IRC, and gave him these requirements for his patch: 1. Don't change the external ABI of Camel, so that Evo needs no changes, *OR* also submit a patch to update Evo for the changed API. Achieved 2. Make sure the summary format on disk works with older Evos without making *them* rewrite the summaries. This is for deployments which have machines with old and new versions of GNOME, but NFS homedirs accessible from any machine. Achieved my renaming all the summary filenames 3. Keep the coding style, variable naming convention, indentation, etc. Done For you, attached and on a plate: o. The patch for evolution-data-server o. The patch for evolution-exchange Trying to get this upstream is, for me, saying thank you. Looking at the patch technically AND testing it (and if it doesn't perform, giving me numbers that compare it with the original implement- ation) is all I'm asking for. If Novell wants me to implement unit tests (or other tests) for this, I will ask for payment. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be -- next part -- A non-text attachment was scrubbed... Name: evolution_data_server__mmap_summary.diff.gz Type: application/x-gzip Size: 14012 bytes Desc: not available Url : /archives/desktop-devel-list/attachments/20060719/9407295b/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: evolution_exchange__mmap_summary.diff.gz Type: application/x-gzip Size: 871 bytes Desc: not available Url : /archives/desktop-devel-list/attachments/20060719/9407295b/attachment-0001.bin -- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list End of desktop-devel-list Digest, Vol 27, Issue 65 ** ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus!
On Wed, 2006-07-19 at 11:38, Brian Nitz wrote: Do we know what level of accessibility is possible within the current mono framework? I can't speak to possible. I would assume that with significant engineering resources it could be achieved. If the existing mono apps all use gtk# to create their GUIs, it might be reasonably straightforward. Otherwise it might take multiple-engineer-years. I haven't run mono/GTK# apps to see whether they export any ATK support already, perhaps the mono team can answer this? Do we know what level of accessibility is likely (e.g. with C# apps ported from other platforms?) If they don't use GTK#, I assume the answer is effectively none. Bill Bill Haneman wrote: Federico said: Big tangent: the GNOME Certification plan will help in defining what is a good GNOME application and what isn't. That certification will include things like consistent lookfeel [insert a lot of handwaving about how to quantify this...] /me points to Gnome Accessibility Guide For Developers, http://developer.gnome.org/projects/gap/guide/gad , and Testing Gnome Applications for Accessibility: http://developer.gnome.org/projects/gap/testing/index.html Bill Federico -- Message: 5 Date: Wed, 19 Jul 2006 01:07:57 +0200 From: Philip Van Hoof [EMAIL PROTECTED] Subject: Re: [Evolution-hackers] Memory consumption and virtual machines To: desktop-devel-list@gnome.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii On Tue, 2006-07-18 at 16:05 -0500, Federico Mena Quintero wrote: On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote: I've been talking to Philip on IRC, and gave him these requirements for his patch: 1. Don't change the external ABI of Camel, so that Evo needs no changes, *OR* also submit a patch to update Evo for the changed API. Achieved 2. Make sure the summary format on disk works with older Evos without making *them* rewrite the summaries. This is for deployments which have machines with old and new versions of GNOME, but NFS homedirs accessible from any machine. Achieved my renaming all the summary filenames 3. Keep the coding style, variable naming convention, indentation, etc. Done For you, attached and on a plate: o. The patch for evolution-data-server o. The patch for evolution-exchange Trying to get this upstream is, for me, saying thank you. Looking at the patch technically AND testing it (and if it doesn't perform, giving me numbers that compare it with the original implement- ation) is all I'm asking for. If Novell wants me to implement unit tests (or other tests) for this, I will ask for payment. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be -- next part -- A non-text attachment was scrubbed... Name: evolution_data_server__mmap_summary.diff.gz Type: application/x-gzip Size: 14012 bytes Desc: not available Url : /archives/desktop-devel-list/attachments/20060719/9407295b/attachment.bin -- next part -- A non-text attachment was scrubbed... Name: evolution_exchange__mmap_summary.diff.gz Type: application/x-gzip Size: 871 bytes Desc: not available Url : /archives/desktop-devel-list/attachments/20060719/9407295b/attachment-0001.bin -- ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list End of desktop-devel-list Digest, Vol 27, Issue 65 ** ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus!
Following up on my own post (sorry) On Wed, 2006-07-19 at 11:52, Bill Haneman wrote: . I haven't run mono/GTK# apps to see whether they export any ATK support already, perhaps the mono team can answer this? I see that there are ATK# bindings already, so it's definitely possible to support ATK using mono. Since the ATK interfaces are only currently used on Gnome and related platforms, it seems unlikely that C# apps ported from another platform would be accessible without additional work to explicitly provide the necessary ATK support - but at least the tools/apis are available in mono. Bill ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Time to heat up the new module discussion
From an embedded developers standpoint working with Gnome as a part of the Gnome Mobile and Embedded group, C and C++ are extremely relevant for our devices. Mono like .NET are quite frankly a no go in terms of memory and performance. Sean On 7/13/06, Ben Maurer [EMAIL PROTECTED] wrote: Hi On Fri, 14 Jul 2006, [ISO-8859-1] Steve Frécinaux wrote: Iain * wrote: I'm not really against having C# apps in the core (in fact I don't really mind), what I'm more frightening about is having applications that run all the time, using managed languages, and, as a consequence, taking up a fairly large amount of memory, from the computer start to the shutdown. Think about it: having an application you run a short time do not really impact on your available memory, so it's not a real issue on low-memory system (like mine: 224 Megs are not much memory these days), but long-running ones do. Please read my previous emails. Designing everything in C will not help. Evolution, OpenOffice and Firefox are evidence that writing your app in C does not make it memory efficient. In the long term, a moving GC may be beneficial. At some point, we also have to realize that users with less memory do need to make compermises. For example, such a user might want to choose not to use Beagle. -- Ben ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
What about Embedded?
Indeed, I find it ironic that in light of recent moves to expand the Gnome tent to include Mobile and Embedded devices as at GUADEC this year, that there is at the same time an effort to push MONO into the stack. At what price are these moves being made or considered? Like Havoc said, innovation at the cost of performance and memory usage is not innovation in my book. One item that Jeff mentioned at GUADEC that I recall is that it is not far from reality that their will be more Gnome embedded/mobile devices than desktop installs at some future date. This sort of development is going on full speed. I personally think more thought needs to be put into the decision than simply the inclusion of pet applications. Sean On 7/16/06, Havoc Pennington [EMAIL PROTECTED] wrote: Iain * wrote: Really? depends on your context... For some people a terminal and text editor are completely worthless, but take away photo management Once again, who are we targetting with the desktop. Apple know who they're targetting, which is probably why text editor and terminal are not high on the list of features. Yes! I was hoping your thread about this would catch fire instead of the one about mono, because answering the what is gnome anyhow? question would make the mono-type debates much simpler. If GNOME can't figure out a way to answer that question, its only option is to be a platform provider for Elisa, Maemo, SLED, Fedora, Ubuntu, Palm, Firefox, WINE, etc. etc. Those are all more focused, more target-audience-decided-upon solutions that in many cases use GNOME technology but diverge to a small or large extent from the GNOME desktop release because guess what, actually shipping something useful requires more focused, specific thinking. There's nothing wrong with the platform provider path, and it's probably inevitable by inertia and industry dynamic, but if taking that path it'd be interesting to do it consciously and optimize GNOME as a platform provider - with the providers of all those more focused solutions as the primary customers. And this _also_ helps answer the Mono debate - the question would become how to best serve the specific solutions and the teams building them. To me there are two hard parts to answering the target audience / what is GNOME question: 1) how does GNOME decide anything? it's a big swarm of people 2) which audience or focus to choose? Here's one way one might approach it. : Step 1. Collect underpants. j/k : Step 1. Redefine GNOME as in the original charter; provide an open source computing platform to the general public. Do this on the foundation level and get wide buy-in. Hammer the message consistently through the web site and other communications. The goal is to fight off the GNOME = desktop environment legacy. Note, platform in the charter I think has to be understood as environment or solution not as APIs - might be worth officially rewording in that way. In fact, I think it has to include both software bits AND finding some way to work with content and online services if there's a serious interest in offering open source alternatives to today's proprietary software companies. So, let's assume platform includes all that stuff for purposes of redefining GNOME in this way. : Step 2. Kill the single desktop release and replace it with target-audience-specific/solution-to-problem-specific more focused releases. For example, while they may not be interested, Maemo and Elisa would be candidates. The current desktop release should become one thing among peers; or it's even worth considering splitting it up to be multiple peers. Don't call the desktop release desktop either because it's too vague. More specific examples might be an enterprise unix/linux GUI release, or tech-oriented consumer/hobbyist release or tech workstation release or high-powered MS Office user in an office release or computer lab / thin client release or whatever people feel is the right focus. The word desktop is like a cancer. Its problems include: - it's vague as hell - includes a zillion target audiences and apps - it accepts an existing category definition (essentially, what windows and mac are) thus precluding meaningful innovation - it excludes content and online services - key elements of all the new stuff going on in the tech industry today The huge debate here is how to split things up; the important thing to remember is that there can be lots of code sharing (where it makes sense) between related offerings. So e.g. almost everything could use GTK, but only some offerings might want the GNOME panel. i.e., doing the split by _codebase_ is wrong; the split is by _target audience_ and _focus_; some splits might be worthwhile _just to change the default config options_ even. The technology can be made to support such things, and in fact it should be made to do so. Also of course, the split
Re: Time to heat up the new module discussion
Em Qua, 2006-07-19 às 06:48 -0500, Sean Kelley escreveu: From an embedded developers standpoint working with Gnome as a part of the Gnome Mobile and Embedded group, C and C++ are extremely relevant for our devices. Mono like .NET are quite frankly a no go in terms of memory and performance. Sean Isn't that true for a lot of the modules in the current desktop set already? Cheers, Evandro ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: What about Embedded?
On Wed, 2006-07-19 at 07:03 -0500, Sean Kelley wrote: Indeed, I find it ironic that in light of recent moves to expand the Gnome tent to include Mobile and Embedded devices as at GUADEC this year, that there is at the same time an effort to push MONO into the stack. At what price are these moves being made or considered? Like Havoc said, innovation at the cost of performance and memory usage is not innovation in my book. One item that Jeff mentioned at GUADEC that I recall is that it is not far from reality that their will be more Gnome embedded/mobile devices than desktop installs at some future date. This sort of development is going on full speed. I personally think more thought needs to be put into the decision than simply the inclusion of pet applications. The current proposal is to add GTK# to the official Bindings set, and Tomboy to the official Desktop set. The Platform set, which is the only set relevant to embedded devices, isn't changed, and unless I'm mistaken the current rules are that whilst Desktop applications can use Bindings, Platform is pure C. Personally, I have an interest in embedded use, but see no problem with GTK# entering Bindings. There are some great applications written in Python and C#, and none of them are useful in the embedded context as they are *desktop* applications. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
downstream bugs [was Re: GnomeClient replacement?]
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. -- Dan ___ 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 Wed, 2006-07-19 at 09:09 -0400, Dan Winship 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. Debian has something like this. It only does the syncing after the bug has been forwarded upstream, currently the bug has to be forwarded manually. http://lwn.net/Articles/182383/ has a summary. I presume launchpad.net does something similar. Ross -- Ross Burton mail: [EMAIL PROTECTED] jabber: [EMAIL PROTECTED] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF signature.asc Description: This is a digitally signed message part ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Memory consumption and virtual machines
I'm going to attempt to conclude this mini-thread that got extended to other mailing lists. On Wed, 2006-07-19 at 02:45 -0600, Veerapuram Varadhan wrote: I have created a branch exclusively for the camel mmap summary work, viz., mmapped-camel-summary-branch which will help Phillip to continue his research further. I'm going to let the patch rest for a few days so that you can take a good look at it and decide what needs improvement before it goes into that branch. Phillip: Make sure you don't change the format-of-summary-file too drastically, the \0 is acceptable though. We have the discuss this :). But lets do that in focused mailing lists like evolution-hackers. Federico, I would like it to be maintained and well tested in the branch rather then rushing it up in HEAD. IMO, a branch gives more freedom to do such research work than HEAD. Correct me if I am wrong. :-) I agree here. Bringing it to HEAD might be to early. Nevertheless would I be indeed very pleased if a lot people test this on a lot config- urations. Thanks for considering the patch. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On mer, 2006-07-19 at 09:52 +0100, Bastien Nocera wrote: I was in discussions with another maintainer of core GNOME modules (that shall remained anonymous), and we were not very impressed at the way Ubuntu forwarded bugs. Right, there is probably nothing to be impressed about but we try to get useful details (debug backtrace by example) and to forward as many upstream issues as possible, no doubt we could do better though. Anything special you would like to get changed from the bugs we forward? (saying that you are not very impressed doesn't give anything special to work on to make that better) Bugs caused by Ubuntu specific patches should not be able to make their way to the GNOME bugzilla I don't think Ubuntu maintainers are forwarding a lot of bugs due to Ubuntu patches upstream but maybe your experience is different? Users are a different issue. We try to push people to report bugs to Ubuntu when they are not sure of what they are doing so we can filter distribution specific ones before sending them upstream but we can't stop people using bug-buddy or bugzilla if they want and patches that aren't brand or slight preferences fixing should have an upstream bugzilla. I have seen some patches showing up in b.g.o after having been in Ubuntu for months. Agreed, that is an issue for pretty much every distribution around. I looked at some fedora, mandriva and suse packages for useful patches we could use for Ubuntu before dapper, and all of them have GNOME patches that would be welcome upstream and have not been forwarded, so nothing specific to Ubuntu on that, but right we should try to do better on that Gathering backtraces should be done in launchpad before a bug is opened upstream, and it's not the case sometimes. That's one of the things we are working one and what Luis was complaining about So it's not perfect, but I'm sure you'll get there. Right, it's far for being perfect at the moment but I think it's still better than sending everything directly upstream by bud-buddy (which was the point of my first mail). Note that the purpose of the mail was not to say Ubuntu does a particularly good job at it, but to point that the job done by distributions might not be perfect but is still something useful and there is no reason flooding directly upstream with distributions bug would be better for GNOME Cheers, Sebastien Bacher ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
On Sat, 2006-07-15 at 11:47 -0500, Shaun McCance wrote: Three of our proposed modules replace existing functionality in the desktop. We need to think about the migration path for our users. How we migrate has an effect on the documentation team as well, so I would like a very clear statement from the development teams about their plans. Come on, nothing? This is important. This is the sort of real software engineering discussion we'd be having if we weren't all busy talking with language wars. Having a cool application is no sufficient for inclusion in the desktop. We require stuff like working within our release cycle, working with our translators, and working with our documentation team. Tomboy has no documentation that I know of. Orca will require a *LOT* of documentation updates and additions in the Accessibility Guide and other places. Alacarte will involve changes to the User Guide. In at least two of these cases, I can't even begin to coordinate documentation efforts until I know how we plan to integrate the programs and migrate the users. I will not endorse a module that isn't cooperating with the documentation team, no matter how much I happen to like the program. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus!
On Wed, 2006-07-19 at 11:17 +0100, Bill Haneman wrote: Big tangent: the GNOME Certification plan will help in defining what is a good GNOME application and what isn't. That certification will include things like consistent lookfeel [insert a lot of handwaving about how to quantify this...] /me points to Gnome Accessibility Guide For Developers, http://developer.gnome.org/projects/gap/guide/gad , and Testing Gnome Applications for Accessibility: http://developer.gnome.org/projects/gap/testing/index.html The Testing guide is really nice, because it's essentially a checklist that you can run through your application. Bill, do you know if any of the points in there could be automatically checked with LDTP or some other ATK-based automation suite? Accessibility will definitely be one of the things required to attain the highest certification level for GNOME apps. I hope that (especially) governments will look for this high mark of certification. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus!
On Wed, 2006-07-19 at 11:38 +0100, Brian Nitz wrote: Do we know what level of accessibility is possible within the current mono framework? Do we know what level of accessibility is likely (e.g. with C# apps ported from other platforms?) Semi-informed reply (Mike Kestner, the gtk-sharp maintainer, will be able to inform you better): - Last I heard inside Novell, gtk-sharp was in the process of adding support for GObject interfaces, which are required to implement the a11y interfaces from C# itself --- you could always implement your accessible interfaces in straight C, but that's not fun :) - Plain GTK+ widgets (even if created from C# through gtk-sharp) of course already work out of the box when a11y is enabled. - As for C# apps ported from other platforms, do you mean stuff written with Windows Forms? I have no idea if that supports a11y at all, either on Windows or elsewhere. It may not be terribly hard to implement ATK interfaces for it. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Focusing on innovation re: mono, python et al
Hi, On Sun, 16 Jul 2006 18:57:04 +0200 Lluis Sanchez [EMAIL PROTECTED] wrote: [...] If there are memory and performance problems with Mono or Python, excluding them from GNOME is not a solution, because like it or not users will still use them to run applications. GNOME should adapt to this reality if it wants to survive. [...] I don't understand the argument: You're right that some users use Mono apps but others don't. So, why should GNOME adapt to one part of the user community, and ignore the other part? Users can already use Mono applications if they like to; it's just an 'apt-get install * ' away. No problem. Why should they care about Mono apps being included (in the desktop release)? Also, developers can already use Mono without GNOME depending Mono so why should the policy be changed? On the other hand, if GNOME depends on Mono, it will be hard to deinstall it without breaking GNOME. Just wait a few releases. This will fragment the user community, and we don't need any more fragmentation in the desktop: It's already bloody complicated to write an article for a journal when considering the differences between KDE and GNOME. It's frustrating to explain every time: Under KDE, you do this to get X, and under GNOME you do that to get X. If you don't write it, you just frustrate new users. Reading all this stuff is even more frustrating! Including Mono will just lead to another desktop being used widely, namely XFce. Splitting our user community will also lead to less influence. Third-party projects already ignore very basic HIG recommendations. And in fact: Why should they bother? It's not that GNOME appears to be the leading Linux desktop, isn't it? If we split due to the desktop release depending on Mono, it will be even harder to convince third-party projects to follow our example. I absolutely agree with you that it's the width and variety of available desktop applications that matter for the success of a desktop! At the same time, a (core) desktop is more useful the more people use it. Mono seems like a good platform so it should be able to sell itself. On the other hand, the risks of forcing users to opt-out instead of letting them opt-in are immense. Just my 2cents from a non-developer point of view. Cheers, Claus ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus!
On Wed, 2006-07-19 at 11:06 -0500, Federico Mena Quintero wrote: On Wed, 2006-07-19 at 11:38 +0100, Brian Nitz wrote: Do we know what level of accessibility is possible within the current mono framework? Do we know what level of accessibility is likely (e.g. with C# apps ported from other platforms?) Semi-informed reply (Mike Kestner, the gtk-sharp maintainer, will be able to inform you better): - Last I heard inside Novell, gtk-sharp was in the process of adding support for GObject interfaces, which are required to implement the a11y interfaces from C# itself --- you could always implement your accessible interfaces in straight C, but that's not fun :) GInterface registration for managed subclasses is our #1 feature request, other than perhaps Data Binding. GInterface reg will probably be the next substantial addition to Gtk#. Much of the work is already completed, but it won't be included in 2.10.x. 2.10.x looks to be an API tracking release only. -- Mike Kestner [EMAIL PROTECTED] ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
Hi Shaun: Tomboy has no documentation that I know of. Orca will require a *LOT* of documentation updates and additions in the Accessibility Guide and other places. Is there a place we can search to look for references to Gnopernicus? We're more than happy to submit patches to the various places needed - finding them all is the hard part. I will not endorse a module that isn't cooperating with the documentation team, no matter how much I happen to like the program. I certainly hope you do not sense a lack of cooperation on part of the Orca team. We're working very hard to be good community members and are going through the process as best we can understand it. If something has given you the impression that we are not cooperating, I'd like to know what it is so we can remedy it. Thanks! Will (Orca project lead) ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
On 7/15/06, Shaun McCance [EMAIL PROTECTED] wrote:
Alacarte has probably the easiest job here,
but I want to make sure that people will get
Alacarte whenever they ask for a menu editor.
A symlink in /usr/bin is probably sufficient.
As far as I know the only place gmenu-simple-editor is exposed in the
UI is the Edit Menus item in the menu applet context menu. Ubuntu
has a patch (attached) that makes this menu item call alacarte if it's
installed. What else would need to be done?
--
Travis Watkins
http://www.realistanew.com
diff -Nur gnome-panel-2.14.1/gnome-panel/panel-menu-bar.c gnome-panel-2.14.1.new/gnome-panel/panel-menu-bar.c
--- gnome-panel-2.14.1/gnome-panel/panel-menu-bar.c 2006-04-14 15:31:19.0 +0200
+++ gnome-panel-2.14.1.new/gnome-panel/panel-menu-bar.c 2006-04-14 15:31:20.0 +0200
@@ -469,10 +469,19 @@
} else if (!strcmp (callback_name, edit)) {
GError *error = NULL;
- panel_launch_desktop_file (gmenu-simple-editor.desktop,
- gmenu-simple-editor,
- screen,
- error);
+ if (panel_is_program_in_path (alacarte)) {
+ panel_launch_desktop_file (alacarte.desktop,
+ alacarte,
+ screen,
+ error);
+ }
+ else {
+ panel_launch_desktop_file (gmenu-simple-editor.desktop,
+ gmenu-simple-editor,
+ screen,
+ error);
+ }
+
if (error) {
panel_error_dialog (screen,
cannot_exec_gmenu-simple-editor, TRUE,
diff -Nur gnome-panel-2.14.1/gnome-panel/panel-menu-button.c gnome-panel-2.14.1.new/gnome-panel/panel-menu-button.c
--- gnome-panel-2.14.1/gnome-panel/panel-menu-button.c 2006-04-14 15:31:19.0 +0200
+++ gnome-panel-2.14.1.new/gnome-panel/panel-menu-button.c 2006-04-14 15:31:20.0 +0200
@@ -1004,10 +1004,19 @@
} else if (!strcmp (callback_name, edit)) {
GError *error = NULL;
- panel_launch_desktop_file (gmenu-simple-editor.desktop,
- gmenu-simple-editor,
- screen,
- error);
+ if (panel_is_program_in_path (alacarte)) {
+ panel_launch_desktop_file (alacarte.desktop,
+ alacarte,
+ screen,
+ error);
+ }
+ else {
+ panel_launch_desktop_file (gmenu-simple-editor.desktop,
+ gmenu-simple-editor,
+ screen,
+ error);
+ }
+
if (error) {
panel_error_dialog (screen,
cannot_exec_gmenu-simple-editor, TRUE,
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
Hi, On Wed, 2006-07-19 at 12:35 -0400, Willie Walker wrote: Hi Shaun: Tomboy has no documentation that I know of. Orca will require a *LOT* of documentation updates and additions in the Accessibility Guide and other places. Is there a place we can search to look for references to Gnopernicus? We're more than happy to submit patches to the various places needed - finding them all is the hard part. AFAIR, there is only a small section in the accessibility guide about the screen reader. It basically contains a link to online Help for Screen Reader and Magnifier. Does orca provide a magnifier? If so, all that is needed, in the first instance, is to change that link (to point to the new orca documentation). If it doesn't, there are probably other questions (like, what is replacing gnopernicus in the magnification stakes?). There is also section dealing with the Assistive Technologies preference tool in the Desktop guide that might need changing if it doesn't work the same way. FWIW, I was planning on updating the accessibility guide again (I updated it a little last cycle) once Feature freeze happened. Hopefully making the section on the onscreen keyboard and screen-reader and other bits a bit more thorough, instead of just a link to the documentation. Any help would be appreciated ;) Don ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Memory consumption and virtual machines
On Wed, 2006-07-19 at 17:40 +0200, Philip Van Hoof wrote: ... On the other hand, Philip, next time we meet in person I'll happily buy you dinner :) oh ... what about Boston? :) I'll check with my daytime employer whether it's okay if I can visit the Summit. I don't know for sure whether I'll be at the Summit. If not, next GUADEC, maybe? [Where do you live? I'm in Boston this week and the next.] Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Memory consumption and virtual machines
On Wed, 2006-07-19 at 01:10 -0600, Veerapuram Varadhan wrote: On Tue, 2006-07-18 at 23:05 +, Philip Van Hoof wrote: If Novell wants me to implement unit tests (or other tests) for this, I will ask for payment. I am afraid that you won't get paid as Camel already has a neat-test-suite and can be used/extended, IMO. ;-) ... On the other hand, Philip, next time we meet in person I'll happily buy you dinner :) Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Memory consumption and virtual machines
On Wed, 2006-07-19 at 09:53 -0500, Federico Mena Quintero wrote: On Wed, 2006-07-19 at 01:10 -0600, Veerapuram Varadhan wrote: On Tue, 2006-07-18 at 23:05 +, Philip Van Hoof wrote: If Novell wants me to implement unit tests (or other tests) for this, I will ask for payment. I am afraid that you won't get paid as Camel already has a neat-test-suite and can be used/extended, IMO. ;-) Aaaah, damn :) ... On the other hand, Philip, next time we meet in person I'll happily buy you dinner :) oh ... what about Boston? :) I'll check with my daytime employer whether it's okay if I can visit the Summit. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Memory consumption and virtual machines
I have to wonder if it's even worth ever merging the mmap hack into Evolution at all. If the plan is to finish Zucchi's disk-summary branch, which also solves the memory problems (afaik) as well as: 1. introducing an API for using cursors to get at message infos 2. better designed on-disk format that uses B-Trees the problem with philip's mmap file format is that the strings that will be hit for sorting/viewing/etc are all spread out over a huge number of pages. I just see this being re-examined later to try and design the format to better optimise it by compacting all the strings into a strtab type thing. I also don't like how it has to reload the summary anytime new messages arrive. I just don't get the feeling this is really all that well thought out and it scares me. I'd just hate to see a rush job come out of this Jeff On Tue, 2006-07-18 at 13:26 -0500, Federico Mena Quintero wrote: On Tue, 2006-07-18 at 18:29 +0200, Philip Van Hoof wrote: I'm waiting for the decision (yours) of making this optional using a compilation flag or at run-time. Let's do this in the usual manner: 0. Polish the patch in the usual way: make sure it follows the indentation and naming conventions of the surrounding code, etc. 1. Branch evolution-data-server into HEAD (development, with Philip's patch), and the stable branch (without the patch). 2. Make the patch *mandatory* in HEAD, so that it gets a good amount of testing. 3. ??? 4. Profit!!! I'd suggest that (3) become write a good stress-test suite for Camel, independent of Evolution. We need that anyway. Novell already has a bunch of LDTP stuff to test the Evo mailer from the user's viewpooint - run those tests on the patched version to see how well they work. [Varadhan, those tests are already part of our QA process, aren't they?] Federico ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Jeffrey Stedfast Evolution Hacker - Novell, Inc. [EMAIL PROTECTED] - www.novell.com ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: [Evolution-hackers] Memory consumption and virtual machines
Hi all, I second fejjs thoughts. Also i have been testing the patch for sometime now. Heres the inference: * The patch works in reducing the memory consumed during the initial startup of evolution. And it does a wonderful job of that. * The patch intends to fix the overall consumption of memory during the usage of evolution, and it does *not* do that. I kept evo running with this patch in for more than 8 hours and using Evo as i would use it regularly. (Reading of new mails, changing foldersblah! blah!) and more than a couple of hundred new mails later and modifying the summary file as many times we lose the memory gain we got initially. I *dont* have fancy graphs to display this information though - but i surely have the data and the necessary information i need. * mmap is *not* the solution to this problem - it helps to a certain extent. * Generating message list each we get a new message is bad enough - we dont want to reload the summary file each time. I still have not tested philips latest patches. I gather he has improvised on the older patches. Would report on the patches after i test them enough. Cheers, partha On Tue, 2006-07-18 at 14:46 -0400, Jeffrey Stedfast wrote: I have to wonder if it's even worth ever merging the mmap hack into Evolution at all. If the plan is to finish Zucchi's disk-summary branch, which also solves the memory problems (afaik) as well as: 1. introducing an API for using cursors to get at message infos 2. better designed on-disk format that uses B-Trees the problem with philip's mmap file format is that the strings that will be hit for sorting/viewing/etc are all spread out over a huge number of pages. I just see this being re-examined later to try and design the format to better optimise it by compacting all the strings into a strtab type thing. I also don't like how it has to reload the summary anytime new messages arrive. I just don't get the feeling this is really all that well thought out and it scares me. I'd just hate to see a rush job come out of this Jeff On Tue, 2006-07-18 at 13:26 -0500, Federico Mena Quintero wrote: On Tue, 2006-07-18 at 18:29 +0200, Philip Van Hoof wrote: I'm waiting for the decision (yours) of making this optional using a compilation flag or at run-time. Let's do this in the usual manner: 0. Polish the patch in the usual way: make sure it follows the indentation and naming conventions of the surrounding code, etc. 1. Branch evolution-data-server into HEAD (development, with Philip's patch), and the stable branch (without the patch). 2. Make the patch *mandatory* in HEAD, so that it gets a good amount of testing. 3. ??? 4. Profit!!! I'd suggest that (3) become write a good stress-test suite for Camel, independent of Evolution. We need that anyway. Novell already has a bunch of LDTP stuff to test the Evo mailer from the user's viewpooint - run those tests on the patched version to see how well they work. [Varadhan, those tests are already part of our QA process, aren't they?] Federico ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers -- Parthasarathi Susarla [EMAIL PROTECTED] Novell Software Development (I) Ltd. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
On Wed, 2006-07-19 at 12:35 -0400, Willie Walker wrote: Hi Shaun: Tomboy has no documentation that I know of. Orca will require a *LOT* of documentation updates and additions in the Accessibility Guide and other places. Is there a place we can search to look for references to Gnopernicus? We're more than happy to submit patches to the various places needed - finding them all is the hard part. I will not endorse a module that isn't cooperating with the documentation team, no matter how much I happen to like the program. I certainly hope you do not sense a lack of cooperation on part of the Orca team. We're working very hard to be good community members and are going through the process as best we can understand it. If something has given you the impression that we are not cooperating, I'd like to know what it is so we can remedy it. What I am primarily concerned with is how we intend to migrate users from Gnopernicus to Orca. It's not an issue of finding the references to Gnopernicus in the documentation. The team is perfectly capable of writing and editing, when they know what to write and edit. (In the case of accessibility tools, however, we often need more help from the developers, because many of us don't understand the technologies very well.) What's important to me is what happens to a Gnome 2.14 user who upgrades to 2.16. Will we automatically migrate her to Orca from Gnopernicus? How will her settings be migrated? How will her settings inter-operate with Gnopernicus if she has multiple machines using the same home directory? What sorts of problems is she likely to encounter, and how can we address those problems in the documentation? For the record, from what I've seen, I love Orca. I think it's the right move for Gnome, and I'm glad the Gnopernicus folks are in favor of it. But we have to be very careful about how we manage migrations, because the sorts of people who use Gnopernicus and Orca will be completely screwed if something goes wrong with them. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
On Wed, 2006-07-19 at 11:37 -0500, Travis Watkins wrote: On 7/15/06, Shaun McCance [EMAIL PROTECTED] wrote: Alacarte has probably the easiest job here, but I want to make sure that people will get Alacarte whenever they ask for a menu editor. A symlink in /usr/bin is probably sufficient. As far as I know the only place gmenu-simple-editor is exposed in the UI is the Edit Menus item in the menu applet context menu. Ubuntu has a patch (attached) that makes this menu item call alacarte if it's installed. What else would need to be done? Binary names constitute a public interface. Maybe we didn't officially declare those interfaces as stable, but without other stable interfaces to do the same thing, third-party developers will use them. So from the patch, it looks to me like gmenu-simple-editor would still be installed, but Alacarte would instead be called if it's found. I find this very disconcerting. Shifty interfaces like this are a huge pain for documentation. Some distro will choose not to install Alacarte, and then the documentation will be wrong for those users. (Then again, right now we have the converse problem with Ubuntu including Alacarte.) Why have two programs to do the same thing? If we like what Alacarte is doing, why don't we just make the menu editor we have do that? Or why don't we just replace it with Alacarte, either by putting it in gnome-panel, or by making gnome-panel depend on it? -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
Bill Haneman wrote: gnome_program_init also loads the accessibility support, calling gconf in the process. It's not clear to me that this could conveniently be put elsewhere without complicating the dependencies of other modules... This is a broken hack that should have been killed long ago, should never have been allowed into libgnome at all since it means that gtk-only apps need to either cut-and-paste the code or just not be accessible, despite having all the other a11y code already in gtk. It can be done with e.g. a GTK_MODULE instead, iirc. or perhaps an xsetting type of deal to get the gconf flag into gtk itself. I remember threatening long ago to kill the cut-and-paste from metacity after a release or two if nobody fixed this properly; Elijah, you should do that, I think it's been maybe two years or more! Fortunately Elijah is probably nicer than me and won't enforce the threat ;-) There's a metacity bug about it iirc. This has got to be a perfect poster child for why maintainers should reject broken half-measures on grounds that nobody will fix it properly once you accept a broken patch. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
I would love to write documentation for Tomboy, and fully intend to. But as my users have not requested it, and Tomboy's acceptance into GNOME is still totally up in the air for other reasons, I hope you can understand why I've held off on it in favor of other endeavors. -Alex Shaun McCance wrote: Tomboy has no documentation that I know of. Orca will require a *LOT* of documentation updates and additions in the Accessibility Guide and other places. Alacarte will involve changes to the User Guide. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
On Wed, 2006-07-19 at 10:50 +1000, Jeff Waugh wrote: A fucking amazing platform isn't an accident, and we need a fucking amazing platform to bring more developers to GNOME - both internal developers and external developers. One of our *crucial* audiences must be FLOSS hackers and ISDs. If we don't satisfy them, we can't build our own momentum for building this amazing software stack, and we can't build an ecosystem with opportunities for everyone else. The GNOME platform is pretty much *done* at this point from the viewpoint of what more code do we need?. - We have support for most human languages. - We have a tremendously powerful and rich GUI toolkit. - We (finally!) have a printing API that doesn't suck. - We have excellent accessibility at the toolkit level. - We have a good way to store configuration data. - We have a rich multimedia API. - etc. In terms of code and APIs, we are *done*. If you remember the Advisory Board meeting at GUADEC, what ISDs asked for was not more APIs, but the polish things: - High-level documentation (not done) - Overviews of the platform (done! Thanks, Shaun!) - Detailed descriptions of the platform's architecture (not done) - Stability guarantees (in progress) - Official word on which API you should use for what (in progress) - Performance tuning to make the platform leaner (in progress) Let me repeat: the platform is *DONE* in terms of code. We need the fit and finish now. Paint, polish, varnish, carpeting, and a nice glossy pamphlet to guide you through the beautiful building that is our architecture. Gaudí would be proud of its organic nature. [If you want to be pedantic and are looking for missing APIs, you can count them on even less than four toes: a lockdown API instead of reading ill-documented GConf keys, and oh, screw it, I can't think of any others right now.] GNOME is a *great* platform to build desktop-ish apps *right now*. That's our platform's space. People who get scared that Web 2.0 is going to replace us need to remember that the web needs a good web browser to run on, and that web browser needs a toolkit to be written in, and that toolkit is GNOME. It's there right now and it works. All the advancements in software for end users are happening elsewhere: in the web, and in high-level languages. That's fine. That stuff also needs a desktop-ish foundation to be built upon, and that foundation is GNOME. Only people who haven't written large-scale software think that it can be written efficiently in a low-level language. That's why most of the programming world is moving to high-level stuff: it's why companies write their internal software in Java, why Microsoft is writing their new software in C#, why all the cool/new end-user apps in free software are using Python and C# and Java... and you know what? Under all that high-level amazing stuff lies a foundation pretty much like GNOME: let that be the historic Win32 (in C and assembler since 1983, baby!), the historic Apple libraries (all the way from NextStep!), or GTK+ (11 years old!) and libgnome* themselves (almost 10 years old now!). Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
Hi Shaun: What's important to me is what happens to a Gnome 2.14 user who upgrades to 2.16. Will we automatically migrate her to Orca from Gnopernicus? How will her settings be migrated? As of right now, we are not planning to migrate user preferences from Gnopernicus to Orca. We've not seen any demand for this from our users (whom we interact with daily) and prefer not to add the complexity if we don't need it. These words may come across a bit stronger than I intend them too, though, so please read on. :-) The setup for Orca is relatively simple (we provide both a self-voicing text-based setup and a GUI-based setup), and the user is automatically placed in setup mode the first time they run Orca. Furthermore, Orca is also designed to run in the absence of any settings. As a result, the following scenario should just work: 1) The user's session is set up to automatically launch the screen reader, which happens to be gnopernicus. 2) The user's machine is updated, replacing gnopernicus with orca. 3) The next time the user logs in, the screen reader (which is now orca) will be launched. In this user environment, Orca will detect that accessibility is enabled, automatically find a working speech synthesis driver, connect to BrlTTY if it is running, and bring up the Orca configuration GUI, which the user can navigate using Orca. A big question for me is what does it mean to be 'the screen reader' and how does it get launched (much like what it means to be 'the web browser' or 'the e-mail reader')? This is something outside of the control of Gnopernicus and Orca, and I'm not sure how this works. Guidance here would be greatly appreciated. If there is a real world use case for why importing Gnopernicus settings is a necessity, however, we can look at importing them. How will her settings inter-operate with Gnopernicus if she has multiple machines using the same home directory? The settings for the two are completely separate at the moment. I'd really hesitate trying to combine them. It could get rather ugly and might screw the user more easily than keeping them separate. What sorts of problems is she likely to encounter, and how can we address those problems in the documentation? We've been keeping a list of FAQs and such at the Orca WIKI: http://live.gnome.org/Orca From my experience, many of the problems the user will encounter are related to audio configuration. Bad configuration of the audio (outside our control, unfortunately) will usually result in Orca and/or Gnopernicus being silent. We try to offer some coping/debugging strategies for how to determine where the failure occurs. For the record, from what I've seen, I love Orca. I think it's the right move for Gnome, and I'm glad the Gnopernicus folks are in favor of it. Thanks! The Gnopernicus folks are a great team. They've also been contributing to Orca over the past few weeks and I'm happy to have people with their skills and experience on board. But we have to be very careful about how we manage migrations, because the sorts of people who use Gnopernicus and Orca will be completely screwed if something goes wrong with them. Agreed. Our focus for Orca has, and always will be, the users. My mantra for the project is let the user requirements drive the architecture, not the other way around. Will ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus!
On Wed, 2006-07-19 at 11:02 -0500, Federico Mena Quintero wrote: On Wed, 2006-07-19 at 11:17 +0100, Bill Haneman wrote: Big tangent: the GNOME Certification plan will help in defining what is a good GNOME application and what isn't. That certification will include things like consistent lookfeel [insert a lot of handwaving about how to quantify this...] /me points to Gnome Accessibility Guide For Developers, http://developer.gnome.org/projects/gap/guide/gad , and Testing Gnome Applications for Accessibility: http://developer.gnome.org/projects/gap/testing/index.html The Testing guide is really nice, because it's essentially a checklist that you can run through your application. Bill, do you know if any of the points in there could be automatically checked with LDTP or some other ATK-based automation suite? Keyboard bindings are queryable via ATK, so you can do some of the testing automatically, but I think ultimately you need a human to do part of this: you'll only see stuff via ATK if it's already at least somewhat accessible. I believe many of the specific test cases are automatable, for example KEY__001: You could automatically inject keyboard events to simulate tabbing through the UI, and look at the XY extents of the widgets, and flag bogus tab orderings that way. Accessibility will definitely be one of the things required to attain the highest certification level for GNOME apps. I hope that (especially) governments will look for this high mark of certification. Federico ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
I have to disagree. As I recall the history, it was the GTK_MODULES/gtk+ fix that caught most of the flak (and still does, relying as it does on an env variable). At the time that the gconf key for assistive technology support was first introduced, nobody called it a hack. Now that we have xsettings in gtk+ I agree though that an XSETTING makes more sense. Bill On Wed, 2006-07-19 at 18:34, Havoc Pennington wrote: Bill Haneman wrote: gnome_program_init also loads the accessibility support, calling gconf in the process. It's not clear to me that this could conveniently be put elsewhere without complicating the dependencies of other modules... This is a broken hack that should have been killed long ago, should never have been allowed into libgnome at all since it means that gtk-only apps need to either cut-and-paste the code or just not be accessible, despite having all the other a11y code already in gtk. It can be done with e.g. a GTK_MODULE instead, iirc. or perhaps an xsetting type of deal to get the gconf flag into gtk itself. I remember threatening long ago to kill the cut-and-paste from metacity after a release or two if nobody fixed this properly; Elijah, you should do that, I think it's been maybe two years or more! Fortunately Elijah is probably nicer than me and won't enforce the threat ;-) There's a metacity bug about it iirc. This has got to be a perfect poster child for why maintainers should reject broken half-measures on grounds that nobody will fix it properly once you accept a broken patch. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: GnomeClient replacement?
On Wed, 2006-07-19 at 17:01, Shaun McCance wrote: Hey Bill, As usual, I'm afraid most of us don't understand all the layers as well as we ought to. Could you clarify exactly which pieces of the accessibility stack wouldn't get activated? There are a lot of GTK-only applications, probably a couple inside Gnome. What are these applications missing out on? For now, as pure gtk+ apps are relying on gnome-session to set the GTK_MODULES environment variable to load the modules gail and atk-bridge. This is not really optimal but it works well enough for gtk+-only apps (some apps that use gtk+, such as mozilla/firefox, have to take measures to un-set this variable and do their own accessibility work based on the gconf key). What we really want is for all desktop apps to have a way of detecting the need for assistive technology support without having the environment tell them what modules they must load in order to get it - in this sense the GTK_MODULES solution makes the apps accessible as a side effect, rather than providing clear semantics as does gconf. A boolean XSETTING would probably be nicer since it would allow apps to make their own decisions on what modules should be loaded in order to enable assistive technologies. This would mean that gtk+ would incur a soft dependency on libgail and at-spi which it currently does not have, but at this stage in the history of ATK this would probably be acceptable. It has been proposed that gail be rolled into gtk+ at some point, which would be very helpful (as a separate module, it can be very awkward to poke into gtk+ widgets to the extent necessary in order to implement ATK on their behalf). The $GTK_MODULES approach also fails for embedded apps and things that use gtkplug/gtksocket, since for those apps an additional module (libgail-gnome) must be loaded - unless we don't mind pure gtk+ apps loading that module needlessly. regards Bill -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
On Wed, 2006-07-19 at 10:43 -0700, Alex Graveley wrote: I would love to write documentation for Tomboy, and fully intend to. But as my users have not requested it, and Tomboy's acceptance into GNOME is still totally up in the air for other reasons, I hope you can understand why I've held off on it in favor of other endeavors. Just to make things clear, we do not require that new modules have existing documentation. Existing documentation certainly eases the burden on the documentation team, particularly for large applications (for instance, when Evolution was proposed). But the documentation team can and will write new documentation for accepted modules. We only ask that the maintainers be cooperative. This means answering questions about obscure behavior and helping us address problems users might encounter, including migration problems. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
Federico Mena Quintero wrote: GNOME is a *great* platform to build desktop-ish apps *right now*. Tech-wise strongly agree; ecosystem-wise no, because the number of users is too low for (non-hobbyist/volunteer) developers to care. That's our platform's space. People who get scared that Web 2.0 is going to replace us need to remember that the web needs a good web browser to run on, and that web browser needs a toolkit to be written in, and that toolkit is GNOME. It's there right now and it works. All the advancements in software for end users are happening elsewhere: in the web, and in high-level languages. That's fine. That stuff also needs a desktop-ish foundation to be built upon, and that foundation is GNOME. While I agree with most of your post, here I think you're missing an important point: - for almost everyone in the world, that foundation is _not_ GNOME. It's some other desktop. - in fact much of the recent innovation does not work on GNOME, and many of us don't notice since we just don't use sites like MySpace and Xanga, or commercial music services, or whatever, and thus don't experience their frequent IE/Windows-specificity i.e. just because people use/need a desktop doesn't mean they use/need any desktop or specifically our desktop. The benefit to audience has to be *vs what they have* not *vs nothing* The relevance of not-just-a-desktop as a direction is that it allows you to think about this question. make a desktop alone almost by definition means failure - it defines the project as an existing product category that everyone already owns - why do they need a new one? GNOME at least needs to say make a desktop that ___ though for many cases of that ___ the desktop aspect will be an artificial addition rather than an essential element of the user benefit, and thus very vulnerable to someone offering the same benefit minus the desktop requirement. I always have to add the disclaimer that people are free to be disinterested in market share, mass adoption, and what have you. There are many other measures of success. However, to me it's very clear that make a desktop has no chance of getting to 10x10 - this is the safe yet guaranteed-to-fail path. Havoc ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
Respectfully, I don't agree. There is a big set of missing frameworks that stops rich interop in Gnome applications, and generally make applications much harder to write well. All other desktop platforms include at least a subset of these... * Document framework Provides document loading/saving/printing/etc abstractions, window/tab management, automatic recently used, scripting hooks, etc. * Scripting framework Allows apps to easily expose external scripting and event notification. D-BUS was the big missing piece here. Can specify sets of interfaces for common tasks that apps can implement, and building up the frameworks to provide useful default implementations. * Rich Extension/Plugin framework Common UI for installing/removing plugins and checking for updates and downloading, common hooks for menu/toolbar integration and UI event integration. * Undo framework Almost no applications in Gnome support good Undo. Should provide both reliable desktop-wide interaction for text widgets as well as at an abstract object level. * Rich DND/CopyPaste framework Undocumented DND targets, poor support, and manual data parsing abound in our applications. Could provide structured data interop to make doing this loads easier. * Persistence framework Saving and indexing application-internal data, optionally exposing to search engines like beagle. Each one of these is a really large amount of work that doesn't exist at all today, with various bits being implemented from scratch in every application. -Alex Federico Mena Quintero wrote: The GNOME platform is pretty much *done* at this point from the viewpoint of what more code do we need?. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Migration Paths for New Modules
On Wed, 2006-07-19 at 14:03 -0400, Willie Walker wrote: A big question for me is what does it mean to be 'the screen reader' and how does it get launched (much like what it means to be 'the web browser' or 'the e-mail reader')? This is something outside of the control of Gnopernicus and Orca, and I'm not sure how this works. Guidance here would be greatly appreciated. I'm not entirely sure about this either, and I'm not sure who's responsible for this. Looking at the accessibility preferences, I see the following label on this machine: No Assistive Technology is available on your system. The 'gok' package must be installed in order to get on-screen keyboard support, and the 'gnopernicus' package must be installed for screenreading and magnifying capabilities. (Why isn't that label selectable? And who thought that screenreading is a word? It's two words, except that it's a compound adjective in this case, so it should be hyphenated.) With a label like that, it seems to me that the tools are hard-coded somewhere. That capplet, at least, is found inside control-center, but I don't know what module is responsible for actually launching the screen reader. If there is a real world use case for why importing Gnopernicus settings is a necessity, however, we can look at importing them. How will her settings inter-operate with Gnopernicus if she has multiple machines using the same home directory? The settings for the two are completely separate at the moment. I'd really hesitate trying to combine them. It could get rather ugly and might screw the user more easily than keeping them separate. I wouldn't necessarily worry about Gnopernicus's and Orca's settings. What I'm worried about is if we have a GConf setting under /desktop/gnome for which accessibility tools to use, and how to launch them. Selecting Orca on a system with Orca could then seriously mess up an older system, if we're not careful about the implementation. This isn't necessarily something the Orca team needs to concern itself with. Rather, it's something we need to deal with in whatever desktop modules glue this together. -- Shaun ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
On 7/19/06, Alex Graveley [EMAIL PROTECTED] wrote: Respectfully, I don't agree. There is a big set of missing frameworks that stops rich interop in Gnome applications, and generally make applications much harder to write well. All other desktop platforms include at least a subset of these... * Document framework Provides document loading/saving/printing/etc abstractions, window/tab management, automatic recently used, scripting hooks, etc. * Scripting framework Allows apps to easily expose external scripting and event notification. D-BUS was the big missing piece here. Can specify sets of interfaces for common tasks that apps can implement, and building up the frameworks to provide useful default implementations. * Rich Extension/Plugin framework Common UI for installing/removing plugins and checking for updates and downloading, common hooks for menu/toolbar integration and UI event integration. * Undo framework Almost no applications in Gnome support good Undo. Should provide both reliable desktop-wide interaction for text widgets as well as at an abstract object level. * Rich DND/CopyPaste framework Undocumented DND targets, poor support, and manual data parsing abound in our applications. Could provide structured data interop to make doing this loads easier. * Persistence framework Saving and indexing application-internal data, optionally exposing to search engines like beagle. I'd add: * collaboration framework (though maybe the Abi guys are pushing in this direction in a way we can all use) * web integration framework- we know that MS is going to make all their apps backend to various web services in the not-too-far future, and we know that we can make our apps much more compelling if (for example) f-spot integrated seamlessly with web-based picture sharing, or gourmet integrated seamlessly with web-based recipe sharing. * search framework. Luis ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
Alex Graveley wrote: * Persistence framework Saving and indexing application-internal data, optionally exposing to search engines like beagle. Already mostly done in Tracker. Tracker's database can store just about any first class object complete with extensible metadata, tags and links. All thats needed it to extend Tracker's Dbus interface to cover the particular need. EG Tomboy notes could be stored directly in Tracker's DB instead of to a file. Tracker automatically indexes anything in its database which can be searched without Beagle (you can disable tracker's indexing if you want to use an external indexer like Beagle). All thats needed is to define a set of Dbus methods (SaveNote, LoadNote, LinkNote etc) for the Notes first class object. Tracker will also fill in the search framework too as well as the persistence/metadata DB stuff as well (when its finished - give it 3 months!) -- Mr Jamie McCracken http://jamiemcc.livejournal.com/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: focus!
On Wed, 2006-07-19 at 11:26 -0500, Mike Kestner wrote: On Wed, 2006-07-19 at 11:06 -0500, Federico Mena Quintero wrote: Semi-informed reply (Mike Kestner, the gtk-sharp maintainer, will be able to inform you better): - Last I heard inside Novell, gtk-sharp was in the process of adding support for GObject interfaces, which are required to implement the a11y interfaces from C# itself --- you could always implement your accessible interfaces in straight C, but that's not fun :) GInterface registration for managed subclasses is our #1 feature request, other than perhaps Data Binding. GInterface reg will probably be the next substantial addition to Gtk#. Much of the work is already completed, but it won't be included in 2.10.x. 2.10.x looks to be an API tracking release only. This is very good news. Thank you so much for wanting to implement this. When are the C# demos, that implement GTypeInterface's, going to be thrown at us? I can't wait for this to happen! Next to a very good IDE (like MonoDevelop), this is going to help us build a GNOME 3.0 platform that cares about higher level programming languages, that integrates with it, that will leverage the techniques, framework interfaces and components that are typically used with the programming environment. I will definitely be one of the contributors that will be working on bringing GNOME things closer to the .NET world, on helping Mono to be that next generation development platform. Lets innovate. Lets go for it. Lets make things better. http://www.funnypics.cc/en/philips_lets_make_things_better_764.php I thank you. -- Philip Van Hoof, software developer at x-tend home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org work: vanhoof at x-tend dot be http://www.pvanhoof.be - http://www.x-tend.be ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Focusing on innovation re: mono, python et al
ons, 19 07 2006 kl. 12:48 +0200, skrev Claus Schwarm: Hi, On Sun, 16 Jul 2006 18:57:04 +0200 Lluis Sanchez [EMAIL PROTECTED] wrote: [...] If there are memory and performance problems with Mono or Python, excluding them from GNOME is not a solution, because like it or not users will still use them to run applications. GNOME should adapt to this reality if it wants to survive. [...] I don't understand the argument: You're right that some users use Mono apps but others don't. So, why should GNOME adapt to one part of the user community, and ignore the other part? Users want good applications, Mono is a really good foundation to build good applications rapidly on. Tomboy, Banshee, Beagle - all applications that have good testing, good stability and a rapid development cycle meaning we can deploy functionality with the users with every cycle. For developers using Mono means we get a free development environment that integrates with GNOME, it's basically unlike python, java, etc. a platform that cares about GNOME and provides GNOME style tools for us to work with - if we bless it today we get the tools today as well, no waiting required. One thing I miss from my college days is visual studio for development, it was a great tool and to date only MonoDevelop comes close within GNOME - you'd be surprised how much this means for some developers. Users can already use Mono applications if they like to; it's just an 'apt-get install * ' away. No problem. Why should they care about Mono apps being included (in the desktop release)? Also, developers can already use Mono without GNOME depending Mono so why should the policy be changed? Users don't care if an application is based on Mono, they care if it's functional, stable and snappy. Blessing Mono is largely a decision for future developers - e.g. I was trained in C++ and Intel ASM when I attended college but I absolutely refuse to write another line of C/C++ in my life after discovering C# - it makes programming fun and it does most of the boring work for me so that I can spend my time making applications rather than chasing common idiotic problems. On the other hand, if GNOME depends on Mono, it will be hard to deinstall it without breaking GNOME. Just wait a few releases. So.. why should users care, if Mono provides the user with good applications that does what he/she wants why would there be any reason to remove it - if you don't run the applications that require Mono all you lose is the bit of space it takes up (much like many GNOME distros ship QT as well) - unless you are on the OLPC or Maemo platform this shouldn't be a big issue. This will fragment the user community, and we don't need any more fragmentation in the desktop: It's already bloody complicated to write an article for a journal when considering the differences between KDE and GNOME. It's frustrating to explain every time: Under KDE, you do this to get X, and under GNOME you do that to get X. If you don't write it, you just frustrate new users. Reading all this stuff is even more frustrating! As if the question of Mono's inclusion doesn't already fragment GNOME, those who are opposed to it because it's MS technology or similar, IMHO, silly reasons (read: not based on technological merit) won't let it in. Then there are people like me who have been waiting for the right moment for Mono to get included so that one day I might rely on Mono for any development I do - I'm frankly getting to the point where if Mono doesn't get included, I'll simply stop using GNOME. I'm getting tired of this debate, I think Mono is great and I think continuing to push a C based platform is a mistake.. We are handed great technology to move GNOME forward, do we want that or are we willing to bet that C is a viable option for Topaz. If you think that not including Mono is a way to keep users you are mistaken, there are plenty out there who will not switch over or leave GNOME if we don't take this step. Including Mono will just lead to another desktop being used widely, namely XFce. Why would this be? remember so long as applications rock users will want to use them - be that in GNOME, XFce, KDE, etc. Mono apps across the board pretty much rock already, f-spot is the best photo management tool out there, banshee for my money is a much more snappy application than rhythmbox (not to mention more stable), Blam! can't be beaten for RSS feed reading. Yes, we need to optimize those applications, just like every other application we ship - Evolution being the prime example that even a C application written by good programmers can be a horror to use - it's slow and eats your ram for breakfast. Untill we have good data we can't really say anything about Mono' ressource consumption longterm, I believe that Mono based applications can be made to run at least as well as 90% of what we have currently in C - some claim that we could actually optimize better in a high level language
Re: GnomeClient replacement?
On Wed, Jul 19, 2006 at 11:36:28AM +0100, Bill Haneman wrote: Well, the other thing that the gnome_program_init provides (as I understand it) is the bug-buddy hooks. However, IMHO, this is more of a distro thing. Ubuntu's solution (https://wiki.ubuntu.com/AutomatedProblemReports) seems to be better here, as distro specific stuff can make great efforts to get symbols, etc. -- Ben gnome_program_init also loads the accessibility support, calling gconf in the process. It's not clear to me that this could conveniently be put elsewhere without complicating the dependencies of other modules... Another thing which needs to be done there is for example setting up the URI handler for GtkLinkButton. There'll always be some things which need to be initialized in a way depending on the platform. As for the URI handler, the handler will differ on UNIX, Win32, OS X, etc. During GUADEC Matthias and I talked about maybe having support for some kind of runtime modules with one for each backend/platform. The module would contain a function that initializes stuff specific to that platform and GTK+ will run that during initialization. Just like what happens with the file system modules right now, we could ship a default simple module for GTK+-only apps on Linux and have some other GNOME package provide a GNOME runtime module, which initializes a11y, sets the bugzilla hooks, etc. Just some thoughts, no real concrete ideas ... regards, -kris. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Mummy, I made a platform in my pants! [Was: focus!]
ons, 19 07 2006 kl. 12:41 -0500, skrev Federico Mena Quintero: In terms of code and APIs, we are *done*. If you remember the Advisory Board meeting at GUADEC, what ISDs asked for was not more APIs, but the polish things: A common spell checking system would be extremely nice, currently GNOME ships with several applications which use different systems to present a spell checking interface to the user. Spell checking in GNOME makes puppies cry... please think of the puppies. - David Nielsen ___ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list
