| 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/opac/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=working/Evergreen.git;a=commitdiff;h=c76ab8141d976804f4553a42d1df9330f5fd585b |
| 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/108236131842416283132/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/innovate/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=working/Evergreen.git;a=commit;h=68d50f2678eb6c558623bfd2c764bc51ec789d5f |
| 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/virtualization-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/record/2?query=concerto;qtype=keyword;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/record/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. |
