User talk:PanSola

 Welcome to the talk page of a devout follower of Lyssa!

= This user is an Admin = If you require the attention of an administrator, you can leave a message on the Admin noticeboard, which I watch. If you want to definitely make sure I be involved in the issue, leave a note here pointing to the discussion on the Admin Noticeboard.

= Archives =
 * Past mistakes are moved into the /MistakeArchive
 * Other closed issues are moved to /Archive/, /Archive2/, /Archive3/, /Archive4/, /Archive5/, /Archive6/, /Archive7/, /Archive8/, /Archive9/

= Messages =

Sortable QR
that is by far the coolest thing i have seen all week. --Honorable Sarah 00:54, 12 April 2007 (CDT)


 * And I'm surprised nobody has done it on GuildWiki yet, considering we got the Javascript to do it ages ago (before I came back). There's a minor issue with the current version of the script though, making the spacing around the sort button ugly )-:  -PanSola 00:56, 12 April 2007 (CDT)


 * The whole thing also looks better in Chinese, because characters naturally go in the vertical direction. http://guildwars.wikia.com/wiki/MesmerSkillDescriptionChart  Sadly, most of the data is out of date there, as I don't have the energy to keep it updated. -PanSola 00:58, 12 April 2007 (CDT)

Is there anyway we could get a stable sorting algorithm? With such an algo, it would be possible to do multiple level sorts by just doing them one after the other (for example: sorting by attribute and name -> sort by name, then attribute). From the tests I did, this seems to not work right now, which would mean that it is using an unstable sorting algorithm. I couldn't find the piece of javascript implementation we use, but if you can point me to it, I could modify it into a stable sort. --Theeth (talk)   12:55, 14 April 2007 (CDT)
 * Yes it's possible, it's on my to-do list, but it's much slower so I'm thinking of making it an "advanced" option that is not enabled by default. The javascript I am using right now (which isn't the one you guys see) is User:PanSola/sortable_mod.js.  -PanSola 16:06, 14 April 2007 (CDT)

Try this instead of shaker sort. It's a swapless stable quicksort with non-random pivot. That should fix the speed issue of the sorting. (no guaranty on the errorlessness of the code, it's adapted from some C code I have lying around, my JS skills might be a bit rusty). --Theeth (talk)   16:43, 14 April 2007 (CDT)

static void qsort_data(list, comp_func, head, tail) { pivot = list[head]; ihead = head; itail = tail;

while (head < tail) {		while (comp_func(list[tail], pivot) >= 0 && head < tail) tail--;

if (head != tail) {			list[head] = list[tail] head++; }

while (comp_func(list[head], pivot) <= 0 && head < tail) head++;

if (head != tail) {			list[tail] = list[head] tail--; }	}

list[head] = pivot; if (ihead < head) { qsort_data(t, ihead, head-1); }	if (itail > head) { qsort_data(t, head+1, itail); } }

function qsort(list, comp_func) { qsort_data(list, comp_func, 0, list.length - 1); }


 * I thought quicksort with non-random pivot, by definition, has terrible worse-case performances. O(n^2). -PanSola 17:48, 14 April 2007 (CDT)
 * With presorted list, yes, it's O(n^2) operations and O(n) storage (recursion) whereas shaker sort's worst case is O(n^2) operations and O(1) storage, but average cases are much better with quicksort than shaker. Moreover, the non-random pivot is rather easy to fix, I just didn't want to hunt around for JS randomize functions. --Theeth (talk)   18:33, 14 April 2007 (CDT)

I've been working with some sortable tables in my User space when I came across the work you've been doing. One thing I have been trying unsuccessfully to implement is marking specific columns as non-sortable. I saw that you have a template/function call { {weapon qr top}} that implements this but I can not for the life of me find the article to look at the implementation. All attempts to find weapon qr top return no results. Where can I find this article? I also read in one of the posts that you have a work-around for the current javascript stripping out template/function calls from header rows (my second problem). Would you also let me know where to find information on that fix as well? Thanks! --  Glamtre  (Talk) 13:55, 16 April 2007 (CDT)


 * Template:weapon qr top sets certain header cells to be class="unsortable", which then gets processed by the javascript MediaWiki:sortable_mod.js. It's not exactly documented, but hopefully the code isn't too hard to understand.  Let me know if you have specific questions.  As for the tag-stripping, it's a very tiny modification used in sortable_mod.js also.  The original behavior is in, but my sortable_mod.js completely overrides it. -PanSola 02:07, 17 April 2007 (CDT)


 * Thanks for the info. I totally forgot about the Template namespace and I REALLY hate wiki search!  Are there any plans for your updated code to replace the installed class="sortable" code?  I am happy to implement your code in my namespace for testing, but if it works one way for me and other for someone else I consider that a bad situation. --  Glamtre  [[Image:Axe-icon-right.png]] (Talk) 12:41, 20 April 2007 (CDT)


 * I've been working on it. But IE compatibility seems to be a very weird issue. -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 18:45, 20 April 2007 (CDT)

Forgive my ignorance
but what's up with the /Characters/Characters thingie? -->Suicidal Tendencie 23:18, 16 January 2009 (UTC)
 * I don't quite remember myself. Something that has to do with template naming/calling probably.  -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 23:44, 16 January 2009 (UTC)

SMW
Please mark any forms etc. that are not fully tested as "experimental", and putting a big red "DO NOT SAVE" on them would be a good idea as well. See [ here]. Also, the fact box at the bottom did appear briefly for some and caused confusion. -- ◄mendel► 10:57, 6 February 2009 (UTC)
 * Um, the warning already went up before you posted that note... ~_~? -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 18:17, 6 February 2009 (UTC)
 * I even removed the entire Save button... -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 18:18, 6 February 2009 (UTC)

#ImageUploadBody
Could you kindly talk changes that create 30k jobs over with somebody else first, please? The issue you mean to fix still persists: if I choose a license now, the "insert file" button is no longer visible, on FF3. -- ◄mendel► 06:27, 11 February 2009 (UTC)


 * Two minor quibbles with your statement:
 * If an issue "still persist", then it's incorrect to use "no longer" to describe the issue.
 * The "insert file" button issue is not related to the action that created 30k jobs.
 * -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 06:35, 11 February 2009 (UTC)
 * Well, you've not explained what it is related to (or I haven't found it yet); I just assumed that twiddling with the dimensions of the table as displayed was all related to the same issue. "No longer" refers to "it is visible until I select a license" and then I have to realize that "hide license text" will bring it back.  -- ◄mendel► 06:56, 11 February 2009 (UTC)
 * Ah ok. Yes, the "if I coose a license now, the "insert file" button is no longer visible" has been a bug.  My edits to Common.css was meant to fix it, but I overlooked the fact that the WMU css gets loaded after our CSS, so my original changes failed to take precedence and didn't actually fix the issue (I just used firebug to figure out what rules were needed, without immediately going back to check the CSS changes behaved as expected since I don't want to get frustrated by waiting for server-side CSS cache to updatee).  The edits to the license table was not related to the "insert file" button issue, though my decision to make the edit was related -- while debugging the scrolling stuff around ImageUploadBody, I noticed the table is constricted to 800px, which I felt was unnecessary and forces horizontal scrolling in the uploader UI.  I found no real good reason to keep it at least 800px wide (or at most 800px wide), thus I edited that out.  But the width of that table doesn't affect the "insert file" button issue in any realistically meaningful way.  -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 07:03, 11 February 2009 (UTC)
 * So what we want is for the pop-up window to either get bigger, or have scroll bars? Or set a max vertical size for the license display and have that get scrollbars? -- ◄mendel► 07:15, 11 February 2009 (UTC) & 07:16, 11 February 2009 (UTC)


 * Giving it scrollbars when necessary is what my edits to Common.css was meant to do. And after you pointed out that the issue persisted, I figured out what's wrong so by now if you refresh your local CSS you will get the scrollbars, when it's needed. -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 07:23, 11 February 2009 (UTC)
 * Well, I get the scrollbars all teh time because there seems to be some whitespace at the bottom of that window. :-P -- ◄mendel► 07:56, 11 February 2009 (UTC)


 * Originally there shouldn't be scrollbars even if there's a mountain at the bottom, due to "Overflow:hidden" in the original CSS rule... o_O" and my first edit didn't work preciously because I failed to take precedence over the WMU.css. The only thing I changed in the second edit was to make the selector more specific to make its rules actually kick in TO generate the scrollbar  By "all the time" you mean since my fix right?  I misunderstood that for the first 60 seconds of replying to you... -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 07:59, 11 February 2009 (UTC)
 * Yeah, "all the time" as opposed to "only when the license text is displayed". -- ◄mendel► 08:09, 11 February 2009 (UTC)

screen
Image:Monaco sidebar.jpg. -- Shadowcrest  02:52, 12 February 2009 (UTC)
 * Oops, ok, the blue *is* something I did. As for the toolbox, what version of IE are you using?  I'll try a few hacks to see if I can get that to behave... -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 03:48, 12 February 2009 (UTC)


 * Alignment *should* be fixed. Is the blue really annoying or is something adjustable?  I really would like to see the search box getting a highlight, despite its high positioning. -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 07:47, 12 February 2009 (UTC)
 * So now you sacrificed the two-column format for the toolbox? Where is the toolbox config page for user page toolboxes? -- ◄mendel► 09:45, 12 February 2009 (UTC)
 * Nope, the number of columns remained unchanged. You can customize your toolbox at Special:Mypage/monaco-toolbox. -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 13:21, 12 February 2009 (UTC)
 * Ok, the deal is this: IE7 shows two columns, firefox shows one. It's been that way in December, as screenshots show, but I swear yesterday I had two columns showing in Firefox as well. What gives? -- ◄mendel► 15:30, 12 February 2009 (UTC)
 * If I can adjust the blue bar to not show, then that's fine.
 * I use IE7. The alignment is indeed fixed, thanks. I still see one column in firefox. --  Shadowcrest  19:49, 12 February 2009 (UTC)
 * To have the blue bar not show, do

background: none;
 * 1) search_box {
 * -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 20:10, 12 February 2009 (UTC)
 * Mendel, that was probably an intermittent glitch. -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 20:10, 12 February 2009 (UTC)
 * I like to think of there just being one column as a persistent glitch. -- ◄mendel► 00:02, 13 February 2009 (UTC)
 * Uh, there being just one column was a legacy feature, from the days when we were narrowing the column down to 160px like Monobook (having two columns at 160px is a little too crowded, besides, the Monobook toolbox is also single-columned). IE having two columns is the bug due to IE's different CSS support.  No one ever brought up the subject that since we are sticking with 200px columns, whether it still makes sense to go single column just to emulate the Monobook look. -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 00:11, 13 February 2009 (UTC)

You heathen
(diff) (hist). . MediaWiki:Monaco-common.css/Narrow-sidebar‎; 22:39. . (-12) . . PanSola (Talk | contribs | block) (→Size tweaking: sacrificing Opera or Safari for IE)

How could you be so cruel :\ (T/C) 07:14, 12 February 2009 (UTC)


 * Cuz I have a fulltime job so I'm used to sacrificing the minorities for the majority. Besides, by "sacrifice" it really means which ever one got sacked gets the same inferior experience as IE (instead of the original superior experience of FF).  This is to ensure IE users don't get a broken experience. -User:PanSola (talk to the [[Image:follower of Lyssa.png]]) 07:46, 12 February 2009 (UTC)