kalo LookAndFeel-nya spesifik pake SVG yg sama, lebih baik dijadiin static member aja.
Alternativenya
Dikonversi jadi binary (bisa pake binary builder).
Atau lebih mudahnya copy aja text SVG-nya jadiin string literal sebagai object const char*.
Kalo pake metode no.2 ada metode static di juce yang bisa parsing dari SVG string jadi Path, kemudian jadi DrawablePath. Jadi gak perlu manggil dari BinaryData.
Jadi kalo LookAndFeel-nya (berikut static member SVG-nya) bakal sering dipake di project lain, tinggal ditulis jadi juce module—lebih portable.
Ini soal project management aja sih. Nanti kalo skala projectnya semakin besar dan rumit, hal-hal seperti ini jadi signifikan dampaknya.
File yang disimpan di BinaryData kan dibuat oleh projucer. File seperti itu lebih cocok untuk asset spesifik project itu saja.
Object semacam LookAndFeel kan bisa dipakai ulang untuk berbagai macam aplikasi, mungkin bukan cuma untuk plugin. Jadi lebih baik jadi module. Nanti kalo kita update modulenya di salah satu project yang pakai, project yang lain akan ikut menyesuaikan.
Kalo LookAndFeel nya dipakai di berbagai project tapi manggil dari BinaryData, kita musti mastiin file yang dipanggil dari BinaryData udah kita ikut masukin di projucer. Ini jadi nambah dependency. Kalo gambar SVG banyak dan beragam, gampang banget cepat pusing LookAndFeel mana pake SVG yg mana. Terus begitu ada satu project yang pake diupdate (source code atau gambarnya nya berubah), kita musti mastiin BinaryData untuk setiap project di-rebuild pakai projucer. Horror.
Sorry jadi panjang biasanya jelasin gini lebih mudah pakai english haha