I'm trying to write a kiosk GUI in ruby/gtk on ubuntu. I'm pretty fluent in ruby, but new to writing GUIs and not great with linux.
I'm using a touch screen, and am using our own images for buttons, e.g.
button_image = Gtk::Image.new(Gdk::Pixbuff.new "images/button_image.png")
#button = Gtk::Button.new
#button.add(button_image)
#button.set_relief(Gtk::RELIEF_NONE)
My issue is that when the buttons are pressed or remain selected (or hovered over, although this is less relevant with a touch screen), gtk shows fat, square borders around them. Obviously it's applying gtk's prelight / selected / active lighting to the buttons. I've tried changing the button properties in various ways, and also tryied hacking apart my theme, and while I can modify how the highlighting looks, I can't seem to completely get rid of it. Changing the color of the highlight via my theme is easy, but if I remove my setting there's still a default I can't get rid of.
Does anyone know if there's a way to stop it, or possibly make it transparent? Thanks in advance!
Sounds like you want to use exactly your image for the whole button, instead of putting an image inside the normal GtkButton - but still use all the normal behavior of the button.
The easiest way to do this is to just override the drawing. If you are on gtk2, connect to the "expose-event" signal, do your drawing there, and return true so that the default handler doesn't get run. If you are on gtk3, connect to the "draw" signal and do the same.
I tried meddling with the drawing as Federico suggested, but found that the most direct way to address this was instead to use an event box rather than a button. Event boxes accept clicks just like buttons, but don't respond to selecting, hovering, etc. In ruby, the code looks like this:
image = Gtk::Image.new("myfile.png")
event_box = Gtk::EventBox.new.add(image)
event_box.visible_window = false
event_box.signal_connect("button_press_event") do
puts "Clicked."
end
Most of this is exactly like a button; the *visible_window* method, obviously, keeps the event box from being visible under the button image.
Related
I'm trying to handle background color properly in a dynamically generated property sheet in dynamically generated property pages in win32 api using MFC (though I expect my question is general, and not restricted to MFC, but since my code and examples use it, it's germane to my question anyway).
So we have a:
CPropertySheet
containing multiple
CPropertyPage
I generate the contents of any given page dynamically - from file resources using a custom dialog definition language - all irrelevant other than to say - a list of controls and their coordinates is created within a given page, and the page is resized to accommodate them. This logic is working beautifully.
However, what doesn't work is that the controls and background of each page draws using the dialog default color/brush.
I've tried a number of ways to attempt to force it to draw using the white color/brush that a hard-coded property sheet / page would.
There are two important pieces to this:
Page Background
Control (on the page) background
For #1, I've tried:
acquire the background brush from parent window class (it's dialog bkgrd) (same is true if I do this and ask the tab control)
change the property page to use WS_EX_TRANSPARENT (PreCreateWindow is not called by the framework when generating a page viz PropertySheet::AddPage)
For #2, I've tried:
overriding OnWndMsg / WM_CTLCOLORSTATIC to forward that request to (A) the parent (sheet), and (B) to the tab control (which is what wants the white in the first place).
However, anytime I use any of the above "ask for the background / forward the request" up the chain to either the sheet or the tab control - I get the dialog background color, never the white I'd expect.
Using Spy64, I can see that for a fully hardcoded property sheet / page - that the only discernable differences I can see is that the dialog window created in AddPage (or its moral equivalent) has WS_CHILD instead of mine which has WS_POPUP (the rest of the styles appear to be the same, such as WS_VISIBLE|DS_3DLOOK|DS_FIXEDSYS|DS_SETFONT|DS_CONTROL and WS_EX_CONTROLPARENT.
So, other than the WS_CHILD, I see no significant differences from what I'm creating and from another property sheet that works properly from a standard resource (i.e. hard coded).
I'm also flummoxed as to how this works normally anyway - since forwarding things like the ctrlcolor message doesn't respond correctly - and asking for the windows background colors similar doesn't - then how is it in a standard case the background colors of controls and pages comes out as white, and not dialog background?
Any ideas or help would be appreciated - I'm kind of running out of ideas...
When Visual Styles were added in Windows XP they really wanted to show off this new feature so they made the tab background a gradient (really a stretched image) instead of a single color and this caused problems in old applications that did custom drawing with the dialog brush as the background.
Because of this, only applications with a comctl32 v6 manifest got the new look but there was a problem; old propertysheet shell extensions would load in new applications (including Explorer) and things would look wrong.
To work around this they also require you (or your UI framework) to call EnableThemeDialogTexture(.., ETDT_ENABLETAB) to get the correct tab page look.
As if things are not tricky enough, there is a undocumented requirement that you also need a button or a static control on the page!
If you have custom controls they have to call DrawThemeParentBackground when you draw if they are partially transparent.
Turns out my old code had defined an ON_WM_ERASEBKGND handler - and removing that (and all of my above attempts) makes it work.
So simply doing NOTHING is the correct answer. D'oh!!!
I'm leaving my shame here in case someone else trips on this! [Whoops!]
(Still interested if anyone has deeper insight into how this mechanism works under the hood)
I'm trying to create a program that creates three buttons on the right side of the screen.
When I press a button, the entire background will change color (each button will make the background a different color). Whenever the mouse is not pressed, the background will return to white. I'm having trouble understanding how to make the three rectangles into buttons.
THIS MUST BE DONE WITHOUT A SPECIAL BUTTON METHOD/LIBRARY
You need to break your problem down into smaller pieces.
Can you create a program that just shows a single button? Don't even worry about making it interactive yet. Just show a single button at hard-coded coordinates.
Now can you detect when the user clicks in that button? Just print something to the console. Get that working perfectly before moving on.
Now can you get multiple buttons working together? Again, just print somethign to the console, and make sure it works perfectly before moving on.
Finally, can you make it so pressing each button changes the background instead of printing something to the console?
If you get stuck on a specific step, you can post a MCVE along with a specific technical question. Stack Overflow really isn't designed for general "how do I do this" type questions. It's for specific "I tried X, expected Y, but got Z instead" type questions. So please try something and post an MCVE of a specific step you're stuck on. Good luck.
Check processing's documentation for mouseClicked() and mousePressed.
The former being a method called upon a click, and the later is a boolean that is constantly updated. (So you'd check for it in your draw())
You'd then want to check the mouseX and mouseY values to see if they are in your desired button's area. (Which would be displayed on screen using rect())
I'm using AutoIt to try and make a little hotkey application to work with Windows Journal so I can quickly select different colors.
It seems I'm very close and yet very far to getting the desired result. I've used the AutoIt tool to find the CommandID of the toolbar and the ID of the colors. Here is my code:
ControlCommand("[CLASS:JournalApp]","",113,"SendCommandID", 40178)
My problem is that the color will not be selected. It will be selected to the degree that the color will have the "selection" brackets around it, but the color that I draw with will still be the last color I've selected.
So I tried messing around and found that this code:
ControlCommand("[CLASS:JournalApp]","",113,"Check","")
It will indeed select the color, but it will only select the light blue color. I don't know why, but that is the color that is always being selected. I have not found a way to combine the selecting ability of "SendCommandID" with the checking ability of "Check"
Also, it is a ToolbarWin32 Control.
I figured it out myself.
Here's what I've learned:
ControlCommand("[CLASS:JournalApp]","",113,"Check","")
Has a serious weakness in that it there is no way to specify which button will be checked. At first it seemed to be random, but after a while of playing around I noticed that it did it at a specific coordinate relative to the client window. Why? I have no idea. But at least it's not random.
ControlCommand("[CLASS:JournalApp]","",113,"SendCommandID", 40178)
Has a weakness in that, while on the surface it appears to have successfully clicked the button. The button's function is not actually executed. For my specific circumstance, the color of the pen did not change after I used this, though it appeared to click on the button.
Here's my solution(s):
I looked around and found that AutoIt has a library specifically for dealing with ToolBarWin32 Classes. This is the library from GuiToolbar.au3. With this I found that I was able to do a few things. One, was that I could send clicks to the buttons and change the state of the buttons even. I found that changing the state of the buttons did nothing in relation to triggering an event and the clicking worked, but it had the weakness that it caused the mouse to flinch. This did not work because my pen was near my tablet as that has priority of mouse movement. So I had to raise my pen away from my tablet in order to use the hotkeys--not very convenient. Here was my code for that solution:
if WinActive("[CLASS:JournalApp]") Then
WinActivate("[CLASS:ToolbarWindow32; INSTANCE:2]", "")
$cmdId = "401"&$hotKeys[$key-1+$shift]
If $cmdId < 40172 or $cmdId > 40188 Then
Return
EndIf
$hWnd = ControlGetHandle("[CLASS:JournalApp]", "", 113)
_GUICtrlToolbar_ClickButton($hWnd, $cmdId)
EndIf
What I found after was that AutoIt's native ControlClick() was a lot more useful in that it didn't cause the mouse to flinch whatsoever. It triggered the mouseclick event directly. So that in combination with a nice command from the toolbar library made for a much cleaner solution. Here it is:
if WinActive("[CLASS:JournalApp]") Then
WinActivate("[CLASS:ToolbarWindow32; INSTANCE:2]", "")
$cmdId = "401"&$hotKeys[$key-1+$shift]
If $cmdId < 40172 or $cmdId > 40188 Then
Return
EndIf
ConsoleWrite($hotKeys[$key-1])
$hWnd = ControlGetHandle("[CLASS:JournalApp]", "", 113)
;get the coords of the button and control send a click
local $btnCoords= _GUICtrlToolbar_GetButtonRect($hWnd, $cmdId)
ControlClick("[CLASS:JournalApp]", "", "[CLASS:ToolbarWindow32; INSTANCE:2]","left",1,$btnCoords[0]+2,$btnCoords[1]+2)
EndIf
I'm writing a Silverlight+XNA game and when the user has something in their clipboard they can see less of the screen. I'd really like to be able to not show this clipbaord but I can't see any way (though it does seem to go away after some amount of time)
I've tried an empty string and Clipboard.SetText(null) but that throws an exception.
Unfortunately, there is no way to either clear the clipboard from code or influence the display of the SIP beyond setting an InputScope.
The best you can do for now is to update your design to allow for the amount of space which the SIP may use. :(
While more complicated, you could create your own text input keys as buttons, and instead of using a textbox, use buttons templated to look like textblocks, with background as you show above, and all... When the user taps the "button" that is a "textblock", you set a flag that says which textblock the keypad buttons send their numbers to.
Or, if the only spot you are sending inputs to (as it appears now that I look at your UI again), there is no need for the button template as the input space, or the flag. Just create buttons for user to tap for input, and send that input to the textblock that appears to be where your answer is. You could make the buttons whatever size you want, that way, as well, so you control how much of the screen is visible. Another thing you could do is make the buttons semi-transparent, so you could have even more background image showing.
Another thought - send the buttons all to the same event handler (except the backspace button), and have the code for that event handler look like this:
{
Button btn = sender as Button;
textblock.Text += btn.Content;
}
I'm making a simple Qt application. It has 4 screens/pages:
Start import
Select folder to import images to
Accept or reject each image in folder, and when no images left:
"No images left" and an OK button.
I can't figure out the best way to implement this. I started off with a QWidget, but this quickly got unmanageable.
Is a QWizard too constrained?
EDIT: Part of the problem with QWizard is it seems to always have "Back" and "Next" buttons. I don't want those as options in this program, so this leads me to believe that a wizard isn't exactly what I'm after.
I'm going to disagree slightly on using a QWizard here. It would be fairly easy to do, but in this case I think it might be easier to just use a QStackedWidget and swap the widget shown based on what you want the user to be able to do. This is likely what is done inside QWizard anyway, without some of the complication for running the buttons and moving back and forth. You also might want to take a look at the state machine stuff they're looking at adding soon, since you're application could so easily be split into states.
I think a QWizardPage is your best bet.
You can disable the 'back' on a QWizardPage by using setCommitPage(True) on it.
You'll also have to override nextId for the 'variable' amount of QWizardPages you want in between step 2 and 4.
here (basic) and here are examples of QWizards.
You can make QWizardPages for your screens and add them to a QWizard. With registerField() you can register fields to communicate between pages.
EDIT:
I didn't test this, but i guess you can control the button layout of QWizard with
setButtonLayout
Create a dialog with a "Start Import" button on top. When the user clicks this:
Populate a QFormLayout :
The layout should have a checkbox and the label is the name of the picture to import. I'm not sure of your requirements, but you could also display a thumbnail of the image.
The user just checks the images he wants.
Then at the bottom have a "Save..." button. When the user clicks this, a Save As dialog appears. You save all the checked images, discard the others.
If there are no images, change the "Save..." button text to "OK", and display a QLabel with the "No images left" string. You can switch between the QLabel and QFormLayout using a QStackedWidget.
Checkout this article on QFormLayout: http://doc.trolltech.com/qq/qq25-formlayout.html
Option: Get rid of the "Start Import" button. Have the app automatically populate the QFormLayout on startup (possibly in constructor if its fast enough).