EDALL button should have a different effect
A Logo programming environment for Microsoft Windows
Brought to you by:
david_costanzo
Menu
▾
▴
#126 EDALL button should have a different effect
The EDALL button now wraps EDIT CONTENTS, but when clicking File -> Edit -> Edit Procedures there is another ALL button which simply wraps EDIT PROCEDURES. So it would perhaps be meaningful, if the big EDALL button also had the effect EDIT PROCEDURES instead of CONTENTS. There is another reason: If a beginner uses EDALL it is easier for her or him not to be confronted with all the contents, but only with all procedures. The rest of the contents can be inspected by EDIT or ED with all the other workspace queries.
I hesitate to make such a large change to the existing usage model based on the input of one or two people. I understand that you don't like what the Edall button does, but it's been like this for over 20 years so all existing MSWLogo and FMSLogo educational material and tutorials have been written with this assumption. Putting an extra dialog box between the programmer and the editor would impede some workflows. Removing the ability to include variables and property lists in the editor would preclude other workflows.
The Edall button simply runs
EDALLso you can re-define EDALL to do whatever you like, including having it display a dialog box that lets you pick a procedure to edit. I can provide some sample code if you need help implementing something like "File -> Edit..." in Logo.I'm more inclined to...
Personally, I think including variables and property lists at the bottom of the workspace is not about making programmers "confront" them but making programmers aware of them. If a programmer creates a global variable, this lets them know. It also lets them see the value and even edit the value, if they like. For the games I wrote, like
lightcycle,pacturtle, andtutrlemaze, the game parameters (including the game board) are stored in variables and so the variables are an essential part to understanding how the game works and the easiest invitation to hacking the game.Well, I perfectly understand this didactic commitment, but everyone who has written a program has also defined the global variables himself or herself and must therefore know them and be able to assess their importance without being reminded of it by their duplicates.
Ah, "duplicates" is the key word. The way I was thinking about it, it wouldn't be a duplicate because the student would have defined the variable exactly where EDALL shows it, at the bottom of the top-level scope. However after looking at the three examples that I cited above, I see that I didn't do that. I assigned the variable a value within a procedure, so there are indeed duplicates. I think I did this because I wanted to preserve the way I formatted the value (with whitespace), which is only possible within a procedure definition.
For me, the duplicates serve a purpose, which is to point out that I forgot a BURY or a LOCAL instruction. When I wrote
lightcycle.lgoI might not have understood LOCAL because it has duplicates. I think this is a bug in lightcycle and will probably fix it. Thus, I have proven that I don't like seeing the duplicates, either.BURY and LOCAL are really only for advanced users, not something to introduce early on when programmers are still learning how to write procedures. So you've convinced me that showing variables and property lists is bad for beginners. However, I'm not convinced that having an extra dialog box between the Edall button and the editor is good. Even if were convinced that it was good, I'm not convinced that the change is so much better that it justifies the confusion it would cause to everyone who is used to the way things are now.
I'm also convinced of your "big button" argument. The "Edall" button is so much more prominent than "File -> Edit..." that even if you told people to use "File -> Edit..." some would mistakenly press "Edall" and be confused. I did this a few times with my EDITFILE program and ended up losing data as a result.
In short, the bit that I'm not convinced of is how to let you customize the behavior of the Edall button without impacting every other user of FMSLogo.
I wasn't suggesting that you modify logolib. You can redefine any library procedure in your external library and it will take effect when you load that library. I have attached "mylib.lgo" as a proof-of-concept. Unfortunately, it looks like there's a bug in COMBOBOXCREATE such that selecting an item will also click the "Edit" button without updating the text. This seems to have been introduced in FMSLogo 7.7.0, probably caused by updating wxwidgets from 2.18.12 to 3.1.0. I have to investigate this further and hopefully have it fixed in the next release.
mylib.lgo
Thanks a lot! This looks very useful.
As I noticed, the combobox seems to work correctly - first the selected procedure appears in the top line, then the edit-button can be activated, then the editor appears (as non-modal).
My only problem is that the File -> Save & Exit or simply Exit returns to Nopwhereland, while I expected it to return to the selection box which called it. The latter would make it easier to edit procedures one after the other directly. Is that possible?
I took WINDOWDELETE "procedurepicker away from the first two buttons and left it only for the CANCEL-button. Like this it 's easier to edit procedures one after the other by picking them immediately from the procedure list.
File -> Edit... also disappears after it opens the editor, so I assumed that's what you wanted. If you want a procedure picker that always remains open, I wonder if you'd be happier with something else. Please humor me as I explore some alternate ideas:
What if there was a "procedure sidebar" that docked to the right of the screen window and had a list of all of the unburied procedure names. Imagine that this list updates automatically whenever a new procedure is defined or an existing procedure is buried/erased. Let's say that double-clicking on the procedure opens it in the editor.
Looking at this, it's similar to opening all procedures in the editor, adding support for folding to the editor (a feature which I dislike and always disable) so that you can collapse/expand a procedure's definition under its "TO line", and adding a menu option to load the contents of the editor into the workspace without closing it.
Or maybe add the procedure sidebar to the editor, instead of the main window, and double-clicking on a procedure name jumps to its "TO line" within the editor. In this case, the sidebar would only show procedure names that are open for editing. This is similar to what I had suggested before as an alternative to line numbers...a jump to procedure dialog.
Well the first option means EDIT ALL PROCEDURES, and the second one means EDIT ALL... the project. I don't see why the interface should have two features (in different places) that do the same thing.
I wonder what specific situation is Manfred trying to avoid... Is it that sometimes the content of variables is huge and the Editor chokes trying to edit (and colorize) so much?
I've had that happen to me, frequently. Though I suppose 99% of all FMSLogo users don't even use lists and property lists, at all.
I usually do not use the FMS editor at all. I use an external editor.
Now that I know about the File -> Edit feature and about the Procedure Selector. I think I might use that, instead of what I usually do, which is kind of cumbersome:
ed "myprocedurename
I would really like to know what type of situations is Manfred trying to avoid...
I'm glad you chimed in, Daniel. Manfred is preparing an argument for the use of FMSLogo in a region of Germany. This request came from a discussion described in Feature Request #125. He's opened other support requests and discussion tickets that give more background.
Please open a bug if you can reproduce this. I know of a few places where the colorizer is incorrect, but only in extreme edge cases, like backslahed backslashes in vbarred strings.
I did as well...until Manfred opened Support Request #10. Since then I've been using a procedure I wrote called EDITFILE to open a file in FMSLogo's editor. There are a few places where the editor is annoying, but I think it's better than emacs....I can't believe I just wrote that. BETTER THAN EMACS?!?!
Related
Feature Requests:
#125Support Requests: #10
David wrote:
File -> Edit... also disappears after it opens the editor, so I assumed that's what you wanted.Perhaps I didn't express well enough what I needed. As long as I walk from one procedure to the next while editing, perhapts because there are dependencies, I 'd prefer to keep the procedure picker open.
David's proposal, to overwrite EDALL by a more sophisticated procedure picker with a combobox and buttons EDIT - EDALL and CANCEL, would do the job,
So, as I wrote already, I took WINDOWDELETE "procedurepicker away from the first two buttons and left it only for the CANCEL-button. If I now added a SAVE TO FILE button, which only would save procedures to an external file, everything would be fine. It would be a simple solution, but a useful one.
David wrote:
What if there was a "procedure sidebar" that docked to the right of the screen window and had a list of all of the unburied procedure names. Imagine that this list updates automatically whenever a new procedure is defined or an existing procedure is buried/erased. Let's say that double-clicking on the procedure opens it in the editor.This would be a step forward to a very comfortable level, and it would make very clear how a project unfolds. What if I doulbleclick a second procedure while the first is still open? Would both procedures appear together in the editor? Or even a complete collection? And what, if I use the commander to define a procedure? Then the editor has a somewhat different appearance. This means, that I'm not quite sure, how the editor(s) behave(s). Nevertheless this could become an important progress.
I hadn't thought that far. I suppose you wouldn't like it if it merely gave the current editor focus, the way File -> Edit... currently behaves. I think it's easier to implement if it opens a new editor for each procedure. It's a little harder to give an editor focus if it's open and was launched to edit that procedure. It's much harder to update the contents of an existing editor and the semantics become confusing (if you open "a" in the editor, add "to b...end", then double-click on "b" in the sidebar, what happens?).
I expect you want to be able to open several procedures at once. Maybe the sidebar could let you select multiple procedures and open them all at once, instead of one by one which I think is too hard/confusing. If you really want to walk between different procedure definitions within an editor, then I think you'd be happier with EDIT PROCEDURES and having a way to jump to a procedure definition as well as collapsing (folding) the other procedures definitions into their TO line so that you only see the definitions that you're working on.
I think you're referring to the mini-editor, which is what appears after you run the first line of a TO instruction in the Commander (not EDIT). The mini-editor doesn't let you change the TO line for implementation reasons. I know it's not pretty, but it's a lot better than what used to happen--a READWORD dialog box would prompt for each line which you could OK or Cancel. If you have suggestion or requests for the mini-editor, please open a separate feature request since I don't think it would be relevant to this request. To answer your question, I assumed the sidebar would open the full editor, like EDIT, so that you can change the TO line or even erase the procedure if you like.
A few more thoughts on the procedure side bar:
One more question:
Edit "procnameinto the commander history?I cannot open SourceForge, so I try to answer this way.
I must admit that these are too many changes for me, and I am not sure
that they are necessary.
My personal habits and preferences are unimportant, what counts is the
maxim "Keep it simple". Yes indeed, I think that one single procedure on
one single editor at one time is enough to work even with large
programs. Of course you have to know the dependencies, but you can see
the forward dependencies in each procedure itself
Attached please find an extended version of your procedurepicker, now
called littlehelper, because it does more than picking procedures. To
test it, I have attached a small program for test purposes.
This little helper can be optimized, but in principle it can do nearly
all I need, and I don't need an external editor instead.
Last edit: David Costanzo 2021-01-28
Thank you for letting me know that there's no need for me to spend timing doing something that won't benefit you. I'm glad that the existing FMSLogo serves your purpose.
Thank you for leaving off the last word from the typical American maxim.
Okay, back on SourceForge.
Regretably Corona keeps stealing pbreport time and efficiency.
There are still unanswered questions:
I sent you what I called "littlehelper". David's preceding "procedurepicker" for me was a very strong inspiration.
Despite a bunch of shortcomings littlehelper solves most of our (pbreport's) remaining problems, and as it still does the work of the former EDALL-button, it is downward compatible (which is important after all).
David wrote about the proposed sidebar:
I think, while programming there is no necessity to be able to do all the other things (like using the commander) concurrently. Especially, littlehelper could even be modal. And it should be in the center of the view, not at the right edge.
That's where I have a problem. The first parameter of the window is now 200 with main as parent, but it looks at is is it at 600 pixel (factor 1.25) on my screen. How comes this? I even tried to use items of MACHINE to design it properly, but there was the same problem: The parameters seem to be no pixels, but something else.
David wrote about a new file:
Perhaps the problem could easily be solved by littlehelper with an addidional button like "new file" or so.
(To be continued later)
I'll have more time to look into this on the weekend, but I expect that the x,y coordinates are relative to desktop, not FMSLogo. MACHINE does not output the x,y position of the screen window so you'd have to use DLLCALL to get it. I'll try to provide sample that does this when I get the chance.
In the meantime, you could look at
UIAUTOMATION.GETWINDOWRECTin uiautomation.lgo (sourceforge.net) to see how I do this in my automated tests. This is not for the feint of heart, but if you can study and understand it, a world of possibility will open to you.Manfred Zindel wrote:
I was surprised to learn the x,y coordinates are in "dialog units", not pixels. It doesn't make much sense for WINDOWCREATE, but that's how MSWLogo behaves, so that's how FMSLogo behaves. This is documented but not well. I'll update the documentation of WINDOWCREATE to state this explicitly.
Roughly speaking "dialog units" are calculated in terms of "base units" which are determined by your font. The conversion to pixels is calculated as:
On my machine, the base units are (8, 16) so, on my machine, this amounts to
Manfred Zindel wrote:
I think I misunderstood this. When you said "center of view" I thought you mean centered on the FMSLogo screen window. To get the screen window's extends, you need to use DLLCALL. If you want it centered on your display (monitor) it's a bit easier since MACHINE does output that information. You'll still need DLLCALL to get the base units or you could assume that they're (8,16).
I've attached a litte_helper_v4.lgo that positions the dialog offset from the FMSLogo's window x,y. If you study it, you should be able to figure out how to center a dialog box on a display. I wrapped all of the DLLCALLs in their own procedure. For example, this is the one that gets the "base units" described above:
I was wondering if having a collection of these documented somewhere would be useful, similar to https://pinvoke.net. It's really only useful if other people want to call into win32. I suspect that I'm the only one who actually does that.
I still have to answer Daniel's question:
Short: I was trying to avoid errors and an awkward two-step method to save my program back to an external file from a workspace which could be a mixture of many things and influences and moreover reordered my procedures. I expected the editor to be a servant, but it was a machine which scrambled and cluttered what I had made.
.
Long: Once upon a time, since I began writing larger programs (more than 2000 lines) in FMSLogo a dozen of years ago I used the EDALL button to open the editor. I was surprised that not only variables and values were added to the listing, but also after closing and reopening my hopefully meaningful order of procedures was scrambled and cluttered by additional material.
Worse than that, after adding more lines or altering something nearly each and every time, an error warning stopped me from leaving the editor, asking me to go back and fix the error. After a while I found out that the error messages nearly always pointed to the part of the variables. Soon I also found out that I could make the error message disappear by erasing all the variable (and plist-) lines from the worklspace. To avoid reordering of the procedures, I let their names begin with a number. (I admit, I better should have traced down the errors precisely and open a ticket aon them. I finally thought that this was too cumbersome and switched to Notepad++ as external editor. Much better!
When we began to teach courses in FMSLogo, we always used the internal editor. The pretty small experimental programs could easily be written without running too deep into the difficulties I had experienced.
Now we plan more ambitious courses and would like to do them in FMSLogo - if possible with a more friendly internal editor - easier to use and to explain.
I already mentioned the two-step method which is necessary to save a program from FMSLogo to an external file. To leave the internal editor, I have to click "Save and exit". Then the contents of the editor are added to the workspace. In a second step, a while later, I have to save the invisible contents of the workspace to an external file. It would be much better to save the program directly from the internal editor to an external file - this is not the most elegant way.
That's awful. I found one such bug in any variable that is made from the output of DIALOGFILEOPEN. If you can reproduce the creation of a variable that prevents FMSLogo from saving a well-formed workspace please report it as a bug.
Related
Bugs: #549
Here comes "little_helper_plus.lgo", the next experimental program derived from David's procedurepicker. We - pbreport's Chinese young lady and me - made a more complete concept and tested it with the FMSLogo-programs "midi.lgo" and "midi_workspace.lgo". If you open "little_helper_plus.lgo", then load "midi_workspace.lgo" (both given here as attachments) and finally click the EDALL-button, you can see, how easy it becomes to play around with the FMSLogo-workarea, which apparently makes sense, and with the editor. One open editor at the same time seems to be enough for editing of even fairly larger programs. It seems as if it is better to open the EDALL-dialog at the right edge but let it float freely to arrange it properly, suitable to the special design and the needs of the loaded program. Erasing works fine when clicking "Clear All" in the Editor, and a new procedure can easily be added using the mini-editor - in both cases the EDALL-dialog regretably is not updated before closing and reloading it. This way we could imagine to work and even teach effectively with FMSLogo without an external editor. The new EDALL-button is downward compatible to the old one, because its name can be kept and its original effect can still be activated. Note that "midi.lgo" has two versions, one with only procedures ("midi.lgo") and another one with the complete workspace stored ("midi_workspace.lgo"), both starting with procedure "piano". If desired you could also save only the variables externally. So far, plists are not provided. If possible, there could be an additional "New procedure"-button in the dialog related to the standard editor instead of the mini-editor, but we didn't know how to code it. And, perhaps, there could be buttons for the plists.
Does "Chinese young lady" use the Chinese translation of FMSLogo or the English one? I have to ask because I refuse to add any kind of statistics gathering logic into FMSLogo for child safety reasons, so the only way I can know how FMSLogo is used in the field is if people tell me.
The mini-editor should only appear if
TOis run outside the context of aLOAD. I won't have time to really read and understand what you're asking until the weekend but if you just want to open the editor with a blank procedure definition try this:It's the weekend. I reread what you wrote. I see a few question:
For #1, you can delete and recreate the listbox.
For #2, you can run
EDIT [].For #3, there are two ways. One is to SETTIMER to poll when the procedure list changes and update the list then. This is complicated but I showed you the principal in my non-modal questionbox sample. The other way is to write what you want to a temp file (with SAVEL), use WINDOWFILEEDIT to open the file and pass a "onclose" instructionlist that deletes the file and refreshes the procedure list, as I suggested in #1. Neither of these are simple, and since you say "keep is simple", I doubt you'll like either of these.
For #4, the editor remembers its position, so I don't think this should be needed. If you wanted to control where the editor opens, you could use DLLCALL to update its "memory" of where it opened (it's in the registry). Alternatively, you could use DLLCALL to move it after it opens. To do this, you first need to find it. In English versions of FMSLogo, it has the title "Editor". Neither of these are simple, either.
I've updated your little_helper_plus.lgo to include #1 and #2. I didn't do #3 or #4 because it's hard and I don't think you'll like it. Sometime later, I'll post an update that demonstrates how to use DLLCALL to position the little helper dialog.
Last edit: David Costanzo 2021-01-30
She tells us the following:
"In principle I'm using the English version. When you asked, we installed the Chinese version once more and tried it out again. During the installation process everything appeared Chinese, that means, menu entries and button labels, but there were English citations, such as the License.
After opening FMSLogo after the installation, menu entries and button labels appeared in Chinese. Other than in the German version, all the commands are expected to be written in English, like "forward", "left" aso. This seems to be not so bad, because it should be international. This is no problem for older children, adolescents and adults, who already have learned English in school. Learning English begins early in school, say in the third year of school, but the ability to understand computer related words may be available some years later. All the other parts of Chinese FMSLogo is written in English, especially the manual and the index. After all, the Chinese version of FMSLogo requires a deep knowledge of English computer words, and the surrounding Chinese is a comfortable environment, but not more. Chinese people who don't speak English, especially young children, will not be able to use FMSLogo. We asked ourselves, why we always prefer the complete English version. It's because we try to be able, to make contacts over the internet with people all over the world, who sometimes speak languages which we don't understand. Even widespread languages like Spanish, French, Portuguese, Russian and others are no problem for us - we can always bridge the gab using English. This applies for people like us, but children whose native language is not English, will be pleased to have material in their own language with commands still original, but well-explained. In our opinion the German version of FMSLogo which translates the genuine commands does a little too much, and it should name the file-extension ".lgo" and not "log". We appreciate that the manual and the index are translated into German."
Manfred writes:
By the way, pbreport plans coursebooks for adolescents and even adults, which can be placed between keyboard and screen and explain everything in a narrative style for adolescents, using English as computer language and English, German, or Chinese as explanatory language. They will be easy to understand even without a teacher being always present.
Thanks for asking about the Chinese FMSLogo. I half-expected her to be using MSWLogo.
Speaking from my own experience, using a non-native language would be a deal-breaker in the U.S. I started learning French in 7th grade (about 12 years old), three times a week for 45 minutes, if I remember correctly. I did that for two years and only knew colors, numbers, the days of the week, etc. Then I took three years in high school but I think only one year was required. At that point, I could only communicate very basic things and only very awkwardly (and incorrectly) with a very patient French speaker. I could never have had a comfortable conversation in French. By analogy, if FMSLogo were in French, then neither students nor the teacher would be able to understand it and it would be a large barrier to learning.
Ha ha. The GPL is not written in English. Although it uses words from English, it's written in a language that only lawyers can understand. The FSF says they cannot translate it for legal reasons.
I'll fix this if a German open a bug on it. The only reason it's ".log" is that Stephan Vogel, the person who created the German translation, said that in Germany ".log" is used and insisted strongly on this. I had no authoritative evidence to disagree. If there's a bug on it, then the next time he insists, I can point to it and say something like "Manfred Zindel is a German educational consultant and he says that Germany uses '.lgo' pervasively and that doing so is necessary for adoption in German schools". That's much stronger than me saying "I don't like it".
David wrote:
First, thank you for making amendments to little-helper.
We're still discussing how to use an editor-system for teaching and for development. As you and Daniel said, you are using external editors yourselves, we assume that even for you it is not so comfortable to go ahead with the FMSLogo-editor and workspace.
And yes, there is a bug, which can be seen when using your new version of little helper (v4)
I send you again the very interesting midi.log file by Hensley Bass which I loaded for testing - naturally after composing a little tune on it. Not quite the same as my Yamaha Tyros 4, but nevertheless a good program.
Working with midi and little helper could be done like this:
After loading you can see all the procedures, but nothing else. You now open the whole workspace, and two lines before it begins you write "piano", the name of the initial procedure. Then you "save and exit" the editor.
Now the whole design of the midi-system appears. Wonderful!
But if you now open the workspace again, the editor shows some variables and nothing more. All the procedures are gone. And if I tried to save them back to an external file without noticing it, the file would be overwritten with nothing.
Now, what happens, if I only open a single file and do the same thing? Well, the same mess happens, but this time only the single file is gone, the others are still in place.
This kind of catastrophe happens only, if I write something on the top-level outside the to ... end-range. Dangerous - especially if I 'm not aware of it.
Other unexpected things happen if I do something with variables which are in the name-part of the workspace.
Playing around with little_helper and Midi shows that editing on the basis of the workspace can be harmful. There may be a solution - but as far we don't understand what happens.