| # | User | Message | Date |
| 342 | Anton | I agree, the cache should probably be located somewhere like system/view/image-cache | 2-Mar-09 8:53 |
| 341 | Oldes | the image-cache is defined as local for this function, so it's not easy to clear it or clear just parts of it. This function is used for example if you do: layut [image some-image] or probably in other places as well. | 21-Feb-09 13:33 |
| 340 | Oldes | I'm not using VID much, but this looks like not nice piece of code: set 'load-image func [ "Load an image through an in-memory image cache." image-file [file! url!] "Local file or remote URL" /update "Force update from source site" /clear "Purge the entire cache" /local image image-cache ][ image-cache: [] ; static block if clear [system/words/clear image-cache recycle] if any [update not image: select image-cache image-file] [ if all [update image] [remove/part find image-cache image-file 2] repend image-cache [ image-file image: either file? image-file [load image-file][ either update [load-thru/binary/update image-file][load-thru/binary image-file] ] ] ] image ] | 21-Feb-09 13:31 |
| 339 | Henrik | I figured if it was standardized, maybe the feature can finally get on the move. | 9-Oct-08 10:44 |
| 338 | Anton | Ah yes, I wanted this at some time in the past. | 9-Oct-08 10:37 |
| 337 | Henrik | iTunes uses this method to edit multiple songs and I need it in two different database programs. | 9-Oct-08 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. | 9-Oct-08 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. | 9-Oct-08 10:29 |
| 334 | Anton | (Use case, that is) | 9-Oct-08 10:23 |
| 333 | Anton | Real world example ? | 9-Oct-08 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. | 9-Oct-08 10:17 |
| 331 | Henrik | Very preliminary: http://rebol.hmkdesign.dk/files/multivalue.r | 9-Oct-08 10:12 |
| 330 | Anton | Oh ? What does that do ? | 9-Oct-08 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. | 9-Oct-08 9:41 |
| 328 | Anton | Ok, I think we'll just have to agree to disagree on how important it is. | 24-Sep-08 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-08 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-08 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-08 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-08 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-08 23:49 |
| 322 | Henrik | it's simple to trigger: focus 'word | 22-Sep-08 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-08 14:33 |
| 320 | Henrik | So I would encourage the change to being more specific about types. | 22-Sep-08 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-08 12:05 |
| 318 | Anton | (and yes, it can obviously trip you up, too.) | 22-Sep-08 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-08 4:53 |
| 316 | Henrik | looking at view-edit.r there are many functions that do no such check. is that appropriate? | 21-Sep-08 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-08 16:04 |
| 314 | Anton | (so I can give advice faster next time I'm asked about this...) | 23-Jun-08 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-08 7:13 |
| 312 | Henrik | many thanks for your help | 23-Jun-08 7:12 |
| 311 | Anton | Cool. :) I have to go now... | 23-Jun-08 7:11 |
| 310 | Henrik | wow, now it feels like a real console. :-) amazing what a few lines of code can do. | 23-Jun-08 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-08 7:04 |
| 308 | Anton | anything missing? | 23-Jun-08 7:03 |
| 307 | Henrik | very nice | 23-Jun-08 7:02 |
| 306 | Anton | Aha. Add deflag-face self on-unfocus | 23-Jun-08 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-08 6:54 |
| 304 | Anton | Ok. Let me know if there's any behaviour missing. | 23-Jun-08 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-08 6:49 |
| 302 | Anton | Is that bad, though ? I mean it's your action. | 23-Jun-08 6:49 |
| 301 | Anton | Yes, when you click down away from the face the global event handler catches it and unfocuses. | 23-Jun-08 6:48 |
| 300 | Henrik | when you unfocus with the mouse | 23-Jun-08 6:48 |
| 299 | Henrik | ah, it prints "action" on unfocus | 23-Jun-08 6:47 |
| 298 | Anton | The first field is obviously a normal field. | 23-Jun-08 6:47 |
| 297 | Henrik | whoops, sorry, wrong. | 23-Jun-08 6:47 |
| 296 | Henrik | it did for the first field the first time, but then it stopped. | 23-Jun-08 6:47 |
| 295 | Henrik | it does not print "action" here, but that's the only problem so far. | 23-Jun-08 6:46 |
| 294 | Anton | Does it have the behaviour you were looking for ? | 23-Jun-08 6:45 |
| 293 | Anton | The fact that you have to modify the engage function is still annoying, of course. | 23-Jun-08 6:44 |
| 292 | Henrik | so it simply does nothing on return | 23-Jun-08 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-08 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-08 6:40 |
| 289 | Anton | I think I have the field for you: | 23-Jun-08 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-08 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-08 18:50 |
| 286 | Anton | do http://anton.wildit.net.au/rebol/patch/layout-patch.r | 21-Jun-08 18:40 |
| 285 | Henrik | ah, that's what I wanted to know, thanks | 21-Jun-08 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-08 18:38 |
| 283 | Anton | While I'm at it... | 21-Jun-08 18:35 |
| 282 | Anton | It's a VID style, if that's what you mean. | 21-Jun-08 18:32 |
| 281 | Anton | "plain" ? | 21-Jun-08 18:31 |
| 280 | Henrik | very cool. and this is plain in VID now? | 21-Jun-08 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-08 18:25 |
| 278 | Anton | Here is a demo of the experimental CHECK-LINE-MIXED style. | 21-Jun-08 18:23 |
| 277 | Henrik | I will have a look at that in 30 mins | 21-Jun-08 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-08 18:00 |
| 275 | Anton | Oops, I should have made it based on check-line instead of check... | 21-Jun-08 15:57 |
| 274 | Anton | But I'm going to perservere with check-mixed anyway, for the moment. | 21-Jun-08 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-08 15:36 |
| 272 | Anton | :) ok, let's get back to check-mixed... | 21-Jun-08 14:06 |
| 271 | Henrik | yes, that's the "fun part" | 21-Jun-08 14:06 |
| 270 | Anton | So you would need other styles to support this mixed state consistently for your application. | 21-Jun-08 14:06 |
| 269 | Henrik | yes, something like that. | 21-Jun-08 14:06 |
| 268 | Anton | So the 'mixed' state for FIELD-MIXED could just be the 'grayed out' imagery. | 21-Jun-08 14:05 |
| 267 | Henrik | yes, that's exactly what I originally wanted to do. | 21-Jun-08 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-08 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-08 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-08 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-08 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-08 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-08 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-08 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-08 13:51 |
| 258 | Anton | That's right, it would be good if its meaning carries across other styles consistently. | 21-Jun-08 13:50 |
| 257 | Henrik | but that was more in cooperation with a structure that would work against a database. | 21-Jun-08 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-08 13:50 |
| 255 | Henrik | so if we have this word, it must be consistently used everywhere we allow mixed states. | 21-Jun-08 13:49 |
| 254 | Anton | (It was worth consideration, anyway.) | 21-Jun-08 13:49 |
| 253 | Anton | Ok :) | 21-Jun-08 13:48 |
| 252 | Anton | We're not trying to scrimp and save on words (at least, I'm not.) | 21-Jun-08 13:48 |
| 251 | Henrik | I give in :-) | 21-Jun-08 13:48 |
| 250 | Henrik | I don't know. Maybe it should be a word. | 21-Jun-08 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-08 13:48 |
| 248 | Henrik | unset! would be nice, but it's too hard to specify. | 21-Jun-08 13:47 |
| 247 | Henrik | I know. It just seems like a cop out to resort to words. :-) | 21-Jun-08 13:46 |
| 246 | Anton | How else are you going to say it ? | 21-Jun-08 13:41 |
| 245 | Anton | Accessor functions should be coded to respect ALLOW-MIXED-STATE. | 21-Jun-08 13:40 |
| 244 | Henrik | so, set-face my-check 'mixed ? it seems a little specific for me. | 21-Jun-08 13:40 |
| 243 | Anton | face/state: on face/state: off face/state: 'mixed | 21-Jun-08 13:39 |
| 242 | Henrik | how would you SET-FACE a mixed state? | 21-Jun-08 13:37 |
| 241 | Anton | I'll go with the first one for now. | 21-Jun-08 13:37 |
| 240 | Anton | (or CAN-BE-MIXED) | 21-Jun-08 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-08 13:36 |
| 238 | Anton | Perhaps this flag should be called ALLOW-MIXED-STATE. | 21-Jun-08 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-08 13:34 |
| 236 | Anton | I'll start with check-mixed. | 21-Jun-08 13:24 |
| 235 | Anton | Ok, so it looks like I'm going to make a style.... :) | 21-Jun-08 13:24 |
| 234 | Anton | Surely. | 21-Jun-08 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-08 13:18 |
| 232 | Anton | I would like a way to specify state flow as I've written above. | 21-Jun-08 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-08 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-08 13:14 |
| 229 | Anton | So no undo necessary there. | 21-Jun-08 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-08 13:10 |
| 227 | Henrik | but a very complicatd one | 21-Jun-08 13:07 |
| 226 | Anton | It's an interesting form of undo, actually... | 21-Jun-08 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-08 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-08 13:05 |
| 223 | Anton | I'm sure I've seen that somewhere. | 21-Jun-08 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-08 13:04 |
| 221 | Henrik | I've never seen it. | 21-Jun-08 13:03 |
| 220 | Anton | I think I disagree. Why not ? | 21-Jun-08 13:02 |
| 219 | Henrik | so the last one you write about should be correct | 21-Jun-08 13:01 |
| 218 | Henrik | mixed is never a state that can be triggered by the user directly. | 21-Jun-08 13:00 |
| 217 | Anton | or it could be : mixed --> on -> off -> on | 21-Jun-08 12:59 |
| 216 | Anton | so when clicking: mixed -> on -> off -> mixed ? | 21-Jun-08 12:59 |
| 215 | Henrik | I think the usual way is to turn it on, when in a mixed state. | 21-Jun-08 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-08 12:17 |
| 213 | Anton | Need to figure out the state diagram after adding the new mixed state. | 21-Jun-08 12:14 |
| 212 | Anton | Ok, so the new images look very nice and consistent to me. | 21-Jun-08 12:03 |
| 211 | Anton | do Users/Henrik/VID/vid-check.r | 21-Jun-08 11:52 |
| 210 | Anton | I hope you don't mind me messing about with your file so much. | 21-Jun-08 11:40 |
| 209 | Anton | mixed-state-images.r | 21-Jun-08 11:40 |
| 208 | Anton | Hmm.. that file should be renamed to ... | 21-Jun-08 11:32 |
| 207 | Anton | do Users/Henrik/VID/vid-check.r | 21-Jun-08 11:11 |
| 206 | Anton | Ok, I'll make a small helper function, I think.. | 21-Jun-08 10:34 |
| 205 | Henrik | ok, just change it if you want. | 21-Jun-08 9:05 |
| 204 | Anton | Can't recall what the number is used for.. | 21-Jun-08 8:58 |
| 203 | Anton | foreach [name image number] svv/image-stock [print name] | 21-Jun-08 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-08 8:32 |
| 201 | Henrik | Users/Henrik/VID/vid-check.r | 21-Jun-08 7:41 |
| 200 | Anton | Do you have a little mockup for your new mixed state images ? | 21-Jun-08 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-08 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-08 6:41 |
| 197 | Anton | It would be good to create one. | 21-Jun-08 6:35 |
| 196 | Anton | I was never aware of any official doc on face flags. | 21-Jun-08 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-08 19:59 |
| 194 | Henrik | ACTIVATE-ON-ENTER could be misinterpreted as ACTIVATE-ON-ENTERING-FIELD, I think | 20-Jun-08 19:56 |
| 193 | Henrik | I agree on longer flag names. Is there one single place those flag names are specified? | 20-Jun-08 19:47 |
| 192 | Anton | (and the meaning is clearly defined, too.) | 20-Jun-08 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-08 18:02 |
| 190 | Anton | or similar. And that's if we're keeping those exact flag semantics. | 20-Jun-08 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-08 17:59 |
| 188 | Anton | I think their names are poorly chosen; too brief. | 20-Jun-08 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-08 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-08 17:54 |
| 185 | Anton | Yeah, let's work that in. | 20-Jun-08 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-08 17:47 |
| 183 | Anton | Ah yes, custom next-field and back-field, per face. | 20-Jun-08 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-08 17:43 |
| 181 | Henrik | so tabbed should stay and the other thing should be implemented. | 20-Jun-08 17:42 |
| 180 | Henrik | ah, well that's no good. I can see that. | 20-Jun-08 17:42 |
| 179 | Anton | Also, pressing tab to focus the next field will not include un-tabbed faces in the search. | 20-Jun-08 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-08 17:37 |
| 177 | Anton | It should be defined more clearly, in English. | 20-Jun-08 17:35 |
| 176 | Anton | I think the meaning of tabbed is "The face participates in tab-key cycling." | 20-Jun-08 17:34 |
| 175 | Anton | tabbed is implemented only by edit-text, next-field and back-field in ctx-text, I think. | 20-Jun-08 17:33 |
| 174 | Henrik | wonder what happens if you turn off 'tabbed | 20-Jun-08 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-08 17:06 |
| 172 | Anton | OR... | 20-Jun-08 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-08 17:05 |
| 170 | Anton | I would change that to: | 20-Jun-08 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-08 17:02 |
| 168 | Anton | (And also to make what can be into static declarations.) | 20-Jun-08 17:00 |
| 167 | Anton | Yes, the aim is to separate each property. I agree. | 20-Jun-08 17:00 |
| 166 | Henrik | yes, exactly | 20-Jun-08 16:59 |
| 165 | Anton | oops - I meant: - unfocus-on-return etc. | 20-Jun-08 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-08 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-08 16:58 |
| 162 | Anton | ... and edit-text checks for the above flags and calls a corresponding action function in the face. | 20-Jun-08 16:58 |
| 161 | Anton | Henrik, yes, we need to modify edit-text. | 20-Jun-08 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-08 16:55 |
| 159 | Henrik | what if there are more focusable items in the layout, but you don't want it to change? | 20-Jun-08 16:54 |
| 158 | Anton | The system does the refocusing here print mold get in ctx-text 'edit-text | 20-Jun-08 16:50 |
| 157 | Anton | I suppose you're just refocusing after the system unfocuses the face? | 20-Jun-08 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-08 21:38 |
| 155 | Anton | It's looking very very functional and useful just as it is ! | 11-Jun-08 18:36 |
| 154 | Henrik | (just 'do the url) | 11-Jun-08 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-08 10:27 |
| 152 | Anton | I've already got test cases for each patch - I just need to publish them. | 31-May-08 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-08 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-08 2:12 |
| 149 | Henrik | I think I'm applying the patch wrong... | 30-May-08 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-08 19:00 |
| 147 | Henrik | very nice | 30-May-08 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-08 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-08 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-08 12:12 |
| 143 | Anton | STYLIZE is also improved: | 30-May-08 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-08 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-08 12:10 |
| 140 | Anton | Submitted patches to rework error reporting in LAYOUT. Hooray ! (The madness is over.) | 30-May-08 12:05 |
| 139 | Anton | But I won' t be distracted until what I'm working on now has been submitted. | 30-May-08 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-08 4:09 |
| 137 | Henrik | I wonder if it's a good time to take another look at the resize patch? | 29-May-08 16:32 |
| 136 | Henrik | nice :-) | 29-May-08 16:31 |
| 135 | Anton | Lots of good error reporting now. | 29-May-08 14:45 |
| 134 | Anton | ... patching patching ... | 29-May-08 14:44 |
| 133 | Henrik | some separators, agree | 28-May-08 19:14 |
| 132 | Henrik | ah, I thought you did that with LIST on purpose. :-) | 28-May-08 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-08 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-08 17:49 |
| 129 | Henrik | so there's an error in init for FACE and an error in the style internally in LIST? | 28-May-08 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-08 17:08 |
| 127 | Anton | Yes, that's a good example. | 28-May-08 13:50 |
| 126 | Henrik | view layout [button button none button none button] Unrecognized parameter: none Unrecognized parameter: none | 28-May-08 13:45 |
| 125 | Henrik | for example when none is used where it shouldn't. I hope you see what I mean. | 28-May-08 13:45 |
| 124 | Anton | Hmm.. I'll see what I can do with that. | 28-May-08 13:44 |
| 123 | Anton | For instance, you can do layout [face] layout [blank-face] layout [list] | 28-May-08 13:42 |
| 122 | Henrik | what annoys me the most is that LAYOUT does not report where an error exists in the layout. | 28-May-08 13:41 |
| 121 | Henrik | can you describe how it handles uninitialized style instances? | 28-May-08 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-08 13:34 |
| 119 | Henrik | forgot your response on shift-tabbing out to avoid validation. yes, I agree as it only is confusing. | 25-May-08 17:32 |
| 118 | Henrik | cool | 25-May-08 17:31 |
| 117 | Anton | I've submitted to DevBase some of the patches we discussed here in April. | 25-May-08 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-08 17:12 |
| 115 | Henrik | I see. | 25-May-08 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-08 6:43 |
| 113 | Henrik | thanks for your help | 24-May-08 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-08 17:28 |
| 111 | Henrik | I would like to see something like view layout [field focus [set-face face "focused!"]] eventually. | 24-May-08 17:27 |
| 110 | Henrik | yes, I'm precisely hmm'ing over that. :-) | 24-May-08 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-08 17:17 |
| 108 | Henrik | hmm, ok. thanks. | 24-May-08 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-08 17:14 |
| 106 | Henrik | in my own patch, that is. | 24-May-08 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-08 17:13 |
| 104 | Anton | Yes, sorry, I don't seem to have a specific demo script available for focus-system-patch.r | 24-May-08 17:11 |
| 103 | Henrik | I'm not sure how one applies a specific focus action to a specific face in your code. | 24-May-08 17:11 |
| 102 | Anton | It essentially only modifies FOCUS and UNFOCUS. | 24-May-08 17:05 |
| 101 | Anton | It does not affect LAYOUT. | 24-May-08 17:03 |
| 100 | Henrik | is it integrated in layout? | 24-May-08 17:03 |
| 99 | Anton | I've been planning to do this patch for a while. | 24-May-08 17:03 |
| 98 | Anton | Instead, face/feel/focus-action or face/feel/unfocus-action are called. | 24-May-08 17:02 |
| 97 | Henrik | oh, I gotta try this. thanks. :-) | 24-May-08 17:02 |
| 96 | Anton | It allows to completely sidestep the old FOCUS and UNFOCUS code. | 24-May-08 17:01 |
| 95 | Henrik | it does the same thing? | 24-May-08 17:01 |
| 94 | Anton | But I have focus-system-patch.r, working well for a long time. | 24-May-08 17:00 |
| 93 | Anton | But the WITH block extends the PANEL spec, so those action blocks should just refer to SELF. | 24-May-08 17:00 |
| 92 | Henrik | I need to see the code that performs ACTION for face. It should do the same thing. | 24-May-08 16:59 |
| 91 | Henrik | that might be the problem. | 24-May-08 16:59 |
| 90 | Anton | Do you pass FACE to those functions ? If not, then why should they recognise face ? | 24-May-08 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-08 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-08 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-08 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-08 16:47 |
| 85 | Anton | And "backcolor none". | 24-May-08 16:43 |
| 84 | Henrik | for FIELD, what's the logic in not running the field action when using SHIFT-TAB? | 22-May-08 16:26 |
| 83 | Henrik | I miss that. | 9-May-08 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-08 7:15 |
| 81 | BrianH | Same here (for the moment) :( | 22-Apr-08 15:04 |
| 80 | Anton | Yes, I know. I'm just too busy to dive into DevBase just yet... :) | 21-Apr-08 15:59 |
| 79 | BrianH | :) | 21-Apr-08 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-08 2:47 |
| 77 | Anton | (but layout is complex, and that would just bloat it up a bit more...) | 20-Apr-08 4:26 |
| 76 | Anton | or actually, maybe better to patch layout so it tolerates a none init. | 20-Apr-08 4:25 |
| 75 | Anton | oh, and svv/vid-styles/face/size: 100x100 (or at least 0x0) | 20-Apr-08 4:25 |
| 74 | Anton | svv/vid-styles/face/init: [] (currently it is none, which hampers experimenting) | 20-Apr-08 4:21 |
| 73 | BTiffin | Yes it does indeed. | 14-Apr-08 0:28 |
| 72 | Paul | Anton, that has a great feel to it. | 13-Apr-08 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-08 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-08 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-08 9:28 |
| 68 | Anton | Patches to inbuilt EDITOR: http://anton.wildit.net.au/rebol/patch/ctx-edit-patch.r | 8-Apr-08 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-08 12:04 |
| 66 | Henrik | are there fixes or changes to the built-in text list? | 26-Mar-08 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-08 17:59 |
| 64 | BrianH | This is the backwards-compatibility world. | 26-Mar-08 17:42 |
| 63 | BrianH | Fix, not redesign. | 26-Mar-08 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-08 17:40 |
| 61 | Pekr | Ah, I thought View 2.7.7., or who knows what I thought :-) | 26-Mar-08 17:39 |
| 60 | Henrik | pekr, sure but I don't know where you want it in VID (hint: group name) :-) | 26-Mar-08 17:23 |
| 59 | BrianH | We have been discussing just that in the DB 2.7.7 group. | 26-Mar-08 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-08 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-08 16:46 |
| 56 | Anton | Well, that's good news. A totally unambiguous domain for you. | 26-Mar-08 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-08 16:38 |
| 54 | Anton | Well, it gets my approval. | 26-Mar-08 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-08 16:36 |
| 52 | Anton | It deserves a web page... :) | 26-Mar-08 16:35 |
| 51 | Anton | That is definitely a good characteristic. | 26-Mar-08 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-08 16:33 |
| 49 | Anton | It's obviously had a good deal of thought put into it. | 26-Mar-08 16:31 |
| 48 | BrianH | I rewrote it from scratch at least 5 times :) | 26-Mar-08 16:30 |
| 47 | Anton | I've done a few simple tests and the system looks good so far. | 26-Mar-08 16:29 |
| 46 | Anton | Your dev-resize.r code looks very good, Brian. | 26-Mar-08 16:05 |
| 45 | BrianH | We should get them involved too. | 26-Mar-08 15:51 |
| 44 | Anton | Allen Kamp. DideC, ... | 26-Mar-08 15:50 |
| 43 | BrianH | Aside from you and Henrik, who are the other VID2 heavy hitters? | 26-Mar-08 15:42 |
| 42 | BrianH | See, I liked that patch :) | 26-Mar-08 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-08 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-08 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-08 15:35 |
| 38 | Anton | Ah yes. Those styles should try to standardise. | 26-Mar-08 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-08 15:31 |
| 36 | Anton | That's right. | 26-Mar-08 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-08 15:29 |
| 34 | BrianH | The real trick is getting existing VID programmers involved so we can head off incompatibilities. | 26-Mar-08 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-08 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-08 15:26 |
| 31 | Anton | Agree. | 26-Mar-08 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-08 15:25 |
| 29 | Anton | I review it now. | 26-Mar-08 15:24 |
| 28 | BrianH | Yes, in the DevBase category for now. dev-resize. | 26-Mar-08 15:24 |
| 27 | Anton | It's in DevBase isn't it ? | 26-Mar-08 15:23 |
| 26 | Anton | I did look at it a bit... but I can't remember exactly what I thought. | 26-Mar-08 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-08 15:22 |
| 24 | BrianH | Darn. Simpler fixes then :( | 26-Mar-08 15:21 |
| 23 | Anton | I wouldn't really like that to be part of default rebol, I think. | 26-Mar-08 15:18 |
| 22 | Anton | Not so simple. My replacement is large. Replacing the face/text rendering system was long and complex. | 26-Mar-08 15:18 |
| 21 | BrianH | Aren't you working on an editor? Use that if it's better. | 26-Mar-08 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-08 15:17 |
| 19 | BrianH | Do you know who the other heavy hitters in the VID developer community are? | 26-Mar-08 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-08 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-08 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-08 15:14 |
| 15 | BrianH | Both are welcome. | 26-Mar-08 15:13 |
| 14 | Anton | Some are fixes, yes. Many are extensions. | 26-Mar-08 15:12 |
| 13 | BrianH | For that matter, do you think you could improve the R2 editor? | 26-Mar-08 14:30 |
| 12 | BrianH | Are some of those hacks fixes? We could incorporate the fixes right into VID. | 26-Mar-08 14:29 |
| 11 | Anton | I've been hacking VID every which way. | 26-Mar-08 14:06 |
| 10 | BrianH | I can only think of the bugs I discovered while I was integrating the resize code. | 24-Mar-08 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-08 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-08 13:38 |
| 7 | Henrik | but things like resizing and properly unified accessors for all faces would make some things a lot simpler. | 24-Mar-08 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-08 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-08 13:35 |
| 4 | BrianH | If we make fixes, how much breaks? | 24-Mar-08 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-08 13:33 |
| 2 | Henrik | We also need to implement BrianH's new window resize scheme. | 24-Mar-08 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-08 13:04 |