MI branch merge

[Vladimir Prus]

On Saturday 20 May 2006 17:13, Andras Mantia wrote:
> Some more bugs:
>
> 1) if you edit a line which had a breakpoint set and press enter, the
> new lines will also have a breakpoint set. Same issue if you just
> insert lines somewhere: the breakpoints are not moved but are fixed to
> the line numbers. This is a bad regression to 2.x days, something I
> fixed for the old debugger early in 3.0 development. Basicly means
> setting breakpoints useless because as soon as you edit the document
> they will not be at the point you really want to. Just enter some lines
> and delete some others and everything will be a mess. :-(

I honestly don't know how moving of breakpoints use to work before. Can you 
give some hints? Did text editor move the marks automatically, or there was 
explicit code on KDevelop side? 

> 2) After doing what is in 1) Delete All breakpoints does not work. I
> suspect the bug is just the same: improper handling of lists (e.g when
> deleting items).
>
> 3) I miss the buttons to delete all or one breakpoint. 

Deleting one breakpoint is done with "Del" key. I plan to add shortcut names 
to the context meny.

> Using the context 
> menu requires extra click and mouse movements. Anyway, if you only keep
> the menu, add icons there so the menu items are found more easily.

Here's a problem. I removed the original toolbar in part because the icons 
were very unobvious. For example, "delete" and "delete all" icons were 
identical. I'd be happy to add nicer icons to the menu, but where do I get 
them?

> 4) when debugging the following for loop:
>   for (KURL::List::ConstIterator i = urls.begin(); i != urls.end(); ++i)
>   {
>     if (!QExtFileInfo::exists(*i, true, this))
>     ...
>   }
> in the variables view the content of i (i->node->data) is OK the first
> time, but after stepping to the next iteration, it is not, it shows the
> first value for i->node->data. Only the following fields are updated:
> i->node
> i->node->next
> i->node->prev
> i->node->data->d
>
> but not anything like:
> i->node->data0>m_strPath...

Is this QString field? Maybe the problem is that QString handling has a slight 
bug... 

> 5) I have some code which look like this:
>  KMimeType::List list = KMimeType::allMimeTypes();
>  KMimeType::List::iterator it;
>  bool status = false;
>  KMimeType::Ptr mime = KMimeType::findByURL(url);
>  QString mimetype = mime->name();
>
> when entering the method, for mimetype the variables view shows
> (inaccessible). After stepping through the line where it is
> initialized, it is still (inaccessible). Obvisouly it *has* some value.

I'd need full debug output from KDevelop to investigate this. See a separate 
email on obtaining the debug output. 

> 6) this might not be a debugger problem, but I noticed that with 3.4 if
> I type something and try to undo, the editor looses the focus after the
> first undo => you have to click to the editor to perform more undo
> steps.

I suppose that an editor problem.

- Volodya