Dream 52

home *** CD-ROM | disk | FTP | other *** search

/ Dream 52 / Amiga_Dream_52.iso / Linux / Divers / freedraft.tar.gz / freedraft.tar / FREEdraft-050298 / journal < prev next >

Wrap

Text File | 1998-05-02 | 27KB | 824 lines

//+++++++++++++++++++++++++++++++++++ // copyright 1997,1998 Cliff Johnson // iamcliff@ix.netcom.com // all rights reserved //+++++++++++++++++++++++++++++++++++ // // THIS FILE IS >>> NOT <<< UNDER THE GNU GENERAL PUBLIC LICENSE. // YOU MAY NOT REPRODUCE THIS FILE, IN WHOLE OR IN PART, IN ANY FORM, // EXCEPT AS NOTED BELOW WITHOUT THE PERMISSION OF THE AUTHOR. // // THIS FILE CAN BE REPRODUCED VERBATIM, COMPLETE AND UNALTERED, AS PART OF A // COMPLETE FREEdraft SOURCE DISTRIBUTION. // // YOU ARE FREE TO REDISTRIBUTE THE FREEdraft SOURCE WITHOUT INCLUDING THIS FILE. // // //+++++++++++++++++++++++++++++++ Changes and random thoughts ( and not so random ones I hope ) are cataloged here. ****************************** Sat May 2 11:56:34 EDT 1998 ****************************** release 0.3.3 050298 New module "MEASUREMENT" which for now includes these functions: WHAT IS? - which displays basic geometric information about a selected entity DISTANCE - to measure distances between 2 points, between 2 parallel lines/segments or from a point to a line, segment, circle, or arc support. ANGLE - to measure the angle between 2 lines/segments Added to the GEOMETRY module: Create:support - to create the underlying sketch geometry (line or circle) from a segment or arc. Lines: orthoginal - to produce a line, perpendicular to a line, segment, circle, or arc, tangent to a point, circle, or arc. ****************************** Mon Apr 27 23:03:58 EDT 1998 ****************************** Another exciting release: freedraft_042798 ( 0.3.2 ) In this episode, the function for a circle by radius and 2 constraints is (seems to be) working. This includes the circle tangent to 2 other circles, which is totally wacked out in implementation, but actually works! (much to my suprise - actually, not, but it is such a complicated thing, finding all the possible solutions and then choosing the correct one. Now I think I know how to implement the general 3 constraint circle... coming soon) ****************************** Fri Apr 24 00:06:08 EDT 1998 ****************************** Dr. Wampler's stuff is in now and working! instead of providing my own V functions, I created a patch to be applied to the V sources v 1.18. I am going to release another snapshot now: freedraft_042498.tar.gz (Release 0.3.1) ****************************** Thu Apr 23 19:40:03 EDT 1998 ****************************** Crude input boxes now working for point real number input. Dr. Bruce gave me some stuff so that the return key can close the dialog, but I have not put it in yet, so for the moment the user must press the OK button. Yech! I hate that. Function Circle by radius and center now implemented Point by keyboard modifier implemented with KB button or just hitting the space bar when point is an candidate input. Did some optimization to circles so that the number of points used to draw it changes with the size on the screen. Rearranged the selection buttons and such, included a few icon buttons. looks a little sharper. What I really want to do is institute a Regeneration function in the viewer. This function would turn all the objects which are not on the screen, or which are very small, invisible. This is not practicle at drawing time. It would might be most speed efficient to put the circle and arc optimizing code here as well. Perhaps 2 functions, Regenerate, to invisibleize things off the screen, and Redisplay to optimize circles, arcs, and whatever else. To be really optimal, maybe restructure the canvasRegister, to have separate lists for what is drawable, and what is registered. This way, the canvas does not even have to ask for each entity- are you displayed? ****************************** Mon Apr 20 19:34:59 EDT 1998 ****************************** Basic save and recall are now working... So I am announcing release 0.3 !!! yee haa! ****************************** Sat Apr 18 10:17:25 EDT 1998 ****************************** --->Moved the instansiation of the drawables into an independant class, where all the drawable pointers are accessable via an enum value like FD_DRAWABLE_POINT, etc. Now I can easily save the drawable with the entity when writing a model to disk. ---> Added Layer to the Attribute class. In the future I will want to have a layer attribute, and I will need it to be in the file format now. ---> Changed directory name ENTITIES to GEOMLIB2D ---> Moved pick and pickgeom from CORE to GEOMLIB2D ---> Changed the Makefiles so that the contents of GEOMLIB2D get made as a shared library. ***This breaks building on other platforms besides linux-elf. **** ---> Added GPL header to all the makefiles. *** minor bugs : If a modifier is activated, and the function is aborted, reinitialized, or another function is chosen before the modifier is completed, the button does not reset to the unselected state. ** SUM should be off by default. ---> Changed Circle-Center back to initializing each time. ****************************** Fri Apr 17 20:30:20 EDT 1998 ****************************** Before starting on save/recall (again) I redid the exception classes to all inherit from a base class. Maybe I should use the standard exceptions instead? ****************************** Thu Apr 16 23:00:19 EDT 1998 ****************************** How to save/recall? These are my initial thoughts: Me thinks save/recall should be based on the contents of the CanvasRegister, yet not built into it. There is some argument for basing saving on the GeomBank contents, but it would be more difficult to manage saving the graphical attributes. Besides, as things stand now, there is nothing in the bank that is not in the register. Possibly this will change in the future. saving: The iterator behavior of the canvas register can be used to iterate through the contained entities (like the drawing routine doesAAA) , for each entity, its type, data, and attributes are written serially to the file. Sounds simple enough. possible problems: Drawable support: Currently, the drawables are instansiated as static members of the menuhandler children - how do should I save which drawables are used for which type? This is not much of a problem now, as each type of entity has but one drawable that it uses. What happens if I want to have different drawables for the same type of entity? Answer: A drawable table - or enums which match the drawables - and move the drawables into the viewer OR somplace where all the drawables can be made at the same time (program start) and assigned indecies which save/recall can use. Should have done that a long time ago anyway. problem: Adding new entity types. ***************************** Sun Apr 12 15:21:46 EDT 1998 ***************************** New features are linestyle and linethickness editing. I have been thinking that the menuhandler class could be redesigned into a more modular machine which can load individual functions - based on a common function class. The menuhandler stuff is very big. geommenuhandler.cpp is more than 2000 lines! yikes. all thoses try- catch try catch stuff takes a lot of space up. ***************************** Wed Apr 1 00:17:59 EST 1998 ***************************** Have added color editing ( which is only slightly broken ), as well as segment and arc trimming/ relimiting and cutting. ***************************** Tue Mar 24 23:23:24 EST 1998 ***************************** Tracing is pretty stable now, with only one minor bug that I see when terminating a line drive entity with a point check entity. Highlighting of selected entities is now implemented and controlable through the MenuHandler. Its really neat. Visibility has been implemented as far as the CanvasRegister goes, but nothing is in the UI yet. I want to now do just a couple more things before releasing 0.3: Color and linestyle control for constructing and editing geometry. Saving and recalling of points lines circles and arcs. ***************************** Mon Mar 23 00:55:02 EST 1998 ***************************** Got the trace function to work pretty swell. You can now create a contour make of a chain of arcs, lines, and points. Nifty. ***************************** Sat Mar 21 14:06:35 EST 1998 ***************************** V released v1.18. Included is support for lesstif. - I tried it but there are problems with mesa and lesstif OR mesa and V1.18 OR all three, so I could'nt get it to work. I considered for a moment changing to the native drawing methods of v, but that would totally mess up selections and be a big mess in general, so for now I am rejecting it. Mesa seems no longer to include the widgets... maybe I will include them here. **************************** Sun Mar 8 17:11:45 EST 1998 **************************** Changed the release to a date based system - like da gimp et all... Got most of my exception handling problems worked out. Got almost all of the c-style error handling replaced already. Fixed a bug in delete, but the type masks are not set correctly. In fact they are not set correcly most everyplace. To do this I changed the deletion function to use a pick, just like all the other function handlers. This simplifies things in some respects in that I do not need to keep the Selection object around just for deletion. To do this I added a method to the GeomBank to return a handle, given an address - ( or throw an exception) The grammer modifiers seem to be working well. There is a bug in Points->Create. Button 1 will not create a point. MenuHandler::Get1Pick is throwing an exception because the pick is local with button 1. I Think that the GetXPick functions need to be seriously updated already. They are totally a total cludge. Possibilities: GetNPicks(int n) throw (ComException) This would be a more general solution along the current lines. But it does'nt address a problem with the current approach: The picks are only checked when they are needed by the solving function. It would be better if a function would set up - somehow - an array of expected pick types and rules - which could be handled as each pick is made. Of course this would be much more compilcated... **************************** Tue Mar 3 20:01:33 EST 1998 - release level 0.2i **************************** I am taking a shot at using egcs with the idea to use exception handling and rtti features instead of my nasty messy error handling facilities and geometry type data memebers. So far the exception handling is blowing up in my face. I am rebuilding the compiler with a binutils patch that reportedly fixes exception handling woes. It could just be that I don't know shit about using exception handling and have just totally messed up. :) AH, well, time to learn something gnu. egcs exception handling report = Oh my! it's still not working. **************************** Sat Dec 20 16:00:32 EST 1997 - release level 0.2f **************************** upgraded GeomLib2d with a bunch more combinations of entity types. In particular: PointConstraints2D now handles works for picks which are any combination of Points, Lines, Circles, Segments, and Arcs. **************************** Tue Dec 16 19:19:17 EST 1997 **************************** Implimented a dialog for options when creating closed arcs Changed the behavior of the circle center + 1 function release level is now 0.2e **************************** Sun Dec 14 02:31:40 EST 1997 **************************** Segment and Arc entities are up an running. Added basic support for linestyles Countour tracing function is still experimental - work with persistent points only. Closed arcs sans options is working. Arc through 3 point is working but seems buggy. Posted announcement to comp.os.linux.announce Started putting new stuff at the top of this file. ********************************************************************************************** ********************************************************************************************** ********************************************************************************************** ********************************************************************************************** ********************************************************************************************** ********************************************************************************************** ********************************************************************************************** 1/25/97 FREE Engineer journal started :: I now have a working 2D viewer, system to create and manage geometric objects, a system with which I can register objects with the viewer. :: I have created nearly 500 points without problem, except the pickstack overflowing, which should be fixible just by defining a bigger stack in vdcmdwin.h -->changed vdglcanvas::BUFFSIZE to 4096, enough for selection of 1000 entities :: Implemented a rounding method for the Point class: { Point Point::Round() } :: Applied the point rounding to the creation of freely picked points. :: Separated Attributes into 2 classes Attributes and Visibility. The idea is that the Visibility associated with a Handle is used to tell if the Handle referent *should* be drawn, while the Attributes describes *how* to draw it. - added class Visibility - added a Visibility member to class RegisteredEntity - moved the isVisible and layerValue members from Attributes to Visibility ::::THink about - drawable class to make representation distinct from geometry type. ::::Interprocess communication - long term architechure. :: Modified Attributes class by adding thickness member, which represents both point size and line thickness for a given entity. :: Modifications to VDGLCanvas::SetAttributes to handle new Attributes object 1/26/97 :: Created a SelectionFilter class - to filter selection be entity type :: Added method TypeMaskBehavior::GetFilter(), returning a SelectionFilter object from the current settings of buttons :: Added method SelectStack::Filter(const SelectionFilter& s) returning a new filtered selectstack ---> The selection filter is intended to be used by functions so they only have to see the entity type they are looking for. :: Have implemented selection methods on the SelectStack class : Top(), Pop(), and TopOfType(int) these should facilitate in selecting the newest entity of a given type. ( since the handles will be in order of creation... for now anyway). :: The immediate mode horizontal and vertical line creation (via button 2) is working. --> there is a problem causing a segfault on resize. Sun Feb 9 1997: Have been resarching yacc and lex (or flex and bison) for the last week or so. Hopfully I will be able to use them to write a parametric language interpreter. Also have started to study unix IPC. As for FREEdraft, I have started the GeomLib2D class that will supply 2D geometry solutions to the basic constructions. Basically all the processing which is not the provence of any particular geometry or data type is handled by this class See GEOMETRY/geomlib2d.h for the details. As of right now, The function SolveLineLineIntersection is working. (testlib.cpp) I am starting to work on modifing the SelectStack class to add a selection filter methods returning objects of type Selection ( a container for the handle and pick coordinates), based on various criteria. distance to start. In fact, I think I'll modify the SelectionFilter class, so criteria are specified by it. if I do that, I can just modify the SelectStack::Filter() method, and not have to add a new one. :: SelectionFilter has been modified adding two private data members int depth, and int criteria. It is not up to SelectStack::Filter to process the new filter object correctly. Am installing enums for different criteria values: NONE, CLOSEST, FURTHEST(?) ... Well, for now at least NONE and CLOSEST Mon Morning 1:10 AM Ive got filtering of the selection by closest type working now by modifications to SelectStack, SelectionFilter, Selection, vdCmdWindow has been changed in the menu handling innerds to use the new SelectionFilter, and take a Selection object off the top of SelectStack passed from VDGLCanvas. Now to get the multi pick actions implemented - i.e line by two constraints and point by intersection of two lines. Perhaps a stack of selections which could be pushed and popped until the necessary amounts are ready.... Mon Feb 10 1997: General case; Action: Line by Two constraints parms = 2; Selection Returned push(selection) parms--; Selection Returned push(selection) parms--; parms == 0 : call function(pop(),pop()) case with modifiers: Action: Line by Two constraints parms = 2; Action: Modifier>Intersection parms += 2; mparms = 2; Selection Returned push(selection) mparms--; parms--; Selection Returned push(selection) mparms--; parms--; mparms == 0 : Selection = Intersection(pop(),pop()) parms--; Selection Returned push(selection) parms--; parms == 0 : call function(pop(),pop()) I will put this logic into a utility class SelectionManagment. :: Moved the Generic Handle vs. Point distance measurment out of SelectStack and made it a public utility function. :: fixed a bug in vdCmdWindow that was seg-faulting when zero handles received in a SelectStack :: re-architechure of the command calling mechinism: currently-... all the entitiy creation functions , ie calls to GeomBank::Create(...) were nastily processed directly by vdCmdWindow. This is not good, for several reasons... So anyway, I have designed class SelectionHandler, designed to be a member of the vdcmdwindow, a parser class of sorts, to handle the recipt of Selection objects of modifiers, and the calling of GeomBank::Create(). This has a couple of advantages: - modularizes the code - abstracts the menu behavior from the menu itself, so multiple selection management derived classes can be used for different menus. in fact this is the mechinism for encapsulating entire menu behaviors ++++++++++++++++++++++++++++ Tue Feb 11 19:41:51 EST 1997 ++++++++++++++++++++++++++++ The SelectionHandler class is written and a derived class MySelectionHandler as well to support the current menu. Major changes are now needed in vdCmdWindow to use the new handler. Larges tracks of code will have to be ripped out to be replaced by tidy little efficient functions. What Fun! extensive modifications to <myselectionhandler> extensive modifications to <selectionhandler> extensive modifications to <vdcmdwin> need to implement library function LineParallel2D(Line,Selection) +++++++++++++++++++++++++++ Sun Feb 16 23:13:24 EST 1997 +++++++++++++++++++++++++++ ANNOUNCMENT: VERSION 0.2 Begins now. - my first slanted line!!!! implemented all of the Line and Point functions in the library. They seem to work although there are bugs. The resulting structure of myselectionhandler, where much more sophisticated than I first envisioned. myselectionhandler inherets its functionality and data protected from selectionhandler selectionhandler is aware of the vdCmdWindow (via a pointer) and a friend of vdCmdWindow as well. SelectionHandler encapsulates a limited set of methods from other children of the command window : Create(), Register(), Redraw(), and SetTypeMask() being the most important. These functions are used by the inherited MySelectionHandler class, responding to menu calls and what not. The SelectionHandler also swallowed vdCmdWindow::FunctionMenuCommand() (which no longer exists) All its functionallity has been transfered out of the command window. This theoretically makes the menus changable, simply by loading another version MySelectionHandler, into the commmand window. The question is now, can I change the labels on the buttons? Now: I want to review the code looking to minimize dependancies. Or at least identify them all. Then I need to implement the circle functions. +++++++++++++++++++++++++++ Thu Feb 20 22:59:04 EST 1997 +++++++++++++++++++++++++++ Went to the linux losers group. extrodinarily pathetic waste of 2 hours. The manual says that you can change the labels on buttons. This is much more better than Icons for now. Now I have to build this final changable menu mechinism into the system. I also have to get working and test the modifier buttons. at least 'intersection of' . Maybe I should call them 'adjective' buttons??? create line from circle(...) near point() to intersection of line1 and line2 create line from circle(...) near point(...) to circle2(...) near point(...) IDEA: DYNAMIC PROMPTING update the text information line each pick prompting for the next expected... for example: pick> 'Line2Consts' prompt: create line from pick> a circle on the screen ... prompt: create line from circle(...) near point(...) to pick> 'intersection of' adjective prompt: create line from circle(...) near point(...) to intersection of pick> first line prompt: create line from circle(...) near point(...) to intersection of line(...) and pick> a circle prompt: create line from circle(...) near point(...) to intersection of line(...) and circle(...)\ near point(...) +++++++++++++++++++++++++++++++++++++ Sun Mar 2 10:07:48 EST 1997 +++++++++++++++++++++++++++++++++++++ Back from the sales meeting. What fun. Now I have the Intersection modifier working correctly, having more properly subdivied the functions of the MenuHandler, and specialized MyMenuHandler classes. The MenuHandler class has been given responsibility for the modifiers, and all permanent menu stuff, while the MyMenuHandler (in this case) handles the specialized processing for the current menu. If I design this right, I should be able just to load a different MenuHandler inheriting class into the vCmdWindow, like "DimensioningMenuHandler", "MillingMenuHandler" or what not, and have the system work as necessary. Current activities: >I am now working on the Delete function. Besides the implementation in the MenuHandler family, this should involve: Modification of the canvas, attaching a second registry, for highlighted entities, such as entities selected for deletion and what not. void VDGLCanvas::HighlightRegister(RegisteredEntities* re) void VDGLCanvas::ClearHighlightRegister(); These entities will then be drawn after the primary registered entities. In this way displayed things can be redrawn with different attributes for highlighting. **************************** Tue Mar 4 19:09:32 EST 1997 **************************** Besides adding a highlight register, I have implemented, at least mostly, the separation between the viewer, and what is being drawn. To do this, the RegisteredEntity class was modifier by adding a data member of type DrawableGeom*, The DrawableGeom family of classes encapsulates the actual OpenGL commands necessary to render the registered entity. This has the effect of dramatically simplfing the DrawRegisteredENtities() and SelectRegisteredEntities() methods of VDGLCanvas. From about 30 lines of code down to 7 in DrawRegisteredEntities() Everytime I add a new feature, I am amazed that the whole thing still works! need to : get delete to work. Its just not finished. possibly get rid of selectRegisteredEntities. The algorithms are so close now. Implement a hightlight buffer of Geom*,DrawableGeom* pairs. Think about this approach to highlighting, is it better than using a second canvasRegister? The CanvasRegister class is fast evolving into an encapsulation of the MODEL of the MVC. By adding Names to the RegisteredEntity class, The MVC of FREEdraft: MODEL class CanvasRegister | ? int nextID; // static ( ? means static. by the way... ) | + class HandleTable // symbol table of handle, name, local id triples | v class RegisteredEntity class RegisteredEntity | | + class Handle | + class Attributes | + class Visibility | + class DrawableGeom* VIEW: V family CONTROLLER: menuhandler family Product plan Version 0.1 Basic menu layout, functioning bank Version 0.2 M: CanvasRegister evolves into the encapsulation of the MODEL. - geometric definitions - display attributes - drawing methods V: The 2D canvas is inpendant of geometry types and drawables. -Zoom,Pan,Center functions -Hot swappable Models, and Highlight lists -Reasonable size limit assumptions -Picking services C: The MenuHandler family, Solver classes - Basic delete handling - Point and Line and some circle functions. Version 0.3 M: Circles, Named geometry and parameters. basic save and recall. V: Color assignment, Group Selection C: circle library functions, menuhandler functions. Version 0.4 M: Segments, Arcs, Contours. Reliable save and recall V: Line Styles C: Version 0.5 M: IGES support: read and write - Segments, Arcs, Points. V: C: User Promting, Point Dialogs, Value Dialogs, (combo boxes...) Version 0.6 M: Recording of Session, dependancies - basic parametric mechanism. V: C: Version 0.7 M: Session playback V: C: Version 0.8 M: V: C: Version 0.9 M: V: C: ***************************** Fri Mar 21 16:47:47 EST 1997 ***************************** compilation timings with my *new* 200MHZ IBM/CYRIX processor and M TECHNOLOGY R436e motherboard -> finish at Fri Mar 21 17:19:41 EST 1997 -> start at Fri Mar 21 17:18:17 EST 1997 ----------- 1:24 !!!! WOW !!!! I am most impressed with the compilation speeds so far. The Kernel compiles in 6:10. **************************** Sun Mar 30 11:08:24 EST 1997 **************************** **************************** Sun Nov 30 23:10:32 EST 1997 **************************** Add loadable menu support - different MenuHandler related classes can be swapped in and out. Reorganized everything. New simpler makefiles. Dependancies are not checked as good though. **************************** Sun Nov 30 23:10:32 EST 1997 **************************** Wrote README file **************************** Fri Dec 5 21:23:05 EST 1997 **************************** The Circle and DrawableCircle classes are working. The CircleCenter function is about 70% implemented. I solved a problem with reusing free-picked points. **************************** Sun Dec 7 15:31:17 EST 1997 **************************** A day that will live in infamy. Circle center works in most cases now. Moved the inputString member from the viewer into the menuhandler parent class.