View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0017475 | Scribus | User Interface | public | 2025-03-26 20:31 | 2025-03-27 07:14 |
Reporter | pygmee | Assigned To | |||
Priority | normal | Severity | feature | Reproducibility | always |
Status | new | Resolution | open | ||
Product Version | Future Release - Low Priority | ||||
Summary | 0017475: Move Form field modal dialog to properties | ||||
Description | Even if PDF form fields are special objects, for the user the just looks like they must be manipulated as some kind of frame. Most users i see want to look at properties window to set the options. + getting modal when you have a full form to verify is just to boring. For those reason, the opportunity to migrate field options to Properties or Content Properties should be considered. | ||||
Tags | No tags attached. | ||||
Patch | No | ||||
|
this ticket made me try out a few things with the pdf toolbar. and then test the result with firefox. the result is rather deceiving. there are things that are possible in scribus (typing some text inside of a checkbox) but make no sense. others are rather complex to define, look sometimes ok in scribus, but produce no satisfying result in firefox (adding a png icon to a button and putting the caption it: the image is rendered below the white fill color of the button; i could not find a way to add a caption) of course, i can set the button border properties both as a field property and in the properties palette. (i guess that only the settings in the field settings are used...) i'm still not convinced about the whole idea of creating "interactive" pdfs, but if we want to improve the state of pdf creation in scribus, i think that: - we should first have a concept on what should be possible, - then improve the ergonomics of the scribus pdf tools, and - document which feature can be used with which pdf reader. having the pdf field properties in the content palette could then probably be a good but we should know what belongs in there (and what potentially should still be in a separate dialog). |
|
and, of course, if i did those tests is also because pygmee's request is a good one. and if we can agree that none of the pdf fields should be detected as text frames, it might also be rather easy to implement. |