Hello,
The new HTML formatting for the news headlines is ready and a lot nice
looking that the old ridiculously-long-blue-eye-popping-links :))
Attached is the patch for this. Please note however that it relays on
the previous patch for ChatConversationPanel in order to display
correctly (Yana confirmed that it was a bug )
Have a nice after-noon,
Mihai

I would like to use S-C to integrate several features now running in
different applets and AJAX in a Web browser. It looks like the S-C HTML
display could be used to flip the relationship between S-C running as an
applet and the Web page in which it's embedded. I'd like to put AJAX,
and maybe even more applets, into the S-C HTML panel. That means S-C
running Javascript.

Which would be an excellent feature for more than just my use case.
Javascript could be used to script all of the S-C features, if they're
exposed in the DOM. How close is S-C to an HTML panel supporting
Javascript, with a scriptable S-C API exposed in it? And who else would
like to work with me to get S-C the rest of the way there? In the
meantime, how much of the S-C API is exposed as public methods that an
S-C applet exposes in a Web page, for a klugey way to do some of this?

···

On Mon, 2007-07-09 at 17:00 +0300, Mihai Balan wrote:

Hello,
The new HTML formatting for the news headlines is ready and a lot nice
looking that the old ridiculously-long-blue-eye-popping-links :))
Attached is the patch for this. Please note however that it relays on
the previous patch for ChatConversationPanel in order to display
correctly (Yana confirmed that it was a bug )
Have a nice after-noon,
Mihai
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

Hello,
The new HTML formatting for the news headlines is ready and a lot nice
looking that the old ridiculously-long-blue-eye-popping-links :))
Attached is the patch for this. Please note however that it relays on
the previous patch for ChatConversationPanel in order to display
correctly (Yana confirmed that it was a bug )
Have a nice after-noon,
Mihai
------------------------------------------------------------------------

I would like to use S-C to integrate several features now running in
different applets and AJAX in a Web browser. It looks like the S-C HTML
display could be used to flip the relationship between S-C running as an
applet and the Web page in which it's embedded. I'd like to put AJAX,
and maybe even more applets, into the S-C HTML panel. That means S-C
running Javascript.

Looks like a nice idea.

Which would be an excellent feature for more than just my use case.
Javascript could be used to script all of the S-C features, if they're
exposed in the DOM. How close is S-C to an HTML panel supporting
Javascript, with a scriptable S-C API exposed in it? And who else would
like to work with me to get S-C the rest of the way there? In the
meantime, how much of the S-C API is exposed as public methods that an
S-C applet exposes in a Web page, for a klugey way to do some of this?

Currently the HTML panel in SC is a JEditorPane that uses an HTMLEditorKit. As much as I know the java HTMLEditorKit supports HTML version 3.2 with a few extensions, but it's also extensible. In your case I would try to make another UIService implementation based on the current one, which will provide an extended HTML editor. I can't think of any right now, but other libraries that provide such functionality probably already exist, so it might be useful to try and google them out.

Unfortunately I won't have the time to participate in writing code, but am very interested in any progress you make in this direction.

···

On Mon, 2007-07-09 at 17:00 +0300, Mihai Balan wrote:

Hello,
The new HTML formatting for the news headlines is ready and a lot nice
looking that the old ridiculously-long-blue-eye-popping-links :))
Attached is the patch for this. Please note however that it relays on
the previous patch for ChatConversationPanel in order to display
correctly (Yana confirmed that it was a bug )
Have a nice after-noon,
Mihai
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

You are gaining speed! How many patches are you planning on
submitting tomorrow? Maybe I should take a day off and work on
integrating them?

I've only had a single modification in
OperationSetBasicInstantMessagingRssImpl:
* I've kept text/html as one of the supported text types in
isContentTypeSupported(). Was there any particular reason to remove it?

Nice work, again!
Emil

Mihai Balan wrote:

···

Hello,
The new HTML formatting for the news headlines is ready and a lot nice
looking that the old ridiculously-long-blue-eye-popping-links :))
Attached is the patch for this. Please note however that it relays on
the previous patch for ChatConversationPanel in order to display
correctly (Yana confirmed that it was a bug )
Have a nice after-noon,
Mihai

Very good work.
I just add the display of the abstracts (just replace your patch
"RssFeedReader.java.patch" with the patch attached
"vincent_RssFeedReader.java.patch").

Cheers,
Vincent

Mihai Balan wrote:

Hello,
The new HTML formatting for the news headlines is ready and a lot nice
looking that the old ridiculously-long-blue-eye-popping-links :))
Attached is the patch for this. Please note however that it relays on
the previous patch for ChatConversationPanel in order to display
correctly (Yana confirmed that it was a bug )
Have a nice after-noon,
Mihai
------------------------------------------------------------------------

The HTML editor pane is not very w3c compliant
In example, when you give a “<br />” tag, you will have your line break (as expected) but you will have an “>” displayed (as an artefact).
For the images, the problem might be another kettle of fish. The images from the “google-news” feed are displayed as wished. But these of “ddj.com” are quite special. Indeed, “ddj.com” gives images images as follow : <img alt="" style=“border: 0;” border=“0” src=“http://www.pheedo.com/img.phdo?i=5534d5bba1bfb69d4a404d13d9b51ff6”/>
As you see, the image source is very strange ... just type the “src” field in your favorite browser and you will see that the image exists but is a “.gif” malformed (gimp says : “EOF / read error on image data”).
Finally, I do not know what we can do to improve this situation (excluding redefining the html editor pane).

Do someone have an idea on this subject?

Vincent

Emil Ivov wrote:

···

Hi Vincent,

I had a problem with the abstracts. It appears that some of them might
contain images, and this is apparently causing some really nasty
problems with the html editor pane :(.

Very good work.
I just add the display of the abstracts (just replace your patch "RssFeedReader.java.patch" with the patch attached "vincent_RssFeedReader.java.patch").

Cheers,
Vincent

Mihai Balan wrote:

Hello,
The new HTML formatting for the news headlines is ready and a lot nice
looking that the old ridiculously-long-blue-eye-popping-links :))
Attached is the patch for this. Please note however that it relays on
the previous patch for ChatConversationPanel in order to display
correctly (Yana confirmed that it was a bug )
Have a nice after-noon,
Mihai
------------------------------------------------------------------------

What's nasty about this is the fact, that there's no way for us to know
whether it'll fail before it actually does, and at that point it's
already in the history, so chances are we'll be getting failures every
time we try to open the corresponding message window.

I wonder if there's a way to detect and fix the problem in the message
window itself.

In case there isn't.

Well, it seems to me that DDJ's empty images don't seem to have anything
to do with information delivery and are more likely to be there to allow
for statistics. More generally, I don't think I've ever seen RSS flows
that absolutely require showing images in order for the information they
deliver to be meaningful so wouldn't it be best if we simply tried to
skip all images in RSS abstracts? (Possibly, replacing them with the alt
attribute value when it's available)

Emil

Vincent Lucas wrote:

···

Hi Emil

The HTML editor pane is not very w3c compliant
In example, when you give a “<br />” tag, you will have your line break
(as expected) but you will have an “>” displayed (as an artefact).
For the images, the problem might be another kettle of fish. The images
from the “google-news” feed are displayed as wished. But these of
“ddj.com” are quite special. Indeed, “ddj.com” gives images images as
follow : <img alt="" style=“border: 0;” border=“0”
src=“http://www.pheedo.com/img.phdo?i=5534d5bba1bfb69d4a404d13d9b51ff6”/>
As you see, the image source is very strange ... just type the “src”
field in your favorite browser and you will see that the image exists
but is a “.gif” malformed (gimp says : “EOF / read error on image data”).
Finally, I do not know what we can do to improve this situation
(excluding redefining the html editor pane).

Do someone have an idea on this subject?

Vincent

Emil Ivov wrote:

Hi Vincent,

I had a problem with the abstracts. It appears that some of them might
contain images, and this is apparently causing some really nasty
problems with the html editor pane :(.

Very good work.
I just add the display of the abstracts (just replace your patch
"RssFeedReader.java.patch" with the patch attached
"vincent_RssFeedReader.java.patch").

Cheers,
Vincent

Mihai Balan wrote:

Hello,
The new HTML formatting for the news headlines is ready and a lot nice
looking that the old ridiculously-long-blue-eye-popping-links :))
Attached is the patch for this. Please note however that it relays on
the previous patch for ChatConversationPanel in order to display
correctly (Yana confirmed that it was a bug )
Have a nice after-noon,
Mihai
------------------------------------------------------------------------

Isn't there a better HTML rendering component that is as forgiving of
"nonstandard" (but usable) HTML and common data objects (like slightly
weird GIFs)? There are so many Java web browsers, for workstations as
well as mobile phones/devices. One of them must use an HTML presentation
component that S-C can use, without having to rewrite that existing
"forgiving" code all over again.

And while we're looking, I'm plugging my own request for an HTML
component that can support Javascript, as I've posted to the list
recently.

···

On Wed, 2007-07-11 at 08:44 +0300, Emil Ivov wrote:

What's nasty about this is the fact, that there's no way for us to know
whether it'll fail before it actually does, and at that point it's
already in the history, so chances are we'll be getting failures every
time we try to open the corresponding message window.

I wonder if there's a way to detect and fix the problem in the message
window itself.

In case there isn't.

Well, it seems to me that DDJ's empty images don't seem to have anything
to do with information delivery and are more likely to be there to allow
for statistics. More generally, I don't think I've ever seen RSS flows
that absolutely require showing images in order for the information they
deliver to be meaningful so wouldn't it be best if we simply tried to
skip all images in RSS abstracts? (Possibly, replacing them with the alt
attribute value when it's available)

Emil

Vincent Lucas wrote:
> Hi Emil
>
> The HTML editor pane is not very w3c compliant
> In example, when you give a “<br />” tag, you will have your line break
> (as expected) but you will have an “>” displayed (as an artefact).
> For the images, the problem might be another kettle of fish. The images
> from the “google-news” feed are displayed as wished. But these of
> “ddj.com” are quite special. Indeed, “ddj.com” gives images images as
> follow : <img alt="" style=“border: 0;” border=“0”
> src=“http://www.pheedo.com/img.phdo?i=5534d5bba1bfb69d4a404d13d9b51ff6”/>
> As you see, the image source is very strange ... just type the “src”
> field in your favorite browser and you will see that the image exists
> but is a “.gif” malformed (gimp says : “EOF / read error on image data”).
> Finally, I do not know what we can do to improve this situation
> (excluding redefining the html editor pane).
>
> Do someone have an idea on this subject?
>
> Vincent
>
> Emil Ivov wrote:
>> Hi Vincent,
>>
>> I had a problem with the abstracts. It appears that some of them might
>> contain images, and this is apparently causing some really nasty
>> problems with the html editor pane :(.
>>
>> You can check out an example flow here:
>> http://ddj.com/rss/all.xml;jsessionid=OEVRSWPBVGBOQQSNDLRSKHSCJUNN2JVN
>>
>> Thanks!
>> Emil
>>
>> Vincent Lucas wrote:
>>> Hi Mihai,
>>>
>>> Very good work.
>>> I just add the display of the abstracts (just replace your patch
>>> “RssFeedReader.java.patch” with the patch attached
>>> “vincent_RssFeedReader.java.patch”).
>>>
>>> Cheers,
>>> Vincent
>>>
>>> Mihai Balan wrote:
>>>> Hello,
>>>> The new HTML formatting for the news headlines is ready and a lot nice
>>>> looking that the old ridiculously-long-blue-eye-popping-links :))
>>>> Attached is the patch for this. Please note however that it relays on
>>>> the previous patch for ChatConversationPanel in order to display
>>>> correctly (Yana confirmed that it was a bug )
>>>> Have a nice after-noon,
>>>> Mihai
>>>> ------------------------------------------------------------------------
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>>>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>> ------------------------------------------------------------------------
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>
>

Hi and sorry for the late answer (stormy weather ),
IMO the best would be to keep things simple. Accepting a minimum of
formatting code and stripping the rest of the tags while keeping the
results readable would be optimal, as there is a very wide range of
content - valid or not valid - that can be included in RSS feeds.
Let's not forget that usually full-fledged RSS Readers, be they online
or offline, use a very basic rendering engine for displaying the
contents *in the feed* and usually display the page referred in the
feed in a platform dependent HTML rendering component.
I'll dig a little further on this matter and come up with a solution
as soon as I get to fix my problems with the Internet connection,
caused by the storm of the last few days

What's nasty about this is the fact, that there's no way for us to know
whether it'll fail before it actually does, and at that point it's
already in the history, so chances are we'll be getting failures every
time we try to open the corresponding message window.

I wonder if there's a way to detect and fix the problem in the message
window itself.

In case there isn't.

Well, it seems to me that DDJ's empty images don't seem to have anything
to do with information delivery and are more likely to be there to allow
for statistics. More generally, I don't think I've ever seen RSS flows
that absolutely require showing images in order for the information they
deliver to be meaningful so wouldn't it be best if we simply tried to
skip all images in RSS abstracts? (Possibly, replacing them with the alt
attribute value when it's available)

Isn't there a better HTML rendering component that is as forgiving of
"nonstandard" (but usable) HTML and common data objects (like slightly
weird GIFs)? There are so many Java web browsers, for workstations as
well as mobile phones/devices. One of them must use an HTML presentation
component that S-C can use, without having to rewrite that existing
"forgiving" code all over again.

After doing a quick search on the net, it seems to me that there are several Java web browsers that can be used to replace the current rendering component. Most of the solutions are proprietary, so they're unusable for us. I think there are some licensing schemes under which one may use some of the components for free, but it's still not open source.

This said, I'm not sure if such an improvement is really necessary at this stage - after all, this is an IM client, not a web browser, and the speed/size/development costs will certainly degrade the quality of the SIP Communicator as such. In my opinion if a protocol provider implementor is aware that some malformed HTML might be passed to the rendering component, she or he should try to fix the HTML (if possible). For now.

I'm not aware to what extent the current HTML engine is rendering the things correctly, but I'm VERY pleased with the results so far, so I think that for the moment we can just leave it as is.

And while we're looking, I'm plugging my own request for an HTML
component that can support Javascript, as I've posted to the list
recently.

The commercial solutions support JavaScript, but as I said before, these don't count. On the other hand there is the possibility to integrate a JavaScript rendering engine (such as Rhino) BUT it doesn't seem an easy task (at a first glance). A fork of Rhino is integrated in Java 6, but I'm not sure if this automatically means integration with Swing (I doubt it). Again, the efforts of adding such functionality seem disproportional to the results (in terms of what we want to achieve).

I'm really curious to know if it's that difficult to implement, so if you find this topic interesting, you can try investigating the issue in depth.

Regards,
Alex

···

Le 11 juil. 07 à 16:31, Matthew Rubenstein a écrit :

On Wed, 2007-07-11 at 08:44 +0300, Emil Ivov wrote:

What's nasty about this is the fact, that there's no way for us to know
whether it'll fail before it actually does, and at that point it's
already in the history, so chances are we'll be getting failures every
time we try to open the corresponding message window.

I wonder if there's a way to detect and fix the problem in the message
window itself.

In case there isn't.

Well, it seems to me that DDJ's empty images don't seem to have anything
to do with information delivery and are more likely to be there to allow
for statistics. More generally, I don't think I've ever seen RSS flows
that absolutely require showing images in order for the information they
deliver to be meaningful so wouldn't it be best if we simply tried to
skip all images in RSS abstracts? (Possibly, replacing them with the alt
attribute value when it's available)

Emil

Vincent Lucas wrote:

Hi Emil

The HTML editor pane is not very w3c compliant
In example, when you give a “<br />” tag, you will have your line break
(as expected) but you will have an “>” displayed (as an artefact).
For the images, the problem might be another kettle of fish. The images
from the “google-news” feed are displayed as wished. But these of
“ddj.com” are quite special. Indeed, “ddj.com” gives images images as
follow : <img alt="" style=“border: 0;” border=“0”
src=“http://www.pheedo.com/img.phdo?i=5534d5bba1bfb69d4a404d13d9b51ff6”/>
As you see, the image source is very strange ... just type the “src”
field in your favorite browser and you will see that the image exists
but is a “.gif” malformed (gimp says : “EOF / read error on image data”).
Finally, I do not know what we can do to improve this situation
(excluding redefining the html editor pane).

Do someone have an idea on this subject?

Vincent

Emil Ivov wrote:

Hi Vincent,

I had a problem with the abstracts. It appears that some of them might
contain images, and this is apparently causing some really nasty
problems with the html editor pane :(.

Very good work.
I just add the display of the abstracts (just replace your patch
"RssFeedReader.java.patch" with the patch attached
"vincent_RssFeedReader.java.patch").

Cheers,
Vincent

Mihai Balan wrote:

Hello,
The new HTML formatting for the news headlines is ready and a lot nice
looking that the old ridiculously-long-blue-eye-popping-links :))
Attached is the patch for this. Please note however that it relays on
the previous patch for ChatConversationPanel in order to display
correctly (Yana confirmed that it was a bug )
Have a nice after-noon,
Mihai
------------------------------------------------------------------------

Let's test these patch (see attachments) that are displaying RSS feeds with abstract and images.
Just note that these patches are correcting the self-closing of <br> and <img> tags.
With these features, the http://ddj.com/rss/all.xml;jsessionid=OEVRSWPBVGBOQQSNDLRSKHSCJUNN2JVN feeds works but still complain (trace log, but does not crash) with unreadable images.

Hi and sorry for the late answer (stormy weather ),
IMO the best would be to keep things simple. Accepting a minimum of
formatting code and stripping the rest of the tags while keeping the
results readable would be optimal, as there is a very wide range of
content - valid or not valid - that can be included in RSS feeds.
Let's not forget that usually full-fledged RSS Readers, be they online
or offline, use a very basic rendering engine for displaying the
contents *in the feed* and usually display the page referred in the
feed in a platform dependent HTML rendering component.
I'll dig a little further on this matter and come up with a solution
as soon as I get to fix my problems with the Internet connection,
caused by the storm of the last few days

What's nasty about this is the fact, that there's no way for us to know
whether it'll fail before it actually does, and at that point it's
already in the history, so chances are we'll be getting failures every
time we try to open the corresponding message window.

I wonder if there's a way to detect and fix the problem in the message
window itself.

In case there isn't.

Well, it seems to me that DDJ's empty images don't seem to have anything
to do with information delivery and are more likely to be there to allow
for statistics. More generally, I don't think I've ever seen RSS flows
that absolutely require showing images in order for the information they
deliver to be meaningful so wouldn't it be best if we simply tried to
skip all images in RSS abstracts? (Possibly, replacing them with the alt
attribute value when it's available)