[Pharo-project] FileBrowser/FileList rant
Hi, it seems that FileBrowser/FileList is never used... And I absolutely don't understand some design choices. 1) Having a single reference inst var for both selectedDirectory and selectedFile : this is a bug factory, see http://code.google.com/p/pharo/issues/detail?id=5881 and http://code.google.com/p/pharo/issues/detail?id=5884 for example of bugs (I could open 1 bug entry per menu item I guess) 2) auto-selecting the file item under pop-up menu click This is a windows thing and anti-Smalltalk-UI-custom This is not at all uniform in the rest of Pharo UI (not even on the directory list) The implementation is buggish (see ttp://code.google.com/p/pharo/issues/detail?id=5882 which is duplicate of ttp://code.google.com/p/pharo/issues/detail?id=5625) There was (and still is) a specific menu when no file is selected... fileListMenu: aMenu reference ifNil: [^ self noFileSelectedMenu: aMenu] ifNotNil: [^ self fileSelectedMenu: aMenu]. I don't want to argue whether or not FileList did deserve a clean-up, I'm quite sure it did. And I also agree that we can temporarily break things in development images. But when the clean-up is so far from anything functional, I just wonder who do you want to eat the dog food? I'm a bit sick of it ;) Nicolas
well the previous implementation was so horrible I didn't really feel to fix too much. besides, drag and drop works pretty nicely, so I personally don't see why using a shitty file browser in pharo when I can do the same thing 100 times faster in my OS :/ but I think we will reimplement it from scratch in 2.0. The whole implementation is almost orthogonal to the new FileSystem... On 2012-05-13, at 16:56, Nicolas Cellier wrote:
Hi, it seems that FileBrowser/FileList is never used... And I absolutely don't understand some design choices.
1) Having a single reference inst var for both selectedDirectory and selectedFile : this is a bug factory, see http://code.google.com/p/pharo/issues/detail?id=5881 and http://code.google.com/p/pharo/issues/detail?id=5884 for example of bugs (I could open 1 bug entry per menu item I guess)
2) auto-selecting the file item under pop-up menu click This is a windows thing and anti-Smalltalk-UI-custom This is not at all uniform in the rest of Pharo UI (not even on the directory list) The implementation is buggish (see ttp://code.google.com/p/pharo/issues/detail?id=5882 which is duplicate of ttp://code.google.com/p/pharo/issues/detail?id=5625)
There was (and still is) a specific menu when no file is selected... fileListMenu: aMenu reference ifNil: [^ self noFileSelectedMenu: aMenu] ifNotNil: [^ self fileSelectedMenu: aMenu].
I don't want to argue whether or not FileList did deserve a clean-up, I'm quite sure it did. And I also agree that we can temporarily break things in development images. But when the clean-up is so far from anything functional, I just wonder who do you want to eat the dog food? I'm a bit sick of it ;)
Nicolas
We will have to reimplement it using Spec so :) Ben On May 14, 2012, at 3:02 PM, Camillo Bruni wrote:
well the previous implementation was so horrible I didn't really feel to fix too much. besides, drag and drop works pretty nicely, so I personally don't see why using a shitty file browser in pharo when I can do the same thing 100 times faster in my OS :/
but I think we will reimplement it from scratch in 2.0. The whole implementation is almost orthogonal to the new FileSystem...
On 2012-05-13, at 16:56, Nicolas Cellier wrote:
Hi, it seems that FileBrowser/FileList is never used... And I absolutely don't understand some design choices.
1) Having a single reference inst var for both selectedDirectory and selectedFile : this is a bug factory, see http://code.google.com/p/pharo/issues/detail?id=5881 and http://code.google.com/p/pharo/issues/detail?id=5884 for example of bugs (I could open 1 bug entry per menu item I guess)
2) auto-selecting the file item under pop-up menu click This is a windows thing and anti-Smalltalk-UI-custom This is not at all uniform in the rest of Pharo UI (not even on the directory list) The implementation is buggish (see ttp://code.google.com/p/pharo/issues/detail?id=5882 which is duplicate of ttp://code.google.com/p/pharo/issues/detail?id=5625)
There was (and still is) a specific menu when no file is selected... fileListMenu: aMenu reference ifNil: [^ self noFileSelectedMenu: aMenu] ifNotNil: [^ self fileSelectedMenu: aMenu].
I don't want to argue whether or not FileList did deserve a clean-up, I'm quite sure it did. And I also agree that we can temporarily break things in development images. But when the clean-up is so far from anything functional, I just wonder who do you want to eat the dog food? I'm a bit sick of it ;)
Nicolas
participants (3)
-
Benjamin -
Camillo Bruni -
Nicolas Cellier