Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
LinuxCon: Some advice from Uncle Dirk
Posted Sep 24, 2009 11:12 UTC (Thu) by michaeljt (subscriber, #39183)
I am thinking of something where all the basic communication between GUI components could be set up in a Qt-like signal-slot way, but without any real coding, and communication between the UI and the (pure console) main programme would also be done via signals from the UI to the programme's standard input, mapped to text strings - e.g.
'MySignal selected "some dropdown entry"',
where "MySignal" is a signal identifier shared between programme and UI - and something similar from the programme's standard output back to the UI (updating graphics would probably be one of the trickiest bits here).
Posted Sep 25, 2009 6:03 UTC (Fri) by magnus (subscriber, #34778)
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.
Posted Sep 25, 2009 9:59 UTC (Fri) by anselm (subscriber, #2796)
Congratulations. You just re-invented Tcl/Tk -- after ... what? 17 years?
Posted Sep 25, 2009 10:10 UTC (Fri) by michaeljt (subscriber, #39183)
Posted Sep 25, 2009 13:58 UTC (Fri) by anselm (subscriber, #2796)
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.
Posted Sep 25, 2009 16:00 UTC (Fri) by michaeljt (subscriber, #39183)
>This is the NIH phenomenon at work.
I wonder whether how much of the (useful part of the) current FOSS ecosystem would exist without all that NIH though :) Perhaps we would all be using Windows or Macs. Be that as it may, if I ever get round to implementing the thing I discussed above, it is likely to be as a lightweight binding for Glade-3, which looks like it does ninety percent or more of what I am looking for now.
Posted Sep 25, 2009 10:05 UTC (Fri) by michaeljt (subscriber, #39183)
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).
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds