![]() This allows you to plan orbits and burns in advance, and make sure you end up exactly where you want to be. While the map view is useful for viewing your current orbital projection, its real power is in the "maneuver" system. Some plugins have watchers on specific variables and update their presentation whenever these variables are changed. The app itself basically works by telling Vue that variables from the websocket have changed, and Vue automatically updates the corresponding DOM elements with the updated data. It's a lot to explain, but look up webpack, it's handling the assembly of the components into a single-page app. It's compiling Jade templates and SASS stylesheets into a component based system using Webpack. ![]() The setup is something I've used for a lot of projects lately, it's basically a single-page app built on Vue.js (a simpler, faster alternative to frameworks like Angular), it works well with an API backend, as well as for a static page like this where the websocket connection is the data provider. This is just initial thoughts, let me know if you guys have any suggestions! and allow the user to link them to specific data providers, while also allowing "static" plugins like the map display, which wouldn't work well with a dynamic data source. I think I'll also end up splitting the components into displays, gauges, etc. This should be simple to store in a JSON structure, and it's a modern and flexible way of defining a grid based layout. I'm thinking that it will work by allowing users to split sections of the interface horizontally or vertically (kind of how the current layout is defined), and resizing them (translating the proportions to the CSS flex-grow or flex-basis property). Thanks! I've looked at some options and other plugins for telemachus, and I'm going to start implementing a flexbox based modular layout soon. If it's possible to display any resource like Rich mentioned above this will be implemented for sure! I'd like to include the ability to display any resource, but the API docs for Telemachus only referenced the vanilla resources so that's what I started with. I haven't done this yet as it requires a bit of work, I've kind of just whipped this thing up over a couple of days, but it's definitely on the long term todo list to improve this.Ģ. I'm kind of leaning towards modularizing the design completely, splitting it into data providers and visualizers like gauges and displays, and allowing the user to customize it to their preferences - maybe with the ability to share layouts as e.g. I've done some tweaks to improve the design flexibility (automatically shrinking some modules to fit smaller screens, using the viewport width and height to scale the elements), the thing is that I haven't really decided how I want the modular design to work yet. While you show the basics, there are quite literally hundreds of modded resources.ġ. Not everyone has a monitor big enough to display it.Ģ. You have apparently hard coded it for a fixed width. If you encounter any issues, please report them on GitHub or in this topic and I'll take a look at it right away. I'd love to hear what you guys think, if you have any cool ideas please feel free to post them in this thread! The source code is available at under the MIT license.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |