[racket] newb: implementation of select items

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 <neil at 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20150125/2b581745/attachment-0001.html>