On Wed, 2005-11-09 at 23:30 +0300, Nickolay V. Shmyrev wrote: > 1. First of all, about old API, we have request from users to make > printing of current page easily available. There is possibility to add > corresponding radio button in old API, but it's completely unusable. > Just because when you add current entry, it became selected by default, > and that is certainly not what user expects. By default all pages radio > should be selected. Unfortunately there is no way to change this value, > so I propose the attached patch. Looks good. I'll verify it and check it in. > 2. Second problem that attached patch should solve is that with new API > passing GNOME_PRINT_DIALOG_RANGE to gnome_print_dialog_new creates two > (old and new) frames with the same label "Print range". Moreover, flags > don't manage visible controls on "Job" page. Proposed patch should make > situation clearer - setting "flags" property will hide or show needed > range control for both old and new API. Thanks for sorting this out. > 3. Third. We had requests to print pages in reverse order. In older view > it was possible with "From ... to ..." entry by passing bigger page in > first spinner and smaller one in second. Now I see this control was > removed in CVS. Do you have any plans to implement such functionality. > > 4. Generic one - I see new printing ui API is much different from older > one and probably won't satisfy our needs. And it looks unfinished a bit. > Is there any plan for future API already or it's in development stage? > Some of our needs are listed below. The functionality is already in CVS. I've just not hooked it up yet. Will do so in the next couple of days. > 5. We need to get range of pages and then create ps file ourselves > (something like that was possible with never offical > gnome_print_job_set_file API, although it's very incomplete. For > example, it's hard to get proper page layout and so on. Is something > like that planned for new API. I see there is no way to even get range > of pages selected by user. libgnomeprint(ui) was designed to take over the generation of PostScript/PDF/SVG/whatever data. If you use the gnome-print-API (gnome_print_moveto, gnome_print_fill...), libgnomeprint will be able to do lots of cool stuff: - printing n-to-1 (even 1-to-n: posters for poor people) - reverse order - pages "1,5-8" - drag and drop pages from one print preview to the print preview of another application and thus merge for example abiword and gnumeric files... As I doubt that you'll implement all of this in evince, you need to suppress elements all over the GUI. How should we do that? Making the elements insensitive? Hiding them (and probably rearranging the visible ones)? How to do it technically? For what do you need the dialog, anyways? > 6. Is it possible to customize new dialog view, for example to remove > "layout" combo in second page. Or to add "current" or "selected" radio > to range control. Is it possible to hide "Preview" dialog action. See comment above. Currently, no elegant solution comes to my mind for customizing the print dialog. > 7. Probably evince will be useful as print preview widget in the future. > Probably we can investigate such question and try to implement it > somehow. The preview widget is just a viewer for gnome-prints internal meta format. This format can be converted by libgnomeprint to PostScript, PDF, SVG and images (gdk-pixbuf). I am not convinced that a dependency on an external program to render that meta format would add benefits. As a sidenote: It seems that the print preview dialog is a relict of the past. firefox displays in the tab. So does the gedit (CVS). The abiword team is getting alarmed if someone finds out that the print output differs from the document shown in the application. > Actually there are much more questions, but it's enough for one mail :) Don't hesitate to ask/suggest/criticize/patch... Regards -- Lutz Müller <lutz topfrose de>
Attachment:
signature.asc
Description: This is a digitally signed message part