Hi,

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.

best
massimiliano


> Thanks,
> ________________
> Miguel de  Benito.
> _______________________________________________
> Texmacs-dev mailing list
> [email protected]
> http://lists.gnu.org/mailman/listinfo/texmacs-dev

_______________________________________________
Texmacs-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/texmacs-dev

Reply via email to