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.

But this approach almost guarantees problems in the future if those lines themselves get changed; worse: if I change that part of the css file and break it, people complain to me, then what do I do?  Do I have to undo my changes?  What if you're not around to fix it?

Sure, I understand. I did posted it just as a test script for anyone else having same trouble and wanting to try it... I did never even said anyone to add them on go file, but I can just edit my post and remove them to avoid future problems (feel free to remove quotes of it). Btw, what about I just add them on a .plg file that will "hack" normal webgui plugin, i.e. using same sed lines? or you don't really want that sort of hacks even from a .plg?

Sure I understand. I did never said anyone to add them on go file, I did posted it just as a test for anyone else having same trouble and wanting to try it... but I can just edit my post and remove them to avoid future problems. Can I just add them on a .plg file that will "hack" normal webgui plugin, i.e. using same sed lines? or you don't really want that sort of hacks even on a .plg?

Sorry, not trying to "knock down" what you did there.  We're making a lot of effort to separate content from layout, which is what needs to happen to let things adjust for different displays such as a smaller monitor or tablet or smartphone or 110" projector.

No problem, fully understand it.

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.

Nothing wrong with that.  And nothing to laugh at either.  I for one would be a very happy if I had the option to use that GUI.

 

But I hear over and over, "your gui looks so old!"

They might as well say the grep command "looks so old" for what I care.

 

So gotta keep up with the trend to stay trendy.

Hey, you're the boss, you know what's best.  It just gives me the feeling of terrible loss when popular demand wastes your time on the webGui, when you could be playing with serious things, like double-parity, 64-bit builds, etc., etc..

 

 

Hey, you're the boss, you know what's best.

Sometimes what's best is not what sells.  BTW, nice reference, and I really loved Pascal.

We're making a lot of effort to separate content from layout, which is what needs to happen to let things adjust for different displays such as a smaller monitor or tablet or smartphone or 110" projector.

This is a very important statement and glad to hear it from you Tom. This separation will potentially allow for some creative work to be done on the GUI in plugin form. Also glad to see a simple version of simplefeatures becoming the stock GUI.

 

That said, all the commentary about GUI speed is interesting. This new GUI shouldn't slow things down much, especially with modern browsers and modern PCs. What I do find somewhat painful is the fact that emhttp seems to be single threaded and there seem to be all kinds of things that can stall it in the background. If a responsive GUI is considered important, I think optimizing emhttp would go the furthest toward this goal.

...I really loved Pascal.

Me too.  It's what I learned in college in the early 80's.  Now I'm stuck writing COBOL for mainframe and iSeries.

What I do find somewhat painful is the fact that emhttp seems to be single threaded and there seem to be all kinds of things that can stall it in the background. If a responsive GUI is considered important, I think optimizing emhttp would go the furthest toward this goal.

 

I couldn't agree more with this comment. The blocking of emhttp is the single biggest cause of "my server is broken" threads in this forum.... Usually a plugin not failing gracefully, but a poorly written plugin really shouldn't have the ability to take down the entire UI.

Ps... How did COBOL survive and not Pascal?

What I do find somewhat painful is the fact that emhttp seems to be single threaded and there seem to be all kinds of things that can stall it in the background. If a responsive GUI is considered important, I think optimizing emhttp would go the furthest toward this goal.

Right this will be addressed post-5.0.  The plan is to integrate lighty, which won't be difficult.  Work which has already been done in the webGui and which is taking place now will make for a smooth transition, but I can't delay the release for this.

Hey, you're the boss, you know what's best.  It just gives me the feeling of terrible loss when popular demand wastes your time on the webGui, when you could be playing with serious things, like double-parity, 64-bit builds, etc., etc..

 

This is surely why any business needs various teams. One man cannot do everything all the time! Especially not something this complex and diverse. I'm relatively new to unRaid but looking back through the forums and seeing it's timeline, I for one am pleased for Limetech to see people like Tom #2, the moderators and now speeding_ant part of the process, as it can only benefit us, the end users.

 

Lets just hope the business model is financially viable

What I do find somewhat painful is the fact that emhttp seems to be single threaded and there seem to be all kinds of things that can stall it in the background. If a responsive GUI is considered important, I think optimizing emhttp would go the furthest toward this goal.

Right this will be addressed post-5.0.  The plan is to integrate lighty, which won't be difficult.  Work which has already been done in the webGui and which is taking place now will make for a smooth transition, but I can't delay the release for this.

Couldn't have asked for a better response

Ps... How did COBOL survive and not Pascal?

COBOL was to entrenched in older long time businesses and more adopted later because of that.  There is just too much code written in COBOL for it to go away quickly.  Pascal was used in academics but not much in the business world.  Any that would have used Pascal switched to C/C++ and other newer languages.

your welcome screen check box "do not display this again" is not persistent between reboots, fyi.

when i click on syslog, it gets stuck in a webpage refresh. tried with ie and chrome.

What I do find somewhat painful is the fact that emhttp seems to be single threaded and there seem to be all kinds of things that can stall it in the background. If a responsive GUI is considered important, I think optimizing emhttp would go the furthest toward this goal.

Right this will be addressed post-5.0.  The plan is to integrate lighty, which won't be difficult.  Work which has already been done in the webGui and which is taking place now will make for a smooth transition, but I can't delay the release for this.

Great! Glad to hear this is on the roadmap.

 

And agree 100% that this should not delay 5.0 final.

when i click on syslog, it gets stuck in a webpage refresh. tried with ie and chrome.

Read this reply from Tom a couple pages back.

when i click on syslog, it gets stuck in a webpage refresh. tried with ie and chrome.

Read this reply from Tom a couple pages back.

 

this?

4) Log opens in a new tab but doesn't load the page 100%. tails the correct data but in safari the blue progress bar never completes. Works in firefox, running safari 6.0.5.

If you are talking about the "Log" button on the right-hand side of the menu bar, that is the designed behavior (that loading the window never completes).  This is because this window is a "live" window that continuously displays syslog entries as they occur.  For example, Stop/Start the array and you'll see lots of messages.  To abort this just close the window.

 

 

 

 

this is a problem in chrome, if you have a bigger syslog (ie mover logging)  the page never stops refreshing and you cant scroll while its doing it.

your welcome screen check box "do not display this again" is not persistent between reboots, fyi.

actually: no setting is persistent between reboots. Not only the "show Welcome screen" setting but also the banner and the number format settings are back to default when I reboot.

your welcome screen check box "do not display this again" is not persistent between reboots, fyi.

actually: no setting is persistent between reboots. Not only the "show Welcome screen" setting but also the banner and the number format settings are back to default when I reboot.

 

looks like a webgui.conf file is needed.

your welcome screen check box "do not display this again" is not persistent between reboots, fyi.

actually: no setting is persistent between reboots. Not only the "show Welcome screen" setting but also the banner and the number format settings are back to default when I reboot.

 

looks like a webgui.conf file is needed.

I put a copy of this issue in the 5.0rc issues forum so it would not be missed.

I am elated to see the CoreUI of SimpleFeatures being absorbed into unRAID. It is easy on the eyes, and easy to navigate. Here's to a swift integration!. Keep up all the good work Tom. 

 

For changes, any chance on removing the parity size from the array "total size" on the main page?. The array total free/used reflects the array without parity so I would think that the total size should/would reflect this as well.

It looks like we are moving to a skinnable unRaid.  Just install a different skin, and it could be sold by others under a different name.  (with Tom's blessing of course).

 

Am I understanding this correctly?

I applaud the efforts on getting 5.0 out the door. But personally I would hate to see a half baked implementation of a plugin manager get tossed in at the last min. As we'd be stuck with this implementation and it could cause more trouble than its worth to 'fix' the short coming with it. I say remove the plugin manager for now, leave the style changes (fix the glaring issues, update it to be responsive) and call it a day for 5.0. This way we can figure out a proper plugin solution and take our time to make sure things are done right. A good framework goes a long way for the good of the community.