I have been working on and off on this graphical editor, and i seem to come across a recurring problem that my initial ideas for the program design weren’t sound, and i have to go back one or two things. This affects the rest of the system and forces me to modify a lot other functions. One example is inside (define (open-file … ) where i now use search-list instead of struct-list (this is a quick hack to get the program working, which i will go back and change eventually) because i realized i need to scale the values.
Another thing is how to break up my code. I have read the style documentation here <http://docs.racket-lang.org/style/Units_of_Code.html> and forgive me but i am new to software development, and i still don’t know what constitutes good modularity in a program. I do have defined sections in this one big script though, namely txt parsing, auxilliary functions, geometric functions, intersection query functions, but i am afraid they are blurring the lines and it is getting harder for me to tell which functions go where. Finally, i wish to say thanks for making Racket such an enjoyable programming environment. DrRacket made it very easy for me to started and the ease of creating a GUI environment quickly was what drew me to start my project here. P.S. no global variables in caps now :) http://pasterack.org/pastes/70507 <http://pasterack.org/pastes/70507> > On 22 Dec 2014, at 6:42 pm, Neil Van Dyke <n...@neilvandyke.org> wrote: > > I think you have some of the right ideas. > > Two additional ideas to consider... > > * Usually you will have some data representation of objects that will be > drawn and manipulated. This might be as simple as a list of structs or > Racket objects, and (in an OOPL way). If you're making a simple graphical > editor, these might have objects like `editor-circle`, which knows its > position, size, and color, as well as has methods like "draw this object on > given graphic context" and "does this object intersect with given selection > rectangle?". The coordinates for these objects will probably be in a "world" > coordinate system, which stays the same regardless of whatever scaling, > scrolling, rotating, etc. is going on in your editor. One of the many > implications of the methods, to answer one of your questions, is that, when > you are dragging out your selection rectangle, you can just traverse this > list, asking each object whether it intersects with the rectangle. (If your > editor gets more sophisticated, or has to deal with , or you can get fancier > with your data structures, which would include making the selection more > efficient than O(n).) > > * When you are looking at doing drawing that is expensive, such as > highlighting objects as you drag the selection rectangle over them, consider > how using off-screen buffers can make that computationally easier. You might > have heard of "double-buffering" as a technique for avoiding flicker in > animations, but you can use similar techniques for things like capturing a > baseline drawing state and then doing fast incremental changes atop that > (say, for highlighting objects during a select rectangle drag, or for > dragging selected objects). > > Also, I beg people not to use all-caps for constants. All-caps are too > useful for syntax transformer variables (which is also a use more consistent > with the original reason that people started using all-caps for constants, > which wasn't because they were constants but because they were involved in... > syntax transformation). And, anyway, more descriptive than `WIDTH` is > `editor-frame-width`. > > Neil V. >
____________________ Racket Users list: http://lists.racket-lang.org/users
