WebUI?

[sdenike]

First off, I want to say THANK YOU for creating this. I was working on some horrible code to do exactly what you have done, so again, thanks for doing this, so my code did not need to see the light of day.

I was curious whether you have plans to create a WebUI to manage the calendar links/files from, so you do not need to edit the config file by hand? Probably not needed, but would be a nice feature to have in the future.

[Jojodicus]

Glad I could help someone out.

Adding a web UI is a very good idea, hasn't crossed my mind so far. I still stand by that the core tool should be as minimal as possible, so I would only consider the GUI manager to be its own microservice with its own endpoint.

Reasoning:

• Easy to disable - someone doing just fine with the bare YAML shouldn't need to have a bloated frontend in there
• Make decoupling easier - throw the UI behind a reverse proxy with authentication, while the core tool can remain public
• Flexibility - the UI can be build with any stack/framework, without affecting the core

Other things that come to mind:

• Should we implement its own authentication system, or delegate to external providers like Authentik/Pangolin/...?
• Can we integrate with Google Calendar OAuth to fetch private iCal links directly?
• Should we add Apple Calendar support via their API/CalDAV, or is the current iCal URL approach sufficient?
• Simple text-based form that abstracts the YAML structure, or visual node-based editor?
• If using nodes for calendars, how to handle renaming, public/private toggling (note: renamed internal calendars are unsupported as of version 1.6.1) and clutter reduction
• Ensure the UI works well on mobile devices for quick calendar management
• Should the UI show more than just a config editor, like "last merge timestamp" or optional statistics?

Refactoring into multiple microservices and building + documenting the new UI is quite a lot of work for (in my opinion) not enough benefit.

I've left the comments here so maybe I (probably not in the near future though) or someone else (contributions are always welcome!) can implement it. Should also help with guiding an AI agent if using one to help build this.

[sdenike]

I am all for keeping the main application as minimal as possible and even if no WebUI gets added this all works perfectly fine in my book. I was thinking it would be a nice feature to have at somepoint so that the less tech savvy family members could get in and add/remove/create/delete calendars with out having to have another person edit the config file.

My opinion on the other things you mentioned, I have really enjoyed using PocketID with a lot of the other applications I have setup on my homelab, so that would get my vote and it "should" keep a webui minimal since you wont have to include an entire authentication setup, but of course relaying on 3rd party setups means it could break and also not everyone uses an Authentic/Pangolin/PocketID setup so it would complicate peoples installs if it was 3rd party...

Overall with the webui I would still vote on it being clean, and simple just a user friendly way to edit the config for novice users simply show each calendar that is in the config, with an easy to use form to add/remove/update calendar feeds with out getting your hands dirty. In the long run it would be great to have some stats (Because who doesn't like stats?!)

Having the ability to authenticate to Google Calendar and pull calendars would be neat, so would the ability to be able to add events to a subscribed feed from another app eg Apple Calendar, Outlook etc ... but of course this likely entails having a database backend, and an exposed service running to do so (which I am not opposed to, but it does start to make this a BIG piece of software).

Thanks for reading my ramble :)

[sdenike]

I came across https://github.com/ridafkih/keeper.sh , just adding it here for reference.

[Jojodicus]

Looks nice, syncing to an existing Google Calendar is a valid use case to block the timeslots from someone booking a meeting. My original idea was to just have an easy to use merger that instantly spits out sharable links.

Though it's leaning a bit much into the "complicated" side, at least in my opinion. But I'm happy to see more people exploring what you can do with DIY calendar management!

[sdenike]

In a previous career, the booking of timeslots on various calendars would have been great for me, but not so much needed these days.... now it's just about making sure I am organized and at the right place at the right time.

I agree that it is on the complicated side with usability, but there are some of the UI aspects of the one linked, just didn't want to forget about it when/if I am able to start working on some frontend, so friends and family are able to enjoy the merged calendars like I am.

[Jojodicus]

I've hit up AI yesterday to come up with a draft on how this could look:

Not perfect, some UI elements and positioning can definitely be debated about, but looks good promising enough to consider it.

I still stand by that CalUnite should have the option of running in "lite" mode, without a UI. An idea is to use multiple docker images: calunite with the webUI and calunite:lite without it (version pinning with calunite:1.7.1-lite for example).

The "full" version can have a second executable inside, alongside all the files needed for the webpage of the UI. The UI can then run a second webserver on a different port, 8081 for example. Would make it easy for users to get the UI up and running, as well as give people the option to use the size-optimized version without it.

Some questions still are: how to do authentication? None, single admin user, or proper user management with something like LDAP?