Hi, On Tuesday 28 June 2011, meik michalke wrote: > am Dienstag 28 Juni 2011 (12:06) schrieb Thomas Friedrichsmeier: > > I guess, having one output file per workspace would be a good default > > behavior (but of course, users should also be able to start new output > > files, manually, easily). > > sounds great!
yeah, but no promises as to when it will happen. > maybe create an "in.TOC=TRUE/FALSE" option for rk.header()? I'm not sure. Do you think there should be any rk.header()s, which are not in the TOC (unless perhaps those with level >= n)? > hm, frames are a bit out-dated, aren't they? but i think i see where you're > heading. how about reserving space for the TOC as a left margin and placing > it there in a <div style="position:fixed;"></div>? the downside would be, > if the TOC gets longer than page height, you couldn't reach the lower end. > but that should be solveable, somehow (or an incentive to reset your > output at least once in a while...). Yes, I know, frames are sort of 1990ish. But the problem is not so much the layout (that's certainly solvable in CSS, somehow), but rather updating the TOC. The output is generated step-by-step by simply appending to the end of it. Having the TOC in the same file would mean considerably more complicated modifications. In contrast, if the TOC is kept in a separate file, we can simply append to each. That's why I was thinking of frames. Of course, a two-file-solution could also work with <iframe>s or with some javascript. > > b) and c) probably cannot be done in plain HTML, indeed. Rather this > > should probably be implemented in C++, as a context menu. > > sounds interesting ;-) i'll have a look at HTML5, too, maybe there's some > nice and useful new stuff. if it could be done rather cleanly in the > output document itself, it would remain more portable with its > functionality. but it's just a vague idea now. Well, yes. But on the other hand, I am a bit worried about the UI, too. I imagine a context menu will be a more natural place for this functionality. Also, I think that at least for c) (the deletion), portability is not much to worry about: - If users want to take the HTML to a word processor, they can use the word processor's functions to modify it. - If users want to publish the HTML, they will not want to / be able to support modifications of the document, anyway. So I think this is only of interest within RKWard. It's not quite as clear-cut for b) (the copying), but to some degree, the same argument applies, IMO. > however, i'm often surprised what can be done in one markup file. for > instance, some time ago i've written a simple jeopardy game with HTML, CSS > and only a little javascript: > o http://reaktanz.de/stuff/jeopardy/ircotofun.html > not pretty, just a POC, too. but it's just that one file (i've written a > bash script to create that file with custom questions, so you can actually > play it). Nice hack ;-). But of course one thing to note is that in RKWard, as a user, I would expect a deleted section to be truely deleted, not merely hidden by CSS, in particular, if I ever want to publish the HTML. Also, be aware that the output file gets reloaded on changes. That might further limit what can be done with JS. Regards Thomas
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
