Re: [pygtk] Verifying Entry inputs
On Sat, Mar 12, 2005 at 03:32:28AM +0100, Jakub Piotr C?apa wrote: > >Correction: we're sorting out anonymous access to the repository. SVN > >isn't the piece of cake to serve that I would have hoped, but we're > >getting to it. We'll notify the list when it's ready. > > Why don't you serve SVN through HTTP (Apache mod_dav_svn)? It's pretty > simple and works really good. Because we're Apache 1.3 holdouts! svnserve's been set up meanwhile; let's hope it holds up. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Kiwi2 repository (was Re: [pygtk] Verifying Entry inputs)
Ok, I'm sorry I was to fast posting the repository url before we really decided how we were going to set it up finally. Now, we actually have tested it and I can say you can get it here: svn co svn://www.async.com.br/Kiwi2 no passwords this time. But note that: a) Kiwi2 is far from being finished and by no means is ready to use b) There is no validation code yet. Nothing. I'm just posting the url here because it looks like some people was interested in that. regards Lorenzo On Sat, 2005-03-12 at 19:45 +0100, Danny Milosavljevic wrote: > Hi, > > Am Freitag, den 11.03.2005, 11:34 +0100 schrieb Lorenzo Gil Sanchez: > > svn checkout svn+ssh://[EMAIL PROTECTED]/pub/Kiwi2 > > password: anonymous > > are you sure that works ? :) > > cheers, > Danny > ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
Hi, Am Freitag, den 11.03.2005, 11:09 -0300 schrieb Christian Robottom Reis: > On Fri, Mar 11, 2005 at 02:03:13PM +, Gustavo J. A. M. Carneiro wrote: > > Well, that would be interesting idea, but unfeasible in X11 until we > > have Composite X.Org extension widely deployed and stable. > > You mean you're still one of those XFree86 holdouts? Bah! Just to voice that: Composite has bug like hell for me. So I had to turn it off :) cheers, Danny -- www.keyserver.net key id A334AEA6 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
Hi, Am Freitag, den 11.03.2005, 11:34 +0100 schrieb Lorenzo Gil Sanchez: > svn checkout svn+ssh://[EMAIL PROTECTED]/pub/Kiwi2 > password: anonymous are you sure that works ? :) cheers, Danny -- www.keyserver.net key id A334AEA6 signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
Christian Robottom Reis wrote: On Fri, Mar 11, 2005 at 09:02:42AM -0300, Christian Reis wrote: On Sat, Feb 26, 2005 at 01:13:49PM +, John Gill wrote: Can you point me at the Kiwi2 code, I hadn't realised work had started on Kiwi2? Lorenzo has an SVN repository set up here at Async; Lorenzo, care to send the address to the list? Correction: we're sorting out anonymous access to the repository. SVN isn't the piece of cake to serve that I would have hoped, but we're getting to it. We'll notify the list when it's ready. Why don't you serve SVN through HTTP (Apache mod_dav_svn)? It's pretty simple and works really good. -- Regards, Jakub Piotr Cłapa ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
Dammit! two mistakes in my short mail: svn checkout svn+ssh://[EMAIL PROTECTED]/pub/Kiwi2 password: anonymous Sorry about that On Fri, 2005-03-11 at 11:22 +0100, Lorenzo Gil Sanchez wrote: > Kiwi2 svn instructions: > > svn checkout svn+ssh://[EMAIL PROTECTED]/pub/Kiw2 > password: anoncvs > > maybe it ask twice for the password. That's ok. > > Lorenzo > > On Fri, 2005-03-11 at 10:30 -0300, Christian Robottom Reis wrote: > > On Fri, Mar 11, 2005 at 09:02:42AM -0300, Christian Reis wrote: > > > On Sat, Feb 26, 2005 at 01:13:49PM +, John Gill wrote: > > > >Can you point me at the Kiwi2 code, I hadn't realised work had > > > > started on > > > >Kiwi2? > > > > > > Lorenzo has an SVN repository set up here at Async; Lorenzo, care to > > > send the address to the list? > > > > Correction: we're sorting out anonymous access to the repository. SVN > > isn't the piece of cake to serve that I would have hoped, but we're > > getting to it. We'll notify the list when it's ready. > > > > Take care, > > -- > > Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 -- Lorenzo Gil Sanchez <[EMAIL PROTECTED]> ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
Kiwi2 svn instructions: svn checkout svn+ssh://[EMAIL PROTECTED]/pub/Kiw2 password: anoncvs maybe it ask twice for the password. That's ok. Lorenzo On Fri, 2005-03-11 at 10:30 -0300, Christian Robottom Reis wrote: > On Fri, Mar 11, 2005 at 09:02:42AM -0300, Christian Reis wrote: > > On Sat, Feb 26, 2005 at 01:13:49PM +, John Gill wrote: > > >Can you point me at the Kiwi2 code, I hadn't realised work had started > > > on > > >Kiwi2? > > > > Lorenzo has an SVN repository set up here at Async; Lorenzo, care to > > send the address to the list? > > Correction: we're sorting out anonymous access to the repository. SVN > isn't the piece of cake to serve that I would have hoped, but we're > getting to it. We'll notify the list when it's ready. > > Take care, > -- > Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 -- Lorenzo Gil Sanchez <[EMAIL PROTECTED]> ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Fri, Mar 11, 2005 at 02:03:13PM +, Gustavo J. A. M. Carneiro wrote: > Well, that would be interesting idea, but unfeasible in X11 until we > have Composite X.Org extension widely deployed and stable. You mean you're still one of those XFree86 holdouts? Bah! Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Fri, 2005-03-11 at 08:31 -0500, Steve McClure wrote: > On Fri, 2005-03-11 at 07:08, Christian Reis wrote: > > On Sun, Feb 27, 2005 at 11:52:41PM +, Gustavo J. A. M. Carneiro wrote: > > > On Sat, 2005-02-26 at 08:43 -0300, Christian Reis wrote: > > > >On Fri, Feb 25, 2005 at 11:08:00AM +, Gustavo J. A. M. Carneiro > > > >wrote: > > > >> My solution, although also not perfect, was to place a small > > > >> gtk.STOCK_DIALOG_WARNING icon inside the entry, and toggle between > > > >> making it insensitive (=value OK) or sensitive (=bad value). > > > > > > > >Interesting! Can we see some screenshots of this? > > > > > > Attached. Code in [1], but you won't be able to run it without > > > modifications (or installing gnumexp), I'm afraid. > > > > Would it be worse to make the icon invisible instead of inactive? > > > > Second question is if it would be possible to right-align the icon > > (instead of left-aligning it, where it makes reading a bit more > > difficult). > > > > > > I had never thought of > > > >this approach and it sounds way cool (though it _does_ take up some of > > > >the entry's real estate). Dream scenario might be a window which > > > >overlays the screen when a validation error occurs. > > > > > > Now that I don't understand. Can you explain better? "window which > > > overlays the screen"? > > > > Basically, balloon help for input errors. > > > > .---. > > | sin(x)+ .---. > > '-| /!\ This should be a valid expression | > > '---' I would find this a bit too annoying. Validation should be much more dissimulated, IMHO. > > > > It could be that this appeared only when a certain time had passed > > (though the input would still be considered invalid) or if focus left > > the input area. > > Jef Raskin mentions this in The Humane Interface. In his view, the > message window should be semi-transparent and not interfere with work. > That is, you don't have to click on it to acknowledge it, just keep > typing/clicking and it then will eventually fade away. He likes that > concept in place of dialogs that popup and require you to read the > message and click OK to continue. It seems appropriate here as well, > they just wouldn't fade away until the error is cleared up. Well, that would be interesting idea, but unfeasible in X11 until we have Composite X.Org extension widely deployed and stable. > > > > But I have come to generally think that multiple mechanisms for > > different types of validation errors are the way to go; that implies > > having a [small] set of forms of feedback implemented in a library. Agreed. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. smime.p7s Description: S/MIME cryptographic signature ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Fri, 2005-03-11 at 07:08, Christian Reis wrote: > On Sun, Feb 27, 2005 at 11:52:41PM +, Gustavo J. A. M. Carneiro wrote: > > On Sat, 2005-02-26 at 08:43 -0300, Christian Reis wrote: > > >On Fri, Feb 25, 2005 at 11:08:00AM +, Gustavo J. A. M. Carneiro wrote: > > >> My solution, although also not perfect, was to place a small > > >> gtk.STOCK_DIALOG_WARNING icon inside the entry, and toggle between > > >> making it insensitive (=value OK) or sensitive (=bad value). > > > > > >Interesting! Can we see some screenshots of this? > > > > Attached. Code in [1], but you won't be able to run it without > > modifications (or installing gnumexp), I'm afraid. > > Would it be worse to make the icon invisible instead of inactive? > > Second question is if it would be possible to right-align the icon > (instead of left-aligning it, where it makes reading a bit more > difficult). > > > > I had never thought of > > >this approach and it sounds way cool (though it _does_ take up some of > > >the entry's real estate). Dream scenario might be a window which > > >overlays the screen when a validation error occurs. > > > > Now that I don't understand. Can you explain better? "window which > > overlays the screen"? > > Basically, balloon help for input errors. > > .---. > | sin(x)+ .---. > '-| /!\ This should be a valid expression | > '---' > > It could be that this appeared only when a certain time had passed > (though the input would still be considered invalid) or if focus left > the input area. Jef Raskin mentions this in The Humane Interface. In his view, the message window should be semi-transparent and not interfere with work. That is, you don't have to click on it to acknowledge it, just keep typing/clicking and it then will eventually fade away. He likes that concept in place of dialogs that popup and require you to read the message and click OK to continue. It seems appropriate here as well, they just wouldn't fade away until the error is cleared up. > > But I have come to generally think that multiple mechanisms for > different types of validation errors are the way to go; that implies > having a [small] set of forms of feedback implemented in a library. > > > An interesting idea that I might try someday would be to reserve some > > empty space in the dialogue window, and display in that space validation > > errors as they occur. > > We do this in some of our interfaces; it works well but requires you to > design this in up-front. > > > [2] http://www.galilea.cl/~snmartin/b2evolution/blogs/index.php > > Interesting, will take a look. > > Take care, > -- > Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 > ___ > pygtk mailing list pygtk@daa.com.au > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ -- Steve McClure Racemi email: [EMAIL PROTECTED]75 5th St NE voice: 404-892-5850 Suite 333 fax: 404-892-7215 Atlanta, GA 30308 http://www.racemi.com ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Fri, Mar 11, 2005 at 09:02:42AM -0300, Christian Reis wrote: > On Sat, Feb 26, 2005 at 01:13:49PM +, John Gill wrote: > >Can you point me at the Kiwi2 code, I hadn't realised work had started on > >Kiwi2? > > Lorenzo has an SVN repository set up here at Async; Lorenzo, care to > send the address to the list? Correction: we're sorting out anonymous access to the repository. SVN isn't the piece of cake to serve that I would have hoped, but we're getting to it. We'll notify the list when it's ready. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Sun, Feb 27, 2005 at 11:52:41PM +, Gustavo J. A. M. Carneiro wrote: > On Sat, 2005-02-26 at 08:43 -0300, Christian Reis wrote: > >On Fri, Feb 25, 2005 at 11:08:00AM +, Gustavo J. A. M. Carneiro wrote: > >> My solution, although also not perfect, was to place a small > >> gtk.STOCK_DIALOG_WARNING icon inside the entry, and toggle between > >> making it insensitive (=value OK) or sensitive (=bad value). > > > >Interesting! Can we see some screenshots of this? > > Attached. Code in [1], but you won't be able to run it without > modifications (or installing gnumexp), I'm afraid. Would it be worse to make the icon invisible instead of inactive? Second question is if it would be possible to right-align the icon (instead of left-aligning it, where it makes reading a bit more difficult). > > I had never thought of > >this approach and it sounds way cool (though it _does_ take up some of > >the entry's real estate). Dream scenario might be a window which > >overlays the screen when a validation error occurs. > > Now that I don't understand. Can you explain better? "window which > overlays the screen"? Basically, balloon help for input errors. .---. | sin(x)+ .---. '-| /!\ This should be a valid expression | '---' It could be that this appeared only when a certain time had passed (though the input would still be considered invalid) or if focus left the input area. But I have come to generally think that multiple mechanisms for different types of validation errors are the way to go; that implies having a [small] set of forms of feedback implemented in a library. > An interesting idea that I might try someday would be to reserve some > empty space in the dialogue window, and display in that space validation > errors as they occur. We do this in some of our interfaces; it works well but requires you to design this in up-front. > [2] http://www.galilea.cl/~snmartin/b2evolution/blogs/index.php Interesting, will take a look. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Sat, Feb 26, 2005 at 01:13:49PM +, John Gill wrote: >Can you point me at the Kiwi2 code, I hadn't realised work had started on >Kiwi2? Lorenzo has an SVN repository set up here at Async; Lorenzo, care to send the address to the list? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Sat, 2005-02-26 at 08:43 -0300, Christian Reis wrote: >On Fri, Feb 25, 2005 at 11:08:00AM +, Gustavo J. A. M. Carneiro wrote: >> My solution, although also not perfect, was to place a small >> gtk.STOCK_DIALOG_WARNING icon inside the entry, and toggle between >> making it insensitive (=value OK) or sensitive (=bad value). > >Interesting! Can we see some screenshots of this? Attached. Code in [1], but you won't be able to run it without modifications (or installing gnumexp), I'm afraid. > I had never thought of >this approach and it sounds way cool (though it _does_ take up some of >the entry's real estate). Dream scenario might be a window which >overlays the screen when a validation error occurs. Now that I don't understand. Can you explain better? "window which overlays the screen"? An interesting idea that I might try someday would be to reserve some empty space in the dialogue window, and display in that space validation errors as they occur. >One of the issues with validation is a performance issue -- some stuff >takes a while to validate (checking database contents, etc). In my case, validation is very quick. It is just about sending the entry context through a math expression parser in a corba server. Nevertheless, validation occurs only after 100ms timeout, to avoid interrupting gtk+ event processing too often. > Another is >the fact that certain patterns are only really validatable when >completely entered (i.e. 123. is invalid but 123.2 is not, though I'm >thinking of more complex situations than this -- involving database >contents as well). Well, if the validation feedback is non-intrusive, like in my example, it's not too annoying to validate in real time, I think.. > >This is one of the two major unsolved issues for me in UI work using >GTK+. The other issue is selecting an item from a large (potentially >database-driven) collection -- autocompletion combos are close, but >still not what we really need. Fernando San Martin Woerner decided to use EntryCompletion for this, and added a pixmap for validation, which is from where I stole my idea. See PixEntryCompletion in [2]. [1] http://cvs.sourceforge.net/viewcvs.py/numexp/gnumexp/src/xygraph/Numexp_XYGraph/dialogs/util.py?rev=1.11&view=auto [2] http://www.galilea.cl/~snmartin/b2evolution/blogs/index.php Best regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic <><>___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
Rafael Villar Burke: > As you seem to know well the Tkinter API for doing this, maybe it's > interesting to try to mimic it in pygtk... would you date to give a try > to that on top of the PixEntryCompletion work?. Not that well, sorry. It's a few years I did it, and all I remember is that it was a very simple, straightforward thing. Even worse, my knowledge of (py)GTK is rather limited. I have no real grasp on the inner workings. ;-( Regards, -- Hans-Joachim Widmaier ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
> Thanks for all of your suggestions! Looks like I wasn't too far off. > Looking at entryvalidator.py, I cannot help but wonder why the > insert-text callback receives the arguments it does ... Especially > the position argument is of absolutely no use. Yes, the position argument to the 'insert-text' callback is frustrating. It can be used in C and C++, but it's an opaque type in pygtk. GTK+ passes it by reference, and this design seems to be quite hostile to language bindings. The gtk.idle_add() trick to set the cursor is either a clever solution or an ugly hack depending on how you look at it. I consider it to be a necessary evil and I salute those who came up with the idea and shared it with the rest of us. There was some discussion of how to provide feedback for invalid entries. I'm not sure there's a single best way to do this, but here are some more ideas. It's really just brainstorming to throw some ideas out there. Some of these can be used together, others are mutually exclusive. 1. You suggest beeping in a comment in your code. Good idea, as long as you provide other feedback for deaf users. Use gtk.gdk.Display.beep(). 2. In some cases you can simply not allow any invalid characters to be inserted into the entry. This is the very best technique if it works for your situation. It's easy to do if every prefix of a valid entry is also a valid entry because then the entry will always be in a valid state. Since there's no way for the user to enter invalid data you never have to worry about signalling an error. The floating point input example you are talking about is an excellent example of where this is not the case so this technique is hard to apply here. 3. A typical GNOME app would probably put an error message in the status bar at the bottom of the application window. Unfortunately a lot of validation is done in property windows which usually don't have status bars. 4. Don't allow focus to leave the entry if the input is invalid. Sometimes this behavior is really annoying, but I think it can work well as long as you at least temporarily allow the user to clear the entry and proceed. 5. If instead you do allow focus to leave the entry if input is invalid, make sure that after a failed attempt to apply or an error is indicated that you set focus on the entry with invalid input. 6. When invalid input is entered, select the invalid characters using editable.select_region(). (Unfortunately this has to be done in an idle callback.) I like this because it gives a visual indication of the bad input and makes it easy for the user to repair. As soon as the user starts typing in the entry the bad input will be overwritten. 7. Set the tooltip text on the entry to indicate what the problem is. I've never tried this and I suspect it wouldn't really help much. 8. Make the OK or Apply buttons insensitive until all the necessary fields validate. I think there are two differing views of this. Because there's no way to submit invalid data, you don't need to pop an error dialog to tell the user what he did wrong. On the other hand, it's hard to give the user an explanation of why the buttons are insensitive and that may cause frustration if the reason is an obscure validation problem. Maybe whether this is a good idea or not depends on your application. You could set a tooltip on the OK or Apply button to indicate why they are insensitive. 9. Flash the entry on invalid input by switching the foreground and background colors a few times. This is similar to other's suggestions. I've never tried this because I don't like to work that hard and I'm not sure it would work well. 10. Use Gustavo's suggestion of using a small icon in the entry to indicate bad input. I've also thought about using doing something similar to indicate required fields. ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
Christian Reis wrote: Re: [pygtk] Verifying Entry inputs On Fri, Feb 25, 2005 at 01:24:23PM +, Gustavo J. A. M. Carneiro wrote: > >It would be great having a "repository" for this pygtk friendly widgets > >if they are general enough... > > I was hoping kiwi2 could be such repository... ;-) It will be -- we're still crawling towards where we want to be, but once the basic infrastructure is laid out we will be adding these bits quickly. Excellent. I've felt for a while that pygtk needs a slightly higher level interface doing the sort of stuff that Kiwi does. Pygtk is a wonderful package to use, but often things work at too low a level + this leads to inconsistency between apps as people roll-their-own solutions to the same problems. Can you point me at the Kiwi2 code, I hadn't realised work had started on Kiwi2? John ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Fri, Feb 25, 2005 at 01:24:23PM +, Gustavo J. A. M. Carneiro wrote: > >It would be great having a "repository" for this pygtk friendly widgets > >if they are general enough... > > I was hoping kiwi2 could be such repository... ;-) It will be -- we're still crawling towards where we want to be, but once the basic infrastructure is laid out we will be adding these bits quickly. > Also missing, and related to this, is gtk forms. A gtk.Dialog > subclass that emits a signal to ask for validation, and another signal > to indicate 'apply these values'. The 'validate' signal handler could > check all widgets in the dialog to see if they have valid values and > return a boolean. The 'apply' signal would let the user add handler > that fetches values from the form widgets and applies them to the > application. The dialog could also track the modified state of the > widgets to make the apply button sensitive only when there are changes. > Also, a simple method would be nice to tell the dialog whether to have > apply/cancel/ok buttons (explicit apply), or only close (instant apply), > without bothering the programmer with more details. > We have this implemented as part of Kiwi and a bit of Stoqlib, which were GTK+1.2-based. Part of the work now is to move these bits to GTK+2.x and make them annoy Lorenzo less (there is a world of evil in Kiwi, and not all of it is really necessary in the 2.x realm). Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Fri, Feb 25, 2005 at 11:08:00AM +, Gustavo J. A. M. Carneiro wrote: > My solution, although also not perfect, was to place a small > gtk.STOCK_DIALOG_WARNING icon inside the entry, and toggle between > making it insensitive (=value OK) or sensitive (=bad value). Interesting! Can we see some screenshots of this? I had never thought of this approach and it sounds way cool (though it _does_ take up some of the entry's real estate). Dream scenario might be a window which overlays the screen when a validation error occurs. One of the issues with validation is a performance issue -- some stuff takes a while to validate (checking database contents, etc). Another is the fact that certain patterns are only really validatable when completely entered (i.e. 123. is invalid but 123.2 is not, though I'm thinking of more complex situations than this -- involving database contents as well). This is one of the two major unsolved issues for me in UI work using GTK+. The other issue is selecting an item from a large (potentially database-driven) collection -- autocompletion combos are close, but still not what we really need. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Fri, Feb 25, 2005 at 09:11:56AM +0100, Hans-Joachim Widmaier wrote: > I'd like to have Entry widgets that allow only numbers (float) as inputs, and > only > in a certain range. This verification should be done as soon as the user is > done > with editing. I tried the focus-out-event, but pygtk didn't like me bringing > up a > modal (error) dialog in the callback. Second try was with an insert-text > handler > which just ignored invalid inputs. It looks like this: On the general topic of input validation, I have a few comments at http://bugzilla.gnome.org/show_bug.cgi?id=50276 which may interest you. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3361 2331 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
Hans-Joachim Widmaier wrote: Thanks for all of your suggestions! Looks like I wasn't too far off. Looking at entryvalidator.py, I cannot help but wonder why the insert-text callback receives the arguments it does ... Especially the position argument is of absolutely no use. This kind of stuff is quite easier to do with Tkinter, I'm afraid. As you seem to know well the Tkinter API for doing this, maybe it's interesting to try to mimic it in pygtk... would you date to give a try to that on top of the PixEntryCompletion work?. Take care, Pachi ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
Thanks for all of your suggestions! Looks like I wasn't too far off. Looking at entryvalidator.py, I cannot help but wonder why the insert-text callback receives the arguments it does ... Especially the position argument is of absolutely no use. This kind of stuff is quite easier to do with Tkinter, I'm afraid. Again, thanks a lot! Hans-J. Widmaier __ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201 ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Fri, 2005-02-25 at 13:09 +0100, Rafael Villar Burke wrote: >Gustavo J. A. M. Carneiro wrote: > >>On Fri, 2005-02-25 at 10:57 +, John Gill wrote: >> >> >>>See attached code for a way to provide visual feedback as the entry is >>>edited. >>> >>> >> >> I was recently faced with the same problem. I thought about this very >>same solution, but in the end I gave it up because hardcoding background >>colour is bad when interacting with themes. For instance, you change >>the background between white and red. This particular pair of colours >>make look bad in some themes. Moreover, dark themes will likely have a >>white or light text colour, and in this case white text in white >>background will disappear. >> >> My solution, although also not perfect, was to place a small >>gtk.STOCK_DIALOG_WARNING icon inside the entry, and toggle between >>making it insensitive (=value OK) or sensitive (=bad value). >> >> >I also had that problem with a "Table for dummies" widget and took the >following solution: >Requesting the gtk.Style object and use one of the colors of a state >other than normal, depending on what you are doing. In my case this was >the base color in a cell. For the entry validation case, it could be >even better to animate the effect, perhaps by rotating through a pair of >these colors... but I haven't implemented this:). > >This is what I did for a treeview... > >def get_color_string(color): >assert isinstance(color, gtk.gdk.Color) >return "#%04X%04X%04X" % (color.red, color.green, color.blue) > >temp_tv = gtk.TreeView() >normal_color = get_color_string(temp_tv.get_style().base[gtk.STATE_NORMAL]) >strong_color = >get_color_string(temp_tv.get_style().base[gtk.STATE_SELECTED]) >del temp_tv Interesting idea, but, I'm not sure if there is any widget state whose colours can be interpreted by the user as meaning the value of the entry is [not] correct. > >Fernando Sanmartín Woerner also wrote some sort of a validating >gtk.Entry IIRC for its use in pygestor called PixEntryCompletion. Your >can get the code for pygestor here: >http://www.galilea.cl/gestor/descargas.html and see PixEntryCompletion >in action (swf screen capture) here: >http://www.galilea.cl/~snmartin/swf/pec/pec.html Yes, I based my code on his idea! :-) > >It would be great having a "repository" for this pygtk friendly widgets >if they are general enough... I was hoping kiwi2 could be such repository... ;-) Also missing, and related to this, is gtk forms. A gtk.Dialog subclass that emits a signal to ask for validation, and another signal to indicate 'apply these values'. The 'validate' signal handler could check all widgets in the dialog to see if they have valid values and return a boolean. The 'apply' signal would let the user add handler that fetches values from the form widgets and applies them to the application. The dialog could also track the modified state of the widgets to make the apply button sensitive only when there are changes. Also, a simple method would be nice to tell the dialog whether to have apply/cancel/ok buttons (explicit apply), or only close (instant apply), without bothering the programmer with more details. Regards. -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic. smime.p7s Description: S/MIME cryptographic signature ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
Gustavo J. A. M. Carneiro wrote: On Fri, 2005-02-25 at 10:57 +, John Gill wrote: See attached code for a way to provide visual feedback as the entry is edited. I was recently faced with the same problem. I thought about this very same solution, but in the end I gave it up because hardcoding background colour is bad when interacting with themes. For instance, you change the background between white and red. This particular pair of colours make look bad in some themes. Moreover, dark themes will likely have a white or light text colour, and in this case white text in white background will disappear. My solution, although also not perfect, was to place a small gtk.STOCK_DIALOG_WARNING icon inside the entry, and toggle between making it insensitive (=value OK) or sensitive (=bad value). I also had that problem with a "Table for dummies" widget and took the following solution: Requesting the gtk.Style object and use one of the colors of a state other than normal, depending on what you are doing. In my case this was the base color in a cell. For the entry validation case, it could be even better to animate the effect, perhaps by rotating through a pair of these colors... but I haven't implemented this:). This is what I did for a treeview... def get_color_string(color): assert isinstance(color, gtk.gdk.Color) return "#%04X%04X%04X" % (color.red, color.green, color.blue) temp_tv = gtk.TreeView() normal_color = get_color_string(temp_tv.get_style().base[gtk.STATE_NORMAL]) strong_color = get_color_string(temp_tv.get_style().base[gtk.STATE_SELECTED]) del temp_tv Fernando Sanmartín Woerner also wrote some sort of a validating gtk.Entry IIRC for its use in pygestor called PixEntryCompletion. Your can get the code for pygestor here: http://www.galilea.cl/gestor/descargas.html and see PixEntryCompletion in action (swf screen capture) here: http://www.galilea.cl/~snmartin/swf/pec/pec.html It would be great having a "repository" for this pygtk friendly widgets if they are general enough... Pachi ___ pygtk mailing list pygtk@daa.com.au http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Fri, 2005-02-25 at 10:57 +, John Gill wrote:
>See attached code for a way to provide visual feedback as the entry is
>edited.
I was recently faced with the same problem. I thought about this very
same solution, but in the end I gave it up because hardcoding background
colour is bad when interacting with themes. For instance, you change
the background between white and red. This particular pair of colours
make look bad in some themes. Moreover, dark themes will likely have a
white or light text colour, and in this case white text in white
background will disappear.
My solution, although also not perfect, was to place a small
gtk.STOCK_DIALOG_WARNING icon inside the entry, and toggle between
making it insensitive (=value OK) or sensitive (=bad value).
Regards.
>
>John
>
>Hans-Joachim Widmaier wrote:
>>Hi all,
>>
>>I'd like to have Entry widgets that allow only numbers (float) as
>>inputs, and only
>>in a certain range. This verification should be done as soon as the
>>user is done
>>with editing. I tried the focus-out-event, but pygtk didn't like me
>>bringing up a
>>modal (error) dialog in the callback. Second try was with an
>>insert-text handler
>>which just ignored invalid inputs. It looks like this:
>>
>>def myInsertText(self, widget, new_text, new_text_length, position):
>>oldtext = widget.get_text()
>># Avoid recursion
>>widget.handler_block(widget.mySigHandID)
>># Insert text and check for validity
>>pos = widget.get_position()
>>widget.insert_text(new_text, pos)
>>newtext = widget.get_text()
>>try:
>>value = float(newtext)
>>except ValueError:
>># Restore previous contents
>>widget.delete_text(pos, pos + new_text_length)
>># XXX Something like a beep might be nice here
>>else:
>>widget.set_position(pos + new_text_length)
>>widget.handler_unblock(widget.mySigHandID)
>>
>># Keep normal handler from running
>>widget.stop_emission("insert-text")
>>
>>In this version I simply can't get the cursor to appear *after* the
>>inserted text, the widget.set_position() call seems to do just
>>nothing.
>>
>>Is there a fundamental flaw in my routine or my whole concept?
>>I'd be really glad to get some recommendations.
>>
>>Thanks,
>>Hans-J. Widmaier
>>__
>>Verschicken Sie romantische, coole und witzige Bilder per SMS!
>>Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
>>
>>___
>>pygtk mailing list pygtk@daa.com.au
>>http://www.daa.com.au/mailman/listinfo/pygtk
>>Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
>>
>___
>pygtk mailing list pygtk@daa.com.au
>http://www.daa.com.au/mailman/listinfo/pygtk
>Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
--
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic.
smime.p7s
Description: S/MIME cryptographic signature
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
See attached code for a way to provide visual feedback
as the entry is edited.
John
Hans-Joachim Widmaier wrote:
[pygtk] Verifying Entry inputs
Hi all,
I'd like to have Entry widgets that allow only
numbers (float) as inputs, and only
in a certain range. This verification should be done
as soon as the user is done
with editing. I tried the focus-out-event, but pygtk
didn't like me bringing up a
modal (error) dialog in the callback. Second try was
with an insert-text handler
which just ignored invalid inputs. It looks like this:
def myInsertText(self, widget, new_text,
new_text_length, position):
oldtext = widget.get_text()
# Avoid recursion
widget.handler_block(widget.mySigHandID)
# Insert text and check for validity
pos = widget.get_position()
widget.insert_text(new_text, pos)
newtext = widget.get_text()
try:
value = float(newtext)
except ValueError:
# Restore previous contents
widget.delete_text(pos, pos +
new_text_length)
# XXX Something like a beep might be nice
here
else:
widget.set_position(pos + new_text_length)
widget.handler_unblock(widget.mySigHandID)
# Keep normal handler from running
widget.stop_emission("insert-text")
In this version I simply can't get the cursor to
appear *after* the
inserted text, the widget.set_position() call seems to
do just nothing.
Is there a fundamental flaw in my routine or my
whole concept?
I'd be really glad to get some recommendations.
Thanks,
Hans-J. Widmaier
__
Verschicken Sie romantische, coole und witzige Bilder
per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
entryvalidator.py
Description: application/python
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
Re: [pygtk] Verifying Entry inputs
On Fri, 25 Feb 2005 09:11:56 +0100, Hans-Joachim Widmaier
<[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'd like to have Entry widgets that allow only numbers (float) as inputs, and
> only
> in a certain range.
May be this function will help you:
def entry_float(entry, new_text, new_text_length, position):
"""Connect insert-text signal to this function to validate
floating type"""
lst_old_string = list(entry.get_chars(0, -1))
_pos = entry.get_position()
lst_new_string = lst_old_string.insert(_pos, new_text)
_string = "".join(lst_old_string)
_hid = entry.get_data('handlerid')
entry.handler_block(_hid)
try:
_val = float(_string)
_pos = entry.insert_text(new_text, _pos)
except StandardError, e:
pass
entry.handler_unblock(_hid)
gtk.idle_add(lambda t: t.set_position(t.get_position()+1), entry)
entry.stop_emission("insert-text")
pass
Usage:-
self.etrInfo = gtk.Entry()
handlerid = self.etrInfo.connect("insert_text", entry_float)
self.etrInfo.set_data('handlerid', handlerid)
Regards,
Baiju M
___
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
