Re: [pygtk] PyGTK gtkmm C++ wrap - possible?

2004-12-06 Thread Fabien COUTANT
[...]
 When I finally managed it to wrap the C++ code using SWIG the next 
 problem occured. When I try for example...
 
 window = gtk.Window()
 widget = MyCustomWidget()
 window.add(widget)
 
 ...I get an exception saying I'd have to pass a gtk.widget instead 
 of a 
 string?! As far as I understand from the SWIG documentation C/C++ 
 wrapped pointers are represented as strings in python. So what can 
 I do?
[...]

Hi Alex,

To avoid the pointers as strings symptom, you have to use SWIG's
type mappings to convert between a GtkWidget* and a Python type.
You also have to use and integrate the PyGTK infrastructure so that
your widget can be used from Python as other widgets.

This should work with C++ as it works with C.  As example of what I
did (a long time ago, this was with Gtk 1.2 / PyGTK 0.6.x and swig 1.1),
look at
http://www.fcoutant.freesurf.fr/python-cschtml.html
http://www.fcoutant.freesurf.fr/python-gdkpixbuf.html
which should give you ideas about what SWIG can do for you, and what
it can't.  I strongly advise you carefully read its manual, so that
you fully understand what you are doing (SWIG is quite obscure 
otherwise :).

The packages there are quite old.  The way to wrap Gtk widgets using
PyGtk may have changed with Python2.3 / PyGTK 2.x / Swig 1.3.  I just 
didn't
look.  It *may* be useful to you as a start point.

Alternatively you could use PyGtk 2.x code generator so that your widget
looks from Python as an object/class and its methods.  For this you 
*may*
have first to write C wrappers for your C++ class' methods, since PyGtk
will only call C functions...

-- 
Hope this helps,
Fabien.
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/


Re: [pygtk] Simple TreeView API

2004-10-07 Thread Fabien COUTANT
 On Wed, 2004-10-06 at 23:10 +1300, John C Barstow wrote:
  ANY feedback would be helpful
 
 I have no technical feedback to provide, actually. 
 Anyway, I want to stress that those who I talk about pygtk will always
 complain about the convolution of tree/list widgets it provides. 
 Powerful, elegant, clever and whatever, but too complicated to begin
 with. 

As a GTK 1.2/2.x and PyGtk 0.6/2.x programmer, I think it's worse than 
that.
I think the problem about the list widget lies in Gtk, not in PyGtk.
Once upon a time was the CList widget. It was limited but simple and 
practical,
and suited many needs.  Using it, it was simple to do simple things, it 
was
moderately complicated to do moderately complicated things, and it was
impossible to do complicated things.
Now the Gtk developers decided CList is deprecated, and want to replace
it with TreeView.  Unfortunately using the TreeView is overly 
complicated
even to do simple things.
PyGtk simply mirrors the Gtk API, and I see nothing wrong with this.

 
 One would expect to see an abstraction layer *within* pygtk, 
 that's the
 point as for me. 

Beware: it should be a temporary replacement solution until Gtk 
developers
understand this problem and provide a simple CList-like widget.

Since /me alone doesn't have enought weight to speak to Gtk developers 
about
this, I'm still looking for people with the same/approaching point of 
view and
enough influence...  But I think this would be The Right Way to go.

-- 
Best regards,
Fabien
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/


Re: [pygtk] pyGTK + windows + skins

2004-03-18 Thread Fabien COUTANT
Hi!  Since I use GTK2 for a project at work I can give some advice on
this...

On Thursday, 18 March 2004, you (Tyler W. Wilson) wrote:
| - The standard location for themes is GTK Folder/2.0/share/themes. You 
| can drop any theme you want in there.

More exactly the location is GTK folder/share/themes.

| - Theme engines go into GTK Folder/lib/gtk-2.0/2.2.0/engines. The only 
| one included in the standard package is libwimp.dll. I have successfully 
| built and used cleanice and xfce - it was quite straightforward if you 
| have the GTK Dev package installed (I used Visual C++ 6).

Right.  I have personally successfully built several engines with MinGW
+ MSYS + some hand tweaking:  bluecurve, cleanice, galaxy, industrial,
thincream, thinice, xfce, pixbuf (aka pixmap in GTK1).

I also got other engines from a previous GTK/Win32 distro: 
lighthouseblue, metal, mist, redmond95, smooth, wimp.  I think all Unix
engines compile easily on Windows too, except maybe QtPixmap.

All themes mostly work with some off-by-one glitch drawing seen on the
right of some borders.  I have submitted a patch to sourceforge to
request their inclusion in the main distro a while ago, with no luck. 
Check the patches page on http://sourceforge.net/projects/gtk-win/ (I
had to split the file in 4 parts).

| The tricky bit is how to tell GTK on Windows which theme to use. There 
| are at least 3 ways to do this (though I have only tested 2):
|
| I was hoping to build a little theme-switcher in PyGTK, but have not 
| found the proper incantations to tell an application to redraw itself (I 
| am new at this PyGTK thing).

System-wide wise, you have to edit GTK folder/etc/gtk-2.0/gtkrc and
place an include directive inside for your wanted theme's gtkrc.

You can do it by hand or more easily use use gtk2_prefs by Alex Shaduri
from http://members.lycos.co.uk/alexv6/, which will also let you change
the font to use.

-- 
Hope this helps,
Fabien.
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/


Re: [pygtk] pyGTK + windows + skins

2004-03-18 Thread Fabien COUTANT
On Thursday, 18 March 2004, you (Christian Robottom Reis) wrote:
|  More exactly the location is GTK folder/share/themes.
| 
| - FAQ 21.13
| 
| http://www.async.com.br/faq/pygtk/index.py?req=showfile=faq21.013.htp
| 
| Reviews and corrections appreciated.

Hmmm this pertains more to a GTK (than PyGTK) -on-windows FAQ.
I can't change it directly (no password).

Should reformulate the last sentence because it (I) was misleading:  the
patch I submitted to sf is pre-compiled engines and associated themes,
NOT a patch to correct the off-by-one glitch !

Should also mention that:
- engines can also be built quite easily with MinGW + MSYS
- there is a GUI program called gtk2_prefs by Alex Shaduri at
  http://members.lycos.co.uk/alexv6/ that allows to preview and select the
  GTK theme and font to be used by GTK apps (it is far more easy than
  tweaking with rc files)

-- 
Hope this helps,
Fabien.
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/


Re: [pygtk] pyGTK + windows + skins

2004-03-18 Thread Fabien COUTANT
On Thursday, 18 March 2004, you (Michal Pasternak) wrote:
| Fabien COUTANT [Thu, Mar 18, 2004 at 01:46:52PM +0100]:
|  All themes mostly work with some off-by-one glitch drawing seen on the
|  right of some borders.
| 
| Do you mean this right-lower corner pixel missing in buttons?
| 
| I'd really like to see it fixed.

Depends on theme and engine:  Some have no error (WinXP-Blue), some have
the corner single pixel missing, some have the whole right border offset
(or is it the two right corners' pixels missing ? ;)

-- 
Hope this helps,
Fabien.
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/


Re: [pygtk] Patch to those who use glc.py (Python Glade Code Generator)

2001-10-18 Thread Fabien COUTANT

Hello Rodrigo, I'm the guy who wrote gladepyc.

On Thursday, 18 October 2001, you (Rodrigo Senra) wrote:
...
  Cool tip about gladepyc, is there a good reason for the absence of a link
  to this project in PyGTK Home Page ?

Good idea.  Don't know why, I didn't think about it before.  However I
just had a look on PyGTK home and links pages, and GLC does not appear
there either.

A long time ago I have submitted the link to Glade's author (Damon
Chaplin), so that it would appear on Glade's links page, which is where
I initially found GLC; Unfortunately the link still hasn't appeared.

On the other hand, James is the author of both PyGTK and libglade, and
the latter is being promoted vigorously (as you saw in the first answer
:-).  Not sure James is willing to add a link to a concurrent product ;)

-- 
Hope this helps,
Fabien.
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk



Re: [pygtk] Request for Comments: shorter widget class names

2001-09-12 Thread Fabien COUTANT

Hello everybody,

On Wednesday, 12 September 2001, you (James Henstridge) wrote:
 One request that has come up many times is to drop the Gtk prefix from
 the widget class names in pygtk.
...
 As this would cause large source incompatibility, I am looking for
 people's opinions about such a change (I haven't decided which way I feel
 about this issue yet).

I'm pretty in favor of it.  Seems cleaner and more Pythonish.  I always
wondered why the module name is repeated as prefix for all functions,
because the way you propose now seems so more simpler.

Additionally, changes required to existing sources are not so difficult: 
should just be a matter of subsituting gtk. for gtk_ and adjusting
import statements.

...
 and the functions in the gtk module that were from GDK have been moved to
 gtk.gdk module.

Here, having separate modules for each prefix may be more appropriate.
I prefer writing gdk.something rather than gtk.gdk.something; OTOH I
could as well change my import statement to import gtk; from gtk import
gdk and go on using the first form.

This is a bigger problem for constants: GTK.CONSTANT is more readable
than gtk.CONSTANT, but I know having a GTK module beside gtk
raises case problems on some platform.

I'm confident there is a module organization that makes things appear
clean to the developper about all aspects.

 There is one other major change that I am considering (although it will
 affect the API far less) -- using the new python 2.2 features instead of
 ExtensionClass.  I haven't started looking at how easy such a change would
...

I see another advantage:  as time passes, more features will be added to
this Python mechanism, and using the standard way to do things will allow
PyGtk to benefit from new features with minor or no changes to it (since
Python's APIs are traditionally more stable).
There still are problems with ExtensionClass, and one can hope that
Python's own implementation will work more seamlessly, sooner or later.

-- 
Hope this helps,
Fabien.
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk



[pygtk] how to contribute

2001-03-29 Thread Fabien COUTANT

Hello,

I'm working with pygtk-0.6.6 / Python 1.5.2 and would like to implement
some missing bindings to it, since it doesn't seem too difficult, and
I'm familiar with Python and it's API.

I saw by browsing the list, that the next major version is already
scheduled as version 2.0, but what I really want is extend the current,
stable version.

How should I proceed ? (cvs access  branch, agreement from maintainers,
etc...)

PS: this will be used to complete a tool I wrote:
http://www.fcoutant.freesurf.fr/gladepyc.html

-- 
Hope this helps,
Fabien.
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk



Re: gladepyc (was Re: [pygtk] how to contribute)

2001-03-29 Thread Fabien COUTANT

On Thursday, 29 March 2001, you (Alexandre Fayolle) wrote:
 On Thu, 29 Mar 2001, Fabien COUTANT wrote:
 
  PS: this will be used to complete a tool I wrote:
  http://www.fcoutant.freesurf.fr/gladepyc.html
 
 This could be a very useful tool. What has stopped me using glade so far
 is the lack of Windows support which is one of the target of the
 application I'm working on. I think I'll give a try to gladepyc soon.

Hello Alexandre,

Gladepyc will happily generate code that runs on Unix, Vms as well as
Windows.

There is glitch however:  non-ASCII characters are encoded with UTF-8 on
Windows' Gtk and ISO-Latin1 (or other 8-bit encoding) on Unix' Gtk (1.2
at least); So if you have some of those characters entered in Glade's
XML on one side, they are not rendered correctly on the other side.  It
works perfect only if you use the generated code on the same platform
that Glade's XML was designed on.

That said, Glade for Windows seemed reasonably stable, from what I
tested a few months ago.  All this GTK/Glade stuff for Windows is
unofficial though -- yet.

-- 
Hope this helps,
Fabien.
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk



[pygtk] [request] glade mapping completion

2000-07-05 Thread Fabien COUTANT

I found that the glade_xml_new_from_memory function is missing.
Would it be feasible to add it to pygtk ?

PS: CC me for the answer, I'm not subscribed on the list -- yet. Thanks.

-- 
Hope this helps,
Fabien.

___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk