Hi! Ralph Glasstetter wrote:
>>I guess it's not necessary to support the format in the project file - >>unless you're going to create project files with a script. > > That was, actually the idea behind that... when editing project files by hand > or automatically by some script and you don't have a frame number > but a time and you are to lazy to calculate. ;-) I'm too lazy to type as well ;) >>>BTW, we now also have an "-exp"-CLI-switch to specify an export >>>file/location in addition to the (optional) <expfile>-projectfile-tag. >>>Nevertheless, the latter has still priority... >> >>It's usually the other way round: command line switches override >>configuration files. > > > Hey,... no problem with that! I also find it more logical to override a > projectfile default with a CLI-option, since the latter is easier to > change... ;-) > > Also -idx is implemented that way... to be consistent CLI should overrule PRJ > for all options! At least for the "simple" options. > And should I also override the start/stop-markers from the project file with > the "-cut" the option? At the moment the -cut-markers are just added... > (BUG-Alert!!! This causes strange behavoir, since when adding new start/stop > markers, the result won't be necessarily alternated anymore!!!). > > So either I delete any old ones (also in GUI-mode with convert bookmarks!) > or always just insert/add new markers, sort the whole list and then alternate > START/STOP... at the moment the appended patch will implement the first > option. Sorting might convert start markers in stop markers and vice versa. In general, this is not what users expect. > Another option would be to replace only in batch mode and add in gui-mode...? I guess replace is the most logical option in all cases. >>[...] >> >>>- if (it->export_flag) >>>+ if (it->export_flag && it!=quick_picture_lookup.end()) >> >>I'm pretty sure this change is useless. `it' can't be at the end of the >>list because it has just been decremented (i.e. moved towards the front >>by one position). > > > Hmmm,... of course you are right... very strange,... I thought I tested > that...?!? :-| Since the new additional condition is always true, I bet you didn't notice any difference. > OK,... in the updated patch file it is now compared to > "quick_picture_lookup.end()-1"! > A cleaner solution maybe would be to set the export_flag of a START-entry > only > to true, if there follows a STOP-entry...? I'd rather keep the flag and make dvbcut act accordingly (i.e. export everything from the last start marker up to EOF). > The appended patch also implements no strict CLI overrules PRJ and adds a > few more context menu entries (hmmm..., quite a long list now!). Too long, in my opinion - a context menu should have at most half a dozen entries, approximately. Maybe we should move similar entries to submenus (e.g. the whole "Delete all X" and "Convert to X" stuff). Patch applied anyway :) We can get the rest done with additional patches. By the way: I would prefer separate patches for every bugfix and every new feature. With these monster patches, it's too hard to track errors because you always have to review all changes. With "atomic" patches, on the other hand, you can e.g. remove a single feature and check if the problem persists. Welcome to r97, -- Michael "Tired" Riepe <[EMAIL PROTECTED]> X-Tired: Each morning I get up I die a little ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DVBCUT-user mailing list DVBCUT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dvbcut-user
