(Almost?) all of the material in the Web regarding PyGTK localization is discussing usage of gettext - i.e., how to properly show the translated strings.
But that's not enough... There are certain languages (Hebrew, Arabic and more) that are written from Right To Left, and therefore, the widgets should be 'swapped'. Packing 'Start' should be at the rightmost, and continue to the left.
I assume that locale.setlocale(locale.LC_ALL, '') should solve the problem.
However, it didn't work (on Hebrew Windows 7 machine).
Here is a sample code, that tries to change the locale to Hebrew and displays 2 buttons - but they are still from Left To Right:
import gtk
import locale
locale.setlocale(locale.LC_ALL, 'Hebrew_Israel.1255')
print locale.setlocale(locale.LC_ALL)
window = gtk.Window(gtk.WINDOW_TOPLEVEL)
window.connect("destroy", lambda w: gtk.main_quit())
box1 = gtk.HBox(False, 0)
window.add(box1)
button1 = gtk.Button("first")
box1.pack_start(button1, True, True, 0)
button2 = gtk.Button("second")
box1.pack_start(button2, True, True, 0)
window.show_all()
gtk.main()
gtk.widget_set_default_direction(gtk.TEXT_DIR_RTL)
This sets the default direction for widgets that don't call set_direction.
Related
In Delphi 10.4 Sydney, if you select a comment, for example //xxx and then press press { on your keyboard, the editor will automatically replace the selected text/comment with {//xxx}.
The expected behavior would be to have only { on the screen, instead of {//xxx}.
How do I stop this behavior?
I disabled all my IDE experts, so this must be from the IDE itself.
This is a general feature not related to comments.
If you have anything selected and type an opening bracket like ( or {, you will automatically surround the selection with this bracket. For instance, if you select cat and type (, you will end up with (cat).
This can be particularly annoying when the IDE helps you with an if statement: If you type if and then a space, the IDE automatically inserts if True then with True selected. If you then type ( (for instance, if you want to type (a = 1) and (b = 4)), you will end up with if (True) then, and not if ( then.
To disable this feature, go to Tools, Options, User Interface, Editor Options, Key Mappings, Enhancement modules and deselect Smart Surround Keys:
I'm using C++Builder 10.3 with a VCL application for Windows. I'm trying to identify a specific item in an AdvPopupMenu by looping through the Items Caption and comparing the Caption to my search text using CompareText(). The Captions have an '&' in the Caption text which I believe is part of the ShortCut feature. This seems to prevent a match when comparing the text.
I have tried setting up the menu items two ways to try and remove the '&'.
//--#1 Menu Setup--
TMenuItem *NewMenuItem;
NewMenuItem = new TMenuItem(MainForm->AdvPopupMenu1);
TShortCut sc2;
sc2 = TextToShortCut("(None)");
NewMenuItem->Caption = "Google";
NewMenuItem->ShortCut = sc2;
//--#2 Menu Setup--
TMenuItem *NewMenuItem;
NewMenuItem = new TMenuItem(MainForm->AdvPopupMenu1);
NewMenuItem->Caption = "Google";
NewMenuItem->ShortCut = NULL;
Below is my loop to search for the AdvPopupMenu item.
UnicodeString SearchFor = "Google";
UnicodeString TestCaption;
for(int i=0; i<MainForm->AdvPopupMenu1->Items->Count; i++){
TestCaption= MainForm->AdvPopupMenu1->Items->Items[i]->Caption;
if(CompareText(SearchFor , TestCaption)==0 ){
//This CompareText always fails
//TestCaption looks like this "&Google" or this "G&oogle"
}
}
How can I setup the AdvPopupMenu Caption to contain no '&' and make the CompareText work?
The &s are important. Without these, keyboard users like myself will find your application more difficult to use.
I think your best solution is to use the StripHotkey function in the Vcl.Menus unit to remove the ampersand character before you pass the caption to CompareText. (In addition, instead of testing if CompareText returns 0, it's better to use the SameText function.)
That is, don't attempt to create the menu items without the ampersand character, and don't try to remove it from the menu items. Only remove the character from the string you pass to the comparison function.
Also notice that the ampersand character is not related to the ShortCut property. The ampersand character makes the next character underlined in the menu item caption, telling the user than he or she can press that key to activate the menu item, but only when the menu is open. On the other hand, the ShortCut property adds a right-aligned text like Ctrl+A or Shift+Ctrl+N or F2 to the menu item, and these shortcuts are available even when the menu isn't open. Hence, these are different features.
In awesome 4.0, is there a way to only display the titlebar on floating windows?
Looking at the docs, there doesn't seem to be an option out of the box.
To specify; I'm looking for a solution that work when I dynamically switch windows between tiling and floating.
A bit late, but I wanted to do this too and I got it mostly working. It doesn't cover all the cases when you'd expect a client to show or hide its titlebar, but it's close enough for my use case.
It's rather simple, first you need to disable titlebars for every client, so add titlebars_enabled = false in the properties of the default rule matching all clients.
Then, when a client becomes floating you need to toggle on his titlebar, and toggle it off when it stops floating.
I wrote this little helper function to make the code clearer. It's rather simple, if s is true then show the bar, hide it otherwise. But there's a catch, in our case the windows never had a titlebar so it isn't created yet. We send the signal to have one built for us if the current one is empty.
-- Toggle titlebar on or off depending on s. Creates titlebar if it doesn't exist
local function setTitlebar(client, s)
if s then
if client.titlebar == nil then
client:emit_signal("request::titlebars", "rules", {})
end
awful.titlebar.show(client)
else
awful.titlebar.hide(client)
end
end
Now we can hook the property change:
--Toggle titlebar on floating status change
client.connect_signal("property::floating", function(c)
setTitlebar(c, c.floating)
end)
But that only applies to clients that changes states after being created. We need a hook for new clients that are born floating or in a floating tag:
-- Hook called when a client spawns
client.connect_signal("manage", function(c)
setTitlebar(c, c.floating or c.first_tag.layout == awful.layout.suit.floating)
end)
And finally, if the current layout is floating, clients don't have the floating property set, so we need to add a hook for layout changes to add the tittlebars on clients inside.
-- Show titlebars on tags with the floating layout
tag.connect_signal("property::layout", function(t)
-- New to Lua ?
-- pairs iterates on the table and return a key value pair
-- I don't need the key here, so I put _ to ignore it
for _, c in pairs(t:clients()) do
if t.layout == awful.layout.suit.floating then
setTitlebar(c, true)
else
setTitlebar(c, false)
end
end
end)
I didn't want to spend to much time on this so it doesn't cover cases where a client gets tagged in a floating layout, or when a client is tagged multiple times and one of those tag is floating.
Change
{ rule_any = {type = { "normal", "dialog" }
}, properties = { titlebars_enabled = true }
},
to
{ rule_any = {type = { "dialog" }
}, properties = { titlebars_enabled = true }
},
Niverton's solution works very well for simply switching from tiling to floating modes; however, floating windows will lose their titlebar when maximized and then unmaximized. To fix this, a better solution would be to replace
client.connect_signal("property::floating", function(c)
setTitlebar(c, c.floating)
end)
with
client.connect_signal("property::floating", function(c)
setTitlebar(c, c.floating or c.first_tag and c.first_tag.layout.name == "floating")
end)
This should fix the issue so that windows can be properly maximized without having to switch to tiling mode and back to get the titlebars again.
I found this general idea on a reddit post about the subject, provided by u/Ham5andw1ch. I have just simplified the code using Niverton's proposed function and some short-circuit logic.
I try add my own characters in keyboard.
I expand key 'z' by code to "Keyboard-en.plist":
"Roman-Accent-z" = {
Keycaps = "z mylongstringtitle ..."; // ... == \U017e \U017a \U017c characters ('z' with apostrophes and dots)
Strings = "z mylongstringvalue ...";
};
But keyboard not shown my string 'mylongstringtitle', only blank space ' ':
I can add only string 4 chars length on normal font and 7 chars on small font on 'button'. But I need add a long string.
Can I add 'mylongstringtitle' inside keycaps's string? May be I need set special parameters for long string? This is possible?
I don't think you will be able to add long string to be displayed in keyboard-en.plist. I believe the limitations of 4/7chars that you discovered are hard-coded in desire to avoid disfigured popup.
This keyboard behavior is not supported by Apple (it's not documented on http://developer.apple.com, or http://devforums.apple.com). Use of this feature in your app, therefore, is undefined behavior, which is considered programmer error.
That said, it's a neat feature. The limits of 4 and 7 characters for keycaps are hardcoded on iOS. I can't find them in any of the keyboard plists. You'd probably have to modify the keyboard binary to do what you want. (On OS X, on the other hand, this limit does not exist.)
A few alternatives exist, which you might know about:
You could modify this custom keyboard project
You could assign a custom inputView to be displayed at the top of the system keyboard
I'm working on an addon for World of Warcraft that completely overhauls the interface to adapt to my play style.
In this addon, I would like to have a large button that acts as a "main dps rotation" for my mage. I would like it to change what spell it casts based on what is optimal at any given time. It doesn't cast the spell automatically, it just presents the next best option for the user.
Here is my code so far:
print "Interface Overhaul : LOADED"
heatingUpIsActive = false
print(heatingUpIsActive)
local Button = CreateFrame("Button", "MyButton", UIParent,"SecureActionButtonTemplate")
Button:SetWidth(256)
Button:SetHeight(256)
Button:SetFrameStrata("HIGH")
Button:SetPoint("LEFT")
Button:SetText("Main Rotation")
Button:RegisterForClicks("AnyUp")
Button:SetAttribute("type", "spell")
Button:SetAttribute("spell", "Fireball")
Button:RegisterEvent("UNIT_AURA");
local function auraGained(self, event, ...)
if (UnitAura("player", "Heating Up")) then
if (heatingUpIsActive == false) then
heatingUpIsActive = true
print (heatingUpIsActive)
print ("Heating Up is active!")
Button:SetAttribute("spell", "Inferno Blast")
end
else
heatingUpIsActive = false
print("Heating Up is NOT active.")
print(heatingUpIsActive)
end
end
Button:SetScript("OnEvent", auraGained);
local tex = Button:CreateTexture("ARTWORK");
tex:SetPoint("LEFT")
tex:SetWidth(256)
tex:SetHeight(256)
tex:SetTexture("Interface\\AddOns\\InterfaceOverhaul\\Button2")
If heatingUpIsActive == true, I would like the button to cast ("spell", "Inferno Blast") instead of ("spell", "Fireball"), but it doesn't work if I place that into the correct part of the if statements.
Any thoughts?
As Mud said, you cannot rebind buttons in combat anymore. Blizzard made this change to prevent bots from being able to automate combat. Notably, in order to cast a spell you need to use one of the secure templates, and these secure templates only allow modification of the attributes that control what they do when you're not in combat. So you cannot have one button change spells mid-combat. Similarly, they also prevent you from modifying attributes like their position or visibility, so you cannot move buttons under the mouse either.
The best you can do is display a visual indicator of what spell should be cast, but rely on the user to actually press the correct button.