(New / Fixed) Widescreen Package Update
-
Given the large number of changes to the all.css file on 2.1 I doubt it will work there without a separate version of the package.
At least this one doesn't stomp on the menu… :-)
-
Can you make a dedicated 2.0.x package and then modify the next one to be 2.1 compliant Jim??
Just so we can begin to DL it directly from packages ?
-
Just so we can begin to DL it directly from packages ?
I can help on 2.0.x as the zip looks like almost done.
-
Shouldn't be too hard to make, I just lack the time to do it. The tags can be set to allow it to only be shown on 2.0.x, so that's not a problem.
-
Can we get it going then?
It would be a very nice addition to the GUI.
-
The screenshot shows pfsense 2.1.EDIT
First screenshot shows 2.0.3 and second 2.1 ???
Supermule, on what version did you applied the version?
-
2.0.3 and your right the screenshot show 2.1
-
2.0.3 and your right the screenshot show 2.1
I'm looking the code and if it fails to apply the patch, it copies entire file.
I'ts not the best way to do that but maybe it's safer to check pfsense version during install process. -
Good idea :)
You are right about the screenshots. Shows both versions. Maybe it just works but needs some package building help?
-
Good idea :)
Manually applying the diff on 2.1 old snapshot, it looks like build for 2.1 (all.css applies fine)
Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -rub /usr/local/www/fend.inc.orig /usr/local/www/fend.inc |--- /usr/local/www/fend.inc.orig 2013-05-19 00:02:16.520088400 -0400 |+++ /usr/local/www/fend.inc 2013-05-19 00:02:57.222514000 -0400 -------------------------- Patching file /usr/local/www/fend.inc using Plan A... Hunk #1 failed at 3. 1 out of 1 hunks failed--saving rejects to /usr/local/www/fend.inc.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -rub /usr/local/www/index.php.orig /usr/local/www/index.php |--- /usr/local/www/index.php.orig 2013-05-19 00:06:36.901112700 -0400 |+++ /usr/local/www/index.php 2013-05-19 00:07:33.409266200 -0400 -------------------------- Patching file /usr/local/www/index.php using Plan A... Hunk #1 failed at 469. Hunk #2 succeeded at 571 (offset 5 lines). Hunk #3 succeeded at 696 (offset 5 lines). Hunk #4 succeeded at 764 (offset 2 lines). Hunk #5 succeeded at 803 with fuzz 1 (offset 4 lines). 1 out of 5 hunks failed--saving rejects to /usr/local/www/index.php.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -rub /usr/local/www/themes/pfsense_ng/all.css.orig /usr/local/www/themes/pfsense_ng/all.css |--- /usr/local/www/themes/pfsense_ng/all.css.orig 2013-05-18 23:44:52.680977900 -0400 |+++ /usr/local/www/themes/pfsense_ng/all.css 2013-05-19 00:00:43.218025500 -0400 -------------------------- Patching file /usr/local/www/themes/pfsense_ng/all.css using Plan A... Hunk #1 succeeded at 185 (offset -8 lines). Hunk #2 succeeded at 338 (offset -8 lines). Hunk #3 succeeded at 427 (offset -8 lines). Hunk #4 succeeded at 470 (offset -8 lines). Hunk #5 succeeded at 1304 (offset -8 lines). Hmm... Ignoring the trailing garbage. doneOn the other hand some patches almost applies fine on 2.0.3 too
Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -rub /usr/local/www/fend.inc.orig /usr/local/www/fend.inc |--- /usr/local/www/fend.inc.orig 2013-05-19 00:02:16.520088400 -0400 |+++ /usr/local/www/fend.inc 2013-05-19 00:02:57.222514000 -0400 -------------------------- Patching file /usr/local/www/fend.inc using Plan A... Hunk #1 failed at 3. 1 out of 1 hunks failed--saving rejects to /usr/local/www/fend.inc.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -rub /usr/local/www/index.php.orig /usr/local/www/index.php |--- /usr/local/www/index.php.orig 2013-05-19 00:06:36.901112700 -0400 |+++ /usr/local/www/index.php 2013-05-19 00:07:33.409266200 -0400 -------------------------- Patching file /usr/local/www/index.php using Plan A... Hunk #1 failed at 469. Hunk #2 succeeded at 571 (offset 5 lines). Hunk #3 succeeded at 696 (offset 5 lines). Hunk #4 succeeded at 764 (offset 2 lines). Hunk #5 succeeded at 803 with fuzz 1 (offset 4 lines). 1 out of 5 hunks failed--saving rejects to /usr/local/www/index.php.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |diff -rub /usr/local/www/themes/pfsense_ng/all.css.orig /usr/local/www/themes/pfsense_ng/all.css |--- /usr/local/www/themes/pfsense_ng/all.css.orig 2013-05-18 23:44:52.680977900 -0400 |+++ /usr/local/www/themes/pfsense_ng/all.css 2013-05-19 00:00:43.218025500 -0400 -------------------------- Patching file /usr/local/www/themes/pfsense_ng/all.css using Plan A... Hunk #1 succeeded at 185 (offset -8 lines). Hunk #2 succeeded at 338 (offset -8 lines). Hunk #3 succeeded at 427 (offset -8 lines). Hunk #4 succeeded at 470 (offset -8 lines). Hunk #5 succeeded at 1304 (offset -8 lines). Hmm... Ignoring the trailing garbage. done -
So far so good!
Screendumps??
-
Screendumps??
As diff rejects the patch, it will mess up gui anyway.
I've sent a pm to RchGrav asking from what version did he used to update the package.
-
Super! Lets see what he comes back with.
-
BUMP!! Any news of this??
-
-
Whats missing??
-
Hey guys,
That Zip file just represents my brainstorming on the situation.. I know the Diff didnt work.. but I was atleast thinking. :-P I was gonna hand write diffs if that was the only way, thanksfully its not.
but here is where I believe the answer lies… Fix the index.php to remove the hardcoded 2 column code, and we have widescreen.. it doesn't break any of the existing themes.. it actually fixes them and lines stuff back up. :-) Try the patched index.php with other themes.. overlay the files onto a 2.1 install, and try every theme..
The code which is present in that Widescreen.zip link posted earlier is ALL based on the 2.1 code, not the 2.0.3 code.. if you want the 2.0.3 one, I have that one done.. but with the same issues.. just less jquery and less requirements in terms of includes.. and file requirements, but no 2.1 features.
The only other file that needs tweaking is the fend.inc.. and maybe it doesnt.. I'm trying to comprehend some advanced javascript, I think the term is Duck Punching / Monkey Patching, which is rewriting other code at runtime... there seems to be other more simplistic examples of these techniques peppered into the existing theme.
But I believe that if there can be more flexible code that avoids that whole mess, we should just fix the 2 files under the www folder.
Here is the majority of the existing "non wide" code in the index.php, the hardcoded fixes, then some code which scales much better than the hardcoded stuff..
Here is the way the existing official code works to print the 2 columns... But its hardcoded to only 2 columns.
// --------------------------------------------- // Here is the way the existing official code works to print the 2 columns... But its hardcoded to only 2 columns. // --------------------------------------------- if ($config['widgets'] && $pconfig['sequence'] != ""){ if ($colpos[$widgetcounter] == "col2" && $printed == false) { $printed = true; ?> } } else if ($widgetcounter >= $halftotal && $printed == false){ $printed = true; ?> } Here is the way the existing NON WIDESCREEN code works to SORT the 2 columns… Hardcoded, column 1 sorts to column 2 and vice versa. (In the Index.PHP) The Hardcoded columns #col1,#col2 need to go away in index.php.// ----------------
// Here is the way the existing NON WIDESCREEN code works to SORT the 2 columns... Hardcoded, column 1 sorts to column 2 and vice versa. (In the Index.PHP)
// The Hardcoded columns #col1,#col2 need to go away in index.php.
// ----------------Here is the solution to the hardcoded col1 -> col2 and col2 -> col1 sorting.. but this version is still hardcoded to 9 columns. this is the code in the widescreen theme now. This is for testing against the other themes, etc.. "ui-sortable" is used to allow sorting from any to any column.// ----------------
// Here is the "ui-sortable" solution to the hardcoded col1 -> col2 and col2 -> col1 sorting.. but this version is still hardcoded to 9 columns.
// this is the code in the widescreen theme now. This is just proof of concept stuff for testing against the other themes, etc..
// ----------------// ----------------
// Here is the hard coded test code for printing more than 2 columns.. this is a hack.. but it works.. its from the original widescreen package, but I think it has tweaks.
// Its not elegant, but would be a nice pull request for the index.php.
// ----------------Ok, now onto my napkin code solution, untested.. but it looks like it works.. but brackets, semicolons, my brain, (I'm not Notch!) I mean I'll get it done if no one else can, .. but whats the word you guys use .. "bandwidth?" well.. I'm basically working on a Commodore 1650 vic modem that only dials pulse. while my customers sap me for around 50Gb sustained transfer 16 hours a day of IT Problem solving.// ---------------------------------------------
// Now, this code here is STARTING to be on the right track.. and once debugged and working it will print 2 columns or 25 columns across 6 WQXGA monitors..
// This is a "Napkin Code" Loop to Print the Sortable Columns (What I am trying to make work, it should work.. maybe as is, maybe needs tweaks..
// my napkin's runtime compiler was on the fritz, and I ran out of time for the weekend and a few days..
// ---------------------------------------------if ($config['widgets'] && $pconfig['sequence'] != ""){
?>}
// Need a loop here for -> jQuery('#col"+colnum+"').sortable({connectWith: '.ui-sortable', dropOnEmpty: true, handle: '.widgetheader', change: showSave});
// See last javascript snippet on this page[code]
// ---------------------------------------------
// We need a similar loop for dealing with the sorting portion of the code which is hardcoded to 2 columns.. so another loop here of some kind..
// ---------------------------------------------
[/code]I will be the first to say that hard coding line after line after line of the same things and only changing a character or 2 in each line is bad form..but it works for testing, and it needs to be commented as such and fixed..
However, getting that hardcoded stuff into the index.php (or something more permanant) to remove the hard coded 2 column stuff, we can then feel good moving forward knowing widescreen is on a solid foundation.
I am happy to make a pull request with the hardcoded stuff as long as its VERY clear that this is not my idea of the final solution. :-)
What do you guys think? I have to apologize if anything above is repeated, misspellended (heh) or anything that makes what I wrote not make sense.. I'm deliriously tired right now.. but wanted to convey all of that..
Regards everyone,
Richard Graver[/i]
-
Thanks Rich and sleep well! :D
-
I got some more notes… all of this work started with Evgeny Yurchenko's original widescreen package.. It was a down and dirty hardcoded patch.. it was essentially an overlay to pfsense, and not a theme, nor was it a package.. in its previous iteration it was unqualified to remain as a package, It modified pfsenses own personal zones of files, this isnt what a package is meant to be, packages extend pfsense.. if a package modifies pfsense, it has stepped beyond its boundries into the area which makes pfsense feel insecure.. and uncomfortable with it.
I think its easy to see how we wont have wide screen themes until the 2 column hardcoded routines are reworked... its bad form to hardcode something that needs to scale, the only difference between 2 columns and 9 is the number of lines of code.. the hardcoded stuff in the widescreen is not different than the 2 column code. just more of it.
Please read the big post I made above, overlay the widescreen fix onto your www folder, test against all themes, etc.. everything should work.. truth be told some stuff looks better, but some centering is lost.. this had not been overlooked.
Besides the official pull tweaks to index.php and fend.inc.. I dont think its good form to overlay onto the pfsense_ng theme.. Why should it even be a package. This is MUCH NEEDED fixes to the existing layout code, and is really at its core enabling wide themes.. Pay close attention to the way the new code lays out the widgets, all of the padding is consistent, top bottom and sides.. also certain widgets look better now.. the picture widget is centered pixel perfect.
The old widescreen plugin attempted scaling the widget widths.. this was just plain terrible and its gone.. unfortunately the content div still scales like it did in the old widescreen plugin, which is terrible to a lesser degree..
All percentage based scaling has been reworked, and spit polished. except. the right side of the content div is scaling based upon %, Check out the superwide screenshot, looks good? nah.. look at the wasted space.. look at how stuff is not centered in the content area. I tried using padding which scaled, it was worse than float left.. all of this has just convinced me that the width needs to scale to accommodate the number of columns, instead of the columns trying to take advantage of the available space in the content area.
The old widescreen looked like it was having a seizure as it scaled.. all the widgets were refreshing hundreds of times as the width changed.... That is fixed also.
I have a github account, I can do pull requests, etc... I honestly was just as excited as you guys were asking to publish this thing.. I jumped in and said "Look at what I did, I fixed the widescreen." Then as a went deeper and picked it apart I kept finding more and more that needed addressing. I think we are close.. but I'd like to fix the right size scaling / passing problem.. this will also make the other themes that dont scale appear consistently centered right now they push a tiny bit left,.. nothing to get worked up about.. but it can be better.
My final feature was going to be to revert everything to match the standard theme, and have widescreen be implemented as an easter egg to be activated only after entering the konami code on the keyboard. Just slap me now. (Don't think mine wont work like that though. hehe)
Best Regards,
Richard Graver
-
Yes, we want it fixed properly in the base code but at this point it's too late to get it into 2.1, because we need to stop adding features there and ship it.
Once we branch 2.1 off, we'd have no problem accepting this kind of change into HEAD/master (which will become 2.2).
