LINUX.ORG.RU

[GSoC][Kate]Прошу совета

 ,


0

1

Очень хотелось бы поучаствовать в GSoC, как, думаю, и многим здесь. Приглянулись мне идеи из Kate. Одна из идей — улучшить Vi-mode.

Я сначала почитал список рассылки и увидел там ещё как минимум троих таких же как я, т.е. хотящих пилить Vi-mode. Два из них какие-то левые, а один запилил патч. Я по irc связывался с ментором той идеи, он сказал, что ещё ничего не определено, но он надеется, что уже есть тот, кто будет делать.

Я почитал код, но вот тут-то... Код выглядит слегка... Нувыпонели. Не, ну понятно, что он появился 3 года, а за такое время любой код обрастёт костылями. Просто если я напишу своё предложение по поводу редизайна, то это будет плохо? Задача ведь, по идее, только исправить баги.

В списке рассылке я также встретил простой баг, на который написал тривиальный патч, и ещё один баг, который видел давно и хотел даже пофиксить, но даже не запостил :( В общем, только что я написал патч на этот баг, но для этого пришлось внедрить ещё пару костылей...

В общем вопрос: предлагать им редизайн, предложить просто, без редизайна, или предложить на какую-нибудь другую идею?

★★★

Текущая архитектура Kate Vi-mode такова:

есть классы режимов, которые наследуются от одного базового, но при этом имеют разный интерфейс, а базовый используется только для хранения общего кода. Большинство работы делается внутри одного класса режима. Команды являются экземплярами класса, который хранит указатель на метод класса режима. Все объекты, которыми оперируют команды являются просто полями в классе режима, аргументы в команду тоже передаются через поля класса режима.

Мне почему-то кажется, что это совсем не ООП, хотя, может ООП здесь просто не нужно... VIM же без всякого ООП.

Но мне почему-то кажется, что нужно сделать такую архитектуру:

Есть дерево классов режимов, режим содержит в себе map команд и map motionов. Каждая комманда и motion — экземпляр отдельного класса, но все унаследованы от абстрактного Command или Motion. Команда регистрируется через registerMapping режима и таким образом плагины могут регистрировать свои команды для отдельных режимов. Когда режим считал команду, он смотрит, нужен ли ей motion и если нужен, считывает его, затем вызывается некоторый метод exec команды, которому передаётся контекст, в котором находится собственно то, что мы собрались править, список регистров и прочее.

По идее, но зато всё будет более инкапсулировано, суть примерно та же, но придётся переписывать много кода, а это явно плохо...

Блин, наверное, как-то сумбурно рассказал, просто уже 5 утра.

Что можно использовать для рисования дизайна? UML же, но чем его править и рендерить?

Yareg ★★★
() автор топика

Такой обширный рефакторинг тянет на отдельный проект, если я себе все правильно представляю. Поэтому в рамках данного могут и не принять - перестрахуются, побоятся, что не справишься и т.п. А вообще лучше непосредственно в списке рассылки это обсудить

yoghurt ★★★★★
()

> Просто если я напишу своё предложение по поводу редизайна, то это будет плохо?

В рамках GSoC будет. В том плане, что займет кучу времени непонятно с каким результатом (не факт, что редизайн выйдет относительно безбажным). Я не знаю, сколько строчек кода занимает Vi-mode, но думается, что немало. Переговорите все-таки с организаторами. Если они согласны, беритесь. Если нет, продолжайте костылять. Хуже вряд ли станет.

//Пользователь Kate c Vi-mode.

Milky_Way
()

имхо, смотри по времени, уложишься ли. Лучше доделать неидеальную концепцию, чем не доделать действительно хороший подход.

unC0Rr ★★★★★
()

самое интересное, что для GTK клавиатурная схема настраивается в текстовом файле (конечно, два режима vi она без дополнительных костылей эмулировать не сможет, но в любом случае - гораздо меньше телодвижений) и работает в любом(ну, почти в любом, большая часть говноподелок на вебките срать хотела на системные настройки) gtk-шном приложении

Такие дела...

lazyklimm ★★★★★
()

Обсуди это в рассылке. Только подготовь аргументы повесомее.

Из личного опыта(=ИМХО) могу сказать что со временем костылей становится столько что они под собственным весом могут начать падать. Поэтому часто лучше один-два раза переписать чем до посинения бороться с кодом.

true_admin ★★★★★
()

Если справишься, форкни и покажи рабочий вариант :-)

jreznot
()

>улучшить Vi-mode

Берется GVim и переписывается на Qt

devl547 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.