Transcript of IRC Meeting: April 24, 2002

[Jon Trowbridge <trow ximian com>]

This is a transcript of that the Gnome Office meeting that was held on
#gnome-office today.  I've edited it slightly, removing lots of "hellos"
and "goodbyes" and a few OT comments.

        dom> jody: the floor is yours :)
      biesi> ah yeah... you might be interested in this... a recent c't (german
             computer magazine) article compared some linux office suites, and
             gnome-office was critisized for the lack of integration with each
             other
       jody> We have a floor ?
      biesi> s/each other//
        dom> jody: so to speak :)
       jody> Ok folks, lets start with a quick role call.
       jody> We have some abi-folk
       jody> some gnumeric & guppi folk
        ---> jody spots Hallski as the MrProject rep
    Kenneth> and rhult
    Hallski> jody: and rhult
    Hallski> ^5 Kenneth 
       jody> Do we have any gnucash / evo / dia people ?
    rodrigo> yes, I'm from evo, and gnome-db :-)
       jody> I suspect that lauris and the sodipodi-folk are unavailable
        dom> i've broadcast it in #gnome
       jody> Any achtung or spanish presentation project folk ?
        joe> yo
        joe> achtung in the house
       jody> joe !
    rodrigo> ViGueTo is the 'spanish presentation folk'
      biesi> hm... is gnome-pim part of gnome-office?
    Hallski> great
       jody> biesi: lets save those for later.
    Hallski> joe: are you actively hacking on achtung?
        joe> Hallski: unfortunately, not actively, no. :(
    Hallski> oh :(
       jody> The first thing that would nice to cover would be release targets
       jody> As I see it there are 2 options
       jody> 1) Do a release (tentatively called 0.5) of all the 1.0 projects
             and their support elements
       jody> this would be based on gnome-1.4
       jody> and would be released with a minimum of integration
       jody> 2) Do a later release based on gnome2
       jody> call it 1.0, and attempt to get some actual integration in place.
    rodrigo> jody: I think we can do both
       jody> rodrigo: we can definitely do either or both, the question is do
             we want to bother.
      biesi> jody: yeah, what about both; firstly release 0.5 with no
             integration, later 1.0 with integration
        joe> What is the benefit of doing a 0.5 release?
    Kenneth> PR
       jody> joe: marketing
        dom> the benefit of doing a 0.5 release is for marketing and press
    MCArkan> joe: let the users start playing
    menesis> jody: depends on how people feel about hacing on gnome1 stuff
      biesi> joe: you can get the complete gnome-offiec in one place
    rodrigo> jody: yes, I mean the same as biesi, 0.5 is just the current apps
             in their current state
       jody> About the only useful integration in a 1.0 would be evolution
       jody> we could all back port support for 'Send file'
    rodrigo> and 1.0 is for GNOME 2 with more integration
    Hallski> how much hacking is going in on the gnome 1 versions of programs?
    Hallski> I know that we in MrProject spend all our time on the gnome 2
             version
     ettore> Hallski: evolution is going to be maintained on gnome 1 at least
             until july
      biesi> Hallski: well, abiword is gnome 1 only
    rodrigo> Hallski: the same for gnome-db
     ettore> Hallski: then we plan to port
        dom> Hallski: abi is being ported to gnome 2 right now
       trow> I'm spending all of my (little) time on porting guppi to gnome2
      biesi> dom: really, didn't know that
        hub> dom: you or martin ?
        dom> biesi: yeah, there's some stuff in my and samth's trees
   chrisime> dom: /me amazed
        ---> Sc0tt grins... as long as these apps don't follow the wheelchair
             tactic of sawfish2
   chrisime> dom: already?
        dom> chrisime: ja
        joe> Well, most of the 1.4 versions that are stable are already out
             there in Ximian GNOME
    Hallski> exactly, so spending too much time on integrating gnome1-versions
             might not be the best spent time (better to first port and then
             start working on that, less to port)
   chrisime> dom: oh. just tell me where u need help
       jody> Hallski: that would seem to be the main draw back to a 0.5
             release.  It would consist almost entirely of apps that are
             actively developed on another platform
        dom> clearly all of the existing apps must have some CVS tag for when
             they stopped development on gnome-1.4 and went onto 2.0
        dom> chrisime: later
     lewing> joe: which also makes it pretty easy to release them
     ettore> yeah, I don't think a .5 should happen now
   chrisime> dom: no hurry
    rodrigo> and is nice for users to say 'install gnome-office' and have all
             apps installed
      biesi> Gnome-office was critizised for not having an easy way to download
             all parts of it in one place
      Sc0tt> rodrigo: I've thought of that as something in the like of mozilla
             installer...
     lewing> so if we skipped 0.5 when could we reasonably expect the major
             apps to be gnome2 ready?
      Sc0tt> rodrigo: where you select the components you wish to have.
        dom> lewing: abi will take some work
        dom> i can't promise anything any time soon
       jody> lewing: If we had a target date of Dec/02 we'd probably be ready
             to freeze
    Hallski> lewing: as for mrproject (which probably doesn't count as major)
             it's already better and more stable on gnome2
    rodrigo> gnome-db is 'fully' ported to G2
      Sc0tt> btw, is this being logged? I'm generally agains logging on irc
             channels, but it would be nice to have the meeting saved... maybe
     lewing> jody: that seems reasonable
      biesi> Sc0tt: it is
    Hallski> Sc0tt: yes
      Sc0tt> biesi: hallski:L ok, thanks.
       uwog> abi1.2 could be freezed in Dec/02, couldn't it Dom? that would
             leave us with plenty of time
    rodrigo> jody: yes, that sounds good
       trow> I'm hoping to have guppi ported within two months.  Then the
             gnumeric integration has to happen.
        dom> uwog: that's more than enough time
        hub> uwog: no. we can't promise a freeze for 1.2
        mg_> uwog: for porting, but for features?
        hub> dom: are you serious ?
    Hallski> trow: as well as mrprojcet integration :)
        dom> hub: we can retarget our milestones
       trow> Hallski: We'll have to talk about that...
    Hallski> trow: yes
      Sc0tt> hub: dec02 seems long enough for some serious overhaul.
        hub> dom: you mean not implementing tables and other stuff ?
    rodrigo> trow: and gnome-db, I plan to make graphs out of DB's with guppi
      Sc0tt> hub: maybe not all, but some.
        dom> hub: and take a more incremental approach to things
        hub> dom: hmm...
        dom> hub: exactly
    Hallski> is the dec02 for gnome2 or gnome1 version of gnome-office?
        mg_> 2
        hub> dom: time to think about it
    rodrigo> Hallski: I hope it's gnome2
        hub> dom: anyway I thought about other Abi specific plans. more to
             follow
        dom> hub: in #abiword please
    gabriel> dom: i think not implementing tables now would be a misstake,
             since we have told users that all the time
    Hallski> rodrigo: me too :)
        hub> dom: in mailing list.
       jody> Lets take the rest of the timeline discussion onto the list
        dom> hub: sounds fine
    Hallski> jody: yes
       jody> The next thing that I'd like to discuss is a status update
        dom> gabriel: we'll progress at a good pace
       jody> rodrigo has lept in and starting a gnome-office module
    Hallski> rodrigo: is that gnome1 or gnome2-based?
       jody> it is in cvs and has the beginings of the gnumeric pluging system
             extracted
       jody> it is glib2 based
    Hallski> ok, great
    rodrigo> Hallski: gnome2
     ettore> hmm
        joe> yeah, it looks nice
      biesi> What's this module for?
     ettore> I think I must be missing something
     ettore> what is the list? :)
    Hallski> any ideas when the copy/paste-stuff will go in there?
    rodrigo> it's just the starting of a plugin system for all GO apps
        dom> ettore: gnome-office-list
     ettore> ok
    rodrigo> ettore: gnome-office-list
        ---> ettore subscribes
       jody> In an effort to make the abi-folk comfortable we'll try to keep
             the lib with only a glib dep
        hub> jody: thanks
        dom> libxml2 should be ok too
    rodrigo> jody: I've got something to say about the plugins, so I'll say it
             later, whenever you want
        hub> libxml2 ok for me too
       jody> The goal is to have the plugin code and the undo/redo journalling
             inthere
       jody> hub: good point
        mg_> dom: our own support for that is still not 100% isnt it?
       jody> hub: that will also be required
     mantas> hello all
        dom> mg_: it works just fine
    Hallski> oops, I meant undo/redo not copy/paste
    rodrigo> hub: and the lib jody is doing will also be a dependency
       jody> I have been working on a replacement for libole2
     sander> dom: if you allow libxml2 libxslt is also very reasonable and
             allows you to import xml file formats for which you have a
             transform trivially
       jody> that will offer 2 things
        mg_> dom: Oops, my misconception
        hub> rodrigo: if it only depends on glib and libxml2, I can cope with it
        hub> rodrigo: MacOS X is not that hard unless you use X11.
       jody> 1) A simple I/O abstraction
        dom> sander: that's not on the table here
    rodrigo> jody: which dependencies has the libole2 repl?
       jody> 2) support for ole and OO style structured files
       jody> rodrigo: glib2
       trow> jody: will that stuff go into libgnomeoffice, or be separate?
      biesi> jody: why a replacement for libole2?
    rodrigo> jody: cool
       jody> There is an optional gnome-vfs depend
       jody> but it distinct, offered only as another i/o source
   chrisime> jody: what's the reason to replace libole2
        dom> libole2 has its share of problems
       jody> chrisime: the current implementation is unmaintained, and is quite
             brittle
        dom> its file system abstraction is bad, the code is sloppy, and it
             can't write files > 5MB
        dom> it is also unmaintained and fragile
       jody> dom: 6.8M
   andersca> jody: was it going to be zip-based?
        dom> jody: close enough :)
      biesi> dom: oh, that are good reasons
   chrisime> dom: strange limitation!
       jody> andersca: the OO structured files are zip based
   andersca> ok
       jody> The interface I've spec-ed out attempts to abstract that.
   andersca> whatever you do make sure there can be some sort of identification
      biesi> What does libole2 has to do with OO's XML files?
   andersca> so we can get the mime type by sniffing the data
        dom> andersca: already done
   andersca> cool
       jody> andersca: that is one of the main goals of the format
   andersca> jody: lovely
        dom> the openoffice list has discussed this to death already
        dom> the gnome, openoffice, and kde folks reached a nice consensus
   andersca> ok
   andersca> great
       jody> I'll probably deploy it as part of the gnome-office module
       jody> With these elements in place I suspect the first thing to do will
             be to
       jody> port gnumeric over onto the platform
       jody> The plugin/undo code should be easy since we're already using it
       jody> the io will be more work.
       jody> once it works there, ideally abi will be far enough into its port
             that they can be the next to jump
       jody> other projects have also mentioned a desire to use these apis
        dom> abi will absorb the plugin code and the io code quickly. the
             undo/redo might be a bit harder, but we'll work on it
    rodrigo> the plugin system in gnome-office is really simple
       jody> the goal is to focus on the interfaces
    rodrigo> so there might not be problems in adding its use to GO apps
       jody> rodrigo: the key work will be getting the interfaces for the
             various services right
    rodrigo> yeah, new interfaces (called services in the plugin system) should
             be defined
    rodrigo> some that are missing there and are in gnumeric:
    rodrigo> * file opener/file saver, which I guess could be merged into 1
       jody> There are several services still missing from gnumeric
    rodrigo> which ones are they? have I missed any?
       jody> things like clipboard support are quite important
    rodrigo> oh, right
       jody> a plugin should be able to register a service that parses/produces
             various mime types
       jody> so that the app can support content negotiation for that type
             using the selection
       jody> eg select a table in mozilla
       jody> paste into gnumeric
       jody> have it parse the html
       jody> but these are details for the list
    rodrigo> I also want to add a 'acquire-data' service
    Hallski> yes, that would be very nice
    rodrigo> so that you can query a plugin, and get a set of rows of data,
             like in a database
       jody> There are 2 more things that we should think about
       jody> 1) printing
       jody> 2) shared drawing layer for presentation,gnumeric,abi
      biesi> hm... can't gnome-print be used for printing, at least on
             platforms where it's available?
       jody> gnome-print is in bad shape
     lewing> gnome-print is pretty weak
        dom> if gnome print wasn't so.. ummm... bad, i might agree
       trow> biesi: no pango support is a problem
       trow> (among other things)
   chrisime> jody: I've proposed to write the GUI for the new printing framework
      biesi> trow: I thought pango was for screen output only?
    rodrigo> pango might support printing, I've heard, is that what we'll use?
       jody> at a minimum we need something that can print from pango
         mg> I was under the impression that there is going to be a total
             overhaul of gnome-print (aka rewrite)
       jody> and uses FontConfig for the fonts
     _kris_> dov was working on some pango to ps stuff IIRC
   andersca> yes
       jody> The basic gnome-print api of pseudo-postsript should be fine
       jody> as is.
       mawa> oops, i always sold gnome-print as a particularly nice gnome
             feature :)
       jody> chema is now the maintainer of gnome-rint
       jody> and he's got some good ideas for integration with cups
       jody> but there are currently no resources to actually do the work
       jody> dom: can abi use gnome-print if it works ?
        dom> jody: abi already uses gnome-print
         mg> yes
        hub> gnome-print or it's replacement should offer API to set-up links
        hub> that way we can easily create hyperlinked PDFs
        dom> there are some interesting things i'l like to get into GP, like
             hyperlinks and bookmarks, the so-called PDF extensions
        dom> we can talk about that with chema later though
      Sc0tt> jody: however, since it's in a pretty bad shape, we've included a
             'Direct Print' using our renderer into gnome builds again.
        dom> Sc0tt: believe-it-or-not, our native PS driver is more broken than
             gnome-print is...
      Sc0tt> dom: it is? oh my... 
       jody> If the goal is to use pango
       jody> and I hope that it is
         mg> Sc0tt: I agree.  A lot of crammed characters, violated margins,
             etc.
      Sc0tt> mg: I haven't printed from abi in ages anyway.
       jody> then the notion of a shared drawing area seems reasonable
     mantas> dom, hub: AbiWord 1.0 released, but still are big problems with it
             - users can't share data with other applications :(
        ---> Kenneth is happy that he doesn't have a printer
        dom> mantas: please explain yourself
    Hallski> Kenneth: :)
        dom> as if the 15 different file formats we support don't count...
       jody> The idea would be something similar to dia and its canvas
        ---> Hallski would be happy if no one had a printer so that we didn't
             have to add printer support to mrproject
        hub> mantas: that is not the scope here
    rodrigo> there is a project called diacanvas2, which might be that drawing
             layer
    rodrigo> and is ported to gnome2 already
      Sc0tt> Hallski: think of the days where your screen was a printer :)
       jody> rodrigo: I've looked at it.
    Hallski> Sc0tt: :)
    rodrigo> jody: and?
       jody> diacanvas2 has some nice stuff
       jody> but still needs some work
        hub> Sc0tt: I usually print PDF done from the PS output of Abi
       jody> It is fairly close to our needs in several spots
         mg> Where does it lack?
     mantas> because rtf import/export is bad :(
        dom> mantas: our rtf import/export is near flawless, actually
    rodrigo> mantas: abi+rtf works perfectly for me
        dom> unless you throw cocoa rtf at it...
       jody> Sadly it is not directly targeted at what we'll need
        hub> dom: who cares of Cocoa RTF:-)
    rodrigo> mantas: even sharing that with windows users
        dom> in which case, i could throw the same crap at gnumeric and get a
             similar result :)
       jody> so a fair amount of thought will be needed to support the derived
             application adding some extra bits to the objects
    danmorg> abi rtf between ms office works fine for me
    rodrigo> jody: so what are your thoughts on the drawing area?
       jody> The main goal of such a system would be so that dia style drawings
             would have a common editing and storage representation amoong all
             he apps
       jody> eg you could have the same org chart in all the office apps
     mantas> and OpenOffice import/export is not finished :(
       jody> and they would not have to do all the ugly irritating work to
             support prop boxes for the various objects
        dom> mantas: not one more app on the planet supports OpenOffice...
        dom> except openoffice, of course
    rodrigo> jody: but in terms of code? a new lib? reuse and existing one?
             refactor?
         mg> Sc0tt: took the words out my mouth (:
       jody> rodrigo: The 2 obvious choices are dia and sodipodi
       jody> we'd want them 'libraryified'
    rodrigo> yeah, sounds good
       jody> I initially prefered sodipodi
       jody> because it uses svg
      Sc0tt> jody: but?
    rodrigo> yeah, and supports other formats, right?
       jody> and nice well understood standard
       jody> but, it is also based on the AA canvas
   andersca> ugh
         mg> Hmm.
       jody> which is just not feasible as a basis for a shared drawing layer
       jody> Which leaves dia
       jody> I should be clear here.  I do mean _drawing_ layer
      Sc0tt> btw, is there anyone from dia here?
       jody> that would mean both model and view
         mg> jody: How compatible (not that it was intended to be) are the two
             code schemes that it may or may not be feasible to work the two
             into some new hybrid creature?
        hub> Sc0tt: I follow dia for almost a year now....
       jody> mg: dunno
      Sc0tt> hub: I followed the mlist, but I haven't resubscribed since I've
             been changing my email.
       jody> It seems feasible for abi to share such a layer, even though it
             would not be a native widget
       jody> It would basicly be a big canvas
       jody> with drawing objects and pango stuff
        ---> Sc0tt uses dia daily with a 500k file.
    rodrigo> hmm, model/view separation seems very nice, so that you can create
             graphics in scripts
        dom> i don't see a problem with embedding a GDK/Pango based canvas in
             the middle of our frame
     mantas> I only want to say about one, XML-based file format for all
             open-sourced Office applications...
       jody> dom: great.
        hub> Sc0tt: what was the question ?
       jody> mantas: that is a debate for another time.  I personally do not
             think that is feasible.
         mg> Mmm...dom what will the layout engine changes effect in that area?
              By 1.2?  2?
        dom> mg: later...
         mg> k
       jody> A shared drawing area would not be ready for any form of 1.0
       jody> that is a longer term goal
       jody> On a maginally related note
      Sc0tt> mantas: go check oo's dtd if you want to know what you're really
             asking for.
       jody> There was talk of an EMF -> SVG converter
        dom> yes, fjf was working on that
        dom> we can work on that harder maybe :) you seem to be less picky than
             the imagemagick folk
       jody> EMF == ExtendedMetaFile, a windows vector style format.
        dom> we already have a WMF->SVG converter
        dom> which basically works
    Kenneth> something like WMF?
        dom> EMF=WMF+32 bit integers and a little bit different header basically
       jody> Kenneth: a cleaned up version of WMF
       jody> This seems to be a very common format for ms-office docs with clip
             art
    Kenneth> I see
        dom> yeah, all clip art is wmf or emf in my experience. many company
             logos and such are also emf and wmf
    Kenneth> ok
        dom> we would gain more support if we fully supported EMF and WMF at
             least on a viewing level
       jody> In summary I'd like to discuss a bit of high level direction
    Kenneth> what do you mean with that? more support?
   jon_kare> There is EMF code in OpenOffice.
        dom> more people would adopt the GO apps if we better supported those
             graphics formats
       jody> jon_kare: I could not see how to easily extract it
   jon_kare> Kenneth: Better import of MS Office formats
        dom> jon_kare: yes, and i've seen it and run away from it screaming...
    Kenneth> ah, yeah, but would the converter be enought for that
        dom> the EMF,WMF->SVG converter would be fine
    Kenneth> k
       jody> As things stand we are a very very loosly knit community
        dom> they could edit the SVG in another app like sodipodi if they
             needed to, which is *extremely* uncommon
       jody> Sharing code is going to be hard
    rodrigo> I don't think so, if we keep clean of dependencies and make simple
             interfces
       jody> I suspect the easiest way to achieve some integration is to tack
             on shared libraries
    rodrigo> as soon as we are all using those simple APIs,
       jody> and interate our way there.
    rodrigo> using more and more is easier
       jody> rodrigo: it is hard to make those initial steps
        dom> the first steps are a killer. it will be tough for abi, but i'll
             do my best
    rodrigo> yeah, but as soon as we do that, which it seems we're going to,
             things will be easier
      Sc0tt> dom: thomasf isn't particulary happy about pango either :(
    Kenneth> dom: Are you going to adobt the tree A's instead of B I U for Bold
             Italic and Underline. Gnumeric does this today
       jody> Yes, which is why I'd like to focus on small easily modularized
             bits first
    Kenneth> it seem to work very well
        dom> Kenneth: i don't know
       jody> Kenneth: abi will get those for free from the gtk stock icon set
        dom> pango is not without its many problems
        dom> i need to update our icons from the gtk+ stock icons. they changed
             them too frequently...
    Kenneth> jody: but they do not use gtk on all platforms so they are
             hardcoded
        dom> i can turn a PNG into an XPM trivially...
        dom> convert gtk/icon.png -to abiword/icon.xpm
       jody> Kenneth: they can copy the pngs easily
    Kenneth> dom, but they you do not get antialiasing, right (or I didn't in
             gnomemeeting, so I used gtk-csource to convert instead)
    Kenneth> true
        dom> Kenneth: that is another issue...
        dom> when we go to gtk+2, anti-aliasing will work fine
        dom> on win32 we'll just turn AA off...
        dom> it's not rocket science
    Kenneth> dom: aa didn't work fine for me with xpm's
       jody> can we get some status onmrproect and the presentation progs ?
        dom> Kenneth: that's becasue we use GTK+1.2 now...
        dom> gtk+1.2 toolbars don't support AA'd xpms
        dom> therefore they look like crap
       jody> sorry for typos baby wants botte
    Kenneth> dom: heh, I didn't talk about abi, but about gnomemeeting. we use
             gtk2, and it didn't work
       jody> Hallski, rhult ?
    Hallski> jody: yes?
      rhult> jody: ?
    Hallski> oops :)
         mg> status
       jody> how long to what you'd consder 1.0 ?
         mg> (-:
    Hallski> jody: hm .. that depends a little on how much time we have to hack
             MrProject
    Hallski> that is (what CodeFactory decides that we should be doing with our
             time :)
       jody> can you offer upper and lower bouns with reasonable confidence ?
    rodrigo> Hallski: you've got acs to work :-)
    Hallski> rodrigo: we sure do
    Kenneth> acs?
       jody> joe : did the gnome2 achtung code make it into cvs ?
    rodrigo> Kenneth: Alvaro del Castillo, a Spanish friend of mine whos joined
             mrproject
    Kenneth> rodrigo: I see
        joe> jody: not yet... I'm thinking that we might want to rely more upon
             gibbon than achtung
    Hallski> jody: if we decide to have a dec02 deadline I really think we will
             be finished for that
        joe> Kenneth: nope, it's in C... (for now. ;)
    Hallski> rodrigo: he is involving more spanish people too :)
      Sc0tt> Hallski: that's extremely good news
    rodrigo> Hallski: yeah
   jon_kare> As a citizen of country formerly occupied by Nazis, I don't think
             "Achtung" is a good name.
       jody> Hallski: yahoo!
    Hallski> jody: is that good enough?
   jon_kare> Then, I'm older than most people around here.
    ViGueTo> Kenneth: it is very difficult now
        joe> jon_kare: valid point. :)
   chrisime> jon_kare: propose a better name then
        dom> jon_kare: it's also the title of a u2 album :)
       jody> ettore: does dec02 seem feasible for g2 evo ?
    domHome> i really must go
      Sc0tt> domHome: a very nice one btw.
   chrisime> domHome: cu!
         mg> bye dom, catch the train
    Kenneth> joe: it just sounded like a project that we wouldnt see in years
    rodrigo> jon_kare: AFAIk, achtung is just a German word, not something
             related to nazis
     Uraeus> joe: I think Agnubis would be a cool name for the presentation
             program :)
    domHome> hava a great day/night folks
        joe> Kenneth: Probably won't. :)
       jody> as a freeze date
   chrisime> rodrigo: indeed
   chrisime> jon_kare: it means: pay attention
   jon_kare> rodrigo: True, but it carries assoications.
     sander> jon_kare: its just a german word... very common one at that
        joe> Uraeus: I think "Anubis" is a pretty cool name. :)
    Kenneth> I do not think any danes have any problem with the Achtung name
       mawa> jon_kare: not really. it just means "attention"
       jody> any of the spanish presentation folk here ?
   chrisime> jon_kare: nonsense
    rodrigo> jon_kare: *you* carry associations :-)
        ---> Sc0tt is having trouble following jody!
    Kenneth> most people thing about U2 when they here it
        joe> I think if anyone ever writes another g-named application, I will
             rip their head off. :)
   chrisime> i'm using it all the time. am i a nazi now. jon_kare ?
    ViGueTo> I´m agree with rodrigo in that name
     Uraeus> joe: well my name was a wordplay on Anubis and gnu so naturally I
             agree :)
     ettore> jody: we'll likely be in beta at that point
     sander> Kenneth: laugh, yes, that is probably the usual case 
       mawa> joe: you can never have enough g-named applications
    ViGueTo> jody: Me
     ettore> joe: what is gibbon?
    ViGueTo> hey 
    ViGueTo> I like anubis
    ViGueTo> I like agnubis
     ettore> jody: I am not totally sure though, the plan isn't finished
        joe> ettore: it's a presentation program some spanish hackers are
             working on
   chrisime> ViGueTo: what does it mean
    Kenneth> ViGueTo: how mature is gibbon?
     Uraeus> having G as the first letter is banned from new apps, the index is
             already swamped under G
     ettore> joe: any webpage?
    ViGueTo> Kenneth: It´s green
    ViGueTo> very alpha
        joe> The bottom line guys is this: I don't get paid to hack on Achtung,
             and so I don't really have any time to hack on it.
    ViGueTo> but I hope have a stable releasse soon
    rodrigo> there isn't even code for gibbon in CVS :-(
      Sc0tt> Uraeus: bah, GA GB, ... GZ :)
    Kenneth> ok, is there any website or information resource
    ViGueTo> Kenneth: nop, I´m only developing
    rodrigo> ViGueTo: do you? where is that code?
      Sc0tt> jody: we're out of luck, please do continue anyway.
    ViGueTo> Ariel Rios and Joaquin cuenca like help us
       jody> joe : you should ship ViGueTo a snap of the current achtung code
        joe> jody: I already have
       jody> great
    danmorg> what is actung?
        joe> danmorg: presentation vaporware
    rodrigo> danmorg: a presentation program
    Kenneth> danmorg a presentation program
        hub> PowerPoint
        ---> hub hides 
    rodrigo> joe: :-)
    danmorg> ok. thanks
        ---> mg fwaps hub
     ettore> I think a presentation program should be somewhat based on sodipodi
    Kenneth> OutOfPowerPoint
    ViGueTo> I will use all my free time for develop in the presentation program
     ettore> which has all the primitives done and stuff
      Conan> how good is open office's presentation program?
    ViGueTo> whatever its name
    Kenneth> it is pretty nice
    ViGueTo> :)
    rodrigo> Conan: seems good, from what I've used it
       jody> ettore: I thing the core drawing element should be the shared
             drawing layer proposed earlier
        joe> ettore: it would require a fork of sodipodi, though
      Sc0tt> Conan: aproximately as bad as the rest.
        hub> and it should offer a text outliner
    rodrigo> ViGueTo: do you have gibbon's code somewhere?
     ettore> joe: or a split in sodipodi itself...
     ettore> jody: yeah
    ViGueTo> rodrigo: yes
       jody> ettore: that means that we're leaning towards dia rather than
             sodiposi
    rodrigo> ViGueTo: where?
     ettore> jody: hmmm
     ettore> jody: why dia?
    ViGueTo> I have some code in mi machine
        joe> ettore: Sure, but I think lauris has opposed that idea previously
     ettore> jody: sodipodi has more features
    rodrigo> ViGueTo: please commit to CVS
     ettore> joe: grrr
     ettore> joe: why?
      Conan> since I miss the guadec talk: how is the plans of porting open
             offcie to gtk?
    ViGueTo> rodrigo: I have to organize much code,
    Kenneth> Conan, forget about it
    ViGueTo> but I will commit to cvs
        hub> Conan: void NULL
    ViGueTo> in this or next week
    rodrigo> ViGueTo: cool
       jody> Conan: there are no plans to do that in the foreseeable future
        hub> Conan: code comes form /dev/zero and output of cc sent to /dev/null
        joe> ettore: I don't recall all the reasons, it's on gnome-devel-list
             somewhere, but he didn't like the idea of splitting out all of
             the code into a library.  Performance/ease of split reasons, I
             think
      Conan> hmmm - to bad. Makes gnome-office even more important then...
    Kenneth> Conan, they are not doing it, but if people do it for them, then
             ok....but who wants to
    ViGueTo> rodrigo: I wiil change of job, and I´m stressed
       jody> ettore: true, it is also svg based which is nice
     ettore> jody: yeah
    ViGueTo> rodrigo: I wiil do to andago :)
    ViGueTo> s/do/go
     ettore> anyway, I wouldn't mind a fork of sodipodi either ;)
       jody> ettore: but its use of the AA canvas decimates performance for
             things like gnumeric and abi
     ettore> (if lauris totally opposes that is)
       jody> lauris is a bit out of commision for now
     ettore> jody: hmm well, it's a different kind of application thougyh
      Sc0tt> jody: sodipodi is quite better than dia, from my experience.
             However, I do have an old version of dia, so I may be being
             unfair.
         mg> What end user ramifications could come of picking dia or sodi over
             the other?
       jody> mg : unknown
      Sc0tt> jody: OTOH, dia has connector's a separate canvas etc..
       plam> It depends on what you need to do.  Dia seems better for the
             diagrams I need than sodipodi.
      Sc0tt> jody: so if I'd cast a vote, I'd vote on dia too.
       jody> My current preference for dia is based on 3 considerations
       plam> For instance connection points are useful.
         mg> For my experience as a user, sodi took a bit of getting used to. 
             Dunno bout others
       jody> 1) already has a nice mocel view split
       jody> 2) Maps nicely to the MS Office perspective of objects in an
             escher stream
       jody> 3) does not require an AA canvas
      Sc0tt> jody: and we need something now, and not in some uncertain future.
        hub> I have seen lot of people using PowerPoint to make diagrams....
        hub> because they did not have Visio
        hub> :-/
         mg> hub: no.  it uses embedded other ms app
       jody> hub: I've seen people draw the diagrams in XL and paste them into
             power point
         mg> hub: or have i misunderstood?
        hub> I think that we should more concentrate on embeding drawings than
             making canvas
    rodrigo> jody: and how hard is it to librarify dia?
        hub> rodrigo: diacanvas do exists
       jody> hub: the 2 concepts are intertwined
      paolo> I cannot still understand why diacanvas2 cannot be a solution
    rodrigo> hub: where?
       jody> paolo: it is the start of a solution
    Kenneth> dia2canvas has nothing to do with the real dia right? I think I
             read that
      paolo> hub: Note that DiaCanvas is not related to the diagramming tool
             DIA, except for its look and feel.
         mg> jody: what ever happened to it being a long term goal?
      Sc0tt> hub: you can get embedded drawings with a shared canvas
        hub> Sc0tt: don't know
       jody> mg : it is a long term goal, in that I doubt anyone here has the
             time to work on this now
      Sc0tt> hub: direct support from the renderer.
    Kenneth> paolo, have you played around with it
    rodrigo> oh, you mean diacanvas2
      Sc0tt> doesn't cvs dia use diacanvas?
    Kenneth> not diacanvas2
    Kenneth> that is unrelated
        joe> all this dia stuff is really confusing
      paolo> Kenneth: no, but it is already librified and already use glib/gtk 2
    Kenneth> http://diacanvas.sourceforge.net
    Kenneth> true
         mg> jody: what in your personal belief should be priority over the
             next 4 mos.?
       jody> mg : I'd like to see a couple of small central shared pieces of
             code develop
       jody> 1) a shared i/o mechanism
       jody> eg structured files , and type sniffing
       jody> 2) shared view of plugins and what they can provide
       jody> This is basicly a poormans bonobo
       jody> but because they rely on simple well understood packaging
             techniques
    rodrigo> :-)
       jody> we can focus on getting the interfaces right
    danmorg> type sniffing == run time type information?
   jon_kare> Document type sniffing
   jon_kare> RTTI is about code
       jody> rather then concentrating on getting out of process components
             running on a mainframe behind a firewall to display locally
    rodrigo> danmorg: mime types
    danmorg> ok
         mg> jody: and in the second half of the period before dec02 (if you
             noticed the split)?
       jody> mg : making stuff work again :-)
   jon_kare> jody: Functionality which is turned off for security reasons
             anyway.
       jody> mg: making changes at this level will definitely break things
       jody> it will take us several months to put them back together
         mg> jody: So interoperability is not going to be there even at
             statistical signifigance by 1.0?
       jody> mg : depends on what we mean by 'interoperability'
         mg> (like, deep, office-ish)
       jody> If we can provide a consistent plugin manager
       jody> that would be a big step
       jody> To actually embed things
         mg> like gibbon could take a chart from gnumeric which uses guppi or
             something (powerpoint from ms chart)
         mg> That's true.
       jody> does not seem feasible in the short term
         mg> Right.
       jody> longer term we should experiment with it
    rodrigo> yeah, a libgnomeofficeui lib with some UI-oriented services would
             be nice
       jody> but the ability to embed a window is the least of it.
         mg> So 1.0 == starting point of holding together this collection of
             apps by _something_
       jody> I learned this the hard way with gnumeric 1.0
       jody> People make claims about embedding one thing in another
       jody> being very useful with very narrow interfaces
       jody> but thus far I've always been bitten
       jody> The amount of interface tended to grow
       jody> eg embedding an image
       jody> via eog required agreement on what formats will be supported
      mgBBS> jody: I think I see where you're getting at.
       jody> and what properties are available to manipulate the image
       jody> eg cropping, gamma ...
       jody> Something like guppi gets much harder very quickly
        ---> trow nods in agreement
       jody> You actualyl want to pass data bi-directionally
    gabriel> jody: it truly is a very complex thing to attack
       jody> and all hell breaks loose.
       jody> gabriel: exactly.  Which is why I'd rather focus on the simpler
             things first.
       jody> ideally we could use some of the galeon code to support window
             embedding at some point
       jody> but to date gnome office apps have focused on actually
             implementing the functionality they claim to have
       jody> I don't see any reason to offer some cut down 1/2 implemented
             embedding
             ... a bunch of people sign off...
       jody> Shall we adjourn ?
    rodrigo> it's ok for me, more detailed discussion should be in the list
      Sc0tt> I don't know... only if for next tuesday.... probably.
      Sc0tt> jody: but this has been a rehash from what you've been talking,
             mostly. I was expecting some more concrete discussion.
  trow_away> I'll post an edited transcript of the meeting to the list tonight.
      Sc0tt> jody: I am going to read diacanvas2 documentation. I have a friend
             who's getting married this weekend, so it will be a perfect place
             (during the wedding rites) to read the documentation.
        hub> trow_away: good idea
       jody> Sc0tt: any particular decisions you'd like to see ?
      Sc0tt> jody: diacanvas or sodipodi. i agree with diacanvas
       jody> as things stand we are basicly resource constrained
      Sc0tt> jody: that's more or less definite, but nothing mostly decided.
       jody> I'd like to get libgsf in place
       jody> (gnome-structured-file)
      Sc0tt> jody: get that into cvs, come on :)
       jody> and flesh out libgnomeoffice so that gnumeric can use it
      Sc0tt> could you repeat that please?
      Sc0tt> jody: I cleared the screen too fast (happens a lot) <:)
       jody> Sc0tt: not until it compiles arnd reads all of my xls files
    rodrigo> jody: I'll add pkg-config files to libgnomeoffice right now, so
             you can use it
    rodrigo> jody: in gnumeric
      Sc0tt> jody: bah.
       jody> The little guy wantsto play, so it is time to go.
             ...at this point things basicaly fizzled out...