Dialecting, higher-level gadget components, and complex stuff ...

Hello list, most discussions currently running on our list is dedicated to some concrete stuff, but as I saw "associative array thread" and tried to implement some stuff at my work, it led mi to think about following general questions: 1) I wanted to have some list of person's tasks on main screen, together with some add button, and pressing an item would open another screen, with another list with concrete tasks of appropriate person, e.g.: pekr mark boss pekr-> ---> report1 definition ---> report2 definition etc. Once you press your "Add" button, you can easily add new person. But - you just extended your 'persons block which you have still present in memory. Once you start thinking about data storage, data organisation style arises. Would you prefer: ["pekr" "mark" "boss"], ["report1" "report2"] kind of organisation or just ["pekr" ["report1" "report2"] "mark" [] "boss" []] nested one? or would you use objects as Elan does in his book? In any case, you have to bear in mind you have to navigate thru data structure, and it would be good to be able to write/append to file or remove from it (while staying synchronised with memory content), as writing/saving whole stuff to file after changing one item could turn into being a little bit inefficient. Perhaps a little dbms system is way to go?. ------------ OK, let's think about another issues. What about small app in REBOL? The first aproach - comfort one, - is to use what system offers and is easily maintainable. So instead of building some custom design, use just button navigation system. But what happens if someone wants to have typical menu? OK, we've got 'choose function. If you will look at the current panel demo though, you will notice it's look&feel is not conformant to the whole design (although there seem to be some possibility to influence style thru parameter sent to function) of panel. The function also doesn't seem to handle block as sub-menu, but displays each item of block as item of given menu. Note: I come from XBase environment, where I succesfully used RAD tool for app building. It made me king here. On the other hand, it generated lot of code and I was forced to use some rules for my app logic. It was OK untill someone asked me to do something another way. As times went by and we switched to Windows Visual Objects, we decided to build "larger" system, and refused to follow tool logic. So we started to define own app logic, functions, objects, and what do we use for each new app from the tool level logic? Just a few lines with general App:Start() etc. stuff :-) RT just started to introduce higher level gadgets to /View. We have pop-ups, we have 'inform dialog windows, we have also calendar and color selector, each with closed look & feel. We will also get file managers soon. I know someone can admit - hey pekr, use what's there and don't care. But I am used to think about app as one mental body :-) I am just currently not able to see, if current combination of REBOL capabilities (VID itself, styles, dialecting) allows us to really easily change/swap look&feel of component in any consistant way? REBOL's cool, we can morph function body, we can swap feelings for face-styles and that's the way I like it. Maybe that's why I prefer separate blocks, but looking at 'dispatch e.g. shows opposite technique of nested information is being used. If something is nested and reduced, is it easily replaceable as it would be using reference? Do you remember slideshow-dialect? OK, it was great, wasn't it? What about introducing domain (higher-level gadget) specific dialects? Eg. main-menu: menu-layout [ styles funky-menu main "File" sub "Edit" sub "View" sub "Help" [view-about] sub "File" "Open" icon1 "printer setup" icon2 checked sub ] etc. Or just block with actions could exist separately, or ....... What I am still not too much comfort with is we don't use scaling or other mechanisms to make REBOL/View experience more pleasant to user. Rebodex or layout demo is more than 600 pixels high. We know certain resolution, right? Wouldn't it be good to have some switch for 'view e.g. telling if /View engine should put scrollers automatically into layout if the resulting window crosses margins of screen? Anyone? PS: Bear in mind I am in no way criticizing anything, just asking about possibilities :-) -pekr-

Hi Petr, I've moved this topic to the ally list, it has been lacking this sort of topic for while. Just on this idea of additional dialects in VID. Have you seen Bo's draw dialect? If not, check out the demos on Volker's rebsite, Bo's dialect is included in those scripts. Although that dialect returns an image!. A similar approach could be developed for other extensions to VID which can have their own dialect. It might be interesting to explore this method as an alternative to using styles & init. Maybe a fairly expressive menu dialect could be written this way? Allen K