Das Mischpult kann nicht angezeigt werden.
Es kann durch den Haken zwar aktiviert und deaktiviert werden, jedoch wird es auch im aktivierten zustand nicht angezeigt.
GIT commit: f51dc11
It sounds like you are needing help figuring out how to do something in MsueScore, but it isn't clear what. Please use the Support forum, not the issue tracker, to ask for further assistance (see "Help / Ask for Help" from within MuseScore). And please describe in more detail what you are trying to do, the steps you are taking, what you expect to see happen, and what happens instead.
Mir ist das gestern im Unterricht mit einer portablen Version passiert. Schüler kam mit seinem USB-Stick, an meinem Rechner erschien das Mischpult nicht.
Abgesehen davon, dass ich in dem Moment keinen Zugriff auf die Anleitung hatte, finde ich die Methode für den Alltag etwas daneben. Weil dann muss ich ja wieder die alten Gegebenheiten herstellen. Meinen Schülern ist ihre Zeit zu kostbar, als das sie darauf warten, dass ich dann erst einmal das Programm wieder zum laufen bringe.
Once again: this is the issue tracker, and as such in English. If you need to discuss something, please use the forum, if you need to discuss in German, please use the German forum.
However: if your pupil had used the portable version on a different PC before, it may very well happen that he moved that mixer to a place that your PC can't show, due to a smaller screen for example. There are 2 options to fix that, one is the facory reset, the other is to (find and) edit MuseScore.ini and get rid of the entry for mixer (without screwing up the other Settings), so it gets opened at ther default position again. The reset is certainly quicker, easier and safer.
If I have to take care of the screensize of the used notebooks, I would call it a bug. And a würgaround is not really a fix. I would call it a bug. But I know the Opensource answer, there is a possibility, so do not call it a bug, because we are (correctly: need the feeling) doing a great job, much better than all this commercial shit.
I don't usually respond to closed issues, but I read a bit of bitterness in hasenfuss' answer which I'd like to address.
It seems you've had quite some negative experience with OpenSource software and the elite attitude of some of their developers, an experience which I sadly had to share more than once as well. I've often came across a project where, when reporting a bug, the answer was "It's open source, fix it yourself or beat it".
I however would ask you to give the MuseScore developers/contributors the benefit of the doubt. In the (fairly short) time I've been around here, none of them have been too shy to admit they've introduced a bug and so far have always tried to come up with a solution (on the spot or sometimes only after months, depending on the priority). If that solution is only available in some future release, occasionally a workaround is provided as well.
Yes, a workaround is not a bugfix. I don't believe anyone will question that. A workaround is something (often inconvenient) to get/keep you going until a bugfix (or a missing feature for that matter) is in place. I invite you to have a browse through the open issues is the issue tracker (but only if you want to spend your time on that); you'll find there are issues which have workarounds, but those aren't closed off. Sometimes, if the workaround is easy enough, the priority of the issue might drop as a result. But a workaround indeed does not fix an issue.
Also note that this issue wasn't closed because it might-or-might-not be a bug. It was closed because the original post is one that should've gone into the forum. Only if the might-or-might-not is cleared up an issue should be created.
Though that workflow might seem a bit harsh (after all, who then gets to say something is a bug?) it helps in keeping the issue tracker more clear of false and duplicate reports. After all, who searches the tracker before submitting their issue? And even if you search first, who's to say you've used the same terminology as the previous report?
Its closure is not dismissive of wanting to ignore the issue, its even requesting more information to be able to provide better help (and enable a better analysis of the might-or-might-not status of the potential bug).
Now onto the actual issue at hand: panels/dialogs being offscreen when the resolution of the pc changed. To me, as to you, this would be regarded as a bug. The culprit here is that its strictly speaking not necessarily a MuseScore bug.
In MuseScore the previous coordinates of the window are stored, and when restarting the program, it reloads those values; no more, no less. Internally this means the MuseScore codebase asks the Qt graphics library to place the window at the restored position, which that library then in turn asks the window manager from your operation system. Some windowmanagers handle this by placing the window offscreen, some don't and put it at a default position (closest edge / top-left / centered).
Although at first glance, it seems an easy enough request, which could perhaps be handled by MuseScore; check where the window manager placed it, and eventually moved it after comparing with the visible screen area. However I imagine those coordinate values become more complex if you have a multi-monitor setup for example.
Lastly I want you to know that the developers do really value your feedback and take it to heart. This issue was just this morning brought up in the developers IRC (by Jojo-Schimtz) to ensure the developer who is currently working on saving/restoring dialog positions would not ignore this. Although in a first implementation step, simply saving/restoring for the dialogs is all that will be done; the developers are in agreement that detection (and moving into view) of offscreen dialogs is something we want to include in MuseScore as well.
Phew, that post turned out a bit longer than I anticipated as well, but I do hope it clarifies and addresses all you had expressed.
Comments
It sounds like you are needing help figuring out how to do something in MsueScore, but it isn't clear what. Please use the Support forum, not the issue tracker, to ask for further assistance (see "Help / Ask for Help" from within MuseScore). And please describe in more detail what you are trying to do, the steps you are taking, what you expect to see happen, and what happens instead.
Hast Du einen kleinen Bildschirm? Weil ab und zu sind die Bedienelemente außerhalb des Bildschirmes. Keine Ahnung wie Du das lösen könntest.
Schreib aber lieber auf Englisch.
Siehe https://musescore.org/de/handbuch/konfiguration-zur%C3%BCcksetzen-0
Mir ist das gestern im Unterricht mit einer portablen Version passiert. Schüler kam mit seinem USB-Stick, an meinem Rechner erschien das Mischpult nicht.
Abgesehen davon, dass ich in dem Moment keinen Zugriff auf die Anleitung hatte, finde ich die Methode für den Alltag etwas daneben. Weil dann muss ich ja wieder die alten Gegebenheiten herstellen. Meinen Schülern ist ihre Zeit zu kostbar, als das sie darauf warten, dass ich dann erst einmal das Programm wieder zum laufen bringe.
Once again: this is the issue tracker, and as such in English. If you need to discuss something, please use the forum, if you need to discuss in German, please use the German forum.
However: if your pupil had used the portable version on a different PC before, it may very well happen that he moved that mixer to a place that your PC can't show, due to a smaller screen for example. There are 2 options to fix that, one is the facory reset, the other is to (find and) edit MuseScore.ini and get rid of the entry for mixer (without screwing up the other Settings), so it gets opened at ther default position again. The reset is certainly quicker, easier and safer.
If I have to take care of the screensize of the used notebooks, I would call it a bug. And a würgaround is not really a fix. I would call it a bug. But I know the Opensource answer, there is a possibility, so do not call it a bug, because we are (correctly: need the feeling) doing a great job, much better than all this commercial shit.
I don't usually respond to closed issues, but I read a bit of bitterness in hasenfuss' answer which I'd like to address.
It seems you've had quite some negative experience with OpenSource software and the elite attitude of some of their developers, an experience which I sadly had to share more than once as well. I've often came across a project where, when reporting a bug, the answer was "It's open source, fix it yourself or beat it".
I however would ask you to give the MuseScore developers/contributors the benefit of the doubt. In the (fairly short) time I've been around here, none of them have been too shy to admit they've introduced a bug and so far have always tried to come up with a solution (on the spot or sometimes only after months, depending on the priority). If that solution is only available in some future release, occasionally a workaround is provided as well.
Yes, a workaround is not a bugfix. I don't believe anyone will question that. A workaround is something (often inconvenient) to get/keep you going until a bugfix (or a missing feature for that matter) is in place. I invite you to have a browse through the open issues is the issue tracker (but only if you want to spend your time on that); you'll find there are issues which have workarounds, but those aren't closed off. Sometimes, if the workaround is easy enough, the priority of the issue might drop as a result. But a workaround indeed does not fix an issue.
Also note that this issue wasn't closed because it might-or-might-not be a bug. It was closed because the original post is one that should've gone into the forum. Only if the might-or-might-not is cleared up an issue should be created.
Though that workflow might seem a bit harsh (after all, who then gets to say something is a bug?) it helps in keeping the issue tracker more clear of false and duplicate reports. After all, who searches the tracker before submitting their issue? And even if you search first, who's to say you've used the same terminology as the previous report?
Its closure is not dismissive of wanting to ignore the issue, its even requesting more information to be able to provide better help (and enable a better analysis of the might-or-might-not status of the potential bug).
Now onto the actual issue at hand: panels/dialogs being offscreen when the resolution of the pc changed. To me, as to you, this would be regarded as a bug. The culprit here is that its strictly speaking not necessarily a MuseScore bug.
In MuseScore the previous coordinates of the window are stored, and when restarting the program, it reloads those values; no more, no less. Internally this means the MuseScore codebase asks the Qt graphics library to place the window at the restored position, which that library then in turn asks the window manager from your operation system. Some windowmanagers handle this by placing the window offscreen, some don't and put it at a default position (closest edge / top-left / centered).
Although at first glance, it seems an easy enough request, which could perhaps be handled by MuseScore; check where the window manager placed it, and eventually moved it after comparing with the visible screen area. However I imagine those coordinate values become more complex if you have a multi-monitor setup for example.
Lastly I want you to know that the developers do really value your feedback and take it to heart. This issue was just this morning brought up in the developers IRC (by Jojo-Schimtz) to ensure the developer who is currently working on saving/restoring dialog positions would not ignore this. Although in a first implementation step, simply saving/restoring for the dialogs is all that will be done; the developers are in agreement that detection (and moving into view) of offscreen dialogs is something we want to include in MuseScore as well.
Phew, that post turned out a bit longer than I anticipated as well, but I do hope it clarifies and addresses all you had expressed.