From: <vl...@eh...> - 2005-01-30 20:43:42
|
On Sun, 30 Jan 2005 20:36:36 GMT, William <ros...@or...> wrote: > Vlada wrote: >> >> This is what i've got after trying to compile todays cvs! >> >> In file included from dialogs.h:35, >> from rosegardengui.h:34, >> from rosegardenguidoc.h:36, >> from audiomanagerdialog.h:28, >> from audiomanagerdialog.cpp:44: >> notepixmapfactory.h:296: error: parse error before `int' >> audiomanagerdialog.cpp: In member function `void >> Rosegarden::AudioManagerDialog::slotPopulateFileList()': >> audiomanagerdialog.cpp:442: warning: comparison between signed and >> unsigned >> integer expressions >> audiomanagerdialog.cpp: In member function `void >> Rosegarden::AudioManagerDialog::slotRename()': >> audiomanagerdialog.cpp:899: warning: `getText' is deprecated (declared >> at >> /usr/local/kde/include/klineeditdlg.h:98) >> audiomanagerdialog.cpp: In member function `bool >> Rosegarden::AudioManagerDialog::addFile(const KURL&)': >> audiomanagerdialog.cpp:1095: warning: `download' is deprecated >> (declared at >> /usr/local/kde/include/kio/netaccess.h:115) >> make[3]: *** [audiomanagerdialog.o] Error 1 >> make[3]: Leaving directory `/home/vlada/rosegarden/gui' >> make[2]: *** [all-recursive] Error 1 >> make[2]: Leaving directory `/home/vlada/rosegarden/gui' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/home/vlada/rosegarden' >> make: *** [all] Error 2 >> bash-2.05b# > > CVS compiles ok for me right now. > I notice you are using bash 2.05b which is more than 3 years old. > Therefore, I wonder which versions of KDE, gcc, autoconf, and automake > you have? > > William gcc version 3.3.2 20031218 Qt: 3.3.3 KDE: 3.3.0 automake (GNU automake) 1.4 Autoconf version 2.13 Thanx for the fast reply! Vlada |
From: <vl...@eh...> - 2005-01-30 21:13:50
|
On Sun, 30 Jan 2005 20:56:08 GMT, William <ros...@or...> wrote: > Vlada wrote: >> >> On Sun, 30 Jan 2005 20:36:36 GMT, William wrote: >> >>> CVS compiles ok for me right now. >>> I notice you are using bash 2.05b which is more than 3 years old. >>> Therefore, I wonder which versions of KDE, gcc, autoconf, and automake >>> you have? >> >>> >>> William >> >> gcc version 3.3.2 20031218 > > Ok, that's not too old although the current gcc is 3.4.3 (be careful > if you do ever upgrade gcc because you will need to get kde/qt packages > that were compiled with the identical version of gcc) > >> Qt: 3.3.3 > > That's ok. > >> KDE: 3.3.0 > > That's ok (latest version is kde-3.3.3). > >> automake (GNU automake) 1.4 > > I don't know if that's the cause of your trouble but 1.4 is very old. > There is automake-1.9.4 that's my gentoo!!! just realised that I have automake and autoconf much more recent!!! And some idiotic oython script for their wrapping... Now it is ok! I think so... I hope there is no need to rebuild from clean?! >> Autoconf version 2.13 > > That's old too. > I think you should upgrade your Linux distribution to a modern version. > Check you also have liblo-0.15, dssi-0.9, and > jack-audio-connection-kit-0.99.0. All up-to-date! Vlada >> Thanx for the fast reply! > > Blame my ISP for that :-) > > William BTW, I've read many of yours feature requests! Great work... Vlada |
From: William <ros...@or...> - 2005-01-30 22:10:38
|
Vlada wrote: > > On Sun, 30 Jan 2005 20:56:08 GMT, William wrote: > >> I don't know if that's the cause of your trouble but 1.4 is very old. >> There is automake-1.9.4 > > that's my gentoo!!! just realised that I have automake and autoconf much > more recent!!! And some idiotic oython script for their wrapping... > > Now it is ok! I think so... > I hope there is no need to rebuild from clean?! It's usually a good idea to build from clean if you are upgrading system tools like automake and autoconf. >>> Autoconf version 2.13 >> >> That's old too. >> I think you should upgrade your Linux distribution to a modern version. >> Check you also have liblo-0.15, dssi-0.9, and >> jack-audio-connection-kit-0.99.0. > > All up-to-date! Good. >>> Thanx for the fast reply! >> >> Blame my ISP for that :-) >> >> William > > BTW, I've read many of yours feature requests! > Great work... Yes, it would be indeed "great work" to implement them all :-) I hope you like the new "rests-outside-staves" -- useful for part-writing, etc. William |
From: <vl...@eh...> - 2005-01-30 23:13:25
|
Vlada wrote: > > On Sun, 30 Jan 2005 20:56:08 GMT, William wrote: > >> I don't know if that's the cause of your trouble but 1.4 is very old. >> There is automake-1.9.4 > > that's my gentoo!!! just realised that I have automake and autoconf much > more recent!!! And some idiotic oython script for their wrapping... > > Now it is ok! I think so... > I hope there is no need to rebuild from clean?! >It's usually a good idea to build from clean if you are upgrading system >tools >like automake and autoconf. >>> Autoconf version 2.13 >> >> That's old too. >> I think you should upgrade your Linux distribution to a modern version. >> Check you also have liblo-0.15, dssi-0.9, and >> jack-audio-connection-kit-0.99.0. > > All up-to-date! >Good. >>> Thanx for the fast reply! >> >> Blame my ISP for that >> >> William > > BTW, I've read many of yours feature requests! > Great work... >Yes, it would be indeed "great work" to implement them all >I hope you like the new "rests-outside-staves" -- useful for part-writing, >etc. >William Hmm, I\m still haveing this message: if g++ -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/local/kde/include -I/usr/qt/3/include -I/usr/X11R6/include -I../base -I../sound -fexceptions -I/usr/X11R6/include -I/usr/include/freetype2 -I/usr/local/include -I/usr/local/include -DQT_THREAD_SUPPORT -D_REENTRANT -DRGKDE3 -Wnon-virtual-dtor -Wno-long-long -Wundef-ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -g3 -fno-inline -Wformat-security-Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -fno-gcse -fexceptions -MT audiomanagerdialog.o -MD -MP -MF ".deps/audiomanagerdialog.Tpo" \ -c -o audiomanagerdialog.o `test -f 'audiomanagerdialog.cpp' || echo './'`audiomanagerdialog.cpp; \ then mv -f ".deps/audiomanagerdialog.Tpo" ".deps/audiomanagerdialog.Po"; \ else rm -f ".deps/audiomanagerdialog.Tpo"; exit 1; \ fi In file included from dialogs.h:35, from rosegardengui.h:34, from rosegardenguidoc.h:36, from audiomanagerdialog.h:28, from audiomanagerdialog.cpp:44: notepixmapfactory.h:296: error: parse error before `int' audiomanagerdialog.cpp: In member function `void Rosegarden::AudioManagerDialog::slotPopulateFileList()': audiomanagerdialog.cpp:442: warning: comparison between signed and unsigned integer expressions audiomanagerdialog.cpp: In member function `void Rosegarden::AudioManagerDialog::slotRename()': audiomanagerdialog.cpp:899: warning: `getText' is deprecated (declared at /usr/local/kde/include/klineeditdlg.h:98) audiomanagerdialog.cpp: In member function `bool Rosegarden::AudioManagerDialog::addFile(const KURL&)': audiomanagerdialog.cpp:1095: warning: `download' is deprecated (declared at /usr/local/kde/include/kio/netaccess.h:115) make[3]: *** [audiomanagerdialog.o] Error 1 make[3]: Leaving directory `/home/vlada/rosegarden/gui' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/vlada/rosegarden/gui' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/vlada/rosegarden' make: *** [all] Error 2 bash-2.05b# Vlada |
From: William <ros...@or...> - 2005-01-30 23:27:20
|
Vlada wrote: > > Hmm, I\m still haveing this message: Sorry, it's my fault. There's a comma missing in gui/notepixmapfactory.h due to something I committed earlier today. It's fixed in CVS now. Either wait for anon CVS to catch up or cut-and-paste the following patch: # cut and paste below here into: cat | sh -c "(cd rosegarden; patch -p2)" --- a/rosegarden/gui/notepixmapfactory.h 2005-01-30 23:22:22.000000000 +0000 +++ b/rosegarden/gui/notepixmapfactory.h 2005-01-30 23:18:44.000000000 +0000 @@ -292,7 +292,7 @@ void drawFlags(int flagCount, const NotePixmapParameters ¶ms, const QPoint &startPoint, const QPoint &endPoint); void drawStem(const NotePixmapParameters ¶ms, - const QPoint &startPoint, const QPoint &endPoint + const QPoint &startPoint, const QPoint &endPoint, int shortening); void makeRoomForBeams(const NotePixmapParameters ¶ms); |
From: <vl...@eh...> - 2005-01-30 23:19:02
|
> BTW, I've read many of yours feature requests! > Great work... >Yes, it would be indeed "great work" to implement them all Sorting the things out IS the good way... Know you understand! >I hope you like the new "rests-outside-staves" -- useful for part-writing, >etc. Actually, this is my first day with computer since last year! Will check... Is there a way of moveing notation symbols for more than one step at a time; that anoys me! (especially all those undos) Vlada >William |
From: William <ros...@or...> - 2005-01-30 23:39:25
|
Vlada wrote: > >> I hope you like the new "rests-outside-staves" -- useful for >> part-writing, etc. > > Actually, this is my first day with computer since last year! Will > check... Is there a way of moveing notation symbols for more than one > step at a time; that anoys me! (especially all those undos) I don't understand what you want to do. What do you mean "for more than one step at a time" ? William |
From: Vladimir S. <vl...@eh...> - 2005-02-04 14:38:48
|
On Sun, 30 Jan 2005 23:41:25 GMT, William <ros...@or...> wrote: > Vlada wrote: >> >>> I hope you like the new "rests-outside-staves" -- useful for >>> part-writing, etc. >> >> Actually, this is my first day with computer since last year! Will >> check... Is there a way of moveing notation symbols for more than one >> step at a time; that anoys me! (especially all those undos) > > I don't understand what you want to do. > What do you mean "for more than one step at a time" ? I ment of abililty of positioning rests ouside staves with one single operation. Mouse dragging for example... Anyway, something's changed now I successifuly compiled rg! After playing with this rests outside staves, here is the summary (my point of view): 1. It looks like all that fine positioning of whole and half rests is related with interval type. Half rest is "at the top" of third line of staff (opposite - whole rest is "hanging" on the fourth line). There is no way to have any of this type of rests to present some notes, let's say C2 positioned rest. That leads to having of performed operation with no visual effect. My suggestion: make this two type of rests to move to the next _posibile_ position. That way we'll have only 5 places in staff where this two rests types could be placed. Hope you got it! :) 2. There is a bug... Well, again I'll do it step by step: "Move" rest outside staff by fine position tool. Click on it (LMB) and drag as you want to perform sweep select. Rest's position will be restored to the original. Observe: There's no way to undo operation. I know my explanation can be confusing... Please ignore that :) Vlada P.S. Hope my ISP is now working good. Please check and report! Anyway, that's the reason for delay! > William > -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
From: William <ros...@or...> - 2005-02-04 18:18:24
|
Vladimir Savic wrote: > > After playing with this rests outside staves, here is the summary (my > point of view): > > 1. It looks like all that fine positioning of whole and half rests is > related with interval type. How is interval type relevant to fine-positioning of rests? > Half rest is "at the top" of third line of > staff (opposite - whole rest is "hanging" on the fourth line). There is > no way to have any of this type of rests to present some notes, let's say > C2 positioned rest. What does "rests to present some notes" mean? Can you give an example of what you want to do? > That leads to having of performed operation with no visual effect. Do you mean you don't see any changes when you fine-position half+whole rests? > My suggestion: make this two type of rests to move to the next > _posibile_ position. > That way we'll have only 5 places in staff where this > two rests types could be placed. Hope you got it! :) That's what they should already be doing! Inside a stave, rests should move in discrete steps (the distance between adjacent stave lines) during fine-positioning until they have been moved outside the stave at which point they should start moving continuously. What do you see when you try fine-positioning rests? > 2. There is a bug... Well, again I'll do it step by step: > "Move" rest outside staff by fine position tool. > Click on it (LMB) and drag as you want to perform sweep select. Do you mean "drag" or drag with shift held down? Dragging a rest while shift is held down will change its fine-positioning, but not its absolute time. Dragging without shift held down will change the absolute time of a rest, but not its fine-positioning. > Rest's position will be restored to the original. > Observe: There's no way to undo operation. If you mean "Redo" a fine-positioning operation after you have undone it, then yes, that is a known bug/limitation. > I know my explanation can be confusing... Please ignore that :) I'm trying hard :) > P.S. Hope my ISP is now working good. Please check and report! Anyway, > that's the reason for delay! Yes, reading you ok today! William |
From: Vladimir S. <vl...@eh...> - 2005-02-04 22:32:12
|
On Fri, 4 Feb 2005 18:18:03 GMT, William <ros...@or...> wrote: > Vladimir Savic wrote: >> >> After playing with this rests outside staves, here is the summary (my >> point of view): >> >> 1. It looks like all that fine positioning of whole and half rests is >> related with interval type. > > How is interval type relevant to fine-positioning of rests? > >> That leads to having of performed operation with no visual effect. > > Do you mean you don't see any changes when you fine-position half+whole > rests? Eureka! Obviously we have two different cases here! (try both on the whole rest) 1) Shift + lmb-dragging works perfectly fine for me. 2) Now try this one: Use "Push Up" from menu and you'll see what I'm talking about. First time... Nothing! Yet, second is giveing the desired result. (Here is mine point of view: Speaking of C key - whole rest is virtualy positioned at the place of B(H) - the 3rd line. If you move up you'll have rest at the position of C, which is not posibile. Another "push up" will move rest up to the 4th line of staff - which is expected to happen.) >> My suggestion: make this two type of rests to move to the next >> _posibile_ position. >> That way we'll have only 5 places in staff where this >> two rests types could be placed. Hope you got it! :) > > That's what they should already be doing! Inside a stave, > rests should move in discrete steps (the distance > between adjacent stave lines) during fine-positioning until they have > been > moved outside the stave at which point they should start moving > continuously. > What do you see when you try fine-positioning rests? I was trying to explain that in previous paragraph... >> 2. There is a bug... Well, again I'll do it step by step: >> "Move" rest outside staff by fine position tool. >> Click on it (LMB) and drag as you want to perform sweep select. > > Do you mean "drag" or drag with shift held down? Just released that option (I ment of shift down). So... I'm talking about just pressing lmb on rest and moveing pointer to the previous bar - WITHOUT SHIFT! > Dragging a rest while shift is held down will change its > fine-positioning, > but not its absolute time. Dragging without shift held down will change > the > absolute time of a rest, but not its fine-positioning. No doubt about that... BY, WHY THE REST POSITION IS RESTORED TO IT'S ORIGINAL??? Read upper note. >> I know my explanation can be confusing... Please ignore that :) > > I'm trying hard :) Try harder :) >> P.S. Hope my ISP is now working good. Please check and report! Anyway, >> that's the reason for delay! > > Yes, reading you ok today! Glad to hear that! Vlada > William |
From: William <ros...@or...> - 2005-02-06 20:32:16
|
Vladimir Savic wrote: > On Fri, 4 Feb 2005 18:18:03 GMT, William wrote: >> Vladimir Savic wrote: >>> >>> 1. It looks like all that fine positioning of whole and half rests is >>> related with interval type. >> >> How is interval type relevant to fine-positioning of rests? No answer? >>> That leads to having of performed operation with no visual effect. >> >> Do you mean you don't see any changes when you fine-position > half+whole rests? > > Eureka! Obviously we have two different cases here! (try both on the > whole rest) > 1) Shift + lmb-dragging works perfectly fine for me. > 2) Now try this one: Use "Push Up" from menu and you'll see what I'm > talking about. First time... Nothing! It's a known bug in fine-positioning but I think it's quite a small problem, don't you? The easiest way to do fine-positioning is to use Shift-drag. > Yet, second is giveing the desired result. (Here is mine point of view: > Speaking of C key - whole rest is virtualy positioned at the place of B(H) > - the 3rd line. If you move up you'll have rest at the position of C, > which is not posibile. Again, it's a known bug in fine-positioning. Use Shift-drag instead. >> Dragging a rest while shift is held down will change its fine-positioning, >> but not its absolute time. Dragging without shift held down will >> change the absolute time of a rest, but not its fine-positioning. > > No doubt about that... BY, WHY THE REST POSITION IS RESTORED TO IT'S > ORIGINAL??? Read upper note. > >>> I know my explanation can be confusing... Please ignore that :) >> >> I'm trying hard :) > > Try harder :) Sorry I still don't understand your explanation of the second bug. I think a picture would be worth a thousand words in this case. Can you provide some screenshots please? William |
From: Vladimir S. <vl...@eh...> - 2005-02-08 11:27:43
|
On Sun, 6 Feb 2005 20:32:12 GMT, William <ros...@or...> wrote: > Vladimir Savic wrote: >> On Fri, 4 Feb 2005 18:18:03 GMT, William wrote: >>> Vladimir Savic wrote: >>>> >>>> 1. It looks like all that fine positioning of whole and half rests is >>>> related with interval type. >>> >>> How is interval type relevant to fine-positioning of rests? > > No answer? It's my fault! Becouse of that menu-performed fine positioning bug, I thought it is interval related. :( Ayk >>>> That leads to having of performed operation with no visual effect. >>> >>> Do you mean you don't see any changes when you fine-position >> half+whole rests? >> >> Eureka! Obviously we have two different cases here! (try both on the >> whole rest) >> 1) Shift + lmb-dragging works perfectly fine for me. >> 2) Now try this one: Use "Push Up" from menu and you'll see what I'm >> talking about. First time... Nothing! > > It's a known bug in fine-positioning but I think it's quite a small > problem, > don't you? The easiest way to do fine-positioning is to use Shift-drag. It's OK for me! But, I'll will not be the one to blame if someone else complaint! >> Yet, second is giveing the desired result. (Here is mine point of view: >> Speaking of C key - whole rest is virtualy positioned at the place of >> B(H) >> - the 3rd line. If you move up you'll have rest at the position of C, >> which is not posibile. > > Again, it's a known bug in fine-positioning. Use Shift-drag instead. Perfectly clear! >>> Dragging a rest while shift is held down will change its >>> fine-positioning, >>> but not its absolute time. Dragging without shift held down will >>> change the absolute time of a rest, but not its fine-positioning. >> >> No doubt about that... BY, WHY THE REST POSITION IS RESTORED TO IT'S >> ORIGINAL??? Read upper note. >> >>>> I know my explanation can be confusing... Please ignore that :) >>> >>> I'm trying hard :) >> >> Try harder :) > > Sorry I still don't understand your explanation of the second bug. > I think a picture would be worth a thousand words in this case. > Can you provide some screenshots please? Nope! That will not work! There are steps to reproduce problem, and no picture can crearify that. Here I go again: 1) Shift+drag rest outside staff 2) Release shift and lmb pressure :) 3) Click on the rest again and drag it to the previous or next bar. 4)) Observe: rest's position is being restored to it's original 5)) If on the step 5 can be watched as editing operation - it is not undoable! Vlada > William -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
From: William <ros...@or...> - 2005-02-08 18:26:55
|
Vladimir Savic wrote: > > 1) Shift+drag rest outside staff > 2) Release shift and lmb pressure :) > 3) Click on the rest again and drag it to the previous or next bar. > 4)) Observe: rest's position is being restored to it's original > 5)) If on the step 5 can be watched as editing operation - it is not undoable! Fine-positioning is not a "persistent" property which means it is reset to zero every time you edit an event. Dragging any notation object is an editing operation because it should change the absolute time of the object, and therefore it resets the fine-positioning. If you were to look at that rest using the Advanced Event Editor you would see a warning message under "Non-Persistent Properties" that "These are cached values, lost if the event is modified" and that's why you cannot undo step 3. Unfortunately, dragging a rest doesn't change the absolute time of the rest. That is a known bug: #971316 Notation: Dragging rests fails silently https://sourceforge.net/tracker/index.php?func=detail&aid=971316&group_id=4932&atid=104932 You can make the fine-positioning property persistent by using the Advanced Event Editor but it's usually not a good idea because a permanent fine-positioning cannot be changed by Rosegarden's automatic layout, which can cause bad layout. William |
From: Vladimir S. <vl...@eh...> - 2005-02-08 18:59:37
|
On Tue, 8 Feb 2005 18:27:04 GMT, William <ros...@or...> wrote: > Vladimir Savic wrote: >> >> 1) Shift+drag rest outside staff >> 2) Release shift and lmb pressure :) >> 3) Click on the rest again and drag it to the previous or next bar. >> 4)) Observe: rest's position is being restored to it's original >> 5)) If on the step 5 can be watched as editing operation - it is not >> undoable! > > Fine-positioning is not a "persistent" property which means it is reset > to zero every time you edit an event. > Dragging any notation object is an editing operation because it should > change > the absolute time of the object, and therefore it resets the > fine-positioning. > If you were to look at that rest using the Advanced Event Editor > you would see a warning message under "Non-Persistent Properties" > that "These are cached values, lost if the event is modified" > and that's why you cannot undo step 3. > > Unfortunately, dragging a rest doesn't change the absolute time of the > rest. > That is a known bug: #971316 Notation: Dragging rests fails silently > https://sourceforge.net/tracker/index.php?func=detail&aid=971316&group_id=4932&atid=104932 > > You can make the fine-positioning property persistent by using the > Advanced Event Editor but it's usually not a good idea because a > permanent fine-positioning cannot be changed by Rosegarden's automatic > layout, > which can cause bad layout. Thanx for clearifying this! Vlada > William -- Using Opera's revolutionary e-mail client: http://www.opera.com/m2/ |
From: Chris C. <ca...@al...> - 2005-02-09 15:30:27
|
On a related subject (CVS problems), anyone who watches the rosegarden-bugs list for CVS commit information might like to know that it seems a bit uneven at the moment -- some commits recently have gone completely unreported, such as my commit just now for #1116216. Sometimes the commit hangs entirely at the point where it should be sending the notification email, and sometimes I get an error message. Either way, the commit happens but the notification email doesn't. Chris |
From: William <ros...@or...> - 2005-01-30 20:54:05
|
Vlada wrote: > > On Sun, 30 Jan 2005 20:36:36 GMT, William wrote: > >> CVS compiles ok for me right now. >> I notice you are using bash 2.05b which is more than 3 years old. >> Therefore, I wonder which versions of KDE, gcc, autoconf, and automake >> you have? > >> >> William > > gcc version 3.3.2 20031218 Ok, that's not too old although the current gcc is 3.4.3 (be careful if you do ever upgrade gcc because you will need to get kde/qt packages that were compiled with the identical version of gcc) > Qt: 3.3.3 That's ok. > KDE: 3.3.0 That's ok (latest version is kde-3.3.3). > automake (GNU automake) 1.4 I don't know if that's the cause of your trouble but 1.4 is very old. There is automake-1.9.4 > Autoconf version 2.13 That's old too. I think you should upgrade your Linux distribution to a modern version. Check you also have liblo-0.15, dssi-0.9, and jack-audio-connection-kit-0.99.0. > Thanx for the fast reply! Blame my ISP for that :-) William |