LINUX.ORG.RU

Новая (возможно) концепция универсального редактора ждет критики

 ,


0

3

Пришла такая идея: пишем оболочку редактора, которая обладает рабочей областью, механизмом масштабирования, панелью инструментов слева, деревом объектов справа, классической панелью инструментов сверху. Ну что-то типа корела какого-нибудь.

Дальше, весь код, необходимый для обработки конкретного формата данных, в т. ч. диалоги, кнопочки, ресурсы, логику кладем в динамическую библиотеку, код которой, в текстовом виде, кладем прямо в файл данных (размер не такой уж и серьезный, особенно если сверху zlib'ом пройтись)

Редактор, открывая файл, смотрит в специальном поле какой формат и какой версии там используется, и, если у него нет соответствующей динамической библиотеки готовой, достает сорцы из файла, компилирует, кладет себе в специальный каталог, динамически ее подгружает, обогащается всякими нужными кнопочками, механизмами обработки соответствующего формата.

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

Все бы было хорошо, но я вижу одну очень страшную проблему - вирусы (ну или вредоносное ПО) и как принципиально все спроектировать чтоб свести эту проблему на нет - я не придумал. Ну можно завести под редактора отдельного пользователя и урезать в правах, можно chroot, можно виртуалку вообще, но это все не то. Вот, выкинул концепцию сюда, вдруг кто что годное придумал...

ЗЫ: все это пьянство никто не мешает сделать кроссплатформенным, это тоже стоит учитывать. К тому же важным преимуществом является независимость от Сети, что срезает возможность централизованной борьбы с вредоносным ПО.

★★★★★

Последнее исправление: ymn (всего исправлений: 1)

Ответ на: комментарий от pihter

Из преимуществ: кроссплатформенность непревзойденная

Ты когда-нибудь портировал код между платформами? Попробуй, сразу розовые очки разобьются о жестокую реальность.

feofan ★★★★★
()
Ответ на: комментарий от pihter

Ну сколько могут весить исходники гимпа? Ну 20 мб - потолок!

Ну ок. Сколько времени на твоей машине собирается LibreOffice, например?

feofan ★★★★★
()
Ответ на: комментарий от emulek

не взлетит, если будешь разбрасываться на несколько тулкитов и ЯП.

В нескольких тулкитах смысла не вижу. Планирую Qt, но, если кому-то захочется, переписать это на GTK - будет плевое дело, ящитаю, ибо там ничего тулкитозависимого не предвидится.

А несколько ЯП - совсем не помеха, их количество ограничивается только количеством компиляторов, доступных редактору. То есть, автор «плагина» волен написать его на любом ЯП, который умеет создавать динамические библиотеки с stdcall'ами. Естественно, С и С++ будут в числе первых, но не единственных.

минус в том, что задолбаешься писать обёртки, если захочешь засунуть скажем glibc в php

И зачем мне это? :) разве на php можно написать динамическую библиотеку?

ну попробовать-то никто не мешает.

О да :)

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

избежать включения иконок и тд в каждый файл
особенно, учитывая что я, by design, собираюсь по каждому файлу еще и gzip'ом проходиться

Так это в корне меняет дело! Претензий больше не имею.

anonymous
()
Ответ на: комментарий от emulek

прав. Иначе ты-бы уже был емакером или вимером, и не страдал-бы х*ёй.

Э! Это исследование нового подхода! Я бы попросил! :D

Может и так... А вообще - много программ, хороших и разных, не? :)

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

исследование нового подхода

Emacs'у уже много лет. А таскать исходники внутри каждого файла ИМХО глупо. Проще таскать, например, ссылку. По той простой причине, что каждый файл будет на порядки меньше весить. Представь, как тебя могут возненавидеть, например, пользователи gprs. Им придется с каждым файлом твоего формата скачивать софт для его обработки.

feofan ★★★★★
()
Ответ на: комментарий от emulek

ну типа подпись есть GnuPG

Это спасибо, посмотрю.

Песочниц — увы, нет. Даже в линуксах везде по своему.

А вот тут, думал, присоветуете чего :(

То есть документ гарантированно сработает в этом редакторе, не смотря на версии.

как он сработает на Qt5 без Qt4?

а какое документу дело до тулкита? Там логика работы редактора. Сам редактор будет устанавливаться на машину пользователя как и любая другая программа, с соответствующими зависимостями. А логический код, что документ будет носить с собой, будет говорить основной программе: «нарисуй кнопочку такую-то там-то там-то, поставь ей такой-то значек, при нажатии вызови такую-то функцию» а уже основная программа отрисует все как надо.

Соображашь? Логику - с собой в документ, всякое другое, по возможности, в редактор.

у меня одни и те же либы и так УЖЕ загружены.

да, но это не те либы. те, про которые я - еще никто не написал, они не могут быть у тебя загружены :)

pihter ★★★★★
() автор топика
Ответ на: комментарий от emulek

Не, я к тому, что делать это на компилируемых ЯП - тлен.

в этих словах ИМХО есть смысл. ТСу бы задуматься...

Да я бы рад, но в толк не возьму: чем вы заменить-то предлагаете? Предложили бинариками, но это - не то. А чем еще? Скриптами на Lua или JavaScript'е?

pihter ★★★★★
() автор топика
Ответ на: комментарий от unborn

Какими известными механизмами сегодня можно

Ну тут действительно тебе eclipse в руки. Только интерфейс там наркоманы делали и ты больше времени потратишь на разработку плагина к этому бегемоту чем на игру.

Воу, воу, воу! Эклипс сам подгрузит нужный плагин? Мой Вася-друг, которому я отправлю файлик, даже не должен будет ни о чем побеспокоиться?

pihter ★★★★★
() автор топика
Ответ на: комментарий от emulek

например я не умею DLL. Увы.

Если умеешь С++, то научишься, прочитав статейку, за 15 минут, при желании.

Я даже по-русски «привет мир!» не нарисую, ибо уверен, что wchar_t — годный контейнер для юникода.

Это все наживное :)

А на пользователей говноосей мне насрано

А мне - нет. Да так даже интереснее писать. Для меня программирование таких штук - хобби :)

Но эти 95% пользователей почему-то меня не любят...

Точнее ЛЮТО БЕШЕНО НЕНАВИДЯТ за моё УМВР.

Да винда тоже имеет свои сильные стороны. У кого мозги есть и ей как-то пользуются.

ЛЮТО БЕШЕНО НЕНАВИДЯТ

Как можно, ты ведь такой приветливый парень ? :D

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Мой Вася-друг, которому я отправлю файлик, даже не должен будет ни о чем побеспокоиться?

Нет. Ты дашь Васе-другу, url на то где лежит твой плагин собранный в джар. Вася забьет его в список плагинов и после установки откроет твой файл. Что не так? Или ты хочешь чтобы Вася просто открыл твой файл, и потом видел диалоги вроде «Подождите идет поиск соответствующего плагина» «Ага нашли» «Ага качаем» и файл открывается. Где-то я это уже видел...

unborn
()
Ответ на: комментарий от pihter

твоя «киллер-фича» выглядит так: мы берем весь фарш функциональности редактора определенного формата приделываем к данным (причем, мы делаем это в каждом документе), я правильно распарсил?

И получаем, грубо говоря, 20 метров фарша + 20 кб данных, которые надо редактировать. И так в каждом документе!

Это прорыв, ящитаю..

aol ★★★★★
()
Ответ на: комментарий от pihter

разве на php можно написать динамическую библиотеку?

просто сам php юзает динамические библиотеки. Через жопу. Ты хочешь сделать что-то похожее на php. Ну делай конечно... Никто не против.

emulek
()
Ответ на: Зачем мусорить кодом? от DonkeyHot

Зачем мусорить кодом?

Такую концепцию я придумал :) хочу реализовать из академического интереса. плюсы есть. уж для некоторых ниш - вообще бесспорные.

adduser ктотодругой && mail -s 'посмотри файл' 'ктотодругой@где.он.там' <<<ssh -X ктотодругой@$HOSTNAME мойредактор мойфайл

А если у него там винда? А если у нас жопарез вместо интернета? А если файл гиговый? А если их таких у меня полторы тыщи?

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

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Может и так... А вообще - много программ, хороших и разных, не?

да. Только для гуёв до сих пор не придумали нормального текстового редактора. Увы.

emulek
()
Ответ на: комментарий от anonymous

pihter, PHP-программист:

ты че, следил за мной? :)

Lisp-программист: (пожимает плечами)

Владеет, очевидно, какой-то скрытой от нас смертных мудростью, но делиться не хочет, кроме как советами перейти всем на лисп.

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Песочниц — увы, нет. Даже в линуксах везде по своему.

А вот тут, думал, присоветуете чего

делить на ноль нельзя. Увы. Вот в маздае пытались. Не вышло.

а какое документу дело до тулкита?

если он с собой все либы тащит? Ага, никакого. Если вправду ВСЕ либы тащит.

«нарисуй кнопочку такую-то там-то там-то, поставь ей такой-то значек, при нажатии вызови такую-то функцию» а уже основная программа отрисует все как надо.

вот это «как надо» и есть тулкит.

emulek
()
Ответ на: комментарий от yoghurt

Из преимуществ: кроссплатформенность непревзойденная - раз

Как раз таки нет.

Ни одна Java и .NET не умеют столько платформ, сколько С. Или я не прав?

не привязанность к ЯП

Как раз таки да

Я думаю, хотя точно и не знаю, что динамические библиотеки больше кто умеет создавать, чем байт-код Java.

И вообще, предложи уже альтернативу разделяемым библиотекам, а то я не знаю против чего обороняюсь :) наугад от жабы :)

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Если умеешь С++, то научишься, прочитав статейку, за 15 минут, при желании.

нет такого желания, говном обмазываться.

Да винда тоже имеет свои сильные стороны. У кого мозги есть и ей как-то пользуются.

да пусть пользуются. Я не против. Секс в противогазе, в гамаке и на уровне 3000м — это круто. Но не для меня.

emulek
()
Ответ на: комментарий от anonymous

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

Самоутверждаешься? По делу то скажешь чего или так и будешь обсирать идею? Сильно не нравятся какие-то моменты в моей концепции - выдели их мышкой и нажми alt+f4! :)

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Владеет, очевидно, какой-то скрытой от нас смертных мудростью, но делиться не хочет

тебе уже сказали — в емаксе ЭТО всё уже сделано. И даже работает.

emulek
()
Ответ на: комментарий от pihter

Java и .NET не умеют столько платформ, сколько С

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

Я думаю, хотя точно и не знаю, что динамические библиотеки больше кто умеет создавать, чем байт-код Java.

Настоящие динамические библиотеки - удел Си и Си++. Т.о. написание расширений сводится до этих не самых высокоуровневых языков.

И вообще, предложи уже альтернативу разделяемым библиотекам, а то я не знаю против чего обороняюсь

Банально - вложенный в документ сценарий на питоне/руби/луа, который расширяет редактор при загрузке документа нужными сущностями/командами/etc.

yoghurt ★★★★★
()
Ответ на: комментарий от feofan

Ты когда-нибудь портировал код между платформами? Попробуй, сразу розовые очки разобьются о жестокую реальность.

Да. Правда немного. И только то, что сам писал. Код, упакованный в динамические библиотеки, прекрасно переезжает из винды в линух и обратно и требуется только откомпилировать исходник в dll-ку или so-шку. Основной бинарик отлично динамически линкуется. При условии, что в динамической библиотеке нет платформозависимого когда.

В чем проблема-то? Все ж шикааааарно :) я не знаю только как быть с безопасностью: ну подписывание - раз и все? Больше никто ничего не посоветует?

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Ни одна Java и .NET не умеют столько платформ, сколько С. Или я не прав?

не прав. Сишечка потому и умеет Over9000 платформ, потому-что она РАЗНАЯ. Там даже целые числа на каждой платформе свои. Это в яве ты пишешь код, который работает везде одинаково. В сишечке ты пишешь код, который везде разный. Потому, в сишечке, шаг влево, шаг вправо === хрен знает что. UB по нашему.

emulek
()
Ответ на: комментарий от feofan

Ну ок. Сколько времени на твоей машине собирается LibreOffice, например?

Понятия не знаю :) Даже если и долго - это один раз. И я предлагаю заменять им не флагманские, самые тяжелые продукты, а кучу мелкой шушеры от и до.

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

При условии, что в динамической библиотеке нет платформозависимого когда.

Такой код в реальной жизни встречается чуть реже, чем всегда.

я не знаю только как быть с безопасностью: ну подписывание - раз и все? Больше никто ничего не посоветует?

Репы давно изобретены.

feofan ★★★★★
()
Ответ на: комментарий от feofan

исследование нового подхода

Emacs'у уже много лет.

не спорю, но, уверен, это не совсем то, что предлагаю я. Я вообще не понимаю, че вы в меня им просто так, голословно, тычите. Объясните чего там такого, из того, что я предлагаю! Точь в точь? Нет? Тогда как там?

А таскать исходники внутри каждого файла ИМХО глупо

Да, но - нет :)

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

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

Проще таскать, например, ссылку. По той простой причине, что каждый файл будет на порядки меньше весить.

Да, но - нет :) много преимуществ теряется: нужен интернет - раз, никто не гарантирует что там, куда смотрит ссылка, оно пролежит хоть десять лет. И Столман не одобрил бы. :)

Представь, как тебя могут возненавидеть, например, пользователи gprs. Им придется с каждым файлом твоего формата скачивать софт для его обработки.

Да, но речь будет о килобайтах-мегабайтах, а не о гигах.

pihter ★★★★★
() автор топика
Ответ на: комментарий от unborn

Нет. Ты дашь Васе-другу, url на то где лежит твой плагин собранный в джар. Вася забьет его в список плагинов и после установки откроет твой файл. Что не так?

А то, что место, куда смотрит url, может и пропасть и васе, для установки потребуется тянуть плагин по сети. (а в моем случае, я мог бы и на флешке передать)

И, если попытаться реализовать таким образом тысячу мелких редакторов, то мне придется поддерживать тысячи плагинов в актуальном состоянии, хостить их, а если в эклипсе апи сменят? все переписывать? А как я перепишу редактор формата, кторого я в глаза не видел? Значит он когда-то перестанет открываться...

Плюс, пользователю в твоем случае все же приходится устанавливать плагин, в моем - все само.

pihter ★★★★★
() автор топика
Ответ на: комментарий от aol

твоя «киллер-фича» выглядит так: мы берем весь фарш функциональности редактора определенного формата приделываем к данным (причем, мы делаем это в каждом документе), я правильно распарсил?

Да. Только не весь фарш, а только логику.

И получаем, грубо говоря, 20 метров фарша + 20 кб данных, которые надо редактировать. И так в каждом документе!

Для больших редакторов это не выгодно, для маленьких - выгодно.

pihter ★★★★★
() автор топика
Ответ на: комментарий от emulek

Только для гуёв до сих пор не придумали нормального текстового редактора.

Ну вот уж на этом рынке такое разнообразие, что вообще. Чем тебя не устраивают существующие? (для консоли, как я понял, претензий нет?)

pihter ★★★★★
() автор топика
Ответ на: комментарий от Corey

пока ТС не начнет есть мозоли, не взлетит...

Смеялся :D

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

Любой «расширяемый» редактор обречен на провал, если его автор считает, что писать расширения это как два пальца об асфальт.

// Да, шишка хорошая и до сих пор болит.

anonymous
()

Отнацполился и прибежал редактор писать?
Похвально!

Все бы было хорошо, но я вижу одну очень страшную проблему - вирусы (ну или вредоносное ПО) и как принципиально все спроектировать чтоб свести эту проблему на нет - я не придумал. Ну можно завести под редактора отдельного пользователя и урезать в правах, можно chroot, можно виртуалку вообще, но это все не то.

ЯТОЖЕ вижу проблему, но вирусов не вижу.

Deleted
()
Ответ на: комментарий от emulek

вот это «как надо» и есть тулкит.

Дак его рисует программа-редактор, а не логическая либа, которая с собой таскается. В чем беда-то?

Ну обновлю я основную программу, хоть с Qt на PihterToolkit, либа, которая таскается с файлами этого и не заметит!

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

/0

я про *.so файлы. Тебе тут правильно сказали, что это всё C/C++, а там никакой кросплатформенности не будет. И даже кросстулкитовости. Пиши на C++/Qt4, и не заморачивайся. И не надейся, что это кто-то осилит переделать. Впрочем, kDevelop уже написан.

emulek
()
Ответ на: комментарий от pihter

Ну вот уж на этом рынке такое разнообразие, что вообще. Чем тебя не устраивают существующие? (для консоли, как я понял, претензий нет?)

потому-что всё === неюзабельное говно, по сравнению с VIm'ом.

emulek
()
Ответ на: комментарий от pihter

Точь в точь? Нет?

Нет

Тогда как там?

Осиль матчасть.

Сейчас для этих целей используется килограмм маленьких одноразовых практически редакторов, или просто текстовый редактор. или вообще ничего.

текстовый редактор

Отличное решение. Откроется, даже если исчезнут все компиляторы языка, который ты выбра для написания своих so-шек.

Да, но речь будет о килобайтах-мегабайтах, а не о гигах.

А если файлов нужно обработать тысячи?

feofan ★★★★★
()
Ответ на: комментарий от emulek

Лучше конечно на Lua

Ну, может и так, только Lua-программистов наверное меньше, чем Си-шников... Можно ведь сделать so-шку, которая обеспечит поддержку Lua - и вперед. Опять же, все сработает

pihter ★★★★★
() автор топика
Ответ на: комментарий от emulek

нет такого желания, говном обмазываться.

Ты конкретно про DLL или so-шки тоже не умеешь и не хочешь?

pihter ★★★★★
() автор топика
Ответ на: комментарий от pihter

Дак его рисует программа-редактор, а не логическая либа, которая с собой таскается.

рисует как раз тулкит. А программа-редактор только говорит тулкиту, где и какую рисовать кнопочку.

Ну обновлю я основную программу, хоть с Qt на PihterToolkit, либа, которая таскается с файлами этого и не заметит!

ага. Не заметит. Заметит юзер, когда у него кнопки будут НЕ ТАМ и нажиматься НЕ ТАК.

emulek
()
Ответ на: комментарий от pihter

Твой редактор взлетит только в одном случае. Если он будет свистеть и пердеть громче саблима. Как это ни странно, но даже вимеры и емаксеры на это ведутся.

Визуальная требуха в ущерб функциональности — тренд последнего времени, начатый айфоном. А тем временем, там ни одной нормальной читалки так и не появилось. Это печально.

А ты пытаешься об архитектуре рассуждать, лол.

anonymous
()
Ответ на: комментарий от pihter

Ну, может и так, только Lua-программистов наверное меньше, чем Си-шников..

больше. Ибо каждый настоящий сишник знает 50 других ЯП. В т.ч. и что-то типа Lua. (что-бы обсирать конечно. Но и написать на нём нужный плагин сможет).

Можно ведь сделать so-шку, которая обеспечит поддержку Lua - и вперед. Опять же, все сработает

говорю-же, хорош трепаться, делай.

emulek
()
Ответ на: комментарий от pihter

Ты конкретно про DLL или so-шки тоже не умеешь и не хочешь?

я про маздай.

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