On 10/20/2013 09:30 PM, Andrius wrote:
> Below are few other minor issues with project loading.
> First one might be caused by r8103, but I am not sure, it might have
> been there earlier.
> After project load, the tooltips that shows file information when cursor
> is located in the notebook tab has only general data for the files that
> were in project already. Name, mime type, encoding. While new files that
> are opened at the later time, has much more detailed information,
> including size and date modified etc.
I have feeling what has caused this issue, I'll have a look at this. But
on my first test I cannot reproduce this...?
> Other issue with r8103 and r8104 is that it is hard to make document
> following when file in the notebook is accessed for the first time.
I don't understand exactly what the issue is. You mean that once the
window is shown, the active document is not 'followed' by the filebrowser?
Olivier
> Pre-filled files has all iters in the treemodel, and it is not possible
> to refresh directory based on whether iter is present or not.
> I just commited r8113 which is attempt to fix this issue, but it is not
> perfect, since it works only for first activated document. If project is
> complicated with files scattered in several folders, activating document
> in different folder fails to follow it in filebrowser.
> The complete fix for issue would be to move register_delayed_refresh()
> to change_focus_to_file() and execute scroll_to_iter() in the callback
> after refresh is finished. But in this case we always will have 200 ms
> delay with document following, which might look too slow.
> Any thoughts?
> Andrius
>
> ------------------------------------------------------------------------
> *From:* Andrius <andriusr-/***@public.gmane.org>
> *To:* "bluefish-dev-QLpEr2logwzILq5++***@public.gmane.org" <bluefish-dev-QLpEr2logwzILq5++***@public.gmane.org>
> *Sent:* Thursday, October 17, 2013 7:00 PM
> *Subject:* Re: new filebrowser backend code merged
>
> Yes, the crash is fixed now.
>
> ------------------------------------------------------------------------
> *From:* Olivier Sessink <olivier-nC7VSXl9xTvubjhGYR2Sn81g+***@public.gmane.org>
> *To:* bluefish-dev-QLpEr2logwzILq5++***@public.gmane.org
> *Sent:* Thursday, October 17, 2013 4:40 PM
> *Subject:* Re: new filebrowser backend code merged
>
> Thanks,
>
> I think I found the real bug: I forgot to remove the record from the
> hash table after I removed the record. So the hash table pointed
> to a
> record that did not exist anymore.
>
> Olivier
>
> On 10/17/2013 02:19 PM, Andrius wrote:
> > It still crashes when closing missing file with traceback:
> > 0 bluefish-bin 0x0000000101b478fb
> > get_treepath_for_record + 27
> > 1 bluefish-bin 0x0000000101b49a16
> > gtk_tree_model_record_changed + 54
> > 2 bluefish-bin 0x0000000101b49c98
> > filetreemodel_set_weight + 152
> > 3 bluefish-bin 0x0000000101b4c5d2
> > fb2_file_is_closed + 66
> > 4 bluefish-bin 0x0000000101b34d76
> doc_set_uri + 102
> > 5 bluefish-bin 0x0000000101b3aa11
> doc_destroy + 1265
> > 6 bluefish-bin 0x0000000101b5db37
> > doc_close_single_backend + 583
> > 7 bluefish-bin 0x0000000101b3cd91
> > doc_close_from_activate + 33
> > 8 libglib-2.0.0.dylib 0x0000000102d6e73b
> g_idle_dispatch
> > + 91
> > 9 libglib-2.0.0.dylib 0x0000000102d6b4e0
> g_main_dispatch
> > + 496
> > Andrius
> >
> >
> >
>
>