Re: defining GNOME Office for developers

> Ok, the last mail was very vague.
> Here i'm trying to set some topics out for discussion, what GO is/should
> be/will be for developers.
> Please note that the points mentioned are mostly based on lurking on
> mailing lists for some time, supplemented by some wild guesses and, of
> course, personal opinions. Furthermore should this only be a suggestion
> which topics do discuss and maybe define later on, it's not the actual
> definition yet! Some things might sound a bit ridiculous, given that GO
> now seems to consist of Abiword, Gnumeric and GDA (Divifund proposed),
> but GO might become bigger once.
> - Is there a common sense of moving GO beyond being an informal
>   communication platform?
> - Is GO in need for more applications? Planner, inkscape ... come to
>   mind.
> - Should we maybe apply some kind of tagging (core, personal,
>   professional, ...) to communicate target audience?
>   Candidates would IMHO be:
>   core:         Abiword, Gnumeric
>   personal:     Divifund, if included
>   professional: Planner maybe?
> - ...
> - GNOME enforces very strict adherence to the HIG for proposed modules.
>   Are we as strict? Would the addition of a text entry to the file
>   selector disqualify an application from inclusion? See inkscape:
> - Release cycle
> - ...
> - Which useful libraries originate in one of the GO apps, what can they
>   do, what is planned for the future. (GDA, enchant, libgsf,
>   libgnomeoffice)
> - What components does GO provide? (e.g. abi's bonobo component)
> - Is an application forced to use certain libraries? GTK+ being pretty
>   obvious, but what about Glade? Can a non-glade app become part of GO?
> - Encourage interop with GO native file formats? (see Divifund)
> - Policy related to Microsoft and ooo file formats?
> - Role of svg?
> - We now have apps written in c, c++.
> - Divifund (python) is proposed, general attitude towards scripting
>   languages?
> - Connection to gnome-language-bindings project, which guarantees the
>   constant quality of a binding?
> - Of course it's easiest to leave this to distributions, but
> - Linux: do we think that evaluating and eventually adopting autopackage
>   ( would make distribution easier?
> - Win32: interest has been mentioned in teaming up with other gtk-based
>   win32 apps to share gtk installations.
> I'm looking forward to hear your opinions!
> Thanks,
> Rob

Hi Rob,
       These are good organisational questions. We have a tension between,
"We want lots of applicatins that work together"


"Having apps that don't meet the required standard just dilutes the brand"

I personally would like to see evolution, *instant messaging*, planner,
inkscape,gimp,a presentation program, *some financial program*, *a page
layout program*, data-base program, *other good productivity programs",
gnome-meeting, beagle-like searching, integrated into a super-duper all
purpose productivity suite.

I want to use the components as needed to create whatever weird document
is required, place it on some sharable whiteboard so my remote colleagues
can look and modify it. Chat to them while we discuss the document. Then
print the thing.

I think that we're actually not that far way from this in principle. We
have an svg backend to gnome-print now. With a bit of work on all our apps
parts we should be able to embed these SVG's in documents. If inkscape
keeps developing as we hope, it may be able to edit the svg produced via

Other people just want a minimalist integration of core apps.

The default solution is to continue to improve our own apps, share code
when ever is possile via libgoffice and integrate via osmosis.

Given the resources we have this second approach makes perfect sense and
is what we're doing.



> Am Mit, den 04.08.2004 schrieb Robert Staudinger um 0:10:
>> Hello,
>> from browsing inkscape's mail archives, especially the thread titled
>> "GNOME HIG" at
>> i got the impression that there might be some uncertainty amongst people
>> (developers) concerning what GO is and what it might become. It seemed
>> to me that there's some reservation because of fears not to "sell their
>> soul (application)" and being forced to use certain libraries and being
>> obliged to restrictions. One point mentioned was cross platform ness.
>> Maybe it would be helpful if we could collect information what being
>> part of GO means for developers, some sort of a manifesto even? This
>> could be published on the upcoming website and help to avoid
>> misinformation and uncertainty.
>> What do you think?
>> Rob
>> _______________________________________________
>> gnome-office-list mailing list
>> gnome-office-list gnome org
> _______________________________________________
> gnome-office-list mailing list
> gnome-office-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]