Howto reference a common data source to update a value across the 'app'?

[tfcroft4]

It seems to be tricky (for me) to access and update values of widgets from different parts of an app.
#1325 suggests the way to update a value across a Toga app is:
"preferably, with a reference to a common data source that, when updated, is reflected in the app's GUI"
I have a 'feedback' Text box which is a child of the main_window and I would like to update it from actions in a separate class that defines a box in an option container which is also a child of the main_window.
In the example below I want to report the outcome of a file upload process - Success or Failure.
Is the treesource example the best starting point to create a shared datasource for a Text Box?
Or perhaps there a simple example to get started with?
I hope that this makes sense.
Thanks

[freakboy3742]

There's two answers to your question.

The first is the pragmatic, "works right now" answer. The sibling relationship between widgets in a layout doesn't matter. All that matters is that you can get a reference to another widget. So - you create the text input as self.my_input = toga.TextInput(...), so it's a property of the app; the button has an on_press handler def my_press_handler(self, widget, **kwargs) which is a method on the app; and that method talks about self.my_input.value = "new value" - accessing the text input as a property of the app - and you're done. The button has referenced and updated the value in the text input.

You can slightly decouple things by using the widget registry - instead of assigning the self.my_input = toga.TextInput(...), you give the TextInput an id, and then in the button handler, you look up the widget ID with either app.widgets[id] or window.widgets[id] to retrieve the widget by ID. Fundamentally, this isn't really any different - you're still using the app (or window) as a point from which you can obtain a reference to other widgets.

Your comments about "shared data source" hint in the direction of the longer term solution - but that solution doesn't currently exist. Toga does contain a ValueSource, which is the "single value" equivalent of TreeSource/ListSource - but, at present, you can't use a ValueSource for anything. Ideally, you would be able to use a ValueSource as the data behind a TextInput - so then, whenever the ValueSource is changed, the TextInput would change, and vice versa.

However, that won't change the underlying issue that made the "pragmatic" solution possible. You need a reference to something to represent the data- and that will mean either assigning something to the app, or using some other "registry" (be that the app/window widget registry, or something else).

If you want an example of this - Toga Tutorial 1 (The Fahrenheit to Celsius converter) in the examples folder of the Toga folder demonstrates this - you press a button, and the value of one text input is used to update another text input.

[tfcroft4]

Thanks again for your insight. Very Helpful. But a few more questions.
Are app and window global and accessible from within a class? I have created separate classes for each Tab display.

The programmatic change to a text value would seem to have a solution. I will test the proposed methods to identify the widgets.
Are there any constraints on widget ids? Any sensible Python string.

My aim is to have a settings summary in a table with a data source then separate Input widgets that can update row items in the table source. (and trigger a display update unless that would be auto magical)
{Not visible in the screen shot but the data changes on the Query Tab and the table is on the Settings Tab.}
Some widgets may be text entry but one may be a File Dialog returned file name. i.e. a programmatic update rather than a text input as such.
If I understand this correctly a ListSource is a separate entity.
The data shown by a table can be changed by setting or resetting the data property of the table.
Change Data in Text Input => Change Table Data Source = > Table updated to reflect changes
(input of programmatic) => lost focus or on change event to update List Source? = > trigger table update or is this automatic?

Cheers
Ted

[freakboy3742]

App is a global singleton, because you can only have one app object - you can access it via toga.App.app.

There's no "window" global because your app can have many windows. But the list of windows is accessible via windows attribute on the App.

Or - you pass the window as context to the thing that needs to know about the window. If you need f() to know about x... you pass x as an argument to f... f(x). Or, you reverse the dependency, and pass a reference of the handler that does know about the window to f(), and then install that handler in the body of f().

As for the rest of your description of your problem - a ListSource is representation of data that is decoupled from the Table widget. If you update an entry in a ListSource, the display in the Table widget will be updated. How you choose to update the ListSource is up to you - but one option would be a handler on another widget reacting to a change in value, a button press, etc.

[tfcroft4]

I am getting my head around this.
This button callback updates a textbox with id = 'weblog' with the id of the Button that was pressed. So using widget id resolved the cross app communication

    def upload_callback(self,button):
        # handle event                
        toga.App.app.widgets["weblog"].value = button.id

Now looking at ListSource updates so making progress.
Thanks again

[tfcroft4]

Continuing my Toga education.
Looking at the Movie example which has a class derived from Source I am trying to understand how the table data is set and changed.

https://github.com/beeware/toga/blob/main/examples/table_source/table_source/app.py

There is a table definition:

        self.table1 = toga.Table(
            headings=["Year", "Title", "Rating", "Genre"],
            data=MovieSource(),
            style=Pack(flex=1),
            on_select=self.on_select_handler,
        )

then later

        # Populate the table
        for entry in bee_movies:
            self.table1.data.add(entry)

Some questions.

• Could some one explain how data=MovieSource() works as a data source?
  I would think that MovieSource() would be an object but perhaps not.
• Why is the table1.data populated directly if the data is set as MovieSource() or does this assignation have a different purpose?
• Is table1.data automagically updating the MovieSource and / or visa versa?
• In this example how do the notify actions work?

Thanks - I am still learning!!
Ted

[freakboy3742]

• Could some one explain how data=MovieSource() works as a data source?
  I would think that MovieSource() would be an object but perhaps not.

MovieSource is a class; () means instantiating that class to produce an instance (an object). Why wouldn't it be an object?

As for "how it works"... I'm not sure what you're asking. It's a data source. That's one of the forms that the widget can accept data - and it's the canonical form that a widget uses. No matter what value you give to data when the Table is constructed, it's converted into a Source - but if you give it a source, it doesn't need to alter anything.

Ultimately, a ListSource is really not much more than a "smart" Python list - a list that can notify others when a row is added, deleted, or modified. But it's specified as an interface so that internally it doesn't have to be implemented as a Python list - it could be backed by live calls on a REST API, as long as it can satisfy data access requests.

• Why is the table1.data populated directly if the data is set as MovieSource() or does this assignation have a different purpose?
• Is table1.data automagically updating the MovieSource and / or visa versa?

Again - I don't understand the question. table.data is a source - no matter how it was initialised. table.data.add()... add a row to that data source.

• In this example how do the notify actions work?

When data changes, the source notifies any widget listening to the source describing the change; that widget then updates/redraws as necessary.

However, the example you've provided doesn't make any mention of notifications, and generally speaking, you shouldn't need to concern yourself with notifications, because they're an internal detail. So - I'm not sure if I've answered your question.

[tfcroft4]

Thanks for the reply and clarification. I only ask to gain understanding.
So
In the movie example the table data is linked to a class instance or object derived from the Source class.
That object has add , delete etc. functionality to manage the 'rows' in the data source.

In the example the table data is initiated with static data from outwith the class. Could this also be achieved when the source object is initialised. e.g. Read from a file or the REST API you suggest? In this case how would the table data initialisation occur.

The object can notify any widget listening however in the movie example there are no listeners so the notifications just 'disappear into the wind'.

Thanks again.
Ted

[freakboy3742]

Thanks for the reply and clarification. I only ask to gain understanding.

I don't doubt that's what you're trying to do - and I'm happy to help.

So In the movie example the table data is linked to a class instance or object derived from the Source class. That object has add , delete etc. functionality to manage the 'rows' in the data source.

Yes - it is a class that satisfies the interface requirement of a Source. How it satisfies that interface is irrelevant to the operation of the table; and how the table uses the source is irrelevant to to the implementation of the source.

In the example the table data is initiated with static data from outwith the class. Could this also be achieved when the source object is initialised. e.g. Read from a file or the REST API you suggest? In this case how would the table data initialisation occur.

With a constructor (__init__). It's a class. Pass in whatever initialisation data is needed to the constructor when you create the class. Want to use a literal list? Pass in a list. Want to use a data file? Pass in the data file. Want to use a REST API? Pass in the URL. As long as your source implementation satisfies the Source API, a Table can use it.

The object can notify any widget listening however in the movie example there are no listeners so the notifications just 'disappear into the wind'.

The table is a listener on the source. You don't have to set that up manually because you specified the source as data for a table instance, which automatically sets up the listening relationship.

The problem I'm having here is that I'm not clear at all what you're trying to achieve. There's clearly a knowledge gap that you're trying to fill, but it's not clear to me where that gap is. You're asking details about the deep internals of Toga... but simultaneously getting stuck on relatively fundamental Python concepts. I'm not sure if that's an artefact of a bad example on Toga's part, or a lack of Toga (or Python) experience on your part (... or both...) - if I had a better idea about where you're coming from and what it is you're trying to do, I might be able to provide better guidance.

[tfcroft4]

Thanks for the reply. To answer your last question.
( I am moving a Windows application to Python so that it can be deployed on other desktop platforms such as MacOS. Toga and Briefcase seemed to provide a suitable development methodology that would met that requirement.)

This is the small step I am working on. The application has 'settings' that can change from time to time but should persist across each use.

Ideal: A table to show 'settings' and 'values' these are used to customise the application and may have say a datatafile value, a database query to run on a selected database. The values can persist by being saved and loaded to and from an INI file. ( An INI text file so that if necessary values can be changed separately from the application.) { other persistence methods may be available.}
Table Row values may be changed from a separate set of text boxes and on change the table data is saved out to the INI file.

I have been looking at:
Using a Custom Source which would also incorporate the data file loading and saving.
Alternatively separate the settings loading and saving into a separate module and use the default ListSource class to manage the data loading and saving.

My previous questions arose as I tried to use a Custom Source solution using the Movie example as a starting point.

Yes - this is a jump from playing with Python to building with Python!!
Cheers
Ted

[freakboy3742]

As I suspected, you're likely massively overthinking things :-)

If all you want is the ability to load from an INI file, allow modifications, then save to an INI file... then do that. There's no need to define a custom data source.

Define a function that can load your INI file into a list of tuples, then set the data on the table to the result of that load method.

Implement a UI that allows users to modify values as required.

Then define a save method that iterates through all the data in the source, writing it out in INI format; and call that save method with a menu item/button as needed.

Could you do this with a custom data source? Sure. You could write a data source that is able to take the path to an INI file on constructions, loads that INI file into an custom internal formal, auto-rewrites the INI file every time there's a modification (or synchronises with disk on a regular interval)... but... do you actually need that?

If all you need is "read file, change value, save file", wrapping it the 2 new methods (load and save) in a data source isn't actually going to improve anything that much. There might be a mild code organization benefit, but that's about it.

The value of DataSource is when you need to have multiple widgets displaying the same data - in the case of the TableSource example, there's a single data source and two tables viewing that data.

The other value is when the data isn't easy to store in a static "list of tuples" format - e.g. if it needs to come from an API. But that's not "load from a file" unless you're thinking at the level of "synchronised transactional database" which... seems like overkill for your situation.

[tfcroft4]

Thanks - lets say exploring the boundaries or the options.
The documentation says. "While this is useful for quick demonstrations, or to visualize simple data, more complex applications should define their own custom data sources."

I suppose it depends on the definition of more complex in this context.

The database processing comes in part two .... but that is a read only process running pre defined queries.

Cheers
Ted

[tfcroft4]

I have worked on the table widget reading data in from a file and also saving data to a file but found the table not updating the display.
The GUI had a table in an opcontainer and I found the display was not updating as well as the already reported issue of the table columns being narrow.
I rebuilt the GUI so that I had a table at the top level within the main box as well as a second table in an opcontainer.
I added a series of tests to append, update and delete rows and ran the tests against each table. The table at the top level worked as expected under the tests. The table in the opcontainer had problems, the display does not always update on a data change or the data change is defered to a subsequent action.

• Add Row : OK new row is displayed ;
• Change value using setitem : table display does not show the change but reading the data back shows it has been updated in the ListSource;
• Delete Row OK and also displays the deferred data change.

I think a lot of my earlier challenges were caused by my GUI design with a table in a box in an opcontainer not acting as expected.
This may be an extension to "Winforms Table not expanding columns when table is inside a box #2974"

For now I will see if I can redesign the GUI to avoid the table in opcontainer design.

Should we close this and I can come back later if necessary as I have strayed away from the Discussion Title?
Ted
PS It would be good if the ListSource returned a data structure for a row that could be edited and resubmitted to update a table entry row. Perhaps I have missed something? However I managed to create a function for this but it seems a bit of a hack.
PPS
For the original question this style of code works to update a specific text box where the text box has an id set:
toga.App.app.widgets["testtext"].value = "Appended 'Zaphod Beeblebrox, 47'"

tabletest.zip

[freakboy3742]

Should we close this and I can come back later if necessary as I have strayed away from the Discussion Title?

Well, this is a discussion topic, so there's no real "close" here; but yes - if you think you've found a new issue, then it should be a new issue. In particular, if you believe you've found a reproducible bug, then you should open an issue with a reproduction case.

The example project you've provided here is on the right track in terms of being a reproduction case, although it's definitely on the more complex end of what would be preferable - and it needs a clear set of "this is how you drive it" instructions, accompanied with "This is what I expected, this is what I got" notes.

PS It would be good if the ListSource returned a data structure for a row that could be edited and resubmitted to update a table entry row. Perhaps I have missed something?

I think you have. The default ListSource returns a row object. The row object has attributes that match the column name accessors. You can modify those attributes, and they'll be reflected as data changes. You don't need to "resubmit" anything. If the ListSource has a Row, you can modify that row.

[tfcroft4]

Thanks for the pointer I now see how to use __setattr__

                        #use __settattr__ for this row to set new value
                        tablet.data[rowid].__setattr__('age',999)

I have opened an issue regarding the table in container bug
#3046
Thanks again
Ted

[freakboy3742]

Ok... so.... that's not what I said. I said:

The row object has attributes that match the column name accessors. You can modify those attributes, and they'll be reflected as data changes.

That is:

tablet.data[rowid].age = 999

Functionally, that will ultimately involve a call to __setattr__ - but __setattr__ is an internal implementation detail. If you're ever invoking a "dunder" ("double underscore") method in Python, you're almost certainly doing it wrong.

[tfcroft4]

Thanks for clarifying that. I think I ended up using the 'wrong' approach because the changes I was trying to make were not reflected in the display. Lesson leaned.
Ted