remove use of g_error() #222
Conversation
LaserEyess
force-pushed
the
remove_g_error
branch
3 times, most recently
from
2b53125
to
5f4229a
Compare
|
@van-de-bugger please try this to make sure it fixes it for you. It should pop up an error dialog if there's a permissions issue. The error message is not the best, but it's what glib returns. |
LaserEyess
force-pushed
the
remove_g_error
branch
from
5f4229a
to
d2158b7
Compare
g_error is only supposed to be for unexpected errors, and therefore should not be used for expected errors. In torrent-add-dialog, the specific issue is that not having read permissions on a file is indeed an *expected* error. In trg_base64encode, not being able to base64encode a file for some reason is also expected. These errors should be passed back to the user, Some refactoring was needed to create a general error-dialog message. There are also still unrelated g_error() usages that need to be cleaned up.
In trg_prefs_constructor, g_get_user_config_dir() is used to create priv->file. This value is always what XDG_CONFIG_HOME is, or at least what the default is, e.g. ~/.config. There should be no circumstances, outside of explicit user intervention, for this to not be user writeable. That being said, if a permissions issue existed, the code was set to core dump via g_error(). That really shouldn't be the response to this as there are cases where this could happen, though it is almost certainly user error outside TRG's control. Therefore, bump this down to a warning. If someone hits this, they'll be able to see what the warning is and understand it.
LaserEyess
force-pushed
the
remove_g_error
branch
from
d2158b7
to
735e406
Compare
I am not familiar with git and git hub. I have managed to checkout the |
|
You can get a patch file by appending `.patch' to the URL: https://github.com/transmission-remote-gtk/transmission-remote-gtk/pull/222.patch But also, I can just create one for you: https://0x0.st/H8j3.patch Github also has some docs for this if you're curious about the "proper" way |
|
Hi, sorry for delay. Ok, with the patch TRG does not crash but shows a dialog box with decent error message. There are few problems, though:
Also, error message is a bit redundant: It says the same info twice: "failed to open" and "open() failed" is just a tautology. I understand failed function name may be meaningful for a developer, but it is too cryptic for an end user. That's not a big problem, though. |
|
Can you open an issue for each of those separately? |
Fixes #221