On Thu, 2015-02-05 at 13:26 +0100, Göran Hasse wrote: > > Den 2015-02-03 16:23, Emmanuele Bassi skrev: > > hi; > > > > On 2 February 2015 at 22:07, G Hasse <gorhas@xxxxxxxxxx> wrote: > >> Den 2015-02-02 22:57, Gulshan Singh skrev: > >> > >> I strongly advice designing an application in this way. Every window in an > >> application should be a separate process. Between processes you should > >> find a good protocol. This protocol should be transported over some message > >> buss. (example: www.spread.org) > > > > there are loads of issues with a design like that. > > > > you're going to overengineer your application, and then have issues > > whenever you have to context switch between processes because you > > moved from a window to another one inside your own application. > > Noop! Absolutly not! This is basic and good design. You should *separate* your > data and the program that manipulate the data. The design pattern is called > model-view-control and is well understood today. Dont confuse MVC with process boundaries, that's not productive. > You should have a good *protocol* to > manipulate your data. The userinterface is just a way to fire of a specific "command". > > > you'll have to ensure all your shared data structures are copied > > correctly across process boundaries, and you'll have to have proper > > bookkeeping to ensure processes do not end up using old data. > > NOOP! The data should *not* be copied! You should have your data *separate* from > the manipulating program. Ever heard of the concept of a database? (The protocol here > is SQL). That is essentially copying your data, every time that you load data from your database, with it's in memory caches and it's ultimate storage medium, you are creating an in memory "copy". Depending on whether you use SQLite or a DB server, it's also going over an IPC. An MVC architecture does not require this, it only states that the modal should be responsible to deliver notifications of changes, the view should only update on those changes, and the controller should only ever update the model and not the view directly, allowing for any validation and consequences to occur in the model. Many CRUD applications do this without multiple processes, and without even having multiple windows. > > you won't be able to fork() and build your UI in a child: that's not > > how X11 (or any other windowing system, really) works. you'll need to > > spawn a new child process from a server. > > Absolutly no problem. You have a missconception of what a "server is". Any > program that listen on sockets is a server. Every GUI-program is a server. It > listen on mouse-move, key-bord-press and it is easy to have it also listen > on event on sockets. > > http://youtu.be/Vrz8ilwnBJY > > In this application the datastore is xml (the application is using librsvg for rendering). > So I can manipulat the picture with simple xml "update" commands. And the library can > rerender the data. You seem to be going off on a tangent here, your claim was that: "every window in an application should be in a separate process" Do you also suggest that when I popup a window with a file chooser dialog, that I should store some intermediate state in a database, and spawn another process to request the user for a filename, so it can then send me back the filename over a message bus ? That sounds incredibly convoluted, in the majority of situations where it is uncalled for. Best, -Tristan _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx https://mail.gnome.org/mailman/listinfo/gtk-list
