November 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Pharo-Project] About new TxText text model

by Camillo Bruni

On 2012-11-20, at 17:30, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > Hello. > > Can you add me as project contributor. I try to upload version with > detailed comment from my first mail but can't. > > 2012/11/18 Camillo Bruni <camillobruni(a)gmail.com> > >> I don't think the basic model should know about the visual lines. We >> discussed >> that for a while, but in the end that's purely a view on the basic model. >> > > If such behaviour will be at view simple Cursor>>moveUp/moveDown will never > work right from user perspective. So why you need cursor at text model > which will never reflect state of visual cursor at screen? it depends, I think the model should not take the view into account. First we implement the cursor movement as simple as possible, and that is for now on the model-base. If it will work properly or not depends on the view implementation. > To me text model should completly represent what user see at text view. > Otherwise why you call it model? Otherwise it is just raw data like Text in > current TextMorph Model IS the raw base model, the view is what you see, that are definitely two different things. For instance where would you deal with hyphenation? dynamic layouts? I don't think they belong in the model and I think we should stick to existing implementation schemes (M VC) and existing implementations like Cocoa...

Nov. 21, 2012

Re: [Pharo-project] About new TxText text model

by Camillo Bruni

Summary ------- TxText is work in progress On 2012-11-20, at 20:35, Stephan Eggermont <STEPHAN(a)STACK.NL> wrote: > Hi, > > I've taken a look at the TxText text model, and it seems rather limited. also do not forget that it's like pre-pre-alpha and not in use yet > I'm a bit confused about the expectations for this code: is this supposed to be just > for editing smalltalk methods? that's the first goal, but definitely not limited to that. > The current Text system looks to me more like a limited > implementation of the OpenStep/GNUStep/Cocoa text system. That separates concerns > and allows high quality layouts. exactly! we want to get rid of the shitty model we currently have in Pharo. With the current model we will never be able to implement a state-of-the-art text editor that supports decent sourcecode/ast interaction! > David Chisnall seems to know something about those systems > http://www.informit.com/articles/article.aspx?p=1602820 yup cocoa is more or less our vision for this, but you gotta start small. NOTE: Pharo does not even have a basic text model that works. - I cannot use the current text model to build anything but a Morphic UI - you add the Editors and you got a big bunch of interacting classes with no clear separation.

Nov. 20, 2012

Re: [Pharo-project] About new TxText text model

by Stephan Eggermont

Hi, I've taken a look at the TxText text model, and it seems rather limited. I'm a bit confused about the expectations for this code: is this supposed to be just for editing smalltalk methods? The current Text system looks to me more like a limited implementation of the OpenStep/GNUStep/Cocoa text system. That separates concerns and allows high quality layouts. David Chisnall seems to know something about those systems http://www.informit.com/articles/article.aspx?p=1602820 Cheers, Stephan

Nov. 20, 2012

Re: [Pharo-project] SortedCollection>>=

by Nicolas Cellier

Absolutely, it's as valid and as arbitrary as comparing blocks, so effectively, opinions will vary. Personal opinion weighted by personal aura certainly is a possible criterion. SIMPLICITY could be one good criterion too (We ain't gonna need it). Especially when you consider cost of learning, documenting, maintaining, testing... Here, we can easily document the behaviour... Seems lot harder to justify utility / cost ratio though. Of course changing has a cost too, but Pharo is definitely willing to pay this price. 2012/11/20 Hernan Wilkinson <hernan.wilkinson(a)10pines.com>: > I completely agree.... your explanation is far much better than mine :-) > > > On Tue, Nov 20, 2012 at 2:28 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> hmm, imo block comparison is superfluous. >> at the point of comparison, if two sorted collections happen to >> contain same elements with same order, i think, it is safe to assume >> them equal. >> >> the point is that block behavior influencing only the way how you add >> or remove elements from collection, >> as for the rest, collections will behave similar for all messages >> except from adding/deleting elements. >> but adding or deleting elements will immediately make them different, >> no matter what sort block is used. >> Sure, they are equivalent thru #do: not necessarily thru #add: There will always be one message for which objects behaviour will vary, things like #identityHash. To be sure whether an object can safely replace another, we can still use #== primitive (fortunately the cost of replacement is then very cheap). Nicolas >> >> On 19 November 2012 16:59, Hernan Wilkinson >> <hernan.wilkinson(a)10pines.com> wrote: >> > Hi, >> > I'm a little surprised with the current SortedCollection #= >> > implementation... it is: >> > >> > = aSortedCollection >> > "Answer true if my and aSortedCollection's species are the same, >> > and if our blocks are the same, and if our elements are the same." >> > >> > self species = aSortedCollection species ifFalse: [^ false]. >> > sortBlock = aSortedCollection sortBlock >> > ifTrue: [^ super = aSortedCollection] >> > ifFalse: [^ false] >> > >> > and my surprise is because it compares the sortBlocks that makes the >> > simplest case to fail like this one: >> > >> > (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection >> > sortBlock: [ :a :b | a < b ]) >> > >> > One could argue that if we remove the sortBlock comparison then : >> > >> > (SortedCollection sortBlock: [ :a :b | a < b ]) = (SortedCollection >> > sortBlock: [ :a :b | a > b ]) >> > >> > would return true... but is that wrong? ... or is the philosophy to use >> > the >> > message #hasEqualElements: on this cases? >> > >> > BTW, VisualWorks implementation is the same as pharo, but the >> > BlockClosure>>= is different and that's why it works as at least I >> > expected >> > :-) >> > >> > Bye, >> > Hernan >> > >> > -- >> > HernÃ¡n Wilkinson >> > Agile Software Development, Teaching & Coaching >> > Phone: +54 - 011 - 6091 - 3125 >> > Mobile: +54 - 911 - 4470 - 7207 >> > email: hernan.wilkinson(a)10Pines.com >> > site: http://www.10Pines.com >> > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > > > -- > HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching > Phone: +54 - 011 - 6091 - 3125 > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson(a)10Pines.com > site: http://www.10Pines.com > Address: Alem 693, Floor 5 B, Buenos Aires, Argentina >

Nov. 20, 2012

Re: [Pharo-project] Package-pane (or 6-paned) browser for Pharo?

by Geert Claes

Hi Stephen, Personally I struggle with creating a UI in Pharo/Squeak and there are plenty of experts on this forum but from a UX pov I do like the idea of a 2 (or multi) level category panel to make the first panel more manageable. It would also be nice to have the "...Tests" category nicely with the category it is testing. Although I reckon the way to clarify would be to have less complexity and panels rather than have more panels. Even the protocol panel could easilly be some dropdown box above the methods panel. I also find that the Instance/?/Class buttons should be some sort of tab or toggle above the last panel rather than buttons under the class panel :) Is the code for the 6 pane browser still available somewhere? -- View this message in context: http://forum.world.st/Package-pane-or-6-paned-browser-for-Pharo-tp4655495p4… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 20, 2012

Re: [Pharo-project] [ANN] Limbo: a simple shell wrapper for NativeBoost

by David T. Lewis

On Mon, Nov 19, 2012 at 05:46:14PM -0300, Igor Stasenko wrote: > > Providing bindings to fork/pipe kernel functions is piece of cake. > But writing a wrapper around it would be a bit of work.. but still it > is possible. And you should try. > > And yes, using fork() stuff having many treacherous pitfalls, but > don't think that if you call this function from code written in C > instead of NB will make it less treacherous. > I think Dave can give some more input on that, because he also using > fork() in OSProcess. In normal use, the fork() call is immediately followed by an exec(), so it is not tricky at all. The only thing that was tricky to do in OSProcess was forkSqueak() which forks the VM itself and then attempts to continue running. But that is really an unusual use case. The system calls such as fork() and pipe() should work the same whether you are calling from FFI or from generated C in a primitive. You can find examples for many of these calls in OSProcess. In general, the interface to system calls and standard C library functions is in UnixOSProcessPlugin, and the associated glue to tie it into the image is in UnixOSProcessAccessor. I have not looked at it closely but I think that in some cases you could change the methods in UnixOSProcessAccessor to make FFI calls, at least in order to get something working initially (I don't know if the design of OSProcess is what you want, but it could get you started). Dave

Nov. 20, 2012

Re: [Pharo-project] [Pharo-Project] About new TxText text model

by Denis Kudriashov

2012/11/21 Denis Kudriashov <dionisiydk(a)gmail.com> > Hello. > > Can you add me as project contributor. I try to upload version with > detailed comment from my first mail but can't. > My smalltalkhub nickname "dionisiy"

Nov. 20, 2012

Re: [Pharo-project] [Pharo-Project] About new TxText text model

by Denis Kudriashov

2012/11/16 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Text model based on sequence of span objects. There are now two kind of > spans: CharacterSpan and LineSeparator. Each span has reference to next and > previous spans. There is TxSelection object which contains cursor. So you > can insert new text at cursor, you can cut selection, replace selection > with another text. Such maniulation changes text model structure. It can > create new span objects. It can split current span at cursor position, It > can remove selected spans. Also you can move cursor up, down, left, right. > Cursor always know about current span and span position. > > If this is not in the class comments can you add it? When I will have permissions

Nov. 20, 2012

Re: [Pharo-project] [Pharo-Project] About new TxText text model

by Denis Kudriashov

Hello. Can you add me as project contributor. I try to upload version with detailed comment from my first mail but can't. 2012/11/18 Camillo Bruni <camillobruni(a)gmail.com> > I don't think the basic model should know about the visual lines. We > discussed > that for a while, but in the end that's purely a view on the basic model. > If such behaviour will be at view simple Cursor>>moveUp/moveDown will never work right from user perspective. So why you need cursor at text model which will never reflect state of visual cursor at screen? To me text model should completelly represent what user see at text view. Otherwise why you call it model? Otherwise it is just raw data like Text in current TextMorph. > For instance if you want to get the insertion point when clicking on some > text view you have to take so many model-unrelated things into account > (global transformation, font sizes). > I think It can be solve easilly if text model will reflect visual lines of text. For example, imagine my simple idea where TextView is just list of SpanMorph's. When user click on text concrete span morph will handle it because TextView is just morph with submorphs (no special behaviour). So target SpanMorph should just compute span position under mouse and change text model cursor position appropriatelly. Then cursor will announce #changed event and CursorMorph will reflect this automatically. 3) What about auto wrap behaviour? > If you have auto wrap option at text editors you have line width > restriction. And you should spit real lines of text to visual lines which > satisfed this restriction. And text mode should know about such restriction > because any text insertion can require new visual lines creation. > I think insertion single line text at span position should be executed by > special "restriction object". It should return new characters of span which > satisfied that restriction. And it should return new span object (or just > remains characters) which will present new visual lines. Then this "remains > characters" should be inserted to next span at 0 position. > When wrap behavior not needed "restriction object" just inserts new text > into current characters at given position and returns result. > Just remember two kinds of such line width restrictions: width in pixels and width in characters. First is usual text wrapping behaviour when line width restricted by view width. Last is when editor wrap lines which contains >100 characters for example.

Nov. 20, 2012

[Pharo-project] [update 2.0] #20414

by Marcus Denker

20414 ----- Issue 7008: clean unsent messages in StringHolder Hierarchy http://code.google.com/p/pharo/issues/detail?id=7008 Issue 7009: clean up CharacterScanner a little http://code.google.com/p/pharo/issues/detail?id=7009 Issue 7015: Form>>#fromBinaryStream: dependent on ImageReadWriter http://code.google.com/p/pharo/issues/detail?id=7015 Diff information: http://ss3.gemstone.com/ss/Pharo20/Tools-MarcusDenker.988.diff http://ss3.gemstone.com/ss/Pharo20/Text-MarcusDenker.38.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.96.diff -- Marcus Denker -- http://marcusdenker.de

Nov. 20, 2012