PureBasic Forums - English

http://code.google.com/p/chromiumembedded/

It uses the BSD (new) license.

It would be great if it was possible to set PureBasic to use CEF instead of IE/Mozilla whatever.
And then just plonk the libcef.dll in the program's directory and you got a full Chrome/Webkit engine to create really advanced "HTML GUI" based apps.

Check out the download section of that link, and test the cefclient.exe to see it in action.

Rescator wrote:http://code.google.com/p/chromiumembedded/

It uses the BSD (new) license.

It would be great if it was possible to set PureBasic to use CEF instead of IE/Mozilla whatever.
And then just plonk the libcef.dll in the program's directory and you got a full Chrome/Webkit engine to create really advanced "HTML GUI" based apps.

Check out the download section of that link, and test the cefclient.exe to see it in action.

If it's embeddable, why not include it into the app-binary?
You wouldn't need the dll then (which is great...)
A clean install of only one exe as this is one of the many advantages of PureBasic..

embed chromium is a good idea, would solve problem with linux x64 and so on.

Rescator wrote:It would be great if it was possible to set PureBasic to use CEF instead of IE/Mozilla whatever.
And then just plonk the libcef.dll in the program's directory and you got a full Chrome/Webkit engine to create really advanced "HTML GUI" based apps.

Why is the dropping of support for IE/Mozilla needed to improve PB-features ?
Does that mean PB-proggers and their clients would be forced to install the Chrome browser or means CEF a meta-basis for any browser?

greetings ~ Vera

Vera wrote: Why is the dropping of support for IE/Mozilla needed to improve PB-features ?

I think, dropping the support for IE/Mozilla wasn't the intention, but to ADD support for chromium.

You're misunderstanding, Vera. He wants Chrome to be an option in
addition to IE/Mozilla. He said he wants to use it instead of, not in
replace of. So, the WebGadget could have an extra flag such as
#PB_Web_Chrome and then the user just needs to put libcef.dll
in their app's dir, and that's it. Mozilla would still work if you used
#PB_Web_Mozilla for the flag.

thanks for the quick reply

Well ~ than I hope Chrome is available for MAC-users too

To be honest, I don't really see the point. What difference does it make which engine renders the website apart from plain ideological arguments? Both Windows and OSX come directly with a reliable rendering engine. There is no need to include another one with the program.

ts-soft wrote:embed chromium is a good idea, would solve problem with linux x64 and so on.

I am currently experimenting with the WebKitGtk library. It looks like it can be a viable replacement for the gtkmozembed library which is hard to get working correctly and isn't available on x64. The Gnome project is currently moving to WebKitGtk for its main html rendering library, so future development and availability of the library should be no problem (which i can't really say about the gtkmozembed library).

I would like to be able to select a rendering engine (I don't care what it is) that allows whatever I'm displaying to render exactly the same no matter what platform it's running on, with the exception of font render nuances, etc.

Working with IE is all fine and dandy until you try getting the thing to render properly on IE6. It's not that big of a deal on a web page but it's terrible when you want to render it as a GUI.

freak wrote:To be honest, I don't really see the point. What difference does it make which engine renders the website apart from plain ideological arguments? Both Windows and OSX come directly with a reliable rendering engine. There is no need to include another one with the program.

Yes! But it's a pain to say make a HTML based app GUI for example.
Passing data to/from the "browser" part and the Exe is limited.

freak wrote:I am currently experimenting with the WebKitGtk library. It looks like it can be a viable replacement for the gtkmozembed library which is hard to get working correctly and isn't available on x64. The Gnome project is currently moving to WebKitGtk for its main html rendering library, so future development and availability of the library should be no problem (which i can't really say about the gtkmozembed library).

Amusing, you are kinda brushing off chromium embedded framework.
but you are looking at gtkwebkit embed? How is that different from CEF at all?
Chromium is built on Webkit in any case so it's the same engine.
only difference is that Chromium also seems to support media (that example has a few media support dlls to handled media content)

GTK and Gnome are GPL or LGPL right? Chromium is BSD so the license is much more flexible for use with PureBasic.
Also, Chromium is updated whenever Google etc. update the Chrome browser since it too uses Chromium.

CEF is available for Windows, Mac OS X (not sure on min OS versions though) and Linux.
So with a CEF dll or so it would not matter what the OS browser is or if it has a render engine available that Webgadget can use or not.
CEF could even be further leveraged as it does downloading and SSL and media as well.

I'm just saying that PureBasic could ship with a CEF lib, and that the compiler could let you specify you'd like to use that instead for the Webgadget,
and open up for the more advanced features CEF provides compared to the current webgadget.

Now don't get me wrong, I can happily do my own thing ad I probably will.

I just thought that a complete "engine" like CEF made sense.

Rescator wrote:

freak wrote:To be honest, I don't really see the point. What difference does it make which engine renders the website apart from plain ideological arguments? Both Windows and OSX come directly with a reliable rendering engine. There is no need to include another one with the program.

Yes! But it's a pain to say make a HTML based app GUI for example.
Passing data to/from the "browser" part and the Exe is limited.

It will be limited in the same way no matter what the engine is. The WebGadget is just an easy way to display html content. It is not intended for GUI making. We cannot expose all features of a html rendering engine to PureBasic. They are just too big. The WebGadget is just a very small feature of PB, it is not the main focus here.

If you really want full access, you'll have to do your own thing using the API of the engine anyway, so this won't help you at all.

Rescator wrote:Amusing, you are kinda brushing off chromium embedded framework.
but you are looking at gtkwebkit embed? How is that different from CEF at all?
Chromium is built on Webkit in any case so it's the same engine.
only difference is that Chromium also seems to support media (that example has a few media support dlls to handled media content)

We need to use standard components that are available on most Linux distributions. Otherwise it will always be a pain to get programs that use it to work because of missing dependencies and configuration differences. If WebKitGtk really gets integrated into Gnome, then this will not be a problem.

Does CEF even have official Linux packages? On the site i only see mention of Windows and OSX. As I said, Windows and OSX are already covered by system components. There is no advantage to be gained there.

Rescator wrote:GTK and Gnome are GPL or LGPL right? Chromium is BSD so the license is much more flexible for use with PureBasic.

LGPL is simpler in the Linux case, because the library itself is part of the distribution and not shipped with the PB program. PB programs only access them, so you don't need to include the LGPL license with the program for example. If you use a BSD component which you ship with your program, you will have to include the appropriate copyright notices etc.

Could it not be an option though, not a replacement?

I would be in favour of this.

Chromium gets updated all the time, so you could ship the latest version with the latest features. By contrast, how often does IE's ATL.dll get updated? Once a year? Once every five years?

Try showing an SVG in the webgadget and most of your customers won't see it. (Even though all the other browsers have supported SVG for about 5 years.)

It would also ensure that a webpage would be displayed the same for all your customers.

And of course, Chromium is lightning fast compared to IE. (Okay not IE9, but how many people have that installed?)

So I think it would be a great idea. It would also help to make PB rely on opensource, modern, frequently updated components instead of, well, Microsoft components.

freak wrote:To be honest, I don't really see the point. What difference does it make which engine renders the website apart from plain ideological arguments? Both Windows and OSX come directly with a reliable rendering engine. There is no need to include another one with the program

I just came across this and I really must strongly disagree and discourage this kind of attitude.

Anyone who has done any kind of long standing and serious web site development knows what an absolute pain in the ass it is to get a web site to render properly in Internet Explorer, while still looking proper in Mozilla-type and other browsers

Internet Explorer alone is a minefield of rendering bugs and quirks whose only predictability is that they unpredictably change with almost every version of the browser that is released. I have written many-a-hacked up CSS Stylesheets in my day just to get IE to play nice. Not to mention all the troublesome proprietary feature sets it supports through various HTML tags or other code interfaces. It's not very conducive to a cross-platform development tool (PB) to so heavily rely on such an anti-open piece of software and there is nothing ideological about that.

I fully admit I have not done any work for quite some time now, but I have no reason to believe the latest IE is that much different, although the compatability layers it comes with help for rendering troublesome sites, I don't think it really is a fair solution to simply rely on the "default" OS browser for our programs.

It is too much extra work on our part, as we should be concentrating on the program and not why our design is 6pixels off in one spot, or block elements are improperly aligned in another spot.
I think Chromium would be a nice solution as it seems to be very cross-platform and updated frequently.

If not integrating it with the Web Gadget, the least that could be done is a little generosity in making it partially supported and easier for the programmer to implement on their end, if they want to use it.

We cannot expose all features of a html rendering engine to PureBasic. They are just too big. The WebGadget is just a very small feature of PB, it is not the main focus here

What does 'Just too big' mean? I think the webgadget is one of PBs biggest selling points, so let the customers decide what parts of PB is a small feature or not.