Re: [python-win32] Possible future direction for PyGUI on Win32
On 28/02/2011 09:40, Tim Golden wrote: Well, the last Svn commit was 4 weeks ago, by barton_c, and Python27 support (ie switches) were added 2 months ago. Looks like Barton_C needs to do some advertising. I'll see if I can contact him/her through sf. Got this reply from Barton, who's not subscribed to this list: Using the current state of the art, I freely mix wxPython, MS Framework 2.0 (others are hooking to .NET 4.0) and ctypes in full GUI apps and drivers. The current challenge for me is getting the whole thing working (together) on Ubuntu Maverick (10.10). I have brought the PythonDotNet project up to python27 compatibility, but have not published the binaries yet. TJG ___ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
Re: [python-win32] Possible future direction for PyGUI on Win32
On Tue, Mar 1, 2011 at 5:05 AM, Tim Golden m...@timgolden.me.uk wrote: On 28/02/2011 09:40, Tim Golden wrote: Well, the last Svn commit was 4 weeks ago, by barton_c, and Python27 support (ie switches) were added 2 months ago. Looks like Barton_C needs to do some advertising. I'll see if I can contact him/her through sf. Got this reply from Barton, who's not subscribed to this list: since when is being subscribed a prerequisite to commenting? Using the current state of the art, I freely mix wxPython, MS Framework 2.0 (others are hooking to .NET 4.0) and ctypes in full GUI apps and drivers. The current challenge for me is getting the whole thing working (together) on Ubuntu Maverick (10.10). I have brought the PythonDotNet project up to python27 compatibility, but have not published the binaries yet. TJG ___ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32 -- According to theoretical physics, the division of spatial intervals as the universe evolves gives rise to the fact that in another timeline, your interdimensional counterpart received helpful advice from me...so be eternally pleased for them. ___ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
Re: [python-win32] Problem with win32print.SetPrinter
Dnia 2011-02-28, pon o godzinie 19:11 -0500, Roger Upole pisze: I think this is dependent on the printer driver. Some use the paper size defined by the the form, and others use the PaperSize member. The driver used is the generic postscript driver (MS Publisher Imagesetter) provided with Windows. My problem is that changing paper size in the default printer preferences UI changes both members of devmode. Changing the way I do it (as shown before) does not change the paper size in preferences UI - and that's exactly what I need to change. I guess that if both fields are affected by the UI then I should also change both to achieve the desired effect, right? bye, Filip Zyzniewski Tefnet ___ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
Re: [python-win32] Possible future direction for PyGUI on Win32
On 01/03/2011 10:14, David Hutto wrote: On Tue, Mar 1, 2011 at 5:05 AM, Tim Goldenm...@timgolden.me.uk wrote: On 28/02/2011 09:40, Tim Golden wrote: Well, the last Svn commit was 4 weeks ago, by barton_c, and Python27 support (ie switches) were added 2 months ago. Looks like Barton_C needs to do some advertising. I'll see if I can contact him/her through sf. Got this reply from Barton, who's not subscribed to this list: since when is being subscribed a prerequisite to commenting? FWIW, I meant: ... and who had therefore not seen this discussion but, as a matter of fact, if a non-subscriber posts to this list, the post is held in a moderator's queue and has to be released explicitly. I've given him the information about this list, of which he was unaware so he can decide for himself whether to post or subscribe or whatever... TJG ___ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
Re: [python-win32] Possible future direction for PyGUI on Win32
On 1 March 2011 07:44, Octavian Rasnita orasn...@gmail.com wrote: From: Greg Ewing greg.ew...@canterbury.ac.nz Octavian Rasnita wrote: From: Greg Ewing greg.ew...@canterbury.ac.nz No, if I go this way, I would probably stop maintaining the current implementation. Oh, in that case imho I think this is a very bad idea. Can you elaborate on exactly what is bad about it, and suggest an alternative? Windows Forms - based apps have a few disadvantages: - First, the most important, and with no solution is that Win32 GUI widgets are much fast responsive than Windows Forms, I've written (quite large) desktop Windows Forms applications with .NET and just not found this to be the case - even when written with IronPython which isn't the fastest .NET language there is. and it is annoying to use Windows Forms - based apps with the keyboard; This need not be the case. You just need to set tab order and provide shortcuts. - Second, it is harder to create executables that include the support for DotNet, because it is not sure that DotNet is available. .NET is pretty ubiquitous these days - see other emails on the topic. The package should be either very big and include DotNet, Definitely not. or it should detect if it is not present and offer the possibility of downloading it from the web, but some computers are not connected to the internet...; Installers can detect this and provide a link. - Windows Forms offer very many accessibility features for screen readers, however this GUI is *always* less accessible than the standard Win32 widgets for those who need to use a screen reader. Evidence for this? - I think there are solutions for making Windows Forms - based apps already, and they can be used if somebody prefers to use this GUI, so it wouldn't be a good idea to dupplicate it and offer the same interface. The point is for writing *cross platform* applications that just happen to use Windows Forms on Windows. All the best, Michael Foord The standard Windows GUI API is severely crippled compared to what is available natively in Cocoa and Gtk. The only alternatives I see at the moment are: * Allow Windows to hold back the development of PyGUI on all the other platforms. * Implement the missing functionality on Windows in pure Python -- a lot of work, and probably not practical for something complex such as a rich text or HTML widget. * Rely on a third party library to supply the missing functionality on Windows. -- Greg I don't know which of these ways would be the most simple to implement, but it is true that it will be more difficult, because I've seen how these problems were solved in other GUIs like wxWIDGETS and SWT. wxWIDGETS offers custom widgets for those which are not offered by the standard Win32 API, but most of them are badly made with no corresponding accessibility features, and if those widgets are used in an application, they could steal the focus or make other problems that make the whole application not accessible for those who use a screen reader. So a better solution than the one offered by wxWIDGETS would mean much more work. In SWT, as far as I know, those widgets which are not offered by the Win32 API are not offered at all, but I am not sure, so others who may know more can comment. But if this is true, this is not an extraordinary solution either. However, I don't know if the focus should be to offer all the possible widget types under all platforms, because now there are more and more platforms considered, like different kind of PDAs and mobile phones, and it would probably be very hard or impossible to offer a GUI that can do everything everywhere. Octavian ___ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32 -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
Re: [python-win32] (again) get Window Title encoding
Hello, i wan't to decode the title to utf-8 'mbcs' encoding doesn't help me sometimes the browser surf on russian, japanese, chinese language and i couldn't decode if i don't know the encoding. thanks for your help Roche Maxime Le 28 févr. 2011 à 22:57, Mark Hammond a écrit : You might find the 'mbcs' encoding is what you are after? Cheers, Mark On 28/02/2011 11:22 PM, Creative iNFiNiTY wrote: here is some code to get the window title: hwnd = win32gui.GetForegroundWindow() # we want the desktop window objid = pyAA.Constants.OBJID_WINDOW # get the object ao = pyAA.AccessibleObjectFromWindow(hwnd, objid) pr= ao.GetProcessAndThreadID() processes = win32process.EnumProcesses() for pid in processes: if pid in pr: handle = win32api.OpenProcess(win32con.PROCESS_ALL_ACCESS,False, pid) processactif=win32process.GetModuleFileNameEx(handle, 0) WindowTitle=ao.Name another code: importwin32gui w=win32gui w.GetWindowText (w.GetForegroundWindow()) * * and i need to get the encoding of the title for internalisation purpose, does anyone know how to get it ? the automatic charset recognition in python , chardet don't work for every charset, if i can take it by the process that will be great. Thanks Roche Maxime Creative iNFiNiTY ___ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32 ___ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
Re: [python-win32] (again) get Window Title encoding
On 1/03/2011 10:38 PM, Creative iNFiNiTY wrote:
Hello,
i wan't to decode the title to utf-8
'mbcs' encoding doesn't help me
sometimes the browser surf on russian, japanese, chinese language
and i couldn't decode if i don't know the encoding.
thanks for your help
You can't decode the title to utf8 - what you need to do is decode the
title *from* whatever encoding it is in, then encode it to utf8. So
something like window_title.decode('mbcs').encode('utf-8') should work
in most cases.
HTH,
Mark
___
python-win32 mailing list
python-win32@python.org
http://mail.python.org/mailman/listinfo/python-win32
Re: [python-win32] Problem with win32print.SetPrinter
Tefnet Developers develop...@tefnet.pl wrote in message news:1298974742.7642.1.camel@cacko... Dnia 2011-02-28, pon o godzinie 19:11 -0500, Roger Upole pisze: I think this is dependent on the printer driver. Some use the paper size defined by the the form, and others use the PaperSize member. The driver used is the generic postscript driver (MS Publisher Imagesetter) provided with Windows. My problem is that changing paper size in the default printer preferences UI changes both members of devmode. Changing the way I do it (as shown before) does not change the paper size in preferences UI - and that's exactly what I need to change. I guess that if both fields are affected by the UI then I should also change both to achieve the desired effect, right? bye, Filip Zyzniewski Tefnet Try adding a second GetPrinter immediately after the SetPrinter, and see if the returned devmode has the expected values. Roger ___ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
Re: [python-win32] Problem with win32print.SetPrinter
Roger Upole wrote: Tefnet Developers develop...@tefnet.pl wrote in message news:1298974742.7642.1.camel@cacko... The driver used is the generic postscript driver (MS Publisher Imagesetter) provided with Windows. My problem is that changing paper size in the default printer preferences UI changes both members of devmode. Changing the way I do it (as shown before) does not change the paper size in preferences UI - and that's exactly what I need to change. I guess that if both fields are affected by the UI then I should also change both to achieve the desired effect, right? bye, Filip Zyzniewski Tefnet Try adding a second GetPrinter immediately after the SetPrinter, and see if the returned devmode has the expected values. This kind of thing is very tricky in Windows -- much trickier than it should be -- and I've been doing Windows programming for a very, very long time. I have a wxPython application that I use to print envelopes through my Dell 3100 laser printer. The printer has a multi-purpose tray that I keep stocked with #10 envelopes. It's very convenient, and since my handwriting it terrible, the people I write to appreciate it as well. Recently, I upgraded from Python 2.5 to Python 2.7, and suddenly my envelope application stopped working. It would print in portrait mode on the normal paper stock, instead of selecting the envelopes in the multi-purpose tray. It required two or three hours of fairly intense hacking before I figured out a recipe to make it work again. If I had not previously been a GDI driver developer, I doubt that I could have figured out the DEVMODE magic that was required. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. ___ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
