On Mon, 2001-12-17 at 18:06, Gediminas Paulauskas wrote:
Ok... .-)Fatih Demir wrote: > On Sun, 2001-12-16 at 17:06, Gediminas Paulauskas wrote: > /Here is the list what I wanted to change:/// > /-----------------------------------------------------------------------/// > /Remove View menu and views sidebar./// > > Hmm, well this is one of the points where I admit it: yes, it's really > ok to remove it if noone says anything against it.. But I don't think > many people loved this feature .-( OK What could have been a target while coding this feature indeed -- but the original target was a lil' bit different.> /Remove "Remove all translations" functionality./// > > Na, this is a good thing to have, why should you remove it? There's an > option to turn something like that on, so this doesn't disturb the > beginner and is there if you want to have it. But what you get is the same as .pot file. Or you take a previously crippled xx.po (no prejudices please, not all of my tr.po files were bad ,-)) and remove all of the crippled translations, let auto translation work for you with a sane and good translation memory and then finish the translation with your sane mind:I just didn't understand how it could be useful. You take no.po, remove all translations, translate into German and save as de.po? Voila, you've got a good po file at the end without the need of using something another then gtranslator to remove the previously crippled translations.Ok, wait <MAILS> (though I doubt whether many people will reply on this case, maybe we'd fwd it to gnome-i18n gnome org...?! Lemme see..).> /Don't check if "file is already opened in another instance of gtranslator"/// > > This is really a diversification question now: kabalak says yes, it's > good, menesis says no, so what do the others say..? Do nothing and wait what others say. Ok, fine with me .-)> /Remove the following options:/// > / * Don't save unchanged files/// I'll do it so: Never save unchanged files. Ok, also fine with me .-)> / * Warn me if I'm trying to save an unchanged file/// I'll remove the check and warning. You mean the option for removing all translations?! I wouldn't have put in an option for this (*woosh* yes, unbelievably but true, I have just put this option in favour of some users' idea that this would be too confusing, crazy for the beginner, so only the more advanced user should ba able to use it after enabling the corresponding option) but so I did.> Ok, these are nonsense but.. > > / * Enable the functionality to update/remove.... (nonsense)/// > > .. the second one isn't nonsense! It's connected to an idea of user > level or something alike that... If you're smart enough to want this > feature, then you do also get the entry in the menus... OK, let's leave them. Functionality is good, I just don't feel there is a need for an option to enable/disable it. If you want to keep the functionality but remove the option: well, could also be done, but then these users who have let me put the option in, could also re-complain about the same situation like when I wrote the code: beginners could vanish their translations for foo (though there are very clear words on the dialogs but you never know how crazy the user could be .-)).Yes, that's the most practicable thing to do, I guess .-)> The only thing which would be Ok herein, is to have a user level option > which would activate/deactivate a set of enhancement functions/menu > entries etc. > > / * Load all backends on startup (they should be loaded only when/// /a sgml or other file is opened/// > > Nice to say but hard to realize for me.. I wanted it to be so, but it > didn't work, so we're currently sticking with the all or nothing > method... Though backends aren't that useful currently to be honest... Yes, it is hard to do. Until backends work nice let's leave the option. Ah, this sounds even fantastic ,-) Didn't get the point this way, but now.. yes, sounds like a good thing to do .-)> /Merge the following options:/// > / * "Use special dictionary" and "Dictionary to use"/// > / * "Save po files automatically..." and "Autosave timeout..."/// > / * "Append a special suffix..." and "Autosave suffix"/// > > Ok, but in which way would you like to do it then? If nothing entered > you don't append anything?! Ok, but what if I want to specify an suffix > without the autosave feature being on? > > Well, that happens often to me, and I do want most of the prefs to be > independently changable from another option or another state. Nothing gets lost. I wanted to merge current two lines [X] Use special dictionary Dictionary to use: [ ] into one line: [X] Use special dictionary: [ ] When option is unchecked, text entry is disabled, but still shows the dictionary. Does this sound good? Ah, I wouldn't be that sure, too, honestly .-)> /Remove the following items from toolbar:/// > / * Save as, Update, Preferences, Exit, (Find, Replace,) Query/// > > Preferences, Exit & Query: ok, but the rest is really nonsense. Why > shouldn't find, replace be in the toolbar? I've put them in parentheses because I was not sure. But I think, a "Save as..." toolbar icon is good for quick access (yesyes, I know, "shortcuts are faster" but... you know).Office apps don't have Save as tollbar item, just a menu entry. Looks also smarter for me then having no "Save as..." entry in the toolbar. Yes, we do .-)At least we agree to remove Preferences & Exit. In the field of query or the toolbar icons?! I guess you meant the query mechanism, then I wanted originally to remove this functionality in the coming releases, but we could discuss about it..Query is not convenient in it's current form, but that would be a big feature enhancement, not just UI improvement what I am talking about. What do you say? Should we keep it or leave it? Hm, fine, sounds good, but would involve massive prefs code changes in the fact. It could be done by using the current wrappers smoothly around it. Also never forget: possibly there's a libkabalakconf coming... You never know ,-)> /Drop most of GtrPreferences and preferences.h stuff in favor of plain GConf/// /with notification./// > > Na, I don't want to be sticked with GConf, maybe the gtranslator_config > stuff will get somehow changing? He, any chance for this? Maybe > bonobo-conf directly or anything another will get the default for > gtranslator_config, what then? No app uses bonobo-conf currently, all move to gconf. gconf really gives flexibility. Think about the case when you have two instances of gtranslator open and change some optin in one of them. With current setup you need to exit and restart another instance, with proper use of GConf notifications your option will change in all instances at once. Yes, I would join this statement, we/you/anyone could merge some options, remove some, but the way prefs code is currently working/written should be kept for the short period of time.> Change all the prefs stuff just because you gave up your level of > abstraction over Gconf/XYZ? No, I don't like this argument... There's no need of abstraction. OTOH, currently preferences work, so they may be left as is. Hehe, games for gaming C code ,-)I have not done anything with gconf, so I guess I'll play with same-gnome or mahjongg preferences before doing anything with gtranslator. Well, I love it and I find them quite useful and working, I can't imagine why one could be against them .-)> I do still miss your comments about colorschemes indeed ,-) I don't have opinion what would be better. I don't like it very much either. Besides this, why don't you love them? It's a bit of themeism every app needs to have in these days (themable colors, pics, sounds, fonts, crahs *oops* the last was a bit wrong I guess ,-)). Oh yes, so I gave them to you all and might you be sharing and spreading the answers and comments.. *hmmm*Thanks for your answers, that's what I wanted to hear from you. We've got sometimes very different opinions but oh well, I guess the people who know me a *little* bit are knowing that some points here are the results of personal kabalak C coding culture so... you got the point I guess...
|
Attachment:
signature.asc
Description: This is a digitally signed message part