การฟื้นฟู GTK1 เผชิญปัญหาการ Build ข้ามแพลตฟอร์มแม้จะมีนักพัฒนาให้ความสนใจ

ทีมชุมชน BigGo
การฟื้นฟู GTK1 เผชิญปัญหาการ Build ข้ามแพลตฟอร์มแม้จะมีนักพัฒนาให้ความสนใจ

ความพยายามของ Robin Rowe ในการฟื้นฟู GTK1 ซึ่งเป็น GUI toolkit น้ำหนักเบาจากช่วงปลายทศวรรษ 1990 ได้ดึงดูดความสนใจจากนักพัฒนาที่กำลังมองหาทางเลือกอื่นจาก framework สมัยใหม่ที่มีขนาดใหญ่เกินไป อย่างไรก็ตาม ความพยายามในช่วงแรกในการ build toolkit ข้ามแพลตฟอร์มนี้เผยให้เห็นปัญหาเสถียรภาพที่สำคัญซึ่งเน้นย้ำถึงความท้าทายในการดูแลรักษา legacy software

ปัญหาการ Build รบกวนการใช้งานในช่วงแรก

สมาชิกชุมชนที่พытается compile GTK1 กำลังประสบกับข้อผิดพลาดที่แตกต่างกันบนแพลตฟอร์ม Windows, Mac และ Linux ประวัติ commit ของโปรเจกต์บ่งบอกว่ามีการเปลี่ยนแปลงโค้ดโดยไม่ได้ตรวจสอบให้แน่ใจว่า library สามารถ build ได้สำเร็จในทุกระบบที่รองรับ ความไม่เสถียรนี้เป็นที่น่ากังวลเป็นพิเศษสำหรับนักพัฒนาที่อาจต้องการใช้ GTK1 สำหรับแอปพลิเคชันในการผลิตหรือเพื่อดูแลรักษาซอฟต์แวร์ที่มีอยู่ซึ่งขึ้นอยู่กับ toolkit เดิม

ปัญหาการ build เกิดขึ้นบางส่วนจากเป้าหมายที่ทะเยอทะยานของ Rowe ในการรวม codebase ที่แยกจากกันสามส่วน - เวอร์ชัน Windows, Linux และ MacOS ที่ถูกดูแลรักษาโดยทีมต่างๆ มาหลายปี แม้ว่าการรวมรวมนี้จะสมเหตุสมผลจากมุมมองการดูแลรักษา แต่ก็สร้างความท้าทายในการรวมระบบที่ต้องได้รับการแก้ไขก่อนที่ toolkit จะใช้งานได้จริง

ข้อกำหนดการ Build ตามแพลตฟอร์ม:

Windows:

  • Visual Studio
  • CMake
  • Git Bash
  • libunistd

Linux (Ubuntu/Debian):

  • เครื่องมือ Build และ CMake ผ่าน apt-get

MacOS:

  • Xcode
  • CMake
  • ต้องการการกำหนดค่า path เพิ่มเติม

ข้อกังวลเรื่องความเข้ากันได้ของ API เริ่มปรากฏ

คำถามสำคัญที่ชุมชนยกขึ้นมาเน้นที่ความเข้ากันได้ทางไบนารีกับ GTK 1.2 เดิม นักพัฒนาที่มีแอปพลิเคชันหรือ patch สำหรับ toolkit คลาสสิกต้องการความมั่นใจว่า GTK1 จะทำงานเป็น drop-in replacement ได้ สมาชิกชุมชนบางคนได้ดูแลรักษา GTK 1.2 distribution ของตัวเองพร้อม patch และกำลังประเมินว่าการย้ายไปใช้การใช้งานใหม่นี้สมเหตุสมผลหรือไม่

คำถามเรื่องความเข้ากันได้กลายเป็นเรื่องซับซ้อนมากขึ้นเมื่อพิจารณาว่า GTK1 มีเป้าหมายที่จะเพิ่ม GTK2 API บางส่วนในขณะที่ยังคงรักษาลักษณะน้ำหนักเบาของเดิมไว้ วิธีการแบบไฮบริดนี้อาจให้เส้นทางการย้ายที่ง่ายขึ้นสำหรับแอปพลิเคชันบางตัว แต่ก็เสี่ยงที่จะสร้าง toolkit ที่ไม่ตอบสนองความต้องการ legacy หรือสมัยใหม่อย่างเต็มที่

ฟีเจอร์สมัยใหม่ เทียบกับ ข้อจำกัดของ Legacy

การอภิปรายเผยให้เห็นความตึงเครียดพื้นฐานระหว่างการรักษาความเรียบง่ายของ GTK1 และการแก้ไขข้อบกพร่องที่ชัดเจนตามมาตรฐานปัจจุบัน toolkit เดิมขาดการรองรับ Unicode และ font antialiasing ซึ่งเป็นฟีเจอร์ที่ยอมรับได้ในปี 1999 แต่รู้สึกล้าสมัยในตอนนี้ แม้ว่าจะมี patch เพื่อเพิ่มการรองรับ antialiasing แต่การใช้งานต้องการการ rebuild แอปพลิเคชันที่เกี่ยวข้องทั้งหมด

GTK1 น่าสนใจสำหรับผมเพราะจำเป็นต้องใช้ในการ build แอป retro ที่ผมชอบ CinePaint เป็นหนึ่งในนั้น และยังมีแอป GTK คลาสสิกอื่นๆ อีกหลายสิบตัว เหตุผลทางเทคนิคที่ต้องใส่ใจเรื่อง GTK1 คือขนาดของโค้ด GTK2 มีขนาดใหญ่กว่า GTK1 มาก GTK3 มีขนาดใหญ่กว่า GTK2 มาก

ข้อได้เปรียบด้านขนาดยังคงเป็นจุดขายที่แข็งแกร่งที่สุดของ GTK1 GTK เวอร์ชันสมัยใหม่มีความซับซ้อนและ dependency เพิ่มขึ้นอย่างมาก ทำให้ไม่เหมาะสำหรับระบบฝังตัว, static linking หรือสถานการณ์ที่การใช้ทรัพยากรน้อยที่สุดสำคัญกว่าฟีเจอร์ล้ำสมัย

การเปรียบเทียบขนาดของ GTK เวอร์ชันต่างๆ:

  • GTK 1.2 (1999): 168,000 บรรทัดของโค้ด
  • GTK 2.0 (2002): 460,000 บรรทัดของโค้ด
  • GTK 3.0+: มีขนาดใหญ่ขึ้นอย่างมากพร้อมกับการพึ่งพาไลบรารีเพิ่มเติม

ความท้าทายในการกระจายและดูแลรักษา

Linux distribution ส่วนใหญ่ในปัจจุบันไม่ได้ package GTK 1.2 อีกต่อไป โดยมี Slackware เป็นข้อยกเว้นที่น่าสังเกต สิ่งนี้สร้างปัญหาไก่กับไข่ที่นักพัฒนาที่สนใจแอปพลิเคชัน GTK1 ต้อง build toolkit จาก source ก่อน ซึ่งเพิ่มความยุ่งยากในการใช้งาน การขาดการรองรับการกระจายอย่างแพร่หลายยังหมายความว่าผู้ใช้งานสุดท้ายอาจประสบปัญหาในการรันแอปพลิเคชันที่ใช้ GTK1 โดยไม่ต้องมีขั้นตอนการตั้งค่าเพิ่มเติม

ความสำเร็จของโปรเจกต์จะขึ้นอยู่กับการแก้ไขปัญหาการ build ปัจจุบันและการสร้างกระบวนการ release ที่เสถียร หากไม่มีการ build ที่เชื่อถือได้ในทั้งสามแพลตฟอร์มหลัก GTK1 เสี่ยงที่จะยังคงเป็นเพียงความอยากรู้อยากเห็นมากกว่าที่จะกลายเป็นเครื่องมือที่ใช้งานได้จริงสำหรับนักพัฒนาที่ต้องการโซลูชัน GUI น้ำหนักเบาอย่างแท้จริง

ในตอนนี้ นักพัฒนาที่สนใจ GTK1 ควรคาดหวังว่าจะประสบปัญหาการ compilation และเตรียมพร้อมที่จะมีส่วนร่วมในการแก้ไขมากกว่าการใช้ toolkit เพียงอย่างเดียว โปรเจกต์แสดงให้เห็นความหวังสำหรับกรณีการใช้งานเฉพาะ แต่ต้องการงานพัฒนาเพิ่มเติมก่อนที่จะสามารถทำหน้าที่เป็นพื้นฐานที่เชื่อถือได้สำหรับแอปพลิเคชันใหม่หรือเป็นโซลูชันการดูแลรักษาสำหรับ legacy software

อ้างอิง: GTK1 Cross-Platform GUI Toolkit