notes2-team Mailing List for Notes (Page 32)
Brought to you by:
andersonrb
Menu
▾
▴
notes2-team — Notes developers mailing list.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(11) |
Apr
(21) |
May
(57) |
Jun
(79) |
Jul
(76) |
Aug
(24) |
Sep
(58) |
Oct
(187) |
Nov
(134) |
Dec
(81) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(30) |
Feb
(42) |
Mar
(60) |
Apr
(23) |
May
(6) |
Jun
(32) |
Jul
(14) |
Aug
(10) |
Sep
(6) |
Oct
(6) |
Nov
(4) |
Dec
(2) |
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(3) |
| 2007 |
Jan
(2) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Anderson B. <no...@ig...> - 2003-06-29 06:23:42
|
*Vota=E7=E3o para novo membro* Ol=E1 pessoas, depois de algumas negocia=E7=F5es, consegui convencer um design amigo meu, chamado Andrei, a entrar para nossa pequena equipe. A necessid= ade de um designer tava ficando grande - precisamos de um=20 logo novo, precisaremos criar =EDcones, layout pro site, etc. Al=E9m disso sempre penso q programador n=E3o =E9 o cara mais indicado para criar design de dialogos, janelas e tals. Se tiv=E9ssemos um desginer ele poderia dar uma m=E3ozinha de vez em quando ao menos.=20 O problema deste meu amigo =E9 que ele anda bastante requisitado atualmente (pq ele =E9 bom). Mas ele tem interesse em come=E7ar a trabalhar com =EDcones e design para software e por isso achou que o Notes era um bom lugar para ele ganhar experi=EAncia nisto, ent=E3o acabou ao final aceitando. Alguns sites que ele fez: http://ppgpsi.psico.ufrgs.br/ www.fotogaleria.art.br www.lelic.ufrgs.br/cartola/ Ele j=E1 tem a aprova=E7=E3o do Koguta, do Andr=E9 e do Marcelo. Mas ainda assim achei melhor submeter o nome dele a todos, pois todos tem direito de voto nesta equipe. Prazo para votar... chov=EA... Como faltam poucas pessoas olharem vamos deixar=20 at=E9 quarta, dia 2/7, ok? Qualquer coisa pode reclamar, como sempre... T+ --=20 Anderson R. Barbieri --------------------- Coordenador do Projeto Notes - Notepad Replacement http://notes.codigolivre.org.br * no...@ig... |
|
From: Equipe de Q. <bug...@ya...> - 2003-06-29 00:43:15
|
Ol=E1 pessoal..... Sou d=E1 seguinte opini=E3o : Se o Tiago Shubert tem conhecimento o sufici=EAnte para ajudar no = desenvolvimento do Notes2, ele fazer parte desta equipe. Ser=E1 interessante termos mais um programador com novas id=E9ias e = principalmente "Know How",=20 na =E1rea de desenvolvimento. Meu voto =E9 favor=E1vel ao Sr Tiago Shubert. Abra=E7os Andr=E9Nix. ----- Original Message -----=20 From: Anderson Barbieri=20 To: Notes Dev List=20 Sent: Saturday, June 28, 2003 9:23 PM Subject: [Notes2-team] ***importante*** Decis=F5es do findi! Temos duas decis=F5es importantes para este final de semana: 1) Se o Tiago Shubert vai poder entrar ou n=E3o na equipe do Notes. At=E9 agora temos 2 votos a favor (Victor e Koguta) e um contra (Luiz). Faltam votar o Andr=E9, o Marcos, o Marcelo e o Amihr. Eu teria que dar o meu voto tamb=E9m, mas como a minha opini=E3o =E9 de que qualquer um que queira deve poder entrar, prefiro deixar o meu voto de fora para esta decis=E3o.=20 2) Se existe algum outro componente de edi=E7=E3o a altura do SynEdit ou se usaremos o SynEdit mesmo e come=E7aremos a alter=E1-lo a partir de agora. Pelo visto ningu=E9m =E9 contr=E1rio a usar o = SynEdit, mas faz mais de qualquer modo dei tempo para que outros candidatos fossem apresentados.... o prazo acaba neste domingo. Era isso. Aguardo as vossas manifesta=E7=F5es... Ab. And. --=20 Anderson R. Barbieri --------------------- Coordenador do Projeto Notes - Notepad Replacement http://notes.codigolivre.org.br * no...@ig... |
|
From: Anderson B. <no...@ig...> - 2003-06-29 00:24:22
|
Temos duas decis=F5es importantes para este final de semana: 1) *Se o Tiago Shubert vai poder entrar ou n=E3o na equipe do Notes.* At=E9 agora temos 2 votos a favor (Victor e Koguta) e um contra (Luiz). Faltam votar o Andr=E9, o Marcos, o Marcelo e o Amihr. Eu teria que dar o meu voto tamb=E9m, mas como a minha opini=E3o =E9 de que qualquer um que queira deve poder entrar, prefiro deixar o meu voto de fora para esta decis=E3o. 2) *Se existe algum outro componente de edi=E7=E3o a altura do SynEdit ou se usaremos o SynEdit mesmo e come=E7aremos a alter=E1-lo a partir de agora.* Pelo visto ningu=E9m =E9 contr=E1rio a usar o SynEdit, = mas faz mais de qualquer modo dei tempo para que outros candidatos fossem apresentados.... o prazo acaba neste domingo. Era isso. Aguardo as vossas manifesta=E7=F5es... Ab. And. --=20 Anderson R. Barbieri --------------------- Coordenador do Projeto Notes - Notepad Replacement http://notes.codigolivre.org.br * no...@ig... |
|
From: <lui...@im...> - 2003-06-28 13:46:13
|
"por exemplo.. se o usu=E1rio digitase "breakk" o notes
informaria um possivel erro de sintaxe.. e indicaria a
possivel sintaxe certa como "break"..."
- -- - - - Mas =E9 como eu disse, n=E3o basta ver se n=E3o faz parte da =
linguagem. Tem q ver tb se n=E3o =E9 uma func=E3o do usu=E1rio. O =
problema =E9 q esta fun=E7=E3o pode estar dentro de um header q aponta =
para uma lib. Ent=E3o o Notes teria q ser esperto suficiente para varrer =
todos os headers (De forma ultra-otimizizada) e verificar se realmente =
foi um erro de digita=E7=E3o.
-----Mensagem original-----
De: Victor Thiago Bartz H=F6her [mailto:vic...@im...]=20
Enviada em: s=E1bado, 28 de junho de 2003 00:44
Para: not...@li...
Assunto: [Notes2-team] Analizador L=E9xico (vtbhoher)
Ao abrir o Notes2 o usu=E1rio responderia uma pergunta,
tipo:
Oque Gostaria de editar? (alguma coisa assim :-)
1 - Texto comum
2 - C
3 - Delphi
4 - Java............e assim vai..
Se o usu=E1rio escolhese por exemplo programar em C..
O notes2 j=E1 estaria informado sobre o que seria
"inicialmente" editado..
Ent=E3o o Notes2 j=E1 saberia qual palavra previamente
reservada ele corrigiria..("sem se preocupar com outras
sintaxes")
por exemplo.. se o usu=E1rio digitase "breakk" o notes
informaria um possivel erro de sintaxe.. e indicaria a
possivel sintaxe certa como "break"...
Como vcs haviam comentado..quando o usuario escolhe
programar em C poderiamos disponibilizar alguns
links..sobre C..(como tutoriais e compiladores) assim como fariamos nas =
outras linguagens... Com isso o Notes2 daria uma aten=E7=E3o especial =
para a linguagem escolhida :-)
ass: Victor T.B.H=F6her
__________________________________________________________
Email enviado pelo webmail de http://www.imasters.com.br
Este servi=E7o pode ser incorporado a qualquer site, intranet
ou extranet. Visite http://www.integraweb.com.br e saiba como.
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including =
Data Reports, E-commerce, Portals, and Forums are available now. =
Download today and enter to win an XBOX or Visual Studio .NET. =
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
notes2-team mailing list
not...@li... =
https://lists.sourceforge.net/lists/listinfo/notes2-team
|
|
From: Victor T. B. H. <vic...@im...> - 2003-06-28 03:44:22
|
Ao abrir o Notes2 o usuário responderia uma pergunta,
tipo:
Oque Gostaria de editar? (alguma coisa assim :-)
1 - Texto comum
2 - C
3 - Delphi
4 - Java............e assim vai..
Se o usuário escolhese por exemplo programar em C..
O notes2 já estaria informado sobre o que seria
"inicialmente" editado..
Então o Notes2 já saberia qual palavra previamente
reservada ele corrigiria..("sem se preocupar com outras
sintaxes")
por exemplo.. se o usuário digitase "breakk" o notes
informaria um possivel erro de sintaxe.. e indicaria a
possivel sintaxe certa como "break"...
Como vcs haviam comentado..quando o usuario escolhe
programar em C poderiamos disponibilizar alguns
links..sobre C..(como tutoriais e compiladores) assim como
fariamos nas outras linguagens...
Com isso o Notes2 daria uma atenção especial para a
linguagem escolhida :-)
ass: Victor T.B.Höher
__________________________________________________________
Email enviado pelo webmail de http://www.imasters.com.br
Este serviço pode ser incorporado a qualquer site, intranet
ou extranet. Visite http://www.integraweb.com.br e saiba como.
|
|
From: Marcelo M. - P. <mar...@po...> - 2003-06-28 02:22:37
|
Pessoas, desculpem o sumi=E7o... to com prova e trabalhos at=E9 o pesco=E7o (mas = t=E1 acabando)... estou lendo os e-mails atrasados para ir acompanhando tudo... posso = estar sumido, mas tenho lido (pelo menos) quase todos os e-mails de = voces... At=E9 + Marcelo |
|
From: Anderson B. <no...@ig...> - 2003-06-27 18:35:55
|
Thiago Koguta wrote: > mas como seria quando o usuario abrisse o notes?????????? > > o notes viria com o synedit em branco pronto pra digitacao (arquivo tex= to > normal em branco e nao salvo), obrigando o usuario a mudar > as propriedades do tipo de arquivo e quando salvo fazendo com que o > usuario escolha a extensao correta do arquivo? > > ou o notes abriria vazio (ou seja, at=E9 mesmo sem o synedit aberto=20 > (criado)), > obrigando o usuario a criar um novo documento do tipo desejado?????????= ??? Os editores atuais resolvem isto de duas maneiras: 1) como tu sugeriu, o programa abre sem nenhum arquivo esperando que o=20 usu=E1rio abra um arquivo ou crie um novo; 2) o programa abre sem nenhum arquivo, mas abre j=E1 com o di=E1logo para= =20 criar e abrir arquivos; 3) o programa abre com uma Start Page (VS .Net e Eclipse) que d=E1 ao=20 usu=E1rio um overview do programa e normalmente j=E1 tem os links para criar/abrir arquivo. No=20 caso do VS .Net a Start Page =E9 algo cheio de bagulhos legais. Nunca usei ele, s=F3 vi os screens... 4) o programa carrega o =FAltimo projeto aberto pelo usu=E1rio. Uma coisa que eu gostaria de pontuar =E9 q o N2 deveria ser muito mais=20 orinetado a projetos do que a arquivos. Muito por que n=E3o temos como guardar configura=E7=F5es dentro= de=20 arquivos fontes, mas podemos guardar o que quisermos dentro de um arquivo de um projeto do Notes -=20 qual compilador/servidor/debuger/interpretador usar, configura=E7=F5es de plugins, etc. Quanto a qual das solu=E7=F5es existentes escolher, como sempre acho q o=20 melhor seria deixar o usu=E1rio escolher se ele quer q o notes inicie em branco, carregue j=E1 o =FAltimo= =20 projeto aberto, crie um projeto de in=EDco a partir de erminado template, inicie com uma start page, etc. Ab. Anderson > ### isso com certeza!! e o melhor pros usuarios ne.. =E9 de gra=E7a!=20 O melhor n=E3o =E9 ser de gra=E7a n=E3o. De gra=E7a j=E1 tem IDEs pra car= amba. Agora=20 boas IDEs, leves, extens=EDveis, configur=E1veis, livres e multiplataforma... isso tem muit= o=20 pouco! T+ Anderson |
|
From: Thiago K. <ko...@ms...> - 2003-06-27 16:42:45
|
Claro que teria como adivinhar Koguta. Quando abri-se um arquivo, indentificaria a linguagem pela extensão do arquivo. ####isso é claro.... mas no caso de um arquivo novo, ou se um codigo que está salvo em arquivo .txt? Ao criar um novo arquivo (acho que devemos ter um diálogo semelhante ao do VS .Net pra isso) o cara já deverá selecionar a linguagem e escolher o template a partiri do qual ele vai querer criar o arquivo. #####essa seria uma opcao. ou melhor! a melhor no caso e mais obvia :) mas como seria quando o usuario abrisse o notes?????????? o notes viria com o synedit em branco pronto pra digitacao (arquivo texto normal em branco e nao salvo), obrigando o usuario a mudar as propriedades do tipo de arquivo e quando salvo fazendo com que o usuario escolha a extensao correta do arquivo? ou o notes abriria vazio (ou seja, até mesmo sem o synedit aberto (criado)), obrigando o usuario a criar um novo documento do tipo desejado???????????? ___________________________ Ou seja, quando tu fosse criar um novo aplciativo em Delphi, o código habitual disto já apareceria no editor, extamente como no Delphi. Quanto a editores visuais, a extensões acrescentarão isto ao Notes. Eu serei o primeiro a trabalhar em um plugin que acrescente edição visual pra object pasca. Esperemos que a comundade acrescente no futuro plugins para outras linguagens.... Ou seja, os outros editores que comecem a tremer. Estamos vindo para ficar!!! ehehehhehehehe ### isso com certeza!! e o melhor pros usuarios ne.. é de graça! T+ And. Thiago Koguta wrote: >galera, > >como estamos pensando em desenvolver "O editor preferido dos programadores" >(claro, nao só dos programadores) mas como estamos pensando muito nisso, >posteriormente poderiamos colocar um help "básico" que seja, de cada >linguagem >nao é? bom... sendo assim imagino que a pessoa só deixaria de desenvolver >no proprio Notes, caso ele precise editar o layout ou compilar o projeto... >ja que para fazer o resto o Notes seria uma excelente alternativa, como em >maquinas em que nao tem o delphi, vb, c#, java, etc.. instalado.... ou que >nao aguentam rodar o dito cujo!! > >(bom ja to vendo o notes como um concorrente do M$ word e koffice.. hahaha) >to brincando.. :) > >bom, quanto ao analisador lexico, a gente poderia fazer um corretor >ortografico, >onde o usuário indicaria o tipo de arquivo!! deixa eu explicar.. > >nas propriedades do arquivo a pessoa dirá se o arquvo é Texto normal, asp, >html, >delphi, vb, java..... e dependendo do tipo do arquivo, mudariamos a >coloracao, >e o tipo de verificacao ortografica. sendo assim se escolhido arquivo de >texto normal, >teriamos o verificador ortografico de portugues comum.. se for asp, html, >delphi, >o verificador verificaria as sintaxes existentes nestas linguagens! > >afinal o notes nao tem como adivinhar qual é a linguagem que o usuarios >está >editando para fazer a verificacao, o usuário tem que dar uma força. assim >cada >linguagem teria um xml para a verificacao, se um usuario CRIAR uma liguagem >que >é que se usa PROCEDIIIIIIMENTO, ao inves de PROCEDURE, que ele edite ou >crie um novo XML para esta nova linguagem, com personalisacao de cor, etc! > >falow, >Thiago koguta > >----Original Message Follows---- >From: Luiz Antonio Gomes Picanço <lui...@im...> >Reply-To: not...@li... >To: <not...@li...> >Subject: [Notes2-team] RES: [Notes2-team] Re: analisador léxico... >Date: Thu, 26 Jun 2003 18:53:59 -0300 > >Po, quanto ao item 1, keywords, como eu disse antes, não basta ter as >keywords no xml, e dizer q ta errado se o usuario digitar algo q nao esta >no xml. Lembre, q se o kra digitar ifs (o correto seria if) e o notes >acusar erro, pode dar errado pois o kra pode ter um metodo chamado ifs. > > -----Mensagem original----- > De: Anderson [mailto:and...@po...] > Enviada em: quinta-feira, 26 de junho de 2003 14:37 > Para: not...@li... > Assunto: [Notes2-team] Re: analisador léxico... > > > Bom, é uma possibilidade victor. Concordo com o Luiz que é meio lento > de implementar se formos ter que ficar varrendo métodos criados pelo > usuário - um compilador de C leva anos só pra fazer isso. > > Mas pensado na idéia do Victor, ou seja, de pensar em "erros básicos" > pensei em algumas correções: > > 1) Keywords escritas erradas (as keywords estão no arquivo XML que > define a coloração de código, é só pegas lá de lá e comparar quando > o token for unknown - ou seja, quando o notes não indentificar o >token) > > 2) finalização de certos tipos: > Ex1. Uma string em pascal precisa iniciar e terminar com '. > Ex2. Uma tag HTML começa com < e termina com >. > > 3) operadores para tipos errados. Nem sempre funcionaria. Mas tipo, se >o > usuário digitasse algo absurdo como if (3 > 'esta string') > > E assim vai. Poderíamos ter uma lista também com as palavras > que comumente os programadores erram. Sei lá. Está dada uma > idéia aí.... > > T+ > Anderson > > ---- > Victor Thiago Bartz Höher wrote: > > > acho que poderiamos começar com o básico, apenas > corrigindo erros bobos digitados pelo usuario... > >_________________________________________________________________ >MSN Messenger: converse com os seus amigos online. >http://messenger.msn.com.br > > > >------------------------------------------------------- >This SF.Net email is sponsored by: INetU >Attention Web Developers & Consultants: Become An INetU Hosting Partner. >Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! >INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >_______________________________________________ >notes2-team mailing list >not...@li... >https://lists.sourceforge.net/lists/listinfo/notes2-team > > -- Anderson R. Barbieri --------------------- Coordenador do Projeto Notes - Notepad Replacement http://notes.codigolivre.org.br * no...@ig... ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ notes2-team mailing list not...@li... https://lists.sourceforge.net/lists/listinfo/notes2-team _________________________________________________________________ |
|
From: Anderson B. <no...@ig...> - 2003-06-27 14:18:20
|
Claro que teria como adivinhar Koguta. Quando abri-se um arquivo, indentificaria a linguagem pela extens=E3o do=20 arquivo. Ao criar um novo arquivo (acho que devemos ter um di=E1logo semelhante ao= =20 do VS .Net pra isso) o cara j=E1 dever=E1 selecionar a linguagem e escolher o template a= =20 partiri do qual ele vai querer criar o arquivo. Ou seja, quando tu fosse criar um novo aplciativo em Delphi, o c=F3digo=20 habitual disto j=E1 apareceria no editor, extamente como no Delphi. Quanto a editores visuais, a extens=F5es acrescentar=E3o isto ao Notes. E= u=20 serei o primeiro a trabalhar em um plugin que acrescente edi=E7=E3o visual pra object pasc= a.=20 Esperemos que a comundade acrescente no futuro plugins para outras linguagens.... Ou seja, os outros editores que comecem a tremer. Estamos vindo para=20 ficar!!! ehehehhehehehe T+ And. Thiago Koguta wrote: > galera, > > como estamos pensando em desenvolver "O editor preferido dos=20 > programadores" > (claro, nao s=F3 dos programadores) mas como estamos pensando muito nis= so, > posteriormente poderiamos colocar um help "b=E1sico" que seja, de cada=20 > linguagem > nao =E9? bom... sendo assim imagino que a pessoa s=F3 deixaria de desen= volver > no proprio Notes, caso ele precise editar o layout ou compilar o=20 > projeto... > ja que para fazer o resto o Notes seria uma excelente alternativa,=20 > como em > maquinas em que nao tem o delphi, vb, c#, java, etc.. instalado.... ou=20 > que > nao aguentam rodar o dito cujo!! > > (bom ja to vendo o notes como um concorrente do M$ word e koffice..=20 > hahaha) > to brincando.. :) > > bom, quanto ao analisador lexico, a gente poderia fazer um corretor=20 > ortografico, > onde o usu=E1rio indicaria o tipo de arquivo!! deixa eu explicar.. > > nas propriedades do arquivo a pessoa dir=E1 se o arquvo =E9 Texto norma= l,=20 > asp, html, > delphi, vb, java..... e dependendo do tipo do arquivo, mudariamos a=20 > coloracao, > e o tipo de verificacao ortografica. sendo assim se escolhido arquivo=20 > de texto normal, > teriamos o verificador ortografico de portugues comum.. se for asp,=20 > html, delphi, > o verificador verificaria as sintaxes existentes nestas linguagens! > > afinal o notes nao tem como adivinhar qual =E9 a linguagem que o=20 > usuarios est=E1 > editando para fazer a verificacao, o usu=E1rio tem que dar uma for=E7a.= =20 > assim cada > linguagem teria um xml para a verificacao, se um usuario CRIAR uma=20 > liguagem que > =E9 que se usa PROCEDIIIIIIMENTO, ao inves de PROCEDURE, que ele edite = ou > crie um novo XML para esta nova linguagem, com personalisacao de cor,=20 > etc! > > falow, > Thiago koguta > > ----Original Message Follows---- > From: Luiz Antonio Gomes Pican=E7o <lui...@im...> > Reply-To: not...@li... > To: <not...@li...> > Subject: [Notes2-team] RES: [Notes2-team] Re: analisador l=E9xico... > Date: Thu, 26 Jun 2003 18:53:59 -0300 > > Po, quanto ao item 1, keywords, como eu disse antes, n=E3o basta ter as= =20 > keywords no xml, e dizer q ta errado se o usuario digitar algo q nao=20 > esta no xml. Lembre, q se o kra digitar ifs (o correto seria if) e o=20 > notes acusar erro, pode dar errado pois o kra pode ter um metodo=20 > chamado ifs. > > -----Mensagem original----- > De: Anderson [mailto:and...@po...] > Enviada em: quinta-feira, 26 de junho de 2003 14:37 > Para: not...@li... > Assunto: [Notes2-team] Re: analisador l=E9xico... > > > Bom, =E9 uma possibilidade victor. Concordo com o Luiz que =E9 meio= lento > de implementar se formos ter que ficar varrendo m=E9todos criados p= elo > usu=E1rio - um compilador de C leva anos s=F3 pra fazer isso. > > Mas pensado na id=E9ia do Victor, ou seja, de pensar em "erros b=E1= sicos" > pensei em algumas corre=E7=F5es: > > 1) Keywords escritas erradas (as keywords est=E3o no arquivo XML qu= e > define a colora=E7=E3o de c=F3digo, =E9 s=F3 pegas l=E1 de l=E1 e c= omparar quando > o token for unknown - ou seja, quando o notes n=E3o indentificar o=20 > token) > > 2) finaliza=E7=E3o de certos tipos: > Ex1. Uma string em pascal precisa iniciar e terminar com '. > Ex2. Uma tag HTML come=E7a com < e termina com >. > > 3) operadores para tipos errados. Nem sempre funcionaria. Mas=20 > tipo, se o > usu=E1rio digitasse algo absurdo como if (3 > 'esta string') > > E assim vai. Poder=EDamos ter uma lista tamb=E9m com as palavras > que comumente os programadores erram. Sei l=E1. Est=E1 dada uma > id=E9ia a=ED.... > > T+ > Anderson > > ---- > Victor Thiago Bartz H=F6her wrote: > > > acho que poderiamos come=E7ar com o b=E1sico, apenas > corrigindo erros bobos digitados pelo usuario... > > _________________________________________________________________ > MSN Messenger: converse com os seus amigos online. =20 > http://messenger.msn.com.br > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: INetU > Attention Web Developers & Consultants: Become An INetU Hosting Partner= . > Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission= ! > INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php > _______________________________________________ > notes2-team mailing list > not...@li... > https://lists.sourceforge.net/lists/listinfo/notes2-team > > --=20 Anderson R. Barbieri --------------------- Coordenador do Projeto Notes - Notepad Replacement http://notes.codigolivre.org.br * no...@ig... |
|
From: Anderson B. <no...@ig...> - 2003-06-27 14:07:33
|
Thiago Koguta wrote: > bom uma ideia mais simples, porem tambem nao tenho ideia de como=20 > implementar..=20 Eu ia dar esta id=E9ia tamb=E9m. Mas n=E3o sei se n=E3o =E9 mais complica= da que o=20 analisador de erros. Como dizia o Luiz, o Notes ter=E1 que tirar a lista para completar= =20 o que o usu=E1rio digitou de algum lugar. E para isto n=E3o vejo outro modo que n=E3o seja escaniar= o=20 c=F3digo a procura destas informa=E7=F5es. Por exemplo, se o cara digita "MyBtn:=3D TButton.= " o=20 notes ter=E1 que sugeriri "create". Depois quando o cara digitar "MyBtn." ter=E1 que=20 sugerir todos os m=E9todos e propriedades p=FAblicos do objeto. De onde ele vai tirar esta lista? O SynEdit possui um componente extra para fazer isto. Vou dar uma olhada=20 como ele funfa... > isso tambem diminuiria erros de ortografia na hora da programacao... e=20 > isso seria muito > util e agradavel..=20 Que seria, seria. Eu uso bastante ela quando n=E3o estou com pressa.=20 Quando nunca usou o componente/classe ele tamb=E9m =E9 uma m=E3o na roda. Outra id=E9ia que queria que pens=E1ssemos =E9 incluir o folding. O foldi= ng=20 existe em v=E1rios editores, como o VS . Net e outros. A minha implementa=E7=E3o favorita dele =E9 a q= ue=20 encontrei no Hot Dog, um editor de HTML da sausage por que voc=EA pode selecionar qualquer part= e=20 do texto e clicar em um [-] (parecido com o do Tree view) para esconder uma parte=20 do texto. Depois basta clciar no [+] para traz=EA-lo de volta. O JediEdit (n=E3o confundir= =20 com JEdit) faz isso usando o SynEdit (que acho q =E9 o q usaremos, estou esperando por concorrentes)= .=20 Podemos copiar as id=E9ias deles (ou at=E9 o c=F3digo, j=E1 q ele =E9 aberto). No VS .Ne= t, pelo=20 que eu vi em screenshoots, ele =E9 que determina qual parte do c=F3digo tu pode esconder - o que al=E9= m=20 de tar trabalho para implementar, tira o controle do usu=E1rio. (Ali=E1s, tirar o controle das= =20 m=E3o do usu=E1rio e d=E1-lo para o programa =E9 algo t=EDpico da M$ - qm disse q o programa =E9 capaz= de=20 adivinhar o que o usu=E1rio quer? O Ruindows =E9 a maior demonstra=E7=E3o de q est=E1 =E9= uma id=E9ia=20 que n=E3o funciona.) O que poder=EDamos =E9 facilitar a vida do usu=E1rio, podendo selecionar = tudo=20 que est=E1 dentro de um if e escond=EA-lo para ele, mas n=E3o acho q devemos determinar o q po= de=20 e o q n=E3o pode ser escondido para ele. Bom, era isso! At=E9 mais. Anderson |
|
From: Anderson <and...@po...> - 2003-06-27 14:07:30
|
N=E3o, n=E3o teria este problema n=E3o. =C9 que n=E3o expliquei direito a= minha id=E9ia: a) primeiro o Notes testa o token para ver se =E9 keyword, indentifier,=20 operator, etc. b) no caso de n=E3o ser nenhum destes (e agora o token com o txt "ifs" qu= e=20 tu citou j=E1 teria colorido como indentifier, ou seja, ele n=E3o chegaria ao analisado= r=20 de erros) o notes veria se n=E3o =E9 uma keyword escrita de forma errada c) para fazer isto o notes n=E3o diria que o que ele desconhece =E9 errad= o.=20 Ele compararia o token que ele desconhece com os keywords do arquivo XML e veria se h=E1= =20 algo semelhante. Por exemplo: se o cara escrevesse "funtion" o notes compararia com as=20 keywords e descobriria que ele =E9 parecido com "function". Sendo parecido, marcaria= =20 o token como errado (sublinharia o token com vermelho ou sei l=E1 o que). No menu de=20 contexto ainda haveria uma op=E7=E3o para corrigir o token pra "function" e para ignorar= o=20 erro naquela sess=E3o ou sempre (no caso dum "ifs" da vida ter sido indentificado como=20 errado). O mesmo tipo de sugest=E3o apareceria para corrigir operators, fechar strings, et= c. Eu estou tirando minhas id=E9ias de processadores de textos, n=E3o tenham= =20 d=FAvida. Voc=EAs lembram da diferen=E7a do M$ Word 98 para o M$ Word 2000? At=E9 o 98 o Word apena= s=20 pegava erros de ortografia - e =E9 algo por a=ED que estou sugerindo fazermos. No Word= =20 2000 passou a pegar erros de sintaxe (ainda q isto fosse cheio de falhas) - que =E9 o que ach= o=20 realmente complicado fazermos, pois exige que encontremos um jeito de checar a sintaxe=20 perfeitamente, =E9 como ter que criar um compilador ultrar=E1pido sem ter uma linguagem espec=EDfica em mente..= .. Temos que lembrar que o Notes 2.0 n=E3o ser=E1 a =FAltima edi=E7=E3o do N= otes. A=20 parte mais complicada do "detector de erros" poder=EDamos deixar para a 2.1, ou sei l=E1 qual=20 edi=E7=E3o. Mas quando formos modificar o componente de edi=E7=E3o, j=E1 temos que pensar como faremos = para=20 que ele possa ser facilmente extendido no futuro para incluir isto (e outras coisas)... Ah! E talvez existam coisas que tenham q ser hardcoded. Ou seja, que n=E3= o=20 sejam configur=E1veis. =C9 melhor termos algo n=E3o configur=E1vel do que n=E3o termos... Ab. Anderson Luiz Antonio Gomes Pican=E7o wrote: > Po, quanto ao item 1, keywords, como eu disse antes, n=E3o basta ter as= =20 > keywords no xml, e dizer q ta errado se o usuario digitar algo q nao=20 > esta no xml. Lembre, q se o kra digitar ifs (o correto seria if) e o=20 > notes acusar erro, pode dar errado pois o kra pode ter um metodo=20 > chamado ifs. > > -----Mensagem original----- > *De:* Anderson [mailto:and...@po...] > *Enviada em:* quinta-feira, 26 de junho de 2003 14:37 > *Para:* not...@li... > *Assunto:* [Notes2-team] Re: analisador l=E9xico... > > Bom, =E9 uma possibilidade victor. Concordo com o Luiz que =E9 meio= lento > de implementar se formos ter que ficar varrendo m=E9todos criados p= elo > usu=E1rio - um compilador de C leva anos s=F3 pra fazer isso. > > Mas pensado na id=E9ia do Victor, ou seja, de pensar em "erros b=E1= sicos" > pensei em algumas corre=E7=F5es: > > 1) Keywords escritas erradas (as keywords est=E3o no arquivo XML qu= e > define a colora=E7=E3o de c=F3digo, =E9 s=F3 pegas l=E1 de l=E1 e c= omparar quando > o token for unknown - ou seja, quando o notes n=E3o indentificar o > token) > > 2) finaliza=E7=E3o de certos tipos: > Ex1. Uma string em pascal precisa iniciar e terminar com '. > Ex2. Uma tag HTML come=E7a com < e termina com >. > > 3) operadores para tipos errados. Nem sempre funcionaria. Mas > tipo, se o > usu=E1rio digitasse algo absurdo como /if (3 > 'esta string')/ > > E assim vai. Poder=EDamos ter uma lista tamb=E9m com as palavras > que comumente os programadores erram. Sei l=E1. Est=E1 dada uma > id=E9ia a=ED.... > > T+ > Anderson > > ---- > Victor Thiago Bartz H=F6her wrote: > >>acho que poderiamos come=E7ar com o b=E1sico, apenas=20 >>corrigindo erros bobos digitados pelo usuario... >> >> >>__________________________________________________________ >>Email enviado pelo webmail de http://www.imasters.com.br >>Este servi=E7o pode ser incorporado a qualquer site, intranet >>ou extranet. Visite http://www.integraweb.com.br e saiba como. >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: INetU >>Attention Web Developers & Consultants: Become An INetU Hosting Partner= . >>Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission= ! >>INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >>_______________________________________________ >>notes2-team mailing list >>not...@li... >>https://lists.sourceforge.net/lists/listinfo/notes2-team >> >> >> =20 >> |
|
From: Thiago K. <ko...@ms...> - 2003-06-27 13:10:23
|
galera, como estamos pensando em desenvolver "O editor preferido dos programadores" (claro, nao só dos programadores) mas como estamos pensando muito nisso, posteriormente poderiamos colocar um help "básico" que seja, de cada linguagem nao é? bom... sendo assim imagino que a pessoa só deixaria de desenvolver no proprio Notes, caso ele precise editar o layout ou compilar o projeto... ja que para fazer o resto o Notes seria uma excelente alternativa, como em maquinas em que nao tem o delphi, vb, c#, java, etc.. instalado.... ou que nao aguentam rodar o dito cujo!! (bom ja to vendo o notes como um concorrente do M$ word e koffice.. hahaha) to brincando.. :) bom, quanto ao analisador lexico, a gente poderia fazer um corretor ortografico, onde o usuário indicaria o tipo de arquivo!! deixa eu explicar.. nas propriedades do arquivo a pessoa dirá se o arquvo é Texto normal, asp, html, delphi, vb, java..... e dependendo do tipo do arquivo, mudariamos a coloracao, e o tipo de verificacao ortografica. sendo assim se escolhido arquivo de texto normal, teriamos o verificador ortografico de portugues comum.. se for asp, html, delphi, o verificador verificaria as sintaxes existentes nestas linguagens! afinal o notes nao tem como adivinhar qual é a linguagem que o usuarios está editando para fazer a verificacao, o usuário tem que dar uma força. assim cada linguagem teria um xml para a verificacao, se um usuario CRIAR uma liguagem que é que se usa PROCEDIIIIIIMENTO, ao inves de PROCEDURE, que ele edite ou crie um novo XML para esta nova linguagem, com personalisacao de cor, etc! falow, Thiago koguta ----Original Message Follows---- From: Luiz Antonio Gomes Picanço <lui...@im...> Reply-To: not...@li... To: <not...@li...> Subject: [Notes2-team] RES: [Notes2-team] Re: analisador léxico... Date: Thu, 26 Jun 2003 18:53:59 -0300 Po, quanto ao item 1, keywords, como eu disse antes, não basta ter as keywords no xml, e dizer q ta errado se o usuario digitar algo q nao esta no xml. Lembre, q se o kra digitar ifs (o correto seria if) e o notes acusar erro, pode dar errado pois o kra pode ter um metodo chamado ifs. -----Mensagem original----- De: Anderson [mailto:and...@po...] Enviada em: quinta-feira, 26 de junho de 2003 14:37 Para: not...@li... Assunto: [Notes2-team] Re: analisador léxico... Bom, é uma possibilidade victor. Concordo com o Luiz que é meio lento de implementar se formos ter que ficar varrendo métodos criados pelo usuário - um compilador de C leva anos só pra fazer isso. Mas pensado na idéia do Victor, ou seja, de pensar em "erros básicos" pensei em algumas correções: 1) Keywords escritas erradas (as keywords estão no arquivo XML que define a coloração de código, é só pegas lá de lá e comparar quando o token for unknown - ou seja, quando o notes não indentificar o token) 2) finalização de certos tipos: Ex1. Uma string em pascal precisa iniciar e terminar com '. Ex2. Uma tag HTML começa com < e termina com >. 3) operadores para tipos errados. Nem sempre funcionaria. Mas tipo, se o usuário digitasse algo absurdo como if (3 > 'esta string') E assim vai. Poderíamos ter uma lista também com as palavras que comumente os programadores erram. Sei lá. Está dada uma idéia aí.... T+ Anderson ---- Victor Thiago Bartz Höher wrote: acho que poderiamos começar com o básico, apenas corrigindo erros bobos digitados pelo usuario... _________________________________________________________________ MSN Messenger: converse com os seus amigos online. http://messenger.msn.com.br |
|
From: <lui...@im...> - 2003-06-26 21:57:44
|
Po, quanto ao item 1, keywords, como eu disse antes, n=E3o basta ter as = keywords no xml, e dizer q ta errado se o usuario digitar algo q nao = esta no xml. Lembre, q se o kra digitar ifs (o correto seria if) e o = notes acusar erro, pode dar errado pois o kra pode ter um metodo chamado = ifs. -----Mensagem original----- De: Anderson [mailto:and...@po...]=20 Enviada em: quinta-feira, 26 de junho de 2003 14:37 Para: not...@li... Assunto: [Notes2-team] Re: analisador l=E9xico... =09 =09 Bom, =E9 uma possibilidade victor. Concordo com o Luiz que =E9 meio = lento de implementar se formos ter que ficar varrendo m=E9todos criados pelo usu=E1rio - um compilador de C leva anos s=F3 pra fazer isso. =09 Mas pensado na id=E9ia do Victor, ou seja, de pensar em "erros = b=E1sicos" pensei em algumas corre=E7=F5es: =09 1) Keywords escritas erradas (as keywords est=E3o no arquivo XML que define a colora=E7=E3o de c=F3digo, =E9 s=F3 pegas l=E1 de l=E1 e = comparar quando o token for unknown - ou seja, quando o notes n=E3o indentificar o = token) =09 2) finaliza=E7=E3o de certos tipos: Ex1. Uma string em pascal precisa iniciar e terminar com '.=20 Ex2. Uma tag HTML come=E7a com < e termina com >.=20 =09 3) operadores para tipos errados. Nem sempre funcionaria. Mas tipo, se = o usu=E1rio digitasse algo absurdo como if (3 > 'esta string') =09 E assim vai. Poder=EDamos ter uma lista tamb=E9m com as palavras que comumente os programadores erram. Sei l=E1. Est=E1 dada uma id=E9ia a=ED.... =09 T+ Anderson =09 ---- Victor Thiago Bartz H=F6her wrote: =09 acho que poderiamos come=E7ar com o b=E1sico, apenas=20 corrigindo erros bobos digitados pelo usuario... =09 =09 __________________________________________________________ Email enviado pelo webmail de http://www.imasters.com.br Este servi=E7o pode ser incorporado a qualquer site, intranet ou extranet. Visite http://www.integraweb.com.br e saiba como. =09 =09 =09 ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting = Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly = Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ notes2-team mailing list not...@li... https://lists.sourceforge.net/lists/listinfo/notes2-team =09 =09 =20 |
|
From: Thiago K. <ko...@ms...> - 2003-06-26 20:19:28
|
bom uma ideia mais simples, porem tambem nao tenho ideia de como implementar.. seria a mesma lista de procedimentos e métodos (como tem no delphi, VB, etc.. mas eu nao sei o nome disso) quando a pessoa começa a digitar uma funçao ou propriedade de algum objeto no delphi ou vb, aparece aquela lista de todas as funcoes e propriedades validas da linguagem, para ser autocompletada enquanto o usuario está digitando... isso tambem diminuiria erros de ortografia na hora da programacao... e isso seria muito util e agradavel.. confesso que as vezes eu só deixei de utilizar um editor de texto qualquer ao inves do proprio delphi para fazer uma programacao basica, por falta deste recurso!! abracos, Thiago Koguta ----Original Message Follows---- From: Anderson <and...@po...> Reply-To: not...@li... To: not...@li... Subject: [Notes2-team] Re: analisador léxico... Date: Thu, 26 Jun 2003 14:37:27 -0300 Bom, é uma possibilidade victor. Concordo com o Luiz que é meio lento de implementar se formos ter que ficar varrendo métodos criados pelo usuário - um compilador de C leva anos só pra fazer isso. Mas pensado na idéia do Victor, ou seja, de pensar em "erros básicos" pensei em algumas correções: 1) Keywords escritas erradas (as keywords estão no arquivo XML que define a coloração de código, é só pegas lá de lá e comparar quando o token for unknown - ou seja, quando o notes não indentificar o token) 2) finalização de certos tipos: Ex1. Uma string em pascal precisa iniciar e terminar com '. Ex2. Uma tag HTML começa com < e termina com >. 3) operadores para tipos errados. Nem sempre funcionaria. Mas tipo, se o usuário digitasse algo absurdo como /if (3 > 'esta string')/ E assim vai. Poderíamos ter uma lista também com as palavras que comumente os programadores erram. Sei lá. Está dada uma idéia aí.... T+ Anderson ---- Victor Thiago Bartz Höher wrote: >acho que poderiamos começar com o básico, apenas corrigindo erros bobos >digitados pelo usuario... > > >__________________________________________________________ >Email enviado pelo webmail de http://www.imasters.com.br >Este serviço pode ser incorporado a qualquer site, intranet >ou extranet. Visite http://www.integraweb.com.br e saiba como. > > > >------------------------------------------------------- >This SF.Net email is sponsored by: INetU >Attention Web Developers & Consultants: Become An INetU Hosting Partner. >Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! >INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >_______________________________________________ >notes2-team mailing list >not...@li... >https://lists.sourceforge.net/lists/listinfo/notes2-team > > > > _________________________________________________________________ MSN Hotmail, o maior webmail do Brasil. http://www.hotmail.com |
|
From: Anderson <and...@po...> - 2003-06-26 17:38:11
|
Bom, =E9 uma possibilidade victor. Concordo com o Luiz que =E9 meio lento de implementar se formos ter que ficar varrendo m=E9todos criados pelo usu=E1rio - um compilador de C leva anos s=F3 pra fazer isso. Mas pensado na id=E9ia do Victor, ou seja, de pensar em "erros b=E1sicos" pensei em algumas corre=E7=F5es: 1) Keywords escritas erradas (as keywords est=E3o no arquivo XML que define a colora=E7=E3o de c=F3digo, =E9 s=F3 pegas l=E1 de l=E1 e compara= r quando o token for unknown - ou seja, quando o notes n=E3o indentificar o token) 2) finaliza=E7=E3o de certos tipos: Ex1. Uma string em pascal precisa iniciar e terminar com '. Ex2. Uma tag HTML come=E7a com < e termina com >. 3) operadores para tipos errados. Nem sempre funcionaria. Mas tipo, se o usu=E1rio digitasse algo absurdo como /if (3 > 'esta string')/ E assim vai. Poder=EDamos ter uma lista tamb=E9m com as palavras que comumente os programadores erram. Sei l=E1. Est=E1 dada uma id=E9ia a=ED.... T+ Anderson ---- Victor Thiago Bartz H=F6her wrote: >acho que poderiamos come=E7ar com o b=E1sico, apenas=20 >corrigindo erros bobos digitados pelo usuario... > > >__________________________________________________________ >Email enviado pelo webmail de http://www.imasters.com.br >Este servi=E7o pode ser incorporado a qualquer site, intranet >ou extranet. Visite http://www.integraweb.com.br e saiba como. > > > >------------------------------------------------------- >This SF.Net email is sponsored by: INetU >Attention Web Developers & Consultants: Become An INetU Hosting Partner. >Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! >INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php >_______________________________________________ >notes2-team mailing list >not...@li... >https://lists.sourceforge.net/lists/listinfo/notes2-team > > > =20 > |
|
From: Victor T. B. H. <vic...@im...> - 2003-06-26 01:21:00
|
acho que poderiamos começar com o básico, apenas corrigindo erros bobos digitados pelo usuario... __________________________________________________________ Email enviado pelo webmail de http://www.imasters.com.br Este serviço pode ser incorporado a qualquer site, intranet ou extranet. Visite http://www.integraweb.com.br e saiba como. |
|
From: Victor T. B. H. <vic...@im...> - 2003-06-26 01:18:49
|
Acho que se o kra ja tem um conhecimento em pascal e delphi, acho que não teria problema de incluilo na equipe, Acho que o que interessa mesmo é a vontade de aprender que ele demonstra e a vontade de ajudar o notes.... quanto mais pessoas bem intencionadas na equipe notes melhor... __________________________________________________________ Email enviado pelo webmail de http://www.imasters.com.br Este serviço pode ser incorporado a qualquer site, intranet ou extranet. Visite http://www.integraweb.com.br e saiba como. |
|
From: <lui...@im...> - 2003-06-26 01:09:14
|
Acho q seria uma boa, por=E9m muito demorado de implementar. Para podermos comparar comandos errados, ter=EDamos q varrer todas os = m=E9todos criados pelo usu=E1rio em v=E1rios arquivos separados, e olha = q isso =E9 s=F3 o b=E1sico. Mas, =E9 poss=EDvel sim. -----Mensagem original----- De: Anderson [mailto:and...@po...]=20 Enviada em: quarta-feira, 25 de junho de 2003 21:29 Para: Notes Dev List Assunto: [Notes2-team] Victor e Luiz: um analisador l=E9xico seria = imposs=EDvel? Alguns e-mails atr=E1s o Victor havia sugerido: >o notes poderia detectar alguns erros b=E1sicos de c=F3digo >antes de chamar um compilador...... Naquela ocasi=E3o eu comentei que isto seria dif=EDcil de ser = implementado, mas que pod=EDamos pensar em algo. A discuss=E3o parou e estou trazendo de novo por que =E9 algo importante. Eu gostaria que o Notes pudesse detectar alguns erros no c=F3digo, por mais que eu n=E3o tenha id=E9ia = de como implementar isto. O =FAnico modo em que eu consegui pensar que isto = seria implement=E1vel seria detectando Keywords mal escritas (funcionando como um editor de texto que encontra erros de ortografia, o que j=E1 seria algo).=20 Mas creio que o victor deve ter uma id=E9ia melhor de como implementar = isto, ent=E3o pediria que ele contasse para n=F3s. Talvez o Luiz tenha alguma = id=E9ia boa tamb=E9m. N=E3o =E9 por que eu acho dif=EDcil de implementar q vamos = deixar de fazer algo. E espero que vcs n=E3o tenham parado esta discuss=E3o por = minha culpa. Vamos l=E1 pessoas! Vamos continuar esta discuss=E3o, please! Estou no aguardo de id=E9ias... T+ Anderson PS: Victor, como =E9 o Kurumin? Tamb=E9m tenho problemas com winmodens = :) ------------------------------------------------------- This SF.Net email is sponsored by: INetU Attention Web Developers & Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php _______________________________________________ notes2-team mailing list not...@li... https://lists.sourceforge.net/lists/listinfo/notes2-team |
|
From: <lui...@im...> - 2003-06-26 01:07:56
|
Sei l=E1 kra, poxa, o kra pelo visto so conhece o b=E1sico de pascal. Quando a parada come=E7ar correr para Orienta=E7=E3o a Objeto, vai ficar = complicado o kra acompanhar.=20 Mesmo pq o Notes esta caminhando para uma super IDE de desenvolvimento e = o desenvolvimento da mesma requer pessoas experientes na equipe. Sei = l=E1, =E9 s=F3 uma opini=E3o. O q a galera acha ??? -----Mensagem original----- De: Anderson [mailto:and...@po...]=20 Enviada em: quarta-feira, 25 de junho de 2003 21:33 Para: Notes Dev List Assunto: [Notes2-team] [Fwd: Interesse] Novo programador. Que voc=EAs = acham? E ae pessoas? Chegou este mail pra mim. =C9 de um cara sem mmmmuuuiiittaa = experi=EAncia em=20 Delphi querendo entrar na equipe. O que voc=EAs acham? Ele entra ou n=E3o? Vou mandar um mail para ele e dizer que a equipe estar=E1 votando se ele = entra ou n=E3o. Digo que at=E9 segunda damos uma resposta para ele, ok. Aguardo a opini=E3o de voc=EAs!!! T+ And. |
|
From: Anderson <and...@po...> - 2003-06-26 00:33:48
|
E ae pessoas? Chegou este mail pra mim. =C9 de um cara sem mmmmuuuiiittaa experi=EAncia= em=20 Delphi querendo entrar na equipe. O que voc=EAs acham? Ele entra ou n=E3o? Vou mandar um mail para ele e dizer que a equipe estar=E1 votando se ele=20 entra ou n=E3o. Digo que at=E9 segunda damos uma resposta para ele, ok. Aguardo a opini=E3o de voc=EAs!!! T+ And. |
|
From: Anderson <and...@po...> - 2003-06-26 00:29:23
|
Alguns e-mails atr=E1s o Victor havia sugerido: >o notes poderia detectar alguns erros b=E1sicos de c=F3digo=20 >antes de chamar um compilador...... Naquela ocasi=E3o eu comentei que isto seria dif=EDcil de ser implementad= o, mas que pod=EDamos pensar em algo. A discuss=E3o parou e estou trazendo de novo por que =E9 algo importante. Eu gostaria que o Notes pudesse detectar alguns erros no c=F3digo, por mais que eu n=E3o tenha id=E9ia de= como implementar isto. O =FAnico modo em que eu consegui pensar que isto seria= implement=E1vel seria detectando Keywords mal escritas (funcionando como um editor de texto que encontra erros de ortografia, o que j=E1 seria algo).=20 Mas creio que o victor deve ter uma id=E9ia melhor de como implementar is= to, ent=E3o pediria que ele contasse para n=F3s. Talvez o Luiz tenha alguma i= d=E9ia boa tamb=E9m. N=E3o =E9 por que eu acho dif=EDcil de implementar q vamos = deixar de fazer algo. E espero que vcs n=E3o tenham parado esta discuss=E3o por = minha culpa. Vamos l=E1 pessoas! Vamos continuar esta discuss=E3o, please! Estou no aguardo de id=E9ias... T+ Anderson PS: Victor, como =E9 o Kurumin? Tamb=E9m tenho problemas com winmodens :) |
|
From: Anderson B. <no...@ig...> - 2003-06-23 02:43:35
|
*Carta aberta aos usu=E1rios do Notes* Caros usu=E1rios do Notes, Devido a import=E2ncia dos comunicados que temos a lhe fazer, decidimos=20 enviar-lhe est=E1 carta. Pedimos que voc=EA a repasse para todos usu=E1rios do Notes que voc=EA co= nhece=20 e publique-a no seu site, blog, f=F3rum, etc. j=E1 que as informa=E7=F5es s=E3o import= antes=20 para todos os atuais e futuros usu=E1rios. Semanas atr=E1s a Equipe do Notes decidiu cancelar o desenvolvimento da=20 vers=E3o 1.6 do Notes. Depois de termos lan=E7ado o alpha desta vers=E3o vimos que ela tinha bug= s=20 demais, muitos deles ligados a forma como o programa foi escrito. Ou seja, levar=EDamos tempo=20 demais corrigindo estes bugs, muito al=E9m do que pens=E1vamos. A boa not=EDcia =E9 que come=E7amos j=E1 a planejar a vers=E3o 2 do Notes= . O Notes=20 2 ser=E1 escrito totalmente do zero e seu planejamento vem sendo baseado em id=E9ias dos usu=E1rios e= da=20 equipe do Notes buscando atender aos pedidos que temos ouvido: colora=E7=E3o de c=F3digo, tabs (ab= rir=20 v=E1rios arquivos na mesma janela), suporte a scripts e plugins, suporte a projetos, etc. Al=E9m disso, o=20 Notes 2 ter=E1 vers=F5es para Linux e para Windows - voc=EA n=E3o precisar=E1 mais mudar de editor quando mudar de=20 sistema operacional! Voc=EA pode participar do planejamento atrav=E9s do novo f=F3rum do Notes= : http://notes2.sourceforge.net/forum/ Voc=EA pode dar sugest=F5es nos f=F3runs "O que os usu=E1rios esperam do = Notes2=20 ? <http://notes2.sourceforge.net/forum/viewforum.php?f=3D3>", "Ambiente=20 gr=E1fico <http://notes2.sourceforge.net/forum/viewforum.php?f=3D4> X Interface gr=E1fica=20 <http://notes2.sourceforge.net/forum/viewforum.php?f=3D4>" e "Faltou=20 alguma coisa ????=20 <http://notes2.sourceforge.net/forum/viewforum.php?f=3D5>". Voc=EA pode=20 acompanhar as discuss=F5es do planejamento final em " Planejamento do Notes2=20 <http://notes2.sourceforge.net/forum/viewforum.php?f=3D2>" e ver outros=20 debates sobre desenvolvimento em "Desenvolvimento=20 <http://notes2.sourceforge.net/forum/viewforum.php?f=3D1>". N=F3s precisaremos de toda a ajuda poss=EDvel para planejar o Notes 2 e p= ara=20 desenvolv=EA-lo. Se voc=EA conhece algu=E9m que programe em Delphi/Kylix, conven=E7a-o a entrar na equipe do= =20 Notes. Se voc=EA sabe HTML e PHP ou =E9 um bom designer, nos ajude a desenvolver o site do Notes. Se=20 voc=EA n=E3o sabe nada disso nem conhece algu=E9m que programe em Delphi/Kylix e mesmo assim quer ajudar,=20 entre em contato pelo nosso email (no...@ig... <mailto:no...@ig...>). Obrigado a todos voc=EAs que usam o Notes. Esperamos que voc=EAs gostem d= as=20 pr=F3ximas vers=F5es! Atenciosamente, Equipe do Notes OBS: Voc=EA est=E1 recebendo este e-mail por que =E9 assinante da newslet= ter=20 do Notes. Voc=EA pode cancelar a sua assinatura pedindo isto atrav=E9s do e-mail=20 no...@ig.... A newsletter do Notes volta ao normal no m=EAs que vem. At=E9 l=E1! |
|
From: Anderson <and...@po...> - 2003-06-23 00:18:04
|
Me corregindo: *A vota=E7=E3o =E9 at=E9 o dia 29/06/03!!!* Desculpem o lapso :) Anderson PS: Andr=E9, obrigado por ter notado este erro idiota!!! ------------- Anderson wrote: >*Voc=EA pode votar _S=D3_ at=E9 6/06/03!!! >Depois n=E3o diga que n=E3o foi avisado! :) >* >N=E3o sei quanto a voc=EAs, >mas estou achando que nosso planejamento at=E9 agora est=E1 muito lento = e que esta lentid=E3o n=E3o trouxe grandes resultados at=E9 o momento. En= t=E3o >vamos come=E7ar a tomar algumas decis=F5es e fazer as coisas andarem... > >Para n=E3o fecharmos simplesmente o planejamento do jeito que est=E1, a >minha proposta =E9 que votemos para ver que editor vamos usar e comecemo= s >a fazer as modifica=E7=F5es necess=E1rias nele enquanto discutimos as ou= tras >partes mais dif=EDceis do planejamento durante mais algum tempo. > >Penso que o melhor editor (componente de edi=E7=E3o) para usarmos =E9 o = SynEdit (os motivos est=E3o no forum <http://notes2.sourceforge.net/forum= /viewtopic.php?t=3D9>). > >Espero at=E9 o dia 29/6/03, ou seja, domingo que vem, por obje=E7=F5es >e apresenta=E7=F5es de componentes alternativos. Dos que pude encontrar >na web, este me parece o melhor. Mas voc=EAs tem uma semana inteira >para procurar e testar por si mesmos... > >Eu to sendo duro e n=E3o gosto disto, mas j=E1 vi que a equipe n=E3o and= a=20 >motivada e que se eu n=E3o agir deste modo o Notes 2 n=E3o vai sair do p= apel... Agora entendo por que o Linus manda sozinho no Kernel at=E9 >hoje... > >OBS: Estarei mandando hoje a noite a "Carta aberta aos usu=E1rios do >Notes", j=E1 que as =FAnicas opini=F5es que recibi eram a favor da carta= ... > >--=20 >Anderson R. Barbieri >--------------------- >Coordenador do Projeto Notes - Notepad Replacement >http://notes.codigolivre.org.br * no...@ig... > |
|
From: Anderson <and...@po...> - 2003-06-22 21:25:00
|
*Voc=EA pode votar _S=D3_ at=E9 6/06/03!!! Depois n=E3o diga que n=E3o foi avisado! :) * N=E3o sei quanto a voc=EAs, mas estou achando que nosso planejamento at=E9 agora est=E1 muito lento e= que esta lentid=E3o n=E3o trouxe grandes resultados at=E9 o momento. Ent= =E3o vamos come=E7ar a tomar algumas decis=F5es e fazer as coisas andarem... Para n=E3o fecharmos simplesmente o planejamento do jeito que est=E1, a minha proposta =E9 que votemos para ver que editor vamos usar e comecemos a fazer as modifica=E7=F5es necess=E1rias nele enquanto discutimos as out= ras partes mais dif=EDceis do planejamento durante mais algum tempo. Penso que o melhor editor (componente de edi=E7=E3o) para usarmos =E9 o S= ynEdit (os motivos est=E3o no forum <http://notes2.sourceforge.net/forum/= viewtopic.php?t=3D9>). Espero at=E9 o dia 29/6/03, ou seja, domingo que vem, por obje=E7=F5es e apresenta=E7=F5es de componentes alternativos. Dos que pude encontrar na web, este me parece o melhor. Mas voc=EAs tem uma semana inteira para procurar e testar por si mesmos... Eu to sendo duro e n=E3o gosto disto, mas j=E1 vi que a equipe n=E3o anda= =20 motivada e que se eu n=E3o agir deste modo o Notes 2 n=E3o vai sair do pa= pel... Agora entendo por que o Linus manda sozinho no Kernel at=E9 hoje... OBS: Estarei mandando hoje a noite a "Carta aberta aos usu=E1rios do Notes", j=E1 que as =FAnicas opini=F5es que recibi eram a favor da carta.= .. --=20 Anderson R. Barbieri --------------------- Coordenador do Projeto Notes - Notepad Replacement http://notes.codigolivre.org.br * no...@ig... |
|
From: Anderson <and...@po...> - 2003-06-22 03:20:59
|
E ae people!
Eis o guia da apple para interfaces. Na realidade s=E3o trechos, o guia m=
esmo
=E9 bem maior. Podemos afanar id=E9ias pro Notes.
quem entende mais de interface q os designer da apple?
And.
Aqua Human Interface Guidelines
Human Interface Design Principles
This section provides a theoretical base for the wealth of practical=20
information on implementing the Aqua interface elements presented in the=20
rest of this book.
You'll undoubtedly find that you can't design in accordance with all of=20
the principles all the time. In those situations, you'll have to make=20
decisions based on which principle or set of principles is most=20
important in the context of the task you're solving. User testing is=20
often an excellent way to decide between conflicting principles in a=20
particular context.
Metaphors
Take advantage of people's knowledge of the world by using metaphors to=20
convey concepts and features of your application. Use metaphors that=20
represent concrete, familiar ideas and make the metaphors obvious, so=20
users can apply a set of expectations to the computer environment. For=20
example, the Macintosh uses the metaphor of file folders for storing=20
documents; people can organize their hard disks in a way that's=20
analogous to the way they organize file cabinets.
Metaphors in the computer interface suggest a use for something, but=20
that use doesn't necessarily define or limit the implementation of the=20
metaphor. The Trash, for example, doesn't have to limit its contents to=20
the number of items an actual wastebasket could contain. Try to strike a=20
balance between the metaphor's suggested use and the computer's ability=20
to support and extend the metaphor.
See-and-Point
People interact with the interface by pointing at onscreen objects with=20
a device, typically a mouse. The Macintosh operating system works=20
according to two fundamental paradigms, both of which assume that users=20
can see what they're doing onscreen at all times and can point at what=20
they see. The paradigms are based on a general form of user action:=20
noun-then-verb.
In one paradigm, the user selects an object (the noun) and then chooses=20
the action to be performed on the object (the verb). All actions=20
available for a selected object are listed in the menus, so a user who=20
is unsure of what to do next can scan through them. Users can choose an=20
available action without having to remember a specific command.
In the second paradigm, the user directly manipulates an object (the=20
noun) and performs an action (the verb) with it. A common example is=20
dragging a document icon to a folder, for example. The user doesn't=20
choose a menu command, but it's clear what happens to an object when=20
it's placed on another one. For this paradigm to work, the user must=20
recognize what objects are for; the fact that the Trash looks like its=20
real-world counterpart makes the interface easier to use.
Direct Manipulation
Direct manipulation allows people to feel that they are controlling the=20
objects represented by the computer. According to this principle, an=20
onscreen object should remain visible while a user performs an action on=20
it, and the impact of the action should be immediately visible. For=20
example, a user moves a file by dragging its icon from one location to=20
another. With drag and drop, the most common example of direct=20
manipulation, users can drag selected text directly into another document=
.
Support direct manipulation when users expect it. Avoid forcing users to=20
use controls to manipulate data. For example, you should be able to send=20
a facsimile by dragging a document's icon to a fax machine icon in the=20
Dock, instead of having to open a utility program, choose a file, and=20
click a Fax button.
User Control
Allow the user, not the computer, to initiate and control actions. Some=20
applications attempt to take care of the user by offering only=20
alternatives judged good for the user or that protect the user from=20
having to make detailed decisions. This approach mistakenly puts the=20
computer, not the user, in control.
The key is to create a balance between providing users with the=20
capabilities they need to get their work done and helping them avoid=20
dangerous irreversible actions. For a situation in which a user may=20
destroy data accidentally, for example, you should always provide a=20
warning and still allow the user to proceed if desired.
Feedback and Communication
Keep users informed about what's happening with your product. Provide=20
feedback as they do tasks. When a user initiates an action, provide an=20
indication that your application has received the user's input and is=20
operating on it.
Users want to know that a command is being carried out or, if it can't=20
be carried out, they want to know why not and what they can do instead.=20
When used sparingly, animation is one of the best ways to show a user=20
that a requested action is being carried out. When a user clicks an icon=20
in the Dock, for example, the icon bounces to let the user know that the=20
application or document is in the process of opening. In Mac OS X, the=20
kernel environment detects when your application doesn't respond to=20
events for 2 seconds and automatically displays a busy cursor.
For operations that don't execute immediately, use a progress indicator=20
to provide useful information about how long the operation will take.=20
See "Progress Indicators"=20
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/A=
HIGControls/chapter_7_section_14.html#//apple_ref/doc/uid/20000963/TPXREF=
106>.=20
Users don't need to know precisely how many seconds an operation will=20
take, but it helps to give an estimate. For example, the Mac OS uses=20
statements such as "about a minute remains." It can also be helpful to=20
communicate the total number of steps needed to complete a=20
task--"Copying 30 of 850 files," for example.
Provide direct, simple feedback that people can understand. In error=20
messages, for example, spell out exactly what situation caused the error=20
("There's not enough space on that disk to save the document") and=20
possible actions the user can take to rectify it ("Try saving the=20
document in another location"). For more information, see "Writing Good=20
Alert Messages"=20
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/A=
HIGLanguage/chapter_13_section_4.html#//apple_ref/doc/uid/20000970/TPXREF=
23>.
Consistency
Consistency in the interface allows people to transfer their knowledge=20
and skills from one application to any other. Use the standard elements=20
of the Aqua interface to ensure consistency within your application and=20
to benefit from consistency across applications. Ask yourself the=20
following questions when thinking about consistency in your product.
Is your product consistent
* within itself?
* with earlier versions of your product?
* with Mac OS standards? For example, does your application use the
reserved and recommended keyboard equivalents? (See "Reserved and
Recommended Keyboard Equivalents"
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidel=
ines/AHIGUserInput/chapter_9_section_6.html#//apple_ref/doc/uid/20000965/=
CHDIGFBH>.)
* in its use of metaphors?
* with people's expectations?
Matching everyone's expectations is the most difficult kind of=20
consistency to achieve, since your product is likely used by an audience=20
with a wide range of expertise. You can address this problem by=20
carefully weighing the consistency issues in the context of your target=20
audience and their needs.
WYSIWYG (What You See Is What You Get)
In applications in which users can format data for printing, make sure=20
there are no significant differences between what the user sees onscreen=20
and what the user receives after printing. When the user makes changes=20
to a document, display the results immediately; the user shouldn't have=20
to wait for a printout or make mental calculations of how the document=20
will look when printed. Use a print preview function if necessary.
WYSIWYG is not about only printing; all data experienced by=20
users--movies, audio, and so on--should be faithfully represented in all=20
media.
People should be able to find all the available features in your=20
application. Don't hide features by using abstract commands. For=20
example, menus present lists of commands so people can see their choices=20
instead of having to remember command names.
Forgiveness
You can encourage people to explore your application by building in=20
forgiveness--that is, making most actions easily reversible. People need=20
to feel that they can try things without damaging the system; create=20
safety nets, such as the Undo and the Revert to Saved commands, so=20
people feel comfortable learning and using your product.
Always warn users before they initiate a task that will cause=20
irreversible loss of data. If alerts appear frequently, however, it may=20
mean that the product has some design flaws; when options are presented=20
clearly and feedback is timely, using an application should be=20
relatively error-free.
Perceived Stability
The Macintosh interface is designed to provide an understandable,=20
familiar, and predictable environment.
To give users a visual sense of stability, the interface defines many=20
consistent graphics elements, such as the menu bar, window controls, and=20
so on. Users encounter a familiar environment in which they know how=20
things behave and what to do with them.
To give users a conceptual sense of stability, the interface provides a=20
clear, finite set of objects and a clear, finite set of actions to=20
perform on those objects. For example, when a menu command doesn't apply=20
to a selected object or to the object in its current state, it is shown=20
dimmed (grayed out) rather than being omitted.
To help preserve the perception of stability, when a user sets up his or=20
her onscreen environment in a certain layout, it should stay that way=20
until the user changes it. Preserve user-modified settings such as=20
window dimensions and locations.
Aesthetic Integrity
Aesthetic integrity means that information is well organized and=20
consistent with principles of visual design. Your product should look=20
pleasant on screen even when viewed for a long time.
Keep graphics simple, and use them only when they truly enhance=20
usability. Don't overload the user with icons or put dozens of buttons=20
in windows or dialogs. Don't use arbitrary symbols to represent=20
concepts; they may confuse or distract users.
Match a graphic element with users' expectations of its behavior. Don't=20
change the meaning or behavior of standard items. For example, always=20
use checkboxes for multiple choices; don't use them sometimes for=20
exclusive choices.
Modelessness
As much as possible, allow people to do whatever they want at all times.=20
Avoid using modes that lock the user into one operation and don't allow=20
the user to work on anything else until that operation is completed.
Most acceptable uses of modes fall into one of the following categories:
* Short-term modes in which the user must constantly do something to
maintain the mode. Examples are holding down the mouse button to
scroll text or holding down the Shift key to extend a text selectio=
n.
* Alert modes, in which the user must rectify an unusual situation
before proceeding. Keep these modes to a minimum. See "Types of
Dialogs and When to Use Them"
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidel=
ines/AHIGDialogs/chapter_6_section_2.html#//apple_ref/doc/uid/20000962/CJ=
ECBHJE>
for more information.
Other modes are acceptable if they do one of the following:
* They emulate a familiar real-life situation that is itself modal.
For example, choosing different tools in a graphics application
resembles the real-life choice of physical drawing tools.
* They change only the attributes of something, not its behavior.
The boldface and underline modes of text entry are examples.
* They block most other normal operation of the system to emphasize
the modality. An example is a dialog that makes all menu commands
unavailable except Cut, Copy, and Paste.
If an application uses modes, there must be a clear visual indicator of=20
the current mode, and it should be very easy for users to get in and out=20
of the mode. For example, in many graphics applications, the pointer can=20
look like a pencil, a cross, a paintbrush, or an eraser, depending on=20
the function (the mode) the user selects.
Knowledge of Your Audience
Identifying and understanding your target audience are important first=20
steps when designing your product. The best way to make sure your=20
product meets the needs of your customers is by exposing your design to=20
their scrutiny. You can do this during every phase of the design process=20
to help reveal what works about your product as well as its flaws. The=20
improvements you make as a result of prototype testing can translate=20
into competitive advantages, increased sales, and enhanced customer=20
satisfaction.
It's useful to create scenarios that describe a typical day in the life=20
of a person you think uses the type of product you're designing. Think=20
about the different environments, tools, and constraints that your users=20
deal with. If possible, visit actual workplaces and study how people do=20
their jobs.
Analyze the steps necessary to complete each task you anticipate people=20
wanting to accomplish with your product. Look at how they perform=20
similar tasks without a computer. Then design your product to facilitate=20
those tasks. Don't replicate each step on the computer; your application=20
should make the whole process /easier/.
Throughout the design process, use people who fit your audience=20
description to test your prototypes. Listen to their feedback and try to=20
address their concerns. Develop your product with people and their=20
capabilities--not computers and their capabilities--in mind.
Text Display and Text Editing
Writing systems differ in the direction in which their characters and=20
lines flow, the size of the character set used, and whether certain=20
characters are context dependent. Mac OS 9 and earlier relied on=20
WorldScript and the Script Manager, which used a different character set=20
for each script system. Mac OS X supports Unicode, a single character=20
set for most writing systems in the world. Unicode is a cross-platform,=20
international standard for character encoding.
Text handling for Cocoa is entirely based on Unicode. For Carbon=20
developers, there is a new set of functions for manipulating Unicode=20
text. For more information about localization tools, fonts, and=20
international technologies, go to http://developer.apple.com/intl.
No matter what level of worldwide text support you provide, it's=20
important to avoid these common assumptions:
* Text isn't always left-aligned and read from left to right.
* Text isn't always read by a person; it might be spoken through a
text-to-speech converter.
* System and application fonts may change.
Layout Guidelines
This chapter provides basic suggestions for arranging controls in=20
dialogs and windows. These guidelines use many of the default control=20
sizes defined in Interface Builder; any exceptions are noted. To=20
simplify the process of resizing and repositioning existing dialogs and=20
windows, most values are based on a multiple of 2 pixels. All=20
user-visible text should use the standard fonts described in "Fonts"=20
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/A=
HIGFonts/chapter_10_section_1.html#//apple_ref/doc/uid/20000966/TP6>.
The Control Manager (Carbon) and Application Kit (Cocoa) include smaller=20
versions of the most commonly used controls, for use in utility windows=20
when necessary. For utility window layout information, see "Using Small=20
Versions of Controls"=20
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidelines/A=
HIGLayout/chapter_8_section_5.html#//apple_ref/doc/uid/20000964/BGBBJHDI>=
.
Positioning Controls in Dialogs and Windows
Keep these guidelines in mind when designing dialogs and windows:
* In general, try for a more centered approach to dialog layout, as
opposed to the strongly left-biased approach of the traditional
Mac OS 9 dialog. Most of the sample layouts in this document
illustrate the center-biased approach.
* All spacing between dialog elements involves a multiple of 2
pixels--2, 4, 6, 8, and so on.
* Maintain a 20-pixel space between the left and right edge of the
window and any controls. Keep 20 pixels of space between the
bottom edge and any controls; this can include the shadow of any
push buttons in that area. Top spacing is determined by which
controls are placed closest to the top of the dialog. For example,
Figure 8-6
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidel=
ines/AHIGLayout/chapter_8_section_4.html#//apple_ref/doc/uid/20000964/BGB=
CEDJE>
uses a radio button as the topmost control, so the spacing is set
to 14 pixels. In contrast, Figure 8-7
<http://developer.apple.com/techpubs/macosx/Essentials/AquaHIGuidel=
ines/AHIGLayout/chapter_8_section_4.html#//apple_ref/doc/uid/20000964/BIA=
FHIIG>
uses a tab control as the topmost element, so the spacing is set
to 12 pixels.
* For dialogs that contain a mix of controls, set 16 pixels of
vertical space between groups of controls. Vertical spacing
between controls is determined by the tallest control in the row.
* Groups of controls should be separated by 20 pixels of vertical
spacing and subgroups of controls within groups should be
separated by 16 pixels.
* The default button for dismissing a dialog should go in the
lower-right corner. If there's a Cancel button, it should be to
the left of the default button.
If there's a third button for dismissing the dialog, it should go
to the left of the Cancel button. If the third button could result
in data loss--Don't Save, for example--position it at least 12
pixels away from the "safe" buttons (Cancel and Save, for example).
A button that affects the contents of the dialog itself, such as
Reset, should have its left edge aligned with the main dialog text
or 12 pixels to the right of the help button (if there is one).
*Figure 8-1 Position of buttons at the bottom of a dialog*
* The minimum screen resolution a dialog needs to accommodate is 800
by 600. (Support for 640 by 480 is provided for games.)
* For most document windows that contain a single view (scrolling
text or tables, for example), do not specify any space between the
window edge and scroll bars (when using the Control Manager) or
the frame of the view (in Interface Builder).
Group Boxes
A *group box* is used to associate a set of related items--such as radio=20
buttons or pop-up menus--in a dialog.
As much as possible, /use additional space between controls to create=20
groups of controls, rather than group boxes./ Excessive use of group=20
boxes creates visual clutter; too many lines and edges can distract=20
users. Also use space or separator lines, rather than secondary group=20
boxes, for subgroupings. The following figures show examples of how to=20
successfully re-create dialogs using space rather than group boxes. When=20
space alone isn't enough to clearly divide areas, use a label and a=20
separator, as shown in the following "after" examples.
Within a group box, no control or label should be positioned within 16=20
pixels of the box's top, bottom, left, or right borders.
Group boxes can be untitled or titled. Titles can be static text, a=20
checkbox label, or text in a pop-up menu.
*Figure 8-2 Dialog redesigned without group boxes (first example)*
In the second "after" example, the group boxes have been replaced by=20
horizontal lines that serve as separators; the lines are 2 pixels to the=20
right of the label and base-aligned with the label text. Although the=20
overall look of the dialog is centered, the two labels, as well as the=20
lines, are right-aligned; flush-left controls would imply an=20
inappropriate hierarchy. The distance from the left edge of the pane to=20
the label text and from the end of the line to the right edge of the=20
pane should be equal.
*Figure 8-3 Dialog redesigned without group boxes (second example)*
In the "after" example, the labels are left-aligned, since they are next=20
to checkboxes, which are most commonly stacked vertically.
*Figure 8-4 Dialog redesigned without a group box (third example)]*
Sample Dialog Layouts
This section contains sample layouts illustrating how to position=20
various types of controls. Unless specified otherwise, all measurements=20
are in pixels.
*Figure 8-5 A standard alert with dimensions*
*Figure 8-6 Sample application preferences dialog*
*Figure 8-7 Sample dialogs with panes*
*Figure 8-8 Sample dialog with scrolling list*
Checklist
* Do you use standard Aqua controls provided by the system, instead
of inventing custom ones? Do you avoid assigning new behaviors to
existing interface elements?
* Does the application have the Mac OS X "feel," including window
minimization, live scrolling, live window dragging, and sheets?
* If a metaphor is being used, is it suitable for the application?
Does the metaphor match a "real" visual and behavioral representati=
on?
* Is the user always able to find an object or action on the screen?
In other words, does your interface follow the see-and-point
principle of design?
* Do document printouts exactly replicate what the user sees on the
screen? Do movies, sounds, and other types of data reproduce
faithfully regardless of what medium they're in? In other words,
is the application WYSIWYG?
* Is your application forgiving and explorable by supporting Undo?
Are there warnings about risky actions? Are users allowed to back
away gracefully from risky territory?
* If an operation can be interrupted, do you provide a Cancel or
Stop button? Can Escape or Command-period be used to cancel or
stop these operations?
* Does the application feel stable?
* Do you respect all of the accessibility features in Mac OS X, such
as keyboard navigation and focus?
* Have you made a clear, consistent distinction between basic and
advanced features?
* If your application has modes, is there a clear visual indication
of the current mode? Does the visual indication of the mode appear
near the object most affected by the mode? Are there enough
landmarks to remind the user what area of the application he or
she is in? For example, many graphics applications change the
pointer to an eraser in erase mode.
* Is each mode absolutely necessary? Do the modes within the
application properly track the user's own modes? Do users
consistently avoid the kind of errors caused by the program being
in a mode other than what the user wants or expects? Making a mode
visually apparent is no guarantee that the user will track it:
Test the application on users and find out what sorts of mistakes
they are making. If the errors are caused by modes, find ways to
communicate the modes more clearly, or eliminate them.
* Can the user save a document or quit an application at any time?
* Are the widest possible range of user activities available at any
time? The user should spend most of his or her time being able to
interact with the application--not waiting for it to complete a
process.
* Does your application always use the file's display name when the
filename is visible to users, except in expanded help tags?
* Is your application speech-enabled?
* Has all user-visible text been reviewed by a professional writer?
* Does all user-visible text use "curly" apostrophes and quotation
marks rather than straight ones (except for measurements or in
code examples)?
* Do windows, dialogs, and palettes look "clean" and free from clutte=
r?
* Does the user have control over the design of the workspace
(location and sizing of windows, toolbar customization), allowing
him or her to individualize it?
* Is the information in windows organized so the most important
information can be read first?
* Do you use white space and graphics to break up long pieces of text=
?
* Are the application, File, Edit, and Window menus present, with at
least the standard items?
* Does the application support Undo, Cut, Copy, and Paste, and are
these items in the Edit menu?
* Does your application menu contain About, Preferences, Hide, and Qu=
it?
* Do the unique menus of the application have appropriate names? Are
the names sufficiently different from the standard system menu
names? Can the user understand and remember their meaning?
* Are frequently used menu items available at the top level rather
than in a submenu or a dialog? If not, can the user change their
location?
* Are currently unavailable items dimmed (rather than being
omitted)? Are dimmed items unselectable? If all items in a menu
are unavailable, is the menu title dimmed? Can the user still pull
down the menu and see the dimmed names of the operations?
* Are toggled menu items unambiguously named?
* Are menu titles and items in caps/lowercase unless there is a
compelling reason to have a different style, such as an ALL CAPS
item in a Style menu?
* Do menu items have an ellipsis character (...) if more information
is required from the user before completing the command?
* Are the menu items truly menu items? Menu items should not be used
as text, section titles, or status indicators.
* In a hierarchical menu, does the title of the submenu have a
right-pointing triangle? Are submenus used only for lists of
related items?
* Can the user see all the commands, items, and submenu titles in a
menu without scrolling? Scrolling should be necessary only for
menus that users have added to or for menus that spill over
because the user has selected a large system font.
* Is the standard state of a window best suited to working on the
document (such as no wider than the page width), and not
necessarily as large as the full screen?
* Does your application sensibly open new windows in either the
standard or the user state?
* Can each resizable window be made as large as the smaller of
either the maximum document size or the maximum size of the
displays, including multiple monitor displays?
* Is the default position of a window contained on a single screen?
* Is each additional window opened below and to the right of its
predecessor?
* If a user drags a window from one monitor to another monitor, does
your application open subsequent windows on the second monitor?
* Do you use the lowercase letters "untitled," without additional
punctuation, in a new window title? Do you add a number to the
second and subsequent new windows, but not to the first? Do you
avoid using blank titles?
* Do document titles display or hide filename extensions appropriatel=
y?
* Do document windows with unsaved changes display a dot in the
close button?
* Before closing a window, do you check to see if the user has
changed its size or position? Do you save window positions, and
then reopen windows in the size and position in which the user
left them?
* Before reopening a window, do you make sure that the size and
position are reasonable for the user's current monitor or
monitors, which may not be the same as the monitor on which the
document was last open?
* When zooming from the user state to the standard state, do you
check if the size of the standard state would fit completely on
the screen without moving the upper-left corner? If so, is the
upper-left corner anchored? If not, is the window moved to an
appropriate default location?
* Do you appropriately display controls and selected items in
inactive windows?
* Does pressing the Tab key cycle through the available elements?
Does Shift-Tab cycle in the reverse direction?
* When appropriate, are buttons named with a verb that describes the
action that it performs, such as Erase, rather than OK?
* Do you provide a Cancel button wherever possible, especially in
progress dialogs? Does pressing Escape or Command-period indicate
Cancel? (Pressing Escape should never cause the user to lose
information.)
* If an operation can be halted midstream, with possible side
effects, is the button named Stop instead of Cancel?
* Do the Return and Enter keys map to the default button, which is
usually the button with the safest result or the most likely respon=
se?
* Do default buttons have color and pulse?
* Are buttons wide enough to accommodate their text names?
* Are buttons placed in functional and consistent locations, both
within your application and across all applications that you
develop? Is the action button placed in the lower-right corner
with the Cancel button to its left or above (for Western readers)?
* Are hidden filename extensions supported? Does the application
display a file's display name instead of its filename, and does
the Save dialog support filename extension hiding?
* Do Save dialogs place a default name in the Save As text field,
and is the name (but not its filename extension) selected?
* When a dialog refers to a document or an application, do you use
the name of the document or application in the message text?
* Has room been left to allow the dialog to grow during
localization? Most languages require more characters than English
to convey equivalent messages.
* Are the bounding rectangles of interface elements (for example,
radio buttons and checkboxes) the same size? When the alignment of
dialog elements is reversed, they should align on the opposite side=
.
* Does the application always provide some indication that an
activity is being carried out in response to a command?
* Does the application provide suitable feedback during task
processing? Does it somehow indicate the completion of a task?
Does it provide information about the duration of the task?
* Is an explanation offered if a particular action cannot be carried
out? Are alternatives offered?
* Do you make all changes clearly visible?
* Do you call the system alert sound when you want the user's
attention? Do you provide all feedback in visual as well as
auditory formats?
* Do you use the new standard alert functions for displaying alerts?
* Do you display your application icon in all dialogs? Do you also
show the caution icon in potentially data-damaging alerts?
* Does the alert have an informative title and text that not only
tell the user what is wrong, but also offer suggestions as to what
to do to correct it? The best alert messages answer the following
questions: What happened? Why did it happen? What can I do about it=
?
* Are all your alerts necessary? You can prevent many user errors
with good or preventative interface design. For example, if the
application cannot handle an 80-character filename, don't display
an 80-character field in which to enter it.
* If the user initiates an action by pressing the mouse button, does
the action take place only when the button is released (except for
drags)?
* Are there ways other than double-clicking to perform a given
action? Double-clicking should never be the only way to do
something; it should be a shortcut only.
* Can arrow keys be used in all text boxes (including in dialogs)?
Can the Shift key be used with the arrow keys to extend the
selection (including in dialogs)?
* If text is selected, does pressing an arrow key cause the
insertion point to go to the corresponding end of the range and
deselect it?
* Are discontinuous selections made with the Command key modifier
(for lists and arrays)? The Shift key is used for graphics
selections and continuous text extensions.
* Do you use Command-arrow key and Option-arrow key for moving the
insertion point in larger semantic units? (Note that when multiple
script systems are available, Command-Left Arrow and Command-Right
Arrow are intercepted by the system and used for changing the
keyboard layout.)
* Does the active font size in a menu have a checkmark next to it?
* Do you avoid making assumptions about font sizes? For example, the
system font may have a different size in other countries.
* Do your icons represent objects that users are familiar with and
that are universally recognizable?
* Do you use a common theme for icons associated with your applicatio=
n?
* Is the instructional suite written for the right audience?
* Do you provide HTML help viewable in Help Viewer and a Help
command in the Help menu?
* Does your documentation focus on real-world user tasks and
troubleshooting?
* When appropriate, do your dialogs have help buttons that open
relevant help text?
|
56 messages has been excluded from this view by a project administrator.
