Может человек хочет json сгенерировать по каким-нибудь данным, и визуализировать? Ну и диффать/мерджить текст обычно попроще — если, например, хочется диаграммы в репозитории хранить.
Наверняка типичных времен для вопросов будет не очень много, что-нибудь вроде 30, 45, 60 секунд.
Поэтому можно просто на карточке где-нибудь в уголочке сделать иконку, которая будет соответствовать нужному времени — например, оранжевый кружочек это 30 секунд, а черный треугольничек это 60. И на странице таймера снизу сделать кнопочки с этими иконками, чтобы переключаться между таймерами с разным временем.
Мне кажется, это удобнее, чем помещать на карточку какой-то код, который нужно сканировать приложением, и делать приложение только ради этого.
----
Вероятно, приложение хочется сделать не только ради этого, но все равно вместо сканирования каждой карточки клацать по нужной кнопке — если их всего три-четыре — будет гораздо быстрее для игроков.
С другой стороны, если бы у карточек был уникальный код, то можно было бы в приложении какие-то дополнительные правила для них включать или что-то такое. Но в этом случае игра из настольной превращается в завязанную на приложение, и в итоге можно дойти до того, что проще приложение с игрой продавать, которое само и номера игроков выберет, и карточки перемешает, и таймер поставит — и не тратить время/деньги на производство физических карточек-коробочек.
Ага, потому что dialogs у них называется список диалогов сбоку, а сам лог сообщений — history. В директории history есть поддиректория view, где, по-видимому, собрались как раз файлы, заведующие отрисовкой этих сообщений. Можно попробовать в файле history_view_message.cpp добавить подобную проверку:
PeerData* pd = item->from();
if (pd->isUser() && pd->asUser()->isBlocked()) return;
Правда, скорее всего, такие сообщения тоже просто будут странно отрисовываться, а не совсем пропадут.
Выше в этом файле есть функция, которая вычисляет габариты сообщения на экране. Возможно, придется добавить почти тот же самый код и туда, только надо будет написать return QSize(0,0); — тогда, скорее всего, оно даже не попытается отрисоваться. Код, естественно, надо вставлять после объявления переменной item, можно прямо на следующей строке.
Странно, конечно. Можно предположить, что изменения коснутся только новых сообщений, потому что старые каким-то образом "кэшируются" (хотя вроде бы и не должны). Вы можете создать с товарищем чат для экспериментов и посмотреть, что будет, если вы его занесете в ЧС. Будут ли новые сообщения заменяться на <blocked>, что будет происходить со старыми сообщениями при перезапуске, и все такое.
Действительно, так может быть попроще. Кода там много, так что я не стал особо вчитываться. Непонятно, как себя начнет вести клиент — может появятся дырки вместо заблокированных сообщений, если их высота рассчитывается где-то еще.
Стоит отметить, что предложенный мной код не удаляет сообщения, а только заменяет их на текст <blocked>. Если хочется их выкинуть из истории сообщений, нужно будет поискать, где они в нее добавляются, и дописать подобную проверку.
Я думаю, у вас есть примерно три варианта, как модифицировать код:
добавить прямо в код список id, которые вы хотите блокировать, и проверять, что UserId (который является просто int32, его можно получить через data.vfrom_id().value_or_empty()) входит в этот список. Естественно, придется каждый раз пересобирать клиент, когда захотелось изменить список;
сохранить этот список в файлик. Тогда нужно будет лишь перезапускать клиент (или написать код так, чтобы файлик периодически перечитывался);
сделать все по красоте, чтобы можно было пользователей блокировать прямо из интерфейса, и все такое.
Первые два варианта несложные, но нужно будет узнать UserId. Наверное, можно его приделать к config.author на строке 438, и тогда он будет показываться прямо в клиенте.
В третьем варианте придется поразбираться с кодом. Однако, как я понял, вы хотите использовать ЧС — в таком случае нужно просто выяснить, что пользователь в нем находится.
HistoryItem, от которого унаследован HistoryMessage, из History* достает PeerData*, соответствующий юзеру. У этого PeerData есть метод asUser(), а у UserData — isBlocked().
Так что, вероятно, должно сработать что-то такое (после строки 440):
UserId from = data.vfrom_id().value_or_empty();
PeerData* pd = from ? history->owner().user(from) : history->peer;
if (pd->isUser() && pd->asUser()->isBlocked()) {
setText({
TextUtilities::Clean(qs("<blocked>")),
Api::EntitiesFromMTP(data.ventities().value_or_empty())
});
} else {
// оригинальные строки 442-448:
if (const auto media = data.vmedia()) {
setMedia(*media);
}
setText({
TextUtilities::Clean(qs(data.vmessage())),
Api::EntitiesFromMTP(data.ventities().value_or_empty())
});
}
Кажется простым вариант взять веб-версию и юзерскриптом или может даже просто хитрым правилом для блокировщика рекламы скрывать все такие сообщения (если вдруг у тегов сообщений в каких-нибудь атрибутах написан id пользователя). Вероятно, уведомления от этого не отключатся. Возможно, вам не подходит этот вариант, потому что десктопная версия нравится больше (или, например, веб-версия не открывается у вашего провайдера).
Касательно вопроса: на строке 445 setText(... data.vmessage() ...) — похоже на то, что вы ищете. Вокруг напишите свой if (видимо, используя data.vfrom_id().value_or_empty()) и поменяйте текст. Опять же, наверняка не спасет от уведомлений, придется покопаться еще, чтобы и их отключить. Хотя, наверное, у вас эти групповые чаты и так на мьюте.
Однако, там несколько конструкторов, так что написать подобный if нужно будет в каждом. Еще стоит обратить внимание, что на 443 строке вызывается setMedia() — скорее всего, так добавляются для отображения прикрепления. Так что чтобы забанить мемы, нужно будет этот кусочек тоже под if загнать.
> Bethesda пообещала выпустить версию Fallout 4 для очков виртуальной реальности HTC Vive уже к 2017 году. К сожалению, об адаптации недавно вышедшего DOOM к VR-технологии не упоминалось.
Вот же говорят, что две у них игры для VR (и потом показывают две будки, одна с Fallout 4, другая с DOOM, обе под вывеской Bethesda VR): https://youtu.be/Z_1mzhRQSsM?t=6299
Действительно, сказали только про дату выхода VR-версии Fallout 4, но, наверное, и DOOM выпустят, раз уже показывают.
Может человек хочет json сгенерировать по каким-нибудь данным, и визуализировать?
Ну и диффать/мерджить текст обычно попроще — если, например, хочется диаграммы в репозитории хранить.
Наверняка типичных времен для вопросов будет не очень много, что-нибудь вроде 30, 45, 60 секунд.
Поэтому можно просто на карточке где-нибудь в уголочке сделать иконку, которая будет соответствовать нужному времени — например, оранжевый кружочек это 30 секунд, а черный треугольничек это 60. И на странице таймера снизу сделать кнопочки с этими иконками, чтобы переключаться между таймерами с разным временем.
Мне кажется, это удобнее, чем помещать на карточку какой-то код, который нужно сканировать приложением, и делать приложение только ради этого.
----
Вероятно, приложение хочется сделать не только ради этого, но все равно вместо сканирования каждой карточки клацать по нужной кнопке — если их всего три-четыре — будет гораздо быстрее для игроков.
С другой стороны, если бы у карточек был уникальный код, то можно было бы в приложении какие-то дополнительные правила для них включать или что-то такое. Но в этом случае игра из настольной превращается в завязанную на приложение, и в итоге можно дойти до того, что проще приложение с игрой продавать, которое само и номера игроков выберет, и карточки перемешает, и таймер поставит — и не тратить время/деньги на производство физических карточек-коробочек.
Ага, потому что dialogs у них называется список диалогов сбоку, а сам лог сообщений — history. В директории history есть поддиректория view, где, по-видимому, собрались как раз файлы, заведующие отрисовкой этих сообщений. Можно попробовать в файле history_view_message.cpp добавить подобную проверку:
Правда, скорее всего, такие сообщения тоже просто будут странно отрисовываться, а не совсем пропадут.
Выше в этом файле есть функция, которая вычисляет габариты сообщения на экране. Возможно, придется добавить почти тот же самый код и туда, только надо будет написать
return QSize(0,0);
— тогда, скорее всего, оно даже не попытается отрисоваться. Код, естественно, надо вставлять после объявления переменной item, можно прямо на следующей строке.Странно, конечно. Можно предположить, что изменения коснутся только новых сообщений, потому что старые каким-то образом "кэшируются" (хотя вроде бы и не должны). Вы можете создать с товарищем чат для экспериментов и посмотреть, что будет, если вы его занесете в ЧС. Будут ли новые сообщения заменяться на
<blocked>
, что будет происходить со старыми сообщениями при перезапуске, и все такое.Собственно, вы в ЧС-то кого-то из чата отправили?
Действительно, так может быть попроще. Кода там много, так что я не стал особо вчитываться. Непонятно, как себя начнет вести клиент — может появятся дырки вместо заблокированных сообщений, если их высота рассчитывается где-то еще.
Стоит отметить, что предложенный мной код не удаляет сообщения, а только заменяет их на текст
<blocked>
. Если хочется их выкинуть из истории сообщений, нужно будет поискать, где они в нее добавляются, и дописать подобную проверку.Я думаю, у вас есть примерно три варианта, как модифицировать код:
data.vfrom_id().value_or_empty()
) входит в этот список. Естественно, придется каждый раз пересобирать клиент, когда захотелось изменить список;Первые два варианта несложные, но нужно будет узнать UserId. Наверное, можно его приделать к config.author на строке 438, и тогда он будет показываться прямо в клиенте.
В третьем варианте придется поразбираться с кодом. Однако, как я понял, вы хотите использовать ЧС — в таком случае нужно просто выяснить, что пользователь в нем находится.
HistoryItem
, от которого унаследованHistoryMessage
, изHistory*
достаетPeerData*
, соответствующий юзеру. У этого PeerData есть метод asUser(), а у UserData — isBlocked().Так что, вероятно, должно сработать что-то такое (после строки 440):
Кажется простым вариант взять веб-версию и юзерскриптом или может даже просто хитрым правилом для блокировщика рекламы скрывать все такие сообщения (если вдруг у тегов сообщений в каких-нибудь атрибутах написан id пользователя). Вероятно, уведомления от этого не отключатся. Возможно, вам не подходит этот вариант, потому что десктопная версия нравится больше (или, например, веб-версия не открывается у вашего провайдера).
Касательно вопроса: на строке 445
setText(... data.vmessage() ...)
— похоже на то, что вы ищете. Вокруг напишите свой if (видимо, используяdata.vfrom_id().value_or_empty()
) и поменяйте текст. Опять же, наверняка не спасет от уведомлений, придется покопаться еще, чтобы и их отключить. Хотя, наверное, у вас эти групповые чаты и так на мьюте.Однако, там несколько конструкторов, так что написать подобный if нужно будет в каждом. Еще стоит обратить внимание, что на 443 строке вызывается
setMedia()
— скорее всего, так добавляются для отображения прикрепления. Так что чтобы забанить мемы, нужно будет этот кусочек тоже под if загнать.Вот же говорят, что две у них игры для VR (и потом показывают две будки, одна с Fallout 4, другая с DOOM, обе под вывеской Bethesda VR): https://youtu.be/Z_1mzhRQSsM?t=6299
Действительно, сказали только про дату выхода VR-версии Fallout 4, но, наверное, и DOOM выпустят, раз уже показывают.