[bonobo] zelf component maken

[Verwijderd]

Ik heb een tijd geleden een GStreamer/linux/Gnome based applicatie geschreven om video/audio op te nemen. GStreamer is het multimedia framework van Gnome/linux, Gnome is de GUI. Nou leek het me leuk om gebruik te gaan maken van het Gnome object model, bonobo, en op die manier op termijn te kunnen worden toegevoegd aan andere programma's (als component), bv. gnonlin (een non-lineair video editor) e.d. Dus, ik wil een component worden!



Dat is de applicatie in de simpelste mode. Je hebt een video widget (grijs, omdat ik geen TV-kaart in de laptop heb), een control scherm (video image, audio volume, video kanaal, etc.) en een preferences scherm (video size, audio rate/bitsize, audio/video device, audio/video codec, etc.).

Okee, nu de vraag: hoe ga ik dit componentizeren? Logischerwijs moet de TV widget een component worden, met "record", "pause" en "stop" als drie actions/states, de timing statistieken als signal. Maar dan? Moet ik het control scherm een component maken? Of moet ik de objecten daarin (video image, audio volume, video channel) componenten maken? Of moet ik dit alles property van het TV scherm (de hoofdcomponent) maken? En wat doe ik met het preferences scherm? Property? Component? Iets anders?

Wat ook belangrijk is, wie is er verantwoordelijk voor het opslaan van de settings (via GConf, soort van registry - denk aan "welk video device" etc.)? De applicatie? Of de component zelf?

Ik ben compleet niet thuis in de componentenwereld en heb dus geen idee hoe dit normaal gebeurd. Het doel is dat andere multimedia applicaties a la gnonlin een recorder kunnen aanroepen zonder die zelf te hoeven programmeren. Binnen dat kader wil ik zo goed als mogelijk in de applicatie integreren. Wat dat betreft zou het dus onlogisch zijn om een eigen preferences scherm aan te houden, maar ja - wat doe je dan?

Oftewel, wat is "normaal" in de componentenwereld?

[Verwijderd]

Ik heb zelf slechts heel even mij beziggehouden met bonobo componenten. Ik vond het een beetje te moeilijk voor mij Misschien ga ik er later nog eens mee verder spelen. Op de developer website van GNOME zijn wel een aantal pointers te vinden volgens mij. Wat ik ook deed is bijvoorbeeld gewoon de broncode van een applicatie bekijken die deze technieken gebruikt. GEdit bijvoorbeeld.

[ Voor 1% gewijzigd door Verwijderd op 01-03-2003 11:26 . Reden: typo ]

[odysseus]

Verwijderd schreef op 01 March 2003 @ 11:13:
Ik ben compleet niet thuis in de componentenwereld en heb dus geen idee hoe dit normaal gebeurd. Het doel is dat andere multimedia applicaties a la gnonlin een recorder kunnen aanroepen zonder die zelf te hoeven programmeren. Binnen dat kader wil ik zo goed als mogelijk in de applicatie integreren. Wat dat betreft zou het dus onlogisch zijn om een eigen preferences scherm aan te houden, maar ja - wat doe je dan?

Oftewel, wat is "normaal" in de componentenwereld?

Zelf ben ik hier ook geen expert in, maar het lijkt mij handig om je preferences-scherm wel beschikbaar te maken, maar dan niet binnen je eigen widgets maar binnen de parent. De parent kan dan zelf beslissen wat er moet gebeuren:
• Parent maakt menuoptie aan om in preferences-scherm van component te komen (dat zie je vaak bij Office-suites: als je een plaatje of tabel selecteert dan krijg je veranderde of extra werkbalken)
• Parent maakt helemaal geen instellingen beschikbaar voor het component (zo gaat het min of meer bij de embedded media player in KDE)
• Parent geeft aan dat de client binnen zijn eigen scherm een preferences-knop moet plaatsen

Die laatste optie is niet per se nodig. Als je programma echter vaak van instelling veranderd moet worden, dan zou je ervoor kunnen kiezen om standaard een eigen preferences-button te hebben en die door de parent uitschakelbaar te laten maken. Hoe dat precies werkt binnen Bonobo weet ik niet, maar ik neem aan dat er allerlei nette communicatiemechanismen gebruikt kunnen worden om zoiets te regelen .

[Verwijderd]

odysseus schreef op 01 March 2003 @ 11:47:
Zelf ben ik hier ook geen expert in, maar het lijkt mij handig om je preferences-scherm wel beschikbaar te maken, maar dan niet binnen je eigen widgets maar binnen de parent. De parent kan dan zelf beslissen wat er moet gebeuren:
• Parent maakt menuoptie aan om in preferences-scherm van component te komen (dat zie je vaak bij Office-suites: als je een plaatje of tabel selecteert dan krijg je veranderde of extra werkbalken)

Hm, okee... Dan zou het dus eigenlijk (voor de simpelheid) geen widgets/component maar property moeten worden? .

• Parent maakt helemaal geen instellingen beschikbaar voor het component (zo gaat het min of meer bij de embedded media player in KDE)

Geen optie. . Overigens, voor een mediaplayer is dat mogelijk (die heeft alleen drie events nodig, play/pause/stop, evt. nog screen resize, maar dingen als playlist etc. heb je niet nodig in dit soort embedded interfaces). Echter, voor een recorder... In welk formaat record je? Hoe groot moet de video zijn? Welke bitrate? Etc. .

• Parent geeft aan dat de client binnen zijn eigen scherm een preferences-knop moet plaatsen

Hmm... Bevordert dat de integratie?

Ik ben d'r nog niet helemaal uit... Irritant allemaal. Ik zal alvast aan de TV widget beginnen, dan doe ik tenminste iets zinnigs.

[AlterEgo]

Verwijderd schreef op 02 March 2003 @ 10:54:
[...]
Geen optie. . Overigens, voor een mediaplayer is dat mogelijk (die heeft alleen drie events nodig, play/pause/stop, evt. nog screen resize, maar dingen als playlist etc. heb je niet nodig in dit soort embedded interfaces). Echter, voor een recorder... In welk formaat record je? Hoe groot moet de video zijn? Welke bitrate? Etc. .

Is dat zo? Ik zat te denken aan een applicatie, en in die applicatie zet je je preferences, zoveel als je zelf wil. Wanneer je je component aanroept, neemt ie de .prefs over van je applicatie.

Ik heb een (hardware) foto/video cam die volgens dat principe werkt: weinig knoppies en veel opties, vooraf in te stellen per PC.

[Verwijderd]

Mjah, ik weet niet... Het is erg irritant als je op record drukt en er een 192x144 movie uitkomt terwijl je full-PAL wilde ("waar stel ik dat in?").

[odysseus]

Dan zou ik ervoor kiezen om standaard je eigen knop 'preferences' te laten zien, die je naar een preferences-scherm brengt. Je biedt daarnaast een publieke functie showPreferencesButton(b) aan die de parent de mogelijkheid biedt om jouw eigen button uit te zetten. Die parent kan dan zelf een eigen button/menuoptie aanmaken die bij jou een functie showPreferencesDialog() aanroept. Op die manier biedt je genoeg flexibiliteit en kan toch iedereen in principe bij de instellingen, tenzij de parent dat om een of andere reden echt niet wil .

[CyBeR]

odysseus schreef op 02 maart 2003 @ 12:42:
Dan zou ik ervoor kiezen om standaard je eigen knop 'preferences' te laten zien, die je naar een preferences-scherm brengt. Je biedt daarnaast een publieke functie showPreferencesButton(b) aan die de parent de mogelijkheid biedt om jouw eigen button uit te zetten. Die parent kan dan zelf een eigen button/menuoptie aanmaken die bij jou een functie showPreferencesDialog() aanroept. Op die manier biedt je genoeg flexibiliteit en kan toch iedereen in principe bij de instellingen, tenzij de parent dat om een of andere reden echt niet wil .

Het lijkt me dan beter om die button helemaal achterwege te laten en een action te maken die die preferences tevoorschijn tovert.
Scheelt in screenspace en complexiteit.

_{Oh, en camel style zuigt}

[odysseus]

CyBeR schreef op 03 March 2003 @ 09:31:
[...]

Het lijkt me dan beter om die button helemaal achterwege te laten en een action te maken die die preferences tevoorschijn tovert.
Scheelt in screenspace en complexiteit.

En hoe ga je die action dan elke keer aanroepen? Je kunt het wel doen als je component voor de eerste keer geladen wordt, maar als iemand dan een foutje maakt en een instelling besluit te veranderen? Dan kan hij niet meer bij het configuratiescherm. En als de instelling al lang goed staan en hij het programma voor de twintigste keer start, dan hoeft hij niet weer dat scherm te zien...nee, ik zou het scherm gewoon op elk moment beschikbaar maken voor de gebruiker en dat kan alleen op een simpele manier via een button. Waar je die neerzet is een ander verhaal, maar hij zal toch wel ergens moeten komen .

[Creepy]

odysseus schreef op 03 March 2003 @ 10:46:

[...]

En hoe ga je die action dan elke keer aanroepen? .

De app. die jou component gebruikt laat je die toch gewoon aanroepen?? Dan hoef je jezelf niet bezig te houden met een extra button en het wel of niet tonen daarvan. Diegene die jou component embed kan dan zelf ergens een button neerzetten, menu optie aanmaken, whatever.

[odysseus]

Creepy schreef op 03 March 2003 @ 11:09:
De app. die jou component gebruikt laat je die toch gewoon aanroepen?? Dan hoef je jezelf niet bezig te houden met een extra button en het wel of niet tonen daarvan. Diegene die jou component embed kan dan zelf ergens een button neerzetten, menu optie aanmaken, whatever.

Dat noemde ik hierboven ook al als oplossing. Ik kan me echter voorstellen dat zoiets niet altijd werkt. Als je component bijvoorbeeld een parent heeft die geen menubalk heeft (dat soort programma's bestaan), dan kan die niet makkelijk je configuratiescherm beschikbaar maken. In dat soort situaties moet de component naar mijn mening voor zichzelf kunnen zorgen - het is immers gewoon een *werkend* onderdeel dat ergens anders als embedded onderdeel wordt gebruikt...dan moet je niet allerlei eisen gaan stellen aan die parent. Je hoeft natuurlijk niet altijd je button te laten zien, maar ik vind wel dat een component de mogelijkheid moet hebben om zoiets zelf te regelen en dat niet aan de parent over te laten.

[Creepy]

Ok, maar vind je dan ook niet dat er een action moet zijn om alle settings te saven naar een bepaalde lokatie, en een action om die settings weer te kunnen laden?

Overigens lijkt het me sterk dat iemand je component embed en geen ruimte heeft voor een menubalk of een extra knopje.

[ Voor 28% gewijzigd door Creepy op 03-03-2003 12:32 ]

[odysseus]

Creepy schreef op 03 March 2003 @ 12:31:
Ok, maar vind je dan ook niet dat er een action moet zijn om alle settings te saven naar een bepaalde lokatie, en een action om die settings weer te kunnen laden?\

Natuurlijk, maar naar mijn mening moet je er niet op vertrouwen dat de parent dat voor je doet, maar moet je zelf die instellingen laden. Als het even kan dan moet er wel een interface voor die dingen richting de parent zijn, maar dat is een ander verhaal .

Overigens lijkt het me sterk dat iemand je component embed en geen ruimte heeft voor een menubalk of een extra knopje.

Stel je een programma voor als The Gimp, dat meerdere schermen opent voor verschillende taken. Jouw component kan wel één zo'n scherm vormen en dus niet 'fysiek' verbonden zijn met de parent. Als die parent dat component dan ook nog een fullscreen maakt, dan kun je als gebruiker dus niet meer bij de parent en ben je wel gedwongen om de configuratie via de component te regelen .

[CyBeR]

odysseus schreef op 03 March 2003 @ 12:39:

[...]

Natuurlijk, maar naar mijn mening moet je er niet op vertrouwen dat de parent dat voor je doet, maar moet je zelf die instellingen laden. Als het even kan dan moet er wel een interface voor die dingen richting de parent zijn, maar dat is een ander verhaal .


[...]

Stel je een programma voor als The Gimp, dat meerdere schermen opent voor verschillende taken. Jouw component kan wel één zo'n scherm vormen en dus niet 'fysiek' verbonden zijn met de parent. Als die parent dat component dan ook nog een fullscreen maakt, dan kun je als gebruiker dus niet meer bij de parent en ben je wel gedwongen om de configuratie via de component te regelen .

In GIMP HEAD hebben alle image vensters tegenwoordig een menubalk

Maar bij gebrek daaraan in een andere app kan die app bijvoorbeeld ook een soort context menu maken op de component, idem aan het <image> menu van The GIMP.

[Verwijderd]

Op zich ben ik geneigd om naar Cyber en Creepy te luisteren - applicaties die componenten embedden zullen toch echt zelf voor toegevoegde waarde moeten zorgen... Evt. d.m.v. zelf de button in de control plaatsen of rechtermuisknop signal/event.

Bij deze nog even een antwoord van [e-mail]:

code:

On Sex, 2003-02-28 at 12:11, Ronald Bultje wrote:
> Hey,
> 
> I'm doing a GStreamer-based project which should one day become a great
> video recorder app. I want to use layering here, so some parts are
> gstreamer plugins, one part should become a bonobo element as well. Now
> my question is about what people normally make bonobo components.
> Basically, the app can be really small, see
> http://www.gstreamer.net/apps/gst-rec/gst-rec-new.png for a screenshot.
> Possibly bonobo'izeable widgets around here: a tv widget (it's gray
> here, but that's because my laptop doesn't have a TV card), a
> preferences screen (where things like capture format, audio codec, video
> codec, audio and video source settings are located) and a control screen
> (where audio volume, video image (brightness etc.) and video channel can
> be changed).

  As Michael said in this list some time ago, widget-level embedding
with bonobo is not recommended.  For one thing, mnemonic activation of
bonobo widgets doesn't work, as I discovered some time ago.

> 
> The question is, what parts here would normally become bonobo
> components? I could make the preferences screen, control screen and TV
> widget a bonobo component, but is that a wise idea? I could also make
> the TV widget a bonobo component and make everything else properties of
> this component (so that the bonobo client needs to implement all GUI
> stuff for this), or make the widgets inside the control screen bonobo
> components on themselves... What do normal people do here? How far
> should I go here?

  Some people wouldn't call me 'normal', :) but a good a example to look
at would be eog.
  Looking at the screenshot, I would say that everything except the menu
bar, tool bar and status bar should be a single bonobo control.  You
would also export the toolbar items and menu layout in a bonobo ui xml
file (read by the component, not the shell). The preferences dialog too
would be in the component factory, invoked by some menu item.

> 
> (The idea is that other GStreamer applications, like Wim's gnonlin NLE,
> can call gst-rec's video-recording function via bonobo, and maybe
> there's other weird people out there that would want to use gst-rec for
> some weird reason).
> 
> Also, related to this, is it normal for applications that call a
> bonobo-component to keep their own configuration of this component, or
> should the configuration be inside the bonobo component? I.e., should I
> use GConf in the component or in the application part?

  I don't have any strong opinion in this matter, but I would say that
using GConf directly in the component is fine.

> 
> Thanks for any help,
> 
> Ronald
> 
> [please CC me, I'm not subscribed]
-- 
Gustavo João Alves Marques Carneiro
<[e-mail]> <[e-mail]>

Op zich sluit het redelijk aan hierbij - gewoon volle preferences screen exporten als component in dezelfde factory, naast de TV widget component en de control component (voor video image/audio controle). Ik ga binnenkort maar eens wat code afmaken en op internet gooien, screenies komen tegen die tijd ook wel!

[Creepy]

odysseus schreef op 03 maart 2003 @ 12:39:

[...]

Natuurlijk, maar naar mijn mening moet je er niet op vertrouwen dat de parent dat voor je doet, maar moet je zelf die instellingen laden. Als het even kan dan moet er wel een interface voor die dingen richting de parent zijn, maar dat is een ander verhaal .


[...]

Stel je een programma voor als The Gimp, dat meerdere schermen opent voor verschillende taken. Jouw component kan wel één zo'n scherm vormen en dus niet 'fysiek' verbonden zijn met de parent. Als die parent dat component dan ook nog een fullscreen maakt, dan kun je als gebruiker dus niet meer bij de parent en ben je wel gedwongen om de configuratie via de component te regelen .

Om hier nog ff op door te gaan (ja, je laatste post heb ik ok gelezen hoor )

Je hoeft natuurlijk niet de optie om te configuren op dezelfde plek te houden als je widget. Dit zou bijv. ook in het configuratie scherm van The Gimp er bij kunnen (ik noem maar een dwars straat, dat Gimp dat zou niet doet snap ik ook wel ).

En je moet er natuurlijk rekening mee houden dat meerdere applicaties jou component kunnen embedden. Wil je dan dat in alle applicaties dezelfde configuratie word gebruikt, of wil je per app. een verschillende configuratie? (ik ben zelf geneigd om per app. een verschillende configuratie te doen.). En dan heb ik min of meer meteen de vraag gesteld wie de instellingen gaat opslaan, de app. of je component?

[odysseus]

Creepy schreef op 03 maart 2003 @ 14:48:
[...]

Om hier nog ff op door te gaan (ja, je laatste post heb ik ok gelezen hoor )

Je hoeft natuurlijk niet de optie om te configuren op dezelfde plek te houden als je widget. Dit zou bijv. ook in het configuratie scherm van The Gimp er bij kunnen (ik noem maar een dwars straat, dat Gimp dat zou niet doet snap ik ook wel ).

Volgens mij noemde ik die optie al in mijn eerste post in dit topic :P:

• Parent maakt menuoptie aan om in preferences-scherm van component te komen (dat zie je vaak bij Office-suites: als je een plaatje of tabel selecteert dan krijg je veranderde of extra werkbalken)

En je moet er natuurlijk rekening mee houden dat meerdere applicaties jou component kunnen embedden. Wil je dan dat in alle applicaties dezelfde configuratie word gebruikt, of wil je per app. een verschillende configuratie? (ik ben zelf geneigd om per app. een verschillende configuratie te doen.). En dan heb ik min of meer meteen de vraag gesteld wie de instellingen gaat opslaan, de app. of je component?

Daar heb je wel een punt. Naar mijn mening hoeft een applicatie bijna helemaal niets te weten van de componenten die hij embed. Als ik even KDE als voorbeeld neem: het moet niet zo zijn dat je Konqueror moet aanpassen om een nieuw KPart voor het afspelen van MP3's te kunnen gebruiken. Konqueror moet gewoon zien dat er een bestand met mimetype audio/x-mp3 aanwezig is en dan gaan zoeken naar een component of extern programma dat zoiets kan afspelen. Op welke manier het dan wordt afgespeeld, dat is volledig aan de gekozen component. Dat betekent dat zo'n component, als hij instellingen beschikbaar wil/moet maken, dat zelf moet regelen. Op welke manier dat gebeurt is niet erg belangrijk, maar er zijn maar twee opties: binnen de component zelf of binnen de parent. Ik pleit er alleen voor dat je, omdat je er niet zeker van mag zijn dat de parent de mogelijkheid tot configuratie biedt, je ook binnen de component een configuratiemogelijkheid moet scheppen.

In een verder stadium kun je er dan voor kiezen om je configuratie ook via een interface door externe programma's mogelijk te maken. Als je eenmaal zover bent, dan kan de parent de configuratiemogelijkheid van de component uitschakelen en zelf iets aanbieden. Dat slaat hij dan op en geeft het via de interface door aan de component, die die instellingen vervolgens gebruikt als 'override' van zijn standaardinstellingen. Op die manier heb je het beste van twee werelden: je programmaonderdelen hoeven geen weet van elkaars werking te hebben en alleen via een standaard (Bonobo-gebaseerde) interface met elkaar te communiceren - dat is echte modulariteit. Tegelijkertijd is ook integratie mogelijk (niet verplicht!), door het instellen van de componenten aan de parent over te laten.

* odysseus vindt dit best een interessant onderwerp .

offtopic:
Dit herinnert me weer aan een vraag die ik heel lang geleden als net-beginnende gebruiker aan de KOffice-developers stelde...zie hier. Leuk om weer terug te lezen, inclusief verontschuldiging voor toen nog brak Engels .

[Creepy]

odysseus schreef op 03 March 2003 @ 15:08:
[nohtml]
[...]

Volgens mij noemde ik die optie al in mijn eerste post in dit topic :P:

[...]

[...]
[/nohtml]
Daar heb je wel een punt. Naar mijn mening hoeft een applicatie bijna helemaal niets te weten van de componenten die hij embed. Als ik even KDE als voorbeeld neem: het moet niet zo zijn dat je Konqueror moet aanpassen om een nieuw KPart voor het afspelen van MP3's te kunnen gebruiken. Konqueror moet gewoon zien dat er een bestand met mimetype audio/x-mp3 aanwezig is en dan gaan zoeken naar een component of extern programma dat zoiets kan afspelen. Op welke manier het dan wordt afgespeeld, dat is volledig aan de gekozen component. Dat betekent dat zo'n component, als hij instellingen beschikbaar wil/moet maken, dat zelf moet regelen. Op welke manier dat gebeurt is niet erg belangrijk, maar er zijn maar twee opties: binnen de component zelf of binnen de parent. Ik pleit er alleen voor dat je, omdat je er niet zeker van mag zijn dat de parent de mogelijkheid tot configuratie biedt, je ook binnen de component een configuratiemogelijkheid moet scheppen.

Ben ik met je eens ja.. alleen kan dat technisch gezien nog leuk worden als je component geen weet door welke parent hij wordt wordt gebruikt. Waar word dan de configuratie opgeslagen? (dus weer mijn vraag of dat éénmalig of per parent word)

In een verder stadium kun je er dan voor kiezen om je configuratie ook via een interface door externe programma's mogelijk te maken. Als je eenmaal zover bent, dan kan de parent de configuratiemogelijkheid van de component uitschakelen en zelf iets aanbieden. Dat slaat hij dan op en geeft het via de interface door aan de component, die die instellingen vervolgens gebruikt als 'override' van zijn standaardinstellingen. Op die manier heb je het beste van twee werelden: je programmaonderdelen hoeven geen weet van elkaars werking te hebben en alleen via een standaard (Bonobo-gebaseerde) interface met elkaar te communiceren - dat is echte modulariteit. Tegelijkertijd is ook integratie mogelijk (niet verplicht!), door het instellen van de componenten aan de parent over te laten.

* odysseus vindt dit best een interessant onderwerp .

offtopic:

Ik ook En jou oplossing is inderdaad het beste van twee werelden, alleen technisch moet je meer moeite doen om het te implementeren

[ Voor 4% gewijzigd door Creepy op 03-03-2003 15:17 ]

[Verwijderd]

Volgens gnome-components-list@.. is het ook toelaatbaar om de configuratie binnen de component af te handelen. Ik zie Creepy's punt wel dat dit niet echt mooi is als de parent het per se zelf wil doen (dit geldt overigens ook voor het embedden van mijn configuratie opties in z'n eigen configuratiescherm - hij moet niet aan mijn aparte config scherm vastzitten). Je moet hier een soort evenwicht tussen vinden, naar gelang de vraag naar flexibiliteit die er bij andere ontwikkelaars die deze component willen gebruiken.

Voorlopig zal de configuratie w.m.b. volledig in de component worden ge-embed, dat is namelijk een stuk makkelijker om te coden. Later kan het dan alsnog geavanceerder worden gedaan. . Wat ook vrij gebruikelijk is, is dat je de componentconfiguratie als default neemt en dan per applicatie de mogelijkheid geeft om hier per optie vanaf te wijken, of de default te blijven gebruiken. Net zoals een user de systeemconfiguratie als default krijgt en die per user apart per optie kan bijstellen in zijn eigen userdir config-space.

[doh] Oh, dit schreef odysseus ook net [/doh] .

[odysseus]

Creepy schreef op 03 maart 2003 @ 15:16:
Ik ook En jou oplossing is inderdaad het beste van twee werelden, alleen technisch moet je meer moeite doen om het te implementeren

Verwijderd schreef op 03 maart 2003 @ 15:22:
[doh] Oh, dit schreef odysseus ook net [/doh] .

Volgens mij zijn we het zowaar eens ondertussen .

[ajvdvegt]

Ik programmeer (als bijbaan) in Delphi, en daar werken we ook vrij veel met componenten. Nu snap ik dat een Delphi omgeving niet helemaal te vergelijken is met een Gnome2 omgeving, maar de principes blijven hetzelfde. Wellicht dat ik iets bruikbaars kan melden....

Creepy schreef op 03 maart 2003 @ 15:16:
[...]

Ben ik met je eens ja.. alleen kan dat technisch gezien nog leuk worden als je component geen weet door welke parent hij wordt wordt gebruikt. Waar word dan de configuratie opgeslagen? (dus weer mijn vraag of dat éénmalig of per parent word)

Het lijkt mij het handigst als het component in 'standaard' modus zelf zijn instellingen regelt (als gnome2 component natuurlijk keurig in de gconf-editor). Daarnaast biedt je interfaces aan om die instellingen op een andere manier op te slaan/te laden. (In Delphi kan je kijken of je interface ('OnSave' bv) is overschreven, en als dat het geval is roep je de OnSave functie van de parent aan, anders je eigen.) Programma's die verder niets van het afspelen van films e.d. afweten (Nautilus bv) gebruiken het component in 'standaard' modus, en het component regelt in zijn eigen instellingen. Iets als FilmGimp overschrijft interfaces als onSave en OnLoad, en geeft zijn eigen opslaan/laden dialoog weer.

In Delphi gebruiken wij zoiets om standaard de instellingen in HKEY_CURRENT_USER op te slaan, en eenmaal in ons programma geintegreerd wordt alles in een database opgeslagen.