RE: [Dillo-dev]which version does this patch file patch
-----Original Message----- From: dillo-dev-admin@lists.auriga.wearlab.de [mailto:dillo-dev-admin@lists.auriga.wearlab.de] On Behalf Of Jeremy Henty Sent: Tuesday, October 05, 2004 1:18 AM To: dillo-dev@lists.auriga.wearlab.de Subject: Re: [Dillo-dev]which version does this patch file patch
On Mon, Oct 04, 2004 at 11:37:33AM -0700, Linda J. Laubenheimer wrote:
*Headdesk* So that's why it won't compile with glib2 and gtk2. It always ended up linking against libmodule 1.2, libglib 1.2, etc.,
Yes. Despite the names, gtk+-1 and gtk+-2 are different libraries. You can't build against one and link against the other, any more than you can build a KDE app and expect it to link against GNOME.
Which is why I tried to build it against gtk2.
Oh, well, no Dillo on my thin box.
Why not? Gtk+-2 is designed to work alongside gtk+-1 with no problems. I have had them both installed for a couple of years, running dillo and other gtk+-1 and gtk+-2 applications. It's all worked out of the box with no problems.
One word: space. When you are working on embedded systems with limited space, you have to chose your libraries carefully, not pile in double libraries that are just slightly different.
If you have to install two versions of a library, you've done something wrong.
I agree, but that doesn't apply here. Gtk+-1 and gtk+-2 are *different* libraries. Since no application built against one of them will even look at the other there's no problem. Version hell only happens when an application can link against more than one library on your system and runs the risk of picking the wrong one. The design of Gtk+-2 ensures that this won't happen.
Technically, two version of a library are different libraries. The fact is, when you have to pick which one of two similar libraries to include, just adding the second isn't an option. We're talking about fitting everything, including printing, on a 32M or 64M flash, and every redundancy counts against you. The whole idea behind looking at Dillo is to obtain a nicely featured browser with a small disk footprint.
I'm not a C programmer, otherwise I'd fix it and send it to you.
Believe me, there's nothing to fix. Just install both gtk+-1 and gtk+-2 and live happily ever after. I did!
Not going to happen. I stated, I thought clearly, that this was an embedded project. You can't just go willy-nilly installing extra libraries because an application only compiles against version 1, but not version 2. The rest of the items in the project are compiled against gtk2. So yes, in order to use Dillo, it would need to be fixed to be compiled against glib2 and gtk2, because just installing another set of libraries is not an option. ljl
On Mon, Oct 04, 2004 at 11:37:33AM -0700, Linda J. Laubenheimer wrote:
*Headdesk* So that's why it won't compile with glib2 and gtk2. It always ended up linking against libmodule 1.2, libglib 1.2, etc.,
What does "*Headdesk*" mean? -- Cheers Jorge.-
"Linda J. Laubenheimer" wrote:
I'm not a C programmer, otherwise I'd fix it and send it to you.
Believe me, there's nothing to fix. Just install both gtk+-1 and gtk+-2 and live happily ever after. I did!
Not going to happen. I stated, I thought clearly, that this was an embedded project. You can't just go willy-nilly installing extra libraries because an application only compiles against version 1, but not version 2. The rest of the items in the project are compiled against gtk2. So yes, in order to use Dillo, it would need to be fixed to be compiled against glib2 and gtk2, because just installing another set of libraries is not an option.
well, I wouldn't use the bloat of gtk2/glib2 in an embedded system and I hope dillo stays gtk1, which is faster, more portable and consumes less resources (and besides,muchmore portable across different operating systems). I could rephrase saying that it is your problem using gtk2! Of course you have choosen your tools and libraries in your project... Personally I hope the independence of the dillo core will enable to port it to different UIs and different toolkits (think of motif or fltk or even other, fast toolkits) instead of binding us to gtk. Of course you can object that gtk2 is actively developed and gtk1 not, but I really agree with other saying here that the two are quite "different" beasts. Just my 2 cents, -R
participants (4)
-
Jorge Arellano Cid -
Kelson Vibber -
Linda J. Laubenheimer -
Riccardo Mottola