On 10/23/06, Guenther Noack <[EMAIL PROTECTED]> wrote:
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. :-)
I create a branch under /etoile/branches/yjchen over this weekend. The loading in background is added in RSSKit. The user interface is rewritten into 3-pane style. The MVC model is FeedList, MainWindow, and Controller. Controller merges AppController and MainController. MainWindow merges FeedManagement and MainTable. FeedList merges from FeedTableDelegate and MainTableDelegate. Maybe you can take a look and see. I haven't recover all the funcions yet, but it works basically. The change of RSSKit is minor, and I think it is fine to merge back to the trunk. Although Grr has a lot of reorganization, it is not very different from your original design. I just centralized some classes which were scattering around. I haven't use BookmarkKit yet. It still uses the same storage as original one. I try to use as many as original gorm files, but the main user interface is written in code. Let me know what you think about it. I can polish it more the next few days. And I prefer to merge it back before I start to adapt BookmarkKit. The modular system is kind-of over kill to me, at least for present. Maybe we can think about it for the next major version after this. The way I am thinking is that you need a modular system only when you want to reuse ths code. Currently I haven't thought about any other application to use the same architecture. As for the notification, I personally perfer to use it as less as possible because it is harder to debug. When a notification is posted, it is not obvious which objects will recevie the notification. Therefore, when I found a bug related to a notification, it is harder to find the source and destination. I use it only when I need to notify several objects at the same time, or when some actions has unknown returned time, such as loading in background. If the chain of reactions is straight and the targets are known, I prefer not to use notification. Have fun. Yen-Ju
-Guenther
_______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
