id be quite happy to jump on that. my "biggest win" with marble was to use it on subsurface but we had to do a soft fork because of how hard it was to compile just the library part for our usecase. in the end it was dropped in favor of qt maps.
On Tue, 17 Sep 2024 at 19:47 Ben Cooksley <bcooks...@kde.org> wrote: > On Tue, Sep 17, 2024 at 8:06 AM Johannes Zarl-Zierl < > johan...@zarl-zierl.at> wrote: > >> Am Montag, 16. September 2024, 19:39:21 CEST schrieb Albert Astals Cid: >> > El dilluns, 16 de setembre del 2024, a les 17:40:04 (CEST), Volker >> Krause va >> > escriure: >> > > Marble however still only requires Qt 5.14 and only has an optional >> > > dependency on ECM, which means our established porting practices don't >> > > work >> > > there. Being able to change that would help significantly. >> > >> > The people that were against using our established practices don't seem >> to >> > be around to be able to disagree to that change ;) >> >> +1 >> >> If marble gets some form of community maintenance, reducing the mental >> load of >> doing so has to take priority over keeping compatibility for every >> use-case >> there ever was... >> > > Yes please. The unusualness of Marble's setup has necessitated specific CI > features so it would be good to make it more standard as that will support > removing that special logic. > > >> >> Cheers, >> Johannes >> >> > Thanks, > Ben >
