Hello Carl & al,
> I'm personally interested in hearing more details about what your
> motivation for sticking with 2.6 is. If it's performance concerns, (as
> is the case with others I've talked to), then I should point out that
> I'm personally very interested, and planning on fixing those
> per
Hello Carl & al,
> I'm personally interested in hearing more details about what your
> motivation for sticking with 2.6 is. If it's performance concerns, (as
> is the case with others I've talked to), then I should point out that
> I'm personally very interested, and planning on fixing those
> pe
Hi,
> One thing you might want to look into is changing the usage of doubles.
> They are used all over the place and they are way overkill. On small
> platforms like ours this is particularly painful because of floating
> point emulation.
Any new descissions ... may there be changes driven by the
Carl,
there 's at least one : Pango is using Cairo, cairo is a double based
vector graphics engine... Pango became slower since it is using it.
On embedded platform the cost for calculations with double is really
heavy.
Embedded computing does not benefit from the pseudo empiric "intel
mo
On 20.07.2006 02:09, Carl Worth wrote:
> I'm personally interested in hearing more details about what your
> motivation for sticking with 2.6 is. If it's performance concerns, (as
> is the case with others I've talked to), then I should point out that
> I'm personally very interested, and planning
Jesse
-Original Message-
From: Carl Worth [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 19, 2006 5:09 PM
To: Jesse Donaldson
Cc: gtk-devel-list@gnome.org
Subject: Why are people sticking with GTK+ 26.? (Re: GTK+
modularization)
On Mon, 17 Jul 2006 13:58:41 -0700, "Jesse D
gtk-devel-list@gnome.org
Subject: Why are people sticking with GTK+ 26.? (Re: GTK+
modularization)
On Mon, 17 Jul 2006 13:58:41 -0700, "Jesse Donaldson" wrote:
> We're still using v2.6, so folks may not care,
> but I'm happy to share our results (
On Mon, 17 Jul 2006 13:58:41 -0700, "Jesse Donaldson" wrote:
> We're still using v2.6, so folks may not care,
> but I'm happy to share our results (once we've obtained them). Also, if
> he'd like, I can try to put Mathias in touch with whoever will be
> looking at this on o
Hello,
Mike Emmel wrote:
> Hmm I'm not sure what to say I don't think that the nature of emedded
> programing
> is comming through our its needs.
i think its a matter of defining "embedded programming".
> Generally your running a small set of custom apps if you provide a
> public api (rare)
> S
Hello,
Matthias Clasen wrote:
> This has been discussed a bit at Guadec; and I have started looking into
> what it would take to allow compiling GTK+ with certain subsets of
> widgets.
>
> My current patch defines a small number of optional subsets:
>
> * broken: widgets covered by GTK_ENABLE_B
btained them). Also, if
he'd like, I can try to put Mathias in touch with whoever will be
looking at this on our end.
Jesse
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Emmel
Sent: Friday, July 14, 2006 12:25 PM
To: Sean Kelley
Cc: gtk-devel-lis
On 7/14/06, Sean Kelley <[EMAIL PROTECTED]> wrote:
> I think you have to be careful about even embedded specs. For
> example, I am working on a device that has 1 to 4GB of flash space and
> 64 to 128MB of RAM. A Nokia 770 would be a good parallel, although
> with less flash space on board. These
I think you have to be careful about even embedded specs. For
example, I am working on a device that has 1 to 4GB of flash space and
64 to 128MB of RAM. A Nokia 770 would be a good parallel, although
with less flash space on board. These sort of specs are more in line
with consumer devices. The
Hmm I'm not sure what to say I don't think that the nature of emedded programing
is comming through our its needs.
Generally your running a small set of custom apps if you provide a
public api (rare)
Someone targeting the device will port to it.
If you have the luxury of tons of space then run ful
On Thu, 13 Jul 2006, muppet wrote:
> As i understand it, the target for this modularization is not
> desktops --- it's embedded devices.
Hmm, perhaps I haven't been following this closely enough. In
an embedded context the slimming of GTK certainly make sense.
> Therefore I heartily condone t
have a bit of a PD eco system. Everybody uses
stuff like busy-box.
--David Moffatt
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mike Emmel
Sent: Thursday, July 13, 2006 6:00 PM
To: gtk-devel-list@gnome.org
Subject: Re: GTK+ modularization
Can I sugges
Can I suggest considering a version designed for custom widgets.
And leave it to the embedded developer to selectivley pull in more widgets.
This would be GtkWindow GdkBin GtkButton and a few more say text input.
basically a very simple toolkit.
After this if you want to use gtk custom widgets a
On Wed, 12 Jul 2006, Murray Cumming wrote:
>> This has been discussed a bit at Guadec; and I have started
>> looking into what it would take to allow compiling GTK+ with
>> certain subsets of widgets.
>>
>> My current patch defines a small number of optional subsets:
>>
>> * broken: widgets cove
Matthias Clasen wrote:
> This has been discussed a bit at Guadec; and I have started looking into
> what it would take to allow compiling GTK+ with certain subsets of
> widgets.
>
> My current patch defines a small number of optional subsets:
>
> * broken: widgets covered by GTK_ENABLE_BROKEN
>
On Wed, 2006-07-12 at 10:47 -0400, Tristan Van Berkom wrote:
> Matthias Clasen wrote:
> [...]
> >>
> >>I meant, for instance, deprecated functions in non-deprecated files.
> >
> >
> > No, it doesn't touch those. It is really meant to be widget subsets.
> >
>
> On a hypothetical level... could t
> On Wed, 2006-07-12 at 08:59 +0200, Murray Cumming wrote:
>> > This has been discussed a bit at Guadec; and I have started looking
>> into
>> > what it would take to allow compiling GTK+ with certain subsets of
>> > widgets.
>> >
>> > My current patch defines a small number of optional subsets:
>
Matthias Clasen wrote:
[...]
>>
>>I meant, for instance, deprecated functions in non-deprecated files.
>
>
> No, it doesn't touch those. It is really meant to be widget subsets.
>
On a hypothetical level... could this all be simplified by attacking it
from a makefile level ?
One could use gcc
On Wed, 2006-07-12 at 08:59 +0200, Murray Cumming wrote:
> > This has been discussed a bit at Guadec; and I have started looking into
> > what it would take to allow compiling GTK+ with certain subsets of
> > widgets.
> >
> > My current patch defines a small number of optional subsets:
> >
> > * br
On Wed, 2006-07-12 at 14:28 +0200, Murray Cumming wrote:
> > On Wed, 2006-07-12 at 08:59 +0200, Murray Cumming wrote:
> >> > This has been discussed a bit at Guadec; and I have started looking
> >> into
> >> > what it would take to allow compiling GTK+ with certain subsets of
> >> > widgets.
> >> >
> This has been discussed a bit at Guadec; and I have started looking into
> what it would take to allow compiling GTK+ with certain subsets of
> widgets.
>
> My current patch defines a small number of optional subsets:
>
> * broken: widgets covered by GTK_ENABLE_BROKEN
> * deprecated: widgets cov
This has been discussed a bit at Guadec; and I have started looking into
what it would take to allow compiling GTK+ with certain subsets of
widgets.
My current patch defines a small number of optional subsets:
* broken: widgets covered by GTK_ENABLE_BROKEN
* deprecated: widgets covered by GTK_DI
26 matches
Mail list logo