Working on new editor - would it be useful for open source release?


I’ve created a custom editor for Xibo, it’s still a bit cumbersome to install and it is very much alpha-status (everything works but it isn’t optimized at all) but I was wondering whether this sort of thing would be useful for anyone else to be released in the ‘wild’?

The entire thing is made in JavaScript/HTML5 and either uses the 1.8 API or reuses functions that currently exist (eg. form rendering).

It uses jQuery and everything is drag-and-drop so it doesn’t need any custom libraries and it also doesn’t reload the entire page every time there is a change, this means though that it is practically a “Live Editor”, any change in the editor, with 1.8 and XMR on the system, results in an “immediate” change if the layout is on-screen.

Let me know if anyone would be interested in this and/or willing to contribute in it’s development.

I’ve attached a screenshot

1 Like

That looks really interesting - you’ve probably seen that we are keen to improve our layout designer experience (see Layout Designer Timeline Improvements). Our suggestion is slightly different from what you’ve produced, but we’re always open to suggestions!

The key part of our specification was to add a floating lower tool box for adding/assigning new and existing widgets to the designer - this would fit nicely in with your design too. It would show “modules” that can be added as widgets, library content and allow searching (opening new tabs in the toolbox so that you can remember searches across Layouts).

With regards to your design, I like the “timeline” style set of regions shown at the top - I guess that if you click on a widget it opens up in the “widget viewer” - effectively providing a scaled preview of that widget?

One of the things we are trying to do with the current designer is to provide a “complete” preview of the content, as it would be seen, side by side. I am guessing that you wouldn’t have a “live” preview in the “Layout Viewer” section - and that section is only designed to position the regions?

In any case we’re really keen to see it working and to potentially use it in the core product to replace the existing designer. We plan to do that for 1.9 release, including having the Playlists functionality working. Would it be possible to provide a copy so that we can see it working?


I’ve shared the work-in-progress on Dropbox. I’ll publish the initial alpha-version on Github as soon as I’ve got everything to a working state. Please be kind, it’s re-using a lot of current Xibo functionality so there are some workarounds and a lot of it could be optimized. The PHP code just goes in XiboRoot/custom, the code that is in “build” goes in XiboRoot/web/modules/liveeditor I’ve symlinked the Twig view to index.html for now. Initially we worked on the design stand-alone (that way the person that designed the UI/CSS wouldn’t have to keep uploading it to Xibo).

We actually had a similar Toolbox in mind when we created this (you can see where it says Library, Image, Video - I still have to add in a few more modules). Adding a few tabs for the Library and (saved) Search function would be great. There is a lot of screen real estate devoted to effectively 2 toolboxes, they could be scaled down and initially we were thinking about having a set of toolboxes that open/close based on what a particular user needs (again, like UI’s in Gimp/Photoshop do).

The main goal for this editor was to show the timeline of each region relative to other regions and we took ideas from video editors like Adobe and iMovie - in current Xibo it’s not really visible or easy to see what is concurrently on the screen while designing so this should solve that and make editing layouts more straightforward.

Clicking on a widget does indeed show the preview, it is scaled correctly and with the right “portion” of the background rendered so that any background effects are visible - double clicking opens the ‘edit’ form. You can also drag and drop them in order (much like audio/video editors) although the drag and drop doesn’t traverse regions, mainly because I am not sure if the code is in Xibo API to move widgets between playlist. You can drag an item from the “modules” into the timeline which should then render the form to do this.

I currently do not have a “Live Preview” in the Layout Viewer although that is on the wish list - for the first version we needed to get something working fairly fast.

Thanks for sharing that - i’ve taken a quick look through and wanted to give you some (kind :slight_smile: ) feedback.


The SPA style is good and inline with how we were planning to tackle our designer improvements in 1.9. I see that you’re serving the SPA from inside the authenticated “web” session, which is exactly what we planned to do also. In 2.0 we are hoping to have a full SPA, which would then use token authentications to talk only with the API - but that is not practical when there is a mix of approaches.

Obviously you’ve already said its early alpha, so i’m going to ignore everything else related to structure. However my one comment is that we can probably improve the backend API to make some of the calls easier to manage.

As a side note - we’d include the twig page and javascript in the theme if we released it with the core cms. We’d need to think about how to model the build process, so that we didn’t ship the SPA src with the release archive (we already build with gulp, so that shouldn’t be hard).


Generally speaking we like it - the toolbox we’ve already spoken about can be expanded into our tool box we’ve already designed, and moved to popover at the bottom of the screen - great.

I can also see why you’ve used the page header to hold the existing toolbox (some of it) - making better use of space.

I think we need a way to “blow up” the Layout Viewer section so that region positions can be changed on a larger view (making changes for a lot of regions / small regions easier).

The timeline is nice - I guess this could scroll if there were more regions. We have one doubt about the way its rendered - for example, the default layout:

This might look like the text in region B will show for 10 seconds and then blank for another 5 seconds - but what actually happens is that region B’s text stays on screen until the end of region A. Perhaps some sort of “read only” repeat would make that more obvious?

Really like the popup preview - much better than loading it in a tab.

I’ll think about this more over the weekend and provide some better feedback


The timeline does scroll sideways, we could also include a scroll horizontal if there are many regions. On the wish list there is also an indicator on the timeline so that when you scroll it renders the preview according to where you currently are on the timeline. But that was a bit more complicated than I wanted to take on initially, it’d be great if I could just pass a timestamp to the API and get a “preview” back.

The widgets indeed do not render ‘correctly’ yet when there is no length specified and I also haven’t yet gotten the right way to render depending on whether the widget is set to loop or the region is set to loop. I actually don’t even know how it renders on the Xibo player, does it interrupt a looping widget/region? I find looping a widget/region confusing because things like a ticker on loop refreshes as soon as the last item comes on screen (it doesn’t play the last item) and there is no indication as to how long a particular widget will display for when there is variable lengths of text (like an RSS feed). The reason we came up with the timeline is so we would figure those details out and be able to represent it to the end user which really doesn’t want to think about loops.

We were thinking of making the Layout Viewer blow up into a Bootstrap Modal, that’s trivial to do.

Feel free to rip the entire thing out of it’s current Gulp setup, it was only a scaffold for us.

A time stamp instead of a sequence - that makes some sense, although does get complicated when you consider that some widgets have non-trivial duration (for example “end detect” videos, duration per item feeds, etc). I guess it could be based entirely on the calculated duration.

Perhaps it would be easier to obtain the sequence based on which element was under the “current position” marker - like a slider that you could position anywhere on the timeline space. As elements scrolled under it, you could ask them for their position. The marker would be positioned far left by default, and would move with mouse clicks on widgets.

If you go right back to first principles the logic is simple - when a region expires (finishes playing everything) it says “hey, i’m finished”. At that point the Layout either says “great, everything else is finished too, lets stop” or it says “great, some other things are still playing, keep going”.

The region is then in-charge for what to do next. It makes the decision based on the number of items it has in its timeline. If there is more than one item, it will always restart from the beginning. If there is only one item, it will start from the beginning only if region loop is ticked.

Imagine a region with 1 image in it (a logo say) - that wants to be fixed on the layout for the entire time we’re playing, not reloaded at all. With the default config - single item in region, loop off - that is what happens (even with a duration of 1 second). The moment you add another item to that region, they will rotate until the rest of the layout expires.

Where items will/will not loop, it would be nice to show a bar, which extends out the entire length of the timeline, something like:

You are right again - the reason for this is that “bad information is worse than no information”. We can’t know how long a dynamic widget will play (dynamic widgets are any widget than can set its own duration). We can guess - i.e. we could say "based on 10 items being returned, this will last for 100 seconds). How that is represented in the timeline is not something I have any good ideas for.

It gets more confusing if the dynamic widget is in a single region on its own - in this case it might actually be the longest running widget and therefore control the length of the entire layout… but it might not.

I think that all we can do is present the timeline in a way that says “we don’t know how long this item will really be”.

Would it be possible to have an “expand” button on it that blew it up - we’d like to move away from our form based approach in 2.0, so doing it outside a form would be consistent with that.[quote=“Guru_Evi, post:5, topic:10225”]
Feel free to rip the entire thing out of it’s current Gulp setup, it was only a scaffold for us.

I don’t object to gulp - i’m tempted to even suggest that this lives in a separate repository and is “built” into the release archive at release time. Your work can then be a foundation for us moving towards a SPA in 2.0

As a side note - 1.9 will have playlists functionality fully implemented, fingers crossed, and there will therefore be a 3rd dimension to the appearance of the timeline. I’m imagining a strong “line” between playlists on the region timeline, that acts as a break and prevents regions being moved past that point. The “toolbox” would somehow show Playlists you have permission to add to your region (as well as widgets).

Just to clarify, i’m not for a moment suggesting that you develop all these things :blush:, they are just suggestions for what we’d need to do to include this working into the core CMS.

I’ll work on the looping system and clean up some of the code. The code has things for playlists since that is currently in the API (you return regions which have playlists which have widgets, I now understand where playlists are going)

Just as a clarification: if the playlist has one widget, the widget stays on regardless of its duration? If it has more than one, the widgets loop based on either individual duration or a minimum (eg 15s for images) but they always stay on for the duration of the layout (they don’t disappear?). If that is the case, what is the purpose of specifying the loop flag if they loop regardless? Or is it just a refresh flag for e.g. web content?

My initial interpretation was that if no duration or loop is set, it stays on for the length of the Layout, divided evenly across multiple widgets.

If a duration is set, it comes on for that time, it shows and then disappears forever. Then the next widgets get the remaining time.

If a loop is set with duration, it shows for that time, then restarts content that is too short to fit (e.g. a 5s video loops in a 60s widget)

If a region loop is set then it loops all widgets in order as described above.

I think it would be wise to get some of the ambiguity out of Xibo, especially during the design process e.g. When you have no regions or widgets that specify a duration but do loop, the Layout still gets reloaded every few seconds or replaced by the next one.

Pretty much everyone that needs a layout to “switch” will understand the necessity to specify limits while those that explicitly don’t want a limit (e.g. Menu boards) are confused that the Layout does reload itself resulting in “flashes” - my ugly hack is to make Layouts that are permanent have length 86400s (24h) with appropriate Region and Widget loops.

I found this: Understanding Media Duration and how it affects the playback of a Layout

That and the picture above explains it a lot better. The admins should amend the post with the picture to explain Region Loop, I think it’s also a good candidate for being included in the documentation.

According to the region loop flag - based on your second message I think you understand. I will add the image to the understanding media duration topic.

I have seen this “hack” on many CMS’s that we’ve looked at and I do understand why users want to remove the “flash” as the layout reloads.

A fantastic first step would be to have a designer that shows how things will play inside a layout in a more visual way. Outside of the Layout, that I think that this can only be solved in Player logic, so that has an understanding of when a layout is the only item in rotation, and will “leave it” in the expired state.

I’ve updated the linked article - hopefully it is clearer now.

I’ve been able to make the timeline representative of how widget playing works in Xibo (single widget in a region spans the entire time, all widgets loop until the end of the timeline).

I’ve also been working on refactoring some of the code that loops through the regions, playlists and widgets and breaking those loops in separate functions so individual widgets etc. can be added on the fly, right now I’m relying too much on redrawing the entire Layout every time a change occurs.

I think the Dropbox link should update automatically, if not, I’ll start putting it on GitHub.

Great - i’ve initialised a new repository to hold this work, here:

If you’d be happy to fork that into your own account and put the code in there, then that would be great. As I said before, the intention is that 2.0 will have a SPA, which gets built from the above repository and included in the release archives - for 1.9 we can get that same process setup only for the layout designer.

Also, I would appreciate it if you had the time to sign the CLA?

All done, I submitted a pull request from my Github account.

Great, thanks.

I’ve created a label in our issue repository for this and submitted a PR to update the readme in the repo. I’ve got some thinking to do for how to architect this so that we have a sensible way to develop/release - pulling from both repo’s

I think it will end up being quite simple - with a gulp task in the CMS repository which pulls and builds the SPA, and puts the files in the right places (.gitignored). In the spa repo, I think we’d have a docker-compose file to spin up a CMS, and a gulp task (monitor) which builds and copies the source into that container so that the work can be tested “live”.

Something along those lines anyway!