Some programmers create Window classes:
class PyApp(gtk.Window):
...
I've defined my window with Glade and then i can get it with:
xmlTree.get_widget('window')
Is there a way to use this object as class and extends it? I want to handle it as other programmers do but using my defined window. I don't want to get a class and a window property.
Thank you.
The simplest way I can think of is to use Glade to construct an Alignment laid out with widgets as you would want your window to look. Your class can then be something like:
class PyApp(gtk.Window):
def __init__(self, filename, widget_name):
# Use builder to open filename
...
# and then add the alignment widget:
self.add(builder.get_object(widget_name))
Related
How do I override a widget in order to provide some custom modifications to one of its property.
For example: Let's say I want to create my own Text widget which will convert whole text to uppercase. I'll do something like:
class MyOwnText extends Text {
MyOwnText(String data) : super(data.toUpperCase());
}
But with this approach, I can't use other properties of Text in my own widget, style, for example. For that, I'll have to add style property in my class constructor like this:
MyOwnText(String data, {TextStyle style}) : super(data.toUpperCase(), style: style);
But Text has got around 12-13 properties, and just to override one, I need to define all of those properties and then their assertion. I'm sure I may not be doing something right. Can anyone please help?
Note: Neither I want to use extension methods nor some client side code. MyOwnText should be a Text.
I get what you wanted to achieve, but I do not recommend to do this.
Why?? - Because most of the class has private variable and they have their separate getter and setter which are expose to the outer front of the class.
Again, If you wanted to for design and func. then you should not extend the widget. Instead you can directly use those in your build method
Why?? - You can't inherit more than one class(Mixin is other way around here)
So ultimately you need to assign properties directly or you could use spread operator
I have trouble getting custom widgets to work in Glade. Let's say I have a custom widget consisting of a stack in a frame.
class FramedStack(Gtk.Misc):
def __init__(self):
self.frame = Gtk.Frame()
self.stack = Gtk.Stack()
self.frame.add(self.stack)
I can add this to the Glade catalogue and it works fine. But now I want to modify the widgets behaviour in Glade. But as soon as I define an adaptor
class FramedStackAdaptor():
def do_post_create(self, w, reason):
pass #something
and modify the line in the catalogue, so that Glade knows about the adaptor
<glade-widget-class title="FramedStack" name="FramedStack" adaptor="FramedStackAdaptor"/>
I get a GladeUI warning
GladeUI-WARNING **: Failed to get FramedStack's adaptor FramedStackAdaptor.
The class definition is in the same file as the definition of the custom widget. I am assuming that FramedStackAdaptor should inherit a Glade Adaptor class, but I can't figure out whether there are such classes. So my question is: How do I correctly define an adaptor for my custom widget?
class FramedStackAdaptor(Gladeui.WidgetAdaptor):
def post_create(w, reason):
pass #something
Should get you started
I started using CoffeeScript today and found myself using a pattern like (args...) => #style(args...) a lot when I needed callback function. The context looks roughly like this:
class Parent
#style: (feature) ->
if feature
#insight()
class Child extends Parent
#insight: ->
alert 'Sara is awesome'
#load: ->
[42].forEach((args...) => #style(args...))
Child.load()
This shows Sara is awesome, which is accurate. If I had only used [42].forEach(#style), style would’ve ended up with a this referring to the parent class (I think?), which doesn’t know insight.
But this is very verbose, and I need a lot of callback functions in my code. Is there a more elegant, idiomatic way to solve this?
(Using forEach in CoffeeScript is bad style I’ve read, but in my actual code I’m working with various Leaflet functions that I can’t just replace with for loops.)
First thing to noticed is that you shouldn't call insight from the Parent class. The whole purpose of a class is to provide encapsulation. So the first thing I'd do is to move insight to Parent
To answer your question, the more idiomatic way to solve that is using the fat arrow notation. What the fat arrow does internally is to create an anonymous function to enclosure the this.
That said, the final code should look something like this:
class Parent
#style: (feature) =>
if feature
#insight()
#insight: ->
alert 'Sara is awesome'
class Child extends Parent
#load: ->
[42].forEach(#style)
Child.load()
Hope that helps.
EDIT
Based on the OP comment:
class Parent
style: (feature) =>
if feature
#insight()
class Child extends Parent
load: ->
[42].forEach(#style)
insight: ->
alert 'Sara is awesome'
(new Child()).load()
How do I extend /include/SearchForm/SearchForm2.php in upgrade safe manner?
You could create /custom/include/SeachForm/CustomSearchForm2.php which extends SearchForm2 (the class name for SearchForm2) traditionally (e.g. CustomSearchForm2 extends SearchForm). The harder task is accessing your custom class at that point.
SearchForm is instantiated from include/MVC/View/views/view.list.php - in a couple of possible places: the protected method getSearchForm2() and [assumed] public method prepareSearchForm().
So how do you extend view.list.php? That one's easier. For any module you'd like a custom list view, create a file at /custom/modules/MyModule/views/view.list.php and define it as CustomMyModuleViewList extends ViewList. Some modules already have their own ViewList (e.g. Accounts, Calls) so for those you'd want to extend their original extended ViewList, e.g. CustomAccountsViewList extends AccountsViewList.
So create your custom ViewList extension, copy-paste the methods you need to alter (prepareSearchForm and getSearchForm2) and adjust as needed to load in your custom SearchForm class.
Assuming the question relates to SugarCRM 6.5.x (and potentially earlier 6.x versions - I haven't checked), Matthew Poer's answer is exactly right except for one thing: the class to extend is called SearchForm instead of SearchForm2. To do this:
Copy include/SearchForm/SearchForm2.php to custom/include/SearchForm/SearchForm2.php
Edit custom/include/SearchForm/SearchForm2.php and edit the class declaration, changing it to:
require_once('include/SearchForm/SearchForm2.php');
class CustomSearchForm extends SearchForm {
Copy include/MVC/View/views/view.list.php to custom/include/MVC/View/views/view.list.php
Edit custom/include/MVC/View/views/view.list.php and edit the class declaration, changing it to:
require_once('include/MVC/View/views/view.list.php');
class CustomViewList extends ViewList {
In the function prepareSearchForm in the CustomViewList class, change the line
require_once('include/SearchForm/SearchForm2.php');
to
require_once('custom/include/SearchForm/SearchForm2.php');
and the line
$searchMetaData = SearchForm::retrieveSearchDefs($this->module);
to
$searchMetaData = CustomSearchForm::retrieveSearchDefs($this->module);
In the function getSearchForm2 in the CustomViewList class, change the line
return new SearchForm($seed, $module, $action);
to
return new CustomSearchForm($seed, $module, $action);
The other functions of CustomSeachForm and CustomViewList can be subsequently overriden as needed. If you have module-specific view.list.php files, you will, of course, need to change them to extend CustomViewList instead of ViewList.
I've been reading up a bit about coffeescript's inheritance model and I have the feeling I'm on the fringes of an ideological debate which I really don't understand. So, I would be perfectly happy to find out that I'm just doing things in the wrong way.
Basically what I am doing is writing a set of widgets which, among other things, need to handle events on their DOM elements. I thought a good way to go about this would be to have a class method which would be called once, to delegate all the events which the widget might need. The base widget class might have some simple click handlers, while the subclass might add to that some mouseover handlers or extra click handlers.
However, it appears that I'm not supposed to try and do the equivalent of calling super() inside a static method. There is a workaround which exists, (this.__super__.constructor.METHODNAME() but I've seen a lot of suggestions that this isn't the best way to do what I'm trying to do. Has anyone got any insights on how I should structure this code? Keep using the workaround, or put all the delegation into a totally different place? I can't really just stick it in the prototype, since I won't necessarily have an instance to call the method on (or can I essentially still call a method on the prototype from a static context, like putting SwatchableWidget.prototype.delegateEvents() into an onload function or something?
Here's a bit of code to illustrate what I'm talking about:
class Widget
#testProp: "ThemeWidget"
#delegateEvents: ->
console.log "delegate some generic events"
class SwatchableWidget extends Widget
#testProp2 = "SwatchWidget"
#delegateEvents: ->
console.log "delegate some specific swatchable widget events"
this.__super__.constructor.delegateEvents()
Widget.delegateEvents()
SwatchableWidget.delegateEvents()
Thanks for any help.
I suggest replacing
this.__super__.constructor.delegateEvents()
with
Widget.delegateEvents()
trying to use super to call static methods is not required (and doesn't make much sense)
I don't understand why delegateEvents would be a class-level method, or why Widget.delegateEvents have to be called again from SwatchableWidget.delegateEvents. If it's just class initialization code, you should put it in the class body directly:
class Widget
console.log "delegate some generic events"
...
#testProp: "ThemeWidget"
class SwatchableWidget extends Widget
console.log "delegate some specific swatchable widget events"
...
#testProp2 = "SwatchWidget"
I take it you're waiting for a specific DOM state before running this initialization code? Maybe I could suggest another approach if you told me a little bit more about the preconditions for delegateEvents.
It sounds like you want a different type of inheritance model where each inherited function of a certain type ("parent calling") will walk the inheritance tree and call all its parents with the same name.
You could call any direct parent functions in each child manually as you've written. Then it will float up the inheritance chain anywhere you specify such a relationship.
I would bind the parents delegate call in the constructor to a current class function
delegateparents =>
#call any parent class methods