View Full Version : Timeline for patches?
just curious on how long it normally takes to get a thumbs up or thumbs down on a patch.
i submitted a patch about a week ago, but have gotton no feedback [1198898].
my main concern is that other changes may touch the same files and maintaining an up-to-date version of xbmc with the changes will become a nightmare.
jmarshall
2005-05-16, 20:53
1. developer time.
2. developer interest.
3. whether devs see a use for the patch.
4. interest by users in patch.
added to cvs. thanks a lot!
spiff
thanks.
now with the changes to the context menu i may start looking at having plugin context items via python.
if something like this is being added to xbmc, it should be added ubiquitously to all three media windows, not just one.
my implementation is highly experimental at the moment.
to implement this properly, there has to be a defined interface so that the python code can taste the item to see if the menu item should be enabled, and another for execution.
it will be a while...
i think this patch has broken the "resume video" option from the context menu because it isn't working anymore.
hmm, the formatting is a bit off. i'll see if somehow the patch went astray.
for the time being you can hit "play" with no video subwindow and resume should work.
found the bug and fixed it. took a bit longer because of the formatting weirdness. you can find the fixed code in the patch section.
hi,
probably my bad :) what do you mean by weird formatting?
spiff
most of the file had cr/lfs, which seems to be the standard, but the patch section had all the lfs replaced with crs.
if the patch file was used, maybe it was tortoisecvs's fault.
it really through me for a loop. i would remove some "blank" lines and the compiler would start complaining.
did a save-as with cr/lfs, then removed the extra lines and now i think its ok. (cross your fingers!).
actually i hand-merged the patch using gvim.
probably what caused it...
will try'n'apply your new version tomorrow.
@spiff
somehow the carriage returns got all munged, as if it was double-spaced. the changelog got messed up too but that seemed as if it was in unix carriage returns. not sure what happened but i cleaned it up.
@deadken
i like how addbutton returns a button id. it's much cleaner. i'm compiling the fix now.
okay,
i'll try to keep my nasty unix-habits in check for the future :)
but it's strange how every other editor just feels awkward once you've gotten used to vim..
the fix worked so i just checked it into cvs.
dont worry about it spiff... i'm a vim guy myself :) i could tell the changelog was do to unix formatting, but i'd never seen what happened to the cpp before.
@spiff
somehow the carriage returns got all munged, as if it was double-spaced. *the changelog got messed up too but that seemed as if it was in unix carriage returns. *not sure what happened but i cleaned it up.
@deadken
i like how addbutton returns a button id. *it's much cleaner. *i'm compiling the fix now.
@deadken
i like how addbutton returns a button id. it's much cleaner. i'm compiling the fix now.
thanks.
the only problem is having all those btn_ and if then elses is a pain.
idealy, you could use a switch statement on the button id, but since these are used internally by the menu itself, i was stuck with this work around.
i was considering adding a simple "tag" member, but really, this should be added at the control base, and i wanted to touch as few files as possible.
the if-then-else's arent that bad. the main advantage is its now easy to insert a new menu item inbetween existing ones. its more difficult on the windows using the switch statement since the id's are all internal.