Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot dynamically remove GUI elements and constraints #30

Closed
dmlockhart opened this issue Aug 11, 2014 · 5 comments · Fixed by #814
Closed

Cannot dynamically remove GUI elements and constraints #30

dmlockhart opened this issue Aug 11, 2014 · 5 comments · Fixed by #814

Comments

@dmlockhart
Copy link

Although I've found its possible to dynamically add GUI elements (e.g. create and display a new view on button press), there doesn't seem to be a way to dynamically delete GUI elements.

For example, I was trying to create a 'show/hide' button for a specific GUI element. I haven't been able to figure out how implement this in the current version of Toga.

I was expecting that deleting a Toga GUI element using del my_element would remove that element and all constraints related to it, but this doesn't seem to be the case.

Is there another way to achieve this functionality?

@freakboy3742
Copy link
Member

At present, no - the APIs for this haven't been developed. Toga is a very early stage project - there's lots of work still on the TODO list, and deleting widgets is part of that list.

jrwdunham added a commit to dativebase/dativetop that referenced this issue Jul 4, 2019
- Used Beeware Toga to attempt to create a native GUI for the core
  DativeTop functionality, namely CRUD operations on OLD instances and
  local-remote synchronization configuration.
- This experiment indicates to me that Toga is too immature for real
  software. Note that this has been an open issue from 2014-08 to 2019-06:
  beeware/toga#30 "Cannot dynamically remove
  GUI elements and constraints". This is a deal-breaker for building the
  DativeTop GUI with Toga.
- Beeware Briefcase can still be used to package the DativeTop meta-app.
  However, future DativeTop GUI development should be in a JavaScript,
  or compile-to-JS, framework.
jrwdunham added a commit to dativebase/dativetop that referenced this issue Jul 4, 2019
- By this commit, the DativeTop proof-of-concept works:

  - It reliably launches a native Mac OS app that displays functioning Dative
    in a Cocoa WebView.
  - It reliably serves the OLD locally and displays a DativeTop native
    dashboard GUI for managing the local Dative and OLD.
  - Note: creation of new OLD instances from the DativeTop GUI is where the
    limitations of Toga were so great that the Toga strategy was terminated.

- detailed feature list

  - Add basic DativeTop Toga GUI

    - Used Beeware Toga to attempt to create a native GUI for the core
      DativeTop functionality, namely CRUD operations on OLD instances and
      local-remote synchronization configuration.
    - This experiment indicates to me that Toga is too immature for real
      software. Note that this has been an open issue from 2014-08 to 2019-06:
      beeware/toga#30 "Cannot dynamically remove
      GUI elements and constraints". This is a deal-breaker for building the
      DativeTop GUI with Toga.
    - Beeware Briefcase can still be used to package the DativeTop meta-app.
      However, future DativeTop GUI development should be in a JavaScript,
      or compile-to-JS, framework.

  - Separated app.py into multiple modules under dativetop/
  - Add config JSON file for DativeTop
  - Make icons work
  - Add Makefile develop and build conveniences
  - Improved README.rst
  - dativetop/app.py App class now correctly shuts down when the user quits.
  - Add docstrings to scripts/register-old-with-dative.py
  - Add pinned beeware==0.1.1 and pyperclip==1.7.0 to requirements; added
    requirements.txt which points to requirements/base.txt.
  - Bump OLD submodule to branch dev/issue-4-offline at commit
    ea949ff1c131e50d9fd3fa66d477db253855f3e7 "Modify requirements/ files to
    facilitate SQLite".
@samschott
Copy link
Member

@freakboy3742, I was thinking of working on this but wanted to check first what a good API would look like. At the moment, there is only the Widget.add(*children) method and I am thinking of adding the following:

  • remove(*children) removes given children from the widget.
  • insert(index, child) inserts the given child at the index.

One could additionally or alternatively also provide:

  • insert_before(child, new_child) inserts new_child before child.
  • insert_after(child, new_child) inserts new_child before child.
  • replace(child, new_child) replaces child with new_child.
  • remove(index) removed child at index.

Personally, I am in favour of keeping it simple and just having the first two methods.

@freakboy3742
Copy link
Member

@samschott I'd say the first of the two suggestions would be my preferred option, as it's closest to the Python List interface (and thus less likely to be surprising).

Adding an index-based using __getitem__ might also be useful (e.g., widget.children[n] = child or del widget.children[n]). However, I'd consider supporting these of secondary importance to the main remove/insert interface.

@samschott
Copy link
Member

samschott commented Feb 10, 2020

Agreed. I'll give it a try.

@obulat
Copy link
Contributor

obulat commented Jun 5, 2021

This issue has been solved in #814

@obulat obulat closed this as completed Jun 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants