Aber wie soll man da anfangen? (Graphische Oberflächen)

[thread]4830[/thread]

Aber wie soll man da anfangen?

Gast Gast

2004-08-28 01:21

Hi Leute,

wenn Ihr eine grössere Anwendung mit graphischer
Oberfläche bauen sollt.
Wie fangt ihr da an?
Trennt ihr die GUI programmierung von der Funktionalität?
Welches Vorgehen findet Ihr am übersichtlichsten?

Danke,

Frodus

frodus

2004-08-28 01:24

User since
2003-09-26
147 Artikel
BenutzerIn
[default_avatar]

Sorry ich war wohl gerade nicht angemeldet.

Strat

2004-08-28 22:43

User since
2003-08-04
5246 Artikel
ModeratorIn

Ich habe gerade eine geschrieben (~7000 Zeilen), und da habe ich den Code in mehrere Module aufgeteilt:
x) abrechnung.pl -> Hauptprogramm, macht eigentlich kaum was
x) Abr/Config.pm -> Konfiguration
x) Abr/Data.pm -> Kommunikation mit der Datenbank (in meinem Fall SQLite)
x) Abr/Navigation.pm -> ich habe eine relativ komplizierte Navigation, so eine Art erweitertes und schoeneres Tk::Notebook, und den Code habe ich hier hereingepackt
x) Abr/Forms.pm -> Hier werden die ganzen Frames und sonstige Widgets erzeugt (mit Ausnahme der Navigation)
x) Abr/Callbacks.pm -> Wenn irgendwo ein Callback auftritt (z.B. -command), dann steht der Code dazu dort.

Abr/Export.pm -> Da eine der Hauptkomponenten ein Export aus der Datenbank ist (mit vielen Konvertierungen), habe ich es in ein eigenes Modul gepackt.

x) ... und noch ein paar weitere

Nebenbei: es ist bei eigenen Modulen besser, einen Hauptnamensraum (hier Abr) zu waehlen, der nicht von irgendwelchen CPAN-Modulen verwendet werden. Und dann das Verzeichnis ./Abr, in dem die Module liegen, dann mit

Code (perl): (dl )

1
2

use FindBin;
use lib "$FindBin::Bin";

Da viele Widgets irgendwie immer dasselbe Aussehen haben sollen, habe ich dafuer eigene Subroutinen geschrieben, die da Standardwerte setzen, z.B.

Code: (dl )

sub Label {
    my ($parent, $text, %options) = @_;
    $parent->Label(-text => $text, -background => &Abr::Config::BACKGROUND, 
           -padx => 2, -pady => 2, %options);
} # Label
# ------------------------------------------------------------
sub LabelTied {
    my ($parent, $textvar, %options) = @_;
    $parent->Label(-textvariable => $textvar, -background => &Abr::Config::BACKGROUND, 
           -padx => 2, -pady => 0, %options);
} # LabelTied

Und wenn in bestimmte Entry's nur bestimmte Werte in einer gewissen Maximallaenge eingegeben werden duerfen, kann ich dir mein Modul Tk::EntryCheck ans Herz legen, das nur gewisse Zeichen zulaesst... (dieses Modul ist im Rahmen dieses Projektes entstanden)

perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/

eisbeer

2004-08-29 15:47

User since
2003-08-29
347 Artikel
BenutzerIn

Kannst du mal deine Version von dem Notebook vielleicht ins netz stellen, oder
zumindest ein screenshot? So komisch es klingt, einige Leute für die ich Programmiere
kommen mit dem "un-windowsischen" Notebook nicht so gut klar wie mit dem normalen...

Die meisten PC Probleme befinden sich zwischen Bildschirm und Stuhl...

lichtkind

2004-08-29 21:26

User since
2004-03-22
5679 Artikel
ModeratorIn + EditorIn

aaaalso,
mach dir vorher ein plan was das programm machen soll und lass dir etwas zeit damit,
damit du erkennst welche strukuren so entstehen werden und was an funktionalität anfällt um auch zu erkennen
was man mit vorhandenen modulen machen kann.
wenn du anfängst zu programmieren, fang bei den wichtigsten features an und versuch auch so früh wie möglich
etwas laufähiges nützliches oder wenigstens nachvollziehbares(debugbar) zu machen.

beim programmieren entwickelt sich auch die vorstellung und du merkst welche einheiten du in extra module packst.
so früh wie sinnvoll lager deinen code in eigene module aus,
denn dann hast du nicht nur wiederverwertbares für später sondern der code wird auch verständlicher wenn du nur sinneinheiten zusammen hast die sich immer nur auf einer programmierebene befinden.
und plane nicht zu weit vorraus sondern beobachte wie entwicklung im moment läuft(man kann nicht alles vorraus sehen)

viel erfolg

Tutorien in der Wiki, mein zeug:
kephra, baumhaus, garten, gezwitscher

Es beginnt immer mit einer Entscheidung.

renee

2004-08-29 21:46

User since
2003-08-04
14371 Artikel
ModeratorIn

Ich empfehle immer, erst die Funktionalität zu programmieren und hinterher erst das GUI. Das nach Möglichkeit auch stark trennen (verschiedene Programme/Module).

Das hat den Vorteil, dass du erstmal die Funktionalität testen zu können, ohne Dich vom GUI ablenken zu lassen. Außerdem kannst Du das Programm mit der Funktionalität vielleicht später auch mal anderweitig einsetzen.

Wenn Du das GUI zu früh machst, und musst dann etwas in der Funktionalität ändern, so kann das Dein ganzen GUI durcheinander bringen. Wenn du es erst zum Schluss machst, dann weißt Du schon, welche Widgets Du brauchst und wie das Layout aussehen soll!

OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/

Crian

2004-08-30 11:45

User since
2003-08-04
5866 Artikel
ModeratorIn

Normalerweise trenne ich Funktionalität und Oberfläche, etwa in die Bereiche Logik, Dateihandling und Oberfläche. Bei größeren Projekten wie in Strats Beispiel zerteile ich diese Bereiche dann noch in weitere Untereinheiten.

Habe ich allerdings ein relativ überschaubares Programm, das auch noch stark mit der Gui verwachsen ist, so trenne ich auch mal ausnahmsweise gar nicht (etwa bei Pentris). Aber eigentlich ist das der schlechtere Weg. Wenn man irgendwann mal die GUI tauschen will hat man es viel einfacher, wenn vorher schon alles sauber getrennt ist.

An machen Stellen ist eine sehr saubere Trennung allerdings schwierig und / oder sehr aufwändig. Da muss man dann auch mal auf sein Gefühl hören, ob der eigene Anspruch an Perfektionismus gerade gerechtfertigt ist.\n\n

s--Pevna-;s.([a-z]).chr((ord($1)-84)%26+97).gee; s^([A-Z])^chr((ord($1)-52)%26+65)^gee;print;

use strict; use warnings; Link zu meiner Perlseite

frodus

2004-08-31 01:39

User since
2003-09-26
147 Artikel
BenutzerIn
[default_avatar]

Danke fuer die Tips :)
Ich werde mir die Empfehlungenzu Herzen nehmen.

Bis dann,

Frodus

View all threads created 2004-08-28 01:21.