Mengapa sulit membuat program Java 'tampak asli'?


98

Sebagian besar aplikasi Java tidak terlihat sama dengan aplikasi C / C ++. Ayunan mungkin telah dirancang dengan sengaja untuk memiliki tampilan yang khas, tetapi berdasarkan apa yang telah saya baca, SWT misalnya mencoba untuk 'terlihat asli', dan tidak sepenuhnya berhasil.

Pertanyaanku adalah:

Mengapa sulit bagi pengembang bahasa Jawa untuk merancang sistem GUI yang persis meniru tampilan GUI asli? Apa yang berbeda dalam GUI asli? Bukankah ini hanya masalah mendesain tombol yang terlihat seperti tombol 'asli'? Atau apakah itu lebih dalam dari itu?


31
karena swing menulis komponen gui-nya sendiri yang mencoba meniru asli, alih-alih menciptakan pengikatan pada komponen asli yang sebenarnya, dalam gagasan portabilitas
ratchet freak

5
Saya bukan ahli dalam topik ini, tapi saya kira itu hanya masalah seberapa banyak upaya vendor alat GUI bersedia berinvestasi untuk mendapatkan semua detail yang tepat. Lihat, misalnya, kerangka C ++ "Qt" dan pertanyaan SO ini: stackoverflow.com/questions/7298441/…
Doc Brown

4
Ada banyak detail yang harus dijaga. Misalnya cara pelengkapan otomatis berfungsi dalam dialog buka file adalah satu titik di mana aplikasi java yang tampak asli mogok.
CodesInChaos

4
Swing memiliki tampilan dan nuansa "mirip aslinya" yang bisa Anda pasang bukan default. Juga, Java pertama kali mencoba menggunakan barang-barang asli yang tersedia dengan AWT tetapi tidak bekerja dengan baik, AFAIK karena perbedaan yang melekat antara platform. Itu sebabnya mereka membuat Swing, sehingga aplikasi Java bekerja persis sama di mana-mana.
marczellm

5
Jangan mengabaikan JavaFX. Ini adalah penggantian SWING dan berada di JDK / JRE secara default dimulai dengan Java 8. Ini jauh lebih modern daripada SWING dan AWT dan terlihat jauh lebih asli pada hampir semua platform (itu banyak kait ke toolkit UI asli pada masing-masing peron). Dengan itu, seperti yang disebutkan orang lain, untuk mendapatkan aplikasi yang tampak asli dari bahasa "satu ukuran untuk semua" seperti Java, Anda harus melakukan beberapa pekerjaan. UI Java dulu / dulu-masih-dimaksudkan untuk menjadi "paling cocok untuk semua platform" out-of-the-box.
SnakeDoc

Jawaban:


56

Bukankah ini hanya masalah mendesain tombol yang terlihat seperti tombol 'asli'?

Nah - semacam, untuk tombol. Tetapi ini mungkin lebih sulit dari yang Anda bayangkan. Saat ini grafik yang digunakan untuk merepresentasikan komponen GUI tidak sesederhana bitmap acak yang diregangkan (karena ini tidak berskala sangat baik) - grafis berbasis vektor dengan banyak kasus sudut diprogram ke dalamnya ( jadi ketika tombol mencapai tepi layar, itu mungkin terlihat sedikit berbeda, misalnya.) Dan tentu saja, Anda akan memerlukan grafik yang berbeda ketika sebuah tombol diklik. Untuk alasan hak cipta, pengembang sering tidak dapat hanya menggunakan grafik yang ada ini secara langsung, sehingga harus dibuat ulang - dan walaupun mereka melakukan pekerjaan yang baik untuk sebagian besar, pasti ada beberapa hal yang terlewatkan mengingat banyaknya komponen grafis di luar sana.

Saya mengatakan semua hal di atas berdasarkan Swing, yang tentu saja merupakan toolkit GUI non-pribumi yang ringan. Anda secara khusus menyebutkan SWT tidak mencari asli, yang agak aneh, karena SWT asli. Ini adalah toolkit yang menggunakan JNI di bawahnya untuk memanggil komponen asli - jadi jika sesuatu tidak terlihat di sana, itu tidak akan terjadi karena tampilan dan nuansa.


1
Terima kasih. Apa arti 'ringan' sebenarnya? Dan apa sebenarnya arti 'asli'? Saya menganggap itu berarti sesuatu yang menggunakan sumber daya dari OS komputer atau berinteraksi dengannya secara langsung. Apakah ini benar?
user3150201

1
@ user3150201 Tentu, jadi OS yang mendasarinya akan memiliki sejumlah tombol dan widget yang dapat ditempatkan secara asli, tetapi jelas tombol-tombol ini akan berbeda antara OS dan antara platform - ini adalah komponen asli kelas berat. Komponen ringan bukan komponen yang ditentukan oleh OS, mereka dibuat oleh Java (dalam hal ini) untuk terlihat dan berperilaku seperti komponen GUI - sehingga mereka dapat terlihat seperti yang Anda inginkan jika Anda memasukkan pekerjaan (tetapi Anda harus meniru platform terlihat dan terasa jika Anda menginginkannya, Anda tidak mendapatkannya secara gratis.)
berry120

14
Penempatan tombol, ukuran tepat, dan gaya GUI yang disukai bervariasi berdasarkan platform dan membuat Java untuk menirunya membutuhkan kerja. Swing dapat memberi Anda tombol asli tetapi jika tingginya 10 piksel, pengguna masih akan berpikir ada yang salah. Apple memiliki Panduan Antarmuka Manusia dan Microsoft memiliki Panduan Antarmuka Pengguna untuk membantu Anda mendapatkan tampilan asli yang benar. Anda perlu mengubah UI antar platform.
Michael Shopsin

4
JavaFX tampak jauh lebih "asli" daripada SWING dan AWT. Ini memiliki jendela transparan asli, dll. Jauh lebih modern terlihat out-of-the-box.
SnakeDoc

2
@SnakeDoc Tampaknya lebih modern, tentu, tapi saya tidak akan mengatakan itu tampak "asli" - tentu saja tidak menggunakan komponen GUI yang mendasari platform, semuanya dikuliti dalam CSS.
berry120

71

Ada setengah lusin toolkit yang dapat dianggap "asli" pada beberapa sistem. Beberapa di antaranya memiliki konsep atau kemampuan yang agak unik, dan mereplikasi mereka dalam toolkit lintas platform sangat membosankan. Tampilan & nuansa aplikasi tidak hanya ditentukan oleh "kulit", tetapi juga pada tata letak dan bagaimana perilakunya. Beberapa pertimbangan:

  • Dalam dialog, di sisi mana tombol "OK" berada - di sebelah kiri atau di kanan? Cukup adil, mari kita membangun dialog terpisah untuk setiap sistem.
  • Bagaimana kita menandai tombol default di layar? Pewarnaan warna, huruf tebal, memperbesar tombol? Cukup adil, mari kita letakkan itu di stylesheet.
  • Di Windows, konsep "Ribbon" agak asli. Bagaimana ini diterjemahkan ke Mac, di mana Ribbon tidak umum? Cukup adil, mari kita lupakan tata letak pixel-tepat dan menyediakan implementasi toolbar yang berbeda untuk setiap sistem.
  • Apakah bilah menu bagian dari jendela (Windows, opsional KDE), atau apakah ia duduk di bagian atas layar (Mac, Unity)? Cukup adil, mari kita tulis implementasi yang berbeda untuk setiap sistem, karena kita sudah membuang tata letak piksel-tepat
  • Bagaimana cara render font? Segunam mungkin, atau sehalus dan antialiasi? Dan font apa yang harus digunakan? Perhatikan bahwa font yang berbeda memiliki metrik yang berbeda, sehingga paragraf yang sama yang dirender dengan lebar yang sama mungkin memiliki jumlah baris yang berbeda tergantung pada font tersebut.
  • Apakah latar belakang jendela adalah warna tunggal, gambar, atau gradien? Mari kita letakkan itu juga di stylesheet.
  • Bagaimana tampilan scrollbar? Di mana tombolnya - jika ada? Seberapa lebar mereka, atau mereka hanya terungkap ketika pointer pindah ke wilayah tertentu?
  • Bagaimana kita memasukkan skema warna lain?
  • Apa yang diharapkan bisa diseret? Di mana menu konteks diharapkan?

Masalah-masalah ini tidak dapat diselesaikan melalui stylesheet sederhana ketika mereka menyentuh perilaku atau tata letak umum aplikasi. Satu-satunya solusi nyata adalah menulis ulang aplikasi untuk setiap sistem (sehingga mengabaikan manfaat lintas platform Java). Satu-satunya solusi realistis adalah melupakan tata letak tepat-pixel, dan menulis ke antarmuka umum yang abstrak di atas toolkit khusus sistem. Solusi yang diambil oleh Swing adalah meniru berbagai sistem, yang gagal secara spektakuler.

Dan kemudian ada konsistensi lintas-platform, gagasan bahwa aplikasi Anda dapat terlihat persis sama pada semua sistem (sering dipilih oleh gim, di mana ini meningkatkan perendaman). Pada aplikasi desktop, ini hanya mengganggu dan menghancurkan harapan pengguna.


1
+1. Hanya satu hal yang ingin saya tambahkan: Bagaimana dengan hal-hal yang dapat dikonfigurasikan oleh pengguna, mulai dari detail “sederhana” seperti bagaimana membuka menu konteks? (Dan saya lebih suka program windows untuk memiliki pita dan aplikasi Mac untuk tidak, terima kasih. Ya, GUI yang baik perlu dirancang per OS.)
Christopher Creutzig

@ChristopherCreutzig Dari situlah pengalaman saya berasal: Di desktop utama saya, saya menggunakan KDE di Linux (keduanya sangat bisa dikonfigurasi sendiri), dan menggunakan QtCurve untuk menyesuaikan tampilan aplikasi. Gaya khusus ini bekerja dengan baik di aplikasi-aplikasi utama KDE. Aplikasi GTK yang ditulis dengan baik dapat menggunakan lapisan kompatibilitas, tetapi gradien latar tidak ada, bilah menu tetap berada di dalam jendela dll. Tetapi kemudian dengan cepat mulai memburuk, dengan program mengambil beberapa widget dari gaya sistem (seperti bilah gulir) , tetapi mengabaikan yang lain (seperti rendering font, atau bayangan di sekitar menu)
amon

Memberi +1 karena ada beberapa poin kuat dalam jawaban ini, tetapi ada beberapa titik lemah juga. Masalah "bagaimana manajer jendela ini menggambar X" ditangani dengan menggunakan API asli. Misalnya, X11 pada OS X dapat menggambar jendela OS X asli, tombol, bilah gulir, dialog, dll. Jadi banyak masalah tersebut hilang. The nyata Jawabannya adalah apa yang dikatakan @TheSpooniest bawah: UX adalah jauh lebih dari sekedar menggambar widget. Jarak, waktu, animasi, akselerasi mouse, input sentuh ... ada dunia detail halus yang sangat mahal untuk diproduksi ulang dengan toolkit lintas platform.
Mark E. Haase

13

Ya, itu lebih dalam.

Membuat tombol yang terlihat seperti tombol Windows atau OS X itu mudah, ketika Anda hanya membangun tombol ini. Tetapi tombol harus "berperilaku" seperti yang asli, yang mungkin tidak mudah: mungkin ada lebih banyak ruang di satu versi yang tersedia, tetapi tidak di yang lain, mungkin warnanya lebih pas untuk desain Anda di versi Windows, dll.

Ini diuraikan saat Anda memiliki GUI secara keseluruhan: program OS X menyajikan kontennya berbeda dari program Windows. Ini hampir tidak mungkin untuk ditangkap dalam satu GUI - Anda akan membutuhkan dua GUI, tetapi tidak banyak aplikasi membuat banyak keributan. Sebaliknya mereka bertujuan untuk "terlihat oke di sebagian besar sistem" - ini masih terlihat agak asing, tetapi dapat digunakan dan lebih mudah untuk dikembangkan.


9

Tidak sulit untuk membuat tombol yang terlihat seperti tombol OSX, atau tombol Windows, atau toolkit lainnya. Tetapi pedoman UI untuk sebagian besar lingkungan tidak sesederhana dasar-dasar "ini seperti apa sebuah tombol." Ada banyak perbedaan yang lebih halus, dari jarak antara elemen UI ke urutan di mana tindakan terkenal tertentu akan muncul dalam daftar ke posisi yang tepat dari dialog Preferensi / Opsi dalam sistem menu. Satu dapat mengotomatiskan kasus yang paling umum untuk antarmuka pengguna yang sangat sederhana, tetapi banyak jika tidak sebagian besar tugas UI memerlukan sentuhan yang jauh lebih baik.

SWT mencoba mengotomatisasi ini sampai taraf tertentu, dan sekali lagi, ini cocok untuk tugas-tugas UI yang sederhana. Tetapi tidak ada solusi satu ukuran untuk semua, dan ketika UI menjadi lebih kompleks, metode dasar yang digunakannya mulai berantakan. Secara umum dimungkinkan untuk membawanya kembali sejalan dengan pekerjaan UI manual yang melelahkan, tetapi ini bukan sesuatu yang sebagian besar programmer mampu atau bersedia lakukan untuk semua platform.

Pendekatan Swing untuk ini adalah hanya menghindari toolkit asli bila memungkinkan. Ini bukan asli, dan tidak mencoba menjadi: sebaliknya, ia mencoba untuk membuat sesuatu yang akan terlihat (hampir) sama di mana pun itu dijalankan. Alih-alih mencoba (sia-sia) untuk menyenangkan semua orang, itu mencoba untuk menyenangkan dirinya sendiri, dan sementara itu berhasil sejauh yang berjalan, orang dapat mempertanyakan seberapa efektif hasilnya bagi komunitas pengguna yang lebih luas.


7

Ada pertukaran antara mengharapkan aplikasi Anda terlihat sealami mungkin pada setiap sistem dan mengharapkan aplikasi Anda bekerja dengan cara yang sama pada setiap sistem. Tidak ada pilihan "benar".

Selain itu, bahkan jika Anda memilih sisi "tampak alami", Anda mungkin ingin melindungi pengguna perangkat grafis Anda terhadap "peningkatan" pada komponen dan API asli yang mendasarinya yang mungkin merusak aplikasi mereka secara tak terduga.

Inilah sebabnya mengapa beberapa pengembang toolkit GUI lebih suka menyediakan komponen mereka sendiri yang meniru komponen asli, tetapi menyediakan implementasinya sendiri. Di sisi lain, mengembangkan perangkat GUI yang lengkap secara fungsional adalah upaya yang signifikan dan pertimbangan ekonomi dapat mengarah pada pemotongan beberapa keunggulan.

Perhatikan bahwa masalah ini tidak spesifik untuk Java, tetapi dihadapi oleh setiap perusahaan yang memproduksi perangkat platform independen.


Daripada diam-diam menurunkan suara Anda akan melakukan layanan yang lebih besar kepada komunitas dengan menjelaskan apa yang Anda rasa salah dengan jawaban. Kecuali itu hanya masalah pribadi ...
Nicola Musatti

4

Itu semua karena sejarah.

Sun berharap semua perangkat lunak Java bekerja sama di semua mesin.

Agar perangkat lunak “tampak asli”, ia harus bekerja sama dengan perangkat lunak lain pada OS yang diberikan.

Sun melakukan segala daya mereka untuk membuatnya sulit untuk menulis perangkat lunak Java yang terintegrasi dengan OS, karena setiap integrasi dengan OS akan membuat perangkat lunak bekerja secara berbeda pada setiap OS.

Saat ini sangat sedikit programmer Java yang peduli tentang apa pun selain perangkat lunak berbasis server web.

Sun membunuh Java di desktop dengan men-shafting semua programmer yang menggunakan sistem berbasis java Microsoft, karenanya membuat setiap programmer yang memilih Java pada hari-hari awal terlihat buruk.

Siapa pun yang menulis perangkat lunak desktop yang peduli tentang “tampak asli” telah lama belajar untuk tidak menggunakan Java dan pandangan mereka diperkuat setiap kali mereka menggunakan perangkat lunak Oracle apa pun.

Oleh karena itu hari ini tidak ada permintaan untuk "tampak asli" pada perangkat lunak desktop dari programmer Java.


5
"Sun melakukan segalanya dengan kekuatan mereka untuk membuatnya sulit untuk menulis perangkat lunak java yang terintegrasi dengan OS," salah. Mereka tidak berusaha keras untuk membuatnya mudah. "Sun membunuh Java di desktop dengan men-shafting semua programmer yang menggunakan sistem berbasis Java java" salah, permusuhan timbal balik antara Microsoft dan Sun menyebabkan Microsoft membuat versi perpustakaan AWT yang tidak kompatibel dengan persyaratan Sun, yang menyebabkan kejamnya. Tuntutan hukum Sun / MS.
jwenting

1
@jwenting, Sun lebih peduli tentang membuat masalah untuk Microsoft kemudian tentang programmer yang telah memilih untuk menggunakan sistem berbasis java Microsoft. Karenanya saya menyerah pada Jave dan terus menggunakan MFC sampai C # keluar.
Ian

3
mungkin beberapa orang di Sun, tetapi sentimen itu saling menguntungkan. Jika Anda mengembangkan secara eksklusif untuk platform tunggal, alat asli untuk platform itu SELALU merupakan pilihan yang lebih disukai, ini tidak ada hubungannya dengan politik perusahaan. Jika Anda memilih alat Anda berdasarkan "Saya benci Sun" atau "Saya benci Microsoft" yang mencerminkan sangat buruk pada sikap profesional Anda. Saya kebanyakan menggunakan Java, tetapi selain itu saya juga menggunakan Delphi, C #, Ruby, C ++, C, Progress, apa pun yang terbaik untuk pekerjaan yang ada. Dan lebih sering daripada tidak, yang akhirnya akan menjadi solusi hybrid.
jwenting

3

Apa yang Anda pikirkan nativesebenarnya adalah aplikasi asli yang melakukan hal mereka sendiri sementara toolkit seperti SWT mengikuti standar yang diterbitkan untuk UI OS tersebut. Masalahnya adalah bahwa tidak ada yang membuat aplikasi mengikuti standar-standar itu sehingga ketika Anda menjalankan aplikasi Java. Tampaknya bukan asli. Sebagai contoh, hampir semua proyek Microsoft (Office, Outlook, dll.) Tidak dapat direproduksi secara visual menggunakan kontrol standar Windows.

Ini akan menjadi lebih buruk karena Microsoft dan Apple menambahkan fitur UI dinamis ke platform OS mereka. Mengizinkan pengembang untuk membuat kulit / gaya aplikasi mereka dengan cara yang sama seperti desain web membuat gaya untuk situs web.

Java pada platform Android mengikuti jalur ini. Membuat elemen UI untuk Android didefinisikan dalam XML dengan gaya skinnable.

Java tidak pernah sangat populer sebagai platform desktop. Sebagai akibatnya, perubahan-perubahan dalam industri ini tidak merambat ke runtimes desktop. Tidak ada cukup pengembang yang mau menghabiskan waktu untuk memperbaiki masalah ini.


1
+1, di era Windows 95 ada tampilan 'standar' untuk kontrol Windows. Sekarang, tidak banyak.
GrandmasterB

Ya, sudah beberapa tahun sejak saya memprogram desktop tetapi saya terkejut bahwa .NET tidak mengirim dengan kontrol gaya pita meskipun itu menjadi bagian integral dari perangkat lunak produktivitas MS built.
Rig

@Rig Sejak NET 4.0 ada Ribbon Control asli yang baik di .NET. Berikut ini adalah artikel yang bagus: c-sharpcorner.com/UploadFile/0b73e1/ribbon-control-in-wpf-4-5
Christian Sauer

1
@Rig Anda akan membutuhkan .NET 4.5, bukan .NET 4. Visual Studio 2010 hanya dapat menargetkan hingga 4; Anda perlu VS2012 atau yang lebih baru untuk menargetkan 4.5. Saya bisa melihatnya ketika menargetkan 4,5 di VS2013, tetapi tidak ketika saya mengubah versi target menjadi 4.
Bob

1
@Rig Dimungkinkan untuk menggunakan Ribbon di Net 4.0 - Anda dapat mengunduhnya dari Microsoft dan kemudian akan muncul: 10rem.net/blog/2010/10/22/wpf-ribbon-october-release (Tidak yakin apakah ini adalah versi terbaru). Lebih baik unduh dari Nuget. Saya harus melakukan itu untuk program yang harus berjalan pada Windows XP - berfungsi dengan baik dan sebagian besar kompatibel dengan varian Net 4.5, sehingga Anda dapat merobek hal 4.0 ketika XP akhirnya pensiun.
Christian Sauer

-1

Yang sistem operasi yang Anda ingin terlihat "asli" juga?

Anda tidak bisa menjadi asli dari mereka semua 100% dari waktu.

SWT dll. Adalah pendekatan upaya terbaik untuk terlihat sebagai asli bagi mereka semua karena ketika Anda perlu mencapai beberapa kompromi .

Dan faktanya, kompromi ini mulai menjadi semakin sulit untuk dijangkau; bukan karena sistem operasi, tetapi karena perangkat input. Untuk layar sentuh, Anda sebenarnya harus mendesain secara berbeda, karena tidak ada tombol mouse kanan. Karena itu, Anda perlu mengakomodasi fungsi yang sama jika tidak.

Tidak akan pernah ada tombol ajaib yang memindahkan fungsionalitas "secara intuitif" dari tombol mouse kanan ke guestures, tanpa Anda menentukan setiap aspek terperinci untuk setiap perangkat input tunggal (pada titik itu, Anda adalah asli dari setiap platform yang Anda pertimbangkan, tetapi tetap saja tidak -native untuk setiap Anda tidak dianggap).


-2

Pertanyaan yang sangat bagus. Saya selalu bertanya-tanya tentang hal itu sendiri selama beberapa tahun berikutnya di masa lalu, saya pikir ada beberapa alasan yang sah di balik ini, tetapi sebenarnya tidak ada.

Saya pikir jawabannya agak sederhana, dan banyak jawaban tidak benar-benar menggali masalah ini.

Jika bahasa Anda memungkinkan untuk menggambar piexel di layar maka 100% memungkinkan untuk membuat kerangka kerja gui berdasarkan itu yang akan meniru kontrol bentuk Windows terlihat & terasa tepat.

Karena Java adalah crossplatform, maka sepenuhnya dimungkinkan untuk memastikan bahwa berdasarkan pada tipe sistem berjalan aktual (Mac / Windows) UI akan memilih untuk terlihat berbeda pada kedua platform, sesuai dengan gaya platform runtime.

Seperti yang Anda lihat di XAML misalnya UI dapat dengan mudah disajikan dalam bentuk dan bahasa yang sangat terstruktur. Memilih perilaku "asli" juga dimungkinkan jika waktu diambil untuk melakukan ini.

Jadi dimungkinkan untuk membuat kerangka kerja GUI yang memungkinkan pengembang Java mendapatkan aplikasi yang terlihat asli di Mac dan Windows.

Jadi kita sampai ke Swing, itu hanya satu kerangka GUI dari potensi tak terbatas kerangka GUI yang bisa dibuat untuk Java. Itu berperilaku bagaimana itu diprogram, yang tidak mengikuti proses di atas dan Anda mendapatkan aplikasi yang aneh di kedua sistem. Itulah pilihan yang dibuat oleh pengembang Swing, tidak ada yang memaksa mereka untuk melakukan ini dan berperilaku seperti itu.


2
ini tidak menjawab pertanyaan, penanya sudah membahas poin ini: "Ayunan mungkin telah dirancang dengan sengaja untuk memiliki tampilan yang khas"
nyamuk

Saya tidak setuju, tapi terima kasih telah berkomentar minus Anda (?)
Valentin Kuzub
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.