Please help me understand the syntax of some statements in the usbserial4a example
Jean-Marc Delaplace
Elliot Garbus
This code is not what I would describe as connectional. It is a rather unique use to create a dictionary to store widgets. More conventionally, there is a dictionary called ids that is created and populated when kv lang is processed. I don’t know if this code is particularly old – or just “different”
On to your questions:
1- line 45
on_parent: app.uiDict['sm'] = self # in the context, self is the screenmanger.
and line 156
self.uiDict['sm'].current = 'screen_test' # current is an attribute of the screenmanager, it changes the current screen to the screen, ‘screen_test’
More conventionally, line 156 would read:
self.root.ids.sm.current = ‘screen_test’ # where sm referes to the id in the kv code, and self.root.ids.sm is the screenmanager instance.
Looking at bigger section of the kv code to answer your next question:
Screen:
name: 'screen_test'
BoxLayout:
orientation: 'vertical'
ScrollView:
size_hint_y: None
height: '50dp'
TextInput:
id: txtInput_write
on_parent: app.uiDict['txtInput_write'] = self
size_hint_y: None
height: max(self.minimum_height, self.parent.height)
text: ''
Button:
id: btn_write
on_parent: app.uiDict['btn_write'] = self
size_hint_y: None
height: '50dp'
text: 'Write'
on_release: app.on_btn_write_release()
ScrollView:
TextInput:
id: txtInput_read
on_parent: app.uiDict['txtInput_read'] = self
size_hint_y: None
height: max(self.minimum_height, self.parent.height)
readonly: True
text: ''
The parent attribute of widget holds the widgets parent in the widget tree. The event on_parent is fired when the parent is set. This is being used to load the widget into the app.uiDict dictionary.
So
app.uiDict['txtInput_write'] is the TextInput widet, and app.uiDict['txtInput_write'].text is the text that was input.
Similarly app.uiDict['btn_write'], is the button and app.uiDict['btn_write'].text is the text that appears on the button.
More conventionally you would access these in the App class as
self.root.ids.sm.get_screen(‘test_screen).ids.txtInput_write
It is possible that there is threading conflict. There is a new thread being created, line 153:
if self.serial_port.is_open and not self.read_thread:
self.read_thread = threading.Thread(target = self.read_msg_thread)
self.read_thread.start()
--
You received this message because you are subscribed to the Google Groups "Kivy users support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kivy-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kivy-users/5bcac92c-8e9b-4915-a40a-9b35678360ddn%40googlegroups.com.
Jean-Marc Delaplace
Elliot Garbus
There is a main thread that is running the UI, and a second thread that is read_msg_thread.
The threading module is part of the python standard library, there a number of synchronization primitives’ including semaphores.
https://docs.python.org/3/library/threading.html
and some examples: https://pymotw.com/3/threading/index.html
I’m not familiar with the serial library that is being used, but often these kinds of libraries are non-blocking, so it is not necessary to use threads.
I do music programming with MIDI (just another serial protocol) and I use the Clock.schedule_interval() method in kivy to poll the read port at a regular interval.
To view this discussion on the web visit https://groups.google.com/d/msgid/kivy-users/bc5d3150-1fbd-494c-ba96-955ce0159df2n%40googlegroups.com.
Jean-Marc Delaplace
Elliot Garbus
Here is what I would recommend:
Do not use threading, it is not required in this case.
In App, create a Clock.schedule_interval(your_read_method, time_in_seconds), that calls the read method at an interval that makes sense for your app.
Alternatively,
Require a lock to access the shared variable. OR
use a recycleview, and just keep adding data to a scrolling list.
To view this discussion on the web visit https://groups.google.com/d/msgid/kivy-users/f17a105e-8f78-49bb-a666-833e0c07c6f7n%40googlegroups.com.
Jean-Marc Delaplace
Elliot Garbus
😊 Good Luck, let me know how it works out!
To view this discussion on the web visit https://groups.google.com/d/msgid/kivy-users/82ae266b-85ce-4c56-84b5-def770a38c37n%40googlegroups.com.
Jean-Marc Delaplace
It does. Thanks again!
Jean-Marc Delaplace
Elliot Garbus
If you share your code I’ll take a look.
To view this discussion on the web visit https://groups.google.com/d/msgid/kivy-users/137417f0-84d7-482f-a493-918c48d3ed51n%40googlegroups.com.
Jean-Marc Delaplace
Elliot Garbus
This code is using threading. Is this the right one?
To view this discussion on the web visit https://groups.google.com/d/msgid/kivy-users/d740b83c-a7ab-4d36-b8f8-47860e13e136n%40googlegroups.com.
Jean-Marc Delaplace
Elliot Garbus
I see two things I suggest you look at.
- In the threaded code the socket is opened unconditionally at the start of the code. In the timer version, opening the socket is done conditionally. Is the socket opened?
- Doing a file comparison of the 2 files, there are a lot of changes beyond just moving from threading to the timed loop.
To view this discussion on the web visit https://groups.google.com/d/msgid/kivy-users/c554b215-f310-4c67-b7c3-8ed85a879fc0n%40googlegroups.com.
Jean-Marc Delaplace
Elliot Garbus
I think that is an Android specific behavior. The clock will continue to run on a desktop os.
I had not expected that – but I should have.
You can get the synch primitives working or and another option you could use a double ended queue from the collections module. https://docs.python.org/3/library/collections.html#collections.deque
This would remove the conflict of writing and clearing the same variable.
The data source fills the queue (append), the display method pulls data from the queue (pop).
To view this discussion on the web visit https://groups.google.com/d/msgid/kivy-users/a4357d8a-a38e-42f2-8f9e-789f8ed39687n%40googlegroups.com.
planckp...@gmail.com
planckp...@gmail.com
jeanmark wrote:
Thank you for your intervention. SInce I am new to this
environment, I still know very little. Can you explain the purpose
of
daemon = True
?
https://docs.python.org/3/library/threading.html
https://realpython.com/intro-to-python-threading/#daemon-threads
For your information, currently I am in the learning phase. My aim is to write an application that acquires a flow of data from a serial source connected to the USB of my tablet, reformat this data and send it out over wifi and also to an app (called TouchOSC) that expects data from the ethernet socket. My application will continuously run in the background, read incoming characters, format them and send some of them through wifi to the outside world, and another part of them to localhost so that the TouchOSC application which runs in the foreground, can display this data.
So the use of the display in my app will be only for debugging purposes, since my app will not be visible to the user in the normal operation.
It sounds like you want all the functionality in an Android Service.
And if you own TouchOSC it should start/stop the service, if not your Kivy app is trivial just start and stop the service.
In this context a service is basically a Python script, possibly with a loop to enable IPC with the app. No Kivy used. I/O will presumably be in thread(s) so as not to stall the IPC loop.
https://python-for-android.readthedocs.io/en/latest/services/
Some time ago I shared this trivial runable Kivy/Android Service example:
https://groups.google.com/g/kivy-users/c/7WKYPLMoZac/m/SQhvsXRcAAAJ
That example uses OSC for IPC (read the OSC notes in the top of main.py); so there may be some relation to TouchOSC?
Anyway, that is everything I have. Any implementation issues you may find - Google is your friend ;)