[Alg] Grafisch programmeren voor het linux OS *

[Oyster]

Momenteel ben ik op zoek naar manieren om een simpele foto slideshow te programmeren. Aangezien ik ook gebruik wil maken van nogal wat randapparatuur heb ik besloten om een lichte Linux versie te installeren (DSL), zodat ik me over een aantal zaken niet druk hoef te maken.

Nu ben ik van plan om het programma in C of java te maken. Alleen rijst mij nu de vraag wanneer ik dit programma kan draaien. Aangezien ik alles lightweighted wil maken probeer ik zo min mogelijk systeem processen te starten. Daarbij eet X een hoop resources. Is het mogelijk om een grafisch programma direct vanuit terminal uit te voeren zonder X te starten? Maw heeft terminal de mogelijkheid om foto's op het scherm te toveren? Of moet ik een X starten om van de window packages gebruik te kunnen maken?

/Edit: Titel dekt de lading niet geheel. Misschien het woord Grafisch toevoegen?

[ Voor 5% gewijzigd door Oyster op 15-11-2006 17:19 ]

[Exirion]

http://tldp.org/HOWTO/Framebuffer-HOWTO-3.html

[Oyster]

Exirion schreef op woensdag 15 november 2006 @ 17:21:
http://tldp.org/HOWTO/Framebuffer-HOWTO-3.html

Thanks voor de link. Dit is al redelijk low-level. Maar als ik nu bijvoorbeeld de JAVA jre in terminal opstart. Kan ik dan ook van de JAVA widgets gebruik maken?

[MBV]

Alle standaard-GUI-dingen maken gebruik van X, daar hebben ze X voor gemaakt. Gnome is bijv. gemaakt om te zorgen dat ze een fatsoenlijke omgeving hadden voor the gimp . Java zal op z'n minst van X de dingen gebruiken, anders zou het niet op een standaard-desktop kunnen werken.

Als je niet al te low-level wilt werken, zou ik zou eens kijken naar de lichtere window-managers, zoals XFCE. Maar erg makkelijk programmeren zal dat niet worden, gok ik. Daar heb je, naar mijn mening, een framework als Qt voor nodig, wat direct wat veel baggage heeft.

Hoe meer low-level, hoe minder overhead

[StephanL]

MBV schreef op woensdag 15 november 2006 @ 18:26:
Alle standaard-GUI-dingen maken gebruik van X, daar hebben ze X voor gemaakt. Gnome is bijv. gemaakt om te zorgen dat ze een fatsoenlijke omgeving hadden voor the gimp . Java zal op z'n minst van X de dingen gebruiken, anders zou het niet op een standaard-desktop kunnen werken.

Als je niet al te low-level wilt werken, zou ik zou eens kijken naar de lichtere window-managers, zoals XFCE. Maar erg makkelijk programmeren zal dat niet worden, gok ik. Daar heb je, naar mijn mening, een framework als Qt voor nodig, wat direct wat veel baggage heeft.

Hoe meer low-level, hoe minder overhead

Ik zou inderdaad juist een framework kiezen zoals bijvoorbeels QT of GTK, dacht ik van Gnome. Zo heb je geen extra framework zoals Java, die weer boven KDE/GNOME draait.

Op werk maken we ook software voor Linux, en dit wordt gemaakt in C++ en QT. Deze software wordt alleen gedraait op KDE.

[MBV]

Ik zou QT aanraden. Je hoeft dat niet perse op KDE te draaien, XFCE ofzo (weinig resources om te draaien) is voldoende. Je hoeft dan alleen de QT library te installeren, dat is best goed te doen qua resources.

[eghie]

Ik persoonlijk zou voor wxWidgets kiezen. Ik heb er nog niet echt veel mee gewerkt, op een paar basis dingen na, maar ik heb al wel de site door gekeken en de documentatie die erbij stond en het boek ook vond ik wel goed.

Hier ook nog een ebook die je daarbij waarschijnlijk wel van pas gaat komen (vooral hoofdstuk 10): Cross-Platform GUI Programming with wxWidgets

[ Voor 31% gewijzigd door eghie op 15-11-2006 19:21 ]

[kenneth]

Qt

Sorry, maar je schrijft het eigenlijk zo, en met die kleine letter t is de naam zoveel stijlvoller

Ik raad het trouwens ook aan. Sommigen zijn bang van een framework omdat er 'zoveel inzit wat je toch nooit gebruikt', maar die 50 features die je wél gebruikt, zijn dan ook gelijk heel goed geimplementeerd, gedebugged, gedocumenteerd en ondersteund. Probeer geen vierkante wielen uit te vinden

offtopic:
Ja dat mag, maar het staat niet zo mooi

[ Voor 5% gewijzigd door kenneth op 15-11-2006 19:56 ]

[MBV]

@eghie: ik heb er een poos geleden ook naar gekeken. Ik heb toen voor Qt gekozen omdat de code leesbaarder is. Je hebt gewoon minder regels nodig om hetzelfde te bereiken, wat zorgt voor minder typovouten. Verder is het vrij snel, zit er meer in (pak-em-beet signal/slot, en wat threading zooi), en is het erg makkelijk te leren.
Ik zou trouwens voor een simpele applicatie de Qt-designer vermijden, omdat die minder makkelijk te beheersen is. Gewoon in je code die 3 knoppen aanmaken werkt uiteindelijk makkelijker, is mijn ervaring .
wxWidgets is vooral handig omdat je er je MS-only-programma's makkelijk mee kan porten, omdat de interface vrijwel compatible is. Dat is dan ook direct het grote nadeel: die interface is onleesbaar

@kenneth: sorry voor de typo, maar op de site staat dat qt, Qt en QT allemaal mag, en dat je het cute en cue-tee mag noemen. Alhoewel cute in dezelfde categorie valt als my-siequell ipv my-es-qu-ell

[Oyster]

Bedankt voor alle replies. Ik zie een aantal widget mogelijheden voorbij komen, maar ze maken alle een erg zware indruk op me. Nadat ik net even wat op internet heb gelezen moet het ook mogelijk zijn om direct op het X Window systeem mn java swing applicatie te draaien (dus zonder window manager als bv fluxbox). Als ik dan in mn applicatie een aantal vitale mogelijkheden meeneem, zoals bijvoorbeeld shutdown heb ik een enorm licht gewicht systeem met alle mogelijkheden die ik maar wil. Of heb ik het nu mis?

[ Voor 4% gewijzigd door Oyster op 15-11-2006 20:07 ]

[MBV]

Hoeveel tijd heb je ervoor uitgetrokken?
Een Qt-applicatie die ongeveer doet wat jij wilt kan je, zonder C++ kennis, in een paar dagen in elkaar zetten (ik ga ervan uit dat je dan in een OO-taal wel eens wat hebt gedaan). Er is bijvoorbeeld al een klasse die JPEG's kan uitlezen zonder gedoe (QImageReader). desktop-screenshot is een voorbeeldapplicatie die de meeste dingen die jij wilt al kan (jpegs lezen en weergeven ).
Misschien zijn er experts die iets kunnen zeggen over direct op X, of direct op een framebuffer, maar dat zal je erg veel tijd kosten. Verder denk ik dat de winst erg klein is, vooral als je een light-weight manager als XFCE of fluxbox gebruikt. Ga dan direct voor programmeren op het framebuffer.

[ Voor 12% gewijzigd door MBV op 15-11-2006 20:18 ]

[Confusion]

Python heeft goede Qt bindings en Trolltech werkt aan (of zijn er inmiddels al?) Java bindings voor Qt.

[NetForce1]

Trolltech is inmiddel al redelijk ver met de java bindings voor Qt (Qt Jambi geheten). Onlangs is Technology Preview 3 vrijgegeven. Voor meer info zie: http://www.trolltech.com/...ds/qt/qtjambi-techpreview

[Hagar]

Kijk ook eens naar freevo http://freevo.sourceforge.net/

Door het gebruik van SDL kan freevo naast X ook direct op de framebuffer werken.
Ik weet niet precies wat het doel is, maar de GPL staat het iig toe om ideën af te kijken

[MBV]

wat heeft java voor waarde als je een light-weight systeem wilt? Hij overweegt zo low-level te gaan dat hij heel X wil schrappen, dus een framework bovenop je windowmanager lijkt me dan niet echt de gewenste richting.

Java is een vrij log iets, wat je standaard niet hebt. Python was dacht ik al iets lichter, maar C++/Qt is niet zo heel moeilijk

[Oyster]

Allemaal bedankt. Ik heb me er even in verdiept en de combinatie C++/Qt ziet er erg goed uit! Nu nog aan de praat krijgen.

[Janoz]

Als het je puur om de slideshow fuinctionaliteit gaat dan zou ik eerder overwegen om X weg te laten en een C(++) oplossing met framebuffer te gebruiken. Welke widgets wil je gaan gebruiken? Een slideshow lijkt me als enige functionaliteit het afbeelden van een plaatje te hebben. Je hebt geen mouse, buttons, frames en window decoraties nodig lijkt me.

[farlane]

Ik kan je vertellen, als je jezelf pijn wilt doen ga je direct in de framebuffer wroeten. Weinig overhead dat wel.

Het idee erachter is dat je het framebuffer device opent, de device parameters met een IOCTL ophaalt en dan het device met een mmap in je proces mapt.

Hoppakee, je hebt een pointer naar 'VGA geheugen' waar je lekker in mag wroeten. Ik kan je wel vertellen dat je vervolgens nog ver verwijderd bent van een werkend windowing system

Nadeel is ook dat je kernel met framebuffer ondersteuning gecompileerd moet zijn anders werkt het helemaal niet. ( Weet niet of dat met een module kan eigenlijk )

[edit]
De lib die Janoz daar aanhaalt ziet er idd wat vriendelijker uit. Zo te zien heeft deze ook functies voor het lezen van bijv gif'jes etc

[ Voor 10% gewijzigd door farlane op 28-11-2006 17:36 ]

[Janoz]

Toevallig ben ik nog even door wezen zoeken op dit onderwerp en kwam ik svgalib tegen. Hierbij kun je je scherm in een bepaalde mode zetten en gewoon pixels schrijven zeg maar. Erg lowlevel, maar wel met een prettige abstractie en waarschjinlijk een stuk werkbaarder dan zelf naar de framebuffer gaan schrijven.

[Genoil]

ja of SDL...

[alx]

Waarom moet een simpel slideshow programma (bestaat zoiets niet al?) lichtgewicht zijn? Waarom is dat zo'n belangrijke eis? Iedere 5 sec moet de pc een nieuwe foto op het scherm toveren. Wil je dat ubersnel maken? Of moet er nog een sloot geheugen over zijn voor al die andere taken die dat ding voor je moet doen, terwijl jij op de bank zit en naar je foto's kijkt?

Lijkt mij dat je liever snel en gemakkelijk zoiets eenvoudigs in elkaar flanst, dan nodeloos low-level zit te hacken.

[Brent]

wxWidgets kan ik je ook aanraden, draait op alles (GTK, QT, Mac, Windows)

[MBV]

wxWidgets draait op X11, het windows-platform en het Mac OS platform. Het heeft alleen helemaal niks te doen met GTK en QT. Het is namelijk precies op dezelfde laag als QT en GTK. Je hebt er net zo goed een library voor nodig om je programma te draaien als de QT library en GTK library.
En wat ik aan onderzoek heb gedaan voor ik mijn HBO-progsel ging schrijven was QT een stuk eenvoudiger te programmeren, en zat er een stuk meer default in.

wat jij bedoelt is waarschijnlijk dat je applicatie in een Gnome- en KDE-omgeving de goede soort schermpjes laat zien. Dat heeft alleen helemaal niets met GTK en QT te maken, maar alles met de standaard layout-conventies. Qua programmeren maakt dat natuurlijk geen bal uit. Maak maar eens een QT-programma en draai het onder KDE, dat ziet er net zo waardeloos uit als een GTK-programma

[ Voor 10% gewijzigd door MBV op 28-11-2006 20:08 ]

[farlane]

simulacrum schreef op dinsdag 28 november 2006 @ 19:55:
Lijkt mij dat je liever snel en gemakkelijk zoiets eenvoudigs in elkaar flanst, dan nodeloos low-level zit te hacken.

Is per definitie niet nodeloos imho

[ATS]

Ik zou ook voor Qt gaan. Waar je ook eens naar kan kijken is of je niet Qt/Embedded (heet tegenwoordig QTopia Core geloof ik) kan gebruiken in plaats van de X windows versie. Dan kan je X gewoon weglaten en met gewone Qt widgets and technieken tekenen op je framebuffer.

[Creepy]

MBV schreef op dinsdag 28 november 2006 @ 20:07:
wxWidgets draait op X11, het windows-platform en het Mac OS platform. Het heeft alleen helemaal niks te doen met GTK en QT. Het is namelijk precies op dezelfde laag als QT en GTK. Je hebt er net zo goed een library voor nodig om je programma te draaien als de QT library en GTK library.
En wat ik aan onderzoek heb gedaan voor ik mijn HBO-progsel ging schrijven was QT een stuk eenvoudiger te programmeren, en zat er een stuk meer default in.

wxWindows heeft naast een X11 binding ook een native GTK binding zodat de GTK widgets gebruikt worden i.p.v. plain X11. Wat dat betreft zit het net een laag hoger dan QT en GTK.

[Martin Sturm]

Het is overigens een beetje raar om te adviseren om Qt te gaan gebruiken op de desktopomgeving Xfce. Dit, omdat Xfce is ontwikkeld in GTK (de zelfde toolkit als Gnome en The Gimp). Als je dus een Qt-programma op Xfce gaat draaien heb je dus zowel GTK als Qt nodig, wat nu niet echt zorgt voor weinig overhead. Als je dus een lichte desktopomgeving zoals Xfce wil gebruiken, kun je het beste je programma ook in GTK+ schrijven.
Daarnaast heb ik het idee dat veel adviseurs hier zich niet zo heel goed in de materie hebben verdiept. Qt is een C++-framework, GTK+ is volledig C. Echter is de laatste ook object georienteerd (door een aantal uitbreidingen van C te ontwikkelen). Toegegeven, het ontwikkelen voor GTK+ in C is niet echt eenvoudig. Echter zijn er inmiddels een groot aantal language bindings, waaronder Python, C++ (Gtkmm), C# (Mono) en Java. In deze objectgeorienteerde talen is het programmeren van GTK+ net zo eenvoudig als het ontwikkelen in Qt. Overigens zijn er voor Qt ook veel taalbindingen beschikbaar, maar (voor zover ik weet) niet zoveel als voor GTK+ (zo is er vziw geen C#-binding die wordt onderhouden).

Als je echter al Java kunt, is het niet echt nodig om een (zware) windowmanager te gebruiken, omdat je gewoon Java-applicaties directh op X11-kunt draaien.

[ATS]

Martin Sturm schreef op woensdag 29 november 2006 @ 13:02:
Het is overigens een beetje raar om te adviseren om Qt te gaan gebruiken op de desktopomgeving Xfce. Dit, omdat Xfce is ontwikkeld in GTK (de zelfde toolkit als Gnome en The Gimp). Als je dus een Qt-programma op Xfce gaat draaien heb je dus zowel GTK als Qt nodig, wat nu niet echt zorgt voor weinig overhead. Als je dus een lichte desktopomgeving zoals Xfce wil gebruiken, kun je het beste je programma ook in GTK+ schrijven.

Eens, maar je hebt helemaal geen Xfce of iets dergelijks nodig.

Daarnaast heb ik het idee dat veel adviseurs hier zich niet zo heel goed in de materie hebben verdiept. Qt is een C++-framework, GTK+ is volledig C. Echter is de laatste ook object georienteerd (door een aantal uitbreidingen van C te ontwikkelen). Toegegeven, het ontwikkelen voor GTK+ in C is niet echt eenvoudig. Echter zijn er inmiddels een groot aantal language bindings, waaronder Python, C++ (Gtkmm), C# (Mono) en Java. In deze objectgeorienteerde talen is het programmeren van GTK+ net zo eenvoudig als het ontwikkelen in Qt. Overigens zijn er voor Qt ook veel taalbindingen beschikbaar, maar (voor zover ik weet) niet zoveel als voor GTK+ (zo is er vziw geen C#-binding die wordt onderhouden).

Errr... dus? Er zijn meer languagebindings, en dus is het beter? Je hebt toch maar één taal nodig voor zo'n project als dit? Als daar een binding voor is voor één goede toolkit dan ben je toch klaar? Voor Qt zijn overigens in elk geval bindings voor C++, C, Ruby, Python en Java, zo uit mijn hoofd. Wat heeft dat nu te maken met het "zich in de materie verdiepen van de adviseurs"?

Als je echter al Java kunt, is het niet echt nodig om een (zware) windowmanager te gebruiken, omdat je gewoon Java-applicaties directh op X11-kunt draaien.

Dat kan dus met Qt ook: gewoon Qtopia Core gebruiken direct op je framebuffer. Is licht genoeg om te gebruiken op een PDA of op een telefoon.

André

[.oisyn]

Wat is dat linux toch een fantastisch platform

[MBV]

Creepy schreef op woensdag 29 november 2006 @ 11:19:
[...]

wxWindows heeft naast een X11 binding ook een native GTK binding zodat de GTK widgets gebruikt worden i.p.v. plain X11. Wat dat betreft zit het net een laag hoger dan QT en GTK.

Dat is vziw geen QT binding. Zoals ik al zei: als je een programma maakt voor X11 ziet het er niet uit in KDE. Daarvoor moet je het afleiden van de KDE-objecten. Je mainwindow moet je afleiden van KMainWindow ipv QMainWindow (als ik de naam goed heb onthouden), dat soort dingen. Daarmee haal ik mijn eigen verhaal weer onderuit dat het op dezelfde laag zit

En dat ik er te weinig vanaf weet ontken ik ook niet. Zou er graag meer vanaf weten, maar helaas is dat niet zo. Ik weet niet meer dan de vergelijking die ik 2 jaar geleden heb gemaakt voor KTermEmulator. Conclusie was toen dat QT het makkelijkste is qua C++-interface.
leukste aan dat projectje is dat de KDE terminal dat met wat trucs zoals pipes ook kan, kwamen we achter toen we op 3/4 waren. Hebben we maar niet tegen de leraar gezegd

[writser]

Nu ben ik van plan om het programma in C of java te maken

Kijk, volgens mij begin je hier precies verkeerd. Je doel is om een slideshow-programma te maken. Relevante vragen zijn dan:

- Waar gaat het op draaien? Framebuffer? X kaal? X met KDE? X met gnome? X met iets anders?
- Zijn er al programma's of libraries die iets soortgelijks doen?
- Is performance belangrijk? (lijkt me niet voor een slideshow)
- Wil ik veel tijd besteden aan het ontwikkelen?
- Wat voor bestandsformaten ga je ondersteunen?

Als je al die vragen hebt beantwoord kun je eens gaan nadenken over de programmeertaal die je wil gebruiken. Volgens mij heb je met Python / Java / C# in een paar regels een programma in elkaar geflanst. Ik zie niet in waarom je het in C zou willen doen. Bovendien bestaan er al tientallen slideshow-programma's, waarom gebruik je die niet?

@.oisyn: keuzevrijheid. Het topic wordt zo verwarrend omdat de topicstarter zelf niet weet wat hij wil.

[.oisyn]

writser schreef op woensdag 29 november 2006 @ 14:57:
@.oisyn: keuzevrijheid.

offtopic:
Die "keuzevrijheid" straalt niet echt bepaald eenheid uit en is de reden dat linux niet zo heel erg populair is onder de beginnende computergebruikers. Bovendien verdeelt het ook nog eens de developers in meerdere kampen (dit geldt ook voor alle verschillende distros). Ik had het trouwens verder niet over de verwarring in deze topic.

Maar goed, ik wil de topic verder niet laten verzanden in een discussie over linux

[ Voor 9% gewijzigd door .oisyn op 29-11-2006 16:46 ]