Porting Violet to Java
sorry, problems at school have arrizen (teacher has undiagnosed bipolar & manic, very anoying) so i havent had a change to do anything. Easy way to connect GUI to other stuff
(cheap example written fast)
GUI's values are stored in a model, the GUI can pass the model to a thread. THread has the values, without touching any GUI methods, thus avoiding lockup (provided you don't do silly stuff).
to your last question, yes you can, i realy dont have the time to mess around with it though
(cheap example written fast)
Code: Select all
//somewhere in code//
GUIcomp foo = new GUIcomp(3.2);
new ProcessThread(foo.getModel());
Class GUIcomp extends jComponent
{
private synchronized DataModel model = new DataModel;
GUIcomp(double parameters)
{model.setValue(parameters);}
/*blablabla*/
public double getVal()
{ return model.getVal(); }
public DataModel getModel()
{ return model; }
}
Public class DataModel
{
private double value;
DataModel(double val){
value = val;}
public void setVal(double val){
value = val;}
public double getVal(){
return value;}
}
to your last question, yes you can, i realy dont have the time to mess around with it though
Yes i know, my spelling sucks
Thanks eman - that's quite useful.
Don't worry about being busy with school, some might say that's more important
edit:
REVISION 39
I have started implementing your pattern eman, and I can now (finally!) see how it works.
Reinhard and Linear parameters should be updating from the GUI, just need to do the rest of the Models and make a couple of buttons work and it'll be fairly useable.
Don't worry about being busy with school, some might say that's more important
edit:
REVISION 39
I have started implementing your pattern eman, and I can now (finally!) see how it works.
Reinhard and Linear parameters should be updating from the GUI, just need to do the rest of the Models and make a couple of buttons work and it'll be fairly useable.
REV 42
GUI plumbing pretty much complete. Need to add switches (checkboxes) to enable certain features (Noise reduction etc).
A brief note-to-self-cum-todo-list based on a few thoughts separate from finishing the features as they are currently implemented:
- Perhaps some of the settings could be laid out differently such that they become less mutually-exclusive.
- Perhaps allow control of the order of processing various functions
- Check all processing functions for concurrency compatibility, and re-enable multi-threading
- erm.. there's more but it's a friday evening and this week has pretty much burned my brain out.
GUI plumbing pretty much complete. Need to add switches (checkboxes) to enable certain features (Noise reduction etc).
A brief note-to-self-cum-todo-list based on a few thoughts separate from finishing the features as they are currently implemented:
- Perhaps some of the settings could be laid out differently such that they become less mutually-exclusive.
- Perhaps allow control of the order of processing various functions
- Check all processing functions for concurrency compatibility, and re-enable multi-threading
- erm.. there's more but it's a friday evening and this week has pretty much burned my brain out.
Okay, i have a slight update to make which will provide a dialog letting the user know that the program is running & not freeze up (very slight multi threading), but there is ONE problem.
when i checked out the latest revision (44), there is a problem with the GUI for jVioletMainView. it for some reason has a problem with imageControls1; and i cant change anything to the file w/o it deleting that instance & will only let me add it back in progmaticaly. this dosent change the functionality of the program any, but i was wondering if you could confirm this problem on your side before i commit.
when i checked out the latest revision (44), there is a problem with the GUI for jVioletMainView. it for some reason has a problem with imageControls1; and i cant change anything to the file w/o it deleting that instance & will only let me add it back in progmaticaly. this dosent change the functionality of the program any, but i was wondering if you could confirm this problem on your side before i commit.
Yes i know, my spelling sucks
eman7613
I know about the jVioletMainView problem, indeed I created it. I'll explain...
I customised the code for the creation of imageControls1 to pass (this) in the constructor.
in jVioletMainView:
in ImageControls:
I did this so that the imageControl's Apply button can call back to jVioletMainView's process() method.
Netbeans seems to have a problem with this, probably because each of jVioletMainView and ImageControls now somewhat depend on each other.
I left it like this for now though because it works, but I kinda assume that because it causes problems, there's probably a different (more elegant) way to implement it ??
I dunno, I'm the Java n00b
I know about the jVioletMainView problem, indeed I created it. I'll explain...
I customised the code for the creation of imageControls1 to pass (this) in the constructor.
in jVioletMainView:
Code: Select all
ImageControls imageControls1 = new ImageControls(this)
Code: Select all
public ImageControls(jVioletMainView parent)
{
..
}
Netbeans seems to have a problem with this, probably because each of jVioletMainView and ImageControls now somewhat depend on each other.
I left it like this for now though because it works, but I kinda assume that because it causes problems, there's probably a different (more elegant) way to implement it ??
I dunno, I'm the Java n00b
didnt even notice that >.<, silly me. Okay, ive fixed it up. isntead of taking the main class as an argument, it now takes a Runnable object, and runs it when the button is pushed. Just did some minor stuff as im not sure were everything is pointing and i dont feel like rummaging through it.
the GUI will now be nice and responsive when the user does stuff.
edit: commited, Revision 45, just read the commit note im lazy
the GUI will now be nice and responsive when the user does stuff.
edit: commited, Revision 45, just read the commit note im lazy
Yes i know, my spelling sucks
re: where is everything pointing...
The GUI is as you wrote it except for the following:
- I removed the custom actionListeners and used bindings.
(known problem: the textfields don't update the sliders)
- I added data models to each GUICompenent, and various getX() methods to pass the models around the app
- A few layout tweaks
The full model layout is:
- each GUIComponent (the ones that contain controls, not the composite ones) which represents an image processing function has a XXParams class as it's data model, and an updateModel() method that updates the model when the controls are moved/changed.
- ImageThreadParams also contains a copy of all these model classes.
- Both jVioletMainView and ImageThread contain instances of ImageThreadParams
- jVioletMainView contains a routine to get all the Params from the GUI models and stuff them into it's own copy of ImageThreadParams
- when starting ImageThread(s) jVioletMainView passes all Params at once to the ImageThread(s), via ImageThreadParams itp.
- the ImageThread(s) use passes parts of the params to the other processing classes and invokes them as necessary.
That's pretty much it. Ask me if you want details on any specific stuff explained if you don't want to figure it out yourself.
The GUI is as you wrote it except for the following:
- I removed the custom actionListeners and used bindings.
(known problem: the textfields don't update the sliders)
- I added data models to each GUICompenent, and various getX() methods to pass the models around the app
- A few layout tweaks
The full model layout is:
- each GUIComponent (the ones that contain controls, not the composite ones) which represents an image processing function has a XXParams class as it's data model, and an updateModel() method that updates the model when the controls are moved/changed.
- ImageThreadParams also contains a copy of all these model classes.
- Both jVioletMainView and ImageThread contain instances of ImageThreadParams
- jVioletMainView contains a routine to get all the Params from the GUI models and stuff them into it's own copy of ImageThreadParams
- when starting ImageThread(s) jVioletMainView passes all Params at once to the ImageThread(s), via ImageThreadParams itp.
- the ImageThread(s) use passes parts of the params to the other processing classes and invokes them as necessary.
That's pretty much it. Ask me if you want details on any specific stuff explained if you don't want to figure it out yourself.
... why? the image processing isnt changing any of the values set by the user, so therese no need for that kind of saftey. It is doing that somewhere?dougal2 wrote:The GUI is as you wrote it except for the following:
- I removed the custom actionListeners and used bindings.
(known problem: the textfields don't update the sliders)
Yes i know, my spelling sucks
I did it mainly to find out how to Please remember that I'm using this project mostly for learning Java, so I might tweak things or use features just so that I can work out how to.
Also, (and I admit this is a very minor point that could have been fixed by other means) I didn't like the way that the text fields started with trailing zeros, ie 0.100 but the sliders didn't format the numbers like that.
In all honesty, I might revert back to the actionListener method so that I can learn how to do that too. (I'll use your earlier code as reference).
REV 46
1) made runnable for copyRenderedImageToDisplay into proper subclass iDisplay, which allows for:
2) implemented proper CountdownLatch and .await() in IndigoImage::doProcess() for both ImageThread and iDisplay
(also using a thread Executor, which may allow for thread control in the future if necessary).
TODO:
Each processing class in ImageThread needs careful attention to multithreadimg capabilities now, then we can let it run at max. threads.
Also, (and I admit this is a very minor point that could have been fixed by other means) I didn't like the way that the text fields started with trailing zeros, ie 0.100 but the sliders didn't format the numbers like that.
In all honesty, I might revert back to the actionListener method so that I can learn how to do that too. (I'll use your earlier code as reference).
REV 46
1) made runnable for copyRenderedImageToDisplay into proper subclass iDisplay, which allows for:
2) implemented proper CountdownLatch and .await() in IndigoImage::doProcess() for both ImageThread and iDisplay
(also using a thread Executor, which may allow for thread control in the future if necessary).
TODO:
Each processing class in ImageThread needs careful attention to multithreadimg capabilities now, then we can let it run at max. threads.
REV 48
Made the Cancel button work to allow interrupt of processing threads.
oh, and one little thing (and I'm trying desparately to avoid doing this myself) - when committing can you please NOT commit any files from the nbproject/ folder, especially private.properties and project.properties. They ALWAYS conflict, are highly system-specific and don't actually affect the updates of new code. Cheers
Made the Cancel button work to allow interrupt of processing threads.
oh, and one little thing (and I'm trying desparately to avoid doing this myself) - when committing can you please NOT commit any files from the nbproject/ folder, especially private.properties and project.properties. They ALWAYS conflict, are highly system-specific and don't actually affect the updates of new code. Cheers
Who is online
Users browsing this forum: No registered users and 1 guest