Re: [Pharo-dev] TxText new version 0.8
On 23 May 2013, at 10:19, Sven Van Caekenberghe s...@stfx.eu wrote: On 23 May 2013, at 10:12, Norbert Hartl norb...@hartl.name wrote: Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe s...@stfx.eu: Hmm, there are different views possible on this. Absolutely! We should never give up the possibility of building/constructing really small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open. That's my only point. Having tests packaged separately just opens the possibility to make things smaller. I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable. agreed. I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO. That is the funny part in this discussion. I stopped minimizing them as well. On most images I use RFB and like to have the full fledge installation being present. I stopped even to use cleanUpForProduction because it removes SUnit. I hook up SUnit to rest handlers and trigger them from the outside to do runtime sanity checks, e.g. used by monit. That is a cool trick ! So cool that I want to make that into a general purpose Zn handler (totally optional and on localhost only of course) ;-) And so I did: --- Name: Zinc-HTTP-SvenVanCaekenberghe.363 Author: SvenVanCaekenberghe Time: 28 May 2013, 10:38:03 am UUID: a1fa8795-eb44-4812-81e7-3da28fa9bda9 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.362 Implemented ZnTestRunnerDelegate (original idea by Norbert Hartl - Thx) Minor optimalization to ZnUtils class#nextPutAll:on: --- $ curl http://localhost:1701/sunit/ZnUtilsTests 15 run, 15 passes, 0 skipped, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes $ curl http://localhost:1701/sunit/ZnUtilsTests/testBase64 1 run, 1 passes, 0 skipped, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes The above are 200 responses, a failure will be a 500 response. With specifically written tests this could be quite useful for monit checks. Sven PS: The service is off by default, and when on only exposed to localhost, don't change this without thinking about the consequences ! Norbert On 23 May 2013, at 09:43, Camillo Bruni camillobr...@gmail.com wrote: On 2013-05-23, at 09:35, Norbert Hartl norb...@hartl.name wrote: Am 23.05.2013 um 09:18 schrieb Camillo Bruni camillobr...@gmail.com: technically yes, but you do not need many things to run the code: - class comments - method comments - any documentation in general And I don't have it at production because I don't have changes file here. yet you load them. so I wonder if it makes sense to even load tests separately? It make sense when you try to reduce production image size. And loading only required packages (without tests) works well. Why change it? I know that this scheme is in use, but why? why do I have to reduce the size of a production image? from how many to many megabytes? It might make sense for moose, but none of the other projects. Do you really care if the image is 35 instead of 25MB? To me this argument sounds invalid :/ I can tell from a server deployment perspective. A production image should only contain the source it really needs. Additional not-used code cannot have a benefit but it could cause side effects (breaking things, slowing things down, opening security holes, etc…). So you reduce it to the bare essentials. Having less code also makes an image faster which is not a noticable effect but it is there. Finally if you want to have 48 images (that can be feasible on a 16 core machine) on your machine then it would sum up to 480 MB which is less memory for additional images or OS I/O cache which in turn makes your machine slower. Not carrying about memory at all is a typical view point that the java community developed. But your professional acting should be reasonable. That means for every action should have a reason. At best a good reason. Growing the image by supporting new possibilties and tools is a good reason. Just wasting memory because it is easier to load a huge bunch is IMHO not a good reason. So I conclude that for a production ready image you want to strip out as much as possible: - tests - comments (luckily in the changes file...) - source code (luckily in the changes file...) - monticello metadata (which was around 5MB or so, did anybody care?) - font files that linger around (also around 2MB, and also mostly ignored) which sort of makes sense, however for that you
Re: [Pharo-dev] TxText new version 0.8
so that means nobody *actually* loads code without tests? :D (evil laugh). But i do not argue about what is the be best deployment scenario. I am arguing about leaving developers to choose: - if (s)he wants to deploy with tests or not, it should be up to him. it's also up to him to - write configurations - write tests - write documentation and examples - commit code to a repository - create jenkins jobs you see, there are many things that one can avoid to do in a project, yet it is a common standard to do ALL of these tasks for a project. Yet you have your liberty to ignore these things. It is about the good path and how you push people towards it. If you do not provide the tools for it we will be stuck in stone age forever. It has never been the liberty of ignoring things that brought a project forward, but the tools that open new possibilities. How does an ideal project look for you?
Re: [Pharo-dev] TxText new version 0.8
Am 25.05.2013 um 13:22 schrieb Igor Stasenko siguc...@gmail.com: On 25 May 2013 11:44, Camillo Bruni camillobr...@gmail.com wrote: so that means nobody *actually* loads code without tests? :D (evil laugh). But i do not argue about what is the be best deployment scenario. I am arguing about leaving developers to choose: - if (s)he wants to deploy with tests or not, it should be up to him. it's also up to him to - write configurations - write tests - write documentation and examples - commit code to a repository - create jenkins jobs you see, there are many things that one can avoid to do in a project, yet it is a common standard to do ALL of these tasks for a project. Yet you have your liberty to ignore these things. It heavily depends what kind of project is it. For small/tiny projects following all steps/recommendations may be not necessary and actually cumbersome. Consider pilot projects as well. For frameworks, mid to big projects or any project with intent to be used by others, of course, building up an ecosystem (docs, tests, examples etc) is necessary. It is about the good path and how you push people towards it. If you do not provide the tools for it we will be stuck in stone age forever. It has never been the liberty of ignoring things that brought a project forward, but the tools that open new possibilities. How does an ideal project look for you? Ideal project has tests, docs, examples books, flyers with ad, sales managers and profit :) But things are never ideal, and you always looking for a sweet spot between: - time - resources - features and in situations when you lack of time resources (usual for open-source projects), you have to pick what features to implement first, and which have to wait. You simply cannot afford to do everything in time, and hence you need to prioritize things. Writing documentation before 1st line of code, or otherwise? But this is orthogonal to my point. I see little point in keeping tests in deployed image. It is good to have tests, and run them regularly while developing, using SCM, continuous integration, writing docs, examples etc etc.. Consider deploying database application. To run all the tests for it may take days, often will require setting up special testing environment (outside of image) and many other things.. That means , even if you will keep those tests in image, you will be never able to run them in deployed environment, simply because this will mean: stopping all services, changing configs, firewalls.. etc.. So, do you really think that in such scenario (which actually typical for most server-based applications), having tests in deployed image makes any difference? Yes, yes and yes. I agree with everything you said. Norbert
Re: [Pharo-dev] TxText new version 0.8
Yes, I think this is good at this point. When the mapping will disappear, things will become simpler. Doru On Thu, May 23, 2013 at 8:11 AM, Denis Kudriashov dionisi...@gmail.comwrote: 2013/5/22 Tudor Girba tu...@tudorgirba.com So, the pattern I know of is to put the Tests as a discriminator before the variable part of your code. So, something like: - BaseName-Core - BaseName-Tests-Core It is exactly my pattern but with dash before Tests word: -TxText-Model -TxTextTests-Model -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] TxText new version 0.8
Am 23.05.2013 um 02:35 schrieb Igor Stasenko siguc...@gmail.com: ProjectName-Core ProjectName-Extras ProjectName-Tests That approach has a limited scope. Because we match by prefix you have to do -Core and not just ProjectName. In a decent amount of projects -Core and -Extras will grow and you will have tests for -Core and -Extras and you don't want to combine them into a single -Tests package. But what do you do? ProjectName-Core-Core ProjectName-Core-Tests ?? Surely not. From this perspective one can look the way seaside does it. It is ProjectName-Core ProjectName-Extras ProjectName-Tests-Core ProjectName-Tests-Extras So there are multiple possibilities how to achieve it. I always start my projects by keeping tests inside the same package as the rest of the code. Well, I have the habit to mostly create a -Core package at the beginning. Later of the module grows I put -Tests in an extra package. And in one big project I did the seaside approach by putting the -Tests after the ProjectName. This way you don't have too much problems until you introduce platform dependent packages. Norbert
Re: [Pharo-dev] TxText new version 0.8
technically yes, but you do not need many things to run the code: - class comments - method comments - any documentation in general And I don't have it at production because I don't have changes file here. yet you load them. so I wonder if it makes sense to even load tests separately? It make sense when you try to reduce production image size. And loading only required packages (without tests) works well. Why change it? I know that this scheme is in use, but why? why do I have to reduce the size of a production image? from how many to many megabytes? It might make sense for moose, but none of the other projects. Do you really care if the image is 35 instead of 25MB? To me this argument sounds invalid :/
Re: [Pharo-dev] TxText new version 0.8
technically yes, but you do not need many things to run the code: - class comments - method comments - any documentation in general yet you load them. so I wonder if it makes sense to even load tests separately? for me there is one big reason to put tests in separate package: modularity. modularity? what does that have to do with tests? Tests are first class participants of software (well some DO NOT WRITE TESTS). So modularity does not count. There are even class tests which map 1 to 1 to existing classes. How does modularity hold up here? My point is the following: Tests ARE functional documentation and thus should be shipped under any circumstance with the rest of the code. I usually care a little about modularity when writing tests (they can use anything from anything, as long as test fulfills its purpose and covers the functionality i need).. But in regular code i cannot afford that , because then Kernel will start depending on Morphic etc.. wait what? that's a 2 level contradiction here :/
Re: [Pharo-dev] TxText new version 0.8
Not even for Moose it makes sense to deploy without tests :) Doru On Thu, May 23, 2013 at 9:18 AM, Camillo Bruni camillobr...@gmail.comwrote: technically yes, but you do not need many things to run the code: - class comments - method comments - any documentation in general And I don't have it at production because I don't have changes file here. yet you load them. so I wonder if it makes sense to even load tests separately? It make sense when you try to reduce production image size. And loading only required packages (without tests) works well. Why change it? I know that this scheme is in use, but why? why do I have to reduce the size of a production image? from how many to many megabytes? It might make sense for moose, but none of the other projects. Do you really care if the image is 35 instead of 25MB? To me this argument sounds invalid :/ -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] TxText new version 0.8
Am 23.05.2013 um 09:43 schrieb Camillo Bruni camillobr...@gmail.com: On 2013-05-23, at 09:35, Norbert Hartl norb...@hartl.name wrote: Am 23.05.2013 um 09:18 schrieb Camillo Bruni camillobr...@gmail.com: technically yes, but you do not need many things to run the code: - class comments - method comments - any documentation in general And I don't have it at production because I don't have changes file here. yet you load them. so I wonder if it makes sense to even load tests separately? It make sense when you try to reduce production image size. And loading only required packages (without tests) works well. Why change it? I know that this scheme is in use, but why? why do I have to reduce the size of a production image? from how many to many megabytes? It might make sense for moose, but none of the other projects. Do you really care if the image is 35 instead of 25MB? To me this argument sounds invalid :/ I can tell from a server deployment perspective. A production image should only contain the source it really needs. Additional not-used code cannot have a benefit but it could cause side effects (breaking things, slowing things down, opening security holes, etc…). So you reduce it to the bare essentials. Having less code also makes an image faster which is not a noticable effect but it is there. Finally if you want to have 48 images (that can be feasible on a 16 core machine) on your machine then it would sum up to 480 MB which is less memory for additional images or OS I/O cache which in turn makes your machine slower. Not carrying about memory at all is a typical view point that the java community developed. But your professional acting should be reasonable. That means for every action should have a reason. At best a good reason. Growing the image by supporting new possibilties and tools is a good reason. Just wasting memory because it is easier to load a huge bunch is IMHO not a good reason. So I conclude that for a production ready image you want to strip out as much as possible: If we assume that we have a use case where it is a requirement, yes! I didn't want to tell it is needed for every deployment. - tests yes, because tests are not used and tests are code that depends on other modules. - comments (luckily in the changes file…) I didn't know comments can be in-image. But if so I would say: If this can be done in a feasible way and saving memory is king then yes I would do it. - source code (luckily in the changes file…) same as for comments - monticello metadata (which was around 5MB or so, did anybody care?) This one thing that is done by cleanUpForProduction. Btw. cleanUpForProduction is exactly what I mean, a workflow to clean unnecessary stuff. - font files that linger around (also around 2MB, and also mostly ignored) Yes, I think cleanUpForProduction does this as well. Being able to disable freetype, unload the freetype stuff and have a small bitmap font that can be used as a replacement is good. which sort of makes sense, however for that you will need a custom tool, which is orthogonal to being able to load tests in a separate package. And the test only contribute to the static code base, whereas in a live production environment I would expect to have more live objects (I am guessing here)?. The tool is cleanUpForProduction. I don't know how you define orthogonality and so I don't get the second sentence. What is a static code base in smalltalk? .sources/.changes? Aren't there classes, class initializations, etc. whenever you load additional code? Maybe you can elaborate on that point. So for a production environment, if you want to get these small MB savings on the image you need a decent script. I would really like to have real numbers on how much the tests contribute to the total size. If you want to save size it doesn't matter how much it is as long as there is an easy way to save it. But this is not only about size. Code that gets loaded might do things in class initialization that opens a security hole or it might that just the presence of the code makes it more vulnerable. I don't like to discuss security issues here. My statement is that in production every single piece that is not used doesn't bring any benefit but it can waste memory, cpu cycles and open security holes. So what reasons can be there to load that stuff if you easily can avoid it? Norbert
Re: [Pharo-dev] TxText new version 0.8
I would use TextModelCore TextModelExtensions TextModelCore-Tests No extra dash in the middle. Stef On May 21, 2013, at 10:24 PM, Denis Kudriashov dionisi...@gmail.com wrote: 2013/5/21 stephane ducasse stephane.duca...@free.fr On May 21, 2013, at 9:00 AM, Denis Kudriashov dionisi...@gmail.com wrote: 2013/5/20 stephane ducasse stephane.duca...@free.fr Hello. New TxText version 0.8 is ready: - editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor may be you should call the second package TxTextEditor-Tests I just follow convention of other TxText packages: TxText-Model - TxTextTests-Model, TxText-Layout - TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0 So what the correct way (Pharo way) to name test packages? For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package should be? Stef
Re: [Pharo-dev] TxText new version 0.8
On 22 May 2013 10:38, Stéphane Ducasse stephane.duca...@inria.fr wrote: I would use TextModelCore TextModelExtensions TextModelCore-Tests No extra dash in the middle. no :) But for tests, i +1, the names are not very good. For package: Package-Name-Tick-Tack tests should be in: Package-Name-Tick-Tack-Tests This convention used everywhere in pharo. Stef On May 21, 2013, at 10:24 PM, Denis Kudriashov dionisi...@gmail.com wrote: 2013/5/21 stephane ducasse stephane.duca...@free.fr On May 21, 2013, at 9:00 AM, Denis Kudriashov dionisi...@gmail.com wrote: 2013/5/20 stephane ducasse stephane.duca...@free.fr Hello. New TxText version 0.8 is ready: - editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor may be you should call the second package TxTextEditor-Tests I just follow convention of other TxText packages: TxText-Model - TxTextTests-Model, TxText-Layout - TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0 So what the correct way (Pharo way) to name test packages? For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package should be? Stef -- Best regards, Igor Stasenko.
Re: [Pharo-dev] TxText new version 0.8
On 2013-05-22, at 21:04, Tudor Girba tu...@tudorgirba.com wrote: Hi, On May 22, 2013, at 5:33 PM, Igor Stasenko siguc...@gmail.com wrote: On 22 May 2013 10:38, Stéphane Ducasse stephane.duca...@inria.fr wrote: I would use TextModelCore TextModelExtensions TextModelCore-Tests No extra dash in the middle. no :) But for tests, i +1, the names are not very good. For package: Package-Name-Tick-Tack tests should be in: Package-Name-Tick-Tack-Tests This convention used everywhere in pharo. Please do not do that :). If you do that, publishing Package-Name-Tick-Tack will publish the code from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely implicit one-to-many mapping. So, the pattern I know of is to put the Tests as a discriminator before the variable part of your code. So, something like: - BaseName-Core - BaseName-Tests-Core But, the rule I apply more recently for code is to use - only for categories, and camel case for the Monticello packages. Like this we also document what is the unit of publishing, thus when you look into the code browser we also know what is mapped on a Monticello package. I would love to change that rule. I think Tests have the same value as the code itself. The only reason to not load the code is the load time for the configuration. Which is basically is unimportant if you have a CI server preparing images for you. I can only speak for smaller projects, but I really do not sea a reason to not load tests...
Re: [Pharo-dev] TxText new version 0.8
On May 21, 2013, at 9:00 AM, Denis Kudriashov dionisi...@gmail.com wrote: 2013/5/20 stephane ducasse stephane.duca...@free.fr Hello. New TxText version 0.8 is ready: - editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor may be you should call the second package TxTextEditor-Tests I just follow convention of other TxText packages: TxText-Model - TxTextTests-Model, TxText-Layout - TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0 Stef
Re: [Pharo-dev] TxText new version 0.8
Denis Kudriashov wrote: 2013/5/20 Igor Stasenko siguc...@gmail.com On 19 May 2013 22:01, Denis Kudriashov dionisi...@gmail.com wrote: TxInsertModeEditDecorator - input with "insert mode" where any new character replace next one. insert mode is actually opposite - inserts when you type. replace mode is replaces when you type. I choose this name because on Windows you have "insert key" to activate such mode in many text editors. I agree with Igor on this one. The "insert key" toggles between Insert Mode and Overwrite Mode - but the "key" is not the "mode" - it only triggers the transition between the two modes. The perception that the "insert key" is more strongly related Overwrite Mode is an illusion since most text editors are in Insert Mode by default. Per your description TxOverwritetModeEditDecorator would be more correct. Supporting info... [1] http://help.sap.com/saphelp_45b/helpdata/en/73/69ecc655bb11d18968e829fbbd/content.htm [2] http://publib.boulder.ibm.com/infocenter/symphony/v1r1/index.jsp?topic=/com.ibm.help.symphony12.doc/text/common/02/2004.html I will be happy if you introduce more clever names. Good names is difficult task for single brain. Especially if you are not native english speaker. But many of you already suggest different names. How we can agree on any one? Sometimes only by thrashing it around to wear off the rough edges. btw, I really enjoy reading about your advances with TxText. From a distance, it just seems like its going to make interesting things easier to do in the future. cheers -ben
Re: [Pharo-dev] TxText new version 0.8
I make changes which you suggest. So new version 0.9 published Renames: TxNoneEditDecorator-TxNullEditDecorator TxInsertModeEditDecorator-TxOverwriteModeEditDecorator And new TxSecretEditDecorator for password like fields. Best regards, Denis 2013/5/21 b...@openinworld.com ** Denis Kudriashov wrote: 2013/5/20 Igor Stasenko siguc...@gmail.com siguc...@gmail.com On 19 May 2013 22:01, Denis Kudriashov dionisi...@gmail.com dionisi...@gmail.com wrote: TxInsertModeEditDecorator - input with insert mode where any new character replace next one. insert mode is actually opposite - inserts when you type. replace mode is replaces when you type. I choose this name because on Windows you have insert key to activate such mode in many text editors. I agree with Igor on this one. The insert key toggles between Insert Mode and Overwrite Mode - but the key is not the mode - it only triggers the transition between the two modes.The perception that the insert key is more strongly related Overwrite Mode is an illusion since most text editors are in Insert Mode by default. Per your description TxOverwritetModeEditDecorator would be more correct. Supporting info... [1] http://help.sap.com/saphelp_45b/helpdata/en/73/69ecc655bb11d18968e829fbbd/content.htm [2] http://publib.boulder.ibm.com/infocenter/symphony/v1r1/index.jsp?topic=/com.ibm.help.symphony12.doc/text/common/02/2004.html I will be happy if you introduce more clever names. Good names is difficult task for single brain. Especially if you are not native english speaker. But many of you already suggest different names. How we can agree on any one? Sometimes only by thrashing it around to wear off the rough edges. btw, I really enjoy reading about your advances with TxText. From a distance, it just seems like its going to make interesting things easier to do in the future. cheers -ben
Re: [Pharo-dev] TxText new version 0.8
Hi
2013/5/21 p...@highoctane.be p...@highoctane.be
Why not TxBaseEditDecorator ?
For me null (or non) prefix better fit general idea about edit decorators.
Edit decorators executes specific actions on text to perform basic edit
operations. TxNullEditDecorator is doing nothing except basic edit
operations.
Also before I introduce edit decorator object TxEditor performs edit
operations by itself. So TxNullEditDecorator works as null pattern here.
On Tue, May 21, 2013 at 9:23 AM, stephane ducasse
stephane.duca...@free.fr wrote:
I named it none edit decorator because It actually not performs any
decoration around basic editing operations. TxNoneEditDecorator just
performs it.
Yes this is what TxNullEditDecorator would convey. I do not see why
TxNoneEditDecorator would mean that and not the TxNullEditDecorator.
Concrete edit decorator can execute specific action on text to perform
requested edit operation. There are three edit operations:
#insertCharacters:at:, #removeNextCharacterAt:,
#removePreviousCharacterAt:. They take aTextSelection as at argument.
For example TxInsertModeEditDecorator extends text selection before
characters insertion:
TxInsertModeEditDecoratoinsertCharacters: aString at: aTextSelection
aTextSelection isEmpty ifTrue: [aTextSelection end moveRight: aString
size]
aTextSelection replaceWith: aString
Yes my point is still valid.
the NullDecorator does not decorate.
TxMaskedEditDecorator- input masked values like phone numbers
TxInsertModeEditDecorator - input with insert mode where any new
character
replace next one.
insert mode is actually opposite - inserts when you type.
replace mode is replaces when you type.
I choose this name because on Windows you have insert key to activate
such mode in many text editors.
I think that igor suggestion is better. because replace is replace :) and
insert is insert.
TxSmartCharsEditDecorator- input smart characters like ()[]{}
TxSingleLineEditDecorator - general way to decorate editing with simple
decoration format. TxSmartNumbersDecorationFormat is example. It
transform
text with number format like: '10 000 000' or '10'000'000'.
btw, can you wrap decorators on top of each other i.e.
Masked-SimgleLine
so i could have a single-line editor for entering only a phone number?
Now with mask decorator you have single line text field. Multilined mask
is not supported (I dont try it actually). When you insert miltiline text
to masked field only first line will be used. I make such restriction to
simplify implementation. Actually I never see multilined masked field.
Decorators can not be wrapped in general way. Maybe some of it. But there
is no cases in current decorators.
Main reason: most of decorators change cursor position with very specific
way. And wrapping decorators will lead to unpredictable and useless results.
Your example Masked-SingleLine (if mask can be multilined) is not about
wrapping decorators. It is about input filtering . It is my next task. I
want put at text morph specification of correct input. So you can forbid
cr characters, can allow only numbers and etc.
And at same time decorators can restrict input by its implementation
requirements which happens with masked decorator. But edit decorators and
filters are different concepts (I not choose name for filters yet).
TxSingleLineEditDecorator implements general way to edit single line text
with simple decoration format. Maybe it should be renamed.
TxSingleLineEditDecorator transforms full text by decoration format after
any edit operation. And it saves logical cursor position after
transformation. Look at methods of TxSmartNumbersDecorationFormat as
example.
I will be happy if you introduce more clever names. Good names is
difficult task for single brain. Especially if you are not native english
speaker.
But many of you already suggest different names. How we can agree on any
one?
Best regards,
Denis
also, going ahead.. how easy/hard would be to implement a password input
field,
when model contains what user types, but display all *** chars?
According methods were added to TxTextMorph:
#editDecorator: - set specific edit decorator (TxNoneEditDecorator by
default)
#inputContents - returns native value (undecorated).
#displayedContents - returns raw text model asString
See new examples on TxTextMorph class side.
Best regards,
Denis
--
Best regards,
Igor Stasenko.
Re: [Pharo-dev] TxText new version 0.8
2013/5/21 b...@openinworld.com I agree with Igor on this one. The insert key toggles between Insert Mode and Overwrite Mode - but the key is not the mode - it only triggers the transition between the two modes.The perception that the insert key is more strongly related Overwrite Mode is an illusion since most text editors are in Insert Mode by default. Interesting. But I am too young to know about it :))
Re: [Pharo-dev] TxText new version 0.8
2013/5/21 stephane ducasse stephane.duca...@free.fr On May 21, 2013, at 9:00 AM, Denis Kudriashov dionisi...@gmail.com wrote: 2013/5/20 stephane ducasse stephane.duca...@free.fr Hello. New TxText version 0.8 is ready: - editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor may be you should call the second package TxTextEditor-Tests I just follow convention of other TxText packages: TxText-Model - TxTextTests-Model, TxText-Layout - TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0 So what the correct way (Pharo way) to name test packages? For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package should be? Stef
Re: [Pharo-dev] TxText new version 0.8
Use Nautilus to generate them, so you will not have to think about it :) (and you can blame someone else in case of bad naming ^^) Ben On May 21, 2013, at 10:24 PM, Denis Kudriashov dionisi...@gmail.com wrote: 2013/5/21 stephane ducasse stephane.duca...@free.fr On May 21, 2013, at 9:00 AM, Denis Kudriashov dionisi...@gmail.com wrote: 2013/5/20 stephane ducasse stephane.duca...@free.fr Hello. New TxText version 0.8 is ready: - editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor may be you should call the second package TxTextEditor-Tests I just follow convention of other TxText packages: TxText-Model - TxTextTests-Model, TxText-Layout - TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0 So what the correct way (Pharo way) to name test packages? For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package should be? Stef
Re: [Pharo-dev] TxText new version 0.8
On 19 May 2013 22:01, Denis Kudriashov dionisi...@gmail.com wrote:
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and
TxTextTests-Editor
- edit decorators implemented:
TxNoneEditDecorator- basic editing
then maybe it should be named as basiceditdecorator?
TxMaskedEditDecorator- input masked values like phone numbers
TxInsertModeEditDecorator - input with insert mode where any new character
replace next one.
insert mode is actually opposite - inserts when you type.
replace mode is replaces when you type.
TxSmartCharsEditDecorator- input smart characters like ()[]{}
TxSingleLineEditDecorator - general way to decorate editing with simple
decoration format. TxSmartNumbersDecorationFormat is example. It transform
text with number format like: '10 000 000' or '10'000'000'.
btw, can you wrap decorators on top of each other i.e.
Masked-SimgleLine
so i could have a single-line editor for entering only a phone number?
also, going ahead.. how easy/hard would be to implement a password input field,
when model contains what user types, but display all *** chars?
According methods were added to TxTextMorph:
#editDecorator: - set specific edit decorator (TxNoneEditDecorator by
default)
#inputContents - returns native value (undecorated).
#displayedContents - returns raw text model asString
See new examples on TxTextMorph class side.
Best regards,
Denis
--
Best regards,
Igor Stasenko.
