Gitea: UIアップデートのディスカッション

Giteaはモバイルデバイスではあまり使用できないため、これが発生することを望んでいますが、これは大規模な作業であり、すべての開発者がGiteaの通常の機能を維持および作業することを妨げないことを願っています。 ：スマイリー：

今はCSSだけに焦点を当てていますが、私には2つの主要な懸念があります。

1. semantic-uiは、テクノロジー的には行き止まりです。 それはフレックスボックスを包含しておらず、私は一般的にそれ自体で多くのことをしていると思います。 ヘルパークラスを追加するだけで、もう少し制御できるようにしたいと思います。

2. lessはおそらく必要ありません。 セレクターのネストは、ソースで検索するのが難しい、無駄に長いセレクターにつながるため、悪いことだと思います。 CSSが変数をサポートしているので、プリプロセッサを使用することはあまり役に立ちません。 プレーンCSSに変換することをお勧めします。

ネイティブのcss変数を優先してドロップすることは、一部のブラウザーのサポートをドロップすることを意味しますが、Giteaを使用するほとんどの人はとにかく最新のブラウザーを使用している開発者であるため、それで問題ないと思います。
私にとってのより大きな問題は、 darken($color)ようなものを使用できず、cssを複数のファイルに分割して1つの単一のcssに結合できることです（ネイティブcssでもそれができることはわかっています。 .. すこし）

新しいデザインは、GiteaがGogsとは大きく異なることをより明確にするのにも役立つ可能性があります。これは、現時点では、両方がほぼ同じUIを共有しているためです。

Framkeworkに関しては、bulma.ioをミックスに入れます。これは、過去に使用したものであり、かなり良いと感じたからです。 高いcustimizationを可能にし、したがって簡単なテーマ設定を可能にしながら、ほとんどのことから面倒を取り除きます。

Giteaに独自のUIを与えることは、GiteaとGogsの違いを示すのに確かに役立つと思います。同時に、lessまたはscssは、おそらくこのプロジェクトに存在し続けるべきものであると言わざるを得ません。機能はCSSでは利用できません。フレームワークに関しては、私は個人的にプロジェクトにBootstrap 4を使用しているだけなので、この議論に役立つ意見はありません（ここで使用する必要はありません）。

ブルマは私にはいいですね:)それは悲しいことに完全なUIの書き直しを意味すると思いました

私は間違いなくプレーンCSSを支持し、フレームワークよりもFlexboxやGridなどの標準を使用しています。 グリッドは、非グリッドフレームワークでは提供できない多くの機能を提供します。

@andrewbanchichBulmaは

はい。ただし、グリッドに基づいていない場合でも、意図されていない方法で何かを使用しているフレームワークです。 まず、グリッドフレームワークはレイアウトにフロートを使用していました。これは、フロートがどのような種類のレイアウトにも対応していないため、回避策でした。 現在、彼らは完全な2DレイアウトにFlexboxを使用していますが、Flexboxは1Dレイアウトのみを対象としています。 グリッドは2Dレイアウト用であり、Flexboxでは不可能なことを簡単に実行できるため、標準のCSSグリッドを使用する必要があると思います。 私の意見では、グリッドフレームワークはもう必要ありません。

Bulmaは非常に軽量で、箱から出してすぐに見栄えのするスタイルを提供します。ここでgiteaの見栄えの良いデザインを行うことができるデザイナーはいないと思います。

@ lafriks @ kolaenteのデザインが本当に気に入りました。

私にとってのより大きな問題は、 darken($color)ようなものを使用できないことです

同意します、私は確かにそれらも必要であり、このような色調整のためのクリーンなCSSソリューションはありません。 私は個人的にLESSよりSCSSを好みますが、軽い使用法では、両方ともほぼ同じである必要があります。

しかし、それがグリッドに基づいていない場合でも、それは意図されていない方法で何かを使用しているフレームワークです

グリッドは確かにオプションですが、それに基づいた適切なフレームワークはありますか？

これが私が遊んだドラフトです:(ブルマで書かれました）

あまり満足していません。

@kolaenteどこか別のgitリポジトリで共有できますか？ 私もブルマで遊んでいるので、一緒にこれに取り組むのがいいでしょう

@lafriksもちろん： https ： //kolaente.dev/konrad/gitea-design

@kolaenteによって作成されたデザインは、

時々私は私の電話を介して問題を追加します。 はい、UIを使用できます。 ただし、他のサービスの中には、応答性の高いUIを備えているものもあります。 残念ながら、私はCSSがあまり得意ではありません。

たぶん、Twitter Bootstrapを使用してレスポンシブにすることができ（たとえば、グリッドのみを選択できます）、ボタンなどの他のコンポーネントにはカスタムレイアウトがあります。

@mbeddedは、レスポンシブCSSフレームワークでもある@jgthmsのBulmaを使用します。

これが私が遊んだドラフトです:(ブルマで書かれました）

私はGitLabよりもGitHub（真ん中のすべて）のデザインが好きです。 気が散ることは少ないと思います。

私はここで新しいです-それは問題＃6687を開くことから始まり、より少ないコードを見て、sassの解決策について尋ねました。 その後、 @ techknowlogickは私にこの問題を指摘しました。

GitHub
私はGitHubのデザインが好きですが、最近多くの新機能が追加されて混雑しています。 ドロップダウンのステータス設定、サイドバーの新しい実験機能。 ->多くの異なるメニュータイプ。 ほとんどのものは、新しいチェック機能のようなサイドメニューに移動します（デザインの幅も崩れます）。 GithubにはすべてをWebサイトに収めるのに問題があるようです。

GitLab / Bitbucket
GitLabだけがサイドバーを使用しているわけではありません。 多くのサービスは、見つけて拡張するのが簡単なため、サイドバーに切り替えました。 同じ要素のすべてのエントリとサブエントリ。 最大5kのディスプレイ（少し失われます）のモバイルで動作し、メインコンテンツの外部に簡単に統合できます。 ヘッダー領域は、この現在のページトピックの情報で始まります。
新しい機能を追加したり、プラグインシステムを提供したりする場合は、新しい（サブ）メニューエントリを追加するのに十分なスペースがあります。

Css / vs. sass
コンパイラを使用してください:)ブラウザごとにさまざまなCssを使用し、自動プレフィックス機能などのツールを使用すると、ブラウザごとに複数の行を書き込んで後で削除することなく、多くの小さな問題を修正できます。 また、色変数のネストなどの機能や、暗い/明るい、rgba（$ color、.8）などの関数もあります。 リンターを使用すると、最大ネスト深度の変数として色のみを使用するように強制できます。 新しいテーマの変数の調整は本当に簡単です。

Bulmaテーマ
標準のブートストラップ、マテリアルデザイン、または（zurb-）ファウンデーションではなく、見栄えが良い（単一のメンテナ/組織アカウントなし）。 必要なコンポーネントのみをインポートします。 Bulmasass構文は一般的ではありません。 ブートストラップと比較して、より多くのサイズがハードコーディングされています。

どちらの方法でもgiteaを使用しますが、ダークテーマを改善し（スタイラスパッチなし）、変数なしで何かを調整してすべてのページを取得するための作業を増やしたいと思います。 多分私はスタイルのもので少し助けることができます、それは望まれています。

サイドバーまたはその他の主要な再設計のトピックについて：多くのユーザーにとっての主な魅力は、GiteaのUIがGitHubに非常に似ていることだと思います。 サイドバーの追加など、レイアウトの基本を変更すると、現在のレイアウトとGitHubに対応しているユーザーにとって非常に混乱を招きます。 私はそれを受け入れるかどうかわかりません。

@silverwindが言ったように：UIがほぼ同じに見えるので、Githubに精通している場合、ユーザーがGiteaを切り替えたり使用したりするのは非常に簡単だと思います。
一方（@ xf-が言ったように）：メニューを左側に置くと、設定やメニュー項目をグループ化するのが簡単になります。 さらに、ほとんどの画面は幅の広いものです。 したがって、左側のメニューはこれらのアイテムへの永続的なアクセスを提供し、コンテンツを混乱させることはありません。 アイテムが3〜4個しかない場合は、「メニューを配置する場所」というトピックについては後で説明する必要があります。

たぶん、現在のテーマの一貫性を高めるために変数とミックスインを使用することから始めます。

例えば。 高さ36pxのサイドバーハットのプライベートリポジトリと35pxのパブリックリポジトリまたは組織。 また、組織は左側へのマージンが少なくなっています。 また、両方のコンテナの幅が異なります。 プロファイルでは、組織の2番目の行にマージンtの最初の行がありません。

メニューについて：ほとんどのナビゲーションはOKで直感的ですが、settings / adminの上部にあるメニューは本当に奇妙です。 私はリストのメニューが好きです。 必要なエントリを見つけるのがはるかに簡単/高速です。

また、font-faceは完全に混乱しています。 Latoはsematic-ui.cssとindex.cssで定義されています。 :langスイッチという意味ではありません。 私は能登フォントを使用します-ほぼすべての言語が利用可能で、等幅フォントと絵文字もあります。 （多分少しオフトピック）
https://en.wikipedia.org/wiki/Noto_fonts
https://www.google.com/get/noto/

それは本当だ。 私の経験から（私はデザイナーというよりプログラマーなので、ちょっとしたWebデザインをしているだけです）：SASSやLESSのようなツールはCSSの使用をとても簡単にしています。 のように変数コードを使用および更新する可能性は素晴らしいです。

ほとんどのIDEには、デフォルトでSALL / LESSコンパイラが含まれているか、ソースコードファイルの保存時にcssファイルを更新するプラグインとして追加できます。 確かに、フォントはここではトピックから外れている可能性があります。 しかし、それはへの最初の投稿の一部です

Gitea UIの将来について話し合うために、このチケットを開きます

たぶん私はいくつかのファイルを整理したり、いくつかの部分をSASSに変換したりするのを少し手伝うことができます。 私の観点から（意見は異なる場合があります）、更新する必要がある2つの重要なことがあります。

• 携帯電話でgiteaを使用する場合のレスポンシブレイアウト（たとえば、通常のデバイスを使用できないときに問題を追加する場合）
• 多くの設定があるため、管理者設定（または個人設定も）の表示を改善します。 垂直メニューは水平メニューよりも優れている場合があります。 計画または希望する機能に応じて、一部が追加される場合があります。

例：Githubでは（GiteaがGithubに似たデザインを好む場合）、「通常の」アイテムはコード、問題、wiki、マイルストーンに対して水平になります。

リポジトリ、組織、または個人アカウントの他の設定が垂直方向に一覧表示されます。 私の観点からは、これは優れた設計上の決定です。 Giteaにはまだそれほど多くの設定はありません。 しかし、githubと比較すると（giteaが大きくなる場合）、水平方向のスペースが十分でないか、16：10画面またはテレビ画面に切り替える必要があります:)

次のスクリーンショットでわかるように：

Github設定、個人アカウント：

Gitea設定、システム管理：

どう思いますか？

それを処理するために、メニューの項目を常に少なくする必要があると思います。 少ないほうがいいですね。 :)

カスタムフロントエンドの開発を非常に簡単にするものは、Giteaサーバー用のAPIを作成する（簡単ではない）タスクです。 そうすれば、フロントエンドは、Mithril、React、vanilla JSなど、人々が快適に使用できるフレームワークで記述できます。

@NetOperatorWibby GiteaにはAPIがありますが、現時点では機能が完全ではありませんください。

私はgitea用のビットバケットのようなカスタムテーマを開発しています。

bitbucketが使用したUIライブラリはReactの上に構築されているため（参照： Atlaskit ）、ReactをGoテンプレートに「ダーティ」な手段で統合しました。

JSで文字列からモジュールへのマッピングを維持し、 render()関数をwindow公開しました。 ページに対応するすべてのテンプレートで関数を呼び出し、ページに必要な一意の文字列といくつかのコンテキスト変数を引数として渡すことができます。 次に、 render()関数は、どのReactコンポーネントをページにマウントする必要があるかを見つけ、それらの変数を小道具として使用してレンダリングします。

正直なところ、現在の実装はReactアプリの哲学を実際には満たしていませんが、実際には機能します。実際、ルーターやグローバルな状態を気にする必要がないため、「実際の」ReactSPAよりもシンプルです。

@balthildすごいですね！ つまり、これは本質的に、GiteaテンプレートをReactに変換するGiteaの上に配置された「変換レイヤー」ですか？

@kolaenteはい。 その理由は、APIの欠如だけでなく、国際化ライブラリーにもあります。 github.com/Unknwon/i18nにはJSと同等のものがないため、Goで文字列をフォーマットする必要があります。

@balthildすばらしい仕事です、あなたはそれのための公開リポジトリを持っていますか？

@NetOperatorWibbyhttps ：//github.com/balthild/bitcupプロジェクトは初期段階にあります。 ダッシュボードページのみが置き換えられ、モバイルデバイスでのエクスペリエンスが低下します。

これはやや無関係ですが、別のテーマを見つける場所があればクールでしょう。 テーマを見つける場所をコミュニティに知らせるだけで、giteaのクールで新しい革新的な外観につながる可能性があると思います。

テーマは現在、十分に抽象化されていません。 テーマの色を定義するためにネイティブCSS変数に移行しているので、テーマは色変数のセットのみで構成されていることがわかりました。 これは、IE11のサポートを削除することも意味します。

@silverwind 2020年1月、EOLに到達するhttps://en.wikipedia.org/wiki/Internet_Explorer_11に従って、IE11サポートを削除できると思います。

「私に希望を与えないでください」

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

Internet Explorer 11は、Windows10がEOLになるまでサポートされます。

@marcstreeterこれはデフォルトのブラウザではなくなり、重大なセキュリティ問題以外の更新を受信しなくなります。

非常に簡単です。IEが機能の出荷をブロックしている場合、そのサポートは終了します。

すべて良い-決定が誤った日付に基づいていないことを確認するだけです。

JSモダナイゼーションの次のステップは次のとおりです。

• Webpackを追加-https ：//github.com/go-gitea/gitea/pull/8440
• ミニファイアを追加-おそらくhttps://github.com/go-gitea/gitea/pull/8440
• 古いブラウザをサポートしながら最新のJSを作成できるBabelを追加します。
• 可能な場合は、ベンダーではなく、npmからJSの依存関係を取得します。 これにより、更新が簡単になります。

@silverwind最新のブラウザで最新のJSを使用することを検討することをお勧めします。 これに関する記事は次のとおりです： https ：

@ mrg0ldenやるべきことはたくさんありますが、これらすべての高度な最適化を行うことは、特にwebpack構成に関して、メンテナンスの負担になる可能性があります。 多くの設定を必要としないフロントエンドコードをバンドルするある種の「バッテリーを含む」方法が理想的です。

これを行うことになった場合は、ストックウィジェットに適切なアクセシビリティを備えたツールキットを使用してください。また、アクセス可能にする場合を除いて、カスタムウィジェットを作成しないでください。

@silverwind小包を試す機会があったことはありますか？ 目的は、ゼロ構成のjsバンドラーであり、すでにミニファイを処理し、 HMRを備えた

私は過去数年間JSと協力してきましたが、必要に応じて喜んでお手伝いします。

私は過去に小包を試しましたが、構成可能性とモジュールエコシステムの点で少し不足していることがわかりました。 構成構文が悪いとはいえ、柔軟性が必要な場合でも、webpackは依然として黄金の標準だと思います。

実際、vue-service-cliを使用すると、VueプロジェクトのWebpack構成がはるかに簡単になります。

@lafriksこのようなSPAツールは、HTMLがwebpackを介して提供されることを前提としていると思いますが、現在はそうではありません。 webpack経由でindex.htmlだけを提供できるかもしれませんが、それは簡単ではありません。

ステップバイステップでやってみましょう。 より単純なページから始めることができます。

@silverwindいいえ、index.htmlを生成しますが、golangから簡単に提供できます

ええ、最終的にはindex.htmlをwebpackに移動して、既存のwebpack構成テンプレートの1つを使用できるようになると思います。 厳密に言えば、vueである必要はありません。最後に、vueの使用量が非常に少ないことを確認したので、必要に応じて他の何かに簡単に変換できます。

GiteaはSPAではなくMPAであるべきだと思います。

MPAに投票する：

• クライアント側で必要なリソースが少ない

編集：誰かがバックエンドとしてgitea APIエンドポイントを使用することにより、html + css + jsでSPAを作成できます...

ええ、私たちはすでにサーバーサイドレンダリングに多額の投資をしているので、SPAとの完全な会話はほぼ間違いなく問題外だと思います。

Azure Reposが使用しているのと同様に、Giteaが水平レイアウトを採用した場合は興味深いと思います。 このレイアウトは、はるかにエレガントで効率的なimhoであり、よりインテリジェントな方法で画面領域を使用します。 これが私が何を意味するかを説明するためのいくつかのスクリーンショットです：

他のすべてのUIと同様に、小型のデバイスでも機能し、下にスクロールしても問題ないためです。
GitHubでさえ、画面の100％を使用し始めます。たとえば、新しい通知（またはPRでのチェック/ファイルの変更）

私は現在の踏み越し段が好きです-しかしこれは私の意見です

「変更されたファイル」の下のビューがいつも好きというわけではありません。 時々、20個以上のファイルが変更されたプルリクエストがありますが、これは常に回避できるとは限りません（Migration PHP 5.6-> 7.3）。

問題は、ブラウザが変更を表示するのに多くの時間を必要とすることです。 プルリクエストページの読み込みが速くなります。 構文の強調表示だけが多くの時間を消費します。

ここでは、Gitlabに似たビューをお勧めします。

私はこのスタイルのようなプルリクエストビューについて話している： https ：