From: Seb J. <se...@hy...> - 2004-03-28 16:25:05
|
Hi Folks, Firstly, congratulations on an excellent application! I'm using 4.0.9.6 to input data using the stave editor. Don't have a keyboard at the moment. I'm using RG to help me study for a music theory exam. The problem I am having concerns time signatures and keys. Although it seems easy to add a time sig/key/clef change at some point during the music, it would be immensely useful to be able to set a key and time signature for _all_ the tracks in a project, as well as being able to easily put the desired clef in at the start of the music. Am I missing something here? It seems that all the code is available to do this, it's just a UI issue. Feature request number 2 is that it would be really useful to (in the stave editor or anywhere else) be able to click start and end points and have the music immediately start looping. Again - am I missing the right way to do this? I've also noticed a crash being caused when I manage my midi devices, related, it seems, to importing and exporting midi banks for my timidiy soft synth ports. What development tools are used to develop RG? regards, Seb James -- Managing Director, Educational Systems, Hypercube Systems Ltd Providing Open Source ICT solutions for schools. Tel: 0845 458 0277 Web: www.hypercubesystems.co.uk Mob: 07900 958964 Email: se...@hy... |
From: Silvan <dmm...@us...> - 2004-03-28 16:54:38
|
On Sunday 28 March 2004 11:25 am, Seb James wrote: > What development tools are used to develop RG? vim, emacs... A couple of the old dialogs were done with QT Designer... I don't think anyone is using anything fancier than that. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ |
From: Seb J. <se...@hy...> - 2004-03-28 22:04:17
|
On Sun, 2004-03-28 at 16:54, Silvan wrote: > On Sunday 28 March 2004 11:25 am, Seb James wrote: > > > What development tools are used to develop RG? > > vim, emacs... A couple of the old dialogs were done with QT Designer... I > don't think anyone is using anything fancier than that. Ah ok. Wondered if KDevelop/QTDesigner had been used. |
From: Chris C. <ca...@al...> - 2004-03-29 09:11:24
|
On Sunday 28 Mar 2004 5:25 pm, Seb James wrote: > Although it seems easy to add a time sig/key/clef change at > some point during the music, it would be immensely useful to be > able to set a key and time signature for _all_ the tracks in a > project, as well as being able to easily put the desired clef in at > the start of the music. Am I missing something here? No. What I'd like to do is a "New..." dialog for creating new documents which gave you the option of starting completely from scratch (as now) or starting with a certain number of tracks with segments pre-created to a certain number of bars in certain clefs, keys, time signatures etc. Actually that's the sort of stand-alone dialog anyone could do -- wouldn't take much knowledge of RG internals. Any takers? > Feature request number 2 is that it would be really useful to (in > the stave editor or anywhere else) be able to click start and end > points and have the music immediately start looping. You can shift-drag a loop area on the playback ruler at the bottom of the editor windows, or you can select a region of notes and use "Set Loop to Selection" on the Move menu (or key ctrl-semicolon). Is that the sort of thing you want? Chris |
From: Seb J. <se...@hy...> - 2004-03-29 10:17:38
|
On Mon, 2004-03-29 at 09:25, Chris Cannam wrote: > On Sunday 28 Mar 2004 5:25 pm, Seb James wrote: > > Although it seems easy to add a time sig/key/clef change at > > some point during the music, it would be immensely useful to be > > able to set a key and time signature for _all_ the tracks in a > > project, as well as being able to easily put the desired clef in at > > the start of the music. Am I missing something here? > > No. What I'd like to do is a "New..." dialog for creating new > documents which gave you the option of starting completely from > scratch (as now) or starting with a certain number of tracks with > segments pre-created to a certain number of bars in certain clefs, > keys, time signatures etc. > > Actually that's the sort of stand-alone dialog anyone could do -- > wouldn't take much knowledge of RG internals. Any takers? I'll do it. Will need to get CVS RG and you'll need to point me at the right source file and a similar dialog that I can crib from. > > Feature request number 2 is that it would be really useful to (in > > the stave editor or anywhere else) be able to click start and end > > points and have the music immediately start looping. > > You can shift-drag a loop area on the playback ruler at the bottom of > the editor windows, or you can select a region of notes and use "Set > Loop to Selection" on the Move menu (or key ctrl-semicolon). Is that > the sort of thing you want? Yes, I'll have a play there. thanks for the replies, Seb. |
From: Chris C. <ca...@al...> - 2004-05-23 15:37:24
|
On Monday 29 Mar 2004 11:17 am, Seb James wrote: > On Mon, 2004-03-29 at 09:25, Chris Cannam wrote: > > No. What I'd like to do is a "New..." dialog for creating new > > documents which gave you the option of starting completely from > > scratch (as now) or starting with a certain number of tracks with > > segments pre-created to a certain number of bars in certain > > clefs, keys, time signatures etc. > > > > Actually that's the sort of stand-alone dialog anyone could do -- > > wouldn't take much knowledge of RG internals. Any takers? > > I'll do it. Will need to get CVS RG and you'll need to point me at > the right source file and a similar dialog that I can crib from. Did anything become of this? Chris |
From: Chris C. <ca...@al...> - 2004-03-29 18:26:35
|
On Monday 29 Mar 2004 11:17 am, Seb James wrote: > On Mon, 2004-03-29 at 09:25, Chris Cannam wrote: > > Actually that's the sort of stand-alone dialog anyone could do -- > > wouldn't take much knowledge of RG internals. Any takers? > > I'll do it. Will need to get CVS RG and you'll need to point me at > the right source file and a similar dialog that I can crib from. Well, let's see. The dialog would probably want to be invoked from RosegardenGUIApp::slotFileNew() in gui/rosegardengui.cpp, in the makeNew branch that currently just creates a new document. I imagine it would pop up the dialog before doing that, so as to abandon in time if the user hit cancel, and then based on the result of the dialog it would add a few segments to the composition in the document, fill them with rests (with Segment::fillWithRests), insert some clef and key events, set up the composition's tempo and time signatures (using the Composition API) etc. As for the dialog itself, I'm not sure that there is a great example of a similar one already. There are a few dialogs in gui/dialogs. {h,cpp}, and some of those (e.g. quantization dialog, although that's largely defined in a separate frame widget in widgets.{h,cpp}) have a similar idea of offering a broad selection of possibilities with options for each -- or the event filter dialog (gui/eventfilter.h) might be helpful. Other apps like KWord have a File->New dialog that does something similar too, although I'm not particularly keen on the one in KWord. Most of our dialogs are hand-coded as classes derived from KDialogBase because we generally find it easier and more maintainable, but there's no law against using Qt Designer. Doesn't matter much either whether you stick it in an existing file like dialogs.cpp or in a new file. Also, don't be disappointed if you come up with a first draft and find that everyone hates it and you have to completely rework it -- these things seldom come out right first time. I do think a dialog like this is a necessary thing though and I'd be grateful if you did find the time and energy to have a shot at it. Chris |
From: Seb J. <se...@hy...> - 2004-03-30 21:57:03
|
On Mon, 2004-03-29 at 19:40, Chris Cannam wrote: > On Monday 29 Mar 2004 11:17 am, Seb James wrote: > > On Mon, 2004-03-29 at 09:25, Chris Cannam wrote: > > > Actually that's the sort of stand-alone dialog anyone could do -- > > > wouldn't take much knowledge of RG internals. Any takers? > > > > I'll do it. Will need to get CVS RG and you'll need to point me at > > the right source file and a similar dialog that I can crib from. > > Well, let's see. The dialog would probably want to be invoked from > RosegardenGUIApp::slotFileNew() in gui/rosegardengui.cpp, in the > makeNew branch that currently just creates a new document. > > I imagine it would pop up the dialog before doing that, so as to > abandon in time if the user hit cancel, and then based on the result > of the dialog it would add a few segments to the composition in the > document, fill them with rests (with Segment::fillWithRests), insert > some clef and key events, set up the composition's tempo and time > signatures (using the Composition API) etc. Where is the Composition API coded? > As for the dialog itself, I'm not sure that there is a great example > of a similar one already. There are a few dialogs in gui/dialogs. > {h,cpp}, and some of those (e.g. quantization dialog, although that's > largely defined in a separate frame widget in widgets.{h,cpp}) have a > similar idea of offering a broad selection of possibilities with > options for each -- or the event filter dialog (gui/eventfilter.h) > might be helpful. Other apps like KWord have a File->New dialog that > does something similar too, although I'm not particularly keen on the > one in KWord. Most of our dialogs are hand-coded as classes derived > from KDialogBase because we generally find it easier and more > maintainable, but there's no law against using Qt Designer. Doesn't > matter much either whether you stick it in an existing file like > dialogs.cpp or in a new file. These should be enough. I'll have a look at a really simple kde program too, to get started with dialogs. > Also, don't be disappointed if you come up with a first draft and find > that everyone hates it and you have to completely rework it -- these > things seldom come out right first time. I do think a dialog like > this is a necessary thing though and I'd be grateful if you did find > the time and energy to have a shot at it. Heh, I'll be pleased to come up with something that works at all! Anyway. I've got cvs version compiled and installed, but curiously not making any noises. However, I shall save that problem for the morning. Looking forward to getting my teeth into this. Seb |
From: Silvan <dmm...@us...> - 2004-03-31 00:13:55
|
On Monday 29 March 2004 01:40 pm, Chris Cannam wrote: > one in KWord. Most of our dialogs are hand-coded as classes derived > from KDialogBase because we generally find it easier and more > maintainable, but there's no law against using Qt Designer. Doesn't After the 375,031st time I had to manually diddle that stupid event filter dialog, I began to regret the decision to hand code it. I started in Designer, decided I didn't like the way it had to be compiled, or the weird QTisms it imposed, so I manually edited all of that away. It's cleaner, more obvious, but I'm not sure if it's more maintainable this way or not. Reminds me, I need to tweak it again. The spacing of some of the buttons is coming out wrong in Keramik again. Dammit. > Also, don't be disappointed if you come up with a first draft and find > that everyone hates it and you have to completely rework it -- these > things seldom come out right first time. I do think a dialog like Toward that end, I'd really suggest at least prototyping it in Designer. Nobody will like his first draft, and he'll have to rework it two or three times until all the whining about word choices and button spacing ceases. He might as well come up with something cosmetically appealing before he bothers to hook everything up and make it work. IMHO, of course, as the most useless person here. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ |
From: Chris C. <ca...@al...> - 2004-03-31 07:33:12
|
On Wednesday 31 Mar 2004 1:13 am, Silvan wrote: > Reminds me, I need to tweak it again. The spacing of some of the > buttons is coming out wrong in Keramik again. Dammit. I think (without looking too closely at the code) that the problem is you're trying to align the elements in grids in multiple separate frames, and you can't really do that without using arbitrary spacings, which is where you start to fall apart when the theme changes. You could probably do a little better by assigning minimum dimensions on the spacers based on the dimensions of the widgets occupying the same row or column in the other frames, rather than hardcoding them. I'm not sure whether you'd get the same problem if using Designer or not. Designer does like to use absolute sizes and positions for things, which can be equally troublesome in other ways. Chris |
From: Dan O. <de...@os...> - 2004-03-31 00:53:14
|
> Nobody will like his first draft, and he'll have to rework it two or three > times until all the whining about word choices and button spacing ceases. > He might as well come up with something cosmetically appealing before he > bothers to hook everything up and make it work. IMHO, of course, as the > most useless person here. Yeah.. at least for prototyping Qt Designer is the way to go I think... you don't usually end up keeping it how you first attempt it and its unnecessary work revising it by hand, imho. QUESTION: There is a background on the multi-page notation editor screenshot on the website.. how do you get that background? I just get a blank one... Dan |
From: Chris C. <ca...@al...> - 2004-03-31 07:42:53
|
On Wednesday 31 Mar 2004 1:53 am, Dan Ostrowski wrote: > There is a background on the multi-page notation editor screenshot > on the website.. how do you get that background? I just get a blank > one... Settings -> Configure Rosegarden -> General page -> check "Use textured backgrounds on canvas areas". Save settings, hope you don't get hit by the settings amnesia bug, exit and restart. You can't get the textured background in notation without also having one in the segment and matrix editors. The option's off by default because it slows things down, but maybe it should have been on by default just for flashiness. If you want to customise the pixmaps, they're in gui/pixmaps/misc (installed in $KDEDIR/share/apps/rosegarden/pixmaps/misc) and are called bg-paper-white.xpm (for notation and matrix), bg-paper-grey.xpm (for segment canvas) and bg-desktop.xpm (the wood effect in the multi-page notation background). Also bg-paper-black, which is currently unused. Chris |
From: Silvan <dmm...@us...> - 2004-04-01 02:44:36
|
On Wednesday 31 March 2004 02:57 am, Chris Cannam wrote: > The option's off by default because it slows things down, but maybe it > should have been on by default just for flashiness. Probably should be on by default, so people know it's there. Of course, if they know it's there, they still won't necessarily be immediately able to figure out how to turn it off. Someone using a POS like this screaming 233 MHz box might think RG is just bog slow. -- Michael McIntyre ---- Silvan <dmm...@us...> Linux fanatic, and certified Geek; registered Linux user #243621 http://www.geocities.com/Paris/Rue/5407/ |
From: Seb J. <se...@hy...> - 2004-03-31 08:07:04
|
On Wed, 2004-03-31 at 01:53, Dan Ostrowski wrote: > > Nobody will like his first draft, and he'll have to rework it two or three > > times until all the whining about word choices and button spacing ceases. > > He might as well come up with something cosmetically appealing before he > > bothers to hook everything up and make it work. IMHO, of course, as the > > most useless person here. > > Yeah.. at least for prototyping Qt Designer is the way to go I think... you > don't usually end up keeping it how you first attempt it and its unnecessary > work revising it by hand, imho. Ok, this is what I shall do. I'll lay out the dialog using qt designer and then I'll post the results on the list. This will at least give me the chance to get a dummy dialog up which has hooks to dummy events (like stdout messages). |
From: Chris C. <ca...@al...> - 2004-03-31 08:37:53
|
On Tuesday 30 Mar 2004 10:56 pm, Seb James wrote: > Where is the Composition API coded? base/Composition.h Quick primer: in gui/rosegardenguidoc.h you have your basic Document class, RosegardenGUIDoc. It's the GUI's main container for everything, and in particular it contains a Composition (the container for all notes and events) and a Studio (container for device information, not interested in that at the moment here). The Composition contains all the Segments (corresponding to the blocks you draw on the main canvas), which themselves contain Events for notes, rests, clefs, MIDI controllers etc -- see base/Composition.h, Segment.h, Event.h. Composition also directly contains tempo changes and time signatures -- they are not stored in Segments: you can't have different time sigs in different segments. Events can have arbitrary type and arbitrary properties, and there are various helper classes in base/NotationTypes.h which can construct and examine the common notation types (to avoid having to get the type and property names exactly right yourself). Note that everything in base/ is in the Rosegarden namespace, but classes in gui/ are not. Example: Given an empty Composition (such as that returned by document->getComposition() on a new document), set a 3/4 time sig, add a single empty segment of 30 bars duration, and put a clef in it: composition->addTimeSignature(0, Rosegarden::TimeSignature(3,4)); Rosegarden::Segment *s = new Rosegarden::Segment(); composition->addSegment(s); s->fillWithRests(composition->getBarEnd(30)); Rosegarden::Clef clef(Rosegarden::Clef::Bass); s->insert(clef.getAsEvent(0)); Note that the time signature will replace any that was previously at time zero, and the segment has to be inserted into a composition with the correct time sig before fillWithRests can work correctly. Those last two lines are equivalent to Rosegarden::Event *e = new Rosegarden::Event (Rosegarden::Clef::EventType, 0); e->set<String>(Rosegarden::Clef::ClefPropertyName, Rosegarden::Clef::Bass); s->insert(e); or even (for illustrative purposes only -- never do this) Rosegarden::Event *e = new Rosegarden::Event("clefchange", 0); e->set<String>("clef", "bass"); s->insert(e); Using Clef::getAsEvent is preferred as it's less error-prone and more likely to continue to do the right thing if the clef event gains any further properties. Not that you'll need to know any of this for a while yet. Chris |
From: William <ros...@li...> - 2004-03-31 20:12:46
|
Chris Cannam <ca...@al...> wrote: >[..] >Example: Given an empty Composition (such as that returned by >document->getComposition() on a new document), set a 3/4 time sig, >add a single empty segment of 30 bars duration, and put a clef in it: > > composition->addTimeSignature(0, Rosegarden::TimeSignature(3,4)); > Rosegarden::Segment *s = new Rosegarden::Segment(); > composition->addSegment(s); > s->fillWithRests(composition->getBarEnd(30)); > Rosegarden::Clef clef(Rosegarden::Clef::Bass); > s->insert(clef.getAsEvent(0)); > >Note that the time signature will replace any that was previously at >time zero, and the segment has to be inserted into a composition with >the correct time sig before fillWithRests can work correctly. Those >last two lines are equivalent to > > Rosegarden::Event *e = new Rosegarden::Event > (Rosegarden::Clef::EventType, 0); > e->set<String>(Rosegarden::Clef::ClefPropertyName, > Rosegarden::Clef::Bass); > s->insert(e); > >or even (for illustrative purposes only -- never do this) > > Rosegarden::Event *e = new Rosegarden::Event("clefchange", 0); > e->set<String>("clef", "bass"); > s->insert(e); > >Using Clef::getAsEvent is preferred as it's less error-prone and more >likely to continue to do the right thing if the clef event gains any >further properties. Out of curiosity as I'm working on a future patch, what would be the calls to: (a) return the total number of tracks T in the composition, (b) return the total number of segments S in the composition, (c) force track number t to be muted, (d) move the playback cursor to the start of bar b in segment s on track t (e) play track t from start of bar b to start of bar c and stop there? William |
From: William <ros...@li...> - 2004-04-02 16:32:19
|
Re: my previous question, perhaps I should have asked first: May I write a patch which does both repeats and ossia (alternatives)? If it's ok, please could one of you kindly start me off by answering: What would be the calls to: (a) return the total number of tracks T in the composition, (b) return the total number of segments S in the composition, (c) force track number t to be muted, (d) move the playback cursor to the start of bar b in segment s on track t (e) play track t from start of bar b to start of bar c and stop there? (f) draw a coloured (solidly-filled) rectangle in the main window of the track editor in canvas coordinates? William |
From: Chris C. <ca...@al...> - 2004-04-02 18:38:12
|
On Friday 02 Apr 2004 5:33 pm, William wrote: > Re: my previous question, perhaps I should have asked first: May I > write a patch which does both repeats and ossia (alternatives)? If > it's ok, please could one of you kindly start me off by answering: Gosh. Well, I can answer your questions approximately, but be warned they're not necessarily at all simple. Repeats are actually on my list for next week, though exactly what fraction of your requirements are also on my practical to-do list I'm not sure. > (a) return the total number of tracks T in the composition, composition->getTracks().size() > (b) return the total number of segments S in the composition, composition->getNbSegments() > (c) force track number t to be muted, Now here we get a bit complicated. First, there's not just a track number t -- there's track internal id t or track position t. You probably want track position t, so you want Track *track = composition->getTrackByPosition(t); if (track) track->setMuted(true); The complication is that this almost certainly won't update the GUI -- there's likely some complicated sequence of signals that I can't currently recall that updates the mute statuses. > (d) move the playback cursor to the start of bar b in segment s > on track t Bar numbers are global and so is the playback cursor, so document->setPointerPosition(composition->getBarStart(b)); > (e) play track t from start of bar b to start of bar c > and stop there? Complicated, you'd have to do a separate solo action to prevent the other tracks playing and there's no way to preschedule the stop at the sequencer side so you'd have to monitor the current pointer position in the document or somewhere (RosegardenGUIApp::slotUpdatePlaybackPosition?) and stop when you got there... or something. > (f) draw a coloured (solidly-filled) rectangle in > the main window of the track editor in canvas coordinates? Create a QCanvasRectangle on the segment canvas (gui/ segmentcanvas.cpp) -- but that's just a graphical object (like the selection rubber-band outline created at line 932), it's not actually connected to any particular object in the application unless you have quite a bit more structure associated with it, like the SegmentItem objects which are derived from QCanvasRectangle but have a lot of their own logic too. I have to say, I think this all sounds rather ambitious! Chris |
From: Seb J. <se...@hy...> - 2004-03-31 21:13:20
|
On Wed, 2004-03-31 at 09:52, Chris Cannam wrote: > The Composition contains all the Segments (corresponding to the blocks > you draw on the main canvas), which themselves contain Events for > notes, rests, clefs, MIDI controllers etc -- see base/Composition.h, > Segment.h, Event.h. Composition also directly contains tempo changes > and time signatures -- they are not stored in Segments: you can't > have different time sigs in different segments. Ok. This means then that a segment is just a number of beats and has nothing to do with bars, right? If I have a segment of 4 4/4 bars: 1 2 3 4|1 2 3 4|1 2 3 4|1 2 3 4 And I swap it into 5/4 after the first bar: 1 2 3 4|1 2 3 4 5|1 2 3 4 5|1 2 I now have half a bar in this segment, and the first bar of my next segment will contain the other 3 beats. > Note that everything in base/ is in the Rosegarden namespace, but > classes in gui/ are not. It's a while since I did any c++ programming. All the Rosegarden functions and so on are part of the Rosegarden namespace are they? > Example: Given an empty Composition (such as that returned by > document->getComposition() on a new document), set a 3/4 time sig, > add a single empty segment of 30 bars duration, and put a clef in it: > > composition->addTimeSignature(0, Rosegarden::TimeSignature(3,4)); > Rosegarden::Segment *s = new Rosegarden::Segment(); > composition->addSegment(s); At this point the segment has indeterminate length, right? > s->fillWithRests(composition->getBarEnd(30)); And this step defines the length of the segment? > Rosegarden::Clef clef(Rosegarden::Clef::Bass); > s->insert(clef.getAsEvent(0)); This is exactly what I'll want to do, apart from the key signature. What will the code be to insert a particular key sig at the start of the segment? > Not that you'll need to know any of this for a while yet. But necessary to know what I'm putting a dialog together to do, I think. Thanks for the info. Now. The dialog itself. In Rosegarden, in the notation editor, there are a number of dialogs that come up for key change, clef change. I need to bring the following elements together into the "new composition" dialog: Clef dialog: Box entitled "Clef" with chooser arrows for clef. (perhaps) Tempo dialog: The box entitled "Tempo" Time signature dialog: Box entitled "Time Signature" Key change: Box called "Key signature" So it would be nice to be able to take those (presumably) custom widgets and have them available in Qt designer so I can shuffle them about. Also, the dialog will want to give the choice of "number of bars to create" or perhaps "number of bars per segment" and "number of segments" Will it also be relevant to ask the user how many individual instruments to create the composition with? Seb |
From: Chris C. <ca...@al...> - 2004-04-01 14:57:06
|
On Wednesday 31 Mar 2004 10:13 pm, Seb James wrote: > Ok. This means then that a segment is just a number of beats and > has nothing to do with bars, right? In the sense that the duration of the segment doesn't have to be a whole number of bars, yes. I'm not sure you would describe it in terms of beats either though. It's just a series of events each with its own particular start time and duration, ordered by start time. > If I have a segment of 4 4/4 bars: > > 1 2 3 4|1 2 3 4|1 2 3 4|1 2 3 4 > > And I swap it into 5/4 after the first bar: > > 1 2 3 4|1 2 3 4 5|1 2 3 4 5|1 2 > > I now have half a bar in this segment Right, the events will have exactly the same timings as they did before you added the time signature, it's just the logical division imposed when rendering in notation or whatever that's changed. > > composition->addSegment(s); > > At this point the segment has indeterminate length, right? It actually has zero length. > > s->fillWithRests(composition->getBarEnd(30)); > > And this step defines the length of the segment? Yes. The length of the segment (we usually use "duration" to refer to length in time, to distinguish it from a spatial measurement when drawing things) is defined entirely by what it contains, it doesn't remember its own duration otherwise. (The exception is that a segment can optionally have an end marker which makes it effectively end before all its events have ended -- but disregard that for now.) So that fillWithRests call just inserts 30 bars worth of rests, thus extending the segment to 30 bars long. > > Rosegarden::Clef clef(Rosegarden::Clef::Bass); > > s->insert(clef.getAsEvent(0)); > > This is exactly what I'll want to do, apart from the key signature. > What will the code be to insert a particular key sig at the start > of the segment? Check out the Key class, alongside Clef in base/NotationTypes.h. You can construct them by name, or more usually by sharp/flats count etc. Rosegarden::Key key("C# major"); // or... Rosegarden::Key key(7, true, false); // seven sharps major key s->insert(key.getAsEvent(0)); > I need to bring the following elements together into the "new > composition" dialog: > > Clef dialog: Box entitled "Clef" with chooser arrows for clef. > (perhaps) Tempo dialog: The box entitled "Tempo" > Time signature dialog: Box entitled "Time Signature" > Key change: Box called "Key signature" > > So it would be nice to be able to take those (presumably) custom > widgets and have them available in Qt designer so I can shuffle > them about. They're not quite as custom-widgets as they might be. They are mostly split into two parts: a bit of code in NotePixmapFactory (the makeXXXDisplayPixmap methods) that draws a key, time sig, clef etc onto a pixmap, and then the rest of the widgetry is just coded straight into the dialog class at the moment. They could fairly straightforwardly be pulled out into separate widgets, but at the moment they're not. It does rather depend on the design though, in a chicken-and-egg sort of way. It's conceivable (depending on space constraints) that the dialog might want to only show the pixmap with the key signature on it, and you click on that to pop up the existing key signature dialog to change it, for instance. That aside, I don't actually know how you get custom widget code into Designer. Anyone? > Will it also be relevant to ask the user how many individual > instruments to create the composition with? I think one might be getting into deep water there -- people will want an equivalent of the Sibelius/Finale setup dialogs where you choose your instruments from a predefined set of categories. Might be nice, but not so straightforward to do. Chris |
From: Richard B. <ric...@fe...> - 2004-04-01 15:03:59
|
On Thursday 01 April 2004 16:11, Chris Cannam wrote: > That aside, I don't actually know how you get custom widget code into > Designer. Anyone? Yes, I've done that a couple of times. A long time ago. It's doable. That I know. R |
From: Guillaume L. <gla...@te...> - 2004-04-01 15:25:22
|
> > That aside, I don't actually know how you get custom widget > code into > > Designer. Anyone? > > Yes, I've done that a couple of times. A long time ago. > It's doable. That I know. http://doc.trolltech.com/3.3/designer-manual-7.html -- Guillaume http://telegraph-road.org |