เหตุใดแอปเดสก์ท็อปที่เขียนด้วย Qt ไม่มากขึ้น [ปิด]

202

เท่าที่ฉันรู้และเข้าใจในประสบการณ์ของฉันกับ Qt มันเป็นห้องสมุดที่ดีและง่ายต่อการเรียนรู้ มันมี API ที่ออกแบบมาเป็นอย่างดีและข้ามแพลตฟอร์มและนี่เป็นเพียงสองคุณสมบัติที่ทำให้มันน่าสนใจ ฉันสนใจที่จะรู้ว่าทำไมโปรแกรมเมอร์มากขึ้นจึงไม่ใช้ Qt มีข้อบกพร่องที่พูดกับมันหรือไม่? ฟีเจอร์ใดที่ทำให้ไลบรารี่อื่นดีกว่า Qt ปัญหาเกี่ยวข้องกับการออกใบอนุญาตหรือไม่

api  libraries  qt 
— Dehumanizer
แหล่งที่มา
60
มันเป็นภาษา C ++ นักพัฒนาส่วนใหญ่ต้องการภาษาระดับสูงกว่าเช่น C #
— user16764
15
ดาบสองคมของความเข้ากันได้แบบย้อนหลังทำให้ Qt มีความผิดปกติหลายอย่างข้อบกพร่องที่ไม่สามารถแก้ไขได้และพฤติกรรมที่ไม่ดีอื่น ๆ
— edA-qa mort-ora-y
26
@ user16764: "ส่วนใหญ่"
— การแข่งขัน Lightness ใน Orbit
17
ฉันไม่คิดว่าดัชนี TIOBE เป็นวิธีการวัดที่แม่นยำจริงๆเพราะเป็นการวัดความนิยมที่ไม่ได้ใช้ การเปรียบเทียบจำนวนโค้ดในแหล่งเก็บข้อมูลโอเพ่นซอร์สเช่น GitHub, Bitbucket, Codeplex และ Sourceforge จะให้การวัดที่แม่นยำยิ่งขึ้น (และผมเชื่อว่าผู้การวัดที่แม่นยำมากขึ้นใส่ C และ C ++ ใน # 1 และ # 2 จุด - Java มีข้อได้เปรียบที่ไม่เป็นธรรมในดัชนี TIOBE เพราะมันใช้สำหรับหลักสูตรน้องวิทยาลัยและเขียนโปรแกรมใหม่ให้ฉวัดเฉวียนมากขึ้นกว่าคนที่มีประสบการณ์ทำ)
— Billy ONeal
12
@Giorgio: เอ่อคุณต้องคิดเกี่ยวกับเรื่องนี้ใน C # แนวคิดของ "ผู้ที่เป็นเจ้าของสิ่งนี้" ยิ่งไปกว่านั้น "ใครเรียกdelete" ความจริงที่ว่าพอยน์เตอร์อัจฉริยะทำให้ชัดเจนนั้นไม่ใช่ภาษาที่ล้มเหลว และถ้าคุณไม่คิดเกี่ยวกับสิ่งต่าง ๆ คุณจะสร้างขยะในภาษาระดับสูง ๆ ที่ฉันเคยเห็นด้วย
— Billy ONeal

คำตอบ:

177

ฉันไม่ได้ตั้งใจให้สิ่งนี้เป็นคำตอบที่ดี แต่นี่คือเหตุผลที่ฉันไม่ได้ใช้ Qt เป็นการส่วนตัว มีหลายสิ่งที่ดีที่จะพูดเกี่ยวกับเรื่องนี้คือ API ทำงานได้เกือบตลอดเวลาและสามารถเชื่อมโยงแพลตฟอร์มได้อย่างราบรื่น แต่ฉันไม่ได้ใช้ Qt เพราะ:

  1. ในบางกรณีมันดูไม่เหมือนโปรแกรมเนทีฟ การออกแบบ UI เดียวสำหรับทุกแพลตฟอร์มโดยเนื้อแท้จะไม่ถูกต้องเมื่อย้ายจากเครื่องไปยังเครื่อง ตัวอย่างเช่นบนเครื่อง Mac แถบแยกมักจะค่อนข้างหนาและปุ่มมีขนาดเล็กและปัดด้วยไอคอน บนเครื่อง Windows แถบแยกจะแคบและปุ่มมีข้อความมากกว่าเดิมและมีการออกแบบสี่เหลี่ยมจัตุรัสมากขึ้น เพียงเพราะคุณสามารถเขียนหนึ่ง UI สำหรับทุกแพลตฟอร์มไม่ได้หมายความว่าคุณควรสำหรับแอปพลิเคชันส่วนใหญ่
  2. Qt ไม่ใช่ไลบรารี C ++ มันต้องมีขั้นตอนการรวบรวมแยกต่างหากซึ่งทำให้กระบวนการสร้างมีความซับซ้อนมากขึ้นเมื่อเทียบกับห้องสมุดอื่นส่วนใหญ่
  3. จาก (2), C ++ IDEs และเครื่องมือสามารถแฟล็กนิพจน์ Qt เป็นข้อผิดพลาดเนื่องจากไม่เข้าใจข้อมูลจำเพาะของ Qt นี้เกือบกองกำลังใช้ QtCreator vimหรือต้นฉบับเดิมเพียงแก้ไขเช่น
  4. Qt เป็นแหล่งข้อมูลจำนวนมากซึ่งจะต้องมีอยู่และติดตั้งล่วงหน้าในเครื่องที่คุณใช้ก่อนที่จะรวบรวม สิ่งนี้สามารถทำให้การตั้งค่าสภาพแวดล้อมการสร้างน่าเบื่อมากขึ้น
  5. สามารถใช้งานได้ภายใต้ LGPL เท่านั้นซึ่งทำให้ยากต่อการใช้การปรับใช้แบบไบนารีเดียวเมื่อต้องการเผยแพร่ภายใต้สิทธิ์การใช้งานที่ จำกัด หรือมีข้อ จำกัด น้อยกว่า
  6. มันสร้างไบนารีที่รวบรวมได้ขนาดใหญ่มากเมื่อเปรียบเทียบกับแอปพลิเคชันดั้งเดิม "ol ol 'ที่เขียนในทำนองเดียวกัน" (ยกเว้นแอปพลิเคชันของหลักสูตรที่เขียนสำหรับ KDE)
— บิลลี่ออน
แหล่งที่มา
11
@Dehumanizer: มีใบอนุญาต LGPL และมีใบอนุญาตการค้า ใบอนุญาตการค้าคือหลายพันดอลลาร์ในส่วนของผู้รับอนุญาตและไม่อนุญาตให้แจกจ่ายซ้ำเป็นต้นสำหรับโครงการโอเพ่นซอร์สภายใต้ใบอนุญาตเสรีเช่น BSD, MIT หรือ Boost ซึ่งผู้เขียนไม่ได้ทำเงินมากมายและพวกเขาต้องการ เพื่อปล่อยรหัสของพวกเขาภายใต้ใบอนุญาตเสรีนิยมการพึ่งพา LGPL นั้นไม่สมเหตุสมผล แต่โดยทั่วไปแล้วนักพัฒนาที่มีปัญหาไม่สามารถจ่ายใบอนุญาตเชิงพาณิชย์ได้
— Billy ONeal
27
# 6 เป็นเหตุผลที่ดีที่สุดที่ฉันหลีกเลี่ยง ฉันหมายถึงฉันไม่ต้องการโปรแกรมที่ยิ่งใหญ่และไม่ชอบและฉันไม่ชอบที่จะผูกพันกับใบอนุญาตเฉพาะ แต่จริงๆแล้วมันขาดความเป็นเจ้าของที่ดูดีและให้ความรู้สึกที่ดีสำหรับฉัน OSX และ Windows รุ่นล่าสุดได้ทำผลงานที่ยอดเยี่ยมในการทำให้อินเตอร์เฟสดั้งเดิมของพวกเขานั้นสวยเร็วและใช้งานได้และฉันอยากจะยกระดับการทำงานทั้งหมดที่พวกเขาทำเพื่อฉันมาแล้ว ฉันพบว่าโปรแกรมหลายรายการที่ไม่มีรูปลักษณ์ดั้งเดิมรู้สึกราคาถูกและแฮ็คมาให้ฉัน (ไม่เสมอไป
— Greg Jackson
16
หมายเลข 6 ของคุณควรจะได้รับจำนวน 1 นี้โดยให้ห่างไกลปัญหาที่ใหญ่ที่สุดกับ Qt ในหลายกรณีมันไม่ได้ใช้ API ดั้งเดิม ฉันชอบซอฟต์แวร์ของฉันที่จะดูพื้นเมือง ผู้ใช้เช่นนั้นเช่นกัน ฉันไม่เคยเห็นแอปพลิเคชัน Mac ที่สร้างขึ้นด้วย Qt ที่ดูเหมือนแอปพลิเคชัน Mac ไม่มีผู้ใช้ Mac คนอื่นและพวกเขาก็มักจะชอบอะไรแบบนั้น คุณสูญเสียประโยชน์ทั้งหมดจากการเป็น "ข้ามแพลตฟอร์ม" หากคุณใช้เพื่อสร้างแอปพลิเคชั่น Linux ซึ่งเกี่ยวกับสถานที่เดียวที่ดูเป็นเจ้าของเพราะไม่มีอะไรเป็นของพื้นเมือง
— Cody Gray
41
ยกเว้นปัญหาของรูปลักษณ์ 'ดั้งเดิม' จะไม่อยู่ที่นั่นอีกต่อไป ความสอดคล้องแบบเก่าของแอพ Windows ตอนนี้กลายเป็นเรื่องแปลกใหม่สำหรับ blobs, glows และภาพเคลื่อนไหว WPF และ Silverlight ที่เป็นเอกลักษณ์ ดูที่ Office หรือแผงควบคุมของ Windows 7 เพื่อดูว่าผลิตภัณฑ์เรือธงของ MSs มี GUI ที่ไม่สอดคล้องกันในทุกวันนี้ ผู้ใช้ Mac - ดีคุณมีจุดที่ถูกต้องมาก
— gbjbaanb
5
@TrevorBoydSmith: ขออภัย แต่คุณผิด Qt เป็นเฟรมเวิร์กเดียวที่ใช้การประมวลผลล่วงหน้า ระยะเวลา ตรวจสอบ GNOME, FLTK, WX และเพื่อน ๆ และแสดงขั้นตอนก่อนการประมวลผลให้ฉันดู คุณจะไม่พบ บางไลบรารีอื่น ๆ มาพร้อมกับระบบการสร้างที่แตกต่างกัน แต่ในตอนท้ายของวันพวกเขาเป็นห้องสมุด C ++ ซึ่งสามารถสร้างโดยคอมไพเลอร์ C ++ ใด ๆ สำหรับ "Raw win32 ไม่ได้อยู่ในเหตุผลของฉัน" มันมีอยู่ในเหตุผลของฉันเป็น # 5 และ # 6
— Billy ONeal
115

อย่างที่ผู้คนพูดว่าแต่ละเครื่องมือเหมาะสมกับแต่ละปัญหาและสถานการณ์ ...

แต่ถ้าคุณเป็นโปรแกรมเมอร์ C ++ Qt คือกรอบงานของคุณ ไม่มีคู่แข่ง

เราพัฒนาแอพพลิเคชั่นทางการแพทย์เชิงภาพทางการแพทย์ที่ซับซ้อนและ Qt ยังคงดำเนินต่อไป

ฉันไม่ได้บอกว่า 'ข้อเสีย' ที่ผู้คนพูดถึงมันเป็นเรื่องจริง แต่ฉันรู้สึกว่าพวกเขาไม่ได้ลอง Qt มาเป็นเวลานาน (มันปรับปรุงอย่างต่อเนื่องในเวอร์ชั่นใหม่แต่ละครั้ง ... ) และส่วนใหญ่ ปัญหาทั้งหมดที่พวกเขาแสดงความคิดเห็นไม่ใช่ปัญหาหากคุณดูแล

ความไม่ลงรอยกันของแพลตฟอร์ม UI: เฉพาะเมื่อคุณใช้วิดเจ็ต UI 'เหมือนที่เป็นอยู่' โดยไม่มีการปรับแต่งหรือกำหนดเอง

ตัวประมวลผลล่วงหน้าเกินพิกัด Qt: เฉพาะในกรณีที่คุณใช้กลไกช่องสัญญาณหรือการสืบทอด QObject เมื่อคุณไม่ต้องการจริงๆ

อย่างไรก็ตามเรายังคงเขียนแอปพลิเคชันใน C # .NET และดำเนินการเป็นเวลานาน ดังนั้นฉันคิดว่าฉันมีมุมมองที่ enouch

อย่างที่ฉันพูดเครื่องมือแต่ละอย่างสำหรับแต่ละสถานการณ์

แต่ Qt นั้นไม่ต้องสงสัยเลยว่าเป็นกรอบงานที่สอดคล้องและมีประโยชน์

— Inigo
แหล่งที่มา
9
+1 Thaks! ฉันแค่อยากจะเขียนเหมือนกัน เรื่องไร้สาระที่สุดคือ "ไม่ใช่โอเพนซอร์ส / การโต้แย้งเชิงพาณิชย์" น่าประหลาดใจที่มีคนจำนวนมากเข้าใจคำว่าโอเพนซอร์ส Qt เป็นโอเพ่นซอร์สตั้งแต่ฉันใช้ (1.4) และเคยมีใบอนุญาตที่ยุติธรรมที่สุด: หารายได้กับ Qt -> จ่าย
— Valentin Heinitz
16
โอ้และผมไม่สนใจเกี่ยวกับการเพิ่มกำลัง 10 MB ถึงแอพลิเคชันที่มี 50 MB ของศิลปะและ 200 เมกะไบต์ของบทเรียนวิดีโอและข้อมูล :)
— ПетърПетров
9
วันนี้พื้นที่ที่จำเป็นสำหรับ Qt ราคาถูก
— trusktr
5
สิ่งนี้ค่อนข้างตรงกับประสบการณ์ของฉันกับ Qt (เฟรมเวิร์กวิดเจ็ตฉันไม่ได้ใช้ QML / QtQuick สำหรับสิ่งที่ร้ายแรงจนถึงตอนนี้) เหมาะที่จะเขียนแอปพลิเคชันขนาดใหญ่ที่มีข้อกำหนด UI ที่ซับซ้อน เมื่อคุณเรียนรู้แล้วคุณจะมีประสิทธิผลมาก ข้อเสียที่กล่าวถึง (ขั้นตอนการรวบรวมแยกต่างหากสำหรับไฟล์ moc ing, ui ฯลฯ ) ไม่ใช่ปัญหาหากระบบบิลด์ถูกตั้งค่าอย่างเหมาะสม ฉันสามารถแนะนำ qmake หรือ cmake
— Nils
จาก Qt 5.8 หลังจากนั้นมีโปรเจ็กต์ชื่อ Qt Lite ซึ่งย่อขนาด Qt ให้ต่ำสุดสำหรับความต้องการเฉพาะของคุณ นี่เป็นคุณลักษณะเชิงพาณิชย์;)
— SMMousavi
36

ในทุกสิ่งที่ฉันไม่ชอบเกี่ยวกับ Qt ความจริงที่ว่ามันเล่นได้ไม่ดีกับเทมเพลตทำให้ฉันเป็นบ้าที่สุด คุณทำสิ่งนี้ไม่ได้:

template < typename T >
struct templated_widget : QWidget
{
  Q_OBJECT;

public signals:
  void something_happened(T);
};

มันยังเล่นได้ไม่ดีกับพรีโปรเซสเซอร์ คุณทำสิ่งนี้ไม่ได้:

#define CREATE_WIDGET(name,type) \
struct name ## _widget : QWidget \
{ \
  Q_OBJECT; \
\
public signals: \
  void something_happened(type); \
}

เมื่อผสมกับความจริงที่ว่าทุกอย่างที่ตอบสนองต่อสัญญาณจะต้องเป็น Q_OBJECT ทำให้ Qt ทำงานได้ยากสำหรับโปรแกรมเมอร์ C ++ ผู้คนเคยชินกับการเขียนโปรแกรมแบบ Java หรือ Python อาจจะยุติธรรมดีกว่า

ที่จริงฉันใช้เวลาและความพยายามในการค้นคว้าและคิดค้นวิธีที่จะได้รับความปลอดภัยจากการพิมพ์และเชื่อมต่อสัญญาณ Qt ไปยังวัตถุ functor: http://crazyeddiecpp.blogspot.com/2011/01/quest-for-sane-signals -in-QT-ขั้นตอน 1.html

สิ่งที่ฉันต้องการทำคือพื้นฐานการพัฒนา C ++ ในชีวิตประจำวันที่ทำไปไม่ได้โดย Qt moc ... ซึ่งตัวมันเองไม่จำเป็นเลยในตอนนี้ถ้าเป็นจริง

ตรงไปตรงมาแม้ว่าฉันติดอยู่กับมันเพราะถ้าคุณต้องการที่จะทำการทดสอบ UI อัตโนมัติ Qt เป็นเกมเดียวที่อยู่ในระยะสั้นของ MFC ... ซึ่งเป็น 1980 ดังนั้น (มันดูดการทำงานในอึนั้นยากจริงๆ) บางคนอาจบอกว่า WX แต่มันก็มีปัญหาร้ายแรงยิ่งขึ้น GTKmm น่าจะเป็นตัวเลือกแรกของฉัน แต่เนื่องจากเป็นเจ้าของทั้งหมดและไม่เข้าถึง ... ไม่สามารถขับเคลื่อนด้วยซอฟต์แวร์ทดสอบมาตรฐานอุตสาหกรรม Qt นั้นยากพอสำหรับเรื่องนั้น ( แทบจะไม่ทำงานเมื่อคุณแก้ไขปลั๊กอินสำหรับการเข้าถึง)

— เอ็ดเวิร์ดแปลก
แหล่งที่มา
1
จากความสนใจคุณเห็นว่าปัญหาหลักของ WX คืออะไร
— Tom Anderson
7
@Tom - เอกสารไม่ดีโดยเฉพาะอย่างยิ่งสำหรับสิ่งใหม่ ส่วนประกอบของ AUI นั้นแทบจะไม่มีเอกสารเลยโดยส่วนใหญ่หายไปทำให้ยากต่อการใช้ในสภาพแวดล้อมการผลิต เอกสารสำหรับกระบวนการเหตุการณ์เป็นพื้นฐานในข้อผิดพลาดเกี่ยวกับเส้นทางที่ตามมาใน win32 อย่างน้อย ใช้เวลาไปกับการตะโกนใส่คอมพิวเตอร์ "นี่น่าจะใช้ได้ !!!" ก่อนลงรหัสการประมวลผลลึกเพื่อค้นหาว่าสิ่งที่ WX ไม่ได้ติดตามเอกสารและสิ่งที่ฉันทำจะไม่ทำงาน
— Edward Strange
1
ฉันยังถูกรบกวนจากการยอมรับของห้องสมุดกริดคุณสมบัติลงในสายหลัก ฉันใช้ห้องสมุดนั้นและมันแสดงให้เห็นข้อบกพร่องพื้นฐานในการออกแบบจำนวนมากนอกเหนือจากการขาดความรู้ในนามของโปรแกรมเมอร์ที่เขียนมัน (เช่นเรียกว่าฟังก์ชั่นเสมือนจริงในตัวสร้าง) และสถานะของ AUI ที่แย่แสดงให้เห็นถึงแนวโน้มของมาตรฐานที่แย่ลง ฉันยังไม่ได้เป็นแฟนตัวยงของตารางเหตุการณ์แบบคงที่ แต่อย่างน้อยก็มีอีกวิธีหนึ่งในการตอบสนองต่อกิจกรรม ... ซึ่งแตกต่างจาก MFC ซึ่ง WX นั้นมากเกินไปที่จะตื่นเต้นเหมือนกัน
— Edward Strange
ขอบคุณ ฉันใช้มันเพียงเล็กน้อยและผ่าน wxPython API ซึ่งมันค่อนข้างดี ฉันรู้สึกซาบซึ้งที่จะซ่อนความชั่วร้ายบางอย่าง แต่ฉันก็ยังไม่ได้มีส่วนเกี่ยวข้องอย่างลึกซึ้งพอที่จะแก้ปัญหาที่ร้ายแรงกว่านี้ได้ สิ่งที่ฉันต้องระวัง
— Tom Anderson
1
ทุกสิ่งที่ตอบสนองต่อสัญญาณจะต้องเป็น Q_OBJECTทุกวันนี้ ... ตอนนี้ฟังก์ชั่นคงที่ฟังก์ชั่นและฟังก์ชั่นแลมบ์ดาสามารถตอบสนองสัญญาณ (คุณสามารถใช้ตัวชี้ฟังก์ชั่นเป็นสล็อต) คลาส No-QObject ยังสามารถมีสล็อตสมาชิกได้หากคุณเชื่อมต่อกับคลาสนั้นโดยใช้ std :: bind เพื่อแปลงสมาชิกอินสแตนซ์เป็นตัวชี้ฟังก์ชัน
— Vinícius A. Jorge
28

เหตุผลหนึ่งที่ไม่ใช้ Qt คือถ้าคุณเขียนเพียงหนึ่งสถาปัตยกรรมเช่น Windows คุณอาจต้องการใช้ C # /. NET (หรือ Cocoa บน Mac) เพราะพวกเขาจะสามารถใช้ประโยชน์จากระฆังล่าสุดได้เสมอ - ข้อดีของระบบปฏิบัติการ

หากคุณกำลังเขียนแอพข้ามแพลตฟอร์มคุณอาจตกเป็นเหยื่อของเทคโนโลยีอื่นเช่น Java (เช่นคุณทำงานใน "Java Shop") การเลือกเทคโนโลยีของคุณอาจถูกกำหนดโดยระบบนิเวศที่คุณกำลังพัฒนาเช่น API เฉพาะภาษา ในกรณีเหล่านี้การลดจำนวนเทคโนโลยีอาจเป็นประโยชน์

เหตุผลข้อที่สามที่ฉันคิดได้ก็คือ Qt นั้นใช้ภาษา C ++ และ C ++ เป็นภาษาที่ค่อนข้างยาก / อันตรายสำหรับการเขียนโปรแกรมฉันคิดว่ามันเป็นภาษาสำหรับมืออาชีพ หากคุณต้องการมีประสิทธิภาพสูงสุดและมีความสามารถในการพิถีพิถัน C ++ อาจเป็นเกมที่ดีที่สุดในเมือง ที่จริงแล้ว Qt ช่วยแก้ไขปัญหาการจัดการหน่วยความจำจำนวนมากถ้าคุณตั้งค่าให้หลุดออกจากขอบเขต นอกจากนี้ Qt เองก็ทำงานได้ดีในการป้องกันผู้ใช้จากปัญหา C ++ ที่น่ารังเกียจมากมาย ทุกภาษาและกรอบงานมีข้อดีข้อเสีย มันเป็นปัญหาที่ซับซ้อนมากซึ่งโดยทั่วไปสามารถสรุปได้จากส่วนเพิ่มเติมที่พบในนักทาน: ความเร็วคุณภาพและราคา (แต่คุณสามารถเลือกได้สองข้อเท่านั้น)

แม้ว่ากฎจะบอกว่าฉันควรจดจ่อกับการตอบคำถามต่อไป แต่ฉันต้องการโต้แย้งบางประเด็นที่บิลลี่ออนเรียยกมาซึ่งฉันคิดว่างานที่ดีสรุปเหตุผลที่อ้างถึงโดยทั่วไปว่าไม่ใช้ Qt:

  1. Qt ย่อมเป็นไฟล์ไลบรารี / กรอบงาน / ส่วนหัว C ++ มันเพิ่มขึ้นโดยตัวประมวลผลแมโคร (moc) ซึ่งเปิดใช้งานสัญญาณและช่องเสียบท่ามกลางสิ่งอื่น ๆ มันแปลงคำสั่งแมโครเพิ่มเติม (เช่น Q_OBJECT) เพื่อให้คลาสนั้นมีวิปัสสนาและสินค้าอื่น ๆ ทุกประเภทที่คุณอาจคิดว่าเป็นการเพิ่มฟังก์ชั่น Objective-C เป็น C ++ ถ้าคุณรู้เรื่อง C ++ มากพอที่จะถูกทำให้ขุ่นเคืองจากการขาดความบริสุทธิ์เช่นคุณเป็นมืออาชีพแล้ว 1) อย่าใช้ Q_OBJECT และ ILK หรือ 2) รู้สึกขอบคุณที่ทำเช่นนี้และตั้งโปรแกรมกรณีมุมที่ จำกัด มาก ซึ่งทำให้เกิดปัญหา สำหรับผู้ที่พูดว่า "ใช้ Boost สำหรับสัญญาณและช่อง!" จากนั้นฉันจะตอบโต้ว่าคุณกำลังแลกเปลี่ยน "ปัญหา" หนึ่งสำหรับปัญหาอื่น Boost มีขนาดใหญ่มากและมีปัญหาที่อ้างถึงโดยทั่วไปเช่นเอกสารไม่ดี API ที่น่ากลัวและความน่ากลัวข้ามแพลตฟอร์ม (คิดว่าคอมไพเลอร์รุ่นเก่าเช่น gcc 3

  2. สำหรับการสนับสนุนบรรณาธิการนี้ยังมีต่อจาก 1 ฉันค่อนข้างเห็นด้วย อันที่จริงแล้วผู้สร้าง Qt เป็น IMHO โปรแกรมแก้ไข C ++ แบบกราฟิคที่ดีที่สุดถึงแม้ว่าคุณจะไม่ได้ใช้ Qt โปรแกรมเมอร์มืออาชีพหลายคนใช้ emacs และเป็นกลุ่ม นอกจากนี้ฉันคิดว่า Eclipse จัดการกับไวยากรณ์เพิ่มเติม ดังนั้นจึงไม่มีปัญหาเกี่ยวกับมาโคร Qt (Q_OBJECT) หรือการเพิ่มสัญญาณ / สล็อต คุณอาจจะไม่พบมาโครเหล่านี้ใน Visual Studio เพราะ (ฉันยอมรับ) มันเป็นส่วนเพิ่มเติมของ C ++ แต่โดยทั่วไปแล้ว C # /. NET folks จะไม่ใช้ Qt อยู่ดีเนื่องจากความจริงที่ว่าพวกเขามีฟังก์ชั่นมากมายที่ครอบคลุมด้วยเทคนิคที่เป็นกรรมสิทธิ์ของตนเอง

  3. ขนาดของแหล่งที่มา Qt ตราบใดที่มันรวบรวมในชั่วข้ามคืนใครสนใจ? ฉันรวบรวม Qt 4 บน Macbook แบบดูอัลคอร์ใน "น้อยกว่าข้ามคืน" ฉันหวังว่านี่ไม่ใช่สิ่งที่ขับเคลื่อนการตัดสินใจของคุณในการใช้หรือไม่ใช้เทคโนโลยีเฉพาะ หากนี่เป็นปัญหาอย่างแท้จริงคุณสามารถดาวน์โหลด SDK ที่คอมไพล์แล้วสำหรับ Mac, Linux และ Windows ได้จากเว็บไซต์ Qt

  4. การออกใบอนุญาตมีให้เลือกสามแบบ: 1) สิทธิ์การใช้งานที่เป็นกรรมสิทธิ์ในกรณีที่คุณต้องการแก้ไข Qt ITSELFและไม่แชร์หรือซ่อนความจริงที่ว่ามีการใช้ Qt และไม่เต็มใจที่จะระบุแหล่งที่มา ) GPL และ 3) LGPL ใช่มีปัญหาเกี่ยวกับการเชื่อมโยงแบบคงที่ (กลิ้ง Qt ทั้งหมดลงในไบนารี่) - แต่ฉันคิดว่ามันมีมากกว่านั้นเพราะไม่มีใครแอบมองเข้าไปข้างในและสังเกตเห็นว่าคุณกำลังใช้ Qt (แสดงที่มา!) ฉันพยายามซื้อลิขสิทธิ์จาก Digia และพวกเขาบอกฉันว่า "สำหรับสิ่งที่คุณกำลังทำอยู่คุณไม่ต้องการมันจริง ๆ " ว้าว. จากธุรกิจที่อยู่ในธุรกิจการขายใบอนุญาต

  5. ขนาดของไบนารี / บันเดิลนั้นเป็นเพราะคุณต้องกระจายเนื้อหาของ Qt ไปยังคนที่ไม่มีมัน: Windows มีอยู่แล้ว? สิ่งที่ Visual Studio หรือคุณต้องติดตั้งเวลาทำงาน Mac นั้นมาพร้อมกับโกโก้ขนาดใหญ่และสามารถเชื่อมโยงได้แบบไดนามิก แม้ว่าฉันจะไม่ได้มีการแจกจ่ายจำนวนมาก แต่ฉันไม่เคยพบปัญหามากนักกับการกระจายไฟล์คงที่ ~ 50 เมกะไบต์ (ซึ่งฉันสามารถทำให้เล็กลงด้วยโปรแกรมอรรถประโยชน์การเต้นระบำเปลื้องผ้า / การบีบอัดแบบไบนารีเช่น UPX) ฉันไม่สนใจพอที่จะทำเช่นนี้ แต่ถ้าแบนด์วิดท์เคยมีปัญหาฉันจะเพิ่มขั้นตอน UPX ให้กับสคริปต์สร้างของฉัน

  6. กำหนด "รูปลักษณ์และความรู้สึกพื้นเมืองคืออะไร" ฉันคิดว่า "ส่วนใหญ่" จะยอมรับว่า Mac นั้นใกล้เคียงกับรูปลักษณ์และความรู้สึกที่รวมเป็นหนึ่ง แต่ที่นี่ฉันนั่งดูที่ Safari, iTunes, Aperture, Final Cut Pro, Pages และอื่น ๆ พวกเขาดูไม่เหมือนกันทั้งๆที่พวกเขาทำโดยผู้จำหน่ายระบบปฏิบัติการ ฉันคิดว่าแง่มุม "รู้สึก" มีความเกี่ยวข้องมากกว่า: การกำหนดสไตล์วิดเจ็ตการตอบสนอง ฯลฯ หากคุณสนใจการตอบสนองนี่เป็นเหตุผลที่ดีที่จะใช้ C ++ แทน Java หรือภาษาอื่น ๆ ที่มีไดนามิกสูง (วัตถุประสงค์ C ยังโขดหิน แต่ฉันพยายามปัดเป่าตำนานเกี่ยวกับ Qt)

สรุปแล้วมันเป็นปัญหาที่ซับซ้อน แต่ฉันอยากจะชี้ให้เห็นว่าฉันคิดว่ามีเหตุผลน้อยกว่าที่จะ "ไม่ใช้ Qt" เนื่องจากอาจคิดว่ามีตำนานและข้อมูลที่ล้าสมัยมาหลายทศวรรษ

— Eric Brown
แหล่งที่มา
1
สิ่งที่ฉันไม่ได้รับคือเหตุใดห้องสมุดข้ามแพลตฟอร์มเหล่านี้ไม่ได้เป็นเพียงฟังก์ชันห่อหุ้มหรือดีกว่านั้น ถ้า defs รอบฟังก์ชั่น Cocoa, Win32, KDE / Gnome มั่นใจ UI ที่ดูดีที่สุดด้วยคุณสมบัติทั้งหมดของมัน
— MarcusJ
2
@MarcusJ การเขียน wrapper โดยรอบหนึ่งชุดเครื่องมือนั้นไม่ใช่เรื่องไม่สำคัญไม่สนใจ 4 หรือมากกว่า - แต่ถ้าคุณคิดว่ามันง่ายขนาดนั้นคุณยินดีที่จะลอง สำหรับแนวคิดที่ว่าสิ่งนี้สามารถทำได้โดยใช้การประมวลผลล่วงหน้าตามเงื่อนไขเท่านั้น ... คุณต้องล้อเล่นใช่ไหม?
— underscore_d
@MarcusJ libuiเป็นสิ่งที่แน่นอน (แต่ไม่สนับสนุน KDE)
— Demi
ฉันต้องการเพิ่มว่าตอนนี้คุณสามารถใช้ Qt / QML กับ. NET คุณไม่จำเป็นต้องแตะ C ++ github.com/qmlnet/qmlnet PS: ฉันเป็นผู้แต่ง
— Paul Knopf
26

บางส่วนก็คือการออกใบอนุญาต ดูhttps://en.wikipedia.org/wiki/Qt_(software)#Licensingสำหรับประวัติสิทธิ์ใช้งานบางส่วน จนถึงปี 2000 ผู้ที่ใส่ใจอย่างยิ่งเกี่ยวกับโอเพ่นซอร์สไม่ได้ใช้ Qt ระยะเวลา (อันที่จริงแล้วเป็นแรงบันดาลใจดั้งเดิมในการพัฒนา Gnome) จนถึงปี 2005 คนที่ต้องการปล่อยซอฟต์แวร์ฟรีสำหรับ Windows ไม่ได้ใช้ Qt แม้หลังจากวันนั้นผู้ที่ต้องการซอฟต์แวร์ฟรีภายใต้สิ่งอื่นนอกเหนือจาก GPL ก็ไม่มีตัวเลือกในการใช้ Qt ดังนั้นโครงการซอฟต์แวร์ฟรีใด ๆ ที่เก่ากว่าวันที่เหล่านั้นไม่สามารถใช้ Qt ได้ และแน่นอนว่าคนที่เขียนรหัสกรรมสิทธิ์ต้องจ่ายค่าสิทธิ์

ยิ่งไปกว่านั้นมันไม่ใช่ว่ามีตัวเลือกอื่น ๆ ขาดแคลน ตัวอย่างเช่นWxWidgets , GTK +และTkเป็นโอเพ่นซอร์สทั้งหมด, ชุดเครื่องมือข้ามแพลตฟอร์ม

นอกจากนี้ Windows ยังมีความโดดเด่นในเดสก์ท็อปมาเป็นเวลานานซึ่งซอฟต์แวร์จำนวนมากเป็นเนื้อหาที่ทำงานบน Windows เท่านั้น หากคุณติดตั้ง Toolchain ของ Microsoft คุณจะสามารถใช้สิ่งที่เป็นกรรมสิทธิ์ของ Microsoft ได้ง่ายกว่าการกังวลเกี่ยวกับสิ่งอื่นและโปรแกรมเมอร์จำนวนมากก็ทำเช่นนั้น

— btilly
แหล่งที่มา
1
@btilly: GTK + เป็นแพลตฟอร์มข้าม ตัวอย่างเช่นไคลเอนต์ IM Pidgin ถูกเขียนบน GTK +
— Billy ONeal
1
อย่างไรก็ตามโอเคมันเป็นไปได้ที่จะ 'ทำงาน' บน Windows :)
— Dehumanizer
6
เพียงติดตั้ง GIMP บน Windows และดู
— 281377
2
ใช่แล้ว GIMP ทำงานได้ดีบน Windows แต่แน่นอนว่าไม่เหมาะกับรูปลักษณ์และความรู้สึกของ Windows 7 UI
— Alan B
5
Pidgin น่าจะเป็นตัวอย่างที่ดีกว่าของ GTK บน Windows มันไม่ได้ทำอะไรแฟนซี แต่มันเข้ากันได้ดีและอาจนานถึง 10 ปีหรือมากกว่า
— เบรนแดนลอง
14

ฉันเห็นด้วยกับเหตุผลเกือบทั้งหมดที่กล่าวถึงข้างต้นอย่างไรก็ตามผู้คนจำนวนมากที่นี่บอกว่าพวกเขาจะไม่ใช้ Qt เนื่องจากค่าใช้จ่ายเพิ่มเติมที่นำมาด้วย ฉันไม่เห็นด้วยเพราะทุกภาษาที่พบบ่อยที่สุดในวันนี้ (Java, C # และ Python) มีค่าใช้จ่ายที่ค่อนข้างยุติธรรม

ประการที่สอง Qt ทำให้การเขียนโปรแกรมด้วย C ++ ง่ายและตรงไปตรงมาซึ่งประกอบขึ้นเป็นทรัพยากรเพิ่มเติมที่ใช้ ฉันเจอแอพพลิเคชั่นคอนโซลที่เขียนด้วย Qt มากกว่า C ++ มาตรฐานเพราะความสะดวกในการเขียน

ฉันจะบอกว่าประสิทธิผลของ Qt นั้นดีกว่า C / C ++ แต่น้อยกว่าภาษาอย่าง Python

— WKS
แหล่งที่มา
2
ฉันเดาว่าทั้งหมดเกี่ยวข้องกับประสบการณ์ของแต่ละบุคคลเพราะฉันสามารถใช้รหัสตกลงใน C ++ 14 แต่ทุกครั้งที่ฉันมองไปที่รหัส Qt บางอย่างฉันต้องเหลื่อมล้ำอย่างหนักเพื่อให้รู้ว่าเป็นภาษาเดียวกัน ... ดังนั้นฉันจึงไม่สวม อย่าคิดว่ามันเป็นตัวช่วยเพิ่มผลผลิตอย่างเป็นเอกฉันท์ที่คุณพูดถึง
— underscore_d
1
@underscore_d เห็นได้ชัดว่าถ้าคุณรู้ว่า C ++ เป็นอย่างดีและคุณไม่ได้ใช้ Qt คุณจะไม่สามารถทำงานได้ดีขึ้นในตอนหลัง แต่เมื่อคุณได้รู้จักทั้ง C ++ และ Qt เฟรมเวิร์กทำให้สิ่งต่าง ๆ ง่ายขึ้นและเร็วขึ้นในการนำไปใช้ (C ++ 11, 14 และอื่น ๆ กำลังเติมเต็มช่องว่าง แต่ยังไม่ครบถ้วน)
— ymoreau
11

นี่ไม่ใช่ความพยายามอย่างแท้จริงในการเริ่มต้นสงครามไฟฉันแค่ต้องการที่จะพูดถึงประเด็นบางอย่าง

อาจเป็นเหตุผลที่แท้จริงที่ Qt ไม่ได้ใช้กันอย่างแพร่หลายมากขึ้นเพราะมันเป็น C ++ และมีคนใช้ c ++ น้อยลงสำหรับแอปเดสก์ท็อป

Qt ไม่ใช่ไลบรารี C ++ มันต้องมีขั้นตอนการรวบรวมแยกต่างหากซึ่งทำให้กระบวนการสร้างมีความซับซ้อนมากขึ้นเมื่อเทียบกับห้องสมุดอื่นส่วนใหญ่

vs-addin สำหรับ visual studio ทำสิ่งนี้โดยอัตโนมัติเช่นเดียวกับ commandline ของ Qt สร้างกระบวนการ คอมไพเลอร์ทรัพยากรที่ใช้ในการสร้างกล่องโต้ตอบสำหรับ MFC ก็เป็นขั้นตอนที่แยกจากกัน แต่นั่นก็ยังคงเป็น c ++

Qt เป็นแหล่งข้อมูลจำนวนมากซึ่งจะต้องมีอยู่และติดตั้งล่วงหน้าในเครื่องที่คุณใช้ก่อนที่จะรวบรวม สิ่งนี้สามารถทำให้การตั้งค่าสภาพแวดล้อมการสร้างน่าเบื่อมากขึ้น

มีการดาวน์โหลดแบบไบนารีสำหรับ Visual Studio แต่ละรุ่นและบิลด์จากแหล่งเป็นคำสั่งเดียว ฉันไม่เห็นว่าขนาดแหล่งที่มาของ SDK นั้นเป็นข้อตกลงจำนวนมากในทุกวันนี้ ขณะนี้ Visual Studio ติดตั้ง libs C ++ ทั้งหมดแทนที่จะปล่อยให้คุณเลือกและเลือกดังนั้นขนาดการติดตั้งของคอมไพเลอร์คือ> 1Gb

สามารถใช้งานได้ภายใต้ LGPL เท่านั้นซึ่งทำให้ยากต่อการใช้การปรับใช้แบบไบนารีเดียวเมื่อต้องการเผยแพร่ภายใต้สิทธิ์การใช้งานที่ จำกัด หรือมีข้อ จำกัด น้อยกว่า

LGPL จะใช้กับ lib เท่านั้นจะไม่มีผลกับรหัสของคุณ ใช่หมายความว่าคุณต้องจัดส่ง DLLs แทนที่จะเป็นไบนารีเดียว (เว้นแต่คุณจะจ่าย) แต่ในโลกที่คุณต้องดาวน์โหลด Java runtime หรือการอัพเดท. Net สำหรับการใช้เล็ก ๆ นี่ไม่ใช่เรื่องใหญ่อะไร นอกจากนี้ยังมีปัญหาน้อยในแพลตฟอร์มที่มี ABI เดียวเพื่อให้แอป Qt อื่น ๆ สามารถแชร์ libs ได้

ในบางกรณีมันดูไม่เหมือนโปรแกรมเนทีฟ การออกแบบ UI เดียวสำหรับทุกแพลตฟอร์มโดยเนื้อแท้จะไม่ถูกต้องเมื่อย้ายจากเครื่องไปยังเครื่อง

มันควรจะใช้วิดเจ็ตและชุดรูปแบบดั้งเดิม ฉันต้องยอมรับว่าฉันทำแอพทางเทคนิคเป็นส่วนใหญ่เพื่อให้ผู้ใช้ของฉันไม่ได้กังวลเกี่ยวกับสไตล์มากเกินไป โดยเฉพาะอย่างยิ่งบนหน้าต่างแฟชั่นใหม่ที่มีทุกสิ่งในสไตล์เป็นเครื่องมือของสมาร์ทโฟนหมายความว่ามีมาตรฐานน้อยลงเรื่อย ๆ

— Martin Beckett
แหล่งที่มา
1
บริษัท ซอฟต์แวร์ขนาดใหญ่จำนวนมากสร้างแอปพลิเคชั่นเชิงพาณิชย์ใน C ++ แต่ฉันไม่ได้ตระหนักถึงการใช้ QT จำนวนมาก ดังนั้นในขณะที่ฉันเข้าใจว่านักพัฒนาที่ไม่ใช่ C ++ อาจหลีกเลี่ยง QT มีเหตุผลอื่นที่จะหลีกเลี่ยง QT แม้ว่าคุณจะเขียนแอป C ++ แต่ดูเหมือนว่า จริงๆแล้วไม่มีภาษาข้ามแพลตฟอร์มและชุดเครื่องมือ GUI ที่ฉันไม่สามารถหาข้อผิดพลาดได้ ดูเหมือนว่าการพัฒนาข้ามแพลตฟอร์มนั้นเป็นเพียงแค่ความยากลำบากและการทำมันให้ดีนั้นไม่ใช่เรื่องง่ายหรือฟรีและสัญญาที่ QT ทำได้ (เขียน GUI ของคุณอีกครั้งและนำ GUI นั้นไปใช้ทุกที่) ไม่เพียงพอ
— Warren P
ซอฟต์แวร์ C ++ ของเดสก์ท็อปส่วนใหญ่มีอยู่ใน MFC เนื่องจากเริ่มทำงานเมื่อ 20 ปีก่อนหรือใช้ชุดเครื่องมือภายในเริ่มต้นเมื่อ 20 ปีก่อนเพื่อหลีกเลี่ยง MFC (เช่น MS-Office หรือ Autocad) ฉันสงสัยอย่างมากว่ากำลังเขียนด้วย C ++ / CLR ด้วย WPF แต่ถึงแม้จะไม่มีข้อพิจารณาข้ามแพลตฟอร์มฉันก็พบว่า Qt ชุดเครื่องมือเดสก์ท็อปที่ดีที่สุด (หรือแย่ที่สุด!) เช่นเดียวกับคนส่วนใหญ่ที่เรากำลังย้ายไปยังส่วนหน้าเว็บ (อาจเป็นใน QtQuick / QML) และแบ็กเอนด์เซิร์ฟเวอร์ C ++ - ซึ่งอาจจะใช้สัญญาณ / สล็อต Qt แต่ไม่มีกุย
— Martin Beckett
ฉันเห็นด้วย. อย่างน้อยที่สุด และแม้กระทั่งในแอปที่ใช้ Windows เท่านั้นฉันต้องการแก้ไขปัญหา QT มากกว่าปัญหา MFC
— Warren P
@WarrenP - ใช่ฉันไม่พลาดการค้นหา codeproject สำหรับทุกสิ่งที่หายไปจาก MFC แต่ด้วยความรักครั้งใหม่ของ MSFT ที่ได้พบกับโค้ดพื้นเมือง - พวกเขาไม่ได้ทำอะไรมากมายเพื่อให้สามารถเขียน gui ได้ง่ายขึ้น
— Martin Beckett
7

เหตุผลง่าย: มันไม่ได้มีการผูกที่ดีที่จะเป็นภาษาหลักทั้งหมดและมันเป็นไปไม่ได้อย่างน่าอัศจรรย์เสมอที่เหมาะสมสำหรับงานในมือ

ใช้เครื่องมือที่เหมาะสมสำหรับงาน หากฉันกำลังเขียนแอปพลิเคชันบรรทัดคำสั่งง่ายๆทำไมฉันจะขยายความด้วย Qt เพียงเพื่อประโยชน์ของมัน

เป็นคำตอบทั่วไปเพิ่มเติม (ซึ่งฉันสามารถให้ได้เพราะฉันเกี่ยวข้องที่นี่) โปรแกรมเมอร์บางคนจะไม่เคยได้รับมันและตัดสินใจที่จะใช้มัน ในบางกรณีไม่มีเหตุผลพิเศษที่นอกเหนือจากโปรแกรมเมอร์ไม่เคยพบความต้องการมันและมองเข้าไปในมัน

— Lightness Races ในวงโคจร
แหล่งที่มา
1
แต่ Qt ให้ความสามารถในการเขียนแอปพลิเคชันคอนโซลเท่านั้น ไม่ใช่เหรอ
— Dehumanizer
9
@ Dehumanizer: ฉันไม่มีความคิด แต่ทำไมฉันถึงใช้มันเป็นเครื่องมือขนาดเล็ก? ประโยชน์อะไรที่จะเกิดขึ้นกับฉันเมื่อฉันสามารถเขียนแอปพลิเคชันเพียงเล็กน้อยในมาตรฐาน C ++ ดูเหมือนว่าคุณกำลังมองหาเหตุผลในการใช้ห้องสมุดซึ่งเป็นวิธีการย้อนหลังในการเขียนโปรแกรม
— Lightness Races ใน Orbit
12
@ Dehumanizer: ตามที่ฉันพูดนั่นเป็นวิธีการย้อนหลัง เมื่อคุณพบความต้องการห้องสมุดคุณก็จะรู้แล้วคุณสามารถไปลองทำสักสองสามข้อแล้วดูว่าอะไรเหมาะกับความต้องการของคุณมากขึ้น การพยายามรวบรวมความเห็นในห้องสมุดเมื่อคุณไม่มีกรณีใช้งานก็เป็นเรื่องของคนโง่
— การแข่งขัน Lightness ใน Orbit
3
"ถ้าฉันกำลังเขียนแอปพลิเคชันบรรทัดคำสั่งง่ายๆทำไมฉันถึงขยายตัวด้วย Qt เพื่อประโยชน์ของมัน" มีเครื่องมือที่ไม่ใช่กุยที่โด่งดังอย่างน้อยหนึ่งรายการที่เขียนด้วย Qt - Doxygen :-)
— Valentin Heinitz
4
@ Dehumanizer ตัวอย่างเช่นเมื่อคุณต้องจัดการกับไฟล์, xml, unicode, json, regexp, concurency, ฐานข้อมูลและอื่น ๆ อย่างรวดเร็วและไม่ต้องการดาวน์โหลดนำมาใช้รักษาไลบรารีของบุคคลที่สามโหล
— Valentin Heinitz
5

เฟรมเวิร์กอย่าง Qt เหมาะสมเมื่อคุณกังวลเกี่ยวกับผลิตภัณฑ์ของคุณเหมือนกันในทุกแพลตฟอร์มมากกว่าที่ผลิตภัณฑ์ของคุณจะถูกต้องในทุกแพลตฟอร์ม บ่อยขึ้นทุกวันนี้แอปพลิเคชั่นประเภทนั้นกำลังเคลื่อนไปสู่เทคโนโลยีบนเว็บ

— คาเลบ
แหล่งที่มา
4

ฉันยอมรับว่า Qt เป็นกรอบที่ดีในการทำงานกับ ยังมีอีกหลายประเด็นที่ฉันมี:

  1. มันเขียนใน C ++ ซึ่งเป็นภาษาระดับต่ำมาก ความจริงเพียงอย่างเดียวว่ามันคือ C ++ จะทำให้โปรแกรมเมอร์ Qt ทุกคนมีประสิทธิผลน้อยลงอย่างมากเมื่อเทียบกับ Frameworks ที่เขียนด้วยภาษาอื่น เนื้อหลักของฉันกับ C ++ เป็นภาษาที่ใช้ในการพัฒนา GUI ก็คือมันไม่ได้มีแนวคิดการจัดการหน่วยความจำอัตโนมัติซึ่งทำให้กระบวนการพัฒนามีแนวโน้มที่จะเกิดข้อผิดพลาดได้ง่ายขึ้น ไม่ใช่การใคร่ครวญซึ่งทำให้การดีบักยากขึ้นมาก ชุดเครื่องมือ GUI ที่สำคัญอื่น ๆ ส่วนใหญ่มีแนวคิดในการจัดการหน่วยความจำอัตโนมัติและวิปัสสนา
  2. ชุดเครื่องมือข้ามแพลตฟอร์มทุกตัวประสบปัญหาที่สามารถใช้ตัวหารร่วมน้อยที่สุดของแพลตฟอร์มที่รองรับทั้งหมดได้ นั่นและแนวทาง UI ที่แตกต่างกันในแพลตฟอร์มที่แตกต่างกันนั้นมีคำถามมากมายเกี่ยวกับความต้องการ GUI ข้ามแพลตฟอร์มในภาพรวม
  3. Qt นั้นเน้นที่การตั้งค่า UI ทั้งหมดของคุณเป็นอย่างมาก แม้ว่าคุณจะสามารถใช้ QtDesigner เพื่อสร้างบางส่วนของ UI ของคุณ แต่ก็ยังขาดการเปรียบเทียบอย่างจริงจังกับการพูดการสร้างส่วนต่อประสาน (Cocoa / Obj-C) หรือเครื่องมือ. Net
  4. แม้ว่า Qt จะมีฟังก์ชั่นแอปพลิเคชั่นระดับต่ำจำนวนมาก แต่ก็ไม่สามารถเปรียบเทียบกับการมีเฟรมเวิร์กที่ออกแบบมาเฉพาะสำหรับแพลตฟอร์มบางแพลตฟอร์มได้ ไลบรารีระบบปฏิบัติการดั้งเดิมสำหรับทั้ง Windows และ OSX นั้นมีประสิทธิภาพมากกว่าการใช้งานของ Qt อย่างมีนัยสำคัญ (คิดว่ากรอบเสียงการเข้าถึงระบบไฟล์ระดับต่ำเป็นต้น)

ที่กล่าวว่าฉันชอบใช้ PyQt สำหรับการสร้างต้นแบบแอปพลิเคชันที่รวดเร็วหรือแอปพลิเคชันภายในองค์กร การใช้ Python เพื่อทำการเข้ารหัสทั้งหมดช่วยลดข้อกังวลด้วย C ++ และทำให้ Qt เป็นสถานที่ที่น่าพอใจมาก

แก้ไขเพื่อตอบสนองต่อความคิดเห็น:

เมื่อฉันเขียนเกี่ยวกับ Qt ที่เขียนใน C ++ ฉันไม่ได้บ่นเกี่ยวกับ Qt มากนัก แต่เกี่ยวกับสภาพแวดล้อมที่อาศัยอยู่มันเป็นความจริงที่ Qt จัดการทรัพยากรของตัวเองได้เป็นอย่างดี แต่ GUI ที่เกี่ยวข้องกับคุณทั้งหมด รหัสที่ไม่ใช่แบบ QT จะต้องเขียนด้วย C ++ เช่นกัน ถึงแม้จะมี Qt มีเครื่องมือที่ดีมากมาย แต่ในที่สุดคุณต้องจัดการกับ C ++ ในระดับนั้น Qt ทำให้ C ++ เป็นที่รับได้ แต่ก็ยังคงเป็น C ++

สำหรับวิปัสสนาสิ่งที่ฉันหมายถึงคือ: กรณีที่ยากที่สุดในการดีบักคือเมื่อคุณมีตัวชี้ไปยังวัตถุบางอย่างที่ไม่ทำงานตามที่คุณคิด ด้วย C ++ ตัวดีบักเกอร์ของคุณอาจมองเข้าไปในวัตถุนั้นได้เล็กน้อย (ถ้ามันมีข้อมูลประเภทที่จุด thwt) แต่ถึงแม้มันจะไม่ได้ผลก็ตาม ในทางกลับกันโกโก้ในสถานการณ์เดียวกัน ใน Cocoa / Obj-C คุณจะสามารถส่งข้อความ ('ฟังก์ชั่นการโทร') ไปยังวัตถุที่อยู่ภายในตัวดีบัก คุณสามารถเปลี่ยนสถานะของวัตถุคุณสามารถสอบถามคุณสมบัติของมันคุณสามารถถามมันสำหรับประเภทและชื่อฟังก์ชั่นของมัน ... ซึ่งจะทำให้การดีบักสะดวกมากขึ้น Qt / C ++ ไม่มีอะไรที่ใกล้เคียง

— bastibe
แหล่งที่มา
11
1. ถามเกี่ยวกับการจัดการหน่วยความจำด้วยตัวเองคุณไม่ต้องโทร 'ลบ' หลังจากแต่ละ 'ใหม่' 1a C ++ ไม่ใช่ภาษาระดับต่ำ แต่เป็นภาษาระดับสูงที่มีความสามารถระดับต่ำ 3. ฉันเห็นด้วย แต่ Qt จัดทำ UI กับ QtDesigner และ 'รหัสธรรมดา' ในเวลาเดียวกัน 4. ยอมรับอีกครั้ง แต่ Qt ยังมีการใช้ API ดั้งเดิม
— Dehumanizer
11
ถึงจุดที่ 1 ของคุณฉันคิดว่า c ++ มีการจัดการหน่วยความจำกึ่งอัตโนมัติ: ถ้าคุณใช้ตัวชี้อัจฉริยะเช่น std :: auto_ptr หรือ boost :: shared_ptr เป็นต้นคุณไม่ต้องสนใจเรื่องการเพิ่มหน่วยความจำ คอนเทนเนอร์ประเภทนี้สามารถสร้างขึ้นสำหรับทรัพยากรอื่น ๆ ได้เช่นกัน (ไฟล์ทรัพยากรระบบที่ต้องเป็นอิสระ) การใช้รูปแบบ RAII ช่วยได้มากกับการจัดการหน่วยความจำและเมื่อมันเติบโตเป็นคุณคุณไม่ต้องกังวลเกี่ยวกับความทรงจำ
— deo
8
"ความจริงเพียงอย่างเดียวว่ามันคือ C ++ จะทำให้โปรแกรมเมอร์ Qt ทุกคนทำงานได้อย่างมีประสิทธิผลน้อยลงเมื่อเทียบกับ Framework ที่เขียนในภาษาอื่น" [อ้างจำเป็น]
— นาธานออสมัน
4
@ SK-logic: ในขณะที่ฉันคิดว่าฉันเข้าใจทุกคำในประโยคที่สามของคุณ แต่ฉันไม่รู้ว่าคุณกำลังพูดอะไร "ระดับ abstraction cap" คืออะไร? สำหรับเรื่องนั้นประโยคแรกของคุณไม่ถูกต้องเนื่องจากนิยามของวิกิพีเดียเป็น "ภาษาระดับต่ำ"
— David Thornley
6
@ SK-logic: เทมเพลตการเขียนโปรแกรมเทมเพลตเสร็จสมบูรณ์และมีคนฉลาดและมีความรู้เพียงพอที่จะใช้ประโยชน์จากสิ่งนั้น RAII ไม่ใช่การรวบรวมขยะที่ยอดเยี่ยม แต่ความจริงที่ว่ามันใช้งานได้กับทรัพยากรทุกประเภทไม่มากก็น้อย ทีนี้สิ่งที่เป็นนามธรรมของ Java แต่ไม่ใช่ C ++?
— David Thornley
3

ฉันชอบ Qt จริงๆ แต่มันค่อนข้างหนาสำหรับแอพพลิเคชั่นมากมาย บางครั้งคุณก็ไม่ต้องการความซับซ้อนระดับนั้น บางครั้งคุณต้องการอะไรที่เรียบง่ายโดยไม่มีค่าใช้จ่ายทั้งหมดของ Qt ไม่ใช่ทุกแอปพลิเคชันที่จะต้องขับเคลื่อนเหตุการณ์และ C ++ มีชุดเทมเพลตที่สมเหตุสมผล Boost เป็นอีกหนึ่งชุดที่ดีมากและมีฟังก์ชั่นระดับต่ำมากมาย (ไฟล์ซ็อกเก็ตพอยน์เตอร์ที่มีการจัดการ ฯลฯ ) ที่ QT ทำ

แอปพลิเคชั่นอื่นมีข้อกำหนดด้านลิขสิทธิ์ที่ไม่สนุกกับ GPL, LGPL หรือ Qt GPL ไม่เหมาะสมสำหรับซอฟต์แวร์เชิงพาณิชย์ LGPL ไม่เหมาะสมสำหรับซอฟต์แวร์ที่มีการเชื่อมโยงแบบคงที่และค่าใช้จ่ายในเชิงพาณิชย์จะเสียค่าใช้จ่ายซึ่งเป็นสิ่งที่หลายคนไม่ต้องการจ่าย

บางคนมีข้อควรพิจารณาด้านความปลอดภัยหรือเสถียรภาพซึ่งไม่อนุญาตให้ใช้ไลบรารีที่ซับซ้อนอย่าง Qt

คุณต้องรันกระทรวงพาณิชย์เพื่อประมวลผลแหล่งที่มาของคุณล่วงหน้า นั่นไม่ใช่ปัญหาใหญ่ แต่มันอาจเป็นเรื่องที่น่ากังวลสำหรับผู้ใช้ใหม่ โปรแกรมเมอร์จำนวนมากคิดว่าคุณต้องใช้ qmake กับ Qt แต่นั่นเป็นชื่อเรียกผิด เป็นไปได้ที่จะเสียบ Qt เข้ากับระบบบิลด์อื่น ๆ ได้อย่างง่ายดาย

เป้าหมายบางอย่างมีหน่วยความจำหรือ CPU จำกัด

มี gotchas เฉพาะแพลตฟอร์มอยู่ในนั้น gotchas เหล่านั้นส่วนใหญ่ไม่มีเอกสาร สร้างแอปพลิเคชันขนาดใหญ่พอสมควรแล้วคุณจะพบกับพวกเขาและสงสัยว่าเกิดอะไรขึ้น (ข้อจำกัดความรับผิดชอบครั้งล่าสุดที่ฉันใช้ Qt ด้วยความโกรธเมื่อ 18 เดือนที่ผ่านมาดังนั้นมันอาจจะดีขึ้น)

มันคือ C ++ เท่านั้น มีการผูกภาษาอื่น แต่มีแนวโน้มที่จะซ่อนหรือเปิดเผยการทำงานจำนวนมากที่คุณต้องการให้ Qt

มีเหตุผลมากมายที่จะไม่ใช้ Qt นั่นคือเหตุผลที่มีทางเลือกอื่น หากสิ่งที่คุณมีคือค้อนปัญหาทุกอย่างจะดูเหมือนเล็บ

— อดัมฮาเวส
แหล่งที่มา
3

สิ่งที่สำคัญที่สุด แต่ไม่ได้กล่าวถึง ในโครงการขนาดใหญ่สิ่งหนึ่งที่ทำให้เกิดปัญหามากและรหัสที่ไม่จำเป็น กลไกช่องสัญญาณของ Qt ไม่มีประสิทธิภาพ วิดเจ็ต Qt ไม่ได้ให้สัญญาณที่จำเป็นสำหรับวิดเจ็ตอย่างง่ายของเหตุการณ์ ตัวอย่างเช่นคุณไม่สามารถตั้งค่าสัญญาณสำหรับ onHover, onMouseEnter, onMouseLeave, onKeyReleased, onLostFocus, onGainFocus และอื่น ๆ แม้แต่เครื่องมือที่ซับซ้อนที่สุดเช่น QTreeWidget ก็ให้สัญญาณไร้ประโยชน์อย่างง่ายเพียงหนึ่งหรือสองอย่าง

ใช่คุณสามารถใช้กิจกรรม แต่ !!! คุณได้สร้างคลาสใหม่สำหรับแต่ละวิดเจ็ตด้วยเหตุการณ์ที่กำหนดเอง นี่คือประสิทธิภาพที่หายไปอย่างมาก

  • คุณเขียนเหตุการณ์วัตถุวิดเจ็ตที่กำหนดเองใหม่แต่ละครั้งมีการเปลี่ยนแปลงเล็กน้อย
  • คุณสูญเสียทุกสิ่งใน Qt Designer คุณต้องส่งเสริมทุกวิดเจ็ตด้วยเหตุการณ์ที่กำหนดเอง
  • โครงการใหญ่และยากที่จะรักษา
  • คุณเริ่มไม่ชอบ qt เนื่องจากสิ่งนี้ และเริ่มพูดคุยเกี่ยวกับวิธีที่. net ให้ผู้ได้รับมอบหมายวิธีที่ดีกว่าช่องสัญญาณมากขึ้นโดยทั่วไปส่วนประกอบ. net (วิดเจ็ต) จะให้ทุกเหตุการณ์ที่คุณสามารถจินตนาการได้อย่างไร และอื่น ๆ.

หนึ่งในวิทยาลัยของฉันได้เขียนคลาส combo box ใหม่สำหรับวิดเจ็ต combo box แต่ละอันเพราะเขาต้องใช้เหตุการณ์ที่ไม่ใช่สัญญาณ เรื่องจริง...

อย่างไรก็ตาม Qt เป็นเฟรมเวิร์ก C ++ UI ที่ดีที่สุดจนถึงตอนนี้ด้วยดาวน์และอัพ

— Obrix
แหล่งที่มา
เกี่ยวกับเหตุการณ์และการสร้างคลาสใหม่: คุณสามารถใช้ตัวกรองเหตุการณ์ในคลาสที่ต้องการตอบสนองต่อพวกเขา
— MrFox
"ใช่คุณสามารถใช้กิจกรรม แต่ !!! คุณได้สร้างคลาสใหม่สำหรับแต่ละวิดเจ็ตที่มีเหตุการณ์ที่กำหนดเองนี่คือประสิทธิภาพที่หายไปอย่างมาก" - ไม่แน่นอน ฉันเพิ่งจบด้วย bool eventFilter ที่จัดการวิดเจ็ตหลาย ๆ อันจากนั้น installEventFilter (นี่) บนวิดเจ็ตลูกทั้งหมด และนี่ไม่ได้เป็นการสูญเสียประสิทธิภาพและประสิทธิภาพของการเขียนโปรแกรม! ที่จริงฉันไม่เคยใช้ "วิดเจ็ตที่ได้รับการโปรโมต" ... ฉันปล่อยแค่วิดเจ็ตเปล่าธรรมดาติดตั้งมันเป็น eventFilter บนมันและนำเหตุการณ์ส่วนใหญ่ของฉันกลับมาใช้ใหม่ภายในคลาส cpp หลักของฉัน ลองไม่เจ็บปวด :) คุณสามารถปรับแต่งเกือบทุกอย่างใน Qt โดยไม่ต้องสร้างคลาสใหม่ทุกครั้ง
— ПетърПетров
3

จากความคิดเห็นของฉันการเรียนรู้การเขียนโปรแกรม C ++ นั้นง่ายกว่าการใช้ภาษาอื่นที่ซ่อนความซับซ้อนไว้และโปรแกรมเมอร์ไม่ทราบว่าเกิดอะไรขึ้นในพื้นหลัง ในทางตรงกันข้าม Qt เพิ่มประโยชน์บางอย่างมากกว่า C ++ เพื่อให้ระดับสูงกว่า C ++ ดั้งเดิม ดังนั้น Qt C ++ จึงเป็นกรอบงานที่ยอดเยี่ยมสำหรับผู้ที่ต้องการพัฒนางานระดับต่ำหรืองานระดับสูงด้วยวิธีเดียวกัน C ++ คือ (โดยวิธีปฏิบัติบางอย่าง) เป็นภาษาที่ซับซ้อนและเรียบง่าย ซับซ้อนสำหรับผู้ที่ไม่ต้องการท้าทายกับมันง่ายสำหรับผู้ที่ชอบ อย่าทิ้งไว้เพราะความซับซ้อน!

— user100691
แหล่งที่มา
2

เหตุผลที่แท้จริงไม่ใช่ทางเทคนิค

ผู้คนต่างกัน ดังนั้นทางเลือกของพวกเขาคือ ความสม่ำเสมอไม่ใช่คุณสมบัติของมนุษย์

— mouviciel
แหล่งที่มา
นั่นเป็นเหตุผลที่ทุกคนเดินบนขาของพวกเขา? ผู้ที่มีขาอย่างน้อย ...
— dtech
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.