Re: Creating Qt Apps That Run In A Tab

[Thomas Passin]

In my first post on apps in tabs, I wrote this:

There are three parts to these "tabbed" apps:

1. Creating the top-level QWidget;
2. Inserting it into a tab and controlling the tab (e.g., toggling it on 
and off);
3. Interacting with the app.

Instead of "Creating the top-level Widget" I could better have written 
"Designing the top-level widget".  Item 2. is the heart of the tabbed-app 
approach, and that's what this post is about.

To make it work, we have to:

1. Find the log frame;
2. Create a new tab;
3. Insert our top-level QWidget into it;
4. Be able to toggle the tab on and off.

Here is how it's done in the demo outline I posted last time. I have 
inserted explanatory comment into the code.  We start with setting up some 
useful constants:


"""A log tab panel for demonstrating plotting techniques."""
log = c.frame.log   # Get the log frame
TABNAME = 'Pyplot'
# We will use these constants when we control the tab later
WIDGET_NAME = f'{TABNAME}-widget'
VISIBLE = f'{TABNAME}-visible'

The core of the code is in the toggle() function:

# The function to toggle the tab on and off.  We use the log's
# contentsDict to hold our own, private variables, since it 
# is always going to exist.  These private names are very unlikely
# to be duplicated by any other tab.
def toggle(log):
"""Create, show, or hide pyplot tab in Log pane.

ARGUMENT
log -- the log panel object for this outline.
"""

# Check whether there is a VISIBLE key.  If so,
# delete the tab and destroy our widget.
if log.contentsDict.get(VISIBLE, False):
log.deleteTab(TABNAME)
log.contentsDict[VISIBLE] = False
w = log.contentsDict[WIDGET_NAME]
w.disconnect_all()
w.deleteLater()
del(log.contentsDict[WIDGET_NAME])
else:
# Create our widget and embed it in a tab
w = PlotWindow()
log.createTab(TABNAME, widget = w, createText = False)
log.selectTab(TABNAME)
log.contentsDict[VISIBLE] = True
log.contentsDict[WIDGET_NAME] = w


# If this is the first call of toggle(), create our widget's code
# This will work for (nearly?) any subclass of QWidget.
# Define the widget's class.  It will be instantiated when
# toggle(log) runs.
if not log.contentsDict.get(WIDGET_NAME, None):
<< Main Widget >>

toggle(log)

Next time: how to toggle the tab on and off without deleting our widget.

On Thursday, April 13, 2023 at 9:27:39 AM UTC-4 Thomas Passin wrote:

> I have re-organized the code a bit to make to easier to read.  It does the 
> same job  as before.  Also, I have zipped up the outline to make it easier 
> to get from the browser.
>
> More to come soon.
>
> On Sunday, April 9, 2023 at 1:14:13 PM UTC-4 Edward K. Ream wrote:
>
>> On Sun, Apr 9, 2023 at 7:32 AM Thomas Passin  wrote:
>>
>>> Remind me what you mean by an "info item".  Would this be a GitHub issue 
>>> with a "devInfo" or "Info" tag?
>>>
>>
>> Exactly.
>>
>> Edward
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/01f2210a-ad9d-4015-8a71-afc21b812b79n%40googlegroups.com.

Re: Creating Qt Apps That Run In A Tab

[Thomas Passin]

In my first post on apps in tabs, I wrote this:

There are three parts to these "tabbed" apps:

1. Creating the top-level QWidget;
2. Inserting it into a tab and controlling the tab (e.g., toggling it on 
and off);
3. Interacting with the app.

Instead of "Creating the top-level Widget" I could better have written 
"Designing the top-level widget".  Item 2. is the heart of the tabbed-app 
approach, and that's what this post is about.

To make it work, we have to:

1. Find the log frame;
2. Create a new tab;
3. Insert our top-level QWidget into it;
4. Be able to toggle the tab on and off.

Here is how it's done in the demo outline I posted last time. I have 
inserted explanatory comment into the code.  We start with setting up some 
useful constants:

"""A log tab panel for demonstrating plotting techniques."""
log = c.frame.log   # Get the log frame
TABNAME = 'Pyplot'
# We will use these constants when we control the tab later
WIDGET_NAME = f'{TABNAME}-widget'
VISIBLE = f'{TABNAME}-visible'

The core of the code is the toggle() function:

# The function to toggle the tab on and off.  We use the log's
# contentsDict to hold our own, private variables, since it 
# is always going to exist.  These private names are very unlikely
# to be duplicated by any other tab.
def toggle(log):
"""Create, show, or hide pyplot tab in Log pane.

ARGUMENT
log -- the log panel object for this outline.
"""
# Check whether there is a VISIBLE key.  If so,
# delete the tab and destroy our widget.
if log.contentsDict.get(VISIBLE, False):
log.deleteTab(TABNAME)
log.contentsDict[VISIBLE] = False
w = log.contentsDict[WIDGET_NAME]
w.disconnect_all()
w.deleteLater()
del(log.contentsDict[WIDGET_NAME])
else:
# Create our widget and embed it in a tab
w = PlotWindow()
log.createTab(TABNAME, widget = w, createText = False)
log.selectTab(TABNAME)
log.contentsDict[VISIBLE] = True
log.contentsDict[WIDGET_NAME] = w


# If this is the first call of toggle(), create our widget's code
# This will work for (nearly?) any subclass of QWidget.
# Define the widget's class.  It will be instantiated when
# toggle(log) runs.
if not log.contentsDict.get(WIDGET_NAME, None):
<< Main Widget >>

toggle(log)

On Thursday, April 13, 2023 at 9:27:39 AM UTC-4 Thomas Passin wrote:

> I have re-organized the code a bit to make to easier to read.  It does the 
> same job  as before.  Also, I have zipped up the outline to make it easier 
> to get from the browser.
>
> More to come soon.
>
> On Sunday, April 9, 2023 at 1:14:13 PM UTC-4 Edward K. Ream wrote:
>
>> On Sun, Apr 9, 2023 at 7:32 AM Thomas Passin  wrote:
>>
>>> Remind me what you mean by an "info item".  Would this be a GitHub issue 
>>> with a "devInfo" or "Info" tag?
>>>
>>
>> Exactly.
>>
>> Edward
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/1abc6a9a-5980-4eed-8eee-c56b28cf6f23n%40googlegroups.com.

Re: ENB: For Thomas and Félix: more about PR #3277

[Edward K. Ream]

On Thu, Apr 13, 2023 at 10:07 AM Thomas Passin  wrote:

> Or maybe I misunderstood and the references to os.cwd() only refer to the
> unit tests and not to how the paths are constructed when used in an outline?
>

Exactly. That's what confused me too.

That's why I said the unit tests aren't the whole story. The *callers *must
specify a proper path. That's what c.fullPath does, and that's why the PR
is sound only if c.fullPath is correct.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/CAMF8tS2AZbkzLcJGGJ0frFkyeqkasvuV%3Dc%2BMYx3g%3D8v7Fq%2B0zA%40mail.gmail.com.

Re: ENB: For Thomas and Félix: more about PR #3277

[Thomas Passin]

Or maybe I misunderstood and the references to os.cwd() only refer to the 
unit tests and not to how the paths are constructed when used in an outline?

On Thursday, April 13, 2023 at 10:16:57 AM UTC-4 Thomas Passin wrote:

> On Thursday, April 13, 2023 at 10:13:11 AM UTC-4 Thomas Passin wrote:
>
>
> On Thursday, April 13, 2023 at 9:32:36 AM UTC-4 Edward K. Ream wrote:
>
> [...]
>
>
> *Testing*
>
>
> *test_g_finalize* and *test_g_finalize_join* were responses to Thomas's 
> compatibility concerns. I worked on these two tests for several days before 
> realizing that these tests weren't the whole story!
>
>
> The very first test case in test_g_finalize_join shows the problem. 
> g.finalize('a.py') must return an absolute path relative to os.getcwd(), 
> *not* the directory containing the outline! In other words, the *callers *of 
> g.finalize_join are responsible for specifying the absolute path.
>
>
> I don't think that this agrees with my understanding of how things have 
> worked in the past.  Please correct me if it's not so.
>
> 1. Paths in at-files should *not* depend on os.getcwd() because that value 
> is state-dependent and is not necessarily defined only by the current 
> outline.  The user may have run various scripts that changed it.  This 
> could lead to changing and unpredictable locations for external files.
>
> 2.  When I create an external file like this, I expect its path to be 
> relative to the *outline*:
>
> @file special/good.py
>
> 3. When I use an @path node like this, I expect the at file to be located 
> at a path which starts with the @path expression:
>
> @path special
> @file good.py   # Path should be special/good.py relative to the 
> outline.
>
> 4. Since the @path expression is to be prepended to the at-file path, if 
> the @path is an absolute path, the at-file path should be absolute, not 
> relative to the outline.
>
>
> I didn't word this clearly enough.  I meant that the final path to the 
> external file should be absolute because the @path segment was absolute.  
> The segment from the at-file node would be relative.
>  
>
> 5. What should happen if *both* the @path and the @file contain absolute 
> paths?  Of course, this shouldn't happen but what if it did?  I would say 
> that the at-file's path should prevail, the @path should be disregarded, 
> and an error message should be given on the first attempt to save the file.
>
> IMO, 2) and 3) are **essential** for stability and sanity.  The changeset 
> in devel as of yesterday afternoon behaves correctly with all the outlines 
> containing external files I have opened.  I have not yet tested whether my 
> @rst files go to the right place when I run the rst3 command.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b321ae77-ce36-4104-97b1-9fa0f014a601n%40googlegroups.com.

Re: ENB: For Thomas and Félix: more about PR #3277

[Thomas Passin]

On Thursday, April 13, 2023 at 10:13:11 AM UTC-4 Thomas Passin wrote:


On Thursday, April 13, 2023 at 9:32:36 AM UTC-4 Edward K. Ream wrote:

[...]


*Testing*


*test_g_finalize* and *test_g_finalize_join* were responses to Thomas's 
compatibility concerns. I worked on these two tests for several days before 
realizing that these tests weren't the whole story!


The very first test case in test_g_finalize_join shows the problem. 
g.finalize('a.py') must return an absolute path relative to os.getcwd(), 
*not* the directory containing the outline! In other words, the *callers *of 
g.finalize_join are responsible for specifying the absolute path.


I don't think that this agrees with my understanding of how things have 
worked in the past.  Please correct me if it's not so.

1. Paths in at-files should *not* depend on os.getcwd() because that value 
is state-dependent and is not necessarily defined only by the current 
outline.  The user may have run various scripts that changed it.  This 
could lead to changing and unpredictable locations for external files.

2.  When I create an external file like this, I expect its path to be 
relative to the *outline*:

@file special/good.py

3. When I use an @path node like this, I expect the at file to be located 
at a path which starts with the @path expression:

@path special
@file good.py   # Path should be special/good.py relative to the 
outline.

4. Since the @path expression is to be prepended to the at-file path, if 
the @path is an absolute path, the at-file path should be absolute, not 
relative to the outline.


I didn't word this clearly enough.  I meant that the final path to the 
external file should be absolute because the @path segment was absolute.  
The segment from the at-file node would be relative.
 

5. What should happen if *both* the @path and the @file contain absolute 
paths?  Of course, this shouldn't happen but what if it did?  I would say 
that the at-file's path should prevail, the @path should be disregarded, 
and an error message should be given on the first attempt to save the file.

IMO, 2) and 3) are **essential** for stability and sanity.  The changeset 
in devel as of yesterday afternoon behaves correctly with all the outlines 
containing external files I have opened.  I have not yet tested whether my 
@rst files go to the right place when I run the rst3 command.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/16b384f4-0330-483f-bc36-a55a010588d1n%40googlegroups.com.

Re: ENB: For Thomas and Félix: more about PR #3277

[Thomas Passin]

On Thursday, April 13, 2023 at 9:32:36 AM UTC-4 Edward K. Ream wrote:

[...]


*Testing*


*test_g_finalize* and *test_g_finalize_join* were responses to Thomas's 
compatibility concerns. I worked on these two tests for several days before 
realizing that these tests weren't the whole story!


The very first test case in test_g_finalize_join shows the problem. 
g.finalize('a.py') must return an absolute path relative to os.getcwd(), 
*not* the directory containing the outline! In other words, the *callers *of 
g.finalize_join are responsible for specifying the absolute path.


I don't think that this agrees with my understanding of how things have 
worked in the past.  Please correct me if it's not so.

1. Paths in at-files should *not* depend on os.getcwd() because that value 
is state-dependent and is not necessarily defined only by the current 
outline.  The user may have run various scripts that changed it.  This 
could lead to changing and unpredictable locations for external files.

2.  When I create an external file like this, I expect its path to be 
relative to the *outline*:

@file special/good.py

3. When I use an @path node like this, I expect the at file to be located 
at a path which starts with the @path expression:

@path special
@file good.py   # Path should be special/good.py relative to the 
outline.

4. Since the @path expression is to be prepended to the at-file path, if 
the @path is an absolute path, the at-file path should be absolute, not 
relative to the outline.

5. What should happen if *both* the @path and the @file contain absolute 
paths?  Of course, this shouldn't happen but what if it did?  I would say 
that the at-file's path should prevail, the @path should be disregarded, 
and an error message should be given on the first attempt to save the file.

IMO, 2) and 3) are **essential** for stability and sanity.  The changeset 
in devel as of yesterday afternoon behaves correctly with all the outlines 
containing external files I have opened.  I have not yet tested whether my 
@rst files go to the right place when I run the rst3 command.

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/731b6ec6-d615-42bc-b4da-508ecfc11e40n%40googlegroups.com.

Re: ENB: For Thomas and Félix: more about PR #3277

[Edward K. Ream]

On Thursday, April 13, 2023 at 8:32:36 AM UTC-5 Edward K. Ream wrote:

> PR #3276 ...lists all 
the places where arguments to these functions have changed. The PR's 
correctness depends on just those places.

Leo's git-diff-pr command (run from the ekr-3267-simply-path branch) is the 
best way to see the changes. The *c.fullPath* and *c.scanAtPathDirectives* 
methods deserve close inspection. The new code does more with less cruft. 
The PR is likely sound if these two methods are sound.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/64972903-e86c-4be6-aeee-cc5c7aa6fa63n%40googlegroups.com.

ENB: For Thomas and Félix: more about PR #3277

[Edward K. Ream]

PR #3277  proposes 
changes to various path-related functions in leoGlobals.py.

These changes will affect leoJS. I don't expect them to expect Leo's users!

Thomas quite rightly raised some concerns. This Engineering Notebook post 
gives my response. Thomas's gadfly questions caused me to think more 
deeply, create better unit tests, and improve the related code.

*Overview of the PR*

The PR changes many files. Here are the highlights:

- Rename *g.of_path_finalize* to *g.finalize*, retaining the old name for 
compatibility. 
- Rename *g.os_path_finalize_join* to *g.finalize_join*, retaining the old 
name for compatibility.
- Make *g.os_path_expand_user* a synonym for g.finalize.
- *Slightly* generalize g.finalize and g.finalize_join compared with legacy 
code.


*Testing*


*test_g_finalize* and *test_g_finalize_join* were responses to Thomas's 
compatibility concerns. I worked on these two tests for several days before 
realizing that these tests weren't the whole story!


The very first test case in test_g_finalize_join shows the problem. 
g.finalize('a.py') must return an absolute path relative to os.getcwd(), 
*not* the directory containing the outline! In other words, the *callers *of 
g.finalize_join are responsible for specifying the absolute path.


The PR lists all the places where arguments to these functions have 
changed. The PR's correctness depends on just those places.


*Compatibility*


Thomas suggested that better docstrings would help. I have just added 
improved docstrings for the two new functions. However, the code itself is 
likely easier to understand than the words.


I have given careful thought to the question of retaining the legacy code. 
I have chosen not to do so. There is no plausible scenario in which the 
legacy code could be superior to the new code. 


*Summary*


Imo, Leo would be better off with the new code. This PR *might* cause 
compatibility problems, but the likelihood is small. 


I plan to merge the new code in a few days, but I'll wait for Thomas and 
Félix to comment first. There is no rush. All comments are welcome.


Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/8faaf86d-41d3-4a29-b386-6935298f0089n%40googlegroups.com.

Re: Creating Qt Apps That Run In A Tab

[Thomas Passin]

I have re-organized the code a bit to make to easier to read.  It does the 
same job  as before.  Also, I have zipped up the outline to make it easier 
to get from the browser.

More to come soon.

On Sunday, April 9, 2023 at 1:14:13 PM UTC-4 Edward K. Ream wrote:

> On Sun, Apr 9, 2023 at 7:32 AM Thomas Passin  wrote:
>
>> Remind me what you mean by an "info item".  Would this be a GitHub issue 
>> with a "devInfo" or "Info" tag?
>>
>
> Exactly.
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9f4ebafc-550f-4154-9d5a-93804f473b39n%40googlegroups.com.
<>

Re: Example of me using chatGPT

[Thomas Passin]

There was a recent thread about this on python-list, including someone's 
experiments.  Here's what I wrote -

" People need to remember that ChatGPT-like systems put words together the 
way that many humans usually do.  So what they emit usually sounds smooth 
and human-like.  If it's code they emit, it will tend to seem plausible 
because lines of code are basically sentences, and learning how to 
construct plausible sentences is what these systems are built to do. That's 
**plausible**, not "logical" or "correct". 

The vast size of these systems means that they can include a larger context 
in figuring out what words to place next compared with earlier, smaller 
systems. 

But consider: what if you wrote code as a stream-of-consciousness process?  
That code might seem plausible, but why would you have any confidence in 
it?  Or to put it another way, what if most of ChatGPT's exposure to code 
came from StackOverflow archives? 

On top of that, ChapGPT-like systems do not know your requirements nor the 
reasons behind your requests.  They only know that when other people put 
words and phrases together like you did, they tended to make responses that 
sound like what the chatbot emits next.  It's basically cargo-culting its 
responses. 

Apparently researchers have been learning that the more parameters that a 
system like this has, the more likely it is to learn how to emit responses 
that the questioner likes.  Essentially, it could become the ultimate 
yes-man! 

So there is some probability that the system will tell you interesting or 
useful things, some probability that it will try to tell you what it thinks 
you want [to] hear, some probability that it will tell you incorrect things 
that other people have repeated, and some probability that it will 
perseverate - simply make things up. 

If I were going to write a novel about an alternate history, I think that a 
chatGPT-like system would be a fantastic writing assistant. Code? Not so 
much."   

On Thursday, April 13, 2023 at 8:15:59 AM UTC-4 Edward K. Ream wrote:

> On Thursday, April 13, 2023 at 12:15:17 AM UTC-5 Félix wrote:
>
> Here I am, (simple screenshot below) working on leojs, converting the 
> stripBOM function from leoGlobals.py from python to typescript.
>
> Have you tried? Any thoughts or particular productivity tips to share?
>
>
> My impression is that chatGPT does well on small tests. I wouldn't trust 
> it with larger tasks.
>  
>
> (*I eventually plan to use Leo to organize and automate calls to it's 
> API, to make some kind of agi-assistant experiment.*)
>
>
> chatGPT has spawned many creative ideas including yours. Please let us 
> know what happens :-)
>
> Edward
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0995d4b7-8d77-4ae8-b477-15bc7db1f904n%40googlegroups.com.

Re: Example of me using chatGPT

[Edward K. Ream]

On Thursday, April 13, 2023 at 12:15:17 AM UTC-5 Félix wrote:

Here I am, (simple screenshot below) working on leojs, converting the 
stripBOM function from leoGlobals.py from python to typescript.

Have you tried? Any thoughts or particular productivity tips to share?


My impression is that chatGPT does well on small tests. I wouldn't trust it 
with larger tasks.
 

(*I eventually plan to use Leo to organize and automate calls to it's API, 
to make some kind of agi-assistant experiment.*)


chatGPT has spawned many creative ideas including yours. Please let us know 
what happens :-)

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/92b1fd06-a5d2-44e8-8179-0ef7eb74566cn%40googlegroups.com.

Re: Eye surgery tommorrow

[Edward K. Ream]

On Tuesday, April 11, 2023 at 4:46:36 PM UTC-5 Edward K. Ream wrote:

It's routine cataract surgery. I may be out of commission for a day or 
three.


Thanks for all the well wishes.

The surgery appears to have gone well. The eye is blurry, but apparently 
that's normal. I'll see my eye doc later today.

Edward

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/0c9749c6-8824-4e9e-b328-1d4c3c20ee4cn%40googlegroups.com.