This is 2_FuturePlans.rtf in view mode; [Download] [Up]
Release 0.31, 7.1.1995 by Thomas Engel (tomi@shinto.nbg.sub.org) 2 Future Plans I will try to give you a impression on how I am planning to continue this project. This files servers as my privat notebook for every idea that arises Most entries are ordered by their level of importance. A long Way to go There are many possible concepts. Here is the more high level view of the future. Almost everything is subject to changes. Concepts Some simple features have been added that make the app more useful compared to v 0.2. Graphics representations are very flexible now. · Bundles BeakerBoy will be using bundles for almost everything that is not system crucial. Filefilters, tools, selection-tools, region class/shapes etc. If you know NeXTIME you might know what system I am thinking about. · Selection mechanism. There should be many ways of creating a new selection and grouping the selection into a certain region type. We could provide some kind of spezial selection bundles. Or they might just be simple tools. See below for more. · Libraries. All the basic fragments and example molecules should be available through a hypertext link browser. Might be compared to the Helppages of a NeXTSTEP system. · Preferences. Extending the current design to allow user drag & drop into the prefs. This will allow the user to establish his privat set of defaults. Maybe I'll wait for the MiscKit prefs system. · Drag & Drop. I should extend drag & drop. With Scott Roy's IconKit that I am using now it should be quite easy. · DO Ports There should be more DO ports inside the app. There might be one for the file manager so it could convert files for other apps. I will have to write some more objects for that so maybe there will be a system of concurrently running object (if NeXT doesn't provide something on their own by the time I get there) with locks etc. pp. · NeXTSTEP'ing. ObjectLinks, services etc. There are many NeXTSTEP features that have to be added into the project. But I still have to find out what, where, when. · Polishing the interface. Including some WavesWorld objects (nice sliders) or some from the MiscKit. Well lets wait and see. · SCI-Tooling The SCI-Tools project is just starting to evolve so its too early to tell how this app will fit into it. For more details subscribe to the mailing list sci-tools@embl-heidelberg.de. Send a mail to: tuparev@EMBL-heidelberg.de · Scripting. Scripting with COWS might become interesting someday. Regions and Shapes BeakerBoys region and shape concept is very flexible and might become more flexible in the next versions. There are many possible shapes that will/could be implemented. They all should get loaded as bundles from the Library/BeakerBoy sections. · BiologicalShapes. Those shapes are already included inside the region inspectors shape overview. But they do not work right now. The following types are considered: helix, sheet, rope, ribbon, arrow, and some extra shapes. · CrystallicShapes. What ever we might have here. · EnergyShapes. This could be a pack of shapes that will render images that show the different energy or load levels using a color maps. We might use shaders for that too. As you see in the current release every region has its shape. Switching between those shapes should be fairly simple. For more details see the implementation section. For marking there could be different mark shapes that might either be rendered inside the 3Dview or drawn as Postscript over some given shape. · ArrowShape. This RenderMan shape might point to a given spot inside the 3D space. It might be used to display certain relations · 2DArrows. Might be used to trace certain selections. Imagine a circle with a number inside and an arrow headed line pointing to a certain place. · 2DAngles. Could display the angle of a certain selection. Postscript painted over the rendered scene. · 2DTitle. Simple Postscript text that is attached to a certain shape or object. How markers will work. Hmm, well I don't know exactly right now. But somehow using drag&drop and some kind of references. It should be quite straight forward. Views and Cameras Right now I am only working with one camera. The way will lead to an approach that does give you the chance to choose between different camera types. But this might take some time. Anyway. Clipping will be added for sure. But the way it will be added is still not fixed. Maybe as a general tool that adds a rootlevel shape with a certain 'cuting' effect. More Tools Some of the apps internal tools can be found inside the current release. But they are only interface prototypes. I still have not decided how to add those tools. Either as BeakerBoy internal or a real ToolBoy tools...maybe even in a SCITools fashion. The following might be part of the main interface: · Selection tools. The selection tools could create active qualifier objects. · Simple build tools. Some other tools will be available via the ToolBoy interface. They will open their windows when double clicked from the ToolBoy window. I might consider giving them a place inside the main menu where they might add their entries. Candidates for this kind of access are the following ± mostly highly complex ± tools. Those tools should serve a DO port so that they can be used from the different region classes (and their shapes too). It might really speed energy optimization if it could run on a big fat server instead on a little PC. · Complex build tools. Maybe used for automatic structure optimization. · Energy optimization. · Structure fitting. · Protein building and analysis. New Projects In addition to the BeakerBoy app I am thinking about writing the StructureBoy. This should be a 2D drawing app that might easiliy cooperate with the BeakerBoy. Smarter DO connections and a DO-save IconKit might help very much. Hard coding Here we have reached the point were I will note all the coding details that have fallen from the sky. The points here are either related very close to the current implementation or quite simple to be implemented in the next version. I have tried to sort them a little. The App Here is what I can't arrange anywhere else or what will affect the app in general. · Bundle loading. Load bundles form the default directories and give them the chance to register for whatever they like. The app will have to maintain a list of all the different bundle types (shape classes, tools, etc.) NEXTIME has a nice architecture...I really enjoy that one. · Connections and relations. I should check all the connections and reations. Who knows who ? Who sets what ? But lets wait until the design comes to a rest. Moving to OPENSTEP should be the right time. We might use something like Scotts addUser, removeUser mechanism. · More checks. Setting a delegate, add some object to a list or what ever. In the dangerous places I should add conformsTo: or respondsTo: checks before accepting an object. · Strings. Strings are a big task too. I will have to rewrite all those 'hacked' sections that use statically included string section to use real strings to allow localization of the app.. · MiscString_ExtendedParsing. Switch to the subStringLeft: and Right: methods. Will make the category much simpler. · Memory. There might be some memory leaks. I also have to try to find good ways of zoneAllocÂating . · Protocols. There should be protocols for all the major object types: regions, shapes, molecules, fileFilters, etc. · Saving and archiving. Dumping scenes as RIBs and archiving the objects is high on the list. The Beaker and Data This includes stuff that takes care of the molecule data. · Grouping regions, molecules and opening them. I will create new objects that are BBSuitcases that know how to open all their subregions or sub-molecules. · Shelf clicking. As soon as Scott adds object based path info to his IconKit I will add shelf click with browser selection. Same as in Workspace. · Multiselection. There is a problem with multiple selections. Once there is a way to select objects inside a camera view we will face the problem that in many situations there is no relating selection inside the browser (atoms+bonds..= two different trees!) So I might not be able to keep selections in sync between the views and the browser. Sometimes this is not even desirable. The Shapes Most of these points are tightly coupled to all my graphics code. · Finding a group. How do I tell the app that I want to select a group ? · Auto-update. Some preference switches telling us to auto-update a certain views shapes etc. · Creating drawing styles. The region inspector creates new render styles if needed. But they never get freed !! Big bug! A drag&drop interface should be used here. · Visible regions. If a molecule has more than one default region we should disable setting the molecule style !! Instead we might show a list of all the visible regions (moving this from "Misc" over to that place) · Rotating shaded boxes. Maybe it could help to use different color levels for the upper side of a bounding box. Or I could have some edges in different colors. This would allow a simpler recognition of the molecules orientation. · Rotating multiple views. There should be a way to rotate multiple molecules or views at once! Maybe some advanced drag & drop setting inside the Rotator or a switch inside the inspector ? · Region color level. There will be a region wide color level or intensity level. Using it may help us exposing one region from the others without having to change the colors of the atoms or bonds. They will just appear covered by a certain color. (Internal color-composing with another overlay color, before we find the renderman color. Or using a special shader for that region. Would be better!...but with the current QRM it's impossible) · Solid SpaceFill. The SpaceFill shape could use some kind of RtJoin or RtBuild(solid) or what ever I might find there to build a solid shape. Or just make it configurable. This might lead to prettier rendering...especially with surface-shaders. · Switching between styles. Whenever I decide to switch between the classes I will get the region class our shape requires. This might be useful because the region can provide methods that simplify the creation of a shape (like return a list of special atoms, performing calculations and storing them in a regions internal property.) Internal region properties have to appear inside the browser and will be passed form one region class to another when changing is desired. We could have naming conflicts here but this is another issue. Anyway. Storing the data as a property allows having precalulated data that won't get lost when you want to temporary use another region shape (and region class). Attention: We have to be sure that every region that is still alive is pleased with the new region class!. This could be done by some kind of 'IKuser' notification. Possible Bugs Most of those 'bugs' are not really approved. They are listed here so I won't forget to check them out. · Drag & Drop. Not tested very much. There might be many bugs right now. · Inspector, nil. What does [Inspector inspect:nil] do ?? It should show not crash the app. · Wrong Menu items. Some of the Menu commands don't work properly. But I have only included this point to not to forget about this nice text style (Command-Description). I might need it later and don't want to search for it again in NeXTs docus :-) Command Description Group... Does not know how to group different objects right now. The main 'grouper' is the BrowserManager and. Save Does nothing at all.
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Netfuture.ch.