VisualGST
Locked
 
|
Hi,
I would like to have your opinion about a possible change on VisualGST UI, there is a guy (that is working on an IDE) that send a nice comment: there are too much widgets on the screen. That's true and this is something I've in mind for such a time but yesterday I've hacked a bit VisualGST and made a simple prototype (this is just a "new" widget): http://www.youtube.com/watch?v=-B4s6niwZEw or you can try the browserWidget branch on VisualGST git Now I want to merge the transcript (should be replaced by a kind of log tool), the workspace and the source widget. They are not exactly the same but share same functionalities the user can evaluate/inspect/debug but the major difference I want to introduce is the idea of "scope" inside a Namespace the source widget will work like a normal workspace inside a class too but inside a method. The idea of scoping could be reuse with the sender/implementor tools the searching could be scoped inside a namespace/class/... I could reuse extra free space with a right pane that display meta information of the scope: namespace or package (package info, ...), history, bug report, changes, code critic, ... Any comments suggestions are welcome ;-) Cheers, Gwen _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
On Domingo, 20 de Marzo de 2011 10:01:20 Gwenael Casaccio escribió:
> Hi, > > I would like to have your opinion about a possible change > on VisualGST UI, there is a guy (that is working on an IDE) > that send a nice comment: there are too much widgets on the screen. > That's true and this is something I've in mind for such > a time but yesterday I've hacked a bit VisualGST > and made a simple prototype (this is just a "new" widget): > > http://www.youtube.com/watch?v=-B4s6niwZEw > > or you can try the browserWidget branch on VisualGST git > > Now I want to merge the transcript (should be replaced by > a kind of log tool), the workspace and the source widget. They are not > exactly the same but share same functionalities the user can > evaluate/inspect/debug but the major difference I want to introduce is > the idea of "scope" inside a Namespace the source widget will work like > a normal workspace inside a class too but inside a method. The idea of > scoping could be reuse with the sender/implementor tools the searching > could be scoped inside a namespace/class/... > > I could reuse extra free space with a right pane that display meta > information of the scope: namespace or package (package info, ...), > history, bug report, changes, code critic, ... > > Any comments suggestions are welcome ;-) There are a lot of widgets true, but this is usefull in Smalltalt, not in other languages perhaps. In smalltalk is very usefull to change fast between namespaces/categories objects, protocols and messages, having more than 2 or 3 browsers opened. Probably, there is a way to show all this information better than the actual, but I think, trimming the windows is not the best way to go IMHO. The guy who commented, probably comes from other language, where this type of working doesn't have sense. The best smalltalk UI I saw was Dolphin[1], probably you can take ideas from it. If you don't know it, you can check it in action in this series of videos [1] [1] http://www.object- arts.com/support/videos_files/21163c4401ba2928d4e0c1ca319c04c7-1.html _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
On 03/20/2011 11:52 AM, Giuseppe Luigi Punzi wrote:
> On Domingo, 20 de Marzo de 2011 10:01:20 Gwenael Casaccio escribió: >> Hi, >> >> I would like to have your opinion about a possible change >> on VisualGST UI, there is a guy (that is working on an IDE) >> that send a nice comment: there are too much widgets on the screen. >> That's true and this is something I've in mind for such >> a time but yesterday I've hacked a bit VisualGST >> and made a simple prototype (this is just a "new" widget): >> >> http://www.youtube.com/watch?v=-B4s6niwZEw >> >> or you can try the browserWidget branch on VisualGST git >> >> Now I want to merge the transcript (should be replaced by >> a kind of log tool), the workspace and the source widget. They are not >> exactly the same but share same functionalities the user can >> evaluate/inspect/debug but the major difference I want to introduce is >> the idea of "scope" inside a Namespace the source widget will work like >> a normal workspace inside a class too but inside a method. The idea of >> scoping could be reuse with the sender/implementor tools the searching >> could be scoped inside a namespace/class/... >> >> I could reuse extra free space with a right pane that display meta >> information of the scope: namespace or package (package info, ...), >> history, bug report, changes, code critic, ... >> >> Any comments suggestions are welcome ;-) > > There are a lot of widgets true, but this is usefull in Smalltalt, not in > other languages perhaps. > > In smalltalk is very usefull to change fast between namespaces/categories > objects, protocols and messages, having more than 2 or 3 browsers opened. > Probably, there is a way to show all this information better than the actual, > but I think, trimming the windows is not the best way to go IMHO. > > The guy who commented, probably comes from other language, where this type of > working doesn't have sense. > > The best smalltalk UI I saw was Dolphin[1], probably you can take ideas from > it. > > If you don't know it, you can check it in action in this series of videos [1] > > [1] http://www.object- > arts.com/support/videos_files/21163c4401ba2928d4e0c1ca319c04c7-1.html > > _______________________________________________ > help-smalltalk mailing list > [hidden email] > http://lists.gnu.org/mailman/listinfo/help-smalltalk I'll take a look at the video thanks for the link. Changes can be fast too with the button on top - a kind of address bar - or with shortcuts. Also I can add an line edit where you can go quickly to a point with auto completion. For me trimming makes sens because I can go to the direction of Code Bubble IDE (http://java.dzone.com/articles/code-bubbles-ide-revolution) but I think I can keep both widgets - full browser widget or a lightweight widget ;-) This is much more a question of flexibility and design everybody should be able choose what it wants. Gwen _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
In reply to this post by MrGwen
I think the reaction was also a little bit due to the first screenshot:
http://imagik.fr/view-rl/341692 which has two extra panes open. And also the browser's window size on the shot is smaller than even 800x600, all IDEs look more cluttered in small windows. On the other hand, I don't say VisualGST's interface is very plain and simple. Especially when more panes or tabs are open it gets pretty cluttered. The new prototype is a nice approach, reminds me of Nautilus. But it might reduce the speed of the coder because it requires more clicks to move aroud. For example you have to click on "Smalltalk" button on top to see the list of the objects inside Smalltalk namespace (I guess?), while in the current browser the list is already open anytime. Same with the namespace list, class list, method list etc. Some suggestions to the current design might be: - Merging namespace and class list into one to gain some space. Switching namespaces occurs less frequently, you generally stay in the namespace of your project. So a tree which includes both namespaces and classes together won't make any difference except that there will be three main lists on top of the browser like the classic class browser of Smalltalk has instead of four. It would look like this: -Namespace 1 ---Class 1 ---Class 2 -Namespace 2 ---Namespace 3 ------Class 3 ------Class 4 ---Namespace 4 ------Class 5 I think, though, this is not needed for a normal size monitor since there is enough space for four lists on top. For those who work on netbooks etc. it might be useful. - Removing the whole border around the code multi line text entry which says "Code" on top to improve the look. It might be necessary to make it clear to a programmer who have not used class browser before but it is such a basic pane whose usage is very obvious after a few seconds of trial and error that it might be removed. - Putting some padding inside multi line text entries to improve the typography. On code text area, workspace and transcript there is no padding around text, they touch to the border of the text area. It would improve the readability to put some padding (like 3-4 px).
Canol Gökel
|
|
|
In reply to this post by MrGwen
And for those who love to type ;-) I've made a new source widget
http://imagik.fr/view-rl/388579 Cheers, Gwen On Sun, Mar 20, 2011 at 10:01 AM, Gwenael Casaccio <[hidden email]> wrote: > Hi, > > I would like to have your opinion about a possible change > on VisualGST UI, there is a guy (that is working on an IDE) > that send a nice comment: there are too much widgets on the screen. > That's true and this is something I've in mind for such > a time but yesterday I've hacked a bit VisualGST > and made a simple prototype (this is just a "new" widget): > > http://www.youtube.com/watch?v=-B4s6niwZEw > > or you can try the browserWidget branch on VisualGST git > > Now I want to merge the transcript (should be replaced by > a kind of log tool), the workspace and the source widget. They are not > exactly the same but share same functionalities the user can > evaluate/inspect/debug but the major difference I want to introduce is the > idea of "scope" inside a Namespace the source widget will work like a normal > workspace inside a class too but inside a method. The idea of scoping could > be reuse with the sender/implementor tools the searching could be scoped > inside a namespace/class/... > > I could reuse extra free space with a right pane that display meta > information of the scope: namespace or package (package info, ...), history, > bug report, changes, code critic, ... > > Any comments suggestions are welcome ;-) > > Cheers, > Gwen > _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
In reply to this post by MrGwen
On Sun, Mar 20, 2011 at 10:01, Gwenael Casaccio <[hidden email]> wrote:
> That's true and this is something I've in mind for such > a time but yesterday I've hacked a bit VisualGST > and made a simple prototype (this is just a "new" widget): > > http://www.youtube.com/watch?v=-B4s6niwZEw > > or you can try the browserWidget branch on VisualGST git It is interesting indeed. I like the idea. However, please make sure that it is implemented with a sane state model---such as my newState experiment, though not necessarily that one. The biggest bug (not limitation!) in VisualGST right now is that the behavior is quite unpredictable when you entered code that does not compile. However, the obvious devil's advocate question is: why do you like this, but not merging the transcript/workspace tab strip with the browsers tabstrip? > Now I want to merge the transcript (should be replaced by > a kind of log tool), the workspace and the source widget. They are > not exactly the same but share same functionalities the user can > evaluate/inspect/debug but the major difference I want to introduce is > the idea of "scope" inside a Namespace the source widget will work > like a normal workspace inside a class too but inside a method. That's nice indeed. Adding Namespace selection to a workspace is a very good idea, especially if we can get rid of the Namespace>>#current: method in 3.3. However, remember that a workspace has the additional functionality of tracking undefined variables. How would that fit? Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
|
|
In reply to this post by MrGwen
On 03/20/2011 01:42 PM, Gwenael Casaccio wrote:
> I think > I can keep both widgets - full browser widget or a lightweight widget > ;-) This is much more a question of flexibility and design everybody > should be able choose what it wants. Hmm, no, I don't like that... there should be only one widget. Otherwise one of the two will bitrot, and the "revolutionary" one will unlikely become complete. Paolo _______________________________________________ help-smalltalk mailing list [hidden email] http://lists.gnu.org/mailman/listinfo/help-smalltalk |
«
Return to Gnu
|
1 view|%1 views
| Free forum by Nabble | Edit this page |