Now that HTML is ubiquitious today, what possibilities are there to
embed such a viewer in a vw application? Required is HTML with CSS only, possibly XML, no flash or other plug-in needed. It should handle static html files (e.g. as help pages), but also dynamically generated content and allow for event callback into the calling application for activated links, e.g. to generate new dynamic content. WithStyle was aimed for that, but unfortunately stopped development some time ago, is capable of most features we currently need, deployed only in Bottomfeeder and in our shop AFAIK. It is a dead end however and probably will be which is a valid decision. But where are the alternatives? Webkit seems one way to go, Anthony Blakey has done a lot with it that seemed easy, though little catched on with this or commented (including me, I have to admit, but nevertheless I was very interested in possible results). It would provide a platform independent tool with even more features than required because it is a full blown rendering engine including plugins. I currently don't know about the license, integration and installation issues. And the future is currently unpredictable regarding support and maintenance, and I want to avoid a second WithStyle dilemma. Embedding IE as ActiveX is the very last on the wishlist. What other alternatives are there? The main challenge in my eyes is the communication with the calling application regarding to events on clicks, etc and the content that should be generated on the fly in response to the event, maybe even AJAX like page updates. So there must be an API that goes beyond a filename. I would be interested if and what others use for this purpose. Is there anybody out there that has the same need for HTML display in a desktop application and does not jump on the seaside train and just makes the whole app web-based? Thomas _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On 04/06/2008, at 12:47 AM, Thomas Brodt wrote: > Webkit seems one way to go, Anthony Blakey has done a lot with it that > seemed easy, though little catched on with this or commented > (including > me, I have to admit, but nevertheless I was very interested in > possible > results). It would provide a platform independent tool with even more > features than required because it is a full blown rendering engine > including plugins. I currently don't know about the license, For WebKit that differs for different platforms. There is currently an effort underway to eliminate the Apple libraries that stops WebKit being completely O/S on Windows. I'm not tracking that effort, but I thing it's nearly done. The code is a mix of licenses, mainly Apple BSD. There's no GPL, but there is some LGPL. Nothing that stops you shipping a commercial app (except for the aforementioned issue with Windows). > integration An embedded browser is already done. Decent integration with the DOM, and hence event handling, requires some changes to the VM's garbage collector. I've have a design for that. Deep integration with Javascript is somewhat more complicated, primarily because JS has it's own GC. Furthermore the JS engine has just been replaced, so it's something of a moving target. Anyway, DOM integration is easy and may well be enough. > and installation issues. WebKit is a set of libraries, you should ship them with your app to ensure you have the version of the browser that you expect. > And the future is currently unpredictable > regarding support and maintenance, and I want to avoid a second > WithStyle dilemma. All technical issues fade into insignificance compared to this. If you want a product that will be supported and maintained, then you need to pay for it. How much are you prepared to pay? If there were enough customers I could do it on a supported basis, but I'm going to bet right now that if Terry Raymond couldn't make enough from his excellent debugger, then I won't make enough from WebKit integration (or LLVM integration, or an improved UIPainter ...). I'd love to do these things on a commercial basis, with costs shared between a number of clients, but I suppose everyone expects Cincom to supply everything, and for the one price. If it was supported by Cincom then that's MORE development and support work for them, and given the nature of the solution it massively increases the native code component of the product, and doesn't even cover all the platforms (yet/out of the box) that VW ships on. You could always do the integration yourself ... as I was. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 A priest, a minister and a rabbi walk into a bar. The bartender says "What is this, a joke?" _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Hi Antony
thanks for your answer. If I understand correctly, the integration requires some VM modifications? The nice thing about WithStyle was that it all happened on the image level only. The open issues with JS don't bother me right now. But an integration can't be done only on the image level? Regarding support and maintenance, you are right. This will be the biggest problem. We might be willing to pay some amount for a solution (as an additional product to vw), but won't be able to fund your shop. And I share your expectations for the tremendous amount of additional users that may invest in an additional product to turn this into a real business opportunity. This is the rather sad situation that vw users live in. There is too little market, so there are fewer and fewer additional products on top of vw, so you are left with what Cincom provides and what the community develops and is willing to share as goodies. And Cincom has not enough power to deal with all request that come from customers. So many things fall aside for the long term or buzz projects like seaside that don't help me now, but bind capacities that are not available for projects I could take profit from. Thomas Antony Blakey schrieb: > > On 04/06/2008, at 12:47 AM, Thomas Brodt wrote: >> Webkit seems one way to go, Anthony Blakey has done a lot with it that >> seemed easy, though little catched on with this or commented (including >> me, I have to admit, but nevertheless I was very interested in possible >> results). It would provide a platform independent tool with even more >> features than required because it is a full blown rendering engine >> including plugins. I currently don't know about the license, > For WebKit that differs for different platforms. There is currently an > effort underway to eliminate the Apple libraries that stops WebKit > being completely O/S on Windows. I'm not tracking that effort, but I > thing it's nearly done. > > The code is a mix of licenses, mainly Apple BSD. There's no GPL, but > there is some LGPL. Nothing that stops you shipping a commercial app > (except for the aforementioned issue with Windows). >> integration > An embedded browser is already done. Decent integration with the DOM, > and hence event handling, requires some changes to the VM's garbage > collector. I've have a design for that. Deep integration with > Javascript is somewhat more complicated, primarily because JS has it's > own GC. Furthermore the JS engine has just been replaced, so it's > something of a moving target. > > Anyway, DOM integration is easy and may well be enough. > >> and installation issues. > > WebKit is a set of libraries, you should ship them with your app to > ensure you have the version of the browser that you expect. > >> And the future is currently unpredictable >> regarding support and maintenance, and I want to avoid a second >> WithStyle dilemma. > > All technical issues fade into insignificance compared to this. > > If you want a product that will be supported and maintained, then you > need to pay for it. How much are you prepared to pay? If there were > enough customers I could do it on a supported basis, but I'm going to > bet right now that if Terry Raymond couldn't make enough from his > excellent debugger, then I won't make enough from WebKit integration > (or LLVM integration, or an improved UIPainter ...). I'd love to do > these things on a commercial basis, with costs shared between a number > of clients, but I suppose everyone expects Cincom to supply > everything, and for the one price. > > If it was supported by Cincom then that's MORE development and support > work for them, and given the nature of the solution it massively > increases the native code component of the product, and doesn't even > cover all the platforms (yet/out of the box) that VW ships on. > > You could always do the integration yourself ... as I was. > > Antony Blakey > -------------------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > A priest, a minister and a rabbi walk into a bar. The bartender says > "What is this, a joke?" > > > > -- Mit freundlichen GrĂ¼ssen Thomas Brodt PORaBo Consulting Tel. +41 71 666 76 52 Fax. +41 71 666 76 57 http://www.porabo.ch _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On 04/06/2008, at 8:10 PM, Thomas Brodt wrote: > thanks for your answer. If I understand correctly, the integration > requires some VM modifications? The nice thing about WithStyle was > that it all happened on the image level only. The open issues with > JS don't bother me right now. But an integration can't be done only > on the image level? You would still need to ship the libraries, and use DLLCC and per- platform code to do the view embedding. I submitted the he changes to the VM on OSX to properly handle the kind of embedding that is purely visual, and they were accepted and are in 7.6. The VM changes are required if you want seamless DOM integration, without having to manual manage the reference counts to and from DOM objects. Otherwise you can do it all via DLLCC. However, doing manual GC is not what I regard as acceptable. The problem is that references are both to and from DOM nodes and you need to determine reachability. You could possible it by changing the reference granularity to the document, and presuming a single lifetime for all objects related to the document, but that isn't a scalable solution for a dynamic interface. In short - it depends on your use cases. > Regarding support and maintenance, you are right. This will be the > biggest problem. We might be willing to pay some amount for a > solution (as an additional product to vw), but won't be able to fund > your shop. And I share your expectations for the tremendous amount > of additional users that may invest in an additional product to turn > this into a real business opportunity. I'm not interested in this as a business opportunity and I don't need the work. I'd like to get paid for the hours, not on an ongoing basis nor with expectation of return. It's not a lot of work, and I know there are large Cincom customers for whom it would be chump change, especially if shared. I say this just to be clear, not as an pitch :) I use a lot of free stuff, and I'm releasing free stuff, but right now my interests lie with a more radical re-examination of what-is- Smalltalk. Maybe I'll get back to WebKit if I need it for my exploration. Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 One should respect public opinion insofar as is necessary to avoid starvation and keep out of prison, but anything that goes beyond this is voluntary submission to an unnecessary tyranny. -- Bertrand Russell _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Antony Blakey-2
Antony Blakey wrote:
> Deep integration with Javascript is somewhat more complicated, primarily > because JS has it's own GC. Furthermore the JS engine has just been > replaced, so it's something of a moving target. I thought you mentioned in one of your blog posts that the WebKit integration would allow to use plain Smalltalk instead of Javascript? Is this not feasible for some reason? Regards, Robin _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
On 05/06/2008, at 5:00 AM, Robin Barendregt wrote: > I thought you mentioned in one of your blog posts that the WebKit > integration would allow to use plain Smalltalk instead of Javascript? > Is this not feasible for some reason? By providing bidirectional interop with the DOM, you can use Smalltalk to do everything that you would normally do in JS.Given a WebKitBrowser part, you could access the DOM, manipulate it and add Smalltalk objects as event handlers (onclick etc). That's not the same as allowing e.g. <script type='text/smalltalk'>...</script> (which I never intended). Note that the DOM in WebKit includes SVG and Canvas objects, so it is both a declarative and procedural graphics platform as well. The interop with Javascript would be so that you can use some of the existing JS components (such as rich text editor components) without having to rewrite them. I wasn't planning on doing JS interop because of the difficulty of integrating the two GCs. Code that intrudes into the WebKit codebase is a maintenance issue. Antony Blakey -------------------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 Man will never be free until the last king is strangled with the entrails of the last priest. -- Denis Diderot _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Thomas Brodt
FWIW, readers of this thread may find this interesting...
http://research.sun.com/projects/lively/#supported >From the website: "Intellectual heritage The idea of the Lively Kernel was inspired in part by the success of the Squeak Smalltalk programming environment. In this regard, we owe a debt to all the people who designed that system. The specific choice of a Morphic-style graphics architecture was inspired by the simplicity of such an architecture manifested originally in the Self system and later in the Squeak system." >-----Original Message----- >From: [hidden email] [mailto:[hidden email]] On Behalf >Of Thomas Brodt >Sent: 4 June 2008 10:41 p.m. >To: Antony Blakey >Cc: VWNC >Subject: Re: [vwnc] [VW] Embeddable WebBrowser for VW? > >Hi Antony > >thanks for your answer. If I understand correctly, the integration >requires some VM modifications? The nice thing about WithStyle was that >it all happened on the image level only. The open issues with JS don't >bother me right now. But an integration can't be done only on the image >level? > >Regarding support and maintenance, you are right. This will be the >biggest problem. We might be willing to pay some amount for a solution >(as an additional product to vw), but won't be able to fund your shop. >And I share your expectations for the tremendous amount of additional >users that may invest in an additional product to turn this into a real >business opportunity. >This is the rather sad situation that vw users live in. There is too >little market, so there are fewer and fewer additional products on top >of vw, so you are left with what Cincom provides and what the community >develops and is willing to share as goodies. > >And Cincom has not enough power to deal with all request that come from >customers. So many things fall aside for the long term or buzz projects >like seaside that don't help me now, but bind capacities that are not >available for projects I could take profit from. > >Thomas > >Antony Blakey schrieb: >> >> On 04/06/2008, at 12:47 AM, Thomas Brodt wrote: >>> Webkit seems one way to go, Anthony Blakey has done a lot with it >>> seemed easy, though little catched on with this or commented (including >>> me, I have to admit, but nevertheless I was very interested in possible >>> results). It would provide a platform independent tool with even more >>> features than required because it is a full blown rendering engine >>> including plugins. I currently don't know about the license, >> For WebKit that differs for different platforms. There is currently an >> effort underway to eliminate the Apple libraries that stops WebKit >> being completely O/S on Windows. I'm not tracking that effort, but I >> thing it's nearly done. >> >> The code is a mix of licenses, mainly Apple BSD. There's no GPL, but >> there is some LGPL. Nothing that stops you shipping a commercial app >> (except for the aforementioned issue with Windows). >>> integration >> An embedded browser is already done. Decent integration with the DOM, >> and hence event handling, requires some changes to the VM's garbage >> collector. I've have a design for that. Deep integration with >> Javascript is somewhat more complicated, primarily because JS has >> own GC. Furthermore the JS engine has just been replaced, so it's >> something of a moving target. >> >> Anyway, DOM integration is easy and may well be enough. >> >>> and installation issues. >> >> WebKit is a set of libraries, you should ship them with your app to >> ensure you have the version of the browser that you expect. >> >>> And the future is currently unpredictable >>> regarding support and maintenance, and I want to avoid a second >>> WithStyle dilemma. >> >> All technical issues fade into insignificance compared to this. >> >> If you want a product that will be supported and maintained, then you >> need to pay for it. How much are you prepared to pay? If there were >> enough customers I could do it on a supported basis, but I'm going to >> bet right now that if Terry Raymond couldn't make enough from his >> excellent debugger, then I won't make enough from WebKit integration >> (or LLVM integration, or an improved UIPainter ...). I'd love to do >> these things on a commercial basis, with costs shared between a >> of clients, but I suppose everyone expects Cincom to supply >> everything, and for the one price. >> >> If it was supported by Cincom then that's MORE development and support >> work for them, and given the nature of the solution it massively >> increases the native code component of the product, and doesn't even >> cover all the platforms (yet/out of the box) that VW ships on. >> >> You could always do the integration yourself ... as I was. >> >> Antony Blakey >> -------------------------- >> CTO, Linkuistics Pty Ltd >> Ph: 0438 840 787 >> >> A priest, a minister and a rabbi walk into a bar. The bartender says >> "What is this, a joke?" >> >> >> >> > > >-- >Mit freundlichen GrĂ¼ssen > >Thomas Brodt >PORaBo Consulting >Tel. +41 71 666 76 52 >Fax. +41 71 666 76 57 >http://www.porabo.ch > > >_______________________________________________ >vwnc mailing list >[hidden email] >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Stewart MacLean wrote:
> FWIW, readers of this thread may find this interesting... > Hmmm.... Doesn't Dan Ingalls work at Sun now? > http://research.sun.com/projects/lively/#supported > > >From the website: > > "Intellectual heritage > The idea of the Lively Kernel was inspired in part by the success of the > Squeak Smalltalk programming environment. In this regard, we owe a debt > to all the people who designed that system. The specific choice of a > Morphic-style graphics architecture was inspired by the simplicity of > such an architecture manifested originally in the Self system and later > in the Squeak system." > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
He sure does... "A Distinguished Engineer at Sun Microsystems
Laboratories, Dan Ingalls is interested in dynamic
languages, graphics and kernel software. He is Principal Investigator of the
Lively Kernel project, a project to rethink web programming and the web itself." http://research.sun.com/people/mybio.php?c=394 >-----Original Message----- >From: [hidden email] [mailto:[hidden email]] On Behalf >Of Donald MacQueen >Sent: 6 June 2008 9:51 a.m. >To: 'VWNC' >Subject: Re: [vwnc] [VW] Embeddable WebBrowser for VW? > >Stewart MacLean wrote: >> FWIW, readers of this thread may find this interesting... >> >Hmmm.... Doesn't Dan Ingalls work at Sun now? > >> http://research.sun.com/projects/lively/#supported >> >> >From the website: >> >> "Intellectual heritage >> The idea of the Lively Kernel was inspired in part by the success of the >> Squeak Smalltalk programming environment. In this regard, we owe a debt >> to all the people who designed that system. The specific choice of a >> Morphic-style graphics architecture was inspired by the simplicity of >> such an architecture manifested originally in the Self system and later >> in the Squeak system." >> >> >> > >_______________________________________________ >vwnc mailing list >http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |