On 19-04-2010 14:58, Yuya Nishihara wrote:
> Though I'm not familiar with the windows installer package,
> it packs modules into single zip file. Maybe it only supports *.py files.
It also supports pyd files, through some manual work in py2exe bootstrap
code, but it doesn't support arbitrary file
Chad Dombrova wrote:
> >> Or introduce a trick to load ui file dynamically:
> >>
> >>try:
> >>from ui_foo import Ui_Foo
> >>except ImportError:
> >>from PyQt4 import uic
> >>Ui_Foo = uic.loadUiType(os.path.join(os.path.dirname(__file__)),
> >> 'foo.ui'))[0]
...
> >
On 18-04-2010 21:25, Chad Dombrova wrote:
> On Apr 18, 2010, at 11:53 AM, Steve Borho wrote:
>> We'll presumably compile the UIs for the installers, so
>> end users will never see this overhead.
>
> before giving yourself extra work to do, it might be worthwhile to determine
> if there is any noti
On 18-04-2010 02:31, Steve Borho wrote:
> On Sat, Apr 17, 2010 at 2:12 PM, Sune Foldager wrote:
>> Well, it will confuse the history, and the two projects are, as you
>> almost say yourself below, not very connected. I don't see why you would
>> want them in the same repo or branch.
>
> This is st
On Apr 18, 2010, at 11:53 AM, Steve Borho wrote:
> On Sat, Apr 17, 2010 at 9:54 PM, Yuya Nishihara wrote:
>> Hi,
>>
>> Laurent Dufrechou wrote:
>>> 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 th
On Sat, Apr 17, 2010 at 9:54 PM, Yuya Nishihara wrote:
> Hi,
>
> Laurent Dufrechou wrote:
>> 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
>> file.
>> And commit _both_ of them.
>
> Or introdu
Steve Borho wrote:
> > Hmm, I think we need another name; hgqt is not easy to type or remember
> > for lusers. ...might even go as keeping hgtk, or maybe thg.
>
> I was speaking of folders, not executables. My intent is to keep hgtk
> as the command line tool until the Qt port is finished. At th
Hi,
Laurent Dufrechou wrote:
> 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
> file.
> And commit _both_ of them.
Or introduce a trick to load ui file dynamically:
try:
from ui_fo
On Sat, Apr 17, 2010 at 2:12 PM, Sune Foldager wrote:
> On 17-04-2010 19:33, Steve Borho wrote:
>> On Sat, Apr 17, 2010 at 11:33 AM, Sune Foldager wrote:
>>> Could we please create separate branches (qtdev/qtstable) or a separate
>>> repo for this? It would be nice to keep the existing code clea
On Sat, Apr 17, 2010 at 12:26 PM, Steve Borho wrote:
> On Sat, Apr 17, 2010 at 1:07 AM, Yuya Nishihara wrote:
>> Hi,
>>
>> Yuki KODAMA wrote:
>>> On Fri, Apr 16, 2010 at 05:48, Chad Dombrova wrote:
>>> > i'm on board with this and will do what i can. just point me to the low
>>> > hanging fruit
g-develop@lists.sourceforge.net
Objet : Re: [thg-dev] PyQt port
On Sat, Apr 17, 2010 at 1:07 AM, Yuya Nishihara wrote:
> Hi,
>
> Yuki KODAMA wrote:
>> On Fri, Apr 16, 2010 at 05:48, Chad Dombrova wrote:
>> > i'm on board with this and will do what i can. just point me
On 17-04-2010 19:33, Steve Borho wrote:
> On Sat, Apr 17, 2010 at 11:33 AM, Sune Foldager wrote:
>> Could we please create separate branches (qtdev/qtstable) or a separate
>> repo for this? It would be nice to keep the existing code clean of QT
>> experiments.
>
> I don't see the need for this;
On Sat, Apr 17, 2010 at 11:33 AM, Sune Foldager wrote:
> Could we please create separate branches (qtdev/qtstable) or a separate
> repo for this? It would be nice to keep the existing code clean of QT
> experiments.
I don't see the need for this; the Qt port will be in a separate
folder under th
On Sat, Apr 17, 2010 at 1:07 AM, Yuya Nishihara wrote:
> Hi,
>
> Yuki KODAMA wrote:
>> On Fri, Apr 16, 2010 at 05:48, Chad Dombrova wrote:
>> > i'm on board with this and will do what i can. just point me to the low
>> > hanging fruit.
>> > -chad
>>
>> Great. The porting of simple dialogs is go
Could we please create separate branches (qtdev/qtstable) or a separate
repo for this? It would be nice to keep the existing code clean of QT
experiments.
/Sune
--
Download Intel® Parallel Studio Eval
Try the new softwar
On 15.04.2010 22:48, Chad Dombrova wrote:
> i'm on board with this and will do what i can. just point me to the low
> hanging fruit.
Good to know, thanks.
What is your primary/preferred/"workhorse" platform?
(Is it Windows? Linux? Mac OS X? Please be as specific as possible, e.g.
"Windows Vista
On 17.04.2010 10:55, Adrian Buehlmann wrote:
> On 17.04.2010 04:00, Yuki KODAMA wrote:
>> On Sat, Apr 17, 2010 at 07:10, Adrian Buehlmann wrote:
>>> On 16.04.2010 23:58, Adrian Buehlmann wrote:
On 16.04.2010 23:32, Adrian Buehlmann wrote:
> Slightly off topic, but Herb Sutter (C++ standar
On 17.04.2010 04:00, Yuki KODAMA wrote:
> On Sat, Apr 17, 2010 at 07:10, Adrian Buehlmann wrote:
>> On 16.04.2010 23:58, Adrian Buehlmann wrote:
>>> On 16.04.2010 23:32, Adrian Buehlmann wrote:
Slightly off topic, but Herb Sutter (C++ standard and concurrent
programming guru) has a very
Could these be of any help with the futures topic ?
http://code.activestate.com/recipes/84317-easy-threading-with-futures/
http://pypi.python.org/pypi/futures/1.0
http://twistedmatrix.com
Johan
--
Download Intel® Parallel
Hi,
Yuki KODAMA wrote:
> On Fri, Apr 16, 2010 at 05:48, Chad Dombrova wrote:
> > i'm on board with this and will do what i can. just point me to the low
> > hanging fruit.
> > -chad
>
> Great. The porting of simple dialogs is good starting point, IMO.
> But, as Steve said, these dialog porting
On 17-04-2010 04:00, Yuki KODAMA wrote:
> Thanks for digging concurrent features in PyQt, Adrian.
> Meanwhile I'll do it with QThread class or others :-)
>
> "Future" mechanism is good, no doubt. But if we decide to use it,
> it's difficult to refer our current GTK+ based implementation of
> the
On Sat, Apr 17, 2010 at 07:10, Adrian Buehlmann wrote:
> On 16.04.2010 23:58, Adrian Buehlmann wrote:
>> On 16.04.2010 23:32, Adrian Buehlmann wrote:
>>> Slightly off topic, but Herb Sutter (C++ standard and concurrent
>>> programming guru) has a very nice blog entry about concurrent programming:
On 16.04.2010 23:58, Adrian Buehlmann wrote:
> On 16.04.2010 23:32, Adrian Buehlmann wrote:
>> Slightly off topic, but Herb Sutter (C++ standard and concurrent
>> programming guru) has a very nice blog entry about concurrent programming:
>>
>> Effective Concurrency: Prefer Futures to Baked-In “Asyn
On 16.04.2010 23:32, Adrian Buehlmann wrote:
> Slightly off topic, but Herb Sutter (C++ standard and concurrent
> programming guru) has a very nice blog entry about concurrent programming:
>
> Effective Concurrency: Prefer Futures to Baked-In “Async APIs”
>
> http://herbsutter.com/2010/01/17/effe
On 16.04.2010 23:01, Adrian Buehlmann wrote:
> On 16.04.2010 19:39, Yuki KODAMA wrote:
>> I'll take a look threading of PyQt tomorrow.
>
> Great.
>
>> TortoiseBZR & CuteHg will be helpful resources to learn it.
>
> I tried to build CuteHg from source, but failed so far.
>
> The book [1] "Rapid
On 16.04.2010 19:39, Yuki KODAMA wrote:
> On Fri, Apr 16, 2010 at 04:36, Steve Borho wrote:
>> On Thu, Apr 15, 2010 at 2:26 PM, Yuki KODAMA wrote:
>>> On Thu, Apr 15, 2010 at 23:12, Steve Borho wrote:
There's been some discussions on the Mercurial users list about
starting a PyQt port
On Sat, Apr 17, 2010 at 02:55, Steve Borho wrote:
> On Fri, Apr 16, 2010 at 12:53 PM, Yuki KODAMA wrote:
>> On Fri, Apr 16, 2010 at 05:48, Chad Dombrova wrote:
>>> i'm on board with this and will do what i can. just point me to the low
>>> hanging fruit.
>>> -chad
>>
>> Great. The porting of s
On Fri, Apr 16, 2010 at 12:53 PM, Yuki KODAMA wrote:
> On Fri, Apr 16, 2010 at 05:48, Chad Dombrova wrote:
>> i'm on board with this and will do what i can. just point me to the low
>> hanging fruit.
>> -chad
>
> Great. The porting of simple dialogs is good starting point, IMO.
> But, as Steve
On Fri, Apr 16, 2010 at 05:48, Chad Dombrova wrote:
> i'm on board with this and will do what i can. just point me to the low
> 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 constructing
of
On Fri, Apr 16, 2010 at 04:36, Steve Borho wrote:
> On Thu, Apr 15, 2010 at 2:26 PM, Yuki KODAMA wrote:
>> On Thu, Apr 15, 2010 at 23:12, Steve Borho wrote:
>>> There's been some discussions on the Mercurial users list about
>>> starting a PyQt port of TortoiseHg. If we decide to go this route,
i'm on board with this and will do what i can. just point me to the low
hanging fruit.
-chad
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fin
On Thu, Apr 15, 2010 at 2:26 PM, Yuki KODAMA wrote:
> On Thu, Apr 15, 2010 at 23:12, Steve Borho wrote:
>> There's been some discussions on the Mercurial users list about
>> starting a PyQt port of TortoiseHg. If we decide to go this route, I
>> have a few suggestions.
>>
>> 1) We mark the curre
On Thu, Apr 15, 2010 at 23:12, Steve Borho wrote:
> There's been some discussions on the Mercurial users list about
> starting a PyQt port of TortoiseHg. If we decide to go this route, I
> have a few suggestions.
>
> 1) We mark the current GTK dialogs as "done" in thg-1.1 and switch
> tortoisehg/
There's been some discussions on the Mercurial users list about
starting a PyQt port of TortoiseHg. If we decide to go this route, I
have a few suggestions.
1) We mark the current GTK dialogs as "done" in thg-1.1 and switch
tortoisehg/hgtk to pure maintenance mode.
2) The hgtk app should be given
34 matches
Mail list logo
