From: Guillaume L. <gla...@te...> - 2002-03-27 22:42:05
|
It's here, except that at the moment it inserts 5 tracks as I haven't made a dialog to ask how many tracks the user wants to add yet. Now I'd like to understand why all of a sudden the selector tool is selected at startup. -- Guillaume. http://www.telegraph-road.org |
From: Guillaume L. <gla...@te...> - 2002-03-27 22:50:03
|
On Wednesday 27 March 2002 23:41, Guillaume Laurent wrote: > Now I'd like to understand why all of a sudden the selector tool is > selected at startup. Found that. I changed RosegardenGUIView::slotSelectTrackSegments() so that it won't change the tool if no segments are on the selected track. -- Guillaume. http://www.telegraph-road.org |
From: Richard B. <bo...@bo...> - 2002-03-28 07:48:26
|
Guillaume Laurent wrote: > It's here, except that at the moment it inserts 5 tracks as I haven't made a > dialog to ask how many tracks the user wants to add yet. And it wasn't giving the Tracks any "position" either so that the track selection mechanism was breaking again. Fixed. Also, the position pointer stops in mid air above the newly added tracks. Please, how do we sort the position pointer vertical length out? It's really really annoying and I've tried everything I can think of to make it the full height of the canvas. I think the problem is the Segment Canvas isn't always the full height of the SegmentCanvas widget - if you see what I mean? Am I the only person this affects? R |
From: Chris C. <ca...@al...> - 2002-03-28 09:30:45
|
Richard Bown wrote: > Guillaume Laurent wrote: > >>It's here, except that at the moment it inserts 5 tracks as I haven't made a >>dialog to ask how many tracks the user wants to add yet. > > And it wasn't giving the Tracks any "position" either so that the > track selection mechanism was breaking again. And Undo doesn't appear to work. Chris |
From: Guillaume L. <gla...@te...> - 2002-03-28 09:43:47
|
On Thursday 28 March 2002 10:29, Chris Cannam wrote: > And Undo doesn't appear to work. Yeah, I haven't worried about that yet. --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Richard B. <bo...@bo...> - 2002-03-28 10:14:25
|
Guillaume Laurent wrote: > On Thursday 28 March 2002 10:29, Chris Cannam wrote: > > > And Undo doesn't appear to work. > > Yeah, I haven't worried about that yet. You see, I tried this excuse but it just doesn't wash y'know? Next trick is to say you can't work out how the undo thing works and get Chris to do it all for you anyway. R |
From: Chris C. <ca...@al...> - 2002-03-28 09:38:07
|
Richard Bown wrote: > I've tried everything I can think of to make > it the full height of the canvas. In this case, I don't see any code that attempts to resize the pointer when the canvas is resized, so unless I'm just missing it, it makes sense that the pointer shouldn't reach the bottom. But: > Canvas isn't always the full height of the SegmentCanvas widget - if > you see what I mean? Am I the only person this affects? In general I think this is true, I think there's simply no way the pointer line _can_ reach the bottom of the view if there aren't enough tracks to make the canvas fill its full height. I find this irritating too, not because I particularly care about the position pointer but because the area between the bottom of the canvas and the bottom of the widget gets filled up with garbage quite often (probably the X server optimizing something too well, I suppose). Making the canvas taller would probably fix this; I used to get garbage in the bottom of the notation view as well until we made the canvas height always be taller than the view. Chris |
From: Richard B. <bo...@bo...> - 2002-03-28 09:40:27
|
> And Undo doesn't appear to work. For Whom The Bell Tolls. |
From: Chris C. <ca...@al...> - 2002-03-28 10:30:34
|
Richard Bown wrote: >>And Undo doesn't appear to work. > > For Whom The Bell Tolls. Maybe you'd like to make Add Tracks into a command at the same time as you do Edit Tempo, then? (Except that Edit Tempo is much easier, as it should be pretty much cut-and-paste from the time signature change command.) Sorry, I feel the need to rant about this. It's a big waste of time to get all the way through implementing an editing feature without even making it a Command. That's because you're only going to have to do it later, and it's much easier to do it from the outset because it means you don't end up having to move code around and add signals and things when you realise (for example) you can't execute commands in the context of your dialog because it doesn't have a document pointer. (For editing operations that use a dialog in the notation view, I've usually made the dialog return with an OK value and the notation view itself execute the command based on that.) And the value of having an undo stack is hugely reduced if not every command can be undone, because as soon as you execute an un-undoable command you've lost any guarantee about the integrity of earlier commands. This is really something worth trying hard to get into your heads: I've had trouble with it too, but really having to stop and think about what your command is actually doing is quite a good mental exercise anyway. And you've got to get the hang of this Command thing some time. Oh and Rich, just got your other email -- and no, I have absolutely no intention of implementing the Commands for either of the above. I'm through with cheapening myself for you, y'hear? I'm through with it. From now on I'm gonna be my own girl. Chris |
From: Richard B. <bo...@bo...> - 2002-03-28 10:38:24
|
Chris Cannam wrote: > Making the canvas taller would probably fix this Actually no. Well yes, this is what I got stuck/bored with. You can resize the canvas - just make it 1000 tall or something but then the canvas always scrolls vertically but the track buttons don't. Then you make the track buttons 1000 tall as well and for some reason you're back to where you started. I suspect we need a GUI expert-type to have a look at it.. R |
From: Guillaume L. <gla...@te...> - 2002-03-28 10:44:58
|
On Thursday 28 March 2002 11:27, Chris Cannam wrote: > It's a big waste > of time to get all the way through implementing an editing > feature without even making it a Command. Yes yes yes you're right. WTF was I thinking. --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-03-28 12:10:58
|
Guillaume Laurent wrote: > On Thursday 28 March 2002 11:27, Chris Cannam wrote: > >>It's a big waste >>of time to get all the way through implementing an editing >>feature without even making it a Command. Of course refresh could be interesting for the add tracks command (and others like changing the order of the tracks). For the segment editing commands, we generally don't do any refresh when the commands are created but only refresh when we get the commandExecuted signal back, which of course means the refresh works for undo and redo without any extra work. Chris |
From: Guillaume L. <gla...@te...> - 2002-03-28 10:46:52
|
On Thursday 28 March 2002 11:35, Richard Bown wrote: > Chris Cannam wrote: > > Making the canvas taller would probably fix this > > Actually no. I'd rather go for maintaining the canvas at the right size, and preventi= ng=20 from resizing the main window to a larger size. That should be possible. --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Richard B. <bo...@bo...> - 2002-03-28 10:54:04
|
Guillaume Laurent wrote: > I'd rather go for maintaining the canvas at the right size, and preventing > from resizing the main window to a larger size. That should be possible. So you can't maximise? What's the "right" size? Eh? R |
From: Guillaume L. <gla...@te...> - 2002-03-28 11:06:36
|
On Thursday 28 March 2002 11:51, Richard Bown wrote: > > So you can't maximise? Good point. I don't know what should happen in that case. > What's the "right" size? Eh? The size (actually the height) needed to show all the tracks. --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Richard B. <bo...@bo...> - 2002-03-28 11:48:32
|
Chris Cannam wrote: > Maybe you'd like to make Add Tracks into a command at the same > time as you do Edit Tempo, then? I've done Edit Tempo at least. Although the undo/redo doesn't appear to be calling my RosegardenTempoDialog::slotCommandExecuted so I can't update the GUI. Any idea why? R |
From: Chris C. <ca...@al...> - 2002-03-28 12:09:52
|
Richard Bown wrote: > I've done Edit Tempo at least. Although the undo/redo doesn't appear > to be calling my RosegardenTempoDialog::slotCommandExecuted > so I can't update the GUI. Any idea why? ??? Why should your _tempo_ dialog care when the tempo command is executed? Even if it still exists (briefly) after you hit OK, it won't be around when you undo or redo the command later. At the moment the only thing that looks like it needs to notice when a tempo command happens is the transport, so you could either catch the signal in there, or catch it in the main GUI and request a change in the transport's state. As I said in a previous email, I'd be inclined not to create the command from the tempo dialog either -- it seems neater somehow if the tempo dialog sticks to editing tempo values and the code that invoked it worries about what to do with them. Wouldn't hold for every dialog though, and it might not hold for this one. Chris |
From: Richard B. <bo...@bo...> - 2002-03-28 12:51:57
|
Chris Cannam wrote: > Why should your _tempo_ dialog care when the tempo command is > executed? Even if it still exists (briefly) after you hit OK, > it won't be around when you undo or redo the command later. See what happens when you shout at me? I get more things wrong. > At the moment the only thing that looks like it needs to notice > when a tempo command happens is the transport, so you could > either catch the signal in there, or catch it in the main GUI Actually, it the same place. The transport requests the tempo change dialog with a signal (because the transport doesn't have a document pointer, yet). R |
From: Guillaume L. <gla...@te...> - 2002-03-28 12:59:42
|
On Thursday 28 March 2002 13:09, Chris Cannam wrote: > > On Thursday 28 March 2002 11:27, Chris Cannam wrote: > >>It's a big waste > >>of time to get all the way through implementing an editing > >>feature without even making it a Command. > > Of course refresh could be interesting for the add tracks command > (and others like changing the order of the tracks). Woah there. I'm lost. When did "refresh" got into the picture ? Or by "interesting" you mean "will be tricky to implement" ? --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-03-28 13:26:47
|
Guillaume Laurent wrote: > When did "refresh" got into the picture ? When you add some tracks, you want those tracks to appear on the GUI. That's easy if you're adding them in response to a user's request made from that same GUI, but not so easy if you're adding them in response to a redo on the command stack. Or removing them in response to an undo, of course. For segment editing operations, we never update the segment canvas simply in response to the user's requests -- we always make a command, stick it on the history, and then refresh the canvas when we get back the commandExecuted signal. That way we know the refresh will work the same regardless of where the command originated. This sort of thing is why it's a good idea to start writing your editing code with commands in mind from the outset. Chris |
From: Guillaume L. <gla...@te...> - 2002-03-28 15:46:21
|
On Thursday 28 March 2002 14:25, Chris Cannam wrote: > > When you add some tracks, you want those tracks to appear on > the GUI. [...] > > For segment editing operations, we never update the segment > canvas simply in response to the user's requests But it's not the segment canvas which needs to be updated here, it's the=20 TrackButtons, it's only a matter of show()ing the newly created widgets,=20 which is already taken care of. --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-03-28 17:18:16
|
Guillaume Laurent wrote: > it's only a matter of show()ing the newly created widgets, > which is already taken care of. Oh, are you going to create and destroy the widgets themselves from the command object? I hadn't thought of that. I suppose it'd work, provided you were confident there'd only be one view to update and it'd be guaranteed to exist. Perhaps a bit of a nasty interdependency between the two layers (command and GUI) though. One potentially nice thing about our command objects is that so far none of them has any particular knowledge of the GUI, which means they might possibly be used from a batch or scripted type of process as well. That may not prove as interesting as all that, though. Chris |
From: Guillaume L. <gla...@te...> - 2002-03-28 17:45:55
|
On Thursday 28 March 2002 18:16, Chris Cannam wrote: > > Oh, are you going to create and destroy the widgets themselves > from the command object? I hadn't thought of that. No, I'd signal the TrackButtons widget that it needs to add some more but= tons. > I suppose > it'd work, provided you were confident there'd only be one view > to update and it'd be guaranteed to exist. Er, there still can be only one track editor, right ? > nasty interdependency between the two layers (command and GUI) Hence the signalling. > One potentially nice thing about our command objects is that so > far none of them has any particular knowledge of the GUI, which > means they might possibly be used from a batch or scripted type > of process as well. That may not prove as interesting as all > that, though. It's been a while since we haven't added anything to the DCOP iface, but=20 actually I have more faith in Petal-style scripting to do really interes= ting=20 stuff. --=20 =09=09=09=09Guillaume =09=09=09=09http://www.telegraph-road.org |
From: Chris C. <ca...@al...> - 2002-03-28 18:46:58
|
Guillaume Laurent wrote: > On Thursday 28 March 2002 18:16, Chris Cannam wrote: > >>Oh, are you going to create and destroy the widgets themselves >>from the command object? I hadn't thought of that. > > No, I'd signal the TrackButtons widget that it needs to add some more buttons. Signal it from where? If you mean from the command, then it'd be more in line with existing uses of commands if you dealt with it from the existing commandExecuted signal. > Er, there still can be only one track editor, right ? Yes. I can't think of any other way of editing tracks offhand, but in general we've got to be a bit careful that things in the main view don't affect other views in unexpected ways. An example might be if we made the notation or matrix view show which tracks the segments being edited were on -- adding tracks at the bottom of the track editor wouldn't make those incorrect, but reordering tracks or adding them in the middle could. That's a pretty minor thing though, and I can't think of anything more serious. >>One potentially nice thing about our command objects is that >>[...] they might possibly be used from a batch or scripted type >>of process > > [...] > actually I have more faith in Petal-style scripting to do really interesting > stuff. I didn't quite follow that. More faith than in what? DCOP? Scripting things using the C++ API (via .so plugins or whatever)? Chris |
From: Guillaume L. <gla...@te...> - 2002-03-28 20:47:27
|
On Thursday 28 March 2002 19:45, Chris Cannam wrote: > > No, I'd signal the TrackButtons widget that it needs to add some more > > buttons. > > Signal it from where? If you mean from the command, then it'd > be more in line with existing uses of commands if you dealt with it > from the existing commandExecuted signal. OK, I'll see how things fit together. > > actually I have more faith in Petal-style scripting to do really > > interesting stuff. > > I didn't quite follow that. More faith than in what? DCOP? > Scripting things using the C++ API (via .so plugins or whatever)? Than in DCOP. -- Guillaume. http://www.telegraph-road.org |