Menu
▾
▴
jazzplusplus-devel
|
From: joakim v. <jo...@ve...> - 2004-03-24 23:27:40
|
Hello, I was going to try to get up to speed by implementing the mididelay dialog with the new cool xml resource system. (I chose this dialog since I wrote the code for it originally and because its really simple) Then I noticed that pianowin no longer inherits eventwin, and the original wx2 ported dialog no longer works(which doesnt matter since I originaly ported it with the ugly property dialog) So, hmm what to do now? I can design the xml resource, but where should the rest of the code go, in the new improved layered design? this is what it currently looks like: tCmdMidiDelay, a command class that acts on the track structure. Should this go into a "kernel" dir? tmidiDelayDlg, a dialog class. Should it be broken out, and put in the dialogs dir? Or, since the code will be trivial, just handled in a function? (I think I prefer a java-style a-file-per-class method) Cheers, /Joakim |
|
From: Dave F. <dav...@co...> - 2004-03-24 23:57:27
|
Joakim, If it were me, and it's *not*, :) , I'd write one single dialog-generator that takes an argument telling it which dialog to generate and then loads the xml resources for it and creates it, grabs the properties, and then makes them available through an associative array, python-like. (There's an STL template for it, but I forget what it's called) Then adding a dialog is a simple matter of creating the xrc file for it and then calling the generator in your event handler. If it were me, that is. :) (I, too, prefer the java-style one-class-per-file method, and a file for each class. Ever play robocode?) Dave On Wednesday 24 March 2004 11:27 pm, joakim verona wrote: > Hello, > > I was going to try to get up to speed by implementing the mididelay > dialog with the new cool xml resource system. > (I chose this dialog since I wrote the code for it originally and > because its really simple) > > Then I noticed that pianowin no longer inherits eventwin, and the original > wx2 ported dialog no longer works(which doesnt matter since I originaly > ported it > with the ugly property dialog) > > So, hmm what to do now? > > I can design the xml resource, but where should the rest of the code go, > in the new improved layered design? > > this is what it currently looks like: > > tCmdMidiDelay, a command class that acts on the track structure. > Should this go into a "kernel" dir? > > tmidiDelayDlg, a dialog class. Should it be broken out, and put in the > dialogs dir? > Or, since the code will be trivial, just handled in a function? > > (I think I prefer a java-style a-file-per-class method) > > Cheers, > /Joakim > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > jazzplusplus-devel mailing list > jaz...@li... > https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel -- Visit my website! http://www.davefancella.com/?event=em We interrupt this fortune for an important announcement... |
|
From: Patrick E. <pa...@pa...> - 2004-03-25 04:55:30
|
I also like having one class per file, though I personally don't mind
having small related utility classes in with the main one. I used to
hate that one class one file Java thing. ;)
As to dialogs, one advantage of the "Attach" method is that different
widgets can be handled automatically. For example, you could attach
a long* to a resource named "number". The user would have the option
of making "number" a wxTextCtrl, a wxSlider, a wxChoice, etc.
With the associative array, extra logic would be necessary to know if
you want, for example, a string or a long. It seems like there could
be issues getting the data in the format you want without having to
write much code for each dialog.
I dunno, I'm sure the "Attach" system is far from perfect, but as far
as I can remember, I haven't seen anything better. I'd be interested
in taking a look at the template thing if you happen to remember what
it is.
BTW, here's an extremely rough comparison of the two techniques:
// "Attach" technique. This is actual code that would work in the
// current system.
jppResourceDialog dialog = jppResourceDialog(parent, "myDialog");
dialog.Attach("myTextCtrl", &myString);
dialog.Attach("myCheckBox", &myBool);
dialog.ShowModal();
// Associative technique.
jppResourceDialog dialog = jppResourceDialog(parent, "myDialog");
if(dialog.ShowModal() == wxID_OK) {
myString = dialog.array["myTextControl"].asString();
myBool = dialog.array["myCheckBox"].asBool();
}
If the associative version were to be non-modal, it would require data
manipulation code in both the Apply and Ok handlers. I'm sure they
could be combined somehow, but it still needs to run at some point.
Switching the "Attach" one to non-modal would be as simple as running
dialog.Show() instead of dialog.ShowModal().
Please tell me if I'm missing some piece of the puzzle, but I honestly
don't see that it gets any simpler than the first method.
For the STL associative arrays, is it the map and hashmap? As far as
I know, those only take keys and values of one type... any type, but
only one at a time.
Patrick
|
|
From: Patrick E. <pa...@pa...> - 2004-03-25 05:07:28
|
On Wednesday 24 March 2004 16:27, joakim verona wrote:
> I can design the xml resource, but where should the rest of the
> code go, in the new improved layered design?
>
> this is what it currently looks like:
>
> tCmdMidiDelay, a command class that acts on the track structure.
> Should this go into a "kernel" dir?
I haven't thought about the whole command / project structure, so
anyone is pretty much an expert compared to me.
> tmidiDelayDlg, a dialog class. Should it be broken out, and put in
> the dialogs dir?
> Or, since the code will be trivial, just handled in a function?
I've been trying to answer that question myself, but I haven't come to
any conclusions. I do think it would be nice if the bulk of the
dialog code could be placed in the dialogs dir in many small files.
That said, the dialogs often need to execute some sort of code
related to the window they were spawned from.
One possible solution is to have the dialog act independently, but
have it call a function defined in an interface. See
tButtonLabelInterface for an example of how tMouseCounter interacts
with the piano window through an interface. If interfaces were
used, the dialog file would contain the interface and any code for
the dialog itself. The main source file would implement the
interface in the form of a function, performing whatever
manipulations were necessary. In fact, if the interface was
implemented by something in the kernel, an upper level class could
simply hook the dialog and the kernel code together though the
interface. Am I making sense? Do I sound sane? If you think my
ideas are flawed, I really want to hear about it.
Patrick
|
|
From: Dave F. <dav...@co...> - 2004-03-25 05:34:45
|
On Thursday 25 March 2004 05:07 am, Patrick Earl wrote: > On Wednesday 24 March 2004 16:27, joakim verona wrote: > > I can design the xml resource, but where should the rest of the > > code go, in the new improved layered design? > > > > this is what it currently looks like: > > > > tCmdMidiDelay, a command class that acts on the track structure. > > Should this go into a "kernel" dir? I'm envisioning a jppTrack object that stores the tracks and each track's selection. In fact, I'm probably going to start in on that class tonight. You would access a given jppTrack through the gProject instance of jppProject. I've got several ideas for that, I'm curious to see how they all play out when I get coding. :) In any case, I'm thinking that the way it should work is you query the jppTrack for data, either the selected data or the entire track, then you get a const pointer to that data. You do whatever you're going to do to it by moving it from your const structure to a new structure, and then you commit the new structure and the jppProject class will organize the new data. The idea is to preserve the history of edits and stuff and ultimately allow unlimited undo, even across multiple saves. > I haven't thought about the whole command / project structure, so > anyone is pretty much an expert compared to me. > > > tmidiDelayDlg, a dialog class. Should it be broken out, and put in > > the dialogs dir? > > Or, since the code will be trivial, just handled in a function? > > I've been trying to answer that question myself, but I haven't come to > any conclusions. I do think it would be nice if the bulk of the > dialog code could be placed in the dialogs dir in many small files. > That said, the dialogs often need to execute some sort of code > related to the window they were spawned from. I don't see any reason this has to remain so. If you consider that everything is an "Action" or a "command", then there should be an interface in the jppProject class for performing actions or commands. So you open your dialog, get data from the user, then pass that data to jppProject and tell it to execute this action or that command or whatever, and jppProject does the execution. It can use callbacks or events to inform the GUI about its progress so the GUI can draw progressbars and so forth. > One possible solution is to have the dialog act independently, but > have it call a function defined in an interface. See > tButtonLabelInterface for an example of how tMouseCounter interacts > with the piano window through an interface. If interfaces were > used, the dialog file would contain the interface and any code for > the dialog itself. The main source file would implement the > interface in the form of a function, performing whatever > manipulations were necessary. In fact, if the interface was > implemented by something in the kernel, an upper level class could > simply hook the dialog and the kernel code together though the > interface. Am I making sense? Do I sound sane? If you think my > ideas are flawed, I really want to hear about it. The last half of the paragraph is exactly what's in my mind. :) Dave > Patrick > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > jazzplusplus-devel mailing list > jaz...@li... > https://lists.sourceforge.net/lists/listinfo/jazzplusplus-devel -- Visit my website! http://www.davefancella.com/?event=em History is on our side (as long as we can control the historians). |
|
From: Dave F. <dav...@co...> - 2004-03-25 05:27:35
|
On Thursday 25 March 2004 04:55 am, Patrick Earl wrote:
> I also like having one class per file, though I personally don't mind
> having small related utility classes in with the main one. I used to
> hate that one class one file Java thing. ;)
Well, to go into more detail, I figure that a class that is only used in one
place is perfectly ok being in that file as well (you'll see me do this
occasionally). But if a class gets used by two or more other classes, it
should be pulled out and stuck in its own file. That said, I also don't like
source trees with a bazillion files, and all these files and classes in Jazz
kinda get on my nerves. I think we should take Fesic's advice and go 'back
to the beginning'. :)
> As to dialogs, one advantage of the "Attach" method is that different
> widgets can be handled automatically. For example, you could attach
> a long* to a resource named "number". The user would have the option
> of making "number" a wxTextCtrl, a wxSlider, a wxChoice, etc.
To be honest, I'm not particular on *how* the data is pulled from the dialog.
I'm interested in this Attach method. Also, bear in mind I just came back
from php-land yesterday, so it'll take a little bit for me to get
strongly-typed again. :( In any case, I was thinking that the absolute best
way to take the most advantage out of XRC would be to have one single dialog
maker using several different XRC dialog resources rather than just making a
bunch of dialogs that all load their resources from a file. It's entirely
possible that the XRC system will take care of the whole problem of pulling
data from the dialog for us. I seem to recall that in XRC you define both
the resource name and the type, placement, look, etc. Maybe it just takes
care of it for us? ;)
> With the associative array, extra logic would be necessary to know if
> you want, for example, a string or a long. It seems like there could
> be issues getting the data in the format you want without having to
> write much code for each dialog.
Not necessarily, but the associative array deal is far from perfect. It is
pretty readable, though, and that's a winning trait for it's use in
weak-typed languages.
> I dunno, I'm sure the "Attach" system is far from perfect, but as far
> as I can remember, I haven't seen anything better. I'd be interested
> in taking a look at the template thing if you happen to remember what
> it is.
It's just a template in STL. I think you were right when you said it was a
hash, map, or hashmap, or something like that. You do:
std::hash<jppDialogData> *DialogData;
jppDialogData is a class you construct to store all the data in. Or something
like that. I'm forgetting how the maps actually work right now. :(
> BTW, here's an extremely rough comparison of the two techniques:
>
> // "Attach" technique. This is actual code that would work in the
> // current system.
> jppResourceDialog dialog = jppResourceDialog(parent, "myDialog");
> dialog.Attach("myTextCtrl", &myString);
> dialog.Attach("myCheckBox", &myBool);
> dialog.ShowModal();
Is this "Attach" method part of wxWindows already? It looks familiar....
> // Associative technique.
> jppResourceDialog dialog = jppResourceDialog(parent, "myDialog");
> if(dialog.ShowModal() == wxID_OK) {
> myString = dialog.array["myTextControl"].asString();
> myBool = dialog.array["myCheckBox"].asBool();
> }
>
> If the associative version were to be non-modal, it would require data
> manipulation code in both the Apply and Ok handlers. I'm sure they
> could be combined somehow, but it still needs to run at some point.
> Switching the "Attach" one to non-modal would be as simple as running
> dialog.Show() instead of dialog.ShowModal().
>
> Please tell me if I'm missing some piece of the puzzle, but I honestly
> don't see that it gets any simpler than the first method.
>
> For the STL associative arrays, is it the map and hashmap? As far as
> I know, those only take keys and values of one type... any type, but
> only one at a time.
Yes, but the type is user-defined. You can give it a struct or a class, so
you can actually store whatever data you want. Build your class just right,
and you can always extract it in whatever form you want. I don't know if
it's the best solution, though. If it were PHP, it would be. :) (Or
Python, heh. Anybody want to port Jazz to wxPython? Then we'd be finished
with it tomorrow)
Dave
--
Visit my website!
http://www.davefancella.com/?event=em
He who has imagination without learning has wings but no feet.
|
|
From: Patrick E. <pa...@pa...> - 2004-03-25 05:40:38
|
On Wednesday 24 March 2004 14:27, Dave Fancella wrote:
> To be honest, I'm not particular on *how* the data is pulled from
> the dialog. I'm interested in this Attach method. Also, bear in
> mind I just came back from php-land yesterday, so it'll take a
> little bit for me to get strongly-typed again. :( In any case, I
> was thinking that the absolute best way to take the most advantage
> out of XRC would be to have one single dialog maker using several
> different XRC dialog resources rather than just making a bunch of
> dialogs that all load their resources from a file. It's entirely
> possible that the XRC system will take care of the whole problem of
> pulling data from the dialog for us. I seem to recall that in XRC
> you define both the resource name and the type, placement, look,
> etc. Maybe it just takes care of it for us? ;)
Well, I don't know precisely what you're refering to, but I do know
that XRC only specifies the GUI widgets and their layout. It doesn't
specify any means for interaction with data. You're expected to do
basically wxWindow:::FindWindowByName(dialog, "someWidget") and get
the data out yourself. It's not -hard- to get the data out, but it's
still much easier with a wrapper class doing the dirty work for you.
> Not necessarily, but the associative array deal is far from
> perfect. It is pretty readable, though, and that's a winning trait
> for it's use in weak-typed languages.
Ya, they're great in dynamically typed languages. :)
> > // "Attach" technique. This is actual code that would work in
> > the // current system.
> > jppResourceDialog dialog = jppResourceDialog(parent, "myDialog");
> > dialog.Attach("myTextCtrl", &myString);
> > dialog.Attach("myCheckBox", &myBool);
> > dialog.ShowModal();
>
> Is this "Attach" method part of wxWindows already? It looks
> familiar....
Hmm, I hope not... otherwise I just re-invented the wheel.
Patrick
|
|
From: Dave F. <dav...@co...> - 2004-03-25 05:45:37
|
On Thursday 25 March 2004 05:40 am, Patrick Earl wrote: > > Is this "Attach" method part of wxWindows already? It looks > > familiar.... > > Hmm, I hope not... otherwise I just re-invented the wheel. In that case, the decision is made. :) Do this "Attach" thing and blind us with your brilliance. :) Seriously! I have seen Attach used as a method to do things, though, but usually in plugin setups and/or threading, I think. Maybe it's looking familiar because every single thread class has an "Attach" method? ;) Dave -- Visit my website! http://www.davefancella.com/?event=em Give your child mental blocks for Christmas. |
|
From: Patrick E. <pa...@pa...> - 2004-03-25 07:28:22
|
On Wednesday 24 March 2004 14:45, Dave Fancella wrote:
> On Thursday 25 March 2004 05:40 am, Patrick Earl wrote:
> > > Is this "Attach" method part of wxWindows already? It looks
> > > familiar....
> >
> > Hmm, I hope not... otherwise I just re-invented the wheel.
>
> In that case, the decision is made. :) Do this "Attach" thing and
> blind us with your brilliance. :) Seriously!
lol... well, it's already done. It doesn't yet apply to every
possible case, but it's not hard to add new widets and data types. I
also didn't implement non-modal dialogs... those are next on my todo
list. If anyone needs anything right away and doesn't want to do it
themselves, please let me know... I will implement it as soon as I
get your mail.
BTW, I wrote quite a bit of doxygen documentation for the
jppResourceDialog class. Check it out if you're trying to do that
stuff. If it's not good enough, again I'm happy to try and fix it.
I got rid of that crazy *d()))at+++(in+t *)+ stuff. Okay, so I
exagerate the mess it was, but only slightly. :P
Patrick
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X