Discussion:
SF.net SVN: harbour-project:[13834] trunk/harbour
(too old to reply)
vouchcac-Rn4VEauK+AKRv+
2010-02-10 02:35:24 UTC
Permalink
Revision: 13834
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13834&view=rev
Author: vouchcac
Date: 2010-02-10 02:35:23 +0000 (Wed, 10 Feb 2010)

Log Message:
-----------
2010-02-09 18:25 UTC-0800 Pritpal Bedi (pritpal-2d44uuzHvMNWk0Htik3J/***@public.gmane.org)
+ contrib/hbide/docs
+ contrib/hbide/docs/idemainpage.html
+ contrib/hbide/docs/interfaceelements.html
+ contrib/hbide/docs/multiviews.html

* contrib/hbide/resources/help.png

* contrib/hbide/hbide.prg
* contrib/hbide/ideactions.prg
* contrib/hbide/idedocks.prg
* contrib/hbide/ideobject.prg

+ Implemented basics of ib-build help mechanism.
It is working in a limited manner and is scheduled to be
matured in next few days, at-least from operations
point-of-view. QtextBrowser() accepts a sub-set of
html commands and hence is very limited in appearnce.
As we have decided against QtWebkit, this implementation
may not look highly professional, will surely solve
our purpose.

If someone is willing to extend help in this direction,
then following are the guidelines how you should design
html page:
1. Open Qt Creator
2. Create a widget in the designer.
3. Place a QTextBrowser control somewhere.
4. Double-click within the control.
5. A rich-text editing box will appear.
6. Design the page.
7. Click on the "Source" tab at the bottom.
8. Select the whole source with Ctrl+A and copy with Ctrl+C.
9. Create a .html file with notepad, paste the source, and save.

The process is lengthy, but no other html editor solves our
purpose due to limited html tags availability in QTextBrowser.

Modified Paths:
--------------
trunk/harbour/ChangeLog
trunk/harbour/contrib/hbide/hbide.prg
trunk/harbour/contrib/hbide/ideactions.prg
trunk/harbour/contrib/hbide/idedocks.prg
trunk/harbour/contrib/hbide/ideobject.prg

Added Paths:
-----------
trunk/harbour/contrib/hbide/docs/
trunk/harbour/contrib/hbide/docs/idemainpage.html
trunk/harbour/contrib/hbide/docs/interfaceelements.html
trunk/harbour/contrib/hbide/docs/multiviews.html
trunk/harbour/contrib/hbide/resources/help.png


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.
Franček Prijatelj
2010-02-10 05:46:46 UTC
Permalink
Hi
Post by vouchcac-Rn4VEauK+AKRv+
As we have decided against QtWebkit, this implementation
may not look highly professional, will surely solve
our purpose.
I don't understand, what is the reason for this decision.
I am currently working with Qt 4.6.1 (both MSVC8, and official MINGW 4.0)
with no problems.
IMHO QtWebkit is one of the most important parts of Qt
(and other toolkits to : WebkitGTK,wxWebkit).
In the near future: "DESKTOP==BROWSER & GUI==BROWSER BASED.
There is a lot off evidence: GNOME SHELL,CHROME OS,Qt (QML, SVG, CSS...)
As I understood and as I hope , it was only a temporary decision .
Today it's easier to develop desktop apps with Qt designer, GLADE or Delphi,
but that is changing rapidly.
The only problem is that there are to many possibilities
(AJAX,XUL,SVG,HTML5) .
Html is standard for documentation for many years now (CHM is html with some
extensions).

I hope that this decision will be reconsidered again.

BRGS
Franček
--
View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13834--trunk-harbour-tp27525434p27526450.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
Pritpal Bedi
2010-02-10 07:45:00 UTC
Permalink
Post by Franček Prijatelj
I don't understand, what is the reason for this decision.
I am currently working with Qt 4.6.1 (both MSVC8, and official MINGW 4.0)
with no problems.
IMHO QtWebkit is one of the most important parts of Qt
(and other toolkits to : WebkitGTK,wxWebkit).
In the near future: "DESKTOP==BROWSER & GUI==BROWSER BASED.
There is a lot off evidence: GNOME SHELL,CHROME OS,Qt (QML, SVG, CSS...)
As I understood and as I hope , it was only a temporary decision .
Today it's easier to develop desktop apps with Qt designer, GLADE or Delphi,
but that is changing rapidly.
The only problem is that there are to many possibilities
(AJAX,XUL,SVG,HTML5) .
Html is standard for documentation for many years now (CHM is html with some
extensions).
I hope that this decision will be reconsidered again.
The decision was based on two factors:

1. Qt with WebKit was not available on some distributions,
which ones, I do not remember, someone has to update this.
2. WebKit was too heavy. Appln consumed double the size of normal load.

But for sure QtWebKit will be a must for us.
Classes are ready and were implemented in hbXBP.
Only group decision is required. I do not know about *nix distros.


-----
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-13834-trunk-harbour-tp4545547p4546441.html
Sent from the harbour-devel mailing list archive at Nabble.com.
Franček Prijatelj
2010-02-10 11:24:14 UTC
Permalink
Hi
Post by Pritpal Bedi
1. Qt with WebKit was not available on some distributions,
which ones, I do not remember, someone has to update this.
2. WebKit was too heavy. Appln consumed double the size of normal load.
But for sure QtWebKit will be a must for us.
Classes are ready and were implemented in hbXBP.
Only group decision is required. I do not know about *nix distros.
It's available AFAIK on Win,Linux,Symbian.
Win32 /64 is available only on Win platforms, but it's hosted in
contrib\hbwin.
I see that you have everything ready.
Is there any problem to have something like HB_WITH_QT_WEBKIT and
build it only on supported platforms.

BRGS
Franček
--
View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13834--trunk-harbour-tp27525434p27529186.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
Viktor Szakáts
2010-02-10 11:30:09 UTC
Permalink
Post by Franček Prijatelj
Post by Pritpal Bedi
1. Qt with WebKit was not available on some distributions,
which ones, I do not remember, someone has to update this.
2. WebKit was too heavy. Appln consumed double the size of normal load.
But for sure QtWebKit will be a must for us.
Classes are ready and were implemented in hbXBP.
Only group decision is required. I do not know about *nix distros.
It's available AFAIK on Win,Linux,Symbian.
Win32 /64 is available only on Win platforms, but it's hosted in
contrib\hbwin.
I see that you have everything ready.
Is there any problem to have something like HB_WITH_QT_WEBKIT and
build it only on supported platforms.
First we should discuss all concerns, if you care, pls
answer them. BTW, it's supported on _some_ Linux distros.
HB_WITH_QT_WEBKIT is no solution, but hack. Such setting
should be resolved automatically.

Or, it's still an option to move the whole QT related
stuff from Harbour SVN to somewhere else and satisfy
QT user special requests there.

Brgds,
Viktor
Franček Prijatelj
2010-02-10 12:15:46 UTC
Permalink
Hi Viktor
Post by Viktor Szakáts
First we should discuss all concerns, if you care, pls
answer them. BTW, it's supported on _some_ Linux distros.
HB_WITH_QT_WEBKIT is no solution, but hack. Such setting
should be resolved automatically.
Or, it's still an option to move the whole QT related
stuff from Harbour SVN to somewhere else and satisfy
QT user special requests there.
You are right.
As a leading architect of Harbour, you better know
how to make a portable solution for most platforms.
I started with xHarbour, but when i saw a quick advancement
(with very strict rules for quality) in Harbour, i switched.
I believe that Harbour is a best app platform.
But I also believe (and i have some experience) that
Webkit (or some other HTML5,SVG,AJAX,FLASH,.....) based
technology is a future.
Merging of both is my dream.

BRGS
Franček
--
View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13834--trunk-harbour-tp27525434p27530300.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
Viktor Szakáts
2010-02-10 12:58:24 UTC
Permalink
Hi Francek,
Post by Franček Prijatelj
Post by Viktor Szakáts
First we should discuss all concerns, if you care, pls
answer them. BTW, it's supported on _some_ Linux distros.
HB_WITH_QT_WEBKIT is no solution, but hack. Such setting
should be resolved automatically.
Or, it's still an option to move the whole QT related
stuff from Harbour SVN to somewhere else and satisfy
QT user special requests there.
You are right.
As a leading architect of Harbour, you better know
how to make a portable solution for most platforms.
I started with xHarbour, but when i saw a quick advancement
(with very strict rules for quality) in Harbour, i switched.
I believe that Harbour is a best app platform.
But I also believe (and i have some experience) that
Webkit (or some other HTML5,SVG,AJAX,FLASH,.....) based
technology is a future.
WebKit is just an engine to process above standards
(at least some them), render them, display them, handle
some related features like caching, history, and maybe
even doc parsing and creation. QT gives an API and classes
to access them.

Creation of doc can be useful, but IMO it has no point
on the client side. And since it's mashed together
with rendering engine, it's very difficult (and unsafe)
to use it efficiently on the server side.

So IMO Harbour's place in this scenario is rather the
server side, to help creating documents complying with
above standards, server them through an IP stack and
make them work in standard browsers.

Brgds,
Viktor
Franček Prijatelj
2010-02-10 13:29:25 UTC
Permalink
Hi Viktor
Post by Viktor Szakáts
So IMO Harbour's place in this scenario is rather the
server side, to help creating documents complying with
above standards, server them through an IP stack and
make them work in standard browsers.
You are right.

I see harbour as "a server side" platform.
Let me explain it.

1. I think that Harbour based Http server is superior solution to
Apache+some scripting
Harbour Http server + classic browser == Standard web app

2. Embeded Harbour Http server + Embeded browser == Standard desktop app
(User knows nothing about server and browser, easy switch beetwen desktop
and web app)

3. Qt bridge beetwen Webkit and APPI == Standard desktop app

4. 1+2+3 == lot of possibilities.

With little changes you can have Web app as well as desktop app.
With embeded web machine you have also multimedia platform.
Html4 was documment oriented.
Html5 is UI oriented.
It's maybe half-developed , but it's developing very quickly.

BRGS
Franček
--
View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13834--trunk-harbour-tp27525434p27531157.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
Viktor Szakáts
2010-02-10 14:24:31 UTC
Permalink
Hi Francek,

To cut it short: See my previous answer, if QtWebKit
wrappers are implemented properly, which means QtWebKit
is an optional and well separated component which is
not referenced when not used by user, or not available
on a given environment (with autodetection), it can
be added. In fact it could have even stayed, but Pritpal
had opted to delete it.

For me though the whole concept stays off the roadmap
I'd personally choose or choose as Harbour do-it-all
IDE/web solution. If someone can prove with actual code,
that such web UI is easily portable to server side,
and be used on the desktop, I may change my mind :)

Brgds,
Viktor
Post by Franček Prijatelj
Hi Viktor
Post by Viktor Szakáts
So IMO Harbour's place in this scenario is rather the
server side, to help creating documents complying with
above standards, server them through an IP stack and
make them work in standard browsers.
You are right.
I see harbour as "a server side" platform.
Let me explain it.
1. I think that Harbour based Http server is superior solution to
Apache+some scripting
Harbour Http server + classic browser == Standard web app
2. Embeded Harbour Http server + Embeded browser == Standard desktop app
(User knows nothing about server and browser, easy switch beetwen desktop
and web app)
3. Qt bridge beetwen Webkit and APPI == Standard desktop app
4. 1+2+3 == lot of possibilities.
With little changes you can have Web app as well as desktop app.
With embeded web machine you have also multimedia platform.
Html4 was documment oriented.
Html5 is UI oriented.
It's maybe half-developed , but it's developing very quickly.
BRGS
Franček
--
View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13834--trunk-harbour-tp27525434p27531157.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
http://lists.harbour-project.org/mailman/listinfo/harbour
Pritpal Bedi
2010-02-10 14:59:47 UTC
Permalink
Post by Viktor Szakáts
First we should discuss all concerns, if you care, pls
answer them. BTW, it's supported on _some_ Linux distros.
HB_WITH_QT_WEBKIT is no solution, but hack. Such setting
should be resolved automatically.
I was expressing the way help can be presented in hbIDE.
In no way I expressed that webkit should be part of hbQT
and be included in hbIDE. I had pointed out it load factor
which is of prime concern for me. This is the single most reason
that I wrote parser to read .uic files in place of calling QtUiTools
engine. And there is no need and place of such heavy load in hbIDE.

To answer next messages, I would say that, at the point when
I removed QtWebKit, I was not equipped how to separate that
component as stand alone. Now probably I think I can do it,
I will exercise another effort.
Post by Viktor Szakáts
Or, it's still an option to move the whole QT related
stuff from Harbour SVN to somewhere else and satisfy
QT user special requests there.
This is not an option, please...




-----
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-13834-trunk-harbour-tp4545547p4548357.html
Sent from the harbour-devel mailing list archive at Nabble.com.
Viktor Szakáts
2010-02-10 15:20:37 UTC
Permalink
Post by Pritpal Bedi
Post by Viktor Szakáts
First we should discuss all concerns, if you care, pls
answer them. BTW, it's supported on _some_ Linux distros.
HB_WITH_QT_WEBKIT is no solution, but hack. Such setting
should be resolved automatically.
I was expressing the way help can be presented in hbIDE.
In no way I expressed that webkit should be part of hbQT
and be included in hbIDE. I had pointed out it load factor
which is of prime concern for me. This is the single most reason
that I wrote parser to read .uic files in place of calling QtUiTools
engine. And there is no need and place of such heavy load in hbIDE.
To answer next messages, I would say that, at the point when
I removed QtWebKit, I was not equipped how to separate that
component as stand alone. Now probably I think I can do it,
I will exercise another effort.
Maybe it went unnoticed, but I've spent a considerate amount
of time committing changes to help such separation. Aside
from the base system, it needs continuous attention to avoid
creating unwanted dependencies, so it's not a one-time task.
Plus in case of QtWebKit, additional autodetection will have
to be added to its Makefile.
Post by Pritpal Bedi
Post by Viktor Szakáts
Or, it's still an option to move the whole QT related
stuff from Harbour SVN to somewhere else and satisfy
QT user special requests there.
This is not an option, please...
It's still an option. You've chosen to go your own separate
way with these components, f.e. HBIDE lives in its own little
"visual" world cut off from any interoperation with so called
"non-visual" world. Harbour needs to offer more than that, and
there is no technical reason not to do so. Anyway we're also
facing a serious bloat by these components now.

Brgds,
Viktor
Pritpal Bedi
2010-02-10 16:20:33 UTC
Permalink
Post by Viktor Szakáts
Maybe it went unnoticed, but I've spent a considerate amount
of time committing changes to help such separation. Aside
from the base system, it needs continuous attention to avoid
creating unwanted dependencies, so it's not a one-time task.
Plus in case of QtWebKit, additional autodetection will have
to be added to its Makefile.
The action would be :

1. Re-create contrib/hbqt/qtwebkit folder.
2. Place all the webkit related classes, auto generated, or otherwise, i.e.,
hbqt.h.
3. Contains its own filelist.mk and makefile
4. Create separate lib hbqtwebkit.
5. This library will have dependancy on hbqt, hbqtcore, hbqtgui, hbqtnetwork
but no other lib must have dependancy on hbqtwebkit.
6. None of the projects in SVN should have dependancy on hbqtwebkit.

Is the above path OK ?
Post by Viktor Szakáts
It's still an option. You've chosen to go your own separate
way with these components, f.e. HBIDE lives in its own little
"visual" world cut off from any interoperation with so called
"non-visual" world. Harbour needs to offer more than that, and
there is no technical reason not to do so. Anyway we're also
facing a serious bloat by these components now.
No, I do not want to choose my own separate way, which
will never get matured and will never be realized. Under the main
banner, the likelyhood of realization are hundreds of time more.

So far I was busy with integrating various visual components
needed to present an effective user-interface. Now I think it has
reached to some level of acceptance, so I will be focussing on
bridging the gap between visual and non-visual components for
the new couple of weeks. You can expect many questions in the process.
One is already posted in another thread.




-----
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-13834-trunk-harbour-tp4545547p4548926.html
Sent from the harbour-devel mailing list archive at Nabble.com.
Viktor Szakáts
2010-02-10 16:38:03 UTC
Permalink
Post by Pritpal Bedi
Post by Viktor Szakáts
Maybe it went unnoticed, but I've spent a considerate amount
of time committing changes to help such separation. Aside
from the base system, it needs continuous attention to avoid
creating unwanted dependencies, so it's not a one-time task.
Plus in case of QtWebKit, additional autodetection will have
to be added to its Makefile.
1. Re-create contrib/hbqt/qtwebkit folder.
2. Place all the webkit related classes, auto generated, or otherwise, i.e.,
hbqt.h.
If you include QtWebKit related stuff in hbqt.h,
there won't be guarantee that it's not used,
so it should have its own local hbqtwebkit.h header.
(this is true even for hbqtnetwork lib, or hbqtgui
for that matter, so it should also be fixed.)
Post by Pritpal Bedi
3. Contains its own filelist.mk and makefile
4. Create separate lib hbqtwebkit.
5. This library will have dependancy on hbqt, hbqtcore, hbqtgui, hbqtnetwork
but no other lib must have dependancy on hbqtwebkit.
6. None of the projects in SVN should have dependancy on hbqtwebkit.
Technically they could, but the whole chain
should be independent from core component parts.
Post by Pritpal Bedi
Is the above path OK ?
Yes, and you will also need autodetection to
avoid failure on platforms how chose not to provide
qtwebkit.

Using something like this instead of calling central detect.mk:
---
HB_HAS_QT_WEBKIT :=

_DET_DSP_NAME := qt
_DET_VAR_INC_ := HB_INC_QT
_DET_VAR_HAS_ := HB_HAS_QT_WEBKIT
_DET_FLT_PLAT := !dos
_DET_FLT_COMP := !mingw64 !watcom !bcc !pocc !pocc64 !poccarm !msvcia64
_DET_INC_DEFP := /usr/include/qt4 /usr/lib/qt4/include /usr/include /Developer/qt/include
# untested
_DET_INC_HEAD := /QtWebKit/QtWebKit
include $(TOP)$(ROOT)config/detfun.mk

ifeq ($(HB_PLATFORM),darwin)
ifeq ($(HB_HAS_QT_WEBKIT),)
_DET_DSP_NAME := qt
_DET_VAR_INC_ := HB_INC_QT
_DET_VAR_HAS_ := HB_HAS_QT_WEBKIT
_DET_INC_DEFP := /Library/Frameworks/QtWebKit.framework/Versions/4/Headers
_DET_INC_HEAD := /QtWebKit
include $(TOP)$(ROOT)config/detfun.mk
endif
endif
---

To do that efficiently moc detection would be better moved
to separate mocdet.mk file and include that in all Makefiles.
Post by Pritpal Bedi
Post by Viktor Szakáts
It's still an option. You've chosen to go your own separate
way with these components, f.e. HBIDE lives in its own little
"visual" world cut off from any interoperation with so called
"non-visual" world. Harbour needs to offer more than that, and
there is no technical reason not to do so. Anyway we're also
facing a serious bloat by these components now.
No, I do not want to choose my own separate way, which
will never get matured and will never be realized. Under the main
banner, the likelyhood of realization are hundreds of time more.
So far I was busy with integrating various visual components
needed to present an effective user-interface. Now I think it has
reached to some level of acceptance, so I will be focussing on
bridging the gap between visual and non-visual components for
the new couple of weeks. You can expect many questions in the process.
One is already posted in another thread.
Thank you.

I didn't follow how is the memory unreleasing issue now,
but if possible it would be good find a solution for it.

Brgds,
Viktor

Viktor Szakáts
2010-02-10 09:03:18 UTC
Permalink
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.

Brgds,
Viktor
Post by Franček Prijatelj
Hi
Post by vouchcac-Rn4VEauK+AKRv+
As we have decided against QtWebkit, this implementation
may not look highly professional, will surely solve
our purpose.
I don't understand, what is the reason for this decision.
I am currently working with Qt 4.6.1 (both MSVC8, and official MINGW 4.0)
with no problems.
IMHO QtWebkit is one of the most important parts of Qt
(and other toolkits to : WebkitGTK,wxWebkit).
In the near future: "DESKTOP==BROWSER & GUI==BROWSER BASED.
There is a lot off evidence: GNOME SHELL,CHROME OS,Qt (QML, SVG, CSS...)
As I understood and as I hope , it was only a temporary decision .
Today it's easier to develop desktop apps with Qt designer, GLADE or Delphi,
but that is changing rapidly.
The only problem is that there are to many possibilities
(AJAX,XUL,SVG,HTML5) .
Html is standard for documentation for many years now (CHM is html with some
extensions).
I hope that this decision will be reconsidered again.
BRGS
Franček
--
View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13834--trunk-harbour-tp27525434p27526450.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
http://lists.harbour-project.org/mailman/listinfo/harbour
Pritpal Bedi
2010-02-10 09:23:07 UTC
Permalink
Post by Viktor Szakáts
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.

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.




-----
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context: http://n2.nabble.com/SF-net-SVN-harbour-project-13834-trunk-harbour-tp4545547p4546782.html
Sent from the harbour-devel mailing list archive at Nabble.com.
Viktor Szakáts
2010-02-10 09:46:42 UTC
Permalink
Post by Pritpal Bedi
Post by Viktor Szakáts
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.
Post by Pritpal Bedi
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
Franček Prijatelj
2010-02-10 11:46:17 UTC
Permalink
Hi
Post by Viktor Szakáts
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.
Many modern applications (almost all IDES) use integrated web machine
(GECKO of Firefox, Webkit of Safari,Chrome,Trident of IE) for
documentation. Qt assistant uses QtWebkit. Ms uses Trident in many places
(Visual studio,..)
As I said, the trend is in replacement of UI with browser based UI.
Many of web based UI toolkits are IMHO even more advanced and have
more controls than "standard" toolkits.
For example : http://demo.qooxdoo.org/current/demobrowser/

BRGS
Franček
--
View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13834--trunk-harbour-tp27525434p27529909.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
Viktor Szakáts
2010-02-10 12:12:43 UTC
Permalink
Post by Franček Prijatelj
Post by Viktor Szakáts
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.
Many modern applications (almost all IDES) use integrated web machine
(GECKO of Firefox, Webkit of Safari,Chrome,Trident of IE) for
Can't see your point, these are web browser applications,
so obviously they have a browser engine built-in.
Post by Franček Prijatelj
documentation. Qt assistant uses QtWebkit. Ms uses Trident in many places
(Visual studio,..)
So you say it's worth 20MB and all the security
risks just to display help text? IMO this is totally
wrong, even in MSVS. Last time MS tried to integrate
their browser into anything more widely used, they got
a large lawsuit as a result. So now they only use
it in such niche tools like dev IDE.

Besides the lawsuit, it's an ill idea from a technical
POV also.
Post by Franček Prijatelj
As I said, the trend is in replacement of UI with browser based UI.
Many of web based UI toolkits are IMHO even more advanced and have
To me the direction rather looks like moving applications
inside the browser, rather than moving the browser inside
applications.
Post by Franček Prijatelj
more controls than "standard" toolkits.
For example : http://demo.qooxdoo.org/current/demobrowser/
So now that we have a half-developed and not very well
tested GUI, we should start to develop a client-side-only
GUI based on html? IMO the concept is wrong and the
execution is wrong as well.

Or as the saying goes: 'All application gets "developed"
until the point they have an integrated e-mail client'?
(or a web browser, or feed-reader).

Perfect recipe for bloatware.

Guys, please move out QT from our repository and fulfill
these dreams, for Harbour Project it's much off topic.

Brgds,
Viktor
Franček Prijatelj
2010-02-10 12:31:37 UTC
Permalink
Hi
Post by Viktor Szakáts
To me the direction rather looks like moving applications
inside the browser, rather than moving the browser inside
applications.
No.
I am just using browser as a very intelligent terminal.
Some time ago (I am old timer, started with CLIPPER SUMMER 87)
i worked on VT100 terminals.
I used a lot of escape sequences for some fancy effects as "bold text,...."
Today i see embeded browser as much more intelligent terminal which
replaced ESC sequences with XML/HTML based technologies.
Post by Viktor Szakáts
So now that we have a half-developed and not very well
tested GUI, we should start to develop a client-side-only
GUI based on html? IMO the concept is wrong and the
execution is wrong as well.
There was no such proposal.
Only a proposal to include a Webkit, which is capable of many things.

BRGS
Franček
--
View this message in context: http://old.nabble.com/SF.net-SVN%3A-harbour-project%3A-13834--trunk-harbour-tp27525434p27530471.html
Sent from the Harbour - Dev mailing list archive at Nabble.com.
Viktor Szakáts
2010-02-10 13:02:52 UTC
Permalink
Post by Franček Prijatelj
Post by Viktor Szakáts
To me the direction rather looks like moving applications
inside the browser, rather than moving the browser inside
applications.
No.
I am just using browser as a very intelligent terminal.
Some time ago (I am old timer, started with CLIPPER SUMMER 87)
i worked on VT100 terminals.
I used a lot of escape sequences for some fancy effects as "bold text,...."
Today i see embeded browser as much more intelligent terminal which
replaced ESC sequences with XML/HTML based technologies.
Yes, browser is an intelligent terminal (but also dumb
in some respect), but I fail to see why we need our own
Harbour wrapped intelligent terminal, since "web standards"
are supposed to be open standards, so any existing browser
should do. It would also be a pretty bad thing to create
Harbour specific client-side browser extensions.

The whole point of the browser, is that it's replaceable,
available on all platforms, and you don't have to maintain
your own.

Brgds,
Viktor
Loading...