View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003419 | Scribus | User Interface | public | 2006-03-14 21:52 | 2011-01-16 11:30 |
| Reporter | christoph_s | Assigned To | cbradney | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | won't fix | ||
| Platform | any | OS | any | OS Version | any |
| Product Version | 1.3 | ||||
| Summary | 0003419: Properties palette should not open above a selected item | ||||
| Description | The PP (and other dialogs as well) should be more "intelligent" and recognise the position of the item selected. Currently, the PP seems to remember its last position, which makes it necessary to remove it because it covers the item that is to be edited. Therefore one is wasting time, pushing the PP around on the canvas. | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
| related to | 0003448 | closed | nitramr | Improvements to properties palette |
| has duplicate | 0006766 | closed | christoph_s | Make Properties box dockable like the toolbar |
|
|
Reminder sent to: Tsoots |
|
|
christoph_s: i don't quite understand, how it should work, could you explain a little more? I also dimly remember a RFE (not yours) asking for the the PP to remember its last position, so we have to be very careful here. |
|
|
It will be made dockable. so that'll sort this problem. First ugly screenshot can be seen at http://www.saunalahti.fi/rikle/scribus.png |
|
|
Only for clarification: IMHO, the PP should never cover the currently selected item when called, be it from the menu or from the context menu. This is simply annoying, because one almost always needs to push it somewhere else. |
|
|
Any update on this? This is still a issue in the current svn version as of 2/16/2008. On Ubuntu Gutsy the panel is not movable and is always in the way. See screenshot in closed item 0006766. |
|
|
As you can see, the issue is assigned , but not resolved ... yet. |
|
|
Well I found an interim workaround. If I set the top parameter for the properties palette in the prefs(135).xml file to something like 84 pixels, it moves the palette far enough down that I can then move and adjust it as needed. Perhaps a simple fix would be to preset those parameters to something that would bring up the palette in the middle of the screen initially. A dockable panel like the tool bar would still be the best solution IMO. I figured this out by reading the source file scrpalettebase. |
|
|
please, don't make the palettes automatically move... i want to know where they are! and if you make their position "intelligent", make it an option... maybe an option for each palette (there are palettes which i always want to have at the same place, other which i would like to have under the current mouse cursor position, others which i'd like to have at the right side of the currently selected item). (in my case, the PP is on the right side of the monitor, full height. and i want it to stay there. hi show and hide as needed. i would say that i'd almost prefer the canvas to move and show the current item, instead of the palette). |
|
|
I have not intent to do anything specific vs that issue. I consider that dockability fix indirectly the problem. |
|
|
It has to be an option the user can turn off. IMHO, one of the most despicable behaviours for dialog boxes/menus is to unpredictable jump around on the screen every time it is used, or change the dialog/menu options available to correspond with the type of object selected, instead of just greying out those options that are not applicable: this is completely anti-production, not efficient and makes impossible to automate work with mouse/ keyboard macros and brain. It should always be an user-selectable option. The documents I work with are almost always large, a few hundred pages, 1000 pages (larges one 3000 pages manual), so options that need many clicks, like the meta data on frames, what's the name, attributes I think --BTW, not exposed to the scripter--, are very difficult/ impossible to use without an Attribute Browser feature able to present all attributes on a tabulated form with options to select, edit, etc... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-03-14 21:52 | christoph_s | New Issue | |
| 2006-04-19 19:10 | mhanski | Relationship added | related to 0003448 |
| 2006-04-19 19:11 | mhanski | Note Added: 0010135 | |
| 2006-04-19 19:15 | mhanski | Note Added: 0010136 | |
| 2006-04-19 19:15 | mhanski | OS | => any |
| 2006-04-19 19:15 | mhanski | OS Version | => any |
| 2006-04-19 19:15 | mhanski | Platform | => any |
| 2006-04-19 19:15 | mhanski | Product Version | 1.3.4cvs => 1.3 |
| 2006-04-19 19:28 | Tsoots | Note Added: 0010137 | |
| 2006-04-19 19:28 | Tsoots | Status | new => assigned |
| 2006-04-19 19:28 | Tsoots | Assigned To | => Tsoots |
| 2006-04-19 21:36 | christoph_s | Note Added: 0010156 | |
| 2006-04-19 21:43 | mhanski | Note Edited: 0010136 | |
| 2008-02-16 19:23 | christoph_s | Relationship added | has duplicate 0006766 |
| 2008-02-16 19:53 | trboyden | Note Added: 0018976 | |
| 2008-02-16 20:06 | christoph_s | Note Added: 0018977 | |
| 2008-02-17 13:56 | trboyden | Note Added: 0018990 | |
| 2011-01-13 09:01 |
|
Assigned To | Tsoots => jghali |
| 2011-01-13 10:01 | ale | Note Added: 0025379 | |
| 2011-01-13 10:37 | jghali | Assigned To | jghali => |
| 2011-01-13 10:39 | jghali | Note Added: 0025380 | |
| 2011-01-13 10:39 | jghali | Status | assigned => new |
| 2011-01-13 13:53 | Thaddeus | Note Added: 0025381 | |
| 2011-01-13 18:16 | cbradney | Status | new => resolved |
| 2011-01-13 18:16 | cbradney | Resolution | open => won't fix |
| 2011-01-13 18:16 | cbradney | Assigned To | => cbradney |
| 2011-01-16 11:30 | cbradney | Status | resolved => closed |
