Evergreen ILS Website

IRC log for #evergreen, 2013-09-24

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat

All times shown according to the server's local time.

Time Nick Message
01:01 hopkinsju joined #evergreen
01:05 Mark__T joined #evergreen
01:46 RBecker joined #evergreen
06:20 kmlussier joined #evergreen
06:51 kmlussier joined #evergreen
06:53 RBecker joined #evergreen
07:00 timlaptop joined #evergreen
07:50 jboyer-isl joined #evergreen
07:54 collum joined #evergreen
07:55 rjackson-isl joined #evergreen
08:03 akilsdonk_ joined #evergreen
08:06 Dyrcona joined #evergreen
08:21 Dyrcona Dev. database reload did not happen last night as planned.
08:22 Dyrcona That slows things down a bit today.
08:24 calvinm joined #evergreen
08:28 csharp erg
08:28 * csharp has to get to loading a fresh PINES db image and upgrading to 2.5
08:32 mrpeters joined #evergreen
08:43 * dbs pokes theory...
08:45 Dyrcona practice pokes dbs... ;)
08:45 dbs I've been fixing a lot of outright bugs and deficiencies in the overall TPAC as part of the mobile TPAC branch
08:45 Dyrcona dbs++
08:46 atheos joined #evergreen
08:47 pastebot joined #evergreen
08:49 Shae joined #evergreen
08:50 bshum dbs: I just saw the numerous new branch changes
08:51 bshum About to go do a clean build
08:51 bshum Give me a few minutes :)
08:51 Dyrcona speaking of mobile-cat-hacking.
08:51 Dyrcona I get a conflict in search.tt2 when merging into clean master.
08:51 mmorgan joined #evergreen
08:52 Dyrcona I wonder if the change from <td> to <div> on line 58 was intentional.
08:52 Dyrcona or, did some other branch that went into master in the meantime change it from <div> to <td>?
08:53 tater joined #evergreen
08:55 bshum Dyrcona: search.tt2 is... where?  Or do you mean homesearch.tt2 or searchbar.tt2?
08:55 dbs Dyrcona: You mean the boolean branch?
08:56 * dbs has not looked at the boolean branch for a long time; mobile-cat is based off of master from about a week ago
08:56 Dyrcona I mean Open-ILS/src/templates/opac​/parts/advanced/search.tt2 an it has nothing to do with the boolean branch.
08:56 Dyrcona I may have the wrong line number.
08:56 dbs 5128c2d9dd3e
08:56 Dyrcona I'm doing some archeology.
08:57 dbs "De-table the advanced search to allow for mobile resizing" sounds like an intentional change.
08:57 Dyrcona All right, then.
08:57 _bott_ bshum:  I'm guessing parts/advanced/search.tt2
08:57 bshum I think paxed's fix to alter the row size went in later
08:58 bshum To make that more flexible
08:58 _bott_ oh, missed that line
08:58 bshum Maybe that's where the conflict is changing
08:58 bshum *occurring
08:58 _bott_ that would be mine, and it was a mess, so I certainly could have over div'd
09:02 dbs _bott_: no, that's a normal result of master changing underneath our branch
09:02 bshum Hmm
09:02 dbs bshum is exactly right
09:02 paxed REBASE ALL THE BRANCHES!
09:02 bshum The addition of colspan there could be tricky
09:03 dbs yeah. in my (extreme) opinion, we should just revert that change
09:03 dbs (paxed's, that is)
09:04 paxed if it's going to be non-table layout, then it should be removed.
09:05 Dyrcona IMHO, it should be fixed in the mobile-cat branch if that is where the de-tablification is taking place.
09:05 dbs paxed: yeah, that's what was happening
09:06 paxed Dyrcona: {row,col}span is a bit annoying to do when using divs for layout instead of tables...
09:06 dbs Dyrcona: Of course. But also IMO the "oh we're scared of mobile OPAC" faction shouldn't be merging any further changes to the TPAC without looking at the mobile OPAC branch first.
09:08 kbeswick joined #evergreen
09:09 Dyrcona Who's afraid of Mobile OPAC?
09:10 dbs What I took away (albeit via Hangout) at the hack-a-way from dbwells was that it was not welcome for 2.5.
09:12 Dyrcona I only care what I should do to resolve the conflict with master. Should both opening <div> tags be there?
09:12 dbs Dyrcona: you shouldn't do anything.
09:13 Dyrcona I'm trying to merge it into my development branch at someone else's request.
09:13 dbs The whole commit needs to be reverted. And I'll do that, and create a new mobile-opac branch, because that's the only way.
09:14 rfrasur joined #evergreen
09:14 Dyrcona I disagree with the part of that statement after because, but anyway, I'll await the new branch.
09:17 dbs collab/dbs/mobile-cat-hacking
09:17 tspindler joined #evergreen
09:17 dbs Dyrcona: creating a new mobile-opac branch is the only way
09:18 Dyrcona The only way to do what? It isn't the only way to revert a commit from the branch and still have it usable by others, i.e. without force pushing.
09:18 dbs I suppose I could put a patch file somewhere and tell people to apply it manually, but that would be nonsensical.
09:18 dbs Dyrcona: oh? do tell
09:19 Dyrcona You reverted the commit from master.
09:19 dbs Uh huh.
09:20 Dyrcona I slightly misunderstood. At some point I thought you were talking about a commit in the mobile branch.
09:21 Dyrcona I'd have done it differently, but anyway.
09:21 dbs Right, that's where I put the revert commit. But that's also why I had to create a new branch, assuming that we want that branch to apply cleanly to master.
09:21 Dyrcona Now, I have other conflicts not related to master to sort out.
09:22 dbs Dyrcona: if there was a different way that wouldn't mess up everyone else's work on the collab/bshum/mobile-cat-hacking branch, that would be good to know.
09:23 ericar joined #evergreen
09:24 Dyrcona Gonna make an omelet; you're likely to eat a few shells. :)
09:25 rfrasur y'all are awesome.  just saying.
09:26 bshum dbs: Hmm, so I refreshed theory and now realize that we have two links to advanced search in the results.  The top portion with searchbar still has a link there, and now we've got the button too.
09:26 bshum I like the button, so maybe this means we just need to figure what to do with the advanced search link / browse the catalog links above in the searchbar.
09:26 bshum Or just hide them.
09:26 bshum :)
09:27 bshum Though I suppose people will want to be able to get to browse somewhere
09:27 bshum Hmm
09:27 dbwells I do wish people would stop speaking for me.  I am not against the mobile OPAC in general, nor am I against working it into 2.5.  I've barely caught my breath at this point, much less had a chance to give the branch a full review.
09:27 dbs bshum: oh yes, conflicting navigation
09:28 Dyrcona I assume it was intended to remove the result_table_format_cell and result_table_liks_cell in Open-ILS/src/templates/opa​c/parts/result/table.tt2?
09:29 dbs dbwells: I was not speaking for you. I was expressing what I thought I heard at the Hack-a-way. And what I thought I heard was that you didn't want to have the mobile OPAC in 2.5 because you were worried about all of the changes to the TPAC in general.
09:29 dbs s/what I thought I heard/what I thought I heard you say/
09:30 dbs bshum: yeah, the button had been being hidden by the nth-child(2) line of CSS. If we don't want the button, we should just remove the HTML for it outright.
09:30 dbwells I am a methodical kind of guy, and anything I said at the Hack-a-Way was not specific to the mobile OPAC.  I think it is fair that any feature branch is going to get extra scrutiny at this late stage.
09:32 dbs dbwells: sure. It's just evident that the TPAC is still pretty terribly flawed; although much of the inline CSS has been moved out, there are still tons of explicit width statements, etc, that are becoming particularly evident as more mobile devices come into play.
09:33 bshum Dyrcona: I think so.  Or at least there's commits in the mobile branch that seem to support that change.
09:34 bshum I'm double checking
09:34 dbwells My suggestion specific to the mobile OPAC were also directed more generally at any other new features, and that suggestion was that if a feature is concise and contained, it is less risky to include it.  From what I have gathered since then, it doesn't sound easy to contain the changes which were made.  That still doesn't exclude from 2.5, it just means we need to be even more diligent in the review process.
09:34 bshum Might have been a typo
09:35 Dyrcona bshum: That's what I thought. I get a weird conflict there, probably from local customizations.
09:35 Dyrcona It shows head having code and mobile being empty.
09:35 dbs bshum: Dyrcona: context?
09:35 bshum http://git.evergreen-ils.org/?p=worki​ng/Evergreen.git;a=commitdiff;h=c76ab​8141d976804f4553a42d1df9330f5fd585b
09:36 dbs That was intentional
09:36 bshum So in that change, the class is set as "result_table_title_cell" but the referring pieces are for format
09:36 bshum But we might just be reusing the class?
09:36 Dyrcona Yes, I gathered. I just wanted to be sure for conflict resolution with our customizations.
09:36 dbs "As a bonus, this enables us to remove one table cell from the search
09:36 dbs results."
09:37 Dyrcona I didn't dig through commit logs for that one.
09:38 dbs bshum: yes, the "title cell" is a long-standing misnomer; it contains lots of metadata
09:38 bshum Yeah, figures.
09:39 bshum Dyrcona: for whatever it's worth, I imagine I'm going to have fun rebasing our local commits with these changes too.
09:39 bshum Stupid more details :)
09:40 dbs My guess is that the sites that have done the most customization are also the ones that most want these changes. Blessing/curse.
09:40 Dyrcona heh.
09:40 bshum Hehe
09:40 bshum You know, dbs, now that I think it over, I'm not sure why there are two links to advanced search on every page.
09:40 bshum One as a button and one as part of the search navigation
09:41 dbs bshum: yeah, and we've always had that. Which is why I wasn't stressing about it.
09:42 dbs bshum: remove the one from the header, and add the "Browse" as a button?
09:43 bshum dbs: I think it'd be easier to go the other way and eliminate the button.
09:43 calvinm joined #evergreen
09:43 bshum But I don't know. Hmm
09:46 bshum Huh
09:46 bshum The advanced search (full size) renders differently in Firefox vs. Chrome.
09:46 bshum In Firefox for me, it seems to put the search inputs to the left of the tabs
09:46 bshum In Chrome, it put them under the tabs as I expected.
09:48 dbs bshum: fair enough (eliminate button)
09:48 dbs bshum: strange, that's the problem that I was seeing before my last commit to add a clear: both;
09:49 bshum dbs: I thought I refreshed to capture that... I'll double check the branch on theory
09:49 dbs bshum: ah, it's there on the initial advanced search tab, but my clear: both fixed the numeric / expert tabs (which is where I saw the problem)
09:50 bshum Ahh
09:50 dbs f6fbea5a4a1cab03e was the relevant commit, but need to fix initial tab too
09:54 dbs bshum: pushed a commit to fix that
09:54 bshum dbs++
09:55 * csharp will throw the mobile OPAC code on a 2.5-ish test server later this week for "production" testing
09:55 Dyrcona It looks good on my Galaxy S4.
09:55 csharp I'll test some today if I get a chance on a vanilla master server, but today is meeting-ful
09:55 csharp theory looks great on my Note 2
09:56 bshum dbs: Works for theory
09:56 csharp I got to brag on y'all to my bosses ;-)
09:57 dbs There are some inconsistencies with Submit button ("Search") vs. Clear Form that we fought with before that raised their heads again last night. Still not pretty.
09:58 bshum I like the new button styles.  Cleaner than they used to be.  Fwiw.
09:58 dbs It really doesn't help that some "Search" buttons don't use an id and therefore vary even from other "Search" buttons :/
09:59 dbs bshum: heh, yeah. gradient + text-shadow is _sooooo_ 2010
09:59 csharp dbs++
09:59 bshum Hmm, are the facets wider than they used to be?
10:00 dbs bshum: they can be, on a screen > 1280px
10:00 bshum Ah
10:00 dbs responsive _both_ ways
10:00 bshum That makes sense now.
10:01 bshum Pretty :)
10:01 * dbs plays with change <a class="opac-button"> to <button class="opac-button"> with good results for consistency on FF and Chrome
10:02 * dbs fears firing up the Windows VM to look with IE
10:02 dbs IE 8 specifically :/
10:02 bshum Ugh
10:02 bshum See, now that you said it, I look with IE10 and my heart sinks a little already
10:03 hopkinsju joined #evergreen
10:04 bshum Mine did weird stuff with the footer and the search bar
10:04 * dbs looks forward to trying it out
10:04 RoganH joined #evergreen
10:05 bshum It took the first two options (search input and type) and threw them down next to the footer
10:05 bshum And then broke the shape of the footer
10:05 bshum That sucks
10:06 dbs hah
10:07 * dbs needs to reboot to enable VirtualBox, back in a sec
10:07 rfrasur (unrelated - I'm always amazed when people that work in libraries complain about having to read instructions)
10:07 rfrasur (the irony)
10:07 bshum Oh man, IE is so terrible.
10:07 yboston joined #evergreen
10:07 csharp @karma IE
10:07 pinesol_green csharp: Karma for "IE" has been increased 0 times and decreased 32 times for a total karma of -32.
10:07 bshum ie--
10:07 csharp ie--
10:08 bshum I mean, extremely bad
10:09 dboyle joined #evergreen
10:10 Dyrcona rfrasur: Heaven forbid you ask anyone to think about anything.
10:10 rfrasur Dyrcona: I'd say you have no idea.....but you do.
10:11 RoganH No good comes of reading.  Wars, revolutions, reading bad.
10:11 rfrasur RoganH: yes...exactly.  Me no read.  Me no think.  Me eat grass and run from the wind.
10:12 csharp @dunno add Fire BAD! Reading GOOD!
10:12 pinesol_green csharp: The operation succeeded.  Dunno #19 added.
10:12 RoganH Reading leads to having new thoughts and thinking about your thoughts.  That leads to questioning.  Obviously no good can come from that.
10:13 * rfrasur smiles at EG & Software Perf Anal email.
10:13 rfrasur nice...yeah, I typed that
10:13 rfrasur analysis
10:13 * rfrasur needs to go home and sleep
10:13 rfrasur (good grief)
10:13 dbs rfrasur++
10:14 * rfrasur hangs head in shame
10:14 * csharp LOLs
10:14 * RoganH thinks that this channel have minds in the gutter.
10:14 csharp RoganH: is the referenced LJ article online?
10:15 rfrasur that's what happens when you read.  bah dum dum
10:15 RoganH csharp: tragically no
10:15 csharp bleh
10:15 rfrasur csharp: LJ makes you subscribed separately to online version
10:15 rfrasur MORE irony
10:15 csharp walled_gardens--
10:15 RoganH but a highly read walled garden
10:16 dbs bshum: IE8 looks terrible in "compatibility mode", actually looks reasonable when it's _not_ in compatibility mode.
10:16 rfrasur RoganH: true
10:16 RoganH If you wait to educate the people that come out of the garden you miss a great opprotunity.  Sometimes you have to take the lesson to them.
10:17 tsbere dbs: So should we add a meta tag for X-UA-Compatible set to "edge" (I think it was) to try and force compatibility mode off?
10:18 rfrasur Hmm, do libraries have to have special permission to copy articles to send via ILL?
10:18 bshum dbs: I think that matches what I'm seeing with IE10 as well.
10:19 rfrasur And RoganH, didn't KCLS say that they were wanting to put back into the EG community?  If I'm remembering right, how can that happen with a fork?
10:19 RoganH Technically you can feed code back with a fork but .... wow it gets hard ... and unlikely.
10:19 RoganH The further from the point of origin you get the less viable it is.
10:20 smyers_ joined #evergreen
10:20 dbs well, if the code is available under an appropriate license, it can be done. but there can be pain, too.
10:20 RoganH They branched off on 2.3 and we're already seeing issues back porting bug fixes that far.
10:20 rfrasur That's what I was thinking...so...
10:20 rfrasur So was the community discussion just being nice?
10:20 rfrasur (hmm, should I have asked that?)
10:21 RoganH I can't speak to their intent obviously.  I think well of the people I know there personally so that's all I'll say.  :)
10:21 * rfrasur nods
10:21 dbs bshum: IE seems to remember "compatibility mode" settings, at least in IE8; so my fresh visit to theory defaults to the desired mode of operation
10:22 dbs But I guess those who have travelled to old versions of our TPACs and chosen compatibility mode in the past will suffer
10:22 dbs tsbere: never heard of it; sounds intriguing
10:23 bshum <meta http-equiv="X-UA-Compatible" content="IE=edge" />
10:23 bshum Is what I found googling
10:23 * tsbere forgot about the IE= part of the content area, but remembered the edge part
10:24 bshum There's probably more involved.
10:25 csharp wow.  just wow
10:25 tsbere I know you can add multiple. Like, say, "IE=7, IE=8" (I think it is via comma, but might be semicolon) to say "grab the highest you can from this list"
10:26 csharp hate to do it, but...
10:26 csharp kcls--
10:26 dbs Safari on Windows likes theory, at least
10:29 dbs Opera on Windows, too. (some JS warnings about dojo, actually, but I don't think that has anything to do with our work)
10:29 ericar joined #evergreen
10:30 dbs https://plus.google.com/10823613​1842416283132/posts/aXX1z3jVkhy (relevant to working with IE)
10:34 bshum dbs: Pretty much.
10:35 dbwells I am trying to catch up with the work being done on the mobile opac branch, but it feels like jumping on a moving train.  How close do we think we are to a resting point?
10:35 bshum You know... I wish I'd known to look for the darned compatibility mode long ago.
10:35 bshum It would have spared me from extra insanity wondering why the catalog looks so stupid.
10:36 bshum And also, why is the icon for it this tiny little thing in the searchbar for IE without much explanation for it being on or off.
10:36 bshum IE--
10:36 bshum GAH
10:37 tspindler Is there a database flag to indicate that an email is invalid in a patron record?
10:38 tsbere tspindler: I believe if you flag an email as invalid it is outright removed and a block (messages tab in the patron record) is added?
10:39 _bott_ Standing Penalty #31 (by default)  INVALID_PATRON_EMAIL_ADDRESS
10:40 dbs dbwells: pretty close to a resting point. I want to improve the advanced-expert search (chrome is wrapping the value: field for some reason) and there are likely a few things we can do for IE
10:40 afterl joined #evergreen
10:43 senator it's exicting to see work taking off on the mobile opac
10:43 csharp mobile_opac++
10:43 senator i'm unclear on why default_adv_select_height has to die... that part's still compatible with responsive design, no?
10:45 dbs senator: relevant commit?
10:45 senator d8ba29e6717a87cf5fc36309165c2802c9f6e061
10:47 dbs senator: I just reverted the entire commit because the colspan/rowspan stuff didn't make sense
10:47 dbs If a single commit was doing two different things, that's unfortunate
10:50 dbs So that part (default_adv_select_height) doesn't have to die. We can keep the templates as crazy complex as we like!
10:51 dbs <meta http-equiv="X-UA-Compatible" content="IE=edge" /> did a nice job of getting rid of the "Compatibility view" button on IE8
10:51 senator i'm certainly for excising the rowspan/colspan parts
10:51 senator i'm wary of steamrolling things in our enthusiasm
10:52 bshum phasefx: The turtle discussion reminds me of this old bug in LP created by SITKA ages ago.
10:52 fparks_ joined #evergreen
10:52 bshum https://bugs.launchpad.net/evergreen/+bug/763944
10:52 tspindler tsbere: that is what I am hearing from others
10:52 pinesol_green Launchpad bug 763944 in Evergreen "a frog would improve usability of transit slip" (affected: 3, heat: 14) [Wishlist,Opinion]
10:52 dbwells FWIW, I thought the ability to specify the height of the advanced search selectors was really helpful, and rather ingenious.  paxed++
10:53 * _bott_ certainly had machete wielding enthusiasm at the hack-a-way
10:53 phasefx bshum: ah, we should at the very least have them reference each other
10:57 dbs Right, I'll revert just the colspan/rowspan part of paxed's commit because it conflicts with the overall direction, and keep the other stuff.
10:57 senator dbs++
10:57 jeff git commit message hall of shame: "latest version" -- 1 changed file with 237 additions and 137 deletions.
10:59 tsbere jeff: I may have to see if I can remember which project I ran into with the commit "changes" with 0 additions and around 800 deletions
11:00 dbs jeff++
11:01 RBecker joined #evergreen
11:02 bshum phasefx: Yeah it took me a bit to find it.  For some reason I thought it was a rabbit slip :)
11:03 dboyle_ joined #evergreen
11:04 phasefx bshum++
11:09 phasefx is there any code that actually calls open-ils.actor.invalidate.email, maybe external to EG? (I don't see any within EG)
11:10 senator phasefx:  Open-ILS/web/js/ui/default/actor/user/register.js  around line 1930
11:11 phasefx ah, no wonder my grep-fu missed
11:11 phasefx senator++
11:14 dbwells dbs: bshum: I would be happy to dedicate as much time as it takes to review (and hopefully merge) the mobile opac branch late this afternoon (say, 4pm or so).  Does that sound realistic, or would you like more time than that?  I am trying my best to balance everyone's desires in getting to beta in a stable, timely, feature-ful fashion.
11:19 kbutler joined #evergreen
11:23 dbwells Also, regarding the brief discussion about removing the extra "Advanced Search" (link vs. button),  I am very much in favor of revamping that aspect of the catalog, but I also think that's a good example of something I would much prefer be handled outside the mobile OPAC review/merge process.  It is only tangentially related, and has a very broad effect, so I think a change like that deserves a chance for separate conversation and consideration.
11:27 dbs okay, collab/dbs/responsive-tpac is the new collab branch
11:27 * csharp misses working with coffee and refreshments being brought by every 2 hours ;-)
11:27 bshum dbwells: For discussing the removal of the button or otherwise resolving it, I think that's a fair shake.
11:27 csharp calvin++
11:27 dbs dbwells: Well, I'm pretty much done working on this anyway.
11:28 dbs I didn't have time to work on it in the first place, it's something that has badly needed to be done for a long time and I wanted the basics to be in place for when we upgrade next spring.
11:28 dbs It was great to actually have people working on it collaboratively.
11:29 jeff calvin++ dbwells++ remingtron++ many thanks, if I haven't said it already
11:29 csharp dbwells++
11:29 csharp remingtron++
11:30 dbs We could just add options in config.tt2 for showing or hiding the advanced search button in multiple places.
11:30 * bshum shudders
11:30 kmlussier dbwells++ remingtron++
11:30 dbs Turn config.tt2 into another templating layer!
11:30 senator dbs++ jeff++ bshum++
11:30 senator if these commits that represent a different concern can be picked out into a different branch,
11:31 senator i can offer reviewingness on that one
11:31 csharp @karma everybody
11:31 pinesol_green csharp: Karma for "everybody" has been increased 5 times and decreased 0 times for a total karma of 5.
11:31 csharp everybody++
11:31 senator to help keep it all clean and orderlylike
11:31 dbs senator: take a look at the 68 commits, probably 30 of them could be separate concerns
11:32 dbs That's the problem that we face. We were worried about how few commits were going in for 2.5? If you want to slow it down, take the work that a bunch of people were hyper-focused on and break it up into separate review units.
11:34 dbwells dbs: Thanks for helping take the lead on it.  I think what you and your group was able to accomplish was incredible.  If you were feeling pressure to not be working on it, and therefore trying get as much done in a short time as you possibly could, then my attempts to slow things down a bit must be all the more frustrating :)
11:34 senator i don't remember worrying about that too few commits, but point taken
11:35 senator would two broad branches, one for responsiveness and another for new stuff, be reasonable?
11:35 dbs dbwells: Heh, thanks for being understanding. Most of that pressure comes from me; I'm supposed to be focusing on structured data (schema.org and the like) and full-text search
11:37 dbs senator: I guess I don't know what "new stuff" would be -- is that like 33933062a9 ("Instead of hiding this HTML, avoid generating it in the first place")?
11:37 bshum dbs: New branch looks neat to me.  I went and applied the last commits to theory but I'll have to do a larger refresh to take into account all the stuff that went into master later on.
11:37 dbs bshum++
11:38 bshum But overall, I feel comfortable staying with this and leaving new issues / work as things to do after we get this initial bulk pushed to master.
11:38 senator well, bigger default font size would be in the "new stuff" category to me
11:38 ktomita joined #evergreen
11:39 senator a commit like the one you suggest is cleanup, i suppose
11:39 senator and i would think worthy in either branch
11:39 dbs So... how many people need to discuss "bigger default font size" then?
11:40 dbs I think we had 3 or 4 people in that discussion, each representing different large consortiums
11:40 bshum Well, I think I asked the whole group to weigh on that.
11:40 bshum So that's like 7 people really
11:40 dbwells I think the answer has always been "whoever wants to".
11:40 senator hey, i have young eyes, and i think big fonts look goofy
11:41 senator i'm kidding, obviously. i don't object to the intent at all
11:41 senator but the reviewer is supposed to make sure the implementation matches the intent, among other things
11:41 senator and this is a lot to review
11:41 senator i'm just for breaking it down, and not a lot, just into maybe two broad branches
11:42 dbwells We have no way to know if other people have strong opinions, or even expertise, if the point is not brought up in a widely visible way.  It may be true that nobody not in your group cares, but we can't know that.
11:42 dbs I would argue that those who have been committing have been reviewing (and improving) each other's work.
11:43 senator well of course, and everyone's doing a great job, and this is an unusually strong, collaborative effort
11:43 senator i'm not trying to put the brakes on anything here
11:44 dbs I've got to go get lunch. With the possible exception of experimenting with <button> instead of <a> for .opac-buttons, I think I'm done for a while.
11:44 * csharp refreshes his dev server to test the mobile OPAC
11:45 dbs There's a lot more to be done, but it has come a long way.
11:45 senator but i think our meaningful review/sign-off practices are worth maintaining
11:45 dbs csharp: collab/dbs/responsive-tpac is the latest, rebased on current master
11:45 csharp dbs: excellent
11:45 senator dbs++ bshum++ everybody++
11:47 dbs senator: I think our meaningful review/sign-off practices are worth maintaining as well. Which is why it is frustrating that with two committers in the group + a number of long-time contributors + some new contributors, it feels like this is getting more pushback than "arcane new feature developed and pushed in after a few weeks of nobody looking at it"
11:48 senator it's like we're talking past each other here. i want it to make 2.5. that's why i'm offering to review half if dbwells reviews half
11:50 Dyrcona A propos of nothing: I just saw a disclaimer in a software manual that basically says, "Do not rely on this manual for proper instructions."
11:51 csharp heh
11:51 bshum senator: I don't really feel like we should review the mobile work in pieces.  Lots of what happened was done with the entire experience in mind and I've been finding it hard to say this is exclusively only benefiting one or the other.
11:52 csharp okay, as a tester, are there places I should poke especially hard?
11:52 bshum Even with the font-size stuff, that helps in the main catalog, but it impacted significantly how the mobile view worked as well with regards to how much finnessing we needed to deal with.
11:53 bshum csharp: The big thing I focused on with testing was ensuring that the original functionality was as close as possible.  Especially with regards to the login page, my account areas, advanced search, and results view.
11:53 bshum Those were the four big areas of change I think.
11:53 csharp okey dokey
11:53 bshum Oh, the searchbar.
11:54 bshum The biggest difference visually is the login page I think
11:54 csharp I was regretting not participating in that working group, but that is allowing me to come in with fresh eyes
11:54 bshum I'm still not wholly comfortable with the result there, but haven't come up with the final solution yet.
11:54 csharp (theoretically) ;-)
11:54 bshum The rest shouldn't have been altered significantly to my recollection.
11:55 jdouma joined #evergreen
11:57 * kmlussier updates LP bug with latest branch
11:57 bshum kmlussier++
11:57 * csharp likes the larger fonts fwiw
11:58 * Dyrcona was surprised by it at first, but one of our most frequent requests is to make the font larger.
11:58 csharp yeah "Advanced Search" looks super tiny to me now
11:58 kmlussier +1 to the larger fonts.
11:59 kmlussier I think the only thing I'm unsure about is the larger widths on the facets when you hit 1280.
12:01 dbwells It couldn't be any more different than an "arcane new feature developed and pushed in after a few weeks of nobody looking at it".  It is the #1 most visible feature (the OPAC), and the code has only existed for a few days.  Add to that the timing of trying to get to a stable beta, and these are the sources of the pushback.
12:01 kmlussier For some reason, they're even wider when I look at it on Dyrcona's server. Must be something about the way it mixes with his local customizations.
12:02 Dyrcona kmlussier: Could be. Plus, I loaded before tsbere rebased our customizations with the earlier branch.
12:02 jdouma joined #evergreen
12:02 bshum Yeah, the wider facet is still messing with my eyes too.
12:05 kbutler Have not seen it yet, but I must say our #1 complaint from staff/patrons is that the font is too small. So +1 to bigger default size.
12:06 kmlussier kbutler: If you're interested, you can take a look at it at theory.biblio.org
12:07 csharp kbutler: and if you're using Firefox (23+) you can use "Responsive Design View" in the Tools -> Web Developer menu to simulate smaller screens
12:07 csharp ^^one of the best things I learned at the hackaway ;-)
12:07 bshum kbutler: The sample bibs are mostly music related.  For example, search for "mozart"
12:08 kmlussier firefox_responsive_design_view++
12:08 csharp okay My Account looks pretty much the same to me
12:08 csharp (comparing to PINES production running 2.3)
12:08 csharp nothing worrisome so far
12:09 jdouma joined #evergreen
12:27 * dbs now has yummy grilled cheese in stomach and is feeling less grumpy
12:27 rfrasur dbs++ grilled_cheese++
12:27 csharp grill me a cheese
12:27 dbs tsbere++ # in case I missed giving him karma for the IE meta fix before
12:29 bshum Indeed, tsbere++
12:29 dbs kmlussier: on a 1280px or greater screen, they will grow to the size of the widest facet, up to 50% of the screen size
12:30 bshum that sounds scary
12:30 dbs we could certainly change that to 33% or something. it just seems silly to keep it at a fixed width no matter how wide your screen is.
12:30 bshum Maybe less.  Facets aren't that exciting no matter how wide the screen is :(
12:30 bshum But that's just my opinion :)
12:31 bshum I'm tracking down why some of the tabs are white backgrounded.  I think I've narrowed it
12:31 bshum Probably should be gray shaded
12:32 bshum Specifically I guess it's the selected tab from the advanced search
12:32 bshum Or the selected tab in the my account areas
12:32 dbs bshum: in the past, there was a coloured bar that would go behind all of the tabs, so that the selected tab wouldn't look so strage
12:32 bshum Yeah
12:33 bshum I wonder where that went
12:33 bshum Maybe that's why it looks weird.
12:33 dbwells It's still there on the small screen version.
12:33 dbs #adv_search_parent no longer has a background I guess?
12:35 dbs or needs a height. 3em or something like that
12:35 dbwells The tabs are busting out of the container, probably a non-contained float.
12:35 kmlussier dbs, bshum: The facets is one area where it might be nice to have a fixed width. Even 33% seems a little high. But maybe that's just because I'm used to the narrower column.
12:35 dbs kmlussier: well, the facets have a fixed width in every case
12:36 dbs with < 600px, they're 100%
12:36 dbs with < 1280px, they're 15em or thereabouts
12:36 dbs with > 1280px, they're 640px
12:37 dbs dbwells: true, if your screen is less than 300px wide at the new default font size they will wrap
12:39 dbs at <1280px facet box width == 15em == effectively 210px wide facets at default font size
12:40 dbwells dbs: you're right, they do.
12:40 dbwells I'd advocate for getting those tabs contained using one of the typical methods.
12:40 * dbs wonders how many screens are < 300px wide
12:41 bshum I think we established at the talk about how the original iphone was 320x480
12:41 dbs kmlussier / bshum: if you want to keep the facet sidebar the same, that's fine with me. I thought growing the facets was a useful demonstration of responding in the opposite direction to use up available whitespace
12:41 bshum So that's as far we were going in widths
12:42 csharp bshum: +1 for that being the baseline
12:42 dbs bshum: yep, and pixel densities on many devices result in the display effectively being the same as 320x480
12:42 dbwells I think containing the tabs is our best bet in any case.  There are at least 4 ways to do it, but I am partial towards using "overflow:auto" on the parent when possible.
12:43 bshum dbs: I think it's a good demonstration, just not sure I like doing it with facets.  I was thinking maybe that'd be more helpful for the results data maybe.
12:43 csharp pre-smartphone blackberrys are 720x720/360x360
12:44 csharp not that we think they're sticking around or anything ;-)
12:45 bshum My first phone with data was a Blackberry Storm.  I thought it was so cool.  Till I found out it didn't have built-in wifi options....
12:45 csharp having said that, 360x360's not bad
12:45 dbs bshum: right; currently .result_metadata has width 30em because we wanted to avoid ragged right edges due to extra long titles, right?
12:45 jeff meanwhile, someone at rim feels greatly offended and they don't know why -- "pre-smartphone blackberries" seems like kicking them when they're down. :-)
12:45 bshum dbs: That sounds familiar, yes.
12:46 csharp jeff: ha!
12:46 bshum Haha
12:46 bshum jeff++
12:47 rfrasur jeff++ #funny!
12:52 ElliotFriend joined #evergreen
12:53 dbs dbwells: fyi, tabs escape the header bar in current master and 2.4 too
12:54 ElliotFriend Hey, all! Our library has noticed something peculiar with marking in-house use on checked-out items. It allows the in-house use to be recorded, but the copy remains checked out. Is that how it is intended to work?
12:55 dbwells dbs: good to know
12:55 csharp ElliotFriend: yes - in-house use shouldn't modify the item's status
12:55 dbs my first smartphone, the HTC Touch from 2007, had a 240x320 resolution
12:56 csharp it just creates a record in the DB of "this item was used"
12:56 ElliotFriend csharp: thanks!
12:57 csharp ElliotFriend: the usual use case for that is picking up items left in reading areas and scanning them for usage stats - I'm not familiar with using it for items that are already checked out
12:57 ElliotFriend some of our students bring in their checked-out items and stick them on the reshelving carts. So, the staff marks in-house use and puts it back on the shelf. What's the best way to handle that situation?
12:57 csharp ah - gotcha
12:57 csharp they should probably drop them in the return bin?
12:58 csharp or just do a quick check-in of items picked up at the end of the day
12:58 ElliotFriend agreed. I'm thinking it is more a policy problem than evergreen problem.
12:58 csharp definitely ;-)
12:59 ElliotFriend i've not tried checking in non-checked-out items yet, what happens then?
13:00 csharp ElliotFriend: from my quick test, it puts the item into Reshelving status
13:00 dbs dbwells++ # overflow:auto does the trick
13:01 * csharp has supported EG for 5+ years but has never used it day-to-day ;-)
13:01 * rfrasur uses EG daily and loves it like a child.
13:02 rfrasur (a well behaved child, in general)
13:02 ElliotFriend csharp: thanks! I'll talk it out with the library staff and see where we go
13:02 dbs overflow:auto fixes the missing bar in the widescreen, too.
13:03 csharp ElliotFriend: best of luck
13:03 Dyrcona ElliotFriend: My solution is don't put the carts where students can get to them.
13:04 ElliotFriend Dyrcona: that's a good call! they've always just been posted in the same spot for the past 5+ years, and I don't even know if there's a reason for it haha
13:06 rfrasur so people don't lose their minds.  I moved the "dvds for reshelving" so people would stop walking behind the circ desk and you'd have thought I asked for organ donation or something.
13:06 * rfrasur ponders asking for organ donations
13:06 Dyrcona rfrasur: staff or patron reaction?
13:06 mcooper joined #evergreen
13:07 rfrasur staff.  The patrons loved it.  The staff had to walk out from behind the desk regularly.  It was a learning curve.
13:07 rfrasur (now I can't seem to get them to be behind the circ desk w/ regularity)
13:07 gmcharlt exercise the staff now so that they're less likely to need donated organs in the future?
13:08 * rfrasur also herds cats
13:08 gmcharlt rfrasur++
13:08 rfrasur gmcharlt++
13:09 * kbutler returns from lunch and has a look at the sample catalog.  I really like the responsiveness so far.   :)
13:10 akilsdonk_ joined #evergreen
13:15 * rfrasur wonders if the fever or the carpet cleaning estimate are going to win.
13:15 * rfrasur cheers for the carpet cleaner...but it's a long shot.
13:18 rfrasur kmlussier and RoganH - both of your development projects made it into an EG-IN development survey that went out to members, so we'll have some more guidance/information fairly soon.
13:18 rfrasur guidance from the consortium....information to relate.
13:22 csharp okay - I don't see any obvious problems caused by the responsive-tpac branch
13:24 dbs Pushed that a.opac-button -> button.opac-button change as well to simplify and standardize the button sizes
13:27 gsams joined #evergreen
13:28 dbs _bott_: we'll probably want to wrap those stylesheet content: values in [% l() %] to support i18n
13:29 _bott_ dbs: hrm...  seems like I did originally.  I wonder where I lost that
13:29 rfrasur (carpet cleaner won!  yay!)
13:30 _bott_ holy scroll back.  go away for a bit and miss a lot!
13:30 dbs _bott_: maybe a commit we missed?
13:30 dbs people get excited about the public face of the project
13:30 _bott_ dbs: more likely a commit I missed (i.e. didn't make)
13:32 dbs ktomita: did you send your ssh key to gitadmin@evergreen-ils.org ?
13:33 * dbs needs to confirm that he's actually receiving mail from that alias
13:33 dboyle joined #evergreen
13:34 ktomita dbs: I just did.  I had sent it to Galen since he added it for me last time
13:34 dbs ktomita: ah, yeah, the impersonal email address is better because it will avoid bottlenecks :) I see it now.
13:35 ktomita dbs: will use that from now on.
13:35 gmcharlt it was sent /just/ today -- can I be given the courtesy of having a chance to respond to my email before being called out?
13:36 jeff gmcharlt: didn't take it as calling out -- just recommendation of "use the aliases, that's what they're there for" best practice. :-)
13:37 dbs ktomita: you should be good to go now
13:37 Dyrcona speaking of responsive web...You'd think sites dedicated to Android and mobile phones would have a responsive design, but you'd be wrong in general.
13:38 dbs gmcharlt: yes, I certainly didn't intend to imply that you were a bottleneck - far from it - just trying to ensure that I was able to help out
13:39 rfrasur Dyrcona: that is kinda surprising.
13:39 ktomita dbs: thanks for the help
13:39 gmcharlt dbs: no worries
13:39 ktomita gmcharlt: thanks also
13:40 jeff gmcharlt: sorry for implying that you shouldn't have taken offense at something -- glad all appears cleared up now. :-)
13:43 jboyer-isl So many jokes in my head re: android and minding details. Have to put them away.
13:44 gmcharlt for when a break is needed ... http://www.ordnancesurvey.co.uk/innovat​e/developers/minecraft-map-britain.html
13:46 RoganH gmcarlt: don't post that where my kids will see it, they will decide to duplicate it
13:46 jeff "You wouldn't DOWNLOAD a COUNTRY."
13:46 gmcharlt RoganH: I make no guarantees when they get old enough to be on Facebook ;)
13:47 gmcharlt (of course, by then, we'd probably be talking in turns of a simulation of the entire planet)
13:48 rfrasur jeff: I can already envision my youngest saying "challenge accepted"
13:48 rfrasur between that and Civilization, I'm confident he's practicing maneuvers for world domination.
14:03 ericar_ joined #evergreen
14:03 jeff standards override bodies: entities empowered with the authority to override those portions of standards which make completely no sense.
14:04 jeff (and yes, for some reason i'm dreaming)
14:05 jeff basic things, though... like "SIP2 error detection no longer exists" (technically, the standards override body there was SIP3)... "NCIP over anything but HTTPS should never be implemented", etc. ;-)
14:05 ericar_ joined #evergreen
14:05 jeff (and actually, NCIP over something other than HTTPS could make sense in some areas, it's just annoying and inconvenient at this particular moment.)
14:07 ericar_ joined #evergreen
14:09 ericar_ joined #evergreen
14:09 smyers_ joined #evergreen
14:10 _bott_ dbs: I've got the i18n back.  I see mobile-cat-hacking and responsive-tpac  ...where are you working?
14:10 dbs _bott_: collab/dbs/responsive-tpac now
14:11 dbs per kmlussier's update to bg 1229226
14:11 ericar_ joined #evergreen
14:12 bshum dbs: After bott is done, I'm going to push a tiny tweak to the margin for the tabs.  There's a lower part for 10px that's making the tabs drift above the actual entry below.  If we set that to 0, then it sits neatly on top and gives back the illusion that the tabs are connected to the frame below.
14:13 bshum The gap became more evident once we changed that overflow: auto; and it put the green background there.
14:13 dbs bshum: sounds good. I *knew* someone would obsess about that :)
14:13 bshum dbs: If I can't obsess over trivial little things like that, I don't know what I'd be doing with this project ;)
14:13 dbs bshum++
14:17 jboyer-isl bshum++ #details matter!
14:17 dbs oh, ugh, I'm going to pretend I did _not_ see that inline width:742px in My OPAC stuff
14:17 * dbwells was secretly obsessing about that, but also trying to keep his head down
14:18 kmlussier joined #evergreen
14:19 dbs and width:662px further down. No, I am not seeing these remnants of years past. No no no.
14:20 dbs and floats that are just noise and should be deleted. Delete it all and it looks nice...
14:20 rfrasur bshum++ #thank you for obsessing in public.  End users would notice and complain, not knowing how to fix it.
14:24 kmlussier I was working on a branch to remove that 662px because it was mucking up the alert for an expired card. But I struggled with getting the display right.
14:25 kmlussier rfrasur: My son is a big Civilization fan too. Just bought 2 expansion packs over the weekend.
14:26 rfrasur kmlussier: it's a good game.
14:27 gmcharlt it's a downright threat to global GDP, is what it is! ;)
14:27 gmcharlt one... more... turn...
14:27 kmlussier I played it a few times when he first started playing it, but, unfortunately, I don't have the same amount of spare time as a 12 year old does. :(
14:28 * rfrasur ponders GDP
14:28 rfrasur I keep thinking someday I'll play games.  same issue kmlussier
14:28 bshum I liked the originals best.  Where the world was more flat :)
14:29 bshum "He is intelligent, but not experienced. His pattern indicates two-dimensional thinking."
14:29 gmcharlt bshum++
14:29 rfrasur my children are all smarter than me.  I just look at the pretty pictures and micromanage their lives.
14:30 rfrasur they play cool games and I devise futile ways to leverage that into marketable skills.
14:54 bshum Course right after I push that commit
14:54 bshum I can see there's a hair difference in the mobile view too for the advanced search tabs with the margins not quite right there too
14:55 kmlussier Accidentally went to the Evergreen git repository while still in responsive design mode. Not very mobile friendly.
14:55 yboston kmlussier++
14:55 bshum Hehe
14:55 rfrasur :)
14:56 kmlussier yboston / rfrasur: Do we have a date yet for the DIG hack-a-way?
14:57 afterl1 joined #evergreen
14:57 rfrasur It looks like Friday, Nov. 15 or Mon, Nov. 18, kmlussier.  bshum, you sure you aren't available those days?
15:00 * _bott_ git foo is weak.  Having trouble pushing i18n change
15:01 dbwells _bott_: what's the issue?
15:01 * kmlussier has been trying to prepare for meetings, but keeps returning to responsive tpac branch.
15:01 yboston kmlussier: the two days with the most votes are Friday Nov 15, and Monday Nov 18, with 9 votes each
15:01 _bott_ dbwells:  is this DENIED a perm thing, or an error in my syntax
15:01 _bott_ remote: FATAL: C refs/remotes/working/collab/dbs/responsive-tpac working/Evergreen bott DENIED by fallthru
15:02 kmlussier I've been resizing my window in the My Account area and notice a big gap on the screen when I'm at around 600/700 pixels.
15:02 yboston kmlussier: we can flip a coin, or I can send out a last call for participants right now?
15:02 bshum rfrasur: I didn't select those dates because I've got potential travel conflicts.  But I've been thinking about flying from Boston instead of wherever and sneaking in for at least most of the day.
15:02 kmlussier I'm thinking we may need to remove those account tabs at a larger resolution.
15:02 dbwells _bott_: are you trying to force push?  Haven't seen a DENIED like that before, that I recall.
15:02 rfrasur yboston: We did say we'd send out a second call...so maybe now's the right time.
15:03 rfrasur bshum: rock on
15:03 kmlussier bshum: Does one date look better than another?
15:03 bshum _bott_: I suspect that you've got a conflict because the local branch you're on might no longer be in sync with the rebased branch dbs put in the new collab branch.
15:03 yboston rfrasur: & kmlussier: I'll do that now
15:03 _bott_ dbwells:  no, no force
15:04 _bott_ bshum: I updated after his latest.
15:04 bshum _bott_: Or it's me cause I pushed a new commit
15:04 _bott_ I've got:    Your branch is ahead of 'working/collab/dbs/responsive-tpac' by 1 commit.
15:04 bshum _bott_: So you might need to pull first, then rebase
15:04 _bott_ lemme give it another pull
15:04 bshum kmlussier: Friday might work better.
15:05 jeff git fetch --clay-pigeons
15:05 jeff git pull
15:05 bshum kmlussier: But really, don't let me be the decider :)
15:10 dbwells _bott_: if you can just push it somewhere, anywhere, I will be happy to merge it in
15:11 yboston rfrasur: & kmlussier: just sent out the email about the poll
15:12 rfrasur yboston++ #thank you
15:13 kmlussier Hmmm...This is odd. I moved the css to hide the "My Account" tabs to the max-width: 800px section. Now they never display, even at 1280. What am I missing?
15:13 acoomes joined #evergreen
15:14 kmlussier nm, user error. :)
15:14 rfrasur k all...takin' this annoying, fevered self home to spread joy and contagion on the homefront.  Be blessed and all that.
15:15 Rogan_Ni joined #evergreen
15:21 kmlussier Oh, I see. That gap is caused by the width:742px code dbs mentioned earlier. dbs: are you working on that? If not, I think I'm close to having a branch that would get rid of it and resolve some display issues I've been seeing.
15:22 _bott_ odd.   pushes just fine to bshum's original branch.
15:22 _bott_ ...but probably a lot of diffs now
15:22 bshum _bott_: Yeah I think that's the rebase messing with you
15:23 bshum I'll pull it into the other branch
15:23 dbs _bott_: you probably need to "git checkout -b new_local_branch working/collab/dbs/responsive-tpac" and cherry-pick your commit on it, then push it.
15:23 dbs or what bshum said :)
15:23 bshum But also what dbs said about starting a new local branch
15:23 dbs kmlussier: not working actively, I've got to take the kids swimming
15:23 kmlussier OK, I'll move foward then.
15:23 bshum _bott_++
15:24 bshum Picked and pushed
15:24 afterl joined #evergreen
15:26 _bott_ ok, back to my routine emergencies
15:28 dbwells okay, since no feedback was given, 4:00pm will be last call for changes to the TPAC branch before it gets reviewed (and likely merged).  After that, I will respectfully request that remaining changes for 2.5RC and final be treated like normal bugs and go through the normal launchpad process.
15:29 * bshum grabs his stopwatch.... and... GO!
15:30 bshum dbwells++ # sounds perfectly reasonable.
15:35 stevenyvr2 joined #evergreen
15:37 remingtron yboston: not sure if you saw my note a few days ago, but I updated the wiki page:
15:37 remingtron http://evergreen-ils.org/dokuwiki/doku.php?id=​evergreen-docs:how-to-contribute-documentation
15:46 senator IE and the mobile opac branch...
15:46 senator where are our expectations right now?
15:46 senator or is that what bshum is furiously working on? :-)
15:46 bshum senator: So dbs and I discovered with tsbere's help that the compatibility mode was screwing with the mobile branch horrifically
15:46 bshum We added a meta tag to force it off
15:47 bshum When we turned it off, it looked much better with IE10 for me at least
15:47 senator and all looks pretty good now? i'm only in a position to test with 8, i think, right now
15:47 bshum I think he tested IE8 and it was fine
15:47 bshum senator: http://git.evergreen-ils.org/?p=wor​king/Evergreen.git;a=commit;h=68d50​f2678eb6c558623bfd2c764bc51ec789d5f
15:47 bshum That's the commit dbs put for the meta tag
15:48 senator thanks
15:48 bshum If you toss that on your test system or use theory.biblio.org with IE8 to test; that'd be great.
15:48 dbwells I am on IE9.  It's functional, but with quite a few display regressions.
15:48 bshum I only have IE10 to test with
15:52 jeff free IE test VMs here: http://www.modern.ie/virtualization-tools
15:53 dbwells I can verify that IE10 displays much better than IE9.
15:53 jeff or http://www.modern.ie/en-us/vi​rtualization-tools#downloads for a barely-more-direct link
15:54 kmlussier Ugh! Git problems trying to push to dbs' branch.
15:55 _bott_ kmlussier:  glad it wasn't just me
15:55 jeff is it possible that you are both trying to push things that were originally in another branch?
15:56 jeff you may have better luck checking out the dbs collab branch, cherry-picking your commits, and pushing.
15:56 _bott_ jeff:  modern and ie don't belong in the same url
15:56 jeff (if this doesn't apply, please ignore)
15:56 dboyle joined #evergreen
15:56 dbwells when in doubt, rebase :)  Our repo is smart enough to protect the rest of us from anyone making a major mistake.
15:56 kmlussier git problems resolved. bshum++ #helping me with git
15:57 kmlussier dbwells: I have one small commit I want to add. Will just take me two minutes now that I've resolved my git problems.
15:57 dbwells Well, you have three minutes, so your good :)
15:57 kmlussier My clock is fast. :)
15:58 bshum Hmm
16:01 jeff Oh hey. I just realized. The concept of Standards Override Bodies already exists. We call them Vendors, right?
16:02 jeff (I come to this realization as we are essentially negotiating a likely non-standard NCIP extension with someone else's vendor indirectly via IM and email)
16:05 * bshum takes his hands off the repo (took a few moments to rebase on top of kmlussier's stuff)
16:08 * senator tests ie, listens to that silly clicking sound a lot
16:10 * dbwells imagines the bug report which started that "The instructions said to click the link.  I kept pressing the mouse button, but never got any clicking..."
16:10 senator generally looks good, only noticing two glitches myself so far: green swatch on the right side of the basic search page, and also on the search results page (but not the record detail page). on the search results page, the white background basically ends at the right edge of the initially visible area (the area visible without horizontal scrolling). to the right of that is only green, and long
16:10 senator titlescut off there instead of wrapping
16:10 senator no, i take that back
16:11 senator the titles keep going, but they're green-on-green, so not legible
16:11 senator but they don't actually "cut off"
16:11 yboston remingtron: I have started looking at your changes, they look good. Though I think we should re-add the mention of "root.xml" but referenced as "root.txt" which is actually still used.
16:11 bshum Wait, where does that happen?
16:11 senator search results page
16:11 senator in the search results themselves
16:12 senator if somebody /just/ pushed something to address that, i can refetch
16:12 senator but this was  current code 15 min ago or so
16:12 bshum Yeah it's not supposed to do that anymore....
16:12 remingtron yboston: glad you caught that. Since I'm a newbie, I'll trust your judgment on things like that.
16:12 dbwells senator: on IE9, I have problems with the shelf browser as well.  How does this look on IE8?  https://theory.biblio.org/eg/opac/r​ecord/2?query=concerto;qtype=keywor​d;locg=1;expand=cnbrowse#cnbrowse
16:12 remingtron yboston: I was mostly trying to update git repo related stuff
16:13 yboston remingtron: no problem, what you did really help. I also updated a handful of small things the last night in GRR, and I am glad you tackled this page, because I got sleepy
16:14 yboston remingtron: BTW, I only noticed the root stuff because I did a diff of the last version before you made your changes
16:14 senator dbwells: it requires lots of horizontal scrolling to read
16:14 senator whereas in google chrome it fits the space compactly
16:15 dbwells senator: ok, same here.  So, for any potential fixers out there, it appears IE8 and IE9 have the same regressions.
16:16 bshum dbwells: senator: To my recollection, nobody worked on the shelf browser yet.  So that's one of those dark corners that hasn't gotten mobile love.
16:19 dbwells bshum: that's fine, I was just mentioning that it is also a regression in the non-mobile view in IE 8/9.  A fix can wait for post-beta, but if someone had an idea right away, even better.
16:19 dbwells In fact, it seems like there is a style preventing IE8/9 from wrapping at all.  See the contents note here: https://theory.biblio.org/eg/opac/recor​d/7?query=concerto;qtype=keyword;locg=1
16:20 bshum dbwells: I'll have to try grabbing an IE8/9 to take a look at that.
16:21 bshum With IE10 that looks the same to me.
16:23 collum I did some work on the shelf browser.  It looks good in FF and chrome.  IE 8/9 must handle block elements differently.
16:23 * collum goes to look for his old laptop
16:26 Dyrcona So IE isn't very responsive....
16:27 bshum No IE just sucks in rendering the regular catalog (especially with some of the changes we've made apparently)
16:27 bshum Just got an old IE8 browser going in a VM to look and yeah it's horrible.
16:27 tsbere bshum: s/just sucks.*/just sucks/ ;)
16:27 bshum Hehe
16:31 jeff data point: IE8 is the highest version of IE that can be installed on Windows XP.
16:31 tspindler left #evergreen
16:32 tsbere jeff: Counter point: Windows XP extended support ends in April anyway...
16:34 senator changing behavior on theory.biblio.org makes me thing bshum has or almost has it
16:34 Dyrcona ends... I thought it ended already.
16:36 bshum senator: I haven't changed anything on theory with regards to IE compatibility.
16:37 bshum I suspect that maybe there's some newer CSS declarations that IE8/9 don't work properly with
16:37 bshum Strike that "maybe".... and we'll go with "definitely"
16:37 jeff Dyrcona: 2014-04-08 for the United States according to microsoft.com/lifecycle :-)
16:38 * Dyrcona shrugs. Windows is only good for games. No one could possibly use it for any serious work.
16:38 senator hm, then some behavior may be inconsistent across reloads or something. wouldn't put that past IE
16:38 bshum jeff: Yeah well, I don't think many of our libraries/patrons are actually buying that level of extended support for the lifecycle.  It's been dead for awhile :)
16:38 bshum Dead to me in more ways than one anyways.
16:38 bshum Grr, stupid IE8
16:39 Dyrcona So, forget about IE8, or IE all together.
16:39 senator the shelf browser regression is consistent to me across reloads though
16:39 Dyrcona Yeah, I know our users would howl..... :/
16:40 mrpeters could a security bug wrangler message me privately?
16:41 senator unrelated, does anyone remember an issue long long ago with serials items being deleted upon receiving the next one, or something like that?
16:42 mrpeters thanks guys
16:46 dbwells senator: If you delete a serial item, and deleting that item results in a unit being "empty" (no associated items), that unit is harvested (found and deleted) the next time an item in the same subscription (or maybe distribution) is received.
16:46 dbwells When receiving in the "Serial Control"
16:48 senator right. and reseting an item to expected can also delete units? something else i was finding from hints in the logs and then looking at the code in parallel with your answer
16:49 dbwells senator: right, anything which runs through that sub (unitize_items() or something like that) will trigger that behavior.
16:49 senator right-o
16:49 jeff there was an issue we ran into which we could not fully reproduce. a large number of possibly "incorrectly" created serial units were "cleaned up"
16:49 senator thanks dbwells
16:49 dbwells (not looking at the code)
16:53 dbwells That code was put in place to better support workflows which legitimately needed to move items between units (e.g. binding).  It could certainly benefit from some speedbumps, especially since I completely underestimated the average user's desire to "clean up" their "old" data.
16:55 Tricheta joined #evergreen
16:56 bshum Where the "average user" is a librarian, I'm wary of how much they love tidying the corners...
16:56 bshum ie--
16:56 bshum Not enough bad karma in the universe right now
16:56 Tricheta madre mia donde estoy ?
16:57 kmlussier ie--
16:57 dbs obviously the answer is to do browser detection and redirect people to a fixed-width 1024x768 skin for IE.
16:57 Tricheta left #evergreen
16:58 dbs btw, when I said IE8 was "fine", it was clear there was still some cleaning up to do. But I did not run across anything horribly broken, at least not once we were out of compatibility mode.
17:00 dbs Oh, and by 1024x768 skin, I meant "KPAC"
17:00 bshum Heh
17:02 bshum jeff++ #just downloaded one of those sucky VMs to play with IE8 easier.
17:02 * bshum forgot how much he hated Win XP
17:02 bshum Till just now
17:02 dbwells yeah, I don't think anyone thinks the IE8/9 bugs mentioned so far are showstoppers
17:11 * dbs is out of home office again
17:14 mmorgan left #evergreen
17:15 senator my account login page, chrome...
17:15 senator don't we want questions? and faqs? over to the left if they're below the gray "log in to your account" box ?
17:15 senator see e.g. here https://theory.biblio.org/eg/opac/login?​redirect_to=%2Feg%2Fopac%2Fmyopac%2Fmain  around width 1024
17:16 bshum senator: I think that's a remnant of the original style which is still a right float
17:17 bshum So that breaks now and isn't a condition of the changes to the CSS presently.
17:17 bshum For mobile I mean
17:18 senator ok
17:18 * senator stashes a quick fix for later, but doesn't want to muddy the waters now
17:19 mrpeters left #evergreen
17:28 bshum So weirdly the title a link isn't respecting the div width it's enclosed within for IE8
17:28 bshum The div is fine at the proper width, but the link just sort of hangs out and goes as far outside the bounds as it likes.
17:28 bshum That's just annoying :)
17:36 bshum kmlussier++ #spotting a bug in the searchbar.tt2
17:44 * kmlussier 's children are going hungry while she plays with mopac.
17:44 gmcharlt kmlussier: well, clearly they should be cooking you dinner so that you can continue hacking! ;)
17:44 kmlussier gmcharlt++
17:45 kmlussier g'night all!
17:53 bshum Pushed a quick bug fix for searchbar.tt2 to repair a missing label that was preventing us from using the library selector for scoping search lib.
17:53 bshum Well, causing difficulty rather.
18:03 kbeswick joined #evergreen
18:29 kbeswick joined #evergreen
19:07 dboyle_ joined #evergreen
19:19 sseng joined #evergreen
19:37 dMiller joined #evergreen
19:47 misilot joined #evergreen
19:47 zxiiro joined #evergreen
19:47 jventuro joined #evergreen
19:48 gdunbar joined #evergreen
19:48 eeevil joined #evergreen
19:54 bshum joined #evergreen
19:54 egbuilder joined #evergreen
19:54 rangi joined #evergreen
19:54 artunit joined #evergreen
19:54 depesz joined #evergreen
19:54 RBecker joined #evergreen
19:54 wjr joined #evergreen
19:54 smyers_ joined #evergreen
19:54 fparks_ joined #evergreen
19:54 pastebot joined #evergreen
19:54 Callender joined #evergreen
19:54 gmcharlt joined #evergreen
19:54 book` joined #evergreen
19:54 edoceo joined #evergreen
19:54 pmurray joined #evergreen
19:54 jeffdavis joined #evergreen
19:54 phasefx joined #evergreen
19:54 pinesol_green joined #evergreen
19:54 csharp joined #evergreen
19:54 remingtron joined #evergreen
19:54 senator joined #evergreen
19:54 phasefx_ joined #evergreen
19:54 dbs joined #evergreen
19:54 tsbere joined #evergreen
21:02 smyers__ joined #evergreen
21:03 dboyle_ joined #evergreen
21:05 stevenyvr2 left #evergreen
21:09 afterl left #evergreen
22:02 ktomita_ joined #evergreen
22:03 smyers_ joined #evergreen
22:19 bshum @roulette
22:19 pinesol_green bshum: *click*
23:05 mrpeters joined #evergreen
23:08 stevenyvr2 joined #evergreen
23:12 stevenyvr2 left #evergreen
23:21 ktomita joined #evergreen
23:22 dbs bshum++ kmlussier++ # nice fixes
23:22 dbs Looks like my s/<strong><center>// commit for the IE home search may not have been necessary after all
23:24 hopkinsju joined #evergreen
23:27 dbs Oh well. <center> was already deprecated back in HTML4, it's nice to have it go away.

| Channels | #evergreen index | Today | | Search | Google Search | Plain-Text | summary | Join Webchat