irc meeting log

[Reinout van Schouwen <reinouts gnome org>]

Hi all,

Here's the unedited log of Monday's irc meeting. 
Please see http://live.gnome.org/Epiphany/Meetings/20081020 for the
summary (thanks Diego!).

regards,

-- 
Reinout van Schouwen

<reinouts> *ding dong* 
<alp> hey gang
--- reinouts has changed the topic to: The meeting is in progress
<barisione> hi
--- reinouts gives channel operator status to diegoe
<xan> hello
<danw> yo
--- reinouts gives channel operator status to xan
 reinouts gives channel operator status to alp
<alp> does anyone have an agenda or can i make a start?
<vuntz> hey there
<xan> diego sent an agenda, but since he's not here maybe we can ignore him *cough*
* reinouts summons diegoe
--> pierlux (~plbeaud jalfrezi collabora co uk) has joined #epiphany
<kov> yo
<pierlux> hello!
<alp> ok, let's give it a couple more minutes
 hey pierlux
<kov> I was under the impression that we were scheduled to 21UTC
 I was surprised to see 20UTC in the reminder email
 koolhead17 kov
<reinouts> kov: afaik it always was 20:00UTC
<kov> my bad then =)
* barisione was not sure about the time being in an unusual time zone now
<xan> alp, hrm, the checkbox in forms in webkit/gtk seems to be rendered almost with 1x1 pixel size
<reinouts> anyway, I can list a couple of bugs with patches needing review
 #537408
<Zeus> epiphany bug #537408: NEW: 'Download complete' notification bubble should show "open file" button http://bugzilla.gnome.org/show_bug.cgi?id=537408
<-- Lethalman has quit (Remote closed the connection)
<reinouts> 546285
 #546285
<Zeus> gtk+ bug #546285: NEW: Allow GtkEntry to draw progress http://bugzilla.gnome.org/show_bug.cgi?id=546285
<reinouts> #547899
<Zeus> epiphany bug #547899: NEW: Limit the completion entry results to a reasonable number to avoid going through the whole model http://bugzilla.gnome.org/show_bug.cgi?id=547899
<alp> would just like to note, we have a fantastic team here and i'm really impressed by the milestones we've reached in the last couple of years
<reinouts> +1
--> Lethalman (~lethal host53-116-dynamic 46-79-r retail telecomitalia it) has joined #epiphany
<-- Lethalman has quit (Read error: 131 (Connection reset by peer))
<reinouts> #537731
<Zeus> epiphany bug #537731: NEW: middle click in history view should open tab on button release, not press http://bugzilla.gnome.org/show_bug.cgi?id=537731
<reinouts> #351163
 brb
<Zeus> epiphany bug #351163: UNCONFIRMED: Default encoding should be should have translator comment http://bugzilla.gnome.org/show_bug.cgi?id=351163
<alp> the things we want to look at are probably split into issues in webkit, and ways we can make epiphany keep up with development better
* vuntz would like to have a "what's missing for webkit to get accepted in 2.26" item to the agenda
<alp> of the former, API enhancements (loader, gdom, gjs)
 before we look at the links, can we take a high level look at what's missing from the point of view of the release team vuntz?
<barisione> vuntz: I can try to list something if you want
<vuntz> barisione: sure
 (IMHO, there are two things: what's missing for ephy and what's missing for the other apps ;-))
<barisione> - accessibility, test alp's patch and fix problems
 - problem with non-latin alphabeths
 *problems
<alp> ok. on the a11y front, i have the ATK patch (which is actually pretty hot, needs a little more work) and caret navigation, which i have done
 barisione: any issues in trunk with the new pango complex text path?
 i can read more languages on wikipedia.org with webkit right now than with firefox 3.1 trunk (seems to fail on Telugu and some others)
<xan> is there anything else missing for the apps that are not ephy besides a11y?
<uws> (Hi all. Slightly late, sorry.)
<barisione> oh, I didn't check in the last 2 weeks, but when I tested it wasn't still working. I realise now that I don't have a compiled copy of webkit here
<alp> xan: gnucash needs replaced widget support (currently provided in gtkhtml)
--> Tester (~tester modemcable254 102-83-70 mc videotron ca) has joined #epiphany
<xan> alp, the ones in GNOME in meant, though it's nice to cover everyone
<alp> i recommend checking out webkit trunk right now btw, got a handful of nice patches in today
<xan> the scrolling speedup is pretty nice
<vuntz> for a11y, I can't stress out enough how important it is to have some testing done by the GNOME a11y team
--> metal (~metal 201 80 8 44) has joined #epiphany
<vuntz> willie seemed to say at the summit that getting it right is really hard
<alp> xan: evolution could do with specific editing API, particularly UIManager for editing actions, but gdom will more than cover the things it needs
<uws> It seems that a11y guys are actually quite willing to jump in if there's something for them to play with.
<vuntz> uws: nod. Maybe providing some packages for a few distros would help?
--> Lethalman (~lethal host53-116-dynamic 46-79-r retail telecomitalia it) has joined #epiphany
<pierlux> the a11y guys (willie) were also very afraid seeing little progress in the last months on a11y front
<uws> Well, not sure if that's what's needed.
<alp> some of the distributions are following our releases, which is one of the topics i want to discuss. i'd like to roll a point release this week
<uws> Perhaps just landing stuff on trunk and progressively improving that works better than having patches floating around
<vuntz> uws: when the a11y people tried back in June/July, they had difficulties compiling webkit. So, making it easy to test would be good
<kov> I am not as aware of what is needed as barisione and alp, probably, but I think there are quite a lot of basic functionality missing, such as proper download support, proper cache support, new window/tab creation, special handling of middle clicks
<pierlux> kov++
<alp> kov: your patches are great btw!
<uws> (but webkit trunk has strict policies for commits)
<kov> alp: oh, thanks =)
<reinouts> diegoe mentioned a patch which xan would review??
<kov> I had a lot of help from barisione and kalikiana1 in hammering them =)
<xan> the cookie stuff, I'm working on that
<alp> barisione: so, can we clear that up? any remaining issues with international text?
<uws> Slightly related question: is the GDOM stuff currently discussed/developed in https://bugs.webkit.org/show_bug.cgi?id=16401 needed for proper a11y support?
<reinouts> xan: cool 8)
<Zeus> Could not parse XML returned by Snarfed Bugzilla URL bugzilla: not well-formed (invalid token): line 1595, column 61
<barisione> alp: compiling now
<-- janm has quit (Ping timeout: 600 seconds)
<alp> uws: it isn't at all related to our a11y framework
<-- koolhead17 has quit (http://www.mibbit.com ajax IRC Client)
<uws> alp: Ok. Thanks for clarifying.
<alp> webkit has its own internal accessibility abstraction which is wrapped to msaa, apple's AX and atk
<xan> danw, alp it would be good to talk a bit about the cookies APIs maybe
<alp> the infrastructure is slightly different to mozilla's in that it does a significant amount of analysis of the view internally and tries to expose a layout view to the accessibility toolkit
<xan> whether we want ephy to go only through libsoup directly, or move ephy-cookie-manager to webkit, or what
 we need some sort of coordination among the three of them
<uws> xan: Might be worth to investigate how other webkit browsers (otherp latforms) do this. What does Safari do, for instance?
<alp> this kind of accessibility infrastructure is slightly different to Mozilla's, which tries to expose a DOM-style hierarchy leaving a lot of the logic to viewers and accessibility tools (there are thousands of lines of python wrapping Mozilla's accessibility objects in orca for example)
<danw> there are some other things where we may need three-way libsoup/webkit/epiphany coordination too. (proxies, passwords, ssl, ...)
<pierlux> alp: yes, and the a11y wouldn'T mind getting rid of those 8k lines
<xan> uws, I think on OSX they do the equivalent of using libsoup directly, but I might be wrong
<kov> webkit does seem to have cookie support from what I noticed in the code I read; there is a CookieJar class, and they seem to be implemented by the network backends (such as curl and soup in our case); I would think webkit is the proper place to implement basic cookie support
<xan> I think ephy querying soup for cookies directly might make sense, but then you tie ephy to the soup backend of webkit. I'm not sure if that's ok or not
<kov> xan: yeah, we do need a proper public API for that IMO
<xan> kov, yeah, sure, but the browser needs to be able to query, modify and delete those cookies
 there's no way to do that atm
<alp> kov: we can persist cookies simply by setting the curl property for the cookie path as a short-term solution. a few dozen lines of code (https://bugs.webkit.org/show_bug.cgi?id=14730)
<Zeus> WebKit bug #14730:  ASSIGNED: [curl] Cookie handling
<uws> Ok, so how does WebkitGtk relate to the curl/soup network backend?
<kov> xan: true enough, what I meant is we need to design an API for webkit/gtk+
<uws> Does the WebkitGtk API need to make a choice for one of them?
<danw> and probably need some way for either webkit or libsoup to filter cookies too (to implement "no third-party cookies")
<xan> kov, yes. Epiphany has pretty decent API for that
<danw> s/libsoup/epiphany/
<alp> has anyone tried running the layout tests with the soup backend yet?
<kov> xan: if we can map the Ephy API to wrap the webkit implementation, that would rock, I think =)
<alp> i have a feeling incremental loading is broken right now, and the gio local file backend isn't doing too well
* diegoe pops
 diegoe checks backlog
 kov waves at diegoe
<xan> also, when I added the soup cookie stuff to webkit it seemed I was going against the general trend there, I was the only one doing slightly evil ad-hoc hacks in the cookie classes
 so adding even more stuff might be weird
 I think the other ports just use their platform libraries for this
<danw> xan: some of the hacks are because the gtk cookie code has to support two different network backends
<uws> what about having our own "gnome web stack" where we put this kind of stuff
<kov> xan: we are missing lots of public API currently, and we really need to invest some time into integrating the patches already in the bugzilla, so that we can free up our brains to think of new ones, such as importing the Ephy cookie API to wrap WebKit's cookie support
--> `Duke` (~gnu AVelizy-751-1-19-174 w90-62 abo wanadoo fr) has joined #epiphany
<uws> it might later evolve into a full-blown "gnome web stack" à la the "gio/gvfs stack"
<alp> uws: the qt guys wrote QNetworkManager which was originally in webkit svn and then moved out into its own external project (in Qt)
<xan> uws, I think there was a plan for that yes...
<uws> instead of putting it into epiphany itself (or is that easier for now and easy to rip out later?
<alp> it would make life a lot easier
<xan> danw, maybe, yes, but even with only one backend there was special stuff needed already
<uws> Can anyone answer my question from ..:25:18 (3 minutes back) about making a choice for curl/soup
<xan> #if USE(SOUP)
     SoupCookieJar* getCookieJar(void);
 #endif
 that's in the cookiejar header :]
<alp> uws: the curl backend is significantly more tested right now (even though curl isn't .. great). someone needs to put time into the soup backend to change that
 the curl http backend passes the most tests after the CFNetwork one i believe, even beating the Qt stack right now
<uws> Is the curl backend only used by WebkitGtk?
 Same question for soup...
<alp> uws: also used by wx and wincairo (but we're maintaining it)
 soup can be enabled in the gtk+ port only
<uws> what is wincairo?
<kov> some URLs which might be useful: http://trac.webkit.org/browser/trunk/WebKit/qt/Api/qwebnetworkinterface.cpp might be useful; also http://trac.webkit.org/browser/trunk/WebCore/platform/network/curl
<alp> uws: http://www.atoker.com/blog/2008/02/10/webkit-for-windows-gets-cairo-support/ <- apple's Windows port modified to build without proprietary dependencies
<pierlux> uws: a port of WebKit for Windows that doesn't use the Mac on Windows approach (more free)
<alp> uws: adobe is also using our cairo backend in one of their producs (AIR)
 remarkably, their version is basically unpatched :-)
<uws> Ok.
<alp> on the subject of a quick 1.0.2 release, are there any critical patches wanted (say a timeline of one week, basically no API changes for this one)?
 the goal here is to sync up since we don't have a release with international text support or a lot of the fixes done in recent months
<pierlux> and when are there going to be API changes?
<kalikiana1> I still wonder how much sense it makes to invent a cookie api in webkit if in the long term there's only going to be soup anyway and we'll just have two interfaces for one thing
 a 1.0.2 w/o api sounds like hot air to me, honestly
<alp> pierlux: possibly today. we can branch from any revision. thinking of getting a replacement for 1.0.1 out though, or we won't move forward
<uws> Is there a reason WebkitGtk should support both the curl and soup backends?
<-- Duke` has quit (Ping timeout: 600 seconds)
<kalikiana1> ^^ Exactly the point
<uws> can't we just decide and have one of them (soup I s'pose since we can control it)
 then focus on getting features in that library itself or in WebkitGtk specifically targeting that one library?
<kov> I agree with kalikiana1; while having better support for the rendering engine itself, we still have a lot of problems which make it impossible to use, for instance, liferea with webkit without a very big regression, because liferea has no public API to work with
<xan> well, I haven't written a line for the curl stuff, so I made my mind up a while ago ;)
<barisione> +1
<kov> I am using liferea-webkit fulltime, and I'm really pissed off when I middle click a link and the webview I'm in navigates to the link heh
<diegoe> uws: i think the problem is that soup is still catching up to curl completeness in webkit-gtk, but chicken-egg
<reinouts> liferea has d-bus support, doesn't it?
<uws> Yes, but only for simple feed management methinks, reinouts
<reinouts> hmm
<alp> getting out a 1.0.2 is a few hours work. it's not to block API additions, but simply to get the fixes out there.
<kov> yeah, it seems to provide org.gnome.feed.Reader through dbus
<xan> alp, as I said before, the checkboxes seem to be broken in trunk, if you are planning to release that
<kalikiana1> how many people are using the "releases" btw? virtually all midori users are using trunk webkit
<alp> xan: dhyatt fixed a rendertheme regression half an hour ago. what revision are you on?
* reinouts raises hand
<alp> kalikiana1: debian
<-- crevette_ has quit (Ex-Chat)
<xan> alp, ok, maybe I updated 45 minutes ago, bad timing
* xan updates again
<diegoe> reinouts: ask my child, ask
 kalikiana1 kalila
<reinouts> diegoe: (in response to kalikiana1)
<diegoe> oh
 :P
<pierlux> diegoe: he was raising hand as a mean to say that he was using the releases
<kov> I'm using Debian's package through my use of liferea-webkit, but then, again, it's essentially full of regressions when compared to the gecko-based packages
<alp> xan: oh, confirmed. they're buggered
 xan: will fix after the meeting
<kov> so not a lot of people are actually using them -- my friends usually install epiphany-webkit and remove it quite quickly
<uws> alp: I think your opinion on the issue stated by  kalikiana and /me 4 minutes ago about choosing between soup/curl
 ...will be useful
<diegoe> kov: same here :-)
<kov> http://qa.debian.org/popcon.php?package=webkit
<xan> kov, it's not really useful for non-developers right now
<pierlux> so according to this, it is fairly unsed: http://qa.debian.org/popcon.php?package=webkit
<alp> programs like gwibber, yelp, devhelp are feature complete now
 feed readers, web browsers are not, and we can fix that :-)
<jonner> alp: btw, the pango complex text stuff doesn't seem to work that well for me atm
 http://www.gnome.org/~jjongsma/temp/webkit-wikipedia.png
<pierlux> but these apps won't ship their webkit branch if webkit doesn't get a11y before the next Gnome release (IMHO)
* kov will try devhelp =)
<reinouts> chpe also mentioned we need to connect epiphany ssl certificate dialogs to webkit
<uws> pierlux: skip the IMHO, it will be ablocker
<pierlux> jonner: that's more minimalist than the CSS free day
<kalikiana1> "we can fix that" sounds good, let's start 9 month ago
<jonner> that input text field didn't even show up until I hovered over it
<alp> jonner: the 'pango' backend isn't supported, might well get removed. the current pango complex text is in the "freetype" backend ironically
<jonner> alp: ah, that's where the confusion is.
<alp> though it can be made not to depend on freetype at all. sorry, the code moved about a bit
* jonner reconfigures
<diegoe> so, we are between releasing 1.0.2 with fixes and releasing x.x.x with new stuff, right?
<uws> alp: (your opinion on soup/curl for webkitgtk, please)
<alp> uws: soup is the future but can't currently be enabled because it causes regression
<kov> I think what we really need is to take a look at what API changes we would need in webkit/gtk+ so that a Epiphany/WebKit in 2.26 is viable
<reinouts> kov: +1
<uws> Ok, let's focus on one thing at a time then.
<kov> and focus on applying the already existing patches, and make an effort to implement what doesn't have a patch yet
<diegoe> ^L
<alp> i'm going to push a 1.0.2. it won't get in the way of the API additions, i promise. 1.0.1 is very old and just doesn't work for international users. 1.0.2 will remove all blockers for the smallest embedders
<vuntz> uws: yep, focus would help ;-)
<barisione> I completely agree with kov
<uws> vuntz: You're in a Big Company now. Step up and show your meeting management skills.
<reinouts> ouch ;)
<diegoe> :P
<alp> ok. what pending API patches are the most important?
<uws> for Ephy/2.26, I guess?
<barisione> policy decisions + download
 they seem important
<uws> new-tab
<kov> with an Epiphany release which is usable we will even get more testing to the core of webkit, and be able to find/patch problems quicker
 I would love to switch to Epiphany/Webkit in my laptop, but I just can't yet
<alp> let's get a couple of patches discussed and landed then
* kov agrees with barisione
<xan> policy decisions++, yep
<pierlux> yes the policy stuff I started back in DECEMBER 2007, is important...
<xan> downloads is pretty basic also
<pierlux> but download depends on policy
<xan> I think barisione was working on that...
<barisione> alp: before adding api we need to know what to do with ABI/API stability
<xan> pierlux, aha, ok
<vuntz> uws: you don't want me to manage a meeting, really
<barisione> AFAIR at GUADEC you said that for long webkit would have been both API and ABI stable
<reinouts> so here's a list of all open Backend:Webkit bugs: http://tinyurl.com/5jzmto
<alp> barisione: it has been API and ABI stable for a very long time (kind of by accident, now pretty much a rule so as not to break apps)
<barisione> yeah but we cannot add new virtual methods now without padding
<alp> but i think we can break ABI, and even look at breaking API if there's a sane way to do it and deployed applications aren't affected badly -- and if it's essential to developing a clean API
<uws> without getting into much detail, there seem to be 2 options:
 1. Break ABI/API and Get Things Done at the cost of breaking apps
<vuntz> much better to break API/ABI now than in 6 months, IMHO: not a lot of things really depend on webkitgtk now
<reinouts> Two of the open bugs have patches
<uws> 2. Keep things stable, thereby hindering new development
<alp> barisione: we can break that fairly easily, i don't think many are subclassing
<uws> WebkitGtk has leaned towards 2. in recent history
 but I feel that e.g. barisione would rather see 1.
<diegoe> vuntz: agree, the few people using wk-gtk somehow know it will break soon
<uws> Is that a correct summarizatioN?
<-- ced117 has quit (Quitte)
<alp> is there an example of what we need to break that isn't a vtable (and thus likely to affect few apps)?
<barisione> uws: it's possible to keep probably the current API and signals
 deprecating them
<uws> There was not only API/ABI, but also things like signal reworking (discussion on guadec)
<barisione> uws: I started to work on the redesign of signals following what we discussed but now I'm not working anymore on webkit
<uws> Let's face it: WebkitGtk is new and not mature. Let's fix things now before it's set in stone.
<barisione> so I don't have much time for that
<kov> uws: agreed
<xan> uws, yes, I think I said that last year :)
<barisione> not that the signal redesign is important also for download
 *note
<kov> and we can use this epiphany cycle to do the API work we need
<alp> kov: which webkit bug is the base/first of the API patches?
<pierlux> alp: I'd say: https://bugs.webkit.org/show_bug.cgi?id=16562
<Zeus> Could not parse XML returned by Snarfed Bugzilla URL bugzilla: not well-formed (invalid token): line 181, column 23
<uws> alp: (don't want to annoy you, but is this related to what we currently focus on, namely keeping/breaking API stability?)
<xan> btw, it's pretty late here and I have to leave soon. Do we have a consensus that soup is the only way to go for webkit/gtk and that the place to put all the needed API is in soup?
 if we agree on that it should be possible to go forward with very minimal changes in webkit itself I think
<kov> alp: I agree with pierlux on that, that seems to be the core of the API work for me, since many of the API workflows depend on it
<kalikiana1> xan: imho it's the only reasonable way
<alp> kov: ok. let's sort this patch out (once the soup discussion is done?)
<reinouts> It would be helpful if the webkit-gtk release cycle were in sync with gnome
<pierlux> xan I agress
 *gree
<uws> reinouts: please, stop raising NEW Points
<uws> let's focus on 1 thing at a time
<kov> then I think download/new-window (hear, hear =D)
<xan> alfauros, sounds good?
 alp: ...
<kalikiana1> who is alfauros :P
* uws sighs
<-- Lethalman has quit (Ex-Chat)
<alp> is anyone volunteering to do a NetworkManager API?
 if not, then i suppose soup is the place to put the changes, and we will switch to that when it's ready
<vuntz> (is anybody taking notes for meeting minutes?)
<reinouts> vuntz: I'll save the transcript
<kov> perhaps soup can be our network manager, then; if we are intending to focus on it for the future I agree to use it
<xan> not sure what you mean with NetworkManager API, guess it has nothing to do with *the* NetworkManager :)
<diegoe> vuntz: i'm waiting for decisions, seems like we are still in discussion phase though...
<reinouts> not all distro's / platforms use NM
<uws> diegoe: No, we're in "say random relevant things" mode
<-- fdd has quit (10100011010.)
<diegoe> right
<uws> diegoe: ...which doesn't help at all.
<alp> xan: an API that wraps http and local requests similar to CFNetwork
<kalikiana1> we can just enhance soup and keep curl working for what I want, there's no problem with that
<jonner> (don't mean to de-rail anything, but since alp asked earlier: I rebuilt with the freetype font backend and it doesn't seem to render CJK fonts correctly on trunk)
<xan> alp, any reason why soup wouldn't do?
--> lincoln (~lincoln 201 80 8 44) has joined #epiphany
<kalikiana1> alp: Heh, sounds useful, I'm basically inventing that locally for midori already :P
<-- juergbi has quit (Ex-Chat)
<kalikiana1> xan: soup doesn't do file:///
* pierlux gotta go, but he will agree on anything that means introducing new API, going with libsoup and in general, makeing things go forward at all cost.  See ya!
<-- seb128 has quit (Ex-Chat)
<xan> "at all costs"
--- diegoe gives channel operator status to uws
* kov read a book with that name recently =)
--- uws has changed the topic to: The meeting is in progress | Let's discuss topics ONE at a time. Current topic:   curl/soup/network backends
<xan> kalikiana1, right, a whole library just for that seem a bit hardcore, but what do I know :)
<kov> uws++
<alp> jonner: http://www.ndesk.org/tmp/WebKitText.png
<barisione> kalikiana1: what's the problem with soup not handling local files?
<danw> alp: so... meaning what? the current ResponseHandle thing is not good enough / not correct / not the current preferred API?
<uws> guys
  
  
  
  stop
  wait
<kalikiana1> barisione: Basically you need to write double code whenever you handle http(s):// and file://
<uws> mind if i try to step up as a chair now?
<kalikiana1> You mean chair man?
<uws> yeah, keep things focus and decide
 focused*
<diegoe> I agree
<kalikiana1> Sure :)
* kov too
<jonner> alp: here's mine: http://www.gnome.org/~jjongsma/temp/webkit-cjk.png
<uws> So instead of shouting, which is all highly relevant but tends to get lost in the mess, I suggest to be very precies and concrete
* diegoe will take notes of the decisions and ideas (ping me if you want to remark something)
<uws> so
 We're discussing curl/soup/network backends
<alp> jonner: #webkit-gtk for out-of-band discussion i guess, uws is right and we should stick to the current topic
<jonner> yup
<uws> There seems to be consensus that Soup is The Future.
* kalikiana1 nods.
<uws> Please prefix your concise remarks with "+" or "-" if you're stating an opinion
<alp> danw: at the core of it, CFNetwork accepts local file requests, http requests, data URIs and does all the work itself, leaving very little to WebKit
<uws> 9sorry for being unfriendly, but otherwise this gets us nowhere)
<kalikiana1> +
<uws> So what I understand is that the best way is probably this:
 - improve the soup backend to be feature complete  cf. curl
 - build new things like cookie store for the soup backend
 - once we have those things in place, we deprecate/drop curl for WebkitGtk
 is this a correct summarization?
--> seb128 (~seb128 ANancy-158-1-46-113 w92-130 abo wanadoo fr) has joined #epiphany
--- Zeus gives channel operator status to seb128
<danw> alp: right... but does WebKit use CFNetwork directly? or is it sufficient to just abstract soup-for-some-things-gio-for-others inside the soup network backend?
* uws is NOT knowledgeable about the details. I'm not a hacker. Just trying to make things clear
<kalikiana1> +
<reinouts> cookie store for soup backend: #522125 (with patch)
<Zeus> libsoup bug #522125: NEW: add support for cookies http://bugzilla.gnome.org/show_bug.cgi?id=522125
<uws> alp, agreed?
<kov> + I agree with points raised by uws; and I think we should have something like a special gio:// handler which provides the application with the possibility of feeding arbitrary GInputStream's as data source
<uws> ok
 let's add an additional point to my previous list:
<kov> there's this bug report: https://bugs.webkit.org/show_bug.cgi?id=17147
<Zeus> WebKit bug #17147:  NEW: [GTK] API: Stream-based loader API
<alp> danw: WebKit uses CFNetwork in Apple's Mac and Win ports. it's not much more than an abstraction
<kov> that would be similar to Qt's qrc://
<uws> - have additional network backend code such as GIO integration and other things target soup
 (or at least integrate with soup_
<barisione> hm, wait. what do we need in soup? cookies, cache and?
<uws> do we agree so far?
 if so, let's summarize what's missing.
<barisione> uws: I agree depending on what we need in soup
<uws> Missing:
 - cookies
 - cache
 - ... ?
<danw> gnome-keyring integration?
<barisione> we don't need cache for local files so we don't have to special case file://
 but do we need cookies for local files?
<danw> proxy support
<reinouts> #334021
<xan> the cookies stuff reinouts pasted is committed btw, what's missing is the storage
<Zeus> libsoup bug #334021: NEW: client SSL certificate support http://bugzilla.gnome.org/show_bug.cgi?id=334021
<alp> danw: i have a tracking bug on the libproxy tracker
<uws> barisione: please keep raising those valid points, but please discuss them later
<alp> cookies should be supported for local files using XMLHttpRequest IIRC
 (tying in with the offline web applications and offline storage W3C specs)
<diegoe> it's persistent cookies and local cookies to be precise then
<alp> i believe there is code around for the curl backend to support that
<uws> Ok, let's summarize missing things again:
--> tevaum (~estevao 200 131 252 2) has joined #epiphany
<uws> - cookies (in progress, missing is sotrage)
<tevaum> yo
<xan> in progress = There Is A Plan To Move Forward At All Costs (tm)
<uws> - cache (don't need it for file://, status ... ?)
<barisione> uws: I have a patch
<alp> might be worth looking at the CFNetwork API for inspiration (or less so, the new one in Qt)
<barisione> but it was blocked by some other patches
<uws> - gnome-keyring integration (status?)
<diegoe> barisione: which one, #?
<uws> - proxy (alp knows more about this)
  
  
  
 so
<reinouts> uws: - client SSL certificate support
<diegoe> +that's pretty much it
<barisione> diegoe: the patches it was depending on were reviewed by zecke but now I don't have time to update it
<uws> oh, add the point by reinouts
<uws>  
  
  
 ok, let's move on
 msot things have been said about curl/soup/network backends now
<kov> barisione: do you have the numbers?
<uws> details later.
<diegoe> barisione: do you have the bug #, so we add it to the minutes
<uws> next topic...?
<diegoe> uws: the pending patches for new api we need
<xan> ok, I have to go now, I'll try to keep going with the cookies stuff this week. Someone send the minutes to the list :)
 good night
<reinouts> night xan
<uws> ok
<alp> laters xan!
--- uws has changed the topic to: The meeting is in progress | Let's discuss topics ONE at a time. Current topic:    pending patches for new API needed for Ephy/Webkit
<uws> cheers xan 
<diegoe> xan: go work! :-)
<barisione> diegoe: https://bugs.webkit.org/show_bug.cgi?id=21239
<Zeus> WebKit bug #21239:  NEW: [GTK][CURL][SOUP] Add on-disk file cache
<kov> xan: see you =)
<alp> back in a couple of minutes
<uws> ok
 ok, which API is missing
 please shout
 i'll try to summarize
<barisione> uws: can I propose a order of importance for the patches?
<uws> barisione: i have a better plan
<barisione> ok, go on :)
<uws> barisione: you're chairing this agena item
 barisione: since you know more about this.
<barisione> noooo :)
 ok
 I will just post a list of patches I know about, give me one minute so I can search everything
 and so we can also wait for alp
<uws> sure
 go on
--- uws gives channel operator status to kov barisione kalikiana1 danw
 uws gives channel operator status to pierlux
<barisione> Creation of popup windows: https://bugs.webkit.org/show_bug.cgi?id=19130
<Zeus> WebKit bug #19130:  NEW: [GTK] ChromeClient::createWindow and friends need to be implemented
<barisione> it seems ready to me
<kov> + the main usability problems which bother me are not having a way of opening new tabs with middle-clicks (which bothers me a lot in liferea and epiphany), maybe I'm biased because of my usual use cases =)
<barisione> Policy delegates: https://bugs.webkit.org/show_bug.cgi?id=16562
<Zeus> Could not parse XML returned by Snarfed Bugzilla URL bugzilla: not well-formed (invalid token): line 181, column 23
<barisione> kov: it should work with the policy decision patch
 Frame loader signals: https://bugs.webkit.org/show_bug.cgi?id=17066
<kov> barisione: yeah =)
<tevaum> kov: agreed... middle-click is a good feature!
<Zeus> WebKit bug #17066:  ASSIGNED: [GTK] Improve frameloader signals
<barisione> no patch as not enough people commented on the proposed api changes
<uws> tevaum: (You're input is valued, but please refrain from making non-productive comments. thanks)
<barisione> I started to work on it 2 weeks ago but I'm not working on webkit anymore so it's frozen
<uws> (s/you're/your/. anyway, just patch discussion now)
 barisione: Whom does #17066 depend on?
 alp?
<Zeus> Error: Error getting gnome bug #17066: NotFound
<alp> back
<barisione> uws: yeah, me and kalikiana1 were waiting for some comments from alp
 Download: https://bugs.webkit.org/show_bug.cgi?id=16826
<Zeus> WebKit bug #16826:  ASSIGNED: [Gtk] Implement WebKitWebDownload
<barisione> the public API is blocked by #17066
<uws> alp: could you glance over the api patches/bugs barisione listed and say what's missing?
<alp> i'm looking now
<uws> great, thanks
<barisione> network request and response: https://bugs.webkit.org/show_bug.cgi?id=18608
<Zeus> WebKit bug #18608:  NEW: [Gtk] WebKitNetworkRequest needs to be finished
<alp> first impression is that this will break the soup backend
<barisione> well, I think this is the list of the most important missing patches (IMHO)
 alp: which one?
<uws> alp: Break in what way? We agreed that the soup backend is The Future and that it is Fixable [tm], right?
<alp> it seems to use curl.h directly, but that can be fixed. looking at the actual content now
<uws> wait, not too much detail
 we can work it out later.
 just summarizing what needs to be done now, please.
<barisione> alp: ops, the +#include <curl/curl.h> is a leftover
<uws> ok, so there is no unfixable issue?
<barisione> pierlux wrote it as a "demo" using directly curl
 I separated it and tested with CURL and a bit with soup
 uws: I hope no
<uws> we have a few todos: popup windows, policy delegates, frame loader signals,  download, network request/respons
 Is that a complete list?
 (that's the list of bugs barisione just mentioned)
<diegoe> yes i think so
<uws> alp, barisione: any additions?
<kov> I'm interested in working in networkresponse, which I started in networkrequest, and I'll do it as soon as request lands; I can probably take on some of barisione's patches after we land some of those patches
<uws> kov: That's great to hear.
 any takers for the others?
<kov> I would suggest landing my pet patch, web inspector, too, since it is important to motivate firefox/firebug to migrate ;)
<barisione> uws: what do you mean with any taker?
<alp> barisione: Mac WebDownload is a subclass of NSURLDownload. if we were to expose soup, would this be simpler?
<kov> https://bugs.webkit.org/show_bug.cgi?id=19392 - but I'm biased since I do web development at work ;)
* Tester fails to see why will anyone want to use epiphany if even more features are cut
<Zeus> WebKit bug #19392:  NEW: [Gtk] Enable WebInspector in the Gtk port
<uws> barisione: Well, let's rephrase. I listed a few bugs. Want to attach names to those
<kov> Tester: exactly, so we need to fix regressions and provide killer features such as the inspector; but the inspector can wait a next round, I think
* uws fails to see what the point made by Tester is.
<barisione> uws: most of them are blocked waiting for review
<uws> barisione: let's go over them one by one
 1. popup windows
<barisione> IMO it's ready
<uws> (NOTE TO EVERYBODY: ONLY ON TOPIC NOW)
 Status: ready for landing according to barisione 
 Next action to be taken by... ?
<barisione> waiting for alp's review
<alp> what is ready for landing?
<uws> 23:31:01 <@uws> 1. popup windows
<barisione> alp, uws: not ready for landing
<uws> ok, but please don't discuss in detail.
<barisione> IMO, but I'm not the maintainer :)
<uws> status: waiting for review by alp
 that's better?
<barisione> yep :)
<alp> first of all, are there any patches waiting and actually ready for landing?
<uws> ok
 alp: please hold your breath, we're going over them in order RIGHT now
 2. policy delegates,
 status: ???
 next action to be taken by:  ???
<barisione> waiting for alp's review
<uws> status?
<barisione> less tested than the new window one
<uws> ok, but there might be progress possible in the foreseeable future. ok.
 next
<barisione> so it may have some/a lot of issues
<uws> 3. frame loader signals,
 statuss: ??
 next action by: ???
<barisione> new signals designed
 next action, alp and epiphany people should comment on the proposed signals
<uws> (thanks for cooperating, this makes things much clearer)
 ok, thanks
 next
<barisione> and see if they work
 wait a sec
<uws> 4. download,
 status?
 next action by: ???
<barisione> status blocked by policy delegates and signal cleanup
<reinouts> do we have bug#s for these?
<kov> (side note) barisione: for the policy delegates, a good way of testing them would probably be landing, and before doing a release start using them in Ephy trunk, so we can test/sharpen that API, and fix it if needed before the next release
<uws> reinouts: Yes, right after I change the /topic. Please do NOT repeat
<uws> ok
 next
 5. network request and network response
 status; ???
<diegoe> reinouts: /Epiphany/Meetings/20081020 @live.gnome.org
<uws> next action: ??
<barisione> kov wrote the patch for network request
 and something for network response
<uws> ok, that'll do
<kov> + network request is good to go, I believe; I just have a small start for response, and plan to work on making it full after request laaands
<barisione> probably we should review the request before moving to working on the reponse
<uws> so we now have 5 API related blocker issues to work on. right?
<kov> yep
<barisione> so next action: review by alp
<uws> great.
 next
 6. web inspector
 status: ???
 next action:???
<barisione> kov: ^
<alp> web inspector, works well but API changes are slightly dubious
<uws> Is this is a blocker?
 guess not. right?
 if not, skip it for now
<kov> yeah, need to do some more thinking API wise, would be good to have epiphany developers input even
 and I need to implement auto-generation or globing of the data files in the makefile
<uws> yes, but for that we need a clear overview, so that e.g. xan and chpe can easily digest the mess we're producing
 ok. let's skip web inspector discussion for now
 so 5 API-related blocker bugs remain
 any additions?
 if not, let's move on to the next topic
 (input please ;))
<kov> yeah, web inspector is not a blocker, it's just one of the webkit killer features for web developers
<uws> i.e. past 2.26
<alp> gdom is very important
 lkcl picked up my initial gdom patch and got it working. i need to pick it up again and get it to completion
<uws> alp: Could you elaborate? there has been some progress (discussion at least) on that bug lately
 how does it relate to Ephy/Wbkit?
<kov> yeah, gdom looks important, since it would allow more powerful addons to be developed in the future
* uws spots the word "future"
<vuntz> is gdom important for 2.26?
<uws> so not critical for 2.26
<reinouts> uws, what about regressions in epiphany-extensions?
<uws> ok. is gdom required for e-e to function?
<alp> uws: i'm not sure of the status of the bug, but i have developed it a little locally. it's the most important feature for setting apart applications like epiphany and midori, which will be able to support extensions that manipulate and inspect content directly. it can also alleviate some of the missing API concerns since the DOM provides access to many of the things people request core API for
<uws> diegoe: ^^ please record that comment by alp. looks useful
<alp> it will help make e-e nicer. one of the best things about gdom is that it can be easily wrapped, so for the first time, you can have python/c# greasemonkey scripts and similar
<uws> Ok, thanks for the explanation. That will do.
 back to the question that lead up to this:
 23:41:13 <@uws> ok. is gdom required for e-e to function?
<reinouts> we do have a greasemonkey extension
<alp> midori has implemented many of the capabilities of e-e without gdom. but it'll help write new extensions faster
<uws> and if so, is how critical is this? (that's a policy decision, not a technical one)
<alp> it isn't required for greasemonkey
<reinouts> and adblock could be relevant
<diegoe> uws: not vital, but would be good
* kov quotes one of the points in the initial epiphany webkit announce: "The WebKit APIs. The API has been designed from the ground up, and feels like any other GObject based API. A two-way GObject bindings to the web page’s DOM, and to JavaScript is in development; this will allow us and our Extensions to access the DOM directly, which hasn’t been possible before in Epiphany in either C or Python. "
<alp> it would be very useful for flashblock/adblock
<uws> ok, let's write it down as "would like"
<diegoe> alp: gdom bug is...?
<alp> gdom is pretty important, and the patch needs a core developer to make it ready for inclusion
<uws> diegoe: https://bugs.webkit.org/show_bug.cgi?id=16401
<reinouts> if we release without adblock support, there'll be a shitstorm :(
<Zeus> Could not parse XML returned by Snarfed Bugzilla URL bugzilla: not well-formed (invalid token): line 1595, column 61
<uws> Subject: [Bug 16401] [GTK] GObject/C DOM binding
<Zeus> Error: Error getting gnome bug #16401: NotFound
<uws> diegoe: ^
<diegoe> reinouts: we can hope to get it working by then, if not, we play the same trick that we played for 2.24
<uws> ... which is?
<diegoe> but having the real basics working will already be an improvement
<kov> gecko? hehe
<diegoe> uws: releasing gecko version as stable
<uws> ok.
<reinouts> diegoe: I'd rather not but...
<alp> may i bring up a subject?
<uws> ok
 let's stop discussing this item
 alp: bring it on
<diegoe> back in 5 mins
<uws> we're done with API blockers now
--- uws has changed the topic to: The meeting is in progress | Let's discuss topics ONE at a time. Current topic:    ??
--> RainCT (~RainCT 212-73-54-80 red-acceso airtel net) has joined #epiphany
<alp> so far we've looked at what needs to happen in webkit, and i'll be putting my time into those items. but there are also a few things that will help make this happen on the ephy side
<RainCT> Hi
 How can I close a tab using Python (from within an extension)?
<uws> RainCT: please wait until later. we're in a meeting right now
<RainCT> oh, sorry
<uws> (please do not disrupt the flow)
 RainCT: (no problem)
<jonner> (btw, just to mention that I just updated to trunk and webkit/gtk displays cjk fonts fine now, so false alarm from earlier)
<alp> (1) getting epiphany development releases out based on webkit -- because magazines and IT websites are _still_ reviewing epiphany-webkit from 2.22 and complaining about issues that were fixed, which kills morale
--- uws has changed the topic to: The meeting is in progress | Let's discuss topics ONE at a time. Current topic:   Required Epiphany stuff (not webkit specific)
<alp> (2) gnome bugzilla integration with webkit bugzilla, similar to what is already there for mozilla.org. don't know who handles those issues (bug team?)
 that's for forwarding and linking bugs between trackers. there's a high rate of crossover and some bugzilla fu would be handy
<uws> alp: (yay keep going in this way, so that I don't have to summarize)
<alp> (3) gnome build bot tie-in. there's the new build bot infrastructure for testing how well gnome applications build. as we move towards a faster rate of API development and additions, continual integration and testing will become essential. we need to switch those over
<uws> alp: Could you describe the "fu" later? (not now) Thanks
<reinouts> on (2): there's a high amount of custom bugzilla code blocking the move to 3.x or so I've heard
<uws> ok
<alp> (4) change channel settings in #epiphany to -t (until/unless it gets abused)
<uws> let's attach the names xan and chpe to alp's point (1)
<uws> attach reinouts to (2)   (can you ask e.g. bkor and inform us later?)
<reinouts> sure
<uws> re (3) who does buildbot stuff? Not sure what needs to be done
<alp> and (5) which i brought up earlier and is IMO quite important. keeping ephy buildable on older versions on gnome since webkit developers (especially contributors from Apple) tend to test our port against stable distributions in a VM without knowing about jhbuild
<uws> alp: please do if you know how
 alp: (re. (4)
<vuntz> uws: there's a build-brigade-list or something like this
<alp> i think that's in.
 that's it.
--- uws sets mode -t #epiphany
<alp> hope those sound reasonable
<uws> alp: (does that address (4)
<barisione> does 5 mean no libsoup from svn?
<alp> uws: maybe, as long as chanserv doesn't set it back
<uws> alp: we don't have that on gimpnet
 alp: otherwise just ask OPs to me and i'll make sure you get it
<alp> barisione: libsoup from svn is fine as long as there's always a buildable configuration (curl or ifdef'd soup) for those users i mentioned
<danw> barisione: in the past, i think people were mostly ok with needing libsoup from svn, it was when svn libsoup also required svn glib that their patience was exhausted
<barisione> this also means gio
 ok, than why not stop requiring only glib/gtk 2.0 if we are going to recommend soup?
<kov> it might be interesting to starting some real work on removing Embed in trunk, too
<barisione> and depend on the last stable glib/gtk
<kov> so that it gets more sane to test new webkit patches in epiphany
<barisione> AFAIR danw said he didn't have any plan to depend on glib trunk
<uws> kov: xan worked on that in the past iirc
<alp> barisione: there are people (opened hand or related?) deploying webkit trunk on gtk+ 2.6 devices with a few minor patches. the effort of maintaining legacy support has been minimal so far
<kov> uws: yeah, I remember some discussion here in the channel
<alp> gtk+ 2.8 and cairo 1.4 are the reasonable versions to aim to support for now, though trunk may often be in a state where it needs something a bit newer. as long as soup isn't the default, we can go wild and depend on trunk without any concerns
<uws> kov: please discuss with xan if you're interested, that would be great
<kov> uws: will do, thanks =)
<uws> ok
 let's stop the discussion here
 alp, others: any other Ephy-specific poitns?
 alp: e.g. a (6) ? :)
<barisione> yes, I have an infrastructure one
<uws> shoot
<alp> uws: that's it. the rest (like keeping up to date with WebKit API additions) will fall in to place with those recommendations implemented IMO
<uws> barisione: you want gnome svn access? we'll get it :)
 alp: Ok, thanks.
 so let's wait what barisione has to say
 then move on to the next topic (if any)
<barisione> now we are using directly the svn (or its semi-official git mirror). what happens if apple commits a big patch one week before a stable gnome (and webkit) release?
<uws> Gnome, by defition, only depends on released versions of library dependencies.
 vuntz: pleae confirm
<barisione> shouldn't we use a git repo and stop taking automatically patches from upstream before a release?
<uws> does that answer the question?
<vuntz> uws: confirmed
<alp> barisione: releases have traditionally been branched for stabilisation, though only by me. i'd like to make that process more open
<barisione> uws: yes and no
 alp: yeah, it's what I mean
<uws> barisione: So your point can be resolved in cooperation with alp?
<vuntz> uws: (except that it's s/Gnome/GNOME/, but well, irrelevant ;-))
<-- `Duke` has quit (Fatal signal: Segmentation Fault)
<uws> vuntz: (using "GNOME" in any nl.po is considered a bug, and we have literature to back us up, but let's leave that discussion for later ;)))
 ok
 next topic
 ?
<alp> dark themes!
--- uws has changed the topic to: The meeting is in progress | Let's discuss topics ONE at a time. Current topic:   Dark themes
<uws> shoot
<alp> they're coming, and i have a WIP patch to fix some issues with dark themes but i simply don't have the time after maintaining the port to test the changes with all the themes that are out there
 i need help with https://bugs.webkit.org/show_bug.cgi?id=15597
<Zeus> WebKit bug #15597:  NEW: [GTK] Text not discernable when using a dark Gtk+ style
<alp> have attached a typical dark gtkrc and example code fixing the bug. great place for a new contributor to get stuck in
<uws> ok, let's ask diegoe since he's about to become a hero
<diegoe> :p
<uws> diegoe: (you're still updating /Epiphany/Meetings/20081020 I hope?)
<diegoe> yeah
<uws> diegoe: (we're quite concise over the last few agenda items)
 ok
 next topic
--- uws has changed the topic to: The meeting is in progress | Let's discuss topics ONE at a time. Current topic:   ??
<alp> gjs?
<uws> ping barisione kalikiana1 kov alp diegoe vuntz pierlux 
 anyone?
<kov> alp: is that discussing whether we should wrap the javascript core api with a glib api?
<diegoe> how does that relate to webkit gdom and stuff?
 kov: i think alp means litl's gjs
--- uws has changed the topic to: The meeting is in progress | Let's discuss topics ONE at a time. Current topic:   G/JavaScript stuff
<-- phaero has quit (Ex-Chat)
<alp> kov: yes. gjs related to gdom in that a gjs_object(?) can contain a gdom node
 but beyond that, no relation
<barisione> how much is it useful/important for epiphany/gnome?
--- danw is now known as danw_out
<alp> we might want to find a home for gjs in a shared git repo or gnome svn (kalikiana1?). languages may still want to bind the JSCore API directly though (i have a CLR/C# binding and don't think C# will want to wrap gjs except for interoperability)
* vuntz is confused because there's already a gjs project (the stuff released by litl)
<alp> i have an example where you can use gtk# via javascript. same could be done directly with gintrospection
<vuntz> or is this the same thing?
<alp> vuntz: gjs is the javascriptcore glib/gobject binding originating from midori. been around for a while
<Tester> the litl gjs uses spidermonkey I believe...
<vuntz> ok, probably not the same thing, then
<kov> oh, so not the litl thing?
* diegoe thought it was litl's gjs
<uws> ok
 before we start digressing again...
<barisione> hm, there were discussions also about using javascriptcore
<uws> what is the status?
 how is it relevant?
<kov> I think it makes a lot of sense to wrap javascript core with a glib API - helps with coherent bindings for webkit as a whole
<uws> who works on it?
<barisione> somebody should ping them
<uws> and what should happen?
<alp> ask them why they're stealing our namespace? ;-)
<barisione> lol
<diegoe> :-)
<uws> ok
<diegoe> perhaps it can be renamed to geejei :p
<kalikiana1> I suppose it would be useful to see who and what uses gjs and find out about its future
 otherwise it's hard to say :)
<uws> there's not much to say about it now, right? let's move on
--- uws has changed the topic to: The meeting is in progress | Let's discuss topics ONE at a time. Current topic:   ??
<uws> any other issues?
 otherwise we'll end the meeting
<kalikiana1> cairo siupports perhaps?
<uws> ping barisione kalikiana1 kov alp diegoe vuntz pierlux 
<diegoe> i would like to set a date for our "internal milestone" for new api in webkit
<kalikiana1> *support
<uws> ok, kalikiana1 first
--- uws has changed the topic to: The meeting is in progress | Let's discuss topics ONE at a time. Current topic:   cairo support
<alp> cairo support?
<uws> kalikiana1: what's the problem/issue?
<reinouts> I haven't heard anyone agree/disagree with my question about the webkit-gtk release cycle yet
<kalikiana1> there used to something in bugzilla for influencing/ hijacking/ redirecting the rendering
<uws> reinouts: we'll merge your point with diegoe's when talking about milestones.
<kalikiana1> ie. render to your own surface
<alp> kalikiana1: WebKitWebRenderer, could be interesting
<uws> is this like gtk offscreen renderinG?
<kalikiana1> Hm.. what is that actually?
 Basically I'd like to render a snaptshot of a view, resize it, make it translucent, and make a thumbnail, you get the idea
 That's what I mainly see as cairo support
<uws> gnome-web-photo!
<kalikiana1> It shouldn't be hard to support that
<uws> kalikiana1: gtk offscreen rendering is for doing fancy graphical things with gtk widgets
<kalikiana1> Well.. gtk offscreen is related but it's not even done yet :)
<kov> kalikiana1: that would rock for a lot of uses
<kalikiana1> And I'm not sure it obsoletes a cairo api
<barisione> kalikiana1: isn't it already possible to render to an arbitrary cairo context?
<kalikiana1> kov: Indeed
<barisione> I did something like that in the past
<alp> it isn't possible yet. would be a nice feature
<kalikiana1> Not with upstream api
<alp> related, i have a patch adding support for windowless WebViews
<barisione> hmmm, I remmeber playing a bit with that
<alp> that means you can pack a transparent WebView in a GtkButton, say, and have it animate some SVG
 unfortunately it interacts badly with windowed plugins so can't be enabled by default
<Tester> that seems very very wrong
<alp> it's fun to play with, especially in glade
 which reminds me, we have patches adding gtk-doc and glade support
 can we make gtk-doc the topic?
<barisione> alp: not very useful to have a full engine inside a button, except for fun :)
 uws: ^
<kov> gtk-doc would be a good topic
--- barisione has changed the topic to: The meeting is in progress | Let's discuss topics ONE at a time. Current topic:   gtk-doc
<alp> barisione: can throw together some pretty interesting hybrid UIs, though not so much related to browsers and feed readers
<diegoe> oh yes, gtk-doc ++++1
<barisione> about gtk-doc I think that Lethalman wrote a patch months ago
--> torrr (~torrr bzq-79-177-165-18 red bezeqint net) has joined #epiphany
<barisione> but probably it will be outdated
<alp> ok, so there's the gtk-doc patch by tko. i've got it here and tried to clean it up a bit. we need to enable gtk-doc without requiring it to be installed though
 and we don't really want it to generate stuff in srcdir
<uws> barisione: Yeah, feel free to change the topic
--> JulioNeto (~julio 189 21 145 130) has joined #epiphany
<barisione> uws: already done, too late :P
<alp> unfortunately the mechanisms used by gtk-doc don't seem to play well with our build system and mode of distribution (not tarballs)
* uws is only trying to keep ppl focused, i'm not managing or deciding things
<barisione> alp: how is webkit distributed?!
<kov> alp: I believe we will have to go the tarballs way, at least when dealing with GNOME
* barisione admits to have always used webkit from git
<alp> i mean, most developers and even many users aren't currently using tarballs, so we can't increase the dist-time dependencies too high
<kov> also, speaking as a DD, I would not really enjoy packaging something that does not have a tarball distribution; I had to do it, but gah
<alp> kov: i commit about once a day to keep make dist going (and distcheck is not far off) :-)
<barisione> alp: how is webkit distributed?
<alp> barisione: tarballs, but most developers and even users are picking it up from svn
<barisione> ah ok. I thought that we were not using tarballs :)
<diegoe> ok so gtk-doc is precisely blocked by... ?
<kov> alp: that is probably transient, we are going to have more users for tarballs as the project progresses
<alp> 1.0.1 was prepared without make dist because there was no dist support
 (sadly it ended up without a configure script!)
<-- RainCT has quit (Random Quote: Bridge ahead.  Pay troll.)
<vuntz> alp: doing frequent tarballs will help make the "make dist" issues disappear :-)
 (at least, they won't accumulate for a long time, so it's easier to solve them)
<alp> vuntz: exactly why i was pushing 1.0.2 and more frequent releases, even if it disappoints people who want new API a bit
<uws> is this still about gtk-doc?
--> tvelocity[a] (~tony 195 167 65 109) has joined #epiphany
--- uws has changed the topic to: The meeting is in progress | Let's discuss topics ONE at a time. Current topic:   releasing, schedules, milestones
<alp> ok. anyone familiar enough with gtk-doc to get that patch ready?
<uws> reinouts, diegoe: please raise your points
<alp> volunteers? i can post my latest in the bug
<diegoe> alp: post it anyway, you don't loose much
<uws> ok
  
 guy
<diegoe> uws: here i go
<uws> s
 I have to leave now
<alp> i was close to landing it but was worried it'd break the build bot
<uws> so please be nice :)
<alp> cheers uws!
<reinouts> I'd just like to add that it would probably  be good if webkit-gtk followed the gnome release cycle
<uws> thanks for all the input
<diegoe> i only want to state that we need a date for "webkit with the api we just said we must put in", otherwise we will stagnate
<uws> diegoe: you will be updating the minutes? (great)
<diegoe> uws: yes, don't worry
--> michelecs (~michelecs 82 85 33 53) has joined #epiphany
<uws> diegoe: (might be useful to have a list of names/nicks on that page for future reference)
<alp> shall we adjourn the meeting and go to a more informal format?
<uws> ok
 let's close the meeting then
<vuntz> a end of december/early january deadline for "important APIs in" sounds like the best thing from a GNOME release management point of view
--- uws has changed the topic to: Epiphany || Minutes for the latest meeting at http://live.gnome.org/Epiphany/Meetings/20081020 (w-i-p)
<uws>  
 THANKS ALL
<vuntz> (and also for making sure a11y works well)
<uws>  
<barisione> I'm in favour of closing the meeting
<uws>  
  
  
  
<-- torr has quit (Ping timeout: 600 seconds)
 tvelocity has quit (Ping timeout: 600 seconds)
<uws>  
<alp> vuntz: i'm a bit frustrated that everyone talks about a11y and there's little interest in actually looking at the code i churn out
<barisione> alp: you kept the patch private for long without anybody knowing about it
<alp> is anyone personally interested in the caret navigation?
<vuntz> alp: well, I don't know how to fix this. I know the a11y team is keen to help test stuff. But it's hard to find people who will have time to look at the code itself
<alp> it was a pretty fun feature to implement
 vuntz: when wwalker started saying "a11y is hard, GNOME should focus on an accessible solution" i ended up just picking up something else in WebKit (learning the JS engine and rendering code for a few months and shutting off)
 felt like a total waste of time. i couldn't believe it
<-- monreal has quit (Ex-Chat)
<vuntz> alp: sorry, I'm not following. Do you think willie was against webkit?
<alp> vuntz: that's how it felt then. pierlux tells me things may not be so bad though and that they talked in Boston
<vuntz> alp: there's clearly a misunderstanding here
<barisione> alp: no, they were only really worried of seeing webkit entering in gnome without proper accessibility
<vuntz> alp: willie is not against webkit. He just says implementing a11y right is hard
<alp> there are half a dozen "cool features" i can hack on when i'm not reviewing patches (like making the JS JIT work on Linux, improving rendering performance, fixing the build, a11y) and a11y is the only one that i've ever felt was actually unwanted work
 so is writing a new graphics backend for Apple's browser engine, or a new complex text backend, but that's what we do for fun ;-)
<vuntz> alp: well, the thing is that a11y is a blocker for GNOME
 there's just no way around that
 I know it's probably not a lot of fun, but, well...
<-- JulioNeto has quit (Saindo)
<alp> certainly, but in a few weeks we came up with something competent, and building off Apple's a11y code it wouldn't take much more time to get something really neat. tired of hearing how difficult it is and how people have spent years working on it, because frankly the code i've seen out there is full of redundancy and boilerplate
 </rant>
<vuntz> alp: so, to get things rolling here. I think we should just make it easy to test the latest webkit so the a11y team can test and report useful bugs
--- diegoe has changed the topic to: Epiphany || Minutes for the latest meeting at http://live.gnome.org/Epiphany/Meetings/20081020
<alp> vuntz: getting a11y patches into trunk is difficult unless i strong-arm them in. might be one of the areas where a public git branch would help
<vuntz> alp: would be nice, indeed
<alp> do we have public git hosting yet in gnome? would anyone object if i used a company repo to host git branches?
<barisione> how about freedesktop?
<alp> fdo has enough bandwidth trouble right now
<vuntz> alp: there's no git hosting in gnome (except some http git, in user pages)
<reinouts> alp: when you start adding translatable strings, people will want it in gnome svn
<kov> since we're talking about git, I think you can make them 'your git branches', and ask people to test from them, so I would not object
<diegoe> reinouts: but for testing purposes, the git branch is a better way to hold wip, otherwise a patch mess will be needed for testers
<reinouts> get things working first, as far as I'm concerned
<diegoe> alp: gitorious might be better, so we can have personal branches there
 but i think we might hit the space limit easily
* diegoe doesn't see the space limit faq anymore
<vuntz> wherever a git branch is hosted, it will help for testing :-)
<jonner> yeah, gitorious might be a solution, gnome should really host a gitorious installation...
<diegoe> alp: gitorious? we can clone debian's filtered git repo and push it to gitorious and add everyone interested as committers and get them to work on their own branches if they want to
* diegoe creates a gitorious webkit project
<diegoe> kov: do you have a proper git repo of the filtered debian branch you can upload?
<alp> diegoe: everyone else is using the upstream git repo (and that's great because it means you can interoperate with other ports/qt and push back to SVN) but sadly full of pixel dump data
 terrible svn layout
<barisione> alp: also because there is not real alternative
<alp> i'm tempted to add pixel dump to GTK+ DRT just to make a point ;-)
<diegoe> ok so what do we do then?
 gitorious? upstream? debian filtered?
<kov> diegoe: I didn't really work on the packaging of webkit yet; it's maintained by the same person who maintains gecko
 but it should be here git://git.debian.org/git/pkg-webkit/webkit.git
<alp> barisione: did you consider doing your spatial focus patch in VisiblePosition so it can be generalised for node selection other than focus?
<barisione> alp: is there any chance to convince apple people that their layout is wrong wrong wrong?
<jonner> heh
<alp> barisione: they're convinced, and the bug is still assigned to me IIRC
<barisione> oh :)
<alp> but whoever works it out needs to make sure nothing breaks
<barisione> alp: I don't know what you are talking about
<alp> barisione: opera-style directional focus support
<barisione> ah, it's the first non-trivial patch I wrote. so it could be full of crack
 actually it's full of crack
<alp> it's cute, but yes
<barisione> there are things that I wasn't able to figure out correctly
<vuntz> fwiw, I'm available to be the link between webkit/gtk developers and the a11y team, if required
 just let me know if you need help
* vuntz leaves for bed
 barisione -> afk
<alp> vuntz: \o/
<diegoe> alp: kalikiana1: barisione: when do you feel we can have a first "new api milestone"?
<alp> think we still need to get together and specifically review API
<reinouts> alp you have a proposal?
<diegoe> when? which one?
<alp> just wondering to complete caret nav first and then concentrate on API, or to shelve caret
 been kind of preoccupied with that patch last couple of days
<kov> let's get together twice per week and focus 1 or 2 hours in getting a patch committed, if it doesn't get ready it gets postponed to the next meeting, or something of that sort =)
<alp> interesting idea
<diegoe> sounds good
<kov> just thinking out loud, though, I'm not sure this is viable, given people's agendas
<diegoe> what about thursday at 20 utc?
 for this week i mean
<kov> I'm good for thursday
<diegoe> alp:  barisione: :)?
<alp> sounds doable, but may do something sooner too
<diegoe> if you guys can meet together, great
 but 2 days sounds reasonable to iron out the comments on any patch
 if you agree, perhaps you can land the one about popups this thursday
 one patch/week with 1 meeting for review and another one for landing it
 maybe?
<alp> having the patches up to date and without debug code will help. i'd like to look at patches that aren't likely to be implementable by exposing soup or gio streams first if possible
 WebDownload is i think one that might be done with far less API surface area
<kov> alp: sounds good, from what I remember the patches we considered top priority do not contain debug code, such as the web policy delegates; I've cleaned my own patches, and provide test code in a separate patch
 sounds good
<alp> if mac does it by exposing a NSURLRequest/Response or subclass, i'd like to give us a shot at doing the same platform integration instead of rolling our own WebDownload class from scratch
 (not meaning to pick on WebDownload in particular)
<kov> perhaps we should start with createWindow, and discuss policy delegates next week?
<alp> yep, createWindow is certainly more fun
 the one with WindowFeatures?
<kov> yeah
* diegoe cheers for alp and kov
<diegoe> go go, discuss
<kov> it's probably easier also because you already did a quick review of the patch, and the issue you found was already fixed
<alp> so, did you check out scrolling in trunk? :-)
<kov> diegoe: =) in other news, confirmed and ready to come to brazil, btw? =)
 alp: not really, I did a git pull at the beginning of the meeting, and am getting build failures yet hehe
<diegoe> kov: sure ;)
 i have my tickets, though i will travel as diego urrelo
<kov> I'll rebase the new-window soonish
<diegoe> so we'll have new window landed by the weekend :-)?
<kov> woohoo
<diegoe> ill take that as yes
--> malnilion (~malnilion 129 244 179 171) has joined #epiphany
<-- psofa has quit (Ping timeout: 600 seconds)
<kov> diegoe: I'm all for it, but it really depends on the patch being good enough in alp's eyes, and in him having the time to properly review/commit it =)
<-- michelecs has quit (Ex-Chat)
<kov> (but I'm on it ;D)
<diegoe> good good!
 :-)
<reinouts> tnx guys, I'm heading for bed as well