English edits?

[matecsaj]

Would you welcome English edits? Some spellings vary by country; I am Canadian but could go by the American dictionary if you prefer.

[alejandroautalan]

Hello @matecsaj, thanks for trying pygubu.

Would you welcome English edits? Some spellings vary by country; I am Canadian but could go by the American dictionary if you prefer.

Do you want to translate the messages and pygubu-designer UI?

The default language is en_US, you can edit that. Or you can create a localized translation, which in your case will be en_CA (if I'm not wrong).

Let me know.

Regards. Alejandro A.

[matecsaj]

Thanks for answering that American is your project's standard dialect for English.

I mostly see opportunities to improve the grammar of the readme and wiki - would you welcome edits to these?

[alejandroautalan]

Thanks for answering that American is your project's standard dialect for English.

I mostly see opportunities to improve the grammar of the readme and wiki - would you welcome edits to these?

You are welcome to edit the wiki as well.

Regards Alejandro A.

[matecsaj]

Before I do more, are the changes that I made to https://github.com/alejandroautalan/pygubu/wiki/2-GUI-overview acceptable?

Regarding that, I made a screenshot of what I currently see on macOS Catalina, should I use it to update the wiki page?

[alejandroautalan]

Hello Peter, sorry for the late response.

Before I do more, are the changes that I made to https://github.com/alejandroautalan/pygubu/wiki/2-GUI-overview acceptable?

Yes, they are acceptable. They look good to me.

Regarding that, I made a screenshot of what I currently see on macOS Catalina, should I use it to update the wiki page?

Yes you can, use all resources that you have available. If it is possible, add an image footer to describe in which OS was the image taken.

Regards Alejandro A.

[matecsaj]

Ok, I replaced the image in https://github.com/alejandroautalan/pygubu/wiki/2-GUI-overview and added a caption.

I started editing https://github.com/alejandroautalan/pygubu/wiki/3-VariableProperty, and something confuses me. In the text, I see "varival" and the images "radiovar"; are these different things, or in the text should "varival" be replaced with "radiovar"?

[alejandroautalan]

Hello.

I started editing https://github.com/alejandroautalan/pygubu/wiki/3-VariableProperty, and something confuses me. In the text, I see "varival" and the images "radiovar"; are these different things, or in the text should "varival" be replaced with "radiovar"?

This text was added by another user. I think he wanted to add an example of use. I edited the page with what I think he wanted to write.

But you are free to delete that paragraph if it does not agree with the rest of the text. Or you can put it in another position below.

Regards Alejandro A.

[matecsaj]

Thanks for explaining and making those edits. I tweaked a few things to hopefully make the page even better.

Moving on to https://github.com/alejandroautalan/pygubu/wiki/4-TkApplication-vs-Tk.Toplevel

To help me make sense of the information I re-organize the content to:

1. explain what a scheme is
2. list the difference between the schemes
3. detail remarks applicable to both schemes

I did not update the wiki because of questions in (brackets).

You must write Python code to use the GUI design you create, the *.ui file. There are two schemes; they differ in how tkinter's default tk.Tk() root window gets configured.

(In Design-Container I see TopLevel. In Code I see Application. Where do I specify the scheme I want to use?)

TkApplication

• Older.
• Is a helper class necessary when Pygubu didn't support containers.
• Recommended for beginners. (Do you still recommend this?)
• Most examples use it. (Is this still the situation?)

Tk.Toplevel

• Newer.
• No helper class is needed.

Remarks:

• Pick one scheme for your app and stick to it. It is not possible to use both schemes in one application. Code copied from an app using one scheme likely won't work in an app using the other.

• To specify initial window size using a tk.Toplevel widget, use the geometry property. (I can't find it, there is something called "specific" in the general widget properties, is that it?) (How does one do this the same for a TKApplication?)

• When changing the sticky property of Frames, don't forget to specify which columns and rows will be resizable using the weight property for them. (More than the grid manager exists now, pack and place, does something need to be said about them too?)

[alejandroautalan]

Hello Peter, thanks for your work.

Moving on to https://github.com/alejandroautalan/pygubu/wiki/4-TkApplication-vs-Tk.Toplevel

To help me make sense of the information I re-organize the content to:

1. explain what a scheme is
2. list the difference between the schemes
3. detail remarks applicable to both schemes

I did not update the wiki because of questions in (brackets).

You must write Python code to use the GUI design you create, the *.ui file. There are two schemes; they differ in how tkinter's default tk.Tk() root window gets configured.

This was valid for pygubu versions before 0.10. Since version 0.10 the project was splitted in two packages: pygubu and pygubu-designer. Pygubu-designer 0.10 included an official Code Generator Tab, wich was used to generate the (recommended) python script that loads the UI file. The code generator never used the TkApplication scheme, since at this time, the tk.Toplevel widget was already added in pygubu.

(In Design-Container I see TopLevel. In Code I see Application. Where do I specify the scheme I want to use?)

You can't. The use of TkApplication is no longer recommended. Is included only for backward compatibility. And might be removed in the future.

TkApplication

• Older.
• Is a helper class necessary when Pygubu didn't support containers.
• Recommended for beginners. (Do you still recommend this?)
• Most examples use it. (Is this still the situation?)

It is not recommended. Only 50% of the examples in this wiki uses it. If you think I should update those examples to the new style, I will.

Tk.Toplevel

• Newer.
• No helper class is needed.

Remarks:

• Pick one scheme for your app and stick to it. It is not possible to use both schemes in one application. Code copied from an app using one scheme likely won't work in an app using the other.

• To specify initial window size using a tk.Toplevel widget, use the geometry property. (I can't find it, there is something called "specific" in the general widget properties, is that it?) (How does one do this the same for a TKApplication?)

For tk.Toplevel use the geometry property located at the "Custom" group. For TKApplication use the geometry method:

    tk_app_object.geometry('320x240')

• When changing the sticky property of Frames, don't forget to specify which columns and rows will be resizable using the weight property for them. (More than the grid manager exists now, pack and place, does something need to be said about them too?)

In version 0.24 of pygubu-designer, a new layout editor for container widgets was added, that makes easy the configuration of grids. The Pack and Place managers are more simpler than the Grid in terms of configuration. The grid manager is the more powerful of the three but requires more attention when configuring the layout.

Regards Alejandro A.

[matecsaj]

Could the following be done to hasten the disappearance of TkApplication and make things as easy as possible for old and new users?

1. Add a feature to the designer that, when loading a *.ui file, checks for TkApplication and offers to convert to Tk.Toplevel.
2. Test the conversation tool, and eliminate the potential for copy-paste errors, by converting the remaining examples to the new scheme.
3. Delete the "TkApplication vs Tk.Toplevel" page after relocating helpful info, such as setting the initial window size, to other relevant pages.

If you like the idea, I will make a new issue for this and continue to improve the writing on other wiki pages.

[alejandroautalan]

Could the following be done to hasten the disappearance of TkApplication and make things as easy as possible for old and new users?

1. Add a feature to the designer that, when loading a *.ui file, checks for TkApplication and offers to convert to Tk.Toplevel.

2. Test the conversation tool, and eliminate the potential for copy-paste errors, by converting the remaining examples to the new scheme.

3. Delete the "TkApplication vs Tk.Toplevel" page after relocating helpful info, such as setting the initial window size, to other relevant pages.

If you like the idea, I will make a new issue for this and continue to improve the writing on other wiki pages.

Yes, I like the idea. I will convert all remaining examples to the new style.

Regards Alejandro A.

[matecsaj]

The example in https://github.com/alejandroautalan/pygubu/wiki/5-Using-the-tk.Toplevel-Widget appears to demonstrate how to skip the pygubu-designer tool and write code for the run-time pyguby library manually. Have I misunderstood, or wouldn't it be more helpful to have step-by-step instructions for the pygubu-designer?

Side question. With nothing in the object tree, if I click ttk and then click Container-Toplevel, the resultant class in the Widget Properties is tk.Toplevel. Should it be ttk.Toplevel?

[alejandroautalan]

Hello,

The example in https://github.com/alejandroautalan/pygubu/wiki/5-Using-the-tk.Toplevel-Widget appears to demonstrate how to skip the pygubu-designer tool and write code for the run-time pyguby library manually. Have I misunderstood, or wouldn't it be more helpful to have step-by-step instructions for the pygubu-designer?

That is correct. Those pages are very old and not in sync with the latest features of pygubu-designer (sorry). It would be more helpful if we have step by step instructions with pygubu-designer screenshots, showing howto generate the initial code.

Side question. With nothing in the object tree, if I click ttk and then click Container-Toplevel, the resultant class in the Widget Properties is tk.Toplevel. Should it be ttk.Toplevel?

There is no ttk.Toplevel class either in tkinter or tcl/tk (At least for now). Both use the same class tk.Toplevel.

Regards Alejandro A.

[matecsaj]

Thanks for those explanations.

Sometimes the best way to improve documentation is to make it unnecessary. Please consider three ideas.

Some wiki pages recommend putting tk.Toplevel in the root of the Object Tree and only using tk.Toplevel once. Is there ever a good reason for doing anything different? If not, what do you think about removing the wiki's advice and changing the pygubu-designer to enforce the recommendations?

After clicking the Code tab, why is the 'Object Tree' still visible? No matter which element of the Tree I select, the generated code appears identical. Should the 'Object Tree' be omitted from the Code tab and relocated under the Design tab's Widget picker with the other Design-only panes?

Regarding https://user-images.githubusercontent.com/8467919/155858162-fe9c14b0-4e5e-4321-921e-b8fc79e2ea62.png Could pygubu-designer be more intuitive and the need for adding red boxes and labels on the screen-shot eliminated? How do you feel about:

1. changing 'Object Tree' to 'Tree,'
2. changing 'Object Property' to 'Properties,'
3. changing 'Widget Id to 'Id,'
4. adding a header to the preview pane that is labelled 'Preview,'
5. in the General tab, eliminating the 'Widget properties' label and the bounding box it is part of,
6. in the Layout tab eliminating the 'Options:' label and the bounding box it is part of,
7. in the Properties pane, rename the 'General' tab to something more descriptive, such as 'Look' or 'Appearance,'
8. putting a fresh screen-shot on the wiki page,
9. and, changing the wording throughout the wiki to use the phrasing Tree, Properties, or Preview pane?

[miyucode]

I have a question about it. Me too i can translate english in french pygubudesigner but without changing all text ?

[alejandroautalan]

Hello @miyucode, thanks for trying pygubu.

I have a question about it. Me too i can translate english in french pygubudesigner but without changing all text ?

I added some info in the wiki. Let me know if you have any difficulties.

Regards Alejandro A.

[alejandroautalan]

Hello @matecsaj, sorry for the late response.

Thanks for those explanations.

Sometimes the best way to improve documentation is to make it unnecessary. Please consider three ideas.

Some wiki pages recommend putting tk.Toplevel in the root of the Object Tree and only using tk.Toplevel once. Is there ever a good reason for doing anything different? If not, what do you think about removing the wiki's advice and changing the pygubu-designer to enforce the recommendations?

I don't want to enforce this. Some of the reasons are:

• A simple app will use just one toplevel
• A more complex app will use any number of toplevel windows all designed and saved in the same UI file.
• You can use Frame as the root to design a compound widget, then generate the code to create a custom widget

After clicking the Code tab, why is the 'Object Tree' still visible? No matter which element of the Tree I select, the generated code appears identical. Should the 'Object Tree' be omitted from the Code tab and relocated under the Design tab's Widget picker with the other Design-only panes?

It make sense. I did this in the 'theming' branch. I will get those changes and merge in master branch.

Regarding https://user-images.githubusercontent.com/8467919/155858162-fe9c14b0-4e5e-4321-921e-b8fc79e2ea62.png Could pygubu-designer be more intuitive and the need for adding red boxes and labels on the screen-shot eliminated? How do you feel about:

1. changing 'Object Tree' to 'Tree,'

2. changing 'Object Property' to 'Properties,'

3. changing 'Widget Id to 'Id,'

4. adding a header to the preview pane that is labelled 'Preview,'

5. in the General tab, eliminating the 'Widget properties' label and the bounding box it is part of,

6. in the Layout tab eliminating the 'Options:' label and the bounding box it is part of,

7. in the Properties pane, rename the 'General' tab to something more descriptive, such as 'Look' or 'Appearance,'

8. putting a fresh screen-shot on the wiki page,

9. and, changing the wording throughout the wiki to use the phrasing Tree, Properties, or Preview pane?

I will try all this changes and upload in a few days.

Thanks for your comments!

Regards Alejandro A.

[matecsaj]

I find it a bit confusing that documentation for the details of hand-coding and designer usage are combined. May I relocate designer-specific documentation to new pages in the designer's wiki?

[alejandroautalan]

Hello,

I find it a bit confusing that documentation for the details of hand-coding and designer usage are combined. May I relocate designer-specific documentation to new pages in the designer's wiki?

Yes you can.

[matecsaj]

I don't see the button for adding wiki pages buttons on https://github.com/alejandroautalan/pygubu-designer. Perhaps the wiki is disabled; see https://docs.github.com/en/communities/documenting-your-project-with-wikis/disabling-wikis Can you assist Alejandro?

[alejandroautalan]

I don't see the button for adding wiki pages buttons on https://github.com/alejandroautalan/pygubu-designer. Perhaps the wiki is disabled; see https://docs.github.com/en/communities/documenting-your-project-with-wikis/disabling-wikis Can you assist Alejandro?

Wiki is now active. Let me know if you have problems.

Regards Alejandro A.

[matecsaj]

Thank you, I can now edit the wiki.

I am unsure whether some information should be in the ReadMe, the Wiki, or both. Having the desired ReadMe Sections and Wiki Table-Of-Contents would provide helpful guidance to contributors.

A wiki is more flexible than a ReadMe, and the ReadMe is the first thing people see on GitHub; perhaps ReadMe could be used for marketing and Wiki guides.

Proposed ReadMe sections: Introduction who - For designers and developers of Python applications that use Tkinter. what - It is a RAD, Rapid Application Development, tool; a drag-and-drop GUI designer, with a Python code generator. where - build and run your applications on Windows, Mac and Linux. when - stable release, it is ready for production use now why - save labour and eliminate a class of coding errors how much - cost-free, including the runtime library Hero Image (a screenshot of the program in use) features (e.g. support for both tk and ttk widgets) benefits (e.g. quickly try different UI design ideas) learn more (link to the wiki)

Proposed Wiki TOC.

What do you think, Alejandro?

[alejandroautalan]

Hello Peter,

Thank you, I can now edit the wiki.

I am unsure whether some information should be in the ReadMe, the Wiki, or both. Having the desired ReadMe Sections and Wiki Table-Of-Contents would provide helpful guidance to contributors.

A wiki is more flexible than a ReadMe, and the ReadMe is the first thing people see on GitHub; perhaps ReadMe could be used for marketing and Wiki guides.

Yes, I agree with this. Also the Readme is used in the pypi page therefore it should be brief and contain the most common ideas and procedures.

Proposed ReadMe sections: Introduction who - For designers and developers of Python applications that use Tkinter. what - It is a RAD, Rapid Application Development, tool; a drag-and-drop GUI designer, with a Python code generator. where - build and run your applications on Windows, Mac and Linux. when - stable release, it is ready for production use now why - save labour and eliminate a class of coding errors how much - cost-free, including the runtime library Hero Image (a screenshot of the program in use) features (e.g. support for both tk and ttk widgets) benefits (e.g. quickly try different UI design ideas) learn more (link to the wiki)

Proposed Wiki TOC.

What do you think, Alejandro?

I like the proposed structure for the the readme and the wiki.

Regards Alejandro A.

[matecsaj]

While working on the wiki pages, opportunities to improve the designer come to mind. I will make independent issues for each so that this thread does not get any more cluttered than it already is. I hope this will work best for you too.

[alejandroautalan]

While working on the wiki pages, opportunities to improve the designer come to mind. I will make independent issues for each so that this thread does not get any more cluttered than it already is. I hope this will work best for you too.

I have seen them. I'm fine with that. I will start working on them soon. Thank you for the work you have done so far. It really helps me to keep improving pygubu.

Regards! Alejandro A.

[miyucode]

Hi @alejandroautalan, thanks for your helping ! I'll maybe contributate on this project, your project looks very good ! And I've a suggestion for you, did you think one time about convert .py to .exe for simple use ? It's a suggestion but he can be a good idea I thought ! :P

[matecsaj]

You are welcome, and thanks for the idea.

[alejandroautalan]

Hi @alejandroautalan, thanks for your helping ! I'll maybe contributate on this project, your project looks very good ! And I've a suggestion for you, did you think one time about convert .py to .exe for simple use ? It's a suggestion but he can be a good idea I thought ! :P

Hello @miyucode, thanks for your suggestion. You can open a issue and elaborate more your idea, so we can discuss it. Tell me about what converter are you using, how do you want pygubu-designer to do to help in the process of creating the executable?

Regards Alejandro A.

[matecsaj]

Instead of writing a code of conduct from scratch, how you feel about adopting this ?

[alejandroautalan]

Instead of writing a code of conduct from scratch, how you feel about adopting this ?

After reading it, I agree. We can adopting it.

[matecsaj]

Alejandro, please help with a couple of wiki pages, I don't know what should be communicated to the reader.

• Edit this page, in particular step 4.
• On this page, replace the two spots where it says "Documentation is needed here."

[matecsaj]

I have edited everything for English in the Wiki, deleted stale content, re-did the Table of Contents, and added some pages. I've done all I set out to do and more. Is there anything I've done that you feel needs re-work, or can I close this out?

[alejandroautalan]

Hello Peter, You can close this issue. I will take care of each individual issue you have open and update the wiki when I'm done. The wiki now looks like a real and useful wiki, thanks for your work.

Alejandro A Regards.

[matecsaj]

Thank you for the helpful tool.