В сабже у нас появилась первая девочка сети =)

AL> В сабже у нас появилась первая девочка сети =)

Теперь придётся документацию переписывать, где написано, что "девочек не было" =)
Ну ничего, придумаю новые пропагандистские лозунги, хехе.

AL> В сабже у нас появилась первая девочка сети =)

Старожилы, надо поднимать активность и брать пример с новичков. Реприза на первом месте по количеству сообщений на этой неделе (за вычетом роботов, конечно), а мы молчим как рыба об лёд.

в юникодо то веки привёл девочку в сеть, а с ней никто не разговаривает =)

AL> Старожилы, надо поднимать активность ..... а мы молчим как рыба об лёд.

В клиенте ничего нового нет, потому что время на него у меня только в выходные появится.

Повседневная жизнь наша здесь вряд ли кого интересует.
Поэтому и молчание.

AL> в юникодо то веки привёл девочку в сеть, а с ней никто не разговаривает =)

Lit.14 - это контент-эха, она не предназначена для общения.

Вот если бы новички сразу в develop.16, linux.14 и.т.д. писали, тогда бы быстро пошёл разговор :)

К тому же, товарищ девочка даже не представилась и ничего здесь не спросила.

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

Чтобы это сделать, надо:
1. Добавить чекбокс в настройки и пункт в меню
2. Запускать слайдер поверх списка сообщений и убирать список при выходе из слайдера
3. Запоминать позицию в каждой эхе

Самое неудобное - это третье. Ведь кроме обычных эх у нас есть карбонка и избранные. А ещё можно ставить фильтр на непрочитанные на экране списка. Породит костылей немало.
Просто в слайдер передаётся уже сразу массив msgid'ов и позиция в этом массиве.

Сделать могу, это не очень сложно, но сначала реализую то, что запланировано.

vit01> Вот тут ты прав, регламентировать не надо. Просто так сложилось, что никто там ничего не обсуждает. Наверное, потому что рассказы обычно пачками складываются (не всё успеваешь прочитать, да и знаешь, что твои сообщения потеряются после очередного "наполнения").

Ну так они уже не так и актуальны будут. Можно, конечно, поступить как в фило: obec.pactet для произведений и obec.3boh для обсуждения, но в реалиях нашего сообщества мы получим лишнюю пустую эху :)

AL>> Обсуждать в сети только софт для этой сети =)
vit01> Приятное в клиенте не то, что это клиент для IDEC, а то, что он на джаве и на андроид. Есть некий ментальный кайф от решения разных нетипичных и странноватых проблем. Реализовал одну фичу, другую, третью, и наступает удовлетворение, сравнимое с тем, как ты вычёркиваешь какие-нибудь сделанные дела из расписания/плана.

Это да. Сродни ему ещё музыка. Когда нащупаешь что-нибудь интересное.

AL> Ну она же девочка =) А ещё у меня много знакомых, которые не разработчики и не линуксоиды.

Девочки тоже люди, и разработка им не чужда =)
А если серьёзно, то предложения по тематике принимаются.

Из нетехнического нероботизированного у нас есть:
1. Юмор
2. Рогалики
3. Литература (разная обычная и крипота)
4. Мёртвые и разбросанные музыкальные эхи
5. Скрытоэхи (недоступны по понятным причинам)

Это просто по списку эх прошёлся.

AL> Хотя, мои попытки рассказать что-либо в трубе пока не увенчались успехом почти ни разу.

Это момент чисто психологический. Вот смотришь на какое-то сообщение в пайпе, а там всего лишь сообщается какой-то факт, описывается явление и.т.д. Человек просто прочитал и воспринял. Думает: "Ну окей, ясно дело". Чтобы такого не происходило, можно
1. Обращаться к народу, а не просто излагать мысли куда-то в эфир.
2. Добавить небольшую интригу, чтобы захотелось узнать больше и спросить.

AL>> в юникодо то веки привёл девочку в сеть, а с ней никто не разговаривает =)
vit01> Lit.14 - это контент-эха, она не предназначена для общения.

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

vit01> Вот если бы новички сразу в develop.16, linux.14 и.т.д. писали, тогда бы быстро пошёл разговор :)

Ну она же девочка =) А ещё у меня много знакомых, которые не разработчики и не линуксоиды. Не надо превращать сообщество в сугубо технический кружок. Хотя, мои попытки рассказать что-либо в трубе пока не увенчались успехом почти ни разу.

vit01> К тому же, товарищ девочка даже не представилась и ничего здесь не спросила.

Товарищ девочка просто товарищ девочка =)

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

Но это так. Просто идея.

vit01>> Lit.14 - это контент-эха, она не предназначена для общения.

AL> Не думаю, что там нельзя обсудить литературу или попросить совета чего почитать. Нужно ли нам такое строгое регламентирование?

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

Можно это поменять.

AL> Это прямо уже какая-то ментальная мастурбация (извиняюсь за грубость).
На самом деле это так и есть =)

AL> Обсуждать в сети только софт для этой сети =)
Приятное в клиенте не то, что это клиент для IDEC, а то, что он на джаве и на андроид. Есть некий ментальный кайф от решения разных нетипичных и странноватых проблем. Реализовал одну фичу, другую, третью, и наступает удовлетворение, сравнимое с тем, как ты вычёркиваешь какие-нибудь сделанные дела из расписания/плана.

AL>> Хотя, мои попытки рассказать что-либо в трубе пока не увенчались успехом почти ни разу.

vit01> Это момент чисто психологический. Вот смотришь на какое-то сообщение в пайпе, а там всего лишь сообщается какой-то факт, описывается явление и.т.д. Человек просто прочитал и воспринял. Думает: "Ну окей, ясно дело". Чтобы такого не происходило, можно
vit01> 1. Обращаться к народу, а не просто излагать мысли куда-то в эфир.
vit01> 2. Добавить небольшую интригу, чтобы захотелось узнать больше и спросить.

Ну это у меня проблема известная. Я фиговый общун :) Но стараюсь бороть сию особенность.

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

vit01> Чтобы это сделать, надо:
vit01> 1. Добавить чекбокс в настройки и пункт в меню
vit01> 2. Запускать слайдер поверх списка сообщений и убирать список при выходе из слайдера
vit01> 3. Запоминать позицию в каждой эхе

А зачем поверх скиска сообщений запускать слайдер? Я слабо себе представляю разработку под андроид. Это особенности местного UI-строения*

vit01> Самое неудобное - это третье. Ведь кроме обычных эх у нас есть карбонка и избранные. А ещё можно ставить фильтр на непрочитанные на экране списка. Породит костылей немало.
vit01> Просто в слайдер передаётся уже сразу массив msgid'ов и позиция в этом массиве.

А чего неудобного в этом деле? У тебя под капотом sqlite? Создать таблицу-аналог lasts из цезия поди не шибко сложно.

vit01> Сделать могу, это не очень сложно, но сначала реализую то, что запланировано.

Ну оно не так чтобы горит, но я очень ленивый. Именно поэтому в цезии получать сообщения и читать новые можно всего лишь двумя клавишами. Очень удобно положить нетбук на пузо и лениво тыкать пробел или enter =)

AL> А чего неудобного в этом деле?

Не в хранилище данных дело. Проблема в изменчивости позиции внутри эхи. В карбонке, например, хранится одинаковое количество сообщений. Когда ты туда заходишь, клиент просто берёт последние N сообщений, у которых получатель стоит на твоё имя. Как здесь запоминать позицию? Единственным вариантом вижу здесь сохранять последний просмотренный msgid и при каждом входе в карбонку искать его последнее вхождение, дабы вычислить индекс.

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

AL> А зачем поверх скиска сообщений запускать слайдер? Я слабо себе представляю разработку под андроид. Это особенности местного UI-строения*

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

Когда ты жмёшь на эху, открывается активити EchoView, в которую передаются параметры (эха: такая-то, станция: такая-то). EchoView запрашивает содержимое эхи и представляет это в виде списка на экране. Когда ты запускаешь слайдер, то в него передаются параметры (список сообщений: [массив msgid], позиция: число). Слайдер ничего не знает о эхе, он воспринимает только массив msgid, поэтому с его помощью можно делать разные фильтры (например, на непрочитанные сообщения и для работы ii-ссылок).

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

MainActivity (станция), низ стека
EchoView (станция, эха)
MessageSlideActivity (станция, список msgid, позиция), вершина стека

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

ООП весь в своей красе. Компоненты полностью независимы, так что приходится выкручиваться как-то.