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

RE: [XaraXtreme-dev] ImageMagick

Comments below.

> >> The ImageMagick stuff is ready for testing as of
> >> r1475.
> >>
> >> * The image format selector looks a bit stupid. Ideas?
> >
> > This is all about to change with the work Luke is doing. We agreed
> > the bitmap type selector would be in the export dialog, so you can
> > switch the type while playing with the settings. So I guess this
> > just be 1 (rather large) popup list on the dialog.
> >
> > Or perhaps, since the list is so long, it would be better to have a
> > separate "Bitmap Types" tab on the dialog, which has a scrollable
> > box?
> I had a long and unproductive discussion with the GTK folks on IRC
> last night about this. The summary of it is:
> * They perceive the "filter" as a filter on the files displayed in
>    the box, rather than a means of selecting save type. They see
>    using it to select save type as an "abuse" of the control and
>    thus are uninterested in fixing bugs that derive from this
>    usage (I think they are wrong, but...)
> * Hence they are uninterested in fixing things so the box can appear
>    with "Browse for other folders" pre-expanded
> * The behaviour where the GTK choicebox with the list of file-types
>    on appears as a huge list, filling the screen, with the top half
>    completely blank is allegedly deliberate (unbelievable, that).

Yes, that is amazing as my first impression was that it had gone very

> * The above decisions are based on some UI guidelines that they
>    now seem to be sticking to pretty rigidly (because before, noone
>    was sticking to any guidelines), even though quite a few people
>    think they are wrong, or (in my opinion) just don't cover some
>    common use-cases (like "Save As").

I don't think you're suggesting otherwise, but just in case please note
that we don't want any export types appearing on our File, Save As type
list. They should only be accessible via Export, not Save As.

> * The recommended behaviour for export is to make it look like
>    OpenOffice's "Save As..." box, or the Gimp "Save As..." box.
>    What they do is they have a SEPARATE expander called "File Type"
>    which allows you to select the file type from a separate list.
>    It's possible to add an extra widget on GTK to do this, though
>    wxWidgets doesn't (yet) support it. There is also an option
>    to automatically add the file extension of the exported type
>    if none is specified, which is checked by default (presumably
>    you want to uncheck it if you don't want your file to end
>    in a dot plus extension). It would be reasonably simple to add
>    this expander and checkboxes to the wxWidgets GTK dialog,
>    simply by overriding wxFileDialog, duplicating the code,
>    and using gtk_file_dialog_set_extra_widget (or whatever
>    it's called). The widget can contain a (gtk) panel or
>    an expander with a panel in, so can in practice have as
>    many extra widgets as you want. But you can't then get rid
>    of the vestigial filter pop-up.

Ok. One option then is that we ask someone to update wxWidgets to give
us these options on the save dialog. We have someone who was interested
in doing the popup slider work (which is already being done by Mart) so
perhaps this is a job for them? Or maybe it's too small - are we talking
just a few hours work or a few days?

> For bitmaps, if Luke goes the way he plans to go, then I seem
> to remember we have an "export as bitmap" menu option (right?)
> which then allows the choice of the filter from within the
> enhanced bitmap export options dialog (is that right?). So
> the "save as" dialog would then only have a single type in
> (the type selected) and would not need the above. Am I on
> track here?

Yes. Except Luke has now said that hooking menu options under File,
Export to the filters is not easy and therefore can't be done in time
for 0.7. So we'll have to live with what we have for 0.7. Luke is now
looking at adding a preview into the current export dialog. Initially
you won't be able to change the export type while on the dialog. We'll
add that later.

So for 0.7 the target is to add a preview to the current export dialog
and include a useful, manageable list of ImageMagick supported types in
the existing export list.

> For vectors, I /think/ where we were was a menu of "save
> as Illustrator EPS", "save as SVG" etc. etc. being a
> submenu of the file menu. Doing the above might make
> things prettier because we could then just offer one
> save dialog.

Again this will have to wait so there will just be the one large list of
types in the save dialog. The list will include all the ImageMagick
types AND those types provided by plug-in filters so we need to avoid
any clashes.

> > We should probably exclude some of the types that don't work well or
> > aren't useful. I tried SVG (presumably just exports a bitmap wrapped
> > SVG?). I didn't get the export dialog appearing after selecting the
> > filename and clicking Save. It seemed to do the export at that
> > but the resulting file was empty. Is this really a useful option
> Well ImageMagick actually support a vector format, but I just convert
> everything to PNG on the way in and out so vectors get lost. And
> I don't plan to change that right now.
> I should /probably/ disable most of the vector format saving. Like
> SVG for instance. SVG loading is useful until we have an SVG vector
> loader. 

Sandro will be sending us a partially working SVG import filter very
soon. So please can you disable ImageMagick SVG import and export so
that we don't get a clash with Sandros plug-in filters (he'll be doing
export later).

> PDF loading is useful. Is PDF saving (as a PDF with a bitmap
> in) useful (for instance) while we have no bitmap exporter? Is
> EPS saving useful? 

Leave everything else in until we've done some testing and decide which
we want to keep. I expect Charles will give us a list of those he wants
in for 0.7.

> Given these will all be selected from Luke's
> new UI which will make it really obvious you are exporting as
> a bitmap, I didn't see too much harm in these (though obviously
> if they work, that would be an improvement :-) ).

Yes we might have to remove more for 0.7 than we would have liked
because we won't be getting Luke's UI changes in time. 

> As you can tell, I didn't test all 180 combinations :-)

Slacker! ;-)