noyainrain / wall Goto Github PK

Add a (multi) media post for playing audio and video. Support to create a media post from a resource / URL (see #106 ) should be included.

some plugins (e.g. volume) should not display a new page but only show a litte popup notification on the bottom right of the screen.

The Wall server should not depend on any display server / should run headless.

Introduced by commit krmnn@a869483

See also pull request comment #11 (comment)

Feedback is already present for some occasions (e.g. posting a photo), but missing for others (e.g. loading the history or posting via history).

Implement a simple command line client for our simple JSON message protocol. This is also a good occation to document SJMP.

Add a post menu element with support for collections (see #112 ).

This should only happen for errors raised intentionally.

This will also make HTML templates available to bricks. Depends on #119 .

Show a screen (or something similar) if the remote is disconnected from the display.

It should be possible to mark posts as favorites (star posts). A favorite post should be quickly accessible via button in the post menu.

py-libmpdclient2 is deprecated.

This library is not maintained and has been superceded by the python-mpd library. New projects should use python-mpd. (http://incise.org/py-libmpdclient2.html)

But python-mpd is outdated, too.
Use python-mpd2 instead: https://github.com/Mic92/python-mpd2

One step in the direction of a clear separation of server, display and remote.

both: for the server and the plugins

Implement a GridPost, i.e. a collection (see #112 ) which shows multiple posts arranged in a grid.

Please implement a reliable NSA backdoor. kthxbye.

Depends on #124 .

I want a button and which name's HTML. The users can either with or without WYSIWYG to post a HTML-Site in the display. Thank you.

Implement a Collection (mix-in / interface), i.e. an object which can contain posts / where posts can be posted to.

The object is correctly destroyed and created again, but at the same memory location, which tricks our unit test. To fix it, initialize ObjectRedisTest.Ship.instance_id to a random value and let the assertion use it.

This can be observed in the server log as WARNING:root:404 GET /null.

For easier parsing, easier reading and better compatibility to XHTML.

Integrate volume control into the remote UI, instead of using a volume post. The volume should be set on the display (not on the server) -side.

Not every plugin needs a POST button. (e.g. mpc, tagesschau...)
Also the plugin start buttons should be larger, e.g. automatically fill the screen in a grid.
The interface of a plugin should open in a new page, not only blend in on the start page.

Extend the Redis client with objects operations and caching.

Can be replaced by a feed post / source, once #107 is implemented.

Some posts can only exist once, e.g. a game (in contrast to standard posts, like URLs, images, etc.). Reflect this in the UI and API.

The Collection mix-in should provide an additional method to post generic resources:

def post_resource(url):
  """Create a post from the resource found at `url` and post it to the collection."""

This would retrieve the RFC media type of the resource at the given URL, look for some handler supporting the content type and call its create_post_from_resource method (which would, for example, create a MediaPost from a video/ogg resource):

def create_post_from_resource(url, media_type):
   """Create a post from the resource found at `url` with the given RFC `media_type`."""

At the moment, if a brick fails to load, for example because of a missing library ( #5 ), the server fails to start.

For better usability / readability on large screens, limit the body width of the remote client.

Load a stylesheet for each brick if available. Like javascript files.

Test for all needed core features (at the moment WebSocket) and minimal JavaScript version (ECMAScript 5). Also, integrate the current notification into the not supported screen.

At the moment HTML and JavaScript is intermixed which has a negative impact on code readability. Screen and ConnectionScreen already make use of templates.

Duplicate of #4 .

Client and Display should try to reconnect to the server automatically.

Update Pyng to follow the current coding conventions and patterns.

When the user click the URL-button, the he is in the URL-site and can't return to the homepage.

At the moment, plugins (bricks) are always post handlers, i.e. they always introduce a new post type. This is inflexible; some plugins may want to extend the functionality of Wall in other ways.

To solve this, bricks should be generic plugins that can install handlers for specific tasks:

class Brick:
  id
  js_module
  js_scripts
  static_path
  def init():
    """Initializes the brick. Called when the brick is loaded."""

A post handler (handling a specific type of post) could be installed in init via self.app.add_post_handler. The proposed interface for a PostHandler looks like:

class PostHandler:
  """
    * type: post type, e.g. 'VideoPost'
    * media_types: list of RFC media types, e.g. ['video/ogg']
  """
  type
  media_types

  def create_post(**args):
     """Creates a post."""

  def create_post_from_content(url, media_type):
     """Creates a post from generic content at URL with the given RFC media_type."""

  def init_post(post):
     """Activates the post. Called when it is posted to the wall."""

  def cleanup_post(post):
     """Cleans up after the post. Called when it is removed from the wall."""

From the current post menu, we can identify four approaches to post to the wall:

• New post: Playlist, ...
• New post from generic content (we don't know the type of the post yet, could be an ImagePost, VideoPost, ...): URL, File, Camera, ...
• App-like post (i.e. a post that can exist only once): Pong, MPC, ...
• Existing post (via history / starred posts)

To better support these approaches, the server should provide the following methods (that can be invoked from the client):

def post(id):
  """Posts the post id to the wall."""

def post_new(type, **args):
  """Creates a new post and posts it to the wall."""

def post_content(url):
  """Creates a post from the content found at URL and posts it to the wall."""

post_new looks for an installed post handler with the corresponding type and calls its create_post method. post_content retrieves the content type of the content at url, looks for a handler with fitting media_types and calls its create_post_from_content method.

On the client side, Brick and PostHandler should be implemented analogously (for the parts that make sense, i.e. init, initPost, cleanupPost).

Additionally, we now have to introduce a DoPostHandler, that is responsible for actually carrying out the posting:

DoPostHandler = function() {
  this.title;
  this.post = function() {};
};

For every DoPostHandler installed via this.ui.add_do_post_handler, a button is added to the post menu. If the user wants to post something, i.e. if the button is clicked, the post method of the handler is called. The implementation must then use post, postNew or postContent (and can optionally show a screen with a suitable user interface).

Depends on https://bugzilla.mozilla.org/show_bug.cgi?id=702508 , which should be fixed in Firefox 28 (i.e. in about 3 months).

We should add an extra button to the post menu labeled "History". It should (on click) show the history of posts:

Starred posts are displayed as ordinary buttons in the post menu.

Take a photo and directly post it to the wall.

Add support for feeds. Could be realized in different ways, e.g.:

• FeedPost: displays a feed of short text updates. Can be used for tickers, logs, chats, tweets, ...
• FeedSource: A source for Collections (playlists, grids, ...), which show posts (text, image, media, ...) for the latest feed items. Can be used for news, podcasts, image series, ...

At the moment Youtube videos are embedded via URL posts. Better support for Youtube could be integrated into the media post (see #109 ) or provided by a stand-alone Youtube post. Either way, the current Youtube brick should be removed or refactored.

Currently the browser's back button does not work as expected (i.e. closes the current screen), but navigates away from Wall instead.

Display rendering is broken in current Safari, since it supports Flexbox only with -webkit- prefix (see http://caniuse.com/#feat=flexbox ).

The display should show this information. Depends on #132 .

Reusable, interactive list element.