From: Kal A. <ka...@te...> - 2001-08-29 15:52:26
|
> > Hi, > > first of all I have to mention that it is not my favourite to > develop GUI programs :) But in lack of having one I decided > to build one. And I would like to participate in the GUI > development. > > > > That sounds good to me - I was going to suggest that seeing as > there seem to > > be a number of people interested in developing this application that it > > would be a good thing to: > > > > a) Split the work up > > yes, i think everyone agrees with you. Should we build a detailed > wishlist to start over? > I think that would be the best starting point. I would like to put some thought into this, but unfortunately I'm in the process of moving house this weekend so I'm not going to have much time until the middle of next week now. However, I would ask all others on this list to publish their wishlists and I'll ask the tm4j-users list for input too. > > b) Develop the editor as a "framework" into which new GUI tools or > > processing tools can be easily slotted. > > > > that sounds really nice. Building the GUI Widget upon the Objects they > are editing it should be easy to include them in a framework. We need > some structure of distributing single aspects of a map through such > a framework. I'm very interested in doing such but I don't know enough > about topic maps and GUIs (as I mentioned last time). > > > > In looking at (b) I think it would be very worthwhile spending some time > > working out an MVC-style architecture for the application. The > model part > > can probably be mostly provided by the existing > TopicMap/TopicMapProvider > > interfaces, however it may need some extension to support all of the > > features required of the editing application. The View and > Controller parts > > could draw on some of the "events" in the current version of > TMNav, though > > I'm not entirely happy with the structure of that application. > > > Could you explain how you think MVC takes place in the application. As > long as > we need widgets for topic map objects the widgets will rely heavily on > using the topic map API. Thus preventing to some extend the use of MVC. > That is true to some extent, mostly because GUI widgets such as Swing widgets really combine View and Controller within a single object. However, there are still some aspects of MVC which we should probably assess for their usefulness such as abstracting selection events so that notification of selection in one view can be propagated to all other views. I need to think a little more about this. But getting into this level of detail before we have the requirements wish-list is probably a bit premature... > > Norbert, would it be possible for you to describe the > architecture of your > > application a little. Existing applications such as yours and the TMNav > > application are good starting points for working out a feasible > architecture > > for this kind of thing. > > > I wouldn't call it application right now :) > I started to figure out what common functionality could form a > topic editing > panel. With comfortable editing in mind I built up three widgets to > contruct the panel for a topic. > > 1.) BaseName and Occurrence. Holding a list of objects. Creation is done > from String (textfield input). The creation of those objects is done > via a factory which is set up in the widget. > -> Constructor(Factory) > 2.) Occurrence type. Selection of a single Object from a predefined list. > 3.) BaseName scope, Occurrence Scope, Topic types. Selection of multiple > objects from a predefined list. > > 2.)+3.) > > The selection capabilities are those of a JList. Additional I work with an > extended ListModel which has search capabilities. This enables the user > to type in the item he is looking for and the widget autocompletes it. > > With the use of a Factory for 1.) and own ListModels and CellRenderers > for 2.) and 3.) the widgets themself are independent from the tm4j API. > > Out of these widgets the topic editing panel is constructed. > > Distribution of the topic map and duplicate Method are collected in a > own class which is itself a Singleton. I don't like the idea but I > didn't want to make things overcomplicated for me. I will change that > soon. > > Editing an object is really like Kals way in TMNav. There are some > methods to duplicate topic map objects which then are used in the > widget for editing. In my opinion this should be a generalized > functionality in or beside the API (util?). > Yes, I think that deep and shallow copy operations would be a really useful thing to have in a utils package...I shall add it to the TODO list! > > It is not much code right now (widgets: 1445 lines, editor 1094 lines). > I will do more work to have a quite working panel for creation/editing > of topics and associations. > In the meantime we could fix some requirements for the GUI. > > > And we need a name. Suggestions anyone ? :-) > > A really fascinating name would be: *tata* TMEdit *rotfl* > That was the only one I could come up with too :-)) Cheers, Kal |