Обсуждение MyTetra v.1.25. Пожелания, багрепорты. (Страница 2 из 6)

Зачитал, все что выше...постараюсь свои мысли выдать структурировано:
1) Формат хранения данных:
Когда у тебя комп, то обход DOM не так страшен, так как проц грузится не особо на долго, дерево все размещать можно в оперативке, обращения к диску минимальны, НО(!) как только нужно будет переводить на уровень гаджетов, от-лайн синхронизации, возможности поделиться - сразу же упрешься во все замечательные ограничения хранилища на базе ФС. А в случае веб-сервиса для публикации и он-ланй синхронизации, даже если писать на очень быстром php и хранить базы где-то на amazon s3 - ну ты скорее амазон повесишь, нежели чем добьешься качественной работы сервиса. Я это говорю как человек с большим опытом администрирования, и хорошим понятием как делаются он-лайн сервисы. А производительность БД - это легко решается масштабированием БД или изначальной заточкой под движки типа couchdb. Как пример, я знаю работающие веб-решение, клиентоориентированное на базе php+Postgresql, где примерно порядка 7000 баз, к которым цепляется порядка 50000 клиентов, и все это крутится всего лишь на двух 4х процессорных серваках, да и к тому же с 32-битными операционками. И тормозов у БД нет, а вот например 1с с базами на основе ФС, начинает валиться на 4х клиентах, а 14 это максимальный предел хоть какой-то работы, в конечном итоге просто кладется вся ФС, огромные очереди на чтение-запись, огромная фрагментация. В БД эти вопросы решены на уровне синхронизации буферов с дисковой копией БД. Я не пытаюсь доказать, что выбранное тобой представление данных плохое, и не говорю - давай использовать SQL базу...оба этих пути могут быть тупиковыми. А могут и нет. Просто из личного опыта, я считаю, чем больше у тебя уровень абстракции между хранением данных и их представлением, тем проше развивать и переносить проект в современных условиях. К примеру выбрав хорошую ORM-библиотеку, ты сейчас завяжешь скажем локальную базу на sqlite, но потом легко сможешь переписать прогу (или дописать модуль) который буде работать с Ораклом....ну и т.д. Это просто как пример.

2)  Синхронизация через дропбокс или гитхаб....блин! ненавижу костыли, они ломаются - а это КОСТЫЛЬ! Это хорошо будет работать для профи, вернее на том, кто понимает. Но, что делать, когда база начнет переваливать 2 гига (ограничение дропбокса) или там будут закрытые данные (бесплатные аккаунты на гитхабе открыты, да и к тому же ограничение в 300 метров)???? Или как пример, на новом месте придется провести полную синхронизацию с дропбоксом или гитхабом, прежде чем начать работать...то есть ты в командировке, нет толкового инета, кроме 3G (дай бог) и ты сидишь и ждешь когда твои ндцать мегабайт придут к тебе...

Очень рекомендую ознакомиться с Evernote!

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

rudenkovk at gmail.com

Какой формат хранения локальных данных вы предлагаете?

Я не пойму, что вы предлагаете. Вы хотите сделать сервис с Web-интерфейсом, чтобы пользователи могли просматривать свои записи, хранимые на сервере синхронизации, в онлайне?

Я знаком. В MyTetra концепт другой.

Хорошо, я ваш контакт сохранил.

Под Suse-11.3x64 завелось после правки исходников (см. вчерашние топики). Подправить бы сразу не мешало. Файлы addnewrecord.cpp и appconfigupdater.cpp, чтоб не сротыкался народ, ага..

Что с локализациями? А то у меня только английский интерфейс..

Пробовал откомпилировать в QT 4.7 под openSuSe 11.2

Ссылки обсолюдные на библиотеки QT из исходников лучше убрать.
Например сделав так
#include <qdir.h>

А вот ресурсы, (раз их код сам не генерирует) лучше добавить в архив исходников.

Ну и русский в меню приятней был-бы - в смысле локализации.
И кнопочка ПОИСК - непомешает, чтоб не нырять в меню постоянно.

Спасибо за внимание.

Уже исправлено в версии 1.26. Новость: http://webhamster.ru/site/page/index/main/news/107.

Пока нет, это будет когда появится полноценная система сборки.

Ждите, будет.

Она есть, в правом верхнем углу. Другого места ей не нашлось. Я планирую её перенести вниз влево в строку состояния, но пока не разбирался, позволяет ли Qt делать в строке состояния кнопки.

Это же не OpenOffice. Работа с таблицами в WyEdit находится в зачаточном состоянии. Там логика простая - если надо разбить ячейку по горизонтали, то программа так же разбивает все ячейки снизу и сверху от разбиваемой. Затем объединяет их в "широкие" ячейки, чтобы снизу и сверху от разбиваемой так и осталось по одной (но уже состоящей из нескольких) ячеек. Если в хитрой конфигурации таблицы этого сделать не удасться, разбиение не будет производиться.

А в какой программе сделано наоборот? Скриншот хотя бы нужен.

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

Это кнопка форматирования в код. В статусной строке есть подсказка.

Хм, вообще-то я специально так сделал. Кнопки TT и {} ведут себя не так, как привычные B U I. Для отмены форматирования TT или {} надо нажимать кнопку сброса [C].

Есть такое дело. Темно-синие иконки я рисовал, когда осваивался с Inkscape. Более светлые для редактора рисовал пожже, когда разобрался с субпиксельным сглаживанием. По хорошему, тёмно-синие иконки надо перерисовать.

Ну сделайте размер окна который вам нужен.

Такое поведение пока в далёкой перспективе.

Недостаёт возможности просмотреть документ программы без всех виджетов. Можно просто скрыть остальные виджеты или отдельным окном открыть просмотр документа. Это вроде несколько минут кодинга.