» SciTE Ru-Board Edition

alrusdi81

Цитата:

В лоб сделать точно так же как в версии для Windows не получится.
Так как используются функции WindowsAPI, которые в Linux не доступны:
::MapVirtualKeyA
::GetKeyboardState
::ToAscii
Что делает это усовершенствование? Попробуем его реализовать под Linux.

Готов помочь, в смысле рассказать что происходит, т.к. под ГТК реализовать возможности нет.
Эти функции используются для получения нажатого символа.
В стандартный обработчик OnKey вообще символ не приходит, приходит код нажатой клавиши (легбез, на клавиатуре 101 клавиша еще легбез - по поводу преобразований русских букв в латинские, как я понял вопрос - если нажата клавиша G, то не обязательно вводимый символ будет G может быть GgПп это на моих раскладках), соответственно совсем и абсолютно не ясно что же за символ вводит пользователь, в винде для этого есть функция ToAscii. Нужно проследить как в ГТК достается символ и тоже выкорчевать, ведь в OnChar он символ подает а не код клавиши, значит достать его реально, просто я не знаю как это в линуксе.
Ну и повторяю:

Цитата:

Если ничего не сможешь сделать, а скомпилеть очень надо, то сделай так:
extender->OnKey(event->keyval, cmodifiers, 0)

Тогда наши скрипты которые завязаны на функцию OnKey просто работать не будут

Добавлено:
Вот что выдал гугл по этому поводу:
http://mail.gnome.org/archives/gtk-app-devel-list/2003-December/msg00352.html
http://svn.openi18n.org:8081/repos/im-sdk/trunk/program/iiim-properties/src/iiim-properties-hkc.c
http://library.gnome.org/devel/gdk/unstable/gdk-Keyboard-Handling.html#gdk-keyval-to-unicode

Посмотрел из чего состоит GdkEventKey и пришла в голову такая мысль:
А может искомое значение тупо содержится в event->string и парится не надо... Если length > 1 то 0 передавать.

Нет, event->string сейчас deprecated
Вот так делают:

Код:
gchar keybuf[9];
guint32 uchar = gdk_keyval_to_unicode (event->keyval);
int len = g_unichar_to_utf8 (uchar, keybuf);
keybuf[len] = '\0';

alrusdi81

Цитата:

То есть в русской раскладке будет мусор передаваться, а в латинской нормальный буквы

Не понял, причем совсем. Как ты букву 'ф' в два байта запихнул? Скайте не юникодный редактор, или под ГТК юникодный? Что разве нельзя в ASСII варианте получить? Когда один символ - 1 байт? Поищи, должна быть такая функция.


Цитата:

Может быть будем передавать строку? Или чревато переполнением буфера?

Да можно и строку передавать... Вот только она же в анси приходит в скрипт, а не юникодной...

Я не совсем понимаю как это сделано в линуксе, распиши подробнее. Если там вся работа с текстом в юникоде, в том числе отправка в lua, то сделаю строку передавать.


Цитата:

Поясни плз что делает остальной код? Отсеивает небуквенные символы?

1. Тут исправлена проблема с мертвыми клавишами, когда вызываешь функцию ToAscii - их состояние сбрасывается, приходится так изворачиваться.
2. Если вводится символ через код, т.е. Alt+цифры то нужно ToAscii с другим флагом запускать иначе сбросится состояние.
Не знаю на сколько актуальны эти проблемы под линукс, лучше после доработки проверить.
Подробнее об этом тут
http://forum.ru-board.com/topic.cgi?forum=2&topic=3339&start=257&limit=1
http://code.google.com/p/scite-ru/issues/detail?id=33&can=1&colspec=ID%20Priority%20Type%20Opened%20Modified%20Defect%20Status%20Owner%20Summary
http://code.google.com/p/scite-ru/issues/detail?id=54&can=1&colspec=ID%20Priority%20Type%20Opened%20Modified%20Defect%20Status%20Owner%20Summary

Гм... Если не использовать Юникод в Скайте под Линукс, то он сможет только отображать русские буквы, но вводить их не получится (вопросики будут вместо букв, то есть тот самый мусор, о котором я говорил выше). Да и 'ф' в кодировке utf-8 два байта.
http://scite.ruteam.ru/scite/ru-fonts-for-scite-for-linux

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

После установки заглушки

MenuEx SciTEGTK::GetMenu(int) {
    return MenuEx();
}

файл SciteGTK.cxx скомпилировался. Идем дальше.

Файл SciTEBase.cxx

Предлагаю функцию GUIDToStr включать только в версию для Windows:

Код:
//!-start-[VarAbbrev]
#define FINALLY(ARG) catch(...){ARG;}ARG;
#if PLAT_WIN
inline void GUIDToStr(const GUID &g, char*a){
    sprintf(a,"{%X-%X-%X-%X%X-%X%X%X%X%X%X}",(unsigned int)g.Data1,
        (unsigned int)g.Data2,(unsigned int)g.Data3,
        g.Data4[0],g.Data4[1],g.Data4[2],g.Data4[3],g.Data4[4],
        g.Data4[5],g.Data4[6],g.Data4[7]);
}
#endif
//!-end-[VarAbbrev]

alrusdi81

Цитата:

Файл SciTEBase.cxx

Закоммитил изменения бери из SVN


Цитата:

После установки заглушки
MenuEx SciTEGTK::GetMenu(int) {
return MenuEx();
}

Ну, с меню мы еще повоюем У меня что-то такое вот чувство )))


Цитата:

лучше строку передавать но пока давай оставим как есть, просто на заметку будет, что нужно поправить.

Т.е. работать будет только для латинских буков?
Ок, че нить придумаем

Добавлено:
alrusdi81
Вот в это место приходят русские буквы?
SciTEBase.cxx [строка 4760] :
Код: handled = extender->OnChar(static_cast<char>(notification->ch));

alrusdi81 BioInfo
Мужики, извините конечно, ОЧЕНЬ ВАЖНОЕ дело вы затеяли...
А я боюсь что раскурёжите код - пойдут какие нить глюки...
Нет, это - нормально... Все постепенно вами же и починится и придет в норму. Причём в норму придет лучшую, чем сегодняшняя... Но, время...
А я хотел сборку очередную нагара выдать, НО достали меня уже с Issue 104.
Может поправите??? (мне кажется что это - очень быстро и несложно).
А я бы сборку упаковал по текущему состоянию.
И курочте код дальше во всеобщее благо
Если я сильно ошибаюсь и задача, поставленная в Issue 104 отоймет у вас более получаса времени, то покорно замолкаю...

BioInfo

Цитата:

Вот в это место приходят русские буквы?
SciTEBase.cxx [строка 4760] :

Оригинальная версия скайта вообще символов туда не посылает, а нашу версию мы еще не скомпилировали, чтобы это проверить.
Меню в GTK динамически изменять можно, но только все целиком (то есть перестраивать его). Это еще вопрос как оно себя поведет в реальных условиях, особенно когда меню видно в момент его перестроения.
Может сделать бранч с Линуховой версией, чтобы не "раскурёжить код" и чтобы "глюки не пошли"? Собственно я могу и локально собрать и пользоваться, но во первых хочется чтобы еще кто-то код мог посмотреть, а во вторых может еще кому то понадобится этот редактор в Линукс (мои поиски альтернативы для него успехом не увенчались, пользуюсь Kate в данный момент, но ему до скайта далеко... Ну или я к нему просто привык).

alrusdi81

Цитата:

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

Вот это новость!!!! OnChar под линуксом не работает.


Цитата:

Это еще вопрос как оно себя поведет в реальных условиях, особенно когда меню видно в момент его перестроения.

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


Цитата:

Может сделать бранч с Линуховой версией, чтобы не "раскурёжить код" и чтобы "глюки не пошли"?

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

Добавлено:
alrusdi81
Я думаю нужно прояснить все таки... Функция NotifyChar должна вызываться вот здесь:
Editor.cxx [строка 3447] :
Код: void Editor::AddCharUTF(char *s, unsigned int len, bool treatAsDBCS) {

OnChar под линуксом работает, я ошибся. Проверю принимает ли эта функция русские символы.

BioInfo VladVRO
Огромное личное СПАСИБО за активное участие в реализации Issue 104!
Пакет собрал по ревизии 675. Завтра с чьей нибудь помощью его выложу.
И скрипт, который без реализации Issue 104 работал бы только наполовину - тоже.

BioInfo alrusdi81
Спокойно продолжайте свой крайне нужный людям диалог, меняйте код на SVN, эксперементируйте... Морально - я с вами

Как и следовало предполагать, OnChar получает вместо русских символов всякий хлам. По крайней мере в режиме Юникод, когда в настройках указываешь:

code.page=65001
LC_CTYPE=en_US.UTF-8

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

Если же говорить про OnKey, то мой код для GTK, приведенный выше, будет нормально передавать в lua русские символы, при условии, что обработчик будет получать все байты строки, а не только первый.

alrusdi81
Цитата:

Если кто-то силен в английском, то эту багу можно запостить в официальную версию

Насколько я понимаю, это - не бага, а официальная позиция. Нейл уже несколько раз говорил что SciTE будет работать только с теми языками, которые перечислены в документаци в описании параметров code.page и output.code.page. Русский среди них не значится

Удалось мне скомпилировать SciTE_ru под Linux
Помимо исправлений уже внесенных в SVN, нужно добавить следущее в файл SciteGTK.cxx:

В декларацию класса SciteGTK добавить метод:

Код:
MenuEx GetMenu(int); //!-change- [ExtendedMenu]

alrusdi81
У тебя есть доступ к SVN? (если нет, то нужно получить, обращайся к mozers он все выдаст) Заливай сразу же изменения. Файлы с суффиксом GTK не влияют на сборку под виндой.


Цитата:

Как реализовать добавление пунктов меню через MenuEx пока ума не приложу. Необходима структура itemFactory, а она в приватных членах SciteGTK... Ковыряюсь. Есть идеи какие-нибудь?

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

BioInfo


Цитата:

Сделать паблик функцию GetItemFactory в SciteGTK.

Гм... А как добыть текущий экземпляр класса SciteGTK, чтобы вызвать из него GetItemFactory? )

С редактором кода холивар тут может быть) Я использую IDE Code::Blocks и на Windows и на Linux. Скорее всего в стандартной поставке его нет
http://mczim-debian.blogspot.com/2008/03/codeblocks-ubuntu.html

Если не ставить IDE то достаточно поставить пакеты:
build-essential, gdb, gcc, g++ и код писать в SciTE

Кроме того придется поставить libgtk2.0-dev

Дальше качаем исходники скайта, и по инструкции в README компилим

Цитата:

To build Scintilla, use the makefile located in the scintilla/gtk directory
    cd scintilla/gtk
    make
    cd ../..

To build and install SciTE, use the makefile located in the scite/gtk directory
    cd scite/gtk
    make
    make install

Только make install лучше не делать. Впрочем, под обычным пользователем это не должно получится, а под root ни в коем случае работать нельзя

alrusdi81

Цитата:

А как добыть текущий экземпляр класса SciteGTK, чтобы вызвать из него GetItemFactory?

вызвать функцию класса:
SciTEBase::GetApplicationInstance()

alrusdi81

Цитата:

OnChar получает вместо русских символов всякий хлам

Почему хлам? А по-моему это здорово, что символы приходят в Юникоде (UTF-8). В scintilla/src/UniConversion.h есть функции для преобразования между UTF-8 и UTF-16.
mozers

Цитата:

Нейл уже несколько раз говорил что SciTE будет работать только с теми языками, которые перечислены в документаци в описании параметров code.page и output.code.page. Русский среди них не значится

А там вообще не указаны никакие языки. Исключение сделано только для иероглифических мультибайтных 932, 936, 949, 950 и 1361 и UTF-8. Остальные определяются по системной кодовой странице (ANSI/OEM) и набору символов. Вполне разумно. Ведь всё равно без полноценной поддержки ОС не обойтись. Так что русский здесь на равных с остальными.

Цитата:

Почему хлам? А по-моему это здорово, что символы приходят в Юникоде (UTF-8).

Вот и я о том, что здорово. Только и в OnKey и в OnChar режется второй байт.

alrusdi81

Цитата:

Вот и я о том, что здорово. Только и в OnKey и в OnChar режется второй байт.

Прошу прощения, не посмотрел в каком контексте это было сказано. Судя по интерфейсу, действительно режется. Вот только исправлять придётся самим. Иначе Нейл попросту отмахнётся.
Lua работает с 8-битными символьными строками. Получается, придётся кодировать символы в utf-8, а в OnChar передавать фиксированную 4-байтовую строку? В любом случае, скрипты придётся перелопачивать и добавлять функции для удобной работы в Lua со строками разных форматов. Или "на лету" перегонять коды символов в однобайтовую кодировку, соответствующую системной кодовой странице. Но тогда как быть с двухбайтными кодировками? Рискну предположить, что OnChar не пользуется популярностью у японцев, китайцев, корейцев... Кто-нибудь в курсе?

Добавлено:
mozers
Ответ на сообщение

Цитата:

нафига мне нужен Юникод в gui.dll ??? Русский текст в любом контроле отображается без каких бы то ни было проблем...

Позади всей этой беспроблемности (на семействе NT) лежит работа с юникодными строками. Просто вся эта кухня скрыта от глаз.

Цитата:

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

Ну, luaCOM-то как раз вовсе не заточен под Юникод - совсем наоборот, и это наследство Lua, который с ним совершенно не работает. От этого проблемы, поскольку именно COM изначально работает с Юникодом. Проблема в том, что люди из западной языковой среды иногда совершенно забывают, что строка не есть последовательность однобайтных символов. На их счастье (и на нашу беду) символы с кодами ниже 128 (латиница, цифры, знаки препинания) в точности совпадают с таковыми из utf-8, отчего COM с радостью принимает их за этот самый utf-8, о коем писавший программу, возможно, и не помышлял.

cvaqlav

Цитата:

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

Зачем такое делать то? Нужно к одному формату все свести!

Цитата:

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

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

Цитата:

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

Вот это глобальный подход! Давай для начала сделаем для Русских, а потом и про китайцев можно думать

Цитата:

Позади всей этой беспроблемности (на семействе NT) лежит работа с юникодными строками. Просто вся эта кухня скрыта от глаз

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

BioInfo

Цитата:

Вот это глобальный подход! Давай для начала сделаем для Русских, а потом и про китайцев можно думать

Сейчас к людям надо помягше, а на вопросы смотреть ширше (c). Тут вот в чём дело. Можно запросто наделать костылей, которые потом будут только мешать.

Код: bool ScintillaWin::ValidCodePage(int codePage) const {
return codePage == 0 || codePage == SC_CP_UTF8 ||
codePage == 932 || codePage == 936 || codePage == 949 ||
codePage == 950 || codePage == 1361;
}

bool ScintillaGTK::ValidCodePage(int codePage) const {
return codePage == 0 || codePage == SC_CP_UTF8 || codePage == SC_CP_DBCS;
}

cvaqlav

Цитата:

Узким местом останется Lua с его однобайтными символами. Отсюда - глючный интерфейс OnChar

Да проблема на пустом месте, передовать туда не символ а строку и всего делов.

Цитата:

Что в этом плохого?

Нет ничего плохого в этом, наоборот я всеми четырьмя лапами за, просто я не вижу тут изящного и простого решения.

Поздравляю всех (и себя в том числе) с прекрасной новостью!
Наш новый автор cvaqlav выполнил долгожданную доработку Доновановской ext-gui.
Теперь ввод русских символов работает как надо

Как и в каком виде разместить доработку пока - неясно (просится в trunk\lualib\gui\ но хотелось бы этот момент как то согласовать со Стивом, которого пока нет). Поэтому временно положил исправленный gui_ext.cpp и откомпиленный gui.dll сюда.

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

Очень хотелось бы чтобы работа над библиотекой была продолжена (и не только со стороны Стива Донована). Есть и баги и пожелания. Хотелось бы чтобы и скрипт заинтересовал народ (некоторые вещи я никак не могу решить самостоятельно).

Добавлено:
ИМХО самая главная проблема gui.dll - невозможность ее нормальной работы при ее непосредственном запуске не из SciTEStartup.lua, а из произвольного lua-файла.
Абсолютно непонятно в чем этот gui.dll видит разницу??? Ведь и в первом и втором случае запуск происходит по dofile...

Вот - простенький пример, наглядно демонстрирующий проблему:
ext-gui-bug-demo.lua :
Код: require("gui")
window1 = gui.window("title")
window1:size(100, 200)
list1 = gui.list()
window1:client(list1)
list1:add_item ('caption1')
list1:add_item ('caption2')

list1:on_double_click(function(i)
if i ~= -1 then
local text = list1:get_item_text(i)
print(text)
end
end)

window1:show()

Сохранение размера и позиции окна в новом SciTE работает следующим образом:
Параметр save.position=1 включает сохранение.
После чего параметры position.left, position.top, position.width, position.height и position.maximize сохраняются в файле SciTE.session (это ж "додуматься" надо!)
В результате этого д#%@№*0го решения все сохраняемые параметры - уже не параметры в полном смысле этого слова. Т.е. извлечь их значения из скрипта невозможно.
props['position.width'] возвратит фигу с маслом и ни один скрипт работать не будет.
Сам виноват конечно... Проспал когда этот вопрос обсуждался на офф-форуме
Всех, проспавших вместе со мной "поздравляю"...
Хотел на офф-форуме хотя бы вслед вякнуть, но http://groups.google.com/group/scite-interest/ вдруг оказался уничтожен. Полный пипец...

Киньте кто ссылку, где можно сборку mingw скачать. Спасибо

dB6

Цитата:

Киньте кто ссылку, где можно сборку mingw скачать.

У нас же на сайте проекта
MinGW-5.1.4-gcc-3.4.5-mini.zip

Или тебе надо полный пакет?

vladvro

Цитата:

У нас же на сайте проекта
MinGW-5.1.4-gcc-3.4.5-mini.zip

Я таки совсем забыл про раздел downloads. Спасибо.


Цитата:

Или тебе надо полный пакет?

Не, не надо.

Хочу привлечь внимание программистов на Issue 105 и Issue 106.
Как мне кажется выполнение большинства пожеланий зависит исключительно от вашей заинтересованности и отзывчивости

Cделал на днях альтернативный вариант сборки gui/ngui. Впервые имею дело с mingw, нужно, чтобы кто-нибудь посмотрел опытным глазом. Всё работает, но может где чушь спорол.
make_mingw.cmd
mingw.mak

Сборка делается в папке mingw_bin. Там же будут gui.dll и ngui.dll.

Поправьте, плиз, кто-нибудь мой баг, а то у меня сейчас проблемы с доступом к учётной записи. В gui_ect.cpp в строке 1007 ф-цию GetWindowLongPtrW надо поменять на GetWindowLongPtrA.

И, наверное, стоит сразу же убрать экспорт классов, как думаете? Никакой функции он не несёт, а веских причин экспортировать не абстрактный интерфейс обычно не бывает. В нашем случае это также ни к чему хорошему не приведёт, т.к. компиляторы используем кто какие. И dll-ки от этого немного "похудеют". Для этого в файле yawl/twl.h строку 58 заменить на пустое определение
#define EXPORT

ngui не делает subclassing. Вроде бы это хорошо - SciTE практически невозможно уронить. Зато и gui.panel будет недоступен - только обычное отдельное окно (gui.window). Пока гуглевский кэш жив, можно посмотреть посты С. Донована по поводу ngui.

Продолжаю бодаться с версией SciTE под Linux... Пока с переменным успехом. Не получается отобразить контекстное меню. Вот такое изменение необходимо в объявление метода Add класса MenuEx в файле SciteBase.h, чтобы скайт хотя бы не падал при правом клике мыши.


Код: void Add(const char * label = 0, int cmd = 0, int enabled = 1, const char *mnemonic = 0, int position = -1);