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

Выглядит это так:

Всего в коллекции более 1500 векторных иконок, распространяемых авторами под свободными лицензиями. Но если и их не хватит, есть возможность добавлять свои (об этом будет написано в новости к релизу).

Последнюю неделю я активно тестировал новую возможность, и должен сказать, что работать с иконками стало гораздо удобнее. Ветки приобрели свою индивидуальность, и их стало очень легко находить. Так же опытным путем я выяснил, что назначать иконки имеет смысл не всем веткам. Достаточно установить иконки самым важным (ключевым) веткам и тем, с которыми происходит постоянная работа.

Кстати, код в ветке experimental стабилизирован, и можно использвать, например, коммит версии 1.32.260 для тестового использования.

Я очень не хотел это делать, но... С некоторых пор на работе начал вести лекции по использованию Word и Excel. Всю жизнь об этом мечтал... Самое смешное, что что дома у меня нет ни Windows, ни MS Офиса, т. е. даже подготовиться к уроку дома не могу.

Как так получается, что во всей организации атомной отрасли с персоналом over 250 человек, обучение по Word и Excel способен сделать сотрудник, которому эти верды и эксели в болт не упёрлись?

Тут что-то пошло не так...

Уважаемые пользователи программы MyTetra! В настоящий момент в ветке experimental залито несколько изменений, влияющих на стабильность работы программы (синхронизация, поиск). Сборка из экспериментальной ветки в настоящий момент будет очень нестабильно работать. Мне нужно время на исправление ситуации. После исправлений я напишу отдельную новость.

Благодарю за внимание.

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

Консольные команды

В настоящий момент поддерживается четыре команды:

1. Консольная команда выхода из MyTetra:

./mytetra --control --quit

После этой команды запущенный GUI-экземпляр MyTetra корректно завершит свою работу.

2. Команда перечитывания базы:

./mytetra --control --reload

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

https://www.youtube.com/watch?v=NGA0VoDnK6w

Теперь перезапуск не требуется, ибо MyTetra может подхватить изменения без перезапуска.

3. Команда открытия на просмотр записи с нужным идентификатором:

./mytetra --control --openNote <id>

После этой команды в GUI-интерфейсе MyTetra откроется запись с указанным ID. Перед тем как произойдет переключение на указанную запись, изменения в редактируемой записи будут, естественно, сохранены.

4. Команда открытия ветки с нужным идентификатором:

./mytetra --control --openTreeItem <id>

После этой команды в GUI-интерфейсе MyTetra откроется ветка с указанным ID.

Что под капотом у консольных команд

Управление работой MyTetra из консоли происходит следующим образом. Сама GUI-программа получила возможность отлавливать сообщения, отправляемые другим экземпляром MyTetra. Так же, программа MyTetra научилась работать в консольном (управляющейм) режиме, через который и осуществляется управление. При запуске в управляющем режиме, GUI не вызывается, а работает только консоль. Признаком того, что MyTetra запускается в управляющем режиме, служит опция --control.

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

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

На этом пока все, следите за новостями.

Сначала Adobe Flash перестала выпускать Flash под Linux, а с некоторых пор и Dropbox перестал поддерживать работу Dropbox под Linux. Ну как перестал... Формально новые версии выпускаются, но работают криво.

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

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

Как показать иконку Dropbox в систрее в Linux KDE4

Может быть, кому-то поможет.

Сегодня в GIT-репозитарий программы MyTetra в ветку experimental был влит функционал импорта веток в базу знаний. Теперь обмен ветками полноценно работает в обе стороны: есть импорт и экспорт.

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

Кстати, до сих пор еще нет решения одной простой, но важной задачи. Задача предельно проста: сброс форматирования текста в виджете QTextEdit. Описание задачи здесь: Очистка форматирования текста в редакторе MyTetra. Нужно изменить всего одну функцию. На первый взгляд ничего сложного, но диавол кроется в мелочах. Моих знаний Qt пока недостаточно, чтобы реализовать сброс форматирования как положено. Задачу попробовал решить один хороший человек из Питера, но готового результата тоже нет. Возможно, найдется герой, который наконец сможет одолеть сию вершину искусства программирования, пока я допиливаю основной функционал. Иначе зачем вообще нужен OpenSource, если автор практически в одиночку тянет проект?

Желаю всем удачи. Следите за новостями на сайте WebHamster.Ru.

MyTetra - это персональный древовидный менеджер накопления информации. Уже давно пользователи просили сделать возможность выгрузки выбранной ветки, чтобы передать её другому пользователю MyTetra.

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

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

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

Что произойдет после реализации процесса импорта? Я расчитываю, что больше никаких крупных изменений уже не будет. Я сделаю еще несколько косметических правок в MyTetra, и наконец-то выпущу долгожданный релиз.

Следите за новостями.

Программа MyTetra, написанная с помощью фреймверка Qt, имеет пятилетнюю историю. Когда шла фаза начальной разработки,  решался один животрепещущий вопрос: как отображать в тексте символы форматирования, так же, как это происходит в Open/Libre Office при нажатии кнопки с закорючкой, похожей на букву Пи. Готовых инструментов в Qt на тот момент не было, и пришлось дописывать этот функционал путем рисования самодельных изображений символов форматирования поверх текста.

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

Три года назад в Qt появился функционал, позволяющий рисовать символы форматирования. У документа, отрисовывающегося через QTextEdit появились опции отображения символов форматирования. Об этом мне сообщил некто Squarero. Так как функционал был новый, а я пользуюсь библиотеками в консервативном стиле (иначе пользователи не смогут даже запустить мою программу), то я не мог его даже проверить. А сейчас как раз дошли руки до того, чтобы убрать вынужденное уродство из кода, и заменить его парой готовых команд.

Вот как выглядит работа с символами форматирования в Qt:

// Показать символы форматирования

QTextOption option = document()->defaultTextOption();
option.setFlags(option.flags() |
                QTextOption::ShowTabsAndSpaces |
                QTextOption::ShowLineAndParagraphSeparators |
                QTextOption::AddSpaceForLineAndParagraphSeparators);
document()->setDefaultTextOption(option);

// Скрыть символы форматирования
QTextOption option = document()->defaultTextOption();
option.setFlags(option.flags() &
                ~QTextOption::ShowTabsAndSpaces &
                ~QTextOption::ShowLineAndParagraphSeparators &
                ~QTextOption::AddSpaceForLineAndParagraphSeparators);
document()->setDefaultTextOption(option);

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

Вот так это выглядит:

Нажмите для просмотра анимации

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

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

ClipFixer - пример Qt-проекта, в котором демонстрируется работа с буфером обмена

Данная программа написана в рамках говноавтоматизации сметно-договорного отдела промышленной организации, в которой я сейчас работаю.

Задача:

Оператору передаются Excel-файлы смет, каждый экземпляр которых создан со всей сопутствующей фантазией. Единой формы нет, единых принципов составления нет. Единственное, что объединяет эти файлы - шапка сметы, которая содержит почти единообразное кол-во столбцов и почти похожие наименования столбцов. Проблема в том, что один и тот же столбец сметы в разных файлах может занимать разное количество ячеек по ширине (от 1 до 80). И одна запись в смете по высоте может занимать от 1 до 10 ячеек. Кто как захотел, тот так и сделал.

Учитывая, что в организации 8 отделов и 2 сторонних организации, а в каждом отделе (организации) пара человек занимается сметами, и каждый человек составляет сметы примерно в двух-трех различающихся форматах, имеем около 50 различных форматов смет. Всего смет около 3000.

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

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

Решение:

Ну что же, вот вам программа с волшебной кнопкой "Сделать хорошо".

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

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

Код:

Код сделан в лучших традициях говнокодинга. Работает, и ладно.

Скриншоты:

Стандартный вид:

Расширенный вид:

Желаю всем программистам никогда не писать подобные программы.

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

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

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

Допустим, пользователь посетил записи с идентификаторами:

a, b, c, d, e

Затем он стал нажимать кнопку "назад по истории". Так как при движении назад удалять историю нельзя (потому что мы должны иметь возможность двигаться вперед), можно ввести понятие "Указатель в истории". При обычной работе он всегда указывает на самую актуальную (последнюю) ячейку в истории. А при движении по истории "Назад", смещается назад. Таким образом, перед началом движения по истории имеем:

a, b, c, d, e

            ^

А после того, как пользователь отъехал на 4 шага назад имеем:

a, b, c, d, e
^

Тут возникает вопрос. А надо ли при движении назад записывать посещаемые при движении назад записи в конец истории? Правильный ответ - надо (в старой версии MyTetra ответа на этот вопрос я не знал). Потому что если не записывать записи при движении по истории, то произойдет следующее. Предположим, что врнувшись к записи a, пользователь самостоятельно нажмет на запись h. А куда надо записать информацию о посещении h? Самое естественное - в конец истории.  А так как пользователь начал "писать свою историю", то и указатель в истории надо переместить на новую запись. И тогда получим следующее:

a, b, c, d, e, h

               ^

А теперь попробуем снова нажать кнопку движения назад. Куда мы попадем? На запись e. А были то мы до этого на записи a. Хорошо, а если поступить по-другому, и поместить запись h после записи a? В середину истории запись h не засунешь, потому что получится черти что. Единственная возможность - это удалить все записи в истории справа от a, и добавить на их место h:

a, h
   ^

Но тогда теряется практически вся истори! Вот поэтому и надо записывать в историю все посещаемые записи, даже при движении по истории. Если мы записываем все движение назад, от e до a, то к моменту достижения записи a получим:

a, b, c, d, e, d, c, b, a
^

И если в этот момент пользователь самостоятельно кликнет на запись h, то история станет выглядеть так:

a, b, c, d, e, d, c, b, a, h
                           ^

И если пользователь пожелает снова нажать кнопку "Назад", то он попадет на запись a, где он и был до этого. И так далее для других записей в глубину истории, причем последовательность именно та, в которой он видел записи. Для перехода с записи h на запись a история станет выглядеть так:

a, b, c, d, e, d, c, b, a, h, a
                        ^

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

Казалось бы, проблема решена? Нет! Что, если пользователь отъедет назад по истории, и начнет двигаться вперед? Из-за того, что посещенные записи добавляются даже, если происходит движение по истории, то история дополняется новыми записями с той же скоростью, что и движение указателя истории вперед. То есть, указатель никогда не достигнет самой актуальной записи:

a, b, c, d, e, d, c, b, a, h, a, h
                           ^

a, b, c, d, e, d, c, b, a, h, a, h, a

                              ^

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

Решение было найдено в еще одном указателе, который активируется при начале движения назад по истории. Очевидно, что необходимо отслеживать момент, когда началось движение назад, чтобы при движении вперед, при достижении данного маркера перепрыгнуть к самой актуальной записи. Ну а если пользователь снова захочет проехать назад, он будет двигаться по "копиям" идентификаторов записей, которые появились в истории, когда он первый раз путешествовал назад-вперед. Причем последовательность этих "копий" правильная.

Именно такой механизм сейчас и реализован в MyTetra, и, если он покажет свою состоятельность, он будет в релизе.

Следите за новостями.