Re: GORM usability enhancements
No there isn't. He's speaking of the outline view for classes and getting rid of the inspector (which is in line with the rest of the philosophy of Gorm) and enhancing the outline view way of editing classes (which is a violation of the "one way to do things" philosophy). I had meant to remove it, but it was too much a part of the development of the app. On Mon, Dec 23, 2019 at 8:44 PM Ivan Vučica wrote: > Speaking of outline views, I haven’t used Gorm in a while; is there now an > outline view of all objects in the nib? That’s what I was missing last time > I was building things in Gorm. > > > > *From: *Gregory Casamento > *Sent: *Monday 23 December 2019 21:49 > *To: *Sergii Stoian > *Cc: *GNUstep Developers > *Subject: *Re: GORM usability enhancements > > > > I don't want to tie people to the outline view. I already explained the > rationale of why in the last post. Classes should be treated like > everything else and be editable by inspectors. I, personally, think the > Outline view in Gorm should be done away with as it would eliminate this > confusion. > > > > On Fri, Dec 20, 2019 at 12:09 PM Sergii Stoian > wrote: > > I think it's quite confusing to do the same things with different tools in > one application. Probably some tool will be used more often than other. > This is a matter of application usability and learning curve. > > Could you explain to the evarage user of GORM: what are cases for Class > Editor and Class Editor Inspector usage and why? > > Anyway, it's up to you, Gregory. Thanks. > > > > On Fri, Dec 20, 2019 at 6:46 PM Gregory Casamento < > greg.casame...@gmail.com> wrote: > > I will not approve #3. The user should have multiple ways of editing the > class. The outline editor should not be the only way. It is consistent to > treat a class the same way we do objects via an inspector. > > > > On Fri, Dec 20, 2019, 11:08 AM Gregory Casamento > wrote: > > Please create a branch to be merged via a pull request. > > > > On Fri, Dec 20, 2019, 5:56 AM Sergii Stoian wrote: > > Hi, everybody. > > > > I use GORM application a lot. I think it's most comprehensive GNUstep > application. > > After a while I've noticed roughness in a various places across > application. So, finally, I've decided to spend some time and polish GORM > from usability point of view. Basically most of the changes will be done at > model files, but I suppose code will be touched also later. > > > > My plan is the following: > > 1. Enhancements in model files (conrtols positionning, autosizing, fonts, > menu items rearrangements). > > 2. Sort out focus change between controls and windows (I've noticed some > inconviences). > > 3. Document window changes: fix selection of objects, make object titles > editable (get rid of "Set Name" panel), finish and make usable Class Editor > outline editor (get rid of Class Editor Inspector). > > > > I see several options to do this with Git: > > 1. Push changes into master branch without pull requests. It seems good > for model files (1) > > 2. Create separate branch or fork and merge changes into master after I > finish. > > > > My questions to community: what option do you think I should go with? > > > -- > > Sergii Stoian > > > > -- > > Sergii Stoian, > > ProjectCenter lead developer > > NEXTSPACE owner, lead developer > > > > > -- > > Gregory Casamento > GNUstep Lead Developer / OLC, Principal Consultant > http://www.gnustep.org - http://heronsperch.blogspot.com > http://ind.ie/phoenix/ > > > -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com http://ind.ie/phoenix/
RE: GORM usability enhancements
Speaking of outline views, I haven’t used Gorm in a while; is there now an outline view of all objects in the nib? That’s what I was missing last time I was building things in Gorm. From: Gregory Casamento Sent: Monday 23 December 2019 21:49 To: Sergii Stoian Cc: GNUstep Developers Subject: Re: GORM usability enhancements I don't want to tie people to the outline view. I already explained the rationale of why in the last post. Classes should be treated like everything else and be editable by inspectors. I, personally, think the Outline view in Gorm should be done away with as it would eliminate this confusion. On Fri, Dec 20, 2019 at 12:09 PM Sergii Stoian wrote: I think it's quite confusing to do the same things with different tools in one application. Probably some tool will be used more often than other. This is a matter of application usability and learning curve. Could you explain to the evarage user of GORM: what are cases for Class Editor and Class Editor Inspector usage and why? Anyway, it's up to you, Gregory. Thanks. On Fri, Dec 20, 2019 at 6:46 PM Gregory Casamento wrote: I will not approve #3. The user should have multiple ways of editing the class. The outline editor should not be the only way. It is consistent to treat a class the same way we do objects via an inspector. On Fri, Dec 20, 2019, 11:08 AM Gregory Casamento wrote: Please create a branch to be merged via a pull request. On Fri, Dec 20, 2019, 5:56 AM Sergii Stoian wrote: Hi, everybody. I use GORM application a lot. I think it's most comprehensive GNUstep application. After a while I've noticed roughness in a various places across application. So, finally, I've decided to spend some time and polish GORM from usability point of view. Basically most of the changes will be done at model files, but I suppose code will be touched also later. My plan is the following: 1. Enhancements in model files (conrtols positionning, autosizing, fonts, menu items rearrangements). 2. Sort out focus change between controls and windows (I've noticed some inconviences). 3. Document window changes: fix selection of objects, make object titles editable (get rid of "Set Name" panel), finish and make usable Class Editor outline editor (get rid of Class Editor Inspector). I see several options to do this with Git: 1. Push changes into master branch without pull requests. It seems good for model files (1) 2. Create separate branch or fork and merge changes into master after I finish. My questions to community: what option do you think I should go with? -- Sergii Stoian -- Sergii Stoian, ProjectCenter lead developer NEXTSPACE owner, lead developer -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com http://ind.ie/phoenix/
Re: GORM usability enhancements
I don't want to tie people to the outline view. I already explained the rationale of why in the last post. Classes should be treated like everything else and be editable by inspectors. I, personally, think the Outline view in Gorm should be done away with as it would eliminate this confusion. On Fri, Dec 20, 2019 at 12:09 PM Sergii Stoian wrote: > I think it's quite confusing to do the same things with different tools in > one application. Probably some tool will be used more often than other. > This is a matter of application usability and learning curve. > Could you explain to the evarage user of GORM: what are cases for Class > Editor and Class Editor Inspector usage and why? > Anyway, it's up to you, Gregory. Thanks. > > On Fri, Dec 20, 2019 at 6:46 PM Gregory Casamento < > greg.casame...@gmail.com> wrote: > >> I will not approve #3. The user should have multiple ways of editing the >> class. The outline editor should not be the only way. It is consistent to >> treat a class the same way we do objects via an inspector. >> >> On Fri, Dec 20, 2019, 11:08 AM Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> >>> Please create a branch to be merged via a pull request. >>> >>> On Fri, Dec 20, 2019, 5:56 AM Sergii Stoian wrote: >>> Hi, everybody. I use GORM application a lot. I think it's most comprehensive GNUstep application. After a while I've noticed roughness in a various places across application. So, finally, I've decided to spend some time and polish GORM from usability point of view. Basically most of the changes will be done at model files, but I suppose code will be touched also later. My plan is the following: 1. Enhancements in model files (conrtols positionning, autosizing, fonts, menu items rearrangements). 2. Sort out focus change between controls and windows (I've noticed some inconviences). 3. Document window changes: fix selection of objects, make object titles editable (get rid of "Set Name" panel), finish and make usable Class Editor outline editor (get rid of Class Editor Inspector). I see several options to do this with Git: 1. Push changes into master branch without pull requests. It seems good for model files (1) 2. Create separate branch or fork and merge changes into master after I finish. My questions to community: what option do you think I should go with? -- Sergii Stoian >>> > > -- > Sergii Stoian, > ProjectCenter lead developer > NEXTSPACE owner, lead developer > -- Gregory Casamento GNUstep Lead Developer / OLC, Principal Consultant http://www.gnustep.org - http://heronsperch.blogspot.com http://ind.ie/phoenix/
Re: GORM usability enhancements
For everybody interested in topic, I've created a branch "UsabilityEnhancements". You can clone it with `git clone https://github.com/gnustep/apps-gorm -b UsabilityEnhancements` if you want to check for what is going on here. Feel free to send me a feedback. On Fri, Dec 20, 2019 at 7:09 PM Sergii Stoian wrote: > I think it's quite confusing to do the same things with different tools in > one application. Probably some tool will be used more often than other. > This is a matter of application usability and learning curve. > Could you explain to the evarage user of GORM: what are cases for Class > Editor and Class Editor Inspector usage and why? > Anyway, it's up to you, Gregory. Thanks. > > On Fri, Dec 20, 2019 at 6:46 PM Gregory Casamento < > greg.casame...@gmail.com> wrote: > >> I will not approve #3. The user should have multiple ways of editing the >> class. The outline editor should not be the only way. It is consistent to >> treat a class the same way we do objects via an inspector. >> >> On Fri, Dec 20, 2019, 11:08 AM Gregory Casamento < >> greg.casame...@gmail.com> wrote: >> >>> Please create a branch to be merged via a pull request. >>> >>> On Fri, Dec 20, 2019, 5:56 AM Sergii Stoian wrote: >>> Hi, everybody. I use GORM application a lot. I think it's most comprehensive GNUstep application. After a while I've noticed roughness in a various places across application. So, finally, I've decided to spend some time and polish GORM from usability point of view. Basically most of the changes will be done at model files, but I suppose code will be touched also later. My plan is the following: 1. Enhancements in model files (conrtols positionning, autosizing, fonts, menu items rearrangements). 2. Sort out focus change between controls and windows (I've noticed some inconviences). 3. Document window changes: fix selection of objects, make object titles editable (get rid of "Set Name" panel), finish and make usable Class Editor outline editor (get rid of Class Editor Inspector). I see several options to do this with Git: 1. Push changes into master branch without pull requests. It seems good for model files (1) 2. Create separate branch or fork and merge changes into master after I finish. My questions to community: what option do you think I should go with? -- Sergii Stoian >>> > > -- > Sergii Stoian, > ProjectCenter lead developer > NEXTSPACE owner, lead developer > -- Sergii Stoian, ProjectCenter lead developer NEXTSPACE owner, lead developer
Re: [gnustep/libs-gui] NSPopUpButton's popup menu in pulldown mode displaying fix (#43)
Hi, Do we have any decision? What's next? Do I need to do/fix something in context of this PR? On Sat, Dec 21, 2019 at 12:39 AM Sergii Stoian wrote: > On 20 Dec 2019, at 18:15, Wolfgang Lux wrote: > > > > > >> Am 20.12.2019 um 16:11 schrieb Fred Kiefer : > >> > >> ... > >> > >> There you just describe that now the popup looks the same whether in > pull down or in popup state. But what is the reason for this change? As I > wrote I am happy with getting rid of all this special code, but last time I > tried to do this it was rejected. > > > > I don't recall whether I was involved in that rejection or not, but if I > wasn't I'd think that it was the correct move. > > > > Regarding the different behavior with regard to the title cell, it > apparently dates back to the heyday of OpenStep (and presumably the > original NeXTstep as well). The idea seems to be that the title that is > visible in the pop up button cell when the menu is not visible should be > backed up by an element of the associated menu. In pop up mode this would > be the selected item, while in pull down mode it is invariably the first > element of the menu (since the title of the pull down is not supposed to > change depending on the user's last selection). I think that's nothing that > GNUstep can or should change. > > This is how it works before and after change. > > > That only leaves you with the option whether to display the title item > when the pull down is visible or to not display it. If you wanted to > display the title, the only reasonable choice for that would be such that > the title item appears above the button itself (because otherwise you would > redundantly display the same information twice). > > Correct. This is how it works after change. > > > But then that doesn't work that well if you display an icon in the > button cell rather than text (useful, for instance, when you want to make > NSToolbar buttons with an attached pull down menu) and the popup button's > width and/or height do not match the width or height of the menu (items). > Also beware that the menu does not necessarily need to appear at the bottom > of the pop up button. You can set the preferredEdge property of the button > cell to make it appear on one of the sides of the button (or even appear > attached to the top edge, although I don't see a reason for doing that). > But of course these are all aesthetic judgements so feel free to disagree. > > Good points. I guess these are the cases for further testing, changing and > separate PR. > > > > > Wolfgang > > > > Sergii -- Sergii Stoian, ProjectCenter lead developer NEXTSPACE owner, lead developer
