Testing the various operators:

I'm must confess that I'm not ready to give up on this yet... I've updated the space_sequencer.py according to the renaming in your version of the operator file:
https://github.com/tin2tin/blender_vse_reworked/blob/master/UI_fix_space_sequencer.py
If you want to edit the space_sequencer.py file from the Blender text-editor, several additional files needs to be loaded into the text editor to avoid errors. They are opened in this .blend:
https://we.tl/t-uWQSc01EbV

In D4199#95636, @Richard Antalik (ISS) wrote:

In D4199#95618, @Peter Fog (tintwotin) wrote:

I feel that info about the shift/ctrl/alt functions should be in the status bar and context-sensitive, so ex. when hovering over a checkbox is should say +alt will add values to entire selection(if that is not the default behavior).

Not sure - this information would how on every editable element, so it would be kinda redundant.
On the other hand it is quite essential information - perhaps it should be shown in status bar, where LMB icon is

In D4199#95594, @Richard Antalik (ISS) wrote:

• SEQUENCER_OT_Move
  • What about moving to nearest snap points(another strip start, end, markers, channels etc) in desired direcion? I got this coded, can move large blocks, but need better collision handling(need this anyway, so why not...)

Ctrl+drag playhead/strip will snap to next cut, so snapping with Ctrl pressed would be in consistency, but the default move should be without snapping.

• How to handle collisions? What should happen when you do ripple delete and attached effect in upper channel would collide into some strip?
  • prevent execution and throw error?
  • move as far as possible?
  • configurable behavior?

When pasting, stips will be inserted into the first free channels, so maybe when strips are colliding they should be moved upwards into the first free channel(but only if it is effect-strips).

• What should be behavior of strip lock?
  • prevent any modification other then changing lock state?

Yes, I think so too.

Another thing, that I wanted to tackle was displaying and modifying properties of selection.

• I was thinking about concept of active strip - my brain refuses to accept it's usefulness. Maybe because active strip is completely independent of selection.

Maybe all select-operators should ensure that the active strip is always the last selected strip, which it is when you select manually. The question is if you deselect all also should deselect the active strip(and close the strip properties panel?). That would be an understandable behavior, but I don't know if it will be annoying to have the panel open and close all the time?

• Alt + tweak value and alt + enter seems to work pretty well so nothing to do here I guess

I feel that info about the shift/ctrl/alt functions should be in the status bar and context-sensitive, so ex. when hovering over a checkbox is should say +alt will add values to entire selection(if that is not the default behavior).

Displaying properties of selection could be done better IMO.

• Ideally you want to display all properties of all types. Logical step would be group properties based on strip type
  • use tab per type, so you can immediately see what types are selected and switch between them?
  • Not sure, if we can show only values of fields that would be same for all selected strips of the same type, otherwise they could be blank or display some label like "varies".

I don't know if this is too much trouble for now? How does the 3D View deal with selections containing different types?

• when I change active strip to strip of different type(from movie to sound), panel organization is quite inconsistent.
  • Don't know what we can do about this...

Yeah, the strips have quite individual settings, which makes it hard to avoid panels jumping around when changing type.

@Richard Antalik (ISS) Thank you for investing so much time in this. The "space_sequencer.py" doesn't seem to be updated to reflect the changes in "sequencer.py"? When I replace these two files in a fresh build of Blender the entire UI is broken. So I can't test your changes.

In D4199#95524, @Richard Antalik (ISS) wrote:

@Peter Fog (tintwotin) I should say, that I am modifying these scripts, so please don't make very big changes.

Sorry, I didn't know that. My son was jumping around me when I updated the file, so I feel that there might be things unfinished. the main changes are the split-extract/lift/remove,operator, navigation - range-start/end menu. Will not do more for now.

In D4199#95378, @Campbell Barton (campbellbarton) wrote:

Looking further into split operators SEQUENCER_OT_SplitExtract and SEQUENCER_OT_SplitLift duplicates functionality, with only one line difference: sequencer.ripple_delete / sequencer.delete_lift. This could be made into a single operator.

These functions seem to be already included in the 'Input' submenu:
'class SEQUENCER_MT_strip_input(Menu):'

In D4199#95377, @Richard Antalik (ISS) wrote:

Oh my.. Now I am looking at this thread, 100 inlines...

OK I will read through this and set this as a priority issue, which it actually is to be fair...

Thank you for updating the files. I can see the try/except wasn't removed in my Github, but they are removed now.

In D4199#95330, @Richard Antalik (ISS) wrote:

I will update files for this patch. As for my progress - I was reformatting keymap file, still have to compare 2 versions and remove items that has not changed.
I was planning to continue this work during the weekend as it can turn to manual labor, so during workdays I an happy when I can do few "one line" patches.

@Brecht Van Lommel (brecht) @Richard Antalik (ISS)
More fixes and comments here: https://github.com/tin2tin/blender_vse_reworked
Ex. View Channel Solo/All & Toggle All Modifiers have now been removed.
A lot has been fixed/addressed, but not yet everything.

@Brecht Van Lommel (brecht) @Richard Antalik (ISS)
Another round of fixes uploaded here: https://github.com/tin2tin/blender_vse_reworked
And now also added some comments below.

@Brecht Van Lommel (brecht) & @Richard Antalik (ISS)
Thank you for spending your time on this.
As I have already stated, I'm not a coder.
Most of the operators are reworked code from ex. KinoRaw. That's why the code-style differs.
I have made the first round of changes from your(Brecht's) remarks(mostly the cosmetic ones), and uploaded the files here:
https://github.com/tin2tin/blender_vse_reworked
(I don't know how to submit patches, sorry)

Thank you for this, @Richard Antalik (ISS)
The changes should work without changing the default VSE layout.

If you want collect VSE issues and such. Here are some links to public documents on bugs, papercuts and suggestions for the VSE:

If you want to test it against a (unofficial) 2.80 VSE panel, you can get it here: https://devtalk.blender.org/t/can-we-in-collaboration-produce-a-working-suggestion-for-improving-the-user-interface-of-the-vse/3264/77

I think this change will be problematic when adding more strips from the same scene using ex. different cameras. I personally do not want the scene-strips to inherit or be limited by any duration from the scene's preview/render ranges. That duration should only be determined by the length of the strip in the sequencer(and not limited to or changed by the range currently in that scene), but that's just my opinion.

If you want to improve the VSE defaults, here's a collection of suggestions: https://devtalk.blender.org/t/suggestions-for-vse-ui-cleanup-and-default-settings-in-2-8/2210

On the topic of left click mode and alterations, it feels counter-intuitive to right click in 'Timeline' and 'Sequencer' to drag the time cursor. Could this be the left click instead?

For inspiration a discussion on StackExchange on the topic of this papercut:
https://blender.stackexchange.com/questions/23159/how-to-make-the-file-manager-default-to-sorting-by-modification-date

Please click on the gif for an illustration of the problem when ex. swapping the position of the panel, where the vertical scrollbar completely disappears, making it impossible to work in the vse:

Wow! On the official 2.79b I get 5 fps.
On your patch I get a clean 25 fps in the cached areas.

Would love to test it, if you can share a build?

I would suggest that the word "Movie" (ex. Movie Clip Editor) in Blender was changed to ex. "Video" or just "Clip".

Strange. It crashes here on 2.8 too.

Thanks for the test-build. I had to run it in compatibility mode for Windows 7 to get it to run on Windows 8.

In T53615#481265, @Philipp Oeser (lichtwerk) wrote:

• cannot confirm the Refresh Reels File Not Found message if I saved your example EDL and browsed to that

Oh, so integrating the sequencer with the 3D Viewport like this, will no more be possible? Previz Camera Tools

Great project! Are you aware of the Movit-lib which generates video effects on the GPU? https://git.sesse.net/?p=movit;a=summary