World: r3wp
[!REBOL3 GUI]
older newer | first last |
Graham 8-Sep-2010 [3110] | pekr, it's optional |
Pekr 8-Sep-2010 [3111] | No, quite the opposite - I feared that all styles will contain that, if not, then it is ok ... |
Henrik 8-Sep-2010 [3112] | yes, validation is a simple indicator style. the "catch" is that you need to place it one place to the right of the style to validate. Carl also talked about doing the validation action itself as a reactor, but the role of reactors is still not clearly defined to me. |
Graham 8-Sep-2010 [3113x2] | Well, I think an alternative might be to change the color of the field instead .. |
instead of having a dedicated icon | |
Pekr 8-Sep-2010 [3115] | Probably a bit different topic, albeit related - in one DOS app generator I worked with, there was a possibility to e.g.: - init form values (e.g. when you create new record) - set 'update trigger - you could have multiple update actions (it was quite primitive, but sufficient - operators like +, -, replace), so e.g. entering some value into 'amount field, could trigger an update into other field on the form, or later during the commit, to even a different table. - getting/setting values of the form/panel is surely going to come IIRC |
Graham 8-Sep-2010 [3116] | AFAIR in dbase I used to change the field colours depending on validation |
Pekr 8-Sep-2010 [3117] | but the role of reactors is still not clearly defined to me - you have Carl on your GUI world, no - so just ask him :-) |
Henrik 8-Sep-2010 [3118] | graham, that's not a good alternative: 1. you create multiple ways of indicating validation 2. you may not be validating a field, but an entire panel or any other style 3. you still need to alter the style itself, which will be a ton of work. |
Pekr 8-Sep-2010 [3119] | Graham - it might not be only field, but also other styles, but it might be one of the options :-) |
Graham 8-Sep-2010 [3120] | give me an example where field validation is insufficient |
Henrik 8-Sep-2010 [3121] | Pekr: - init already happens on window open. you can specifically validate and display init symbols in the indicators. - possible to do with attach or set reactor - panel validation already works |
Pekr 8-Sep-2010 [3122] | Henrik - the proposal does not need to alter the style, right? That is indeed good. But - I still have to think about the form design - do I have to count for the space for the validator? I talk about some alignment stuff ... |
Henrik 8-Sep-2010 [3123x3] | Pekr, correct. What you need to do is attach an option for how you want to validate. Then you need to place the validation-indicator. Then the rest is supposed to take care of itself, auto-updating, etc. |
count for space: well, it should not be necessary as it simply is another style that you place after the style to validate: panel 2 [ field validate-indicator field validate-indicator field validate-indicator ] like that. | |
graham, not insufficient. inconsistent. | |
Graham 8-Sep-2010 [3126] | The issue I have with validation icons is that it makes the whole display much busier |
Henrik 8-Sep-2010 [3127x3] | that's a small problem compared to working validation into each style |
if your form is very large you will appreciate the need for consistency as you only have to check for red Xes to see where the problem is, and the validation system also automatically focuses the first problem. | |
also fields will eventually become sub-fields in tight panels, where the fields themselves may not be incorrect, but the overall value combination may be wrong, such as that for a date field and that can be for multiple different reasons. this is why the valid-indicator would contain a tool-tip to describe the problem. you would be eventually able to click on it, to get an overview or deeper help on how to solve the issue via the help system (not yet written). | |
Pekr 8-Sep-2010 [3130] | Henrik - any progress on new styles, integration of resizing model into current system, etc.? You surely can't do business apss with just buttons and fields being the only styles available? :-) What is currently being done in the R3GUI area? (as View transition to Extension has mostly finished?) |
Robert 8-Sep-2010 [3131x4] | Now we need to get R3-GUI to work again with the new hostkit. Will be finished this week. |
We work on business apps (that's always our main focus). These have highest priority. | |
buidl & deployment system is currently done so we can do large scale projects. | |
call/wait is something we will need. | |
Henrik 8-Sep-2010 [3135] | Pekr, I plan to begin implementation of dialogs and validation, but the plan has kept being pushed back due to lack of feedback from the community. |
Pekr 8-Sep-2010 [3136x2] | call/wait .... kissing your hands! :-) That is an integration problem with R3, thanks for that .... |
As for business apps - that sounds fine, it is just that we did not see e.g. list of styles, you might need. Is there e.g. a tree-view? Tabs? Table is there IIRC (there is a screenshot on henrik's site) | |
Graham 8-Sep-2010 [3138x2] | You can't write business apps without these widgets .. so ... take it easy Pekr! |
Henrik, don't you see why you're not getting any feedback? You guys shut everyone out for months and now suddenly want their help with feedback. Human nature doesn't respond well to such treatment. | |
Henrik 8-Sep-2010 [3140] | graham, and I posted all the relevant information to validation and dialogs a week ago, the build system 2 weeks ago. zero feedback. |
Pekr 8-Sep-2010 [3141] | when is validation triggered? In DOS app generator I mentioned, there was such a functionality, that you could limit values to type - it was called 'vtg - variable-to-get, and it was used e.g. when you wanted to limit selection to floppy drive A, B values, etc. :-) Nowadays we have list-boxes, but I still can imagine special kind of fields, e.g. Date, IP field with various masks, allowing to type only numbers for e.g. But that would require validation being triggered on per-press basis ... just thinking out loudly .... |
Henrik 8-Sep-2010 [3142x3] | currently validation is triggered on window open to init state. then you can call it on the window as needed and it runs also as a reactor, hence every time a field is unfocused or a button is pressed. it also is triggered on window close, given the button that closes the window is a dialog button. |
as for the type of validation, that is completely customizable. you can also scope validation, so you can say that a panel of fields may not be empty, by adding that option to the panel instead of each field. | |
http://rebol.hmkdesign.dk/files/r3/gui/236.png Materials system is back in (just a quick test) | |
Pekr 8-Sep-2010 [3145] | Cool :-) Cold you please say few words about the material system? What's its purpose, design? Is it more complex/flexible system, or just mostly a gradient/background replacement? thanks .... |
Henrik 8-Sep-2010 [3146] | the purpose is both to eliminate the need for fiddling with colors directly when creating a gradient surface for, say, a button, and both to store material settings, so you can switch quickly between them or select one for a style. so for gradients, instead of working with RGB values (unwieldy), you work with brightness, diffusion and specular. |
Pekr 8-Sep-2010 [3147] | I will try to reshape my question - I am trying to understand the way it is implemented in. Simply put - style is recently represented by one (or in future by multiple switching?) draw blocks. The draw block draws the widget. Now - where's the place for material? Does it somehow overdraws the whole widget (replacing original draw block), or does it influence some of original draw block parameters? |
Henrik 8-Sep-2010 [3148] | the material only represents colors and gradients. it doesn't do anything to the draw block. |
Pekr 8-Sep-2010 [3149] | and also - does material mean a skin? Or is material system going to be part of even more complex/flexible skinning? Note - those are just question, so no offense :-) |
Henrik 8-Sep-2010 [3150x2] | no, material doesn't mean skin. it's only a small part of the skin where you can reference a pre-calculated gradient by name for a single part in the draw block. |
if anything, inspiration was drawn from 3D modelers on how they apply textures and surface to a 3D model. Bolek is working on improving the way that materials are created and used. | |
Pekr 8-Sep-2010 [3152x2] | ok, thanks - now it makes sense ... you can cut those few sentences and add them to Material System: About - section :-) |
but the material (gradient) is still represented by draw, right? I mean - there is no chance for designer to e.g. use some gfx tool, to create some nice material, as it is not convertible to AGG, right? Or would there be any way, via SVG for e.g.? | |
Henrik 8-Sep-2010 [3154] | no, the material system simply calculates a gradient block or a color. then you are free to use it whereever you want. |
Rebolek 8-Sep-2010 [3155] | Pekr, the basic usage is this: set-material face material. Where material is name from list of predefined materials. Of course you can add your own materials. |
Pekr 8-Sep-2010 [3156x3] | I know that I will be able to use it wherever I want. I was just trying to discover possible workflow. E.g. someone does nice Photoshop mock-up, and now you want to cut it down to particular pieces, for particular widgets. So it will mean "gradient hunting" - you will have to reproduce the possible Photoshop effect in draw dialect, am I right? |
Rebolek - I do understand the process. I am trying to find out possible workflow, nothing more .... | |
btw - I expect we will not allow bitmap skinning/material? (I know that it does not scale) | |
Rebolek 8-Sep-2010 [3159] | It's not exactly in draw dialect, but yes, you're right. Of course there's still posibility, that you make your own buttons in Photoshop and just use the bitmaps. |
older newer | first last |