FileList2 has both #listForPattern: and #listForPatterns: I cannot find any usage of the #listForPattern: and it also looks like it might be a left over from some EToys experiment. Given the possibilities of confusion between the tow I’d prefer to remove it.
Both methods also try to handle having the fileSelectionBlock be a MessagesSend, and do it horribly. Using #isKindOf: is not a nice thing. a) I can’t find any place where a MessageSend is actually meaningfully used except an EToys method where a Block would be at least as good and easier to understand, so why even have the option? b) the usage seems poor - why set the arguments, evaluate the MS and then empty the arguments instead of simply treating it as a Block? I might be missing some subtlety of MessageSend I suppose, but given the mess of code in that class I wouldn’t be surprised.
Does anyone know why we shouldn’t remove #listForPattern: and clean out the (mis)use of MessageSend in #listForPatterns: ?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Two wrongs are only the beginning.
FWIW, #listForPattern: was the original method many moons ago. FileList had one version and then FileList2 had another that was more attuned to EToys. The plural patterns version came along sometime after 2001.
On 10/3/17 3:59 PM, tim Rowledge wrote:
FileList2 has both #listForPattern: and #listForPatterns: I cannot find any usage of the #listForPattern: and it also looks like it might be a left over from some EToys experiment. Given the possibilities of confusion between the tow I’d prefer to remove it.
Both methods also try to handle having the fileSelectionBlock be a MessagesSend, and do it horribly. Using #isKindOf: is not a nice thing. a) I can’t find any place where a MessageSend is actually meaningfully used except an EToys method where a Block would be at least as good and easier to understand, so why even have the option? b) the usage seems poor - why set the arguments, evaluate the MS and then empty the arguments instead of simply treating it as a Block? I might be missing some subtlety of MessageSend I suppose, but given the mess of code in that class I wouldn’t be surprised.
Does anyone know why we shouldn’t remove #listForPattern: and clean out the (mis)use of MessageSend in #listForPatterns: ?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Two wrongs are only the beginning.
On 03-10-2017, at 12:59 PM, tim Rowledge tim@rowledge.org wrote:
[snip everything but the randomly chosen sigline]
Two wrongs are only the beginning.
Too true in this case. As I look through and trace the code involved in FileList and it’s subclasses I’m struck (forcefully) by the amazing appallingness of it.
Some highlights of the horror movie -
- FileList is referred to in 70 places, FileList2 in 33. Which one is meant to be our standard UI for files? No idea. - When opening a default FileList (from the dock menu for example) the contents of the default directory are read and processed twice. This may not seem a big deal, unless perhaps you have a thousand or more files in a directory, or your default directory is across a network, or you machine is slow etc. It’s stupid, whatever. - A FileList2 seems to double that stupidity. - There are strange artefacts of what looks like partial attempts to hack in EToys support, left to bitrot. - Why would a FileList be a subclass of StringHolder? - A default FileList is built via the ToolBuilder. FileList2 adds a load of non-TB ways to build. - The look of different variants of secondary dialogues built from FileList* vary wildly. Some have rounded blue frames. Some look like ‘normal’ windows. - Some variants show a directory hierarchy by adding spaces in front of path elements. Others use a hierarchy displaying morph. The space-formatted list is built even when not needed. - FileChooser adds yet another layer of ‘interest’ but appears totally unused. - PluggableFileList appears to only actually get used within MVC world, which is just as well since the morph version is rather ugly; it also seems to be only referred to usefully from StandardFileMenu, which makes an especially odd thing since the code reads as asking for a menu and you get a dialogue/window. And in some places the code alternately requests a StandardFileMenu and a FileList! Talk about causing confusion. As an extra bit of fun, the fact that it got squeezed into place as if a menu means that it has to implement assorted menu messages like #startUpWithCaption:
I think we’re probably at the point where a completely new file accessing model is needed in order to try to obsolete this nest of nightmares. Unless, of course, someone can point to a nice replacement already written and functional?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RLB: Ruin Logic Board
Thank you for the analysis, Tim.
Noteworthy that FileList2 has a class comment from 2003. http://wiki.squeak.org/squeak/2379
But it seems FileList2 goes back at least to version 3.0 (screen shot). It seems it was introduced as an experiment for extending FileList and then later was never fully integrated.
As FileList is built via the ToolBuilder it seems worthwile to focus on extending that and get rid of FileList2.
--Hannes
On 10/5/17, tim Rowledge tim@rowledge.org wrote:
On 03-10-2017, at 12:59 PM, tim Rowledge tim@rowledge.org wrote:
[snip everything but the randomly chosen sigline]
Two wrongs are only the beginning.
Too true in this case. As I look through and trace the code involved in FileList and it’s subclasses I’m struck (forcefully) by the amazing appallingness of it.
Some highlights of the horror movie -
- FileList is referred to in 70 places, FileList2 in 33. Which one is meant
to be our standard UI for files? No idea.
- When opening a default FileList (from the dock menu for example) the
contents of the default directory are read and processed twice. This may not seem a big deal, unless perhaps you have a thousand or more files in a directory, or your default directory is across a network, or you machine is slow etc. It’s stupid, whatever.
- A FileList2 seems to double that stupidity.
- There are strange artefacts of what looks like partial attempts to hack
in EToys support, left to bitrot.
- Why would a FileList be a subclass of StringHolder?
- A default FileList is built via the ToolBuilder. FileList2 adds a load of
non-TB ways to build.
- The look of different variants of secondary dialogues built from
FileList* vary wildly. Some have rounded blue frames. Some look like ‘normal’ windows.
- Some variants show a directory hierarchy by adding spaces in front of
path elements. Others use a hierarchy displaying morph. The space-formatted list is built even when not needed.
- FileChooser adds yet another layer of ‘interest’ but appears totally
unused.
- PluggableFileList appears to only actually get used within MVC world,
which is just as well since the morph version is rather ugly; it also seems to be only referred to usefully from StandardFileMenu, which makes an especially odd thing since the code reads as asking for a menu and you get a dialogue/window. And in some places the code alternately requests a StandardFileMenu and a FileList! Talk about causing confusion. As an extra bit of fun, the fact that it got squeezed into place as if a menu means that it has to implement assorted menu messages like #startUpWithCaption:
I think we’re probably at the point where a completely new file accessing model is needed in order to try to obsolete this nest of nightmares. Unless, of course, someone can point to a nice replacement already written and functional?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RLB: Ruin Logic Board
And there is no FileList2 in Pharo.
On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:
Thank you for the analysis, Tim.
Noteworthy that FileList2 has a class comment from 2003. http://wiki.squeak.org/squeak/2379
But it seems FileList2 goes back at least to version 3.0 (screen shot). It seems it was introduced as an experiment for extending FileList and then later was never fully integrated.
As FileList is built via the ToolBuilder it seems worthwile to focus on extending that and get rid of FileList2.
--Hannes
On 10/5/17, tim Rowledge tim@rowledge.org wrote:
On 03-10-2017, at 12:59 PM, tim Rowledge tim@rowledge.org wrote:
[snip everything but the randomly chosen sigline]
Two wrongs are only the beginning.
Too true in this case. As I look through and trace the code involved in FileList and it’s subclasses I’m struck (forcefully) by the amazing appallingness of it.
Some highlights of the horror movie -
- FileList is referred to in 70 places, FileList2 in 33. Which one is
meant to be our standard UI for files? No idea.
- When opening a default FileList (from the dock menu for example) the
contents of the default directory are read and processed twice. This may not seem a big deal, unless perhaps you have a thousand or more files in a directory, or your default directory is across a network, or you machine is slow etc. It’s stupid, whatever.
- A FileList2 seems to double that stupidity.
- There are strange artefacts of what looks like partial attempts to
hack in EToys support, left to bitrot.
- Why would a FileList be a subclass of StringHolder?
- A default FileList is built via the ToolBuilder. FileList2 adds a load
of non-TB ways to build.
- The look of different variants of secondary dialogues built from
FileList* vary wildly. Some have rounded blue frames. Some look like ‘normal’ windows.
- Some variants show a directory hierarchy by adding spaces in front of
path elements. Others use a hierarchy displaying morph. The space-formatted list is built even when not needed.
- FileChooser adds yet another layer of ‘interest’ but appears totally
unused.
- PluggableFileList appears to only actually get used within MVC world,
which is just as well since the morph version is rather ugly; it also seems to be only referred to usefully from StandardFileMenu, which makes an especially odd thing since the code reads as asking for a menu and you get a dialogue/window. And in some places the code alternately requests a StandardFileMenu and a FileList! Talk about causing confusion. As an extra bit of fun, the fact that it got squeezed into place as if a menu means that it has to implement assorted menu messages like #startUpWithCaption:
I think we’re probably at the point where a completely new file accessing model is needed in order to try to obsolete this nest of nightmares. Unless, of course, someone can point to a nice replacement already written and functional?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RLB: Ruin Logic Board
It was an experiment from the summer of 2000. It was where expandable hierarchical directory lists were added. It also added some features that were wanted in EToys at the time. Some time later, some of its features were rolled back into FileList.
Change Set: multiProjects4 Date: 16 June 2000 Author: Bob Arning
- introducing some FileList variants using hierarchical lists. The main reason is to create some simplified file locators for loading projects, but you may want to use this in other circumstances as well.
On 10/4/17 7:48 PM, H. Hirzel wrote:
Noteworthy that FileList2 has a class comment from 2003. http://wiki.squeak.org/squeak/2379
But it seems FileList2 goes back at least to version 3.0 (screen shot). It seems it was introduced as an experiment for extending FileList and then later was never fully integrated.
On 04-10-2017, at 5:26 PM, Bob Arning arning315@comcast.net wrote:
It was an experiment from the summer of 2000. It was where expandable hierarchical directory lists were added. It also added some features that were wanted in EToys at the time. Some time later, some of its features were rolled back into FileList.
Thanks Bob. I’m glad someone can remember that far back!
Don’t suppose you recall anything about why it is subclassed from StringHolder? That really does seem odd...
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Computer and car salesmen differ in that the latter know when they are lying.
On 10/4/17 9:27 PM, tim Rowledge wrote:
On 04-10-2017, at 5:26 PM, Bob Arning arning315@comcast.net wrote:
It was an experiment from the summer of 2000. It was where expandable hierarchical directory lists were added. It also added some features that were wanted in EToys at the time. Some time later, some of its features were rolled back into FileList.
Thanks Bob. I’m glad someone can remember that far back!
Doesn't take remembering - just open up a 2.9 image.
Don’t suppose you recall anything about why it is subclassed from StringHolder? That really does seem odd...
Well, the whole point is to provide a view of the contents of a file which you can read, edit and save. The rest is just how to get that content in the first place. So, it's a StringHolder with some extra buttons attached.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Computer and car salesmen differ in that the latter know when they are lying.
On 04-10-2017, at 6:48 PM, Bob Arning arning315@comcast.net wrote:
Well, the whole point is to provide a view of the contents of a file which you can read, edit and save. The rest is just how to get that content in the first place. So, it's a StringHolder with some extra buttons attached.
Ah, right, as previously mentioned a case of is-a or has-a. I much prefer has-a myself.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: New classic
I note that most references to FileList are for registering/unregistering a specific tool as a service for a specific fileType... So the goal is to make file services modular/pluggable/extendable. What I don't understand is that FileList seems to duplicate FileServices code (see for example implementors of #registerFileReader)... And that there is a random mixture of usage:
ChangeList class>>initialize FileList registerFileReader: self
ChangeSet class>>initialize "ChangeSet initialize" AllChangeSets == nil ifTrue: [AllChangeSets := OrderedCollection new]. self gatherChangeSets. FileServices registerFileReader: self.
What do you suggest instead? Who should survive?
P.S.: it seems that we abused a bit of living system metaphor. It's like we wanted to create diversity in order to multiply the chances of squeak to survive ;) Unfortunately, natural selection of code doesn't obey fair rules: - code tends to bloat and complexify over years that could be like our cells that gradually degenerate... - but the worse code (the most complex) tend to survive longer. this is because it becomes more and more complex to change it without breaking features. and breaking features is frowned upon...
In biology, the immune system also help eliminating own degenerated cells. I don't see anything equivalent in Squeak. So the whole organism is in danger if we don't help the bad cells to die ;)
2017-10-05 20:04 GMT+02:00 tim Rowledge tim@rowledge.org:
On 04-10-2017, at 6:48 PM, Bob Arning arning315@comcast.net wrote:
Well, the whole point is to provide a view of the contents of a file
which you can read, edit and save. The rest is just how to get that content in the first place. So, it's a StringHolder with some extra buttons attached.
Ah, right, as previously mentioned a case of is-a or has-a. I much prefer has-a myself.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: New classic
On 10/5/17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I note that most references to FileList are for registering/unregistering a specific tool as a service for a specific fileType... So the goal is to make file services modular/pluggable/extendable. What I don't understand is that FileList seems to duplicate FileServices code (see for example implementors of #registerFileReader)...
FileServices was introduced with Squeak 3.9 in November 2006
http://wiki.squeak.org/squeak/1001
And that there is a random mixture of usage:
ChangeList class>>initialize FileList registerFileReader: self ChangeSet class>>initialize "ChangeSet initialize" AllChangeSets == nil ifTrue: [AllChangeSets := OrderedCollection new]. self gatherChangeSets. FileServices registerFileReader: self.
What do you suggest instead? Who should survive?
P.S.: it seems that we abused a bit of living system metaphor. It's like we wanted to create diversity in order to multiply the chances of squeak to survive ;) Unfortunately, natural selection of code doesn't obey fair rules:
- code tends to bloat and complexify over years that could be like our cells that gradually degenerate...
- but the worse code (the most complex) tend to survive longer. this is because it becomes more and more complex to change it without
breaking features. and breaking features is frowned upon...
In biology, the immune system also help eliminating own degenerated cells. I don't see anything equivalent in Squeak. So the whole organism is in danger if we don't help the bad cells to die ;)
2017-10-05 20:04 GMT+02:00 tim Rowledge tim@rowledge.org:
On 04-10-2017, at 6:48 PM, Bob Arning arning315@comcast.net wrote:
Well, the whole point is to provide a view of the contents of a file
which you can read, edit and save. The rest is just how to get that content in the first place. So, it's a StringHolder with some extra buttons attached.
Ah, right, as previously mentioned a case of is-a or has-a. I much prefer has-a myself.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: New classic
And the registration mechanism in FileServices was intended to replace the one in FileList.
So it is like you buy a new Kenwood and still keep and old blender (or accessory parts of it) around.
It is a matter of putting old things into the dustbin and moving the bin out of the house to be emptied.
And active effort is needed to clean up and this is what people do here all the time. Not a new issue. You have to work on a room by room or shelf by shelf basis.
The question is what to do so that the cleaning task of FileList / FileList2 remains manageable.
On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:
On 10/5/17, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
I note that most references to FileList are for registering/unregistering a specific tool as a service for a specific fileType... So the goal is to make file services modular/pluggable/extendable. What I don't understand is that FileList seems to duplicate FileServices code (see for example implementors of #registerFileReader)...
FileServices was introduced with Squeak 3.9 in November 2006
http://wiki.squeak.org/squeak/1001
And that there is a random mixture of usage:
ChangeList class>>initialize FileList registerFileReader: self ChangeSet class>>initialize "ChangeSet initialize" AllChangeSets == nil ifTrue: [AllChangeSets := OrderedCollection new]. self gatherChangeSets. FileServices registerFileReader: self.
What do you suggest instead? Who should survive?
P.S.: it seems that we abused a bit of living system metaphor. It's like we wanted to create diversity in order to multiply the chances of squeak to survive ;) Unfortunately, natural selection of code doesn't obey fair rules:
- code tends to bloat and complexify over years that could be like our cells that gradually degenerate...
- but the worse code (the most complex) tend to survive longer. this is because it becomes more and more complex to change it without
breaking features. and breaking features is frowned upon...
In biology, the immune system also help eliminating own degenerated cells. I don't see anything equivalent in Squeak. So the whole organism is in danger if we don't help the bad cells to die ;)
2017-10-05 20:04 GMT+02:00 tim Rowledge tim@rowledge.org:
On 04-10-2017, at 6:48 PM, Bob Arning arning315@comcast.net wrote:
Well, the whole point is to provide a view of the contents of a file
which you can read, edit and save. The rest is just how to get that content in the first place. So, it's a StringHolder with some extra buttons attached.
Ah, right, as previously mentioned a case of is-a or has-a. I much prefer has-a myself.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Oxymorons: New classic
On 05-10-2017, at 12:47 PM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
In biology, the immune system also help eliminating own degenerated cells. I don't see anything equivalent in Squeak. So the whole organism is in danger if we don't help the bad cells to die ;)
I fairly often feel like “that would be me” is the answer here.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Braccae illae virides cum subucula rosea et tunica Caledonia-quam elenganter concinnatur! = Those green pants go so well with that pink shirt and the plaid jacket!
We should move to new File system. My choice is Juan Vuletich enhancements of original FileMan. This could be a case for Enviroments , having two file systems at once until all fell confortable with new File system,then rip older and move new out of Enviroments.
On 10/4/17, 20:35, "tim Rowledge" tim@rowledge.org wrote:
Too true in this case. As I look through and trace the code involved in FileList and it¹s subclasses I¹m struck (forcefully) by the amazing appallingness of it.
Some highlights of the horror movie -
- FileList is
referred to in 70 places, FileList2 in 33. Which one is meant to be our standard UI for files? No idea.
- When opening a default FileList (from the
dock menu for example) the contents of the default directory are read and processed twice. This may not seem a big deal, unless perhaps you have a thousand or more files in a directory, or your default directory is across a network, or you machine is slow etc. It¹s stupid, whatever.
- A FileList2
seems to double that stupidity.
- There are strange artefacts of what looks
like partial attempts to hack in EToys support, left to bitrot.
- Why would a
FileList be a subclass of StringHolder?
- A default FileList is built via the
ToolBuilder. FileList2 adds a load of non-TB ways to build.
- The look of
different variants of secondary dialogues built from FileList* vary wildly. Some have rounded blue frames. Some look like normal¹ windows.
- Some
variants show a directory hierarchy by adding spaces in front of path elements. Others use a hierarchy displaying morph. The space-formatted list is built even when not needed.
- FileChooser adds yet another layer of
interest¹ but appears totally unused.
- PluggableFileList appears to only
actually get used within MVC world, which is just as well since the morph version is rather ugly; it also seems to be only referred to usefully from StandardFileMenu, which makes an especially odd thing since the code reads as asking for a menu and you get a dialogue/window. And in some places the code alternately requests a StandardFileMenu and a FileList! Talk about causing confusion. As an extra bit of fun, the fact that it got squeezed into place as if a menu means that it has to implement assorted menu messages like #startUpWithCaption:
I think we¹re probably at the point where a completely
new file accessing model is needed in order to try to obsolete this nest of nightmares. Unless, of course, someone can point to a nice replacement already written and functional?
Hi, there.
We should distinguish between (1) tools for artifacts and (2) the artifacts themselves. That is, cleaning-up FileList and FileList2 is a different challenge than moving to a new file system, which would also need appropriate tools.
Let's not mix those up but keep focus during discussions if possible. ;-)
Best, Marcel Am 05.10.2017 10:47:18 schrieb Edgar J. De Cleene edgardec2005@gmail.com: We should move to new File system. My choice is Juan Vuletich enhancements of original FileMan. This could be a case for Enviroments , having two file systems at once until all fell confortable with new File system,then rip older and move new out of Enviroments.
On 10/4/17, 20:35, "tim Rowledge" wrote:
Too true in this case. As I look through and trace the code involved in FileList and it¹s subclasses I¹m struck (forcefully) by the amazing appallingness of it.
Some highlights of the horror movie -
- FileList is
referred to in 70 places, FileList2 in 33. Which one is meant to be our standard UI for files? No idea.
- When opening a default FileList (from the
dock menu for example) the contents of the default directory are read and processed twice. This may not seem a big deal, unless perhaps you have a thousand or more files in a directory, or your default directory is across a network, or you machine is slow etc. It¹s stupid, whatever.
- A FileList2
seems to double that stupidity.
- There are strange artefacts of what looks
like partial attempts to hack in EToys support, left to bitrot.
- Why would a
FileList be a subclass of StringHolder?
- A default FileList is built via the
ToolBuilder. FileList2 adds a load of non-TB ways to build.
- The look of
different variants of secondary dialogues built from FileList* vary wildly. Some have rounded blue frames. Some look like normal¹ windows.
- Some
variants show a directory hierarchy by adding spaces in front of path elements. Others use a hierarchy displaying morph. The space-formatted list is built even when not needed.
- FileChooser adds yet another layer of
interest¹ but appears totally unused.
- PluggableFileList appears to only
actually get used within MVC world, which is just as well since the morph version is rather ugly; it also seems to be only referred to usefully from StandardFileMenu, which makes an especially odd thing since the code reads as asking for a menu and you get a dialogue/window. And in some places the code alternately requests a StandardFileMenu and a FileList! Talk about causing confusion. As an extra bit of fun, the fact that it got squeezed into place as if a menu means that it has to implement assorted menu messages like #startUpWithCaption:
I think we¹re probably at the point where a completely
new file accessing model is needed in order to try to obsolete this nest of nightmares. Unless, of course, someone can point to a nice replacement already written and functional?
Hello Edgar,
Replacing file access with the FileMan API is another issue. This thread is about the FileList *tool*. [3] .
The FileMan File accessing API may be loaded through SqueakMap (for 5.1, no entry yet for 6.0a).
FileList uses the FileServices registration mechanism [4]. The open task there is that the initialization code does not yet fully do its job [5], [6]. See discussion earlier this year in March in which you took part.
Regards
Hannes
[3] FileList comment:
I am model that can be used to navigate the host file system. By omitting the volume list, file list, and template panes from the view, I can also be used as the model for an editor on an individual file.
The FileList now provides a registration mechanism to which any tools the filelist uses ***MUST*** register. This way it is possible to dynamically load or unload a new tool and have the FileList automatically updated. This change supports a decomposition of Squeak and removes a problem with dead reference to classes after a major shrink.
http://wiki.squeak.org/squeak/1975
------------------------------------------
[4] FileList class registeredFileReaderClasses FileReaderRegistry := nil. "wipe it out" ^FileServices registeredFileReaderClasses
[5] FileServices -- http://wiki.squeak.org/squeak/1001
[6] Which file reader classes are not touched by "FileServices initialize"? -- http://wiki.squeak.org/squeak/1023
On 10/5/17, Edgar J. De Cleene edgardec2005@gmail.com wrote:
We should move to new File system. My choice is Juan Vuletich enhancements of original FileMan. This could be a case for Enviroments , having two file systems at once until all fell confortable with new File system,then rip older and move new out of Enviroments.
On 10/4/17, 20:35, "tim Rowledge" tim@rowledge.org wrote:
Too true in this case. As I look through and trace the code involved in FileList and it¹s subclasses I¹m struck (forcefully) by the amazing appallingness of it.
Some highlights of the horror movie -
- FileList is
referred to in 70 places, FileList2 in 33. Which one is meant to be our standard UI for files? No idea.
- When opening a default FileList (from the
dock menu for example) the contents of the default directory are read and processed twice. This may not seem a big deal, unless perhaps you have a thousand or more files in a directory, or your default directory is across a network, or you machine is slow etc. It¹s stupid, whatever.
- A FileList2
seems to double that stupidity.
- There are strange artefacts of what looks
like partial attempts to hack in EToys support, left to bitrot.
- Why would a
FileList be a subclass of StringHolder?
- A default FileList is built via the
ToolBuilder. FileList2 adds a load of non-TB ways to build.
- The look of
different variants of secondary dialogues built from FileList* vary wildly. Some have rounded blue frames. Some look like Œnormal¹ windows.
- Some
variants show a directory hierarchy by adding spaces in front of path elements. Others use a hierarchy displaying morph. The space-formatted list is built even when not needed.
- FileChooser adds yet another layer of
Œinterest¹ but appears totally unused.
- PluggableFileList appears to only
actually get used within MVC world, which is just as well since the morph version is rather ugly; it also seems to be only referred to usefully from StandardFileMenu, which makes an especially odd thing since the code reads as asking for a menu and you get a dialogue/window. And in some places the code alternately requests a StandardFileMenu and a FileList! Talk about causing confusion. As an extra bit of fun, the fact that it got squeezed into place as if a menu means that it has to implement assorted menu messages like #startUpWithCaption:
I think we¹re probably at the point where a completely
new file accessing model is needed in order to try to obsolete this nest of nightmares. Unless, of course, someone can point to a nice replacement already written and functional?
Note: What [4] FileList class registeredFileReaderClasses says is that in the olden days FileList acted as a file registry.
This is now done by FileServices [5] but is does not do it for all cases [6].
On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:
Hello Edgar,
Replacing file access with the FileMan API is another issue. This thread is about the FileList *tool*. [3] .
The FileMan File accessing API may be loaded through SqueakMap (for 5.1, no entry yet for 6.0a).
FileList uses the FileServices registration mechanism [4]. The open task there is that the initialization code does not yet fully do its job [5], [6]. See discussion earlier this year in March in which you took part.
Regards
Hannes
[3] FileList comment:
I am model that can be used to navigate the host file system. By omitting the volume list, file list, and template panes from the view, I can also be used as the model for an editor on an individual file.
The FileList now provides a registration mechanism to which any tools the filelist uses ***MUST*** register. This way it is possible to dynamically load or unload a new tool and have the FileList automatically updated. This change supports a decomposition of Squeak and removes a problem with dead reference to classes after a major shrink.
http://wiki.squeak.org/squeak/1975
[4] FileList class registeredFileReaderClasses FileReaderRegistry := nil. "wipe it out" ^FileServices registeredFileReaderClasses
[5] FileServices -- http://wiki.squeak.org/squeak/1001
[6] Which file reader classes are not touched by "FileServices initialize"? -- http://wiki.squeak.org/squeak/1023
On 10/5/17, Edgar J. De Cleene edgardec2005@gmail.com wrote:
We should move to new File system. My choice is Juan Vuletich enhancements of original FileMan. This could be a case for Enviroments , having two file systems at once until all fell confortable with new File system,then rip older and move new out of Enviroments.
On 10/4/17, 20:35, "tim Rowledge" tim@rowledge.org wrote:
Too true in this case. As I look through and trace the code involved in FileList and it¹s subclasses I¹m struck (forcefully) by the amazing appallingness of it.
Some highlights of the horror movie -
- FileList is
referred to in 70 places, FileList2 in 33. Which one is meant to be our standard UI for files? No idea.
- When opening a default FileList (from the
dock menu for example) the contents of the default directory are read and processed twice. This may not seem a big deal, unless perhaps you have a thousand or more files in a directory, or your default directory is across a network, or you machine is slow etc. It¹s stupid, whatever.
- A FileList2
seems to double that stupidity.
- There are strange artefacts of what looks
like partial attempts to hack in EToys support, left to bitrot.
- Why would a
FileList be a subclass of StringHolder?
- A default FileList is built via the
ToolBuilder. FileList2 adds a load of non-TB ways to build.
- The look of
different variants of secondary dialogues built from FileList* vary wildly. Some have rounded blue frames. Some look like Œnormal¹ windows.
- Some
variants show a directory hierarchy by adding spaces in front of path elements. Others use a hierarchy displaying morph. The space-formatted list is built even when not needed.
- FileChooser adds yet another layer of
Œinterest¹ but appears totally unused.
- PluggableFileList appears to only
actually get used within MVC world, which is just as well since the morph version is rather ugly; it also seems to be only referred to usefully from StandardFileMenu, which makes an especially odd thing since the code reads as asking for a menu and you get a dialogue/window. And in some places the code alternately requests a StandardFileMenu and a FileList! Talk about causing confusion. As an extra bit of fun, the fact that it got squeezed into place as if a menu means that it has to implement assorted menu messages like #startUpWithCaption:
I think we¹re probably at the point where a completely
new file accessing model is needed in order to try to obsolete this nest of nightmares. Unless, of course, someone can point to a nice replacement already written and functional?
I have started a new thread covering the topic of the two previous mails.
'About missing services in FileServices initialize'
This thread is about FileList / FileList2 HH
On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:
Note: What [4] FileList class registeredFileReaderClasses says is that in the olden days FileList acted as a file registry.
This is now done by FileServices [5] but is does not do it for all cases [6].
On 10/5/17, H. Hirzel hannes.hirzel@gmail.com wrote:
Hello Edgar,
Replacing file access with the FileMan API is another issue. This thread is about the FileList *tool*. [3] .
The FileMan File accessing API may be loaded through SqueakMap (for 5.1, no entry yet for 6.0a).
FileList uses the FileServices registration mechanism [4]. The open task there is that the initialization code does not yet fully do its job [5], [6]. See discussion earlier this year in March in which you took part.
Regards
Hannes
[3] FileList comment:
I am model that can be used to navigate the host file system. By omitting the volume list, file list, and template panes from the view, I can also be used as the model for an editor on an individual file.
The FileList now provides a registration mechanism to which any tools the filelist uses ***MUST*** register. This way it is possible to dynamically load or unload a new tool and have the FileList automatically updated. This change supports a decomposition of Squeak and removes a problem with dead reference to classes after a major shrink.
http://wiki.squeak.org/squeak/1975
[4] FileList class registeredFileReaderClasses FileReaderRegistry := nil. "wipe it out" ^FileServices registeredFileReaderClasses
[5] FileServices -- http://wiki.squeak.org/squeak/1001
[6] Which file reader classes are not touched by "FileServices initialize"? -- http://wiki.squeak.org/squeak/1023
On 10/5/17, Edgar J. De Cleene edgardec2005@gmail.com wrote:
We should move to new File system. My choice is Juan Vuletich enhancements of original FileMan. This could be a case for Enviroments , having two file systems at once until all fell confortable with new File system,then rip older and move new out of Enviroments.
On 10/4/17, 20:35, "tim Rowledge" tim@rowledge.org wrote:
Too true in this case. As I look through and trace the code involved in FileList and it¹s subclasses I¹m struck (forcefully) by the amazing appallingness of it.
Some highlights of the horror movie -
- FileList is
referred to in 70 places, FileList2 in 33. Which one is meant to be our standard UI for files? No idea.
- When opening a default FileList (from the
dock menu for example) the contents of the default directory are read and processed twice. This may not seem a big deal, unless perhaps you have a thousand or more files in a directory, or your default directory is across a network, or you machine is slow etc. It¹s stupid, whatever.
- A FileList2
seems to double that stupidity.
- There are strange artefacts of what looks
like partial attempts to hack in EToys support, left to bitrot.
- Why would a
FileList be a subclass of StringHolder?
- A default FileList is built via the
ToolBuilder. FileList2 adds a load of non-TB ways to build.
- The look of
different variants of secondary dialogues built from FileList* vary wildly. Some have rounded blue frames. Some look like Œnormal¹ windows.
- Some
variants show a directory hierarchy by adding spaces in front of path elements. Others use a hierarchy displaying morph. The space-formatted list is built even when not needed.
- FileChooser adds yet another layer of
Œinterest¹ but appears totally unused.
- PluggableFileList appears to only
actually get used within MVC world, which is just as well since the morph version is rather ugly; it also seems to be only referred to usefully from StandardFileMenu, which makes an especially odd thing since the code reads as asking for a menu and you get a dialogue/window. And in some places the code alternately requests a StandardFileMenu and a FileList! Talk about causing confusion. As an extra bit of fun, the fact that it got squeezed into place as if a menu means that it has to implement assorted menu messages like #startUpWithCaption:
I think we¹re probably at the point where a completely
new file accessing model is needed in order to try to obsolete this nest of nightmares. Unless, of course, someone can point to a nice replacement already written and functional?
Ok, my mistake.
On 10/5/17, 06:33, "H. Hirzel" hannes.hirzel@gmail.com wrote:
Hello Edgar,
Replacing file access with the FileMan API is another
issue.
This thread is about the FileList *tool*. [3] .
The FileMan File
accessing API may be loaded through SqueakMap (for
5.1, no entry yet for
6.0a).
FileList uses the FileServices registration mechanism [4]. The
open
task there is that the initialization code does not yet fully do its job
[5], [6]. See discussion earlier this year in March in which you
took
part.
Regards
Hannes
On 10/5/17, tim Rowledge tim@rowledge.org wrote:
On 03-10-2017, at 12:59 PM, tim Rowledge tim@rowledge.org wrote:
[snip everything but the randomly chosen sigline]
Two wrongs are only the beginning.
Too true in this case. As I look through and trace the code involved in FileList and it’s subclasses I’m struck (forcefully) by the amazing appallingness of it.
Some highlights of the horror movie -
- FileList is referred to in 70 places, FileList2 in 33. Which one is meant
to be our standard UI for files? No idea.
- When opening a default FileList (from the dock menu for example) the
contents of the default directory are read and processed twice. This may not seem a big deal, unless perhaps you have a thousand or more files in a directory, or your default directory is across a network, or you machine is slow etc. It’s stupid, whatever.
- A FileList2 seems to double that stupidity.
- There are strange artefacts of what looks like partial attempts to hack
in EToys support, left to bitrot.
- Why would a FileList be a subclass of StringHolder?
- A default FileList is built via the ToolBuilder. FileList2 adds a load of
non-TB ways to build.
- The look of different variants of secondary dialogues built from
FileList* vary wildly. Some have rounded blue frames. Some look like ‘normal’ windows.
- Some variants show a directory hierarchy by adding spaces in front of
path elements. Others use a hierarchy displaying morph. The space-formatted list is built even when not needed.
- FileChooser adds yet another layer of ‘interest’ but appears totally
unused.
- PluggableFileList appears to only actually get used within MVC world,
which is just as well since the morph version is rather ugly; it also seems to be only referred to usefully from StandardFileMenu, which makes an especially odd thing since the code reads as asking for a menu and you get a dialogue/window. And in some places the code alternately requests a StandardFileMenu and a FileList! Talk about causing confusion. As an extra bit of fun, the fact that it got squeezed into place as if a menu means that it has to implement assorted menu messages like #startUpWithCaption:
I think we’re probably at the point where a completely new file accessing model is needed in order to try to obsolete this nest of nightmares.
I assume you mean the model for the FileList/FileList2 tools?
My answer: Yes!
Unless, of course, someone can point to a nice replacement already written and functional?
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RLB: Ruin Logic Board
A scary example of how code can become awful. Look at TheWorldMenu>loadProject. It has ended up using a generic directory chooser dialogue *plus* a rather ugly StandardFileMenu to choose a project file. There is a specific project loader provided by FileList2 but just try `FileList2 modalFolderSelectorForProjectLoad` *after* you have put on strong sunglasses. Maybe the current state is preferable after all... `FileList2 modalFolderSelectorForProject: Project current` is similarly a tad ‘bright’.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Solid concrete from the eyebrows backwards.
I'm wondering if you realize that EToys was the driver for much of this and they generally got the colors they wanted.
On 10/6/17 4:14 PM, tim Rowledge wrote:
There is a specific project loader provided by FileList2 but just try `FileList2 modalFolderSelectorForProjectLoad` *after* you have put on strong sunglasses. Maybe the current state is preferable after all... `FileList2 modalFolderSelectorForProject: Project current` is similarly a tad ‘bright’.
On 06-10-2017, at 1:33 PM, Bob Arning arning315@comcast.net wrote:
I'm wondering if you realize that EToys was the driver for much of this and they generally got the colors they wanted.
Oh certainly; but that doesn’t mean I have to approve of their colour choices. I do, after all, have an arts degree that requires me to look down my nose at visual choices made by hoi polloi - or I lose my membership.
And being a bit more serious (hey, it’s Friday and I’m in pain from a back injury, I’m allowed to be grumpy) this is a case where fully integrated observation of the theme stuff would (I hope) solve that kind of thing.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim The world will end in 5 minutes. Please log out.
squeak-dev@lists.squeakfoundation.org