gnu-social

History

Mikael Nordfeldth 414a95a784 Initial move towards microformats2 No validation has been attempted yet. Lots of changes left. This is visibly not (very) different from the previous CSS layout. But some simplifications have been made. Might cause issues with local changes to themes and CSS. Also maybe javascript which depends on certain legacy microformats elements. The move to microformats2 is motivated by the announcement that all microformats should be migrated to version 2, as of 2014-06-20 at: http://microformats.org/2014/06/20/microformats-org-turns-9-upgrade-to-microformats2		2014-06-22 17:11:04 +02:00
..
actions	plugins onAutoload now only overloads if necessary (extlibs etc.)	2013-08-28 16:10:30 +02:00
classes	Replace common_good_random with common_random_hexstr	2013-10-21 13:20:30 +02:00
css	Preparing plugins for no-minify-in-core-policy	2014-02-24 01:01:34 +01:00
js	Initial move towards microformats2	2014-06-22 17:11:04 +02:00
locale	Localisation updates from http://translatewiki.net .	2012-06-30 11:10:38 +00:00
scripts	plugins onAutoload now only overloads if necessary (extlibs etc.)	2013-08-28 16:10:30 +02:00
Makefile	Makefile for Realtime's min.js	2011-03-01 15:33:10 -08:00
README	Realtime plugin: fix i18n, thumbnails, location display, OStatus server display, micro-apps display.	2011-03-14 13:29:35 -07:00
RealtimePlugin.php	getConversationUrl introduced for linking to conversations	2014-05-01 15:25:19 +02:00

README

As of StatusNet 1.0.x, actual formatting of the notices is done server-side,
loaded by AJAX after the real-time notification comes in. This has the drawback
that we may make extra HTTP requests and delay incoming notices a little, but
means that formatting and internationalization is consistent.

== TODO ==
* Update mark behaviour (on notice send)
* Pause, Send a notice ~ should not update counter
* Pause ~ retain up to 50-100 most recent notices
* Make it work for Conversation page (perhaps a little tricky)
* IE is updating the counter in document title all the time (Not sure if this
  is still an issue)
* Reconsider the timestamp approach