Loading ...
Sorry, an error occurred while loading the content.

Good morning!

Expand Messages
  • markpasc@mindspring.com
    Gooood morning! What kind of thing should I be pointing out? ... The Open option wouldn t work before I ran the install script, so I had to use
    Message 1 of 5 , Jul 27, 2001
    View Source
    • 0 Attachment
      Gooood morning! What kind of thing should I be pointing out?


      > 4) Open radio71preRelease01.fttb, using the Open command in the File menu.

      The "Open" option wouldn't work before I ran the "install" script, so I had
      to use filemenu.open in a Quick Script. (Also couldn't close Radio before
      then, except by hitting ctrl-F4 twice.) Got all the fingers and toes now,
      though.

      The desktop website loads in Opera (and boy, does that look cool =) ), but
      not in K-Meleon, where it just shows the index.txt file:
      "{radio.weblog.view ()}". Seems that's because K-Meleon is very thorough in
      its HTTP Accept header and unlike Opera explicitly says it accepts
      "text/plain", so the code in radio.webServer.responder to "turn off
      rendering if the client specifically supports the type" because
      "Radio-as-a-client wants to get the OPML, not the HTML rendering" means
      K-Meleon gets the unrendered text file. It does in fact work after changing
      K-Meleon's Accept header to not include "text/plain".

      In the weblog editing page, the textareas holding the output templates have
      "<p>" appended to lines that have a blank line after them.

      The <title/> for the Home page is "index.txt".

      Are the menus going to stay like that, where it takes the whole page
      reloading to change the menu?

      In, eg, http://127.1/system/pages/weblog?itemToEdit=550 , in both the HTML
      and the textarea, the edited weblog item has become double-spaced, with two
      CRs at the end of each line, and saving such a double-spaced item saves the
      spaces.

      I see the reason for separate #homeTemplate.opml and #template.txt, but I
      imagine it'd be nice to have a change to one reflect in the other if
      they're supposed to start out the same. Haven't wanted to change either yet
      though.
    • Jake Savin
      on 7/27/01 8:05 AM, markpasc@mindspring.com at markpasc@mindspring.com ... Anything you see that s not working. Anything that s awkward. Anything that worked
      Message 2 of 5 , Jul 27, 2001
      View Source
      • 0 Attachment
        on 7/27/01 8:05 AM, markpasc@... at markpasc@...
        wrote:

        > Gooood morning! What kind of thing should I be pointing out?

        Anything you see that's not working. Anything that's awkward. Anything that
        worked in Radio 7.0.1, and doesn't work now. Any features you want or need
        that aren't there. These are good reports you've sent. Thanks, and keep 'em
        coming.

        >> 4) Open radio71preRelease01.fttb, using the Open command in the File menu.
        >
        > The "Open" option wouldn't work before I ran the "install" script, so I had
        > to use filemenu.open in a Quick Script. (Also couldn't close Radio before
        > then, except by hitting ctrl-F4 twice.) Got all the fingers and toes now,
        > though.

        There's a known bug with enabling commands in the File menu. I've got it
        fixed here, and it will be included in the next set of pre-release changes.

        > The desktop website loads in Opera (and boy, does that look cool =) ), but
        > not in K-Meleon, where it just shows the index.txt file:
        > "{radio.weblog.view ()}". Seems that's because K-Meleon is very thorough in
        > its HTTP Accept header and unlike Opera explicitly says it accepts
        > "text/plain", so the code in radio.webServer.responder to "turn off
        > rendering if the client specifically supports the type" because
        > "Radio-as-a-client wants to get the OPML, not the HTML rendering" means
        > K-Meleon gets the unrendered text file. It does in fact work after changing
        > K-Meleon's Accept header to not include "text/plain".

        Ok, so does K-Meleon's Accept header also include text/html? (My guess is
        that it does.) Radio should clearly place the priority on the HTML version
        of the page, if both MIME types are present in the Accept header.

        > In the weblog editing page, the textareas holding the output templates have
        > "<p>" appended to lines that have a blank line after them.
        >
        > The <title/> for the Home page is "index.txt".

        I noticed this too. I'm still thinking about what to do with it.

        > Are the menus going to stay like that, where it takes the whole page
        > reloading to change the menu?

        So far we've been thinking that they are going to stay like that, but if
        there's something better we can do, I'd like to make the menus faster. Do
        you have any ideas?

        > In, eg, http://127.1/system/pages/weblog?itemToEdit=550 , in both the HTML
        > and the textarea, the edited weblog item has become double-spaced, with two
        > CRs at the end of each line, and saving such a double-spaced item saves the
        > spaces.

        I think I know why this is. It's similar to a problem we had with URLs in
        weblog entries when we were developing MyUserLand.root. I'll get this fixed
        in the next pre-release.

        > I see the reason for separate #homeTemplate.opml and #template.txt, but I
        > imagine it'd be nice to have a change to one reflect in the other if
        > they're supposed to start out the same. Haven't wanted to change either yet
        > though.

        I'm not sure what you mean by this. The templates are (nearly?) identical
        right now. They're both there primarily for testing purposes at the moment.

        Thanks again for the reports.

        -Jake
      • markpasc@mindspring.com
        ... I had to copy my {archiveurl} and {safewhen} (for permalinks) and {categories} pseudomacros from myUserLandSuite.blog.publish to radio.weblog.publish. It d
        Message 3 of 5 , Jul 27, 2001
        View Source
        • 0 Attachment
          At 12:54 PM 7/27/01 -0700, you wrote:
          >Any features you want or need that aren't there.

          I had to copy my {archiveurl} and {safewhen} (for permalinks) and
          {categories} pseudomacros from myUserLandSuite.blog.publish to
          radio.weblog.publish. It'd be wonderful to be able to add that kind of
          functionality without directly editing the publish script (but I guess
          that's one of those 1% features).


          > > not in K-Meleon, where it just shows the index.txt file:

          >Ok, so does K-Meleon's Accept header also include text/html? (My guess is
          >that it does.) Radio should clearly place the priority on the HTML version
          >of the page, if both MIME types are present in the Accept header.

          Yup. K-Meleon's default Accept header is like so:

          text/xml;q=1, text/html;q=0.9, image/png;q=1, image/jpeg;q=1,
          image/gif;q=0.9, text/plain;q=0.8, text/css;q=1, */*;q=0.01

          It may be a matter of supporting the "q=" accept-param thing and seeing the
          browser prefers text/html to text/plain. But that sounds like work, and I
          don't know what other browsers use "q=", though I assume Mozilla does
          (since K-Meleon is like Mozilla Lite for Windows) and it's a "may" in the
          HTTP/1.1 spec.

          It'd certainly be simpler to categorically prefer text/html over text/plain
          (but not everything, or that defeats the purpose for Radio and text/x-opml,
          right?).


          > > Are the menus going to stay like that, where it takes the whole page
          > > reloading to change the menu?
          >
          >So far we've been thinking that they are going to stay like that, but if
          >there's something better we can do, I'd like to make the menus faster. Do
          >you have any ideas?

          Just DHTML dropdowns (insert groaning here), to supplement the current
          method in browsers that would support it. On some of the longer (news and
          weblog) pages, I almost think a separate frame would be better.

          Speaking of that, couldn't the weblog page be a lot shorter if it were
          split into a weblog and weblog settings/preferences page?


          > > I see the reason for separate #homeTemplate.opml and #template.txt, but I

          >I'm not sure what you mean by this. The templates are (nearly?) identical
          >right now. They're both there primarily for testing purposes at the moment.

          Just that I first played with changing #template.txt and had to figure out
          why it didn't change 127.1/ . No big thing. =)


          Twice today Radio's only read parts of items from my own rss.xml feed; the
          first time it was part way through an HTML comment, and this last time it
          stopped in the middle of an <a/>'s title, both with disastrous effects on
          the News page's table. I'm not really sure what to look for, other than
          that the rss.xml locally and on the server are both whole.

          Cool that posting a news item returns to the posted news item's anchor
          instead of just the news page.
        • Jake Savin
          on 7/27/01 2:39 PM, markpasc@mindspring.com at markpasc@mindspring.com ... That s on the to-do list. Basically I want to use html.processMacros there, so that
          Message 4 of 5 , Jul 27, 2001
          View Source
          • 0 Attachment
            on 7/27/01 2:39 PM, markpasc@... at markpasc@...
            wrote:

            > At 12:54 PM 7/27/01 -0700, you wrote:
            >> Any features you want or need that aren't there.
            >
            > I had to copy my {archiveurl} and {safewhen} (for permalinks) and
            > {categories} pseudomacros from myUserLandSuite.blog.publish to
            > radio.weblog.publish. It'd be wonderful to be able to add that kind of
            > functionality without directly editing the publish script (but I guess
            > that's one of those 1% features).

            That's on the to-do list. Basically I want to use html.processMacros there,
            so that people can put whatever they want in user.html.macros, to extend the
            functionality.

            >>> not in K-Meleon, where it just shows the index.txt file:
            >
            >> Ok, so does K-Meleon's Accept header also include text/html? (My guess is
            >> that it does.) Radio should clearly place the priority on the HTML version
            >> of the page, if both MIME types are present in the Accept header.
            >
            > Yup. K-Meleon's default Accept header is like so:
            >
            > text/xml;q=1, text/html;q=0.9, image/png;q=1, image/jpeg;q=1,
            > image/gif;q=0.9, text/plain;q=0.8, text/css;q=1, */*;q=0.01

            Cool, so it looks like we'll be able to tell what type is preferred.

            > It may be a matter of supporting the "q=" accept-param thing and seeing the
            > browser prefers text/html to text/plain. But that sounds like work, and I
            > don't know what other browsers use "q=", though I assume Mozilla does
            > (since K-Meleon is like Mozilla Lite for Windows) and it's a "may" in the
            > HTTP/1.1 spec.

            I'll take a look at the spec, and see if this is standard or not.

            >>> Are the menus going to stay like that, where it takes the whole page
            >>> reloading to change the menu?
            >>
            >> So far we've been thinking that they are going to stay like that, but if
            >> there's something better we can do, I'd like to make the menus faster. Do
            >> you have any ideas?
            >
            > Just DHTML dropdowns (insert groaning here), to supplement the current
            > method in browsers that would support it. On some of the longer (news and
            > weblog) pages, I almost think a separate frame would be better.

            I brought it up a while back, but we decided against using DHTML/JavaScript,
            since there are so many platform differences, which makes it difficult to
            support. I'll think about it some more. Maybe there's an in-between
            solution.

            BTW, you can edit the menu if you want. Take a look at [Radio
            Folder]/www/system/misc/editorsOnlyMenu.opml.

            > Speaking of that, couldn't the weblog page be a lot shorter if it were
            > split into a weblog and weblog settings/preferences page?

            That's already in the plans as well.

            >>> I see the reason for separate #homeTemplate.opml and #template.txt, but I
            >
            >> I'm not sure what you mean by this. The templates are (nearly?) identical
            >> right now. They're both there primarily for testing purposes at the moment.
            >
            > Just that I first played with changing #template.txt and had to figure out
            > why it didn't change 127.1/ . No big thing. =)

            I'm not sure what you mean here. (I'm probably just being dense.)

            > Twice today Radio's only read parts of items from my own rss.xml feed; the
            > first time it was part way through an HTML comment, and this last time it
            > stopped in the middle of an <a/>'s title, both with disastrous effects on
            > the News page's table. I'm not really sure what to look for, other than
            > that the rss.xml locally and on the server are both whole.

            Hmmm. Where was the feed you were reading? Was it dynamically generated by
            Manila? I'm not quite sure what could have caused this.

            -Jake
          • markpasc@mindspring.com
            ... Keen, thanks. Guess I need to poke around in there more. ... Can tell I hadn t looked in Prefs, huh? =) ... I didn t know at the time that
            Message 5 of 5 , Jul 27, 2001
            View Source
            • 0 Attachment
              At 03:05 PM 7/27/01 -0700, you wrote:
              >BTW, you can edit the menu if you want. Take a look at [Radio
              >Folder]/www/system/misc/editorsOnlyMenu.opml.

              Keen, thanks. Guess I need to poke around in there more.


              > > Speaking of that, couldn't the weblog page be a lot shorter if it were
              > > split into a weblog and weblog settings/preferences page?
              >
              >That's already in the plans as well.

              Can tell I hadn't looked in "Prefs," huh? =)


              > > Just that I first played with changing #template.txt and had to figure out
              > > why it didn't change 127.1/ . No big thing. =)
              >
              >I'm not sure what you mean here. (I'm probably just being dense.)

              I didn't know at the time that #homeTemplate.opml was the template for
              127.1/ and #template.txt for the 127.1/system/ pages, so when I poked and
              prodded #template.txt (I added some text and made the Editors Only menu
              justify right instead of center), I didn't know why my changes weren't
              reflected in 127.1/ (that being because I should've changed
              #homeTemplate.opml to change 127.1/, not #template.txt). Just me not
              knowing yet which template affected which pages.


              > > Twice today Radio's only read parts of items from my own rss.xml feed; the

              >Hmmm. Where was the feed you were reading? Was it dynamically generated by
              >Manila? I'm not quite sure what could have caused this.

              http://markpasc.home.mindspring.com/blog/rss.xml , the normal weblog RSS
              file Radio makes.


              And another thing:

              I couldn't unsubscribe from a channel through the view channel/magnifying
              glass page for the feed, though it worked through the Subscriptions page.
              When it didn't work, it looked like it was fetching for a moment, then just
              stopped.

              Changing index.txt to "{radio.html.viewNewsItems ()}" works fairly nicely. =)

              It'd be great if the News page could show X items or all items from the
              last scan, whichever's greater.

              Also, it would be *great* if Radio could figure out (or have me tell it) to
              not scan certain feeds every hour. The site I'm thinking most of is
              Disenchanted, which only updates weekly, so it'd be nice to tell it, "Only
              update this site on Tuesdays." But then, what I really mean is, "Don't
              update unless it's Tuesday; then update hourly until the feed changes,"
              which isn't exactly easy to explain programmatically. Mainly I'm just a
              little troubled whenever I see "167 total threads; 43 new stories."
            Your message has been successfully submitted and would be delivered to recipients shortly.