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

آزمایشی نیست، نهایی شده هست. اما خب فعلاً جای کار داره و باید از سمت مرورگر‌ها و سرور‌ها به خوبی بهینه‌سازی بشه. در کل این ویژگی در کنار دیگر ویژگی‌های کیوت یکی از بهترین موارد است.

فعلاً به بلوغ نرسیده، باید در سمت مرورگر‌ها و سرور بهینه‌سازی بشه.

همانطور که می‌دانید اخیرأ فناوری وب‌اسمبلی (Qt for WebAssembly) معرفی شده است، توسعه‌دهندگان کیوت یک نمایشگر برای اجرای خروجی‌های QML در مرورگر طراحی کرده‌اند که به شما این امکان را می‌دهد تا کد‌های نوشته شده‌ی خود را در محیط مرورگر اجرا کنید. در این بخش می‌توانید آخرین نسخه‌ی مرتبط با Qt Design Viewer را برای آزمایش پیدا کنید، نمایشگر Qt Design Viewer با چند طرح آماده برای آزمایش همراه است. برای اجرای یک برنامه‌ی سفارشی تحت QML، باید یک پرونده‌ی qmlproject. که پرونده‌ی اصلی QML است را تعریف کنید. این همان قالب اساسی پروژه است که توسط Qt Design Studio و Qt Creator برای پروژه‌های QML استفاده می‌شود. پوشه‌ی پروژه باید به صورت یک فایل Zip فشرده شود و سپس در Qt Design Viewer بارگذاری گردد. همچنین می‌توانید از نسخه‌ی Qt Design Studio 1.3 یک فایل منبع را از پروژه ایجاد کرده و بسته‌ای را که به صورت خودکار ایجاد شده است را بارگذاری کنید. آزمایش‌های مربوطه بر روی مرورگر‌های Safari، Chrome، FireFox و Edge انجام شده است و عملکرد اجرای QML در تمامی آن‌ها بسیار خوب است. البته زمان تدوین و پیکربندی به مرورگر شما بستگی دارد، اما عملکرد واقعی برنامه پس از اجرا همانند نسخه‌ی دسکتاپ است. سیستم Qt Design Viewer همراه با اکثر ماژول‌های QML به عنوان بخشی از کیوت است که در نسخه‌ی ۵.۱۴ ساخته شده است. همچنین، این محیط بر روی سیستم‌عامل‌های iOS و Android اجرا می‌شود که یک روش ساده را برای اجرای طرح‌های آزمایشی ارائه می‌کند. این فناوری جدید است، بنابراین در صورت مشاهده‌ی مشکلات آن را به تیم توسعه‌دهنده‌ی آن گزارش دهید.

مثالت انقدر خوب بود که گفتم متنی هم تشکر کنم ازت ?

خوشم میاد سوألت بسیار بسیار تازست! یعنی کیوت این فناوری رو چند روزی نیست معرفی کرده! ? همچین کاربرای فعالی داریم ما... احسنت ? به هر حال، من سعی کردم چند بار این ویژگی رو بخونم و اگر درست متوجه شده باشم، با توجه به درکی که از مستندات خودش داشتم باید همچین تعریفی داشته باشه که در ادامه باز‌نویسی کردم. در صنایع مختلفِ پزشکی و اتوماسیون‌های پیشرفته و یا خودرو‌سازی نمایش اطلاعاتِ ایمن، مرتبط با اطلاعات مربوط به خطا‌ها و گزارشات بحرانی که بسیار هم مهم و حساس هستند که متخصص‌ها باید به این اطلاعات در زمان خودش همراه با اطلاعات صحیح و ایمنی از طریق صفحه‌ نمایشگر‌های دیجیتالی در اختیار داشته باشند مهم است. برای مثال در صنعت پزشکی، پرستاران، پزشکان و تکنسین‌ها از وسایل پزشکی بسیار مهمی استفاده می‌کنند که باید این تجهیزات به حداکثر ایمنی در زمان ارائه‌ی گزارش‌ها در جای مناسب خودشون تضمین شوند. با توجه به مشکلات احتمالی که در زمان ارائه‌ی این گزارشات در زمان رندر سازی سمت UI (که بسیار حساس هستند و نباید تأخیر و یا اختلالی در ارائه‌ی این‌ موارد به وجود بیاد) کیوت سعی کرده راهکاری را ارائه بدهد تا این مشکلات احتمالی را تضمین و ایمن سازد. بنابراین، ماژول Qt Safe Renderer هم یک راهکار از طرف شرکت کیوت است برای ارائه‌ی اطلاعات حساس و ایمن در برنامه‌های کاربردی ایمنی که عملکرد آن‌ها بر اساس کیوت است. این ماژول یک محصول تجاری است که باید جداگانه خریداری شود، زیرا بخشی از مجوز‌های توسعه‌ی برنامه‌ یا دستگاه مربوط به این ویژگی بخشی از برنامه‌های کیوت محسوب نمی‌شوند. این راهکار برای این ارائه شده تا، یک سیستم جداگانه برای ادغام و یکپارچه‌سازی یک سیستم با پردازش‌های جداگانه جهت عملکرد‌های مهم ایمنی و غیر ایمنی باشد. با توجه به ساختاری که دارد، پردازش‌های مورد نیاز را به یک زیر سیستم مستقل در فرآیند اختصاصی اجرا می‌کند، مانند ظبط گرافیکی از اطلاعات مهم و ایمنی که این موارد را تضمین خواهد کرد. در واقع این راه‌کار، وظیفه‌ی مانیتورینگ اصلی عملکرد رابط‌کاربری اصلی و خطاهای موجود در آن را بر عهده می‌گیرد تا اختلالی در زمان ارائه‌ی اطلاعات مهم و حساس رُخ ندهد.

زبانی را انتخاب کنید که پاسخگوی برنامهٔ تحت بلاک‌چین شما باشد! فناوری بلاک‌چین به سرعت در حال تبدیل شدن به یکی از مهمترین پیشرفت‌های فناوری در چند دههٔ گذشته است. این سیستم، معاملات ناشناس و همتا را بین کاربران امکان‌پذیر می‌کند که اساساً بر پایهٔ انقلاب رمزنگاری است. بازار جهانی بلاک‌چین در حال حاضر حدود ۱.۲ میلیارد دلار تخمین زده می‌شود و کارشناسان پیش‌بینی می‌کنند که تا سال ۲۰۲۵ به ارزش ۵۷ میلیارد دلار برسد که در سال بیش از ۶۹ درصد رشد خواهد داشت. عمدهٔ شرکت‌ها و سرمایه‌دارانِ سرمایه‌گذار در توسعهٔ فناوری جدید رمزنگاری، قرارداد‌های هوشمند دفترچه‌های توزیع‌شده برای بانک‌های سنتی، توکن‌های بازی و سیستم‌های مدیریت زنجیره تأمین با شرکت‌های مشاوره بلاک‌چین همکاری می‌کنند. توسعه‌دهندگان در حال حاضر از زبان‌های برنامه‌نویسی محبوبی مانند C++ و JavaScript برای ساختن برنامه‌های سفارشی بلاک‌چین استفاده می‌کنند. علاوه بر این، مهندسان رمزنگاری زبان‌هایی مانند Simplicty و Solidity را برای این کار طراحی کرده‌اند. اما، آن‌ها آیا این‌ها بهترین زبان‌های برنامه‌نویسی برای فناوری بلاک‌چین هستند؟ بلاک‌چین چیست؟ بانکداری سنتی از یک بانک به عنوان رهبر و واسط استفاده می‌کند. جهت انتقال پول به یک دوست، یک شخص ابتدا حسابی داشته باشد و بخواهد که پول را به یک شماره حساب خاص که برای اوست انتقال دهد. بانک، حساب ارسال کننده را برای وجه بررسی می‌کند و آن وجه را به مقصد منتقل می‌کند و معامله در حساب فرستنده ثبت می‌شد. همچنین بانک دریافت کننده نیز همین کار را باید انجام دهد. با این حال، مشکل سیستم بانکی سنتی این است که سوابق در داخل ذخیره می‌شوند و در برابر هک و دستکاری‌های آسیب‌پذیر هستند. بلاک‌چین با ذخیره کردن تمامی سوابق به صورت آنلاین در یک دفترچهٔ مستعار (بی‌نام) ذخیره می‌کند که توسط هر کسی قابل دسترس است. بلاک‌چین از بلاک‌ها استفاده می‌کند، یا مجموعه‌ای از داده‌ها، مشابه سطر‌ها و ستون‌های صفحه‌های گسترده جهت ذخیره داده‌ها استفاده می‌کند. بلاک‌ها به ترتیب متوالی به «زنجیر» اضافه می‌شوند. برخلاف دفترچه‌های سنتی، که در داخل ذخیره می‌شوند، هر کاربرِ بلاک‌چین دارای سوابق کاملی از کل بلاک‌چین در رایانهٔ خود است. این بدان معنی است که در صورت داشتن کد هش (رمز‌شدهٔ) مربوطه می‌توانند به سرعت هر معامله‌ای را که اتفاق افتاده است را پیدا کنند. از آن‌جایی که این داده‌ها به صورت عمومی ذخیره می‌شوند، هرگز قابل تغییر یا حذف نیستند! در نتیجه آرامش خاطر را به کاربران فراهم می‌کند. زبان برنامه‌نویسی JavaScript (جاوااسکریپت) از آن‌جایی که گیت‌هاب به تازگی این زبان را به عنوان محبوب‌ترین زبان برای توسعه‌دهندگان اعلام کرده است، به طور باورنکردنی بیش از ۹۵٪ وب‌سایت‌ها به طریقی از آن‌ استفاده می‌کنند. با این حال، جاوااسکریپت تنها پادشاه وب نیست؛ چرا که به عنوان یک زبان انعطاف‌پذیر در بلاک‌چین استفاده می‌شود. یکی از دلایلی که جاوااسکریپت را برای توسعه‌دهندگان می‌بخشد نحوهٔ دستیابی به مدیریت کد‌ها به صورت ناهمزمان (ناهمگام) است. این امر در بلاک‌چین بسیار مهم است، زیرا ممکن است هزاران یا حتی میلیون‌ها معاملات در همان زمان آغاز شود! برنامه‌نویسی موازی یک برنامه را قادر می‌سازد تا چندین عمل را به صورت همزمان انجام دهد در حالی که برنامه‌نویسی استاندارد و همزمان نمی‌توانند آن حجم را تحمل و کنترل کنند. با اجرای چندین کار به صورت همزمان، کد ناهمزمان می‌تواند باعث افزایش پاسخگویی و عملکرد برنامه شود. این امر باعث می‌شود برنامه‌های بلاک‌چین بتوانند حجم بسیار زیادی از اقدامات را بدون عملکرد کُند و نا امید سازی کاربر، آن را انجام دهند. زبان برنامه‌نویسی C++ (سی‌پلاس‌پلاس) سی‌پلاس‌پلاس همچنین به عنوان یکی از قدرتمند‌ترین و محبوب‌ترین زبان‌های برنامه‌نویسی در دنیای فناوری شناخته می‌شود و در صنعت بلاک‌چین نیز یک قدرت غالب است. زبان شیء‌گرایی برای توسعه بلاک‌چین مناسب است، زیرا از همان اصول کپسوله‌سازی، انتزاع، چند‌ریختی و مخفی کردن داده‌ها استفاده می‌کند. به عنوان مثال بلاک‌چین از ویرایش‌های ناخواسته از داده‌ها جولوگیری می‌کند. توسعه‌دهندگان همچنین به دلیل قابلیت کنترل حافظه، از C++استفاده می‌کنند. این زبان به شما اجازه می‌دهد تا بلوک‌های ایمن را نگه‌ داشته و تعداد زیادی از درخواست منابع را مدیریت کنید. با اجازه دادن به هر نود (گره) شبکه می‌توانید بلوک‌های فردی را پذیرفته یا رد کنید. همچنین C++ به دلیل پشتیبانی و مدیریت وظایف موازی و نخی به طور گسترده در بلاک‌چین مورد استفاده قرار می‌گیرد. این زبان قادر به مدیریت هردو ویژگی موازی و غیرموازی در وظایف است، در واقع می‌تواند به خوبی انجام وظایف تک-نخی/تک رشته‌ای (single-thread) را بهبود دهد. نمونهٔ فوق‌العاده‌ای از برنامه‌های اساسی از بلاک‌چین که با C++ نوشته شده است EOS نام دارد. این نرم‌افزار به صورت منبع‌باز در سال ۲۰۱۸ توسط بلاک منتشر شد و به گونه‌ای طراحی شده است که معاملات را سریع‌تر از گزینه‌های دیگر پردازش می‌کند. این نرم‌افزار اجازه می‌دهد تا در کمتر از یک ثانیه معامل را تأیید کرده و فقط در دو دقیقه آن را نهایی کنید. زبان برنامه‌نویسی Solidity این زبان یک نمونهٔ هوشمند است که با همکاری توسعه‌دهندگان Ethereum و بلاک‌چین توسعه یافته است. این زبان به صورت اختصاصی دامنه‌های بسیاری از اصول و اصطلاحات مشابه به جاوا‌اسکریپت را برای ایجاد برنامه‌های با کیفیت بالا و غیر متمرکز فراهم می‌کند. توسعه‌دهندگان، این زبان را برای این ترجیح می‌دهد که به شما این امکان را فراهم می‌کند تا یک کد سطح بالا را برای شبکهٔ بلاک‌چینی Ethereum، دومین بلاک‌چین رمزنگاری محبوب، که می‌تواند به زبان سطح پایین و کد ماشین کامپایل شود. در حال حاضر Solidity در طیف گسترده‌ای از سکو‌ها (پلتفرم‌های) بلاک‌چینی از جمله، Ethereum، Tendermint، Ethereum Classic و Counterparty موجود است. زبان برنامه‌نویسی Simplicity این یک زبان کاملاً جدید است که در تاریخ نوامبر ۲۰۱۷ برای قرارداد‌های خاص و هوشمندِ بلاک‌چین طراحی و منتشر شده است. این زبان برای افزایش بهره‌وری و پنهان‌سازی اجزای منطقی سطح پایین از مهندسان است که یکی از دلایلی است که به سرعت در جامعه محبوب می‌شود. مانند C++، این یک زبان شیء‌گرایی است که برای جولوگیری از خطاها و تغییر داده‌ها در بلاک‌چین استفاده می‌کند. خلاصه بلاک‌چین اینجاست تا بماند! فناوری محبوب (Record-Keeping) چیزی است که تبادلات رمزنگاری را ممکن می‌سازد و بطور گسترده توسط شرکت‌ها، افراد و خدمات مشاوره‌ای بلاک‌چین، برای توسعهٔ نرم‌افزار مورد استفاده قرار می‌گیرد. توسعه دهندگان می‌توانند به راحتی از زبان‌های محبوب مانند C++ و JavaScript برای توسعهٔ بلاک‌چین استفاده کنند. از طرفی این انجمن اخیراً زبان‌هایی به عنوان Solidity و Simplicity را ایجاد کرده است که باعث می‌شود تا فرآیند توسعهٔ رمزنگاری روان‌تر شود.

همینطوره خب، منم اشاره کردم مثالش رو که تحت Get باید پارامتر‌ها رو در Url بیاری. توی اندروید و مثالی که زدی تابع getParams اضافه هست و صرفاً در روش Post به درد می‌خوره. با توجه به مثال خودت همچین کاری کافی هست : String Url="http://192.168.43.3/shop/register.php?username=name&email=mymail";

چرا گیر دادی به متد Get؟ در این متد زمانی می‌تونید پارامتری رو ارسال کنید که در قالب url باشه. برای مثال به این شکل: http://www.domain.com/request.php?username=myname&email=myemail در این صورت دیگه نمی‌تونید کوئری‌های سفارشیِ خارج از url ارسال کنید.

سلام، متد Get معمولاً روشی برای درخواست اطلاعات هست نه ارسال! هرچند برای ارسال هم استفاده می‌شه اما اگر شما می‌خواهید اطلاعاتی مثل همین کدی که می‌بینم رو در قالب کوئری نه url ارسال کنید بهتره متد رو به Post تغییر بدین. خیلی ساده بخوام توضیح بدم هرجا که قرار بود مقادیری رو به عنوان کوئری به سمت سرور ارسال کنید حتماً از Post استفاده کنید. در این صورت لازم نیست پارامتر‌ها رو در قالب url ارسال کنید. مثالی هم که زدین متد Post هست، اگر دقت کنید نوع params داره چند تا نوع با مقدار رو ارسال می‌کنه. سمت سرور هم مثلاً با Php با در نظر گرفتن نوع درخواست از Post به این شکل می‌تونید مقدار رو بگیرید. $email = $_POST["email"]; $username = $_POST["username"]; $password = $_POST["password"]; $mobile = $_POST["mobile"]; echo $email; ... ..... ......

سلام، این روش‌ها که بهشون اشاره کردین به عنوان متد (method) انتقال اطلاعات بین سرور و کلاینت هستند. برای دریافت و یا اعمالِ یک درخواست برای انجام کار مانند انتقال، به‌روز‌رسانی، دریافت، حذف و غیره از متد‌هایی مثل GET, POST, DELETE, PUT, PATCH استفاده می‌شود که متد‌های Get و Post دو نمونه‌ی مهم و پرکاربردی از این روش‌ها محسوب می‌شوند. در اندروید شما برای اینکه بخواهید اطلاعاتی را از سرور خود دریافت و یا انتقال دهید، اگر اون پروتکل تحت http یا https باشه می‌توانید تحت این متد‌ها تراکنش را انجام دهید. بنابراین هیچ فرقی بین متد‌های GET و POST در اندروید و HTML وجود نداره چون این‌ها یک سری متد‌های استانداردِ از قبل تعریف شده برای پروتکل‌ HTTP بشمار می‌آیند.

معمولاً در سی‌پلاس‌پلاس برای چاپ اطلاعات مربوط به کد منبع از ماکرو‌ها استفاده می‌شود. ماکروها به عنوان یکی از ویژگی‌های بسیار قدرتمند زبان C محسوب می‌شوند که در C++ نیز از آن‌ها پشتیبانی می‌شود. برای مثال ماکرو‌های __LINE__ و __FILE__ اطلاعات مربوط به شماره خط، فایل و نام آن را بر می‌گردانند. در استاندارد جدید یعنی 2a یا همان نسخهٔ ۲۰ زبان، کلاس source_location معرفی شده است که در فایل سرآیند <source_location> تعبیه شده است. با دسترسی به فیلد‌های line، column، filename و function_name می‌توان تحت این کلاس مشخصات مورد نیاز را از کد منبع چاپ کرد. مثال : #include <iostream> #include <string_view> #include <source_location> void log(std::string_view message, const std::source_location& location = std::source_location::current()) { std::cout << "info:" << location.file_name() << ":" << location.line() << " " << message << '\n'; } int main() { log("Hello world!"); } خروجی کد مربوطه به صورت زیر است. info:main.cpp:15 Hello world! منبع در مرجع سی‌پلاس‌پلاس

سلام، معمولاً یکی از بزرگترین مشکلات استارتاپ‌ها همین سهام‌بندی و عدم رضایت بین اعضای گروه هست. بنابراین من یک توضیح خلاصه و مقدماتی میدم شاید کمک کند. برای اینکه این مشکل حل بشه باید توجه کرد بنیان‌گذاران باید مسئولیت مشخصی داشته باشند. میزان تاثیر و اهمیت تخصص و وجود یک فرد در گروه جهت به بلوغ رساندن پروژه بسیار مهم است. اینکه چه کسی ارزش بیشتری خلق می‌کند مهم است. البته نوع استارتاپ هم بسیار موثر است، برای مثال استارتاپی که اساس آن نرم‌افزار است مسلماً تخصص یک مهندس نرم‌افزار بسیار اهمیت دارد. در نهایت موارد زیر برای هر یک می‌تواند مورد توجه قرار گیرد: میزان نقش آفرینی قدرت رسانه‌ای قدرت تخصصی و توسعه تجربه و نفوز میزان مسئولیت پذیری نوع فعالیت تجربه‌ی قبلی از استارتاپ‌ها اعتبار ارائه شده مالی و یا تخصصی دانش و میزان تحصیلات و ... میزان درصد هم بهتر است بر اساس توافق بر اساس سود به دست آمده نیز باید با توجه به میزان ارزش‌گذاری هر یک از افراد صورت بگیرد. برای مثال با توجه به تعریف شما، تاثیرِ توسعه‌دهندگان فرانت‌اند و بک‌اند (به خصوص بک‌اند) در به وجود آمدن یک نرم‌افزار بیشتر از گرافیست و برنامه‌ریز است. بنابراین ترتیب تاثیر و ارزش‌گذاری لیست شما با توجه به نوع محصول شما درست است. چرا که ابتدا باید محصول به لطف و دانش برنامه‌نویس توسعه و سپس طراحی رابط‌کاربری ایجاد شود تا در نهایت به مراحل گرافیکی (تجربه‌کاربری، بصری، رابط‌کاربری نهایی) و سپس به مرحله‌ی معرفی و تبلیغات برسد.

لینکی که دادم پاسخ مرتبط با همون سوأل بود. این مقالات رو مطالعه کنید:

کامپوننت یا جزء (بخشی) از یک نرم‌افزار یا پروژه هستند. پروژه‌ی شما می‌تونه از بخش‌ها و اجزای اصلی و فرعی بسیاری تشکیل شود که هر کدام وظیفه‌ی خود را خواهند داشت. برای مثال در یک پروژه تحت سی‌پلاس‌پلاس یک کنترل به عنوان یک جزء یا همان کامپوننت تعریف می‌شود. در رابطه با SDK مخفف (Software Development Kit) به معنای کیت توسعه‌ی نرم‌افزار است. کیت توسعه‌ی نرم‌افزار به مجموعه توابع و کتابخانه‌های کامپایل شده‌ای که تولیدکنندگان نرم‌افزار برای آسان کردن برنامه‌نویسی برای محیط یا سکوی خاصی فراهم می‌کنند و در اختیار برنامه‌نویسان کاربردی قرار می‌دهند گفته می‌شود. به عنوان مثال جهت توسعه‌ی محصولات ویندوز و دسترسی به سرویس‌های آن شما باید از کیت ویندوز استفاده کنید. تفاوت بین چهارچوب (فریم‌ورک) و کیت این است گه کیت برای توسعه‌ی یک پلتفرم خاص کمک می‌کند تا شما محصول خود را برای آن هدف توسعه دهید. اما کتابخانه یا فریم‌ورک با اینکه مشابه کیت هستند اما آن‌ها شامل کلاس‌ها، توابع و راهکار‌های بسیار مفیدی برای تکمیل یا حل نیاز‌های جانبی به کار می‌رود. معمولاً توسعه‌ی نرم‌افزار‌ها می‌تواند بر اساس کتابخانه و فریمورک‌هایی انجام شود. برای مثال OpenSSL یک کتابخانه‌ی رمزنگاری است. یا Qt به عنوان یک کتابخانه و فریمورک گرافیکی جهت تولید و توسعه‌ی رابط‌های کاربری مورد استفاده قرار می‌گیرد. نه تنها در سی++ بلکه در زبان‌های دیگر هم این موارد کاربرد دارند.

سلام و درود بر اعضای محترم، نسخه‌ی جدید ۰.۶.۷۸۳ با به‌روز رسانی‌ها، بهود‌ها و ویژگی‌های پایه برای ویندوز ۳۲ و ۶۴ بیتی منتشر شد. برای دریافت و مشاهده‌ی جزئیات کلیک کنید. مشکلات و مواردی که حل شده‌اند به صورت زیر است: بهبود‌ها حل شدن مشکل کرش و هنگ کردن نرم‌افزار در سیستم‌هایی که فاقد کارت گرافیکی یا درایور‌های نصب شده هستند (مشکل گزارش شده در نسخهٔ Fanoox Standard) حل شدن مشکل کرش برنامه بعد از بازدید‌های پشت سر هم از پکیج‌های آموزشی به صورت تصادفی ادغام نسخه‌های Software و OpenGLEs بر روی نسخهٔ استاندارد بر پایهٔ سِل حل شدن مشکل پذیرش شماره تلفن معتبر حل شدن مشکل ارتفاع کم در بخش اسکرول دربارهٔ ما و گزینه‌های سوألات متداول حل شدن عدم سوئیچ به صورت خودکار در بخش تأیید شماره وارد شده حل شدن نمایش نوتیفیکیشن بعد از هر بار به‌روز‌رسانی پروفایل حل شدن عدم بازیابی و تغییر رمزعبور حل شدن عدم اعمال محدودیت در اسلایدر امتیاز حل شدن عدم بررسی آدرس پست الکترونیکی و شمارهٔ موبایل در بخش پروفایل و زمان ثبت‌نام حل شدن ارسال مقدار شمارهٔ موبایل نامعتبر حل شدن عدم هماهنگی استایل دکمه‌های خروج پروفایل حل شدن عدم پذیرش کلید Enter در تأیید ایمیل و شمارهٔ همراه حل شدن عدم هماهنگی چیدمان در متن‌های سوألات متداول حل شدن ارسال مقادیر عدد در عنوان‌ نظرات حل شدن عدم غیرفعال شدن دکمهٔ ارسال نظر بعد از ارسال و تأیید  ویژگی‌های جدید بازنویسی و جایگزینی کلاس شبکهٔ پیشفرض جایگزینی و حذف ماژول Qt Multimedia با FFmpeg - این تغییرات در نتیجه منجر به پشتیبانی از دِکدر سخت‌افزاری برای DXVA2, VAAPI, VDA, CedarX, CUDA می‌باشد. بنابراین نیازی نیست افزونه‌ای مانند K-Lite Codec به عنوان دکدر ویدیو‌ها بر روی سیستم شما نصب باشد - پشتیبانی از فرمت‌های Hi10P اعمال شد - افزوده شدن ویژگی Real time preview در هستهٔ پلیر (در نسخه‌های بعدی فعال خواهد بود) - ویژگی فیلتر‌ برای OSD - امکان فیلتر سازی بر اساس libavfilter و مانند stero3d و blur - امکان پشتیبانی از ویژگی زیر‌نویس در قالب srt و ass بر اساس موتور libass - نمایش و رندر ویدیو به صورت فریم به فریم یا FBF - استریم بر پایه منابع فایل محلی، rtsp، https و ... و حتی پشتیبانی از استریمر سفارشی - پشتیبانی از چند خروجی برای هر کاربر - پشتیبانی و اعمال وضعیت بر اساس OpenGL و Software برای اعمال brightness, contrast, saturation, hue - پشتیبانی از پروتکل‌ mbedTLS با پشتیبانی TLS - پشتیبانی از فیلترینگ بیت‌استریم برای ویرایش فراداده‌ها در جریان‌های H.264, HEVC و MPEG-2 افزوده شدن سیستم به‌روزرسانی هوشمند جهت تشخیص نوع پلتفرم برای نسخهٔ سازگار جایگزینی تمامی ویژگی‌های پیشفرض پخش کننده با انجین جدید افزوده شدن پوسته‌های تاریک و روشن افزوده شدن نوار جستجوی اصلی افزوده شدن فیلتر‌های مرتب سازی در جستجو افزوده شدن نوار پنجرهٔ اختصاصی افزوده شدن امکان ساخت رمزعبور اختصاصی در بخش فراموشی رمز اافزوده شدن امکان ارسال رمزعبور جدید به شماره تلفن همراه جهت تأیید افزوده شدن ویژگی تمام صفحه و تنظیم حداکثری اندازه افزوده شدن امکان افزودن تصویر نمایه افزوده شدن نوار پنجرهٔ اختصاصی افزوده شدن دکمهٔ پسندیدن و دیگر تغییرات جزئی ?

این کنترل استانداردش همین هست، در واقع مشکل وجود نداره. دلیلش هم اینه که اشیاء رو باید در عرض و طول مشخصی از لیست قرار بدین. برای مثال مشخصه‌ی width بهتره برابر با مشخصه‌ی width والدش باشه.

به این روش عمل کنید: TextInput{ id: textInput width: 100 height: 30 text: "Hello, World!" selectByMouse: true MouseArea{ id: mouseArea enabled: textInput.focus ? false : true anchors.fill: parent cursorShape: Qt.IBeamCursor onClicked: textInput.forceActiveFocus() } }

درود، مثال درسته، اما مرتبط با نسخه‌ی ۲.۰ از Qt Controls نیست، مرتبط به نسخه قدیمی ۱.۰ هستش که به صورت زیر بهش دسترسی خواهید داشت. در نسخه‌های جدید روش توسعه پوسته متفاوت و البته بسیار راحت‌تر هست که در ادامه مثال زدم. import QtQuick.Controls.Styles 1.4 البته توصیه می‌کنم از نسخه جدید استفاده کنید. مثال : import QtQuick 2.12 import QtQuick.Controls 2.12 RadioButton { id: control text: qsTr("RadioButton") checked: true indicator: Rectangle { implicitWidth: 26 implicitHeight: 26 x: control.leftPadding y: parent.height / 2 - height / 2 radius: 13 border.color: control.down ? "#17a81a" : "#21be2b" Rectangle { width: 14 height: 14 x: 6 y: 6 radius: 7 color: control.down ? "#17a81a" : "#21be2b" visible: control.checked } } contentItem: Text { text: control.text font: control.font opacity: enabled ? 1.0 : 0.3 color: control.down ? "#17a81a" : "#21be2b" verticalAlignment: Text.AlignVCenter leftPadding: control.indicator.width + control.spacing } } این هم مستند نحوه‌ی گسترش پوسته در کیوت کوئیک کنترل ۲.۰

با سلام و درود، روشی که به کار گرفته‌اید صحیح است اما حرفه‌ای و پویا نیست. پیشنهاد من ایجاد یک کلاس در سمت بک‌اِند تحت C++ مشتق شده از QObject است. برای مثال کلاس زیر را در نظر بگیرید. #pragma once #ifndef STYLE_HPP #define STYLE_HPP #include <QObject> #include <QColor> class Style : public QObject { Q_OBJECT Q_PROPERTY(QColor primary READ primary WRITE setPrimary NOTIFY primaryChanged) Q_PROPERTY(QColor secondary READ secondary WRITE setSecondary NOTIFY secondaryChanged) Q_PROPERTY(int h1 READ h1 WRITE setH1 NOTIFY h1Changed) public: Style(); ~Style(); QColor primary () const; QColor secondary () const; int h1 () const; public slots: void setPrimary (const QColor &color); void setSecondary (const QColor &color); void setH1 (const int &size); signals: void primaryChanged (); void secondaryChanged(); void h1Changed(); private: QColor m_primary; QColor m_secondary; int m_h1; }; #endif // STYLE_H #include "style.hpp" Style::Style() { this->m_primary = "gray"; this->m_secondary = "black"; this->m_h1 = 12; } Style::~Style() { } void Style::setPrimary(const QColor &color) { if (color != m_primary) { m_primary = color; emit primaryChanged(); } } QColor Style::primary() const { return m_primary; } void Style::setSecondary(const QColor &color) { if (color != m_secondary) { m_secondary = color; emit secondaryChanged(); } } QColor Style::secondary() const { return m_secondary; } void Style::setH1(const int &size) { if (size != m_h1) { m_h1 = size; emit h1Changed(); } } int Style::h1() const { return m_h1; } تابع Main #include <QGuiApplication> #include <QQmlApplicationEngine> #include <QQmlEngine> #include <QQmlContext> #include "style.hpp" int main(int argc, char *argv[]) { QCoreApplication::setAttribute(Qt::AA_EnableHighDpiScaling); QGuiApplication app(argc, argv); QQmlApplicationEngine engine; QQmlContext *context = engine.rootContext(); Style style; const QUrl url(QStringLiteral("qrc:/main.qml")); context->setContextProperty("Style", &style); QObject::connect(&engine, &QQmlApplicationEngine::objectCreated, &app, [url](QObject *obj, const QUrl &objUrl) { if (!obj && url == objUrl) QCoreApplication::exit(-1); }, Qt::QueuedConnection); engine.load(url); return app.exec(); } و در بخش QML به این صورت: import QtQuick 2.12 import QtQuick.Window 2.12 import QtQuick.Layouts 1.12 import QtQuick.Controls 2.12 Window { visible: true width: 640 height: 480 title: qsTr("Hello World") Rectangle { anchors.fill: parent color: Style.primary ColumnLayout { anchors.centerIn: parent Text { text: qsTr("Hello, World!") color: Style.secondary font.pixelSize: Style.h1 } Slider { from: 12 to: 64 snapMode: Slider.SnapAlways stepSize: 0.5 onValueChanged: { Style.setH1(value) } } Switch { onCheckedChanged: { if(checked) { Style.setPrimary("green") Style.setSecondary("orange") } else { Style.setPrimary("gray") Style.setSecondary("black") } } } } } } مثالی که زدم صرفاً یک روش مفهومی (Concept) است و شما می‌تونید تغییر و توسعش بدین.

این چشم‌انداز احتمالاً برای دوست‌‌داران کتابخانهٔ قدرتمند Qt و طرفدارانش جذاب باشد! بنابراین من سعی کرده‌ام تا نتایج پست رسمی کیوت را در رابطه با چشم‌انداز فنی برای آیندهٔ کیوت نسخهٔ ۶ است در اختیار شما قرار دهم. تقریباً ۷ سال پیش کیوت نسخهٔ ۵.۰ منتشر شد! از آن زمان بسیاری از چیز‌ها در دنیای اطراف ما تغییر پیدا کرده است. و اکنون وقت آن رسیده است که چشم‌انداز جدیدی را از نسخهٔ جدید‌تر تعریف کنیم. بنابراین در این پست ما به معرفی مهمترین مواردی که به کیوت ۶ مرتبط است را می‌پردازیم. به نقل از مدیر فنی کیوت Lars Knoll، کیوت ۶ دقیقاً ادامهٔ کارهایی است که در نسخهٔ ۵ انجام داده شده است. بنابراین توسعه باید به گونه‌ای باشد که کاربران نباید اذیت شوند. اما نسخهٔ جدید می‌تواند یک آزادی بالاتر را در اجرای ویژگی‌های جدید، عملکرد و پشتیبانی بهتر از شرایط امروز و فردا از آنچه در حال حاضر می‌توان در سری ۵ داشته باشیم را به ما خواهد داد. همانطور که جزئیات بیشتر در زیر شرح داده شده است، کیوت ۶ هدف زیادی از سازگاری با نسخهٔ قبلی خود یعنی کیوت ۵ را خواهد داشت. همچنین ما در حال توسعه روی نسخهٔ ۵ نیز هستیم که قصد داریم برخی از ویژگی‌های کیوت ۶ را در نسخه‌های کیوت ۵.۱۴ و کیوت ۵.۱۵ LTS معرفی کنیم. بنابراین با ثابت نگه‌داشتن ویژگی‌ها در کیوت ۵.۱۴، بیشترِ تمرکزِ تحقیق و توسعه به سمت کیوت ۶ تغییر خواهد یافت. بنابراین انتظار می‌رود کیوت ۶ تا پایان سال ۲۰۲۰ آماده شود. قبل از اینکه همه به چیز‌های جدید بپردازیم، بیایید برخی از ارزش‌های پایه از هستهٔ اصلی کیوت را برای کاربران خود یادآوری کنیم تا چیز‌هایی که نمی‌خواهیم تغییر کنند را تعریف کنیم. چه چیزی Qt را برای کاربران ما ارزشمند می‌کند؟ کیوت محصولی است که در بازار‌های مختلفی مورد استفاده قرار می‌گیرد، ارزش‌های اصلی در هستهٔ کیوت برای مشتریان و کاربران ما عبارتند از: ماهیت چند-سکویی آن، به کاربران این امکان را می‌دهد تا برنامه‌های خود را با استفاده از این فناوری به تمامی سیستم‌عامل‌های رو میزی، موبایل و سیستم‌های تعبیه شده (اِمبِد‌ها) مستقر کنند. مقایس پذیری آن از دستگاه‌های کم مصرف و یک منظوره تا برنامه‌های دسکتاپ پیچیده و یا سیستم‌های متصل شده. رابط‌های برنامه‌نویسی و ابزار‌ها و مستندات در سطح جهانی، ایجاد برنامه‌ها را ساده‌تر می‌کند. حفظ، ثبات (پایداری) و سازگاری، امکان حفظ بانک بزرگی از کد‌ها با حداقل تلاش برای نگه‌داری آن‌ها. یک اکو سیستم بزرگ توسعه‌دهنده با بیش از ۱ میلیون کاربر. یک نسخهٔ جدید از کیوت باید خواسته‌های محصول ما را مطابق با نیاز‌های بازار تنظیم کند، و در عین حال پنج ویژگیِ بالا را به خوبی حفظ کند. بازار دسکتاپ، ریشهٔ پیشنهادات و یک بازار قوی و مهم برای کیوت است؛ در این مرحله است که بیشترین تماس‌ها با ما و در انجمن‌های کیوت از طرف کاربران صورت می‌گیرد که باید سالم نگه‌ داشتن و رشد آن مهم باشد. بزرگترین بخش از رشد کیوت نیز مربوط به دستگاه‌های تعبیه شده و متصل شده می‌باشد؛ صفحات نمایش لمسی به تعداد تصاعدی در حال افزایش است که در کنار آن افزایش قیمت سخت‌افزار برای این دستگاه‌ها وجود دارد. چیپست‌های کم مصرف، میکرو‌کنترلر‌ها، همراه با صفحه نمایش لمسی به اندازه‌های کوچک در همه جا استفاده می‌شوند. بسیاری از این دستگاه‌ها عملکردی نسبتاً ساده‌ای دارند، اما به رابط کاربری صیقلی و صافی نیاز دارند. بنابراین حجم زیادی از این دستگاه‌ها ایجاد می‌شود و ما باید اطمینان حاصل کنیم که می‌توانیم با ارائهٔ خود آن فضا را هدف قرار دهیم تا بتوانیم قوبل مقیاس پذیری خود را عملی کنیم. در عین حال، رابط‌های کاربری در طیف دستگاه‌‌ها همچنان به افزایش پیچیدگی ادامه می‌دهند که شامل هزاران صفحه مختلف و برنامه‌های بسیاری است. ادغام عناصر سه بعدی و دو بعدی در یک رابط کاربری مشترک خواهد بود که در کنار آن استفاده از واقعیت افزوده و مجازی نیز وجود خواهد داشت. عناصر هوش مصنوعی بیشتر در حوزهٔ برنامه‌ها و دستگاه‌ها مورد استفاده قرار می‌گیرد و ما نیاز به روش‌های آنسان برای ادغام با آن‌ها داریم. رشد شدید تعداد دستگاه‌های متصل به هم و همچنین الزامات بسیار بالاتر در تجربه‌کاربر باعث می‌شود تا برای ساده سازی ایجاد برنامه‌ها و دستگاه‌ها، روی ابزار‌های کلاس جهانی تمرکز کنیم. هماهنگ سازی و ادغام طراحان UX در گردش کار توسعه یکی از اهداف است؛ اما بسیاری از زمینه‌های دیگر وجود خواهد داشت که ما باید برای ساده سازی زندگی کاربران تلاش کنیم. کیوت ۶ یک نسخهٔ اصلی و جدید برای Qt خواهد بود؛ هدف اصلی با چنین نسخهٔ اصلی و جدید، آماده سازی کیوت برای شرایط مورد نیاز در سال ۲۰۲۰ و بعد از آن، تمیز کردن کد‌های پایهٔ ما و حفظ آسان‌تر است. به همین ترتیب تمرکز روی آن مواردی خواهد بود که نیاز به تغییرات معماری در کیوت دارند و بدون شکستن برخی از سازگاری‌ها با سری‌های کیوت ۵ قابل انجام نیست. در زیر برخی از تغییرات اساسی که ما باید در کیوت ایجاد کنیم برای مناسب‌تر کردن آن برای سال‌های آینده ارائه شده است. نسل بعدی کیو‌اِم‌اِل (QML) زبان QML و فناوری Qt Quick فناوری‌های اصلی رشد سال‌های گذشتهٔ ما بوده است. روش‌های بصری ایجاد واسط‌های کاربری با استفاده از آن فناوری‌ها نقطه فروش بی نظیری از پیشنهاد ما است. اما QML، همانطور که برای کیوت ۵ ایجاد شده است، دارای تعداد زیادی تغییرات ناگهانی و محدودیت است. این به نوبهٔ خود به این معنا است که، امکان پیشرفت‌های چشم‌گیری وجود دارد که ما قصد داریم با کیوت ۶ آن‌ها را پیاده سازی کنیم. معرفی وابستگی زیاد به نوع (strong typing)، وابستگی کم به نوع (weak typing) امکان ایجاد تغییر در کدها را برای کاربران ما سخت می‌کند. سیستمی از مدل وابستگی زیاد به نوع امکان پشتیبانی از این تغییرات را در محیط‌های یکپارچهٔ توسعهٔ نرم افزار و سایر ابزارها به کاربران می‌دهد و به طور چشمگیری حفظ و نگهداری از آن‌ها را راحت می‌کند. همچنین، قادر به تولید کدهای اجرایی هرچه بهتر و با سربار کمتر خواهیم بود. اعمال JavaScript به عنوان یک ویژگی اختیاری، با توجه به این موضوع، داشتن یک موتور کامل جاوا اسکریپت هنگام استفاده از QML می‌تواند مشکلات را پیچیده‌تر کند و به خصوص هنگام هدف قرار دادن سخت‌افزار کم مصرف مانند میکرو کنترلرها یک مشکل اصلی محسوب می‌شود. اما در بسیاری از موارد استفاده از آن بسیار مفید است. حذف نسخه سازی QML، با ساده کردن برخی از قوانین بررسی و جستجو و تغییرات در برخی از خواص می‌توانیم نیاز به نسخه را در QML حذف کنیم. این به نوبهٔ خود منجر به ساده سازی‌های زیاد در موتور کیو‌ام‌اِل می‌شود. حجم کار در حفظ فناوری کیوت کوئیک و ساده‌تر کردن استفاده از QML و Qt Quick را برای کاربران بسیار ساده‌تر خواهد کرد. حذف ساختار داده‌های تکراری بین QObject و QML در حال حاضر، برخی از ساختار داده‌ها بین meta-object و QML کپی و تکرار می‌شوند و عملکرد (کارایی و پرفرمنس) را در استارتاپ برنامه کاهش می‌دهد و باعث افزایش مصرف حافظه نیز می‌گردد. بنابراین با متحد کردن ساختار‌های داده‌ها، ما قادر خواهیم بود بخشی اعظمی از آن را حذف کنیم. خودداری کردن از ساختار‌های داده تولید شده این مربوط به نکتهٔ قبل است، جایی که در حال حاضر بسیاری از ساختار‌های داده تکراری در زمان اجرا تولید می‌شوند. باید تولید اکثر آن‌ها در زمان کامپایل کاملاً امکان‌پذیر باشد. پشتیبانی از کامپایل QML برای بهره‌وری از کد‌های بومی C++، با وابستگی زیاد به نوع و قوانین جستجوی ساده‌تر، می‌توانیم QML را به کد‌های بومی C++ تبدیل کنیم که نتیجهٔ آن به طور قابل توجهی عملکرد زمان اجرا را افزایش می‌دهد. پشتیبانی از پنهان کردن جزئیات اجرا، روش و خصوصیات «خصوصی» یک نیاز طولانی مدت است تا بتوانید داده‌ها و عملکرد‌ها را در اجزای QML پنهاد کنید. هماهنگ‌سازی و ادغام بهتر ابزار‌ها، مدل کد‌های ما غالباً برای QML ناقص است و باعث می‌شود که تغییر مکان و خطاها را در زمان کامپایل غیر ممکن کند. با تغییرات فوق، می‌توان تشخیص کامپایلر را ارائه داد که بتواند با C++ و همچنین پشتیبانی از آن پالایشِ کد‌ها را بهبود بخشد. نسل بعدی گرافیک‌ها بسیاری از موارد در حوزهٔ گرافیک در نسخهٔ کیوت ۵ تغییر یافته‌اند. این باعث می‌شود که برای حفظ رقابت و توسعه در پُشته انجام شود. با کیوت ۵، ما از رابط‌های برنامه‌نویسی OpenGL را برای گرافیک‌های ۳ بعدی استفاده کردیم. از آن زمان به بعد، میزبانی از رابط‌‌های برنامه‌نویسی جدید نیز تعریف شده است. بنابراین وُلکان (Vulkan) جانشین مشخصی برای OpenGL در لینوکس است، اپل نیز مِتال (Metal) را تحت فشار قرار داد تا آن را جایگزین کند و مایکروسافت DirectX را دارد. این بدان معنی است که کیوت در آینده مجبور است به صورت یکپارچه با تمام رابط‌های برنامه‌نویسی کار کند. برای اینکه این ویژگی امکان‌پذیر باشد، باید یک لایهٔ جدید که رابط‌های برنامه‌نویسی گرافیکی را انتزاع می‌کند مانند (QPA برای ادغام سکو) به نام رابط سخت‌افزاری RHering تعریف شود. ما نیز باید زیر ساخت‌های ارائه شدهٔ خود (Qt Quick Scenegraph، QPainter و پشتیبانی ۳ بعدی) را در بالای آن لایه قرار دهیم. مجموعهٔ رابط‌های برنامه‌نویسی گرافیکی مختلف باعث می‌شود که ما از زبان‌های مختلف سایه‌زنی پشتیبانی کنیم. ابزار Qt Shader به عنوان یک ماژول به ما کمک می‌کند تا سیستمِ سایه‌زنی را به صورت هم‌زمان (کراس‌-کامپایل) و در زمان اجرا کامپایل کنیم. بحث ۳ بعدی نقش مهم و مهمتری را ایفا می‌کند، و پشتیبانی فعلی ما یک راه حل یکپارچه برای ایجاد رابط کاربری (UI) ‌هایی که حاوی هر دو عنصر ۲ و ۳ بعدی باشد را ندارد. ادغام QML با محتوا از Qt3D و یا Qt 3D Studio در حال حاضر کار دشواری است و باعث سر‌ریز شدن برخی از کارایی‌ها و عناصر نمایشی می‌شود. علاوه بر این همگام سازی انیمیشن‌ها و انتقال‌ها بر روی یک فریم با سطح فریم بین محتوای ۲ و ۳ بعدی غیر ممکن است. ادغام جدید محتوای ۳ بعدی با فناوری کیوت کوئیک با هدف حل این مشکل ایجاد شده است. در این حالت، یک سیستم ساخت (رندر) کامل و جدید به شما امکان می‌دهد تا محتوای ۲ و ۳ بعدی را با هم ظبط کنید. با این کار QML به زبان UI تعریف و تبدیل می‌شود که سه بعدی هستند و نیاز به فرمت UIP برطرف می‌شود. ما یک پیش‌نمایش از کیوت کوئیک جدید با پشتیبانی سه بعدی در حال حاضر با کیوت ۵.۱۴ ارائه می‌دهیم که اطلاعات بیشتر در یک پست جداگانه ارائه خواهد شد. سرانجام پشتهٔ گرافیکی جدید نیاز به پشتیبانی از خط لولهٔ برای چیز‌های گرافیکی هستند که این امکان را می‌دهد تا آن‌هایی که در زمان کامپایل برای سخت افزار مورد نظر تهیه شده‌اند آماده کرده و از موارد مورد نظر استفاده کند. برای مثال، فایل‌های PNG را به بافت‌های فشرده تبدیل می‌کند و بسیاری از آن‌ها را به بافت (Texture) تبدیل کند. سایه‌ها و مِش‌ها را به قالب‌های باینری بهینه شده و موارد دیگر تبدیل خواهد کرد. همچنین هدف ما این است که یک موتور متحد برای پوسته/ظاهر در کیوت ۶ ارائه دهیم که به ما این امکان را می‌دهد تا از نظر ظاهری و احساسات بر روی دسکتاپ و موبایل آن را بر روی هر دو فناوری کیوت‌ ویجت و کیوت‌ کوئیک ارائه کنیم. ابزار یکپارچه و سازگار ابزار‌های گرافیکی ما برای ساخت رابط‌های کاربری به دو بخش با استودیو کیوت ۳ بعدی (Qt 3D Studio) و استودیو طراحی کیوت (Qt Design Studio) تقسیم بندی شده‌اند. علاوه بر آن، استودیو ۳ بعدی اند;ی از بقیه کیوت جدا شده است که باعث می‌شود کمی بیشتر سعی بر آن شود! ابزار‌های طراحی نیز به ایجاد محتوا مانند، محتوای ساخته شده در Photoshop، Sketch، Illustrator، Maya، 3DsMax و دیگر موارد ادغام شده است. ابزار‌های توسعه به توجه زیادی برای تمرکز دارد تا بتوانیم بهترین‌ها را در پشتیبانی کلاس برای QML، C++ و پایتون ارائه دهیم. یک ابزار متحد و یکپارچه این اجازه را می‌دهد که یک طراح UX بتواند از قابلیت‌های طراحی در کیوت کریتور استفاده کند و طراحان می‌توانند از ویژگی‌های ابزار‌های توسعه‌دهنده مانند تهیه یک پروژه یا آزمایش روی یک دستگاه بهره‌مند شوند. ابزار ساخت QMake به عنوان ابزار ساخت در کیوت ۵ مورد استفاده قرار می‌گیرد که تعداد زیادی تغییرات ناگهانی و محدودیت‌ها خواهد دارد. برای کیوت ۶، هدف ما این است که CMake را به عنوان سیستم ساخت ثالث و استاندارد برای ساخت خود کیوت استفاده کنیم. چرا که سی‌میک تاکنون پرکاربرد‌ترین سیستم ساخت در جهان برای سی‌پلاس‌پلاس بوده است و ادغام هرچه‌بهتر آن کاملاً مورد نیاز است. البته پشتیبانی از QMake ادامه خواهد داشت، اما آن را توسعه نخواهیم داد یا از آن برای ساخت فریم‌ورک کیوت استفاده نخواهیم کرد. بهبود رابط‌های برنامه‌نویسیC++ سی‌پلاس‌پلاس طی سال‌های گذشته تغییرات بسیار زیادی کرده است؛ در حالی که ما مجبور بودیم کیوت ۵.۰ را روی سی‌پلاس‌پلاس ۹۸ پایه‌گذاری کنیم. اما اکنون می‌توانیم به سی‌پلاس‌پلاس ۱۷ برای پایه‌گذاری کیوت ۶ اطمینان کنیم. این بدان معنی است که C++ عملکرد بسیار بیشتری را نسبت به زمان توسعه و اجرای کیوت ۵ که در دسترس نبود ارائه خواهد کرد. هدف ما با کیوت ۶ بهتر شدن با یکپارچه‌سازی و ادغام قابلیت‌ها بدون از دست دادن پشتیبانی و سازگاری از روش‌های پیشین (رو به عقب یا همان backward compatibility) است. برای کیوت ۶، هدف ما این است که برخی از قابلیت‌های معرفی شده با QML و فناوری Qt Quick را از طرف C++ در دسترس قرار دهیم. بنابراین ما در تلاش برای معرفی یک سیستم خاص برای QObject و کلاس‌های مرتبط هستیم. موتور اتصال دهنده را از QML در هستهٔ کیوت ادغام می‌کنیم و آن را از سی‌پلاس‌پلاس در دسترس قرار می‌دهیم. این سیستم خاص از موتور اتصال به کاهش قابل توجهی در سربار زمان کار و مصرفه حافظه در اتصال منجر می‌شود و آن‌ها را برای همهٔ قسمت‌های Qt، نه تنها Qt Quick قابل دسترس می‌کند. پشتیبانی از زبان با کیوت ۵.۱۲، پشتیبانی از پایتون معرفی شده است. همچنین مرورگر را به عنوان پلتفرم جدید از طریق کیوت برای وِب اسمبلی اضافه کرده‌ایم. پس از انتشار کیوت ۶.۰ نگه‌داشتن و گسترش بیشتر بر روی سطح چند‌-سکویی بخش مهمی از اهداف و مسیر توسعهٔ سری‌های کیوت ۶ خواهد بود. سازگاری با کیوت ۵ و افزایش سازگاری‌ها و بهبود‌ها سازگاری با نسخه‌های قدیمی‌تر بسیار مهم است، بنابراین وقتی کیوت ۶ را توسعه می‌دهیم یک نیاز اساسی محسوب می‌شود. توسط چهارچوب کیوت میلیون‌ها خط کد نوشته شده است و هرگونه تغییرات در ناسازگاری که انجام شود هزینه‌ای را برای کاربران خواهد داشت. علاوه‌ بر این، کار بیشتری برای تغییرات در کیوت ۶ نیاز است تا کاربران کم کم با آن سازگار شوند که منجر به هزینه‌های بیشتر از طرف تیم توسعهٔ کیوت برای حفظ آخرین نسخه کیوت ۵ خواهد بود. به این ترتیب، ما باید به فکر جلوگیری از ساطع شدن خطاهای احتمالی در زمان کامپایل و یا زمان اجرا برای کاربران می‌شود باشیم. در حالی که ما نیاز به حذف بخش‌هایی از کیوت خواهیم داشت، باید اطمینان حاصل کنیم که کاربران ما از عملکرد مورد نیاز خود برخوردار هستند. این بدان معنا است که کلید‌هایی مانند Qt Widgets و سایر قسمت‌هایی که توسط بخش بزرگی از کاربران ما مورد استفاده قرار می‌گیرد، در دسترس باشد. ما در حال برنامه‌ریزی برای افزایش بسیاری از پیشرفت‌ها در کلاس‌های اصلی و عملکردی هستیم که در سری کیوت ۵ نتوانستیم انجام دهیم. هدف این است که سازگاری کامل منبع را حفظ کنیم، اما از آنجا که می‌توانیم سازگاری باینری را با کیوت ۶ بشکنیم، می‌توانیم پاک‌سازی‌ها و اصطلاحات کاملاً زیادی را انجام دهیم که در کیوت ۵ نمی‌توانستیم آن را عملی کنیم. با این وجود، ما باید به جلو پیش برویم و برخی از پاک‌سازی‌ها که در کیوت ۵ در مورد کلاس‌ها، توابع و یا ماژول‌ها عنوان شده بود را در کیوت ۶ به طور کامل اعمال کنیم. این کار باعث می‌شود ما روی مبنای کد‌گذاری شدهٔ فعلی تمرکز بیشتر و بهتری داشته باشیم. با این حال، انتقال به دور از قسمت‌های منسوخ شده باید تا حد امکان ساده باشد و کاربران ما می‌توانند با استفاده از کیوت ۵.۱۵ «پشتیبانی بلند مدت» به صورت ایده‌آل این کار را انجام دهند. هدف ما باید این باشد که کیوت ۶ به اندازهٔ کافی با نسخهٔ ۵.۱۵ سازگار باشد تا فرد بتواند به راحتی یک بخش اعظمی از کد خود را حفظ کند، به طوری که کد آن در هر دو نسخهٔ ۵ و ۶ قابل کامپایل باشد. بازار و ساختار فنی محصول علاوه بر بهبود چهارچوب و ابزار‌های کیوت، هدف ما ایجاد بازار جدیدی برای قطعات و ابزار‌های توسعه است. این بازار بر روی کاربران مستقیم ما متمرکز خواهد شد که برنامه‌های کاربردی و دستگاه‌های تعبیه شده را طراحی و توسعه می‌دهند؛ به این ترتیب این یک مرکز تجمع اصلی برای اکو سیستم کیوت خواهد بود که این امکان را به شخص ثالث می‌دهد تا نسخه‌های اضافی خود را در کیوت منتشر کنند و هم محتوای رایگان و تجاری را که برای آن هزینه پرداخت می‌کنند. کیوت طی سال‌های گذشته رشد بسیار زیادی داشته است، تا جایی که ارائهٔ نسخهٔ جدید آن یک کار مهم است. با استفاده از کیوت ۶ فرصتی برای باز‌سازی محصولات ارائه شده ما وجود دارد و یک محصول اصلی و کوچکتر که شامل چهارچوب‌ها و ابزار‌های اساسی است. ما از بازار استفاده خواهیم کرد تا چهارچوب و ابزار‌های اضافی خود را ارائه دهیم، نه به عنوان یک بسته‌نرم‌افزاری وابسته به کیوت! چشم‌انداز فنی تا اولین نسخهٔ کیوت ۶ تکامی خواهد یافت. اگرچه معتقد هستیم که این سند بسیاری از مهمترین نکات را برای نسخهٔ بعدی کیوت معرفی می‌کند اما مطمئناً کامل نیست. اگر شما هم ایدهٔ دیگری دارید می‌توانید آن را با ما در میان بگذارید.

مدتی است در مورد مسدود شدن اپلیکیشن‌های ایرانی برای iOS از طرف شرکت اپل خبر‌هایی به گوش می‌رسد که در سایت‌ها و پایگاه‌های خبری از سمت نویسندگان و افراد غیرفنی تجزیه تحلیل و روش‌های دور زدن آن‌ها ارائه می‌شود. واقعیت بر دلیل نوشتن این مقاله این است که این فرصت و مشکلات کنونی آبی گل‌آلود برای سود‌جویانی شده است که کاربران از آن بی‌خبرند! هر روز یک توسعه‌دهنده یک سایت جدید راه‌اندازی می‌کند و با ادعای ارائه بستری نامحدود اقدام به تبلیغات می‌کند. بنده نیز به عنوان توسعه‌دهنده وظیفهٔ خودم می‌دانم که یک بار برای همیشه توضیحات شفاف و روشنی را در اختیار کاربران iOS قرار دهم تا متوجه اصلِ موضوع باشند (بعد از آن تصمیم با خود شما)! اول از خودمان شروع کنیم، آیا واقعاً حرکت‌هایی که ما داشته‌ایم درست بوده است؟ به گونه‌ای که انگار اقدامات ما ایرانی‌ها بدون عیب و ایراد بوده و اپل بدون دلایل منطقی اقدام به تحریم ما کرده است! (هدف از این مقاله به هیچ عنوان طرفداری از اقدامات شرکت اپل نیست، چرا که این شرکت به عنوان فروشندهٔ محصولات خود وظیفه دارد به پشتیبانی و ارائهٔ خدمات به کاربرانش باشد نه اینکه هم سود کند و هم به خاطر مسائل سیاسی برخی از مشتریان خود را محدود کند. بنابراین ما اپل را هم محکوم به آن می‌کنیم که هیچ ارزشی به کاربران و توسعه‌دهندگان ایرانی به خاطر مسائل سیاسی قائل نیست)، و در مقابل مشترکین و حتی شرکت‌ها و فروشگاه‌های اپلیکیشن موظف هستند به جای توجیح کار‌های غیر قانونی و ناعادلانهٔ خود (و استفاده از چنین فرصت‌ها)، اقدامات به شفاف سازی روش‌های انتشار و توسعه کنند که مسلماً کاربران عادی و غیر حرفه‌ای از این امر بی خبرند! به گونه‌ای که انگار ما عادت کرده‌ایم هر زمان که مشکلی گریبان گیر ملت ما می‌شود به جای حل آن از روش صحیح و قانونی، اقدام به فشار بیشتر و سوء استفاده از آن فرصت کنیم که اصلاً روش انسان‌ دوستانه‌ای نیست (حداقل از فرهنگ اصیل ایرانی چنین انتظاراتی نداریم). اما واقعیت امر در چیست و دلایل مسدود سازی نرم‌افزار‌ها بر روی iOS در چیست؟ اینطور که به گوش می‌رسد و به گفتهٔ پایگاه‌های خبری و سایت‌های فناوری خبر‌ها اینگونه است که، اپل تا کنون چندین بار برخی اپلیکیشن‌های ایرانی را مسدود یا رَد اعتبار کرده است ولی این بار، اپلیکیشن‌های پرداخت الکترونیکی و موبایلی مانند آسان پرداخت و نرم‌افزار‌ بانک‌های معروف ایرانی تحریم شدند. افزون بر این، اپ‌های محبوب و پر کاربردی مانند اسنپ، تپسی، فون‌پی، دیجی‌کالا، فیدیبو، سیب‌اپ نیز جزو تحریم شده‌ها هستند. در قدم اول ممکن است دلایل این کار را به خاطر مسائل سیاسی بدانیم، این مسئله تا حدی ممکن است درست باشد، اما با بازنگری و یادآوری حریم خصوصی و حقوق مشتری در جامعهٔ بشری از سمت اپل نیز حکم می‌کند که جوابگوی خدمات پس از فروش خودش باشد. بنابراین بهانه‌ تراشی بخشی از اقدامات می‌تواند باشد اما مسئلهٔ اصلی این نیست! اجازه دهید جایگاه خودمان را برعکس در نظر بگیریم، با این حساب که ما به عنوان خدمات دهنده‌های ایرانی بستری را فراهم کرده‌ باشیم که به جامعهٔ بزرگی از دنیا خدمات ارائه می‌دهیم. بنابراین قوانین و چهارچوب‌های شفاف و مشخصی را عنوان خواهیم کرد که خارج از آن باید اقدام به یادآوری و گوشزد، تذکر و در نهایت برخورد قانونی و تحریم را در برنامه‌ داشته باشیم که یک روند قانونی و طبیعی است. این قوانین در صورتی اجرا می‌شوند که حقوق توسعه، تولید، نشر و پشتیبانی رسمی محصولات نادیده گرفته شود. بنابراین فرض کنید شما صاحب فروشگاهی هستید که نویسندگان (توسعه‌دهندگان) و ارائه‌دهندگان خدمات آن همگی ساعت‌ها، ماه‌ها و سال‌ها زمان بر توسعه و تولید محصولات خود گذاشته‌اند. حال ممکن است آن را رایگان و یا حتی با دیدگاه تجاری در اختیار کاربران قرار دهند. بنابراین عقل و منطق اجازه می‌دهد که شما نرم‌افزار رایگان را به صورت رایگان و نرم‌افزار‌های تجاری را در قبال پرداخت هزینهٔ آن مورد استفاده قرار دهید. در غیر این صورت اگر محصولی که شما ارائه داده‌اید با نقض این موارد مواجه شود (بدون شک اولین تصمیمی که خواهید گرفت حذف خدمات پس‌ از فروش، پشتیبانی و ... خواهد بود). اما واقعیت این مسئله چیست؟ آیا اپل اقدام به تحریم بی دلیل بر روی اپلیکیشن‌های ایرانی داشته است؟ اگر منطقی به قضیه فکر کنیم، به راحتی می‌توان این مسائل را بررسی و دلایل تحریم را درک کرد؛ من در این مقاله ابتدا به دلایل تحریم اپل می‌پردازم که پاسخ روشن و صریح این اقدامات اخیر را در این باره به شما خواهد داد. هرچند من به عنوان یک برنامه‌نویس باید به دنبال توسعه و تولید محصولات و حتی دور زدن تحریم‌های ناشیانه در این حوزه باید باشم، اما اینکه هم نوعان و همکاران خودم هم در این باره خبر‌ها و اطلاعات دروغ را به مشتریان این حوزه می‌دهند قابل تحمل نیست! چرا که اول باید از خودمان شروع کنیم! بهتر است در نظر داشته باشیم قوانینی که در اپل نیز ذکر شده‌اند به این اشاره دارد که در صورت خروج از این چهارچوب که ممکن است امنیت و حقوق مادی و معنوی توسعه‌دهنده و ناشر را پایمال کند، هیچ گونه تعهدی در رابطه با ادامهٔ همکاری و یا پشتیبانی از آن خدمات را نخواهند داشت. بنابراین شخصاً ندیدم حتی در یکی از فروشگاه‌های ایرانی اشاره‌ای به این حقوق شده باشه (حتی برعکس و شدیداً بر خلاف مواردی هستند که ذکر شده‌اند که با دلیل و اسناد معتبر خود مرجع اپل آن‌ها را شفاف سازی خواهم کرد). به عنوان مثال، اگر شما یک کاربر عادی یا حتی تازه کار باشید، یا اگر شما یک توسعه‌دهندهٔ تازه‌کار و حتی حرفه‌ای باشید بهتر است به این بخش از قوانین اپل (App Store Review Guidelines) توجه جدی کنید! این بخشی از قوانین صریح و شفاف اپل در حوزهٔ اپلیکیشن‌های iOS و فروشگاه خودش است که در زیر آمده است: App Store Review Guidelines Introduction Apps are changing the world, enriching people’s lives, and enabling developers like you to innovate like never before. As a result, the App Store has grown into an exciting and vibrant ecosystem for millions of developers and more than a billion users. Whether you are a first time developer or a large team of experienced programmers, we are excited that you are creating apps for the App Store and want to help you understand our guidelines so you can be confident your app will get through the review process quickly. The guiding principle of the App Store is simple - we want to provide a safe experience for users to get apps and a great opportunity for all developers to be successful. We do this by offering a highly curated App Store where every app is reviewed by experts and an editorial team helps users discover new apps every day. For everything else there is always the open Internet. If the App Store model and guidelines are not best for your app or business idea that’s okay, we provide Safari for a great web experience too. On the following pages you will find our latest guidelines arranged into five clear sections: Safety, Performance, Business, Design, and Legal. The App Store is always changing and improving to keep up with the needs of our customers and our products. Your apps should change and improve as well in order to stay on the App Store. A few other points to keep in mind: We have lots of kids downloading lots of apps. Parental controls work great to protect kids, but you have to do your part too. So know that we’re keeping an eye out for the kids. The App Store is a great way to reach hundreds of millions of people around the world. If you build an app that you just want to show to family and friends, the App Store isn’t the best way to do that. Consider using Xcode to install your app on a device for free or use Ad Hoc distribution available to Apple Developer Program members. If you’re just getting started, learn more about the Apple Developer Program. We strongly support all points of view being represented on the App Store, as long as the apps are respectful to users with differing opinions and the quality of the app experience is great. We will reject apps for any content or behavior that we believe is over the line. What line, you ask? Well, as a Supreme Court Justice once said, “I’ll know it when I see it”. And we think that you will also know it when you cross it. If you attempt to cheat the system (for example, by trying to trick the review process, steal user data, copy another developer’s work, manipulate ratings or App Store discovery) your apps will be removed from the store and you will be expelled from the Developer Program. You are responsible for making sure everything in your app complies with these guidelines, including ad networks, analytics services, and third-party SDKs, so review and choose them carefully. Some features and technologies that are not generally available to developers may be offered as an entitlement for limited use cases. For example, we offer entitlements for CarPlay Audio, HyperVisor, and Privileged File Operations. Review our documentation on developer.apple.com to learn more about entitlements. We hope these guidelines help you sail through the App Review process, and that approvals and rejections remain consistent across the board. This is a living document; new apps presenting new questions may result in new rules at any time. Perhaps your app will trigger this. We love this stuff too, and honor what you do. We’re really trying our best to create the best platform in the world for you to express your talents and make a living, too. در قوانین ذکر شده به صراحت عنوان شده است که اگر به فکر برنامه‌های آزمایشی هستید بهتر است از محیط Xcode با همان حساب توسعه‌دهندگی استفاده کنید که تنها بر روی دستگاه‌ خودتان می‌تواند اجرا شود. در صورتی که به فکر بحث تجاری آن هستید باید تمامی حقوق مربوطه را رعایت کنید و حتی نباید به فکر کپی کردن، درز اطلاعات، به خطر اندازی حریم خصوصی و دیگر مسائل بپردازید که در این صورت اپل محصول شما را رَد خواهد کرد. فشار دو طرفه، بهانه تشدید بهانه... بهانه و باز هم بهانه!!! مسلماً برای همه روشن است که سیاست‌های آمریکایی و شرکت‌های آن منتظر بهانه‌هایی هستند که سریعاً فشار‌ها را به سمت ملت ایران وارد کنند، بنابراین مانند اقدامات اخیر Github که متأسفانه مجبور هستند بر اساس سیاست‌های دولتی خود اقدام به محدود سازی خدمات خود به ایرانی‌ها باشند (اپل بسیار مشتاقانه‌تر به دنبال بهانه و ایجاد فشار به ملت ما می‌شتابد). بنابراین باز هم یادآوری کنیم محصولی که بابت آن پول پرداخت می‌شود اعمال محدودیت و فشار بر آن دیگر جایز و انسان‌دوستانه نیست! جالبتر از این موارد یادآوری این موضوع است که دوستان داخلی به جای حل مشکلات با فرصت طلبی‌ها و سوء استفاده‌‌ها و بی‌انصافی‌ها هم فشار وارده را بر کاربران iOS بیشتر کرده‌اند و هم وضعیت و بهانه‌های بیشتری به دست شرکت اپل می‌دهند! این واقعیتی است که باید پذیرفت (به گونه‌ای که در شرایط اقتصادی کنونی هم فشار از خارج هم داخل بر ملت ما وارد است). کاش منصفانه به فکر راه حل‌های مشکلات کنونی باشیم... ملت ما در چنین شرایطی هر جا که به کمک هم شتاب کرده‌اند موفق‌تر بوده‌اند و خواهند بود (اما به روش درست نه غلط!!!). حال با در نظر گرفتن نقض قوانین صریح از سمت فروشگاه‌های ایرانی که به آن‌ هم افتخار می‌کنند، آیا نباید انتظار داشت تا روزی اپل یا هر شرکت دیگری صبرش به پایان برسد و خیس و خُشک را باهم بسوزاند؟! بخشی از ادعاهایی که بزرگترین مرجع ایرانی (سیب‌اپ) اپلیکیشن‌های iOS ارائه شده است به صورت زیر می‌باشد: زمانی که دسترسی به هزاران اپلیکیشن خارجی با ارزش ۵۰،۰۰۰ دلار در کشور ما با افتخار حقوق توسعه‌دهنده و ناشر را زیر سوأل می‌برد نباید انتظار داشت چنین تحریم‌هایی حق ماست؟ حال آنکه چنین فروشگاه‌هایی جدیداً از محدودیت‌های اخیر سوء استفاده کرده و حتی با وعده‌های دروغین اقدام به فروش اشتراک ویژه می‌کنند که در ازای آن هیچ تضمینی از امنیت، حقوق مادی و معنوی و حتی اجرا شدن نرم‌افزار‌های موجود در آن فروشگاه وجود ندارد! متأسفانه دروغ‌ها و فرصت‌ طلبی‌ها از چنین فرصت‌ها به جای حل مسائل و اختلاف‌های سیاسی و تجاری چیزی به جز بدتر کردن وضعیت کنونی نخواهد داشت. حتی هیچ شانسی برای بهتر شدن وضعیت کنونی باقی نخواهد ماند. نقل قول زیر از طرف سیب‌اپ است که ادعا کرده است با پرداخت اشتراک شما قادر به دانلود بدون مشکل اپلیکیشن‌ها خواهید بود. راه حل‌های ناشیانه و واقعا مسخره که از طرف فروشگاه‌ها و نویسندگان خبری اخیر به دستمان رسیده است به صورت زیر هستند: استفاده از نسخه وب اپلیکیشن حقیقت نفهته در پشت این راه حل‌ها به این صورت است که یک فناوری به عنوان PWA یا همان (Progressive web applications) وجود دارد که همان نسخهٔ وب به شمار می‌آید! در واقع اپلیکیشن‌های نوشته شده به این روش بسیار بدتر از حتی یک وب‌سایت کامل هستند و تنها به روش‌های غیر بومی و خارج از محیط Xcode تحت فناوری‌های وب مانند HTML, CSS و JavaScript توسعه داده می‌شوند. در نهایت هیچ ربطی به نسخهٔ اصلی و نوشته شده‌ به روش طبیعی نرم‌افزار‌های iOS ندارد و تنها نسخهٔ محدود شده‌ای از وب‌سایت خدماتی است که با حقه‌های فریبنده و کاملاً ناشیانه اقدام به ساخت میان‌بر و ایجاد آیکون بر روی صفحه گوشی شما می‌کنند که اینطور برداشت کنید نسخهٔ واقعی اپلیکیشن را نصب کرده اید!!! در حالی که بهتر است به جای آن از همان وب‌سایت استفاده کنید. مسخره است نه؟! دسترسی به برنامه‌هایی که پیش‌تر از اپ استور دانلود کرده‌اید دسترسی به برنامه‌هایی که پیش‌تر از اپ‌استور دانلود شده است روشی کاملاً مسخره‌تر است که به شما پیشنهاد می‌دهد تا نسخه‌های قدیمی اپلیکیشن‌هایی که اپل آن‌ها را نگه‌داشته است اما توسعه‌دهنده‌گان آن‌ها هم نمی‌توانند آن را به‌روز رسانی کنند استفاده کنید! این کار چه فایده‌ای دارد دقیقاً؟ تعداد اپلیکیشن‌هایی این چنینی بسیار محدود هستند مانند دیوار ... که آخرین به‌روز رسانی آن به ۲ سال پیش مربوط است!!! جیلبریک کردن این روش ممکن است کارایی داشته باشد، اما تمامی مسائل امنیتی و خدماتی که اپل آن‌ها را ارائه می‌کند را از بین برده و در واقع در این روش هیچ تضمینی برای حفظ اطلاعات و صحت عملکرد دستگاه شما وجود ندارد (در واقع شما از روش بسیار خطرناک از بین هزاران حفره‌های شکافته شدهٔ امنیتی عبور کرده و از برنامهٔ مورد نظرتان که شاید آن یک اپلیکیشن بانکی و ... باشد استفاده می‌کنید). راه حل سیب اپ (بزرگ‌ترین فروشگاه ایرانی برای برنامه های iOS) این پیشنهاد زمانی معتبر است که فروشگاه و یا فروشگاه‌های مربوطه با شفافیت کامل بیان کنند که راه‌حل‌های فعلی هیچکدام نهایی نیست و اصلاً مخصوص کاربر نیست!!! چرا که مشتری نه توسعه‌دهنده است و و نه شرکت! بنابراین زمانی که با حرکت‌های ظاهراً حرفه‌ای اما در حقیقاً کاملاً غیر حرفه‌ای از هر کاربر یک توسعه‌دهنده یا شرکت و یا سازمان می‌سازند طبیعی است که باید هزینه‌هایی مانند ۹۹ تا ۲۹۹ دلار در سال را بپردازند که مسلماً منجر به پولی شدن حق نصب اپلیکیشن خواهد بود که از بیخ غلط است! بنابراین انتظار می‌رود تحت هیچ شرایطی مردم را نَفَهم فرض نکنیم! مطمئنان هر عقل سلیمی می‌تواند تشخیص دهد که این روش دقیقاً همان مثال معروف (ماهی گرفتن از آب گل‌آلود است) در واقع شما باید پول به چیزی بپردازید که خودش روش غیرقانونی و نامناسب است!!! برخی از توسعه‌دهندگان و سایت‌های خبری و حتی استور‌ها چنین ادعا می‌کنند که هیچ محدودیتی در توسعه و انتشار برنامه‌های iOS وجود ندارد، آیا این حقیقت است؟ طبق توضیحاتی که در بالا اشاره کردم، هیچ روش منطقی در داخل کشور وجود ندارد که قانونی باشد، اگر کسی مدعی به انتشار است مطمئنان از همین روش‌هایی که اشاره شد استفاده می‌کند که خارج از این نیست. فروشگاه‌های جدید و مدعی بدون محدودیت چگونه کار می‌کنند؟ متأسفانه با وجود شرایط کنونی و محدودیت‌های اپل افراد و فروشگاه‌های زیادی در چندین ماه اخیر ایجاد شده‌اند که از این فرصت برای ارائه خدمات به شیوهٔ PWA و دو روش دیگر که ذکر شد استفاده می‌کنند که هیچ یک از آن‌ها ارائه دهندهٔ خدمات واقعی نیستند. (اگر شما فروشگاهی را می‌شناسید که از روش‌های قانونی برای نشر برنامه‌ها استفاده می‌کند که نیاز نباشد هر چند وقت یک بار برنامه‌ را حذف و دوباره نصب کنند و یا در بهترین حالت شما را به عنوان توسعه‌دهندهٔ اپل معرفی نکنند به ما معرفی کنید تا به گوش همگان برسانیم!). روش‌های پیشنهادی و رسمی اپل چیست؟ طبق اسناد رسمی، اپل می‌گوید اگر شما برنامهٔ خودتان را به صورت استاندارد توسعه‌ داده‌اید می‌توانید به دو روش آن را منتشر کنید؛ روش اول این است که آن را در فروشگاه اپل منتشر کنید (که در این روش بنابر اساس سیاست‌هایی که دارند مسلماً تحریم ما خواهد بود که شاهدش بودیم - حذف اپلیکیشن‌های ایرانی از فروشگاه اپل). روش دوم آن است که شما اپلیکیشن خود را در قالب روش‌های Ad-Hoc ایجاد کنید که محدود بر ۱۰۰ دستگاه (کاربر) خواهد بود. این روش نیز به گونه‌ای قابل استفاده است اما محدود بر تعداد کاربران خواهد بود و برای اهداف داخلی و سازمانی خودمان طراحی شده است و بدون شک امضاء و مدیریت آن همراه با تولید آمار بسیار زیادی از تأییدیه‌ها سرسام آور خواهد بود. درواقع اپل می‌گوید اگر می‌خواهید در دامنهٔ بزرگتر یعنی جهان، استفاده کنندهٔ اپلیکیشن شما باشد باید در فروشگاه من آن را منتشر کنید تا هم امنیت و هم پشتیبانی آن را تضمین کنم. روش‌های دیگر نیز با عنوان (Enterprise Program) مطرح هستند که مخصوص تیم‌های توسعه‌ای که در برنامه Enterprise یا همان تجاری ثبت نام کرده‌اند نیز می‌توانند از توزیع داخلی استفاده کنند. این روش همان روشی است که اپل برای عموم اکثراً محدود کرده است و مختص تحریم‌های ایران نیست. درواقع همان روشی که بعضی از شرکت‌های ایرانی هر روز می‌گویند اپلیکیشن را از لینک جدید دریافت کنید!!! که البته همراه با هزینهٔ سالانه ۲۹۹ دلار است! روش‌های محدود‌تر دیگری وجود دارد که کاربران با محدودیت بیشتری با آن می‌توانند برنامه‌ها را صرفاً برای مصارف ازمایشی و خودمانی استفاده کنند که این دسته با عنوان University Program شناخته شده اند و توانایی نشر برنامه به جامعهٔ هدف بزرگتری را نخواهند داشت. با توجه به این تعاریف مشخص است که دو روش پیش‌فرض استاندارد و Ad-Hoc باقی مانده است. تکلیف روش اول مشخص است که تا زمانی که تحریم‌ها وجود دارد نباید انتظار داشت که در اپ‌استور بتوان اپلیکیشن‌های ایرانی را بارگذاری کرد. اما روش اد‌هاک همان روشی است که اجازه می‌دهد با خرید و ثبت دستگاه در بانک گواهی‌های معتبر اپل اپلیکیشن‌های خود را به مدت ۱ سال یا بیشتر امضا کنید (این روش برای توسعه‌دهندگان) پیشنهاد شده است که احتمالاً روش‌های فعلی استور‌ها این باشد! مسلماً این روش هزینهٔ شارژ و امضای توسعه‌دهنده را خواهد داشت. البته لازم به ذکر است این روش قطعی نیست و اگر اپل بداند که به زودی هم خواهد دانست میلیون‌ها کاربر توسعه‌دهنده پیدا کرده است! مسلماً طی اقداماتی روش‌هایی برای حل آن ارائه خواهد داد. خب راه حل منطقی چیست؟ با توجه به مستندات و منابع رسمی که اعلام کرده‌اند، از اولین ساعت‌های مسدود شدن نرم‌افزار‌های بانکی و پرداختی، شرکت‌هایی که در این مجموعه اپ یا اپ‌هایی داشتند؛ راه‌حل موقت خود را ارایه کردند، عمده‌ترین راه‌حل استفاده از اپ‌های مسدود شده روی گوشی‌های آیفون، مراجعه به نسخه وب اپلیکیشن یا استفاده از پلتفرم‌های دیگری مانند اندروید است. مدیران اسنپ و دیجی‌کالا از کاربران‌شان درخواست کردند به طور موقت نسخه وب آن‌ها را استفاده کنند تا مشکل حل شود. برخی شرکت‌ها مانند سیب‌اپ و تپسی، نسخه جدید و مجزایی از اپ‌استور ارایه داده و از کاربران‌شان درخواست کردند این اپلیکیشن را از روی سایت آن‌ها دریافت و نصب کنند. سیب‌اپ در پیام‌های ویدیویی و اطلاعیه رسمی، به کاربران خود وعده داده است به‌زودی نسخه جدیدی از اپلیکیشن سیب‌اپ ارایه خواهد شد که دیگر مشکل مسدود بودن یا عدم اعتبارسنجی توسط اپل را ندارد (که این روش زمانی قابل تأیید خواهد بود که به روش‌هایی غلطی که در بالا اشاره شد عمل نشود و رسالت و شعار‌های فریبانهٔ خود را تغییر دهند) که مسلماً باید اول حقوق مادی و معنوی و حریم خصوصی مصرف کننده را تضمین کنند و در نهایت به روش‌های قانونی مجوز‌های لازم را از اپل دریافت کنند که با توجه به شرایط حاکم کمی غیر ممکن و دور از انتظار است!!! روش‌های بهتری جهت نصب و راه‌اندازی اپلیکیشن‌های ایرانی وجود دارد که با نام‌های Add-Hoc نیز معروف هستند که محدود به نوع توسعه‌دهنده و تجاری معرفی می‌شوند. البته روش‌های تجاری همان روش‌هایی است که سیب‌اپ و دیگر شرکت‌ها مورد استفاده قرار داده‌اند. اما روش روش نوع توسعه‌دهنده می‌تواند با در نظر گرفتن ثبت دستگاه شما در پروفایل این مشکل را تا حدی برطرف کند که فروشگاه‌هایی مانند اناردونی با در نظر گرفتن هزینهٔ ثبت دستگاه آن را تا به مدت ۱ سال تضمین می‌کنند. روش درست و صحیح‌تر آن است که دقیقاً طبق قوانین اپل عمل شود، در واقع تمامی ماده‌ها و تبصره‌های عنوان شده توسط شرکت اپل در اپ‌استور را باید پذیرفت. اما مشکل اصلی و اساس این مشکلات این است که اپل قبلاً هم گفته است حاضر به ارائهٔ خدمات به ایران نیست. (یاد شعار استیو جابز مرحوم افتادم که ما خواهیم گفت کاربر از چه چیزی باید استفاده کنند نه آن‌ها) در واقع اپل با این اقدامات و فشار‌های خود رسماً می‌گوید شما بهتر است از محصولات دیگر استفاده کنید که عمل زشت و بسیار نژاد‌پرستانه است. آیا فروشگاه‌های داخلی به داد مردم می‌رسند یا از آب گل‌آلود ماهی می‌گیرند؟ قضیه این است!!! خوشبختانه در حالت عادی خدمات فروشگاه‌های داخلی خوب به نظر می‌رسد، اما وقتی به واقعیت‌های آن‌ها می‌پردازیم می‌بینیم که فرصت‌های خوبی برای پول به جیب زدن‌های خیلی خوشگل فراهم شده است که هرچند برای فراهم سازی بستر آن باید زحمت کشید و پول خرج کرد... اما در ازای چه خدماتی چه چیزی به دست می‌آورند؟ وقتی به خدماتی قرار است پولی پرداخت شود، آن سرویس باید بدون هیچ دغدغه و مشکلات مادی و معنوی قابل استفاده باشد. با توجه به عدم شفاف سازی کاربران که دلیل آن را نداشتن دانش فنی می‌دانند. از جانب بعضی از توسعه‌دهندگان و فروشگاه‌های ایرانی ترجیح داده‌شده است که، خدمات ارائه شود اما با دریافت هزینه! کافی است یک حساب کتاب ساده انجام دهید، وقتی شما قرار است توسعه‌دهندهٔ اپل باشید باید هزینهٔ سالیانه آن را پرداخت کنید که چیزی حدود ۹۰ تا ۱۲۰ دلار بسته به مالیات متغیر است. و اگر قرار است امضاء از نوع سازمانی داشته باشید باید هزینه‌ای معادل ۲۹۹ دلار برای آن بپردازید که در نهایت هر ۱۰ الی ۲۰ روز یک بار هزینه نزدیک به ۳ میلیون تومان برای خرید اکانت تجاری باید تقدیم کنید! در قبال آن به دست آوردن برخی از فروشگاه‌ها مانند سیب‌اپ هزینه‌‌ی حداقل ۳۰،۰۰۰ تومان را بابت آن دریافت می‌کنند. به گفتهٔ خودشان تعداد کاربران میلیونی... با پرداخت چنین هزینه‌هایی معادل صد‌ها شاید هم هزاران و میلیون‌ها برابر آن را به دست خواهند آورد!!! فرصت خوبی برای راه‌اندازی کسب‌و‌کار و به قول قدیمی‌ها (ماهی گرفتن از آب گل‌آلود) است نه! البته فروشگاه‌هایی هم وجود دارند که با روش‌های PWA ادعای به اشتراک گذاری اپلیکیشن‌ها را دارند که از اشاره به نسخه وب بودن و محدودیت‌های آن دریغ می‌کنند. اخیراً هم که با حقه‌بازی‌های هرچه تمام هزینه‌های چند برابری با وعده‌های دروغین به مردم خدمات می‌دهند که شخصاً با خرید حساب ۱ ساله بعد از ۳ ماه دوباره از ما پول خواستن! حالا که در جریان واقعیت قرار گرفته‌اید، بهتر است خودتان قضاوت کنید (چرا که به عنوان یک برنامه‌نویس این ننگ است که بدانیم اما به زبان نیاوریم که چه چیزی به خُرد ملت می‌دهیم). آیندهٔ نرم‌افزار‌های iOS ایرانی چطور خواهد شد؟ شما کاربران عزیز باید در نظر داشته باشید که هیچ روش رسمی و قانونی به جز مواردی که اشاره شده است وجود ندارد، مشخص نیست با این وضعیت چه بلایی به بازار اپلیکیشن‌های ایرانی در پلتفرم iOS خواهد آمد، اما با توجه به مسائل سیاسی که دولت ایالات متحدهٔ آمریکا اعمال کرده است و تمامی تحریم‌های بانکی و ... از قبل گریبان گیر ما شده است کمی بعید است بدون حل مسائل سیاسی این دو کشور به این راحتی ها بتوان راه حل‌های دائمی و مطمئن معرفی کرد. بنابراین، باید منتظر ماند تا دید آیا نظر اپل در این بهانه تراشی‌ها تغییر خواهد کرد یا خیر! البته بر اساس نظرات کارشناسی برخی از حقوق‌دان‌ها و سیاست‌مداران اینطور عنوان می‌شود که شرکت‌ها بعضاً مجبور هستند بر خلاف میل خود طبق دستورات دولت خودشان اقدام کنند. در نهایت، باید منتظر ماند و دید که آیا حتی با پذیرفتن هزینه‌های بسیار بالا و رعایت قوانین کامل اپل باز هم اقدام به مسدود کردن برنامه‌های ایرانی خواهد کرد یا خیر. هدف از این مقاله این است که با چشمان باز حقیقت پنهاد در پشت این مسائل را بدانید.

سلام، افزونه‌ی Qt در Visual Studio تنها امکان توسعه‌ی برنامه‌های تحت کیوت رو در محیط ویژوال استودیو می‌دهد (بنابراین هماهنگی کامل با فناوری‌های اختصاصی کیوت را نخواهد داشت). در صورتی که شما کامپایلر و تنظیمات qmake یا cmake را برای پلتفرم‌های مورد نظر به درستی تنظیم کنید می‌تونید خروجی مناسب را تهیه کنید. دقت کنید که برای iOS و Linux شما باید روی پلتفرم‌های مک و لینوکس خروجی بگیرید. برای iOS و macOS بهترین روش همین هست که شما در پلتفرم مربوط به خودشون کامپایل کنید. حتی برای لینوکس هم بهتره از همین روش استفاده کنید (هرچند به کمک روش کراس کامپایل می‌تونید خروجی بگیرید). سعی کنید از استاندارد‌ها و رابط‌های خاص ویندوز استفاده نکنید، سعی کنید استاندارد‌های هر پلتفرم رو برای خودش اعمال و تحت چهارچوب و قوانین کیوت طراحی و توسعه انجام بدین. در این صورت بدون دردسر‌های متداول می‌تونید برنامه‌ی خودتون رو برای پلتفرم مقصد خروجی و اجرا کنید. این بخش هم مقالات و آموزش‌های مناسبی موجود هستند که پیشنهاد می‌کنم بررسی بفرمایید.

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

اولین پلتفرم آموزشی چند منظورهٔ بومی اگر شما به دنبال فراگیری مهارت خاصی در زندگی خود هستید، فانوکس بستر مناسبی برای شما است؛ نام فانوکس الهام گرفته از فانوس دریایی است که نماد پیدا کردن مسیر و نور راهنما تا رسیدن به مقصد می‌باشد. هدف : آموزش و یادگیری هوشمند در هر زمان و هر جا برای بهبود زندگی و کسب و کار این تاپیک برای این منظور ایجاد شده است که پروژه معرفی و بازخورد‌های آن در این بخش اعلام و اصلاح شوند. بنابراین تمامی دوستان و علاقه‌مندانی که بازخورد‌هایی برای آن دارند می‌توانند در این بخش آن را اعلام کنند تا به کمک هم آن را اصلاح و توسعه دهیم. نکته: نسخهٔ ریلیز شده ویژگی ثبت خطاها را دارد که به شما اجازه می‌دهد کد و پیغام خطا را کپی و در اختیار ما قرار دهید. بنابراین شرط جاری روی مُد User و فلگ‌های Info، Warning، Failed و Critical نیز تنظیم شده‌اند که می‌توانید در صورت مشاهده آن‌ها را تقسیم بندی کنید. if(DeveloperMode::IsEnable) { Logger::LoggerModel = Logger::Mode::User; Log("Log Message : " + Event , LoggerType::Info); Log("Log Message : " + Event , LoggerType::Warning); Log("Log Message : " + Event , LoggerType::Failed); Log("Log Message : " + Event , LoggerType::Critical); } پیش اطلاعات فنی انجین : سِل Cell رابط کاربری: JavaScript، QML و فناوری Qt Quick کتابخانه‌ها : STL, OpenSSL, Curl و Qt سمت سرور: Php7.2 و MySQLi MariaDB (در آینده همین بخش رو هم احتمالاً با ++C توسعه بدم). رابط‌های برنامه‌نویسی: Restful Api v.1.0 در قالب JSon نسخهٔ فعلی: ۰.۵ آلفا پلتفرم‌های پشتیبانی دسکتاپ : Windows, macOS, Linux پلتفرم‌های پشتیبانی موبایل و تبلت : iOS, Android, iPadOS معرفی در آی‌او‌استریم نسخهٔ فعلی توسعه یافته : ۰.۵.۳۴۳.۰ ریلیز شده در سه حالت Normal, OpenGLEs و Software Mode هدف از این روش ریلیز این هست که سیستم‌هایی که دارای کارت گرافیکی ضعیف‌تر و یا بدون نصب کارت گرافیک و درایور آن هستند را تحت پوشش دهیم، بنابراین نسخهٔ Software Mode تنها مناسب برای سیستم‌های اداری و مشابه آن هستند که عموماً خبری از کارت گرافیکی و یا درایور‌های نصب شده بر روی آن‌ها نیست ? دوستان توجه داشته باشند که برای بازخورد‌ها و اعلام نظرات توسعه حتماً از مُد اجرای برنامه‌ٔ خودشون و نوع سیستم‌عامل و شرایط سخت‌افزاریشون مطلع باشند تا بتونیم به درستی مشکلات احتمالی را حل کنیم. در ادامه بعد از نظر نسخهٔ آلفا شروع به بررسی و حل مشکلات احتمالی در مسیر توسعه خواهیم کرد.