Re: [Chicken-users] cross-platform gui toolkit
Brandon J. Van Every wrote: Crazy Eddie's GUI System http://www.cegui.org.uk/wiki/index.php/Main_Page is worth looking at in this regard. It is a C++ toolkit, skinnable, MIT licensed, and has survived as the preferred GUI of the Ogre3D engine. Ogre3D ain't small potatoes. This means CEGUI has community resources that most open source projects lack. When I say look at it, I mean for design inspiration, since it's a successful system. I think C++ wrapping projects are currently hard in Chicken, so I've been leery of chasing anyone's C++ development. Not bad! And give some inspiration. I'd ignore C++ wrapping is currently hard in Chicken. It could be solved rather easily for this particular (and simillar) case(s). What I would do: 1. Nag Felix, the poor guy - until he adds (that is finishes, as I recall) an interface to call Chicken from POSIX threads. Maybe that's even possible already, but I don't think so. Is it? 2. Start two POSIX threads. One running Crazy Eddie plus a some C++ driver code talking to the other POSIX thread running Chicken, where it's a different job to dispatch events to whatever chicken thread. I like CE's XML way of specifying GUI layouts. Fit's pretty well with SXML on the Scheme side. It should not be too hard to deploy the ResourceProvider mechanism of CE to fetch the XML in core from Chicken. Also Input gathering ougth to be done here per default (though for the sake of game developers optionally). This must not preclude event injection from the Scheme side. 3. At the Scheme side, *I* would (I told you in the other mail that I'm sold already) base the interface at this cell-gtk syntax (with modifications like dropping mk- prefixes. I'd consider to modify the language: compare to CE's syntax and unify or alias what maps. 3b. Do these cells very general, Scheme way of doing things. If this becomes a SRFI of it's own, not bad but also not nessesary. 4. While doing 2 and 3 in parallel, have a look aside to the cell-gtk LISP code. Eventually, that is once 3 is sort of stable (beta), throw some alternate GTK bindings underneath the syntax of 3. 4b. Having two bindings, some KDE guy will probably sit down and create an alternative to the CE thread, driving KDE. 5. Write two SRFI's about (1) and (3). (3) will need some system support impossible with pure Scheme - the graphics side. But there where several bindings at this time already. And the conversation between Scheme and the GUI system is by now broken down to a thread-thread communication, which could be done via ports for the SRFI, while we don't have an extra interpreter and pipes for the real thing of an implementation. 6. Have a lot fun with the result. And don't mind if the SRFI takes years to adoption. /Joerg ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Hm, I think a cross-platform gui toolkit is a big thing anyway? Let's assume you want a lighwight GUI toolkit. You said, you want to accomplish the platform independency by implementing your API against different existing platform specific toolkits. I suppose that approach will take as least as much effort as when you implement your API against QT, because the platform independency is encapsulated in it. You may be right there: but with support for a couple of toolkits, you gain one very important thing: improved independence regarding platforms and libraries. Last but not least: Couldn't the meta-object protocol of QT actually help to write a wrapper that is not as fragile regarding changes of QT as wrappers for other toolkits regarding their changes? Right, too. Really, targeting Qt(4) is a perfectly reasonable choice. Actually, I have no clue what's the best option - but I fear committing to one particular toolkit. I see your point. However, independence of the toolkit ranks second for me. Having a platform independent API with which you can build full-featured professional looking GUIs ranks first. It seems to me that here are two groups. One wants a slick API for 3D-OpenGL-game-development and the other a comparatively big API with lots of standard-widgets for standard-looking desktop-applications. Perhaps we should distinguish between the requirements these two groups have? I suppose that two different APIs are necessary. but I fear committing to one particular toolkit I think there are people who say the same and choose Qt because of that fear ;) Best regards Daniel Sadilek ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
I agree. My preference would be SDL and GTK+ based on self interest. Both of these work well on the mobile/handheld devices I am interested in. I have written some bindings to libsdl-console (the kind of thing you find in Quake) with Chicken and it was very easy and worked well on a handheld. I have not done any GTK+ programming but some fairly influential mobile phone projects are being based on it. For desktop development I use Cocoa but there is also GNUstep which I have not tried. I am not sure there are many fans of Objective-C out there though! Perhaps we need to take a vote/poll on all the options available. John. On 08/02/07, Daniel Sadilek [EMAIL PROTECTED] wrote: It seems to me that here are two groups. One wants a slick API for 3D-OpenGL-game-development and the other a comparatively big API with lots of standard-widgets for standard-looking desktop-applications. Perhaps we should distinguish between the requirements these two groups have? I suppose that two different APIs are necessary. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Daniel Sadilek wrote: Right, too. Really, targeting Qt(4) is a perfectly reasonable choice. Actually, I have no clue what's the best option - but I fear committing to one particular toolkit. I see your point. However, independence of the toolkit ranks second for me. Having a platform independent API with which you can build full-featured professional looking GUIs ranks first. It seems to me that here are two groups. One wants a slick API for 3D-OpenGL-game-development and the other a comparatively big API with lots of standard-widgets for standard-looking desktop-applications. Perhaps we should distinguish between the requirements these two groups have? I suppose that two different APIs are necessary. There are at least 3 camps: - put OpenGL windows on screen, no widgets. For game developers who don't want a bunch of extraneous stuff in their way. Not much to discuss about requirements here. We've got 3 people working on it, and we all know what we're doing well enough. We welcome anyone who actually wants to cut code. - minimalist GUI, minimal core set of the most useful widgets. Intended to be simple, portable, and sufficient for modest GUI apps. Not intended to be fully featured. Not important to have native look and feel. Has many different GUI toolkits as backends. This is Felix's plan for conquering the universe. I fear he won't actually secure the support resources for more than 1 platform, in practice. Multi-platform will exist as proof-of-concept, but outside the de facto area of core strength, the builds will suck and be forever broken. I point to Chicken itself as evidence, pre-CMake. MinGW simply didn't get the love. MSVC had 2 different build methods and different path conventions than the Unix builds. It took 1 year to pave all that over. People who come along to do that much gratuitous refactoring are the exception rather than the rule, i.e. I am insane. - maximalist GUI. Maximal number of widgets, fully featured, can handle any enterprise class problem you have in mind. Native look and feel. Fear of committment is silly here. WxWidgets, GTK+, and Qt have been dealing with the heavy duty and portable problem for the past decade. If you want to be fully featured, you can't do better. Pick 1 and wrap it. Also there's an undercurrent of research and exoticism in some people's posts, with regards to event handling and other would-be GUI features. This could skew people into yet more camps. RD is a non-issue for OpenGL windowing. We're not going to do enough to get ourselves into trouble. I'm sure Thu will cook up some event handling experiments, and at some point I'll try my own hand at it. Don't know what John has in mind here. For Felix's portaGUI, the RD impulse will cause a lot of design discussion. Hope it sheds more light than heat. I don't expect all designers to last through the process. The direction taken will not be equally fascinating to all parties, and some will lose interest. For a maximalist GUI, the RD impulse is counter to getting the job done. WxWidgets, GTK+, and Qt are exceedingly mature projects with gigantic user communities. Not Invented Here isn't going to get anyone anywhere. People have to value the pragmatic result, not the fun of doing their own RD. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
john wrote: Perhaps we need to take a vote/poll on all the options available. I think people are already voting when they state their preferences. What would be good, is for people to commit to writing some code. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
How about WxWidgets? It is very much a multiplatform GUI tool. On Linux/BSD/Unix systems, Wx maps to Gtk (not sure but may also be Qt). On Windows, it maps to the Win32 API and on OS X it maps to the Carbon/Cocoa interface (It is a standard install part of XCode). This way, widgets are rendered using native engines. It might be really useful alternative. -Dinesh On 2/7/07, felix winkelmann [EMAIL PROTECTED] wrote: On 2/7/07, Daniel Sadilek [EMAIL PROTECTED] wrote: Fully understandable, but Qt is big and I fear that a complete wrapper will end up as a huge lump that has continuously be maintained (to stay complete). The qt egg is explicitly meant as a lightweight facility for exploiting the meta-object protocol of Qt - sort of an experiment (but still quite useful). Hm, I think a cross-platform gui toolkit is a big thing anyway? Let's assume you want a lighwight GUI toolkit. You said, you want to accomplish the platform independency by implementing your API against different existing platform specific toolkits. I suppose that approach will take as least as much effort as when you implement your API against QT, because the platform independency is encapsulated in it. You may be right there: but with support for a couple of toolkits, you gain one very important thing: improved independence regarding platforms and libraries. Last but not least: Couldn't the meta-object protocol of QT actually help to write a wrapper that is not as fragile regarding changes of QT as wrappers for other toolkits regarding their changes? Right, too. Really, targeting Qt(4) is a perfectly reasonable choice. Actually, I have no clue what's the best option - but I fear committing to one particular toolkit. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/8/07, Brandon J. Van Every [EMAIL PROTECTED] wrote: There are at least 3 camps: - put OpenGL windows on screen, no widgets. For game developers who don't want a bunch of extraneous stuff in their way. Not much to discuss about requirements here. We've got 3 people working on it, and we all know what we're doing well enough. We welcome anyone who actually wants to cut code. Good. I plan to use it then. But is there a feature list, stuff that you need to add? It still seems to me that the current opengl egg + glut egg does quite a bit already, but maybe not enough for text rendering (which I have not investigated yet). And you don't want to change the existing opengl egg's API, right? (So that code I write now will still run on future ones?) - minimalist GUI, minimal core set of the most useful widgets. Intended to be simple, portable, and sufficient for modest GUI apps. Not intended to be fully featured. Not important to have native look and feel. Has many different GUI toolkits as backends. This is Felix's plan for conquering the universe. I fear he won't actually secure the That also is the base level of what I want to do. I will try to achieve a pretty advanced level of portability by having a lowest-common-denominator 2D graphics API, which will render to OpenGL and to my own frame-buffer 2D implementation, or possibly others (SDL? sx?) Then I will build widgets by drawing them with the 2D API. Whenever OpenGL is the basis, you will be able to use the OpenGL API too, and draw 3D stuff into the same windows. (And maybe not on some of the other basis platforms.) As a bonus if you take a nominally 2D GUI, but with some 3D-modeled elements, and apply textures and a lighting model, it would look slick compared to any of the existing 2D toolkits. Now that Vista has arrived (and people have had Mac OS X envy for years already), the existing ubiquitous grey widgets are going to be perceived the same way TK is now, in a year or so. I'm not going to start out with slick appearance being the #1 goal, the way a game developer would; but if we make sure it's possible, then lots of 3D widget themes will emerge over time, and what started out as a minimalist GUI gets legs and has a direction for growth (towards maximalism), while at the same time it works for the RD stuff. And my goal is to keep it backwards compatible and portable too (but only with the simpler themes). The actual applications should run on all the platforms, or as many as possible (since some apps will absolutely require OpenGL). The real trick is that in going towards maximalism I want to make sure the API for applications to use it remains terse and easy and uniform. support resources for more than 1 platform, in practice. Multi-platform will exist as proof-of-concept, but outside the de facto area of core strength, the builds will suck and be forever broken. I point to Chicken itself as evidence, pre-CMake. MinGW simply didn't get the love. MSVC had 2 different build methods and different path conventions than the Unix builds. It took 1 year to pave all that over. People who come along to do that much gratuitous refactoring are the exception rather than the rule, i.e. I am insane. Good! Me too! :-) (laughs maniacally) - maximalist GUI. Maximal number of widgets, fully featured, can handle any enterprise class problem you have in mind. Native look and feel. Fear of committment is silly here. WxWidgets, GTK+, and Qt have been dealing with the heavy duty and portable problem for the past decade. If you want to be fully featured, you can't do better. Pick 1 and wrap it. This I don't want to develop (no time for it) but I might sometimes have a use for it for quick 'n dirty stuff if it could be that easy to use. RD is a non-issue for OpenGL windowing. We're not going to do enough to get ourselves into trouble. I'm sure Thu will cook up some event handling experiments, and at some point I'll try my own hand at it. What kind of experiments? For Felix's portaGUI, the RD impulse will cause a lot of design discussion. Hope it sheds more light than heat. I don't expect all designers to last through the process. The direction taken will not be equally fascinating to all parties, and some will lose interest. Yeah too much discussion does take too much time. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Shawn Rutledge wrote: On 2/8/07, Brandon J. Van Every [EMAIL PROTECTED] wrote: There are at least 3 camps: - put OpenGL windows on screen, no widgets. For game developers who don't want a bunch of extraneous stuff in their way. Not much to discuss about requirements here. We've got 3 people working on it, and we all know what we're doing well enough. We welcome anyone who actually wants to cut code. Good. I plan to use it then. But is there a feature list, stuff that you need to add? I'm not big on frontloaded discussions. I am big on looking at what work people have already done, and I haven't finished that exercise yet. It still seems to me that the current opengl egg + glut egg does quite a bit already, but maybe not enough for text rendering (which I have not investigated yet). Glut is an ancient, decrepit, not open source, not modifiable toolkit that must die. There is of course FreeGlut that attempts to remedy that problem, but its development didn't look very active. I don't think we should chase it. I think we should mostly write our own Scheme code. We'll get more people willing to expand various capabilities if we're actually using the language the Scheme developers want to be using. And you don't want to change the existing opengl egg's API, right? (So that code I write now will still run on future ones?) No promises. I'm not into gratuitous change for its own sake, but I haven't looked at that egg's design yet, and I know it doesn't support OpenGL 2.0 or the various OpenGL ESes. Now that Vista has arrived (and people have had Mac OS X envy for years already), the existing ubiquitous grey widgets are going to be perceived the same way TK is now, in a year or so. I'm not going to start out with slick appearance being the #1 goal, the way a game developer would; but if we make sure it's possible, then Crazy Eddie's GUI System http://www.cegui.org.uk/wiki/index.php/Main_Page is worth looking at in this regard. It is a C++ toolkit, skinnable, MIT licensed, and has survived as the preferred GUI of the Ogre3D engine. Ogre3D ain't small potatoes. This means CEGUI has community resources that most open source projects lack. When I say look at it, I mean for design inspiration, since it's a successful system. I think C++ wrapping projects are currently hard in Chicken, so I've been leery of chasing anyone's C++ development. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
[snip] RD is a non-issue for OpenGL windowing. We're not going to do enough to get ourselves into trouble. I'm sure Thu will cook up some event handling experiments, and at some point I'll try my own hand at it. What kind of experiments? Hi, I think Brandon talked about the (long) mail I've send about gui api design. But it's not intended as a Chicken community project (although I've nothing against). It's simply something I was thinking for a while and then Felix's gui project appeared, so I thought I could share with you what I was thinking. And if it comes to be a source of ideas for Felix's project, then good ! Cheers, thu ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Fully understandable, but Qt is big and I fear that a complete wrapper will end up as a huge lump that has continuously be maintained (to stay complete). The qt egg is explicitly meant as a lightweight facility for exploiting the meta-object protocol of Qt - sort of an experiment (but still quite useful). Hm, I think a cross-platform gui toolkit is a big thing anyway? Let's assume you want a lighwight GUI toolkit. You said, you want to accomplish the platform independency by implementing your API against different existing platform specific toolkits. I suppose that approach will take as least as much effort as when you implement your API against QT, because the platform independency is encapsulated in it. Last but not least: Couldn't the meta-object protocol of QT actually help to write a wrapper that is not as fragile regarding changes of QT as wrappers for other toolkits regarding their changes? Best regards Daniel Sadilek ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Brandon Van Every wrote: Chicken wouldn't have half the eggs it does if the non-Chicken Scheme community had taken that position. Fortunately for us, they did not. Which half? My world is OpenGL and C FFIs. I don't see any interloper eggs helping out here. It's one thing if your task is pure Scheme, quite another if your task is OS interfacing. Brandon, please don't take things personal. Don't downplay others contributions just because you don't know yet where you might need them. I'm not sure you are right here, Brandon. The people and interest are there. Just some of them will not jump on the chicken/gui ship when it's chicken specific - as they refuse to jump on those other PLT or whatever specific ships even though they seriously lack an viable alternative. You can of course post an abstract GUI project to comp.lang.scheme and see what takers you get. But from a practical standpoint, you're in serious danger of design by committee. :-) If I would bother so much, maybe I would do. Or a bunch of people talking and no action. But I'm not doing this for the fun of it. I'm forced to think economical too. There's a project, a design, a market need, obstacles, challenges, actual and potential resources. I'm on action for several years now. Slowly, sure, but eventually not without success. (I just hired a first employee for Scheme programming - ok wrt. no action, thank you.) A good GUI toolkit is such a resource. But I don't have the time or money to write something up, just to see what I can eventually use it for. So let me tell you something: a chicken specific gui toolkit, which somehow wraps opengl and that it - that's something I don't have time for. It would make a lot more sense to get it done in Chicken with a few people, show it to the world, and show that it's actually good. Then refactor whatever is Chicken specific about it, if you can draft up the labor for ports. However I still have so much time for it, that I might spend half an hour or more to write up my requirement for those, who might pick the project up anyway. Not because I'm ready to fight with them over their design. They might care or ignore my notes entirely. If they ignore my requirements however, there is little chance that, once they show their work to world, they will meet my needs. If it fails, like those toolkits before, I'll ignore their work as much as they ignored my requirements. (Hey, I can live without M$-Windows - because it fails my requirements - I'll come over yet another gui toolkit to forget.) However I've got the feeling that there where some persons, who listened, who - at least partially - agreed with my concerns. Look, Brandon: long ago, when there was no chicken Scheme, I choose a pretty nice Scheme for the feature set it had: multithreaded, asynchronous i/o, persistant data, compile to C. (Before than, I used bigloo for my work.) Then I went on to actually read the source and had a look at it's community to find out how good I could support my compiler without the original author (hey, he could be run over by a bus the next day), before I based a business case on it. A little more community would have been a plus, but as things where, it was ok. The I coded. I tried to abstain from anything not looking like R5RS+SRFI (except when there was real - i.e. economic - pressure). I ignored a nice object system. I reimplemented few features to avoid dependancies. I ignored a huge amount of code (DNS, PDF, database integration, font metrics, X11 integration spring to mind), which all where very tempting to just reuse (and add sexy features). All because - by design - I'm not going to produce a rscheme specific result. Nevertheless - as I said economic pressure - a few things crept in, like FFI related code, few finalization issues, and eval/sandbox API questions, SSL etc. which keep the result system specific for the moment. (Currently the incompatibilities with chicken+eggs appear to boil down mostly to API differences, not feature sets anymore; some changes to our code base are just motivated to use chicken's APIs.) See: been there, done that. For economical reasons, we'll be able to shell out money for porting Askemos to Java. Otherwise I'll take the freedom to wait and help for more and more pieces of the work we have put into Askemos beeing doublicated for other Schemes. I'm not agry about that. Maybe a bit sad, because it's taking longer that way. The advantage for me: there'll be others who will be asked to fix their bugs. ;-) I'm desperately *and* paitiently waiting for the moment, when, eventually, there will be enough eggs to port Askemos in a few days, cutting off most of my code. Zero code sharing between hosts is what I call a heterogenous network and that's what Askemos is going to become - by definition. Schemers don't share code! (Except if doing so buys them time.) I wish you
Re: [Chicken-users] cross-platform gui toolkit
Hi! What all these toolkits share is a very static model of programming, which is a pity. Qt4 has improved support for dynamic widget manipulation, but, boy, it's fat. What is ``dynamic widget manipulation''? And how would a dynamic model of programming be diferent from the one used by Qt4? Groetjes, Peter. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Joerg F. Wittenberger wrote: Brandon Van Every wrote: Chicken wouldn't have half the eggs it does if the non-Chicken Scheme community had taken that position. Fortunately for us, they did not. Which half? My world is OpenGL and C FFIs. I don't see any interloper eggs helping out here. It's one thing if your task is pure Scheme, quite another if your task is OS interfacing. Brandon, please don't take things personal. Don't downplay others contributions just because you don't know yet where you might need them. This conversation does remind me that I haven't properly looked about for Scheme-based OpenGL windowing toolkits. I don't recall any from previous searches, other than SDL bindings, but it has been awhile since I looked. So let me tell you something: a chicken specific gui toolkit, which somehow wraps opengl and that it - that's something I don't have time for. Right, but that's all that 3D OpenGL game developers need. Collaboration isn't always beneficial, especially in the abstract. We only need to get a simple job done. It's also a mostly Chicken-specific job, binding to low level OS interfaces. You want to do something much more complicated and far reaching. The complication of your job, far outweighs the resources you're offering to do the job. So from my standpoint it is a loss. There is no benefit in worrying about the greater Scheme community for this particular task. Once we have our base layer working, and it matures, then presumably people will be writing much more pure Scheme code on top of it. Then maybe it is worth it to someone to refactor for other Schemes. Or maybe it isn't. There's always this question of *labor*. Who will extend and maintain the code? People don't just grow on trees to do all these porting and maintenance jobs. In fact, most people don't like maintaining other people's code. Attracting and keeping labor is a community formation problem. Strategically, I think Chicken is far better off trying to pull people into its fold, than trying to work with the Scheme community at large. That may sound like a matter of religion, but Chicken is tangible. Scheme isn't, when you're talking about OS-specific stuff. What in 3D-land would really bind up a community? I think a high quality 3D engine would. I think also, such an engine would inevitably have to succeed with 1 Scheme, in this case Chicken, before even remotely considering the possibility of porting it to other Schemes. The bar for success in a 3D engine is very, very high. Everyone and their mother's uncle has a 3D engine out there. What matters is if someone ships several commercial games with the engine. As you can imagine, by that time the engine is a *big* project. Porting it to another Scheme is a *huge* refactoring effort. Probably unjustifiable, and probably uninteresting to most people out there. However I've got the feeling that there where some persons, who listened, who - at least partially - agreed with my concerns. Listening and agreeing is one thing. Hammering out workable specs that address multiple people's concerns, and actually cutting code, is quite another. I have low expectations for you uber-GUI guys, frankly. You're all brilliant, you've all got wonderful ideas. But first you're going to get distracted by a lot of design stuff. Then some people are going to drop out, because the problem isn't interesting to them anymore, it's too much work, financial priorities rear their ugly heads, the design strategy isn't meeting their goals, or whatever. Then what you're going to actually get done, is either 1 binding to 1 extant toolkit, or 1 from scratch uber-simple toolkit. You may get part of a 2nd binding done, as proof of the backend concept. But it won't be very good because you won't have labor that's interested in doing the job. This is the elephant in the room about deferring problems through backends: those backends will never get done. You'll end up with 1 de facto backend. Show Me The Labor. I wish you all the success with the gui toolkit. If you are interested, I might take some time to review you design. For clarity: Thu, John, and myself are not working on the kind of GUI toolkit you're talking about. We're not doing widgets. We're just putting OpenGL windows up on a screen, so that game developers can get started with something productive. We're not going to try to make events invisible to the programmer. We will facilitate a developer who wants his own control over event loops, callbacks, and other event passing mechanisms. Game developers usually hate it when the toolkit gets in the way of how they want to do the event handling stuff. Ergo, there's going to be precious little design to comment on. That's why the job is doable with 3 people. More than doable. Our decisions amount to, should we write this mostly from scratch, stealing
Re: [Chicken-users] cross-platform gui toolkit
On Wed, Feb 07, 2007 at 12:12:44PM -0800, Brandon J. Van Every wrote: For clarity: Thu, John, and myself are not working on the kind of GUI toolkit you're talking about. We're not doing widgets. We're just putting OpenGL windows up on a screen, so that game developers can get started with something productive. We're not going to try to make events invisible to the programmer. We will facilitate a developer who wants his own control over event loops, callbacks, and other event passing mechanisms. Game developers usually hate it when the toolkit gets in the way of how they want to do the event handling stuff. So how is the SDL and OpenGL egg not sufficient for this? I've coded plenty of graphics programs (in C) with those two alone. Most games have some handwritten windowing system in them anyway--and wouldn't have it any other way. SDL provides plenty of fine granularity for things like keyboard/mouse events and the programmer has their own event loop. Unless I'm mistaken in understanding what you're trying to do, I think you're trying to solve a problem that isn't there. The SDL APIs (graphics, mixer, tiff, etc) are plenty good for serious games. In looking through the eggs, I'd add SDL-mixer and libpng to the pile, port the OpenGL egg to use OpenGL 1.5 at least, add an OpenGL Shader egg, and then there'd be *plenty* of goodies to write good games (and their level editors). If you want more toolkit-like junk, then write a nice asset management library since that is stuff a programmer usually just wants to have and doesn't like having to write. Later, -pete ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/6/07, felix winkelmann [EMAIL PROTECTED] wrote: On 2/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I agree with Joerg. Currently I am developing with bigloo and I am looking for a good GUI library to use with it. As I have used Gtk+ before (in OCaml and C), I am just experimenting how would be a bigloo interface to gtk. But I do not think I will use bigloo for all of my Scheme developments. The next project could be in Chicken, for instance. So common libraries to many scheme implementations are valuable to me and I think the Scheme community should put efforts to develop them, when possible. For that the Scheme community would first need a common FFI... Why? Wouldn't the SRFI just cover the API which a user of the GUI library can expect to have, rather than implementation strategy for every Scheme? ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/7/07, Shawn Rutledge [EMAIL PROTECTED] wrote: On 2/6/07, felix winkelmann [EMAIL PROTECTED] wrote: On 2/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I agree with Joerg. Currently I am developing with bigloo and I am looking for a good GUI library to use with it. As I have used Gtk+ before (in OCaml and C), I am just experimenting how would be a bigloo interface to gtk. But I do not think I will use bigloo for all of my Scheme developments. The next project could be in Chicken, for instance. So common libraries to many scheme implementations are valuable to me and I think the Scheme community should put efforts to develop them, when possible. For that the Scheme community would first need a common FFI... Why? Wouldn't the SRFI just cover the API which a user of the GUI library can expect to have, rather than implementation strategy for every Scheme? Hm. Yes, you are probably right there. I mostly think in terms of implementation, which I consider (currently) more important. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
felix winkelmann wrote: On 2/7/07, Shawn Rutledge [EMAIL PROTECTED] wrote: On 2/6/07, felix winkelmann [EMAIL PROTECTED] wrote: On 2/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I agree with Joerg. Currently I am developing with bigloo and I am looking for a good GUI library to use with it. As I have used Gtk+ before (in OCaml and C), I am just experimenting how would be a bigloo interface to gtk. But I do not think I will use bigloo for all of my Scheme developments. The next project could be in Chicken, for instance. So common libraries to many scheme implementations are valuable to me and I think the Scheme community should put efforts to develop them, when possible. For that the Scheme community would first need a common FFI... Why? Wouldn't the SRFI just cover the API which a user of the GUI library can expect to have, rather than implementation strategy for every Scheme? Hm. Yes, you are probably right there. I mostly think in terms of implementation, which I consider (currently) more important. And without concrete implementation on several Schemes, aren't SRFIs typically rejected / withdrawn as 1 guy's pet project? This is where lack of a standard C FFI is really crippling. It greatly raises the bar for what a proof of concept requires. Also, what's the scope of a SRFI? I'm doubting that cross-platform GUI widget toolkits are within scope. It's not a simple facility, it's a big piece of software. You could try instead for a standard window SRFI, but seeing how it's so OS-specific, I seriously doubt you'll get anyone to SRFI that. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/7/07, Daniel Sadilek [EMAIL PROTECTED] wrote: Fully understandable, but Qt is big and I fear that a complete wrapper will end up as a huge lump that has continuously be maintained (to stay complete). The qt egg is explicitly meant as a lightweight facility for exploiting the meta-object protocol of Qt - sort of an experiment (but still quite useful). Hm, I think a cross-platform gui toolkit is a big thing anyway? Let's assume you want a lighwight GUI toolkit. You said, you want to accomplish the platform independency by implementing your API against different existing platform specific toolkits. I suppose that approach will take as least as much effort as when you implement your API against QT, because the platform independency is encapsulated in it. You may be right there: but with support for a couple of toolkits, you gain one very important thing: improved independence regarding platforms and libraries. Last but not least: Couldn't the meta-object protocol of QT actually help to write a wrapper that is not as fragile regarding changes of QT as wrappers for other toolkits regarding their changes? Right, too. Really, targeting Qt(4) is a perfectly reasonable choice. Actually, I have no clue what's the best option - but I fear committing to one particular toolkit. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/7/07, Peter Busser [EMAIL PROTECTED] wrote: Hi! If I had a simple, GUI toolkit running on Linux, OS X and Windows, binds native widgets, has a simple basic graphics API (OpenGL would be ideal), is smaller than 1-2 MB, provides text-editing (multiline), buttons, images, frames, checkboxes, and a couple more widgets, simple menus, then I'd be happy. You mean something like an improved sx egg? Sort of. But SX lacks a multiline editor, depends on X and NO WAY I'M EVER EVER WRITING A LINE OF XLIB CODE! cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/7/07, Peter Busser [EMAIL PROTECTED] wrote: Hi! What all these toolkits share is a very static model of programming, which is a pity. Qt4 has improved support for dynamic widget manipulation, but, boy, it's fat. What is ``dynamic widget manipulation''? And how would a dynamic model of programming be diferent from the one used by Qt4? Well, the nice thing about Qt 4 is that they have extended the meta-object protocol: you can modify most widget properties by name, that is: you have a string designating the property (say, background color) and can set it through a single generic interface. Another feature is that it can create widgets at runtime from an XML spec and there is a very nice GUI designer that generates that XML. As usual everything is extensively documented. Still, it's big, slow and a bit proprietary. Powerful, though. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Hi, my personal choice would be QT. It has nice native look'n'feel on all platforms and a GUI builder. I managed to get the qt egg running on Mac OS X and Windows. For me, completing this egg would be the best option. Best regards Daniel Sadilek ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On Tue, Feb 06, 2007 at 11:45:35AM +0100, Joerg F. Wittenberger wrote: Brandon Van Every wrote: Matthew Welland wrote: I'd suggest going one step further and striving to keep the scheme portion not too chicken specific. Other schemes would only have to provide the interface layer and the bulk of the code could be reused. From a support and community growth standpoint, I see no value in projects that try to be all things to all Schemes. Doing things well on Chicken is what's important. Also, reuse doesn't mean anything without people and interest. I'm not sure you are right here, Brandon. The people and interest are there. Just some of them will not jump on the chicken/gui ship when it's chicken specific - as they refuse to jump on those other PLT or whatever specific ships even though they seriously lack an viable alternative. So adding one more ship will extends the set of options I'm *not* taking anyway. For me this boild down to accepting strange restrictions (besides coding R5RS(subset) whenever possible): [...] End goal: SRFI, not less! [...] I agree with Joerg. Currently I am developing with bigloo and I am looking for a good GUI library to use with it. As I have used Gtk+ before (in OCaml and C), I am just experimenting how would be a bigloo interface to gtk. But I do not think I will use bigloo for all of my Scheme developments. The next project could be in Chicken, for instance. So common libraries to many scheme implementations are valuable to me and I think the Scheme community should put efforts to develop them, when possible. José Romildo ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/6/07, Daniel Sadilek [EMAIL PROTECTED] wrote: Hi, my personal choice would be QT. It has nice native look'n'feel on all platforms and a GUI builder. I managed to get the qt egg running on Mac OS X and Windows. For me, completing this egg would be the best option. Fully understandable, but Qt is big and I fear that a complete wrapper will end up as a huge lump that has continuously be maintained (to stay complete). The qt egg is explicitly meant as a lightweight facility for exploiting the meta-object protocol of Qt - sort of an experiment (but still quite useful). cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/6/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I agree with Joerg. Currently I am developing with bigloo and I am looking for a good GUI library to use with it. As I have used Gtk+ before (in OCaml and C), I am just experimenting how would be a bigloo interface to gtk. But I do not think I will use bigloo for all of my Scheme developments. The next project could be in Chicken, for instance. So common libraries to many scheme implementations are valuable to me and I think the Scheme community should put efforts to develop them, when possible. For that the Scheme community would first need a common FFI... cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Joerg F. Wittenberger wrote: Brandon Van Every wrote: Matthew Welland wrote: I'd suggest going one step further and striving to keep the scheme portion not too chicken specific. Other schemes would only have to provide the interface layer and the bulk of the code could be reused. From a support and community growth standpoint, I see no value in projects that try to be all things to all Schemes. Doing things well on Chicken is what's important. Also, reuse doesn't mean anything without people and interest. I'm not sure you are right here, Brandon. The people and interest are there. Just some of them will not jump on the chicken/gui ship when it's chicken specific - as they refuse to jump on those other PLT or whatever specific ships even though they seriously lack an viable alternative. You can of course post an abstract GUI project to comp.lang.scheme and see what takers you get. But from a practical standpoint, you're in serious danger of design by committee. Or a bunch of people talking and no action. It would make a lot more sense to get it done in Chicken with a few people, show it to the world, and show that it's actually good. Then refactor whatever is Chicken specific about it, if you can draft up the labor for ports. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
John Cowan wrote: Brandon J. Van Every scripsit: From a support and community growth standpoint, I see no value in projects that try to be all things to all Schemes. Doing things well on Chicken is what's important. Chicken wouldn't have half the eggs it does if the non-Chicken Scheme community had taken that position. Fortunately for us, they did not. Which half? My world is OpenGL and C FFIs. I don't see any interloper eggs helping out here. It's one thing if your task is pure Scheme, quite another if your task is OS interfacing. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On Feb 5, 2007, at 11:04 PM, felix winkelmann wrote: On 2/6/07, Kon Lovett [EMAIL PROTECTED] wrote: I do like Cells, but I am unsure if Tilton is still working on Cello. It seems dormant. A TinyCLOS Cells extension would be nice (so would ContextL but Cells might be more generally useful). I've never grokked cells. It's hard to figure out the facts from Tilton's lingo... Is there some documentation available? Yeah, it is unnecessarily obscure. However, the declarative style with constraint satisfaction is the start of a good abstraction for UI programming. http://common-lisp.net/project/cells/ http://www.tilton-technology.com/cells_top.html Any use in following PLT's MrEd, MrLib Framework for Scheme GUI bindings? It uses an old hacked version of wxWidgets. I'd prefer to stay away from that. I meant the Scheme layer, not the impl. But I haven't done any analysis of it (except that I do not like the '%' hanging around in the symbols.) cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
[I sent this to the wrong list.] John Cowan wrote: Brandon J. Van Every scripsit: My world is OpenGL and C FFIs. Then don't talk as if you spoke for the whole Chicken community. It's irritating at best. If you avoid getting personal in engineering design discussions, you'll get a lot farther with people. I've provided my opinions and plainly labeled them as such. Since they are rationally stated and have the merits of focus and execution behind them, I don't apologize if you find them irritating. I don't count myself in the uber-GUI camp. I'm interested in quickly getting OpenGL windows and events functioning. Minh Thu and John Emhoff actually have some code for this already. Our outlook is game oriented, so we have a lot of agreement on what the interfaces and abstractions should and shouldn't be. We're going to write code and not worry about what an uber-GUI needs. Maybe we'll be one of the uber-GUI backends someday. Or maybe doing 1 thing well, matters a great deal more than trying to be all things to all people. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/5/07, Brandon J. Van Every [EMAIL PROTECTED] wrote: And why would you prefer a little bit of every toolkit, as opposed to picking 1 toolkit and doing a good job wrapping all its functionality? If you target every toolkit out there, then it'll be capable of very little. Too trivial for more than toys. Dependencies are the problem. By allowing multiple configurations you will serve a greater number of users and platforms. Also, wrapping a complete toolkit you just end up with a huge glob of wrapper code that is constantly out of date as you try to cover all corners (even the quickly changing ones, i.e. more obscure pieces). I don't need a super GUI. I just want some portable means of creating basic, simple GUIs (call them toys, if you want). Add a basic 2D graphics API, you can then create all the widgets in the world. I have a good deal of Qt experience, a bit of FLTK and generally not enough resources to create this on my own (surprise!). I also am unable to do any windows-related coding. Would there be someone interested in taking this up or join me with such an undertaking? It's suicide. Bind Qt. It doesn't matter if Qt is not all things to all people. It has a community behind it, which will cause growth of Chicken. You dabble a little in every GUI out there, and you have nothing. Binding Qt takes too much time, Qt is a big dependency for those who prefer Gnomish desktops, Qt is too large for some systems. Qt is also quite slow. Qt is proprietary. What I've found out so far: the one true C/C++ (native) gui toolkit does not exist, so I'd rather not bet a bunch of work on wxWidgets or Qt. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On Mon, Feb 05, 2007 at 09:02:36AM +0100, felix winkelmann wrote: On 2/5/07, Brandon J. Van Every [EMAIL PROTECTED] wrote: And why would you prefer a little bit of every toolkit, as opposed to picking 1 toolkit and doing a good job wrapping all its functionality? If you target every toolkit out there, then it'll be capable of very little. Too trivial for more than toys. Dependencies are the problem. By allowing multiple configurations you will serve a greater number of users and platforms. Also, wrapping a complete toolkit you just end up with a huge glob of wrapper code that is constantly out of date as you try to cover all corners (even the quickly changing ones, i.e. more obscure pieces). I don't need a super GUI. I just want some portable means of creating basic, simple GUIs (call them toys, if you want). Add a basic 2D graphics API, you can then create all the widgets in the world. I have a good deal of Qt experience, a bit of FLTK and generally not enough resources to create this on my own (surprise!). I also am unable to do any windows-related coding. Would there be someone interested in taking this up or join me with such an undertaking? It's suicide. Bind Qt. It doesn't matter if Qt is not all things to all people. It has a community behind it, which will cause growth of Chicken. You dabble a little in every GUI out there, and you have nothing. Binding Qt takes too much time, Qt is a big dependency for those who prefer Gnomish desktops, Qt is too large for some systems. Qt is also quite slow. Qt is proprietary. What about Gtk+? José Romildo ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Binding Qt takes too much time, Qt is a big dependency for those who prefer Gnomish desktops, Qt is too large for some systems. Qt is also quite slow. Qt is proprietary. What about Gtk+? Not fully ported to Mac OS X, not really suitable for embedded systems, etc. (All those toolkits are good, don't get me wrong - but they are not universally usable on all platforms). cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
felix winkelmann wrote: Again, this shouldn't be the mother of all GUIs - just a basic layer to get work done with. Well, that's the thing though. You imagine your needs are simple, and so does the next guy, and so does the next guy. But you don't have the same needs, and pretty soon you've reinvented the mother of all GUIs. With all the bugs. What's magical about your basic layer that it won't succumb to Second System Syndrome? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
I don't need a super GUI. I just want some portable means of creating basic, simple GUIs (call them toys, if you want). Add a basic 2D graphics API, you can then create all the widgets in the world. I agree with this point. The bare minimum is a framebuffer with some drawing routines; I've done some of that already. Then it's possible to build all the widgets in Scheme. I got interested in OpenGL to avoid having to write the rest of the 2D drawing routines right now, and also because I realize that UIs in general are all going 3D and why be permanently stuck in the past? I can do 2D just as well with OpenGL and be prepared to add 3D features as the desire arises. But not on every device, so I will need to come up with a 2D API that works either way. And then to integrate into existing windowing systems, it'd be nice to be able use the same low-level 2D routines either on SDL or the raw framebuffer. It's suicide. Bind Qt. It doesn't matter if Qt is not all things to all people. It has a community behind it, which will cause growth of Chicken. You dabble a little in every GUI out there, and you have nothing. And this one too. :-) I want to create custom widgets, but I will be busy building my idea of an ultimate GUI for a long time, and I think there may be a need in the meantime for a stopgap measure to rapidly build conventional apps like the everyday kind that already exist. Binding Qt takes too much time, Qt is a big dependency for those who prefer Gnomish desktops, Qt is too large for some systems. Qt is also quite slow. Qt is proprietary. It runs on high-end phones and PDAs. It is not terribly proprietary anymore; it's free for free software. It is somewhat portable. The code for a typical app is pretty elegant, as much as a C++ programmer could expect. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/5/07, Brandon J. Van Every [EMAIL PROTECTED] wrote: felix winkelmann wrote: Again, this shouldn't be the mother of all GUIs - just a basic layer to get work done with. Well, that's the thing though. You imagine your needs are simple, and so does the next guy, and so does the next guy. But you don't have the same needs, and pretty soon you've reinvented the mother of all GUIs. With all the bugs. What's magical about your basic layer that it won't succumb to Second System Syndrome? That it's just that: basic. Most people just need basic things. And too many attempts at finding the right one have failed, because there is no right one. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
I'm considering the pros and cons of this, but I am with Felix in the belief that a simple, Schemish basic GUI layer design is desirable. It shouldn't require Qt or Gtk, which are both on the heavy end of GUI toolkits. Instead it should provide a layer that works on top of whatever GUI tools are available, with a minimum of back-end glue code. I'm fairly new to Chicken development (though not to Scheme) and I'm making an effort to gain experience in designing extensions and tinkering with the engine. My aim is to gain enough experience to be able to contribute to the production of a GUI of this kind. ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
felix winkelmann wrote: On 2/5/07, Brandon J. Van Every [EMAIL PROTECTED] wrote: And why would you prefer a little bit of every toolkit, as opposed to picking 1 toolkit and doing a good job wrapping all its functionality? If you target every toolkit out there, then it'll be capable of very little. Too trivial for more than toys. Dependencies are the problem. By allowing multiple configurations you will serve a greater number of users and platforms. You serve a greater number of platforms. The number of *users* you get, depends on how many people find the library useful. You could be better off just taking a % of a major library community, such as WxWidgets or Qt. Also, wrapping a complete toolkit you just end up with a huge glob of wrapper code that is constantly out of date as you try to cover all corners (even the quickly changing ones, i.e. more obscure pieces). If you write your own huge GUI project from scratch, you still have a huge glob of code that is constantly out of date. The question is whether you have a large number of people working on the problem. Leveraging an entire mature community can be worth more here. You may be better off improving Chicken's binding technologies. If you cover lotsa different GUIs, you still have a lot of code going out of date, chasing all the different projects around. I don't see how you avoid things going out of date, if you have massive numbers of external dependencies. Doesn't matter if those dependencies are broad or deep. I don't need a super GUI. I just want some portable means of creating basic, simple GUIs (call them toys, if you want). Has any GUI toolkit ever aspired to the minimalism you have in mind? Add a basic 2D graphics API, you can then create all the widgets in the world. Which does most people no good, as nothing will be standard for a long time. Binding Qt takes too much time, Qt is a big dependency for those who prefer Gnomish desktops, Qt is too large for some systems. Qt is also quite slow. Qt is proprietary. Bind something else then. I didn't say I cared about Qt. What I've found out so far: the one true C/C++ (native) gui toolkit does not exist, so I'd rather not bet a bunch of work on wxWidgets or Qt. It may not exist for a good reason. Like, people don't want simple, minimalist GUI toolkits. They want full-featured ones that they can write every piece of enterprise software they have in mind. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/5/07, Shawn Rutledge [EMAIL PROTECTED] wrote: Binding Qt takes too much time, Qt is a big dependency for those who prefer Gnomish desktops, Qt is too large for some systems. Qt is also quite slow. Qt is proprietary. It runs on high-end phones and PDAs. It is not terribly proprietary anymore; it's free for free software. It is somewhat portable. The code for a typical app is pretty elegant, as much as a C++ programmer could expect. Qtopia 4 runs like molasses on the systems we use here (200Mhz ARM and MIPS without FPU), the new graphics engine (Arthur) is pretty demanding. Ok, that are pretty basic systems by todays standards. On the other hand, what about a 68k-based uCLinux system without MMU? Qt is the highest quality toolkit available, yet its overkill for most things. It does have good marketing, though... cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Tony Sidaway wrote: I'm considering the pros and cons of this, but I am with Felix in the belief that a simple, Schemish basic GUI layer design is desirable. It shouldn't require Qt or Gtk, which are both on the heavy end of GUI toolkits. Instead it should provide a layer that works on top of whatever GUI tools are available, with a minimum of back-end glue code. If it's really going to be *that* simple, I don't see why we're discussing Qt or Gtk or WxWidgets as backends. Just write straight to native OS window systems, the lowest system level. Basically, a from scratch project. Well at least I've accomplished one thing. I've touched off a GUI storm. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
felix winkelmann wrote: Qt is the highest quality toolkit available, yet its overkill for most things. It does have good marketing, though... You're big on embedding. Does any GUI toolkit not suck at embedding? In any language? Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/5/07, Brandon J. Van Every [EMAIL PROTECTED] wrote: If you write your own huge GUI project from scratch, you still have a huge glob of code that is constantly out of date. The question is whether you have a large number of people working on the problem. Leveraging an entire mature community can be worth more here. You may be better off improving Chicken's binding technologies. I don't want to write a complete GUI toolkit: just a common Scheme API *over* some native toolkits. Nothing big, nothing huge. If you cover lotsa different GUIs, you still have a lot of code going out of date, chasing all the different projects around. I don't see how you avoid things going out of date, if you have massive numbers of external dependencies. Doesn't matter if those dependencies are broad or deep. Not all at once: just implementations for a common subset - we build whatever is available on the user's system or what she choses. I don't need a super GUI. I just want some portable means of creating basic, simple GUIs (call them toys, if you want). Has any GUI toolkit ever aspired to the minimalism you have in mind? No. I've looked long and hard and didn't find it. It's like looking for the ideal language implementation. Add a basic 2D graphics API, you can then create all the widgets in the world. Which does most people no good, as nothing will be standard for a long time. That's intended for the point when the standard widget set (which is likely to be small) isn't enough. Binding Qt takes too much time, Qt is a big dependency for those who prefer Gnomish desktops, Qt is too large for some systems. Qt is also quite slow. Qt is proprietary. Bind something else then. I didn't say I cared about Qt. I haven't found the one ideal 'kit. That's the whole problem. What I've found out so far: the one true C/C++ (native) gui toolkit does not exist, so I'd rather not bet a bunch of work on wxWidgets or Qt. It may not exist for a good reason. Like, people don't want simple, minimalist GUI toolkits. They want full-featured ones that they can write every piece of enterprise software they have in mind. I've come to the belief that this is wrong, and that many many have made the mistake of doing it right once and for all and ending up with something that does too much, but not good enough. If I had a simple, GUI toolkit running on Linux, OS X and Windows, binds native widgets, has a simple basic graphics API (OpenGL would be ideal), is smaller than 1-2 MB, provides text-editing (multiline), buttons, images, frames, checkboxes, and a couple more widgets, simple menus, then I'd be happy. FLTK could be the one, but is a bit flaky and why should a Linux user that has Gtk installed hunt down the proper FLTK version? There are weird GUIs like widestudio (which I don't understand) or the various SDL based ones (Guichan, etc. which are all quite immature). I simply don't believe that there is the perect one. There is no perfect software. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/5/07, Brandon J. Van Every [EMAIL PROTECTED] wrote: felix winkelmann wrote: Qt is the highest quality toolkit available, yet its overkill for most things. It does have good marketing, though... You're big on embedding. Does any GUI toolkit not suck at embedding? In any language? Nano-X is pretty good, but very minimalistic. Old Qt versions are currently the best choice (3.3). I've used SDL, too. There is a FLTK version that can be run on top of nano-X (using a faked Xlib), but it's pretty much slapped together. That's mostly all there is. But on these systems you can pick whatever you prefer and build anyway you like. The situation is different on desktop machines, where you don't want to hassle the user and support what he/she has available and/or installed. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Hi all, [snip] If I had a simple, GUI toolkit running on Linux, OS X and Windows, binds native widgets, has a simple basic graphics API (OpenGL would be ideal), is smaller than 1-2 MB, provides text-editing (multiline), buttons, images, frames, checkboxes, and a couple more widgets, simple menus, then I'd be happy. About the API. You'd like to go opengl-style, right (stateful or stateless ?) ? What about a xhtml/css/javascript style ? I mean, of course, everything in Scheme but with content/presentation/logic separated... Otherwise, it would be the classical event-based (with callbacks) mechanism ? I wonder what other means could be used. Maybe some kind of message passing instead of function calling ? (any idea of gui toolkit for erlang ?) Or some kind of spreadcheet-like (I think to phooey in haskell or cello in common lisp). Sorry, I understand the goal is to be practical and cheap for the time and effort of the community :) Cheers, thu ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
felix winkelmann wrote: If I had a simple, GUI toolkit running on Linux, OS X and Windows, binds native widgets, Why native widgets? What's important about that? As a game developer, this fetish has been very difficult for me to relate to. Games all want to distinguish how they look, not look like the same game. I can understand having menus with roughly the same stuff in roughly the same places on every OS. But people have been doing that for quite a number of years now, it's not an aesthetic problem. In fact, what I've typically wanted out of the big bloated GUI toolkits, and where at last count they all failed, is I wanted my widgets skinnable. Or even shapeable. But accountants don't need that sort of thing, so even at the OS level, the support for it wasn't so good. Granted I wanted things to run on Windows 2000 and that's getting long in the tooth to worry about anymore. But I'm still using Windows 2000. Microsoft has added zero value since then, so why move on? has a simple basic graphics API (OpenGL would be ideal), I fear for OpenGL on Windows. is smaller than 1-2 MB, provides text-editing (multiline), buttons, images, frames, checkboxes, and a couple more widgets, simple menus, then I'd be happy. FLTK could be the one, but is a bit flaky And there's actually something rock solid out there? Chicken doesn't even have automated nightly builds or testing suites. It has bugs especially is not a valid excuse in open source. You can contribute bugfixes and feature improvements to other communities. It's a lot more sane than NIH. There are reasons to decline other people's software though. When I look at OpenGL windowing toolkits, I decline the ones written in C++, and the ones that don't have active communities. There's just no value in 1..3 guys barely getting anything done, almost never making releases, and having a mailing list where crickets chirp. CPW and GLFW both have poachable C starter code, but that's about all. I'm not going to go try to save their communities. The leadership and energy simply isn't there. We're better off building a community from scratch here. In contrast, WxWidgets, Gtk+, and Qt all have vast communities, far outstripping the size of our little Chicken enclave. We're small time, small potatoes, and pretty immature compared to them. It would be great to tap into their resources. Unfortunately, they may be ossified in their political goals. I wouldn't bank on smaller is better getting much play in those circles. FLTK could be have the right focus on size. But it is written in the wrong language, C++. You could work on Chicken's C++ capabilities, using FLTK as the test target. and why should a Linux user that has Gtk installed hunt down the proper FLTK version? Why should they bother to install Chicken or CMake? It's a lazy argument for lazy people. I simply don't believe that there is the perect one. There is no perfect software. That doesn't imply that everything should be your own software. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/5/07, minh thu [EMAIL PROTECTED] wrote: About the API. You'd like to go opengl-style, right (stateful or stateless ?) ? What about a xhtml/css/javascript style ? I mean, of course, everything in Scheme but with content/presentation/logic separated... Otherwise, it would be the classical event-based (with callbacks) mechanism ? I wonder what other means could be used. I'd go with classical event-based. We have continuations and closures to make it less painful. Maybe some kind of message passing instead of function calling ? (any idea of gui toolkit for erlang ?) Or some kind of spreadcheet-like (I think to phooey in haskell or cello in common lisp). Sorry, I understand the goal is to be practical and cheap for the time and effort of the community :) But your ideas are good! At some stage a higher-level approach would be needed, but I'm still thinking about the basics. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Brandon J. Van Every scripsit: Well, that's the thing though. You imagine your needs are simple, and so does the next guy, and so does the next guy. But you don't have the same needs, and pretty soon you've reinvented the mother of all GUIs. With all the bugs. What's magical about your basic layer that it won't succumb to Second System Syndrome? It's worse than that. Open-source developers consciously or unconsciously are drawn to projects with an active bug-fixing community, which is facilitated by large systems with thousands of bugs. As the bugs get fixed, new features are installed, which creates more bugs, which creates more buzz. And so on. If you want a small stable toolkit, use Tk. It's not sexy and earlier versions didn't have native LF, but it works. Best yet, we already have an egg for it. -- John Cowan [EMAIL PROTECTED] http://ccil.org/~cowan I must confess that I have very little notion of what [s. 4 of the British Trade Marks Act, 1938] is intended to convey, and particularly the sentence of 253 words, as I make them, which constitutes sub-section 1. I doubt if the entire statute book could be successfully searched for a sentence of equal length which is of more fuliginous obscurity. --MacKinnon LJ, 1940 ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
John Cowan wrote: [...] If you want a small stable toolkit, use Tk. It's not sexy and earlier versions didn't have native LF, but it works. Best yet, we already have an egg for it. [...] Hello, I vote against Tk, because in my humble opinion * Tk is not a small toolkit and it bloats your applications even more because you need a second scripting runtime -- Tcl or Perl -- to use it. I find that only acceptable if I'm programming in Tcl or Perl anyway. * Tk is not very stable -- some experience with Perl/Tk teaches me that it's extremely easy to produce segfaults and infinite hangs with seemingly correct Tk code for obscure reasons. * Tk is not very portable -- even screen coordinates for drawing in canvasses work differently on Windows and Unix implementations of Tk. * I don't like the idea of using the CHICKEN Tk egg for production code because a GUI library should not need to spawn a different language interpreter subprocess and control GUI interaction by reading and writing code to and from a pipe. That's like controlling a database by spawning an SQL shell and interacting with it using pipes. I don't think it's a clean approach. And of course its very inefficient too, especially given the fact that Tcl evaluates strings to strings all the time... cu, Thomas ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Thomas Christian Chust wrote: I vote against Tk, because in my humble opinion I vote against Tk, for all the aforementioned reasons, and an additional one: it is perceived as old crap. It will not attract people to the Chicken project. In fact, that kind of design is likely to drive people away. Cheers, Brandon Van Every ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 5, 2007, at 2:47 AM, felix winkelmann wrote: On 2/5/07, minh thu [EMAIL PROTECTED] wrote: About the API. You'd like to go opengl-style, right (stateful or stateless ?) ? What about a xhtml/css/javascript style ? I mean, of course, everything in Scheme but with content/presentation/logic separated... Otherwise, it would be the classical event-based (with callbacks) mechanism ? I wonder what other means could be used. I'd go with classical event-based. We have continuations and closures to make it less painful. Maybe some kind of message passing instead of function calling ? (any idea of gui toolkit for erlang ?) Or some kind of spreadcheet-like (I think to phooey in haskell or cello in common lisp). Sorry, I understand the goal is to be practical and cheap for the time and effort of the community :) But your ideas are good! At some stage a higher-level approach would be needed, but I'm still thinking about the basics. I do like Cells, but I am unsure if Tilton is still working on Cello. It seems dormant. A TinyCLOS Cells extension would be nice (so would ContextL but Cells might be more generally useful). Any use in following PLT's MrEd, MrLib Framework for Scheme GUI bindings? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Darwin) iEYEARECAAYFAkXH0o8ACgkQJJNoeGe+5O70/ACeJbx2v9Mb9G8THSojN0IBRXM4 XW8Anj/7YqeOlqDWT9A6osl6CMhIWaDF =Jxq9 -END PGP SIGNATURE- ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/5/07, Thomas Christian Chust [EMAIL PROTECTED] wrote: * Tk is not a small toolkit and it bloats your applications even more because you need a second scripting runtime -- Tcl or Perl -- to use it. I find that only acceptable if I'm programming in Tcl or Perl anyway. * Tk is not very stable -- some experience with Perl/Tk teaches me that it's extremely easy to produce segfaults and infinite hangs with seemingly correct Tk code for obscure reasons. * Tk is not very portable -- even screen coordinates for drawing in canvasses work differently on Windows and Unix implementations of Tk. * I don't like the idea of using the CHICKEN Tk egg for production code because a GUI library should not need to spawn a different language interpreter subprocess and control GUI interaction by reading and writing code to and from a pipe. * Tk integrates very badly on OS X * Tk is slow and speaking to it via pipes doesn't make it very suitable for, say, games That's not to say that Tk is bad as such - but properly not the right thing if you need native access. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/6/07, Kon Lovett [EMAIL PROTECTED] wrote: I do like Cells, but I am unsure if Tilton is still working on Cello. It seems dormant. A TinyCLOS Cells extension would be nice (so would ContextL but Cells might be more generally useful). I've never grokked cells. It's hard to figure out the facts from Tilton's lingo... Is there some documentation available? Any use in following PLT's MrEd, MrLib Framework for Scheme GUI bindings? It uses an old hacked version of wxWidgets. I'd prefer to stay away from that. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/4/07, felix winkelmann [EMAIL PROTECTED] wrote: I have a good deal of Qt experience, a bit of FLTK and generally not enough resources to create this on my own (surprise!). I also am unable to do any windows-related coding. Why not build on top of something like wxwidgets? -- Toby Butzon ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
On 2/5/07, Toby Butzon [EMAIL PROTECTED] wrote: On 2/4/07, felix winkelmann [EMAIL PROTECTED] wrote: I have a good deal of Qt experience, a bit of FLTK and generally not enough resources to create this on my own (surprise!). I also am unable to do any windows-related coding. Why not build on top of something like wxwidgets? wxWidgets would be another suitable backend. But wxWidgets itself is quite a massive thing, has bugs (depending the the platform) and is just one possible option. I tihnk by supporting multiple native toolkits, deployment and portability is actually simplified and improved. Every toolkit has i's own quirks, dependencies and bugs. By using what is available, we wouldn't force a particular library on the user, and users with specialized needs (easy deployment, game developers, embedded systems) can pick what they prefer. I agree if that means slightly more stressful maintenance and that's why I think our toolkit should be simple and small. Again, this shouldn't be the mother of all GUIs - just a basic layer to get work done with. cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
Re: [Chicken-users] cross-platform gui toolkit
Hello, I guess felix knows this, but let me remind people what I think. GUI toolkit is one of the most desirable components for me. I first tried to use GCJ compiled version of SWT, which has a simple API of JNI that can be called from chicken. However, something is weird with JNI and this approach doesn't work. The second trial is wrapping wxWidgets as wxchicken egg. I agree that wxWidgets is too huge and it's C++ based. Nevertheless, it's worth trying. I've done some coding and found that this is doable but it would take time to finish it. I'm not working on this recently, just because my recent interest is in building web applications, but I would be happy to continue the work if someone was interested and could help with it. Building an original toolkit can be an option, but I too don't code on windows. Thanks, Daishi On 2/5/07, felix winkelmann [EMAIL PROTECTED] wrote: Hi! Something that we desperately need, IMHO, is a cross-platform GUI toolkit. Several people have mentioned this at various times and for plain application-delivery beyond POSIX functionality some sort of GUI will likely to make chicken more usable. It should be easy, dumb, straightforward. Simple, traditional event-handling, a core set of easy-to-port widgets, a small and simple API. Backends to various existing gui toolkits (Gtk, Qt, FLTK, Win32(?)) should be supported using a greatest common divisor aproach. More funky abstractions can be built on top of that and eggs could provide more specialized widget sets, particular to a specific GUI backend. I have a good deal of Qt experience, a bit of FLTK and generally not enough resources to create this on my own (surprise!). I also am unable to do any windows-related coding. Would there be someone interested in taking this up or join me with such an undertaking? cheers, felix ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users ___ Chicken-users mailing list Chicken-users@nongnu.org http://lists.nongnu.org/mailman/listinfo/chicken-users
