Kotlin

[hannesa2]

@shmueldabomb441 I prefer Kotlin on many reasons and I see no point to stay with Java. But the consequence is an execution of a hard fork. It means a rebase to upstream makes no sense anymore.

contra hard fork: We'll loose improvements from upstream. The maintainer there drives the complete story and is high motivated to push it forward.

pro hard fork: The upstream is technological very outdated and in the style of ~2015 and additional I've doubt that upstream maintainer will jump to a modern technology. The upstream is his baby and I see he protect it from "external influences". This is the end of innovation. The few pull requests I've seen where closed or just discussed. At least no one were merged. As a contributor it's frustrating when your work will not merged

[Sternbach-Software]

Yes, very strongly agree on the frustration.

If you notice, the name of my fork is GeniForAndroid, because my plan is to publish the as of yet only available Android client for the extremely popular Geni.com, based on FamilyGem. I have been very unsure and debating for days whether to base it off of FamilyGem or start from scratch.

Pros for basing it on FamilyGem:

• only open source family tree Android app
• already implements family tree logic, including edge cases - so I can get a product to the masses sooner
• implements GEDCOM logic
• is functional
• has some nice features (not all working 100%, like PDF export, but still nice)
• tested with time by 50K+ users and liked by many (400 reviews on Google Play, 3.9 stars)
• best implementation of family tree view (only other options I was able to find after extensive looking: GraphView and it's derivative TreeView, both nice but significantly lacking the fine control that this app needs - e.g. defining individual Paint between two specific nodes)

Contra to basing it on FamilyGem:

• flat out horrible and inefficient code (conventions and algorithms, e.g: string concatenation in loop, using Object and casting way too often, calling hidden methods using reflection, creating UIs in Java using his place(Object)etc., #67)
• doesn't work well with large trees (not sure exactly why yet, #66)
• doesn't use Kotlin (porting to iOS using kmm would require that)
• a few more I can't think of now because it is 2 AM.
• not flawless (only 3.9 stars) - so will it be better than the responsive web app and be worth the transition for users? The last point is important, because the whole thing would be a waste if it weren't better than what is currently available. I personally think that for the regular and simple use case, it is a better experience - but that is just me, and that doesn't include the potential unpredictable bugs that can come up from his horrible code.

Would you be interested in writing something from the ground up together with me? I would probably at least look at the way FamilyGem was structured (I am doing that now as I translate), and how it performed certain operations (e.g. tree diff) to know what the edge cases to plan for are. I may even use some components (like the tree view).

[hannesa2]

A lot of "Pros for basing it on FamilyGem:" are given and were not lost when we take over. The only question is about future.

I see your visions and I like it. To be honest, I would make the move to a more own-build future. First move to Kotlin by stupid conversion, and then tests (!), improve bottlenecks, a new styling, publish, features ...

I can imagine to help/contribute/improve, but I can't promise how much. I only can guaranty fast response, approve and merge.

[Sternbach-Software]

By styling do you mean UI design?

[hannesa2]

By styling do you mean UI design?

Yes, but maybe just the main colors

[Sternbach-Software]

So are you for or against a hard fork? If for it, would you be interested in me writing the UI in Compose? I think this is a good excuse to learn it.

[hannesa2]

I'm pro hard fork, but not alone.

But with the Compose I've the fear to spend too much time with it. I know, it has the smell of future ... The thing is, when you want too much, you maybe get nothing ...

[hannesa2]

@shmueldabomb441 I see you are against a hard fork as you invest time in class translation

[Sternbach-Software]

I may have misunderstood you. I understood that you were supportive of refactoring to the point that new upstream commits cannot be merged into downstream.

I thought the best way to approach the refactor was with an incremental approach (as is suggested in The art of refactoring, improving the design of existing Software), changing class by class. In order to make that easier, it would be better if everything was in English. Both in terms of the rewrite, and in terms of maintaining code that lasts through the refactor untouched.

[hannesa2]

Sure increment is the way to go ! I see, you still hope to get merged a huge PR, even the maintainer complains to be too big, and you add more and more changes. -brave-

You know the evolution of brave ?

1. knowledge
2. trust
3. hope
4. brave
5. stubborn
6. hopeless
7. stupid

I hope you don't reach all words ! I reached hopeless already

[Sternbach-Software]

Are you referring to the fact that I didn't close the PR? I have no intention of him accepting the pull request; it just isn't worth my time to close it.

[hannesa2]

Yes. As long as it's open, I've the suspect, that there could appear more commits. Currently I only observe the situation.

[hannesa2]

I offered a new organization with shared power and you accepted it. But you continued in your own new named user Sternbach-Software. That's complete fine and probably the best decision for you !

But to be realistic, that's why I see not a real interest from your side to do something combined. I think you decided to go your own ways 👍 As a follow up, I'll kick you as onlooker out of my organization. If you (against my expectation) don't agree to it, let me know

[Sternbach-Software]

No, I disagree! I simply completely forgot about this organization! And I continued with the status quo, for no particular reason other than that is what it was before. How should I proceed?

[Sternbach-Software]

It is counterintuitive that you forked this repo from upstream instead of from my fork, even after I pushed commits to mine. And why did you want to create a separate organization? Given that you said that you can't necessarily contribute so much, I think it makes sense for me to commit to my fork, pull request into your fork, and then do as you said, "...response, approve and merge."