From octave-maintainers-request at bevo dot che dot wisc dot edu Tue Nov 11 18:14:24 2003 Subject: Re: Handle Graphics implementation in Octave. From: Paul Kienzle To: Ole Jacob Hagen Cc: octave-maintainers at bevo dot che dot wisc dot edu, N Smethurst Date: Tue, 11 Nov 2003 19:14:13 -0500 On Tue, Nov 11, 2003 at 11:56:22PM +0100, Ole Jacob Hagen wrote: > > > But a user might want to send many parameters such as > > > set(gca, 'PropertyName1', 'PropertyValue1',... > > > 'PropertyName2', 'PropertyValue2',... > > > 'PropertyName3', 'PropertyValue3'); > > > which is allowed in Matlab. This is not a problem > > > really, since we sent these as four messages. > > > 1. send that gca are to be configured. > > > 2. setValue('PropertyName1', 'PropertyValue1'); > > > 3. setValue('PropertyName2', 'PropertyValue2') > > > 4. setValue('PropertyName3', 'PropertyValue3') > > > > > > This will require four transmissions. > > > This will be a base for transport unit. > > > > You probably want a way of batching the ops so that > > the screen updates happen altogether rather than > > piecemeal. > > I guess a user wouldn't notice this changes, if they > were executed sequentially, or? > It's not much data to sent. > Of course we could always send absolutely all handle graphics data, > and not send the modified one. > This is not a very good solution, since transmission errors might occur, > and what a waste of bandwidth? > This will require some kernel memory usage, > to send all handle graphics objects every time. Hmmm... we seem to be talking past each other. If I have a complicated visual representation I want to create, including several different graphs in a set of windows with a number of different annotations associated with them, and if I want to produce this graph from within my GUI app in response to some user file selections, I don't want to see one curve plotted, then another on top of it (with axis limits scaling automatically), then have it shrink down because I want to put another graph beside it, then have it shrink some more because I add a title, then have it shrink some more because I add an x-axis label, etc. Instead I want to see the whole operation happen as a single update. The question is how. Do you mark a start and end of transaction? Or do you hold all updates until the input queue is empty and no more draw commands have come in the last 200 milliseconds? Or is there some other way of batching the commands? Maybe the second way is best, with an explicit flush command to update the current graph. Also, when streaming data from some simulation, you will want to update the graph periodically, but not if the queue is getting too full, so you need some way of detecting whether the graph app is busy (possibly with a command on the queue which is send("I'm not busy") back to the app. There are a lot of details like this that you need to account for if you want to create apps that are smooth and responsive. > > > > Different visualisers have different capabilities. You > > need some way of testing whether a certain class of > > features is supported. The details get messy here. > > For example, what if one app supports latex style > > math, another supports mathml and a third supports > > none of the above? Do we standardize on one model > > (e.g. latex since it is human readable) and require > > the app to translate it as best they can? > > Latex-style support. > > I don't know if VTK supports latex-style fonts, but > I guess this could be fixed. > I know that Coin3d doesn't support latex-styles. > > > Output is important. Try to include the page model > > in the design up front. > ??? What's on your mind? A design of visualisation > frontend? With some features it should have? The printed representation of a graph does not match the screen representation. You need a way to compose graphs on a page for printing so that they come out nicely. E.g., don't take the postscript representation of your graph and stretch it to fit since the fonts will look horrible and your square point markers will turn into rectangles. You need a way to preview the graph so that the user knows what will come out. Ideally, you need to be able to move the graphs around on the print canvas. And finally, since you are doing this from an end user app, you need a way of storing the configuration for that particular page layout so that the next time the user prints that report she doesn't have to rearrange the graphs again. Or you can punt and tell the user that they should use Origin or some such for all their publication quality work, and just make it easy to export the data in any format. Niceties like selecting a line causing the x,y,dy data which underlies it to be entered into the clipboard so it is easy to paste in another application for example. > > Thinking some years from now on.... > > This question is raised number of times: > When is a GUI-frontend to Octave available? Whenever a community gets together to develop and maintain one. It's certainly not a priority for me. > Will it ever be made one, which is included > into either sourceforge, or core? octave-forge initially. > This will require some rethinking of code, > and a choice of gui-API has to be made. > Is there anyone, who are developing on this? No, not in a sustained manner. There are a couple of attempts, but nothing to rally around. My own efforts have been on developing an end-user application. I'm using Tcl/Tk because it is a full-featured GUI building language with lots of widgets. It is really convenient for making simple GUIs and has the features necessary to support modular programming in the large. I'm using something called freewrap which allows me to bundle all my Tcl/Tk scripts and dlls into a single executable for easy deployment. What I haven't yet had the opportunity to do is pop my head up and write the simple wrappers for figure, plot, etc. which would make it convenient for my users to explore their data interactively in ways I haven't anticipated. That will come, but only after I've handled the needs of the majority of my users. Personally, I don't see the value in reinventing Tcl/Tk for Octave. For one thing, you lose all the community efforts going into the design and development of new Tcl widgets. For another, you then assume the responsibility for keeping the toolkit up to date and portable. Yes, you can start with a pre-existing widget set such as Qt or Gtk or wxWindows, but then you are still responsible for keeping the Octave mapping of these widgets in sync with the underlying toolkit. Finally, I doubt you will come up with anything as convenient for GUI building as Tcl/Tk. The GUI code I've seen for Matlab certainly isn't it. That being said, it would be nice if stuff targeted to matlab UI controls would just work, but I wouldn't recommend writing anything new in that framework without the addition of a gridded geometry manager. > A visualiser should be integrated in gui-frontend, > but this will narrow down a possibilities of an user. No, John and I have both said that the GUI frontend should be implemented using the tools provided by the visualiser. We differ slightly in that he would prefer to map the entire GUI toolkit into Octave commands while I prefer to keep the GUI toolkit in its own language environment. > > I am developing Oplot++ based on Coin3D and Qt, > while Nick is developing KVisualiser based on VTK and KDE. > What if I and Nick agree on a making a gui-frontend > to Octave, using e.g Qt for portability. The rules are simple: show me the code. If you have something that works you are welcome to add it to octave-forge. It is a community project and the community is us. Personally, I would much prefer you implement it at a higher level, such as in Octave, with a mapping from Octave to the underlying toolkit. I would recommend the mapping be logical rather than physical: call a button a button rather than a QtButton so when the next flavour of the month comes around we can swap out the widget set without affecting our code. > Free version of Qt runs on both Mac OS X, Windows and Linux. > Octave is still running in Windows using Cygwin? I would rather not have Octave depend on Cygwin, and even less do I want it dependent on an X11 server. I also don't want it dependent on ghostview, but pdf would be okay. > > And this GUI-frontend supports both Oplot++, > KVisualiser and Gnuplot for starters? > Me and Nick is pretty much doing the same thing here. > This is completely waste of time, if you ask me. Agreed. And I appreciate both of your efforts. So far I've been limping along by pasting image markers on a graph, but soon I'm going to need to represent structured grids, so a simple image won't work anymore. Contours would be nice, too. > Why: handle graphics offers also run-time creation > of widgets, so called uicontrol and uimenu. > This will require a good base of GUI-frontend, > using Qt, we can create run-time widgets, and > pushbuttons and so on. > And use Oplot and Kvisualiser as plugins to the > GUI-frontend, may be? Yes, separate the plotting from UI so that you have more control. Be aware that your users are going to want several graphs and other user interface widgets shown on the same panel, with the ability to interact with objects on the graph. Paul Kienzle pkienzle at users dot sf dot net