>> Sorry, but I don't understand: QWebKit is an embedded web >> browser component. Why do we need to implement a browser >> in Harbour? >> >> There are _plenty_ of free browsers on the market which >> do the job much better than any local effort in Harbour >> will ever do. >> >> Launch it and us it, that's all. >> >> If someone terribly needs a browser in a local window, >> it should be dead easy to implement it as a 3rd party >> project. >> > > It is ok that we have not to implement it in Harbour. > But this is not ok that the use of QtWebKit is synonymous > to any web-browser in the market. QtWebKit is begins where > any web-browser ends. It transfers the control to desktop > application to present and exploit web-contents with > DBFCDX. No browser gives this flexibility. > > To illustrate, you create a window as a web-page, design > its contents from some table's fields, capture the user-input, > naviage the www as your appln requires and accomplish > your target in modern environments. This alone opens up a > pandora of extensions. > > The only point I disliked is its heavy load. But then, if you > ever visualized in the task manger, IE also consumes a > lot of memory.
That is why I don't use IE. Of course other browsers also eat a lot of memory (WebKit-based ones too), and here I like the choice that I can simply close them when I don't need them. > QtWebKit is not a "browser" by definition, a framework > to design user-interface, even ReadModal() the WWW way. > It is much more than, to understand better, Alaska's WAA. I also fail to see a point in a non-client-server web GUI, but all available documentation indicates that QtWebKit module is the WebKit browser engine ported to the Qt project. I don't see any notion of user interface design. Of course you can internally generate a webpage and display it in the same app, but that's not more than "smoke and mirrors", not real web UI. If we want to offer web UI in Harbour, it should be done what 99.9% of ppl perceive as web UI: a regular web browser client (of user's choice!) with a server backend. For this we don't need a browser component in Harbour. Also notice that QtWebKit, like all other browser components is full of security problems, and I'm not sure we in Harbour need to take this extra worry on our back. BTW back than nobody told you to remove QtWebKit, all we were saying was to _separate/modularize components_ so that apps that don't need QtWebKit would not require its .dll and all the heavy load with it, plus that hbqt and qt apps could be built on platforms that don't have QtWebKit. Since you removed it instead of resolving the modularization, I guess the latter was impossible, or wasn't important enough. Anyhow I think it's a quite bad idea to add 20MB of .dll to hbide (loaded into memory on every startup) just to display help text. But, hbide is already off the track I would have imagined for native Harbour IDE, so for me this doesn't really matter anymore, the rest of point stays valid though. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
