< ebassi> okay, as usual: the meeting agenda is available at http://live.gnome.org/GTK%2B/Meetings * mclasen goes for coffee < mclasen> ok, shall we go ? < ebassi> fine by me :-) < mclasen> do we have anything else for the agenda ? < ebassi> I didn't receive any further point < mclasen> ok < mclasen> first one is the assistant redesign < ebassi> okay, first point: • GtkAssistant design refresh: 648136 (committed, comments still welcome) < mclasen> I landed that by now (and just found some issues with it today...) < mclasen> the one thing why this is worth discussing at all < garnacho_> I think it needs some love for the default theme, I may take care of that < mclasen> is that I had to slightly weaken our guarantees for child properties < ebassi> I saw a bug from hadess about adding titles for pages; do we need to check every Assistant use and see if the title is not set? or do should we add a fallback to avoid unnamed pages? < mclasen> so that containers can have internal structure < mclasen> the problem in hadess' bug was that the control center code was poking at the internals of hte assistant < mclasen> to make the page titles take markup < ebassi> ah, okay < mclasen> and since we've moved the internals around, that broke... < Company> "poke at the internals"? < Company> in what way? < mclasen> list all direct children, and assume that the page labels are among those < Company> ah < Company> yeah, that is supposed to break < Company> if you do things in a way that is obviously not the right way to do things but works around a missing feature, you should expect it to break in the future < mclasen> I'm slightly worried that glades assistant handling seems pretty busted < mclasen> but maybe it was so before, too ? not sure... < Company> like calling APIs reserved for containers from random code < Company> (glade is pretty broken in lots of ways anyway) < ebassi> mclasen: relaxing the child properties worries me a bit; it might happen that you start poking from a button to its grandparent :-/ < mclasen> ebassi: the alternative would have been to introduce a much heavier 'composite' interface, and duplicate all the child property machinery < ebassi> mclasen: or add a GParamSpec *(* find_property) to GtkContainer? < ebassi> mclasen: then the assistant would overrid it < ebassi> override, even < mclasen> one alternative I proposed was a 'is_this_your_child?' vfunc for containers < mclasen> I think this somehow relates to tristan's ideas about composites, but I'm not sure yet how, in detail < Company> i think it boils down to protected vs public API < mclasen> anyway, I don't plan to go on a wild chase to introduce indirect-child properties all over the place < mclasen> although it would be handy in some places, e.g. response ids in dialogs < mclasen> if there is nothing else on assistants, I think we can move on; I'll keep an eye out for regressions, and hope to get cosimo/garnacho to apply some theme love to them < garnacho_> for sure :) < mclasen> next topic on the list was GtkLockButton < cosimoc> mclasen, will get to it < mclasen> I've committed that as well before 3.1.4 < mclasen> the slight concern here is that this is fairly specialized < mclasen> but otherwise, it should be a straightforward widget < ebassi> not any more specialized than the GtkSwitch, or the Assistant :-) < mclasen> the only things it is missing atm is a tailored a11y implementation and a nice example in gtk-demo < mclasen> I was struggling a bit with how to add a nice example without adding a polkit dep, I may try again at some point... < mclasen> should probably move on further to the interesting topics < mclasen> the next one is certainly more interesting: GeditOverlay < ebassi> I still need to see that in action < mclasen> its what you get if you search in gedit, no ? < Company> GeditOverlay is the popup in nautilus and epiphany, no? < mclasen> yeah, it is used there too < cosimoc> nautilus uses it for the floating statusbar yeah < Company> (i'm not gonna comment on it because i think it's really crappy UI) < Company> other than that it's interesting because it stacks widgets < Company> which no other "serious" widget does < ebassi> does it use compositing or is it just stacking? < aruiz> my only concerns with it is the navigating behaviour < aruiz> it is inconsistent with firefox for example < ebassi> as soon as you tab out, it goes away < aruiz> and not very nice to navigate the results with the keyboard < mclasen> ebassi: I think it has compositing support, but turned off by default, since it was causing performance problems with scrolling < ebassi> which is also inconsistent with chrome < mclasen> I don't think the hide-on-focus-out is builtin, or is it ? < ebassi> dunno, I haven't seen the code :-/ < cosimoc> I don't think it is, no < Company> why is it 2 widgets? < aruiz> ebassi, my concern is more about the usability of it than the consistency with other apps, how to navigate is not very discoverable < mclasen> Company: it isn't really; and I've commented that the child thing should probably just go away and be turned into regular child properties < Company> ah < Company> a workaround for child properties :) < mclasen> no, I think it is because they needed a window in between < mclasen> but you have just demonstrated how to do that without extra widgets in gtkpaned, as I understand... < Company> the handlebox can do without, too < Company> yeah, it should be quite simple to do with gtk_widget_set_parent_window() < ebassi> aruiz: to fully copy from chrome, you'd need to add a close button < mclasen> so, my general feeling is that we should probably take a container like this, since it seems to be a pattern that is actually used in apps < xan> mclasen: it is because of the need for a window, yes < ebassi> aruiz: that at least would allow closing it without a) tabbing out or b) pressing Esc < aruiz> ebassi, nod < mclasen> and we should probably get some more eyes on the code to get it closer what we want < mclasen> I already did one round of review... < ebassi> mclasen: and probably, to avoid another Switch, some input from the design team < cosimoc> my feeling is that the interaction can be improved, but it belongs to the embedded widget really < ebassi> mclasen: about usage guidelines < mclasen> ebassi: good point < Company> cosimoc: it should pretty much be done manually and not be part of the overlay < Company> cosimoc: the overlay should just be about displaying the overlay widget at some given position < cosimoc> Company, yeah that's what I'm saying - the overlay could indeed offer some high-level helpers like "move on the other side on mouse hover" < Company> cosimoc: or not if its visibility == FALSE < cosimoc> but that's just about it < mclasen> the overlay also needs to handle focus, somehow < Company> yeah < Company> it needs to do the magic for this stuff < Company> probably provide some signals to hook up to < mclasen> ok, I'll try to condense this discussion into a comment on the bug - anything else on the overlay ? < mclasen> do people agree that this would deprecate gtkfixed ? < Company> no < Company> wait < Company> gtklayout is scrollable, gtkfixed isn't, right? < cosimoc> mclasen, I don't think the overlay can be assigned an arbitrary x/y < Company> but nonetheless, fixed should be deprecated (just like handlebox) < mclasen> there is a 'static' mode; just not implemented, from what I saw < mclasen> could be easily added, I think < cosimoc> mclasen, at least the copy I copied in nautilus only worked on corners...yeah not too hard to add < Company> i would use align flags for that btw < Company> use gtk_widget_get_halign (child) to layout the child < ebassi> Company: +1 < cosimoc> that's a good idea < ebassi> fixed coordinates is not a great solution < ebassi> especially with resizable windows < cosimoc> that would make it more similar to clutter constraints too < ebassi> cosimoc: yeah, though I'd like to add Constraints to gtk ;-) < mclasen> yeah, not sure that fixed coords is going to be very useful < Company> and it'd make it possible for totem to use it < Company> if they'd want to < mclasen> although you already have it, kinda, with the offsets < Company> totem could use valign end and halign center or fill < mclasen> ok, further comments in the bug ? this clearly needs a few more rounds of refinement... < ebassi> agree < mclasen> ok, the next one should be a fun topic too < mclasen> font selection dialog < aruiz> \o/ < Company> i'd suspect it goes through some more blog posts < aruiz> so, I've been working on a branch to implement a design I've been discussing mostly with aday, but with input from jimmac and most recently hbons < Company> until no more UI guys comment ;) < mclasen> has anybody other than me tried th ebranch ? * Company hasn't, he only argues on irc or blogs < aruiz> I'm taking that as a no < cosimoc> I did not...some screenshots would probably be useful? :) < aruiz> Company, I implemented your idea of hiding the preview entry < aruiz> Company, with a property < aruiz> cosimoc, sure, one sec < aruiz> cosimoc, http://dl.dropbox.com/u/4524326/Screenshot-Font%20Selection.png < aruiz> so with this design, the major controversial point is what to do with the preview entry when it grows < aruiz> mclasen, suggests that it should eat the treviews space up to a maximum < ebassi> aruiz: resize the entry at the expense of the treeview < aruiz> okay < aruiz> that's a +2 < Lethalman> isn't it possible to compute the maximum size of the preview? < aruiz> Lethalman, for the standard sizes, yes < mclasen> you don't want to show tiny text in a huge entry, really < aruiz> mclasen, I guess that makes sense < aruiz> most times you have sensible sizes there < ebassi> plus, you want to make sure that a) the dialog does not need resizing and b) it doesn't occupy the whole screen on netbooks < mclasen> one alternative you could try is to avoid the vertical scrollbar and go for a paned instead < mclasen> which lets you manually shrink the list to make the preview fit < aruiz> ebassi, yeah, I've designed the dialog with small screens in mind < aruiz> mclasen, I had something like that in 2.x, but the size_request behavior changed < cosimoc> aruiz, why the marks on the range? < aruiz> cosimoc, those are the standard sizes < aruiz> cosimoc, it's more convinient than a treeview < mclasen> some of the designers favor a different arrangement: http://bugzilla-attachments.gnome.org/attachment.cgi?id=187582 < aruiz> and they are not critical enough to use the space of a whole treeview < ebassi> I like the slider; it's more informative than a spin button < aruiz> mclasen, I have several problems with that design < Company> mclasen: the fontselectionwidget is orientable! < Company> mclasen: :) < mclasen> more like a netbook mode < cosimoc> I like the slider too, but I think marks other than the default size don't really add anything < ebassi> it could detect the aspect ratio of the screen < aruiz> mclasen, the first one is that it scarifies horizontal space for both the treeview and the preview < ebassi> and change orientation based on that < aruiz> mclasen, the other one is that the slider will be next to the treeview's scrollbar < aruiz> very confusing < mclasen> yeah, I noticed that too < mclasen> so, lets not get hung up on this one thing < aruiz> and the relationship between the spin button and the slider is lost in that layout < aruiz> yeah < aruiz> I mean, I'm open to suggestions < mclasen> there's some other questions that are maybe more relevant for this meeting < aruiz> but I did run through a lot of iterations with jimman and aday < aruiz> and I moved over stuff to C when there was some consensus in gnome-design < mclasen> such as the deprecated old apis, and code to support them < aruiz> yes < aruiz> So I deprecated the accessors to the old treeviews, but still implemented them to work alongside the new UI < mclasen> I guess there's two questions here: < mclasen> if they give you a treeview thats not actually shown, is that cheating ? < aruiz> mclasen, yes :P < mclasen> and is that going to be useful for whatever use people might have for those accessors ? < ebassi> I do wonder if somebody is actively using those < cosimoc> aruiz, so you create a treeview on the fly that mimics the old behavior? < aruiz> cosimoc, yeah, there's some signal spaghetti involved, but yes < mclasen> would it not be more straightforward to just return NULL ? < ebassi> because I honestly can't see the point in accessing the treeview of a composite widget < aruiz> ebassi, AFAIK, none < ebassi> we don't allow that for GtkFileChooserWidget < Company> mclasen: depends on your goal - NULL would break apps < aruiz> I searched through codesearch < aruiz> and found nothing but bindings < ebassi> (even though people begged us to do that) < mclasen> Company: assuming any apps use these apis < Company> mclasen: yes < ebassi> I'd return NULL, and if apps break then we can fake it < Company> mclasen: but if we break it anyway, we could just remove the API < mclasen> the obvious alternative would be to leave the old fontsel in place, and put a new api next ot it < aruiz> honestly, I though you guys would yell at me if I returned NULL < mclasen> but then people have to port < aruiz> :-) < Company> mclasen: and claim it was a bug we left it in for 3.0 < ebassi> Company: bindings are more resilient against NULL than against a missing symbol < Company> ebassi: true * aruiz is happy to maintain that code < Company> ebassi: we could also just return the font list tree view -.- < ebassi> mclasen: GtkFontChooser? < cosimoc> I think I would like better having a new widget altogether < cosimoc> that leaves no room for misunderstandings < Company> yeah < Company> doing subtle things leads to subtle bugs < aruiz> that would be two new widgets or just one? < aruiz> I mean < Company> i know from GtkLabel::width-chars < aruiz> GtkFontChooser + Dialog < ebassi> aruiz: GtkFontChooserWidget and GtkFontChooserDialog < mclasen> aruiz: it would be 2, I think < aruiz> or would GtkFontSelectionDialog use FontChooser underneath? < ebassi> aruiz: like GtkAppChooser, GtkRecentChooser and GtkFileChooser < Company> gtk_font_selection_dialog_get_apply_button() < ebassi> aruiz: no, I'd deprecate GtkFontSelection* < Company> we do have awesome apis... < aruiz> okay < ebassi> aruiz: like we deprecated GtkFileSelection* < aruiz> Company, yeah, I thought the same thing :P < Company> ebassi: +1 < aruiz> okay < mclasen> ok, so we all think that that is better ? < mclasen> cool < aruiz> you guys tell me what to do, I have no strong opinions in this regard < mclasen> it does mean that apps need to be ported, but that should not be hard, I assume < Company> we can then reuse the "selection" term when we deprecate the cooser widgets < mclasen> aruiz: I hope you don't mind the extra work < aruiz> mclasen, I'll cry a little bit for the few afternoons I spent on the deprecated stuff, but that's about it :-) < aruiz> I'm fine with it < Company> aruiz: you now have full freedom in redesigning the API < Company> aruiz: so i'd throw out everything that people don't need :) < mclasen> that is an added benefit, indeed < ebassi> just make it small :-) < mclasen> and we probably do want some extra apis < aruiz> ebassi, yeah < mclasen> like app-provided filtering (monospace !) < aruiz> mclasen, the monospaced filter < ebassi> and, for god's sake: no poking at internals! < aruiz> mclasen, app-provided? < aruiz> with some sort of filtering function? < mclasen> as opposed to by-the-user < aruiz> ebassi, absolutely < mclasen> like a little brother of GtkFileFilter < Company> i suppose that's easy - gboolean (* FontFilter) (PangoFontSomething *font, gpointer data); < aruiz> mclasen, is that a requirement for an eventual merge? < mclasen> no < mclasen> just something to keep in mind < aruiz> I will, definitively < Company> mclasen: GtkFileFilter sucks, don't use that... < ebassi> a simple function would do < mclasen> now that we gave aruiz enough to do for the next week, we should probably move on... < ebassi> we don't need mime type or regexp < mclasen> quite a few more things on the agenda < aruiz> yup < ebassi> right, next up: GProperty < mclasen> gproperty ? I lost track of the developments there < mclasen> whats the latest ? < ebassi> I have a v0.2 which bypasses GValue and adds some API that makes Company happy :-) < ebassi> missing docs+examples, a bunch of cosmetic fixes, a GVariant variant, and locking < mclasen> ok < Company> i mainly added it to the list < Company> so that everybody is aware of it < ebassi> it's on a branch on git.gnome.org now < Company> i expect that ebassi, me and whoever is interested will review it < ebassi> so people can check it out (though I rebase it quite often) < mclasen> anything to discuss there today ? or just ongoing in bz ? < Company> and then merge it when we're happy < mclasen> sounds good to me < Company> and then port gtk < mclasen> although we probably need to hire janitors at some point < Company> and other stuff < mclasen> we are already behind on the latest property technology in gtk < Company> to make sure it really works how we imagined it < Company> what are we missing in gtk? < mclasen> the pspec array stuff < ebassi> mclasen: the nice part is that changing this + array of paramspecs is a single job < ebassi> since it integrates nicely, and both touch the same code < mclasen> that is nice, indeed < ebassi> but yeah, it'll need some of the old jjardon magic :-) < mclasen> I'll look at v2 when this gnome release is behind me < mclasen> does it still do the atomic stuff, or did you drop that ? < Company> while we are at announcing stuff * aruiz is in the same room that the so called janitor < Company> i should probably announce the pending css parser merge < Company> especially now that garnacho_ listens < mclasen> good point < Company> so for anybody not aware of it: < ebassi> mclasen: I didn't drop the API, just the implementation; I actually added API for overriding the lock/unlock primitives < Company> i've a rewrite of the css parser that does not use GScanner and conforms closer to css < Company> *css parsing rules < ebassi> mclasen: I'll work on the default implementation along with the rest of the fixes < mclasen> makes sense, I guess < Company> the main reason is that i want proper error handling with line numbers < Company> and long term i want to get to making css work properly with inherit etc < jjardon> ebassi: give me the first patch ;) < Company> i'm doing that with cosimoc < Company> so if anyone wants to provide input there, it's in gnome git, the parser branch < mclasen> I will, after 3.1.1 < mclasen> I don't have a ton of time today, so let rush the deprecation topics, if you don't mind... < ebassi> sure < mclasen> there's various: h/v variants, table/box, misc/alignment and color < ebassi> my take: yes, yes, yes and yes :-) < mclasen> not sure there is too much to discuss here, even < cosimoc> box is going to be huge < Company> question is how quickly we want to deprecate it < mclasen> I did merge tristan's rgba textview patch, so we are much closer on gdkcolor < mclasen> box is not really realistic for 3.2, I think < jjardon> links to the bugs in http://live.gnome.org/GTK+/Meetings < Company> yeah, color should go asap < jjardon> cosimoc: yeah, thats the most difficult task < mclasen> the others are much easier < Company> color just requires someone doing the work < Company> misc should go asap, too < mclasen> what exactly is left in gdkcolor ? just style properties ? < ebassi> misc and alignment should just go < jjardon> Company: I'm sending patches to the bug to review. Thanks mclasen btw < Company> mclasen: i think it's just the API < Company> mclasen: style properties should all be rgba by now < ebassi> one thing for Box would be a nice migration chapter, with examples for each setting < ebassi> and screenshots < mclasen> there's some leftovers like link colors < Company> damn < jjardon> mclasen: the link colors < ebassi> those are pretty trivial < mclasen> ebassi: yep, that would be of utmost importance < Company> and we can't change that i guess because of API stability? < ebassi> it's just two: link and link-visited, AFAIR < mclasen> the thing is that nobody really uses style properties as api < Company> there might be subclasses? < mclasen> they are just set in css (where we parse whatever) and used inside gtk < jjardon> bug here: https://bugzilla.gnome.org/show_bug.cgi?id=648989 < Company> i'd like to move a bunch of properties around fwiw < ebassi> you cannot set style properties directly anyway < Company> and i'm not yet sure how to do that without breaking API < mclasen> what kind of properties ? < Company> ebassi: but style_get (widget, "link-color", &gdk_color, NULL) will break... < ebassi> you can mark properties as deprecated < Company> mclasen: big thing is merging style properties and style context properties or whatever they are named < mclasen> Company: we can add a rgba property next to it, deprecate the original, and keep them in sync < mclasen> but yeah, just phasing out style properties altogether might be better < Company> mclasen: that's kinda ugly in the css though, we'd need special cases there... < Company> should link-color be using :visited or some generic state flag? < Company> or is :visited too css specific? < Company> also: it's probably something not for this meeting < mclasen> sounds like a nice idea, actually < ebassi> :active, :hover, :visited < ebassi> would be nicer using pseudoclasses like that < mclasen> yeah, so: anything else on deprecations ? it seems jjardon is working on it, and I will try to do some work on the migration docs too < mclasen> if not, I'd like to close the meeting and run off, unless there's misc items to bring up < ebassi> not here * mclasen has one himself < jjardon> yeah < jjardon> what about the new website? < mclasen> I haven't followed that, tbh < ebassi> jjardon: I think the person that was working on that disappeared or something < ebassi> we'll have to poke martyn again < mclasen> there was a mail from martyn today < mclasen> where he said 'I'll migrate it shortly' < ebassi> oh, cool < jjardon> oh, ok, I didnt see that < mclasen> sent 3 hours ago < mclasen> I wrote an initial patch for hiding focus rectangles < mclasen> when not doing keynav < mclasen> the designers wanted something like that to reduce clutter < cosimoc> mclasen, how do you detect if we're doing keynav or not? < mclasen> it is somewhat limited, but maybe people want to give it a try anyway < mclasen> I just show the rectangles when any key event comes in < ebassi> mclasen: do you have a bugref? < mclasen> no good way to discriminate between e.g editing in an entry and 'keynav' per se < cosimoc> mclasen, ah so it's hidden by default and activated after the first keypress < mclasen> https://bugzilla.gnome.org/show_bug.cgi?id=649567 < ebassi> thanks < mclasen> yeah, I tried to be smart and inherit the initial value from a transient parent < mclasen> but what you would really need is to pass not just a timestamp along, but the entire event, when activating a window/application < mclasen> so you could see if it was activated 'by keynav' < jjardon> about GtkBox -> GtkGRid transition, what do you think about set a GnomeGoal / GtkGoal as seems a huge work but that can be done for new contributors? < mclasen> I think we need the docs first, before such a goal can make any sense < mclasen> also, I just found what looked like some issues with nested grids today < Company> yeah < Company> i'm not sure how expand flags should really work yet < mclasen> so maybe not quite ready for widespread conversion yret... < Company> and i don't think hp is either... < jjardon> mclasen: sure < mclasen> sorry, I have to go now. Thanks everybody ! < mclasen> see you sometime soon < jjardon> see you! < ebassi> thanks everyone for attending < ebassi> as usual, minutes will be sent to the list ASAP, and log will be on the wiki < ebassi> next meeting in two weeks, if everyone is alright with that