[c/gtk/xml] nieuw project

[Verwijderd]

Hoihoi

Ik wil een app voor mensen met functionele beperking maken waarmee dmv een paar muis kliks een standaard zin kan produceren.

De interface zal vrij simpel eruit te komen zien met NxM knoppen waarmee een gebruiker een hoofdcategorie kan kiezen en dan verder kan klikken naar sub categorie kan kiezen totdat er een zin op het scherm te voorschijn komt. Een zin bevat een hoofddcat--->subcat--->subsubcat-->subsubcat-> zin etc De interface zal waarschijnlijk gtk worden omdat het in de eerste instantie op een linux-omgeving gedraaid moot worden.

Categorien/sub categorieren/ zinnen kunnen door gebruikers gemaakt/gewijzigd en verwijderd kunnen worden.

Het zal op een blader-systeem lijken zoals pos systemen die ze bij kassa's gebruiken, alleen dan met een andere doeleinden.

Op dit moment ben ik een beetje aan het zoeken hoe, waarmee ik dit kan gaan doen. Omdat de gebruiker de zinnen moet kunnen verwijderen dacht ik aan xml. Het gui-gedeelte zal niet al te lastig zijn, maar ik zit een beetje met die tree/xml gedeelte waar ik nog nooit mee gewerkt heb. Ik heb wel gezien dat met libxml veel mogelijk is. Dus vandaar deze post. Suggesties / ideeen zijn welkom.

Groetjes.

[flashin]

Waarom zou je dit niet webbased doen?
Is volgens mij gewoon de snelste manier om dit neer te zetten en je kunt er visueel veel leukere dingen mee.

[Woy]

Dit is meer een design vraag en past dus beter in SEA.

Maar op zich lijkt me het probleem vrij eenvoudig

Lijkt me zo ongeveer wat je wilt.
Dit is zowel in een (Embedded)database als een XML of een flat text file of als een binary file op te slaan.

Dus misschien heb je een wat concretere vraag? Want op deze manier is het wel een erg ruime vraag.

[whoami]

flashin schreef op dinsdag 14 juli 2009 @ 22:49:
Waarom zou je dit niet webbased doen?
Is volgens mij gewoon de snelste manier om dit neer te zetten en je kunt er visueel veel leukere dingen mee.

Alsof dat dit het enige criterium is om te beslissen om iets web-based of niet te doen ?
Trouwens, welke dingen (op ui gebied) zou je 'webbased' kunnen doen, dat je met een rich client niet kan ?

[Woy]

Het lijkt me idd dat je juist met een Rich client visueel veel leukere dingen kunt doen. Je hebt immers beschikking over de complete hardware van de PC, eventueel kun je er zelfs een website in embedden. Dus je kunt minstens wat je ook met een web-based client kunt doen.

[Stoffel]

flashin schreef op dinsdag 14 juli 2009 @ 22:49:
Waarom zou je dit niet webbased doen?
Is volgens mij gewoon de snelste manier om dit neer te zetten en je kunt er visueel veel leukere dingen mee.

Grappig hoe echt alles tegenwoordig in een webomgeving gegooid moet worden, ook als dat om geen enkele reden de beste oplossing oplevert. No offense voor jou verder, maar het valt me op dat mensen tegenwoordig echt niet meer verder kijken dan dat.

offtopic:
Beetje offtopic, maar het gaat zelfs zover dat mensen zich in allerlei bochten gaan wringen om in een browser een rich client look en feel te krijgen, terwijl een heel groot voordeel van webbased applicaties, namelijk geen gedoe met deployment op alle clients, tegenwoordig perfect mogelijk is met rich client applicaties. Imo is de huidge webbased techniek gewoon zwaar verouderd. Het concept van applicaties die online worden gedraaid is dat zeker niet, maar html/js/css is echt niet meer afdoende voor wat er tegenwoordig gedaan mee moet worden. Zelfs met Ajax trouwens, het is gewoon niet stabiel, betrouwbaar en efficient genoeg. Ik vind het dan ook jammer dat er niet meer gebruik wordt gemaakt van de steeds krachtiger wordende clients.

[Bjornski]

Als je C goed beheerst, dan lijkt me de combinatie C en GTK prima.

Mocht je C niet zo goed beheersen, dan zou ik voor een wat meer high-level aanpak kiezen (specifiek: C# op Mono of Python). Dat ontwikkeld sneller.

Het gebruik van XML vind ik vreemd. Je krijgt nogal wat categorieën met subs en nog meer subs. Daarbij kan ik me voorstellen dat eenzelfde sub onder meerdere ouders kan voorkomen.
XML is minder geschikt om hele grote hoeveelheden data op te slaan. Veel XML betekent veel geheugen in gebruik (tenzij je parset met SAX, maar dat lijkt me niet ideaal in dit geval) en xpath queries worden traag.

Schrijven in XML kost ook een hoop tijd omdat (tenzij je SAX gebruikt) het hele XML document na een wijziging moet worden weggeschreven.

Kijk eens naar een referentiële database. MySQL lijkt me prima en mocht het niet zoveel data zijn, dan is SQLite ook zeker prima. Beiden zijn simpel in het gebruik. Voor SQLite hoef je geen aparte daemon te draaien. MySQL performt beter en kan referentiële integriteit afdwingen.

[!null]

Eens met Stoffel, alles in de browser doen, bleh

Verder, voor de database, dat kan van alles zijn. XML is erg leuk, maar als je niet eens gebruik wil maken van de flexibiliteit in structuur ervan kan je ook andere dingen gebruiken. SQLite werkt ideaal voor lokale dingen, en kun je gewoon lekker simpel SQL doen.
(en met SQLite kan je ook op de commandline lueke dingen doen, wel handig, zeker tijdens ontwikkelen)

Edit: al gezegd zie ik

[ Voor 16% gewijzigd door !null op 15-07-2009 10:53 ]

[Woy]

Bjornski schreef op woensdag 15 juli 2009 @ 10:48:
Als je C goed beheerst, dan lijkt me de combinatie C en GTK prima.

Mocht je C niet zo goed beheersen, dan zou ik voor een wat meer high-level aanpak kiezen (specifiek: C# op Mono of Python). Dat ontwikkeld sneller.

Laten we niet weer de discussie beginnen welke taal er het meest geschikt is. Daar komt toch niks uit, en er is al genoeg ( vrij zinloze IMHO ) informatie over te vinden op GoT en de rest van internet

Het gebruik van XML vind ik vreemd. Je krijgt nogal wat categorieën met subs en nog meer subs. Daarbij kan ik me voorstellen dat eenzelfde sub onder meerdere ouders kan voorkomen.
XML is minder geschikt om hele grote hoeveelheden data op te slaan. Veel XML betekent veel geheugen in gebruik (tenzij je parset met SAX, maar dat lijkt me niet ideaal in dit geval) en xpath queries worden traag.

Schrijven in XML kost ook een hoop tijd omdat (tenzij je SAX gebruikt) het hele XML document na een wijziging moet worden weggeschreven.

Dat je XML als storage gebruikt zegt natuurlijk niks over het geheuge gebruik! Je laad de XML in en zet het dan toch in een Data container die voldoet aan je eisen.

Kijk eens naar een referentiële database. MySQL lijkt me prima en mocht het niet zoveel data zijn, dan is SQLite ook zeker prima. Beiden zijn simpel in het gebruik. Voor SQLite hoef je geen aparte daemon te draaien. MySQL performt beter en kan referentiële integriteit afdwingen.

Ik zou niet zo snel naar MySQL grijpen als je gewoon controle hebt over welke software er op de machines komt. Maar welke manier van storage je gaat gebruiken is grotendeels afhankelijk van je eisen van je systeem. Als het een simpel systeem is dan heb je grote kans dat je al af kan met een simpele serialisatie naar een binair bestand.

[Verwijderd]

Dank voor de reacties.

Ik heb er wel aan gedacht om het webbased te gaan doen, omdat ik zeer weinig c-knowledge heb. Dank voor de reacties. Webbased is vrij snel neer te zetten is en omdat het visueel aspect niet belangrijk is. Daarnaast is het vrij simpel aan te passen voor elke beperking (denk aan sneltoetsen, kleurschema, scanopties), want daar ontbreekt het weleens aan bij software voor mensen met een beperking. Maken ze een standaard software pakket voor een standaard beperking. Klopt toch niet
Nadelen van webbased zijn dat je een webserver lokaalmoet draaien en ik twijfel aan de snelheid. Maar goed, het is mogelijk met wamps

Woy schreef op woensdag 15 juli 2009 @ 10:55:
[...]

Ik zou niet zo snel naar MySQL grijpen als je gewoon controle hebt over welke software er op de machines komt. Maar welke manier van storage je gaat gebruiken is grotendeels afhankelijk van je eisen van je systeem. Als het een simpel systeem is dan heb je grote kans dat je al af kan met een simpele serialisatie naar een binair bestand.
[...]

Zou jij voor boomstructuren ook voor serialisatie gaan?

[Skinkie]

Hoi Eric


Waar je ook nog naar zou kunnen kijken, en het direct embedded maakt is de combinatie van http://www.clutter-project.org/ en een database backend. Clutter zorgt voor je grafische meuk en eventueel betere animaties, zodat je eventueel zelfs eens Dasher achtige toepassing kunt maken door daadwerkelijk in 3D in te zoomen op een knop.

[Verwijderd]

Ik heb gezocht je het beste trees kan opslaan en ik kwam het volgende tegen.

code:

id||parent||title||buttonname||phrase
0,0,hulp,hulp,bla
1,hulp,drank,drank,bla
2,hulp,eten,eten,bla
2,drank,bier,bier,Mag ik een biertje?

Ik vraag me af of het niet beter is om parent vervangen door tak, dan krijg je zo iets:

code:

id||tak||title||buttonname||phrase
0,/0/,hulp,hulp,bla
1,/0/hulp/drank,drank,drank,bla
2,/0/hulp/eten,eten,eten,bla
2,/0/hulp/drank/bier,bier,bier,Mag ik een biertje?

Zou je de 2de situatie een betere zijn om de boom op te slaan? Dan zou ik eventueel gebruik kunnen maken van reguliere expressies om gemakkelijker/sneller de bijbehorende nodes te zoeken.