1. 25 Mar, 2005 1 commit
    • Leigh B. Stoller's avatar
      Okay, I think I am finally done with WikiWhacking (or WhackingTheWiki?) · 90dcbbe2
      Leigh B. Stoller authored
      for the near future. Two big changes:
      
      * Add WikiOnly accounts. An external user can register for an account on
        the wiki. Rather then use the registration stuff that comes with TWiki,
        redirect to new Emulab web page so we can manage all of the wiki accounts
        from one place. I modified the joinproject page to spit out a subset of
        the required fields so that its simple to get a wiki only account (just a
        few things to fill in).
      
        In keeping with current security practices, we still generate a
        verification email message to ensure the email address works. However,
        when the user completes the verification, the wiki account is created right
        away, rather then waiting for someone to approve it (since that would
        defeat the entire point of the wiki).
      
        Aside: I have not thought much about the conversion from a wiki-only
        account to a real account. That is going to happen, and it would be nice
        if that step did not require one of use to go in and hack the DB. Will
        cross that moat later.
      
        Aside: Rather beat up on the modify user info page too much, I continue
        to spit out the same form, but mark most of the fields as not required,
        and allow wiki-only people to not specify them.
      
      * Both the joinproject and newproject pages sport a new WikiName field so
        that users can select their own WikiName. I added some JavaScript to
        both pages that generate a suitable wikiname from the FullName field, so
        that as soon as the user clicks out of the FullName, a default wikiname is
        inserted in the field.
      
        Both pages verify the wikinames by checking to make sure it is not
        already in use, and that it meets the WikiRules for WikiTopic names.
        (someone please shoot me if I continue to use WikiNotation).
      90dcbbe2
  2. 23 Mar, 2005 1 commit
  3. 22 Mar, 2005 1 commit
  4. 21 Mar, 2005 3 commits
  5. 14 Mar, 2005 1 commit
  6. 11 Mar, 2005 1 commit
  7. 09 Mar, 2005 2 commits
  8. 08 Mar, 2005 1 commit
  9. 07 Mar, 2005 1 commit
    • Leigh B. Stoller's avatar
      Change to the UI. Add a right click context menu (right click over a · b369447e
      Leigh B. Stoller authored
      node) brings up a context menu that allows you to 1) Cancel the
      current drag operation for that robot, 2) bring up the Emulab shownode
      page in another window, and 3) set the orientation for the robot using
      a popup dialog input box. This allowed me to clean up some of the
      table handling code, and fix a glitch whereby a value left inside a
      cell being edited caused the a cancel drag operation to immediately
      start a new one.
      b369447e
  10. 04 Mar, 2005 5 commits
    • Leigh B. Stoller's avatar
      This started out as a cleanup pass ... · 4e1cc382
      Leigh B. Stoller authored
      * Add nodeinfo backend page for the tracker applet to query for info about
        the nodes, including what type, what size, fixed/mobile, allocated etc.
        This is so we can draw the dots in the right scale, and make sure that
        fixed motes cannot be dragged around in the applet.
      
      * Clean up a bunch of hardwired constants, mostly related to the size
        of the dots, and the font size (which determines where labels get
        drawn.
      
      * And then I noticed the oddity resulting from having a robot that is 10.5
        inches long, but sweeps a diameter of 14 inches. The dot we draw is in
        scale (10.5in), but when I changed it to draw a 14in scale dot, that
        looked all wrong. So, there are actually two sizes now; the size of
        the robot, and the radius of the circle it sweeps (which is critical
        for determining obstacle avoidance). Still, this is confusing cause the
        user will place a robot near an obstacle (not overlapping) but will be
        told there is overlap cause the bubble around the robot is bigger then
        the dot. Not sure what to do about that. I could draw a large bubble
        around the robots but that is going to increase the clutter quite a bit.
      4e1cc382
    • Russ Fish's avatar
    • Leigh B. Stoller's avatar
      Add checks to make sure that a robot destination does not overlap a · 84c4f96b
      Leigh B. Stoller authored
      current robot location (or its destination if the other robot is
      moving or being dragged to a new location).
      
      Oh, I should mention that to make the calculation easier, I am
      treating robots as rectangles not circles. This is not ideal, but I
      was not sure how to calculate overlap of two circles in a reasonably
      efficient manner. I'm sure a high school student can tell me though.
      84c4f96b
    • Timothy Stack's avatar
    • Leigh B. Stoller's avatar
      As per Tim's comments, just the center point of a robot needs to be · be6ded17
      Leigh B. Stoller authored
      fully contained within at least one camera (not the entire robot).
      be6ded17
  11. 03 Mar, 2005 4 commits
  12. 02 Mar, 2005 4 commits
  13. 01 Mar, 2005 3 commits
  14. 24 Feb, 2005 1 commit
  15. 23 Feb, 2005 1 commit
  16. 22 Feb, 2005 5 commits
  17. 20 Feb, 2005 1 commit
  18. 18 Feb, 2005 4 commits