Currently, when evidence is revealed, it appears in the order that the evidence was entered into the editor. This means if I have evidence (1) and (2), and I enter evidence (1) after (2), then it will appear behind evidence (2), even though it was entered later. This is a minor presentation issue, but it could be fixed by allowing evidence and profiles to be re-ordered like frames. I imagine it would be similar to the code used to re-order frames (clicking and dragging the number), but I know nothing about how this works, so correct me if I'm wrong.
Currently, you can fix this by deleting and recreating the evidence in the correct order, but this requires you to either remove all references to the evidence or have a "dummy" piece of evidence that you can't delete. Since this is such a minor detail, it's probably not worth the effort unless it would be an easy addition for the developers. Just figured I'd throw the idea out there.
[E] Re-ordering evidence/profiles
Moderator: EN - Forum Moderators
- drvonkitty
- Posts: 567
- Joined: Sat Apr 14, 2012 12:25 am
- Spoken languages: English
- Enthalpy
- Community Manager
- Posts: 5172
- Joined: Wed Jan 04, 2012 4:40 am
- Gender: Male
- Spoken languages: English, limited Spanish
Re: [E] Re-ordering evidence/profiles
I like the idea. I'll look into how complicated this would be to implement, but your QA takes priority over this.
[D]isordered speech is not so much injury to the lips that give it forth, as to the disproportion and incoherence of things in themselves, so negligently expressed. ~ Ben Jonson
- Unas
- Admin / Site programmer
- Posts: 8850
- Joined: Tue Jul 10, 2007 4:43 pm
- Gender: Male
- Spoken languages: Français, English, Español
- Contact:
Re: [E] Re-ordering evidence/profiles
I confirm it's just a matter of UI development in the editor, since evidence and profiles all have a static ID number independent of the ordering.
Technically, you could export the source code of your trial, reorder the profiles and evidence in the JSON, and save it, it would work fine.
And the logic is fairly simple.
CSS classes are defined in editor_storyboard.css, section "STYLE FOR DRAG AND DROP" :
- draggable (on the ID number to appear as a handle),
- drop-target (on every profile that can be the target a drag, ie any profile that has an insert-before bar... ie every profile. That's simpler that frame rows ! )
- dragging and drag-source (used while dragging, that will slightly fade out the row being dragged and trigger the "growing" of the insert-before bar to highlight the destination of the drop)
The only issue you'll have is to tweak the 'body.dragging [drop-target="1"]:hover .insert' and 'body.dragging [drop-target="1"]:hover .frame' rules, that currently act on the height, to act on the width when in a section that has vertical insertion bars.
The corresponding JS code is currently in editor_frame_rows.js, search for the comment "// Drag and drop handle".
The only thing is, if you decide to implement if for other tabs, I'd suggest extracting that logic outside of the frame context and make it content-agnostic, rather than duplicating it for other tabs. That will require refactoring the other tabs to use the same kind of "behaviour" object with insert_fct and delete_fct like frames do, as the drag and drop logic basically needs to call those (to trigger the delete on the existing row and the insert before the drop target) in order to remain content-agnostic.
Technically, you could export the source code of your trial, reorder the profiles and evidence in the JSON, and save it, it would work fine.
And the logic is fairly simple.
CSS classes are defined in editor_storyboard.css, section "STYLE FOR DRAG AND DROP" :
- draggable (on the ID number to appear as a handle),
- drop-target (on every profile that can be the target a drag, ie any profile that has an insert-before bar... ie every profile. That's simpler that frame rows ! )
- dragging and drag-source (used while dragging, that will slightly fade out the row being dragged and trigger the "growing" of the insert-before bar to highlight the destination of the drop)
The only issue you'll have is to tweak the 'body.dragging [drop-target="1"]:hover .insert' and 'body.dragging [drop-target="1"]:hover .frame' rules, that currently act on the height, to act on the width when in a section that has vertical insertion bars.
The corresponding JS code is currently in editor_frame_rows.js, search for the comment "// Drag and drop handle".
The only thing is, if you decide to implement if for other tabs, I'd suggest extracting that logic outside of the frame context and make it content-agnostic, rather than duplicating it for other tabs. That will require refactoring the other tabs to use the same kind of "behaviour" object with insert_fct and delete_fct like frames do, as the drag and drop logic basically needs to call those (to trigger the delete on the existing row and the insert before the drop target) in order to remain content-agnostic.