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
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
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
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
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
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.
>
>
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
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
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
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
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
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
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
> 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
> 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
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
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
17 matches
Mail list logo