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

Added tag for easier tracking

I could not resist to do a little experiment of jumpy panel: https://photos.app.goo.gl/dXQyg23Z5sTzJUVH6

To reproduce please follow T54117

Not sure how exactly reproduce the error, but from code it feels like you need to pass clip->flag instead of 0 to BKE_movieclip_get_ibuf_flag.

@Sergey Sharybin (sergey), can you review this?

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

I was looking at menu items,
Biggest problem are operators - many of them can be run with properties, that would contradict their description, or depends on selected sequences, etc...

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

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.

Regarding the C core and Py shell idea: if we can contribute operators in Python, we'd work directly on Blender instead of our add-on Power Sequencer with my teammate Razvan. I'm in the middle of a Kickstarter campaign now so too busy to help, unfortunately, but we do all of our work with the VSE so we'd gladly contribute directly to Blender itself. 🙂
Thanks a lot for your work everyone!

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.

Poll should never be accessing collections/selection, it's called on drawing and will slowdown playback if it needs to build a list of many items only to check if a button should be greyed out.

This patch is getting to big to be able to review usefully.

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

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

@Richard Antalik (ISS), could you identify any of the changes here that'd be better done in C? (as TODO's in comments for eg).

In the case of extending "Select Grouped" this is something you could probably do even without much experience in C.
We can help you get started compiling Blender.

Otherwise, someone else can add this.

I have "no problem" with C code.

Also depends on if and what has to be done in C.
If it was up to me, I would rather keep C side as simple as possible(expose props, sanity checks, object factory + low level glue basically) and do "complex" operations in python.

• As OOP, python is more suited to work with objects
• Contribution base is larger
• Maintenance is easier You can have lot of data even in VSE but I can hardly imagine hitting performance limit due to opertators written in python (have seen https://github.com/mikeycal/vse-stopwatch-timer-for-blender IMO could be done by animating visibility + transform + speed or number of other possibilities) If python operators are OK to create, I implementation of some feature-rich container for strips may quite simplify code in general.

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

@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.

@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#95531, @Campbell Barton (campbellbarton) wrote:

@Richard Antalik (ISS), could you identify any of the changes here that'd be better done in C? (as TODO's in comments for eg).

In the case of extending "Select Grouped" this is something you could probably do even without much experience in C.
We can help you get started compiling Blender.

Otherwise, someone else can add this.

@Richard Antalik (ISS), could you identify any of the changes here that'd be better done in C? (as TODO's in comments for eg).

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.

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

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.

Should be fixed in d3e856cd but I can't really test it. Please give it a try with a build bot build newer than this comment and check if it works there. If not, feel free to reopen this bug report!

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...

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.

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

I think it is better to wait with the keymap until sequencer.py and space_sequencer.py are good to go, as the keymap may change with changes in the other two files. NB. though @Brecht Van Lommel (brecht) has invested a lot of time in evaluating the code, there still seems to be a good deal which hasn't been commented(and I fear that it isn't because the code is perfect). Maybe Brecht can let you know what still needs a first evaluation? It is not all remarks I'm skilled to solve myself. And as mentioned in another comment here, there are several open design questions, which someone with the right authority needs to decide on.

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

Can not reproduce even in 2.79
Maybe can you save blend file, with which This can be reproduced?

Tried to reproduce, however in output settings value of Video Codec item is empty.
What codec do you have set?

Updated patch based on latest version

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.

Hello, sorry for lack of communication.

Re-assigning, as @Richard Antalik (ISS) is working on this.

I can still reproduce this in 2.80 bata -84c06e996a7a-

Fixed by 3610f1fc43d0

In T52586#476128, @Peter Fog (tintwotin) wrote:

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

How about allowing the Sequencer run in a "local" scene different from the "global" scene on the same screen? That way the global scene(screen setting) could be switched as the scenes changes in the sequencer(by a script), but not the contents of the sequencer(area setting). That way the annoying problem of changing the scene also changing the timeline contents of the sequencer could be avoided.

This seems to be a short-term, and patchy fix to Blender not being able to handle an ideal workflow. I really hope the idea of a "global" sequencer is being looked at by the Blender Foundation.

@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.