| # | User | Message | Date |
| 7402 | Cyphre | I succesfully 'overloaded' some mezz functions in R3 in the RMA hostkit. See the inclusion of %rma-patches.r file in src\tools\make-host-init.r in the RMA host-kit release. So it is possible to do some fixes that way.(of course not every part can be tweaked such way) | 31-Jan 21:02 |
| 7401 | BrianH | Hopefully this patch file will serve as an example for others who want to do similar patching. | 31-Jan 17:33 |
| 7400 | BrianH | I have a list of fixes and improvements in mind, so I'll see if there's some time by the end of this week to put together a patch file. I'm sorry that I haven't documented the module system well enough to make it practical for anyone other than me to patch it at runtime. Improving its documentation is on my todo list, though I've been a bit busy at work lately. | 31-Jan 17:19 |
| 7399 | Andreas | But I guess we could at least try, if you have a particular hotfix in mind. | 31-Jan 17:09 |
| 7398 | Andreas | I don't have the loading intricacies in enough detail in my head right now to reason about this sensibly. | 31-Jan 17:09 |
| 7397 | BrianH | %rebol.r still works, and it loads pretty early on in the boot process. The host init loads earlier. | 31-Jan 17:08 |
| 7396 | BrianH | I load a patch file in %rebol.r right now, for my work use of R3. If I was doing my own host builds then I would put a reference to the patch file early on in the host-init code. | 31-Jan 17:07 |
| 7395 | Andreas | (For this particular RESOLVE issue.) | 31-Jan 17:05 |
| 7394 | Andreas | I think you mentioned somewhere, that replacing affected functions from user.r is not possible. | 31-Jan 17:05 |
| 7393 | Andreas | When would you load that patch file? | 31-Jan 17:04 |
| 7392 | BrianH | We can't hot-patch functions in R3 for security reasons, but we can replace them completely with fixed versions. | 31-Jan 17:04 |
| 7391 | BrianH | If I make a patch file that fixes the mezz problems, including the module-related ones, will that work? For now (when the module list isn't really protected yet) this is doable... | 31-Jan 17:01 |
| 7390 | Andreas | (See %src/tools/make-host-{init,ext}.r for details.) | 31-Jan 16:54 |
| 7389 | Andreas | Some of them are (mostly the bundled extension related ones), most of them are not. | 31-Jan 16:50 |
| 7388 | BrianH | Interesting. I thought that the mezzanines were loaded by the host, not built into r3lib. | 31-Jan 16:46 |
| 7387 | Andreas | Nope, the current hostkit build does not take mezz changes into account in any way. | 31-Jan 16:45 |
| 7386 | BrianH | Nope, you just can't build a single binary with a statically linked r3lib. You can build a host kit exe with a dynamically linked r3lib with any mezz changes you want. | 31-Jan 16:45 |
| 7385 | Andreas | Afaik, we (the community, that includes Saphirion) cannot build binaries incorporating mezzanine changes with the current hostkit. | 31-Jan 16:43 |
| 7384 | BrianH | The module system can be fixed to not use RESOLVE/extend/only, and a few months ago I submitted such a fix to Saphiron for them to include in their next host code release, along with other mezzanine fixes. I'm just waiting for them to post another release. In the meanwhile, in my own module code that does exports I do the exports explicitly in the module code itself instead of using the EXPORT keyword or the Exports header. | 31-Jan 16:41 |
| 7383 | Pekr | We should probably buy a radio, and contact Carl on Mendoradio :-) | 31-Jan 15:21 |
| 7382 | Jerry | I can assure you that there is a bug in Resolve. | 31-Jan 14:52 |
| 7381 | Andreas | Basically, everywhere you use IMPORT you could be affected by this bug. | 31-Jan 14:36 |
| 7380 | Andreas | One nasty crash seems to be located in RESOLVE (cc#1865), which basically makes almost all module-system related stuff unstable/crashy. | 31-Jan 14:32 |
| 7379 | PeterWood | True. | 31-Jan 14:12 |
| 7378 | Oldes | Sadly, debugging does not help if nobody is interested. | 31-Jan 14:09 |
| 7377 | PeterWood | Sadly, it doesn't help with debugging. | 31-Jan 14:09 |
| 7376 | Oldes | I'm quite used to have several consoles opened which I use for multiple purposes and do not close them after each finished script. So I'm more affected by these possible GC bugs in R3. | 31-Jan 14:08 |
| 7375 | PeterWood | I had a couple of crashes that went away when I set trace on ...they were both on OS X and I think are related to memory issues. They are still open in CureCode. | 31-Jan 14:08 |
| 7374 | Oldes | I don't know... it was after some heavy real job made in console. I'm using R2 instead.. it's a little bit slower, but stable. | 31-Jan 14:06 |
| 7373 | PeterWood | Does it still crash with trace set on ? | 31-Jan 14:03 |
| 7372 | Oldes | I can confirm I've seen such a strange crash as well without any graphic involved. | 31-Jan 13:48 |
| 7371 | Cyphre | There is definitely 'something' in the R3 Core that crashes the interpreter. At the moment it is very hard to track it without the access to the sources or having the debug release of the R3 library. (ie. I was able to trace the crash using the debug release of hostkit exe but the trace ended in the 'hidden' dll part so the hostkit code seems to be most probably out of the game here) IMO it has nothing to with the graphics part(unless there are 2 separate bugs ;)) as I was able to crash R3 when writing non graphical script as well. The crash is very hard to reproduce as it occurs only with specific form of the executed script. If you change some line or even order of words etc. the script works just fine. It looks to me either some GC or other memory allocation leak issue and have suspicion it have something to do with the map! datatype (but this is just my feeling). | 31-Jan 12:52 |
| 7370 | Pekr | Graham - there simply might be errors related to R3 Core, not View core, which are fixable only by Carl. I think that Carl could at least fix those eventual show stoppers, to allow others to continue with R3 usage .... | 31-Jan 9:12 |
| 7369 | Henrik | GrahamC, I think the issue here is that the bug can't be found unless Carl provides a debugging version of R3, so we can find where the bug occurs, whether it's in the host kit or the core. I can't be sure as it's something that was discussed last over 6 months ago. | 31-Jan 9:12 |
| 7368 | Rebolek | R3GUI is not abandonned, but only required bugfixes will be done. If the situanion with R3 will improve, development will continue. | 31-Jan 9:03 |
| 7367 | GrahamC | And the error lies in ... ? | 30-Jan 22:45 |
| 7366 | Henrik | I had mentioned earlier that it would crash due to complex layouts, but this is not the case. The layouts can be very simple. For example this one: 1. run graphical version of r3.exe 2. load following R3GUI release from web: do http://www.rm-asset.com/code/downloads/files/r3-gui.r3 3. execute this simple layout example: view [tab-box ["tab1" [] "tab2" [] "tab3" [] "tab4" [] "tab5" []]] | 30-Jan 19:50 |
| 7365 | GrahamC | What are the things blocking progress? | 30-Jan 19:34 |
| 7364 | Henrik | But it sure would help, if Carl just started again. | 30-Jan 19:19 |
| 7363 | Henrik | That didn't come out quite right. The R3GUI is needed for an inventory application, so development will continue for it. | 30-Jan 19:19 |
| 7362 | GrahamC | Or, waiting to see if Carl can fix show stoppers? | 30-Jan 18:45 |
| 7361 | GrahamC | Robert says not spending time on R3GUI .. so is it now dead? | 30-Jan 18:44 |
| 7360 | Robert | Yep. We do it in an non-intrusive way, so the things are decoupled from style development. | 17-Dec 16:03 |
| 7359 | Pekr | well, skinning work is also dependant upon material systsem, etc., which was not done, last time I checked? Is it still so? | 17-Dec 15:57 |
| 7358 | Henrik | It'll be a while, before I'm available to do any skinning work. | 17-Dec 15:36 |
| 7357 | Pekr | Screenshot of the UI? Your last Twitter message towards the gui was related to creating new skin? I expect it was not high priority on your list though? | 17-Dec 15:21 |
| 7356 | TomBon | looking for solution to create a very fine grained heapmap (500X100) elements. the only solution for this resolution I have tested is pixelbased so far. a gob apprach would have many advantages but think it's will overload R3. | 17-Dec 13:23 |
| 7355 | Robert | Than you can color, vary line thick-ness etc. to indicate different information. | 17-Dec 13:23 |
| 7354 | Robert | The number of levels depend on the stuff you want to visualize. IMO for quite complex real-life situations you have about 7 levels. | 17-Dec 13:22 |
| 7353 | TomBon | ok, organigram... thought something like this -> http://www.mathworks.com/matlabcentral/fx_files/24253/1/heatmap.png | 17-Dec 13:21 |
| 7352 | TomBon | ahh, ok grid/cell approach. how many containers in avarage do you create for a big headmap? running fluent? | 17-Dec 13:19 |
| 7351 | Robert | It generates pictures like this: http://www.mindtree.com/node/657 | 17-Dec 13:18 |
| 7350 | Robert | We will, screenshot mode not yet working. It's a nested container structure and each container either layouts left-right or top-down in 1,2,3, ... lines / rows. | 17-Dec 13:16 |
| 7349 | TomBon | robert, can you post a screenshot from a sample headmap? nested layout means you are arranging small gobs as grid and color them or is it a pixelbased image created on the fly? | 17-Dec 13:14 |
| 7348 | Robert | jsut a short update: We build our first real-life R3-GUI based tool. It's a little thing but needed in a lot of companies. It's a tool you can interactively create things like heat-maps with. Heat-maps for how your IT system landscape looks like, organizational things etc. It's a nested layout created with color-mapping for visualization. | 17-Dec 11:59 |
| 7347 | GrahamC | the problem is that i may not see any benefit until I swtich a few 100 windows across | 16-Dec 9:52 |
| 7346 | Endo | You may try to put each windows into separate objects to make all the set-words are local. Then set them none manually when the window closed then call recycle. This may work? | 16-Dec 9:37 |
| 7345 | GrahamC | just close them ... and let rebol do GC on them | 16-Dec 9:18 |
| 7344 | Henrik | do you destroy one when leaving it? | 16-Dec 9:16 |
| 7343 | GrahamC | most of them are ... | 16-Dec 9:15 |
| 7342 | Henrik | if you have that many, it's probably a good idea to build each screen on the fly, rather than keeping them all in memory. | 16-Dec 9:09 |
| 7341 | GrahamC | You wouldn't see issues with so few windows | 16-Dec 9:07 |
| 7340 | Henrik | no, the app we build has about 12-15 windows, and we are using a different branch of RebGUI with our own fixes. | 16-Dec 9:06 |
| 7339 | GrahamC | do you have any such issues as i experience? | 16-Dec 9:04 |
| 7338 | Henrik | Saphirion's main app is built in R2, and is a very large project, so the issue is currently "just" frustrating. Some R3 apps are being built, though. | 16-Dec 9:02 |
| 7337 | GrahamC | Must be very frustrating ... and dangerous to base a business on such a situation | 16-Dec 9:00 |
| 7336 | Henrik | he has not responded on the bug at all. | 16-Dec 8:58 |
| 7335 | GrahamC | Has Carl promised to fix it? | 16-Dec 8:58 |
| 7334 | Henrik | it's not easy to do stress testing, due to a specific bug not yet fixed by Carl, which prevents the creation of complex layouts without crashes. | 16-Dec 8:57 |
| 7333 | GrahamC | I have a RebGUI application of some hundreds of screens and sadly it is not very brisk these days presumably due to GC occurring at inconvenient times, or just using too much ram. Any stress testing down with R3GUI with hundreds to screens? | 16-Dec 8:56 |
| 7332 | GrahamC | How goes the GUI? | 16-Dec 8:54 |
| 7331 | Ladislav | "So the GUI we can see in screenshots is modified RebGUI?" - yes | 12-Oct 11:52 |
| 7330 | Pekr | So the GUI we can see in screenshots is modified RebGUI? Looks decent enough. Similar skin would be nice tohave for R3 too .... | 12-Oct 11:50 |
| 7329 | Ladislav | Rather it can be called a "Performace pricing" program, i.e. a program implementing a performance pricing methodology. | 12-Oct 11:44 |
| 7328 | Ladislav | BTW, it is not a "plannig app" | 12-Oct 11:40 |
| 7327 | Ladislav | No, NLPP 2.0 is already being tested, and adjusted (finishing touches), in R2 | 12-Oct 11:39 |
| 7326 | Pekr | Will your planning app (which abbreviation I forgot - NNLP?) version 2 be done in R3? | 12-Oct 11:38 |
| 7325 | Pekr | I know ... | 12-Oct 11:37 |
| 7324 | Ladislav | ...And, R3GUI is not in limbo, it is being developed | 12-Oct 11:32 |
| 7323 | Pekr | No, not a musical request program, just whole REBOL ecosystem being a hilarious parody .... | 12-Oct 11:30 |
| 7322 | Robert | and: Than you need to take action and change it. It's not a "musical request programm" where you want something and it will happen. | 12-Oct 11:27 |
| 7321 | Ladislav | "we just did not want to have many GUIs available" - that is pure theory. Currently, R3GUI is the only available alternative working with the present interpreter version. | 12-Oct 11:25 |
| 7320 | Pekr | ah, so it might be just a separate package,like RebGUI is to VID ... yes, that's possible too ... we just did not want to have many GUIs available. But R3 GUI is in limbo anyway, so .... | 12-Oct 11:04 |
| 7319 | Robert | Exactly. | 12-Oct 10:57 |
| 7318 | Henrik | That would depend if Carl approves it, and AFAIK he has not looked at any of the changes yet. However, it won't affect the development of the R3 GUI, whether he approves it or not. It will still be made. | 12-Oct 10:55 |
| 7317 | Pekr | hmm, that makes R3 GUI a private, mostly a closed effort. The only question which remains now is - once R3 development is re-established, is R3 GUI becoming part of official distribution, or not? What's Carl's take on that? :-) | 12-Oct 10:47 |
| 7316 | Robert | "to give it a try once time permits" - It didn't in the past, so high chances are that it won't in the future too. Further it might be 1-2 persons. I take the risk of loosing those... | 12-Oct 10:24 |
| 7315 | Ladislav | ;-p | 12-Oct 10:23 |
| 7314 | Ladislav | That are not the same excuses. For core, the excuses are, that Carl is not developing. For R3 GUI, the excuses are that we *are* developing. | 12-Oct 10:23 |
| 7313 | Pekr | Ladislav - those might be just the same "excuses" as with R3 ... some ppl claimed, that they are not using R3, as it is not known, if Carl will develop it any further ... while Carl stated his intention to do so ... | 12-Oct 9:04 |
| 7312 | Pekr | no, just real-life aproach. If there is a risk, that half year SW might be outdated API-wise, I would at least check how safe I am using last published distro,no? But - everything is solvable - those who really want, surely would find their way to the latest stuff ... | 12-Oct 9:03 |
| 7311 | Ladislav | "Anyone eventually willing to give it a try once time permits will think twice" - excuses? | 12-Oct 8:50 |
| 7310 | Pekr | But that's just theoretical situation anyway .... | 12-Oct 8:13 |
| 7309 | Pekr | I understand that you are focusing resources as much as possible, otoh it is a bit dangerous aproach - R3 GUI saw rather intense concept changes during last year. Anyone eventually willing to give it a try once time permits will think twice, as recent public release could be pretty much outdated in few weeks, API wise, etc. There should imo be a way, that upon some request or bunch of requests, public release is done e.g once in few months? | 12-Oct 8:12 |
| 7308 | Pekr | Well, that contradicts a bit expectation, that RMA's GUI is RT's officially endorsed GUI to be bundled with R3. OTOH there are no official R3 releases anyway, so .... | 12-Oct 8:10 |
| 7307 | Robert | Anyway... we continue with our development but public releases will have lower priority. We are using our stuff to build some small tools, we will publish. Than you might take a look what's possible. | 12-Oct 6:19 |
| 7306 | Robert | Well, we all have a hell lot to do. There are just a some simple facts: - making public releases cost us time. Not horrible lot but anyway... - people are interested to take a look at the code and run the tests... - maybe we get some feedback All nice, but it doesn't move us forward faster. I'm not frustrated I'm just wondering.... there are still a lot of excuses why R3 can't be used (which is wrong) but only a very few people try to build something with it. | 12-Oct 6:18 |
| 7305 | BrianH | I will be more actively interested when I start having to write code that requires any GUI at all, but what I'm working on right now doesn't even need a web interface. All batch and server stuff, and almost all the REBOL stuff is R3. This can't last forever, so I will eventually need a GUI. I am working on ODBC though. | 12-Oct 1:06 |
| 7304 | james_nak | Robert, I am in the same boat working on an R2 application when I get the time to even work on that. I do understand your frustration though after listening to all the concern. As Endo said, please keep up the good work. | 11-Oct 21:25 |
| 7303 | Sunanda | Robert -- an R3 GUI just isn't one of my priorities just now. While there is no likely target date for a beta release of R3, all my REBOL development is on R2. I was happy to help debug R3 alphas while that project had some momentum, and I may be again in the future, But right now, I just do not have the time for what I have to consider to be speculative projects. I hope you do get the help and feedback you need. | 11-Oct 21:04 |
| 7302 | Endo | Robert: you are wrong. As Pekr said many of us are waiting and busy with something else. I downloaded all the RMA R3 stuff, tested all GUI examples (found some crash problems btw) I really would like to help/write a tree style, but I'm not a good Rebol coder I'm afraid. So please keep up the work. | 11-Oct 20:07 |
| 7301 | Pekr | As for me - "I would like to help", and I will at some point, at least with testing. But got my own project 2Zone moving, awaiting LED Screen arrival and needing to do many arrangements. I can't surely code tree-view,but I can test, even privately, for anyone who asks me. Not much next 3-5 weeks though .... | 11-Oct 13:49 |
| 7300 | Pekr | Robert - I think that it is not accurate, that noone is interested in the R3 GUI. IMO we all are, it is just that each of us is busy elsewhere. If you look into the past of this group, or in the old GUI (Carl's one) old days, it was mostly me and 1-2 users to do some comments, studying code, etc. It is about the general lack of man-power. E.g. shadwolf claimed, he can do tree view in few hours, but is refusing to, and you better don't read the long blog chat. It is also about lost confidence of many rebollers into R3 in general. Or just maybe - ppl being in wait mode, untill Carl reappears? | 11-Oct 13:48 |
| 7299 | Robert | So, I see no one is really interested in this R3 GUI stuff... I'm wondering a bit but anyway... I think doing public releases might not be worth the effort. | 11-Oct 13:23 |
| 7298 | Robert | We don't have it on our plan at the moment, but it's a fundamental style so this would fit good with the styles we do. | 8-Oct 10:21 |
| 7297 | Robert | Is anyone willing to try to develop a tree style? | 8-Oct 10:20 |
| 7296 | Robert | We are already working on it. But it doesn't impact the style writer. You can add a nice look later. | 7-Oct 14:48 |
| 7295 | Pekr | Robert - so the infrastructure for skinning will be added later? | 7-Oct 14:07 |
| 7294 | Robert | The base is now matured enough that all can help. | 7-Oct 13:43 |
| 7293 | Robert | Anyone going to help developing styles? We need more of them. | 7-Oct 13:43 |
| 7292 | Pekr | As for the possible "look & feel" of the GUI, I personally like HTC Sense, and Linux Mint - combination of light greay and green. IIRC Ashley created some more lightweight look for his GUI too later in the process ... http://www.xda-developers.com/wp-content/uploads/2010/04/ScreenShots.png?139d23 http://smartphoneblogging.com/android-picture-galleries/htc-sense-screenshots/ http://www.linuxmint.com/screenshots.php Take it just as a note :-) | 7-Oct 10:07 |
| 7291 | Claude | great release ;-) thank you. perhaps ask carl to do somethink for gui on linux | 4-Oct 18:19 |
| 7290 | Henrik | Need the facilities for skinning to be in place first, so it will be a while. | 3-Oct 13:23 |
| 7289 | Pekr | Does it mean, that material system is in-place, or was it simplified? What is the state re skinning? From what I understand, Henrik had no free time to work on it last I checked? | 3-Oct 13:09 |
| 7288 | Pekr | "Our next focus is on the skinning system. We finally want to have the most beautiful R3 apps on the planet :-)" - your Twitter message is very welcomed :-) | 3-Oct 13:08 |
| 7287 | Pekr | Cool that he's available. I noticed his new photo on a vineyard, on facebook, so he's still alive and well :-) | 3-Oct 11:48 |
| 7286 | Robert | We are in contact with him, but as you know this can than still take some time. | 3-Oct 11:45 |
| 7285 | Pekr | Cyphre - is there any chance Carl is going to be available to do some low-level fixes? It kind of crashes very often, but of course, with one specific use-case, so "normal GUI usage" (whatever that means) could be without any problems ... | 3-Oct 11:39 |
| 7284 | Cyphre | Pekr, the 'hard crashes' are most probably related to one bug that is waiting on Carl to trace/fix since it looks we are not able to do it from the host-kit side. | 3-Oct 9:58 |
| 7283 | Henrik | ok. anything reproducible helps. | 2-Oct 15:54 |
| 7282 | Pekr | I just posted what I do. Running above script, closing the windows, and trying to click into some forms. Not easily reproducible ... | 2-Oct 15:52 |
| 7281 | Henrik | Pekr, if you can post directly what you do, that would be helpful, so Bolek can solve cases, one at a time. | 2-Oct 15:51 |
| 7280 | Pekr | I can still get hard crasches of R3, in various phases: do %r3-gui.r3 do %examples/run-layouts.r3 Two times I got a crash, when just closing the windows, and when at layout #15, clicking in the form. Once I got it with layout #20, and once at layout #27, clicking the big red button ... | 2-Oct 13:42 |
| 7279 | Robert | The more help to build test-cases and submit them to us, the faster we will be in pushing R3-GUI forward. | 2-Oct 9:41 |
| 7278 | Robert | With our R3-GUI test-system available now, we could really need some help in creating test-cases. The more the better. We want to build-up a huge test-suite for GUI tests that we run on "every commit" to keep quality high and identify breaking changes. | 2-Oct 9:40 |
| 7277 | GrahamC | Thanks for the new release. | 1-Oct 1:38 |
| 7276 | Henrik | Not sure, as the usefulness is probably limited outside NLPP. | 26-Sep 9:05 |
| 7275 | GrahamC | Are the RebGUI widgets being released? | 26-Sep 9:01 |
| 7274 | Henrik | That time is better invested in allowing people to work on specific things, like the automated testing system for the R3 GUI, rather than specialize ourselves into a corner this early. | 26-Sep 8:59 |
| 7273 | Henrik | The timing is bad, as NLPP 2.0 has already been in development since early 2011 and it's almost leaving alpha development. Furthermore, there is a lot of development time invested in some special RebGUI widgets for NLPP and converting this work to R3 would take a significant amount of time. | 26-Sep 8:57 |
| 7272 | Pekr | ok, thanks ... Ithought that R3 GUI is suited for that task, but that would be probably a preliminary assumption :-) | 26-Sep 8:54 |
| 7271 | Henrik | NLPP 2.0 is R2 and RebGUI based. | 26-Sep 8:43 |
| 7270 | Pekr | If I understand it correctly, your NLPP app, version 2.0, is going to be done in R3, hence using R3 GUI? | 26-Sep 8:40 |
| 7269 | Pekr | Taken from RMAsset Twitter: "We plan to release a new R3-GUI version next Friday." Any significant changes about tobe expected, in comparison to latest release? | 26-Sep 8:39 |
| 7268 | GrahamC | In an async application you can't control which windows popup in the background ... so you want to keep focus on a field where you are entering data and not be kicked out of that field | 17-Sep 21:53 |
| 7267 | Henrik | noted. perhaps Bolek can answer if this is already possible (I'm already doing that in the VID Extension Kit). | 17-Sep 21:52 |
| 7266 | GrahamC | or dialog | 17-Sep 21:51 |
| 7265 | GrahamC | without having to create a modal requester | 17-Sep 21:51 |
| 7264 | GrahamC | One thing I would like to see is the ability to keep focus on a field and not let it be lost to other faces/widgers appearing | 17-Sep 21:50 |
| 7263 | Kaj | Ah, so you enter the text. Thanks | 17-Sep 21:26 |
| 7262 | GrahamC | looks like it removes the widget | 17-Sep 21:25 |
| 7261 | Henrik | I think the intention is to emulate the MacOSX tag field. You write in a "floating" text field and when pressing enter, it becomes a tag, which can be deleted or moved around. Deleting or moving doesn't work yet. | 17-Sep 21:25 |
| 7260 | Kaj | Is that just CHECK, or does it work differently? | 17-Sep 21:23 |
| 7259 | Henrik | Tag field style: http://rebol.hmkdesign.dk/files/r3/gui/257.png | 17-Sep 21:19 |
| 7258 | james_nak | Thanks Cyphre for the explanation. | 2-Sep 21:36 |
| 7257 | Robert | And, there won't be any changes. It's just to access stuff in a face. | 2-Sep 13:42 |
| 7256 | Robert | We found a way to support both without big effort. The non path version is better if things are script generated. | 2-Sep 13:42 |
| 7255 | Pekr | How one distinguis obfuscated path notation from the real one? I have headache because of path notation usage from VID2, where one could cause "unexpected" changes :-) | 2-Sep 13:33 |
| 7254 | Kaj | I like path notation better, too | 2-Sep 13:29 |
| 7253 | Robert | We are currently discussion an option how to write GUI dialects. The thing is how to access face stuff. At the moment you write it like this: get-face/field my-table [cell 2x3] Whereas I like path notation more: my-table/cell/2x3 Using path notaion is not possible but we could enhance the dialect in a way that: "get-face my-table/cell/2x3" would be converted internally to: get-face/field my-table [cell 2x3] So, what do you think? I'm not sure if supporting the path notationis worth the effort. | 2-Sep 13:00 |
| 7252 | Cyphre | James, I wrote first round of basic tests for some styles and so far this method works well. I haven't tested recording of realtime resizing and dragging so far but I'm sure if there are any issues they'll be fixed along the way. Otherwise this method doesn't cover only recording of user input, but it is possible to insert 'checkpoints' with REBOL like code to check specific conditions during the testing sequence. Cmobination of both makes this testing subsystem very flexible and relatively easy to use. | 30-Aug 15:07 |
| 7251 | Henrik | Perhaps that's a question for Cyphre? | 30-Aug 7:14 |
| 7250 | james_nak | Thanks Henrik. I'm curious if you have found things that didn't work using these methods. | 29-Aug 23:25 |
| 7249 | PeterWood | That's impressive Henirk | 28-Aug 4:46 |
| 7248 | Gregg | Most excellent Henrick (and RMA). | 27-Aug 23:18 |
| 7247 | GrahamC | Very nice | 27-Aug 19:59 |
| 7246 | Henrik | Simple demo of automated testing: http://rebol.hmkdesign.dk/files/r3/gui/010.mov | 27-Aug 13:56 |
| 7245 | james_nak | DB mode? That's exciting news. Thanks Rebolek for the update and Pekr for asking. | 26-Aug 13:32 |
| 7244 | Rebolek | It queries db on table refresh for visible rows. | 25-Aug 13:58 |
| 7243 | Pekr | btw - do you work with the db/query-obtained data block "as-is", just selecting which column to display at what position, or do you have to pre-build/modify your data first to be displayed? | 25-Aug 13:55 |
| 7242 | Pekr | interesting, thanks ... | 25-Aug 13:53 |
| 7241 | Rebolek | column sorting: three state. column filtering: yes. how much data: lots of. In normal mode you're limited by memory, in DB mode you're limited by your DB system. horizontal scrolling: not yet, but can be easily implemented (you can already select which columns to display). | 25-Aug 13:48 |
| 7240 | Pekr | I am referring to: http://rebol.hmkdesign.dk/files/r3/gui/255.png - hmm, no horizontal scrolling? | 25-Aug 13:32 |
| 7239 | Pekr | how powerfull is a table style? I expect it not being full grid capable, as Cyphre did in the past, however what's the basic functionality to expect? - column sorting - two state, or three state? (I don't like when I can't get back the original sorting = unsorted), but that's just my point-of-view, and not importan feature initially - column filtering like in MS Excel - how much data the table handles? | 25-Aug 13:30 |
| 7238 | Gregg | Thanks for the update Henrik! | 24-Aug 16:07 |
| 7237 | Henrik | actually it doesn't have to be particuarly large, but there are some specific triggers, like this one: view [tab-box ["tab1" [] "tab2" [] "tab3" [] "tab4" [] "tab5" []]] | 24-Aug 15:25 |
| 7236 | Henrik | it's the old assertion failure | 24-Aug 15:21 |
| 7235 | Pekr | btw - what's the bug preventing to create larger layouts? | 24-Aug 15:20 |
| 7234 | Pekr | Thanks a lot for an update, both Robert and Henrik. It is encouraging to see some activity. As I personally offered to Rebolek - I can make some quick testing/private reporting, so if you can prepare some interim release, I am interested. But - I can wait for the official one. | 24-Aug 15:20 |
| 7233 | Henrik | The current overview of all styles: http://rebol.hmkdesign.dk/files/r3/gui/253.png Some more images here: http://rebol.hmkdesign.dk/files/r3/gui/ A bit of status: - Cyphre has recently fixed a bug in the hostkit with the display of some unicode characters. Will see if there can be a release. - Cyphre has been working on fixing various low level issues in the R3 GUI source - Cyphre is working on testing scheme for GUI and some documentation - Bolek is working on styles and a TODO test application, called "Notation" for Robert - We still need Carl to fix one particular bug, which is prevents creating complex layouts | 24-Aug 8:26 |
| 7232 | Henrik | Still into deep rewrites. | 23-Jul 7:56 |
| 7231 | GrahamC | Has there been any recent releases here? | 22-Jul 23:50 |
| 7230 | Gerard | Thery are also developing a compatibler ELICA LOGO compiler called Lhogho. refs are also included. | 11-Jul 19:37 |
| 7229 | Gerard | A post to keep you informed about what the ELICA LOGO can do relative to 3D graphics, animation an GUI (under windows only) - all their libraries are open source and I thought you would like to know about - see the link in the OPEN GL group. Hope it can be useful in some way or another. Regards, Gerard | 11-Jul 19:36 |
| 7228 | Gregg | Thanks for the report Robert! | 24-Jun 22:54 |
| 7227 | Robert | This is already done. | 24-Jun 8:03 |
| 7226 | Pekr | Robert - interesting. How goes redesign of "vid level" actions/reactions? | 24-Jun 7:56 |
| 7225 | Pekr | As for the "event bubbling", I too agree, that Steeve has some merit here, although I voted differently :-( | 24-Jun 7:54 |
| 7224 | PeterWood | Sounds very encouraging Robert. | 24-Jun 7:54 |
| 7223 | Robert | This is a major step as it will reduce our hours to do these tasks. Testability must be designed in right from the start and it will save thousands of hours of effort later. | 24-Jun 7:53 |
| 7222 | Robert | Quite good. We did some major re-factoring and are currently getting automatic GUI testing done. We need this for several reasons: 1. Automatic style lib testing 2. Applicaiton testing | 24-Jun 7:53 |
| 7221 | Pekr | Any news from RMA guys? Not trying to push for anything, just curious about the progress of the GUI implementation. Acutally I do remember you stating you are taking longer time before there is next relase. So how things go? | 24-Jun 7:42 |
| 7220 | Gregg | It's a good point though Steeve. | 12-Jun 19:09 |
| 7219 | Gregg | If there is design tension between what is easier for the style developer versus the style user, my vote is to favor the style user because styles are used far more often than they are built. | 12-Jun 19:09 |
| 7218 | Steeve | I take one example: If I create one button style with only one gob and then I decide to add an inner gob to change its aspect. I don't want to have to change some code just because of that. Gob's compositing should be the easiest as possible | 12-Jun 12:20 |
| 7217 | Steeve | On the contrary of what other believe, I tink the most common case, is to propagate events | 12-Jun 12:10 |
| 7216 | Steeve | easiest way meaning: less code | 12-Jun 12:06 |
| 7215 | Steeve | I'm late and give my vote to #2. Why ? because I think it's the easiest way to assemble components containing several gobs acting together. | 12-Jun 12:00 |
| 7214 | Pekr | Close the topic, Cyphre - your conclusion seems about to be right ..... | 9-Jun 23:19 |
| 7213 | GrahamC | most flexible option is the preferred for me | 9-Jun 21:13 |
| 7212 | Cyphre | Gregg, Ladislav: ye, I agree, so to me it looks the 'conclusion' is heading to the #3 case with some possible 'shortcut' support to make the event propagation less verbal for the programmer. What do you think? Should we wait for more input or close this topic? | 9-Jun 20:14 |
| 7211 | Ladislav | (a simple actor "propagating" some event up the parent hierarchy can be easily inherited) | 9-Jun 19:10 |
| 7210 | Ladislav | the "it will be complex for event handling of the rest 95% of normal cases" is the reason why I prefer #3. As Gregg noted, in case of having #3 we can still define some "shortcuts" either by defining a simple actor "propagating" some event, or even adjust the layout dialect to accept a keyword | 9-Jun 19:09 |
| 7209 | Gregg | Given Richard's example, where unhandled events bubble: view [ hpanel [ box red on-click [print "red box clicked"] box blue on-click none ] on-click [print "panel clicked"] ] "box blue on-click none" had hidden meaning. It means "pass thru", not "don't take action". Give his example of how to explicitly propagate events: on-click: [ all [ pf: parent-face? face do-actor pf 'on-click arg ] ] Would it be possible to define a shortcut, e.g. on-click 'pass-thru, in either scenario? | 9-Jun 16:19 |
| 7208 | Rebolek | I never liked insert-event-func very much. | 9-Jun 11:41 |
| 7207 | Cyphre | (this feature is imo more flexible than the 'insert-event-func' stuff in R2) | 9-Jun 11:37 |
| 7206 | Cyphre | Pekr, I don't think 'insert-event-func' has anything to do with this decission. Currently R3GUI doesn't have the exact 'insert-event-func' mechanism. But you can add your custom handler with specific priority into the main event loop and then either filter out or pass the events to the system. | 9-Jun 11:35 |
| 7205 | Cyphre | Rebolek, also I'm afraid in case of #1....since you can call any actor of any style/face from the style code, we would propbably check all such DO-ACTOR calls in the code to make sure they are not called on style/face that doesn't have the specific actor defined othervise the propagation would be triggered. | 9-Jun 11:21 |
| 7204 | Pekr | Cyphre: if we go for #3, will there be the option to "insert-event-func" like in R2 ('detect functionality), which would allow us to apply some filters? E.g. for dev/demo purposes? | 9-Jun 11:18 |
| 7203 | Pekr | As for overriding. I am not sure higher level on-click should disable lower level on-click. In the OOP I used (CA-Visual Objects), and just IIRC (so sorry, if inaccurate), you had such options: - to execute child method - in the above you either returned false (maybe I get this one wrong, but you get the idea) or the parent method was called right after the child's method - there was also some override option, but I don't remember it, it is 12 years old experience | 9-Jun 11:13 |
| 7202 | Cyphre | Rebolek, that's not true. You can create layouts with misc actors combinations that will behave strange and you'll be scratching your head where to put at least empty actor to stop the unvantred propagation. | 9-Jun 11:13 |
| 7201 | Henrik | For style content you would use standard styles that may have complex event handlers. You likely don't want to overwrite those. | 9-Jun 11:13 |
| 7200 | Henrik | Cyphre, I was supposing that this would be the same for style content as well as for layouts. Hard to explain without a deeper study of all the mechanics of how events are propagated or overwritten. | 9-Jun 11:12 |
| 7199 | Cyphre | So maybe th #3 is really best default behaviour that keeps events under control. I agree here that in case of #3, if you want to propagate event's then you would need to write more code that you would like though but OTOH you know what you are doing. | 9-Jun 11:11 |
| 7198 | Rebolek | I think if such confusing situation will happen, it's solely style's writer responsibility. | 9-Jun 11:11 |
| 7197 | Cyphre | image=imagine | 9-Jun 11:09 |
| 7196 | Cyphre | Otherwise in the #1 case I can image there could be some confusing situations where some face doesn't have some actor defined and the event will 'bubble' too much up in the face structure causing execution of unwanted actor. What do you think? | 9-Jun 11:09 |
| 7195 | Cyphre | Henrik, "in case the inner ON-CLICK is very complex" what you mean by this? The inner ON-CLICK just doesn't have to be defined, not complex if you want to execute the outer one no? | 9-Jun 11:07 |
| 7194 | Cyphre | The #1 is IMO very simmilar to #4..it differs just by the form of the syntax: #1 example: view [ hpanel [ box red on-click [print "red box clicked"] box blue on-click none ] on-click [print "panel clicked"] ] #4 example: view [ hpanel [ box red on-click [print "red box clicked"] box blue options: [propagate-actors: [on-click]] ] on-click [print "panel clicked"] ] | 9-Jun 11:04 |
| 7193 | Henrik | I don't like the idea in #1 that an outer ON-CLICK overwrites an inner ON-CLICK in case the inner ON-CLICK is very complex. | 9-Jun 11:04 |
| 7192 | Henrik | ok, I think I got it a bit backwards, so maybe #3 is OK. | 9-Jun 11:02 |
| 7191 | Cyphre | Henrik, I think propagating large number of events is solved easily using the #2 as this is some kind of special case imo. normally you don't need to propagate even't too much. That's why others doesn't like the #2 option much imo. | 9-Jun 11:01 |
| 7190 | Cyphre | When thinking #3 vs. #1: In the #3 case the propagation should be done like: on-click: [ all [ pf: parent-face? face do-actor pf 'on-click arg ] ] the code above would pass the received event in ARG value to the ON-CLICK actor of the parent face. The #1 option would offer probably simpler shortcut to propagate the event up like: on-click: none but we would need to allow write in the dialect something like: view [ hpanel [ box red on-click [print "red box clicked"] box blue on-click none ] on-click [print "panel clicked"] ] in the code above the ON-CLICK actor of blue box face could be set to NONE to allow propagate the click event up so the ON-CLICK actor of hpanel is executed. | 9-Jun 10:59 |
| 7189 | Henrik | is there any issue in propagating a larger number of different events? suppose you want to simply handle all events from an inside face. | 9-Jun 10:56 |
| 7188 | Cyphre | Personally I prefer also the the current #3 behaviour but if we want to deal with more complex propagation I'd go with the #2 which gives really flexible control for some special cases but as some of you noted it will be complex for event handling of the rest 95% of normal cases. | 9-Jun 10:42 |
| 7187 | Cyphre | yes, I'm just trying to see what could be better on the #1 | 9-Jun 10:41 |
| 7186 | Rebolek | as I said, it's just an example | 9-Jun 10:39 |
| 7185 | Cyphre | ...and currently you cannot set actor to undefined state. So #1 wouldn't be too much useful, isn't it? | 9-Jun 10:34 |
| 7184 | Cyphre | If yes, then in #1 case the event would be processed in the Image as well because image style have defined on-click actor no? | 9-Jun 10:33 |
| 7183 | Rebolek | exactly. | 9-Jun 10:32 |
| 7182 | Cyphre | So can I translate as 'Image face inside Button face'? | 9-Jun 10:31 |
| 7181 | Rebolek | It's just an example, image you want to add save icon to save button. | 9-Jun 10:30 |
| 7180 | Cyphre | So far it looks everyone is happy with the current behaviour (#3)? | 9-Jun 10:30 |
| 7179 | Cyphre | Rebolek, wht you mean by 'add image to button'? | 9-Jun 10:28 |
| 7178 | Rebolek | For example if I add image to button, with #3 I need to ad actor to image to catch click and send it to button. With #1 it's done automatically. | 9-Jun 8:18 |
| 7177 | Rebolek | If bubbling is enabled by default, you just need to add an actor where you want to catch the event. | 9-Jun 8:17 |
| 7176 | Robert | Is there a way that we can use #1 and add a way that it can be overriden by #3 concept? So, everyone how don't require fine-grained handling, uses default bubbeling. | 9-Jun 8:13 |
| 7175 | Rebolek | I prefer #1 and then #3. | 9-Jun 8:06 |
| 7174 | Robert | Yes, 3. is explicit while 1. is implicit. | 9-Jun 8:01 |
| 7173 | PeterWood | On the other hand with #3, this could be achieved by the buttons sharing a single event handler function. The clairty that option #3 brings in that as you always have to specify what happens to an event would, for me, lead to a lower number of "head scratching" bugs. | 9-Jun 7:53 |
| 7172 | Robert | With 3. you can simulate 1. The advantage of 3. is, that I can decide at what place the parent actor is called. Which leads me to a question: Is 3. a call the parent actor, which returns, or do I just let the event flow and it will never return to my handler? | 9-Jun 7:51 |
| 7171 | PeterWood | Perhaps a better example would be to allow a user to tab along a row of buttons. A single handler could be written for the button "container" that would handle tab presses instead of each button having a specific "handler". | 9-Jun 7:48 |
| 7170 | PeterWood | One of the attractions of #1 is that it makes it easy to implement "default handlers" at some point higher up the hierarchy. For example based upon an "esc pressed event" (if one were to exist.) and you had designed a panel with four buttons. If you wanted to close the panel when the user pressed esc, you would simply have a single "handler" for the panel which would receive the event. I'm sure that this isn't the best example and apologise in advance for my ignorance of REBOL3-GUI and its common terms. | 9-Jun 7:44 |
| 7169 | Pekr | I am probably for #3 or #1. Just help me to brainstorm one case - what we have mostly wrong in REBOL, is pop-up handling. I mean - just recently e.g. when you "drag", and you move away from the face coordinates, the dragging stops. The same goes for the context menu etc - you have to be able to close the menu by clicking anywhere in the apps window. Which model fits best? | 9-Jun 6:22 |
| 7168 | Pekr | Hmm, I wonder if my Photon example is in contradition or in any relation, as having translucent face upon A->B does not make A->B being child of such a filter face ... | 9-Jun 6:19 |
| 7167 | Pekr | I do remember how QNX Photon used such a trick to share screen content. You defined X*Y area of the screen (imagine empty translucent face) and all events got via that "filter", so that you know what to send to target computer, and then the event was propagated to cause an action (at least that is how I understood it back then) | 9-Jun 6:18 |
| 7166 | Pekr | I wonder if anyone uses reverse aproach - from top window, down to bottom face. Would be slow probably? | 9-Jun 6:16 |
| 7165 | Pekr | Just supppoting question - in R2 we were able to have "event filters" defined via insert-event-func. It allowed us to catch events going to subfaces. So my question is - if e.g. for #1, the event goes directly to face B, am I able to catch it, by inserting the filter into face A? http://www.rebol.com/docs/view-face-events.html#section-14 | 9-Jun 6:15 |
| 7164 | Ladislav | Yes, the alternative "some events bubble, some don't" looks like worse than any of #1 to #4 | 9-Jun 6:10 |
| 7163 | Ladislav | * I do agree with Peter that #3 is clear and workable. Accepting any of the alternatives would require (a lot of, I am afraid) code to stop unsolicited bubbling. * #4 appears to lead to complexity, and thus it may be the worst alternative * #1 looks like the second best to me * #2 looks like the second worst | 9-Jun 6:09 |
| 7162 | PeterWood | I am thankful that you aren't considering the DOM 2t option - some events bubble, some don't. | 9-Jun 0:30 |
| 7161 | PeterWood | Yes to stop bubbling you define an empty event handler. | 9-Jun 0:29 |
| 7160 | PeterWood | #2 seems the worst of both "worlds" #3 seems clear and workable #4 appears to lead to complexity | 9-Jun 0:29 |
| 7159 | Gregg | Or does it have to return a specific value to say it handled the event? | 9-Jun 0:25 |
| 7158 | Gregg | To stop bubbling, you just define an empty on-click handler I assume? | 9-Jun 0:24 |
| 7157 | PeterWood | The approach outlined in #1 is similar to that employed by LiveCode (used to be called Revolution). It seems to be a good model. It additionally supports "user-defined" events in the same way. | 9-Jun 0:23 |
| 7156 | Gregg | #4 is an extension to #3, and would be my first choice if #3 isn't enough. I generally don't like having to say "stop!" to avoid unexpected behavior. I don't know if #1 works well, though I think QNX Photon used it. If the 'bubble option can be part of the style, then you can define buttons not to bubble on-click by default, but maybe 'text would, for example. | 8-Jun 20:48 |
| 7155 | Cyphre | It's time to decide about propagation of events using actors in R3GUI so we would like to know your opinion on that. example: Let's have face A and face B which is inside face A. Currently, when you click mouse button on the face B and the face B has defined ON-CLICK actor the event is fired to that actor. If the face B have no ON-CLICK actor the event is not catched anywhere. We got a request to checnge this so there are few possible options we could use: 1. If face B doesn't have ON-CLICK actor defined then propagate the event up to its parent face (in our case face A) and up until any ON-CLICK is found. (If the face B have ON-CLICK defined then the actor is executed and propagation stops here.) In other words the event propagation stops in the closest found ON-CLICK actor during the 'bubbling' of the event upwards. 2. Propagate the event from face B thru its parent face (in our case face A) and up to the topmost(Window) face. The propagation/bubbling is done by default and can be stopped in any ON-CLICK actor on the way upwards by returning 'stop-event(or any other chosen) keyword. (this is simmilar to the model used in HTML) 3. (current behaviour) Don't propagate the event. Just execute the ON-CLICK actor in face B in case it is defined. Programmer have to manually add event propagation code to the actor if event bubbling is required. 4. Don't propagate the event by default. But introduce PROPAGATE/BUBBLE-ACTORS (or any other chosen word) option field that can be set for each face. The option could hold block of actor names that should propagate/bubble the events up. Please, keep in mind that chosen behaviour affects not only actors that handle user input but also actors like ON-INIT, ON-MAKE and any other possible actors in general. Please post either your favorite from the above options or even any other possible solution you think is better. Thanks for your help. | 8-Jun 20:13 |
| 7154 | DideC | IS-ATTACHED / HAVE-ATTACH | 27-May 7:42 |
| 7153 | GrahamC | These are like linked lists where elements might be in one than one list? | 20-May 21:57 |
| 7152 | GrahamC | Ok, change that to parents-faces | 20-May 21:56 |
| 7151 | Sunanda | It is possible, I think, Graham that a face can be in more than one heirarchy; so PARENT and CHILD alone does not describe which hierarchy. Other structures that may have child/parent faces: panels within panels; Z-axis visibility. | 20-May 16:38 |
| 7150 | GrahamC | or similar | 20-May 10:33 |
| 7149 | GrahamC | parent-faces child-faces | 20-May 10:33 |
| 7148 | Pekr | Sunanda - nice suggestion .... | 20-May 10:26 |
| 7147 | Pekr | there is also an alternative world to ATTACH - CONNECT? | 20-May 10:25 |
| 7146 | Sunanda | My understanding is that the purpose of ATTACH is to direct the flow of action events..... ....If face B is attached to face C, then face C also gets B's action events. And if B is attached to A, then B gets A's action events, prior to them flowing to C. So, from a stream-of-events, perspective: A is UPSTREAM of B. While C is DOWNSTREAM of B. Hence a suggestion,,,,,, ATTACHED-UPSTREAM and ATTACHED-DOWNSTREAM. | 20-May 10:18 |
| 7145 | Pekr | I am not sure it is correct english wise though ... | 20-May 10:02 |
| 7144 | Pekr | Well, this is really a bit longish :-) Having fever, it is a bit difficult to think for me, but :-): 1) ATTACHED 2) ATTACHING Hmm,not clear after few secs .... so: 1) ATTACHED-FROM 2) ATTACHING-TO ? | 20-May 10:02 |
| 7143 | Ladislav | A terminology problem related to the ATTACH keyword. Every face should have an attribute listing the items attached to it, and an attribute listing the items to which it was attached. One (let's call it 'extra long') alternative might be ITEMS-ATTACHED-TO-THIS and ITEMS-TO-WHICH-THIS-IS-ATTACHED. To show you an example, let's have faces A and B, and suppose, that the user attached B to A. Then: 1) for A, the ITEMS-ATTACHED-TO-THIS list shall contain B 2) for B, the ITEMS-TO-WHICH-THIS-WAS-ATTACHED shall contain A The problem is, that the above two attribute names probably aren't the best possible (or, are they?). Any "ideal" attribute names you prefer? | 20-May 9:41 |
| 7142 | Henrik | I'm not sure it will be implemented that way, but it is already a problem that we need to append actor code to a previous actor, when creating a new style, based on an older one. An example of this is a field with extra functionality to perform some kind of action on an attached face in the ON-KEY actor. This is possible now, but the method is obscure. | 11-May 10:32 |
| 7141 | Pekr | What you are basically doing is some OOP aproach here. But adding the code to the end? Who decided that? There are three levels - replace action, pre-init, post-init. So what do we choose? In Visual Objects I had all three capabilities. Dunno if you would find that usefull though .... | 11-May 9:48 |
| 7140 | Henrik | if you can't, then the GUI will be entirely useless. you couldn't even start it. | 11-May 9:44 |
| 7139 | Pekr | stacking, chaining - whatever. We just need to be able to specify more than one action, that's all ... | 11-May 9:43 |
| 7138 | Henrik | it won't be necessary with actions (I hope). you simply call actors directly. About chaining them, how does it make sense to chain an on-click and on-hover actor? They are separate actions. What you need is the ability to stack the action code for actors, so that if an actor is already defined for a style, then the new action code could be appended to the original code. I use a similar design in my private version of the VID Extension Kit, but am also forced to use the traditional actions as they are part of the standard face. | 11-May 9:40 |
| 7137 | Pekr | Well, VID was always declarative, and we know it was/is limited. From your proposal it still looks good to me, there just will be the need to be able to specify more then one action. I can even imagine: button "browse" #"B" action [ on-click [do something] on-hover [do something] ] But for single actions, there would be one unnecessary block level probably. I am open to any proposals, and looking forward to final solution .... | 11-May 9:28 |
| 7136 | Robert | the problem with complexity is, you can't get rid of it. Only complicated things can be reduced. | 11-May 9:18 |
| 7135 | Robert | complicated: No, it get clearer. The current system is complicated if you want to do more than kid things. That was the same problem with VID. It was simple for non-value things but not flexible for enterprise things. | 11-May 9:17 |
| 7134 | Robert | chain: Yes, why not. | 11-May 9:16 |
| 7133 | Pekr | well, so you are basically exposing low level actors to the dialect level. Initial idea was to have hidden actions inside the style level. What you propose might work, but how do I set an action? Can I somehow "chain" actions? button "browse" on-hoover [code here] on-click [code here]? Also - does not it make dialect more complicated? You have to count on every possible action any style can have .... | 11-May 8:22 |
| 7132 | Robert | than you can use things like: on-hoover, etc. too | 10-May 16:46 |
| 7131 | Robert | button "browse" on-click [browse http://rm-asset.com] | 10-May 16:45 |
| 7130 | Pekr | Also - DO is an implicit REACTOR, but still one of reactors. So - what will happen to DO itself? Will we call it just another KEYWORD? | 10-May 13:36 |
| 7129 | Pekr | "- making reactors unnecessary ..." - understood, but doesn't it break Carl's idea of having most common actions directly available in a layout, without any overhead? I mean - reactions like DO, SUBMIT, BROWSE, CLOSE etc.? Could syntax example be shown? E.g. BUTTON "browse" BROWSE http://www.rebol.com will become? BUTTON "browse" ATTACH ???? | 10-May 13:34 |
| 7128 | Pekr | There was ATTACH IIRC - it was used for scrollers mainly. In more abstract pov it might just call attached style's on-attach or on-set, I don't remember anymore. But - I also remember guys here said, that areas will not be done that way anyway (attaching just separate scroller style) .... | 10-May 13:27 |
| 7127 | Kaj | Wasn't there an ATTACH already? Or was it implicit? | 10-May 11:21 |
| 7126 | Ladislav | - forgot about yet another Layout dialect keyword: OVERRULE | 10-May 8:22 |
| 7125 | Ladislav | In a simplified form: - the DO-STYLE function will be renamed to DO-ACTOR - both Henrik and Robert wanted to be able to influence the behaviour of actors from the Layout dialect, - which was not possible yet, - and was not compatible with the idea of reactors - therefore, it looks like the best idea to introduce one new Layout dialect keyword (ATTACH), - and allow to influence actors from the Layout dialect, - making reactors unnecessary | 10-May 6:52 |
| 7124 | Robert | So, we are thinking about making the handling of events much more clear. | 10-May 6:43 |
| 7123 | Robert | The main problem at the moment is (and I hope I hit it correctly, otherwise Lad etc. will correct me) that it's not clear which ACTORs call which REACTORS. And if all REACTORS are executed or not. So, there is not logical relation between an ON-KEY event and an ON-KEY handler. Further, one sometimes need to first call the user-code event handler, than the style handler, or the other way, or in between. | 10-May 6:43 |
| 7122 | Kaj | Perhaps a summary of the proposed changes would clear the air? | 9-May 19:29 |
| 7121 | Ladislav | Pekr: "I can imagine..." - that is where we need your imagination, since we strived very hard, but the goal to make it more rigid than possible seems to be elluding us. | 9-May 11:51 |
| 7120 | Pekr | Ppl pay lots of money for crap like SAP, because there is no other way around for them :-) | 9-May 10:57 |
| 7119 | Robert | Yep, which are very limited and that's why people pay a lot for our stuff. | 9-May 10:49 |
| 7118 | Pekr | As status of RMA's GUI is more of a private effort targetting business level apps, I can imagine kind of simplification, which makes it "dumb, incappable and more rigid than possible", because it just fitst your limited business apps needs :-) | 9-May 10:48 |
| 7117 | Henrik | :-) | 9-May 10:33 |
| 7116 | Ladislav | Pekr: "I hope it stays as flexible as possible?" - sorry to spoil your expectations, but our main goal is to make it dumb, incapable and more rigid than possible. | 9-May 10:27 |
| 7115 | Robert | It will much simpler and more cabable. | 8-May 17:58 |
| 7114 | Jerry | view [ AREA [ red "12" green "AB" blue "ab"] ] Caret cannot move to "12" and "AB". A bug, I think. | 8-May 17:26 |
| 7113 | Kaj | If you streamline well, in the REBOL way, things become more flexible and capable | 8-May 13:48 |
| 7112 | Pekr | Streamlined typically sounds like simpler, less capable. I hope it stays as flexible as possible? | 8-May 13:34 |
| 7111 | Robert | We are going to re-factor the complete ACTOR & REACTOR stuff in R3-GUI. It will be streamlined, much simpler and more common in that it follows "best practices" from other GUI libs. The side effect is, that this is a bigger re-refactoring step and will take some time. Until done, we are not going to make a new release. | 8-May 13:04 |
| 7110 | Henrik | Another suggestion is to have them all end in *-FACE, so ACT-FACE, REACT-FACE. If you have another DO-* that works in a completely different domain, maybe that would be confusing. | 5-May 6:56 |
| 7109 | Pekr | IIRC,I even suggested to also rename DO-FACE to DO-REACTOR .... | 5-May 5:55 |
| 7108 | Pekr | I already expressed my preference, hence 2) | 5-May 5:55 |
| 7107 | Maxim | I definitely prefer 2. | 5-May 3:10 |
| 7106 | Ladislav | Correction: 1) do-style face 'on-key arg 2) do-actor face 'on-key arg 3)? | 5-May 0:24 |
| 7105 | Ladislav | Some time ago Pekr suggested to rename the DO-STYLE function to DO-ACTOR. The proposal seems to have attracted the attention now, so, one of the last opportunities to express your preferences. To not be just abstract, In this example we call the ON-KEY actor for a certain given FACE, supplying it a certain ARG. Variants: 1) at present, the actor call looks as follows: do-style face arg 2) the variant proposed by Pekr is: do-actor face arg 3) is there any other variant you prefer more? | 5-May 0:23 |
| 7104 | Pekr | Sorry, forgot we have recently hpanel and vpanel .... | 24-Apr-11 2:04 |
| 7103 | Pekr | "Before panel was used as a style name" - I exptect panel/vpanel to exist in upcoming releases ... and then I suggest to remove word panel from the function name. | 24-Apr-11 2:04 |