Meeting log

[Peter Harvey <pah06 uow edu au>]

Conversation with #epiphany at 2005-10-16 21:57:43 on (irc)
(22:00:26) phil|sleep is now known as philipl
(22:00:28) philipl: ugh.
(22:00:34) reinouts_: morning!
(22:00:37) chpe: hi
(22:00:46) philipl: 5am. 
(22:00:50) reinouts_: crispin, you awake?
(22:00:50) philipl: Hi.
(22:00:58) philipl: He's watching the F1.
(22:01:03) philipl: :-)
(22:01:12) reinouts_: anyone logging?
(22:01:17) harves: always logging
(22:01:23) reinouts_: good
(22:01:44) harves: on wireless though. best someone else does as well. :)
(22:01:51) adamh: I am...
(22:01:52) reinouts_: everyone having $favourite_cafeinated_beverage handy?
(22:01:53) chpe: I'm always logging too
(22:02:03) crispin: right, I'm really here now
(22:02:05) crispin: I'm logging
(22:02:06) harves: we ran out of coke here. :( but got soft drink
(22:02:20) ***adamh has no caffeine or alcohol in his apartment :(
(22:03:11) crispin: who else are we expecting ? tko ? marco_ ?
(22:03:14) philipl: Now that chpe is here: http://intr.overt.org/diff.cgi/diffs/middle-click-actions.diff
(22:03:16) philipl: :-)
(22:03:38) reinouts_: iirc tko wasn't sure he could make it
(22:03:41) chpe: philipl: I'll review it after the meeting, thanks :)
(22:03:48) philipl: no worries.
(22:04:01) reinouts_: shall we just get started then?
(22:04:09) tko: I'm here, just confused about timezones, I see :)
(22:04:31) reinouts_: wb tko
(22:04:40) tko: date -d "14:00 CET" says there's still one hour to go...
(22:05:02) reinouts_: tko: it doesn't count daylight saving time probablyt
(22:05:05) biesi: but we have CEST now
(22:05:27) crispin: how confusing
(22:05:31) reinouts_: it is
(22:05:50) tko: well, the time was CET.. if it had been CEST that would be now :)
(22:06:04) reinouts_: my mistake, probably
(22:06:12) ***crispin wonders what suitable meeting music is ....
(22:06:15) tko: but nevermind me
(22:06:17) ***crispin settles on The Coral
(22:06:24) harves: crispin: frou frou?
(22:06:30) ***adamh somehow has ended up listening to the Ghostbusters theme song :P
(22:06:36) reinouts_: haha
(22:06:48) crispin: ok, should we get going then ?
(22:07:04) chpe: ok
(22:07:06) reinouts_: this is the agenda for as far as I can recall:
(22:07:11) reinouts_: 1. open 1.8 bugs
(22:07:11) reinouts_: 2. re-prioritize 1.10 bugs, long term plans
(22:07:11) reinouts_: 3. Harves patch
(22:07:11) reinouts_: 4. suggestions, which ones to implement and which not?
(22:07:11) reinouts_: 5. extensions
(22:07:40) crispin: hmm, 1 is sort of impossible to do ...
(22:07:47) chpe: and 2 too
(22:07:48) crispin: 2 looks tricky too
(22:07:56) crispin: so, onto point 3 :-)
(22:08:12) harves: hehe. well, atm the patch seems fine to me...
(22:08:12) chpe: I bet someone sabotaged bugzilla just because of us ;)
(22:08:17) philipl: heh.
(22:08:24) philipl: Which patch is this?
(22:08:27) reinouts_: let's still talk about long term plans, perhaps as a later point
(22:08:52) harves: philipl: http://home.exetel.com.au/harvey/epiphany/ (though looks like we'll get to this later)
(22:09:09) philipl: harves: ah. could have guessed :-)
(22:09:23) reinouts_: harves: So, what's the current status?
(22:09:29) chpe: harves: as I recall you had some problems porting to gtk 2.8?
(22:10:05) harves: chpe: yeah, need to check that again, see if it's been fixed. i haven't found time to create a simple test case to submit to the gtk lists.
(22:10:18) crispin: I think that if the patch is going in, now would be the time to get it in, more eyeballs and all that
(22:10:26) harves: it also needs some accessibility work, but i think that will be easier now that we can have context menus for all toolbar items.
(22:10:33) chpe: yeah, so we can have it in the first 1.9 release
(22:11:02) crispin: I haven't actually tried it, but from what people who have tried have said, it sounds good :-)
(22:11:10) kikidonk entered the room.
(22:11:10) #epiphany: mode (+o kikidonk ) by Zeus
(22:11:18) chpe: hi kikidonk !
(22:11:22) harves: hey kikidonk
(22:11:27) reinouts_: crispin: quite a few bookmark/toolbar bugs are pending on integration of harves' patch
(22:11:44) chpe: harves: iirc the patch was mostly fine, but with a few follow-ups to do
(22:12:04) chpe: harves: like make it use EphyExtension iface, and the View->Toolbar submenu
(22:12:13) harves: chpe: yeah. i think i prefer to follow up on them once they're in trunk too.
(22:12:19) harves: yep.
(22:12:24) crispin: the few follow-ups are almost certainly easier to do when it is in CVS
(22:12:30) chpe: harves: I too think we should get it in as is now, and improve from there
(22:12:32) chpe: yeah
(22:12:35) reinouts_: was compatibility with Python extns really fixed now?
(22:12:47) crispin: that just needs the python API re-generating
(22:12:54) harves: reinouts_: i believe so
(22:12:56) reinouts_: I know it built with it, but I had some problems with using them
(22:13:05) harves: did you? hmm.
(22:13:16) reinouts_: I didn't check out what the real problem was though
(22:13:17) crispin: we don't have to preserve API compatibility fortunately
(22:13:22) reinouts_: it could as well be a problem on my side
(22:13:49) harves: python is something i haven't messed with at all yet. i didn't even do the stuff to get python working again.
(22:14:09) crispin: I'll happily fix up the python till it works again
(22:14:24) reinouts_: does the patch apply against 1.8.2?
(22:14:35) crispin: I would like to get more complete coverage of the API too, I think there are a few functions that need wrappers still
(22:14:39) harves: reinouts_: good question. i believe it should. can try right now.
(22:15:04) harves: had downloaded the latest 1.8.2 to try.
(22:16:45) reinouts_: ok, so: what is still blocking the patch integration, and how can this be fixed asap? 
(22:17:29) harves: there may be some code styling issues. some things are a little hacky.
(22:17:55) chpe: harves: should we arrange cvs access for you?
(22:17:58) crispin: it sounds like nothing is really blocking it from getting in, just someone to check it in
(22:18:20) harves: chpe: i dunno. i'm kinda fine having my stuff pass through you guys instead.
(22:18:46) chpe: 'k
(22:18:57) harves: chpe: i do less damage that way. ;)
(22:19:15) harves: there are no major bugs that i can find. atm i only know of menu-to-drag-and-drop with gtk 2.8 being broken.
(22:19:25) reinouts_: harves, in the long term you may want to have cvs access anyway
(22:19:41) reinouts_: it doesn't hurt to request it
(22:20:10) kikidonk: hi there :)
(22:20:11) philipl: Yeah, the lag time can be quite high, so do it when it's not urgent.
(22:20:14) harves: agree. but i'm going to have time issues soon, if not already, so don't want to waste too many people's time with it.
(22:20:57) harves: under pressure to get thesis written by january so i can get a job in canada. if i don't get it done the next 3 years plan kinda falls apart on me.
(22:21:13) crispin: chpe, are you going to check the patch in then ?
(22:21:30) chpe: yeah, I can do it
(22:21:33) reinouts_: if I understand correctly, crispin will check the patch for python compatibility?
(22:21:43) crispin: yeah
(22:21:45) reinouts_: cool
(22:21:51) crispin: (after it is in)
(22:22:07) kikidonk left the room (quit: Read error: 104 (Connection reset by peer)).
(22:22:37) harves: fwiw, i'm just checking what patch i'm running myself. i think it's h18 or possibly h19. what was the last one you got reinouts?
(22:23:10) reinouts_: harves: iirc you sent me a prerelease
(22:23:14) chpe: he latest on the website is h18
(22:23:37) harves: yeah. i think what i sent reinouts was basically h18 + kikidonk's python fix.
(22:23:48) reinouts_: that's right
(22:24:04) harves: ok, then h18 is up-to-date and should be ready to merge.
(22:24:16) harves: though it's written for 1.8... guess i should update for cvs hey?
(22:24:39) chpe: I think it should apply mostly clean, not many changes in src/bookmarks/ since then
(22:25:07) harves: will try a cvs update now. move to other things on agenda?
(22:25:12) reinouts_: there are two bugs with 'harves' keyword in bugzilla, they should be looked at when the patch is in
(22:25:39) chpe: I think all bugs in 'toolbar' category needs looking at if they're fixed by this
(22:26:00) chpe: so, that was 3.
(22:26:07) harves: should i reply to every bug i think is fixed by my patch, or what?
(22:26:12) reinouts_: the next point on the agenda was about the Suggestions page on the wiki
(22:26:15) reinouts_: which is also down :(
(22:26:18) philipl: *grumble*
(22:26:23) crispin: grr
(22:26:35) kikidonk entered the room.
(22:26:37) #epiphany: mode (+o kikidonk ) by Zeus
(22:26:42) harves: anyone have a cache of it?
(22:27:21) chpe: well, then 5: extensions
(22:27:26) crispin: I'm wondering if archive.org does
(22:27:40) crispin: ok, so extensions, they rock :-)
(22:27:42) reinouts_: there's one thing I clearly remember from that page, it was a request for a keyboard shortcut to focus the address bar and paste the clipboard there at once
(22:28:01) adamh: Google Cache?
(22:28:05) nimeplux: http://www.cache.com/
(22:28:15) crispin: reinouts_: hmm, sounds like something an extension could do rather than ephy proper
(22:28:25) adamh: Google Cache has it
(22:28:29) nimeplux: http://www.google.com/help/features.html
(22:28:33) crispin: http://tinyurl.com/75ll8
(22:28:42) crispin: ^^ the google cache
(22:28:53) reinouts_: yeah, i have it
(22:29:03) adamh: reinouts_: That sounds like a pretty esoteric feature
(22:29:36) adamh: (was there a use case? middle-click always does the trick for me)
(22:29:56) reinouts_: adamh: middle click is disabled by default
(22:29:57) crispin: the middle click thing is a gconf option
(22:30:01) adamh: oh
(22:30:02) harves: to be honest, i would like ctrl+shift+L to focus the first field in the current page.
(22:30:15) kikidonk: has the meeting started ?!
(22:30:24) reinouts_: kikidonk: half an hour ago :)
(22:30:27) philipl: Well, on the subject of keyboard navigation, I was mentioning last night that the keyboard event handling workaround (not a hack, thanks tko :-) from galeon should be ported over. It will make EMACS keybindings work if they're active.
(22:30:29) kikidonk: oh shit
(22:30:31) harves: kikidonk: do you want a log? :)
(22:30:40) adamh: Maybe Ctrl-V should do the same thing as middle-click?
(22:30:41) kikidonk: i'll read it when it's over i guess
(22:31:05) chpe: kikidonk: since bugzilla is down, we've only talked about harves' patch so far
(22:31:10) kikidonk: lol
(22:31:12) crispin: kikidonk: summary so far: harves patch is going in
(22:31:16) kikidonk: perfect day for a bugzilla outage
(22:31:19) kikidonk: cool !
(22:31:23) kikidonk: any schedule ?
(22:31:28) reinouts_: adamh: does nothing break with that?
(22:31:33) chpe: kikidonk: as soon as I can apply it
(22:31:35) harves: current log at http://www.dsl.uow.edu.au/~harvey/epiphany.txt
(22:31:47) reinouts_: just binding Ctrl+V to 'paste url into address bar' sounds a bit too simple to work ;)
(22:31:57) adamh: reinouts_: Beats me. Seems a bit scary, people might press Ctrl-V in the wrong window and be surprised at its behavior.
(22:32:10) adamh: (Or meaning to paste into an input element)
(22:32:24) reinouts_: adamh: yeah, that's the bigger problem
(22:32:33) adamh: But Ctrl-L, Ctrl-V, Enter works?
(22:32:52) crispin: yep, that works
(22:32:53) reinouts_: adamh: it works, but there's a request for a shortcut that does all 3 at once
(22:33:01) adamh: Sheesh
(22:33:23) philipl: Can't this be an extension?
(22:33:25) crispin: I say, 'crack'; do it in an extension :-)
(22:33:33) adamh: Definitely
(22:33:42) harves: fwiw, is there any shortcut to get to the first field in the current page?
(22:33:43) adamh: I wonder if the guy who suggested it simply doesn't know about middle-click
(22:33:52) chpe: we need a GNOME Macro Recorder :)
(22:33:56) adamh: Maybe we should make middle-click an option in the prefs page?
(22:34:12) reinouts_: adamh: nah, that doesn't really help
(22:34:26) reinouts_: adamh: it's already in gconf for people who need it
(22:34:38) reinouts_: adamh: plus, there are multiple extensions already claiming the middle mouse button
(22:34:40) chpe: adamh: it's quite easy to mis-middle-click with a scroll wheel, so I don't think it's good to enable by default
(22:34:44) reinouts_: gestures and autoscroll
(22:35:05) crispin: I think the middle click paste should be an extension ....
(22:35:10) chpe: philipl: how clean is that 'workaround'? it just passes the event first to the GtkEntry?
(22:35:20) adamh: chpe: That's a great idea
(22:35:23) philipl: chpe: it's a bit more general than that.
(22:35:24) adamh: :s/chpe/crispin
(22:35:42) philipl: It passes events to the current focused widget, and if they're handled that's it.
(22:35:50) philipl: Otherwise, it follows the standard path - basically.
(22:36:11) crispin: I think it only kicks in for when the key theme is Emacs
(22:36:20) crispin: (we had loads of problems initially ....)
(22:36:22) philipl: Yeah, which is a bit dubious to be honest.
(22:36:23) reinouts_: then we get to the point of having extension dependencies and mutually excluding extensions
(22:36:43) philipl: but it works great now :-)
(22:36:45) kikidonk: is that a bit overkill ?
(22:36:47) reinouts_: being able to activate 3 extensions that all do sth with middle mouse...
(22:36:53) reinouts_: is asking  for problems
(22:36:54) tko: you need to have similar event routing in dialogs where you have a text entry and a 'delete' shortcut in menus
(22:37:06) adamh: reinouts_: Gestures and middle-click-paste work well together
(22:37:23) adamh: But autoscroll would conflict with both, right?
(22:37:29) kikidonk: also people areable to figure out some extensions will conflict
(22:37:30) chpe: adamh: yes
(22:37:31) crispin: yeah
(22:37:59) crispin: shall we continue discussing that suggestions page, and then come on to extensions ?
(22:38:06) reinouts_: yes
(22:38:09) chpe: ok
(22:38:16) crispin: there is a lot of stuff on that page :-/
(22:38:23) reinouts_: "Add F5 as another shortcut to refresh the page, instead of just CTRL-R."
(22:38:30) chpe: next: F5... evince uses it for presentation mode not reload...
(22:38:31) philipl: GTKUIManager sucks.
(22:38:45) chpe: s/sucks/has a few shortcomings/ :)
(22:38:52) philipl: you get the point :-)
(22:38:56) chpe: philipl: like you need a new action just for a new keybinding
(22:38:59) harves: philipl: i hope not. it's used all the way through the bookmarks presentation code. :)
(22:39:00) philipl: yep.
(22:39:03) adamh: F5 works on FF, right?
(22:39:13) marco_ left the room (quit: Remote closed the connection).
(22:39:14) kikidonk: f5 is wondows-esque
(22:39:17) crispin: adamh: I don't think so
(22:39:20) kikidonk: i wonder if f5 reooads in nautilus
(22:39:21) philipl: harves: I was just referring to needing to duplicate an action to get a second key binding.
(22:39:34) chpe: kikidonk: yes
(22:39:35) harves: philipl: ah, ok. hadn't done that yet. :)
(22:39:35) adamh: crispin: Just tested, it does
(22:39:38) kikidonk: oh yes
(22:39:41) crispin: adamh: oh ok
(22:39:50) adamh: They have to, 'cuz they're on Windows
(22:39:50) kikidonk: so they have both ctrl-r and f5
(22:40:07) adamh: yeah, and then Ctrl-Shift-R as well (we have that too)
(22:40:10) chpe: so: nautilus + ff: F5=reload, evince:F5=something else. sucks
(22:40:16) philipl: We don't have backspace for go-back either...
(22:40:50) crispin: if nautilus has f5 = reload, I think ephy should too
(22:40:51) reinouts_: philipl, no but iirc there was a rationale behind it
(22:41:00) crispin: and then we can persuade evince to change
(22:41:09) reinouts_: mpt would remembre what it was
(22:41:18) chpe: crispin: sounds like a plan! /me concurs
(22:41:23) adamh: yeah
(22:41:24) kikidonk: but it's kind of stupid to have two keys to achieve the same thing in every app
(22:41:27) kikidonk: just because windows has it
(22:41:27) reinouts_: it would break in text forms, anyhow
(22:41:38) philipl: heh. Well, I can't remember the rationale for why it's not in galeon. I assumed it was the whole multiple-keybindings problem.
(22:41:53) adamh: I don't like backspace for go-back -- I've seen people browsing the 'web hitting Backspace to delete text when not being right in a form field.
(22:41:56) crispin: kikidonk: we don't document the F5, it just helps the user experience for windows users
(22:41:59) chpe: reinouts_: it's because if you backspace while you think you're in a form but actually are not, it goes back and you lose
(22:42:05) kikidonk: oh right
(22:42:10) reinouts_: kikidonk: there's another bug asking for alt+d focusing the address bar like ie
(22:42:17) reinouts_: chpe, indeed
(22:42:25) chpe: right, same as nautilus, Ctrl-R in the menu but F5 works
(22:42:26) kikidonk: yeah, well that's less conflicting
(22:42:29) crispin: reinouts_: ff has alt+d focussing the address bar
(22:42:36) philipl: reinouts_: can't we just make gtk re-mapping work and let people do their own thing?
(22:42:51) reinouts_: crispin: it would break in the duth translation, because alt+d is the accelerator for the view menu
(22:42:52) adamh: reinouts_: *ALT*? How many alt keybindings are there in GTK apps?
(22:42:52) crispin: gtk re-mapping does work, its just off by default :-(
(22:42:56) kikidonk: the problem is that it's not easy to know it works like that
(22:43:25) kikidonk: and it should be turned on, too
(22:43:32) crispin: reinouts_: ahh, good point
(22:43:39) reinouts_: adamh, and *then* there's the issue of forms supporting accelerator keys
(22:43:50) ***adamh is guessing Microsoft realized that alt-D was a mistake and is stuck with it, why should we copy their mistake?
(22:43:58) crispin: yeah, we shouldn't use alt+<x> for anything other than the menus
(22:44:07) reinouts_: an important issue for a11y
(22:44:20) crispin: ok, next?
(22:44:24) chpe: ok, next 
(22:44:31) reinouts_: CTRL-arrows (up, left, down) do the same thing as (or instead of) ALT-arrows (up, back, forward). -- KristofferLunden
(22:44:42) chpe: Ctrl/Shift+Enter is going to be reserved for new tab/window IMHO
(22:44:55) crispin: ctrl+arrows are used by metacity
(22:45:00) philipl: Right.
(22:45:02) adamh: chpe: THat's what I figured
(22:45:07) crispin: I doubt ephy even sees them
(22:45:12) adamh: crispin: They are? What do they do?
(22:45:17) philipl: workspaces.
(22:45:22) tko: I'd add Ctrl/Shift+<anything> should be handled consistently
(22:45:23) reinouts_: crispin: are they? Ctrl+left arrow would make a better Back accelerator than Alt+left arrow
(22:45:24) kikidonk: workspace is ctrl+alt
(22:45:27) harves: ctrl+alt+arrow and ctrl+alt+shift+arrow are what i use in metacity
(22:45:34) reinouts_: (AltGr+left arrow doesn't count)
(22:45:34) adamh: harves: ditto
(22:45:43) tko: crispin, the defaults are ctrl+alt+arrow, but I also find ctrl+arrow much more convenient
(22:45:57) reinouts_: ok, so basically ctrl+arrow is out of the question?
(22:46:00) crispin: hmm, maybe I had an odd setup, I use ctrl+arrow to move workspace, and ctrl+alt+arrow to move windows around
(22:46:01) kikidonk: i think so
(22:46:07) adamh: IMO ctrl+arrow would be good
(22:46:26) reinouts_: I'd like to have it if it's not overridden by metacity
(22:46:28) adamh: one-handed navigation is really useful
(22:46:30) tko: but IIRC in some cases Ctrl+left should skip words
(22:46:36) reinouts_: yes, in textfields
(22:46:42) harves: ctrl+arrow moves around word-by-word in abiword, so yeah
(22:47:01) reinouts_: harves: it does in any gtk text entry
(22:47:17) harves: k
(22:47:28) reinouts_: so do we then have the same problem as with Backspace?
(22:47:39) tko: that too should almost "just work" if you do the keyevent workaround :)
(22:48:24) reinouts_: keyevent workaround?
(22:48:33) philipl: reinouts_: as mentioned above.
(22:48:35) philipl: from galeon
(22:49:08) tko: reinouts_, making sure keyevents are passed to currently focused widget first before considering global keyboard shortcuts (as defined in menus)
(22:49:39) reinouts_: tko: yes, but what if you mean to move back a word in a text entry but wrongly assume it is focused?
(22:49:59) kikidonk: we can't have that
(22:50:03) kikidonk: it always happen to me
(22:50:23) crispin: reinouts_: is that an argument for or against ctrl+arrows to go back / forward / up ?
(22:50:28) tko: hmm.. the 'NextPlease' suggests ctrl+right to load the 'next' link (as in google results)
(22:50:28) kikidonk: against
(22:50:35) reinouts_: against
(22:50:38) philipl: It seems that sticking with alt is safer in this matter.
(22:50:55) crispin: chpe, views ?
(22:51:01) adamh: yeah, I agree. Shame, it seems like ctrl+arrow would be useful :)
(22:51:34) chpe: I think it's better to leave ctrl-arrow as is
(22:51:59) reinouts_: we also have the scrollwheel trick to move through history, although that doesn't help for keyboard only browsing
(22:52:14) chpe: about that "Next please" thing: we should support <link> navigation
(22:52:32) adamh: chpe: Yeah :)
(22:52:36) adamh: Extension?
(22:52:40) kikidonk: does firefox support it ?
(22:52:40) reinouts_: chpe: was there no bug for that yet?
(22:52:50) chpe: adamh: yes
(22:52:55) adamh: kikidonk: Mozilla Suite does, it's got an awesome "navigation bar"
(22:52:59) kikidonk: oh
(22:53:04) chpe: reinouts_: I think there's a bug with a patch, for galeon
(22:53:08) kikidonk: i think we have a 'link' signal
(22:53:09) tko: so far the biggest problem with <link>s is IMHO the UI
(22:53:13) kikidonk: so extension could catch it
(22:53:18) crispin: chpe, totally bit-rotted
(22:53:19) reinouts_: nice, is that something for 1.10 then?
(22:53:22) adamh: tko: Wasn't the Mozilla UI nice?
(22:53:33) chpe: kikidonk: atm it's only emitted for favicon and rss links
(22:53:38) adamh: Oh, and maybe some entries in the Go menu?
(22:53:40) kikidonk: can we stick two button in the bottom right corener ?
(22:53:48) kikidonk: chpe: it can be extended, though
(22:53:55) chpe: reinouts_: e-e 1.10 maybe, if we can think of good UI and someone to write it 
(22:53:55) reinouts_: right, the Go menu, we need to discuss that too
(22:54:05) tko: adamh, there was something not so right about it, but I've forgot
(22:54:18) philipl: I think we discussed putting them in the go menu for galeon.
(22:54:27) philipl: Maybe we were just lazy but it didn't happen :-)
(22:54:35) adamh: kikidonk: <link> gives lots more than 2 buttons. There's back/forward/up, home, authors, and more too I think
(22:54:42) tko: I guess it was that it takes quite a bit of space (I think doing it in ephy would take more space than in mozilla)
(22:54:47) adamh: kikidonk: Where authors is a link to every author's homepage
(22:54:49) chpe: it would fit better under "Go" than what's currently there, the pseudo-history items
(22:54:52) reinouts_: chpe, how about that? we wanted to get rid of the most-visited links in the Go menu anyway
(22:55:20) tko: galeon1.2 had the toolbar item, but it was very badly visible and not too accessible
(22:55:22) adamh: tko: Yeah, but in Mozilla at least it'd only show up when desired
(22:55:35) crispin: how many users browse sites with proper <link> tags that are useful ?
(22:55:41) marco_ entered the room.
(22:55:43) philipl: The main concern to my mind is go-back/forward in the menu vs. the <link> back/forward.
(22:55:44) chpe: we can try it, yes... but I think it should have a toolbar representation too, maybe just a drop-down with the links
(22:55:44) #epiphany: mode (+o marco_ ) by Zeus
(22:55:45) tko: crispin, how would you know? :)
(22:55:48) adamh: crispin: Hardly any -- definitely extension material :)
(22:55:48) chpe: crispin: google
(22:55:58) adamh: chpe: Really? Oh
(22:56:15) reinouts_: wb marco_
(22:56:22) chpe: hmm apparently not, I thought it had them
(22:56:29) adamh: chpe: Nope
(22:56:57) adamh: That'd be awfully useful, though. I can't imagine anybody would find that toolbar annoying if it showed up on a Google results page :)
(22:57:05) kikidonk: chpe: would it be possible to have a "drop-down" toolbar ?
(22:57:15) kikidonk: that only appear when hitting a key combo ?
(22:57:19) tko: for most people I'd assume just having two or three buttons (next, prev, everything else) clearly visible would be nice
(22:57:37) adamh: tko: "up" is just as useful as next/prev, I find
(22:57:50) chpe: kikidonk: with harves patch we can show/hide individual otolbars, but a whole tb just for some items...
(22:57:51) kikidonk: (and doesn't resize the view)
(22:57:54) adamh: e.g., I find a manual in my Google results, and then I want to navigate to the correct chapter
(22:58:00) reinouts_: I dare say Up is more useful than Forward
(22:58:13) philipl: kikidonk: We (vmware) actually released a slider widget in our library. You could actually do it.
(22:58:21) adamh: reinouts_: I wouldn't go that far :)
(22:58:36) kikidonk: maybe we could have those navigation items in a drop down toolbar
(22:58:45) tko: but anyhow, even with two buttons you still have a problem with placement
(22:58:45) reinouts_: adamh: if/when temporal back gets implemented, noone needs Forward anymore
(22:58:52) kikidonk: so if you need them, you show them by hitting a key combo
(22:59:06) tko: if you put everything in one toolbar button dropdown it's like galeon1.2 and no one will notice
(22:59:15) crispin: hmm, we aren't getting on very fast with the suggestions page .....
(22:59:26) adamh: Anyway, navigation is definitely an extension, right?
(22:59:33) kikidonk: yes
(22:59:35) adamh: So whoever authors it gets to decide on the UI :P
(22:59:42) kikidonk: :D
(22:59:43) crispin: yes (at least to start with)
(22:59:47) tko: to summarize: <link> support would be nice, but...? :)
(23:00:04) reinouts_: right, let's move on to the TLD shortcuts then
(23:00:10) adamh: tko: But it'll be an extension :)
(23:00:40) philipl: TLD shortcuts: The ctrl-k thing reminds me that having keybindings for smart bookmarks to focus the entry would be slick.
(23:00:41) tko: adamh, yeah, but might need a bit of support from core if that one signal isn't emitted for all links atm
(23:00:50) crispin: as stated before Ctrl+(+shift)+Enter will be for open in new tab
(23:01:12) philipl: I think the rest of that suggestion is crack
(23:01:24) adamh: tko: Well, only to improve latency. We could just walk the DOM after the page is loaded :)
(23:01:46) chpe: crispin: yes, tko: yes, although maybe we could wait for </head> and get them in one go and not emit a signal for (potentially many) <link>s
(23:02:30) kikidonk: is the temporal back forward idea going somehwere ?
(23:02:35) crispin: I think Josephs proposal is just total crack ...
(23:02:36) reinouts_: yes, it should be possible to bind accelerators to smart bookmark entries
(23:02:47) chpe: crispin, philipl :yeah
(23:02:49) tko: chpe, I haven't been able to catch </head> but if you can do that it would help favicon.ico latency...
(23:03:29) tko: reinouts_, would just one shortcut for cycling between them all be sufficient?
(23:03:36) crispin: ok, so onto Session Management ?
(23:03:53) ***crispin is trying to keep things moving ....
(23:03:58) harves: reinouts_: would like to see smart bookmarks placed into a new extension. they're really "user-defined actions on text input" and not bookmarks at all.
(23:04:18) reinouts_: tko: I don't think so, you wouldn't need many shortcuts but each visible one on the toolbar should be able to be binded to one
(23:04:21) philipl: As long as there's an API to save a session that will get picked up at startup, explicit management like galeon can be an extension.
(23:04:38) reinouts_: harves: but they are normal bookmarks if they don't get input
(23:04:42) adamh: Yeah, I've written a "quit" extension and there's another one on bugzilla right now
(23:04:46) reinouts_: that's the beauty
(23:05:04) chpe: tko: I think I had an idea about that, but I can't remember :)
(23:05:08) philipl: adamh: so the current session api is good enough?
(23:05:15) harves: reinouts_: but it seems to me to be overloading it. a google search query with an empty query is not really the same as just going to the google site.
(23:05:18) tko: the smart URL should just be an extra attribute for a bookmark
(23:05:26) harves: (perhaps google a bad example, but you get the idea)
(23:05:42) adamh: philipl: API? Yeah, we could have stored sessions, load-special-session-on-first-open... that'd all work fine in extensions, from either Python or C.
(23:05:44) tko: the current way of searching for empty string doesn't quite work
(23:05:49) chpe: yeah that's one of the needed extensions to the ext iface probably
(23:05:56) chpe: (adding custom fields)
(23:06:02) philipl: adamh: ok, good.
(23:06:05) kikidonk: harves: currently a smart google bookmark you click brings you to google.com
(23:06:08) reinouts_: tko: and there should be a way to construct a smart bookmark from a query form-- ff can do this already
(23:06:38) adamh: We could do that with an extension
(23:06:39) tko: so you just need a way to extend the bookmark properties UI and you could do the whole smart URL thing (including keywords) as an extension
(23:06:44) adamh: Would be especially easy with PyXPCOM
(23:06:45) kikidonk: yes ! intercepting the POST and matching against the form input
(23:07:03) harves: i dunno, i just see smart bookmarks as user actions on text strings. for example, i would like one that takes comma separated input and fills in various fields for me, not just one.
(23:07:12) ***reinouts_ sees a new extension growing here ;)
(23:07:29) kikidonk: reinouts_ how does firefox does that ?
(23:08:03) reinouts_: kikidonk: I don't know exactly _how_ but you can rightclick a form field and select some option to make it a query
(23:08:05) reinouts_: lemme see
(23:08:10) tko: kikidonk, not just POST, but also GET
(23:08:22) tko: right-click on the submit button?
(23:08:31) reinouts_: no, the field iirc
(23:08:42) kikidonk: hmm
(23:08:50) kikidonk: something more like the RSS feed icon would be handy
(23:08:55) reinouts_: ah yes
(23:08:59) tko: ah, yeah, then that field becomes the smart entry
(23:09:18) reinouts_: right click a field and then there is the option 'add keyword for this query'
(23:09:42) adamh: Not all that tricky to do, especially if you only do it for GET
(23:09:52) adamh: (I think there's no good reason to do it for POST)
(23:10:44) tko: yeah, you shouldn't be making bookmarks that do POST when selected
(23:10:53) kikidonk: indeed
(23:11:06) kikidonk: maybe we should be more clever, anddo that on bookmark ctrl-d
(23:11:13) kikidonk: so you search in google
(23:11:20) kikidonk: have the result, hit ctrl-d
(23:11:34) kikidonk: and the add bookmark dialog allows you to select fields to turn into a smart query
(23:11:49) adamh: Bah, much easier to just right-click on the Google input and click "Make into Smart bookmark"
(23:12:00) kikidonk: like 'What did you search for ?' : [list of fields content]
(23:12:03) reinouts_: but less discoverable
(23:12:05) adamh: The name would be <title>, the favicon would work...
(23:12:07) kikidonk: less discoverable
(23:12:13) kikidonk: and not nice for lambda users :)
(23:12:22) tko: you can have both :)
(23:12:25) kikidonk: yep
(23:13:35) chpe: ok, next one?
(23:13:47) reinouts_: is anyone taking this?
(23:14:13) kikidonk: i'd love to do it
(23:14:14) tko: session management is something for an extension? needs little help from core to get extension running early enough, I guess?
(23:14:16) crispin: yeah, we need to keep this meeting moving ....
(23:14:23) kikidonk: time permitting
(23:14:34) reinouts_: right, sessions, my opinion is clear from the wikipage :)
(23:14:55) adamh: tko: The one on b.g.o detects when it's the first window, and it closes the window right after it's opened....
(23:14:58) philipl: reinouts_: as long as the api is accessible to an extension, there's no problem
(23:14:59) bruci entered the room.
(23:15:07) crispin: philipl: nod
(23:15:08) chpe: tko: yes, ext, and needs a tiny bit of help from core. maybe just a way to tell ephy to try session file f instead of session_crashed.xml on startup
(23:15:18) reinouts_: philipl: I'm not objecting to an extension
(23:15:30) philipl: chpe: right. I need this to make galeon style management an extension.
(23:15:57) crispin: someone could also use that to make a g1.2 session management extension ...
(23:16:01) tko: I guess you only need attach_session / detach_session callbacks
(23:16:16) kikidonk: a session is a set of pages to be opened ?
(23:16:21) tko: or _shell
(23:16:23) crispin: ok, that sounds like a plan, next "Scrolling"
(23:16:31) chpe: kikidonk: yes
(23:16:44) adamh: Should autoscrolling be in core? It is in firefox and in msie
(23:16:46) crispin: there doesn't seem like much ephy can do there, it appears to be all gecko probs
(23:17:02) philipl: yeah. the inappropriate events is a gecko issue.
(23:17:12) tko: I think it even boils straight down to the plugin
(23:17:12) crispin: adamh: it's pure crack IMO (and I wrote the extension) :-)
(23:17:19) adamh: That would postpone our "extension conflicts" problem -- loading the gestures extension would simply override the default ;)
(23:17:21) chpe: yeah, and it only occurs on suite not ff backend, right?
(23:17:31) kikidonk: and autoscroll icon is dreadful
(23:17:50) crispin: kikidonk: oh yeah, I mean't to change that for something else
(23:17:56) kikidonk: :)
(23:18:07) kikidonk: are there actually people using middle scroll ?
(23:18:09) tko: crispin, ask tango project? :)
(23:18:14) adamh: I'm not particularly a fan of autoscroll, but IMHO there isn't much of a reason to deviate from FF/MSIE
(23:18:16) chpe: yeah the icon can be improved
(23:18:17) kikidonk: it's so unuseful..
(23:18:18) reinouts_: weren't there problems with not being able to get out of autoscroll mode?
(23:18:31) reinouts_: same thing that was a problem for gestures iirc
(23:18:45) reinouts_: the X cursor being locked
(23:18:49) adamh: reinouts_: I *hate* that, I ought to try and track it down again :)
(23:18:50) chpe: adamh: there was a bug about autoscroll for ephy from daveb, I closed it when I checked the ext in...
(23:19:05) chpe: adamh: I don't know what people expect on middle click
(23:19:11) tko: but gtk2.8 has new 'grab-broken' signals or something, I think.. one might be able to fix it
(23:19:26) crispin: chpe did for ephy :-)
(23:19:28) chpe: tko, reinouts_: I fixed that problem already
(23:19:29) adamh: I don't think many people expect autoscroll :P
(23:19:39) kikidonk: noone expect autoscroll it's broken
(23:19:41) adamh: tko: Oh, really? Wow... what a bizarre signal :)
(23:19:46) kikidonk: and it's a 1996 "feature"
(23:19:55) kikidonk: i vote to get rid of it
(23:20:14) crispin: kikidonk: its just an extension ....
(23:20:17) kikidonk: how often do i click just beside a link and enter in autoscroll
(23:20:18) kikidonk: yes
(23:20:20) kikidonk: true
(23:20:23) kikidonk: i should disable it :)
(23:20:34) chpe: let's keep it as ext  only
(23:20:39) crispin: yeah
(23:20:41) reinouts_: autoscroll is a bit redundant with the advent of scrollwheels, true
(23:20:44) crispin: (with a better image)
(23:20:57) crispin: reinouts_: it is vaguely useful on laptops
(23:20:59) chpe: crispin: file a bug when bugzilla works again :)
(23:21:18) crispin: someone should distill this meeting into a list of actions
(23:21:32) crispin: ok, "Tabs and Windows"
(23:21:46) crispin: we would love to fix the _blank problem :-)
(23:21:49) philipl: Does epiphany treat "new window" targets as new windows right now? It should be new tabs...
(23:21:52) kikidonk: oh yes
(23:22:10) kikidonk: some time ago i was told this was a gecko bug ?
(23:22:12) chpe: unless someone has an idea how to get that info (_blank, or just a popup window) from gecko...
(23:22:18) kikidonk: ha !
(23:22:33) philipl: chpe: you can get the target. sidebar code does it.
(23:22:43) kikidonk: but also
(23:22:59) kikidonk: sometimes you have forms with a ? button tight beside it
(23:23:03) chpe: philipl: how? we just get chrome mask in the new-window signal
(23:23:12) kikidonk: when you click it opens a new page with a little help blurb
(23:23:13) reinouts_: philipl: ephy was designed in principle as SDI, *if* you're going to do a new tab instead, it should get focus and not open in the background
(23:23:23) kikidonk: if we open that in a new tab, things can get broken
(23:23:28) philipl: reinouts_: sure. That's a separate complaint :-)
(23:23:48) adamh: Yeah, definitely don't open tabs in background. (As a separate complaint, there's no notification when a 6th or 7th tab is opened)
(23:24:04) kikidonk: GtkNotebooks problems :)
(23:24:12) kikidonk: seems like everyone is complaining about it
(23:24:32) crispin: I love tabs opening in the background ... :-)
(23:24:36) philipl: chpe: that's the wrong time to check. You have to pick it up from the originating page.
(23:24:47) reinouts_: kikidonk, adamh: true, that's why I always resist people asking for opening everything and your grandmother in a new tab
(23:25:08) tko: I suppose you can detect when a new popup window is sized before it's made visible? so if it's not specifying any particular size and/or chrome, you could stick it in the notebook
(23:25:25) philipl: chpe: In galeon there is DOM walking code that picks it up.
(23:25:27) kikidonk: tko: that could ba an approach yes
(23:25:41) kikidonk: so if a popup has size info it's opened as a new window
(23:25:49) adamh: tko: A lot of popups are meant to be annoying but don't specify size, so I don't think that's a good way to make a distinction
(23:25:50) kikidonk: else it's opened as a new tab
(23:26:12) kikidonk: we are talking about useful popups here
(23:26:20) kikidonk: like help popups
(23:26:26) reinouts_: popup blocking is a separate thing
(23:26:28) philipl: re popups in tabs: I may be biased, but I prefer the galeon approach. There's a pref. Check the box and damn the consequences.
(23:26:33) kikidonk: thos which are triggered by manual action
(23:26:45) adamh: Maybe we should just go nuts and remove any "target=_blank" from any <a>. (I could try that as a greasemonkey extension and see how it goes)
(23:26:52) tko: also if you could detect that the only content loaded in a newly created window is download, you might try to close the window
(23:26:58) reinouts_: adamh: nice idea
(23:27:24) chpe: tko: there's a patch in bugzilla for that, I'm just not sure yet I totally like it
(23:27:27) kikidonk: and also see if middle click + javascript ends up calling window.open() open in a new tab rather than in a new empty tab
(23:27:31) chpe: (the patch, not the idea)
(23:27:58) kikidonk: i see that a lot in javascripted image galleries
(23:28:12) kikidonk: you just cannot middle click images because it ries to open the javascript, or something
(23:28:26) reinouts_: kikidonk: that's this? http://www.extensionsmirror.nl/index.php?showtopic=169&hl=disable+targets
(23:28:41) tko: kikidonk, IIRC galeon has a fix for that, middle-clicking on javascript links equals to left-click
(23:28:56) kikidonk: reinouts_ no it's more what tko says
(23:29:02) reinouts_: ok..
(23:29:03) adamh: sounds like the right fix
(23:29:10) kikidonk: that's a good wrokaround
(23:29:23) kikidonk: but it will still open a new window instead of new tab
(23:29:46) tko: kikidonk, but that's already a different problem :)
(23:30:03) kikidonk: why ? i think it's a Single problem
(23:30:18) tko: middle-click on javascript is one, window.open() is another
(23:30:19) chpe: philipl: are you sure? I don't see DOM walking code for that in galoen... afaics it just always or never opens in new tab
(23:30:47) kikidonk: tko: i want middle-click+window.open() == tab.open()
(23:31:29) tko: kikidonk, that might be possible
(23:32:04) philipl: chpe: look at galeon-sidebar.c
(23:32:14) philipl: It reacts to the link_target attribute
(23:32:14) reinouts_: ok, next, variable width tabs not possible without gtk support...
(23:32:22) philipl: which we extract in the DOM code.
(23:32:27) kikidonk: variable width tabs are evil
(23:32:43) reinouts_: kikidonk: but invisible opening tabs are, too
(23:32:44) philipl: chpe: rather, we extract with DOM code. It's a generic property getter
(23:32:55) kikidonk: having variable width tbs is not a good fix
(23:33:11) tko: reinouts_, I don't fully understand, by default tabs are variable width in notebook
(23:33:16) philipl: flash the scrollbuttons of the notebook
(23:33:23) ***adamh much prefers non-variable-width
(23:33:36) kikidonk: make a dropd down menu for next/back button in gtknotebook ?
(23:33:51) chpe: philipl: ah I see now
(23:34:10) reinouts_: kikidonk: good idea, but totally undiscoverable
(23:34:15) tko: philipl, I was thinking about showing partial tab on the left/right side to indicate more clearly there are more tabs in the notebook
(23:34:26) kikidonk: make that and the flashing ?
(23:34:34) kikidonk: cause now it's unbearable
(23:34:44) kikidonk: you have to click on the rightmost item, then click the next button
(23:34:45) reinouts_: kikidonk: a solution in OS/2 Warp4 notebooks was to display the next tab for 1/2
(23:34:49) chpe: tko: I tried the ff approach (1/N width), but gtknotebook didn't cooperate, some tabs got the new width others the old one, until resize, or new tab, or whatever
(23:34:50) philipl: tko: escher style? :-)
(23:35:08) reinouts_: so you know that there's something following the current one
(23:35:19) kikidonk: ah yes, that'b be good too
(23:35:25) tko: philipl, I've no idea what you mean
(23:35:26) kikidonk: but please no varible width tab s
(23:35:47) reinouts_: (btw offtopic but I always enabled  single row colored tabs in OOo, but they removed that option in OOo2 :-/ )
(23:36:17) chpe: next?
(23:36:17) adamh: A very common use case for me is I open a shitload of tabs and then sift through them. I hover over the "tab-close" button and I click it on every tab I've lost interest in. (usually 3-4 in a row)
(23:36:20) philipl: tko: the infinite line. The current tab is always in the centre and then going outward, each tab is shorter, so all of them are on screen but shrinking as you move outward.
(23:36:28) philipl: It's a terrible idea but would look cool :-)
(23:36:31) kikidonk: adamh: same here
(23:36:33) adamh: lol
(23:36:34) reinouts_: anyone know if it'd be feasible to patch gtknotebook to display the half of the next tab in overfow situations?
(23:36:54) kikidonk: philipl: that's cool !
(23:37:05) tko: reinouts_, I don't know about half, I was thinking just enough to see the curvature
(23:37:09) chpe: reinouts_, don't think so, gtknotebook is scary
(23:37:18) harves: would it help to have an overflow menu like the toolbar, but with "7 more" or similar written there?
(23:37:20) reinouts_: philipl: I'd rather see a kazehakase-style sidebar list with all opened pages
(23:37:22) tko: philipl, hmm.. sounds interesting and unusable :)
(23:37:41) harves: would mean that when a new tab is open you at least get some indication that it did really open (the number goes up)?
(23:37:44) adamh: Sounds a bit like the Mac OSX launch bar thingy
(23:37:53) kikidonk: indeed
(23:37:53) harves: and have quick access to any tab via a drop-down
(23:38:07) kikidonk: and hovering the mouse on it widens the hovered tab :)
(23:38:13) philipl: kikidonk: haha. quite
(23:38:17) adamh: harves: I was thinking of that (tabs dropdown)... we *do* have the tabs menu, though
(23:38:35) adamh: kikidonk: And whenever your mouse goes towards the close button, the close button runs away :)
(23:38:41) tko: kikidonk, oh, like mac os panel or whatnot.. might not be too bad
(23:38:56) harves: adamh: good point, though having the tab list at the bottom is annoying. beyond "detach tab" there's nothing else i use that menu for.
(23:39:04) reinouts_: this is a useless discussion as long as noone dares touch gtkntebook code
(23:39:06) adamh: harves: Ditto
(23:39:11) adamh: lol
(23:39:25) kikidonk: well running owards close button would make it bigger
(23:39:28) tko: reinouts_, yeah, reminds me of that tab dnd patch for gtknotebook...
(23:39:29) philipl: harves: epiphany supports detach tab?
(23:39:29) kikidonk: so it's easier to close a tab
(23:39:46) harves: philipl: it does, but gecko doesn't play nice, so it's disabled in code by default. :)
(23:40:03) philipl: harves: that doesn't stop galeon :-)
(23:40:26) harves: philipl: it's some bug related to javascript iirc.
(23:40:43) philipl: harves: this is the grey window bug?
(23:40:43) tko: btw, anyone thought of doing something like eclipse and showing the close button only when the mouse is hovering over the tab? (probably bad if you happen to click straight to the right edge..)
(23:40:43) reinouts_: harves: dropdown boxes don't work anymore
(23:40:55) chpe: philipl: no that's a different problem
(23:41:03) adamh: tko: I *hate* that!
(23:41:05) chpe: harves: no it's a bug in the widget code, not in js
(23:41:09) ***adamh is using Eclipse right now :)
(23:41:09) harves: adamh: ah! just realised why the tabs menu doesn't work for me though. it shows all the tabs that i can already see. i just want a list of those that i can't, and a count of them so i get feedback
(23:41:16) reinouts_: tko, showing/hiding widgets based on mouse movement is not so nice
(23:41:40) tko: oh yeah, there was a nice suggestion for tabs menu from someone I forgot
(23:41:50) adamh: When I want to close a tab, I have to go to a place where there *isn't* a frickin' close button
(23:41:56) adamh: And Ctrl-W doesn't work, too...
(23:42:03) philipl: the eclipse style is non-sensical anyway. You don't save any space and you're no less likely to accidentally close a tab.
(23:42:03) adamh: I've been using Eclipse all morning...
(23:42:05) adamh: </rant>
(23:42:15) tko: the menu should somehow reflect the visible state of the tabs, so that you have some grouping like <tabs to the left of visible area> <visible tabs> <tabs to the right>
(23:42:33) reinouts_: tko: good, then only the visible ones need an accelerator
(23:42:48) reinouts_: (or do they?)
(23:43:11) tko: oh and the menu should also include tab states
(23:43:51) tko: reinouts_, tough question, then the accelerators would change kind of randomly
(23:44:04) tko: in a way it would make sense, but otoh..
(23:44:27) reinouts_: you know which Alt+number to use by its position counting from the left of the scren
(23:44:29) reinouts_: *screen
(23:44:39) reinouts_: (hmm would this work the other way in RTL locales?)
(23:44:58) adamh: reinouts_: Accelerator should be for all of them, IMO
(23:45:17) adamh: reinouts_: use case: I'm on tab 0. I go alt-9, alt-0. I wanted to go to tab 9 and back to tab 0...
(23:45:25) reinouts_: adamh: what about tab 11 then?
(23:45:26) tko: <press alt> 1 2 3 <release alt>
(23:45:57) adamh: reinouts_: I've never had too much of a problem with that... after 10 tabs nobody knows which is which anyway :P
(23:46:03) reinouts_: heh
(23:46:08) tko: that is true :)
(23:46:35) reinouts_: I still think a sidebar list of open pages is a big part towards a solution
(23:46:49) kikidonk: with thumbnails
(23:46:51) reinouts_: (in the sidebar extn then)
(23:47:00) philipl: reinouts_: Could prototype it in the sidebar extension :-)
(23:47:08) tko: undo close tab is an interesting problem also
(23:47:21) chpe: yeah a prototype impl as extension
(23:47:36) reinouts_: tko, yeah, we talked about it a little bit already
(23:47:53) philipl: of course, a really cheap prototype is just to put the tabs on the side of the notebook :-)
(23:48:21) tko: it's a bit of extension to history. currently history is enter-only as far as I've seen, you'd need to extend it to consider entering and exiting the page
(23:48:33) chpe: philipl: yeah, that's 2 lines of python extension code 
(23:48:46) tko: chpe, you still need that import epiphany? :)
(23:48:59) reinouts_: tabs just aren't as useful anymore after > 4 or 5 ones
(23:49:02) reinouts_: you need a list
(23:49:09) ***kikidonk agrees
(23:49:13) kikidonk: with thumbnails :)
(23:49:18) ***reinouts_ agress :)
(23:49:22) reinouts_: *ees
(23:49:24) chpe: tko, I think so, yes.
(23:49:42) kikidonk: and fir the undo
(23:49:54) kikidonk: would you expect undo to work also to undo clicking on a link ?
(23:49:55) adamh: chpe: *extension* code? Just use the python console :)
(23:50:10) chpe: adamh: right :)
(23:50:21) tko: so.. still keeping the tabs and no one's writing the one true window manager, eh? :)
(23:50:54) reinouts_: tko, maybe we should have invited elijah here ;)
(23:51:24) reinouts_: go on to the next item?
(23:51:34) chpe: adamh: window.get_notebook().set_tab_pos(gtk.POS_LEFT)
(23:52:01) chpe: so the decision was "someone try to write a tabs sidebar" ?
(23:52:04) chpe: ok, next :)
(23:52:07) adamh: chpe: lol, I *LOVE* the Python Console!
(23:52:17) adamh: chpe: Actually, that looks very cool
(23:52:23) tko: offering autocompletion for google form would be nice (wouldn't hurt to have it in the location entry either)
(23:52:40) adamh: I like all those "close" buttons lined up, too :)
(23:52:47) philipl: smartbookmark history like galeon?
(23:52:55) kikidonk: let's move tabs to the left
(23:53:04) kikidonk: :)
(23:53:05) reinouts_: tko, for the location entry it's a gtk shortcoming
(23:53:33) tko: reinouts_, more like overloading one widget to do gazillion things :)
(23:53:42) reinouts_: true..
(23:53:49) chpe: philipl: per smb, or one history for all smbs?
(23:54:23) philipl: chpe: galeon is per smb. Whether you then chose to expose it as a dropdown for the sbm entry like galeon or use that history in the main location entry is a separate issue
(23:54:30) reinouts_: if you have separate smb entries on the toolbar, have separate histories
(23:54:47) tko: chpe, I'd say should be per sbm with the option to have global history available with much lower priority
(23:54:55) reinouts_: in fact why don't smb entries use autocomplete entries?
(23:55:22) kikidonk: slb ? help !
(23:55:25) kikidonk: smb ? help !
(23:55:36) chpe: smart bookmark
(23:55:39) kikidonk: ah :)
(23:55:52) kikidonk: and why forms doesn't autocomplete like mozilla or firefox ?
(23:55:53) philipl: reinouts_: I like that idea.
(23:56:01) philipl: kikidonk: turned off by default.
(23:56:11) kikidonk: but there is no UI to enable it..
(23:56:17) philipl: about:config :-)
(23:56:27) kikidonk: can we have a checkbox in the prefs ?
(23:56:29) tko: hmm.. do you mean autocomplete or autofill?
(23:56:32) chpe: kikidonk: because it's not working
(23:56:32) kikidonk: it's a major feature
(23:56:38) tko: I'd like autocomplete first
(23:56:39) kikidonk: not working ?
(23:56:52) chpe: kikidonk: autofill on pwd form works, but not autofill on other form elements, or autocompletion popups
(23:56:59) kikidonk: autocomplete is a drop down resenting the last things you typed ?
(23:57:15) chpe: there's a bug filed which has some info what needs to be done to fix it
(23:57:16) kikidonk: then i want autocomplete
(23:57:17) chpe: yes
(23:57:52) kikidonk: is it gecko unsanity , as usual ?
(23:58:12) philipl: So, sbm autocomplete. Using an autocomplete entry is easy. Where should the sbm history live? In the bookmarks or somewhere else?
(23:58:17) chpe: the ff autocompletion popup is implemented in XBL, no idea how/if we can reuse it
(23:58:19) tko: as an added bonus would be nice to have autocomplete consider all previous addresses when filling up another 'address' form field :)
(23:59:02) tko: chpe, hmm.. don't you get dom events for focus movement and keyboard input?
(23:59:07) chpe: philipl: would one need to look at all entries, or just use it for autocompletion?
(23:59:33) chpe: tko: yes we get them
(23:59:41) philipl: chpe: hmm? I mean the search history for that sbm.
(00:00:09) chpe: tko: but I don't want to reimplement nsFormFill*, we need just the UI for it, ff backend is ok
(00:00:36) chpe: philipl: yeah, would you need to see the whole history? if not, it doesn't matter where it's stored
(00:00:46) chpe: ephy-smb-history
(00:00:52) chpe: or whatever :)
(00:01:03) philipl: chpe: I'd have thought that if the UI elements are children of the page, we'd be ok. If they're overlays on the other hand...
(00:01:05) chpe: tko: the bug has the info, but... bugzilla is still down
(00:01:15) philipl: chpe: No, I mean where the actual data lives. It has to be persisted somewhere.
(00:01:34) reinouts_: i hear the server has run out of memory and someone needs to visit the colo, and it's 8am over there currently
(00:01:39) tko: philipl, I'd think it's just another (list) attribute for bookmark :)
(00:01:50) chpe: yeah
(00:01:55) philipl: tko: that's the obvious way. I'm fine with that.
(00:02:16) reinouts_: Go on with Search?
(00:02:19) philipl: except it has implications for privacy I guess.
(00:02:34) chpe: philipl: right, clearing history should clear these too
(00:02:36) tko: hilighting all matches on page would be nice...
(00:02:57) chpe: yeah, except I couldn't get it to work right... and it's (potentially) slow
(00:03:01) reinouts_: as would giving a beep when wrapping the search
(00:03:11) kikidonk: a beep ?
(00:03:22) kikidonk: i think firefox has a text appearing "The search has wrapped" or something
(00:03:26) reinouts_: or other indication
(00:03:36) crispin: beeps are the work of the devil :-)
(00:03:45) kikidonk: using the system beep
(00:03:51) chpe: tko: and highlight can break the layout :/
(00:03:54) kikidonk: that'd give a little retro touch
(00:04:09) reinouts_: kikidonk: we could have it play the LSL1 theme
(00:04:10) adamh: If there were an indicator saying "match 1 or 300", it would be obvious the search has wrapped
(00:04:16) kikidonk: also what if you ghighlight with the same color has the page background
(00:04:16) adamh: :s/or/of/
(00:04:22) reinouts_: how about that for retro ;)
(00:04:33) kikidonk: :)
(00:04:38) kikidonk: i like adamh idea
(00:04:40) tko: chpe, if you do it the way we used to do it, then yeah, but the layout issue should be fixable
(00:05:05) tko: adamh, match count would be good
(00:05:11) chpe: tko: ff has the layout problem too... if they haven't found a way to fix it, will we ? :)
(00:06:16) reinouts_: am I the only one who just totally can't make sense of this: Alternative: The complete phrase and each of the parts in a dropdown or similar, searches for those when chosen. Same as: paste chosen into find box, CTRL-G.
(00:06:47) kikidonk: lol
(00:06:59) kikidonk: gah my brain burns
(00:07:20) philipl: then it's clearly not an alternative.
(00:07:20) philipl: next.
(00:07:26) reinouts_: context menu
(00:07:52) crispin: argh, 2 hours in, and we haven't got through that page yet :-(
(00:07:53) tko: hmm.. if selected text is a valid link, the context menu should have the items for links
(00:08:10) chpe: I'm for keeping the "add bookmark" item
(00:08:16) kikidonk: maybe it's a bi silly but can i have the url of that page :)
(00:08:17) philipl: yeah. keep that.
(00:08:19) reinouts_: yes, that item is useful
(00:08:30) reinouts_: http://66.249.93.104/search?q=cache:PxntdQcPrcwJ:live.gnome.org/Epiphany_2fSuggestions+epiphany+suggestions+site:live.gnome.org&hl=nl&lr=&strip=1
(00:08:32) philipl: "Feed selected text to location bar". We've seen that before...
(00:08:44) kikidonk: haha google cache :)
(00:08:48) philipl: middle-click paste-and-go :-)
(00:09:43) chpe: I think there's a bug filed for considering selected text as link if it fits the url pattern
(00:09:53) chpe: I agree that it should do that
(00:10:01) chpe: anything else?
(00:10:17) reinouts_: nop, move on to Bookmakrs
(00:10:19) chpe: let's skip the "Bookmarks" section?
(00:10:23) kikidonk: copy text instead of copy link ?
(00:10:24) reinouts_: oh ;)
(00:10:30) kikidonk: besides not instead
(00:10:38) reinouts_: chpe: for another time?
(00:10:54) chpe: just IMO
(00:11:14) reinouts_: there's a lot of discussion on bugzilla abouit these issues
(00:11:15) chpe: kikidonk: is that useful ?
(00:11:18) kikidonk: yes
(00:11:24) kikidonk: how do you copy a linked text ?
(00:11:48) tko: kikidonk, very carefully? :)
(00:11:57) chpe: heh
(00:11:59) kikidonk: :)
(00:12:03) kikidonk: yay for usability
(00:12:21) reinouts_: adding yet-another item to that context menu doesn't make it much clearer
(00:12:29) kikidonk: or a modifier key to disable link clicking
(00:12:51) kikidonk: ctrl-meta-apple-shit click and you don't follow the link
(00:13:02) tko: kikidonk, I was kind of expecting shift+press+drag to do that, but no...
(00:13:10) tko: "Eventually downloads are going to be delegated to Nautilus" -- is this still true?
(00:13:26) kikidonk: i have a prototype of dbus forwarding
(00:13:32) philipl: tko: I have no confidence in that.
(00:13:37) kikidonk: but downloads re still handled in mozilla
(00:13:54) reinouts_: nautilus ftp bugs should be fixed first
(00:13:57) philipl: In general an internal downloader has to exist because it's hard to communicate all the state that might be needed to make a download work.
(00:14:02) chpe: just external progress notification, not actual downloading
(00:14:07) reinouts_: but ideally, nautilus would be respsonsible for file transfers
(00:14:10) tko: unless you can transfer all state to external application you must use the internal handler
(00:14:24) tko: chpe, heh, I've done that too as a dbus experiment :)
(00:14:50) kikidonk: i also have a nautilus extensions that puts an emblem showing progress
(00:15:01) tko: basically you'd have just a UI that manages the downloads and shows progress, downloading itself would be done by mozilla/gaim/whatever
(00:15:02) kikidonk: so it's kind of integrated
(00:15:14) chpe: tko: yeah that's the idea
(00:15:22) reinouts_: kikidonk: but why isn't it ready for production yet?
(00:15:29) kikidonk: it needs a bit of rework since dbus has changed since the last time
(00:15:38) kikidonk: just i have been busy with other things, 
(00:16:01) reinouts_: yeah, we have noticed kikidonk ;)
(00:16:01) kikidonk: i can rework on it more actively if requested
(00:16:11) crispin: reinouts_: it's almost impossible to make nautilus do the file transfers, we need to transfer so much state (cookies, basic auth details, referrers etc)
(00:16:44) reinouts_: crispin: sharing that stuff is on the "future" section of the roadmap
(00:16:47) chpe: kikidonk: it would be cool to have it, esp. if other programs buy in, like nautilus copy ops, cd burning progress etc
(00:16:50) kikidonk: i also have a global preogres smonitor if any other ap is interested in showing rogress for long background tasks
(00:16:55) kikidonk: yep
(00:17:54) kikidonk: http://raphael.slinckx.net/images/unnati
(00:18:02) chpe: voice I/O suggestion is crack , beagle: postpone IMHO, services: maybe bookmarks/history, but not HTTP, parsing! crack!
(00:18:06) tko: full text indexing and parsing the content for keywords to suggest for use when bookmarking a page are something for beagle?
(00:18:21) chpe: yeah
(00:18:33) reinouts_: we don't want beagle as a hard dependency i think
(00:18:52) reinouts_: tko: libots can also suggest keywords
(00:19:31) tko: kikidonk, I'm not so sure about grouping all kinds of long running tasks into one, but I think it would work if you group just all file transfers first (then you could also control them)
(00:19:57) tko: reinouts_, oh yeah, that was another thought, in bookmarks dialog you'd have a thumbnail and summary :)
(00:20:12) philipl: tko: binary chunks in xml. yay!
(00:20:19) reinouts_: that's something for harves to work on after his patch is in 
(00:20:39) tko: philipl, binary?
(00:20:41) chpe: I think the idea was to dump the xml format :)
(00:20:43) arose entered the room.
(00:20:44) chpe: .png
(00:20:59) tko: ~/.thumbnails/...
(00:21:07) philipl: tko: that's no fun :-)
(00:21:24) reinouts_: I've lost track, are we in the Interface section now?
(00:21:28) tko: chpe, I don't mind xml but calling rhythmbdb xml is so wrong :)
(00:21:30) philipl: Not quite.
(00:22:21) kikidonk: is keyword suggestion already working ?
(00:22:23) philipl: but we should be.
(00:22:37) reinouts_: kikidonk: i've tried with libots, it works quite well
(00:22:38) arose: does bookmark exporting do strange things for anyone else?
(00:23:10) reinouts_: but maybe it could also use meta tags as input
(00:23:12) chpe: arose: no, what does it do?
(00:23:15) kikidonk: good
(00:23:30) chpe: reinouts_: meta tags are just spam nowadays, aren't they
(00:23:32) ***adamh simply must go shower and get breakfast... back in a bit
(00:23:38) adamh is now known as adamh|brb
(00:23:47) kikidonk: tko: it's jut a prototype
(00:23:55) reinouts_: chpe: true, they should not be taken over literally
(00:23:58) kikidonk: the interface is just to show the underlying dbus signals
(00:24:08) arose: chpe, missing bookmarks, missing categories, some bookmarks get exported into categories they aren't included in
(00:24:09) kikidonk: it can be improved much, but the concept is there
(00:24:11) arose: a mess
(00:24:13) tko: I gathered harves' patch was suggesting topics based on something, but didn't quite get it based on what (btw, the suggestion arrow looks too much of an expander, IMHO)
(00:24:15) reinouts_: but they could be additional input to reinforce cretain keyword candidates
(00:24:49) reinouts_: tok: it's based on earlier bookmarks you've filed with similar topics
(00:24:50) kikidonk: we need an IA algorithm with reinforcement learning :)
(00:24:51) chpe: arose: export to mozilla format? I don't recall any bugs there...
(00:25:08) chpe: so, on to interface section ?
(00:25:44) reinouts_: good
(00:26:00) philipl: Onward!
(00:26:01) arose: there isn't anything else to export to, is there?
(00:26:17) reinouts_: we've talked multiple times about the zoom widget already, there's a bug open about it
(00:26:22) reinouts_: even a patch
(00:26:25) philipl: I'd like the plug the overlay box from libview as an option for autohiding the toolbar in fullscreen mode.
(00:26:41) chpe: arose: our own format, RDF...
(00:26:41) tko: is this about the toolbar button or the prefs dialog?
(00:26:50) chpe: arose: but yeah, moz is the only useful one
(00:27:10) crispin: philipl: yeah, but that is in C++ ....
(00:27:13) chpe: arose: I have no idea why it's wrong
(00:27:16) philipl: crispin: no. the overlay box is C
(00:27:22) crispin: oh, sweet
(00:27:22) philipl: It's the only C thing in there :-)
(00:27:39) crispin: we need to steal^H^H^H^H^Hborrow that then
(00:27:43) chpe: yeah
(00:27:48) arose: I tried the XSL, different, but also missing a lot of things
(00:27:58) chpe: philipl: how does it work? a popup window?
(00:28:16) philipl: chpe: No, it does all the voodoo to have an X window slide over another one
(00:28:42) crispin: chpe, it works _very_ nicely, the toolbar slides down when you put the cursor at the top of the screen
(00:28:43) philipl: You give it two windows and overlap rules.
(00:29:17) chpe: yeah, but does GtkEntry focus work right? that's the problem with the evince way of using a different toplevel window, which is override-redirect...
(00:29:28) philipl: chpe: it's not override-redirect.
(00:29:37) philipl: It's a window with two children.
(00:29:37) chpe: good :)
(00:29:50) crispin: it is certainly worth a try IMO
(00:29:52) philipl: The guy who wrote it is really good with this stuff. No hacks allowed.
(00:29:55) chpe: yeah
(00:30:00) chpe: URL?
(00:30:01) tko: chpe, is the same problem with treeview typeahead popup?
(00:30:14) philipl: http://view.sourceforge.net/
(00:30:46) chpe: arose: is there anything unusal about the bookmarks for which this happens? in the title, or the url maybe, or the category names?
(00:30:48) chpe: thx
(00:30:54) arose: the strangest thing is that export didn't work at all with two or three bookmarks
(00:31:01) arose: not really
(00:31:14) chpe: tko: yes, they send fake focus-in messages but that messes the focus up when you have something else in the popup too that can take focus, entry thinks it always has focus
(00:31:17) arose: except for a few bookmarlets there'
(00:31:30) arose: s nothing extraordinary
(00:32:01) chpe: arose: if you can share the bookmarks file I could take a look, but I guess you don't (I wouldn't either :)
(00:32:31) kikidonk: hide those .ru sites, and it's ok :)
(00:32:32) reinouts_: the Fitt's Law suggestion, is it possible to implement?
(00:32:35) chpe: fitts law thing is a gtknotebook problem, bug filed ages ago, no progress as usual
(00:32:40) arose: not at the moment, I'm not at my computer
(00:32:46) reinouts_: :-/
(00:32:52) chpe: subdomains for "Up"... ??
(00:32:58) philipl: fitts law for toolbar can be done if you do crazy style overrides, I think.
(00:33:06) kikidonk: chpe: it never works
(00:33:19) arose: I could after 6h
(00:33:56) philipl: The link colour suggestion sounds like he's talking about open-in-new-tab which was fixed in shiny new gecko right?
(00:33:58) chpe: arose: if you don't want to make it public, email me, else you can file a bug on bugzilla.gnome.org (hopefully it's back soon)
(00:34:00) reinouts_: kikidonk: subdomain for Go Up never works?
(00:34:09) chpe: philipl: yep fixed in gecko 1.8
(00:34:27) chpe: I'm on google.com, Up -> .com? :)
(00:34:38) philipl: chpe: up -> www.google.com :-)
(00:34:49) chpe: that's down, since it adds www. ;)
(00:34:55) reinouts_: groups.google.com could do that
(00:34:55) philipl: It's all releative :-)
(00:35:03) reinouts_: (though you don't need to with google)
(00:35:05) kikidonk: well it never works, so :)
(00:35:08) marco_ left the room (quit: Remote closed the connection).
(00:35:17) chpe: would you expect Up to do that? I don't think I would
(00:35:32) philipl: chpe: I'm being facetious.
(00:35:35) arose: ok, if it'll be up...
(00:35:46) chpe: arose: thx
(00:36:06) chpe: "Forms" section? all discussed except spellcheck I think
(00:36:34) tko: up in planet.g.o should go to gnome.org .. rarely needed but simply stripping subdomains shouldn't hurt
(00:36:42) reinouts_: well there's the rfe to make textfields have the same context menus as gtk textfields
(00:37:03) chpe: reinouts_, impossible atm, no way to get the embed's im context
(00:37:19) chpe: or if there is, I didn't see it
(00:37:19) reinouts_: sucks
(00:37:56) reinouts_: ok and spellcheck?
(00:38:02) reinouts_: i think that was my suggestion :)
(00:38:21) kikidonk: i bet it's impossible too
(00:38:27) chpe: it's difficult
(00:38:28) kikidonk: mozilla embedding sux0rz
(00:38:45) philipl: fix spellcheck on the mozilla side.
(00:38:50) philipl: They have all the pieces.
(00:38:51) chpe: you'd need to take a ff extension which does it, and look how its done
(00:39:01) reinouts_: <HostingGeek>Use gtkwebcore!</HostingGeek>
(00:39:09) kikidonk: :D
(00:39:46) philipl: extensions?
(00:39:58) reinouts_: adblock needs an UI
(00:40:08) reinouts_: a better one than the ff version
(00:40:14) tko: galeon stuff needs more extension points in core
(00:40:18) kikidonk: yes ! that one is for ultimate geeks
(00:40:19) philipl: yeah.
(00:40:36) philipl: for galeon stuff, we need: toolbar/preferences/pdm hooks.
(00:40:37) crispin: yeah, I would like to see extensions able to add things to dialogs
(00:40:44) kikidonk: but aren't there some site with predefined block list
(00:41:00) reinouts_: kikidonk: the existing adblock extn has a predefined blocklist
(00:41:05) kikidonk: good
(00:41:23) kikidonk: i prefer 10 times an extension tha just works by enabling it, than one that requires manual filtering
(00:41:39) reinouts_: kikidonk: the major problem is that it crashes ephy on exit
(00:41:43) crispin: I think adblock doesn't have a UI at the moment because it doesn't work so adamh lost heart, but chpe has a plan to avoid the crashes
(00:41:45) kikidonk: yeah, i know :)
(00:41:48) chpe: I'm fixing that
(00:41:52) kikidonk: yes ?!
(00:41:56) kikidonk: god that's wonderful
(00:41:56) chpe: in ephy this time, since the moz bug is stalled
(00:42:01) kikidonk: yes
(00:42:50) chpe: I'm ok with adding to the extension iface to get at the dialogues
(00:42:51) reinouts_: and then we need a View menu item to enable blocking per site, just like popup blocking
(00:43:49) philipl: chpe: cool. And the toolbar stuff is important, but given the limitations of the egg mechanism I'm not sure how elegant it could be.
(00:43:53) chpe: another thing about extensions that I'd like to discuss is this: we're getting more and more extensions... should we add them all to e-e? make a template one-extension package that you can just adapt? or sth else?
(00:44:28) crispin: chpe, yeah, I have about 4 lying around, and don't really know what to do with them
(00:44:31) tko: chpe, I think in some cases it would useful to be able to add new widgets in existing dialogs
(00:45:13) philipl: Well, a 'galeon' meta-extension would probably be useful :-)
(00:45:35) crispin: that requires extension dependancies
(00:45:36) reinouts_: chpe: what about a guaranteed-to-work-stable package of extns in a basic epiphany-extensions package
(00:45:40) chpe: tko: yes. otoh, I don't want anyone to expect dialogue internal widget layout to stay the same...
(00:45:52) philipl: crispin: it could just be a packaging thing.
(00:45:57) reinouts_: and let the rest free, and make it not conflict
(00:46:17) chpe: reinouts_, would we ship them all in e-e? or would you need to checkout e-e yourself to get the 'extra' extensions?
(00:46:46) reinouts_: hm
(00:46:48) kikidonk: can we have an epiphany-extensions-extras ?
(00:46:52) philipl: haha.
(00:46:56) kikidonk: and a download site for python extensions ?
(00:47:05) reinouts_: jEdit has a plugin manager that checks out plugins by itself
(00:47:08) crispin: then an e-e-extras-extra in the future ? :-)
(00:47:11) chpe: another package to maintain & update for APIs and build changes... :/
(00:47:16) kikidonk: :)
(00:47:31) kikidonk: so let's put C extensions in e-e and a webpage for python extensions
(00:47:52) crispin: we should make easy to drag and drop extensions from the web page to the extension manager
(00:48:15) crispin: (package up the .py and .xml in a .tgz file, and the ext manager should extract them in the right place)
(00:48:24) reinouts_: and the ext. manager could just have a button to show available-but-uninstalled extensions
(00:48:35) reinouts_: (on the current page/in the main repository)
(00:48:48) crispin: reinouts_: or why not just list them, and if you enable them it goes off and downloads them ?
(00:48:53) philipl: python extensions still need a cvs to be maintained in though...
(00:49:14) crispin: we are all forgetting mono extensions :-)
(00:49:15) reinouts_: crispin: possible, but depends on servers being up all the time
(00:49:18) chpe: and tarballs for distributions
(00:49:31) chpe: crispin: you need to make a release! :)
(00:49:41) crispin: I need to fix the big bug first! :-)
(00:50:06) philipl: chpe: we could keep all the source in e-e in cvs but have it produce multiple tarballs.
(00:50:11) reinouts_: should an extension author be able to publish his extn on his webpage without going through gnome?
(00:50:22) reinouts_: he should, right?
(00:50:25) crispin: reinouts_: yes
(00:50:28) philipl: reinouts_: of course.
(00:50:39) chpe: philipl: can you do that with auto*?
(00:50:41) reinouts_: so ext. manager should facilitate that
(00:50:48) philipl: chpe: I'm sure if you beat it up enough :-)
(00:50:53) crispin: e.g. I have at least one which I doubt will ever get into a gnome cvs tree
(00:51:51) crispin: grr, I can't check libview out, sf sucks!
(00:52:02) adamh|brb is now known as adamh
(00:52:07) philipl: hah. just like gnome.org apparently.
(00:52:08) tko: chpe, (sorry, phonecall) I was thinking one could add placeholders inside dialogs roughly the same way as in menus, so then one could just add widgets into that box .. it should allow some flexibility in changing layouts without breaking it completely
(00:52:18) philipl: Ok, I'm just about out of time now. Tai Chi and all that :-)
(00:52:40) reinouts_: bye philipl
(00:52:47) philipl: I just wanted to formally announce my intention (which should be obvious) of trying to turn all the outstanding galeon features into extensions
(00:52:57) philipl: or merging them in like the middle-click stuff I've been doing.
(00:53:10) reinouts_: hence the meta-galeon-extension package 
(00:53:14) philipl: Yeah.
(00:53:46) crispin: myportal: in ephy then! :-D
(00:53:49) tko: extensions can have dependencies? :)
(00:53:55) philipl: hehe, quite.
(00:54:00) crispin: when you write the code to do it tko :-)
(00:54:05) reinouts_: so, what do we have left
(00:54:07) chpe: one thing about that: this will cause a HUGE flamewar when it gets out... can we keep it under wraps until we have a bit of it done? :)
(00:54:19) philipl: chpe: do you have any comments on the email I sent you?
(00:54:20) reinouts_: Gmail notifier?
(00:54:50) crispin: I don't see that the browser is the place for a gmail notifier, surely a notification icon or something is
(00:55:07) reinouts_: crispin: agreed
(00:55:11) chpe: philipl: no, it's perfectly fine, but that won't stop flames :)
(00:55:53) reinouts_: hey, we could even announce it on /.
(00:55:54) ***reinouts_ runs
(00:55:56) philipl: chpe: heh. Well, the flames will be directed at me for the most part and I can take that. :-) My only concern about waiting is that it will take a while to do and galeon users need to know the strategy.
(00:56:05) chpe: reinouts_: NO! :P
(00:56:21) tko: hmm.. I sort of understand the idea of gmail notifier, whenever you have a browser open you could be connected to gmail (since it runs with js) and blink a tray icon when things change
(00:56:30) tko: better gmail/gnome integration and all
(00:56:40) crispin: philipl: perhaps we should give timescales as to how long we think it will take, e.g. 6 months or a year
(00:57:07) reinouts_: just moving on for now...
(00:57:09) philipl: crispin: Yeah. And We should just put out a 2.0 release and say that 'unstable' is the extension project.
(00:57:26) reinouts_: chpe: I think the Back context menu option also on images is a sane idea
(00:57:32) reinouts_: I mean, it makes senes
(00:57:34) reinouts_: *sense
(00:57:41) adamh: Just as a disclaimer: I'd *like* to work on adblock/greasemonkey/extension dependencies... but recently I did a little time-budgeting of my typical week, and ended up with 6.5 hrs of sleep per night. I can't work on anything these days :(
(00:58:16) chpe: reinouts_: yeah
(00:58:35) philipl: Ok. I'm out of time. This has been useful. See you guys later.
(00:58:38) philipl is now known as phil|out
(00:58:43) chpe: grrr sourceforget is so sloow again :(
(00:58:44) adamh: So if anybody wants to do any work on those and is afraid of offending me or of treading on my development territory... don't worry about it
(00:58:46) chpe: laters
(00:59:09) reinouts_: adamh: you did suggest to make a greasemonkey script to remove target=_blank?
(00:59:17) adamh: reinouts_: yeah, it'd be easy
(00:59:29) adamh: Hey, nobody's talked about PyXPCOM yet, btw...
(00:59:30) reinouts_: so if you could do that, and leave the rest for when you have more time
(01:00:21) adamh: reinouts_: Can't even commit to a timeframe for that, either :P
(01:00:33) chpe: adamh: if we wait for gecko 1.9 it'll hopefully have it... otherwise import to ephy, but that's going to be a lot of work to test with all geckos, and maintain...
(01:01:09) tko: oh, is killing ephynode on the roadmap? :)
(01:01:23) adamh: chpe: So you mean this won't happen in the 1.10 timeframe?
(01:02:13) chpe: adamh: I don't want to take that on my workload, and since you're overloaded too...
(01:02:23) tko: and favicon and history title/bookmark url (or vice versa) inclusion for autocompletion?
(01:02:29) adamh: Yeah. Well, if I found the time to take on any one feature, PyXPCOM would be it.
(01:03:05) chpe: tko: yes, killing ephynode is on the roadmap, but it'll happen when it happens :)
(01:03:19) chpe: tko: autocompletion, I'd like that too
(01:03:35) chpe: only thing is that the icon won't line up under the drag handle
(01:03:43) chpe: but we can live with that glitch
(01:05:55) reinouts_: Hide the protocol for http, file and keyword urls?
(01:06:25) chpe: not sure...
(01:06:47) reinouts_: are there situations where it's still useful (bar https)?
(01:07:09) tko: what happens when you start editing the location?
(01:07:27) reinouts_: ftp sites could have a corresponding favicon 
(01:08:56) reinouts_: tko : I figure the protocol wouldn't magically appear
(01:08:59) tko: hmm.. speaking of favicons, local files should use the same favicon as file chooser
(01:09:41) kikidonk: and should not be cached
(01:10:08) reinouts_: I would like to try it out
(01:10:40) chpe: that ought to be easy, just a bit of code in ephy-tab, if someone wants to try :)
(01:10:49) chpe: I have to go too, bbl
(01:10:52) tko: I'm just thinking that hiding the protocol makes the URI ambiguous so that if you go and edit it, hitting enter gives you something different
(01:11:02) reinouts_: ok, let's call it a day then
(01:11:02) chpe is now known as chpe|afk
(01:11:09) reinouts_: for this meeting at least
(01:11:25) tko: yeah, I'm hungry
(01:11:31) adamh: All right, later all
(01:11:32) reinouts_: tko: 99,8% of the times you want http anyhow
(01:11:32) adamh left the room.
(01:11:56) reinouts_: the first one to post the log on epiphany-list gets cookies