On Sun, Jul 13, 2008 at 7:10 PM, Igor Novikov <[EMAIL PROTECTED]> wrote: > > > On Mon, Jul 14, 2008 at 12:16 AM, Guilherme Polo <[EMAIL PROTECTED]> wrote: >> >> On Sun, Jul 13, 2008 at 6:04 PM, Igor Novikov <[EMAIL PROTECTED]> >> wrote: >> > >> > >> > On Sun, Jul 13, 2008 at 11:06 PM, Guilherme Polo <[EMAIL PROTECTED]> >> > wrote: >> >> >> >> On Sun, Jul 13, 2008 at 4:39 PM, Igor Novikov >> >> <[EMAIL PROTECTED]> >> >> wrote: >> >> > Hi, >> >> > >> >> > Recently I have found your message regarding ttk package which is a >> >> > part >> >> > of >> >> > your GSoC 2008 project: >> >> > >> >> > >> >> > http://mail.python.org/pipermail/tkinter-discuss/2008-June/001439.html >> >> > >> >> > It is curiously enough, but our sK1 project has used similar package >> >> > since >> >> > 2006 year (it was Tile wrapper initially). I think our code base >> >> > could >> >> > be >> >> > useful for your GSoC project, because it contains a lot of fixes and >> >> > workarounds. >> >> >> >> I'm taking a look at it, Igor, I guess you are referring to Ttk.py at >> >> sK1/src/app/UI, correct ? >> > >> > on this moment the package is refactored to sK1/src/app/UI/lib-ttk to be >> > generic for all packages like Tkinter. >> > >> >> >> >> Initially I see it is missing Notebook, Treeview and all the theming >> >> management, I guess you just wrapped the bits useful for your project. >> > >> > Yes, you are right. Our goal is providing custom Ttk package for our >> > project >> > but not for conventional usage. So our code could be useful as tips, no >> > more. >> > >> >> >> >> I'm curios why you prefixed most classes with a "T", except the >> >> Labelframe one. Other thing I noticed is that the class TButton has >> >> way more methods than those supported by a ttk Button. >> > >> > We don't use ttk::labelframe due to some ttk implementation bugs (may >> > be >> > they have been fixed). In Ttk.py you have found regular tk::labelframe. >> >> Now I see it, but then why did you redo what is already done at Tkinter.py >> ? > > >> >> > "T" prefix is used to avoid clashes with Tkinter classes. If you migrate >> > from Tkinter to Ttk and your project is bigger than regular 'hello >> > world' >> > such clashes could be a serious issue. >> >> >> Only if you are doing from Tkinter import *, which is not really >> recommended. > > Not only in such cases. If tk widgets are instantiated with tk specific > options or some tk specific changes are applied to widgets, such code should > be refactored step-by-step.
Yes, and how that does not relate to doing a star import ? If you don't do such imports, you won't have names being overrided. > Similar issue was for tcl scripts when Tile was > released. Attemps to substitute all widgets by changing namespaces have been > unsuccessful so all new widgets have ttk:: prefix and migration on ttk is > recommended to be accurate. I've changed IDLE to use ttk widgets when they are available, I'm aware of the differences between standard Tk widgets and Ttk widgets. This "ttk::" prefix just reinforces what I said about not using star imports, not sure why you are bringing it up. Ideally I would like to see "import Tkinter as tk" or something like that being used, instead of "from Tkinter import *", just like people do in every other toolkit. > >> >> Also, did you happen to give a try to my wrapper and found some >> >> different behavior than yours ? >> > >> > Sorry, I cannot using your package because it isn't compatible with sK1 >> > code >> > base. >> >> > >> >> In what sense ? > > There is no sence to refactor 0.5Mb of source code replacing existing > implementation by your classes. I never told you to use it in your project. I just asked if you tried it or not, because it seemed like you found a bug on it and your wrapper had some correction regarding the supposed problem. > More over in such case we should adding to > our SVN your ttk.py and regulary updating it. But such work doesn't improve > sK1 functionality because as our code and your implementetion are similar > wrappers surround the same tcl commands :) In that case you won't have to refactor 500kb of source code then. > Such migration will be reasonable > when Ttk will be officially included into Python distribution and API will > be freezed. > I haven't been changing its API at all for some weeks now, not in incompatible ways at least. And again, I didn't tell to you to just move your project to my wrapper and drop yours. > Regards, > > Igor Novikov > sK1 Project > http://sk1project.org > > -- -- Guilherme H. Polo Goncalves _______________________________________________ Tkinter-discuss mailing list Tkinter-discuss@python.org http://mail.python.org/mailman/listinfo/tkinter-discuss
