Replies: 3 comments 2 replies
-
I think your app is super cool. Have you looked at the new library notcurses? Profanity doesn't necessarily need sixel or graphics (which do not have universal support), but the drawing UI might be of interest to you. |
Beta Was this translation helpful? Give feedback.
-
Just an idea - what about an option to use a mobile (portrait) friendly layout. Something like this would be nice on the linux based pinephone. |
Beta Was this translation helpful? Give feedback.
-
I also think it would be nice to have an option to not have the dates printed on each line. In the chat windows this might sense but in the console window it makes only sense in some cases and otherwise just wastes space. For This will probably not as easy as we have a million window functions... Hint: there is |
Beta Was this translation helpful? Give feedback.
-
Profanity aims to be an XMPP client in the spirit of the irssi IRC client.
The following image is supposed to explain the names of the various UI elements in Profanity:
Our goal is to stay with the default look and feel of irssi.
But occasionally new users have requested some changes. Let's discuss them here.
Window management
Our windows are on a fixed position.
The roster/occupantswin can be hidden. The roster can only be visible while we are in the console window. The occupants window is only visible in MUCs.
Two users expressed the wish to have the roster window always visible?
How would we do that?
Which brings us to the question: should we be more flexible with our window managment?
Modal interface
Several users would like to have a modal interface like vim.
AFAIK mcabber also has this to a certain extent.
How would we do this? What could be done in normal mode? How would we be able to stay with the irssi like behaviour by default?
More modular UI
So far we just print everything in the chatwin/privwin/mucwin window. In there everything is just text.
We have the following issues/requests:
#1663 would just let us manipulate what we write as the first part into a window. This means once it's written we can't change that. So if a user changes this mid-session. The messages so far would stay in the old style.
Does this matter? Maybe not. But maybe it should become a new element for easier configuration.
#987 wants a configuration option to indent the incoming nicknames / messages. So this would again me more elements on the screen. And not just writing a whole line and then be done with it.
Maybe we need to sort this like
timestamp | stamp | message
. Wherestamp
is the nickname/jid (depending on setting.#1301 wants to display inline (among other techniques, ASCII art) images. This also can be problematic. What if the terminal is resized? We would have to rescale the picture and redraw. Maybe this request doesn't make sense at all and we should implement this and leave the task of displaying images to an image viewer.
Internal
Earlier we read/write messages to text chatlogs. Later, as a preparation for MAM support, we introduced an SQLite database #1282 for storing the messages. The text chatlogs are still supported but Profanity will just write them, so the user can use them for various purposes, but never read them.
We still need to implement reading from this database. So that we can infinitely scroll back our current window to read all messages ever written (that were saved to the DB). This retrieval isn't implemented yet.
We need to find a smart way to do this. We have ProfWindow, ProfBuffer (with a limited size) and the DB backend. For performance reasons we don't want to store too much in space and also don't want to read the disk upon each scroll.
When #660 MAM is implemented we also need to find a way to fill in the blanks. Meaning:
Profanity is online - we log the messages to the DB
Profanity is offline - another client reads the messages - we dont have them in the DB
Profanity is online - we get more messages and write them to the DB
We need to send a MAM request to get messages and insert the ones that we didn't have so far. Depending where we are in the UI we also need to insert them on various locations.
Earlier we just had text in ProfBuffer. I'm not entirely certain but I think I rewrote this to be of ProfMessage, so that we have more details.
We need IDs #1207 for checking and we also need them when:
Maybe in the future we also want something like an LMC history. So that we can see the old messages that got replaced.
We need to rewrite our internal handling to accomodate for all those cases.
And maybe rewrite the UI elements to be more modular.
Beta Was this translation helpful? Give feedback.
All reactions