QT Library ile uygulama geliştirmek, nasıl?

[bluekid]

Murat DİCLE

Anlayamadım. Benim bildiğim,GPL yada benzeri lisanslarda, open sorce kullanılan bölümleri açmak mecburiyeti yok mu?

GPL ile LGPL farklılıkları vardır
http://wiki.linux-sevenler.org/index.ph ... L_Nedir%3F

...Ticari derken kastettiginiz kapali kaynak kodlu yazilim demek ise o zaman
evet, kodun icinde GPL yazilima yer veremezsiniz. Hatta GPL bir
kutuphaneden bir fonksiyonu bile kapali kaynak kodlu bir yazilimdan
cagiramazsiniz.

LGPL, Lesser GPL, daha asagi bir GPL, yani bir nevi sulandirilmis GPL .
LGPL'de GPL'den farkli olarak kutuphaneyi tamamen bagimsiz ayri bir
paket olarak kapali kaynak kodlu yazilimin yaninda verebilir ve kapali
kaynak kodlu yaziliminizin icinden o kutuphaneyi kullanabilirsiniz. Ancak
"kullanim"dan kastettiginiz, LGPL bir yazilimin kodlarini kapali kaynak
kodlu bir yazilima gommek ise -- hayir bunu LGPL'le de olsa yapamazsiniz.

http://listweb.bilkent.edu.tr/Linux/lin ... /0026.html

[aLonE CoDeR]

Topice devam etmeyi düşünmüyordum ama son birkaç şey daha yazma gereği duydum..

Evet, kaçırmışsınız sanırım. Bir önceki cümlemde yazılıma göre dil seçilmesini söylemiştim, lisp ya da herhangi bir dil örnek olaraktı orada. Kaçırdığınız nokta burası.

Burada bir yanlış anlaşılma var, kendi yazdıklarımı kastederek bu cümleyi sarfettim. Her neyse..

Kullanılan dilin tüm özelliklerini tam olarak kullanamadıktan sonra ne anlamı kalır ki? Elinizde bir ferrari var ama yol toprak ise anlamı olmaz.

Burada kaçırdığın olay şu;
Elimde ferrari olması ve yolun toprak olmasıyla kullanılan dile tam hakim olmak farklı çözümler gerektirir..Ferrariyi kullanabilmek için yolu senin yapmanla dile hakim olabilmek için detaylara girmen arasında çok ciddi fark var..Kaldı ki bugün kullandığımız dile (örneğin Delphi..) ne kadar hakimiz bunun bir değerlendirmesini yapsak zaten çelişki burada başlıyor.

Neyse, konu uzadıkça daha fazla vakit ayırmak gerekiyor, kendi adıma nokta koyuyorum konuya..

Kolay gele..

[doganzorlu]

Selam,

Uzunca bir süre bu konuda çalışmış biri olarak şu soruların cevabını bulmanız gerektiğini düşünüyorum;

1. Uygulama native mi olacak interpret mi edilecek (bir vm olabilir precompile de edilse bir çalıştırıcı gerektirebilir vs)

2. Çalıştığında uygulama ve prezentasyondan oluşan klasik bir uygulama mı olacak yoksa dağıtık bir model için çok katmanlı mı olacak ?

3. Veritabanı kullanıcaksa kullanılacak veritabanı ne olacak ve bu kullanılacak araç için API ve sürücü desteği ne olacak ?

4. Şayet resim/rapor/sheet gibi bölümler olacaksa diğer uygulamalarla birarada çalışabilirliği gerekecek mi ? (Misal spreadsheet den bir bölüm datayı bir başka ss uygulamasına taşımak gerekecek mi ?)

5. Taşınırken kod aynen mi taşınacak yeniden mi derlenecek ? (1. soruyla doğrudan bağlantılıdır) Yani platform bazında sürümleri mi olacak yoksa tek sürüm heryerde mi çalışacak..?

6. İşletim sistemi sistem api ları kullanılacak mı ? Bu durumda taşınabilirlik nasıl olacak ?

Bu soruların cevaplarını düşünüp ona göre karar vermek gerekiyor. Tek dağıtım ihtiyacı olduğunda bile katman sayısı arttğında katmanların ayrı ayrı araçlarla yazılması bile sözkonusu olabilir.

Şu anda kullandığım sistem %100 portable. Veritabanı C ve üzerine bindirilmiş java VM i ile, application serverın business logic işleten bölümü C ile iletişim katmanı java ile yazılmış ve sistemin kullanıcıya ulaşmasını sağlayan prezentasyon katmanı ise java ile geliştirilmiş durumda.

Taşınabilirliği performansla birlikte düşünmek gerekiyor. Seçilecek hazrılop kütüphane işin en kolay kısmı, sistemin bir bütün olarak kurgulanması gerekiyor.

Kolay gelsin.