Schrift
Wiki:Tipp zum Debugging: use Data::Dumper; local $Data::Dumper::Useqq = 1; print Dumper \@var;
[thread]4729[/thread]

Core & GUI voneinander getrennt



<< |< 1 2 >| >> 12 Einträge, 2 Seiten
coax
 2004-03-10 08:00
#41725 #41725
User since
2003-08-11
457 Artikel
BenutzerIn
[default_avatar]
Ich habe vor ein Programm zu schreiben das ueber die Kommandozeile als Interaktive Shell (aehnlich dem PPM) zu bedienen ist.
Zusaetzlich moechte ich noch eine GUI fuer das Programm schreiben.

Wie sollte ich das am guenstigsten realisieren, ich hab ja nun Einfluss auf die Arbeitsweise des Core-Programms. Sollte ich einen
zusaetzlichen Optionsschalter einbauen, der mir nur die puren Daten liefert, damit ich die Daten leichter aus der Programmausgabe
herausloesen kann und nicht mit komplexen RegExps arbeiten muss oder sollte ich mich damit gar nicht weiter beschaeftigen,
das Programm einfach weiter schreiben und dann spaeter die GUI drumherum basteln (was aber das Parsen der Daten erschwert).

Welchen Weg wuerdet Ihr waehlen bzw. was ist da Gang und Gebe.

Funktionen des Programms sind: Auffinden von Dateien gleichen Inhalts, Extrahieren derer Dateitypischen Informationen
und Schreiben einer neuen Datei mit den wichtigsten Informationen aus den Quelldateien (Duplikate werden danach  geloescht).
Ein Beispiel waeren jetzt MP3-Dateien mit gleichen Inhalt aber unterschiedlicher Dateinamen (bzw. unterschiedlichen ID3Tags).
Daraus wird dann eine einzige MP3-Datei mit den wichtigsten Zusatzinformationen erstellt.

Grusz coax.
,,Das perlt aber heute wieder...'' -- Dittsche
esskar
 2004-03-10 11:24
#41726 #41726
User since
2003-08-04
7321 Artikel
ModeratorIn

user image
zuerst die funktionen schreiben, die genau das Realsieren, was dein Programm später können muss...

danach einen wrapper schreiben, der die kommandos aus der shell auf deine funktionen mappt

danach einen wrapper schreiben, der die kommandos aus der gui auf deine funktionen mappt.
Crian
 2004-03-10 13:38
#41727 #41727
User since
2003-08-04
5872 Artikel
ModeratorIn
[Homepage]
user image
Und die Funktionen in ein eigenes Modul stopfen...
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
coax
 2004-03-10 20:15
#41728 #41728
User since
2003-08-11
457 Artikel
BenutzerIn
[default_avatar]
Dank euch beiden erstmal.

[quote=esskar,10.03.2004, 10:24]zuerst die funktionen schreiben, die genau das Realsieren, was dein Programm später können muss...
[/quote]
Das waeren ja dann meine Module, die sind so weit auch schon geschrieben dass ich alle Funktionen so nutzen kann wie von mir gewollt.

Quote
danach einen wrapper schreiben, der die kommandos aus der shell auf deine funktionen mappt

danach einen wrapper schreiben, der die kommandos aus der gui auf deine funktionen mappt.

Das heiszt ich soll nicht (so wie ich dachte) die Ausgabe von den Shellprogramm parsen und das dann auf die GUI uebertragen, sondern Shell und GUI als jeweils eigenstaendige Programme schreiben (unabhaengig von einander) ?

Grusz coax.
,,Das perlt aber heute wieder...'' -- Dittsche
esskar
 2004-03-10 22:33
#41729 #41729
User since
2003-08-04
7321 Artikel
ModeratorIn

user image
jo... würde ich schon machen...
die ausgaben, die die console macht, würde ich auch nur von dem consolen warpper machen lassen... dieser verarbeitet (genau wie an der gui wrapper) die ergebnisse deiner funktionen
coax
 2004-03-10 22:53
#41730 #41730
User since
2003-08-11
457 Artikel
BenutzerIn
[default_avatar]
alles klar, danke. :)
,,Das perlt aber heute wieder...'' -- Dittsche
Strat
 2004-03-11 11:56
#41731 #41731
User since
2003-08-04
5246 Artikel
ModeratorIn
[Homepage] [default_avatar]
[quote=esskar,10.03.2004, 10:24]zuerst die funktionen schreiben, die genau das Realsieren, was dein Programm später können muss...[/quote]
Bei sowas kann man hervorragend schon waehrend dem Entwickeln tests fuer die Funktionen/Module schreiben ;-)
perl -le "s::*erlco'unaty.'.dk':e,y;*kn:ai;penmic;;print"
http://www.fabiani.net/
coax
 2004-03-11 12:22
#41732 #41732
User since
2003-08-11
457 Artikel
BenutzerIn
[default_avatar]
[quote=Strat,11.03.2004, 10:56]Bei sowas kann man hervorragend schon waehrend dem Entwickeln tests fuer die Funktionen/Module schreiben ;-)[/quote]
Hab auch waehrend ich meine Module entwickle einen GUI-Prototyp verwendet, damit ich leichter verstehe wie die Schnittstelle auszusehen hat.

Ich hab mich eben mal umgeschaut wie ich mir die Arbeit bei der interaktiven Shell abnehmen kann, hab Term::Interact gefunden.
Das funktioniert scheinbar dann wieder nicht unter Windows, moechte da aber gerne so gut wie moeglich versuchen plattform-
unabhaengig zu entwickelen. Jemand eine Idee ?
,,Das perlt aber heute wieder...'' -- Dittsche
ptk
 2004-03-11 13:38
#41733 #41733
User since
2003-11-28
3645 Artikel
ModeratorIn
[default_avatar]
Term::ReadLine::Perl? Das sollte wenigstens auch unter Windows funktionieren.
coax
 2004-03-12 01:32
#41734 #41734
User since
2003-08-11
457 Artikel
BenutzerIn
[default_avatar]
thx @ptk,

ja normalerweise sollte es unter Windows funktionieren, wenn man nicht gerade diese Fehlermeldung bekommt:

Quote
The system cannot find the path specified.
Unable to get Terminal Size. The Win32 GetConsoleScreenBufferInfo call didn't work. The COLUMNS and LINES environment variables didn't work. The resize program didn't work. at E:/Perl/site/lib/Term/ReadKey.pm line 343.
Compilation failed in require at E:/Perl/site/lib/Term/ReadLine/Perl.pm line 58.


Hab mich da auch gleich mal im betreffenden Modul ReadyKey.pm umgeschaut, hab nur noch nicht genau herausgefunden woher die Funktion GetTermSizeWin32 stammt.

verwendete Testcode @ This is perl, v5.8.1 built for MSWin32-x86-multi-thread (Win2k3 Server)
Code: (dl )
1
2
3
4
#!/usr/bin/perl

 use Term::ReadLine;
 my $term = new Term::ReadLine;


Ist zumindest schon mal das Richtige, bedarf nur noch etwas Arbeit.

Danke, coax.
,,Das perlt aber heute wieder...'' -- Dittsche
<< |< 1 2 >| >> 12 Einträge, 2 Seiten



View all threads created 2004-03-10 08:00.