[Pharo-project] possible TODOs...
Hi, I was already multiple times asked for a list of specific things that people could work on. Here are some ideas: -> World menu (after applying the simplification from bugtracker #166) -> Fullscreen of/on should be rendered like soundof/on, that is just one entry that changes according to state of display. -> in debug the start rendering entries should only be rendered when flag is set. (see code it calls) -> Preferences contains the code of the old preferences-browser. Remove all code related to this. (see Preferences class>>preferencesControlPanel) -> Browser has "printOut" menu entries that just do fileOut. Remove those entries. -> Browser has entry "browse all" in system category menu. This makes no sense. -> SqueakMap stores 1.5MB of crap in the image. make changeset that removes SqueakMap from the image. (check SqueakMap default purge) -> registerInFlapsRegistry... called in the class side initalize, please remove this and the infrastructure of flaps-registering. -> clean up Preferences. There are many preferences that nobody ever changes because the default makes a lot of sense. These need to be removed. -> CurvierMorph should be merged with PolygonMorph -> FileList2 should be merged with FileList. -> TranslatedMethod is a leftover from the original Jitter of 1998. Needs to be removed. Please note, it's in the specialObjectArray! -> Remove PluggableDictionary, PluggableSet (these are workarounds for the broken hashing in Squeak. We will fix hashing later for real) -> ColorTheme and subclasses should be removed. Refactoring needed for all users. (maybe best done after polymorph is added) -> remove BOBTransformationMorph. Refactor, merge with TransformationMorph? (maybe wait till etoys is gone) -> AlignmentMorphBob1 should be removed. Refactoring needed. (maybe wait till etoys is gone) -> Remove world-in-world support. start by removing classes EmbeddedWorldBorderMorph, NewWorldWindow after fixing all uses. -> TwoWayScrollPane shoud be removed (ScrollPane can do everything). Fix all useres of TwoWayScrollPane and delete class. -> CurrentProjectRefactoring is deprecated, yet it is referenced. Please fix all references (mostly just use Project current) and remove CurrentProjectRefactoring. -> Use Sophie's code to render a real pulldown menu entries on windows and Mac -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Hi, Let me add few my wishes: - Inspect and Explore merging into just Inspect. By extending Explorer with remaining Inspector functionalities like editing objects? - Inspect always on the same place in menus, not once at the top, then on the middle, on the bottom... - same for senders/implementors - Integrating Monticello commands directly into code browser, in right-click menu over packages. This really helps with code management, I know that from VW. - switch off halos by default, - multi select by Ctrl-left click or Shift-left click (all other windowing systems have multi select, so it is a time to introduce it here too = a big plus for newcomers) And last wish and I hope it is not too heretic: shouldn't we "harmonize" menus between different Smalltalk dialects a bit? This would help us the web guys a lot, we need to switch between dialects daily. Specially with VisualWorks, which most people use besides Squeak. And where in the era of Vasily Bykov a lot of sound usability features were introduced. Why wouldn't introduce them here too? Here is first such good usability feature: Do it Print it Inspect it Debug it ... in all menus in the middle, without exception! Best regards Janko Marcus Denker wrote:
Hi,
I was already multiple times asked for a list of specific things that people could work on. Here are some ideas:
-> World menu (after applying the simplification from bugtracker #166) -> Fullscreen of/on should be rendered like soundof/on, that is just one entry that changes according to state of display. -> in debug the start rendering entries should only be rendered when flag is set. (see code it calls)
-> Preferences contains the code of the old preferences-browser. Remove all code related to this. (see Preferences class>>preferencesControlPanel)
-> Browser has "printOut" menu entries that just do fileOut. Remove those entries.
-> Browser has entry "browse all" in system category menu. This makes no sense.
-> SqueakMap stores 1.5MB of crap in the image. make changeset that removes SqueakMap from the image. (check SqueakMap default purge)
-> registerInFlapsRegistry... called in the class side initalize, please remove this and the infrastructure of flaps-registering.
-> clean up Preferences. There are many preferences that nobody ever changes because the default makes a lot of sense. These need to be removed.
-> CurvierMorph should be merged with PolygonMorph
-> FileList2 should be merged with FileList.
-> TranslatedMethod is a leftover from the original Jitter of 1998. Needs to be removed. Please note, it's in the specialObjectArray!
-> Remove PluggableDictionary, PluggableSet (these are workarounds for the broken hashing in Squeak. We will fix hashing later for real)
-> ColorTheme and subclasses should be removed. Refactoring needed for all users. (maybe best done after polymorph is added)
-> remove BOBTransformationMorph. Refactor, merge with TransformationMorph? (maybe wait till etoys is gone)
-> AlignmentMorphBob1 should be removed. Refactoring needed. (maybe wait till etoys is gone)
-> Remove world-in-world support. start by removing classes EmbeddedWorldBorderMorph, NewWorldWindow after fixing all uses.
-> TwoWayScrollPane shoud be removed (ScrollPane can do everything). Fix all useres of TwoWayScrollPane and delete class.
-> CurrentProjectRefactoring is deprecated, yet it is referenced. Please fix all references (mostly just use Project current) and remove CurrentProjectRefactoring.
-> Use Sophie's code to render a real pulldown menu entries on windows and Mac
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
Good list ! - What do you think about remove bookMorph because it introduced a lot of dependencies - I will continue to work on etoy removal On Sep 21, 2008, at 2:22 PM, Marcus Denker wrote:
Hi,
I was already multiple times asked for a list of specific things that people could work on. Here are some ideas:
-> World menu (after applying the simplification from bugtracker #166) -> Fullscreen of/on should be rendered like soundof/on, that is just one entry that changes according to state of display. -> in debug the start rendering entries should only be rendered when flag is set. (see code it calls)
-> Preferences contains the code of the old preferences-browser. Remove all code related to this. (see Preferences class>>preferencesControlPanel)
-> Browser has "printOut" menu entries that just do fileOut. Remove those entries.
-> Browser has entry "browse all" in system category menu. This makes no sense.
-> SqueakMap stores 1.5MB of crap in the image. make changeset that removes SqueakMap from the image. (check SqueakMap default purge)
-> registerInFlapsRegistry... called in the class side initalize, please remove this and the infrastructure of flaps-registering.
-> clean up Preferences. There are many preferences that nobody ever changes because the default makes a lot of sense. These need to be removed.
-> CurvierMorph should be merged with PolygonMorph
-> FileList2 should be merged with FileList.
-> TranslatedMethod is a leftover from the original Jitter of 1998. Needs to be removed. Please note, it's in the specialObjectArray!
-> Remove PluggableDictionary, PluggableSet (these are workarounds for the broken hashing in Squeak. We will fix hashing later for real)
-> ColorTheme and subclasses should be removed. Refactoring needed for all users. (maybe best done after polymorph is added)
-> remove BOBTransformationMorph. Refactor, merge with TransformationMorph? (maybe wait till etoys is gone)
-> AlignmentMorphBob1 should be removed. Refactoring needed. (maybe wait till etoys is gone)
-> Remove world-in-world support. start by removing classes EmbeddedWorldBorderMorph, NewWorldWindow after fixing all uses.
-> TwoWayScrollPane shoud be removed (ScrollPane can do everything). Fix all useres of TwoWayScrollPane and delete class.
-> CurrentProjectRefactoring is deprecated, yet it is referenced. Please fix all references (mostly just use Project current) and remove CurrentProjectRefactoring.
-> Use Sophie's code to render a real pulldown menu entries on windows and Mac
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Let me add few my wishes:
- Inspect and Explore merging into just Inspect. By extending Explorer with remaining Inspector functionalities like editing objects?
- Inspect always on the same place in menus, not once at the top, then on the middle, on the bottom...
- same for senders/implementors
- Integrating Monticello commands directly into code browser, in right-click menu over packages. This really helps with code management, I know that from VW.
you should use the package browser and ask for improvement because you can start to do what you want with it.
- switch off halos by default,
- multi select by Ctrl-left click or Shift-left click (all other windowing systems have multi select, so it is a time to introduce it here too = a big plus for newcomers)
And last wish and I hope it is not too heretic: shouldn't we "harmonize" menus between different Smalltalk dialects a bit? This would help us the web guys a lot, we need to switch between dialects daily. Specially with VisualWorks, which most people use besides Squeak. And where in the era of Vasily Bykov a lot of sound usability features were introduced. Why wouldn't introduce them here too?
Here is first such good usability feature:
Do it Print it Inspect it Debug it
... in all menus in the middle, without exception!
Best regards Janko
Marcus Denker wrote:
Hi, I was already multiple times asked for a list of specific things that people could work on. Here are some ideas: -> World menu (after applying the simplification from bugtracker #166) -> Fullscreen of/on should be rendered like soundof/on, that is just one entry that changes according to state of display. -> in debug the start rendering entries should only be rendered when flag is set. (see code it calls) -> Preferences contains the code of the old preferences- browser. Remove all code related to this. (see Preferences class>>preferencesControlPanel) -> Browser has "printOut" menu entries that just do fileOut. Remove those entries. -> Browser has entry "browse all" in system category menu. This makes no sense. -> SqueakMap stores 1.5MB of crap in the image. make changeset that removes SqueakMap from the image. (check SqueakMap default purge) -> registerInFlapsRegistry... called in the class side initalize, please remove this and the infrastructure of flaps-registering. -> clean up Preferences. There are many preferences that nobody ever changes because the default makes a lot of sense. These need to be removed. -> CurvierMorph should be merged with PolygonMorph -> FileList2 should be merged with FileList. -> TranslatedMethod is a leftover from the original Jitter of 1998. Needs to be removed. Please note, it's in the specialObjectArray! -> Remove PluggableDictionary, PluggableSet (these are workarounds for the broken hashing in Squeak. We will fix hashing later for real) -> ColorTheme and subclasses should be removed. Refactoring needed for all users. (maybe best done after polymorph is added) -> remove BOBTransformationMorph. Refactor, merge with TransformationMorph? (maybe wait till etoys is gone) -> AlignmentMorphBob1 should be removed. Refactoring needed. (maybe wait till etoys is gone) -> Remove world-in-world support. start by removing classes EmbeddedWorldBorderMorph, NewWorldWindow after fixing all uses. -> TwoWayScrollPane shoud be removed (ScrollPane can do everything). Fix all useres of TwoWayScrollPane and delete class. -> CurrentProjectRefactoring is deprecated, yet it is referenced. Please fix all references (mostly just use Project current) and remove CurrentProjectRefactoring. -> Use Sophie's code to render a real pulldown menu entries on windows and Mac -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Janko Mivšek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
do we turn that into a list of todo? Stef On Sep 21, 2008, at 2:22 PM, Marcus Denker wrote:
Hi,
I was already multiple times asked for a list of specific things that people could work on. Here are some ideas:
-> World menu (after applying the simplification from bugtracker #166) -> Fullscreen of/on should be rendered like soundof/on, that is just one entry that changes according to state of display. -> in debug the start rendering entries should only be rendered when flag is set. (see code it calls)
-> Preferences contains the code of the old preferences-browser. Remove all code related to this. (see Preferences class>>preferencesControlPanel)
-> Browser has "printOut" menu entries that just do fileOut. Remove those entries.
-> Browser has entry "browse all" in system category menu. This makes no sense.
-> SqueakMap stores 1.5MB of crap in the image. make changeset that removes SqueakMap from the image. (check SqueakMap default purge)
-> registerInFlapsRegistry... called in the class side initalize, please remove this and the infrastructure of flaps-registering.
-> clean up Preferences. There are many preferences that nobody ever changes because the default makes a lot of sense. These need to be removed.
-> CurvierMorph should be merged with PolygonMorph
-> FileList2 should be merged with FileList.
-> TranslatedMethod is a leftover from the original Jitter of 1998. Needs to be removed. Please note, it's in the specialObjectArray!
-> Remove PluggableDictionary, PluggableSet (these are workarounds for the broken hashing in Squeak. We will fix hashing later for real)
-> ColorTheme and subclasses should be removed. Refactoring needed for all users. (maybe best done after polymorph is added)
-> remove BOBTransformationMorph. Refactor, merge with TransformationMorph? (maybe wait till etoys is gone)
-> AlignmentMorphBob1 should be removed. Refactoring needed. (maybe wait till etoys is gone)
-> Remove world-in-world support. start by removing classes EmbeddedWorldBorderMorph, NewWorldWindow after fixing all uses.
-> TwoWayScrollPane shoud be removed (ScrollPane can do everything). Fix all useres of TwoWayScrollPane and delete class.
-> CurrentProjectRefactoring is deprecated, yet it is referenced. Please fix all references (mostly just use Project current) and remove CurrentProjectRefactoring.
-> Use Sophie's code to render a real pulldown menu entries on windows and Mac
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 21.09.2008, at 18:17, Stéphane Ducasse wrote:
Good list !
- What do you think about remove bookMorph because it introduced a lot of dependencies
Yes, that needs to be removed. But that's some work as it has dependencies everywhere. (sometimes the code is really amazing that you can see in Squeak...) Marcus
- I will continue to work on etoy removal
ok!
On Sep 21, 2008, at 2:22 PM, Marcus Denker wrote:
Hi,
I was already multiple times asked for a list of specific things that people could work on. Here are some ideas:
-> World menu (after applying the simplification from bugtracker #166) -> Fullscreen of/on should be rendered like soundof/on, that is just one entry that changes according to state of display. -> in debug the start rendering entries should only be rendered when flag is set. (see code it calls)
-> Preferences contains the code of the old preferences-browser. Remove all code related to this. (see Preferences class>>preferencesControlPanel)
-> Browser has "printOut" menu entries that just do fileOut. Remove those entries.
-> Browser has entry "browse all" in system category menu. This makes no sense.
-> SqueakMap stores 1.5MB of crap in the image. make changeset that removes SqueakMap from the image. (check SqueakMap default purge)
-> registerInFlapsRegistry... called in the class side initalize, please remove this and the infrastructure of flaps-registering.
-> clean up Preferences. There are many preferences that nobody ever changes because the default makes a lot of sense. These need to be removed.
-> CurvierMorph should be merged with PolygonMorph
-> FileList2 should be merged with FileList.
-> TranslatedMethod is a leftover from the original Jitter of 1998. Needs to be removed. Please note, it's in the specialObjectArray!
-> Remove PluggableDictionary, PluggableSet (these are workarounds for the broken hashing in Squeak. We will fix hashing later for real)
-> ColorTheme and subclasses should be removed. Refactoring needed for all users. (maybe best done after polymorph is added)
-> remove BOBTransformationMorph. Refactor, merge with TransformationMorph? (maybe wait till etoys is gone)
-> AlignmentMorphBob1 should be removed. Refactoring needed. (maybe wait till etoys is gone)
-> Remove world-in-world support. start by removing classes EmbeddedWorldBorderMorph, NewWorldWindow after fixing all uses.
-> TwoWayScrollPane shoud be removed (ScrollPane can do everything). Fix all useres of TwoWayScrollPane and delete class.
-> CurrentProjectRefactoring is deprecated, yet it is referenced. Please fix all references (mostly just use Project current) and remove CurrentProjectRefactoring.
-> Use Sophie's code to render a real pulldown menu entries on windows and Mac
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
On 21.09.2008, at 18:26, Stéphane Ducasse wrote:
do we turn that into a list of todo?
Yes! A page on the wiki for now. This way we can keep bugs separate from TODOs. Marcus
Stef
On Sep 21, 2008, at 2:22 PM, Marcus Denker wrote:
Hi,
I was already multiple times asked for a list of specific things that people could work on. Here are some ideas:
-> World menu (after applying the simplification from bugtracker #166) -> Fullscreen of/on should be rendered like soundof/on, that is just one entry that changes according to state of display. -> in debug the start rendering entries should only be rendered when flag is set. (see code it calls)
-> Preferences contains the code of the old preferences-browser. Remove all code related to this. (see Preferences class>>preferencesControlPanel)
-> Browser has "printOut" menu entries that just do fileOut. Remove those entries.
-> Browser has entry "browse all" in system category menu. This makes no sense.
-> SqueakMap stores 1.5MB of crap in the image. make changeset that removes SqueakMap from the image. (check SqueakMap default purge)
-> registerInFlapsRegistry... called in the class side initalize, please remove this and the infrastructure of flaps-registering.
-> clean up Preferences. There are many preferences that nobody ever changes because the default makes a lot of sense. These need to be removed.
-> CurvierMorph should be merged with PolygonMorph
-> FileList2 should be merged with FileList.
-> TranslatedMethod is a leftover from the original Jitter of 1998. Needs to be removed. Please note, it's in the specialObjectArray!
-> Remove PluggableDictionary, PluggableSet (these are workarounds for the broken hashing in Squeak. We will fix hashing later for real)
-> ColorTheme and subclasses should be removed. Refactoring needed for all users. (maybe best done after polymorph is added)
-> remove BOBTransformationMorph. Refactor, merge with TransformationMorph? (maybe wait till etoys is gone)
-> AlignmentMorphBob1 should be removed. Refactoring needed. (maybe wait till etoys is gone)
-> Remove world-in-world support. start by removing classes EmbeddedWorldBorderMorph, NewWorldWindow after fixing all uses.
-> TwoWayScrollPane shoud be removed (ScrollPane can do everything). Fix all useres of TwoWayScrollPane and delete class.
-> CurrentProjectRefactoring is deprecated, yet it is referenced. Please fix all references (mostly just use Project current) and remove CurrentProjectRefactoring.
-> Use Sophie's code to render a real pulldown menu entries on windows and Mac
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
- removing componentWithModel is another one of the missing ones. On Sep 21, 2008, at 7:49 PM, Marcus Denker wrote:
On 21.09.2008, at 18:17, Stéphane Ducasse wrote:
Good list !
- What do you think about remove bookMorph because it introduced a lot of dependencies
Yes, that needs to be removed. But that's some work as it has dependencies everywhere. (sometimes the code is really amazing that you can see in Squeak...)
I agree but pharo will be much cleaner :)
On 21.09.2008, at 16:22, Janko Mivšek wrote:
Hi,
Let me add few my wishes:
- Inspect and Explore merging into just Inspect. By extending Explorer with remaining Inspector functionalities like editing objects?
- Inspect always on the same place in menus, not once at the top, then on the middle, on the bottom...
- same for senders/implementors
- Integrating Monticello commands directly into code browser, in right-click menu over packages. This really helps with code management, I know that from VW.
- switch off halos by default,
- multi select by Ctrl-left click or Shift-left click (all other windowing systems have multi select, so it is a time to introduce it here too = a big plus for newcomers)
Good ideas! I am collecting them for now in this bug-report: http://code.google.com/p/pharo/issues/detail?id=186 Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
There's one important item that Janko proposed some time ago: - swapMouseButtons preset depending on target OS (this one is probably the most annoying thing for newcomers!) Adrian On Sep 22, 2008, at 10:12 , Marcus Denker wrote:
On 21.09.2008, at 16:22, Janko Mivšek wrote:
Hi,
Let me add few my wishes:
- Inspect and Explore merging into just Inspect. By extending Explorer with remaining Inspector functionalities like editing objects?
- Inspect always on the same place in menus, not once at the top, then on the middle, on the bottom...
- same for senders/implementors
- Integrating Monticello commands directly into code browser, in right-click menu over packages. This really helps with code management, I know that from VW.
- switch off halos by default,
- multi select by Ctrl-left click or Shift-left click (all other windowing systems have multi select, so it is a time to introduce it here too = a big plus for newcomers)
Good ideas! I am collecting them for now in this bug-report:
http://code.google.com/p/pharo/issues/detail?id=186
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 24.09.2008, at 21:31, Stéphane Ducasse wrote:
Hi marcus
did you remove squeakmap already?
no. I only purged the data, which means it does not load anymore. (there is a fix for that on the bugtracker). Marcus -- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
Yes I saw Now I imagine that we want to get rid of Project too. I ask because I was looking at EmbeddedWorld.... Stef
no. I only purged the data, which means it does not load anymore. (there is a fix for that on the bugtracker).
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
folks, I was wondering (or I have missed the docs) if someone could update HowToContribute on the wiki to include the loose ideas for how to construct and manage wish lists & todos etc? Is the plan that the issue tracker is used as the master todo list? Say #186 contains a list of things to do. If I start working on one should I create a new entry so that I can show progress on it? I like the issue tracker, i'm just not entirely sure how to behave in this pre-coding / organisational phase. HowToContribute assumes pretty much you're ready with your mcz. cheers, Mike On Mon, Sep 22, 2008 at 9:12 AM, Marcus Denker <denker@iam.unibe.ch> wrote:
On 21.09.2008, at 16:22, Janko Mivšek wrote:
Hi,
Let me add few my wishes:
- Inspect and Explore merging into just Inspect. By extending Explorer with remaining Inspector functionalities like editing objects?
- Inspect always on the same place in menus, not once at the top, then on the middle, on the bottom...
- same for senders/implementors
- Integrating Monticello commands directly into code browser, in right-click menu over packages. This really helps with code management, I know that from VW.
- switch off halos by default,
- multi select by Ctrl-left click or Shift-left click (all other windowing systems have multi select, so it is a time to introduce it here too = a big plus for newcomers)
Good ideas! I am collecting them for now in this bug-report:
http://code.google.com/p/pharo/issues/detail?id=186
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I thought marcus was planning to create a wiki page with the todos. So if you cannot find one, just create one. I have the impression that we could use another tag for todo issue. since wiki pages do not work well for trakcing. On Sep 27, 2008, at 4:53 PM, Michael Roberts wrote:
folks, I was wondering (or I have missed the docs) if someone could update HowToContribute on the wiki to include the loose ideas for how to construct and manage wish lists & todos etc? Is the plan that the issue tracker is used as the master todo list? Say #186 contains a list of things to do. If I start working on one should I create a new entry so that I can show progress on it? I like the issue tracker, i'm just not entirely sure how to behave in this pre-coding / organisational phase. HowToContribute assumes pretty much you're ready with your mcz.
cheers, Mike
On Mon, Sep 22, 2008 at 9:12 AM, Marcus Denker <denker@iam.unibe.ch> wrote:
On 21.09.2008, at 16:22, Janko Mivšek wrote:
Hi,
Let me add few my wishes:
- Inspect and Explore merging into just Inspect. By extending Explorer with remaining Inspector functionalities like editing objects?
- Inspect always on the same place in menus, not once at the top, then on the middle, on the bottom...
- same for senders/implementors
- Integrating Monticello commands directly into code browser, in right-click menu over packages. This really helps with code management, I know that from VW.
- switch off halos by default,
- multi select by Ctrl-left click or Shift-left click (all other windowing systems have multi select, so it is a time to introduce it here too = a big plus for newcomers)
Good ideas! I am collecting them for now in this bug-report:
http://code.google.com/p/pharo/issues/detail?id=186
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, 2008-09-27 at 17:09 +0200, Stéphane Ducasse wrote:
I thought marcus was planning to create a wiki page with the todos. So if you cannot find one, just create one. I have the impression that we could use another tag for todo issue. since wiki pages do not work well for trakcing.
I would opt for putting the todos in the tracker. IMHO it is impossible to keep a wiki page in sync. In tracker there is already something like a todo: an accepted enhancement! my 2 Norbert
On Sep 27, 2008, at 4:53 PM, Michael Roberts wrote:
folks, I was wondering (or I have missed the docs) if someone could update HowToContribute on the wiki to include the loose ideas for how to construct and manage wish lists & todos etc? Is the plan that the issue tracker is used as the master todo list? Say #186 contains a list of things to do. If I start working on one should I create a new entry so that I can show progress on it? I like the issue tracker, i'm just not entirely sure how to behave in this pre-coding / organisational phase. HowToContribute assumes pretty much you're ready with your mcz.
cheers, Mike
On Mon, Sep 22, 2008 at 9:12 AM, Marcus Denker <denker@iam.unibe.ch> wrote:
On 21.09.2008, at 16:22, Janko Mivšek wrote:
Hi,
Let me add few my wishes:
- Inspect and Explore merging into just Inspect. By extending Explorer with remaining Inspector functionalities like editing objects?
- Inspect always on the same place in menus, not once at the top, then on the middle, on the bottom...
- same for senders/implementors
- Integrating Monticello commands directly into code browser, in right-click menu over packages. This really helps with code management, I know that from VW.
- switch off halos by default,
- multi select by Ctrl-left click or Shift-left click (all other windowing systems have multi select, so it is a time to introduce it here too = a big plus for newcomers)
Good ideas! I am collecting them for now in this bug-report:
http://code.google.com/p/pharo/issues/detail?id=186
Marcus
-- Marcus Denker -- denker@iam.unibe.ch http://www.iam.unibe.ch/~denker
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I would keep them in the tracker too. the question in my mind is if dumping a large list into a single issue scales? Perhaps by convention if an issue contains a list, it is considered a bucket and people break issues out on their own as they go? A single issue with 100s of comments is going to get a mess. but then you have comments on issues in two places. that would be where the wiki would help as a dumping ground for lists, where you could delete items on insertion into the tracker. I'm just thinking out loud... I implemented the full screen but marcus beat me to it. i'll start at the bottom next time ;) just my 0.02 GBP / EUR Mike
On Sat, 2008-09-27 at 16:35 +0100, Michael Roberts wrote:
I would keep them in the tracker too. the question in my mind is if dumping a large list into a single issue scales? Perhaps by convention if an issue contains a list, it is considered a bucket and people break issues out on their own as they go? A single issue with 100s of comments is going to get a mess. but then you have comments on issues in two places. that would be where the wiki would help as a dumping ground for lists, where you could delete items on insertion into the tracker. I'm just thinking out loud... I implemented the full screen but marcus beat me to it. i'll start at the bottom next time ;)
just my 0.02 GBP / EUR
I'm not for a wiki page beside one that explains how to deal with tickets. This page is already there. As long as you cannot group tickets with assigned dependencies a ticket with 100 issues is not a good idea. Just create 100 issues where discussion takes place in every single issue. I don't see a single reason not to do so. Everything else is too complicated. Keeping information in two different places is a no no. If there is something more complex that has to go this way it is milestone planning. So you create a wiki page with all the issue numbers that have to be solved before the milestone is reached. Usually you would expect this from the tracker, too. But google code is not capable of doing this. In this case the wiki page does no harm as it is easy to sync. Just have a look at the tickets and you know what to do. I want to avoid new categories or types in the tracker as well as it just complicates things. If you need a strong filter for dealing with the tickets it is ok. that's another 2 cents (euro type) Norbert
we should split the list into issues but we should tag them as todo. Stef On Sep 27, 2008, at 5:35 PM, Michael Roberts wrote:
I would keep them in the tracker too. the question in my mind is if dumping a large list into a single issue scales? Perhaps by convention if an issue contains a list, it is considered a bucket and people break issues out on their own as they go? A single issue with 100s of comments is going to get a mess. but then you have comments on issues in two places. that would be where the wiki would help as a dumping ground for lists, where you could delete items on insertion into the tracker. I'm just thinking out loud... I implemented the full screen but marcus beat me to it. i'll start at the bottom next time ;)
just my 0.02 GBP / EUR
Mike
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sun, Sep 21, 2008 at 6:18 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
- Integrating Monticello commands directly into code browser, in right-click menu over packages. This really helps with code management, I know that from VW.
you should use the package browser and ask for improvement because you can start to do what you want with it.
Stéphane is right. Just download a Pharo dev image and the default browser has these features. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu)
participants (7)
-
Adrian Lienhard -
Damien Cassou -
Janko Mivšek -
Marcus Denker -
Michael Roberts -
Norbert Hartl -
Stéphane Ducasse