SF.net SVN: bluefish:[8009] trunk/bluefish/src/stringlist.c

[Olivier Sessink]

Olivier,
actually I was writing new code that would remove dead entries from
OpenRecent menu (the files that are no longer accesible).
Your fix seems to be working well- I tested my code with 8010 and found
no issues.
I am attaching the code I mentioned above. In the past we discussed
about more general approach of handling dead entries, however, it seems
this is not that easy to do. At first, project_open_from_file() and
doc_new_from_uri() does not return anything, so there is no way to
detect if file was opened sucessfully. Rewriting these functions is more
complicated than using access(), I think.
Second, project files are handled differently from simple files, and
there is no generic function to add or remove filename from stringlists...
Looking forward for Your comments.
Andrius

I think that is actually quite a hard problem to do it right. Because
there might be temporary reasons why a file does not exist (for example
a network location that is not mounted - which is quite common for web
developers). Second, detecting if a file exist might be a very slow
operation. I update the Bluefish website over sftp:// for example, and
opening or saving a file easily takes a second or two (I'm in the
Netherlands, the server is somewhere on the US west coast). That is why
all file operations in file.c are all done in a background thread. So
detecting this should be done in a background thread too.

This is also why access() is not the right thing to use, because it will
not work for URL's, so existence of files over sftp:// or smb:// cannot
be detected. There is a g_file_....() alternative, but we should use the
asynchronous method (otherwise we might block the GUI for multiple seconds).

So perhaps the best approach would be to integrate this in the dialog
that the user gets when a file is loaded which cannot be found. If the
user then cancels the load, remove it from the recent list, if a user
reloads (because he realized that he forgot to mount the network drive),
don't remove it.

Does that sound like a good idea?

(cc-ing the -dev list)

Olivier

[Andrius]

Olivier,
I totally agree that dialog should provide more choices. I would say that there should be three choices - first one would be to Open file as new one(we can show standard Open... dialog), then to leave entry in the list ad do nothing (we can call it Cancel, probably) and third to remove file entry from list. What do You think?
Regarding access(); I havent noticed any delays when using it on MacOSX (also with network files), but this might be related to how MacOSX handles remote files. Probably it is worth to put code on svn to test it on more systems?
By the way, .bfproject files are opened synchronuosly using g_file_get_uri(). Since average user stores project file locally, this should be OK (at least nobody is complaining). So, it is not that much different from access().
Other related question is about .po files. For dialog window I would probably need to add several extra strings. Should I also update .po file or this is handled by someone else?

Andrius

________________________________
Sent: Tuesday, July 30, 2013 10:30 PM
Subject: Re: Fwd: Re: SF.net SVN: bluefish:[8009] trunk/bluefish/src/stringlist.c

Olivier,
actually I was writing new code that would remove dead entries from
OpenRecent menu (the files that are no longer accesible).
Your fix seems to be working well- I tested my code with 8010 and found
no issues.
I am attaching the code I mentioned above. In the past we discussed
about more general approach of handling dead entries, however, it seems
this is not that easy to do. At first, project_open_from_file() and
doc_new_from_uri() does not return anything, so there is no way to
detect if file was opened sucessfully. Rewriting these functions is more
complicated than using access(), I think.
Second, project files are handled differently from simple files, and
there is no generic function to add or remove filename from stringlists...
Looking forward for Your comments.
Andrius

I think that is actually quite a hard problem to do it right. Because
there might be temporary reasons why a file does not exist (for example
a network location that is not mounted - which is quite common for web
developers). Second, detecting if a file exist might be a very slow
operation. I update the Bluefish website over sftp:// for example, and
opening or saving a file easily takes a second or two (I'm in the
Netherlands, the server is somewhere on the US west coast). That is why
all file operations in file.c are all done in a background thread. So
detecting this should be done in a background thread too.
This is also why access() is not the right thing to use, because it will
not work for URL's, so existence of files over sftp:// or smb:// cannot
be detected. There is a g_file_....() alternative, but we should use the
asynchronous method (otherwise we might block the GUI for multiple seconds).
So perhaps the best approach would be to integrate this in the dialog
that the user gets when a file is loaded which cannot be found. If the
user then cancels the load, remove it from the recent list, if a user
reloads (because he realized that he forgot to mount the network drive),
don't remove it.
Does that sound like a good idea?
(cc-ing the -dev list)
Olivier
--
Bluefish website http://bluefish.openoffice.nl/
Blog http://oli4444.wordpress.com/

[Olivier Sessink]

Olivier,
I totally agree that dialog should provide more choices. I would say
that there should be three choices - first one would be to Open file
as new one(we can show standard Open... dialog), then to leave entry
in the list ad do nothing (we can call it Cancel, probably) and third
to remove file entry from list. What do You think?

I like the option "Open file as new", or perhaps we should call it
"Create file".

I'm not sure about giving the user a button to remove it from the recent
list. Too many choices in a GUI make people have to search too much. I'm
not sure if this is important enough for most people. I would say "if
cancel -> always remove from recent list".

Regarding access(); I havent noticed any delays when using it on
MacOSX (also with network files), but this might be related to how
MacOSX handles remote files. Probably it is worth to put code on svn
to test it on more systems?

have you tried it on a local network, or also on files on a far away
webdav share or sftp server? The issue is only present on server that is
very remote with a high latency. (ever tried to edit files over a
satellite connection?)

By the way, .bfproject files are opened synchronuosly using
g_file_get_uri(). Since average user stores project file locally, this
should be OK (at least nobody is complaining). So, it is not that much
different from access().

true, we currently don't handle project files on a far away remote
server nicely. But I assume that most users have their project files
locally (is that a valid assumption?).

Other related question is about .po files. For dialog window I would
probably need to add several extra strings. Should I also update .po
file or this is handled by someone else?

That is done automatically by 'make update-po', assuming the string is
marked with _() or N_(). We do that just before string freeze, so you
don't need to commit changes to the po files.

Olivier

[Andrius]

"Create file" would be more appropriate for blank file creation. What about
"Open from new location" ? Regarding Cancel I agree- it is enough to
have single button.

I got Your point regarding remote files. OK, lets do check file existence in the correct way. Should we use existing queues for this ( fiqueue that gets file info should be the best way), or just make generic function with  g_file_query_info_async()? I think check of the file info would have smallest overhead for proof of accesability.
Looking forward for Your comments,
Andrius

________________________________
Sent: Wednesday, July 31, 2013 9:46 PM
Subject: Re: Fwd: Re: SF.net SVN: bluefish:[8009] trunk/bluefish/src/stringlist.c
Olivier,

Post by Andrius
I totally agree that dialog should provide more choices. I would

say that there should be three choices - first one would be to
Open file as new one(we can show standard Open... dialog), then
to leave entry in the list ad do nothing (we can call it Cancel,
probably) and third to remove file entry from list. What do You
think?

I like the option "Open file as new", or perhaps we should call it

"Create file".

I'm not sure about giving the user a button to remove it from the

recent list. Too many choices in a GUI make people have to search
too much. I'm not sure if this is important enough for most people.
I would say "if cancel -> always remove from recent list".

Regarding access(); I havent noticed any delays when using it on MacOSX (also with network files), but this might be related to how MacOSX handles remote files. Probably it is worth to put code on svn to test it on more systems?
have you tried it on a local network, or also on files on a far away

webdav share or sftp server? The issue is only present on server
that is very remote with a high latency. (ever tried to edit files
over a satellite connection?)

By the way, .bfproject files are opened synchronuosly using g_file_get_uri(). Since average user stores project file locally, this should be OK (at least nobody is complaining). So, it is not that much different from access().
true, we currently don't handle project files on a far away remote

server nicely. But I assume that most users have their project files
locally (is that a valid assumption?).

Other related question is about .po files. For dialog window I would probably need to add several extra strings. Should I also update .po file or this is handled by someone else?
That is done automatically by 'make update-po', assuming the string

is marked with _() or N_(). We do that just before string freeze, so
you don't need to commit changes to the po files.

Olivier
--

Bluefish website http://bluefish.openoffice.nl/
Blog http://oli4444.wordpress.com/

[Olivier Sessink]

Post by Andrius
"Create file" would be more appropriate for blank file creation. What
about "Open from new location" ?

This button will be in the dialog that pops up when you switch to a file
that failed loading, right?

How about

"Create at this location" ? (hmm too long for a button text)
"Create at location"
"Create here"
"Create this file"

Post by Andrius
I got Your point regarding remote files. OK, lets do check file
existence in the correct way. Should we use existing queues for this (
fiqueue that gets file info should be the best way), or just make
generic function with g_file_query_info_async()? I think check of the
file info would have smallest overhead for proof of accesability.

yes I think so too, so fiqueue in file.c is too much overhead, it also
tries to find the mime type etc. fiqueue has two advantages over plain
g_file_query_info_async(): it avoids hundreds of simultaneous calls
(max. 8, the rest will be queued), and it can handle locations that
first need to mounted (stop all queries for the moment, and after
mounting start them again). Are these advantages required for the place
where you will use the code? Where do you intent to call this?

Olivier

[Andrius]

Post by Olivier Sessink

Post by Andrius
"Create file" would be more appropriate for blank file creation. What
about "Open from new location" ?

This button will be in the dialog that pops up when you switch to a file
that failed loading, right?
How about
"Create at this location" ? (hmm too long for a button text)
"Create at location"
"Create here"
"Create this file"

The dialog will pop up when file fails to load from **OpenRecent** menu. The reason this is happening is that user moved file to other folder, for example. Or he removed USB drive. I think it would be right to suggest to open the same file from other location. Word "Create" would confuse user, since is not willing to create anything, just open what already exist.

Post by Olivier Sessink

Post by Andrius
I got Your point regarding remote files. OK, lets do check file
existence in the correct way. Should we use existing queues for this (
fiqueue that gets file info should be the best way), or just make
generic function with  g_file_query_info_async()? I think check of the
file info would have smallest overhead for proof of accesability.

yes I think so too, so fiqueue in file.c is too much overhead, it also
tries to find the mime type etc. fiqueue has two advantages over plain
g_file_query_info_async(): it avoids hundreds of simultaneous calls
(max. 8, the rest will be queued), and it can handle locations that
first need to mounted (stop all queries for the moment, and after
mounting start them again). Are these advantages required for the place
where you will use the code? Where do you intent to call this?

I think we have to add several new functions.
In bfwin_uimanager.c create recent_menu_activate_async() that would initiate file availability check.
In file.c create function for file availability check and callback to handle result.
Depending on result show error dialog or call currentrecent_menu_activate() (which handles OpenRecent atm).

Post by Olivier Sessink
Olivier
--
Bluefish website http://bluefish.openoffice.nl/
Blog http://oli4444.wordpress.com/
--
To unsubscribe from this list: send the line "unsubscribe bluefish-dev" in
Bluefish web site: http://bluefish.openoffice.nl/

[Olivier Sessink]

Post by Andrius
The dialog will pop up when file fails to load from **OpenRecent** menu. The reason this is happening is that user moved file to other folder, for example. Or he removed USB drive. I think it would be right to suggest to open the same file from other location. Word "Create" would confuse user, since is not willing to create anything, just open what already exist.

I thought to use the dialog that is already present in Bluefish that
pops up if you activate a document that failed loading. So the recent
menu will just try to open the document like it is done right now. If it
fails, you get the dialog "File failed to load" with current options
"retry" "retry all failed" "close" and "close all failed". Then we add
an option "create this file", and if the user selects "close", remove
the file from the recent list. I think that would be less code to
accomplish the same. Do you think that is a good solution as well?

Post by Andrius
I think we have to add several new functions.
In bfwin_uimanager.c create recent_menu_activate_async() that would initiate file availability check.

I assume that runs when the list of recent documents is loaded and we
add them to the GUI? What do we do with a sftp or webdav url in the
recent list? Are we going to ask the user to provide the
username/password for every server that is on the recent list when we
load it?

Olivier

[Andrius]

Post by Andrius

Post by Andrius
The dialog will pop up when file fails to load from **OpenRecent** menu.

The reason this is happening is that user moved file to other folder, for
example. Or he removed USB drive. I think it would be right to suggest to open
the same file from other location. Word "Create" would confuse user,
since is not willing to create anything, just open what already exist.
I thought to use the dialog that is already present in Bluefish that
pops up if you activate a document that failed loading. So the recent
menu will just try to open the document like it is done right now. If it
fails, you get the dialog "File failed to load" with current options
"retry" "retry all failed" "close" and "close
all failed". Then we add
an option "create this file", and if the user selects
"close", remove
the file from the recent list. I think that would be less code to
accomplish the same. Do you think that is a good solution as well?

I will look into that, but my impression that this would not result in less code. It is a quite different to what we need when opening file  trough OpenRecent.
This also will not work for .bfproject files, since they are not handled different way. I think we need solution that would also handle errors for project files.
Can You also clarify what "create this file" will do? It will just create blank file with the same name? Or something different?

Post by Andrius

Post by Andrius
I think we have to add several new functions.
In bfwin_uimanager.c create recent_menu_activate_async() that would

initiate file availability check.
I assume that runs when the list of recent documents is loaded and we
add them to the GUI? What do we do with a sftp or webdav url in the
recent list? Are we going to ask the user to provide the
username/password for every server that is on the recent list when we
load it?

No, this will only run when user goes to File|OpenRecent..  or Project|OpenRecent... menu and clicks on the entry. So, only one file or one project file( Imean .bfproject) will be accessed for availability check. Project files will be handled the same way as it is now. Look in recent_menu_activate() in bfwin_uimanager.c for details.
Sorry, I could not answer about ftp since there is no ftp stuff on MacOSX (and Windows). But I guess, for user it will look the same way as it is now, I mean the same things will show up.

[Olivier Sessink]

Post by Andrius
I will look into that, but my impression that this would not result in
less code. It is a quite different to what we need when opening file
trough OpenRecent. This also will not work for .bfproject files, since
they are not handled different way. I think we need solution that
would also handle errors for project files. Can You also clarify what
"create this file" will do? It will just create blank file with the
same name? Or something different?

true, for projects we need new code, because we currently don't handle a
project load failure.

But we *do* handle a file load failure, why handle it different if it is
opened from the recent menu compared to a file dialog or the sidebar or
a project file? I don't see the real advantage (yet)..

Olivier

[Andrius]

Post by Olivier Sessink

Post by Andrius
I will look into that, but my impression that this would not result in
less code. It is a quite different to what we need when opening file
trough OpenRecent. This also will not work for .bfproject files, since
they are not handled different way. I think we need solution that
would also handle errors for project files. Can You also clarify what
"create this file" will do? It will just create blank file with

the

Post by Andrius
same name? Or something different?

true, for projects we need new code, because we currently don't handle a
project load failure.
But we *do* handle a file load failure, why handle it different if it is
opened from the recent menu compared to a file dialog or the sidebar or
a project file? I don't see the real advantage (yet)..

Sorry to say, but I just now got what You were pointing to regarding simple files. I was working on project (.bfproject) files which are not handled at all at the moment.
Sure, for non-bfproject files we can just add remove_filename_from_recentlist() to the handling of Close and Close All buttons. This function is in the patch I attached earlier.
But we still need code for bfproject files. In my earlier emails I was suggesting regarding these. Can You give feedback from this point of view?

[Olivier Sessink]

Post by Andrius
Sorry to say, but I just now got what You were pointing to regarding simple files. I was working on project (.bfproject) files which are not handled at all at the moment.
Sure, for non-bfproject files we can just add remove_filename_from_recentlist() to the handling of Close and Close All buttons. This function is in the patch I attached earlier.
But we still need code for bfproject files. In my earlier emails I was suggesting regarding these. Can You give feedback from this point of view?

oh sorry, perhaps I didn't make that very clear. Yes all my reasoning
was about the files, not the projects.

regarding the patch: perhaps it is nicer to make
project_open_from_file() return 0 on fail, and then remove the entry
from the menu? That way we can also handle other errors that make a
project unable to open.

your patch has some duplicate code, for example
gtk_recent_manager_remove_item(main_v->recentm, str, &gerror); is called
twice. I think you moved some code to a separate function
remove_filename_from_recentlist() and then forgot to remove the code at
the original location? The rest looks good, but I think it would be even
nicer if we introduce a return code for project_open_from_file(). I
think you suggested that in some earlier email already, right?

Olivier

[Andrius]

Post by Andrius

Post by Andrius
Sorry to say, but I just now got what You were pointing to regarding simple

files. I was working on project (.bfproject) files which are not handled at all
at the moment.

Post by Andrius
Sure, for non-bfproject files we can just add

remove_filename_from_recentlist() to the handling of Close and Close All
buttons. This function is in the patch I attached earlier.

Post by Andrius
But we still need code for bfproject files. In my earlier emails I was

suggesting regarding these. Can You give feedback from this point of view?
oh sorry, perhaps I didn't make that very clear. Yes all my reasoning
was about the files, not the projects.
regarding the patch: perhaps it is nicer to make
project_open_from_file() return 0 on fail, and then remove the entry
from the menu? That way we can also handle other errors that make a
project unable to open.
your patch has some duplicate code, for example
gtk_recent_manager_remove_item(main_v->recentm, str, &gerror); is called
twice. I think you moved some code to a separate function
remove_filename_from_recentlist() and then forgot to remove the code at
the original location? The rest looks good, but I think it would be even
nicer if we introduce a return code for project_open_from_file(). I
think you suggested that in some earlier email already, right?

The patch code is messy (it is just first iteration to proof the principle), however, I do not see where I call gtk_recent_manager_remove_item() twice. The program paths for bfprojects and regular files are different, so this function is never called twice for given file.
I probably modify a little bit remove_filename_from_recentlist() to make it work for both bfproject and other files.
Making project_open_from_file() to return something actually was my first though. It is easy to do.
The last question is regarding dialog for bfproject files. Should it be the same as for other files? Retry all and Close All buttons are clearly overkill, since project it opened one-by-one. How about just Open from new location and Cancel?

[Olivier Sessink]

Post by Andrius
The patch code is messy (it is just first iteration to proof the principle), however, I do not see where I call gtk_recent_manager_remove_item() twice. The program paths for bfprojects and regular files are different, so this function is never called twice for given file.

sorry, I didn't review it very well.

Post by Andrius
I probably modify a little bit remove_filename_from_recentlist() to make it work for both bfproject and other files.
Making project_open_from_file() to return something actually was my first though. It is easy to do.
The last question is regarding dialog for bfproject files. Should it be the same as for other files? Retry all and Close All buttons are clearly overkill, since project it opened one-by-one. How about just Open from new location and Cancel?

yeah, Open from new location and Cancel seems good.

Olivier

[Jim Hayward]

Post by Olivier Sessink
So perhaps the best approach would be to integrate this in the dialog
that the user gets when a file is loaded which cannot be found. If the
user then cancels the load, remove it from the recent list, if a user
reloads (because he realized that he forgot to mount the network drive),
don't remove it.

My preference would be to stop using pop-up dialogs to present this type
of information/options to users about specific documents. I think it
would be better to start using a GtkInfoBar at the top of the specific
document window that the message applies too.


Regards,
Jim H

[clansco]

On Fri, 02 Aug 2013 19:53:20 -0700

Post by Jim Hayward

Post by Olivier Sessink
So perhaps the best approach would be to integrate this in the dialog
that the user gets when a file is loaded which cannot be found. If the
user then cancels the load, remove it from the recent list, if a user
reloads (because he realized that he forgot to mount the network drive),
don't remove it.

My preference would be to stop using pop-up dialogs to present this type
of information/options to users about specific documents. I think it
would be better to start using a GtkInfoBar at the top of the specific
document window that the message applies too.

+1

[Olivier Sessink]

Post by Jim Hayward

Post by Olivier Sessink
So perhaps the best approach would be to integrate this in the dialog
that the user gets when a file is loaded which cannot be found. If the
user then cancels the load, remove it from the recent list, if a user
reloads (because he realized that he forgot to mount the network drive),
don't remove it.

My preference would be to stop using pop-up dialogs to present this type
of information/options to users about specific documents. I think it
would be better to start using a GtkInfoBar at the top of the specific
document window that the message applies too.

true, that would be nice for all document-related dialogs (also for
very-long-line popup for example).

Olivier

[Andrius]

Post by Olivier Sessink
true, that would be nice for all document-related dialogs (also for
very-long-line popup for example).

That would be nice, but it will require a lot of code changes. For example, we would need to remove buttons like "Retry all" and "Close all" ...
Dialogs that are related to the projects I think is better to make old way (since they are related to all documents that are in project)?

[Olivier Sessink]

Post by Andrius

Post by Olivier Sessink
true, that would be nice for all document-related dialogs (also for
very-long-line popup for example).

That would be nice, but it will require a lot of code changes. For example, we would need to remove buttons like "Retry all" and "Close all" ...
Dialogs that are related to the projects I think is better to make old way (since they are related to all documents that are in project)?

yes for now I think improving the old dialogs would be an improvement
already, in the future we could improve it further.

Olivier