ircv3 / ircv3-ideas

46 stars 3 forks source link

Road to a full GUI #49

Open Alexendoo opened 5 years ago

Alexendoo commented 5 years ago

I think it would be great if it were possible to drive typical IRC usage fully through a GUI, rather than being required to use text commands in many cases.

Many things work great currently, the main blockers I can think of are:

Having a full fledged GUI for configuring user/channel settings would require at a minimum being able to enumerate all the configurables for a given target, and some server provided descriptions to display alongside them.

Other things like describing the type (text, on/off, a number, etc) and categorisation would allow an IRC clients to drastically improve their ease of use.

Are there any solutions in the pipeline that cover this? And have I missed any other blockers?

prawnsalad commented 5 years ago

A few clients have been working towards this. Kiwiirc, I believe quassel-android. As we start to cover different areas of the UI then that's when new specs tend to come about to cover the use cases.

Account registration, https://github.com/ircv3/ircv3-specifications/pull/276 Channel management is already possible for the most part. Likewise with modes

DanielOaks commented 5 years ago

note for others: this could also be interpreted as 'consistency'. having these sort of things done in a consistent manner in the protocol also allows text-based clients to create nice, clean interfaces for them that work across multiple irc nets and servers, so it's good for erryone.

Definitely have some stuff in the works here! The Account Management Framework spec provides consistent user registration. I've opened the Channel Management -ideas issue as a holding issue because account and channel management interfaces should be as similar as possible, so I'm waiting for the final ok/nah on the account management framework PR before opening up a channel management framework PR that's almost identical to whatever gets ok'd.

Modes, Insp has had some custom named-modes stuff for a while now but not sure where that's progressing (Atilla was in charge of it but since they're not active it may be worth someone else pushing that forward for now instead).

With regards to the general configurables for users/channels, for the account stuff at least the frameworks described above are designed to be extensible so something like that can just be slotted right in. For the non-account stuff, named modes should let clients do that a lot better without needing to maintain weird custom lists.

Alexendoo commented 5 years ago

Named modes would certainly help with colliding modes between servers, but I feel like it could go further and expose a description for each mode so clients don't have to maintain a (possibly incomplete) list.

@prawnsalad Could you elaborate on how channel management/modes are possible currently? I can't see a way short of targeting all the service/network specific behaviour

progval commented 1 year ago

Update with the current status: