Re: [pygtk] progress bar problems

[Andreas Kostyrka]

Am Freitag, 21. Februar 2003 00:10 schrieb John Hunter:
> I have a long, computationally intensive task that I want to use a
> progress bar for.
>
> My problem is that the progress bar is only displaying at the end of
> the computation, even though the function updating the progress bar is
> being called during the long computation
[snip]
> while gtk.events_pending():
> gtk.mainiteration()
>
> but am not sure if this is relevant here.
Yes it is.
The updating alone is not enough as GTK queues this requests till it's idle 
for a moment. So you have to process this requests to create the desired 
effect.

This idiom is actually relevant to most GUI toolkits.

Andreas
-- 
Andreas Kostyrka
Josef-Mayer-Strasse 5
83043 Bad Aibling
___
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] missing characters in textview when using UTF-8 in textbuffer

[Abraham Egnor]

...length _parameter_, not function.

Abe

___
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] missing characters in textview when using UTF-8 in textbuffer

[Abraham Egnor]

When inserting into a text buffer, it wants the length in bytes, not
characters; python's len(), however, returns the number of characters.  A
very easy way around this is to always use -1 as the length function, as
that'll just insert the whole string.

Abe

On Thu, 20 Feb 2003, Anthony Tekatch wrote:

> 
> I am having a problem while inserting a string containing UTF-8 characters
> into TextBuffer for display in a TextView. The displayed string in the
> textview is always truncated by the same number of special UTF-8
> characters. For example if I want to display 32degF (where: deg is the
> degree symbol), I would insert the string u'32\xb0F', the result is that
> the last character is missing from the textview.
> 
> I am using gtk.TextBuffer.insert_at_cursor and my length is 4 for the
> above example.
> 
> 
> Thanks in advance.
> 
> -- 
> Anthony Tekatch
> ___
> pygtk mailing list   [EMAIL PROTECTED]
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
> 

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

[pygtk] missing characters in textview when using UTF-8 in textbuffer

[Anthony Tekatch]

I am having a problem while inserting a string containing UTF-8 characters
into TextBuffer for display in a TextView. The displayed string in the
textview is always truncated by the same number of special UTF-8
characters. For example if I want to display 32degF (where: deg is the
degree symbol), I would insert the string u'32\xb0F', the result is that
the last character is missing from the textview.

I am using gtk.TextBuffer.insert_at_cursor and my length is 4 for the
above example.


Thanks in advance.

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

[pygtk] How to draw in a DrawingArea?

[Dan Christian]

This seems like an obvious question, but I've found the answer quite 
elusive.

How do you draw in a DrawingArea with PyGtk2?

Gtk uses gdk calls, but there are no docs or examples for Python.

You used to be able to use gtkglarea and PyOpenGL, but gtkglarea doesn't 
seem to be supported for gtk2 (correct me if I'm wrong here).

gtkglext might work, but there is no Python version.

The FAQ mentions draw_line, but I can't find any documentation for it.

Help!

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

[pygtk] old Glade to the new Glade 2

[mekkaoui omar]

Hi,
I used Python1.5, PyGTK, Gnome.python and the old Glade to 
develop my application. With the new Glade and python2.2, 
many modifications are introduced (which is the case in 
RedHat 8) like (gnome.congig ==> gconf) and (lib.glade ==> 
XML.Glade).

Was it possible to develop a littlme synthesis about these 
modifications. I suppose, it will so interesting for PyGTK 
mailing list users.

For instance, I would like to convert an old glade project in 
a new glade 2 format using libglade but I don't see how can I 
do that.

Thanks for your help, essentially, for this last point.


Omar Mekkaoui
THEMA - University de Cergy-Pontoise
Economie des Transports
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

[pygtk] Glade/PyGTK bug reports

[Eric S. Raymond]

This is a report of bugs in Glade 0.6.4 (and possibly libglade 0.17)
under Red Hat 8.0.  I observed them while my friend Rob Landley and I
were using Glade to build a GUI for a DNS configuration editor.  I
have enclosed my Glade spec and the Python driver program that runs it
so you can reproduce these.

Yes, we have RTFM, including:

The PyGTK docs at .  Generated
from the C documentation, and (as the author notes) both incorrect and
incomplete.

The PyGnome/PyGTK/Libglade Tutorial at
, with its
actively misleading example code.

The Libglade programming notes at
, 
which might actually have been useful if I were programming in C.

The PyGnome tutorial at
,
which was the best of the lot (though that's not saying much; it is woefully
incomplete).

We're not just bitching about the docs without being willing to pitch
in.  Rob has started work on a Python-and-Glade tutorial, so what we
learn from experience and the answers to these reports will go into that.

Glade bugs, in decreasing severity order:

1. Tooltips on text-view widgets seem not to work during editing.
   That is, filling in the tooltip has no effect.  I was able to invoke 
   tootips to all my other widgets with a tooltip field successfully.

   To reproduce, move the mouse over the commentview widget in the
   editor diplay.  Note that no tooltip comes up.  Select it and
   verify that the tootip property is nonempty. 

2. Tooltips on list/tree widgets display in the editor interface, but
   not when an instance is actually running.  

   To reproduce, note that the domain_tree and properties widgets have 
   tooltips.  Then run oakum.py and hover the mouse over them.  Nothing
   happens.

3. Pixel position of panes defaults to enabled and 1 by default. 
   This makes paned interfaces look broken on startup if the user hasn't 
   manually set the position to something reasonable, an easy thing to 
   forget to do. The default should be 50% of the appropriate dimension
   (stored scaled, see feature request #1).

4. There are bad redraw artifacts when modifying fill and expand on 
   button rows.  They manifest as the widget select box not getting
   erased properly.  

   Alas, I can no longer reproduce this.  It used to happen with the
   button row on the main window.  I don't know what I changed that
   is now masking the bug.

Glade features needed:

1. All pixel positions should be specifiable as a decimal fraction or
   percent of the enclosing widget size, so that layouts make sense at
   any window size.  Absolute, unscaled pixel positions are bugs waiting
   to happen, and the fact that the Glade interface requires them is a bug.

2. The editing interface should have undo.  The lack of it makes
   experimentation too risky, especially when deleting widgets.
   The absence of this feature is a serious design-level bug.

3. In the tree view, it should be possible to drag a widget subtree out of
   its container widget into a new one (so, e.g, you can get rid of an 
   unwanted container by lifting its children up a level and then deleting it).
   Without this feature one is forced to hand-hack the XML.

3. Dragging a pane boundary in the Glade editor should change the pixel 
   position default for that pane (and it should be stored scaled, see
   feature request #1).

4. Convenience feature: add "Select parent widget" in right-click menu.  
   Yes, I know, it's easily done in the widget-tree view.

5. I think the widget-tree view should be on by default.  This is
   an interface style issue, not a feature request per se.

libglade/gtk bugs (?):

1. When I run my code, I get 16 repetitions of the following message:

(oakum.py:822): libglade-WARNING **: unknown property `stock_item' for class 
`GtkImageMenuItem'

   What is going on here?  Where did that bogus large line number come from?
   What is `stock_item', what do I have to do about it, and why does none of
   the existing documentation mention this issue?  In general, how do I trace
   these runtime messages back to a problem I can fix?

The combination of Glade and Python looks like it has the potential to be an
amazingly powerful tool.  Once the rough edges are smoothed a bit...

FYI, our intention is to build a GUI configuration editor that will allow 
end-users to hack DNS zone configurations without shooting themselves
in the foot or having to comprehend zone file syntax.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

 
http://glade.gnome.org/glade-2.0.dtd";>




  600
  530
  True
  Oakum main window
  GTK_WINDOW_TOPLEVEL
  GTK_WIN_POS_NONE
  False
  True
  False
  

  

  True
  False
  0

  

  True

  

  True
  GNOMEUIINFO_MENU_FILE_TRE

Re: [pygtk] progress bar problems

[Malcolm Tredinnick]

On Thu, Feb 20, 2003 at 05:10:47PM -0600, John Hunter wrote:
> I have a long, computationally intensive task that I want to use a
> progress bar for.
> 
> My problem is that the progress bar is only displaying at the end of
> the computation, even though the function updating the progress bar is
> being called during the long computation
> 
> dlg = gtk.Dialog('Computing coherences', flags=gtk.DIALOG_MODAL)
> dlg.set_transient_for(parent)
> dlg.show()
> 
> progBar = gtk.ProgressBar()
> progBar.set_text('Almost there...')
> progBar.set_usize(300, 40)
> progBar.set_fraction(0)
> progBar.show()
> dlg.vbox.pack_start(progBar)
> def progress_callback(frac,  msg):
> print msg, frac
> progBar.set_text(msg)
> progBar.set_fraction(frac)
> 
> somelongcomputation(pars, progress_callback)
> 
> somelongcomputation periodically calls progress_callback with a
> fraction and a message.
[...]
> In my search of the archives, I've seen some references to 
> 
> while gtk.events_pending():
> gtk.mainiteration()
> 
> but am not sure if this is relevant here.

Definitely relevant. Some the events that are pending are widget updates
that change the progress bar's image. If you do not periodically call
mainiteration(), you will notice other effects like parts of your
windows that were covered and uncovered not being redrawn and so forth.

So you could put the above "while..." fragment at the end of
progress_callback, for example.

Malcolm

-- 
The early bird may get the worm, but the second mouse gets the cheese.
___
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] progress bar problems

[Steve McClure]

On Thu, 2003-02-20 at 18:10, John Hunter wrote:
> I have a long, computationally intensive task that I want to use a
> progress bar for.
> 
> My problem is that the progress bar is only displaying at the end of
> the computation, even though the function updating the progress bar is
> being called during the long computation
> 
> dlg = gtk.Dialog('Computing coherences', flags=gtk.DIALOG_MODAL)
> dlg.set_transient_for(parent)
> dlg.show()
> 
> progBar = gtk.ProgressBar()
> progBar.set_text('Almost there...')
> progBar.set_usize(300, 40)
> progBar.set_fraction(0)
> progBar.show()
> dlg.vbox.pack_start(progBar)
> def progress_callback(frac,  msg):
> print msg, frac
> progBar.set_text(msg)
> progBar.set_fraction(frac)
> 
> somelongcomputation(pars, progress_callback)
> 
> somelongcomputation periodically calls progress_callback with a
> fraction and a message.
> 
> I am printing the results to stdout just to make sure that the
> progress_callback is being called, and it is.  Only the bar is not
> updating.
> 
> Is this some kind of resource sharing problem, ie, the progress
> bar doesn't update itself under a heavy CPU load?
> 
> In my search of the archives, I've seen some references to 
> 
> while gtk.events_pending():
> gtk.mainiteration()
> 
> but am not sure if this is relevant here.

That is exactly what you want here.

> 
> Any suggestions?
> 
> Thanks,
> John Hunter
> 
> pygtk 1.99.14
> ___
> pygtk mailing list   [EMAIL PROTECTED]
> http://www.daa.com.au/mailman/listinfo/pygtk
> Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
-- 
Steve McClure <[EMAIL PROTECTED]>
Racemi, Inc.



signature.asc
Description: This is a digitally signed message part

[pygtk] progress bar problems

[John Hunter]

I have a long, computationally intensive task that I want to use a
progress bar for.

My problem is that the progress bar is only displaying at the end of
the computation, even though the function updating the progress bar is
being called during the long computation

dlg = gtk.Dialog('Computing coherences', flags=gtk.DIALOG_MODAL)
dlg.set_transient_for(parent)
dlg.show()

progBar = gtk.ProgressBar()
progBar.set_text('Almost there...')
progBar.set_usize(300, 40)
progBar.set_fraction(0)
progBar.show()
dlg.vbox.pack_start(progBar)
def progress_callback(frac,  msg):
print msg, frac
progBar.set_text(msg)
progBar.set_fraction(frac)

somelongcomputation(pars, progress_callback)

somelongcomputation periodically calls progress_callback with a
fraction and a message.

I am printing the results to stdout just to make sure that the
progress_callback is being called, and it is.  Only the bar is not
updating.

Is this some kind of resource sharing problem, ie, the progress
bar doesn't update itself under a heavy CPU load?

In my search of the archives, I've seen some references to 

while gtk.events_pending():
gtk.mainiteration()

but am not sure if this is relevant here.

Any suggestions?

Thanks,
John Hunter

pygtk 1.99.14
___
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] Issues for PyGTK 2.0

[Christian Reis]

On Thu, Feb 20, 2003 at 12:46:43PM -0300, Johan Dahlin wrote:
> Well, It would be good with an empty bugzilla for 2.0 :-)

s/with/to have/ :-P

> And mean while, fix bug and add incomplete APIs.

s/mean while/meanwhile/

THE NAZI SPELLER STRIKES AGAIN

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
___
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] Issues for PyGTK 2.0

[Johan Dahlin]

tor 2003-02-20 klockan 07.44 skrev [EMAIL PROTECTED]:
> Hi,
> 
> Johan mentioned in his announcement for PyGTK 1.99.15 that this 
> might be the last beta release for PyGTK 2.0.
> 
> My question is: what are the issues that have to be fixed? 
> supppose not all reports in bugzilla have to be resolved...

Well, It would be good with an empty bugzilla for 2.0 :-)

But the main problem currently is the lack of documentation.
PyGtk 2.0 should ship with good documentation.
James wrote a script to generate documentation from the headers in C.
Next step would be to write a merge script, so we can merge user
comments with the generated code and after that starting to documenting
every single function that's available to pygtk.
And mean while, fix bug and add incomplete APIs.

-- 
Johan Dahlin <[EMAIL PROTECTED]>
Async Open Source

___
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] Porting of wrapper from pygtk1 to pygtk2

[Roberto Cavada]

Hi all,

Johan Dahlin wrote:

tis 2003-02-18 klockan 09.42 skrev Roberto Cavada:


  I am currently trying to port the python wrapper for a gtk widget 
(gtkscintilla2).


*** THE PROBLEM:
After initialization, every time W2's code calls PyGtk_New 
(=pygobject_new) a segfault occurs.


Do you have a traceback?
Do you have the code somewhere, so I can help you debug what's wrong?



The segfault - as everyone could guess - was due to the only partial 
initialization of pygtk: module pygobject was not initialized,
since a init_pygobject() call was missing.

After that, I obtained several other problems, so in second stage I 
tried to address the problem with a different (and more structured) 
approach.

This means essentially that I dropped the old pygtk wrapper for 
scintilla, and I used codegen to generate a new one, starting from 
GtkScintilla2.

The result if you can help me can be found at URL:


As you can guess from the filename, it does not work any well, but I 
think I am closed to have a first working version of the wrapper...
If only I were able to fix some problem!

The problem is that when I try to instantiate a Scintilla object, I 
obtain what follows (if you try, make sure you have "./" in your 
LD_LIBRARY_PATH):

>>> import scintilla
Initializing scintilla module
Registered class GtkScintilla
>>>
>>> dir(scintilla)
['Scintilla', '__doc__', '__file__', '__name__']
>>> scintilla.Scintilla

>>> dir(scintilla.Scintilla)
['__class__', '__delattr__', '__doc__', '__getattribute__', 
'__gtype__', '__hash__', '__init__', '__new__', '__reduce__', 
'__repr__', '__setattr__', '__str__', 'add_ref_document', 'add_text', 
'append_text', 'autoc_active', 'autoc_cancel',



>>> scintilla.Scintilla()
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: cannot create 'scintilla.Scintilla' instances
>>>

I cannot figure out what's happening here. Maybe I set wrong names 
insede scintilla.defs and generated code (see scintilla.c), that I 
partially modified by hand. Don't know.

Some suggestions?
Thank you,
 roberto

--
--
Roberto Cavada
ITC-irst Institute for Scientific and Technological Research
Automated Reasoning Systems - Formal Methods Group
Via Sommarive, 18 - 38050 Povo (TN) - Italy
Tel: +39 0461 314 321   Fax: +39 0461 302 040
[EMAIL PROTECTED]  http://sra.itc.it/people/cavada/
--

___
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 on windows

[Christian Reis]

On Thu, Feb 14, 2002 at 01:40:02AM +0530, "§ s.o.m.e.s.h §" wrote:
> i have pygtk binary for windows, python 2.1 and 1.5 and gtk runtime
> 
> 3 binaries
> 
> plz let me know how to start/set env variables etc for running my pygtk scripts
> 
> 
> i tried too many times here but not getting succed
> tell me from a to z for this..

This is described in FAQ 21.2, isn't it?
http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq21.002.htp

Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
___
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

[pygtk] Issues for PyGTK 2.0

[arjanmolenaar]

Hi,

Johan mentioned in his announcement for PyGTK 1.99.15 that this might be the last beta 
release for PyGTK 2.0.

My question is: what are the issues that have to be fixed? I supppose not all reports 
in bugzilla have to be resolved...


Regards,

Arjan


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

[pygtk] pygtk on windows

["§ s.o.m.e.s.h §"]

i have pygtk binary for windows, python 2.1 and 1.5 and gtk runtime

3 binaries

plz let me know how to start/set env variables etc for running my pygtk scripts


i tried too many times here but not getting succed
tell me from a to z for this..



plz guide me...

somesh


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