Stuff

kris welcome all
rambokid ehlo krismaster.
kris matthias might be a few minutes late;
* tml (~tml@MMCDLXII.tun.saunalahti.fi) has joined #gtk-devel
* Hallski (~micke@h15n1fls305o1035.telia.com) has joined #gtk-devel
kris (matthias should show up real soon now)
* matthias (~matthias@c-24-218-204-47.hsd1.ma.comcast.net) has joined #gtk-devel
kris there he is
matthias fresh from the bike
matthias and without an agenda
matthias what do we need to talk about ?
kris do we have a schedule for the next 2.8 releases?
alex_away http://people.redhat.com/alexl/files/offscreen3.html
alex_away Here is my latest cool screen capture :)
* alex_away is now known as alex
matthias kris: one went out today...
matthias kris: I would expect to do the next one in 6-8 weeks
kris ok
kris i know one went out today, but was wondering if there was a target date for the next release or whether we would just spin a release once needed
alex matthias: is owen gonna be around for the meeting today?
matthias alex: I don't expect him to
alex ok
matthias alex: mail is the best way to reach him currently 
matthias (even for us)
alex ok
alex I wanna discuss the Gdk stuff i'm working on
alex and i think he's still the one who knows that sort of things best
matthias alex: does that make sense without owen, or should we specifically invite him to a meeting about that topic ?
alex matthias: i'll mail him for some opinions first. Maybe we can have a meeting about it later.
matthias sounds good
jdahlin I have an item for the agenda, a name for GladeXML
matthias alex: so, what does your demo show ? I only see a black square, due to lack of a plugin...
jdahlin and the name for an interface which provides additional information about constructable objects (such as how to add a child)
jrb matthias: it's pretty sweet.  It shows rotated widgets interacting with the moused
alex matthias: some widgets, and a GtkHScale that lets you rotate some of them
rambokid alex: do you generate your own crossing events?
alex rambokid: yeah
* matthias remembers that from playing with Fresco 10 years ago...
alex rambokid: pain in the ass....
alex rambokid: especially with grabs...
rambokid alex: yeah, mitch said they once had to cook that logic up for the FB port
rambokid alex: that might still be sitting around somewhere.
alex rambokid: I've already done it once for the linux-fb port
matthias we might need xserver-in-a-lib
alex rambokid: so, i had both code that i could use and some idea how it works
alex There are some issues though
alex for instance, take the GtkComboBox popup menu
alex it calculates the menu position by taking the root-origin on the top-left corner of widget->window and adding widget->allocation.x/y
alex Now, if the widget is not axis-aligned this isn't really right...
matthias alex: that gives you the untransformed position
rambokid alex: there should be a generic position calculation function in gtk that can deal with this.
alex half-transformed. The root-origin is using the transform
rambokid this kind of logic has been replicated in a LOT of places, even in third party apps
alex rambokid: yeah
matthias alex: you could transform the displacement vector
alex matthias: atm i have a signal on the GdkWindow that you can hook up to to add your own window-to-parent-coord transform.
alex matthias: that would need changes to e.g. GtkComboBox though
rambokid and everyone gets it wrong since menu popup positions/dimensions need to be bounded by monitor dimensions, and special hacks are involved to sync this with option menu offsets, etc, etc
alex (the default signal handler does the standard child position transform)
matthias it would be nice to have an exported positioning function that can handle the few things that are generally needed 
matthias like clamping to monitors, popping above/below a widget, etc
rambokid alex: wouldn't it make sense to implement the concept of a virtual desktop that does positioning if drawing multiple windows offscreen?
alex rambokid: i'm not sure what you mean
rambokid alex: well for real windows, you have a desktop/rootwindow and a window manager that takes care of the positioning.
rambokid for drawing offscreen, it's kinda hard to tell where the windows go (all 0,0 would be insane for instance). so you could implement some kind of window manager positioning logic which behaves as if the offscreen windows were positioned on a virtual desktop.
alex You're talking about toplevel windows here? Composite and the compositing manager have this issue. ATM Composite only allow you to use the "standard transform", ie. the one using the normal window coordinates
alex keithp supposedly have a plan how to get more general tranformations working, but i haven't seen it
* dindinx (~dindinx@cap69-1-82-233-39-60.fbx.proxad.net) has joined #gtk-devel
rambokid alex: hm no. i thought you just had toplevel positioning problems with your offscreen windows (toplevel ones of course), with the corresponding _Get_root_origin.
matthias jdahlin: what does the current patch use (for names) ?
jdahlin matthias: GtkObjectBuilder
jdahlin and the interface is called GtkConstructable
rambokid matthias: what's this for?
kaffee wouldn't it be better if the two names matched?  (GtkObjectConstructor + GtkConstructable or GtkObjectBuilder + GtkBuildable)
alex rambokid: The way i implement gdk_window_get_origin() is, take the gdk_window_get_origin() of the non-offscreen parent of the offscreen window, then add the back-transformed coordinates of the window in relation to the toplevel offscreen window. The transformation is user-specifiable, so in general it would be handled by the canvas widget using the offscreen windows.
matthias rambokid: libglade functionality
jdahlin kaffee: definitely
rambokid alex: ah, i didn't know you were tying this to a an onscreen window.
rambokid ok, and what's builder respectively buildable doing?
rambokid matthias: is this a component in its own respect or will it actually use/include libglade code?
jdahlin builder constructs objects from xml/gmarkup
jdahlin buildable provides additional information needed by builder, constructing, setting name, attaching children
rambokid jdahlin: what's buildable technically? an interface? implemented by what?
jdahlin rambokid: I think an interface, not sure if it's possible yet
jdahlin eg, it's not written yet
jdahlin in the python prototype I've used an adapter
rambokid jdahlin: yeah, but who would iplement it? i.e. supply this functionality?
jdahlin rambokid: GtkWidget would implement parts of it, GtkContainer other parts
rambokid adapter yeah, i see.
rambokid jdahlin: where would the xml come from?
jdahlin rambokid: a buffer or from disk
rambokid jdahlin: well how's it produced?
jdahlin rambokid: in a user interface designer, such as glade
rambokid and the designer is not supposed to be part of gtk?
jrb rambokid: for all practical purposes, glade is part of GTK right now
rambokid jrb: it's not shipped with it/gtkbuilder, so the question still stands.
jdahlin sure, as soon as matthias accepts pygtk to be included
jrb rambokid: it's not an interesting question
rambokid jrb: oh it is, for multiple reasons.
jrb rambokid: there are at least 3 independent .glade file creaters out there.
rambokid jrb: like libglade, glade and libglade2?
jdahlin glade-2, glade-2, gazpacho, stetic
jdahlin sorry, glade-3
Snorfle_ please add to agenda: website changes
rambokid the thing is, either you're going to ship an xml creator with gtk, or you get to standardize the xml somehow.
rambokid jdahlin: i wrote such a builder component already for beast, the xml there is optimized to be easily written by hand.
jrb rambokid: for better or worse, the .glade format is pretty mature
matthias rambokid: I don't see how we could accept a libglade-alike in gtk without defining the xml format
rambokid jdahlin: what i did for the buildable part was attaching function tables to types, and i'm even supporting "adding children" there which are objects which is usefull in a couple szenarios (the most obvious reason is canvas items)
jdahlin rambokid: xml & easily written by hand does really go well together
jrb (actually, it's a giant PITA in practice)
jdahlin rambokid: where can I find this code?
rambokid jdahlin: so we might want to take that part to private mail, so you can look at some of the work i've done there/concepts i've used which may be interesting for your take.
rambokid as for the GUI building component, a couple apps are emerging that support basic GUI building functionality and currently this is duplicated across projects.
rambokid so it might not only be ineteresting to ship a builder with gtk, but to support GUI building as a library component, usable by applicaitons.
rambokid if an xml based builder component goes into gtk, a GUI building lib obviously should be in sync with that builder functionality.
rambokid matthias: i don't quite understand your point about libglade-alike, can you rephrase that please?
rambokid jrb: enough reason for thorough review if your going to move this into a standard supported by gtk. at least that'd be my take opn it.
matthias rambokid: I don't think we can support generating UI from an xml format without defining the xm format
jdahlin rambokid: GxkRadgetType seem very similar to what I had in mind
rambokid jdahlin: the code is as i said in beast, but you probably want a bit of more private chit-chat about this to understand what i did there.
rambokid matthias: ok yes, agreed. i do think that having a somewhat more formal definition of that xml format than just "it's what libglade uses" would be good in terms of compatibility and reliability.
matthias rambokid: yes, "what libglade uses" doesn't cut it as a definition
rambokid jdahlin: yes, it's the radget code. dunno, the funtions might even be partly documented on the beast website at this point.
rambokid matthias: ok, agreement there ;)
matthias ok, Snorfle_ mentioned the new website / web server, so let me mention it here: http://beta.gtk.org
jdahlin did we agree on any names?
matthias jdahlin: I didn't see any new proposals
matthias jdahlin: (ignoring GxkRadget...)
rambokid oh, and for examples of where third party apps need GUI builder funtionality, toolbar editing, menu editing are already wide use examples. and work also is underway to support simple dialog design from properties of plugin networks (a couple other music programs are also working on this).
kaffee the Screenshot page links to screenshots of 2.4 -- maybe 2.10 or even 2.12 would be better.
Snorfle_ my current plan for the website is to update the look to what is reflected on beta.gtk.org currently
jdahlin matthias: the current list: Gtk(Object|Widget)(Builder|Constructor|XML|Glade)
kaffee (GNOME 2.4, that is.)
rambokid jdahlin: from what i understood so far, GtkBuilder and GtkBuildable makes sense to me.
rambokid jdahlin: online docs: http://beast.gtk.org/beast-gxk.3.html#fnindex-70
jdahlin rambokid: I wanted to use an interface, but it seems to be tricky to make it work for the actual construction
kaffee Snorfle_: the image boxes on the success page overlap the text boxes of different nodes here.
matthias jdahlin: I think owen was slightly unhappy with GtkBuilder, but I don't recall his objections
Snorfle_ kaffee: is the behavior the same on www.gtk.org?
kaffee Snorfle_: yes.
ebassi Snorfle_: same here
jdahlin Apr 05 18:05:02 <owen>  GtkBuilder isn't awful, though it isn't terribly descriptive
jdahlin Apr 05 18:06:48 <owen>  Is the object really a factory / builder? It corresponds to one resource file right?
Snorfle_ I think that is on purpose, but I didn't write that page
rambokid jdahlin: right, the function table GxkRadgetType works better there. i don't think this can be properly objectified with the GObject framework unless you create a dedicated function object which would just be an API wrapper around a function table like GxkRadgetType.
kaffee Snorfle_: on the team page, Søren's umlaut isn't displayed correctly.  (that doesn't happen on gtk.org)
rambokid kaffee: the don't overlap here, firefox resize the text layout as the images appear.
rambokid this should be tested with IE though...
Snorfle_ the CSS is not written from scratch (it is public domain) and seems to have a lot of effort working in IE
kaffee rambokid: hrm, not for me.  (firefox 1.0.7)
rambokid Snorfle_: well we do have regular windows users though.
Snorfle_ kaffee: oh, it's actually over the text, not just the boxes?
Snorfle_ rambokid: I can test in IE as well
kaffee Snorfle_: nope, just the boxes.  the text gets wrapped properly.
rambokid kaffee: where is the team page?
kaffee in the upper right there's a link.
kaffee that might be a hint that those two links aren't terribly well discoverable.
Snorfle_ agreed
Snorfle_ however, the goal isn't to keep the site like this long-term.  The goal is to clean it up enough that we have a base which validates so we can make small incremental changes as time goes on.
rambokid well soeren really doesn't look good there ;)
rambokid prolly iso vs. UTF-8 again.
Snorfle_ you think if I switch it all to UTF-8 that will go away?
matthias yes
Snorfle_ I'll do that.
rambokid Snorfle_: yep. any content you have (docs etc.) are going to be utf-8 anyway (and i18n maintainer names)
rambokid Snorfle_: couldn't the green of the menu on the left be the blue of the top bar?
rambokid Snorfle_: and, does it actually have all the content that www.gtk.org has? (with all its boxes etc.)
Snorfle_ rambokid: so they are both blue?
rambokid Snorfle_: no the menu is green and i don't lik ethe green ;)
rambokid Snorfle_: oh you mean as outcome? yes, make both blue.
Snorfle_ rambokid: I didn't realize you were anti-green :-)
rambokid that has some odd conotations... ;)
Snorfle_ heh
Snorfle_ matthias previously commented text size being too small, but I think it's the same as wikipedia and some other sites
* alex is now known as alex_away
Snorfle_ rambokid: talk tigert or one of the other graphics gurus to design us a nice look :-)
rambokid Snorfle_: or maybe we shouldn't use colorized backgrounds at all for important text (such as menus): http://beast.gtk.org/wiki:UsabilityGuidelines#colors
rambokid Snorfle_: well, who's responsible for beta?
matthias though in this case, the color is the only hint about the text being links
Snorfle_ rambokid: I am
rambokid Snorfle_: i mean for the graphical design of beta.
Snorfle_ rambokid: I ripped off some CSS and did the work myself to get the current look
rambokid and i agree with matthias on too small text size.
rambokid Snorfle_: ah, then i don't need to really talk to tigert to change the design ;)
rambokid (he appears to be way overworked tehse days anyway)
Snorfle_ rambokid: I mean, let's get someone besides me to design it and it would look better
Snorfle_ but, I think it beats the previous attempt from 5 years ago
Snorfle_ my goal is to switch this over on thursday or friday of this week so I can start looking at things like site design instead of html/css
matthias some content is missing from the old site, though, e.g. the boxes on the right "Origins"
Snorfle_ the "hard" parts will probably be the faq and tutorial
* jean has quit (Leaving)
Snorfle_ "Origins" was deleted on purpose, and the other links are to old release announcements
rambokid Snorfle_: "switch" means save the old site and copy over contents from beta to wilber?
matthias Snorfle_: I agree that the other box is outdated and should go, but why remove the "Origins", that seems to be useful information ?
Snorfle_ switch will involve migrating www.gtk.org to the cube.gtk.org; currently it runs on wilber.gimp.org.
rambokid Snorfle_: we need the 1.0 announcement still inked there! ;)
rambokid Snorfle_: where's cube located? and, was there consensus about moving the actual site at some point?
matthias rambokid: I don't think we have th 1.0 announcement on www.gtk.org, do we ?
rambokid matthias: no ;) but 1.0 was a *lot* of work.
rambokid yeah, shutting up already. just grandpa's ramblings... ;)
Snorfle_ rambokid: we did discuss cube previously
rambokid Snorfle_: i think i remember the discussion but not the consensus.
matthias rambokid: one could move the contents of the "Origins" tab to a "History" page, that would be a nice place for the 1.0 announcement
Snorfle_ rambokid: it is located on the University of Minnesota network very close to the servers which first housed the original gtk webpage and faq
Snorfle_ rambokid: the hardware was paid for by me
rambokid matthias: i was just kidding. but yes, a history page makes sense.
Snorfle_ rambokid: is there objections?
Snorfle_ s/is/are/
Snorfle_ matthias: I like the idea of a history page
rambokid Snorfle_: i think owen wasn't fully convinced. and my personal concern is that for wilber we got yosh doing maintenance for 7+ years now, and he's pretty reliably around, while i'm not sure that's the same case of r cube.
rambokid Snorfle_: and of course we (i) don't have accounts on cube. at least not yet.
Snorfle_ yosh has access to cube
* theAdib (~chatzilla@213-140-22-78.fastres.net) has joined #gtk-devel
Snorfle_ and I will create accounts as needed
Snorfle_ I've also been maintaining the box since january; patches, updates, etc.
rambokid Snorfle_: well, can you send a announcement of intention (email) and make sure to cc the relevant maintainers? i.e. owen, matthias, yosh, me, ... so if there are any issues left, people can speak up?
rambokid Snorfle_: that way you can move the site if there aren't any other issues raised.
Snorfle_ sure, sounds like a plan
rambokid Snorfle_: maybe cc-ing gtk-devel on the heads up would be appropriate?
rambokid other than that, i'd really like to have dinner now and go to bed.
rambokid so any other issues left?
matthias no, I need to go too, lets close the meeting
Snorfle_ I'd rather a private beating than a public one :-)