Gitea: Обсуждение обновления пользовательского интерфейса

Я бы хотел, чтобы это произошло, поскольку Gitea не очень удобна для мобильных устройств, но это будет масштабное мероприятие, и я надеюсь, что оно не отвлечет всех разработчиков от поддержки и работы над обычными функциями Gitea. : смайлик:

Сосредоточившись сейчас только на CSS, у меня есть две основные проблемы:

1. semantic-ui - технологически тупиковый. Он не поддерживает flexbox, и я обычно думаю, что он многое делает сам по себе. Я бы предпочел иметь немного больше контроля, возможно, просто добавив несколько вспомогательных классов.

2. less , вероятно, не требуется. Я считаю, что вложение селекторов - это плохо, потому что это приводит к бесполезно длинным селекторам, которые трудно найти в источнике. С переменными, поддерживающими CSS, я не вижу особого смысла в препроцессоре. Я бы предложил преобразовать в простой CSS.

Отказ от собственных переменных css означал бы отказ от поддержки некоторых браузеров, но я думаю, я бы согласился с этим, поскольку большинство людей, использующих Gitea, в любом случае являются разработчиками, которые обычно используют современные браузеры.
Более серьезной проблемой для меня было бы невозможность использовать такие вещи, как darken($color) и возможность разделить CSS на несколько файлов, которые затем были бы объединены в один единственный CSS (я знаю, что собственный CSS тоже может это сделать. .. вид)

Новый дизайн также может помочь прояснить, что Gitea сильно отличается от Gogs, потому что на данный момент оба имеют в значительной степени один и тот же пользовательский интерфейс.

Что касается Framkework, я бы добавил bulma.io в микс, так как это то, что я использовал в прошлом, и нашел его довольно хорошим. Я избавляюсь от хлопот по большинству вещей, сохраняя при этом высокую настройку и, следовательно, легкую тематику.

Я думаю, что предоставление Gitea собственного уникального пользовательского интерфейса - это то, что определенно поможет показать разницу между ним и Gogs. В то же время я должен сказать, что меньше или scss, вероятно, должны продолжать существовать в этом проекте, поскольку некоторые из их функциональность недоступна в CSS, с точки зрения фреймворка, у меня нет мнения, которое принесло бы пользу этому обсуждению, поскольку лично я просто использую Bootstrap 4 для своих проектов (не то, что следует использовать здесь)

Bulma звучит хорошо для меня :) думал, что это означает полную переписывание пользовательского интерфейса, к сожалению

Я определенно поддерживаю простой CSS и использую такие стандарты, как Flexbox и Grid, вместо фреймворков. Grid предоставляет множество функций, недоступных для фреймворков, отличных от Grid.

@andrewbanchich Bulma основана на flexbox

Да, но если он не основан на Grid, то это все же фреймворк, который использует что-то не так, как предназначалось. Во-первых, в сеточных фреймворках для разметки использовались плавающие элементы, что было обходным решением, поскольку флоты не предназначались для какого-либо вида макета. Теперь они используют Flexbox для полного 2D-макета, но Flexbox предназначен только для 1D-макетов. Сетка предназначена для 2D-макетов и может делать то, что Flexbox не может легко сделать, поэтому я чувствую, что нам следует просто использовать стандартную сетку CSS. На мой взгляд, в сетке больше нет необходимости.

Bulma очень легкая и дает вам довольно красивый стиль из коробки, я не думаю, что у нас есть дизайнер, который мог бы сделать нам здесь красивый дизайн для gitea.

@lafriks Мне очень понравился дизайн @kolaente .

Для меня более серьезной проблемой было бы невозможность использовать такие вещи, как darken($color)

Согласитесь, они мне, безусловно, тоже нужны, и нет чистого CSS-решения для такой настройки цвета. Я лично предпочитаю SCSS, а не LESS, но для легкого использования оба должны быть примерно равными.

но если он не основан на сетке, то это все же фреймворк, который использует что-то не так, как

Сетка - это, конечно, вариант, но есть ли на ее основе подходящие фреймворки?

Вот черновик, с которым я играл: (написано на Bulma)

Я не совсем доволен этим.

@kolaente, можете ли вы поделиться им где-нибудь в каком-нибудь отдельном

@lafriks Конечно: https://kolaente.dev/konrad/gitea-design

Дизайн, сделанный @kolaente, немного напоминает мне Gitlab. Здорово, что есть тема для обсуждения доработки пользовательского интерфейса. Лично мне нравится дизайн рабочего стола, потому что он близок к Github. Думаю, это может помочь многим разработчикам начать работу с сервисом.

Иногда я добавляю проблемы по телефону. Пользовательский интерфейс можно использовать, да. Но у некоторых других сервисов более отзывчивый пользовательский интерфейс. К сожалению, я не очень хорошо разбираюсь в CSS.

Возможно, Twitter Bootstrap можно было бы использовать для гибкости (например, вы можете выбрать только сетку), а другие компоненты, такие как кнопки, имеют настраиваемый макет.

@mbedded использует Bulma от @jgthms , которая также является

Вот черновик, с которым я играл: (написано на Bulma)

Мне нравится дизайн GitHub (все посередине) больше, чем GitLab. Меня это меньше отвлекает.

Я здесь новичок - все началось с открытия проблемы №6687, посмотрел меньше кода и спросил о решении в sass. Впоследствии @techknowlogick указал мне на эту проблему.

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

GitLab / Bitbucket
Не только GitLab использует боковую панель. Многие службы перешли на боковую панель, потому что ее легко найти и развернуть. Каждая запись и подзапись по одному и тому же элементу. Он работает на мобильных устройствах с дисплеем до 5k (немного потеряно) и легко интегрируется вне основного контента. Область заголовка начинается с информации по этой теме текущей страницы.
Если вы добавляете новую функцию или предоставляете систему плагинов, достаточно места для добавления нового (под) пункта меню.

Css / против sass
Используйте компилятор :) Css разный от браузера к браузеру, а такие инструменты, как автопрефиксатор, исправляют множество мелких проблем, без написания нескольких строк для каждого браузера и их удаления позже. Также есть такие функции, как вложение цветовых переменных и функции, такие как темнее / светлее, rgba ($ color, .8). С помощью линтера вы можете принудительно использовать только цвета в качестве переменных максимальной глубины вложения. Настроить переменные для новой темы очень просто.

Бульма тема
Выглядит хорошо (один сопровождающий / нет учетной записи организации), не стандартный бутстрап, материальный дизайн или (zurb-) фундамент. Импортирует только нужные компоненты. Синтаксис Bulma sass необычен. По сравнению с бутстрапом жестко запрограммировано больше размеров.

В любом случае я буду использовать gitea, но мне нужна улучшенная темная тема (без патча для стилуса) и без переменных больше работы, чтобы что-то настроить и получить каждую страницу. Может быть, я смогу немного помочь со стилем, это необходимо.

Что касается боковой панели или других серьезных изменений дизайна: я думаю, что многих пользователей больше всего привлекает то, что пользовательский интерфейс Gitea очень похож на GitHub. Если мы изменим основы макета, например добавим боковую панель, это будет очень разрушительно для пользователей, приспособленных к текущему макету и GitHub. Я не уверен, что приму это.

Как сказал @silverwind : я думаю, пользователям очень легко переключаться или использовать Gitea, если они знакомы с Github, потому что пользовательский интерфейс выглядит почти так же.
С другой стороны (как сказал @ xf-): размещение меню с левой стороны упрощает группировку настроек или пунктов меню. Кроме того, большинство экранов широкие. Таким образом, меню слева дает постоянный доступ к этим элементам и не нарушает контент. Возможно, тему «где разместить меню» придется обсудить позже, если их больше, чем 3-4 пункта.

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

Например. Частное репо на боковой панели высотой 36 пикселей и публичное репо или организация 35 пикселей. Также у организации меньше поля слева. Также ширина обоих контейнеров разная. В профиле организаций второго ряда нет маржи t первого ряда.

О меню: в большинстве случаев навигация нормальная и интуитивно понятная, но меню вверху в настройках / админке действительно странные. Я предпочитаю меню в виде списка. Намного проще / быстрее найти желаемую запись.

Также font-face - это полный беспорядок. Lato определен в sematic-ui.css и index.css. Я не имею в виду переключатели :lang . Я бы использовал шрифт Noto - доступен почти любой язык, моноширинный, а также смайлы. (Может немного оффтопа)
https://en.wikipedia.org/wiki/Noto_fonts
https://www.google.com/get/noto/

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

Большинство IDE включают компилятор SALL / LESS по умолчанию или могут быть добавлены в качестве плагина для обновления файла css при сохранении файла исходного кода. Правда шрифт здесь может быть не по теме. Но это часть первоначального поста для

Я открываю этот билет, чтобы мы могли обсудить будущее Gitea UI.

Возможно, я смогу немного помочь с организацией некоторых файлов или преобразованием некоторых частей в SASS. С моей точки зрения (мнения могут отличаться) есть две важные вещи, которые следует обновить:

• Адаптивный макет при использовании gitea на мобильном телефоне (например, для добавления проблем, когда вы не можете использовать свое обычное устройство)
• Улучшите отображение админ-настроек (или личных настроек), потому что настроек очень много. Вертикальное меню может быть лучше горизонтального. Некоторые могут быть добавлены в зависимости от запланированных или желаемых функций.

Например: в Github (если Gitea любит дизайн, похожий на Github) ваши «обычные» элементы горизонтальны для кода, проблем, вики, этапов ..

Остальные настройки вашего репозитория, организации или личного кабинета перечислены вертикально. С моей точки зрения, это отличное дизайнерское решение. В Gitea пока не так много настроек. Но по сравнению с github (если gitea сильно разрастется) горизонтального пространства не хватит или придется всем переходить на экраны 16:10 или экраны телевизоров :)

Как вы можете видеть на следующих скриншотах:

Настройки Github, личный кабинет:

Настройки Gitea, системное администрирование:

Что вы думаете?

Я думаю, что нам всегда нужно держать меньше пунктов в меню, чтобы справиться с этим. Меньше - больше. :)

Что-то, что упростило бы разработку пользовательских интерфейсов, было бы (непростой) задачей создания API для серверов Gitea. Таким образом, интерфейсная часть может быть написана на любом удобном для людей фреймворке - Mithril, React, vanilla JS и т. Д.

@NetOperatorWibby Gitea имеет api, на данный момент он просто не является полнофункциональным, см. Https://try.gitea.io/api/swagger

Я разрабатываю кастомную тему, похожую на битбакет, для gitea.

Библиотека пользовательского интерфейса, которую использует bitbucket, построена на основе React (Ref: Atlaskit ), поэтому я интегрировал React в шаблон Go с помощью некоторых «грязных» средств.

Я поддерживал преобразование строки в модуль в JS и предоставил функцию render() window . Я могу вызвать функцию в каждом шаблоне, соответствующем странице, передав уникальную строку и некоторые переменные контекста, необходимые странице в качестве аргументов. Затем функция render() определяет, какой компонент React должен быть установлен на странице, и отображает его с этими переменными в качестве свойств.

Честно говоря, текущая реализация на самом деле не соответствует философии приложений React, но она работает, и на самом деле она проще, чем «настоящий» React SPA, потому что вам не нужно заботиться о маршрутизаторах и глобальных состояниях.

@balthild Выглядит потрясающе! Значит, это, по сути, «слой перевода» поверх Gitea, который переводит шаблон Gitea в React?

@kolaente Да. Причина не только в отсутствии API, но и библиотеки интернационализации. Для github.com/Unknwon/i18n нет эквивалента JS, поэтому я должен отформатировать строки в Go.

@balthild Отличная работа, у вас есть публичное репо?

@NetOperatorWibby https://github.com/balthild/bitcup Проект находится на ранней стадии. Заменяется только страница панели инструментов, и она плохо работает на мобильных устройствах.

Это несколько не связано, но было бы здорово, если бы было место, где можно найти разные темы. Я думаю, что если просто сообщить сообществу, где найти темы, это может привести к появлению новых интересных новаторских взглядов на gitea.

Тематика в настоящее время недостаточно абстрактна. Я мог видеть, как мы переходим к собственным переменным CSS для определения цветов темы, чтобы тема состояла только из набора переменных цвета. Это также означало бы удаление поддержки IE 11.

@silverwind Я думаю, что в январе 2020 года мы можем удалить поддержку IE11, согласно https://en.wikipedia.org/wiki/Internet_Explorer_11 , когда он достигнет EOL

"Не давай мне надежды"

https://support.microsoft.com/en-us/help/17454/lifecycle-faq-internet-explorer

Internet Explorer 11 будет поддерживаться, пока Windows 10 не станет EOL

@marcstreeter Это больше не браузер по умолчанию, и он не будет получать никаких обновлений, кроме критических проблем с безопасностью.

Это довольно просто: если IE блокирует нам возможность поставки функции, его поддержка будет прекращена.

Все хорошо - просто убедитесь, что решение не было основано на ложной дате.

Следующие шаги по модернизации JS должны быть:

• Добавить Webpack - https://github.com/go-gitea/gitea/pull/8440
• Добавить минификатор - возможно, https://github.com/go-gitea/gitea/pull/8440
• Добавьте Babel, который позволяет нам писать современный JS, поддерживая старые браузеры.
• По возможности исходите JS-зависимости из npm вместо того, чтобы продавать их. Это упростит их обновление.

@silverwind Вы можете рассмотреть возможность использования современного JS в современных браузерах. Вот статья об этом: https://philipwalton.com/articles/using-native-javascript-modules-in-production-today/

@ mrg0lden Еще многое предстоит сделать, но выполнение всех этих расширенных оптимизаций может стать бременем обслуживания, особенно в отношении конфигураций веб-пакетов. Какой-то способ объединения кода внешнего интерфейса, который не требует особой настройки, с «включенными батареями» был бы идеальным.

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

@silverwind Вы когда-нибудь пробовали посылку ? Его цель состоит в том, чтобы быть именно таким, js- сборщиком с нулевой конфигурацией, он уже обрабатывает HMR .

Я работал с JS последние пару лет и более чем рад помочь в случае необходимости.

Раньше я пробовал использовать parcel, но обнаружил, что в нем немного не хватает настраиваемости и экосистемы модулей. Я думаю, что webpack по-прежнему является золотым стандартом, когда нужна гибкость, даже если синтаксис конфигурации - отстой.

На самом деле vue-service-cli значительно упрощает настройку веб-пакетов для проектов Vue.

@lafriks Я думаю, что такие инструменты SPA предполагают, что HTML обслуживается через веб-пакет, что в настоящее время не относится к нам. Возможно, мы сможем обслуживать только index.html через webpack, но это будет нелегко.

Давайте сделаем это шаг за шагом. Мы можем начать с более простой страницы.

@silverwind нет, он сгенерирует index.html, но вы можете легко передать его из golang

Да, я думаю, в конечном итоге мы могли бы попытаться переместить index.html в webpack, чтобы мы могли использовать один из существующих шаблонов конфигурации webpack. Строго говоря, это не обязательно должен быть vue, потому что в последний раз, когда я проверял, наше использование vue было очень минимальным, поэтому его можно легко преобразовать во что-то еще, если мы захотим.

Я считаю, что Gitea должна быть не SPA, а MPA.

проголосовать за MPA:

• меньше ресурсов требуется на стороне клиента

РЕДАКТИРОВАТЬ: кто-то все еще может писать SPA с html + css + js, используя конечные точки API gitea в качестве бэкэнда ...

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

Я думаю, было бы интересно, если бы Gitea приняла горизонтальную компоновку, аналогичную той, что используется в Azure Repos. Этот макет намного более элегантен и эффективен, imho, и использует экранное пространство более разумным образом. Вот несколько снимков экрана, чтобы проиллюстрировать, что я имею в виду:

как и любой другой пользовательский интерфейс, потому что он также работает на небольших устройствах, и прокрутка вниз - это нормально.
Даже GitHub начинает использовать 100% экрана, например, новые уведомления (или проверки / изменения файлов в PR)

Мне нравится современный стиль - но это только мое мнение

Мне не всегда нравится вид в разделе «Измененные файлы». Время от времени у меня возникают запросы на вытягивание, в которых было изменено 20 и более файлов, чего не всегда можно избежать (Миграция PHP 5.6 -> 7.3).

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

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

Я говорю о представлении запроса на перенос, как в этом стиле: https://github.com/go-gitea/gitea/issues/5937#issuecomment -584859265