Hi,
I've looked over the code, and i think i understood how it works. Ok.
Now some things that i think should be done before going further (just a few
hints):
- FileExplorer should extend JPanel. JSplitPanel will be a component in it.
Will need a toolbar, a statusbar, etc.
- DirectoryModel isn't right. Must be able to support dinamic changing of
columns. I thought maybe an array with columns or a vector.
- I see that you've thought to bring internet support to the application.
That's cool, but will require a little bit of more work.
- A settings file will be a must. The application will need to be
customizable in some way, and the settings to be stored somewhere.
Bottom line: it's fine, not a big deal, but it's fine. The ideea will be
to try to offer something that others do not. It's hard nowdays with so many
file explorers, but not impossible. A good structure and then the coding
part will be easy.
What jdk you've thought the application will need?
Java knows natively how to work with zip archives. Will be cool if we could
support this. This anyway will require a little bit different structure,
just to support modules of some kind. If someone decides to support tar.gz
or .rar archives, it must be easy to write one.
Tell me what you think.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Don't think to bad of mine.
You did not say anything in that direction and I see you are very polite by saying
"Bottom line: it's fine, not a big deal, but it's fine."
I know that it is even not fine.
It is only the sample from sun extended by some things taken from the JFileChooser
to be able to have a starting point that relies on the platform specificas.
It is a very small start.
I would have never started with it, if I found something similar in any open source library.
But I didn't find it and I thought, that a lot of people have the need for such thing.
So lets put them together in this project. Thats why I started.
You wrote:
> The ideea will be to try to offer something that others do not.
> It's hard nowdays with so many
> file explorers, but not impossible. A good structure and then the coding
> part will be easy.
I am completly with you in that we should bring out something that others do not and that
there are already a lot of FileExplorers out there.
Therefore to bring out another file explorer is not my main goal.
I want a framework, that someone can use when he needs it as feature in his application,
which is written in Java and as I wrote at the beginning, there exists no (open source)
file explorer in java
Having a full functional standalone file explorer should be delivered as a usage sample of
this framework.
I think making it a framework first with well defined interfaces is in your spirit.
---------
> - FileExplorer should extend JPanel. JSplitPanel will be a component in it.
> Will need a toolbar, a statusbar, etc.
The toolbar and the statusbar are something we have to think about deeply, if the JFileExplorer
is used as a framework.
The info for what to display has to come from the JFileExplorer, but the areas will be set up by
the application that uses it.
---
>- DirectoryModel isn't right. Must be able to support dynamic changing of
> columns. I thought maybe an array with columns or a vector.
absolutly correct!
The DirectoryModel has to be much more configurable.
---
>- I see that you've thought to bring internet support to the application.
>That's cool, but will require a little bit of more work.
Sorry, I don't what internet support I am thinking of.
Of course, it would be a nice feature for the next release.
I think, that we are on the same in that way, that we have internet support in our mind
when we design, but will doing it in a later release.
---
> - A settings file will be a must. The application will need to be
> customizable in some way, and the settings to be stored somewhere.
You are right settings are a must.
Storing it in a file and loading from there should be supported, too.
I am thinking of a JFileExplorerSettings class. This should be serializable in the first step.
Storing to XML could be another option (maybe by using the new data binding mechanism introduced by SUN).
---
> What jdk you've thought the application will need?
JDK 1.3 upward should be supported.
---
> Java knows natively how to work with zip archives. Will be cool if we could
> support this. This anyway will require a little bit different structure,
> just to support modules of some kind. If someone decides to support tar.gz
> or .rar archives, it must be easy to write one.
> Tell me what you think.
Thats, great.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am sorry. I was wrong. I thought that u would like to make an application, not a component, that somebody would use in an application. Wow, this idea requires a little bit of another thinking of classes, how do they interact, etc. As a component it should be much much smaller, easily extensible, etc. Give me a little time please, to think about it. first i think we should draw a picture about how we would like it to look like, then make a discussion about implementing. I, honestly, don't like the look and feel right now, but i don't have any ideas for now.
I think it should be more like a dialog of some kind, not with all the stuff that i first thought of. Even the settings file isn't a must anymore. The programmer should do the configuration. A little time please.
P.S. If u have any ideas, please tell me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
at first I'd like to introduce myself: I'm Michael, an 18-year-old German student, and I was recently added as developer to this project by Horst due to my requests for further information on this file explorer. And here I am (without even having seen the source code, but I'll see it through the next days):
Toolbar and statusbar: we should provide a set of actions (javax.swing.Action implementations) which can be taken over by an application and then shown as a menu item or a toolbar button.
But the main thing that bothers me (and that for a pretty long time, long before I read of JFileExplorer) is that we won't be able to add listeners or something similar to the operating system to monitor file creation or file deletion operations, so that the user will be forced to update the view periodically - not very nice, isn't it?
Thats all for now, folks
bye
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
No you won't be able to monitor system's files, even if the user has the right to at least read some files, but you just can't go so deep in the OS in Java. It may be possible if we would write some native code, but i do not quite agree with that. After you look at the code, could you please come up with some idea about the design of the component? How it should look like? Being a component it should be small (in my opinion), but right now i don't have any idea about a l&f.
Bye.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have an idea concerning the monitoring of file creations and file deletions: When the component is initialized, a background daemon thread starts which then periodically checks whether the displayed files are still existing and whether there are new files. If any change occured, the view is updated.
And by the way: I highly recommend that the data retrieval, that is the directory scans, takes place in another background thread not affecting the event dispatch thread, otherwise the component will take an arbitrary amount of time to load, if you have slow file / network systems.
I love multithreading :-)
And still by the way: I hate native code comingling with Java - please try to avoid this wherever you can! (so far concerning monitoring)
Concerning the look: I think Horst has some nice ideas. Lets wait what he thinks about it.
Good night, Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The background daemon is a good idea!
But I think he should only work, when the file explorer has the focus.
Best would be if this is a configurable flag.
About the look:
The only idea I have, is that we should use the same icons as the JFileChooser.
Don't know what other ideas about look I shall have?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I disagree in what concerns the daemon thread: Imagine a user returning to the file explorer component after having worked a litte with his application; he now wants to proceed and chooses a different file from the file list and realizes surprisingly that it doesn't exist anylonger and is only removed from the file list when he clicks on it. Therefor I said that the daemon thread should run permanently but the view should only be updated whenever changes occur so that the event dispatch thread won't be that overloaded.
I am just about to study the source code and I notices some things that disturbed me - in what concerns coding I am a very accurate person, you have to know.
1. Due to file explorer being a lightweigt (swing) component we should rename it to "JFileExplorer"
2. Why is the file selection in the file table limited to SINGLE_SELECTION_MODE? It should be MULTIPLE_INTERVAL_SELECTION as it is in many other file explorers, too.
3. The method "private void getChilds()" in class "RootDirNode" and in class "DirNode" is misspelled: It should be "private void getChildren()".
4. The flag "rowcount" in class "DirectoryModel" is not necessary, the number of rows can be obtained by the state and the method "public int size()" of the Array "children".
5. The method "public void setDirectory(Object)" in class "DirectoryModel" should have a counterpart in bean-style: "public Object getDirectory()".
6. The first column of the file table should not be labeled, as long as it contains file icons (the user will be used to icons showing the file type, we needn't explain what is self-explanatory).
7. The third column of the file table should be entitled "Size" rather that "Bytes".
8. The method "public Class getColumnClass(int)" in class "DirectoryModel" should not return process values as long as the number of columns and the kind of their content is constant, so omit method calls here and return just classes. The execution time of this method will then be reduced.
9. The method call "super.getTableCellRendererComponent(JTable,Object,boolean,boolean,int,int)" in class "DirectoryRenderer" in method "public Component getTableCellRendererComponent(JTable,Object,boolean,boolean,int,int)" is useless because the returned value is not stored anywhere.
10. The method "public String toString()" in class "DirNode" should return "ivDir.getName()" rather than "ivDir.getPath()" otherwise the directory's full path will be displayed in the folder tree rather than the folder name.
11. The field declaration and initialization statement "File file=null" in class "DirNode" in method "private void getChilds()" is not necessary.
12. Class "FileExplorerBeanInfo" seems to be incomplete or just an example bean info.
For now this is all I found concerning the source code. I am not quite sure about some theoretical things (i.e. the data models, the renderes, etc.) but I will immediately pass it to you if I have something definite.
best regards, Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First about the thread:
I don't want to use cpu-time if the application is not in the foreground
A lot of fileexploreres start looking at the directory just when the get back the focus.
For a normal filesystem the response is ok for me that way.
What's the opinion of the others?
I thought I am accurate, too!
Seems I have to adjust this selfassessement.
1. Do you mean the package name?
Because even the swing packages are without a "J". and the component is named JFileExplorer.
2. The selection model should be a setable flag.
3. I will correct the spelling to getChildren.
To get a fast entry I copied the directory model from the sun example.
Seems there have to be done some rework.
4. Ok, corrected.
5. Ok, corrected.
6. Ok, corrected.
7. Ok, corrected.
8. Ok, corrected.
9. Ok, corrected.
10. toString() in DirNode returns the name, only if the name is empty (For the drives) the path is returned.
11. Ok, corrected.
12. The BeanInfo is generated by JBuilder. I don't want to ship it as a bean by now. It is to early. So please ignore it.
Thanks for your comments!
best regards, Horst
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm sorry, but it seems as if I've tried to be a little too accurate, but I still have some things in mind concerning my first criticisms:
1. I meant the class name of course, because in the source code I downloaded, it is "FileExplorer" - no J at the beginning.
2. I agree.
10. Sorry, seems as if I rushed too fast through the code - you're right of course!
I am still thinking about some things and I'll inform you...
best regards, Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I've looked over the code, and i think i understood how it works. Ok.
Now some things that i think should be done before going further (just a few
hints):
- FileExplorer should extend JPanel. JSplitPanel will be a component in it.
Will need a toolbar, a statusbar, etc.
- DirectoryModel isn't right. Must be able to support dinamic changing of
columns. I thought maybe an array with columns or a vector.
- I see that you've thought to bring internet support to the application.
That's cool, but will require a little bit of more work.
- A settings file will be a must. The application will need to be
customizable in some way, and the settings to be stored somewhere.
Bottom line: it's fine, not a big deal, but it's fine. The ideea will be
to try to offer something that others do not. It's hard nowdays with so many
file explorers, but not impossible. A good structure and then the coding
part will be easy.
What jdk you've thought the application will need?
Java knows natively how to work with zip archives. Will be cool if we could
support this. This anyway will require a little bit different structure,
just to support modules of some kind. If someone decides to support tar.gz
or .rar archives, it must be easy to write one.
Tell me what you think.
Don't think to bad of mine.
You did not say anything in that direction and I see you are very polite by saying
"Bottom line: it's fine, not a big deal, but it's fine."
I know that it is even not fine.
It is only the sample from sun extended by some things taken from the JFileChooser
to be able to have a starting point that relies on the platform specificas.
It is a very small start.
I would have never started with it, if I found something similar in any open source library.
But I didn't find it and I thought, that a lot of people have the need for such thing.
So lets put them together in this project. Thats why I started.
You wrote:
> The ideea will be to try to offer something that others do not.
> It's hard nowdays with so many
> file explorers, but not impossible. A good structure and then the coding
> part will be easy.
I am completly with you in that we should bring out something that others do not and that
there are already a lot of FileExplorers out there.
Therefore to bring out another file explorer is not my main goal.
I want a framework, that someone can use when he needs it as feature in his application,
which is written in Java and as I wrote at the beginning, there exists no (open source)
file explorer in java
Having a full functional standalone file explorer should be delivered as a usage sample of
this framework.
I think making it a framework first with well defined interfaces is in your spirit.
---------
> - FileExplorer should extend JPanel. JSplitPanel will be a component in it.
> Will need a toolbar, a statusbar, etc.
The toolbar and the statusbar are something we have to think about deeply, if the JFileExplorer
is used as a framework.
The info for what to display has to come from the JFileExplorer, but the areas will be set up by
the application that uses it.
---
>- DirectoryModel isn't right. Must be able to support dynamic changing of
> columns. I thought maybe an array with columns or a vector.
absolutly correct!
The DirectoryModel has to be much more configurable.
---
>- I see that you've thought to bring internet support to the application.
>That's cool, but will require a little bit of more work.
Sorry, I don't what internet support I am thinking of.
Of course, it would be a nice feature for the next release.
I think, that we are on the same in that way, that we have internet support in our mind
when we design, but will doing it in a later release.
---
> - A settings file will be a must. The application will need to be
> customizable in some way, and the settings to be stored somewhere.
You are right settings are a must.
Storing it in a file and loading from there should be supported, too.
I am thinking of a JFileExplorerSettings class. This should be serializable in the first step.
Storing to XML could be another option (maybe by using the new data binding mechanism introduced by SUN).
---
> What jdk you've thought the application will need?
JDK 1.3 upward should be supported.
---
> Java knows natively how to work with zip archives. Will be cool if we could
> support this. This anyway will require a little bit different structure,
> just to support modules of some kind. If someone decides to support tar.gz
> or .rar archives, it must be easy to write one.
> Tell me what you think.
Thats, great.
Further features:
- directories in the table (right)
should be a flag
- setting a filter for the table
Typically an application wants to show the related files.
Therefore a filter should be setable.
- A flag for allowing the filter to be user editable
I am sorry. I was wrong. I thought that u would like to make an application, not a component, that somebody would use in an application. Wow, this idea requires a little bit of another thinking of classes, how do they interact, etc. As a component it should be much much smaller, easily extensible, etc. Give me a little time please, to think about it. first i think we should draw a picture about how we would like it to look like, then make a discussion about implementing. I, honestly, don't like the look and feel right now, but i don't have any ideas for now.
I think it should be more like a dialog of some kind, not with all the stuff that i first thought of. Even the settings file isn't a must anymore. The programmer should do the configuration. A little time please.
P.S. If u have any ideas, please tell me.
hi there,
at first I'd like to introduce myself: I'm Michael, an 18-year-old German student, and I was recently added as developer to this project by Horst due to my requests for further information on this file explorer. And here I am (without even having seen the source code, but I'll see it through the next days):
Toolbar and statusbar: we should provide a set of actions (javax.swing.Action implementations) which can be taken over by an application and then shown as a menu item or a toolbar button.
But the main thing that bothers me (and that for a pretty long time, long before I read of JFileExplorer) is that we won't be able to add listeners or something similar to the operating system to monitor file creation or file deletion operations, so that the user will be forced to update the view periodically - not very nice, isn't it?
Thats all for now, folks
bye
Hi,
No you won't be able to monitor system's files, even if the user has the right to at least read some files, but you just can't go so deep in the OS in Java. It may be possible if we would write some native code, but i do not quite agree with that. After you look at the code, could you please come up with some idea about the design of the component? How it should look like? Being a component it should be small (in my opinion), but right now i don't have any idea about a l&f.
Bye.
hi again,
I have an idea concerning the monitoring of file creations and file deletions: When the component is initialized, a background daemon thread starts which then periodically checks whether the displayed files are still existing and whether there are new files. If any change occured, the view is updated.
And by the way: I highly recommend that the data retrieval, that is the directory scans, takes place in another background thread not affecting the event dispatch thread, otherwise the component will take an arbitrary amount of time to load, if you have slow file / network systems.
I love multithreading :-)
And still by the way: I hate native code comingling with Java - please try to avoid this wherever you can! (so far concerning monitoring)
Concerning the look: I think Horst has some nice ideas. Lets wait what he thinks about it.
Good night, Michael
The background daemon is a good idea!
But I think he should only work, when the file explorer has the focus.
Best would be if this is a configurable flag.
About the look:
The only idea I have, is that we should use the same icons as the JFileChooser.
Don't know what other ideas about look I shall have?
hi there,
I disagree in what concerns the daemon thread: Imagine a user returning to the file explorer component after having worked a litte with his application; he now wants to proceed and chooses a different file from the file list and realizes surprisingly that it doesn't exist anylonger and is only removed from the file list when he clicks on it. Therefor I said that the daemon thread should run permanently but the view should only be updated whenever changes occur so that the event dispatch thread won't be that overloaded.
I am just about to study the source code and I notices some things that disturbed me - in what concerns coding I am a very accurate person, you have to know.
1. Due to file explorer being a lightweigt (swing) component we should rename it to "JFileExplorer"
2. Why is the file selection in the file table limited to SINGLE_SELECTION_MODE? It should be MULTIPLE_INTERVAL_SELECTION as it is in many other file explorers, too.
3. The method "private void getChilds()" in class "RootDirNode" and in class "DirNode" is misspelled: It should be "private void getChildren()".
4. The flag "rowcount" in class "DirectoryModel" is not necessary, the number of rows can be obtained by the state and the method "public int size()" of the Array "children".
5. The method "public void setDirectory(Object)" in class "DirectoryModel" should have a counterpart in bean-style: "public Object getDirectory()".
6. The first column of the file table should not be labeled, as long as it contains file icons (the user will be used to icons showing the file type, we needn't explain what is self-explanatory).
7. The third column of the file table should be entitled "Size" rather that "Bytes".
8. The method "public Class getColumnClass(int)" in class "DirectoryModel" should not return process values as long as the number of columns and the kind of their content is constant, so omit method calls here and return just classes. The execution time of this method will then be reduced.
9. The method call "super.getTableCellRendererComponent(JTable,Object,boolean,boolean,int,int)" in class "DirectoryRenderer" in method "public Component getTableCellRendererComponent(JTable,Object,boolean,boolean,int,int)" is useless because the returned value is not stored anywhere.
10. The method "public String toString()" in class "DirNode" should return "ivDir.getName()" rather than "ivDir.getPath()" otherwise the directory's full path will be displayed in the folder tree rather than the folder name.
11. The field declaration and initialization statement "File file=null" in class "DirNode" in method "private void getChilds()" is not necessary.
12. Class "FileExplorerBeanInfo" seems to be incomplete or just an example bean info.
For now this is all I found concerning the source code. I am not quite sure about some theoretical things (i.e. the data models, the renderes, etc.) but I will immediately pass it to you if I have something definite.
best regards, Michael
First about the thread:
I don't want to use cpu-time if the application is not in the foreground
A lot of fileexploreres start looking at the directory just when the get back the focus.
For a normal filesystem the response is ok for me that way.
What's the opinion of the others?
I thought I am accurate, too!
Seems I have to adjust this selfassessement.
1. Do you mean the package name?
Because even the swing packages are without a "J". and the component is named JFileExplorer.
2. The selection model should be a setable flag.
3. I will correct the spelling to getChildren.
To get a fast entry I copied the directory model from the sun example.
Seems there have to be done some rework.
4. Ok, corrected.
5. Ok, corrected.
6. Ok, corrected.
7. Ok, corrected.
8. Ok, corrected.
9. Ok, corrected.
10. toString() in DirNode returns the name, only if the name is empty (For the drives) the path is returned.
11. Ok, corrected.
12. The BeanInfo is generated by JBuilder. I don't want to ship it as a bean by now. It is to early. So please ignore it.
Thanks for your comments!
best regards, Horst
Hi,
I'm sorry, but it seems as if I've tried to be a little too accurate, but I still have some things in mind concerning my first criticisms:
1. I meant the class name of course, because in the source code I downloaded, it is "FileExplorer" - no J at the beginning.
2. I agree.
10. Sorry, seems as if I rushed too fast through the code - you're right of course!
I am still thinking about some things and I'll inform you...
best regards, Michael
ad 1) I will correct this