From alexeys9 at yandex.ru Sat Nov 6 14:48:34 2010 From: alexeys9 at yandex.ru (Makarov Alexey) Date: Sat, 06 Nov 2010 19:48:34 +0500 Subject: [mcclim-devel] Two problems with McCLIM with gtkairo Message-ID: <1289054914.5673.50.camel@reginleif.ufanet.ru> Hello! I have two problems with gtkairo backend. First problem is black application frame while presented information on frame parts is not changed, mouse pointer is not hover on scrollbar or interactor menu doesn't appear on that pane. This appear in Ubuntu Linux 10.04 with SBCL 1.0.40 and GTK 2.20. Second problem is McCLIM with gtkairo backend hangs on Windows XP on SBCL 1.0.43 (https://sites.google.com/site/dmitryvksite/sbcl-distr/sbcl-1.0.43-threads-g002bdc7.msi) and GTK 2.22. I try to eval: (run-frame-top-level (make-application-frame 'superapp)) Then application frame is appear but panes not draw on it and frame hang (can't close window). SBCL hang too, but this issue I can avoid: (sb-thread:make-thread (lambda () (run-frame-top-level (make-application-frame 'superapp)))) I run this code: (defpackage "APP" (:use :clim :clim-lisp) (:export "APP-MAIN")) (in-package :app) (define-application-frame superapp () () (:pointer-documentation t) (:panes (app :application :display-time nil :height 400 :width 600) (int :interactor :height 200 :width 600)) (:layouts (default (vertically () app int)))) (defun app-main () (run-frame-top-level (make-application-frame 'superapp))) (define-superapp-command (com-quit :name t) () (frame-exit *application-frame*)) (define-superapp-command (com-parity :name t) ((number 'integer)) (format t "~a is ~a~%" number (if (oddp number) "odd" "even"))) I use quicklisp and mcclim from quicklisp repository. Have your any ideas to solve that problems? -- Makarov Alexey From james.ashley at gmail.com Sat Nov 20 01:10:59 2010 From: james.ashley at gmail.com (James Ashley) Date: Sat, 20 Nov 2010 01:10:59 +0000 Subject: [mcclim-devel] Feasibility Question Message-ID: Hi, all. I've been programming for close to 30 years now, and I've been trying to find a good excuse to really learn common lisp (as opposed to just dabbling) for the past 3 or so. I think I've finally come across a project that feels like the right "fit." The basic idea is a collaborative 3-d client-side application server with a built-in IDE that persists the state off all its applications between all its program runs. This is total vaporware at the moment...I'm just trying to do some basic research and pick the right tools. I've been involved in way too many where we started out in one environment, got a proof of concept, then realized there were some fundamental limitations that kept us from moving forward, so we essentially had to start over from scratch (or wound up layering ever-more-unmaintainable pieces on top of an unsustainable architecture). Right now, I'm thinking off "applications" being developed on at least 4 different levels. One would be raw common lisp, that interacts directly with the "interpreter." Another would really be creating custom frame managers (I think...I'm just scratching CLIM's surface) to provide eye candy effects (since I'm planning on targeting the masses, I've learned that it's pretty much all about the eye candy). Yet another would be something like the HTML/CSS/Javascript paradigm to create 2-d "applications." And the last would be the actual 3-d world where the users interact. A combination of Open Cobalt and World Forge seemed like the "proper" mix at first. But, the more I dug into smalltalk, the less impressed I was. I kept thinking "If only I could write a macro to do all this..." The more I dug into it, the more I realized just how big and ambitious this project is. If I'm going to be dedicating 10 years (or more) to something, and forcing my users to download some obscure runtime anyway...why not go with a language that left my jaw on the floor and my head spinning? I realize common lisp isn't perfect, but what is? (Clojure's tempting. I downloaded it, spent about 20 minutes to get a REPL, and finally gave up. It may be mature and "ready for the big leagues" before this project is, but...common lisp's there now. Racket's similarly tempting, but I just don't seem to fit with the Scheme community). The ideas behind McClim seem to feel like it's the right "fit" for the GUI part of the project. Not all the eye-candy pieces, of course. Just...conceptually. I've been digging my way through the old mailing list archives (the check-in comments are a lot more educational than I realized at first. I'm glad they got archived that way), and I see that there's been speculation about an OpenGL backend for ages now (and at least an experimental stab at writing one). Conventional wisdom seems to dictate using something like one of the GTK bindings for the UI. But it seems to me that, if I started there, I'd just wind up re-implementing tons of CLIM to get to an abstraction level where I could forget about that and get down to real work. It seems to me that my time would be better spent helping get the GTKairo working solidly. Either way, I'll wind up duplicating the work to switch to some crazy gadget set built entirely on some 3-d engine or other. I see one of the fundamental programs being a traditional "form builder" kind of drag-and-drop thing along the lines of VB. Probably with some kind of tree view (or maybe boxes) to hide the fact that the code's actually being written in lisp. Am I barking up the wrong tree? Like I said...I've been going through the old mailing list archives. I've normally have wrapped that up and at least gotten more than a passing acquaintance with actually writing McCLIM code (at this point, I'm just digesting that ancient CLIM "walk-through" referenced first on the home page) before de-lurking. But I ran across someone else today who seems to be thinking on at least vaguely parallel lines to mine, and I figured this was the best place to check before I wasted his time with my ideas. Thanks, James From CraigL at sc.rr.com Sat Nov 20 04:21:00 2010 From: CraigL at sc.rr.com (Craig Lanning) Date: Fri, 19 Nov 2010 23:21:00 -0500 Subject: [mcclim-devel] Feasibility Question In-Reply-To: References: Message-ID: <1290226860.2270.115.camel@lanning.lanning.lan> On Sat, 2010-11-20 at 01:10 +0000, James Ashley wrote: > Hi, all. > > I've been programming for close to 30 years now, and I've been trying > to find a good excuse to really learn common lisp (as opposed to just > dabbling) for the past 3 or so. I've been programming in Lisp (first Zetalisp on a lisp machine, then Common Lisp on Unix, Windows, and Linux) professionally for 25 years and I find it to be the best language for just about anything. > I think I've finally come across a project that feels like the right > "fit." The basic idea is a collaborative 3-d client-side application > server with a built-in IDE that persists the state off all its > applications between all its program runs. You need to be aware that CLIM doesn't have any 3D concepts in it so you will need to add those abstractions. The good thing is that CLIM is layered so if there are no high level facilities that do what you need, you can build them up from the lower level facilities. > This is total vaporware at the moment...I'm just trying to do some > basic research and pick the right tools. I've been involved in way too > many where we started out in one environment, got a proof of concept, > then realized there were some fundamental limitations that kept us > from moving forward, so we essentially had to start over from scratch > (or wound up layering ever-more-unmaintainable pieces on top of an > unsustainable architecture). > > Right now, I'm thinking off "applications" being developed on at least > 4 different levels. One would be raw common lisp, that interacts > directly with the "interpreter." Another would really be creating > custom frame managers (I think...I'm just scratching CLIM's surface) > to provide eye candy effects (since I'm planning on targeting the > masses, I've learned that it's pretty much all about the eye candy). > Yet another would be something like the HTML/CSS/Javascript paradigm > to create 2-d "applications." And the last would be the actual 3-d > world where the users interact. > > A combination of Open Cobalt and World Forge seemed like the "proper" > mix at first. But, the more I dug into smalltalk, the less impressed I > was. I kept thinking "If only I could write a macro to do all this..." > > The more I dug into it, the more I realized just how big and ambitious > this project is. One thing I've found is that I can build applications much faster in Common Lisp and they are much more robust. You may find that as you become more proficient in CL that your project doesn't take as long as you thought. > If I'm going to be dedicating 10 years (or more) to > something, and forcing my users to download some obscure runtime > anyway...why not go with a language that left my jaw on the floor and > my head spinning? I realize common lisp isn't perfect, but what is? > (Clojure's tempting. I downloaded it, spent about 20 minutes to get a > REPL, and finally gave up. It may be mature and "ready for the big > leagues" before this project is, but...common lisp's there now. > Racket's similarly tempting, but I just don't seem to fit with the > Scheme community). I currently use SBCL as my free CL of choice and LispWorks as my commercial CL of choice. > The ideas behind McClim seem to feel like it's the right "fit" for the > GUI part of the project. Not all the eye-candy pieces, of course. > Just...conceptually. I've been digging my way through the old mailing > list archives (the check-in comments are a lot more educational than I > realized at first. I'm glad they got archived that way), and I see > that there's been speculation about an OpenGL backend for ages now > (and at least an experimental stab at writing one). > > Conventional wisdom seems to dictate using something like one of the > GTK bindings for the UI. But it seems to me that, if I started there, > I'd just wind up re-implementing tons of CLIM to get to an abstraction > level where I could forget about that and get down to real work. It > seems to me that my time would be better spent helping get the GTKairo > working solidly. It's interesting that you should mention "re-implementing tons of CLIM". I have watched (mostly) and participated (a little) in the development of XEmacs for many years. As they discussed the various target user intefaces (Win32, GTK, etc.), I noticed that they were implementing parts of CLIM in C. Actually, one of the nice things about using CL and CLIM is that you get to define your UI separately from the implementation, thus, allowing you to more easily port your application to more systems. CLIM can have multiple backends: GTK, OpenGL, Win32, XLib, etc. > Either way, I'll wind up duplicating the work to switch to some crazy > gadget set built entirely on some 3-d engine or other. > I see one of the fundamental programs being a traditional "form > builder" kind of drag-and-drop thing along the lines of VB. Probably > with some kind of tree view (or maybe boxes) to hide the fact that the > code's actually being written in lisp. > > Am I barking up the wrong tree? Like I said...I've been going through > the old mailing list archives. I've normally have wrapped that up and > at least gotten more than a passing acquaintance with actually writing > McCLIM code (at this point, I'm just digesting that ancient CLIM > "walk-through" referenced first on the home page) before de-lurking. > But I ran across someone else today who seems to be thinking on at > least vaguely parallel lines to mine, and I figured this was the best > place to check before I wasted his time with my ideas. I say go for it. I haven't found a project yet that I wouldn't rather do in Lisp. Craig From k2msmith at gmail.com Sat Nov 20 20:41:43 2010 From: k2msmith at gmail.com (k2msmith at gmail.com) Date: Sat, 20 Nov 2010 20:41:43 +0000 Subject: [mcclim-devel] Feasibility Question In-Reply-To: <1290226860.2270.115.camel@lanning.lanning.lan> Message-ID: <000e0cd20d92fdfba90495820c73@google.com> Thanks for the interesting thread. I was considering using clim for an experimental openGL application I'm writing, but I didn't get too far with it (on Darwin platform). So, I'm using OpenGL and GLU only for now. See link below for more details. Since I'm at a point where I need some high-level UI gadgets like pop-menus and things, it would be nice to fit what I have into a lisp framework, since the toplevel of what I have is written in lisp (image proceessing stuff is in C++). http://kevinmichaelsmith.posterous.com/ I'm interesting in learning more about the benefits of clim and if that could work with an openGL canvas using mac backend for UI look and feel. On Nov 19, 2010 8:21pm, Craig Lanning wrote: > On Sat, 2010-11-20 at 01:10 +0000, James Ashley wrote: > > Hi, all. > > > > I've been programming for close to 30 years now, and I've been trying > > to find a good excuse to really learn common lisp (as opposed to just > > dabbling) for the past 3 or so. > I've been programming in Lisp (first Zetalisp on a lisp machine, then > Common Lisp on Unix, Windows, and Linux) professionally for 25 years and > I find it to be the best language for just about anything. > > I think I've finally come across a project that feels like the right > > "fit." The basic idea is a collaborative 3-d client-side application > > server with a built-in IDE that persists the state off all its > > applications between all its program runs. > You need to be aware that CLIM doesn't have any 3D concepts in it so you > will need to add those abstractions. The good thing is that CLIM is > layered so if there are no high level facilities that do what you need, > you can build them up from the lower level facilities. > > This is total vaporware at the moment...I'm just trying to do some > > basic research and pick the right tools. I've been involved in way too > > many where we started out in one environment, got a proof of concept, > > then realized there were some fundamental limitations that kept us > > from moving forward, so we essentially had to start over from scratch > > (or wound up layering ever-more-unmaintainable pieces on top of an > > unsustainable architecture). > > > > Right now, I'm thinking off "applications" being developed on at least > > 4 different levels. One would be raw common lisp, that interacts > > directly with the "interpreter." Another would really be creating > > custom frame managers (I think...I'm just scratching CLIM's surface) > > to provide eye candy effects (since I'm planning on targeting the > > masses, I've learned that it's pretty much all about the eye candy). > > Yet another would be something like the HTML/CSS/Javascript paradigm > > to create 2-d "applications." And the last would be the actual 3-d > > world where the users interact. > > > > A combination of Open Cobalt and World Forge seemed like the "proper" > > mix at first. But, the more I dug into smalltalk, the less impressed I > > was. I kept thinking "If only I could write a macro to do all this..." > > > > The more I dug into it, the more I realized just how big and ambitious > > this project is. > One thing I've found is that I can build applications much faster in > Common Lisp and they are much more robust. You may find that as you > become more proficient in CL that your project doesn't take as long as > you thought. > > If I'm going to be dedicating 10 years (or more) to > > something, and forcing my users to download some obscure runtime > > anyway...why not go with a language that left my jaw on the floor and > > my head spinning? I realize common lisp isn't perfect, but what is? > > (Clojure's tempting. I downloaded it, spent about 20 minutes to get a > > REPL, and finally gave up. It may be mature and "ready for the big > > leagues" before this project is, but...common lisp's there now. > > Racket's similarly tempting, but I just don't seem to fit with the > > Scheme community). > I currently use SBCL as my free CL of choice and LispWorks as my > commercial CL of choice. > > The ideas behind McClim seem to feel like it's the right "fit" for the > > GUI part of the project. Not all the eye-candy pieces, of course. > > Just...conceptually. I've been digging my way through the old mailing > > list archives (the check-in comments are a lot more educational than I > > realized at first. I'm glad they got archived that way), and I see > > that there's been speculation about an OpenGL backend for ages now > > (and at least an experimental stab at writing one). > > > > Conventional wisdom seems to dictate using something like one of the > > GTK bindings for the UI. But it seems to me that, if I started there, > > I'd just wind up re-implementing tons of CLIM to get to an abstraction > > level where I could forget about that and get down to real work. It > > seems to me that my time would be better spent helping get the GTKairo > > working solidly. > It's interesting that you should mention "re-implementing tons of CLIM". > I have watched (mostly) and participated (a little) in the development > of XEmacs for many years. As they discussed the various target user > intefaces (Win32, GTK, etc.), I noticed that they were implementing > parts of CLIM in C. > Actually, one of the nice things about using CL and CLIM is that you get > to define your UI separately from the implementation, thus, allowing you > to more easily port your application to more systems. CLIM can have > multiple backends: GTK, OpenGL, Win32, XLib, etc. > > Either way, I'll wind up duplicating the work to switch to some crazy > > gadget set built entirely on some 3-d engine or other. > > I see one of the fundamental programs being a traditional "form > > builder" kind of drag-and-drop thing along the lines of VB. Probably > > with some kind of tree view (or maybe boxes) to hide the fact that the > > code's actually being written in lisp. > > > > Am I barking up the wrong tree? Like I said...I've been going through > > the old mailing list archives. I've normally have wrapped that up and > > at least gotten more than a passing acquaintance with actually writing > > McCLIM code (at this point, I'm just digesting that ancient CLIM > > "walk-through" referenced first on the home page) before de-lurking. > > But I ran across someone else today who seems to be thinking on at > > least vaguely parallel lines to mine, and I figured this was the best > > place to check before I wasted his time with my ideas. > I say go for it. I haven't found a project yet that I wouldn't rather > do in Lisp. > Craig > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From CraigL at sc.rr.com Sat Nov 20 23:08:16 2010 From: CraigL at sc.rr.com (Craig Lanning) Date: Sat, 20 Nov 2010 18:08:16 -0500 Subject: [mcclim-devel] Feasibility Question In-Reply-To: <000e0cd20d92fdfba90495820c73@google.com> References: <000e0cd20d92fdfba90495820c73@google.com> Message-ID: <1290294496.2270.168.camel@lanning.lanning.lan> On Sat, 2010-11-20 at 20:41 +0000, k2msmith at gmail.com wrote: > Thanks for the interesting thread. I was considering using clim for an > experimental openGL application I'm writing, but I didn't get too far > with it (on Darwin platform). So, I'm using OpenGL and GLU only for > now. See link below for more details. Since I'm at a point where I > need some high-level UI gadgets like pop-menus and things, it would be > nice to fit what I have into a lisp framework, since the toplevel of > what I have is written in lisp (image proceessing stuff is in C++). > > http://kevinmichaelsmith.posterous.com/ Interesting project. > I'm interesting in learning more about the benefits of clim and if > that could work with an openGL canvas using mac backend for UI look > and feel. I don't know of any real reason that it can't. McCLIM has the beginnings of an OpenGL backend, but I don't know how far along it is. The trick is to get the OpenGL backend to the point where it supports the current 2D CLIM capabilities. Then start extending CLIM into 3D. Using something like CLIM helps relieve you of having to implement all of the common functionality like menus, panes, layout, etc. You could spend your time on getting the backend code to work and then you get the other stuff for free. Maybe CLIM needs to be extended to simultaneously support multiple backends within the same UI. That way the 2D windows, menus, etc are done in a conventional backend and the specialized panes could use a more specialized backend like OpenGL to do 3D. Craig From rm at tuxteam.de Wed Nov 24 22:25:27 2010 From: rm at tuxteam.de (rm at tuxteam.de) Date: Wed, 24 Nov 2010 23:25:27 +0100 Subject: [mcclim-devel] Two problems with McCLIM with gtkairo In-Reply-To: <1289054914.5673.50.camel@reginleif.ufanet.ru> References: <1289054914.5673.50.camel@reginleif.ufanet.ru> Message-ID: <20101124222527.GA6310@seid-online.de> On Sat, Nov 06, 2010 at 07:48:34PM +0500, Makarov Alexey wrote: > Hello! > > I have two problems with gtkairo backend. > > First problem is black application frame while presented information on > frame parts is not changed, mouse pointer is not hover on scrollbar or > interactor menu doesn't appear on that pane. This appear in Ubuntu Linux > 10.04 with SBCL 1.0.40 and GTK 2.20. I have similar problems with the gtkairo backend. As a quick fix I use (setf clim-gtkairo::*medium-type* :gdk) wich seems to fix the redrawing problems. With :cairo as a medium type I get serious redraw problems (mostly areas that stay black). I'm running SBCL on Ubuntu 8.10. No idea about your windows problems. HTH Ralf Mattes > Second problem is McCLIM with gtkairo backend hangs on Windows XP on > SBCL 1.0.43 > (https://sites.google.com/site/dmitryvksite/sbcl-distr/sbcl-1.0.43-threads-g002bdc7.msi) and GTK 2.22. I try to eval: > > (run-frame-top-level (make-application-frame 'superapp)) > > Then application frame is appear but panes not draw on it and frame hang > (can't close window). SBCL hang too, but this issue I can avoid: > > (sb-thread:make-thread > (lambda () > (run-frame-top-level (make-application-frame 'superapp)))) > > I run this code: > > (defpackage "APP" > (:use :clim :clim-lisp) > (:export "APP-MAIN")) > > (in-package :app) > > (define-application-frame superapp () > () > (:pointer-documentation t) > (:panes > (app :application :display-time nil :height 400 :width 600) > (int :interactor :height 200 :width 600)) > (:layouts > (default (vertically () app int)))) > > (defun app-main () > (run-frame-top-level (make-application-frame 'superapp))) > > (define-superapp-command (com-quit :name t) () > (frame-exit *application-frame*)) > > (define-superapp-command (com-parity :name t) ((number 'integer)) > (format t "~a is ~a~%" number > (if (oddp number) > "odd" > "even"))) > > I use quicklisp and mcclim from quicklisp repository. > > Have your any ideas to solve that problems? > > -- > Makarov Alexey > > > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel