From: Guillaume L. <gla...@te...> - 2004-02-19 23:52:58
|
Following up on BR 851972 ("open file" always relies on extension), I've changed the RG file read/write to use KFilterDev rather than raw zlib calls. The reason is to be able to set the original file name to some 'magic' constant which can then be recognized by the KDE mime classes (see $KDE/ share/mimelnk/magic, especially the KOffice types). Other side benefits include much simpler code and faster execution (no need to use an intermediate string to read or write the uncompressed file into). I propose the following plan regarding the mime type : - leave things as they are now for the next release. Current rg files can still be loaded, saved files now carry a mime type string in the gzip header that will allow them to be recognized even without a .rg|.rgd suffix. - announce with the next release that you need to load and resave your files with this release - add the magic mime types in the 2nd next release. -- Guillaume. http://www.telegraph-road.org |
From: Richard B. <ric...@fe...> - 2004-02-20 07:28:18
|
On Thursday 19 February 2004 23:47, Guillaume Laurent wrote: > - add the magic mime types in the 2nd next release. I think we should just have both file open methods alongside each other indefinitely (now we have something of a user base) rather than just having this new migration way available for one point release. Either that or an automatic upgrade filter inside RG. Anyway we should push to go into beta testing sometime soon - and to do that we don't want to have releases with many major changes in, and this would definitely count as one of those I'd say in the form you're suggesting. Let's be a little pragmatic about it so we don't piss off the users we already have. R |
From: Guillaume L. <gla...@te...> - 2004-02-20 09:27:31
|
On Friday 20 February 2004 08:22, Richard Bown wrote: > On Thursday 19 February 2004 23:47, Guillaume Laurent wrote: > > - add the magic mime types in the 2nd next release. > > I think we should just have both file open methods alongside each other > indefinitely (now we have something of a user base) rather than just having > this new migration way available for one point release. We can't, unless perhaps we keep the current mime type around, renaming it to something else... But we already have 4, there would be 6 (since there's actually 2 mime types for RG files : .rg and .rgd). > Either that or an automatic upgrade filter inside RG. That's a possibility, but it shouldn't be too elaborate either. I doubt users have tons of files already. Providing a simple external converter is another solution. -- Guillaume http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2004-02-20 08:32:31
|
On Thursday 19 Feb 2004 11:47 pm, Guillaume Laurent wrote: > Following up on BR 851972 ("open file" always relies on extension), > I've changed the RG file read/write to use KFilterDev rather than > raw zlib calls. Fine, good. (Provided it works -- haven't tested it yet.) > I propose the following plan regarding the mime type : > > - leave things as they are now for the next release. Current rg > files can still be loaded, saved files now carry a mime type string > in the gzip header that will allow them to be recognized even > without a .rg|.rgd suffix. > > - announce with the next release that you need to load and resave > your files with this release I don't entirely understand why this step is necessary. Can't we continue to "recognise" any file with a .rg or .rgd extension as a Rosegarden file, and additionally use the mime type to recognise files that don't have such an extension? (Will it continue to be possible to load a Rosegarden file that does not have a .rg extension and does not have a magic mime type, by naming it on the command line? At the moment you can run e.g. "rosegarden my-rosegarden-file.some-random-extension" and it'll work if the file is in fact actually a Rosegarden one. We need to preserve that; if we do, then it may make it more acceptable to "suggest" that people re-save their files with an intermediate version, since they won't have lost them beyond the reach of a simple bit of troubleshooting. In that case I could maybe accept a plan to make every version from here to 0.9.9.x or 1.0-pre-x accept non-magic files in the file dialog and just pop up a dialog warning you about their non-magic-ness, and then turn that off before 1.0. But I would also need to know, as I said, why this was necessary at all.) Chris |
From: Guillaume L. <gla...@te...> - 2004-02-20 09:19:28
|
On Friday 20 February 2004 09:29, Chris Cannam wrote: > > > > - announce with the next release that you need to load and resave > > your files with this release > > I don't entirely understand why this step is necessary. Can't we > continue to "recognise" any file with a .rg or .rgd extension as a > Rosegarden file, and additionally use the mime type to recognise > files that don't have such an extension? Not as far as I can see. A mime type relies either on the extension or on magic-lookup of the file contents, these are mutually exclusive. > (Will it continue to be possible to load a Rosegarden file that does > not have a .rg extension and does not have a magic mime type, by > naming it on the command line? Of course, what I'm trying to fix is precisely to have this same behavior when loading an RG file from the GUI, which is currently not the case. > if we do, then it may make it more acceptable to > "suggest" that people re-save their files with an intermediate > version, since they won't have lost them beyond the reach of a simple > bit of troubleshooting. In that case I could maybe accept a plan to > make every version from here to 0.9.9.x or 1.0-pre-x accept non-magic > files in the file dialog and just pop up a dialog warning you about > their non-magic-ness, and then turn that off before 1.0. That's doable. -- Guillaume http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2004-02-20 09:23:44
|
On Friday 20 Feb 2004 9:13 am, Guillaume Laurent wrote: > Not as far as I can see. A mime type relies either on the extension > or on magic-lookup of the file contents, these are mutually > exclusive. That's a shame. We very much want to say that if the magic lookup fails, we should still use the extension. > > (Will it continue to be possible to load a Rosegarden file that > > does not have a .rg extension and does not have a magic mime > > type, by naming it on the command line? > > Of course, what I'm trying to fix is precisely to have this same > behavior when loading an RG file from the GUI, which is currently > not the case. I think you missed the "and does not have a magic mime type" part -- I'm just asking whether relying on magic mime types (so as to make it possible to load non-.rg RG files from the GUI) will make it impossible to load non-.rg non-magic RG files at all, or whether we will continue to accept totally unmagic-looking files on the command line and treat them as potential candidates for RG-format file loading. Chris |
From: Guillaume L. <gla...@te...> - 2004-02-20 09:38:05
|
On Friday 20 February 2004 10:21, Chris Cannam wrote: > That's a shame. We very much want to say that if the magic lookup > fails, we should still use the extension. If all mime types could do that, that would become awfully complicated :-). > I think you missed the "and does not have a magic mime type" part -- > I'm just asking whether relying on magic mime types (so as to make it > possible to load non-.rg RG files from the GUI) will make it > impossible to load non-.rg non-magic RG files at all, No, the only thing that will change is what the File->Open dialog will display (and, more generally, what Konqueror will display too), nothing more. File loading in itself is unchanged. -- Guillaume http://www.telegraph-road.org |
From: Richard B. <ric...@fe...> - 2004-02-20 09:37:51
|
On Friday 20 February 2004 09:21, Chris Cannam wrote: > On Friday 20 Feb 2004 9:13 am, Guillaume Laurent wrote: > > Not as far as I can see. A mime type relies either on the extension > > or on magic-lookup of the file contents, these are mutually > > exclusive. > > That's a shame. We very much want to say that if the magic lookup > fails, we should still use the extension. Yeah, I must admit I don't see quite what any of this wins the user except better KDE compatability - and I don't give a shit about that really. Aren't we just sacrificing some of our functionality here? I certainly don't think we should losing backwards compatability in any way at all at this stage. Rosegarden-4 (1.0) must be able to handle RG files pretty much as have been in circulation for the last year or so. R |
From: Chris C. <ca...@al...> - 2004-02-20 09:42:02
|
On Friday 20 Feb 2004 9:31 am, Richard Bown wrote: > On Friday 20 February 2004 09:21, Chris Cannam wrote: > > On Friday 20 Feb 2004 9:13 am, Guillaume Laurent wrote: > > > Not as far as I can see. A mime type relies either on the > > > extension or on magic-lookup of the file contents, these are > > > mutually exclusive. > > > > That's a shame. We very much want to say that if the magic > > lookup fails, we should still use the extension. > > Yeah, I must admit I don't see quite what any of this wins the user > except better KDE compatability It wins the user the ability to open files in Rosegarden that don't have .rg or .rgd extensions. At first glance that sounds like a pointless thing to want, but the problem is you often get files served through browsers or whatever that have random dynamic names (file.php?id=blah&user=blah actually turns out to be a Rosegarden file or whatever). It's also of course more like the proper Unix way of doing things: identify a file by what it actually consists of rather than what it's called. I don't think it makes any difference to KDE compatibility. That said, I do agree with this: > Rosegarden-4 (1.0) > must be able to handle RG files pretty much as have been in > circulation for the last year or so. Chris |
From: Guillaume L. <gla...@te...> - 2004-02-20 09:48:36
|
On Friday 20 February 2004 10:31, Richard Bown wrote: > Yeah, I must admit I don't see quite what any of this wins the user except > better KDE compatability It allows us to select RG files regardless of their extension. > Aren't we just sacrificing some of our functionality here? It's either that or we force rg files to carry the right extension, we can't have both. > I certainly > don't think we should losing backwards compatability in any way at all at > this stage. Rosegarden-4 (1.0) must be able to handle RG files pretty much > as have been in circulation for the last year or so. I doubt there's been that many, really. It worst a simple external converter and an FAQ entry will be enough. -- Guillaume http://www.telegraph-road.org |
From: Richard B. <ric...@fe...> - 2004-02-20 09:58:15
|
On Friday 20 February 2004 09:42, Guillaume Laurent wrote: > > Aren't we just sacrificing some of our functionality here? > > It's either that or we force rg files to carry the right extension, we > can't have both. Well I vote for not changing anything then. I don't see a need to break things to shoehorn in some unlikely if "correct" technology. From a user perspective it's not correct. > > I certainly > > don't think we should losing backwards compatability in any way at all at > > this stage. Rosegarden-4 (1.0) must be able to handle RG files pretty > > much as have been in circulation for the last year or so. > > I doubt there's been that many, really. It worst a simple external > converter and an FAQ entry will be enough. That's not the point, Guillaume. Anyway you blithely saying that you doubt there are that many is a) wrong and also b) doesn't inspire any of our existing users and kind testers now does it? Logic or Cubase would't expect a user to run an external command line tool to import their files. Why should we? Especially so close to beta and 1.0 we shouldn't be doing anything to scare off testers. This is more about our attitude to our users than it is about this mere technical point. Try stepping outside of your developer's shoes for a minute and consider someone working with our software in a studio. Ron at Mirror Image uses Rosegarden, plenty of people on the user's list have posted songs too - they are a fraction of the people that will have tried it out. Consequently this functionality needs to be seamless or not at all. R |
From: Guillaume L. <gla...@te...> - 2004-02-20 10:18:58
|
On Friday 20 February 2004 10:52, Richard Bown wrote: > On Friday 20 February 2004 09:42, Guillaume Laurent wrote: > > > Aren't we just sacrificing some of our functionality here? > > > > It's either that or we force rg files to carry the right extension, we > > can't have both. > > Well I vote for not changing anything then. I don't see a need to break > things to shoehorn in some unlikely if "correct" technology. From a user > perspective it's not correct. I think you're seeing this as a bigger issue than it really is. I don't suggest we prevent users from loading their files all of a sudden, we can give them plenty of times to simply load and resave their files. In most cases they will do so without realizing it throughout the natural course of their work, indeed seamlessly. -- Guillaume http://www.telegraph-road.org |
From: Richard B. <ric...@fe...> - 2004-02-20 10:26:11
|
On Friday 20 February 2004 10:12, Guillaume Laurent wrote: > I think you're seeing this as a bigger issue than it really is. I'm seeing it as a user would see it. If a user's file doesn't load then that's the biggest issue there can be. If the upgrade path isn't invisible and fully backwards compatible then there's no way we should be doing it. R |
From: Guillaume L. <gla...@te...> - 2004-02-20 10:32:44
|
On Friday 20 February 2004 11:20, Richard Bown wrote: > > I'm seeing it as a user would see it. If a user's file doesn't load then > that's the biggest issue there can be. It's not that it won't load, but that it will, eventually, not be seen from the File->Open dialog. It would still work if you pass it directly on the command line. > If the upgrade path isn't invisible > and fully backwards compatible then there's no way we should be doing it. Then I suppose renaming and keeping the current mime types around along with the new magic-based ones is the only solution. -- Guillaume http://www.telegraph-road.org |
From: Michael G. <mg...@te...> - 2004-02-20 10:23:01
|
Hi developers ! I'm not quite sure I do understand all the technical implications of doing it one way and why doing it the other way raises which complications. However I always liked the way Logic did handle the switch from their format pre-version 5 and version 5+. When they load a file they recognize the format from the content (it is a binary format). Thus they realize wether it had been created on Atari/Mac (ie. it is big endian) or Wintel. There is a popup box informing the user wether that's ok and then it is loaded. When saving they use version 5+ and they have a special menuentry to save in pre-version 5 (version 4.8 actually) for easier exchange with people that did not yet upgrade their version of Logic. What I would expect RG to do is use being able to load "old" .rg/.rgd/.whatever files through the file->open dialog. This functionality should be preserved for quite some time to allow users to upgrade their files at their leisure. FWIW I still have Logic-files written with Logic 3.5 lying around. I really appreciate that I can read them with Logic 5.5 A solution that satisfies the above requirement gets my thumbs up. Best, Michael -- Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Chris C. <ca...@al...> - 2004-02-20 10:32:06
|
On Friday 20 Feb 2004 10:16 am, Michael Gerdau wrote: > What I would expect RG to do is use being able to load "old" > .rg/.rgd/.whatever files through the file->open dialog. This > functionality should be preserved for quite some time to allow > users to upgrade their files at their leisure. Yes, and the problem here is that although (in the proposed scheme) we would be able to load any kind of .rg file forever, we would only be able to do so from the command line -- the "old" files would stop showing up in the file dialog at all. I'm afraid that's confusing ("my files have disappeared!") as well as bad-in-principle. I think Rich is pretty much right here -- although it's true that pre-1.0 is the right time to change the file format if we have to, unless we can have it both ways (recognising the extension as well as the file contents) then the gain from this feature is not really sufficient. That annoys me because it's a feature I very much want, but the cost of just making any file you didn't edit with 0.9.7 seem to disappear altogether when using 0.9.8 (or whatever) is too much. Chris |
From: Michael G. <mg...@te...> - 2004-02-20 10:44:56
|
> > What I would expect RG to do is use being able to load "old" > > .rg/.rgd/.whatever files through the file->open dialog. This > > functionality should be preserved for quite some time to allow > > users to upgrade their files at their leisure. > > Yes, and the problem here is that although (in the proposed scheme) we > would be able to load any kind of .rg file forever, we would only be > able to do so from the command line -- the "old" files would stop > showing up in the file dialog at all. I'm afraid that's confusing > ("my files have disappeared!") as well as bad-in-principle. Logic "solves" this by allowing the user to select between different filetypes in the dialog: - Logic songs (.lso) - MIDI files (.mid) - all Logic files (.lso, .mid and possibly some other) - all files (*.*) I think it would be acceptable to present a similar solution. Best, Michael -- Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: mg...@te... GPG-keys available on request or at public keyserver |
From: Silvan <dmm...@us...> - 2004-02-20 23:11:49
|
On Friday 20 February 2004 05:29 am, Chris Cannam wrote: > sufficient. That annoys me because it's a feature I very much want, > but the cost of just making any file you didn't edit with 0.9.7 seem > to disappear altogether when using 0.9.8 (or whatever) is too much. Why not have cake and eat it too? The first time I run the GIMP, it triggers a first-time setup mode. What if the first time I ran 0.9.7 it offered me the option of finding and converting all of my old data files to the new format? A simple script could do the trick nicely. The only problem I see with *this* idea is that I have a lot of fucked up RG files with no extension or with .mid extensions, thanks to various bugs. A find command wouldn't catch those. A combination of find and file might improve the odds of finding everything, but there would still be a risk of missed files, and of false positives. Additionally, it could take a hell of a long time to run if the user has a huge number of files in userspace. As far as my opinion overall, I don't really care how this goes. Not being able to load old files is not an issue because I haven't ever actually done anything creative with Rosegarden yet anyway. I have an assortment of converted MIDI files and a slew of test files, but nothing terribly important. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ |
From: Richard B. <ric...@fe...> - 2004-02-20 10:39:46
|
On Friday 20 February 2004 10:29, Chris Cannam wrote: > unless we can have it both ways (recognising the extension as well as > the file contents) Yeah, and I'm still not quite clear why we can't have both. BTW just reading Michael's reply I was struck that we should have an export or save as RG2.1 filter really. Can't believe we've never thought of that one before. R |
From: Chris C. <ca...@al...> - 2004-02-20 10:43:05
|
On Friday 20 Feb 2004 10:33 am, Richard Bown wrote: > BTW just reading Michael's reply I was struck that we should have > an export or save as RG2.1 filter really. Can't believe we've > never thought of that one before. What do you mean, "we've never thought of that one before"? The only reason we don't have it is that in order to have it we would first have to write it, and that part has not been done. Chris |
From: Richard B. <ric...@fe...> - 2004-02-20 10:44:27
|
On Friday 20 February 2004 10:40, Chris Cannam wrote: [RG2.1 export] > What do you mean, "we've never thought of that one before"? The only > reason we don't have it is that in order to have it we would first > have to write it, and that part has not been done. Ok, well I don't remember a conversation about it and I don't see it on a TODO list or as a feature request (not that I've looked). R |
From: Guillaume L. <gla...@te...> - 2004-02-20 23:30:50
|
On Friday 20 February 2004 00:47, Guillaume Laurent wrote: > I propose the following plan regarding the mime type : > > - leave things as they are now for the next release. Current rg files can > still be loaded, saved files now carry a mime type string in the gzip > header that will allow them to be recognized even without a .rg|.rgd > suffix. > > - announce with the next release that you need to load and resave your > files with this release > > - add the magic mime types in the 2nd next release. OK, discard that, it was based on completely false premises. First, the good news : it's perfectly possible to have both a magic and a pattern-based mimetypes. So adding the magic mimetype won't prevent "old" .rg files from being seen by the File->Open dialog. Then, the (somewhat) bad news : for technical reasons not worth explaining here, it's not possible for us to have our magic mime type described in a seperate file installed in $KDE/share/config/magic/ (this pb is specific to our mimetype and the fact it's gzipped-derived). The mimetype has to be included in the main $KDE/share/mimelnk/magic file at a precise location. I've asked for permission to commit it in KDE CVS and David Faure just agreed, so KDE will have it starting with v3.2.1. So for the moment we can let this issue rest. -- Guillaume. http://www.telegraph-road.org |
From: Silvan <dmm...@us...> - 2004-02-21 00:24:51
|
On Friday 20 February 2004 06:24 pm, Guillaume Laurent wrote: > I've asked for permission to commit it in KDE CVS and David Faure just > agreed, so KDE will have it starting with v3.2.1. > > So for the moment we can let this issue rest. Oh, I see. Yeah, rest for a good bit I should think. I just did a big KDE upgrade last night (Debian Testing) and I'm all the way up to 3.1.5 now. I have no idea where 3.2 is, but I gather people running every other distro have had it for months now. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ |
From: Guillaume L. <gla...@te...> - 2004-02-21 00:29:23
|
On Saturday 21 February 2004 01:18, Silvan wrote: > > have no idea where 3.2 is, but I gather people running every other distro > have had it for months now. It's only been released this month :-) -- Guillaume. http://www.telegraph-road.org |
From: Silvan <dmm...@us...> - 2004-02-21 05:16:05
|
On Friday 20 February 2004 07:22 pm, Guillaume Laurent wrote: > > have no idea where 3.2 is, but I gather people running every other distro > > have had it for months now. > > It's only been released this month :-) I should get it in fall then. (I could go get it now, I'm sure, but I've grown tired of screwing around with unreliable third-party package sources, and I have plenty of patience...) -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ |