[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Texmacs-dev] Running without a GUI plus other ideas and tasks

From: Gubinelli Massimiliano
Subject: Re: [Texmacs-dev] Running without a GUI plus other ideas and tasks
Date: Sun, 7 Nov 2010 00:13:16 +0100


On 6 nov. 2010, at 23:12, Miguel de Benito Delgado wrote:

Hi all,

  in my quest for a deeper understanding of the code (well, any understanding at all would be nice right now), I've come up with the idea of writing a QuickLook plugin for MacOS, i.e. a quick .tm to .pdf renderer which applications like Finder call to get a nice preview of files. Command line options exist already in TeXmacs which basically call the relevant scheme stuff: "-c in out" does a texmacs-load-buffer in followed by export-buffer out (wich is sort of an alias for print_to_file, right?) and then "-q" quits TeXmacs. Sadly enough this won't do because a gui is created in the startup process and an ugly window pops in and out of existence before the bewildered eyes of the user who just expected a flawless-MacOS-like-preview of some file.

This would be a nice project but I fear that the current TeXmacs code is not quite ready for this extreme specialization. You would have to rewrite most of the toplevel functions to start a texmacs server object without gui and send appropriate messages to trigger conversion to pdf. Essentially write a new main. I'm not sure however if there are implicit assumptions around on the existence of a well behaved gui (for example wrt delayed messages instatiated on the scheme side).

  Stupid, blindfolded commenting out of mostly random lines proved a waste of time, so a bit of list-digging got me to http://lists.gnu.org/archive/html/texmacs-dev/2007-11/msg00000.html, and the notion that it might be easier to implement some sort of dummy gui-without-gui plugin than to tackle the issue of building a (usable) library out of the existing code, especially since I am most definitely not ready for the latter (nor am I likely to be any time soon, for that matter.)

I'm not sure if it is possible to have a dumb gui, it would deserve investigation and testing. nice idea tough.

  Any comments? One very welcome suggestion indeed would be another task to focus on, sufficiently uncoupled from the main development process as to make it something I can encompass without being totally absorbed in it, which I can't afford. There are a couple of things that I'd also like to have in TM for my daily use, namely graphical configuration of shortcuts (to quickly fix those that don't work for some reason or other) and better image support (scaling, embedding, eps bugs fixing, etc.), but they look pretty daunting to me. Maybe not the first, if I convince someone (<cough>) to explain to me how the keyboard shortcuts system works.

if you want some relatively easy projects here they are:
1) make the file chooser dialog native. At the moment this is disabled since on the mac there is a difficulty: a native  file open dialog do not allow to type the file name. You have to take different actions in the case of a file load or a file save and the old texmacs api didn't differentiate the two possibilities. Now Joris has made some changes and when the dialog has to be created we know if it is for a load or a save, so that in principle we can choose the right native widget. Relevant lines in Graphics/Gui/widget.hpp are

widget file_chooser_widget (command cmd, string type, bool save);
  // file chooser widget for files of a given 'type';
  // for files of type "image", the widget includes a previsualizer for images
  // 'save' indicates whether we intend to save the file

2) make a native print dialog. The relevant api is 

widget printer_widget (url ps_pdf_file);
  // widget for printing a file, offering a way for selecting a page range,
  // changing the paper type and orientation, previewing, etc.

where we are given a temporary ps or pdf file and we need to ask the user where to send it (print or file) and as many transformations are possible (page layout, page size, etc....). Note that the file is already typesetted but maybe the user would like to print 2 pages in one, landscape, reduced, etc.... In any case even a simple print dialog is missing so any improvement is welcome. I've started some preliminary code in this respect but is not active. Give a look at the function qt_print in qt_utilities.cpp. 

If you want to work on these tasks tell me so that we do not superpose. If you have any question do not hesitate to post on the dev list.


Miguel de  Benito.
Texmacs-dev mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]