Electron: Linux बिल्ड में GTK2 w GTK3 को बदलने पर विचार करें

हमारे द्वारा Chrome 47 में अपग्रेड करने के बाद यह मुझे अच्छा लगता है।

क्रोम 47 तीन दिन पहले जारी किया गया था। :) http://googlechromereleases.blogspot.se/2015/12/stable-channel-update.html

इसमें थोड़ा खोदो लेकिन अभी भी यह सुनिश्चित नहीं है कि use_gtk3 ध्वज कहां रखा जाए .. @zcbenz इसे करने के इच्छुक हैं?

@zcbenz या आप हमें संकेत दे सकते हैं कि इसे कहाँ रखा जाए?

मैं क्रोमियम के लिए बिल्ड सिस्टम के निर्माण व्यवहार में कोई विशेषज्ञ नहीं हूं, लेकिन वहां क्रोमियम से संबंधित बग से पढ़कर , यह ठीक होना चाहिए कि हम इसे variables से common.gypi जोड़ दें। प्रासंगिक रेखा यहां है ।

असल में मैं उसके लिए भी एक लिनक्स बॉक्स पर परीक्षण कर रहा हूं। मेरा वर्तमान विकास बॉक्स प्राथमिक ओएस चलाता है, और जब भी कोई Gtk2 एप्लिकेशन निष्पादित किया जाता है तो यह Gtk-Message: Failed to load module "pantheon-filechooser-module" ( Ref ) चेतावनी प्रदर्शित करेगा। अगर चीजें सुचारू होती हैं (उम्मीद है) चलो देखते हैं कि क्या मुझे पीआर भी मिल सकता है। हालांकि निश्चित रूप से आपके इनपुट्स को पसंद करेंगे।

इस पर किसी भी अद्यतन? एक परमाणु उपयोगकर्ता के रूप में मैं इसे GTK2 के बजाय GTK3 का उपयोग करते हुए देखना चाहूंगा।

@netsgnut क्या यह अच्छी तरह से काम करता है?

"%" का क्या मतलब है?

क्या केवल यही परिवर्तन है?

diff --git a/common.gypi b/common.gypi
index 7c41c36..d00d7f7 100644
--- a/common.gypi
+++ b/common.gypi
@@ -9,6 +9,7 @@
     'chromeos': 0,
     # Reflects node's config.gypi.
     'component%': 'static_library',
+    'use_gtk3': 1,
     'python': 'python',
     'openssl_fips': '',
     'openssl_no_asm': 1,

कोई खबर ? GTK2 खुला फ़ाइल संवाद उपयोग करने के लिए काफी दर्द भरा है!

@ फ्लाइंग-भेड़ आह, लंबी रेडियो चुप्पी के लिए खेद है। गिटहब से अन्य परियोजनाओं के लिए प्रतिबद्ध, मेरा बुरा।

हमारे मामले में वापस, यही वह था जो मुझे लगता है कि मूल रूप से काम करना चाहिए, लेकिन रहस्यमय तरीके से मेरे बॉक्स पर उचित Gtk3 एप्लिकेशन बनाने में विफल रहता है। मेरे मामले में, मेरा मूल इरादा एक इलेक्ट्रॉन निर्माण करना है जो मेरे विकास बॉक्स (जो प्राथमिक ओएस फ्रेया चला रहा है) के तहत त्रुटि का उत्सर्जन नहीं करेगा। हालांकि ऐसा लगता है कि इस तरह से निर्माण वास्तव में चेतावनी को दूर नहीं करेगा।

#4642 में, @zcbenz ने कहा:

use_gtk3 ध्वज केवल क्रोमियम की ओर से सार्थक है, GTK3 को सक्षम करने के लिए हमें पहले इसे libchromiumcontent में सक्षम करना होगा, और फिर इलेक्ट्रॉन में लिंक सेटिंग्स को बदलना होगा।

तो वास्तव में क्या करने की आवश्यकता है?

1. जोड़ने में एक ध्वज होगा: libchromiumcontent में GTK3 का उपयोग कर सक्षम chromiumcontent.gypi पर्याप्त हो? क्या यह महत्वपूर्ण है या इलेक्ट्रॉन उस लक्ष्य निर्माण का उपयोग नहीं करता है?
2. इलेक्ट्रॉन में लिंक सेटिंग्स बदलें: यह कहां करें?

मैं इस क्षेत्र का कोई विशेषज्ञ नहीं हूं, और मुझे यकीन नहीं है कि मैंने @zcbenz की टिप्पणी को गलत

प्रश्नों के संबंध में:

1. शायद नहीं। libchromiumcontent , लगता है इसके बारे में नज़र से, स्क्रिप्ट का एक समूह नदी के ऊपर से डाउनलोड क्रोमियम स्रोत , पैच , और repackages एटम में इस्तेमाल के लिए। जैसा कि आपने उल्लेख किया है, chromiumcontent.gypi पर एक ध्वज बदलने के अलावा, कम से कम निर्भरता पुस्तकालयों को भी ठीक से पैक किया जाता है । libgtk2ui के उदाहरण देखें।
2. इलेक्ट्रॉन में ऐसे जो libgtk2- विशिष्ट UI का संदर्भ देते हैं । वे क्रोमियम (और/या डेरिवेटिव) के भीतर एक निर्भरता की ओर इशारा करते हैं। "लिंक" जैसा कि @zcbenz की टिप्पणी में है, शायद उन लोगों को देखें।

क्रोमियम पर ट्रैकिंग बग अपस्ट्रीम से किसी प्रकार की स्थिति को दर्शाता है। टिप्पणीकारों में से एक ध्यान दें:

IIRC, इसे क्रोम/ब्राउज़र/ui/libgtk2ui/ से मेल खाने के लिए एक libgtk3ui लाइब्रेरी बनाने की आवश्यकता होगी, और इन दो पुस्तकालयों को स्टार्टअप समय पर स्विच करना होगा।

और, लेखन के समय, libgtk3ui अभी तक मौजूद नहीं है :( आप libgtk2ui पर भी कोड देख सकते हैं।

मूल रूप से इसे पोस्ट करने के बाद मैं व्यक्तिगत लैपटॉप के बीच था और कुछ महीनों के लिए मेरी कंपनी द्वारा जारी एमबीपी का उपयोग कर रहा था। लेकिन मेरे पास आखिरकार मेरी नई मशीन है, डाउनटाइम और इस पर एक स्टैब लेने का फैसला किया। मेरी अब तक की प्रगति:

मैं gtk3 के साथ निर्माण करने के लिए libchromiumcontent प्राप्त करने में सक्षम था, इसमें निम्नलिखित शामिल थे:

• chromiumcontent.gypi में 'use_gtk3': 1 जोड़ें।
• स्क्रिप्ट/अपडेट में install_sysroot() लिए कॉल को मैन्युअल रूप से टिप्पणी करके अक्षम sysroot। नोट: libchromiumcontent संस्करण के आधार पर, आपको use_sysroot में chromium/src/build/common.gypi से 'use_sysroot': 0 पर सेट करने की आवश्यकता हो सकती है। मुझे लगता है कि भविष्य में सही दृष्टिकोण निर्माण में क्रॉस-कंपाइलिंग क्षमता के लिए debian_jessie पर स्विच करना होगा?
• भाग गया pkg-config:

pkg-config --cflags gtk+-3.0 wayland-protocols gl egl glib-2.0 x11 gdk-3.0 gmodule-2.0 gthread-2.0 gtk+-unix-print-3.0 libpulse atk --libs gtk+-3.0 wayland-protocols gl egl glib-2.0 x11 gdk-3.0 gmodule-2.0 gthread-2.0 gtk+-unix-print-3.0 libpulse atk && export PKG_CONFIG_PATH=/usr/lib/pkgconfig:/usr/share/pkgconfig

• भाग गया script/update -t x64 && script/build -t x64 && script/create-dist -t x64
• घंटों इंतजार किया :)

हालाँकि, मैं दुर्भाग्य से बिल्ड समाप्त होने के बाद थोड़ा बहुत आशावादी था, यह सोचकर कि यह एक इलेक्ट्रॉन निर्माण के लिए एक ड्रैग एन 'ड्रॉप है, लेकिन निश्चित रूप से ऐसा नहीं था। मुझे लगता है कि अगला कदम एक स्थानीय ब्राइट्रे का निर्माण करना है और जो भी अन्य जिप फाइलें मेरे सिस्टम लिबास का उपयोग करने के लिए अपडेट की गई हैं न कि sysroot।

और libgtk2ui के संबंध में - मुझे उस संदर्भ का पता लगाने में परेशानी हो रही है जहां मैंने इसे पढ़ा है (शायद जेंटू फ़ोरम, क्रोमियम इश्यू ट्रैकर या एक आर्क लिनक्स कम्युनिटी थ्रेड) - लेकिन मेरा मानना ​​​​है कि क्रोमियम gtk3/gtk2 की परवाह किए बिना libgtk2ui बनाता है क्योंकि काम करने के लिए gtk3 के साथ निर्माण करने के लिए देव न्यूनतम न्यूनतम कर रहे थे। मैं गलत हो सकता था और मुझे नहीं पता कि यह किसी भी इलेक्ट्रॉन-आधारित पैच को कैसे प्रभावित कर सकता है जो विशेष रूप से gtk2 के लिए लिखे गए थे।

मैं अपने व्यक्तिगत ब्राउज़र के लिए एक साप्ताहिक क्रोमियम-gtk3 बिल्ड करता हूं और libgtk2ui अभी भी मौजूद है और मैं इसका उपयोग कर रहा हूं।

मैं अगले कुछ दिनों में उम्मीद के साथ यहां वापस आऊंगा और अपने पीओसी रेपो को प्रीबिल्ट बायनेरिज़ और कुछ स्क्रीनकैप्चर के साथ लिंक करूंगा।

हो गया और मैं आशा करता हूँ कि atom-gtk3 ऊपर और जल्द ही चल रहा होगा!

सबसे बड़ी बाधा थी debian_wheezy_sysroot का उपयोग पूरे libchromium सामग्री/इलेक्ट्रॉन/ब्राइट्रे में किया जा रहा था। उन रेपो के अनुरक्षकों को शायद कुछ चर्चा करने और निर्णय लेने की आवश्यकता होगी कि क्या जेसी पर स्विच करना है या संभवतः सिसरूट को वैकल्पिक बनाना है।

सप्ताहांत में मैं एक वितरण योग्य इलेक्ट्रॉन gtk3 निष्पादन योग्य बनाने के लिए एक नोड या बैश स्क्रिप्ट को एक साथ रखने की कोशिश करूंगा। मुझे नहीं लगता कि मेरे द्वारा किए गए किसी भी पुल अनुरोध को स्वीकार किया जाएगा, इसलिए अभी के लिए साथी gtk3 उपयोगकर्ताओं के लिए बिल्ड प्राप्त करने और उसका उपयोग करने के लिए यह संभवतः प्रभावी तरीका होगा। और अगले कुछ हफ्तों में मैं अपने साथी आर्क उपयोगकर्ताओं के लिए कुछ AUR पैकेज प्राप्त करने का प्रयास भी कर सकता हूं।

इलेक्ट्रॉन निर्माण के दौरान ये gtk3 चेतावनियाँ थीं https://gist.github.com/nikolowry/05865698788d66ae0edfea2eb7c7fb0c

@nicolowry क्या हमारे लिए sysroot रखने का कोई तरीका है लेकिन GTK+ 3.x में sysroot में कॉपी करें?

@paulcbetts मुझे लगता है कि अगर wayland-protocols glib-2.0 gdk-3.0 gtk+-unix-print-3.0 ।

बहुत बढ़िया लगता है @nicolowry , आपके काम के लिए धन्यवाद। क्या स्रोत कोड कहीं उपलब्ध है? मैं उबंटू उपयोगकर्ताओं के लिए जीवन को आसान बनाने के लिए पीपीए तैयार करना पसंद करूंगा।

मैं यह भी जोड़ना चाहूंगा कि यह मुद्दा केवल आधुनिक विजेट प्रदान करने का प्रश्न नहीं है। GTK2 HiDPI सिस्टम पर उपयोग करने योग्य नहीं है (कम से कम ubuntu 16.04 के साथ नहीं) क्योंकि बटन और टूलबार के सभी आइकन बेहद छोटे हैं। सौभाग्य से एटम के मामले में ऐसा लगता है कि यह केवल फ़ाइल खुले संवाद को प्रभावित करता है, कम से कम जहां तक ​​​​मैं देख सकता हूं, इसलिए एटम स्वयं काफी उपयोगी रहता है।

@EiNSTEiN मैं सप्ताहांत के अंत तक शीघ्र ही एक इलेक्ट्रॉन-gtk3 रेपो से लिंक करूंगा।

पहले थोड़ा बैकस्टोरी - इस काम को करने के लिए मेरे दृढ़ संकल्प का मुख्य कारण यह था कि मैं अपने दैनिक ड्राइवर के रूप में एटम का उपयोग करता हूं और अब फ़ाइल संवाद देखने के लिए खड़ा नहीं हो सकता! हालांकि, असर/संकलित-कैश/एनपीएम-नॉट-रनिंग-पोस्ट-इंस्टॉल-स्क्रिप्ट के साथ जटिलताओं के कारण उस निर्माण में अपेक्षा से अधिक समय लगा, लेकिन अब मैं जाने के लिए अच्छा हूं।

मैं ऐसा करने के सर्वोत्तम तरीके पर विचार कर रहा था - इसलिए अनुरक्षकों के पास एक अच्छा संदर्भ होगा (यह सभी व्यक्तिगत रेपो में पुल अनुरोधों का समन्वय करना कठिन होगा) और इसलिए gtk3-होगा-उपयोगकर्ता उठ सकते हैं और चल सकते हैं जल्दी असंभव।

लेकिन मैं स्वचालित बिल्ड नहीं करूंगा, इसलिए सभी को 4-6 घंटे के निर्माण समय के लिए या कुछ सर्वर तैयार करने के लिए तैयार रहना चाहिए। जब तक ये परिवर्तन आधिकारिक रेपो में परिलक्षित नहीं हो जाते, तब तक मैं कभी-कभार रिलीज कर सकता हूं।

मैं एक सबमॉड्यूल के रूप में इलेक्ट्रॉन के साथ एक रेपो बनाने और सभी gtk3 अच्छाई के साथ इलेक्ट्रॉन के निर्माण के लिए एक एकल बैश स्क्रिप्ट लिखने पर संकुचित हो गया हूं। तब प्रत्येक डिस्ट्रो के पास अंततः पैकेज वितरित करने के लिए एक आसान प्रारंभिक बिंदु हो सकता है जब तक कि ये परिवर्तन वास्तव में औपचारिक रूप से न हों।

और हिडपी नोट पर - atom-gtk3 लिए मेरा निष्पादन cmd GTK_THEME=Adwaita:dark GDK_SCALE=2 GDK_DPI_SCALE=.5 /usr/local/share/atom/atom --force-device-scale-factor=1.5 %U । GDK पैमाने के झंडे chromium-gtk3 ui फ़ॉन्ट आकार को भी ठीक करते हैं। atom-gtk3 की कुछ स्क्रीन यहां दी गई हैं:

https://goo.gl/ydHspu

नमस्ते,

मैं आर्क लिनक्स पर GTK3 के साथ इलेक्ट्रॉन 1.1.2 को संकलित करने में सक्षम था, use_gtk3=1 को libchromiumcontent में पास कर रहा था और gtk+-2.0 को gtk+-3.0 में Brightray.gyp में

अब जब भी मैं कोई कुंजी दबाता हूं तो इलेक्ट्रॉन का डिफ़ॉल्ट ऐप क्रैश हो जाता है।

यहां विवरण: https://github.com/tensor5/arch-atom।

बिल्ड स्क्रिप्ट रेपो:
https://github.com/nikolowry/electron-gtk3

उम्मीद है कि सप्ताह के अंत तक इसे पूरा कर लिया जाएगा। यह एक डब्ल्यूआईपी है और अभी तक कुछ भी सार्थक नहीं बनाता है।

@EiNSTEiN और @tensor5 - https://github.com/nikolowry/electron-gtk3 अब बन रहा है। ध्यान दें कि यह केवल release संस्करण बनाता है जब तक कि आप इसे विशेष रूप से debug और release दोनों को बनाने के लिए नहीं कहते हैं। README देखें और अगर कुछ काम नहीं कर रहा है तो एक समस्या खोलें।

@zcbenz क्या डेबियन

संपादित करें: @ tensor5 क्या आप एक्स या वेलैंड का उपयोग कर रहे हैं? मुझे पता है कि वेलैंड में प्रमुख इनपुट इवेंट पर क्रोमियम gtk3 बिल्ड क्रैश हो रहे हैं।

@nikolowry : हाँ मैं वेलैंड का उपयोग कर रहा था, और वास्तव में यह एक्स के साथ ठीक काम करता है, धन्यवाद। क्या आप जानते हैं कि क्या इस क्रोमियम मुद्दे पर कहीं चर्चा की गई है?

यह मिला: https://bugs.chromium.org/p/chromium/issues/detail?id=615164।

@nikolowry हम केवल क्रोमियम के निर्माण विन्यास का अनुसरण कर रहे हैं, बहुत सारे लिनक्स वितरण हैं और हम उन सभी का परीक्षण करने में सक्षम नहीं हैं, जबकि क्रोमियम हर जगह पूरी तरह से परीक्षण किया जाता है, इसलिए क्रोमियम का पालन करना सुरक्षित है।

मैं GTK+3 के निर्माण के लिए एक ध्वज जोड़ना अच्छा कर रहा हूं, और आपकी बिल्ड स्क्रिप्ट में एक लिंक जोड़ना भी मुझे अच्छा लगता है। यह लिनक्स बिल्ड इंस्ट्रक्शन के उन्नत विषयों का हिस्सा हो सकता है।

@zcbenz अच्छा लगता है - उनके पास एक अजगर स्क्रिप्ट है जिसे कोई चला सकता है जो

सामान्य तौर पर, सबसे पुराने डिस्ट्रो के खिलाफ निर्माण करना एक अच्छी बात है जब ग्लिब ++ वर्जनिंग के कारण सॉफ्टवेयर वितरित करने की बात आती है - जेसी में अपग्रेड (हालांकि मैं इसे सामान्य रूप से सुरक्षित मानता हूं) अनाथ लोग जो इलेक्ट्रॉन में काम कर रहे थे भूतकाल। हमने इस मुद्दे को आरएचईएल उपयोगकर्ताओं के साथ बहुत मारा

@ tensor5 ने पता लगाया कि वेलैंड में कैसे लॉन्च किया जाए। मैंने उस क्रोमियम टिकट पर टिप्पणी की और अपना gtk3 रेपो अपडेट किया।

बस GDK_BACKEND=x11 electron चलाने की जरूरत है क्योंकि क्रोमियम स्वचालित रूप से XWayland मॉड्यूल में हुक नहीं करता है।

@nicolowry बहुत बढ़िया!

इसलिए अगर मैं सही ढंग से समझूं, तो समस्या यह है कि GTK3 को लगता है कि इलेक्ट्रॉन एक शुद्ध वेलैंड एप्लिकेशन है, जबकि ऐसा नहीं है।

@ tensor5 बिल्कुल! GTK3 मानता है कि टूलकिट का उपयोग करने वाले सभी ऐप्स वेलैंड के लिए तैयार हैं (इस प्रकार यदि आवश्यक हो तो XWayland को लोड करने के लिए जिम्मेदार)।

मैं इस सप्ताह के अंत में क्रोमियम स्रोत-कोड में घुटने तक जाने के लिए तैयारी कर रहा था, और जैसा कि मैं कुछ लॉग उत्पन्न करने की कोशिश कर रहा था, मैं https://fedoraproject.org/wiki/How_to_debug_Wayland_problems के माध्यम से सरल समाधान पर ठोकर खाई

क्रोमियम और एटम मेरे अंतिम गैर-वेलैंड-रेडी ऐप्स थे - बहुत खुश मेरा स्काईलेक लैपटॉप अब xrandr के माध्यम से क्रैश नहीं होगा जब मिश्रित डीपीआई मोड में मल्टी-मॉनिटर से जुड़ा होगा !!!!

संपादित करें: मुझे पता है कि आप कुछ AUR पैकेज भी बनाए रखते हैं, इसलिए हो सकता है कि आप "env GDK_BACKEND=x11" को शामिल करने के लिए डेस्कटॉप फ़ाइलों को संपादित करना चाहें, यह ऐप्स को X और Wayland दोनों में चलाने की अनुमति देगा और बाकी सभी को सिरदर्द से बचाएगा भविष्य!

@nikolowry मैं पहले से ही इस पर हूँ!

आखिरकार इसे इलेक्ट्रॉन स्रोत में तय किया जाना चाहिए, लॉन्चर स्क्रिप्ट का उपयोग करना सबसे सुंदर तरीका नहीं है।

BTW AUR पैकेज मेरा नहीं है। मैं एक भंडार बनाए रखता हूं

@nikolowry Firefox भी एक यहां देख सकते हैं, यह पहले X11 बैकएंड की कोशिश करता है, और फिर gdk_display_open लिए डिटेक्टेड डिस्प्ले_नाम का उपयोग करता है।

क्रोमियम में शायद ऐसा ही कुछ किया जा सकता है।

प्राथमिक ओएस पर हमें पैन्थियॉन-फाइल-चयनकर्ता का उपयोग करने के लिए जीटीके 3 की आवश्यकता है, या हम इन्हें प्राप्त करेंगे:

Gtk-Message: Failed to load module "pantheon-filechooser-module"

Qt5-WebEngine को सिर्फ सपोर्ट/पोर्ट क्यों नहीं? यह वैसे भी क्रोमियम के इंजन का उपयोग करता है, और क्यूटी पर सब कुछ जीटीके के विपरीत अधिक देशी दिखता है ...

प्लस qt5 gtk3 की तरह हर समय नहीं टूटता है जो अपने F ** किंग एपीआई को हर बार सिर्फ इसलिए बदलता है क्योंकि वे सूक्ति विकास के अलावा किसी और चीज की परवाह नहीं करते हैं।

यहाँ एक बढ़िया वीडियो प्रस्तुति है कि क्यों gtk खराब है और qt बेहतर है (2 साल पुराना लेकिन फिर भी अच्छा और प्रासंगिक)

क्यूटी 5.6.x अब एलटीएस में है और उनका लाइसेंस 5.7 के साथ बदल गया है , यह ओपन सोर्स उपयोगकर्ताओं/देवों के लिए बेहतर है

मैं व्यक्तिगत रूप से नहीं जानता कि लोग gnome सामग्री के बाहर gtk का उपयोग क्यों कर रहे हैं, जब इसे इसके लिए डिज़ाइन नहीं किया गया है।

@ahjolinna वास्तव में जीटीके + का उपयोग जीनोम सामग्री के बाहर भी अनुप्रयोग विकास के लिए किया जाना है। किसी भी तरह से एपीआई को क्यूटी में बदलना इलेक्ट्रॉन टीम के लिए एक बुरा सपना होगा क्योंकि इसमें क्रोमियम अपस्ट्रीम से बहुत सी चीजों को पैच करने की आवश्यकता होगी। यह परेशानी के लायक नहीं है।

GTK+3 _is_ आंतरिक रूप से GNOME से विवाहित है, क्योंकि मूल रूप से (?) सभी GTK देव GNOME देव हैं, जिन्हें लाल टोपी द्वारा नियोजित किया गया है।

उल्लिखित जीटीके एपीआई टूटना इसलिए होता है क्योंकि लाल टोपी गनोम को आगे बढ़ाने को प्राथमिकता देती है। @ahjolinna सही है कि Qt5 अधिक स्थिर है, _but_ यह केवल क्रोमियम इंस्टेंस तक सीमित पहुंच प्रदान करता है।

कारण भी स्थिरता है: क्रोमियम स्वयं ही इतना टूट जाता है कि वे कुछ क्षेत्रों में अपने स्थिर एपीआई को बनाए रखने के लिए केवल अपने संसाधनों को प्रतिबद्ध कर सकते हैं।

@nikolowry अगर मैं gtk3 समर्थन के साथ इलेक्ट्रॉन बनाने के लिए https://github.com/nikolowry/electron-gtk3 का उपयोग करता, तो परमाणु-gtk3 बनाने के लिए मुझे परमाणु निर्माण में क्या बदलाव करने की आवश्यकता होगी?

gtk3 बिल्ड का उपयोग करने वालों के लिए, संभवतः आपको लाइट थीम का उपयोग करते समय मेनू बार पर सफेद टेक्स्ट दिखाई दे रहा है। यह पैच समस्या का समाधान करता है।

मैं अगले दिनों में अन्य gtk3 बिल्ड चेतावनियों को ठीक करने जा रहा हूँ।

Gtk2 के साथ क्रोमियम में मेनू 'देशी gtk शैली' नहीं है, और बहुत बदसूरत है। क्या Gtk3 इसे ठीक करेगा?

@मेन्सी। नहीं, gtk3 वाला मेनू बार बिल्कुल वैसा ही दिखता है जैसा gtk2 के साथ होता है। आप सही हैं, यह पूरी तरह से मूल नहीं है, बस टेक्स्ट और बैकग्राउंड के रंग gtk थीम का अनुसरण करते हैं।
मैंने पिछले दिनों कोड को देखा, यह देखने के लिए कि क्या इसे ठीक किया जा सकता है। एक समस्या यह है कि क्रॉस प्लेटफॉर्म रैपर की परतों के पीछे देशी जीटीके कोड छिपा हुआ है। हो सकता है कि जीटीके विशेषज्ञ इसमें मदद कर सकें।

@ tensor5 मुझे लगता है कि मेनू को क्रॉस प्लेटफॉर्म रैपर में लागू किया जाना चाहिए। जैसे ओएस एक्स का मेन्यू देशी है और देशी कोको कोड भी क्रॉस प्लेटफॉर्म रैपर की परतों के पीछे छिपा हुआ है।

@ मेंसी बेशक, इस तरह के पैच को स्वीकार करने का यही एकमात्र तरीका है।

Gnome ऐप मेन्यू रखना भी अच्छा होगा।

आप देख सकते हैं कि लिब्रे ऑफिस ने इसे कैसे किया, यह इसी तरह से है।

मुझे लगता है कि लिब्रे ऑफिस के मेनू वास्तव में देशी नहीं हैं। थाय में ड्रॉप शैडो नहीं है और एनिमेशन दिखाना/छिपाना नहीं है।

http://caolanm.blogspot.sk/2016/02/native-gtk3-menubar-in-libreoffice.html

GTK+ ऐप्स ने कभी भी gnome (और अन्य gtk spinoffs) के बाहर देशी नहीं देखा है, वे हमेशा KDE, LXQt पर भयानक दिखते हैं) और यूनिटी 8 के आने पर वही समस्या होगी (इसकी Qt5 आधारित)। केडीई टीम ने इसे जारी करने के साथ जीटीके टीम के साथ काम करने की कोशिश की है, लेकिन वे 100% बेवकूफ हैं और उन्हें इस बात की परवाह नहीं है कि उनका एपीआई हर लानत अपडेट के साथ बदलता / टूटता है और यह (कुछ) केडीई सामान जैसे हवा-जीटीके थीम को तोड़ देगा , जो बीटीडब्ल्यू। gtk टीमों के मूर्खतापूर्ण तर्क के कारण हार्डकोड करना पड़ा।*

बीटीडब्ल्यू। KDE, LXQt और Unity 8 + Ubuntu Touch और SailfishOS के साथ, Qt5 "मार्केटशेयर" gtk से बड़ा हो गया है और कम से कम लंबी अवधि में इसका बहुत बड़ा प्रभाव पड़ेगा

पुनश्च. लिब्रेऑफ़िस के बारे में, आप इसे जीटीके के बिना बना सकते हैं और इसे मूल फ़ाइलपिकर का उपयोग कर सकते हैं, उदाहरण के लिए चक्रोस क्या करता है, पीकेजीबीयूआईएलडी , क्यों? क्योंकि इसका केडीई/क्यूटी केंद्रित डिस्ट्रो जो जितना संभव हो सके जीटीके का उपयोग करने से बचना पसंद करता है

संपादित

*जीटीके डेवलपर्स ने थीम इंजन तक पहुंच को अवरुद्ध कर दिया, जो पहले केडीई में जीटीके एकीकरण के लिए उपयोग किया जाता था, इसलिए अब "सीएसएस तरीका" को आजमाने का एकमात्र तरीका है

कुछ ऐप्स जिन्हें मैं जानता हूं जो Qt का उपयोग करते हैं:
ड्रॉपबॉक्स, OBS, MEGA, VIber, Wireshark, makemkv, yacreader, Masterpdfeditor, vaporsynth-editor, SVP, teampeak3, mkvtoolnix-gui, hplip, scribus WPS-office...

Qt5 का उपयोग करने वाले अन्य DE: http://papyros.io/ और https://lumina-desktop.org/

@ahjolinna मुझे लगता है कि आप गलत भीड़ को समझाने की कोशिश कर रहे हैं। यदि क्रोमियम स्विच नहीं बना रहा है तो मुझे अत्यधिक संदेह है कि इलेक्ट्रॉन स्विच करेगा। इलेक्ट्रॉन टीम को इस परियोजना को बनाए रखने के लिए कहने के साथ-साथ क्रोमियम का एक क्यूटी 5 कांटा बहुत अधिक मांग रहा है।

इसके अतिरिक्त यह समस्या GTK2 को GTK3 से बदलने के बारे में है। यदि आप उन्हें एक स्विच पर विचार करना चाहते हैं तो कृपया एक नया मुद्दा बनाएं। अन्यथा यह विषय से हटकर है और इस धागे को शोर से भर देता है।

@alzadude आपको कुछ प्रीबिल्ट इलेक्ट्रॉन को डाउनलोड न करे, पैकेज को संपादित करें। इलेक्ट्रॉन बिल्ड से मेल खाने के लिए पैकेज को संपादित करें जो आपने स्थानीय रूप से gtk3 के साथ किया था और शायद एक अजगर संपादित या दो (क्षमा करें बंद हो रहा है) स्मृति अभी)। यह मुश्किल नहीं है लेकिन जब मैं एक नया निर्माण करता हूं तो मुझे हमेशा एक मिनट लगता है क्योंकि मैं हमेशा पिछले पिछले निर्माण में उठाए गए कुछ कदमों को भूल जाता हूं।

यदि @ tensor5 अपने आर्क-एटम रेपो में gtk3 का उपयोग करना शुरू कर रहा है, तो मैं सुझाव दूंगा कि शायद इसे आज़माएँ - अन्यथा मैं अगली बार जब मैं एक बिल्ड करूँगा और आपके लिए परिवर्तनों का दस्तावेज़ीकरण करूँगा (आमतौर पर उन्हें करते हैं) सप्ताहांत)

@nikolowry धन्यवाद, कुछ दस्तावेज परिवर्तन बहुत अच्छे होंगे :)

मैं फेडोरा पर हूं इसलिए मैं इस फेडोरा कॉपर के आधार पर परिवर्तनों को शामिल करना चाहता हूं:

https://copr.fedorainfracloud.org/coprs/mosquito/atom/

ऐसा लगता है कि यह कॉपर वर्तमान में फेडोरा पर एक मानक पैकेज की सबसे नज़दीकी चीज है। यह इन अपस्ट्रीम आरपीएम स्पेक फाइलों पर आधारित है:

https://github.com/FZUG/repo/tree/master/rpms/atom

और इस बगजिला बग में उल्लेख किया गया है:

https://bugzilla.redhat.com/show_bug.cgi?id=1132661

मौजूदा काम के आधार पर मैं संभवतः अपना खुद का कॉपर बनाना चाहता हूं, gtk3 इलेक्ट्रॉन और एटम के निर्माण के लिए (दस्तावेज परिवर्तनों के आधार पर आवश्यक पैच को शामिल करने के लिए अपस्ट्रीम आरपीएम स्पेक फाइलों को फोर्क करना)। जब तक कोई और मुझे निश्चित रूप से मारता है :)

मैं इसके लिए एक जेंटू ईबिल्ड लिखने की कोशिश कर रहा हूं, लेकिन बिना किसी सफलता के। मैं बहुत आभारी रहूंगा, अगर किसी ने मुझे ऐसा करने में मदद की।

@ शाश्वत-दुःख क्या आपने पहले से ही देव-उपयोग/इलेक्ट्रॉन पर एक नज़र डाली है, जो कि वर्तमान में आधिकारिक जेंटू पेड़ में है?

@devurandom , मैंने किया। यह इलेक्ट्रॉन का बहुत पुराना संस्करण है (0.36.12)। मैंने इसे वर्तमान संस्करण (1.3.1) के लिए संशोधित किया, सभी पैचों को अनुकूलित किया, लेकिन फिर भी एक v8 लिंकिंग समस्या (बहुत सारे अपरिभाषित v8 प्रतीक) प्राप्त कर रहा था।

@अनन्त-दुःख

1. उस पैकेज के अनुरक्षक [email protected] से संपर्क करें।
2. जीएच पर अपने ईबिल्ड के साथ एक ओवरले रेपो सेट करें, हो सकता है कि हम इसे एक साथ काम कर सकें।

@ आर्क लिनक्स में शाश्वत-दुख हम GTK3 के साथ इलेक्ट्रॉन का नवीनतम संस्करण बनाते हैं, इसे देखें।

इस पर कोई प्रगति?

@nikolowry , आप अपने परमाणु-gtk3 में परमाणु और इलेक्ट्रॉन के किस संस्करण का उपयोग कर रहे हैं? मैंने महसूस किया कि परमाणु के वर्तमान संस्करणों में इलेक्ट्रॉन-0.37 की आवश्यकता होती है और यह इलेक्ट्रॉन के वर्तमान संस्करणों के साथ नहीं चल सकता। क्या मै गलत हु?

@ शाश्वत-दुःख परमाणु हाल ही में इलेक्ट्रॉन के एक नए संस्करण में अद्यतन किया गया था।

https://github.com/atom/atom/blob/efae2e08c3f902149431732cbd550aea09748acc/package.json#L15

क्या gtk3 का उपयोग करने का कोई तरीका है? विशेष रूप से बेहतर फ़ाइल संवाद के लिए इसे पसंद करेंगे।

चूँकि आर्चलिनक्स में पहले से ही एक gtk3 बिल्ड है, जो इसमें नहीं है वह इलेक्ट्रॉन कोर है?

मुझे लगता है कि वे चाहते हैं कि स्विच अपस्ट्रीम हो। और यह अब आधिकारिक रूप से नियोजित है, https://chromium.googlesource.com/chromium/src/+/acc4214c4dece4e70fb53355d557bd45f35965d6/docs/linux_gtk_theme_integration.md#GTK3 देखें।

अतिरिक्त जानकारी, क्रोमियम/गूगल क्रोम देव चैनल gtk 3 का उपयोग कर रहे हैं, इसलिए यह अभी समय की बात है।

Chrome 59 के लिए https://bugs.chromium.org/p/chromium/issues/detail?id=79722#c110 पर पुष्टि की गई है

अभी कुछ ही समय की बात है...

क्रोम 59 बाहर है! टाडा:

अब जब क्रोम 59 बाहर हो गया है तो लिनक्स के लिए GTK3 के साथ निर्मित इलेक्ट्रॉन प्री-रिलीज़ देखना बहुत अच्छा होगा।

GTK3 समर्थन अब क्रोमियम स्थिर (59) में है, जिसका अर्थ है कि यह जल्द ही इलेक्ट्रॉन में समर्थित होगा! एक Linux नौसिखिया के रूप में, मैं वास्तव में GTK3 से परिचित नहीं हूँ। इस थ्रेड और गुगलिंग के माध्यम से पढ़कर, मुझे पता चला है कि इस अपग्रेड से मेनू, विंडो, डायलॉग आदि की उपस्थिति में सुधार होगा। मुझे लगता है कि यह एक ब्लॉग-योग्य अपडेट हो सकता है, लेकिन इस बारे में और जानना अच्छा लगेगा कि यह परिवर्तन उपयोगकर्ताओं को कैसे प्रभावित करता है।

मेरे कुछ प्रश्न हैं:

• आप GTK3 समर्थन क्यों चाहते हैं?
• मैं इस धागे में "फ़ाइल संवाद" का बहुत उल्लेख करता हूं। GTK2 में इसमें क्या गलत था और GTK3 में इसे कैसे सुधारा गया?
• क्या यह अपडेट प्रदर्शन, अनुकूलता आदि जैसी चीजों में सुधार करता है? या सिर्फ यूआई?
• लोग और क्या सुधार की उम्मीद कर सकते हैं?
• कौन से लिनक्स डिस्ट्रो जीटीके(3) का उपयोग करते हैं?

@ज़ेके :

आप GTK3 समर्थन क्यों चाहते हैं? मैं इस धागे में "फ़ाइल संवाद" का बहुत उल्लेख करता हूं।

एक सुधार जिसमें मेरी दिलचस्पी है, वह यह है कि फ़्लैटपैक सैंडबॉक्स के अंदर चल रहे इलेक्ट्रॉन अनुप्रयोग अब होस्ट पर एक पोर्टल का मूल रूप से उपयोग करेंगे। यदि उपयोगकर्ता के पास Qt पोर्टल स्थापित है तो यह सही Qt एक का भी उपयोग करेगा।

क्या यह अपडेट प्रदर्शन, अनुकूलता आदि जैसी चीजों में सुधार करता है? या सिर्फ यूआई?

सिद्धांत रूप में Gtk3 का hidpi समर्थन प्रासंगिक हो सकता है, लेकिन मुझे नहीं पता कि यह क्रोमियम के प्रतिपादन के साथ कैसे इंटरैक्ट करता है जो उसमें से अधिकांश को बायपास कर देगा। तो शायद यह केवल थीम बदलता है।

कौन से लिनक्स डिस्ट्रो जीटीके(3) का उपयोग करते हैं?

प्रभावी रूप से सभी डिस्ट्रो में Gtk3. Unity, GNOME, MATE, Cinnamon, Budgie, और अंततः XFCE अनुप्रयोगों के लिए अपने मुख्य टूलकिट के रूप में Gtk3 का उपयोग करते हैं।

@zeke

कौन से लिनक्स डिस्ट्रो जीटीके(3) का उपयोग करते हैं?

सभी प्रमुख लिनक्स डिस्ट्रो अपने डेस्कटॉप (शेल) के लिए GTK3 का उपयोग करते हैं। कुछ में केडीई स्वाद भी होता है लेकिन उन सभी के लिए डिफ़ॉल्ट जीटीके3 है।

मैं इस धागे में "फ़ाइल संवाद" का बहुत उल्लेख करता हूं। GTK2 में इसमें क्या गलत था और GTK3 में इसे कैसे सुधारा गया?

हां, GTK2 और GTK3 एप्लिकेशन एक ही सिस्टम में एक साथ रह सकते हैं, GTK3 एप्लिकेशन वर्तमान डेस्कटॉप के साथ बेहतर एकीकृत हैं। फ़ाइल चयनकर्ता संवाद एक अच्छा उदाहरण है।

@zeke

आप GTK3 समर्थन क्यों चाहते हैं?

मैं एकरूपता को महत्व देता हूं - जीटीके 3 पर फ़ाइल संवाद काफी अलग है, जीटीके संस्करणों के बीच विषय अक्सर थोड़ा असंगत होते हैं। मुझे अपने सिस्टम को न्यूनतम रखना भी पसंद है, एटम ड्रॉपिंग जीटीके 2 का मतलब जीटीके 2 स्थापित करने का एक कम कारण होगा।

मैं इस धागे में "फ़ाइल संवाद" का बहुत उल्लेख करता हूं। GTK2 में इसमें क्या गलत था और GTK3 में इसे कैसे सुधारा गया?

ऊपर के रूप में, मेरे लिए सबसे महत्वपूर्ण चीज निरंतरता है। GTK 3 संवाद वास्तव में कुछ लोगों द्वारा हीन माना जाता है, क्योंकि यह निर्देशिका में वृद्धिशील खोज के बजाय पुनरावर्ती नाम खोज का उपयोग करता है।

लोग और क्या सुधार की उम्मीद कर सकते हैं?

मेनू को जीटीके का भी उपयोग करना चाहिए, एक कस्टम कार्यान्वयन के बजाय जो निमोनिक्स का समर्थन नहीं करता है और तीर कुंजियों का उपयोग करके आसन्न मेनू के बीच कूदता है।

एटम ड्रॉपिंग GTK 2 का मतलब GTK 2 को स्थापित करने का एक कम कारण होगा।

बस इसलिए मैं समझता हूं कि आप यहां क्या कह रहे हैं, @jtojnar : यदि आपके पास लिनक्स का एक नया संस्करण है जो डिफ़ॉल्ट रूप से

@zeke स्थापना निर्भरता आमतौर पर आपके वितरण के पैकेज प्रबंधक द्वारा स्वचालित रूप से की जाती है, जीटीके 3 ऐप इंस्टॉल करने से libgtk3 भी डाउनलोड हो जाएगा और जीटीके 2 ऐप इंस्टॉल करने से libgtk2 प्राप्त होगा। आप दोनों को सुरक्षित रूप से स्थापित कर सकते हैं, यह सिर्फ इतना है कि एक एसएसडी कम जगह के साथ, मैं हर विरासत पैकेज से छुटकारा पाना चाहता हूं जो मैं कर सकता हूं।

आप GTK3 समर्थन क्यों चाहते हैं?

GTK3 नया है और इसमें HiDPI सपोर्ट है।
GTK2 अब विकसित नहीं हुआ है और न ही आधुनिक है।

मैं इस धागे में "फ़ाइल संवाद" का बहुत उल्लेख करता हूं। GTK2 में इसमें क्या गलत था और GTK3 में इसे कैसे सुधारा गया?

इस बारे में नहीं जानते।

क्या यह अपडेट प्रदर्शन, अनुकूलता आदि जैसी चीजों में सुधार करता है? या सिर्फ यूआई?

कहा जाता है कि GTK3 कुछ CPU और RAM सुविधाओं का बेहतर उपयोग करता है, लेकिन मैं अन्यथा निश्चित नहीं हूं। हालांकि यह एक बड़ा यूआई अपडेट होगा।

लोग और क्या सुधार की उम्मीद कर सकते हैं?

बेहतर थीमिंग समर्थन।

कौन से लिनक्स डिस्ट्रो जीटीके(3) का उपयोग करते हैं?

सभी डिस्ट्रो के रिपॉजिटरी में GTK3 है।
कई प्रमुख डेस्कटॉप वातावरण GTK3 का उपयोग करते हैं, जैसे Gnome 3, Budgie, Deepin, MATE और जल्द ही (tm) XFCE भी।

इसके लिए एक पूर्वापेक्षा क्रोमियम 59 है जिसे #9946 के लिए पुल अनुरोध है।

@zeke Main takeaway बेहतर UI संगतता है क्योंकि Linux पर आप GTK(2 या 3) या Qt का UI टूलकिट के रूप में उपयोग करने वाले ऐप्स को देखने की संभावना से अधिक हैं। विंडोज़ और मैकोज़ का अपना स्वयं का होता है और आप आमतौर पर उन प्लेटफॉर्म पर अधिकतर ऐप्स पाएंगे जो उनका उपयोग करते हैं, स्टीम में वह मूल रूप नहीं है, उदाहरण के लिए क्योंकि यह मूल यूआई टूलकिट का उपयोग नहीं कर रहा है।

मैं इस धागे में "फ़ाइल संवाद" का बहुत उल्लेख करता हूं। GTK2 में इसमें क्या गलत था और GTK3 में इसे कैसे सुधारा गया?

GTK3 की तुलना में GTK2 को विंडोज या macOS के पुराने संस्करणों के रूप में सबसे अच्छी तरह से समझाया जा सकता है, जहां UI का एक अलग दृश्य रूप था (फ़ाइल ब्राउज़र जैसी चीजों का लेआउट/कार्यक्षमता अंतर)। यदि आप विंडोज 10 चलाते हैं और एक फाइल डायलॉग प्राप्त करते हैं जो विंडोज विस्टा या एक्सपी जैसा दिखता है, तो यह जगह से बाहर दिखाई देगा और संभवत: कुछ सुविधाओं / यूएक्स की कमी होगी।

केडीई जैसे डेस्कटॉप वातावरण (डीई) पर, यह अभी भी उस डीई, क्यूटी के लिए अधिक सामान्य टूलकिट के बजाय जीटीके 3 संवाद बनाता है। तो वहाँ अभी भी कुछ असंगतता है, लेकिन यह GTK2 से बेहतर है।

यहाँ केडीई पर डिफ़ॉल्ट ब्रीज़ थीम के साथ कुछ उदाहरण दिए गए हैं:

वर्तमान इलेक्ट्रॉन ऐप्स के साथ GTK2 डायलॉग - GitKraken:

GTK3 डायलॉग - मेल्ड:

क्यूटी संवाद - केट:

Mono/.NET(?) Dialog - BundleModder - Linux पर असामान्य, जावा एप्लिकेशन भी एक असामान्य टूलकिट का उपयोग कर सकते हैं:

जैसा कि आप देख सकते हैं कि अलग-अलग UI टूलकिट में शैली की स्थिरता काफी भिन्न है। यह एक आकस्मिक उपयोगकर्ता के रूप में भ्रमित हो सकता है कि वे अलग क्यों हैं, जिससे आपको आश्चर्य होता है कि क्या वे एक ही उद्देश्य के लिए हैं या नेविगेशन/प्रस्तुति विवरण अलग-अलग होने के कारण निराशा है (जीटीके आप डबल क्लिक कर सकते हैं, जबकि क्यूटी सिंगल के लिए सेटअप हो सकता है फ़ोल्डर नेविगेशन पर क्लिक करें) या केवल निरंतरता की कमी को गैर-पेशेवर के रूप में देखना।

Gnome (GTK केंद्रित DE) GTK3 और Qt के बीच निरंतरता के साथ KDE (Qt केंद्रित DE) की तुलना में इसे बेहतर तरीके से संभालने में सक्षम है, क्योंकि Qt के टूलकिट को एक देशी अनुभव/अनुभव देने के लिए प्लेटफार्मों में एकीकृत करने के लिए डिज़ाइन किया गया है। GTK देव Gnome के अलावा अन्य DE पर अपने टूलकिट का समर्थन करने के लिए अनिच्छुक हैं, इसके बावजूद KDE देव अपने DE पर समस्या का समाधान करने के लिए कोड का योगदान करना चाहते हैं। यदि उपयोगकर्ता पुराने एप्लिकेशन का उपयोग नहीं कर रहा है जो GTK2 या असामान्य टूलकिट का उपयोग करते हैं, तो उनके पास एक अच्छा अनुभव होगा।

अक्सर आपको जीटीके और क्यूटी ऐप्स का मिश्रण मिलेगा जब टूलकिट में अन्य टूलकिट समकक्ष ऐप के रूप में एक प्रस्ताव के रूप में मजबूत नहीं होता है, कुछ उपयोगकर्ताओं के लिए केवल एक टूलकिट ऐप का उपयोग करना व्यवहार्य होता है (केओएस एक डिस्ट्रो है जो क्यूटी 5 को पूरा करता है अनुभव, क्रोम जैसे वैकल्पिक जीटीके ऐप्स के साथ उपलब्ध)। इलेक्ट्रॉन अनुप्रयोगों की लोकप्रियता के साथ, जीटीके से बचना हमेशा वांछनीय नहीं होता है।

आप GTK3 समर्थन क्यों चाहते हैं?

संगति, फ़ाइल संवाद वह है जो केडीई उपयोगकर्ता के रूप में मेरे लिए सबसे अधिक चिपक जाता है।

क्या यह अपडेट प्रदर्शन, अनुकूलता आदि जैसी चीजों में सुधार करता है? या सिर्फ यूआई?
लोग और क्या सुधार की उम्मीद कर सकते हैं?

जबकि मुझे फ़्लैटपैक (सैंडबॉक्स्ड, डिस्ट्रो-एग्नॉस्टिक ऐप्स, जीयूआई ऐप्स के लिए डॉकर/कंटेनरों की तरह) के बारे में ज्यादा जानकारी नहीं है, मुझे लगता है कि जीटीके 3 की जीटीके 2 की तुलना में बेहतर कहानी है, जिसमें डीई के साथ एकीकरण शामिल है (फ्लैटपैक थीमिंग एक और है निरंतरता के लिए कहानी, FlatPak में GTK3 को हाल ही में थीम का समर्थन मिला है, अन्य टूलकिट को इसे भी जोड़ने की आवश्यकता है)। जैसा कि उल्लेख किया गया है, फ्लैटपैक अपने पोर्टल समर्थन के माध्यम से फ़ाइल संवाद समस्याओं को भी कम कर सकता है।

मैं व्यक्तिगत रूप से जीटीके 2 बनाम जीटीके 3 के बारे में बहुत ज्यादा नहीं जानता, लेकिन जीटीके 3 की कल्पना के लिए हायडीपीआई कहानी बेहतर होगी (जीटीके 2 को ऐसा भी नहीं मिल सकता है?) मुझे लगता है कि थीम समर्थन बेहतर है, या कम से कम आपको GTK3 के लिए 2 से अधिक थीम मिलने की संभावना है, खासकर भविष्य में। जीनोम पर फ़ाइल संवाद क्लाइंट साइड डेकोरेशन (सीएसडी) के साथ उन उपयोगकर्ताओं के लिए यूएक्स में सुधार के साथ थोड़ा अलग हो सकता है। केडीई पर मुझे लगता है कि जीटीके3 सपोर्ट ग्लोबल मेन्यू फीचर के साथ बेहतर काम कर सकता है (अभी भी डब्ल्यूआईपी, मैकओएस जैसे मेन्यू बार एप्लिकेशन विंडो से बंधे होने के बजाय)।

कौन से लिनक्स डिस्ट्रो जीटीके(3) का उपयोग करते हैं?

अधिकांश आधुनिक डिस्ट्रो GTK3 का उपयोग कर रहे हैं या जहाँ तक मुझे पता है इसका समर्थन कर रहे हैं। GTK2 काफी पुराना है। यदि आप क्रोम या इलेक्ट्रॉन ऐप का उपयोग कर रहे हैं तो आप जीटीके का उपयोग कर रहे हैं (शायद 2/3 का मिश्रण, लेकिन 3 की ओर अधिक झुकाव)।

@polarathene , आपने उल्लेख नहीं किया कि GTK3 समर्थन भविष्य में वेलैंड समर्थन जोड़ने की अनुमति देता है, जबकि GTK2 नहीं करता है।

JFYI क्रोमियम GTK2 बिल्ड नवीनतम स्थिर 60.0.3112.90 और बीटा 61.0.3163.31 में टूटा हुआ है।
हालांकि यह नवीनतम मास्टर में काम करता है।

और बीटीडब्ल्यू, इसे अब आधिकारिक तौर पर बनाए नहीं रखा गया है।
https://groups.google.com/a/chromium.org/d/msg/chromium-dev/iO3qzex6oYA/Q-i4Cie3BwAJ

GTK3 के गुणों पर हर किसी के लिए बहुत बढ़िया प्रतिक्रिया। आपके सहयोग के लिए धन्यवाद।

दुर्भाग्य से ऐसा लगता है कि GTK3 अपडेट इलेक्ट्रॉन 1.8 में क्रोम 59 के साथ नहीं उतरेगा। यह वर्तमान में बिल्ड को रोक रहा है, इसलिए हमें GTK3 समर्थित होने से पहले अगले क्रोमियम बंप 61 (हम 60 को छोड़ रहे हैं) तक इंतजार करना होगा। इलेक्ट्रॉन में।

क्या यह सही है, @alexeykuzmin?

@zeke क्या आपके पास कोई मोटा अनुमान है कि क्रोमियम 61 बंप कब होगा? हम उस रिलीज़ के साथ संरेखित करने के लिए मूल ES6 वेब घटकों के लिए अपने कदम की योजना बनाना चाहते हैं। ऐतिहासिक रूप से रिलीज के एक या दो महीने बाद धक्कों आते हैं?

@zeke
हां, क्रोमियम 59 शाखा में GTK3 के साथ हमें कुछ परेशानी हुई।
लेकिन हमें आगामी क्रोमियम 61 अपग्रेड में GTK2 से GTK3 में स्विच करना चाहिए।

@cpoole वर्तमान में हमारे पास अनुमान नहीं है कि क्रोमियम 61 इलेक्ट्रॉन में कब https://github.com/electron/libchromiumcontent/pull/335 में काम किया जा रहा है @tonyganch , @cifratila , @alexeykuzmin , @alespergl , अन्य?) तो मैं आशावादी हूँ :)

आप GTK3 समर्थन क्यों चाहते हैं?

@deikatsuo वह कौन सा ब्राउज़र है? ऐसा लगता है कि क्रोम और एपिफेनी का बच्चा था ...

@mdsitton एपिफेनी

इस पर कोई भी समाचार?

@ ziggy42 यह पहले से ही नवीनतम क्रोमियम 61 (https://github.com/electron/electron/pull/10213) में होना चाहिए। मुझे लगता है कि यह केवल मास्टर में विलय करने और किसी बिंदु पर रिलीज करने की बात है।

इंतजार नहीं कर सकता, उन बदसूरत फाइल पिकर्स ने मेरी आंखें जला दीं: आग:

क्या यह परिवर्तन CSS को इलेक्ट्रॉन ऐप्स में अनुमति देगा?

तो, क्रोमियम 61 का विलय हो गया है, क्या gtk3 इसके साथ आएगा?

इलेक्ट्रॉन अब मास्टर शाखा में GTK3 का उपयोग कर रहा है, अगली छोटी/बड़ी रिलीज में भेज दिया जाएगा।

@ahjolinna

धन्यवाद कि आपने इस चर्चा पर कुछ विवेक खर्च किया।

आपको वास्तव में KaOS में दिलचस्पी हो सकती है, जिसका पहले ही उल्लेख किया जा चुका है।
यह उसी व्यक्ति द्वारा बनाए रखा जाता है जिसने चक्र को कई वर्षों तक महान बनाया, IMHO।

@सब

जीटीके+3 कब जारी हुआ?

7 साल पहले।

इसे कुछ देर के लिए अपने मुंह में पिघलने दें।

और सॉफ्टवेयर परियोजनाओं का एक बड़ा समूह अभी भी 2 पर बैठा है।
चूंकि पोर्टिंग एक खुशी की बात है..

XFCE, Mate और कई अन्य लोगों को कोड पोर्ट करने में 6 साल लगे।
अन्य परियोजनाएं 2 के भीतर जीटीके से क्यूटी तक पूरी तरह से स्विच हो गईं।

और हाँ: GTK+ GNOME द्वारा विकसित किया गया है, यहाँ तक कि रेपो भी वहाँ बैठा है।
यह - प्रकृति और परिभाषा के अनुसार - गनोम के लिए विकसित किया गया है और कुछ नहीं।

Qt को कई प्लेटफार्मों में सच्चे और मूल एकीकरण के लिए विकसित किया गया है।

इलेक्ट्रॉन क्या है?

एक गनोम दुकान?

अच्छा है।

चतुर सोच।

यह अनिवार्य और कार्यात्मक प्रोग्रामिंग के साथ-साथ इस दृश्य में यहां कई अन्य पहलुओं के समान है: अनावश्यक, पुराने, पुराने सॉफ़्टवेयर को अक्सर नशे की लत वाली दवा के रूप में माना जाता है, जो इसे एक बनाता है।

और नए, चतुर, अभिनव सॉफ्टवेयर का इलाज गलत धारणा और शुद्ध अज्ञानता से होता है।

10, 12 परियोजनाएं जीटीके+ से क्यूटी पर स्विच की गईं, जबकि मुझे एक भी मामले की जानकारी नहीं है, जहां दूसरी तरफ हुआ।

इसे अपनी जीभ पर फिर से पिघलने दें: इसका मतलब है कि उनके संपूर्ण, एकीकृत UI कोड का पूर्ण पुनर्लेखन।
गहरा घोंसला, अक्सर।

जिसका अर्थ है कि वे अपने मौजूदा टूल के बड़े अपग्रेड की तुलना में इसे पसंद करते हैं।
और वे सभी आज तक उस फैसले से खुश हैं।

उनसे पूछों।

अपने विकल्पों पर विचार किए बिना झुंड का पालन करने से पहले।

@ahjolinna ने आपको इनमें से एक व्यक्ति का वीडियो पोस्ट किया है, VLC, Wireshark, LXQt और अन्य उल्लेखनीय सॉफ़्टवेयर प्रोजेक्ट भी पूर्व में GTK पर आधारित हैं।

जीटीके का उपयोग क्रोमियम में ऑरा के लिए बाध्यकारी के रूप में किया जाता है और यह केवल लिनक्स/फ्रीबीएसडी/सोलारिस पर होता है और इसी तरह:
विंडोज और मैकओएस बिल्ड इससे मुक्त हैं।

:आँख मारना:

हालाँकि मुझे आपके अंक मिलते हैं @ शालोक शालोम , कठोर होने की कोई आवश्यकता नहीं है, इलेक्ट्रॉन क्रोमियम टीम द्वारा दिए गए

कांटा बटन शीर्ष बीटीडब्ल्यू पर है, बेझिझक।

हाँ, यह अनावश्यक रूप से अपघर्षक था।

लेकिन मैं सहमत हूं। जीटीके में बहुत अधिक अनावश्यक टूट-फूट है जिससे दर्द होता है, क्यूटी एक बेहतर विकल्प होता

• IF QtWebEngine अंतर्निहित क्रोमियम इंस्टेंस तक पर्याप्त पहुंच प्रदान करता है
• यदि QtWebEngine नवीनतम क्रोमियम को शीघ्रता से ट्रैक करता है

मेरा सुझाव है कि हम चर्चा को अधिक उपयुक्त स्थान पर ले जाएं। @ शालोक शालोम , आप यहां एक नया मुद्दा कैसे खोलते हैं और समस्या का वर्णन अभी की तुलना में अधिक नागरिक तरीके से करते हैं?

वीएलसी , वायरशर्क, एलएक्सक्यूटी और अन्य उल्लेखनीय सॉफ्टवेयर परियोजनाएं भी पूर्व में जीटीके पर आधारित हैं।

यह सच नहीं है। VLC Qt से पहले wxWidgets का उपयोग कर रहा था, GTK का नहीं: https://wiki.videolan.org/WxWidgets_Interface/

मुझे लगता है कि जीटीके लोगों ने काफी समय से स्वीकार किया है कि उन्होंने 3.x श्रृंखला में पर्याप्त रूप से टूटने और संस्करण को अच्छी तरह से संवाद नहीं किया है और भविष्य में बेहतर और अधिक स्पष्ट दीर्घकालिक स्थिरता के साथ कड़ी मेहनत करेंगे जैसा कि https:/ पर पढ़ा जा सकता है।

मैं यह भी कहूंगा कि अलग-अलग इतिहास, समर्थन और लक्ष्यों के कारण क्यूटी और जीटीके की तुलना एक से एक से नहीं की जा सकती है और मेरी राय में आपके दृष्टिकोण के आधार पर दोनों के पक्ष और विपक्ष हैं।

यह कहना कि जीटीके केवल और केवल गनोम परियोजना के लिए बना है, मेरी राय में एक अनुचित कंबल बयान है।

हा! मैं वास्तव में उन योजनाओं के बारे में नहीं जानता था। ऐसा लगता है कि उन्होंने आखिर में सीख लिया है। आइए आशा करते हैं कि वे सीएसएस में किसी भी ब्रेकिंग बदलाव को वास्तविक ब्रेकिंग बदलाव पर विचार करना शुरू कर देंगे।

आखिरी बात जो मैंने सुनी वह थी ... उम ... एक्ससेंट्रिक जीटीके 4.0 जीटीके 4 नहीं है । तो अंत में सेवर के रूप में लगभग कुछ अच्छा हो रहा है! वे लगभग उतना ही अच्छा करते हैं जितना कि क्यूटी ने 20 साल पहले किया था! मैं

हमें इस ट्विटर पोस्ट के आधार पर जल्द ही इलेक्ट्रॉन को मूल GTK3 समर्थन के साथ डिफ़ॉल्ट रूप से देखना चाहिए:

इलेक्ट्रॉन 2.0.0-बीटा.1 अद्यतन क्रोमियम और Node.js, macOS इन-ऐप खरीदारी, Linux के लिए GTK3 समर्थन , और बहुत कुछ के साथ बाहर है।

हां। इसके लिए वास्तविक कार्य क्रोमियम लेखकों द्वारा किया गया था और इलेक्ट्रॉन 2.0.0 में क्रोमियम अपग्रेड के माध्यम से इसे प्राप्त किया।

इसके अलावा, इलेक्ट्रॉन का अपना कोड https://github.com/electron/electron/pull/11879 में GTK3ified हुआ।

हाँ, यह अनावश्यक रूप से अपघर्षक था।
लेकिन मैं सहमत हूं। जीटीके में बहुत अधिक अनावश्यक टूट-फूट है जिससे दर्द होता है, क्यूटी
एक बेहतर विकल्प होता
IF QtWebEngine अंतर्निहित क्रोमियम इंस्टेंस तक पर्याप्त पहुंच प्रदान करता है
यदि QtWebEngine नवीनतम क्रोमियम को शीघ्रता से ट्रैक करता है

खैर, यह मुख्य मुद्दा है। लोग मानते हैं कि उनके लिए लागू करने के लिए सबसे तेज़ क्या है, जो ठीक है, जबकि वे अक्सर यह भूल जाते हैं कि इसे चलाने के लिए वास्तविक कार्यान्वयन दीर्घकालिक रखरखाव से कुछ अलग है।

मेरे दृष्टिकोण से यह बिल्कुल स्पष्ट है, कि उल्लिखित मुद्दों से निपटा जा सकता है।

एक बार जब आप GTK3 पोर्ट पर वास्तव में काम करने वाले कोडर की मात्रा और एक नए टूलकिट पर अपना संपूर्ण UI कोड पोर्ट करने वालों की तुलना करते हैं, तो क्या आप देख सकते हैं कि अंतर कितना अद्भुत है। मुझे लगता है कि मैंने पहले ही इसके बारे में एक वीडियो पोस्ट कर दिया है, जिसका नाम है 'जीटीके से क्यूटी तक: एक अजीब यात्रा।'

क्यूटी में समर्थन में हैकिंग के बजाय, पुराने सॉफ़्टवेयर पर ध्यान केंद्रित क्यों करें, क्योंकि यह उपयोग करने के लिए तैयार लगता है?

यह है कि 'मैं तैयार रहने के लिए जो _लगता है_ का उपयोग करता हूं' हठधर्मिता, जो दीर्घकालिक निर्णयों को पूरी तरह से अनदेखा करता है। हां, ऐसा लग सकता है कि पहली बार में यह थोड़ा अधिक प्रयास करता है, जबकि एक बार लागू होने के बाद आप लोग निश्चित रूप से आधुनिक टूलकिट से लाभान्वित होंगे।

यह भी इतना कठोर नहीं है, कि QtWebEngine क्रोम का इतनी जल्दी पालन नहीं करता है:
यह काफी तेज है और Qupzilla साबित करता है कि आप इसके साथ अद्भुत चीजें कर सकते हैं - विशेष रूप से उपयुक्त वातावरण में, जैसे कि KaOS।

क्या आपको सच में लगता है कि आपको 'अंतर्निहित क्रोमियम तक अधिक पहुंच' की आवश्यकता है और 'QtWebEngine क्रोमियम का शीघ्रता से पालन नहीं करता है' क्योंकि Qupzilla और अन्य सॉफ़्टवेयर एक एकल कोडर द्वारा बनाए गए अद्भुत सॉफ़्टवेयर को शिप करने के लिए सिद्ध होते हैं?

आपको लगता है कि आपको इलेक्ट्रॉन में एक पूर्ण वेब ब्राउज़र के रूप में अधिक पहुंच और त्वरित अनुसरण की आवश्यकता है? ऐसा कैसे?

अब, आप इतने सारे प्रोजेक्ट्स में इस अनाड़ी सॉफ़्टवेयर स्टैक पर बैठते हैं और छोटी टीमें अपने डीप नेस्टेड कोड के 40-60% को त्वरित और कुशल क्यूटी में पोर्ट करने का प्रबंधन करती हैं;

कुछ ऐसा जो वे जीटीके 2 से जीटीके 3 तक नहीं कर पाए, जो काफी आश्चर्यजनक है। जैसा कि कहा गया है: अधिकांश परियोजनाओं को एक प्रमुख संस्करण को

और ऐसा लगता है कि लगभग हर कोई इसे अनदेखा कर रहा है? यह इतना दुखद है, कि प्रारंभिक वैज्ञानिक समुदाय में, आदिम निर्णय फैलते रहते हैं।

शांति :)

@ शालोक शालोम , "पुराने सॉफ़्टवेयर" से आपका क्या मतलब है? जीटीके+? आपके ऐसा कहने का कोई कारण?

कृपया इस क्यूटी स्पैम के साथ रुकें, यह जीटीके 3 पोर्ट के बारे में एक मुद्दा है। यदि आप अनुरक्षकों को Qt पर स्विच करने के लिए मनाने की आवश्यकता महसूस करते हैं, तो एक अलग मुद्दा खोलें। मैं कार्यान्वयन प्रगति के बारे में समाचार प्राप्त करना चाहता हूं, क्यूटी फैनबॉय से संदेश नहीं।

विषय से अधिक चर्चा के कारण इस वार्तालाप को लॉक किया जा रहा है।

लॉकिंग केवल एक लक्षण को संबोधित करता है, लेकिन एक उचित त्वरित समाधान है क्योंकि GTK3 की ओर बढ़ना समाप्त हो रहा है और इस मुद्दे पर GTK2 से GTK3 में जाने के विषय पर चर्चा करने के लिए बहुत कुछ नहीं बचा है।