Response to what is significant self sacrifice obligatory

When is significant self sacrifice obligatory?

One day, I happened to donate a small sum of money at a cash register for a particular then active charity.

No sooner had I walked out of the grocery with stores in tote, then having in the parking lot crossed a sum of the same amount on the ground.

There could be many interpretations of this I imagined.

To this extent, I remember having read in another context someone having said to the effect of another's charity: why do or give if you have animosity doing so?
Transcending a bit the abstracts of passion to social justice, there is something of a personal statement concerning direct involvement in active charitable work, and maybe this is very true: what help could you be to yourself and others, if having eroded the charity that you sought to provide?  Is 'sacrifice' an obligation as in duty, as in not having some other desired life relative to another path 'sacrificially' chosen?

Returning to the abstract,
As to the effect of charity,  it seems behaviour is much complex here.  What profit might be had of charity that could be utilised in so many ways?  Much in line with the article above, it seems that even in the efforts of organisations themselves, however, large, diverse, and responsive to any number of circumstances are neither entirely holistic to condition of any and every plight when it has arisen.   How much time and attention should be devoted?  Maybe some consider any effort enough, while others would claim so much could be done significantly reduce or remove a condition in a society?  And if resources are finite and limited what suitable balance should exist in so far as donation of time and monies?

When any number of problems have emerged or have existed simultaneously, how are resources used in addressing these?  Does any one charity resource sufficiently provide address to all?  And how does one intelligently make decision as to what priority in addressing should exist?  Maybe obligatory and thoughtless donations could be ill served?


 

Notes on Cairo set_source_rgb and set_source_rgba

Noticed three channel values (all non zero) seem to produce a value (255, 255, 255) color which is white.  However two channel values appear to produce their designated colour.   At this point recommend when setting colors that these are done on a two channel basis, i.e., assign no more then two non zero values at any set_sourc_rgb or set_source_rgba call, at a time.

for example, the following arbitrary values should work:
(r,g,b)
(255, 255, 0 ), (178, 89,0), (0, 178, 31), (67, 0, 43), and so forth

but the following doesn't work

(244, 34, 32), (111, 23, 11), and so forth

Python gtk 3+ pango cairo example

from gi.repository import Gtk, Gdk, cairo, Pango, PangoCairo
import math
import sys


RADIUS = 150
N_WORDS = 10
FONT = "Sans Bold 27"

class Squareset(Gtk.DrawingArea):
    def __init__ (self, upper=9, text=''):
##        Gtk.Widget.__init__(self)
        Gtk.DrawingArea.__init__(self)
        self.set_size_request (200, 200)
##        self.show_all()  

    def do_draw_cb(self, widget, cr):
        # The do_draw_cb is called when the widget is asked to draw itself
        # with the 'draw' as opposed to old function 'expose event' 
        # Remember that this will be called a lot of times, so it's usually
        # a good idea to write this code as optimized as it can be, don't
        # Create any resources in here.

          cr.translate ( RADIUS, RADIUS)
        
          layout = PangoCairo.create_layout (cr)
          layout.set_text("Text", -1)
          desc = Pango.font_description_from_string (FONT)
          layout.set_font_description( desc)
##          desc.free()
          rangec = range(0, N_WORDS)
          for i in rangec:
            
              width, height = 0,0
              angle = (360. * i) / N_WORDS;
              red =0.0
              cr.save ()
##              #/* Gradient from red at angle == 60 to blue at angle == 240 */
              red   = (1 + math.cos ((angle - 60) * math.pi / 180.)) / 2
              cr.set_source_rgb ( red, 0, 1.0 - red)
              cr.rotate ( angle * math.pi / 180.)
              #/* Inform Pango to re-layout the text with the new transformation */
              PangoCairo.update_layout (cr, layout)
              width, height = layout.get_size()
              cr.move_to ( - (float(width) / 1024.) / 2, - RADIUS)
              PangoCairo.show_layout (cr, layout)
              cr.restore()
              

def destroy(window):
        Gtk.main_quit()

def main():
    window = Gtk.Window()
    window.set_title ("Hello World")
    box = Gtk.Box('Vertical',5)

    app = Squareset()
##    box.pack_start(app,
##                   True,
##                   True,
##                   0)
    window.add(app)
                       
    app.connect('draw', app.do_draw_cb)
    window.connect_after('destroy', destroy)
    window.show_all()
    Gtk.main()
       
if __name__ == "__main__":
    sys.exit(main()) 

Translated C api example to python utilising PangoCairo and Pango libraries.

This draws pango cairo text

Original example in C here 

Python conversion notes between gtk2+ and gtk3+

Some recent tidbits on translations between C and and python languages in so far as gtk libraries.

So far some fairly easy to discern conversions:

Often in python a an object will have a method call which is done so in terms of the convention

gtk.object.method_call

whereas at least in gtk libraries, by c convention,

gtk_object_method_call(object,...)

so if hadn't had a readily provided api, you might be able to guess the method call simply altering syntax here.  Helps also to use the python console to verify existence firstly...as mentioned before a dir(object) call can provide method information alongside additional argument calls for such object.  In c a bit more verbose and redundant then python here with respect to naming conventions on method calls and the applicable class objects to them therein but that's the way it is...

Additionally, some things that I have come across...

type flag objects and the like in the form

gtk.KEYNAME_OBJECTFLAG

need to be converted, not just in gdk libraries.

I believe this were partially (if not fully) mentioned in the conversion process for the C api.

typically something OBJECT might be expressed as

gtk.KEYNAME_OBJECTFLAG

instead, in python the conversion might look like

Gtk.KeyName.OBJECTFLAG

the C api however generally helps in discerning the KeyName class object call.  Ways to find this in the api are:

1.  Probe the method call utilising such flag, the API may provide KeyName
     here even if in gtk2+ it appears differently(truncated or otherwise) relative
     to gtk3+.
2.  In c typically it may be written GtkKeyName (something like
     this anyways)...here you can run the command in python console
     dir(Gtk.KeyName), and you may find a directory of flag objects
     for the given KeyName. 
3.  Obvious the python syntax places a '.' between 'Gtk' and 'KeyName'
     and typically in python possibly converting  '_' to '.'  

generally speaking similarity in method call structures and objects appear to abound cross gtk2+ and gtk3+ libraries, so elsewhere conversion appears fairly straight forward.

As a translating research example I have the following window flag conversion:

w = gtk.Window()
....
w.set_type_hint(gtk.WINDOW_POPUP)

as it turns out we partially have in gtk3+ KeyName provided but not the whole story here and the flag is obtained through a different library altogather, namely, gdk.   How to start here:

1.  we notice the 'w' object is a gtk.Window() object
2.  Then we notice 'set_type_hint'  is a method call on the gtk_window class object
3.  We look up the method call 'set_type_hint' on gtk_window class object in the C api.  where we find that in our look up the following is yielded:

void                gtk_window_set_type_hint            (GtkWindow *window,
                                                         GdkWindowTypeHint hint);

Thus it appears that the argument flag call object for this method in gtk3+ is a
GdkWindwTypeHint object.

At console with Gdk library imported we can call

>> dir(Gdk.WindowTypeHint)

where a list of flags are populated confirming our desired flag.

As it turns out the converted call in gtk3+  is

Gdk.WindowTypeHint.POPUP_MENU

which is the closest equivalent.

py gtk3+ popup qwerty keyboard with caps toggle functionality example

from gi.repository import Gtk, Gdk, GObject

import math


TRACKER_COLORS = [
    (0.0,0.0,1.0), #blue
    (0.0,0.75,0.0), #green
    (0.6,0.0,1.0), #purple
    (1.0,0.5,0), #orange
    (0.5,0.5,0.5), #grey
    (0.6,0.15,0.15), #maroonish
    (0,0.3,0.0), #dark green
    (0,0,0.5), #dark blue
    (0.5,0.35,0.1), #muddy
    (0.5,0.25,0), #dark orange
    ]

def Gtkcolor_to_rgb (c):
    return c.red/float(2**16),c.green/float(2**16),c.blue/float(2**16)

def overlay (color_1, color_2, method=1):
    return color_1[0]+color_2[0]*method,color_1[1]+color_2[1]*method,color_1[2]+color_2[2]*method

ERROR_HIGHLIGHT_COLOR = (1.0,0,0)

BASE_SIZE = 35 # The "normal" size of a box (in pixels)

BORDER_WIDTH = 9.0 # The size of space we leave for a box

BORDER_LINE_WIDTH = 4 # The size of the line we draw around a selected box

LITTLE_LINE_WIDTH = 0.25
NORMAL_LINE_WIDTH = 1 # The size of the line we draw around a box

SPACING_FACTOR = 40 # The size of a box compared (roughly) to the size
                    # of padding -- the larger this is, the smaller
                    # the spaces
SMALL_TO_BIG_FACTOR = 3 # The number of times wider than a small line a big line is.

LATIN_QWERTY_TH_LOWER = {1:'q',2:'w',3:'e',4:'r',5:'t', 6:'y', 7:'u',
                           8: 'i', 9:'o', 10:'p'}
LATIN_QWERTY_TM_LOWER = {1:'a', 2:'s', 3:'d', 4:'f', 5:'g', 6:'h',
                           7:'j', 8:'k', 9:'l'}
LATIN_QWERTY_TL_LOWER = {1:'z', 2:'x', 3: 'c', 4:'v', 5:'b', 6:'n',
                         7:'m', 8:'ABC'}
LATIN_QWERTY_TH_UPPER = {1:'Q',2:'W',3:'E',4:'R',5:'T', 6:'Y', 7:'U',
                           8: 'I', 9:'O', 10:'P'}
LATIN_QWERTY_TM_UPPER = {1:'A', 2:'S', 3:'D', 4:'F', 5:'G', 6:'H',
                           7:'J', 8:'K', 9:'L'}
LATIN_QWERTY_TL_UPPER = {1:'Z', 2:'X', 3: 'C', 4:'V', 5:'B', 6:'N',
                         7:'M', 8:'abc'}
LATIN_QKEY_LOWER = {1: LATIN_QWERTY_TH_LOWER, 2: LATIN_QWERTY_TM_LOWER,
                    3: LATIN_QWERTY_TL_LOWER}
LATIN_QKEY_UPPER = {1: LATIN_QWERTY_TH_UPPER, 2: LATIN_QWERTY_TM_UPPER,
                    3: LATIN_QWERTY_TL_UPPER}

class NumberSelector (Gtk.EventBox):

    __gsignals__ = {
        'changed':(GObject.SIGNAL_RUN_LAST,GObject.TYPE_NONE,()),
        }

    def modifykeys(self):
        if self.caseflg:
            Key_Layout = LATIN_QKEY_UPPER
        else:
            Key_Layout = LATIN_QKEY_LOWER
        for y in Key_Layout:
            for x in Key_Layout[y]:
                b = self.bdict[(y,x)]
                b.set_label(Key_Layout[y][x])
                
                self.bdict[(y,x)] = b
        self.show_all()        
                

    def setkeys(self):
        if self.caseflg:
            Key_Layout = LATIN_QKEY_UPPER
        else:
            Key_Layout = LATIN_QKEY_LOWER
            
        self.bdict = {}
        for y in Key_Layout:
            for x in Key_Layout[y]:
                b = Gtk.Button()
                l = Gtk.Label()
                if Key_Layout[y][x]==self.value:
                    l.set_markup('%s'%Key_Layout[y][x])
                else:
                    l.set_markup('%s'%Key_Layout[y][x])
                b.add(l)
                b.set_relief(Gtk.ReliefStyle.HALF)
                l = b.get_children()[0]
                b.set_border_width(0)
                l.set_padding(0,0)
                l.get_alignment()
                b.connect('clicked',self.alpha_clicked, (y,x))
                self.table.attach(b,x,x+1,y,y+1)
                self.bdict[(y,x)] = b
               
        
    
    def __init__ (self,default=None,upper=9):
        self.caseflg = 0
        self.value = default
        Gtk.EventBox.__init__(self)
        self.table = Gtk.Table()
        self.add(self.table)
        self.setkeys()

        self.connect('key-release-event',self.key_press_cb)
        self.show_all()

    def key_press_cb (self, w, e):
        txt = Gdk.keyval_name(e.keyval)
        if txt.isalpha():
            self.value = txt
            self.emit('changed')
        else:
            self.emit('changed')

    def alpha_clicked (self, button, val):
        
        if self.caseflg:
            Key_Layout = LATIN_QKEY_UPPER
            y,x = val
            aval = Key_Layout[y][x]
            
            
        else:
            Key_Layout = LATIN_QKEY_LOWER                
            y,x = val
            aval = Key_Layout[y][x]
                    
        
        if not aval == 'ABC' and not aval == 'abc':
            self.value = aval
            self.emit('changed')
                
      
        else:
            if aval == 'ABC':
                self.caseflg = 1
                self.modifykeys()
            else:
                self.caseflg = 0 
                self.modifykeys()
                
    def get_value (self):
        return self.value

    def set_value (self,val):
        self.value = val


w = Gtk.Window()
w.set_app_paintable(True)
w.set_type_hint(Gdk.WindowTypeHint.POPUP_MENU)
w.set_decorated(False)
ns = NumberSelector()
def number_changed_cb (b):
    w.destroy()
    print('value:', ns.get_value())
    Gtk.main_quit()

ns.connect('changed',number_changed_cb)
w.grab_focus()
w.connect('focus-out-event',lambda *args: w.destroy())

w.add(ns)
w.show_all()
        
Gtk.main()
r = w.get_allocation()

w.show()      

This is a pop up window for a QWERTY keyboard using latest gtk3+ libraries in python.  Albeit has resizing issues initially when toggling caps, this provides a structural framework for on screen pop up keyboard (e.g., something that might be similarly used in tablet based apps).

 

Concern with the truth of an idea as presented by the one to offer it, neither necessarily reveals any more truth of such idea nor diminishes it.

I would offer this on a point of logic.

python gtk 3+ example implementing cairo drawn object

from gi.repository import Gtk, GdkPixbuf, Gdk
import os, sys
import math



class GUI:
    def draw_callback(guiobj, widget, cr):
            def MIN(x, y):
                if x < y:
                    return x
                else:
                    return y
               
        width = 100
        height = 100
       
        ##cr = Gdk.cairo_create()
##        width = widget.get_allocation().x
##        height = widget.get_allocation().y
        cr.arc (
                 width / 2.0, height / 2.0,
                 MIN (width, height) / 2.0,
                 0, 2 * math.pi)

        stylecontext = widget.get_style_context()                
        color = stylecontext.get_color (0)
        cr.set_source_rgba (0.5, 0.5, 0.5)
       
        cr.fill()
                
        return FALSE
       
       
    def __init__(self):
       
            window = Gtk.Window()
            window.set_title ("Hello World")
            box = Gtk.Box('Vertical',5)
           
            self.drawing_area = Gtk.DrawingArea()
            self.drawing_area.set_size_request (100, 100)
            box.pack_start(self.drawing_area,
                           True,
                           True,
                           0)
           
            self.button = Gtk.Button('Hello')
            box.pack_start(self.button,
                           True, True, 0)
            window.add(box)
                       
            self.drawing_area.connect('draw', self.draw_callback)
            window.connect_after('destroy', self.destroy)


            window.show_all()

    def destroy(window, self):
            Gtk.main_quit()

def main():
    app = GUI()
    Gtk.main()
       
if __name__ == "__main__":
    sys.exit(main())

So I managed to translate a gtk3+ example into python calls,
this is done outside graphic ide builder (e.g., Glade or visual Anjuta),
 here I've managed to use for a drawn graphic context using Cairo, to implement via a Drawing Area widget object.  Since in gtk3+ 'expose event' has been removed for drawing in this widget, instead a drawing event can be handled using a 'draw' event handler.  The function 'draw_callback' implements as in the gtk3+ example a pythonic version here.   Automatically this event sends three arguments to the draw_callback function in the named ordering at the event functions header declaration....note a bit different here relative to c gtk structure.  'cr' designates the automatically created 'cairo context' which is later used to draw cairo based objects...although I hadn't fully implemented as in the example, either grabbing the width height of the drawing area object widget, or the color return from the widget's style context...this should be a three tuple rgb assignment in order to set this properly with a python based cairo function call.

Original c code example here