เจาะลึก GTK4: เลิกแก้ Widget ทีละแถวด้วย GListModel และ ListView
เรียนรู้วิธีจัดการรายการข้อมูลใน GTK4 ด้วย GListModel และ ListView แยกข้อมูลออกจาก UI อย่างเด็ดขาด พร้อมไขข้อข้องใจเมื่อไหร่ควรใช้ GtkListBox
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- บทความตอนที่ 3 ของคู่มือ GTK Widgets เจาะลึกการสร้างและจัดการรายการข้อมูล
- เปลี่ยนจากการเพิ่ม-ลบแถวด้วยมือ มาเป็นการจัดการผ่าน GListModel และ GtkListView
- อธิบายความแตกต่างระหว่างการใช้ GListModel สำหรับข้อมูลไดนามิกและ GtkListBox สำหรับรายการสั้นๆ
บทความนี้เป็นตอนที่สามในชุด A Field Guide to GTK Widgets ซึ่งมุ่งเน้นการเลือกใช้วิดเจต์ให้ถูกจังหวะและรับมือกับปัญหาที่มักพบเจอ โดยข้ามมาพูดถึงเรื่องรายการ (lists) ก่อนเรื่องเลย์アウトและการนำทาง เนื่องจากเอกสารอ้างอิงทางการมักอธิบายส่วนนี้ได้ไม่เคลียร์นัก โค้ดทั้งหมดในบทความนี้มีตัวอย่างที่ใช้งานจริงในคลังโค้ดประกอบ
สมมติว่าคุณกำลังแสดงรายการงาน (tasks) วิธีที่ง่ายที่สุดโดยไม่ต้องอ่านเอกสารเลยคือการใช้ลูปวนเพิ่มข้อมูลเข้าไปตรงๆ แต่เมื่อสถานการณ์เปลี่ยน เช่น งานชิ้นหนึ่งถูกทำเครื่องหมายว่าเสร็จแล้ว รายการจะต้องจัดเรียงใหม่เพื่อให้งานที่เสร็จแล้วตกลงไปด้านล่าง หรือเมื่อมีปุ่มสลับ "แสดงรายการที่เสร็จแล้ว" เพื่อกรองแถวเข้าออก แนวทางแบบเดิมจะบังคับให้คุณต้องคอยแก้ไของค์ประกอบวิดเจต์ด้วยตัวเอง ค้นหาแถว ลบออก สร้างใหม่ และแทรกกลับเข้าไปให้ถูกลำดับ ซึ่งมักจะพังไม่เป็นท่าหลังจากเขียนโค้ดไปได้สามสัปดาห์
นี่คือปัญหาหลักที่ GTK4 ได้ทำการออกแบบสถาปัตยกรรมใหม่เพื่อแก้ไข โดยในเวอร์ชันเก่า GTK เคยใช้ GtkTreeView, GtkListStore และ cell renderers ซึ่งปัจจุบันถูกเลิกใช้งานไปแล้ว แนวคิดสมัยใหม่จึงสลับความสัมพันธ์ใหม่ แทนที่คุณจะต้องคอยแก้ไขต้นไม้วิดเจต์ด้วยมือ ให้เก็บข้อมูลไว้ใน list model ที่ใช้โครงสร้างอินเทอร์เฟซ GListModel และปล่อยให้มุมมอง (view) เป็นฝ่ายคอยเฝ้าระวังข้อมูลแทน
GListModel ไม่ใช่วิดเจต์ แต่เป็นอินเทอร์เฟซที่วัตถุ GObject ใดๆ สามารถนำไปใช้เพื่อบอกว่า "ฉันคือชุดข้อมูลที่มีลำดับและเข้าถึงได้ด้วยดัชนี และฉันจะแจ้งเตือนเมื่อมีการเปลี่ยนแปลง" โดยคลาสรูปธรรมที่คุณจะได้ใช้งานบ่อยคือ GListStore ซึ่งเป็นโมเดลรายการในหน่วยความจำแบบปรับเปลี่ยนได้
"describe the relationship between data and widget once, and let the toolkit run it."
เมื่อข้อมูลและมุมมองถูกแยกออกจากกันอย่างแท้จริง โครงสร้างไฟล์โค้ดก็ควรสะท้อนสิ่งนั้น โดยแบ่งออกเป็นไฟล์สำหรับจัดการข้อมูล ไฟล์สำหรับแปลงข้อมูลเป็นแถว และไฟล์หลักสำหรับเชื่อมโยงทั้งสองเข้าด้วยกัน จุดสำคัญคือโค้ดส่วนจัดการข้อมูลจะไม่นำเข้า (import) ไลบรารี GTK เลย เพราะข้อมูลก็คือข้อมูล
การเปลี่ยนผ่านสถาปัตยกรรมมาใช้ GListModel และ ListView ใน GTK4 สะท้อนรูปแบบการพัฒนาซอฟต์แวร์สมัยใหม่ที่แยกส่วนข้อมูล (Model) ออกจากหน้าจอ (View) อย่างเด็ดขาด ช่วยลดความซับซ้อนในการซิงก์สถานะ UI เมื่อข้อมูลเบื้องหลังเปลี่ยนไป ทำให้แอปพลิเคชันมีความเสถียรและดูแลรักษาง่ายขึ้นในระยะยาว
อย่างไรก็ตาม ไม่ได้หมายความว่า GtkListBox จะถูกเลิกใช้งานไปทั้งหมด GtkListBox ยังคงเป็นเครื่องมือที่ถูกต้องสำหรับการแสดงรายการสั้นๆ ที่แทบไม่เปลี่ยนแปลง เช่น หน้าการตั้งค่า หรือตัวเลือกแบบเรดิโอปุ่ม ส่วนการตัดสินใจเลือกใช้งานจึงขึ้นอยู่กับขนาดและความผันผวนของข้อมูลเป็นหลัก
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น