Re: Drive applet by default

2006-09-14 Thread Ben Maurer
Is another daemon going to be created in order to do this, something like ejectable-device-manager? Regardless of any usability issues, this needs to be doable without a new process on the desktop, so that we don't waste memory. -b On Thu, 14 Sep 2006, David Prieto wrote: > I've noticed that

Re: Putting the 'Mono debate' back on the rails

2006-07-23 Thread Ben Maurer
On Sun, 23 Jul 2006, Eugenia Loli-Queru wrote: > Miguel wrote: "I would be interested in understanding what the issues of > non-splitting are, from the GNOME point of view." > > For one, if in the future Gnome would like to provide an embedded version > (there was some talk about it already), it wo

Re: Putting the 'Mono debate' back on the rails

2006-07-21 Thread Ben Maurer
On Fri, 21 Jul 2006, Jason D. Clinton wrote: > On Fri, 2006-07-21 at 13:39 -0400, Ben Maurer wrote: >> I don't think this is an item worth dividing on. For languages like Mono >> (and Java with GCJ), the compile or JIT (for Mono) or interp (for GCJ) is >> purely

Re: Putting the 'Mono debate' back on the rails

2006-07-21 Thread Ben Maurer
On Fri, 21 Jul 2006, Jason D. Clinton wrote: > On Sat, 2006-07-22 at 00:03 +1000, Jeff Waugh wrote: >> * Should applications built with anything in the Bindings suite be accepted >>into the Desktop suite? >> - short to medium term >> - do we want the central components of our software to p

Re: GnomeClient replacement?

2006-07-19 Thread Ben Maurer
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 goo

Re: Killing the splashscreen for 2.16

2006-07-15 Thread Ben Maurer
Hey, On Fri, 14 Jul 2006, Soeren Sandmann wrote: > I would like to turn off the login splashscreen by default, for the > following reasons: > >- login is somewhat faster > >- the 'progress' icons in the splashscreen don't reflect the > time it actually takes to login. > >

Re: Time to heat up the new module discussion

2006-07-14 Thread Ben Maurer
On Fri, 14 Jul 2006, Alvaro Lopez Ortega wrote: > Yeah, 100% agree. That is exactly the problem: applications would > use another framework rather than the one that they are suppose to > use (we are speaking about GNOME apps). libxml is an XML library for *C* apps. It's not designed to be usabl

Re: Time to heat up the new module discussion

2006-07-14 Thread Ben Maurer
On Fri, 14 Jul 2006, Nate Nielsen wrote: Steve Frécinaux wrote: Iain * wrote: As for .NET, even Microsoft themselves had to pull back from using it for core functionality due to performance reasons - why do we think we will do any better? As someone who is running mono based applications fa

Re: Mono/GTK#/Tomboy

2006-07-14 Thread Ben Maurer
On Fri, 14 Jul 2006, Murray Cumming wrote: > I don't believe that you've adressed the memory problems, though these are > not specific to Mono. We maybe can handle one highlevel runtime, but 2 > highlevel runtimes seems to be getting silly. If exactly one runtime needs to be choosen, making python

Re: Mono/GTK#/Tomboy

2006-07-14 Thread Ben Maurer
On Fri, 14 Jul 2006, Murray Cumming wrote: > And while there were almost no objections to Python, there are clearly > many objections to Mono. What objections? So far, the only two objections I've heard are: 1. Performance -- I feel that I've addressed this in other emails. 2. Vague references t

Re: Time to heat up the new module discussion

2006-07-13 Thread Ben Maurer
On Fri, 14 Jul 2006, [ISO-8859-1] Steve Fr?cinaux wrote: Ben Maurer wrote: 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

Re: Time to heat up the new module discussion

2006-07-13 Thread Ben Maurer
On Fri, 14 Jul 2006, [ISO-8859-1] Steve Fr?cinaux wrote: Andrew Cowie wrote: Which, to be honest, I feel makes this whole discussion a bit pointless. I realize that GNOME release engineering is holy ground, but don't you see? Everyone already ships Beagle. Which means they ship Mono. Which mea

Re: Time to heat up the new module discussion

2006-07-13 Thread Ben Maurer
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 f

Re: Time to heat up the new module discussion

2006-07-13 Thread Ben Maurer
> Joe Shaw wrote: > >>> It is a very different situation. While the power manager support >>> provides new functionality, GTK# would only provide duplicate >>> functionality for another development framework that overlaps with >>> GNOME. >> >> Perhaps I am misunderstanding, but this argument d

Re: Time to heat up the new module discussion

2006-07-13 Thread Ben Maurer
> On Thu, 2006-07-13 at 02:00, Ben Maurer wrote: [...] >> In the long term, Mono can potentially reduce our performance problems. >> > > In the short term, there are performance problems and Mono will worsen > them. In the short term, Mono will deliver us appl

Re: Time to heat up the new module discussion

2006-07-12 Thread Ben Maurer
Hey, On Wed, 12 Jul 2006, Darren Kenny wrote: > It's been mentioned many times before that we already have too many component > models in the GNOME platform - and once they are in there, it's VERY hard to > get > them back out again - just look at Bonobo. Bonobo is, by design, intended to be use

Re: [gpm] Re: Gnome 2.16 Module Proposal: GNOME Power Manager

2006-04-10 Thread Ben Maurer
On Mon, 10 Apr 2006, Rodrigo Moya wrote: since there is already a daemon (HAL and underlying power save software, like pmu, powersave, etc), why do we need another daemon? I think the current g-p-m architecture, with the 'daemon' being also the notification icon makes a lot of sense. If adding th