Еще не ставил, но видео понравилось, я собираюсь использовать как каталогизатор для картинок и рисунков, прочего. Стоки вообще не использую. Спасибо.

Напишите потом как получилось.

Поставил в Debian 8. При запуске в консоли выдаёт

QT_MESSAGE_PATTERN: Unknown placeholder %{time hh:mm:ss.zzz}
Ошибка сегментирования

прочитал сначала - для микрохипстеров.

Сообщу мейнтейнеру пакетов. Спасибо.

Напишите, пожалуста, вашу версию Qt. Важно для фикса.

Аналогичная проблема на buntu 14.04

 QT_MESSAGE_PATTERN: Unknown placeholder %{time hh:mm:ss.zzz}
Ошибка сегментирования 

Using Qt version 4.8.6 

А Брэм Стокер был макростокером или мегастокером?

Минимальный Qt - 5.2

Если у вас Qt ниже 5.2, работать не будет.

Debian 8, Qt 5.3

Если у вас Qt - работать не будет.

вона он тебе ответил уже выше

он был жутким писателем

Там QML?

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

Да

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

Вопрос. Чем не устраивает curl, который работает сейчас?

(username/password сохраняются в зашифрованном виде, с пользовательським паролем, с AES-128 (что бесполезно, пока стоки не перейдут на SFTP)

Ну вот, а то тут недавно в какой-то теме на ЛОРе доказывали, что QML мало кто пользуется, в основном, все остались на QtWidgets.

Я сам больше поклонник QtWidgets, но как я понимаю, здесь QML выбран из соображений нацеленности на мобильные платформы?..

QML был выбран из-за возможности более легкого разделения UI и Code Behind, которые в QtWidgets довольно сильно связаны. Когда я только взялся за QML, была розовая мечта, что тут будет Xaml (от WPF), который будет консистентен и по-настоящему крос-платформен. Но, конечно, тут свои косяки в избытке..

Под мобильные планирую, только рук не хватает. UI по-любому надо будет другой (так, как идеология другая), но Core останется, что удобно.

«из-за возможности более легкого разделения UI и Code Behind, которые в QtWidgets довольно сильно связаны»

мнэээ... А что мешает разделению кода? Разве обязательно функционал мостить в методах виджетов?

«You will need to install the Exiftool to use Xpiks»

На маке это, кажись, неправославно. Ближе к церкве, все в один бандл собрать.

Скоро не надо будет Exiftool вообще. Не хотел раздувать, собственно, бандл.

Нет, но мне QtWidgets напоминает Delphi Forms, Windows Forms, подобие MFC и прочее. Суть не про функционал в методах, конечно, а идеологическое разделение на Model/View/_, которое мне нравится больше (можно отдаленно сравнить к идеи в WPF, Angular, Rails etc.)

Можно считать просто личным предпочтением.

Оно понятно, с точки зрения программера. Но ленивые юзьвери такого не прощают :)

Да, верно. Сначала я получил относительно много негативного фидбека от пользователей, которые не понимали почему у них «ничего не работает».

Та отож... Поэтому после стройной системы пакетов в Линуксе, другие системы кажутся чудищем из лесу :)

QtWidgets напоминает Delphi Forms

Если использовать QTableWidget, то очень напоминает. Если использовать QTableModel/QTableView, то ничем не напоминает. Очень простые модели в 2 строчки вряд ли получится сделать... но и ничего сверхъестественного там тоже нет. Overhead в пару сотен строк максимум.

Да, правда. Но кастомный контрол намного приятней и быстрей сделать в QML, чем в QtWidgets. По крайней мере по тому, что я видел. Может гуру QtWidgets сейчас смеются над такими заявлениями..

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

На plain C++ без всяких *.ui/uic проблемы нет вообще. Если нужно в дизайнере, то «преобразованные виджеты» могут помочь... Сложный контрол конечно придется делать по феншую, устанавливать (при этом не забывать, что designer может работать с одной версией Qt, а сборка идет под другую версию) и т.д.

Дело нужное!

Тестил более раннюю версию вашей программы под Linux Mint - полет нормальный. Несколько месяцев назад переехал с Минта на Manjaro, в репах Xpiks нет, если появится свободное время постараюсь собрать и заценить. А вообще нужную прогу делаете!

Спасибо!

Насчет собрать - вот общий материал http://ribtoks.github.io/xpiks/blog/2014/building-xpiks-alone, а в репозитории можно посмотреть на скрипт для .deb пакета, для .rpm пакета или просто скрипт для тестов на Travis CI, который каждый день собирает Xpiks https://github.com/Ribtoks/xpiks/blob/master/.travis.yml

Если будут вопросы - обращайтесь.

Вопрос. Чем не устраивает curl, который работает сейчас?

Пример: Dokuwiki может импортировать страницу из ODF (плагин), в т.ч. заливая хранимые там картинки. Скриптом можно сформировать нужный файл, возможно, даже, получив метаинфорацию из описания картинки, тем самым сформировав рыбу фото-отчёта. Ну а затем залить используя тот-же curl. Т.е. гибкости больше. Плюс система не задумывается куда и как она заливает.

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

Более того, я там увидел только настройки FTP.

Если у вас есть время и желание - можете также попробовать законтрибьютить уже сейчас.

Больше время. Семья, малой, несколько своих проектов, пара PPA, плюс мелкие апериодические мелкие багофиксы в паре проектов от open source... В общем и хотел бы мир лучше сделать, да сил не хватает :)

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

Обычно с этим проблем не возникает.

Внутри несколькопоточная релизация оптимизирована для загрузки по сети (сейчас - используя libcurl).

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

намного быстрее просто написать bash скрипт с кастомными преобразованиями

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

Собирается, но только Debug-вариант

Собрал Xpiks 1.3 под Manjaro Linux из исходников по вашей инструкции, правда пришлось несколько раз мануал раскурить )) Что интересно, нормально собирается только дебажный вариант проекта! Как собрать релиз я что-то никак не допру, постоянно падает с ошибкой:

/usr/bin/ld: /home/MyName/git/xpiks/src/xpiks-qt/../libs//libquazip.a(zip.o): undefined reference to symbol 'deflate'
/usr/lib/gcc/x86_64-pc-linux-gnu/6.1.1/../../../../lib/libz.so: error adding symbols: DSO missing from command line

При этом Debug собирается с пол-пинка при тех же libquazip.a и libface.a в xpiks-qt/../libs

[Здесь должен быть смайлик чешущий в затылке и разводящий руками]

Вопрос по функционалу

Решил уточнить у вас один момент... Существует ли возможность одновременно добавлять ключевые слова в несколько выделенных изображений? Допустим, у нас есть два изображения (на самом деле их может быть и больше), на одном изображено поле в летний день, на другом летний лес. Я могу сначала вписать в каждое изображение уникальные слова, к примеру для леса: лес, деревья, зелень, листва и т.д. Ну и для поля: поле, колосья, и т.д. Теперь было бы неплохо выделить оба изображения и вписать сразу обоим общие для них ключевые слова, например: солнечно, лето, синее, небо и т.д. При этом конечно же введенные раньше слова не должны поломаться, т.е. новые дописываются к существующим но не перезаписывают их. Я попробовал несколько изображений разом описать - не получилось. Может какая хитрость есть? Или просто не реализовано?

Попробуй добавить явно что-то вроде

LIBS += -lz

В проектный файл (*.pro) приложения (или библиотеки quazip) и обновить Makefile(s) повторным вызовом qmake.

Есть конечно. Выделяете изображения, вверху есть кнопка Edit. Если вы хотите только добавить новые ключевые слова, там есть галочка «только добавить новые». Также удобней редактировать каждое изображение, если 2 раза клацнуть на нем.

Я думаю, вам надо сначала посмотреть скринкасты - может узнаете о новых фичах http://ribtoks.github.io/xpiks/blog/2016/videos

Попробуйте установить libquazip1 пакет (или как он называется в вашем дистрибутиве) и удалить libquazip.a с папки libs и потом пересобрать.

Здесь у нас отголосок «стройной системы пакетов» в линуксе (ранее в комментариях), который стройный, но неконсистентный..

Нет, там проблема в другом была - старый libquazip в дистрибутиве, который чуть-чуть несовместим с новым.

В Debian и OpenSUSE релиз удалось собрать с системным libquazip.
В старой Ubuntu 12.04 (которая на Travis CI) - невозможно и приходится свой quazip протаскивать.

Стоп. А вы делаете Release версию libquazip для Release версии Xpiks или вы используете Debug версию libquazip для Release build Xpiks?

Может вы забыли просто собрать Release версию libquazip?

Может вы забыли просто собрать Release версию libquazip?

Нет конечно )) Собираю релиз из релизных компонент, т.е. libquazip & libface откомпилены в релизе. При этом дебажный Xpiks 1.3 собирается с релизными libquazip & libface на ура. Спасибо за ответы, будет время, попробую варианты описанные выше.