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
Conversation
- 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
Add Appstream metainfo and more
also add some more fields to the metainfo. and use "Pure Data (Pd)" as the application name.
better than renaming...
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
* 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)
As a user for a possible libpd GUI communication API with my PdParty application on iOS, I would like:
|
This comment was marked as resolved.
This comment was marked as resolved.
As I assume In any case, I needed at least one commit to be able to open a PR, so I chose those in |
This comment was marked as resolved.
This comment was marked as resolved.
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:
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 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. |
to keep the posts managable, i've opened a discussion #1694 (more to follow) |
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. |
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:
Refactor away (or at least centralize) Tcl/Tk string formatting within the core
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, ...")
Possible workflow (step by step without large changes at once):
References:
Questions / Considerations (so far):