Apache OpenOffice (AOO) Bugzilla – Issue 68219
gtk fpicker - expand 'type' on Export ...
Last modified: 2009-04-23 14:07:02 UTC
So - this is really #51002# re-filed, since (it seems) that got marked fixed without this being fixed ;-) [snip] So - it turns out that the file-type functionality is rather confusing on export, where the type combo is hidden, and well, life is non-obvious. This adds an extra psuedo-control which is that & get the helper to expand it, so we show the type selection prominently on export in the gtk+ file selector [snip]
Created attachment 38311 [details] patch
Dunno really, I kind of like it the way it is a) There's already the env variable "SAL_EXPANDFPICKER" which when set to 1 does this, though admittedly affects open as well as save (and set to 2 expands the browser as well) b) The only other sort of similiar app is the gimp, which defaults to not expanding the types, and we have the same "use extension as default save type" logic in place which reduces the need to use the drop down list of types in most cases
Well - on export, it's not very discoverable; the set of export formats is non-obvious in most cases - and it's nice to see PDF / XHTML listed there (IMHO etc. ;-) ie. Export is different to 'Save As'/ The Gimp doesn't do export, Inkscape has a hard-coded 'Export Bitmap' File menu option, gnumeric doesn't do it ... so really nothing to go on. Convinced ?
oh, export dialog, not save dialog, makes sense. I probably should actually apply it rather than guess what it does from reading the bare patch. Would be nice if the "export as PDF" dialog didn't actually have the full list of exportable formats available, only implicitly PDF so the format list would be empty in the dialog, removing the verbosity of export to PDF in this case.
cmc->mmeeks: Looks good, but I'm not touching any more fpicker stuff with a 10 foot bargepole
retarget
Do we still want this patch ? We should commit it then at some point :-)
sure - I guess we need to resurrect cmc's CWS at some stage: but lets get the process problem that lead to his acute pain fixed first :-) that is unless someone else has a CWS they want to include this in [ it's not as if Sun uses the gtk+ file-picker by default anyway so ... ;-].
ping
pl - pong ? any chance you can include it in one of your CWS? :-) it'd save a ton of grief, and should be low-risk.
will do, seems harmless enough. OTOH I'd like to have an implementation for the other platforms, too.
committed in CWS vcl80
please verify in CWS vcl80
Verified with cws vcl80 = ok
from #desc12: "and should be low-risk." Well, a look to issue 81318 shows us something different. :-( Unfortunately that was discovered pretty late. IMHO it's a show stopper but it seems that this opinion is not shared.
excuse me, but could you explain to me how adding a new control to the IDL and activating it could possibly adversely affect other implementations (like the windows file picker) ? I do not remotely understand how this can be related to issue 81813
The bug was caused because adding the control triggered an unfortunate side effect. This was of course not forseeable for the developer that created the patch (and for the developer that accepted it). My comment didn't aim at the patch being fine or not (IMHO it was fine und correct). My concern is the amount of testing applied. This issue is a good example that even if the developers swear that their change is "low risk" it is a good idea to apply some testing, especially if the patch is done short before a release. So every change in file dialog related code should perhaps be tested for all common uses cases and on all platforms.
closed