Make bf to honor follow active document setting

[Andrius]

Hi all,
I did made some improvement if filebrowser behavior- now it is honors Follow Active Document setting and scrolls to the active document.

Unfortunately, I have possibility to tests on MacOSX only, so I am not sure if it would be good idea to commit it to svn. Since some features of filebrowser are OS sensitive (on MacOSX I could not open files trough ftp, for example), would it be possible for everybody to test it on their systems first?
Looking forward for comments.
Andrius

[clansco]

On Sat, 28 Sep 2013 03:13:23 -0700 (PDT)

Post by Andrius
Hi all,
I did made some improvement if filebrowser behavior- now it is honors Follow Active Document setting and scrolls to the active document.

Navigation now works perfectly in Slackware 14. This improvement is very nice. Thank you.

[Olivier Sessink]

Post by Andrius
Hi all,
I did made some improvement if filebrowser behavior- now it is honors
Follow Active Document setting and scrolls to the active document.
Unfortunately, I have possibility to tests on MacOSX only, so I am not
sure if it would be good idea to commit it to svn. Since some features
of filebrowser are OS sensitive (on MacOSX I could not open files trough
ftp, for example), would it be possible for everybody to test it on
their systems first?
Looking forward for comments.
Andrius

I've just tested it a bit. It looks promising, but I think it can be
improved a bit. It's not behaving the same in all view modes. In view
mode 'tree' it now scrolls to the filename of the current document, but
in view mode 'flat' and 'dual' it does not (it opens the directory, but
does not scroll to the filename).

In flat view, it refreshes the directory on every document switch - even
if both documents are in the same directory. In treeview it never
refreshes a directory when switching documents. In dual view it works as
expected -> it refreshed the directory when you switch to a document
that has a different directory than the previous document. (not tested
if this is a new or an old bug - could be that this was a bug already
before)

Something that was definitely a bug before: I noticed that in mode
'tree' the directory dropdown on the top of the filebrowser doesn't work.

Olivier

[Andrius]

I would like to clarify, that this improvement is only for tree mode. Flat and Dual modes are behaving the same as before: flat mode does no scrolling at all, while dual mode scrolls in directory window only. It should be possible to implement doc following also in other modes, I think.

Post by Olivier Sessink
In flat view, it refreshes the directory on every document switch - even
if both documents are in the same directory. In treeview it never
refreshes a directory when switching documents.

Can You clarify what You mean by "refreshing"? Can You point to GUI part that is not refreshing? Is this directory dropdown on the top of filebrowser?

Post by Olivier Sessink
Something that was definitely a bug before: I noticed that in mode
'tree' the directory dropdown on the top of the filebrowser doesn't work.

Probably this was also before. This one is easy to fix.

Post by Olivier Sessink
________________________________
Sent: Saturday, September 28, 2013 10:43 PM
Subject: Re: Make bf to honor follow active document setting

Post by Andrius
Hi all,
I did made some improvement if filebrowser behavior- now it is honors
Follow Active Document setting and scrolls to the active document.
Unfortunately, I have possibility to tests on MacOSX only, so I am not
sure if it would be good idea to commit it to svn. Since some features
of filebrowser are OS sensitive (on MacOSX I could not open files trough
ftp, for example), would it be possible for everybody to test it on
their systems first?
Looking forward for comments.
Andrius

I've just tested it a bit. It looks promising, but I think it can be
improved a bit. It's not behaving the same in all view modes. In view
mode 'tree' it now scrolls to the filename of the current document, but
in view mode 'flat' and 'dual' it does not (it opens the directory, but
does not scroll to the filename).
In flat view, it refreshes the directory on every document switch - even
if both documents are in the same directory. In treeview it never
refreshes a directory when switching documents. In dual view it works as
expected -> it refreshed the directory when you switch to a document
that has a different directory than the previous document. (not tested
if this is a new or an old bug - could be that this was a bug already
before)
Something that was definitely a bug before: I noticed that in mode
'tree' the directory dropdown on the top of the filebrowser doesn't work.
Olivier
--
To unsubscribe from this list: send the line "unsubscribe bluefish-dev" in
Bluefish web site: http://bluefish.openoffice.nl/

[Olivier Sessink]

Post by Andrius
I would like to clarify, that this improvement is only for tree mode. Flat
and Dual modes are behaving the same as before: flat mode does no
scrolling at all, while dual mode scrolls in directory window only. It
should be possible to implement doc following also in other modes, I
think.

ahh thanks for this clarification. I think we should look at all three
modes, so we can re-use the code as much as possible. I would like to
avoid that every mode has it's own code paths. This makes both coding and
testing harder.

Post by Andrius

Post by Olivier Sessink
In flat view, it refreshes the directory on every document switch - even
if both documents are in the same directory. In treeview it never
refreshes a directory when switching documents.

Can You clarify what You mean by "refreshing"? Can You point to GUI part
that is not refreshing? Is this directory dropdown on the top of
filebrowser?

refreshing as in "opening the directory on the disk and seeing if anything
has changed"

what is the best way to proceed if I want to help coding to get this
working in all view modes? Should I use your patch and continue based on
your changes, or should I work on top of SVN and integrate your changes on
the way?

Olivier

[Andrius]

Post by Olivier Sessink
refreshing as in "opening the directory on the disk and seeing if anything
has changed"

In this case refreshing on each document change might be not bad idea, since directory content might change, for example, if file is on some network share.

Post by Olivier Sessink
what is the best way to proceed if I want to help coding to get this
working in all view modes? Should I use your patch and continue based on
your changes, or should I work on top of SVN and integrate your changes on
the way?

Fell free to choose any way, for me it is difficult to decide. After spending week or so on this patch, I can say that current code is quite inconsistent and probably will require some rethink and rewrite. Right now filebrowser behavior is quite different in different view modes due this inconsistency.

1. Directory dropdown on the top shows different things in different view modes. In flat and dual modes its display changes depending on what directory is selected. So, we might look at it as the line that shows directory of active document or the document selected in the filebrowser. However, in tree mode this is not true, since when we select document (or activate it) the directory name does not change (this is coded in dir_v_selection_changed_lcb() ). I think it would be useful to make behavior uniform in all modes.
And there is problem with dropdown selection as You noticed...

2. Further code complication is two callbacks dir_v_selection_changed_lcb() and dirmenu_changed_lcb(). Obviously they are required for navigating in filebrowser, however, code in fb2_focus_dir() also depends on them, so code reading gets difficult. In some cases we have do disable signals, sometimes we do not. I think it would be useful to do not use these callbacks inexplicably in the code, even if it would add some extra lines. 

Andrius

[Olivier Sessink]

Post by Olivier Sessink

Post by Olivier Sessink
refreshing as in "opening the directory on the disk and seeing if

anything

Post by Olivier Sessink
has changed"

In this case refreshing on each document change might be not bad idea,
since directory content might change, for example, if file is on some
network share.

refreshing a directory over a slow network connection easily takes a
couple of seconds (even from my high speed connection at home in europe,
refreshing a directory hosted on the US west coast over sftp takes a
couple of seconds). If someone uses <ctrl><arrow> to switch to a another
open document a few tabs away that might trigger multiple refreshes. So
I think we should not refresh on every document switch, or make this
optional behavior.

Post by Olivier Sessink
Fell free to choose any way, for me it is difficult to decide. After
spending week or so on this patch, I can say that current code is
quite inconsistent and probably will require some rethink and rewrite.
Right now filebrowser behavior is quite different in different view
modes due this inconsistency.
1. Directory dropdown on the top shows different things in different
view modes. In flat and dual modes its display changes depending on
what directory is selected. So, we might look at it as the line that
shows directory of active document or the document selected in the
filebrowser. However, in tree mode this is not true, since when we
select document (or activate it) the directory name does not change
(this is coded in dir_v_selection_changed_lcb() ). I think it would be
useful to make behavior uniform in all modes.
And there is problem with dropdown selection as You noticed...
2. Further code complication is two callbacks
dir_v_selection_changed_lcb() and dirmenu_changed_lcb(). Obviously
they are required for navigating in filebrowser, however, code in
fb2_focus_dir() also depends on them, so code reading gets difficult.
In some cases we have do disable signals, sometimes we do not. I think
it would be useful to do not use these callbacks inexplicably in the
code, even if it would add some extra lines.

I'll try to start merging code that works for all viewmodes to svn, and
I'll try to cleanup code on the way.

Olivier

[Olivier Sessink]

Post by Andrius
Fell free to choose any way, for me it is difficult to decide. After
spending week or so on this patch, I can say that current code is
quite inconsistent and probably will require some rethink and rewrite.

ok, I started a massive rewrite, I'm currently sorting the code in a
couple of sections:

1) utility functions

2) directory re-read functions

3) filtering and sorting functions

4) data model functions

5) dialogs and popup menu functions

6) main gui functions

that will at least make it a bit easier to see what we have and where it is.

after I have committed this lets start to remove the dependencies on
backend functions that rely on signals as you mentioned (I found some
even nastier code: fb2_focus_dir calls fb2_set_basedir_backend, which
calls fb2_focus_dir again.......).

Olivier

[Olivier Sessink]

Post by Olivier Sessink
ok, I started a massive rewrite, I'm currently sorting the code in a
1) utility functions
2) directory re-read functions
3) filtering and sorting functions
4) data model functions
5) dialogs and popup menu functions
6) main gui functions
that will at least make it a bit easier to see what we have and where it is.

this re-ordering is done, and there is a bit of a rewrite already in svn

THE FILEBROWSER CODE IN SVN REVISION 8055 IS NOT FUNCTIONAL.

More rewriting is needed, I did not yet merge much of the patch from
Andrius (@Andrius: feel free to work on the code and improve it
further, I won't have time until tomorrow evening).

Olivier

[Olivier Sessink]

the filebrowser should be functional again.

if you see any inconsistencies, please report them.

Olivier