IRC: discussion on html/panes/front page

20 Nov 2000 00:22:12 -0500

OK.  Some people feel strongly about this one way or another, but as a
test here goes.

Some people can't be involved in IRC discussions, but would still like
to know anything interesting that goes on.  I'm going to try (for at
least the most significant of conversations I notice) to take the
important parts of the log and post them to the list.  If anyone has
any great objections to this let me know.

Players:
grib: bill gribble
rlb: rob browning
dave_p: dave peticolas

Time is Friday, 17 November 2000 EST.

Script:
16:14:36 <grib>	anyone who cares: just talked to jon trowbridge on #guppi and he will add a vector-argument version of the varargs guppi-object creator tonight. this means we don't have to do the libffi thing.
16:15:12 ---	grib has changed the topic to: gnucash development: gtkhtml, gnome-print, docbook
17:15:27 <grib>	dave_p: i'm working on the report-window code. seems clear we need the ability to have multiple reports open at once.  Thoughts on the "open in this window/open in another window" interface?  I've been toying with a right-button popup menu for some of this stuff; should I make it so adding an icon to the toolbar adds a similar menu option, so window-less (embedded) reports still have options and histories?  other thoughts?
17:16:40 <rlb>	grib: if I'm following, I think when there's no reason not to, we should mirror netscape and friends.  I believe there the middle mouse opens a new window when you click on a link...
17:16:48 <rlb>	grib: and I use that all the time...
17:17:25 <dave_p>	embedded reports would need options, but probably not histories
17:18:55 <grib>	what about "similar but different" content... i.e. a gnc-help: link (which opens a Help window, or possibly THE help window if we decide there should be just one) embedded in a report?  In that case, you have to open the link in another window.  For the most part, a report window should only be able to open reports in the same window.
17:19:50 <grib>	Does that mean the underlying HTML widget needs some semantic knowledge about what "flavor" of HTML documents it's allowed to open?
17:22:01 <grib>	I agree that embedded reports might not need histories, but what do you do in an embedded report when there's a link to another report?  I was supposing you would need a "open a new window" callback, which might actually just split a pane in some default way to make room, or might open a whole new window.
17:22:49 <dave_p>	I had assumed that hitting a report link in an embedded report would open a new window, but maybe it needs to be more flexible.
17:25:31 <dave_p>	it would be cool if we could some how tell gnucash to take the contents of a report window and put it into a pane. I was envisioning separating the creation of panes from choosing their content. I think that is more flexible, and puts the user in more control.
17:34:07 <grib>	i think that's the right approach; the q is the interface. 
17:37:24 <dave_p>	I see three choices: open in new window (probably the default), open in new horiz pane, open in new vert pane, open in existing pane (which you would pick). That's for the main window. The choices would have to depend on what is was embedded in. If it was embedded in a report window, it's open in existing window or open in new window, with existing window probably the default. If we can arrange it so that clicking the link does the default, and r
17:37:52 <dave_p>	that's really four choices, isn't it
17:38:01 <grib>	who's counting?
17:38:06 <dave_p>	not me, clearly
17:42:06 <dave_p>	grib: could the report click/right-click hotspot have fly-over help?
17:42:23 <grib>	elaborate.
17:42:31 <grib>	(that's a request not an adjective)
17:42:38 <rlb>	grib: and in generall, it would be cool if we could have other "fly-over" info.
17:43:13 <dave_p>	when the mouse moves over the hotspot, you get flyover help telling you about right-clicking (that fact that you can just click should be visually obvious)
17:43:16 <grib>	we get a callback from gtkhtml whenever you fly over a URL, so it's easy to do the "URL at the bottom" trick.  I reckon that could be (ab)used to do a tooltip-ish thing.
17:43:16 <rlb>	grib: for example, other fin apps have actual numbers pop up when you put the mouse over a bar or pie slice, though I don't know how hard that would be to do...
17:43:33 <dave_p>	grib: yes, that would work
17:44:09 <rlb>	grib: I wonder if we could also make it really easy to add tips with an optional "property" like "gnc-tip" or whatever...
17:44:33 <rlb>	grib: for the URL or tag or whatever...
17:45:02 <rlb>	grib: though none of this is really critical...
17:45:06 <grib>	Ah.  I don't know about callbacks on flyovers of other things.  If we wanted to be really naughty, we could make a very, very "special" url type called gnc-flyover-info: that might work.  It would be a no-op anchor if you click it but its info would show up. 
17:45:55 <grib>	i.e. <a href="gnc-flyover-info:this is too much to spend on liquor!">5000.0</a>
17:45:59 <rlb>	grib: could it not be a "wrapper" for other things that passed the click through? or does that make any sense at all?
17:46:50 <grib>	rlb: give me a f'rinstance scrap of html
17:47:34 <rlb>	grib: something like <flyover tip="this is the tip"><a href="some-other-report">subtotals</a></flyover>
17:47:49 <grib>	(btw I think <a> tags can have attributes which say "don't underline, don't show in a different color")
17:48:20 <grib>	rlb: (1) we can't make up our own tags (2) we only get flyover callbacks for anchors
17:48:44 <rlb>	grib: and anchors are just <a></a> blocks?
17:49:28 <grib>	that's right.  there may be other instances of URLs giving flyover callbacks, but it's definitely only for things that gtkhtml thinks are URLs, meaning they are in href= blocks somewhere.
17:49:56 <grib>	I can't think of any other legal places where we would be likely to get callbacks.
17:53:52 <rlb>	grib: so are we allowed to use non-html compliant "up to us" properties in the <a> blocks/tags, or will gtkhtml barf?  If gthtml would be OK with that, then perhaps we could do something like this...
17:54:05 <grib>	rlb: your q about "other fin apps": whether Guppi will give us flyover callbacks is a totally different question.  I know you can get click callbacks.
17:55:18 <rlb>	<a href="gnc-report:subtotal-report" gncflyovertip="Some relevant text">Show subtotals</a>
17:56:43 <grib>	no, that won't work.  We don't get to see the contents of any tags except for very special circumstances (generally URLs).  gtkhtml would barf on that, because its job is to interpret the html and that ain't html.
17:57:45 <grib>	the only time it asks you questions is when it needs content that it doesn't know how to get.  gtkhtml is ignorant of HTTP, it just knows HTML.  So you get to see all URLs and it's up to you to interpret them.
17:58:52 <grib>	<object> is different because you can do such crazy things with it.  You basically get to see the whole contents of <object> forms, though what you can do with them is somewhat limited.
17:59:31 <grib>	(actually you don't get to see the body of <object> forms, just attributes in the start-tag and any <param> declarations in the body.
18:07:19 <rlb>	grib: so technically could we have a type of <object> that was essentially identical to a normal anchor, but also let us add a "gnctip"?  I'm not saying we should; at this point I'm just curious.
18:07:50 <rlb>	grib: so you'd only use <a>'s whenever you were happy with the no-frills semantics.
18:09:38 <grib>	no, I don't think so.  the <object> block won't generate any callbacks for the "on_url" signal.
18:10:04 <grib>	I think we're stuck with using <a> if we want to do it.
18:11:12 <rlb>	So but now that I look back at your example, we could do most of what we want with suitable encoding/parsing in the href data...
18:11:51 <grib>	right.  we get to see the href data and do whatever we want with it (including nothing) and we can treat different URL types differently when we get the flyover callbacks.
18:13:01 <grib>	It would be possible to have a report object have a tip, so that an href="gnc-report:foo" would call a function on the foo report object to get a tip to pop up on flyover of that URL.
18:13:27 <grib>	I think we are getting a little out in the weeds with this, but it could be interesting. 
18:13:41 <rlb>	Hell, we could even do something like this and parse it with assoc :>  <a href="(link (file-target "report-1") (tip "this is too much to spend on..."))">Show report-1</a>
18:14:38 <rlb>	Uhh... plus or minus some double quote issues...
18:14:54 <grib>	that wouldn't bother gtkhtml; I have been trying to keep things looking as much like HTML as possible, but that's not necessary (and we're not really tied to it).
18:16:23 <rlb>	Well, I'm don't care that much how it looks either way.  Right now whatever's going to provide us the flexibility we need to get things whipped up fast (and to be able to change them quickly) is fine with me.
18:16:57 *	grib  agrees

-- 
@James LewisMoss <dres@debian.org>      |  Blessed Be!
@    http://jimdres.home.mindspring.com |  Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach