Обсуждение развития MSEide + MSEgui
Модератор: Модераторы
- Alexander
- энтузиаст
- Сообщения: 864
- Зарегистрирован: 18.12.2005 18:10:00
- Откуда: оттуда
- Контактная информация:
Attid писал(а):о пропащие появились =)
Были очень серьёзные проблемы со здоровьем мамы.
Attid писал(а):ну что органайзер сделал ?
Не до органайзера было.
Потихоньку его делаю когда время позволяет.
Пока воюю с записной книжкой. Продумал
более менее формат файлов и организацию
работы. Обойдусь без баз данных, уж очень
муторно и не в тему, простые текстовые файлы в utf8.
Борьба всё ещё предстоит с деревом МСЕ.
Да и с сетками тоже. Сейчас вот буду ФПК новый
качать и собирать
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
Обойдусь без баз данных, уж очень
муторно и не в тему, простые текстовые файлы в utf8.
--------------
А я бы SQlite3 использовал - потому что автоматом предоставит и сжатие, и группировку на SQl-запросах, и локальные индексы + поиск....
ПС:
Парни из M$ ведь не дураки, что для хранения писем в Outlook выбрали БД = DBF.
муторно и не в тему, простые текстовые файлы в utf8.
--------------
А я бы SQlite3 использовал - потому что автоматом предоставит и сжатие, и группировку на SQl-запросах, и локальные индексы + поиск....
ПС:
Парни из M$ ведь не дураки, что для хранения писем в Outlook выбрали БД = DBF.
- Alexander
- энтузиаст
- Сообщения: 864
- Зарегистрирован: 18.12.2005 18:10:00
- Откуда: оттуда
- Контактная информация:
А в каком виде с тз файловой системы и формата файла(ов) SQlite3
хранит данные ?
Идея записной книжки в том, чтобы была возможность автогруппировать
объекты по их полям. Кроме того, в объекте могут быть поля с
разными предназначениями, те это не таблица, но может отображаться
и в виде таблицы. Под объектом здесь следует понимать одну запись
записной книжки, например, человек, собака, корова, контора Никонора, монета из коллекции, ....
Впрочем выложу в тему органайзера рабочий вариант формата.
Думаю программа могла бы заинтересовать многих.
Я в Линуксе Клаусом пользуюсь. Так он каждое письмо в отдельном
файле хранит. А Оутлук выкинул быстро (заменил Бэтом) после знакомства
с ним в 2000 году. Вирусы собирает, ящики не сохраняет, глючит.
И криптографию не поддерживает.
хранит данные ?
Идея записной книжки в том, чтобы была возможность автогруппировать
объекты по их полям. Кроме того, в объекте могут быть поля с
разными предназначениями, те это не таблица, но может отображаться
и в виде таблицы. Под объектом здесь следует понимать одну запись
записной книжки, например, человек, собака, корова, контора Никонора, монета из коллекции, ....
Впрочем выложу в тему органайзера рабочий вариант формата.
Думаю программа могла бы заинтересовать многих.
debi12345 писал(а):Парни из M$ ведь не дураки, что для хранения писем в Outlook выбрали БД = DBF.
Я в Линуксе Клаусом пользуюсь. Так он каждое письмо в отдельном
файле хранит. А Оутлук выкинул быстро (заменил Бэтом) после знакомства
с ним в 2000 году. Вирусы собирает, ящики не сохраняет, глючит.
И криптографию не поддерживает.
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
А в каком виде с тз файловой системы и формата файла(ов) SQlite3
хранит данные ?
Есть несколько фундаментальных ( disk storage ) типов - INTEGER2/4/8, TEXT, FLOAT и BLOB. Остальные типы - композитные (из может быть сколь угодно много ), то есть записываются в поля соответствующих фундаментальных, с определенными соглашениями о формате и опознавательными признаками. Так появились типы VARCHAR, DATE, DATETIME, NUMERIC... Текст хранится строго в UTF8-кодировке. NUMERIC, LARGEINT => INTEGER8. BOOLEAN => INTEGER2. Многостраничный текст, музыка и фото => BLOB, работает на "ура", и чтение, и запись.
Файлы - самые обычные, из заголовка и данных. После удаления записей файлы по умолчанию не уменьшаются (но есть VACUUM или опция "autovacuum" ). Одну или несколько таблиц можно вынести в отдельный файл БД, а потом все эти файлы их объединить в одну виртуальную (на время сеанса ) БД командой ATTACH (за что я сразу ухватился и сделал проект на этой фиче - ROZNITSA называется ).
Режим доступа - настоятельно рекомендуется через SQL, практически неотличимо от PostgreSQL/FireBird. Поэтому о формате файлов можно не задумываться.
ПС:
1) категорически запрещается пользоваться сторонними утиллитами типа SQliteAdmin - создают нестандартный форм полей, запарывают "чужие" БД.
2) за деталями реализации можете посмотреть рабочий вышеупомянутый проект ROZNITSA из реaльной жизни ( лежит в "public.binaries" ветке конференции )
- Attid
- долгожитель
- Сообщения: 2588
- Зарегистрирован: 27.10.2006 17:29:15
- Откуда: 44°32′23.63″N 41°2′25.2″E
- Контактная информация:
debi12345 писал(а):1) категорически запрещается пользоваться сторонними утиллитами типа SQliteAdmin - создают нестандартный форм полей, запарывают "чужие" БД.
кста былоб не плохо прям в МСЕ сделать создание БД в SQLite через гуи.
можно внести в список полезных прог на сайте =) только у на сайте в МСЕ всего 3 человека видно.
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
кста былоб не плохо прям в МСЕ сделать создание БД в SQLite через гуи.
Мартин на это намекает уже давно - но в проекте пока сидят голые прикладники ( озабоченные только своими рабочими проектами ), которым не до IDE. Эх, совсем плохо без бескорыстных энтузиастов...
Лично я - не особый сторонник этой тулзы, потому что манипуляции с БД через SQL-скрипты гибче ( и безопаснее ), ИМХО.
обновился до ФПК 2.2.0. "Экзешники" стали крупнее (ну всегда так).
Причина резкого увеличения экзешников - включение всех возможных модулей в USES - чтобы не нужно было искать, какой модуль включить для компиляции некоего "EVENT HANDLER". Это я "удружил" - скрипт написал для генерации "UNIT GROUPs", сканирующий RTTI и узнающий, какие модули могут быть ПОТЕНЦИАЛЬНО задействованы.
Лечится только релизной сборкой ( смартлинк, выкидывание отладочной информации ). Кстати, FPC 2.2 пока не даст сделать смартлинк.
Но make действительно не работает,
Работает, но только после выравнивания дат файлов ( делаемом при BUILD ).
- Alexander
- энтузиаст
- Сообщения: 864
- Зарегистрирован: 18.12.2005 18:10:00
- Откуда: оттуда
- Контактная информация:
Мартин поднимал тему раскрутки МСЕ.
Думаю, что без х вещей массовый пользователь к МСЕ не потянется.
1. Документация.
2. Автодополнение. Да, к нему народ привык. И это действительно
нужная вещь.
3. Отсутствует механизм компонентов. Сейчас для установки
компонента надо менять вручную содержимое файла.
Без этого МСЕ будем пользовать только мы, круг посвящённых
Но если о 3п должен подумать Мартин, то над первыми двумя и мы должны.
У меня есть пара мыслей насчёт документирования.
Думаю, что без х вещей массовый пользователь к МСЕ не потянется.
1. Документация.
2. Автодополнение. Да, к нему народ привык. И это действительно
нужная вещь.
3. Отсутствует механизм компонентов. Сейчас для установки
компонента надо менять вручную содержимое файла.
Без этого МСЕ будем пользовать только мы, круг посвящённых
Но если о 3п должен подумать Мартин, то над первыми двумя и мы должны.
У меня есть пара мыслей насчёт документирования.
- debi12345
- долгожитель
- Сообщения: 5761
- Зарегистрирован: 10.05.2006 23:41:15
- Откуда: Ташкент (Узбекистан)
2. Автодополнение. Да, к нему народ привык. И это действительно
нужная вещь.
Народ - понятие растяжимое. Лично я не вижу в нем особого смысла. Нынешний незакрываемый popup намного удобнее - лазишь в нем, варианты смотришь.
3. Отсутствует механизм компонентов. Сейчас для установки
компонента надо менять вручную содержимое файла.
Это не от Мартина зависит, а от FPC. Делать суррогатные псевдо-компоненты по типу Лазаруса - нет смысла, потому что нет наработанных компонент, которые нужно срочно импортировать.
1. Документация.
В точку ! Это - ЕДИНСТВЕННОЕ препятствие для новичков.
У меня есть пара мыслей насчёт документирования.
Это какие ?: Приказать по-военному "Дока, напи-шИсь!" ?
Лично я считаю, что без финансового поощрения ( в рамках наших умеренных цен и зарплат ) это процесс будет крайне медленным ( по себе знаю - невероятно адский и ненужный для пишущего это труд, и нужно уйму свободного времени, с которым у профессионалов всегда напряг, а непрофессионал такую систему не разложит по полочкам ). Я, увы, не профессионал ( они все в Москве ) - но держу в качеств ориентира.
Кстати, Мартин случайно не миллионер ?
- Alexander
- энтузиаст
- Сообщения: 864
- Зарегистрирован: 18.12.2005 18:10:00
- Откуда: оттуда
- Контактная информация:
Не совсем.
Есть путь документирования исходников в них самих - pasdoc.
Этот путь удобен для программиста (создателя программы).
Другой путь - просто документировать, а потом тоже лазить, искать.
Этот путь удобен для писателя документации - не программиста.
Третий путь - как в Делфи - автодополнение и контекстная справка.
Этот путь наиболее удобен для пользователя. Но ещё не позволяет
пользователю участвовать в процессе.
На мой взгляд должно быть что то вроде базы данных с уникальными
вхождениями "путей" (функций записей типов констант классов итд.)
А возможно, наоборот, не база, а к каждому файлу исходников
файл(ы) доки.
Для каждого такого вхождения можно написать доку, причём на разных
языках. RAD могла бы давать запрос к такой базе и показывать
справку. Если вхождения нет - пользователю будет предложено дописать.
Например написал название функции нажал на что то и получил
справку по ней. Или нажал правой кнопкой мыши на поле в
object inspector и получил справку по нему. А нет - разобрался и написал.
Такая база могла бы быть полезной не только для МСЕ.
Мне автодополнение в Делфи и ВБ помогало в изучении языка и
заметно ускоряло написание программ. Это могучая вещь.
Но если физически возможно реализовать вышеуказанную систему
помощи, можно относительно несложными средствами реализовать
и автодополнение, которого в Делфи не снилость - с описанием.
Вот.
Есть путь документирования исходников в них самих - pasdoc.
Этот путь удобен для программиста (создателя программы).
Другой путь - просто документировать, а потом тоже лазить, искать.
Этот путь удобен для писателя документации - не программиста.
Третий путь - как в Делфи - автодополнение и контекстная справка.
Этот путь наиболее удобен для пользователя. Но ещё не позволяет
пользователю участвовать в процессе.
На мой взгляд должно быть что то вроде базы данных с уникальными
вхождениями "путей" (функций записей типов констант классов итд.)
А возможно, наоборот, не база, а к каждому файлу исходников
файл(ы) доки.
Для каждого такого вхождения можно написать доку, причём на разных
языках. RAD могла бы давать запрос к такой базе и показывать
справку. Если вхождения нет - пользователю будет предложено дописать.
Например написал название функции нажал на что то и получил
справку по ней. Или нажал правой кнопкой мыши на поле в
object inspector и получил справку по нему. А нет - разобрался и написал.
Такая база могла бы быть полезной не только для МСЕ.
debi12345 писал(а): Лично я не вижу в нем особого смысла. Нынешний незакрываемый popup намного удобнее - лазишь в нем, варианты смотришь.
Мне автодополнение в Делфи и ВБ помогало в изучении языка и
заметно ускоряло написание программ. Это могучая вещь.
Но если физически возможно реализовать вышеуказанную систему
помощи, можно относительно несложными средствами реализовать
и автодополнение, которого в Делфи не снилость - с описанием.
Вот.
