1C
TI_Eugene
По рекомендации Григория пишу в
рассылку (а не в привате, как собирался)
:-)
Миссия (как сейчас модно):
* продвинуть OpenSource в массы - на горбу
старожилов этого рынка. Т.е. по
простому - пользуясь рынком,
наработками и системой сопровождения
(!) одной всеми уважаемой фирмы - дать
возможность пользоваться Ананасом
простым живым пользователям.
Это даст возможность не очень
известную разработку сделать
стандартом де-факто (как и произошло с
... см. выше).
Цель:
* рассмотреть вопрос целесообразности
обеспечения миграции пользователей 1С
на Ананас.
Ключевые недостатки:
* учетного софта OpenSource вообще и под
Линуксом в частности - полно. Но:
а) нет ни одного с такой пизвестностью
на просторах СНГ, как 1С. Не секрет, что
очень часто звучит: "Windows - из-за 1С".
б) инсталяционная база которой - от 700К
(грубо).
в) но нет ни одного из этих софтин,
которые могут хоть частично
обеспечить переход с 1С.
г) и тем не менее каждая команда копает
свой незалежный огородик.
Ключевые преимущества:
* предлагается же сделать уникальный
продукт
* пользуясь наработками как проекта
Ананас, так и проекта 1Л (которые пока
не пересекаются).
План:
* проанализировать различия между 1С и
Ананасом - технология, язык, объекты,
удобство и т.д.
* вычислить объем работы по
обеспечению прямой
совместимости/конвертиртации
конфигураций и баз 1С.
* изготовить конвертер
* конвертировать Типовые и
регламентированные отчеты 1С в Ананас
* обеспечивать синхронность Типовых
для Ананаса и 1С (но это уже в область
коммерции я залез :-)
Проанализировать могу я. Но нужна
будет помощь разработчиков Ананаса.
Просьба высказаться
PS. Надеюсь, не сильно много букофф?
Fedor A. Ezeev
Непонаслышке знаком с проектом 2С.
>План:
>* проанализировать различия между 1С и
>Ананасом - технология, язык, объекты,
>удобство и т.д.
>* вычислить объем работы по
>обеспечению прямой
>совместимости/конвертиртации
>конфигураций и баз 1С.
>* изготовить конвертер
Вот эти пункты для 2C были выполнены процентов на 50 за ОЧЕНЬ
продолжительное время. Потом эта работа была заброшена.
Наработки по формату хранения данных и метаданных в 1С у меня имеются. Если
что - обращайтесь.
>* конвертировать Типовые и
>регламентированные отчеты 1С в Ананас
>* обеспечивать синхронность Типовых
>для Ананаса и 1С (но это уже в область
>коммерции я залез :-)
Собственно, если будет 100%-ый конвертер, то эти пункты будут выполнятся
автоматически.
Вопрос только с правами на типовые и отчетность. Вы уверены, что фирма 1С
Вам передавала право конвертировать их типовые и потом распространять их в
сконвертированном виде?
С уважением,
Fedor A. Ezeev
______________________________________________________
IT Officer, Alterplast Ltd, +7 (095) 788-09-39 ( 30 lines), ext. 125
mailto:f...@alterplast.ru, http://www.alterplast.ru
TI_Eugene
> Непонаслышке знаком с проектом 2С.
Я тоже.
Более того - одна из реализаций 1Л (qt1L)
основана на коде 2С.
К сожалению, 2С - Windows only, и разработчики
не рассматривают его как
кросс-платформенный.
> Вот эти пункты для 2C были выполнены процентов на 50 за ОЧЕНЬ
> продолжительное время. Потом эта работа была заброшена.
Кхм...
Возможно, у меня мало информации.
Но по состоянию на год назад 2С не была
совместима по метаданным вообще.
> Наработки по формату хранения данных и метаданных в 1С у меня имеются. Если
> что - обращайтесь.
Федор, Ваше имя и так навечно вписано в
скрижали документации 1Л :-)
Я думаю, когда-нибудь дойдут руки до
привести её в порядок - мы еще
поработаем (в любом случае).
> Собственно, если будет 100%-ый конвертер, то эти пункты будут выполнятся
> автоматически.
К сожалению - нет :-(
100% совместимость можно получить,
только если сделать 100% интерепретатор
1С:Васика.
Вместе с его глюками.
А это - нереально.
Здесь же речь идет о трансляции
1С:Васика в QSA.
Поэтому конвертация будет
полуавтоматическая.
Впрочем - не будем задерживаться на
мелочах.
> Вопрос только с правами на типовые и отчетность. Вы уверены, что фирма 1С
> Вам передавала право конвертировать их типовые и потом распространять их в
> сконвертированном виде?
Т.к. этот вопрос постоянно у всех
выскакивает - редактирую:
"...конвертировать и поддерживать в
актуальном виде _какую_нибудь_
конфигурацию 1С (_например_ - Типовую
самой 1С)".
Просто как пример, ничего личного.
Можно поставить "свою конфигурацию",
"типовую третьих фирм (при их согласии)
и т.д.
Что касается самой 1С - никто не доказал
пока обратного.
Если кто-нибудь мне покажет _живую_
лицензию 1С - буду благодарен.
Предлагаю пока не заостряться на
юридических моментах.
Это не суть важно пока.
Fedor A. Ezeev
>> Вот эти пункты для 2C были выполнены процентов на 50 за ОЧЕНЬ
>> продолжительное время. Потом эта работа была заброшена.
>Кхм...
>Возможно, у меня мало информации.
>Но по состоянию на год назад 2С не была совместима по метаданным вообще.
Был написан набросок конвертора 1С -> 2С. Последние изменения в нем
датированы октябрем 2004 года :)
В репозитории 2С он лежит в каталоге Конвертеры\КонвертерМетаданных1С77
>> Наработки по формату хранения данных и метаданных в 1С у меня имеются.
Если
>> что - обращайтесь.
>мы еще поработаем (в любом случае).
Договорились :)
>> Собственно, если будет 100%-ый конвертер, то эти пункты будут выполнятся
>> автоматически.
>К сожалению - нет :-(
>100% совместимость можно получить,
>только если сделать 100% интерепретатор 1С:Васика.
...
>Здесь же речь идет о трансляции 1С:Васика в QSA.
Ну да вообще-то... 2С:Васик был изначально написан так, чтобы быть
синтаксически максимально близким к 1С:Васику.
apa...@gmail.com
проектам!
Не могу не порадоваться формирующейся
среде сторонников свободного учетного
ПО. Вместе стем, в связи с
непрекращающимися попытками склонить
разработчиков проекта Ананас,
единственного на данный момент
успешно развивающегося проекта
свободного учетного ПО, на путь, на
котором сложил голову не один
свободный проект, хочу разьяснить свое
видение правильного маршрута развития
проекта на пути к широкому признанию.
Проект Ананас ни когда не ставил и не
ставит своей целью такие цели как:
1) Победить 1С
2) Отнять у 1С ее партнеров, играя в
дискаунт
3) Быть максимально совместимым с 1С
Я изхожу из того, что рынок учетных
систем, каким бы большим он уже на
сегодня не был, сохраняет огромный
потенциал роста. Рекомендую изучить
мнение например, руководства того же 1С
по этому вопросу. Такой
продолжительный рост рынка возможен
только за счет пополнения
пользовательской базы теми, кто раньше
не использовал ПО для ведения учета, и
скорее всего не использовал даже ПК.
Мы делаем Ананас в расчете именно на
эту аудиторию, а не на нех
пользователей, которые уже успели
подружиться с 1С или любой другой
учетной системой.
Поэтому давайте не будем агитировать
разработчиков Ананаса биться за уже
соблазненных пользователей, в то время
когда еще не пересох поток ньюкамерс.
Я, разумеется понимаю, что есть
пользователи/внедренцы желающие без
переучивания поменять 1С на что-нибудь
свободное, еще больше поднимающее
маржу. Но это не целевая аудитория
проекта Ананас.
Те внедренцы 1С, которые готовы будут
потратить время на переучивание,
найдут в Ананасе интересную как в
техническом, так и (будем надеется
через некоторое время) в бизнес плане
альтернативу. Таких внедренцев мы
намерены поддерживать с помощью
программы миграции, как только
появиться такая возможность.
Silin D
> по этому вопросу. Такой
> продолжительный рост рынка возможен
> только за счет пополнения
> пользовательской базы теми, кто раньше
> не использовал ПО для ведения учета, и
> скорее всего не использовал даже ПК.
>
платят 1С, но платят "чёрным " внедренцам. Так вот достаточно большая
доля этого рынка - тоже потенциальные пользователи Ананаса и ему
подобных проектов.
> Поэтому давайте не будем агитировать
> разработчиков Ананаса биться за уже
> соблазненных пользователей, в то время
> когда еще не пересох поток ньюкамерс.
>
Согласен полностью :-) Это дело внедренцев, а никак не разработчиков.
> Я, разумеется понимаю, что есть
> пользователи/внедренцы желающие без
> переучивания поменять 1С на что-нибудь
> свободное, еще больше поднимающее
> маржу. Но это не целевая аудитория
> проекта Ананас.
>
БЕЗ переучивания не получится :-)
> Те внедренцы 1С, которые готовы будут
> потратить время на переучивание,
> найдут в Ананасе интересную как в
> техническом, так и (будем надеется
> через некоторое время) в бизнес плане
> альтернативу. Таких внедренцев мы
> намерены поддерживать с помощью
> программы миграции, как только
> появиться такая возможность.
>
Есть такие внедренцы, но нет никакой документации по QSA, так что помощь
будет нужна.
Andrey
>
> > по этому вопросу. Такой
> > продолжительный рост рынка возможен
> > только за счет пополнения
> > пользовательской базы теми, кто раньше
> > не использовал ПО для ведения учета, и
> > скорее всего не использовал даже ПК.
> >
> Не согласен. Достаточно велик рынок "чёрных 1С", пользователи которых не
> платят 1С, но платят "чёрным " внедренцам. Так вот достаточно большая
> доля этого рынка - тоже потенциальные пользователи Ананаса и ему
> подобных проектов.
Согласен. Мое утверждение не бесспорно. Углубляясь в детали можно обнаружить потенциал и в других источниках
пополнения пользовательской базы. Я назвал наиболее значимый на сегодня для нас источник.
[skip]
> Есть такие внедренцы, но нет никакой документации по QSA, так что помощь
> будет нужна.
Trolltech поставляет с QSA великолепную документацию.
API Ананаса мы документируем и постоянно улучшаем документацию.
http://ananas.lrn.ru/doxygen/html-ru/index.html
http://ananas.lrn.ru/index.php?title=Manual:Ananas_Script
--
Андрей
Fedor A. Ezeev
>> > по этому вопросу. Такой
>> > продолжительный рост рынка возможен
>> > только за счет пополнения
>> > пользовательской базы теми, кто раньше
>> > не использовал ПО для ведения учета, и
>> > скорее всего не использовал даже ПК.
>> Не согласен. Достаточно велик рынок "чёрных 1С", пользователи которых не
>> платят 1С, но платят "чёрным " внедренцам. Так вот достаточно большая
>> доля этого рынка - тоже потенциальные пользователи Ананаса и ему
>> подобных проектов.
>Согласен. Мое утверждение не бесспорно. Углубляясь в детали можно
обнаружить потенциал и в других источниках
>пополнения пользовательской базы. Я назвал наиболее значимый на сегодня
для нас источник.
Да ну глупости это все по поводу потенциала перехода с других учетных
систем.
И от цвета внедренца тут вообще ничего не зависит.
Смена учетной системы - это очень, ОЧЕНЬ рискованный шаг в жизни компании.
Чаще всего на него идут в ситуации, когда старая система ПОЛНОСТЬЮ
перестает устраивать.
И тогда просто берут ГОТОВОЕ решение и начинают жизнь заново.
А это те же newcomers, только вид сбоку.
P.S. Про мнение той же фирмы 1С - очень тонко подмечено. Если бы товарищи
из 1С не видели бы мощного потенциала первичного рынка учетных систем - они
бы сделали более полный конвертер из 7.7 в 8.0.
Silin D
> Да ну глупости это все по поводу потенциала перехода с других учетных
> систем.
> И от цвета внедренца тут вообще ничего не зависит.
> Смена учетной системы - это очень, ОЧЕНЬ рискованный шаг в жизни компании.
> Чаще всего на него идут в ситуации, когда старая система ПОЛНОСТЬЮ
> перестает устраивать.
> И тогда просто берут ГОТОВОЕ решение и начинают жизнь заново.
>
если ты нормальный внедренец, то фирма всегда будет работать на том
продукте, который ты укажешь. А уж если переходить на халявную систему,
то и подавно :-)
TI_Eugene
Ну, не стоит так уж однозначно...
Прямо - "глупости"!
:-)
> Смена учетной системы - это очень, ОЧЕНЬ рискованный шаг в жизни компании.
> Чаще всего на него идут в ситуации, когда старая система ПОЛНОСТЬЮ
> перестает устраивать.
> И тогда просто берут ГОТОВОЕ решение и начинают жизнь заново.
Рассматривается "сферический клиент в
вакууме"?
Вы, Федор, видимо не в курсе, что до сих
пор некоторые пользуют 1С 6.0.
Это которые не сторонники "до
основания - а затем".
У меня опыт небольшой (лет 10), но я
крайне мало видел клиентов, которые
меняют платформу. А те, кто меняют -
матерятся при этом так, что я и слов
таких не знаю.
Но - им деваться некуда.
Потому что... (см ниже).
> P.S. Про мнение той же фирмы 1С - очень тонко подмечено. Если бы товарищи
> из 1С не видели бы мощного потенциала первичного рынка учетных систем - они
> бы сделали более полный конвертер из 7.7 в 8.0.
Если бы товарищи из 1С сделали
конвертер из 7.7 в 8.0 (который, кстати,
существует - но только для Типовых
самой 1С), то а) они бы уже собирали
бутылки, и б) франчайзи сильно на них
обиделись бы - лишить возможности
взять 2 раза денег с одного и того же
клиента - это нехорошо. Так в среде 1С не
принято.
Я не думаю, что здесь место и время
обсуждать маркетинг 1С, просто поимеем
в виду - они делают всё, что бы получить
максимальную прибыль. Для 1С, ессно.
Здесь модель бизнеса 1С отличается от
модели OpenSource (как верно Андрей
подметил).
Fedor A. Ezeev
>> Да ну глупости это все по поводу потенциала перехода с других учетных
систем.
>Ну, не стоит так уж однозначно...
>Прямо - "глупости"!
>:-)
>> Смена учетной системы - это очень, ОЧЕНЬ рискованный шаг в жизни
компании.
>У меня опыт небольшой (лет 10), но я
>крайне мало видел клиентов, которые
>меняют платформу. А те, кто меняют -
>матерятся при этом так, что я и слов
>таких не знаю.
Я так и не понял. Или у перехода с других систем есть потенциал, или
"клиентов, которые меняют платформу - крайне мало".
Определитесь пожалуйста.
Fedor A. Ezeev
Мне вот кажется, что если ты нормальный внедренец, то в первую очередь не
будешь ломать уже имеющуюся систему, не имея на это веских причин. Хотя
против 25-ти летнего опыта мне противопоставить нечего. Мой существенно
короче :)
TI_Eugene
Fedor A. Ezeev wrote:
> Я так и не понял. Или у перехода с других систем есть потенциал, или
> "клиентов, которые меняют платформу - крайне мало".
> Определитесь пожалуйста.
Даю определение:
Переход:: всё бросить - и начать заново
на другой платформе.
Миграция:: перенести данные из старой
системы в новую и _продолжить_ работу в
новой.
Федор утверждает, что нормальные
пацаны вытягивают всё из старой
системы, и, дойдя до ручки - до
основания, а затем.
А кто не до основания, а пытается
переползти со своими данными - тот не
пацан :-)
Я же речь вел о том, чтобы обеспечить
_миграцию_ с 1С.
Не убирая, ессно, возможностей для
newcomerce.
Всё это - под тем соусом, что
потенциально мигрирующих - на много
порядков больше, чем newcomerce и любителей
"до основания" (AKA нормальных пацанов :-)
PS. Прошу воспринимать с номинальной
долей юмора и отделять лексику от
семантики. Ничего личного! :-)
TI_Eugene
Fedor A. Ezeev wrote:
> Я так и не понял. Или у перехода с других систем есть потенциал, или
> "клиентов, которые меняют платформу - крайне мало".
> Определитесь пожалуйста.
Забыл уточнить - их мало, потому что
миграция на текущих продуктах
(особенно отечественных учетных) или
невозможна, или предельно затруднена.
Причем - не сказать, что из-за
технической невозможности девелов
соотв-щих продуктов.
TI_Eugene
> Мне вот кажется, что если ты нормальный внедренец, то в первую очередь не
> будешь ломать уже имеющуюся систему, не имея на это веских причин.
1. Предлагаю фильтровать экзистенции
"нормальный/ненормальный"
2. Чаще всего внедренец _заставляет_
ломать потому, что _ему_ будет удобнее
на новой системе обеспечить требуемую
клиентом же функциональность. Как
правило, ломать или нет, решает сам
клиент. Хотя и обработанный, согласен
:-) Но источник ломки всё же достаточно
честен - выполнить максимум при
мимнимуме затрат. В конце концов сам же
внедренец и будет выгребать
результаты ломки.
Fedor A. Ezeev
Воду в ступе толчем, IMHO. Люди все тут опытные, все всё прекрасно
понимают.
Если создать инструмент, позволяющий пользователям безболезненно
мигрировать со всеми данными и настройками из одного продукта в другой - у
этого "другого" продукта сразу же появится масса потенциальных клиентов.
Это очевидно.
Настолько же очевидно, что без подобного инструмента можно претендовать
практически только на рынок newcomers, который, к счастью, не так уж и мал.
Это тоже очевидно.
У ананаса на данный момент НЕТ подобного инструмента миграции с 1С. И в
обозримом будущем - не появится. И это тоже очевидно.
Об чем спор?
TI_Eugene
> Воду в ступе толчем, IMHO. Люди все тут опытные, все всё прекрасно понимают.
Зато не осталось белых пятен.
> Если создать инструмент, позволяющий пользователям безболезненно
> мигрировать со всеми данными и настройками из одного продукта в другой - у
> этого "другого" продукта сразу же появится масса потенциальных клиентов.
> Это очевидно.
Я предложил создать инструмент.
Однако он требует переделки Ананаса.
Точнее - приближение синтаксиса и
состава классов/объектов
Ананас-скрипта к системе - источнику
миграции (не будеим тыкать пальцами).
> Настолько же очевидно, что без подобного инструмента можно претендовать
> практически только на рынок newcomers, который, к счастью, не так уж и мал.
> Это тоже очевидно.
Тем не менее, как я понял, разработчики
Ананаса - против :-(
> У ананаса на данный момент НЕТ подобного инструмента миграции с 1С. И в
> обозримом будущем - не появится. И это тоже очевидно.
А вот это уже неправда.
Он _может_ появиться.
Но без участия и желания девелов - или
нет, или очень не скокро (и это уже
будет не Ананас).
> Об чем спор?
Вот об этом же - добиться не "не против"
девелов Ананаса (хотя, оказывается,
таки против, а именно соучастия).
А конвертер - это уже дело техники.
Половина (скажем грубо) уже готова.
Grigory Panov
Fedor A. Ezeev wrote:
> Воду в ступе толчем, IMHO. Люди все тут опытные, все всё прекрасно
> понимают.
>
> Если создать инструмент, позволяющий пользователям безболезненно
> мигрировать со всеми данными и настройками из одного продукта в другой - у
> этого "другого" продукта сразу же появится масса потенциальных клиентов.
> Это очевидно.
>
> Настолько же очевидно, что без подобного инструмента можно претендовать
> практически только на рынок newcomers, который, к счастью, не так уж и мал.
> Это тоже очевидно.
>
> У ананаса на данный момент НЕТ подобного инструмента миграции с 1С. И в
> обозримом будущем - не появится. И это тоже очевидно.
> Об чем спор?
Насколько я понял, спор о том,
целесообразно ли написание такого
инструмента. И на этот вопрос ответа
пока нет. Основная, но не единственная,
загвоздка на данный момент в
синтаксисе QSA. Непонятно, можно ли
динамически определять свойства
объекта или нет. Если нет, то за
написание конвертера никто не
возьмется.
Silin D
Grigory Panov пишет:
> Fedor A. Ezeev wrote:
>
>> Воду в ступе толчем, IMHO. Люди все тут опытные, все всё прекрасно
>> понимают.
>>
>> Если создать инструмент, позволяющий пользователям безболезненно
>> мигрировать со всеми данными и настройками из одного продукта в другой - у
>> этого "другого" продукта сразу же появится масса потенциальных клиентов.
>> Это очевидно.
>>
>> Настолько же очевидно, что без подобного инструмента можно претендовать
>> практически только на рынок newcomers, который, к счастью, не так уж и мал.
>> Это тоже очевидно.
>>
>> У ананаса на данный момент НЕТ подобного инструмента миграции с 1С. И в
>> обозримом будущем - не появится. И это тоже очевидно.
>>
>
>
>> Об чем спор?
>>
> Насколько я понял, спор о том,
> целесообразно ли написание такого
> инструмента. И на этот вопрос ответа
> пока нет. Основная, но не единственная,
> загвоздка на данный момент в
> синтаксисе QSA. Непонятно, можно ли
> динамически определять свойства
> объекта или нет. Если нет, то за
> написание конвертера никто не
> возьмется.
>
>
Господа, да не нужен никакой конвертор :-)
Нужен просто удобный конфигуратор и язык грамотно документированые, а
остальное уже дело техники...
TI_Eugene
> целесообразно ли написание такого
> инструмента.
> И на этот вопрос ответа
> пока нет.
Ну, насчет целесообразности - я так
понял, многие таки за.
Вопрос скорее в _возможности_.
> Основная, но не единственная,
> загвоздка на данный момент в
> синтаксисе QSA. Непонятно, можно ли
> динамически определять свойства
> объекта или нет. Если нет, то за
> написание конвертера никто не
> возьмется.
Сформулировано ИДЕАЛЬНО :-)
Кто возьмет найти и проверить аналоги
питоновских __getattr__ и __setattr__ ?
Потому как я в QSA - как свинья в
апельсинах, честно говоря.
Dmitriy.Kruglikov
> Сформулировано ИДЕАЛЬНО :-)
>
> Кто возьмет найти и проверить аналоги
> питоновских __getattr__ и __setattr__ ?
В Qt есть специальный встраиваемый язык
для написания
скриптов ...
Лучше ориентироваться на него ...
Он не сложный .... Совсем не сложный ....
Не нужно пихать невпихуемое ...
>
> Потому как я в QSA - как свинья в
> апельсинах, честно говоря.
Это не так сложно .... Даже я, со своей
тупостью смог осилить ...
Dmitriy.Kruglikov
apa...@gmail.com wrote:
> Те внедренцы 1С, которые готовы будут
> потратить время на переучивание,
> найдут в Ананасе интересную как в
> техническом, так и (будем надеется
> через некоторое время) в бизнес плане
> альтернативу. Таких внедренцев мы
> намерены поддерживать с помощью
> программы миграции, как только
> появиться такая возможность.
Андрей, мне кажется, ты необоснованно
ограничил круг потенциальных
внедренцев.
Кроме того, ты не учитываешь
психологический фактор, который в
значительной мере может повредить
распространению Ананаса ...
А именно, отсутсвие уверенности
ИТ-менеджера вирмы, в которую прийдут
внедренцы, или свой сотрудник
предложит переход.
Любой здравомыслящий менеджер
подумает о том, как ему быть с
продуктом, если фирма-внедренец, или
собственный сотрудник откажутся, по
тем или иным причинам, от дальнейшего
сопровождения.
В случае, если будет реализован
синтаксис конфигурации, максимально
приближенный к 1С, например, то любой
подготовленный разработчик
конфигураций 1С сможет продолжить
работу ....
В случае же оригинального языка, такой
вариант неприемлем...
Исходя из этих соображений выбор
менеджера весьма предсказуем.
И, боюсь, не в пользу Ананаса...
Я сейчас нахожусь именно в такой
ситуации, и в беседе с моим
работодателем однозначно услышал
именно эту тему ...
Grigory Panov
пока все, что удалось найти. И самое
дурацкое то, что ответа там нет :)
TI_Eugene
> > питоновских __getattr__ и __setattr__ ?
> Женя, не нужно так кардинально ....
> В Qt есть специальный встраиваемый язык
> для написания
> скриптов ...
Дима, читай внимательно - _аналог_
питоновских...
Т.е. аналоги в QSA, в смысле.
Питоновские - указаны.
/usr/share/doc/python-docs-2.4.3/html/ref/attribute-access.html
> Это не так сложно .... Даже я, со своей
> тупостью смог осилить ...
Здесь не сам язык надо знать, а attribute
access control features (прошу прощения).
TI_Eugene
Во-во-во!
Это ж оно и есть!
Только не на ActiveX, а так просто.
Тут только-что вспомнилось - то, что
хочется, делает pyton-xmlrpc:
-----
def getcontacts(self):
while True:
contacts=self.sp.addressbook.boaddressbook.search({'start': offset,
'limit': limit})
----
Это был кусок софтины для снятия
адресной книги с eGroupWare.
Ессно, addressbook.boaddressbook.search - это не члены
данного объекта (self.sp), а нечто, на что
реагирует xmlrpc-server. Но разбирается это
дело в XML-запрос - клиентом.
Если что - ошибка, что нет такого
объекта/метода search у объекта...
Может - так?:
TI_Eugene
Даже так - обратимся к классике:
http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Guide:Creating_New_Objects:Defining_Getters_and_Setters
Вот именно это и нужно.
Самое интересное - это ж тоже ECMA
Andrey
> Исходя из этих соображений выбор
> менеджера весьма предсказуем.
> И, боюсь, не в пользу Ананаса...
>
> Я сейчас нахожусь именно в такой
> ситуации, и в беседе с моим
> работодателем однозначно услышал
> именно эту тему ...
Разумеется не в пользу Ананаса.
Ты находишся в такой тяжелой ситуации только по тому, что взял на себя роль
erly adapters.
Всем, кто будет работать с Ананасом до его действительного массового
распространения будет не легко в бизнес плане и это необходимо понимать.
Сейчас, до массового распространения Ананаса и появления команд независимых
внедренцев, основное, чем мы можем привлеч заказчика, на мой взгляд -
получение услуг напрямую от производителя.
В любом случае, получение заказа на внедрение Ананаса в настоящий момент можно
прировнять к подвигу :)
--
Андрей
Dmitriy.Kruglikov
Andrey писал(а):
> Всем, кто будет работать с Ананасом до его действительного массового
> распространения будет не легко в бизнес плане и это необходимо понимать.
Текущее обсуждение (суммарное мнение
высказавшихся) показывает, что до
массового распространения Ананаса
дело может не дойти вообще, как это не
прискорбно осознавать... Имея нечто
более привычное, ни кто не захочет
переходить на новый, пускай даже
хороший, но непривычный продукт.
Безспорно, Ананас абсолютно
обоснованно займет определенную нишу,
но, весьма скромную, на мой взгляд.
Но вот в случае реализации варианта
1С-совместимости по синтаксису
конфигурации, эта ниша станет
значительно шире, так как количество
потенциальных внедренцев будет
несоизмеримо больше...
Сегодня можно рассчитывать только на
энтузиастов, которые с 1С (или другими
системами) не знакомы или знакомы мало,
и которых привлекает удобство и
легкость разработки. Или просто нет
другого выхода...
В качестве статистики возьмем
количество разаработчиков, которые
пытаются сделать что-либо и общаются
на форуме Ананас...
Кроме конфигурации оперативного учета
от разработчиков Ананас, я могу
назвать еще три ... Умножим на два,
закрыв глаза.... Но все равно, до
обидного мало ...
Неужели ради такого узкого круга
фанатов вы работаете несколько лет?
И я уверен, что ваш just for fun неимоверно
возрастет, если разработчиков будет в
десятки раз больше :)
А те, кто умеет писать на 1С, потянутся к
Ананасу...
В качестве экспертного мнения по этому
тезису предлагаю спросить Дмитрия
Силина... :)
Более того, предложение пересмотреть
некоторые аспекты разработки является
не просто голословным предложением
париться самостоятельно...
В случае утверждения этой концепции, к
команде разработчиков Ананаса готовы
примкнуть не менее трех человек ...
Которым нужен продукт именно
совместимый с синтаксисом 1С ...
Разве Ананасу не нужны разработчики?
Dmitriy P.
Последние новости:
http://ananas.lrn.ru/phpBB2/viewtopic.php?t=371
--
С уважением,
Дмитрий Павлюк
Silin D
с 1С специалистам :-)
Хотя специалистов нам подобных и немного...
У меня есть знакомый парень, который пишет конфы только с нуля. Ему
по-барабану на какой системе это будет написано, лишь бы она была похожа
(изнутри) на 1С. А учить что-то новое он отказывается наотрез...
> В качестве статистики возьмем
> количество разаработчиков, которые
> пытаются сделать что-либо и общаются
> на форуме Ананас...
>
> Кроме конфигурации оперативного учета
> от разработчиков Ананас, я могу
> назвать еще три ... Умножим на два,
> закрыв глаза.... Но все равно, до
> обидного мало ...
>
> Неужели ради такого узкого круга
> фанатов вы работаете несколько лет?
>
> И я уверен, что ваш just for fun неимоверно
> возрастет, если разработчиков будет в
> десятки раз больше :)
>
> А те, кто умеет писать на 1С, потянутся к
> Ананасу...
> В качестве экспертного мнения по этому
> тезису предлагаю спросить Дмитрия
> Силина... :)
>
> Более того, предложение пересмотреть
> некоторые аспекты разработки является
> не просто голословным предложением
> париться самостоятельно...
> В случае утверждения этой концепции, к
> команде разработчиков Ананаса готовы
> примкнуть не менее трех человек ...
> Которым нужен продукт именно
> совместимый с синтаксисом 1С ...
> Разве Ананасу не нужны разработчики?
>
деньги от них?
Dmitriy.Kruglikov
Silin D wrote:
> > Сегодня можно рассчитывать только на
> > энтузиастов, которые с 1С (или другими
> > системами) не знакомы или знакомы мало,
> > и которых привлекает удобство и
> > легкость разработки. Или просто нет
> > другого выхода...
> >
> Тут ты нет прав. Трудно отнести тебя или меня, например, к малознакомым
> с 1С специалистам :-)
> Хотя специалистов нам подобных и немного...
> У меня есть знакомый парень, который пишет конфы только с нуля. Ему
> по-барабану на какой системе это будет написано, лишь бы она была похожа
> (изнутри) на 1С. А учить что-то новое он отказывается наотрез...
Я не являюсь специалистом в 1С ....
Я ни строки кода на 1С-васике не написал
...
Ананас начал изучать с конфигурации
"Оперативный учет" и писать свою с
чистого листа ...
И мне, лично, сравнивать сложно...
Но я выбрал Ананас по двум причинам...
Значительная часть делается средсвами
дизайнера, без моего участия...
Ни чего более подходящего по сумме
факторов я не нашел ...
Мне лично было вполне удобно и
доступно для понимания ....
Думаю, что если бы у меня был опыт
разработки на 1С, мне было бы тяжелее
многократно, так как я постоянно
срывался бы на привычные механизмы ...
TI_Eugene
А нече так движок получился, а? :-)
Сразу видно - проект живой!
Можно даже сказать, что как будто это
форум 1Л, а не Ананаса :-))
Для стабилизации динамики (во как) могу
высказать предположение, что Андрей
ревнует к 1Л (или как там правильно
говорится), откуда проистекает...
проистекает, короче.
Это - личноt, глубоко ошибочное IMHO ;-)))
Только для поддержания тонуса, так
сказать.
А может и не только...
TI_Eugene
> высказать предположение, что Андрей
> ревнует к 1Л (или как там правильно
> говорится), откуда проистекает...
> проистекает, короче.
В ответ на многочисленные возмущения
общественности отвечаю:
Вы что - шуток вообще не понимаете, что
ли?
Ну как дети малые, чессло.
Grigory Panov
а вот так - работает:
var doc = new Document("Doc");
// следующие две строки надо автоматом дописывать при создании
// объекта скрипта для каждого свойства. Как это скажется на
//производительности, сказать не берусь.
doc.getField1 = function() { return this.value("Field1"); }
doc.setField1 = function(val) { this.setValue("Field1", val); }
doc.Field1 = "10";
sys.Message(0,doc.Field1);
выводит на экран 10.
--
Grigory Panov
Grigory Panov
использование русских названий для
полей либо нужно будет писать все на
русском, и прикручивать препроцессор
для замены всего русского на
нерусское.
Andrey
В сообщении от 9 августа 2006 10:10 Dmitriy.Kruglikov написал(a):
> В случае утверждения этой концепции, к
> команде разработчиков Ананаса готовы
> примкнуть не менее трех человек ...
> Которым нужен продукт именно
> совместимый с синтаксисом 1С ...
> Разве Ананасу не нужны разработчики?
На мой взгляд, дисскусия от обсуждения целей ( А как я понимаю, мы
дискутировали о приоритетности работ по совместимости в той или иной форме с
1С) перешла в плоскость обсуждения процедур.
То есть, подведя остаток, можно констатировать, что принципиально ни кто не
против, что бы проект Ананас рано или поздно помогал пользователям и
внедренцам переходить с 1с.
Теперь о процедурах.
Так как похоже появились реальные желающие вносить вклад в виде кода в проект,
то я бы предложил не заниматься дальше высказыванием аргументов о пользе
совместимости С 1c, а присылать патчи повышающие такую совместимость, для
тестирования и вливания в проект.
Патчи прошу сопровождать пояснениями и аргументами об их полезности. Такие
пояснения и аргументы как раз и стоит публично обсуждать, на мой взгляд.
--
Андрей
Andrey
Если вам проще и удобнее зарабатывать на клиентах 1С, это не значит что нет
других бизнес моделей и/или они не доступны другим.
В сообщении от 9 августа 2006 12:04 Silin D написал(a):
> Я бы поставил вопрос немного иначе - Разве Ананасу не нужны внедрения и
> деньги от них?
--
Андрей
TI_Eugene
- есть еще вариант генерации классов по
метаданным - на лету на старте.
Несколько некрасиво, но снаружи видно
не будет.
Хотя хотелось бы обойтись, ессно.
TI_Eugene
Вот мы и подошли к одному из вопросов,
требующих не "не против"
отцов-основателей Ананаса, а их
прямого участия.
Для разрешения указанной проблемы
предлагается завести поле, скажем,
AsciiName в метаданных.
Я давненько уже не запускал <censored> 8.x, но
мне смутно помнится, что там подобный
механизм есть.
Итак, это поле:
* подобно синониму имени
* содержимое - ascii only
* по нему, и только по нему можно
вызывать атрибут "ч-з точку"
* если Имя - ascii, то AsciiName с ним совпадает
* Если Имя - не-ascii - то AsciiName генерится
(по словарю и/или транслитом) из Имени с
ручной доводкой после
* если Имя меняется - то AsciiName
регенерится тоже.
RFC
(прошу комментировать - прим. перев.)
Grigory Panov
> > но это автоматом запрещает
> > использование русских названий для
> > полей либо нужно будет писать все на
> > русском, и прикручивать препроцессор
> > для замены всего русского на
> > нерусское.
>
> Вот мы и подошли к одному из вопросов,
> требующих не "не против"
> отцов-основателей Ананаса, а их
> прямого участия.
> Для разрешения указанной проблемы
> предлагается завести поле, скажем,
> AsciiName в метаданных.
> Я давненько уже не запускал <censored> 8.x, но
> мне смутно помнится, что там подобный
> механизм есть.
> Итак, это поле:
> * подобно синониму имени
> * содержимое - ascii only
> * по нему, и только по нему можно
> вызывать атрибут "ч-з точку"
начиная
> * если Имя - ascii, то AsciiName с ним совпадает
> * Если Имя - не-ascii - то AsciiName генерится
> (по словарю и/или транслитом) из Имени с
> ручной доводкой после
> * если Имя меняется - то AsciiName
> регенерится тоже.
заканчивая этим.
это, по-моему, лишнее.
( красивая фигурная резьба и шелковые бантики на костыле )
Как насчет того, чтобы генерить этот синоним из префикс + id объекта
метаданных? Синоним задается системой при создании объекта, уникален, и
накосячить с ним пользователь не сможет, если не полезет руками править
cfg файл.
> RFC
> (прошу комментировать - прим. перев.)
>
>
>
--
Grigory Panov
TI_Eugene
будет много букофф.
== Вступление
Напомню, что вся эта буча была поднята
для решения 2-х вопросов, касающихся
<censored/>-совместимости:
1. добавления к синтаксису скрипта
(доступ к атрибутам, описанным в
метаданнных, "ч-з точку")
2. изменения в структуре самой
библиотеки.
Первый вопрос мы вроде бы закрыли -
доказано, что вещь нужная, осталось
найти оптимальный механизм
реализации.
Теперь по второму вопросу.
Дабы сразу определить контекст того,
что пойдет ниже, пишу - речь идет о
стурктуре классов, подобной структуре
типов <censored/> v.8.x.
Кроме того, всё, что пойдет ниже, я буду
писать от лица потенциальных
пользователей системы - внедренцев
учетных систем (надеюсь, они на меня не
обидятся за такую наглость),
собирающихся _начать_ работать с
Ананасом.
== Преамбула
Для разогрева - соглашение об
именовании.
Когда мы работаем с Qt, мы четко знаем -
все типы начинаются с Q. Т.е. чтобы
завести переменную Qtшного типа - мы
пишем букву Q, и потом начинаем думать.
Верно и обратное - если мы встретили в
сырцах Q* - мы знаем, что речь идет о
Qtшном типе.
Кроме того, не помню по какой
рекомендации типы/классы начинаются с
большой буквы, а объекты - с маленькой
(в Qt именно так и есть).
Посмотрим же на то, что мы имеем.
* Все (?) типы Ананаса в C++-коде
начинаются с "a" (маленькая).
* Все типы в Ananas-script начинаются...
Правильно. Могу поспорить, что даже
сами разработчики не все вот так влет
скажут - какой с чего начинается.
Подсказываю - судя по
http://ananas.lrn.ru/index.php?title=Manual:Ananas_Script с буквы
A начинаются 2 (два) объекта. Почему
именно ARegister и ATime, и почему остальные с
буквы A не начинаются - непонятно, и,
самое главное - неудобно.
== Амбула
Берем первый попавшийся. Первым
попавшимся у нас, как всегда, будет
Справочник.
=== 7.x
В <censored/> v.7.x объект этого АТД
(Агрегатного Типа Данных (прим.перев.) -
классом его назвать рука не
поворачивается) создается простым
движением Create("Reference.Organization"). Заметим,
что:
* функция Create _не_создает_справочник_.
Справочник уже существует в
метаданных. Создается объект,
ссылающийся на ...
* А вот на что ссылающийся в данном
месте кода - это зависит от контекста
кода (и это огромный геморрой даже для
опытных 1Сников). То он указывает на
весь справочник, то на запись, то
становится самой записью...
=== 8.x
Теперь берем <censored/> v.8.x. (сейчас пойдет
отсебятина, т.к. доку по 8ке дома
оставил - но тут главное не точные
названия, а идея). Здесь о Справочнике
есть 6 (шесть!) типов/объектов:
* CatalogsManager - это контейнер всех
Справочников; с его помощью можно,
например, получить список всех
Справочников конфигурации (а не ч-з
костыль Метаданные, как в 7ке).
* CatalogManager - доступ к свойствам одного
справочника, как целого
* CatalogReference - _ссылка_ на одну запись в
Справочнике.
* CatalogItem - собственно запись
Справочника.
* еще какой-то (забыл)
* и еще один (тоже забыл)
Вот это действительно удобный состав
типов - каждый из несет четкую
смысловую нагрузку и имеет
непересекающуюся с соседями пачку
атрибутов/методов.
=== Ananas
Здесь мы имеем 2 (?) класса, из которых в
скрипте, судя по всему, доступен 1
(aCatalogue), который, судя по
http://ananas.lrn.ru/doxygen/html-ru/classaCatalogue.html,
довольно хорошо повторяет состав
атрибутов/методов Справочника v.7.7.
Со всеми вышеуказанными.
== Выводы
Я думаю, выводы напрашиваются сами по
себе :-)
Теперь я отбегу подальше - и начнем
обсуждение.
Dmitriy P.
Был успешно выполнен первый этап портирования программы Ананас на Qt4.
Т.е. сборка программы на Qt4.
На данный момент идет второй этап - перенос наиболее важных частей
программы на чистый Qt4.
К сожалению, до сих пор не понятна позиция руководителя проекта Андрея,
на происходящее.
Останеться ли результат работы лишь частной инициативой, или код будет
принят в проект.
TI_Eugene
> метаданных? Синоним задается системой при создании объекта, уникален, и
> накосячить с ним пользователь не сможет, если не полезет руками править
> cfg файл.
ID - числовой?
Ну, и как я буду писать - spr._314159 ?
А вот, скажем, есть поле Цена, а ascii
записано - Price (это мне так нравится).
А кто учил албанский - напишет Zena (это
ему так нравится).
А если оба промолчат, то сгенерится Tsena
(это системе так нравится).
vvz
1. объекты типа "Справочник", "Документ"
имеют ассоциативный массив свойств
2. При
спр=СоздатьОбъект("Справочник.Запасы");
а) создается встроенный объект системы
"Справочник"
б) из его массива свойств создаются
свойства объекта сл. образом:
result_type = QSInterpreter::evaluate ("
class Goods{
.......definition of metaproperties.........
}
" ,core_doc )
в) создается экземпляр объекта скрипта
г) инициализируется
д) возвращается в виде результата.
Grigory Panov
> > Как насчет того, чтобы генерить этот синоним из префикс + id объекта
> > метаданных? Синоним задается системой при создании объекта, уникален, и
> > накосячить с ним пользователь не сможет, если не полезет руками править
> > cfg файл.
>
> ID - числовой?
> Ну, и как я буду писать - spr._314159 ?
примерно так. зато это можно сделать быстро.
ну и старый вариант тоже останется (value/setValue)
> А вот, скажем, есть поле Цена, а ascii
> записано - Price (это мне так нравится).
> А кто учил албанский - напишет Zena (это
> ему так нравится).
> А если оба промолчат, то сгенерится Tsena
> (это системе так нравится).
Системе все равно, на самом деле, но программиcтам, которые будут писать код
реализации "генерения" значения по умолчанию, гораздо больше понравится
что-то вроде user_field_2342342
>
>
--
Grigory Panov
TI_Eugene
Grigory Panov wrote:
> примерно так. зато это можно сделать быстро.
Да, но в таком виде этим невозможно
будет пользоваться.
=> теряет смысл.
BTW насчет быстро - у нас (1Л имеется в
виду) один из трасляторов 1С в питон
делает подстановку транслитерацией.
И ниче так - читабельно.
Хотя выглядит полученный код
страшновастенько.
> ну и старый вариант тоже останется (value/setValue)
Ессно.
В той же 8ке все атрибуты можно поиметь
и так и так.
И в 7ке тоже, кажись (частично).
И это правильно.
> Системе все равно, на самом деле, но программиcтам, которые будут писать код
> реализации "генерения" значения по умолчанию, гораздо больше понравится
> что-то вроде user_field_2342342
Ага.
А внедренцам, которые этими полями
будут пользоваться?
Товарищи внедренцы - кто согласен
писать
spr.user_field_2342342 = a.user_field_912834 * b.user_field_31415926
???
Grigory Panov
> Заранее прошу прощения, но сейчас
> будет много букофф.
>
> == Вступление
> Напомню, что вся эта буча была поднята
> для решения 2-х вопросов, касающихся
> <censored/>-совместимости:
> 1. добавления к синтаксису скрипта
> (доступ к атрибутам, описанным в
> метаданнных, "ч-з точку")
> 2. изменения в структуре самой
> библиотеки.
> Первый вопрос мы вроде бы закрыли -
> доказано, что вещь нужная, осталось
> найти оптимальный механизм
> реализации.
как этот механизм будет найден, и проверена его работоспособность.
все остальное можно пока не читать, по поводу первых букв в названии -
вообще непонятно, зачем это.
не все.
> * Все типы в Ananas-script начинаются...
> Правильно. Могу поспорить, что даже
> сами разработчики не все вот так влет
> скажут - какой с чего начинается.
> Подсказываю - судя по
> http://ananas.lrn.ru/index.php?title=Manual:Ananas_Script с буквы
> A начинаются 2 (два) объекта. Почему
> именно ARegister и ATime, и почему остальные с
> буквы A не начинаются - непонятно, и,
> самое главное - неудобно.
ARegister, IRegister... не прояснилось?
ATime - вообще выкинуть надо, я его добавил временно,
да так и оставил...
Попробую угадать: надо реализовать функциональность 1С v8?
:)
> Теперь я отбегу подальше - и начнем
> обсуждение.
--
Grigory Panov
Grigory Panov
> > Системе все равно, на самом деле, но программиcтам, которые будут писать
> > код реализации "генерения" значения по умолчанию, гораздо больше
> > понравится что-то вроде user_field_2342342
>
> Ага.
> А внедренцам, которые этими полями
> будут пользоваться?
>
> Товарищи внедренцы - кто согласен
> писать
> spr.user_field_2342342 = a.user_field_912834 * b.user_field_31415926
> ???
так, как нравится....
Просто не понимаю, для чего добавлять совершенно ненужную функциональность по
переводу в транслит.
--
Grigory Panov
Den Kaftaev
> В сообщении от Пятница 11 Август 2006 11:53 TI_Eugene написал(a):
>
>> Заранее прошу прощения, но сейчас
>> будет много букофф.
>>
>>
> :)
>
>
>
>
работал, то есть внедрял, настраивал, ввел учет) другие
учетно-управленческие системы? Что вы носитесь вокруг этой <censored />?
Grigory Panov
я и <censored /> одним глазом видел только :)
--
Grigory Panov
TI_Eugene
> переводу в транслит.
Чтобы можно было пользоваться "из
коробки".
Например - после конвертирования конф
<censored/>.
Сразу
TI_Eugene
> как этот механизм будет найден, и проверена его работоспособность.
Закрыт вопрос - нужно ли этим
заниматься - в смысле поиска и
реализации механизма.
> все остальное можно пока не читать, по поводу первых букв в названии -
> вообще непонятно, зачем это.
Не понял. Названия чего?
> > * Все (?) типы Ананаса в C++-коде
> > начинаются с "a" (маленькая).
> не все.
Я так и написал - "все (?)", а не "все"
Это была моя догадка, т.к. нигде не
видел code style Ананаса.
> ARegister, IRegister... не прояснилось?
Если бы не было ATime - то прояснилось бы.
> ATime - вообще выкинуть надо, я его добавил временно,
> да так и оставил...
> > == Выводы
> > Я думаю, выводы напрашиваются сами по
> > себе :-)
> Попробую угадать: надо реализовать функциональность 1С v8? :)
Хорошая попытка.
Не угадал.
Речь идет о перестройке текущего
дерева классов Ананаса в более
логичное.
_Как_пример_ можно взять 1C v8.
Пример дерева, а не пример названий
классов.
Хотя сами названия основных типов там
тоже удобные.
TI_Eugene
Если это - критика, то "критикуя -
предлагай".
Grigory Panov
> > А по-моему не закрыт. И будет закрыт только после того,
> > как этот механизм будет найден, и проверена его работоспособность.
>
> Закрыт вопрос - нужно ли этим
> заниматься - в смысле поиска и
> реализации механизма.
>
> > все остальное можно пока не читать, по поводу первых букв в названии -
> > вообще непонятно, зачем это.
>
> Не понял. Названия чего?
> > > * Все (?) типы Ананаса в C++-коде
> > > начинаются с "a" (маленькая).
> >
> > не все.
>
> Я так и написал - "все (?)", а не "все"
> Это была моя догадка, т.к. нигде не
> видел code style Ананаса.
Это и был ответ на твой вопрос.
> > ARegister, IRegister... не прояснилось?
>
> Если бы не было ATime - то прояснилось бы.
>
> > ATime - вообще выкинуть надо, я его добавил временно,
> > да так и оставил...
> >
> > > == Выводы
> > > Я думаю, выводы напрашиваются сами по
> > > себе :-)
> >
> > Попробую угадать: надо реализовать функциональность 1С v8? :)
>
> Хорошая попытка.
> Не угадал.
>
> Речь идет о перестройке текущего
> дерева классов Ананаса в более
> логичное.
> _Как_пример_ можно взять 1C v8.
> Пример дерева, а не пример названий
> классов.
> Хотя сами названия основных типов там
> тоже удобные.
Короче, какие изменения ты предлагаешь и какую пользу они по-твоему принесут.
Желательно с примерами.
>
>
--
Grigory Panov
Dmitriy.Kruglikov
Grigory Panov писал(а):
>
> Короче, какие изменения ты предлагаешь и какую пользу они по-твоему принесут.
> Желательно с примерами.
>
Мне так кажется, что различия,
приведенные в примере
http://ananas.lrn.ru/phpBB2/viewtopic.php?p=1028#1028
должны, в результате, сойти на 0 в
результате всех этих действий :)
...
TI_Eugene
> названия классов в скрипте.
Чтобы я мог отличть названия классов
Ананаса от всех остальных (например -
моих).
В конце концов девелы Qt, wx и других
хороших и не очень библиотек зачем-то
пошли на это.
> > Я так и написал - "все (?)", а не "все"
> > Это была моя догадка, т.к. нигде не
> > видел code style Ананаса.
> Это и был ответ на твой вопрос.
"Не говорите загадками, Вы меня
изводите!" (с) Ильченко.
Я сегодня не выспался, видать.
На какой вопрос-то?
> > Речь идет о перестройке текущего
> > дерева классов Ананаса в более
> > логичное.
> > _Как_пример_ можно взять 1C v8.
> > Пример дерева, а не пример названий
> > классов.
> > Хотя сами названия основных типов там
> > тоже удобные.
>
> Короче, какие изменения ты предлагаешь и какую пользу они по-твоему принесут.
> Желательно с примерами.
ОК.
Я рад, что предложение хотя бы принято
к рассмотрению.
Прежде всего - в наименовании.
* _Все_ классы Ананаса - насинать с
_одной_ _большой_ буквы. Возможно - с
двух (чтобы отделить, например графику
от неграфики.
<Пример>
...
AExtensionFactory
AExtensionPlugin< type >
aForm
aIRegister
...
aWindowsList
iTemplate
wCatalogEditor
...
</Пример>
Должен остаться кто-то один.
По поводу дерева - развернуть бы код
под какой-нить IDE (BTW неплохо было бы в
самом проекте оставить конфы,
например, KDevelop), и присмотреться
внимательнее.
Но я смогу это сделать уже после
кросс-транслятора (который сам по себе
забирает время), т.е. - очень нескоро,
скорее всего.
Grigory Panov
Перефразирую вопрос:
Какие конкретно действия (пр. класс aCatalogue надо разделить на 6 классов,
что потребует полного переписывания этого класса и принесет такую-то пользу)
надо произвести в ананасе, что для этого придется
дописать/выкинуть/переписать и что это даст в итоге.
Я это хотел узнать, а не то, что язык Ананаса станет похож на язык 1С, что
еще тоже вилами писано...
--
Grigory Panov
Dmitriy.Kruglikov
Andrey писал(а):
> Теперь о процедурах.
> Так как похоже появились реальные желающие вносить вклад в виде кода в проект,
> то я бы предложил не заниматься дальше высказыванием аргументов о пользе
> совместимости С 1c, а присылать патчи повышающие такую совместимость, для
> тестирования и вливания в проект.
> Патчи прошу сопровождать пояснениями и аргументами об их полезности. Такие
> пояснения и аргументы как раз и стоит публично обсуждать, на мой взгляд.
Андрей, на мой, непрофессиональный,
взгляд этот патч будет приближаться к
100% переработке ... В купе с переходом на
Qt4 ...
Может быть имеет смысл выделить в
отдельную ветку?
В рамках проекта .... А?
Пускай она некоторое время будет иметь
статус экспериментальной и не
рекомендованной для пользования ....
Только для узкого круга разработчиков
и тестеров...
Но как-либо патчить текущую версию -
убийственно для неё...
А бы не стал ее трогать, а доводил до
рабочего состояния как есть, без
изменений.
А вот в экспериментальной ветке
испытать все новшества, которые
предлагаются, и, если такая
целесообразность будет, уже из нее
перенести наработки по синтаксису в
текущую ветку .... Ну, или оставить
существующий вариант с существующим
синтаксисом для тех, кому 1С ни в какие
места не впёрлась ...
Как тебе такой паритетный вариант ?
Как по мне, так минимальный напряг для
всех...
Кому хочется шашкой помахать, имеют
такую возможность, и ни кого не
напрягают на предмет рассмотрения
патчей и требованиями включить в
текущую ветку "еще вчера" ...
И работа идет в двух направлениях
паралельно, и удачные наработки
"кочуют" между двумя ветками ...
Давай, выноси свое одобрительное
решение, и будем уже плодотворно
трудиться ...
:)
TI_Eugene
> приведенные в примере
> http://ananas.lrn.ru/phpBB2/viewtopic.php?p=1028#1028
> должны, в результате, сойти на 0 в
> результате всех этих действий :)
Я точно не выспался...
В результате каких _этих_?
Но - указанная сцылка навела на второй
RFC (в смысле - request for changes)
(потому как "синтаксис Ананаса
корректнее сравнивать с синтаксисом
1с8" - лесть грубая, хотя и приятная):
* разделить классы на более мелкие - с
четкой ориентацией по ф-циям.
Пример:
<code>
var cat1 = new Catalogue("Контрагенты");
cat1.Select();
var fam = cat1.GetElementValue(name, "Фамилия");
</code>
С т.з. семантики здесь используются
объекты 3-х типов:
* Ссылка на справочник
* Результат выборки
* Ссылка на элемент справочника
Сравним (сорри - пишу по памяти, могу
сильно ошибиться) с 8кой - в стиле
Ананаса (можно и по-другому):
<code>
var cat1 = CatalogsManager.Catalog["Контрагенты"]; //
получили объект типа CatalogManager
var sel = cat1.GetSelection(); // CatalogSelection - это 5-й
тип (первый из забытых :-)
var cref = sel.GetReference(); // сцылка на элемент
var fam = cref.Field["Фамили"]
</code>
Grigory Panov
> > > Не понял. Названия чего?
> >
> > названия классов в скрипте.
>
> Чтобы я мог отличть названия классов
> Ананаса от всех остальных (например -
> моих).
В скрипте.
У тебя их будет с десяток, неужели не запомнишь?
А что еще за "мои классы"?
Возможно имеет место непонимание различия между именами
c++ классов и классами qsa.
сейчас многострадальный класс aCatalogue называется в скрипте
Catalogue, а мог бы называться VasyaPupkin
> В конце концов девелы Qt, wx и других
> хороших и не очень библиотек зачем-то
> пошли на это.
Мы про QSA говорим сейчас, и там нет такой практики
допустим класс Math называется Math, а не QSMath
> > > Я так и написал - "все (?)", а не "все"
> > > Это была моя догадка, т.к. нигде не
> > > видел code style Ананаса.
> >
> > Это и был ответ на твой вопрос.
>
> "Не говорите загадками, Вы меня
> изводите!" (с) Ильченко.
> Я сегодня не выспался, видать.
> На какой вопрос-то?
Как с Вами сложно, Евгений.
поищи в своем посте знак вопроса. На него я и ответил.
ti_eugene> > * Все (?) типы Ананаса в C++-коде
ti_eugene> > начинаются с "a" (маленькая).
gr> не все.
--
Grigory Panov
TI_Eugene
Всё будет не так.
> в стиле Ананаса:
<code>
var cat1 = CatalogsManager["Контрагенты"];
var sel1 = cat1.Select();
var fam = sel1["Фамилия"]
</code>
в стиле 7.7:
<code>
var cat1 = CatalogsManager.Контрагенты;
var sel1 = cat1.Select();
var fam = sel1.Фамилия
</code>
А всего требуются такие классы -
аналоги:
* CatalogsManager
* CatalogManager
* CatalogRef
* CatalogObject
* CatalogSelection
* CatalogList
TI_Eugene
* CatalogManager
* CatalogRef
* CatalogObject
* CatalogSelection
* CatalogList
Польза - удобное, логичное дерево
классов, исключающее или значительно
снижающее количество ошибок при
написании скрипта.
Пример неудобного:
<code>
var cat1 = new Catalogue("Контрагенты");
var fam = cat1.GetElementValue(name,"Фамилия");
</code>
Error: Справочник не позиционирован.
Разбор:
* Справочник _не_может_ быть
позиционирован! Может
позиционироваться только _ссылка_ на
справочнки. И даже не на справочник, а
на выборку из него.
* Да, может быть и cat1.GetElementValue("Фамилия").
Но это работа не с конкретным полем
конкретного элемента, а с колонкой
(если рассматривать справочник как
таблицу). С совсем другими методами.
Люди, не воспримите как немца - я ж не
шуму ради всё это пишу.
Да, речь идет о переделках. Да, они
значительные. Но - "детей надо
воспитывать, пока они лежат поперек
дивана <сложенного>. Потом будет
поздно." (c) моя матушка.
Лучше сейчас переделать пару десятков
классов - чем потом попасть в ситуацию
<censored/>
На ошибках - учатся. Но "на своих
ошибках учатся только дураки" (с)
Бисмарк (умный мужик был, BTW).
Перед глазами живой пример <censored/>
когда следующая версия не совместима с
предыдущей. Да, конвертер метаданных
есть и давно. А вот модули - руками. Не
конвертируются абсолютно. И - самое
интересное - и не могут
конвертироваться _принципиально_. И
фирма пошла на значительные убытки
только потому, что предыдущий
синтаксис был крайне неудачен.
Ну не будем же повторять ошибок!
Нет, я конечно понимаю, что девелы
Ананаса даже и не смотрели (типа) в
сторону <crnsored/>. Но при просмотре списка
методов того же Catalogue не покидает
чувство, что содрано... пардон -
реинжиниринговано с 7.7 1-в-1 :-))) 7.7 - не
лучший образец, честное слово.
PS. Что-то я расписался сегодня... Всех - с
пятницей!
TI_Eugene
Неа.
Десяток своих + сотня ананасовских +
тысяча Qt + пара сотен плагинов
сторонних разработчиков... Не запомню.
И не должен запоминать. И не я.
Если код идет на экспорт - ни о каком
"запомнить" не может идти речь.
> А что еще за "мои классы"?
Не твои, а мои :-)
Которые я написал.
Могу?
> Возможно имеет место непонимание различия между именами
> c++ классов и классами qsa.
Бывает.
Именование C++ желательно привести в
порядок - это я уже писал.
А QSAшные - само собой. И - желательно -
синхронно.
Чтобы не думать потом - как один и тот
же класс называется в Ананасе и в
скрипте.
> Мы про QSA говорим сейчас, и там нет такой практики
> допустим класс Math называется Math, а не QSMath
Это - среди trolltech.
Мы ж не девелы QSA, правда?
И находимся несколько в другом ракурсе
относительно QSA.
> Как с Вами сложно, Евгений.
Бывает :-)
Andrey
> > Теперь о процедурах.
> > Так как похоже появились реальные желающие вносить вклад в виде кода в
проект,
> > то я бы предложил не заниматься дальше высказыванием аргументов о пользе
> > совместимости С 1c, а присылать патчи повышающие такую совместимость, для
> > тестирования и вливания в проект.
> > Патчи прошу сопровождать пояснениями и аргументами об их полезности. Такие
> > пояснения и аргументы как раз и стоит публично обсуждать, на мой взгляд.
>
> Андрей, на мой, непрофессиональный,
> взгляд этот патч будет приближаться к
> 100% переработке ... В купе с переходом на
> Qt4 ...
Дмитрий, тогда я не понимаю какая связь того совместимого продукта с проектом
Ананас?
У меня такое ощущение, что группу разработчиков проекта Ананас все
рассматривают как бесплатную рабочую силу и считают своим долгом направить их
на путь истинный :)
Давайте уже закроем эту тему. Так как нам не хватает собственных ресурсов и
для достижения своих целей.
Участники проекта Ананас готовы делиться даром со всеми результатами своего
труда, но не собственными рабочим временем :)
Почувствуйте разницу.
--
Андрей
Dmitriy.Kruglikov
Andrey wrote:
> Дмитрий, тогда я не понимаю какая связь того совместимого продукта с проектом
> Ананас?
Он был и останется проектом Ананас ...
Допустим, у классов появятся новые
названия, но внутри-то они останутся
такими же, или немножко измененными ...
К примеру ...
Когда я говорил о том, что объемы
патчей будут соизмеримыми с объемом
самого кода, я имел в виду, что
изменения могут быть в каждой строке ...
Ну хоть по запятой добавить, и уже
строка изменена ...
Патчи будут просто огромными ...
> У меня такое ощущение, что группу разработчиков проекта Ананас все
> рассматривают как бесплатную рабочую силу и считают своим долгом направить их
> на путь истинный :)
Тут ты не прав ...
Группа разработчиков Ананас уже
проделала, и продолжает делать
огромную работу... И это понимают все,
тут собравшиеся ...
И идея портировать на Qt4 и доработать
синтаксис, поддерживается реальными
намерениями ... Ни кто ж не говорит "вот
вы сделайте" ... Говорять "мы сделаем" ...
Таким образом, группа разработчиков
Ананас получает пополнение ...
>
> Давайте уже закроем эту тему. Так как нам не хватает собственных ресурсов и
> для достижения своих целей.
Ну, если в ходе работы над веткой Qt4
будут выработаны какие-либо решения
(вне графических элементов, а в
алгоритмике и чистой математике),
которые можно будет использовать в
основной (официальной) ветке, так это
только облегчит ваш труд ...
А мне кажется, что именно таким образом
будет строится работа в тестовой
ветке, так как делать работу дважды ни
кто не хочет ... :)
>
> Участники проекта Ананас готовы делиться даром со всеми результатами своего
> труда, но не собственными рабочим временем :)
>
Вот мы и хотим ваше время вам
сэкономить ...
И не трёпом, а реальными делами ...
Andrey
>
> Andrey wrote:
>
> > Дмитрий, тогда я не понимаю какая связь того совместимого продукта с проектом
> > Ананас?
> Он был и останется проектом Ананас ...
> Допустим, у классов появятся новые
> названия, но внутри-то они останутся
> такими же, или немножко измененными ...
> К примеру ...
> Когда я говорил о том, что объемы
> патчей будут соизмеримыми с объемом
> самого кода, я имел в виду, что
> изменения могут быть в каждой строке ...
> Ну хоть по запятой добавить, и уже
> строка изменена ...
> Патчи будут просто огромными ...
Тем не менее другой процедуры взаимодействия разработчиков я не вижу, кроме как работа с патчами.
Не к тебе, Дмитрий, обращаясь, давно призываю заниматься делом - кодировать, документировать, ...
а не напрягать Ананасовцев поучениями и пожеланиями
Хочу поблагодарить за высказанные мысли. Не смотря на что, что я отвечал в основном в негативном ключе,
я стараюсь не упускать интересные и/или полезные замечания. Следите за развитием проекта и возможно у кого-то появиться возможность
воскликнуть "Ну я же так и говорил" :)
>
>
> >
>
--
Андрей
Dmitriy.Kruglikov
Andrey писал(а):
> Тем не менее другой процедуры взаимодействия разработчиков я не вижу, кроме как работа с патчами.
>
Не вижу противоречий ...
Портирование на Qt4 подразумевает
глубокое изучение текущего кода, и при
возникновении конструктивных мыслей и
предложений будет порождаться патч,
что вполне естественно ...
В то же время, не исключена вероятность
того, что кто-либо из разработчиков
Ананас (официальной ветки) захочет
выпустить патч к ветке неофициальной
(Qt4) ...
Тут ни кто ни кому не противоречит ...
Естественно, ни кто не требует, чтобы
разработчики официальной ветки Ананас
бросали все свои планы и начинали
реализовывать идеи и прожекты,
высказываемые в данном треде.
>
> Хочу поблагодарить за высказанные мысли. Не смотря на что, что я отвечал в основном в негативном ключе,
> я стараюсь не упускать интересные и/или полезные замечания. Следите за развитием проекта и возможно у кого-то появиться возможность
> воскликнуть "Ну я же так и говорил" :)
>
Твоя позиция понятна и вполне
объяснима.... Ты радеешь за
стабильность процесса разработки, и в
этом прав...
Но факт наличия неофициальной ветки не
является дестабилизирующим фактором
...
У тебя не должно быть причин для
беспокойства ... А возможность выбора
из более чем одного варианта всегда
была полезна для любого проекта ...
И пусть время и практика покажет, что
больше понравится пользователям ....
Мне так кажется, что твое одобрение и
фактическое объявление об открытии
неофициальной (тестовой) ветки Ананас
на QT4 и с попыткой реализовать новый
синтаксис языка, откроет перед
проектом новые перспективы, которые ни
коим образом не мешают развитию
основного направления ...
А вдруг ты пересраховываешься?
А вдруг получится лучше?
Я пока не могу утверждать ни "За", ни
"Против" ...
Давай дадим ситуации развиваться
своим ходом ...
Есть группа энтузиастов, отлично... Дай
им право на самореализацию ...
Они же не забирают у проекта, они дают
проекту... :)
А патчи, они будут, не сомневайся ....
И документация .... (Я вот планирую сесть
за перевод доки по QSA) ...
Grigory Panov
> <censored/>
> На ошибках - учатся. Но "на своих
> ошибках учатся только дураки" (с)
> Бисмарк (умный мужик был, BTW).
> Перед глазами живой пример <censored/>
> когда следующая версия не совместима с
> предыдущей. Да, конвертер метаданных
> есть и давно. А вот модули - руками. Не
> конвертируются абсолютно. И - самое
> интересное - и не могут
> конвертироваться _принципиально_. И
> фирма пошла на значительные убытки
> только потому, что предыдущий
> синтаксис был крайне неудачен.
> Ну не будем же повторять ошибок!
>
> Нет, я конечно понимаю, что девелы
> Ананаса даже и не смотрели (типа) в
> сторону <crnsored/>. Но при просмотре списка
> методов того же Catalogue не покидает
> чувство, что содрано... пардон -
> реинжиниринговано с 7.7 1-в-1 :-))) 7.7 - не
> лучший образец, честное слово.
Правильно я понял, что ты предлагаешь
переписать все классы Ананаса
к виду 1Сv8 like?
Это все равно, что написать Ананас
заново. Т.е весь код, который есть
сейчас и
который с таким трудом отлаживался,
можно просто выкинуть...
Как то мне не нравится эта перспектива.
TI_Eugene
> переписать все классы Ананаса
> к виду 1Сv8 like?
Как ни ужасно это звучит, но деваться
мне некуда :-)
ДА - именно это я и предлагаю.
> Это все равно, что написать Ананас заново.
Нет, не весь.
1. самое интересное (логика работы
самих объектов) переписывать не
прийдется.
2. Здесь, скорее, не переписывание
заново, а разделение крупных классов
на более мелкие и функционально более
заточенные.
По ходу дела, код приобретет большу
стройность и управляемость.
Пример: я еще не смотрел внутрь Catalogue,
но что-то мне подсказывает, что внутри
сидит некая state machine, по которой
отслеживается, в каком сейчас
состоянии данный объект (например -
позиционирован он или нет). И логика
этой штуки не очень тривиальна, видимо.
Рефакторинг же этого класса позволит
отказаться от этого ненадежного
механизма.
(я могу и ошибаться, просто логика
подсказывает наличие такого механизма
в текущей реализации).
> Т.е весь код, который есть
> сейчас и
> который с таким трудом отлаживался,
> можно просто выкинуть...
Можно, в принципе, зубы никогда не
пломбировать - авось пройдет...
Но в реальности в 100% случаев _потом_
приходится принимать более
основательные и дорогостоящие меры.
В нашем случае - от лица внедренцев -
текущее дерево классов - _неудобно_.
А внедренцы - народ наглый и ленивый, и
тем, чем пользоваться неудобно -
пользоваться не будут.
Зачем людей мучить?
> Как то мне не нравится эта перспектива.
Мне тоже.
Но проект еще на достаточно ранней
стадии, и рефакторить его не так
больно, как переделывать потом или же
наблюдать "широкую известность в узкой
(десяток-полтора народу) среде".
Жалко ведь - столько лет пахать - и
никому не надо...
PS. Я не настаиваю, а только предлагаю. А
также предлагаю еще раз _внимательно_
почитать <censored/>.chm (хотя бы в разделе
"Прикладные_объекты.Справочник*"). И
примерить к себе (как к внедренцу).
TI_Eugene
> Что касается самой 1С - никто не доказал
> пока обратного.
> Если кто-нибудь мне покажет _живую_
> лицензию 1С - буду благодарен.
>
> Предлагаю пока не заостряться на
> юридических моментах.
> Это не суть важно пока.
В ходе icq-переговоров с еще одним
девелом учетного софта basic on 1C опять
возник тот же самый вопрос - "а как на
это отреагирует 1С"?
Вопрос горячий и актуальные уже не
один год.
Дабы не засорять данную рассылку и не
подставлять сотоварищей по оружию -
просьбы высказать мысли по адресу:
http://groups.google.com/group/onel
Thread "LAW"
PS. IMHO вопрос стОит внимания.
Dmitriy Pavlyuk
Возможно, этот вопрос уже и обсуждался, но хочется поднять его еще раз.
Предлагаю, если не всегда, то хотя бы на выбор, иметь возможность
хранить модули и формы отдельно.
Это нужно скажем для хранения на CVS. Или при совместной работе над
конфигурацией.
В общем хорошо бы воспользоваться опытом, 1С.
Например есть программа Федора Езеева, которая распаковывает и
запаковывает конфу 1С.
Так зачем изобретать велосипед, и сразу предусмотреть такую возможность
в самом ананасе.
Думаю многим пригодиться.
Прошу высказаться за и против.
Если стоит вопрос в реализации, то я могу попробовать реализовать эту
фичу в новой программе.
--
С уважением,
Дмитрий Павлюк
Dmitriy.Kruglikov
Dmitriy Pavlyuk писал(а):
> Привет!
>
> Возможно, этот вопрос уже и обсуждался, но хочется поднять его еще раз.
> Предлагаю, если не всегда, то хотя бы на выбор, иметь возможность
> хранить модули и формы отдельно.
Считаю такую возможность
целесообразной и востребованной ....
Особенно, принимая во внимание не
однократные (стоит признать - не
частые) случаи сбоев в конфигураторе
при сохранении, когда конфа слетала
из-за какого-нить глюка в формах...
Как вариант - хранение сжатого
контента в ООО ...
Разархивировал - каталоги с данными, а
так - один файл ...
По моим наблюдениям - экономия места
более чем в 10 раз ....
Моя конфа в чистом виде - 1,5М, а в сжатом
-130К ...
TI_Eugene
за.
Пример:
В ходе разбора типовой 1C:Комплексной в
xml (как в Ананасе - один файл) получился
файл весом 50M (около 6К элементов) (это
без картинок и других двоичных данных).
При этом, заметим, его структура
намного экономичнее ананасовской
(ничего личного - просто так
получилось). Так вот при обработке
DOM-парсером сначала заканчивается 512M
RAM, потом - 1G свопа, а потом... Ну, понятно,
что потом. Вешалка наглухо потом.
Поэтому решено было:
* минимизировать длины имен элементов
и атрибутов.
* вынести текстовые куски в файлы
(модули, хелпы) - это разгрузило файл
примерно наполовину.
* диалоги и таблицы вынести каждый в
отдельный файл.
Правда, DOM-парсер всё равно машину
укладывает :-), но - надежда есть!
Leader
>Привет!
>
>Был успешно выполнен первый этап портирования программы Ананас на Qt4.
>Т.е. сборка программы на Qt4.
>
>На данный момент идет второй этап - перенос наиболее важных частей
>программы на чистый Qt4.
>
>К сожалению, до сих пор не понятна позиция руководителя проекта Андрея,
>на происходящее.
>Останеться ли результат работы лишь частной инициативой, или код будет
>принят в проект.
>
>
>
Мое мнение:
1. Переход на QT4 планируется начать не ранее выпуска 1-й версии Ананас
2. Полный переход будет осуществлен после включения QT4 в стандартные
дистрибутивы Linux, т.е. после выхода KDE4
3. Экспериментальный вариант сборки для QT4 в дерево проекта будет
добавлен в соотв. с п.1
4. Не вижу смысла поддерживать одновременно QT3 и QT4 в связи с
увеличением трудоемкости синхронизации функциональности из-за
идеологических различий в плагинах и SQL (IMHO). Или прийдется писать
дополнительную абстракцию для отвязывания от версии QT
Вывод: код будет принят в проект, по-любому!
Валерий Гражданкин
Silin D
А можно по всем вышеуказанным пунктам ещё и даты, проставить, хотя бы
ориентировочные?
Спасибо.
Дмитрий Силин
Dmitriy P.
Попалась статья, о реинжинеренге, по сути портирование этим и являеться:
http://www.codenet.ru/progr/other/reengineering.php
Так в ней говориться, что реинжинеринг, гороздо сложнее написание нового
программного обеспечения.
А кто-то утверждал, что это просто. ;-)
Silin D
Dmitriy P. пишет:
> Привет!
>
> Попалась статья, о реинжинеренге, по сути портирование этим и являеться:
> http://www.codenet.ru/progr/other/reengineering.php
>
> Так в ней говориться, что реинжинеринг, гороздо сложнее написание нового
> программного обеспечения.
> А кто-то утверждал, что это просто. ;-)
>
>
Dmitriy P.
>>
> Мое мнение:
> 1. Переход на QT4 планируется начать не ранее выпуска 1-й версии Ананас
Вот этого я вообще не понимаю, смысл развивать проект на умерающе платформе?
Когда уже на халяву есть возможность перейти на новую версию Qt, и взять
все лучшее от Qt4, что она предоставляет.
Тем более все крупные проекты, уже перешли на Qt4, такие как KDE, и KOffice.
Если учесть, темпы развития Ананаса, то полный переход на чистый Qt4,
будет выполненн не быстро, и займет этот не меньше пару месяцев думаю,
так какой смысл откладывать, терпеть ограничения Qt3, а потом все
начинать сначала?
> 2. Полный переход будет осуществлен после включения QT4 в стандартные
> дистрибутивы Linux, т.е. после выхода KDE4
Имееться ввиду после включения в Альт?
> 3. Экспериментальный вариант сборки для QT4 в дерево проекта будет
> добавлен в соотв. с п.1
Думаю, тут будет логичней открыть SVN, и начинать новый репозиторий.
> 4. Не вижу смысла поддерживать одновременно QT3 и QT4 в связи с
> увеличением трудоемкости синхронизации функциональности из-за
> идеологических различий в плагинах и SQL (IMHO). Или прийдется писать
> дополнительную абстракцию для отвязывания от версии QT
>
Перейти на Qt4, а в версии Qt3 можно только устранять ошибки.
И то не долго, и через какое-то время закрыть эту ветку.