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
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
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?
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
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
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.
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
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,
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
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
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
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
/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
-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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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,
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
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.
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
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
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
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
55 matches
Mail list logo
