Как "усыпить" текущий поток?

[spectre71]

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

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

Немного не пойму вот этого:

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

Если все дело в красоте, то это глупо тормозить процесс загрузки при больших объемах данных. Пусть будет 100 мелких сообщений умножаем на 200мс и уже получаем 20 сек выкинутые в воздух. Кому это нужно?

Никто не говорит что нужно доходить до крайности.
У меня например - 5-100(в зависимоти от ситуации) сообщений во время загрузки, и при общем времени 3-100 сек, потери 0.5-10 сек(приблизительно)

[BRE]

У меня например - 5-100(в зависимоти от ситуации) сообщений во время загрузки, и при общем времени 3-100 сек, потери 0.5-10 сек(приблизительно)

Когда будет много срочной работы, попробуй раз в три минуты останавливаться и размеренно считать до 10. 
Терять на каждой загрузке по 10 сек (в сложных ситуациях), это перебор. Тебе не кажется?
И это для того, чтобы вывести сообщение, которое все равно никто читать не будет... 

[alex12]

Как вариант:

Код

C++ (Qt)
void widget::slot1()
{
  SpalashInfo->show();
  SpalashInfo->info("Start Loading"); //200ms
  SpalashInfo->info("do1");  //1000ms
  QTimer::singleShot (  200, this, SLOT( slot2() ) );
}
 
void widget::slot2()
{
  SpalashInfo->show();
  SpalashInfo->info("do2");  //1000ms
  QTimer::singleShot (  200, this, SLOT( slot3() ) );
}
 
void widget::slot3()
{
  SpalashInfo->show();
  SpalashInfo->info("Start Loading"); //200ms
  SpalashInfo->info("do3");  //1000ms
  QTimer::singleShot (  200, this, SLOT( slot4() ) );
}
 

Еще моджно строить автомат на void QObject::timerEvent(QTimerEvent *event).

Хотя ИМЕННО в данной задаче мне кажется использование тупого sleep оправдано.

[spectre71]

Как вариант:
...
Еще моджно строить автомат на void QObject::timerEvent(QTimerEvent *event).

Хотя ИМЕННО в данной задаче мне кажется использование тупого sleep оправдано.

Я могу делать SpalashInfo->show() , SpalashInfo->hide() совершенно в разных местах и не один раз.
Могу поменять мин интервал в любой момент SpalashInfo->minInfoInterval(int).
SpalashInfo сам определяет сколько нужно сделать доп. задержку(или не нужно), между показами сообщений.
И все это очень просто делается через sleep.

Пока более правильного и более-менее простого решения не нашел.

[ритт]

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

[spectre71]

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

Согласен, хорошее решение, если хочется отказаться от задержек и приемлем вывод статуса в виде списка!
Хорошо смотриться во время загрузки приложения. Возможно на загрузку приложения так и сделаю.

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

[ритт]

сплэш на сохранение файла - вот где слишком информативно

[spectre71]

сплэш на сохранение файла - вот где слишком информативно

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

[ритт]

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

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

[spectre71]

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

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

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

[pastor]

имхо, нужно изначально писать правильно. Будешь писать дальше, софтина разрастется, захочешь что-то изменить и все это закончится переписываним почти с 0.

Но это только имхо

[ритт]

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

[spectre71]

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

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

[ритт]

я не говорил про изменение записываемых объектов.
попросту говоря, имеем двадцать одновременно открытых проектов -> пока сохраняется один, девятнаяцать ещё/уже можно редактировать.

ладно, тема исчерпана.

[spectre71]

я не говорил про изменение записываемых объектов.
попросту говоря, имеем двадцать одновременно открытых проектов -> пока сохраняется один, девятнаяцать ещё/уже можно редактировать.

ладно, тема исчерпана.

Я понял что ты про это не говорил.
Но с тем проектом который сохраняется проблема все равно остается:
- блокировать работу пользователя именно с ним пока он сохраняется(если проект очень большой(1000-10000 задач) то это могут быть ~ 5-20 сек)
- как-то информировать пользователя об этом, чтобы ему не казалось что это какой-то глюк или тормоза
Не говоря уж о том что это тоже не просто, как-то странно оно будет выглядеть для пользователя, то один не доступен, то другой, а может и тот с которым он сейчас работает.
Так что проблему лучше будет решить без дополнительных промежуточных вариантов. А текущий вариант вполне прилично и понятно смотриться, если будет время, сделаю флеш и покажу как это выглядит.
С сохранением в другом потоке я согласен, надо будет обязательно сделать, но пока еще много более приоритетных задач.