I need to only handle mouse up and mouse down on images to replace those images with other images.
I am using eventbox right now but it seems like it might be overkill. Is there a lightweight alternative?
I imagine I could wrap the entire widget collection I'm using(sorta like a toolbar) and then do my own hit testing. Is there an easier way? Does gtk have some helper routines built in?
Obviously the hit testing is not difficult but just curious, as it's still a bit of extra plumbing that I might not need to re-implement? Or maybe eventbox is pretty lightweight?
Related
So I have seen a few of these scripts in unity and I am wondering how I can recreate it in my own scripts?
So I have a script the when a object is clicked, it will call a function on another script. I want to be able to pass arguments and much more but the Inspector got messy with a bunch of toggles, int fields etc.
Is there any way to recreate this sort of thing?
Not as much the Event type but the little function box instead. If that makes sense :)
Thanks!
The box you showed in that screenshot is an Event Trigger. There isn't any way that I know of that lets you separate the UI object from this underlying type. So there isn't a way to just draw the delegate box.. However, you can make a class based off of EventTrigger and then you can extend EventSystemEditor.
You can also make a class derived from UnityEvent in this fashion and it will show up with a function delegate box the way you wanted it to.
However, again, that just won't get you a drawing method that draws the function/delegate box for you. I don't know of a single way of getting Unity3D to let you do that.
You can check the entire list of GUI drawing methods:
https://docs.unity3d.com/ScriptReference/EditorGUILayout.html
https://docs.unity3d.com/ScriptReference/EditorGUI.html
But it's just not there.
I know that some people have managed to achieve similar effects with Inspector wizardy, recreating a similar aspect and functionality. I know FullInspector can do delegates in its inspector and you could check its source code to figure out how, but it could end up being a lot of work. Specifically serializing the delegate is hellish, so if you want it to serialize, I wouldn't even bother. I suggest finding a different path of minimal resistance.
Here's an alternative:
You can collect the methods in the class you're targeting via reflection and present them in a dropdown menu. Then once a method is selected you can again use reflection to see what parameters that method requires and use GUI functions to draw the appropriate fields required to receive those parameters from user input.
It's definitely possible, but again, I think that will take quite a lot of time to elaborate and you're better off finding a way of satisfying your requirements without this level of Editor GUI shenanigans.
I am working on a game using GTK3 as a rendering technique (terrible idea, but it's a school project).
My gameobjects are made of Image widgets and are placed in a Fixed container. It's working pretty well, however when i move widgets beoynd right or bottom border, the window automatically grows along with it.
I want the window to stay at the sam size, event if widget leaves its area and becomes invisible. It works when i move widget past the upper or left border.
I tried using gtk_widget_set_vexpand and gtk_widget_set_hexpand. My window is set as not resizable (gtk_window_set_resizable).
Is there any way I can achieve this?
This isn't the right way to use GTK+. GTK+ is intended for laying out widgets in a GUI program.
There are better options for animating 2D elements. One that works with GTK+ natively is the Clutter library. You can also integrate SDL or OpenGL or something like that if you so choose.
That being said, you can also use GtkLayout instead of GtkFixed, or put the GtkFixed in a GtkScrolledWindow and hide the scrollbars and set the scroll policy to prevent scrolling. It's still technically misuse, and in fact GtkFixed (and possibly GtkLayout too but the docs don't say) is really not supposed to be used anymore unless absolutely necessary because it doesn't give you automatic support for tricky UI layout problems, but it doesn't have extra dependencies.
I've implemented a musical keyboard as a subclass of Fixed and where each individual key is a subclass of DrawingArea, and so far, it works great: custom drawing code in expose, press+release functionality working... kind of. See, here's the problem: I want the user to be able to drag the mouse across the keyboard with the mouse down to play it. I currently capture the button press and release signals, as well as enter and leave notify. Unfortunately, this doesn't quite work because the widget seems to grab focus of the mouse as soon as the mouse is pressed over it. This makes sense for normal buttons, but not for a musical keyboard. Is there any good way to remedy this other than rewriting the entire keyboard to be one massive DrawingArea?
Also, it shouldn't matter, but in case it does I'm using GTK#.
You might consider using GooCanvas: You can represent each of the keys as CanvasPolylines, fill them with the colors you need. Each of the Canvas items is a GtkWidget, so you can act on events like enter, leave, button-pressed etc.
This method seems to make more sense (to me) than separate DrawingAreas. As each drawn element is still accessible, you can even change colors/size and other properties dynamically. Also, Polyline lets you make more complex shapes.
I've written a simple Scrabble game with a simple Bot and Human part which can interact using consolebased I/O. Although there is already a Qt based overview of the current situation in the game: A simple custom QWidget which simply paints everything. No interaction or anything fancy yet.
(source: b52 at reaktor42.de)
My problem is that I would like to remove the consolebased interaction and switch to a new Drag'n'Drop based approach, but I'm not that familiar with PyQt and GUI development in general.
Therefor my question is, what would be a good way to go? Creating custom Layouts for Board and Rack and custom Letter Widget which would be dragable?
Thanks in advance
Oli
That looks pretty good! If you need to actually move things around on the screen using the mouse, I think the Graphics View Framework would be a better way to go than widgets.
All you ios architects out there, please help me choose architecture/technology for the following iphone/ipad app.
The app itself is a financial app, but we want more of a game look-and-feel of the app, so we probably don't want to use the builtin looks of the cocoa widgets. The elements on the screen will probably be some kind of blob-shaped images.
The app will essentially have five "blob"-shaped areas, spread out evenly across the screen. One of the blobs will be centered and larger than the other ones. Within each blob there will be clickable areas which will pop up "details" and menu-action blobs. These blobs are also graphics objects and must not take over the whole screen. The blobs should animate nicely when popping up. The graphics elements will have a couple of lines of text, which are generated, so the overlaying text itself cannot be part of the static background-image.
The main user interaction will be swiping within the center blob, displaying summaries of the items that are conceptually contained within the blobs underlying data store. Now and then, the user will drag and drop the item to one of the other blobs. While dragging, the item should be traced by a line and when dropping on the other blob, the item should be animated to look like it's being "sucked into" the blob.
Now, what kind of technique would you suggest for this app? Is Cocoa suitable in this scenario? Should I use a game framework like Cocos2D? All kinds of suggestions including example code snippets are most welcome.
I realize that this question might not be as straightforward and to the point as questions generally are on SO, but I hope your answers will come to use by more people than me. Thanks!
EDIT (MY SOLUTION):
I eventually ended up doing everything in UIKit, which was a lot easier than I expected.
Briefly described I used UIButtons with Custom style and an image background, which gave me full control over the visual appearance of the "items". I also found it very useful to manipulate the underlying CALayer of many of my other UIViews. It is often easier than drawing things from scratch using Core Graphics programming.
Another thing that was useful were the UIGestureRecognizer:s. I found them useful for both handling "real" gestures like swiping, longpress etc, but also for handling normal "tap" for UIView classes that aren't subclasses of UIControl. Two examples are UIImage, UILabel and UIView itself. That way I could handle taps for these simple classes. I could for example use a normal UIView, modify it's CALayer to change the look of it completely and still handle taps. Using this technique, I didn't have to subclass any views at all in my app.
The animations were pretty easy too, even though I had to use a non-public method to use "suck" animation, so my app will never pass App Store moderation. It was just a prototype anyway so I don't care.
When this app will be for real, I will probably implement it in HTML5/JavaScript wrapped by Phonegap. The reason for this is mainly reuse of existing mobile web services and also for code reuse across platforms. It will probably also be easier to hook into the existing security solution when using a webapp.
Cocos2d is great if you need to move elements around really fast as it is a layer on top of OpenGLES. I think from what you have said the UIKit will be fine, you get nice animation support, you can do some nice things with UIScrollViews to handle moving elements around etc.
If you need more detailed graphics support and lots of moving elements, particle effects etc then by all means go for Cocos2D but be aware that in Cocos2d the application works more on a scheduled update method, i.e. you get notified every 1/60th of a second to move stuff draw stuff etc, whereas with normal UIKit approach it is more event drive, i.e. I click a button and show a view etc.