Re: glib-mkenums in glib 2
On 30 Dec 2012, at 16:36, John Ralls wrote: Hmm. Your python doesn't seem to agree that codegen is a package, in spite of being imported into gdbus-codegen. On 30 Dec 2012, at 16:40, jose.ali...@gmail.com wrote: I don't know if this is related, but It seems you are missing the empty __init__.py in the codegen/ directory. This is a requirement for a directory so python may consider it as a package. Hi guys, Maybe you'll remember that I eventually bought a Python programming book and ran some examples which also used the 'from / import' construct. The textbook examples worked but building this gdbus stuff still wouldn't work. Well, eventually I spotted a difference which I think might be important Each sample package from my textbook does have that file __init__.py. But when I run the actual sample, a second file gets generated, called '__init__.pyc'. If I delete that file and then run the sample again, it gets regenerated each time. This isn't happening with the gdbus code. Although the codegen package does have a file called __init__.py, I never see a file called __init__.pyc getting generated. Could that be significant? I think perhaps that explains why codegen isn't getting recognised as a package. John ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: glib-mkenums in glib 2
On 13-01-04 02:13 AM, John Emmas wrote: On 30 Dec 2012, at 16:36, John Ralls wrote: Hmm. Your python doesn't seem to agree that codegen is a package, in spite of being imported into gdbus-codegen. On 30 Dec 2012, at 16:40, jose.ali...@gmail.com wrote: I don't know if this is related, but It seems you are missing the empty __init__.py in the codegen/ directory. This is a requirement for a directory so python may consider it as a package. Hi guys, Maybe you'll remember that I eventually bought a Python programming book and ran some examples which also used the 'from / import' construct. The textbook examples worked but building this gdbus stuff still wouldn't work. Well, eventually I spotted a difference which I think might be important Each sample package from my textbook does have that file __init__.py. But when I run the actual sample, a second file gets generated, called '__init__.pyc'. If I delete that file and then run the sample again, it gets regenerated each time. This isn't happening with the gdbus code. Although the codegen package does have a file called __init__.py, I never see a file called __init__.pyc getting generated. Could that be significant? I think perhaps that explains why codegen isn't getting recognised as a package. That file is cached bytecode that Python compiles to avoid re-compiling it at runtime each time the script is imported (unless the file changed). If Python can't import your module/package, those .pyc files won't be compiled. From the last few messages on this thread, it kind of sounds like your module search path is not set up correctly, that is, Python doesn't know where to look to import your modules/packages (try print(sys.path) to see which paths I mean). There's good docs about this on python.org (as well as all kinds of other excellent docs/tuts). Good luck, Matthew Brush ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Stable, long term support releases for gtk+
hi all; a couple of points have been raised on IRC, so let me try to summarize them here: • LTS is probably the wrong name, given that it has support into it; I merely used a known name, but what this whole initiative is about is to provide releases coming from upstream (the GTK+ project) that can be used downstream (the GTK+ distributors) to avoid distro-specific silos, or different bug fixes reaching downstream distributors at different times; • related to the point above, the scope of this initiative is to integrate (well-tested) patches, either coming from downstream, or identified from upstream: no new features, no sweeping changes, no refactorings, and more importantly *no* *regressions*; I am currently drafting a list of guidelines for the process of integrating patches, to avoid unnecessary confusion, and to allow somebody else to pick a branch up in the future, in case this initiative is successful. there are some discrepancies in the versions chosen by different downstreams, at the moment; plus, GTK+ 3.4 has its own quirks that have been resolved in GTK+ 3.6, as well as in the current 3.7 cycle. I think the current situation is inevitable, at least for this cycle. even if we selected the next stable version, 3.8, to be the one with long term updates (which would put some pressure on the things that still need to land with just a month or so before API freeze), it wouldn't do anybody good at least until the next LTS cycle in a couple of years, and this whole thing would be a pointless exercise in futility. given the installed base that depends on GTK+ 3.4 and GLib 2.32 *already*, the sanest option is to do a run with those, and see how this whole thing works out. for the next long term support cycle of our various downstreams we'll probably be able to select a version beforehand, and get everybody on the same page from the start. ciao, Emmanuele (who is not subscribed to distributor-list, so would appreciate to keep gtk-devel-list in the loop when replying). ___ gtk-devel-list mailing list gtk-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Ekiga and Linphone Keypads need not to be affected by RTL (force LTR)
Solved. http://lists.nongnu.org/archive/html/linphone-developers/2013-01/msg2.html https://trac.gajim.org/changeset/5f8bfea2054a http://git.gnome.org/browse/ekiga/commit/?id=76c9b23 + // the dialpad is LTR even for RTL languages + gtk_widget_set_direction (dialpad, GTK_TEXT_DIR_LTR); Thank you to the developers of Claws Mail and Leafpad. On Sat, 10 Nov 2012 14:47:46 +0100 Genghis Khan genghisk...@gmx.ca wrote: Hello, RTL = Right to left LTR = Left to right When using Ekiga or Linphone with RTL UI, the keypad reverts to: A 3 2 1 B 6 5 4 C 9 8 7 D # 0 * As far as I know, there is no such keypad order anywhere on the globe. Is it possible to force the original English alignment on certain element/object and to segregate it when using RTL locale such as Arabic, Hebrew, Farsi or Urdu? Code references: Ekiga http://git.gnome.org/browse/ekiga/tree/lib/gui/dialpad.c#n141 LinPhone ../linphone/gtk/main.ui from line 1129 http://www.linphone.org/eng/download/ child object class=GtkFrame id=frame3 property name=visibleTrue/property property name=can_focusFalse/property property name=label_xalign0.5/property property name=shadow_typenone/property child ... -- Proper English www.reddit.com/r/proper 4 teh lulz... http://email.is-not-s.ms ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
Re: Ekiga and Linphone Keypads need not to be affected by RTL (force LTR)
On Sat, Nov 10, 2012 at 02:47:46PM +0100, Genghis Khan wrote: Ekiga http://git.gnome.org/browse/ekiga/tree/lib/gui/dialpad.c#n141 Always best to use Bugzilla for bugs: https://bugzilla.gnome.org/ That way the Ekiga developers are notified directly and it is tracked. -- Regards, Olav ___ gtk-list mailing list gtk-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-list
