Hi!
On Fri, Oct 20, 2006 at 12:03:30PM -0700, Yen-Ju Chen wrote:
> So if you don't mind, I would like to spend some time on RSSKit and Grr.
> I will create a branch first and merge back after each stage..
> Here is my plan step by step:
>
> 1. Change the interface into 3-pane style.
> This should be the easier part and have no major impact of existing
> users.
>
> 2. Try to get RSS asynchronously.
> It will avoid the thread, but I am not sure it will work in the end.
> I need to play with that.
>
> 3. Use BookmarkKit for subscription.
> This should work, but will have a major modification which may
> affect current users.
>
> 4. Use BookmarkKit for articles (optional).
> Since it is only used in Grr internally, it is not that critical.
> So I will keep this option open until everything is done.
I would rather prefer to rewrite Grr from scratch again, since I'm
really having some trouble with the GUI and the controller and the model
part can be mostly used as it is. The big problem with the GUI is at the
moment that it used to be a one-Gorm-file-project which was then split
up into multiple Gorm files. Unluckily, on that transition, I lost some
connections between interface elements (like the "show only articles
from the selected feed" button). Also, I'm afraid that the division
into different Gorm files is not necessarily reflected in the code, so
that everything is still quite monolithic.
So, my personal aims for a rewrite are as follows:
- Making the code modular
There should be modules (best: bundles) that provide one NSView
each that can be put into one of the three panes in the three
pane view. The application should communicate with the bundles
through the bundle controller only. Bundles can also communicate
using the NotificationCenter. Every bundle has methods to get a
set of articles as input and can output articles using
notifications. The three loaded bundles are then put into a
"chain" where each one has a subset of its input as the output.
The first bundle has the whole set of articles as input.
As I'm currently working on the terminal, here's a rough sketch
in ASCII:
+----------------+-----------------------------------+
| | |
| Bundle 1 of 3 | Bundle 2 of 3 |
| | |
| input: all | input: output from Bundle 1 |
| available | output: subset of input |
| articles | |
| | |
| output: subset | |
| of input +-----------------------------------+
| | |
| | Bundle 3 |
| | input: output from Bundle 2 |
| | output: none, it just displays |
| | the first article in the input set |
+----------------+-----------------------------------+
The protocol for the bundle controllers would be something
like this:
// getting the NSView
-(NSView*) bundleView;
// handling input:
// set the reference to the "input" article set
-(void) setArticleSet: (NSSet*) article;
// is called when the content of the article set has changed
-(void) updateArticleSet: (id)sender;
// handling output is simply done by sending notifications.
// other bundles can connect to those notifications using their
// setArticleSet: and updateArticleSet: methods.
This would also have the major advantage, that those bundles can
be developed quite independently and they are also changeable.
The first implementations would of course be plain table bundles
that show feeds and articles for bundle 1 and 2 and a textview
bundle for bundle 3. But I want to make sure that it's possible
to embed a podcast media player in bundle 3 and a world map
which shows where what happened in bundle 2. (Like that:
http://freshmeat.net/projects/rssplanet/ ) :-) I know that I
like to play around with things like that, but it's better to
use plugins for that so you can build upon a solid basis. :-)
- Implementing MVC the right way
The model sends notification if it changes. These notifications
are sent to the controller which then invokes the appropriate
reloading and redrawing methods on the GUI. In the current code,
this is solved in a completely unstructured way. (I'm learning.
:-))
Okay, this is actually not the plain original MVC, but it is
what Apple recommends for using MVC in Cocoa, too.
I have no special opinion about that multithreading issue, but I'll be
glad to use it if you find a better solution than the current one. :-)
Using BookmarkKit for subscription is okay with me, and now that I read
a bit more about BookmarkKit, I'm quite comfortable with the thought.
:-) Yet I think that using it for the articles is overkill, since it
would only make things more complicated internally and retrieving
fetched articles using plain RSSKit is already easy enough now that it
has the property list based storage. (It's just an instantiation with
a specific URL. It automatically deserializes itself from the hard disk
then.)
Is that architecture acceptable for you? It still needs to be refined on
some points (like adding menu entrys and toolbar buttons from the
plugins like in GNUmail), but I hope the rough idea is clear. I'm happy
I finally wrote that down now, since I'm thinking about this for quite a
long time now. :-)
-Guenther
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
