sastanak 26.03.04
Sastanak smo odrzali u kafeu u metrou.
Od sefova timova bili su prisutni samo Tihomir i moja malenkost.
Predlozeno je da sve nase klase imaju prefix Eda, a da klase koje su
vezane za sheme, imaju i dodatak Sch u prefiksu.
1. predlog prezentacije u memoriji:
1a.prva varijanta
class EdaSchKomponenta {
EdaSchPrimKomponenta *niz;
int numpart; //broj nezavisnih komponenti u jednom cipu
...
//ovde bi isao opis komponente, jedinstveni broj u biblioteci itd.
...
}
class EdaSchPrimKomponenta {
EdaSchLine *linije;
EdaSchRectangle *pravougaonici;
EdaSchAnnotation *tekstovi;
...
//razne druge primitive nasledjene iz Qt-a
...
EdaSchPin *pinovi;
...
}
class EdaSchLine : public QCanvasLine {
...
}
ostale primitive bi se nasledjivale na isti nacin iz vec
gotovih Qt klasa, osim EdaSchPin:
class EdaSchPin {
QCanvasLine *linija;
QBrush *tacka;
...
}
naravno, sve ove klase bi sadrzale i odgovarajuce fje koje bi sve
ovo odrzavale u jednu celinu.
1b. neki moj pokusaj koji mi sad deluje mnogo lose, pa samim tim i
nije vredan pomena.
1c. SVG? ja nesto nisam za ovo resenje, jer ne znam kako bi se
odvojila predstava pina i graficka prestava. meni deluje lakse kad
bi sve sami odradili...
ovde nam definitivno treba pomoc iskusnijih :(
2. komunikacija izmedju biblioteka 2 i 3:
2a.bez DOM stabla, kako je predlozio Toplica u nekom od prethodnih
mailova.
Prilikom importa, biblioteka 3 bi pozivala npr. konstruktor klase
EdaKomponenta i tako formirala objekat u memoriji. NISMO nasli neko dobro
resenje za interfejs za eksport.
Ovde se postavilo pitanje cemu uopste XML ako se radi ovako? jer
biblioteka 2 bi lako sama mogla da sacuva klasu u fajl...
2b.DOM stablo - nedostatak je prakticno nestajanje granice izmedju
tima 2 i 3...
i ovde nam treba pomoc iskusnijih :((
3. da li je u planu za 21 nedelju predvidjen samo Editor Biblioteke,
ili i Schematic Editor? na ovo smo imali 2 razlita odgovora... a samim
tim nijedan :)
4. dao sam predlog da se kompletno zaobidje KDE, i da se oslonimo samo
na Qt, kako ne bi bilo problema oko portovanja. ovo bas i nije naislo
na dobar odziv kod Tihomira i Ivanka, a drugi su koliko mi se cini bili malo
nakolonjeniji varijanti bez KDE-a. Pretpostavljam sta ce biti ishod ovog
pitanja, ali morao sam da pomenem...
I dalje stojim pri tome da OD STARTA treba imati funkcionalnu verziju
i na Windowsu.
5. Windows vs. Redhat vs. Suse.
odluceno je da je Redhat bolji od Suse-a, a da je Windows zakon za sve LOL
salim se, ovo je poruka za Tihomira, chill, kad bi svi voleli iste
stvari i mislili isto, kakav li bi svet bio :) prihvatite me ovakvog kakav
jesam, proamericki do srzi LOL
pozdrav,
nikola
Od sefova timova bili su prisutni samo Tihomir i moja malenkost.
Predlozeno je da sve nase klase imaju prefix Eda, a da klase koje su
vezane za sheme, imaju i dodatak Sch u prefiksu.
1. predlog prezentacije u memoriji:
1a.prva varijanta
class EdaSchKomponenta {
EdaSchPrimKomponenta *niz;
int numpart; //broj nezavisnih komponenti u jednom cipu
...
//ovde bi isao opis komponente, jedinstveni broj u biblioteci itd.
...
}
class EdaSchPrimKomponenta {
EdaSchLine *linije;
EdaSchRectangle *pravougaonici;
EdaSchAnnotation *tekstovi;
...
//razne druge primitive nasledjene iz Qt-a
...
EdaSchPin *pinovi;
...
}
class EdaSchLine : public QCanvasLine {
...
}
ostale primitive bi se nasledjivale na isti nacin iz vec
gotovih Qt klasa, osim EdaSchPin:
class EdaSchPin {
QCanvasLine *linija;
QBrush *tacka;
...
}
naravno, sve ove klase bi sadrzale i odgovarajuce fje koje bi sve
ovo odrzavale u jednu celinu.
1b. neki moj pokusaj koji mi sad deluje mnogo lose, pa samim tim i
nije vredan pomena.
1c. SVG? ja nesto nisam za ovo resenje, jer ne znam kako bi se
odvojila predstava pina i graficka prestava. meni deluje lakse kad
bi sve sami odradili...
ovde nam definitivno treba pomoc iskusnijih :(
2. komunikacija izmedju biblioteka 2 i 3:
2a.bez DOM stabla, kako je predlozio Toplica u nekom od prethodnih
mailova.
Prilikom importa, biblioteka 3 bi pozivala npr. konstruktor klase
EdaKomponenta i tako formirala objekat u memoriji. NISMO nasli neko dobro
resenje za interfejs za eksport.
Ovde se postavilo pitanje cemu uopste XML ako se radi ovako? jer
biblioteka 2 bi lako sama mogla da sacuva klasu u fajl...
2b.DOM stablo - nedostatak je prakticno nestajanje granice izmedju
tima 2 i 3...
i ovde nam treba pomoc iskusnijih :((
3. da li je u planu za 21 nedelju predvidjen samo Editor Biblioteke,
ili i Schematic Editor? na ovo smo imali 2 razlita odgovora... a samim
tim nijedan :)
4. dao sam predlog da se kompletno zaobidje KDE, i da se oslonimo samo
na Qt, kako ne bi bilo problema oko portovanja. ovo bas i nije naislo
na dobar odziv kod Tihomira i Ivanka, a drugi su koliko mi se cini bili malo
nakolonjeniji varijanti bez KDE-a. Pretpostavljam sta ce biti ishod ovog
pitanja, ali morao sam da pomenem...
I dalje stojim pri tome da OD STARTA treba imati funkcionalnu verziju
i na Windowsu.
5. Windows vs. Redhat vs. Suse.
odluceno je da je Redhat bolji od Suse-a, a da je Windows zakon za sve LOL
salim se, ovo je poruka za Tihomira, chill, kad bi svi voleli iste
stvari i mislili isto, kakav li bi svet bio :) prihvatite me ovakvog kakav
jesam, proamericki do srzi LOL
pozdrav,
nikola
- Follow-Ups:
- Re: sastanak 26.03.04
- From: Toplica Tanaskovic <toptan@kde.org.yu>
- RE: sastanak 26.03.04
- From: "Gvozden Marinkovic" <gvozden@titan.etf.bg.ac.yu>
- RE: sastanak 26.03.04
- From: "Gvozden Marinkovic" <gvozden@titan.etf.bg.ac.yu>
- Re: sastanak 26.03.04
- From: Ivankovic Ivanko <ivankoi@tesla.rcub.bg.ac.yu>
- Re: sastanak 26.03.04
Previous by date: jos jedan logo
Next by date: Re: sastanak 26.03.04
Previous by thread: jos jedan logo Next by thread: Re: sastanak 26.03.04
Previous by thread: jos jedan logo Next by thread: Re: sastanak 26.03.04