Hi steve, all,
I see you project as porting tortoiseHg to Qt very interesting :)
Just a few comments, (from my little experience of pyqt).
User who use source install will not be bothered by using uic file or not.
Since each time you generate a new ui file, you should regenerate the .py
And commit _both_ of them.
>From my experience, using ui file (and thus designer) for simple dialogs
lower the level for people
to participate to the project and also force people to derivate always from
(Well in my case it was for an in house tool, but still...).
Looking behind, I gained a lot of time using Qt designer, instead of doing
all by hand.
The thing I loved, was that while using it, your code still stay very very
clean, since qtdesigner only define widget not actions like classical GUI
Another point, I've readen that you are considering using qt threads.
Do you need them for speed or user interactivity?
If for speed, how about using classical python thread with queue or even
better multiprocessing module?
Because if you design well your program, multiprocessing module (that as
same API as threading module) can use multiple processors.
I'm especially wondering if it could be used when checking files of a
specific revision, and when you got lot of files.
I've sometimes seen big slowdown when there is lot of unmanaged files (>10K
(perhaps it is more an issue with hg itself...)
Perhaps, multiprocessing module is overkill, but at least using classical
thread allow using them later...
On the other side, if you use Qt network API, perhaps using qt thread is
more usefull. I've got no experience on this thing...
It depends, for what you will use the threads :)
Anyway, all continue your good work, every new release is even better!
De : Steve Borho [mailto:steve@...]
Envoyé : samedi 17 avril 2010 19:26
À : Yuya Nishihara
Cc : tortoisehg-develop@...
Objet : Re: [thg-dev] PyQt port
On Sat, Apr 17, 2010 at 1:07 AM, Yuya Nishihara <yuya@...> wrote:
> Yuki KODAMA wrote:
>> On Fri, Apr 16, 2010 at 05:48, Chad Dombrova <chadrik@...> wrote:
>> > i'm on board with this and will do what i can. just point me to the
>> > hanging fruit.
>> > -chad
>> Great. The porting of simple dialogs is good starting point, IMO.
>> But, as Steve said, these dialog porting should be done after
>> of application base which communicate with Mercurial using threading.
>> I'll post result or progress of that work to this mailing list when I
> Wow, that'll be exciting!
> I also want to contribute, starting from a small part.
> Until then, I'll be playing with Qt and hgtk, learn about Qt's model-view
> architecture, unit testing, etc.
> BTW, do we use Qt Designer based GUI?
Feel free to use the Qt Designer to get started. I would prefer not
to use them for the final dialogs, if possible, because it adds extra
steps (and tools requirements) on users who use source installs. If
someone feels they absolutely need to use machine generated dialog
files, they should add first intelligence to hgtk to detect missing or
out of date interface files and build them programatically (pyuic4 has
a Python interface).
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
Tortoisehg-develop mailing list