On Wednesday 05 November 2008, Jérémie Dimino wrote:
> Jon Harrop <[EMAIL PROTECTED]> writes:
> > I'd forget about that and just focus on making the whole of Qt4 available
> > safely from OCaml in any form first. Even this is an unsolved problem in
> > the OCaml world!
>
> I suggest an idea. I know
> > And neither QPainterPath nor QPicture are really hierarchical. About the
> > only way to think of a hierarchy for Qt's drawing system is at the level
> > of QPainter, which provides save() / restore() functionality for its
> > state. All of this structure is implemented by the QPainter(), so as
On Wednesday 05 November 2008 16:33:43 Jérémie Dimino wrote:
> Jon Harrop <[EMAIL PROTECTED]> writes:
> > I'd forget about that and just focus on making the whole of Qt4 available
> > safely from OCaml in any form first. Even this is an unsolved problem in
> > the OCaml world!
>
> I suggest an idea
On Wednesday 05 November 2008 17:08:21 Jon Harrop wrote:
> Smoke already runs fine using Mesa and Mesa is still seeing huge
> performance improvements, e.g. using run-time generated code via LLVM. If
> you desperately needed Smoke on an embedded platform, I would just port it
> to OpenGL ES instead
Jon Harrop <[EMAIL PROTECTED]> writes:
> I'd forget about that and just focus on making the whole of Qt4 available
> safely from OCaml in any form first. Even this is an unsolved problem in the
> OCaml world!
I suggest an idea. I know that Qt4 offer some facility to export
objects trough DBus
On Wednesday 05 November 2008 15:55:24 Kuba Ober wrote:
> Would it be useful, then, to have Smoke have a built-in renderer for
> embedded/non-accelerated platforms? It should still be faster than Mesa,
> since you can work with higher-level objects that can perhaps be drawn
> faster with object-spe
On Wednesday 05 November 2008 15:44:24 Kuba Ober wrote:
> And neither QPainterPath nor QPicture are really hierarchical. About the
> only way to think of a hierarchy for Qt's drawing system is at the level of
> QPainter, which provides save() / restore() functionality for its state.
> All of this s
On Wednesday 05 November 2008, Jon Harrop wrote:
> On Wednesday 05 November 2008 15:20:26 Kuba Ober wrote:
[snip]
> > So, please understand that I'm not oblivious to benefits of thinking in
> > higher levels of abstraction, but I'm also practical and know that Qt
> > provides me with a whole big lo
On Wednesday 05 November 2008 15:05:13 Kuba Ober wrote:
> > However, Trolltechs own demos segfault on my machine regularly
> > and KDE is unreliable despite being written almost entirely in Qt's
> > native language. So I would not be so hasty to blame PyQt for Qt's
> > reliability problems.
>
> As
On Wednesday 05 November 2008 08:39:32 Paolo Donadeo wrote:
> > In contrast, you can implement a GUI toolkit in OCaml that far exceeds
> > the relevant limitations of Qt4 with quite easily.
>
> Jon, did you ever used Qt in a big C++ or Python project? Qt is the
> best GUI framework out there, GTK i
On Wednesday 05 November 2008, Paolo Donadeo wrote:
> > In contrast, you can implement a GUI toolkit in OCaml that far exceeds
> > the relevant limitations of Qt4 with quite easily.
>
> Jon, did you ever used Qt in a big C++ or Python project? Qt is the
> best GUI framework out there, GTK is a ridi
On Wednesday 05 November 2008 15:20:26 Kuba Ober wrote:
> > > Have you ran recent Qt demos distributed with Qt? I'd say they look
> > > pretty cool in my book.
> >
> > They would not have impressed me a decade ago, let alone today. Many of
> > them don't even work on either of my Debian machines.
>
> > Have you ran recent Qt demos distributed with Qt? I'd say they look
> > pretty cool in my book.
>
> They would not have impressed me a decade ago, let alone today. Many of
> them don't even work on either of my Debian machines.
I have one question regarding OpenGL: maybe it's just me, but isn'
> However, Trolltechs own demos segfault on my machine regularly
> and KDE is unreliable despite being written almost entirely in Qt's native
> language. So I would not be so hasty to blame PyQt for Qt's reliability
> problems.
As a longtime KDE user, I'm very much disappointed by the most recent
On Wednesday 05 November 2008, Jon Harrop wrote:
> On Tuesday 04 November 2008 23:06:00 Kuba Ober wrote:
> > On Tuesday 04 November 2008, Jon Harrop wrote:
> > > You'll just be invoking autogenerated Python code using OCaml so
> > > OCaml's class system is only relevant if you want to do some fancy
On Wednesday 05 November 2008 08:53:28 Paolo Donadeo wrote:
> > No, you just invoke the existing Python bindings. OCaml doesn't have to
> > implement anything except bindings to Python, which are already done.
>
> From this sentence I deduce you don't know *how* the PyQt binding is
> generated. It'
> No, you just invoke the existing Python bindings. OCaml doesn't have to
> implement anything except bindings to Python, which are already done.
>From this sentence I deduce you don't know *how* the PyQt binding is
generated. It's not a trivial task and the binding layer adds it's own
bugs and gl
> In contrast, you can implement a GUI toolkit in OCaml that far exceeds the
> relevant limitations of Qt4 with quite easily.
Jon, did you ever used Qt in a big C++ or Python project? Qt is the
best GUI framework out there, GTK is a ridiculous toy in comparison,
and it took ages to reach this leve
18 matches
Mail list logo
