Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: RebGUI or GLayout

From: moliad:gma:il at: 20-Dec-2007 1:21

wow! such passion... and Glayout is at the core of all the dilemma :-) I won't reply to single mails, cause there are too many, but here is my general (long) response: to Pekr (and onlookers ;-): -------- I'll start by saying that I'm not in any way under any sense of "attack". you and I are critical people and use strong words in our language. There is a term called perceived quality, which is what you do not feel with my stuff. Some of that is my own fault, I'll agree to that, but some of it also due to your ignorance of what I have done and what really is available. The fault I might give to you is about having written a few things which are not quite true. REBOL is not my life. like nick, its something I do within my life. Maybe you don't perceive that the fact these tools exist is not about trying to make REBOL better. REBOL allows me to pursue my own vision more quickly. yet I have decided to give back to the community some of the usefull code which has resulted from my work. its obvious that you never followed any of my development seriously, cause you'd know that my web site is updated at least 2 to 3 times a year. you would also know that it has moved and HAS been updated this spring, again. GLayout is also not my main programming venture. Its a necessary tool I use everytime I do an app, that's really all it is. I have stopped coding in general as a hobby after the devcon, for many personal reasons... some of which have led me to a burn-out, of which I am currently recuperating at home, playing music, composing mostly, helping me hunt a few deamons out of my soul. this said, elixir and remark development has continued a bit and is about to resume in much more vigor in a (very) short while. I have stopped actively developping GLayout, because it now is mature enough not to really need anything more in general for my useage of GUIs, and because of the community in general. Your mail was the perfect and penultimate example of what is wrong in the community IMHO. STEEL was one of the first attempts at gathering the community. I am the very first person to have believed in REBOL capabilities in PITL programming and strangely, many aspects of R3 which are not a binary limitation of the basic architecture, are ALREADY AVAILABLE within the STEEL toolset. And have been for a while. I'll explain these again, while on my web site its very clear, each section has an introduction, some stuff is not released, cause there is much effort in releasing things, and unless real demand, I've got other places to put energy these days: -STEEL: a set of tools, a web site. apis and apps or demos which help programmers and rebolers, in general. Originally setup as an effort to get people to get to work together adding to and fixing some of the stuff in REBOL, bad timing, my choice of licensing at the time, and the general culture around REBOL had prevented the idea to pick up. so I removed the concept of collaboration from steel. Its still there, really, I'd love to have a few people actively helping me out on adding new features to every api and tool, I have, but alas, everyone is busy with his own stuff I guess. REBOLers tend to be invetors and technophiles, so its in our nature to be our own chiefs. I have accepted this fact for a long time. -SLIM: managed library modules with explicit identification of api (lib exposing). versioning, multiple cascading path resolution (3 different setup possibilities, including one which needs none!), codependent libs, multiple load prevention, resource dir management, advanced indented and run time switcheable verbosity (per module), linking which retains ALL aspects of this architecture even if the concept of "current" dirs is completely different from app to libs, and more. -GLayout: an advanced VID extension which solves most but not all of the problems in VID, all integrated into one (large, I admit) library, including many nagging issues like per character keyboard trapping, non-focused cascading scroll-wheel events (similar to event/detect concept), a very capable layout engine which even prevents resizing in one single direction (vertical or horizontal) when none of the content of that window needs it. It has quite a few styles built in, but since its based on VID... come on, its so easy to make your own... From its onset, GLayout was never intended at being the largest style gallery. it was meant as a collection of enabling functions, technologies and tools, allowing people to leverage them and build up their own collections (which I am more than eager to put back in). Most if not all of Henrik's and Anton stuff can be merged within GLayout, and indeed, I have done some integration and its pretty easy. -Liquid: technologically capable implicit dataflow procedural core. it supports A Lot of features, several processing models merged into one single run-time polymorphable class, and is VERY simple to use, and scales better than any other rebol construct I have used before. I have systems that have 10000 nodes allocated and the system is still responsive, not even consuming 10MB of ram. it can scale to millions of nodes(but stretches rebol's capacity at this point). obviously, the fact that a single full screen view refresh takes longer to perform than to manage the average largish tree, wheighs heavily on any application in rebol, so for this reason, liquid was never optimised outside of the intrinsic optimisation which lazy computing offers, and frankly, so far, I have not needed more speed since the systems I do outperform view and AGG by several orders of magnitude. -GLOB(unreleased): Graphic Layered Objects. basically, R3 gobs in R2, implemented a year ago, and a public demo was shared here and on altme just before christmas (or was it the new year?). Implemented over the liquid core using AGG Draw, allowing us to program ANY individual or grouped AGG gfx as if they where Faces, including pixel-precise mouse-based detection, focus integrated to VID, linked to a feel object which has more high-level events like on-click, on-drag, or your host of on-down, on-up, etc events. in fact, GLOBS are more capable than gobs, as a single GLOB can contain several layers of graphics which can be interlinked to other globs dynamically which also have several layers. Each of these layers can be displayed individually or even separately, meaning that only a subset of each individual glob will be processed and displayed which can save A LOT of processing when its not needed. also, individual layers are not forced to be displayed in their internal order. liquidGL(unreleased publicly): a merge of GLayout and liquid which allow your dataflow systems to integrate to a gui seamlessly. also, obviously, since GLayout becomes driven by a dataflow system itself, it can interlink within itself. This is augmented by the fact that the handling of such things is done directly within the VID dialect. so setting a text field to reflect a field is as easy as adding two words to your dialect: [myfield: field vtext attach myfield] remark: a VERY capable static web site building engine, which after having used MS can indeed claim to be better designed, in some aspects. Its management, is GUI driven, merges http and dialecting, uses an html based dialect (using <>, not the rebol [] brackets), and allows TRUE code and visuals separation. it can even do the whole recursive ftp mirroring to your server in one click. actually, you can use remark to create parsed file management in non html documents too, like graham has been doing to fix javascript issues just before sending them off to a server. You could use remark to manage ANY ascii file and provide functional style data parsing to it. capabilities for handling multiple document formats is there(converting makedoc on the fly for example). work has started, integrating it within cheyenne as a module, making it cgi capabale too, and rebuilding the whole kernel from scratch (now 10 times faster, using managed parse) but time constraints mean, such "FUN" projects stop and go. if any can pay me full time to bring these technologies to par, they would be available within days/weeks in a production stable capacity. R3 addresses other issues, like data hidding, 64bit stuff, and many little fixes whcih will make life easier for PITL dev. easier binary linking and better internal graphics. mostly, these are capacity issues, but for me, R3 is a moot point, as frankly, with ladislav's powertools library and the tests I have done using external libs in various ways, I can already do all applications I want, a part from the visual internal limitations of view, which hides too much of the OS from us, or doesn't provide enough low-level Abstraction to it. may I note that ALL of this is available NOW, has been used already for years in some circumstances, is being used by clients, some even running these things within a web-based application (browser plugin) speaking asyncronously with MULTIPLE concurrent http servers AND an internal XML web service, syncing stuff like altme in a multi-user real-time environment, which might I add I was able to make completely invisible by using stylesheets... something which would not have been possible with Rebgui AFAIK. so, pekr... where is the hype, the promises, may I ask ? can rebgui do all of the advanced stuff GLayout can. no. This was all demonstrated at the devcon, and in fact, Carl, was quite impressed by it and we discussed about it. No Hype, just already available added value, which I am willing to support, on this mailing list. In fact, if I had given support for it *here* each time, I probably would have a lot more users, cause it would have had public visibility. and some newbies would like the quick added value which GLayout offers, dead easy install too. you can even make a simple validation in your code and install all prerequisites for glayout (including the proper version) to download it directly from my GLayout demo, has it within, just to make it a one line download and run. also, where in my reply to Giuseppe, did I ever say that Rebgui was bad. I said that GLayout had a better layout algorythm, but then, simply went on to state many of what it ALREADY adds to VID. nothing against Rebgui was said. in fact, I was hoping someone from the Rebgui would step up and give a similar heads up on what value it has over VID, which basically was all Giuseppe was asking for. then, can I ask, when did I ever say that GLASS (v2) was available, downloadable, and when did I promise it would be done. frankly, I might have given indications that some prototypes had been made, many tests, but I've never made a web site showing off GLASS a part for the 5 year old GLayout precursor I had done. Some of GLASS philosophy is within Glayout, some is now within Elixir, as it has its own 100% independant gadget engine core (based on globs) and indeed, there are yet other tests into this research on building 100% dataflow driven gadgets, but still, GLASS although designed and planned, has never been a product. it is something else, something completely independent from GLayout. GLayout will not be better or worse for the existence of GLASS. also, you say nothing has ever been shown... well, you should have come to the devcon, cause while in my demo, I did hear a few gasps when showing my stuff, not the least elixir which is a hierarchical, graph driven Programming interface. 300kb of REBOL code when linked, AGG interface trough globs and glayout, "antidote" my own rebol interpreter for preventing any side effects, and much more. my work is commercial in nature, and my hobby is builing APIs, not apps. do you realise how many tookits I currently maintain, and DO support? Sorry to say, but I have been delivering on my toolsets for the last year. any inquiries are answered, support is always one email away. I have a (rebol) user which started switching his medical dentistry record and scheduling app to GLayout and its much more appealing now. I, like you, use REBOL, but I feel no religious zeal towards it. REBOL to me is an empowering tool, simply cause its the most productive environment in computing today . I am one of the lucky few who has done so commercially, but do not think that my goal is to try and have a claim for fame in the community. I give back stuff I do for myself and clients, FREE. I am not RT, no one has given me a dime form GLayout, liquid and remark, et al. And for the record, it has been said to me that Rebgui has its own set of issues. I don't want to do laundering here, but do not promote it as a perfect godsend... nothing is perfect, not GLayout, not RebGui, and not even R3 will be. yet, thanks for the frank appraisal of what you feel GLayout and steel are. If you do no yet "get" it, then its obvious, I must continue doing more hype... about what it already is and provides ;-) TO GIUSEPPE: ------- thank you for the genuine and honest interest. I will upload the latest version of all of my stuff for you on tomorrow, and I will add liquidGL and glob too. I think doing all of the support on this list will be the best way to raise awareness. This should have been done every time a user wanted (or has) used it, in order to show some "activity" about it... now I know. Your idea about a wikibook is excellent. I would contribute to it, if you can get it setup and are willing to add to it yourself while you get to grips with GLayout (often the best time to document stuff, since oldies loose the sense of what is not obvious). Hey, if others want to join too, probably brian from would too. Glayout has an internal function allowing to snapshot a GUI (while its running), crop it and save it out without need to resort to using an external application... this makes documentation of any GLayout driven application or tutorial dead easy! We can also use remark, which is infact much like a wiki dilalect concept, but extensible and scriptable (outside of the page). Pages contain only content, and all the page and site stuff is added on the fly, even the menus are programatic. I could send you notes on how we can collaborate on this, if you wish. The Glayout demo (quicktour) on GLayout's web site: you will see the GLayout demo app. try it out, it should give you a quick tour of some of what is inside. (not liquidGL enabled though). TO ALL: ------ thanks to all of you for rooting for me in my absence hehe. It actually does me a good deal of good to my kharma today, to have read all these good words oriented in my direction. Darn someone even labeled me one of the guru <gasp!> hehe. thanks, very much. Today I feel like I've been given a measure of recognition, and during my resting period, nothing could be better for my (mental) healing. CONCLUSION: ------ many of the issues which Graham had encountered a while back when he had attempted to convert an application to GLayout (using an older version of GLayout) have been integrated as per his feedback (later, when I had time). And a lot of stuff lies within, unexploited by the masses. There ARE bugs and limitations, obviously, but mostly on the more advanced and specific stuff. Some stuff about the visuals have come up, many rooting for, and some rooting against. this can be changed within your apps, and if there is usage, I could add my old real-time external stylesheet (aka skins) switching code back in. I've not had use for it myself. There are no promises, just a tool which is there, used less than it should. One thing remains, if there where more people at least willing to give it a try for real, then issues would be uncovered and solved. I don't even mind making a clean up of some stuff... but is there any point when no one is really asking or waiting for it? its all working for me, so why bother... I'm not being payed for putting 4 hours a day on GLayout, so I can't, even less if that time spent will be as usefull as throwing a rock in water. I've got kids to feed, and a life to live! have fun! -MAx