- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Conseils for develop a grid

by Hilaire Fernandes

Alain Plantec a Ã©crit : > Hilaire Fernandes a Ã©crit : >> nullPointer a Ã©crit : >> >>> Then, there is not way of to improve much more that speed. I want use Pharo >>> for commercial apps too, and surely need load lots of data. >>> >>> >>>> It seems that you're using the stepping mechanism, it is time consuming. >>>> also the layout managing and invalid areas redrawing. >>>> >>> Is possible fix that? >>> >> What about a late instantiation mechanism for invisible cell morph >> > I've tried that (see LazyMorphTreeMorph). It seems to work well. > A list is opened in a second whatever the number of items. > the drawback (a serious one for very long list) is the scrolling > because rows are recomputed when they become visible. > try it with Why not late initialization and caching. Thus rows are instantiated only when they are first viewed. Hilaire

Feb. 7, 2010

Re: [Pharo-project] Conseils for develop a grid

by Alain Plantec

Hilaire Fernandes a Ã©crit : > nullPointer a Ã©crit : > >> Then, there is not way of to improve much more that speed. I want use Pharo >> for commercial apps too, and surely need load lots of data. >> >> >>> It seems that you're using the stepping mechanism, it is time consuming. >>> also the layout managing and invalid areas redrawing. >>> >> Is possible fix that? >> > > What about a late instantiation mechanism for invisible cell morph > I've tried that (see LazyMorphTreeMorph). It seems to work well. A list is opened in a second whatever the number of items. the drawback (a serious one for very long list) is the scrolling because rows are recomputed when they become visible. try it with LazyClassListExample new openOn: Object (for 1.0, get it from www.squeaksource.com/Momo10) So maybe an example to start with .... Cheers Alain > Hilaire > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >

Feb. 7, 2010

Re: [Pharo-project] Conseils for develop a grid

by Alain Plantec

nullPointer a Ã©crit : > > > > > > >> also the layout managing and invalid areas redrawing. > > do you redraw even the not visible cells? > > > I donÂ´t know. I have a ScrollPane widget. In that scrollPane i have a > container (simply a panel morph). That pane have TableLayout policy, > from top to bottom. Each row is added at that panel. Te rows is > configured with TableLayout policy too, from left to right list > direction, and in each row exists a collection of cells. > > I suppose than the ScrollPane dont redraw controls out of limits, but > I donÂ´t know. yes, it works well like this > > ------------------------------------------------------------------------ > View this message in context: Re: Conseils for develop a grid > <http://n4.nabble.com/Conseils-for-develop-a-grid-tp1299737p1471870.html> > Sent from the Pharo Smalltalk mailing list archive > <http://n4.nabble.com/Pharo-Smalltalk-f1294837.html> at Nabble.com. > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 7, 2010

Re: [Pharo-project] Conseils for develop a grid

by StÃ©phane Ducasse

I'm very sorry that I'm good at widgets I would really like to help you. This is for such a reason that we should continue to clean morphic to arrive to the point where we do not have three different classes for doing the same and often not ahving the behavior we want. Stef On Feb 7, 2010, at 10:22 AM, nullPointer wrote: > > > I think that there are always space to improve. > This is just that we should look at what we are doing in a different way. > > >> It seems that you're using the stepping mechanism, it is time consuming. > > Yes stepping is not the way to go > > WhatÂ´s stepping? :) > > > >> also the layout managing and invalid areas redrawing. > > do you redraw even the not visible cells? > > I donÂ´t know. I have a ScrollPane widget. In that scrollPane i have a container (simply a panel morph). That pane have TableLayout policy, from top to bottom. Each row is added at that panel. Te rows is configured with TableLayout policy too, from left to right list direction, and in each row exists a collection of cells. > > I suppose than the ScrollPane dont redraw controls out of limits, but I donÂ´t know. > > Seeing the trace seems than the more problematic is when creating the cells ( the method #buildCellsStructureFrom ). > > Is possible stop all UI events when Iis running the build of cells and rows? > I did think in use threads, but the UI crushes when I try that way. > > Regards > > View this message in context: Re: Conseils for develop a grid > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 7, 2010

Re: [Pharo-project] Conseils for develop a grid

by StÃ©phane Ducasse

That a morph will perform an action every miliseconds. Did you define the step method? or stepTime? Stef On Feb 7, 2010, at 10:22 AM, nullPointer wrote: > > > I think that there are always space to improve. > This is just that we should look at what we are doing in a different way. > > >> It seems that you're using the stepping mechanism, it is time consuming. > > Yes stepping is not the way to go > > WhatÂ´s stepping? :) > > > >> also the layout managing and invalid areas redrawing. > > do you redraw even the not visible cells? > > I donÂ´t know. I have a ScrollPane widget. In that scrollPane i have a container (simply a panel morph). That pane have TableLayout policy, from top to bottom. Each row is added at that panel. Te rows is configured with TableLayout policy too, from left to right list direction, and in each row exists a collection of cells. > > I suppose than the ScrollPane dont redraw controls out of limits, but I donÂ´t know. With widgets from Squeak nothing is like we think they are :) With the new tree widget developed by alain you get a lazy Tree morph with can handle large collection. > Seeing the trace seems than the more problematic is when creating the cells ( the method #buildCellsStructureFrom ). > > Is possible stop all UI events when Iis running the build of cells and rows? > I did think in use threads, but the UI crushes when I try that way. > > Regards > > View this message in context: Re: Conseils for develop a grid > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 7, 2010

Re: [Pharo-project] Conseils for develop a grid

by Hilaire Fernandes

nullPointer a Ã©crit : > Then, there is not way of to improve much more that speed. I want use Pharo > for commercial apps too, and surely need load lots of data. > >> It seems that you're using the stepping mechanism, it is time consuming. >> also the layout managing and invalid areas redrawing. > > Is possible fix that? What about a late instantiation mechanism for invisible cell morph Hilaire

Feb. 7, 2010

Re: [Pharo-project] Conseils for develop a grid

by nullPointer

I think that there are always space to improve. > This is just that we should look at what we are doing in a different way. > > >> It seems that you're using the stepping mechanism, it is time > consuming. > > Yes stepping is not the way to go > WhatÂ´s stepping? :) > >> also the layout managing and invalid areas redrawing. > > do you redraw even the not visible cells? > I donÂ´t know. I have a ScrollPane widget. In that scrollPane i have a container (simply a panel morph). That pane have TableLayout policy, from top to bottom. Each row is added at that panel. Te rows is configured with TableLayout policy too, from left to right list direction, and in each row exists a collection of cells. I suppose than the ScrollPane dont redraw controls out of limits, but I donÂ´t know. Seeing the trace seems than the more problematic is when creating the cells ( the method #buildCellsStructureFrom ). Is possible stop all UI events when Iis running the build of cells and rows? I did think in use threads, but the UI crushes when I try that way. Regards -- View this message in context: http://n4.nabble.com/Conseils-for-develop-a-grid-tp1299737p1471870.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Feb. 7, 2010

Re: [Pharo-project] Metacello - the missing information??

by laurent laffont

2010/2/6 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > The closest thing I see in the tutorial (assuming it is working as > intended) is a mention of baseline configurations. If that is in fact how > things can work, there should be an abstract super class for all > configurations (or at least a trait they all use to avoid duplicate code) > and a method that loads the baseline. > > ProfStef would be a lot more useful if it made use of Polymorph: a table > of contents in a left pane, select an item and the righ pane shows the > content, actions replaced with buttons rather than forcing a lot of > right-clicking. To the extent that those things are difficult, we need > easy-to-use tree models. From what I have been able to figure out of the > tutorial, a wiki page would be more helpful and more likely to be read. > If you "force" loading of code, then there should be some benefit in the > form of interaction. > Danny Chan has written ProfStefBrowser (in the same repository as ProfStef) which has both browsing and interactive (ProfStef next) capabilities. Tudor Girba has also written a proof-of-concept using Glamour: Gofer new squeaksource: 'glamoroust'; package: 'ConfigurationOfGlamoroust'; load. (Smalltalk at: #ConfigurationOfGlamoroust) perform: #loadDefault. And then: GTProfStef open (You spawn the new lesson by command+o) Cheers Laurent Laffont > My question stands. > Bill > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr] *On Behalf Of *Mariano > Martinez Peck > *Sent:* Saturday, February 06, 2010 4:52 PM > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] Metacello - the missing information?? > > > > On Sat, Feb 6, 2010 at 10:22 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > >> For any given cofiguration, how does one know which version to load? >> There are incantations in the beginner workspace, but what happens for >> things not listed there? >> >> > You must know about Metacello. As you can noticed, that's why I added the > link to the tutorial. > > >> Bill >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 7, 2010

Re: [Pharo-project] World Menu (was [BetaTesting] [ANN] Pharo1.0-10507-rc2dev10.01.2)

by StÃ©phane Ducasse

can you point us to the class? On Feb 6, 2010, at 9:54 PM, Alain Plantec wrote: > StÃ©phane Ducasse a Ã©crit : >> we need a registration mechanism for the menu >> > yes, I have built one which is using pragma but it needs a > to reviewed a little bit. > Alain >> >> On Feb 5, 2010, at 9:53 PM, Mariano Martinez Peck wrote: >> >> >>> On Fri, Feb 5, 2010 at 9:23 PM, laurent laffont <laurent.laffont(a)gmail.com> wrote: >>> Hi Mariano, >>> >>> You will find a changeset attached here http://code.google.com/p/pharo/issues/detail?id=1937 which add the Help menu. >>> >>> >>> Thanks Laurent! Thanks cool !!! >>> >>> Now, I have another question. It would be cool that the help menu is in the core image. But then, there will be items that should be from the core, suppose a workspace with the shortcuts or something similar and items that are from the PharoDev image, for example, ProfStef. >>> >>> So, my question is, can I integrate this menu in PharoCore, with the current items of PharoCore and then, from outside, suppose when building PharoDev I add things there ? or even ProfStef for example could add himself there when installing (in the metacello post doit). >>> >>> I think this is similar to the problem of the ToolSet. I want to be able to build or modify in runtime the items of a menu :) >>> >>> Is this possible ? >>> >>> Cheers >>> >>> Mariano >>> >>> Laurent >>> >>> >>> >>> On Fri, Feb 5, 2010 at 9:51 AM, laurent laffont <laurent.laffont(a)gmail.com> wrote: >>> >>> 2010/2/5 Mariano Martinez Peck <marianopeck(a)gmail.com> >>> >>> >>> >>> 2010/2/4 laurent laffont <laurent.laffont(a)gmail.com> >>> >>> Hi, >>> >>> I was thinking that there's no entry in the world menu to re-open the welcome workspace. For beginners it may be useful ? >>> >>> Yes, I agree. I also though about that but I didn't know where to put it in the menu neither how to code it. Ok, I have several examples to look how to do it, but nil time for the last week :( >>> >>> Where exactly do you think is the best place to put it in the menu ? I said several times about the issue: >>> >>> http://code.google.com/p/pharo/issues/detail?id=1042 >>> >>> (search in mailing list also) >>> >>> It is OBVIOUS that we are missing a "help menu". >>> >>> >>> I agree >>> >>> >>> >>> >>> There we can put also this thing to reopen the welcome workspace. >>> >>> Now....do we have time to do this for 1.0 ? someone ? >>> >>> >>> I will take a look. No promise. >>> >>> >>> In World > Tools: >>> - duplicated entries: Class Browser, Workspace, Test Runner, Monticello Browser >>> >>> These are the most common used tools, that's why they are there. >>> >>> >>> I prefer one thing at one place :) >>> >>> >>> Laurent >>> >>> >>> >>> In World > Tools > More: >>> - Language editor / language editor for.... these tools look strange :) >>> >>> And I don't know if they are even working, >>> >>> - duplicated entries: Monticello Browser, Preference Browser, Test Runner >>> - someone use Search Browser and Services Browser ? >>> - MCConfigurationBrowser: what is the purpose of this tool ? >>> (may be we can remove this "Other tools" menu, merging it with tools) >>> >>> >>> Cheers, >>> >>> Laurent Laffont >>> >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 7, 2010

Re: [Pharo-project] Conseils for develop a grid

by StÃ©phane Ducasse

On Feb 7, 2010, at 9:21 AM, nullPointer wrote: > > Then, there is not way of to improve much more that speed. I want use Pharo > for commercial apps too, and surely need load lots of data. I think that there are always space to improve. This is just that we should look at what we are doing in a different way. >> It seems that you're using the stepping mechanism, it is time consuming. Yes stepping is not the way to go >> also the layout managing and invalid areas redrawing. do you redraw even the not visible cells? > > Is possible fix that? > -- > View this message in context: http://n4.nabble.com/Conseils-for-develop-a-grid-tp1299737p1471822.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 7, 2010