Even if you link statically, there are dynamic modules in gtk that are
pulled in at run time.
Also, remember that linking statically has license implications, as you in
such a case are forced to release your source code under the LGPL.
Regards,
Dov
On Tue, Jun 15, 2010 at 10:19, Steve Frécinaux
* Emmanuele Bassi eba...@gmail.com schrieb:
Really ? did you measure it ?
it's been measured multiple times, on multiple platforms - especially on
embedded ones.
URL ?
How often do typically gtk applications get startet - how many
per second ?
that's absolutely inconsequential.
* Michael Torrie torr...@gmail.com schrieb:
Can you prove that it doesn't? Until you can, there's no logical reason
to change the way GTK+ is currently done based on your say-so.
There're a lot of other reasons for smaller libraries, for example
reducing memory footprint, easier systems
On 08/16/2010 07:22 AM, Enrico Weigelt wrote:
hmm, isnt v3.x going to drop directfb support ? well ...
Why would you want to use directfb when a tiny X server is the same
footprint and much better supported? directfb is redundant. I hope
you're not using it. It reimplements (poorly)
On Mon, Aug 16, 2010 at 9:22 AM, Enrico Weigelt weig...@metux.de wrote:
* Michael Torrie torr...@gmail.com schrieb:
Can you prove that it doesn't? Until you can, there's no logical reason
to change the way GTK+ is currently done based on your say-so.
There're a lot of other reasons for
* Michael Torrie torr...@gmail.com schrieb:
Hi,
Why would you want to use directfb when a tiny X server is the
same footprint and much better supported?
Which one are you talking about ? Kdrive ?
How good is it supported, especially on non-x86 platforms ?
Xwindow generelly has several
* Stefan Kost enso...@hora-obscura.de schrieb:
I wonder how many dependencies are in between the widgets. If not many
one could make gtk plugin based. Like having a gtkcore with the
baseclasses, paint engine and event system only. All widgets are
provided by plugins. That is a plugin can
* Paul Davis p...@linuxaudiosystems.com schrieb:
There're a lot of other reasons for smaller libraries, for example
reducing memory footprint, easier systems maintenance (smaller libs
normally mean less changes, since many of them will be done elsewhere),
easier code review (less code to
On 08/16/10 15:29, Enrico Weigelt wrote:
It grows as soon as certain pages are accessed. And - as already said -
unless the distinct functional (sub)modules are aligned into their
own pages instead of randomly cat'ed to one big contigious text section
on linker's will, there's great chance
Le 16/08/2010 15:56, Stefan Kost a écrit :
On 15.06.2010 02:16, Matthias Clasen wrote:
On Mon, Jun 14, 2010 at 7:02 PM, Alberto Ruizar...@gnome.org wrote:
2010/6/14 Sam Thursfieldsss...@gmail.com:
A more socially-minded approach would be to work on the problem of
sharing
On 08/16/2010 12:54 PM, Enrico Weigelt wrote:
Why would you want to use directfb when a tiny X server is the
same footprint and much better supported?
Which one are you talking about ? Kdrive ?
How good is it supported, especially on non-x86 platforms ?
Correct. kdrive is now part of the
2010/6/15 Olav Vitters o...@vitters.nl:
On Tue, Jun 15, 2010 at 12:10:58PM +0200, Tshepang Lekhonkhobe wrote:
Yeah, I get it, but here's the point: it isn't nice when a maintainer
says unlikely without giving even one reason, leaving the rest of us
to guess (EG, that's most likely the reason).
* Emmanuele Bassi eba...@gmail.com schrieb:
because loading tons of small libraries is actually going to cost
much more in terms of resources (memory, I/O, linking and loading time)
Really ? did you measure it ?
How often do typically gtk applications get startet - how many
per second ?
On Sun, 2010-08-15 at 14:41 +0200, Enrico Weigelt wrote:
* Emmanuele Bassi eba...@gmail.com schrieb:
because loading tons of small libraries is actually going to cost
much more in terms of resources (memory, I/O, linking and loading time)
Really ? did you measure it ?
it's been
On 08/15/2010 06:41 AM, Enrico Weigelt wrote:
because loading tons of small libraries is actually going to cost
much more in terms of resources (memory, I/O, linking and loading
time)
Really ? did you measure it ?
Can you prove that it doesn't? Until you can, there's no logical reason
to
* Tshepang Lekhonkhobe tshep...@gmail.com schrieb:
Maybe the patches may be useful to someone else, and you want
to makethose available from one place, that is upstream.
If upstream doesn't want it, lets make a downstream for
(eg. in the OSS-QM project). I'm also concerned about continously
* Martyn Russell mar...@lanedo.com schrieb:
On Tue, 2010-06-15 at 09:54 +0200, Tshepang Lekhonkhobe wrote:
On Tue, Jun 15, 2010 at 01:16, Matthias Clasen
That may be, but 'disable this random set of widgets I don't need'
patches have very little chance of going upstream.
Why do they
On Fri, 2010-08-13 at 21:34 +0200, Enrico Weigelt wrote:
The maintenance overhead is just not worth it and that's most likely the
reason. When projects get to the size of GTK+ you really notice this
overhead.
The big question to me is, why has it grown to this size in the
first place ?
On 06/15/2010 01:02 AM, Alberto Ruiz wrote:
2010/6/14 Sam Thursfieldsss...@gmail.com:
A more socially-minded approach would be to work on the problem of
sharing a GTK+ runtime between all apps on a system. It's perhaps not
an easy problem, due different requirements in versions and specific
Wouldn't it be possible to link gtk+ statically and rely on the linker to
drop all the unused symbols?
Not out-of-the-box currently, but working on that would be a better
idea, and enabling statically building the GTK+ stack would have a
better chance of getting upstream.
--tml
On Tue, Jun 15, 2010 at 01:16, Matthias Clasen
matthias.cla...@gmail.com wrote:
On Mon, Jun 14, 2010 at 7:02 PM, Alberto Ruiz ar...@gnome.org wrote:
2010/6/14 Sam Thursfield sss...@gmail.com:
A more socially-minded approach would be to work on the problem of
sharing a GTK+ runtime between all
Why do they have little chance of going upstream?
Because the maintainer says so?
--tml
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
On Tue, Jun 15, 2010 at 10:05, Tor Lillqvist t...@iki.fi wrote:
Why do they have little chance of going upstream?
Because the maintainer says so?
Is it good enough that the maintainer doesn't even give a reason? Did
I miss something?
--
blog: http://tshepang.tumblr.com
Is it good enough that the maintainer doesn't even give a reason?
It is good enough for me. I admire a maintainer that doesn't let
everything turn into bikeshedding.
Did I miss something?
The possibility to maintain patches for the features you are missing
in your own distro or whatever?
On Tue, Jun 15, 2010 at 10:23, Tor Lillqvist t...@iki.fi wrote:
Is it good enough that the maintainer doesn't even give a reason?
It is good enough for me. I admire a maintainer that doesn't let
everything turn into bikeshedding.
A short explanation would be far better than just we are
On 15/06/10 09:26, Tor Lillqvist wrote:
Not out-of-the-box currently, but working on that would be a better
idea, and enabling statically building the GTK+ stack would have a
better chance of getting upstream.
You can already build GTK+ statically, can't you? Or doesn't it work on Windows?
You can already build GTK+ statically, can't you? Or doesn't it work on
Windows?
Well, not only GTK+, but presumably then also everything else under it
in the stack, otherwise it would be a rather pointless exercise,
wouldn't it? I am fairly sure it doesn't work out-of-the-box. I have
never
On 15/06/10 11:01, Tor Lillqvist wrote:
Well, not only GTK+, but presumably then also everything else under it
in the stack, otherwise it would be a rather pointless exercise,
wouldn't it? I am fairly sure it doesn't work out-of-the-box. I have
never tried.
We build GTK+, GLib, Pango and
On Tue, 2010-06-15 at 09:54 +0200, Tshepang Lekhonkhobe wrote:
On Tue, Jun 15, 2010 at 01:16, Matthias Clasen
That may be, but 'disable this random set of widgets I don't need'
patches have very little chance of going upstream.
Why do they have little chance of going upstream?
The
On Tue, Jun 15, 2010 at 11:59, Martyn Russell mar...@lanedo.com wrote:
On Tue, 2010-06-15 at 09:54 +0200, Tshepang Lekhonkhobe wrote:
On Tue, Jun 15, 2010 at 01:16, Matthias Clasen
That may be, but 'disable this random set of widgets I don't need'
patches have very little chance of going
On Tue, Jun 15, 2010 at 12:10:58PM +0200, Tshepang Lekhonkhobe wrote:
Yeah, I get it, but here's the point: it isn't nice when a maintainer
says unlikely without giving even one reason, leaving the rest of us
to guess (EG, that's most likely the reason).
Can we stop this discussion now or take
On Tue, Jun 15, 2010 at 6:10 AM, Tshepang Lekhonkhobe
tshep...@gmail.com wrote:
Yeah, I get it, but here's the point: it isn't nice when a maintainer
says unlikely without giving even one reason, leaving the rest of us
to guess (EG, that's most likely the reason).
These things have been
On Tue, Jun 15, 2010 at 13:35, Matthias Clasen
matthias.cla...@gmail.com wrote:
On Tue, Jun 15, 2010 at 6:10 AM, Tshepang Lekhonkhobe
tshep...@gmail.com wrote:
Yeah, I get it, but here's the point: it isn't nice when a maintainer
says unlikely without giving even one reason, leaving the rest
Would GTK+ upstream accept patches to disable GTK+ features? For example,
./configure --disable-file-chooser-disable
would make the GtkFileChooser() an empty stub.
I ship GTK+ in my application's Windows installer, and I'd like to
shrink GTK+ because my application's dependencies are ~95%
On Mon, Jun 14, 2010 at 11:24 PM, Andrew Ziem ahz...@gmail.com wrote:
Would GTK+ upstream accept patches to disable GTK+ features? For example,
./configure --disable-file-chooser-disable
would make the GtkFileChooser() an empty stub.
I ship GTK+ in my application's Windows installer,
2010/6/14 Andrew Ziem ahz...@gmail.com:
Would GTK+ upstream accept patches to disable GTK+ features? For example,
./configure --disable-file-chooser-disable
would make the GtkFileChooser() an empty stub.
I ship GTK+ in my application's Windows installer, and I'd like to
shrink GTK+
2010/6/14 Sam Thursfield sss...@gmail.com:
A more socially-minded approach would be to work on the problem of
sharing a GTK+ runtime between all apps on a system. It's perhaps not
an easy problem, due different requirements in versions and specific
libraries, but it's a more long-term solution
On Mon, Jun 14, 2010 at 7:02 PM, Alberto Ruiz ar...@gnome.org wrote:
2010/6/14 Sam Thursfield sss...@gmail.com:
A more socially-minded approach would be to work on the problem of
sharing a GTK+ runtime between all apps on a system. It's perhaps not
an easy problem, due different requirements
On Mon, Jun 14, 2010 at 4:59 PM, Alberto Ruiz ar...@gnome.org wrote:
2010/6/14 Andrew Ziem ahz...@gmail.com:
Would GTK+ upstream accept patches to disable GTK+ features? For example,
./configure --disable-file-chooser-disable
would make the GtkFileChooser() an empty stub.
I ship GTK+
On Mon, Jun 14, 2010 at 5:16 PM, Matthias Clasen
matthias.cla...@gmail.com wrote:
On Mon, Jun 14, 2010 at 7:02 PM, Alberto Ruiz ar...@gnome.org wrote:
2010/6/14 Sam Thursfield sss...@gmail.com:
A more socially-minded approach would be to work on the problem of
sharing a GTK+ runtime between
40 matches
Mail list logo
