Hi,

> Write or find a Tcl parser and bind all the tcl comands coming from Pd to
> new functions written for whatever toolkit you like.

This is what I would like to avoid my all means :-) The Tcl commands are, well, 
just too Tcl specific.

> Make an abstraction layer between Pd and the TCL calls, and swap in compatible
> calls to another toolkit.  This has been proposed a few times but seems like
> major surgery.

I think this is the way to go! It would certainly require major surgery but I 
think it would pay off tremendously in the future, because people could easily 
do alternative GUIs without forking the core. But first someone has to come up 
with a proof of concept.

Christof


> Gesendet: Dienstag, 27. August 2019 um 03:43 Uhr
> Von: "Miller Puckette" <[email protected]>
> An: "Christof Ressi" <[email protected]>
> Cc: pd-dev <[email protected]>
> Betreff: Re: [PD-dev] Why don't we implement zooming in Tcl?
>
> Well, possiblities:
>
> Rip the GUI out and replace it (this is done in Purr Data)
>
> Write or find a Tcl parser and bind all the tcl comands coming from Pd to
> new functions written for whatever toolkit you like.  This was done once
> by a very smart person and shown (I think) at the first Pure Data Convention
> (Graz!)  Perhas Iohannes will remember who this was or know how to find it.
> Maybe it's even in the Pd convention book...
>
> Make an abstraction layer between Pd and the TCL calls, and swap in compatible
> calls to another toolkit.  This has been proposed a few times but seems like
> major surgery.
>
> (previous suggestoin, lite version) - Hang onto Tcl/Tkfor dialogs and the
> like, but redo the "pd window" calls using some other toolkit (less major
> surgery, but then you're using two toolkits, ugh.)
>
> Do somtheing not int he above list (and that I haven't though of :)
>
> M
>
>
> On Tue, Aug 27, 2019 at 02:38:17AM +0200, Christof Ressi wrote:
> > > Maybe I'm missing something obvious?
> >
> > Of course I did... We send raw Tcl commands from the core with the actual 
> > canvas coordinates and this complicates things because of how Tk's "scale" 
> > method works...
> >
> > Maybe it's time to eventually refactor the GUI messaging and use abstract 
> > commands instead of actual Tcl code, with logical coordinates instead of 
> > actual coordinates... This would mean that zooming could be implemented 
> > easily on the GUI side.
> >
> > But what's more important: people can replace the Tk GUI with other 
> > (better) GUIs. I think the libpd people would love that as well, because 
> > apps could easily integrate Pd's GUI into their GUI framework of choice. 
> > Also, people can offer alternative GUIs for Pd vanilla. Personally, I can 
> > imagine writing a Qt GUI. This would be similar to how Supercollider has 
> > alternative language clients which all talk to the Server via well-defined 
> > OSC messages.
> >
> > <rant>
> >
> > I appreciate Pd's minimalism but a simple GUI should also be a *fast* GUI. 
> > The Tk canvas implementation is actually pretty terrible performance-wise. 
> > Moving an object in a larger patch maxes out a whole core(!) on my Laptop. 
> > It appears that Tk simply redraws the whole canvas :-( Any decent GUI 
> > framework should use some kind of spatial partitioning to determine which 
> > part of the canvas actually needs to be redrawn. Qt's QGraphicsScene does 
> > this pretty well (I've written a level editor where the view can easily 
> > contain 10 thousands of tiles and editing/zooming is smooth!).
> >
> > So I'm pretty frustated with Tk. A short-term solution could be to patch 
> > Tk's canvas code, but in the long run I think we need an abstract GUI 
> > interface, so that people can experiment with better GUI frameworks.
> >
> > </rant>
> >
> > Christof
> >
> > > Gesendet: Dienstag, 27. August 2019 um 00:30 Uhr
> > > Von: "Christof Ressi" <[email protected]>
> > > An: [email protected]
> > > Betreff: [PD-dev] Why don't we implement zooming in Tcl?
> > >
> > > Hi, I've been wondering why the zooming is implemented on the Pd core? 
> > > Tk's canvas has a scale method and people have been using to implement a 
> > > zoom feature, e.g. https://www.tek-tips.com/viewthread.cfm?qid=239833
> > >
> > > Ideally, the core shouldn't have to know about the size of the GUI window 
> > > at all and just work with "logical" coordinates. The GUI can scale the 
> > > content to whatever size it wants and when communicating with the core it 
> > > would transform the mouse coordinates between logical and screen 
> > > coordinates. Some better GUI frameworks already do that for you (e.g. 
> > > Qt's QGraphicsScene/QGraphicView), but it shouldn't be too hard to do it 
> > > manually for Tk. This would also allow fractional zoom factors. 
> > > Unfortunately, Tk doesn't allow fractional font sizes (or has this 
> > > changed?), but we could have at least *some* steps between 100% and 200%. 
> > > Also, it would make the Pd core code much easier because we wouldn't have 
> > > to worry about zoom at all...
> > >
> > > This is just I've been wondering about when having a look at the zooming 
> > > code and coming from my experience of developing GUI apps with Qt. Maybe 
> > > I'm missing something obvious?
> > >
> > > Christof
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Pd-dev mailing list
> > > [email protected]
> > > https://lists.puredata.info/listinfo/pd-dev
> > >
> >
> >
> >
> > _______________________________________________
> > Pd-dev mailing list
> > [email protected]
> > https://lists.puredata.info/listinfo/pd-dev
>



_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Reply via email to