I have an idea to write a program that modifies the behavior of text fields on Linux. What I want is that the program will automatically change the text entry language according to the textfield's text direction in all the system. For example, if I have English and Hebrew languages installed, and I click on a textfield in some software that normally outputs the text from right to left, than the program will automatically change the text entry language to Hebrew. If I click on a text field that outputs text from left to right, the program will switch the language to English.
I don't know much about system or UI programming on Linux, ( More experienced on Windows ) and I don't know where to start. Is there a way to register 'hooks' on GUI elements on Gnome and KDE? Maybe I should add this to Gnome and KDE's code?
I'd appreciate any hints as to how to start.
Many thanks,
Oded.
First some caveats:
Normally text field alignment for GUI windowing toolkits is either explicitly set by the program or is set based on the detected system locale (in Qt and GTK at least) either in relevant Text Object QLineEdit in Qt or GtkEntry in GTK or in the higher level Layout Object that contains them.
That said in order to implement the functionality at least for your own programs, you will need to identify a few things
GTK or Qt or both ? If you are implementing at base level (i.e not just bindings), then this also means C or C++ or both ?
GTK 2 or GTK 3, QT 3 or QT4 ?
Which text widgets on each GUI toolkit to you want to override ? Just the two I mentioned I above or any or all of the possible text widgets in either library ?
Do you want your behavior to work regardless of the locale set ? E.g If you have LTR locale set do you want right aligned text widgets to switch input method ?
What method of switching input method do you want to use ? SCIM, XIM, ibus or just immodule (in both its GTK and Qt forms) ? Do these input methods support being programatically changed ??
What happens if a user has 2 or more LTR languages installed or 2 more RTL languages installed ? Do they get to pick which language ? Is there current locale setting respected ?
Assuming you want to go down the immodule path
See the following resources for Qt
How to support input method in KDE/Qt application.
QInputMethodEvent Class Reference. You will want to implement this event, and the get Text widget's alignment using an alignment accessor, then set the Input Method based on alignment.
See the following resources for GTK
GtkIMContext
GtkIMContextSimple
GtkIMMulticontext
The general method is the same.
Implement the event handler for when text is typed into the widget but before it is displayed in the widget.
Switch the input method based on the widget's alignment property
Resources on learning GTK
GTK 3 Reference Manual
GTK 2 Reference Manual
Gnome Developer Centre
Resources on learning QT
QT Reference Documentation
Qt4 tutorial for absolute beginners
The Qt4 tutorial
From your comment, it seems you would be instead be writing your own InputMethod mechanism or modifying an existing one.
In order to have it loaded by default in Gnome and KDE programs not difficult to do, just set your input method based on locale association. The difficult part is having the InputMethod aware of location it is being typed into. Normally the InputMethod isn't aware of the calling application, let alone the GUI framework it is written in.
Resources on Input Methods
List of input methods for UNIX platforms
Linux input method framework brief summary
ibus
uim
scim
Related
I am working on an MBCS app using MFC. I am trying to support Asian languages. For the purposes of this discussion, we'll say I'm trying to support Chinese. I am able to support Pop up dialogs via MessageBoxW and Dialog SCREENs by pasting Chinese characters directly into the RC file. I can't get file menus to work using either resource view or editing the RC file directly. Whenever I type in ANY Asian character, the screen shows ???. One ? for each character. I have tried modifying the menu in C++ using ModifyMenuW. I get more question marks. Visual Studio shows everything working, and the RC file is unicode (UTF-16). I can't easily convert my project to unicode mode. Spanish, French, and German all works fine (one of the Essets in German doesn't work, but that isn't a show stopper). What should I try next?
Thanks in advance!
Well, the easy answer would be change the application to Unicode, but this is not always simple, or possible at all.
Concerning using Unicode in a MBCS application, some things are possible and some others not. For example, I have made a MBCS application displaying and editing translations of program strings (messages, menues etc) in a ListView control, however ListView does have a specific message to turn it to Unicode (LVM_SETUNICODEFORMAT) and support operations (see also CCM_SETUNICODEFORMAT). Menus aren't controls though, but they do have "wide" (Unicode) functions.
If you want to use Unicode in your application, there are some tests you need to make. Success is not guaranteeded, but you can at least draw some conclusions and determine whether what you want to do is possible.
Test1:
You mentioned trying ModifyMenuW(), but this will try to modify an existing menu. Instead, try InsertMenuW() or InsertMenuItemW(). Any unicode string should be displayed properly, so try not just Chinese, but other laguages too (eg Greek or Russian). And btw, I can't see how French works and German doesn't (they use the same codepage - West European). What's the system codepage of your test-machine?
Test2: (if the above has failed)
Try changing the whole menu (SetMenu()) with having a single (unicode) menu item as its root.
Test3: (if the above have failed)
Then you need to check whether the window containing the menu must be Unicode. Create a simple "Hello World" Win32 application, or find a sample, if Visual Studio does not do this for you (these basically register the window class, create the main window and start the message-loop) - you must add a menu too, using the "wide" version of the menu functions explicitly. If this doesn't work, try changing the code that creates the window to unicode. This way you will know whether you need a unicode window, to own the menu.
Please make these tests and let us know the results. I will further post if needed.
In Linux, one can use xwininfo to get the location of a window. Is that possible to get the location of it's component, e.g. the content area of a browser, the button of a window? -children option of xwininfo can only get the location of children windows, not components.
My understanding is that modern toolkits (like GTK+, Qt) do not necessarily back every component with an X11 window, but I find it hard to find a definite source for this claim. If the components, or widgets, are not backed by X11 windows, xwininfo will not be able to determine their location.
For example, GTK+ used to interpret the environment variable GDK_NATIVE_WINDOWS to mean that every GdkWindow (corresponding to every widget) should have a native window, but this was only for compatability with some applications that would not work otherwise. This feature has since been removed (https://mail.gnome.org/archives/commits-list/2011-March/msg03590.html). Gtk+/Gdk now has gtk_ensure_native_window(), but if not enabled explicitly by the programmer, it seems that Gdk will not back the widgets by X11 windows and therefore xwininfo will not be able to pick up the location of these.
It seems that there may be alternatives for specific toolkits though. For example, GTK+ has gtkparasite which might be able to give you the information on specific components, but this will only work for GTK+ applications.
I'm coding a demon like program from Gambas on Ubuntu 13.10.
This is a GUI application which becomes visible when the user hits specific key.
Therefore, I don't want this program to appear on the task bar.
Is there a way I can bypass it? (Maybe from a Bash trick or a Gambas code?)
Thanks! :)
You need to add _NET_WM_STATE_SKIP_TASKBAR atom to _NET_WM_STATE - see 'Application window properties' part of emwh spec.
I don't know at all gambas, but what you want is the following for gtk (in python):
window.set_property("skip-taskbar-hint", True)
or for QT:
setWindowFlags(QtCore.Qt.SplashScreen)
basically, you need to find a way to change the properties or flags for the windows you want to display. Look at the API of the windows in gambas
is there a function / class in wxwidgets that allows me to find out what keyboard layouts are installed and then change them?
I looked through the documentation and came across wxLanguage and wxKeyboardstate, but they don'T seem to be the answer.
No. This is done using the standard system-global methods and wxWidgets doesn't provide access to it. FWIW wxLanguage is only used to select the locale to use and you can also retrieve the default user language, but not the keyboard layout.
We have a midlet that needs to allow the user to switch input languages on the fly (its a dictionary type app) between several languages (say English to Arabic etc). All was charming in the "old days" with the numeric keypad, we handled the input ourselves matching 2 clicks on the 5 to feed the correct char to our program. Then came the E71 out, it has a qwerty keyboard and in our canvas KeyPressed we get the character the user pressed, say "a" on the keyboard,
now the task of matching this to the correct language (say the user is now searching for the Arabic to English side of the dictionary) involves the task of matching "a" (on the qwerty layout I guess) to the arabic letter that would come out if the layout was arabic.
There is a special keyboard shortcut in these S60 devices (varies between devices) that allows the user to pop the input language selector (function + space in the case of E71) but these does not seem to work when our midlet is running.
another suggested solution was to somehow use an editable textfield for the input in which case a standard support for changing the input language is offered by the jvm, however we render a canvas (a nice looking one) and replacing this with a textfield is a last resort for us.
So, the question we have is what other solution can someone think of to tackle this issue?
or if anyone found a way around this annoyance?
best regards,
--tzurs
I think you can do the mapping using the Nokia specific system properties for keypad settings. Using com.nokia.keyboard.type, com.nokia.key.scancode and com.nokia.key.modifier you should be able to create a generic enough solution for Nokia devices.
More info on these system properties available on Nokia docs