Change Details

This task should coordinate efforts for rewriting operators to python. == Motivation == - With VSE module being rather niche use-case for Blender, it also gets very little attention from contributors. Those willing to contribue in area of operators now can contribute python code. - Python code is easier to maintain. - Python operatos will validate and test API. I believe, that all operators should use API only, regardless of language. Personally I would like to have all VSE specific operators in one place, with preference for python, but I am not taking hard stance here. I am aware, that operators written in python will be slower than pure C implementation. However new operator can massively reduce time required for editing. We should find practical limit of each operator and consider if this limit is acceptable. However I think that benefits will cover potential performance losses multiple times. == Rewrite possible == If your contribution is wrapping function of another operator(s), it is better to rewrite all operators, that would normally be called in sequence. Example: operator that is doing cut, deleting strips and removing gap in one action. - mute - lock - slip - snap - swap - strip_jump - offset_clear - gap_remove - change_effect_input - export_subtitles - rendersize - cut - This one has quite complex implementation. I reserve to work on this. - gap_insert - this could be tool / modal for now to allow to choose width of gap - reassign_inputs - must check for recursion - change_path - may require API changes - swap_data - may require API changes - select_grouped - I would rethink this one a bit to be a search based on selected properties, independent of current selection. == New == Before contribution, adding item should be consulted. https://blender.chat/channel/vse is prefferable channel to do this. == Remove / review == - unmute - should be mode of mute - unlock - should be mode of lock - SequencerDeinterlaceSelectedMovies - remove, too specific to validate operator handling of checkbox - swap_inputs - duplicates function of change_effect_input == Implemented API == These operators are technically duplicating API functions. Before rewriting these I have to look at current implementation and consult if they should be rewritten. - delete_strip - scene_strip_add - movieclip_strip_add - mask_strip_add - movie_strip_add - sound_strip_add - image_strip_add - effect_strip_add - strip_modifier_add - strip_modifier_remove == Add to API == - Sequence.duplicate - ImageSequence.images_separate - SequenceModifiers.move - SequenceModifiers.duplicate == Conventions == - If operator can not run, or finish action, report a message explaining why (in human language) - No hacks. If there is some issue, that is not clear how to resolve, let me know - Use https://docs.blender.org/api/blender2.8/bpy.ops.sequencer.html as a reference of current operator options / modes - Avoid calling other operators from within operator.

This task should coordinate efforts for rewriting operators to python. == Rewrite ==Motivation == - With VSE module being rather niche use-case for Blender, it also gets very little attention from contributors. Those willing to contribue in area of operators now can contribute python code. - Python code is easier to maintain. - Python operatos will validate and test API. I believe, that all operators should use API only, regardless of language. Personally I would like to have all VSE specific operators in one place, with preference for python, but I am not taking hard stance here. I am aware, that operators written in python will be slower than pure C implementation. However new operator can massively reduce time required for editing. We should find practical limit of each operator and consider if this limit is acceptable. However I think that benefits will cover potential performance losses multiple times. == Rewrite possible == If your contribution is wrapping function of another operator(s), it is better to rewrite all operators, that would normally be called in sequence. Example: operator that is doing cut, deleting strips and removing gap in one action. - mute - lock - slip - snap - swap - strip_jump - offset_clear - gap_remove - change_effect_input - export_subtitles - rendersize - cut - This one has quite complex implementation. I reserve to work on this. - gap_insert - this could be tool / modal for now to allow to choose width of gap - reassign_inputs - must check for recursion - change_path - may require API changes - swap_data - may require API changes - select_grouped - I would rethink this one a bit to be a search based on selected properties, independent of current selection. == New == Before contribution, adding item should be consulted. https://blender.chat/channel/vse is prefferable channel to do this. == Remove / review == - unmute - should be mode of mute - unlock - should be mode of lock - SequencerDeinterlaceSelectedMovies - remove, too specific to validate operator handling of checkbox - swap_inputs - duplicates function of change_effect_input == Implemented API == These operators are technically duplicating API functions. Before rewriting these I have to look at current implementation and consult if they should be rewritten. - delete_strip - scene_strip_add - movieclip_strip_add - mask_strip_add - movie_strip_add - sound_strip_add - image_strip_add - effect_strip_add - strip_modifier_add - strip_modifier_remove == Add to API == - Sequence.duplicate - ImageSequence.images_separate - SequenceModifiers.move - SequenceModifiers.duplicate == Conventions == - If operator can not run, or finish action, report a message explaining why (in human language) - No hacks. If there is some issue, that is not clear how to resolve, let me know - Use https://docs.blender.org/api/blender2.8/bpy.ops.sequencer.html as a reference of current operator options / modes - Avoid calling other operators from within operator.