|Version 8 (modified by anonymous, 4 years ago)|
MattisManzel 2005-09-27 : Nevermind, feature-ideas on the mailing-list vanish into eternity and noone ever reads them again (and a bit it's the same with tickets ;)), better place them here, so they can be developed, also by non programmers and without disappearing from the recent changes. If some idea is nice we can always start a ticket on it. That's step No 2.
There is the locate patictipants function on the right side of the main window. I never used subethaedit and can only guess what it is.
("Locate participants" is an idiotic term for "display [on the srollbar] which part of the file is visible in the other participants' windows". The length of the marker even tells you how large their windows are. It tells you where to scroll to in order to see them working.)
On tings text tends to become pretty chaotic. We even had tings in several languages. When people write a lot and the session goes on for several hours it can be hard to find out where the other participants are writing. By that time we used MoonEdit? and finally finding out that a click on a participant in the list takes you to this person's cursor helped me. But: It would be far nicer it you could see the person, if you could "locate participants". The color shows up to the right where the person's cursor is.
More useful information could be given in this bar to the right. Where has a participant been writing? The line of the last edit in full color, older edits getting more and more pale.
Maybe full width of the bar for cursor localisation and half width for edits?
The windows version of MoonEdit? has an interesting feature of "locate participant". The volume of the typing sound of other participants gets lower and lower the more distant on the page they are from your own cursor.
Well, anyhow having started this page, I can add: I enjoyed the typing-sound feature in MoonEdit? a lot. It creates an extraordinary magnetism to stick to a text and follow its development. I'd be glad to see it developed for gobby. This is no gimick, I think. Maybe check it out on your sister's win box these days ;) (two typers don't do it. It only starts getting sexy with 4+)
A bit similar to the previous feature, but it would be nice to actually see the others' insertion cursors (like we se ours). I know it will be a bit hard to implement with the gtk text view, maybe it will need manual drawing, but it will certainly come dead useful (you see where the others are working, so there is much less chance of unexpected collisions).
Client-side Color Configuration
When using a gnome theme with a dark background and light text, the default highlight colors are effectively useless. More to the point, while it's fine for me to select a dark blue background color to make the white text easily readable for my own text, this makes users of a standard white background/black text theme unable to read my text, and I'm still unable to read theirs. I see two various means for remedying this situation, which take a somewhat different approach to solving it:
- Allow every user to pick others' highlight colors.
- In the user list, have right click options -> properties, leading to 'highlight color' (and whatever else may be appropriate ... checkbox for 'show cursor' or 'play typing noise' or whatever else may be implemented.
- Allow the user to set a list of 'others' highlight colors, such that the first user will always get green, and the second user will always get red, and the third user will always get blue, and so on...
- Have an 'invert colors' option, or something similar, so that everyone's light backgrounds will be 'inverted' into dark backgrounds.
As a side note, it seems that there could be situations in which a user selects a background color that conflicts with certain aspects of the default syntax highlighting, in which case there should be some sort of options to configure the colors/etc. of syntax highlighting.
#167 has been opened for an 'invert colours' option. The syntax highlighting is completely handled by GtkSourceView?, it would require quite some effort to provide sensible highlighting colour handling depending on the background colour of the current bit of text.
Our opinion always was that it's the users' problem if they choose wrong colours, but the dark background on one machine but not on the others is an acceptable case to fix.