New API questions

[Nickolay V. Shmyrev]

Hello all.

I've started some work on evince printing and the following questions
appeared, let me ask them in one mail since they all are related.

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.

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.

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.

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.


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.

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.

Actually there are much more questions, but it's enough for one mail :)

Thanks for attention.


[gnomeprint.diff]

---

diff -upr libgnomeprintui-2.12.1/libgnomeprintui/gnome-print-dialog.c libgnomeprintui-2.12.1.new/libgnomeprintui/gnome-print-dialog.c
--- libgnomeprintui-2.12.1/libgnomeprintui/gnome-print-dialog.c 2005-09-19 21:59:29.000000000 +0400
+++ libgnomeprintui-2.12.1.new/libgnomeprintui/gnome-print-dialog.c 2005-11-09 17:07:19.000000000 +0300
@@ -242,6 +242,7 @@ gnome_print_dialog_set_property (GObject
  GValue const *value, GParamSpec *pspec)
 {
  GnomePrintDialog *gpd = GNOME_PRINT_DIALOG (object);
+ gpointer r;
 
  switch (prop_id) {
  case PROP_TITLE:
@@ -249,8 +250,16 @@ gnome_print_dialog_set_property (GObject
  break;
  case PROP_FLAGS:
  gpd->flags = g_value_get_int (value);
- g_object_set (G_OBJECT (gpd->e_range), "visible",
- (gpd->flags & GNOME_PRINT_DIALOG_RANGE) > 0, NULL);
+
+ r = g_object_get_data (G_OBJECT (gpd->e_range), "range");
+ if (r) {
+ g_object_set (G_OBJECT (gpd->e_range), "visible",
+ (gpd->flags & GNOME_PRINT_DIALOG_RANGE) > 0, NULL);
+ } else {
+ g_object_set (G_OBJECT (gpd->s_page), "visible",
+ (gpd->flags & GNOME_PRINT_DIALOG_RANGE) > 0, NULL);
+ }
+
  g_object_set (G_OBJECT (gpd->s_copies), "visible",
  (gpd->flags & GNOME_PRINT_DIALOG_COPIES) > 0, NULL);
  break;
@@ -483,7 +492,6 @@ gnome_print_dialog_init (GnomePrintDialo
 
  /* Print range, new API */
  gpd->s_page = g_object_new (GNOME_TYPE_PRINT_PAGE_SELECTOR, NULL);
- gtk_widget_show (gpd->s_page);
  gtk_box_pack_start (GTK_BOX (vb), gpd->s_page, FALSE, FALSE, 0);
 
  /* Copies */
@@ -531,9 +539,10 @@ gpd_create_range (gint flags, GtkWidget
  group = NULL;
  row = 0;
 
- if (flags & GNOME_PRINT_RANGE_CURRENT) {
- rb = gtk_radio_button_new_with_mnemonic (group, (const gchar *) clabel);
- g_object_set_data (G_OBJECT (t), "current", rb);
+
+ if (flags & GNOME_PRINT_RANGE_ALL) {
+ rb = gtk_radio_button_new_with_mnemonic(group, _("_All"));
+ g_object_set_data (G_OBJECT (t), "all", rb);
  gtk_widget_show (rb);
  gtk_table_attach (GTK_TABLE (t), rb, 0, 1, row, row + 1, GTK_FILL | GTK_EXPAND,
   GTK_FILL, 0, 0);
@@ -541,9 +550,9 @@ gpd_create_range (gint flags, GtkWidget
  row += 1;
  }
 
- if (flags & GNOME_PRINT_RANGE_ALL) {
- rb = gtk_radio_button_new_with_mnemonic(group, _("_All"));
- g_object_set_data (G_OBJECT (t), "all", rb);
+ if (flags & GNOME_PRINT_RANGE_CURRENT) {
+ rb = gtk_radio_button_new_with_mnemonic (group, (const gchar *) clabel);
+ g_object_set_data (G_OBJECT (t), "current", rb);
  gtk_widget_show (rb);
  gtk_table_attach (GTK_TABLE (t), rb, 0, 1, row, row + 1, GTK_FILL | GTK_EXPAND,
   GTK_FILL, 0, 0);
@@ -692,6 +701,8 @@ gnome_print_dialog_construct_range_any (
  g_return_if_fail (!((flags & GNOME_PRINT_RANGE_SELECTION) && (flags & GNOME_PRINT_RANGE_SELECTION_UNSENSITIVE)));
 
  gtk_widget_hide (gpd->s_page);
+ g_object_set (G_OBJECT (gpd->e_range), "visible",
+ (gpd->flags & GNOME_PRINT_DIALOG_RANGE) > 0, NULL);
 
  f = g_object_get_data (G_OBJECT (gpd->job), "range");
  g_return_if_fail (f != NULL);
@@ -742,6 +753,8 @@ gnome_print_dialog_construct_range_page
  GtkWidget *hbox = NULL;
 
  gtk_widget_hide (gpd->s_page);
+ g_object_set (G_OBJECT (gpd->e_range), "visible",
+ (gpd->flags & GNOME_PRINT_DIALOG_RANGE) > 0, NULL);
 
  if (flags & GNOME_PRINT_RANGE_RANGE) {
  GtkWidget *l, *sb;

---

_______________________________________________
gnome-print-list mailing list
gnome-print-list@...
http://mail.gnome.org/mailman/listinfo/gnome-print-list

[Lutz Müller-2]

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@...>


_______________________________________________
gnome-print-list mailing list
gnome-print-list@...
http://mail.gnome.org/mailman/listinfo/gnome-print-list

[Nickolay V. Shmyrev]

> > 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.
>
> The functionality is already in CVS. I've just not hooked it up yet.
> Will do so in the next couple of days.
>

Ups, I haven't noticed it. I was playing with current CVS, but the
reverse checkbox is placed in the copies selector somehow and it's
not shown.

Placement in copies looks strange for me. I'm not an usability expert
anyhow, but it seems that some other UI improvements to dialog usability
can be made. For example, label "n pages to 1" for me looks like
designed for programmers :) Will something like  "Several pages to one
..." better than the current label. Another very confusing thing is
"Even/Odd checkboxes". When I click on  "Even" and then on "Odd"
checkbox "Even" became selected. That's is certainly not what user
expects. I'd better use something like radio "Both, Even, Old". Actually
I wonder if all this advanced functionality can fit in one dialog.
Probably our usability list can say something or at least flame on it.
That is why I am asking is there some mockups for a new dialog or
another type of proposal. Sorry for above if you like present state ;)

> 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?
>

About printing itself. You see there are several task that libgnomeprint
can deal with - first of all, access to system hardware (that is the
common part). Second, conversion between formats (cairo <-> postscript
<->pdf <-> pixbuf <-> gnomeprint metaformat). That is also quite common
although, for some apps like gedit or gnumeric it's better to create
data in gnomeprint metaformat or probably with cairo in the future. But
for some apps like our evince, it's much easier to generate postscript.
But we still need dialog functionality and functionality to access the
printer. Older API allow as to do that, newer don't. We can't work with
our postscript files and it seems almost impossible for us to create
documents in gnoemprintui metaformat.

Probably when cairo will be used, it would be acceptable although
I can't say if it will work (for example poppler which already depends
on cairo in theory can be adopted to cairo printing, but some formats
like djvu has libraries that generate Postscript and will never work
with cairo, mozilla also btw).

Due to such problem with already have a lot of requirements that really
hard to satisfy (for example, poppler only generates A4 and there is no
way to make it respect page settings in the dialog and so on).

So, we need the ability to "embed" our app between document generation
code and sending data to printer. That task was handled by
gnome_print_set_file function that've never became stable part of API.
Or we need a way to convert postscript to gnomeprint metaformat for
passing it through printing framework.

> > 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.
>

And about preview. You see it's a widget and it's almost the same widget
as evince main view. You know, implementing a good custom widget is very
hard, just because it requires very careful attention to details like
accessibilty and so on. That is why I am asking about common parts of
evince work and gnomeprintui work. Probably we can find some common part
in our widgets and work on them together. Users will ask you for
continuous pages in print preview one day, then you'll remember evince
once again :)

Let me note that there is no problem with dependency. Evince depends
on libgnomeprintui, so common parts may be placed there.

Although probably such monster will be too complicated to handle, may be
I am wrong and small code that just do it's work will be better than
common widget that handles everything. That's why I am asking what do
other people think about it.


_______________________________________________
Evince-list mailing list
Evince-list@...
http://mail.gnome.org/mailman/listinfo/evince-list

[Lutz Müller-2]

On Thu, 2005-11-10 at 12:37 +0300, Nickolay V. Shmyrev wrote:
> Placement in copies looks strange for me.

That's the KDE way. I just wanted to have it in the dialog. We can
certainly move it around.

> Will something like  "Several pages to one
> ..." better than the current label.

It's a bit long. How about 'Any page to 1'?

> I'd better use something like radio "Both, Even, Old".

Radio buttons are so space consuming. Perhaps a menu with those entries?

> Actually I wonder if all this advanced functionality can fit in one dialog.

At least on several tabs. I'd like to add a colorspace selector, too
(b/W, gray, color). That's easy to implement in libgnomeprint (just a
filter that converts the colors to gray or black/white) and very useful.
But I don't know how to call it GUI-wise and where to place it.

> Probably our usability list can say something or at least flame on it.

Yes, please.

> That is why I am asking is there some mockups for a new dialog or
> another type of proposal.

There isn't even a website for libgnomeprint.

> Sorry for above if you like present state ;)

I am open to suggestions as long as we move forward. There hasn't been
any development on libgnomeprint in the last couple of years, but I
think it is worth working on it.

> > For what do you need the dialog, anyways?
> About printing itself. You see there are several task that libgnomeprint
> can deal with - first of all, access to system hardware (that is the
> common part).

Ok, that's the first tab.

> Second, conversion between formats (cairo <-> postscript
> <->pdf <-> pixbuf <-> gnomeprint metaformat). That is also quite common
> although, for some apps like gedit or gnumeric it's better to create
> data in gnomeprint metaformat or probably with cairo in the future. But
> for some apps like our evince, it's much easier to generate postscript.

libgnomeprint is no conversion program between formats. That's what
gstreamer was designed for.

> But we still need dialog functionality and functionality to access the
> printer. Older API allow as to do that, newer don't. We can't work with
> our postscript files and it seems almost impossible for us to create
> documents in gnoemprintui metaformat.

How about giving apps the choice to add their own tabs?
- The printer tab can always be there.
- Remove the paper selector tab - it belongs to the "print setup" menu
item.
- Show the job tab only if the app generated libgnomeprint metadata. If
not, the application needs to create its own tab if it can offer
advanced features like page selection.

> Due to such problem with already have a lot of requirements that really
> hard to satisfy (for example, poppler only generates A4 and there is no
> way to make it respect page settings in the dialog and so on).

That's why I'd like to get rid of the paper selector tab.

> So, we need the ability to "embed" our app between document generation
> code and sending data to printer. That task was handled by
> gnome_print_set_file function that've never became stable part of API.

We can make it part of the API. Again, people will then be prevented
from all those fancy options, but that's the decision of the
application, not libgnomeprint.
> Or we need a way to convert postscript to gnomeprint metaformat for
> passing it through printing framework.

Just render it. We can use the gstreamer framework for that - then you
can also read PDFs, images... It's easy done with just one plugin for
gstreamer.

> And about preview. You see it's a widget and it's almost the same widget
> as evince main view. You know, implementing a good custom widget is very
> hard, just because it requires very careful attention to details like
> accessibilty and so on. That is why I am asking about common parts of
> evince work and gnomeprintui work. Probably we can find some common part
> in our widgets and work on them together. Users will ask you for
> continuous pages in print preview one day, then you'll remember evince
> once again :)

Can you drag and drop individual pages from evince to another document
shown in another instance of evince? As I understand, evince is 'just' a
viewer. The gnome-print-preview lets you delete pages, reorder them,
insert pages from another print preview...

Can we split this discussion up into several parts/emails?

(1) Printing PostScript documents (-> conversion to meta format,
dropping fancy GUI options...)

(2) Improving the user interface when using the GnomePrintMeta format
(where to place the reverse option...)

(3) Finding synergies between evince and the gnome-print-preview

Regards
--
Lutz Müller <lutz@...>


_______________________________________________
gnome-print-list mailing list
gnome-print-list@...
http://mail.gnome.org/mailman/listinfo/gnome-print-list

[Jim Evins]

On Thu, 2005-11-10 at 22:52 +0100, Lutz Müller wrote:

> On Thu, 2005-11-10 at 12:37 +0300, Nickolay V. Shmyrev wrote:
> > Placement in copies looks strange for me.
>
> That's the KDE way. I just wanted to have it in the dialog. We can
> certainly move it around.
>
> > Will something like  "Several pages to one
> > ..." better than the current label.
>
> It's a bit long. How about 'Any page to 1'?
>
> > I'd better use something like radio "Both, Even, Old".
>
> Radio buttons are so space consuming. Perhaps a menu with those entries?
>
> > Actually I wonder if all this advanced functionality can fit in one dialog.
>
> At least on several tabs. I'd like to add a colorspace selector, too
> (b/W, gray, color). That's easy to implement in libgnomeprint (just a
> filter that converts the colors to gray or black/white) and very useful.
> But I don't know how to call it GUI-wise and where to place it.
>
> > Probably our usability list can say something or at least flame on it.
>
> Yes, please.
>
> > That is why I am asking is there some mockups for a new dialog or
> > another type of proposal.
>
> There isn't even a website for libgnomeprint.
>
> > Sorry for above if you like present state ;)
>
> I am open to suggestions as long as we move forward. There hasn't been
> any development on libgnomeprint in the last couple of years, but I
> think it is worth working on it.
>
> > > For what do you need the dialog, anyways?
> > About printing itself. You see there are several task that libgnomeprint
> > can deal with - first of all, access to system hardware (that is the
> > common part).
>
> Ok, that's the first tab.
>
> > Second, conversion between formats (cairo <-> postscript
> > <->pdf <-> pixbuf <-> gnomeprint metaformat). That is also quite common
> > although, for some apps like gedit or gnumeric it's better to create
> > data in gnomeprint metaformat or probably with cairo in the future. But
> > for some apps like our evince, it's much easier to generate postscript.
>
> libgnomeprint is no conversion program between formats. That's what
> gstreamer was designed for.
>
> > But we still need dialog functionality and functionality to access the
> > printer. Older API allow as to do that, newer don't. We can't work with
> > our postscript files and it seems almost impossible for us to create
> > documents in gnoemprintui metaformat.
>
> How about giving apps the choice to add their own tabs?
> - The printer tab can always be there.
> - Remove the paper selector tab - it belongs to the "print setup" menu
> item.
> - Show the job tab only if the app generated libgnomeprint metadata. If
> not, the application needs to create its own tab if it can offer
> advanced features like page selection.

This is an excellent idea.  Currently in glabels I have to do a really
stupid hack to create a custom print dialog with a printer-selector.
See http://bugzilla.gnome.org/show_bug.cgi?id=99728 (which BTW was
incorrectly marked resolved as FIXED, it wasn't).  Gthumb (at least in
2.6.5) requires the user to go through two print dialogs (its own
followed by libgnomeprintui's), which is an extremely clumsy UI.

An application may have many application specific printing options (e.g.
layer selections, header and footer options, scaling options, record
selections, etc.) that cannot be generalized.  You could argue that
these go into a separate "Print setup" or "Page setup" dialog, however
this would depend on the intended scope of these options.

-Jim

> > Due to such problem with already have a lot of requirements that really
> > hard to satisfy (for example, poppler only generates A4 and there is no
> > way to make it respect page settings in the dialog and so on).
>
> That's why I'd like to get rid of the paper selector tab.
>
> > So, we need the ability to "embed" our app between document generation
> > code and sending data to printer. That task was handled by
> > gnome_print_set_file function that've never became stable part of API.
>
> We can make it part of the API. Again, people will then be prevented
> from all those fancy options, but that's the decision of the
> application, not libgnomeprint.
> > Or we need a way to convert postscript to gnomeprint metaformat for
> > passing it through printing framework.
>
> Just render it. We can use the gstreamer framework for that - then you
> can also read PDFs, images... It's easy done with just one plugin for
> gstreamer.
>
> > And about preview. You see it's a widget and it's almost the same widget
> > as evince main view. You know, implementing a good custom widget is very
> > hard, just because it requires very careful attention to details like
> > accessibilty and so on. That is why I am asking about common parts of
> > evince work and gnomeprintui work. Probably we can find some common part
> > in our widgets and work on them together. Users will ask you for
> > continuous pages in print preview one day, then you'll remember evince
> > once again :)
>
> Can you drag and drop individual pages from evince to another document
> shown in another instance of evince? As I understand, evince is 'just' a
> viewer. The gnome-print-preview lets you delete pages, reorder them,
> insert pages from another print preview...
>
> Can we split this discussion up into several parts/emails?
>
> (1) Printing PostScript documents (-> conversion to meta format,
> dropping fancy GUI options...)
>
> (2) Improving the user interface when using the GnomePrintMeta format
> (where to place the reverse option...)
>
> (3) Finding synergies between evince and the gnome-print-preview
>
> Regards
> _______________________________________________
> gnome-print-list mailing list
> gnome-print-list@...
> http://mail.gnome.org/mailman/listinfo/gnome-print-list

_______________________________________________
gnome-print-list mailing list
gnome-print-list@...
http://mail.gnome.org/mailman/listinfo/gnome-print-list