В GitLab'е Wiki сделана через git, каждая правка как комит. И его тоже можно поставить on-premise. На вид все примитивно и до Confluence как до луны, но всё же, они постепенно допиливают.
Мне пора уже Макбук Про агрейдить. Придется покупать, ждал как раз 32Гб. Смущает только рисованная на тачбаре кнопка Esc. Я даже представить себе не могу на сколько это окажется неудобно. Ладно бы еще она как Home Button на iPhone 7/8 имела taptic отклик и углубление, чтобы можно было её вслепую наживать. Так она еще не всегда отображается в зависимости от режима, скрывается другими элементами. Её надо будет постоянно искать глазами.
Хорошо хоть в офисе я пользуюсь внешней клавиатурой, а в дороге придется мучиться.
Кто бы мог поверить, что настанет когда-нибудь тот великий час, когда Майкрософт начнет писать статьи о том, как установить Ubuntu на Raspberry Pi. А Стив Балмер тем временем читает вашу статью и плачет кровавыми слезами. Его пророчество сбылось, та самая «раковая опухоль», как он выражался в свое время о Linux, поразила и его любимую компанию.
В Либрофисе вручную скрытые строки не приравнены к строкам, скрытым фильтром.
У них получается ситуация, что вручную скрытые строки не находятся под защитой и могут быть затерты при сквозной вставке или сквозном автозаполнении или массовом форматировании. А выфильтрованные строки всегда остаются в неизменном виде. В принципе такую логику можно и принять. Она бы устроила большинство пользователей. В любом случае у Libre идея в том, что механизм скрытия строк для ручного и фильтрового скрытия разный, за это по всей видимости отвечает разный код.
В Microsoft Office for Mac 2016 сделано как-то странно. Если только скрывать вручную или только фильтром, то логика получается как и в Либрофисе. Если же в области фильтрации применить фильтр и затем в той же области скрыть пару строк вручную, то ручные строки окажутся под защитой и останутся нетронутыми. Это решение какое-то неочевидное и странное. Не факт, что они действительно так задумывали, возможно, это какой-то побочный эффект или баг.
Решение от Либр на вид более стройное.
«если вы зашли в редактируемый кем-то документ и накосячили».
Да, знакомо. Крайне неприятная ситуация. Но в редакторе таблиц вы разве это исправили? Вроде пока все по-старому. Кнопка Undo неактивна, если в документе более одного человека.
И опять тот же вопрос из раза в раз: фильтры. Когда исправите затирание скрытых с глаз данных при редактировании нескольких строк одновременно? Скрытые фильтром данные должны оставаться неприкасаемыми, это табу. Во всех взрослых редакторах таблиц так.
Большинство коллег не умеет пользоваться кнопкой «сохранить». Они будут фигачить весь день, надолго блокируя содержимое. А потом наивно спрашивать «Как? Ты еще не видел мои изменения?». «Так ты сохрани черт тебя побери!».
И вот придется названивать друг другу, «ну что, готово?». «Да, но я вышел пообедать, забыл сохранить, давай через полтора часа». «Чтоб ты подавился!».
Вот вам примерная зарисовка того, как это будет работать с т.н. строгим редактированием. Этот режим в каком-то смысле действительно более правильный, вы правы, но в идеальной среде. Хорошо, когда все вокруг технически грамотные, ответственные и аккуратные. Но…
Что касается live-editing, то Atlassian обещает прям уже вот-вот зарелизить Confluence 6.0 с такой возможностью. Мы как раз пользуемся их продуктом, но в то же время смотрим, что происходит вокруг в мире и открыты для всего нового, поскольку есть и определенные минусы, не относящиеся к теме разговора.
Так вот у них режим будет намного хитрее, чем в Google Docs. Страница будет существовать в двух ипостасях – для просмотра и для редактирования. И всё безумие с бегающими курсорами и буквами будет происходить только в режиме редактирования у тех, кто редактирует. А проходящие мимо читатели будут видеть старую чистую версию до тех пор, пока последний редактирующий не нажмет «сохранить». Такой подход выглядит самым логичным на данный момент, посмотрим, что у них получится на самом деле.
Искал, где бы в явном виде были перечислены отличия Community версии от Enterprise, но так и не нашел. (только on-premises, SAAS не интересует как класс).
Вот оно, оказывается, и нашлось отличие. Было бы здорово, если бы вы все же написали это где-то. Все ведь понимают, что фирме надо на что-то существовать и платная версия обязана для этого иметь определенную фору в развитии. Так все делают и в этом нет ничего плохого. Просто скажите вслух, чтобы развеять недопонимание.
Хотелось бы установить онлайн опенсорс версию, но без live-редактирования смысла нет никакого.
Уточните пожалуйста, когда произойдет обновление до последней версии?
В GitLab'е Wiki сделана через git, каждая правка как комит. И его тоже можно поставить on-premise. На вид все примитивно и до Confluence как до луны, но всё же, они постепенно допиливают.
Хорошо хоть в офисе я пользуюсь внешней клавиатурой, а в дороге придется мучиться.
У них получается ситуация, что вручную скрытые строки не находятся под защитой и могут быть затерты при сквозной вставке или сквозном автозаполнении или массовом форматировании. А выфильтрованные строки всегда остаются в неизменном виде. В принципе такую логику можно и принять. Она бы устроила большинство пользователей. В любом случае у Libre идея в том, что механизм скрытия строк для ручного и фильтрового скрытия разный, за это по всей видимости отвечает разный код.
В Microsoft Office for Mac 2016 сделано как-то странно. Если только скрывать вручную или только фильтром, то логика получается как и в Либрофисе. Если же в области фильтрации применить фильтр и затем в той же области скрыть пару строк вручную, то ручные строки окажутся под защитой и останутся нетронутыми. Это решение какое-то неочевидное и странное. Не факт, что они действительно так задумывали, возможно, это какой-то побочный эффект или баг.
Решение от Либр на вид более стройное.
Да, знакомо. Крайне неприятная ситуация. Но в редакторе таблиц вы разве это исправили? Вроде пока все по-старому. Кнопка Undo неактивна, если в документе более одного человека.
И опять тот же вопрос из раза в раз: фильтры. Когда исправите затирание скрытых с глаз данных при редактировании нескольких строк одновременно? Скрытые фильтром данные должны оставаться неприкасаемыми, это табу. Во всех взрослых редакторах таблиц так.
И вот придется названивать друг другу, «ну что, готово?». «Да, но я вышел пообедать, забыл сохранить, давай через полтора часа». «Чтоб ты подавился!».
Вот вам примерная зарисовка того, как это будет работать с т.н. строгим редактированием. Этот режим в каком-то смысле действительно более правильный, вы правы, но в идеальной среде. Хорошо, когда все вокруг технически грамотные, ответственные и аккуратные. Но…
Что касается live-editing, то Atlassian обещает прям уже вот-вот зарелизить Confluence 6.0 с такой возможностью. Мы как раз пользуемся их продуктом, но в то же время смотрим, что происходит вокруг в мире и открыты для всего нового, поскольку есть и определенные минусы, не относящиеся к теме разговора.
Так вот у них режим будет намного хитрее, чем в Google Docs. Страница будет существовать в двух ипостасях – для просмотра и для редактирования. И всё безумие с бегающими курсорами и буквами будет происходить только в режиме редактирования у тех, кто редактирует. А проходящие мимо читатели будут видеть старую чистую версию до тех пор, пока последний редактирующий не нажмет «сохранить». Такой подход выглядит самым логичным на данный момент, посмотрим, что у них получится на самом деле.
Искал, где бы в явном виде были перечислены отличия Community версии от Enterprise, но так и не нашел. (только on-premises, SAAS не интересует как класс).
Вот оно, оказывается, и нашлось отличие. Было бы здорово, если бы вы все же написали это где-то. Все ведь понимают, что фирме надо на что-то существовать и платная версия обязана для этого иметь определенную фору в развитии. Так все делают и в этом нет ничего плохого. Просто скажите вслух, чтобы развеять недопонимание.
Уточните пожалуйста, когда произойдет обновление до последней версии?