In general, it's reasonable to let an app decide how to form the Edit Menu and what to include.
If doing a native development to the best of my knowledge, you can get rid from standard menu items: https://developer.apple.com/library/ios/documentation/StringsTextFonts/Conceptual/TextAndWebiPhoneOS/AddingCustomEditMenuItems/AddingCustomEditMenuItems.html Why not to let Qt-developers such useful option via API? I'd believe that hardware keys settings should not enforce Edit Menu Items. Yes, indeed, your investigation would be very much appreciated. Thank you in advance! Regards, Robert On Tue, Nov 10, 2015 at 5:02 PM, Gustavsen Richard <richard.gustav...@theqtcompany.com> wrote: > Currently the logic is so that if the current focus object in Qt supports > text input (Qt::ImEnabled), then the platform plugin will inform iOS that > cut/copy/paste actions are supported. iOS will then add extra items in the > edit menu, extra buttons on the virtual keyboard (unless you apply your > work-around), and send callbacks to Qt when pressing shortcut keys on a > bluetooth keyboard. And currently I cannot think of any work-arounds you can > do to hinder that (except remove input focus / close the keyboard before > showing the menu). > > I can investigate a bit if it's reasonable to dynamically inform iOS that we > don't support e.g copy while opening an edit menu that has no items with > QKeySequence::Copy included. > > -Richard > > ________________________________________ > Fra: Robert Iakobashvili <corobe...@gmail.com> > Sendt: 10. november 2015 11:58 > Til: Gustavsen Richard; interest@qt-project.org > Emne: Re: [Interest] Qt at iOS: Crash on null QWindow pointer in > QIOSInputContext::scrollToCursor > > Dear Richard, > To get rid from Keyboard Shotcuts Bar with Cut/Copy/Paste is rather easy, > I'm using the below that works in 4.2 as well as in 5.5.1: > > 1. Disable predictive input in the window/text-field; > 2. Pass the view/window/text-field as Wid (widget->winId()) to the > function below and disable two vectors/groups of UITextInputAssistantItem-s > > void disable_iOS9_keyboard_shortcut_bar(void* window) > { > if (SYSTEM_VERSION_GREATER_THAN_OR_EQUAL_TO(@"9.0")) { > UIView* view = (UIView*)window; // You can also iterate thru > subviews if required. > if ([view respondsToSelector:@selector(inputAssistantItem)]) { > UITextInputAssistantItem *inputAssistantItem = [view > inputAssistantItem]; > inputAssistantItem.leadingBarButtonGroups = @[]; > inputAssistantItem.trailingBarButtonGroups = @[]; > } > } > } > > My question was about QPlatformMenu. > When doing the below: > > QPlatformTheme *theme = QGuiApplicationPrivate::platformTheme(); > QPlatformMenu *menu = theme->createPlatformMenu(); > menu->setMenuType(QPlatformMenu::EditMenu); > > QPlatformMenuItem *item = theme->createPlatformMenuItem(); > item->setText(QLatin1String("MyCoolItem")); > menu->insertMenuItem(item, 0); > > menu->showPopup(qApp->focusWindow(), QRect(100, 100, 0, 0), 0); > > > In Qt-5.4 it works properly and the menu seen has only "MyCoolItem" > > In Qt-5.5 adds various standard Apple's standard items like > Cut, Copy, Paste, Speak, etc depending on area. > > How to get rid of various standard Apple's menu items? > > Thank you in advance. > > Kind regards, > Robert > > > On Tue, Nov 10, 2015 at 12:26 PM, Gustavsen Richard > <richard.gustav...@theqtcompany.com> wrote: >> Hi! >> >> If it's the cut/copy/paste actions you mean, it's problematic to remove them >> fully, since we don't really know if the application needs them or not. If >> we did, then support for e.g cmd-c on a bluetooth keyboard (or copy button >> on the virtual keyboard), would be removed as well. >> >> But after https://codereview.qt-project.org/#/c/124596/ we check if the >> application adds any actions with short-cut bindings to >> QKeySequence::StandardKey explicit (e.g QKeySequence::Copy). If so, we link >> the action directly to the corresponding native iOS menu item, including the >> button / shortcut on the keyboard. >> >> -Richard >> >> ________________________________________ >> Fra: Robert Iakobashvili <corobe...@gmail.com> >> Sendt: 10. november 2015 09:43 >> Til: Gustavsen Richard; interest@qt-project.org >> Emne: Re: [Interest] Qt at iOS: Crash on null QWindow pointer in >> QIOSInputContext::scrollToCursor >> >> Hi Richard, >> >> I was using 5.4.2, and I see that it was fixed for 5.5 >> >> Unfortunately, in Qt-5.5 QPlatformMenu adds Apple's standard >> MenuItems prior to my custom item, so I cannot >> make my custom Editing Menu without Apple's standard; >> this is the reason to continue with 5.4 >> >> Can we get rid from Apple's Menu Items in QPlatformMenu with Qt-5.5.1? >> Thanks! >> >> Regards, >> Robert >> >> >> On Tue, Nov 10, 2015 at 10:27 AM, Gustavsen Richard >> <richard.gustav...@theqtcompany.com> wrote: >>> Which version on Qt are you using? It looks like this was fixed in 5.5: >>> >>> https://codereview.qt-project.org/#/c/109592/ >>> >>> >>> -Richard >>> >>> >>> ________________________________ >>> Fra: Interest <interest-boun...@qt-project.org> på vegne av Robert >>> Iakobashvili <corobe...@gmail.com> >>> Sendt: 10. november 2015 06:49 >>> Til: interest@qt-project.org >>> Emne: [Interest] Qt at iOS: Crash on null QWindow pointer in >>> QIOSInputContext::scrollToCursor >>> >>> Gentlemen, >>> My app was crashing on a null QWindow pointer >>> from focusView() in QIOSInputContext::scrollToCursor >>> >>> Unfortunately, my attempt to create a reproducing example >>> failed; thus, a formal bug-report is not an option. >>> >>> The scenario is: >>> sending an email from a native popover over a Qt-widget app, >>> it was crashing on appearance of >>> Apple's Mail window. >>> >>> It could be work-arounded by checking the result of >>> focusView() call prior to using it and not assuming that >>> it for sure contains a valid QWindow: >>> >>> --- qiosinputcontext.mm.orig 2015-11-02 14:39:50.000000000 +0200 >>> +++ qiosinputcontext.mm 2015-11-02 14:45:43.000000000 +0200 >>> @@ -456,7 +456,10 @@ >>> >>> const int margin = 20; >>> QRectF translatedCursorPos = qApp->inputMethod()->cursorRectangle(); >>> - >>> translatedCursorPos.translate(focusView().qwindow->geometry().topLeft()); >>> + QWindow* qw = focusView().qwindow; >>> + if (! qw) >>> + return; >>> + translatedCursorPos.translate(qw->geometry().topLeft()); >>> >>> qreal keyboardY = [rootView convertRect:m_keyboardState.keyboardEndRect >>> fromView:nil].origin.y; >>> int statusBarY = qGuiApp->primaryScreen()->availableGeometry().y(); >>> >>> >>> Hope, it helps to somebody. >>> >>> Take care, >>> >>> Regards, >>> Robert _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
