| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Replace the eel_boolean_bit typedef with a plain guint and remove all
includes.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In order to prevent deadlock when cancelling operations, new thread
were added by commit 2db9a295. However, this introduce various races.
One of them has been fixed by commit 45c7c967. However, I am convinced
that there is still a race when finalizing. One way to fix it is the
usage of g_thread_join. But I think that it would be better to avoid
the deadlock another way. Let's instead remove the problematic thread
and call g_cancellable_cancel without the lock held.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/issues/124
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The test-file-operations-move-files and test-file-operations-copy-files
test cases randomly crash with "GLib-FATAL-CRITICAL: g_source_is_destroyed:
assertion 'g_atomic_int_get (&source->ref_count) > 0' failed", which causes
GitLab CI pipeline failures among others, which is a shame.
I am not able to reproduce those crashes locally, so I can't easily verify
the call stack, but only place where `g_source_destroy()` is called is
when handling progress infos. I see two potential issues which might cause
this. Let's try to fix them.
|
| |
|
|
| |
It’s superfluous and now causes GLib to throw warnings.
|
| |
|
|
|
|
|
| |
This patch reduces the number of macros used to define the type,
by means of the macro G_DECLARE*, and improves the readability of code.
https://bugzilla.gnome.org/show_bug.cgi?id=778139
|
| |
|
|
|
| |
Some issues were fixed, and now we can rerun Uncrustify to format
correctly more part of the code.
|
| |
|
|
|
|
|
|
|
|
|
| |
We were not checking whether the operations was aborted from the user
side when setting the details,so that could make a race and the info
thread setting the details to canceled and the operation thread setting
the details too afterwards before realizing the operations was canceled.
To fix it, always check whether the info progress was canceled or not.
https://bugzilla.gnome.org/show_bug.cgi?id=775094
|
| |
|
|
|
|
|
|
| |
And make the style of Nautilus the same for all files.
Hopefully we can fix all the style issues we can find in the next days,
so expect a little of movement on this.
https://bugzilla.gnome.org/show_bug.cgi?id=770564
|
| | |
|
|
|
And fix make distcheck.
Although libnautilus-private seem self contained, it was actually
depending on the files on src/ for dnd.
Not only that, but files in libnautilus-private also were depending on
dnd files, which you can guess it's wrong.
Before the desktop split, this was working because the files were
distributed, but now was a problem since we reestructured the code, and
now nautilus being a library make distcheck stop working.
First solution was try to fix this inter dependency of files, but at
some point I realized that there was no real point on splitting some of
those files, because for example, is perfectly fine for dnd to need to
access the window functions, and it's perfectly fine for the widgets
in the private library to need to access to all dnd functions.
So seems to me the private library of nautilus is somehow an artificial
split, which provides more problems than solutions.
We needed libnautilus-private to have a private library that we could
isolate from extensions, but I don't think it worth given the problems
it provides, and also, this not so good logical split.
Right now, since with the desktop split we created a libnautilus to be
used by the desktop part of nautilus, extensions have access to all
the API of nautilus. We will think in future how this can be handled if
we want.
So for now, merge the libnautilus-private into src, and let's rethink
a better logic to split the code and the private parts of nautilus than
what we had.
Thanks a lot to Rafael Fonseca for helping in get this done.
https://bugzilla.gnome.org/show_bug.cgi?id=765543
|
