Gtk.DrawingArea: Port to python3/gtk3
Hi,
How should I convert this gtk3?
self.area = Gtk.DrawingArea()
#Paints the piano roll (Where the notes are)
def paint_widget(self):
if self.area.window == None:
return
colormap = self.area.get_colormap()
if self.gc_background == None:
color_background = colormap.alloc_color('#FF',
True, True)
self.gc_background = self.area.window.new_gc()
self.gc_background.set_foreground(color_background)
--
Patrick Shirkey
Boost Hardware Ltd
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk apps on iOS/Android?
On Mon, September 10, 2012 3:40 pm, Tristan Van Berkom wrote: > On Mon, Sep 10, 2012 at 3:15 AM, Michael Torrie wrote: >> On 09/07/2012 07:40 AM, Allin Cottrell wrote: >>> I'm contemplating trying to produce a version of my gtk app >>> for tablet use. Can anyone point me to relevant resources or >>> examples? At this point I'm totally clueless about porting to >>> tablets (though I'm able to build my app for OS X OK), and I >>> haven't found googling to be very useful. >> >> Basically you'll want to get a book on developing android apps, download >> the sdk, and go to town. All in Java of course. And using the Android >> UI toolkit. GTK+ is not available on Android or iOS, nor will it likely >> ever be. Use the native toolkits. > > interesting, wouldnt the quartz backend for osx build for iOS ? > > not exactly sure but I think the NSView and highlevel cocoa stuff > is built upon the same low level windowing apis that are available > on osx... > You can compile other languages on android and ios. I'm not sure that anyone has tried to port gtk to android or ios yet. probably inevitable though so if it's your thing than I'm sure you will be able to make something happen. -- Patrick Shirkey Boost Hardware Ltd ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: button background color in gtk3
On Sun, August 26, 2012 1:39 pm, Giuseppe Penone wrote:
> Hi, I faced the same problem some time ago in gtkmm3.
> I asked a question and then replied myself in this post:
> http://stackoverflow.com/questions/8952679/gtkmm-3-button-background-color-change
> You have to use a CSS file (a working example in my code) and import from
> code
> to override the gtk3 theme that you are using on your distribution.
> Cheers,
> Giuseppe.
>
I had a similar problem and it seems that even with Priority = Application
the default theme is overriding "override_background_color()". I would
like to know if this is a bug as I wasted several hours trying to find the
work around and ended up having to use the css method with the applicable
config from the default theme which seems a little excessive when a 1
liner in code should be possible.
>
> On Sun, Aug 26, 2012 at 1:44 PM, Rudra Banerjee
> wrote:
>
>> I will be grateful if someone please show me the way.
>> On Sun, 2012-08-26 at 00:20 +0100, Rudra Banerjee wrote:
>> > Friends,
>> > I am putting gtkbuttons inside a grid with modify_bg. I am getting an
>> > odd case that when the window is focused, all buttons are showing
>> white,
>> > not what suggested by modify_bg. The same structure was working fine
>> in
>> > gtk2 (while I was using table instead of grid).
>> > I am posting the complete minimal code(60 line only) for your
>> reference.
>> >
>> > I have seen that the gtk_widget_modify_bg is deprecated in gtk 3 so I
>> > tried the suggested method with gtk_widget_override_background_color
>> but
>> > there it seems that declaration of GdkColor colorRed2 = {0x,
>> 65535,
>> > 29555, 24158} has changed to something like GdkRGBA.
>> > I tried to change to
>> >
>> > GdkRGBA colorRed = {1,0,0,1};
>> > yeilding error:
>> >
>> > const struct GdkRGBA * but argument is of type GdkRGBA
>> >
>> > Please Help.
>> > here is the complete code:
>> >
>> > #include
>> > int main(int argc,
>> > char *argv[]) {
>> > GtkWidget *window;
>> > GtkWidget *grid;
>> > GtkWidget *menubar;
>> > GtkWidget *filemenu;
>> > GtkWidget *quit;
>> > GtkAccelGroup *accel_group = NULL;
>> >
>> > gtk_init(&argc, &argv);
>> > window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
>> > gtk_window_set_title(GTK_WINDOW(window), "Try Grid");
>> > gtk_container_set_border_width(GTK_CONTAINER(window), 05);
>> >
>> > grid = gtk_grid_new();
>> > gtk_container_add(GTK_CONTAINER(window), grid);
>> > gtk_grid_set_column_homogeneous(GTK_GRID(grid),TRUE);
>> > gtk_grid_set_row_homogeneous(GTK_GRID(grid),TRUE);
>> > menubar = gtk_menu_bar_new();
>> > filemenu = gtk_menu_new();
>> >
>> > accel_group = gtk_accel_group_new();
>> > gtk_window_add_accel_group(GTK_WINDOW(window), accel_group);
>> >
>> > GtkWidget *file = gtk_menu_item_new_with_mnemonic("_File");
>> > quit = gtk_image_menu_item_new_from_stock(GTK_STOCK_QUIT,
>> > accel_group);
>> >
>> > gtk_menu_item_set_submenu(GTK_MENU_ITEM(file), filemenu);
>> > gtk_menu_shell_append(GTK_MENU_SHELL(filemenu), quit);
>> > gtk_menu_shell_append(GTK_MENU_SHELL(menubar), file);
>> >
>> > g_signal_connect(G_OBJECT(quit), "activate",
>> > G_CALLBACK(gtk_main_quit), NULL);
>> >
>> > gtk_grid_attach(GTK_GRID(grid), menubar, 0, 0, 2, 1);
>> >
>> >
>> > /* Color Scheme */
>> > GdkColor colorRed2 = {0x, 65535, 29555, 24158};
>> > GdkColor colorBlue = {0x, 3598, 57054, 61937};
>> > GdkColor colorWht = {0x, 65535, 65535, 65535};
>> >
>> >
>> > GtkWidget *Abutton = gtk_button_new_with_label("A");
>> > gtk_grid_attach(GTK_GRID(grid), Abutton, 0, 1, 1, 1);
>> > gtk_widget_modify_bg(Abutton, GTK_STATE_NORMAL, &colorBlue);
>> > gtk_widget_modify_bg(Abutton, GTK_STATE_PRELIGHT, &colorWht);
>> >
>> > /* Create second button */
>> > GtkWidget *Bbutton = gtk_button_new_with_label("B");
>> > gtk_grid_attach(GTK_GRID(grid), Bbutton, 10, 1, 1, 1);
>> > gtk_widget_modify_bg(Bbutton, GTK_STATE_NORMAL, &colorRed2);
>> > gtk_widget_modify_bg(Bbutton, GTK_STATE_PRELIGHT, &colorWht);
>> >
>> >
>> > gtk_widget_show_all(window);
>> > gtk_main();
>> >
>> > return 0;
>> > }
>> >
>> >
>> > ___
>> > gtk-app-devel-list mailing list
>> > gtk-app-devel-list@gnome.org
>> > https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>>
>>
>> ___
>> gtk-app-devel-list mailing list
>> gtk-app-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
--
Patrick Shirkey
Boost Hardware Ltd
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk3 + python : lookup_widget
On Mon, August 20, 2012 9:16 am, Tristan Van Berkom wrote:
> On Mon, Aug 20, 2012 at 2:32 PM, Patrick Shirkey
> wrote:
>>
>> On Mon, August 20, 2012 6:59 am, Tristan Van Berkom wrote:
>>>The "lookup_widget()" paradigm comes from a very old time when we
>>> had very poor
>>> tools and actually it originates from people using generated code from
>>> the original Glade
>>> tool (Glade versions 1 and 2).
>>>
>>> Ideally, as specially as you are using python, your application should
>>> be modular.
>>>
>>> Perhaps you have an Application object which owns the main widgetry
>>> created
>>> by GtkBuilder after having parsed a Glade file initially, this is
>>> different from a global
>>> variable.
>>>
>>> Ideally you can use you object constructor as an entry point to load
>>> your GtkBuilder
>>> and assign the pointers you need later on to the members you define on
>>> your
>>> Application object.
>>>
>>
>> In this case I am programatically creating the widget.
>>
>>> After that you simply have to pass your Application object to all the
>>> callbacks
>>> which originate from the user interface, giving you access to
>>> everything
>>> you
>>> need when you need it.
>>>
>>
>> This is the part I am having trouble with.
>>
>>> This concept can be further extended to be more modular, for instance
>>> if
>>> you have a preferences dialog/window... it can be defined by a separate
>>> python class/GtkBuilder file and reused at will throughout your
>>> program.
>>>
>>
>> Thanks for your advice. I am planning to make this app as modular as
>> possible but I am finding it hard to find a simple example that deals
>> with
>> my use case.
>
> Look at GTK+ sources: gtkdialog.c for example, or gtkmessagedialog.c even.
>
> Many composite widgets exist in GTK+, all of them follow the same
> construct:
>
>o Create child widgets at initialization time and assign them to your
> private data structure members which you have declared for them
> (in other words, of course you hold a private instance member for
> any composite children you need, like dialog->entry or dialog->label
> or dialog->button etc).
>
> o Connect signals to, for example the button, when doing so..
> supply the dialog (self) instance as user data for the callback
>
> When the callback runs, it receives the dialog as user data, so
> all of the internal composite children are always available in
> those callbacks.
>
> In theory, in this 'dialog' example, normally all composite children
> are private to the dialog and the dialog has some kind of output
> or modifies your program state in some way, so no user of the
> dialog should ever have to access those internal widget members
> and the dialog can change internally without breaking any API.
>
> So in the context where "the dialog" handles a callback for any
> signal originating from one of it's instance members, it always
> has the dialog in context so it can always access any member
> of the dialog.
>
Do you know of a python example of this concept? I have the signals part
under control and I am ok with python classes but I'm a bit murky on how
to pass the commands back to the object.
I have seen an examples where a class exposed a function that pulled in
the dynamic variable which is updated when the signal is sent/received.
But I can't figure out how to adjust widgets that are defined outside of
the class. For example in the code below how would the label be accessed
by the "MyWidget" class if it is defined in the PyApp class?
i.e
from gi.repository import Gtk, Gdk
import cairo
class MyWidget(Gtk.DrawingArea):
def __init__(self, parent):
self.par = parent
super(MyWidget, self).__init__()
self.connect("draw", self.expose)
def expose(self, widget, event):
self.variable = self.par.get_cur_value()
label.text = variable
class PyApp(Gtk.Window):
def __init__(self):
super(PyApp, self).__init__()
self.cur_value = 0
mywidget = MyWidget
label = Gtk.Label()
def on_changed(self, widget):
self.cur_value = widget.get_value()
self.mywidget.queue_draw()
def get_cur_value(self):
return self.cur_value
PyApp()
Gtk.main()
> How that translates to python script, I'm not exactly sure, but
> I'm sure that it does indeed translate to python script ;-)
>
> In any case it's the coding practice which
Re: gtk3 + python : lookup_widget
On Mon, August 20, 2012 9:16 am, Tristan Van Berkom wrote:
> On Mon, Aug 20, 2012 at 2:32 PM, Patrick Shirkey
> wrote:
>>
>> On Mon, August 20, 2012 6:59 am, Tristan Van Berkom wrote:
>>>The "lookup_widget()" paradigm comes from a very old time when we
>>> had very poor
>>> tools and actually it originates from people using generated code from
>>> the original Glade
>>> tool (Glade versions 1 and 2).
>>>
>>> Ideally, as specially as you are using python, your application should
>>> be modular.
>>>
>>> Perhaps you have an Application object which owns the main widgetry
>>> created
>>> by GtkBuilder after having parsed a Glade file initially, this is
>>> different from a global
>>> variable.
>>>
>>> Ideally you can use you object constructor as an entry point to load
>>> your GtkBuilder
>>> and assign the pointers you need later on to the members you define on
>>> your
>>> Application object.
>>>
>>
>> In this case I am programatically creating the widget.
>>
>>> After that you simply have to pass your Application object to all the
>>> callbacks
>>> which originate from the user interface, giving you access to
>>> everything
>>> you
>>> need when you need it.
>>>
>>
>> This is the part I am having trouble with.
>>
>>> This concept can be further extended to be more modular, for instance
>>> if
>>> you have a preferences dialog/window... it can be defined by a separate
>>> python class/GtkBuilder file and reused at will throughout your
>>> program.
>>>
>>
>> Thanks for your advice. I am planning to make this app as modular as
>> possible but I am finding it hard to find a simple example that deals
>> with
>> my use case.
>
> Look at GTK+ sources: gtkdialog.c for example, or gtkmessagedialog.c even.
>
> Many composite widgets exist in GTK+, all of them follow the same
> construct:
>
>o Create child widgets at initialization time and assign them to your
> private data structure members which you have declared for them
> (in other words, of course you hold a private instance member for
> any composite children you need, like dialog->entry or dialog->label
> or dialog->button etc).
>
> o Connect signals to, for example the button, when doing so..
> supply the dialog (self) instance as user data for the callback
>
> When the callback runs, it receives the dialog as user data, so
> all of the internal composite children are always available in
> those callbacks.
>
> In theory, in this 'dialog' example, normally all composite children
> are private to the dialog and the dialog has some kind of output
> or modifies your program state in some way, so no user of the
> dialog should ever have to access those internal widget members
> and the dialog can change internally without breaking any API.
>
> So in the context where "the dialog" handles a callback for any
> signal originating from one of it's instance members, it always
> has the dialog in context so it can always access any member
> of the dialog.
>
Do you know of a python example of this concept? I have the signals part
under control and I am ok with python classes but I'm a bit murky on how
to pass the commands back to the object.
I have seen an examples where the class exposed a function that pulled in
the dynamic variable which is updated when the signal is sent/received.
i.e
from gi.repository import Gtk, Gdk
import cairo
class MyWidget(Gtk.DrawingArea):
def __init__(self, parent):
self.par = parent
super(MyWidget, self).__init__()
self.connect("draw", self.expose)
def expose(self, widget, event):
self.variable = self.par.get_cur_value()
label.text = variable
class PyApp(Gtk.Window):
def __init__(self):
super(PyApp, self).__init__()
mywidget = MyWidget
self.cur_value = 0
def on_changed(self, widget):
self.cur_value = widget.get_value()
self.mywidget.queue_draw()
def get_cur_value(self):
return self.cur_value
PyApp()
Gtk.main()
> How that translates to python script, I'm not exactly sure, but
> I'm sure that it does indeed translate to python script ;-)
>
> In any case it's the coding practice which is relevant, not
> the language binding which you use to achieve it
>
Thanks Tristan, I appreciate your detailed explanation.
It seems to me that gtk3 and python3.2 hasn't yet received much love in
terms of documentation effo
Re: gtk3 + python : lookup_widget
On Mon, August 20, 2012 6:59 am, Tristan Van Berkom wrote:
>The "lookup_widget()" paradigm comes from a very old time when we
> had very poor
> tools and actually it originates from people using generated code from
> the original Glade
> tool (Glade versions 1 and 2).
>
> Ideally, as specially as you are using python, your application should
> be modular.
>
> Perhaps you have an Application object which owns the main widgetry
> created
> by GtkBuilder after having parsed a Glade file initially, this is
> different from a global
> variable.
>
> Ideally you can use you object constructor as an entry point to load
> your GtkBuilder
> and assign the pointers you need later on to the members you define on
> your
> Application object.
>
In this case I am programatically creating the widget.
> After that you simply have to pass your Application object to all the
> callbacks
> which originate from the user interface, giving you access to everything
> you
> need when you need it.
>
This is the part I am having trouble with.
> This concept can be further extended to be more modular, for instance if
> you have a preferences dialog/window... it can be defined by a separate
> python class/GtkBuilder file and reused at will throughout your program.
>
Thanks for your advice. I am planning to make this app as modular as
possible but I am finding it hard to find a simple example that deals with
my use case.
Basically I want to be able to modify the text in a label widget from a
Entry or EventBox signal.
I haven't found an example of that but if anyone knows of one that would
be very helpful.
--
Patrick Shirkey
Boost Hardware Ltd
> Cheers,
> -Tristan
>
> On Mon, Aug 20, 2012 at 1:10 PM, Patrick Shirkey
> wrote:
>> Hi,
>>
>> I'm having a little trouble finding examples online of using the
>> equivalent of lookup_widget() with gtk3 + python.
>>
>> For example in the following code what is the best way to modify the
>> "message" label after the "commandline" callback is sent?
>>
>> Should I be using globals or a glade file or is there a way to
>> dynamically
>> lookup the "message" widget ?
>>
>>
>>
>> def create_gtkEntry():
>>
>> commandline = Gtk.Entry()
>> commandline.connect("activate", command_entered, 1)
>>
>> messages = Gtk.Label('TEST')
>>
>>
>>
>> def command_entered(self, *args):
>>
>> cmi_command = self.get_text()
>> messages.set_text(cmi_command)
>> print "command entered: ", args[0]
>>
>>
>>
>> --
>> Patrick Shirkey
>> Boost Hardware Ltd
>> ___
>> gtk-app-devel-list mailing list
>> gtk-app-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
--
Patrick Shirkey
Boost Hardware Ltd
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gtk3 + python : lookup_widget
Hi,
I'm having a little trouble finding examples online of using the
equivalent of lookup_widget() with gtk3 + python.
For example in the following code what is the best way to modify the
"message" label after the "commandline" callback is sent?
Should I be using globals or a glade file or is there a way to dynamically
lookup the "message" widget ?
def create_gtkEntry():
commandline = Gtk.Entry()
commandline.connect("activate", command_entered, 1)
messages = Gtk.Label('TEST')
def command_entered(self, *args):
cmi_command = self.get_text()
messages.set_text(cmi_command)
print "command entered: ", args[0]
--
Patrick Shirkey
Boost Hardware Ltd
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
