Re: [pygtk] ANNOUNCE: Kiwi 1.9.1
Hi, Am Donnerstag, den 01.09.2005, 12:20 -0300 schrieb Johan Dahlin: Kiwi is a PyGTK framework for building graphical applications loosely based on MVC Model-View-Controller (MVC) and Allen Holub's Visual proxy [1]. Think of Kiwi as a high-level, object-oriented layer built on PyGTK. [EMAIL PROTECTED]:~/work/src/kiwi-1.9.1$ python setup.py build Traceback (most recent call last): File setup.py, line 36, in ? data_files = [ File setup.py, line 14, in listfiles return [os.path.join(dir, filename) OSError: [Errno 2] No such file or directory: '/home/dannym/work/src/kiwi-1.9.1/gazpacho-plugin' [EMAIL PROTECTED]:~/work/src/kiwi-1.9.1$ dunno if that is relevant/normal, just though I'd mention it... cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] gtk.FileChooserButton and custom gtk.FileChooseDialog
Hi, hmm, and where is the connection between your classes filechooser and filedlg ? cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] trying to launch a pygame app from within my gtk app
Hi, Am Mittwoch, den 09.11.2005, 13:25 -0600 schrieb nephish: thanks gents, i am using linux. and i have been trying to get the spawn command to work. in the docs, i dont understand what is ment by args, i dont really have any args to pass. Most programs expect their own full path as the first argument (arg 0). i tried like this os.spawnl(os.P_NOWAIT, '/path/to/program.py') os.spawnl(os.P_NOWAIT, '/path/to/program.py', '/path/to/program.py') Note that in order to be able to run python programs like that, they have to: - be executable (have executable flag) - contain a shebang in the first line (#!/usr/bin env python) and it doesnt act like anything is actually happening. the program does not really exit. i just close its window. should i change that? i dont know where to put the sys.exit. What do you mean ? Put it where you want to quit. thanks for your help guys. i have thought about running it as a thread, but the thread needs to die after i close the window. umm. What are you trying to do ? thanks again, shawn cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Re: Pixbuf memory leak?
Hi, Am Mittwoch, den 16.11.2005, 09:06 + schrieb Loris Caren: On Tuesday 15 November 2005 21:06, you wrote: I'm doing a large number of calls to p = gtk.gdk.pixbuf_new_from_file(f) ... del p and am finding that the process consumes more and more memory as it goes on. Should I expect the del to free up the memory used by the loaded image, or is there some kind of 'close' call I need to be invoking first? Think I've found the answer to this one in the archives. Various other people have reported a similar bug, but http://article.gmane.org/gmane.comp.gnome.gtk+.python/2315/match=pixbuf suggests it's an issue with the garbage collector. Adding an explicit gc.collect() after my del stops my memory usage wandering off the scale. This looks like a generic issue for anyone manipulating lots of large objects, and an easy trap for those that thought that python 'just did' memory allocation and one never need bother about it. I'm also disturbed by this and I wonder if it is possible to have python memorize the virtual size aswell, and then garbage collect using the virtual size instead of the (real) size of the handle. I think this should be brought to the attention of the developers of python, since they should know best how to proceed. Note that the handle size data size problem would be a quite universal problem (thinking about any python C extensions here) cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Does such a widget exist?
Hi, Am Mittwoch, den 16.11.2005, 19:51 +0100 schrieb Stefano Esposito: Hi all, i need a widget that displays mobile/fixed points and fixed rectangles and which is capable to catch mouse-click events. Does such a widget exist somewhere in the world? :) diacanvas perhaps, if I understand you right... Bye Stefano cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Disabling or greying out other windows
Hi, Am Montag, den 21.11.2005, 16:08 -0500 schrieb Thierry Lam: Let's say I have a main window which has a File menu. When I click on the File menu and the open button, I have a File Chooser window which comes in front of my main window. How do I make the main window unselectable? That is, the only window I should be able to select at this point is the File Chooser window while the main one is greyed out. Set the dialog modal. Easiest to do it just to call run() on the dialog. Note that this is a little different from what you described. You can still minimize/move/... the main window, but the events will be ignored as long as the file dialog is open. Which is nice :) Thanks Thierry cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Help with modal in Gtk::FileChooserDialog
Hi, Am Dienstag, den 22.11.2005, 14:37 -0500 schrieb Thierry Lam: Does anyone know how to set modal to True for Gtk::FileChooserDialog? Usually you just use a modal event loop: dialog = gtk.FileChooserDialog() answer = dialog.run() # hangs around until dialog is closed del dialog Thanks Thierry cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Help with modal in Gtk::FileChooserDialog
Hi, Am Montag, den 28.11.2005, 15:47 -0500 schrieb Graham Ashton: On Monday 28 November, dannym wrote: Usually you just use a modal event loop: dialog = gtk.FileChooserDialog() answer = dialog.run() # hangs around until dialog is closed del dialog Hi. Wouldn't it be better to say: dialog.destroy() instead of del dialog ? It was a long time ago that I did looked into this, but I found that in order to avoid memory leaks in long running processes that created/destroyed a lot of widgets, I had to explicitly call destroy() myself. I confess I'm not even sure if del calls it for you... I have no idea. My gut feeling says that exactly the same should happen when you del it manually than what would happen if it were just gc'ed after you closed it. However, your scenario is entirely possible too (i.e. gtk_object_destroy is never called. Note that gtk_object_destroy is merely a method that emits a signal destroy to which others can connect and make sure that they don't hold a reference to the widget anymore, which would have caused it to idle around indefinitely, as an immortal) Would be worth testing .. care to test? :) cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Port of a gtk date entry widget
Hi, Am Sonntag, den 04.12.2005, 02:20 +0100 schrieb Fabian Sturm: Hi! thanks for your reply! On Sat, 2005-12-03 at 18:55 +0100, Jakub Piotr Cłapa wrote: 2. I can't hide any of the widgets. E.g. a call to self.__cal_label.hide() does not hide the label Okay I found the problem to this, I used mainwindow.show_all() in the test case. This had the effect that I could no longer hide the time controls. But unfortunately this behaviour is different from what is done in the c code! I am really lost with this one! Why are the widgets in the c code not shwown by the call to show_all?? Because they use some stupid workaround to make all not mean all. I suggest you use show() on the widgets you want to see and be over with (and not use show_all at all). 3. The c version of the widget had two different constructors, as far as I understood is this impossible in python, so how do you cope with it. Which ones ? from reading the C header file at 01:47 am in the night (so don't quote me on that, it might be gibberish) I deduce : GtkWidget *gnome_date_edit_new(time_t the_time, gboolean show_time, gboolean use_24_format); GtkWidget *gnome_date_edit_new_flags (time_t the_time, GnomeDateEditFlags flags); I would suggest you to drop both and make the stuff properties instead (as far as possible). Most of the stuff is a bad idea to pass and you should get the GnomeDateEditFlags from the locale (Localization settings) of the user that is logged in, hardcoded. You add keyword arguments to __init__ and check them on runtime or ^^^ that is overloading. (my own idea; not sure if it's Harmful(TM)) add a class method returning an instance. nice idea, but depends on the actual constructors of the original version if it is worth the complexity of it all... As I have looked them up now, don't bother with them. Get rid of them, use properties. Also, they actually do the same. I think the one is a backwards compability hook for the other: i.e. gnome_date_edit_new actually calls gnome_date_edit_new_flags (I didn't check that, too late to read C code :)). I dont' like the idea, since the two keywords would mean the same thing and it would be unclear which one to fill out, or even both... yeah, but I don't think you understood him correctly. It's better if you don't use it because it leads to weird code. Trusting you to take that advice seriously (kwargs = bad code), I show you what it is: def foobar(**args): if hello in args: print hello args: , args[hello] if bar in args: print bar args: , args[bar] foobar(hello = foo) hello args: foo foobar(bar = baz) bar args: bar foobar(baz) (I have no clue in hell what that causes... let me try... aha :)) TypeError: foobar() takes exactly 0 arguments (1 given) For the calendar thing, just make the constructor take no args. Nobody will pass any to a widget either way (they are usually not instantiated manually, so...). So overloading would be the best, if possible. see above. that _is_ overloading. How do others handle this? Stuff like constructor overloading feels just weird [in python. Everywhere else too? I think I managed to ignore it in C++ somehow - as long as they do the same ;)] Finally I have attached the new state of the widget, it already is useable, even so I have not yet added the set_property, get_property stuff. Some help / demo code with this part would also be very cool. Anyways this version can already be tested for functionality and bugs! Thanks a lot, Fabian Nice :) Thanks for your work :) There are a few nitpicky things I want to note: Space the widgets apart. See the Gnome HIG (Human Interface Guidelines). Basically, what I want to get at is: don't make users feel clausthrophobic :) (there is set_border_width on any widget - not so helpful in that case, set_spacing on any container - use it on the hbox, value 7 or something - can't remember, look it up to be safe) If your gtk version is new enough, don't use OptionMenu, use gtk.ComboBox. Or, now that I see what that uses it for, use a MenuToolButton. The only thing you should use pixel units for is for borders and spacing. Don't do set_size_request(), rather say: - for the gtk.Entry: use set_max_length() to set the max length in characters You might want to use: self.__date_button.connect(clicked, self.select_clicked_cb) def select_clicked_cb(self, widget): dialog = gtk.Dialog...( widget.get_toplevel_widget()) dialog.add_button(gtk.STOCK_CANCEL, gtk.RESPONSE_CANCEL) dialog.add_button(gtk.STOCK_OK, gtk.RESPONSE_OK) response = dialog.run() dialog.destroy() if response == gtk.RESPONSE_OK: If there is stuff I have not covered, ask me again, I might have overlooked :) cheers, Danny ___ pygtk mailing list
Re: [pygtk] Trouble modifying a GtkTreeView
Hi, Am Montag, den 12.12.2005, 07:53 -0500 schrieb Gary Jaffe: Hi -- I have a GtkTreeView that is working fine, but I would like to change 2 things. 1) Change the background color in the text area and I sure hope you have a good reason for that, like changing it to RED to GREEN as a status info (even then, not sure if it's ok to hardcode that). that said, you can set background modify_bg / modify_base or on the cell renderer by referring to a cell in the tree store for the background info. 2) Reduce the amount of vertical space between the text lines. Don't. Modify the theme. Edit ~/.gtkrc-2.0 (or load an external theme file for the app from the user's homedir - somewhere he can modify things) To change the background color, I tried viewBgCol = gtk.gdk.color_parse(#808080) view.modify_bg(gtk.STATE_NORMAL, viewBgCol) The background color of the even rows or the odd rows or where there are no rows or the selected row or the marked row or the selected and marked row? but this did not change the color. For the reduction of space, I've read through the pango docs, but was not able to figure out how to do this. Any help would be appreciated. Edit ~/.gtkrc-2.0 I'd say it is a style property of the GtkTreeView or whatever Cell Renderer you use. The basic rule of thumb is: Honor the theme the user has chosen and match those settings as close as possible. As I said, there are exception, like for highlighting problematic rows or such, but usually honor the rule. I'm running gtk version 2.8.6 and pygtk version 2.8.1. Thanks, Gary cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] ANNOUNCE: DateEdit widget for linux and win32
Hi, Am Dienstag, den 06.12.2005, 01:22 +0100 schrieb Fabian Sturm: Hi! I finally finished my dateedit widget, it is not yet thoroughly tested but all I tested worked fine. nice :) It is not an exact port of the libgnomeui widget, since I think some changes make more sense for a python widget (e.g. datetime as return type instead of epoch). I also hope to make this a bug free and documented widget, since I couldn't find any simple but still feature complete custom gobject in python. So I hope many people will comment on this so that it can be used as reference for other developers. Things which still bug me: - constructor The original gnome-dateedit has two constructors, unfortunately with overlapping but different parameters, so they can't just be merged into one python constructor with named parameters. don't use constructors with parameters at all in that case. I don't see what one would want to use them for here. Use module locale to get the settings and pass them to the C stuff. Except for the date, there are no programmer-should-set-them settings that I can see, and the date is better done as a property. Remaining 0 constructor parameters :) add more spacing between the entry and the button and the optionmenu... Don't use set_size_request (use set_max_length in characters). Note that the number of characters may be locale-dependent and to leave some extra space (at least 1-2 chars) so the user can edit around without having to delete first. Hmm, I like the option menu thingie for the Time :) Please split the dateedit_flags property into the actual properties... I don't know what the gnomeui guys smoked on this but I don't like it :) i.e. show_time: (gobject.TYPE_BOOLEAN, ... and I don't think the 24hr and weekstartsonmonday stuff should be setable at all. just query the locale. It just feels weird to have them there at all. :) So far I only got one response on this problem. - destruction The original version has these additional functions: free_resources, mnemonic_activate, destroy, finalize I don't know what of this is needed for python, so some comments would be great. mnemonic_activate is usually when some keyboard bound key got pressed. Not sure what they do in there (didn't look yet though)... try if the keyboard shortcuts work fine now... finalize is pretty sure just C legacy, free_resources probably too. destroy is partly. But if destruction works right now, no need for that either. - show_all if you add this widget to a window and then do a window.show_all() the Don't use show_all(). Instead, use show() on the widgets you want to see. I don't think it is worth the hassle. Did I mention already that I hate show_all and no_show_all ? ;) dateedit widget will show the time entry, even though it should be hidden by the show_time = False flag. I can't see the difference to the c widget so I need help here too! - todos I have several todos at various places in the source, most are just spots which should be verified by other developers Thanks a lot, Fabian P.s. I will set up a webpage for the widget and announce it once more at the list when the above stuff is resolved. Good work :) cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Help with modal in Gtk::FileChooserDialog
Hi, Am Donnerstag, den 01.12.2005, 12:23 + schrieb Gustavo J. A. M. Carneiro: [...] You need to call dialog.destroy(). del dialog doesn't work because gtk+ itself always keeps one last reference to toplevel windows until you destroy() them (or until they are implicitly destroyed by the user clicking the close window button). This must be documented somewhere, I would imagine?... Hard to say, really. In my gtk+ bindings (for pascal), I usually ref and sink any gtkobject at the beginning (i.e. in my WrapGObject function - like pygobject_from_??? or-what-they-are-called-in-pygtk) to stop unexpected stuff like what you describe from happening ... now if pygtk does that or not, I don't know... (note that my gtk pascal bindings are refcounted themselves so it's different from a mixed gc/refcount environment, I'd imagine) cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] how to bring dialog to top of window stack?
Hi, Am Montag, den 19.12.2005, 15:56 -0500 schrieb george young: [pygtk 1.99.17, python 2.4.2] [Yes, I know 1.99 is ancient -- I'm working on it...] I have a Dialog which is popped up from a menu item. I want to enforce that there is at most one of this type dialog extant at any time. Sometimes the dialog gets hidden under other windows and dialog.set_transient_for(mainwindow) then it doesn't get hidden under other windows (at least not under _that_ window) the user just hits the menu entry, foretting that she already has one. I need a way to force an existing dialog to the top of the stack. Dialogs apparently can't be minimized, so I don't have to worry about that possibility. I tried just dia.show(), but that did not bring the dialog window to the top. dia.present() -- George Young cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] question about tree view
Hi, Am Montag, den 02.01.2006, 16:36 + schrieb nephish: Hey there, i am using a tree view to show one main coloum and one child. i can browse through the tree just fine, but i have to double-click to make it selected and give the on_tree_row_activated signal. Where can i set it up to make a single click work the same way ? The design really is like that: - activation is double-click (everywhere) - single-click is for changing the selection Therefore, if you want to react on single click, you really want to react on selection change, so you have to do something like, treeview1.get_selection().connect(changed, selection_changed_cb) in there you probably check the current selection (with get_selected_rows or get_selected) and update some preview (I assume this is what you want to do) cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] How do you make a widget lose its focus?
Hi, Am Dienstag, den 10.01.2006, 18:03 -0500 schrieb Thierry Lam: Let’s say I have Gtk.ComboBoxEntry. Each time I select an entry, the widget.is_focus() returns true. If I want to click another window, can I explicitly set the widget’s focus to False? By clicking on another focusable widget, the entry loses focus anyways... or did I miss something? cheers, Danny ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
