curScore.name
This value seems to be blank or undefined when I try to access it directly. Is there a trick to finding out the current score's filename?
Do you still have an unanswered question? Please log in first to post your question.
This value seems to be blank or undefined when I try to access it directly. Is there a trick to finding out the current score's filename?
Do you still have an unanswered question? Please log in first to post your question.
Comments
As per this score.title should be answer?
In reply to As per this score.title by Jojo-Schmitz
Originally, "name" was supposed to hold the full pathname, or so I inferred from the documentation at the time (it has now been removed from the documentation). My first attempt at a PDF export plugin was just to export the current score, and I wanted to get the pathname of the current score so I could save a PDF with the same basename, back to the same folder, with no input required from the user. The "title" field doesn't give me any of that information, so not the same thing. On the other hand, now that we have the plugin to export the full contents of a folder, I don't care so much about my original plugin idea. Still would be nice to have access to the pathname at some point, though.
In reply to Originally, "name" was by Marc Sabatella
Oh, in that case I'd like score.name to be added to the plugin interface
In reply to Oh, in that case I'd like by Jojo-Schmitz
Me too, although I kind of suspect there is a reason it was pulled from the documentation rather than being implemented. Seems like it should be a straightforward thing to implement, but perhaps there turned out to be unforeseen consequences?
Anyhow, it occurs to me that grabbing the pathname of the current score would be a great way to set the starting folder for the file dialogs such as the one in batch (pdf) export. As it is, the Qt framework provides a way to get the users' "Home" folder, but it doesn't actually work the way one would want on Windows. It shows "C:\Users\Name\" even if your Documents folder has been redirected to live on a different drive.
If for some reason curScore.name as a full pathname) really is something that is problematic to pass to a plugin, for the purposes of setting a default folder in file dialogs, the folder the user configured as his Working directory in Preferences would be useful as an alternative. And that would be a nice thing to have in any case.
In reply to Me too, although I kind of by Marc Sabatella
curScore.name is not really a developer friendly name if we want to send back the filename or the complete path. Maybe curScore.filename. What would you expect if the file has never been saved?
In reply to curScore.name is not really a by [DELETED] 5
Good point. Title is nice for what it is, I would say filename or pathname is what I would be expecting here. I guess it wuld be empty in the case of an unsaved file. Which means it isn't quite as useful for setting the default folder for file dialogs as it otherwise might be, and that getting at the global workingDirectory setting would be nice too. Actually, given the choice, the latter is probably more useful to me at this point than the filename of the current score, but I know for 2.0, there are all sorts of new user directories, so I'm not sure one global workingDirectory variable makes sense going forward.
In reply to curScore.name is not really a by [DELETED] 5
If the file has never been saved, score.name could contain either nothing (as Marc noted) or the proposed filename, consisting of prefDir + score.title + ".mscz", just like the MuseScore Save dialog does it, can't it? Default for score.title seems to be 'Untitled'?
The attached patch adds score.filename (which returns only the name of the file without the path, "Untitled" for unsaved scores) and score.filepath (which returns the path of the score without the name of the file, an empty string if the file is not saved) to the plugin API. Please let me know if it should be done in some other way.
Soerboe
In reply to The attached patch adds by Soerboe
The patch is commited and works as advertised. I still wonder if it's the best interface we can provide. We could also send back the full QFileInfo object. Is that too much for plugin developers?
In reply to The patch is commited and by [DELETED] 5
To send back the QFileInfo adds quite some complexity. It could be fine for some, but way too much to handle for others. One possibility could be to have both options, so the plugin developer can choose.
In reply to To send back the QFileInfo by Soerboe
I'd like to have a choice, so vote for having both...
In reply to The patch is commited and by [DELETED] 5
If it's reasonably easy for a plugin to get QFileInfo onject itself, given a pathname, then I don't know that the framework needs to.
As for the plugin i terface provide by the patch, getting name and directory seaprately is fine, but I'd have been happy with just a single property that returned the ful path. I kind of expect that if I'm asking about files, I'm going to be doing some sort of manipulations with the names anyhow, so it really doesn't matter. I would say the name of the proposed property for the directory seems awkward to me, but I don't know if it's consistent with usage elsewhere in the code or in Qt.
In reply to If it's reasonably easy for a by Marc Sabatella
The reason I separated the path and the filename was to be able to get the folder without having to extract the it from the whole path. And it's easy to just combine the two if you want the full path. But there's no problem changing it if something else works better. What is your suggestion?
In reply to The reason I separated the by Soerboe
I'm not opposed to having the file and directory available separately. I just would normally expect the plugin framework to try to provide the minimum number of properties and methods it can, as opposed to going out of its way to provide the convenience of separate properties for things like this. No big deal, though. It is of course easier for the user to have them separate, as I'm likely to need to work with them seprately anyhow. As for the naming, I don't know how standard "filepath" is; that's really my main concern - and it too is a small one.
In reply to I'm not opposed to having the by Marc Sabatella
I agree with filepath naming, the tiny patch attached changes it to score.path.
As for the separation I find it convenient to be able to know the folder path without doing string manipulations yourself (and the same for the filename)
In reply to I agree with filepath naming, by Soerboe
path and fileName are standard in Qt : http://doc.qt.nokia.com/latest/qfileinfo.html
I suggest to stick with them and I will change the case.
You don't need to do any string manipulation yourself. If you have the full path, create a QFileInfo
var fi = new QFileInfo(path);and you can get anything, including basename (without extension). That's why I asked if a QFileInfo wouldn't be easier to handle.