[16:13] <littlegirl> Hey there, shaunm, there's a bug report that looks like it might want to have you on it. (:
[16:56] <shaunm> littlegirl: link?
[16:57] <littlegirl> shaunm: https://bugs.launchpad.net/ubuntu-docs/+bug/1232708
[16:57] <ubot2> Launchpad bug 1232708 in Ubuntu Documentation "Some GNOME only help showing up in Unity help (13.10)" [Undecided,Confirmed]
[16:57] <littlegirl> shaunm: I've been beating my head on this one. I've tried every possible way I can think of to do conditionals on it and get it to work, but it either displays nothing or displays the wrong text (I use KDE and I see the Unity text when I see any text at all during my tests). It's a stumper. (:
[16:59] <littlegirl> shaunm: I'm not sure if it's mentioned in that report, but the file you want to edit is color-assignprofiles.page and the file that displays it is color.page.
[17:01] <shaunm> littlegirl: so I did notice when testing something else that universal-access-menu.png and view-fullscreen-16.png are missing
[17:03] <littlegirl> shaunm: Oh! In that document?
[17:04] <shaunm> yes, they're both referenced from pages, and not inside conditionals
[17:04] <littlegirl> Ouch, that needs to be added to that bug or a new one needs to be made. I'll make a note of it right now and look into it, and if there's no bug and I can't fix it right away, I'll write it up as a bug. (:
[17:05] <shaunm> it is noted in that bug
[17:05] <shaunm> comments on that bug seem to mention a lot of issues. not sure what the root issue is
[17:09] <littlegirl> Ah, okay. Well, the one I was working on that would interest you is the conditional inside the <info> tag. I can't get it to behave properly no matter how I code it (whether I do it inside the <desc> tag or outside of it or whether I toss some of the code outside of the <info> tag entirely.
[17:09] <shaunm> "The if:choose element can occur in any general block context"
[17:09] <shaunm> http://projectmallard.org/if/1.0/if_choose
[17:09] <littlegirl> Yep, and I'm not sure if <info> qualifies as a block or not. (:
[17:09] <shaunm> it does not
[17:09] <shaunm> a block context is somewhere you could put a paragraph
[17:09] <littlegirl> Ah, okay, so is there a way to do a conditional inside an <info> tag?
[17:10] <shaunm> not at this time
[17:10] <littlegirl> Yeah, that's what I was starting to figure, and since <info> is invisible, it can't hold a paragraph.
[17:10] <littlegirl> shaunm: Could it be hacked by doing the conditional outside of the <info> tag entirely making the conditional point to two <info> tags, one of which gets chosen if the condition is satisfied?
[17:11] <littlegirl> I know that would be a sloppy hack, but it would get the job done if it's allowed. (:
[17:15] <shaunm> that won't work either
[17:15] <shaunm> I'm afraid there's just currently no way to do what you're trying to do
[17:15] <shaunm> do you actually use the same set of page files when users are running under gnome?
[17:17] <littlegirl> I think so. I didn't write the page, and I'd have to study it thoroughly to see what can be done. I'm sure it can just be rewritten to tell the user what would have been automated by the conditional. I'll take a good look at it and see if I can at least sort that part out. Then I'll go after that bug and see if I can't get whoever put all the sloppy additions into it into separate bug reports. (:
[17:23] <shaunm> it would probably help to start using version attributes and strict validation in yelp-check
[17:23] <shaunm> unfortunately, there are some road blocks to doing that
[17:24] <shaunm> I've solved those road blocks, but you won't see the solution until my patch is accepted in libxml2 and a new version is packaged :(
[17:25] <shaunm> you can always still use the version attribute without strict validation to get better validation of your conditionals. you just won't have anything tell you when you forgot the version attribute
[17:25] <littlegirl> It's currently pretty common to use the command (or a variant of the command) in the check_validation.sh file, which uses xmllint. Nobody on the doc team has ever suggested using yelp-check to validate the files. I tried it in the Ubuntu docs the other day and there are some issues that will need attention, and as soon as I get another issue sorted out I'll go after them with yelp-check. (:
[17:26] <littlegirl> Does that mean in your new version (which sounds exciting!) there will be a way for those conditionals to happen?
[17:26] <littlegirl> Or just that there will be a way to find out that a bad conditional was written?
[17:28] <shaunm> you'll just know when the conditionals were written wrong
[17:28] <shaunm> for those sorts of conditionals to work, we'll need a new version of conditionals on projectmallard.org
[17:28] <shaunm> which can happen
[17:29] <littlegirl> Cool. No hurry, though. I love your work, and would never want to do anything to make you frustrated with it. (:
[17:29] <shaunm> for validation, the core mallard schema is intentionally very forgiving whenever it sees anything outside of the normal namespace. so when you use an if:when element just about anywhere, the schema basically says "I don't know what this is, so I'll just assume it's right"
[17:30] <shaunm> that's the schema that's used by yelp-check if you don't use a version attribute, and almost certainly what your validation script uses
[17:31] <littlegirl> Yep. All of those just get quietly ignored. At least all the variants I tried when I was doing if:choose, if:when, if: test, etc., etc., etc. in an attempt to get it to do it. I finally gave up and hunted you down. (:
[17:31] <shaunm> but you can set the version attribute on the page element to tell the validator to load in schema plug-ins. if you load the plug-in for conditionals, then when the schema sees if:when, it does know what it is, and it actually checks if it's correct
[17:33] <littlegirl> I'm not that advanced in the use of Mallard yet to fully understand that, but I'll do my best to learn those. I'm still digging through all the documentation I can find on Mallard and writing up my own personal reference, and I'm not up to plug-ins yet. (:
[17:33] <shaunm> here's a good example: yelp-check validate color-assignprofiles.page
[17:34] <shaunm> that passes, even though the conditionals are wrong
[17:34] <shaunm> edit that file and put the attribute version="1.0 if/1.0" on the page element
[17:34] <shaunm> re-run the command. witness the glory of validation errors
[17:35] <littlegirl> Interesting. yelp-check validate *.page doesn't turn up any issues, either.
[17:36] <shaunm> that's good. that means that everything that's in the normal namespace is correct
[17:36] <shaunm> but it's not checking anything in if/1.0 or ui/1.0 or experimental or experimental/ui
[17:37] <littlegirl> Ooooh, then I get: color-assignprofilestwo.page:5: element page: Relax-NG validity error : Expecting element title, got info
[17:37] <littlegirl> color-assignprofilestwo.page:5: element page: Relax-NG validity error : Element page failed to validate content
[17:37] <littlegirl> color-assignprofilestwo.page fails to validate
[17:37] <littlegirl> Oh, I forgot to mention that I created a color-assignprofilestwo.page so I could leave the original one alone, and the two page is the one I put the version attribute into. (:
[17:38] <littlegirl> So if I add that version attribute to all the pages they can be tested with yelp-check from now on?
[17:39] <shaunm> they'll be tested much more strictly with yelp-check, yes
[17:39] <shaunm> there's no need to do it on pages that don't use conditionals
[17:39] <shaunm> though it doesn't hurt
[17:40] <shaunm> files-copy.page uses the ui extension, so you could use version="1.0 ui/1.0" there
[17:40] <shaunm> or even version="1.0 if/1.0 ui/1.0"
[17:40] <littlegirl> These are the ones that are currently used, with line 7 being the one in the check_validation.sh file, but I prefer the last one: http://paste.ubuntu.com/6348233/
[17:41] <shaunm> oh, one caveat: unless you've installed local copies of the schema and done black magic with xml catalog files, yelp-check will hit the internet to put together the schema for validation
[17:41] <littlegirl> It slips right past all of those, though.
[17:42] <littlegirl> That's okay. This is for the Ubuntu docs, and it should do that so that it's always up-to-date. On my local documentation, in which I'm converting all my personal documents to Mallard, I'll stick with xmllint.
[17:43] <shaunm> there is a package you can install that gives you a local copy of the 1.0 schema and does the xml catalog black magic for you. but it only contains finalized specs, and conditionals isn't finalized yet
[17:43] <shaunm> and I don't know if it's packaged for ubuntu
[17:43] <shaunm> we should finalize conditionals soon
[17:44] <littlegirl> It is, but I didn't install it.
[17:44] <littlegirl> Will  version="1.0 if/1.0 ui/1.0" cover all eventualities and be a blanket attribute I can just add to all the docs to make it possible to yelp-check them all?
[17:45] <shaunm> it covers everything ubuntu is using now *except* experimental features and embedded ITS
[17:45] <shaunm> there will never be schemas for experimental features, and there's not currently a mallard schema plug-in for ITS
[17:45] <littlegirl> I'm kind of surprised Ubuntu uses experimental features. That's not usually the Ubuntu way. (:
[17:46] <shaunm> gnome does too
[17:46] <littlegirl> Maybe that's why, then.
[17:47] <shaunm> but I kind of need gnome to use them, or else they won't get tested. and the whole point of experimental features is to give them some real-world testing before they get put in a formal specification and I have to support them forever and ever
[17:47] <littlegirl> True.
[17:48] <littlegirl> So the 1.0 in that version attribute will coincide with the 1.0 in xmlns="http://projectmallard.org/1.0/" right? So if the Mallard version changes, the version attribute should follow suit, right?
[17:48] <littlegirl> I'm testing the heck out of links right now. (:
[17:49] <shaunm> if the Mallard version changes, you'd change the version attribute, but not the xmlns
[17:49] <shaunm> unless it changes to a backwards-incompatible 2.0, which I have no plans on any time soon
[17:50] <littlegirl> So you just leave the xmlns at 1.0?
[17:50] <shaunm> yeah, I probably should have named the namespaces just 1 or even 1.x
[17:51] <shaunm> if you change namespaces, you basically have to rewrite all the tools
[17:51] <littlegirl> There are all kinds of philosophical discussions out on the internet on how to number software. I think it's six of one, half a dozen of the other when it comes to which way is best. (:
[17:52] <shaunm> I followed soname naming conventions, which was probably a mistake because only C programmers understand it
[17:52] <littlegirl> For my personal uses, I'll use it "out of the box" rather than bolting anything onto it. For Ubuntu, hopefully there are others who know how to do the fancy stuff so that can be updated properly. I've already seen some neat stuff (like mouse-over actions) that I don't yet know how to do, let alone maintain. (:
[21:15] <moewe11> neither chrome nor firefox let me edit the following wiki entry
[21:15] <moewe11> https://help.ubuntu.com/community/Howto%3A%20Custom%20keyboard%20layout%20definitions
[21:15] <moewe11> All I get is: "The address wasn't understood". Seems to be the colon in the URL which throws off the browsers