Commits

Anonymous committed fae6568

Not calling Toplevel.quit() in a non-main thread

Comments (0)

Files changed (6)

 New Features
 ============
 
-* Handling imports when inlining
-* Handling recursive restructurings
-* Better diff highlighting
-
-Inline method refactoring can add imports when necessary.  For
-instance consider ``mod1.py`` is::
-
-  import sys
-
-
-  class C(object):
-      pass
-
-  def do_something():
-      print sys.version
-      return C()
-
-and ``mod2.py`` is::
-
-  import mod1
-
-
-  c = mod1.do_something()
-
-After inlining `do_something`, ``mod2.py`` would be::
-
-  import mod1
-  import sys
-
-
-  print sys.version
-  c = mod1.C()
-
-Also rope can inline class methods; for instance in::
-
-  class C(object):
-      @classmethod
-      def say_hello(cls, name):
-          return 'Saying hello to %s from %s' % (name, cls.__name__)
-  hello = C.say_hello('Rope')
-
-inlining `say_hello` will result in::
-
-  class C(object):
-      pass
-  hello = 'Saying hello to %s from %s' % ('Rope', C.__name__)
-
-
-Restructurings can handle recursive patterns like searching for
-``${?a} // ${?b}`` in ``1 // 2 // 3``.  Also the diffs in show history
-and preview changes dialog are highlighted.
+*
 
 
 Getting Started
 *Rope* tries to improve these limitations.
 
 The main goal of *rope* is to concentrate on the type inference and
-refactoring of python programs and not a state of art IDE (At least
+refactoring of python programs and not a state of art IDE (at least
 not in the first phase).  The type inference and refactoring parts
 will not be dependent on *rope* IDE and if successful, will be
 released as standalone programs and libraries so that other projects

docs/dev/issues.txt

 
 * Where should we put scope statements that are outside other
   sub-scopes?
-* How to specify the new order
+
+  * Keep them on their own place; Might cause problems
+  * Put them at the end of scope; What to do for imports
+  * Put them at the start of scope; Might cause problems
+  * Hang them to the upper scope; Problems like imports
+  * Hang them to the lower scope; Problems like __main__ checks
+
+* How to specify the new order?
 
 
 Enhancing Refactorings

docs/dev/workingon.txt

 Small Stories
 =============
 
-- Using tooltips in restructuring dialog
-
+* Updating and adding docs on SOI
 * Adding restructuring scope; local scope, module, all files?
 * Better search triggering in find type dialog
 * Some of the things in `codeanalyze.WordFinder` can be achieved using

docs/overview.txt

 rope.
 
 
-Renaming attributes
+Renaming Attributes
 -------------------
 
 Consider we have::
   eval('newfunc()')
 
 
+Rename When Unsure
+------------------
+
+This option tells rope to rename when it doesn't know whether it is an
+exact match or not.  For example after renaming `C.a_func` when the
+'rename when unsure' option is set in::
+
+  class C(object):
+
+      def a_func(self):
+          pass
+
+  def a_func(arg):
+      arg.a_func()
+
+  C().a_func()
+  
+we would have::
+
+  class C(object):
+
+      def new_func(self):
+          pass
+
+  def a_func(arg):
+      arg.new_func()
+
+  C().new_func()
+
+Note that the global `a_func` was not renamed because we are sure that
+it is not a match.  But when using this option there might be some
+unexpected renames.  So only use this option when the name is not
+another python defined elements.
+
 Move Method Refactoring
 -----------------------
 
 
       def __init__(self):
           self.a = A()
-          self.attr = 1
+          self.a.attr = 1
 
   b = B()
   print(b.a.attr)
 
 Change occurrences refactoring is a special refactoring.  It replaces
 occurrences of something with what you want.  This refactoring is
-different from rename refactoring; It only changes the scope
-it was invoked from.  Second it does not rename anything it only
-replaces occurrences and has no side-effects.  This refactoring
-can be used to perform some non-standard refactorings.
+different from rename refactoring; It only changes the scope it was
+invoked from.  Second it does not rename anything it only replaces
+occurrences and has no side-effects.  This refactoring can be used to
+perform some non-standard refactorings.
+
+
+Inline Method Refactoring
+-------------------------
+
+Inline method refactoring can add imports when necessary.  For
+instance consider ``mod1.py`` is::
+
+  import sys
+
+
+  class C(object):
+      pass
+
+  def do_something():
+      print sys.version
+      return C()
+
+and ``mod2.py`` is::
+
+  import mod1
+
+
+  c = mod1.do_something()
+
+After inlining `do_something`, ``mod2.py`` would be::
+
+  import mod1
+  import sys
+
+
+  print sys.version
+  c = mod1.C()
+
+Also rope can inline class methods; for instance in::
+
+  class C(object):
+      @classmethod
+      def say_hello(cls, name):
+          return 'Saying hello to %s from %s' % (name, cls.__name__)
+  hello = C.say_hello('Rope')
+
+inlining `say_hello` will result in::
+
+  class C(object):
+      pass
+  hello = 'Saying hello to %s from %s' % ('Rope', C.__name__)
 
 
 Sorting Imports
 Object Inference
 ================
 
+This section is a bit out of date.  SOI can do more than described
+here (See unittests).  Hope to update this someday!
+
 
 Static Object Inference
 -----------------------
 files is changed on the changed scopes automatically. (This can be
 overridden in project ``config.py``.)
 
-Many kind of information is collected during SOI like per name data
+Many kinds of information is collected during SOI like per name data
 for builtin container types::
 
   l1 = [C()]
 more than one module and more than once (not considering dynamic
 situations.) One advantage of SOI is that it is much faster than DOI.
 
-Many enhancements to rope's object inference has been planned and till
-``0.5`` release most of them will be implemented.  I'll write more
-about them in future releases.
-
-'Rename when unsure' option has been added to rename refactoring.  This
-option tells rope to rename when it doesn't know whether it is an
-exact match or not.  For example after renaming `C.a_func` when the
-'rename when unsure' option is set in::
-
-  class C(object):
-
-      def a_func(self):
-          pass
-
-  def a_func(arg):
-      arg.a_func()
-
-  C().a_func()
-  
-we would have::
-
-  class C(object):
-
-      def new_func(self):
-          pass
-
-  def a_func(arg):
-      arg.new_func()
-
-  C().new_func()
-
-Note that the global `a_func` was not renamed because we are sure that
-it is not a match.  But when using this option there might be some
-unexpected renames.  So only use this option when the name is not
-another python defined elements.
-
 
 Dynamic Object Inference
 ------------------------
 
-Dynamic type inference gets its needed information from running
-modules (``M-X p``) or unit tests (``M-X t``).  You open the module
-to run (probably your test suite), then use ``M-X p`` or ``M-X t`` if
-it is a test suite.  Since as the program runs, rope gathers
-type information, the program runs slower.  Right now rope doesn't
-have a good interface for running programs.  It just prints the output
-to the terminal and does not get inputs.  This will be enhanced in
-future releases. After the program is run, you can get better code
-assists and some of the refactorings perform much better.
+Dynamic type inference collects its information by running modules
+(``C-c x p``) or unit tests (``C-c x t``).  Since as the program runs,
+rope gathers type information, the program runs slower.  Right now
+rope doesn't have a good interface for running programs.  It just
+prints the output to the terminal and does not get inputs.  This will
+be enhanced in future releases. After the program is run, you can get
+better code assists and some of the refactorings perform much better.
 
 ``mod1.py``::
 
   func(C1())
   func(C2())
 
-After running `mod1` module test rope's DOI this way:
+After running `mod1` either SOI or DOI on this module you can test:
 
 ``mod2.py``::
 

rope/ui/actionhelpers.py

                 self.exception = None
 
             def __call__(self):
+                toplevel.bind('<<dont_wait_here>>', self._quit)
                 try:
-                    try:
-                        self.result = self.task(handle)
-                    except Exception, e:
-                        self.exception = e
+                    self.result = self.task(handle)
+                except Exception, e:
+                    self.exception = e
                 finally:
-                    toplevel.quit()
-                    toplevel.update_idletasks()
+                    toplevel.event_generate('<<dont_wait_here>>')
+
+            def _quit(self, event):
+                toplevel.quit()
 
         calculate = Calculate(self.task)
         def stop(event=None):

rope/ui/refactor.py

 
     def _get_dialog_frame(self):
         frame = Tkinter.Frame(self.toplevel)
-        goal_label = Tkinter.Label(frame, text='Goal :')
-        pattern_label = Tkinter.Label(frame, text='Pattern :')
-        self.pattern = Tkinter.Text(frame, width=50, height=2)
-        self.goal = Tkinter.Text(frame, width=50, height=2)
+        goal_label = Tkinter.Label(frame, text='Goal')
+        pattern_label = Tkinter.Label(frame, text='Pattern')
+        self.pattern = Tkinter.Text(frame, width=62, height=2)
+        self.goal = Tkinter.Text(frame, width=62, height=2)
 
         patterns_help = \
             'Rope searches for `pattern` in the project and replaces its\n' \
         imports_frame = Tkinter.Frame(frame, borderwidth=1,
                                       relief=Tkinter.RIDGE)
         imports_help = 'Add imports here; These imports are added to ' \
-                       'changed files:'
+                       'changed files'
         imports_label = Tkinter.Label(imports_frame, text='Imports',
                                       justify=Tkinter.LEFT, width=70)
         imports_label.grid(row=0)