Bir Java programını 'yerli' yapmak neden zor?

Java uygulamalarının çoğu, C / C ++ uygulamalarıyla aynı görünmez. Swing, farklı bir görünüme sahip olmak amacıyla tasarlanmış olabilir, ancak okuduklarım temelinde, örneğin SWT 'yerel görünmeye' çalıştı ve başarılı olamadı.

Sorum şu:

Java dilinin geliştiricileri için, yerel GUI'lerin görünümünü tam olarak kopyalayan bir GUI sistemi tasarlamak neden bu kadar zor ? Yerel GUI'lerde farklı olan nedir? Sadece 'yerel' düğmelere benzeyen düğmeler tasarlama meselesi değil mi? Yoksa bundan daha derine mi iniyor?

Sadece 'yerel' düğmelere benzeyen düğmeler tasarlama meselesi değil mi?

Peki - düğmeler için. Ama bu senin hayal ettiğinden daha zor olabilir. Bugünlerde GUI bileşenlerini temsil etmek için kullanılan grafikler gerilmiş rasgele bitmap'ler kadar basit değildir (bunlar çok iyi ölçeklenemezler) - genellikle kendilerine programlanmış çok sayıda köşe durumu bulunan vektör tabanlı grafiklerdir ( bu yüzden düğme ekranın kenarına ulaştığında, örneğin biraz farklı görünebilir.) Ve elbette, bir düğmeye tıklandığında farklı grafiklere ihtiyacınız olacaktır. Telif hakkı nedenleriyle, geliştiriciler genellikle bu mevcut grafikleri tamamen kullanamazlar, bu nedenle yeniden yaratılmaları gerekir - ve çoğu zaman iyi bir iş yaparken, kaçınılmaz olarak, oradaki çok çeşitli grafik bileşenleri göz önüne alındığında bazı şeyler kaçırılır.

Tüm bunların elbette hafif, yerel olmayan bir GUI araç seti olan Swing'e dayandığını söylüyorum. SWT'nin yerel olduğu için, özellikle biraz tuhaf olan yerel görünmüyor . Yerli bileşenleri çağırmak için altındaki JNI'yi kullanan bir araç - yani eğer orada bir şey görünmüyorsa, görünüm ve his yüzünden olmayacak.

Kelimenin tam anlamıyla, bazı sistemlerde “yerel” sayılabilecek yarım düzine araç kiti var. Bunlardan bazıları benzersiz kavramlara veya yeteneklere sahip ve bunları platformlar arası bir araç setinde çoğaltmak sıkıcı. Bir uygulamanın görünümü ve hissi sadece “cilt” ile değil, aynı zamanda düzen ve nasıl davrandığını da belirler. Bazı düşünceler:

• Bir diyalogda, “OK” düğmesi hangi tarafta, solda veya sağda? Yeterince adil, her sistem için ayrı bir diyalog kuralım.
• Ekrandaki varsayılan düğmeyi nasıl işaretleriz? Renk tonu, kalın yazı tipi, düğme büyütme? Yeterince adil, hadi bir stil sayfasına koyalım.
• Windows'ta “Şerit” kavramı oldukça doğal. Bu, Şerit'in yaygın olmadığı Mac'e nasıl çevrilir? Yeterince adil, piksel-kesin düzenini unutalım ve her sistem için farklı bir araç çubuğu uygulaması sunalım.
• Menü çubuğu pencerenin bir parçası mı (Windows, isteğe bağlı olarak KDE) veya ekranın en üstünde mi duruyor (Mac, Unity)? Yeterince adil, piksel-kesin düzenini zaten attığımızdan, her bir sistem için farklı bir uygulama yazalım
• Yazı tipleri nasıl oluşturulur? Mümkün olduğunca net veya pürüzsüz ve antialiased? Ve hangi yazı tipi kullanılmalı? Farklı yazı tiplerinin farklı metrikleri olduğuna dikkat edin, bu nedenle aynı genişlikte oluşturulan aynı paragraf yazı tipine bağlı olarak farklı satır sayısına sahip olabilir.
• Pencerenin arka planı tek renk, görüntü veya degrade mi? Bunu da bir stil sayfasına koyalım.
• Kaydırma çubukları nasıl görünüyor? Düğmeler nerede - varsa? Ne kadar genişler veya yalnızca işaretçi belirli bir bölgeye hareket ettiğinde ortaya çıkıyorlar mı?
• Diğer renk şemalarını nasıl birleştiririz?
• Sürüklenebilir ne bekleniyor? Bağlam menüleri nerede beklenir?

Bu sorunlar, uygulamanın davranışına veya genel düzenine dokunduğunda basit bir stil sayfasıyla çözülemez. Tek gerçek çözüm, her bir sistemin başvurusunu yeniden yazmaktır (bu nedenle Java'nın platformlar arası faydalarını göz ardı etmek). Tek gerçekçi çözüm, piksel kesin düzenini unutmak ve sisteme özel araç setleri üzerinden soyutlayan ortak bir arayüze yazmaktır. Swing tarafından alınan çözüm, muhteşem bir şekilde başarısız olan çeşitli sistemleri taklit etmektir.

Daha sonra, platformlar arası tutarlılık var, uygulamanızın tüm sistemlerde tamamen aynı görünebileceği fikri (genellikle oyunların seçtiği, daldırmayı artırdığı yerlerde). Masaüstü uygulamalarında, bu sadece can sıkıcı ve kullanıcı beklentilerini bozuyor.

Evet, daha derine gider.

Yalnızca bu düğmeyi oluştururken, Windows veya OS X düğmesine benzeyen bir düğme oluşturmak kolaydır. Ancak düğme orijinalleri gibi "davranmalı", kolay olmayabilir: belki bir sürümünde daha fazla yer var, ancak diğerinde değil, belki de renk Windows sürümünde tasarımınız için daha uygun.

GUI’niz tamamen varsa, bu istisnadır: Bir OS X programı, içeriğini bir Windows programından farklı olarak sunar. Bu, bir GUI'de yakalamak imkansız olan yanındadır - iki GUI'ye ihtiyacınız olacaktır, ancak pek çok uygulama bu kadar telaşa neden olmaz. Bunun yerine, "çoğu sistemde iyi görünüyor" u hedefliyorlar - bu hala biraz yabancı görünüyor, ancak kullanması daha kolay ve geliştirmesi daha kolay.

OSX düğmesine veya Windows düğmesine veya başka bir araç setine benzeyen bir düğme oluşturmak zor değildir. Ancak çoğu ortam için kullanıcı arabirimi yönergeleri, "düğmenin nasıl göründüğü" nin temelleri kadar basit değildir. UI öğeleri arasındaki boşluktan, iyi bilinen belirli eylemlerin bir listede görünmesi gereken sıraya, menü sistemindeki Tercihler / Seçenekler iletişim kutusunun tam konumuna kadar birçok ince fark vardır. Biri çok basit kullanıcı arayüzleri için en yaygın durumları otomatik hale getirebilir, ancak çoğu kullanıcı arayüzü görevinin çok daha hassas bir dokunuş gerektirmemesi durumunda.

SWT bunu bir dereceye kadar otomatikleştirmeye çalıştı ve bir kez daha basit UI görevlerinde doğru buluyor. Fakat tek bedene uyan tek bir çözüm yok ve UI'ler daha karmaşık hale geldiğinde, kullandıkları temel yöntemler dağılmaya başlıyor. Genel olarak titizlikle çalışan manuel kullanıcı arayüzü çalışmasına geri dönmek mümkündür, ancak bu çoğu programcının tüm platformlar için yapabileceği veya yapabileceği bir şey değildir.

Swing'in buna yaklaşımı, mümkün olan her yerde doğal araç takımlarından kaçınmaktı. Yerli değil ve olmaya çalışmaz: onun yerine, nerede çalıştırılırsa çalışsın neredeyse aynı görünecek bir şey yaratmaya çalışır. Herkesi memnun etmek için (boşuna) çalışmak yerine, kendisini memnun etmeye çalıştı ve bu kadarıyla başarılı olsa da, sonuç daha geniş bir kullanıcı topluluğu için ne kadar etkili olduğunu sorgulayabilir.

Başvurunuzun her sistemde mümkün olduğunca doğal görünmesini beklemek ve başvurunuzun her sistemde aynı şekilde çalışmasını beklemek arasında bir denge vardır. "Doğru" bir seçenek yok.

Ayrıca, "doğal görünümlü" tarafı seçseniz bile, grafik araç setinizin kullanıcılarını, temel bileşenlerde ve API'de beklenmedik bir şekilde uygulamalarını kırabilecek API'deki "iyileştirmelere" karşı korumak isteyebilirsiniz.

Bu nedenle bazı GUI araç takımı geliştiricileri, yerel olanları taklit eden, ancak kendi uygulamalarını sağlayan kendi bileşenlerini sağlamayı tercih ediyor. Öte yandan, işlevsel olarak tamamlanmış bir GUI araç takımı geliştirmek önemli bir çabadır ve ekonomik düşünceler birkaç kenarın kesilmesine yol açabilir.

Bu sorunun Java'ya özel olmadığını, ancak platformdan bağımsız araç setleri üreten her şirketin karşılaştığını unutmayın.

Hepsi tarih yüzünden.

Sun, tüm Java yazılımlarının tüm makinelerde aynı şekilde çalışmasını diledi.

Yazılımın “yerel görünmesi” için, verilen işletim sistemindeki diğer yazılımlarla aynı şekilde çalışması gerekir.

Sun, bir işletim sistemine entegre olan Java yazılımı yazmayı zorlaştırmak için elinden gelen her şeyi yaptı; bir işletim sistemi ile herhangi bir entegrasyon, yazılımı her işletim sisteminde farklı şekilde çalıştırabilir.

Bugünlerde çok az Java programcısı web sunucusu tabanlı yazılımdan başka bir şeye önem veriyor.

Sun, Java'yı Microsoft java tabanlı sistemleri kullanan tüm programcıları gölgeleyerek öldürdü, bu nedenle ilk günlerde Java'yı seçen herhangi bir programcının kötü görünmesini sağladı.

“Yerel gibi” önemseyen masaüstü yazılımı yazan herkes, uzun zaman önce Java'yı kullanmamayı öğrendi ve her Oracle yazılımını kullandıklarında görüşlerini güçlendirdi.

Bu nedenle, bugünlerde Java programcılarından gelen masaüstü yazılımında “yerel görünme” talebinde bulunulmamaktadır.

Sizce, nativeSWT gibi araç setleri bu işletim sisteminin kullanıcı arayüzü için yayınlanmış standartları takip ederken, aslında kendi uygulamalarını yapan yerel uygulamalar. Sorun şu ki, hiç kimse bir Java uygulamasını başlattığınızda bu standartlara uyarak uygulama yapmaz. Yerli değil gibi görünüyor. Örnek olarak, neredeyse Microsoft'un tüm projeleri (Office, Outlook vb.), Windows standart kontrolleri kullanılarak görsel olarak çoğaltılamaz.

Hem Microsoft hem de Apple, işletim sistemi platformlarına dinamik UI özellikleri eklediğinden daha da kötüleşecek. Geliştiricilerin, uygulamalarını aynı şekilde kaplamalarına / stil vermelerine izin vermek, web tasarımları web siteleri için stiller oluşturur.

Android platformunda Java bu yolu takip ediyor. Android için kullanıcı arabirimi öğelerini XML'de tanımlanan skinnable stilleriyle oluşturma.

Java bir masaüstü platformu olarak hiç bu kadar popüler olmamıştı. Sonuç olarak, sektördeki bu değişiklikler masaüstü çalışma zamanlarına doğru aşağı inmiyor. Sadece sorunu çözmek için zaman harcamak isteyen geliştiriciler yok.

Hangi işletim sistemini de "yerel" görmek istersiniz?

Sadece zamanın% 100'ünde hepsine yerli olamazsın .

SWT vb., Bir uzlaşmaya varmanız gerektiğinde aldığınız her şey için yerli gibi görünmek için en iyi çaba yaklaşımıdır .

Ve aslında, bu uzlaşma ulaşmak gittikçe zorlaşmaya başlar; işletim sistemleri nedeniyle değil, giriş cihazları nedeniyle değil. Dokunmatik ekranlar için, aslında farklı bir tasarım yapmanız gerekir , çünkü sağ fare düğmesi yoktur. Bu nedenle, aynı işlevi yerine getirmeniz gerekir.

Sihirli olmadan, guestures için farenin sağ düğmesini "sezgisel" işlevselliğini taşır düğmesi var olmayacak sen bu noktada, aklınıza her platformda yerli vardır (her giriş cihazı için her detaylı yönü specifiying, ama yine de sigara herhangi -Anadili sen gelmiş değil ) kabul.

Gerçekten güzel bir soru. Geçmişte birkaç yıl boyunca hep kendimden merak etmiştim, bunun arkasında yasal bir sebep olduğunu düşündüm, ama gerçekten yok.

Cevabın oldukça basit olduğunu düşünüyorum ve birçok cevap konuya gerçekten değmiyor.

Diliniz ekranda pasta çizmesine izin veriyorsa, Windows form denetimlerinin görünümünü taklit edecek ve tam olarak hissedecek şekilde temel alan bir gui çerçevesi oluşturmak% 100 mümkündür.

Java çapraz platform olduğundan, çalışan sistem türüne göre (Mac / Windows) kullanıcı arayüzünün çalışma ortamı platform stiliyle eşleşen her iki platformda farklı görünmeyi seçtiğinden emin olmak da tamamen mümkündür.

Örneğin XAML'de görebileceğiniz gibi, kullanıcı arayüzü çok yapılandırılmış biçimde ve dilde kolayca sunulabilir. Bunu yapmak için zaman harcanması halinde "yerel" davranışları seçmek de mümkündür.

Böylece, Java geliştiricilerinin Mac ve Windows'ta yerel görünecek uygulamalar edinmesine izin verecek GUI çerçevesi oluşturmak mümkün olacaktır.

Böylece Swing'e geçiyoruz, Java için oluşturulabilecek GUI çerçevelerinin potansiyel sonsuzluğundan yalnızca bir GUI çerçevesi. Yukarıdaki süreci izlemeyen nasıl programlandığı gibi davranır ve her iki sistemde de tuhaf görünümlü uygulamalar elde edersiniz. Bu, Swing geliştiricileri tarafından yapılan seçimdir; hiç kimse onları yapmaya ve bu şekilde davranmaya zorladı.