graphic-forms-devel

graphic-forms-devel@common-lisp.net

53 discussions

Re: [graphic-forms-devel] graphic-forms
by Michael Jung 04 Sep '06

04 Sep '06

At 19:23 04.09.2006, you wrote: >Also, you're only loading the callback patch once, right? I don't >know what happens if you execute that code multiple times; it >might be harmless or it might not. Graphic-Forms automatically >loads it via the ASD file. > >Another thing to try is to restart SBCL without the callback >patch, and remove the :stdcall attribute from Alastair's >code. Win32 has a special hack that allows non stdcall >callbacks to be used as window procedures. This would >help rule out whether that patch is causing the problem. It didn't change anything loading the patch before compiling graphic-forms or not. I will try and remove the attribute and see what happens Michael Jung

1 0

Re: [graphic-forms-devel] graphic-forms
by Michael Jung 04 Sep '06

04 Sep '06

At 19:15 04.09.2006, you wrote: >On 9/4/06, Michael Jung <jung(a)mijn-design.de> wrote: >> >>Hello Jack, >> >>At 17:55 04.09.2006, you wrote: >> >> >OK, that's helpful info. Check your taskbar and see if in fact a window >> >did get created but at the bottom of the desktop Z-order instead of >> >the top. I notice this happening no matter whether I use SBCL or >> >CLISP, and it has something to do with the console window. Whereas, >> >if I run an application delivered as an executable, the window appears >> >as you would normally expect. >> >>It looks as if no window is created at all, nothing in the taskbar. > >If it were me at this point, I would start sprinkling debug statements >around to try to find out more info. I would do this with Alastair's >hello.lisp since it is such a small amount of code to work with. >Check that REGISTERCLASSEX is not returning zero, and that >CREATEWINDOW is returning a non-null foreign pointer. Check >that his WINDOW-PROCEDURE function is getting called, >and print out the argument values, so that you can see what >events get processed. Ok, I know what you mean, but that will take some time. In nearly any other language I would have done it already, but Lisp is ... different ;-) and I have to learn so much >If those debug statements indicate everything is succeeding, >but you still don't see any window, then I would suggest installing >a Spy utility (I use Winspector Spy) so that you can check whether >the window is getting created but not being made visible. Alastair's >window classname is "hello". I have a Spy software around and can check >Is it safe to assume that you don't have any desktop mods or >virtual desktops or anything of that sort? No, nothing. I'm thinking of setting up a plain new VM just for training on Lisp development just in case any of my other environments is causing troubles. Michael Jung

1 0

Re: [graphic-forms-devel] graphic-forms
by Michael Jung 04 Sep '06

04 Sep '06

Hello Jack, At 17:55 04.09.2006, you wrote: >OK, that's helpful info. Check your taskbar and see if in fact a window >did get created but at the bottom of the desktop Z-order instead of >the top. I notice this happening no matter whether I use SBCL or >CLISP, and it has something to do with the console window. Whereas, >if I run an application delivered as an executable, the window appears >as you would normally expect. It looks as if no window is created at all, nothing in the taskbar. Regards Michael Jung

2 2

[graphic-forms-devel] graphic-forms
by Michael Jung 04 Sep '06

04 Sep '06

Hello Jack, first of all, thanks for offering help to a newbie ! Nothing unusal happens so far, everything compiles fine. When I load and start the tests it seems to evaluate and hangs, so that means it doesn't return to the normal prompt. I thought that I'm doing something wrong with that patch for sbcl, tried the demo from lisphacker.com - the same, nothing happens. Regards Michael Jung Senior Software-Architect | Designer | Consultant | Trainer Borland Delphi, LISP, Linux-Workstations, Server, Virtual-, Cluster-, Grid-Computing fon: 0163 - 517 66 02 openBC - Get together - wherever you are -> http://www.openbc.com/go/invita/5622521

2 1

[graphic-forms-devel] gfw:append-item API change
by Jack Unrue 28 Aug '06

28 Aug '06

Just a heads-up that I intend to change gfw:append-item such that the 'text' and 'image' required arguments will be replaced with a single 'object' argument. Whereas the old arguments were required to be a string and a gfg:image, respectively, the new argument will accept any Lisp object type. In addition, the gfw:item-manager class, which replaces the old gfw:widget-with-items class, will gain two new slots: text-provider will hold a function accepting a single argument returning a string image-provider will hold a function accepting a single argument returning a gfw:image It's my hope that this will enable greater flexibility for rendering code. I'm borrowing this idea from JFace in the Eclipse framework, which has similar abstractions. -- Jack Unrue

1 0

[graphic-forms-devel] input requested: adding a REPL to the library
by Jack Unrue 10 Jul '06

10 Jul '06

I'm thinking about adding a Lisp listener to Graphic-Forms, and was hoping to get some input from you all. Do you think it is: a) a "must have" feature if GF is to be taken seriously b) a "nice-to-have" feature that you could live without (note -- thinking of the availability of SLIME or commercial IDEs as I write this) c) more important to make sure apps built with GF have the right building blocks for a listener, rather than bundling one directly with the library proper d) a complete waste of time ??? Thanks in advance. -- Jack Unrue

1 0

[graphic-forms-devel] event functions API change
by Jack Unrue 08 Jul '06

08 Jul '06

Hi all. Just a quick heads-up that I'm going to be changing the argument lists for the event-*** generic functions so that I can make the lesser used arguments &optional. E.g., (defgeneric event-paint (dispatcher widget time gc rect) ...) will become (defgeneric event-paint (dispatcher widget gc &optional time rect) ...) ...similar changes will be made to the other functions. -- Jack Unrue

1 0

[graphic-forms-devel] Graphic-Forms 0.3.0 release
by Jack Unrue 26 Apr '06

26 Apr '06

The next release of Graphic-Forms (version 0.3.0), a CL library for Windows GUI programming, is now available. This is definitely pre-alpha code, so be prepared for missing features, bugs, and API changes in subsequent releases. Download a release tarball from here: http://prdownloads.sourceforge.net/graphic-forms/graphic-forms-0.3.0.tar.gz… The primary changes in this release are as follows: • implemented graphics-context methods for the typical drawing operations and pen attributes; see the new test program invoked by (gft::run-drawing-tester) • implemented a representation of fonts and font data, including an API for looking up fonts based on font data • implemented font metrics and text metrics querying • expanded image drawing operations to support double-buffering • expanded the classes representing different window types: top-level represents primary application windows, panel represents child-windows, and the root-window class represents the desktop • formalized the window parent and owner concepts with documentation and functions • implemented the display class to represent the monitor attached to the system • implemented new window style attributes to help applications choose whether the system should automatically repaint the background • provided maximum-size and minimum-size functions to allow applications to constrain window sizes • revised label controls to support either text or images • implemented the file-dialog class which encapsulates the standard open/save dialog • made other bug fixes and resource usage cleanup Please consult README.txt for other details about this release. The main project website is: http://common-lisp.net/project/graphic-forms/ -- Jack Unrue

1 0

[graphic-forms-devel] another API cleanup
by Jack Unrue 01 Apr '06

01 Apr '06

Just in case anyone happens to read the archive before I release version 0.3.0, I'm also making two corrections to the existing :style initarg for top-level windows: 1) the value of the :style initarg will be a list to make it consistent with other classes that also use that initarg 2) I'm removing the style- prefix from those keywords -- Jack Unrue

1 0

Re: [graphic-forms-devel]
by Jack Unrue 29 Mar '06

29 Mar '06

On 3/28/06, Mac Chan <emailmac(a)gmail.com> wrote: > Hi Jack, Hi Mac! > Since I don't see anyone post on the dev. mailing list, I just want to > send you an email to say hi and let you know that I'm one of those > people that are interested in your project. > > I'm a lisp hobbyist and used lispworks capi to create some homebrew > applications for fun (a vocab builder for my sister, an email > notification app for my cousin, etc). Cool! > However, CAPI is severely limited to cover all windows programming aspects. > Your project is very interesting for lisp lover like myself who wanted > to create windows programs. > > A lot of lisp guru are windows haters (don't know why), sometimes you > don't even want to mention that you liked to program in windows on cll > for fear that other hackers will look down on you. I too have detected that on occasion. But I have found that there are also a bunch of folks on cll who are very helpful, and some of them are actively working on Windows ports of Lisp stuff (not counting me). I guess I don't care what the anti-MS crowd thinks; if people want to rant and rave, that's their choice :-) > It's that pathetic... > > Anyway, please keep up the good work. Thanks very much for your encouraging words. I should probably put some sort ofa roadmap up on the project website so folks can have an idea of what to expect. What I'm working on right now is the usual assortment of graphic operations, and I think I will make a new release with that next. I hope you will eventually (once I get more stuff implemented!) find Graphic-Forms to be useful. Thanks again for your email. -- Jack Unrue

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

graphic-forms-devel