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

[WIP] GUI abs(traction) layer 🏋 #1693

Merged
merged 42 commits into from Sep 1, 2022
Merged

Conversation

danomatika
Copy link
Contributor

@danomatika danomatika commented Jun 13, 2022

This is research/brainstorming PR for refactoring the communication between the Pd core and the GUI.

Note: This is not a full, open rewrite away from Tcl/Tk but a refactor and abstraction to allow for implementing custom GUIs without worrying about Tcl-specifics. Also, this current work maintains the editing logic within the core.

Please keep the discussion focused on technical considerations. This is not meant to be a GUI feature wish list!

Goals:

  1. Refactor TCL-specific string handling & escaping into single function / interface #1694
    Refactor away (or at least centralize) Tcl/Tk string formatting within the core
  2. toolkit-agnostic Core->GUI Communication #1695
    Move GUI API drawing specifics out of the core into the GUI (ex: "draw a bng" as opposed to "draw a box, draw a circle, draw an inlet, draw an outlet, ...")
  3. Develop/implement a communication API (which could also be used by externals)
  4. Allow for message communication via callback as well as network for use in libpd
  5. Maintain modularity for the layer (ie. refactor into separate file that could extended or compiled optionally?)
  6. Accomplish the points above without breaking anything... 🤭

Possible workflow (step by step without large changes at once):

  • Refactor TCL-specific string handling & escaping into single function / interface
  • Refactor one GUI object or drawing routine, ie. something simple like "bng"
  • Finalize communication specs
  • Refactor other GUI objects
  • Create an example GUI external?
  • ...

References:

Questions / Considerations (so far):

  • What about dialogs?
  • We should provide a set of basic drawing routines for data structures and externals.
  • How to optimize array draw communication, etc?

mxa and others added 30 commits August 4, 2021 13:27
- Exec: provide arguments to 'pd-gui' so dragging files on the deskto icon launches Pd
- Categories: see https://specifications.freedesktop.org/menu-spec/latest/apa.html
  - replace the invalid "Multimedia" with "AudioVideo"
  - add "Development"
  - add "Music"
  - add "Graphics"
- Comment: slightly different wording with a couple of translations
- NoDisplay: drop the explicit setting to "false" (it's the default anyhow)
AppStream prefers the scheme: <tld>.<vendor>.<product>
and AppStream forces us to use the same id for the .desktop file as for the
 appstream metainfo.

so let's switch now, rather than later...
to be used by app-store like software, e.g. "gnome-software"
The same file is available as tcl/pd.xpm
also add some more fields to the metainfo.
and use "Pure Data (Pd)" as the application name.
fixups and automate installation of mimeinstall
…on an non-available xy position (eg. in a multi-monitor setup).
also remove redundant gatom_senditup.
don't set EOF if there is a pending "open" request
copy t_soundfile struct with mutex locked because it might be set concurrently in readsf_child_main() resp. writesf_child_main()
+ remove redundant sfread_cond_signal() call
Spacechild1 and others added 12 commits May 25, 2022 13:30
* fix [route] rejected output for bang input with float arguments

currently, nothing is output, this fixes it

closes #1678
in 2022, there are a couple of text editors out there,
that will automatically break lines at whatever position you want.
it's probably not "notepad.exe" (but you really shouldn't use that anyhow)
fixes a regression of 8f089c7
that would prevent autopatching (as whenever a new object gets created
with the old one not yet instantiated, the text would be lost)
@danomatika danomatika added feature suggestion for an enhancement subject:GUI things concerning the GUI side subject:core things concerning the Pd-core subject:code-cleanup cleaning up the code-base subject:API "External Programming Interface" (things concerning development of externals) improvement improves an existing functionality without adding new features subject:libpd things concerning libpd labels Jun 13, 2022
@danomatika
Copy link
Contributor Author

danomatika commented Jun 13, 2022

As a user for a possible libpd GUI communication API with my PdParty application on iOS, I would like:

  • replace my custom UIKit & CoreGraphics Pd GUI implementations with simply drawing calls controlled by the pd core.
  • pipe input events from UIKit into the pd core to allow for consistent behavior between desktop and (mobile) Pd
  • add multitouch event handling within Pd for those GUI APIs / frameworks which support more than a single mouse

@Spacechild1

This comment was marked as resolved.

@danomatika
Copy link
Contributor Author

danomatika commented Jun 13, 2022

As I assume develop can/should be merged at some point, I would keep it pointed to master. OTOH if your question is more a workflow issue, then maybe it makes sense to point to develop.

In any case, I needed at least one commit to be able to open a PR, so I chose those in develop.

@Spacechild1

This comment was marked as resolved.

@Spacechild1
Copy link
Contributor

Spacechild1 commented Jun 13, 2022

I agree with the goals and workflow suggestion!

As someone who wants to write a (fast) alternative desktop GUI, I would like to emphasize the importance of goal number 2:

Move GUI API drawing specifics out of the core into the GUI (ex: "draw a bng" as opposed to "draw a box, draw a circle, draw an inlet, draw an outlet, ...")

With GUI frameworks like Qt you would not draw Pd objects by issuing individual canvas drawing commands. Instead, you would instantiate a single (custom) Qt widget that already knows how to draw itself. This would be much more efficient because
a) there's only a single command to send to the GUI (= less traffic)
b) there will be fewer objects in the canvas container (e.g. QGraphicsScene).

Actually, a) would also apply to the Tcl GUI.

It also gives the widget a chance to decide how it wants to draw itself. For example, it might want to use vector graphics instead of individual draw calls.

@umlaeute umlaeute marked this pull request as draft June 13, 2022 15:04
@umlaeute
Copy link
Contributor

to keep the posts managable, i've opened a discussion #1694 (more to follow)

@millerpuckette millerpuckette merged commit 48f229e into master Sep 1, 2022
@umlaeute
Copy link
Contributor

umlaeute commented Sep 1, 2022

this pseudo-PR got accidentally closed as a side-effect of merging #1696 (:tada: for that).

it's probably better to use github discussions and projects instead of such a meta PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature suggestion for an enhancement improvement improves an existing functionality without adding new features subject:API "External Programming Interface" (things concerning development of externals) subject:code-cleanup cleaning up the code-base subject:core things concerning the Pd-core subject:GUI things concerning the GUI side subject:libpd things concerning libpd
Projects
Status: In Progress
Development

Successfully merging this pull request may close these issues.

None yet