rssview-developers

[Rssview-developers] Performance Update & Feed Assitant

[Christoph W. <sai...@ya...>]

Hi,
 
I've a rather big update concerning rssview performance in my lokal project
folder. Should I check it in now or wait for a 2.1 release. We could do a
Beta 2 or a release candidate :)
To increase performance I tuned the register and unregister process for
event listeners so that only view components that are used by the view
receive events. And I tuned the JEditorPane to append text in an
asynchrounus way (the GUI is not blocked anymore).
I created an "alpha" implementation of our feed assitent. I would checkl it
in with the other changes.
 
All changes have been tested quite extensivly but some failures might still
reside in the code.
 
Ciao
Christoph
 
--
Christoph Walcher
Albrechtskreithgasse 4-6/1/11
A-1160 Wien
 
email:   chr...@we...
mobile: +43 (650) 8320065
 

Re: [Rssview-developers] Performance Update & Feed Assitant

[Martin <cin...@gm...>]

Am Mi, den 27.10.2004 schrieb Christoph Walcher um 13:04:

> I've a rather big update concerning rssview performance in my lokal
> project folder.

Wow. That's really what we need.

>  Should I check it in now or wait for a 2.1 release. We could do a
> Beta 2 or a release candidate :)

Yes. Performance and assistant are not radical changes.

> To increase performance I tuned the register and unregister process
> for event listeners so that only view components that are used by the
> view receive events. And I tuned the JEditorPane to append text in an
> asynchrounus way (the GUI is not blocked anymore).
> I created an "alpha" implementation of our feed assitent. I would
> checkl it in with the other changes.

Are you afraid, you could break something? We can branch the
project, but I would prefer, if you simply commit it. We can
test everything.

Martin

RE: [Rssview-developers] Performance Update & Feed Assitant

[Christoph W. <sai...@ya...>]

Hi,

Christoph Walcher wrote:
>> I've a rather big update concerning rssview performance in my lokal=20
>> project folder.
>
> Wow. That's really what we need.
>

We have it. Performance did not significantly increase for JEditorPane =
(it's
just terrible slow...) stuff. But the user experience is a lot better
because GUI is not blocked.

Do you have an idea how to implement a "delete article" action. My =
approach
would be:
* Save a "updated flag" for each article if it was in the last refresh =
run
* If an article is deleted:
  * mark all articles with "updated flag" as "ready to delete"
  * delete all other articles from database

Any more elegant ideas?

>>  Should I check it in now or wait for a 2.1 release. We could do a=20
>> Beta 2 or a release candidate :)
>
> Yes. Performance and assistant are not radical changes.
>
>> To increase performance I tuned the register and unregister process=20
>> for event listeners so that only view components that are used by the =

>> view receive events. And I tuned the JEditorPane to append text in an =

>> asynchrounus way (the GUI is not blocked anymore). I created an=20
>> "alpha" implementation of our feed assitent. I would checkl it in =
with=20
>> the other changes.

> Are you afraid, you could break something? We can branch the project, =
but
I would prefer, if you simply commit it. We can > test everything.

I'm not afraid to break something - I'm just afraid that I could =
introduce
too many new bugs so that our final release is delayed by some years =
again
:)

Cheers
Christoph

PS: Quoted by hand. Excuse the (possibly) ugly message