| |||||||||||||
LinuxCon: Some advice from Uncle DirkLinuxCon: Some advice from Uncle DirkPosted Sep 25, 2009 6:03 UTC (Fri) by magnus (subscriber, #34778)In reply to: LinuxCon: Some advice from Uncle Dirk by michaeljt Parent article: LinuxCon: Some advice from Uncle Dirk
Having the communication at that low level would mean that your non-GUI process would need to know lots of detail about the GUI side (which controls exists etc) so you wouldn't achieve any real separation between the two.
To make this separation work well, you would need to make your text-only process like a server that handles the application's state only, and the GUI process is the more active part that sends queries and requests to change the state.
For many applications a bit part of the code is in the GUI handling, and I don't think you can get away from that. What you could possibly do is move the GUI handling code to a scripting language like Javascript which many designers are familiar with.
(Log in to post comments)
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 9:59 UTC (Fri) by anselm (subscriber, #2796) [Link] Congratulations. You just re-invented Tcl/Tk -- after ... what? 17 years? :^)
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 10:10 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
Except that Tcl applications had to be written in Tcl, which might put off some developers :) (I do seem to remember that Tk could be coupled to other things, but I don't remember that taking off). But was a Tk GUI really that easy for a non-programmer to rip out and replace without changing the underlying application?
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 13:58 UTC (Fri) by anselm (subscriber, #2796) [Link] The original idea behind Tcl/Tk was that the meat of an application would be written in a language like C, and its functionality be made available as Tcl commands. These Tcl commands could then be used to »script« the application, to allow automated testing, or -- in conjunction with Tk -- to create a GUI for the application. Hence the actual application code (in C, mostly) and the GUI code (in Tcl/Tk) would be neatly separated. This approach was (and presumably still is) used to great effect, for example, in various VLSI design applications. Tcl got much of its bad reputation because people would try to write big(gish) programs in Tcl itself rather than subscribe to the philosophy outlined above. It took the language some time to acquire the necessary properties to be really useful for larger applications, but by that time much of the damage was already done. Tcl/Tk did earn its inventor, John K. Ousterhout, an ACM Software System Award in 1997 (something that all the other X11 toolkits have yet to achieve), so it is officially a Good Idea. It is worth noting that when Tcl/Tk came out (early 1990s) it was running rings around its competitors such as OSF/Motif as far as ease of development was concerned. It can also be surmised that if, instead of inventing various other X11 toolkits from scratch, the community had poured the same amount of effort into improving Tcl/Tk (which already existed and worked quite well), we would all be much better off :^) For example, Gtk started out as the »GIMP toolkit«, but if the original developers of the GIMP had decided to come up with a better Tk canvas widget rather than implement a complete new X11 toolkit from the ground up, they could have saved themselves a whole amount of work, and the GIMP would be a better program even today. This is the NIH phenomenon at work.
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 16:00 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
>The original idea behind Tcl/Tk was that the meat of an application would be written in a language like C, and its functionality be made available as Tcl commands.
Indeed, in my first proper job I worked on a scripting language for processing vector data which was based on Tcl.
>This is the NIH phenomenon at work.
LinuxCon: Some advice from Uncle Dirk Posted Sep 25, 2009 10:05 UTC (Fri) by michaeljt (subscriber, #39183) [Link]
My personal suspicion is that the approach I am pushing will work well up to a certain point, but will not scale beyond that. It will depend how much can be achieved by connecting UI components with signals and slots (and how many clever solutions people can find to increase that). As a simplified example: the signal "File menu/open" would be connected to "File chooser dialogue/show", the different components would also be connected to one another ("Directory view/select directory" to "File view/change directory") and "File view/select" would be connected to "File chooser dialogue/hide" and to a text signal into the text process: "OpenFile <filename>". The question is how many uncomfortable details my simplified example simplifies away, but thinking back to Visual Basic 1 (the only one I ever used), I do think that it could work for some applications.
The other point I am hoping may hold is that many more complex applications are built around a single main central widget. For example in MS Word, that would be the editor widget. I hope that at least for some applications, it will be possible for the text controller process to hold some state about that widget (the visible size, the position of the scrollbars), to accept a few events like key pressed, mouse clicked, mouse dragged, scroll down, refresh rectangle and to send a few, like fill rectangle with bitmap, change vertical scroll range, place cursor, while still not knowing implementation details like what the widgets are called, exactly where the scrollbars are and what they look like and so on. (In other words, behave as if it were managing a full screen application like a DOS editor, rather than worrying about the full complexity of a GUI).
|
|||||||||||||