کامبیز اسدزاده

در اسناد QML هر فایلی می‌تونه به عضو‌ها و خواص فایل‌های والد خودش دسترسی پیدا کنه. اما روش پیشنهادی این هست با تعریف یک QtObject اعضای مورد نظر خودتون رو تعریف کنید تا هر جا داخل هر فایلی که هستین بتونید به اون دسترسی داشته باشید. به عنوان مثال فایل main.qml import QtQuick 2.11 import QtQuick.Window 2.11 Window { visible: true width: 640 height: 480 title: qsTr("Hello World") QtObject { id:mainObject property string name : "Kambiz" } Page1 { anchors.fill: parent; } } و فایل دیگه که با نامPage1.qml هست تنها کافیه درونش شناسه‌ی QtObject رو صدا بزنید. به صورت زیر: import QtQuick 2.0 Item { Text { anchors.centerIn: parent text: mainObject.name } } اینجا من مقدار name که به عنوان عضوی از فایل main.qml هست رو صدا زدم و برابر با مقدار نوع Text قرار دادم.

مراحل ساخت برنامه‌ در زبان سی‌پلاس‌پلاس پیش نویس ۰.۶ قبل از هر چیز به اینفوگرافی زیر توجه کنید که مراحل ساخت برنامه در سی‌پلاس‌پلاس را نشان می‌دهد. مقدمه‌ای بر همگردانی (کامپایل) و اتصال (لینک کردن) این سند مرور مختصری در رابطه با مراحل را برای شما فراهم می‌کند تا به شما در درک دستورات مختلف برای تبدیل و اجرای برنامه‌ی خودتان کمک کند. تبدیل مجموعه‌ای از فایل‌های منبع و هدر در سی‌پلاس‌پلاس به یک فایل خروجی و اجرایی در چندین گام (به طور معمول در چهار گام) پیش‌پردازنده (Preprocessors)، کامپایل و گرد‌آوری (Compilation)، اسمبلر (Assmbler) و پیوند دهنده (Linker) تقسیم می‌شود. قبل از هر چیز اگر در محیط توسعه‌ی Qt Creator داخل فایل .pro مقدار زیر را وارد کنید، تا بتوانید فایل‌های ساخته شده‌ی موقت در زمان کامپایل را مشاهده کنید. QMAKE_CXXFLAGS += -save-temps تعریف پیش‌پردازنده پیش‌پردازنده‌ها (Preprocessors) درواقع دستوراتی هستند که اجازه می‌دهند تا کامپایلر قبل از آغاز کردن مراحل کامپایل دستوراتی را دریافت کند. پیش‌پردازنده‌ها توسط هشتگ (#) مشخص می‌شوند این نماد در سی‌++ مشخص میکند که دستور فوق از نوع پیش‌پردازنده می‌باشد که نتیجه‌ی آن در قالب ماکرو (Macro) در دسترس خواهد بود. برای مثال ماکروی __DATE__ توسط پیش‌پردازنده‌ها از قبل تعریف شده است که مقدار تاریخ و زمان را بازگشت می‌دهد. بنابراین هرکجا که از آن استفاده شود کامپایلر آن را جایگزین متن خواهد کرد. در شکل زیر مرحله‌ای که از پیش‌پردازنده‌ها استفاده می‌شود آمده است: پیش‌پردازنده، کامپایل (گردآوری کردن)، لینک (پیوند کردن) و ساخت برنامه اجرایی فرایند تبدیل مجموعه‌ای از فایل‌های متنی هِدر و سورس سی‌++ را «ساخت» یا همان Building می‌گویند. از آنجایی که ممکن است کُد پروژه در بسیاری از فایل‌ها هدر و سورس سی++ توسعه و گسترش یابدمراحل ساخت در چند گام کوچک صورت می‌گیرد. یکی از رایج‌ترین موارد در مراحل گردآوری (ترجمه‌ی یک کد سی‌پلاس‌پلاس به دستورالعمل‌های قابل فهم ماشین) است. اما گام‌های دیگری نیز وجود دارد، پیش‌پردازنده و لینک (پیوند‌ها) این بخش به طور خلاصه توضیح می‌دهد که چه اتفاقی در هر یک از مراحل رُخ می‌دهد. یک کامپایلر یک برنامه‌ی خاص است که پردازش اظهارات (دستورات) نوشته شده در یک زبان برنامه‌نویسی خاص را به یک زبان ماشین که قابل فهم برای پردازنده می‌باشد تبدیل کند. به طور معمول یک برنامه‌نویس با استفاده از یک ویرایشگر که به محیط توسعه‌ی یکپارچه‌ی نرم‌افزار (IDE) مشهور است توسط زبان برنامه‌نویسی مانند ++C دستورات (اظهارات) را می‌نویسد. فایل ایجاد شده با نام (filename.cpp در زبان برنامه‌نویسی سی‌پلاس‌پلاس) شامل محتوایی است که معمولاً به عنوان دستورات برنامه‌نویسی سطح بالا نامیده می‌شود. سپس برنامه‌نویس کامپایلرِ مناسب برای زبان برنامه‌نویسی مانند سی++ را اجرا می‌کند و نام فایل‌هایی که حاوی دستورات هستند را برای کامپایل مشخص می‌کند که این انتخاب و مشخص سازی توسط IDE به راحتی قابل مدیریت است. پس از آن، کار کامپایلر این است که فایل‌های منبع .cpp را جمع آوری کرده و پیش‌پردازنده‌ها را بررسی کند تا دستورات احتمالی را اجرا نماید که نتیجه‌ی این مرحله در فایلی با پسوند .ii ر قالب filename.ii تولید می‌شود که در این فرایند نیز خط به خط کُد‌های موجود در آن‌ها را بررسی می‌کند تا خطاهای احتمالی نحو (سینتکس - Syntax) بررسی می‌شود و آن‌ها را به طور ترتیبی به دستورالعمل‌های سطح ماشین تبدیل کند. توجه داشته باشید که هر نوع پردازنده‌ی کامپیوتر دارای مجموعه‌ای از دستورالعمل‌هایِ ماشین خودش است. بنابراین کامپایلر تنها برای سی++ نیست، بلکه برای اهداف و مقاصدخاص هر پلتفرم است. پس کد‌هایی که توسط پیش‌پردازنده سی‌پلاس‌پلاس به زبان اسمبلی برای معماری مورد نظر در پلتفرم مقصدترجمه شده‌اند نتایج آن در فایلی با پسوند .ss در قالب filename.ss قابل نمایش هستند که در حالت عادی قابل رویت نیست. توجه داشته باشید که باید در این مرحله باید مشخص شود برنامه قرار است توسط چه نوع پردازنده‌ای تحتِ چه نوع معماری مونتاژ (اسمبل) شود. برای مثال پردازنده‌ها با انواع معماری‌های مختلف وجود دارند که برخی از آن‌ها به صورت x86-x64، x64، ARMv7، aarch64 غیره ... می‌باشند. شکل یک (کامپایل یک فایل منبع ++C) مرحله‌ی سوم را در نظر داشته باشید که عمل کامپایل فایل سی‌پلاس‌پلاس در دو مرحله قبلی یک فایل اجرایی را تولید نمی‌کند. برنامه‌ای که توصیف شده است، احتمالاً توابعی را در رابط‌های برنامه‌نویسی (API) و یا توابع ریاضی یا توابع مرتبط با I/O را فراخوانی کند که ممکن است شامل فایل‌های هدر مانند iostream یا fstream و حتی ماژول‌های دیگری که در زبان‌ تعبیه شده‌اند را داشته باشد که فایل تولید شده توسط کامپایلر در این مرحله یک فایل شیء نامیده می‌شود که با پسوند .o به صورت filename.o تولید خواهد شد که علاوه بر دستورالعمل‌های تبدیل شده به کد ماشین، شامل توابع و دستورالعمل‌های خارجی نیز می‌باشد. هرچند در این مرحله دستورات تبدیل به دستورالعمل‌های قابل فهم توسط پردازنده شده‌اند اما فعلاً قابل اجرا نیستند چرا که باید این توابع خارجی افزوده شده را به آن لینک کرد که در مرحله‌ی بعد یعنی مرحله‌ی چهارم اتفاق می‌افتد. در نهایت مرحله‌ی چهارم فایل با پسوند .o که شامل کد‌های تولید شده توسط کامپایلر به زبان ماشین است که پردازنده‌ها می‌توانند این دستورات را درک کنند که همراه با کد‌های تولید شده‌ی هر کتابخانه‌ی دیگری که مورد نیاز است توسط لینکر (لینک شده) و در نهایت جهت تولید یک فایل اجرایی مورد استفاده قرار می‌گیرند که نوع آن فایل از نوع اجرایی یا در واقع Executable File خواهد بود. شرح کامل فرایند ساخت فایل اجرایی اکثر پروژه‌ها دارای مجموعه‌ای از فایل‌های هدر سی++ هستند، که امکان ماژولار شدن در آن را فراهم می‌کند و مجموعه‌ای از آن می‌تواند به عنوان بخش‌های کوچکی از برنامه محسوب شوند. برای ساخت چنین پروژه‌هایی هر فایل سی‌پلاس‌پلاس باید کامپایل شود و سپس فایل‌های ساخته شده در قالب شیء (آبجکت) باید همراه توابع و کتابخانه‌های دیگر لینک (پیوند) شوند. البته هر گام از مراحل کامپایل شامل یک مرحله پیش‌پردازنده است که دستورالعمل # عمل تغییرات و اصلاحیه‌ها را در فایل متن اعمال می‌کند. شکل زیر فرایند ساخت چند فایل به صورت همزمان را نشان می‌دهد:

خدارو شکر. خب وقتی سیستم عاملت رو تازه نصب کردی حتماً یک سری ابزار‌ها و کتابخانه‌ها روش وجود نداره. مثل کتابخانه‌های گرافیکی مورد نیاز، کامپایلر‌ و برخی از ابزار‌های دیگه که روی لینوکس باید این دو دستور رو اجرا کنی و نصبشون کنی. خطای lGL- هم مربوط به کتابخانه OpenGL هست.

زمان، اوایل دهه ۹۰ است و چند سال از شروع به کار دیجیکالا و سپس چند فروشگاه اینترنتی دیگر که حالا نامی از آن‌ها شنیده نمی‌شود سپری شده اما هنوز هم مردم به خرید آنلاین اعتماد چندانی ندارند. اندکی بعد نماد اعتماد الکترونیکی متولد می‌شود؛ نمادی که در ابتدای راه به کمک کسب‌وکارهای اینترنتی برای جلب اعتماد عمومی آمد اما در ادامه مسیر، به‌روز شدن را فراموش کرد و به لطف یک مصوبه از سوی بانک مرکزی، تبدیل شد به یکی از بزرگ‌ترین کابوس‌های هر استارت‌آپ و فروشگاه ایرانی. مصوبه بانک مرکزی به شکل خلاصه می‌گفت که سایت و فروشگاه‌های اینترنتی برای دریافت درگاه پرداخت بانکی باید احراز هویت شوند. این‌چنین بود که کسب‌وکارهای آنلاین برای دریافت درگاه پرداخت، ملزم به دریافت پیش‌نیازی به نام نماد اعتماد الکترونیکی شدند؛ نمادی که از سوی مرکز توسعه تجارت الکترونیکی، وابسته به وزارت صنعت، معدن و تجارت ایران ارائه می‌شود و به همین شکل، برخلاف نمونه‌های جهانی از یک امتیاز اختیاری برای جلب اعتماد مخاطب در کسب‌وکار نوپا، به یک الگوی اجباری بدل شد. نماد اعتماد الکترونیکی که به ای‌نماد نیز مشهور است امروز آن‌قدر برای استارت‌آپ‌ها و فروشگاه‌های اینترنتی چالش‌زا شده که برخی از آن‌ها حتی با قبول ریسک فیلترینگ، آن را تمدید نکرده یا از سایت‌شان حذف می‌کنند. از سوی دیگر برای دریافت درگاه پرداخت، به راه‌های دیگری به‌جز ای‌نماد روی می‌آورند؛ حرکتی که در روزهای گذشته، از سوی پلتفرم تامین مالی جمعی «دونیت» آغاز شده است. «محی‌الدین سنیسل»، مدیرعامل دونیت در علت حذف ای‌نماد، به مشکلات پایه‌ای اشاره کرد و فلسفه وجودی این نماد را زیر سوال برد: «نمادهای اعتماد در دنیا وجود دارند اما هیچ‌جا الزامی نیستند. نماد اعتماد باید یک مزیت برای جذب کاربر باشد. اگر ببینیم نماد اعتماد اختیاری است و رقیب آن را دریافت کرده، کسب‌وکارها آن را برای جذب اعتماد کاربر دریافت می‌کنند. فلسفه اجباری بودن آن از پایه اشتباه است.» تولیدکننده بی‌اعتمادی یکی از مشکلات اصلی نماد اعتماد الکترونیکی که از همان ابتدای کار نیز مطرح شده بود و هنوز هم پاسخ دقیقی برای آن وجود ندارد، وجود پنج ستاره در آن است. این در حالی است که شما به‌عنوان یک کسب‌وکار، در حال حاضر تنها می‌توانید دو ستاره دریافت کنید. حتی دیجیکالا، فروشگاهی که امروز به ۱۱ سالگی‌اش قدم گذاشته نیز در نماد اعتماد خود تنها دو ستاره دارد. اما آیا برنامه‌ای برای پر شدن ستاره‌های دیگر وجود دارد و آیا همین مساله به‌جای ایجاد اعتماد، ایجاد بی‌اعتمادی نمی‌کند؟ مدیرعامل دونیت در همین رابطه می‌گوید: «چند سال پیش که نماد اعتماد شروع به کار کرد ما گفتیم که حتماً برنامه‌ای دارند تا در آینده آن سه ستاره‌ی باقی مانده را هم پر کنند. برای همان تک‌ستاره اطلاعات بسیاری از ما دریافت شد و زمانی که SSL دریافت کردیم، شدیم دو ستاره. واقعاً سه ستاره باقی‌مانده را می‌خواهند به چه کسب‌وکاری بدهند؟ کاربر وقتی می‌بیند از پنج ستاره یک یا دو ستاره پر است، به‌جای احساس اعتماد پیش خود می‌گوید احتمالاً مشکلی وجود دارد چون زمانی که پنج ستاره وجود دارد قاعدتاً هرچه تعداد ستاره‌های پر شده بیشتر باشد، باید اعتماد هم به آن بیشتر شود.» او به فرایند تمدید ای‌نماد نیز اشاره می‌کند و می‌گوید حتی برای تمدید یک دامین ارزان‌قیمت، ایمیل و پیامک به صاحب دامین ارسال می‌شود اما ای‌نماد که نقش یک مجوز یک‌ساله را به عهده گرفته به‌هیچ‌عنوان به فرد ثبت‌کننده یادآوری نمی‌کند که باید نماد خود را تمدید کند: «برای تمدید نماد اعتمادی که درگاه بانک ما به آن وابسته است، و به قول خودشان اعتماد کاربران به آن متکی است، حتی یک ایمیل هم نمی‌زنند. کاربری به من گفت نماد شما منقضی شده؛ می‌خواهید جمع کنید بروید؟» یک «مجازی» به مجوز اضافه کن حوزه کسب‌وکارهای آنلاین متفاوت از کسب‌وکارهای سنتی است اما در کشور ما بسیاری از مجوزها صرفاً با اضافه شدن کلمه آنلاین یا مجازی به آن‌ها، برای استارت‌آپ‌ها بازتولید می‌شوند. به دلیل نو بودن برخی از کسب‌وکارها و وجود نداشتن نمونه‌های فیزیکی، این روند باعث می‌شود بخشی از کسب‌وکارهای آنلاین همواره با مشکل مجوز درگیر باشند. حال یکی از پیش‌نیازهای دریافت نماد اعتماد، داشتن مجوز مرتبط به فعالیت است؛ مجوزی که در بعضی مواقع هنوز وجود خارجی ندارد. یکی از بخش‌هایی که هنوز هم مجوز مشخصی برای آن وجود ندارد، بحث «کرادفاندینگ» یا تامین مالی جمعی است. سنیسل می‌گوید در بحث قانون‌گذاری مرتبط با کرادفاندینگ، دخیل بوده و با همراهی وزیر ارتباطات دستورالعمل و صورت‌جلسه تهیه شده است اما درنهایت به او گفته شده است که برای نماد اعتماد باید از فرابورس مجوز دریافت کند: «در فرابورس چنین مجوزی وجود ندارد. به‌عنوان یکی از افرادی که در روند صدور مجوز کرادفاندینگ حضور دارم، به شکل موثق اطلاع دارم که برای این موضوع هنوز مجوز مشخصی در کشور نداریم. ای‌نماد می‌گوید از فرابورس مجوز بگیرید و زمانی که می‌گوییم فرابورس چنین مجوزی ارائه نمی‌دهد می‌گویند ما نمی‌دانیم.» تمام این مسائل سبب شده تا کسب‌وکارهای آنلاین یا استارت‌آپ‌ها برای دریافت ای‌نماد و درنهایت درگاه بانکی با چالش روبه‌رو شوند؛ چالشی که درنهایت باعث «پیچاندن مصلحتی» ای‌نماد برای دریافت درگاه بانکی شده است. سنیسل در خصوص همین پیچش می‌گوید: «من با مدیران استارت‌آپ‌های زیادی آشنایی دارم و حقیقت، بدون تعارف این است که همه در حال پیچاندن نماد اعتماد هستیم. در واقع هیچ‌کدام به شکل اصولی نتوانسته ای‌نماد دریافت کند. حتی خودمان هم دو سال پیش که در دونیت نماد اعتماد گرفتیم، مجبور شدیم قرارداد صوری با جایی ببندیم و مدرک را ارائه کنیم. گویا اصلاً مهم نیست چه چیزی به مسئولین ای‌نماد تحویل می‌دهید؛ صرفا باید یک برگه کاغذ بدهید تا آن‌ها بگویند انگار کار شما درست است. خیلی از خدماتی که امروز در وب ارائه می‌شود در لیست آن‌ها وجود ندارد. دونیت در دو سال گذشته که نماد اعتماد دریافت کرده، مجوز خود را خدمات نگه‌داری از سالمندان در منزل تعیین کرده است چون ای‌نماد اصلاً کسب‌وکارهای نوین را نمی‌شناسد.» اگرچه ای‌نماد پیش‌نیاز دریافت درگاه بانکی است اما این روندهای غیرشفاف سبب شده تا راه‌هایی برای دور زدن آن نیز وجود داشته باشد. نکته اینجاست که در کنار استارت‌آپ‌هایی که مجبور می‌شوند به هر شکل درگاه را برای ارائه خدمات خود به دست بیاورند، افراد دیگر نیز از همین روش‌ها استفاده کرده و درگاه بانکی را در سایت‌های مختلفی ازجمله سایت‌های شرط‌بندی اضافه می‌کنند. تغییری که هزینه دارد قوانین مربوط به نماد اعتماد الکترونیکی مربوط به گذشته هستند و در طول سال‌های فعالیتش به‌روز نشده‌اند. این در حالی است که فضای آنلاین به‌سرعت در کشور در حال گسترش و تغییر است. حال برای ایجاد تغییر در شرایط نماد اعتمادی که به کسب‌وکارهای آنلاین تحمیل می‌شود، احتمالاً باید هزینه‌ داد؛ هزینه‌ای که نه‌تنها در حد حذف یک درگاه بانکی، بلکه می‌تواند به بزرگی فیلتر شدن یک کسب‌وکار آنلاین هم باشد. مدیرعامل دونیت می‌گوید می‌شود در صورت حذف درگاه، از راه‌های جایگزین فعلی برای اضافه کردن یک درگاه جدید استفاده کرد اما باید ریسک احتمالی فیلترینگ را نیز پذیرفت؛ ریسکی که البته دودش به چشم مسدودکنندگان می‌رود تا مسدودشدگان. بااین‌حال به عقیده او، باید این هزینه را پرداخت کرد: «به دلیل عدم وجود حساب‌وکتاب مشخص، این احتمال وجود دارد که فیلتر شویم. البته تصور نمی‌کنم صرف برداشتن نماد اعتماد از سایت باعث فیلتر شدن آن شود چون حتی شما اگر چندین سایت بزرگ مربوط به استارت‌آپ‌ها را بررسی کنید می‌بینید که نماد اعتمادی در آن‌ها وجود ندارد و مشغول فعالیت به شکل گسترده هستند. بااین‌حال اگر با فیلتر شدن دونیت، این اتفاق می‌افتد، اجازه دهیم فیلتر شود. اگر فیلتر شویم هم اقدامی برای رفع فیلتر نمی‌کنیم چون دونیت یک پلتفرم خیریه اجتماعی است که تاکنون باعث ساخته شدن ۲۰ مدرسه و ۵۰ کارگاه اشتغال در کشور شده. بیشتر از اینکه ما ضرر کنیم، آن‌ها از فیلتر شدن ما ضرر می‌کنند.» تو حق متولد شدن نداری نماد اعتماد الکترونیکی اکنون روی یک صندلی قدرت نشسته است که اجازه می‌دهد یا نمی‌دهد که یک کسب‌وکار به وجود بیاید یا نیاید. «جعفر محمدی»، نایب رییس کمیسیون تجارت الکترونیکی سازمان نظام صنفی رایانه‌ای عقیده‌ی صریح‌تری دارد و نماد اعتماد الکترونیکی را نمادی از مورد تجاوز قرار گرفتن حقوق شهروندی کسب‌وکارها می‌داند: «اینکه بانک مرکزی بگوید من فقط به کسانی درگاه پرداخت می‌دهم که ای‌نماد داشته باشند، مشکل‌ساز می‌شود. به این دلیل که متولیان ای‌نماد این حق را به خودشان می‌دهند که به بخشی از کسب‌وکارها اجازه به وجود آمدن و فعالیت بدهند یا ندهند. آیا ای‌نماد در جایگاهی است که تشخیص بدهد چه کسب‌وکاری باید اجازه وجود داشته باشد یا خیر؟ آیا این عدالت و شرایط را دارد؟» محمدی اشاره می‌کند که اگر متولیان ای‌نماد نتوانند تشخیص درستی در این رابطه بدهند، کسی خسارت این موضوع را متحمل نخواهد شد و این نماد، در جایگاه قاضی و حَکَم قرار گرفته است: «ای‌نماد اجازه نداشته است که این حق مسلم را که بر اساس قانون تجارت در اختیار کسب‌وکارهاست، از آن‌ها سلب کند. درنتیجه مشغول پایمال کردن حق قانونی افراد و تجاوز به حقوق آنهاست. زمانی هم که متوجه اشتباهش شود، هیچ اراده‌ای برای جبران خسارتی که در این چند سال به بار آمده وجود ندارد.» تدوین دورهمی قوانین محمدی در پاسخ به این پرسش که آیا نماد الکترونیک اعتماد قابل اصلاح است یا استارت‌آپ‌ها باید فکر دیگری بکنند، عنوان کرد که راهی جز برچیده شدن ای‌نماد وجود ندارد و به‌جای آن باید ساز‌وکار مناسب‌تری برای این روند در نظر گرفته شود. اما سوال این است که بر اساس شرایط قانونی کشور، آیا امکان برچیده شدن ای‌نماد وجود دارد؟ این کارشناس تجارت الکترونیک عقیده دارد که این شرایط به شکل کامل فراهم است، چراکه نماد اعتماد الکترونیکی، روی ستون‌های قانونی استوار نیست و وجودش به شکل فعلی، مساوی با بی‌قانونی است: «این یک نوع تخلف است و روش منطقی، برداشته شدن چنین اجباری است. ای‌نماد برای اینکه خودش را در جایگاه فعلی تثبیت کند، به چند مورد اشاره می‌کند که یکی از آن‌ها شورای امنیت کشور است. درواقع متولیان نماد الکترونیکی اعتماد بر اساس دستوری که از سوی همین شورا به آن‌ها داده‌ شده، اجبار در دریافت این نماد را برای گرفتن درگاه بانکی لحاظ می‌کنند. این در حالی است که شورای امنیت کشور در جایگاهی نیست که چنین دستوری بدهد. این شورا، صرفاً یک جایگاه مشورتی برای وزیر کشور دارد. درنهایت وزیر کشور می‌تواند نظرات آن‌ها را بپذیرد یا نپذیرد که البته این هم صرفاً در موارد امنیتی است.» همه این‌ها در حالی است که تجارت الکترونیکی، موضوعی امنیتی به‌حساب نمی‌آید و در باب ششم قانون تجارت الکترونیک مصوبه مجلس، آمده است که چنین مواردی باید تصویب هیات وزیران را داشته باشد. محمدی می‌گوید که هیات وزیران، چنین تصویبی نداشته است: «کاشف به‌عمل‌آمده که نه خود شورای امنیت کشور، بلکه یکی از کمیسیون‌های آن‌ها در یک جلسه دورهمی، چنین مواردی را نوشته‌اند. درنتیجه این روند از بیخ‌ و بن اشتباه است.» برخی از اعضای بدنه دولت هم به احتمال اشتباه بودن این روند اذعان دارند. «حسین میرشجاعیان»، معاون وزیر اقتصاد در اردیبهشت‌ماه امسال خبر از شناسایی ۲۱۰۰ مجوز توسط «هیات مقررات زدایی» برای کسب‌وکارها داد و عنوان کرد حدود ۵۰۰ مجوز حذف یا ادغام شده و در حال حاضر هنوز ۱۵۷۰ مجوز فعال هستند: «بعد از مطرح شدن بحث نماد اعتماد الکترونیکی در وزارت صنعت، معدن و تجارت سایر دستگاه‌ها نیز مشتاق شدند که چنین نمادی را طراحی کنند و بحث تی نماد در سازمان میراث فرهنگی و اچ نماد در وزارت بهداشت مطرح شد که با توجه به اینکه پشتوانه قانونی نداشت با آن‌ها مخالفت شد. ای نماد نیز پشتوانه قانونی ندارد و باید اصلاح شود. اگر به این نتیجه برسیم که برای کسب‌وکارها مضر است، می‌توان حذف آن را در دستور کار قرار داد.» واقعیت این است که نماد اعتماد الکترونیکی در ذات خود و در صورت اجرای صحیح که اختیاری است، می‌تواند تبدیل به یک ابزار مناسب برای جلب اعتماد مخاطبین در کسب‌وکارهای نوپا شود؛ اما روند فعلی که اجبار را دیکته می‌کند، باعث شده تا استارت‌آپ‌ها و کسب‌وکارها ملزوم به دور زدن قوانین و بستن قراردادهای صوری صرفاً برای داشتن یک درگاه بانکی باشند. نمادی که دریافت آن برای داشتن درگاه بانکی الزامی است، هنوز سیستم مشخصی برای اعطای ۵ ستاره‌اش ندارد و همان‌گونه که ذکر شد حتی سایتی مانند دیجیکالا که برنامه دارد امسال خارج از ایران و در منطقه نیز فعالیت کند، تنها دو ستاره کسب کرده است. ستاره اول، صرفاً گویای این است که یک احراز هویت صورت گرفته و دو ستاره، به مفهوم این است که صاحب سایت با صرف هزینه‌ای اندک و خرید SSL، از پروتکل HTTPS استفاده می‌کند. عضو کمیسیون تجارت الکترونیک سازمان نظام صنفی رایانه‌ای در همین رابطه می‌گوید: «اینکه کسی SSL تهیه می‌کند، چه معنی دارد که بگوییم اعتماد به این شکل بیشتر می‌شود؟ آیا یک متخلف نمی‌تواند SSL بخرد؟ تنها پیش‌نیاز، هزینه‌ی ۳۰۰ الی ۷۰۰ هزارتومانی است.» تحریم قانونی امروز استارت‌آپ‌ها برای دریافت نماد اعتماد الکترونیکی مسیرهای پرپیچ‌وخمی را طی می‌کنند و زمانی که در شبکه‌های اجتماعی در همین رابطه جستجو کنید می‌بینید که تعدادی از آن‌ها در همین مسیر، بی‌خیال ادامه دادن می‌شوند و با روش‌های جایگزین، در پی دریافت درگاه بانکی برای ارائه خدمات خود هستند. در زمانه‌ای که شرایط اقتصادی کشور آرام نیست، استارت‌آپ‌ها بارقه‌های امیدی هستند از رونق اقتصادی در اوج ناآرامی. حاکمیت و دستگاه‌های مختلف کم‌کم در حال درک اهمیت استارت‌آپ‌ها برای اقتصاد و حل مشکل اشتغال هستند اما عجیب است که هنوز هم قدم موثری برای برداشتن این موانع که حتی در وهله اول علت وجود آن‌ها شفاف نبوده، برداشته نمی‌شود. جعفر محمدی، تحریم ای‌نماد را حق قانونی استارت‌آپ‌ها بیان‌ می‌کند و می‌گوید: «اصولاً اگر کسی پیگیر شود و شکایت کند، طبق قانون این حق کسب‌وکار است و اگر اجازه فعالیت به همین دلیل از آن‌ها سلب شده است، متولیان ای‌نماد باید خسارت این موضوع را پرداخت کنند. ای‌نماد از لحاظ قانونی جایگاهی ندارد و ممکن است با لابی‌گری، بانک مرکزی یا شاپرک را متقاعد کنند که درگاهی را از سایتی حذف کند. بااین‌حال کسب‌وکار حق شکایت دارد و اگر تعداد استارت‌آپ‌هایی که چنین کاری کنند افزایش پیدا کند، متولیان نماد اعتماد الکترونیکی مجبور به عقب‌نشینی خواهند بود؛ همان کاری که فین‌تک‌ها هم انجام دادند.»

با سلام، ما برای بهبود و سرعت بخشی برای توسعه محصولاتمون رو پلتفرم‌های مختلف برای جولوگیری از بازنویسی کُد‌های مشابه و یک سری ابزار‌هایی که برای تولید قابلیت‌های ویژه در پروژه‌ها و اپلیکیشن‌های موبایل و دسکتاپ نیاز داشتیم رو به صورت انحصاری در قالب یک موتور اختصاصی برای شرکت خودمون تولید کردیم که در توسعه هر چه سریعتر استارت‌آپ‌ها بسیار مفید واقع می‌شود. قابلیت‌ها و ویژگی‌ها با استفاده از پروژه‌ی جِنسیس ما می‌توانیم بَک‌اند و ترکیبی از عملیات فرانت‌اِند پروژه‌های خود را در کمترین زمان ممکن تولید و توسعه دهیم که در نتیجه گیری سریع یک استارت‌آپ بسیار مفید است. این کار باعث می‌شود ما هر بار در پروژه‌های خودمان نیاز به باز نویسی کلاس‌ها و توابع و تولید ابزار‌هایی نباشیم که در یک محصول مورد نیاز است. عنوان: پروژه‌ی جِنسیس (Genesis) توضیحات: این پروژه یک موتور برنامه‌نویسی چند‌سکویی در قالب یک چهارچوب تخصصی می‌باشد که در توسعه هرچه سریع‌تر محصولات و طراحی و همچنین مستقر سازی آن‌ها بر روی پلتفرم‌های مختلف کمک بسیاری می‌کند. زبان‌ها و فناوری‌های استفاده شده: زبان برنامه‌نویسی ++C فریم وُرک‌ و کتابخانه‌ها: کتابخانه‌ی OpenSSL‌، LibCurl، STL ابزار‌های ساخت: qmake، qbs و cmake نوع پروژه: تجاری (انحصاری شرکتِ Dotwaves LLC) نویسندگان: کامبیز اسدزاده وضعیت: در حال توسعه حق چاپ و تکثیر: شرکت دات‌ویوز برخی از محصولاتی که تحت این موتور طراحی شده اند: سیستم مدیریت محتوای جگوار

با سلام، همانطور که می‌دانید سیستم‌‌های مدیریت محتوا به عنوان سیستم پویا برای مدیریت محتوای یک وب‌سایت بسیار مفید هستند. حال آنکه یک سیستم مدیریت محتوا فراتر از یک سیستم نرم‌افزاری جهت مدیرین محتوای وب‌سایت توسعه یابد بسیار مفید خواهد بود. قابلیت‌ها و ویژگی‌ها با استفاده از سیستم مدیریت محتوای جگوار (Jaguar) ما می‌توانیم برای مشتریان خود یک سیستم مدیریت چند منظوره با قابلیت‌های کاملاً پویا ارائه دهیم که هر استارتاپی می‌تواند کسب‌و‌کار خود را تحت آن توسعه دهد. این سیستم دارای قابلیت‌های چند سکویی و چند منظوره می‌باشد که یکی از قابلیت‌های برجسته‌ی آن پشتیبانی از سیستم چند زبانه می‌باشد. این سیستم در پلتفرم‌های وب، موبایل و دسکتاپ توسعه داده شده است. عنوان: پروژه‌ی جگوار (Jaguar) توضیحات: سیستم مدیریت محتوای چند منظوره و پیشرفته زبان‌ها و فناوری‌های استفاده شده: زبان‌های PHP، C++، JavaScript، QML فریم وُرک‌ و کتابخانه‌ها: کتابخانه‌ی STL, Zend, Qt,, OpenSSL، BootStrap4 ابزار‌های ساخت: qmake، qbs و cmake نوع پروژه: تجاری (انحصاری شرکتِ Dotwaves LLC) نویسندگان: کامبیز اسدزاده وضعیت: در حال توسعه حق چاپ و تکثیر: شرکت دات‌ویوز این محصول بر پایه موتور جِنسیس توسعه داده شده است. برخی از تصاویر مرتبط با این محصول:

با سلام، با توجه به درخواست‌های مکرر از کاربران و اساتید محترم، نیاز جامعه‌‌ی برنامه‌نویسی به معرفی محصولات و قابلیت‌های یک زبان در قالب یک محصول قابل لمس و دیداری احساس می‌شد. بنابراین این بخش با هدف این که توسعه‌دهندگان بومی بتوانند محصولات و پروژه‌های خود را برای معرفی از جنبه‌های فنی و همچنین تجاری مطرح نمایند ایجاد شده است. هدف این است که شما توسعه‌دهنده‌ی محترم بتوانید برای کسب نظر از تجربیات اساتید برای توسعه هرچه بهتر پروژه‌‌ی خود و همچنین معرفی محصول نوشته شده‌ی خود اقدام کنید. در صورتی که محصول شما تحت زبان و استاندارد‌های ویژه‌ای تولید شده است می‌توانید آن را برای همگان نشان دهید تا بتوانند نمونه‌ی واقعی یک محصول را در آن حوزه مشاهده نمایند. اهداف کلی معرفی محصولات نوشته شده توسط زبان‌های مختلف (این کار باعث می‌شود توسعه‌دهندگان قابلیت‌های یک زبان را در پروژه واقعی مشاهده کنند) هر چند ممکن است پروژه‌های کوچکی معرفی شود اما اینکه با یک زبان واقعاً چه کار‌هایی می‌توان انجام داد بسیار مهم است. امکان نظر سنجی و کسب نظرات اساتید و افراد با تجربه برای بهبود هرچه بهتر پروژه شما امکان بررسی و ارسال نظر و امتیاز به پروژه شما جهت کسب امتیاز مهارتی و تجربی امکان بررسی پروژه و رزومه‌های واقعی شما توسط کارفرمایان و اساتید معتبر امکان ایجاد محیط رقابتی برای بهبود مهارت‌های تخصصی و شخصی در توسعه‌دهندگان و در نهایت بهبود مهارت‌های جامعه‌ی برنامه‌نویسی نمونه قالب معرفی پروژه به صورت زیر می‌باشد: عنوان پروژه توضیحات در رابطه با کاربرد پروژه معرفی زبان برنامه‌نویسی بَک‌اِند معرفی زبان یا فناوری‌های به کار گرفته شده در بخش فرانت‌اِند کتابخانه‌ها و فریموُرک‌های استفاده شده نوع پروژه (رایگان یا تجاری) تعداد توسعه دهندگان یا تیم حق چاپ و تکثیر (شخصی یا حقوقی) چند قطعه تصویر استاندارد از محیط محصول مثال: با سلام، عنوان: پروژه‌ی جِنسیس (Genesis) توضیحات: این پروژه یک موتور برنامه‌نویسی چند‌سکویی در قالب یک چهارچوب تخصصی می‌باشد که در توسعه هرچه سریع‌تر محصولات و طراحی و همچنین مستقر سازی آن‌ها بر روی پلتفرم‌های مختلف کمک بسیاری می‌کند. زبان‌ها و فناوری‌های استفاده شده: زبان برنامه‌نویسی ++C فریم وُرک‌ و کتابخانه‌ها: کتابخانه‌ی OpenSSL‌، LibCurl، STL ابزار‌های ساخت: qmake، qbs و cmake نوع پروژه: تجاری (انحصاری شرکتِ Dotwaves LLC) نویسندگان: کامبیز اسدزده حق چاپ و تکثیر: شرکت دات‌ویوز *دوستان می‌توانند نظرات و پیشنهادات خود را در رابطه با این پروژه اعلام کنند.

دستورات زیر را در ترمینال اجرا کنید. sudo apt-get install build-essential sudo apt-get install mesa-common-dev libglu1-mesa-dev

پیشنهادات و ملاحظات در عملکرد و کارآیی همانطور که می‌دانید تولید و توسعه‌ی یک نرم‌افزار با سرعت و کارآیی بالا یکی از مزایایی مهارتی توسعه‌دهندگان است که به تنهایی می‌تواند به عنوان یک فاکتور بسیار مهم مطرح شود. بنابراین در صورتی که شما محصولی را در قالب وب، موبایل یا دسکتاپ تولید می‌کنید باید به آن توجه داشته باشید که سرعت اجرایی برنامه‌ی شما در زمان استارتاپ و بعد در مراحل پردازشی و فرایند‌های دیگر باید مورد قبول باشد. در این میان برنامه‌نویسان سی++ می‌دانند که باید در مدیریت حافظه و دیگر موارد با دقت بیشتری عمل کنند تا بتوانند به حداقل نشتی در حافظه (حتی فاقد نشتی در آن) و در نهایت رسیدن به حداکثر سرعت پردازشی توجه داشته باشند. با توجه به این موضوع که کتابخانه‌ی Qt به عنوان یکی از کتابخانه‌های این زبان بشمار می‌آید؛ بسیاری از توسعه‌دهندگان درگیر توسعه‌ی بخش فرانت‌اِند نیز می‌شوند. بنابراین باید توجه داشت در زمان توسعه رابط کاربری مبتنی بر فناوری Qt Quick مواردی را جهت افزایش کارآیی سرعت و هماهنگی کامل با سی++ را در نظر بگیرند چرا که بدون در نظر گرفتن فاکتور‌های زمانی نتیجه‌ی آن بسیار بد خواهد بود. شما به عنوان یک توسعه دهنده نرم‌افزار، باید برای رسیدن حداکثر فریم ریت ۶۰ در موتور رندرینگ تلاش کنید. این میزان بدین معنی است که بین هر فریم که در میان آن‌ها می‌تواند پردازش انجام شود، تقریباً ۱۶ میلی ثانیه وجود دارد که شامل پردازش مورد نیاز برای بارگذاری‌های اولیه به سمت سخت‌افزار گرافیکی می‌باشد. در عمل، این به این معنی است که توسعه‌دهنده نرم‌افزار باید: هر کجا که ممکن است از روش ناهمزمان (Asynchronous) در بخش برنامه‌نویسی رویدادمحور (Event-driven programming) استفاده کند. در بخش‌هایی که به میزان قابل توجهی شامل پردازش می‌شوند از وُرکر‌ترد‌ (worker threads) استفاده کند. هرگز حلقه رویداد را به صورت دستی برای چرخش و ادامه تنظیم نکند. هرگز بیش از چند میلی ثانیه برای هر فریم در بلوک توابع صرف نکند. عدم انجام این کار‌ها باعث پَرش در فریم‌ها می‌شود که تاثیر بسیار جدی در تجربه‌ کاربری دارد. نکته: الگویی که وسوسه انگیز است اما نباید هرگز از آن استفاده شود، چرا که یک‌‌ متد QEventLoop و یا صدا زدن یک متد دیگر مانند QCoreApplication::processEvent به منظور جلوگیری از مسدود شدن در یک بلوک کُد سی++ که در QML استفاده شده است به کار گرفته می‌شود. این خطرناک است، زیرا زمانی که یک حلقه رویداد در هندلر سیگنال و یا پیوند (Binding) وارد می‌شود، موتور QML همچنان برای اجرای سایر پیوندها، انیمیشنها، ترنسیشن‌ها و غیره می‌پردازد. این اتصالات می‌توانند باعث عوارض‌های جانبی شوند. پروفایلینگ (Profiling) مهمترین نکته این است که: از ابزار QML Profiler که بخشی از محیط توسعه یکپارچه‌ی نرم‌‌افزار Qt Creator است استفاده کنید. زیرا دانستن زمانی که در یک برنامه صرف می‌شود به شما امکان این را می‌دهد تا بر قسمت یا بخشی که در آن مشکل وجود درد تمرکز سریع‌تر و بهتری داشته باشید. برای نحوه‌ی استفاده از این ابزار به کتابچه‌ی راهنمای خود کیوت کریتور مراجعه کنید. تعیین کردن اینکه اغلب کدام پیوند (اتصال) در حال اجرا است، یا کدام یک از توابع شما بیشترین زمان را برای اجرا صرف می‌کنند، به شما این امکان را می‌دهد که تصمیم بگیرید که آیا شما نیاز به بهینه سازی آن بخش از کُدها را دارید یا نیاز خواهد بود آن بخش از کد خود را مجددا پیاده سازی کنید تا عملکرد آن بهتر شود یا خیر. به طور کلی تلاش برای بهینه سازی بدون استفاده از ابزار QML Profiler احتمالاً باعث بهبود‌های جزئی و غیرقابل توجه در عملکرد خواهد شد. کُد جاوا اسکریپ (JavaScript) بیشتر برنامه‌های QML مقدار زیادی از کدهای جاوا اسکریپت در درون خود خواهند داشت. که به شکل توابع پویا، مدیریت سیگنال و یا عبارت‌های مربوط به پراپرتی‌ها (مشخصه، اموال) را در اختیار دارند. به طور کلی این یک مشکل نیست. با تشکر از برخی از بهینه سازی‌های موتور QML، مانند آنهایی که به کامپایلر منتقل می‌شوند، می‌تواند (در بعضی موارد استفاده شده) حتی سریع‌تر از فراخوانی‌های سمت سی++ باشد. با این حال، باید اطمینان حاصل شود که پردازش غیر ضروری به طور تصادفی اتفاق نیفتاده باشد. اتصالات (Binding) دو نوع اتصال در QML وجود دارد: اتصالات بهینه شده و غیر بهینه شده. ایده‌ی خوبی است که عبارات مربوطه را به همان اندازه ساده‌تر حفظ کنید. زیرا موتور QML برای ارزیابی عبارات از یک ارزیابی ساده و بهینه شده استفاده می‌کند که می‌تواند مشخص کند تا نیازی به تغییر آن در محیط جاوا اسکریپت نباشد. این اتصالات بهینه سازی شده بسیار کارآمدتر از اتصالات پیچیده تر (غیر بهینه سازی شده) هستند. الزامات اساسی نیز برای این گونه اتصال‌ها این است که اطلاعات نوع هر نماد که به آن دسترسی دارد باید در زمان کامپایل شناخته شده باشد. عواملی که باعث جلوگیری از به حداکثر رساندن بهینه سازی در عبارات اتصالات می‌شود: تعریف متغیرهای واسط توسط جاوا اسکریپت دسترسی به خواص var صدا زدن توابع جاوا اسکریپت ساخت (آغاز یا خاتمه یافتن) و یا تعریف توابع در میان عبارت‌ اتصالات دسترسی به خواص (پراپرتی‌های) خارج از محدوده ارزیابی فوری نوشتن درمورد سایر عوامل به عنوان عوارض جانبی توجه داشته باشید، زمانی اتصالات سریعتر می‌شوند که نوع اشیاء و خواصی که با آنها کار می‌کنند مشخص شده باشند. این به این معنی است که، خواص غیرنهایی (non-final) ممکن است در بعضی موارد کُند‌تر باشد. (جایی که ممکن است یک خاصیت تغییر کرده باشد). محدوده‌هایی ای که برای ارزیابی فوری می‌توان در نظر گرفت قسمت زیر هستند: ارزیابی در خاصیت‌ عبارت‌های دامنه‌ی یک شیء (برای عبارت‌های اتصال، این است که شیء به کدام یک از خاصیت‌های اتصال تعلق دارد). ارزیابی در شناسه‌های هر یک از اشیاء موجود در کامپوننت (جزء) ارزیابی در خاصیت‌های ریشه‌ی آیتم در یک کامپوننت (جزء) شناسه‌های اشیاء از دیگر کامپوننت‌ها و خاصیت‌های هر یک از اشیاء، مانند نمادهای تعریف شده و یا وارد شده از طرف جاوا اسکریپت در محدوده ی ارزیابی فوری نیستند. به این ترتیب اتصالاتی که به این موارد مربوط هستند نمی‌توانند بهینه سازی شوند. نکته: توجه داشته باشید که اگر نمی‌توانید اتصالات مورد نظر خود را توسط موتور QML بهینه‌سازی کنید، در این صورت باید آن را در محیط کامل جاوا اسکریپت بهینه سازی نمایید. نوع تبدیل (Type-Conversion) یک مزیت عمده برای استفاده از جاوا‌ اسکریپت این است که در اغلب موارد، هنگامی‌‌که به یک ویژگی از نوع QML دسترسی پیدا می‌شود‌، یک شیء جاوا اسکریپت با منبع حاوی سی‌پلاس‌پلاس پایه (یا یک مرجع آن) ایجاد می‌‌گردد. در بیشتر موارد، این عمل به‌نسبت کم‌هزینه است، اما در سایر موارد می‌تواند بسیار پر‌هزینه باشد. یک مثال از پر‌هزینه بودن آن، ارجاع کردن QVariantMap و Q_PROPERTY به ویژگی نوع QML است. لیست‌ها نیز می‌توانند هزینه‌بالایی داشته‌ باشند. اگرچه دنباله‌ی انواع خاص (QList از int، qreal، bool، Qstring و QUrl) باید کم‌هزینه باشد. تبدیل انواع دیگر لیست هزینه‌ی زیادی دارد (ایجاد آرایه‌ی جدید جاوا اسکریپت و افزودن تک به تک انواع جدید، با تبدیل هر نوع از نمونه‌ی‌ نوع سی‌پلاس‌پلاس به مقدار جاوا اسکریپت). رفع سازی خواص‌ها تفکیک پذیری در خواص (پراپرتی‌ها) زمان بر است. در حالی که در بعضی از موارد نتیجه آن می‌تواند ذخیره شده و دوباره مورد استفاده قرار بگیرد. بهتر است همیشه از انجام کارهای غیر ضروری جلوگیری شود. در مثال زیر، ما یک بلوک کد داریم که اغلب اجرا می‌شود (در این مورد، آن شامل یک حلقه صریح است؛ اما برای مثال می‌توان آن را با یک عبارت پیوند و مورد ارزیابی قرار داد). در این مثال مشکل را با در نظر گرفتن شناسه "rect" و خاصیت رنگ "color" آن را چندین بار تغییر و تولید می‌کنیم. این مثال کاری که می‌خواهیم را انجام می‌دهد، اما روش بهینه شده ای نیست بنابراین مثال زیر بسیار بد خواهد بود: import QtQuick 2.3 Item { width: 400 height: 200 Rectangle { id: rect anchors.fill: parent color: "blue" } function printValue(which, value) { console.log(which + " = " + value); } Component.onCompleted: { var t0 = new Date(); for (var i = 0; i < 1000; ++i) { printValue("red", rect.color.r); printValue("green", rect.color.g); printValue("blue", rect.color.b); printValue("alpha", rect.color.a); } var t1 = new Date(); console.log("Took: " + (t1.valueOf() - t0.valueOf()) + " milliseconds for 1000 iterations"); } } برای اینکه کد فوق بهینه سازی شود بهتر است به صورت زیر باشد: import QtQuick 2.3 Item { width: 400 height: 200 Rectangle { id: rect anchors.fill: parent color: "blue" } function printValue(which, value) { console.log(which + " = " + value); } Component.onCompleted: { var t0 = new Date(); for (var i = 0; i < 1000; ++i) { var rectColor = rect.color; // resolve the common base. printValue("red", rectColor.r); printValue("green", rectColor.g); printValue("blue", rectColor.b); printValue("alpha", rectColor.a); } var t1 = new Date(); console.log("Took: " + (t1.valueOf() - t0.valueOf()) + " milliseconds for 1000 iterations"); } } فقط این تغییر ساده باعث بهبود عملکرد قابل توجهی می‌شود. بنابراین، توجه داشته باشید که کد بالا را می‌توان حتی بهبود بیشتری داد (از آنجا که ویژگی مورد نظر هرگز در طول پردازش حلقه تغییر نکرده است)، با بالا بردن دقت خارج از حلقه، به صورت زیر است: import QtQuick 2.3 Item { width: 400 height: 200 Rectangle { id: rect anchors.fill: parent color: "blue" } function printValue(which, value) { console.log(which + " = " + value); } Component.onCompleted: { var t0 = new Date(); var rectColor = rect.color; // resolve the common base outside the tight loop. for (var i = 0; i < 1000; ++i) { printValue("red", rectColor.r); printValue("green", rectColor.g); printValue("blue", rectColor.b); printValue("alpha", rectColor.a); } var t1 = new Date(); console.log("Took: " + (t1.valueOf() - t0.valueOf()) + " milliseconds for 1000 iterations"); } } پیوند خاصیت‌ها (Property Binding) در صورتی که خواص مرجع هر یک از اتصالات تغییر یابند، به آن خاصیت متصل دوباره ارزیابی خواهد شد. به همین ترتیب، عبارات خواص باید به همان اندازه ساده باشند. اگر شما یک حلقه دارید که در آن پردازشی را انجام می‌دهید، اما تنها نتیجه نهایی پردازش مهم است، اغلب بهتر است که موقتاً آن را به‌روز کرده و در صورت نیاز آن را برای به‌روز رسانی یک خاصیت مورد نیاز اختصاص دهید. این کار به منظور جلوگیری از ارزیابی‌های مجدد بسیار مفید خواهد بود. مثال ذکر شده زیر این نکته را نشان می‌دهد که بسیار بد پیاده سازی شده است: import QtQuick 2.3 Item { id: root width: 200 height: 200 property int accumulatedValue: 0 Text { anchors.fill: parent text: root.accumulatedValue.toString() onTextChanged: console.log("text binding re-evaluated") } Component.onCompleted: { var someData = [ 1, 2, 3, 4, 5, 20 ]; for (var i = 0; i < someData.length; ++i) { accumulatedValue = accumulatedValue + someData[i]; } } } حلقه ای که در رویداد onCompleted می‌باشد، موجب می‌شود تا خاصیت متن text به تعداد ۶ بار مجدداً مورد ارزیابی قرار بگیرد (که در نتیجه هر گونه پیوند مرتبط با مقدار متن متکی است) همچنین کنترلر سیگنال onTextChanged هر یک را مجدداً ارزیابی می‌کند و این موجب می‌شود متن هر بار نمایش داده شود. این امر ضروری نیست چرا که هدف ما دسترسی به ارزش نهایی آن خواهد بود. روش پیشنهادی به صورت زیر خواهد بود: import QtQuick 2.3 Item { id: root width: 200 height: 200 property int accumulatedValue: 0 Text { anchors.fill: parent text: root.accumulatedValue.toString() onTextChanged: console.log("text binding re-evaluated") } Component.onCompleted: { var someData = [ 1, 2, 3, 4, 5, 20 ]; var temp = accumulatedValue; for (var i = 0; i < someData.length; ++i) { temp = temp + someData[i]; } accumulatedValue = temp; } } بارگذاری‌ها و منابع مرتبط به تصاویر تصاویر بخش مهمی از رابط کاربری هستند. متأسفانه، به دلیل زمان بارگیری آنها، میزان حافظه ای که مصرف می‌کنند نیز قابل توجه است. بنابراین توجه داشته باشید که در صورتی که اپلیکیشن شما شامل تصاویری با اندازه بزرگتر هستند، اما شما آن را در اندازه‌ی کوچکتر از واقعی خود نشان می‌دهید. در این صورت بهتر است اندازه سورس آن را نیز مشخص کنید که در خاصیت "sourceSize" مشخص می‌شود. این کار باعث می‌شود تا مطمئن شویم عنصور تولید شده با مقیاس کوچکتری در حافظه نگهداری می‌شود. البته مراقب این نیز باشید که تغییر اندازه سورس موجب می‌شود تصویر دوباره بارگیری شود. بارگیری غیر‌همزمان (Asynchronous) معمولاً برنامه‌های زیبا و با کیفیت دارای تصاویر با کیفیت نیز هستند، بنابراین لازم است تا اطمینان حاصل شود که بارگیری یک تصویر یک رشته از UI را بلوک یا مسدود نمی‌کند. خاصیت asynchronous در نوع QML Image را با مقدار true تنظیم کنید تا بارگیری غیرهمزمان از تصاویر بر روی سیستم فایل‌های محلی بارگیری شود. این کار از وارد کردن فشار بر روی تصاویر و رابط کاربری جلوگیری خواهد کرد که نتیجه‌ی آن حفظ زیبایی رابط کاربری شما در زمان بارگذاری تصاویر خواهد شد. نکات ریز اما مهم از سایه پردازی‌ها و تصاویری که در حین زمان اجرا در ترکیب تصاویر شما ایجاد می‌شوند دوری کنید. توجه داشته باشید که در صورت عدم نیاز از خاصیت smooth استفاده نکنید. فعال سازی این خاصیت موجب تولید تصاویر صاف و با کیفیت می‌شود که در سخت افزا‌های قدرتمند توصیه می‌شود. در سخت افزار‌های ضعیف تولید تصاویر صاف زمانبر خواهد بود و در صورتی که اندازه‌ی تصویر واقعی نباشد بر روی نتیجه‌ی آن تاثیری نخواهد داشت. از نقاشی و یا رسم طرح بر روی یک ناحیه به صورت پشت سر هم اجتناب کنید. از نوع Item به عنوان عنصر ریشه به جای Rectangle استفاده کنید. عناصر موقعیت با لنگر استفاده از لنگرها (anchors) به جای اتصالات (bindings) به یک آیتم موقعیت نسبتاً تاثیر بیشتری خواهد داشت. برای مثال برای اتصال موقعیت rect2 به rect1 را توجه کنید: import QtQuick 2.3 .... Rectangle { id: rect1 x: 20 width: 200; height: 200 } Rectangle { id: rect2 x: rect1.x y: rect1.y + rect1.height width: rect1.width - 20 height: 200 } .... این کار را می‌توان توسط لنگر‌ها به طور بسیار موثری انجام داد: import QtQuick 2.3 .... Rectangle { id: rect1 x: 20 width: 200; height: 200 } Rectangle { id: rect2 height: 200 anchors.left: rect1.left anchors.top: rect1.bottom anchors.right: rect1.right anchors.rightMargin: 20 } .... تنظیم موقعیت توسط اتصالات (با اختصاص دادن عبارت‌های اتصال به محورهای x و y طول و ارتفاع به عنوان خواص یک شیء به جای استفاده از لنگر‌ها) هرچند به حداکثر انعطاف پذیری اجازه می‌دهد اما نتیجه تولیدی آن نسبتاً کُند است. در نظر داشته باشید که اگر شیء شما به صورت داینامیک (پویا) تغییر پیدا نمی‌کند، روش مناسب تغییر موقعیت استفاده از خاصیت‌های y، x‌، width و height می‌باشد که متناسب و وابسته به والد خود می‌باشد. در صورتی که می‌خواهید وابستگی ایجاد نشود بهتر است از لنگر‌ها استفاده کنید. در مثال زیر، اشیاء مستطیل (Rectangle) فرزند در یک مکان مشابهی قرار گرفته اند، اما کدهای مرتبط به لنگرها (anchors) نشان میدهد که موقعیت آن شیء به صورت ثابت مقدار دهی شده است. import QtQuick 2.3 Rectangle { width: 60 height: 60 Rectangle { id: fixedPositioning x: 20 y: 20 width: 20 height: 20 } Rectangle { id: anchorPositioning anchors.fill: parent anchors.margins: 20 } } مدلها و نمایش‌ها اکثر برنامه های کاربردی (Application) حداقل از یک مدل (Model) تغذیه داده را به نمایه (View) ارسال می‌کنند. بعضی از مواردی که توسعه دهندگان برای به حداکثر رساندن عملکرد به آنها باید توجه داشته باشند وجود دارد. مُدل‌های سفارشی سمت سی‌پلاس‌پلاس این بسیار خوب است که شما مدل‌های داده‌ای سفارشی خود را سمت ++C برای استفاده ار نمایه‌ی QML بنویسید. اما باید توجه داشته باشید این کار به شدت بستگی به کاربرد آن در موقعیت خودش را دارد که برخی از دستورالعمل های کلی به شرح زیر هستند: تا جایی که ممکن است ناهمزمان باشد. تا جای ممکن بصورت ناهمزمان، تمام پروسه‌های پردازشی را در یک نخ با (اولیت پایین) انجام دهید. عملیات بک‌اند را به صورت دسته ای انجام دهید تا (به طور بالقوه آهسته) عمل‌های I/O و IPC به حداقل برسد. از یک پنجره مجزا برای نتایج کَش که پارامترهایش به پروفایلینگ کمک می‌کنند، استفاده کنید. این مهم است که توجه داشته باشیم استفاده از یک نَخ (Thread) کارآمد با کمترین اولویت توصیه میشود تا خطر قحطی (starving) را در نخ های رابط کاربری به حداقل برساند. همچنین به یاد داشته باشید که مکانیزم هماهنگ سازی و قفل کردن می‌تواند عامل مهمی برای عملکرد آهسته باشد، بنابراین لازم است از اعمالِ قفل غیر ضروری جلوگیری (صرف نظر) شود. نوع لیست مُدل (ListModel) در QML کیوامال (QML) یک نوع ListModel ای را فراهم می‌کند که می‌تواند برای ارسال داده به یک نوع از ListView استفاده شود. این باید برای اکثر موارد مناسب باشد و تا زمانی که به درستی استفاده شود نسبتاً عملکرد درستی داشته باشد. تجمع در داخل یک نخ عناصر ListModel را می توان در یک نخِ کاری (با اولویت پایین) در JavaScript جابجا کرد. توسعه‌دهنده باید صریحاً متد sync() را که به عنوان یکی از خواص موجود در ListModel می‌باشد را داخل یک WorkerScript صدا بزند تا تغییرات همزمان با نَخ اصلی صورت بکیرد. جهت کسب اطلاعات بیشتر مستندات WorkerScript را مطالعه کنید. لطفاً توجه داشته باشید که با استفاده از یک عنصر WorkerScript یک موتور جاوا اسکریپت جداگاه ایجاد می‌شود (چرا که موتور جاوا اسکریپت در هر نَخ (Thread) می‌باشد). این باعث افزایش مصرف حافظه خواهد شد. چرا که عناصر متعدد (چندگانه) WorkerScript همه از یک نَخ استفاده خواهند کرد. بنابراین تاثیر شدیدی در حافظه‌ی استفاده شده توسط وُرکر دوم و سوم وارد خواهد کرد که در زمان اجرای برنامه و وُرکر اسکریپت اول تاثیر آن بسیار ناچیز خواهد بود. از نقش‌های (Roles) پویا استفاده نکنید عنصر ListModel در QtQuick 2 بسیار کارآمدتر از QtQuick است. بهبود عملکرد عمدتاً از پیش فرض‌های مربوط به نوع نقشها (Roles) در هر عنصر در یک مدل داده می‌شود. اگر نوع آن تغییر نکند، عملکرد ذخیره سازی به طور چشمگیری بهبود می‌یابد. اگر نوع قابلیت تغییر به صورت پویا از عنصر به عنصر دیگری را داشته باشد، بهینه سازی غیر ممکن شده و عملکرد (پرفرمنس - کارآیی) مدل به اندازه‌ی بزرگی بدتر و کُند‌تر خواهد شد. بنابراین به صورت پیشفرض حالت داینامیک غیر فعال بوده و توسعه‌دهنده خود باید خاصیت dynamicRoles را به عنوان یکی از خاصیت‌های ListModel فعال کند. البته به شدت پیشنهاد می‌شود برنامه‌ی خود را از اول طراحی کنید اما این قابلیت را فعال نکنید. نمایه‌ها (Views) توجه داشته باشید که نماینده (دلیگیتس یا delegates) باید به طور ساده حفظ شود. به اندازه‌ی کافی از انواع QML در این خاصیت‌های ضروری استفاده کنید. هرگونه قابلیت اضافه که بلافاصله مورد استفاده قرار نمی‌گیرد نیاز نیست. برای مثال اگر نیاز است اطلاعات بیشتری در موقع کلیک بر روی آیتم نمایش داده شود، نیاز نیست که همان لحظه ایجاد و بر روی آیتم نمایان شوند. نباید تا قبل از زمان نیاز ایجاد شوند. لیست زیر، خلاصه‌ی خوبی از مواردی است که باید هنگام طراحی بر روی خاصیت delegate در نظر داشته باشید: عناصری که کمتر در خاصیت delegate هستند، سریعتر می توانند ایجا شوند، و بنابراین سریعتر میتوانند در نمایه (view) مشاهده و اسکرول شوند. تعداد پیوندها (اتصالات) را در delegate به حداقل تعدادشان نگه داری کنید. از لنگرها (anchors) به جای اتصال برای موقعیتهای نسبی در یک delegate استفاده شود. از به کار گیری عناصر ShaderEffect در delegate اجتناب شود. هرگز خاصیت clip را در خاصیت delegate فعال نکنید. نکته: شما می‌توانید ویژگی cacheBuffer یک نمایه (view) را تنظیم کنید تا اجازه ایجاد و ارسال غیر مستقیم به delegate خارج از ناحیه قابل مشاهده را ایجاد کنید. استفاده از cacheBuffer برای delegate های نمایشی توصیه می شود. توجه داشته باشید که خاصیت delegate یک cacheBuffer اضافی را در حافظه نگه می‌دارد، بنابراین مقدار حاصل از استفاده cacheBuffer باید با استفاده از حافظه اضافی متعادل شود. توسعه‌دهندگان خود باید از معیارهای سنجش (بنچ مارک‌ها) برای یافتن بهترین مقدار مناسب برای استفاده را انجام دهند. چرا که افزایش حافظه ناشی از استفاده cacheBuffer می‌تواند در بعضی از موارد نادر، باعث کاهش نرخ فریم در هنگام پیمایش (اسکلرول) شود. جلوه‌های بصری فناوری کیوت کوئیک ۲ شامل چند ویژگی است که به توسعه‌دهندگان و طراحان اجازه می‌دهد تا رابط کاربری فوق العاده جذاب ایجاد کنند؛ تغییرات پویا (داینامیکی) و همچنین جلوه‌های بصری می‌توانند برای یک اثر بزرگ در برنامه‌‌ی کاربردی مورد استفاده قرار گیرد. اما هنگام استفاده از بعضی از ویژگی‌های QML، باید نکاتی را در نظر گرفت که می‌توانند دلالت بر کارآیی (پرفرمنس) را داشته باشند. انیمیشن‌ها به طور کلی، متحرک سازی (انیمیشن سازیِ) یک خاصیت (پراپرتی) می‌تواند سبب شود تا اتصالاتی که به یک خاصیت دیگر اشاره می‌کند را مجدداً مورد ارزیابی قرار گیرد. معمولاً این مورد مطلوب است، اما در برخی از موارد ممکن است بهتر باشد قبل از انجام متحرک سازی (انیمیشن سازی) اتصالات را غیر فعال کنید، و سپس آن انیمیشن را تکمیل کنید. از اجرای کدهای جاوا اسکریپت در طول یک انیمیشن اجتناب کنید. برای مثال، اجرای یک عبارت پیچیده جاوا اسکریپت برای هر فریم از انیمیشنِ یک خاصیت مانند x باید اجتناب شود. توسعه‌دهندگان باید در استفاده از انیمیشن‌های اسکریپتی دقت کنند، زیرا آنها در یک نخ اصلی اجرا می‌شوند (در نتیجه در صورتی که اجرا و تکمیل انیمیشن بیش از حد طول بکشد)، ممکن است فریم‌هایی را پرش کرده و موجب کاهش کارآیی اصلی آن‌ شود. ذَرات، پارتیکل (Particles)‌ ماژول Qt Quick Particles اجازه می‌دهد تا ذراتی را برای زیبایی هرچه بهتر رابط کاربری اضافه شود. با این حال، هر پلتفرم دارای قابلیت‌های سخت افزاری مختلفی است و ماژول Particles قادر به محدود کردن پارامترهای سخت افزاری شما نمی‌باشد. بنابراین زمانی که شما ذرات بیشتری برای تولید (رندر) می‌خواهید (هرچه بزرگتر می شوند)، سرعت بیشتری برای پردازش سخت افزار گرافیکی شما نیاز خواهد بود تا بتواند سرعت تولید آن‌ها را با نرخ ۶۰ فریم بر ثانیه اجرا کند. بنابراین ذرات بیشتر خواهان پردازنده‌های مرکزی سریعتری می‌باشند. بنابراین، این بسیار مهم است که تمام ذرات و اثرات آنها را بر روی پلتفرم‌های هدف خود با دقت آزمایش کنید، تا برای کالیبره کردن تعداد و اندازه ذرات قابل تولید با نرخ ۶۰ فریم به نتیجه قابل قبول برسید. لازم به ذکر است که برای جلوگیری از شبیه سازی غیر ضروری یک سیستم ذره را می‌توان غیر فعال کرد (به عنوان مثال عنصری را غر قابل مشاهده کنید) این کار باعث می‌شود تا شبیه سازی‌های غیر ضروری غیر فعال شوند. عملکرد سیستم ذرات با مقایس تعداد ذرات نگه داری می‌شود. پس از نمونه برداری از اثر مورد نظر، با کاهش مقدار ذرات، عملکرد آن را می‌توان بهبود داد. برعکس، اگر عملکرد آن به خوبی و در حد قابل قبول باشد، می‌توان تعداد ذرات را تا زمانی که در آن نقطه قرار می‌گیرد افزایش دهید(این کار باعث بهبود خواهد شد). همانند ShaderEffect، عملکرد سیستم ذرات تا حد زیادی وابسته به سخت افزار گرافیکی است که در حال اجرا می‌باشد. کنترل طول عمر عنصر با تقسیم کردن یک برنامه به اجزای ساده، ماژولار، هرکدام از آنها در یک فایل QML منعکس می‌شوند، می‌توانید زمان راه اندازی برنامه را سریعتر و کنترل بیشتری از استفاده از حافظه را به دست آورده و تعداد عناصر فعال اما غیر قابل مشاهده را در برنامه خود کاهش دهید. به طور کلی سعی کنید برای هر ماژول یا بخشی از برنامه یک سند جداگانه از QML را فراهم کنید. مقدار‌دهی اولیه سریع (از روی تنبلی)! موتور QML برخی چیزها را به صورت هوشمندانه (یا زیرکانه) انجام می‌دهد تا اطمینان حاصل شود که بارگذاری و مقدار دهی اولیه اجزاء باعث نمی‌شود تا فریم‌ها از بین بروند. با این حال هیچ راهی برای کاهش زمان راه اندازی بهتر از این وجود ندارد که شما کارهایی را تا زمانی که به آن‌ها نیاز ندارید را انجام ندهید و از آن‌ها اجتناب کنید. این ممکن است با استفاده از اجزای پرکاربردی مانند نوع Loader یا ساخت کامپوننت (جزء)‌های پویا (Dynamic Object Creation) انجام شود. استفاده از بارکننده (لودر - Loader) لودر یک عنصری است که اجازه می‌دهد بارگذاری و تخلیه پویا بر روی اجزاء انجام شود. با استفاده از ویژگی "active" در Loader، مقدار دهی اولیه میتواند تا زمان لازم انجام شود. با استفاده از تابع setSource() مقدار دهی اولیه می‌تواند تامید شود. تنظیم خاصیت asynchronous بر روی مقدار true می‌تواند تاثیر بر روی بهبود عملکرد بر روی کامپوننت (جزء) در زمان نمونه سازی داشته باشد. استفاده از سازنده‌ی پویا توسعه دهندگان می‌توانند از یک تابع Qt.createComponent() برای ایجاد یک مولفه به صورت پویا در زمان اجرا از داخل جاوا اسکریپت استفاده کنند و سپس createObject() را برای نمونه سازی آن، فراخوانی کنند. نابود کردن عناصر استفاده نشده عناصری که مخفی هستند به عنوان فرزندی از عناصر غیر بصری محسوب می‌شوند. برای مثال زمانی که یک زبانه از TabBar یا TabWidget انتخاب شده است و نمایش داده می‌شود به لایلی باید سریع مقدار دهی اولیه شوند و زمانی که از آن به مدت طولانی استفاده نمی‌شود و این خود باعث بارگذاری اضافی است. بنابراین در صورت استفاده از این روش جهت جلوگیری از این هزینه مداوم در زمان اجرا ( که شامل تولید انیمیشن، اتصالات، رندرینگ و غیره...) به صورت خودکار حذف می‌شوند. نکته: یک آیتم بارگذاری شده با یک نوع عنصر Loader ممکن است توسط تنظیمات مجدد خاصیت source یا sourceComponent آزاد شود. در حالی که موارد دیگر ممکن است به صورت صریح با فراخوانی متد destroy() بر روی آنها منتشر شود. در بعضی از موارد ممکن است لازم باشد آیتم فعال را ترک کرده و یا حداقل آن را نامرئی کنید. این کار موجب می‌شود سرعت برنامه‌ی شما بهینه شود. تولید (رندرینگ) Rendering گرافیک صحنه‌ای که برای رندر در کیوت کوئیک ۲ استفاده می‌شود، رابط کاربری بسیار متحرک را به صورت فیزیکی در ۶۰ فریم بر ثانیه ارائه می‌کند. با این حال برخی چیزها به طور چشمگیری در عملکرد رندرینگ کاهش می‌یابند. توسعه دهندگان باید مراقب باشند تا از این مشکلات در هر جا که ممکن است اجتناب کنند که به برخی از آن‌ها اشاره شده است. کلیپ کردن (Clipping) کلیپ کردن به صورت پیشفرض غیرفعال است و توصیه می‌شود تنها زمانی که به آن نیاز دارید فعالش کنید. کلیپ کردن یک اثر بصری دارد، نه بهینه سازی! بنابراین این ویژگی پیچیدگی بیشتری را برای رندرینگ افزایش می‌دهد. اگر کلیپ فعال باشد، اجزای تولید شده خود و دیگر اجزای فرزندش را به محدوده خود متصل خواهد کرد. این باعث می‌شود رندرینگ در آن بخش متوقف شده و آن بخش از اشیاء مرتبط و منظم دیده شوند. نکته مهم این است که کلیپ کردن در داخل delegate بسیار نامناسب است و باید از این کار اجتناب شود. چرا که موجب کاهش کارآیی برنامه خواهد شد. نقاشی بیش از اندازه و عناصر نامرئی اگر شما عناصری دارید که توسط عناصر دیگری (مات) یا پوشانیده شده اند، بهتر است از خاصیت visible استفاده کرده و آن را به مقدار false تنظیم کنید. برای مثال در زبانه‌هایی که به صورت پیشفرض یکی از آن‌ها فعال هستند و زبانه‌های دیگر تا زمان انتخاب مخفی! در این صورت بهتر است آیتم‌های آن‌ها به از طرف والد آن‌ها مخفی شوند تا در زمان اجرا بابت نمایش مواردی که مخفی هستند هزینه‌ای نشود. شفاف در مقابل مات محتوای مبهم (مات) عموماً بسیار سریعتر از محتوای شفاف هستند. دلیل این امر این است که محتوای شفاف نیاز به ترکیب (مخلوط) کردن دارند و سیستم رندر کننده به مراتب می‌تواند نوع مات را بهتر بهینه سازی نماید. یک تصویر با یک پیکسل شفاف به طور کامل به عنوان یک نتیجه کاملاً شفاف تلقی می‌شود، حتی اگر عمدتاً مات باشد. همین امر برای نوع BorderImage با لبه های شفاف درست است. سایه‌ها نوع ShaderEffect باعث می‌شود که کد درون خطی GLSL را به صورت یکپارچه در یک برنامه Qt Quick با سربار بسیار کم قرار دهید. با این حال مهم است که بدانید، که قِطعه برنامه نیاز به اجرا برای هر یک از پیکسل‌ها در شکل تولید شده را دارد. هنگام استقرار بر روی یک سخت افزار با توان پایین، شیدر‌ها مقدار زیادی از پیکسل‌ها را پوشش می‌دهند برای جلوگیری از عملکرد ضعیف، باید یک قطعه شیدر را برای چند دستورالعمل جهت جلوگیری از پرفرمنس ضعیف نگهداری کنید. شیدرهای نوشته شده در GLSL اجازه می‌دهد تا تبدیلات و جلوه‌های پیچیده‌تری را تولید کنید. با این حال باید با دقت بسیاری از آنها استفاده کرد. استفاده از ShaderEffectSource باعث از پیش رندر شدن صحنه به FBO قبل از کشیده شدن آن می‌شود . این سربار اضافی می‌تواند بسیار پر‌هزینه باشد. تخصیص و جمع آوری حافظه مقدار حافظه‌ای که توسط یک برنامه اختصاص داده می‌شود و اینکه آن حافظه چگونه اختصاص داده می‌شود شامل ملاحظات بسیار مهمی هستند. صرف نظر از نگرانی‌های مربوط به خارج از حافظه در دستگاه‌های محدود به حافظه، تخصیص حافظه در پُشته به عنوان یک عمل محاسباتی نسبتاً گران می‌باشد. در این میان استراتژی‌های اختصاصی تخصیص حافظه می‌تواند باعث افزایش تقسیم داده‌ها در صفحات شود. خوشبختانه، جاوا اسکریپت از روش مدیریت حافظه خودکار در پُشته (Heap) در قالب GC پشتیبانی می‌کند که دارای برخی از مزیت‌ها است. اما با این حال دلالت بر مهم بودن برخی موارد دارد. یک برنامه نوشته شده در QML حافظه را از هر دو پُشته از سمت مدیریت حافظه تحت ++C و JavaScript مدیریت می‌کند. توسعه دهنده نرم‌افزار باید در رابطه با هر یک از آنها به منظور به حداکثر رساند پرفرمنس آگاه باشد. نکاتی برای توسعه‌دهندگان برنامه QML نکات و پیشنهادات موجود در این بخش تنها در قالب دستورالعمل هستند و ممکن است در همه شرایط قابل اجرا نباشند. با استفاده از معیارهای تجربی و بررسی بنچ مارک‌ها و همچنین آنالیز و همچنین با استفاده از ومعیار‌های تجربی برنامه خودتان بهترین تصمیم ممکن را بگیرید. اگر برنامه شما شامل نمایه (View) های متعدد (به عنوان مثال زبانه‌های چندگانه) می‌باشد اما در هر زمان تنها یکی از آنها مورد نیاز است در این صورت برای کم کردن حافظه مصرفی می‌توانید از روش مقدار‌دهی سریع (از روی تنبلی) استفاده کنید که در بالا به آن اشاره شده است. نابود سازی اشیاء ای که مورد استفاده قرار نمی‌گیرند اگر شما از روش ساده بارگیری کامپوننت‌ها و یا ساخت اشیاء به صورت پویا در طول یک عبارت جاوا اسکریپتی استفاده می‌کنید، بهتر است آنها را به صورت دستی توسط متد destroy() نابود کنید. این بهتر از آن است که منتظر باشید تا به صورت خودکار سیستم GC آن‌ها را جمع آوری و نابود کند. در زمانی که نیاز نیست به صورت دستی عمل GC (بازیافت حافظه) را انجام ندهید در اکثر موارد، دستیابی به مجموعه زباله‌ها به منظور دستیبای به آن نیست. زیرا این کار به مدت زیادی نخ‌های سمت رابط کاربری را مسدود می‌کند. این کار باعث می‌شود فریم‌ها و پرش‌هایی در انیمیشن‌های متحرک به وجود آید که باید از اینگونه هزینه ها اجتناب شود. به طور کلی باید توجه داشته باشید که به صورت مستقیم و دستی همه جا نباید اقدام به نابود سازی حافظه اخصاص یافته شده کنید. اجتناب از اتصال پیچیده گذشته از اینکه اتصالات پیچیده موجب کاهش پرفرمنس (کارایی) می‌شود استفاده از آن‌ها (برای مثال، زمانی که نیاز است ارزیابی جداگانه تحت کد‌های جاوا اسکریپت شود) به صورت پیچیده‌ای حافظه بیشتری را در هر دو پُشته ++C و JavaScript برای بهینه سازی محاسبات اختصاص می‌دهند. بنابراین نیاز نیست همیشه از اتصالات پیچیده و ارزیابی آن‌ها تحت JS استفاده کرد. اجتناب از تعریف چند نوع ضمنی یکسان اگر یک عنصر QML یک خصوصیت سفارشی تعریف شده در QML داشته باشد، آن نوع خاصی و ضمنی خود را میگیرد. این مورد در بخش بعدی بیشتر توضیح داده شده است. اگر چندین نوع ضمنی یکسان در یک جزء درون خطی تعریف شده باشند، موجب هدر‌رفتن بخشی از حافظه خواهند‌ شد. در این وضعیت معمولاً بهتر است که جزء را به‌صورت صریح تعریف کنیم که بعدا می‌تواند دوباره استفاده شود. تعریف یک اخاصیت سفارشی اغلب می تواند در بهینه سازی عملکرد سودمندی داشته باشد (برای مثال، برای کاهش تعداد پیوند‌هایی که مورد نیاز است یا دوباره ارزیابی می‌شوند)، یا می‌تواند ماژولار بودن و قابلیت نگهداری یک جزء را بهبود بخشد. در این موارد، استفاده از خواص سفارشی پیشنهاد می‌شود. با این حال، نوع جدید باید، اگر از بیش از یک بار استفاده می شود، به جزء خود (فایل .qml) به منظور حفظ حافظه، تقسیم شود. استفاده مجدد از اجزای موجود اگر شما در حال تعریف یک جزء جدید هستید، لازم است دوباره بررسی کنید که چنین جزئی در پلتفرم شما وجود دارد یا خیر. در غیر این صورت شما باید موتور QML را مجبور به ساخت و ذخیره سازی نوع داده برای یک نوع که نیاز است کنید که به عنوان یک نوع تکراری که از اجزای موجود می باشد بارگذاری می‌شود. به جای کتابخانه‌های اسکریپتی پراگما از انواع تک تک (singleton) استفاده کنید. اگر از یک اسکریپت کتابخانه pragma برلی ذخیره داده های نمونه استفاده می‌کنید، به جای استفاده از یک نوع تک تکی از QObject استفاده کنید. نتیجه آن در کارآیی بهتر تاثیر گذار خواهد بود و باعث می‌شود حافظه کوچکتری در پُشته‌ی جاوا اسکریپت مورد استفاده قرار گیرد. اختصاص دادن حافظه در یک برنامه QML استفاده از حافظه یک برنامه مبتنی بر QML ممکن است به دو بخش تقسیم شود: استفاده از پُشته سمت ++C و پشته‌ی سمت JavaScript می‌باشد. برخی از حافظه اختصاص داده شده در هر یک از اجزاء غیرقابل اجتناب خواهند بود. به عنوان آن که توسط موتور QML یا موتور جاوا اسکریپت اختصاص داده می‌شود. در حالی که بقیه آن وابسته به تصمیمات گرفته شده توسط توسعه دهنده اپلیکیشن می‌باشد. پشته در ++C شامل موارد زیر خواهد بود: سربار ثابت و اجتناب ناپذیر از موتور QML (پیاده سازی ساختارهای داده، اطلاعات زمینه و غیره). اطلاعات هر جزء کامپایل شده و نوع داده‌ها، شامل هر یک از انواع و فرا داده هایی می‌باشد، که توسط موتور QML بسته به نوع ماژول‌ها و کامپوننت‌هایی است که توسط اپلیکیشن بارگیری می‌شوند. هر شیء‌ای که در داده‌های سی++ (شامل مقادیرِ خاصیت) به همراه هر یک از عناصر متا آبجکت هستند که وابسته به کامپوننت‌ (اجزای) معرفی شده توسط اپلیکیشن می‌باشند. هر داده ای که به طور خاص توسط QML اختصاص داده می‌شود که شامل کتابخانه‌های وارد شده نیز هستند. پشته در JavaScript شامل موارد زیر خواهد بود: سربار ثابت و اجتناب ناپذیر از موتور QML (خودش انواع از قبل ساخته شده‌ی جاوا اسکریپتی را دارد). سر بار ثابت شده و اجتناب ناپذیر از ادغام جاوا اسکریپت (توابع سازنده برای انواع داده های بارگذاری شده، قالب‌های توابع، و غیره). اطلاعات مربوط به هر نوع و و دیگر انواع داخلی توسط موتور جاوا اسکریپت که در زمان اجرا تولید می‌شود. هر شیء ای که به عنوان داده جاوا اسکریپتی (خاصیت‌های نوع var ، توابع جاوا اسکریپتی و هندلرهای سیگنال و عبارات بهینه نشده). متغیرهای اختصاص داده شده در زمان ارزیابی عبارت‌ علاوه بر این، یک پشته جاوا اسکریپتی اختصاص یافته شده برای استفاده از نَخ اصلی و دیگری در پُشته جاوا اسکریپت برای استفاده در WorkerScript اختصاص یافته می‌شود. اگر یک اپلیکیشن از یک عنصر WorkerScript استفاده نکند متحمل به سربار گیری نخواهد شد. اندازه پشته در جاوا اسکریپت می‌تواند به چندین مگابایت برسد و بنابراین برنامه‌های نوشته شده برای دستگاه هایی که دارای محدودی حافظه هستند، ممکن است بهترین با اجتناب از عنصر WorkerScript باشد، با وجود سودمندی آن در مدل‌ها لیستی، که به صورت یکپارچه ذخیره می‌شوند باشد. توجه داشته باشید که هر دو موتور QML و JavaScript به طور خوکار مخازن خود را از نوع داده های ملاحظه شده تولید خواهند کرد. هر کامپوننت (جزء) توسط یک برنامه بارگذاری می‌شود که یک نوع متمایز (صریح) بوده و هر عنصر (به جای کامپوننت) ویژگی‌های سفارشی خود را در QML که به صورت ضمنی است تعریف می‌کند. مثال زیر را در نظر بگیرید: import QtQuick 2.3 Item { id: root Rectangle { id: r0 color: "red" } Rectangle { id: r1 color: "blue" width: 50 } Rectangle { id: r2 property int customProperty: 5 } Rectangle { id: r3 property string customProperty: "hello" } Rectangle { id: r4 property string customProperty: "hello" } } نمونه‌های قبلی مستطیل‌های r0 و r1 دارای ویژگی‌های اختصاصی (سفارشی) نبودند. بنابراین موتورهای جاوا اسکریپت و QML هر دو آنها را از همان نوع در نظر می‌گیرند. به عبارت دیگر هر دوی آن‌ها به عنوان یک نوع صریح از Rectangle (مستطیل) در نظر گرفته می‌شوند. مستطیل‌های r2، r3 و r4 هر یک از آنها با داشتن ویژگی‌های اختصاصی خود هر کدام با انواع مختلف ضِمنی در نظر گرفته شده‌اند. حتی اگر اطلاعات مربوط به ویژگی‌های یکسانی داشته باشند. ملاحظات اختصاصی در عُمق حافظه هرگاه تصمیماتی در خصوص تخصیص دادن حافظه یا کارآیی آن به وجود آید، این مهم است که تاثیرات شدید در عملکرد پردازنده مرکزی و مخازن مربوط به آن، صفحه بندی‌‌های سیستم‌عامل و بازیافت حافظه (GC) در جاوا اسکریپت را در نظر داشته باشید. بنابراین راه حل‌های بالقوه باید با دقت بررسی شوند تا مطمئن شوید که بهترین مورد را انتخاب کرده‌اید. هیچ مجموعه‌ای از دستور العمل‌های کلی نمی‌تواند یک درک جامع ای از اصول اساسی علوم رایانه را با یک دانش علمی از جزئیات پیاده سازی کرده و پلتفرمی که یک توسعه‌دهنده‌ی نرم‌افزار در حال توسعه آن است را جایگزین کند. تقسیم بندی تقسیم بندی به عنوان یک مسأله برای توسعه در سی‌پلاس‌پلاس است. اگر توسعه‌دهنده برنامه هیچ نوع یا پلاگینی از سی‌پلاس‌پلاس را تعریف نکند، ممکن است آنها را در این بخش با خیال راحت نادیده بگیرند. با گذشت زمان، یک برنامه بخش بزرگی از حافظه را برای خود اختصاص داده و داده‌ها را به آن حافظه ارسال می‌کند و بعضی اوقات برخی از قسمت های آن را پس از اتمام استفاده آن‌ها را آزاد می‌کند. این می‌تواند منجر به «حافظه آزاد» شده ای در تکه‌های غیر مجاور شود که نمی‌تواند برای برنامه های کاربردی دیگر توسط سیستم‌عامل مورد استفاده قرار گیرد. همچنین تاثیر شدیدی بر روی ذخیره سازی پنهان و دسترسی به ویژگی‌های یک اپلیکیشن می‌گذارد. زیرا داده‌هایی که زنده هستند (در حال استفاده) هستند، ممکن است در بسیاری از صفحات مختلف حافظه فیزیکی گسترش یابند. این به نوبه خود می‌تواند سیستم‌عامل را مجبور به (swap) یا مبادله کند که می‌تواند سبب شود تا عمل I/O ایجاد شود که به شدت عمل آهسته‌ای بشمار می‌آید. تقسیم بندی می‌تواند توسط دیگر موارد تخصیص دهنده حافظه، با کاهش میزان حافظه‌ای که در هر زمان با دقتِ مدیریتِ زمان زندگیِ اشیاء مورد بررسی قرار گیرد. با تمیز کردن و باز سازی دوره‌ای از حافظه‌ها یا با استفاده از زمان اجرا بر روی حافظه از تجزیه آن می‌توان جلوگیری کرد که توسط سیستم‌عامل بازیافت حافظه خودکار (GC) مانند جاوا اسکریپت ممکن است. بازیافت حافظه جاوا اسکریپت سیستم بازیافت حافظه به صورت خودکار را فراهم می‌کند. حافظه ای که در دسته جاوا اسکریپتی قرار دارد (بر خلاف پُشته در سی‌پلاس‌پلاس) متعلق به موتور خود جاوا اسکریپت است. این موتور به طور دوره‌ای تمامی داده‌های نا مشخص (غیر قابل استفاده) را در پُشته‌ی جاوا اسکریپت جمع آوری می‌کند. پیامد‌های بازیافت حافظه بازیافت حافظه، مزایا و معایبی دارد. این به این معنی است که مدیریت عمر مفید شیء به صورت دستی اهمیت کمتری دارد. با این حال، این بدان معنی است که یک عمل بالقوه طولانی مدت ممکن است توسط موتور جاوا اسکریپت در زمانیکه که خارج از کنترل توسعه‌دهنده نرم افزار است آغاز شود. استفاده از پُشته در جاوا اسکریپت با دقت بسیاری توسط توسعه‌دهنده برنامه مورد توجه قرار می گیرد. لذا تکرار و مدت زمان بازیابی حافظه ممکن است تاثیر منفی بر تجربه نرمافزار داشته باشد. فراخوانی بازیابی حافظه یک برنامه نوشته شده در QML (به احتمال زیاد) در یک مرحله‌ای به بازیافت حافظه (GC) نیاز دارد. در صورتی که حجم حافظه آزاد شده کم باشد سیستم بازیافت خودکار حافظه توسط موتور جاوا اسکریپت انجام می‌شود. بعضی اوقات این کار در صورتی که توسعه‌دهنده‌ی نرم‌افزار تصمیمی در مورد اینکه چه زمانی بازیافت حافظه را انجام دهند نگرفته باشد می‌تواند مناسب باشد. (اگر چه که معمولاً این مورد مطرح نمی‌شود). توسعه‌دهنده نرم‌افزار احتمالاً می‌داند که برنامه چه زمانی را به مدت قابل ملاحظه‌ای بیکار است. اگر یک برنامه QML از حافظه بسیار زیادی از پُشته جاوا اسکریپت را مصرف کند، باعث می‌شود چرخه و تکرار‌های مکرری در بازیافت حافظه صورت گیرد که در وظایف حساس بر روی کارآیی تاثیر خواهد گذاشت. مانند (لیست پیمایش، انیمیشن‌ها، و غیره). توسعه‌دهنده نرم‌افزار ممکن است به‌طور دستی به بازیافت حافظه در طول دوره صفر فعالیت کمک کند. دوره های بیکاری برای انجام بازیافت حافظه ایده آل هستند چرا‌‌که کاربر هیچ‌گونه تضعیفی را در تجربه کاربری خود (فریم‌های پرش شده، انیمیشن‌های پر‌تحرک و نا‌منظم و غیره) حس نخواهد‌کرد؛ که این تضعیف تجربه، در‌نتیجه فراخوانی بازیافت حافظه به هنگام فعالیت برنامه رخ می‌هد. توسعه‌دهنده نرم‌افزار احتمالاً می‌داند که برنامه چه زمانی را به مدت قابل ملاحظه‌ای برای بیکاری بکار می‌گیرد. اگر یک برنامه QML از حافظه بسیار زیادی از پُشته جاوا اسکریپت را مصرف کند، باعث می‌شود چرخه و تکرار‌های مکرری در بازیافت حافظه صورت گیرد که در وظایف حساس بر روی کارآیی تاثیر خواهد گذاشت. مانند (لیست پیمایش، انیمیشن‌ها، و غیره). از طرفی ممکن است توسعه‌دهنده با دستکاری بازیافت حافظه موجب تخریب آن شوند. بازیافت حافظه ممکن است به صورت دستی با فراخوانی gc() در جاوا اسکریپت اعمال شود. این باعث می‌شود یک چرخه بازیافت جامع از حافظه صورت بگیرد که ممکن است مدت زمانی بین چند صد تا بیش از هزار میلی ثانیه برای تکمیل آن سپری شود. بنابراین در صورت امکان باید از آن اجتناب شود. حافظه در مقابل کارآیی در بعضی موارد ممکن است که زمان پردازش حافظه برای سبک سنگین کردن افزایش مصرف حافظه کاهش یابد. برای مثال، ذخیره سازی نتیجه یک جستجوی نماد که در یک حلقه تنگ به یک متغیر موقت در یک عبارت جاوا اسکریپتی استفاده می‌شود که در بهبود ارزیابی این عبارت تاثیر قابل توجهی خواهد داشت. اما این شامل تخصیص یک متغیر موقت می‌باشد. در بعضی از موارد، این سبک سنگین کردن ممکن است معقول باشد (مانند موارد فوق، ک تقریباً همیشه منطقی هستند)، اما در موارد دیگر ممکن است بهتر باشد تا اجازه دهیم تا پردازش طول بکشد تا از افزایش فشار بر روی حافظه سیستم جلوگیری شود. در بعضی از موارد، تاثیر افزایش فشار بر روی حافظه می‌تواند شدید باشد. در برخی موارد، استفاده دوباره از حافظه ممکن است برای به دست آوردن عملکرد پیشنهادی منجر به افزایش ترافیک صفحات یا ترافیک بر روی حافظه نهان شود که باعث کاهش عملکرد شدید آن خواهد شد. این همیشه برای ارزیابی لازم است، تاثیر تعاملات با دقت به منظور تعیین اینکه بهترین راه حل در یک وضعیت خاص است مهم هستند.

شما می‌تونید اون QtObject رو حذف و مستقیم پراپرتی‌های عمومی تعریف کنید، باز هیچ ایرادی نداره اما در اصل QtObject به عنوان یک عنصر غیر بصری می‌تونه نام اشیاء رو بگیره و اون‌ها رو در جایی که می‌خواین در اختیارتون قرار بده. مثلاً وقتی می‌خواین یک کامپوننت یا ماژول یا هر نوع افزونه‌ای به بخشی از برنامه‌ی خودتون در QML اضافه کنید بهتره از QtObject هم استفاده کنید تا اشیاء مربوط به اون واحد رو به صورت اختصاصی تعریف و سفارشی سازی کنید که در توسعه و حتی برقراری ارتباط با سی‌++ بسیار مفید خواهد بود.

همین روشی هست که مثال زدم، فقط از یه فایل js کمک گرفته که تو این مراحل نیازی نیست.

سادست که! محتوای فایل اول هست MyFirstFile.qml و محتوای فایل دوم MySecondFile.qml پایینی هست. فایل اول شما شامل Component ای هستش که می‌خواهید مقادیرش رو تو فایل دیگه‌ای تغییر بدین. فایل دوم که شامل فراخوانی و اعمال تغییرات روی کامپوننت به حساب میاد.

از پراپرتی‌های سراسری و همچنین QtObject استفاده کنید، نمونه مثال زیر رو برای این منظور نوشتم که پاسخ سوال شماست. //MyFirstFile.qml import QtQuick 2.11 import QtQuick.Controls 2.2 Page { property color setColor: "green" property string setTitle: "Hi" QtObject { id: myObjectSetting property color color: setColor property string title: setTitle } Loader { sourceComponent: myComp anchors.centerIn: parent } Component { id: myComp Rectangle { color: myObjectSetting.color; width: 100; height: 100; Text { anchors.centerIn: parent text: myObjectSetting.title color: myObjectSetting.color } } } } //MySecondFile.qml import QtQuick 2.11 import QtQuick.Layouts 1.3 import QtQuick.Controls 2.4 ColumnLayout { anchors.centerIn: parent MyFirstFile { id:myItem setTitle: "Hi" setColor: "red" } Button { text: "Change" onClicked: { myItem.setColor = "yellow" myItem.setTitle = "Bye!" } } }

لطفاً جهت ارسال آگهی‌های خود در حوزه‌ی درخواستی خود برای برنامه‌نویس و تشکیل تیم توسعه خود قوانین زیر را در نظر داشته باشید. در غیر این صورت آگهی شما تایید نخواهد شد. آگهی نباید شامل تصویر باشد. سعی کنید نیاز خود را برای درخواست با جزئیات کامل ارسال کنید. آدرس و مزایای استخدامی خود را مشخص نمایید. در صورتی که نیاز است لینکی را ارسال کنید سعی کنید آن لینک آدرس سایت شرکت خودتان باشد. این بخش به صورت رایگان در نظر گرفته شده است، و مرجع هیچ مسئولیتی در قبال نتایج استخدامی شما نخواهد داشت. قوانین نگارشی و شرایط ارسال محتوا برای ارسال آگهی‌های خود از این بخش اقدام کنید.

شرایط و مجوز‌های تحت کیوت نوع مجوز و ویژگی‌ها LGPLV3 GPLV2/GPLV3 مجوز تجاری هزینه رایگان رایگان شروع هزینه از ۴۵۹ دلار در هر ماه حقوق و خدمات پشتیبانی جامعه پشتیبانی رسمی از طرف شرکت کیوت شما می‌توانید نرم‌افزارتان را به صورت خصوصی نزد خود نگه‌دارید. در صورتی که اپلیکیشن خود را به صورت لینک-پویا (Dynamic-link) کامپایل کرده باشید، می‌توانید آن را خصوصی برای خود حفظ کنید. بدون ارائه مکانیزم خاصی برای کتابخانه‌های کیوت (می‌توانید همیشه از کامپایل استاتیک) بهره‌مند شوید. نیازی برای ارائه کپی از مجوز و صراحت از استفاده کیوت نمی‌باشد. نیازی برای ارائه یک کپی (نسخه) از سورس کُد کیوت برای مشتری را ندارید. حقوق کامل برای تغییرات در کد منبع کیوت و سفارشی آن اجبار و تاکید بر (مدیریت حقوق دیجیتال) مشاهده‌ جزئیات در مجوز LGPv3 مشاهده‌ جزئیات در مجوز LGPv3 اجبار و تاکید بر (پیاده سازی پروتکل های نرم افزاری) مشاهده‌ جزئیات در مجوز LGPv3 مشاهده‌ جزئیات در مجوز LGPv3 می‌توانید دستگاه‌های مصرف کننده‌ی بسته شده ایجاد کنید ماژول‌ها ماژول Qt Essentials افزونه‌های عمومی کیوت ماژول Qt Charts ماژول Qt Data Visualization ابزار‌ها محیط توسعه یکپارچه‌ی نرم‌افزاری Qt با تمامی قابلیت‌ها ابزار‌های مستند‌ سازی ابزار داخلی سازی (درونی ساز) ابزار طراحی Qt Quick Designer ابزار Qt Quick Profiler ابزار توسعه و پیشرفت در Visual Studio ابزار Qt Quick 2D Renderer، استفاده بدون OpenGL ابزار کامپل Qt Quick Compiler ابزار‌ها و راه حل‌های کیوت برای ساخت دستگاه‌های اِمبِد ابزار Qt Virtual Keyboard خطایابی (دیباگینگ مستقیم) بر روی دستگاه ابزار Boot to Qt نصب و استقرار با یک کلیک در دستگاه و پلتفرم هدف دستورالعمل‌های پروژه Yocto برای سفارشی سازی ایمیج‌های از پیش ساخته شده توجه داشته باشید که معمولاً شرکت کیوت بعضی از ویژگی‌های موجود را که مختصِ نسخه‌ی تجاری است بعضاً در نسخه‌های جدید تحت مجوز‌های LGPv3 منتشر می‌کند. در این اواخر نمونه‌ای از آن‌ها Qt Quick Compiler بود که در نسخه‌ی ۵.۱۱.۰ منتشر شد.