Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | gtk fpicker - expand 'type' on Export ... | ||||||
---|---|---|---|---|---|---|---|
Product: | gsl | Reporter: | mmeeks <mmeeks> | ||||
Component: | code | Assignee: | thorsten.martens | ||||
Status: | CLOSED FIXED | QA Contact: | issues@gsl <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | issues, Mathias_Bauer | ||||
Version: | 680m179 | ||||||
Target Milestone: | OOo 2.3 | ||||||
Hardware: | All | ||||||
OS: | Linux, all | ||||||
Issue Type: | PATCH | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
mmeeks
2006-08-07 12:36:23 UTC
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 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 |