|
|
This seems reasonable enough. I'm not sure it needs to be a direct part of Scribus, though, as we pretty much use OO.o hyphenation files. Maybe there's an OO.o hyphenation editor available? As for short words, I really don't know. Seems reasonable enough, just a matter of someone whipping up the tool I guess. I'd suggest doing it as a plugin that could also be run as a stand-alone application. |
|
|
you can edit custom short words in 1.3x version. |
|
|
>>I'm not sure it needs to be a direct part of Scribus, though, as we pretty much use OO.o hyphenation files. Maybe there's an OO.o hyphenation editor available? The problem I see here is that scribus may become too dependent on OO.o. As scribus is intended to run natively under Win32 and OS/X too, it is quite likely that OO.o will not be installed on the majority of machines running these OSes I must admit, however, that the idea of a separate editor (probably as universal tool for short words, hyphenation, spelling + whatever needs to be editable that way in the future), which can also be compiled as plugin, seems quite intriguing to me. A solution might be something like OO.o's user dictionaries: xml files containing short words, hyphenation exceptions etc. |
|
|
> you can edit custom short words in 1.3x version. Petr, "Edit>Edit system configuration" launches a text editor as the current user, which is useless in this case, since you cannot save the system wide conf file as a simple user. Could you make it launch the text editor as root? |
|
|
I'm rewritting it into Preferences/plugins dialog. It will use something like kcontrol's superuser mode (e.g. at Font configuration etc.). I'm not sure in one thing - how is it portable (win/mac). |
|
|
mhanski: Noooooo! Please no! The right answer, IMO, is to *copy* the default config to the user's .scribus/ directory, then edit it there. If they want to make the changes apply globally, they can replace the system-wide file with it using standard administration tools. The less code that ever runs as root, the better. In particular, an app launching an editor as root using a setuid binary is the absolute height of insanity. Try this, using sudo instead of a setuid binary just for this example. If you don't have su, use "su -c" instead: $ sudo vim /tmp/unimportant_test_file now, type: :!sh and enjoy your new root shell. Exit that with ^D and type: :e /etc/shadow where you could replace the root password hash with whatever you felt like. There are editors with 'restricted' modes, etc, but they're just not good enough. In general, if you launch any app that's not designed from the ground up for single-task secure simple operation as root, you've just given full root access to the user you launched it for. Even if you just call out to sudo or "su -c" to get root, so the user needs root priveleges anyway, it's just not a good idea to have general GUI apps playing around with root priveleged processes. It's just a bad plan. If you want a way to globally configure these settings without replacing files from RPM/DEB packages, then the way to do that is to have a search path. That goes for prefs, too. For example, you might search: $HOME/.scribus/shortwords.$LANG /etc/scribus/shortwords.$LANG $PREFIX/share/misc/shortwords.$LANG For now, though, I suggest just copying the file into the users's .scribus on first use of short-words, then always using it from there. Search paths can be worried about later. |
|
|
Well, I'm overwhelmed :) Petr, simply removing the useless "Edit>Edit system configuration" menu entry will do either for the time being, since asking an user for a root password and, in case he knows it, launching an editor as root could pose such a danger. <quote> For now, though, I suggest just copying the file into the users's .scribus on first use of short-words, then always using it from there. Search paths can be worried about later. </quote> This sounds very plausible to me. |
|
|
IMHO, the best solution would be to have a copy of the system wide rc file in the user's .scribus directory by default. That way, most users wouldn't even have to think about copying any file anywhere, because they are not familiar with these things. Everything should be as easy as possible. |
|
|
I'd really wonder if this is more a failing of the initial files. IE, how many day to day DTP users actually want to edit this stuff? I'd hazard a guess at bugger all to none. Put a more complete set in the install directories and perhaps thats enough. I'm not against a nice GUI editor for this purpose, but perhaps its an answer to a second issue rather than the first. |
|
|
wait a few hours. I'm working on it. |
|
2005-10-03 20:31
|
short_words_prefs.png (41,988 bytes) |
|
|
Hi Petr, I like the way you've solved the issue with the Short Words preferences. This remark is not meant for the upcoming 1.3.1 release: Could you add a few words of description to your Short Words prefs dialog (see my attached screen shot). I think it's not obvious enough for new users, what this plug-in is meant for and how to edit the config file. |
|
|
Hi Maciej, there is a desription of Short Words in the help files. As for the rest, I agree with you. |
|
|
Hi Christoph, I know of the existance of the Short Words help file, but in this case I mean only a short description, sth like "A configurable plug in for inserting non-breaking spaces to prevent unwelcome linewraps" or sth like that in real English, not mine:) Below the conf file window, I would like to have a clear info, that this config file is editable, because on first sight it wasn't obvious even to me, that this is not only a preview window. Two sentences like "Edit this custom file to replace the system wide configuration. Place a space before or behind a short word to indicate, where the non breaking space should be inserted" will be more than enough, perhaps one of our native speakers could put it even shorter. |
|
|
Hi Maciej, agree with you 100 %. Petr, would it be possible to have the file uneditable by default and add an "edit" button? A tool tip could be assigned to this button, explaining the function exactly as Maciej suggested. This would also prevent inadvertent editing of the file. |
|
|
Petr, I just compiled 1.3.1. The GUI gives the impression that a normal user can edit the system preferences. Is that true? If so, this should be changed as soon as possible, for the reasons mentioned by Craig. |
|
|
Christoph, you can be stoic in this case. User cannot modify any system-wide settings. When he saves(applies) the changes, everything will be saved into ~/.scribus/ directory. Of course there are missing some illustrative strings (Maciej proposed something above), so I'll create it ASAP. Be patient, please, I've got new job and all is quite hectic for me these days ;) |
|
|
I wouldn't bother with this for 1.3.4. Its only introducing more things to test. |
|
|
Craig, I take it as own as it's related to the "short words" reimplementation planned somewhere between 1.3.5 and 1.3.6 |
|
|
compatibility with hyphenation dictionaries from other tools (e.g. Word) would be helpful, especially the ability to import user customizations from those tools. |
|
|
unassigning subik and changing to 'acknowledged' + assigning to Future Release - Low Priority |
- Anonymous
