Спасибо, будем разбираться. Тестировали на похожем ноутбуке — все было отлично. Посмотрю еще. Масштаб системы мы не учитываем. Ориентируемся на dpi устройства. И при переносе с монитора с на монитор — анализируем новый.
Какой размер монитора и разрешение? Мы сами решаем, как масштабировать интерфейс. Но странно, что внутренность не увеличена, а только шапка приложения.
У нас четкое разграничение в редакторах. Логическая (форматная) часть -> измерение -> отрисовка. И сохранение в пдф — это просто подмена отрисовщика на канве/нативного на сохранялку в пдф. Поэтому сохранение в пдф 1-в-1 так, как вы видите в редакторе документ. Согласен на 100%, что если файл не для редактирования и его надо передавать — то только PDF. Чтобы со встроенными шрифтами и без багов/особенностей измерятеля.
Мы считаем, что чем меньше нагрузка на сервер — тем лучше. Так как если пользователь работает с документом — странно передавать (через сервер) эти тормоза человеку, который работает на этом же сервере, но с другим документом. Много людей — потребуется много серверов, а это не выгодно. И, по-нашему мнению, Collabora так поступает лишь по одной причине — потому что у них нет браузерного редактора. И совместного редактирования тоже нет. И был выбран максимально простой вариант — открывать Либру на сервере и транслировать мышь и клавиатуру пользователей. Рабочий вариант, никто не спорит. Но уж точно не «грамотный».
Он сделал два действия, но отменил только одно. Это произошло из-за конфликта с действиями другого пользователя. Если конфликт разрешился, то действия снова могут быть отменены.
Никакого конфликта нет. Он вводил текст и отменил свой ввод. Второй пользователь удалил текст и отменил удаление. При неправильном порядке Undo появляется удаленный текст. Это нормально, тут нет конфликтов, поэтому и нет смысла не давать пользователю не делать Undo. На самом деле ввод двух символов, хоть это и 2 разных действия, но можно их трактовать как одно (например, так делает Google Docs), и на ввод двух символов у вас будет ровно одно Undo, а не 2. В такой ситуации Undo запрещать нельзя, т.к. один из символов все еще есть в тексте.
В совместном редактировании документа. Значит он должен был учитывать, что на состояние влияют другие люди. Рассчитывать на другое, все равно что рассчитывать, что содержимое Интернета не изменится за ночь.
С такой логикой пенять на «неправильную» работу Undo вообще нет смысла. Т.к. пользователь жмет Undo и надеется увидеть предыдущее состояние, но в это время кто-то правит этот же кусок текста (возможно правки вносятся с помощью опять-таки Undo второго пользователя, но первому-то какая разница как) и предыдущего состояния первый пользователь не увидит уже никогда.
Если есть история изменений документа (в виде визуального стека) у пользователей, то человек может попробовать сделать undo. Если при этом в стеке есть действия других пользователей, то отправляется запрос пользователям на разрешение этого undo. Все это верно, если затрагивается блок с общей информацией. Если блок создал и изменял один пользователю, то отмена будет без подтверждений.
С точки зрения интерфейса и взаимодействия пользователей так делать нежелательно. Почти все пользователи всегда уверены в изменениях, которые вносят сами, и если им придет предложение «Разрешить внести изменения в свои правки ради Undo у другого пользователя», то мы почти уверены, что в 99% случаев все будут запрещать это делать и Undo как такового не будет вообще. Кроме этого, такое поведение сильно усложняет совместный набор документа.
Согласен, можно было бы добавить историю документа read-only. То есть можно откатить вид документа по истории внесения изменений (того же стека). При этом добавить возможность печати документа и, например копирования его, чтобы его можно было редактировать уже как отдельный документ.
Хотелось бы добавить по поводу Google. Все выше приведенные примеры на тему «недостатки нашей реализации», повторяются и сейчас в Google документах. Вы можете сами проверить это прямо сейчас. Т.е. в этом плане между нами и Google никакой разницы нет. Поэтому странно слышать про старую реализацию в Google Docs, поскольку у них в этом плане ничего не поменялось. Все эти проблемы, которые есть у нас, есть и у них.
В некотором смысле да. Отдельные части документа, представленные в виде массивов, у нас смоделированы по схеме CmRDT, т.е. по коммутативному варианту, когда другим пользователям мы не пересылаем целиком состояние всего массива, а только изменения связанные с ним, и этим изменения мы коммутируем между собой, чтобы у всех пользователей состояния этих массивов были идентичны.
Во-первых, здесь приведен сильно упрощенный случай из возможных. Хорошо, когда все изменения между собой не связаны, а если бы это изменение, связанное с другим, то так как вы предлагаете сделать уже нельзя. Другими словами, из блока своих действий вырывать какие-то действия и не делать к ним Undo — неправильно, и может привести к еще более худшим последствиям.
Во-вторых, как это будет выглядеть для первого пользователя? Вот он откатил все свои действия до конца (кнопка Undo неактивна), и тут неожиданно после действий другого пользователя его кнопка Undo станет снова активной. Так неправильно, он же ничего не делал, значит и кнопка Undo не должна становится активной для него.
На самом деле у всех слишком большое доверие названию Google. Поредактируйте совместно (двумя пользователями) документ в Гугл и поотменяйте одновременно. И посмотрите, как документ вернется в первоначальное состояние). И тогда наши разговоры может воспримутся чуть лучше.
Никакого конфликта нет. Он вводил текст и отменил свой ввод. Второй пользователь удалил текст и отменил удаление. При неправильном порядке Undo появляется удаленный текст. Это нормально, тут нет конфликтов, поэтому и нет смысла не давать пользователю не делать Undo. На самом деле ввод двух символов, хоть это и 2 разных действия, но можно их трактовать как одно (например, так делает Google Docs), и на ввод двух символов у вас будет ровно одно Undo, а не 2. В такой ситуации Undo запрещать нельзя, т.к. один из символов все еще есть в тексте.
С такой логикой пенять на «неправильную» работу Undo вообще нет смысла. Т.к. пользователь жмет Undo и надеется увидеть предыдущее состояние, но в это время кто-то правит этот же кусок текста (возможно правки вносятся с помощью опять-таки Undo второго пользователя, но первому-то какая разница как) и предыдущего состояния первый пользователь не увидит уже никогда.
С точки зрения интерфейса и взаимодействия пользователей так делать нежелательно. Почти все пользователи всегда уверены в изменениях, которые вносят сами, и если им придет предложение «Разрешить внести изменения в свои правки ради Undo у другого пользователя», то мы почти уверены, что в 99% случаев все будут запрещать это делать и Undo как такового не будет вообще. Кроме этого, такое поведение сильно усложняет совместный набор документа.
История версий у нас есть.
Во-вторых, как это будет выглядеть для первого пользователя? Вот он откатил все свои действия до конца (кнопка Undo неактивна), и тут неожиданно после действий другого пользователя его кнопка Undo станет снова активной. Так неправильно, он же ничего не делал, значит и кнопка Undo не должна становится активной для него.