I just did the switch from Allmon2 to Allmon3 as well and ran into the same issue. You can tweak commands.js to allow the commands to show on the actual node menu. I find it more convenient to have my node/voter commands grouped in one menu. I also modified index.html & voter.html to integrate them into one display.
I have no desire to maintain a fork and the changes are not fitting for inclusion with a PR due to the nature of the changes. I have no issue sharing my files though.
In summary, the changes are as follows:
voter.html is modified to only show the actual voter data like the image below. (unused code in voter.html is simply commented out as to allow easier code comparison when new versions are released).
index.html is then modified to have voter.html inserted via two iframes at the bottom - one for each of my voting nodes. Below the iframes the voting legend info is also inserted in the index.html file.
Additional changes include hiding the sidebar with a css block in custom.css
.sidebar {
display: none!important;
}
I'm fully open to someone adding layout ability to Allmon3. But it has to be reasonably configurable for things like on/off, still supporting separate pages, the menuing system, etc.
I know you're a busy guy, @WB6OZD but could you at least do a PR of what you have? Even if it not exactly what @N8EI likes at least it's a starting point and a reminder for the todo list.
@wd6awp Like I mentioned above, the changes are not fitting for a pull request.
Ideally, voter.html should be modified to take a parameter so it can display multiple voters. To really make this easier for folks, you should be able to specify both nodes and voters on the index.html page.
Something like index.html?node=49371,49372,49373,49374&voter=49371,49373
For now, folks are welcome to look at my modified files and adjust yours as needed. Since I couldn’t upload a ZIP file here, I have made it available via a download link.
Agree with this. I think it makes a lot more sense to have the functionality combined into a single reusable page, rather than sectioning VOTER stuff off somewhere else.
Since the URL param method is already in place and "the norm", this makes sense.
The other idea, is why not "know" that a node is a VOTER and show the display automatically whenever that node is requested from index.html? I think this is already an issue/PR with Allmon3 (having to manually specify that a node # is a VOTER, and having to manually add a menu button pointing to voter.html for that node). I guess that would need to be user controllable in case someone does not want to see the VOTER display for a node, which brings us back to manually specifying node and VOTER #s in the URL.
I don't foresee making an automatic process to identify and display everything that has a Voter configured (I'm not sure you even get that from AMI). There's a lot of people who use chan_voter connections for "non voting" applications - e.g. using an RTCM on a repeater radio and connecting back to ASL hosted elsewhere.
It wouldn't be that hard to display a set of Voter bars under the node overall. However the problem is everyone wants something different and I don't really want to get into the position of having to support a multitude of UI/UX options (at least not personally). Additionally, I don't actually have or have access to a voter system where I can test any of the voter code. So it's difficult for me to fix issues - e.g., the longstanding bug that some voters don't turn green. I'm more than open to having others join the repo as contributors if they want to hack on the Allmon3 code. But I also don't want to lose track of the fact that the 95%+ usage of Allmon3 is for people without voters.
