On Sun, Mar 15, 2009 at 11:37 AM, Douglas Philips <[email protected]> wrote: > On or about 2009 Mar 15, at 11:56 AM, Steve Borho indited: >> >> My TODO list for 0.8 looks something like this: > > (Lots of good things elided.) > > >> * General usability >> ** consistent geometry saving and recovery across all windows >> ** consistent keyboard accelerators for all windows and dialogs > > Among my personal favorites! As well as some way to find out what they are. > When I showed my group the Control-F search in the history/log viewer, they > thought it was great, but also asked: "How did you know about that? How do > we find out what those magic keys are?" And all I could say was: "Well, it > is < 1.0". :)
Yes, please add things like this to the manual pages on the Wiki when you remember them. I would like for those pages to be the compendium of features. >> ** Win64 support in the shell extensions > > I'm supposed to be getting a 64-bit Vista 2nd boot drive so I might be able > to help with testing on this. I have to admit, I wish I could think of a way > to automate Windows testing, as I tend to have a very stylized usage pattern > of THg and don't feel that even a one-week RC eval-time is enough (for me) > to get to all the corners of the interface in my usual work flow... It would be nice if there were regression tests, but in my experience GUI regression tests are more trouble than they're worth. >> I've been following the CuteHg project and they have some good ideas for >> usability. They also have a new C++ shell extension that I'm eager to get >> a look at. Tom has expressed an interest at merging projects at some >> point, >> using his Qt dialogs as an optional GUI backend for the TortoiseHg >> framework. > > Interesting, but I thought Qt had been deprecated for THg? It has, or it was. Qct was deprecated because the internal tool eclipsed it, and hgconfig because it ended up being redundant. I'm not going to rule out making a GUI toolkit switch in the binary installer in some future revision. > I have to say that the recent round of GTK bugs has left me a bit depressed, > but all the major toolkits have bugs and it is probably more a matter of > familiarity (a quick google of "qt vs gtk" found a lot of many-years-old > rantings but no clear winner as I would have expected). Some folks use > wxWidgets at work, but I am not very familiar with it. Most of the old arguments centered around licensing issues, but that's no longer a factor. Qt is now LGPL. I've used both PyGTK and PyQt in multiple projects and they both have pros and cons. Going with Qt would fix a lot of our interop bugs, since it doesn't require a metric ton of DLLS in your executable directory, and in general it packages cleaner on non-Linux platforms. I also think Qt looks better on non-Linux platforms, but there would be an enormous amount of work behind such a switch. BTW: For those of you who have no idea what I'm talking about, this is cutehg: http://bitbucket.org/bfrog/cutehg-stable/wiki/ScreenShots > All by way of asking what a potential project merging might be like given > the different toolkits involved... I'm not going to try to predict what a merger would be like, as Tom and I haven't discussed it much. ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Tortoisehg-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
