Status - update


Recommended Posts

  • Replies 181
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Posted Images

Clicking on Systemlog makes safari go spastic.

Do you mean the Log button on the menu bar, the System Log utility on the Utilities menu, or something else?  Also what version of Safari are you using?

 

System log Utilities menu, has a refresh rate of 1 sec by the looks of it.

 

Safari - 6.0.5

There shouldn't be any refresh of that page at all... possible some other plugin is doing this?

 

The APC UPS plugin is acting up.  When I installed it and re-booted I got this constant refresh.

Link to comment

Will this new SF integration into the release be selectable (as in you must install the .plg) so those that do not want SF can still run the stock GUI?  No offense to Speeding_Ant and all the others that have put in time on this, but I do not want a pretty look prone to issues on a device I need to be simple and 100% functional uptime.

It's not the pretty UI in and of itself that causes problems. It is the fact that SimpleFeatures was developed separately from the rest of unRAID. Now that Tom is in charge of this new UI, it should stay in sync with updates to unRAID. Perhaps more importantly, it should be "officially supported" and Tom is on the hook for compatibility/stability issues related to it. This is a good move forward.

 

+ 1. There is no service, or anything else in this new GUI that causes instability. It is largely based off the 'stock' GUI code, but has some styles to improve the look.

 

You'll end up with a better experience, as Tom can now make changes to the GUI when he needs - and it'll be included with each version of unRAID.

 

Cheers!

Link to comment

some quick notes, thought vomit.

 

the zebra striping on the tables should be reversed, aka dont start with white. why? because the boot device table is only going to have one item.. thus it looks odd the table break being the same white..thus it appears to just be floating vs part of the table. the array devices table have a darker footer.. so a white ending row there works fine.

 

you put a border color for the table header/footer..but not the actual rows.. -- just putting a border on the left/right side (then the last item has bottom as well) would 'complete' the look..

 

the spinup/down icon seems a bit close to the drive label.. could see accidental clicks happening.. why can i spin down disk thats not installed? (could also desaturate the icon to give it a disabled look)

 

main page, changed the image type to 'dimmed' and notice the missing image, 'http://husky/plugins/webGui/images/green-blink0.gif' for all my drives -- also the popup for the drive ball colors needs some more.. fontsize/image bg transparency color/etc

 

when clicking on 'log' on the menu, the font size used for that page seems un-necessalry tiny... the syslog page looks good.

 

table content starts on the same left margin as the page header and menu.. but have a margin on the right side for the scroll bar.. this makes it look a little odd.. looks like this one is going to be addressed in r3 already

 

in your setting page, hard resizing your 48x48 images down to 16x16 looks a bit rough, maybe 24x24 will look better (since its size/2).. however really you are better off making a proper resized image rather than relying on the browser to do the scaling for you.. but I understand that means more images/larger plugin.

 

now that the ui has jquery.. you really should add tablesorter to the tables so users can sort the content easily. (i see you use the old legacy/defunct one on the plugins page) you really really need to check out Mottie's fork which has been actively developed and has much nicer features..

*plugs* https://github.com/Mottie/tablesorter - demo/docs: http://mottie.github.io/tablesorter/docs/index.html

 

plugin page, the image src for the plugins link to the wiki.. with a link to the wiki image... i would think it should link to the app's homepage? seems like a lot of unneeded traffic to the wiki to get images.. should this not be part of the plugin install so they can be local?

 

plugins page, author column seems a bit tiny for some of these.. plus it doesn't add to much benefit on being able to sort off this.. maybe move this into the plugin description? that way you can give more room to the 'type' column.

maybe use child rows, example of what you could do (notice you can search within it too) -- http://mottie.github.io/tablesorter/docs/example-child-rows-filtered.html

 

plugin page, could really use zebra striping here..

 

plugin page, are all these plugins safe for unraid 4.x? 5.x? some food for thought on handing packages and scenarios to be mindful of: these posts are about unmenu's package installer but would also work here as well: http://lime-technology.com/forum/index.php?topic=27051.msg256168#msg256168 / http://lime-technology.com/forum/index.php?topic=27051.msg256173#msg256173

 

I agree with most of this! I will be working with Tom to ensure the final version of the webGUI is polished.

 

The tables will need to be modified (not a particularly easy feat as they are generated multiple times depending on array status. This is nothing something that should be messed with until thoroughly tested) to work with the jQuery plugins. This may come in a later update.

Link to comment

I do fully agree with PeterB and Dephcon comments above, the new frames-like gui is a real pain, mainly for small screens with low resolutions. You may not believe it but on one of my pc's, with xp, I still use 800x600, with an old crt, and I do often browse unraid gui from it, I know... I know... that almost no users probably use this res. nowadays... and I will not ask you support it. But even browsing it on larger screen honestly I don't like the frames*like gui always taking a lot of screen space for no reason, sorry.

 

I did made a small script to apply some very very simple css changes that fixes it (i.e. remove the frames-like thing, shorten side padding and remove res limitation) for me (even making it reasonable for 800x600, with some wraping for sure, but still reasonable and avoiding scroll):

 

#!/bin/bash

sed -i '/#page-container {/,/}/ s/^[ \t]*position:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*top:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*bottom:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*left:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*right:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*overflow-x:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*overflow-y:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css

sed -i '/#page-container {/,/}/ s/^\([ \t]*padding-left:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^\([ \t]*padding-right:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#header-container {/,/}/ s/^\([ \t]*padding-left:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#header-container {/,/}/ s/^\([ \t]*padding-right:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#template {/,/}/ s/^\([ \t]*min-width:\).*/\1 780px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css

 

WARNING: LIMETECH STRONGLY RECOMMENDS THIS SORT OF HACK DON'T BE ADDED ON GO FILE AS IT MAY BRING PROBLEMS WITH FUTURE VERSIONS!!!

 

(note: if anyone else interesting in testing applying these changes, last 5 lines may be unneeded unless also wanting to browse it on 800x600... just 1st 7 lines get rid of the frames-like gui)

 

Link to comment

I do fully agree with PeterB and Dephcon comments above, the new frames-like gui is a real pain, mainly for small screens with low resolutions. You may not believe it but on one of my pc's, with xp, I still use 800x600, with an old crt, and I do often browse unraid gui from it, I know... I know... that almost no users probably use this res. nowadays... and I will not ask you support it. But even browsing it on larger screen honestly I don't like the frames*like gui always taking a lot of screen space for no reason, sorry.

 

I did made a small script to apply some very very simple css changes that fixes it (i.e. remove the frames-like thing, shorten side padding and remove res limitation) for me (even making it reasonable for 800x600, with some wraping for sure, but still reasonable and avoiding scroll):

 

#!/bin/bash

sed -i '/#page-container {/,/}/ s/^[ \t]*position:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*top:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*bottom:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*left:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*right:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*overflow-x:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*overflow-y:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css

sed -i '/#page-container {/,/}/ s/^\([ \t]*padding-left:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^\([ \t]*padding-right:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#header-container {/,/}/ s/^\([ \t]*padding-left:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#header-container {/,/}/ s/^\([ \t]*padding-right:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#template {/,/}/ s/^\([ \t]*min-width:\).*/\1 780px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css

 

(note: if anyone else interesting in testing applying these changes, last 5 lines may be unneeded unless also wanting to browse it on 800x600... just 1st 7 lines get rid of the frames-like gui)

 

Hi - are you talking about the 'sticky' header?

Link to comment

Yes, it appears like a frames page that's why I called it "frames-like" despite not using frames, but yes, exactly that :)  Btw I did attached a screenshot of it on 800x600 after my small changes, you can see it is ok, and before changes it was a real pain to browse it as top header and the white space at bottom for status did take half screen... Again I recon there should be very very small % of users browsing it on 800x600 nowadays, but even on 1024x768 and similar it is not very confortable as PeterB and Dephcon also said above.

 

Ah, just to add, I did also disabled the banner image as many also commented as it looks really bad along with the new design, just white background is surely a lot better.

 

And one small suggestion: the top left lime-tech logo, I would prefer it to link to the 'Main' tab instead of limetech site (you could link site somewhere else... like on bottom copyright bar...), just because I'm used on many sites to click site logo to go to home/start page... big thing, easy to click to get home... sometimes I click it by mistake intending to go to start page :) but maybe just a bad habit I got from some sites, not sure :)

 

And a small issue I did found on 'Info' on vmware workstation:

System: Intel Corporation - 440BX Desktop Reference Platform
CPU: 00000000000000000000000000000000 - Unknown
Cache: 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB, 16 kB, 4096 kB
Memory: 512 Module (max. 1024 GB)
Network: eth0: 10000Mb/s - Full Duplex
Connections: Zero
Uptime:0 days, 10:33:43

11adwdawdaawdw.png.e631ed4821437cf2c997442c8ac45460.png

Link to comment

wonder if it would be best to just put the boot + cache in the the same table with the array.. just segment them in that one table. vs having 3 separate tables with wasted table headers+spacing.. would reduce quite a bit of vertical space.

Link to comment

In part I understand you zoggy, but I would not go that far asking that, if header and bottom status is not always there, sticky, you just scroll a bit and you should have a lot of space to show whatever you want, like all hdd's (or almost in case of really many) even on small on screens... I think.

 

Btw, one last suggestion, I was to ask that before but didn't wanted to be annoying for something that will probably not be useful for all... but now seeing that a lot of display options got added... would it be possible to add one more option to allow showing temperature for spindown disks? I know that many hdd's will wake with that... but some doesn't, I'm sure that at least wd red ones doesn't as sometimes I manually pool them manually with smartctl.

Link to comment

some random thoughts about package manager.. i prob wont make much sense since i haven't slept yet in 24hrs.. but here i go :P

 

package manager.. dunno if you guys have ever checked out but synology and the 'synocommunity' package solution they have come up with.

https://github.com/SynoCommunity/spksrc

 

discovery wise, showing a 'rss' style feed works pretty well (especially if you tracked the downloads/comments): http://www.synocommunity.com/packages

 

its kinda interesting how it all works together.. combo python+shell based system with some js/html included. packages are really just wrappers that do some logic/setup the env to install the actual package/build the source/do whatever.. there are even scripts that setup other scripts.... 'NZB Config' for example.

 

ideally if we could mimic a well established system like apt-get / nodejs - this would be ideal. especially if it worked from the command line. that way script people could have fun with that.. and if something broke in the ui.. you could have a way to fix it as well.

 

having a github repo that manages a master 'plugin' list (listing the md5/sha with url to packages) with branches for each main unraid trunk.. 4.x / 5.x / 5.x-64 / whatever..  and have the unraid system grab that file on startup and update if needed.

 

you would then yes have to include git with unraid.. but doing that also would allow you to leverage this for other things like version control changes to user files for upgrades? for restoring defaults? for checking out changes.. etc

 

then what about when a user upgrades unraid versions.. 4.x->5.x. plugins prob need to be updated/redone?

 

to do any or all of that stuff is going to take a bit of work.. and lots of thought.

 

now if you are wanting to keep it 'simple', then unmenu's approach as we are just d/ling 'offical' untouched slackware packages (less likely for things to break) with some basic shell script to do any env logic if needed.. works pretty decently.

the problem with unmenu's manager is the lack of dependency control (the package maker has to come up with that and test it.. or just put a note and hope the user reads it)

this makes it all a bit cumbersome to test and ensure things got installed right or in the right order with other packages.

theres a lot of legacy packages in there as well.. really the plugin manager needs some sort of way to segment/key off the unraid version to know whats supported/tested. which i've posted a few ideas about doing so earlier...

then there is the whole point of providing support for languages other than english.. or x86 cpu... and the list goes on and on.

 

 

Link to comment

wonder if it would be best to just put the boot + cache in the the same table with the array.. just segment them in that one table. vs having 3 separate tables with wasted table headers+spacing.. would reduce quite a bit of vertical space.

 

I suspect cache is separate because soon there will be the ability to have a cache pool which means there will potentially be multiple drives in that section, possibly with the option to configure them in a variety of ways...

 

Sent from my Nexus 4 using Tapatalk 2

 

 

Link to comment

I did found a problem, not sure if related to new gui or just a bug on latest rc's and didn't noticed it before? apparently right after starting array I'm unable to do a NOCORRECT parity check.

 

Please anyone else can try these steps and confirm this:

- stop array

- start array

- uncheck "Write corrections to parity disk"

- start parity check

isn't "Write corrections to parity disk" checkbox checked again? (and looking at syslog it is doing a 'check CORRECT')

 

Then if I stop the parity check, uncheck Write corrections to parity disk" checkbox and try again I can't reproduce it again, until stop/start array, that's why I think it only happens on first time we attempt it right after starting array.

 

Edit: I did now tested and can reproduce it on stock rc16c, on both baremetal and vmware workstation, then not related at all with the new gui... you may want to move it to issues... Also note that it doesn't happen after boot (with array auto-start), just after a stop/start as I did mention above.

Link to comment

wonder if it would be best to just put the boot + cache in the the same table with the array.. just segment them in that one table. vs having 3 separate tables with wasted table headers+spacing.. would reduce quite a bit of vertical space.

 

I suspect cache is separate because soon there will be the ability to have a cache pool which means there will potentially be multiple drives in that section, possibly with the option to configure them in a variety of ways...

 

Sent from my Nexus 4 using Tapatalk 2

Winner winner chicken dinner!

Link to comment

I do fully agree with PeterB and Dephcon comments above, the new frames-like gui is a real pain, mainly for small screens with low resolutions. You may not believe it but on one of my pc's, with xp, I still use 800x600

 

+1

 

 

(Personally, all I ever wanted from a GUI was in the 4.7 GUI.  I don't much care for JavasScript enabled browsers.)

 

Link to comment

I do fully agree with PeterB and Dephcon comments above, the new frames-like gui is a real pain, mainly for small screens with low resolutions. You may not believe it but on one of my pc's, with xp, I still use 800x600, with an old crt, and I do often browse unraid gui from it, I know... I know... that almost no users probably use this res. nowadays... and I will not ask you support it. But even browsing it on larger screen honestly I don't like the frames*like gui always taking a lot of screen space for no reason, sorry.

 

I did made a small script to apply some very very simple css changes that fixes it (i.e. remove the frames-like thing, shorten side padding and remove res limitation) for me (even making it reasonable for 800x600, with some wraping for sure, but still reasonable and avoiding scroll):

 

#!/bin/bash

sed -i '/#page-container {/,/}/ s/^[ \t]*position:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*top:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*bottom:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*left:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*right:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*overflow-x:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^[ \t]*overflow-y:/#&/' /usr/local/emhttp/plugins/webGui/css/default_layout.css

sed -i '/#page-container {/,/}/ s/^\([ \t]*padding-left:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#page-container {/,/}/ s/^\([ \t]*padding-right:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#header-container {/,/}/ s/^\([ \t]*padding-left:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#header-container {/,/}/ s/^\([ \t]*padding-right:\).*/\1 5px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css
sed -i '/#template {/,/}/ s/^\([ \t]*min-width:\).*/\1 780px;/' /usr/local/emhttp/plugins/webGui/css/default_layout.css

 

(note: if anyone else interesting in testing applying these changes, last 5 lines may be unneeded unless also wanting to browse it on 800x600... just 1st 7 lines get rid of the frames-like gui)

This is EXACTLY the kind of thing easily done in a Plugin and one reason why the plugin system even exists.  If you know enough about how to edit the css files using 'sed' it's much easier done using a plugin.  All you have to do is define your own 'default_layout.css' file anyway you want and put it in a .plg INLINE file section.  If you find you need more "hooks" in the PHP code (e.g, maybe another DIV or some more class tags) then you can email me and I'll put them into the code.  In the future I will be putting the entire webGui 'plugin' on github (probably) so anyone can make customizations and have them integrated into the stock code.  I really really don't want hacks like this in the 'go' file.

Link to comment

I did it on 'sed' lines just to make it easy to apply on future versions changing only really required lines, not just replacing whole css file by an old patched one that could obviously easily break something... you see what I mean... but I fully understand your idea for not liking "non standard mess" on go file.

Link to comment

I do fully agree with PeterB and Dephcon comments above, the new frames-like gui is a real pain, mainly for small screens with low resolutions. You may not believe it but on one of my pc's, with xp, I still use 800x600

 

+1

 

 

(Personally, all I ever wanted from a GUI was in the 4.7 GUI.  I don't much care for JavasScript enabled browsers.)

LOL I'd go even further.  I just dug out an old server running code from 2006.  The webGui used HTML framesets to make boxes (not to be confused with frames).  Used a simple parser I coded in about 5 hours.  Blazing fast.  Just the vital info - virtually no css or javascript, no jquery libraries and plugins, no dropdown boxes, no accordion affects, etc etc.  But I hear over and over, "your gui looks so old!"  So gotta keep up with the trend to stay trendy.  Oh well that horse has long left the barn, and the barn is now a Soho Loft.  ::)

Link to comment
Guest
This topic is now closed to further replies.