use webkit instead of gtktextview

Pleas see the relevant bug ticket and check the mailing list for
previous discussions.

Short summary is that webkit python / gtk bindings are far from the
level of integration that would be needed to reproduce the current
interface of zim.

So would be a considerable amount of work. Partly contributing to the
gtk webkit library to expose sufficient interfaces.

Regards,

Jaap

Greetings Jaap,

Thanks for the comments! I definitely see your point, but on the other hand, given the limited functionality of the textview widget compared to that of what a browser can do, I have the feeling that an opportunity is lost here. I think this statement is underlined by those things in the wishlist that are not implemented, simply because they are hard to implement in the textview.

Cheers,
Zoltán

Well if you want to pick up the challenge and do a prototype based on
webkit I would be very interested to see how it works out :)

-- Jaap

On Mon, Aug 20, 2012 at 3:55 PM, Zoltán Vörös
<email address hidden> wrote:
> Question #206232 on Zim changed:
> https://answers.launchpad.net/zim/+question/206232
>
> Zoltán Vörös posted a new comment:
> Greetings Jaap,
>
> Thanks for the comments! I definitely see your point, but on the other
> hand, given the limited functionality of the textview widget compared to
> that of what a browser can do, I have the feeling that an opportunity is
> lost here. I think this statement is underlined by those things in the
> wishlist that are not implemented, simply because they are hard to
> implement in the textview.
>
> Cheers,
> Zoltán
>
> --
> You received this question notification because you are an answer
> contact for Zim.

Greetings Jaap,

I think I would like to drop a comment here, for there might be some misunderstanding, or misinterpretation of what I had in mind. This is due to the fact that my original statement wasn't really very clear.

> Short summary is that webkit python / gtk bindings are far from the
> level of integration that would be needed to reproduce the current
> interface of zim.

I didn't propose to replace all widgets in zim by webkit. I am fully aware of the difficulties, and this wouldn't even be necessary. All I wanted to say is that, if one replaces the main textview, the one that displays the content of the text files, but leaves everything else the same, then more things could be displayed.

I don't quite understand what you meant by saying that the webkit bindings lack required features. After all, there is not too much interaction in the main textview, it only displays, really. As far as I see, what would be required here is that instead of passing the text to the textview widget with the appropriate gtk tags, one would have to pass the text to the browser as a html markup. Although, even that is probably unnecessary for two reasons. One is that one could just pass on the markdowned text, and filter it through a markdown parser. This could be javascript, and this is how ipython's markdown interpreter works in the new htmlnotebook. The second reaons is that one could take a simple text editor, written in javascipt, and then let the browser do the work. There are many freely available javascript text editors, so this would be relatively straightforward.

In short, what I am advocating is to replace the notebook display container with a web browser, and let zim do the rest as it does now.

Cheers,
Zoltán

On Wed, Aug 22, 2012 at 9:21 AM, Zoltán Vörös
<email address hidden> wrote:
> I didn't propose to replace all widgets in zim by webkit. I am fully
> aware of the difficulties, and this wouldn't even be necessary. All I
> wanted to say is that, if one replaces the main textview, the one that
> displays the content of the text files, but leaves everything else the
> same, then more things could be displayed.

That is understood. The difficulty is that there is a lot of
interaction between the textview itself and other widgets in the
interface. E.g. when the toggle buttons for bold / italic / .. should
reflect the state of the text under the cursor. Another example is
that when I use the "insert link" dialog I need to insert a link at
the current cursor. Then when the user selects "edit link" I need to
retrieve information again about the cursor position, etc. etc.

> I don't quite understand what you meant by saying that the webkit
> bindings lack required features. After all, there is not too much
> interaction in the main textview, it only displays, really. As far as I
> see, what would be required here is that instead of passing the text to
> the textview widget with the appropriate gtk tags, one would have to
> pass the text to the browser as a html markup. Although, even that is
> probably unnecessary for two reasons. One is that one could just pass on
> the markdowned text, and filter it through a markdown parser. This could
> be javascript, and this is how ipython's markdown interpreter works in
> the new htmlnotebook.

Not really, the index, tag plugin etc. all need information about the
parsed structure, so we need a representation of the document outside
the textview.

> The second reaons is that one could take a simple
> text editor, written in javascipt, and then let the browser do the work.
> There are many freely available javascript text editors, so this would
> be relatively straightforward.

Agree the javascript editors are becoming better, but I have yet to
see one that could be mistaken for a desktop editor. That is part of
the reason I started with zim in the first place, online wikis
were/are just to cumbersome to edit.

> In short, what I am advocating is to replace the notebook display
> container with a web browser, and let zim do the rest as it does now.

I understand, but I'm afraid you underestimate the impact of this change.

Regards,

Jaap