[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [mylar-dev] this week's plan (v0.3.9)
Mik Kersten wrote:

  Strange, but it seems that it behave much better now.
  Could it be because I wasn't submitting user study monitoring results for several weeks? Just did that this morning...
   Hmm. I believe that using multiple check boxes is really confusing.
The way you've described it is just a single choice and it would be more
intuitive to use something like "radio button" idems similar to .
    
I agree the multiple check boxes are weird, but how else do we indicate that
when you have it set to "3: project", it *also* runs the searches for "1:
landmarks" and "2: interesting files"?  There are fancier widgets that would
work better for this, but for the time being we need something simple.
  To me these 0..5 numbers already intuitive enough and single checkbox/radio would be more sufficient...

  Actually I wonder what kind of widget you have in mind? Please don't use sliders.

  By the way, it would be nice for accessibility to have the same drop-down menus available from a view menu for active search.
   Not much difference between 0 and 1, 2 freezes for 20 seconds and 3 -
for few minutes. None of views are updated in that time.
   Actually the most noticeable freeze happens when I change degree
level or add something to the landmark (especially when resource is
referenced a lot). After that initial freeze the active search view
seems working ok with degree 2.
   It also seems that there should be a limit on the size of search
result in case when something is referenced a lot.
    
Good idea, I've scheduled it for this week:
https://bugs.eclipse.org/bugs/show_bug.cgi?id0042
  Interestingly, but neither standard search or quick-type popup (from Ctrl-T) allows to limit results and can cause similar freeze effect (e.g. try to use Ctrl-T on Object.toString() method)
But I'm still concerned about the freeze that you're seeing.  I have 75
source projects in my workspace, and if I switch between degrees there is no
noticeable delay.  The initial switches to high degrees take a couple
seconds or so to populate the view, until the results are cached at which
point it's faster.  I realize that we don't yet have reproducible steps, but
could you report this as a bug where we can diagnose it?  Please include the
following:
- description of the freeze (e.g. does Eclipse's titlebar go white), does
anything populate the Progress view before the freeze
  Toolbar is going white, CPU load is 100% and Eclipse is not repainting widgets (actually completely weird in this case because it is not entirely gray but rather partial loss of repainting)
- any messages that pop up in the PDE Runtime -> Error Log view
  Nothing in there and not in error log.
- Eclipse, OS, and VM versions
  3.2M1
  win2000 sp2  1Gb RAM
 
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_02-b09)
  Java HotSpot(TM) Client VM (build 1.5.0_02-b09, mixed mode, sharing)
- if you have the memory profiling visible on a note on how much is
allocated before and after the freeze
(http://www.eclipsezone.com/java/forums/t44200.html)
  That reminds me to update my patch for Eclipse 3.2... See http://jroller.com/page/eu?entry=eclipse_patches

  I've played with VisualGC and noticed heavy GC when changing degree. It seems that I should increase Eden space to reduce GC intervals.
  So, default settings from eclipse.ini are not good at all
-vmargs -Xms40m -Xmx256m
  It seems that increasing eden space additionally helped with performance...

  regards,
  Eugene