It seems when I call Gdk.Seat.grab() in GJS I get an error:
Gjs-WARNING **: JS ERROR: TypeError: Gdk.Seat.grab is not a function
This function and class is listed in the GJS Docs, but maybe I'm calling it wrong? If I call typeof on Gdk.Seat.grab it comes back undefined. Is this not possible, or is there another way I can grab focus in this way?
My use case is gathering a keybinding from a user, for which I can use Gtk.CellRendererAccel, but I would prefer not to use a Gtk.TreeView. The docs say about CellRenderers that:
These objects are used primarily by the GtkTreeView widget, though they aren’t tied to them in any specific way.
and...
The primary use of a GtkCellRenderer is for drawing a certain graphical elements on a cairo_t.
Which implies I could use it outside of TreeView, but with no hints as to how.
grab() is a method of Gdk.Seat, so you need a Gdk.Seat object to call it on. It looks like you're calling it as a static method, Gdk.Seat.grab(). So, you'll need something like Gdk.DeviceManager.get().get_default_display().get_default_seat() or you can get a Gdk.Seat object from a Gdk.Event.
It's not clear from the described use case what you are trying to do with the grab, but there may be an easier way to accomplish it.
Related
I am trying to call a method of a class that I only know by name as a String. Now therefore I would need a ClassMirror of that class that allowes me to instantiate an instance. However, creating ClassMirrors seems to be only possible by entering a type using reflectClass(Type) or by passing an already existing instance of that class into reflect(dynamic). So these aren`t helping if I only have a String.
In Java you can do this pretty easily, by calling Class.forName(String). Then you would get a Constructor instance, make it accessibly and call it.
Does anyone know if this is even possible in dart? What seems weird is that once you have a ClassMirror you can access fields and methods by passing symbols, which can be created by Strings.
You can put a specific list of strings to map to a specific list of closures to create a new object with specific parameters.
But you can't get a reflection without using dart:mirrors, which is being deprecated, and also had a negative impact on tree shaking to get the payload size down.
In general, you're invited to look at the package:reflectable to achieve most of what you'd want out of dart:mirrors, using source-to-source builders.
I'm creating a wrapper class for an API because my application will need to call it with different credentials at different times. I started off passing the wrapper a method and arguments and then doing (basically) this when calling it
call
set_credentials
TheAPI::Thing.send(method, args)
ensure
reset_credentials_to_default
end
HOWEVER, I realized that a challenge here is if I need to chain methods; this way I can only call one at a time; so for example I wouldn't be able to to TheAPI::Thing.find(id).delete. (At least, not without re-calling the credentials setter, which is undesirable since I have to fetch a token).
Is there a way using ruby to collect the methods/args being chained onto an object? Or would I simply have to pass in some ugly ordered set of things?
EDIT: Surely activerecord's query builder does something like this, collecting the chained methods before returning, and then after they're all collected, ensuring that as a final step the query is built, called, and returned?
the way to do this is to define a proxy object and to pass that around instead of the actual thing.
In the object itself, hold a reference to the Thing and override method_missing: http://ruby-doc.org/core-2.1.0/BasicObject.html#method-i-method_missing
In the method missing do the thing you are doing today. In a nutshell this is what ActiveRecord is doing.
As far as chaining things, I don't believe it would be a problem as methods that can be chained usually return references to self. When you call the 2nd method in the chain, you actually have done the work for the first one and have an object that has the 2nd method in the chain. The only trick you need to pay attention to is that you want to return a reference to the proxy class that encapsulates the thing instead of the actual return of the thing if you want the chaining to succeed.
Give it a shot and ping me if you run into trouble and I can spin up a fully working example.
I'm currently working on a Rails project, and have found times where it's easiest to do
if object.class == Foo
...
else if object.class == Bar
...
else
...
I started doing this in views where I needed to display different objects in different ways, but have found myself using it in other places now, such as in functions that take objects as arguments. I'm not precisely sure why, but I feel like this is not good practice.
If it's not good practice, why so?
If it's totally fine, when are times that one might want to use this specifically?
Thanks!
Not sure why that works for you at all. When you need to test whether object is instance of class Foo you should use
object.is_a? Foo
But it's not a good practice in Ruby anyway. It'd much better to use polymorphism whenever it's possible. For example, if somewhere in the code you can have object of two different classes and you need to display them differently you can define display method in both classes. After that you can call object.display and object will be displayed using method defined in the corresponding class.
Advantage of that approach is that when you need to add support for the third class or a whole bunch of new classes all you'll need to do is define display method in every one of them. But nothing will change in places where you actually using this method.
It's better to express type specific behavior using subtyping.
Let the objects know how they are displays. Create a method Display() and pass all you need from outside as parameter. Let "Foo" know to display foo and "Bar" know how to display bar.
There are many articles on replacing conditionals with polymorphism.
It’s not a good idea for several reasons. One of them is duck typing – once you start explicitly checking for object class in the code, you can no longer simply pass an instance of a different class that conforms to a similar interface as the original object. This makes proxying, mocking and other common design tricks harder. (The point can be also generalized as breaking encapsulation. It can be argued that the object’s class is an implementation detail that you as a consumer should not be interested in. Broken encapsulation ≈ tight coupling ≈ pain.)
Another reason is extensibility. When you have a giant switch over the object type and want to add one more case, you have to alter the switch code. If this code is embedded in a library, for example, the library users can’t simply extend the library’s behaviour without altering the library code. Ideally all behaviour of an object should be a part of the object itself, so that you can add new behaviour just by adding more object types.
If you need to display different objects in a different way, can’t you simply make the drawing code a part of the object?
I've noticed that luasocket doesn't seem to provide a way to know if a value is a luasocket object or not.
The usual approach of comparing metatables doesn't work, as different socket object types have different metatables.
There don't seem to be any consistent values in the metatable to check either (eg, same __tosting metamethods)
So: how can one know if a value they have is a luasocket object?
Since you only want to know if it's a LuaSocket object so you can get the fd, why not just look to see if the object has a getfd() method? As a bonus this will work with current and future libraries that provide this method on objects, not just LuaSocket.
This technique is known as 'duck typing'.
You don't. Generally, you're expected to keep track of that sort of thing yourself. You trust that objects you are passed are what you expect them to be. And if you're not sure, you can always use pcall to call functions on them and catch any errors.
I would like to do coloring in Eclipse without using the presentation reconciler. Therefore, first, I need to figure out how to associate a TextPresentation object with either my editor or document, but I am having difficulty finding out how to link it either of those. Normally, the CreatePresentation in the IPResentationReconciler interface would give the style range to the textpresentation, and from there Eclipse would know what to do with that presentation object. Is there some way to use a TextPresentation object without the use of PresentationReconciler? It would be nice if I could do coloring without the use of reconciler. Thank you.
I finally figured out how to achieve the coloring without the use of Reconcilers.
I discovered that first I needed a way to obtain a reference to my SourceViewer object, as I am extending TextEditor. I also discovered that I could implement the TextListener interface and add my own listener to the SourceViewer object. One must be careful, however, as calling the getSourceViewer() method can result in null if not called at the appropriate spot. Originally, I overwrote the init(...) function in my editor class and made the getSourceViewer() call, but it still resulted in null. After doing a bit of research, I discovered that I could properly obtain a reference to the SourceViewer object by overriding the createPartControl method. I first call super.createPartControl(...) and then make a call to getSourceViewer(). After I obtained that reference, I used that with my listener class I created and was able to do the coloring myself with the setTextColor method the SourceViewer object has. Hope this helps others in the same situation.