Sejauh ini semua program kita berjalan dari atas ke bawah: kita mengeksekusi script, MATLAB memproses baris demi baris, lalu program berakhir. Graphical User Interface (GUI) membalik model ini — app kita tidak tahu kapan pengguna akan menekan tombol, mengisi field, atau menggeser slider. Program GUI justru menghabiskan sebagian besar waktunya menunggu, lalu bereaksi hanya pada momen tertentu. Bab ini membangun fondasi konsep sebelum kita menyentuh App Designer: event, komponen sebagai objek, callback, dan peta teknologi GUI di MATLAB. Cakupannya:

  • model event-driven: event loop, antrean, dan dispatch ke callback
  • komponen antarmuka sebagai objek dengan properti
  • perbandingan GUIDE, uicontrol, uifigure, App Designer, dan Live Script controls
  • arsitektur dasar sebuah app: komponen + state + callback

GUI adalah Program Event-Driven #

Aturannya: program GUI tidak berjalan lurus, melainkan reaktif. Pengguna menghasilkan event (klik, ketikan, perubahan nilai), MATLAB menyimpan event itu, lalu memanggil fungsi yang telah didaftarkan untuk event tersebut — fungsi itulah callback. Mekanisme di balik layar: saat jendela app tampil, MATLAB memasuki event loop internal — loop yang terus memeriksa antrean event sistem operasi, mengubah event menjadi pemanggilan callback, lalu kembali menunggu. Kode yang kita tulis tidak pernah dipanggil secara berurutan oleh kita; kode kita dipanggil oleh event loop.

Alur satu klik tombol diperlihatkan diagram berikut:

Diagram tersebut menunjukkan satu siklus penting: setelah callback selesai, kendali kembali ke event loop — app kembali idle dan siap menerima event berikutnya. Hubungan aksi pengguna dengan callback dipetakan lewat callback property milik komponen:

Aksi penggunaEventCallback property
Menekan ButtonButtonPushedButtonPushedFcn
Mengubah isi EditFieldValueChangedValueChangedFcn
Memilih item DropDownValueChangedValueChangedFcn
Menutup jendela UIFigure—CloseRequestFcn

Komponen adalah Objek #

Komponen antarmuka — tombol, kolom teks, axes — adalah objek MATLAB lengkap dengan properti dan method. Kita membuat komponen dengan fungsi pembuatnya, menyimpan handle yang dikembalikan, lalu membaca atau menulis propertinya dengan dot notation — persis pola class yang sudah kita kuasai di bagian OOP. Contoh programatik minimal versi modern (uifigure + uibutton):

matlab
fig = uifigure;
btn = uibutton(fig, ...
    "Text", "Mulai Analisis", ...
    "ButtonPushedFcn", @(src, event) mulaiAnalisis());

Ketika kode di atas dieksekusi di desktop MATLAB, jendela kosong tampil berisi satu tombol bertuliskan Mulai Analisis; setiap penekanan tombol memicu event loop memanggil fungsi mulaiAnalisis(). Properti penting yang akan sering kita set: Text (tulisan), Value (nilai/kondisi), Items (daftar pilihan), Limits (batas angka), Position (letak dan ukuran dalam piksel). Parent komponen (figure, panel, atau grid layout) menentukan di mana komponen itu hidup — menghapus parent ikut menghapus komponen di dalamnya, sama seperti relasi handle class yang sudah kita bahas.

Empat Jalur Membuat GUI di MATLAB #

MATLAB punya riwayat panjang, sehingga ada beberapa teknologi GUI yang hidup berdampingan. Tabel berikut memetakan statusnya per R2026b:

TeknologiDiperkenalkanStatus saat iniKapan dipakai
GUIDE (guide)lamadeprecated, lingkungan desainnya telah dihapushanya membaca/migrasi app lama
figure + uicontrolklasikmasih berfungsi, tidak dikembangkan lagimemelihara kode lama; app sederhana programatik
uifigure + UI componentsR2016ajalur modern programatikapp yang dibangun 100% lewat kode
App DesignerR2016ajalur utama resmi, drag-drop visualhampir semua app baru
Live Script controlsbertahapkontrol interaktif di dokumenparameter kecil dalam analisis, bukan aplikasi

Dua baris teratas adalah warisan sejarah: MathWorks telah memindahkan seluruh pengembangan ke keluarga uifigure dan App Designer, dan app GUIDE lama didorong bermigrasi. Pilihan praktis kita sepanjang bab ini: App Designer untuk membangun app secara visual, dan uifigure programatik ketika kita ingin memahami atau mengotomatisasi pembentukan UI lewat kode — dua-duanya menghasilkan jenis objek yang sama.

Arsitektur Sebuah App #

Sebelum menulis kode, mari kita tetapkan tiga bagian yang membentuk setiap app — pemisahan yang sama dengan pola model–view:

  1. Komponen — objek antarmuka yang dilihat pengguna: UIFigure, Button, EditField, UIAxes, beserta properti tampilannya.
  2. State — data yang hidup selama app berjalan (nama berkas, hasil hitungan, jumlah klik), disimpan di properti app.
  3. Callback — fungsi yang menghubungkan keduanya: membaca komponen, memproses state, lalu memperbarui komponen lain.

Event loop-nya sendiri bisa kita simulasikan sebagai fungsi murni — intinya hanya antrean event, satu loop, dan dispatch berdasarkan tipe event. Inilah isi contoh.m di folder chapter ini:

matlab
antrean = [ ...
    buatEvent('klik_tombol', 'Hitung', ''), ...
    buatEvent('ubah_nilai',  'InputSuhu', 'tiga puluh satu'), ...
    buatEvent('ubah_nilai',  'InputSuhu', '31'), ...
    buatEvent('klik_tombol', 'Hitung', ''), ...
    buatEvent('klik_tombol', 'Reset', ''), ...
    buatEvent('tutup_jendela', 'UIFigure', '')];

state = struct('jumlahKlik', 0, 'suhu', NaN, 'pesan', 'app siap');

fprintf('Event loop mulai: %d event menunggu\n', numel(antrean));
for k = 1:numel(antrean)
    evt = antrean(k);
    fprintf('event %d: tipe=%-12s sumber=%s\n', k, evt.tipe, evt.sumber);
    state = dispatchEvent(evt, state);
end
fprintf('Event loop selesai\n');

Mari kita bedah baris-baris kode di atas:

  1. Baris 1-7 (antrean = [...]): enam event disusun sebagai struct array — padanan antrean event yang diisi oleh aksi pengguna di GUI asli; setiap record memuat tipe (jenis event), sumber (komponen asal), dan data (muatan event).
  2. Baris 9 (state = struct(...)): state app dibuat sekali di awal — padanan properti app yang bertahan selama app berjalan.
  3. Baris 12-17 (for k = ...): loop pengambilan event — padanan event loop MATLAB yang memproses antrean satu per satu; dispatchEvent() berperan sebagai pemilih callback.
  4. Baris 4 dan 5 (event ubah_nilai): satu event sengaja berisi teks "tiga puluh satu" untuk menguji bahwa handler menolak input yang tidak valid — perilaku yang sama dengan validasi callback di bab berikutnya.

Output yang Dihasilkan:

text
Event loop mulai: 6 event menunggu
event 1: tipe=klik_tombol  sumber=Hitung
    handler Hitung: klik ke-1, pesan="belum ada suhu untuk dihitung"
event 2: tipe=ubah_nilai   sumber=InputSuhu
    handler ubah_nilai: "tiga puluh satu" bukan angka, ditolak
event 3: tipe=ubah_nilai   sumber=InputSuhu
    handler ubah_nilai: suhu tersimpan=31
event 4: tipe=klik_tombol  sumber=Hitung
    handler Hitung: klik ke-2, pesan="suhu 31 siap dianalisis"
event 5: tipe=klik_tombol  sumber=Reset
    handler Reset: state dikembalikan ke awal
event 6: tipe=tutup_jendela sumber=UIFigure
    handler tutup_jendela: state disimpan, jendela ditutup
Event loop selesai
state akhir: jumlahKlik=0 suhu=NaN pesan=app ditutup pengguna

Perhatikan tiga perilaku event-driven yang muncul di output: handler Hitung yang pertama menolak jalan karena suhu masih NaN (state belum siap), event ubah_nilai yang tidak valid diabaikan tanpa menghancurkan loop, dan event Reset yang mengembalikan state awal — semuanya adalah skenario yang persis sama kita tangani dengan callback di app sungguhan.

Ringkasan #

GUI MATLAB adalah program event-driven: event loop MATLAB menunggu event pengguna, lalu mendispatchnya ke callback yang terdaftar pada callback property (ButtonPushedFcn, ValueChangedFcn). Komponen adalah objek dengan properti (Text, Value, Items, Limits) yang dibuat dari uifigure dan dikelola lewat dot notation. Untuk app baru, pilihan jalurnya dua: App Designer (visual, drag-drop) atau uifigure programatik (100% kode) — keduanya modern sejak R2016a, sementara GUIDE dan uicontrol tinggal warisan yang harus kita kenali, bukan tiru. Arsitektur app terdiri dari komponen, state, dan callback; karena GUI-nya sendiri MATLAB-only, logika loop-dispatch-handler kita isolasi di contoh.m dan teruji penuh.