2015-05-05 06:35:04 +00:00
|
|
|
"use strict";
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
describe("Zotero.CollectionTree", function() {
|
2016-03-11 12:36:36 +00:00
|
|
|
var win, zp, cv, userLibraryID;
|
2015-04-30 21:06:38 +00:00
|
|
|
|
|
|
|
before(function* () {
|
|
|
|
win = yield loadZoteroPane();
|
2015-06-09 05:29:26 +00:00
|
|
|
zp = win.ZoteroPane;
|
|
|
|
cv = zp.collectionsView;
|
2016-03-11 12:36:36 +00:00
|
|
|
userLibraryID = Zotero.Libraries.userLibraryID;
|
2015-04-30 21:06:38 +00:00
|
|
|
});
|
2015-05-22 23:15:21 +00:00
|
|
|
beforeEach(function () {
|
2015-05-25 02:57:46 +00:00
|
|
|
// TODO: Add a selectCollection() function and select a collection instead?
|
|
|
|
return selectLibrary(win);
|
2015-05-22 23:15:21 +00:00
|
|
|
})
|
2015-04-30 21:06:38 +00:00
|
|
|
after(function () {
|
2015-05-04 06:00:52 +00:00
|
|
|
win.close();
|
2015-04-30 21:06:38 +00:00
|
|
|
});
|
|
|
|
|
2016-03-11 12:34:57 +00:00
|
|
|
describe("#refresh()", function () {
|
2019-06-10 06:37:54 +00:00
|
|
|
it("should show Duplicate Items and Unfiled Items by default and shouldn't show Retracted Items", function* () {
|
2016-03-11 12:34:57 +00:00
|
|
|
Zotero.Prefs.clear('duplicateLibraries');
|
|
|
|
Zotero.Prefs.clear('unfiledLibraries');
|
2019-06-10 06:37:54 +00:00
|
|
|
Zotero.Prefs.clear('retractedLibraries');
|
2016-03-11 12:34:57 +00:00
|
|
|
yield cv.refresh();
|
2016-03-14 00:31:15 +00:00
|
|
|
assert.ok(cv.getRowIndexByID("D" + userLibraryID));
|
|
|
|
assert.ok(cv.getRowIndexByID("U" + userLibraryID));
|
2019-06-10 06:37:54 +00:00
|
|
|
assert.isFalse(cv.getRowIndexByID("R" + userLibraryID));
|
2016-03-11 12:34:57 +00:00
|
|
|
});
|
|
|
|
|
2019-06-10 06:37:54 +00:00
|
|
|
it("shouldn't show virtual collections if hidden", function* () {
|
2016-07-01 09:48:19 +00:00
|
|
|
Zotero.Prefs.set('duplicateLibraries', `{"${userLibraryID}": false}`);
|
|
|
|
Zotero.Prefs.set('unfiledLibraries', `{"${userLibraryID}": false}`);
|
2019-06-10 06:37:54 +00:00
|
|
|
Zotero.Prefs.set('retractedLibraries', `{"${userLibraryID}": false}`);
|
2016-03-11 12:34:57 +00:00
|
|
|
yield cv.refresh();
|
2016-03-12 10:03:47 +00:00
|
|
|
assert.isFalse(cv.getRowIndexByID("D" + userLibraryID));
|
|
|
|
assert.isFalse(cv.getRowIndexByID("U" + userLibraryID));
|
2019-06-10 06:37:54 +00:00
|
|
|
assert.isFalse(cv.getRowIndexByID("R" + userLibraryID));
|
2016-03-11 12:34:57 +00:00
|
|
|
});
|
2016-07-02 05:26:44 +00:00
|
|
|
|
|
|
|
it("should maintain open state of group", function* () {
|
|
|
|
var group1 = yield createGroup();
|
|
|
|
var group2 = yield createGroup();
|
|
|
|
var group1Row = cv.getRowIndexByID(group1.treeViewID);
|
|
|
|
var group2Row = cv.getRowIndexByID(group2.treeViewID);
|
|
|
|
|
|
|
|
// Open group 1 and close group 2
|
|
|
|
if (!cv.isContainerOpen(group1Row)) {
|
|
|
|
yield cv.toggleOpenState(group1Row);
|
|
|
|
}
|
|
|
|
if (cv.isContainerOpen(group2Row)) {
|
|
|
|
yield cv.toggleOpenState(group2Row);
|
|
|
|
}
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
|
2016-07-02 05:26:44 +00:00
|
|
|
cv._saveOpenStates();
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
// #_saveOpenStates is debounced
|
|
|
|
yield Zotero.Promise.delay(500);
|
2016-07-02 05:26:44 +00:00
|
|
|
|
|
|
|
group1Row = cv.getRowIndexByID(group1.treeViewID);
|
|
|
|
group2Row = cv.getRowIndexByID(group2.treeViewID);
|
|
|
|
|
|
|
|
yield cv.refresh();
|
|
|
|
|
|
|
|
// Group rows shouldn't have changed
|
|
|
|
assert.equal(cv.getRowIndexByID(group1.treeViewID), group1Row);
|
|
|
|
assert.equal(cv.getRowIndexByID(group2.treeViewID), group2Row);
|
|
|
|
// Group open states shouldn't have changed
|
|
|
|
assert.isTrue(cv.isContainerOpen(group1Row));
|
|
|
|
assert.isFalse(cv.isContainerOpen(group2Row));
|
|
|
|
});
|
2017-09-10 07:18:25 +00:00
|
|
|
|
|
|
|
it("should update associated item tree view", function* () {
|
|
|
|
var collection = yield createDataObject('collection');
|
|
|
|
var item = yield createDataObject('item', { collections: [collection.id] });
|
|
|
|
yield cv.reload();
|
|
|
|
yield cv.selectCollection(collection.id);
|
|
|
|
yield cv.selectItem(item.id);
|
|
|
|
});
|
2016-03-11 12:34:57 +00:00
|
|
|
});
|
|
|
|
|
2015-05-22 18:40:04 +00:00
|
|
|
describe("collapse/expand", function () {
|
|
|
|
it("should close and open My Library repeatedly", function* () {
|
2016-03-11 12:36:36 +00:00
|
|
|
yield cv.selectLibrary(userLibraryID);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
var row = cv.selection.focused;
|
2015-05-22 18:40:04 +00:00
|
|
|
|
2016-03-11 12:36:36 +00:00
|
|
|
cv.collapseLibrary(userLibraryID);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
assert.equal(cv.selection.focused, row);
|
2015-05-22 18:40:04 +00:00
|
|
|
assert.isFalse(cv.isContainerOpen(row));
|
|
|
|
|
2016-03-11 12:36:36 +00:00
|
|
|
yield cv.expandLibrary(userLibraryID);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
assert.equal(cv.selection.focused, row);
|
2015-05-22 18:40:04 +00:00
|
|
|
assert.ok(cv.isContainerOpen(row));
|
|
|
|
|
2016-03-11 12:36:36 +00:00
|
|
|
cv.collapseLibrary(userLibraryID);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
assert.equal(cv.selection.focused, row);
|
2015-05-22 18:40:04 +00:00
|
|
|
assert.isFalse(cv.isContainerOpen(row));
|
|
|
|
|
2016-03-11 12:36:36 +00:00
|
|
|
yield cv.expandLibrary(userLibraryID);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
assert.equal(cv.selection.focused, row);
|
2015-05-22 18:40:04 +00:00
|
|
|
assert.ok(cv.isContainerOpen(row));
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
2016-05-07 08:02:42 +00:00
|
|
|
describe("#expandLibrary()", function () {
|
|
|
|
var libraryRow, col1, col2, col3;
|
|
|
|
|
|
|
|
before(function* () {
|
|
|
|
yield cv.selectLibrary(userLibraryID);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
libraryRow = cv.selection.focused;
|
2016-05-07 08:02:42 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
beforeEach(function* () {
|
|
|
|
// My Library
|
|
|
|
// - A
|
|
|
|
// - B
|
|
|
|
// - C
|
|
|
|
col1 = yield createDataObject('collection');
|
|
|
|
col2 = yield createDataObject('collection', { parentID: col1.id });
|
|
|
|
col3 = yield createDataObject('collection', { parentID: col2.id });
|
|
|
|
});
|
|
|
|
|
|
|
|
it("should open a library and respect stored container state", function* () {
|
|
|
|
// Collapse B
|
2016-05-09 16:33:12 +00:00
|
|
|
yield cv.toggleOpenState(cv.getRowIndexByID(col2.treeViewID));
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
cv._saveOpenStates();
|
|
|
|
// #_saveOpenStates is debounced
|
|
|
|
yield Zotero.Promise.delay(500);
|
2016-05-07 08:02:42 +00:00
|
|
|
|
|
|
|
// Close and reopen library
|
|
|
|
yield cv.toggleOpenState(libraryRow);
|
|
|
|
yield cv.expandLibrary(userLibraryID);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
|
|
|
|
assert.isTrue(cv.isContainerOpen(libraryRow));
|
|
|
|
assert.isTrue(cv.isContainerOpen(cv.getRowIndexByID(col1.treeViewID)));
|
|
|
|
assert.isFalse(cv.isContainerOpen(cv.getRowIndexByID(col2.treeViewID)));
|
2016-05-07 08:02:42 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
it("should open a library and all subcollections in recursive mode", function* () {
|
2016-05-09 16:33:12 +00:00
|
|
|
yield cv.toggleOpenState(cv.getRowIndexByID(col2.treeViewID));
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
cv._saveOpenStates();
|
|
|
|
// #_saveOpenStates is debounced
|
|
|
|
yield Zotero.Promise.delay(500);
|
2016-05-07 08:02:42 +00:00
|
|
|
|
|
|
|
// Close and reopen library
|
|
|
|
yield cv.toggleOpenState(libraryRow);
|
|
|
|
yield cv.expandLibrary(userLibraryID, true);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
|
|
|
|
assert.isTrue(cv.isContainerOpen(cv.getRowIndexByID(col1.treeViewID)));
|
|
|
|
assert.isTrue(cv.isContainerOpen(cv.getRowIndexByID(col2.treeViewID)));
|
2016-05-07 08:02:42 +00:00
|
|
|
});
|
2016-07-18 21:15:48 +00:00
|
|
|
|
|
|
|
it("should open a group and show top-level collections", function* () {
|
|
|
|
var group = yield createGroup();
|
|
|
|
var libraryID = group.libraryID;
|
|
|
|
var col1 = yield createDataObject('collection', { libraryID });
|
|
|
|
var col2 = yield createDataObject('collection', { libraryID });
|
|
|
|
var col3 = yield createDataObject('collection', { libraryID });
|
|
|
|
var col4 = yield createDataObject('collection', { libraryID, parentID: col1.id });
|
|
|
|
var col5 = yield createDataObject('collection', { libraryID, parentID: col4.id });
|
|
|
|
|
|
|
|
// Close everything
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield Zotero.Promise.all([col4, col1, group]
|
|
|
|
.map(o => cv.toggleOpenState(cv.getRowIndexByID(o.treeViewID), false)));
|
2016-07-18 21:15:48 +00:00
|
|
|
|
|
|
|
yield cv.expandLibrary(libraryID);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
|
2016-07-18 21:15:48 +00:00
|
|
|
assert.isNumber(cv.getRowIndexByID(col1.treeViewID));
|
|
|
|
assert.isNumber(cv.getRowIndexByID(col2.treeViewID));
|
|
|
|
assert.isNumber(cv.getRowIndexByID(col3.treeViewID));
|
|
|
|
assert.isFalse(cv.getRowIndexByID(col4.treeViewID));
|
|
|
|
assert.isFalse(cv.getRowIndexByID(col5.treeViewID));
|
|
|
|
});
|
2016-05-07 08:02:42 +00:00
|
|
|
});
|
|
|
|
|
2015-06-01 19:31:57 +00:00
|
|
|
describe("#expandToCollection()", function () {
|
|
|
|
it("should expand a collection to a subcollection", function* () {
|
|
|
|
var collection1 = yield createDataObject('collection');
|
|
|
|
var collection2 = createUnsavedDataObject('collection');
|
|
|
|
collection2.parentID = collection1.id;
|
2015-06-02 07:33:05 +00:00
|
|
|
yield collection2.saveTx({
|
2015-06-01 19:31:57 +00:00
|
|
|
skipSelect: true
|
|
|
|
});
|
|
|
|
var row = cv.getRowIndexByID("C" + collection1.id);
|
|
|
|
assert.isFalse(cv.isContainerOpen(row));
|
|
|
|
|
|
|
|
yield cv.expandToCollection(collection2.id);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
cv.forceUpdate();
|
2015-06-01 19:31:57 +00:00
|
|
|
|
|
|
|
// Make sure parent row position hasn't changed
|
|
|
|
assert.equal(cv.getRowIndexByID("C" + collection1.id), row);
|
|
|
|
// Parent should have been opened
|
|
|
|
assert.isTrue(cv.isContainerOpen(row));
|
|
|
|
})
|
|
|
|
})
|
|
|
|
|
2015-05-25 05:43:07 +00:00
|
|
|
describe("#selectByID()", function () {
|
2015-05-25 02:04:40 +00:00
|
|
|
it("should select the trash", function* () {
|
2015-06-08 08:12:45 +00:00
|
|
|
yield cv.selectByID("T1");
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
var row = cv.selection.focused;
|
2015-06-08 08:12:45 +00:00
|
|
|
var treeRow = cv.getRow(row);
|
2015-05-25 02:04:40 +00:00
|
|
|
assert.ok(treeRow.isTrash());
|
2016-03-11 12:36:36 +00:00
|
|
|
assert.equal(treeRow.ref.libraryID, userLibraryID);
|
2015-05-25 02:04:40 +00:00
|
|
|
})
|
|
|
|
})
|
|
|
|
|
2015-05-25 05:43:07 +00:00
|
|
|
describe("#selectWait()", function () {
|
|
|
|
it("shouldn't hang if row is already selected", function* () {
|
2016-03-11 12:36:36 +00:00
|
|
|
var row = cv.getRowIndexByID("T" + userLibraryID);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield cv.selectWait(row);
|
2015-05-25 05:43:07 +00:00
|
|
|
yield Zotero.Promise.delay(50);
|
2015-06-08 08:12:45 +00:00
|
|
|
yield cv.selectWait(row);
|
2015-05-25 05:43:07 +00:00
|
|
|
})
|
|
|
|
})
|
|
|
|
|
2015-04-30 21:06:38 +00:00
|
|
|
describe("#notify()", function () {
|
|
|
|
it("should select a new collection", function* () {
|
|
|
|
// Create collection
|
|
|
|
var collection = new Zotero.Collection;
|
|
|
|
collection.name = "Select new collection";
|
2015-05-10 08:20:47 +00:00
|
|
|
var id = yield collection.saveTx();
|
2015-04-30 21:06:38 +00:00
|
|
|
|
|
|
|
// New collection should be selected
|
2015-06-08 08:12:45 +00:00
|
|
|
var selected = cv.getSelectedCollection(true);
|
2015-04-30 21:06:38 +00:00
|
|
|
assert.equal(selected, id);
|
|
|
|
});
|
|
|
|
|
|
|
|
it("shouldn't select a new collection if skipNotifier is passed", function* () {
|
|
|
|
// Create collection with skipNotifier flag
|
|
|
|
var collection = new Zotero.Collection;
|
|
|
|
collection.name = "No select on skipNotifier";
|
2015-05-10 08:20:47 +00:00
|
|
|
var id = yield collection.saveTx({
|
2015-04-30 21:06:38 +00:00
|
|
|
skipNotifier: true
|
|
|
|
});
|
|
|
|
|
|
|
|
// Library should still be selected
|
2016-03-11 12:36:36 +00:00
|
|
|
assert.equal(cv.getSelectedLibraryID(), userLibraryID);
|
2015-04-30 21:06:38 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
it("shouldn't select a new collection if skipSelect is passed", function* () {
|
|
|
|
// Create collection with skipSelect flag
|
|
|
|
var collection = new Zotero.Collection;
|
|
|
|
collection.name = "No select on skipSelect";
|
2015-05-10 08:20:47 +00:00
|
|
|
var id = yield collection.saveTx({
|
2015-04-30 21:06:38 +00:00
|
|
|
skipSelect: true
|
|
|
|
});
|
|
|
|
|
|
|
|
// Library should still be selected
|
2016-03-11 12:36:36 +00:00
|
|
|
assert.equal(cv.getSelectedLibraryID(), userLibraryID);
|
2015-04-30 21:06:38 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
it("shouldn't select a modified collection", function* () {
|
|
|
|
// Create collection
|
|
|
|
var collection = new Zotero.Collection;
|
|
|
|
collection.name = "No select on modify";
|
2015-05-10 08:20:47 +00:00
|
|
|
var id = yield collection.saveTx();
|
2015-04-30 21:06:38 +00:00
|
|
|
|
2015-05-25 02:57:46 +00:00
|
|
|
yield selectLibrary(win);
|
2015-04-30 21:06:38 +00:00
|
|
|
|
|
|
|
collection.name = "No select on modify 2";
|
2015-05-10 08:20:47 +00:00
|
|
|
yield collection.saveTx();
|
2015-04-30 21:06:38 +00:00
|
|
|
|
|
|
|
// Modified collection should not be selected
|
2016-03-11 12:36:36 +00:00
|
|
|
assert.equal(cv.getSelectedLibraryID(), userLibraryID);
|
2015-04-30 21:06:38 +00:00
|
|
|
});
|
|
|
|
|
2015-06-09 05:29:26 +00:00
|
|
|
it("should maintain selection on a selected modified collection", function* () {
|
2015-04-30 21:06:38 +00:00
|
|
|
// Create collection
|
|
|
|
var collection = new Zotero.Collection;
|
|
|
|
collection.name = "Reselect on modify";
|
2015-05-10 08:20:47 +00:00
|
|
|
var id = yield collection.saveTx();
|
2015-04-30 21:06:38 +00:00
|
|
|
|
2015-06-08 08:12:45 +00:00
|
|
|
var selected = cv.getSelectedCollection(true);
|
2015-04-30 21:06:38 +00:00
|
|
|
assert.equal(selected, id);
|
|
|
|
|
|
|
|
collection.name = "Reselect on modify 2";
|
2015-05-10 08:20:47 +00:00
|
|
|
yield collection.saveTx();
|
2015-04-30 21:06:38 +00:00
|
|
|
|
|
|
|
// Modified collection should still be selected
|
2015-06-08 08:12:45 +00:00
|
|
|
selected = cv.getSelectedCollection(true);
|
2015-04-30 21:06:38 +00:00
|
|
|
assert.equal(selected, id);
|
|
|
|
});
|
2015-05-07 22:18:48 +00:00
|
|
|
|
2016-03-25 20:48:33 +00:00
|
|
|
it("should update the editability of the current view", function* () {
|
|
|
|
var group = yield createGroup({
|
|
|
|
editable: false,
|
|
|
|
filesEditable: false
|
|
|
|
});
|
|
|
|
yield cv.selectLibrary(group.libraryID);
|
|
|
|
yield waitForItemsLoad(win);
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
assert.isFalse(zp.getCollectionTreeRow().editable);
|
2016-03-25 20:48:33 +00:00
|
|
|
var cmd = win.document.getElementById('cmd_zotero_newStandaloneNote');
|
|
|
|
assert.isTrue(cmd.getAttribute('disabled') == 'true');
|
|
|
|
|
|
|
|
group.editable = true;
|
|
|
|
yield group.saveTx();
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
assert.isTrue(zp.getCollectionTreeRow().editable);
|
2016-03-25 20:48:33 +00:00
|
|
|
assert.isFalse(cmd.getAttribute('disabled') == 'true');
|
|
|
|
});
|
|
|
|
|
2015-06-09 05:29:26 +00:00
|
|
|
it("should re-sort a modified collection", function* () {
|
|
|
|
var prefix = Zotero.Utilities.randomString() + " ";
|
|
|
|
var collectionA = yield createDataObject('collection', { name: prefix + "A" });
|
|
|
|
var collectionB = yield createDataObject('collection', { name: prefix + "B" });
|
|
|
|
|
|
|
|
var aRow = cv.getRowIndexByID("C" + collectionA.id);
|
|
|
|
var aRowOriginal = aRow;
|
|
|
|
var bRow = cv.getRowIndexByID("C" + collectionB.id);
|
|
|
|
assert.equal(bRow, aRow + 1);
|
|
|
|
|
|
|
|
collectionA.name = prefix + "C";
|
|
|
|
yield collectionA.saveTx();
|
|
|
|
|
|
|
|
var aRow = cv.getRowIndexByID("C" + collectionA.id);
|
|
|
|
var bRow = cv.getRowIndexByID("C" + collectionB.id);
|
|
|
|
assert.equal(bRow, aRowOriginal);
|
|
|
|
assert.equal(aRow, bRow + 1);
|
|
|
|
})
|
|
|
|
|
|
|
|
it("should re-sort a modified search", function* () {
|
|
|
|
var prefix = Zotero.Utilities.randomString() + " ";
|
|
|
|
var searchA = yield createDataObject('search', { name: prefix + "A" });
|
|
|
|
var searchB = yield createDataObject('search', { name: prefix + "B" });
|
|
|
|
|
|
|
|
var aRow = cv.getRowIndexByID("S" + searchA.id);
|
|
|
|
var aRowOriginal = aRow;
|
|
|
|
var bRow = cv.getRowIndexByID("S" + searchB.id);
|
|
|
|
assert.equal(bRow, aRow + 1);
|
|
|
|
|
|
|
|
searchA.name = prefix + "C";
|
|
|
|
yield searchA.saveTx();
|
|
|
|
|
|
|
|
var aRow = cv.getRowIndexByID("S" + searchA.id);
|
|
|
|
var bRow = cv.getRowIndexByID("S" + searchB.id);
|
|
|
|
assert.equal(bRow, aRowOriginal);
|
|
|
|
assert.equal(aRow, bRow + 1);
|
|
|
|
})
|
|
|
|
|
2016-02-21 10:19:01 +00:00
|
|
|
|
2017-02-27 09:51:04 +00:00
|
|
|
it("should add collection after parent's subcollection and before non-sibling", function* () {
|
|
|
|
var c0 = yield createDataObject('collection', { name: "Test" });
|
|
|
|
var rootRow = cv.getRowIndexByID(c0.treeViewID);
|
|
|
|
|
|
|
|
var c1 = yield createDataObject('collection', { name: "1", parentID: c0.id });
|
|
|
|
var c2 = yield createDataObject('collection', { name: "2", parentID: c0.id });
|
|
|
|
var c3 = yield createDataObject('collection', { name: "3", parentID: c1.id });
|
|
|
|
var c4 = yield createDataObject('collection', { name: "4", parentID: c3.id });
|
|
|
|
var c5 = yield createDataObject('collection', { name: "5", parentID: c1.id });
|
|
|
|
|
|
|
|
assert.equal(cv.getRowIndexByID(c1.treeViewID), rootRow + 1);
|
|
|
|
|
|
|
|
assert.isAbove(cv.getRowIndexByID(c1.treeViewID), cv.getRowIndexByID(c0.treeViewID));
|
|
|
|
assert.isAbove(cv.getRowIndexByID(c2.treeViewID), cv.getRowIndexByID(c0.treeViewID));
|
|
|
|
|
|
|
|
assert.isAbove(cv.getRowIndexByID(c3.treeViewID), cv.getRowIndexByID(c1.treeViewID));
|
|
|
|
assert.isAbove(cv.getRowIndexByID(c5.treeViewID), cv.getRowIndexByID(c1.treeViewID));
|
|
|
|
assert.isBelow(cv.getRowIndexByID(c5.treeViewID), cv.getRowIndexByID(c2.treeViewID));
|
|
|
|
|
|
|
|
assert.equal(cv.getRowIndexByID(c4.treeViewID), cv.getRowIndexByID(c3.treeViewID) + 1);
|
|
|
|
});
|
|
|
|
|
|
|
|
|
2016-02-21 10:19:01 +00:00
|
|
|
it("should add multiple collections", function* () {
|
|
|
|
var col1, col2;
|
2020-07-05 10:20:01 +00:00
|
|
|
yield Zotero.DB.executeTransaction(async function () {
|
2016-02-21 10:19:01 +00:00
|
|
|
col1 = createUnsavedDataObject('collection');
|
|
|
|
col2 = createUnsavedDataObject('collection');
|
2020-07-05 10:20:01 +00:00
|
|
|
await col1.save();
|
|
|
|
await col2.save();
|
2016-02-21 10:19:01 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
var aRow = cv.getRowIndexByID("C" + col1.id);
|
|
|
|
var bRow = cv.getRowIndexByID("C" + col2.id);
|
|
|
|
assert.isAbove(aRow, 0);
|
|
|
|
assert.isAbove(bRow, 0);
|
|
|
|
// skipSelect is implied for multiple collections, so library should still be selected
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
assert.equal(cv.selection.focused, 0);
|
2016-02-21 10:19:01 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
|
2015-06-09 05:29:26 +00:00
|
|
|
it("shouldn't refresh the items list when a collection is modified", function* () {
|
|
|
|
var collection = yield createDataObject('collection');
|
|
|
|
yield waitForItemsLoad(win);
|
|
|
|
var itemsView = zp.itemsView;
|
|
|
|
|
|
|
|
collection.name = "New Name";
|
|
|
|
yield collection.saveTx();
|
|
|
|
|
|
|
|
yield waitForItemsLoad(win);
|
|
|
|
assert.equal(zp.itemsView, itemsView);
|
|
|
|
})
|
|
|
|
|
2015-05-07 22:18:48 +00:00
|
|
|
it("should add a saved search after collections", function* () {
|
|
|
|
var collection = new Zotero.Collection;
|
|
|
|
collection.name = "Test";
|
2015-05-10 08:20:47 +00:00
|
|
|
var collectionID = yield collection.saveTx();
|
2015-05-07 22:18:48 +00:00
|
|
|
|
|
|
|
var search = new Zotero.Search;
|
|
|
|
search.name = "A Test Search";
|
|
|
|
search.addCondition('title', 'contains', 'test');
|
2015-05-10 08:20:47 +00:00
|
|
|
var searchID = yield search.saveTx();
|
2015-05-07 22:18:48 +00:00
|
|
|
|
|
|
|
var collectionRow = cv._rowMap["C" + collectionID];
|
|
|
|
var searchRow = cv._rowMap["S" + searchID];
|
2016-03-11 12:36:36 +00:00
|
|
|
var duplicatesRow = cv._rowMap["D" + userLibraryID];
|
|
|
|
var unfiledRow = cv._rowMap["U" + userLibraryID];
|
2015-05-07 22:18:48 +00:00
|
|
|
|
|
|
|
assert.isAbove(searchRow, collectionRow);
|
|
|
|
// If there's a duplicates row or an unfiled row, add before those.
|
|
|
|
// Otherwise, add before the trash
|
|
|
|
if (duplicatesRow !== undefined) {
|
|
|
|
assert.isBelow(searchRow, duplicatesRow);
|
|
|
|
}
|
|
|
|
else if (unfiledRow !== undefined) {
|
|
|
|
assert.isBelow(searchRow, unfiledRow);
|
|
|
|
}
|
|
|
|
else {
|
2016-03-11 12:36:36 +00:00
|
|
|
var trashRow = cv._rowMap["T" + userLibraryID];
|
2015-05-07 22:18:48 +00:00
|
|
|
assert.isBelow(searchRow, trashRow);
|
|
|
|
}
|
|
|
|
})
|
2015-06-08 08:04:38 +00:00
|
|
|
|
2015-07-19 21:08:36 +00:00
|
|
|
it("shouldn't select a new group", function* () {
|
|
|
|
var group = yield createGroup();
|
|
|
|
// Library should still be selected
|
2016-03-11 12:36:36 +00:00
|
|
|
assert.equal(cv.getSelectedLibraryID(), userLibraryID);
|
2015-07-19 21:08:36 +00:00
|
|
|
})
|
|
|
|
|
2015-06-08 08:04:38 +00:00
|
|
|
it("should remove a group and all children", function* () {
|
|
|
|
// Make sure Group Libraries separator and header exist already,
|
|
|
|
// since otherwise they'll interfere with the count
|
|
|
|
yield getGroup();
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
var originalRowCount = cv._rows.length;
|
2015-06-08 08:04:38 +00:00
|
|
|
|
|
|
|
var group = yield createGroup();
|
|
|
|
yield createDataObject('collection', { libraryID: group.libraryID });
|
|
|
|
var c = yield createDataObject('collection', { libraryID: group.libraryID });
|
|
|
|
yield createDataObject('collection', { libraryID: group.libraryID, parentID: c.id });
|
|
|
|
yield createDataObject('collection', { libraryID: group.libraryID });
|
|
|
|
yield createDataObject('collection', { libraryID: group.libraryID });
|
|
|
|
|
2016-07-01 09:48:19 +00:00
|
|
|
// Group, collections, Duplicates, Unfiled, and trash
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
assert.equal(cv._rows.length, originalRowCount + 9);
|
2015-06-08 08:04:38 +00:00
|
|
|
|
2017-02-24 06:34:22 +00:00
|
|
|
// Select group
|
|
|
|
yield cv.selectLibrary(group.libraryID);
|
|
|
|
yield waitForItemsLoad(win);
|
|
|
|
|
2015-06-08 08:04:38 +00:00
|
|
|
var spy = sinon.spy(cv, "refresh");
|
|
|
|
try {
|
|
|
|
yield group.eraseTx();
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
assert.equal(cv._rows.length, originalRowCount);
|
2015-06-08 08:04:38 +00:00
|
|
|
// Make sure the tree wasn't refreshed
|
|
|
|
sinon.assert.notCalled(spy);
|
|
|
|
}
|
|
|
|
finally {
|
|
|
|
spy.restore();
|
|
|
|
}
|
|
|
|
})
|
2016-01-13 13:13:29 +00:00
|
|
|
|
|
|
|
it("should select a new feed", function* () {
|
|
|
|
var feed = yield createFeed();
|
2017-06-16 09:56:06 +00:00
|
|
|
// Feed should be selected
|
2016-01-13 13:13:29 +00:00
|
|
|
assert.equal(cv.getSelectedLibraryID(), feed.id);
|
2017-06-16 09:56:06 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
it("shouldn't select a new feed with skipSelect: true", function* () {
|
|
|
|
var feed = yield createFeed({
|
|
|
|
saveOptions: {
|
|
|
|
skipSelect: true
|
|
|
|
}
|
|
|
|
});
|
|
|
|
// Library should still be selected
|
|
|
|
assert.equal(cv.getSelectedLibraryID(), userLibraryID);
|
|
|
|
});
|
2016-01-13 13:13:29 +00:00
|
|
|
|
2016-06-28 18:29:15 +00:00
|
|
|
it("should remove deleted feed", function* () {
|
|
|
|
var feed = yield createFeed();
|
|
|
|
yield cv.selectLibrary(feed.libraryID);
|
|
|
|
waitForDialog();
|
|
|
|
var id = feed.treeViewID;
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
let promise = waitForCollectionTree(win);
|
2016-06-28 18:29:15 +00:00
|
|
|
yield win.ZoteroPane.deleteSelectedCollection();
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield promise;
|
2016-06-28 18:29:15 +00:00
|
|
|
assert.isFalse(cv.getRowIndexByID(id))
|
|
|
|
})
|
2017-10-07 09:05:34 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
describe("#selectItem()", function () {
|
|
|
|
it("should switch to library root if item isn't in collection", async function () {
|
|
|
|
var item = await createDataObject('item');
|
|
|
|
var collection = await createDataObject('collection');
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
Zotero.debug(zp.itemsView._rows);
|
2017-10-07 09:05:34 +00:00
|
|
|
await cv.selectItem(item.id);
|
|
|
|
await waitForItemsLoad(win);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
assert.equal(cv.selection.focused, 0);
|
|
|
|
assert.sameMembers(zp.itemsView.getSelectedItems(), [item]);
|
2019-02-23 22:28:44 +00:00
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
describe("#selectItems()", function () {
|
|
|
|
it("should switch to library root if at least one item isn't in the current collection", async function () {
|
|
|
|
var collection = await createDataObject('collection');
|
|
|
|
var item1 = await createDataObject('item', { collections: [collection.id] });
|
|
|
|
var item2 = await createDataObject('item');
|
|
|
|
await cv.selectItems([item1.id, item2.id]);
|
|
|
|
await waitForItemsLoad(win);
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
assert.equal(cv.selection.focused, 0);
|
2019-02-23 22:28:44 +00:00
|
|
|
assert.sameMembers(zp.itemsView.getSelectedItems(true), [item1.id, item2.id]);
|
2017-10-07 09:05:34 +00:00
|
|
|
});
|
|
|
|
});
|
2015-05-22 23:15:21 +00:00
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
describe("#onDrop()", function () {
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
/**
|
|
|
|
* Simulate a drag and drop
|
|
|
|
*
|
2015-08-08 21:26:42 +00:00
|
|
|
* @param {String} type - 'item' or 'collection'
|
|
|
|
* @param {String|Object} targetRow - Tree row id (e.g., "L123"), or { row, orient }
|
|
|
|
* @param {Integer[]} collectionIDs
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
* @param {Promise} [promise] - If a promise is provided, it will be waited for and its
|
2015-08-08 21:26:42 +00:00
|
|
|
* value returned after the drag. Otherwise, an 'add' event will be waited for, and
|
|
|
|
* an object with 'ids' and 'extraData' will be returned.
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
*/
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
var onDrop = Zotero.Promise.coroutine(function* (objectType, targetRow, ids, promise, action = 'copy') {
|
2015-08-08 21:26:42 +00:00
|
|
|
if (typeof targetRow == 'string') {
|
|
|
|
var row = cv.getRowIndexByID(targetRow);
|
|
|
|
var orient = 0;
|
|
|
|
}
|
|
|
|
else {
|
|
|
|
var { row, orient } = targetRow;
|
|
|
|
}
|
2015-05-22 23:15:21 +00:00
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
Zotero.DragDrop.currentDragSource = objectType == "item" && zp.itemsView.collectionTreeRow;
|
|
|
|
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
if (!promise) {
|
2015-08-08 21:26:42 +00:00
|
|
|
promise = waitForNotifierEvent("add", objectType);
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
}
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield cv.onDrop({
|
|
|
|
persist: () => 0,
|
|
|
|
target: {ownerDocument: {defaultView: win}},
|
|
|
|
dataTransfer: {
|
|
|
|
dropEffect: action,
|
|
|
|
effectAllowed: action,
|
|
|
|
types: {
|
|
|
|
contains: function (type) {
|
|
|
|
return type == `zotero/${objectType}`;
|
|
|
|
}
|
|
|
|
},
|
|
|
|
getData: function (type) {
|
|
|
|
if (type == `zotero/${objectType}`) {
|
|
|
|
return ids.join(",");
|
|
|
|
}
|
2015-05-22 23:15:21 +00:00
|
|
|
}
|
|
|
|
}
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
}, row);
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
|
|
|
|
// Add observer to wait for add
|
|
|
|
var result = yield promise;
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
Zotero.DragDrop.currentDragSource = null;
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
return result;
|
|
|
|
});
|
|
|
|
|
|
|
|
|
2015-08-08 21:26:42 +00:00
|
|
|
var canDrop = Zotero.Promise.coroutine(function* (type, targetRowID, ids) {
|
2015-06-08 08:12:45 +00:00
|
|
|
var row = cv.getRowIndexByID(targetRowID);
|
2015-05-22 23:15:21 +00:00
|
|
|
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
var dt = {
|
2015-05-22 23:15:21 +00:00
|
|
|
dropEffect: 'copy',
|
|
|
|
effectAllowed: 'copy',
|
|
|
|
types: {
|
|
|
|
contains: function (type) {
|
2015-08-08 21:26:42 +00:00
|
|
|
return type == `zotero/${type}`;
|
2015-05-22 23:15:21 +00:00
|
|
|
}
|
|
|
|
},
|
|
|
|
getData: function (type) {
|
2015-08-08 21:26:42 +00:00
|
|
|
if (type == `zotero/${type}`) {
|
|
|
|
return ids.join(",");
|
2015-05-22 23:15:21 +00:00
|
|
|
}
|
|
|
|
}
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
};
|
2015-06-08 08:12:45 +00:00
|
|
|
var canDrop = cv.canDropCheck(row, 0, dt);
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
if (canDrop) {
|
2015-06-08 08:12:45 +00:00
|
|
|
canDrop = yield cv.canDropCheckAsync(row, 0, dt);
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
}
|
|
|
|
return canDrop;
|
|
|
|
});
|
|
|
|
|
2015-08-08 21:26:42 +00:00
|
|
|
describe("with items", function () {
|
|
|
|
it("should add an item to a collection", function* () {
|
|
|
|
var collection = yield createDataObject('collection', false, { skipSelect: true });
|
|
|
|
var item = yield createDataObject('item', false, { skipSelect: true });
|
|
|
|
|
|
|
|
// Add observer to wait for collection add
|
|
|
|
var deferred = Zotero.Promise.defer();
|
|
|
|
var observerID = Zotero.Notifier.registerObserver({
|
|
|
|
notify: function (event, type, ids, extraData) {
|
|
|
|
if (type == 'collection-item' && event == 'add'
|
|
|
|
&& ids[0] == collection.id + "-" + item.id) {
|
|
|
|
setTimeout(function () {
|
|
|
|
deferred.resolve();
|
|
|
|
});
|
|
|
|
}
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
}
|
2015-08-08 21:26:42 +00:00
|
|
|
}, 'collection-item', 'test');
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield onDrop('item', 'C' + collection.id, [item.id], deferred.promise);
|
2015-08-08 21:26:42 +00:00
|
|
|
|
|
|
|
Zotero.Notifier.unregisterObserver(observerID);
|
|
|
|
|
|
|
|
yield cv.selectCollection(collection.id);
|
|
|
|
yield waitForItemsLoad(win);
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
var itemsView = win.ZoteroPane.itemsView;
|
2015-08-08 21:26:42 +00:00
|
|
|
assert.equal(itemsView.rowCount, 1);
|
|
|
|
var treeRow = itemsView.getRow(0);
|
|
|
|
assert.equal(treeRow.ref.id, item.id);
|
|
|
|
})
|
|
|
|
|
2017-02-03 05:04:05 +00:00
|
|
|
it("should move an item from one collection to another", function* () {
|
|
|
|
var collection1 = yield createDataObject('collection');
|
|
|
|
yield waitForItemsLoad(win);
|
|
|
|
var collection2 = yield createDataObject('collection', false, { skipSelect: true });
|
|
|
|
var item = yield createDataObject('item', { collections: [collection1.id] });
|
|
|
|
|
|
|
|
// Add observer to wait for collection add
|
|
|
|
var deferred = Zotero.Promise.defer();
|
|
|
|
var observerID = Zotero.Notifier.registerObserver({
|
|
|
|
notify: function (event, type, ids, extraData) {
|
|
|
|
if (type == 'collection-item' && event == 'add'
|
|
|
|
&& ids[0] == collection2.id + "-" + item.id) {
|
|
|
|
setTimeout(function () {
|
|
|
|
deferred.resolve();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}, 'collection-item', 'test');
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
let promise = zp.itemsView.waitForSelect();
|
|
|
|
yield onDrop('item', 'C' + collection2.id, [item.id], deferred.promise, 'move');
|
|
|
|
yield promise;
|
2017-02-03 05:04:05 +00:00
|
|
|
|
|
|
|
Zotero.Notifier.unregisterObserver(observerID);
|
|
|
|
|
|
|
|
// Source collection should be empty
|
|
|
|
assert.equal(zp.itemsView.rowCount, 0);
|
|
|
|
|
|
|
|
yield cv.selectCollection(collection2.id);
|
|
|
|
yield waitForItemsLoad(win);
|
|
|
|
|
|
|
|
// Target collection should have item
|
|
|
|
assert.equal(zp.itemsView.rowCount, 1);
|
|
|
|
var treeRow = zp.itemsView.getRow(0);
|
|
|
|
assert.equal(treeRow.ref.id, item.id);
|
|
|
|
});
|
|
|
|
|
2017-04-12 04:56:37 +00:00
|
|
|
describe("My Publications", function () {
|
|
|
|
it("should add an item to My Publications", function* () {
|
2017-09-18 21:45:33 +00:00
|
|
|
// Remove other items in My Publications
|
|
|
|
var s = new Zotero.Search();
|
|
|
|
s.addCondition('libraryID', 'is', Zotero.Libraries.userLibraryID);
|
|
|
|
s.addCondition('publications', 'true');
|
|
|
|
var ids = yield s.search();
|
|
|
|
yield Zotero.Items.erase(ids);
|
|
|
|
|
2017-04-12 04:56:37 +00:00
|
|
|
var item = yield createDataObject('item', false, { skipSelect: true });
|
|
|
|
var libraryID = item.libraryID;
|
|
|
|
|
|
|
|
var stub = sinon.stub(zp, "showPublicationsWizard")
|
|
|
|
.returns({
|
|
|
|
includeNotes: false,
|
|
|
|
includeFiles: false,
|
|
|
|
keepRights: true
|
|
|
|
});
|
|
|
|
|
|
|
|
// Add observer to wait for item modification
|
|
|
|
var deferred = Zotero.Promise.defer();
|
|
|
|
var observerID = Zotero.Notifier.registerObserver({
|
|
|
|
notify: function (event, type, ids, extraData) {
|
|
|
|
if (type == 'item' && event == 'modify' && ids[0] == item.id) {
|
|
|
|
setTimeout(function () {
|
|
|
|
deferred.resolve();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}, 'item', 'test');
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield onDrop('item', 'P' + libraryID, [item.id], deferred.promise);
|
2017-04-12 04:56:37 +00:00
|
|
|
|
|
|
|
Zotero.Notifier.unregisterObserver(observerID);
|
|
|
|
stub.restore();
|
|
|
|
|
|
|
|
// Select publications and check for item
|
|
|
|
yield cv.selectByID("P" + libraryID);
|
|
|
|
yield waitForItemsLoad(win);
|
|
|
|
var itemsView = win.ZoteroPane.itemsView
|
|
|
|
assert.equal(itemsView.rowCount, 1);
|
|
|
|
var treeRow = itemsView.getRow(0);
|
|
|
|
assert.equal(treeRow.ref.id, item.id);
|
|
|
|
});
|
|
|
|
|
|
|
|
it("should add an item with a file attachment to My Publications", function* () {
|
|
|
|
var item = yield createDataObject('item', false, { skipSelect: true });
|
|
|
|
var attachment = yield importFileAttachment('test.png', { parentItemID: item.id });
|
|
|
|
var libraryID = item.libraryID;
|
|
|
|
|
|
|
|
var stub = sinon.stub(zp, "showPublicationsWizard")
|
|
|
|
.returns({
|
|
|
|
includeNotes: false,
|
|
|
|
includeFiles: true,
|
|
|
|
keepRights: true
|
|
|
|
});
|
|
|
|
|
|
|
|
// Add observer to wait for modify
|
|
|
|
var deferred = Zotero.Promise.defer();
|
|
|
|
var observerID = Zotero.Notifier.registerObserver({
|
|
|
|
notify: function (event, type, ids, extraData) {
|
|
|
|
if (type == 'item' && event == 'modify' && ids[0] == item.id) {
|
|
|
|
setTimeout(function () {
|
|
|
|
deferred.resolve();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}, 'item', 'test');
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield onDrop('item', 'P' + libraryID, [item.id], deferred.promise);
|
2017-04-12 04:56:37 +00:00
|
|
|
|
|
|
|
Zotero.Notifier.unregisterObserver(observerID);
|
|
|
|
stub.restore();
|
|
|
|
|
|
|
|
assert.isTrue(item.inPublications);
|
|
|
|
// File attachment should be in My Publications
|
|
|
|
assert.isTrue(attachment.inPublications);
|
|
|
|
});
|
|
|
|
|
|
|
|
it("should add an item with a linked URL attachment to My Publications", function* () {
|
|
|
|
var item = yield createDataObject('item', false, { skipSelect: true });
|
|
|
|
var attachment = yield Zotero.Attachments.linkFromURL({
|
|
|
|
parentItemID: item.id,
|
|
|
|
title: 'Test',
|
|
|
|
url: 'http://127.0.0.1/',
|
|
|
|
contentType: 'text/html'
|
|
|
|
});
|
|
|
|
var libraryID = item.libraryID;
|
|
|
|
|
|
|
|
var stub = sinon.stub(zp, "showPublicationsWizard")
|
|
|
|
.returns({
|
|
|
|
includeNotes: false,
|
|
|
|
includeFiles: false,
|
|
|
|
keepRights: true
|
|
|
|
});
|
|
|
|
|
|
|
|
// Add observer to wait for modify
|
|
|
|
var deferred = Zotero.Promise.defer();
|
|
|
|
var observerID = Zotero.Notifier.registerObserver({
|
|
|
|
notify: function (event, type, ids, extraData) {
|
|
|
|
if (type == 'item' && event == 'modify' && ids[0] == item.id) {
|
|
|
|
setTimeout(function () {
|
|
|
|
deferred.resolve();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}, 'item', 'test');
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield onDrop('item', 'P' + libraryID, [item.id], deferred.promise);
|
2017-04-12 04:56:37 +00:00
|
|
|
|
|
|
|
Zotero.Notifier.unregisterObserver(observerID);
|
|
|
|
stub.restore();
|
|
|
|
|
|
|
|
assert.isTrue(item.inPublications);
|
|
|
|
// Link attachment should be in My Publications
|
|
|
|
assert.isTrue(attachment.inPublications);
|
|
|
|
});
|
|
|
|
|
|
|
|
it("shouldn't add linked file attachment to My Publications", function* () {
|
|
|
|
var item = yield createDataObject('item', false, { skipSelect: true });
|
|
|
|
var attachment = yield Zotero.Attachments.linkFromFile({
|
|
|
|
parentItemID: item.id,
|
|
|
|
title: 'Test',
|
|
|
|
file: OS.Path.join(getTestDataDirectory().path, 'test.png'),
|
|
|
|
contentType: 'image/png'
|
|
|
|
});
|
|
|
|
var libraryID = item.libraryID;
|
|
|
|
|
|
|
|
var stub = sinon.stub(zp, "showPublicationsWizard")
|
|
|
|
.returns({
|
|
|
|
includeNotes: false,
|
|
|
|
includeFiles: false,
|
|
|
|
keepRights: true
|
|
|
|
});
|
|
|
|
|
|
|
|
// Add observer to wait for modify
|
|
|
|
var deferred = Zotero.Promise.defer();
|
|
|
|
var observerID = Zotero.Notifier.registerObserver({
|
|
|
|
notify: function (event, type, ids, extraData) {
|
|
|
|
if (type == 'item' && event == 'modify' && ids[0] == item.id) {
|
|
|
|
setTimeout(function () {
|
|
|
|
deferred.resolve();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}, 'item', 'test');
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield onDrop('item', 'P' + libraryID, [item.id], deferred.promise);
|
2017-04-12 04:56:37 +00:00
|
|
|
|
|
|
|
Zotero.Notifier.unregisterObserver(observerID);
|
|
|
|
stub.restore();
|
|
|
|
|
|
|
|
assert.isTrue(item.inPublications);
|
|
|
|
// Linked URL attachment shouldn't be in My Publications
|
|
|
|
assert.isFalse(attachment.inPublications);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2022-02-08 11:27:00 +00:00
|
|
|
it("should copy an item with a PDF attachment containing annotations to a group", async function () {
|
2022-02-19 18:41:59 +00:00
|
|
|
await Zotero.Users.setCurrentUserID(1);
|
|
|
|
await Zotero.Users.setName(1, 'Name');
|
|
|
|
|
2022-02-08 11:27:00 +00:00
|
|
|
var group = await createGroup();
|
2015-08-08 21:26:42 +00:00
|
|
|
|
2022-02-08 11:27:00 +00:00
|
|
|
var item = await createDataObject('item', false, { skipSelect: true });
|
2015-08-08 21:26:42 +00:00
|
|
|
var file = getTestDataDirectory();
|
2022-02-08 11:27:00 +00:00
|
|
|
file.append('test.pdf');
|
|
|
|
var attachment = await Zotero.Attachments.importFromFile({
|
|
|
|
file,
|
2015-08-08 21:26:42 +00:00
|
|
|
parentItemID: item.id
|
|
|
|
});
|
2022-02-08 11:27:00 +00:00
|
|
|
var annotation = await createAnnotation('highlight', attachment);
|
2015-08-08 21:26:42 +00:00
|
|
|
|
2022-02-08 11:27:00 +00:00
|
|
|
var ids = (await onDrop('item', 'L' + group.libraryID, [item.id])).ids;
|
2015-08-08 21:26:42 +00:00
|
|
|
|
2022-02-08 11:27:00 +00:00
|
|
|
await cv.selectLibrary(group.libraryID);
|
|
|
|
await waitForItemsLoad(win);
|
2015-08-08 21:26:42 +00:00
|
|
|
|
|
|
|
// Check parent
|
|
|
|
var itemsView = win.ZoteroPane.itemsView;
|
|
|
|
assert.equal(itemsView.rowCount, 1);
|
|
|
|
var treeRow = itemsView.getRow(0);
|
|
|
|
assert.equal(treeRow.ref.libraryID, group.libraryID);
|
|
|
|
assert.equal(treeRow.ref.id, ids[0]);
|
|
|
|
// New item should link back to original
|
2022-02-08 11:27:00 +00:00
|
|
|
var linked = await item.getLinkedItem(group.libraryID);
|
2015-08-08 21:26:42 +00:00
|
|
|
assert.equal(linked.id, treeRow.ref.id);
|
|
|
|
|
|
|
|
// Check attachment
|
|
|
|
assert.isTrue(itemsView.isContainer(0));
|
Deasyncification :back: :cry:
While trying to get translation and citing working with asynchronously
generated data, we realized that drag-and-drop support was going to
be...problematic. Firefox only supports synchronous methods for
providing drag data (unlike, it seems, the DataTransferItem interface
supported by Chrome), which means that we'd need to preload all relevant
data on item selection (bounded by export.quickCopy.dragLimit) and keep
the translate/cite methods synchronous (or maintain two separate
versions).
What we're trying instead is doing what I said in #518 we weren't going
to do: loading most object data on startup and leaving many more
functions synchronous. Essentially, this takes the various load*()
methods described in #518, moves them to startup, and makes them operate
on entire libraries rather than individual objects.
The obvious downside here (other than undoing much of the work of the
last many months) is that it increases startup time, potentially quite a
lot for larger libraries. On my laptop, with a 3,000-item library, this
adds about 3 seconds to startup time. I haven't yet tested with larger
libraries. But I'm hoping that we can optimize this further to reduce
that delay. Among other things, this is loading data for all libraries,
when it should be able to load data only for the library being viewed.
But this is also fundamentally just doing some SELECT queries and
storing the results, so it really shouldn't need to be that slow (though
performance may be bounded a bit here by XPCOM overhead).
If we can make this fast enough, it means that third-party plugins
should be able to remain much closer to their current designs. (Some
things, including saving, will still need to be made asynchronous.)
2016-03-07 21:05:51 +00:00
|
|
|
itemsView.toggleOpenState(0);
|
2015-08-08 21:26:42 +00:00
|
|
|
assert.equal(itemsView.rowCount, 2);
|
|
|
|
treeRow = itemsView.getRow(1);
|
|
|
|
assert.equal(treeRow.ref.id, ids[1]);
|
|
|
|
// New attachment should link back to original
|
2022-02-08 11:27:00 +00:00
|
|
|
linked = await attachment.getLinkedItem(group.libraryID);
|
2015-08-08 21:26:42 +00:00
|
|
|
assert.equal(linked.id, treeRow.ref.id);
|
|
|
|
|
2022-02-08 11:27:00 +00:00
|
|
|
// Check annotation
|
|
|
|
var groupAttachment = Zotero.Items.get(treeRow.ref.id);
|
|
|
|
var annotations = groupAttachment.getAnnotations();
|
|
|
|
assert.lengthOf(annotations, 1);
|
|
|
|
|
2015-08-08 21:26:42 +00:00
|
|
|
return group.eraseTx();
|
2022-02-08 11:27:00 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
it("should copy a group item with a PDF attachment containing annotations to the personal library", async function () {
|
2022-02-19 18:41:59 +00:00
|
|
|
await Zotero.Users.setCurrentUserID(1);
|
|
|
|
await Zotero.Users.setName(1, 'Name 1');
|
|
|
|
await Zotero.Users.setName(12345, 'Name 2');
|
2022-02-08 11:27:00 +00:00
|
|
|
|
2022-02-09 04:57:49 +00:00
|
|
|
var group = await createGroup();
|
|
|
|
await cv.selectLibrary(group.libraryID);
|
|
|
|
|
|
|
|
var groupItem = await createDataObject('item', { libraryID: group.libraryID });
|
|
|
|
var file = getTestDataDirectory();
|
|
|
|
file.append('test.pdf');
|
|
|
|
var attachment = await Zotero.Attachments.importFromFile({
|
|
|
|
file,
|
|
|
|
parentItemID: groupItem.id
|
|
|
|
});
|
|
|
|
var annotation = await createAnnotation('highlight', attachment);
|
2022-02-19 18:41:59 +00:00
|
|
|
await annotation.saveTx();
|
2022-02-09 04:57:49 +00:00
|
|
|
|
|
|
|
var ids = (await onDrop('item', 'L1', [groupItem.id])).ids;
|
|
|
|
var newItem = Zotero.Items.get(ids[0]);
|
|
|
|
|
|
|
|
// Check annotation
|
2022-02-19 18:41:59 +00:00
|
|
|
var newAttachment = Zotero.Items.get(newItem.getAttachments())[0];
|
2022-02-09 04:57:49 +00:00
|
|
|
var annotations = newAttachment.getAnnotations();
|
|
|
|
assert.lengthOf(annotations, 1);
|
|
|
|
|
|
|
|
return group.eraseTx();
|
|
|
|
});
|
|
|
|
|
2022-08-13 06:00:24 +00:00
|
|
|
it("should copy a standalone attachment to a group", async function () {
|
|
|
|
await Zotero.Users.setCurrentUserID(1);
|
|
|
|
await Zotero.Users.setName(1, 'Name 1');
|
|
|
|
await Zotero.Users.setName(12345, 'Name 2');
|
|
|
|
|
|
|
|
var group = await createGroup();
|
|
|
|
|
|
|
|
var item = await importPDFAttachment();
|
|
|
|
|
|
|
|
var ids = (await onDrop('item', 'L' + group.libraryID, [item.id])).ids;
|
|
|
|
var newItem = Zotero.Items.get(ids[0]);
|
|
|
|
|
|
|
|
assert.equal(newItem.libraryID, group.libraryID);
|
|
|
|
assert.isTrue(newItem.isPDFAttachment());
|
|
|
|
|
|
|
|
return group.eraseTx();
|
|
|
|
});
|
|
|
|
|
2015-08-08 21:26:42 +00:00
|
|
|
it("should not copy an item or its attachment to a group twice", function* () {
|
|
|
|
var group = yield getGroup();
|
|
|
|
|
|
|
|
var itemTitle = Zotero.Utilities.randomString();
|
|
|
|
var item = yield createDataObject('item', false, { skipSelect: true });
|
|
|
|
var file = getTestDataDirectory();
|
|
|
|
file.append('test.png');
|
|
|
|
var attachment = yield Zotero.Attachments.importFromFile({
|
|
|
|
file: file,
|
|
|
|
parentItemID: item.id
|
|
|
|
});
|
|
|
|
var attachmentTitle = Zotero.Utilities.randomString();
|
|
|
|
attachment.setField('title', attachmentTitle);
|
|
|
|
yield attachment.saveTx();
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield onDrop('item', 'L' + group.libraryID, [item.id]);
|
2015-08-08 21:26:42 +00:00
|
|
|
assert.isFalse(yield canDrop('item', 'L' + group.libraryID, [item.id]));
|
|
|
|
})
|
2015-05-22 23:15:21 +00:00
|
|
|
|
2020-05-20 12:45:37 +00:00
|
|
|
it("should copy an item from a read-only group to an editable group", async function () {
|
|
|
|
var group1 = await createGroup();
|
|
|
|
var item = await createDataObject('item', { libraryID: group1.libraryID });
|
|
|
|
group1.editable = false;
|
|
|
|
await group1.saveTx();
|
|
|
|
var group2 = await createGroup();
|
|
|
|
|
|
|
|
await cv.selectLibrary(group1.libraryID);
|
|
|
|
await waitForItemsLoad(win);
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
await onDrop('item', 'L' + group2.libraryID, [item.id]);
|
2020-05-20 12:45:37 +00:00
|
|
|
|
|
|
|
assert.isFalse(await item.getLinkedItem(group2.libraryID));
|
|
|
|
// New collection should link back to original
|
|
|
|
assert.ok(await item.getLinkedItem(group2.libraryID, true));
|
|
|
|
|
|
|
|
await group1.eraseTx();
|
|
|
|
await group2.eraseTx();
|
|
|
|
});
|
|
|
|
|
2021-07-21 04:12:15 +00:00
|
|
|
it("should ignore a linked, trashed item when re-dragging an item to a group", async function () {
|
|
|
|
var group = await getGroup();
|
|
|
|
var collection = await createDataObject('collection', { libraryID: group.libraryID });
|
2015-08-08 21:26:42 +00:00
|
|
|
|
2021-07-21 04:12:15 +00:00
|
|
|
var item = await createDataObject('item', false, { skipSelect: true });
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
await onDrop('item', 'L' + group.libraryID, [item.id]);
|
2015-08-08 21:26:42 +00:00
|
|
|
|
2021-07-21 04:12:15 +00:00
|
|
|
var droppedItem = await item.getLinkedItem(group.libraryID);
|
2015-08-08 21:26:42 +00:00
|
|
|
droppedItem.setCollections([collection.id]);
|
|
|
|
droppedItem.deleted = true;
|
2021-07-21 04:12:15 +00:00
|
|
|
await droppedItem.saveTx();
|
2015-08-08 21:26:42 +00:00
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
await onDrop('item', 'L' + group.libraryID, [item.id]);
|
2021-07-21 04:12:15 +00:00
|
|
|
|
|
|
|
var linkedItem = await item.getLinkedItem(group.libraryID);
|
|
|
|
assert.notEqual(linkedItem, droppedItem);
|
2015-08-08 21:26:42 +00:00
|
|
|
|
2021-07-21 04:12:15 +00:00
|
|
|
assert.isTrue(droppedItem.deleted);
|
2015-08-08 21:26:42 +00:00
|
|
|
})
|
2015-05-22 23:15:21 +00:00
|
|
|
})
|
2015-05-24 01:10:07 +00:00
|
|
|
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
|
2015-08-08 21:26:42 +00:00
|
|
|
describe("with collections", function () {
|
|
|
|
it("should make a subcollection top-level", function* () {
|
|
|
|
var collection1 = yield createDataObject('collection', { name: "A" }, { skipSelect: true });
|
|
|
|
var collection2 = yield createDataObject('collection', { name: "C" }, { skipSelect: true });
|
|
|
|
var collection3 = yield createDataObject('collection', { name: "D" }, { skipSelect: true });
|
|
|
|
var collection4 = yield createDataObject('collection', { name: "B", parentKey: collection2.key });
|
|
|
|
|
|
|
|
var colIndex1 = cv.getRowIndexByID('C' + collection1.id);
|
|
|
|
var colIndex2 = cv.getRowIndexByID('C' + collection2.id);
|
|
|
|
var colIndex3 = cv.getRowIndexByID('C' + collection3.id);
|
|
|
|
var colIndex4 = cv.getRowIndexByID('C' + collection4.id);
|
|
|
|
|
|
|
|
// Add observer to wait for collection add
|
|
|
|
var deferred = Zotero.Promise.defer();
|
|
|
|
var observerID = Zotero.Notifier.registerObserver({
|
|
|
|
notify: function (event, type, ids, extraData) {
|
|
|
|
if (type == 'collection' && event == 'modify' && ids[0] == collection4.id) {
|
|
|
|
setTimeout(function () {
|
|
|
|
deferred.resolve();
|
|
|
|
}, 50);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}, 'collection', 'test');
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield onDrop(
|
2015-08-08 21:26:42 +00:00
|
|
|
'collection',
|
|
|
|
{
|
|
|
|
row: 0,
|
|
|
|
orient: 1
|
|
|
|
},
|
|
|
|
[collection4.id],
|
|
|
|
deferred.promise
|
|
|
|
);
|
|
|
|
|
|
|
|
Zotero.Notifier.unregisterObserver(observerID);
|
|
|
|
|
|
|
|
var newColIndex1 = cv.getRowIndexByID('C' + collection1.id);
|
|
|
|
var newColIndex2 = cv.getRowIndexByID('C' + collection2.id);
|
|
|
|
var newColIndex3 = cv.getRowIndexByID('C' + collection3.id);
|
|
|
|
var newColIndex4 = cv.getRowIndexByID('C' + collection4.id);
|
|
|
|
|
|
|
|
assert.equal(newColIndex1, colIndex1);
|
|
|
|
assert.isBelow(newColIndex4, newColIndex2);
|
|
|
|
assert.isBelow(newColIndex2, newColIndex3);
|
|
|
|
assert.equal(cv.getRow(newColIndex4).level, cv.getRow(newColIndex1).level);
|
|
|
|
})
|
|
|
|
|
|
|
|
it("should move a subcollection and its subcollection down under another collection", function* () {
|
|
|
|
var collectionA = yield createDataObject('collection', { name: "A" }, { skipSelect: true });
|
|
|
|
var collectionB = yield createDataObject('collection', { name: "B", parentKey: collectionA.key });
|
|
|
|
var collectionC = yield createDataObject('collection', { name: "C", parentKey: collectionB.key });
|
|
|
|
var collectionD = yield createDataObject('collection', { name: "D" }, { skipSelect: true });
|
|
|
|
var collectionE = yield createDataObject('collection', { name: "E" }, { skipSelect: true });
|
|
|
|
var collectionF = yield createDataObject('collection', { name: "F" }, { skipSelect: true });
|
|
|
|
var collectionG = yield createDataObject('collection', { name: "G", parentKey: collectionD.key });
|
|
|
|
var collectionH = yield createDataObject('collection', { name: "H", parentKey: collectionG.key });
|
|
|
|
|
|
|
|
var colIndexA = cv.getRowIndexByID('C' + collectionA.id);
|
|
|
|
var colIndexB = cv.getRowIndexByID('C' + collectionB.id);
|
|
|
|
var colIndexC = cv.getRowIndexByID('C' + collectionC.id);
|
|
|
|
var colIndexD = cv.getRowIndexByID('C' + collectionD.id);
|
|
|
|
var colIndexE = cv.getRowIndexByID('C' + collectionE.id);
|
|
|
|
var colIndexF = cv.getRowIndexByID('C' + collectionF.id);
|
|
|
|
var colIndexG = cv.getRowIndexByID('C' + collectionG.id);
|
|
|
|
var colIndexH = cv.getRowIndexByID('C' + collectionH.id);
|
|
|
|
|
|
|
|
yield cv.selectCollection(collectionG.id);
|
|
|
|
|
|
|
|
// Add observer to wait for collection add
|
|
|
|
var deferred = Zotero.Promise.defer();
|
|
|
|
var observerID = Zotero.Notifier.registerObserver({
|
|
|
|
notify: function (event, type, ids, extraData) {
|
|
|
|
if (type == 'collection' && event == 'modify' && ids[0] == collectionG.id) {
|
|
|
|
setTimeout(function () {
|
|
|
|
deferred.resolve();
|
|
|
|
}, 50);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}, 'collection', 'test');
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield onDrop(
|
2015-08-08 21:26:42 +00:00
|
|
|
'collection',
|
|
|
|
{
|
|
|
|
row: colIndexE,
|
|
|
|
orient: 0
|
|
|
|
},
|
|
|
|
[collectionG.id],
|
|
|
|
deferred.promise
|
|
|
|
);
|
|
|
|
|
|
|
|
Zotero.Notifier.unregisterObserver(observerID);
|
|
|
|
|
|
|
|
var newColIndexA = cv.getRowIndexByID('C' + collectionA.id);
|
|
|
|
var newColIndexB = cv.getRowIndexByID('C' + collectionB.id);
|
|
|
|
var newColIndexC = cv.getRowIndexByID('C' + collectionC.id);
|
|
|
|
var newColIndexD = cv.getRowIndexByID('C' + collectionD.id);
|
|
|
|
var newColIndexE = cv.getRowIndexByID('C' + collectionE.id);
|
|
|
|
var newColIndexF = cv.getRowIndexByID('C' + collectionF.id);
|
|
|
|
var newColIndexG = cv.getRowIndexByID('C' + collectionG.id);
|
|
|
|
var newColIndexH = cv.getRowIndexByID('C' + collectionH.id);
|
|
|
|
|
|
|
|
assert.isFalse(cv.isContainerOpen(newColIndexD));
|
|
|
|
assert.isTrue(cv.isContainerEmpty(newColIndexD));
|
|
|
|
assert.isTrue(cv.isContainerOpen(newColIndexE));
|
|
|
|
assert.isFalse(cv.isContainerEmpty(newColIndexE));
|
|
|
|
assert.equal(newColIndexE, newColIndexG - 1);
|
|
|
|
assert.equal(newColIndexG, newColIndexH - 1);
|
|
|
|
|
|
|
|
// TODO: Check deeper subcollection open states
|
|
|
|
})
|
2016-02-01 14:59:30 +00:00
|
|
|
|
|
|
|
it("should move a subcollection and its subcollection up under another collection", function* () {
|
|
|
|
var collectionA = yield createDataObject('collection', { name: "A" }, { skipSelect: true });
|
|
|
|
var collectionB = yield createDataObject('collection', { name: "B", parentKey: collectionA.key });
|
|
|
|
var collectionC = yield createDataObject('collection', { name: "C", parentKey: collectionB.key });
|
|
|
|
var collectionD = yield createDataObject('collection', { name: "D" }, { skipSelect: true });
|
|
|
|
var collectionE = yield createDataObject('collection', { name: "E" }, { skipSelect: true });
|
|
|
|
var collectionF = yield createDataObject('collection', { name: "F" }, { skipSelect: true });
|
|
|
|
var collectionG = yield createDataObject('collection', { name: "G", parentKey: collectionE.key });
|
|
|
|
var collectionH = yield createDataObject('collection', { name: "H", parentKey: collectionG.key });
|
|
|
|
|
|
|
|
var colIndexA = cv.getRowIndexByID('C' + collectionA.id);
|
|
|
|
var colIndexB = cv.getRowIndexByID('C' + collectionB.id);
|
|
|
|
var colIndexC = cv.getRowIndexByID('C' + collectionC.id);
|
|
|
|
var colIndexD = cv.getRowIndexByID('C' + collectionD.id);
|
|
|
|
var colIndexE = cv.getRowIndexByID('C' + collectionE.id);
|
|
|
|
var colIndexF = cv.getRowIndexByID('C' + collectionF.id);
|
|
|
|
var colIndexG = cv.getRowIndexByID('C' + collectionG.id);
|
|
|
|
var colIndexH = cv.getRowIndexByID('C' + collectionH.id);
|
|
|
|
|
|
|
|
yield cv.selectCollection(collectionG.id);
|
|
|
|
|
|
|
|
// Add observer to wait for collection add
|
|
|
|
var deferred = Zotero.Promise.defer();
|
|
|
|
var observerID = Zotero.Notifier.registerObserver({
|
|
|
|
notify: function (event, type, ids, extraData) {
|
|
|
|
if (type == 'collection' && event == 'modify' && ids[0] == collectionG.id) {
|
|
|
|
setTimeout(function () {
|
|
|
|
deferred.resolve();
|
|
|
|
}, 50);
|
|
|
|
}
|
Relations overhaul (requires new DB upgrade from 4.0)
Relations are now properties of collections and items rather than
first-class objects, stored in separate collectionRelations and
itemRelations tables with ids for subjects, with foreign keys to the
associated data objects.
Related items now use dc:relation relations rather than a separate table
(among other reasons, because API syncing won't necessarily sync both
items at the same time, so they can't be stored by id).
The UI assigns related-item relations bidirectionally, and checks for
related-item and linked-object relations are done unidirectionally by
default.
dc:isReplacedBy is now dc:replaces, so that the subject is an existing
object, and the predicate is now named
Zotero.Attachments.replacedItemPredicate.
Some additional work is still needed, notably around following
replaced-item relations, and migration needs to be tested more fully,
but this seems to mostly work.
2015-06-02 00:09:39 +00:00
|
|
|
}
|
2016-02-01 14:59:30 +00:00
|
|
|
}, 'collection', 'test');
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
yield onDrop(
|
2016-02-01 14:59:30 +00:00
|
|
|
'collection',
|
|
|
|
{
|
|
|
|
row: colIndexD,
|
|
|
|
orient: 0
|
|
|
|
},
|
|
|
|
[collectionG.id],
|
|
|
|
deferred.promise
|
|
|
|
);
|
|
|
|
|
|
|
|
Zotero.Notifier.unregisterObserver(observerID);
|
|
|
|
|
|
|
|
var newColIndexA = cv.getRowIndexByID('C' + collectionA.id);
|
|
|
|
var newColIndexB = cv.getRowIndexByID('C' + collectionB.id);
|
|
|
|
var newColIndexC = cv.getRowIndexByID('C' + collectionC.id);
|
|
|
|
var newColIndexD = cv.getRowIndexByID('C' + collectionD.id);
|
|
|
|
var newColIndexE = cv.getRowIndexByID('C' + collectionE.id);
|
|
|
|
var newColIndexF = cv.getRowIndexByID('C' + collectionF.id);
|
|
|
|
var newColIndexG = cv.getRowIndexByID('C' + collectionG.id);
|
|
|
|
var newColIndexH = cv.getRowIndexByID('C' + collectionH.id);
|
|
|
|
|
|
|
|
assert.isFalse(cv.isContainerOpen(newColIndexE));
|
|
|
|
assert.isTrue(cv.isContainerEmpty(newColIndexE));
|
|
|
|
assert.isTrue(cv.isContainerOpen(newColIndexD));
|
|
|
|
assert.isFalse(cv.isContainerEmpty(newColIndexD));
|
|
|
|
assert.equal(newColIndexD, newColIndexG - 1);
|
|
|
|
assert.equal(newColIndexG, newColIndexH - 1);
|
|
|
|
|
|
|
|
// TODO: Check deeper subcollection open states
|
|
|
|
})
|
2018-12-16 07:18:18 +00:00
|
|
|
|
|
|
|
it("should copy a collection and its subcollection to another library", async function () {
|
|
|
|
var group = await createGroup();
|
|
|
|
|
|
|
|
var collectionA = await createDataObject('collection', { name: "A" }, { skipSelect: true });
|
|
|
|
var collectionB = await createDataObject('collection', { name: "B", parentKey: collectionA.key });
|
|
|
|
var itemA = await createDataObject('item', { collections: [collectionA.key] }, { skipSelect: true });
|
|
|
|
var itemB = await createDataObject('item', { collections: [collectionB.key] }, { skipSelect: true });
|
|
|
|
|
|
|
|
await cv.selectCollection(collectionA.id);
|
|
|
|
|
|
|
|
// Add observer to wait for collection add
|
|
|
|
var deferred = Zotero.Promise.defer();
|
|
|
|
var observerID = Zotero.Notifier.registerObserver({
|
|
|
|
notify: function (event, type, ids, extraData) {
|
|
|
|
if (type == 'collection' && event == 'modify' && ids.includes(collectionB.id)) {
|
|
|
|
setTimeout(function () {
|
|
|
|
deferred.resolve();
|
|
|
|
}, 50);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}, 'collection', 'test');
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
await onDrop(
|
2018-12-16 07:18:18 +00:00
|
|
|
'collection',
|
|
|
|
'L' + group.libraryID,
|
|
|
|
[collectionA.id],
|
|
|
|
deferred.promise
|
|
|
|
);
|
|
|
|
|
|
|
|
Zotero.Notifier.unregisterObserver(observerID);
|
|
|
|
|
|
|
|
var pred = Zotero.Relations.linkedObjectPredicate;
|
|
|
|
var newCollectionA = await Zotero.URI.getURICollection(collectionA.getRelations()[pred][0]);
|
|
|
|
var newCollectionB = await Zotero.URI.getURICollection(collectionB.getRelations()[pred][0]);
|
|
|
|
var newItemA = await Zotero.URI.getURIItem(itemA.getRelations()[pred][0]);
|
|
|
|
var newItemB = await Zotero.URI.getURIItem(itemB.getRelations()[pred][0]);
|
|
|
|
assert.equal(newCollectionA.libraryID, group.libraryID);
|
|
|
|
assert.equal(newCollectionB.libraryID, group.libraryID);
|
|
|
|
assert.equal(newCollectionB.parentID, newCollectionA.id);
|
|
|
|
assert.equal(newItemA.libraryID, group.libraryID);
|
|
|
|
assert.equal(newItemB.libraryID, group.libraryID);
|
|
|
|
assert.isTrue(newCollectionA.hasItem(newItemA));
|
|
|
|
assert.isTrue(newCollectionB.hasItem(newItemB));
|
|
|
|
assert.isFalse(newCollectionA.hasItem(newItemB));
|
|
|
|
assert.isFalse(newCollectionB.hasItem(newItemA));
|
|
|
|
})
|
2020-05-20 12:45:37 +00:00
|
|
|
|
|
|
|
it("should copy a collection from a read-only group to another group", async function () {
|
|
|
|
var group1 = await createGroup();
|
|
|
|
var collection = await createDataObject('collection', { libraryID: group1.libraryID });
|
|
|
|
var item = await createDataObject('item', { libraryID: group1.libraryID, collections: [collection.id] });
|
|
|
|
group1.editable = false;
|
|
|
|
await group1.saveTx();
|
|
|
|
|
2020-05-20 22:47:55 +00:00
|
|
|
var group2 = await createGroup();
|
2020-05-20 12:45:37 +00:00
|
|
|
|
|
|
|
await cv.selectCollection(collection.id);
|
|
|
|
await waitForItemsLoad(win);
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
await onDrop('collection', 'L' + group2.libraryID, [collection.id]);
|
2020-05-20 12:45:37 +00:00
|
|
|
|
|
|
|
assert.isFalse(await collection.getLinkedCollection(group2.libraryID));
|
|
|
|
// New collection should link back to original
|
|
|
|
assert.ok(await collection.getLinkedCollection(group2.libraryID, true));
|
|
|
|
|
|
|
|
assert.isFalse(await item.getLinkedItem(group2.libraryID));
|
|
|
|
// New item should link back to original
|
|
|
|
assert.ok(await item.getLinkedItem(group2.libraryID, true));
|
|
|
|
|
|
|
|
await group1.eraseTx();
|
|
|
|
await group2.eraseTx();
|
|
|
|
});
|
2016-02-01 14:59:30 +00:00
|
|
|
})
|
|
|
|
|
|
|
|
|
|
|
|
describe("with feed items", function () {
|
|
|
|
it('should add a translated feed item recovered from an URL', function* (){
|
|
|
|
var feed = yield createFeed();
|
|
|
|
var collection = yield createDataObject('collection', false, { skipSelect: true });
|
2016-02-11 11:02:38 +00:00
|
|
|
var url = getTestDataUrl('metadata/journalArticle-single.html');
|
2016-02-01 14:59:30 +00:00
|
|
|
var feedItem = yield createDataObject('feedItem', {libraryID: feed.libraryID}, { skipSelect: true });
|
|
|
|
feedItem.setField('url', url);
|
2016-02-11 11:02:38 +00:00
|
|
|
yield feedItem.saveTx();
|
2016-02-01 14:59:30 +00:00
|
|
|
var translateFn = sinon.spy(feedItem, 'translate');
|
|
|
|
|
|
|
|
// Add observer to wait for collection add
|
|
|
|
var deferred = Zotero.Promise.defer();
|
|
|
|
var itemIds;
|
|
|
|
|
XUL -> JS tree megacommit
- Just a single huge commit. This has been developed over too long a
time, required many tiny changes across too many files and has seen too
many iterations to be separated into separate commits.
The original branch with all the messy commits will be kept around for
posterity
https://github.com/zotero/zotero/compare/bb220ad0f2d6bf0eca6df6d225d3d358cb50a27b...adomasven:feature/react-item-tree
- Replaces XUL <tree> element across the whole zotero client codebase
with a custom supermegafast virtualized-table inspired by
react-virtualized yet mimicking old XUL treeview API. The
virtualized-table sits on top on a raw-to-the-metal,
interpreted-at-runtime JS based windowing solution inspired by
react-window. React-based solutions could not be used because they were
slow and Zotero UI needs to be responsive and be able to
display thousands of rows in a treeview without any slowdowns.
- Attempts were made at making this screen-reader friendly, but yet to
be tested with something like JAWS
- RTL-friendly
- Styling and behaviour across all platforms was copied as closely as
possible to the original XUL tree
- Instead of row-based scroll snapping this has smooth-scrolling. If
you're using arrow keys to browse through the tree then it effectively
snap-scrolls. Current CSS snap scroll attributes do not seem to work in
the way we would require even on up-to-date browsers, yet alone the ESR
version of FX that Zotero is on. JS solutions are either terrible for
performance or produce inexcusable jitter.
- When dragging-and-dropping items the initial drag freezes the UI for
a fairly jarring amount of time. Does not seem to be fixable due to
the synchronous code that needs to be run in the dragstart handler.
Used to be possible to run that code async with the XUL tree.
- Item tree column picker no longer has a dedicated button. Just
right-click the columns. The column preferences (width, order, etc) are
no longer handled by XUL, which required a custom serialization and
storage solution that throws warnings in the developer console due to
the amount of data being stored. Might cause temporary freezing on HDDs
upon column resize/reorder/visibility toggling.
- Context menu handling code basically unchanged, but any UI changes
that plugins may have wanted to do (including adding new columns) will
have to be redone by them. No serious thought has gone into how plugin
developers would achieve that yet.
- Opens up the possibility for awesome alternative ways to render the
tree items, including things like multiple-row view for the item tree,
which has been requested for a long while especially by users switching
from other referencing software
2020-06-03 07:29:46 +00:00
|
|
|
var ids = (yield onDrop('item', 'C' + collection.id, [feedItem.id])).ids;
|
2016-02-01 14:59:30 +00:00
|
|
|
|
|
|
|
// Check that the translated item was the one that was created after drag
|
|
|
|
var item;
|
|
|
|
yield translateFn.returnValues[0].then(function(i) {
|
|
|
|
item = i;
|
|
|
|
assert.equal(item.id, ids[0]);
|
|
|
|
});
|
|
|
|
|
|
|
|
yield cv.selectCollection(collection.id);
|
|
|
|
yield waitForItemsLoad(win);
|
|
|
|
|
|
|
|
var itemsView = win.ZoteroPane.itemsView;
|
|
|
|
assert.equal(itemsView.rowCount, 1);
|
|
|
|
var treeRow = itemsView.getRow(0);
|
|
|
|
assert.equal(treeRow.ref.id, item.id);
|
|
|
|
})
|
2015-05-24 01:10:07 +00:00
|
|
|
})
|
2015-05-22 23:15:21 +00:00
|
|
|
})
|
2015-04-30 21:06:38 +00:00
|
|
|
})
|