One more amazing feature. I just put a dynamic sub-browser panel (call it overlay).
- Short press toggle visibility.
- Long press open edit panel in edit mode.
- View only mode avaiable (so no interraction) otherwise usually in interactive mode
- Hold control for quick edit (i.e. repositioning).
- Undere consideration (and partially constructed) is inner zoom and pan. But i am sort of running out of unused key combination bindings on the browser.
Here is how the panel interaction looks like
This could be any website or webviewer (or cammera view). For me remotes or scores or tempo are most useful. We chould have multiple of those if needed.
New password page 
Then i just tough woulnd’t it be cool to have slowly blending backgrounds and here is the result at 30x speedup
New offline app upcomming
While you are connected to the server you sync up data which is stored locally. Then you can browse the songs and the bibles offline anytime.
Well i really went overboard this time. What you are seeing is a service process manager.
And in white. I think it looks better in white actually. … anyway
So:
-
Essentially, it includes or supersede the original init which is just a single sequence. (main method)
-
Can seed-up startup. Now we can don’t need a predefined sequence but can allowed automatic initialization in parallel based on dependency tree. Cool!
Any one that knows anything might think Docker or SystemD and you would be right. It’s sort of like that.
-
We can control the lifecycle of the services (if you are given the user-permissions).
-
Restarting or stopping any part is not a problem now. Maybe you need a lower RAM usage.
-
Any errors that might occur could potentially be fixed by restating a module but even more so it’s very useful for the HTTP web servers for remote and content and as well as the MIDI control module. If say a device appeared after initialization. (unlike in OpenLP where i made the same midi plugin, this one is more basic and can’t auto wait (reconnect but not quite), although Java sort of allows auto reconnect.
-
You have a nice UI.
-
Now we can initialize Quelea partially, which means we could potentially run it as a terminal application . Or headless mode.
===========================================================
-
Finally, this is half the work (maybe 1/3) to enabling 3rd party plugins to work. Generally we need a dynamic or runtime attachment mechanism and also we would need a solid (maybe polling) api interface… not that i expect anyone to write a plugin but now we could.
I wrote this tool to check code contributions by lines of code for developer and also shows how many files each has toched. Based on the src and the server dirs, which is the meat of the project I have altered almost 30% of the application, which i didn’t expect.
To show you a cool visual of the tool:
1 Like
Here is something pretty cool: 3rd party plugins!!!
Since I did a service manager/init system it ended up being really easy. So i just went for it.
Also in the repo there is an example template how to create the plugin you can see below.
The example is a simple timer process with some UI and dynamic menu entry.
Some interesting points to note:
- Overall it’s pretty robust, you can load them during runtime, and you can restart any services for whatever reason. So it’s pretty great.
- The plugin subscribes to the service manager and the theme manager and loads assets from within the directory that it’s found in.
- If during start there is a problem the indicator will be in red.
- If there is an error during attachment it won’t show up. i guess we can put a message it was detected but failed to load.
- Fancy python code ? Sure use whatever. Just needs a Gradle entry and you can do just about anything.
- During development, the plugin can be initialized with service manager as normal service code.
When done the code is moved to the plugin directory (see example) and we give it a name and a starting point.
- Actually, the InteliJ Idea’s debugger will attach to the .java files just fine even if we initialize it from the JAR externally which is good for deployment testing.
- Then we place the JAR file into .quelea/plugins and that’s it. No fuss no buzz
======================================
P.S. I have put there just about anything we could want at this point. I think the only thing missing to take it to superhero level is a multimedia engine which deals with routing of sources, sinks, muxes, layers, filters etc.
I have 0 incentive to build that, although to me it would be only a bit harder than what I have done so far.
I kinda “hate” Java a bit too… anyway.
In theory having control over the item data flow would allow for any kind of cool configuration. e.g. :
- multiple projectors
- allowing each to have a specific layer: each could put a different theme on the song
- We route to NDI, or OBS, or web specific layers or whatever we want.
- Dealing and routing with audio would also be amazing.
And of course having dynamic items like mini clips.
To be honest I didn’t really want to bother doing it but since it was really easy, I just refactored the RChandler into a proper API. Any previous http methods were overloaded as normal methods with some suitable arugment. Like so:
Now this thing can be used internally as an plugin context API. Also fixed various ussues along the way.
Actually, there is a api.js file which contains all api calls in a very simple form, obviously http://localhost/api-list will get you a really nice list (probably needs a bit of update actually).
.
Now external integration can be done more easily at any level: a JAVA plugin, http server, API list , MIDI control etc.
I got annoyed an switched to a socketed connection, but since i am lazy to do more i just implemented a basic Media Router which only gets notified some content was updated. Then pushes to the socket which is managed by a service
The socket only does notifications and doesn’t push data. So everything else is the same and we do an HTTP calls to fetch data. Obviously, it’s not the most efficient but it’s quite minimal in terms of changes, and still getting the benefit of the socket.
On the frontend the server checker …
It will always try to re-establish a connection with the server and it will re-setup the socket.
The pollers are still there and actually. I left the poller for the drawer as is, but that one dynamically scales the refresh frequency dynamically depending on the open/close state.
Sooo … No more constant beaming of requests! And control will feel a lot more snappy. Backward compatibility is ensured.
P.S. The only think to decide would be if i want to use the pollers as a backup. If the user manually turns the socket OFF then … maybe the user should just not touch that stuff
I think it’s more elegant to have this choice
View pdf will open it in the default pdf viewer, while print should do
I think it’s better than just printing straight away to who knows what device
Instead of live text, for messages I went with something more chat styled:
Supports both chat style and immediate style. Whatever you fancy.
