jana said:
> So, Bird, you have decided
> the user interface wasn't "solid"
> after all, huh?... (:
if you want to focus on the color of
the bike-shed, i will use your colors.
functionality still seems more important
to me, but this is a collaboration, so i am
trying to be responsive to collaborators...
> The options screen doesn't work correctly for me.
you need to resize the browser window.
this is a flaw in the compiler i am using.
> I don't know when and why,
> it just sometimes happens.
yes, i've seen that. and the compiler guys
know it's a problem. they're working on it.
it's not your fault.
> I had _not_ changed the text yesterday
> when that huge Save button appeared.
i don't know what to say. the only way that
that button appears is if there is a keystroke
in the edit-field... perhaps it was accidental,
and you didn't even realize that you'd done it?
at any rate, the "abort" button is there now,
if you wanna ensure any change is not saved.
and, again, every version of the file is saved, so
if you want to revert at any time, it's quite easy.
i will even provide some diff program so that you
can see the difference between various versions...
> Guess it was just some kind of glitch,
> like the user interface not always looking correct;
> resizing the window usually resolves that,
> which does of course not make it any less irritating.
as i said, the compiler guys know about this,
and they're working on it. that's all i can say.
> You said they were; so when's "later" going to be?
i will incorporate all of the options at one time,
to save time. no sense in doing them piecemeal.
> The font is used in the conversions; for now,
> that would mean the righthand side, because
> as I understand it, that's the only conversion
> we're doing right now: HTML. And in my HTML,
> why not let me choose the font I wanna see?
i was just asking to see what you wanted, jana...
i didn't know if you meant the text-field in the tool,
the html-field in the tool, or the converted output,
which will consist of the .html, the .pdf, and .epub.
(i don't think that .mobi allows you to specify font.)
for the record, i think you should be able to
specify the font for _all_ of those places...
the only thing i'm unsure about is whether i
should allow _different_ fonts in each of them.
the positive argument is finer-grained control.
the negative side is that it means more work
for the user, by specifying 4 fonts instead of 1.
> But that's exactly it!
no, that's not "exactly it"...
but it's not your fault that you don't know that.
so i will explain it to you...
> The righthand side _is_ a conversion,
> namely the HTML conversion.
well, it is, in one way, and it's not, in another way.
the .html conversion is actually a file that is saved
on the site itself. you can verify this for yourself...
change some text in a chapter, then save the file,
then navigate somewhere else and then go _back_
to that chapter, and then look at the site's directory:
> http://76.74.254.239/~bowerbird/
sort by "last modified" to see the file you just created.
for instance, if the text you changed was in chapter 11:
> http://76.74.254.239/~bowerbird/chapter11.html
load it and see that that file contains your changes...
(at least until someone views an unedited chapter 11.)
what the app does is that it loads in _that_ .html file...
it reads the text, and puts it in the text-field, and then
it does a conversion, saves the converted .html to a file,
then reads that file in and displays it in the .html-field.
sounds convoluted, i know, but that's how it has to do it.
now, i could write an anchor into that file, but my app
doesn't know about anchors when it displays its .html,
so it wouldn't do any good to write in such an anchor.
(you can confirm, for instance, that the file _will_ have
the search-term marked to display in red, and my app
_does_ understand how to display that color command.
it just doesn't understand anchors... and besides that,
there's no real _need_ for that, not in a converter tool.
if this was a viewer-tool, ok, yeah, sure, but then if this
was a viewer-tool, why would you need to have _both_
the plain-text displayed alongside the .html display?)
> Are you telling me I need links from the table of contents
> to the chapters in epub, mobi and PDF, but not in HTML?
> That's just plain silly.
yeah, that would be "just plain silly".
so you can be pretty sure that's not what i was saying,
because i never say anything that is "just plain silly"...
(except when i'm trying to make my girlfriend smile.)
all of your converted files will have a linked table of contents:
the .pdf version, and the .epub, and the .mobi, and the .html.
i cannot make such links work inside the tool right now,
which is why i provided the table of contents in a popup.
(besides, a popup is more convenient, because it means
that you don't always have to sidetrack to a contents page.)
and -- just so you understand all that's going on here --
i also need to tell you that the .html file that is saved out
-- you know, the .html file that you looked at up above --
is _not_ the one that will be used in the conversion process.
those .html files require some other little doo-dads that
mean that they need to be written using another routine.
(or, actually, several routines, depending on whether the
.html book will all be in one file, which makes more sense,
or split across many files, as required by the .epub format,
which is so brain-dead it cannot handle over 300k of text,
meaning we need to chop the book into bite-sized chunks.)
and yes, the users of my tool are now free to roam around
without having to acquire all of this technical crap, because
i already did the work of slogging through all of it for them.
so they can just click a button and boom!, out comes the file.
so they have more time to make their significant other smile.
> Then why allow for searching at all,
> if you're not willing to make it user-friendly?
again, this is not a viewer-tool. it is a _converter_.
i put in the search facility because it might be useful.
if you would prefer, i can take it out. just tell me...
> You can argue that the user doesn't need
> a search capability, and I would accept that.
as i said, i think that it might be useful.
_i_ will find it useful. there's often some text
that i know that i want to check in the .html
-- to see if it has been converted correctly --
and the ability to have the tool find that text
for me so i don't have to remember where it is.
and if i could have the tool point to it directly,
i would. but the best i can do now is colorize it.
> But what you are doing is arguing that
> the user needs a _crippled_ search capability,
> but not a _decent_ one.
that's not even close to what i am saying...
> That doesn't seem to make much sense to me,
> I must admit.
yet you have no trouble putting those words in my mouth?
that's hardly the spirit of collaboration.
> Yes, I can of course use my browser search
> after I've used the built-in search;
> that's just not very intuitive, you know?...
sorry. it's the best i can do right now.
if you can do better, please show us...
> Why do I have to search _twice_
> in order to find something _once_?
because the first search finds the appropriate chapter,
and the second search finds the text inside that chapter.
neither one can do the job all by itself. neither one.
is that difficult to understand?
-bowerbird