| # | User | Message | Date |
| 339 | Henrik | I figured if it was standardized, maybe the feature can finally get on the move. | Thu 10:44 |
| 338 | Anton | Ah yes, I wanted this at some time in the past. | Thu 10:37 |
| 337 | Henrik | iTunes uses this method to edit multiple songs and I need it in two different database programs. | Thu 10:30 |
| 336 | Henrik | say a list of names, where the selected names are "John", "Carl" and "Danny". with this method you could change them to "Brian" in one go. | Thu 10:29 |
| 335 | Henrik | for example a table where multiple rows are selected for editing. all rows are fed into a single form with each field representing the values from each selected row. click the checkmark to unlock a field and type a new value. when you are done editing, an external commit function would then insert that value in the given field for all selected rows. | Thu 10:29 |
| 334 | Anton | (Use case, that is) | Thu 10:23 |
| 333 | Anton | Real world example ? | Thu 10:23 |
| 332 | Henrik | Some goals: 1. Simple 2. _Really_ simple. No fancy stuff. Largely standard VID. Little flexibility. 3. Standard way of conveying multiple values in a face. 4. Standard way of getting all changes from a panel. 5. Non-destructive manipulation of input values. 6. Allow the construction of new multi-value faces from the base MULTI-FACE. Each MULTI-FACE consists of a CHECK-FACE, READ-FACE and WRITE-FACE. 7. All standard accessors must be usable. 8. Setting multiple values for a face is done by inputting a block rather than a single value. | Thu 10:17 |
| 331 | Henrik | Very preliminary: http://rebol.hmkdesign.dk/files/multivalue.r | Thu 10:12 |
| 330 | Anton | Oh ? What does that do ? | Thu 9:49 |
| 329 | Henrik | Anton, I'm working on a simple way to convey multiple values in the same field using an attached checkmark. Will release some code later today. | Thu 9:41 |
| 328 | Anton | Ok, I think we'll just have to agree to disagree on how important it is. | 24-Sep 17:34 |
| 327 | Henrik | I still think it's much faster to just add [object!] in the FOCUS parameter block. It does not complicate the code. This is my main rule when I write my own code, and it simplifies debugging. The print method can furthermore be very time consuming if you are using the function in 50 different places. | 24-Sep 7:34 |
| 326 | Anton | Henrik, ok, type checking would help in that case to identify where the bug is more quickly - *but*, if you ever get a bug with Near: code that you didn't write, you can, without much extra work, zero in on the expression which causes it just using well-placed print statements, of course. | 24-Sep 3:57 |
| 325 | Anton | Gregg, yes, it kind of depends on how you feel about the code, the position it's in in a source file etc. I agree with the idea that, as a code library matures and "hardens", that it would be good to make type checking more strict. | 24-Sep 3:54 |
| 324 | Gregg | I've tripped myself up with some general lib funcs that don't check type (and then I add it), but I've also gone too far the other way and spec'd type on things that are only used in a very narrow scope, and complicated things needlessly. | 22-Sep 23:50 |
| 323 | Gregg | The wider in scope something is, the more useful it is to have it check arguments (and to behave gracefully in any case). | 22-Sep 23:49 |
| 322 | Henrik | it's simple to trigger: focus 'word | 22-Sep 16:27 |
| 321 | Anton | Where was the line of code that passed the word to FOCUS ? I ask because it's a straightforward matter to track down bugs like this. | 22-Sep 14:33 |
| 320 | Henrik | So I would encourage the change to being more specific about types. | 22-Sep 12:05 |
| 319 | Henrik | Well, I disagree that it's annoying to specify object all the time. I actually am always specific about types in my code, because I can tell where the error originates and catch an incorrect type as early as possible. It takes way shorter time to be specific about the type than it takes to figure out where the code that is being displayed as an error is buried. I discovered that it was related to focus by pure chance and you won't be able to find anything about it in the docs. Furthermore, it writes an incorrect value to system/view/focal-face, so VID basically stops working, until you figure out what to do. | 22-Sep 12:05 |
| 318 | Anton | (and yes, it can obviously trip you up, too.) | 22-Sep 4:54 |
| 317 | Anton | Yes, makes the code clearer. I originally had the same reaction, but when you write lots of functions taking face as an argument, it's annoying to specify [object!] all the time. | 22-Sep 4:53 |
| 316 | Henrik | looking at view-edit.r there are many functions that do no such check. is that appropriate? | 21-Sep 16:11 |
| 315 | Henrik | Shouldn't FOCUS only allow object! for input? I was quite confused for a while, debugging a specific piece of code, when it turned out that I had accidentally passed a word! to FOCUS, and the code fails inside FOCUS instead of at its input. | 21-Sep 16:04 |
| 314 | Anton | (so I can give advice faster next time I'm asked about this...) | 23-Jun 7:14 |
| 313 | Anton | I updated face-flags.txt and added a new doc. http://anton.wildit.net.au/rebol/doc/face-flags.txt http://anton.wildit.net.au/rebol/doc/field-flags-and-focusing.txt | 23-Jun 7:13 |
| 312 | Henrik | many thanks for your help | 23-Jun 7:12 |
| 311 | Anton | Cool. :) I have to go now... | 23-Jun 7:11 |
| 310 | Henrik | wow, now it feels like a real console. :-) amazing what a few lines of code can do. | 23-Jun 7:07 |
| 309 | Henrik | I don't think there is. Some better cursor management will be my next task. It's custom for the field anyway. | 23-Jun 7:04 |
| 308 | Anton | anything missing? | 23-Jun 7:03 |
| 307 | Henrik | very nice | 23-Jun 7:02 |
| 306 | Anton | Aha. Add deflag-face self on-unfocus | 23-Jun 6:57 |
| 305 | Henrik | I've been thinking now, and concluded that action on unfocus is bad behavior. Think about a console where you type in commands and you casually/accidentally click elsewhere. | 23-Jun 6:54 |
| 304 | Anton | Ok. Let me know if there's any behaviour missing. | 23-Jun 6:51 |
| 303 | Henrik | I have to think about that, but I'll try the do-face fix and see if I get the required behavior. | 23-Jun 6:49 |
| 302 | Anton | Is that bad, though ? I mean it's your action. | 23-Jun 6:49 |
| 301 | Anton | Yes, when you click down away from the face the global event handler catches it and unfocuses. | 23-Jun 6:48 |
| 300 | Henrik | when you unfocus with the mouse | 23-Jun 6:48 |
| 299 | Henrik | ah, it prints "action" on unfocus | 23-Jun 6:47 |
| 298 | Anton | The first field is obviously a normal field. | 23-Jun 6:47 |
| 297 | Henrik | whoops, sorry, wrong. | 23-Jun 6:47 |
| 296 | Henrik | it did for the first field the first time, but then it stopped. | 23-Jun 6:47 |
| 295 | Henrik | it does not print "action" here, but that's the only problem so far. | 23-Jun 6:46 |
| 294 | Anton | Does it have the behaviour you were looking for ? | 23-Jun 6:45 |
| 293 | Anton | The fact that you have to modify the engage function is still annoying, of course. | 23-Jun 6:44 |
| 292 | Henrik | so it simply does nothing on return | 23-Jun 6:44 |
| 291 | Anton | If you also wanted to do the face action when enter is pressed, then do it just before 'exit' (do-face face face/data). | 23-Jun 6:40 |
| 290 | Anton | view layout [ field field with [ ; Prevent enter key or tab key moving the focus away. deflag-face self return ; insert newline char instead of cycling focus or doing action refocus: none ; tab key will not cycle focus ] feel [ ; Clone the feel ; Modify the ENGAGE function so a "carriage return" character is ignored. (makes this a single-row field). insert select select second :engage [switch act][key] bind [if event/key = #"^M" [exit]] second second :engage ] [ print "Action" ] field ] | 23-Jun 6:40 |
| 289 | Anton | I think I have the field for you: | 23-Jun 6:38 |
| 288 | Anton | Hi Henrik, I reread our comments on face flags and field focusing issues. (My suggestions were quite poor quality.) So I've reviewed the situation. | 23-Jun 6:38 |
| 287 | Anton | So you can now see the effect of the layout patches I submitted to devbase on 30-May-2008. | 21-Jun 18:50 |
| 286 | Anton | do http://anton.wildit.net.au/rebol/patch/layout-patch.r | 21-Jun 18:40 |
| 285 | Henrik | ah, that's what I wanted to know, thanks | 21-Jun 18:38 |
| 284 | Anton | Here is the layout patch I was working on 30-May-2008 (in this group). This file contains tests for each patch. Open the file, search for "test cases", uncomment the test you want to run, and DO the file: | 21-Jun 18:38 |
| 283 | Anton | While I'm at it... | 21-Jun 18:35 |
| 282 | Anton | It's a VID style, if that's what you mean. | 21-Jun 18:32 |
| 281 | Anton | "plain" ? | 21-Jun 18:31 |
| 280 | Henrik | very cool. and this is plain in VID now? | 21-Jun 18:30 |
| 279 | Anton | do %Users/Henrik/VID/mixed-state-images.r ; and just close the window do http://anton.wildit.net.au/rebol/gui/demo-check-line-mixed.r | 21-Jun 18:25 |
| 278 | Anton | Here is a demo of the experimental CHECK-LINE-MIXED style. | 21-Jun 18:23 |
| 277 | Henrik | I will have a look at that in 30 mins | 21-Jun 18:00 |
| 276 | Anton | My flatmate showed me the librarything.com "Power edit" mode, which allows to edit and set a field for multiple entries at once. When not in "power edit" mode, you can only edit a single field at a time. This means users don't have to learn strange new widget behaviour. (They get a new mode, of course.) | 21-Jun 18:00 |
| 275 | Anton | Oops, I should have made it based on check-line instead of check... | 21-Jun 15:57 |
| 274 | Anton | But I'm going to perservere with check-mixed anyway, for the moment. | 21-Jun 15:37 |
| 273 | Anton | I was just having a discussion with my flatmate about the mixed state. She thought it makes things confusing. Now that I think about it, it seems like the solution you came to with the check-box, meaning "do the same edit for all", is the simplest, and does not require changes to all the other styles. | 21-Jun 15:36 |
| 272 | Anton | :) ok, let's get back to check-mixed... | 21-Jun 14:06 |
| 271 | Henrik | yes, that's the "fun part" | 21-Jun 14:06 |
| 270 | Anton | So you would need other styles to support this mixed state consistently for your application. | 21-Jun 14:06 |
| 269 | Henrik | yes, something like that. | 21-Jun 14:06 |
| 268 | Anton | So the 'mixed' state for FIELD-MIXED could just be the 'grayed out' imagery. | 21-Jun 14:05 |
| 267 | Henrik | yes, that's exactly what I originally wanted to do. | 21-Jun 14:05 |
| 266 | Anton | I know; when mixed, the field can show itself grayed out (similar to 'disabled' state), and its contents is empty. When you type anything in it, it brightens to display as normal and would set all. When you delete all your text, it returns to 'grayed out' and would leave all unaffected. | 21-Jun 14:04 |
| 265 | Henrik | I found a simpler solution in iTunes, which doesn't display anything for mixed state. There's just a checkbox next to each field, so that when you write something in the field and set the checkbox, that sets the value for all selected tunes. If it's unchecked, the value is just ignored. | 21-Jun 13:59 |
| 264 | Anton | We can see this behaviour in the music player Amarok in linux land, when editing mp3 tags for multiple files. | 21-Jun 13:57 |
| 263 | Henrik | but this is very difficult to build a structure from, if you want to support more than just fields, so I steered clear of it. | 21-Jun 13:56 |
| 262 | Henrik | if all strings in the block were identical, they would show as the value. if just one string differs, it would show as mixed state. then when you edited the field, it would set all strings to the same value. | 21-Jun 13:56 |
| 261 | Henrik | the thing was that I would have a list of items in a LIST-VIEW that was tied together with some fields, so whenever you would select one line, it would set-face each field with a string. if there was more than one row selected, the list view would return columns as blocks that each would be fed to the respective field. | 21-Jun 13:55 |
| 260 | Anton | How do you get a field to show multiple texts ? Does it allow you to edit them ? Sounds like getting into complexity there. | 21-Jun 13:52 |
| 259 | Henrik | I gave it up, because I couldn't build a consistent structure from it. Too much work. But maybe now.. ? :-) | 21-Jun 13:51 |
| 258 | Anton | That's right, it would be good if its meaning carries across other styles consistently. | 21-Jun 13:50 |
| 257 | Henrik | but that was more in cooperation with a structure that would work against a database. | 21-Jun 13:50 |
| 256 | Henrik | I had toyed with an idea that you could set-face a field with a block of strings and it would show as mixed state. | 21-Jun 13:50 |
| 255 | Henrik | so if we have this word, it must be consistently used everywhere we allow mixed states. | 21-Jun 13:49 |
| 254 | Anton | (It was worth consideration, anyway.) | 21-Jun 13:49 |
| 253 | Anton | Ok :) | 21-Jun 13:48 |
| 252 | Anton | We're not trying to scrimp and save on words (at least, I'm not.) | 21-Jun 13:48 |
| 251 | Henrik | I give in :-) | 21-Jun 13:48 |
| 250 | Henrik | I don't know. Maybe it should be a word. | 21-Jun 13:48 |
| 249 | Anton | It doesn't really seem appropriate. It is a new state, so give it a new word. That's the approprate thing to do. | 21-Jun 13:48 |
| 248 | Henrik | unset! would be nice, but it's too hard to specify. | 21-Jun 13:47 |
| 247 | Henrik | I know. It just seems like a cop out to resort to words. :-) | 21-Jun 13:46 |
| 246 | Anton | How else are you going to say it ? | 21-Jun 13:41 |
| 245 | Anton | Accessor functions should be coded to respect ALLOW-MIXED-STATE. | 21-Jun 13:40 |
| 244 | Henrik | so, set-face my-check 'mixed ? it seems a little specific for me. | 21-Jun 13:40 |
| 243 | Anton | face/state: on face/state: off face/state: 'mixed | 21-Jun 13:39 |
| 242 | Henrik | how would you SET-FACE a mixed state? | 21-Jun 13:37 |
| 241 | Anton | I'll go with the first one for now. | 21-Jun 13:37 |
| 240 | Anton | (or CAN-BE-MIXED) | 21-Jun 13:36 |
| 239 | Henrik | I agree that a flag would make more sense in all styles where it makes sense to have it. | 21-Jun 13:36 |
| 238 | Anton | Perhaps this flag should be called ALLOW-MIXED-STATE. | 21-Jun 13:35 |
| 237 | Anton | An instance of CHECK-MIXED can sometimes be just like a CHECK, when there is no mixed information available, right ? That means there must be another flag somewhere which allows or disallows entering 'mixed state. I think that should go in face/flags. (I remember Carl was once against using face/flags for style-specific uses, but we can see this concept can be extended to other styles.) | 21-Jun 13:34 |
| 236 | Anton | I'll start with check-mixed. | 21-Jun 13:24 |
| 235 | Anton | Ok, so it looks like I'm going to make a style.... :) | 21-Jun 13:24 |
| 234 | Anton | Surely. | 21-Jun 13:23 |
| 233 | Henrik | now if specifying the state flow was to be implemented as a flag, would a similar behavior be desired or possible for radio? perhaps there are other styles that benefit from your method. | 21-Jun 13:18 |
| 232 | Anton | I would like a way to specify state flow as I've written above. | 21-Jun 13:16 |
| 231 | Anton | I think we should spawn a new 'check-mixed' style and a test file to demonstrate how it should work. | 21-Jun 13:14 |
| 230 | Henrik | yes, that's of course one way to look at it. but there has got to be a way to make it optional. | 21-Jun 13:14 |
| 229 | Anton | So no undo necessary there. | 21-Jun 13:10 |
| 228 | Anton | Not necessarily, because the check (or radio) could be in a form with a submit button. Leaving the check in mixed state, even after clicking through a whole cycle, just means "do nothing" when the submit button is pressed. | 21-Jun 13:10 |
| 227 | Henrik | but a very complicatd one | 21-Jun 13:07 |
| 226 | Anton | It's an interesting form of undo, actually... | 21-Jun 13:06 |
| 225 | Henrik | mixed state represents, in case you want to revert to that mixed state from inside the check-mark, that is | 21-Jun 13:06 |
| 224 | Henrik | in that case, it might be a good idea to allow both state flows. the point would be that you need to remember what the mixed state represents. could be a lot of code. | 21-Jun 13:05 |
| 223 | Anton | I'm sure I've seen that somewhere. | 21-Jun 13:04 |
| 222 | Anton | If the mixed state is there to represent multiple on/off states, then the user could click once to indicate that all states should go 'on', again to indicate all 'off', and again to return to 'mixed' (meaning the multiple on/off states are left unaffected). | 21-Jun 13:04 |
| 221 | Henrik | I've never seen it. | 21-Jun 13:03 |
| 220 | Anton | I think I disagree. Why not ? | 21-Jun 13:02 |
| 219 | Henrik | so the last one you write about should be correct | 21-Jun 13:01 |
| 218 | Henrik | mixed is never a state that can be triggered by the user directly. | 21-Jun 13:00 |
| 217 | Anton | or it could be : mixed --> on -> off -> on | 21-Jun 12:59 |
| 216 | Anton | so when clicking: mixed -> on -> off -> mixed ? | 21-Jun 12:59 |
| 215 | Henrik | I think the usual way is to turn it on, when in a mixed state. | 21-Jun 12:22 |
| 214 | Anton | What should clicking a check do when it has mixed state ? I imagine different applications would like to allow or prevent changing state, and if allowed to specify whether the state should move to 'on' or 'off'. | 21-Jun 12:17 |
| 213 | Anton | Need to figure out the state diagram after adding the new mixed state. | 21-Jun 12:14 |
| 212 | Anton | Ok, so the new images look very nice and consistent to me. | 21-Jun 12:03 |
| 211 | Anton | do Users/Henrik/VID/vid-check.r | 21-Jun 11:52 |
| 210 | Anton | I hope you don't mind me messing about with your file so much. | 21-Jun 11:40 |
| 209 | Anton | mixed-state-images.r | 21-Jun 11:40 |
| 208 | Anton | Hmm.. that file should be renamed to ... | 21-Jun 11:32 |
| 207 | Anton | do Users/Henrik/VID/vid-check.r | 21-Jun 11:11 |
| 206 | Anton | Ok, I'll make a small helper function, I think.. | 21-Jun 10:34 |
| 205 | Henrik | ok, just change it if you want. | 21-Jun 9:05 |
| 204 | Anton | Can't recall what the number is used for.. | 21-Jun 8:58 |
| 203 | Anton | foreach [name image number] svv/image-stock [print name] | 21-Jun 8:34 |
| 202 | Anton | vid-check.r does not insert the images correctly into svv/image-stock. There is a third integer (yes, unexpected) field which you do not take account of. | 21-Jun 8:32 |
| 201 | Henrik | Users/Henrik/VID/vid-check.r | 21-Jun 7:41 |
| 200 | Anton | Do you have a little mockup for your new mixed state images ? | 21-Jun 6:59 |
| 199 | Anton | RADIO and CHECK; It's certainly possible to do. The radio and check styles know and control their own state. I would just make new variant styles of radio and check with the new 'mixed' state in them. | 21-Jun 6:58 |
| 198 | Anton | It's a pity about ACTIVATE-ON-ENTER, how about ACTIVATE-ON-ENTER-KEY ? That destroys any remaining ambiguity about "enter" and "return", which are present in multiple domains. | 21-Jun 6:41 |
| 197 | Anton | It would be good to create one. | 21-Jun 6:35 |
| 196 | Anton | I was never aware of any official doc on face flags. | 21-Jun 6:34 |
| 195 | Henrik | On a different topic, I've made bitmaps for mixed select for RADIO and CHECK. They should artistically match what's there already for the two, but the radio and check mark themselves do not yet support a mixed state. Is that planned or possible for 2.7.7? | 20-Jun 19:59 |
| 194 | Henrik | ACTIVATE-ON-ENTER could be misinterpreted as ACTIVATE-ON-ENTERING-FIELD, I think | 20-Jun 19:56 |
| 193 | Henrik | I agree on longer flag names. Is there one single place those flag names are specified? | 20-Jun 19:47 |
| 192 | Anton | (and the meaning is clearly defined, too.) | 20-Jun 18:06 |
| 191 | Anton | But, with names like the above, we'll no longer have the situation where you look in edit-text, see one of the flags and think: "I'll have to look up that flag." It's better when it's self explanatory. | 20-Jun 18:02 |
| 190 | Anton | or similar. And that's if we're keeping those exact flag semantics. | 20-Jun 18:01 |
| 189 | Anton | FIELD should be HIGHLIGHT-ON-FOCUS RETURN should be ACTIVATE-ON-RETURN (or -ENTER) TABBED should be FOCUS-CYCLE-PARTICIPANT (being verbose here) ON-UNFOCUS should be ACTIVATE-ON-UNFOCUS | 20-Jun 17:59 |
| 188 | Anton | I think their names are poorly chosen; too brief. | 20-Jun 17:55 |
| 187 | Anton | So I think the four face flags, relevant to fields, that currently exist, are: FIELD RETURN TABBED ON-UNFOCUS | 20-Jun 17:55 |
| 186 | Anton | http://anton.wildit.net.au/rebol/doc/face-flags.txt excerpt: FIELD A face with this flag in its face-flags will have its text highlighted when it gains the focus. (See source of FOCUS) RETURN If flagged with RETURN, the focused face's action is done when the Enter key is pressed. (See ctx-text/edit-text) TABBED The face participates in tab-key cycling. (See ctx-text/next-field and ctx-text/back-field) ON-UNFOCUS This has a relationship with FACE/DIRTY? and UNFOCUS as seen in the default global event handler function. See: print mold system/view/screen-face/feel | 20-Jun 17:54 |
| 185 | Anton | Yeah, let's work that in. | 20-Jun 17:48 |
| 184 | Henrik | I use odd tab cycling a lot in forms. More than I would think, when I started doing them, so it's nice to be able to specify them on their 'var name. | 20-Jun 17:47 |
| 183 | Anton | Ah yes, custom next-field and back-field, per face. | 20-Jun 17:45 |
| 182 | Henrik | but from a VID user perspective, I wouldn't mind if unfocus-on-return was specified through defining next-field and back-field to be the face itself. | 20-Jun 17:43 |
| 181 | Henrik | so tabbed should stay and the other thing should be implemented. | 20-Jun 17:42 |
| 180 | Henrik | ah, well that's no good. I can see that. | 20-Jun 17:42 |
| 179 | Anton | Also, pressing tab to focus the next field will not include un-tabbed faces in the search. | 20-Jun 17:39 |
| 178 | Anton | What happens when you remove the tabbed flag from the face is that pressing the tab key inserts a tab char, and no refocusing or action is done. | 20-Jun 17:37 |
| 177 | Anton | It should be defined more clearly, in English. | 20-Jun 17:35 |
| 176 | Anton | I think the meaning of tabbed is "The face participates in tab-key cycling." | 20-Jun 17:34 |
| 175 | Anton | tabbed is implemented only by edit-text, next-field and back-field in ctx-text, I think. | 20-Jun 17:33 |
| 174 | Henrik | wonder what happens if you turn off 'tabbed | 20-Jun 17:30 |
| 173 | Anton | I would think about it more carefully, after first getting some sleep, and reviewing the definitions of the other face flags :) | 20-Jun 17:06 |
| 172 | Anton | OR... | 20-Jun 17:05 |
| 171 | Anton | something like... enter [ if flag-face? face return [ if flag-face? face hide swap-text if flag-face? face unfocus-on-return [focus next-field face] action face face/data exit ] insert-char face newline ] | 20-Jun 17:05 |
| 170 | Anton | I would change that to: | 20-Jun 17:02 |
| 169 | Anton | Let's look at edit-text's enter key handler: enter [ if flag-face? face return [ if flag-face? face hide swap-text if flag-face? face tabbed [focus next-field face] action face face/data exit ] insert-char face newline ] | 20-Jun 17:02 |
| 168 | Anton | (And also to make what can be into static declarations.) | 20-Jun 17:00 |
| 167 | Anton | Yes, the aim is to separate each property. I agree. | 20-Jun 17:00 |
| 166 | Henrik | yes, exactly | 20-Jun 16:59 |
| 165 | Anton | oops - I meant: - unfocus-on-return etc. | 20-Jun 16:59 |
| 164 | Henrik | in short, edit-text does too many thing simultaneously. I would want focusing to be a separable, controllable process. | 20-Jun 16:59 |
| 163 | Henrik | well, I think the action part is OK, it's more when you unfocus. I have created a modified field that allows you to specify the next face to focus by it's 'var, but it does not work if I specity the field itself as the next face to focus, because focusing happens in edit-text. | 20-Jun 16:58 |
| 162 | Anton | ... and edit-text checks for the above flags and calls a corresponding action function in the face. | 20-Jun 16:58 |
| 161 | Anton | Henrik, yes, we need to modify edit-text. | 20-Jun 16:56 |
| 160 | Anton | The clean way, I think, is by adding face flags to field (and field-based) styles. I would add 3 flags: - does-action-on-return - does-action-on-tab - does-action-on-shift-tab (verbose flag names in this example) | 20-Jun 16:55 |
| 159 | Henrik | what if there are more focusable items in the layout, but you don't want it to change? | 20-Jun 16:54 |
| 158 | Anton | The system does the refocusing here print mold get in ctx-text 'edit-text | 20-Jun 16:50 |
| 157 | Anton | I suppose you're just refocusing after the system unfocuses the face? | 20-Jun 16:45 |
| 156 | Henrik | I wonder if there can be made a clean way to avoid dropping focus from a field when pressing enter or tab or shift tab. I have quite a few cases where there is only one field for searching that must never lose focus. My current ways are hacks that cause lots of flickering. | 17-Jun 21:38 |
| 155 | Anton | It's looking very very functional and useful just as it is ! | 11-Jun 18:36 |
| 154 | Henrik | (just 'do the url) | 11-Jun 10:27 |
| 153 | Henrik | http://bolek.techno.cz/reb/request-color.r This is BSD licensed. I wonder if we can prettify it and perhaps simplify it a bit to get a (usable) color requester. | 11-Jun 10:27 |
| 152 | Anton | I've already got test cases for each patch - I just need to publish them. | 31-May 17:25 |
| 151 | Henrik | yes, that works. perhaps you should do some test cases for each patch so Carl can very quickly test the patch | 31-May 6:24 |
| 150 | Anton | No, not correct to do it in a console. But you can DO this: http://anton.wildit.net.au/rebol/patch/tog-patch.r | 31-May 2:12 |
| 149 | Henrik | I think I'm applying the patch wrong... | 30-May 19:14 |
| 148 | Henrik | Anton, I'm looking at your TOG patch. Is it correct to just DO it in a console and try it out? Anyway, what happened was that I tested it with a few TOGs in a layout and tried dragging out of the TOG while holding the mouse down and the highlight stays. | 30-May 19:00 |
| 147 | Henrik | very nice | 30-May 15:48 |
| 146 | Anton | For now, faces which make errors in their INIT still make it into the pane. Maybe it's best not to allow such faces into the pane ? Let's just see how it flies. | 30-May 12:20 |
| 145 | Anton | And LAYOUT now traps and reports errors in INIT (so it is somewhat tolerant of errors) as I have shown above (on Thursday). | 30-May 12:18 |
| 144 | Anton | >> stylize [b: button m: "munchkin" 10x10 a: area] **** Invalid style for: m ** VID Phrase: [m: "munchkin" 10x10] **** No such style: "munchkin" ** VID Phrase: [m: "munchkin" 10x10] ** Script Error: Cannot use path on none! value ** Where: forskip ** Near: forall args [ if any [ find facet-words first args all [old-face/words find old-face/words first ar... | 30-May 12:12 |
| 143 | Anton | STYLIZE is also improved: | 30-May 12:11 |
| 142 | Anton | >> layout [button "hello" indent "munchkin" 3x3 field] **** Expected position or size, not: "munchkin" ** VID Phrase: [indent "munchkin" 3x3] ** Script Error: Invalid path value: x ** Where: forever ** Near: pos/x | 30-May 12:11 |
| 141 | Anton | (for now at least.) Now you get back a VID "Phrase", showing the part in the dialect spec block where the grammar error was detected. | 30-May 12:10 |
| 140 | Anton | Submitted patches to rework error reporting in LAYOUT. Hooray ! (The madness is over.) | 30-May 12:05 |
| 139 | Anton | But I won' t be distracted until what I'm working on now has been submitted. | 30-May 4:09 |
| 138 | Anton | You mean the part of the BrianH's resize code which patches layout ? BrianH's patch does not interact with my patches, which is good. | 30-May 4:09 |
| 137 | Henrik | I wonder if it's a good time to take another look at the resize patch? | 29-May 16:32 |
| 136 | Henrik | nice :-) | 29-May 16:31 |
| 135 | Anton | Lots of good error reporting now. | 29-May 14:45 |
| 134 | Anton | ... patching patching ... | 29-May 14:44 |
| 133 | Henrik | some separators, agree | 28-May 19:14 |
| 132 | Henrik | ah, I thought you did that with LIST on purpose. :-) | 28-May 19:13 |
| 131 | Anton | Reading the above errors makes you go a bit cross-eyed, though. I think I'll put in a visual separator of some sort. | 28-May 17:51 |
| 130 | Anton | Yes, both are INIT errors. The LIST's default INIT can't handle an uninitialized LIST. It assumes a few facets have been specified. I'll probably patch the four styles which have this problem soon. | 28-May 17:49 |
| 129 | Henrik | so there's an error in init for FACE and an error in the style internally in LIST? | 28-May 17:30 |
| 128 | Anton | How does this look: >> layout [button face with [init: [1 / 0]] 10x20 black white list area] ** Error in init of style: face ** Math Error: Attempt to divide by zero ** Where: forever ** Near: 1 / 0 ** VID phrase: [face with [init: [1 / 0]] 10x20 black white] ** Error in init of style: list ** Script Error: second expected series argument of type: series pair event money date object port time tuple any-function struct event ** Where: forever ** Near: subface: layout/parent/origin/styles second :action blank-face ** VID phrase: [list] | 28-May 17:08 |
| 127 | Anton | Yes, that's a good example. | 28-May 13:50 |
| 126 | Henrik | view layout [button button none button none button] Unrecognized parameter: none Unrecognized parameter: none | 28-May 13:45 |
| 125 | Henrik | for example when none is used where it shouldn't. I hope you see what I mean. | 28-May 13:45 |
| 124 | Anton | Hmm.. I'll see what I can do with that. | 28-May 13:44 |
| 123 | Anton | For instance, you can do layout [face] layout [blank-face] layout [list] | 28-May 13:42 |
| 122 | Henrik | what annoys me the most is that LAYOUT does not report where an error exists in the layout. | 28-May 13:41 |
| 121 | Henrik | can you describe how it handles uninitialized style instances? | 28-May 13:40 |
| 120 | Anton | I'm on the verge of submitting a patch to LAYOUT, which would allow it to handle uninitialized style instances, and handle errors in init as well. What's holding me up is what to call the error reporting function, and where it should be put, because svv already has an error reporting function that doesn't quite do what I want. | 28-May 13:34 |
| 119 | Henrik | forgot your response on shift-tabbing out to avoid validation. yes, I agree as it only is confusing. | 25-May 17:32 |
| 118 | Henrik | cool | 25-May 17:31 |
| 117 | Anton | I've submitted to DevBase some of the patches we discussed here in April. | 25-May 17:14 |
| 116 | Anton | Ah.. could add some keywords ('focus and 'unfocus) to the layout dialect. That should make it simple for both our ways. | 25-May 17:12 |
| 115 | Henrik | I see. | 25-May 8:23 |
| 114 | Anton | Note that the reason I've put the functions in the feel is for automatic sharing. When you put the functions directly in the face, every instance gets a clone of those functions, so the memory used increases. Typically, once you've designed a style, its functions remain the same, so it makes sense to share them. | 25-May 6:43 |
| 113 | Henrik | thanks for your help | 24-May 17:28 |
| 112 | Henrik | but I think I solved my problem in my own patch and since it's already integrated, I'm going to keep with that one. | 24-May 17:28 |
| 111 | Henrik | I would like to see something like view layout [field focus [set-face face "focused!"]] eventually. | 24-May 17:27 |
| 110 | Henrik | yes, I'm precisely hmm'ing over that. :-) | 24-May 17:26 |
| 109 | Anton | You're probably 'hmming' about the lengthy spec. I understand this concern. It's possible to make a face dialect to allow a simple "one block" action block specification, but I never got around to this, as it would have to be done for every style. | 24-May 17:17 |
| 108 | Henrik | hmm, ok. thanks. | 24-May 17:15 |
| 107 | Anton | Anyway, once the focus and unfocus functions are redefined, you can set the focus-action function in the feel. eg: view layout [field feel [focus-action: func [face /scroll /animate /no-show][print "got focus"]]] | 24-May 17:14 |
| 106 | Henrik | in my own patch, that is. | 24-May 17:13 |
| 105 | Henrik | I think my patch should essentially do the same that DO-FACE does. that's probably my issue here. | 24-May 17:13 |
| 104 | Anton | Yes, sorry, I don't seem to have a specific demo script available for focus-system-patch.r | 24-May 17:11 |
| 103 | Henrik | I'm not sure how one applies a specific focus action to a specific face in your code. | 24-May 17:11 |
| 102 | Anton | It essentially only modifies FOCUS and UNFOCUS. | 24-May 17:05 |
| 101 | Anton | It does not affect LAYOUT. | 24-May 17:03 |
| 100 | Henrik | is it integrated in layout? | 24-May 17:03 |
| 99 | Anton | I've been planning to do this patch for a while. | 24-May 17:03 |
| 98 | Anton | Instead, face/feel/focus-action or face/feel/unfocus-action are called. | 24-May 17:02 |
| 97 | Henrik | oh, I gotta try this. thanks. :-) | 24-May 17:02 |
| 96 | Anton | It allows to completely sidestep the old FOCUS and UNFOCUS code. | 24-May 17:01 |
| 95 | Henrik | it does the same thing? | 24-May 17:01 |
| 94 | Anton | But I have focus-system-patch.r, working well for a long time. | 24-May 17:00 |
| 93 | Anton | But the WITH block extends the PANEL spec, so those action blocks should just refer to SELF. | 24-May 17:00 |
| 92 | Henrik | I need to see the code that performs ACTION for face. It should do the same thing. | 24-May 16:59 |
| 91 | Henrik | that might be the problem. | 24-May 16:59 |
| 90 | Anton | Do you pass FACE to those functions ? If not, then why should they recognise face ? | 24-May 16:59 |
| 89 | Henrik | FOCUS-ACTION runs an action for a face when the face has been set to system/view/focal-face. UNFOCUS-ACTION runs an action for a face after the face is no longer set to system/view/focal-face. | 24-May 16:51 |
| 88 | Henrik | Anton, perhaps you know what the problem can be: I try to focus a panel, so I can perform keyboard navigation inside it, but the FOCUS-ACTION block I added like this: stylize/master [ panel: panel with [focus-action: none unfocus-action: none] ] does not recognize FACE. It would seem like a binding issue and I'm probably not doing it correctly. | 24-May 16:50 |
| 87 | Henrik | I've added two lines of code to FOCUS and UNFOCUS. They allow me to run FOCUS-ACTION and UNFOCUS-ACTION inside any face that has these two blocks. It seems like a very simple patch, but I've hit a few problems with it. Still if I can get past this, I think it's worth adding. | 24-May 16:48 |
| 86 | Anton | field action - some people wanted a way to avoid validation (which could be a significant delay, I suppose, like a search/database/network operation) so the shift-tab was wanted to "reverse out". I thought it was inconsistent and didn't like it. | 24-May 16:47 |
| 85 | Anton | And "backcolor none". | 24-May 16:43 |
| 84 | Henrik | for FIELD, what's the logic in not running the field action when using SHIFT-TAB? | 22-May 16:26 |
| 83 | Henrik | I miss that. | 9-May 7:15 |
| 82 | Henrik | very small thing: Allow the use of "backdrop none" to set the background color to none to make a panel transparent. | 9-May 7:15 |
| 81 | BrianH | Same here (for the moment) :( | 22-Apr 15:04 |
| 80 | Anton | Yes, I know. I'm just too busy to dive into DevBase just yet... :) | 21-Apr 15:59 |
| 79 | BrianH | :) | 21-Apr 2:50 |
| 78 | BrianH | The source is in DevBase. You don't need to patch it, you can fix it. For that matter, changes to layout are planned. | 21-Apr 2:47 |
| 77 | Anton | (but layout is complex, and that would just bloat it up a bit more...) | 20-Apr 4:26 |
| 76 | Anton | or actually, maybe better to patch layout so it tolerates a none init. | 20-Apr 4:25 |
| 75 | Anton | oh, and svv/vid-styles/face/size: 100x100 (or at least 0x0) | 20-Apr 4:25 |
| 74 | Anton | svv/vid-styles/face/init: [] (currently it is none, which hampers experimenting) | 20-Apr 4:21 |
| 73 | BTiffin | Yes it does indeed. | 14-Apr 0:28 |
| 72 | Paul | Anton, that has a great feel to it. | 13-Apr 12:52 |
| 71 | Anton | text-list-update-step-patch.r
28-Apr-2006 Anton Rolls
This patches the text-list style update function to recalculate step: use [code body face][ code: [sld/step: 1 / ((1 + length? data) - lc)] if not find body: second get in face: svv/vid-styles/text-list 'update code [ insert body bind code face ] ] view layout [ text-list 50x55 data [1 2 3 4 5 6 7 8 9 10] with [ append init [update] ] ] | 13-Apr 8:15 |
| 70 | Anton | Probably a good idea to clone the para for the AREA style, as Ashley has done, above.
I also think the default "selected" colour for area should be much closer to the "unselected" colour.
I've done this, eg:
stylize/master [area: area snow white] rationale: The contrast between the pen colour and the background is increased when selected, and fades away a little bit when unselected. | 8-Apr 10:09 |
| 69 | Anton | ; Change the built-in EDITOR background colour ;if block? ctx-edit [ctx-edit: context ctx-edit] ;ctx-edit/t1/color: 180.171.158 ; might be better to modify ctx-edit as a block without making ctx insert find/tail third find ctx-edit [ed-lo:][t1: area] 180.171.158 ; assumes ctx-edit is still a block | 8-Apr 9:28 |
| 68 | Anton | Patches to inbuilt EDITOR: http://anton.wildit.net.au/rebol/patch/ctx-edit-patch.r | 8-Apr 9:27 |
| 67 | Ashley | My essential VID2 fixes included: refresh-list: func [face /update-row update-data /insert-row insert-data /delete-row] [ either update-row [ replace face/data face/picked/1 update-data ][ either insert-row [ insert face/data insert-data ][ if delete-row [remove find face/data face/picked/1] ] clear face/picked face/sld/data: 0 face/sn: 0 face/sld/redrag face/lc / max 1 length? head face/lines ] show face ] fix-slider: func [faces [object! block!]] [ foreach list to-block faces [ list/sld/redrag list/lc / max 1 length? head list/lines ] ] stylize/master [ area: area wrap with [insert tail init [para: make para []]] ; scroll bug ] system/view/vid/vid-face/color: x ; to change default background change svv/vid-styles/text-list/init/75/4/6 x ; to change default text-list selected color | 7-Apr 12:04 |
| 66 | Henrik | are there fixes or changes to the built-in text list? | 26-Mar 22:03 |
| 65 | Henrik | Pekr, there are many, many fixes to VID lurking around. It would be a good idea to review them for inclusion in 2.7.7. | 26-Mar 17:59 |
| 64 | BrianH | This is the backwards-compatibility world. | 26-Mar 17:42 |
| 63 | BrianH | Fix, not redesign. | 26-Mar 17:42 |
| 62 | Pekr | So you guys plan on updating VID? Does it make sense? I will read the discussion now. Because - Bobik is still waiting, when do we fix text-list multiline selection :-) I wonder what makes sense to fix, as one big fix to VID is VID3 :-) | 26-Mar 17:40 |
| 61 | Pekr | Ah, I thought View 2.7.7., or who knows what I thought :-) | 26-Mar 17:39 |
| 60 | Henrik | pekr, sure but I don't know where you want it in VID (hint: group name) :-) | 26-Mar 17:23 |
| 59 | BrianH | We have been discussing just that in the DB 2.7.7 group. | 26-Mar 17:23 |
| 58 | Pekr | Do you think it would be possible to get ODBC3 support into 2.7.7? That would somehow "complete" DB support - library is free now, so we've got SQLite, but few others do work via ODBC. | 26-Mar 17:22 |
| 57 | BrianH | Unambiguous enough anyways. There are a few other "Brian Hawley"s on the web. Fortunately the domain was available. | 26-Mar 16:46 |
| 56 | Anton | Well, that's good news. A totally unambiguous domain for you. | 26-Mar 16:40 |
| 55 | BrianH | Strange that you would mention the web page; I have just been given a domain: brianhawley.com. I will be setting up a site there as soon as I can (less soon than you think though, I am busy). | 26-Mar 16:38 |
| 54 | Anton | Well, it gets my approval. | 26-Mar 16:38 |
| 53 | BrianH | It will definitely come in handy if we decide to incorporate the code into VID2, since the integration code would disappear and the propagation code would likely be changed as a result. Plus, the resize model may be adjusted to better fit VID3's. | 26-Mar 16:36 |
| 52 | Anton | It deserves a web page... :) | 26-Mar 16:35 |
| 51 | Anton | That is definitely a good characteristic. | 26-Mar 16:34 |
| 50 | BrianH | The best part is that the resize model, the propagation code and the integration code are pretty seperate. You could change each of them independently without affecting either of the other two. | 26-Mar 16:33 |
| 49 | Anton | It's obviously had a good deal of thought put into it. | 26-Mar 16:31 |
| 48 | BrianH | I rewrote it from scratch at least 5 times :) | 26-Mar 16:30 |
| 47 | Anton | I've done a few simple tests and the system looks good so far. | 26-Mar 16:29 |
| 46 | Anton | Your dev-resize.r code looks very good, Brian. | 26-Mar 16:05 |
| 45 | BrianH | We should get them involved too. | 26-Mar 15:51 |
| 44 | Anton | Allen Kamp. DideC, ... | 26-Mar 15:50 |
| 43 | BrianH | Aside from you and Henrik, who are the other VID2 heavy hitters? | 26-Mar 15:42 |
| 42 | BrianH | See, I liked that patch :) | 26-Mar 15:41 |
| 41 | Anton | I think that layout patch to call the init block stands on its own two feet; you can probably get that integrated all by itself because its doing "the right thing". | 26-Mar 15:40 |
| 40 | Anton | You mean to avoid a common resize function binding itself over and over to each face in a deeply nested face hierarchy ? | 26-Mar 15:38 |
| 39 | BrianH | I like the resize accessor principle, as long as it is fast. Resize code should be delegated to prevent bind/copy explosion. | 26-Mar 15:35 |
| 38 | Anton | Ah yes. Those styles should try to standardise. | 26-Mar 15:33 |
| 37 | BrianH | The dev-resize code has to patch around the few styles that handle their own resizing. That code could be integrated. | 26-Mar 15:31 |
| 36 | Anton | That's right. | 26-Mar 15:31 |
| 35 | BrianH | I found out that the non-window faces don't actually catch resize events. The resize accessor concept was added in 1.3, but never implemented. | 26-Mar 15:29 |
| 34 | BrianH | The real trick is getting existing VID programmers involved so we can head off incompatibilities. | 26-Mar 15:28 |
| 33 | Anton | I remember I had an idea which tried to minimize the difference between window faces and non-window faces, which simplifies resizing. I remember I didn't like window faces using a different method than non-window faces for catching resize events. | 26-Mar 15:27 |
| 32 | BrianH | Henrik says that it follows the OS X resize model, but it could probably be adjusted to follow the VID 3 resize model instead. | 26-Mar 15:26 |
| 31 | Anton | Agree. | 26-Mar 15:26 |
| 30 | BrianH | There are a lot of ways that I could clean it up if it could be built into VID. The existing VID resize code is half-implemented and broken. | 26-Mar 15:25 |
| 29 | Anton | I review it now. | 26-Mar 15:24 |
| 28 | BrianH | Yes, in the DevBase category for now. dev-resize. | 26-Mar 15:24 |
| 27 | Anton | It's in DevBase isn't it ? | 26-Mar 15:23 |
| 26 | Anton | I did look at it a bit... but I can't remember exactly what I thought. | 26-Mar 15:23 |
| 25 | BrianH | Did you look at the resize code? I don't recall you commenting on it when it was being developed. What do you think? | 26-Mar 15:22 |
| 24 | BrianH | Darn. Simpler fixes then :( | 26-Mar 15:21 |
| 23 | Anton | I wouldn't really like that to be part of default rebol, I think. | 26-Mar 15:18 |
| 22 | Anton | Not so simple. My replacement is large. Replacing the face/text rendering system was long and complex. | 26-Mar 15:18 |
| 21 | BrianH | Aren't you working on an editor? Use that if it's better. | 26-Mar 15:18 |
| 20 | BrianH | Replace the editor then. It's a fairly self-contained piece of code that can be completely swapped out. | 26-Mar 15:17 |
| 19 | BrianH | Do you know who the other heavy hitters in the VID developer community are? | 26-Mar 15:16 |
| 18 | Anton | I'm not sure it's worth fixing the R2 editor. There are a few little things that could be done to it, but in the end, it suffers from poor performance when scrolling large texts due to the underlying face/text render system. | 26-Mar 15:16 |
| 17 | BrianH | I am only familiar with VID through having to study the source of it during the resize integration project. | 26-Mar 15:16 |
| 16 | BrianH | In the core VID code it would help if you would sort these into fixes and extensions. As for the editor, rewrite it if you like :) | 26-Mar 15:14 |
| 15 | BrianH | Both are welcome. | 26-Mar 15:13 |
| 14 | Anton | Some are fixes, yes. Many are extensions. | 26-Mar 15:12 |
| 13 | BrianH | For that matter, do you think you could improve the R2 editor? | 26-Mar 14:30 |
| 12 | BrianH | Are some of those hacks fixes? We could incorporate the fixes right into VID. | 26-Mar 14:29 |
| 11 | Anton | I've been hacking VID every which way. | 26-Mar 14:06 |
| 10 | BrianH | I can only think of the bugs I discovered while I was integrating the resize code. | 24-Mar 13:41 |
| 9 | BrianH | Actually, that may be a good idea anyways. They would have a good idea about what needs fixing the most. | 24-Mar 13:40 |
| 8 | BrianH | There can't be too many in the REBOL community who develop these kind of hacks - that kind of thing is difficult to think about. There may not be more than a handful. It might be feasible to ask most of them. | 24-Mar 13:38 |
| 7 | Henrik | but things like resizing and properly unified accessors for all faces would make some things a lot simpler. | 24-Mar 13:36 |
| 6 | BrianH | Who are the major VID developers who make these kind of patches? Some of these are commercial. We need to ask them before we break the apps they are writing for a living. | 24-Mar 13:36 |
| 5 | Henrik | It's hard to say, since I think 75% of VID users, somehow hack VID to make it do what they need. Practically anything I do, uses some kind of hack. | 24-Mar 13:35 |
| 4 | BrianH | If we make fixes, how much breaks? | 24-Mar 13:34 |
| 3 | BrianH | There is a lot of code out there that patches VID at runtime. I know, that kind of thing was a bad idea, but when we couldn't fix the code otherwise it was our only choice. Now that we can fix VID in theory, that kind of thing is going to be a problem. | 24-Mar 13:33 |
| 2 | Henrik | We also need to implement BrianH's new window resize scheme. | 24-Mar 13:04 |
| 1 | Henrik | I'm wondering about some inconsistencies in VID, that I think might be simple to fix. For example INFO does not support being CLEAR-FACEd while it's in a panel, while FIELD does. Since I see INFO being a read-only version of FIELD, I think they should support the same accessors. | 24-Mar 13:04 |