Dashboard enahancement

[limetech]

Soon there is going to be a "dynamix.domain.manager" webGui built-in which will be similar to existing dynamix.xen.manager with ability to manage either KVM or Xen virtual machines, depending on user boot selection.

The idea with virtual machines, whether designed to run under KVM or Xen, is that each will be represented by an icon, in similar manner as Docker containers. Clicking the icon will bring up controls for the VM similar to Docker container controls.

From a user perspective, these Icons simply represent "Apps" they have running on their unRaid server, and this is exactly the concept we are trying to implement.

Therefore, what I'd like to see is a section at the top of the Dashboard called "Apps" which lists all the Docker containers and Virtual Machines installed by the user. It's not necessary to separate them out by type (ie, container vs vm), but maybe the type is displayed when user clicks an icon to bring up the drop-down menu.

Also.......... one more thing to try and get onto the Dashboard: Move the "Array Operations" there (and at same time we can rename "Main" to "Devices"). This should let user stop/start array and spinup/down all devices, etc.

With these changes, the Dashboard will provide all the critical status and control operations.

Comments?

[bergware]

My initial design goal with "dashboard" is to have a single status page with all relevant system information combined together. This meant no actions are done from the dashboard page, it is purely informational.
A "trap" to avoid is to have too much information on the dashboard page, when things get too cluttered, one easily looses the 'oversight'.
I was thinking of a "widget" kind of approach, on the available space different functions can be chosen by the user to assemble the look and feel of the dashboard (different people have different views of what is relevant in their system). This is a massive turnaround of the current implementation, but might be a longterm goal though ?

[limetech]

Yes I can see that goal. I think of a list of running apps belongs on the page because it's extremely relevant. When a user opens the page they would get a snapshot of what's running along with device health, etc.

The "widget" approach is something that can be supported by the paging system. As a review, there are three types of pages (actually there are four):

1. A normal page, written in PHP.
2. A "menu"
3. An "extended menu" ("xmenu")
   You already know how these three pages are rendered.
   The fourth page type is another kind of menu but has no name. It's used to generate the top menu bar. The code for this page is just hard-coded in DefaultPageLoyout.php to generate the top level menu items (Dashboard, Main, etc). This page type says, "Render all pages on the "'tasks' menu as a set of horizontal text links.". I should have done this more formally (maybe call it "hmenu"), but never got around to it.

Anyway, the plan was to make everything a page and introduce more "menu" types. For example, lets look at the current header. It consists of a "logo" on the left and a "block" on the right, in which is the server name, IP address etc.

Well the code the renders the logo should be in it's own page file where:
Menu=Header:1

Likewise the code that generates the server name, IP address, etc. should also be in it's own page that also has:
Menu=Header:2

Then we create a new menu type called "header" and another page called Header.page. Next inside default layout we have it render all the items on the "Header" menu in a loop similar to how it currently "Build page menu". I hope this makes sense...

To go one more step, the DefaultPageLayout.php could simply have a loop where it "renders" all pages on the "Layout" menu. Where pages on the Layout menu would be, "Header", "Tasks", "Content", and "Footer".

The reason I didn't do this from the start was that page generation should be recursive and I was having trouble with this in PHP and didn't want to take the time to totally learn how to solve this (being a C programmer mainly), and expediency won the day.....

Anyway, with this approach you can define a "Widget" menu, and have it render all pages of that type as a set of floating blocks.

Similar I was going to have a "Table" menu that would render all pages as sets of table columns.

Well I bet this is confusing, I'm more of white board kind of guy when it comes to explaining concepts locked in my brain :/

[bergware]

I can follow you pretty well, spent myself also quite some time in the page building section (you may have noticed some changes in that department).

Indeed if you want to become fully flexible then all sections must be dynamically build and no more static rendering. In this process it would also be nice if optional plugins can "hook" in and can add or change to the page rendering. Think of additional buttons or fields to be added when the optional plugin is present. The way I do it now is a bit 'clumpsy' ...

Man, these are all BIG plans :)