http://uint32t.blogspot.com/2008/07/qtlisp-looking-for-feedback.html
It's not CLIM nor cells-gtk, but a 1-1 mapping. Anyway, feel free to
flame constructively.
Sohail
On 18 Lug, 20:44, Sohail Somani <······@taggedtype.net> wrote:
> http://uint32t.blogspot.com/2008/07/qtlisp-looking-for-feedback.html
Tutorial 1, line 1:
My favorite Lisp complained:
There exists no package with name "QT"
Now I think there are 3 possibilities for the disaster:
1) I didn't find a download link
2) I forgot to download it
3) I didn't install it
It seems to me that all 3 happened...
What can I do??
-PM
········@gmail.com wrote:
> On 18 Lug, 20:44, Sohail Somani <······@taggedtype.net> wrote:
>> http://uint32t.blogspot.com/2008/07/qtlisp-looking-for-feedback.html
>
> Tutorial 1, line 1:
>
> My favorite Lisp complained:
> There exists no package with name "QT"
>
> Now I think there are 3 possibilities for the disaster:
> 1) I didn't find a download link
> 2) I forgot to download it
> 3) I didn't install it
>
> It seems to me that all 3 happened...
>
> What can I do??
Ok, I guess I should have mentioned that I was mostly looking for
feedback on the API as it stood right now by those examples.
To generate the API, you need a patched version of swig and some
homebrew code to feed swig.
I hate releasing code before it is ready but it is kind of silly of me
not to put up some code I guess, so I have updated the post with a
package that contains the generated code and instructions on how to run it.
http://taggedtype.net/~sohail/package.tgz
I have only tested with SBCL on Ubuntu and you would need the qt4-dev
packages. Be warned that it takes forever to build the core (2 mins). I
think that I will not optimize that though as I expect that actual
application development would not require loading the code every time.
I don't read c.l.l too often any more so if you have any comments,
please CC me on them.
Thanks for your message.
Sohail Somani wrote:
> http://uint32t.blogspot.com/2008/07/qtlisp-looking-for-feedback.html
>
> It's not CLIM nor cells-gtk, but a 1-1 mapping. Anyway, feel free to
> flame constructively.
I see three problems:
(a) Never show fear (by asking flamers to be constructive).
(b) Nothing says you cannot add Cells. Something says you should. Just
take Celtk or Cell-Gtk and swap in your Qt work.
(c) that should be "it is /neither/...nor...".
hth, kenny
Kenny wrote:
> Sohail Somani wrote:
>> http://uint32t.blogspot.com/2008/07/qtlisp-looking-for-feedback.html
>>
>> It's not CLIM nor cells-gtk, but a 1-1 mapping. Anyway, feel free to
>> flame constructively.
>
> I see three problems:
>
> (a) Never show fear (by asking flamers to be constructive).
Lol.
> (b) Nothing says you cannot add Cells. Something says you should. Just
> take Celtk or Cell-Gtk and swap in your Qt work.
I really think this will happen eventually. I like the way Cells works
for most things and I think I would need it for the application I am
considering. But, can we do something about documentation? ;-)
> (c) that should be "it is /neither/...nor...".
Indeed.
> hth, kenny
It does.
Hi,
nice work!
On 2008-07-18, Sohail Somani <······@taggedtype.net> wrote:
> Kenny wrote:
>> Sohail Somani wrote:
>>> http://uint32t.blogspot.com/2008/07/qtlisp-looking-for-feedback.html
>>>
>>> It's not CLIM nor cells-gtk, but a 1-1 mapping. Anyway, feel free to
>>> flame constructively.
I particullary like that it has a 1:1 cardinallity with Qt. There are two
reasons that I think this is important:
- All the *high quality documentation* of Qt can be used as it is.
- It reduces complexity, increasing the probability that the project will
survive.
In other words, you are "keeping it simple", which is very nice!
>> (b) Nothing says you cannot add Cells. Something says you should. Just
>> take Celtk or Cell-Gtk and swap in your Qt work.
>
> I really think this will happen eventually. I like the way Cells works
> for most things and I think I would need it for the application I am
> considering. But, can we do something about documentation? ;-)
There are good reasons not to use Cells too, I think. For one, it adds
complexity. Remember that Qt already has a signal/slot system that takes
care of data propagation. So, the complexity is added (and developer time is
consumed) without really buying you very much.
Even more importantly, Qt (as from Qt4) already includes everything to build
graphical user-interfaces using the standard model-view-controller (MVC)
pattern. There also exist high quality documentation (even books) about how
to use this in Qt. It would really be a pity to disregard it.
Anyway. Very nice work. Thank you for your efforts on it so far!
--
Oyvin
�yvin Halfdan Thuv wrote:
> Hi,
>
> nice work!
>
> On 2008-07-18, Sohail Somani <······@taggedtype.net> wrote:
>> Kenny wrote:
>>> Sohail Somani wrote:
>>>> http://uint32t.blogspot.com/2008/07/qtlisp-looking-for-feedback.html
>>>>
>>>> It's not CLIM nor cells-gtk, but a 1-1 mapping. Anyway, feel free to
>>>> flame constructively.
>
> I particullary like that it has a 1:1 cardinallity with Qt. There are two
> reasons that I think this is important:
>
> - All the *high quality documentation* of Qt can be used as it is.
>
> - It reduces complexity, increasing the probability that the project will
> survive.
>
> In other words, you are "keeping it simple", which is very nice!
>
>>> (b) Nothing says you cannot add Cells. Something says you should. Just
>>> take Celtk or Cell-Gtk and swap in your Qt work.
>> I really think this will happen eventually. I like the way Cells works
>> for most things and I think I would need it for the application I am
>> considering. But, can we do something about documentation? ;-)
>
> There are good reasons not to use Cells too, I think. For one, it adds
> complexity.
Impossible. Cells makes GUI programming fun and easy and leaves users
giggling and with more time for shopping. Complexity has precisely the
opposite effect.
Have you ever actually programmed with cells and cells-gtk or celtk? If
so, which and how extensively and why were you not giggling?
If not, what was the basis for the above anti-recommendation? A Yobbo
flier? Fear of learning?
Resistance is futile! All your GUI are belong to us!
:)
More seriously, you are right so you are wrong. You are right about
wrappers not obscuring the wrapped, you are wrong because that was the
prime directive in the design of Celtk, from which Cells-Gtk was cloned.
Your other mistake was in thinking all dataflow hacks are born equal.
You have no idea how much more powerful is cells than things like Qt and
Tcl/Tk (which also has some cute propagation tricks).
Did I mention resistance was futile?
:)
kt
On 2008-07-23, Kenny <·········@gmail.com> wrote:
> �yvin Halfdan Thuv wrote:
>> On 2008-07-18, Sohail Somani <······@taggedtype.net> wrote:
>>> Kenny wrote:
>>>> Sohail Somani wrote:
>>>> (b) Nothing says you cannot add Cells. Something says you should. Just
>>>> take Celtk or Cell-Gtk and swap in your Qt work.
>>> I really think this will happen eventually. I like the way Cells works
>>> for most things and I think I would need it for the application I am
>>> considering. But, can we do something about documentation? ;-)
>>
>> There are good reasons not to use Cells too, I think. For one, it adds
>> complexity.
>
> Impossible. Cells makes GUI programming fun and easy and leaves users
> giggling and with more time for shopping. Complexity has precisely the
> opposite effect.
As I said, Qt already has dataflow capabilities, and they are well-documented
too. Therefore, adding a separate library to handle dataflow increases
complexity.
> Have you ever actually programmed with cells and cells-gtk or celtk? If
> so, which and how extensively and why were you not giggling?
Yes, I have tried it (cells-gtk). I think that Cells is useful, but not for
Qt, since a mature, well-documented, industry standard (MVC) architecture is
already in place for consistency handling in Qt.
--
Oyvin
�yvin Halfdan Thuv wrote:
> On 2008-07-23, Kenny <·········@gmail.com> wrote:
>> �yvin Halfdan Thuv wrote:
>>> On 2008-07-18, Sohail Somani <······@taggedtype.net> wrote:
>>>> Kenny wrote:
>>>>> Sohail Somani wrote:
>>>>> (b) Nothing says you cannot add Cells. Something says you should. Just
>>>>> take Celtk or Cell-Gtk and swap in your Qt work.
>>>> I really think this will happen eventually. I like the way Cells works
>>>> for most things and I think I would need it for the application I am
>>>> considering. But, can we do something about documentation? ;-)
>>> There are good reasons not to use Cells too, I think. For one, it adds
>>> complexity.
>> Impossible. Cells makes GUI programming fun and easy and leaves users
>> giggling and with more time for shopping. Complexity has precisely the
>> opposite effect.
>
> As I said, Qt already has dataflow capabilities, and they are well-documented
> too.
And as I said, calling two things the same when they are different does
not make them the same. I just looked at the signals-slots documentation
and there is no comparison with Cells. signals/slots are fine as far as
they go (pretty much the observer pattern from the GoF book, or (IIRC)
subscribe/notify from Smalltalk), but they do not go very far. Deets below.
> Therefore, adding a separate library to handle dataflow increases
> complexity.
Cool, we have instantly entered a loop in which we will simply persist
in repeatedly talking past each other! I love science.
>
>> Have you ever actually programmed with cells and cells-gtk or celtk? If
>> so, which and how extensively and why were you not giggling?
>
> Yes, I have tried it (cells-gtk). I think that Cells is useful, but not for
> Qt, since a mature, well-documented, industry standard (MVC) architecture is
> already in place for consistency handling in Qt.
>
It depends on how much work Sohail wants to do. The perfect execution
would begin with the pure wrapper you are describing (for those who Just
Want To Qt) and then do a more powerful wrapper (with or without Cells)
that would improve on Qt and make it even cooler. Without breaking the
first layer.
Or Sohail could just have fun and go straight to Qt/Cells, without
losing any of the functionality of Qt or making its documentation useless.
Except signals and slots. Those might have to go. I see those coded as
extra class thingys in the Qt "language", and "slots" are just function
calls, so it is not clear to me how to originate those on the Lisp side.
(I did not look to see if there was an API to gen those on the fly.)
Functionally, multiple dependents are called in arbitrary order,
violating data integrity as defined in cells 3 -- if the dependency
graph has two paths from A to B, B gets called twice, once without
seeing an intermediate signal current with the change to A.
Meanwhile, so-called slots being just member functions, one does not get
The Grail of declarative programming from signals and slots. Ewww. If I
want to make the structure of a complex widget sensitive to other data
in the model, i end up wiring it all by hand getting only the
notification of change itself out of Qt. Kinda like having only Cells
observers and no (real CLOS) slots with declarative rules.
So it is a bit of a non-sequitor to respond to my "Use Cells!" with "No!
Qt has signals/slots" -- the latter is just a small bit of the wiring
one finds in Cells and the fun comes when you get the whole thing
working thru cells.
Now I happen to know Sohail is motivated mostly by fun, so...resistance
is futile!
:)
kt
On 2008-07-23, Kenny <·········@gmail.com> wrote:
> It depends on how much work Sohail wants to do. The perfect execution
> would begin with the pure wrapper you are describing (for those who Just
> Want To Qt) and then do a more powerful wrapper (with or without Cells)
> that would improve on Qt and make it even cooler. Without breaking the
> first layer.
Yes, indeed (with emphasis on you last sentence).
--
Oyvin
On 2008-07-23 11:39:19 -0400, ········@gmail.com said:
> (2) Cells is much, much better and simpler, but it still is not as
> simple to set up as my home-grown solution
To come to Kenny's defense here, the reason Cells is as complicated as
it is is that getting data integrity correct in a dataflow framework is
hard - there are many ways to lose and simple systems don't guard
against these.
········@gmail.com wrote:
> On 23 Lug, 16:51, �yvin Halfdan Thuv <·······@pvv.ntnu.no> wrote:
>> ...
>
> No, sorry, but simply no.
>
> Neither Cells nor MVC has been able to convince me.
>
> Do I really have to mention it?
>
> We are at *Lisp* here, and, exactly, the *Common* one:
>
> (1) MVC is simply horribly complicated in setting up and getting to
> work.
> (2) Cells is much, much better and simpler, but it still is not as
> simple to set up as my home-grown solution
>
> No, sorry, but *no*, you both didn't really convince me...
>
> Think harder... (but this will not help you, so: *think* *simpler*,
> both of you!!)
You sir are The One True Master of open source! I thought I had done
good by not documenting my stuff, but you have managed to eliminate
providing the code as well! Or even saying what your library does!! You
just tell potential users to think!!! I bow before you.
What to major upgrades look like? Think again?
:)
kt