Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=643140 --- Comment #21 from Raghu Udiyar <raghusiddarth@xxxxxxxxx> 2011-05-24 18:29:37 EDT --- Hi David, Thank you very much for your comments. (In reply to comment #20) > - Line spacing: I like to see a fixed number of blank lines between each spec > section header. Currently you have either 1 or 2. (I prefer to use 2 so that > each heading stands out, but at least be consistent). I see what you mean, but at the same time, I don't want the spec file to get too long. However, I have added the spacing, should be more readable now. > - Use of tabs: in the top part, if you really want to use tabs, then the same > number of tabs should be used between each ':' and value. (Currently there is > some 2x or 1x tab, equating to between 1 and 4 characters spacing). The reason I used 1x and 2x tabs is to line all the entries. Does'nt look good otherwise. > - Can the package by used command line only ? No, GUI is required. > - There seems to be no files assigned to the main package. Does that create a > real but no files present package ? Could the -common subpackage instead just > be the main package ? The main "autokey" package is a meta-package. The reason I used this format was because of the two frontends available, gtk and qt. I searched around for packages that provide two frontends and found the spec for the "Transmission" package, and so I followed the implementation there. This is how the dependencies get pulled currently. On, Gnome : 1) autokey -> autokey-common -> autokey-gtk or 2) autokey-gtk -> autokey-common On, Kde : 3) autokey-qt -> autokey-common So, here Gnome users have the advantage of just using 1), run "yum install autokey" and get the package. They don't have to search and find that the package is named autokey-gtk. I could keep a common "autokey" package, but then I don't know to write the dependency to pull gtk, qt frontend. I guess I'd have to define "autokey-gtk" and "autokey-qt", but lose the Gnome advantage I mentioned above. > - As a side note: Upstream mentions it is essentially maintenance only, and > that the most up2date autohotkey compatibility is found with IronAHK. What > made you choose autokey rather than IronAHK for packaging ? Couple of reasons : 1. IronAHK uses mono, Autokey uses python (and I like python) 2. Autokey doesn't implement the advance features present in autohotkey (you'll have to use IronAHK for that) 3. So , it's a lot simpler 4. I like the interface and it's very lightweight 5. Has been very stable and has an active user community : http://groups.google.com/group/autokey-users 6. Featured on Lifehacker.com ( so, kinda well known :) ) Regarding "maintenance only", see below > - If bugs are present in autokey, do you feel that you would be able to tackle > them without upstream support ? Excerpt from autokey homepage : http://code.google.com/p/autokey/ " The development status of this software is support-only. Bug reports will be handled and fixes released if deemed appropriate, but no new features will be implemented. Users seeking more advanced features are encouraged to use and support IronAHK." So, the project is not dead, but on a feature freeze. Bugs found are being pursued and fixed : http://code.google.com/p/autokey/issues/list Please do let me know if you have any other concerns. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review