It’s the end of the first GSoC period, so it’s about time I clutter the blog
again!
A good few changes have been made to Caya― most obviously support for
multi-user rooms and some UI changes. Multi-protocol add-ons are now supported,
the program is oriented around “Conversations” rather than “Contacts,” basic
moderation (kicking, banning, muting) works, etc.
Looks great! In terms of polish, maybe the avatar and the status dropdown can be moved to the upper area where channel titles are displayed. That area seems a bit dull at the moment. Also the left view can use a border, if it is possible.
Further ideas:
Channels can be grouped according to the protocol
A compact mode similar to the old version with separate optional windows with small tab bars (more Haiku-y if you ask me)
It would be great if you could add the build requirements to the readme on the github page. This would make it easier for non-developers to build and test the program.
On my x86_64 system I had to install expat_devel and gloox_devel. Don´t know if that´s all, I have a lot of development packages already installed
Quick comment : I often follow several concurrent discussions (and I know I am not the only one), so the single “vision like” window looks like over-simplification for my use case. In particular stacking/tiling several windows together is so much more the Haiku way.
I am not very convinced by this. I tried it for Renga, and using stacked windows for more than 2 or 3 discussions was not working so well (and I usually have a lot more than that).
But it is a common request in both directions. In fact, Vision was started precisely to implement a single window, the previous IRC client, Baxter, being multi-window. And then people started asking for multi window mode in Vision…
I am not sure stacking is required here. Deskbar with application windows serves ideally for applications with many windows unlike other operating systems.
(But I see your point with many stacked windows. Haiku needs a new approach in managing many stacked windows, maybe an integrated drop-down or something similar.)
I personally do not like the approach communication software is taking these days. Every new software prefers a unified approach, and taking valuable screen estate. I prefer modularity, where only required/preferred materials are drawn on screen. Maybe it’s nostalgia, but software back in the day definitely did it better (MSN, Adium, iChat, ICQ, Yahoo etc.). Especially Adium mastered multi-network support with a great UI.
I used MSN to chat with friends and it was a lot of one-to-one chats or small groups (up to 16 persons I think?), and in that context, multiple windows did make sense. But for something like IRC or Mattermost, usually you will have channels with hundreds of people in them and a lot of activity, and this needs a different user interface. I think Mattermost and Discord have taken this IRC-like direction even further. I think in this case it’s the idea that you will have the discussions contained in a window, and running in the background (at least for IRC) or as a fullscreen thing when you are actively discussing things with people. Whereas with the MSN Messenger way, it was more like a phone: you’d have the phone somewhere on your desk, and people would call you, requiring immediate attention to reply to them. Which maybe works better when you are multitasking that with other things you’re doing.
I think it is not so easy to cover all possible cases in a single application. I know this all too well from being an XMPP supporter, as the XMPP protocol also sort of tries to cover all possible cases by picking ideas from other popular messaging networks, and goes a bit in all directions at the same time.
Sorry, but this is the worst advice you could give to somebody.
@JadedCtrl:
The posted screenshots are ugly if not horrendous. I don’t see myelf using it at all in its current state. It is basically a 1:1 copy of Quaternion.
I happen to like quaternion, and Rengas gui is similar as is Visions, so that critique seems a bit meh to me :)
It’s good to see work on another chat client, especially native ones.
edit: Quaternion also has a UI control caled a shuttle scroller for scrolling long views without it jumping around, basically a relative positioning scroller with the middle position beeing 0 inertia and higher and lower increasing the scroll speed in that direction (and the knob junping back). we don’t have a control like that yet, might be interesting (i have some ideas for that, heh)
Thanks! Right now I’m just planning on a libpurple add-on (which’ll work with anything libpurple supports), but I do want to do native IRC and Matrix add-ons at some point, for all the goodies that come with that.
Actually, thinking about it, I use separate windows for one2one discussions but use single window when using channels/groups-discussions. Probably got this weird habit when MSTeams was forced on me. I guess I could live with any option, but if giving the user choice is not too hard, that’d be nice (just like you can take a tab from Firefox and move it to a separate window).
I think the idea of “let’s use BFS and Tracker for everything” usually does not work all that well when you try to use it for more than fun demos. Tracker does one thing well: file management. Trying to get it to do more things does not work.
This applies to email: at first, the idea of “all your emails are just files” sounds nice. But then you try to use it and find out that Tracker cannot easily do simple things such as showing your emails grouped by threads, in a tree view, seeing who replied to who. And that’s not the job of Tracker. And that’s why we got a more normal looking lail client, that’s Beam.
Caya is the result of a similar thinking starting from the IM Kit, I think. The initial idea sounded nice, but it didn’t work so well in practice. Your instant messaging rooms and contacts are not files, and Tracker isn’t a great place to manage them.
Now, for mails, it works somewhat fine. Beam still use the standard email format. It makes sense because emails have some data to store. But chat contacts? What would you put in the file? Just contact information? Offline conversation logs?
It is a work in progress and UI often look like that when work in progress.
I think one problem is having lots of margins everywhere, whereas in Haiku apps we are used to very compact layout, not wasting a single pixel. This is easily solved later on, and not something to spend so much time messing with right now. The importance of the UI at the moment is that it allows testing the features. Cleaning it up is not so difficult for someone who is used to doing it. A small margin here, a bit of bold text there, and suddenly it looks 1000x better.
Also this is nothing a sketchbook can fix. Sketchbooks are not good at discussing the size of pixel margins.
I’ve heard BFS’ query language is based on a parsing expression grammar. Is a directory structure of links too expensive or too difficult to maintain? How would that stack up against Beam in this context? If that still wouldn’t work maybe we should start discussion about a glass elevator feature for the BFS query system to more generally index data like MongoDB or its DocumentDB fork.
