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 <[email protected]> Sendt: 10. november 2015 11:58 Til: Gustavsen Richard; [email protected] 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 <[email protected]> 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 <[email protected]> > Sendt: 10. november 2015 09:43 > Til: Gustavsen Richard; [email protected] > 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 > <[email protected]> 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 <[email protected]> på vegne av Robert >> Iakobashvili <[email protected]> >> Sendt: 10. november 2015 06:49 >> Til: [email protected] >> 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 [email protected] http://lists.qt-project.org/mailman/listinfo/interest
