GAUCHO 1.0 released!
Locked
12
12
 
|
Hi Simon,
On Jun 7, 2010, at 5:48 PM, Simon Denier wrote: > > OK two other things > > 1) (minor) I find myself repeatdly trying to extend a Shape size to display more instance variables and methods by looking for the resize handle in the bottom right corner > We wanted to provide a concise and compact view of the shapes, due to the restrictions that the current Morphic is pixel based and not scalable, to take the most of the real estate of a pampas. Possibly once i migrate to a scalable and vectorized UI framework ( Morphic3 ?), resizing would be considered. > 2) when I want to edit a method, the shape takes the full screen and I can't see any other data. Why can't I edit the method in-place > This was a decision i took, based on the fact that this lets you focus on writing that method only, similar to what Ommwriter proposes. http://www.ommwriter.com/ The idea is to provide a Control panel where the developer can customize the system in the next version. > > Also, I find it quickly annoying when I have to place manually each shape created. It would be better if shapes tend to stick to their parent shape when created, and I can move them freely after (I think that one point where codebubbles is good). This is also something for the next release, i also think that code bubbles has a good automatic layout strategy, and would like to provide something similar, or even better. > I actually have more ideas about that, but it's tedious to explain by plain mail. > I would love to hear them! I think this next ESUG would be an excellent place to meet and discuss. Thanks for the feedback ! Fernando _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Gaucho icons framework into Pharo1.1 ?
|
|
In reply to this post by Fernando olivero
Le 08/06/2010 09:21, Fernando olivero a écrit :
> Hi Simon, the icons are the Oxygen family of icons from the GNOME project. > > I've made a icons framework importer , which loads an icon set into Pharo and creates a class for each icon set. > The idea is to have polymorphic classes of icons sets: > For example > > IconsFamilyBuilder>>build > | specs secs | > specs := self iconsSpecs . > specs do:[:each| each resourcesFolderName: self resourcesFolderName ]. > ^ GMIconFamily createFamilyNamed: self iconFamilyName specs: specs . > > Which has subclasses such as OxygenIconsBuilder, that creates GMIconFamilyOxygen. > The code is similar to that found in MenuIcons, but i've added the notion of icons sets. > > I would like to integrate it to Pharo1.1, so we should unify the MenuIcons and maybe the UIThemes methods found in the icons category, so we provide only one entry point for icons in the system, together with a simple importer and provider of icons. > > Let me know what you think. > It seems cool. Maybe open an issue with a package for your icon framework so that people can test and write feedbacks. Cheers Alain > > > Fernando > > > > >> >> Who did the nice icons? >> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Gaucho icons framework into Pharo1.1 ?
|
|
In reply to this post by Fernando olivero
On Tue, Jun 8, 2010 at 9:21 AM, Fernando olivero <[hidden email]> wrote: Hi Simon, the icons are the Oxygen family of icons from the GNOME project. Please don't. We need to freeze Pharo1.1. We are near to the release and only bug fixes should be integrated. But of course, this is more than welcome in Pharo 1.2 ;) Let me know what you think. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Gaucho icons framework into Pharo1.1 ?
|
|
In reply to this post by Fernando olivero
Yes this would be a nice idea to have several icons importers and icons family.
If we could have the default set under the same infrastructure it would be good. For 1.2 :) On Jun 8, 2010, at 9:21 AM, Fernando olivero wrote: > Hi Simon, the icons are the Oxygen family of icons from the GNOME project. > > I've made a icons framework importer , which loads an icon set into Pharo and creates a class for each icon set. > The idea is to have polymorphic classes of icons sets: > For example > > IconsFamilyBuilder>>build > | specs secs | > specs := self iconsSpecs . > specs do:[:each| each resourcesFolderName: self resourcesFolderName ]. > ^ GMIconFamily createFamilyNamed: self iconFamilyName specs: specs . > > Which has subclasses such as OxygenIconsBuilder, that creates GMIconFamilyOxygen. > The code is similar to that found in MenuIcons, but i've added the notion of icons sets. > > I would like to integrate it to Pharo1.1, so we should unify the MenuIcons and maybe the UIThemes methods found in the icons category, so we provide only one entry point for icons in the system, together with a simple importer and provider of icons. > > Let me know what you think. > > > > Fernando > > > >> >> >> Who did the nice icons? >> >> >> -- >> Simon >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Fernando olivero
On Jun 8, 2010, at 9:28 AM, Fernando olivero wrote: > Hi Simon, > > On Jun 7, 2010, at 5:48 PM, Simon Denier wrote: > >> >> OK two other things >> >> 1) (minor) I find myself repeatdly trying to extend a Shape size to display more instance variables and methods by looking for the resize handle in the bottom right corner >> > Fernando if you listen what simon is telling you is that he does not want to see the code in larger font. he said that on his 30 inches screen he would like to see more method names at once. Now looking at what your hand is doing is interesting: simon hand wanted to have a large number of methods so he tried to grab the corner. In terms of UI assessment, one guru said that we can debug 50% of the problems by asking people to speak aloud when they try an interface. So this is a cheap but really effective way of making progress. > We wanted to provide a concise and compact view of the shapes, due to the restrictions that the current Morphic is pixel based and not scalable, to take the most of the real estate of a pampas. Possibly once i migrate to a scalable and vectorized UI framework ( Morphic3 ?), resizing would be considered. You have a far easier solution if you want to let people work better. > 2) when I want to edit a method, the shape takes the full screen and I can't see any other data. Why can't I edit the method in-place >> > > > This was a decision i took, based on the fact that this lets you focus on writing that method only, similar to what Ommwriter proposes. http://www.ommwriter.com/ Bad bad bad idea. You never want to have a look at other code while programming. For me this will be the reason 1 for not using gaucho. Smalltalk is already bad because you have to open another browser but gaucho is a jail since you cannot even look at something else. > The idea is to provide a Control panel where the developer can customize the system in the next version. > >> >> Also, I find it quickly annoying when I have to place manually each shape created. It would be better if shapes tend to stick to their parent shape when created, and I can move them freely after (I think that one point where codebubbles is good). > > > This is also something for the next release, i also think that code bubbles has a good automatic layout strategy, and would like to provide something similar, or even better. > > >> I actually have more ideas about that, but it's tedious to explain by plain mail. >> > > I would love to hear them! I think this next ESUG would be an excellent place to meet and discuss. if you want to run a real user experience feedback I can be a guinea pig you can ask me to do some tasks and tape me. Stef > > > Thanks for the feedback ! > > > Fernando > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Tue, Jun 8, 2010 at 10:07 AM, Stéphane Ducasse <[hidden email]> wrote:
never -> always ? Laurent For me this will be the reason 1 for not using gaucho. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Stéphane Ducasse
On Jun 8, 2010, at 10:07 AM, Stéphane Ducasse wrote:
Stef, i was not speaking of font resize, we used the scroller widget to reveal hidden attributes or methods, and not shape resizing, providing a compact view of the shapes for the reasons above expressed. Every shape is has a fixed dimension of 340p x 400px, because we wanted to avoid getting rid of real state quickly and not being able to attack this problem with the current Morphic. Even though i agree that the hand behaves differently, and this in direct conflict with the habits of Pharo users, there is no "resize" handle of visual cue in the bottom corner of the shapes ( at least for now , till the Morphic dependency is dropped).
Thats why we needed to release it! To get good feed back like this one! You are right, occluding other methods shapes behind the Code editor view is to restricting. I'll modify this behavior ASAP.
Thanks Stef! I'll set up an experiment and will take your offer! Fernando _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Gaucho icons framework into Pharo1.1 ?
|
|
In reply to this post by Mariano Martinez Peck
On Jun 8, 2010, at 9:46 AM, Mariano Martinez Peck wrote:
OK, i agree. I'll follow Alain guidelines for including the icons framework into Pharo1.2.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Fernando olivero
>>
> > Stef, i was not speaking of font resize, we used the scroller widget to reveal hidden attributes or methods, and not shape resizing, providing a compact view of the shapes for the reasons above expressed. but may be the user can decide if he wants more :) > > Every shape is has a fixed dimension of 340p x 400px, because we wanted to avoid getting rid of real state quickly and not being able to attack this problem with the current Morphic. > > Even though i agree that the hand behaves differently, and this in direct conflict with the habits of Pharo users, there is no "resize" handle of visual cue in the bottom corner of the shapes ( at least for now , till the Morphic dependency is dropped). > > >>> 2) when I want to edit a method, the shape takes the full screen and I can't see any other data. Why can't I edit the method in-place >>>> >>> >>> This was a decision i took, based on the fact that this lets you focus on writing that method only, similar to what Ommwriter proposes. http://www.ommwriter.com/ >> >> Bad bad bad idea. >> You never want to have a look at other code while programming. >> For me this will be the reason 1 for not using gaucho. >> Smalltalk is already bad because you have to open another browser but gaucho is a jail since you cannot even >> look at something else. >> > > Thats why we needed to release it! To get good feed back like this one! You are right, occluding other methods shapes behind the Code editor view is to restricting. I'll modify this behavior ASAP. Good because else this is clearly a no go at all for me. I got enough frustrated with smalltalk editors. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |