Re: [pygtk] problem with ong image
On Wed, 2 Aug 2000, Torsten Landschoff wrote: > On Tue, Aug 01, 2000 at 10:47:35PM +0200, YuRiX wrote: > > hy guys, sorry for my english ... it's orrible i know > > No problem, but another thing bothers me: As you are using Debian you > should report this bug to the Debian BTS using reportbug for example > or by mail to [EMAIL PROTECTED] > > There is no reason to bother the pygtk developers as long as you don't > know if this problem is Debian specific. > > > ok here you are the problems : i can't load png images from my small > > python program using gdk_imlib, and also the view.py example can't do > > that. > > > > what did i wrong ? > > i have installed helix gnome on my sweet debian and i get this with > > imlib-config > > Yep, I have the same problem with helix gnome packages as well. When I > have the standard gnome packages installed the example works... > > Seems like the person at helix code should work this out or we should > merge helix and fix it in Debian... This problem can be fixed by either modifying the python executable or the imlib build process. You either need to modify imlib so that the image loading modules link against libgdk_imlib.so, or modify python so that it loads shared libraries with the RTLD_GLOBAL flag (Red Hat makes the second change). Libtool-1.3b (the 1.4 beta) makes the first option quite easy, but doesn't support all the platforms in the latest 1.3.x release. > > HTH > > Torsten (python-gdk-imlib maintainer) > > James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] problem with ong image
On Tue, Aug 01, 2000 at 10:47:35PM +0200, YuRiX wrote: > hy guys, sorry for my english ... it's orrible i know No problem, but another thing bothers me: As you are using Debian you should report this bug to the Debian BTS using reportbug for example or by mail to [EMAIL PROTECTED] There is no reason to bother the pygtk developers as long as you don't know if this problem is Debian specific. > ok here you are the problems : i can't load png images from my small > python program using gdk_imlib, and also the view.py example can't do > that. > > what did i wrong ? > i have installed helix gnome on my sweet debian and i get this with > imlib-config Yep, I have the same problem with helix gnome packages as well. When I have the standard gnome packages installed the example works... Seems like the person at helix code should work this out or we should merge helix and fix it in Debian... HTH Torsten (python-gdk-imlib maintainer) -- Torsten Landschoff Bluehorn@IRC <[EMAIL PROTECTED]> Debian Developer and Quality Assurance Committee Member PGP signature
[pygtk] gdk-pixbuf bindings
I made python/pygtk bindings for gdk-pixbuf. It's the first time I've worked with the Python C-API, so... it probably sucks badly, :) but should be good enough if you just want to play around. http://users.systec.com/acano/pygdkpixbuf.tar.gz ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
[pygtk] problem with ong image
hy guys, sorry for my english ... it's orrible i know anyway, this is my first message to this list so i don't know if anybody has had my problems, in this case sorry ! ok here you are the problems : i can't load png images from my small python program using gdk_imlib, and also the view.py example can't do that. what did i wrong ? i have installed helix gnome on my sweet debian and i get this with imlib-config yurix@gufo:~$ imlib-config --version 1.9.8.1 yurix@gufo:~$ imlib-config --libs -L/usr/lib -lImlib -ljpeg -ltiff -lungif -lpng -lz -lm -lXext -L/usr/X11R6/lib -lSM -lICE -lXext -lX11 yurix@gufo:~$ imlib-config --cflags -I/usr/X11R6/include yurix@gufo:~$ imlib-config --libs-gdk -L/usr/lib -lgdk_imlib -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm yurix@gufo:~$ imlib-config --cflags-gdk -I/usr/lib/glib/include -I/usr/X11R6/include -I/usr/X11R6/include okay,that's all ! good nigth ! -- E-Mail: YuRiX <[EMAIL PROTECTED]> Date: 01-Aug-2000 Time: 22:38:32 This message was sent by XFMail -- ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Window Stacking Problem
On Tue, 1 Aug 2000, Mitch Chapman wrote: > Well-put, but my customer wants mode*less* dialogs. > They want to be able to continue working with the main > application after the dialog appears. > > Imagine a window full of thumbnail vector images. A single > left-click on a thumbnail brings up a resizable window > showing a larger view of the window. The number of > thumbnails, and consequently the number of enlarged views, > can be quite large. That's what the current specs call for. > > Here's the problem scenario: The user has clicked on a > thumbnail and gotten a larger view. Now the user wants to > go back to the main window and click on another thumbnail > to get another larger image to compare to the first. As soon > as they click on the new thumbnail the main window comes > forward, obscuring the original thumbnail. Alright, tell them to turn on focus follows mouse (or sloppy focus) without autoraising of windows. That way they can click in the other window without raising it. Without some control over what window manager is used, you are going to have trouble getting what you want. James. -- Email: [EMAIL PROTECTED] WWW: http://www.daa.com.au/~james/ ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Window Stacking Problem
Aaron Optimizer Digulla wrote: > > On Wed, Jul 26, 2000 at 11:35:30AM -0600, Mitch Chapman wrote: > > > It may be that I'm solving the wrong problem. In other words, > > there may be a better way to present the information that's > > currently being displayed in these modeless dialogs. But if > > y'all have any suggestions for how to solve this specific > > problem, I'd be grateful. > > The correct solution would be to fix the customer :-) > The reason why you cannot iconify modal dialogs independently > of your application is the human brain: Just imagine, your > working with your app and then suddenly, one of the modal > dialogs is in your way and you iconify it. Now you do > what you wanted when the dialog got in your way. After > some time, you go back to your app and try to continue > to work with it. But now it "hangs". You try everything > and after some time kill the app and start it again because > you didn't remember that there was an iconified modal dialog > which blocked the "hanging" application. > > Conclusion: > > - Don't use modal dialogs. Disable gadgets instead. This > gives the user a visual feedback of what is going on > unlike the modal dialogs. What you can do is you can > disable the main window of the application. This will > make the (non-modal) dialogs independent of it and you > can iconify every window indepently. Also, a user > will now see right away why he cannot work with the > application. Well-put, but my customer wants mode*less* dialogs. They want to be able to continue working with the main application after the dialog appears. Imagine a window full of thumbnail vector images. A single left-click on a thumbnail brings up a resizable window showing a larger view of the window. The number of thumbnails, and consequently the number of enlarged views, can be quite large. That's what the current specs call for. Here's the problem scenario: The user has clicked on a thumbnail and gotten a larger view. Now the user wants to go back to the main window and click on another thumbnail to get another larger image to compare to the first. As soon as they click on the new thumbnail the main window comes forward, obscuring the original thumbnail. You and I know that, with most window managers, you can just go back to the taskbar and bring the original zoomed view forward again. And our users know that, too. But in practice I've seen them get confused (not to mention annoyed) when their original zoomed view "disappears". The most obvious solution is to make the zoomed views transients for the main window, so they always stay in front of it. But this would force the user to keep dragging the zoomed views out of the way, so they could see enough of the main window to get at other thumbnails. Hence (I think) the request to make the zoomed views stay in front of, but be separately iconifiable from, the main window. We need to look at the usage scenarios in more detail. For instance, if the users tend to view only two or three zoomed views at a time, then it might not be so annoying to make them transients for the main window. Screen real estate being what it is, I can't imagine them trying to look at very many zoomed views at once. But a completely different solution might be much better. This is what you're saying, and is also what I meant by "solving the wrong problem." For instance, since users seem to be trying to compare zoomed images, it might make sense to grid the views into a zoom "dock", one which comes forward every time its content changes, but is not a transient for the main window. This would let the user create comparative views without manually dragging modeless dialogs into position, and would also get around the problem of screen-blocking transients. Guess it's time for another prototype. Thanks for helping trigger some ideas. -- Mitch Chapman [EMAIL PROTECTED] ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
Re: [pygtk] Window Stacking Problem
On Wed, Jul 26, 2000 at 11:35:30AM -0600, Mitch Chapman wrote: > It may be that I'm solving the wrong problem. In other words, > there may be a better way to present the information that's > currently being displayed in these modeless dialogs. But if > y'all have any suggestions for how to solve this specific > problem, I'd be grateful. The correct solution would be to fix the customer :-) The reason why you cannot iconify modal dialogs independently of your application is the human brain: Just imagine, your working with your app and then suddenly, one of the modal dialogs is in your way and you iconify it. Now you do what you wanted when the dialog got in your way. After some time, you go back to your app and try to continue to work with it. But now it "hangs". You try everything and after some time kill the app and start it again because you didn't remember that there was an iconified modal dialog which blocked the "hanging" application. Conclusion: - Don't use modal dialogs. Disable gadgets instead. This gives the user a visual feedback of what is going on unlike the modal dialogs. What you can do is you can disable the main window of the application. This will make the (non-modal) dialogs independent of it and you can iconify every window indepently. Also, a user will now see right away why he cannot work with the application. -- == Sowatec AG, CH-8330 Pfäffikon (ZH) Witzbergstr. 7, http://www.sowatec.com Tel: +41-(0)1-952 55 55 Fax: +41-(0)1-952 55 66 -- Aaron "Optimizer" Digulla, [EMAIL PROTECTED] == ___ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk
