On Sonntag, 29. August 2021 15:41:06 CEST Kolja Koch wrote: > > Regex patterns are doing the job, including use cases that go beyond > > your > > personal needs, and I don't have to maintain parsing code by myself. > > So the > > plan is to make this feature configurable by standard regex patterns > > only for > > now; no self-invented formats/tags and no custom parser code on top > > that would > > need to be developed, documented, extended and ... fixed. Instead > > some regex > > examples in the man page should already be a good starting point for > > new > > users. > > As I said, that's fine with me. This could lead to a commandline > switch, where for each attribute a regex would be given. That should be > a relatively small patch.
Exactly. Small changes, little worries. > > People who might refrain from using the wav2gig tool because of regex > > patterns > > being user-unfriendly, usually neither want to use command line tools > > in the > > first place. So for such people you would rather want to write a GUI > > app ontop > > of libgig where you could really invest a *load* of development time > > and > > people would probably still give you suggestions how it could be > > improved. > > E.g. you can make a clickable pattern editor with coloured > > highlighting and > > nice token frames that would show you a preview of the expected > > results in > > real-time, and you could combine that with an automatic prescan of a > > directory > > and deploy an A.I. on top of the prescan for a fully automated > > initial pattern > > suggestion. > : > :) Yes, I thought about these suggestions as well, including the A.I.. Yeah, I know. :) > : > > Well, if you really want to start such kind of project: I would > > recommend to > > reconsider the toolkit decision and no longer use gtk(mm) for new > > projects > > anymore, for many reasons actually. You would probably safe yourself > > a load of > > development time and frustration on the long run by simply picking > > another > > toolkit right from the start. > > Do you have any suggestions for one? I better don't. ;-) If you asked me couple years ago, I would have clearly said Qt. Nowadays the latter also aged and lacks things that I would expect from a modern UI toolkit today. > I just picked gtk because gigedit uses it... gigedit still uses gtk(mm) simply because it was started that way, and it probably always will, because a rewrite for another toolkit would be too much work now. AFAICR when Andreas started work on gigedit he expected of spending just like few weeks of spare-time on it, so AFAIK he picked a toolkit that matched natively/visually his personal favourite desktop at that time. CU Christian _______________________________________________ Linuxsampler-devel mailing list Linuxsampler-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxsampler-devel
