Another feature patch (Append Label Suffixes)

[Julie S]

Hello Everyone.

I've attached at patch for consideration.

Main purpose of patch:
----------------------
* This patch allows the user to decide if RG will attach suffixes such as "(copied)", "(recorded)", "(split), etc. to segment labels.

How to use feature:
-------------------
* From Settings->Configure Rosegarden...

* Goto General->Behavior (this is the front page of the dialog on my system.)

* Select or de-select the "Append suffixes to segment labels" checkbox.  This is set to "true" by default to mimic standard RG behavior.

* Select "OK."
 
Other goals of patch:
---------------------
* Simplify adding suffixes to segment label.  This makes the code easier to read.

* Makes how RG adds label suffixes consistent throughout application.  Current code has each function implement error checking and decision making such as: Does the suffix--like "(copied)"--already appear in the label? Labeling code was not consistently applied in the code, I found several implementations of the code I believe was intended to give the same result.

* Updated Split on Silence feature to add "(part %1)" instead of "(part)" for SegmentAutoSplitCommand and "(autosplit %1)" for AudioSegmentAutoSplitCommand.  This was a morphing of how the to commands did autosplitting.

Known Issues:
-------------
* Translations need updated.  In the German translation, I found about 10 messages that need updated.

Questions:
----------
* I don't know if I implemented the best way to read Rg configurations in base/Segments.cpp.  I had to include <kapplication.h> and <kconfig> to Segment.cpp.  Is there a more elegant method to get at the configuration values.

* If this patch is added, should I go and edit the translations.  Other than the "(part %1)" label I can easily discern what needs to be modified in each file.  I can even make an intelligent guess from existing messages how to correct the "(part %1)" autosplit messages.  I didn't want to step on anyones toes concerning this--the translators have done a lot of work and I didn't want to interfere with that process.

...

I'm open for comments and suggestions.

Sincerely,
Julie S.



     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre]

On Thursday 17 July 2008, Julie S wrote:

> * This patch allows the user to decide if RG will attach suffixes such as
> "(copied)", "(recorded)", "(split), etc. to segment labels.

These seem like worthy goals. The whole "Acoustic Grand Piano (split) (copied)
(copied) (split) (copied) (copied) (copied) (split) (split) (split)" thing
has always been pure cheese, but nobody ever got motivated to do anything
about it, and/or nobody came up with a workable fix before.  I remember
arguing about this whole issue before, but not what came of it.  (Looks like
nothing ever came of it.)

> Questions:
> ----------
> * I don't know if I implemented the best way to read Rg configurations in
> base/Segments.cpp.  I had to include <kapplication.h> and <kconfig> to
> Segment.cpp.  Is there a more elegant method to get at the configuration
> values.

This is one of the troublesome things about working on Rosegarden.  We tried
to design all the base classes so that we could port to some other GUI
toolkit one day (as Guillaume Laurent is in fact doing now with his OS-X
Cocoa fork) and we don't allow QT or KDE classes in base/.

We've argued about this before, but so far we have never allowed an exception
to the rule. So we have to figure out a way to refactor this so that it
doesn't need KDE classes in base/, or we need to officially decide to give up
that rule.

I'm sure there's a precedent for getting the state of some GUI-level
configurable down in base/, but I can't think of anything off the top of my
head.

Considering that we're at least nominally working on a QT4 port that will have
to use a different configuration mechanism[1] and considering that we have
agreed to pull any changes to trunk/ after the official split into the new
(billions of eons from actually building yet at this rate) line, we should
probably go ahead and use this as an opportunity to think about.

1) Do we want to remove the restriction on toolkit-specific classes in base/
now that we have pretty much officially decided that there is no practical
way to ever port to anything other than QT?  (We have a disagreement here
with Guillaume on the side of doing exactly that, and Chris and I both of the
idea that it's nothing short of madness to do so.)

2) We haven't yet picked which way we're going to do the config stuff, I don't
think.  We should choose.  (Or did we officially decide to use QSettings?)

[1] KConfig still exists in KDE4, but the syntax is substantially different,
so whether we use the new KConfig or switch over to QSettings (I think it's
called) we still have to totally refactor all the user config interaction
stuff in some way.

> * If this patch is added, should I go and edit the translations.  Other
> than the "(part %1)" label I can easily discern what needs to be modified
> in each file.  I can even make an intelligent guess from existing messages
> how to correct the "(part %1)" autosplit messages.  I didn't want to step
> on anyones toes concerning this--the translators have done a lot of work
> and I didn't want to interfere with that process.

I'd hold off on the translations. You should feel free to work on any
translations you want, but I'd recommend doing everything by the book, using
the procedure we have spelled out somewhere. It's easy to muck things up
trying to be inventive here, which I've discovered the hard way.

We also have to deal with this issue in the port too.  i18n() is changing
considerably, but if we go the pure QT route we have to move everything over
to tr().  I don't remember if we've already made a call on this.  If we
haven't, I will officially decide we're going to use the new i18n classes,
and have one less headache to deal with.  Stuff a free porting tool can even
halfway help with is the way to go, sez me.  Plus we don't have to change
formats at all that way.

Anyway, for 10 strings, I wouldn't sweat any of that at this point in time.  I
don't usually bother to update translations until there are at least 50
strings to deal with.  (I've been the de facto Spanish translator for awhile,
since we can't keep one on hand. Even though translations from a non-native
always suck, and I'm sure somebody out there wonders what jackass did the
Spanish translation.)

Now, having written all that, I'll go actually take a look at the patch, and
I'll get back to you with any further thoughts.

Oh, and thanks, and especially thanks for your patience in dealing with this
nasty time in terms of being caught between the old world and the future new
world that mostly doesn't even exist yet.
--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre]

> Now, having written all that, I'll go actually take a look at the patch,
> and I'll get back to you with any further thoughts.

Bah.  My post hasn't arrived yet, so I'll just re-reply to the original
message.  Having looked at the patch briefly, it seems like having this code
in Segment is elegant in terms of minimizing redundancy, and I'm not seeing a
tidy way to tweak it to avoid the whole issue.  Looks like a tweak would
involve passing in a bool and redundant code in several places to get a value
for that bool, all to accomplish something of dubious value in the first
place.

So the biggest question is which is more dubious here.

1) Continuing to exclude QT from base/ in this brave new world of (almost
completely) vaporware Rosegarden 2.0 for QT/KDE4?

2) Bothering with any of this complicated what if logic to preserve old
behavior that everyone has always thought was cheese anyway?

Depending on that answer, possible solutions are:

1) Pull the bool deciding logic into gui/ in whatever way seems the most
elegant and least redundant, and pass a new parameter to
Segment::setLabelPrefix() to let it know the answer to the user's GUI config
question

2) Commit the patch.  Who really cares at this late date about keeping QT out
of base/ anyway?  (Although if we make that argument, it follows to get rid
of all the qstrtostr() whatever hackery we have bloody everywhere in this
thing already to accommodate that original design parameter, and it wouldn't
be very clean just to let one exception in half-assed without refactoring all
of base to just use bloody QString already)

3) Forget about the GUI configuration what if jibbledefruckis and just decide
to eliminate the stupid suffixes entirely anyway.

4) Proposition 933B

5) Eat more Cheese Whiz.

I don't know.  Big proclamations like this one really need someone from on
higher than I am in the scheme of things.  We don't have a real official
leader, but Chris writes better code in his sleep than I write at my height
of achievement, so let's see if we can't lure him into this, shall we?

(Proposition 933B is the one where we vote to pay me a salary of $50,000 USD
per year.)

Aw crap.  Gotta run anyway.
--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre]

On Thursday 17 July 2008, D. Michael McIntyre wrote:

> 1) Pull the bool deciding logic into gui/ in whatever way seems the most
> elegant and least redundant, and pass a new parameter to
> Segment::setLabelPrefix() to let it know the answer to the user's GUI
> config question

Or, uh, just don't *call* it if it isn't wanted.  Duh.

> 2) Commit the patch.  Who really cares at this late date about keeping QT
> out of base/ anyway?  (Although if we make that argument, it follows to get
> rid of all the qstrtostr() whatever hackery we have bloody everywhere in
> this thing already to accommodate that original design parameter, and it
> wouldn't be very clean just to let one exception in half-assed without
> refactoring all of base to just use bloody QString already)

Right, so at this point I'm leaning toward keeping QT out of base/ just
because that's the way everything else is.  I don't think it makes a lot of
sense overall to persist with this aspect of the design, but if I wanted to
lift the ban on QT in base/, I'd want to refactor all the stupid hacky
qstrtostr nonsense we have everywhere at the same time, and that's a side
project that would just add senseless complexity to an already senselessly
complex job of porting.

> 3) Forget about the GUI configuration what if jibbledefruckis and just
> decide to eliminate the stupid suffixes entirely anyway.

Vote++, unless there are good arguments to be made for stuff like after the
autosplitting whatsis maybe.

--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Julie S]

Dear Michael,

Boy, I didn't intend to stir the pot so much.  I guess I found that cow pasture you were talking about.

I've read both of your posts.  Good advice on the translation stuff.  I thought that leaving it alone might be best.

QT/KDE/OS-X/--That is really all beyond me.  I know QT works on several platforms.  KDE in a Linux thing as far as I know.  So I can see limiting any extra KDE code since portability is an issue.  I can also see monopolizing on QT--like Qsettings and tr.  But, RG creators intended an even more portable base. So, I would want to respect that.

Now I understand the translation page on the RG site that talks about design issues and internal storing of content.  It sounds like we are dealing with an original intent issue and being true to the intents of the author.

You said:
> 1) Pull the bool deciding logic into gui/ in whatever way seems the
> most elegant and least redundant, and pass a new parameter to
> Segment::setLabelPrefix() to let it know the answer to the user's GUI
> config question

As far as checking configuration files is concerned,  We can fix that, too, using your approach.  But, we would need to write a function that checks the status and returns a bool.  We could pass that value as a parameter as you suggested.  But, I think that would make setLabelSuffix clumsy in practice and nonfocused.  If we checked the status and know the answer, why would we call seLabelSuffix and pass it a bool false, knowing the outcome of the call to setLAbelSuffix is to do nothing.

I guess I'm arguing that if we pull the status check out from setLabelSuffix, we should use the results of the call to the check the status to decide if even to call setSuffixLabel.

So, we could leave the checking of adding duplicate suffixes to the original setLabelSuffix command and do a call to check the status "isAppendLabelChecked()" (or some other named function).  Then check the results before calling setLabelSuffix

So, a sample fragment in a command would look like:
if (isAppendLabelChecked()) {
  new_segment->setLabelSuffix(qstrtostr(i18n("(copied")));
}

Where to define isAppendLabelChecked() is a good question since it needs to be available to multiple areas of RG code.  Maybe in the src/misc directory.

...

You said:
> 2) Bothering with any of this complicated what if logic
> to preserve old behavior that everyone has always thought
> was cheese anyway?

This code was an attempt to address that.  Yes I think label suffixes are cheese.  I also think people should be careful when editing--specially in bulk, but I think they serve a purpose at time.  I think removing the suffixes completely might be a bit unwise.  At times they can be helpful, but usually they are a nuisance.

It as an attempt to add features without taking away intent of the author, just like the whole KDE and QT in base class stuff--just a smaller scale courtesy.

Well, those are my thoughts.

Sincerely,
Julie S.



     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre]

On Thursday 17 July 2008, Julie S wrote:

> Boy, I didn't intend to stir the pot so much.  I guess I found that cow
> pasture you were talking about.

Moo.  :)

> monopolizing on QT--like Qsettings and tr.  But, RG creators intended an
> even more portable base. So, I would want to respect that.

Always the best approach, though it still really is debatable at this point
whether it's worth it to continue with that policy. That's not a discussion
you need to worry about unless you have a vested interest though.

The other big thing to step in around here is that you should never run your
code, and especially not an entire source file--or worse, the whole
project--through a code beautifier.

> the status and returns a bool.  We could pass that value as a parameter as
> you suggested.  But, I think that would make setLabelSuffix clumsy in
> practice and nonfocused.

Yeah yeah, I already thought of that in a comment to myself later on.  That
would be stupid.

> Where to define isAppendLabelChecked() is a good question since it needs to
> be available to multiple areas of RG code.  Maybe in the src/misc
> directory.

How many different places?  This isn't likely to change much in the future, so
if it's three or less, and it was me, I'd probably just paste the code
snippet in three different places, even though writing some new shareable
whatzit would be the best approach from a design perspective.

It also depends on where this is called, and whether you already have a
KConfig object available there.  This seems rather likely in most places a
segment would be twiddled.  There's usually a local config or cfg or
sometimes c variable you could just use on the spot with a config|cfg|
c->readBoolEntry(bliffle) or whatever.  (I'm not looking at any of the code,
or any of the real syntax at the moment.)

Well, carry on then.  Tweak from here, and we'll take another look directly.

(Speaking of stepping in things, we were poking around in the creek trying to
find crayfish or newts or frogs or something, and instead we found
yellowjackets.  I hate those sorry bastards.  I'm stung all over, and not in
a great mood just now.)

> It as an attempt to add features without taking away intent of the author,
> just like the whole KDE and QT in base class stuff--just a smaller scale
> courtesy.

Always the most sensible approach around here, where you never know who is
going to be totally in love with some legacy feature like that, and when your
bold new stroke of brilliance is going to be met with all kinds of crazily
unexpected resistance.

Your instincts are great, and there's nothing at all wrong with your approach.  
I'm just saying in this particular case, if it's more than a little bother,
we could probably just dispense with these ridiculous labels once and for
all.  I don't think anyone is going to cry if they go away.
--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Julie S]

Dear Michael,

>From your last message, I will go ahead and make a tweak to the patch.

I need to accomplish the following:
* Rewrite setLabelSuffix so no KDE/QT code appears.
* Add a function such as isAppendLabelChecked() to a logical location.

I will give this all some thought.  Maybe, I can find a better way to package all of this.

You said:
> (Speaking of stepping in things, we were poking around in
> the creek trying to
> find crayfish or newts or frogs or something, and instead
> we found
> yellowjackets.  I hate those sorry bastards.  I'm stung
> all over, and not in
> a great mood just now.)

I'm sorry.  I hope you feel better soon.  Take care.

Sincerely,
Julie S.




     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[cannam]

On Thu, Jul 17, 2008 at 4:51 PM, D. Michael McIntyre
<michael.mcintyre@...> wrote:
> I'm sure there's a precedent for getting the state of some GUI-level
> configurable down in base/, but I can't think of anything off the top of my
> head.

There is a precedent, but it is a precedent for configuration data
that are stored in the document rather than in application settings --
see Configuration.h, and particularly the TransportMode configuration
which was added relatively recently by Philippe Macaire.

I can't however think of any examples of application settings that are
used by classes in base, and I don't think therefore that we have any
established way of doing that.  Ingenuity may be called for.

> 1) Do we want to remove the restriction on toolkit-specific classes in base/
> now that we have pretty much officially decided that there is no practical
> way to ever port to anything other than QT?  (We have a disagreement here
> with Guillaume on the side of doing exactly that, and Chris and I both of the
> idea that it's nothing short of madness to do so.)

Well, to be fair I was the one who insisted on not using any Qt stuff
in base in the first place -- not Guillaume.

I don't feel as strongly about that as I used to, partly because it's
obvious that the amount of stuff we have in base/ is now pretty small
in comparison with everything else (e.g. we don't even have a proper
Qt-free document class) and partly because we lose so much readability
through pervasive use of things like qstrtostr().

But I think we need to either abandon the policy properly (making an
effort to replace std::string with QString throughout, for example,
and get rid of all the nasty hacks) or else stick to it.  I don't
think we should allow just the odd exception here and there; that
would be the worst of both worlds.

I do think this approach for segment labels is a good one, though.
It's just that if we're sticking with the no-Qt-in-base policy, it'll
need to have some slightly more roundabout mechanism for getting the
preference in there (perhaps the document sets it on the composition
and the segment queries it from that, or something).


Chris

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre]

On Friday 18 July 2008, Chris Cannam wrote:
> There is a precedent, but it is a precedent for configuration data
> that are stored in the document rather than in application settings --
> see Configuration.h, and particularly the TransportMode configuration
> which was added relatively recently by Philippe Macaire.

Yeah, that's what I was trying to dredge up.

> Well, to be fair I was the one who insisted on not using any Qt stuff
> in base in the first place -- not Guillaume.

I have no idea who was responsible for that, and wasn't implying that it was
Guillaume.  I merely point out that he's the one most likely to benefit from
that design consideration now that he's off working on his fork.  For our
part, I think we've pretty much decided our fate and QT's fate are one.  
There's just too much GUI code, and while we do build on an encapsulated
base, that doesn't do much to mitigate the complexity of porting the massive
GUI to something else.

> But I think we need to either abandon the policy properly (making an
> effort to replace std::string with QString throughout, for example,
> and get rid of all the nasty hacks) or else stick to it.  I don't
> think we should allow just the odd exception here and there; that
> would be the worst of both worlds.

No, I totally agree, and said as much in another message in the thread.  To
reiterate:

 (Although if we make that argument, it follows to get rid
 of all the qstrtostr() whatever hackery we have bloody everywhere in this
 thing already to accommodate that original design parameter, and it wouldn't
 be very clean just to let one exception in half-assed without refactoring all
 of base to just use bloody QString already)
--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Julie S]

Hello Chris,

> I do think this approach for segment labels is a good one,
> though.
> It's just that if we're sticking with the
> no-Qt-in-base policy, it'll
> need to have some slightly more roundabout mechanism for
> getting the
> preference in there (perhaps the document sets it on the
> composition
> and the segment queries it from that, or something).

Well, you caught me Chris.  I am an old school programmer who hasn't done any coding for many years.  C and I were good friends a long time ago.  But, my interest in RG has got me dusting off the ancient knowledge--now in C++ flavor.  It's been quite a learning curve for me--my coding shows it.

I'm happy to take your route, though.  I had a feeling I was breaking some rules, when I hacked in the KConfig stuff.  I was hoping somebody would show me a better way to access KConfig stuff.

Breaking rules or not, I was just happy I got anything working.

I'm now looking at the RosegardenGUIDOoc and Composition files to decipher them.  Hopefully, I'll find a good route.

I'll return later after looking at those documents.  I've got a lot to learn.

Thank you.

Sincerely,
Julie S.



     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[cannam]

On Fri, Jul 18, 2008 at 3:38 PM, Julie S <msjulie_s@...> wrote:
> I'm happy to take your route, though.  I had a feeling I was breaking some rules, when I hacked in the KConfig stuff.

Only because our rule is so arbitrary.  It would be a perfectly
sensible way to do it otherwise.


Chris

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre]

On Friday 18 July 2008, Julie S wrote:
> Well, you caught me Chris.  I am an old school programmer who hasn't done
> any coding for many years.  C and I were good friends a long time ago.
> But, my interest in RG has got me dusting off the ancient knowledge--now in
> C++ flavor.  It's been quite a learning curve for me--my coding shows it.

You're in good company here, Julie.  I looked at C++ briefly 40 million years
ago (about 1994ish?) but never really did much more with it than switch
printf for cout and that kind of thing at the time.  I was definitely not
down with the whole OOP thing back when, and my only attempt at writing
anything in a GUI environment was with Turbo Pascal for Windows.  I was
trying to rewrite an old favorite DOS utility of mine (one of the few pieces
of software I ever got paid real money to write!) in a newly minted graphical
Windows version.

I eventually used a debugger to trace my program opcode for opcode, and
determined that the reason it kept crashing was because some string of mine
translated to a JMP instruction in machine language, and my program was
executing its strings.  A buffer overflow, I guess.  Anyway, that was when I
packed it up and decided no more programming for me, because I couldn't for
the life of me figure out why the hell that was happening.

Enter Rosegarden, and a copy of "Learn C++ in 21 Days."

I think I do pretty well under the circumstances, but as a project
administrator here, I really do wish we could afford to fire my sorry ass and
hire a real programmer to replace me.  :)

> Breaking rules or not, I was just happy I got anything working.

Rule #1:  Get it working first.  If you can get it working, or even just
mostly working, then someone else can help with the rest.

Rule #2:  Don't use QT in base/

Rule #3:  Never run our code through a code reformatter

Rule #4:  Pay D. Michael McIntyre $50,000

Rule #5:  GOTO Rule #4

> I'm now looking at the RosegardenGUIDOoc and Composition files to decipher
> them.  Hopefully, I'll find a good route.

Or just do the test in the calling code, like we talked about.  That would be
perfectly fine.  We care about results first, and elegance isn't mandatory;
though you should by no means feel dissuaded from pursuing elegance if you
wish to do so.

Keep in mind that while it's always a good idea to design something so that it
can be used in new ways easily, this particular code isn't going to see a lot
of changes, so if it's a mild pain in the ass to call the string grabbing
function now in a few places in the code, it's no big deal.
--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Julie S]

Dear Michael,

Thank you for the encouragement and the tips.

You said:
> Rule #4:  Pay D. Michael McIntyre $50,000
>

The check is in the mail.  Keep a look out for it.

You said:
> Or just do the test in the calling code, like we talked
> about.  That would be
> perfectly fine.  We care about results first, and elegance
> isn't mandatory;
> though you should by no means feel dissuaded from pursuing
> elegance if you
> wish to do so.

Well, the error, in one fashion or another (for duplicate labels), already exists in 10 files--taking a quick count.  So, taking your advice and just putting the status checking in would not change the current level of readability, since I would just be swapping out one status check for another in each file.

You also mention that this feature will not change much--that is true, too.  But if anyone else adds a feature that "requires" label suffixes, they will add to the number of times this coding appears.

If, we are not in a hurry, I'd like to continue to explore "the elegant approach."  Chris has given some good advice, and I'm willing to continue at it and learn along the way.

My current thought is to treat the use suffix labels similar to the PropertyNames TransportMode and PropertyNames ZoomLevel found in base/configuration.h & .cpp.  They are accessible in base and stored in KConfig. So the GUI can access them and so can base.

My STL is super weak, though.  Give me some time.

Also, I'm signing off for the weekend.  Got lots of family and friend time to put in.  I'll be back at it Monday.

Sincerely,
Julie S.



     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[Julie S]

Hello All,

Like Tommi and his pitch wheel work, I too am at an impasse and need some help:

I've covered many option including using PropertyNames UseLabelSuffixes.  I could not find any way to directly save the values above the document (.rg file) level.  Each RG file could save it.  So I saved a default studio.  I was left with saving a copy of the value in KConfig and reinitalizing the PropertyName USeLabelSuffixes each time the Studio was initialized.

This, in my mind, is an ugly hack.

At this point, I'm pretty confident that the code for this patch must not reside in any base code at all.

Unfortunately, I don't know where to put the code.  The code must be available to about 9 files in src/commands/segment to src/commands/edit/CopyCommand and src/document/RosegardenGUIDoc.

My though is to treat this like misc/Strings.  I'd like to move the code to misc/LabelSuffixes.  That way I can use KConfig and avoid and src/base changes.

Any thought on this would be nice.

Sincerely,
Julie S.



     

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Rosegarden-devel mailing list
Rosegarden-devel@... - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-devel

[D. Michael McIntyre]

On Tuesday 22 July 2008, Julie S wrote:

> At this point, I'm pretty confident that the code for this patch must not
> reside in any base code at all.

Seems like a sensible conclusion.

> My though is to treat this like misc/Strings.  I'd like to move the code to
> misc/LabelSuffixes.  That way I can use KConfig and avoid and src/base
> changes.
>
> Any thought on this would be nice.

I can't think of any better place to put it off hand, and having taken a
glance at some of the places where this would need to be used, encapsulating
the whole bit into some tidy call to something somewhere would definitely be
easier to read and more maintainable.

I think I might just throw this directly into misc/Strings.* myself, since
this is going to be a small amount of code, and since every affected file
should already include misc/strings.h anyway.  That way you don't have to add
new files to the build system, and add new includes everywhere just for this
one small bit.
--
D. Michael McIntyre

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://mob