[Roadster] Roadster meeting minutes Apr 3, 2005

[Ian McIntosh]

The meeting was very helpful.  Many thanks to those who participated!

=========================================================================
Summary:

POI Basic GUI

- POI invisible above a certain level, except for those with
info-balloons

- single click on a POI to open info-balloon (must use X in balloon to
close)

- double click on a POI centers it and opens info-balloon

- click and drag on POI should drag the map normally


POI Edit Dialog

- POI Dialog will be a list of key/value and be directly editable like
gconf-editor and workspace applet preferences (if this doesn't work
well, we'll consider a popup or standard edit boxes below the list)

- To edit a value, double click it (or later: add right click "Edit"
like gconf editor's "Edit Key" menu item)

- Open POI Dialog via "more info" (possibly rename) link (the link
should be in bold)


POI Search

- POI Search: probably exclude address field.  use "all words in any
values."

========================================================================
Full Log:

(20:31:37) ian: some topics
http://linuxadvocate.org/projects/roadster/meeting.php
(20:33:26) ian: alright, so #2 might be an easy one
(20:33:45) nelson: I would suggest that POIs should be transparent.
(20:33:53) ian: how familiar are you guys with MS S&T, Delorme Street
Atlas and Google Maps?
(20:34:21) sgarrity: I'm familiar with Google Maps and MS S&T (though I
haven't used it in a while).
(20:34:44) ian: nelson: do you mean the little points or the balloons?
(20:34:56) ian: this is how points are being drawn now
http://linuxadvocate.org/projects/roadster/images/roadster-0.2.5-1_large.png
(20:35:26) ian: we had plans of using meaningful icons (PNG and/or SVG)
(20:35:53) ian: MS S&T seems to use icons when zoomed past some level,
otherwise dots like that
(20:36:16) nelson: Ahhh, I see. I'd suggest that you use the largest
representation that doesn't obscure any feature.
(20:36:55) ian: nelson: you mean draw different POI differently in a
single view?
(20:37:29) nelson: No, I'm referring to the scale.
(20:37:41) ian: the size of the dot/icon?
(20:38:26) nelson: yes.
(20:38:42) ian: each dot with a different size? seems like it might be
confusing
(20:38:47) nelson: I think you should, as a general principle, display
all the information you can without obscuring other information.
(20:38:56) nelson: No, each dot with the same size at the same scale.
(20:39:09) ian: what do you mean "that doesn't obscure any feature"?
(20:39:09) nelson: always draw at least one pixel.
(20:39:30) sgarrity: ian: is that screenshot a mockup, or are the POI
working like that in CVS?
(20:39:35) ian: working
(20:39:37) p0m: I think he means so that it doesn't overlap anything
else and cause confusion.
(20:39:42) nelson: e.g.: don't draw a POI so large that you can't read a
street name.
(20:39:49) nelson: as, for example, google maps currently does.
(20:40:22) ian: sgarrity: there will be no POI in your database though
(20:40:36) sgarrity: Ok, cool.
(20:40:47) ***sgarrity is still waking up from his nap...
(20:40:58) ian: sgarrity: there's code to insert some test points in
main(), could get nathan to fiddle with it
(20:41:50) sgarrity: so, MS S&T does a mouse-over on POI for more info -
right?
(20:43:20) ian: no, it either draws the name next to it (without a halo
or anything so it's quite hard to read IMO) if you're zoomed in enough,
or you can click to select ONE at a time (in which case it draws the
text regardless of zoomlevel and draws a box around dot+text), or you
can turn the info balloon on for a POI, in which case it draws the icon
and balloon at all zoomlevels
(20:43:34) ian: and info balloons for multiple POI can be turned on at
once
(20:44:06) ian: I think you do it by double clicking, or single-clicking
to select then clicking the a toolbar button
(20:44:42) ian: nelson: well, we will be reducing the POI glyph size
when zoomed out, but I'm not sure how it could totally avoid overlapping
things (well, we could make text not be displayed if it would overlap a
glyph. is that desirable?)
(20:46:23) ian: is this the model we want? POI are invisible above some
zoomlevel, except for selected POI?
(20:47:44) nelson: Hmmmmm.... I think you ought to draw one pixel.
(20:47:50) nelson: That will get people a target if they need to zoom
in.
(20:48:05) ian: that means loading POI for potentially the whole country
(20:48:08) ian: or world
(20:48:41) ian: nelson: what is the use-case you're thinking of?
(20:48:55) sgarrity: yeah - and it could mean the world would be solid
with POI pixels if there are too many.
(20:49:19) nelson: Maybe I don't know how many POIs you plan to support.
(20:49:35) ian: I think "millions" is safe
(20:49:40) nelson: are these user-created bookmarks, or things like post
offices?
(20:49:47) ian: both
(20:50:01) ian: I think a lot of the "official" POI will have to come
from users
(20:50:13) ian: but it will also be for users to share POI sets
(20:50:41) jsk_: if the "poi density" is above some threshold for a
region, perhaps have single glyph represent it... clicking that zooms in
to see the regional pois in more detail
(20:51:10) nelson: Perhaps a POI needs to have a scale associated with
it?
(20:51:14) sgarrity: jsk_: Yeah.
(20:51:19) sgarrity: Example of POI: I might grab the "geourl.org"
database and map the points of weblogs.
(20:51:24) nelson: As in "Draw state capitals no matter what the scale"
(20:51:47) jsk_: so the one gas station in western New Mexico gets its
own glyph, while you have to zoom in on Santa Fe. :)
(20:51:52) nelson: and "draw county seats below scale 3" and "draw post
offices below scale 5"
(20:51:53) ian: nelson: I think city/state/etc. names will not be POI
(20:52:11) ian: nelson: so that stuff will be hardcoded (or rather, in
config files without GUI editing)
(20:52:11) nelson: I'm just using them for a density of POI reference.
(20:53:02) ian: that's the model I was envisioning in the beginning, but
I wonder now if it's too complicated -- for example, a user can toggle
on/off a POI set, but if they toggle it on above the zoom threshold for
that set, it won't show up?
(20:53:30) ian: having a single threshold (MS S&T starts drawing POI at
the same zoomlevel that it uses the high-res street data)
(20:53:41) ian: ...might make it more understandable?
(20:54:17) nelson: i think you might be right there.
(20:54:31) nelson: and one less datum per poi.
(20:54:37) ian: yeah...
(20:54:51) jsk_: I guess I'd love to see a glyph which indicates "there
are gas stations in this region" or "there are hotels in this region"
even if I can't see all of them
(20:55:09) sgarrity: I think jsk_ is on to something there.
(20:55:17) ian: so basically, you can select a few POI that are of
interest (text balloons open) and then zoom out and see them all
(country/world wide)
(20:55:40) sgarrity: yeah
(20:55:51) ian: that's the MS S&T model and I think it works pretty
well 
(20:57:54) ian: jsk_: hmm. so a "region" would get an icon if there were
more POI than some threshold?
(20:58:21) ian: I suppose it could be really hard to find a few POI in
some custom set
(20:58:25) jsk_: ian: Yeah, hopefully that can be reasonably automated
(20:58:47) jsk_: basically set the threshold such that the screen isn't
too cluttered
(20:59:06) ian: actually, what I was thinking is that the search would
only match POI from sets that are set enabled (visible). agree?
(20:59:25) jsk_: yeah
(20:59:42) ian: I like that because it integrates the UI-- only one POI
list needed
(21:00:03) sgarrity: where will that POI list be in the UI?
(21:00:07) ian: sidebar
(21:00:18) ian:
http://linuxadvocate.org/projects/roadster/images/roadster-0.2.4-1_large.png
(21:02:28) ian: does that work?
(21:02:39) sgarrity: yeah, that's what I was going to suggest
(21:02:43) ian: cool
(21:03:09) ian: any thoughts on creating a new POI and POI Set?
(21:03:19) ian: do we put buttons on that tab?
(21:04:39) sgarrity: yeah, probably
(21:04:51) ian: jsk_: that seems like it would demand a "mode" for
that-- otherwise you'd see "gas stations are here" icons everywhere
(along with 20 other POI Sets)
(21:04:58) p0m left the room (quit: Bleh).
(21:05:10) jsk_: (sorry, making a pizza in parallel :) The sidebar looks
good. There might be some need for customization even of the poi. For
instance, for gas whether to display price or closing hours
(21:05:50) ian: that's #5 on the list :)
(21:06:17) jsk_: ian: Oh, sorry, I miss understood... I agree that they
should be enabled/disabled :)
(21:06:24) jsk_: I should go check the list ;)
(21:06:25) ian: I think #2 is answered well enough
(21:07:32) ian: let's tackle #1 if possible
(21:07:55) ian: MS S&T does single-click to select, double-click to set
info-balloon on
(21:08:12) ian: however, I'd rather not have a 'select' mode for POI
(21:08:21) ian: having two states is confusing
(21:08:27) sgarrity: Google does single-click to show info, double-click
to re-center.
(21:08:44) ian: I think I like that model
(21:08:46) ian: you?
(21:08:52) sgarrity: yeah, it works nicely
(21:09:25) sgarrity: and I like that single-click on items in the
sidebar show the info box on the map for the associated POI
(21:10:05) ian: that's actually the hard thing for us, will we show an
info-balloon for the currently selected search result?
(21:10:33) sgarrity: I think so, yeah.
(21:10:37) ian: if so, will the balloon for point A disappear when the
user selects point B?
(21:10:42) ian: and what if they want it to stay open?
(21:11:22) sgarrity: is that necessary?
(21:11:36) ian: what, keeping it open?
(21:11:48) sgarrity: yeah - you can't on Google Maps
(21:11:59) ian: I think so, for example searching for coffee shops in
the area. you find three you like and leave the balloons open
(21:12:09) ian: then zoom out
(21:12:28) sgarrity: maybe that should be done with push-pins or
something like that?
(21:13:23) ian: perhaps-- why is that better? I'd like to avoid a whole
new "thing" in the UI if possible
(21:13:42) sgarrity: yeah, would be good to avoid that.
(21:13:43) ian: I know MS S&T uses pushpins, but they also don't let you
edit POI
(21:13:56) ian: if you could create/edit POI, is there any need for
pushpins?
(21:14:05) sgarrity: no, I don't think so.
(21:14:38) ian: I wonder if pushpins are visible at all zoomlevels
(21:15:17) sgarrity: Maybe a way to move or copy a POI to a new set
("Add to My Points")?
(21:15:29) ian: yeah-- favorite points or something?
(21:15:38) sgarrity: yeah, like bookmarks.
(21:15:39) ian: there are two ways to do that
(21:15:50) ian: one is to copy the POI into a new set like "My Points"
(21:15:55) ian: kind of messy.
(21:16:05) ian: the other is to just record the POI # 
(21:16:11) ian: mark it with a star or something
(21:17:24) sgarrity: the latter seems better - but what if you turn off
that POI set?
(21:17:44) ian: hmm, not sure
(21:18:00) ian: that seems like a good preference. I could see two uses
for Favorites
(21:18:57) ian: one is to tell which gas stations are best at a glance,
the other is to select a few POI from various sets then turn those sets
off and get a custom view
(21:20:40) ian: a few little unrelated details: if you double click on a
POI, should it recenter and show balloon?
(21:21:15) ian: and: how do you get rid of balloon? just using an X in
the balloon or should clicking on the icon again close the balloon
(21:21:17) nelson: yes.
(21:21:25) sgarrity: what does double-click do elsewhere on the map
right now?
(21:21:32) nelson: lcick anywhere else?
(21:21:36) ian: recenters like google maps (only smoother:) )
(21:21:59) ian: nelson: can't do that because we will support having
multiple balloons open
(21:22:06) sgarrity: then recentering is probably good for POI too then
(21:23:15) ian: so single click to open balloon, but how do you close
it?
(21:23:20) nelson: X in the balloon, then. People will know what to do.
(21:23:36) sgarrity: yeah
(21:23:47) ian: so clicking a POI always turns it on
(21:24:01) ian: (never turns it off)
(21:25:22) ian: correct?
(21:25:28) sgarrity: yes
(21:25:45) ian: ok, that works nicely with navigation as it is
(21:25:58) ian: what about click-and-drag on a POI? just drag the map?
(21:26:22) sgarrity: yeah - that way the map behaves the same if you
click to drag, but hit a POI by accident
(21:26:30) ian: yeah
(21:26:38) ian: which will be common if you have lots of POI
(21:26:53) ian: so as long as you move the mouse after button-down, it
won't pop up an info box
(21:27:30) ian: great, so #1 is settled
(21:27:30) sgarrity: a subtle mouse-over on POI icons might be nice, to
help indicate clickability, and let you know you've got your
clicking-target.
(21:27:42) ian: it currently changes the mouse cursor
(21:27:48) sgarrity: ah, that's good
(21:27:51) ian: from normal arrow to pointy-hand
(21:28:17) ian: a subtle change in the image might be nice
(21:28:27) ian: probably leave that for later though
(21:28:37) sgarrity: yeah, cursor change works well for now
(21:29:34) ian: so dragging of POI is not possible with this setup--
perhaps that's good (maybe have a special mode/tool for editing?) 
(21:29:59) sgarrity: yeah, that should probably be separate
(21:30:25) sgarrity: If I'm just using someone elses POI data (hotels,
or something), I don't want to be dragging them around)
(21:30:32) ian: yeah
(21:30:35) ian: ok, so #3 is viewing/editing POI attributes
(21:30:49) ian: for those that don't know, POI will have unlimited
key=value pairs
(21:30:54) ian: even multiples
(21:31:12) ian: eg. 
(21:31:12) ian: phone=617-555-5435
(21:31:12) ian: phone=617-555-1414
(21:31:57) ian: the info balloon will show some of these -- probably
name, address, phone, some urls, and maybe (part of) a description
(21:32:42) ian: so those names may be hard-coded in
(21:33:06) ian: but I think users should be able to store (and search
on, in an Advanced search?) other values
(21:34:32) ian: I think most values should be clickable, like phone
number could pop up huge text (as described on the meeting topic list)
(21:34:44) ian: "I think Quicksilver does something special with phone
numbers: displays them in a VERY LARGE font across the bottom of the
screen to make dialing super easy. Can/should we experiment with this?"
(21:35:14) ian: perhaps it should show the phone number and make it be
clickable?
(21:35:45) ian: I'm not entirely sure that's useful (as I haven't used
it), but I think it's pretty clever
(21:36:47) ian: thoughts?
(21:38:43) sgarrity: gotta plug in my laptop - brb
(21:39:05) ian: mockup of an info balloon here
http://linuxadvocate.org/projects/roadster/images/poi_box_mockup-2.png
(21:40:11) cworth entered the room.
(21:40:15) ian: hi carl
(21:40:44) ian: cworth:
http://linuxadvocate.org/projects/roadster/meeting.php
(21:41:09) sgarrity: Hi Carl - Steven Garrity here. I saw your photo at
the Grokster trial on Planet Gnome.
(21:42:10) ian: sgarrity: any thoughts on how to show all the other data
we have on a POI?
(21:42:51) ian: I'm thinking a dialog box is in order-- perhaps it
should even allow multiple dialogs so you can compare POI?
(21:42:58) ian: and copy/paste between them, etc
(21:43:09) sgarrity: Yeah, I think it'll have to be a dialog box.
(21:43:54) ian: think it should be all editable (a bunch of text boxes)?
or all non-editable with some way to edit individual values?
(21:43:59) cworth: sgarrity: Hi Steven. Perhaps I wasn't at my best
after a full night of no sleep.
(21:44:34) sgarrity: ian: Yeah, I was just thinking about that... not
sure how to best handle that.
(21:45:11) ***sgarrity is making some tea - brb
(21:45:48) ian: cworth: what's a nice way to show a bunch of text values
(potentially quite long) and make them easily editable?
(21:47:50) ian: I wonder if it should just be a list
(21:49:54) ian: perhaps a list, sorted by attribute name, where you can
click to edit both the 'key' and the 'value' (perhaps the key should be
a combo box?)
(21:52:31) ian: with some easy way to add a new one to the list
(21:53:29) ian: I wonder which is easier to discover/use, editing in
place (in the list) or editing in a popup
(21:54:10) sgarrity: editing in place seems nicer, but it's not
something that's really done anywhere else in GTK - unless the text is
already in a text input box
(21:54:42) ian: I know one place-- Workspace Switcher preferences dialog
(21:56:02) sgarrity: Ah, yeah. I see. Kind of strange
(21:56:37) ian: also try gconf
(21:57:20) ian: I think I like editing in place-- eventually we could do
clever things like make certain types of values be boolean
(21:57:30) ian: (checkbox)
(21:57:38) sgarrity: yeah, gconf is pretty good
(21:58:01) ian: then it's really simple, just a list of values for the
POI
(21:58:33) ian: the only trouble is how a user knows they can edit it
(21:58:52) nevroe_ entered the room.
(21:58:57) ian: at times like this, I ask myself What Would Apple Do
(21:59:10) ian: hi nevroe
(21:59:17) nevroe_: hi
(21:59:25) sgarrity: actually, Apple does a weird in-line edit in iCal -
but it's really strange, because no other Mac app does it that way
(21:59:39) ian: for calendar names?
(21:59:59) sgarrity: for appointment details (title, date, time, etc.)
(22:00:16) ian: got a screenshot by any chance?
(22:00:27) sgarrity: I'll get one... just a sec.
(22:00:38) ***ian twiddles his WWAD bracelet
(22:01:00) ***nevroe_ thinks iam should make some WW<apple sign>D
t-shirts
(22:01:18) ian: hehe
(22:01:34) nevroe_: sorry I'm late to the party ... just a lurker on the
mailing lists, and thought I would drop by and listen in
(22:01:44) ian: that would be so great and illegal
(22:02:31) nevroe_: how about "WWGD?"
(22:02:51) sgarrity: what's the advantage of the gconf-style in-line
edit, over a list of normal text inputs? the appearance?
(22:04:39) ian: yeah the appearance, and ease of programming
(22:05:10) sgarrity: ian: Here's a screenshot of the editing in iCal:
http://actsofvolition.com/images/screenshots/roadster/ical-editing.png
(on the right)
(22:05:12) ian: (ease of programming may seem like a cop-out, but it
also means other programmers are more likely to do it the gconf way, and
consistency is good)
(22:05:35) ian: I see. doesn't the datebook app do it that way too?
(22:06:13) ian: what's that road sign app in the kicker?
(22:06:35) sgarrity: Acquisition - a P2P app
(22:07:00) ian: nice icon, although I don't see how it relates to P2P
(22:07:19) sgarrity: ian: yeah, the Address Book app does that too - but
you have to hit an "Edit" button to activate the in-line editing
(22:08:16) ian: do you prefer a list of edit boxes?
(22:08:39) sgarrity: not sure - they sure look uglier
(22:08:48) ian: reminds me of a web app
(22:09:30) sgarrity: Yeah - the gconf way is probably a good way to go
(22:09:40) ian: I'm not sure how well the gconf way handles multi-line
input, or if it does at all
(22:10:01) sgarrity: probably not very well - we ran into that problem
in Gnome Outliner
(22:10:45) ian: does it work at all?
(22:11:05) ian: enter seems to end editing
(22:11:35) sgarrity: Yeah - Shift-Enter gives you a new line - pretty
ugly.
(22:12:03) ian: hmm
(22:12:24) ian: that's a bit of info you'd have to give the user
(22:12:35) ian: a little italic text tip :-/
(22:12:45) sgarrity: Yeah - pretty sucky.
(22:12:53) sgarrity: we're not really happy with it as is.
(22:13:21) ian: what do you think about having an edit area below the
list
(22:13:41) sgarrity: What would be in the edit area?
(22:13:42) ian: normally disabled, but when you select a row, the values
go into the edit area and it becomes active
(22:13:51) ian: just key on the left, value on the right
(22:14:35) sgarrity: It would mean editing happens in more traditional
widgets, which is good - but it would get away from the HIG guideline to
make things directly manipulatable.
(22:15:08) ian: yeah
(22:15:51) ian: another option is to support both direct and popup
(22:15:58) ian: as gconf seems to do
(22:16:11) ian: (double click on a key name)
(22:16:25) ian: pretty hilariously ugly dialog box there
(22:16:26) sgarrity: Yeah - saw that. Kind of strange.
(22:18:13) ian: so I think we should go with a list, make it editable,
and see how that works
(22:18:25) sgarrity: agreed
(22:18:25) ian: if it doesn't work, we'll go from there
(22:18:33) ian: cool
(22:18:44) ian: nevroe_: we're working off this btw
http://linuxadvocate.org/projects/roadster/meeting.php
(22:19:02) ian: so how do you get to this dialog?
(22:19:19) sgarrity: a button/link from the info box on the map?
(22:20:30) ian: yeah-- what should the link text be?
(22:20:46) ian: it's sort of "more info" and "edit" at the same time
(22:21:09) cworth: ian: From the small amount of time I've spent with OS
X, I've often found it hard/confusing to get the
click0in-the-right-place-to-turn-a-field-editable right in one program
or another.
(22:21:29) ian: cworth: how about gconf?
(22:21:39) sgarrity: cworth: Yeah, I agree.
(22:22:24) cworth: ian: I've never tried it.
(22:22:33) ian: cworth: seriously?? :)
(22:22:50) ***cworth installs gconf-editor
(22:22:54) cworth: ian: What's it good for?
(22:23:04) ian: cworth: changing settings that have no GUI
(22:23:52) ian: sgarrity: any ideas for link text?
(22:24:10) sgarrity: not sure - maybe just "More Info"
(22:24:25) sgarrity: Doesn't cover the "Edit" aspect, but I'm not sure
what else to use
(22:24:40) ian: so it might have: website photos more info 
(22:25:01) cworth: So, double-click or right-click->Edit for editing.
That seems quite discoverable to me at least.
(22:25:10) sgarrity: the "more info" should look different and be more
prominent that the website/photo links, I think.
(22:25:27) ian: cworth: like gconf's "edit key" menu item?
(22:26:18) ian: sgarrity: different color or something more?
(22:26:32) sgarrity: maybe a button vs. text-link?
(22:26:46) ian: I'm afraid that would be anti-sexy
(22:26:46) cworth: ian: I was commenting on what gconf does, not
necessarily recommending it.
(22:27:01) sgarrity: maybe just bold text for the more-info link
(22:27:48) ian: depending how we do balloons (real windows or GDK/Cairo
drawn) a real GUI button could be quite hard to add
(22:28:01) ian: I think I like making it bold
(22:28:09) sgarrity: yeah, me too
(22:28:10) ian: works for the color blind too :)
(22:28:28) ian: not sure I like the text "more info" but that's easy to
change
(22:29:09) ian: alright that's #3 down. excellent
(22:29:13) sgarrity: Yeah, "more info" is problematic too for POIs that
don't actually have any more info to show.
(22:29:23) sgarrity: but it's probably fine for now
(22:29:27) ian: yeah
(22:29:35) ian: maybe like info/edit
(22:29:41) ***ian shrugs
(22:30:02) ian: so that's #3 down. this is going extremely well. :) you
good to keep going?
(22:30:11) sgarrity: sure - what's next?
(22:30:13) ian: http://linuxadvocate.org/projects/roadster/meeting.php
(22:30:39) ian: 5 and 6 are similar to each other and to what we've been
talking about 
(22:31:05) ian: 4 might be quick-- everyone want to just throw out which
you prefer?
(22:32:28) ian: are they clear?
(22:32:42) ian: could try to explain any of them further 
(22:33:23) sgarrity: I'm not sure what to do about the
"Cambridge"-in-all-address-fields issue.
(22:33:35) ian: yeah
(22:33:48) ian: I'm tempted to just exclude the address field
(22:34:47) ian: it's an entirely different way to search, and it
conflicts with the real way (possibly moving the view to where you want
to search around, searching, and seeing results ordered by distance from
where you are)
(22:36:18) ian: thoughts on excluding address?
(22:37:10) sgarrity: kinda of weird - but I think you might have to
(22:38:04) ian: ok, let's experiment with it when the time comes
(22:38:16) ian: what do you think about search operation (above three
options)?
(22:38:58) ian: cworth, nelson, nevroe_, jsk_: everyone. :)
(22:39:14) sgarrity: I'd recommend option #1
(22:39:41) ian: so you couldn't do like "coffee wifi"
(22:40:07) sgarrity: Sorry, I meant #2
(22:41:22) ian: anyone else?
(22:42:19) ian: I agree, I like #2. It was #3 at first, but then you get
more hits the more words you put, which seems wrong (and more
importantly, it's not how web search engines work)
(22:43:02) ian: unfortunately #2 is the hardest to write :)
(22:43:53) ian: ok, I'll mark that one done
(22:44:42) ian: so the last two are easy, 5 is just brainstorming cool
things to do, and 6 is how to integrate it in the UI
(22:45:23) ian: the idea here is that certain 'name' parts of the
name=value pairs could be treated specially
(22:45:47) ian: I think it might be more future-proof if it were
"certain suffixes" like "-url"
(22:46:03) ian: so you could have website-url="http://..."
(22:46:26) ian: or email-url="" (I'm not sure if this should be url or
uri)
(22:47:01) ian: the idea being that you could then make them a) show
them as links in the balloon and b) make them launch
(22:48:46) ian: so you could be looking at a POI Set of your friend's
vacation with points all over the place, and click one of the POI to
bring up the balloon, then click the "photos-url" link (I think the link
would show up without the -url part, so just "photos") and it would open
a web browser to that url
(22:49:11) sgarrity: Yeah, sounds good.
(22:49:55) ian: however, I wonder if this "-url" thing is too hacky
(22:50:09) ian: another way to do it would be to have flags on the value
(checkbox in the GUI)
(22:50:27) sgarrity: or field-types
(22:50:32) ian: hm?
(22:51:22) sgarrity: field-types - like text, bit-field (checkbox), URL
- not sure if that's a good idea.
(22:52:08) ian: if we did, it would be associated with the field name,
not the individual value
(22:52:19) ian: so all values with name "website" would be a url
(22:53:05) sgarrity: what about just auto-linking any URLs in any field?
(22:53:28) ian: then you have to show the actual url though
(22:53:37) sgarrity: yeah, that sucks
(22:54:29) ian: so either way works
(22:55:22) ian: photos="http://..." or photos-url="http://..."
(22:56:10) ian: can you think of any other suffix that would be special?
(22:56:41) sgarrity: email? or is that considered a URL?
(22:56:55) ian: not sure if it's technically a url
(22:57:00) ian: but it is handled that way
(22:58:51) ian: check out this key in gconf: /desktop/gnome/url-handlers
(23:01:49) ian: this is what roadster is using to open urls
(23:02:05) ian: through a command line program "gnome-open"
(23:03:45) ian: I think we should call it a night-- the rest is probably
best left for later