Closed infeeeee closed 1 year ago
Yes, I think this is a cleaner solution, since I tried to think when to use other dependencies but nothing came to my mind. I think it's safer to accept this after these PR first (#37 #27 #28) to avoid possible conflicts.
I just wanted to ask if I should continue working on this :) Maybe I will have some time continue contributing
Yes sure, solving a conflict on your repo made this branch merge but I rollbacked it :(
The fact is: I want to use your solution and making some changes but if I edit the entities then we will have a lot of conflicts. So I wanted to integrate your branch with the new version to work on your branch on the new version but I don't to how to to this.
You can add my fork as another remote, than you can just cherrypick and use them as yours.
I use it this way: In vscode I installed the Git Graph
addon, then on the Git menu -> remotes, +:
Then on the Git Graph view, you can just rightclick any commit on any branches, and merge it to your working branch.
Good point, thank you
I think the dependency system currently doesn't make a lot of sense, as all 'base' entities (
de
andos
)are just providing static values. Simply using a module to collect those values makes maintaining the project much easier.I didn't touch the current dependency system, I just modified the entities. But this fork is working, except for the
Notify
entity. (I didn't modify that because of #28 )If this is accepted, the dependency related functions can be removed from
EntityManager
and from the configurator.If this is accepted, the
SystemConsts
module can be merged with theMyApp
module, making maintaining even more easier.Related to #30
What do you think @richibrics ? Should I continue working on this, or the dependency chain management is the way to go?
I've already written some code about better de detection on linux, but I want this to be settled first: https://github.com/richibrics/IoTuring/compare/main...infeeeee:IoTuring:desktop-environment