!eSTlitQAfqxWWEHMFD:matrix.org

SchildiChat Web/Desktop

715 Members
Discussion about SchildiChat Web/Desktop | FAQ: https://schildi.chat/desktop/faq/ | Bugs: https://github.com/SchildiChat/schildichat-desktop/issues | Translations: https://translate.schildi.chat/projects/schildichat/209 Servers

Load older messages


SenderMessageTime
3 Mar 2024
@suguru:progressiv.devsuguru
In reply to @qg:supercable.onl
I hadn't time to go through them yet, maybe I'll have some later today.
No hurries, please take your time.
10:36:29
@suguru:progressiv.devsugurubecause this would make it possible for us to create a CSS file which only defines mixin to be used somewhere, import the file where we want to use the mixin, minimizing the impact of cascading. With help of CSS scope, we would be able to control the impact of cascading as much as possible.10:42:03
@suguru:progressiv.devsuguru* because this would make it possible for us to create a CSS file which only defines mixin to be used somewhere, import the file to another file where we want to use the mixin, minimizing the impact of cascading. With help of CSS scope, we would be able to control the impact of cascading as much as possible.10:54:37
@suguru:progressiv.devsuguru* because this would make it possible for us to create a CSS file which only defines mixin to be used somewhere, import the file on another file where we want to use the mixin, minimizing the impact of cascading. With help of CSS scope, we would be able to control the impact of cascading as much as possible.10:54:57
@luigimi:matrix.orgluigi joined the room.11:00:03
@luigimi:matrix.orgluigiHelp, Schildi for Mac? link for old and ignorantšŸ™ƒšŸ„°šŸ˜€11:03:07
@suguru:progressiv.devsuguru
In reply to @qg:supercable.onl
Apart from that, there can be as many feature/fix branches as necessary.

So if I understand correctly, branches, rather than actual folders, will be expected to work as placeholder for files which will have been changed?

Branches would share the same files with the same single folders tree, however it would be named named (something like /feature-improvement ?), and these files would be changed by commits, which means that each of them would include changes by those various commits. -- Do I understand correctly?

11:13:41
@suguru:progressiv.devsuguru
In reply to @luigimi:matrix.org
Help, Schildi for Mac? link for old and ignorantšŸ™ƒšŸ„°šŸ˜€
I guess you would like to have a look at https://matrix.to/#/!eSTlitQAfqxWWEHMFD:matrix.org/$wHXfAn18NYtru5-P3irGZP0JjsOADoJ-kvw5Ib5YcjU?via=progressiv.dev&via=matrix.org&via=nomadserver.us
11:14:54
@suguru:progressiv.devsuguru
In reply to @suguru:progressiv.dev
I guess you would like to have a look at https://matrix.to/#/!eSTlitQAfqxWWEHMFD:matrix.org/$wHXfAn18NYtru5-P3irGZP0JjsOADoJ-kvw5Ib5YcjU?via=progressiv.dev&via=matrix.org&via=nomadserver.us
It seems difficult to provide a newer build for macOS.
11:21:57
@suguru:progressiv.devsuguru* So if I understand correctly, branches, rather than actual folders, will be expected to work as placeholder for files which will have been changed? Branches would share the same files with the same single folders tree, however it would be named (something like /feature-improvement ?), and these files would be changed by commits, which means that each of them would include changes by those various commits. -- Do I understand correctly? 11:22:25
@suguru:progressiv.devsuguru* So if I understand correctly, branches, rather than actual folders, will be expected to work as placeholder for files which will have been changed? Branches would share the same files with the same single folders tree, however it would be named (something like /feature-improvement ?), and these files would be changed by commits, which means that each file would include changes by those various commits. -- Do I understand correctly?11:22:56
@hallooooo:matrix.org@hallooooo:matrix.org joined the room.11:26:00
@hallooooo:matrix.org@hallooooo:matrix.org left the room.11:52:40
@qg:supercable.onlqg
In reply to @suguru:progressiv.dev

So if I understand correctly, branches, rather than actual folders, will be expected to work as placeholder for files which will have been changed?

Branches would share the same files with the same single folders tree, however it would be named (something like /feature-improvement ?), and these files would be changed by commits, which means that each file would include changes by those various commits. -- Do I understand correctly?

If there is a branch irc-layout-improvements, all it's css related changes should go into _schildichat/irc-layout-improvements, if there is a branch schildi-bubble-layout, all its css related changes should go into _schildichat/schildi-bubble-layout.

12:58:58
@qg:supercable.onlqg
In reply to @suguru:progressiv.dev

So if I understand correctly, branches, rather than actual folders, will be expected to work as placeholder for files which will have been changed?

Branches would share the same files with the same single folders tree, however it would be named (something like /feature-improvement ?), and these files would be changed by commits, which means that each file would include changes by those various commits. -- Do I understand correctly?

*

If there is a branch irc-layout-improvements, all its css related changes should go into _schildichat/irc-layout-improvements, if there is a branch schildi-bubble-layout, all its css related changes should go into _schildichat/schildi-bubble-layout.

12:59:11
@suguru:progressiv.devsuguruAh I understood, though I cannot really imagine how the actual process it will be yet ...13:34:35
@qg:supercable.onlqg

The process now will basically be the following:

  1. Reset the matrix-react-sdkĀ repo to Element
  2. Merge until latest Element (the other repos are usually no big issue)
  3. Establish a sc-base branch for matrix-react-sdk
  4. Create/rebase/fix/port from old/... sc-{room-list-improvements,schildi-bubble-layout, irc-layout-improvements,...} feature branches for matrix-react-sdk based on the sc-base branch
  5. Create an sc-<upstream-version> branchĀ for matrix-react-sdk
  6. Merge the feature branches into that
  7. Once Element releases a new version, merge as usual (into the sc-base branch for matrix-react-sdk)
  8. Continue with 4.
13:55:41
@suguru:progressiv.devsuguru
In reply to @qg:supercable.onl

The process now will basically be the following:

  1. Reset the matrix-react-sdkĀ repo to Element
  2. Merge until latest Element (the other repos are usually no big issue)
  3. Establish a sc-base branch for matrix-react-sdk
  4. Create/rebase/fix/port from old/... sc-{room-list-improvements,schildi-bubble-layout, irc-layout-improvements,...} feature branches for matrix-react-sdk based on the sc-base branch
  5. Create an sc-<upstream-version> branchĀ for matrix-react-sdk
  6. Merge the feature branches into that
  7. Once Element releases a new version, merge as usual (into the sc-base branch for matrix-react-sdk)
  8. Continue with 4.
OK, so sc-base include only commits by Element, correct?
14:13:01
@suguru:progressiv.devsuguru* OK, so `sc-base` includes only commits by Element, correct?14:13:42
@suguru:progressiv.devsuguru* OK, so sc-base includes only commits by Element, correct?14:13:55
@suguru:progressiv.devsuguru* OK, so `sc-base` base includes only commits by Element, correct?14:14:13
@suguru:progressiv.devsuguru* OK, so `sc-base` branch includes only commits by Element, correct?14:14:32
@qg:supercable.onlqgNo, it might contain anything that's useful (e.g. scripts) or doesn't conflict easily with stuff from Element.14:25:46
@qg:supercable.onlqg
In reply to @qg:supercable.onl

Wer need to prevent conflicts inside _customization.pcss when merging multiple feature branches, thus, something like this needs to go in the base for itĀ probably:

/* start feature-irc-layout-improvementsĀ */
/* end feature-irc-layout-improvementsĀ */

The feature-irc-layout-improvements branch can then place its imports in between those two comments.

We also need to namespace the single features if we stick toĀ replicating the file structure from Element (not sure if it's more clean or if it gets a pain in the ass if there are many single line changes in multiple files for a specific feature), multiple feature branches might operate on the same files from Element (when namespaced, at least every feature branch can decide for itself how to name its files).

So for example, the feature-irc-layout-improvements branch should apply the following to _customization.pcss:

/* start feature-irc-layout-improvementsĀ */
@import "./feature-irc-layout-improvements/views/rooms/_EventTile.pcss";
@import "./feature-irc-layout-improvements/views/rooms/_IRCLayout.pcss";
/* end feature-irc-layout-improvementsĀ */
Basically like described here. ^^
14:26:33
@suguru:progressiv.devsuguru
In reply to @qg:supercable.onl
No, it might contain anything that's useful (e.g. scripts) or doesn't conflict easily with stuff from Element.
Ah yes, right I rememberšŸ˜„
14:28:52
* @negidery:matrix.orgsuguru * already feels like the updated IRC UI based on the PR is better and much less distracting 14:54:36
@slyneko:matrix.orgslyneko joined the room.16:32:23
4 Mar 2024
@suguru:progressiv.devsuguru
In reply to @qg:supercable.onl

The process now will basically be the following:

  1. Reset the matrix-react-sdkĀ repo to Element
  2. Merge until latest Element (the other repos are usually no big issue)
  3. Establish a sc-base branch for matrix-react-sdk
  4. Create/rebase/fix/port from old/... sc-{room-list-improvements,schildi-bubble-layout, irc-layout-improvements,...} feature branches for matrix-react-sdk based on the sc-base branch
  5. Create an sc-<upstream-version> branchĀ for matrix-react-sdk
  6. Merge the feature branches into that
  7. Once Element releases a new version, merge as usual (into the sc-base branch for matrix-react-sdk)
  8. Continue with 4.
One of the burdens would be how to handle localization files; Element switched from Weblate to another service which is proprietary if I remember correctly. Wondering if those files are compatible with Weblate.
01:23:25
@suguru:progressiv.devsuguru
In reply to @qg:supercable.onl

The process now will basically be the following:

  1. Reset the matrix-react-sdkĀ repo to Element
  2. Merge until latest Element (the other repos are usually no big issue)
  3. Establish a sc-base branch for matrix-react-sdk
  4. Create/rebase/fix/port from old/... sc-{room-list-improvements,schildi-bubble-layout, irc-layout-improvements,...} feature branches for matrix-react-sdk based on the sc-base branch
  5. Create an sc-<upstream-version> branchĀ for matrix-react-sdk
  6. Merge the feature branches into that
  7. Once Element releases a new version, merge as usual (into the sc-base branch for matrix-react-sdk)
  8. Continue with 4.
* One of the burdens would be how to handle localization files; Element has switched from Weblate to another service which is proprietary if I remember correctly. Wondering if those files are compatible with Weblate.
01:27:48
@cadence:cadence.moecadence [they]

qg: I'm not sure if I get it or not, so I'd like you to imagine this scenario:

  1. Each feature branch holds one feature
  2. (Your step 5) We branch off an Element version
  3. The feature branches are merged with the release branch to make a SchildiChat version
  4. Later on, Element does some refactoring, which means a certain feature doesn't merge cleanly any more. (Let's say maybe part of our feature has to be rewritten.)

How would somebody fix the broken feature? How does the branching work for just that one feature?

03:13:46

There are no newer messages yet.


Back to Room ListRoom Version: 6